WebML modelling in UML - UMA

WebML modelling in UML

N. Moreno, P. Fraternali and A. Vallecillo

Abstract: In recent years, we have witnessed how the Web Engineering community has startedusing the standard unified modelling language (UML) notation, techniques and supporting toolsfor modelling Web systems, which has led to the adaptation to UML of several existing modellinglanguages, notations and development processes. This interest for being MOF and UML-compliantarises from the increasing need to interoperate with other notations and tools, and to exchange dataand models, thus facilitating reuse. WebML, like any other domain-specific language, allows one toexpress in a precise and natural way the concepts and mechanisms of its domain of reference.However, it cannot fully interoperate with other notations, nor be integrated with other model-based tools. As a solution to these requirements, a UML 2.0 profile for WebML which allowsWebML models to be used in conjunction with other notations and modelling tools has beendescribed. The paper also evaluates UML 2.0 as a platform for Web modelling and identifiessome key requirements for making this version of the standard more usable.

1 Introduction

The UML [1] is a general purpose visual modellinglanguage for specifying, constructing and documentingsystems, which can be used in all major applicationdomains and implementation platforms. It has beenwidely adopted by both industry and academia as the stan-dard language for describing software systems. This isreflected by the fact that it is currently supported by hun-dreds of model-driven commercial tools, which have beensuccessfully used in numerous development projects.However, the fact that UML is a general purpose notation

may limit its effectiveness in modelling some specificdomains (e.g. the hypertext interfaces of Web applications),for which specialised languages and tools, such as forexample WebML/WebRatio [2], OO-H/VisualWade [3]and so on may be more appropriate. These domain-specificlanguages (DSLs) tend to support higher-level abstractionsthan general-purpose modelling languages, and are closerto the problem domain than to the implementationdomain. Thus, a DSL allows modellers to perceive them-selves as working directly with domain concepts.Furthermore, the rules of the domain can be included intothe language as constraints, enabling model-based checkingof illegal or incorrect specifications.Despite the potential benefits of using specific languages,

in the short term we certainly see a growing interest inMeta-Object Facility (MOF), UML and UML profiles formodelling Web applications. This interest for being MOFand UML-compliant arises from the increasing need tointeroperate with other notations and tools, and to exchangedata and models, thus facilitating and improving reuse. Andalthough some DSLs (and their supporting environments)

# The Institution of Engineering and Technology 2007

doi:10.1049/iet-sen:20060067

Paper first received 15th November 2006 and in revised form 10th May 2007

N. Moreno and A. Vallecillo are with the Department of Lenguajes y Cienciasde la Computacion, University of Malaga, Spain

P. Fraternali is with the Dipartimento di Elettronica e Informazione Politecnicodi Milano, Milano, Italy

E-mail: [email protected]

IET Softw., 2007, 1, (3), pp. 67–80

might be probably more suitable for modelling specificaspects of Web applications than pure UML, they havenot reached the level of acceptance and diffusion of UMLmodelling tools. As a consequence, developers must buyand use ‘yet-another’ modelling tool (with additional learn-ing costs and efforts) if they want to take advantage of theirfavourite DSL. Even worse, proprietary DSL-based toolsoften do not interoperate with other tools, which fragmentsthe workspace into a a set of isolated developmentenvironments.

Because of these driving forces, the Web Engineeringcommunity has started using standard UML notation, tech-niques and supporting tools for modelling Web systems,which has led to the adaptation of several DSLs, represen-tation diagrams and development processes to UML.Several authors have proposed their approach to the defi-nition of metamodels and UML extensions, as illustrated,for example [4–7]. Especially UML profiles have provedto be a simple and effective mechanism for representingproprietary Web Engineering modelling languages.

We provide a contribution to the effort of expressingstate-of-the-practice Web Engineering modelling languagesin UML, by introducing a UML 2.0 profile for WebML,which allows the WebML language and its developmentprocess (supported by the WebRatio tool) to be smoothlyintegrated with standard UML development environments.In addition, we also describe a metamodel for WebML,which will allow its integration with other MDA tools assoon as they are available (editors, validators, metric eva-luators etc.) and also with other model-driven approachesand tools (e.g. those using KM3-or Ecore-basedmetamodels).

The remainder of the paper is organised as follows.Section 2 introduces a running example used throughoutthe paper, and Section 3 briefly presents WebML andWebRatio. Then, Sections 4 and 5 define the WebML meta-model and WebML profile, respectively. Section 6 com-pares the WebML and UML representations, reviews themain design choices taken in the definition of WebMLand discusses how they have been impacted by the use ofUML for encoding WebML, and summarises some of thelessons learnt in the process of mapping WebML to UML.

67

Finally, Section 7 examines related work, whereas Section 8draws some conclusions and outlines future works.

2 Running example

Before illustrating WebML and discussing its represen-tation in UML, we introduce a simplified runningexample: the product catalogue and content managementsystem of small furniture manufacturing company.

The catalogue is a Web application offered to the generalpublic that advertises various types of furniture, for examplechairs, tables, lamps and so on, and also special combi-nations of items sold at a discounted price. Individualitems are described by an image, a textual description,their price, a set of technical features (dimensions, availablecolours etc.), and larger images. Combinations are illus-trated by a photograph, advertising text and the discountedprice.

Information about the store locations is also made avail-able, including the address and contact information, animage of the store and a map. Users are expected to visitthe catalogue home page containing the offer and theproduct of the day. From there, they can access the detailsof the advertised product and offer, or enter dedicatedareas for navigating the catalogue, using various searchand browsing facilities.

From the page describing a combination, the individualitems forming the combination can be accessed, and conver-sely, it is possible to navigate from an item to the combi-nations including it. From the home page, the list ofstores can also be reached.

The employees of the company can login from the homepage into a protected Web application, which enables mana-ging the content of all the objects displayed in the publicsite.

3 WebML and WebRatio in brief

WebML [2] describes Web applications at three levels: thecontent objects, the front-end organisation and the look andfeel. Content objects are specified using a simplifiedentity-relationship (E-R)data model (or, equivalently, a sim-plified UML class diagram), comprising classes, entities,attributes, single inheritance, binary relationships and dataderivation expressions. Fig. 1 shows the data model of therunning case, with the objects mentioned in therequirements.

68

The front-end is specified using the hypertext model,which has a hierarchical organisation: each application cor-responds to a site view, internally structured into areas,which in turn may contain sub-areas and pages. Multiplesite views can be associated to the same data model, forexample to represent applications delivered to differentactors or designed for different access devices (web,digital television, mobile phones, PDAs). Site views, areasand pages are not only units of modularisation, but alsogovern access, which can be selectively granted to eachindividual module based on the user’s identity and subscrip-tion to groups. A first kind of navigation, which does notdepend on page content, can be expressed over site views,areas and pages: if a page or area is marked as ‘landmark’(L), it is assumed to be reachable (through suitable naviga-tion commands) from all the other areas and pages in thesame module; if a page or area is marked as ‘default’ (D),it is assumed to be displayed by default when the enclosingmodule is accessed; if a page is marked as ‘home’ (H), it isdisplayed by default when accessing the application. Fig. 2shows the hypertext model of the public site view of therunning case, with the areas and pages mentioned in therequirements, annotated with the navigation markers.Pages are the basic interface containers: they can be

