1COM6030 Systems Analysis and Design © University of Sheffield 2005 COM 6030 Software Analysis and Design Lecture 7 – More on 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  More on use case diagrams  > and > relationships  ATM system specification revisited  Activity diagrams modelling more complex processes Reading: Bennett chapter 6; Stevens chapters 7, 11

3COM6030 Systems Analysis and Design © University of Sheffield 2005 ATM system - use cases Insert card & validate PIN Manage PIN Withdraw cash Get balance ATM system Customer Bank Remember…

4COM6030 Systems Analysis and Design © University of Sheffield 2005 Identifying and documenting actors and use cases  Use cases can help with requirements capture by providing a structured way to identify:  actors  associated use cases. CustomerAny card holder accessing an ATM. BankThe bank system that manages customers’ accounts. Card Manager The bank system that manages accounts and cards. 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… Use case descriptions Actor descriptions

5COM6030 Systems Analysis and Design © University of Sheffield 2005 More about ATM transactions  Manage PIN, Get balance, Withdraw cash are presented below… 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 PINIt allows changing the four digit PIN with a new value. Get balanceIt displays/prints out the current balance of the bank account. Withdraw cashThe customer chooses an amount to be withdrawn either from a list or enters a free choice amount. It is checked that the requested amount is less than the current balance of the associated bank account – including the overdraft limit; it is also checked that the requested amount is under the amount that can be withdrawn from the card per day; lastly it is checked that the requested amount is available in the ATM dispenser. When all these conditions are true then the bank account, the card day limit and the dispenser amount are updated, the card is released and the cash is dispensed; if one of these conditions is false then the customer will be prompted to consider another option.

6COM6030 Systems Analysis and Design © University of Sheffield 2005 First part of the course > relationship between use cases > is represented as X use case Y use case > It shows that X use case uses Y use case When some functionality (behaviour) is used more than once in a system specification then it is worth factorising it out as a separate component – this will be used by various use cases; the set of use cases is revisited. Find address Send invoice Deliver goods This approach is usually part of a second iteration of requirements analysis stage when use case diagrams are employed. >

7COM6030 Systems Analysis and Design © University of Sheffield 2005 ATM – use cases with > In the ATM system Insert card & validate PIN identifies both the PIN and the bank account that are used by other use cases.  Identify Provide PIN and Provide bank account as common behaviour to other use cases.  Use Provide PIN and Provide bank account as new factorisations in the current system.  The natural language description as well as use case descriptions need to be reconsidered. Provide PINIt provides the PIN captured by Insert card & validate PIN or the one modified by manage PIN. Provide bank account It provides the bank account identified when the PIN is validated.

8COM6030 Systems Analysis and Design © University of Sheffield 2005 ATM system with > Insert card & validate PIN Manage PIN Withdraw cash Get balance ATM system Customer Bank Provide PIN Provide bank account >

9COM6030 Systems Analysis and Design © University of Sheffield 2005 ATM new use cases 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; PIN number and bank account will be recorded. Manage PINIt allows changing the four digit PIN with a new value; updated PIN recorded. Get balanceIt displays/prints out the current balance of the bank account using the PIN number and bank account provided. Withdraw cashThe customer chooses an amount to be withdrawn either from a list or enters a free choice amount. It is checked that the requested amount is less than the current balance of the associated bank account – including the overdraft limit; it is also checked that the requested amount is under the amount that can be withdrawn from the card per day; lastly it is checked that the requested amount is available in the ATM dispenser. When all these conditions are true then the bank account, the card day limit and the dispenser amount are updated, the card is released and the cash is dispensed; if one of these conditions is false then the customer will be prompted to consider another option; PIN number and bank account provided are used. Provide PIN … Provide bank account …

10COM6030 Systems Analysis and Design © University of Sheffield 2005 > relationship  When a use case incorporates two or more different scenarios then these may be represented as different use cases: a main use case and some subsidiary cases.  Use the > arrow from the less central (exceptional case) to the main case.  Used when variants different from the main behaviour are identified. Deliver goods Print invoice Print unavailable goods > -- Exceptional case -- Optional situation

11COM6030 Systems Analysis and Design © University of Sheffield 2005 ATM system with > Insert card & validate PIN Manage PIN Withdraw cash Get balance ATM system Customer Bank Refuse withdraw insuff cash Refuse withdraw insuff day limit Refuse withdraw insuff balance >

12COM6030 Systems Analysis and Design © University of Sheffield 2005 Summary on >, >  > relationship is considered to  show how the system can use a pre-existing component;  show common functionality between use cases;  document a new reusable component developed by the current project.  > relationship shows  an optional case that is different from the main use case;  an exceptional case that is considered by the main use case.  > and > define new relationships among use case.  Are addressed by the next iteration stages.  Use case descriptions are updated in each iteration stage.

13COM6030 Systems Analysis and Design © University of Sheffield 2005 Activity diagrams (recap) 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 …… More complex use cases and parallel behaviour will be addressed on the next slides.

14COM6030 Systems Analysis and Design © University of Sheffield 2005 Cash withdrawal – complex scenario Select amount Check customer’s card day limit Check customer’s balance Check dispenser Return cardRelease cash [amount>balance] [amount<=balance] [amount>day limit] [amount<=day limit] [amount>available cash] [amount<=available cash]

15COM6030 Systems Analysis and Design © University of Sheffield 2005 Activity diagrams – relating use cases [withdraw cash] [don’t withdraw cash] [get balance] [don’t get balance] [PIN operation] [no PIN operation] [exit][no exit] Insert card & validate PIN Choose from menu Withdraw cash Display balance Manage PIN Display errorReturn card

16COM6030 Systems Analysis and Design © University of Sheffield 2005 Activity diagrams – business process  Activity diagrams may describe some more general business processes.  Some processes may run either in parallel or in an arbitrary order – it requires the use of the synchronisation bar and join/fork primitives.

17COM6030 Systems Analysis and Design © University of Sheffield 2005 ATM – business process Wait in queue Remember PINInsert card Type in & validate PIN Perform transaction Return card The order of these activities is not important

18COM6030 Systems Analysis and Design © University of Sheffield 2005 Business process & swimlanes Library memberLibrary assistant Wait in queue Identify book(s) Go to library desk StampRecord Give book(s) to library member

19COM6030 Systems Analysis and Design © University of Sheffield 2005 Summary  Use case diagrams capture iteratively requirements stages.  Systems, subsystems, actors and basic case studies – first iteration.  Functionality common to several use cases and unusual cases is captured via > and > in later iterations.  Relationships between use cases, complex behaviour, control mechanisms, parallel processing are expressed through activity diagrams.