1!University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 1 Lecture 8:!“Use Case”-Driven Design"" User Stories in Agile Development" Introducing UML into the Software Process" E.g. ICONIX" Domain Models" Use Cases"University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 2 Refresher: UML Notations"UML Class Diagrams"information structure"relationships between data items"modular structure for the system"Use Cases"userʼs view "Lists functions"visual overview of the main requirements""UML Package Diagrams"Overall architecture "Dependencies between components"(UML) Statecharts"responses to events "dynamic behavior"event ordering, reachability, deadlock, etc"UML Sequence Diagrams "individual scenario"interactions between users and system"Sequence of messages"Activity diagrams "business processes;"concurrency and synchronization;"dependencies between tasks;"""""""✔!✔!✔!2!University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 3 What do users want?"User Stories"Used in XP, Scrum, etc."Identify the user (role) who wants it"Typically written on notecards""(User Interface) Storyboards"Sketch of how a user will do a task"Shows the interactions at each step"Commonly used in UI Design""Use Cases"Sets of user features"UML diagram shows inter-relationships "University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 43!University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 5 ICONIX process"University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 6 Domain Model"4!University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 7 Analyse"Risks"Update "Accounts"Set"Limits"Price a"Deal"Capture a"Deal"Trader"Use Case Diagram"Trading"manager"Accounting"System"Salesperson"Value a "Deal"<<includes>>!<<includes>>!University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 8 <<extends>>""Check Campaign!Budget"Print Campaign Summary!"<<uses>>"Find Campaign"Relationships between Use Cases"<<extends>> when one use case adds behaviour to a base case"used to model a part of a use case that the user may see as optional system behavior;"also models a separate sub-case which is executed conditionally."<<uses>>: one use case invokes another (like a procedure call);"used to avoid describing the same flow of events several times"puts the common behavior in a use case of its own.""5!University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 9 Using Generalizations"Actor classes"Identify classes of actor"Where several actors belong to a single class"Some use cases are needed by all members in the class"Other use cases are only needed by some members of the class"Actors inherit use cases from the class"Use Case classes"Sometimes useful to identify a generalization of several use cases"University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 10 Describing Use Cases"For each use case:"a “flow of events” document, written from an actorʼs point of view."describes what the system must provide to the actor when the use case is executed."Typical contents"How the use case starts and ends;"Normal flow of events;"Alternate flow of events;"Exceptional flow of events;"Documentation style:"Choice of how to elaborate the use case:"English language description"Activity Diagrams - good for business process"Collaboration Diagrams - good for high level design"Sequence Diagrams - good for detailed design"6!University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 11 Detailed Use Case"Buy a Product""Main Success Scenario:"1. Customer browses catalog and selects items to buy"2. Customer goes to check out"3. Customer fills in shipping information (address, next-day or 3-day delivery)"4. System presents full pricing information"5. Customer fills in credit card information"6. System authorizes purchase"7. System confirms sale immediately"8. System sends confirming email to customer"Extensions:"3a: Customer is Regular Customer"".1 System displays current shipping, pricing and billing information"".2 Customer may accept or override these defaults, returns to MSS at step 6"6a: System fails to authorize credit card"".1 Customer may reenter credit card information or may cancel"University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 12 Finding Use Cases"Browse through existing documents"noun phrases may be domain classes"verb phrases may be operations and associations"possessive phrases may indicate attributes"For each actor, ask the following questions:"Which functions does the actor require from the system? "What does the actor need to do ?"Does the actor need to read, create, destroy, modify, or store some kinds of information in the system ?"Does the actor have to be notified about events in the system? "Does the actor need to notify the system about something? "What do those events require in terms of system functionality?"Could the actorʼs daily work be simplified or made more efficient
View Full Document
Unlocking...