implementing product line variabilities - presentation

Universidade Federal de Alagoas - UFAL - Campus A. C. Simões - Tabuleiro do Martins - Maceió - AL, CEP: 57072-970 - Instituto de Computação (IC)

Implementing Product Line Variabilities :: Implementação de Variabilidades em Linhas de Produto de Software :: Seminário :: Prof. Arturo Hernández

Implementing Product Line VariabilitiesImplementação de Variabilidades em Linhas de Produto de Software

Michel Alves dos Santos :: Ailton Felix de Lima Filho

Universidade Federal de Alagoas, Campus A. C. SimõesTabuleiro do Martins - Maceió - AL, CEP: 57072-970Docente Responsável: Prof. Dr. Arturo Hernández

{michel.mas,afdlf2}@gmail.com

08 de Outubro de 2012

Michel Alves • Ailton Felix : Bacharelado em Ciência da Computação Instituto de Computação - Bloco 12 - Campus A. C. Simões - UFAL



Introdução

Principais Objetivos da Apresentação

Implementing Product Line Variabilities

Michalis Anastasopoulos

Fraunhofer Institute for Experimental Software Engineering

Sauerwiesen 6D-67661 Kaiserslautern, Germany

+49 (0) 6301 707 [email protected]

ABSTRACTSoftware product lines have numerous members. Thus, a product lineinfrastructure must cover various systems. This is the significantdifference to usual software systems and the reason for additionalrequirements on the various assets present during software productline engineering. It is imperative that they support the description ofthe product line as a whole, as well as its instantiation for thederivation of individual products.

Literature has already addressed how to create and instantiate genericproduct line assets, such as domain models and architectures togenerate instance specific ones [1, 2, 3], yet little attention has beengiven on how to actually deal with this genericity at the code level.

This paper addresses the issue of handling product line variability atthe code level. To this end various implementation approaches areexamined with respect to their use in a product line context.

KeywordsSoftware product lines, product line variability, implementationapproaches, implementing variabilities, traceability

1. INTRODUCTIONSoftware product lines have numerous members. Thus, a product lineinfrastructure must cover various systems. This is the significantdifference to usual software systems and the reason for additionalrequirements on the various assets present during software productline engineering. It is imperative that they support the description ofthe product line as a whole, as well as its instantiation for thederivation of individual products. To reflect a product line, the generic assets have to cover all elementsthe product family is built from, and their corresponding compositionrules. Clarifying how the various parts may be combined is a verychallenging task.Generic assets differ from specific ones in the fact that they embracecommon and variable product aspects. Generic assets can beinstantiated, that is, product-specific assets can be derived from them.Specific assets on the other hand are uniquely mapped to product linemembers.Products within a product line context consist of constant as well asvariable elements. Dependencies between these elements do exist(e.g., elements may exclude each other or one element may make theintegration of a second one a necessity). Hence only a subset of allcombinations are correct and complete configurations. Therefore we

have to restrict the product line infrastructure to cover only the set ofvalid family members.

A decision model structures the variability within a product line as aset of decisions to be resolved. Interrelations between decisions arecaptured as well. Such a model is also generic, that is, it can be alsoinstantiated. In the instance all decisions are resolved. Every diversityin each generic asset must be connected to an open

decision in the decision model. The presence of a decision model isimportant because a decision model specifies an instance of eachgeneric asset and thus a complete product line member.

Literature has already addressed how to create and instantiate genericproduct line assets, such as domain models and architectures togenerate instance specific ones [1, 2, 3], yet little attention has beengiven on how to actually deal with this genericity at the code level.Variabilities and their composition rules must also be reflected at thecode level, and be instantiated when creating individual productinstances.

This paper addresses the issue of handling product line variability atthe code level. To this end various implementation approaches areexamined with respect to their use in a product line context. The restof this paper is structured as follows: section 2 introduces some of therelevant related work, this is followed by a discussion on the types ofvariabilities to be supported and the requirements for theirimplementation support (section 3), we then introduce our frameworkfor comparison of implementation approaches (section 4), presentsome examples of the techniques discussed (section 5), and brieflydiscuss evaluation criteria needed for implementation techniques(section 6). Section 7 comments on some of our practical experienceand section 8 concludes the paper with a short discussion of thevarious research needs we have been able to elicit so far.

