Download - 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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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/31/2019 CMS-ML User's Guide
7/82
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
11/82
2.1. WEBSITE TEMPLATE
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
-
7/31/2019 CMS-ML User's Guide
12/82
-
7/31/2019 CMS-ML User's Guide
13/82
2.1. WEBSITE TEMPLATE
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
-
7/31/2019 CMS-ML User's Guide
14/82
2.1. WEBSITE TEMPLATE
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
-
7/31/2019 CMS-ML User's Guide
15/82
2.1. WEBSITE TEMPLATE
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
-
7/31/2019 CMS-ML User's Guide
16/82
2.1. WEBSITE TEMPLATE
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
-
7/31/2019 CMS-ML User's Guide
17/82
2.1. WEBSITE TEMPLATE
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
-
7/31/2019 CMS-ML User's Guide
18/82
2.1. WEBSITE TEMPLATE
(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
-
7/31/2019 CMS-ML User's Guide
19/82
2.1. WEBSITE TEMPLATE
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
-
7/31/2019 CMS-ML User's Guide
20/82
2.1. WEBSITE TEMPLATE
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
-
7/31/2019 CMS-ML User's Guide
21/82
-
7/31/2019 CMS-ML User's Guide
22/82
2.1. WEBSITE TEMPLATE
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
-
7/31/2019 CMS-ML User's Guide
23/82
2.1. WEBSITE TEMPLATE
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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
-
7/31/2019 CMS-ML User's Guide
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