Unit 4 Analysis Model

SoftwareEngineering:APractitionersApproach, 6/e
Chapter8 AnalysisModeling
copyright 1996, 2001, 2005
R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.
ThesecoursewarematerialsaretobeusedinconjunctionwithSoftwareEngineering:APractitionersApproach,6/eand areprovidedwithpermissionbyR.S.Pressman&Associates,Inc.,copyright1996,2001,2005
RequirementsAnalysis
Requirementsanalysis

Requirementsanalysisallowsthesoftwareengineer (calledananalystormodelerinthisrole)to:

specifiessoftwaresoperationalcharacteristics indicatessoftware'sinterfacewithothersystemelements establishesconstraintsthatsoftwaremustmeet
elaborateonbasicrequirementsestablishedduringearlier requirementengineeringtasks buildmodelsthatdepictuserscenarios,functionalactivities, problemclassesandtheirrelationships,systemandclass behavior,andtheflowofdataasitistransformed.

2
ABridge
system descriptio n
analysis mo del design mo del
RulesofThumb

Themodelshouldfocusonrequirementsthatarevisiblewithinthe problemorbusinessdomain.Thelevelofabstractionshouldbe relativelyhigh. Eachelementoftheanalysismodelshouldaddtoanoverall understandingofsoftwarerequirementsandprovideinsightinto theinformationdomain,functionandbehaviorofthesystem. Delayconsiderationofinfrastructureandothernonfunctional modelsuntildesign. Minimizecouplingthroughoutthesystem. Becertainthattheanalysismodelprovidesvaluetoall stakeholders. Keepthemodelassimpleasitcanbe.
DomainAnalysis
Softwaredomainanalysisistheidentification,analysis, andspecificationofcommonrequirementsfroma specificapplicationdomain,typicallyforreuseon multipleprojectswithinthatapplicationdomain... [Objectorienteddomainanalysisis]theidentification, analysis,andspecificationofcommon,reusable capabilitieswithinaspecificapplicationdomain,in termsofcommonobjects,classes,subassemblies,and frameworks...
Donald Firesmith
DomainAnalysis

