Chapter 13 Requirements and Domain Classes Requirements Analysis

Chapter 13 Requirements and Domain Classes

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

Learnin g Goals for This Chapter Understand distinctions: q OO analysis vs. design q Traditional application development vs. OO analysis & design Domain vs. non-domain Be able to … classes q q … determine basic Use Cases q … create sequence diagrams q … select domain classes 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 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Characteristics of OO Analysis & Design q 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 q Introduces domain classes at requirements time Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Win. Help Example: Requirements Win. Help 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 Win. Help Get description Report problem description solution Match key: Solution databas e solution = data flow XXX = functional Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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

Requirements Traceability Matrix Module 1 Module 2 Module 3 1783 show. Name() compute. Balanc e() get. Interest() 1784 show. Account() compute. Balanc e() show. Balance( ) Requirement 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 refine select 2. Convert the use cases to sequence diagrams 3. Select the resulting (“domain”) classes 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.

Design Analysis 1/2 After Jacobson et al: USDP 1. Conceptual & abstract 1. Concrete: implementation blueprint 2. Applicable to several designs 2. Specific for an implementation 3. «control» , «entity» & «boundary» stereotypes 3. No limit on class stereotypes 4. Less formal 5. More expensive to 5. Less expensive to 4. More formal develop ( 5×) Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Analysis Design 6. Outlines the design 6. Manifests the design 7. Emerges from conceptual thinking 7. May use tools (e. g. visual, round-trip engineering) 8. Few layers 9. Relatively unconstrained 2/2 After Jacobson et al: USDP 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.

OOA&D Roadmap (to be explained) Develop use cases with customer I. Requirements analysis. Convert use cases to sequence diagrams phase Seek domain classes from other sources Gather domain classes Use to classify requirement II. Architecture phase Determine architecture Consider Framework (existing, modified, or new) III. Detailed Design phase Introduce design Finalize design patterns (class model, use case model, …. ) or components. 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) q Role-playing game which simulates all or part of the lifetime of the player's character. q Game characters not under the player’s control called "foreign" characters. q Game characters have a number of qualities such as strength, speed, patience etc. q q 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) q The result of an engagement depends on the area in which it takes place, and on the values of the characters’ relevant qualities q Players may reallocate the values of their qualities when the foreign character is absent q Reallocation q Success takes effect after a delay is measured by life points Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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.

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.

OOA&D Roadmap: Parts Discussed in This Section Develop use cases with customer I. Requirements analysis Convert use cases to sequence diagrams phase 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.

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

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

Travel To Adjacent Area Use Case Encounter Travel to Adjacent Area Initialize player Travel to adjacent area Engage foreign character designe r 1. Player hits hyperlink connecting displayed area to adjacent area. 2. Application displays the indicated adjacent area, including the player’s character. Set rules 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.

Sequence Diagram for Initialize Use Case : Encounter Game main player character: Player Character : Player quality window 1*. 1 create and display dressin g room: Area 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.

Sequence Diagram for Engage Foreign Character Use Case : Encounte r Game freddie: Foreign Character : Engagement : Engagemen t 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.

User : Connectio n Hyperlink : Area. Connecti on : Player. Character : Area 1. 1 hit 1. 2 display other area 2. 1 display Sequence Diagram for Travel to Adjacent Area Use Case 2. 2 display Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

OOA&D Roadmap: Parts Discussed OOA&D Roadmapin. Version 2 This Section Develop use cases with customer I. Requirements analysis Convert use cases to sequence diagrams phase 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.

Classes in Initialize Sequence Diagram Encounter. Game - a class with a single object Player. Character - with object main. Player. Character Area - with object dressing. Room, and Player. Quality. Window - 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 Encounter. Character Area Encounter. Area. Connection Engagement Player Game. Character Engagement. Display Connection. Hyperlink Foreign. Character Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

OOA&D Roadmap: Parts Discussed OOA&D Roadmapin. Version 3 This Section Develop use cases with customer I. Requirements analysis Convert use cases to sequence diagrams phase 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.

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.

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

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

Photo. Composer: Brainstorming I Nouns from text (existing documentation) Background, Frame, Composition, Display, Family, Photograph, Portrait, Record, Scroll. Bar, 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.

