UML for Use Cases, Jan 4/5 2006 Introduction to UML and Use Case Diagrams Richard Hopkins rph@nesc.ac.uk NeSC Training

1. UML for Use Cases, Jan 4/5 2006Introduction to UMLandUse Case DiagramsRichard Hopkins rph@nesc.ac.ukNeSC Training Team Member

2. Goals and Overview • Goals – • To explain the context and overall approach for UML and its Use Case diagrams • Overview • UML History and concepts • Use Case Diagrams • Practical

3. History of UML • Use of diagrams • In any discipline for the construction of complex artefacts • Need to use diagrams, as tools for • Thinking • Communicating • As discipline matures, diagrams become - • Standardised – For effective communication between all practitioners • Stylized – Specialised technical language for compact representation • UML – M is for Models • A diagram is a model of the (proposed) system • A partial representation of some aspect of the system

4. History of UML • Historically • A variety of stylised diagram languages • Each associated with a design methodology • A formalised Process for arriving at a design • E.g., for Object-oriented design (early 90’s) • Grady Booch’s OOD – Object-Oriented Design • James Rumbaugh’s OMT – Object-oriented Modelling and Design • Ivar Jacobson’s OOSE – Object-Oriented Software Engineering • Competing Methodologies • Rather improbably – • Rumbaugh joined Booch, with intention of merging their methods • They bought out Jacobsonn’s company – Objectory • These three aimed for a single Unified Method

5. Methodology vs Notation • Generally need different methodologies for different contexts • Small application in four weeks by single programmer • Large system in four years by 200-strong development organisation • Often “use of X methodology” was actually • use of “X’s” notation • with methodology appropriate to context • Strong reasons for using the same notation • Concept of Unified Method, changed to Unified Modelling Language

6. Methodology vs Notation • UML is NOT a methodology • UML is a notation for recording the results of • A requirements gathering / design process • Carried out using some methodology – maybe! • Any kind of diagram can be used for any purpose that is useful • Sufficiently general that could be used with any imaginable O-O methodology • A typical Methodology -

7. Sequence Diag. Sequence Diag. An Overall Development Process These diagram types, and the process can be used both for • Designing a new system • Understanding an existing system e.g example scenarios Partially articulated requirements Capture Requirements Requirements Use Case Diag. … Construct Model of Overall system Class Diag. Structure … Behaviour

8. Goals and Overview • Goals – • To explain the context and overall approach for UML and its Use Case diagrams • Overview • UML History and concepts • Use Case Diagrams • Practical

9. Introducing the Library Example • A computer system for a university library; • The purposes include • Keeping track of when items are borrowed/returned • Allowing users to search for an item and check availability • The library has two kinds of members – • Staff • Students • The library contains two kinds of items - • Books • possibly several copies of each book • Some books are for short-term loan only – only students can do short-term loans • Journals • Only staff may borrow journals

10. Borrow Copy of book Return Copy Notify Lost Copy Simple Use Cases An Actor – • a user of the system, in a particular role • “BookBorrower” is a role played by library members • Usually a person, but could be another system • An entity outside the system being modelled Update Catalogue BookBorrower Librarian A Use Case – • An example of the behaviour of the system – more general than our previous formulation • “Borrow Copy of Book” describes the successful outcome – there will be variants for the exception cases - This Actor participates in this Use Case

11. Return Copy Notify Lost Copy Use Case Documentation Use Case Documentation • Not a very rich diagram • Needs more explanation – associated documentation • Our previous Use Case description – could be anything • Use Case: Borrow copy of book. • Summary: … • Actors: BookBorrower … • Stakeholders: …. • The bookBorrower presents a book. • The system validates that the potential borrower is a member of the library, • The system validates that s/he does not already have the maximum permitted number of books on loan. ( The maximum is 6 unless the member is a staff member, in which case it is 12.) • The system records that this library member has this copy of the book on loan. Borrow Copy of book BookBorrower Update Catalogue Librarian

