Chapter 13 Requirements and Domain Classes

1. Chapter 13Requirements and Domain Classes

2. Process Phases Discussed in This Chapter Requirements Analysis Design Framework Architecture Detailed Design Implementation Key: = main emphasis = secondary 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 application’s 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 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.

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

9. Module 1 Module 2 Module 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.

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 OOA&D Approach • State the main use cases • Convert the use cases to sequence diagrams • 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. 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×) Analysis Design 1/2 After Jacobson et al: USDP Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

14. 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 Design 2/2 After Jacobson et al: USDP Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

15. OOA&D 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 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.

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

21. OOA&D 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 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. 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 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. 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 player’s 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 :Encounter Game freddie: Foreign Character :Engagement :Engagement Display :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. OOA&D Roadmap Version 2 OOA&D 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 EncounterCharacter Area EncounterAreaConnection Engagement GameCharacter EngagementDisplay Player ConnectionHyperlink ForeignCharacter Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

32. OOA&D Roadmap Version 3 OOA&D 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 usedto 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. Extract nouns from text Booch: Discovery Invention Coad & Yourdon: Structures Systems Devices Events Roles Sites Organizational units Ideas for Brainstorming Domain Classes 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 Structures • PhotoTree • FamilyTree Systems • PhotoDatabase • ImageManipulation Devices • Printer • Monitor Events • Print • Store • Sites • Monitor • Laboratory • Organizational units • Family • InLaws Roles • Composer • Presenter • User 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. 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? Filters for Paring Domain Class Candidates 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 Frame Composition Photograph 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. OOA&D Roadmap Version 3 OOA&D 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 EncounterCharacter EngagementDisplay PlayerCharacter Engagement EncounterArea ForeignCharacter (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 Passageway ExitChoiceWindow PlayerWindow Result Room Rule Quality Encounter Door Exit Score Game Combat Map 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 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.

49. Filtering Candidate Domain Classes 3 • 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 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 ConnectionHyperlink EncounterAreaConnection 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.