structured in sub-pages and comprise content units. Acontent unit is defined as a component that publishessome content in a page; the published content can beextracted dynamically from the objects specified in thedata model or specified statically in the hypertext model(e.g. an entry form consisting of multiple input fields). Inaddition to content units, WebML comprises operationunits, defined as components for executing arbitrarybusiness logic. Operation units, unlike content units, donot publish content and thus are positioned outside pages.Components (content and operation units) may haveinput and output parameters (e.g. the OID attribute of theobject to display or to modify, the username and password

Fig. 1 Data model of the running case

Fig. 2 Hypertext model of the public site view

IET Softw., Vol. 1, No. 3, June 2007

for authenticating the user etc.). Parameter passing isexpressed as a side effect of navigation: components areconnected by links, which have a threefold purpose:enabling the user’s navigation, supporting the passage ofparameters and triggering the execution of components.Therefore a WebML hypertext can essentially be describedas a graph of parametric components, connected by links,in which some components publish content and are con-tained within pages, some other components performbusiness actions, and are triggered from links emanatingfrom pages. Links express the ‘wiring’ of the application.Five kinds of link are defined: normal links, denoted bysolid arrows, allow both navigation and parameterpassing; transport links, denoted by dashed arrows, allowonly parameter passing and are not rendered as navigationdevices; automatic links, denoted by the symbol [A], arenormal links automatically ‘navigated’ by the system onpage load; OK and KO links are output links of operations,respectively, followed after execution success or failure. InFig. 2, the home page contains two data-driven contentunits (for displaying the product and offer of the day)and one static content unit (an entry form); the entryform is connected to a login operation (placed outsidethe home page), for authenticating the employees beforeaccessing the protected content management site view.The outgoing link of the entry unit shows the parameterstransferred to the login operation units. Application devel-opment with WebML is supported by WebRatio, a toolenabling the editing of data and hypertext models and thegeneration of the application source code. WebRatio alsosupports all the technical development tasks: declaringthe data sources and Web services used in the project,forward and reverse engineering of the data model, presen-tation specification through page mockups, and code gener-ation and deployment for different platforms.

4 Metamodel for WebML

A metamodel is the ‘perfect’ way to model a dynamicallyevolving notation and maintain it in a homogeneous andcomprehensive way [5]. There are different metamodellinglanguages and notations, among which the combination ofMOF and the object constraint language (OCL) constitutesthe Object Management Group (OMG) proposal for speci-fying metamodels.Mapping a DSL like WebML to MOF involves represent-

ing each element of the domain – its syntax and semantics –as a MOF artefact and performing a refactoring process inorder to introduce further MOF-elements such as compo-sitions/aggregations or abstract classes, which preservethe original semantics while allowing a better grouping ofconcepts with similar attributes.This task is relatively simple when there is a formal

description of the language syntax and grammar (althoughthe MOF metamodel generated must be augmented withseveral OCL constraints to cover the semantical featuresand structural rules of the language). In the WebML case,a formal Backus-Naur Form (BNF) grammar is availableonly for its derivation language (WebML-Object QueryLanguage, OQL).A possible starting point for deriving the metamodel

could be the set of document type definition (DTDs)employed by the WebRatio development tool for storingWebML projects (see [8]), as done by other authors (cf.[9]). However, the WebRatio DTDs are low level becausethey comprise many auxiliary concepts, necessary to thetool but redundant with respect to the formal definition ofthe language. Therefore we decided to build the MOF


metamodel from scratch, starting from the definition ofthe basic concepts of the language. Such a metamodel isdescribed in the remainder of this section.

4.1 WebML metamodel structure

We have represented the WebML concept space by meansof four metamodel packages, as illustrated in Fig. 3:CommonElemets, DataView, HypertextView andPresentationView. Complying with a package requires tocomply with its abstract syntax, well-formed rules, seman-tics and notation.

† The CommonElements package comprises core conceptsused when metamodelling WebML elements, such as datatypes or common features (e.g. name, comment, identifier,properties etc.). The other packages have dependencies onthe CommonElements package because of association andgeneralisation relationships.† The DataView package addresses WebML data modelconcepts, such as entities, attributes, relationships, ISA hier-archies and so on, which are reused by the HypertextViewpackage.† The HypertextView package establishes the overallstructure of the WebML hypertexts, in terms of siteviews, areas, pages, content units and so on, and showshow these artefacts can be assembled and interconnectedto constitute a WebML hypertext model.† Finally, the PresentationView package is concerned withhow WebML represents pages on the screen. Each WebMLpage has associated one or more style sheets specifying adifferent way of presenting its instances on the screen,where style sheets are XML documents obeying theWebML presentation DTDs mentioned in [8].

In the next subsections, each package is described, and allthe entities, relations and constraints instantiated within theWebML models are progressively introduced.

4.2 CommonElements package

As shown in Fig. 4, the abstract ModelElement metaclass isthe central element of the abstraction. It represents anyWebML modelling element from both the data, hypertextand presentation models. Its abstract sub-metaclasses rep-resent the fact that any WebML element may have aname, an identifier, a comment, a property, a type or a deri-vation constraint associated to its definition.

WebML data types are represented by the Type meta-class. In this way, WebML enumeration types and their cor-responding values have been realised by metaclassesDomain and DomainElement, whereas WebML primitivetypes such as Integer or String have been meta-modelledby the WebMLType metaclass.

Fig. 3 WebML metamodel packages

69

4.3 DataView package

All WebML specifications contain a DataModel describingthe data structures used to represent the information(content) handled by the application. Content can be mod-elled using an E-R model (or, equivalently, a simplifiedUML class diagram) comprising DataModelElements suchas entities and relationships.

Entities are described by means of typed Attributes whereeach entity has at least one attribute namely the OID. Thetype of an Attribute may be either a WebMLType or aDomain defined by the user.

Entities can be organised in generalisation hierarchies,which express the derivation of a specific concept from amore general one. In particular, single inheritance and binaryrelationships are allowed in the DataModel. Each binaryrelationship is characterised by two RelationshipRoles thatcan be annotated with minimum and maximum cardinalityconstraints.

Finally, all DataModelElements must be distinguishableby means of a unique identifier (the OID). The MOFWebML metamodel defines this property using a singlespecial purpose metaclass, called IdentifiedElement.

