11
Kyung Hee University
Diagram Editor : Design ViewDiagram Editor : Design View
Spring 2001
22
Kyung Hee University
Diagram Editor: Design ViewDiagram 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.
33
Kyung Hee University
Diagram Editor: Design View (cont’d)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.
44
Kyung Hee University
Design modelsDesign 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.
55
Kyung Hee University
ClassesClasses Decisions about classes have already been made in realizing u
se 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.
66
Kyung Hee University
Classes (cont’d)Classes (cont’d)
Classes in UML are denoted by rectangles labelled simply wit
h the name of the class.
Objects are instances of classes: this is shown by underlining t
he class name in an object symbol. A colon separates the objec
t name, if specified, from the class name.
77
Kyung Hee University
AssociationsAssociations
Associations between classes specify that instances of the clas
ses can be linked at run-time. The links in the diagram above i
mply that the following associations must exist between the cla
sses:
88
Kyung Hee University
Associations (cont’d)Associations (cont’d)Just as objects are instances of classes, links are instances of a
ssociations. UML makes a general distinction between descript
ors and instances:
Given only these associations, the following object diagram is i
llegal, as there is no association corresponding to the link betw
een the two objects.
99
Kyung Hee University
MultiplicityMultiplicity There are two important aspects of links that need to be speci
fied:
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 r
ectangle can not simultaneously belong to two diagrams, so th
e situation shown below is not a legitimate state of the diagra
m editor:
1010
Kyung Hee University
Notation for multiplicityNotation 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 th
e ends of associations:
1111
Kyung Hee University
Notation for multiplicity (cont’d)Notation for multiplicity (cont’d)
1212
Kyung Hee University
Multiple associations between classesMultiple associations between classes
Diagram objects can be linked to the diagram editor by two diff
erent types of links. One type of link represents all the current
diagrams, and the other is used specifically to pick out the cur
rent diagram. These distinct types of links should be modelled
with two distinct associations. They are distinguished by havin
g different multiplicities and by suitable labels, as shown belo
w.
Association with multiplicity constraints
1313
Kyung Hee University
Different kinds of elementsDifferent 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.
1414
Kyung Hee University
Different kinds of elements (cont’d)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.
1515
Kyung Hee University
GeneralizationGeneralization
We can deal with this by introducing a “general” class called
Element. The relationship between this and the specific classes
is called generalization.
1616
Kyung Hee University
Generalization (cont’d)Generalization (cont’d)
The superclass Element is abstract: this means that instances o
f it cannot be created.
Whenever the design refers to an element, it is possible to sub
stitute an instance of any of the subclasses of Element.
This property of substitutability defines what generalization m
eans in UML. (Compare generalizaton between use cases or ac
tors.)
1717
Kyung Hee University
PolymorphismPolymorphism
In general, a diagram can hold any number of elements:
1818
Kyung Hee University
Polymorphism (cont’d)Polymorphism (cont’d)
This diagram specifies that instances of Diagram can be linked
to instances of Element. Because of substitutability (and the fa
ct that Element is an abstract class), this means that diagrams
will in fact be linked to a mixture of instances of the three sub
classes of Element.
This association replaces the three separate associations show
n previously. Generalization is a way of describing common p
roperties (such as being able to appear on a diagram) that a n
umber of classes share. These become properties of the supecl
ass.
1919
Kyung Hee University
Creation ToolsCreation Tools
A similar hierarchy can be defined for the creation tools.
2020
Kyung Hee University
Creation Tools (cont’d)Creation Tools (cont’d)
This doesn’t show that rectangle tools create rectangeles, ellip
se tools create ellipses and so on.
It would not be correct to model this with associations betwee
n the corresponding tool and element classes, as tool and elem
ent instances are not linked at run time. Tools simply create el
ements, and then immediately pass them over to the diagram f
or storage.
2121
Kyung Hee University
DependenciesDependencies
UML models relationships which are not associations as depe
ndencies. A dependency is shown as a dashed arrow, labelled
with a stereotype which gives more information about the type
of relationship being modelled.
2222
Kyung Hee University
Selection Tool (cont’d)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.
2323
Kyung Hee University
Selection Tool Selection Tool The multiplicity constraints state that any number of elements
may be selected, and that an element may or may not be select
ed 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
.
2424
Kyung Hee University
Multiple associationsMultiple 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 d
efine an additional association linking the selection tool and el
ement classes.
2525
Kyung Hee University
Multiple associations (cont’d)Multiple associations (cont’d)
This shows that two distinct relationships are possible betwee
n instances of the two classes. The two relationships are distin
ugished by:
Different labelling
Different formal properties (ie multiplicity constraints)
At most one element can be resized at any one time
2626
Kyung Hee University
AttributesAttributes
Class symbols can show the “member variables” or attributes
of classes. These specify the name and type of data items that c
an be stored in instances of the class.
2727
Kyung Hee University
Attributes (cont’d)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 ze
ro or more points, representing its position. If no multiplicity i
s specified, the default is “exactly one”. Attributes of superclas
ses are inherited by subclasses. The creation tool class therefor
e 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.
2828
Kyung Hee University
OperationsOperations 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.
2929
Kyung Hee University
Complete Class DiagramComplete Class Diagram All these little class diagrams belong to a single model describ
ing the static structure of the diagram editor. Viewed as a who
le, this model gives an overview of the static structure of the di
agram editor.
It is common to omit attributes and operations from class dia
grams.
3030
Kyung Hee University
Complete Class Diagram (cont’d)Complete Class Diagram (cont’d)
3131
Kyung Hee University
Static and Dynamic PropertiesStatic 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, an
d 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 rec
eives one of these messages.
3232
Kyung Hee University
Sequences of InteractionsSequences 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 propor
tion of the possible interactions a user could have with a syste
m. For example, the only sequence of messages considered for
the creation tool was:
Move; Press; Move; Release
3333
Kyung Hee University
Sequences of Interactions (cont’d)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 s
hould specify them in a suitable notation.
3434
Kyung Hee University
Behaviour Dependent on HistoryBehaviour Dependent on History
Some messages have the property of eliciting a different resp
onse from the receiver at different times. For example, when a
creation tool gets a move message, a faint outline will be draw
n only if the mouse button is pressed down.
It looks as if the tool has to be able to find out if the mouse but
ton 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!
3535
Kyung Hee University
Behaviour Dependent on History (cont’d)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 ne
xt.
3636
Kyung Hee University
Specifying BehaviourSpecifying 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 alrea
dy 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 m
achine 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.
3737
Kyung Hee University
Developing StatechartsDeveloping Statecharts
Statecharts define the behaviour of all the object belonging t
o a class. So a statechart is part of the specification of a class.
Statecharts can show sequences of messages. Here is a statech
art representing the basic sequence of messages for a creation
tool.
3838
Kyung Hee University
Developing Statecharts (cont’d)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 t
o generalize it to capture more of the creation tool’s behaviour.
3939
Kyung Hee University
IterationIteration 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
:
4040
Kyung Hee University
Iteration (cont’d)Iteration (cont’d)
The whole interaction can be repeated, to create more than
one element:
4141
Kyung Hee University
Creation and TerminationCreation 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, to enable selected elements to be unselected.
4242
Kyung Hee University
ActionsActions
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 dep
ending 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 f
rom it by a diagonal slash.
4343
Kyung Hee University
Actions (cont’d)Actions (cont’d)
This now specifies that the faint outline only appears if the use
r moves the mouse when searching for the stop point of the ne
w element. This is exactly what is required by the specification
.
4444
Kyung Hee University
Selection Tool StatechartSelection 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 m
eaning of the states and the actions attached to the move messages are diff
erent.
The complete statechart for the selection tool must also include specificatio
ns of resizing and exceptional behaviour.
4545
Kyung Hee University
Non-determinismNon-determinism
When a press event is received by a selection tool, it may or
may not result in an element being selected, depending on whe
re the mouse cursor is at the moment of the press.
The subsequent behaviour of the tool depends on whether an e
lement 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, a
nd both are states that a transition labelled “press” could lead
to.
4646
Kyung Hee University
Non-determinism (cont’d)Non-determinism (cont’d)
This is an example of non-determinism. We cannot tell from t
his statechart which state the tool will end up in when a press
event is detected.
4747
Kyung Hee University
Guard ConditionsGuard 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” states.
4848
Kyung Hee University
Resizing ElementsResizing Elements
The selection tool actually has to execute a three-way choice o
n 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 le
ad to either no action, or elements being moved or resized, as
shown on the complete statechart for the selection tool.
4949
Kyung Hee University
Resizing Elements (cont’d)Resizing Elements (cont’d)
5050
Kyung Hee University
Statecharts for other classesStatecharts for other classes
We could draw a statechart for diagrams:
Message can come in any order
There is no state-dependent behaviour
5151
Kyung Hee University
Statecharts for other classesStatecharts for other classes
so it doesn’t really specify anything significant about the diag
ram editor.
Normally, statecharts are only drawn where a class has interes
ting behaviour, ie if the same message can cause different beh
aviour at different times.
5252
Kyung Hee University
Error handlingError 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.