Information and Communication Technology Seminar, Vol. 1 No. 1, August 2005
ISSN 1858-1633 2005 ICTS 41
MUE: MULTI USER UML EDITOR
Suhadi Lili, Sutarsa, Siti Rochhimah
Informatics Department, Faculty of Information Technology, Sepuluh Nopember Institute of Technology Kampus ITS, Jl. Raya ITS, Sukolilo – Surabaya 60111, Tel. + 62 31 5939214, Fax. + 62 31 5913804
email : suhadinwa.iao.co.id, sitiits-sby.edu
ABSTRACT
Most of software developers nowadays use object- oriented method, and Unified Modeling Language
UML is the most popular modeling language used. There are a number of tools for modeling software
application in UML notations, but the majority of those tools do not support multi-user mode, where on-
line team collaboration is not supported.
In this paper, we developed a multi-user UML Editor called WEKMU. This system allows a number
of developers to work together at the client site on the same model and the server keep them updated in real
time of any change made by others. This feature is implemented using .Net Remoting feature provided in
.NET framework. Beside the view synchronization, this system also provide another feature, that is, Undo
function, which enables user to return to the previous state of the model
Keywords : UML Editor, .NET Framework.
1. INTRODUCTION
UML is the most popular modeling language used by software developer that based their engineering
process on Object Oriented method. This modeling language is known to be well-defined, expressive,
powerful, and widely used. Nowadays, there are already a number of tools that support this modeling
language, such as ArgoUML, Poseidon, and Rational Rose. But most of them were designed for single-
mode user. As the consequence, those tools do not support an online collaborative way of designing a
model, which is really common in real life. Therefore, we developed a multi-user UML editor called
WEKMU.
This paper covers four main issues of this system, that is:
1. How to model the 8 UML standard diagrams use case, class, state chart, activity, sequence,
collaboration, component, and deployment. 2. How .NET Remoting feature from .NET is
used. 3. How the undo strategy is done and its
authorization. This paper is organized as follows. The second
section describes the overview of the architecture of the system. The third section explains its
implementation. The fourth section describes some result from testing phase. The last section concludes
some findings and further works.
2. SYSTEM ARCHITECTURE
Figure 1 shows the system architecture of WEKMU. This system is comprises of two main
applications, that is, client and server applications. The client application resides on the user’s sites,
where the editing on a model are done. This application displays the UML elements according to
their hierarchy as represented by the tree view. This view can be accessed through the the model explorer.
As a modification is done by a user, the client application does not immediately modify the element.
All the user actions are pushed to the server application. Then, the server application makes sure
that all the required manipulations are done. Then, it propagates the result of the modification too all
clients, so that all views are updated.
Figure 4 System Architecture
The server and client applications are connected using .NET Remoting [1][5]. This is done as follows.
The server application registers all channels and the objects, which then registered as remoteable objects.
The client application receives a proxy of a remoteable object that has been activated by the
server. Through this proxy, a diagram modification request is sent by the client to the server, which by the
proxy will be forwarded to the respective object.
2.1. The Architecture of UML Elements
There are at least 8 different diagrams in UML, i.e. use case, class, state chart, activity, sequence,
collaboration, component, and deployment. Each diagram is filled with particular kind of elements. For
instance, class diagram can only contain any of the following elements: class, association relation,
Information and Communication Technology Seminar, Vol. 1 No. 1, August 2005
ISSN 1858-1633 2005 ICTS 42
generalization relation, dependency relation, and realization relation.
An element in UML can be viewed in different diagrams. In order to do so, class representations of an
element should be separated into model and glyph. An object model contains the name and other attributes of
an element, while glyph contains the element position, dimension, and color in a diagram. Glyph is referred
to an object model. This different glyph is then showed in corresponding diagram. This separation is
implemented using a bridge pattern [4].
2.2. Model Element
A UML element can be grouped into 2 major groups, i.e. relation elements and shape elements,
which become the source and destination object of a relation. A set of elements composed a hierarchy. An
element can be a container of other elements. Table 1 shows the possible hierarchies.
Table 1 Possible Hierarchies
Element Possible sub-element
Use case
class diagram,use case diagram,activity
diagram,state chart diagram class
classinner class, Attribute, Method, state chart diagram,
activity diagram Method Parameter, state chart
diagram, activity diagram State
state chart diagram ,acitvity diagram
Activity state chart diagram, acitvity diagram
Package use case, Class, sequence object, collaboration object,
Package, Component, Device, Processor,
Association, Generalization, Realization, Dependency,
Message
In order to arrange an element hierarchy as shown in Table 1, we use Composite pattern introduced by
Gang of Four GoF[3]. By using this design pattern, all elements can be treated consistently, i.e. the
container element or what it contains. The hierarchies of shape and relation elements are shown by Figure 2
and Figure 3, respectively.
UmlBaseRelat ion
UmlAssociat ionRelat ion UmlDependencyRelat ion
UmlGeneralizeRelat ion UmlRealizeRelat ion
UmlSt at eTransit ion UmlDeviceConnect ion
UmlInt eract ionMessage
Figure 5 Relation element hierarchy
UmlClass UmlBaseShape
UmlClassAt ribut e UmlElement
UmlMet hod UmlMet hodParamet er
UmlUseCase UmlSt at eAct ivit y
UmlDecision UmlSwimline
«property» + AttachedClass
UmlI nt eract ionObject
«property» + AttachedClass
UmlComponent
UmlDevice UmlProcessor
UmlPackage
- _UmlElement
St at eAct ivit yCont ainer
- _UmlElement - _UmlElement
- _UmlElement - _UmlElement
- _UmlElement
Figure 6 Shape elements hierarchy Glyph Element
BaseGraph BaseLineGraph
BaseShapeGraph Relat ionLineGraph
At t achedShapeGraph Not eGraph
At t achedLineGraph
_destGraph _sourceGraph
Not eAnchorGraph
_notedShape _theNote
_notedLine
Figure 7 Glyph Hierarchy
Glyph is the part that responsible to handle the representation of an element. In general, an glyph
object can be explained in two different views, i.e. shape-based object AttachedShapeGraphs and line-
based object AttachedLineGraphs. A shape-based object contains information about dimension, width,
height, and position of an object in x,y coordinate. A line-based object contains information about the
direction of a line, which can be represented as dots of line. Figure 4 shows the class hierarchy for Glyph
element. Figure 5 and 6 show their relation with model element.
At t achedLineGraph
UmlBaseRelat ion
«property» + AttachedRelation
Figure 8 Bridge between AttachedLineGraph and Model Element
UmlBaseShape At t achedShapeGraph
«property» + Obj ectModel
Figure 9 Bridge between AttachedShapeGraph and Model Element
Not all glyphs require this separation, because not all elements need to be shown in more than one
diagram. The following are the elements that do not require separation: note and element link to a node.
These elements, called BaseGraphs, do not require
MUE: Multi User UML Editor – Suhadi Lili, Sutarsa, Siti Rochhimah
ISSN 1858-1633 2005 ICTS 43
view consistency among diagrams, because it will only shown in one diagram. For this kind of element
hierarchies, we do not apply bridge pattern [2][3].
2.3. Diagram Element
Diagram element represents the container of a glyph object. There are 8 derivation classes of
UMLDiagram as being implemented by our application. The diagram hierarchy of these 8 classes
can be seen in Figure 7.
UmlDiagram UmlAct ivit yDiagram
UmlClassDiagram UmlComponent Diagram
UmlDeployment Diagram UmlSt at eChart Diagram
UmlUseCaseDiagram UmlCollaborat ionDiagram
UmlSequenceDiagram UmlElement
Figure 10 Element Diagram Hierarchy
2.4. Editing
In our implementation, the editing process can be seen from two sides, i.e. at the client side and at the
server side. Although the client application has the direct interaction with the user actions, any editing
command on the model is not carried out by the client. The editing command, i.e. insert, update, or delete, is
passed by the client to the server. The server takes the decision whether an editing command will be
committed or not, and then notifies its decision to corresponding clients. As soon as client receives the
notification, it will update its view accordingly.
The client application consists of Diagram Editor Form and Model Explorer. The diagram editor form
provides the user with means to edit a diagram. In this form, user interacts with the glyph objects. Figure 8
shows the use cases available in diagram editor form.
autentified us er m em ilih elem en
Drag elem en res ize elem ent
hapus elem en m em buat elem en baru
Form diagram
render gam bar m em inta m em buat em en graph
m em inta m odifikasi elem en graph m em inta delete elem en
s inkronisas i data dengan s erver m enotifikas i client atas perubahan
fro m Use-Ca se M o de l
Diagram controller
f rom U s e-C as e Model
Figure 11 Use-cases for Diagram Editor Form
The model explorer displays the model element according to the hierarchy of the element, which is
viewed as a tree. In model explorer, user can interact with the model. Figure 9 shows the use cases available
in model explorer.
m enam bahkan elem en baru kondis inya dis ini adalah
aplikas i client m em inta s erver untuk m em buat
elem en
renam e elem en autentified us er
f rom ak si di f orm diagram
ubah s pes ifikas i tam pilkan s pes ifikas i
include
delete elem en pada tree Model explorer
m em inta delete elem ent m odel m em inta m odifikas i atribut
m em inta m em buat elem en m odel baru
Model Controller
f rom U s e-C as e Model
Figure 12 Use-cases for Model Explorer
2.5. Server Application Architecture
The server application is divided into two parts, i.e. Model Controller and Diagram Controller. The Model
Controller is responsible to handle any manipulation action on the model. While the Diagram Controller is
responsible to handle any manipulation action on the diagram. Therefore, there will only be one Model
Controller and a number of Diagram Controllers for a running project. When the client application passes an
editing command on a model element from user to the server, the command is handled by Model Controller.
While an editing command on a diagram is handled by Diagram Controller.
As already mentioned earlier, a model can be referred by many glyphs that view the model on
different kind of diagrams. As the consequence, any manipulation on a model element should be
synchronized through all of its corresponding glyphs. If a model element is deleted, then all of
corresponding glyphs should be deleted from all diagrams.
Since both objects, model and glyph, are handled by different Controllers, there should be a mechanism
between both controller to handle such object manipulation. In our architecture, we used an observer
pattern to represent the relation [2][3]. Figure 10 displays the implementation of this patter to these
controllers.
BaseDiagramCont roller
+ OnModelElementCreated + OnModelElementDeleted
+ OnModelElementModified
ModelCont roller
_lastUndoEnabledUserSession : long = -1 _lastUndoSequence : long = 0
UndoLength : int = 20 + CreateShapeBasedModelElement
+ CreateRelationBasedElement + StoreUndoData
+ «get» TopLevelPackage _modelController
I List eningDiagram
- _diagramControllerList 0..1
Figure 13 Class Relation: Model and Diagram Controller
Given this architecture decision, a Model Controller can immediately manage a model element
manipulation through all the Diagram Controller.
2.6. Undo
The undo command requires the application to store all previous states, model element and glyph,
that follows sequence of manipulations. When an undo command is initiated, the application not only
should reverse the sequence but also execute the opposite manipulation commands. For example, if an
Information and Communication Technology Seminar, Vol. 1 No. 1, August 2005
ISSN 1858-1633 2005 ICTS 44
undo on a delete command is initiated, the application should recreate the deleted object.
Memento Pattern
In the manipulation action, the application modifies a model element or glyph. Therefore, in the
state storing process, the internal variables of the object should be copied. These internal variables are
probably private attributes of the object. It means that it cannot be accessed from outside. If we change these
variables as public, we might intrude its encapsulation function.
To solve this problem, we introduce memento pattern [3]. The class that contains the internal
variables that need to be stored is added with a method, SaveCurrentState for model element and
SaveGraphState for glyph, that instantiate a memento class, which will store the internal variables. Figure 11
and 12 show the implementation of memento pattern.
UmlElement
+ SaveCurrentState + CopyAttributeFromStateSaver
UmlElement Mement o
«property» + SubElementState
- _UmlElementMemento 0..1
Figure 14 Memento class for Model Element
BaseGraph
+ GetGraphState + CopyAttributeFromStateSaver
GraphMement o
- _GraphMemento 0..1
Figure 15 memento class for Glyph
State Saving Mechanism
As already shown, a modification can be done on an model element or a glyph. Any modification
requires the application to save the state before the modification takes effect. Therefore, any modification
on a model element or glyph needs to be stored in a form of UndoItem or DiagramUndoItem, respectively.
UML diagrams are correlated with each other. Any modification on a model element may require
modifications on other diagrams. Therefore, it is not a wise architecture decision to implement the undo stack
on a diagram level. Because it means that each diagram save its own undo information. The
information for undo command needs to be integrated. The state of a model element that needs to be saved is
embedded into its class structure, as shown in Figure 13.
DiagramUndoI t em
+ «property» CreatedElementID : int [ ] + «property» ModifiedElementSavedState : GraphMemento [ ]
+ «property» DeletedElementSavedState : GraphMemento [ ] + «property» UndoDataOwnerID : int
UndoI t em
+ «property» UndoSequenceNumber : long + «property» UndoDataOwner : long
+ «property» CreatedModelElementID : int [ ] + «property» ModifiedElement : UmlElementMemento [ ]
+ «property» DeletedItemState : UmlElementMemento [ ]
- _DiagramUndoItem
Figure 16 Class diagram for saving states
The UndoItem can be describe as follows: UndoSequenceNumber, a sequence number of
undo information. This number is used to verify whether an undo request is correspond to the
sequence number. If it is not, than an undo request is rejected.
DataOwner, the id of a user that has the right to request the undo, that is, the user that initiates the
modification. CreatedModelElementID, a list of created element
IDs. This attribute is filled if the modification is a create model element command.
ModifiedElement, an array of UMLElementMemento instances that holds the
states of model elements. This attribute is filled if a modification command is intitated.
DeletedItemState, a state element of a deleted model element. This attribute is filled if the
modification is a deleted model element command.
The DiagramUndoItem is quite similar to UndoItem. The only difference is that
DiagramUndoItem save the state of glyphs instance of GraphMemento.
Undo Process
The undo process begins by extracting the UndoItem data that resides on the top of the stack.
According to the modification data create, delete, update, the application decides what command should
be done in order to annul the previous action. Figure 14 shows the general scheme of undo process.
hapus elem ent buat elem ent
kopikan s tate ke dalam elem en
createditem 0 deleteditem 0
m odifieditem 0
Figure 17 Undo Process: State Diagram
MUE: Multi User UML Editor – Suhadi Lili, Sutarsa, Siti Rochhimah
ISSN 1858-1633 2005 ICTS 45
2.7. Client Views Synchronization
To maintain the synchronization view among the clients that connected to the server over the same
model, the server need to notify its clients of any modification that takes place. The mechanism used is
push. Basically, the relation between server and client is similar to Model and Diagram Controller. But,
server and clients reside in separate sites. Therefore, we use .NET Remoting [1][5] to enable the
synchronization between server and clients.
It begins with client that registered its interface methods to server by delegating them. The server sees
the clients as the delegated method. When the server needs to notify a client, it triggers the delegate method
of the client. And then the delegated method functions as server notification for the client.
3. IMPLEMENTATION
In the implementation phase, we use C under .NET Platform 1.1 [1]. We deploy the system in 7
projects, where two of them are the client application and server application. The server is deployed as a
console application, while the client application is deployed as a GUI-based application. The rest of the
projects are built as shared libraries .dll to support the server and client applications.
4. TESTING
For the testing phase, we have planned a number of testing scenarios. These scenarios are targeted to
verify the system integration and based on the use cases that we have proposed. Parts of the tests
involved a number of users working together on a same model and exercising the modification
commands. The results show that the system functionalities
meet its specification. But it fails to show a significant performance in the sense of execution and responds
time.
5. CONCLUSION