Fig. 5 represents the E-R data schema metamodelledfrom the WebML viewpoint. We would like to point out

Fig. 5 DataView package

Fig. 4 CommonElements package

70

that although there are other proposals for metamodellingthe E-R model, they do not reflect precisely the usage ofthe data model in WebML and WebRatio. For example, ifwe metamodelled RelationshipRoles as meta-attributes ofthe Relationship metaclass, we would miss part of thesemantics of WebML.

4.4 HypertextView package

The HypertextView package is sub-structured into theCore, SiteView, ServiceView, AreaView, PageView,OperationUnitView, ContentUnitView, TransactionView,GLParameter, ParameterView and LinkView sub-packages(see Fig. 6). The former contains the basic core modellingelements for organising the hypertext structure of Webapplications. The latter depends on the Core package andit contains further sub-packages for exploiting specifichypertext elements.Because of space limitations, we provide only a brief over-

view of the HypertextView package (see Fig. 7). The inter-ested reader can download the complete MagicDrawmodel from [8].The SiteView metaclass of this package represents a

collection of SiteViewElements allowing users to performa set of activities. From the WebML viewpoint, aSiteViewElement can be a Page, an Area, anOperationUnit, a GLParameter or a Transaction.Pages comprise PageElements, an abstract metaclass

representing other Pages and ContentUnits. Each Page hasassociated a Choreography that describes the chain ofWebML operations or actions to be performed as a conse-quence of the invocation of the Units. This Choreographycan be both a predefined sequence represented in the meta-model by the ChoreographySequence metaclass and acustom sequence established by the designer and metamo-delled by the CustomLinkPropagation metaclass.Pages can be clustered into Areas, dealing with a homo-

geneous subject (e.g. the Amazon Web Store includes abook area, a music area etc.). Features related to howSiteViews, Areas and Pages can be reachable from otherSiteViews, Areas or Pages have been metamodelled asmetarelationships between the participant metaclasses.Units can be classified into two metaclasses: ContentUnits

and OperationUnits. The content displayed in a ContentUnittypically comes from an Entity of the DataModel, and can bedetermined by means of a Selector, which is a logicalCondition filtering the entity instances to be published.Instances selected for displaying can be sorted accordingto OrderingClauses. OperationUnits, unlike ContentUnits,do not publish content and may have input and output

Fig. 6 Package Structure of the Hypertext WebML Metamodel


Fig. 7 Excerpt of the HypertextView package

Parameters. The link parameter coupling defines the flowof parameters from the source unit to the destinationunit of the link, which output parameter of the sourceunit provides a value to which input parameter of thedestination unit.Units are connected to each other through Links. For each

kind of link (NonContextualLinks, Transport, Automatic,OK and KO) identified in Section 3 a MOF metaclass hasbeen declared inheriting from the Non-ContextualLinkand ContextualLink metaclasses, respectively. While theNonContextualLink metaclass captures the semantics andbehaviour of WebML links allowing only the navigation,the abstract ContextualLink metaclass represents thoseothers allowing also the parameter passing.WebML OperationUnits can be grouped into Transactions

describing sequences of operations that are executedatomically, as they were one unique big operation. In theWebML, this concept is represented by the Transaction meta-class, inside which the TransactionElements to be executedtransactionally can be placed.The context information needed to calculate units that is

not transferred point-to-point during navigation, but must be


available ‘globally’ to all the pages of a site is metamo-delled by the GlobalParameter metaclass. LocalParametersare similar to GlobalParameter, but are locally to a specificSiteViewElement.

Additionally, well-formed rules complete the semanticsof the metamodel and its elements. We show some ofthem but the interested reader can visit the WebMLsite [8] for a complete description of the metamodelconstraints.

– A page cannot be nested in a SiteView– and in an Area at the same time.context Page inv:self.isOclKind(AreaElement)xor self.isOclKind(SiteViewElement)

– Any page marked as ‘landmark’ must be– nested in a SiteView or in an Area.context Page inv :self.landmark implies

self.siteView- . notEmpty()or self.area- . notEmpty()

71

5 Representing WebML using a UML profile

Early attempts at encoding WebML in UML 1.X did notsucceed in producing a completely equivalent profile,because of the lack of appropriate structuring conceptsand mechanisms of UML, and the semantic gap betweenspecific Web application concepts and the UML constructs.

However, with the advent of UML 2.0 the situation haschanged, since not only its semantics have been definedmore precisely, but it also incorporates a whole new set ofdiagrams and concepts which are more appropriate for mod-elling the structure and behaviour of Web applications. Inaddition, UML 2.0 provides enhanced profiling capabilities,which allow the precise definition of MOF-based domain-specific languages.

The OMG offers three approaches for defining a DSL. Thefirst solution is to develop a metamodel, as we have done inthe previous section. This means creating a new domainlanguage alternative to UML, using the MOF metamodellingfacilities. In this way, the syntax and semantics of theelements of the new language are defined to faithfullymatch the domain’s specific characteristics. The problemwith metamodel definition is that standard UML tools arenot able to deal with the new language (e.g. to edit modelsthat conforms to the metamodel, compile them etc.). Thisapproach has been followed by languages such as CWM(common warehouse metamodel) and W2000, becausesome of their constructs do not match the semantics of thecorresponding UML model elements.

The second and third options provided by the OMG arebased on extending UML. Extensions of the UML can beeither heavyweight or lightweight. The difference betweenlightweight and heavyweight extensions comes from the wayin which they extend the UML metamodel. Heavyweightextensions are based on a modified UML metamodel withthe implication that the original semantics of modellingelements are changed and therefore the extension might nolonger be compatible with UML tools. Lightweight extensionsare called UMLprofiles and exploit the native extensionmech-anisms of UML (stereotypes, tag definitions and constraints)for specialising its metaclasses, without breaking their originalsemantics. UML profiles may impose new restrictions on theextended metaclasses, but they should respect the UML meta-model, without modifying the original semantics of the UMLelements (i.e. the basic features of UML classes, associations,properties etc. will remain the same, only new constraintscan be added to the original elements). Syntactic sugar canalso be defined in a profile, in terms of icons and symbols forthe newly defined elements. One of the major benefits of pro-files is that they can be handled in a natural way by UMLtools. In UML profiles, stereotypes define particularisationsof given UML elements, adding them some semantics.Perhaps the best known example of profileable UML-basedWeb modelling language is UWE [10].

In this section, we describe the UML profile for WebML.In building the profile, we have pursued two main goals:

1. To provide UML modellers with a UML profile that canhelp them structure their Web application specificationsaccording to a mature Web Engineering proposal. In thisway, UML modellers can reuse their knowledge of standardUML, exploit any tool that supports UML for editing thespecifications and export the application model toWebRatio for generating a complete implementation.2. To provide WebML modellers with a UML profile forexpressing their specifications in a standard way, decou-pling the abstract syntax and semantics of the modellingelement from its specific representation, hence allowingits use within any standard UML tool environment.

