Software product lines using FODA: a formal approach

摘要

El término línea de producción en inglés product line evoca a menudo la imagen de una fábrica de coches con un conjunto de brazos mecánicos especializados en colocar piezas, oudtareas específicas como atornillar, soldar o ensamblar para conseguir, como producto final, un coche de manera rápida, invirtiendo la menor cantidad de recursos posibles, entre ellos, tiempo y dinero. Esta metodología se ha aplicado en contextos totalmente diferentes a la fabricación de coches, como por ejemplo en el entorno de la alimentación o el textil, entre otros. En los últimos años, en el campo del desarrollo de software se está investigando cómo aplicar los principios de esta metodología para el desarrollo de aplicaciones de software de alta calidad optimizando los recursos asignados para su implementación. La metodología de las líneas de producción, también conocida como producción en masa dentro del contexto informático, es sustancialmente distinta a la metodología anterior. Siudtomamos literalmente el significado clásico, alguien podría pensar que el problema al que se enfrenta el mundo informático es obtener n copias distintas de un determinado programa. Éste no es el principal problema de la informática, ya que copiando n veces el programa en diferentes archivos (ya sean medios físicos, internet, entre otros) podemos obtener un conjunto de copias fieles, rápidas y a bajo coste sobre el programa original. El problema al que nos enfrentamos es el siguiente. Supongamos que tenemos una empresa E que está desarrollando un software de gestión para dos empresas distintas X e Y . Ambos desarrollos tienen partes comunes y no comunes entre si. La empresa E quiere reducir costes y aprovechar parte del desarrollo de X en Y y viceversa. Una posible alternativa para E sería implementar en primer lugar el producto para la empresa X y luego para Y . La alternativa que propone la aplicación de una metodología de línea de producción para este caso se basaría en los siguientes puntos. Primero definir todas aquellas características comunes y no comunes de los productos a desarrollar para las empresas X e Y . De esa manera determinar los puntos de variación y las variantes que puedan existir entre los componentes que conformarían el conjunto de productos finales, entre ellos X e Y . Seguidamente, implementar y probar de manera exhaustiva una plataforma que implementeudel conjunto de funcionalidades requeridas por ambos clientes. Finalmente, desarrollar módulos que personalicen cada aplicación con las necesidades de cada una de las empresas. Un ejemplo muy gráfico de este tipo de desarrollo lo podemos encontrar en la construcción de aplicaciones para teléfonos móviles. Pensemos en dos modelos diferentes de móviles de la misma compañía. Seguramente la plataforma para ejecutar todas las aplicaciones (llamadas, mensajes, IM, entre otras) es la misma en los dos sistemas. Sin embargo la posibilidad de utilizar WIFI o Bluetooth podría corresponder a cada teléfono en particular. La unidad básica de una línea de producción es llamada característica o en inglés feature. Una característica puede ser un módulo, la utilización de una tecnología, o en un conceptoudmás general, cualquier componente funcional reutilizable. Las relaciones entre las distintas características que componen una línea de producción de software, establecen las posibles configuraciones de los productos. Al conjunto de relaciones y características se le es llamado modelo de características, también conocido como feature models. Anteriormente mencionamos que el desarrollo de una plataforma común, además de tener que representar todas aquellas características comunes y no comunes entre los productos, debe ser un entorno altamente testeado. Determinar la existencia de fallos en dicha plataforma es una tarea no trivial. La utilización de métodos formales nos ayudan a automatizar este proceso; de aquí surge la necesidad de definir modelos formales relacionados con la producción masiva de software. La principal contribución de este Trabajo de Fin de Máster se centra en definir un marco formal para un modelo de características que actualmente se está utilizando en el desarrollo de software(1). Proponemos no solo la sintaxis de las características y sus relaciones, sino también proveemos tres diferentes semánticas, operacional, denotacional y axiomática, equivalentes entre sí, que permitirán deducir propiedades interesantes de los sistemas. A continuación presentamos la estructura de este trabajo.ud1. En el Capítulo 1 se realizará una reseña sobre las Líneas de producción de software y Modelos de características. Se hará una introducción sobre el proceso de desarrollo sistematizado de software y las distintas maneras de modelar las partes funcionales de un producto de software. De tal manera que el lector pueda entrar en contexto con el tema central de este proyecto. Entre las metodologías estudiadas estánud- Feature Oriented Domain Analysis (FODA).ud- Product Line Use case modeling for Systems and Software engineering (PLUSS)ud- Reuse-Driven Software Engineering Business (RSEB)ud2. A continuación, en el Capítulo 2 se presentará un estado del arte sobre distintas técnicas que permiten la especificación de Modelos de características utilizando métodos formales; entre ellos los Sistemas de Etiquetado de Transiciones, Álgebras de Procesos, Sistemas de Transiciones Modales y Lógica Proposicional.ud3. En el Capítulo 3 se especificará una nueva forma de representar los Modelos de características utilizados en FODA. Este capítulo contiene nuestras principales aportaciones al área. Primero se desarrollará un álgebra que traduzca los diagramas presentados por FODA (fodaA). Luego se definirán tres semánticas para fodaA y se demostrará que las semánticas definidas anteriormente son equivalentes.ud4. Y por último en el Capítulo 4, se mostrará una herramienta, para el análisis automatizado de Modelos de características llamada AT. Adicionalmente se mostrará un caso de estudio no trivial para el modelado de software. En este caso se modelará una herramienta que permite hacer streaming de una señal de vídeo y se ilustrará el marcouddescrito en el capítulo anterior. udPara concluir el Trabajo de Fin de Máster, en el Capítulo 5 se mostrarán las conclusiones y posibles trabajos futuros en esta área de investigación.ud(1) Feature Oriented Domain Analysis (FODA)udud[Abstract]udProduct line term often evokes a car factory image with a specialized set of mechanical arms to individually assembly pieces, or do some specic tasks such as screwing, welding,udetc. to be able to get as a nal product, a car as soon as possible, spending the minimum amount of resources, among them time and money. This methodology has been applied inudentirely dierent contexts, from cars manufacture to textile fabrics among others [32]. In recent years, inside the software development eld 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 fulll clients requirements. Product line methodology in the context of computer science, signicantly diers from the other examples mentioned. If we use this approach, people might think that the problem may be solved easily by getting n dierent copies from some particular software. The main problem is not the creation of multiple copies of the same software into dierent locations. The problem that we face is this. Suppose that we have a company E which is developinguda management software for two dierent 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, dene 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 nal 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 rst on what is common to all products, and then in what is dierent [28]. Components must be created for being reused by all, or most of the possible congurations (functional variant of a software product). These components can be developed from scratch or derived from other platforms. This exible design allows to reuse these components with dierent congurations for a particular solution; in this way, mass customization of a set of well dened products is provided. This customization requires eort, but exibility 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 work-ows. It may also require to adopt new technologies within the company. Software is flexible and easily customizable, but wrong decisions in terms of dening the production engineering process can be expensive, therefore, it is required to have a perfect knowledge of the businessudlogic 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 dierent clients or even for entirely dierent 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 congurations for audproduct in the SPL. This variability, is dened 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 dened in purpose. udA graphic example of this type of development can be found in software developments for mobile phones. Consider two dierent 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. udThe basic unit of a production line is called feature. A feature can be a particular module, the use of a specic technology, and, in general, any reusable functional component. The relationships between features in a SPL builds products congurations, the relationships andudfeatures set is called feature model. udSince 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 dene formal models related to massive software production. The main contribution of this Master Thesis work focuses on dening a formal framework for a widely used feature model in software development(3). It has been done under(4) the Facultad de Informatica of Universidad Complutense de Madrid. We have dened a formal syntax to express the features and their relationships. And also we have dened 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. ud. First, in Chapter 1, we give an introduction to Software Product Lines and Feature Modeling. We describe the systematic software development process, and we showudsome dierent 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. Weudoverview a state of art over SPLs, detailing several methodologies to specify software systems. Among them are:ud- Feature Oriented Domain Analysis (FODA).ud- Product Line Use case modeling for Systems and Software engineering (PLUSS)ud- Reuse-Driven Software Engineering Business (RSEB)ud. Next, in Chapter 2 will overview the state of art over dierent formalisms that allow the specication of Feature Models using Formal Methods, including Labelled TransitionudSystems, Process Algebras, Modal Transition Systems and Propositional Logic. ud. In Chapter 3 we present our formalism to represent Feature Models using FODA. ud. In Chapter 4, we describe a tool, called AT, for the automated analysis of feature models. Additionally, we show a non-trivial case study for modeling video streaming software products.ud. To conclude this Master Thesis Project, Chapter 5 shows some conclusions and some possible lines of future work.udud(2)Software Product Line (SPL)ud(3)Feature Oriented Domain Analysis (FODA)ud(4)The Spanish MEC project TESIS (TIN 2009-14312-C02-01)ud