Transcript UML A Practical Course

UML
The Unified Modeling Language
A Practical Introduction
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
Creating Use Cases in Rational Rose
Request
Actor 1
Use Case 1
Actor properties in Rational Rose
Use Case properties in Rational Rose
Message properties in Rational Rose
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