Diagram Editor : Design View
Spring 2001
Kyung Hee
University
1
Diagram Editor: Design View
The use case view of the diagram editor includes:
A use case diagram giving a structured view of the program’s
functionality
Use cases each of which describes a coherent subset of the system
from the user’s point of view
Realizations of use cases or collaborations of objects which support
that functionality.
Kyung Hee
University
2
Diagram Editor: Design View (cont’d)
However:
Realizations are snapshots: they only show particular examples, or special
cases of the system.
It is not feasible to define a system completely with collaborations: there
are too many of them.
Some more abstract way of describing the program’s design is
required.
Kyung Hee
University
3
Design models
 There are two important design models used in UML:
Class diagrams (static model) describe data: the classes that exist and how
they are related. They specify which object diagrams and collaborations
represent possible states of the system.
Statecharts (dynamic model) describe the behaviour of objects. They
specify the sequences of interactions that an object can participate in.

A particular form of state transition diagram
 Design models summarize the functionality specified in the use
case view
They present information in a way that’s convenient
For understanding the system by specifying the structure of the system
As a basis for subsequent development (ie coding).
 Acts as blueprints for further development.
Kyung Hee
University
4
Classes
 Decisions about classes have already been made in realizing
use cases. For example:
This immediately gives three of the classes in the editor, and
shows some ways in which their instances can be linked
together.
Kyung Hee
University
5
Classes (cont’d)
Classes in UML are denoted by rectangles labelled simply
with the name of the class.
Objects are instances of classes: this is shown by underlining
the class name in an object symbol. A colon separates the
object name, if specified, from the class name.
Kyung Hee
University
6
Associations
 Associations between classes specify that instances of the
classes can be linked at run-time. The links in the diagram
above imply that the following associations must exist between
the classes:
Kyung Hee
University
7
Associations (cont’d)
Just as objects are instances of classes, links are instances of
associations. UML makes a general distinction between
descriptors and instances:
Given only these associations, the following object diagram is
illegal, as there is no association corresponding to the link
between the two objects.
Kyung Hee
University
8
Multiplicity
 There are two important aspects of links that need to be
specified:
Which objects can be correctly linked together (type information).
How many objects can be linked simultaneously (multiplicity
information).
 For example, a diagram could contain two rectangles, but a
rectangle can not simultaneously belong to two diagrams, so
the situation shown below is not a legitimate state of the
diagram editor:
Kyung Hee
University
9
Notation for multiplicity
 Facts about multiplicity in the diagram editor:
A rectangle tool must be linked to exactly one diagram.
A diagram may or may not have a tool linked to it.
A diagram is linked to zero or more rectangles.
Every rectangle belongs to exactly one diagram.
 These are represented by multiplicity constraints written at
the ends of associations:
Kyung Hee
University
10
Notation for multiplicity (cont’d)
Kyung Hee
University
11
Multiple associations between classes
Diagram objects can be linked to the diagram editor by two
different types of links. One type of link represents all the
current diagrams, and the other is used specifically to pick out
the current diagram. These distinct types of links should be
modelled with two distinct associations. They are
distinguished by having different multiplicities and by suitable
labels, as shown below.
Kyung Hee
University
Association with multiplicity constraints
12
Different kinds of elements
The example above shows rectangles only. Different kinds of
element are possible, however, and a diagram can contain any
mixture of the possible elements. Different kinds of tools also
exist, and may be active at any given time.
Kyung Hee
University
13
Different kinds of elements (cont’d)
 This could be specified with multiple associations:
But:
This is rather redundant
For most purposes, the diagram doesn’t need to distinguish between
different kinds of element.
Kyung Hee
University
14
Generalization
 We can deal with this by introducing a “general” class called
Element. The relationship between this and the specific
classes is called generalization.

Kyung Hee
University
15
Generalization (cont’d)
The superclass Element is abstract: this means that instances
of it cannot be created.
 Whenever the design refers to an element, it is possible to
substitute an instance of any of the subclasses of Element.
This property of substitutability defines what generalization
means in UML. (Compare generalizaton between use cases or
actors.)
Kyung Hee
University
16
Polymorphism
 In general, a diagram can hold any number of elements:
Kyung Hee
University
17
Polymorphism (cont’d)
This diagram specifies that instances of Diagram can be linked
to instances of Element. Because of substitutability (and the
fact that Element is an abstract class), this means that
diagrams will in fact be linked to a mixture of instances of the
three subclasses of Element.
This association replaces the three separate associations shown
previously. Generalization is a way of describing common
properties (such as being able to appear on a diagram) that a
number of classes share. These become properties of the
supeclass.
Kyung Hee
University
18
Creation Tools
 A similar hierarchy can be defined for the creation tools.
