cms-ml user's guide

7/31/2019 CMS-ML User's Guide

1/82

UNIVERSIDADE TECNICA DE LISBOA

INSTITUTO SUPERIOR TECNICO

CMS-ML:

CMS Modeling Language

Users Guide

Document produced by

PhD Student: Joao de Sousa Saraiva ([email protected]) (author)PhD Supervisor: Alberto Silva ([email protected])

April 2010


2/82

Contents

1 Introduction 1

1.1 Conventions Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 CMS-ML Elements 3

2.1 WebSite Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Structure View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.2 Roles View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.3 Permissions View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.1 Roles View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2.2 Tasks View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.3 Domain View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2.4 States View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.2.5 WebComponents View . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.2.6 Side Effects View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2.2.7 Interaction Access View . . . . . . . . . . . . . . . . . . . . . . . . 52

2.2.8 Interaction Triggers View . . . . . . . . . . . . . . . . . . . . . . . 55

2.3 WebSite Annotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

2.4 Additional Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

2.4.1 Additional Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

2.4.2 Importing Toolkits . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

2.4.3 Using Toolkit Elements In Other Toolkits . . . . . . . . . . . . . . 63

2.4.4 Using Toolkit Elements In WebSite Templates . . . . . . . . . . . . 64

3 Examples 66

3.1 Personal WebSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.2 Document Management Toolkit . . . . . . . . . . . . . . . . . . . . . . . . 70

4 Conclusion 77

i


3/82

List of Figures

1.1 The roles and artifacts considered by CMS-ML. . . . . . . . . . . . . . . . 2

2.1 The relationship between CMS-ML models. . . . . . . . . . . . . . . . . . 3

2.2 Metalevels considered by CMS-ML. . . . . . . . . . . . . . . . . . . . . . . 52.3 The views involved in the definition of a WebSite Template. . . . . . . . . 6

2.4 Abstract syntax for the WebSite Templates Structure view. . . . . . . . . 7

2.5 Concrete syntax for WebSite. . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.6 Concrete syntax for Dynamic WebPages in the Macro Structure View. . . . 8

2.7 Concrete syntax for Dynamic WebPage Child. . . . . . . . . . . . . . . . . 9

2.8 Concrete syntax for Dynamic WebPage Template. . . . . . . . . . . . . . . 9

2.9 Concrete syntax for Dynamic WebPage Containers. . . . . . . . . . . . . . 11

2.10 Concrete syntax for WebComponents. . . . . . . . . . . . . . . . . . . . . . 122.11 Concrete syntax for Dynamic WebPages. . . . . . . . . . . . . . . . . . . . 13

2.12 Abstract syntax for the WebSite Templates Roles view. . . . . . . . . . . . 13

2.13 Concrete syntax for Template Role. . . . . . . . . . . . . . . . . . . . . . . 14

2.14 Concrete syntax for Role Delegation. . . . . . . . . . . . . . . . . . . . . . 15

2.15 Abstract syntax for the WebSite Templates Permissions view. . . . . . . . 15

2.16 Concrete syntax for graphical representation of Dynamic WebPage Permis-

sion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.17 Concrete syntax for graphical representation of WebComponent Permission. 17

2.18 Concrete syntax for matrix representation of Dynamic WebPage Permis-

sions and WebComponent Permissions. . . . . . . . . . . . . . . . . . . . . 19

2.19 The views involved in the definition of a Toolkit. . . . . . . . . . . . . . . . 20

2.20 Abstract syntax for the Toolkits Roles view. . . . . . . . . . . . . . . . . . 20

2.21 Concrete syntax for Toolkit Role. . . . . . . . . . . . . . . . . . . . . . . . 21

2.22 Concrete syntax for Role Specialization. . . . . . . . . . . . . . . . . . . . 21

2.23 Abstract syntax for the Toolkits Tasks view. . . . . . . . . . . . . . . . . . 22

2.24 Concrete syntax for Task. . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.25 Concrete syntax for Task Participation. . . . . . . . . . . . . . . . . . . . . 23

ii


4/82

LIST OF FIGURES

2.26 Concrete syntax for the various kinds of Action. . . . . . . . . . . . . . . . 26

2.27 Concrete syntax for a Task with some Actions. . . . . . . . . . . . . . . . . 27

2.28 Abstract syntax for the Toolkits Domain view. . . . . . . . . . . . . . . . 28

2.29 Concrete syntax syntax for Entity (with no Attributes). . . . . . . . . . . . 282.30 Concrete syntax for Entity with a set of Attributes. . . . . . . . . . . . . . 31

2.31 Concrete syntax for Association. . . . . . . . . . . . . . . . . . . . . . . . . 32

2.32 Example of valid and invalid Association. . . . . . . . . . . . . . . . . . . . 33

2.33 Concrete syntax for Specialization. . . . . . . . . . . . . . . . . . . . . . . 34

2.34 Abstract syntax for the Toolkits States view. . . . . . . . . . . . . . . . . 34

2.35 Concrete syntax for Lifecycle. . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.36 Concrete syntax for State. . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.37 Concrete syntax for State Transition. . . . . . . . . . . . . . . . . . . . . . 362.38 Abstract syntax for the Toolkits WebComponents view. . . . . . . . . . . 37

2.39 Concrete syntax for Toolkit WebComponents (with no contained WebEle-

ments). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.40 Concrete syntax for Support WebPages (with no contained WebElements). 39

2.41 Concrete syntax for Expected Entity. . . . . . . . . . . . . . . . . . . . . . 40

2.42 Concrete syntax for Binding. . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.43 Concrete syntax for Simple WebElement. . . . . . . . . . . . . . . . . . . . 44

2.44 Concrete syntax for HTML WebElement. . . . . . . . . . . . . . . . . . . . 45

2.45 Concrete syntax for WebElement Container. . . . . . . . . . . . . . . . . . 47

2.46 Example of a Toolkit WebComponent with some contained WebElements. . 47

2.47 Abstract syntax for the Toolkits Side Effects view. . . . . . . . . . . . . . 48

2.48 Concrete syntax for Side Effect, the corresponding mapping, and a set of

contained Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

2.49 Abstract syntax for the Toolkits Interaction Access view. . . . . . . . . . . 52

2.50 Concrete syntax for WebInteractionSpace Access. . . . . . . . . . . . . . . 54

2.51 Concrete syntax for matrix representation of Interaction Access elements. . 55

2.52 Abstract syntax for the Toolkits Interaction Triggers view. . . . . . . . . . 56

2.53 Concrete syntax for Trigger. . . . . . . . . . . . . . . . . . . . . . . . . . . 56

2.54 Concrete syntax for Display On Start. . . . . . . . . . . . . . . . . . . . . 57

2.55 Abstract syntax for the WebSite Annotations model. . . . . . . . . . . . . 58

2.56 Concrete syntax for Annotations. . . . . . . . . . . . . . . . . . . . . . . . 59

2.57 Abstract syntax for CMS-ML Additional Features. . . . . . . . . . . . . . . 60

2.58 Concrete syntax for Additional CMS Feature. . . . . . . . . . . . . . . . . 61

2.59 Concrete syntax for Additional Toolkit Feature. . . . . . . . . . . . . . . . 61

2.60 Abstract syntax for the CMS-ML Toolkit Import mechanism. . . . . . . . . 62

iii


5/82

LIST OF FIGURES

2.61 Concrete syntax for Toolkit Import elements. . . . . . . . . . . . . . . . . . 63

2.62 Toolkit Domain view with imported Toolkit elements. . . . . . . . . . . . . 64

2.63 Concrete syntax for Toolkit elements in WebSite Templates. . . . . . . . . 65

3.1 The Macro Structure view of the Personal WebSite. . . . . . . . . . . . . . 67

3.2 The Micro Structure view of the Personal WebSite. . . . . . . . . . . . . . 68

3.3 The Roles view of the Personal WebSite. . . . . . . . . . . . . . . . . . . . 69

3.4 The Permissions view of the Personal WebSite. . . . . . . . . . . . . . . . . 70

3.5 The Roles view of the Documents Toolkit. . . . . . . . . . . . . . . . . . . 71

3.6 The Tasks for the Documents Toolkit. . . . . . . . . . . . . . . . . . . . . 72

3.7 The Domain view of the Documents Toolkit. . . . . . . . . . . . . . . . . . 72

3.8 The States view of the Documents Toolkit. . . . . . . . . . . . . . . . . . . 73

3.9 The Manage Documents WebComponent of the Documents Toolkit. . . . . 74

