Diseño de la Brida inferior

Composition), which have the same semantics as their UML-homonyms;

• The Concept element is defined to represent concepts (i.e., metaclasses that have some meaning and representation, which is specified by a language designer). The reason why Model Element is not abstract (considering all of its specializations) is that it is also used to represent elements that (1) are only instances of another Model Element and (2) are not themselves metaclasses for other Model Elements; and • The Attribute can hold multiple values of its type.

Regarding Attribute’s link to Model Element (its type), we opted to maintain this link unaltered (as opposed to linking Attribute to Data Type, which is the case in UML), in order not to curtail the expressiveness of this metamodel (e.g., by preventing scenarios in which an Attribute references a specific Model Element instance). Nevertheless, we do not take advantage of this feature in ReMMM-based metamodels, so that we can use UML’s concrete syntax as-is and facilitate the reader’s interpretation of those metamodels.

Its MoMM-based heritage notwithstanding, ReMMM could also be considered as being defined using MOF (or even UML), although in this case ReMMM as a metamodel would bring no added-value (regarding expressiveness) in relation to its own (meta-)metamodel.

Finally, ReMMM shares MoMM’s trait of being reflexive (i.e., ReMMM can be used to describe itself). As was previously mentioned in Chapter 2, we take advantage of this fact in our research work, as the metamodels for the CMS-ML and CMS-IL languages were defined using ReMMM as their metametamodel. More specifically, we take advantage of (1) the reflexiveness of ReMMM and (2) the explicit definition of the Instantiation concept to define these languages using multiple metalevels (further details of which will be given in Chapters 7 and 8, where the languages are respectively presented). The MYNK model synchronization language also assumes that the metamodels of the models being synchronized can be themselves specified using ReMMM (a fact that we expect to be true for most existing modeling languages, because of ReMMM’s simplicity and high degree of expressiveness); this is because MYNK needs to have a “common ground” that allows it to receive and manipulate many kinds of models.

6.3

Guidelines For Language Specification

As was already mentioned in this chapter, the approach proposed in this dissertation contemplates only two languages, CMS-ML and CMS-IL. However, it would be rather naive to just assume that these two languages would be sufficient to support any kind of stakeholder in the development of a real-life web application. This, in turn, increases the likelihood of cases in which the approach must be extended with additional CMS-oriented

modeling languages, designed to support new stakeholder perspectives. Therefore, it becomes necessary to determine how to create such languages, and make them suitable for usage with MYNK.

During the research work presented in this dissertation, we have identified a small set of guidelines that proved helpful in the construction of the CMS-ML and CMS-IL languages. Although these guidelines should not be interpreted as steps in a language definition methodology, we believe that they can help to address some potential problems that typically occur during a language’s design process, such as metamodeling issues (described in Chapter 2) or multiple alternatives for the concrete syntax. Furthermore, it should be noted that some of these guidelines were based on the DSM language definition rules provided in [KT 08], while others were based on our own previous experiences with the development of the XIS2 language [SSSM 07] and on available best practices for DSL design [KP 09, MHS 05].

The identified guidelines are explained below (it is assumed, of course, that the language designer has already searched for a DSL that addresses the desired problem-domain, and found no adequate languages).

Identify the target audience for the language. This is, in our opinion, one of the most important guidelines, as its results should be main factor in most of the language design decisions that will follow. In particular, it is important to ascertain:

• the audience’s main concerns, regarding the language’s modeling purpose; and • the audience’s expected level of technical expertise (considering that the goal of

using the language will be to ultimately obtain a model that accurately represents software to run in a computer).

Although this guideline likely seems obvious to readers, it is important nevertheless because a model’s ultimate purpose is to answer questions about the system that it represents [Fav 04 b]. Thus, common sense dictates that it is important to determine first what are the questions to be answered, and only after that define a way to answer those questions.

Identify the problem-domain that the language should address. Just as impor- tant as the previous guideline (and closely related to it), a correct and precise identification of the problem-domain is essential, so that the language designer can be aware of what should be modeled and what is irrelevant in a model for a desired web application.

A correct identification, in turn, can help to minimize essential complexity [Bro 87, AK 08] in the language, by avoiding the inclusion of unnecessary elements that will likely only contribute to making the language harder to learn and use. Furthermore, we are

6.3. GUIDELINES FOR LANGUAGE SPECIFICATION

confident that, depending on factors such as the problem-domain’s essential complexity and the language designer’s experience regarding that domain, this correct identification can help to prevent accidental complexity in the language altogether.

This identification will typically result in the definition of the language’s abstract syntax (either formally with a metamodeling language, or just an informal text-based definition), which is why designers can consider that the core activities of this guideline are actually identifying: (1) the problem-domain’s concepts that the language must support; (2) the relationships between those concepts; and (3) any partitions or views that are

suitable for the language’s target audience (if applicable) [IEEE 00].

Determine the degree of extensibility that the language should address. After identifying the problem-domain, the language designer should consider whether it will be necessary for stakeholders to change the language (e.g., by adding new elements or changing elements that are already present in the language).

