1 / 62

Software Engineering

Learn how to represent software systems using graphical models, explore different types of required models, understand fundamental system modeling perspectives, and get introduced to UML diagrams. Gain insights into model-driven engineering.

fskipper
Télécharger la présentation

Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Engineering Chapter 5 (Part 1) System Modeling Dr.Doaa Sami ModifiedfromSommerville’soriginals

  2. Objectives 2 Represent SW systems using graphical models. Show different types of required models. Explain fundamental system modeling perspectives: context, interaction, structure, and behavior. Introduce some types of diagrams in UML. Understand the ideas underlying model-driven engineering.

  3. Modeling A modelis a systemabstraction. Amodelabstracts from irrelevantsystemdetails to simplifyits description. Wecan identifyfollowing kinds ofmodels: Descriptivemodels:modelrealsystems. Prescriptivemodels:planfornewsystems. Each model presenting a different view orperspectiveof thesystem. 3

  4. Modeling Cont. 4 Codeis often hardtounderstandevenby thosewhoparticipatein the development. We needsimplerrepresentationsfor complexsystems: Modelingisameanfordealingwithcomplexity. The most important aspect of a system model is that it leaves out detail. A model is an abstraction of the system being studied rather than an alternative representation of that system.

  5. System Perspectives 5 An external perspective showingthesystems’ context orenvironment. An interaction perspective showing the interactionsbetweenasystemanditsenvironment, orbetweenthe componentsof asystem. A structural perspective showingthesystem organization or the structure of the data that is processed by the system. A behavioral perspective showingthe dynamic behavior of the system and how it responds to events.

  6. OMG 6 The Object Management Group OMG™ is an international,openmembership, not-for-profit computerindustry consortium since1989. Itisnowfocusedonsomeofmodellingstandards suchas UML,OCL,XMI…etc.

  7. What is UML? 7 UnifiedModelingLanguage(UML)isageneral- purpose modelinglanguagetospecify,visualize, modify,constructand documentsoftwaresystems. UMLincludesasetofgraphic notationto createvisual model of object-oriented software systems. Using a standard modeling language such as the UML (the Unified Modeling Language), different members of development team can communicate their decisions unambiguously to one another. “Apictureisworth1000words”

  8. Classification of UML Models 8 A.Context Models:A type of diagrams that illustrate the operational context of a system - they show what lies outside the system boundaries. B.InteractionModels: Emphasize the interactions. Involves user inputs and outputs, interaction between the system being developed and other systems or interaction between the components of the system.

  9. UML diagrams Classification 9 • C.Structural Models: A type of diagrams that display the organization of a system in terms of the components that make up that system and their relationships. • D.Behavioral Models: Describethe dynamic behavior of the system as it is executing, andshowhowtocapture itin amodel.

  10. 10 A. Context Models

  11. Context Models 11 Definition of system boundary is not a value-free judgment. The position of the system boundary has a profound effect on the system requirements. Context models normally show that the environment includes several other automated systems.However, they do not show types of relationships between the systems in the environment and the system that is being specified. Normally, producing a simple architectural model is the first step in this activity.

  12. Context Models (Example) 12 In developing the specification for MHC-PMS system, you have to decide if the system should focus exclusively on collecting information about consultations (using other systems) or it should collect personal patient information. Advantage of relying on other systems for patient information is that you avoid duplicating data. Disadvantageis that using other systems may make it slower to access information. MHC-PMS cannot be used if these systems are unavailable.

  13. The Context of the MHC-PMS 13

  14. 14 B. Interaction Models

  15. 15 1. USE CASE Diagrams

  16. Use Case Modeling 16 Use case diagrams were developed originally tosupport therequirements elicitation.Now,incorporated intotheUML. They describe the functional requirements of the systemin termsof usecases. Itprovidesahigh-levelviewofwhatthesystem does(use case)and whousesit (actor). Anactorrepresentsanythingthatinteractswiththesystem PeopleorSystem. Each use case represents a separated task that involves externalinteractionwithasystem.

  17. Use Case 17 Usecase includes: Use-casediagrams. Use-casespecificationsoutline. The textualspecificationis more important thandiagrams.

  18. Use Case Diagram 18 Anyusecasediagramshowsasetofusecasesand actorsand theirrelationships. Definesclear boundariesof a system. Identifieswho or what interacts with the system. Summarizesthe behaviorof the system.

  19. What is an Actor? 19 Actorsaredrawnasstickpersonswiththeroleofthe actor writtenbelow. Actor role names are unique typically representtherolethatanactor plays withthe system. Each actor participates in one or more use cases. Actors arenot partof thesystem(EXTERNAL). Actors may represent a human, a machine, or another system. Student

  20. Use Case Diagram:Actor • Primary Actor - an entity external to the system that uses system services in a directmanner. • Supporting Actor- an actor that provides services to the system being built. • Hardware, software applications, individual processes, can all be actors. UML Use Case DrivenObject

  21. What is aUse Case? 20 Ausecasedescribestheactionsthesystemtakesto deliversomething of value to the actor. Ausecasemodelsadialog(scenario)between actorsandthe system. Usecasesaredrawnasellipseswiththenameof the usecase written inside the ellipse. Usecasenametypicallyconsistsofanactiveverbandone ormorenounsthat concisely describe the systemfunction modeled. Usecase name Register for Courses

  22. IdentifyingUseCases 21 Using one wayof: 1-Actorbased 2-Eventbased • Identifytheactors related toan • Identifytheexternal events organization.thata systemmust respond to. •For each actor, identifythe • Relatetheeventsto actors processestheyinitiateor and usecases. participateinprocesses. Example: Cashier Login,Cashout Customer Buy items, refunditems

  23. Use Case (Example) 22 • In a university management system: • Studentscan submitthe assignments,the instructormarksthose assignmentsand uploadsresults.Studentare allowed toview results. • Now, by recallingthedefinition of use-case, can youidentify theuse-cases in this System? • SubmitAssignments. • MarkAssignments. • UploadResults. • ViewResults.

  24. Association(Relationship) 23 Actor(s)connectedtousecase(s)byaline,which representstherelationshipbetweenthe actor(s)andthe usecase(s). Oneactor maybe associatedwithone ormore use cases. Oneuse case may be associated with one or more actors. A use case is initiated by an actor to invoke a certain functionalityinthe system.

  25. Example: ATM UseCases • Developasetofusecases andausecasediagram forasimpleATM (simple means you can just consider two kinds of accounts, savings and checking, and two transactions,depositsand withdrawals) UML Use Case DrivenObject

  26. ATM Machine Example .

  27. Use Cases for the MHC-PMS Chapter 4 Requirements engineering

  28. Use Case Scenario 25 Anorderedsetofflowsfromthestartofausecase toone of its end points. Eachusecase is likely tohave several scenarios. Theidealor“happy”scenarioiswhentheprocess worksas normal,such as: moneyiswithdrawnfromATM. “Unhappy”scenarios,or“extensions”arewhen thingsdon’tgosowell,such as: wrongpinnumberentered. Thebaseusecasecanbeexecutedwithouttheuse caseextensionin extendassociations.

  29. Exampleofuse case format 26 UseCase:ReportEmergency Actors:FieldOfficer Precondition:The FieldOfficeractivatesthe“ReportEmergency” functionof herterminal. Trigger:customerenteredits username and password Mainsuccessscenario: •Theterminal respondsbypresentingaformtotheofficer... •TheFieldOfficer fills theform.... •TheDispatcherreviewstheinformationsubmittedbytheFieldOfficer... Post condtion:The FieldOfficer receivestheacknowledgmentand theselectedresponse.

  30. Example: LIBSYS usecases Articlesearch Articleprinting Library User Library Staff Catalogueservices Supplier S.H 2010 UML Use Case DrivenObject

  31. A Library Example . library system borrow client employee reserve Order title Fine payment supervisor

  32. Example: Rent Videos UseCases Rent Videos. A Customer arrives with videos to rent. The ClerkenterstheirID, andeachvideoID.The System outputs information oneach. The Clerk requests the rental report. The System outputs it, whichisgiventothe Customer with their videos. ● Showcomputersystemactors withanalternatenotationto humanactors. Video Store InformationSystem «actor» Credit Authorization Service RentVideos . .. primaryactorson theleft supportingactors on theright UML Use Case DrivenObject

  33. Example: Point of Sale – Use CaseDiagram Processsale Payment Authorization service Handlereturns Cashier <<actor>> Taxcalculator Processrental Managesecurity <<actor>> Accounting system Systemadministrator Manageusers Use Case Diagram: illustrates a set of use cases for asystem. UML Use Case DrivenObject

  34. Use case diagram for Movie TicketMachine Settitle # oftickets Setprice Buytickets Give change Setseats Manager TicketMachine Customer UML Use Case DrivenObject

  35. <<extend>> 27 Anextensionisasignificantexceptiontothenormalcase. Useanextendlinkto showthatoneusecasemayadd functionalitytoanotheruse caseunder certain circumstances. Majorvariation:Ifyouhaveanalternativepathintheuse case, especially whensomethinggoesdifferent fromwhat doesplan. Optionalsub-goal:If youhave parts of theusecase that wouldbeoptionaltoimplement orexecutetomeettheactor’s goals.Doingsoclarifiestherelationships betweenactorsand theirgoals.Italsoemphasizesthatyoumay deliver these optionalgoals in laterreleases.

  36. <<extend>> 28 The arrow should point at the main, extended use case. Forexample,theLoginusecaseofatypicalWebsite can involveRegisterNewUser-butonlywhenthe userdoesnot already have anaccount

  37. <<include>> 29 Used to indicate thatoneusecaseincludes the functionalityof another use case. Someusecases may share oneor morecommon steps Thearrowshouldpointatthemoredetailed,included usecase.

  38. Use CaseDiagram Modeling the Context of aSystem UML Use Case DrivenObject

  39. Use Case Diagram Relationships Close Machine Close Machine Open Machine Open Machine Restock Collect . <<includes>> <<includes>> <<includes>> <<includes>>

  40. Use Case Diagram Relationships <<includes>> Close Machine Open Machine Restock <<includes>> <<extends>> Restock According to Sales .

  41. Self Service Machine Use Case Diagram Open Machine Open Machine Close Machine Buy a product Collect Restock . Self Service Machine <<includes>> customer <<includes>> Restock according to sales <<includes>> <<includes>> supplier Close Machine

  42. Generalization 30 GeneralizationbetweenUseCasesmeansthatthe child is amorespecific than theparent; the child use case inheritsall attributes and associations of the parentuse case,butmay add new features. Childrenofthesameparentareallspecializations ofthe parent.

  43. Generalization 31

  44. Generalization 32

  45. Example 33 CustomerusesbankATMtomakeanATMtransactionas check balances of his/her bank account, deposit funds, withdrawcashand/ortransferfunds. VIPcustomers can makeATMtransactionandprintaccount statement. The customerisauthenticatedbyinsertingaplasticATMcard andenteringapersonalidentification number(PIN). The customerrequestshelpbyselectingHelpmenuitem. BankemployeeupdatesATMbalance.

  46. Use Case SpecificationOutline 34 • Arequirementsdocumentthatcontainsthetextof • a usecase, including: • Adescriptionoftheflowofeventsdescribingthe interactionbetweenactors andthesystem. • Other information, such as: • Preconditions. • Trigger. • Flowofevents. • Postconditions.

  47. Use Case SpecificationOutline Example 35 UseCase:WithdrawMoney Actors:systemuser Precondition: 1.TheCustomerhasselectedalanguagetouse. 2. TheCustomerisa memberofabank. 3. TheCustomerhasplacedtheircreditcardintotheATMmachine. 4.TheCustomerhasverifiedtheiraccountwithPINnumber. Trigger:Customerselectswithdrawmoneyfromthetransactionoptionslist. Flowof events: 1.TheusecasestartswhentheCustomerselectswithdrawmoneyfromthetransactionoptionslist.. 2.ThesystemthenchecksthischosenamountagainstCustomer’scurrentaccountbalance. 3.Thesystemshows aconfirmationmessagethatthewithdrawmoneytransactionwassuccessful. 3.1.IftheCustomerdoesnothave sufficientfundsforthewithdrawamounta messageis displayedand theyarerequestedtosupplyadifferentwithdrawmoneyamount. 4.Thesystemthencountsupmoneynotestothevalueofthewithdrawamountandplacesit inthecash dispenser. 5. Thesystemasktheuserif theyneedareceipt 5.1.IftheCustomerselects“No”thenatransactionreceiptis notprinted. 5.2.IftheCustomerselects“yes” thenatransactionreceiptis printed. 5.2.1if thereisnopapers,a messageisdisplayed“Sorryreceiptcannotbeprinted”. Postcondition: 1. ThesystemhasupdatedtheCustomer’saccountbalanceif atransactionwas successfullycompleted. 2. ThesystemhasejectedtheCustomer’saccountcardif noothertransactionswere required.

  48. 36 • 2. SequenceDiagrams

  49. SequenceDiagrams 37 Sequence diagramsarepartoftheUML andareused to model theinteractions betweenthe actors andthe objectswithin a system. Itshowsthesequenceofinteractionsthattakeplace duringaparticularusecase. Objects and actors involved are listed along the top of the diagram, with a dotted line drawn vertically from these. Interactions between objects are indicated using the annotatedarrows. An important characteristic of a sequence diagram is that time passes from top to bottom.

  50. SequenceDiagrams Cont. 38 Consistsof: Objectsrepresentedby rectangleswiththenameunderlined. Messagesrepresentedasasolidlineandarrowswiththe name ofmessageon it. Timerepresentedasaverticalprogression. The rectangle on the dotted lines indicates the lifeline of the object.

More Related