3.10 The Edit Document Support WebPage of the Documents Toolkit. . . . . . 74

3.11 The Interaction Access view of the Documents Toolkit Can Interact With

elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

3.12 The Interaction Triggers view of the Documents Toolkit Trigger elements. 76

iv


6/82

Chapter 1

Introduction

The Model-Driven Engineering paradigm has become increasingly popular due to its usage

of models as the main artifacts in the software development process, while artifacts such as

documentation and source code can be produced from those models by using automated

transformations. On the other hand, we are currently witnessing the rise in popularity

of a particular kind of web application, Content Management Systems (CMS), which are

already typically regarded as software systems critical to the success of organizational

websites and intranets.

This documents presents the CMS Modeling Language (CMS-ML), a graphical languagefor the high-level modeling of CMS-based web applications. CMS-ML is oriented toward

enabling non-technical stakeholders to quickly model a web application supported by a

CMS system. Furthermore, the language also allows for its extension, in order to address

an organizations specific requirements and to support the modeling of more complex web

applications.

CMS-ML was structured so that it is not mandatory that a single designer have the skills to

create both WebSite Template and CMS-based Toolkit models. Although CMS-ML does

not define a modeling approach per se, we consider that CMS-ML models will typicallybe developed according to the following roles, shown in Figure 1.1:

The Toolkit Designer, who models Toolkits;

The WebSite Template Designer (usually designated just as Template Designer,

for text simplicity), who models a WebSite Template; and

The WebSite Creator, who instantiates the various elements defined in the Web-

Site Template.

1


7/82


8/82

Chapter 2

CMS-ML Elements

The Content Management System Modeling Language (CMS-ML) is a graphical modeling

language that has been developed with the objective of allowing the specification of CMS-

-based web applications in a high-level and platform-independent manner.

CMS-ML modeling is mainly focused on three different (and complementary) types of

model: (1) WebSite Templates, (2) WebSite Annotations, and (3) Toolkits. Figure 2.1

illustrates the relationship between these CMS-ML model types.

Figure 2.1: The relationship between CMS-ML models.

A WebSite Template (sometimes just called Template, for simplicity) is a model that

reflects the intended websites structure and behavior; this Template is modeled using

CMS-oriented elements such as Role, Dynamic WebPage, WebComponent that are pro-

vided by CMS-ML.

On the other hand, a Toolkit allows the addition of new modeling elements to the set

of elements that are available for modeling a WebSite Template, namely by specifying

3


9/82

a domain model, user interface, and corresponding behavior. A WebSite Template can

then reference a Toolkit (or a set of Toolkits), making the Toolkits elements available

for use in the Template model. Furthermore, a Toolkit can also reference other Toolkits,

enabling scenarios in which a Toolkit A refines and/or extends functionality defined in aToolkit B.

Finally, the elements of a WebSite Template can be annotated, by means of a WebSite

Annotations model (or just Annotations). This model decorates a WebSite Template,

allowing designers to specify CMS-specific properties without polluting the Template with

platform-specific details. Thus, from a practical perspective, CMS-ML designers do not

view two different models (the Template and the Annotations), but rather a single model

that results from combining those two models (i.e., a model that is the result of extending

the Template with the Annotations).

Before starting the description of CMS-ML, it is important to highlight that WebSite

Templates and Toolkits are located in different metalevels. While WebSite Templates are

meant to create abstractions (i.e., models) of concrete web applications by using CMS-

-oriented elements, Toolkits use generic modeling elements to create new CMS-oriented

modeling elements. Because some Toolkit concepts are also specializations of WebSite

Template concepts (and so instances of those Toolkit concepts are automatically consid-

ered as instances of the corresponding WebSite Templates concepts), Template Designers

can then use those Toolkit concepts to create WebSite Templates in the same manner aswhen using the predefined Template modeling elements.

The architecture of CMS-ML illustrated in Figure 2.2 considers the following met-

alevels:

Metalevel ML3 contains the Toolkit Modeling model, which provides the definition

of the generic Toolkit modeling elements that will be used to define Toolkit models.

This metalevel cannot be changed by designers of any kind;

The ML2 metalevel contains the WebSite Template Modeling and WebSite Anno-

tations Modeling models, which provide the modeling elements that will be used to

define WebSite Template and WebSite Annotations models. Furthermore, Toolkit

Designers can create instances of the generic modeling elements located in ML3, in

order to define new elements that specialize WebSite Template Modeling elements.

However, like the Toolkit Modeling models in ML3, the WebSite Template Model-

ing and WebSite Annotations Modeling models are fixed and cannot be changed by

anyone;

In metalevel ML1, WebSite Template Designers can create WebSite Template and

WebSite Annotations models, by using the modeling elements defined in ML2.

4


10/82

2.1. WEBSITE TEMPLATE

Figure 2.2: Metalevels considered by CMS-ML.

These elements include not only those provided by the WebSite Template Mod-

eling and WebSite Annotations Modeling models, but also the elements defined by

any Toolkit model(s) that are made available to the WebSite Template, via the

Toolkit Import concept (explained in Subsection 2.4.2); Finally, in metalevel ML0, the WebSite Creator (not the Template Designer) uses

the elements defined in the WebSite Template model (along with its decorating

WebSite Annotations model, if any) to configure a particular CMS installation.

This will usually require some CMS-specific mechanism that establishes a mapping

between an instance and a model element (e.g., a column in a Users database table

that, for each row/CMS user, identifies the corresponding Template User).

The remainder of this chapter is dedicated to describing these models WebSite Templates

and Toolkits in greater detail as well as the Annotations feature.

2.1 WebSite Template

CMS-ML provides a set of generic modeling elements that WebSite Template Designers

can use to define their Templates for CMS-based websites.

A WebSite Template is defined according to a set of views (illustrated in Figure 2.3),

namely:

5


11/82


The Structure view, which specifies the websites structural components;

The Roles view, which deals with the set of responsibilities that the website expects

its users to assume; and

The Permissions view, specifying which Roles have access to the websites structuralcomponents.

Figure 2.3: The views involved in the definition of a WebSite Template.

The next subsections provide further details on these views and on how to model WebSite

Templates.

2.1.1 Structure View

The Structure view is perhaps the most important view in CMS-ML, as it enables the

modeling of the websites structure, a factor which is usually paramount in the users

acceptance of a website. Figure 2.4 illustrates the concepts that are used when specifying

the Structure view.

Because of the large number of composition relationships between the concepts of thisview, in practice the Structure view is divided into two sub-views:

The Macro Structure view, where the high-level view of the WebSite and its Dynamic

WebPages is defined;

The Micro Structure view, where the layout of each Dynamic WebPage is specified.

Modeling the website begins with the Macro Structure view, more specifically with the

WebSite concept, which represents the system/website that is being modeled. This

concept defines a single attribute:

Name (string): The name of the website that is being modeled (e.g., My Personal

WebSite).

A WebSite is represented by drawing a large rectangular shape, which is further divided

horizontally into two smaller rectangles: the top rectangle is where the WebSites name

is specified (on the left), while the bottom rectangle is where its Dynamic WebPages

(explained next) will be inserted. Figure 2.5 illustrates the representation of a WebSite

(Home and About me are two Dynamic WebPages). To make it easier to distinguish the

WebSites representation from other similar representations (namely Dynamic WebPages),

the symbol is placed on the right of the top rectangle.

6


12/82


13/82


By default, a Dynamic WebPage can be viewed by anyone (including anonymous users).

If this is not desired, the Template Designer must specify a set of permissions for the

Dynamic WebPage, in the Permissions view (see Subsection 2.1.3 for further details).

A Dynamic WebPage in the Macro Structure view is represented as shown in Figure 2.6,

by drawing a rectangular shape which is further divided horizontally into two smaller

rectangles. The top rectangle specifies whether the Dynamic WebPage is the WebSites

HomePage (the HomePage is marked with a small flag on the top rectangles left side, as

illustrated in Figure 2.6a). The bottom rectangle contains the Dynamic WebPages name

(in the center of the figure) and its order within the WebSite or parent Dynamic WebPage

(in the lower-left corner of the figure), as shown in Figure 2.6b. Furthermore, all Dynamic

WebPages are specified within the bottom rectangle of the WebSites representation (as

was depicted in Figure 2.5).

(a) A DynamicWebPage markedas the WebSitesHomePage.

(b) A regular Dy-namic WebPage.

Figure 2.6: Concrete syntax for Dynamic WebPages in the Macro Structure View.

