Analysis modeling & scenario based modeling

This slide describes the concepts are Analysis Modeling & Scenario-Based Modeling in Object-oriented software engineering

1. ANALYSIS

2. Modeling
•Wecreatemodelstogainabetterunderstandingofthe
actualentitytobebuilt.Whentheentityisaphysical
thing(e.g.,abuilding,aplane,amachine),wecanbuilda
modelthatisidenticalinformandshapebutsmallerin
scale.
•Insoftwareengineeringwork,twoclassesofmodelscan
becreated:requirementsmodelsanddesignmodels.
Requirementsmodels(alsocalledanalysismodels)
•Representcustomerrequirementsbydepictingthe
softwareinthreedifferentdomains:theinformation
domain,thefunctionaldomain,andthebehavioral
domain.
Designmodelsrepresentcharacteristicsofthesoftware
thathelppractitionerstoconstructiteffectively:the
architecture,theuserinterface,andcomponent-level
detail.

3. Requirements Modeling/
Analysis Modeling
•Requirementsmodelinginsoftwareengineeringis
essentiallytheplanningstageofasoftwareapplicationor
system.
•Generallytheprocesswillbeginwhenabusinessoranentity,
forexampleaneducationalinstitution,approachesa
softwaredevelopmentteamtocreateanapplicationor
systemfromscratchorupdateanexistingone.
•Requirementsmodelingcomprisesseveralstagesor
'patterns':scenario-basedmodeling,datamodeling,flow-
orientedmodeling,class-basedmodelingandbehavioral
modeling.
•Eachofthesestages/patternsexaminesthesameproblem
fromadifferentperspective.

4. Why Requirements Modeling/
Analysis Modeling?
•Attempttoproducethesimplestmodelthatwill
describetheproblemorthesoftware.
•Buildmodelsinawaythatmakesthemamenableto
change.
•Beabletostateanexplicitpurposeforeachmodel
thatiscreated:Everytimeyoucreateamodel,ask
yourselfwhyyou’redoingso.
•Adaptthemodelsyoudeveloptothesystemat
hand.
•Getfeedbackassoonasyoucan.

5. Requirements Modeling principles /
Analysis Modeling principles.
•Principle1.Theinformationdomainofa
problemmustberepresentedand
understood.
–Theinformationdomainencompassesthedata
thatflowintothesystem(fromendusers,other
systems,orexternaldevices),thedatathatflow
outofthesystem(viatheuserinterface,network
interfaces,reports,graphics,andothermeans),
andthedatastoresthatcollectandorganize
persistentdataobjects(i.e.,datathatare
maintainedpermanently).

6. Requirements Modeling principles /
Analysis Modeling principles.
•Principle2.Thefunctionsthatthesoftware
performsmustbedefined.
–Softwarefunctionsprovidedirectbenefittoendusers
andalsoprovideinternalsupportforthosefeatures
thatareuservisible.Somefunctionstransformdata
thatflowintothesystem.Inothercases,functions
effectsomelevelofcontroloverinternalsoftware
processingorexternalsystemelements.Functionscan
bedescribedatmanydifferentlevelsofabstraction,
rangingfromageneralstatementofpurposetoa
detaileddescriptionoftheprocessingelementsthat
mustbeinvoked.

7. Requirements Modeling principles /
Analysis Modeling principles.
•Principle 3. The behavior of the software (as a
consequence of external events) must be
represented.
–The behavior of computer software is driven by its
interaction with the external environment. Input
provided by end users, control data provided by an
external system, or monitoring data collected over a
network all cause the software to behave in a specific
way.

8. Requirements Modeling principles /
Analysis Modeling principles.
•Principle4.Themodelsthatdepictinformation,
function,andbehaviormustbepartitionedina
mannerthatuncoversdetailinalayered(or
hierarchical)fashion.
•Principle 5. The analysis task should move from
essential information toward implementation
detail.

9. What is Requirements analysis /
Analysis modeling
•Requirementsmodelingusesacombinationoftextand
diagrammaticformstodepictrequirementsinawaythat
isrelativelyeasytounderstand,andmoreimportant,
straightforwardtoreviewforcorrectness,completeness,
andconsistency.
•Whodoesit?
–Asoftwareengineer(sometimescalledan“analyst”)
buildsthemodelusingrequirementselicitedfromthe
customer.
•Whyisitimportant?
–Tovalidatesoftwarerequirements,youneedto
examinethemfromanumberofdifferentpointsof
view.

