1. Diagram Editor : Use Case VIew
Spring 2001

2. Use Case View The use case view consists of:
A set of actors: roles users can play in interacting with the system.
A set of use cases: each describes a possible kind of interaction between an actor and the system.
A number of relationships between these entities.
It provides a structured view of the system’s functionality, and is a good starting point for system development.

3. Diagram Editor : Specification (cont’d)
The drawing editor is an interactive graphics editor. With it, users can create and edit drawings composed of lines, rectangles, ellipses and text.
Tools control the mode of operation of the editor. Exactly one tool is active at any one time. Two kinds of tools exist: the selection tool and creation tools. When the selection tool is active, existing drawing elements can be selected with the cursor. One or more drawing elements can be selected and manipulated; if several drawing elements are selected, they can be manipulated as if they were a single element. Elements that have been selected in this way are referred to as the current selection. The current selection is indicated visually by displaying the control points for the element. Clicking on and dragging a control point modifies the element with which the control point is associated.
When a creation tool is active, the current selection is empty. The cursor changes in different ways according to the specific creation tool, and the user can create an element of the selected kind. After the element is created, the selection tool is made active and the newly created element becomes the current selection.

4. Diagram Editor : Specification (cont’d)
The text creation tool changes the shape of the cursor to that of an I-beam. The position of the first character of the text is determined by where the user clicks the mouse button. The creation tool is no longer active when the user clicks the mouse button outside the text element. The control points for a text element are at the four corners of the region within which the text is formatted. Dragging the control points changes this region.
The other creation tools allow the creation of lines, rectangles and ellipses. They change the shape of the cursor to that of a crosshair. The appropriate element starts to be created when the mouse button is pressed, and is completed when the mouse button is released. These two events create the start point and the stop point.
The line creation tool creates a line from the start point to the stop point. These are the control points of a line. Dragging a control point changes the end point.

5. Diagram Editor : Specification (cont’d)
The rectangle creation tool creates a rectangle such that these points are diagonally opposite corners. These points and the other corners are the control points. Dragging a control point changes the associated corner.
The ellipse creation tool creates an ellipse fitting within the rectangle defined by the two points described above. The major radius is one half the width of the rectangle, and the minor radius is one half the height of the rectangle. The control points are at the corners of the bounding rectangle. Dragging a control point changes the associated corner.

6. The Use Case View
Describes the externally visible behavior of the system
Presents a structured view of a system’s functionality.
By defining a number of actors, which model the roles that users can play when interacting with the system and describing the use cases that those actors can participate in
Should be comprehensible to clients, end users, domain experts, testers, and anybody else whose involvement with the system does not require detailed knowledge of its structure and implementation.
Does not describe the organization or structure and implementation
Use case
Describing one way in which a user can interact with a system

7. Actors
Systems have different categories of users, who are able to perform different subsets of the system’s functionality.
Actors
Different roles that people interact with a system

8. Use Cases
Here is a screen shot of the diagram editor in action:

9. Use Cases
The specification above states that users can do the following things with the diagram editor:
1. Create diagrams.
2. Creating text and graphical elements.
3. Edit diagrams, perhaps by deleting elements.
4. Select existing elements.
5. Manipulating diagram elements, for example by moving them.
6. Modifying diagram elements, or resizing them by dragging a control point.
Each of these corresponds to a single use case.

10. Use Case Diagram
Each of these “user options” can be modelled as a use case. UML provides notation to summarize the set of use cases for a system:
Initial use case diagram for the diagram editor

11. Use Case Diagram (cont’d)
An actor represents a role a user can play when interacting with a system. In this case, all users have the same capabilities, but other systems have more than one actor, with different levels of access.
Use cases are shown as labelled ovals.
Lines indicate which actors can participate in which use cases.

12. Creating Diagram
The use case for creating a diagram is very simple. We will assume that the editor starts with a new, empty diagram for the user to edit, and that menu options are provided enabling the user to create new diagrams, and to cycle through the set of current diagrams.
Following the rule of thumb that states that domain concepts can be modelled as objects, the initial state of the editor might be shown as:

13. Creating Diagram (cont’d)
The Diagram object represents the initial diagram
The DiagramEditor object represents a “top-level”, application object. It keeps track of what diagrams have been created.

14. Multiple Diagrams
If the user creates further diagrams, extra Diagram objects will be created and linked to the DiagramEditor.
How does the system know which diagram is the current one, the one the user is currently working on?
A standard solution to this sort of problem is to introduce an additional link into the diagram, connecting the DiagramEditor with the current diagram.

15. Multiple Diagrams (cont’d)
(In programming terms, DiagramEditor holds an array of diagram objects, and currentDiagram is an index into the array.)

16. Use Case Realization
Realizing a use case is the process of coming up with proposed objects and interactions that will implement it. It is a first step in moving from a description of the system’s functionality to a more detailed design of its structure.
The interactions between objects in a use case realization are often shown in a sequence diagram.

17. Use Case Realization (cont’d)
This diagram shows:
The user, represented as an actor.
Objects, with lifelines indicating the period during which each object exists. Time flows down the page.
Messages sent between the objects, including parameters where appropriate.

18. Sequence Diagram
Read from top to bottom, a sequence diagram describes the progress of a particular interaction.

19. Sequence Diagram (cont’d)
At the start of this interaction, only the user and the DiagramEditor object exist.
The user selects the appropriate menu option; this results in the message newDiagram being sent to the diagram editor.
The diagram editor creates a new diagram object. This object is shown at its point of creation, and its lifeline continues below this point.
The diagram editor sends a message to itself; this will have the effect of resetting the currentDiagram link to point to the new object, but this is not shown explicitly.

20. Creating New Elements : Scenarios
From the user’s point of view, creating a new diagram is trivial. Creating a new element, however, is a much more interactive process.
For complex use cases, scenarios can be used to explore the various possibilities in a use case. A scenario is a description of a single, concrete interaction between a system and its user(s).

21. Creating New Elements : Scenarios (cont’d)
Scenario: Creating a rectangle
1. The user makes a rectangle tool active; the shape of the cursor changes to a crosshair.
2. The user moves the cursor a number of times.
3. The user presses the mouse button.
4. The user moves the cursor a number of times. A faint image of a rectangle is drawn; opposite corners of the rectangle are defined by the position at which the mouse button was pressed and the current position of the cursor.
5. The user releases the mouse button and the new rectangle is displayed on the screen

22. Use case generalization
Ellipses and lines will be created in the same way as rectangles. Text elements, however, will be created very differently.
We can show this by splitting the “create element” use case into two more specialized use cases.

23. Use case generalization (cont’d)
The base case “create element” is abstract. This means that the user cannot simply create an element without deciding whether a textual or graphical element is to be created. The child use cases specify what interactions between the system and the user will take place when particular kinds of element are being created.

24. Use case description
UML does not specify a notation for descriptions of use cases or scenarios. We will just use English to describe the possible sequences of interactions involved in a use case. Because the interactions involved in creating rectangles, lines and ellipses are identical, we will not bother to describe these as three separate use cases.

25. Use case description (cont’d)
Use case: Create graphical element
The user makes the appropriate creation tool active and the shape of the cursor changes to a crosshair. The user moves the cursor to the desired start point of the shape, and presses the mouse button. The user moves the cursor to the desired stop point; a faint image of the shape defined by the start point and current position is displayed by the editor and updated as the mouse moves. When the desired stop point is reached, the user releases the mouse button. The new shape is added to the current diagram.

26. Create graphical element: realization
In order to provide a realization of the “create graphical element” use case, we make the following design decisions.
Graphical elements will be represented by objects, and will be stored by “adding” them to the diagram.
Each interaction that a user has with the editor is managed by a tool.
Messages from the user are forwarded to the tool by the diagram editor; for simplicity, this is not shown below.

27. Create graphical element: realization (cont’d)