Dynamic WebPages can be related to each other by two kinds of relationship, Dynamic

WebPage Child and Dynamic WebPage Template.

The Dynamic WebPage Child relationship enables the Template Designer to establish

parent-child relationships (in an ordered manner) between Dynamic WebPages, allowing

the modeling of the WebSites Dynamic WebPage hierarchy in a tree-like manner. This re-

lationship carries the semantics of composition, in that the removal of the parent Dynamic

WebPage will cause the removal of all child Dynamic WebPages.

The Dynamic WebPage Child relationship is represented by drawing a line between the

parent Dynamic WebPage and the child Dynamic WebPage, with a blank diamond deco-

rating the parents end of the line. Figure 2.7 illustrates this representation, in which the

Home Dynamic WebPage is the parent of both the Contacts and My Private Page Dynamic

WebPages. The order of the page is also shown: Home is the first Dynamic WebPage within

the WebSite (and it is also the HomePage, as mentioned previously) because it has a

1 in its lower-left corner and it has no parent Dynamic WebPage, and Contacts and My

8


14/82


Private Page are the first and second children of Home because of the 1 and 2 in their

representations, respectively.

Figure 2.7: Concrete syntax for Dynamic WebPage Child.

A Dynamic WebPage Template is another kind of relationship between two Dynamic

WebPages, the template and the duplicate. This relationship allows the Template Designer

to quickly specify that the duplicate will have the same visual structure as the template.This relationship is transitive, allowing the visual structure of a Dynamic WebPage to

be duplicated among several other Dynamic WebPages while keeping the models design

relatively simple. However, it is an error to model such Templates in a circular manner

(e.g., Page A duplicating Page B, and Page B duplicating Page A), because otherwise

the template specification could become ambiguous.

The effects of establishing a Dynamic WebPage Template relationship between a template

Dynamic WebPage and a duplicate Dynamic WebPage are the following (the concepts that

are mentioned in this list will be explained further down the text of this guide): All the Containers (from the Micro Structure view) in the template are replicated

to the duplicate;

The WebComponents (from the Micro Structure view) that are present in the tem-

plate are not replicated to the duplicate.

A Dynamic WebPage Template is represented by drawing a line between the template

Dynamic WebPage and the duplicate Dynamic WebPage, with a blank-filled arrowhead

decorating the templates end of the line. Figure 2.8 illustrates this representation, in

which the Contacts Dynamic WebPage serves as a template for My Private Page.

Figure 2.8: Concrete syntax for Dynamic WebPage Template.

After modeling the Macro Structure view (the WebSite and its Dynamic WebPages), the

Template Designer can then model the Micro Structure view. This is done by modeling

9


15/82


the layout and components of each Dynamic WebPage that was specified in the Macro

Structure view.

To begin with, each Dynamic WebPage must be represented again, so that their contents

can be modeled. In the Micro Structure view, the Dynamic WebPage is represented by

drawing a large rectangle which is further divided horizontally into two smaller rectan-

gles. In the top rectangle, the Dynamic WebPages name is written on the left side, while

the symbol is placed on the right side. The Dynamic WebPages contents (namely

Containers and/or WebComponents) will be specified within the bottom rectangle. Fig-

ures 2.9 and 2.11 provide an example of modeling the layout of a Dynamic WebPage in

the Micro Structure view.

Within each Dynamic WebPage there must be a set of Containers. The Container is a

concept that represents an area, within its Dynamic WebPage, where WebComponents will

be placed. This concept defines the following attributes:

Name (string): The name of the Container (e.g., Top, Bottom, Left);

Left (measure): The distance from the left border of this Container to the left

border of the parent Dynamic WebPage. Specified as a size measure, the kind of

which is identified by the values suffix (e.g., percentage is indicated by %, pixels

as px, points as pt, or other size measures that are acceptable by a web browser);

Top (measure): The distance from the top border of this Container to the top

border of the parent Dynamic WebPage, specified as a size measure;

Width (measure): The width of this Container, specified as a size measure;

Height (measure): The height of this Container, specified as a size measure.

A Container is represented simply by drawing, within the Dynamic WebPage, a rectangle

with its name on its top-center section. The rectangles position and dimension should

correspond to the containers desired position and dimension (i.e., Left, Top, Width, and

Height) in relation to the Dynamic WebPage. Figure 2.9 shows an example, depicting

three Containers (Banner, Navigation Bar, and Body) within the Dynamic WebPage Home.

Of course, it is not possible to specify Containers for Dynamic WebPages that are du-

plicates, as per the Dynamic WebPage Template relationship, because those Containers

are inherited from the template Dynamic WebPage.

Each Container will be used to hold an arbitrary number of WebComponents. A Web-

Component is a concept that represents the CMSs functionality, which users can see

and with which they will possibly interact (e.g., a GuestBook, some HTML text). The

WebComponent concept defines the following attribute:

Name (string): The name of the WebComponent that is being modeled (e.g., My

Blog, My Photos).

10


16/82


Figure 2.9: Concrete syntax for Dynamic WebPage Containers.

The WebSite Template perspective of CMS-ML defines two kinds of WebComponents,

Standard WebComponent and Custom WebComponent.

A Standard WebComponent can be regarded as a strongly-typed WebComponent (e.g.,

a Forum, a Blog) that will be available in most CMS systems. Because most WebComponent

details will be handled by the CMS system itself, the Standard WebComponent concept

defines no attributes. CMS-ML defines the following kinds of Standard WebComponents:

HTML

Image

Links Portal Tree

BreadCrumb

Announcements

Events

Blog

Forum

GuestBook

Poll

Survey

Additionally, a Custom WebComponent is a WebComponent whose type is manually

specified, as a string of characters, by the Template Designer. This concept defines a

single attribute:

Type (string): The kind of WebComponent that this model element is supposed to

represent (e.g., PodCast Receiver, WebTV Receiver).

It is usually a good idea for Template Designers to use Standard WebComponents when-

ever possible, and also to only use Custom WebComponents when there are no Standard

11


17/82


WebComponents that are suitable for their purposes (or when they are absolutely sure that

the target CMS will be able to correctly interpret the string that is provided in the Type

attribute).

WebComponents are represented by drawing a rectangular shape within a Containers

shape (or, if the Dynamic WebPage is a duplicate, within the Dynamic WebPages bottom

rectangle itself). This rectangular shape is further divided horizontally into two smaller

rectangles: the top rectangle is where the WebComponents type is specified, while the

bottom rectangle contains the WebComponents details, namely its name (in the center of

the rectangle) and its order within the Container (in the rectangles bottom-left corner).

Figure 2.10 illustrates these possible WebComponent representations.

A Standard WebComponent is represented by specifying its type (as one of the values that

have been previously mentioned) in the top rectangles left side, and by drawing a circle

on that rectangles right side, as shown in Figure 2.10a.

A Custom WebComponent (depicted in Figure 2.10b) is represented in a manner very

similar to a Standard WebComponent, but its top rectangle (the WebComponents type) is

represented in a different manner: in the left of the rectangle, the Template Designer can

specify any type of WebComponent (instead of using a Standard WebComponents Type),

and the icon in the right is replaced by a small rectangle with the letters XYZ in it

(meaning the WebComponents Type is a simple string).

(a) Standard WebComponent. (b) Custom WebComponent.

Figure 2.10: Concrete syntax for WebComponents.

If the WebComponent belongs to a Dynamic WebPage that is not a duplicate of another,

it is not necessary to explicitly specify in which Container it is located (as this informa-

tion can be automatically inferred from the model). On the other hand, if the Dynamic

WebPage is a duplicate, it is necessary to specify the WebComponents Container. To do

so, the Template Designer must write the Containers name above the WebComponents

representation.

Figure 2.11 presents two examples of Dynamic WebPage models in the Micro Structure

view. In Figure 2.11a, a Dynamic WebPage (Home) is modeled as having three Containers

12


18/82


(Navigation Bar, Banner, and Body); of these Containers, only Body has WebComponents

within it, namely My Blog and My TV Receiver, in that order. On the other hand, in Fig-

ure 2.11b, a Dynamic WebPage (HomeDuplicate), which is a duplicate of the Home Dynamic

WebPage shown in Figure 2.11a, is modeled as just having two WebComponents withinBody, My Blog and My TV Receiver, in that order; note that the Body Container is not

modeled in this Dynamic WebPage, but is inherited from the Home Dynamic WebPage.

(a) Dynamic WebPage in Micro Structure view, withContainers.

