WebML which stands for Web Modeling Language is a language elaborated to support designing data-intensive web solutions. There is given in this post a quick introduction to this modeling language with an investigation to incorporate it into web projects. Some web solutions may suffer from lack of incomplete requirements definitions missed in a design stage which can finally lead to burden maintenance. WebML is shown here as a comprehensive tool that helps avoid incomplete requirements collection, incorrect estimation during design time and offers dedicated models facilitating implementation. The text considers it all for medium and large size projects.
Background
I first met WebML and WebRatio when I was studying at the technical university. In the beginning I was very skeptical to them. My thoughts become finally clear after spending long hours with technical documents and WebRatio IDE to elaborate a lecture and to prepare a working project. I found WebML as an interesting way to model web solutions. On the other hand, WebRatio seemed to be good only for predefined purposes. Custom solutions, especially business logic services were inconvenience to introduce (or maybe I didn’t know how to do that). I didn’t investigated so deeply what WebRatio offers now when I was writing this text. I’d like to focus here on the WebML. There are considered only main principals offered by this methodology. Links for language materials, success stories and examples can be found in the References section, particularly positions: [1, 2, 3, 7].
WebML definition
“WebML is a visual language for specifying the content structure of a Web application and the organization and presentation of such content in a hypertext (Ceri et al., 2000, 2002)” [8].
1. WebML
WebML can be treat as a tool to describe idea of a web system. Having once defined solution it is possible performing further analysis on it to find advantages, disadvantages and adjust a solution when needed. An idea is usually vast without details. WebML is dedicated to web projects and brings something more than other models. These arguments are the reasons I think it’s worth to consider incorporating WebML into web projects. Models are described in further dedicated part.
IFML and WebML
According to [5] Interaction Flow Modeling Language (IFML) is the new OMG standard language with a purpose to modeling the application front-end. They claim: “IFML is inspired by the extensive 10-year experience of WebML and WebRatio.” It means that WebML and WebRatio are currently under process of complying with IFML notation [6]. Elements names and visual representations are changing to those defined in the IFML. Differences between WebML and IFML are described in Differences Between WebML and IFML.pdf file which is included in the WebRatio 7.2 installer package [4].
2. Models overview
The core of the WebML are models. There are four general models: Structural Model, Derivation Model, Hypertext Model (divided into: Composition Model, Navigation Model) and Presentation Model.
Structural Model
Structural Model is to express conceptual data organization. It based on a Entity-Relationship model. The Entity and Relationships are the fundamental elements. No new notation is introduced. It is compatible with well known notations like E/R model and UML class diagrams.
Structural Model example
User, Group and Module and their relations (Fig. 1) are default created types by WebRatio in a new domain model. I addition to them I created a simple structure with Employee, Department and Company.
Figure 1: Structural Model example
Derivation Model
Derivation Model it to provide additional information into structure schema based on already existing definitions. When an additional attribute can be computed using some other attributes expressed in a schema then there is no need to store such attribute. Storing this attribute would be redundant. Relationships can also be derived.
Hypertext Model
Hypertext Model takes care of a general organization of a view into areas, areas into pages, components on pages and finally links between them. There are two logical structures: views and areas. View is the top level structure within a project domain which is a parent for areas. One project can have several views corresponding to the same domain but with different purposes. We can imagine different views for ordinary web browser and for mobile devices.
This model is divided into two more specified separate models:
1) Composition Model – this one is to define pages and their internal structure. In other words, it prepares a logical layout of components within a page. The actual visual representation (styles, images) is determined by the Presentation Model.
Page is top level visual creature existing in an area and is a placeholder to smaller component units.
Three types of pages:
- The home page, this is a unique and default page for a view. Is expressed through home icon symbol.
- The default page, this is a unique page and default page for an area. Is expressed through [D] symbol.
- The landmark page, any page in a view which is achievable through a direct link. Is expressed through [L] symbol.
There are predefined visual components to display data called Composition Units (Tab. 1). Operation Units (Tab. 2) are another unit types responsible for operation on a data. Those two unit types cooperate to build flows for use cases. For example to update an entity it is good to first take a look on an existing state (Data Unit) and then provide new data in a form (Data Entry Unit) and finally perform an update operation (Modify Unit). More details are in Hypertext Model example section.
Table 1: Composition Units
Unit | Visual representation | Description |
Data Unit | ![]() |
Displays one entity instance. |
Multi-data Unit | ![]() |
Displays collection of entities. |
Index Unit | ![]() |
Displays list of entities. Each position is a link to corresponding entity instance. |
Scroller Unit | ![]() |
Enables go through list of entities exploring them in a sequence. |
Filter Unit | ![]() |
Delivers functionality to specify search criteria. |
Direct Unit | ![]() |
Enables select entity which corresponds to an entity based on one-to-one relationship . |
Table 2: Operation Units
Unit | Visual representation | Description |
Data Entry Unit | ![]() |
Enables to provide input values. |
Create Unit | ![]() |
Creates a new instance of an entity. |
Delete Unit | ![]() |
Deletes an instance of an entity. |
Modify Unit | ![]() |
Modifies an instance of an entity. |
Connect Unit | ![]() |
Creates a new instance for a relationship. |
Disconnect Unit | ![]() |
Removes an instance of relationship. |
Generic Operation Unit | ![]() |
Invokes a generic operation, |
2) Navigation Model – specifies connections between elements in a one view. There are possible connections within units, between pages, between pages and units. Depends on which exact elements are connected, there are two distinguished link types:
- Contextual links, connect units following defined structure schema. This link passes some information from a source to a destination hence is contextual. For example, to delete an entity (Delete Unit) it is required to have an identifier to be able to determine that entity. An identifier in this case may comes from Data Unit instance.
- Non-contextual links, connect pages and do not pass extra information. It is just a pure link.
Hypertext Model example
To materialize the theory I prepared a simple hypertext model example (Fig. 2) which can be an introduction to develop an ERP solution. The domain is as defined in previous Structural Model example (Fig. 1).
Figure 2: Hypertext model example
This model consists of:
1) One view, named ERP (is not explicitly visible on Fig. 2, all elements belong to this view).
2) Four areas (outer rectangles) directly associated with ERP view. There are: ERP dashboard, Employees management area, Hardware management area and Software management area.
Each area is a logical group of related pages. All of them are marked with Landmark [L] hence they are available from each location within current view. ERP dashboard area has a ERP Home page which is marked both default [D] and home [home icon]. ERP home is the only home page in the whole ERP view. It makes it the first displayed page when ERP application is loaded. Each area also has a default [D] page which is presented when the exact area is chosen.
Dashboard, Hardware and Software areas have no reflection in the domain model therefore they are empty. Employees management area contains some simple CRUD operations on prepared structural model. The green arrows point to destination when operation finishes with a success. On the other hand, the red arrows are to handle operation failure. This model was design using WebRatio 7.2.0 which is following IFML notation and the visual representation little differs from elements in tables Tab. 1 and Tab. 2.
Presentation Model
Presentation Model is responsible for look and feel definition and pages layout composition.
3. An approach to incorporate models
Web solution can be seen in those four models dimensions. Generally speaking, nearly each medium and large size web project undertakes following objectives: data, pages, links and visual representation. When to consider them in terms of WebML we need to be more pragmatic in models. It means that all these objectives need to first appear in a modeling stage before the actual implementation will take place.
We can assume that most nowadays created web project use some kind of data models which reflect to the Structural Model. When data model in web tier is taken directly from business domain then it is the same as used by service/façade tier. It implies that in most cases there is no need to redesign data model.
Derivation Model takes place when some attributes or relationships are not directly stored and are received based on already existing smaller units.
The Hypertext Model seems to be the most outstanding WebML model. It addresses those design issues which are often neglected in web projects. Pages, content and links are elements especially associated with web. It is easier to find potential bugs and lacks having all elements and their dependencies on a picture. This model can merge both business and technical worlds because of model’s simplicity. Model expresses his content using simple shapes and symbols. Visual form tend to be more straightforward to understand than text descriptive one. Data and operation units are also worth to consider. There is a possibility to define new types of them. In case when WebRatio will not be the realization tool, the idea of units can be a motivation in elaborating internal frameworks. Unit definitions could predefine generic visual components and expected operations.
This post’s title tells about a structured approach. This is achieved by models. Models are in the middle between idea and implementation. They are the detailed high level idea’s descriptions and a foundation to provide a final implementation. Structured approach is also reflected through different model types with dedicated purposes. Number of models determines the model-driven nature.
When to use WebML:
1) For medium and large scale web projects, especially data-intensive
2) Reasons for use the hyperlink diagram:
- hyperlink graph gives an opportunity to asses both a visual complexity and a measurable complexity
- diagram allows to observe links density, links connections depth, links cycles, missing and redundant links
When not to use it:
1) For static web sites
2) For small web projects to avoid overhead with models incorporation
4. Summary
WebML and WebRatio are closely related even though it is not required go for both of them. Moreover, the WebML does not have to be applicable to a web project in all his aspects. It is a wise to select only those parts of this language which can bring a value. It mainly depends on project’s scale. WebML can be especially appreciated by those people who have business-oriented thinking. This methodology is compatible with a top-down process in delivering IT projects. It operates on models which means that can be implemented in many ways, to many targets, in different times, and so forth. On the other hand, there is no way to get it for free. It requires to take time and trouble to get used to it. People involved in such project should have a knowledge appropriate to requirements. An another important issue is to bear in mind the IFML when using WebML.
This post is only a short introduction to WebML and also encourages to consider taking advantage of different models in web projects design.
References
[1] WebML home – http://www.webml.org/
[2] WebML on Wiki – http://en.wikipedia.org/wiki/WebML
[3] WebRatio Home – http://webratio.com/
[4] WebRatio download page – http://webratio.com/portal/content/en/download
[5] IFML home – http://www.ifml.org/
[6] IFML specification – http://www.omg.org/spec/IFML/
[7] Conference Management System case study – http://webml.org/webml/upload/ent5/2/IWWOST01.pdf
[8] S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, and M. Matera. Designing Data-Intensive Web Applications. Morgan Kauffmann, 2002.