Software Engineering Foundations

Dept of Computer Science Software Engineering Foundations Introduction to UML Use Cases Activity Diagrams Monica Farrow EM G30 email : M.Farrow@hw.ac.uk Material available on Vision F21SF1 Use case and Activity diagrams

Topics • Introduction to UML • Use Cases • Activity Diagrams • Class diagrams and Sequence diagrams were introduced in previous lectures and summarised in ClassSeqDiags.doc. • Also read Case Study on Noughts and Crosses • A different sort of problem, but still using UML F21SF1 Use case and Activity diagrams

Object-oriented Design questions • We’re aiming for a well-designed, robust and maintainable object-oriented system which meets the users’ requirements • What does the user require? • Which classes should there be? • What responsibilities should each class have? • How should objects interact? F21SF1 Use case and Activity diagrams

Where did UML come from ? • Unified Modeling Language • From the late 1980’s to the early 1990s, many languages were developed for modelling object-oriented design graphically • In 1997 Booch, Rumbaugh,Jacobson (called ‘3 Amigos’) combined the best ideas into UML • Now UML is an open standard controlled by the Object Management Group, a consortium of companies • www.omg.org • UML2 is the later version, so you may see small differences in older books or websites F21SF1 Use case and Activity diagrams

How it can be used • Sketch - recommended • Informal • Selective – ONLY use it if the problem is complex and therefore the diagram helps • Blueprint • Complete • Usually too time-consuming, especially if design changes • Programming language • Diagrams transformed to executable code • Not widespread F21SF1 Use case and Activity diagrams

Topics covered in this module • Use cases • How people interact with the system • Activity diagrams • Shows workflow, how software and human activities interact • Class diagrams • Used both from the conceptual and the software perspective (i.e. design and documentation) • Sequence and communication diagrams • Interaction between the classes for common scenarios • State machine diagrams(mentioned, covered in Advanced Software Engineering) • Shows changes in the state of an object F21SF1 Use case and Activity diagrams

Use CasesHow people interact with the system F21SF1 Use case and Activity diagrams

Use Case • Use Cases describe the main processes in the system, from the users’ perspective. • Look at the next 2 slides to get an idea of what a use case diagram and textual description look like, then read the following slides to find out more details. F21SF1 Use case and Activity diagrams

Use Case Diagram for Library join reserve book Here’s an example of a diagram showing all the use cases for a library borrower borrow book return book add stock librarian remove stock F21SF1 Use case and Activity diagrams

The textual description for the ‘Borrow’ use case USE CASE: Borrow GOAL: To borrow a library book ACTORS: Borrower, System • Main success scenario • Provide card with membership bar code • Provide book with bar code • System checks membership • System records loan to borrower for 3 weeks • Borrower leaves with the book • Alternatives 3a Borrower already has borrowed maximum number of books • The loan cannot happen 3b Borrower has outstanding fines to pay • Borrower may pay fines, in which case system updated to show this. • Continue from 4 F21SF1 Use case and Activity diagrams

Use Case • A Use Case is a textual description of the processes in the system, from the users’ perspective. • They describe the interaction between a user and the high level functions within the system. • A user can be a person, another information system, or a hardware device : anything that triggers or is involved in the system • E.g. • Library Use Case: Borrow book • VCR Use Case: Set Timer • IT Help Desk Use Case: Log issue F21SF1 Use case and Activity diagrams

Use Case Diagram - notation SYSTEM BOUNDARY ACTOR LINK borrower borrow book USE CASE F21SF1 Use case and Activity diagrams

Actors • An actor indicates a role played by an external person or system which is involved in a use case • The same person or system may play the role of more than one actor, depending on the context • E.g. maybe a librarian is also a borrower • An actor may be involved in more than one use case • Actors initiate and/or respond to use cases e.g. • Sales rep logs call • Driver starts car • Alarm system alerts duty officer • Timer triggers email F21SF1 Use case and Activity diagrams

Diagrams and textual description • You should always make a list of use cases and for each one, write a textual description. An example is given a few slides back. Look back at the example while you read the next few slides. • There’s not a lot of point drawing a use case diagram with 1 actor and 2 or 3 use cases – a simple list of the use cases would do • Use the diagram whenever the situation is more complex F21SF1 Use case and Activity diagrams

