KingSaudUniversityCollegeofComputerandInformationSciences

InformationTechnologyDepartment

SystemAnalysisandDesignGuideGraduationProject1

IT496

PreparedbyHendAlrasheed

halrasheed@ksu.edu.sa

Aug.2019

ThisdocumentisdirectedtotheIT496studentsintheDepartmentofInformationTechnology,KingSaudUniversity.Thegoalistoclarifythetechnicaldetailsrequiredintheirprojectreport.Assumingyouhaveaclearprojectideaandasolidlistofrequirements,thisdocumentfocusesontheSystemAnalysisandDesignchapterofthegraduationreport(Chapter4oftheProject-1Guide).ThisdocumentdoesnotintendtorepeatbasicSoftwareEngineeringconceptsandtechniques(asintroducedintheSoftwareEngineeringcourseIT320).However,thisdocumentshedssomelightonsomeofthemajorandcommonquestionsthatstudentsmayfaceduringtheirgraduationprojects.

2

TableofContents

Overview................................................................................................................................3

Projectscope..........................................................................................................................4

Softwarerequirements..........................................................................................................4

Use-casediagram...................................................................................................................4

Use-cases...............................................................................................................................7

TraditionalorObject-Orientedrequirementsmodeling?.......................................................11

UMLdesigndiagrams............................................................................................................12

ArchitecturalDesign..............................................................................................................12

Componentleveldesign........................................................................................................13

DataFlowDiagrams(DFD).....................................................................................................13

ConceptualModel.................................................................................................................14

ClassDiagram........................................................................................................................15

ERDiagram............................................................................................................................15

WhatisthedifferencebetweenaclassdiagramandanERD?................................................15

Deploymentdiagram.............................................................................................................16

Statediagram–Describesthestatechangesofthesystem...................................................17

Activitydiagram–Representstheactivityflowofthesystem...............................................18

Decisiontables......................................................................................................................18

WhatdiagramsdoIneed?.....................................................................................................19

References:...........................................................................................................................20

3

Overview.Generally,thefirstpartofyourgraduationproject(GP1)willincludethreemajoractivities:

- Understandingthesoftwarerequirements.- Systemanalysisanddesign.- Componentleveldesign.

Eachoftheactivities listedabovehas itsownsetofdeliverables.Thefigurebelowshowsthemost common types of deliverables during each activity. Note that you may not need alldiagrams.Also,youmayneedsomediagramsthatarenotlistedinthediagrambelow.Detailsofeachdiagramwillbeprovidedintherestofthisdocument.

4

Projectscope.Theprojectscopeisthepartoftheprojectinwhichtheteamdeterminesthegeneralgoalsanddeliverablesoftheproject.Hereyoualsomentionwhatwillnotbeincludedintheproject.Whenyouwriteyourscopestatement,makeitSMART(Specific,Measurable,Agreedupon,Realistic,andTimebound).Example:Thisprojectwillconsistofcreatingasoftwaresystemthat……………………Themainobjectiveofthissoftwareisto…………………..Thefollowingfunctionswillbeoutofthescopeofthisproject……………..Theprojectwillbecompletedon…………………

Softwarerequirements.Thesoftwarerequirementslistisadetaileddescriptionofthesoftwaretobedeveloped.Hereyou tell the customerswhat can your system do andwho will use it. Note that the systemrequirementsdonotprovideanydetailsonhowthoserequirementswork.Requirementscanbefunctionalandnon-functional.Functional requirements: a detailed list of the system features and functions. Those are thefunctionsyouwilllaterimplement.Foreachfunction,specifytheinput,theoutput,andthetypeofuser.Foreachfunctionalrequirement,youwillwriteause-case(explainedbelow)toexplainitinmoredetails.Itisagoodideatonumberyourrequirementssoitiseasiertorefertothem.Non-functional requirements: a descriptionof the general characteristics (or qualities) of thesystemsuchasperformance,scalability,security,andmaintainability.

