Introduction
The human mind inadvertently and continuously re-works reality by applying cognitive processes that alter the subjective perception of it. Among the various cognitive processes that are applied, abstraction is one of the most prominent ones. In simple words, abstraction consists of the capability of finding the commonality in many different observations and thus generating a mental representation of the reality which is at the same time able to:
• generalize specific features of real objects (generalization);
• classify the objects into coherent clusters (classification); and
• aggregate objects into more complex ones (aggregation).
Actually, generalization, classification, and aggregation represent natural behaviors that the human mind is natively able to perform (babies start performing them since they are a few months old) and that are performed by people in their everyday life. Abstraction is also widely applied in science and technology, where it is often referred to as modeling. We can informally define a model as a simplified or partial representation of reality, defined in order to accomplish a task or to reach an agreement on a topic. Therefore, by definition, a model will never describe reality in its entirety.
1.1 PURPOSE AND USE OF MODELS
Models have been, and are, of central importance in many scientific contexts. Just think about physics or chemistry: the billiard ball model of a gas or the Bohr model of the atom are probably unacceptable simplifications of reality from many points of view, but at the same time have been paramount for understanding the basics of the field; the uniform motion model in physics is something that will never be accomplished in the real world, but is extremely useful for teaching purposes and as a basis for subsequent, more complex theories. Mathematics and other formal descriptions have been extremely useful in all fields for modeling and building upon models. This has been proven very effective at description and powerful at prediction.
A huge branch of philosophy of science itself is based on models. Thinking about models at the abstract and philosophical level raises questions in semantics (i.e., the representational function performed by models), ontology (i.e., the kind of things that models are), epistemology (i.e., how to learn through or from models), and philosophy.
Models are recognized to implement at least two roles by applying abstraction:
• reduction feature: the models only reflect a (relevant) selection of the original’s properties, so as to focus on the aspects of interest; and
• mapping feature: the models are based on an original individual, which is taken as a prototype of a category of individual and is abstracted and generalized to a model.
The purpose of models can be different too: they can be used for descriptive purposes (i.e., for describing the reality of a system or a context), prescriptive purposes (i.e., for determining the scope and details at which to study a problem), or for defining how a system shall be implemented.
In many senses, also considering that it is recognized that observer and observations alter the reality itself, at a philosophical level one can agree that “everything is a model,” since nothing can be processed by the human mind without being “modeled.” Therefore, it’s not surprising that models have become crucial also in technical fields such as mechanics, civil engineering, and ultimately in computer science and computer engineering. Within production processes, modeling allows us to investigate, verify, document, and discuss properties of products before they are actually produced. In many cases, models are even used for directly automating the production of goods.
The discussion about whether modeling is good or bad is not really appropriate. We all always create a mental model of reality. In a sense, one can say that you cannot avoid modeling. This is even more appropriate when dealing with objects or systems that need to be developed: in this case, the developer must have in mind a model for her/his objective. The model always exists, the only option designers have is about its form: it may be mental (existing only in the designers’ heads) or explicit [47]. In other words, the designer can decide whether to dedicate effort to realizing an explicit representation of the model or keeping it within her/his own mind.
1.2 MODELING FOR SOFTWARE DEVELOPMENT
The scope of this book is to discuss approaches based on modeling for the development of software artifacts. In this field, this is known as Model-Driven Software Engineering (MDSE). MDSE practices proved to increase efficiency and effectiveness in software development, as demonstrated by various quantitative and qualitative studies [1].
The need for relying on models for software development is based on four main facts.
1. Software artifacts are becoming more and more complex and therefore they need to be discussed at different abstraction levels depending on the profile of the involved stakeholders, phase of the development process, and objectives of the work.
2. Software is more and more pervasive in people’s life, and the expectation is that the need for new pieces of software or the evolution of existing ones will be continuously increasing.
3. The job market experiences a continuous shortage of software development skills with respect to job requests.
4. Software development is not a self-standing activity: it often imposes interactions with non-developers (e.g., customers, managers, business stakeholders, etc.) which need some mediation in the description of the technical aspects of development.
Modeling is a handy tool for addressing all these needs. That’s why we strongly believe that MDSE techniques will see more and more adoption. This vision is supported by all the major players of the field (tool vendors, researchers, and enterprise software developers), and also by business analysts. For instance, Gartner foresees a broad adoption of model-driven techniques thanks to the convergence of software development and business analysis. This is particularly true in scenarios where the complexity of new, service-oriented architectures (SOAs) and cloud-based architectures, jointly applied with business process management (BPM), demand more abstract approaches than mere coding. Also from the standardization and tooling point of view, Business and IT modeling and technologies are converging. This brings huge benefits to organizations, which struggle to bridge the gap between business requirements and IT implementation. Companies try to exploit this convergence and to ensure collaboration among the IT organization, business process architects, and analysts who are using and sharing the models. This obviously also implies organizational changes that should move toward more agile approaches, combined with fostering modeling efforts and reusable design patterns and frameworks to improve productivity, while ensuring quality and performance [10].
A different discussion is the use people make of models (based on Martin Fowler’s classification 1):
• models as sketches: models are used for communication purposes, only partial views of the system are specified;
• models as blueprints: models are used to provide a complete and detailed specification of the system; and
• models as programs: models, instead of code, are used to develop the system.
Of course, during the course of a development process, a team can use the models in several different ways. For instance, while discussing design decisions models could be used as sketches as an aid for the discussion; and after, complete models could be defined as part of the blueprint of the system. Finally, these blueprint models may be further refined to create the system using code-generation techniques to minimize the coding tasks.
1.3 HOW TO READ THIS BOOK
This is an introductory book to model-driven practices and aims at satisfying the needs of a diverse audience.
Our aim is to provide you with an agile and flexible book to introduce you to the MDSE world, thus allowing you to understand the basic principles and techniques, and to choose the right set of instruments based on your needs. A word of caution: this is neither a programming manual nor a user manual of a specific technology, platform, or toolsuite. Due to space limitations, we will not be able to address in detail all the MDSE technologies existing on the market. Through this book you will be able to delve into the engineering methodologies, select the techniques more fitting to your needs, and start using state of the art modeling solutions in your everyday software development activities.
We assume the reader is familiar with some basic knowledge of software engineering practices, processes, and notations, and we also expect some software programming capabilities.
The book is organized into two main parts.
• The first part (from Chapter 2 to Chapter 6) discusses the foundations of MDSE in terms of principles (Chapter 2), typical ways of applying it (Chapter 3), a standard instantiation of MDSE (Chapter 4), the practices on how to integrate MDSE in existing development processes (Chapter 5), and an overview of modeling languages (Chapter 6).
• The second part (from Chapter 7 to Chapter 10) deals with the technical aspects of MDSE, spanning from the basics on how to build a domain-specific modeling language (Chapter 7), to the description of Model-to-Model and Model-to-Text transformations (Chapters 8 and 9, respectively), and the tools that support the management of MDSE artifacts (Chapter 10).
We think we can classify the attitude of a reader of this book into three main categories: the curious, the user, and the developer—plus, the atypical one of the B.Sc., M.Sc, or Ph.D. student that needs to address some academic course on MDSE. It’s up to you to decide what are your expectations from this book. Obviously, you may want to read the book from the first to the last page anyway, but here we try to collect some suggestions on what not to miss, based on your profile.
MDSE Curious
If you are interested in general in MDSE practices and you would like to learn more about them, without necessarily expecting to do the technical work of using model-driven approaches or developing modeling languages, you are probably MDSE curious.
This attitude is extremely useful for CTOs, CIOs, and team managers that want to have a bird’s eye view on the matter, so as to take the appropriate decisions when it comes to choosing the best development techniques for their company or team.
In this case, our suggestion is to focus on the first part of the book, namely the: MDSE principles (Chapter 2) and usage (Chapter 3); MDA proposal by OMG (Chapter 4); and overview on the modeling languages (Chapter 6). We also suggest reading how to integrate MDSE in existing development processes (Chapter 5) and possibly the tools that support the management of MDSE artifacts (Chapter 10).
If you are a technical person (software analyst, developer, or designer) and you expect to use in your development activities some MDSE approach or modeling notation, with the purpose of improving your productivity and learning a more conceptual way for dealing with the software development problem, you are probably a MDSE user. In this case, you are probably not going to develop new modeling languages or methods, but you will aim at using your best the existing ones.
If you think you fall into this category, we recommend that you read at least the: basics on MDSE principles and usage in Chapters 2 and 3; overview on OMG’s MDA approach (Chapter 4) and on modeling languages (Chapter 6); description of Model-to-Model and Model-to-Text transformations (Chapters 8 and 9, respectively), and tools that support the management of MDSE projects (Chapter 10).
MDSE Developer
Finally, if you already have some basic knowledge of MDSE but you want to move forward and become a hardcore MDSE adopter, by delving into the problems related to defining new DSLs, applying end-to-end MDSE practices in your software factory, and so on, then we classify your profile as MDSE developer.
As such, you are probably interested mostly in the second part of the book, which describes all the details on how to technically apply MDSE. Therefore, we recommend that you read at least the following chapters: the overview on modeling languages (Chapter 6), the basis on domain-specific modeling languages (Chapter 7); the description of Model-to-Model and Model-to-Text transformations (Chapters 8 and 9, respectively) and the tools that support the management of MDSE artifacts (Chapter 10).
Optionally, if you need to refresh your mind on the basic MDSE principles, you can read Chapters 2 and 3. As a final read, if you are also involved in management activities, you can read the chapter on agile development processes (Chapter 5).
Student
If you are a student of an academic or professional course, our suggestion is to go through the whole book so as to get at least the flavor of the objectives and implications of the MDSE approach. In this case, this book possibly will not be enough to cover in detail all the topics of the course you are following. Throughout the text we offer a good set of references to books, articles, and online resources that will help you investigate the topics you need to study in detail.
In addition to the contents of the book, more resources are provided on the book’s website (http://www.mdse-book.com) including the examples presented in the book.