Kyung Hee
University
19
Creation Tools (cont’d)
This doesn’t show that rectangle tools create rectangeles,
ellipse tools create ellipses and so on.
It would not be correct to model this with associations
between the corresponding tool and element classes, as tool
and element instances are not linked at run time. Tools simply
create elements, and then immediately pass them over to the
diagram for storage.
Kyung Hee
University
20
Dependencies
 UML models relationships which are not associations as
dependencies. A dependency is shown as a dashed arrow,
labelled with a stereotype which gives more information about
the type of relationship being modelled.
Kyung Hee
University
21
Selection Tool (cont’d)
This shows that links can exist between selection tools and
elements. We model this by an association between the
corresponding classes.
Kyung Hee
University
22
Selection Tool
The multiplicity constraints state that any number of elements
may be selected, and that an element may or may not be
selected at any given time.
Selection tools are linked to diagrams just like creation tools.
They can both be modelled as subclasses of a general tool
class.
Kyung Hee
University
23
Multiple associations
 A second type of link connects a selection tool to the element,
if any, that is currently being resized. To model this, we can
define an additional association linking the selection tool and
element classes.
Kyung Hee
University
24
Multiple associations (cont’d)
 This shows that two distinct relationships are possible
between instances of the two classes. The two relationships are
distinugished by:
Different labelling
Different formal properties (ie multiplicity constraints)
 At most one element can be resized at any one time
Kyung Hee
University
25
Attributes
 Class symbols can show the “member variables” or attributes
of classes. These specify the name and type of data items that
can be stored in instances of the class.
Kyung Hee
University
26
Attributes (cont’d)
 Here we are assuming that Point is a datatype provided by the
target language.
Attributes can have multiplicity: the element class contains
zero or more points, representing its position. If no
multiplicity is specified, the default is “exactly one”.
Attributes of superclasses are inherited by subclasses. The
creation tool class therefore contains two attributes.
1. The attribute giving the current position of the mouse is inherited from
the tool class.
2. An addition attribute, defining the “start” point of the element being
created, is defined in the class itself.
Kyung Hee
University
27
Operations
 Each message sent to an object on a sequence diagram should correspond
to an operation belonging to the corresponding class.
 As with attributes, these operations are inherited by subclasses.
 A subclass can override an operation if necessary. By default, operations
behave like virtual functions in C++ or Java methods, providing late
binding.
Kyung Hee
University
28
Complete Class Diagram
 All these little class diagrams belong to a single model
describing the static structure of the diagram editor. Viewed
as a whole, this model gives an overview of the static structure
of the diagram editor.
 It is common to omit attributes and operations from class
diagrams.
Kyung Hee
University
29
Complete Class Diagram (cont’d)
Kyung Hee
University
30
Static and Dynamic Properties
 Class diagrams specify the data held by the system and its relationships.
 We also need to specify the dynamic properties of the objects in the system,
and in particular the way that objects respond to messages.
 For example, creation tools receive three messages:
1. press() indicating that the mouse button has been pressed.
2. release() indicating that the mouse button has been released.
3. move(pos) indicating that the mouse cursor has been moved to the specified
position.
 We want to be able to specify in general terms how a tool responds when it
receives one of these messages.
Kyung Hee
University
31
Sequences of Interactions
 The order in which messages are sent to an object depends on
the object’s environment. In principle we need to state how an
object responds to any sequence it may receive.
It is only feasible to draw sequence diagrams for a tiny
proportion of the possible interactions a user could have with
a system. For example, the only sequence of messages
considered for the creation tool was:
Move; Press; Move; Release
Kyung Hee
University
32
Sequences of Interactions (cont’d)
 We assumed a number of things informally:
1. Move messages can be repeated as often as necessary.
2. Some sequences are assumed to be not possible:
Move; Press; Press; Move
Move; Release; Move; Press
 A design language should not leave these things implicit, but
should specify them in a suitable notation.
Kyung Hee
University
33
Behaviour Dependent on History
 Some messages have the property of eliciting a different
response from the receiver at different times. For example,
when a creation tool gets a move message, a faint outline will
be drawn only if the mouse button is pressed down.
It looks as if the tool has to be able to find out if the mouse
button is pressed down. It can’t check this directly:
1. It would be rather inefficient.
2. If the user was using keyboard short-cuts, the mouse button
might not be physically pressed down!
Kyung Hee
University
34
Behaviour Dependent on History (cont’d)
 A press() message really means something like:
This is the start point of the new element; the user is
trying to locate the stop point.
 The tool’s response to move messages depends on whether it
has received a press message without a corresponding release
message. Somehow, it must “remember” what messages have
been received (its history) as this determines what happens
next.
Kyung Hee
University
35
Specifying Behaviour
 There are two aspects of an object’s behaviour that needs to be specified.
