Summary:It is possible to incorporate the proposed model extensions into different web engineering solutions’ models, either using«merge»or model transformations. This makes it easier to create usability tool support which can work with different types of models. Special steps are needed for XML-format presentation models.
The previous section has shown how to add information about the context, presentational and navigational aspects to an existing set of web engineering models. This was done by combin- ing newly introduced metamodels (from theusability package) with existing metamodels from
UML-based web engineering (UWE). This section more thoroughly describes the changes re- quired at the metamodel level to cleanly integrate the proposed model extensions into existing models. Figure5.12shows an overview of the classes in the metamodel. Together, they form the
usabilitypackage.
The goal behind the clear separation of the model extensions is to design the extensions to be “portable” to other web engineering environments and models. This includes making the extensions available to all the web engineering solutions mentioned in section3.2, such as UWE, WebML, OO-H and others. Another important aim is portable tool support: It should be avoided that any model-based tool must be adapted for each web engineering solution to allow the tool to read that web engineering solution’s models. The presence of the commonusabilitymetamodel is a way to achieve this, as it enables a tool to keep track which class in the existing web engineering model represents which abstract concept – for example, any presentational metaclass will be derived fromPresUiModel. Furthermore, most of the properties which are of interest to a tool with usability/accessibility support are specified in one of the metaclasses.
Integration is only necessary once for a particular set of web engineering models. As outlined below, there are several ways to integrate the model extensions depending on the features of the web engineering model that is to be extended. Figure 5.13 shows how theusability model extensions are formally integrated into UWE models:
• Two «merge» operations are used to copy both UWE’s metamodels and the usability
model extensions into the same namespace, which is calledusabilityUWEin the figure.
• Model elements are added which connect the web engineering model with the extensions.
For example, UWE’sNavigationalClassmetaclass is made a child class ofNavUiModel.
• Finally, some elements of the existing models may also have to be modified. A typical
example is that in UWE’s representation of a “guided tour” pattern, the type property, inherited from theUiPatternclass, is set to the fixed value “guided-tour”.
The UWE example in figure5.13 is a slightly simplified version of the actual model. Apart from the fact that not all relevant classes and attributes are shown (e.g. other pattern classes in addition toGuidedTour), the UWEpackage structure is more sophisticated in reality, with a hi- erarchy of packages for different aspects of the modelling task [Knapp04ArgoUWE]. To avoid the need for the developer to duplicate information about patterns in the model, the informa- tion from the association between UWE’sNavigationalClassandAccessElementis “copied” to
NavUiModelandUiPatternby means of aunionwith a singlesubsetfor each association end. A few prerequisites must be fulfilled for a similar procedure to succeed with another web engineering solution’s models. First, obviously the notation that is used for all models in this chapter is the Unified Modeling Language – however, not all existing models use UML. For the web engineering methods which are most important in practice (WebML, UWE and OO-H), this is not an issue most of the time (see below for an exception) as they are UML-based or at least provide an alternative UML-based notation for all concepts. In general, a trend towards using
usability UiModel UiPattern PresUiModel UWE UI Element NavigationalClass AccessElement 1 0..* PresentationClass UI View GuidedTour 1..* 1..* usabilityUWE <<merge>> <<merge>> NavigationalClass AccessElement GuidedTour type : string = "guided-tour" 1 0..* UiModel
PresUiModel NavUiModel UiPattern
type : string 1 0..* UI View PresentationClass 1..* UI Element 1..* Context appliesTo 0..* 0..* Context appliesTo 0..* 0..* pat union ui union subsets pat subsets ui NavUiModel 1 0..*
Figure 5.13: The«merge»operations copy existing web engineering models (top left) and the extension classes (top right) into a common package, usabilityUWE (bottom). In the next step, they are combined, primarily using inheritance (model elements shown in red).
UML is noticeable [Kappel04WE, section 3.10], so it is unlikely that future developments will be based on other modelling notations. If the notation is not UML-based, the model extensions cannot be applied – a UML profile must be created for the notation, a UML model must be produced using automatic model transformations, or a UML model which can express equivalent semantics must be created from scratch. In case this proves inconvenient or if the effort cannot be justified, one last resort exists: As shown below in section5.4, the non-UML modelling solution could be used to output an implementation in which the information from theusabilitypackage is embedded, e.g. using a Microformats-like syntax.
Another prerequisite for a successful integration of the usability-related information is that the concepts of navigational and presentational models exist in the web engineering solution. In most cases, this is not a problem – the concepts are general enough to be applicable to most existing models. Sometimes, the distinction between navigation and presentation models is not very pronounced. For example, with UWE the presentation model is only a refinement of the navigation model. For these kinds of models, it is also possible that the class which represents a page inherits from bothNavUiModelandPresUiModel.
Finally, the classes of theusabilitypackage contain a number of assumptions: HTML pages are represented with classes (rather then, say, associations), any user interaction pattern refer- ences several navigation classes using a directed association, no suitable user model is present so the one introduced in usabilityshould be used, etc. A web engineering model can conceivably have a completely different view of these concepts, or it can already contain information about the context of use which should not be duplicated in another part of the models. If such a mis- match between models occurs, again automated model transformations are a promising solution: Either the “native” models are transformed just for the purpose of giving them to usability-related tools, or modelling takes place with an adapted version of the models, which is transformed into a form suitable for the web engineering solution’s code generation.
Integration With Non-UML Presentation Models
The WebML and OO-H presentation models do not fulfil the requirement that all models should be UML models. Instead, they are XML documents which are used as page templates [Ceri00WebML] [Cachero00PresOOH]. Similar to these two approaches, other current and fu- ture web engineering approaches might choose a related approach and interpret the page layout and presentation as part of the implementation. (In the form of UWEXML [Kraus02Generation], even UWE features a similar, XSLT-based template mechanism, but UWEXML templates are present in addition to UWE’s presentation models.)
For web engineering solutions whose presentation models are only page template documents, there are two possibilities to provide the information from the presentational metaclassPresUi- Modelto tools:
• Introduce a new presentation model. Figure5.14shows a possible way to do this: In the
usabilityWebML UiModel PresUiModel role : string importance : int PageArea id : string 0..* <<artifact>> WebMLPageTemplate <<instanceOf>> Context 0..* appliesTo 0..*
Figure 5.14: When the presentation model uses XML rather than UML, a new class
PageAreais introduced. After further refinement, it becomes the XML page template.
newPresUiModelchild class which doesnothave any corresponding class in the existing web engineering solution. In the figure, it is simply called PageArea. This class can represent a hierarchy of page areas, where the top-level PageArea represents an entire HTML page. The non-UML page template document can be imagined as an instance of this newly introduced simple presentation model.
• Do not includePresUiModel child class instances in the models at all, only embed infor-
mation on page areas (“this page area is advertising”) in the implementation. This means that the tools need to analyse not only the models, but also the final HTML code to ac- cess the relevant information. In this case, usability analysis which is based on the models
alone(section4.2.3) cannot determine e.g. whether the page layout is acceptable, but a tool which analyses both the models and an implementation (section4.3.1) will not have this problem.
In the second case, the necessity for tools to access the HTML code is not a significant problem. In practice, many usability-related tools will already have to access the implementation directly for other reasons. As shown in the next section, embedding of model information has other advantages besides solving the problem that some web engineering solutions do not feature a
concept that corresponds to PresUiModel. The section also explores different ways of adding model information to the implementation of a website.