UNIVERSIDADE TECNICA DE LISBOA INSTITUTO SUPERIOR TECNICO

CMS-ML: CMS Modeling Language

Users Guide

Document produced by PhD Student: Joo de Sousa Saraiva (jppmssaraiva@gmail.com) (author) a PhD Supervisor: Alberto Silva (alberto.silva@acm.org)

April 2010

Contents
1 Introduction 1.1 Conventions Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 CMS-ML Elements 2.1 WebSite Template . . . . . . . . . . . . . . . . . . . 2.1.1 Structure View . . . . . . . . . . . . . . . . . 2.1.2 Roles View . . . . . . . . . . . . . . . . . . . 2.1.3 Permissions View . . . . . . . . . . . . . . . . 2.2 Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Roles View . . . . . . . . . . . . . . . . . . . 2.2.2 Tasks View . . . . . . . . . . . . . . . . . . . 2.2.3 Domain View . . . . . . . . . . . . . . . . . . 2.2.4 States View . . . . . . . . . . . . . . . . . . . 2.2.5 WebComponents View . . . . . . . . . . . . . 2.2.6 Side Eects View . . . . . . . . . . . . . . . . 2.2.7 Interaction Access View . . . . . . . . . . . . 2.2.8 Interaction Triggers View . . . . . . . . . . . 2.3 WebSite Annotations . . . . . . . . . . . . . . . . . . 2.4 Additional Aspects . . . . . . . . . . . . . . . . . . . 2.4.1 Additional Features . . . . . . . . . . . . . . . 2.4.2 Importing Toolkits . . . . . . . . . . . . . . . 2.4.3 Using Toolkit Elements In Other Toolkits . . 2.4.4 Using Toolkit Elements In WebSite Templates 1 2 3 5 6 13 15 19 20 22 27 34 36 47 52 55 57 59 59 62 63 64

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

3 Examples 66 3.1 Personal WebSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 3.2 Document Management Toolkit . . . . . . . . . . . . . . . . . . . . . . . . 70 4 Conclusion 77

List of Figures
1.1 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 2.19 2.20 2.21 2.22 2.23 2.24 2.25 The roles and artifacts considered by CMS-ML. . . . . . . . . . . . . . . . The relationship between CMS-ML models. . . . . . . . . . . . . . . . . . Metalevels considered by CMS-ML. . . . . . . . . . . . . . . . . . . . . . . The views involved in the denition of a WebSite Template. . . . . . . . . Abstract syntax for the WebSite Templates Structure view. . . . . . . . . Concrete syntax for WebSite. . . . . . . . . . . . . . . . . . . . . . . . . . Concrete syntax for Dynamic WebPages in the Macro Structure View. . . . Concrete syntax for Dynamic WebPage Child. . . . . . . . . . . . . . . . . Concrete syntax for Dynamic WebPage Template. . . . . . . . . . . . . . . Concrete syntax for Dynamic WebPage Containers. . . . . . . . . . . . . . Concrete syntax for WebComponents. . . . . . . . . . . . . . . . . . . . . . Concrete syntax for Dynamic WebPages. . . . . . . . . . . . . . . . . . . . Abstract syntax for the WebSite Templates Roles view. . . . . . . . . . . . Concrete syntax for Template Role. . . . . . . . . . . . . . . . . . . . . . . Concrete syntax for Role Delegation. . . . . . . . . . . . . . . . . . . . . . Abstract syntax for the WebSite Templates Permissions view. . . . . . . . Concrete syntax for graphical representation of Dynamic WebPage Permission. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Concrete syntax for graphical representation of WebComponent Permission. Concrete syntax for matrix representation of Dynamic WebPage Permissions and WebComponent Permissions. . . . . . . . . . . . . . . . . . . . . The views involved in the denition of a Toolkit. . . . . . . . . . . . . . . . Abstract syntax for the Toolkits Roles view. . . . . . . . . . . . . . . . . . Concrete syntax for Toolkit Role. . . . . . . . . . . . . . . . . . . . . . . . Concrete syntax for Role Specialization. . . . . . . . . . . . . . . . . . . . Abstract syntax for the Toolkits Tasks view. . . . . . . . . . . . . . . . . . Concrete syntax for Task. . . . . . . . . . . . . . . . . . . . . . . . . . . . Concrete syntax for Task Participation. . . . . . . . . . . . . . . . . . . . . ii 2 3 5 6 7 7 8 9 9 11 12 13 13 14 15 15 17 17 19 20 20 21 21 22 23 23

LIST OF FIGURES 2.26 2.27 2.28 2.29 2.30 2.31 2.32 2.33 2.34 2.35 2.36 2.37 2.38 2.39 2.40 2.41 2.42 2.43 2.44 2.45 2.46 2.47 2.48 2.49 2.50 2.51 2.52 2.53 2.54 2.55 2.56 2.57 2.58 2.59 2.60 Concrete syntax for the various kinds of Action. . . . . . . . . . . . . . . . Concrete syntax for a Task with some Actions. . . . . . . . . . . . . . . . . Abstract syntax for the Toolkits Domain view. . . . . . . . . . . . . . . . Concrete syntax syntax for Entity (with no Attributes). . . . . . . . . . . . Concrete syntax for Entity with a set of Attributes. . . . . . . . . . . . . . Concrete syntax for Association. . . . . . . . . . . . . . . . . . . . . . . . . Example of valid and invalid Association. . . . . . . . . . . . . . . . . . . . Concrete syntax for Specialization. . . . . . . . . . . . . . . . . . . . . . . Abstract syntax for the Toolkits States view. . . . . . . . . . . . . . . . . Concrete syntax for Lifecycle. . . . . . . . . . . . . . . . . . . . . . . . . . Concrete syntax for State. . . . . . . . . . . . . . . . . . . . . . . . . . . . Concrete syntax for State Transition. . . . . . . . . . . . . . . . . . . . . . Abstract syntax for the Toolkits WebComponents view. . . . . . . . . . . Concrete syntax for Toolkit WebComponents (with no contained WebElements). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Concrete syntax for Support WebPages (with no contained WebElements). Concrete syntax for Expected Entity. . . . . . . . . . . . . . . . . . . . . . Concrete syntax for Binding. . . . . . . . . . . . . . . . . . . . . . . . . . . Concrete syntax for Simple WebElement. . . . . . . . . . . . . . . . . . . . Concrete syntax for HTML WebElement. . . . . . . . . . . . . . . . . . . . Concrete syntax for WebElement Container. . . . . . . . . . . . . . . . . . Example of a Toolkit WebComponent with some contained WebElements. . Abstract syntax for the Toolkits Side Eects view. . . . . . . . . . . . . . Concrete syntax for Side Eect, the corresponding mapping, and a set of contained Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abstract syntax for the Toolkits Interaction Access view. . . . . . . . . . . Concrete syntax for WebInteractionSpace Access. . . . . . . . . . . . . . . Concrete syntax for matrix representation of Interaction Access elements. . Abstract syntax for the Toolkits Interaction Triggers view. . . . . . . . . . Concrete syntax for Trigger. . . . . . . . . . . . . . . . . . . . . . . . . . . Concrete syntax for Display On Start. . . . . . . . . . . . . . . . . . . . . Abstract syntax for the WebSite Annotations model. . . . . . . . . . . . . Concrete syntax for Annotations. . . . . . . . . . . . . . . . . . . . . . . . Abstract syntax for CMS-ML Additional Features. . . . . . . . . . . . . . . Concrete syntax for Additional CMS Feature. . . . . . . . . . . . . . . . . Concrete syntax for Additional Toolkit Feature. . . . . . . . . . . . . . . . Abstract syntax for the CMS-ML Toolkit Import mechanism. . . . . . . . . iii 26 27 28 28 31 32 33 34 34 35 35 36 37 38 39 40 43 44 45 47 47 48 52 52 54 55 56 56 57 58 59 60 61 61 62

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 The Macro Structure view of the Personal WebSite. . . . . . . . . . . . . . The Micro Structure view of the Personal WebSite. . . . . . . . . . . . . . The Roles view of the Personal WebSite. . . . . . . . . . . . . . . . . . . . The Permissions view of the Personal WebSite. . . . . . . . . . . . . . . . . The Roles view of the Documents Toolkit. . . . . . . . . . . . . . . . . . . The Tasks for the Documents Toolkit. . . . . . . . . . . . . . . . . . . . . The Domain view of the Documents Toolkit. . . . . . . . . . . . . . . . . . The States view of the Documents Toolkit. . . . . . . . . . . . . . . . . . . The Manage Documents WebComponent of the Documents Toolkit. . . . . The Edit Document Support WebPage of the Documents Toolkit. . . . . . The Interaction Access view of the Documents Toolkit Can Interact With elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.12 The Interaction Triggers view of the Documents Toolkit Trigger elements. 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 67 68 69 70 71 72 72 73 74 74 75 76

iv

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 language for 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 specic 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 dene a modeling approach per se, we consider that CMS-ML models will typically be 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 dened in the WebSite Template.

1.1. CONVENTIONS USED

Figure 1.1: The roles and artifacts considered by CMS-ML.

1.1

Conventions Used