In [Sta 75], Standish identifies three different approaches to programming language extensibility: (1) paraphrase, in which new features are added to a language by defining them only in terms of features that are already present in that language; (2) orthophrase, in which new features are added to a language without requiring the features that are already included in the language; and (3) metaphrase, in which a language’s interpretation rules are changed, leading to existing language features being processed in a different manner. Although these approaches were identified in the context of programming language design, it can be considered that such programming languages are themselves textual cases of modeling languages (as was discussed in Chapter 2). Thus, these approaches may also be applied to extensibility in modeling language design, although the practical use of each approach can be subject to discussion, both in terms of (1) feasibility and of (2) added-value versus potential for users to make mistakes when modeling.

It should be noted that, because languages should continuously evolve [KP 09], it is possible (and perhaps recommended) to follow this guideline after the initial release of the language under construction, in order to avoid gold plating the language and thus minimize its accidental complexity. However, in such early stages, language designers should consider the target audience and ponder the possibility that the language’s users may need to extend it with new features that the language designer could not possibly predict. This can guide the language designer in specifying the language in such a manner that it can be extended in the future without needing to recreate the entire language.

Considering the identified problem-domain, determine the language’s model- ing levels and their hierarchy. Although closely related to the previous guideline

regarding extensibility, the focus of these two guidelines is somewhat different: the previous guideline aims primarily at determining what aspects of the language should be extendable by its users, while the current guideline is where the language designer formally structures the language’s concepts (from the problem-domain) into different modeling levels (i.e., metalevels).

More specifically, the language designer should consider the various concepts and relevant objects (previously identified during the analysis of the problem-domain), and determine any instance-of or composition relationships between them; in other words, the language designer must analyze the identified elements (concepts and objects), and determine (1) what classifies what, and (2) what are the building blocks for what.

This follows the notion of a stratified design approach [AS 96]. In this kind of approach, a complex system should be structured according to a set of levels described using different languages. Each level is specified by combining elements that are considered primitives at that level, and such primitives are themselves the result of combinations performed in the previous level. The authors also state that the language in each level should thus contain (1) primitives, as well as (2) combination and (3) abstraction mechanisms appropriate for

the intended level of detail.

The explicit definition of these modeling levels (metalevels in metamodeling nomen- clature) allows the language designer to establish a hierarchical structure between those metalevels. This hierarchy, in turn, ensures the practice of Strict metamodeling [AK 02, K¨uh 09] (already presented in Chapter 2), if the language designer ensures that: (1) no instance-of relationships are present within each metalevel; (2) instance-of is the only relationship that occurs between elements in different metalevels; and (3) all elements EL1

that occur in a metalevel M L1 are related (via the instance-of relationship) to elements

EL2 in another metalevel M L2.

Identify any constraints that may condition the choice of a metamodeling lan- guage. Besides the problem-domain’s concepts and relationships, the language designer must also determine any constraints that may make certain metamodeling languages unsuitable for specifying the language’s abstract syntax.

Although most metamodeling languages do not impose a considerable set of constraints due to their inherent simplicity, language designers should still identify those relevant constraints (related to either the problem-domain or the modeling levels identified), and evaluate whether the selected metamodeling language is able to model or satisfy those constraints in a satisfactory manner. Possible examples of such constraints are the usage of multiple-inheritance (e.g., the Kermeta metamodeling language1 supports multiple-

1

6.3. GUIDELINES FOR LANGUAGE SPECIFICATION

-inheritance by including a mechanism to address conflicts regarding operator and feature redefinition), or the need to specify particular restrictions over a specific model (e.g., to model the fact that an automobile should have four wheels).

Aside from the constraints identified, language designers also have to weigh the advantages and disadvantages of relevant issues, when considering whether to use (1) a general-purpose modeling language such as UML, or (2) a DSM-oriented language for the language’s metametamodel. Each of these approaches will have its own benefits and disadvantages. One of these important issues is tool support, as the adoption of a general-purpose language instead of DSM may facilitate the activity of creating a modeling tool. Another is the maintainability of the language’s models (i.e., the possibility of new users to correctly understand and change the model), regarding which [CRR 09] points out an advantage in using DSM instead of UML.

Identify the kind of concrete syntax that the target audience is most comfort- able with. This guideline is intended to address the dilemma of whether the language should have a graphical concrete syntax, a textual one, use a mixed approach to the language’s concrete syntax (by providing a language containing both graphical and textual elements), or even by providing multiple concrete syntaxes. This, in turn, is crucial to ensure the language’s quality and usability (according to the criteria mentioned in Section 2.3), and ultimately its acceptance by users [KT 08, BAGB 11].

To do so, the language designer must consider the target audience and its preferred manner of representing the desired system. The audience’s technical expertise may also be an influencing factor in this decision: according to [KP 09], (1) a significant proportion of developers prefers text-based languages, because of their activities involving traditional programming and scripting languages, while (2) the general population typically prefers graphical languages, as long as they reflect the shapes of the real world entities that are being represented in the model. The frequency with which the language will be used should also be considered: a language that is used often should try and provide a concrete syntax that ensures its users can define models in a quick and error-free manner, while it is likely not problematic that a language which is only used occasionally (and briefly) not provide a syntax with which users can quickly define models.

