swe 316 software design and architecture n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Lecture # 8 Requirements and Domain Classes PowerPoint Presentation
Download Presentation
Lecture # 8 Requirements and Domain Classes

Loading in 2 Seconds...

play fullscreen
1 / 22

Lecture # 8 Requirements and Domain Classes - PowerPoint PPT Presentation


  • 92 Views
  • Uploaded on

SWE 316: Software Design and Architecture. Lecture # 8 Requirements and Domain Classes . Ch 13. Finding Domain Classes From Other Sources. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission. 2/22. Introduction. Brainstorming.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Lecture # 8 Requirements and Domain Classes' - siusan


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
swe 316 software design and architecture
SWE 316: Software Design and Architecture

Lecture # 8Requirements and Domain Classes

Ch 13

  • Finding Domain Classes From Other Sources

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

finding classes from other sources

2/22

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes

Finding Classes from Other Sources
finding domain classes from other sources

3/22

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes

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.

13.3.4

photocomposer

4/22

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes

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

M

ideas for brainstorming domain classes

5/22

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes

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

6/22

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes

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

photocomposer brainstorming ii

7/22

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes

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 collected class candidates

8/22

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes

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

9/22

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes

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

10/22

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes

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”

photocomposer needed

11/22

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes

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 redundant

12/22

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes

PhotoComposition: Redundant?
  • 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

slide13

13/22

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes

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

candidate classes for encounter game

14/22

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes

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

filtering candidate domain classes 1

15/22

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes

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
filtering candidate domain classes 2

16/22

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes

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
filtering candidate domain classes 3

17/22

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes

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
domain classes for encounter video game showing inheritance

18/22

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes

Domain Classes for Encounter Video Game, Showing Inheritance

ConnectionHyperlink

EncounterAreaConnection

Engagement

EncounterArea

EncounterCharacter

PlayerQualityWindow

«singleton»

PlayerCharacter

«singleton»

ForeignCharacter

EncounterGame

«singleton»

EngagementDisplay

using domain classes

19/22

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes

Using domain classes
  • to organize requirements. How?
  • Key advantage of OO is the fact that the implementation maps well to the real world
  • E.g., list all requirements that belong to “Customer” class under a section called “Customer” in the requirements document
contents of each requirements paragraph

20/22

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes

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, …”
summary of this chapter

21/22

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes

Summary of This Chapter
  • 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 chapter1

22/22

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes

Summary of This Chapter
  • Domain Classes are found from
    • sequence diagrams, and
    • brainstorming / editing.
    • Correctness/Modularity We want to easily match requirements with classes.
  • Practical Requirements Organization-- can be achieved by determining domain classes up front, then using them to organize requirements.