1COM6030 Systems Analysis and Design © University of Sheffield 2005 COM 6030 Software Analysis and Design Lecture 6 - Use cases and activity diagrams Dr Richard Clayton & Dr Marian Gheorghe Module (1 st part) homepage

2COM6030 Systems Analysis and Design © University of Sheffield 2005 Outline  Use case model  ATM system specification  Activity diagrams  Workflow description using activity diagrams Reading: Bennett chapter 6; Stevens chapters 7, 11

3COM6030 Systems Analysis and Design © University of Sheffield 2005 First part of the course Use case model A user-oriented approach on systems analysis.  Identify the users of the system and the tasks they must undertake.  UML uses technical terms actors and use cases.  Actor = a user of the system in a particular role (an actor might be an external system as well); a customer in the ATM system is an actor.  Use case = is a task which an actor needs to perform with the help of the system; withdraw cash from ATM is a use case; use case may describe a simple or a fairly complex behaviour.

4COM6030 Systems Analysis and Design © University of Sheffield 2005 Use cases Use cases were first proposed by Jacobson (1992) for capturing requirements:  identify single user interactions with a system;  identify stakeholder interactions with a business;  not a good formalism for expressing control logic. Idea is to elicit required system functionality. No prior knowledge of system assumed:  interview the client, taking notes;  collect use cases (i.e. scenarios, examples of usage);  concentrate initially on normal flow of events;  later, look for alternative or exceptional flows;  structure the model afterwards.

5COM6030 Systems Analysis and Design © University of Sheffield 2005 Use cases  A use case is: "a single complete interaction of a user with a system that delivers a result of observable value"  i.e. the smallest-level business task that has meaning and delivers something of value for the user.  Limits:  single complete interaction - accomplishes a single objective, not multiple (upper bound);  result of observable value - accomplishes a business function, not a code instruction (lower bound).  Positive examples:  Deliver goods, Pay Invoice, Process order.  Negative examples:  Enter password, Increase productivity, Quit menu.

6COM6030 Systems Analysis and Design © University of Sheffield 2005 Natural language representations  There is deliberately no specified format. Natural language representations can be:  informally structured descriptions  pseudocode with pre, post-conditions  Aim to use consistent style if at all possible.  Adopt format that is appropriate for type of scenario in business system, may be terse or verbose.  Remember  inherent ambiguity in natural language, use cases should be reviewed critically with client;  use cases are a description of interactions from the user’s perspective.

7COM6030 Systems Analysis and Design © University of Sheffield 2005 ATM example – natural language Name:Insert card and v alidate PIN Type: Functional Description: Inserts the card; v alidates the PIN entered by the user against the central record held on the bank system. Returns an output indicating that the PIN is either correct or incorrect. If the PIN is correct then the session can continue. If the PIN is not correct then the session will terminate, and the card should be returned to the user. Inputs: PIN, bank system record. Outputs: PIN correct, PIN incorrect. Criticality: Validation of PIN is a key component of ATM function. Risk: Very high. Dependencies: User input, communication with bank system.

8COM6030 Systems Analysis and Design © University of Sheffield 2005 Use cases – a summary  Use cases describe who (actor) does what (interaction) with the System, for what purpose (goal).  A complete set of use cases  Specifies all the different ways to use the system  Defines all the behaviour required of the system  Use cases are used to construct use case diagrams. These are a formal description, defined as part of the UML.

9COM6030 Systems Analysis and Design © University of Sheffield 2005 UML use case diagram syntax Cash withdraw from ATM > Actor – participant in use case; usually a user of the system, may not be a human. An individual use case. Communication association. Generalisation relationship. Dependency relationship. A stereotyped model element. System or subsystem boundary.

10COM6030 Systems Analysis and Design © University of Sheffield 2005 Actors Actors are a fundamental component of Use Case diagrams  An actor interacts with a system to produce an observable result.  Actors are often users of a system.  Names correspond to role of actor in use case.  Actors may not necessarily be human.  A generalisation relationship may exist between actors. X is a generalisation of Y if Y-is-a-X. Buyer Seller Broker Three actors in an estate agency Actor Academic University employee University employee is a generalisation of academics. All academics are university employees, but not all university employees are academics.

