Warning: Declaration of action_plugin_authad::register(Doku_Event_Handler &$controller) should be compatible with DokuWiki_Action_Plugin::register(Doku_Event_Handler $controller) in /home/clients/0de9ff9beee4541cf1f61437ce7bce2b/web/hec/lib/plugins/authad/action.php on line 89

Warning: Declaration of action_plugin_editsections::register(&$controller) should be compatible with DokuWiki_Action_Plugin::register(Doku_Event_Handler $controller) in /home/clients/0de9ff9beee4541cf1f61437ce7bce2b/web/hec/lib/plugins/editsections/action.php on line 72

Warning: Declaration of action_plugin_importoldchangelog::register(&$controller) should be compatible with DokuWiki_Action_Plugin::register(Doku_Event_Handler $controller) in /home/clients/0de9ff9beee4541cf1f61437ce7bce2b/web/hec/lib/plugins/importoldchangelog/action.php on line 157

Warning: Declaration of action_plugin_tag::register(&$contr) should be compatible with DokuWiki_Action_Plugin::register(Doku_Event_Handler $controller) in /home/clients/0de9ff9beee4541cf1f61437ce7bce2b/web/hec/lib/plugins/tag/action.php on line 79
Appendix C Technical Supplements [HEC 4 ALL]

Appendix B Sample Business Models

Appendix C Technical Supplements

C.1 Prototype 2 Server Domain Classes

Figure C1 shows the class diagram of the domain objects representing the business model ontology. There is no class representing the building blocks instead there exists a class for each element of a building block. These classes all inherit their common attributes from a common element parent class. Elements have all at least one layer. Some subclasses of element have additional custom attributes, while others do not. Every possible element is modeled, this to allow the creation of all the linked relationships defined by the BMO. On the figure the dashed lines symbolize these many to many relationships.

A business model is composed by all its layers, elements and annotations. A business model can also have many children to create the branch graph of the snapshot manager.

A user can own many business models through the permission mapping.

Questions are grouped into question sets, but there is no relationship with annotation for saving an answer. The reference to the question’s id is currently stored in a text field of the annotation.

There are also java enum classes to define the value range of some of the attributes.

Figure C.1: Prototype 2 server domain classes and attributes

C.2 Prototype 2 Client Classes

Figure C2 illustrates the file structure of the flex client application. Each rectangle is a folder, the bold text being its name. Since the Cairngorm framework was used we can identify the Model, View, Controller structure it advocates. In blue are the model components, in orange the views and in green the controllers.

The model part is composed of business services which are the connection points to the backend server. The Value Object are a local representation of the server domain classes, they need to be defined to allow proper mapping between Java and ActionScript. The model class itself is a singleton regrouping all the state information and data for binding to views.

The views are for the most part all defined in mxml and organized in subfolders only for clarity. The appcontroller class connects the events to commands. One event can have multiple types, but each type of an event is mapped to a unique command.

Figure C.2: File structure of the 2nd prototype’s client

C.3 Detailed Example Roundtrip of a Query

The client being a user interface and object oriented program, most of the actions are initiated by events. Figure C3 shows the event call history for a link creation between two elements.

Figure C.3: Event sequence of a link creation after drag and drop

Dragging an element will start an event that registers the drag operations. Whenever the dragged element enters in contact with another element, a new event is started which will check if the two elements can be dragged onto each other (1.1). If this is the case, the icon of the dragged element will change, the underlying element will get highlighted and the correct operations are set in the drag manager. This allows, when the element is dropped (1.2), to execute the link creation event between the two elements(1.2.1-3). This action will call the appropriate method on the server via the service endpoint (4-6). The server looks up the correct elements from the database, validates if linking this two types of element is allowed and then creates the associations that represents the link between the two elements. After receiving confirmation of success from the server (6-7), the client starts another event that will do a refresh of the model (8-10). The refresh event, will contact the server to get the last version of the complete graph of object and then parse it (11-14). While parsing the data, objects are put in their respective lists which are watched by the graphical objects which display the model (15). Also additional listeners are added to be able to interact easily with the data from the different user generated events (15.1). Finally flex’s automatic data binding will triggers its own refresh events on the subscribed view elements (16).

C.4 Versions of Software Used

C.4.1 Prototype 1

C.4.2 Prototype 2

Client

Server

Assets

References

tm/appendixc.txt · Dernière modification: d-m-Y H:i par boris
chimeric.de = chi`s home Creative Commons License Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0 Fristcher.ch