Chapter 13 Requirements and Domain Classes

Chapter 13 Requirements and Domain Classes

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

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.

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.

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.

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.

Non-OO Design of WinHelp
Get description Report problem description solution Solution database Match solution key: = data flow XXX = functional component 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 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 Require-ment 1783 showName() computeBalance() getInterest() 1784 showAccount() showBalance() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Disadvantages of Functional Methods
1.2 Contrasting OO and Traditional Methods Disadvantages of Functional Methods As the large number of over-budget, late, and outright disastrous application developments has shown, traditional methods are not adequate for the scope of contemporary applications. There are several reasons for this. Because of the sheer complexity of the system design task, we seldom know completely what must be build before beginning to design and build it: in practice, our conception becomes increasingly concrete while we analyze, design and implement. Functional methods, however, do not support this iterative, dynamic process. They tend to assume that we understand the entire application before we begin to build it. Due to the hierarchical nature of functional methods, and their relative rigidity, it has proven expensive to add or remove functionality. This is because non-OO designs are made with particular functionality strongly in mind, and so changes frequently impact many parts of the design in complex ways. Suppose, for example, we added the requirement that WinHelp “list the most common WindowsTM problems.” The existing design is set up to support quite different functionality, so this new requirement could be expensive to implement. Another deficiency of most non-OO methods is the difficulty of matching the code with the application: in particular, it is generally difficult to associate each application requirements with the code that implements it. In a traditional implementation of WinHelp, for example, it is typically difficult to locate the code associated with “Windows problem”: such code is usually present in numerous locations rather than one easily manageable place. This makes the design hard to understand, build, change and maintain. Because of these factors, software is too seldom re-used on more than one application. Textbook reading: Rumbaugh discusses traditional development methodologies and compares them with the OO process as described by OMT. 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.

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.

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.

2. Applicable to several designs
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.

7. Emerges from conceptual thinking 8. Few layers
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.

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.

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

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

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.

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.

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 dressing room: Area 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.

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.

Sequence Diagram for Travel 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 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.

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

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

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.

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

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.

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 PhotoComposer: Brainstorming II 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 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.

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.

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.

PhotoComposition: Standard Entity. Clear
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.

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.

Candidate Classes for Encounter Game
ConnectionHyperlink EncounterAreaConnection PlayerCharacter EncounterCharacter EngagementDisplay 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 Score Door Exit Combat Map Game Adapted 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 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 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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.

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

Chapter 13 Requirements and Domain Classes

Similar presentations

Presentation on theme: "Chapter 13 Requirements and Domain Classes"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Chapter 13 Requirements and Domain Classes

Similar presentations

Presentation on theme: "Chapter 13 Requirements and Domain Classes"— Presentation transcript:

Similar presentations

About project

Feedback