(b) Dynamic WebPage in Micro Structureview, with no Containers.

Figure 2.11: Concrete syntax for Dynamic WebPages.

2.1.2 Roles View

The Roles view describes the various kinds of expected responsibilities that users are

expected to have when interacting with the CMS-based web application. It defines two

concepts, Role and Role Delegation: the former models those expected responsibilities,

while the latter specifies whether such responsibilities can also be played out by other

Roles. Figure 2.12 illustrates these concepts.

Figure 2.12: Abstract syntax for the WebSite Templates Roles view.

As was previously mentioned, a Role represents a certain kind of responsibility (with a

corresponding set of rights) that the modeled web application expects from its users (e.g.,

a Role can be used to model the responsibility of managing a document repository). This

concept has the following attributes (their data types are specified in parenthesis):

Name (string): The Roles name. There must not be two Roles with the same

name;

13


19/82


Type (Role Type): The type of the Role. It assumes one of the following values:

Administrator: The Role is considered as a CMS administrator. Although

this kind of Role can delegate (or be delegated) responsibilities, most CMS

systems tend to allow administrators to do anything at all, so it is not recom-mended to establish Role Delegations with Administrator Roles;

Anonymous: The Role is anonymous (i.e., it represents users that have not

authenticated themselves with the CMS system). An Anonymous Role does

have some caveats, namely it cannot delegate or be delegated responsibili-

ties;

Regular: The Role is just a plain CMS role, without any particular traits.

By default, the value of this attribute is Regular.

A Role is represented by drawing a simple shirt-like figure, as shown in Figure 2.13a. TheRoles name is written below the drawn figure. If the Role is an Administrator Role

(i.e., its Type attribute assumes the value Administrator), it is represented as a Role

with a small diamond-shaped pentagon and the letter A over the figure, as shown in

Figure 2.13b. Finally, if the Role is an Anonymous Role (i.e., its Type attribute assumes

the value Anonymous, meaning its users are not authenticated with the CMS system), it

is represented as a Role but with a question mark (?) over the figure, as illustrated in

Figure 2.13c.

(a) A typicalRole.

(b) An Administra-tor Role.

(c) An Anony-mous Role.

Figure 2.13: Concrete syntax for Template Role.

On the other hand, a Role Delegation is a very simple concept that establishes a

delegation of responsibilities between two Roles, (1) the delegator, which is the Role

that delegates its responsibilities, and (2) the delegatee, which is the Role that assumes

those responsibilities. There are some notes and constraints regarding the usage of Role

Delegations, namely:

A Role Delegation cannot involve an Anonymous Role, either as a delegator or as

a delegate;

An Administrator Role can be involved in a Role Delegation, although this is

not a recommended practice;

14


20/82


Although CMS-ML does not forbid circular delegations (e.g., Role A delegating to

Role B, and Role B delegating to Role A), this is usually not recommended because

it would make such Role Delegations become redundant (and most CMS systems

tend to forbid such circular delegations anyway). Designers using this practice areencouraged to revise their models, either by collapsing those Roles into a single

Role, or by removing such Role Delegations.

A Role Delegation is represented in the manner shown in Figure 2.14, by drawing a line

between the delegator and the delegatee, with a filled arrowhead decorating the delegatees

end of the line and the string delegates to written on the line.

Figure 2.14: Concrete syntax for Role Delegation.

2.1.3 Permissions View

The Permissions view can be considered as establishing a mapping between the web-

sites structure and its roles. It defines two concepts, Dynamic WebPage Permission

and WebComponent Permission, which enable the creation of RoleDynamic WebPage

and RoleWebComponent links, respectively. Figure 2.15 provides an illustration of these

concepts.

Figure 2.15: Abstract syntax for the WebSite Templates Permissions view.

A Dynamic WebPage Permission determines the actions that a Role can perform

over a Dynamic WebPage. It has the following attributes:

View (boolean): Whether the Role can view the Dynamic WebPage. The default

value of this attribute is True;

15


21/82


22/82


Roles and Macro Structure views, respectively (although it is not necessary to represent

the Dynamic WebPages details, such as its order within the WebSite).

(a) A Dynamic WebPage Permission with all of its valuesexplicitly specified.

(b) A Dynamic WebPage Permission with some of its valuesexplicitly specified.

(c) A Dynamic WebPage Permission withall default values (simplified representa-tion).

Figure 2.16: Concrete syntax for graphical representation of Dynamic WebPage Permis-sion.

A WebComponent Permission is represented in a very similar manner as Dynamic WebPage

Permissions, by drawing a line between the Role and the WebComponent, with the valuesof the Permissions attributes written on the line, as presented in Figure 2.17. As with

Dynamic WebPage Permissions, the names and values of the Permissions attributes

(View, Configure, and Edit Content) only need to be represented if they are not set to

their default value, otherwise they can be omitted as illustrated in Figure 2.17b, which

presents a WebComponent Permission with only one non-default value). In this view,

WebComponents are represented with the same syntax as in the Micro Structure view (al-

though it is not necessary to represent the WebComponents details, such as its type or its

order within the Container).

(a) A WebComponent Permission with all of itsvalues explicitly specified.

(b) A WebComponent Permission with one of itsvalues explicitly specified.

Figure 2.17: Concrete syntax for graphical representation of WebComponent Permission.

17


23/82


Regarding the representation of the Permissions view via a set of permission matrices,

this view can be represented by the following set:

A matrix containing the permission mappings between the websites Roles and

Dynamic WebPages, called Page Permission Matrix;

For each Dynamic WebPage, a matrix containing the permission mappings between

the Roles and the pages WebComponents, called WebComponent Permission Ma-

trix.

The Page Permission Matrix is represented as a typical matrix, with:

The WebSite symbol ( , also used in the WebSites representation in the

Macro Structure view) in the matrixs top-left corner;

The websites Roles providing the columns; The Dynamic WebPages providing the lines; and

The names of the permissions prefixed by a checkmark or a cross (like in the graph-

ical representation for a Dynamic WebPage Permission).

The WebComponent Permission Matrix is also represented as a typical matrix, with:

The Dynamic WebPages name on top of the matrix;

The Dynamic WebPage symbol ( , also used in the Dynamic WebPages represen-

tation in the Micro Structure view) in the matrixs top-left corner;

The websites Roles providing the columns;

The pages WebComponents providing the lines; and

The names of the permissions prefixed by a checkmark or a cross (like in the graph-

ical representation for a WebComponent Permission).

As in the graphical representation, permissions that are omitted assume their default val-

ues. Figure 2.18a shows a set of Dynamic WebPage Permissions in the matrix format:

for the represented Dynamic WebPages, the permissions for ARegularRole are all set to

their default values (because they are not specified in the top-left section, and they are

with their default values in the bottom-left section), but ManagerRole has permissions to

do any kind of action (remember that only the View permission is True by default). Fig-

ure 2.18b also shows a set of permissions, now regarding WebComponents: the represented

permissions state that RegularRole has default permissions for the MyBlog and Forum

WebComponents except for the Forum WebComponent in which it has an Edit Content

permission , and that BlogManager has default permissions over Forum (View is True by

default), but has permission to do any kind of action over MyBlog.

18


24/82

2.2. TOOLKIT

(a) A set of Dynamic WebPage Permissions in a ma-trix representation.

(b) A set of WebComponent Permissions in amatrix representation.

Figure 2.18: Concrete syntax for matrix representation of Dynamic WebPage Permissionsand WebComponent Permissions.

2.2 Toolkit

Although CMS-ML provides the WebSite Template elements (presented in the previous

section) out-of-the-box, the language also allows for its extension to a certain degree by

means ofToolkits. A Toolkit can be regarded as a task-oriented complement to Template

elements, as it enables the addition of new Template-related concepts (namely Roles and

WebComponents) that are particularly oriented toward supporting a particular set of tasks.

Like a WebSite Template, a Toolkit is defined according to a set of views (illustrated in

Figure 2.19), namely:

The Roles view, specifying the expected roles that are to perform the Toolkits tasks;

The Tasks view, which deals with the user tasks that the Toolkit should support;

The Domain view, which specifies the domain model that underlies the Toolkits

tasks;

The States view, which deals with the lifecycle (or states) of the entities that the

tasks are to manipulate;

The WebComponents view, specifying the components that will support the tasks;

The Side Effects view, which establishes the side effects that the modeled tasks and

components will have;

The Interaction Access view, which establishes the access mappings between roles

and components (i.e., who can access what);

The Interaction Triggers view, which establishes mappings between tasks and com-

