UML The Unified Modeling Language A Practical Introduction

1. UMLThe Unified Modeling LanguageA Practical Introduction Al-Ayham Saleh Al-Ayham Saleh Aleppo University 16-11-2003

2. Importance of software Modeling • A software application is like a city • Modeling = Architecture • OOP = Civil Engineering • UML Classes = Blueprints of Buildings • UML is a common vocabulary for all software specialists

3. UML Modeling • A model is an abstraction of a situation • Models consist of objects • Objects are alive: • They know their attributes • They can do things using their methods • They exist in different states • Each object is unique, it is not any other object. • Objects live in communities • they exchange messages • They have relationships with each other • Objects live in a world, and there are other worlds • Classes are blueprints of objects • Object are instances of classes

4. UML Diagrams • Use Case diagrams • Class diagrams • Object diagrams • Sequence diagrams • Collaboration diagrams • State chart diagrams • Activity diagrams • Component diagrams • Deployment diagrams

5. Use Case Diagrams • Describe what the system does from the view of an external observer. • Use cases represent scenarios of what could happen to the system. • A Use Case is a summary of a scenario of some related tasks

6. Example Use Case • “A patient calls the clinic to make an appointment for a yearly checkup. The receptionist finds the nearest empty time slot in the appointment book and schedules the appointment for that time slot.”

7. Example Use Case diagram • A Use Case diagram is a summary of Use Cases

8. Use Case Diagrams • Use Case diagrams show the system boundaries

9. Use Case Diagrams • Generalization = one is a special kind of the other

10. Use Case Diagrams • Includes = one invokes the other

11. Use Case Diagrams • Extend = one is a variation of the other

12. Understanding Use Cases • Ask “what”, “when”, “why” questions • Explain what you understand • Keep doing that until you get a precise mutual understanding

13. Writing Use Cases • Use cases should be names using verbs • Use Cases should be described: • What makes them happen • What are the conditions that they happen • What are the input messages • What are the output messages • What are all the other conditions and restraints • What are the exceptions • Use Cases are tools use by Actors to get results

14. Why write Use Cases • Because Use Cases • Help you understand WHAT you are modeling • Help you communicate with your clients • Help you estimate your requirements • Help you introduce the system to your team • Help you plan your design phase • Help you plan your testing phase • Help you write your documentation (How-to’s)

15. How to write Use Cases • At least, you should describe: • Who are the actors • Why does it happen? (the goal and/or context) • When does it happen? (the triggering event) • What happens? (the normal flow) • What else? (alternative and/or exceptional flows) • What are all the business rules? • Do not bother writing how it happens.

16. Writing effective Use Cases • Actor names are in single. • Actors represent roles, not persons • Use case name is a verb followed by a direct object. • Show only Use Cases that are important to the user • Show only actors that are directly related to the Use Cases • Create many detailed Use Case diagrams to analyze requirements • Group common Use Cases in Packages.

17. Common Use Case pitfalls • Unclear system boundary • The Use Case is written from the system view • The actor names are inconsistent • There are too many Use Cases • The Actor to Use Case relationship is too complicated • The use-case specifications are too long • The use-case specifications are confusing • Incorrect description of the Use Case functionality • The customer doesn't understand the use cases • The use cases are never finished

18. Quiz 1 • A Use Case is • A diagram showing all the functionalities of the system • A functionality of the system • An interaction between parts of the system • A functionality that is used by some outside system to make the system perform some tasks for some reason • A Use Less thing…

19. Quiz 2 • Three items of interest in use case diagrams are: • Objects, activities, and communications • Actors, messages, and activities • Objects, use cases, and activities • Actors, use cases, and communications

20. Use Cases in Rational Rose • Start Rational Rose • Rose creates a new model, and prompts for template • Click Cancel to create an abstract UML model

21. Use Cases in Rational Rose • Close the default class diagram • Open the main Use Case diagram • You may want to place the diagram toolbar above the workspace

22. The Use Case toolbar in Rational Rose Package Use Case Actor Message Dependency Generalization

23. Creating Use Cases in Rational Rose

24. Actor properties in Rational Rose

25. Use Case properties in Rational Rose

26. Message properties in Rational Rose

27. Workshop • Imagine that you are responsible of modeling a specific system for a customer. • Define the actors of this system • Draw A Use Case diagram for the system • Define the name and its system boundaries. • Write a short and explanatory description for the system, the actors, and the Use Cases. • Make a draft requirement analysis • Make a draft design plan • Make a draft test plan • Make a draft documentation plan • Did you find the Use Case modeling useful? Explain your opinion Duration 90 minutes