1 Kyung Hee University Diagram Editor : Implementation View Spring 2001

2 Kyung Hee University Diagram Editor: Implementation Implementation of a design is often bound up with various technology choices. For a system which has to maintain a large amount of data, a suitable database backend will often be chosen. For a distributed application, suitable communication protocols will be considered. The diagram editor is representative of a large class of interactive, single-user applications with a windows-based graphical user interface and user interactions supplied by means of devices such as a mouse and a keyboard. The design so far has considered the specific functionality of the diagram editor, but not the details of the interaction and display of information. Because this type of application is so common, and because the user-interface code is essentially the same for all such applications, frameworks have evolved which provide a standard architecture for such applications.

3 Kyung Hee University Frameworks  In this type of application, a framework will: manage windows, and provide standard user-interface widgets detect user input (from mouse, keyboard or widget) provide library functions for producing output  The term framework is used because: this code “surrounds” the application-specific code it provides a skeletal but complete application which the framework user can extend and specialize

4 Kyung Hee University What a framework does  The framework: Shields the programmer from details of low-level APIs, thus making application development easier Provides generic functionality that can be used in many applications

5 Kyung Hee University Hotspots  Object-oriented frameworks usually provide “hotspots”: classes in the framework that the framework user can specialize to provide application-specific functionality.

6 Kyung Hee University Hotspots (cont’d) 1.The framework calls the functions of the hotspot class. Default versions of these are provided by the framework. 2.The user defines an application-specific specialization of the hotspot class, and overrides the necessary functions. 3.By using late binding the framework then executes the user’s code, not the default code.  This mechanism is often known as inversion of control. A framework provides reusable code which calls the programmers code. This is the opposite of what happens with traditional libraries.

7 Kyung Hee University Overriding framework operations  One way of using a framework is to override operations that are provided in the hotspot classes.

8 Kyung Hee University Overriding framework operations (cont’d)  The framework detects a mouse move, and sends a mouseMove message to the hotspot class.  The framework provides a default implementation of this operation, which probably does nothing.  In an application, this operation can be overridden to implement specific functionality.

9 Kyung Hee University Overriding callback operations  Sometimes the interaction involved is a bit more complex. The framework detects a situation in which the display could be altered, and sends a redisplay message to the hotspot class.

10 Kyung Hee University Overriding callback operations  The framework detects a situation in which the display could be altered, and sends a redisplay message to the hotspot class.  The framework provides a default implementation of this operation, which calls an auxiliary function displayConten t. Perhaps redisplay draws windows and scroll bars, but displayContent draws application data.  In an application, the displayContent operation can be overridden to implement specific functionality.

11 Kyung Hee University Example: Java applets  The implementation of the diagram editor as a Java applet uses two “hotspots” provided by the Java API.  The Applet class in the Java API provides the ability to run the diagram editor in a Web page, for example.  The Canvas class enables the display of the current diagram, and also traps the user-generated events such as mouse moves.

12 Kyung Hee University Handling user input  When the user moves the mouse over the diagram editor, this event is detected by the Java run-time system and translated into a call to the method ‘mouseMove’, which is defined in the canvas class.  For example, the Java 1.0 run-time system ensures that the message MouseMove() is sent to the canvas.  If the DiagramEditor class overrides this method, it will be able to send the appropriate message on to the current tool object:

13 Kyung Hee University Handling output  The implementation of the diagram editor will follow a fundamental strategy of keeping display code separate from application code.  Display of the elements on the current diagram will be performed in response to the Paint method of the canvas class.  This message can either be sent by the framework (for example, if the applet is uncovered and needs to be refreshed) or by the application (for example, if the user updates the diagram in any way).

14 Kyung Hee University Handling output (cont’d)

15 Kyung Hee University Redrawing the diagram  The paint method simply redraws everything, including: The diagram, which draws Every element The current tool (to draw any interaction-specific stuff such as the faint images displayed when an element is being created). Parameter ‘g’ on the messages is a reference to a graphics context in which drawing can take place.

16 Kyung Hee University Implementation of Classes  There is a direct correspondence between the basic UML notation for classes and object-oriented code.  As this illustration suggests: UML classes are represented by classes in Java or C++, and abstract classes by abstract classes. Attributes are represented by private data members. Operations are represented by public methods.  The implementation of the class has to be specific about the types of variables and functions, which are often omitted in UML.

17 Kyung Hee University Implementation of Generalization  The UML relationship of generalization should be implemented using inheritance in Java or C++.  Generalization has two important properties in UML, both of which are preserved by this implementation. Substitutability Instances of subclasses should be usable wherever an instance of a superclass is expected or specified. Inheritance Data members and methods defined in a superclass are inherited and become in effect members of the subclass.