ponents (i.e., what triggers what).

These views are explained in the following subsections.

19


25/82

2.2. TOOLKIT

Figure 2.19: The views involved in the definition of a Toolkit.

2.2.1 Roles View

In a manner that is very similar to the WebSite Templates Roles view, the Toolkit Roles

view describes the various kinds of expected responsibilities that are expected by the

Tasks defined in the Toolkit (explained in Subsection 2.2.2). It defines two concepts,

Role and Role Specialization. Figure 2.20 provides a tentative illustration of the

relationship between the concepts of the Toolkit Roles view.

Figure 2.20: Abstract syntax for the Toolkits Roles view.

Role models those expected responsibilities, and defines only the following attribute:

Name (string): The Roles name. There must not be two Toolkit Roles (within

the same Toolkit) with the same name.

On the other hand, Role Specialization models specialization relationships between

Roles, as the name indicates. In other words, it is possible to specify that a Role A is a

20


26/82

2.2. TOOLKIT

particular case of a Role B, and so the former can fill in the shoes of the latter (although

the reverse is not true). Note that this is not the same as delegating responsibilities (which

is the purpose of Role Delegation): a specialization is typically meant as a permanent

relationship between Roles, while a delegation often expresses a temporary relationship.

It is important to note that Toolkit Roles are not modeled in the same manner as the

WebSite Templates Roles, as these two concepts are located in different conceptual levels.

In fact, the only relationship between the Template Role and Toolkit Role concepts is

that each modeled Toolkit Role will actually be a specialization of the Template Role

concept (which, in turn, will be modeled as a concrete Role in the WebSite Template).

Thus, when modeling the WebSite Template Roles view, each Role will be an instance of

the WebSite Templates Role concept presented in Subsection 2.1.2, but it may also be1

a Toolkit Role that will participate in some of the Toolkits Tasks. However, because theToolkit is modeled in a different conceptual level than the WebSite Template, it is not

possible to use Toolkit Roles and WebSite Template Roles in the same model, nor is it

possible to model Role Delegations in the Toolkit Roles view.

A Toolkit Role is represented in almost the same manner as a Template Role (see Sub-

section 2.1.2), by drawing a shirt-like figure with the letter T within the figure and the

Roles name underneath it, as shown in Figure 2.21.

Figure 2.21: Concrete syntax for Toolkit Role.

On the other hand, a Role Specialization is represented by drawing a line between

the generalization and specialization Roles, with a blank-filled arrowhead decorating the

bases end of the line, as shown in Figure 2.22.

Figure 2.22: Concrete syntax for Role Specialization.

1One of the most important issues to be aware of when dealing with metamodeling is the ambiguity of the

is-a term, as it can refer to either specializations or instantiations. Each of these possibilities carriesa completely different set of semantics with it.

21


27/82

2.2. TOOLKIT

2.2.2 Tasks View

The Tasks view is one of the most important views for the Toolkit Designer, because it

allows the specification of the various tasks that the Toolkit should support. The mostimportant concepts in this view are Task and Action, which represent the tasks to be

performed, and the various actions (or steps) that will be necessary to perform those

tasks, respectively. Figure 2.23 depicts the concepts that are defined in the Tasks view.

Figure 2.23: Abstract syntax for the Toolkits Tasks view.

The Toolkit Designer will start by using the Task concept. A Task is used to describe

the manner in which the interaction between a user and the Toolkit should be performed,

and defines the following attributes:

Name (string): The name of the Task (e.g., View Document). This attribute is

actually inherited from the Action concept (which is described further down the

text). It is an error for two Tasks to have the same name;

Goal (string): The objective of the Task (written in natural language). It is not

mandatory to explicitly specify the Tasks goal.

A Task is represented as shown in Figure 2.24a, by drawing a large rectangle and writing

the Tasks name, underlined, in the top-left corner of the rectangle. The symbol

(representing a connection between a user and a Task, because Tasks are specifications of

interaction between users and the system) should be included in the rectangles top-right

corner. If the goal is specified, it is written below the Tasks name, in a smaller font and

not underlined, as is illustrated in Figure 2.24b.

22


28/82

2.2. TOOLKIT

(a) A Task (with no goal specified). (b) A Task, with a goal specified.

Figure 2.24: Concrete syntax for Task.

A Task must be performed by someone. The Task Participation concept enables the

modeling of this fact, by establishing a relationship between the Task to be performed

and each of the Roles that play some part in performing that Task (i.e., the Roles that

participate in the Task).

A Task Participation is represented simply by drawing a line between the Toolkit Role

and the Task, as depicted in Figure 2.25. In this view, Roles are represented with the

same concrete syntax as in the Roles view.

Figure 2.25: Concrete syntax for Task Participation.

A Task can be described as a series of actions, which are captured by means of the Action

concept. Nevertheless, it is important to emphasize that a Task should not be viewed just

as a structured collection of Actions; a Task can be regarded as a holistic entity that

drives the interaction between the user and the web application, an entity which is also

composed of a sequence of steps that will be executed by users performing the Task.

An Action can be considered as a unit of work that is necessary to perform in order to

complete a Task (e.g., one of the actions in a Task View Document Contents can be the

Action select Document to view). There is a number of types of Action, namely:

User Interaction

Automatic Action

Choice

Fork

Join

Finish

Composite Action

23


29/82

2.2. TOOLKIT

Furthermore, of these types of Action, some are Named Actions. Named Actions are,

as the name indicates, Actions that have a Name (a string that should consist of a small

statement regarding what the Action will do). The Named Actions available in CMS-ML

are User Interaction, Automatic Action, and Composite Action.

A User Interaction is an Action that requires some kind of interaction with the user

(e.g., showing a message to a user, which will require that the user press an OK button).

It is represented as shown in Figure 2.26a, by drawing a rectangle, writing the Actions

name in the center of the rectangle, and placing the symbol (representing a user that

will have to interact with the system) in the rectangles top-left corner.

An Automatic Action is a kind of Action that will be performed automatically by the

system, without requiring any interaction with the user. An example of an Automatic

Action can be the sending of an e-mail (considering that the e-mails parameters sender,

destination, contents have already been specified in previous Actions). An Automatic

Action is represented in a manner similar to a User Interaction, by drawing a rectangle

and writing the Actions name in the center of the rectangle. The symbol (repre-

senting the system that will have to interact with the system) is placed in the rectangles

top-left corner. Figure 2.26b depicts the representation of an Automatic Action.

A Choice is an Action that expresses a set of alternatives regarding the path of Actions

to perform in the Task. It defines a single attribute:

Expression (string): An expression that will determine what path to take in the

Tasks Actions. There is no restriction regarding the language in which the ex-

pression should be defined (e.g., a natural language statement if we have a good

enough search match or a logical expression searchResultRanking 10 are

valid Choice expressions). It is possible for two Choices (within the same Task, or

in different Tasks) to have the same expression.

A Choice is represented by drawing a large diamond shape and writing the Choices

expression in the center of the diamond, as depicted in Figure 2.26c.A Fork is a kind of Action that splits the Tasks flow into several other Action flows

(which can, in turn, be performed in a concurrent manner). A Fork is represented simply

by drawing a thick line, as depicted in Figure 2.26d (some Action Transitions are

also represented in the figure). This line will be connected to other Actions by Action

Transitions (which will be explained near the end of this section). There are, however,

some restrictions regarding the possible connections in which a Fork may be involved.

On the other, a Join is a kind of Action that receives multiple Task Actions flows

(which are being performed concurrently) and joins them into a single flow. In practice, a

24


30/82

2.2. TOOLKIT

Join will mean wait for all the selected concurrent Actions to finish, and then proceed

with the Task. A Join is represented in the same manner as a Fork, by drawing a

thick line as shown in Figure 2.26e (the figure also includes some Action Transitions).

As is the case with the Fork, this line will be connected to other Actions by Action

Transitions.

A Finish Action is used to specify that the Task is finished (although not necessarily

in a successful manner), and so no further Actions will be performed in the context of

that Task. A Finish Action is represented simply by drawing two concentric circles of

slightly different sizes: the larger circle is filled with white, while the smallest one is filled

with black, as depicted in Figure 2.26f.

A Composite Action is a kind of Action that has the sole purpose of aggregating other

Actions. It is typically used as a way to organize Actions, by grouping related finer-

-grained Actions into a coarser-grained Action (e.g., a set of Actions Enter Author Name

and Enter Author Address can be grouped into a Specify Author Composite Action).