72

Table 1 shows the main elements of the profile forWebML that we are going to describe in the next subsections.

5.1 WebML data model in UML 2.0

As illustrated in Fig. 5, the data modelling is supported inWebML by means of the classical E-R model with general-isation hierarchies, typed attributes and cardinality con-straints. The essential elements of the E-R model areentities, defined as containers of structured data, andrelationships, representing semantic associations betweenentities. Since the semantic equivalence between the E-Rmodel and its corresponding in UML is very clear, wejustify the selection of UML metaclasses in those cases inwhich it may not seem so intuitive for the reader.

5.1.1 Entities: Following a UML-based approach, eachEntity of the WebML data model will be mapped to aUML class. In UML, classes are classifiers that have a setof features that characterise their instances. Consequently,each typed attribute of the entity will be considered as atyped structural feature, that is, one of its properties. Itsassociated type may correspond to a predefined WebMLtype or a specific type defined by the user. In this lastcase, we will consider that each WebML Domain representsa UML enumeration datatype where the set of possiblevalues are the UML literals of that datatype.

5.1.2 Relationships: Relationships are characterised bycardinality constraints, which impose restrictions on thenumber of relationship instances an object may take partin. WebML represents N-ary relationships as a combinationof entities and binary relationships. Consequently, allrelationships in the WebML data model are binary relation-ships characterised by two relationship roles, each oneexpressing the function that one of the participating entitiesplays in the relationship.At first sight we may consider that WebML Relationships

have the same semantics as UML associations given thatthey model connections between entities. However,because of to the role that relationships have on both theWebML data model and the hypertext model this wouldbe a poor solution (neither behavioural descriptions norattributes can be associated with a UML association).Alternatively, UML association classes could be used torepresent WebML Relationships, which does permit anappropriate semantic definition to be supplied. However,note the reader that WebML Relationships may be par-ameters of a unit, may have derivation constraints sub-setting and/or concatenating existing relationships, theirinstances can be created, modified or deleted as a conse-quence of user interactions and so on. Therefore defininga �Relationship� stereotype for a Class can make theuse of WebML Relationships easier.

5.1.3 Derivation constraints: The value of some of theattributes or relationships of a WebML entity can be deter-mined from the value of some other elements of the schema.The computation rule that defines the derived attribute orrelationship is specified as an expression added to thedeclaration of the attribute or relationship. UML 2.0 deri-vation mechanisms for attributes and associations can beused to naturally represent WebML derivations.Applying these correspondences to our running example,

Fig. 8 shows a WebML data model for the Acme applicationand its corresponding representation in UML using ourUML profile.


Table 1: Subset of the UML Profile for WebML

WebML Concept UML Base Element Stereotype

DataModel Model �DataModel�

Domain Enumeration �Domain�

DomainElement EnumerationLiteral �DomainElement�

Entity Class �Entity�

Attribute Property �Attribute�

Relationship Class �Relationship�

RelationRole Property �RelationRole�

HypertextModel Model �HypertextModel�

SiteView Package �SiteView�

ServiceView Component �ServiceView�

Port Port None

GlobalParameter Class �GlobalParameter�

Area Package �Area�

Page StructuredClasiffier �Page�

HomePage StructuredClasiffier �HomePage�

Default Package, Component, Struct.Clasiffier �Default�

Landmark Package, Component, Struct.Clasiffier �Landmark�

Secure Package, Component, Struct.Clasiffier �Secure�

Localized Package, Component, Struct.Clasiffier �Localized�

Protected Package, Component, Struct.Clasiffier �Protected�

DataUnit Component �DataUnit�

MultiDataUnit Component �MultiDataUnit�

IndexUnit Component � IndexUnit�

MultiChoiceIndexUnit Component �MultiChoiceIndexUnit�

HierarchicalUnit Component �HierarchicalUnit�

Level Class, Association �Level�

EntryUnit Component �EntryUnit�

CustomContentUnit Component �CustomContentUnit�

ValidationRule Constraint �ValidationRule�

CreateUnit Component �CreateUnit�

DeleteUnit Component �DeleteUnit�

ModifyUnit Component �ModifyUnit�

ConnectUnit Component �ConnectUnit�

DisconnectUnit Component �DisconnectUnit�

LoginUnit Component �LoginUnit�

LogoutUnit Component �LogoutUnit�

ChangeGroupUnit Component �ChangeGroupUnit�

SendEmailUnit Component �SendEmailUnit�

AdapterUnit Component �AdapterUnit�

SetUnit Component �SetUnit�

OKLink Connector �OKLink�

KOLink Connector �KOLink�

AutomaticLink Connector, Association �AutomaticNavigation�

TransportLink Connector, Association �Transport�

LinkParameterCoupling Port �LinkParCoupling�

Parameter Port �UnitParameter�

Condition Constraint �Condition�

SelectorCondition Constraint �SelectorCondition�

Property Property �WebMLProperty�

5.2 WebML hypertext model in UML 2.0

The profile must express three essential aspects of the theWebML hypertext model: the modularisation structure ofsite views, the specification of components (content and


operation units) and the interconnection of componentsthrough links supporting parameter passing. For data-centric content and operation units, it is also important toexpress how a component draws or updates the content ofthe data model objects.

73

5.2.1 Modularisation: WebML groups hypertext modelelements into site views and areas. The grouping function-ality for better understanding and management of modelsis supported in UML by means of packages. Therefore wewill represent WebML site views and areas as UMLpackages. At a second level of modularisation, pages arealso containers of sub-pages or of units that can involvemultiple individual operations. WebML suggests that thedefault behaviour of a Web page can be defined only onceand reused in the rest of the projects using it.

Moving WebML page requirements to a UML approach,we can consider it as an autonomous unit that is replaceablewithin its environment and which functionality is providedand/or required by means of the combination of providedand/or required funtionalities of the content unitsnested inside the page. In this case, we find that thisconcept corresponds to the UML concept of component.However, this is not exactly what represents a page inWebML. Pages in WebML act not only as containers ofunits but also they represent a composition of intercon-nected WebML elements, whose instances collaborate atrun-time to achieve some common objective. Thereforethis semantics fits much better with UML structuredclasses. Consequently, pages are more appropriately rep-resented as structured classes, comprising the contentunits nested inside them.

5.2.2 Visibility level: Some properties of site views, areasand pages, such as home, default and landmark properties,allow the designer to fine-tune the visibility level of theseconstructs inside the hierarchical structure of a site view.Other properties, such as secure, protected or localized,provide information required for code generation. UMLstereotypes have been defined to ‘mark’ the appropriatemodel elements with such properties, allowing the annota-tion of the corresponding models with these characteristics.Alternatively, we could have considered to represent pre-vious properties as tag definitions of their correspondingstereotypes. From our viewpoint, the approach selectedimproves its practical application adding more visualclarity to UML4WebML models as WebML does bymeans of the (L), (H) and (D) marks.

