 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

 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

 Use Case diagrams  Class diagrams  Object diagrams  Sequence diagrams  Collaboration diagrams  State chart diagrams  Activity diagrams  Component diagrams  Deployment 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

 “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.”

 A Use Case diagram is a summary of Use Cases

 Use Case diagrams show the system boundaries

 Generalization = one is a special kind of the other

 Includes = one invokes the other

 Extend = one is a variation of the other

 Ask “what”, “when”, “why” questions  Explain what you understand  Keep doing that until you get a precise mutual understanding

 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

 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)

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

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

 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