It should be noted that this paper�s purpose is not to impart profoundinsights into the technologies but only to report on the possibilities oftheir use for handling code variabilities in a product line. Finally wemust mention that the set of approaches presented here is notcomplete. We are certain that other approaches may also beadvantageous in this context. We believe though that their majoritybears upon the collection introduced here.

2. RELATED WORKJames Coplien in his book �Multi-Paradigm Design for C++� [4]presents a design method that takes advantage of the popularprogramming language�s support for multiple paradigms, such asclasses, over-loaded functions, templates, modules, and proceduralprogramming. Each of those paradigms is described as being uniquelysuitable for solving a specific class of design problems. Thisconclusion is particularly important for product line engineeringbecause the book has a strong focus on problems related to therealization of commonalities and variabilities.

David Sharp has studied [5] existing object oriented techniques thatfacilitate anticipated variabilities between different software versions.Parameters of variations, which refer to the different aspects ofsoftware that can vary, are being initially identified. Tailoringtechniques featured by languages like C++ and Ada95 are describednext. Each technique is categorized with respect to the supportedcombinations of variabilities for each parameter of variation. Scope,

1 This work was done while the author was working for the IESE

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and thatcopies bear this notice and the full citation on the first page. To copyotherwise, or republish, to post on servers or to redistribute to lists,requires prior specific permission and/or a fee.SSR�01, May 18-20, 2001, Toronto, Ontario, Canada.Copyright 2001 ACM 1-58113-358-8/01/0005...$5.00.

Cristina Gacek1

Centre for Software ReliabilityDepartment of Computing Science

University of NewcastleNE1 7RU Newcastle upon Tyne, United Kingdom

+44 (0) 191 222 [email protected]

109

I Debater sobre o conteúdo do paperintitulado Implementing ProductLine Variabilities (Autores: M.Anastasopoulos and C. Gacek.).

I Comentar a respeito de algunstrabalhos relacionados ao tema.

I Debater sobre os requerimentosnecessários a implementação datécnica.

I Analisar os tipos mais comuns (elargamente aceitos) de Variabilidade.

I Apresentar uma comparação deabordagens de implementação ealguns critérios de avaliação.

O que entendemos por Variabilidade?




Trabalhos Relacionados

Apanhado de Trabalhos Relacionados

James Coplien, Multi-Paradigm Design for C++, Addison Wesley, 1995

David C. Sharp, “Containing and Facilitating Change Via Object OrientedTailoring Techniques,” to appear in Proceedings of The First Software

Product Line Conference Denver, Colorado, August, 2000

Mikael Svahnberg, Variability in Evolving Software Product Lines,Licentiate thesis, Blekinge Institute of Technology, Department of

Software Engineering and Computer Science, Karlskrona, Sweden, 2000

Jilles Van Gurp, Jan Bosch, and Mikael Svahnberg. On the Notion ofVariability in Software Product Lines. In Proceedings of the WorkingIEEE/IFIP Conference on Software Architecture (WICSA’01), 2001.




Requerimentos

Requerimentos para Suporte a Implementação

Figure: Visão geral dos tipos de feature e critérios de inclusão em uma linha de produto.

Toda variabilidade encontrada em um contexto de linha de produto pode ser conectada a suafeature correspondente. A relação entre feature e variabilidade é de 1:N, pois a implementação

da mesma geralmente se encontra espalhada pelos aquivos fontes e módulos.




Tipos de Variabilidade

Categorização dos Tipos de Variabilidade

Classificação em Tempo de Resolução (Binding Time)

Em tempo de compilação (Compile-time), em tempo de ligação (Link-time), em tempo deexecução (Runtime) e em tempo de atualização (Update-time/Post-runtime).




Comparação de Abordagens de Implementação

Abordagens para Implementação de Variabilidade

Figure: Matriz de comparação de abordagens de implementação de variabilidade.




Comparação de Abordagens - Mapeamento das Linguagens

Mapeamento das Linguagens Usadas na Exemplificação

Figure: Mapeamento de abordagens nas linguagens: C++, Delphi, Java e Smalltalk.




