Server Application Architecture Undo

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