Use-casediagram.Theuse-casediagramshowstheinteractionbetweenthesystemandtheexternalentities(calledactors).Theactorsmaybeusersorothersystems.Inause-casediagram,a(human)user(actor)isusually representedwitha stick figurewith thenameof theactorbelow the figure.Othersystems(thatareexternalandinteractdirectlywiththesystem)arerepresentedwithaboxwiththeword“actor”.Insomespecialcases,Timecanbeanactor.Forexample,whenthesystemisautomatedandtriggeredbytime(thisincludeseventsthatoccureverymonth,everyday,oreveryminute).

5

Thesystemisrepresentedasasetofuse-cases.Eachuse-caserepresentsasinglemeaningfulfunctionthatisobservabletosomeoneorsomethingoutsidethesystem.Inause-casediagram,ause-caseisdenotedbyanellipse.A generalization/specialization relationship (also called inheritance relationship) may existbetweenactorswhenoneactor(thedescendantactor)inheritsthepropertiesofanotheractor(theancestoractor).Thisrelationshipimpliesthatthedescendantactorcanusealltheuse-casesdefinedforitsancestoractor.Similarly,ageneralization/specializationrelationshipmayexistbetweenuse-caseswhenthereisabasicflowofeventsthatisfollowedbymultiplespecialconsiderations.Wecanthinkofthesuperuse-caseasageneralizationofthesubuse-cases.Lookattheexamplebelow.

The sub use-case (or cases) in the specialization/generalization relationship carries theunderlyingbusinessprocessmeaning.Twotypesofadvancedrelationshipsmayexistbetweenuse-cases:the“Include”relationshipandthe“Extend”relationship.The Include relationship: this relationship is usedwhen a use-case contains the processes ofanotheruse-caseaspartofitsnormalflowofactions.

Weassumethatanyincludeduse-casewillbealwayscalledaspartoftheincludinguse-case.Ause-casemaybeincludedbyoneormoreuse-cases.Seetheexamplebelow.

6

ThemaingoalofusingtheIncluderelationshipistoavoidrepetition.The Extend relationship: this relationship is usedwhen a use-case augments the behavior ofanotheruse-case.Thatis,whenthefunctionalityoftheoriginaluse-caseneedtobeextendedasaresultofsomeexceptionalcircumstance(theoriginaluse-casecanbeexecutedwithouttheextendeduse-case).

Forexample,theuse-caseSolveProblembelowiscompletebyitself,butcanbeextendedbytheuse-caseReporttoSupervisorinaspecificscenarioinwhichtheuserwantstoreporttheproblemtothesupervisor.

Multipleuse-casescanextendasingleuse-case(lookattheexamplebelow).

ThemaingoalofusingtheExtendrelationshipistoreducethecomplexityofalargeuse-case(bydividingit).TheGeneralization and theExtend relationships are similar and you can think of the ExtendrelationshipasatypeoftheGeneralizationrelationship.ThemaindifferencebetweenthemisthatintheGeneralizationrelationship,thesubuse-casesareexpectedtoredefinethebehaviorof the superuse-case.That is, thebehaviorsof the superand the subuse-cases canbeverydifferent.However,intheExtendrelationship,theextendinguse-casewillbeexecutedaftertheexecutionoftheextendeduse-casereachesacertainpoint(acondition).Therefore,theExtendrelationshipuseswhatwecallanExtensionPoint.

7

Anextensionpoint showwhen theextendinguse-casewillbeperformed.Takea lookat theexamplebelow.In(a),itishardtotellwhentheGiveraiseuse-casewillbeexecuted.Thisproblemwasresolvedusingtheextensionpointasin(b).

(a) (b)

Use-cases.A use-case is a template that describes one of the processes of the system from the user’sperspective.Theuse-casedescribestheprocessfromstarttofinishassequenceofeventsandactionsthatarerequiredtocompletetheprocess.Youneedtocreateause-caseforeachprocessintheuse-casediagram.Mostuse-casescontainthefollowingsections:use-casename,actor,purpose,overview,crossreferences, constraints, pre-conditions, post-conditions, type, priority, frequency of use, andtypicalcourseofactions.Next,abriefdescriptionofeachsectionisprovided.- Use-casename: theuse-casenamemustbemeaningfulandunique.Forexample,LogIn,