28. Relationships between objects
After the rectangle has been created, the configuration of objects in the running diagram editor is the following:

29. Relationships between objects (cont’d)
The structural information about what elements are on the diagram is modelled with links between the diagram and element objects.
Notice the two distinct links between the diagram editor and diagram.
The link between the current tool and the diagram objects models the fact that the tool has to add new elements to the diagram, and therefore needs to be related to the diagram somehow. This link will serve as a communication channel.

30. Notation for Interactions
The “create rectangle” interaction could also be shown on a collaboration diagram. (Messages are really passed from the user to the tool via the diagram editor, but as before this detail has been omitted for clarity.)
Collaboration diagrams are basically object diagrams with messages shown flowing along links in the diagram.

31. Notation for Interactions (cont’d)
This diagram shows links between object, but not the flow of time.
Messages therefore have to be numbered to indicate their order.
Objects (and links) that are created in the course of the interaction are marked with the property {new}.
They are easily confused with the objects and links that exist at the start of the interaction.
The point at which new objects and links are created is not very clear.

32. Selecting elements
The next use case describes how users select elements that have been created. The specification states that elements are selected “by clicking on them with the cursor”. As well as the normal course of events, this use case describes what happens in two exceptional situations.
Use case: Select an element
If necessary, the user makes the selection tool active. The user moves the mouse cursor over an element and presses the mouse button. [Exception: no such element.] The element becomes selected and its control points are displayed. [Exception: element already selected.] The user releases the mouse button.

33. Selecting elements (cont’d)
Exceptions
No such element: If the user presses the mouse button in a position on the screen where no element is displayed, no element is selected. Element already selected: If the user presses the mouse button over an element that is already selected, that element stays selected.

34. Realization of “select element”
A selection tool is responsible for enabling the user to select elements. If one rectangle has been created, and the user is about to select it, the state of the system will be the following:

35. Realization of “select element” (cont’d)
When the user presses the mouse button over the rectangle:
The selection tool asks the diagram for the identity of the element at the current mouse position.
The diagram asks each element if it contains the mouse position.
When an element returns true, the diagram returns the identity of that element to the tool.
The tool then “selects” that element.

36. Select element: normal case
These interactions can be shown on a sequence diagram:

37. Select element: normal case (cont’d)
Activations show the periods of time during which an object is active. They help clarify the flow of control in a sequence diagram.
Return messages are shown as dashed arrows between lifelines, and are used to specify data that is returned from a message call. This diagram also includes an example of an object sending a message to itself.

38. Recording selected elements
One of the responsibilities of the selection tool is to remember which elements on the diagram are currently selected. When it sends itself a “select” message, this is basically what it is doing.
This information is recorded structurally, by means of links between the selection tool and each selected element. These links can be labelled for clarity.

39. Recording selected elements (cont’d)
This diagram shows the situation after the rectangle has been selected. Note that in general there will be other element linked to the diagram which are not selected.

40. Selecting elements: exceptional case
If the user had clicked the mouse over an empty area of the diagram, the values returned by the “contains” and “find” messages would have been different, and no element would have been selected.
This scenario can be illustrated in a separate sequence diagram.

41. Deleting elements
In order to remove an element from the diagram, the user must first select it and then send a message to the selection tool requesting that the element be deleted.
This use case includes the use case for selecting an element: an element must be selected before it is deleted. This relationship can be shown on the use case diagram as follows:

42. Deleting elements (cont’d)
This means that a complete sequence diagram for the deletion use case should, in principle, include all the messages shown for the selection use case on the sequence diagrams above. Furthermore, these m “included” messages should be performed as an unbroken sequence. In this case the extra messages for deletion would appear after the element to be deleted had been selected.
By specifying that one use case includes another, it no longer becomes necessary to write out the repeated messages explicitly.

43. Realization of element deletion
In order to remove an element from the diagram:
1. It must be “unselected”, by destroying the “currentSelection” link between the selection tool and the element to be deleted.
2. It must be removed from the diagram, thus destroying the link between the diagram and the element.
3. The element itself must be destroyed.
The first two steps avoid “dangling pointers” in the selection tool and diagram objects.

