1. 1 Kyung Hee University Diagram Editor : Design View Spring 2001

2. 2 Kyung Hee University 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.

3. 3 Kyung Hee University 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.

4. 4 Kyung Hee University 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.

5. 5 Kyung Hee University 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.

6. 6 Kyung Hee University 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.

7. 7 Kyung Hee University 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:

8. 8 Kyung Hee University 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.

9. 9 Kyung Hee University 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:

10. 10 Kyung Hee University 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:

11. 11 Kyung Hee University Notation for multiplicity (cont’d)

12. 12 Kyung Hee University 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. Association with multiplicity constraints

13. 13 Kyung Hee University 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.

14. 14 Kyung Hee University 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.

15. 15 Kyung Hee University Generalization  We can deal with this by introducing a “general” class called Elemen t. The relationship between this and the specific classes is called generalization. 

16. 16 Kyung Hee University 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.)

17. 17 Kyung Hee University Polymorphism  In general, a diagram can hold any number of elements:

18. 18 Kyung Hee University 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.

19. 19 Kyung Hee University Creation Tools  A similar hierarchy can be defined for the creation tools.

20. 20 Kyung Hee University 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.

21. 21 Kyung Hee University 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.

22. 22 Kyung Hee University 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.

23. 23 Kyung Hee University 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.

24. 24 Kyung Hee University 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.

25. 25 Kyung Hee University 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

26. 26 Kyung Hee University 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.

27. 27 Kyung Hee University 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.

28. 28 Kyung Hee University 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.

29. 29 Kyung Hee University 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.

30. 30 Kyung Hee University Complete Class Diagram (cont’d)

31. 31 Kyung Hee University 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.

32. 32 Kyung Hee University 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

33. 33 Kyung Hee University 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.

34. 34 Kyung Hee University 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!

35. 35 Kyung Hee University 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.

36. 36 Kyung Hee University 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.

37. 37 Kyung Hee University 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.

38. 38 Kyung Hee University 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.

39. 39 Kyung Hee University 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:

40. 40 Kyung Hee University Iteration (cont’d)  The whole interaction can be repeated, to create more than one element:

41. 41 Kyung Hee University 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, to enable selected elements to be unselected.

42. 42 Kyung Hee University 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.

43. 43 Kyung Hee University 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.

44. 44 Kyung Hee University 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.

45. 45 Kyung Hee University 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.

46. 46 Kyung Hee University 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.

47. 47 Kyung Hee University 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” states.

48. 48 Kyung Hee University 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.

49. 49 Kyung Hee University Resizing Elements (cont’d)

50. 50 Kyung Hee University Statecharts for other classes  We could draw a statechart for diagrams:  Message can come in any order  There is no state-dependent behaviour

51. 51 Kyung Hee University 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.

52. 52 Kyung Hee University 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.