Chapter 13 Requirements and Domain Classes

Process Phases Discussed in This Chapter Requirements Analysis Design Implementation ArchitectureFrameworkDetailed Design x Key:= secondary emphasis x = main emphasis Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Learning Goals for This Chapter  OO a nalysis vs. d esign  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: Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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 design Adapted 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 time o 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.

WinHelp Example: Requirements WinHelp shall advise novice Windows TM 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 solutions Adapted 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 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Non -OO Design of WinHelp: Top-Down Organization Control Get descriptionMatchReport Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Module 1Module 2Module 3 Require- ment 1783 showName()computeBalance()getInterest() 1784 showAccount()computeBalance()showBalance() Requirements Traceability Matrix Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Disadvantages of Functional Methods o Whole application must be specified first - to do top-down design o Usage hard to change o Code does not match the application well o Traceability difficult o Re-use low Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

The Basic OOA&D Approach 1.State the main use cases 2.Convert the use cases to sequence diagrams 3.Select the resulting (“domain”) classes refine select Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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.

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 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Seek domain classes from other sourcesGather domain classes Develop use cases with customer Convert use cases to sequence diagrams Introduce design patterns or 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 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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.

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. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Encounter Area Configuration Dressing room Courtyard DungeonStudy Key:= connection Living room Kitchen Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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.

Seek domain classes from other sourcesGather domain classes Develop use cases with customer Convert use cases to sequence diagrams Introduce design patterns or 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: Parts Discussed in This Section Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Initialize Use Case for Encounter Case Study Engage foreign character player designer Set rules actors Travel to adjacent 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 titlesUse case detail Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Engage Foreign Character Use Case player designer Initialize Encounter Travel to adjacent area 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. Engage foreign character Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Travel To Adjacent Area Use Case player designer Initialize Encounter Travel to adjacent area 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 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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.

Player :Encounter- Game main player character: Player Character 1*.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 quality window dressing room: Area 4. select exit for character 3.1 set quality values Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

1.1 create; display Sequence Diagram for Engage Foreign Character Use Case 2.1 execute 3 create and show :Engagement Display :Engagement 2.2 change quality values 1.2 create :Player Character :Encounter Game 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 for Travel to Adjacent Area Use Case Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Seek domain classes from other sourcesGather domain classes Develop use cases with customer Convert use cases to sequence diagrams Introduce design patterns or 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 Version 2 OOA&D Roadmap: Parts Discussed in This Section Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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.

Harvesting Classes From the Sequence Diagrams Area PlayerForeignCharacter EncounterCharacter GameCharacterEngagement EncounterAreaConnection EngagementDisplay ConnectionHyperlink Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Seek domain classes from other sourcesGather domain classes Develop use cases with customer Convert use cases to sequence diagrams Introduce design patterns or 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 Version 3 OOA&D Roadmap: Parts Discussed in This Section Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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.

Ideas for Brainstorming Domain Classes  Extract nouns from text Booch:  Discovery  Invention Coad & Yourdon:  Structures  Systems  Devices  Events  Roles  Sites  Organizational units Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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.) Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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.

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.

Filters for Paring Domain Class Candidates Rumbaugh et al o Stay in domain o Needed? o Several attributes ? o Several operations ? o Several instances ? o Standard entity? o Clear? Coad and Yourdon o Redundant? o Should be attribute ? o Should be operation ? o Should be left for design phase? Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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.

Clear PhotoComposition: Standard Entity?.... Clear ?.... [ Redundant] ( Should be Attribute) ?.... Ceremony ImageManipulationMementoMemorial PhotoTree, SouvenirVisualization 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 clear e.g., redundant with Photograph e.g., not standard Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Clear PhotoComposition: Standard Entity?.... Clear ?.... [ Redundant] ( Should be Attribute) ?.... Ceremony ImageManipulationMementoMemorial PhotoTree, SouvenirVisualization 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 clear e.g., redundant with Photograph e.g., not standard Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

CompositionPhotographFramePortrait 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 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Seek domain classes from other sourcesGather domain classes Develop use cases with customer Convert use cases to sequence diagrams Introduce design patterns or 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 Version 3 OOA&D Roadmap: Parts Discussed in This Section Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

(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 Combat Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Filtering Candidate Domain Classes 1 o Encounter : Change to EncounterGame to make its purpose clearer o Game : Not a domain class -- too general o GameCharacter : too general to be within the domain o Player : PlayerCharacter is more specific to the domain, and should replace it o ForeignCharacter : OK  act differently from the player character Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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 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 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

 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 Filtering Candidate Domain Classes 3 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Domain Classes for Encounter Video Game, Showing Inheritance EncounterArea EncounterGame «singleton» Engagement PlayerCharacter «singleton» ForeignCharacter EncounterCharacter PlayerQualityWindow «singleton» EngagementDisplay EncounterAreaConnectionConnectionHyperlink Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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.

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.

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 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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.

Summary of This Chapter  OO Analysis = Requirements analysis + Domain class selection o Product = Complete requirements document + Domain class model + Basic sequence diagrams  OO Design = All other activities except coding o 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 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.