Chapter 13 Requirements and Domain Classes

1
Chapter 13Requirements and Domain Classes
2
Process Phases Discussed in This Chapter
Requirements Analysis
Design
Architecture
Framework
Detailed Design
Implementation
Key
secondary emphasis
main emphasis
x
x
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
3
Learning Goals for This Chapter
Understand distinctions

• OO analysis vs. design
• Traditional application development vs. OO
  analysis design
• Domain vs. non-domain classes
• determine basic Use Cases
• create sequence diagrams
• select domain classes
• use domain classes to organize requirements

Be able to
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
4
The Activities of Application Development

• Gather requirements
• Specify Customer-oriented requirements specs
• Specify Developer-oriented requirement specs
• Create design
• Select architecture
• Specify detailed design
• Implement design

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
5
Characteristics of OO Analysis Design

• Approach is initially through the applications
  domain classes (its ingredients)
• -- rather than its required functionality
• Like starting a recipe by listing the ingredients
• Typically obtain from introducing use cases then
  transforming these into sequence diagrams
• Introduces domain classes at requirements time
• Remaining classes at design time
• Supports iterative development processes

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
6
WinHelp Example Requirements

• WinHelp shall advise novice WindowsTM users on
  their difficulties using this operating system.

Input Problem description Process Determine
users difficulty match with solution
database Output Up to 3 possible solutions
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
7
Non-OO Design of WinHelp
Get description
Report
problem description
solution
Solution database
Match
solution
key
XXX
data flow
functional component
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
8
Non-OO Design of WinHelp Top-Down Organization
Control
Get description
Match
Report
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
9
Requirements Traceability Matrix 
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
10
Disadvantages of Functional Methods

• Whole application must be specified first
• - to do top-down design
• Usage hard to change
• Code does not match the application well
• Traceability difficult
• Re-use low

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
11
The Basic OOAD Approach

1. State the main use cases
2. Convert the use cases to sequence diagrams
3. Select the resulting (domain) classes

select
refine
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
12
Design Goal At Work ? Reusability ?
Because we want to reuse classes, we identify
domain classes early in the process.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
13
Analysis
Design
1/2
After Jacobson et al USDP

• 1. Conceptual abstract
• 2. Applicable to several designs
• 3. control, entity boundary stereotypes
• 4. Less formal
• 5. Less expensive to develop

• 1. Concrete implementation blueprint
• 2. Specific for an implementation
• 3. No limit on class stereotypes
• 4. More formal
• 5. More expensive to develop (? 5)

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
14
Analysis
Design
2/2
After Jacobson et al USDP

• 6. Outlines the design
• 7. Emerges from conceptual thinking
• 8. Few layers
• 9. Relatively unconstrained

• 6. Manifests the design
• 7. May use tools (e.g. visual, round-trip
  engineering)
• 8. Several layers
• 9. Constrained by the analysis architecture

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
15
OOAD Roadmap(to be explained)
I. Requirements analysis phase
Develop use cases with customer
Convert use cases to sequence diagrams
Seek domain classes from other sources
Gather domain classes
Use to classify requirements
II. Architecture phase
Consider Framework (existing, modified, or new)
Determine architecture
III. Detailed Design phase
Introduce design patterns or components
Finalize design (class model, use case model, .)
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
16
Key Concept ? The Object-Oriented Approach ?
is to begin with ingredients rather than
functionality.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
17
Case Study Summary Specification Encounter (1/2)

• Role-playing game which simulates all or part of
  the lifetime of the player's character.
• Game characters not under the players control
  called "foreign" characters.
• Game characters have a number of qualities such
  as strength, speed, patience etc. 
• Each quality has a value
• Characters engage each other when in the same
  area. 

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
18
Case Study Summary Specification Encounter (2/2)

• The result of an engagement depends on the area
  in which it takes place, and on the values of the
  characters relevant qualities
• Players may reallocate the values of their
  qualities when the foreign character is absent
