1 kyung hee university diagram editor : implementation view spring 2001

11

Kyung Hee University

Diagram Editor : Implementation ViewDiagram Editor : Implementation View

Spring 2001

22


Diagram Editor: ImplementationDiagram Editor: Implementation

Implementation of a design is often bound up with various technology choice

s. For a system which has to maintain a large amount of data, a suitable da

tabase 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-use

r applications with a windows-based graphical user interface and user inte

ractions supplied by means of devices such as a mouse and a keyboard.

The design so far has considered the specific functionality of the diagram edit

or, 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 evol

ved which provide a standard architecture for such applications.

33


FrameworksFrameworks

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

44


What a framework doesWhat 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

55


HotspotsHotspots

Object-oriented frameworks usually provide “hotspots”: clas

ses in the framework that the framework user can specialize t

o provide application-specific functionality.

66


Hotspots (cont’d)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.

77


Overriding framework operationsOverriding framework operations

One way of using a framework is to override operations that

are provided in the hotspot classes.

88


Overriding framework operations (cont’d)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 ope

ration, which probably does nothing.

In an application, this operation can be overridden to implem

ent specific functionality.

99


Overriding callback operationsOverriding 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.

1010


Overriding callback operationsOverriding callback operations

The framework detects a situation in which the display could

be altered, and sends a redisplay message to the hotspot clas

s.

The framework provides a default implementation of this ope

ration, which calls an auxiliary function displayContent. Per

haps redisplay draws windows and scroll bars, but displayContent draws application data.

In an application, the displayContent operation can be over

ridden to implement specific functionality.

1111


Example: Java appletsExample: Java applets The implementation of the diagram editor as a Java applet uses two “hots

pots” provided by the Java API.

The Applet class in the Java API provides the ability to run the diagram edi

tor 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.

1212


Handling user inputHandling user input When the user moves the mouse over the diagram editor, this event is det

ected 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 th

e appropriate message on to the current tool object:

1313


Handling outputHandling output

The implementation of the diagram editor will follow a funda

mental strategy of keeping display code separate from applica

tion code.

Display of the elements on the current diagram will be perfor

med in response to the Paint method of the canvas class.

This message can either be sent by the framework (for examp

le, if the applet is uncovered and needs to be refreshed) or by t

he application (for example, if the user updates the diagram in

any way).

1414


Handling output (cont’d)Handling output (cont’d)

1515


Redrawing the diagramRedrawing 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.

1616


Implementation of ClassesImplementation 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.

1717


Implementation of GeneralizationImplementation 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.

1818


Implementation of Links and AssociationsImplementation of Links and Associations

Java, in common with most other programming languages, provides no di

rect support for associations. One common strategy strategy is to use refer

ences to implement associations.

Objects are connected at run-time by links which enable objects to send m

essages to each other: holding a reference to another object provides this f

unctionality.

A complication with this implementation is that links are bidirectional: me

ssages can be passed along a link in either direction. References, on the oth

er hand, are uni-directional.

To provide the full functionality of a link, two references would be require

d, one pointing in either direction.

1919


Implementation of Links and AssociationsImplementation 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.

2020


Unidirectional ImplementationUnidirectional Implementation

In practice, many associations are only used in one direction.

For example, a diagram object sends messages to elements, bu

t no messages flow in the other direction.

In this case, the implementation can be simplified by only pro

viding a pointer in the direction of use.

This implementation decision can be documented by includin

g an arrowhead on the association.

2121


Unidirectional Implementation (cont’d)Unidirectional Implementation (cont’d)

Arrowheads can be added to associations to show the intende

d direction of implementation, or navigation. The diagram cla

ss simply stores a vector of references to elements, thus suppor

ting the “many” multiplicity of the association.

2222


Unidirectional Implementation (cont’d)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);

}

}

2323


Implementing Multiplicity ConstraintsImplementing Multiplicity Constraints

If the multiplicity of an association is “one” rather than “man

y”, it can be implemented by a single reference. If the multipli

city is “exactly one”, however, care must be taken to ensure th

at the reference is always non-null.

2424


Implementing Multiplicity Constraints (cont’d)Implementing Multiplicity Constraints (cont’d)

public abstract class Tool

{

Diagram diagram ;

Tool(Diagram d) {

if ( d == null ) {

// throw NullDiagramError

}

diagram = d ;

}

}

2525


Implementation of StatechartsImplementation of Statecharts

A statechart specifies, for each instance of a class, the possibl

e 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 cu

rrent state.

A simple way of implementing the states of an object is with a

n enumeration type whose values represent the possible states.

Here for example is the definition of the possible states of the s

election tool:

2626


Implementation of Statecharts (cont’d)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.

2727


Implementation of Statecharts (cont’d)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

2828


Implementation of Statecharts (cont’d)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;

}

}

2929



public void release () {

switch (state) {

case LocatingStart:

break;

case LocatingStop:

Element e = newElement (start, Current);

Diagram.add(e);

state = LocatingStart;

break;

}

}

3030



public class RectangleTool extends CreationTool

{

Element (Point start, Point stop) { … }

void drawElement (Graphics g) { … }

}

3131


Implementation of Statecharts (cont’d)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;

}

}

3232


Implementation of eventsImplementation of events

Events in a statechart often simply correspond to calls of ope

rations in the class. In some cases, the implementation of an o

peration depends on the current state of an object.

This can be made very clear by structuring operations as a sw

itch statement with different cases for the different states.

3333


Implementation of events (cont’d)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) ;

}

3434


Tool managementTool management The design states that there is only one tool active in the editor at any give

n 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.

3535


Document/View architectureDocument/View architecture

An alternative framework to Java applets is provided by Mic

rosoft’s diagram/view architecture. The name is derived from

the two most significant hotspot classes in the framework.

3636


Document/View architecture (cont’d)Document/View architecture (cont’d)

Documents represent sensible units of data, such as a file, or i

n this case a diagram.

Views present the information in a document graphically in a

window.

3737


Document/View (2)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.