Introduction to UML

1. Introduction to UML Use Case Diagrams

2. Today we will cover • Unified Modelling Language (UML) • Use Case Diagram

3. What is UML? • Unified Modelling Language • A language for specifying, visualising & constructing the descriptive diagrams and documentation of software systems • Industry standard for object-oriented modelling • Helps in designing and describing software systems • Communicate & understand ideas • “A picture is worth 1000 words”, • We’re aiming for a well-designed, robust & 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? 3

4. Useful material • There are many good books on UML, such as • “Teach Yourself UML in 24 hours” by Joseph Schmuller • Stevens P. with Pooley, R. (2000) Using UML: Software Engineering with Objects and Components, Addison-Wesley, Harlow, Essex, UK • “UML Distilled Third Edition” by Martin Fowler • There are also a lot of websites with suitable materials, such as • http://bdn.borland.com/article/0,1410,31863,00.html • http://www.agilemodeling.com/essays/umlDiagrams.htm • Tools for UML • ArgoUML, argouml.tigris.org • Commercial software, e.g. Microsoft Visio & IBM Rational Rose • A list of open-source & free UML editors:www.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools 4

5. UML Diagrams Structural modelling diagrams • Class diagrams Describe the static structure of the system: Objects, Attributes, and Associations. • Object diagram Describe a set of objects and their relationships • Component diagram Describe the various components in a system and their dependencies • Deployment diagram Shows the physical relationships among software and hardware components in the delivered system 5

6. UML Diagrams Behavioural modelling diagrams • Use Case diagrams Describe the functional behavior of the system as seen by the user. • Sequence diagrams Describe the dynamic behavior between actors and the system and between objects of the system • State Machine Diagrams Show system states and events that cause transition from one state to another

7. Use case diagrams • Use Cases: • Technique for capturing functional requirements of a system • Describe typical interactions between users of a system and the system itself • When to use? • Use cases are used in almost every project. • They are helpful in exposing requirements • During the initial stage of a project most use cases should be defined, but as the project continues more might become visible.  7

8. Use case diagrams • A scenario is a sequence of steps describing an interaction between a user and a system • Scenarios model the goal of the user (an actor) • An actor is a role that a user plays with respect to the system • A use case is a set of scenarios tied together by a common user goal

9. join reserve book borrower borrow book return book add stock librarian remove stock Use case diagram for library Here’s an example of a use case diagram showing the use cases for a library

10. Use case diagram notation ACTOR SYSTEM BOUNDARY LINK borrower borrow book USE CASE

11. 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 representative logs call • Driver starts car • Alarm system alerts duty officer • Timer triggers email

12. PurchaseTicket Use Case A use case represents a class of functionality provided by the system as an event flow. A use case consists of: • Unique name • Participating actors • Pre-conditions • Entry conditions (triggers) • Flow of events • Exit conditions (success ‘guarantees’) • Special requirements

13. 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 E.g. • money is withdrawn from ATM • book is borrowed from library • “Unhappy” scenarios, or “extensions” are when things don’t go so well. E.g. • wrong pin number entered • member has maximum number of books out already

14. 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 • Extensions: 3a. Borrower already has borrowed maximum number of books • The loan cannot happen

15. Notes on the description • The borrower is the actor that initiates the loan • The inputs to 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 & 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

16. One more example • A Web-based on-line store • Buy a Product scenario:The customer browses the catalog and adds desired items to the shopping basket. When the customer wishes to pay, the customer describes the shipping and credit card information and confirms the sale. The system checks the authorization on the credit card and confirms the sale both immediately and with a follow-up e-mail. • Potential exceptions: • the credit card authorization might fail… • Other extensions: • a regular customer doesn't need to input shipping & credit card info…

17. USE CASE: Buy a Product GOAL: To buy a product ACTORS: Customer, System Main Success Scenario: • Customer browses catalogue and selects items to buy • Customer goes to check out • Customer fills in shipping information (address; next-day special delivery, or 1st class delivery) • System presents full pricing information, including shipping • Customer fills in credit card information • System authorises purchase • Systems confirms sale immediately • System sends confirmation e-mail to customer Extensions: 3a. Customer is regular customer • System displays current shipping, pricing and billing information • Customer may accept or override these defaults, returns to MSS at step 6 6a. System fails to authorise credit card purchase • Customer may re-enter credit card information, or may cancel • There is no standard way to write the content of a use case

18. 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

19. Use cases : extend • An extension is a significant exception to the normal case Borrowing refused <<extend>> borrower borrow book

20. borrow book Borrower : books only borrower borrow CD Borrower : books and CDs 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.

21. ATM Requirements Capture • A simplified Automatic Teller Machine • Which requirements are to be captured? • The activities in Requirement capture • Identification of system boundaries: actors and use cases • Diagramming use cases • Elaborating scenarios • Diagramming scenarios

22. A Simplified Automatic Teller Machine • The ATM is associated with only one bank • It gives access to all the accounts the customer owns in the bank • Several types of transactions can be chained in a single session • Withdrawal, deposit, transfer between the customer’s own accounts, consulting an account • The customer may obtain a printed receipt for each transaction

