1 kyung hee university diagram editor : design view spring 2001

11

Kyung Hee University

Diagram Editor : Design ViewDiagram Editor : Design View

Spring 2001

22


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


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


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


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


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


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


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


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


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


Notation for multiplicity (cont’d)Notation for multiplicity (cont’d)

1212


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


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


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


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


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


PolymorphismPolymorphism

In general, a diagram can hold any number of elements:

1818


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


Creation ToolsCreation Tools

A similar hierarchy can be defined for the creation tools.

2020


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


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


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


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


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


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


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


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


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


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


Complete Class Diagram (cont’d)Complete Class Diagram (cont’d)

3131


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


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


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


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


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


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


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


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


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


Iteration (cont’d)Iteration (cont’d)

The whole interaction can be repeated, to create more than

one element:

4141


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


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


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


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


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


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


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


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


Resizing Elements (cont’d)Resizing Elements (cont’d)

5050


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


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


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.

1 kyung hee university diagram editor : design view spring 2001

Documents