Analysis Results

The analysis of these web application development approaches, according to the analysis criteria listed in the previous subsection, has yielded the results that are presented in Table 4.1.

Table 4.1: Relevant characteristics of the analyzed MDE approaches and languages. Web- ML UWE XIS2 Out- Systems Sketch- flow A. Domain modeling ! ! ! ! #

Independent from persistence ! ! ! # —

Independent from UI ! # ! ! —

B. Business Logic modeling ! ! ! ! !

Domain manipulation using patterns ! # ! ! #

Custom patterns ! — ! # —

Low-level specifications ! ! # ! !

Domain query ! ! — ! !

Domain manipulation ! # — ! #

Process specification # ! — ! #

C. Navigation Flow modeling ! ! ! ! !

D. User Interface modeling ! ! ! ! !

Access control specification ! # ! ! #

Custom interface elements ! # # ! !

Interaction patterns ! # ! ! !

Custom interaction patterns # — # # !

UI elements bound to domain

elements ! ! ! ! !

Bindings are customizable # # ! ! #

E. Model-to-model transformations # ! ! # #

F. Generated application is complete # # # ! #

G. Independent from deployment

environment ! ! ! # !

A – Domain modeling. Domain modeling is an essential aspect in any application development approach. The analyzed approaches enable independence between the domain model and other parts of the application design, but only WebML and XIS2 address domain modeling in a manner that is completely independent of the remaining application details, by not requiring that the domain model be adjusted with UI- or persistence-oriented details. In UWE’s case, the Content Model is supposed to be somewhat oriented toward the Presentation Model (e.g., in the Address Book example at the UWE tutorial5_{, the}

AddressBookclass has an attributeintroduction, used for the main screen of the application

5

4.1. COMPARATIVE ANALYSIS

to show a small introductory message to the user). In the Agile Platform, the domain model is modeled like a database schema, although with different terms (Entities and Attributes instead of tables and columns); although this lack of abstraction may be regarded as a bad thing, in practice it does endow the designer with a greater level of control over the web application’s real database schema. WebML also features a way to adjust the domain model to particular needs of other layers, by means of the Derivation Model, and XIS2 provides the BusinessEntities View to address the manipulation of domain entities by other layers.

B – Business Logic modeling. Business logic modeling is addressed by all of the analyzed approaches, albeit in very different ways. XIS2 considers this aspect by means of Business-Entities – allowing other layers to manipulate elements that are coarser- -grained than domain elements – and patterns (the typical create/read/update/delete

operations are supported, and the designer can add more operations, although they must be implemented in a manual fashion). WebML uses similar mechanisms (the Derivation Model for adjusting the domain model to other layers, Content Units and Operation Units to query and manipulate the domain, and the designer can add new Operation Units that must be implemented manually), but the designer can orchestrate them in a flowchart-like manner, enabling the specification of data manipulation workflows. UWE, however, only considers this aspect by means of the Process Model – class diagrams that represent the relationships between the various processes, and activity diagrams that specify the steps of each process – and OCL constraints; the implementation itself must be done manually. Sketchflow, albeit a prototype-creation tool, allows designers to imbue their prototypes with some behavior, by means of the Behaviors mechanism; it can also be extended with additional behavior patterns, but the creation of such functionality involves some manual development. Finally, the Agile Platform allows designers to specify complex business logic in a graphical manner: by defining Actions such as domain query and manipulation patterns, designers can specify most (if not all) of the functionality that would usually have to be manually coded.

C – Navigation Flow modeling. Navigation flow modeling is addressed by all of the analyzed approaches, because it is fundamental to any kind of web application. Due to their web application modeling nature and all that it implies (e.g., the existence of HTML pages, hyperlinks to navigate between pages, using request parameters or a similar mechanism to provide necessary parameters), they all follow the same guidelines (although the terms used are somewhat different): a directed graph is drawn, where nodes correspond to HTML pages, and edges correspond to the possible navigation flows that are available

to the user within the context of a certain page. Nevertheless, the analyzed approaches do differ in whether the designer can specify the sets of edges (i.e., actions or links) available in each node. In WebML, each DataUnit node has a well-defined set of links, for input and output, and the designer cannot specify additional links. On the other hand, XIS2 allows the designer to specify actions, associated to UI elements in a page, and the navigation flows will afterward be associated with those page actions; XIS2’s approach to this aspect is very similar to what can be found in the Agile Platform, Sketchflow, and UWE.

D – User Interface modeling. Except for WebML, all of the analyzed approaches address UI modeling in a graphical WYSIWYG (What You See Is What You Get) manner. WebML only allows the specification of what elements will be present on the page, but not where they will be located. Also, the Agile Platform, WebML, and Sketchflow support the creation of new page or UI elements to be reused in other application screens. This allows designers to specify certain screen sections only once, and import those sections into some/all of the application’s screens, with the obvious added advantage that changes to such a section need to be done only in a single point in the model; a good example of such a component would be a website banner, or a website navigation tree.

The behavior aspect is explicitly addressed by XIS2, WebML, and the Agile Platform through the capture of UI patterns, enabling applications to interact with users instead of just displaying requested resources. This focus on the capture of UI-oriented patterns is also present in Sketchflow, in the form of Behaviors. Sketchflow itself is the only tool, of those analyzed, that supports adding new interaction patterns in a reusable manner. Also, the specification of access control (i.e., which users or roles can access which UI components) is supported in all approaches, except for UWE and Sketchflow. Although in Sketchflow this shortcoming is understandable (considering its nature as a prototyping tool), in UWE this hampers its adequacy to model real-world scenarios.

All of the analyzed approaches allow binding UI elements to domain elements (e.g., configure the rows of a table to show the values of a field in specific instances). However, only XIS2 and the Agile Platform allow the customization of those bindings in the model (e.g., change a cell in a table row to show a different value for each instance). Although not being able to customize these bindings can simplify the model and avoid designer errors, in practice this is also a limitation of the language, which forces developers to change generated source code in order to address specific requirements.

E – Model-to-model transformations. Support for model-to-model transformations is an aspect that is usually not addressed by web application modeling approaches; from the analyzed approaches, only the UML-based ones (UWE and XIS2) address this aspect.