1. How the response to one message depends on the messages that have
already been received. (Behaviour is history-sensitive.)
2. What sequences of messages the object expects to receive, and can sensibly
process.
 UML specifies these aspects of an object’s behaviour by defining a state
machine for each class. These are shown on statechart diagrams.
Informally:
An object can be in one of a number of states depending on its history.
Its response to a new message may depend on its current state.
It may change state in response to a message, as shown on the diagram.
Kyung Hee
University
36
Developing Statecharts
 Statecharts define the behaviour of all the object belonging
to a class. So a statechart is part of the specification of a class.
Statecharts can show sequences of messages. Here is a
statechart representing the basic sequence of messages for a
creation tool.
Kyung Hee
University
37
Developing Statecharts (cont’d)
 Terminology
Events are messages sent to objects.
States An object is in a state while it is waiting for a message.
Transitions arrows which connect two states, and are labelled with
an event.
 This statechart only shows one sequence of messages. We need to
generalize it to capture more of the creation tool’s behaviour.
Kyung Hee
University
38
Iteration
 When creating an element, the mouse can be moved as often
as required:
 It’s simpler to specify that the mouse need not be moved at
all:
Kyung Hee
University
39
Iteration (cont’d)
The whole interaction can be repeated, to create more than
one element:
Kyung Hee
University
40
Creation and Termination
 How does the creation tool arrive in the first state? This represents the
‘initial’ or starting state of the tool.
 The event on the transition corresponds to the class’ constructor, and it need
not been shown explicitly. A tool can only be killed by the user selecting
another tool.
 This can only happen when the mouse button is not pressed.
 The diagram assumes that before creating the new tool, the diagram editor
sends a Quit() message to the tool. This would be necessary, for example,
Hee
to Kyung
enable
selected elements to be unselected.
University
41
Actions
 We also need to show how an object’s behaviour depends on
what state it is in.
In this case, a Move() message will have a different effect
depending what state the tool is in when it receives the
message.
We can show this by adding actions to the statechart.
Actions are written after the event on a transition, separated
from it by a diagonal slash.
Kyung Hee
University
42
Actions (cont’d)
This now specifies that the faint outline only appears if the
user moves the mouse when searching for the stop point of the
new element. This is exactly what is required by the
specification.
Kyung Hee
University
43
Selection Tool Statechart
 In the same way, a statechart can be developed showing how the selection
responds to messages in locating and then moving elements.
 This diagram has the same structure as the creation tool statechart, the
meaning of the states and the actions attached to the move messages are
different.
 The complete statechart for the selection tool must also include
specifications of resizing and exceptional behaviour.
Kyung Hee
University
44
Non-determinism
 When a press event is received by a selection tool, it may or
may not result in an element being selected, depending on
where the mouse cursor is at the moment of the press.
The subsequent behaviour of the tool depends on whether an
element was selected: if it was, subsequent move messages will
move elements, but if not, nothing will move.
Two distinct states are required to model these possibilities,
and both are states that a transition labelled “press” could
lead to.
Kyung Hee
University
45
Non-determinism (cont’d)

 This is an example of non-determinism. We cannot tell from
this statechart which state the tool will end up in when a press
event is detected.
Kyung Hee
University
46
Guard Conditions
 Selection tools are not, however, non-deterministic. The transition that is
followed is determined completely by where the user clicks the mouse.
 We can show this by adding guard conditions to the transitions, written in
brackets after the event name.
 Guard conditions are boolean expressions. They are evaluated when a press
event is received, and depending which one is true at the time of the event
being received, the tool will transition to either of the “Moving” or “Error”
Kyung Hee
states.
University
47
Resizing Elements
 The selection tool actually has to execute a three-way choice
on receipt of a Press() message:
1. Cursor over control point of a selected element.
2. Cursor over an element.
3. Cursor not over any element.
 Depending on the outcome, subsequent move messages may
lead to either no action, or elements being moved or resized, as
shown on the complete statechart for the selection tool.
Kyung Hee
University
48
Resizing Elements (cont’d)
Kyung Hee
University
49
Statecharts for other classes
 We could draw a statechart for diagrams:
 Message can come in any order
 There is no state-dependent behaviour
Kyung Hee
University
50
Statecharts for other classes
 so it doesn’t really specify anything significant about the
diagram editor.
Normally, statecharts are only drawn where a class has
interesting behaviour, ie if the same message can cause
different behaviour at different times.
Kyung Hee
University
51
Error handling
 In principle, any message could be sent to any state at any
time. Objects do not control what their environment does.
What does it mean if an unexpected or unspecified message is
received? There are two interpretations:
1. Ignore it as a do-nothing operation.
2. treat it as an error.
The semantics of statecharts in UML specify that events which
do not cause any transition to fire are ignored
Error handling can be specified explicitly by defining suitable
error states, and showing which events cause errors to be
raise.
Kyung Hee
University
52