Implementing Product Line Variabilities

192 views

Published on

A abordagem de linha de produto de software tem como objetivo principal promover a geração de produtos específicos com base na reutilização de uma infra-estrutura central. Uma linha de produto representa um conjunto de sistemas que compartilham características comuns e gerenciáveis que satisfazem as necessidades de um segmento particular do mercado ou de uma missão. Esse conjunto de sistemas é também chamado de família de produtos. Os membros da família são produtos específicos desenvolvidos de maneira sistemática a partir de um conjunto comum de artefatos da linha de produto.

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
192
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Implementing Product Line Variabilities

  1. 1. Implementing Product Line Variabilities Ailton Felix de L. Filho :: Michel Alves dos Santos ∗ Outubro de 2012 Conteúdo 1 Introdução 1 2 Requisitos de Apóio à Implementação 2 3 Quadro para Comparação de Abordagens de Programação 2 3.1 Exemplos . . . . . . . . . . . . . . . . . . . 3 4 Avaliação 3 5 Conclusões 3 Referências 4 1 Introdução A abordagem de linha de produto de software tem como objetivo principal promover a geração de pro- dutos específicos com base na reutilização de uma infra-estrutura central. Uma linha de produto representa um conjunto de sistemas que compartilham características comuns e gerenciáveis que satisfazem as necessidades de um segmento particular do mercado ou de uma missão. Esse conjunto de sistemas é também chamado de família de produtos. Os membros da família são produtos específicos desenvolvidos de maneira siste- mática a partir de um conjunto comum de artefatos da linha de produto. O SEI (Software Engineering Institute), através da iniciativa PLP (Product Line Practice), estabe- leceu as atividades essenciais de uma abordagem de linha de produto. Essas atividades, como podem ser vistas na Figura 1, são o Desenvolvimento do Núcleo de Artefatos, também conhecida como Engenharia de Domínio, o Desenvolvimento do Produto, tam- bém conhecida como Engenharia de Aplicação, e o Gerenciamento da Linha de Produto [Jun05]. Uma infra-estrutura de linha de produto de soft- ware cobre vários sistemas, isto devido ao número de membros que uma linha de produto possui. Para mostrar uma linha de produto, os assets (re- cursos) de um software têm de cobrir todos os ele- ∗Bacharelandos em Ciência da Computação, Univer- sidade Federal do Estado de Alagoas (UFAL). E-mail: {afdlf2, michel.mas}@gmail.com. Disciplina: Linha de Produto de Software. Docente Responsável: Arturo. Figura 1: Atividades essenciais de linha de pro- duto de software. Os três círculos indicam que as atividades de uma linha de produto são alta- mente interligadas e iterativas. mentos da família do produto de onde o mesmo foi construído e suas correspondentes regras de compo- sição. O artigo aborda a questão de manipulação de va- riabilidade de linha de produto (ver [WEI99]) em nível de código. Para esse fim várias abordagens de implementação são examinadas com respeito ao uso das mesmas em um contexto de linha de software. A proposta do trabalho não é transmitir mais pre- ocupação em tecnologias, mas somente informar so- bre as possibilidades de seu uso para manipular va- riabilidades de código em linha de produto. É dei- xado claro também que o conjunto de abordagens apresentado no trabalho não é completo. Em [Cop95] um método de design que leva vanta- gem do popular apóio a linguagem de programação para múltiplos paradigmas é apresentado. O livro mantém um foco nos problemas relacionados a com- preensão de comunalidades e variabilidades, o que o torna de interesse para a engenharia de linha de pro- duto. 1
  2. 2. 2 Requisitos de Apóio à Im- plementação As variabilidades podem ser inicialmente identifi- cadas por meio do conceito de feature [VAN01]. Este conceito teve origem na engenharia de domínio. Fe- ature pode ser definida como uma característica de um sistema que é relevante e visível para o usuário final [KAN]. Toda variabilidade encontrada em um contexto de linha de software pode ser conectada com uma feature correspondente. A relação entre feature e variabilidade é de 1 : N, pois a implementação da mesma geralmente se encontra espalhada pelos ar- quivos fontes e módulos. Uma visão global dos tipos de features e o critério para inclusão da mesma em uma instância de linha de produto pode ser vista na Tabela 1. Tipo de Feature Significado Obrigatória A feature deve ser sempre incluída. Opcional A feature é um complemento independente que pode ser incluída ou não. Alternativo A feature substitui uma outra feature quando incluída. Mutualmente Inclusiva Para que uma feature seja incluída, outras features específicas devem ser também incluídas e vice-versa. Mutualmente Exclusivas Para que uma feature seja incluída, outras features específicas não devem ser incluídas e vice-versa. Tabela 1: Tipos de features. Variablidades podem ser principalmente classifi- cadas como positivas e negativas. A Tabela 2 mostra como as variablidades podem ser categorizadas. Tipo de Variabilidade Significado Positiva Quando adicionam funcionalidades. Negativa Quando removem funcionalidade. Opcional Quando um código é incluído. Alternativo Quando um código é substituído. Funcional Quando a funcionalidade muda. Plataforma / Ambiente Quando a plataforma ou ambiente mudam. Tabela 2: Tipos de features. Um fator importante no gerenciamento de varia- bilidade é o seu tempo de resolução. Ele indica em qual momento uma ou mais variantes serão associa- das a um determinado ponto de variação [VAN00]. O tempo de resolução de variabilidade pode ser classificado como [ANA01]: • Tempo de compilação; • Tempo de ligação; • Tempo de execução; • Tempos de atualização. O tempo de resolução de variabilidade restringe a escolha de mecanismos de implementação de va- riabilidade. Por exemplo, se uma variabilidade é resolvida em tempo de execução, não se pode implementá-la com um mecanismo que é definido em tempo de compilação [FRI02]. Os principais parâmetros de variação são as inter- faces e as implementações correspondentes. A inici- alização de módulo também é considerada como um possível parâmetro de variação. Uma técnica de implementação claramente conta com a escolha da linguagem de programação. A decisão de qual linguagem usar é tipicamente resol- vida sobre uma instânciação do produto. Portanto a criação e descobrimento de uma aquitetura de re- ferência para uma linha de produto como uma base para instanciação de membros é uma das atividades fundamentais dessa área. 3 Quadro para Comparação de Abordagens de Progra- mação No artigo [MA01] (ver também [ANA01]), várias abordagens para variabilidade de codificação são apresentadas, onde o mesmo descreve as caracte- rísticas de cada um delas, onde também, no mesmo artigo, é possível encontrar uma matriz que faz com- parações entre estas abordagens. São elas: 1. Agregação / Delegação: permite que obje- tos deleguem funcionalidades; 2. Herança: adiciona funções básicas às super- classes e funções especializadas às subclasses; 3. Parametrização: representa software reutili- zável como uma biblioteca de componentes pa- rametrizados; 4. Sobrecarga: esta técnica utiliza o mesmo nome de um elemento para operar de manei- ras diferentes; 5. Propriedades do Delphi: propriedades as- sociadas a ações específicas como leitura ou atualização de dados; 6. Carga Dinâmica de Classe: todas as classes são carregadas na memória assim que estas são necessárias; 7. Bibliotecas Estáticas: contém um conjunto de funções exeternas que podem ser linkadas em um aplicação depois da mesma ter sido compilada; 2
  3. 3. 8. Bibliotecas de Ligação Dinâminca: são carregadas quando necessárias em uma aplica- ção em tempo de execução; 9. Compilação Condicional: possibilita o con- trole sobre os segmentos de código a serem in- cluídos ou excluídos da compilação de um pro- grama; 10. Frames: reuso hierárquico de entidades de montagem de software; 11. Reflexão: é a habilidade de um programa ma- nipular, na forma de dados, algo que representa o estado de um programa durante sua própria execução; 12. Programação Orientada a Aspecto: téc- nica desenvolvida pela Xerox PARC (http: //www.parc.com/); 13. Padrões de Projeto: muitos dos padrões de projeto podem variar e fornecer soluções para o gerenciamento de variabilidade. 3.1 Exemplos Um dos exemplos das técnicas apresentadas é o uso do Padrão de Projeto Builder. O Builder é um exemplo de padrão de criação que pode ser usado para carregar código variante em tempo de execu- ção. Este padrão é adequado quando a lógica da construção de objetos complexos deve ser separada do usuário desses objetos e quando essa lógica deve facilitar a construção de variações. A estrutura do padrão pode ser vista na Figura 2. Figura 2: Padrão Builder. Product representa o objeto complexo a ser cons- truído. O administrador coordena a construção do produto pela chamada do objeto ConcreteBuilder. Esse objeto implementa a mesma interface para cri- ação de partes que é definida na classe abstrata Buil- der. Porém, cada ConcreteBuilder cria partes dife- rentes. 4 Avaliação Qualquer decisão tomada durante o processo de desenvolvimento do software pode comprometer a sua qualidade final. Para se produzir software com alta qualidade, é necessário investir em qualidade em todos os pontos do processo. Qualidade de software é um processo sistemático que focaliza as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos, prevenindo e eliminando defeitos [Bar02]. Para avaliação, um critério de técnica de imple- mentação deve ser definido e uma classificação deve ser feita para expressar o grau de satisfação. Escopo, flexibilidade, eficiência, compatilidade binária são exemplos de qualidades fundamentais que devem ser identificados para comparar e ava- liar técnicas de implementação de linha de produto. 5 Conclusões A gestão sistemática da variabilidade em nível de código é um campo bastante imaturo. É chegada a conclusão de que mais trabalhos nessa área devem ser feitos. Outra conclusão que se é chegada pelo trabalho [MA01] é de que diferentes abordagens foram neces- sárias para dar suporte a diferentes problemas. Isso significa dizer que técnicas precisam ser mapeadas para problemas conhecidos. Além disso, a combina- ção de técnicas disponíveis é algo que não pode ser evitado. Referências [ANA01] ANASTASOPOULOS, M. Implementing product line variabilities, volume 26. ACM SIGSOFT Software Engineering Notes, May 2001. [Bar02] Alexandre Bartié. Garantia de Qualidade de Software. 2002. [Cop95] James Coplien. Multi-Paradigm Design for C++. 1995. [FRI02] FRITSCH, C.; LEHN, A.; STROHM, T. Evaluating variability implementation mechanisms. In In: INTERNATIONAL WORKSHOP ON PRODUCT LINE EN- GINEERING, 2., 2002, Seattle. Procee- dings, pages 59–64, 2002. [Jun05] Edson A. Oliveira Junior. Um processo de gerenciamento de variabilidade para linha de produto de software. Departamento de Informática, Universidade Estadual de Maringá, 2005. [KAN] KANG, K. Feature-oriented domain analysis (foda) - feasibility study. Tech- nical report, Technical Report CMU/SEI- 90-TR-21, SEI/CMU, Pittsburgh. 3
  4. 4. [MA01] Cristina G. Michalis A. Implementing pro- duct line variabilities. Fraunhofer Insti- tute for Experimental Software Enginee- ring and Centre for Software Reliability Department of Computing Science Uni- versity of Newcastle, 2001. [VAN00] VAN GURP, J.; BOSCH, J. Managing va- riability in software product lines. In In: THE WORKING IEEE/IFIP CONFE- RENCE ON SOFTWARE ARCHITEC- TURE, 2000, Amsterdam. Proceedings, 2000. [VAN01] VAN GURP, J.; BOSCH, J. On the no- tion of variability in software product li- nes. In In: THE WORKING IEEE/IFIP CONFERENCE ON SOFTWARE AR- CHITECTURE, 2001, Amsterdam. Pro- ceedings, 2001. [WEI99] WEISS. D, CHI TAU, R. L. Software product-line engineering: a family-based software development process. 1999. 4

×