SYST512 Unit 3: The Unified Software Development Process

1
SYST512Unit 3 The Unified Software
Development Process

• Analysis and Design Workflow

2
Analysis Definition and Reasons

• Analysis is to resolve unresolved issues by
  analyzing the requirements in depth
• The language of the developers can be used to
  describe the results
• Reasons for unresolved issues
• Use cases must be kept as independent of each
  other as possible
• Use cases must be described using the language of
  the customer
• Each use case must be structured to form a
  complete and intuitive specification of
  functionality

3
The Purpose of the Analysis Model

• Yields a more precise specification of the
  requirements than we have in the results from
  requirements capture, including the use-case
  model
• As it is described in the language of the
  developers and it can introduce more formalism
  and be used to reason about the internal workings
  of the system
• It structures the requirements in a ways that
  facilitate understanding them, preparing them and
  maintaining them
• It can be considered a first cut at a design
  model and is an essential input to the design and
  implementation

4
Comparison of Use-Case Model and Analysis Model
5
The Role of Analysis
6
Artifact Analysis Class

• Focuses on handling functional requirements and
  postpones the handling of nonfunctional
  requirements by designating them as special
  requirements of the class
• Seldom defines or provides any interface in terms
  of operations or their signatures
• Defines attributes at a fairly high level
• Involved in relationships, although are at more
  conceptual level than the design or
  implementation counterparts
• Fit in one of three basic stereotypes boundary,
  control or entity

7
Boundary Classes

• Represented by
• Used to model interaction between the system and
  its actors, often information I/O
• Model parts of the system that depend on actors
  gt can be used to clarify system boundaries
• Should be kept at a reasonably high level
• Often represent printer interfaces, terminals,
  APIs, etc.
• Each boundary class should be related to one
  actor and vice versa

8
Entity Classes

• Represented by
• Used to model information that is long-lived and
  persistent
• Often derived from the corresponding business
  entity class
• Difference is that in the analysis model, the
  entity classes represent objects handled by the
  system
• May have associated behaviors and a logical data
  structure

9
Control Classes

• Represented by
• Model coordination, sequencing, transactions and
  control of other objects
• Dynamics of the system are modeled by control
  classes
• Do not encapsulate issues related to interactions
  with the actors
• Encapsulate changes to control, coordination,
  sequencing, transactions and business logic

10
Example Payment Scheduler (Jacobson p. 185)
Invoice
browses
change status
Buyer
schedule invoice
Payment Scheduler
Payment Request UI
11
Artifact Use-Case Realization-Analysis

• A Use-Case Realization-analysis is a
  Collaboration within the analysis model that
  describes how a specific use-case is realized and
  performed in terms of analysis classes and their
  interacting analysis objects
• Composed of class diagrams, interaction diagrams,
  flow of events analysis and special requirements
• Class diagrams are attached to use-case
  realizations, showing their participating classes
  and relationships

12
Interaction Diagrams Flow of Events Analysis, and
Special Requirements

• For Interaction Diagrams
• Object interaction is illustrated by using
  collaboration diagrams
• Boundary object need not be specific to one
  use-case realization
• An entity object is often not specific to one
  use-case realization
• Control classes often encapsulate control related
  to a specific use-case
• For analysis models, the flow of events focuses
  on how the use-case is realized by the system in
  terms of (logical) objects that collaborate
• Special requirements are textual descriptions
  that collect all nonfunctional requirements on a
  use-case realization

13
An Example of a Realization of a Use Case
(Jacobson p. 188)
5. Get
Order Confirmation
4. Get
1. Browse Invoices 6. Schedule invoice
for payment
Order Handler
2. Browse
3. Check Invoice
Invoice
change status
Buyer
9. setStatus(scheduled)
7. Schedule payment
8. New
Payment Request
Payment Scheduler
Payment Request UI
14
Artifact Analysis Package

• Can represent a separation of analysis concerns
• Can be created based on functional requirements
  and on the problem domain
• Are likely to become distributed among subsystems
  in the two top application layers in the design
  model
• Service package contains a reusable set of
  fundamentally related classes
• A service package is indivisible
• When a use case is realized, one or more service
  packages may be participants
• A service package often has very limited
  dependencies toward other service packages
• A service package is usually of relevance to only
  one or a few actors