• Reallocation takes effect after a delay
• Success is measured by life points accumulated,
  by living as long as possible etc.

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
19
Encounter Area Configuration
Kitchen
Dressing room
Courtyard
Living room
Dungeon
Study
Key
connection
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
20
Foreign Character Freddies Image
Graphics reproduced with permission from Corel.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
21
OOAD Roadmap Parts Discussed in This Section
I. Requirements analysis phase
Develop use cases with customer
Convert use cases to sequence diagrams
Seek domain classes from other sources
Gather domain classes
II. Architecture phase
Consider Framework (existing, modified, or new)
Determine architecture
III. Detailed Design phase
Introduce design patterns or components
Finalize design (class model, use case model, .)
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
22
Initialize Use Case for Encounter Case Study
Use case titles
Use case detail
actors
Initialize
Initialize 1. Application displays players main
character in the dressing room. 2. Application
displays a window for setting his character's
qualities. 3. Player allocates the qualities of
his main character. 4. Player chooses an exit
from the dressing room.
Travel to adjacent area
player
Engage foreign character
Set rules
designer
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
23
Engage Foreign Character Use Case
Encounter
Engage Foreign Character 1. Application displays
the foreign character in the same area as the
players. 2. Application exchanges quality values
between the two characters. 3. Application
displays the results of the engagement. 4.
Application displays players character in a
random area.
Initialize
Travel to adjacent area
player
Engage foreign character
designer
Set rules
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
24
Travel To Adjacent Area Use Case
Encounter
Travel to Adjacent Area 1. Player hits hyperlink
connecting displayed area to adjacent area. 2.
Application displays the indicated adjacent area,
including the players character.
Initialize
Travel to adjacent area
player
Engage foreign character
designer
Set rules
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
25
Key Concept ? Use Cases ?
are a beginning point for requirements and
analysis.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
26
Sequence Diagram for Initialize Use Case
main player character Player Character
Player quality window
dressing room Area
Encounter- Game
1.1 create and display
1.2 create and display
Player
2. create and display
3.1 set quality values
3.2 set quality values
4. select exit for character
5. move
Numbering keyed to use case
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
27
Sequence Diagram for Engage Foreign Character Use
Case
Engagement Display
Engagement
Encounter Game
freddie Foreign Character
Player Character
1.1 create display
1.2 create
2.1 execute
2.2 change quality values
3 create and show
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
28
Sequence Diagram forTravel to Adjacent Area Use
Case
Connection Hyperlink
AreaConnection
PlayerCharacter
User
Area
1.1 hit
1.2 display other area
2.1 display
2.2 display
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
29
OOAD Roadmap Version 2
OOAD Roadmap Parts Discussed in This Section
I. Requirements analysis phase
Develop use cases with customer
Convert use cases to sequence diagrams
Seek domain classes from other sources
Gather domain classes
II. Architecture phase
Consider Framework (existing, modified, or new)
Determine architecture
III. Detailed Design phase
Introduce design patterns or components
Finalize design (class model, use case model, .)
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
30
Classes in Initialize Sequence Diagram

• EncounterGame
• - a class with a single object
• PlayerCharacter
• - with object mainPlayerCharacter
• Area
• - with object dressingRoom, and
• PlayerQualityWindow
• - a GUI class included to complete the use case.

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
31
Harvesting Classes From the Sequence Diagrams
Area
EncounterCharacter
EncounterAreaConnection
GameCharacter
Engagement
EngagementDisplay
Player
ForeignCharacter
ConnectionHyperlink
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
32
OOAD Roadmap Version 3
OOAD Roadmap Parts Discussed in This Section
I. Requirements analysis phase
Develop use cases with customer
Convert use cases to sequence diagrams
Seek domain classes from other sources
Gather domain classes
II. Architecture phase
Consider Framework (existing, modified, or new)
Determine architecture
III. Detailed Design phase
Introduce design patterns or components
Finalize design (class model, use case model, .)
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
33
Finding Domain Classes From Other Sources