10. Analysis modeling
•Analysis modeling
focuses on three
attributes of
software:
–information to be
processed
–function to be
delivered
–behavior to be
exhibited.
Itgivesthe
situation to
discoverwhatthe
problemreallyis

11. Requirements analysis /
Analysis modeling
•Requirementsanalysisresultsinthespecificationof
software’soperationalcharacteristics,indicates
software’sinterfacewithothersystemelements,
andestablishesconstraintsthatsoftwaremust
meet.
•Requirementsanalysisallowsyou(regardlessof
whetheryou’recalledasoftwareengineer,an
analyst,oramodeler)toelaborateonbasic
requirementsestablishedduringtheinception,
elicitation,andnegotiationtasksthatarepartof
requirementsengineering.

12. Requirements analysis /
Analysis modeling
•Thesemodelsprovideasoftwaredesigner
withinformationthatcanbetranslatedto
architectural,interface,andcomponent-level
designs.
•Finally,therequirementsmodel(andthe
softwarerequirementsspecification)provides
thedeveloperandthecustomerwiththe
meanstoassessqualityoncesoftwareisbuilt.

13. Types of Requirements analysis /
Analysis modeling
(It is the first technical representation of systems)
•Scenario-basedmodelsofrequirementsfromthepointof
viewofvarioussystem“actors”
•Datamodelsthatdepicttheinformationdomainforthe
problem
•Class-basedmodelsthatrepresentobject-orientedclasses
(attributesandoperations)andthemannerinwhichclasses
collaboratetoachievesystemrequirements
•Flow-orientedmodelsthatrepresentthefunctionalelements
ofthesystemandhowtheytransformdataasitmoves
throughthesystem3
•Behavioralmodelsthatdepicthowthesoftwarebehavesasa
consequenceofexternal“events”.
–ThemostcommonmethodforcreatingthesediagramsisUML,
UnifiedModelingLanguage.

14. Elements/Types of Requirements analysis /
Analysis modeling

15. Scenario-based Modeling
•Forthebuildingofanalysisanddesignmodels,itis
essentialforsoftwareengineerstounderstandhowend
usersandotheractorswanttointeractwiththesystem.
•itidentifiesthepossibleusecasesforthesystemand
producestheusecasediagram,towhichalltheother
stagesofrequirementsmodelingrefer.
•AnalysisModelingwithUMLbeginswiththecreationof
scenariosintheform:
•Use-casesText
•Use-casesdiagrams
•ActivityDiagrams
•SwimlaneDiagrams

16. Usecase
•Theusecaseisessentiallyaprimaryexampleof
howtheproposedsoftwareapplicationor
systemismeanttobeused,fromtheuser's
pointofview.Ausecasediagramwilltypically
showsystem'actors'(humansorotherentities
externaltothesystem)andhowtheyinteract
withthesystem.Technically,eachactionsucha
systemactorcanperformwiththeapplication
orsystemisconsideredtobeaseparateuse
case.
•Usecasecanberepresentedin2waysas
usecasetextandusecasediagram.

17. Use-cases Text
•Thefirststepindefiningausecaseistodefinethename,
usingtheverb-nounnamingconvention.
Sample Use Case Brief
•Use Case Name: Place Order
•Actors:
–Shopper
–Fulfillment System
–Billing System
•UseCaseDescription:Aftertheuserhasselecteditemsto
purchaseandthenordertheitems.Theuserwillprovide
paymentandshippinginformation.Thesystemwillrespond
withconfirmationoftheorderandatrackingnumberthat
theusercanusetocheckonorderstatusinthefuture.The
systemwillalsoprovidetheuserwithanestimateddelivery
datefortheorder,whichwillincludeallselecteditems.The
usermayalreadyhaveanaccountwiththecompanywith
billingandshippinginformation.