11COM6030 Systems Analysis and Design © University of Sheffield 2005 Use cases Insert card & validate PIN Manage PIN Withdraw cash Get balance ATM system System Actor - human Actor – another system Customer Bank One can distinguish a Card Manager actor Use case

12COM6030 Systems Analysis and Design © University of Sheffield 2005 Use cases – using generalisations Insert card & validate PIN Manage PIN Withdraw cash Get balance ATM system CustomerBank Transaction

13COM6030 Systems Analysis and Design © University of Sheffield 2005 Generalisations  A generalisation relationship may exist between use cases as well as actors.  X is a generalisation of Y if Y-is-a-X.  Direction of generalisation is from specific to general.  For ATM system … Transaction Get balance Bank Card manager

14COM6030 Systems Analysis and Design © University of Sheffield 2005 Requirements review Insert card &validate PIN Inserts card; validates the PIN entered by the user against the central record held on the bank system. Returns an output indicating that the PIN is either correct or incorrect. If the PIN is correct then the session can continue. If the PIN is not correct then the session will terminate, and the card should be returned to the user. Manage PIN.. Get balance… Withdraw cash… CustomerAny card holder accessing an ATM. BankThe bank system that manages customers’ accounts. Card Manager The bank system that manages accounts and cards.  The system is specified as a set of subsystems (only one for ATM system).  Each subsystem consists of  a list of actors and their roles;  a list of use case descriptions;  associated use case diagrams;  activity diagrams (next slides) – optional. Use case descriptions Actor descriptions

15COM6030 Systems Analysis and Design © University of Sheffield 2005 Use cases for requirements capture  Use cases can help with requirements capture by providing a structured way to deal with it:  Identify the actors.  For each actor find out: what they need from the system – their associated use cases; other interactions – which use cases they might take part in for someone else’s benefit.  Possible problems with use cases:  Build a system in a non-object oriented manner (functional approach).  Danger of thinking too operationally; users describe the use cases as a sequence of interactions in a given order, maybe not the right one – leads into design.  Danger of missing requirements by focusing too much on finding actors and their uses cases; can be lessened by doing use case analysis and conceptual class modelling in parallel.

16COM6030 Systems Analysis and Design © University of Sheffield 2005 Activity diagrams Activity diagrams are useful to  describe an overall workflow of an area of the customer’s activities;  specify how individual use cases unfold and may depend on other use cases (all transactions of an ATM follow PIN validation);  represent how an operation (see object specifications) could be implemented. The fundamental block is an activity; a transition out of an activity normally means that the activity has been completed. Insert cardValidate PIN ……

17COM6030 Systems Analysis and Design © University of Sheffield 2005 Elements of activity diagrams Validate PIN An activity – a sort of state which is left when the activity it represents is finished. A transition – a non-labelled arrow; it might have a guard. A synchronisation bar – expresses either waiting for all subtasks to finish before proceeding (join) or starting several subtasks in parallel (fork). A decision diamond – a non-labelled arrow; it might have a guard. A start marker – points to the initial activity. A stop marker – indicates the end task.

18COM6030 Systems Analysis and Design © University of Sheffield 2005 Insert card & validate PIN : Inserts card; validates the PIN entered by the user against the central record held on the bank system. Returns an output indicating that the PIN is either correct or incorrect. If the PIN is correct then the session can continue. If the PIN is not correct then the session will terminate, and the card should be returned to the user. Insert cardValidate PIN TransactionReceive card [incorrect PIN] [correct PIN] Activity diagrams - example It also shows that a transaction is executed after the PIN is validated against the central record.

19COM6030 Systems Analysis and Design © University of Sheffield 2005 When activity diagrams contain several groups of related activities (belong to the same objects, use cases etc) they can be split into partitions known as swimlanes. ATM – Insert card & validate PIN: Insert cardValidate PIN TransactionReceive card [incorrect PIN] [correct PIN] Partitions and swimlanes CustomerATM system

20COM6030 Systems Analysis and Design © University of Sheffield 2005 Summary  Two key UML diagrams for requirements analysis: use cases and activity diagrams.  Requirements specification using use case diagrams and natural language description.  Activity diagrams to specify formally a use case description and to show interdependences among use cases.