Besides this grouping usage, the Composite Action presents no functional added value

whatsoever, and so it is possible to define any Task without using Composite Actions.

Furthermore, it is possible for a Composite Action to group other Composite Actions.

A Composite Action is represented by drawing a rectangle, as shown in Figure 2.26g

(which includes two Actions within the represented Composite Action, as well as three

Action Transitions), with the symbol in its top-left corner and the Actionsname centered in its top section. The Actions that are contained within the Composite

Action are represented within the rectangle, using their normal concrete syntax.

All of these Actions are linked to each other by Action Transitions. An Action Tran-

sition is a directed link between any two Actions, the source and the target, and indicates

the control flow between the Tasks Actions. After a source Action is completed, the

next Action to perform is determined by finding the Action Transition that has the

current Action as its source and finding its target Action. An Action Transition is

represented by drawing a line between the source Action and the target Action, withan arrowhead decorating the targets end of the line, as in Figure 2.26g. If the Action

Transition has a condition specified (namely when its source is a Choice action), the

condition is represented by writing it on the actions corresponding line.

There are some considerations when modeling Tasks and Actions. First of all, the ini-

tial Action to be performed when the Task starts is defined by specifying an Action

Transition between the Task itself (because the Task itself is a particular kind of

Action) and the initial Action. Following the same line of thought, the first Action to be

performed in a Composite Action is determined by specifying an Action Transition

25


31/82

2.2. TOOLKIT

(a) A User Interaction. (b) An Automatic Action. (c) A Choice.

(d) A Fork. (e) A Join. (f ) A Finish Action.

(g) A Composite Action.

Figure 2.26: Concrete syntax for the various kinds of Action.

between the Composite Action itself and its initial Action; furthermore, there should

be an Action Transition between the last Action in a Composite Action and the

Composite Action (except if that last Action is a Finish Action). Figure 2.27 presents

an example of a modeled Task, performed by the Document Manager Role, and containing

some Actions (including a Composite Action, a Fork, and a Join) and some Action

Transitions between them.

Finally, there are the following restrictions to consider when modeling the Actions of a

Task: A User Interaction can be the source of more than one Action Transitions (if

there is more than one Action Transition, each of them must have a Condition

explicitly specified);

An Automatic Action can be the source of only one Action Transition;

A Choice must be the source of more than one Action Transition (each of which

with a Condition explicitly specified);

A Fork must be the source of more than one Action Transition;

A Join must be target of more than one Action Transition;

26


32/82

2.2. TOOLKIT

Figure 2.27: Concrete syntax for a Task with some Actions.

Each Finish Action must be target of at least one Action Transition, and cannot

be the source of any Action Transitions;

There must be exactly one Action Transition with the Task as its source (and

the initial Action as the target);

There can be no Action Transitions with the Task as the target;

A Task cannot contain other Tasks.

2.2.3 Domain View

The Domain view is where the Toolkits underlying domain model is specified. It is

very similar to the UMLs Class Diagram concepts, and consists of specifying entities

and relationships between them. Figure 2.28 depicts the concepts that are used in the

modeling of the Domain view.

The most important concept in the Domain view is the Entity concept. This concept is

used to model the entities (e.g., Person, Credit Card, Document) that will be manipulated

by the users of websites where the Toolkit is used. The Entity concept defines the

following attributes:

Name (string): The name of the Entity (e.g., Person);

Is Abstract (boolean): Whether the Entity is considered as abstract; default value

is False. A consequence of marking an Entity as abstract is that it cannot have

direct instances: you must define another Entity that specializes it (by using the

27


33/82

2.2. TOOLKIT

Figure 2.28: Abstract syntax for the Toolkits Domain view.

Specialization concept, described further down this text), in order to be able to

have (indirect) instances of this Entity.

Furthermore, an Entity can have a lifecycle associated with it, although this is optional.

CMS-ML allows for the explicit definition of an Entitys lifecycle by means of the States

view, which is described in Subsection 2.2.4.

An Entity is represented by drawing a rectangle figure which is horizontally divided into

two smaller rectangles. The Entitys name is written in the center of the top rectangle,

as shown in Figure 2.29a. If the Entity is abstract, then the top-right corner of the top

rectangle will also be marked with the letter A (depicted in Figure 2.29b). Also, if

the Entity has a Lifecycle defined (explained further in Subsection 2.2.4), the bottom-

-right corner of the top rectangle will be decorated with the Lifecycle symbol ,

as illustrated in Figure 2.29c. The bottom rectangle is the Attribute compartment, and

as such will be used to represent the Entitys Attributes, which will be described next.

(a) A typical, non--abstract, Entity.

(b) An abstract Entity. (c) An Entity with a de-fined Lifecycle.

Figure 2.29: Concrete syntax syntax for Entity (with no Attributes).

28


34/82

2.2. TOOLKIT

An Attribute is simply a field that belongs to an Entity. Whenever an instance of an

Entity is created, corresponding instances for its Attributes will also be created, which

will be used to store values that constitute the instances state (e.g., if a person has paid

its monthly subscription for a magazine). If we consider that an example of Entity couldbe Person, then typical Attributes for this Entity would be Name, Date of birth, or

Address. This concept defines the following attributes:

Name (string): The name of the Attribute. It cannot include the dot (.) char-

acter;

Multiplicity - Lower Bound (integer): The minimum number of actual values (of

the Attributes Type) that the Attribute must hold. If there is no lower bound,

then the asterisk character (*) should be used, instead of using some artifice to

represent this using an integer; Multiplicity - Upper Bound (unlimited natural): The maximum number of

actual values (of the Attributes Type) that the Attribute must hold. If there

should be no upper bound (i.e., the Attribute can hold an infinite set of values),

then the asterisk character should be used;

Is Identification Criteria (boolean): Indicates whether the value of this Attribute

can be used to uniquely identify the corresponding instance of the Attributes

Entity, from a set of other possible Entity instances. Default value is False.

Furthermore, each Attribute must have a certain Type, which is an indication of thekind of value to be stored and is determined by the Data Type concept. CMS-ML

defines two different kinds of Data Type, Primitive Data Types and CMS Data Types.

A Primitive Data Type is a kind of element that is usually provided by any software

system (e.g., strings, integers, dates). On the other hand, a CMS Data Type is used

to represent the identification criteria for a concrete instance of a CMS concept; as an

example, the User data type can be used to store whatever information is necessary to

uniquely identify a concrete user in the CMS system. An easy way to distinguish between

these two kinds of Data Types is that the names of CMS Data Type values always startwith an uppercase character (e.g., User), while the names of Primitive Data Type values

always start with a lowercase character (e.g., string).

CMS-ML defines the following Primitive Data Types (note the lowercase initials):

string

integer

decimal

boolean

time

29


35/82

2.2. TOOLKIT

date

enumeration

Furthermore, the following CMS Data Types (with uppercase initials) are also made avail-

able by CMS-ML:

User

Role

Dynamic WebPage

WebComponent

There are some notes and constraints regarding the definition of Attributes, namely:

There cannot be two Attributes with the same name within the same Entity;

The multiplicitys lower bound must be lower than, or equal to, the upper bound; If the Attributes multiplicity is not specified, it assumes the default value of 1

(for both lower- and upper-bound);

It is possible for more than one of the Entitys Attributes to be identification

criteria. If this happens, then instances of the Entity can be uniquely identified by

considering the values of all its identification criteria Attributes put together;

It is also possible for an Entity to not have any Attributes that are identification

criteria. In this case, it will be up to the implementors of the Toolkit to obtain

some other identification criteria for instances of the Entity (typically by addingan object ID (OID) column to a supporting database).

An Attribute is represented within the Entitys Attribute compartment, by writing

the Attributes name followed by a colon (:) and its type. Its multiplicity, if specified

and different than the default value, will be specified afterward using square brackets

([ ]). Furthermore, if the Attribute is an identification criteria, it will be represented by

appending the string (ID) to its representation. Examples of Attribute representations

are:

An Attribute called Name, of type string: Name : string; An Attribute called Date of birth, of type date: Date of birth : date;

An Attribute called CMS User, of type User: CMS User : User;

An Attribute called Preferred pages, of type Dynamic WebPage and multiplicity

between 0 (lower-bound) and infinity (upper-bound): Preferred pages : Dynamic

WebPage [0..*].

Figure 2.30 illustrates an example of an Entity with some Attributes within it. Note

that, in this example, the Name Attribute is considered as being identification criteria,

because it has the suffix (ID).

30


36/82