44. Realization of element deletion (cont’d)
Element deletion is shown by a large ‘X’ at the end of the object’s lifeline.

45. Moving and resizing elements
When the selection tool is active, the user can either:
Select a new element by clicking on it.
Move an element by dragging it with the mouse.
Resize a selected element by dragging one of its control points.
If the diagram editor is to exhibit the correct functionality, it must do the following when the user presses the mouse button:
1. Check whether the user has pressed on a control point of an element that is already selected. In this case, dragging the mouse will cause the element to be resized.
2. If not, check whether the user has pressed the mouse over an element. In this case, dragging the mouse will cause the element to be moved.

46. Initial state
To illustrate this, suppose that the diagram contains three elements (a rectangle, a line and an ellipse) and that two elements (the line and the rectangle) are currently selected:

47. Resizing an element
The sequence diagram below shows the selection tool checking whether either of the selected elements has a control point at the position where the user pressed the mouse button.

48. Resizing an element (cont’d)
When the user drags the control point, the selection tool only sends moveControl messages to the element containing that control point, namely the one that returned “true” from the findControl message. How does the selection tool remember which element this was?

49. Remembering the resized element
This kind of situation, where it is necessary to identify one object (e.g. the element being resized) out of a set of objects (e.g. all the selected elements) often arises. A standard modelling solution to it is to use a temporary link to identify the required object.
So when the line returns “true” to findControl, the selection tool creates a special link to that object.

50. Remembering the resized element (cont’d)
This diagram now contains three different types of link, distinguished by appropriate labelling.
The currentlyResizing link will be used as the “communication channel” for sending moveControl messages.

51. Moving an element
If all the selected elements return “false” from the findControl message, the selection tool reverts to the normal case of selecting an element. If the user moves the mouse when the button is pressed down, however, the selected elements will be moved.

52. Moving an element (cont’d)
(In this diagram we are for simplicity assuming that there are no selected elements before the interaction starts.)

53. Reuse of use cases
These diagrams show that there is considerable commonality between the use cases for moving and resizing elements, and the use case for selecting elements.
In the case of moving, the sequence diagrams are almost the same, apart from some extra move messages before the mouse button is released.
In the case of resizing, there is some alternative functionality that can take place depending on where the mouse button is pressed.
These use cases do not include the select use case, however, as its interactions are not included as an uninterruped whole within either of the two other use cases.

54. Use case extension
The relationship between the use cases can be modelled as one of extension. For example:
To describe this relationship fully, the base use case (select) must contain:
an extension point indicating where the additional functionality is added (in this case, just after the user presses the mouse button down);
a condition stating when the additional functionality is added (in this case, when the user moves the mouse before releasing the button).
The extension use case must describe the new functionality:
The user can move the mouse, and selected elements move too.

55. Resizing as an extension
Resizing can also be described as an extension of the select use case:
The extension point is at the point where the user presses the mouse button.
The condition is that the user has pressed the mouse over a selected element’s control point.
The additional functionality is that subsequent moves will drag the control point and hence resize the element.

56. Final use case diagram
We have seen three relationships between use cases that are defined in UML:
Generalization One use case is a special case of another.
Inclusion A use case includes a base use case if it wants to reuse all the functionality of the base case without modification.
Extension One use case extends another if it inserts extra functionality at a specified place in the base use case.
These relationships have been used in building up a complete use case diagram for the diagram editor.

57. Final use case diagram (cont’d)

58. Generalization between actors
As well as use cases, actors can be related by generalization. This provides a convenient way for different levels of access to a system to be provided.
Suppose that, in a shared environment, ordinary users of the diagram editor were not allowed to delete elements. System administrators, however, can delete elements in addition to doing everything else that orfinary users can.
This could be shown by a slight modification to the use case diagram, modelling administrators and ordinary users as different actors.

59. Generalization between actors (cont’d)