Scenarios • A Scenario is a sequence of steps describing an interaction between a user and a system. • Each use case is likely to have several scenarios • The ideal or ‘happy’ scenario is when the process works as normal. This is the primary business flow : it does not cater for any errors in the system or any user entry errors. • money is withdrawn from ATM • book is borrowed from library F21SF1 Use case and Activity diagrams

Scenarios • ‘Unhappy’ scenarios, or ‘extensions’ are when things don’t go so well • wrong pin number entered • member has maximum number of books out already • Numbering of extensions – e.g. 3a means that the extension relates to step 3, and the ‘a’ identifies it as the first thing that might go wrong. Other problems for this step would be numbered b,c etc • After identifying the extension, list the steps that must be taken. This should clearly show whether the process stops or resumes at another step. F21SF1 Use case and Activity diagrams

Notes On The Description • The borrower is the actor that initiates the loan • The inputsto the use case are identified • The book code, the membership code • The outcomes are identified • The borrower leaves with the book, the loan is recorded in the system • The exceptions are identified and the alternative outcomes are given. • The borrower already has 6 books out : loan refused • This use case is adequate for the users to agree that it is accurate, without becoming a design. • The cheapest place to sort out errors in the requirements is at this stage F21SF1 Use case and Activity diagrams

Use Cases : include (used to be ‘uses’) • Some use cases may share one or more common steps Reserve book <<includes>> Check membership borrower <<includes>> Borrow book F21SF1 Use case and Activity diagrams

Use cases : extension • An extension is a significant exception to the normal case Borrowing refused <<extends>> borrower borrow book F21SF1 Use case and Activity diagrams

borrow book borrower borrow CD Use Cases: generalisation • Actors and use cases can be generalised, showing that one is simply a special case of the other • This is like inheritance in object-oriented design • Suppose that to borrow a CD, users must have additional registration and pay per CD. Borrower : books only Borrower : books and CDs F21SF1 Use case and Activity diagrams

Simplifying Complex Use Cases Break large/complex use cases down into smaller and more manageable use cases – is this a good diagram?

Is the previous diagram OK? • It is often necessary to break up a complex use case into components before a suitable Use Case description can be written. • Do create sub-use-cases and write the description • Sub-use-cases in a diagram are particularly useful if they each involve different actors. • BUT, the diagram on the previous slide doesn’t show anything that couldn’t be shown with • A simple list, if no conditions • An activity diagram (next topic) if conditions exist • Current thinking is that the previous slide is not a good use of a diagram. F21SF1 Use case and Activity diagrams

Finally • Don’t get too involved with the diagrams. Remember that the textual description is more important. • You will see slight variations in the use of use cases, due to different use and versions of UML • There is no one right answer to any question associated with design. F21SF1 Use case and Activity diagrams

Activity Diagrams F21SF1 Use case and Activity diagrams

Activity Diagrams overview • Activity diagrams model flow of control in a system • States have transitions to other states • States may be either • action states: atomic action • activity states: actions that can be broken down • They may have decisions, explained by conditions, and merges • They may have forks and joins for modelling simultaneous activities (not covered here) F21SF1 Use case and Activity diagrams

The basic notation Action / Activity • Long rounded rectangle Start / Initial State • unique with only one transition line End State • not necessarily unique Transition • Lines indicate sequential flow of actions. Must be labelled after a decision. • Arrows indicate direction of next action Activity is shown in more detail in another diagram Process loan F21SF1 Use case and Activity diagrams

Decision Points and Guards • Decision point : diamond • Single entry transition line • Multiple exit transition lines • each with Guard (condition) • Exit lines must cover all eventualities • There could be a problem with the decisions in this diagram. What do you think it is? [sunny] [rainy] socks sandals shoes F21SF1 Use case and Activity diagrams

Merge Points • Merge : diamond • Are used to indicate a merge after a decision • Multiple entry, single exit • In UML1, more than one transition line can enter an activity. • In UML2 (and in this module!), use merge diamonds. [sunny] [rainy] socks sandals shoes sandals shoes go out go out UML1 F21SF1 Use case and Activity diagrams

A mathematical formula, showing process flow n! = n * (n-1) * (n-2) * … * 1 Notes In the format n! = result result = 1 counter = 1 [n== 0, n== 1] [n>1] print ( result ,n ) result = counter * result counter += 1 [counter > n] [counter <=n] F21SF1 Use case and Activity diagrams

