CIS224 Software Projects: Software Engineering and Research Methods

1. CIS224Software Projects: Software Engineering and Research Methods David Meredith d.meredith@gold.ac.uk www.titanmusic.com/teaching/cis224-2007-8.html Lecture 3 Use Case Models (Based on Fowler (2004, Chapter 9) and Stevens and Pooley (2006, Chapters 7 & 8))

2. Introduction • A use case model describes a system from the user’s point of view • ‘User’ can be a person, software system or hardware device • Used to help with • Requirements capture • Planning iterations in the development process • Validating the design of a system • Introduced by Ivar Jacobson as a development of scenarios • Scenarios still exist in UML

3. Use case diagrams • Intuitive and easy to understand so can be discussed with customers • An individual use case, represented by a named oval, is a class of task that is supported by the system • Each use case also described in detail using text. • Use case diagram is a summary of the detailed information given in the use case descriptions • Actor represented by stick figure • Actor connected to use case by a line if the actor is involved in carrying out the use case • System represented by box around use cases

4. Use cases and class associations • Class Copy represents the set of all possible Copy objects • Class Book represents the set of all possible Book objects • Association “is a copy of” means that every instance of class Copyis a copy of an instance of class Book • BookBorrower actor represents the role of being a book borrower – in principle, anyone or anything could be fulfilling this role in any particular situation • Borrow copy of book use case represents all possible scenarios with the goal of borrowing a book – regardless of whether a book is successfully borrowed or not • A scenario is an instance of a use case just as an object is an instance of a class • Line between BookBorrower actor and Borrow copy of book use case represents a communicates relation and means that it is possible for someone in the role of a BookBorrower to be involved in carrying out the use case Borrow copy of book • It does NOT mean that all BookBorrowers are always borrowing books

5. Actors • An actor is a representation of a user in a particular role from the point of view of the system • Beneficiary of a use case is an actor that benefits from the use case being carried out • GiftRecipient is beneficiary in Buy gift use case • Primary actor of a use case is the actor whose goal is achieved by carrying out the use case • GiftBuyer is primary actor in Buy gift use case • Other actors involved in the use case are secondary actors • A given person might play different roles on different occasions and therefore be represented by different actors in the use case model • An actor usually only represents a role carried out by an external non-human device or system when it is autonomous • If the device or system is being operated by a human, then it is usually the role the human is playing that should be represented by the actor • Credit card authorization system providing services to a till system might be represented by an actor • Bar code scanner probably not represented by an actor since operated by human

6. Use cases • A scenario is an instance of a use case just as an object is an instance of a class • Examples of scenarios in Borrow copy of book use case • BookBorrower presents a book and is permitted to borrow it. The system is updated accordingly. • BookBorrower presents a book but is refused permission to borrow it because he/she already has the maximum number of books on loan • Use case usually named after the main success scenario which is the normal successful scenario in the use case • Other scenarios in a use case are called extensions • Extensions may be either successful or unsuccessful • All scenarios in a use case have the same goal • Usually use text in third person active voice to describe the details of a use case and its extensions

7. Using use cases for requirements capture • To capture requirements using use cases we • Identify the users and the systems that will interact with the system to be built • Identify the actors (i.e., the different roles taken by the users when interacting with the system) • For each actor, find out • The use cases in which the actor is the primary actor or a beneficiary • The other use cases in which the actor is involved • Find out how important each use case is to the users

8. Using use cases for planning • Before producing an overall plan and cost estimation we must have an initial list of all the use cases for the system and • A good understanding of what each use case means • An understanding of who wants each use case and how important it is • Knowledge of which use cases are the most risky • An idea of how long each use case will take to implement • Note that this is so that we can carry out the “inception” phase of the project where we produce a high-level predictive plan, business case and feasibility assessment • We should not make the plan too rigid because it is bound to change when we start doing iterative development and presenting users with prototype systems to evaluate • When we have a “complete” initial list of use cases and an understanding of how risky and important each is, we can then plan which iterations will provide realizations of which use cases

9. Choosing which use cases to realize in the early iterations • Should aim to realize those use cases in the early iterations that the users have indicated are most important • Gibbs (1994): 25% of projects cancelled • Need to give high priority to realising use cases that are considered important by those who are in a position to cancel the project! • But remember that system must ultimately satisfy the users’ needs • Initial use case analysis can help with determining whether or not the project is worth doing at all

10. Using use cases in validation • Validate a design by taking each use case in turn and checking if the design supports the use case (“walking” the use case) • Should be a system test for each significantly different scenario family within each case • In Borrow copy of book, should be system test for • BookBorrower being permitted to borrow the book • BookBorrower being refused permission to borrow book because already has too many books out

11. Problems with use cases • Danger of building system which is not object-oriented (i.e., component-based) • Too much emphasis on use cases can cause developers to make bad architectural decisions in the rush to realize quickly the important use cases • Danger of confusing design with requirements • Users describe procedures for achieving their goals • Developers must consider other procedures and focus in use case analysis on identifying the users’ goals