RateProduct,andBuyItems.- Actor:thetypeofuserswhocaninitiatethisuse-case.Ause-casemayhaveasingleactoror

multiple actors. If a use-case hasmultiple actors, it is a good idea to decidewho is theinitiator of the use-case. For example, the Buy Items use-case has two actors: customer(initiator)andcashier.

- Purpose:theobjectiveoftheuse-case.Technicalandimplementationdetailsshouldnotbementionedasapartoftheuse-casepurpose.

8

- Overview:whattypeofactionstakeplaceduringthisuse-case?Itisagoodideatostarttheuse-caseoverviewwiththissentence:“Thisuse-casebeginswhen…..”andendsitwith“Thisuse-caseendswhen…..”or“Oncompletion,…..”.

- Crossreferences:thenumberofthefunctionalrequirementthatcanbelinkedtothisuse-case.

- Pre-conditions:theconditionsthatneedtobemetbeforetheuse-casecanbegin.

- Post-conditions:thechangesthatoccuraftertheexecutionoftheuse-casesuchassaving

informationorgeneratingoutput.

- Type:therearetwowaystodescribethetypeofause-case:

(1)Accordingtousageand(2)Accordingtoabstractionlevel.

Accordingtousage,use-casetypecanbeprimary,secondary,oroptional.

• Primary:whentheuse-casedescribesamajorandcommonfunction.• Secondary:whentheuse-casedescribesanexceptionalfunction(afunctionthatis

rareorunusual).• Optional:whentheuse-casedescribesafunctionthatmayormaynotbeused(may

ormaynotbeimplemented).Accordingtoabstractionlevel,ause-casetypecanbeessentialorreal.

• Essential:whenthedescriptionoftheuse-caseiswrittenusingahigh-levellanguage(free of technology and implementation details).Most use-caseswill be essentialbecausetheyarecreatedduringtheanalysisphase.

• Real:whenthedescriptionoftheuse-caseinvolvesadetaileddesigndescription.Thefollowingisanexampleofthelanguageusedinanessentialandarealuse-cases.

Essentialuse-case Realuse-caseTheaccountholderidentifiesherselftotheATM.

TheaccountholderinsertsthecardintotheATMcardreader.TheaccountholderispromptedtoenterherPINwhichsheinputusinganumerickeypad.

9

- Typicalcourseofevents:Thetypicalcourseofeventsistheformaldescriptionoftheflowofeventsthatoccurduringtheexecutionoftheuse-case.Ittellsusstepbystephowthesystemreactstoeveryuseraction(keepinmindthatthesystemmaynotrespondtoeveryuseractionoritmayrequiremultipleuseractionstorespond).Youcanthinkofitasatextualrepresentationofthecorrespondingsequencediagram.Itiscalled“typical”courseofeventsbecauseitdescribeshowmostusersinteractwiththesystem.Itincludes“Alternatives”sectionthathandlesalltheothercasesinwhichaneventmayhappendifferently.ThetablebelowshowshowthetypicalcourseofeventslookslikefortheBuyItemsuse-case.

Actoraction Systemresponse1. 1.Thisuse-casebeginswhenacustomer

arrivesatthecheckoutpoint.

2. 2.Thecashierscanseachitem. 3.Determinestheitempriceandaddsitsinformationtothecurrenttransaction.

3. 4.Thecashierindicatesthattheitementryiscomplete.

5.Calculatesanddisplaysthetotal.

4. 6.Thecashiertellsthecustomerthetotal.

5. 7.Thecustomergivesacashpayment.6. Thecashierrecordsthecashreceived.

8.Showsthebalanceduebacktothecustomer.

7. 9.Thecashierdepositsthecashandextractsthebalanceowing.

8. 11.Thecashiergivesthebalanceowingtothecustomer.

