1. 1 Advanced DataBases 12-6212 Unified Modelling Language An Introduction and Use Case Lecture 2 Susan Curtis

2. 2 Provide structure for problem solving Experiment to explore multiple solutions Furnish abstractions to manage complexity Reduce time-to-market for business problem solutions Decrease development costs Manage the risk of mistakes Why do we model?

3. 3 UML: What is it? Rumbaugh's OMT Modeling: Rumbaugh ++ 1992 Jacobson's Objectory: Jacobson ++ 1992 Booch's OO Analysis and Design: Booch 1994 OMG has adopted it as standard Jacobson OOSE Use Case................….............…......... Sequence Diagrams Rumbaugh OMT Object Model State Transition Diagrams (STDs) www.omg.org

4. 4 Define an easy-to-learn but semantically rich visual modeling language Unify the Booch, OMT, and Objectory modeling languages Include ideas from other modeling languages Incorporate industry best practices Address contemporary software development issues –scale, distribution, concurrency, executability, etc. Provide flexibility for applying different processes Enable model interchange and define repository interfaces UML Goals

5. 5 UML Components Use Case Diagrams Class Diagrams State-Transition Diagrams Interaction Diagrams –Sequence –Collaboration Component Diagrams Deployment Diagrams

6. 6 The basic building blocks of UML are: –model elements (classes, interfaces, components, use cases, etc.) –relationships (associations, generalization, dependencies, etc.) –diagrams (class diagrams, use case diagrams, interaction diagrams, etc.) Simple building blocks are used to create large, complex structures –cf. elements, bonds and molecules in chemistry –cf. components, connectors and circuit boards in hardware Building Blocks

7. 7 Gathering Requirements “Ours is a world where people don’t know what they want and are prepared to go through hell to get it.” Scope. System Boundary User Requirements.

8. 8 Modelling requirements with ‘Use Cases’ A use case represents an atomic transaction through the system. A use case shows how the system uses data elements. The use case is the basis for the business rules that constrain your design. A use case provides for measurement and validation of the database product.

9. 9 Use Case Modelling in UML Staff contact client Actor Use case System boundary Communication association

10. 10 What is use case modeling? use case model: a view of a system that emphasizes the behavior as it appears to outside users. A use case model partitions system functionality into transactions (‘use cases’) that are meaningful to users (‘actors’).

11. 11 Use Cases Can Provide a Basis for:  Software code directory structure  Project management infrastructure  Work Allocation  Software integration and test  System test  Project Management metrics capture  Project Technical metrics capture

12. 12 Use Case and Database Modelling Basis of: What data does the user need? How will they use the data? –Must store all the data required for the system –Shouldn’t store data not required

13. 13 Interface Implications Each use case linked to an actor should be visible as a interface (menu) option If there is a sub-use case – particularly one that is labelled extends is a sub menu option A user should be able to see the transactions they can activate at the first menu level

14. 14 How to do Use case modelling ActorsUse Cases  Identify Actors and Use Cases model  Construct a use case model  Document the use case normal course of events  Identify use case dependencies  Document use case alternative course of events  Find potential objects  Select objects

15. 15 How to Identify Use Cases Use CaseA Use Case is a statement of functionality required of the software, expressed in the format ActorActionSubjectActorActionSubject An Actor represents a stimulus to the software system. The stimulus can be internal or external. An Action represents a capability of the software system. A Subject represents the item acted upon by an Action of the software system (potential object).

16. 16

17. 17

18. 18 Document the Use Case Normal Course of Events Actor who initiated it High level description Description of major steps (course of events) Preconditions (state before execution) Post-condition (state after execution) Assumptions Are there any alternative course of events? Remember - this will be used for testing!

19. 19 How to handle overlap between use cases?  Minor variants versus different use cases – a matter of judgement.  Use cases can have basic course and alternative course.  Can have a form of specialisation – one use case extends another. Can have a form of generalisation - several use cases have commonality (uses).

20. 20 A Simple Use Case Model

21. 21 Uses Uses implies a must do transaction

22. 22 Extends Extends implies a may do (optional) transaction

23. 23 Extends

24. 24 Scenarios A scenario is a step by step description of a particular instance of a use case. It gives an example of how one specific (named) actor goes through the use case. It will detail any exceptions to the main course through the use case. Scenarios are an excellent way of validating the user requirements.

25. 25 Using Rational Rose

26. 26 UML Components Use Case Diagrams Class Diagrams State-Transition Diagrams Interaction Diagrams –Sequence –Collaboration Component Diagrams Deployment Diagrams

27. 27 Object-Oriented Systems Analysis and Design using UML : Bennett, McRobb & Farmer. UML Toolkit : Eriksson & Penker. Object-Oriented Analysis : objects in plain English : Brown. Books in the library