chapter 13 requirements and domain classes. process phases discussed in this chapter requirements...

Chapter 13Requirements and Domain Classes

Process Phases Discussed in This ChapterRequirementsAnalysis

Design

Implementation

ArchitectureFramework Detailed Design

xKey: = secondary emphasisx = main emphasis

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

Learning Goals for This Chapter

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 …

Understand distinctions:


The Activities of Application Development

1. Gather requirements

Specify Customer-oriented requirements specs

Specify Developer-oriented requirement specs

2. Create design

Select architecture

Specify detailed design

3. Implement designAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Characteristics of OO Analysis & Design

Approach is initially through the application’s domain classes (its “ingredients”)

-- rather than its required functionality

o Like starting a recipe by listing the ingredients

o Typically obtain from introducing use cases then transforming these into sequence diagrams

Introduces domain classes at requirements timeo Remaining classes at design time

Supports iterative development processes


WinHelp Example: Requirements

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

Input: Problem description

Process: Determine user’s difficulty

match with solution database

Output: Up to 3 possible solutionsAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Non-OO Design of WinHelp

key: = data flow

Get description

Match

Report

Solution database

XXX = functional component

problem description

solution

solution


Non-OO Design of WinHelp: Top-Down Organization

Control

Get descriptionMatch Report


Module 1 Module 2 Module 3

Require-ment

1783 showName() computeBalance() getInterest()

1784 showAccount() computeBalance() showBalance()

Requirements Traceability Matrix


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


The Basic OOA&D Approach

1. State the main use cases

2. Convert the use cases to

sequence diagrams

3. Select the resulting

(“domain”) classesrefine

select


Design Goal At Work: Reusability

Because we want to reuse classes, we identify domain classes early in the process.


Analysis

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×)

After Jacobson et al: USDP

Design 1/2


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

Analysis After Jacobson et al: USDP

Design 2/2


Seek domain classes from other sources Gather domain classes

Develop use cases with customer

Convert use cases to sequence diagrams

Introduce design patternsor components

Finalize design(class model, use case model, ….)

I. Requirements analysis phase

II. Architecture phase

III. Detailed Design phase

Determine architecture Consider Framework(existing, modified, or new)

OOA&D Roadmap(to be explained)

Use to classify requirements


Key Concept: The Object-Oriented Approach …

… is to begin with ingredients rather than functionality.


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 player’s 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.

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.


Encounter Area Configuration

Dressingroom

Courtyard

Dungeon Study

Key: = connection

Livingroom

Kitchen


Foreign Character Freddie’s Image

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










OOA&D Roadmap: Parts Discussed in This Section


Initialize Use Case for Encounter Case Study

Engageforeign

character

player

designer Set rules

actors

Travel toadjacent area

Initialize

1. Application displays player’s 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.

Initialize

Use case titles Use case detail


Engage Foreign Character Use Case

player

designer

Initialize

Encounter


Set rules

Engage Foreign Character

1. Application displays the foreign character in the same area as the player’s.2. Application exchanges quality values between the two characters.3. Application displays the results of the engagement. 4. Application displays player’s character in a random area.

Engageforeign

character


Travel To Adjacent Area Use Case

player

designer

Initialize

Encounter


Set rules

Travel to Adjacent Area

1. Player hits hyperlink connecting displayed area to adjacent area.2. Application displays the indicated adjacent area, including the player’s character.Engage

foreign character


Key Concept: Use Cases …

… are a beginning point for requirements and analysis.


Player

:Encounter-Game

main playercharacter:

Player Character1*.1 create and display

5. move

Sequence Diagram for Initialize Use Case

* Numbering keyed to use case

1.2 create and display

2. create and display

3.2 set quality values

:Player qualitywindow

dressing room:

Area

4. select exit for character

3.1 set quality values


1.1 create; display

Sequence Diagram for Engage Foreign Character Use Case

2.1 execute

3 create and show

:EngagementDisplay

:Engagement

2.2 change quality values

1.2 create

:Player Character

:EncounterGame

freddie: Foreign

Character

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

User:Connection

Hyperlink

1.1 hit

1.2 display other area

:AreaConnection

:Area

2.1 display

2.2 display

