UML Dynamic Models
This is one a part of a set of notes on the Unified Modelling language --
[ uml.html ]
Scenarios and UseCases
Scenarios and Use-Cases are an ideal place to start a project.
They must be expressed in terms that the user and client understands
and can (and should) avoid all technical jargon. The set of usecases
answer the questions:
- Who wants to use this software?
- What do they want to do with it?
A scenario describes a particular user getting something useful done.
A usecase is a set of similar scenarios all with the same type
of user and all ending when the user finds out that the process
is complete. The user must begin a usecase and must know when
it is complete. The user must be active entity - an actor - and
communicates with the system to achieve the goal of the usecase.
A usecase is written out in a natural language like English.
UML provides a notation for naming and classifying both actors and usecases.
Here is a UML diagram that shows three usecases: "add class", "drop class",
"get roster", and "submit work" and two actors: "Student" and "Teacher".
Notice the use of a "stick figure" to indicate a class of
actors. The usecase is indicated by an oval. Communication is
modeled as a simple link between an actor and an
It is also possible to use the UML generalization
relationship between classes of actors: For example a Graduate Student
might be a special kind of Student and so could share the
Add Class Scenario. The generalisation link is also used between
Usecases to indicate that one usecase is a special case of another one,
or that one usecase makes use of another one.
These allow you to work out how your classes can help the user solve problems.
Sequence diagrams make the timing of various operations clear. Collaboration diagrams are better for modelling a complex interaction or algorithm. There
is no reason why you shouldn't draw both.
Historically, Charles Babbage was the first person to draw a diagram were
each part of a machine was shown as a vertical line, time flows down the
page, and connections between the parts flow across the page. This idea
has been reinvented several times in the last 10 years.
The above diagram indicates the following sequence of events (inside
- JoDoe asks to drop a class, the request is handled by Jo's Student object -- -- --(jd)
- jd asks the Section --(s) to drop jd.
- s (the section) passes the message to an Enrollment --(e) which self-destructs.
- s reports success to jd.
- jd reports success to Joe.
Each vertical line indicates an existing object. When it is active it
the line becomes a rectangle. Connections can show flow and whether
it is synchronous(----->) or asynchronous(with only half an arrowhead!).
Normally the steps are described on the left hand side of the diagram.
A collaboration diagram shows how a collection of objects and classes
work together (Latin: co - labor = work together) to fulfill a
use-case. Each step in the process is numbered and follows a link from one
object to another. Here is an example - a first sketch of how
the system helps a student add a section:
The diagram above describes the following:
- Jo Doe, a student asks to add a class by giving Jo's student id -- -- --(sid)
and a section id--(sd).
- The student class uses the sid to get Jo's object -- (jd)
The jd object is passed to the section.
- The Section class uses the find operation to find the asked for Section object -- -- --(s)
- s finds out which course it is and passes s and jd into the
Enrollment class which
- constructs a new added enrollment linking jd to s.
Exercise. There are some obvious errors and ommissions in the above
diagram -- fix them!
. . . . . . . . . ( end of section Interaction Diagrams) <<Contents | End>>
State Transition Diagrams
State transition diagrams have been a part of computer science and computer
programming since the 1940's. David Harel in the middle 1980's reinvented
the state transition diagram in a form that has become popular in many
different notations and methods. UML incorporates Harel's StateCharts
as a way to work out, document and verify the gross patterns of behavior
of an object in a class.
The basic rules are easy to state.
- Draw only one object's chart at a time.
state is drawn as a box with rounded corners.
- Each state models a
set of possible object values that have similar behavior - but possibly
different attribute values.
- A state is in a different box if objects in these states behave differently.
- From each state draw an arrow to another state
if the object can change from one to the other in one step.
- Label the
arrow with the event that causes it.
- Show the initial state by drawing an
arrow from a black blob to the initial state.
- Show the destruction of the
object (if there is one) as an arrow going from a state to a
blob inside a circle.
Here are a pair of examples showing the life of an idealized Student.
You will notice that in the above pair of diagrams the bottom one has the
name of a state in the upper diagram. This means that the the state has
been refined. It is also possible to redraw the two diagrams as a single
diagram with the refinement replacing the unrefined state.
. . . . . . . . . ( end of section Dynamic Models) <<Contents | End>>
Note. In this glossary a definition is written like this
When there are several alternative meanings they are separated
by a vertical bar symbol: "|". This is an informal extension of
the notation John Backus and Pete Naur developed in 1960.
[ BNF in glossary ]
[ BNF in comp.text.Meta ]
[ algol60.syntax.html ]
UML::=Unified Modelling Language.
actor::=an entity that starts scenarios and gets results from them.
attributes::=values that an object or class is responsible for maintaining.
application_domain::=a collection of more or less similar solutions.
operations::=things that an object in a class knows how to do.
results::=the end points of a set of scenarios.
result::=the end point of a scenario.
scenarios::=plural of scenario.
scenario::=A description of how a particular actor achieves a tangible result.
subtype::=One class is a subtype of another class if all the operations
of the second class of object also apply to objects of the first type - perhaps in a different way.
usecase::=a set of scenarios sharing a a class of similar actors achieving similar tangible results documented by a natural language text and pictured as an oval.