18 Kyung Hee University Implementation of Links and Associations  Java, in common with most other programming languages, provides no direct support for associations. One common strategy strategy is to use references to implement associations.  Objects are connected at run-time by links which enable objects to send messages to each other: holding a reference to another object provides this functionality.  A complication with this implementation is that links are bidirectional: messages can be passed along a link in either direction. References, on the other hand, are uni-directional.  To provide the full functionality of a link, two references would be required, one pointing in either direction.

19 Kyung Hee University Implementation of Links and Associations  To avoid the additional overheads and complexity involved in supporting inverse references of this type, associations are often implemented in one direction only.

20 Kyung Hee University Unidirectional Implementation  In practice, many associations are only used in one direction. For example, a diagram object sends messages to elements, but no messages flow in the other direction.  In this case, the implementation can be simplified by only providing a pointer in the direction of use.  This implementation decision can be documented by including an arrowhead on the association.

21 Kyung Hee University Unidirectional Implementation (cont’d)  Arrowheads can be added to associations to show the intended direction of implementation, or navigation. The diagram class simply stores a vector of references to elements, thus supporting the “many” multiplicity of the association.

22 Kyung Hee University Unidirectional Implementation (cont’d)  A simple implementation of this unidirectional association public class Diagram { private Vector elements = new Vector(16) public void add (Element e) { elements.addElement (e); }

23 Kyung Hee University Implementing Multiplicity Constraints  If the multiplicity of an association is “one” rather than “many”, it can be implemented by a single reference. If the multiplicity is “exactly one”, however, care must be taken to ensure that the reference is always non-null.

24 Kyung Hee University Implementing Multiplicity Constraints (cont’d) public abstract class Tool { Diagram diagram ; Tool(Diagram d) { if ( d == null ) { // throw NullDiagramError } diagram = d ; }

25 Kyung Hee University Implementation of Statecharts  A statechart specifies, for each instance of a class, the possible states it can be in, how it switches from one state to another, and in some cases how an object’s behaviour depends on its current state.  A simple way of implementing the states of an object is with an enumeration type whose values represent the possible states. Here for example is the definition of the possible states of the selection tool:

26 Kyung Hee University Implementation of Statecharts (cont’d) public class SelectionTool extends Tool { final static int Locating = 0 ; final static int Moving = 1 ; final static int Resizing = 2 ; final static int Error = 3 ; int state ; } The intention behind this is that at any given instant, the value stored in state will specify the current state of the tool.

27 Kyung Hee University Implementation of Statecharts (cont’d) public abstract class CreationTool extends Tool { final static int LocatingStart = 0; final static int LocatingStop = 1; int state; CreationTool (Diagram d) { super(d); state = LocatingStart; } … } The creation tool hierarchy

28 Kyung Hee University Implementation of Statecharts (cont’d) public void operation () { switch (state) { case LocatingStart: // Specific actions for locating start state break; case LocatingStop: // Specific actions for locating stop state break; }

29 Kyung Hee University Implementation of Statecharts (cont’d)  public void release () { switch (state) { case LocatingStart: break; case LocatingStop: Element e = newElement (start, Current); Diagram.add(e); state = LocatingStart; break; }

30 Kyung Hee University Implementation of Statecharts (cont’d) public class RectangleTool extends CreationTool { Element (Point start, Point stop) { … } void drawElement (Graphics g){ … } }

31 Kyung Hee University Implementation of Statecharts (cont’d)  Selection tool class public void press () switch (state) { case Locating: if (findControl (current)) { state = Resizing; } else if (diagram.find(current) != null) { state = Moving ; } else { state = off; Case Moving: break; Case Resizing: break; Case error:break; }

32 Kyung Hee University Implementation of events  Events in a statechart often simply correspond to calls of operations in the class. In some cases, the implementation of an operation depends on the current state of an object.  This can be made very clear by structuring operations as a switch statement with different cases for the different states.

33 Kyung Hee University Implementation of events (cont’d) void move(int x, int y) { switch (state) { case Locating: break ; case Moving: Enumeration enum = selected.elements() ; // Move each element in turn break ; case Resizing: resizing.moveCP(x-lastPoint.x, y-lastPoint.y) ; break ; case Error: break ; } lastPoint = new Point(x, y) ; }

34 Kyung Hee University Tool management  The design states that there is only one tool active in the editor at any given time. When the user requests the creation of a new tool, something like the following must happen:  We also need to do this whenever the current diagram is changed, to ensure that the current tool is always active on the current diagram. Otherwise, strange effects might ensue.

35 Kyung Hee University Document/View architecture  An alternative framework to Java applets is provided by Microsoft’s diagram/view architecture. The name is derived from the two most significant hotspot classes in the framework.

36 Kyung Hee University Document/View architecture (cont’d)  Documents represent sensible units of data, such as a file, or in this case a diagram.  Views present the information in a document graphically in a window.

37 Kyung Hee University Document/View (2)  The diagram editor application can be integrated into the document/view framework as follows:  The application class is provided by the framework, but can be generated automatically by a Microsoft tool. It contains no application-specific code.