lecture # 8 requirements and domain classes

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

Upload: siusan

Post on 23-Feb-2016

48 views

Category:

Documents


0 download

DESCRIPTION

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. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Lecture # 8 Requirements and Domain  Classes

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

Obj

ectiv

esLecture # 8

Requirements and Domain Classes

SWE 316: Software Design and Architecture

Finding Domain Classes From Other Sources

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

Ch 13

Page 2: Lecture # 8 Requirements and Domain  Classes

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

Finding Classes from Other Sources

Introduction

Brainstorming

Cut down to few classes Filtering Using Domain

Classes 2/22

Page 3: Lecture # 8 Requirements and Domain  Classes

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

Finding Domain Classes From Other Sources1- 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

Introduction

Brainstorming

Cut down to few classes Filtering Using Domain

Classes 3/22

Page 4: Lecture # 8 Requirements and Domain  Classes

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

M

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

Introduction

Brainstorming

Cut down to few classes Filtering Using Domain

Classes 4/22

Page 5: Lecture # 8 Requirements and Domain  Classes

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

Ideas for Brainstorming Domain ClassesExtract

nouns from text

Booch:Discovery Invention

Coad & Yourdon:StructuresSystemsDevicesEventsRolesSitesOrganizational

units

Introduction

Brainstorming

Cut down to few classes Filtering Using Domain

Classes 5/22

Page 6: Lecture # 8 Requirements and Domain  Classes

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

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

Introduction

Brainstorming

Cut down to few classes Filtering Using Domain

Classes 6/22

Page 7: Lecture # 8 Requirements and Domain  Classes

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

PhotoComposer: Brainstorming IIStructures

PhotoTree FamilyTree

Systems PhotoDatabase ImageManipulation

Devices Printer Monitor

Events Print Store

Sites Monitor Laboratory

Organizational units Family InLaws

Roles Composer Presenter User

Introduction

Brainstorming

Cut down to few classes Filtering Using Domain

Classes 7/22

Page 8: Lecture # 8 Requirements and Domain  Classes

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

PhotoComposer: Collected Class CandidatesAlbum, 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

Introduction

Brainstorming

Cut down to few classes Filtering Using Domain

Classes 8/22

Page 9: Lecture # 8 Requirements and Domain  Classes

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

Filters for Paring Domain Class CandidatesRumbaugh 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?

Introduction

Brainstorming

Cut down to few classes Filtering Using Domain

Classes 9/22

Page 10: Lecture # 8 Requirements and Domain  Classes

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

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.

Introduction

Brainstorming

Cut down to few classes Filtering Using Domain

Classes 10/22

Page 11: Lecture # 8 Requirements and Domain  Classes

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

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.

Introduction

Brainstorming

Cut down to few classes Filtering Using Domain

Classes 11/22

Page 12: Lecture # 8 Requirements and Domain  Classes

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

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 clear

e.g., redundant with Photograph

e.g., not standard

Introduction

Brainstorming

Cut down to few classes Filtering Using Domain

Classes 12/22

Page 13: Lecture # 8 Requirements and Domain  Classes

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

Composition PhotographFrame Portrait

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

Introduction

Brainstorming

Cut down to few classes Filtering Using Domain

Classes 13/22

Page 14: Lecture # 8 Requirements and Domain  Classes

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

(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

QualityRoomDoor

Rule

Engagement

ResultScore

ExitChoiceWindow

Map

Passageway

EncounterAreaConnection

EngagementDisplay

ConnectionHyperlink

Above classes: From sequence diagrams, do not cut

Exit Combat

Introduction

Brainstorming

Cut down to few classes Filtering Using Domain

Classes 14/22

Page 15: Lecture # 8 Requirements and Domain  Classes

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

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

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes 15/22

Page 16: Lecture # 8 Requirements and Domain  Classes

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

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

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes 16/22

Page 17: Lecture # 8 Requirements and Domain  Classes

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

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

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes 17/22

Page 18: Lecture # 8 Requirements and Domain  Classes

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

Domain Classes for Encounter Video Game, Showing Inheritance

EncounterArea

EncounterGame«singleton»

Engagement

PlayerCharacter«singleton»

ForeignCharacter

EncounterCharacterPlayerQualityWindow

«singleton»

EngagementDisplay

EncounterAreaConnectionConnectionHyperlink

Introduction

Brainstorming

Cut down to few classes

Filtering

Using Domain Classes 18/22

Page 19: Lecture # 8 Requirements and Domain  Classes

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

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

Introduction

Brainstorming

Cut down to few classes Filtering Using Domain

Classes19/22

Page 20: Lecture # 8 Requirements and Domain  Classes

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

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, …”

Introduction

Brainstorming

Cut down to few classes Filtering Using Domain

Classes20/22

Page 21: Lecture # 8 Requirements and Domain  Classes

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

Summary of This ChapterOO analysis & design: “Ingredients-

oriented”

Domain classes = “Ingredients” Obtained via use cases sequence diagrams,

and Brainstorming / Editing process

Use domain classes to organize requirements

Introduction

Brainstorming

Cut down to few classes Filtering Using Domain

Classes 21/22

Page 22: Lecture # 8 Requirements and Domain  Classes

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

Summary of This ChapterDomain 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.

Introduction

Brainstorming

Cut down to few classes Filtering Using Domain

Classes 22/22