Take-away meal • Draw an activity diagram for this situation: When I order a take-away meal, I phone the Chinese restaurant, give him my phone number, and his computer will automatically display my address if I’ve ordered before. But if I’m a new customer calling for the first time, he must get my address before he takes my order. F21SF1 Use case and Activity diagrams

Take-away meal diagram F21SF1 Use case and Activity diagrams

Synchronisation • When modelling activities, you sometimes need to show that certain action sequences can be done in parallel (synchronously, concurrently, simultaneously). • You are buying some items from a shop like Argos. • First you fill in a form showing which items you want to buy. • Then you take it to a desk where a member of staff enters the items into a computer. • If all of these items are in stock, you pay for them, and AT THE SAME TIME, staff in the warehouse are picking the items off the shelves for you. • You collect the items, but ONLY WHEN you have finished paying AND when the items have been picked out and sent to the collection desk F21SF1 Use case and Activity diagrams

Fork and Join • Fork • Shows start of concurrent actions • The thread within each exit can be executed at the same time as the other thread • Single entry, multiple exits • Join • Shows end of concurrent actions • The exit cannot occur until all entry threads have been completed • Multiple entry, single exit F21SF1 Use case and Activity diagrams

Shopping in Argos (assuming all items in stock) • The fork shows that the payment can be processed at the same time as the items are being picked out and sent for collection. • The join shows that you can’t collect them until the payment has been processed and also the items have been picked out and sent for collection Fill in form Items entered into computer Items picked process payment Sent for collection Collect items F21SF1 Use case and Activity diagrams

Synchronization and decisions • Beginners often get confused here. • Use a fork/join if the actions can be done • at the same time • if the order does not matter • but both must be done before continuing • In the Argos example, if the warehouse is busy, the items may not be picked until after the payment is processed. The fork shows that these actions CAN be done at the same time – but they don’t have to be. The join shows that they must both be done before continuing. • Do NOT use a join after a decision – use a merge. • We can’t model forks and joins in the java applications this course F21SF1 Use case and Activity diagrams

Another example F21SF1 Use case and Activity diagrams

Eating dinner • Draw an activity diagram to model eating dinner, including a fork and a join You have to decide whether to eat at home or in a restaurant. If you eat in a restaurant, you go there, order your meal, and eat it. If you stay at home, you have to find a recipe, find the ingredients, and cook it. You need to lay the table. Finally you eat your dinner.In this scenario, assume that nothing goes wrong – all ingredients are in the house, there is a table in the restaurant etc etc. F21SF1 Use case and Activity diagrams

Swimlanes / partitions • Useful to model activity's procedural flow of control between objects • Use vertical columns • Assign column object’s name • placed at the top of the column • Place each action associated with an object in that object's swimlane F21SF1 Use case and Activity diagrams

Swimlanes/ partitions example : library Librarian Member [borrowing] Find book on shelf [returning] Wait in queue [returning] [borrowing] Process return Process loan F21SF1 Use case and Activity diagrams

Expanding one action : library Process return Record return [reserved] [not reserved] Place book back on shelf Place book In reserved pile F21SF1 Use case and Activity diagrams

The activity diagram's purpose • Activity diagrams are used to • Communicate effectively • Clarity and simplicity • Model the procedural flow of actions that are part of a larger activity • Model a specific use case at a more detailed level • Model business-level function or flow of program code F21SF1 Use case and Activity diagrams

The activity diagram's focus • Focuses on the action sequence of execution and the conditions that trigger or guard those actions. • Focused on the activity's internal actions and not on external actions • Activity diagrams show all potential sequence flows in an activity, whereas a sequence diagram (covered in a later lecture)typically shows only one flow of an activity F21SF1 Use case and Activity diagrams

Activity diagrams, statechart diagrams & UML2 • In UML1 they were considered to be a special case of statechart diagrams (covered later in the course) • Not really appropriate • UML2 • Not a special case of statechart diagrams • Always use merge or join explicitly • Further features • They can be used to show more details such as timing and parameters (not covered in this module) F21SF1 Use case and Activity diagrams

Try it yourself • Draw a high-level use case diagram for the use of an ATM machine. Write a textual description for the main scenario of the use case to withdraw money, with alternatives • Then draw the corresponding activity diagram for the withdraw money use case • Answer available on website F21SF1 Use case and Activity diagrams

Software Engineering Foundations