Predimensionamiento de losas Aligeradas en dos direcciones.

Figure 7.33 illustrates the concrete syntax for both Toolkit Import elements. It should be noted that the concrete syntax for these elements consists of a box (containing the imported Toolkit’s name) and a dashed line connecting the WebSite/Toolkit to that box, which explains why there is no “connection” element defined in the abstract syntax.

(a) A WebSite Template importing a Toolkit. (b) A Toolkit importing another Toolkit.

Figure 7.33: Concrete syntax for Toolkit Import elements.

Regarding the representation of imported Toolkit elements, Figure 7.34 depicts some examples of their representation:

• Figure 7.34a illustrates a Toolkit WebComponent instance, My Favorite TV, that is used of a WebSite Template (more specifically, in a Dynamic WebPage Home). This element is an instance of a TV ReceiverWebComponent, which was made available when the WebTV Toolkit was imported;

• Figure 7.34b depicts the representation of a Toolkit Role, called MySite Document Manager, used in a WebSite Template. This element is an instance of the Role Document Manager, available in an imported Toolkit called DMS (which stands for “Document Management System”);

• Figure 7.34c illustrates a simple Domain view for a Toolkit that imports other Toolkits (Resources and Entities). In the figure, the Document Entity – which is defined in the importer Toolkit – is a specialization of an Entity Resource (imported from the Resources Toolkit), and it is also associated with thePersonEntity (imported from the EntitiesToolkit).

7.9

Language Design Considerations

In addition to the CMS-ML description presented in the previous sections, it is important to provide further insight into some language design considerations that, in turn, are the motivating factor for some of the design decisions that led to the existence – or lack thereof – of some modeling elements. These considerations concern not only the metalevel

(a) A Toolkit WebComponent in a WebSite Template.

(b) A Toolkit Role in a Web- Site Template.

(c) Toolkit Domain view with imported Toolkit elements.

Figure 7.34: Concrete syntax for imported Toolkit elements.

structure presented in Section 7.3, but also the question of which modeling elements are relevant to the language and which are not.

The first consideration is that the tactic used for CMS-ML’s architecture – splitting the language into different metalevels, each of which with a set of hardcoded modeling elements – is actually an application of the Language metaphor (described in Chapter 2), as each of the unchangeable models can be considered as being hardcoded into an orthogonal metamodel. This usage of the Language metaphor – instead of the (more extensible) Library metaphor – was due to our decision to follow the simplest approach when defining the first iterations of CMS-ML. Nevertheless, CMS-ML presents no issues that would make it inadequate for the Library metaphor, although this would involve the extra work of defining more basic elements (for the hardcoded metamodel) and defining libraries for the various models considered.

Another consideration concerns CMS-ML’s extensibility, as we have opted for a limited application of orthophrase [Sta 75], because it is clearly more useful for extending a modeling language, as it allows the designer to add truly new elements to the language. The other approaches [Sta 75] were also considered, but discarded: (1) the paraphrase approach would serve little purpose other than supporting design patterns, such as those defined in [GHJV 95], by providing new elements that are just syntactic sugar for elements that already exist in the language; and (2) the metaphrase approach would likely be more

7.9. LANGUAGE DESIGN CONSIDERATIONS

harmful than helpful, as the same WebSite Template model could have different meanings depending on its imported Toolkits, thus introducing a potential source of confusion for a stakeholder when looking at a model and interpreting it.

Furthermore, although CMS-ML provides a WebSite Annotations mechanism, it does not provide a corresponding Toolkit Annotations mechanism (in a manner similar to the WebSite Annotations Modeling model defined in ML2). This is because the WebSite Annotations mechanism is meant to allow the Template Designer to configure a Template’s deployment with additional CMS-specific details that could not be conveyed via its elements alone (e.g., the aforementioned example specifying that a WebComponent should allow users to subscribe to content updates). However, considering that a Toolkit model does not define any elements that are immediately displayed to the web application’s users (i.e., a Toolkit model does not configure the WebSite Template model, but rather only endows it with additional building blocks), it would not make sense to define a Toolkit Annotations mechanism to configure a Toolkit’s deployment in a CMS-specific manner.

