STUDIA UNIV. BABES–BOLYAI, INFORMATICA, Volume XLVII, Number 1, 2002

DIAGRAM DESIGN IN OCL EVALUATOR

HORIA CHIOREAN

Abstract. OCL Evaluator is a tool developed by the Computer ResearchLaboratory of the Babes-Bolyai University (LCI), designed for checking UMLmodels stored in XMI format. The main purpose of this software is that ofchecking (verifying). The general use case scenario is: the user designs hisapplication using a case tool like Rational Rose, Together, etc. Once thisdesign faze is finished, the user has a model for the problem. This modelis exported using the same case tool or some other program into an XMIdocument. The XMI document is inputted into our tool and verified. Theseverifications are done according to certain rules, that can be very complexand are grouped into several categories.

On the other hand, once errors are reported for a model, it’s naturalto allow the user to correct these errors. This is where the diagrams “kickin”. Diagrams can simplify very much the process of error correcting, becausethey can provide a visual representation for a model.

The problem was to implement these diagrams in OCL Evaluator, usingthe Java programming language.

1. Achievements regarding OCL

The Object Constraint Language (or OCL) first appeared in 1997 as part ofUML’s 1.1 specification. OCL is a formal language used to express constraints.These typically specify invariant conditions that must be satisfied by the systembeing modeled.

Although it has been developed some years ago, very little support has beengiven to OCL in the sense that there are very few software tools that give theuser the possibility to check his/hers model using the object constraint language.Well known CASE tools, such as Rational Rose, have plugins that allow certainverifications to be done using OCL, but these plugins are by no means enough inorder to use OCL’s the full power.

2000 Mathematics Subject Classification. 68N30.1998 CR Categories and Descriptors. D.2.3 [Software] : Software Engineering – Coding

Tools and Techniques; D.2.7 [Software] : Software Engineering – Distribution, Maintenanceand Enhancements .

89

90 HORIA CHIOREAN

2. The importance of UML diagrams

A diagram (in general) could be considered a graphical representation of certainelements together with their relations. The reason why diagrams are so importantis because they provide a graphical representation for a system (or for a part ofthe system). Having such a representation, makes it a lot easier to understandhow that system works.

The Unified Modeling Language (or UML) is, as its name states, a modelinglanguage. In other words, it is a language that is used to design models forproblems. (by problems, we mean software problems, that can be solved using anObject Oriented approach) It is natural for such a language to have diagrams inits specification and therefore UML (in the 1.4 specification), defines the followingkinds of diagrams:

(1) Static Structure Diagrams – class diagram and object diagram.(2) Use Case Diagrams – the use case diagram.(3) Interaction Diagrams – collaboration diagram and sequence diagram.(4) State Charts Diagrams – the state chart diagram.(5) Activity Diagrams – the activity diagram.(6) Implementation diagrams – the component diagram and the deployment

diagram.

Each of these diagrams contains several elements and relations, according totheir type, that are abstract elements defined in UML’s specification. (elementslike classes, actors, use cases, messages, objects, associations, etc) Each and everyone of those, has a graphical notation like: rectangles for classes, lines for associ-ations, ovals for use cases, etc, graphical notations that are used in a diagram.

The diagrams should give the user the possibility of representing only parts ofthe model or the model in it’s entirety. This means that a diagram should havethe following features:

(1) To allow one or more elements to be represented in more then one di-agram. In other words, an element can be represented in multiple dia-grams.

(2) Deleting one/more elements from a diagram, without affecting the model.(3) Undo/Redo functionalities.(4) Element filtering – this is a very important feature, because it allows

the user to see only the part of that element that he is interested in.Plus it can simplify a great deal the situation when you have very largediagrams.

Most of the well known CASE tools: Rational Rose, Together, Use, etc. supportdiagrams, but each has their drawbacks.

DIAGRAM DESIGN IN OCL EVALUATOR 91

3. Our solution: UML diagram design in OCL Evaluator usingJGraph

We developed the only tool, OCL Evaluator, that is based on the object con-straint language, with the sole purpose of providing efficient support for modelchecking. Although there are several OCL compilers out there (like the DresdenOCL Compiler or IBM’s OCL Compiler), none provide an adequate user interfaceand are therefore very difficult to use. OCL Evaluator is based on our own OCLcompiler, but also has an extensive user interface that facilitates the process ofchecking. Moreover, the user not only has the possibility of checking a system,but also to correct that system based on eventual errors.