Fig. 8 UML 2.0 data model of the Acme application

74

5.2.3 Content and operation units: Content and oper-ation units are components that can be assembled togetherto obtain arbitrary complex hypertext pages. Their essenceis the capability of executing business actions and interope-rate through the exchange of parameters. This notion ismost closely reflected by the concept of UML 2.0 com-ponent. As shown in Table 1, specific stereotypes havebeen defined for each type of content and units supportedby WebML taking as base UML element the componentnotion.As a UML component, WebML units may optionally

have an internal structure and own a set of ports that formal-ise their interaction points. Ports can formalise the input andoutput of a unit: one port allows the environment of thecomponent to supply parameter values; another portallows the the environment of the component to extract par-ameter values.

5.2.4 Links and parameter passing: Pages and units donot stand alone, but are linked to form a hypertext structure.Links express the possibility of navigating from one point toanother in the hypertext, and allow the passage of par-ameters from one unit to another. Several alternativeshave been considering for representing this WebMLfeature in UML. Links can be visualised as basic UMLassociations, dependency relationships, traces, usagerelationships and so on. Although they can all be labelledwith suitable stereotypes such as �TransportLink� ,�NavigationLink� or �KOLink� to denote theclasses of links, a more precise semantic definition can beprovided by the use of UML assembly connectors. Anassembly connector is a UML connector between two com-ponents that defines how one component provides the ser-vices that another component requires. It is defined from aprovided port (i.e. an output WebML parameter) to arequired port (i.e. an input WebML parameter) of theunits involved.

5.2.5 Realisation of data-centric units: Content andoperation units may operate on objects specified in thedata model. This is represented by specifying the internalrealisation structure of components, which may exploitauxiliary classes to represent a view over the data modelentities. At least, for each content unit there will be twoauxiliary classes: one class stereotyped as � focus�that defines core logic or control behaviour of the unit andanother class that selects content from the datamodel.Appropriate OCL invariants in the auxiliary classes rep-

resent the selector condition determining the instancesupon which they operate, and UML delegation connectorslink the input and output ports of the component to theauxiliary classes, granting parameters flow.

5.2.6 Global and local parameters: WebML par-ameters denote small pieces of information, which can be‘recorded’ during the user navigation, to be later retrievedand exploited in the computation of the content of somepage. A parameter will be represented as a singletonUML class that contains: a public class-scope (static) prop-erty, a class constructor declared as private so that no otherobject can create a new instance and finally a class methodthat returns a reference to the single instance of the class.The above-mentioned mappings are pictorially illustrated

in Fig. 9, which represents the UML specification equival-ent to the WebML page of Fig. 10.The StorePage, represented as a classifier, contains an

index unit component and a data unit component, linked byan assembly connector with the �AutomaticLink�


Fig. 9 UML 2.0 representation equivalent to the page of Fig. 10

stereotype. The internal structure of the index unit is realisedby a focus class, comprising methods for sorting the indexinstances and for selecting one instance. The focus class isconnected by a one-to-many part of association to classStoreView1, which represents a view over the data modelentity Store. Instances of class StoreView1 contain theaddress attribute, necessary to build the index and thehidden attribute OID, necessary for parameter passing. A del-egation connector links the output port of the focus class tothe outport port of the component, and specifies that theoutput value of the select( ) method is emitted by the indexunit component’s output port. The parameter associatedwith the �AutomaticLink� connector is received at theinput port of the data unit component, which delegates itstreatment to an inner focus class. The focus class containson instance of class StoreView2, which represents anotherview over the data model entity Store. An OCL invariant inthe focus class enforces the contained instance of classStoreView2 to have the value of the OID attribute equal tothe parameter value received at the input port.As a conclusive example, Fig. 11 overviews the UML 2.0

representation of the public site view of the running caseexpressed with the WebML profile; this should be comparedto the native WebML representation of Fig. 2.

6 Comparison of the WebML and UMLrepresentations

This section compares the WebML representation in UMLagainst its native encoding. We first compare in Section6.1 how compact the two representations are, using therunning application as an example. Then, Section 6.2

Fig. 10 Page with an index unit for selecting a store and a dataunit for displaying its details (left). Same page with abbreviatednotation (right)


reviews the main design choices taken in the definition ofthe WebML model and tool. Finally, Section 6.3 discusseshow these design principles have been impacted by theuse of UML for encoding WebML, and summarises someof the lessons learnt.

6.1 Compactness and complexity comparison

The proposed encoding of WebML as a UML 2.0 profile hasbeen validated and used to compare the complexity of thetwo approaches.

Validation was performed by implementing an ExtensibleStylesheet Language Transformation (XSLT) translator fromthe XMI representation [Note: In the experiment, we used theXMI output of MagicDraw version 10.5.] of the modelencoded in the UML profile into the native WebML format(which has its own XML Schema) and then: (1) verifyingthe correctness of the synthesised WebML specifications bymeans of the model checker of WebRatio; (2) generatingthe Java2EE code of the application from the the synthesisedWebML specifications and comparing the obtained codewiththe one produced by using native WebML. Both assessmentsproved the equivalence of the UML 2.0 profile and the nativeWebML representation.

Next, the complexity of the UML representation wascompared to that of native WebML, with respect to multipledimensions. Table 2 shows the result of the comparison.[Note: The editing time has been estimated by assigningfixed time in seconds to the base editing actions: insertionof a node, arc and editing of a property.]

6.2 Design of WebML

The original principles adopted in the design of WebML putspecial emphasis on three aspects, which were consideredprominent for achieving developers’ acceptance: (1) expres-sive power: the model should be capable of expressingWeb applications comparable in complexity to industrial-strength systems developed manually; (2) ease of use: themodel should be easy-to-learn for developers not skilledin software engineering; (3) implementability: the modelshould encompass enough information to permit the gener-ation of code for all the tiers of a dynamic Web application.Code generation should produce optimised code as far as

75

Fig. 11 Hypertext model represented with the WebML UML profile

possible. In the following paragraphs, we comment on theessential choices taken in the design of the language.

6.2.1 Model boundaries: The approach to define modelboundaries has been rather crude: the model contains theminimal number of concepts necessary to generate code.This led to the partition of the concepts into the three per-spectives of the data model, hypertext model and presen-tation; the latter perspective gathers all those aspects thathave to do with aesthetics and interface usability and isnot expressed diagrammatically, but by means of annotatedexamples.

