Unified Process: Elaboration Phase

1
Unified Process Elaboration
Phase

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

2
References

• The Unified Software Development Process,
  Jacobson, Booch Rumbaugh, 1999.
• Chapter 8

3
Who does what

• Architect architectural analysis

Use Case Engineer Use case analysis
Component Engineer Class and Package Analysis
4
Identify Packages
Architect -- Architectural Analysis

• Group related use cases into analysis packages
• each package supports
• one domain, task, or actor or
• are otherwise related (via extends/generalizes)
• MRC Example (too abstract?)
• Controller package
• Simulator package

5
Analysis Packages
A service is a functionally related set of
classes. A service performs some piece of
functionality for the customer Example MRC
Internet service or email service (part of a
connectivity package, that also does things like
get TV viewing guides)
6
Architecture Analysis Tips

• Handling commonality between packages (same class
  needs to be in 2 or more packages)
• these are usually domain entities (e.g. customer)
• extract class into new class (separate customer
  class)
• make original packages dependent on this new
  package
• Finding services
• Look for services that could be purchased
  separately by customer

7
Defining Analysis Package Dependencies

• Layered model often useful to get low coupling
  high cohesion

App specific pkg general pkg
Other layers added in design
8
MRC Analysis Package
Consider a smart house development company
Mood Control
User Profileusers habits could be used for MRC,
HVAC, security, etc.
9
Identify Obvious Entity Classes
Architect -- Architectural Analysis

• Purpose
• skeleton for use case engineer
• What to do
• get major entities from use cases (
• DBAs its like building ER diagram
• Example MRC
• MRC User Name, ID, Age (Adult/Teen/Child)
• Device ID, Power Status (off/on), Volume
• Environment Date, Time, Day of week

10
Identify Common Special Requirements
Architect -- Architectural Analysis

• Find items the use case engineer needs to
  consider (further document) in order to give
  proper info to designer/implementer
• expected number of objects (instances)
• expected frequency of updates
• data storage needs
• reliability needs (e.g. if system crashes, does
  this object need to survive?)
• Here, you just define the items (like a template)
  that the use case engineer needs to examine to
  fill in specifics

11
Identify Analysis Classes
Use Case Engineer -- Analyze Use Case

• Purpose capture data (class diagram)
• Look at uses cases
• may need to more KA
• Find classes
• classify as boundary, entity or control
• For each class, sketch their
• name
• responsibilities (tasks)
• attributes
• relationships

12
Tips -- Identify Analysis Classes
Use Case Engineer -- Analyze Use Case

• Use noun extraction or other techniques to help
  decide what should be a class (vs. an attribute,
  for example abstract nouns like illumination)
• 1 boundary class/human actor
• central boundary class to represent main
  interface window
• 1 boundary class/entity class
• primitive boundary class to represent other
  parts of UI
• 1 boundary class/external system actor
• central boundary class to represent
  communications interface
• 1 control class for control/coordination of the
  use case
• for non-trivial control
• may be further subdivided later
• More tips on pages 204-205 of UP book

13
Describe Analysis Object Interactions
Use Case Engineer -- Analyze Use Case

• Purpose capture action via collaboration
  diagram
• interaction diagram flow of events
• actors, objects, links
• may create several/use case (primary
  alternative)
• may augment with text to explain
  (maintainability!)

14
Tips -- Describe A.O. Interactions
Use Case Engineer -- Analyze Use Case
msg

• Start with actor to boundary
• If find analysis classes (prior step) that dont
  fit in any collaboration diagrams, throw them
  out!
• Messages should convey essence of task
• e.g. power on device
• process may uncover relationships between
  classes -- go back and add to class diagram
• Links and messages are primary focus
• sequence is good, but secondary
• Show relationship (e.g. specialization) links
  here too

15
Capture Special Requirements
Use Case Engineer -- Analyze Use Case

• Look at special requirements defined by architect
• decide which apply to this use case
• fill in values that apply
• examples
• user profile class is persistent
• CD selector must be able to handle duplicate CD
  titles
• other inconsistency handling, throughput, etc.

16
Component Engineer Actions
Component Engineer -- Analyze Class and Package
UCR-Analysis from Use case engineer

• responsibilities
• attributes
• relationships
• special reqts

Analysis Class
Analysis Class Outline from Architect
Analysis Packages
Architecture Description Outline from Architect
17
Responsibilities
Component Engineer -- Analyze Class

• Study the diagrams
• use cases, robustness and interaction diagrams
  any other
• Example The MRC Mood Controller has the
  following responsibilities
• Construct a mood frame (all settings)
• Request a prespecified mood frame
• Initiate device settings according to mood frame
  settings
• Tip Try working with 1 use case realization at a
  time, each time refine responsibilities to
  integrate new use case

18
Attributes
Component Engineer -- Analyze Class

• name should be a noun
• Keep at domain level (station, not floating
  point)
• try for attribute type reuse (e.g. station)
• Attribute appear in many classes?
• Make it its own class
• Class too complicated?
• Split it up (duh!)
• Control classes may have few or no attributes
• often just accumulators or derived values
• more tips on page 209

19
Relationships
Component Engineer -- Analyze Class

• Associations Aggregations
• Note these may change in design as
  implementation issues emerge
• Look at links in collaboration diagram
• try to minimize these types of
• Define multiplicities, role names, self
  associations, etc.
• Use aggregations when objects represent
• part of (a bike has a frame, wheels, )
• physical containment (car has a driver)
• conceptual collection (family lt-- mom, dad, kids)

An invoice is the payment of one or more orders
Order
Invoice
20
Relationships Generalizations
Component Engineer -- Analyze Class

• For shared or common behavior (domain level)

21
Capturing Special Requirements
Component Engineer -- Analyze Class

• Capture as come up and from architect for design
  consideration
• Example (page 211)
• INVOICE CLASS persistence requirements
• size range 2-24 KB / object
• volume lt 100,000
• update frequency
• create/delete 1000/day
• update 30/hour
• read 1/hour

22
Analyze Package
Component Engineer -- Analyze Package

• Goals
• low inter-package coupling
• validated package (meets reqs)
• dependencies described
• helps estimate impact of future changes
• cohesive packages
• Tips
• keep package dependencies to a minimum what you
  do have must be maintained!