Uml2 and Use Case Model Ver 0 0 4

30.10.
2011
UML 2 &
Use Case Models
BinnurKurt,Ph.D.
OmegaTrainingandConsultancy
www.omegaegitim.com
binnur.kurt@gmail.com
UML2&UseCaseModels
Agenda
1. ModelingwithUML2andSoftwareDevelopmentProcess
2. CreatingUseCaseDiagrams
3. CreatingUseCaseScenariosandForms
30.10.2011
UML2&UseCaseModels
Background
1995,B.Sc.
1997,M.Sc.
2007,Ph.D.
(AllinComputerEngineering)
20042008,Lecturer, ITUComputer Eng. Dept.
2008todate,Trainer &Consultant
UML2&UseCaseModels
References UML2
30.10.2011
UML2&UseCaseModels
References UML2, Use Cases
UML2&UseCaseModels
References Use Cases
30.10.2011
UML2&UseCaseModels
Biography
Dr. Binnur Kurt received BS, MS, and PhD degrees from Istanbul Technical
University in 1995, 1997, 2007 all in computer engineering. He was a
lecturer at the Computer Engineering Department of Istanbul Technical
University from 2004 to 2007 and offered courses mostly on web
programming and object oriented software engineering. He is currently
working as an information technology consultant and trainer in Java
Enterprise Technologies, Object Oriented Analysis and Design, Service
Oriented Architecture, MySQL, Oracle Middleware Technologies, Unix
Programming and Administration, High performance computing, and Real
Time Computer Vision systems. He has published many international
conference and journal papers, and book chapters on these topics. He has
also designed many IT trainings and written training materials on
advanced topics, including Spring Framework, JSF, XML Web Services,
Service Oriented Architecture, and OSGi. He holds several certifications,
including Sun Certified Java Programmer, Oracle Certified Professional
MySQL 5.0 Developer, Oracle Certified Professional MySQL 5.0 Database
Administrator and Red Hat Certified Engineer. He is also referee for the
assessment of industrial projects submitted to TUBITAK Technology and
Innovation Funding Programs Directorate (TEYDEB) and inspector for
industrial projects supported by TUBITAK Technology and Innovation
Funding Programs Directorate (TEYDEB).
UML2&UseCaseModels
AreasofInterest
>
>
>
>
>
>
JavaDesktopandEnterpriseTechnologies
SOA
OOAD
MySQL
OracleDirectoryServer
ApplicationServers:WebLogic,Glassfish,Tomcat
30.10.2011
1
ModelingwithUML2
and
SoftwareDevelopmentProcess
UML2&UseCaseModels 1 ModelingwithUML2
10
SoftwareComplexity
> Theprofileandimportanceofsoftwarehasincreased
30.10.2011
11
SoftwareComplexityisincreasing
12
Andthingsareonlygoingtogetworse
> Increasinglycomplex,vulnerableand everychanging
platforms,applications andcustomerdesires.
30.10.2011
13
ImportantSkills
> Theseskillsareessentialforthecreationofwelldesigned,robust,and
maintainablesoftware
OOA/D
Patterns
UMLnotation
Skills
Principlesand
guidelines
Requirements
analysis
Software
Development
ProcessModel
> Applyprinciplesandpatternstocreatebetterobjectdesigns.
> Followasetofcommonactivitiesinanalysisanddesign,basedonthe
UnifiedProcessasanexample.
> CreatediagramsintheUMLnotation.
14
OOConcepts
>
>
>
>
>
>
>
>
>
>
>
Objects
Classes
Abstraction
Encapsulation
Inheritance
Interfaces
Polymorphism
Cohesion
Coupling
Classassociationsandobjectlinks
Delegation
30.10.2011
15
OOPPrincipals
>
>
>
>
>
>
>
TheSingleResponsibilityPrinciple(SRP)
TheOpen/ClosedPrinciple(OCP)
TheLiskov SubstitutionPrinciple(LSP)
CommonClosurePrinciple(CCP)
AcyclicDependencyPrinciple(ADP)
StableDependenciesPrinciple(SDP)
StableAbstractionsPrinciple(SAP)
16
Patterns
>
>
>
>
>
DesignPatterns GoFPatterns
SecurityPatterns
NetworkingPatterns
Concurrent,ParallelSystemPatterns
JavaEEPatterns
30.10.2011
17
DescribingSoftwareMethodology
Amethodologyisabodyofmethods,rules,andpostulates
employedbyadiscipline[WebsterNewCollegiateDictionary]
> InOOSD,methodologyreferstothehighestlevel
organizationofasoftwareproject.
> Thisorganizationcanbedecomposedinto medium
levelphases.Phasesaredecomposedinto workflows
(disciplines).Workflowsaredecomposed intoactivities.
> Activitiestransformtheartifactsfromoneworkflowto
another.Theoutputofoneworkflowbecomesthe
inputintothenext.
> Thefinalartifactisaworkingsoftwaresystemthat
satisfiestheinitialartifacts:thesystemrequirements.
18
TheOOSDHierarchy
30.10.2011
19
Listingthe WorkflowsoftheOOSDProcess
Softwaredevelopmenthastraditionallyencompassedthe
followingworkflows:
> RequirementsGathering
> RequirementsAnalysis
> Architecture
> Design
> Implementation
> Testing
> Deployment
20
DescribingtheSoftwareTeamJobRoles
10
30.10.2011
21
DescribingtheSoftwareTeamJobRoles
22
ExploringtheRequirementsGathering
Workflow
11
30.10.2011
23
ActivitiesandArtifactsoftheRequirements
Gathering Workflow
24
ExploringtheRequirementsAnalysis
Workflow
12
30.10.2011
25
ActivitiesandArtifactsoftheRequirements
Analysis Workflow
26
ExploringtheArchitectureWorkflow
13
30.10.2011
27
ActivitiesandArtifactsoftheArchitecture
Workflow
28
ExploringtheDesignWorkflow
14
30.10.2011
29
ExploringtheDesignWorkflow
30
ActivitiesandArtifactsoftheDesign
Workflow
15
30.10.2011
31
ExploringtheImplementation,Testing,and
Deployment Workflows
32
ExploringtheImplementation,Testing,and
Deployment Workflows
16
30.10.2011
33
ExploringtheBenefitsofModelingSoftware
> Theinceptionofeverysoftwareprojectstartsasanideain
someonesmind.
> Toconstructarealizationofthatidea,thedevelopment
team mustcreateaseriesofconceptualmodelsthat
transformthe ideaintoaproductionsystem.
34
ActivitiesandArtifactsofthe
Implementation,Testing,andDeployment
Workflows
17
30.10.2011
35
WhatisaModel?
Amodelisasimplificationofreality.(Booch UMLUserGuide
page6)
> A modelisanabstractconceptualizationofsomeentity
(suchasabuilding)orasystem(e.g.software).
> Differentviewsshowthemodelfromdifferent perspectives.
36
WhyModelSoftware?
Webuildmodelssothatwecanbetterunderstandthesystem we
aredeveloping.(Booch UMLUserGuidepage6)
> Specifically,modelingenablesusto:
Visualizeneworexistingsystems
Communicatedecisionstotheprojectstakeholders
DocumentthedecisionsmadeineachOOSDworkflow
Specifythestructure(static)andbehavior(dynamic)
elementsofasystem
Useatemplateforconstructingthesoftwaresolution
18
30.10.2011
37
InformationSystemsandITSystems
> AnITsystemisacomputerbasedsystemasystemthatprovides
informationneeded fortheexecutionofcertainbusiness
processes.
> Abusinessmodelisaframeworkforcreating economic,social,
and/orotherformsofvalue.
> Abusinessprocessisacollectionofrelated,structuredactivities
ortasksthatproduceaspecificserviceorproductforaparticular
customerorcustomers.
38
Definition:BusinessProcessManagement
BusinessProcessManagement(BPM)isdefinedasa
strategyformanagingandimprovingtheperformanceof
abusinessthroughcontinuous optimization ofbusiness
processesinaclosedloopcycle ofmodeling,execution,
andmeasurement.
Modeling
Execution
Measurement
19
30.10.2011
39
Definition:BusinessProcess
Abusinessprocess isasetoflinkedactivities performed
bypeople andsystems thatdeliversomekindofvalue
throughaproductorprocesstointernalorexternal
customers.
40
RealWorldBusinessProcesses
OrganizationalUnits
Operations
Salesand
Marketing
Manu
facturing
Financeand
HR
OrderManagement
Processes
ProductConfiguration
WarrantyandReturnsManagement
Enterpriseinfrastructureservices
(portal,SOA,IDRS,LDAP,EAI,Email,IToperations)
20
30.10.2011
41
RealWorldBusinessProcessManagement
OrderManagementProcess
Operations
Salesand
Marketing
Manu
facturing
Financeand
HR
Enterpriseinfrastructureservices
(portal,SOA,IDRS,LDAP,EAI,Email,IToperations)
42
Summary:BusinessProcessManagement
Strategy
Goals
Policies
Process
X
Systems
People
Information
21
30.10.2011
43
ElementsofaBPMNBusinessProcessModel
Gateway
Task
UserTask
Start
End
Activity1
Activity2
Event
SequenceFlow
44
OOSDasModelTransformations
> Softwaredevelopmentcanbeviewedasaseriesof
transformationsfromtheStakeholdersmentalmodelto
the actualcode:
22
30.10.2011
45
OOSDasModelTransformations
Book
title
Book
title:String
+turnPage(int)
Applicationdomain
Applicationdomainmodel
Softwaredomainmodel
public class Book {

private String title;
public void turnPage(int pn){...}
}
46
DefiningtheUML
TheUnifiedModelingLanguage(UML)isagraphical languagefor
visualizing,specifying,constructing,and documentingthe
artifactsofasoftwareintensivesystem. (UMLv1.4pagexix)
> UsingtheUML,amodeliscomposedof:
Elements(thingsandrelationships)
Diagrams(builtfromelements)
Views(diagramsshowingdifferentperspectivesofa
model)
23
30.10.2011
47
UMLElements
48
UMLDiagrams
24
30.10.2011
49
UMLDiagramCategories
50
CommonUMLElementsandConnectors
> UMLhasafewelementsandconnectorsthatarecommon
acrossUMLdiagrams.Theseinclude:
Package
Note
Dependency
Stereotypes
25
30.10.2011
51
PackagesandNotes
> Package
> Notes
52
DependencyandStereotype
26
30.10.2011
53
WhatUMLIsandIsNot
54
HistoryofUML
27
30.10.2011
55
UMLSubspecifications
UMLVersion2.0hasbeenformallydividedintothe
followingsubspecifications:
> Infrastructure:Coreofthearchitecture,profiles,and
stereotypes.
> Superstructure:Staticanddynamicmodelelements.
> ObjectConstraintLanguage(OCL):Aformallanguage
usedtodescribeexpressions onUMLmodels.
> DiagramInterchange:TheUMLinterchangeformatfor
diagrams.
56
TheMetamodel ofUML 2.0