A notable feature of WebML is the absence of a separatesub-model for the business logic. Server-side business logicis partly encoded in the data model (in the form of declara-tive specifications of derived data) and partly in the hyper-text model (in the form of black-box content and operationunits, which can represent components with arbitrary func-tionality. This choice simplified dramatically the model, tothe price of two (not necessarily negative) unforeseenphenomena: (1) the proliferation of custom units for encod-ing non-standard server-side business logic; (2) the com-plexity growth of the presentation model, which was usedto capture, beside aesthetics, also client-side behaviour(e.g. JavaScript event handling), not expressible otherwise.

This restriction of the model boundaries reduced themodel concepts necessary for building real-world dynamicweb sites. For instance, the initial version of the

76

Acer-Euro web applications was specified and automati-cally built using only simplified E-R diagrams and 14WebML units (six content units: index, data, multidata,scroller, entry, get; and eight operation units: create,delete, modify, connect, disconnect, set, login, logout).Clearly, not all applications can be represented by the orig-inal WebML components; in time, a wealth of ad hoc com-ponents has been developed to manage further requirements(messaging, web service interaction, sophisticated inputetc.), but they have been treated as black-box plug-ins tothe three existing sub-models, rather than constituents ofan independent modelling layer. As a further simplification,

Table 2: Comparison of the running casemodel in nativeWebML and in the UML WebML profile

Parameter Native

WebML

UML 2.0

WebML Profile

number of modelling concepts 10 9

number of instances of the

modelling concepts

23 90

number of constraints on model

elements

6 10

size of XML file of the model 22 kbytes 505 kbytes

estimated editing time 345 s 1350 s


no explicit architectural model is provided. Physicalresources (data sources, application servers, web services,identity repositories etc.) are not modelled diagrammati-cally, but simply declared as project resources in thedevelopment tool, and referred to by the model conceptsthat use them.Another essential aspect of model definition is the

compact representation and efficient management of inter-model references, which are ubiquitous: the hypertextdiagram references the data model (e.g. for data extractionand update), and the presentation refers to the hypertextmodel (e.g. for content positioning in pages). Fig. 10shows a reference from the hypertext model to the datamodel: the AllStores index unit and the StoreDetails dataunit refer to entity Store, which provides the components’content. The reference to the data model element issimply realised by means of a typed property in the hyper-text model.

6.2.2 Level of abstraction: A WebML specification isfar more abstract than an object-oriented representation ofthe generated code. A model concept is normally mappedonto multiple software arteifacts, possibly residing at differ-ent tiers. For example, a WebML page, its unit and links areindeed a compact representation of multiple arteifacts: (1)the data extraction code in the data tier (stored procedures,queries, Enterprise JavaBeans (EJB) finder methods etc.);(2) the object(s) storing the content in the business and/orpresentation tier (entity EJB, javabeans); (3) the actionclass decoupling the request from the business tierobjects; (4) the business service orchestrating the compu-tation of the page content; (5) the JavaServer Pages (JSP)executable tags translating object content into page markup.The decision of keeping a high level of abstraction traded

realism for compactness. To the developer’s eye theWebML model of a page mixes things that in realitystand apart. However, if the ultimate purpose of modellingis to generate the code, the ease of building up a completemodel should prevail on the realism of the representation,provided that the meaning of each abstract concept isknown and the behaviour of element composition predict-able. Considering that a small-size project may typicallyconsist of tens of pages comprising hundreds of com-ponents, it is easy to see that raising the level of abstraction,while preserving semantics, is crucial to achieve practicalusability.

6.2.3 Behavioural semantics: A non-obvious aspect ofmodel design, which distinguishes WebML from traditionalOO modelling, is the absence of a separate behaviouralmodel. Behavioural aspects are embedded in the hypertextmodel, which has a fixed operational semantics thatapplies to all WebML applications, and therefore need notbe specified explicitly by the designer. In essence, a hyper-text model is represented by an extended finite statemachine [11], in which events capture user’s interactionsand system generated events, and transitions describe thepropagation of computation from one component toanother one. Conditions on transitions express the flow ofcontrol, for example the order in which components mustbe executed depending on the availability of user’s inputor of system-provided parameters. The provision of a stan-dard, application-independent operational semantics is acornerstone of the design of WebML: the ‘in the large’semantics describes the general functioning of the Webapplication as a network of cooperating components; the‘in the small’ semantics describes how individual com-ponents work. The former is standardised and developers


need not address it; the latter is treated as a plug-in to themodel: developers are requested to understand how the pre-defined WebML components work and define their owncomponents by respecting a few basic rules requested bythe ‘in the large’ semantics (essentially, each componentshould declare its input and output parameters and optionaldefault rules). This approach proved quite effective. Thecases in which the default ‘in the large’ semantics provedinadequate for capturing application requirements are verylimited (we estimate less 1% of the cases) and we copedwith these situations in the design tool, where the developerthat understand the computation semantics can alter thecomponents’ execution sequence. Another lesson welearned is that standardising the model semantics does notreduce the expressive power. The range of implementedapplications demonstrates this claim; developers werealways able to partition requirements into what can beachieved using standard components and behaviour andwhat requires the construction of ad hoc components.This approach resembles the notion of framework at thecoding level, raised to a more abstract level.

6.2.4 Ergonomics: The success of a model-drivenmethod is tightly connected with its practical usability. Ifediting the model is more cumbersome than implementingfunctionality in the code, developers will hardly switch tomodel-driven development (MDD). The evolution ofWebML is characterised by innumerable revisions aimedat optimising the performance of modelling, whosecommon principle is ‘everything that can be reasonablyinferred from the context must not be specified explicitly’.

A notable example occurs with parametric componentsand parameter passing along links. Such a feature is thebackbone of hypertext modelling and occurs repeatedly inany application model. To alleviate the developer’s task,WebML provides default rules whereby 80% of parameterpassing is inferred from the context. The notation on theright part of Fig. 10 exemplifies this idea. The AllStoresindex unit has a single output parameter (X) of type(Store), the entity underlying the component; theStoreDetails data unit has a parametric selection condition(i.e. a query) determining the object to display([OID=X]), which makes use of the parameter associatedwith the input link: in this way, the data unit showsexactly the object chosen in the index unit. By inference,the model in the left-hand side of Fig. 10 is equivalent tothat in the right-hand side of Fig. 10, in which the para-metric selection condition and the parameter passing onthe link are omitted. This simple default rule spares twoediting actions per link, which results into a substantialreduction of the model editing effort.

6.2.5 Openness: The last far-reaching design choice con-cerned the evolution of the model. Being a DSL, WebMLwas initially conceived as a closed language, comprisingall the primitives deemed necessary for building Web appli-cations. This choice soon proved ineffective: the extensionof application functionality constantly demanded for languagerevisions. A major breakthrough was achieved with the defi-nition of a standard model extensionmechanism, which trans-formedWebML into an open component-assembly language.The semantics was revised so that developers could definetheir own components, by wrapping any existing piece ofsoftware, and mix them freely with the built-in WebMLunits. This required a simple standardisation of the componentexternal behaviour to make it comply to the (very minimal)requirements of the standard component orchestration seman-tics; each content and operation unit must simply declare its

77

input and output interfaces, and the rules for inferring par-ameter passing and content selection conditions. After suchrevision, the standard component orchestration semantics,coupled to libraries of domain-specific components, provedadequate to the modelling and automatic implementation ofapplications in the most disparate domains: mobile, digitaltelevision, Web service interaction, workflow managementand so on.

6.3 Lessons learned on UML as a Web modellinglanguage

The definition of an UML 2.0 profile equivalent to WebMLdemonstrates practically the suitability of UML for encod-ing the requirements and generating the complete code ofcomplex real-world Web applications. However, severalissues were encountered in representing WebML withUML 2.0, both of general nature and specific to the encod-ing of WebML.

6.3.1 Expressive power: The UML profile for WebMLprovides the same expressiveness as the native represen-tation: all WebML concepts were mapped into the corre-sponding UML (stereotyped) elements and the resultingUML profile proved sufficient to describe complete Webapplications that could be successfully processed by theWebRatio model checking and code generation engine.This result, which was not achieved in the previous attemptsat encoding WebML in UML 1.X, has been granted by thenew features of UML 2.0. For example, ports and connec-tors as defined in UML 2.0 have provided the necessaryexpressive power to represent the interconnection of com-ponents and the associated flow of parameters, which isessential to hypertext specification. Furthermore, OCLinvariants, involving ports, realisation and view classes,can express the semantics of data-centric Web componentsin quite a natural and compact way. The notion of connec-tor, although criticised elsewhere [12] for its lack of beha-vioural semantics, proved sufficient for expressing thelinking of Web components, where parameters are simplytransferred from one component to the other.

6.3.2 Complexity: Only a limited number of UML con-cepts proved necessary to model and implement aWebML application. UML seems to contain far more con-cepts and mechanisms than needed for Web modelling.The main advantage of the UML profiling mechanism hasnot been found in the extension of the UML metamodel(which is already too large and complex to be used infull), but in the possibility of ‘restricting’ the set of UMLelements that are relevant to a given domain, tailoringtheir semantics so as to capture the behaviour and well-formedness rules of the domain-specific concepts they rep-resent. In this respect, the complexity of UML is greatlyalleviated by the use of a well-designed profile.

6.3.3 Required skills: Using UML properly requires deepknowledge of specialised concepts (e.g. ports, connectors,structured classes, collaborations etc.). These concepts aremostly alien to the Web engineer, who thinks in terms ofWeb-specific entities (Web pages, links, forms etc.). Theuse of stereotypes, possibly represented with icons thatexploit visual objects familiar to the domain expert,lowers the skill-level necessary to make practical use ofUML in implementing Web applications, because it helpsbridging the gap between the domain concepts and theUML constructs and mechanisms.

78

6.3.4 Behaviour modelling: Representing behaviour inUML, and generally in MDD, is much more complex thanrepresenting structure. UML structural diagrams have aclear semantics and can easily be customised to fit mostdomains. At present, UML dynamic models (collaboration,sequence and activity) are more frequently used as a docu-mentation for the human reader than as a specificationusable for code generation. Other models (statecharts) aremore formal and naturally suited for code generation, butare hard to master for practitioners.There is a current lack of a concrete syntax for actions in

UML, which hinders the specification of executable code.The progress of tools in the field of executable UML andaction semantics [13] may change this situation, by allow-ing the direct execution or compilation into code of arbitra-rily sophisticated behavioural models. This approach, whichdemonstrated effective in such application domains likereal-time embedded systems, is still be proven in the Webdomain, where the interplay of dynamic behaviour withuser interfaces and business logics is more intricate.In this sense, the approach taken by WebML of not repre-

senting explicitly the behaviour of their elements (as dis-cussed in Section 6.2) has proved its benefits, exploitingthe domain-specific meaning of business componentswithout loss of expressive power. For instance, all the data-centric content and operation units have a well-definedbehaviour: they are just the basic CRUD (content read,update, delete) operations familiar to any data designer,and thus it would make no sense representing their beha-viour in a high-level diagram; their transformation intoplatform-dependent code can easily be delegated to a tool.The same is true for user-defined components: their seman-tics is known to the developer and need not be expressedwhen specifying their usage in a hypertext model. Theycan be modeled and coded elsewhere and treated as aplug-in in the Web design model.

6.3.5 Usability: WebML native representation is far morecompact than its UML counterpart (see Section 6.1). This isobviously unavoidable, when comparing a general purposelanguage such as UML and a DSL that has been refinedfor years in search of compactness and notationaleconomy. However, the disproportion shows that there isample room for making UML more concise. One of theareas of possible improvement is in the cross-referencesbetween models. One aspect in which UML 2.0 provedrather cumbersome is the specification of the internal realis-ation of set-oriented content units (e.g. index units). Here,three classes (the component realisation class, its focusclass and a data view class) were necessary to express thetrivial concept of ‘select-project’ view (a subset of theobjects of a class, possibly with a restricted set of attributes).Clever mechanisms for abbreviating the expression of viewrelationships between classifiers in different models coulddramatically reduce the complexity of diagrams. Anotherarea where usage proves rather cumbersome in the specifica-tion of parametric conditions, a fundamental issue incomponent-based applications. Suitable abbreviations anda better scope mechanism for OCL variables within struc-tured classifiers could greatly simplify the task.

7 Related work

Several authors in the Web Engineering community haveexploited metamodelling and UML extensions in definingtheir DSLs and Web models [4–7, 9, 14]. The pioneeringwork of Conallen [4] uses, in conjunction with the standard


UML diagrams, the Web application extensions (WAE),which comprise the typical Web arteifacts (server pages,client pages, forms, frames, etc.). The main advantage ofWAE proposal is that its simplicity allows an efficientreflect the design artefacts of a Web Interface, as well asto drive the implementation of such interface. On theother hand, this same simplicity evidences a lack ofelements for modelling navigation and representing tech-nology and device independent requirements. Basically,WAE is a too low-level proposal for capturing the complex-ity a high level of abstraction of the navigation and presen-tation viewpoints.In order to solve these limitations, Goomez and Cachero

proposed in [7] a set of new views that extended UML dia-grams to provide a Web interface model. Built up departingfrom a UML-compliant use-case and a business classdiagram, the navigation and presentation models aredescribed using a mix of UML and proprietary primitives,not compatible with current UML tools.Also similar in goals to our work, Koch [6] and Baresi [5]

independently define a conservative extension of the UML1.4 metamodel, aimed at allowing the easy definition of pro-files. The shortcomings of using UML 1.4 make it difficultto use the resulting profiles for modelling complex distrib-uted Web systems. However, these works show that‘although alternative Web models use different notations,they could be based on a common metamodel, whichcould help the unification of modelling constructs andallow easier comparison and integration’ [6].UML 1.4 has been criticised also for its scarce support to

represent architectural styles. In the Web domain, architec-ture specification is elaborated in [14], where a UML 2.0profile based on the new composite structure model isexploited to specify the architecture of Web applications.As in our work, [14] uses UML components and connectorsfor Web modelling. However, the authors exploit these con-structors to express the architectural view of the system,which adds up to the functional view embodied in the struc-ture and navigation diagrams. The result is a proliferation ofmodels and stereotypes, which can be difficult to integrateinto a well-structured code generation process.Generally, both the definition of metamodels and UML

profiles are very laborious tasks made by hand by anexpert on the corresponding DSL. There are not manyworks that address the automatic generation of metamodelsor profiles from DSLs descriptions. In this regard, we findvery interesting the proposal of [9] which present a semiau-tomatic approach that allows to generate MOF-based meta-models from DTDs. Also very interesting results can befound in [15]. The author addresses the validation of thesemantics equivalence between UML profiles and the orig-inal DSLs from which they arise (e.g. by means of rules for-malising the correspondences between the mapped models).Bezivin described a tool that can bridge an UML profile andan equivalent DSL, whereby it is possible to produce auto-matically the UML profile from the DSL, and vice versa.Such tool could automatically convert WebML modelsinto their corresponding UML diagrams, following themapping rules described.

8 Conclusion and future work

We have presented both a metamodel and a UML profile forWebML, with the aim of integrating WebML into the MDAapproach – hence allowing UML modellers to make use ofa Web Engineering mature proposal for designing anddeveloping Web applications, and also allowing WebML


modellers to use their notation and tool (WebRatio)within a UML modelling environment.

This work clearly shows that UML 2.0 has the potentialto be used for industrial-strength Web development,especially if some simplifications on model cross-referencesand declarative semantics specifications are introduced. Thestandardisation of Web development platforms and technol-ogies, rather than making MDD/MDA less attractive [16],multiplies its potential, making the long-envisioned benefitsof software engineering more concretely attainable. Thedefinition of an UML profile alleviates the issues ofmodel complexity, required skills and semantics, becausea profile helps tailoring the subset of UML used to modela specific application domain, makes UML elements andmodels closer to the language of the domain expert, andhelps customising the ‘loose’ semantics of UML to betterfit the meaning of domain concepts.

Our future work will concentrate on completing the UMLprofile of WebML with presentation and architecturefeatures, and complementing the code generation processcurrently implemented by WebRatio with a novel approachcloser to the declarative model-transformation paradigmadvocated by MDA. In this way, it will be possible to elim-inate any dependency between the WebML models and thefinal implementation technologies (currently Java 2Enterprise Edition), and realisemore flexible code generatorscapable of exploiting a declarative specification of the targetarchitecture. In addition, the WebML metamodel will allowus to perform formal reasoning and transformations onWebML models for solving a broader classes of problems,related to other phases of the development process, forexample, the estimation of the size and cost of a projectfrom its conceptual model and the derivation of optimaltest sets directly from the model of a Web application.

9 Acknowledgments

The authors would like to thank the anonymous referees fortheir thorough comments and suggestions that have helpedus improve the paper. This work has been partialy supportedby Spanish Research Project TIN2005-09405-02-01 and theItalian grant FAR N. 4412/ICT.

10 References

1 Object Management Group ‘UML 2.0 Superstructure Specification’,2005, http://www.omg.org/cgi-bin/apps/doc?formal/05-07-04.pdf

2 Ceri, S., Fraternali, P., Brambilla, M., Bongio, A., Comai, S., andMatera, M.: ‘Designing data-intensive web applications’ (MorganKaufmann, 2002)

3 Garrigos, I., Gomez, J., and Cachero, C.: ‘Modelling dynamicpersonalization in web applications’. Proc. Int. Conf. on WebEngineering, Oviedo, Spain, July 2003, pp. 472–475

4 Conallen, J.: ‘Building web applications with UML’ (AddisonWesley, 2002, 2nd edn.)

5 Baresi, L., Garzotto, F., andMaritati,M.: ‘W2000 as aMOFMetamodel’.Proc. 6thWorldMulti-Conf. on Systemics, Cybernetics and Informatics -Web Engineering Track, Orlando, USA, July 2002

6 Kraus, A., and Koch, N.: ‘A metamodel for UWE’. PhD thesis,Ludwig-Maximilians-Universitat Munchen, January 2003.

7 Gomez, J., and Cachero, C.: ‘Information modeling for internetapplications’, ‘Chapter OO-H method: extending UML to modelweb Interfaces’ (Idea Group Publishing, Hershey, PA, USA, 2003),pp. 144–173

8 WebML resources. ‘The WebML Metamodel’, 2006, http://www.webml.org/webml/page5.do

9 Schauerhuber, A., Wimmer, M., and Kapsammer, E.: ‘Bridgingexisting web modeling languages to model-driven engineering:a metamodel for WebML’. Proc. of Model Driven WebEngineering, Palo Alto, CA, July 2006

10 Koch, N., and Kraus, A.: ‘Towards a common metamodel for thedevelopment of Web applications’. Proc. Int. Conf. on WebEngineering, Oviedo, Spain, July 2003, pp. 495–506

79

11 Brambilla, M., Comai, S., and Fraternali, P.: ‘Hypertext semantics forWeb applications’. Proc. Sistemi Evoluti per Basi di Dati, Isolad’Elba, Italy, January 2002, pp. 73–86

12 Ivers, J., Clements, P., Garlan, D., Nord, R., Schmerl, B., and OviedoSilva, J.R.: ‘Documenting component and connector views with UML2.0’, Technical Report CMU/SEI-2004-TR-008, Carnegie MellonUniversity, 2004

13 Mellor, S.J., and Balcer, M.J.: ‘Executable UML: a foundation formodel driven architecture’ (Addison Wesley, 2002)

80

14 Melia, S., Gomez, J., and Koch, N.: ‘Improving Web design methodswith architecture modeling’. Proc. Electronic Commerce and WebTechnologies, Copenhagen, Denmark, August 2005, pp. 53–64

15 Abouzahra, A., Bezivin, J., Del Fabro, M., and Jouault, F.: ‘A practicalapproach to bridging domain specific languages with UML profiles’.Proc. Best Practices for Model Driven Software Development atOOPSLA’05, San Diego, CA, October 2005

16 Haywood, D.: ‘MDA in a Nutshell’, 2004. http://www.theserverside.com/articles/article.tss?l=MDAHay-wood


Documents

WebML modelling in UML - UMA