The Architecture of UML Elements Model Element

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