• The functionality defined by a service package
  can be managed as a delivery unit
• Service packages may be mutually exclusive
• Service packages constitute an essential input to
  subsequent design and implementation models in
  terms of service subsystems

15
Analysis Workers

• Architect - Responsible for ensuring that the
  analysis model as a whole is correct, consistent
  and readable as well as the architecture of the
  analysis model
• Use-Case Engineer - Responsible for the integrity
  of one or several use-case realizations, ensuring
  that they fulfill the requirements made on them
• Component Engineer - Defines, maintains the
  responsibilities, attributes, relationships and
  special requirements of one or several classes,
  making sure that the analysis class fulfills the
  requirements

16
Analysis Summary

• The analysis model includes the following
  elements
• Analysis packages and service packages and their
  dependencies and contents
• Analysis classes, their responsibilities,
  attributes, relationships and special
  requirements
• Use-case realizations

17
Design

• The purposes of design are to acquire an in-depth
  understanding of the issues regarding
  nonfunctional requirements and constraints
• Create and appropriate input to and departure for
  subsequent implementation activities by capturing
  requirements on individual subsystems, interfaces
  and classes
• Be able to decompose implementation work into
  more manageable pieces
• Capture major interfaces between subsystems early
  in the softwares life cycle
• Be able to visualize and reason about the design
  by using a common notation
• Create a seamless abstraction of the systems
  implementation

18
The Role of Design
19
Comparison of Analysis Model and Design Model
20
Artifact Design Class

• The language used to specify a design class is
  the same as the programming language
• Visibility of attributes and operations of a
  design class is often specified
• Relationships in which a design class is involved
  with other classes often has a straightforward
  meaning when the class is implemented
• The methods of a design class have
  straightforward mappings to the corresponding
  methods in the implementation class
• A design class can postpone the handling of some
  requirements to subsequent activities by noting
  them as implementation requirements on the class
• A design class is often given a stereotype that
  is seamlessly mapped to a construct in the given
  programming language
• A design class can realize - and thus provide -
  interfaces if it makes sense to do so in the
  programming language
• A design class can be active and maintain their
  own thread of control and run concurrently with
  other objects

21
Artifact Use-Case Realization-Design (1 of 2)

• A collaboration within the design model that
  describes how a specific use case is realized and
  performed in terms of design classes and their
  objects
• Can trace back to the use-case realization-analysi
  s
• Contains textural flow-of-events, descriptions,
  class diagrams depicting its participating design
  classes and interaction diagrams depicting the
  realization of a particular flow or scenario of
  the use-case in terms of interactions between
  design objects
• Provides the physical realization of the use-case
  realization-analysis and handles most of the
  nonfunctional requirements
• Can postpone some of the handling of
  nonfunctional requirements to the implementation

22
Artifact Use-Case Realization-Design (2 of 2)

• The Use-Case Realization-Design Contains
• Class Diagrams - Important to coordinate all the
  requirements relevant to a class and objects by
  using class diagrams attached to a use-case
  realization
• Interaction Diagrams - The sequence of actions
  begins when an actor invokes the use case by
  sending some form of message to the system
• Flow of Events - Textual description of an
  interaction diagram which does not mention object
  attributes, associations and operations
• Implementation Requirements - Textual description
  of requirements that are better handled at
  implementation

23
Artifact Design Subsystem

• Provide a means of organizing the artifacts of
  the design model into more manageable pieces
• Can represent a separation of design concerns
• The two top application layers and their
  subsystems in the design model often have a
  straightforward trace to analysis packages and/or
  classes
• Can represent large grained components in the
  systems implementation
• Can represent reused software products by
  wrapping them
• Can represent legacy systems by wrapping them
• Service subsystems are used to prepare for
  changes in individual services by localizing the
  changes to the corresponding service subsystem

24
Artifact Interface

• Used to specify the operations provided by design
  classes and subsystems
• Design class that provides an interface must also
  provide methods that realize the operations of
  the interface
• A subsystem that provides an interface must also
  provide methods or subsystems that provide the
  operations of the interface
• Provide a means of separating the specification
  of functionality in terms of operations from
  their implementation in terms of methods

25
Artifact Architecture Description

• Contains the following artifacts
• The decomposition of the design model into
  subsystems, their interfaces and the dependencies
  between them
