View
6
Download
0
Category
Preview:
Citation preview
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
Recommended