2.2. TOOLKIT

Figure 2.30: Concrete syntax for Entity with a set of Attributes.

An enumeration Data Type is defined in the same way as a UML Enumeration, by

specifying a set of possible values that the enumeration can assume. An enumera-

tion is also represented in a manner similar to an Entity or to an UML Enumeration,

by drawing a rectangle figure which is horizontally divided into two smaller rectangles.

The enumerations name is written in the center of the top rectangle, and the various

enumeration values are represented as simple strings in the bottom rectangle (one value

per line).

The Association concept enables, as the name suggests, the modeling of associations

between Entities. CMS-ML only supports binary associations (i.e., associations be-

tween two Entities), although the two Entities can be the same, enabling reflexive

associations. This concept only defines the following attribute:

Name (string): The name of the Association (e.g., Owns). This name is op-

tional.

Just as important as the Association concept is the Association Role concept. An

Association contains exactly two Association Roles (one for each of the associated

Entities). An Association Role is what actually links each Entity to the Association,

and determines the part that the linked Entity will play in the Association or, from

each entityE

1s perspective, the role of entityE2 in relation to itself. This concept is linked

to an Entity (typically called its related Entity), and defines the following attributes:

Name (string): The name of the Association Role. It is mandatory, and it cannot

include the dot (.) character;

Multiplicity - Lower Bound (integer): The minimum number of instances of

related Entity that this Association Role must reference2. If there should be no

lower bound, then the asterisk character (*) should be used;

2Be aware that, like in other modeling languages such as UML, each modeled concept is actually a

representation of a set of instances. Thus, it is necessary to always be aware that multiplicities arerelated to the quantity of instances, and not of the concepts themselves.

31


37/82

2.2. TOOLKIT

Multiplicity - Upper Bound (unlimited natural): The maximum number of

instances (of related Entity) that this Association Role must reference. If there

should be no upper bound (i.e., the Association Role can reference an infinite

number of instances), the asterisk character should be used; Contains Other Entity (boolean): Whether the Association carries the se-

mantics of composition. More precisely, this determines whether the Association

Roles related Entity is composed of the other Association Roles related Entity.

A consequence of this being True is that, when an instance of this Association

Roles related Entity is discarded, then the referenced instances in the other

Association Role will also be discarded. Default value is False.

Of course, it is an error for the two Association Roles within the same Association

to have their Contains Other Entity attribute with the value True (because it wouldbe impossible for an Entity to contain an Entity that contains it).

An Association is represented by drawing a line between the two Entities with its name

(if specified) written on the line. The information regarding each of its Association

Roles will also be written on the line, but at their corresponding end (i.e., near the

position of their related Entity), as illustrated in Figure 2.31a. If the Association carries

composition semantics, then the end for the Association Role that has the Contains

Other Entity attribute set to True (i.e., the end for the container Entity) will also be

represented with a small blank-filled diamond shape (depicted in Figure 2.31b, in whichinstances of Folder are composed of instances of Document).

(a) An Association and its Association Roles.

(b) An Association with composition semantics.

Figure 2.31: Concrete syntax for Association.

To avoid ambiguity in the traversal of the Toolkits Domain model, any Entity must

not have more than one opposite Association Role (i.e., an Association Role that

is located on the opposite side of the Association to which the Entity is connected)

with the same name. Figure 2.32 provides an example of a Domain model that is invalid

because of its Associations: in Figure 2.32a, Folder is associated with Document and

32


38/82

2.2. TOOLKIT

Shortcut by two Associations, and the two Association Roles that are opposite to

Folder have the same name, contents. These two associations make the Domain model

invalid, and a way to solve this problem is to assign different names to the Association

Roles related to Document and Shortcut (see Figure 2.32b).

(a) An invalid Domain model, as Foldersopposite Association Roles have the samename (contents).

(b) A valid Domain model.

Figure 2.32: Example of valid and invalid Association.

This constraint makes sense when the designer looks at Folder in Figure 2.32b, and

looks at its related Associations: the set of Documents of a Folder are known to the

Folder as its documents, while the set of Shortcuts are its shortcuts. On the other hand,

in Figure 2.32a, both Documents and Shortcuts would be known to the Folder as its

contents, making the model ambiguous.

Finally, the Specialization concept allows Toolkit Designers to specify inheritance (gen-

eralization or specialization, depending on the point of view) between two Entities, the

base and the inheritor. The specification of an inheritance hierarchy between these two

Entities allows:

The inheritor Entity to be considered as a particular case (or specialization) of the

base Entity;

The Attributes of the base Entity to also be available to the inheritor Entity.

Lifecycles are also inherited from base classes. However, an inherited Lifecycle can

be overridden, by defining a new Lifecycle in the inheritor Entity. As an example, if

a base Entity E1 defines a Lifecycle L1, and one of its inheritor Entities, E2, defines

another Lifecycle L2, then the Lifecycle for instances ofE2 will be L2; on the other

hand, ifE2 does not define a new Lifecycle, then the Lifecycle for instances ofE2 will

be L1.

It is not possible for Entities to use multiple inheritance (i.e., for an inheritor Entity

to have more than one base Entity), in order to avoid possible conflicts coming from

33


39/82

2.2. TOOLKIT

Attributes or Association Roles with the same name in different base Entities, or

from Lifecycles inherited from those different base Entities.

A Specialization is represented in the manner shown in Figure 2.33, by drawing a line

between the base and inheritor Entities, with a blank-filled arrowhead decorating the

bases end of the line.

Figure 2.33: Concrete syntax for Specialization.

2.2.4 States View

The States view is where the lifecycle of the Domain views Entities is modeled. This

is done by defining, for each Entity specified in the Domain view, a Lifecycle that will

reflect the Entitys lifecycle (as the concepts name suggests). In a manner similar to

traditional state machine modeling, this Lifecycle will consist of a set of States and

State Transitions between them. Figure 2.34 illustrates the concepts involved in the

States view and the relationships between them.

Figure 2.34: Abstract syntax for the Toolkits States view.

A Lifecycle can be considered as an aggregator for a set of States and of State

Transitions. Although the Lifecycle concept defines no attributes, it exists because

any Entity can have a lifecycle; in turn, this lifecycle has a set of properties, namely:

The State that is to be considered as the start State. When an instance of the

Entity is created, it will be in the start State.

A set of States that are to be considered as end States. These States will indicate

that the Entitys instance is no longer important to the system, and so it may be

34


40/82

2.2. TOOLKIT

discarded. Because it may be possible for an Entity to never become unnecessary

(e.g., for accountability purposes), specifying the ending State(s) is optional.

It is important to emphasize that it is not necessary for an Entity to have a Lifecycle

defined. If no Lifecycle is specified for an Entity, then the instances of that Entity

will simply exist (one of the consequences of this is that they will never be discarded).

A Lifecycle is represented by drawing a large rectangle with the symbol in its top-

-right corner, as shown in Figure 2.35a. The name of the Entity to which the Lifecycle

belongs may optionally be written in the rectangles top-left corner, as shown in Fig-

ure 2.35b. The Lifecycles States and Transitions will be represented within this

rectangle.

(a) A Lifecycle, with noEntity name shown.

(b) A Lifecycle, withits Entity name explicitlyrepresented.

Figure 2.35: Concrete syntax for Lifecycle.

A State is a concept that represents a specific stage in the Entitys lifecycle (e.g., the

State Awaiting approval can be used to represent the point in a documents lifecycle

in which it is awaiting approval by some moderator). This concept has the following

attribute:

Name (string): The name of the State (e.g., Awaiting approval). It is an error

for two States within the same Lifecycle to have the same name.

A State can be represented in one of three ways, depending on whether it is a start

State, an end State, or neither (i.e., a regular State). A regular State is represented

as shown in Figure 2.36a, by drawing a rectangle with rounded corners and writing theStates name within the rectangle. If the State is a start State, it is represented like

a regular State, but with the symbol included in its top-left corner, as depicted in

Figure 2.36b. Finally, if the State is an end State, it is also represented like a regular

State, but with the symbol included in its top-left corner (illustrated in Figure 2.36c).

On the other hand, a State Transition establishes a possible flow between two States,

the source State and the target State. This enables the specification of what States in

the Entitys Lifecycle can be reached from a particular State. The State Transition

concept defines the following attribute:

35


41/82

2.2. TOOLKIT

(a) A State. (b) An initial State. (c) A final State.

Figure 2.36: Concrete syntax for State.

Name (string): The name of the State Transition (e.g., Document approved). It