23. A Simplified Automatic Teller Machine (cont. 1) • The card contains • an ID number • an expiration date • a secret code • The card must be verified by the ATM • The customer cannot make more than 3 attempts to enter the correct code, otherwise the card is swallowed • Interface • Keyboard and screen, with menus • The customer may cancel the current transaction at meaningful points

24. A Simplified Automatic Teller Machine (cont. 2) • The connections with the bank are kept to a minimum • When a session is opened, a connection makes it possible to known all the accounts the customer owns • Every night, the information about the current day transactions are transferred to the bank • From time to time an employee manually • empties the machine and/or fills it with bank notes • supplies consumables and does any maintenance that may be needed

25. Which requirements are to be captured? • Functional requirements • Modeled as Use Cases • Non functional requirements • Some are specific to one use case • Some relate to technical issues addressed by implementation diagrams and models • Other in some supplementary documents, out of the UML scope…

26. Identifying System BoundariesIdentifying Actors • Actors are anything which interact with the system • People, other systems, hardware, software, networks… • They are roles, not necessarily full-fledged objects • Actors are not part of the system • They are just at the boundary (external to the system) • They won’t produce code!

27. Customer Bank Technician Identifying System BoundariesIdentifying Actors (cont.) • ATM example • Customer using the teller machine • Bank • Maintenance technician

28. Identifying System BoundariesIdentifying Use Cases • Use cases describe the services the system must perform from the point of view of the actors • Functional description • From a usage point of view

29. system boundary Bank Customer Technician Diagramming Use CasesTop Level Use Case Diagram Handle Session Transfer Daily Maintain

30. « include » « include » « include » Handle Transaction « include » AuthenticateCustomer « extend » Get CustomerInformation Diagramming Use CasesStereotyped Dependencies HandleSession VerifyCard Deliver Receipt

31. Included Extending « include » « extend » Including Extended Diagramming Use CasesStereotyped Dependencies • « include » • The included use case is a mandatory part of the including one • « extend » • The extending use case is an optional part of the extended one (functionality-wise, not actor-wise)

32. Handle Withdrawal Handle Consult Handle Transfer Diagramming Use CasesGeneralization Handle Transaction Handle Deposit

33. Elaborating scenariosUse Case and Scenarios • Use cases classify the ways of using the system • To each use case correspond many possible usage scenarios • Thus scenarios • are instances of use cases • specify use cases • Each use case has generally • a primary scenario, possibly several (a few) • several secondary (more exceptional) scenarios

34. HandleSession « include » « include » Handle Transaction VerifyCard « include » « include » AuthenticateCustomer Get CustomerInformation Elaborating Scenarios for Use Cases Use Case: Handle Session Precondition: the ATM is free Primary Scenario • The Customer inserts the card into the ATM. • The ATM verifies the card validity. • The Customer authenticates with the ATM. • The ATM gets the Customer information from the Bank. • The Customer selects a transaction. • The Customer quits. • The ATM ejects the card. Postcondition: the ATM is free

35. Elaborating Scenarios for Use CasesAlistair Cockburn’s style (2) Use Case: Handle Session Precondition: the ATM is free Primary Scenario • The Customer inserts the card into the ATM. • The ATM verifies the card validity. • The Customer authenticates with the ATM. • The ATM gets the Customer information from the Bank. • The Customer selects a transaction. • The Customer quits. • The ATM ejects the card. Postcondition: the ATM is free Variants 2a The card is invalid; the ATM swallows it; this ends the session. 3a The Customer fails to authenticate; the ATM swallows the card; this ends the session. 4a The connection with the Bank is impossible or interrupted; the ATM ejects the card; this ends the session. 5a The Customer may quit immediately. 6a The Customer chooses to perform another transaction; goto step 5. * The Customer may cancel the session; the ATM ejects the card.

36. Elaborating scenariosPrimary Scenario Use Case: Handle Session Scenario: Primary (typical) Precondition: the ATM is free • The scenario starts when the customer inserts the card • The card is accepted • The customer enters the secret code correctly • The ATM gets the customer information from the bank • The customer performs a transaction • When the transaction is finished, the customer may ask for another transaction (go to 5) or quit • The scenario is finished when the customer decides to quit; the card is ejected Postcondition: the ATM is free

37. Elaborating scenariosExample of Secondary Scenarios Use Case: Handle Session Scenario: Secondary (customer interrupt) Precondition: the ATM is free • The scenario starts when the customer inserts the card • The card is accepted • The customer enters the secret code correctly • The customer cancel the session • The card is ejected and the scenario is finished Postcondition: the ATM is free

38. Note • Don’t get too involved with the diagrams • 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 • There is no right or wrong design • There can be good or bad design

39. Exercise • Draw a use case diagram for a voting machine, on which voters can see a list of candidates and select one to vote for. The machine should check that each voter is eligible to vote. The electoral registrar will also want to print a summary of the total votes for each candidate. The electoral registrar will also want to see a list of voters who have voted and a list of those who haven’t. in case of a dispute, the machine should also list a complete record of who voted for whom, but only a judge can use this function.

40. An example of application of Object-Oriented Analysis and Design http://www.cs.gordon.edu/courses/cs211/ATMExample/index.html 40