18. Detail/Formal Use Case Example
•You can clarify the use case further by refining the use case into a formal use case.
Example Usecase
•Use Case Name: Place Order
•Actors:
•Registered Shopper (Has an existing account, possibly with billing and shipping
information)
•Non-registered Shopper (Does not have an existing account)
•Fulfillment System (processes orders for delivery to customers)
•Billing System (bills customers for orders that have been placed)
•Triggers:
•The user indicates that she wants to purchase items that she has selected.
•Preconditions:
•User has selected the items to be purchased.
•Post-conditions:
•The order will be placed in the system.
•The user will have a tracking ID for the order.
•The user will know the estimated delivery date for the order.

19. Detail/Formal Use Case Example
•Normal Flow:
•Theuserwillindicatethatshewantstoordertheitemsthathavealreadybeen
selected.
•Thesystemwillpresentthebillingandshippinginformationthattheuserpreviously
stored.
•Theuserwillconfirmthattheexistingbillingandshippinginformationshouldbeused
forthisorder.
•Thesystemwillpresenttheamountthattheorderwillcost,includingapplicabletaxes
andshippingcharges.
•Theuserwillconfirmthattheorderinformationisaccurate.
•ThesystemwillprovidetheuserwithatrackingIDfortheorder.
•Thesystemwillsubmittheordertothefulfillmentsystemforevaluation.
•Thefulfillmentsystemwillprovidethesystemwithanestimateddeliverydate.
•Thesystemwillpresenttheestimateddeliverydatetotheuser.
•Theuserwillindicatethattheordershouldbeplaced.
•Thesystemwillrequestthatthebillingsystemshouldchargetheuserfortheorder.
•Thebillingsystemwillconfirmthatthechargehasbeenplacedfortheorder.
•Thesystemwillsubmittheordertothefulfillmentsystemforprocessing.
•Thefulfillmentsystemwillconfirmthattheorderisbeingprocessed.
•Thesystemwillindicatetotheuserthattheuserhasbeenchargedfortheorder.
•Thesystemwillindicatetotheuserthattheorderhasbeenplaced.
•Theuserwillexitthesystem.

20. Use-cases diagrams
•IntheUnifiedModelingLanguage(UML),ausecase
diagramcansummarizethedetailsofyoursystem's
users(alsoknownasactors)andtheirinteractionswith
thesystem.
•Createaprofessionaldiagramforanyusecaseusing
UMLdiagramtool.
•Tobuildone,you'lluseasetofspecializedsymbolsand
connectors.
•Aneffectiveusecasediagramcanhelpprojectteamto
discussandrepresent(useofuse-caseModel):
–Representing the goals of system-user interactions
–Defining and organizing functional requirements in a system
–Specifying the context and requirements of a system
–Modeling the basic flow of events in a use case
–Thescopeofyoursystem

21. Use case diagram components
•Actors:Theusersthatinteractwithasystem.An
actorcanbeaperson,anorganization,oran
outsidesystemthatinteractswithyourapplication
orsystem.Theymustbeexternalobjectsthat
produceorconsumedata.
•System:Aspecificsequenceofactionsand
interactionsbetweenactorsandthesystem.A
systemmayalsobereferredtoasascenario.
•Goals:Theendresultofmostusecases.A
successfuldiagramshoulddescribetheactivities
andvariantsusedtoreachthegoal.

22. Example 1

23. Use case diagram symbols and notation
•Usecases:Horizontallyshapedovalsthatrepresentthe
differentusesthatausermighthave.
•Actors:Stickfiguresthatrepresentthepeopleactually
employingtheusecases.
•Associations:Alinebetweenactorsandusecases.In
complexdiagrams,itisimportanttoknowwhichactors
areassociatedwithwhichusecases.
•Systemboundaryboxes:Aboxthatsetsasystemscope
tousecases.Allusecasesoutsidetheboxwouldbe
consideredoutsidethescopeofthatsystem.For
example,PsychoKillerisoutsidethescopeofoccupations
inthechainsawexamplefoundbelow.
•Packages:AUMLshapethatallowsyoutoputdifferent
elementsintogroups.Justaswithcomponentdiagrams,
thesegroupingsarerepresentedasfilefolders.

24. Book publishing use case diagram example

25. Railway reservation use case diagram example