Structures Sites Photo. Tree Family. Tree Monitor Laboratory Systems Photo. Database Image. Manipulatio n Devices Organizational units Family In. Laws Printer Roles Monitor Photo. Composer r: Presenter Events Brainstorming User Print II Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Photo. Composer: Collected Class Candidates Album, Background, Frame, Ceremony, Collage, Composer, Composition, Display, Family, Graphic, Illustration, Image, Laboratory, In. Laws, Image. Manipulation, Memento, Memorial, Monitor, Photo. Database, Photograph, Photo. Tree, Position, 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 Coad and Yourdon o Needed? o Redundant? o Several o Should o Several operations? be operation? o Should in domain attributes? be attribute? o Should o Stay be left for o Several instances? Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Photo. Composer Example: Stay in Domain Album, Background, Frame, Ceremony, Collage, Composer, Composition, Display, Family, Graphic, Illustration, Image, Laboratory, In. Laws, Image. Manipulation, Memento, Memorial, Monitor, Generic, not Photo. Database, Photograph, special to Photo. Tree, Position, Photo. Composer. Portrait, Presenter, Print, Record, Scroll. Bar, Souvenir, User, Visualization Underlined: “not in domain Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Photo. Composer: Needed? Album, Background, Frame, Ceremony, Collage, Composer, Composition, Display, Family, Graphic, Illustration, Image, Laboratory, In. Laws, Image. Manipulation, Memento, Memorial, Monitor, e. g. , not sure Photo. Database, Photograph, Photo. Tree, Position, applications to Portrait, Presenter, Print, Record, has Scroll. Bar, distinguish in. Souvenir, User, Visualization laws. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Photo. Composition: Standard Entity? . . Clear? Clear. . [Redundant] (Should be Attribute)? . . Album, Background, Frame, Ceremony Collage, Composer, Composition, Display, Family, Graphic, e. g. , not Illustration, [Image], e. g. , Laboratory, In. Laws, not standard clear Image. Manipulation, Memento, Memorial, Image. Manipulation Memento Monitor , Photo. Database, Photograph, Photo. Tree, e. g. , redundant with (Position), Portrait, Presenter, Print, Record, Photograph Souvenir, User, Visualization Scroll. Bar, Souvenir Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Photo. Composition: Standard Entity? . . Clear? Clear. . [Redundant] (Should be Attribute)? . . Album, Background, Frame, Ceremony Collage, Composer, Composition, Display, Family, Graphic, e. g. , not Illustration, [Image], e. g. , Laboratory, In. Laws, not standard clear Image. Manipulation, Memento, Memorial, Image. Manipulation Memento Monitor , Photo. Database, Photograph, Photo. Tree, e. g. , redundant with (Position), Portrait, Presenter, Print, Record, Photograph Souvenir, User, Visualization Scroll. Bar, Souvenir Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Photo. Composition 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.

OOA&D Roadmap: Parts Discussed OOA&D Roadmapin. Version 3 This Section Develop use cases with customer I. Requirements analysis Convert use cases to sequence diagrams phase 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.

Candidate Classes for Encounter Game Encounter. Area. Connection. Hyperlink Encounter. Character Engagement. Display Player. Character Engagement Encounter. Area Foreign. Character (1) list every reasonable candidate class you can think of (this list), then Above classes: From sequence diagrams, do not cut (2) drastically cut down to a few essential classes. Passageway Result Score Exit. Choice. Window Room Door Rule Exit Player. Window Quality Combat Map Encounter Game 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 Encounter. Game to make its purpose clearer o Game: Not a domain class -- too general o Game. Character: too general to be within the domain o Player: Player. Character is more specific to the domain, and should replace it o Foreign. Character: 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 Game. Character · 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 · Encounter. Area: OK Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Filtering Candidate Domain Classes 3 · · · · · Engagement: OK Passageway: Use Encounter. Area. Connection Result: OMIT -- vague Combat: OMIT -- not sure we’ll need it -already have Engagement Score: OMIT -- try as attribute of other classes Player. Quality. Window: needed for Initialize u. c. Exit. Choice. Window: OMIT -- not needed Map: OMIT -- not required yet Engagement. Display: OK -- needed by use Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

ain Classes for Encounter Video Game, Showing Inherit Connection. Hyperlink Encounter. Area. Connection Engagement Encounter. Area Encounter. Character Player. Quality. Window «singleton» Player. Character Foreign. Character «singleton» Engagement. Display Encounter. Game «singleton» 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.

Contents of Each Section Heading (e. g. , “Customers”) Requirements Paragraph 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 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

ey 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.

Summar q OO Analysis = Requirements analysis + y of This Domain class selection Chapter o Product = Complete requirements document + Domain class model + Basic sequence diagrams q OO Design = All other activities except coding o Product = Complete detailed design ready for coding q Traditional application development: Function -oriented q OO analysis & design: “Ingredients-oriented” q Domain classes = “Ingredients” o Obtained via use cases sequence diagrams, and Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.