The following conventions are assumed through the remainder of this Users Guide. CMS-MLs abstract syntax is described in this document using UML, because: (1) although the language is not based on UML, it is nevertheless possible to use UML to illustrate each of CMS-MLs metalevels; and (2) it is expected that most readers are familiar with UMLs class diagrams, due to its widespread use nowadays. When the text mentions a name with uppercase initials, it is referring to a CMS-ML concept, while a name with lowercase initials refers to a generic term. As an example, the term WebSite is used to refer to the Structure views WebSite concept in particular, while the term website is used to refer to the website or system that is being modeled. At some points in the text, when describing the representation of some concepts, the text will mention that a certain string is to be written on a certain line. This should be interpreted as writing over or near the line. The preferable way to represent those strings should be to write them over the line, but if that is not possible or convenient, the string may be placed near the line, as long as there is no doubt regarding the line to which the string belongs. It should also be noted that, for the remainder of this Guide (and for simplicity reasons), the terms website and web application are considered to be synonyms.

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 specication of CMS-based web applications in a high-level and platform-independent manner. CMS-ML modeling is mainly focused on three dierent (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 reects the intended websites structure and behavior; this Template is modeled using CMS-oriented elements such as Role, Dynamic WebPage, WebComponent that are provided 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

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 renes and/or extends functionality dened in a Toolkit 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-specic properties without polluting the Template with platform-specic details. Thus, from a practical perspective, CMS-ML designers do not view two dierent 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 dierent 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 considered as instances of the corresponding WebSite Templates concepts), Template Designers can then use those Toolkit concepts to create WebSite Templates in the same manner as when using the predened Template modeling elements. The architecture of CMS-ML illustrated in Figure 2.2 considers the following metalevels: Metalevel ML3 contains the Toolkit Modeling model, which provides the denition of the generic Toolkit modeling elements that will be used to dene Toolkit models. This metalevel cannot be changed by designers of any kind; The ML2 metalevel contains the WebSite Template Modeling and WebSite Annotations Modeling models, which provide the modeling elements that will be used to dene WebSite Template and WebSite Annotations models. Furthermore, Toolkit Designers can create instances of the generic modeling elements located in ML3, in order to dene new elements that specialize WebSite Template Modeling elements. However, like the Toolkit Modeling models in ML3, the WebSite Template Modeling and WebSite Annotations Modeling models are xed 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 dened in ML2. 4

2.1. WEBSITE TEMPLATE

Figure 2.2: Metalevels considered by CMS-ML. These elements include not only those provided by the WebSite Template Modeling and WebSite Annotations Modeling models, but also the elements dened 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 dened in the WebSite Template model (along with its decorating WebSite Annotations model, if any) to congure a particular CMS installation. This will usually require some CMS-specic 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, identies 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 dene their Templates for CMS-based websites. A WebSite Template is dened according to a set of views (illustrated in Figure 2.3), namely:

2.1. WEBSITE TEMPLATE The Structure view, which species 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 structural components.