• Key design classes such as classes that trace to
  architecturally significant analysis classes,
  active classes and design classes
• Use-case realizations-design that realize some
  important and critical functionality that needs
  to be designed early in the system lifecycle

26
Artifact Deployment Model

• Object model that describes the physical
  distribution of the system in terms of how
  functionality is distributed among computational
  nodes
• Each nodes represents a computational resource,
  often a processor or similar hardware device
• Nodes have relationships that represent means of
  communications between them, e.g., internet
• The deployment model can describe several
  different network configurations
• The functionality (or processes) of a node is
  defined by the components deployed on the node
• The deployment model itself manifests a mapping
  between the software architecture and the system
  architecture

27
Workers

• Architect - responsible for the integrity of the
  design and deployment models, ensuring that the
  models are correct, consistent and readable
• Not responsible for the continuous development
  and maintenance of the various artifacts within
  the design model
• Use-Case Engineer - responsible for the integrity
  of one or several use-case realizations-design,
  ensuring that they fulfill the requirements made
  on them
• Component Engineer - defines and maintains the
  operations, methods, attributes, relationships
  and implementation requirements of one or several
  design classes, making sure each design class
  fulfills the requirements made on it from the
  use-case realizations in which it participates

28
Design Workflow Overview
Architectural Design
Architect
Design a Use-Case
Use-Case Engineer
Design a Subsystem
Design a Class
Component Engineer
29
Activity Architectural Design

• Outline the design and deployment models by
  identifying
• Nodes and their network configurations
• Subsystems and their interfaces
• Architecturally significant design classes, such
  as active classes
• Generic design mechanisms that handle common
  requirements, e.g. persistency, distribution,
  performance

Use-Case Model
Subsystem (outlined)
Supplementary Requirements
Interface (outlined)
Architect
Design class (outlined)
Analysis Model
Deployment model (outlined)
Architecture Description
Architectural Design
Architecture Description
30
Sequence Diagrams

• The use case is invoked by a message from an
  actor instance to a design object
• Each design class identified in the preceding
  step should have a least one design object
  participating in the sequence diagram
• Messages are sent between object lifelines to
  realize the use case
• The sequence in the diagram should be in primary
  focus because the use-case realization-design is
  the primary input when the use case is
  implemented
• Use labels and flow-of-events-design to
  complement the sequence diagrams
• The sequence diagram should handle all
  relationships of the use-case that is realized

31
An Example Sequence Diagram(Jacobson p. 252)
Payment Request UI
Payment Request Processing
Invoice Processing
Invoice
Order Confirmation
Payment Scheduler
Buyer
browse invoice
browse()
browse invoices()
Order Handler
getbrowseinfo()
checkinvoice
getConfirmationinfo()
getinvoice()
getinvoiceinfo()
Schedule invoice for payment
SchedulePayment(invoice)
Schedule(invoice)
new()
Payment Request
setStatusOfInvoice(Scheduled)
setStatus (Scheduled)
32
Class Design (1 of 2)

• Designing a class involves
• Outlining the design class
• Designing boundary classes
• Designing entity classes
• Designing control classes
• Distribution issues
• Performance issues
• Transaction issues
• Identifying operations
• Describe operations that need to be provided by
  the design class in the syntax of the programming
  language

33
Class Design (2 of 2)

• Designing a class involves (cont.)
• Identifying attributes
• Reuse is encouraged
• Identifying associations and aggregations
• Based on message transmissions in sequence
  diagrams
• Identifying generalizations
• Can be supported by inheritance or message-based
  delegation
• Describing methods
• How operations are realized
• Describing states
• Statecharts
• Handling special requirements
• May be postponed until implementation

34
Design Summary

• The design model includes
• Design subsystems and service subsystems and
  their dependencies, interfaces and contents.
• Design classes, including active classes, and
  their operations, attributes, relationships, and
  implementation requirements.
• Use-case realizations -design, which describe how
  use-cases are designed in terms of collaboration
  within the design model.
• The architectural view of the design model,
  including its architecturally significant
  elements.
• Design results in the deployment model which
  includes
• Nodes, their characteristics and connections
• An initial mapping of active classes onto nodes
• The architectural view of the deployment model,
  including its architecturally significant
  elements
• The design model and the deployment model are the
  primary input to implementation and test