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 happenWhat are the conditions that they happenWhat are the input messagesWhat are the output messagesWhat are all the other conditions and

restraintsWhat are the exceptions

Use Cases are tools use by Actors to get results

Because Use CasesHelp you understand WHAT you are

modelingHelp you communicate with your clientsHelp you estimate your requirementsHelp you introduce the system to your teamHelp you plan your design phaseHelp you plan your testing phaseHelp you write your documentation (How-

to’s)

At least, you should describe:Who are the actorsWhy 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