• Brainstorm
• List every reasonable class candidate.
• See checklist of potential sources.
• (2) Cut
• Pare down to a few essential classes.
• Err on the side of rejecting.
• (3) Verify
• Combine with classes from sequence diagrams.
• Ensure class names classify all requirements.

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
34
PhotoComposer
... a program for making compositions of
photographs as illustrated ... can be used to
bring together photographs of individual family
members, possibly taken at different times, so
that the result has the effect of a family
photograph ... backgrounds can also be chosen by
the user
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
35
Ideas for Brainstorming Domain Classes

• Coad Yourdon
• Structures
• Systems
• Devices
• Events
• Roles
• Sites
• Organizational units

• Extract nouns from text
• Booch
• Discovery
• Invention

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
36
PhotoComposer Brainstorming I
Nouns from text (existing documentation)
Background, Frame, Composition, Display,
Family, Photograph, Portrait, Record,
ScrollBar, User
Invention (generalization etc.)
Album, Ceremony, Collage, Graphic,
Illustration, Memento, Memorial, Souvenir,
Visualization
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
37
PhotoComposer Brainstorming II

• Sites
• Monitor
• Laboratory
• Organizational units
• Family
• InLaws
• Roles
• Composer
• Presenter
• User

• Structures
• PhotoTree
• FamilyTree
• Systems
• PhotoDatabase
• ImageManipulation
• Devices
• Printer
• Monitor
• Events
• Print
• Store

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
38
PhotoComposer Collected Class Candidates
Album, Background, Frame, Ceremony, Collage,
Composer, Composition, Display, Family,
Graphic, Illustration, Image, Laboratory,
InLaws, ImageManipulation, Memento, Memorial,
Monitor, PhotoDatabase, Photograph, PhotoTree,
Position, Portrait, Presenter, Print, Record,
ScrollBar, Souvenir, User, Visualization

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
39
Filters for Paring Domain Class Candidates

• Rumbaugh et al
• Stay in domain
• Needed?
• Several attributes?
• Several operations?
• Several instances?
• Standard entity?
• Clear?

• Coad and Yourdon
• Redundant?
• Should be attribute?
• Should be operation?
• Should be left for design phase?

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
40
PhotoComposer Example Stay in Domain
Album, Background, Frame, Ceremony, Collage,
Composer, Composition, Display, Family,
Graphic, Illustration, Image, Laboratory,
InLaws, ImageManipulation, Memento, Memorial,
Monitor, PhotoDatabase, Photograph, PhotoTree,
Position, Portrait, Presenter, Print,
Record, ScrollBar, Souvenir, User,
Visualization
Generic, not special to PhotoComposer.
Underlined not in domain
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
41
PhotoComposer Needed?
Album, Background, Frame, Ceremony, Collage,
Composer, Composition, Display, Family,
Graphic, Illustration, Image, Laboratory,
InLaws, ImageManipulation, Memento, Memorial,
Monitor, PhotoDatabase, Photograph, PhotoTree,
Position, Portrait, Presenter, Print, Record,
ScrollBar, Souvenir, User, Visualization
e.g., not sure applications has to distinguish
in-laws.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
42
PhotoComposition Standard Entity? .... Clear?
.... Redundant (Should be Attribute)? ....
Album, Background, Frame, Ceremony, Collage,
Composer, Composition, Display, Family,
Graphic, Illustration, Image, Laboratory,
InLaws, ImageManipulation, Memento, Memorial,
Monitor, PhotoDatabase, Photograph, PhotoTree,
(Position), Portrait, Presenter, Print,
Record, ScrollBar, Souvenir, User,
Visualization
e.g., not standard
e.g., not clear
e.g., redundant with Photograph
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
43
PhotoComposition Standard Entity? .... Clear?
.... Redundant (Should be Attribute)? ....
Album, Background, Frame, Ceremony, Collage,
Composer, Composition, Display, Family,
Graphic, Illustration, Image, Laboratory,
InLaws, ImageManipulation, Memento, Memorial,
Monitor, PhotoDatabase, Photograph, PhotoTree,
(Position), Portrait, Presenter, Print,
Record, ScrollBar, Souvenir, User,
Visualization
e.g., not standard
e.g., not clear
e.g., redundant with Photograph
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
44
PhotoComposition Domain Classes
Composition
Photograph
Frame
Portrait

