Unidad 1. Introducción a las redes
1.1. Antecedentes
We investigate the differences and similarities between various software engi- neering practices currently in use, differentiated in the manner they approach the programming process. We start by describing an abstract scenario to pro- vide a framework of reference from which the differences in each practice can be derived. We provide an overview of how each practice approaches the sce- nario. Lastly, we reflect on the advantages and drawbacks of our envisioned practice, compared to the traditional ones.
Program Source Code
1
3
Model2
Reality4
0
Observe Formulate an hypothesis Provide a detailed descriptionConstruct and run an experiment
Alter the hypothesis Figure 3.2. An abstract scenario of our view on the programming process
Abstract Scenario
Adele works as a senior developer at a software company focused on medical applications. The project manager has requested her to produce a simulation program, to simulate the growth of a generic multicellular organism from the early stages of conception to its demise. Figure 3.2 depicts our view on the programming process, in the context of this scenario.
To complete her task, Adele performs a sequence of actions. In particular she
1. starts by observing the reality, to understand the laws that govern the growth and composition of multicellular organisms;
41 3.1 Motivation 2. distinguishes three entities: a simulation, a cell, and a multicellular or- ganism. She describes a model, capturing her current knowledge of the domain;
3. provides a more detailed specification of the behavior and composition of the model;
4. creates an executable computer model from the specification, and runs the simulation;
5. notices that she missed to distinguish an environment entity, thus needing to alter the initial model.
Program Source Code
1
3
Model2
4
Reality(a) Code centric workflow
Program Source Code
1
3
Model2
4
Reality (b) MDE workflow Program1
3
Model Reality4
Source Code(c) Object focused workflow
42 3.1 Motivation We describe how this happens for three software engineering practices, the code centric approach (e.g. by using a mainstream OOP like Java), the MDE approach, and the object-focused modeling approach, which is our vision. In Figure 3.3 we detail the workflow of each practice.
Code Centric Workflow
Mainstream OOP practices revolve around the notion of source code. Models are only implicitly part of the programming process, therefore Adele omits de- scribing it, and goes directly to writing the source code. She refines the specifi- cation by typing precise class and method definitions. Afterwards she compiles and runs an executable program. When Adele notices that she missed to distin- guish the environment entity, she is forced to discard the executable, then add a new class definition to the source code, and perform the necessary textual editions to integrate it into the existing model. Given that the source code and the executable are in different technological spaces, the program is deemed obsolete because the source code and the executable program cannot directly interoperate with each other. The latter is the main reason why code-centric practices hinder flexible modeling activities.
MDE Workflow
Adele describes the model using a modeling language, such as UML. Then she uses MDE tools to automatically generate the source code, to ultimately compile the source code into a platform dependent computer executable pro- gram. Model transformation (MT) is an essential part of MDE, thus several tools—termed roundtrip engineering tools—support UML transformations and synchronization between the diagrams and the source code. The advantage is that they automatically bridge the gap between the diagrams and the code, en- abling the use of high level views for comprehending the model without losing the features offered by the tools for writing the programs.
Roundtrip engineering tools have not been widely adopted because the di- agrams are inert models, while the source code remains the complete specifi- cation of the system under construction [53]. The latter tools are mainly used as palliatives for resolving navigation and comprehension issues when dealing with source code [37]. The value of MDE models increases when they serve other purposes than just contemplative models used only for documentation or visualization purposes [39]. This occurs when MDE models are made exe- cutable by introducing a set of possible actions together with a complete code
43 3.1 Motivation generation or model interpretation engine. The drawbacks are that MDE tools are simpler than a full blown object-oriented programming language, generally based on a state machine, although recent work is improving the capabilities of such tools. Moreover, to validate the simulation model, Adele has to open an- other environment to run the validation, thus hindering interoperability which prevents, for instance that the model is automatically made aware of the latest validation and transformation results.
Object focused Workflow
In our vision, Adele describes the model using a visual high level language, which depicts the object model view on the simulation system under construc- tion. Instead of source code, the program’s full specification is the model itself, and the notion of code is used for specifying behavior at the method level. Adele writes methods such as simulate and terminate, and associates them to the simulation model. The program consists of a world of collaborating objects, such as the simulation model and meta-model, the simulation object and the multicellular organism object. For instance, when Adele introduces the con- cept of environment in the model, she simply resends the message simulate to the simulation and the program continues running, now collaborating with an environment object. In the object-focused workflow, the running program, the model and its multiple views, the model transformations and model validators, all coexist in the same environment, and are manipulated using the same tools. Objects and message passing are the means to describe the meta-models, mod- els, and the programs. This enables full interoperability between all artifacts.
3.1.3
Summary
We described the programming process, and the different steps involved in crafting computer systems with a purpose, i.e. to solve a problem from real- ity. We presented the differences between software engineering practices that guide the process of crafting software systems, and revealed them by means of a scenario. We discussed the drawbacks of traditional code centric practices, and current model based practices: the diversity of technological spaces that the produced artifacts live in hinders interoperability between them, and more importantly they push the program too far away from the models. We proposed a vision where all the steps involved in the programming process transparently interoperate, by strictly adhering to the unifying principle which states that ev- erything is an object. Next, we describe the embodiment of that vision.