9. 10.Logsthecompletedsale.Printthereceipt.

12.Thecashiergivesthereceipttothecustomer.13.Thecustomerleaveswiththeitems.

Alternatives:Line9:insufficientcashindrawertopaybalance.Askforcashfromsupervisor.

Intheuse-caseabove,itisexpectedthatthecustomerwillalwayschoose“paybycash”asherpaymentmethod (onlyonemethodof payment is provided). If the systemhas twomethodsofpayment(cashandcreditcard),thenlistthetypical(mostcommon)oneinthetableandtheotherintheAlternativessection.However,ifthetwomethodsareequalintheir likelihood, thenyouneedtoaddanewtable foreachoption(lookat theexamplebelow).

10

Section:MainActoraction Systemresponse

1.Thisuse-casebeginswhenacustomerarrivesatthecheckoutpoint.

2.Thecashierscanseachitem. 3.Determinestheitempriceandaddsitsinformationtothecurrenttransaction.

4.Thecashierindicatesthattheitementryiscomplete.

5.Calculatesanddisplaysthetotal.

6.Thecashiertellsthecustomerthetotal.

1. 7.Customerchoosespaymentmethod:a. Ifcustomerchoosescash,seesection

paybycash.Ifcustomerchoosescreditcard,seesectionpaybycreditcard.

8.Logsthecompletedsale.Printthereceipt.

9.Thecashiergivesthereceipttothecustomer.10.Thecustomerleaveswiththeitems.

Alternatives:

Section:PaybycashActoraction Systemresponse

1. 1.Thecustomergivesacashpayment.2. 2.Thecashierrecordsthecash

received.

3. 3.Showsthebalanceduebacktothecustomer.

4. 4.Thecashierdepositsthecashandextractsthebalanceowing.

5. 5.Thecashiergivesthebalanceowingtothecustomer.

Alternatives:Line4:insufficientcashindrawertopaybalance.Askforcashfromsupervisor.

Similarly,addaPaybycreditcardcourseofeventstable.

11

TraditionalorObject-Orientedrequirementsmodeling?ThechoiceofthesoftwarerequirementsmodelingdeterminesyouroverallviewofthesystemsandtheUMLdiagramsyouwillneedtoprovideaspartofyourproject.Thechoiceofthesoftwarerequirementsmodelingisdeterminedbythenatureofyoursoftwareproject.However,someprojectscanbedevelopedusinganyapproach.Generally,weusethefollowingruletodecide:Whenthebasicbuildingblocksofourprojectisfunctions,thenweusethetraditionalapproach.Whenthebasicbuildingblocksofourprojectisentities(data),thenweusetheobject-orientedapproach.Whatdowemeanbyabuildingblock?Thinkofitasthebasicsetofelements(orabstractions)ofyourproject.Forexample,inabankingsoftware,thebasicbuildingblocksaretheclient,theaccount,thetransaction,etc.Thoseareallentities,andeachentityincludessetsofattributesandmethods.Generally,usinganobject-orientedapproachworkswellforabankingsoftware.Inadocumenteditingsoftware,thebasicbuildingblocksarefunctionssuchasadddocument,editdocument,addtext,changetextcolor,etc.Thismakesusingthetraditionalapproachmakesmoresenseinthiscase.Notethatitispossibletouseanyapproach;however,thereisalwaysoneapproachthatismoreefficient(leadstoastrongerdesign).Ifyouchosethetraditionalapproach,thenyourcomponentsarefunctionsandyouneedtodoadataflowdiagram.Ifyouchosetheobject-orientedapproach,thenyourcomponentsareentitiesandyouneedtodoaclassdiagram.

12

UMLdesigndiagrams.The rest of this document presents a several popularUML diagrams that developers usuallycreate as part of the software development process. Generally, those diagrams can bepartitionedintotwogroups:behavioralandstructural(seethefigurebelow).Behavioraldiagramsfocusonthedataflowwithinthesystem(orwithinaspecificpartofthesystem).Structuraldiagramsshowthestatic(stable)representationofthesystem.