12. Dependencies between use cases • Two main ways in which a use case may depend on another use case: • A simpler use case may be included as a step within a more complex use case • The more complex use case depends on the simpler one • a change in the simpler one might mean the more complex one has to be changed too • A use case may be an extension of another use case • An extension is a scenario within a use case that does not have the same outcome as the main success scenario • Extension depends on main use case since it is defined to be a variation on the main success scenario

13. The <<include>> relationship • Scenarios that are instances of the more complex (“including”) use case contain subscenarios which are instances of the simpler (“included”) use case • More complex use case depends on the simpler use case – hence dashed arrow with open head which indicates dependency in UML

14. Use case descriptions • Every use case should have a detailed use case description which is usually written in third-person, active-voice prose

15. Use case description forBorrow copy of book A BookBorrower presents a copy of a book and his or her library card at the issue desk. The system checks that the BookBorrower is a library member and that he or she does not already have the maximum permitted number of books on loan. This maximum is 6 unless the BookBorrower is a staff member, in which case the maximum is 12. If both checks succeed, the system checks that the copy of the book is one that can be borrowed. If it is, then the system checks if there is a reservation on the book (done according to the use case Check for reservation). If there is no reservation on the book, the system records that the BookBorrower has the book on loan from the current date and prompts the librarian to stamp the book with the return date. If any of the checks fail, the BookBorrower is refused permission to borrow the book.

16. Use case description forExtend loan A BookBorrower asks (either in person or by telephone) to extend the loan of a copy of a book. The system checks whether there is a reservation on the copy (done according to the use case Check for reservation). If so, the system refuses to extend the loan. Otherwise it records that the BookBorrower’s loan of the copy has been extended and prompts the librarian to stamp the book with the new return date. If the BookBorrower is present, the copy of the book is stamped. Otherwise, the librarian asks the BookBorrower over the phone to write the new return date in the book.

17. Use case description forCheck for reservation Given a copy of a book, the system determines whether or not the book is reserved.

18. Benefits of the <<include>> relation • Instance of the “write once principle” • Identify common steps in the main use cases and factor these out as included use cases so that the details of these steps only have to be defined once • Can make use case descriptions shorter • Helps with identifying reusable components if included use cases are coherent units of functionality

19. Problems with the <<include>> relation • Encourages functional decomposition of system instead of an object-oriented design • Avoid this by developing class model in parallel with use case model • Make sure use case reuse makes sense at the class level • Makes use case diagram harder to understand for the user or customer • Tends to blur boundary between design and requirements • Using <<include>>s implies that some design decisions have been made

20. Extending a use case • If a use case contains two or more scenarios with quite different outcomes, then all the scenarios apart from the main success scenario are called extensions and are considered to be variants on the main success scenario • It is not necessary to represent each extension on the use case diagram since all extensions are represented within the main use case symbol • However, you can show an extension as a separate use case by creating a new use case oval labelled with the name of the extension, then drawing a dashed dependency arrow from the extension to the main use case and labelling this arrow with the keyword <<extend>> to indicate that the extension extends the main use case

21. Generalizing an actor and a use case

22. System classes that represent actors • If a system interacts with an actor it is not unusual for the actor to be represented by a class within the system • Two main types of situation when this happens: • When the system must store data about each instance of the actor e.g., library system must store data about each library member such as name, id number, list of books borrowed • When the system represents (or wraps) an external device with an internal object and uses the interface of the object to interact with the device e.g., there might be a Sensor class within a home alarm system through which the system interacts with the physical motion sensors positioned around the house

23. Summary • Use case model represents a system from the point of view of the users • Use case models can help with • requirements capture • planning the goals of iterations • validating the design of a system and testing the completed system • Use case diagram is a summary or table of contents on the use case analysis • each use case must also have a detailed textual description • Each use case is a class of task that is supported by the system to be built • A scenario is a particular instance of a use case with a particular outcome • All the scenarios within a single use case have the same goal • The normal successful scenario within a use case, after which the use case is named, is called the main success scenario • The other scanarios within a use case are called extensions • Users can be humans or autonomous devices or systems that are external to the system that we are building • An actor represents a particular role that a user might adopt when interacting with the system • A beneficiary of a use case is an actor that benefits from the use case being carried out • The primary actor of a use case is the actor whose goal is achieved by carrying out the use case • The other actors involved in a use case are called secondary actors • Important to focus on requirements when doing a use case analysis and try not to make design assumptions • Two ways in which use cases may depend on each other: • A simpler use case may be included within a more complicated one • A use case may be an extension of another use case • Like classes, actors may be related by generalization, as may use cases • An actor may be represented by a class within a system if either • the system needs to store information about instances of the actor; or • the system interacts with an autonomous physical device via the interface of an object that wraps that device