26. Activity Diagrams
•Activitydiagramisanotherimportantdiagramin
UMLtodescribethedynamicaspectsofthe
system.
•Activitydiagramisbasicallyaflowchartto
representtheflowfromoneactivitytoanother
activity.Theactivitycanbedescribedasan
operationofthesystem.
•Thecontrolflowisdrawnfromoneoperationto
another.Thisflowcanbesequential,branched,
orconcurrent.Activitydiagramsdealwithall
typeofflowcontrolbyusingdifferentelements
suchasfork,join,etc

27. Purpose of Activity Diagrams
Activitydiagramisanotherimportantbehaviouraldiagram
inUMLdiagramtodescribedynamicaspectsofthesystem.
Activitydiagramisessentiallyanadvancedversionofflowchart
thatmodellingtheflowfromoneactivitytoanotheractivity.
Activitydiagramcanbeusedfor
oModelingworkflowbyusingactivities.
oModelingbusinessrequirements.
oHighlevelunderstandingofthesystem'sfunctionalities.
oDescribethesequencefromoneactivitytoanother.

28. How to Draw an Activity Diagram?
•Beforedrawinganactivitydiagram,wemusthaveaclear
understandingabouttheelementsusedinactivity
diagram.
•Themainelementofanactivitydiagramistheactivity
itself.Anactivityisafunctionperformedbythesystem.
•Afteridentifyingtheactivities,weneedtounderstand
howtheyareassociatedwithconstraintsandconditions.
•ComponentsofActivityDiagram:
–Activities
–Association
–Conditions
–Constraints

29. Example -order management system
•Theactivitydiagramismadetounderstandtheflowof
activitiesandismainlyusedbythebusinessusers.
•Followingdiagramisdrawnwiththefourmainactivities−
–Sendorderbythecustomer
–Receiptoftheorder
–Confirmtheorder
–Dispatchtheorder
•Afterreceivingtheorderrequest,conditionchecksare
performedtocheckifitisnormalorspecialorder.After
thetypeoforderisidentified,dispatchactivityis
performedandthatismarkedastheterminationofthe
process.

30. Example -order management system

31. Activity diagram can be used for
•Activitydiagramcanbeusedfor−
–Modelingworkflowbyusingactivities.
–Modelingbusinessrequirements.
–Highlevelunderstandingofthesystem's
functionalities.
–Investigatingbusinessrequirementsata
laterstage.

32. Swimlane Diagram
•Aswimlanediagramisatypeofflowchartthatdelineateswho
doeswhatinaprocess.
•Activitydiagramstellyouwhathappens,buttheydonottellyou
whodoeswhat.
•Like a flowchart, it diagrams a process from start to finish, but it
also divides these steps into categories(lanes) to help distinguish
which departments or employees are responsible for each set of
actions.
•Itshowsconnections,communicationandhandoffsbetween
theselanes,anditcanservetohighlightwaste,redundancyand
inefficiencyinaprocess.

33. Why Swimlane Diagrams Are Useful
•Duringanyprocessimprovementinitiative,swimlaneshelpidentifynotjustthe
bottlenecksinaprocess,butalsowhichdepartmentisresponsibleforthem.
•Helpingtoclarifyresponsibilitiesandhelpdepartmentsworktogetherinaworld
wheredepartmentsoftendon'tunderstandwhattheotherdepartmentsdo.
•Youmayfindcostlyredundanciesandduplicationsorgapsandcommunication
problems.
How to Create a Swim Lane Flowchart
•Identifythelanes.Decidewhatdivisionsyouneedrepresentedbyswimlanes
andlabelthem.
•Startyourchart.Definethestartingpointoftheprocess.Addarounded
rectangletothetopoftheappropriateswimlanetoindicateitsstartingpoint
andlabelit.
•Addsteps.Nextaddmorestepstoyourchart.Eachstepshouldbeconnected
totheonebeforeitwithaline.Todrawstepsinthesameswimlane,draw
fromtoptobottom.Toaddastepinanotherdivisiongofromlefttoright.
Witheachstep,describewhatitrepresentsuntilyoureachtheendofthe
process.Thearrowsbetweenthestepsindicatethetransferofinformationor
flow.

34. Example -order management system

35. Swimlane Diagram

36. Example –ATM System