Exemplos - Delegação, Compilação Condicional e Design Patterns

Utilizando Delegação, Compilação Condicional e Design Patterns

Figure: Utilização de Delegação, Compilação Condicional e Design Patterns.




Avaliação da Variabilidade

Critérios de Avaliação na Implementação de Técnicas

No artigo são identificados três tipos de critérios:

Critérios Fundamentais de Comparação eAvaliação

Critérios Extendidos de Comparação eAvaliação

Elementos Primitivos Existentes emLinguagens




Avaliação da Variabilidade - Critérios Fundamentais


Critérios Fundamentais de Comparação e Avaliação

I Escopo: Identifica a menor unidade de integração suportada.I Flexibilidade: Medida do tempo de integração.I Eficiência: Custo de suporte da integrabilidade.I Compatibilidade Binária: Medida de compatibilidade com

bibliotecas pré-compiladas.

Tal lista é extendida pelos autores através de mais seteatributos chamados de critérios extendidos.




Avaliação da Variabilidade - Critérios Extendidos


Critérios Extendidos de Comparação e Avaliação

I Separação de Lógica: Partes variantes e invariantes de código.I Escalabilidade: Impactos na expansão do código.I Rastreamento Realizável: Capacidade de rastrear uma unidade de integração.I Facilidade de Introdução: Grau de reestruturação requerida dos sistemas

quando ocorre a introdução da técnica.I Suporte em Linguagem: Forma com as linguagens existentes podem usufruir

da técnica.I Suporte a Ferramentas: Automação no uso das técnicas.I Facilidade de Contorno: Simulação ou emulação através de outras técnicas.

Outro aspecto interessante que deve ser levado em consideração no momento daavaliação é a descoberta de elementos primitivos da linguagem.




Avaliação da Variabilidade - Elementos Primitivos


Elementos Primitivos Existentes em Linguagens

I Adição de Níveis de Indireção: Técnicas como delegation. Pode causarimpactos na eficiência pois toda uma classe deve ser carregada antes dainvocação de um método.

I Ligação Tardia (Late Binding): Utilizada nos mecanismos de herança virtual,ligando código de um método a sua declaração em tempo de execução.

I Ligação Precoce (Early Binding): Manutenção de informação estática.Utilizada em bibliotecas de tipo. Mais rápido que a ligação tardia.

I Tipos Abstratos: Classes Abstratas são um exemplo. Definem funcionalidadesem implementação que geralmente é fornecido em subclasses. Criaminterfaces comuns para acesso as instâncias e reduzem o acoplamento empontos de variabilidade.

I Mecanismos de Composição: Usados para implementar aspectos dos sistemasseparadamente e depois combiná-los para obtenção do sistema final.




Conclusões

Conclusões a Respeito dos Tópicos Apresentados

O Gerenciamento Sistemático de Variabilidade a nível de código é um campoum tanto imaturo, necessitando de mais esforços científico-investigativos.

A migração de sistemas com fraco gerenciamento de variabilidade parasistemas que possuem intenso suporte a essa modalidade pode se tornar

uma tarefa árida.

Diferentes abordagens são necessárias para a resolução de diferentesproblemas, a combinação das técnicas hoje disponíveis é algo que não

pode ser evitado.

Mais trabalhos nessa área necessitam serrealizados!




Agradecimentos

Grato Pela Atenção!Michel Alves dos Santos - [email protected]

Ailton Felix de Lima Filho - [email protected]




Referências Bibliográficas

Referências BibliográficasM. Anastasopoulos and C. Gacek.Implementing product line variabilities.IESE - International Encounter of Systems Engineering, May 2001.

M. Anastasopoulos, J. Bayer, O. Flege, and C. Gacek.A process for product line architecture creation and evaluation.Technical report, IESE, 2000.

E. Gamma.Design Patterns: Elements of Reusable Object-Oriented Software.Addison-Wesley, 1994.

O. Lewis.Performance Issues Of Variability Design in Embedded System Application Families.PhD thesis, November 2000.

M. Svahnberg.Variability in envolving software product lines.Master’s thesis, Blekinge Institute of Technology, Departament of Software Engineering andComputer Science, Karlskrona , Sweden, 2000.


implementing product line variabilities - presentation

Education