12. Return Copy Borrow Copy Notify Lost Copy Return Overdue Copy Return Overdue Copy, deferring fine Notify Lost Copy, paying fine by credit card Return Overdue copy, paying fine by credit card Notify Lost Copy, deferring fine Just a list of Use Cases? • Likely to be commonality between these Use Cases • Counter-productive to repeat the common steps • Have relationships between Use Cases • Extension • Inclusion • Specialisation BookBorrower

13. <<extend>> Return Overdue Copy Use Case Relationships (A) show clerk – sometimes involved, sometimes not system might record which clerk Return Copy Clerk Book Returner Notify lost Copy <<extend>> – an “interuption” of the indicated base case <<include>> <<include>> Pay fine Defer fine <<extend>> Note – Participant Inheritance BookReturner & Clerk implicitly involved in Return Overdue Copy Pay Fine needs to be specific about participants <<include>> – allows common sub-structure to be factored out. Pay fine by credit card Generalisation /Specialisation– a special case of. Everything that happens in the general case also happens in the special case

14. Specialisation vs Extension Specialisation vs Extension Distinction not clear-cut (some say UML should not have both) For extension base case can document the conditions for the extension case (“extension point”) One possible decider - Generalisation is when user unilaterally chooses a variant Extension is when system detects the condition, or needs to check whether it is OK – testing internal system state Return Copy <<extend>> Return Overdue Copy <<include>> Pay fine Defer fine <<extend>> Pay fine by credit card

15. Use Case - Variants Library Reserve book personally Book Reserver Clerk Show system boundary With system name Particularly when A sub-system of A larger model Book Reserver Reserve Book electronically Reserve Book Authenticate User • The actor can be another system (a class) – • In this case a library enquiry and reservation system • Which is modelled as a separate system • Electronic vs Personal reservation have different requirements • E.g. user authentication is inside vs outside the system

16. Use Case Diagrams - Usage • Identification of Actors and functionalities • Requirements feed-back • To communicate to the clients what the providers have understood a being the requirements • DANGER – • generalisations, extensions and inclusions • make the diagrams too complex and technical for the clients to understand properly • Test Case generation • Do Design Walk-throughs (sequence diagrams) of all Use Cases • Implementation tests for all Use Cases

17. Use Case Diagrams - Usage • Identification of Actors and functionalities • Requirements feed-back • Test Case generation • To drive the system design (not a good use!) • Producing one module of code for each use case. • Leads to top down, function-oriented system • Loses the maintainability and flexibility benefits of object-oriented design • Keep focus on requirements documentation • Include what is important for understanding system functionality

18. Questions

19. Goals and Overview • Goals – • To explain the context and overall approach for UML and its Use Case diagrams • Overview • UML History and concepts • Use Case Diagrams • Practical

20. Practical – Use Case Elaboration Objective – to arrive a Use Case diagram for a collection of Use Cases which employ the relationships • Generalisation / Inclusion / Extension and have the potential for communication between several actors (systems) • Can use as any combination of • Your Use Case from previous practical • ?? Another Group’s Use Case from previous practical ?? • One or more of the Use Cases provided • organised into sets of related Use Cases • Invented variants to illustrate the relationships 1. Choosing base Use Case(s) for rest of practicals • 30 mins in total, e.g. • 15 mins – look at provided use case • 15 mins – decide which one(s) to use • make a second choice • report to me which you are doing

21. Practical –Use Case Elaboration • 2. Individually Draw A, using either • Word document template • Visual Paradigm for UML • 10 mins • 3. Use Case Structures • 90 mins in total • Work out alternatives to the chosen base Use Case(s) • Structure them using the extends etc. relationships • Draw the Use Case diagram • Document each use case variant – • using VP-UML notes or separate documents – up to you • 4. Swap – look at two other groups’ outputs • 45 mins