Data Dictionary Composition a collection of
photographs whose rendering (e.g. on the monitor)
takes place in a specific order Frame design
for the framing of Composition objects Photograph
a digitized photograph Portrait a photograph
having foreground and background
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
45
OOAD Roadmap Version 3
OOAD Roadmap Parts Discussed in This Section
I. Requirements analysis phase
Develop use cases with customer
Convert use cases to sequence diagrams
Seek domain classes from other sources
Gather domain classes
II. Architecture phase
Consider Framework (existing, modified, or new)
Determine architecture
III. Detailed Design phase
Introduce design patterns or components
Finalize design (class model, use case model, .)
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
46
Candidate Classes for Encounter Game
EncounterAreaConnection
ConnectionHyperlink
PlayerCharacter
EncounterCharacter
EngagementDisplay
EncounterArea
ForeignCharacter
Engagement
(1) list every reasonable candidate class you can
think of (this list), then (2) drastically cut
down to a few essential classes.
Above classes From sequence diagrams, do not cut
PlayerWindow
ExitChoiceWindow
Passageway
Encounter
Quality
Room
Rule
Result
Game
Door
Score
Map
Exit
Combat
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
47
Filtering Candidate Domain Classes 1

• Encounter  Change to EncounterGame to make its
  purpose clearer
• Game Not a domain class -- too general
• GameCharacter too general to be within the
  domain
• Player PlayerCharacter is more specific to the
  domain, and should replace it
• ForeignCharacter OK
• act differently from the player character

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
48
Filtering Candidate Domain Classes 2

• Quality OMIT -- try to handle as simple
  attribute of GameCharacter
• Room OMIT -- not sure if we need this already
  have Area
• Door OMIT -- not sure well need it -- see Exit
• Exit Not sure if we need this leads to
  neighboring area -- try as simple attribute of
  Area -- OMIT for now
• Rule OMIT -- not sure well need it
• EncounterArea OK

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
49
Filtering Candidate Domain Classes 3

• Engagement OK
• Passageway Use EncounterAreaConnection
• Result OMIT -- vague
• Combat OMIT -- not sure well need it -- already
  have Engagement
• Score OMIT -- try as attribute of other classes
• PlayerQualityWindow needed for Initialize u. c.
• ExitChoiceWindow OMIT -- not needed
• Map OMIT -- not required yet
• EngagementDisplay OK -- needed by use case

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
50
Domain Classes for Encounter Video Game, Showing
Inheritance
EncounterAreaConnection
ConnectionHyperlink
Engagement
EncounterArea
EncounterCharacter
PlayerQualityWindow singleton
PlayerCharacter singleton
ForeignCharacter
EncounterGame singleton
EngagementDisplay
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
51
Key Concept ? Domain Classes are found from ?
sequence diagrams and brainstorming / editing.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
52
Design Goal At Work ? Correctness/Modularity ?
We want to easily match requirements with classes.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
53
Contents of Each Requirements Paragraph
Section Heading (e.g., Customers) Subsection 1.
Attributes (required properties) e.g., The
application shall maintain the names of all
customers. Subsection 2. Instances (specific
ones that must exist if applicable) e.g.,
The application shall accommodate John D.
Rockefeller Subsection 3. Functionality (the
heart of the requirements spec.) e.g., The
application shall be able to print customer
profiles Subsection 4. Events (events that
instances are sensitive to if any) e.g.,
Whenever a customers address is changed,
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
54
Key Concept ? Practical Requirements
Organization ?
-- can be achieved by determining domain classes
up front, then using them to organize
requirements.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
55
Summary of This Chapter

• OO Analysis Requirements analysis
  Domain class selection
• Product Complete requirements document
  Domain class model Basic sequence
  diagrams
• OO Design All other activities except coding
• Product Complete detailed design ready for
  coding
• Traditional application development
  Function-oriented
• OO analysis design Ingredients-oriented
• Domain classes Ingredients
• Obtained via use cases ? sequence diagrams, and
• Brainstorming / Editing process
• Use domain classes to organize requirements

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.