ArchitecturalDesign.Thearchitecturaldesignshowsthestructureofthesystem.Thatis,themainsystemcomponentsandtheirrelationships.Usea“boxandline”diagramrepresentationtoshowyourdesign.Donotprovideanycomponentdetailsatthislevel(thisisnotaclassdiagram).To come up with your architectural design, you need to figure out the following: the maincomponents of your system and the best organization of those component (how thosecomponentsareconnected).

13

Remembertouseoneoftheexistingarchitecturalpatternsifoneissimilartoyoursystem.Someofthemostcommonsoftwarearchitecturalpatternsare:

1. Thelayeredpattern.2. Theclient-serverpattern.3. Thepipeandfilterpattern.4. Therepositorypattern.5. Thecallandreturnpattern.

ComponentleveldesignAcomponentisaclass,amodule,orasetofinterrelatedclassesormodulesthatcollaboratetoachieveacommongoal.Componentleveldesignfollowsthearchitecturaldesignstep.Thegoalistoelaborateoneachoftheelementsinyourarchitecturaldiagrambyprovidingdetailsthatleadtotheactualcode.Component level design can be achieved by using a pseudo-code, aDFD, a state diagram, acollaborationdiagram,adecisiontable,etc.Remembertofollowgoodcomponentleveldesignprinciples(suchascohesionandcoupling).Thiswillhelpyoucreateadesignthatiseasiertodealwith(test,maintain,etc).

DataFlowDiagrams(DFD).If youdecided touse a traditional software requirementsmodeling, then you know that thefunctionsarethebasicbuildingblocksofyoursystem.Therefore,youhavetocreateadetailedlistofallthefunctions(methods)thatyouaregoingtoimplementduringtheimplementationphase.DFDshelpyoucreatethislist.ADFDisatopdownmethodthatisusedasatraditionalvisualrepresentationoftheinformationflowwithin a given system. It supports thehierarchical decompositionof the system into itsdifferentfunctionsandactivities.YouwillalwaysneedmultipleDFDseachofwhichdescribesthesystematadifferentlevelofabstraction.ThenumberofDFDscannotbeknowninadvanced.Generally,DFDsshowthefollowinginformation:

• Datathatentersandleavesthesystem(systeminputandoutput).• Externalentities(peopleorothersystems)thatinteractwithyoursystem.Thiswillhelpyoudecidetheboundaryofyoursystem,thatis,whatisandwhatisnotincludedinyoursystem.

• Theprocessesthattakeplacewithinthesystem.• Theinformationthatisstoredinthesystem.

14

ThefollowingprovidesabriefdescriptionofthefirstfourDFDlevels:• Level0DFD(alsocalledtheContextLevelDFD)considersthewholesystemasasingleprocess that interacts with a set of external entities. The entire system will beencapsulatedintoonebubble.

• Level 1 DFD presents a more detailed view of the system by showing its main subprocesses.Thesystembubbleshowninlevel0DFDwillbereplacedbymultiplebubbleseachofwhichdescribes(highlevel)amainsystemfunction.

• Level2DFDisusedtoprovidemorespecificdetailsabouteachofthesystemfunctions.• LevelnDFD(n>=3)decomposeseachbubble(function)thatexistsinleveln-1DFDintobasicfunctionalunits.ThedecompositionprocessfinisheswheneachofthebubblesinthelastDFDrepresentsafunctionalprimitive.

ThefinalDFDtobefactored.Factoring“leadstoaprogramstructureinwhichtop-levelcomponentsperformdecisionmakingandlow-levelcomponentsperformmostinput,computation,andoutputwork.Middlelevelcomponentsperformsomecontrolanddomoderateamountsofwork.”

ConceptualModel.Theconceptualmodel isasystemrepresentationthatdescribes thesystematahigh levelofabstraction.Itmainlydescribes

• Themainsystementitiesandrelationships.• Systemstatesandtransitions.• Systeminteractionsanduserinterfaces.

