7.3
Derivation process in our Software Product
Line
The derivation process is the actual generation of a product from a SPL. This step of our methodology serves to analyse the particulars for the derivation of products within our product line.
In most SPL the analyst simply selects a set of features and then the derivation engine assembles the required components into the final source code. In the case of our SPL, given that each web-based GIS is built for a specific data domain, the selection of features is not enough to build the products. Hence, in the first step of the derivation process for the products of our software product line, the analyst needs to provide the data model definition for the product. This way, the code generated can adjust to the specific data model for the product. There is already another tool that creates web-based GIS applications from a data model,
GENGHIS [DMG13], but, unlike our SPL, the data model is the only variability
of the products generated by GENGHIS, being every product exactly the same application with a different data model.
The actual feature selection is the second step of our derivation process. The analyst selects a set of features from the feature model, and this selection must be
validated within the derivation process (using operations defined in [BSRC10], for
example), so the analyst receives feedback in case he or she makes a mistake in the selection.
At this point, the analyst has chosen the entities that the application will manage, and the set of features that the application will provide. However, not even this is enough for products of our domain: just deciding to have the feature “map viewer” does not provide information regarding how many map viewers the product requires or which layers should be shown in each map viewer. The analyst needs to answer these questions among others, and some of them need to be answered for each one of the map viewers of the product:
1) Which base layer uses the map viewer?
2) Which entity or entities are shown in the map viewer?
3) Can the user make a textual search over the elements shown in the map viewer? 4) Can the user click on the elements shown in the map viewer? What happens if
he or she clicks?
94 Chapter 7. Architecture Evaluation and Derivation
6) . . .
All these options do not belong to the feature model but are something specifically related to each one of the products. Thus, they belong to the application engineering domain and our derivation process needs to provide a way to define all these aspects. Moreover, there are more features susceptible of this kind of specialization. For example, the set of forms that the final product will have, the menu entries that we want to show (instead of just showing everything) or the sorting order of these entries.
To summarize, our domain requires a further step beyond the selection of features or the definition of the data model. We have called this step parametrization of the product. It is important to note that this step does take into account both the data model and the feature model defined previously, since the parameters or “questions to ask” depend on which features are selected or which entities are defined.
For example, to configure a map to visualize the cars managed by the application, we first need to include an entity “Car” within our data model.
So far, we have described the requirements of the process regarding the “inputs” required, but we also need to point out some requirements about how this derivation is produced and how should be the code produced by it. These requirements are the result of discussion with project managers from Enxenio, and they reflect some requirements that the product must comply with in order to integrate the SPL within their organization:
• Static binding [ABKS13]. The product is the generated code itself, so it is
important that the implementation technique allows derivation in the earliest stage, before the compilation step, to get the product variant source code.
• Clean output code. After generating each product, the code may evolve
independently from the platform because developers may modify it with custom features not belonging to the platform. To allow this, the final code must be maintainable and as well-written as possible, and must not depend on anything beyond the own product (e.g., implementing variability with aspects makes the product dependant of them).
• Allow different programming languages. The implementation of web applica-
tions, nowadays, involves lots of different programming languages. Just in the client side, HTML, JavaScript and CSS are the main ones, but there are many frameworks that do not work directly with these but uses many other
languages to generate them, such as template engines like Jade1, JavaScript
7.4. Summary 95
derived languages like Dart2or TypeScript3, or stylesheets preprocessors like
Sass4. In the server side, there are many choices to implement the features
depending on the ecosystem: Java for Spring, JavaScript (or any variant) for Node, PHP, Ruby, etc. Therefore, our derivation engine has to handle different programming languages.
• IDE independent. The technique used cannot impose any IDE or tool
restriction to the developers of the source code. Many of the existing tools [ADT07,MSC+14,MTS+14] share the same problem: they depend on an outdated IDE. We want to avoid this dependency, making our derivation engine independent of any other software as much as possible.
• Derivation independent of the design of the products. This is, the products
should be very close to the same products if they were manually developed; “sacrifices” in the code just to fit the derivation engine shall be minimum or
null.
7.4
Summary
In this section we have described the last two steps in our methodology: the architecture evaluation and the derivation of a specific product.
In order to do a proper architecture evaluation, we have gone through each one of the different components and services identified for our architecture and we have joined them with features extracted from our set of requirements. Every time there were miss-matches between both elements, it was a time for a new iteration in our process, adjusting both the feature model and the product line architecture until both things were totally coherent with each other.
Afterwards, once the PLA is finished and the traceability is maintained, the SPL is ready to be used to generate products, and we have proposed a set of requirements for the derivation process. These requirements are decisive for the evolution of the platform, and the derivation engine used to generate the products for this line must comply them.
2https://www.dartlang.org/ 3
https://www.typescriptlang.org/
Part III
GISBuilder: a tool for the
semi-automatic generation of
web-based GIS applications
8
SPL implementation techniques &
Scaffolding: state of the art
8.1
Introduction
In the previous part, we have fully detailed the definition of our software product line for web-based geographic information systems. We have identified the requirements of the products, we have designed an architecture for them, and finally we have described how the derivation of these products must be done. Once this definition
is finished, the next step is its actual implementation. In SPLE, the actual
implementation is usually a very simple process (or at least a non-interesting
process) in which developers must code the different features. However, we
defined some very specific and advanced requirements for the derivation of each product (see Section 7.3) that are not contemplated by any state of the art SPLE implementation technique. In this part we show the particular implementation of our SPL (see Chapter 9), but first, we describe the state of the art regarding SPLE implementation techniques and their issues with the requirements of our derivation process, as well as basic concepts about scaffolding, that will help the reader to better understand the importance of our solution.
100 Chapter 8. SPL implementation techniques & Scaffolding: state of the art