Unified Process: The Design Workflow

1
Unified Process The Design
Workflow

• Dr. Lisa J. Burnell
• Texas Wesleyan University
• Spring 2000

2
References

• The Unified Software Development Process,
  Jacobson, Booch Rumbaugh, 1999. Chapter 9
• Prereq for TWU Chapter 12 of Schach text

3
Purpose of Design

• Develop Detailed System Specification
• Account for all requirements and constraints
• detailed requirements on subsystems, classes,
  interfaces
• decide languages, DBMS, OS, other technologies
• Prepare for implementation
• decompose into pieces that can be assigned to
  different groups
• Detail is almost at the level of code
• industry moving away from manual coding
• Primary activity in
• late Elaboration phase iterations
• early Construction phase iterations

4
Design process interfaces
Design Model
Analysis Model (requirements and system structure)
Design Process
Deployment Model
5
Comparison of Analysis and Design Models

• Blueprint (not conceptual)
• Design specific (little room left for making
  choices on how to do something)
• Class stereotypes move from control/boundary/entit
  y to implementation language specific
• Usually many layers (architecture usually has
  few)
• Focus on sequence
• Still contains an architectural view, plus
  detailed views
• Maintain throughout life of product
• Created by round-trip engineering with
  implementation model in visual environments
• STILL want traceability back to use case model!

See Figure 9.1 of UML book
6
Who does what (workers/artifacts)

• Architect
• System structure
• design model
• deployment model
• architecture description
• high level views of the design deployment
  models
• Use-case engineer
• use-case realizations -- design
• ensure all artifacts correctly models the
  use-cases
• Component engineer
• handles the nitty gritty
• design classes
• design subsystems (architect decides what the
  subsystems are)
• interfaces
• recommended
• does the implementation too

7
Artifact Overview

• Design Model
• Design Classes
• Use-Case Realization -- Design
• Class diagrams for a use case
• Interaction diagrams ( flow of events
  description) for a use case
• Implementation requirements
• Design Subsystems
• including service subsystems
• Interface Specification
• Deployment Model
• Architecture Description Views of the
• Design Model
• Deployment Model

8
Artifact Description

• Design Model
• Complete object model
• subsystems, classes, relationships
• minimal abstraction
• should be simple mapping to code
• Design Classes
• code-specific specification
• classes, attributes, relationships, etc.
• As much detail as makes sense
• exception method body--gtpseudocode
• only do this if designer ? implementor
• real-time, distributed, multi-threaded systems
• other books articles address

More details examples will follow
9
Artifact Description

• Use-Case Realization -- Design
• Purpose
• Planning builds in construction
• Defining traceability to use case model
• through the analysis model, if its retained
• Use-case specific views of
• class diagrams
• interaction diagrams flow of events
• Design subsystems
• Group artifacts into manageable pieces
• Purpose
• help schedule, assign work packages
• support incremental/optional delivery of services

More details examples will follow
10
Artifact Description

• Interface
• specify interfaces for all class subsystems
• Purpose
• different teams can implement different
  components
• interface specification is all they need to know
  to use components from another team
• Deployment Model
• Purpose
• specifies where classes subsystems will reside
• nodes, network configuration

More details examples will follow
11
Artifact Description

• Architecture Descriptions
• Text that describes (at architectural level)
• design model
• deployment model
• Purpose
• Describe the fundamental system structure
• When all the gory details are more than someone
  needs to know

More details examples will follow
12
Design Model

• Analysis Packages --gt Design Subsystems
• The container for the artifacts being produced in
  design
• subsystems
• used to organize the design model into manageable
  peices
• classes
• use-case views
• interfaces

13
Design Classes

• Analysis classes --gt design classes
• Design classes are mostly specified in the
  implementation language
• example public, private and protected attributes
  (C)
• example ltltformgtgt, ltltuser controlgtgt class (VB)

14
Design Class Example
15
Use-Case Realization -- Design

• Views of the design model for a specific use-case
  
• Class diagrams
• MN mapping between use cases and design entities
• this view shows just parts of the design that
  implements a use case
• Example which classes implement the requirement
  set a mood
• Interaction diagrams ( flow of events
  description) for a use case
• Okay to show interaction between subsystems
  instead of between objects
• TIP Message names should be meaningful (indicate
  the operation being performed)
• Flow of Events description
• tip use subsystem and object names, but not
  attribute, operation or association names (too
  hard to maintain)
• can have a combined document that describes
  multiple interaction diagrams
• Implementation requirements
• textual description of implementation reqs, or
  new derived reqs
• example The Payment Request object must
  concurrently process up to 10 buyer clients
  without perceivable delay for any individual buyer

16
Design Subsystemsincluding service subsystems

• Manageable size groupings of artifacts
• cohesive
• low coupling
• represent separation of design concerns
  (different skill groups can concurrently
  implement)
• reusable components and their wrappers
• legacy systems middleware or system layers
• Top 2 layers often come from analysis packages
• now we refine these
• example device controller package

17
Interface Specification

• Specify interfaces for each
• subsystem
• class
• Purpose different teams can implement
  independently
• Look at
• boundary classes
• messages into/out of analysis packages

18
Deployment Model

• What subsystems/classes go where and connections
  between

Internet
MRC Simulation Users Machine
Intranet
19
Architecture Description Views

• Design
• Refined architecture view
• subsystems, interfaces, dependencies between them
• key design classes
• usually not all subclasses (radio, tape player)
• complex or critical use-case--design views
• Deployment
• if deployment diagram is too complex to
  understand (if youre trying to get the basic
  structure), create an abstracted view

20
Coming Next

• Details of
• activities
• how tos for the artifacts
• examples