TheUML2.0languageislargelydefinedinasocalled
metamodel.
> Thereasonfor theprefixmetaisthatthelanguage
residesoneabstractionlevelabovethemodel thata
UMLusermodels.
> Now,themetamodel mightseemconfusingand
illogical atfirstbecausethemetamodel isaUMLclass
modelthatdescribesUML.
> Inother words,UMLisdefinedinUML.
28
30.10.2011
57
ThefourlayerarchitectureofUML
58
Datatypes
UMLdistinguishesbetweenthefollowingdatatypes:
> Simpledatatypes(DataType)Asimpledatatypeisa
typewithvaluesthat havenoidentity(e.g.,money,
bankinginformation
> Primitivedatatypes(PrimitiveType)Aprimitivedata
typeisasimpledatatypewithoutstructures.
> UMLitselfdefinesthe followingprimitivedatatypes:
Integer:(Infinite)setofintegers:(...,2,1,0,1,2,...)
Boolean: true,false
UnlimitedNatural (Infinite)setofnaturalnumbers(0,
1,2,...)
29
30.10.2011
59
Datatypes
> UMLitselfdefinesthe followingprimitivedatatypes:
EnumerationtypesEnumerationtypesaresimple
datatypeswithvalues thatoriginatefromalimitedset
ofenumerationliterals
60
Themetamodelofdatatypes
30
30.10.2011
61
OverviewoftheUMLdiagrams
62
Stereotypes
> Stereotypesareformalextensionsofexistingmodel
elementswithintheUML metamodel,thatis,metamodel
extensions.
> Themodelingelementisdirectlyinfluenced bythe
semanticsdefinedbytheextension.
> Ratherthanintroducinganewmodel elementtothe
metamodel,stereotypesaddsemanticstoanexisting
modelelement.
31
30.10.2011
63
MultipleStereotyping
> Severalstereotypescanbeusedtoclassifyonesingle
modeling element.
> Eventhevisualrepresentationofanelementcanbe
influencedbyallocating stereotypes.
> Moreover,stereotypescanbeaddedtoattributes,
operations,andrelationships.
> Further,stereotypescanhaveattributestostore
additionalinformation.
64
Notation
> Astereotypeisplacedbeforeorabovetheelementname
(e.g.,class name)andenclosedinguillemets (,).
> Thecharactersand,sometimes referredtoasangled
quotes,shouldnotbemistakenfordoubledgreaterthan,
>>,orsmallerthan,<<,characters.
> Noteveryoccurrenceofthisnotationmeansthatyouare
lookingatastereotype.
> KeywordspredefinedinUMLarealsoenclosedin
guillemets.
32
30.10.2011
65
GraphicalSymbols
> Asanalternativetothispurelytextualnotation,special
symbols canbeused.
> Examples: entity,boundary,andcontrol
> Inaddition,toolsarefreetousespecialcolormarkingor
othervisualhighlighting
66
UMLStandardStereotypes
33
30.10.2011
67
UMLStandardStereotypes
68
NonStandardUMLStereotypes
34
30.10.2011
69
NonStandardUMLStereotypes
70
UMLTools
> UMLitselfisatool.YoucancreateUMLdiagramson
paper orawhiteboard.However,softwaretoolsare
availableto:
> ProvidecomputeraideddrawingofUMLdiagrams
> Support(orenforce)semanticverificationofdiagrams
> Providesupportforaspecificmethodology
> GeneratecodeskeletonsfromtheUMLdiagrams
> Organizeallofthediagramsforaproject
> Automaticgenerationofmodelingelementsfordesign
patterns,JavaPlatform,EnterpriseEdition(JavaEE
platform)components,andsoon
35
30.10.2011
71
An Example:
Dice Game
72
AnExample
> Beforedivingintothedetailsofrequirementsanalysisand
OOA/D,thissectionpresentsabirdseyeviewofafewkey
stepsanddiagrams,usingasimpleexample
A "dice game"inwhichaplayerrollstwodie.
Ifthetotalisseven, theywin
Otherwise,theylose.
36
30.10.2011
73
DefineUsecases
> Usecasesarenotanobjectorientedartifacttheyare
simplywrittenstories.
> However,theyareapopulartoolinrequirementsanalysis
andareanimportant partoftheUnifiedProcess.
74
DiceGameusecase
> PlayaDiceGame:Aplayerpicksupandrollsthedice.If
the dicefacevaluetotalseven,theywin;otherwise,they
lose.
37
30.10.2011
75
DefineaDomainModel
> Objectorientedanalysisisconcernedwithcreatinga
descriptionofthedomain fromtheperspectiveof
classificationbyobjects.
> Adecompositionofthedomain involvesanidentification
oftheconcepts,attributes,andassociationsthatare
considerednoteworthy.
76
DefineInteractionDiagrams
> Objectorienteddesignisconcernedwithdefining
softwareobjectsandtheircollaborations.
> Acommonnotationtoillustratethesecollaborationsis
theinteraction diagram.
38
30.10.2011
77
DefineInteractionDiagrams
:DiceGame
die1:Die
die2:Die
play()
roll()
fv1:=getFaceValue()
roll()
fv2:=getFaceValue()
78
DefineDesignClassDiagrams
> Inadditiontoadynamicviewofcollaboratingobjects
shownininteractiondiagrams, itisusefultocreatea
staticviewoftheclassdefinitionswithadesign class
diagram.
> Thisillustratestheattributesandmethodsoftheclasses.
DiceGame
die1:Die
die2:Die
play()
Die
1
faceValue:int
getFaceValue():int
roll()
39
30.10.2011
2
Creating
UseCaseDiagrams
?
?? ?
UML2&UseCaseModels 2 CreatingUseCaseDiagrams
80
40
30.10.2011
81
ProcessMap
82
ProcessMap
41
30.10.2011
83
JustifyingtheNeedforaUseCaseDiagram
FollowingarereasonsaUseCasediagramisnecessary:
> AUseCasediagramenablesyoutoidentifyby
modelingthehighlevelfunctionalrequirements(FRs)
thatarerequiredtosatisfyeachusersgoals.
> Theclientsidestakeholdersneedabigpictureviewof the
system.
> Theusecasesformthebasisfromwhichthedetailed FRs
aredeveloped.
> Usecasescanbeprioritizedanddevelopedinorderof
priority.
> Usecasesoftenhaveminimaldependencies,which
enablesadegreeofindependentdevelopment.
84
Usecasesandotherrequirements
FURPS
> Functionality
> Usability
> Reliability
> Performance
> Supportability
Use Cases
Designconstraints
> Operatingsystems
> Environments
> Compatibility
> Applicationstandards
Legalandregulatoryrequirements
> FederalCommunicationCommission
> FoodandDrugAdministration
> DepartmentofDefense
> CanadianStandardsAssociation
> EuropeanUnionDirective
42
30.10.2011
85
Usecasesdrivesoftwaredevelopment
Implemented by
UseCaseModel
DesignModel
TestModel
Implementation Model
86
IdentifyingtheElementsofaUseCase Diagram
> AUseCasediagramshowstherelationshipsbetween
actors (roles)andthegoalstheywishtoachieve.
> Aphysicaljobtitlecanassumemultipleactors(roles).
43
30.10.2011
87
IdentifyingtheElementsofaUseCase Diagram
> Thisdiagramillustratesanalternatestylethatexplicitly
showsanassociationbetweentheReceptionistactor
(role) andtheManageReservationusecase.
88
Actors
Anactor:
> Modelsatypeofrolethatisexternaltothesystemand
interactswiththatsystem
> Canbeahuman,adevice,anothersystem,ortime
> Canbeprimaryorsecondary
Primary:Initiatesandcontrolsthewholeusecase
Secondary:Participatesonlyforpartoftheusecase
Asinglephysicalinstanceofahuman,adevice,orasystem
mayplaytheroleofseveraldifferentactors.
44
30.10.2011
89
Actors
Thisiconrepresentsa Thisiconcan
humanactor(user)of represent anyactor,
butisusually usedto
the system.
represent external
systems,devices, or
time.
Thisiconrepresents
atimetrigger
mechanismthat
activatesausecase.
90
Actors
Dkkan
Mteriye Sat Sistemi
Vergi
Dairesi
Ama: Vergileri
doru toplamak
Terminal
(kasa)
Sat nceleme
Sistemi
Kasa
Grevlisi
Mteri
Ama: Mal satn almak
Ama: Sat yapmak

Ama:Firmann sat
Performansn belirlemek
45
30.10.2011
91
UseCases
Ausecasedescribesaninteractionbetweenanactorand
the systemtoachieveagoal.
> Ausecaseencapsulatesamajorpieceofsystem behavior

withadefinableoutcome.
> Ausecaseisrepresentedasanovalwiththeusecase title
inthecenter.
> Agoodusecasetitleshouldconsistofabriefbut
unambiguousverbnounpair.
> AusecasecanoftenbeUIindependent.
92
SystemBoundary
> Theusecasesmayoptionallybeenclosedbyarectangle
that representsthesystemboundary.
Thesystemboundary
boxisoptional.
ThisequivalentUseCase
diagram showsthesystem
boundaryforclarity.
46
30.10.2011
93
UseCaseAssociations
Ausecaseassociationrepresentstheparticipationofan
actor inausecase.(UMLv1.4spec.page357)
> Anactormustbeassociatedwithoneormoreuse cases.

> Ausecasemustbeassociatedwithoneormoreactors.
> Anassociationisrepresentedbyasolidlinewithno
arrowheads. However,someUMLtoolsusearrowsby
default.
94
CreatingtheInitialUseCaseDiagram
> Oneoftheprimaryaimsoftheinitialmeetingwiththe
projectsbusinessowneristoidentifythebusiness
significant usecases.
Ausecasediagrammaybecreatedduringthemeeting.
Alternatively,thediagramscanbecreatedafterthe
meetingfromtextualnotes.
> Thenexttwoslidespresentsometextshowinganabstract
of theusecasespecifictopicsdiscussedduringthe
meeting.
47
30.10.2011
95
> Thebookingagent(internalstaff)mustbeabletomanage
reservationsonbehalf ofcustomerswhotelephoneoremail
withreservationrequests.Themajorityof theserequestswill
makeanewreservation,butoccasionallytheywillneedto
amendorcancelareservation.Areservationholdsoneormore
roomsofaroom typeforasingletimeperiod,andmustbe
guaranteedbyeitheranelectronic cardpaymentorthereceipt
ofapurchaseorderforcorporatecustomersand travelagents.
Thesepaymentguaranteesmustbesavedforfuturereference.
> AreservationcanalsobemadeelectronicallyfromtheTravel
Agentsystemand alsobycustomersdirectlyviatheinternet.
96
> Thereceptionistmustbeabletocheckincustomersarrivingatthe
hotel.This actionwillallocateoneormoreroomsoftherequested
type.Inmostcases,a furtherelectroniccardpaymentguaranteeis
required.
> Mostreceptionistswillbetrainedtoperformthebookingagenttasks
for customerswhoarrivewithoutabookingorneedtochangea
booking.
> Themarketingstaffwillneedtomanagepromotions(specialoffers)
basedona reviewofpastandfuturereservationstatistics.The
marketingstaffwill elaborateonthedetailedrequirementsina
subsequentmeeting.
> Themanagementneedsadailystatusreport,whichneedstobe
producedwhen thehotelisquiet.Thisactivityisusuallydoneat3
a.m.
48
30.10.2011
97
98
IdentifyingadditionalUseCases
> Duringthemeetingwiththebusinessowner,youwill
typicallydiscover10to20percentoftheusecases
neededfor thesystem.
> Duringthemeetingwiththeotherstakeholders,youwill
discovermanymoreusecasetitlesthatyoucanaddto
the diagram.
> Forexample:
MaintainRooms
Create,Update,andDelete
MaintainRoomTypes
Create,Update,andDelete
49
30.10.2011
99
> Thetimeofdiscoverydependsuponthedevelopment
process.
> Inanoniterativeprocess:
Youideallyneedtodiscoveralloftheremaininguse
casetitles,bringingthetotalto100percent.
However,thisisaresourceintensivetaskandis rarely
completelyaccurate.
100
> Inaniterative/incrementaldevelopmentprocess,an
optionisto:
Discoveratotalof80percentoftheusecasetitlesin
thenextfewiterationsfor20percentoftheeffort. This
isjustoneofthemanyusesofthe80/20 rule.
Discovertheremaining20percentofusecasetitles in
thelateriterationsforminimaleffort.
> Thisprocessworkswellwithsoftwarethatisbuiltto
accommodatechange.
50
30.10.2011
101
Workflowofusecasemodeling
Iterate
DescribetheUseCases
SeekActors
SeekUseCases
> SeekActors:Nameanddescribe
> SeekUseCases:
ForeachactoraskWhat'dyouliketousethesystemfor?
> NameandbrieflydescribeeachUseCase
> Iteratebasedonpreviousfindings
102
Findingactors
> Actorsareendpointsforcommunication,oraddsome
information.(Abuttonisnotanactorifithasnoother
functionthantoinformthesystemthatsomeonehas
pressedit.)
> Concentrateontheactiveactors.TheygiveyoutheUse
Cases.
> Remember:
Actorsrepresentroles!
Actorsarealwaysoutsidethesystem!
> Examples:users,othersystems,externalhardwareetc.
51
30.10.2011
103
Findingusecases
> BlackBoxviewofthesystem
> Ausecaseshouldsatisfyamajorgoalfortheactor
> Putyourselfinthesituationofan(active)actor.Ask
yourself:WhatdoIwanttodowiththesystem?
> Nameeachusecaseusingaverb/nouncombination
> TheUseCaseshallrepresentacompletefunctionalityfor
theinitiatingactor.Donotdivideitintopartsthatmustbe
usedtogethertoaddsomevaluetotheactor
104
Usecasedrawingguide
> Usedifferentusecasediagramstoseparateusecasesin
alogicalway
> Groupusecasesthatareinitiatedbycommonactors
> Donotputunrelatedusecasesinthesamediagram
> Limitthenumberofusecasesperdiagramto10
52
30.10.2011
105
UseCaseElaboration
> Duringthemeetingwiththeotherstakeholders,you
will discover manymoreusecasesthatyoucanaddto
thediagram.
> Youmightalsofindthatsomeusecasesaretoohigh
level.Inthis case,youcanintroducenewusecasesthat
separatethe workflows.
Example:
Becomes:
106
ExpandingHighLevelUseCases
> Typically,managinganentityimpliesbeingableto
Create,(Retrieve),Update,andDeleteanentity(so called,
CRUDoperations).Otherkeywordsinclude:
Maintain
Process
> Otherhighlevelusecasescanoccur.Identifytheseby
analyzingtheusecasescenariosandlookfor significantly
divergentflows.
> Ifseveralscenarioshaveadifferentstartingpoint,these
scenariosmightrepresentdifferentusecases.
53
30.10.2011
107
ExpandingHighLevelUseCases
> Theexpandeddiagram:
108
AnalyzingInheritancePatterns
InheritancecanoccurinUseCasediagramsforbothactors
andusecases:
> Anactorcaninheritalloftheusecaseassociationsfrom
theparentactor.
> Ausecasecanbesubclassed intomultiple,specialized use
cases.
54
30.10.2011
109
ActorInheritance
> Anactorcaninheritalloftheusecaseassociationsfrom
the parentactor.
> Thisinheritanceshouldbeusedonlyifyoucanapplythe
is akindofrulebetweentheactors.
110
UseCaseSpecialization
Ausecasecanbesubclassed intomultiple,specializeduse
cases:
> Usecasespecializationsareusuallyidentifiedby
significantvariationsintheusecasescenarios.
> Ifthebaseusecasecannotbeinstantiated,youmust
markitasabstract.
55
30.10.2011
111
AnalyzingUseCaseDependencies
Usecasescandependonotherusecasesintwoways:
> Oneusecase(a)includesanotherusecase(i).
Thismeansthattheoneusecase(a)requiresthe
behavioroftheotherusecase(i)andalways performs
theincludedusecase.
> Oneusecase(e)canextendanotherusecase(b).
Thismeansthattheoneusecase(e)can(optionally)
extendthebehavioroftheotherusecase(b).
112
TheincludeDependency
> Theincludedependencyenablesyoutoidentifybehaviors
of thesystemthatarecommontomultipleusecases.
> Thisdependencyisdrawnlikethis:
56
30.10.2011
113
> Anincluderelationshipisusedtointegrateausecaseinto
anotherusecase,thus becomingalogicalpartofthatuse
case.
114
Identifyingandrecordingcommonbehavior:
> Reviewtheusecasescenariosforcommonbehaviors.
> GivethisbehavioranameandplaceitintheUseCase
diagramwithanincludedependency.
57
30.10.2011
115
Identifyingbehaviorassociatedwithasecondaryactor:
> Reviewtheusecasescenariosforsignificantbehavior that
involvesasecondaryactor.
116
> Splitthebehaviorthatinteractswiththissecondary actor.
GivethisbehavioraUseCasetitle,andplaceitin theUse
Casediagramwithanincludedependency.
58
30.10.2011
117
TheextendDependency
> Theextenddependencyenablesyoutoidentify behaviors
of thesystemthatarenotpartofthe primaryflow,but
existin alternatescenarios.
> Thisdependencyisdrawnlikethis:
118
TheextendDependency
Identifyingandrecordingbehaviorsassociatedwithan
alternateflowofausecase:
> Reviewtheusecasescenariosforsignificantand cohesive
sequencesofbehavior.
> GivethisbehavioranameandplaceitintheUseCase
diagramwithaextenddependency.
59
30.10.2011
119
ACombinedExample
120
extendorinclude
60
30.10.2011
121
PackagingtheUseCaseViews
> Itshouldbeapparentthatanynontrivialsoftware
developmentwouldneedmoreusecasesthancouldbe
viewedatonetime.Therefore,youneedtobeableto
manage thiscomplexity.
> Onewayofmanagingthiscomplexityistobreakdownthe
usecasesintopackages.
122
61
30.10.2011
123
> Youcanlookinsideeachpackagetorevealthedetailed
content.
> Ausecaseelementmayexistinmultiplepackages, where
itparticipatesinmultipleviews.
124
> Adiagramconsistsofanareawithinarectangleanda
headerintheupperleftcorner.Thediagramheader
shows thediagramtype(optional),thediagramname
(mandatory),andparameters (optional).
62
30.10.2011
125
126
TheMetamodel forUsecasesandActors
63
30.10.2011
3
Creating
Use Case Scenarios
and Forms
UML2&UseCaseModels 3 CreatingUC Scenarios&Forms
128
ProcessMap
64
30.10.2011
129
BlackBoxUseCases
> Blackboxusecasesarethemostcommonand
recommendedkind;
> Theydonot describetheinternalworkingsofthesystem,
itscomponents,ordesign.
> Thesystemisdescribedashavingresponsibilities,whichis
acommonunifying metaphoricalthemeinobject
orientedthinking
Blackboxstyle
Not
Thesystemrecordsthesale. Thesystemwritesthesaletoadatabase.
...or(evenworse):
ThesystemgeneratesaSQLINSERT
statementforthesale...
130
FormalityTypes
> Usecasesarewrittenindifferentformats,dependingon
need.Inadditiontothe blackboxversuswhitebox
visibilitytype,usecasesarewritteninvarying degreesof
formality:
briefterseoneparagraphsummary,usuallyofthe
mainsuccessscenario.
casualinformalparagraphformat.Multiple
paragraphsthatcovervariousscenarios.
fullydressedthemostelaborate.Allstepsand
variationsarewrittenin detail,andthereare
supportingsections,suchaspreconditionsandsuccess
guarantees.
65
30.10.2011
131
Theusecases.org Format
> Variousformattemplatesareavailableforfullydressed
usecases.
> However,perhaps themostwidelyusedandshared
formatisthetemplateavailableat www.usecases.org.
132 P
Analysis
Usecasedescription
TheUseCaseusuallycontainsthefollowingcomponents:
> Name
Averb/nounthatsatisfiesamajorgoalfortheactor
> Description
Onesentencedescribingwhatthisusecaseisabout
> PreConditions
Condition(s)whichmustbesatisfiedbeforetheusecasecantakeplace
> PostConditions
Thestateinwhichthesystemwillbeattheendoftheusecase
> CourseofAction
Describesthemostconventionalflowofeventsthroughtheusecase
> AlternativeFlows
Describelesscommonflowsthroughtheusecase
> ExceptionFlows
Describeflowswhereerrorshaveoccurredandhowtorecover
66
30.10.2011
133
TheTwoColumnVariation
> Somepreferthetwocolumnorconversationalformat,
whichemphasizesthe factthatthereisaninteraction
goingonbetweentheactorsandthesystem.
> It wasfirstproposedbyRebeccaWirfsBrock,andisalso
promoted byConstantineandLockwoodtoaidusability
analysisandengineering.
134
TheTwoColumnVariation
67
30.10.2011
135
TheBestFormat?
> Thereisntonebestformat;someprefertheonecolumn
style,somethetwocolumn.
> Sectionsmaybeaddedandremoved;headingnamesmay
change.
> Noneof thisisparticularlyimportant;thekeythingisto
writethedetailsofthemain successscenarioandits
extensions,insomeform.
136
RecordingUseCaseScenarios
> AUseCasescenarioisaconcreteexampleofausecase.
> AUseCasescenarioshould:
Beasspecificaspossible
Nevercontainconditionalstatements
Beginthesamewaybuthavedifferentoutcomes
Notspecifytoomanyuserinterfacedetails
Showsuccessfulaswellasunsuccessfuloutcomes(in
differentscenarios)
> UseCasescenariosdriveseveralotherOOADworkflows.
68
30.10.2011
137
SelectingUseCaseScenarios
> Whileitisidealtohavemultiplescenariosforalluse
cases, doingsowouldtakealotoftime.Therefore,you
canselect appropriatescenariosbythefollowingcriteria:
Theusecaseinvolvesacomplexinteractionwiththe
actor.
Theusecasehasseveralpotentialfailurepoints,such
asinteractionwithexternalsystemsoradatabase.
> Therearetwotypesofscenarios:
Primary(Happy)scenariosrecordsuccessfulresults.
Secondary(Sad)scenariosrecordfailureevents.
138
WritingaUseCaseScenario
AUseCasescenarioisastorythat:
> Describeshowanactorusesthesystemandhowthe
systemrespondstotheactionsoftheactor.
> Hasabeginning,amiddle,andanend.
69
30.10.2011
139
PrimaryUseCaseScenario:Example
> Thebeginning:
Theusecasebeginswhenthebookingagentreceivesa
request tomakeareservationforroomsinthehotel.
140
> Themiddle:
Thebookingagententersthearrivaldate,thedeparture
date, andthequantityofeachtypeofroomthatis
required.The bookingagentthensubmitstheentered
details.Thesystem findsroomsthatwillbeavailable
duringtheperiodofthe reservationandallocatesthe
requirednumberandtypeof roomsfromtheavailable
rooms.Thesystemrespondsthatthe specifiedroomsare
available,returnstheprovisional reservationnumber,
andmarksthereservationasheld.The bookingagent
acceptstheroomsoffered.
70
30.10.2011
141
> Moreofthemiddle:
Thebookingagentselectsthatthecustomerhasvisited
oneof thehotelsinthisgroupbefore,andentersthezip
codeand customername.Thesystemfindsandreturnsa
listofmatching customerswithfulladdressdetails.The
bookingagentselects oneofthecustomersasbeingthe
validcustomer.Thesystem assignsthiscustomertothe
reservation.Thebookingagent performsapayment
guaranteecheck.Thischeckissuccessful.
142
> Theend:
Thesystemassignsthepaymentguaranteetothe
reservation andchangesthestateofthereservationto
confirmed.The systemreturnsthereservationIDand
bookingdetails.
71
30.10.2011
143
SecondaryUseCaseScenario:Example
> Thebeginning:
Theusecasebeginswhenthebookingagentreceivesa
request tomakeareservationforroomsinthehotel.
> Themiddle:
Thebookingagententersthearrivaldate,thedeparture
date, andthequantityofeachtypeofroomthatis
required.The bookingagentthensubmitstheentered
details.Thesystem respondsthattherearenorooms
availableofanytypeforthe daterangespecifiedinthe
request.
> Theend:
Theusecaseends.
144
SupplementarySpecifications
> Someoftheprojectinformationthatyougathercannot
be storedwiththeusecasesbecausethisinformation
needstobe sharedbyseveralusecases.
> Thisadditionalinformationcanbedocumentedina
SupplementarySpecificationDocument,whichoften
contains:
NFRs
ProjectRisks
ProjectConstraints
GlossaryofTerms
72
30.10.2011
145
NonFunctionalRequirements(NFRs)
> Nonfunctionalrequirements(NFRs)definethe qualitative
characteristicsofthesystem.Asinan animal,theNFRs
describestrength,speed,andagility oftheinternal
featuresoftheanimal.Howfastcanthe animalmove?
Howmuchweightcantheanimalcarry?
> AnyadverbialphrasecanbeanNFR.
146
NFRs:Examples
> NFR1:Thesystemmustsupport200simultaneoususers
intheWebapplication.
> NFR2:Theprocessforcompletinganyreservation
activitymusttaketheaverageusernomorethan10
minutestofinish.
> NFR3:Thecapacityofreservationrecordscouldgrowto
2,600permonth.
> NFR4:TheWebaccessshouldusetheHTTPStransport
layerwhencriticalcustomerinformationisbeing
communicated.
> NFR5:Thenumericalaccuracyofallfinancialcalculations
(forexample,reportsandcustomerreceipts)should
followa2significantdigitprecisionwithstandard
roundingofintermediateresults.
73
30.10.2011
147
NFRs:Examples
> NFR6:TheSystemmustbeavailable7by24by365.
However,theapplicationscanbeshutdownfor
maintenanceonceaweekforonehour.Thismaintenance
activityshouldbescheduledbetween3a.m.and6a.m.
> NFR7:Basedonhistoricalevidence,thereare
approximately600reservationspermonthpe property.
> NFR8:Thesearchforavailableroomsmusttakenolonger
than30seconds.
148
GlossaryofTerms
> TheGlossaryofTermsdefinesbusinessorITtermsthat
will beusedintheproject.
> Thisisalivingdocument,whichshouldbeappendedwith
newterms,oramendedifatermisfoundtobeincorrect
or needsredefinition.
74
30.10.2011
149
GlossaryofTerms:Examples
150
DescriptionofaUseCaseForm
> AUseCaseformprovidesatooltorecordthedetailed
analysisofasingleusecaseanditsscenarios.
75
30.10.2011
151
152
76
30.10.2011
153
> Somemethodologiesrecommendmoreorlessanalysisof
the usecases.TheAnalysisworkflowpresentedinthis
module tendstobemoredetailed.
> UseCaseformsarenotstandard.Therearedifferent
styles thatcanbeusedtocreateaUseCaseform.
154
CreatingaUseCaseForm
StepstodeterminetheinformationforUseCaseform:
1. Determineabriefdescriptionfromtheprimary
scenarios.
2. Determinetheactorswhoinitiateandparticipateinthis
usecasefromtheUseCasediagrams.
3. Determinethepriorityofthisusecasefromdiscussions
withthestakeholders.
4. Determinetheriskfromscenariosandfromdiscussions
withthestakeholders.
5. DeterminetheextensionpointsfromtheUseCase
diagrams.
6. Determinethepreconditionsfromthescenarios.
7. Determinethetriggerfromthescenarios.
77
30.10.2011
155
CreatingaUseCaseForm
8. Determinetheflowofeventsfromtheprimary(happy)
scenarios.
9. Determinethealternateflowsfromthesecondary(sad)
scenarios.
10. Determinethebusinessrulesfromscenariosand from
discussionswithstakeholders.
11. Determinethepostconditions.
12. DeterminethenewNFRsfromdiscussionswith
stakeholders.
13. Addnotesforinformationgatheredfromdiscussions
withstakeholdersthatdoesnotfitintothestandard
sectionsoftheform.
156
FillinValuesfortheUseCaseForm
> Fillinelementsderivedfromstakeholdersandprevious
artifacts
78
30.10.2011
157
158
79
30.10.2011
159
FillinValuesfortheAlternateFlowof Events
> Determinethealternateflowsfromthesecondary
scenarios andremainingprimaryscenarios:
> Performadifferenceanalysisbetweenthescenarioused
forthemainflowandeachoftheotherscenarios(in
turn).
> Thealternateflowsarethestepsthataredifferent
betweenthescenariousedforthemainflowandeach of
theotherscenarios.
160
80
30.10.2011
161
162
FillinValuesfortheBusinessRules
81
30.10.2011
AppendixA
Improving
RequirementQuality
UML2&UseCaseModels A ImprovingRequirementQuality 164
Objectives
Whenyoucompletethismodule,youshouldbeableto:
Knowthebestpracticewhenwritingrequirements
Avoidcommonpitfalls
Critiqueindividualrequirements
82
30.10.2011
Characteristicsofagoodrequirement
Design-free
Consistent
Complete
Individual
Verifiable
Identified
Modular
Positive
Correct
Unique
Clear
Traceable
Feasible
Positive
Modular
Traceable
Consistent
Feasible
Clear
Correct
Unique
Design-free
Verifiable
Complete
Individual
Identified
Anatomyofagoodstakeholderrequirement
Usertype
Performancecriteria
Positiveendresult
TheInternetusershallbeabletoaccesstheircurrentaccount
balanceinlessthan5seconds.
Measurable
Thechallengeistoseekouttheusertype,endresult,andsuccess
measureineveryrequirementthatyoudefine.
r572
83
30.10.2011
Writingpitfallstoavoid
or
andsoon
shallincludebutnotbelimitedto
Example:
Thepilotorcopilotshallalsobeabletohearor
seeavisibleoraudiblecautionorwarningsignal
incaseofemergency,hazard,andsoon
Improvements:
Ambiguity
Writingpitfallstoavoid(cont.)
Each requirement is a single sentence

Conjunctions
and , or. , with , also
Example:
Theusershallbenotifiedwithalowbattery
warninglamplightwhenthevoltagedropsbelow
3.6Voltsandthecurrentworkspaceorinputdata
shallbesaved.
Improvements:
Ambiguity
84
30.10.2011
let out clauses

if , but , when , except
unless , although.
Example:
Thehomeownershallalwayshearthesmokedetector
alarmwhensmokeisdetectedunlessthealarmisbeing
testedorsuppressed.
Improvements:
Ambiguity
Long sentences
Arcane language
References to unreachable documents
Example:
Improvements:
Providedthatthedesignatedinputsignalsfromthe
specifieddevicesarereceivedbytheuserinthecorrect
orderwherethesystemisabletodifferentiatethe
designators,theoutputsignalshallcomplywiththe
requiredframeworkofsection3.1.5toindicatethe
desiredinputstate.
Ambiguity
85
30.10.2011
Mix user, system, design, test, and installation

High-level mixed with database design, software
terms, technical terms
Example:
Theusershallbeabletoviewthecurrentlyselected
channelnumber,whichshallbedisplayedin14ptSwiss
typeonanLCDpaneltestedtoFederalRegulation
Standard56789andmountedwithshockproofrubber
washers.
Improvements:
Ambiguity
Specify design envelope for level required
Name components, materials, software objects,

fields, and records in stakeholder or system
requirements
Example:
TheantennashallbecapableofreceivingFMsignals,
usingacoppercorewithnyloncoveringanda
waterproofhardenedrubbershield
Improvements:
Ambiguity
86
30.10.2011
Wish lists
Vague about which stakeholder is speaking
usually , generally , often ,
normally , typically
Example:
Thealarmsystemwillprobablyhavetooperateover
normalphonelines.
Improvements:
Ambiguity
Qualitative terms
User friendly, highly versatile, and flexible
To the maximum extent, approximately, as much as
possible, with minimal impact.
Example:
Theusershallbeprovidedwithauserfriendlyfront
end.
Improvements:
Ambiguity
87
30.10.2011
Suggestions will be ignored by developers
May, might, should, ought, could, perhaps, or

probably
Example:
Thenetworkmanagermaybeprovidedwithpossible
networkcontentionpoints,andshouldinstantaneously
reroutethetraffic.
Improvements:
Ambiguity
Ask for the impossible

100% reliable, safe, handles all failures, fully
upgradeable, and runs on all platforms
Example:
Thenetworkmanagershallhandleallunexpected
errorswithoutcrashingthesystem,andbefullycapable
ofmanagingfuturenetworkconfigurations.
Improvements:
Ambiguity
88
30.10.2011
AppendixB
PracticalExercise
UML2&UseCaseModels B PracticalExercise
178
1. TheATMusershallbeallowedtowithdrawmoneyandbe
abletomakeapaymenttoanyoutstandingloan.
2. TheATMusershallbeallowedtowithdrawuptothecurrent
accountbalanceamountintheselectedaccount,the
maximumamountavailableforwithdrawal,oruptothe
maximumlineofcreditfortheaccount.
3. TheATMshallbeabletodisplayallpromptsintheEnglish
languageandotherlanguagesincluding,butnotlimitedto,
Spanish,French,andGerman.
4. ThepriceoftheATMshallnotexceed$30,000andallowthe
maintainertorequestanotificationbepostedtoindicateto
allATMusersthatthesystemisabouttobecome
unavailable.
5. OftenanATMusermayusuallyperformmultipletransactions
duringasingleaccountsession.
89
30.10.2011
179
6. TheATMshallprobablyhavetoaccessthebankprovider
systemtodeterminewhattransactionsarevalidforthis
user.
7. TheATMusermayprobablywishtomakeapaymentonany
outstandingloan.
8. TheATMshallbeabletoprovidefoolproofidentificationof
allATMuserstopreventanyunauthorizedaccesstoausers
account.
9. TheATMusershallbeabletoviewthecurrentaccount
balanceafteranupdatewithin5seconds.
10. TheATMshallnotifytheuseroftheclosestATMtothe
currentunitintheeventthatthecurrentunitisoutofcash.
180
Foreachpotentialusecase,determinewhetherit
isausecase
Have system 100% available
during regular business hours
Comply with SOX
Support English and Japanese
Display error messages within 30

seconds
Login
Transfer funds
Make reservation
Withdraw cash from an ATM
Place order
Create customer user interface
Support IE7.0
Support LDAP authentication
90
30.10.2011
181
TheprimaryUseCases fortheSampleBankATM
182
SupportingUseCases fortheSampleBankATM
Refill and Service the Machine
ATM Engineer
Configure the Machine

Check the Machine is in Working
Order
Analyze System Performance

ATM Operator
Reconcile Transaction Logs
Update System Configuration
Service
Administrator
Run Advertising Compaign
91
30.10.2011
183
renciOtomasyon
Sistemi
<<actor>>
Veritaban
Gekayt
<<extend>>
Danman
Snflistesi
gster
Sistemegiri
<<include>>
<<include>>
Dersekayt
Kullanc
retmen
renci
AppendixC
LectureNotesinTurkish
92
30.10.2011
UML2&UseCaseModels C LectureNotesinTurkish
185
UMLNedir
> UMLyazlmsistemininnemlibileenlerinitanmlamay,
tasarlamayvedokmantasyonunusalayangrafikselbir
modellemedilidir
> Yazlmgelitirmesrecindekitmkatlmclarn(kullanc,i
zmleyici,sistemzmleyici,tasarmc,programc,...)
gzylemodellenmesineolanaksalar,
> UMLgsteriminesneyedayalyazlmmhendisliinedayanr.
186
Ortakbirdil
>
>
>
>
dx
Tmmhendisler simgesininanlamnbilir
Simgebasitolsadaarkasndakianlamkarmakvederindir!
:Terssekiz?
Kapasite?
C
93
30.10.2011
187
UMLinKazanmlar
> Yazlmsistemiherhangibirkodyazmadannce
profesyonelcetasarlanrvedokmantasyonuyaplr
> Yenidenkullanlabilirkodparalar kolaylkla ayrtedilirve en
yksekverimlekodlanr
> Dahadkgelitirmemaliyeti
> Tasarmdakimantksal boluklar tasarmizimlerinde
kolaylklasaptanabilir
188
UMLinKazanmlar2
> Dahaazsrpriz yazlmlarbeklendiimizekildedavranrlar
> Overalldesignwilldictatethewaysoftwareisdeveloped tm
tasarmkararlarkodyazmadanverilir
> UMLresmintamamngrmemizisalar
> Morememoryandprocessorefficientcodeisdeveloped
> Sistemdedeiiklikyapmaykolaylatrr
94
30.10.2011
189
UMLinKazanmlar3
> Lessre/learningofthesystemtakesplace
> Diagramswillquicklygetanyotherdeveloperuptospeed
> Programclararasndadahaetkinbiriletiimeolanaksalar
190
UMLin Gelitirme Srecindeki Yeri

> ThreeAmigosUMLigelitirirken,dilinbelirlibirsremodeline
balolmamasnazengsterdiler.
> Farklsremodelleri:RUP,ShlaerMellor,CRCveExtreme
Programmingkullanlabilir.
> RUP:ThreeAmigostarafndangelitirildi.
> DersteRUPuinceleyeceiz
> BunedenleUMLfarklyazlmprojelerinecevapverebilecek
genelliesahiptir:
ETicaretUygulamas AskeriUygulamalar
Dokmantasyon,Snama,Performans
> UMLnaslyazlmgelitirileceinisylemez!
95
30.10.2011
191
Hatrlatma
> SreYnetimikonusunaksabirgeridnyapalm:
> elaleModeli
> VModeli
> SpiralModel
> ArtmsalveYinelemeliModeller
192
elaleModeli
Kkprojeleriinuygun
Birkaaylkprojeler
BigBangEtkisi
96
30.10.2011
193
elaleModelininYitimleri
Risk
Hatay
Dzeltmenin
Maliyeti
Zaman
194
SprilModel
97
30.10.2011
195
SpiralModelin Kazanmlar
>
>
>
>
>
>
Takmyazlmyaamevriminintmaamalarnakatlr,
Ksasredevedzgnaralklarlageribeslemealnr,
Risklibileenlerncedenkestirilebilirvegereklenebilir,
inleivekarmaklncedenkefedilebilir,
alanbirsrmnvarltakmnmoraliniyksektutar,
Projenindurumudahakesinolarakdeerlendirilebilir.
196
RUP
> RUPyinelemli,artmsal,mimarimerkezli,riskgdml,
kullanmsenaryolarnadayalbiryazlmgelitirmesreci
modelidir.
> RUPiyitanmlanmveyaplandrlmbiryazlmsrecidir:
KiminNedensorumluolduu,ilerinNaslveNeZaman
yaplacaakatanmlanr.
98
30.10.2011
197
Kullanm Senaryosu emas

> Kullanmsenaryosuemas,tasarlanacaksistemekullanc
gzylebakldndakidavranntanmlar.
> emannanlalmasoldukakolaydr.
> [Bunedenle]Hemgelitirmeekibininhemdemterininortak
olarakalabileceibiremadr.
> Analizdeyardmcolur,tasarmdaisteklerinanlalmasnda
yardmcolur.
Customer
(f rom Actors)
Barrow Book
(from <Use Case Name>)
aktr
198
Kullanm Senaryosu emasnn Bileenleri
99
30.10.2011
199
KullanmSenaryosuemas
> Biraktrbirdenfazlakullanm
senaryosundayeralabilir
> Aynsenaryodabirdenfazlaaktr
olabilir.
Start Up
Shutdown
Operator
(from <Use Case Na me >)
(f rom Actors)
Produce Report
Order System
(f rom Actors)
View Order Statu s

200
Actor
>
>
>
>
>
Aktreylemibalatannesnedir.
Aktrnesnesimutlakabirkiiolmakzorundadeil.
Soyutbirnesneolabilir:zaman,tarih,...
Aktrsistemindndanbirnesneolabilir
KullanlanSimge:
Start Up
Operator
(f rom Actors)
> Heraktrenazbirsenaryoile
ilikilendirilmelidir:
Operator
(f rom Actors)
Shutdown
Produce Report
100
30.10.2011
201
Kullanm Senaryolarnn Salad Kazanmlar

> Sisteminerimini,snrlarnbelirler.
> Byleliklegelitirileceksisteminboyutunuvekarmakln
kafamzdadaharahatcanlandrabiliriz.
> Kullanmsenaryolaristeklerinzmlenmesineok
benzemektedir:dahanettirvetamdr.
> Basitoluumteriilegelitirmeekibiarasndailetiimeolanak
tanr.
> Gelitirmeaamasiintemeloluturur.
> Sistemtestiiintemeloluturur.
> Kullancklavuzuhazrlamayayardmcolur.
202
znrlkNeOlmal?
> Kullanmsenaryosununkullanmnailikinbirrnek:ATM
cihazndanparaekmek
Enter Card
Enter PIN
Remove Card
Customer
(f rom Actors)
Select Amount
Confirm Amount
Take Receipt
101
30.10.2011
203
zm
> Kullanm senaryosu, aktr iin bir amac yerine getirmelidir.
Ama:paraekmek
Customer
(f rom Actors)
Withdraw Money
Check Balance
Customer
(f rom Actors)
204
Withdraw Mone y
Trans fer Mone y

(f rom < Use Case Name>)
102
30.10.2011
205
Kullanm Senaryolar Aras likiler

> Kullanmsenaryolararasndatrilikibulunabilir
> ermeinclude
Birsenaryogrubuiindekullanlanbakabirsenaryogrubudur
> Geniletmeextend
Senaryogruplardoalakagreverilirler.Buaktanolan
sapmalargeniletmeilikisiileanasenaryodanolansapma
gsterilir.
> Genelletirme
Snflararasndakitremeilikisinebenzer.Genelbirsenaryo
grubundanzelbirsenaryogrubutretilir.
206
rnek Kullanm Senaryosu

<<include>>
Withdraw Money
Update Accoun t
Custom er
<<extend>>
(f rom Actors)
Withdraw Money with Overdraft

Protection
Protect Overdraft
(f rom < Use Case Name>)
103
30.10.2011
207
Kullanm Senaryosu Anlatm

1.MterikartnATMcihaznatantr.Sistemkarttakibilgileriokurve
dorular.
2. SistemPINkodunusorar.MteriPINkodunugirer.SistemiPINkodunu
dorular.
3. Sistemhangitrilemyapmakistediinisorar.Mteri Paraekiseer
4. Sistemekilecekmiktarsorar.Mterimiktargirer.
5. Sistemhesaptrnsorar.Mterihesaptrngirer.
6. SistemATMankullanarakkimlik,PINkoduveekilenmiktardorular.
7. Sistemmakbuzistenipistenmediinisorar.Builemcihazdakatvarsa
yrtlr.
8. Sistemmteridenkartyuvasndanalmasnister.Mterikartnalr.(Bu
istek mterininkartcihazdaunutmadndaneminolmakiingvenlik
amacylayaplr.)
9. Sistemistenilenmiktarbanknotuverir.
10.Eermteriistemisesistemkatmakbuzuverir. Senaryosonaerer.
208
KullanmSenaryosuAnlatm
Standartbirformatyok.
Herfirmakendineuygunbirformatbelirleyebilir.
Senaryo:Senaryoad
zettantm:Senaryonunksabirtanmlamas
nkoullar:Senaryonunbalamasiinsalanmas
gerekenkoullar
Sonukoullar:Senaryonunsonundanelerolduu
tanmlanr
AnaAk: Sistemiinolaansenaryodurumunda
gerekleenetkileimlerinbirlistesiverilir.
AlternatifAk: Olasalternatifetkileimlerintanmlanmas
SradAk: Beklenmeyenyadangrlmeyenolaylarn
gerekletiisenaryolartanmlanr
104
30.10.2011
209
KullanmSenaryolarnnYazlmas
AktrlerinBelirlenmesi:
Sistemintemelilevlerinikimkullanacak?
Sisteminbakmnveiletiminikimyapacak?
Sistemhangicihazlarkullanacak?
Dierhangisistemlerleetkileimdebulunacak?
Sisteminklarnkimleriilgilendirir?
210
Sistem Davrannn Belirlenmesi

Aktrlerdenyararlanaraksistemdavrannnbelirlenmesi
Aktrlerintemelilevinedir?
Aktrsistembilgilerineerimelimi?
Durumdeiiklikleriaktrebildirilecekmi?
Aktrhangiilevlereihtiyaduyar?
Bazdavranlaraktrlerdenyolakarakbelirlenemeyebilir.Bu
durumdaaadakisorulardasormakuygunolur:
Sistemingerekduyduugiriveknedir?
Sistemdolaylardanetkilenir?
uandakisistemineksiklikleriveproblemlerinelerdir?
Periyodikolarakgerekletirilenilemlervarm?
105
30.10.2011
211
Kullanm Senaryolarnn Saptanmas

Olassistemkullanclarilegrmeyapmak
JointRequirementsPlanningWorkshop(JRP)
Beyinfrtnas:olastmaktrlersaptanr
Beyinfrtnas:olastmsenaryolarsaptanr
HersenaryoiinKullanmSenaryoAnlatmkadaaktarlr
vedorulanr
ModelCASEToolkullanlarakbilgisayardaoluturulur
106

Uml2 and Use Case Model Ver 0 0 4

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Uml2 and Use Case Model Ver 0 0 4

Diunggah oleh

Hak Cipta:

Format Tersedia

30.10.

References UML2, Use Cases

References Use Cases

public class Book {

TheMetamodel ofUML 2.0

Ama: Mal satn almak

Ama: Sat yapmak

> Ausecaseencapsulatesamajorpieceofsystem behavior

> Anactormustbeassociatedwithoneormoreuse cases.

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels 3 CreatingUC Scenarios&Forms

UML2&UseCaseModels A ImprovingRequirementQuality 164

UML2&UseCaseModels A ImprovingRequirementQuality 165

UML2&UseCaseModels A ImprovingRequirementQuality 166

UML2&UseCaseModels A ImprovingRequirementQuality 167

UML2&UseCaseModels A ImprovingRequirementQuality 168

Each requirement is a single sentence

UML2&UseCaseModels A ImprovingRequirementQuality 169

let out clauses

UML2&UseCaseModels A ImprovingRequirementQuality 170

UML2&UseCaseModels A ImprovingRequirementQuality 171

Mix user, system, design, test, and installation

UML2&UseCaseModels A ImprovingRequirementQuality 172

Name components, materials, software objects,

UML2&UseCaseModels A ImprovingRequirementQuality 173

UML2&UseCaseModels A ImprovingRequirementQuality 174

UML2&UseCaseModels A ImprovingRequirementQuality 175

May, might, should, ought, could, perhaps, or

UML2&UseCaseModels A ImprovingRequirementQuality 176

Ask for the impossible

Comply with SOX