.Open UML Dynamic Models
. Introduction
This is one a part of a set of notes on the Unified Modelling language --
.See http://www/dick/samples/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:
.Box
 Who wants to use this software?
 What do they want to do with it?
.Close.Box

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

.Image uml.usecases.gif Four Usecases

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

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.

.Open Interaction Diagrams
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.
. Sequence Diagrams
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.

.Image uml.seq.gif A Sequence Diagram

The above diagram indicates the following sequence of events (inside
our program):
.Box
 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.
.Close.Box
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.
. Collaboration Diagrams
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:

.Image uml.collab.gif Add Class Collaboration Diagram

The diagram above describes the following:
.Box
 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.
.Close.Box
Exercise.  There are some obvious errors and ommissions in the above
diagram -- fix them!
.Close Interaction Diagrams
. 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.
.Set
 Draw only one object's chart at a time.
  A
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.
.Close.Set

Here are a pair of examples showing the life of an idealized Student.

.Image uml.states.gif State Diagram of a 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.
.Close Dynamic Models


. Glossary
Note. In this glossary a definition is written like this
.As_is 		defined_term::=what_the_term_means.
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.
.See http://www/dick/samples/glossary.html#BNF
.See http://www/dick/samples/comp.text.Meta.html#BNF
.See http://www/dick/samples/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.