270 likes | 409 Views
UML The Unified Modeling Language A Practical Introduction. Al-Ayham Saleh. Al-Ayham Saleh. Aleppo University. 16-11-2003. Importance of software Modeling. A software application is like a city Modeling = Architecture OOP = Civil Engineering UML Classes = Blueprints of Buildings
E N D
UMLThe Unified Modeling LanguageA Practical Introduction Al-Ayham Saleh Al-Ayham Saleh Aleppo University 16-11-2003
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
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
UML Diagrams • Use Case diagrams • Class diagrams • Object diagrams • Sequence diagrams • Collaboration diagrams • State chart diagrams • Activity diagrams • Component diagrams • Deployment diagrams
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
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.”
Example Use Case diagram • A Use Case diagram is a summary of Use Cases
Use Case Diagrams • Use Case diagrams show the system boundaries
Use Case Diagrams • Generalization = one is a special kind of the other
Use Case Diagrams • Includes = one invokes the other
Use Case Diagrams • Extend = one is a variation of the other
Understanding Use Cases • Ask “what”, “when”, “why” questions • Explain what you understand • Keep doing that until you get a precise mutual understanding
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
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)
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.
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.
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
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…
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
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
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
The Use Case toolbar in Rational Rose Package Use Case Actor Message Dependency Generalization
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