Client Design and Implementation

We decide to use the following languages and libraries for implementing the client interface according to the Web technology development.

In the file mymodel.js will find our model, it represents all our diagrams elements we'll give support from the basis and it will be used for creating the JSON file that represents our diagram and that can be translated to OWL.

The JSON string can be generated directly applying the Javascript toSource() (see the function documentation at MDN) function to the object we want to represent. However, using this method will add objects functions and attributes to the JSON representation that the server won't need and make the debugging difficult. In order to solve this issue, we create a function called to_json() in each primitive class that return a JSON object that can be transformed into a string for sending to the server.

A MyModel class will define the common behaviour and information all our diagram elements wil have, initially we want a name as mandatory for all elements, even links. Then, we created a Class subclass that represents the UML Class primitive and it can have attributes and methods lists.

All of our models instances have a relation and can create its propper Joint object so it can update its view with the correct information our model have.

We contemplate the possibilities for giving support not only for the UML graphical language, also for ERD and, in the near future, OMR. Creating and editin diagrams elements has some differences that has to be taken in mind while programming the Front-End and while translating it to Description Logic and OWL/OWLlink.

We decided to use an Abstract Factory pattern mixed with an Observer for resolving this conflict. The figure fig:abstract_factory_observer show the design of our model.

j

The interface supports widgets and diagram objects for different languages. This are accessible throug the gui package. The following design is intended to provide simple access from different part of the software while providing an organized development environment.

The GUI class handles differents GUIIMPL instances. Each GUIIMPL are a representation of the language interface, its events, widgets and diagram. The WidgetMgr subclasses manages all the widgets needed. DiagAdapter provides a bridge between interface and the model diagram object, useful when showing the diagram response in the UI while doing a modification to the MyModel subclass object.

Some widgets are common to all languages. For supporting them, the design includes a WidgetMgr associated with the GUI class.

A widget is created adding and modifying the following files:

• Add a widget Backbone.View subclass.
• Add a widget HTML or PHP template.
• Modify the WidgetMgr subclass (for UML is UMLWidgets) for creating an instance of the widget class.
• Add a template in all_templates.php.
• Add a div as a placeholder in placeholders.php.

The compiler script will merge all CoffeeScript views founded in coffee/views directory automatically.

For example, supose we want to create a modal dialog, common to UML, EER and ORM interfaces, called "Warning". We need to create a CoffeeScript file that will render and accepts events and a template PHP file which represent the HTML visual part.

The CoffeeScript file will be stored in /coffee/views/common/warning_widget.coffee.

exports = exports ? this
exports.views = exports.views ? {}
exports.views.common = exports.views.common ? this


WarningWidget = Backbone.View.extend
    initialize: () ->
        this.render()

    render: () ->
        template = _.template $("#template_warning").html() 
        this.$el.html template({})

    events:
        "click button#done_button" : "hide"

    hide: () ->
        this.$el.modal 'hide'

    show: () ->
        this.$el.modal 'show'


exports.views.common.WarningWidget = WarningWidget

The PHP file, is stored in the same folder and must be called accordingly (i.e. /coffee/views/warning.php).

<div class="modal fade" id="warning_widget" tabindex="-1" role="dialog"
     aria-labelledby="warning_widget" aria-hidden="true">
    <div class="modal-dialog" role="document">
        <div class="modal-content">

            <div class="modal-header alert alert-warning">
                <h1 class="modal-title"> Warning: </h1>
                <button type="button" class="close" data-dismiss="modal"
                        aria-label="close">
                    <span aria-hidden="true">&times;</span>
                </button>
            </div>

            <div class="modal-body">
                <dl>
                    <dt>Status:</dt><dd>
                        <div id="errorstatus_text"></div>
                    </dd>
                    <dt>Server Answer:</dt><dd>
                        <pre>
                            <div id="errormsg_text"></div>
                        </pre>
                    </dd>
                </dl>
            </div>

            <div class="modal-footer">
                <button type="button" class="btn btn-primary" data-dismiss="modal">
                    Hide
                </button>
            </div>
        </div>
    </div>
</div>

The client needs to load the widget in its Javascript code. For that purpose, we create an instance of the view in the constructor of CommonWidgets.

class CommonWidgets extends gui.WidgetMgr
    constructor: () ->
        super()
        # ...
        @warningwidget = new views.common.WarningWidget
            el: $("#warning_placeholder")

The following code adds the template, it should be inserted in the all_templates.php:

insert_template("warning", "common");

This function searchs for the warning.php file inside the /coffee/views/common.

Finally, we add the placeholder in the placeholders.php file:

<div id="warning_placeholder"></div>

TODO: Add QUnitJS website at the bibliography. TODO: Explain how testings has to be create.

The development of WICOM is separated on some stages and modules. Implementing each module and testing it "by hand" can work for the first time, but when implementing the second stage or adding a new feature we may break the code we have created before.

For detecting this, we create some black-box unit tests while writing the code. The idea is this: we wrote the expected value that each important function or feature should answer when executed with a predefined parameter.

QUnit help us on writing the comparation between the results and the function calling, and also it execute each test automatically and show us the results in a propper format for easy detect the problems. It only works for Javascript (or compiled CoffeScript) code, in the following section we'll explain the unit testing for PHP.

biblio.bib