Figure 2.3: The views involved in the denition 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 this view, 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 dened; The Micro Structure view, where the layout of each Dynamic WebPage is specied. Modeling the website begins with the Macro Structure view, more specically with the WebSite concept, which represents the system/website that is being modeled. This concept denes 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 specied (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

2.1. WEBSITE TEMPLATE

Figure 2.4: Abstract syntax for the WebSite Templates Structure view.

Figure 2.5: Concrete syntax for WebSite. After dening the WebSites name, the Template Designer will use the Dynamic WebPage concept. A WebSite contains an ordered set of at least one Dynamic WebPage; one of these Dynamic WebPages will be the websites HomePage. This set must be ordered because these Dynamic WebPages will typically be presented in a hierarchical tree mechanism, in which alphabetical sorting by the Dynamic WebPages name is often not adequate. Dynamic WebPages can themselves contain additional Dynamic WebPages (also in ordered sets) via the Dynamic WebPage Child concept, allowing Template Designers to specify a hierarchy of Dynamic WebPages for the website. The Dynamic WebPage concept denes the following attribute: Name (string): The name of the Dynamic WebPage (e.g., Home, Photo Gallery).

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 species whether the Dynamic WebPage is the WebSites HomePage (the HomePage is marked with a small ag 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 gure) and its order within the WebSite or parent Dynamic WebPage (in the lower-left corner of the gure), as shown in Figure 2.6b. Furthermore, all Dynamic WebPages are specied within the bottom rectangle of the WebSites representation (as was depicted in Figure 2.5).

(a) A Dynamic WebPage marked as the WebSites HomePage.

(b) A regular Dynamic 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 relationship 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 decorating 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 rst 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

2.1. WEBSITE TEMPLATE

Private Page are the rst 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 specication could become ambiguous. The eects 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 template 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-lled 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

2.1. WEBSITE TEMPLATE the layout and components of each Dynamic WebPage that was specied 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 rectangles. In the top rectangle, the Dynamic WebPages name is written on the left side, while is placed on the right side. The Dynamic WebPages contents (namely the symbol Containers and/or WebComponents) will be specied within the bottom rectangle. Figures 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 denes 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. Specied as a size measure, the kind of which is identied by the values sux (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, specied as a size measure; Width (measure): The width of this Container, specied as a size measure; Height (measure): The height of this Container, specied 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 duplicates, 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 WebComponent 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 denes the following attribute: Name (string): The name of the WebComponent that is being modeled (e.g., My Blog, My Photos). 10

2.1. WEBSITE TEMPLATE

Figure 2.9: Concrete syntax for Dynamic WebPage Containers. The WebSite Template perspective of CMS-ML denes 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 denes no attributes. CMS-ML denes 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 specied, as a string of characters, by the Template Designer. This concept denes 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 whenever possible, and also to only use Custom WebComponents when there are no Standard 11

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 specied, 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 dierent 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 information 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

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 Figure 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 within Body, 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, with Containers.

(b) Dynamic WebPage in Micro Structure view, 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 denes two concepts, Role and Role Delegation: the former models those expected responsibilities, while the latter species 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 specied in parenthesis): Name (string): The Roles name. There must not be two Roles with the same name; 13

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 recommended 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 responsibilities; 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 gure, as shown in Figure 2.13a. The Roles name is written below the drawn gure. 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 gure, 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 gure, as illustrated in Figure 2.13c.

(a) A Role.

typical

(b) An Administrator Role.

(c) An Anonymous 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

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 are encouraged 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 lled 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 websites structure and its roles. It denes 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

2.1. WEBSITE TEMPLATE Congure (boolean): Whether the Role can set the Dynamic WebPages CMS-dependent properties (e.g., its name or its caching time). The default value of this attribute is False; Manage Child Pages (boolean): Whether the Role can manage this Dynamic WebPages child pages, namely create new child pages or delete existing ones. The default value of this attribute is False; Manage WebComponents (boolean): Whether the Role can manage the Dynamic WebPages WebComponents (i.e., add WebComponents to it, congure the permissions of its WebComponents, or delete existing WebComponents). The default value of this attribute is False. On the other hand, a WebComponent Permission determines the actions that a Role can perform over a WebComponent. It has the following attributes (very similar to the attributes of Dynamic WebPage Permission): View (boolean): Whether the Role can view the WebComponent. The default value of this attribute is True; Congure (boolean): Whether the Role can set the WebComponents CMS-dependent properties (e.g., its name or its caching time). The default value of this attribute is False; Edit Content (boolean): Whether the Role can edit the WebComponents contents (e.g., change HTML, add new forum posts). The default value of this attribute is False. The Permissions view can be represented by two alternative manners, either a graphical manner or a set of permission matrices. The graphical manner is more adequate for conveying simpler sets of permissions, while the matrix representation enables the representation of larger sets of permissions in a more compact and ecient manner. Regarding the graphical manner, a Dynamic WebPage Permission is represented by drawing a line between the Role and the Dynamic WebPage, as shown in Figure 2.16. This line has the names of the Permissions attributes on the line, and their values are located next to their names; these values are specied with checkmarks or crosses, depending on whether the value is True or False, respectively. The names and values of the Permissions attributes (View, Configure, Manage Child Pages, and Manage WebComponents) need to be explicitly specied in the graphical model only if they are not set to their default value (e.g., if Manage Child Pages is True), otherwise they can be omitted (as illustrated in Figures 2.16b and 2.16c, which present Dynamic WebPage Permissions with some non-default values and with all-default values, respectively). In this view, Roles and Dynamic WebPages are represented with the same syntax as in the 16

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 values explicitly specied.

(b) A Dynamic WebPage Permission with some of its values explicitly specied.

(c) A Dynamic WebPage Permission with all default values (simplied representation).

Figure 2.16: Concrete syntax for graphical representation of Dynamic WebPage Permission. 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 values of 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 (although 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 its values explicitly specied.

(b) A WebComponent Permission with one of its values explicitly specied.

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

17

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 Matrix. The Page Permission Matrix is represented as a typical matrix, with: , also used in the WebSites representation in the The WebSite symbol ( 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 prexed by a checkmark or a cross (like in the graphical 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 representation 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 prexed by a checkmark or a cross (like in the graphical representation for a WebComponent Permission). As in the graphical representation, permissions that are omitted assume their default values. 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 specied 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). Figure 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

2.2. TOOLKIT

(a) A set of Dynamic WebPage Permissions in a matrix representation.

(b) A set of WebComponent Permissions in a matrix representation.

Figure 2.18: Concrete syntax for matrix representation of Dynamic WebPage Permissions and 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 of Toolkits. 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 dened 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 species 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 Eects view, which establishes the side eects 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 components (i.e., what triggers what). These views are explained in the following subsections.

19

2.2. TOOLKIT

Figure 2.19: The views involved in the denition 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 dened in the Toolkit (explained in Subsection 2.2.2). It denes 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 denes 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

2.2. TOOLKIT particular case of a Role B, and so the former can ll 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 dierent 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 the Toolkit is modeled in a dierent 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 Subsection 2.1.2), by drawing a shirt-like gure with the letter T within the gure 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-lled arrowhead decorating the bases end of the line, as shown in Figure 2.22.

Figure 2.22: Concrete syntax for Role Specialization.

One 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 carries a completely dierent set of semantics with it.

21

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 specication of the various tasks that the Toolkit should support. The most important 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 dened 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 denes 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 specications of interaction between users and the system) should be included in the rectangles top-right corner. If the goal is specied, it is written below the Tasks name, in a smaller font and not underlined, as is illustrated in Figure 2.24b. 22

2.2. TOOLKIT

(a) A Task (with no goal specied).

(b) A Task, with a goal specied.

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

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 specied in previous Actions). An Automatic Action is represented in a manner similar to a User Interaction, by drawing a rectangle (repreand writing the Actions name in the center of the rectangle. The symbol 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 denes 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 expression should be dened (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 dierent 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 ow into several other Action ows (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 gure). 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 ows (which are being performed concurrently) and joins them into a single ow. In practice, a 24

2.2. TOOLKIT Join will mean wait for all the selected concurrent Actions to nish, 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 gure 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 nished (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 dierent sizes: the larger circle is lled with white, while the smallest one is lled 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 ner-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 dene 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 in its top-left corner and the Actions Action Transitions), with the symbol name 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 Transition is a directed link between any two Actions, the source and the target, and indicates the control ow between the Tasks Actions. After a source Action is completed, the next Action to perform is determined by nding the Action Transition that has the current Action as its source and nding its target Action. An Action Transition is represented by drawing a line between the source Action and the target Action, with an arrowhead decorating the targets end of the line, as in Figure 2.26g. If the Action Transition has a condition specied (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 initial Action to be performed when the Task starts is dened 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 rst Action to be performed in a Composite Action is determined by specifying an Action Transition 25

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 specied); 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 specied); A Fork must be the source of more than one Action Transition; A Join must be target of more than one Action Transition;

26

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 specied. 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 denes 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 dene another Entity that specializes it (by using the

27

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 denition 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 gure 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 dened (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, -abstract, Entity.

non-

(b) An abstract Entity.

(c) An Entity with a dened Lifecycle.

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

28

2.2. TOOLKIT An Attribute is simply a eld 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 could be Person, then typical Attributes for this Entity would be Name, Date of birth, or Address. This concept denes the following attributes: Name (string): The name of the Attribute. It cannot include the dot (.) character; 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 artice 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 innite set of values), then the asterisk character should be used; Is Identication 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 the kind of value to be stored and is determined by the Data Type concept. CMS-ML denes two dierent 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 identication 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 start with 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 denes the following Primitive Data Types (note the lowercase initials): string integer decimal boolean time 29

2.2. TOOLKIT date enumeration Furthermore, the following CMS Data Types (with uppercase initials) are also made available by CMS-ML: User Role Dynamic WebPage WebComponent

There are some notes and constraints regarding the denition 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 specied, 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 identication criteria. If this happens, then instances of the Entity can be uniquely identied by considering the values of all its identication criteria Attributes put together; It is also possible for an Entity to not have any Attributes that are identication criteria. In this case, it will be up to the implementors of the Toolkit to obtain some other identication criteria for instances of the Entity (typically by adding an 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 specied and dierent than the default value, will be specied afterward using square brackets ([ ]). Furthermore, if the Attribute is an identication 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 innity (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 identication criteria, because it has the sux (ID). 30

2.2. TOOLKIT

Figure 2.30: Concrete syntax for Entity with a set of Attributes. An enumeration Data Type is dened in the same way as a UML Enumeration, by specifying a set of possible values that the enumeration can assume. An enumeration is also represented in a manner similar to an Entity or to an UML Enumeration, by drawing a rectangle gure 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 between two Entities), although the two Entities can be the same, enabling reexive associations. This concept only denes the following attribute: Name (string): The name of the Association (e.g., Owns). This name is optional. 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 entity E1 s perspective, the role of entity E2 in relation to itself. This concept is linked to an Entity (typically called its related Entity), and denes 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;
2

Be 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 are related to the quantity of instances, and not of the concepts themselves.

31

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 innite number of instances), the asterisk character should be used; Contains Other Entity (boolean): Whether the Association carries the semantics 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 would be 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 specied) 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-lled diamond shape (depicted in Figure 2.31b, in which instances 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

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 dierent names to the Association Roles related to Document and Shortcut (see Figure 2.32b).

(a) An invalid Domain model, as Folders opposite Association Roles have the same name (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 (generalization or specialization, depending on the point of view) between two Entities, the base and the inheritor. The specication 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 dening a new Lifecycle in the inheritor Entity. As an example, if a base Entity E1 denes a Lifecycle L1 , and one of its inheritor Entities, E2 , denes another Lifecycle L2 , then the Lifecycle for instances of E2 will be L2 ; on the other hand, if E2 does not dene a new Lifecycle, then the Lifecycle for instances of E2 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 conicts coming from

33

2.2. TOOLKIT Attributes or Association Roles with the same name in dierent base Entities, or from Lifecycles inherited from those dierent 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-lled 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 dening, for each Entity specied in the Domain view, a Lifecycle that will reect 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 denes 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

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 dened. If no Lifecycle is specied 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). in its topA Lifecycle is represented by drawing a large rectangle with the symbol -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 Figure 2.35b. The Lifecycles States and Transitions will be represented within this rectangle.

(a) A Lifecycle, with no Entity name shown.

(b) A Lifecycle, with its Entity name explicitly represented.

Figure 2.35: Concrete syntax for Lifecycle. A State is a concept that represents a specic 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 the States 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 ow between two States, the source State and the target State. This enables the specication of what States in the Entitys Lifecycle can be reached from a particular State. The State Transition concept denes the following attribute:

35

2.2. TOOLKIT

(a) A State.

(b) An initial State.

(c) A nal 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 dened 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

2.2. TOOLKIT

Figure 2.38: Abstract syntax for the Toolkits WebComponents view. Modeling the WebComponents view starts with the denition 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 WebComponent 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 denes the following attribute:

37

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 WebSite Template WebComponents is similar to the relationship between Toolkit Roles and WebSite Template Roles, as they are located in dierent 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 instance 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 dierent conceptual level than the WebSite 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 is placed on the right side. The WebComponents contained WebElements symbol will be represented within the bottom rectangle. Figure 2.39 provides an example of a WebComponents representation (details regarding WebElement representations will be presented shortly).

Figure 2.39: Concrete syntax for Toolkit WebComponents (with no contained WebElements). 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 specic 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 denes the following attribute: Name (string): The name of the Support WebPage that is being modeled (e.g., Edit Document, Read Terms of Service). 38

2.2. TOOLKIT Regarding implementation, Support WebPages will typically correspond to dynamic HTML pages that receive some URL parameters and perform a specic set of activities in a workow. In a way similar to a WebComponent, a Support WebPage 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 Support is placed on the right WebPages name is written on the left side, while the symbol side; furthermore, below the WebPages name, the string supports <WebComponent> is written, in which <WebComponent name> 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 dened 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 specic Entity from the Domain view (the type of instance that will be expected). The Expected Entity concept denes 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 dierent Entities, depending on the kind of instances expected) and with a dierent 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

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 dened 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 Eects view (which will be presented in Subsection 2.2.6). An Expected Entity concept is represented as a string, in the format expects <list of expected entities>, in which the expected entities are separated by commas (,); each expected entity is represented also as a string in the format <type of expected entity> as <name of expected entity>. 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 expecting two Domain Entity instances.

(b) Support WebPage expecting a Domain 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 concept, 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 denes 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

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. Specied as a size measure, the kind of which is identied by the values sux (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, specied as a size measure; Width (measure): The width of this Container, specied as a size measure; Height (measure): The height of this Container, specied 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 order to avoid possible misinterpretations of the model. Furthermore, a WebElement can have a Binding, which allows it to be associated (or bound ) to specic instances of the Domain models Entities. This concept denes 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 specication of this value is optional if the WebElement is already within a Binding, because the Entity instance to which the WebElement is bound will be inherited from its outer binding context; Binding Path (string): A set of names, concatenated by dots (.), that navigate through the elements dened in the Domain view and establish a binding context. This path should start with a dot, referring to the Entity instance identied by Entity Name or if no such instance was specied the instance that is inherited from the outer context. The following kinds of context can be specied: No value: if no value is specied for this attribute, the Binding will refer the Entity indicated by Entity Name (or to the Entity that was inherited from the outer context); <path to Domain instance>.<Attribute name>: if a path of this kind is used, in which <path to Domain instance> leads to a Domain instance of type E1 and <Attribute name> is an Attribute of E1 , the Binding will refer to that Attribute; <path to Domain instance>.<Association Role name> (in which <path to Domain instance> leads to a Domain instance of type E1 and <Association

41

2.2. TOOLKIT Role name> corresponds to an Association Role AR1 opposite to E1 in an Association A1 ): If A1 connects the Entity E1 to a set of elements of another Entity E2 (i.e., AR1 has non-default multiplicity), the Binding will refer to that set of elements of E2 ; If A1 connects the Entity E1 to a single element of another Entity E2 (i.e., AR1 has default multiplicity), the Binding will refer to that E2 element (and not to a set of elements of E2 ). Is Dummy (boolean): Indicates that this Binding will not actually bind to anything (i.e., the Binding will be invalid), and is just used when the specication of some Binding is performed (e.g., for a List Box) but it is not possible to actually provide all of those Bindings in a valid manner (e.g., because the values to be bound were not modeled). This allows designers to ignore the WebElements current Binding without having to specify another such context. The default value is False. It is important to note that the Binding for a WebElement can be reset at any time, by explicitly specifying a value for the Bindings Entity Name attribute. Otherwise, as already mentioned, the Binding will inherit the Entity instance from the Binding that contains it. Nevertheless, whether the Bindings that were specied before the Binding reset will actually be ignored or not varies by WebElement (according to the WebElement descriptions provided next). Finally, it is not fundamental that the Toolkit Designer dene Bindings as, depending on tool support, these Bindings are oriented mainly toward helping Toolkit Designers to determine whether the necessary information (i.e., expected Entities) is being provided to the WebComponent or Support WebPage. A Binding is represented as a string, in the format bound to <Entity Name> <Binding Path>; if the Entity is not specied (as it may be inherited from an outer binding context), the <Entity Name> will be left blank. If the IsDummy property is True, the Binding will be represented as bound to nothing. This string must be written underneath the corresponding WebElements name. Figure 2.42 provides an example of a Bindings representation (the Entity Name being station and the Binding Path .schedule). There are some kinds of WebElements that are both simple (i.e., they have relatively simple semantics) and frequently found when designing websites or web applications. These elements are captured in CMS-ML by the Simple WebElement concept, which

42

2.2. TOOLKIT

Figure 2.42: Concrete syntax for Binding. consists of a WebElement with a predened type. CMS-ML denes the following types of Simple WebElement: Button Link Image Text Text Input Box List Box Selection Box

Each of these types will correspond to a specic browser element, and may be able to interpret a Binding (or set of Bindings) in which it is inserted. The following list denes what each Simple WebElement Type corresponds to, its required Binding if any , and the possible kinds of Binding to which it can be bound: Button A typical browser button. Can not be bound to any Binding; Link A hyperlink. It can be bound to an Attribute, in which case the Attributes value will be shown as the hyperlinks text; Image An image. It can be bound to an Attribute, in which case the images path will be determined by the value of the Attribute; Text A piece of text. It can be bound to: An Attribute, in which case the text displayed will be determined by the value of the Attribute; An Entity, in which case the displayed text will be the values of all of the Entitys Attributes, using a CMS-specic format. Text Input Box A text box into which the user can insert a value. It can be bound to an Attribute, in which case the value of the text box will be determined by the Attributes value. This binding is unidirectional, in the sense that values specied by the user in the text box will not be automatically propagated to the Attributes value;

43

2.2. TOOLKIT List Box An HTML select element that will show multiple options at the same time. In order for the List Box to be bound, it must be placed within a Binding that species an Attribute AT T R1 belonging to an Entity E2 , in which E2 denotes a set of elements. In other words, the binding path must be like <path to Domain instance E1 >.<path to set of Domain instances E2 >.<Attribute name>. The selected value(s) will be determined by the value(s) of AT T R1 or AS1 . Selection Box An HTML select element that operates in a manner very similar to the List Box WebElement, but will show only a single option at any given moment, and will only allow the selection of a single value. Because of these facts, AT T R1 or AS1 (whichever is specied) cannot support multiple values. Note that, if the Simple WebElement is placed within a Binding to which it cannot be bound, that Binding will be ignored by the Simple WebElement. Furthermore, it is not necessary to place a Simple WebElement within a Binding. Simple WebElements are represented by drawing a rectangular shape: the type is specied in the right side of the rectangle (within a smaller rectangle represented using a dashed line style), while its name is represented in the left side of the rectangle. Figure 2.43 provides an example of a Simple WebElements representation.

Figure 2.43: Concrete syntax for Simple WebElement. An HTML WebElement is simply a WebElement that will correspond to a piece of HTML manually specied by the Toolkit Designer. Due to its HTML-based nature, this concept cannot be used as a container for other WebElements. This kind of WebElement will not use Bindings (any congured Bindings in which this WebElement is located will be ignored). It denes the following attribute: HTML (string): The HTML string that this WebElement will correspond to (e.g., <span>Hello!</span>). HTML WebElements are represented by drawing a rectangular shape, which is further divided horizontally into two smaller rectangles. The top rectangle is very similar to the representation of a Simple WebElement, as the type is specied using the string HTML in the right side of the rectangle (within a smaller rectangle represented using a dashed line style), while its name is represented in the left side of the rectangle. Finally, the bottom rectangle will contain the HTML. Figure 2.44 illustrates the representation of an HTML WebElement.

44

2.2. TOOLKIT

Figure 2.44: Concrete syntax for HTML WebElement. Finally, it is possible to dene WebElements that can contain other WebElements. These are modeled by using the WebElement Container concept, a kind of WebElement that serves as a container for other WebElements and is used to organize semantically related WebElements. A WebElement Container must contain other WebElements, and it is an error to have an empty WebElement Container. CMS-ML denes the following types of WebElement Container: Normal Popup List Table Binding

Each of these types (except for Binding) will correspond to a specic browser element, and may be able to interpret a Binding element in which it is inserted. The following list denes what each WebElement Container Type corresponds to, the possible kinds of Binding to which it can be bound, and the Binding that it can establish for the WebElements that it contains: Normal A typical browser division (usually a div HTML element). Popup A container that will act as a popup window, and will not be seen by users when viewing the visual element where this container is placed. Besides this popup behavior, there are no dierences between a Popup WebElement Container and a Normal WebElement Container; List A container that will display a set of Entity E1 instances as a list of entries, in a non-tabular manner. It contains other WebElements (typically a set of Simple WebElements) that determine the way in which each entry will be displayed, and is ordered by a left-to-right, top-to-bottom approach. This element establishes, for its contained WebElements, a Binding for a single instance of E1 . There are two ways to display the details of E1 : If a WebElement within the List is bound to an Attribute A1 (either of E1 or of an associated Entity E2 ), that WebElement will only display the value of A1 ; 45

2.2. TOOLKIT Otherwise, if a WebElement within the List does not provide a Binding, all the Attribute values of E1 will be displayed in the WebElement, using a CMS-specic format. It is an error for a WebElement (other than a container) within a List to have a Binding referring something other than an Attribute (in order to display that Attributes value) or nothing at all (to display all details of the Entity in its Binding). If the Lists Binding is invalid or not specied (because no Bindings have been established in the WebComponent or Support WebPage), this container along with its contained WebElements will just indicate that a list with a certain structure should be displayed. Table A container that will also display a set of Entity E1 instances, like List, but as a list of table rows. The dierence between a Table container and a List container is the manner in which they display information, as WebElements contained within the Table will correspond to columns in the resulting table. Other than that, they operate in the same manner, expecting and establishing exactly the same kinds of Binding. Binding A container that is only used to establish new Bindings (or rene the Binding in which it is inserted). Other than this purpose, this container has no other purpose or function, and will not be displayed to users (but its contents will, obviously). As is the case for Simple WebElements, if the WebElement Container is placed within a Binding to which it cannot be bound, that Binding will be ignored by the Container. Furthermore, it is not necessary to place a WebElement Container within a Binding. A WebElement Container is represented by drawing a rectangular shape, further divided horizontally into two smaller rectangles. The top rectangle is again similar to the representation of a Simple WebElement, as the type is specied in the right side of the rectangle (within a smaller rectangle represented using a solid line style), while its name is represented in the left side of the rectangle. Finally, the bottom rectangle provides a canvas (much like the bottom rectangle of the Dynamic WebPage, in the WebSite Templates Micro Structure view) in which the contained WebElements are represented: the graphical position and size of the contained WebElements will be determined by their Left, Top, Width, and Height attribute values. This same canvas representation principle also applies to Toolkit WebComponents and Support WebPages, as contained WebElements are represented in their respective bottom rectangles. Figure 2.46 provides an example of a WebComponent representation containing some WebElements (which have already been represented in the previous gures).

46

2.2. TOOLKIT

Figure 2.45: Concrete syntax for WebElement Container.

Figure 2.46: Example of a Toolkit WebComponent with some contained WebElements.

2.2.6

Side Eects View

The Side Eects view allows Toolkit designers to specify a set of side eects that will take place when some event occurs. Such events can be Action Transitions or even clicks on a WebElement. Figure 2.47 depicts the concepts that are relevant to the Side Eects view. The primary concept in this view is the Side Effect. A Side Eect is an ordered set of eects (or Operations) that will take place when a specied event occurs. Possible events that CMS-ML considers as being able to trigger side eects are: Occurrence of an Action Transition (dened in the Tasks view); Beginning (or entering) an Action; Occurrence of a State Transition (dened in the States view); An event occurs over a WebElement. Possible events are dened by Side Eect Trigger Type (default value is Default): 47

2.2. TOOLKIT

Figure 2.47: Abstract syntax for the Toolkits Side Eects view. Click, for when a user clicks on the WebElement; View, for when the WebElement is presented in the users screen; and Default, for when the user either clicks or views the WebElement, depending on its kind (WebElements that are, by their nature, interactive e.g., buttons will use the value Click, while non-interaction WebElements such as HTML will use View). The mapping between a Side Effect and an event is established by either the WebElement Side Effect Connection, Action Side Effect Connection, or Event Side Effect Connection concepts, depending on the kind of event itself. Although the typical usage scenario will see any Side Effect being associated to only one element (an event, a WebElement, or an Action), it is possible for a Side Effect to be associated with several such elements, by establishing a corresponding number of side eect mappings for the same side eect. An Operation is the basic unit of side eects that will take place. CMS-ML denes the following types of Operation (also illustrated in Figure 2.47): Create Entity Delete Entity Establish Association Remove Association 48

2.2. TOOLKIT Change Value Trigger Transition Other A Create Entity operation species the creation of a new instance of a Domain Entity. This operation denes the following attributes: Entity Type Name (string): The name of the Entity to instantiate. This must be the name of an Entity that was dened in the Domain view; New Name (string): The name to assign to the new instance. This instance then becomes available in the binding context of the WebElement, if any, that has directly or indirectly triggered this operation. A Delete Entity operation species the removal or destruction of an instance. This operation denes the following attribute: Entity Name (string): The name of the instance to destroy. This name must be present in the binding context of the WebElement, if any, that has triggered this operation. An Establish Association operation means the creation of an instance of an Association between two instances of Entities (E1 and E2 ) in the Domain view. This operation denes the following attributes: Association Type Name (string): The name of the Association to instantiate. This must be the name of an Association that was dened in the Domain view; First End Entity Name (string): The name of the instance E1 to place in the rst end of the association. This name must be present in the binding context of the WebElement, if any, that has triggered this operation; First End Association Role Name (string): The name of the Association Role to assign to E1 . This role must belong to the Association mentioned in Association Type Name; Second End Entity Name (string): The name of the instance E2 to place in the second end of the association. This name must also be present in the binding context of the WebElement, if any, that has triggered this operation. It is possible for E1 to be the same instance as E2 ; Second End Association Role Name (string): The name of the Association Role to assign to E2 . This role must also belong to the Association mentioned in Association Type Name.

49

2.2. TOOLKIT A Remove Association operation species the removal of an instance of an Association between two Entity instances (E1 and E2 ). This operation denes the following attributes: Association Type Name (string): The name of the Association whose instance should be removed. This must be the name of an Association that was dened in the Domain view; First End Entity Name (string): The name of the instance E1 that is placed in the rst end of the association. This name must be present in the binding context of the WebElement, if any, that has triggered this operation; First End Association Role Name (string): The name of the Association Role to which E1 is assigned. This role must belong to the Association mentioned in Association Type Name; Second End Entity Name (string): The name of the instance E2 that is placed in the second end of the association. This name must also be present in the binding context of the WebElement, if any, that has triggered this operation. It is possible for E1 to be the same instance as E2 ; Second End Association Role Name (string): The name of the Association Role to which E2 is assigned. This role must also belong to the Association mentioned in Association Type Name. A Change Value operation species the changing of a value in an Attribute A1 of a Domain Entity E1 . This operation denes the following attributes: Entity Name (string): The name of the instance E1 where A1 s value is to be changed. This name must be present in the binding context of the WebElement, if any, that has triggered this operation; Attribute Name (string): The name of the Attribute A1 whose value is to be changed. This must be the name of an Attribute in Entity E1 ; New Value (string): The new value to assign to the Attribute. A Trigger Transition operation species the triggering of a State Transition T1 in an Entitys Lifecycle L1 . This operation denes the following attributes: Entity Name (string): The name of the instance that contains L1 , containing the State Transition to be triggered. This name must be present in the binding context of the WebElement, if any, that has triggered this operation; Source State Name (string): The name of the State that is the source of T1 . This must be specied because most Action Transitions will usually be name-less (and also, there may be more that one Transition, in the same Lifecycle, with the same name); 50

2.2. TOOLKIT Transition Name (string): The name, if any, of the State Transition T1 to be triggered. Finally, a Other operation species a side eect that cannot be specied by any of the other operation types that have been described above. This operation only denes the following attribute: Description (string): The natural-language description of the eect to take place. Any Operation is represented using a purely textual notation, which varies according to the Operations concrete sub-type. It is important to note that each operation is ended with a semicolon (;), in order to avoid possible ambiguity between a set of Operations within the same Side Effect. The representations of Operations concrete sub-types is as follows (the operations attribute values are inserted in the section marked as <attribute name>): Create Entity: Create instance of <EntityTypeName> called <NewName>;; Delete Entity: Destroy <Object>;; Establish Association: Establish <AssociationTypeName> having <End1 Object> as <End1 AssociationRoleName> and <End2 Object> as <End2 AssociationRoleName>; (if the Association does not have a name, then <AssociationTypeName> will be replaced by Association); Remove Association: Remove <AssociationTypeName> between <End1 Object> as <End1 AssociationRoleName> and <End2 Object> as <End2 AssociationRoleName>; Trigger Transition: Trigger <SourceStateName>.<TransitionName> in <Object>; (if the Transition does not have a name, then <TransitionName> will be replaced by Transition); Change Value: Change value of <AttributeName> in <Object> to <NewValue>;; Other: The representation is simply the value of the Description attribute, terminated by a semicolon (;). The semicolon character itself cannot be a part of the Descriptions value.

51

2.2. TOOLKIT A Side Effect is represented as a square bracket that contains the representations of its Operations. On the other hand, a mapping connection (regardless of whether it is a Event Side Effect Connection, Action Side Effect Connection, or WebElement Side Effect Connection) is represented as a line connecting the element and the Side Effect. If the mapping is a WebElement Side Effect Connection, the trigger type (View, Click, or Default) is also represented over the line; nevertheless, if the trigger type is Default, it is not necessary to represent it in the line. Figure 2.48 provides an example of a Button that has a side eect (with the trigger type Click); this side eect contains two operations, of type Create Entity and Change Value.

Figure 2.48: Concrete syntax for Side Eect, the corresponding mapping, and a set of contained Operations.

2.2.7

Interaction Access View

The Interaction Access view is used to establish a mapping between the WebComponents and Roles views. More concretely, it enables the specication of mappings between Roles and the visual elements (WebElements, WebComponents, and Support WebPages) with which they can interact, by means of its two concepts, WebElement Access and WebInteractionSpace Access. Figure 2.49 provides an overview of the concepts involved in this view.

Figure 2.49: Abstract syntax for the Toolkits Interaction Access view. The WebElement Access is used to specify Toolkit RoleWebElement access permissions, and is used to indicate which WebElements the Role can interact with. This concept denes the following attributes (or actions): 52

2.2. TOOLKIT View (boolean): Whether the Role can see the WebElement (i.e., if the WebElement is visible). The default value of this attribute is True. If this is set to False, then users with that Role will not be able to see the WebElement; Use (boolean): Whether the Role can interact with the WebElement (e.g., by clicking or dragging). The default value of this attribute is True. If this is False, then users with that Role will be able to see the WebElement unless the View attribute is also set to False but it will be disabled (e.g., a disabled button). On the other hand, the WebInteractionSpace Access is used to specify Toolkit Role WebInteractionSpace access permissions (concretely, RoleWebComponent and Role Support WebPage access), and is used to indicate which WebInteractionSpaces the Role can access. This concept denes the following attribute: View (boolean): Whether the Role can view the visual element. The default value of this attribute is True. If this is set to False, then users with that Role will not be able to access the visual element (and any attempted accesses will result in an empty response or an Access denied-like message). It should be noted that it is possible (and common) for CMS users to have several CMS roles assigned to them. Thus, it is possible for such permissions to conict with one another for a specic user in a WebSite Template. If a user has two (or more) CMS Roles that are also Toolkit Roles, and those Roles have conicting access specications (dened with either WebElement Access or WebInteractionSpace Access), then an optimistic perspective will be assumed: if the user has at least one Role that (1) has an access relationship with the visual element, and (2) has the conicting attribute value set to True, then the users permission over that visual element will have the value True; otherwise, the permission will have the value False. In other words, the nal result for a users access permissions over a visual element follows a logic based on the OR-operator. WebElement Access and WebInteractionSpace Access are both represented in the same manner, by drawing a line between the Role and the visual element, with the attribute values written on the line (in a manner very similar to Permissions from the WebSite Templates Permissions view), as presented in Figure 2.50. The values are specied with checkmarks or crosses, depending on whether the value is True or False, respectively. The names and values of the attributes (View and Use) need to be explicitly specied in the graphical model only if they are not set to their default value (e.g., if Use is False), otherwise they can be omitted. In this view, Roles and visual elements are represented with the same syntaxes as in the Roles and WebComponents views, respectively. WebComponents, however, are represented as small rectangular boxes, in a manner very

53

2.2. TOOLKIT similar to WebComponents in the WebSite Templates Micro Structure view (the dierence is that the WebComponents top-right corner is lled with the letter T).

Figure 2.50: Concrete syntax for WebInteractionSpace Access. The WebElement Access and WebInteractionSpace Access elements can also be represented by matrices. This representation consists of: A matrix containing the mappings between the Toolkits Roles and WebComponents, called the WebComponent Interaction Matrix ; For each WebComponent, a matrix containing the mappings between the Roles and the WebComponents Support WebPages, called the Support WebPage Interaction Matrix ; and For each WebComponent and each Support WebPage, another matrix containing the mappings between the Roles and the contained WebElements, called the WebElement Interaction Matrix. The WebComponent Interaction Matrix (used to dene WebInteractionSpace Access elements between Roles and WebComponents) is represented as a typical matrix, with: (also used in the WebComponents representation in the WebCom The symbol ponents view) in the matrixs top-left corner; The Toolkits Roles providing the columns; The WebComponents providing the lines; and The value of the View represented as a checkmark or a cross (like in the graphical representation of a WebInteractionSpace Access). The Support WebPage Interaction Matrix (for dening WebInteractionSpace Access elements between Roles and the Support WebPages of a WebComponent) is also represented as a matrix, with: The The The The The WebComponents name on top of the matrix; Support WebPage symbol ( ) in the matrixs top-left corner; Toolkits Roles providing the columns; WebComponentss Support WebPages providing the lines; and actions values represented as a checkmark or a cross.

Finally, the WebElement Interaction Matrix (used to dene WebElement Access elements between Roles and WebElements) is also represented as a matrix, with: 54

2.2. TOOLKIT The The The The name of the WebComponent (or Support WebPage) on top of the matrix; Toolkits Roles providing the columns; WebElements providing the lines; and actions values represented as a checkmark or a cross.

As in the graphical representation, actions that are omitted assume their default values. Figure 2.51a shows a set of WebInteractionSpace Access and WebElement Access elements in the matrix format: for the represented WebComponents, the access permissions for RegularRole are set to the default values in the top-left cell (because they are not specied) and to explicitly allow access in the bottom-left cell, but ManagerRole is explicitly allowed to access any of the WebComponents. Figures 2.51b and 2.51c also show WebInteractionSpace Access and WebElement Access elements (respectively).

(a) A set of WebInteractionSpace Access elements between Roles and WebComponents.

(b) A set of WebInteractionSpace Access elements between Roles and Support WebPages.

(c) A set of WebElement Access elements between Roles and WebElements.

Figure 2.51: Concrete syntax for matrix representation of Interaction Access elements.

2.2.8

Interaction Triggers View

The Interaction Triggers view is used to establish a mapping between the WebComponents and Tasks views. More concretely, mappings between: WebElements and the Tasks that they will initiate, or the Action Transitions that they will trigger; Task Actions and the visual elements that they should be displayed on. Figure 2.52 provides an overview of the concepts involved in the Interaction Triggers view.

55

2.2. TOOLKIT

Figure 2.52: Abstract syntax for the Toolkits Interaction Triggers view. The Trigger concept consists of a relationship between a WebElement (such as a button) and either a Task or an Action Transition (that is dened within a Task). It allows Toolkit Designers to specify that interaction with the WebElement will trigger some event (depending on the element to which the Trigger relationship is connecting the WebElement): If the WebElement is connected to a Task, interaction will initiate the Task; Otherwise, if the WebElement is connected to an Action Transition, interaction will cause the Action Transition to be triggered (and thus the Tasks current Action will ow to the next Action). A Trigger has a certain type, which is dened by the Trigger Type concept. This concept indicates the kind of interaction (between the user and the WebElement) that must occur in order to trigger the event. There are two kinds of trigger type, View and Click: the former indicates that merely viewing the WebElement is enough to trigger the event, while the latter indicates that the user must click on the WebElement (or take a similar action) in order to trigger the event. A Trigger is represented as a line between the WebElement and the Task or the Action Transition, with the word triggers written below the line, and the Trigger Type written above it. Figure 2.53 illustrates the representation of a Trigger (between a Button and a Task), in which a users click over the WebElement will lead to an execution of the Task.

Figure 2.53: Concrete syntax for Trigger.

56

2.3. WEBSITE ANNOTATIONS Finally, the Display On Start concept is used simply to indicate that, when its associated Action is started, a certain visual element must be displayed to the user (specic details, such as which instance of the WebComponent will be displayed, are left for the CMS to decide). It will be up to the CMS to determine what are the necessary steps to display that visual element (e.g., it may be necessary to navigate to a dierent URL, display a popup window, or scroll to a dierent part of the HTML page). A Display On Start is represented as a line between the Action and the visual element, with the word display written over the line. Figure 2.54 provides an example of a Display On Starts representation, in which the Text Input Box will be displayed when the User Action starts.

Figure 2.54: Concrete syntax for Display On Start.

2.3

WebSite Annotations

As was mentioned, the WebSite Annotations model allows designers to add annotations (representing tags, properties, or general constraints) to a WebSite Template. These annotations can convey any kind of information, such as content conguration options (e.g., a tag Allows Content Subscription applied to a WebComponent can indicate that the WebComponent should provide readers with an RSS feed or similar) or platform-specic deployment data. Unlike Additional Features (which are explained in Subsection 2.4.1), these annotations are supposed to be interpreted by the CMS system in which the model is deployed. The most important concept of this model is the Annotation, which denes only the following attribute: Name (string): The Annotations name. This is a string that will be recognized by the target CMS, if any; thus, there are no restrictions to this name, except for characters such as newlines or other restrictions that the target CMS imposes. Figure 2.55 illustrates the relationship between the various concepts considered by the WebSite Annotations model. Annotation is specialized by various other concepts in this model. The most commonly used is likely the Generic Annotation, which can be associated with any CMS Element 57

2.3. WEBSITE ANNOTATIONS

Figure 2.55: Abstract syntax for the WebSite Annotations model. (from which all WebSite Template modeling elements inherit, as described later in Subsection 2.4.1). Furthermore, for each WebSite Template modeling element E dened (e.g., WebComponent, Role), CMS-ML also denes an annotation element called E Annotation, which can only be associated with instances of E. In other words, a Role Annotation can only be applied to a Template Role, but not to a WebComponent; the only Annotation that can be applied to elements of dierent kinds is a Generic Annotation. An Annotation (either generic or specic to a Template element) is represented as a string, in the format <<Name>>, which is placed immediately above the representation of the associated Template element. If the same Annotation is associated to multiple Template elements, it will be represented as several dierent strings (although they all correspond to the same Annotation element instance). Furthermore, if several Annotations are applied to the same Template element, they will be represented in a stacked manner (i.e., one representation on top of another). Figure 2.56 illustrates an example of an Annotations representation; more specically, an annotation Allows Content Subscription is applied to a Standard WebComponent (of type Forum).

58

2.4. ADDITIONAL ASPECTS

(a) An Annotation of a Standard WebComponent.

(b) An Annotation of a WebSite.

Figure 2.56: Concrete syntax for Annotations. Finally, it should be mentioned that the WebSite Annotation model decorates a WebSite Template, allowing designers to specify CMS-specic properties without polluting the Template with platform-specic details. Thus, from a practical perspective, WebSite Template designers do not view two dierent models (the Template and the Annotations), but rather a single model that results from composing those two models (i.e., a model that is the result of extending the Template with the Annotations); this is the perspective that is also conveyed by Figure 2.56.

2.4

Additional Aspects

Most of the modeling elements of CMS-ML have been presented. However, some topics must still be explained, namely: The handling of desired features which cannot be modeled using the language; How to import Toolkit(s) into a WebSite Template; How to use imported Toolkit elements in a WebSite Template.

2.4.1

Additional Features

Although the modeling elements presented so far allow the modeling of most kinds of CMS-based websites, CMS-ML is too high-level (and lacks the expressiveness) to be able to address particular issues, such as the implementation of algorithms. This is to be expected, as the objective of CMS-ML is not to model such details, but nevertheless such desired features should not simply be ignored. To address this issue, CMS-ML provides some concepts, CMS Feature and Toolkit Feature, which consist of small textual descriptions of desired features or requirements

59

2.4. ADDITIONAL ASPECTS that the Template Designer or Toolkit Designer (respectively) were unable to model adequately with CMS-ML, due to the languages lack of expressiveness. These feature descriptions can be associated with any of the modeling elements that have been presented so far (except for Annotations). Figure 2.57 illustrates how these Feature concepts are related to other elements in the CMS-ML language.

(a) The Additional CMS Feature concept.

(b) The Additional Toolkit Feature concept.

Figure 2.57: Abstract syntax for CMS-ML Additional Features. As was mentioned, the CMS Feature concept consists simply of a textual description for some desired feature in the website being modeled, and denes a single attribute: Description (string): The features description, written in natural language. The Additional CMS Feature is a simple concept that is used to establish a relationship between a CMS Feature and a CMS Element, from which all modeling elements in WebSite Template modeling inherit. Due to these concepts, it is possible for any of the modeling elements presented in Section 2.1 to be associated with one or more (additional) CMS Features. CMS Features are represented by drawing a rectangle, with its top-right corner bent and the string FTR (short for Feature) written on its top-right corner. The features description is written within the rectangle gure. Additionally, an Additional CMS Feature is represented by drawing a line between the CMS Feature and the CMS Element to which it pertains. Figure 2.58 provides an example of how to represent a CMS Feature (and its corresponding Additional CMS Feature connection), which in this case is associated with a Custom WebComponent and denes some particular details of how the WebComponent should behave. The Toolkit Feature and Additional Toolkit Feature concepts are very similar to CMS Feature and Additional CMS Feature (respectively), as they have nearly the same meaning. Nevertheless, it is important to take into account the fact that they are located 60

2.4. ADDITIONAL ASPECTS

Figure 2.58: Concrete syntax for Additional CMS Feature. on dierent conceptual levels. Furthermore, an Additional Toolkit Feature establishes a relationship between a Toolkit Feature and a Toolkit Element, from which all Toolkit modeling elements inherit, and so any of the modeling elements presented in Section 2.2 can be associated with one or more Toolkit Features. The representation of these elements is done in the same manner as their WebSite Template counterparts. An instance of Toolkit Feature is represented by drawing a rectangle with a bent top-right corner, the string FTR written on its top-right corner, and the features description written within the rectangle gure. An Additional Toolkit Feature is represented by drawing a line between the Toolkit Feature and the Toolkit Element to which it pertains. Figure 2.59 provides an example of how to represent a Toolkit Feature, which in this case is associated with a Toolkit Role and denes a particular detail that should be considered when creating an instance of that Toolkit Role.

Figure 2.59: Concrete syntax for Additional Toolkit Feature. The main motivation for providing these Additional Feature concepts is to allow Template Designers and Toolkit Designers to follow a model specication workow in which: (1) they design the model and make it as detailed and correct as allowed by the language; and (2) when CMS-ML is not expressive enough to specify some aspect(s) of the intended web application, they add new Additional Features that should be addressed, in order to comply with the web applications requirements (which should be established before modeling the target system). These Additional Features could also be compared to 61

2.4. ADDITIONAL ASPECTS Scrums Product Backlog items, which are the set of all features, requirements, and xes that must be made to future versions of the product. Furthermore, although it might seem that specifying such feature-request modeling elements in the model is useless (because they cannot be addressed), the idea is for these elements to serve as reminders in other (semantically equal) models. Such models will likely be specied using other modeling languages, which will be more or less expressive than CMS-ML, and thus may be able to address those requirements.

2.4.2

Importing Toolkits

Toolkits can be used by WebSite Templates, or even by other Toolkits, by using the Toolkit Import concept. This concept consists of a relationship between a Toolkit (the imported Toolkit) and either a WebSite Template or a Toolkit (the importer ). This Toolkit Import concept is actually a set of two such concepts: one at the WebSite Template level (connecting a WebSite to a Toolkit, identied only by name) and the other at the Toolkit level (connecting a Toolkit to another Toolkit, also by name). Figure 2.60 illustrates how these concepts are related to WebSite Templates and Toolkits.

(a) The Toolkit Import for a WebSite Template.

(b) The Toolkit Import for a Toolkit.

Figure 2.60: Abstract syntax for the CMS-ML Toolkit Import mechanism. A Toolkit Import (in both WebSite Template and Toolkit models) is represented by drawing a dashed line between the imported Toolkit and the importer, with the string import written on the line, and an arrowhead decorating the imported Toolkits end of the line, as depicted in Figure 2.61. In the WebSite Template model, the WebSite is represented by using the same syntax as for the Macro Structure view, and the imported Toolkit is represented simply as a rectangle with the Toolkits name written inside it (see Figure 2.61a). On the other hand, in the Toolkit model, both Toolkits (the current Toolkit and the imported one) are represented as rectangles with their names written inside them (see Figure 2.61b). The Toolkit Import relationship is transitive. Thus, if a Toolkit T1 imports Toolkits T2 and T3 , and a WebSite Template W ST1 imports T1 , then W ST1 will also automatically import T2 and T3 (without the need for the WebSite Template Designer to explicitly specify that T2 and T3 should be imported by W ST1 ). 62

2.4. ADDITIONAL ASPECTS

(a) Representation of Toolkit Import for a WebSite Template.

(b) Representation of Toolkit Import for a Toolkit.

Figure 2.61: Concrete syntax for Toolkit Import elements. However, the imports for each Toolkit must be done specically in that Toolkits model; in other words, if we are modeling Toolkit Z which imports Toolkit A, and Toolkit A imports Toolkit B, As import of B must not be represented in Zs model, but rather in As model.

2.4.3

Using Toolkit Elements In Other Toolkits

As was previously mentioned, a Toolkit can import other Toolkits (via the Toolkit Import concept, presented in Subsection 2.4.2). When a Toolkit T1 is imported into a Toolkit T2 , the elements in T1 s following views become available for T2 : T1 s T1 s T1 s T1 s Roles view; Domain view; States view; Tasks view.

These imported elements of T1 can be used just like T2 s own elements (although they cannot be changed ), and imported elements are represented in the same manner as the current Toolkits own elements. There are a few caveats to consider when using these elements: When representing these imported elements, their names must be written in the form <Toolkit name>::<Element name> (to avoid ambiguity in cases where two dierent Toolkits dene some elements with the same name); Imported Domain elements (e.g., Entities) cannot be changed, but they can be rened through Specialization and can participate in Associations; Because of the issue regarding imported Domain elements, imported States views elements (e.g., States and Transitions) cannot be used in other Toolkits States views. They can, however, be referenced in the importer Toolkits Side Eects view; 63

2.4. ADDITIONAL ASPECTS Due to the holistic nature of Tasks, imported Actions and Actions Transitions also cannot be used in other Toolkits Tasks views. They can, however, be referenced in the importer Toolkits Side Eects view (following the same reasoning regarding the States view). Figure 2.62 illustrates an example of a Domain view for a Toolkit that imports other Toolkits (Resources and Entities); in this gure, the Document Entity which is dened in the importer Toolkit is a specialization of an Entity Resource (imported from the Resources Toolkit), and it is also associated with the Person Entity (imported from the Entities Toolkit).

Figure 2.62: Toolkit Domain view with imported Toolkit elements.

2.4.4

Using Toolkit Elements In WebSite Templates

Finally, the whole purpose of dening a Toolkit is its ultimate inclusion into a WebSite Template, by using the Toolkit Import concept that was presented in Subsection 2.4.2. When a Toolkit T1 is imported into a WebSite Template W ST1 , the elements in T1 s following views become available for W ST1 : T1 s Roles view; T1 s WebComponents view. Because Toolkit Roles and WebComponents are also specializations of the WebSite Templates Role and WebComponent concepts, they can be used in exactly the same manner that was presented in Subsections 2.1.2 and 2.1.1 (respectively). There are however two representation dierences to consider when using Toolkit elements in a WebSite Template. The rst caveat to consider is that Toolkit WebComponents used in a WebSite Template are represented in nearly the same manner as Custom WebComponents; the only dierence is that the XYZ string (in the top-right corner) is replaced by a T, and the

64

2.4. ADDITIONAL ASPECTS WebComponents Type is specied in the form <Toolkit name>::<Toolkit WebComponent name>. Figure 2.63a depicts the representation of a Toolkit WebComponent, when it is used within a WebSite Template. The second caveat is that Toolkit Roles used in a WebSite Template are represented as regular CMS Roles (presented in Subsection 2.1.2), but the letter T written in the center of the shirt-like gure (in a manner similar to representing a Role when dening a Toolkit), and with the Roles name specied in the form <Role name> (<Toolkit name>::<Toolkit Role name>) (it is recommended that the part in parenthesis is written in a new line to enhance readability but it is not required). Figure 2.63b depicts the representation of a Toolkit Role, when used within a WebSite Template.

(a) A Toolkit WebComponent in a WebSite Template.

(b) A Toolkit Role in a WebSite Template.

Figure 2.63: Concrete syntax for Toolkit elements in WebSite Templates.

65

Chapter 3 Examples
This chapter presents two simple examples that illustrate the usage of CMS-ML. The rst example presented is the WebSite Template for a small personal website, consisting mainly of information that is relatively static. The second example consists of a simple Toolkit for viewing and managing folders and documents.

3.1

Personal WebSite

This example illustrates how to model a small personal website, consisting of a few web pages and some information. Because this is meant to be a simple starter example, this example will be presented using only the WebSite Template Designers perspective. The modeled website will consist of the following pages (in the given order): 1. Main 2. Projects I worked on (a) Academic (b) Industry 3. Achievements 4. Personal Stuff All of these pages will be available to the public, except for the last one (Personal Stuff). Furthermore, Main will be the websites home page, and the only pages that share the same visual structure are the Academic and Industry pages (i.e., one of them should use the other as a template). The visual structure and contents of each page should be the following: Main: Has a navigation tree and a hit-counter in a container on the left side of the page, and in a container occupying the remainder of the page there should be an 66

3.1. PERSONAL WEBSITE introductory text, an announcements list, and a guestbook (which can be signed by any kind of user). Projects I worked on: Has just a navigation tree in a container on the left side of the page, and some HTML text in a container that occupies the remainder of the page. Uses the same visual structure of Home. Academic: Has a navigation tree in a container on the left side of the page, some links in a container on the right side of the page, and some HTML text in a container that occupies the remainder of the page. Industry: Just like Academic, it has a navigation tree in a container on the left side of the page, some links in a container on the right side of the page, and some HTML text in a container that occupies the remainder of the page. Achievements: Has just a navigation tree in a container on the left side of the page, and some HTML text in a container that occupies the remainder of the page. Uses the same visual structure of Home (and Projects I worked on). Personal Stuff: Has just a wiki (editable by only some users) in a container that occupies the whole page. There should also be a small margin between each page and its contents (e.g., the page contents should occupy only about 99% of the pages size). The modeling of the WebSite Template corresponding to this website starts at the Structure view, more concretely by its Macro Structure view. Figure 3.1 illustrates how the facts that we have just described are modeled in the Macro Structure of CMS-ML, using the WebSite and Dynamic WebPage concepts.

Figure 3.1: The Macro Structure view of the Personal WebSite.

67

3.1. PERSONAL WEBSITE After dening the Macro Structure view, we should dene the contents of each Dynamic WebPage, by means of the Micro Structure view. Figure 3.2 provides illustrations of a manner in which the facts described above can be modeled in the Micro Structure of CMS-ML, using the Dynamic WebPage, Container, and WebComponent concepts.

(a) The Main Dynamic WebPage.

(b) The Projects I Worked On Dynamic WebPage.

(c) The Academic Dynamic WebPage.

(d) The Personal Stu Dynamic WebPage.

(e) The Industry Dynamic WebPage.

(f) The Achievements Dynamic WebPage.

Figure 3.2: The Micro Structure view of the Personal WebSite. Now the Structure view of our website is completely dened. The next step is modeling the Roles view. Because this is a small personal website, there wont be many roles in this website. In fact, if we assume that the websites owner will have a CMS administration 68

3.1. PERSONAL WEBSITE role (which automatically has permissions to do anything in the website), the only roles that need to be explicitly modeled are: An anonymous role, because the guestbook located in the Main page can be signed by any kind of user (which includes anonymous users); A regular role, which will be able to edit the Wiki in the Personal Stuff page. Thus, the Roles view for this example can be modeled simply as shown in Figure 3.3.

Figure 3.3: The Roles view of the Personal WebSite. After modeling the Roles view, it becomes possible to model the Permissions view. As was previously stated, the following permissions-related requirements must be honored: 1. The whole website can be viewed by the general public except for the Personal Stuff page; 2. The guestbook located in the Main page can be signed by any kind of user (which includes anonymous users); 3. The wiki in the Personal Stuff page can be edited by a select group of users (which were modeled in the Roles view as the PersonalWiki Editors Role). Figure 3.4 illustrates the Permissions view for this example (we have opted for a graphical representation instead of a matrix representation; however, if these permissions were more extensive or complex, the matrix representation might be better suited). Note that the rst requirement was already partly represented in the Macro Structure view (in Figure 3.1), as all Dynamic WebPages are visible to everyone by default, and so it is only necessary to represent that anonymous users the general public cannot view the Personal Stuff page (in Figure 3.4b). The second requirement is modeled in Figure 3.4a (the GuestBook WebComponent is represented within its Container and Dynamic WebPage to facilitate the understanding of this view, but it is not required), where anonymous users are given the permission to edit the contents of the GuestBook (in this particular case, to sign it). The third requirement is modeled in Figure 3.4b, where the PersonalWiki Editors Role is given permissions to both view the Personal Stuff page (otherwise the Roles users would not be able to even view the Dynamic WebPage, much less edit the contents of one of its WebComponents) and to edit the contents of the My Wiki WebComponent in that page.

69

3.2. DOCUMENT MANAGEMENT TOOLKIT

(a) The permissions for the Main Dynamic WebPage.

(b) The permissions for the Personal Stu Dynamic WebPage.

Figure 3.4: The Permissions view of the Personal WebSite. We have now modeled the WebSite Template for a small personal website. However, it is very limited, because more custom advanced functionality (such as document management, as per a Document Management System) cannot be modeled using just a WebSite Template. This is why the Toolkit model exists, which will be explained in the next example.

3.2

Document Management Toolkit

This example illustrates not how to model a website, but rather how to model a Toolkit, which consists of additional functionality that can afterward be included in a websites model. The modeled Toolkit will be very simple, and allow the management and viewing of documents and folders. A Document is an entity with a name (which identies it within the context of its parent Folder), a description, a creation date, and some contents (a le for which the Document itself can be considered as a placeholder). On the other hand, a Folder is another entity consisting of a container of Documents (and other Folders), and it also has a name (which identies it within the context of its parent Folder, if any). Folders and Documents can be manipulated by the Document Manager, while the 70

3.2. DOCUMENT MANAGEMENT TOOLKIT Document Operator can only manage Documents (and new Documents must be validated by the Document Manager before they become available in the system) and the Document Viewer can only view Documents (i.e., access their contents). The modeling of the Toolkit starts at the Roles view. Figure 3.5 illustrates how the roles that we have just described (Document Manager, Document Operator, and Document Viewer) are modeled in the Toolkit Roles view.

Figure 3.5: The Roles view of the Documents Toolkit. The next step is to model the Tasks view. This is one of the most important views of a Toolkit, as it establishes most of the Toolkits scope regarding its functionalities. Because of text size, we will not provide an exhaustive listing of the Tasks that this toolkit should provide, and instead will illustrate a few more signicant Tasks, namely: Create Document Delete Document The Create Document Task can be thought of as having three Actions (performed sequentially): (1) Ask the user for the Documents name and description; (2) Ask the user for the Documents le itself; and (3) Have the system create the Document. Figure 3.6a illustrates how this Task could be represented using CMS-ML. On the other hand, the Delete Document Task can be considered as having the following Actions: (1) Ask the user for the Document to delete; (2) Have the system try to delete the Document; (3) If the Document was successfully deleted, end the Task; (4) Otherwise, alert the user that there was a problem deleting the Document. Figure 3.6b illustrates how this Task could be represented using CMS-ML. In parallel to the modeling of the Tasks view, the Toolkit Designer can also dene the Domain view. Figure 3.7 depicts the Domain view that reects the description provided above. Note that the two Entities dened (Folder and Document) both have associated Lifecycles, because in this kind of systems a Folder can usually be deleted, an operation which also destroys the Documents it contains, while in this system new Documents have to be validated before they become accessible. After dening the Domain view, the Toolkit Designer should model the States view if it is relevant because of any of the Entities dened in the Domain view (in Figure 3.7, both the Document and Folder Entities are to have associated Lifecycles). Figure 3.8 71

3.2. DOCUMENT MANAGEMENT TOOLKIT

(a) The Create Document Task.

(b) The Delete Document Task.

Figure 3.6: The Tasks for the Documents Toolkit.

Figure 3.7: The Domain view of the Documents Toolkit.

72

3.2. DOCUMENT MANAGEMENT TOOLKIT depicts the States view of this Toolkit: the Folders Lifecycle in Figure 3.8a is very simple (it exists until it is deleted), while the Documents Lifecycle in Figure 3.8b is a little more complex because it involves an approval/rejection before it can become available for users.

(a) The Lifecycle of the Folder Entity.

(b) The Lifecycle of the Document Entity.

Figure 3.8: The States view of the Documents Toolkit. Now that the Domain and the Tasks view are dened, the Toolkit designer can start specifying the WebComponents view. In this view, the designer will design the interface (in a low-delity prototype kind of way) of the WebComponents that this Toolkit will provide to support the dened Tasks, as well as any Support WebPages that are necessary to support their related WebComponent. To keep this example small, we will only illustrate the modeling of a WebComponent, Manage Documents, and its Supporting WebPage Edit Document. The Manage Documents WebComponent, represented in Figure 3.9, expects no Domain Entity instances, and is composed of: A A A A
Document List List WebContainer, containing only a Text WebElement Name; Create Document Link; Edit Document Button; and Delete Document Button.

On the other hand, the Edit Document Support WebPage represented in Figure 3.10 supports the Manage Documents WebComponent, and expects a Document (which is assigned the local name document). Furthermore, this Support WebPage is composed of: A Name: Text WebElement, and a Text Input Box, called NameValue, in which the Documents Name will be entered; 73

3.2. DOCUMENT MANAGEMENT TOOLKIT

Figure 3.9: The Manage Documents WebComponent of the Documents Toolkit. Like with Name, a Description: Text WebElement and a Text Input Box, called DescriptionValue, to hold the Documents Description; A Cancel Button; and A Confirm Button.

Figure 3.10: The Edit Document Support WebPage of the Documents Toolkit. Finally, all that is left is the Interaction Access and Interaction Triggers views (remember that the Side Eects view is not mandatory), in which we specify the mappings between the dened Tasks, Roles, and WebComponents. We can start by establishing the Interaction Access view, namely by using the WebElement Access and WebInteractionSpace Access concepts to establish access permissions between the toolkits Roles and its dened visual elements (WebComponents, Support WebPages, and WebElements). Figures 3.11a and 3.11b illustrate mappings established between the Document Manager and Document Operator Roles and the Manage Documents WebComponent and its Delete Document Button, respectively. More specically, both 74

3.2. DOCUMENT MANAGEMENT TOOLKIT the Document Manager and Document Operator Roles are allowed to view the Manage Documents WebComponent, while the Document Operator Role is not allowed to use (or even view) the Delete Document WebElement that is dened within Manage Document (a real model would likely have more interaction mappings dened, but we will not dene additional mappings in this example, due to text size).

(a) Interaction mappings between the toolkits Roles and the Manage Documents WebComponent.

(b) Interaction mappings between Document Operator and the Delete Document WebElement.

Figure 3.11: The Interaction Access view of the Documents Toolkit Can Interact With elements. Regarding the Interaction Triggers view and the denition of Triggers, the model could easily be expanded to feature a large set of WebElement Triggers. In Figure 3.12, we demonstrate how to represent: A WebElement triggering a Task, in Figure 3.12a, in which the Create Document Buttons Click triggers the start of the Create Document Task. A WebElement triggering an Action Transition, in Figure 3.12b, where a Click of the Confirm Button supposedly of a Create Document Support WebPage triggers the Action Transition that will lead to the Action in which the Document is eectively created.

75

3.2. DOCUMENT MANAGEMENT TOOLKIT

(a) Trigger mapping between a WebElement and a Task.

(b) Trigger mapping between a WebElement and an Action Transition.

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

76

Chapter 4 Conclusion
In this manual, we have presented the CMS-ML language. The WebSite Template and Toolkit models have been explained in great detail, and their concepts have been dened. Finally, we have presented an example of both types of models: (1) a WebSite Template for a Personal WebSite; and (2) a Toolkit for performing some operations regarding Document management.

77