of the CMS systems (and their corresponding development approaches) that were compared in Chapter 5.
1.10
Adopted Notations and Conventions
In order to establish a clear distinction between plain text and certain relevant terms and designations, this dissertation adopts a typographical convention that is reflected in the following styles:
• The bold face font is used to highlight the definition of concepts that are important to this dissertation.
Example:
“A web application is an executable program that (. . . )”
• The italic font is used to emphasize a relevant name or segment of text. Foreign terms are also represented using an italic font.
Example:
“Is it feasible to have models as the project’s de facto main artifact (. . . )” • The typewriter font, when used in its normal size, indicates language keywords or
code snippets (e.g., names of classes, attributes, or methods). On the other hand, a smaller typewriter font is used when representing values of elements (e.g., the name of a certain class, or the value assumed by a specific attribute).
Example:
“The instances of UML’s Class element – namely Social Network, Person, Role, and Relationship – are represented (. . . )”
• Quotation marks (“”) are used with one of the following purposes: (1) to represent a word, and not its meaning; (2) to represent a string; (3) to mention the title of a literary work (e.g., a user’s manual); or (4) as scare quotes (i.e., indicators that the corresponding text should not be interpreted literally).
Example:
“Several definitions for the term “metamodeling” can be found (. . . )”
Furthermore, whenever a figure is extracted or adapted from another document, the figure’s caption will explicitly indicate this fact and make a reference to the corresponding
document. All the original figures created for this dissertation (i.e., not extracted or adapted from some external source) have no such reference.
When suitable, figures will consist of diagrams specified using the UML modeling language [OMG 11 e], as it is assumed that readers are familiar with this standard. These diagrams also assume that the default cardinality for the extremities of each association (including aggregations) is 1, unless the diagram explicitly indicates otherwise.
Finally, this dissertation uses some terms that are synonym to other terms also found in literature. The most relevant cases to mention are the following:
• The terms “metalevel” and “metalayer” have the same meaning. Most of the available literature uses the term “metalevel”, and thus we use “metalevel” in this dissertation; nevertheless, the Object Management Group (OMG) uses the term “metalayer” [OMG 11 b]. Furthermore, we only use the term “layer” when referring to technology (and not metamodeling), or when referring to models that have dependencies on elements in other models (e.g., a UI model is a layer that uses elements from a domain layer); and
• The terms “website” and “web application” assume the meaning that was previously provided in this chapter: a web application is a program that uses web-based technologies, and a website is a deployment of a web application. This means that, in this dissertation, a website can be understood as being an instance of a web application. Nevertheless, because these concepts are closely related, the terms “website” and “web application” will sometimes be used in an interchangeable manner,
and the reader can often consider these terms as synonyms (unless the text explicitly states otherwise).
Summary
In this chapter, we have provided a brief introduction to the research work that was performed in the context of this PhD dissertation, namely by presenting (1) the research problem that motivated this work, (2) the thesis statement, and (3) the research objectives that the dissertation aims to accomplish.
The following chapters are dedicated to the presentation of the State of the Art that was considered relevant for this research work. In particular, the next chapter is dedicated to presenting the MDE paradigm in greater detail, as well as some important modeling language creation approaches that are of interest regarding the work presented in this dissertation.
Chapter 2
Modeling Language Design
A different language is a different vision of life.
Federico Fellini To improve the manner in which a software program is developed, it is necessary that the software program’s stakeholders have the ability to express their domain knowledge, intents, and objectives using suitable languages with which they can relate. Such languages can be graphical (e.g., pictorial languages such as UML) or even textual (e.g., traditional programming languages such as Python, Ruby, C#, Java, or many others that exist today),
depending on factors such as the stakeholder’s concerns and technical background. This need for stakeholder-friendly languages, in turn, originates the need for mechanisms to create those languages, to support the definition of new ways to create and specify models representing solutions for problems. Furthermore, the subject of language creation is closely related with the continuous effort by software engineers and researchers to elevate the abstraction level at which they perform their software analysis, design, and development tasks.
In the context of this research, we have studied and analyzed the following language design topics and approaches: (1) Model-Driven Engineering (MDE); (2) Model-Driven Architecture (MDA), the Object Management Group’s approach; (3) Domain-Specific Modeling (DSM); (4) metamodeling; and (5) the similarities between the activities of designing modeling languages and programming languages. Although other modeling language design approaches and respective supporting tools exist – such as (1) MIC (Model- -Integrated Computing)1 [SK 97] and its GME tool (Generic Modeling Environment)2,
1
http://www.isis.vanderbilt.edu/research/MIC (accessed on March 15th, 2012)
2
(2) Microsoft’s Software Factories3[GSCK 04], or (3) the Eclipse GMP (Graphical Modeling
Project)4 – we consider that they share similar underlying concepts with the analyzed
approaches.
It should be noted beforehand that the analysis presented is not intended to be exhaustive. This is because some aspects of such an analysis would be out of the scope of this research work. Furthermore, each of these topics has already been the subject of numerous books and articles, and so presenting such an analysis would extend this dissertation’s length significantly, while providing little added-value. Instead, the presented analysis is focused only on aspects that are of particular relevance to the scope of this work, namely the aspects that are identified in Section 2.4.
2.1
Modeling and Model-Driven Engineering
Software systems are reaching such a high degree of complexity that even current third- -generation programming languages, like Java or C#, are becoming unable to efficiently
support the creation of such systems [Sch 06]. One of the problems with such current languages is that they are still too oriented toward specifying how the solution should work, instead of what the solution should be. This leads to a need for mechanisms and techniques that allow the developer to abstract over the programming language itself and focus on creating a simple (and, whenever possible, elegant) solution to a certain problem.
A considerable research effort has been made in recent years to raise the abstraction level into Model-Driven Engineering (MDE). Sometimes called Model-Driven Development (MDD), MDE is an emerging paradigm based on the systematic use of models as the cornerstones of the solution specification [Sch 06, MCF 03, SV 05 b]. Unlike previous (source code-based) software development paradigms, models become the most important entities, and artifacts such as source code or documentation can then be obtained from those models in an automated manner, relieving developers from issues such as underlying platform complexity or inability of third-generation languages to express domain concepts.
MDE is not a new idea. In fact, in the 1980s and 1990s, Computer-Aided Software Engineering (CASE) tools were already focused on endowing developers with methods and tools to design software systems using graphical general-purpose language representations. The developer would then be able to perform different tasks over those representations, such as verification or transformations to/from code. However, these CASE tools failed to accomplish their intended purpose, due to issues such as [Sch 06]: (1) poor mapping of general-purpose languages onto the underlying platforms, which made generated code
3
http://www.softwarefactories.com (accessed on March 15th, 2012)
4
2.1. MODELING AND MODEL-DRIVEN ENGINEERING
much harder to understand and maintain; (2) inability to scale, because they did not support concurrent development; and (3) source code was still the most important entity in the development process, while models were seen as only being suited for documentation. Nowadays, the stage is more favorable for the MDE paradigm to succeed. This is because of the aforementioned inability of third-generation languages to address the increasing degree of complexity of current software systems, combined with the choices of development platforms currently available (e.g., Java) to which models can be mapped.
There are currently a significant number of MDE-oriented approaches, of which we highlight the Model-Driven Architecture (MDA) and Domain-Specific Modeling (DSM). It is important to note that MDE does not define any particular approach; instead, MDE itself is a paradigm that is addressed by such approaches, while being independent of language or technology [Fav 04 b, Fav 04 a].
Nevertheless, all MDE-oriented approaches share the same basic concepts. A model is an interpretation of a certain domain – a fragment of the real world over which model- ing and system development tasks are focused – according to a determined structure of concepts [SV 05 a]. In other words, a model can be viewed as a reduced representation of a system, highlighting properties that are of interest according to a specific perspec- tive [Sel 03]. It can also be regarded as a system, which itself provides answers about the system that is being analyzed without the need to directly consider the latter [Fav 05].
The structure of concepts that defines a model is provided by a metamodel, which is an attempt at describing the world around us for a particular purpose, through the precise definition of the constructs and rules needed for creating models [SS 08 a, SS 10 b]. This means that a metamodel provides a language that can be used to create a model, as Figure 2.1 illustrates; similarly, a metamodel that defines the language in which another metamodel is specified is called a metametamodel.
Figure 2.1: The relationship between a model and a metamodel (adapted from [SS 08 a]).
Also noteworthy is the concept of metalevel (sometimes called metalayer, namely in OMG’s specifications). A metamodel is often said to be in a metalevel above the corresponding model’s metalevel. Thus, defining a stack of metalevels provides a way to hierarchically structure a set of models in relation to their respective metamodels. The
concept of metalevel is particularly important when defining metamodeling architectures such as OMG’s (which is further explained in Subsection 2.2.2).
From a practical perspective, and considering Figure 2.1, it is noteworthy to point out that most modeling tools typically deal with only one logical level (i.e., user model editing and a hardcoded metamodel). This is because creating such a tool is easily done with a typical Object-Oriented Programming (OOP) language [CN 91], by taking advantage of the class–instance relation and making the logical level be supported by the instance level.
Now that these basic modeling concepts have been presented, we are now able to provide an analysis of some relevant MDE approaches and languages, according to the aspects that were identified at the beginning of this chapter.