Themainobjectiveoftheconceptualmodelistoenableeffectivecommunicationbetweenthesoftwareteamandthestakeholders.Thereisnooneformalnotationfortheconceptualdiagram.Generally,classdiagramnotationsareusedtorepresenttheconceptualdiagram.Aconceptualmodelcanbeusedasastartingpointforbuildingtheclassdiagramofyoursystem.Therefore,whenyoustartdrawingyourconceptualdiagram,drawadiagramthatrepresentstheconceptsinthesystemdomain(notyourspecificsystem).

15

ClassDiagram.Aclassdiagramdescribesthestructureofthesystem.Itshowsthesystemclasses,attributes,methods,andrelationshipsamongtheclasses.Classdiagramsservetwomainobjectives:

1. Systemvisualizationanddescription.2. codeconstruction(duringimplementation).

Whendrawingyourclassdiagram,keepthisquestioninmind:Whattypeofrelationshipsexistbetweentheclassesinreal-life?Thoserelationshipsmusthelpyoudrawaclassdiagramthatiseasytounderstandbyhumans.Itmustalsohelpprogrammerswritetheircodeclearly.

ERDiagram.TheERD(Entity-RelationshipdiagramorEntity-Relationshipmodel)representstheentitiesthatexistinthesystemandtheirrelationshipsthewaytheywillbestoredinthesystemdatabase.You only need an ERD if your system has a database (most likely your system will need adatabase).WhendrawingyourERD,keepthisquestioninmind:Whattypeofrelationshipsyouneedtoaddbetweenyourentitiestoansweryourdatabasequeries?ER diagrams may represent system relationships that are more difficult for humans tounderstand.

WhatisthedifferencebetweenaclassdiagramandanERD?Inshort,aclassdiagramrepresentsthesystemcomponents(thecode),whileanERDrepresentsthedatabase.AnERDisnotareplacementtotheclassdiagram.Insomeprojects,youwillneedbothmodels(forexample,ifyouuseobject-orientedrequirementsmodelingandyouplantohaveasystemdatabase).Insomeothercases,youmanyneedonlyone.Generally,aclassdiagramandanERDaresimilar,buttheymaynotbeidentical.Classdiagramsfocusonthesystemstaticrepresentationandtheoverallsystembehavior.Ontheotherhand,ERdiagramsfocusonsystemdata.

16

Example:KingSaudUniversityhasseveraldepartments.Eachdepartmentismanagedbyachair.Professorsmust be assigned to oneormore departments. A professor teaches oneormorecourses.Acoursemaybetaughtbymultipleprofessors.

Classdiagram ERD

DeploymentdiagramAdeploymentdiagramspecifiesthephysicalhardwarethatwillrunthesystem.Eachblockinthedeploymentdiagramrepresentsanode.Anodehereisaphysicalentity(suchasaPC)wherethesystemcomponentswillbeuploaded.

17

Statediagram–DescribesthestatechangesofthesystemAstatediagram(alsocalledastatemachinediagram)modelsthedynamicbehaviorofaclass,amodule,ortheentiresystemasasequenceofstatesasareactiontointernalorexternalstimuli.Youdonotneedastatediagramforeachclassorfunction.Thediagrambelowisastatediagramthatshowsthesystemstateswhilehandlingauserorderuponcheckout.

Inastatediagram,youneedtodefineeachofthefollowing:

• Initialstate:thestateofthesystembeforetheprocess(thedarkcircleatthebeginningofthediagramabove).

• Systemstate:representedasaboxwiththestatenameandtheactionthatthesystemdoeswhileinthestate.Forexample,checking,dispatching,andwaitingintheexampleabove.

• Event: the event that causes the system to transition fromone state to another. Forexample,itemsreceivedabove.

• Condition:theconditionthatcausesthesystemtotransitionfromonestatetoanother.Forexample,allitemsinstockabove.

• Action:theactionthattakesplaceasaresultofasystemstate.Forexample,deliveritemsabove.

18