Summary

In this chapter, we have presented our MDE-oriented approach for the development of CMS-based web applications. This approach differentiates itself from other existing approaches for web application development (some of which have already been analyzed in

Chapter 4) by (1) its usage of multiple modeling languages (instead of a single language, such as UML or WebML), and (2) its model synchronization mechanism.

More concretely, the approach defines the CMS-ML, CMS-IL, and MYNK languages. CMS-ML and CMS-IL are meant to be used by Business Designers (business stakeholders) and System Designers (programmers), respectively. On the other hand, the MYNK model synchronization language is meant to be used by language developers (e.g., DSL creators that wish to specify new CMS-oriented languages different from CMS-ML and CMS-IL) as a way to allow further kinds of stakeholder to participate in the web application’s development process.

We have also presented a small set of guidelines for defining new modeling languages that can be used with MYNK. These guidelines enable the creation of further languages that better suit the needs of further kinds of stakeholder, which can prove useful in cases where CMS-ML and CMS-IL are not sufficiently adequate for creating the intended web application.

The following chapters are dedicated to presenting each of these languages in a greater level of detail (although not in an exhaustive manner), namely the rationale for the choices and compromises that were made when designing the languages. In particular, in the next chapter we present CMS-ML, this approach’s modeling language for Business Designers to create a high-level specification of a CMS-based web application, which should provide a level of support for some (or all) of an organization’s tasks.

Chapter 7

CMS-ML: CMS Modeling Language

A language that doesn’t have everything is actually easier to program in than some that do.

Dennis M. Ritchie

A typical problem with current web application modeling languages is that their models are often computation-oriented (i.e., oriented toward programming-specific details), and are not understandable by non-technical stakeholders, in the sense that such people will not be able to look at a model and easily determine what information it conveys. This problem can be found in most web application modeling approaches (such as UWE [KK 08], XIS2 [SSSM 07], or WebML [BCFM 07, CFB+ 02]), some of which have already been analyzed in Chapter 4. Furthermore, this is an issue that can potentially impact our approach’s usage in real-life web application development projects.

To address this problem, we propose CMS-ML (CMS Modeling Language) [SS 10 d], a graphical modeling language with the objective of allowing the specification of CMS-based web applications in a high-level and platform-independent manner. Furthermore, this language also allows for its extension, in order to address a stakeholder’s specific needs and support the modeling of web applications with a higher degree of complexity.

The CMS-ML language is designed to enable non-technical stakeholders to quickly model a web application supported by a CMS system. More specifically, its main objectives are to allow stakeholders to:

1. Read a model, in the sense that a model should not be so complex that a stakeholder could easily get lost while looking at it;

2. Understand the model, i.e., correctly interpret the model’s semantics; and 3. Change the model, so that it more accurately reflects the stakeholder’s intent.

Although creating a CMS-ML model can be considered a particular case of changing a model (more specifically, a “blank” model), it is possible for CMS-ML-supporting modeling tools to provide a predefined model, with a few elements such as a basic web application with a page. However, because this chapter is dedicated to presenting the language (and not discussing such modeling tool decisions), we will not further elaborate on this topic.

CMS-ML is also designed with the intent of being a platform-independent language, and does not provide a large number of modeling elements with which to specify web application models. This limited number of elements is because the aforementioned intent would mean that the language could either (1) contain a superset of elements that can be found in one or more CMS systems, or (2) contain a subset of elements that can typically be found in various CMS systems. The first option would originate a language with a larger set of modeling elements, some of which may or may not have a platform-specific counterpart, while the second option would lead to a smaller set of elements that will probably be easy to map to a specific platform. However, considering that languages featuring a larger set of elements are likely to be harder to organize and remember (thus making the language more complex and harder to learn) [Har 07], the decision was made to define a smaller set of modeling elements.

Nevertheless, this limited set of elements could mean that CMS-ML is not expressive enough to model most kinds of CMS-based web applications (other than simple toy examples). In fact, when considering the elements available for modeling WebSite Templates (explained further down this text), it would not be difficult to define a case study that could not be modeled by CMS-ML. Although this lack of expressiveness is a result of a trade-off between language expressiveness and complexity, we have tried to mitigate it by (1) allowing some modeling elements to freely express a set of textual properties (instead of constraining those properties to sets of possible values), (2) defining a language extension mechanism, which we designated as Toolkit, and (3) defining a tag-like mechanism, by which elements can be annotated in a manner that will not make the model become platform-specific. These aspects will be explained further in this chapter.

In this chapter, we provide a brief description of CMS-ML. More specifically, this chapter describes: (1) the artifacts and modeling roles considered; (2) the language’s metalevels, establishing the relationship between the different models considered, and the underlying rationale; (3) the modeling elements available for specifying a web application; and finally (4) the modeling elements available for extending the language, which can be used afterward when modeling a web application. For additional information, we also