a software application is like a city modeling = architecture oop = civil engineering uml classes...
TRANSCRIPT
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.”
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