Definethedomaintobeinvestigated. Collectarepresentativesampleofapplicationsin thedomain. Analyzeeachapplicationinthesample. Developananalysismodelfortheobjects.
DataModeling
examinesdataobjectsindependentlyof processing focusesattentiononthedatadomain createsamodelatthecustomerslevelof abstraction indicateshowdataobjectsrelatetoone another
WhatisaDataObject?
Object somethingthatisdescribedbyaset ofattributes(dataitems)andthatwillbe manipulatedwithinthesoftware(system) each instance ofanobject(e.g.,abook) canbeidentifieduniquely(e.g.,ISBN#) eachplaysanecessaryroleinthesystem i.e.,thesystemcouldnotfunctionwithout accesstoinstancesoftheobject eachisdescribedbyattributesthatare themselvesdataitems
TypicalObjects
externalentities(printer,user,sensor) things (e.g,reports,displays,signals) occurrencesorevents(e.g.,interrupt,alarm) roles (e.g.,manager,engineer,salesperson) (e.g.,division,team) organizationalunits places (e.g.,manufacturingfloor) structures(e.g.,employeerecord)
DataObjectsandAttributes
Adataobjectcontainsasetofattributesthat actasanaspect,quality,characteristic,or descriptoroftheobject object: automobile attributes: make model body type price options code
10
WhatisaRelationship?
relationship indicatesconnectedness; a"fact"thatmustbe"remembered" bythesystemandcannotorisnotcomputed orderivedmechanically
severalinstancesofarelationshipcan exist objectscanberelatedinmanydifferent ways
11
ERDNotation
One common form: object 1
(0, m)
relationship
(1, 1)
object 2
attribute
Another common form: object 1

relationship (0, m) (1, 1)
object 2
12
BuildinganERD
Level1modelalldataobjects(entities)andtheir connectionstooneanother Level2modelallentitiesandrelationships Level3modelallentities,relationships,andthe attributesthatprovidefurtherdepth
13
TheERD:AnExample
Customer standard task table (1,1)
selected from
(1,1)
places
(1,m)
request for service (1,1)

generates
(1,n)
work order (1,1)
work (1,w) tasks materials
(1,w) (1,i)
(1,1)
consists of lists
14
ObjectOrientedConcepts
Mustbeunderstoodtoapplyclassbased elementsoftheanalysismodel Keyconcepts:

Classesandobjects Attributesandoperations Encapsulationandinstantiation Inheritance
15
Classes
objectorientedthinkingbeginswiththe definitionofaclass,oftendefinedas:

ametaclass(alsocalledasuperclass) establishesahierarchyofclasses onceaclassofitemsisdefined,a specificinstanceoftheclasscanbe identified
template generalizeddescription blueprint...describingacollectionof similaritems
16
BuildingaClass
class name attributes: operations
attributes: operations:
17
WhatisaClass?
occurrences things external entities roles organizational units places structures
class name attributes:
operations:
18
Encapsulation/Hiding
The object encapsulates both data and the logical procedures required to method manipulate the data
#1
data
method #2 method #3
method #6
method #5
method #4
Achieves information hiding

19
ClassHierarchy
PieceOfFurniture (superclass)
Table
Chair
Desk
Chable"
subclasses of the
instances of Chair
20
Methods (a.k.a.Operations,Services)
An executable procedure that is encapsulated in a class and is designed to operate on one or more data attributes that are defined as part of the class. A method is invoked via message passing.
21
ScenarioBasedModeling
[Usecases]aresimplyanaidtodefiningwhatexists outsidethesystem(actors)andwhatshouldbe performedbythesystem(usecases).IvarJacobson
(1)Whatshouldwewriteabout? (2)Howmuchshouldwewriteaboutit? (3)Howdetailedshouldwemakeourdescription? (4)Howshouldweorganizethedescription?
22
UseCases
ascenariothatdescribesathreadofusagefor asystem actorsrepresentrolespeopleordevicesplayas thesystemfunctions userscanplayanumberofdifferentrolesfora givenscenario
23
DevelopingaUseCase

Whatarethemaintasksorfunctionsthatareperformedbythe actor? Whatsysteminformationwillthetheactoracquire,produceor change? Willtheactorhavetoinformthesystemaboutchangesinthe externalenvironment? Whatinformationdoestheactordesirefromthesystem? Doestheactorwishtobeinformedaboutunexpectedchanges?
24
UseCaseDiagram
SafeHome Access camera surveillance via the Internet cameras
Configure SafeHome system parameters homeowner
Set alarm
25
ActivityDiagram
enter pas word s and user ID
Supplementstheusecasebyprovidingadiagrammatic representationofproceduralflow
valid p sswor d ID a s/ in valid p asswor d ID s/
s elect m ajor function

ot h er f u ct ion n s may also b e select ed
prom pt for reentry
select s urveillance
in u t r ies r emain p t n in u o p t t r ies r emain
t h mb ail views u n
select a sp ecif ic camer a
s elect s pec ific cam era - thum bnails
select cam era icon
view cam era output in labelled window
prom pt for another view

exit t h f u ct ion is n
see an h ot er camer a
26
h o m e o wn e r
enter pas s word Allowsthemodelertorepresenttheflowofactivitiesdescribedbytheusecaseandatthe and us er ID sametimeindicatewhichactor(iftherearemultipleactorsinvolvedinaspecificusecase) oranalysisclasshasresponsibilityfortheactiondescribedbyanactivityrectangle

va lid p asswo r d s/ ID in valid p asswo r d s/ ID
SwimlaneDiagrams
c a m e ra
i n t e rf a c e
s elect major function

o t h er f u n ct io n s may also b e se lect ed
prompt for reentry
s elect s urveillance
n o in p u t t r ies r ema in
in p u t t r ie s r emain
t h u mb n ail vie ws
select a sp e cif ic camer a
s elect s pecific camera - thumbnails
s elect camera icon
generate video output view camera output in labelled window prompt for another view
exit t h is f u n ct io n see an o t h e r camer a
27
FlowOrientedModeling
Representshowdataobjectsaretransformedatthey movethroughthesystem Adataflowdiagram(DFD)isthediagrammaticform thatisused Consideredbymanytobeanoldschoolapproach,flow orientedmodelingcontinuestoprovideaviewofthe systemthatisuniqueitshouldbeusedtosupplement otheranalysismodelelements
28
TheFlowModel
Everycomputerbasedsystemisan informationtransform....
input
computer based system
output
29
FlowModelingNotation
external entity
process data flow data store

30
ExternalEntity
A producer or consumer of data Examples:aperson,adevice,asensor Anotherexample:computerbased system Datamustalwaysoriginatesomewhere andmustalwaysbesenttosomething
31
Process
A data transformer (changes input to output) Examples:computetaxes,determinearea, formatreport,displaygraph Datamustalwaysbeprocessedinsome waytoachievesystemfunction
32
DataFlow
Data flows through a system, beginning as input and be transformed into output.
base compute triangle area area
height
33
DataStores
Data is often stored for later use.
sensor # sensor #, type, location, age
report required
look-up sensor data

sensor number
type, location, age sensor data
34
DataFlowDiagramming: Guidelines
alliconsmustbelabeledwithmeaningful names theDFDevolvesthroughanumberof levelsofdetail alwaysbeginwithacontextleveldiagram (alsocalledlevel0) alwaysshowexternalentitiesatlevel0 alwayslabeldataflowarrows donotrepresentprocedurallogic

35
ConstructingaDFDI
reviewthedatamodeltoisolatedataobjects anduseagrammaticalparsetodetermine operations determineexternalentities(producersand consumersofdata) createalevel0DFD
36
Level0DFDExample
user
processing request requested video signal
video source
digital video processor

NTSC video signal
monitor
37
ConstructingaDFDII

writeanarrativedescribingthetransform parsetodeterminenextleveltransforms balancetheflowtomaintaindataflow continuity developalevel1DFD usea1:5(approx.)expansionratio
38
TheDataFlowHierarchy
x a P b y level 0
p1
c d
p2
f
p4
p3
level 1
39
FlowModelingNotes
eachbubbleisrefineduntilitdoesjust onething theexpansionratiodecreasesasthe numberoflevelsincrease mostsystemsrequirebetween3and7 levelsforanadequateflowmodel asingledataflowitem(arrow)maybe expandedaslevelsincrease(data dictionaryprovidesinformation)
40
ProcessSpecification(PSPEC)
bubble
PSPEC narrative pseudocode (PDL) equations tables diagrams and/or charts
41
DFDs:ALookAhead
analysis model
Maps into
design model
42
ControlFlowDiagrams
Representseventsandtheprocessesthatmanage events AneventisaBooleanconditionthatcanbe ascertainedby:

listingallsensorsthatare"read"bythesoftware. listingallinterruptconditions. listingall"switches"thatareactuatedbyanoperator. listingalldataconditions. recallingthenoun/verbparsethatwasappliedtotheprocessing narrative,reviewall"controlitems"aspossibleCSPEC inputs/outputs.

43
TheControlModel
thecontrolflowdiagramis"superimposed"ontheDFD andshowseventsthatcontroltheprocessesnotedin theDFD controlflowseventsandcontrolitemsarenotedby dashedarrows averticalbarimpliesaninputtooroutputfromacontrol spec(CSPEC)aseparatespecificationthat describeshowcontrolishandled adashedarrowenteringaverticalbarisaninputtothe CSPEC adashedarrowleavingaprocessimpliesadata condition adashedarrowenteringaprocessimpliesacontrol inputreaddirectlybytheprocess controlflowsdonotphysicallyactivate/deactivatethe processesthisisdoneviatheCSPEC
44
ControlFlowDiagram
c p sd n o ie o e b e e o /o e p r n ff
re d a o e to p ra r in u pt
fu ll p bm ro le lig t h
s rt ta
mn g aae c p in oy g
e p m ty
re a lo d p cs ro e s p rfo e rm p bm ro le d g o is ia n s
c a re te ue sr dpy is la s
d p yp n l e a le is la a e n b d ja m d me
45
ControlSpecification(CSPEC)
TheCSPECcanbe: statediagram (sequentialspec) statetransitiontable decisiontables activationtables combinatorialspec
46
GuidelinesforBuildingaCSPEC
listallsensorsthatare"read"bythesoftware listallinterruptconditions listall"switches"thatareactuatedbytheoperator listalldataconditions recallingthenounverbparsethatwasappliedtothe softwarestatementofscope,reviewall"controlitems" aspossibleCSPECinputs/outputs describethebehaviorofasystembyidentifyingits states;identifyhoweachstateisreachanddefines thetransitionsbetweenstates focusonpossibleomissions...averycommonerrorin specifyingcontrol,e.g.,ask:"IsthereanyotherwayI cangettothisstateorexitfromit?"
47
ClassBasedModeling
Identifyanalysisclassesbyexaminingthe problemstatement Useagrammaticalparsetoisolatepotential classes Identifytheattributesofeachclass Identifyoperationsthatmanipulatetheattributes
48
Externalentities(e.g.,othersystems,devices,people)thatproduceorconsume informationtobeusedbyacomputerbasedsystem. Things(e.g,reports,displays,letters,signals)thatarepartoftheinformation domainfortheproblem. Occurrencesorevents(e.g.,apropertytransferorthecompletionofaseriesofrobot movements)thatoccurwithinthecontextofsystemoperation. Roles(e.g.,manager,engineer,salesperson)playedbypeoplewhointeractwiththe system. Organizationalunits(e.g.,division,group,team)thatarerelevanttoanapplication. Places(e.g.,manufacturingfloororloadingdock)thatestablishthecontextofthe problemandtheoverallfunctionofthesystem. Structures(e.g.,sensors,fourwheeledvehicles,orcomputers)thatdefineaclassof objectsorrelatedclassesofobjects.
AnalysisClasses
49
SelectingClassesCriteria
retainedinformation neededservices multipleattributes commonattributes commonoperations essentialrequirements
50
Class name
ClassDiagram
System
systemID verificationPhoneNumber systemStatus delayTime telephoneNumber masterPassword temporaryPassword numberTries
attributes
program() display() reset() query() modify() call()
operations
51
ClassDiagram
FloorPlan
type nam e ou tsid eDim ension s determineTyp ( ) e position Floorplan scale( ) ch ang color( ) e
is placed within is part of
Camera
type ID location fieldV iew panA ngle ZoomSetting determineType () trans lateLocation () dis playID() dis playV iew() dis playZoom()
Wall
type wallDimens ions
determ eType ( ) in com teDim sion pu en s
()
is used to build
is used to build is used to build
WallSegment
type s tartCoordinates s topCoordinates nextWallSement
Window
type s tartCoordinates s topCoordinates nextWindow
Door
type s tartCoordinates s topCoordinates nextDoor
d eterm ineType ( ) d raw ) (
d eterm ineType ( ) d raw ) (
determineTyp ( ) e draw ) (
52
CRCModeling
Analysisclasseshaveresponsibilities
Analysisclassescollaboratewithoneanother
Responsibilitiesaretheattributesandoperationsencapsulatedby theclass Collaboratorsarethoseclassesthatarerequiredtoprovidea classwiththeinformationneededtocompletearesponsibility. Ingeneral,acollaborationimplieseitherarequestfor informationorarequestforsomeaction.
53
CRCModeling
Class: Class: Description: Class: Description:FloorPlan Class: Description: Respo nsibility: Description: Respo nsibility: Respo nsibility: Respo nsibility:
defines floor plan name/type manages floor plan positioning scales floor plan for display scales floor plan for display incorporates walls, doors and windows Wall shows position of video cameras Camera
Co llabo rato r: Co llabo rato r: Co llabo rato r: Co llabo rato r:
54
ClassTypes
Entityclasses,alsocalledmodelorbusinessclasses,areextracted directlyfromthestatementoftheproblem(e.g.,FloorPlanand Sensor). Boundaryclassesareusedtocreatetheinterface(e.g.,interactive screenorprintedreports)thattheuserseesandinteractswithas thesoftwareisused. Controllerclassesmanageaunitofwork[UML03]fromstartto finish.Thatis,controllerclassescanbedesignedtomanage

thecreationorupdateofentityobjects; theinstantiationofboundaryobjectsastheyobtaininformationfrom entityobjects; complexcommunicationbetweensetsofobjects; validationofdatacommunicatedbetweenobjectsorbetweenthe userandtheapplication.
55
Responsibilities

Systemintelligenceshouldbedistributedacrossclasses tobestaddresstheneedsoftheproblem Eachresponsibilityshouldbestatedasgenerallyas possible Informationandthebehaviorrelatedtoitshouldreside withinthesameclass Informationaboutonethingshouldbelocalizedwitha singleclass,notdistributedacrossmultipleclasses. Responsibilitiesshouldbesharedamongrelatedclasses, whenappropriate.
56
Collaborations
Classesfulfilltheirresponsibilitiesinoneoftwoways:
Collaborationsidentifyrelationshipsbetweenclasses Collaborationsareidentifiedbydeterminingwhetheraclasscanfulfilleach responsibilityitself threedifferentgenericrelationshipsbetweenclasses[WIR90]:

Aclasscanuseitsownoperationstomanipulateitsownattributes,thereby fulfillingaparticularresponsibility,or aclasscancollaboratewithotherclasses.
theispartofrelationship thehasknowledgeofrelationship thedependsuponrelationship
57
CompositeAggregateClass
Player
PlayerHead
PlayerBody
PlayerArms
PlayerLegs
58
ReviewingtheCRCModel
Allparticipantsinthereview(oftheCRCmodel)aregivenasubsetoftheCRCmodel indexcards.
Allusecasescenarios(andcorrespondingusecasediagrams)shouldbeorganized intocategories. Thereviewleaderreadstheusecasedeliberately.
Cardsthatcollaborateshouldbeseparated(i.e.,noreviewershouldhavetwocardsthat collaborate).
Whenthetokenispassed,theholderoftheclasscardisaskedtodescribethe responsibilitiesnotedonthecard.
Asthereviewleadercomestoanamedobject,shepassesatokentothepersonholdingthe correspondingclassindexcard.
Iftheresponsibilitiesandcollaborationsnotedontheindexcardscannot accommodatetheusecase,modificationsaremadetothecards.
Thegroupdetermineswhetherone(ormore)oftheresponsibilitiessatisfiestheusecase requirement.
Thismayincludethedefinitionofnewclasses(andcorrespondingCRCindexcards)orthe specificationofneworrevisedresponsibilitiesorcollaborationsonexistingcards.
59
AssociationsandDependencies
Twoanalysisclassesareoftenrelatedtooneanotherin somefashion

Inmanyinstances,aclientserverrelationshipexists betweentwoanalysisclasses.
InUMLtheserelationshipsarecalledassociations Associationscanberefinedbyindicatingmultiplicity(theterm cardinalityisusedindatamodeling
Insuchcases,aclientclassdependsontheserverclassinsome wayandadependencyrelationshipisestablished
60
Multiplicity
Wall
1 is used to build 1..*

WallSegment Window
1 is used to build
0..* is used to build

Door
0..*
61
Dependencies
DisplayWindow <<access>>
{password}
Camera
62
AnalysisPackages
Variouselementsoftheanalysismodel(e.g.,usecases, analysisclasses)arecategorizedinamannerthat packagesthemasagrouping Theplussignprecedingtheanalysisclassnameineach packageindicatesthattheclasseshavepublicvisibility andarethereforeaccessiblefromotherpackages. Othersymbolscanprecedeanelementwithinapackage. Aminussignindicatesthatanelementishiddenfrom allotherpackagesanda#symbolindicatesthatan elementisaccessibleonlytopackagescontainedwithina givenpackage.
63
AnalysisPackages
package name
Environment +Tree e +Landscape e +Road d +Wall l +Bridge e +Building g +VisualEffect t +Scene e
RulesOfTheGame +RulesOfMovement t +ConstraintsOnAction
Characters +Player r +Protagonist t +Antagonist t +SupportingRole
64
BehavioralModeling
Thebehavioralmodelindicateshowsoftwarewillrespondto externaleventsorstimuli.Tocreatethemodel,theanalystmust performthefollowingsteps:

Evaluateallusecasestofullyunderstandthesequenceofinteractionwithin thesystem. Identifyeventsthatdrivetheinteractionsequenceandunderstandhow theseeventsrelatetospecificobjects. Createasequenceforeachusecase. Buildastatediagramforthesystem. Reviewthebehavioralmodeltoverifyaccuracyandconsistency.
65
StateRepresentations
Inthecontextofbehavioralmodeling,twodifferent characterizationsofstatesmustbeconsidered:

Thestateofaclasstakesonbothpassiveandactive characteristics[CHA93].

thestateofeachclassasthesystemperformsitsfunctionand thestateofthesystemasobservedfromtheoutsideasthe systemperformsitsfunction
Apassivestateissimplythecurrentstatusofallofanobjects attributes. Theactivestateofanobjectindicatesthecurrentstatusofthe objectasitundergoesacontinuingtransformationorprocessing.
66
StateDiagramfortheControlPanelClass
t imer < lockedTime locked
t imer > lockedTime
password = incorrect & numberOfTries < maxTries comparing password ent ered numberOfTries > maxTries
key hit
reading
do: validatePassword
password = correct
select ing
act ivat ion successful
67
TheStatesofaSystem
stateasetofobservablecircumstances thatcharacterizesthebehaviorofa systematagiventime statetransitionthemovementfromone statetoanother eventanoccurrencethatcausesthe systemtoexhibitsomepredictableform ofbehavior actionprocessthatoccursasa consequenceofmakingatransition
68
BehavioralModeling
makealistofthedifferentstatesofasystem (Howdoesthesystembehave?) indicatehowthesystemmakesatransition fromonestatetoanother(Howdoesthe systemchangestate?)

drawastatediagramorasequencediagram
indicateevent indicateaction
69
SequenceDiagram
homeowner cont rol panel syst em sensors sensors syst em ready
A
password ent ered
reading
comparing
request lookup result

password = correct
numberOfTries > maxTries
request act ivat ion locked
t imer > lockedTime
select ing act ivat ion successful act ivat ion successful
Figure 8.27 Sequence diagram (partial) for
SafeHome security function
70
WritingtheSoftwareSpecification
Everyone knew exactly what had to be done until someone wrote it down!
71
SpecificationGuidelines
use a layered format that provides increasing detail as the "layers" deepen use consistent graphical notation and apply textual terms consistently (stay away from aliases) be sure to define all acronyms be sure to include a table of contents; ideally, include an index and/or a glossary write in a simple, unambiguous style (see "editing suggestions" on the following pages) always put yourself in the reader's position, "Would I be able to understand this if I wasn't intimately familiar with the system?"
72
Be on the lookout for persuasive connectors, ask why? keys: certainly, therefore, clearly, obviously, it follows that ... Watch out for vague terms keys: some, sometimes, often, usually,ordinarily, most, mostly ... When lists are given, but not completed, be sure all items are understood keys: etc., and so forth, and so on, such as Be sure stated ranges don't contain unstated assumptions e.g., Valid codes range from 10 to 100. Integer? Real? Hex? Beware of vague verbs such as handled, rejected, processed, ... Beware "passive voice" statements e.g., The parameters are initialized.By what? Beware "dangling" pronouns e.g., The I/O module communicated with the data validation module and its contol flag is set. Whose control flag?
73
When a term is explicitly defined in one place, try substituting the definition forother occurrences of the term When a structure is described in words, draw a picture When a structure is described with a picture, try to redraw the picture to emphasize different elements of the structure When symbolic equations are used, try expressing their meaning in words When a calculation is specified, work at least two examples Look for statements that imply certainty, then ask for proof keys; always, every, all, none, never Search behind certainty statementsbe sure restrictions or limitations are realistic
74

Unit 4 Analysis Model

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit 4 Analysis Model

Uploaded by

Copyright:

Available Formats

SoftwareEngineering:APractitionersApproach, 6/e

specifiessoftwaresoperationalcharacteristics indicatessoftware'sinterfacewithothersystemelements establishesconstraintsthatsoftwaremustmeet

elaborateonbasicrequirementsestablishedduringearlier requirementengineeringtasks buildmodelsthatdepictuserscenarios,functionalactivities, problemclassesandtheirrelationships,systemandclass behavior,andtheflowofdataasitistransformed.

analysis mo del design mo del

Definethedomaintobeinvestigated. Collectarepresentativesampleofapplicationsin thedomain. Analyzeeachapplicationinthesample. Developananalysismodelfortheobjects.

examinesdataobjectsindependentlyof processing focusesattentiononthedatadomain createsamodelatthecustomerslevelof abstraction indicateshowdataobjectsrelatetoone another

severalinstancesofarelationshipcan exist objectscanberelatedinmanydifferent ways

Another common form: object 1

request for service (1,1)

work order (1,1)

work (1,w) tasks materials

Mustbeunderstoodtoapplyclassbased elementsoftheanalysismodel Keyconcepts:

Classesandobjects Attributesandoperations Encapsulationandinstantiation Inheritance

ametaclass(alsocalledasuperclass) establishesahierarchyofclasses onceaclassofitemsisdefined,a specificinstanceoftheclasscanbe identified

template generalizeddescription blueprint...describingacollectionof similaritems

class name attributes:

Achieves information hiding

ascenariothatdescribesathreadofusagefor asystem actorsrepresentrolespeopleordevicesplayas thesystemfunctions userscanplayanumberofdifferentrolesfora givenscenario

Whatarethemaintasksorfunctionsthatareperformedbythe actor? Whatsysteminformationwillthetheactoracquire,produceor change? Willtheactorhavetoinformthesystemaboutchangesinthe externalenvironment? Whatinformationdoestheactordesirefromthesystem? Doestheactorwishtobeinformedaboutunexpectedchanges?

Configure SafeHome system parameters homeowner

s elect m ajor function

prom pt for reentry

in u t r ies r emain p t n in u o p t t r ies r emain

select a sp ecif ic camer a

s elect s pec ific cam era - thum bnails

select cam era icon

view cam era output in labelled window

prom pt for another view

enter pas s word Allowsthemodelertorepresenttheflowofactivitiesdescribedbytheusecaseandatthe and us er ID sametimeindicatewhichactor(iftherearemultipleactorsinvolvedinaspecificusecase) oranalysisclasshasresponsibilityfortheactiondescribedbyanactivityrectangle

s elect major function

prompt for reentry

select a sp e cif ic camer a

s elect s pecific camera - thumbnails

s elect camera icon

computer based system

process data flow data store

look-up sensor data

type, location, age sensor data

alliconsmustbelabeledwithmeaningful names theDFDevolvesthroughanumberof levelsofdetail alwaysbeginwithacontextleveldiagram (alsocalledlevel0) alwaysshowexternalentitiesatlevel0 alwayslabeldataflowarrows donotrepresentprocedurallogic

reviewthedatamodeltoisolatedataobjects anduseagrammaticalparsetodetermine operations determineexternalentities(producersand consumersofdata) createalevel0DFD

digital video processor

writeanarrativedescribingthetransform parsetodeterminenextleveltransforms balancetheflowtomaintaindataflow continuity developalevel1DFD usea1:5(approx.)expansionratio

eachbubbleisrefineduntilitdoesjust onething theexpansionratiodecreasesasthe numberoflevelsincrease mostsystemsrequirebetween3and7 levelsforanadequateflowmodel asingledataflowitem(arrow)maybe expandedaslevelsincrease(data dictionaryprovidesinformation)

PSPEC narrative pseudocode (PDL) equations tables diagrams and/or charts

Representseventsandtheprocessesthatmanage events AneventisaBooleanconditionthatcanbe ascertainedby:

listingallsensorsthatare"read"bythesoftware. listingallinterruptconditions. listingall"switches"thatareactuatedbyanoperator. listingalldataconditions. recallingthenoun/verbparsethatwasappliedtotheprocessing narrative,reviewall"controlitems"aspossibleCSPEC inputs/outputs.

Identifyanalysisclassesbyexaminingthe problemstatement Useagrammaticalparsetoisolatepotential classes Identifytheattributesofeachclass Identifyoperationsthatmanipulatetheattributes

program() display() reset() query() modify() call()

is placed within is part of

determ eType ( ) in com teDim sion pu en s

is used to build is used to build

d eterm ineType ( ) d raw ) (

d eterm ineType ( ) d raw ) (

Responsibilitiesaretheattributesandoperationsencapsulatedby theclass Collaboratorsarethoseclassesthatarerequiredtoprovidea classwiththeinformationneededtocompletearesponsibility. Ingeneral,acollaborationimplieseitherarequestfor informationorarequestforsomeaction.

Co llabo rato r: Co llabo rato r: Co llabo rato r: Co llabo rato r:

thecreationorupdateofentityobjects; theinstantiationofboundaryobjectsastheyobtaininformationfrom entityobjects; complexcommunicationbetweensetsofobjects; validationofdatacommunicatedbetweenobjectsorbetweenthe userandtheapplication.

Collaborationsidentifyrelationshipsbetweenclasses Collaborationsareidentifiedbydeterminingwhetheraclasscanfulfilleach responsibilityitself threedifferentgenericrelationshipsbetweenclasses[WIR90]:

Aclasscanuseitsownoperationstomanipulateitsownattributes,thereby fulfillingaparticularresponsibility,or aclasscancollaboratewithotherclasses.

theispartofrelationship thehasknowledgeofrelationship thedependsuponrelationship

Allusecasescenarios(andcorrespondingusecasediagrams)shouldbeorganized intocategories. Thereviewleaderreadstheusecasedeliberately.

InUMLtheserelationshipsarecalledassociations Associationscanberefinedbyindicatingmultiplicity(theterm cardinalityisusedindatamodeling

1 is used to build 1..*

0..* is used to build