Software product lines using FODA: a formal approach

Product line term often evokes a car factory image with a specialized set of mechanical arms to individually assembly pieces, or do some specific tasks such as screwing, welding, etc. to be able to get as a final product, a car as soon as possible, spending the minimum amount of resources, among them time and money. This methodology has been applied in entirely different contexts, from cars manufacture to textile fabrics among others [32]. In recent years, inside the software development field it has been investigated how to apply the principles of this methodology, for high quality software development, optimizing the implementation time as well as the amount of money required to fulfill clients requirements. Product line methodology in the context of computer science, significantly differs from the other examples mentioned. If we use this approach, people might think that the problem may be solved easily by getting n different copies from some particular software. The main problem is not the creation of multiple copies of the same software into different locations. The problem that we face is this. Suppose that we have a company E which is developing a management software for two different companies X and Y . Both developments have common and uncommon parts between each other. Company E wants to reduce costs and take advantage of reusing resources to build software products for X and Y . A possible alternative would be the implementation of a product for company X, and then build the product for Y separately. The proposed alternative by the application of a production line methodology for this case, should be based on the following points. First, define all the common and uncommon features between X and Y . In this way, determine the variation points and variants that may exist between the components that will compose the set of final products among the products for companies X and Y . Next, implement and test exhaustively a platform that represents the set of functionalities required by both companies. A common platform design, for a diverse set of components is not a trivial task. It involves preparation for mass customization, focusing first on what is common to all products, and then in what is different [28]. Components must be created for being reused by all, or most of the possible configurations (functional variant of a software product). These components can be developed from scratch or derived from other platforms. This flexible design allows to reuse these components with different configurations for a particular solution; in this way, mass customization of a set of well defined products is provided. This customization requires effort, but flexibility is the key for mass customization success and it is a must for it. A reorganization process for the mass customization initiative may require additional organizational units to guide towards standardization of procedures and workflows. It may also require to adopt new technologies within the company. Software is flexible and easily customizable, but wrong decisions in terms of defining the production engineering process can be expensive, therefore, it is required to have a perfect knowledge of the business logic within the organization and of the solution to be implemented. On one hand, a lot of software products are derived from a common base, and they represent essentially the same context, because they are variations or successive variations of a single product. For instance, if we strip down a car we can see that the main parts are the same (engine, transmission, chassis, among others), between the luxury and standard version. On the other hand, SPL 2 engineering aims to support a wide range of products. These products may be for the same client, for different clients or even for entirely different markets. As a result, variability management is a very important concept in SPL approach. Variability design is about incorporating components that represents the range of possible configurations for a product in the SPL. This variability, is defined during the domain engineering process [18]. When we use the term variability, we are referencing to the ability that something has to change in time. This variability is defined in purpose. A graphic example of this type of development can be found in software developments for mobile phones. Consider two different models of phones from the same company. Surely the platform to run all applications (calls, messages, IM) is the same in both models. However, the possibility of using WIFI or Bluetooth for each phone may vary. The basic unit of a production line is called feature. A feature can be a particular module, the use of a specific technology, and, in general, any reusable functional component. The relationships between features in a SPL builds products configurations, the relationships and features set is called feature model. Since in the SPL frameworks software is made of reusable components it is very important to have tools that allow the correct development. Not only within any component, but also in the whole framework. The use of formal methods aims to automate this task. This raises the need to define formal models related to massive software production. The main contribution of this Master Thesis work focuses on defining a formal framework for a widely used feature model in software development. It has been done under the Facultad de Informática of Universidad Complutense de Madrid. We have defined a formal syntax to express the features and their relationships. And also we have defined three different formal semantics: an operational semantics, a denotational semantics and an axiomatic semantic. We have proved that all three semantics are equivalent. Here is the structure of this work. • First, in Chapter 1, we give an introduction to Software Product Lines and Feature Modeling. We describe the systematic software development process, and we show some different approaches to model the functional parts of software products. In this way, the reader can get into the context of the central line of this research project. We overview a state of art over SPLs, detailing several methodologies to specify software systems. Among them are: – Feature Oriented Domain Analysis (FODA). – Product Line Use case modeling for Systems and Software engineering (PLUSS) – Reuse-Driven Software Engineering Business (RSEB) Software Product Line (SPL) Feature Oriented Domain Analysis (FODA) The Spanish MEC project TESIS (TIN 2009-14312-C02-01)