Unified Process: The Analysis Workflow

1
Unified Process The Analysis
Workflow

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

2
References

• UML Distilled, 2nd Edition, Fowler Scott, 2000.
  
• The Unified Software Development Process,
  Jacobson, Booch Rumbaugh, 1999.
• Chapter 8
• Prereq for TWU Chapter 11 of Schach

3
Purpose of Analysis

• Understand requirements
• refine
• structure
• resolve remaining system requirements issues
• informal (use case) language of customer means
  requirements are not guaranteed to be complete,
  correct, redundant, inconsistent, etc.
• move from informal to formal
• informal is easy for customer
• document so can maintain them can use to
  structure system
• Primary activity in the Elaboration phase
• early iterations

4
Moving inward

• use case model (external view)
• imprecise
• language of customer
• structured by functionality
• use cases
• analysis model (internal view)
• more precise
• language of developer
• first cut at design
• architecture
• conceptual design (home plans)
• structured by architecture
• classes, packages
• KEY traceability between models

5
Who does what (workers/artifacts)

• Architect
• analysis model
• container for top view of system
• architecture description
• Use-case engineer
• use-case realizations -- analysis
• ensure all documentation correctly models the
  use-cases
• will also do use-case realizations -- design
• Component engineer
• analysis classes
• analysis packages

6
Artifact Analysis Model

• A conceptual object model
• Analysis System
• top-level package of system
• Composed of analysis packages
• subsystems or system layers
• contains classes
• Use-case realization -- analysis
• link to the use case model
• for traceability between models
• UP book page 181 (Fig 8.3)

7
Artifact Analysis Class

• Abstraction
• represents 1 classes/subsystems
• focus on functional requirements
• save non-functional for design
• responsibilities listed
• describe behavior (textual)
• save methods and their interfaces for later
• attributes (not data type level of detail)
• relationships (dont worry about implementation
  details yet)
• three types of classes
• boundary -- the interfaces
• entity -- the data
• control -- the procedures

8
Analysis Class Boundary

• Models interaction between system and actors
• receiving and presenting information
• requests from and to users and external systems
• Realized in (the following components)
• GUIs
• Communications interfaces
• Printers, terminals, sensors
• Tips
• each boundary class relates to 1 actors
• fairly high abstraction
• describe what info is passed
• dont model every button

9
Analysis Class Entity

• Models information
• and associated behavior
• long-lived, usually persistent data
• key place to represent domain objects
• from developers perspective
• think of what goes in the ER diagram

10
Analysis Class Control

• Models
• coordination
• sequencing
• transactions
• complex calculations
• control of other objects
• not related to a specific entity in system
• e.g. inductive learning component
• Encapsulates control related to a specific use
  case (common usage)

11
Analysis Class Example
Invoice
Change status
browses
Buyer
Schedule invoice
Payment Request UI
Payment scheduler

• Adapted from UP text, page 187

12
Artifact Use-Case Realization Analysis

• Link (for traceability) from a use case to
  analysis classes
• Composed of
• description of flow-of-events (text)
• class diagrams
• show participating analysis classes and use cases
• interaction diagram
• shows scenario flow in terms of analysis objects
• Special requirements
• non-functional requirement, e.g.,
• voice command response within 2 seconds
• invoices should be paid via the SET standard

13
Class DiagramAnalysis

• Link analysis model items to use cases
• For traceability
• Ensure that the class meets all requirements of
  all the use cases it is associated with
• Usually
• Boundary and entity classes are associated with
  many use cases
• Control classes are associated with one use cases
  (but can be with many, or one use case can have
  many control classes, or none!)

14
Interaction DiagramAnalysis

• Collaboration diagrams
• focus is on finding requirements and
  responsibilities on objects and not on finding
  detailed and chronological sequences of
  interactions (in which case we would use sequence
  diagrams) pages 186-187
• Create links between objects
• Attach messages to these links
• UP page 188

15
Flow of EventsAnalysis

• Text to accompany figures
• Write it in terms of the objects that interact to
  perform a use case
• especially the control objects
• do not mention object attributes,
  responsibilities and associations
• too hard to maintain through changes
• in terms of system behavior (use cases were in
  terms of externally observable behavior)
• Example UP page 189

16
Special Requirements Analysis

• Collects all non-functional requirements from the
  use cases
• Textual

17
Artifact Analysis Package

• Mechanism for grouping artifacts of this workflow
• assign packages to developers/companies
  independently
• usually leads to design subsystems
• look for reuse possibilities
• Each package should be
• cohesive
• strongly related (via domain, not design
  concepts)
• think of services to be provided
• loosely coupled
• dependencies between packages is minimized
• more tips UP page 191

18
Artifact Architecture Description

• Architectural view of the analysis model
• a view primarily addresses the refinement and
  structuring of the system requirements. The
  structure in this view is preserved as much as
  possible when we design and implement the
  systems architecture.
• Architecturally significant items weve created
• analysis packages and their dependencies
• key analysis classes (are general, central and
  have many relationships with other classes.
  Consider vs. subclasses)
• critical functionality/broad coverage use case
  realizations