An additional consideration regards the Structure view’s usage of a page-centric approach, as opposed to a content-centric one. The rationale behind the usage of a page-centric approach approach is that most users are accustomed to it, namely when using a web browser to navigate the World Wide Web. This activity consists of a user being presented with pages, which in turn contain content and links to other pages. On the other hand, content-centric approaches are typically used in a CMS’s back office, where the definition of the web application’s content before structure is often a best practice to avoid the copy-paste of contents when restructuring the web application at a later point in time. However, since CMS-ML does not consider the definition of the web application’s content, a page-centric approach is the one that makes most sense.

It should also be noted that some WebSite Template modeling elements are based on similar elements from the CMS reference model presented in [Car 06]. Nevertheless, our work regarding CMS-ML goes beyond that reference model, namely by (1) addressing the behavior of CMS systems, (2) enabling the possibility of adding new elements to the language (by using the Toolkit mechanism), and (3) refining existing modeling elements (e.g., specifying their attributes) and adding new elements (such as Content).

The final consideration that we highlight regards the usage of side effects. It should be noted that, from a software development perspective, the use of side effects has its advantages and disadvantages [Hug 90, AS 96], of which we respectively highlight: side effects provide a way to specify a sequence of steps that can modify the program’s state in some manner (e.g., change a bank account’s balance); and they can make a program harder to understand and debug (because these activities require knowledge about the program’s context and possible history). Nevertheless, the reason why CMS-ML includes

a Toolkit view dedicated to the definition of side effects is that Toolkit Designers can use this view to specify changes (as Side Effects) that will occur over the Domain view’s Entity and Association instances. Those changes, in turn, can result from a variety of factors (such as business rules), and will often be implied by the Tasks view’s Action that ended up resulting in performing the Side Effect.

Summary

In this chapter, we have presented CMS-ML, a high-level and platform-independent modeling language that aims to endow non-technical stakeholders with the necessary elements to model a CMS-based web application according to their intent. Unlike other modeling languages, CMS-ML provides a mechanism for its extension, called Toolkit, which allows designers to add new modeling elements (Roles and WebComponents) to the language in a controlled manner.

However, CMS-ML presents a lack of expressiveness (considering its target domain, CMS-based web applications) that is the result of a trade-off between language learnability and the number of modeling elements provided by the language. This, in turn, makes CMS-ML unable to address particular features (e.g., algorithm specifications) that are expected of some CMS-based web applications.

In the next chapter, we present the CMS-IL modeling language. Unlike CMS-ML, CMS-IL provides a low level of abstraction over computation concepts (in the sense that it is similar to a programming language), although it is still platform-independent. The objective of this language is to provide a implementation-independent language that can be used to (1) address low-level computation aspects that could not be handled by CMS-ML, and (2) deploy a web application model in any CMS platform (assuming, of course, that the platform can interpret CMS-IL models).

Chapter 8

CMS-IL: CMS Intermediate

Language

The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its

complexity often abstract away its essence.

No Silver Bullet: Essence and Accidents of Software Engineering Frederick P. Brooks, Jr.

The CMS-ML language, described in Chapter 7, allows non-technical stakeholders to model a CMS-based web application according to their intent, in a high-level and platform-independent manner. Unlike other modeling languages that have been analyzed in this dissertation, CMS-ML also provides the Toolkit mechanism, which enables its extension in a controlled manner.

However, the language is the result of a trade-off between learnability and the number of modeling elements provided. The main premise for this decision is CMS-ML’s main objective to allow non-technical stakeholders (i.e., people without expertise in the de- velopment and maintenance of web applications and underlying technology) to quickly make correct models of CMS-based web applications. Nevertheless, this trade-off makes CMS-ML unable to address particular requirements that are typically expected of web applications, such as algorithm specifications (e.g., show an advertisement banner that chooses ads based on how much each advertiser pays) or integration with external web functionality, such as web services.