is an error for two State Transitions with the same source State and within

the same Lifecycle to have the same name.

It should be noted that, because of the semantics that are associated with an end State, it

is an error to have State Transitions with an end State as their source. It is possible,

however, to have State Transitions with a start State as their target (e.g., when a

document is returned to a set of documents to review).

A State Transition is represented by drawing a line between the source State and

the target State, with its name written on the line and an arrowhead decorating the

targets end of the line. Figure 2.37 illustrates the representation of a State Transition,

Reviewed, that occurs between the Awaiting Review and Awaiting Publication States.

Figure 2.37: Concrete syntax for State Transition.

2.2.5 WebComponents View

One of the main goals of Toolkit modeling is to allow Toolkit Designers to create new

kinds of WebComponent, directed toward supporting the user tasks that were defined in the

Tasks view. The WebComponents view enables this, by providing Toolkit Designers with

the possibility of modeling WebComponents and Support WebPages (i.e., pages that will

be used to support parts of the tasks addressed by their WebComponents) as orchestrations

of simpler elements (which CMS-ML designates as WebElements). Figure 2.38 provides

an overview of the concepts that are used in the WebComponents view.

As depicted in Figure 2.38, the most important concepts in the WebComponents view

are WebElement, WebComponent, and Support WebPage (for simplicity, throughout the

remainder of this Guide we will refer to these elements just as visual elements, because

they convey elements that users will actually see and interact with).

36


42/82

2.2. TOOLKIT

Figure 2.38: Abstract syntax for the Toolkits WebComponents view.

Modeling the WebComponents view starts with the definition of a WebComponent (often

called Toolkit WebComponent in this Guide, to distinguish between WebComponents in

the Toolkit and WebComponents in the WebSite Template). A Toolkit WebCompo-

nent is similar in theory to a WebSite Template WebComponent, and consists of a piece

of functionality to support the user tasks that have been modeled in the Tasks view (in

Subsection 2.2.2). This concept defines the following attribute:

37


43/82

2.2. TOOLKIT

Name (string): The name of the WebComponent that is being modeled (e.g., Blog,

Photo Gallery, TV Receiver).

It is important to note that the relationship between Toolkit WebComponents and Web-

Site Template WebComponents is similar to the relationship between Toolkit Roles and

WebSite Template Roles, as they are located in different conceptual levels. The only

relationship between these two WebComponent concepts is that each modeled Toolkit

WebComponent will actually be a specialization of the CMS WebComponent concept (which,

in turn, will be modeled as a concrete WebComponent in the WebSite Template). Thus,

when modeling the WebSite Template Structure view, each WebComponent will be an in-

stance of the WebSite Templates WebComponent concept presented in Subsection 2.1.1,

but it may also be a Toolkit WebComponent that supports some of the Toolkits Tasks.

However, because the Toolkit is modeled in a different conceptual level than the Web-Site Template, it is not possible to use Toolkit WebComponents and WebSite Template

WebComponents in the same model, nor is it possible (in the Toolkit WebComponents

view) to model relationships between WebComponents and CMS Structural elements.

A WebComponent is represented as a rectangle (large enough to accommodate its contained

WebElements representations), further divided horizontally into two smaller rectangles.

In the top rectangle, the WebComponents name is written on the left side, while the

symbol is placed on the right side. The WebComponents contained WebElements

will be represented within the bottom rectangle. Figure 2.39 provides an example ofa WebComponents representation (details regarding WebElement representations will be

presented shortly).

Figure 2.39: Concrete syntax for Toolkit WebComponents (with no contained WebEle-ments).

On the other hand, a Support WebPage is used to model a web page (not to be confused

with a Dynamic WebPage) that will be used to used to support a specific WebComponent

in parts of the Task(s) that it addresses (e.g., a Support WebPage can be used to edit

details regarding a certain Domain Entity). Like WebComponent, this concept defines the

following attribute:

Name (string): The name of the Support WebPage that is being modeled (e.g.,

Edit Document, Read Terms of Service).

38


44/82

2.2. TOOLKIT

Regarding implementation, Support WebPages will typically correspond to dynamic HTML

pages that receive some URL parameters and perform a specific set of activities in a work-

flow.

In a way similar to a WebComponent, a Support WebPage is represented as a rectan-

gle (large enough to accommodate its contained WebElements representations), further

divided horizontally into two smaller rectangles. In the top rectangle, the Support

WebPages name is written on the left side, while the symbol is placed on the right

side; furthermore, below the WebPages name, the string supports

is written, in which is the name of the WebComponent that

the current WebPage supports. The WebPages contained WebElements will be represented

within the bottom rectangle. Figure 2.40 provides an example of a Support WebPages

representation.

Figure 2.40: Concrete syntax for Support WebPages (with no contained WebElements).

Each WebComponent or Support WebPage can expect a set of Entity instances (from

the domain model that was defined in the Domain view) to be provided to it, in order

to perform some activities using those instances (e.g., display some information about

a certain instance of a document). This is captured by the Expected Entity concept,

which is associated to a specific Entity from the Domain view (the type of instance that

will be expected). The Expected Entity concept defines the following attribute:

Entity Name (string): A name that will be used to identify the concrete instance

of the Entity to expect (e.g., SelectedDocument). There cannot be two Expected

Entity instances with the same Entity Name and within the same WebComponent

or Support WebPage.

It is possible for a WebComponent or Support WebPage to expect more than one instance

of the same Entity: this is represented by creating multiple instances of the Expected

Entity concept, each linked to the same Entity (or to different Entities, depending on

the kind of instances expected) and with a different Entity Name. For example, if we

wanted to allow a Support WebPage to establish an association (Marriage) between two

people (i.e., two instances of the Entity Person), the Toolkit Designer would have to:

39


45/82

2.2. TOOLKIT

1. Model two instances of the Expected Entity concept, each connected to the Person

Entity from the Toolkits Domain view;

2. Assign a descriptive (but unique) Entity Name to each of those Expected Entity

instances (e.g., Husband and Wife);3. Associate those Expected Entity instances with the relevant Support WebPage.

The Expected Entity concept allows Toolkit Designers to specify activities to perform

over instances of Entities defined in the Domain view, without actually identifying

which instances should be used. In this regard, the provided Entity Name is especially

important because it will be extensively used in Bindings, as well as in the Toolkits Side

Effects view (which will be presented in Subsection 2.2.6).

An Expected Entity concept is represented as a string, in the format expects , in which the expected entities are separated by commas (,); each

expected entity is represented also as a string in the format as

. This string must be written underneath the corresponding

WebComponents or Support WebPages name. Figures 2.41a and 2.41b present examples

of representing expected entities for WebComponents and Support WebPages, respectively.

(a) WebComponent expectingtwo Domain Entity instances.

(b) Support WebPage expecting aDomain Entity instance.

Figure 2.41: Concrete syntax for Expected Entity.

In order to support users in performing Toolkit Tasks, WebComponents and Support

WebPages must contain visual elements (such as buttons, images, or text boxes) that

users will be able to see and interact with. The visual elements that are contained within

WebComponents and Support WebPages are captured by the WebElement abstract con-

cept, which represents something that will be shown in the web browser and with which

the user may be able to interact (assuming the user can access the element, as explained

in Subsection 2.2.7). This concept defines the following attributes:

Name (string): A name that will be used to identify the WebElement. Depending

on the concrete type of WebElement and on whether it is bound to an adequate

40


46/82

2.2. TOOLKIT

Binding (bindings will be explained further down this text), this may also be the

text displayed in the WebElement (e.g., the text that is displayed on a hyperlink);

Left (measure): The distance from the left border of this WebElement to the left

border of the parent visual element. Specified as a size measure, the kind of which isidentified by the values suffix (e.g., percentage is indicated by %, pixels as px,

points as pt, or other size measures that are acceptable by a web browser);

Top (measure): The distance from the top border of this WebElement to the top

border of the parent visual element, specified as a size measure;

Width (measure): The width of this Container, specified as a size measure;

Height (measure): The height of this Container, specified as a size measure.

There must be no sibling WebElements (i.e., WebElements contained within the same

WebElement Container, explained further down this text) with the same name, in orderto avoid possible misinterpretations of the model.

Furthermore, a WebElement can have a Binding, which allows it to be associated (or

bound) to specific instances of the Domain models Entities. This concept defines the

following attributes:

Entity Name (string): The name of the instance to which the resulting Binding

should refer. This name should be the same as the name of an instance of Expected

Entity. The specification of t