Page ‹#›Information Systems Analysis and Design csc3402004 John MylopoulosUse Cases -- 1IX. Use CasesThe Unified Modeling LanguageThe Unified Modeling LanguageActors and Use CasesActors and Use CasesHow to Find ThemHow to Find ThemInformation Systems Analysis and Design csc3402004 John MylopoulosUse Cases -- 2The Unified Modeling Language (UML) Booch and Rumbaugh started working towards a unifiedmodelling language (UML) in 1994 under the auspices ofRational Inc. They were later joined by Jacobson. UML only offers a notation, not a methodology formodeling (as various OOA techniques do). Combines Jacobson’s use cases with Booch andRumbaugh concepts for object modeling, along withstatecharts. UML has been adopted by the Object ManagementGroup {OMG) as an (object) modelling standard. OMGUML 1.0 is the first version of this new modellingstandard.Page ‹#›Information Systems Analysis and Design csc3402004 John MylopoulosUse Cases -- 3Where Do We Start? Use CasesWhere Do We Start? Use Cases Use cases describe how the system-to-be (or anyartifact under design, for that matter!) from a user’sperspective. They answer the question: How will the artifact beused, once it is built? Used to show the functions to be supported. Developed by Ivar Jacobson and friends[Jacobson92].Information Systems Analysis and Design csc3402004 John MylopoulosUse Cases -- 4ActorsActors An actor is anything that needs to exchangeinformation with the artifact An actor could be a person, or another external,system. Actors define roles that users can play while usingthe artifact.AccountantCampaignManagerStaff ContactPage ‹#›Information Systems Analysis and Design csc3402004 John MylopoulosUse Cases -- 5Use CasesUse Cases A use case is a function the new system needs tosupport. Each use case is a sequence of steps performed byan actor and the system through a dialogue. To find use case, examine each actor and herneeds.Record client paymentAdd new clientChange a client contactInformation Systems Analysis and Design csc3402004 John MylopoulosUse Cases -- 6Use Case DiagramsUse Case Diagrams Use case diagrams are created to capture therelationships between actors and use casesCampaignManagerAccountantChange a client contactAdd a new clientRecord client paymentStaff contactPage ‹#›Information Systems Analysis and Design csc3402004 John MylopoulosUse Cases -- 7Notation for Use CasesNotation for Use CasesStaff contactActorChange client contactCommunicationassociationSystem/Artifact boundaryUse caseInformation Systems Analysis and Design csc3402004 John MylopoulosUse Cases -- 8Agate is an Advertising Company…which puts together advertising campaigns for clientcompanies. Here is the breakdown of their staff:Direction Admin Campaigns Mgt1 Campaign 1 Office mgr2 Campaign managers1 Creative 3 Direction asst 3 Campaign marketers1 Admin 4 Manager clerks 1 Editor in Chief1 Finance 2 Receptionists 1 Creative Manager2 Clerks/typistsEdition1 Filing clerkGraphics2 Editors 6 Graphic designers4 Copy writers 2 PhotographersIT Accounts Edition Documentation1 IT manager 1 Accountant manager 1 Media librarian1 Network administrator 1 Credit controller 1 Resource libr1 System admin 2 Accounts clerks 1 Knowledge worker1 Analyst 2 Purchasing assistants 1 Computer techPage ‹#›Information Systems Analysis and Design csc3402004 John MylopoulosUse Cases -- 9AgateAgateCaseCaseStudyStudyAdd new staff memberAdd new staff gradeCalculate staff bonusesChange gradefor staff memberAccountantChange ratefor staff gradeInformation Systems Analysis and Design csc3402004 John MylopoulosUse Cases -- 10<<extends>> and <<uses>><<extends>> and <<uses>> <<extends>> used to model a part of a use casethat the user may see as optional system behavior;also models a separate sub-case which is executedconditionally. <<uses>> adds behavior to a base case (like aprocedure call).<<extends>>Check CampaignBudgetCheck PoliticalCampaign Budget<<uses>>Find CampaignPage ‹#›Information Systems Analysis and Design csc3402004 John MylopoulosUse Cases -- 11Finding ActorsFinding Actors Actors can be identified by answering the following:Who will be a primary user of the artifact?Who will be supported?Who will maintain, administrate the artifact?What hardware does the system need?Which other systems does it interact with?Who or what has an interest in the results thatthe artifact produces ? Tip: don’t consider only the users who directly usethe artifact, but also others who need services fromthe artifact!Information Systems Analysis and Design csc3402004 John MylopoulosUse Cases -- 12Finding Use CasesFinding Use CasesFor each actor, ask the following questions: Which functions does the actor require from theartifact? What does the actor need to do? Does the actor need to read, create, destroy,modify, or store some kinds of information in theartifact? Does the actor have to be notified about events inthe artifact? Or, does the actor need to notify theartifact about something? What do those eventsrequire in terms of artifact functionality? Could the actor’s daily work be simplified or mademore efficient through new functions provided bythe artifact?Page ‹#›Information Systems Analysis and Design csc3402004 John MylopoulosUse Cases -- 13Documenting Use CasesDocumenting Use Cases For each use case, prepare a “flow of events”document, written from an actor’s point of view. The document details what the system mustprovide to the actor when the use case is executed. Typical contentsHow the use case starts and ends;Normal flow of events;Alternate flow of events;Exceptional flow of events;Information Systems Analysis and Design csc3402004 John MylopoulosUse Cases -- 14Use Cases for aMeeting Scheduling SystemInitiatorParticipantScheduleMtgValidateUserGenerateSchedule<<uses>>EditConstraintsProvideConstraintsWithdraw<<extends>><<uses>>Page ‹#›Information Systems Analysis and Design
View Full Document
Unlocking...