To address this problem, we propose CMS-IL (CMS Intermediate Language), a textual language which provides a low level of abstraction over computational concepts (in the sense that it is similar to a programming language), although it is still CMS-oriented and platform-independent. This language’s objectives are:

• To provide a mechanism, independent of any particular CMS implementation, that can be used by technical stakeholders to (1) address low-level computation aspects that could not be handled by CMS-ML, and (2) deploy a web application model in any CMS platform (assuming, of course, that the platform can interpret CMS-IL models); and

• To establish a common ground for the specification of CMS-based web applications (this is, in fact, the ultimate objective of CMS-IL).

CMS-IL provides structure models that are very similar to CMS-ML. In fact, most of the structural views are identical, although some modeling elements define additional attributes that technical stakeholders typically find useful when defining CMS-based web applications. Furthermore, like CMS-ML, the language also allows for its extension, in order to address a stakeholder’s specific requirements and to support the modeling of more complex web applications. Nevertheless, the greatest differences between these two languages lie in behavior specification, which in CMS-IL is of a much more low-level nature.

The CMS-IL language also provides a significant number of modeling elements with which to specify web application models. This is due to the aforementioned compromise between language learnability and number of elements: while CMS-ML attempts to improve learnability at the expense of having a moderate number of modeling elements (and a relatively low degree of expressiveness), CMS-IL strives to improve the degree of expressiveness, although this may make it harder to learn even by technical stakeholders.

In this chapter, we provide a general description of CMS-IL. More specifically, this chapter – which is structured in a manner similar to Chapter 7 – describes: (1) the artifacts and modeling roles considered for CMS-IL modeling; (2) the metalevels that are the basis for CMS-IL modeling, as well as the underlying rationale; (3) the modeling elements available for specifying a web application; and finally (4) the modeling elements available for extending this language with elements that are better adjusted to the web application’s specific purpose. The “CMS-IL User’s Guide” [SS 11 b] describes this language with a greater level of detail than the presentation that is provided in this chapter.

Before proceeding with the presentation of CMS-IL, there are some important points that should be taken into consideration by the reader.

The first point is that CMS-IL’s abstract syntax is described in the present chapter using UML. Although CMS-IL has a textual concrete syntax, its abstract syntax does not provide any limitations (besides the ones regarding its multiple metalevels, as was

8.1. GUIDELINES

the case with CMS-ML) that prevent its representation using simple UML elements, such as Class, Association, and Generalization. Furthermore, it is possible to depict the concepts of textual languages using UML class diagrams, as long as those languages can be described in a formal manner (e.g., using EBNF [EA 06]). Thus, just like in Chapter 7, we have opted to use UML in this chapter (although not strictly following the translation rules described in [EA 06], for simplicity), in order to facilitate the reading of this chapter.

Another point is that some of the concrete syntax examples provided in this chapter contain line breaks, and some lines are indented. These breaks and line indentations are included only to facilitate reading, and are considered by CMS-IL as whitespace, which is ignored. The indentations, in particular, are used to indicate that the current line continues the element declaration that was present in the previous line(s).

Finally, most of the concrete syntax examples are usually presented in their simplest form (i.e., without representing other contained elements), also in order to facilitate reading. An example of such a simplified form is the following (extracted from Listing 8.8):

1 CSS Class "OceanBlue Component" is applied to WebComponent "My Blog"

There could be a number of CSS Classes and WebComponents with such names, according to the Visual Themes and Structure views that are presented later in this chapter. Thus, if a CMS-IL model is being defined, then the names of their containing entities should also be specified – to remove any possible ambiguity – and the previous declaration should be as follows (again, the line break is only used to improve readability):

1 CSS Class "OceanColors"."OceanBlue Component" 2 is applied to WebComponent "My WebPage"."My Blog"