:PlayerCharacter

Sequence Diagram forTravel to Adjacent Area Use Case











OOA&D Roadmap Version 2OOA&D Roadmap: Parts Discussed in This Section


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.


Harvesting Classes From the Sequence Diagrams

Area

Player ForeignCharacter

EncounterCharacter

GameCharacterEngagement

EncounterAreaConnection

EngagementDisplay

ConnectionHyperlink


Finding Domain Classes From Other Sources

(1) 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.


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


Ideas for Brainstorming Domain Classes

Extract nouns from text

Booch: Discovery Invention

Coad & Yourdon: Structures Systems Devices Events Roles Sites Organizational units


PhotoComposer: Brainstorming I

Nouns from text (existing documentation)

Background, Frame, Composition, Display, Family, Photograph, Portrait, Record, ScrollBar, User

Album, Ceremony, Collage, Graphic, Illustration, Memento, Memorial, Souvenir, Visualization

Invention (generalization etc.)


PhotoComposer: Brainstorming II

SitesMonitor

Laboratory

Organizational unitsFamily

InLaws

RolesComposer

Presenter

User

StructuresPhotoTree

FamilyTree

SystemsPhotoDatabase

ImageManipulation

DevicesPrinter

Monitor

EventsPrint

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

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


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?


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

Underlined: “not in domain”

Generic, not special to PhotoComposer.


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.


PhotoComposition: Standard Entity? .... ClearClear? .... [Redundant]

(Should be Attribute)? ....

Album, Background, Frame, CeremonyCeremony, Collage,

Composer, Composition, Display, Family, Graphic, Illustration, [Image], Laboratory, InLaws,

ImageManipulationImageManipulation, MementoMemento, MemorialMemorial, Monitor, PhotoDatabase, Photograph, PhotoTree, PhotoTree,

(Position), Portrait, Presenter, Print, Record, ScrollBar, SouvenirSouvenir, User, VisualizationVisualization

e.g., not clear

e.g., redundant with Photograph

e.g., not standard


Composition PhotographFrame Portrait

PhotoComposition Domain Classes

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


(1) list every reasonable candidate class you can think of (this list), then

(2) drastically cut down to a few essential classes.

Candidate Classes for Encounter Game

EncounterArea

Encounter

PlayerCharacter

ForeignCharacter

PlayerWindow

Game

EncounterCharacter

QualityRoom

Door

Rule

Engagement

Result

Score

ExitChoiceWindow

Map

Passageway

EncounterAreaConnection

EngagementDisplay

ConnectionHyperlink

Above classes: From sequence diagrams, do not cut

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

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.


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 we’ll 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 we’ll need it EncounterArea: OK


Engagement: OK Passageway: Use EncounterAreaConnection Result: OMIT -- vague Combat: OMIT -- not sure we’ll 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



Domain Classes for Encounter Video Game, Showing Inheritance

EncounterArea

EncounterGame«singleton»

Engagement

PlayerCharacter«singleton»

ForeignCharacter

EncounterCharacterPlayerQualityWindow

«singleton»

EngagementDisplay

EncounterAreaConnectionConnectionHyperlink


Key Concept: Domain Classes are found from …

… sequence diagrams and brainstorming / editing.


Design Goal At Work: Correctness/Modularity

We want to easily match requirements with classes.


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 customer’s address is changed, …”

Contents of Each Requirements

Paragraph


Key Concept: Practical Requirements Organization

-- can be achieved by determining domain classes up front, then using them to organize requirements.


Summary of This

Chapter

OO Analysis = Requirements analysis + Domain

class selectiono Product = Complete requirements document + Domain class

model + Basic sequence diagrams

OO Design = All other activities except codingo Product = Complete detailed design ready for coding

Traditional application development: Function-oriented

OO analysis & design: “Ingredients-oriented”

Domain classes = “Ingredients”o Obtained via use cases sequence diagrams, and

o Brainstorming / Editing process

Use domain classes to organize requirements


chapter 13 requirements and domain classes. process phases discussed in this chapter requirements...

Documents

software design

braude wiley

design goal

nondomain classes

nonoo design of winhelpkey

applications domain

basic use cases

domain classesprocess