In this context, it was decided that to include a graphical representation ofa system, by means of diagrams, was very important because firstly, it wouldfacilitate the checking process a great deal by giving a visual representation andsecondly, no other OCL software had this facility.

Although only class diagrams and use case diagrams have been implemented,most of these diagrams have a thing in common: they can be looked at similar toa graph. In other words, the structure of a diagram is similar to that of a graphwhere the objects are vertices (cells) and the relations between them are edges.

Therefore, when it was decided to include diagrams in the OCL Evaluator,there were 2 options: either to implement a graphical library from scratch or touse an existing graph library and to modify it so that it would fulfill the need ofrepresenting a good UML diagram. The later was chosen in the end and the graphlibrary chosen was JGraph (http://www.jgraph.com) .

JGraph is a freeware, Java based library, used to represent graphs. The inten-tion behind it, is to provide a freely available and fully Swing compliant implemen-tation of a graph component. As a Swing component for graphs, JGraph is basedon the mathematical theory of networks, called graph theory, and the Swing userinterface library, which defines the architecture. By combining these two, JGraphbecomes a Swing user interface component used for visualizing graphs.

The design of the JGraph is similar to that of a Swing component. In otherwords, besides the fact that JGraph is a Swing component (because it subclassesJComponent), its architecture is based on Swing Model View Controller (or MVC).

Figure 1 shows, according to [1], the diagram of a JComponent (JTree), whichshows the way in which the MVC pattern is applied.

On the diagram, you clearly see all the participants (except the controller):the component itself - JTree, its UI (which has the responsibility of renderingthe component) - TreeUI, and its model which encapsulates all the information –DefaultTreeModel. The control in Swing MVC is encapsulated in the UI-delegate,which is in charge of rendering the component in platform-specific manner, andmapping the events from the user interface to transactions, that are executed onthe model.

92 HORIA CHIOREAN

Figure 1. JTree MVC architecture

The JGraph component inherits this basic setup from the JComponent classand its UIdelegate, which implements the ComponentUI abstract class.

As in the case of text components, the split between platform-dependent andnon-platform Design and Implementation of JGraph dependent attributes, is im-plemented using the concept of views, which are independent from the elementsthat appear in the model.

In Swing’s text components, the elements of the model implement the Elementinterface, and for each of these elements, there exists exactly one view. Theseviews, which implement the View interface, are either accessed through a mappingbetween the elements and the views, or through an entry point called root view,which is referenced from the text component’s UIdelegate.

JGraph has an analogous setup, with the only difference that a graph view isreferenced by the JGraph instance. The cells of the graph model implement theGraphCell interface, which is JGraph’s analogy to the Element interface. Thecell views implement the CellView interface, in analogy to Swing’s View interface.The cell views are either accessed through the CellMapper mechanism, or throughthe graph view, which is an instance of the GraphView class. However, since theGraphView class works together with other classes, the analogy with Swing’s textcomponents is more helpful to understand the separation between the cell and theview.

In contrast to text components, where the geometric attributes are stored inthe model only, JGraph allows to store such attributes separately in each view,thus allowing a graph model to have multiple graphic configurations, namely onefor each attached view.

Figure 2 shows JGraphs’s model view controller diagram, according to [1].The key elements in a JGraph are the GraphCells. These cells are inserted into

the GraphModel and using the GraphUI they are given a visual representation.There a 3 kinds of GraphCells: Vertexes, Edges and Ports. While vertexes and

DIAGRAM DESIGN IN OCL EVALUATOR 93

Figure 2. JGraph MVC

edges are the common elements of a graph, the port is new concept. In JGraph,a port is connection point for an edge. Ports are added as children to vertexes,providing a way for an edge to connect to a vertex. The graphical representationof a GraphCell is achieved using CellView. CellView is the base class for all thespecial views such as: VertexView, PortView and EdgeView.

The graph cell has 2 very important attributes: it holds a reference to an Object(referred to as the user object) and it has a corresponding View. This view is infact an instance of the JGraph’s CellView interface and it also holds a referenceto a Renderer (which normally is a subclass of JComponent). This renderer isresponsible for the painting. For each cell in the graph model, there exists exactlyone cell view in each graph view, which has its own internal representation of thegraph model. The renderers are instantiated and referenced by the cell views.

Renderers are based on the idea of the TreeCellRenderer class from Swing, andon the Flyweight design pattern. The basic idea behind this pattern is to “usesharing to support large numbers of fine-grained objects efficiently.”

Because having a separate component for each CellView-instance would be ex-pensive, the component is shared among all cell views of a certain class. A cellview therefore only stores the state of the component (such as the color, size etc.),whereas the renderer holds the component’s painting code (for example a JLabelinstance – in the case of Vertex).

The CellViews are painted by configuring the renderer, and painting the latterto a CellRendererPane , which may be used to paint components without theneed to add them, as in the case of a container. The renderers in JGraph areused in analogy to the renderer in JTree, just that JGraph provides more thanone renderer, namely one for each type of cell. Thus, JGraph provides a rendererfor vertices, one for edges, and one for ports. For each subtype of the CellView

94 HORIA CHIOREAN

interface, by overriding the getRenderer method, you may associate a new renderer.The renderer should be static to allow it to be shared among multiple instances ofa class.

The renderer itself is typically an instance of the JComponent class, with anoverridden paint method that paints the cell, based on the attributes of the passed-in cell view. The renderer also implements the CellViewRenderer interface,which provides the getRendererComponent method to configure the renderer. Ac-cording to [1], Figure 3 shows the architecture of the renderers.

Figure 3. JGraph’s renderers

The three default implementations of the CellViewRenderer interface are theVertexRenderer, EdgeRenderer and PortRenderer classes.

4. Our solution

There were 2 main challenges in using this library: firstly fixing some bugs thatwere present in the implementation of JGraph (the most important of which beingan annoying flicker when dragging cells) and secondly, adapting JGraph so that itcould be used for UML diagrams.

There were two main bugs in JGraph 1.0:(1) When dragging a cell or an edge, or when changing the size of a cell,

there would be a visible and annoying flicker on the screen.(2) When trying to bend an edge, the connection point would not be inserted

correctly. (bending edge is achieved by adding connection points to anedge and dragging those points).

Fixes:(1) The overlay() method in the BasicGraphUI class did not use Swing’s

double buffering technique, this begin the reason for the flicker. Themethod was modified so that the painting would be done in an off-screenbuffer and only after that displayed on screen.

(2) The OnMouseClick() method in the EdgeHandler class did not makecorrectly the calculations about the location of the control point.

DIAGRAM DESIGN IN OCL EVALUATOR 95

In the current implementation of the Evaluator, the diagrams were implementedgraphically by using the JDektopPane and JInterFrame Swing classes. This meantthat a diagram would contain an instance of a JGraph and this instance wouldactually work as a canvas for JInternalFrame. This design allows (and so in should)the existence of multiple diagrams.

Figure 4 shows what the diagrams look like (when they are empty).

Figure 4. Diagram Overview in OCL Evaluator

Each element in a diagram, would have to be a cell in a graph. However, becauseJGraph’s support for cells was limited to only one kind of cell - the Vertex, whichis a rectangle with an optional text in the center, the cells implemented by uswere: Class Cell, Package Cell, Actor Cell and UseCase cell.

Because JGraph uses the Factory method to create views for each type of cell,(this is achieved trough a method called createView in the JGraph class), wesub-classed JGraph and created our own DiagramGraph. This class representsthe graph behind the diagram and it’s responsible for creating the correct viewsfor each kind of cell. We didn’t implement a new GraphModel because the oneprovided by the library (DefaultGraphModel) was general enough for what weneeded.

Therefore, we implemented only the necessary types of cells. Each one of ClassCell, Use Case Cell, Package Cell and Actor Cell represents the graph cell, andholds the user object.

Every custom cell, also has a corresponding view related to it, as shown inFigure 6:

Every renderer, has an appropriate paint() method. This method will be in-voked by BasicGraphUI, when the rendering mechanism takes place. This is theplace where we wrote the code that displays each cells according to its abstractcounterpart from UML 1.4. The cell class holds a reference to an object for themodel (the object which it represents). So when the paint() method is invoked by

96 HORIA CHIOREAN

Figure 5. Diagram Cells implemented for OCL Evaluator

the view, the user object is accessed, and the painting is done according to the in-formation extracted from this object. For example, in order to draw a class, beforedrawing it’s outline (the rectangle), we take the name of the class, its attributesand methods from the object (which must be an instanceof Classifier), and drawthem using the drawString() and drawImage() methods from java.awt.Graphics.This painting mechanism is used for every kind of cell, the only difference beingthe user object and the shape of the cell (shape which conforms to the UML 1.4specification).

In addition to the having a view, we implemented two other classes for ourcells. The first one called GProperty and encapsulates the graphical property forthat cell – meaning the fill color, the outline color, the title font size, the bodyfont size, etc. The second one is called AbstractFilter and represents a filter. Thisfilter has been only implemented for ClassCell, and it allows the filtering of classesaccording to the visibility of the attributes and methods.

Holding a model element as a user object, provides greater flexibility in the sensethat when this user object, which is always an instance of the Element interfacefrom UML1.4, is modified, a simple repaint is enough to visualize the change inall the corresponding diagrams.

As far as the relations between elements are concerned, in any kind of UMLdiagram, these relations are represented by straight lines with possible decorations

DIAGRAM DESIGN IN OCL EVALUATOR 97

Figure 6. Custom Views and Renderers

Figure 7. A class diagram

at the extremities. Already JGraph already had the support for this, there weretwo important issues that were solved:

98 HORIA CHIOREAN

(1) An Association in UML, besides being represented as a straight line, alsohas several additional text labels that indicate the role names and themultiplicity of that association. Therefore we implemented text labelsthat could be set at the end of the edge. Although these labels are nottied to the edge, by double clicking an edge, they will gather around thatedge.

(2) See Figure 8.

Figure 8. Diagram with an Association Class

An Association Class in UML is represented with a dashed line that connects aclass with an association. This meant that we had to connect a cell with an edgeusing a second edge. We stated previously that the key to connecting edges arethe ports. These ports act as a sort of “glue” in the sense that they keep edgesconnected. However, in the JGraph library the only cells that are allowed to haveports are the vertexes.

So, we needed some sort of hybrid edge that allowed the addition of portsas children on one hand, but would still have the capability to connect to ver-texes together. We solved this problem by creating 2 special classes (with theircorresponding views): SpecialEdge and SpecialPort, which extend DefaultEdgerespectively DefaultPort. However, SpecialEdge’s view class - SpecialEdgeView issimilar to the view of a vertex making SpecialEdge therefore both an edge and avertex. Figure 9 illustrates this.

The OCL evaluator is divided in 5 major parts, as shown in Figure 10.You can create a diagram by right-clicking in the browser on the desired parent

for the diagram (a package usually), and from the pop-menu selecting New. Inorder to add elements to the diagram, you can achieve this in 2 ways:

DIAGRAM DESIGN IN OCL EVALUATOR 99

Figure 9. The Special Cells

Figure 10. OCL Evaluator Overview

(1) Dragging and dropping an element from the browser onto the diagram,in which case the element will be represented graphically according toits information.

(2) Using the toolbar to create new elements/relations.

100 HORIA CHIOREAN

5. Conclusions and future work

OCL Evaluator is not yet in a release version. It’s still in beta version. How-ever, several extensions of our project are possible such as: using OCL to verifycomponents and using OCL for checking XMI documents.

Of course that the two types of diagrams that were implemented, although theyare the most “fundamental diagrams”, are not enough for a competitive tool. Newdiagrams will be implemented as the project extends. However, because JGraph’sextensibility is limited, a decision will have to be taken whether to continue usingthis library, or to implement a new one.

References

[1] Alder. The JGraph Paper. http://jgraph.sourceforge.net/paper.pdf[2] Alder. The JGraph 1.0 API Specification. http://api.jgraph.com[3] Gamma, Helm, Johnson, Vlissides. Design Patterns. Addison-Wesley, Reading MA, 1995.[4] Geary. Graphic Java 2, Volume II: Swing (3rd Edition). Sun Microsystems, Palo Alto CA,

1999.[5] OMG Unified Modeling Language Specification, Version 1.4 draft, February 2001

Babes-Bolyai University, Computer Science Research Laboratory, RO 3400 Cluj-Napoca, Str. Kogalniceanu 1, Romania