The only exception to this rule would be if there was no possible ambiguity (e.g., if there was only one WebComponent named My Blog).

8.1

Guidelines

Like in the previous chapter, it is important to provide some answers for the guidelines identified in Section 6.3 (see Chapter 6), before starting the definition of CMS-IL. These answers, used to steer the CMS-IL definition process, are provided in the next paragraphs. Like in the CMS-ML guidelines presentation of the previous chapter, these answers are presented in an abbreviated manner, for the same reasons.

Identify the target audience for the language. The target audience for CMS-IL are technical stakeholders (namely developers) that are well-versed in the area of CMS-based web applications. These stakeholders are aware of the CMS website-oriented and HTML

concepts (which were presented in Chapter 7) that are employed by CMS-ML business users. However, while those business users define a new CMS Component by specifying what they want the Component to do, CMS-IL stakeholders define that Component by specifying the low-level details of how the Component will accomplish its objective. Furthermore, because of their web application development background, these stakeholders are also aware of typical programming language constructs, such as the declaration of variables and the assignment of elements to those variables.

Identify the problem-domain that the language should address. Like the case of CMS-ML, the problem-domain for this language is the universe of CMS systems and CMS-based web applications. However, because of its target audience, CMS-IL is oriented toward the specification of how to address the statements that have been modeled in CMS-ML; in turn, this will require that the former provide technical concepts (namely to represent instructions to be run by a computer) that are not present in the latter. Other aspects to consider include the specification of the web application’s users, contents, and look-and-feel, as well as the localization and structuring of the aforementioned contents. Once again, we will not expand on the identification of this problem-domain right now, for the same reasons as in the previous chapter.

Determine the degree of extensibility that the language should address. As in CMS-ML, and according to the identified problem-domain, CMS-IL stakeholders need the ability to add new kinds of CMS Component, which will support the tasks (if any) that were previously identified in CMS-ML. Due to those tasks, stakeholders will also need to specify new kinds of role that will participate in the aforementioned Components.

CMS-IL stakeholders will occasionally need to add snippets of source code (written in a CMS-specific programming language), namely calls and auxiliary functions that will interact directly with the underlying system.

Furthermore, stakeholders should also be able to define source code (in either CMS-IL or some CMS-specific language) that can extend the CMS’s behavior, namely with the ability to: (1) intercept certain events that occur when a web request takes place (e.g., the request’s user is authenticated with the CMS); (2) implement functionality for an Action defined in the corresponding CMS-ML model; and (3) implement functionality corresponding to a CMS-ML CMS Feature or Toolkit Feature. The functionalities available to this code should include the ability to interact with the elements that have been defined in the CMS-IL model.

Finally, stakeholders will not need to modify the Components that are available out-of-the-box in the CMS, for the same reasons that have been presented in CMS-ML.

8.2. MODEL TYPES AND MODELING ROLES

Considering the identified problem-domain, determine the language’s model- ing levels and their hierarchy. Considering the previous answers, the important composition relationships identified are: (1) between a Component and its HTML parts (when defining new Components); (2) between a Website, its Pages, and their Components;

and (3) between a snippet of source code and its containing entity (typically a Website, Page, or Component). Some of these relationships are also present in CMS-ML, which can be considered as a motivation to reuse some of its concepts in CMS-IL (albeit with some changes when deemed necessary).

We have identified the same relevant instance-of relationships as in CMS-ML, namely: (1) a Website will contain instances of user-defined Components; and (2) some CMS roles will be instances of roles that were designed to interact with those Components.

Taking these relationships into consideration, the CMS-IL language requires the exis- tence of at least two metalevels (in addition to the metalevel that will contain the CMS instances): one metalevel for stakeholder-defined Components and CMS extensions, and the other for specifying the Website itself (with instances of those Components).

Identify any constraints that may condition the choice of a metamodeling language. As was the case with CMS-ML, the only noteworthy constraint detected was the need to allow stakeholder modeling in two metalevels (in addition to the “reality”