Activitydiagram–Representstheactivityflowofthesystem.Activity diagrams show the flow of actions that happen in parallel or in sequence. Activitydiagramsarenotidenticaltostatediagramsbecausetheycanbeusedtodescribeeachsystemfunction(use-case).Unlikestatediagrams,activitydiagramsdonotneedatriggerevent.Belowistheactivitydiagramforthereceiveorder.

DecisiontablesAdecisiontableisavisualtabularrepresentationthatdescribeswhichactionstoperformundercertainconditions.Itisespeciallybeneficialwhenthelogicoftheprocessiscomplex(hasmultipleconditionsandactions).The table has twomain sections: conditions and actions. The conditions evaluate to simpleBooleanvalues(True/False).Eachactionthatoccurasaresultofsatisfyingacondition(orasetofcondition)willbemarked.Decisiontreescanbeusedasalternativestodecisiontables.

19

Example:Thetablebelowrepresentsthedecisiontableforthefollowingdecisionlogic,whichdescribeshowaprintertroubleshooterworks.

• Iftheprinterdoesnotprint,itsredlightisflashing,andtheprinterisunrecognized,thentheuserneedstochecktheprinter-computercable,ensuresprintersoftwareisinstalled,andcheckorreplacetheink.

• Iftheprinterdoesnotprintanditsredlightisflashing,thentheuserneedstocheckorreplacetheinkandcheckforpaperjam.

• Iftheprinterdoesnotprintandtheprinterisnotrecognized,thentheuserneedstocheckthepowercable,checktheprinter-computercable,andensuresprintersoftwareisinstalled.

• Iftheprinterdoesnotprint,thentheuserneedstocheckforpaperjam.• Iftheprinterredlightisflashingandtheprinterisunrecognized,thentheuserneedstoensure

printersoftwareisinstalledandcheckorreplacetheink.• Iftheprinterredlightisflashing,thentheuserneedstocheckorreplacetheink.• Iftheprinterisunrecognized,thentheuserneedstoensureprintersoftwareisinstalled.

Rules 1 2 3 4 5 6 7

ConditionsPrinterdoesnotprint T T T T Aredlightisflashing T T T T Printerisunrecognized T T T T

Actions

Checkthepowercable ´ Checktheprinter-computercable ´ ´ Ensureprintersoftwareisinstalled ´ ´ ´ ´

Check/replaceink ´ ´ ´ ´ Checkforpaperjam ´ ´

WhatdiagramsdoIneed?There aremultiple UML diagrams that are included in the Analysis and Design steps of thesoftware development. For example, asmentioned above, a component level design can beaccomplishedusingseveralways.Arewerequiredtouseallofthem?Obviouslynot.Itdependsmainlyonthecomponentcomplexity.Complexcomponentsneedtobespecifiedveryclearly tomake the implementation stepmore efficient. For example, if a component has acomplicatedlogic,itwouldbeagoodideatousedecisiontablestoclarifyit.Ifthesystemneedstobedistributedonseveraldevices,itwouldbeclevertouseadeploymentdiagramtoshowthespecificdeploymentplan.Finally,ifthesystemhasacomplicatedinterface,itisadvisabletousean interfacedesigntocommunicateanddiscussthe interfacewiththedesignersandtheendusers.

20

References:https://sparxsystems.com/resources/tutorials/uml2/use-case-diagram.htmlhttps://www.bridging-the-gap.com/what-is-a-use-case/https://slideplayer.com/slide/10764095/https://alagadinc.wordpress.com/2005/02/15/uml-use-case-diagrams/https://people.ok.ubc.ca/bowenhui/310/8-DFD.pdfhttps://www.cs.toronto.edu/~sme/CSC340F/2005/slides/tutorial-classes_ERDs.pdfhttps://www.omg.org/spec/UML/2.4.1/Superstructure/PDFhttps://www.guru99.com/deployment-diagram-uml-example.htmlhttps://www.visual-paradigm.com/guide/uml-unified-modeling-language/state-machine-diagram-vs-activity-diagram/https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013