RiSE – Reuse in Software Engineering Labs ... · Hewlett-Packard Tempo de desenvolvimento...

RiSE – Reuse in Software Engineering Labs http://riselabs.dcc.ufba.br

1.  Introdução / Motivação

2.  Definição de Linha de Produto de Software

3.  Experiências com Linhas de Produto

4.  Implantando uma Linha de Produto

5.  Análise de Domínio

6.  Considerações Finais

7.  Atividade Prática

Software Reuse: Theory and Practice http://wp.me/PMzBA-6B 2

  O modo como bens e produtos são produzidos mudou significativamente com o passar do tempo ◦  Production line: Ford; Boeing (737, 747, 767, 777, 787) ◦  Produção mais barata, porém reduziu as possibilidades de

diversificação

  Produtos de engenharia customizados

  Criação de uma plataforma   Introdução de flexibilidade   Reorganização da companhia


  Kodak / Fujitsu ◦  Em 1987, Fuji lançou a Quicksnap, a primeira máquina

fotográfica doméstica. ◦  Pegou a Kodak de surpresa

  Cresceu de 3 milhões em 1988 para 43 milhões em 1994 ◦  Para reconquistar o mercado a Kodak lançou uma série de

diferentes modelos de câmera, baseados em uma plataforma comum. ◦  Entre Abril de 1989 e Julho de 1990, a Kodak reconstruiu

seu modelo padrão, criando mais 3 modelos   Todos com componentes comuns e mesmo processo de

manufatura ◦  Assim, a Kodak passou a desenvolver câmera mais

rapidamente e com menor custo.

[Robertson and Ulrich 1999; Clark and Wheelwright 1995]


  Noção de plataforma em materiais de escritório ◦  As notas de "Post-it" da 3M são consideradas uma

plataforma da qual foram derivados muitos produtos individuais. Por exemplo, notas de "Post-it" com um logotipo de uma companhia ou marcadores para selecionar páginas em livros, etc.


[Cooper et al. 2001]

•  Redução dos custos de desenvolvimento

•  Melhoria da qualidade •  Redução do time-to-market •  Redução dos esforços com manutenção •  Melhorias na estimativa de custos •  Benefícios para os clientes


[Pohl et al. 2005]

  Pré-requisitos ◦  Habilitar tecnologias ◦  Maturidade do processo ◦  Características do domínio e expertise


"Software product line engineering is a paradigm to develop software applications (software-intensive systems and software products) using platforms and mass customization."

[Pohl et al., 2005]

  Nem tudo é uma linha de produto ◦  Considerar os níveis de maturidade é importante


[Bosch, 2002]

  Muitos casos de sucesso citados pela literatura envolvendo grandes empresas que obtiveram excelentes resultados com a aplicação de Linhas de Produto de Software (Product Line Hall of Fame) ◦  Asia Brown Boveri (ABB)   “The reference architecture of the turbine control system

for the ABB Gas Turbine Family led to shorter development time, higher code quality, and eased the exchange of modules.”

◦  Boeing Company   “The success of the Bold Stroke software product line is

based on the reduction of dependencies between components and the dependency on platform-specific hardware.”


◦  Hewlett-Packard   Tempo de desenvolvimento reduzido em 67%   96% menos defeitos

◦  Philips   Lidera o mercado de pesquisadores europeus no

campo de linhas de produto de software.   Philips Consumer Electronics provê linhas de produto

de software para equipamentos de áudio e vídeo, tais como aparelhos de TV, apresentando uma arquitetura de referência estável.

◦  Além de outros exemplos: CelsiusTech Systems AB, LG Industrial Systems, Lucent Technologies, Robert Bosch GmbH.


  Nokia ◦  Líder mundial no ramo de aparelhos celulares (40% do

mercado) ◦  25~30 novos produtos por ano em mais de 130 países ◦  Suporte:

  58 línguas   Variável número de teclas   Diferentes tamanhos de tela   Diferentes conjuntos de features   Variações de protocolos, operadoras, hardware e estilo (série XX)   Features configuráveis (Liga / Desliga -- > Conectar e usar)

◦  Diferentes Linhas de Software espalhadas pelo mundo. Releases são feitos para outros grupos.   DSP   Arquitetura   Interface com o usuário   Etc.


  Linhas de Produtos da Nokia


  Grande complexidade gerenciada


  Exemplos de componentes – Idioma   Suporte a 58 idiomas   Várias línguas não-latinas (Chinês, Árabe, Hebraico, Thai)   Recurso opcional de T9   Ao alterar a língua ativa, todos os textos devem ser alterados

automaticamente

  Solução   Separar a base de conhecimento da língua do código   Separar aparência de comportamento   Independente da língua escolhida, o código não muda


  Exemplos de componentes – Idioma ◦  Padrão Observer adotado


  Exemplos de componentes – Interface com usuário ◦  Window Manager separa comportamento da aparência


  Exemplos de componentes – Interface com usuário


...

for (int a = 0; a<=10; a++)

AddProfileMenu(MenuArray[a]);

...

  Sugestões: think ahead ◦  Sempre pense na frente ◦  Faça sempre brainstorms sobre todos os possíveis

usos futuros de features ◦  Considere o impacto de novas tecnologias ◦  Considere todas as variáveis que podem ser

configuráveis ◦  Nunca “codifique no duro” (harcode) nada ◦  Enquanto não é necessário prever todo o futuro,

leve-o em consideração no seu projeto (arquitetura). Isso vai salvar muito tempo no futuro.


  Tecnologias de Linhas de Produto são também encontradas no nosso dia-a-dia.

  Exemplos: ◦  Meantime

  adaptações de jogos/software para diferentes dispositivos/celulares;

◦  Geradores de CRUD   Geradores de código fonte para operações básica de

cadastro (inserir, remover, consultar e atualizar) de sistemas web de informação baseado numa arquitetura genérica

◦  Plataforma Eclipse   Arquitetura extensível baseada em plugins que permite a

customização do seu ambiente para diferentes usuários


  Plataforma Eclipse ◦  Arquitetura extensível baseada em plugins que permite a

customização do seu ambiente para diferentes usuários

  Diferentes versões do Eclipse podem ser personalizadas, e elas podem até mesmo “sobreviver” juntas em tempo de execução ◦  Diferentes perspectivas: Modelagem, Implementação,

Testes, Gerência de Configuração, Depuração

  A arquitetura extensível baseada em plugins do Eclipse pode também ser considerada uma arquitetura de linha de produto que permite a criação/geração de vários produtos


  A arquitetura do Eclipse oferece uma estrutura flexível que : ◦  Oferece pontos de extensão específicos que

podem ser estendidos pelo usuário final

◦  A instalação/desinstalação de plugins que estendem os pontos de extensão oferecidos pela plataforma do Eclipse, possivelmente, oferecendo novas plataformas para isso


  Eclipse plugins: ◦  São componentes de código e/ou dados que contribuem

para a extensão da plataforma com alguma funcionalidade, tais como:   novas bibliotecas/APIs   novas visões/perspectivas/editores/depuradores   documentação (help) ◦  Em geral, estendem pontos de extensão oferecidos pela

plataforma (outros plugins), assim como podem oferecer seus próprios pontos de extensão

  Exemplos: ◦  JDT (Java Development Tooling), PDE (Plugin Development

Environment) ◦  JUnit Extensions, Ferramenta de Modelagem UML, etc



plug-in A plug-in B

class C interface I

extensionpoint P extension

contributes

creates, calls

implements

  Engenharia de linha de produto de software baseia-se em dois processos: ◦  Estabelecimento da plataforma (Engenharia de

Domínio)   Gerenciamento de pontos variáveis e pontos em

comum.   Plataforma consiste em: requisitos, projeto do

domínio, implementação de componentes, testes.

◦  Derivando aplicações (Engenharia de Aplicação)   Explora variabilidade de acordo com a necessidades

específicas de cada aplicação.


  Artefatos do domínio ◦  Mapa de produtos ◦  Modelo de variabilidade do domínio ◦  Requisitos do domínio ◦  Arquitetura do domínio ◦  Implementação de artefatos do domínio ◦  Testes de artefatos do domínio

  Artefatos da aplicação ◦  Modelo de variabilidade da aplicação ◦  Requisitos da aplicação ◦  Arquitetura da aplicação ◦  Implementação de artefatos da aplicação ◦  Testes de artefatos da aplicação


  [Weiss e Lai, 1999] ◦  Forma como os membros de uma família de produtos

podem se diferenciar entre si   [Trigaux e Heymans, 2003] ◦  Pontos de variação

  Local específico de um artefato em que uma decisão de projeto ainda não foi resolvida

  Cada ponto de variação tem associado um conjunto de variantes

◦  Variantes   Uma alternativa de projeto para instanciar uma determinada

variabilidade ◦  Resolução de uma variante

  Escolha de uma ou mais variantes do conjunto relacionado


  Variabilidades representadas em termos de features   Feature pode ser definida como uma característica de um

sistema que é relevante e visível para o usuário final [Kang et al., 1990]

  Representação FODA – Feature Oriented Domain Analysis


  Tipos de features ◦  Mandatórias ◦  Opcionais ◦  Alternativas ◦  OR

  Conceitos simples da representação FODA: ◦  Todas as “features-folha” mandatórias devem estar presentes (n

para n) ◦  Qualquer número de features opcionais pode ser incluído (m para

n, 0 < = m <= n) ◦  Exatamente uma feature deve ser selecionada de um grupo de

features alternativas (1 para n) ◦  Pelo menos uma feature deve ser selecionada de um grupo de OR

features (m para n, m > 1)   Dependências ◦  Implicação ◦  Exclusão



A) Monga. B) American Dad – Roger’s Scape. C) Zaak.

  Planejar o domínio ◦  Atividades iniciais para o analista de domínio   Analisar stakeholders   Definir objetivos   Definir restrições   Analisar mercado, se possível   Coletar dados

  Tarefas ◦  Mapear aplicações candidatas ◦  Desenvolver funções de avaliação ◦  Caracterizar aplicações ◦  Analisar benefícios


  Modelar o domínio ◦  Seguindo guidelines para organizar features   Não usar features para representar dependências

funcionais, como por exemplo chamadas de funções. Features são usadas para capturar pontos em comum e pontos variáveis.

◦  As simple as possible


  Validar o domínio ◦  Documentar features

◦  Documentar o domínio

◦  Validar consistência do domínio


  E se houver a necessidade de definir o domínio em termos de requisitos textuais: ◦  Variabilidade em requisitos do domínio:


  E se houver a necessidade de definir o domínio em termos de casos de uso: ◦  Variabilidade diagramas de casos de uso:


  Variabilidade em diagramas de casos de uso. ◦  Diferenciação


SPL Sistemas únicos

  Existem algumas ferramentas que auxiliam no gerenciamento de variabilidades ◦  ToolDAy [Barachisio, 2006]

◦  pure:variants [Beuche et al., 2004]


  ToolDAy – Tool for Domain analysis ◦  Requisitos funcionais

  Mapa de produtos   Definição do escopo do domínio   Modelagem do domínio   Modelagem dos produtos   Checagem de consistência   Documentação de artefatos   Glossário   Geração de relatórios ◦  Requisitos não-funcionais

  Usabilidade   Rastreabilidade


  ToolDAy – Passos para usar a ferramenta ◦  Criar um domínio

  Documentar detalhes como aplicações exemplo e versão   Comentar análise dos stakeholders e objetivos   Documentar requisitos e casos de uso (se necessário) ◦  Criar um glossário (opcional) ◦  Criar um mapa de produtos

  Preencher planejamento   Definir funções de avaliação e mapa de produtos ◦  Definir diagrama de features do domínio ◦  Definir produtos e seus respectivos modelos de features


  Mapa de produtos


  ToolDAy – Detalhes ◦  Modelagem de domínio ◦  Baseada no GMF (Graphical Modeling Framework) para construção

da interface com o usuário ◦  Representação FODA (Feature-Oriented Domain Analysis), com

algumas adaptações.


  ToolDAy – Detalhes ◦  Modelagem de

produtos   Identifica as features

para cada produto

  Gera o modelo baseado nas features selecionadas

  Inclusão de novos relacionamentos no modelo de produtos


  ToolDAy – Detalhes ◦  Checagem de consistência   Erros   Avisos   Informações


  Glossário


  pure:variants ◦  Permite a especificação de uma LP a partir de suas

features. ◦  Provê suporte às fases de planejamento e modelagem ◦  O domínio pode ser visualizado de três formas: árvores,

diagramas e matrizes ◦  É possível criar famílias de sistemas e especificar

configurações de produtos específicos da família. ◦  Auxilia na análise de impacto ao adicionar ou remover

features ◦  Provê soluções para problemas de consistência no

domínio ◦  Disponível na forma de plug-in para o Eclipse (http://

eclipse.org).


  pure:variants


  Variabilidade é um conceito que não está presente somente quando consideramos a abordagem de ED/LPS

  Frameworks são excelentes exemplos

  Gerenciar variabilidades requer saber exatamente como identificá-las, representá-las, delimitá-las, implementá-las ◦  Monitorar a evolução dos artefatos variantes de um sistema computacional

  Várias são as propostas de gerenciamento de variabilidade existentes ◦  Problemas específicos

  Existe uma carência de um processo de gerenciamento de variabilidade ◦  Gerenciar as variabilidades de uma LP da forma mais genérica possível


  Software Product Line Engineering: Foundations, Principles, and Techniques [2005]

  by Klaus Pohl, Gunter Bockle, Frank van der Linden


  Realizar análise de domínio utilizando a PURE:VARIANTS de três jogos arcade de nave do Atari 2600 (shoot’em up).


  Pontos a serem analisados: ◦  Movimentação do personagem principal ◦  Movimentação dos inimigos (Inteligência Artificial?) ◦  Vidas (bônus e perda) ◦  Elementos do cenário (obstáculos) ◦  Inimigos especiais que podem ser atingidos ◦  Sons (música de fundo e efeitos sonoros) ◦  Armas (tipos de tiro) ◦  High Scores ◦  Condições de fim de jogo ◦  Elementos apresentados na tela principal do jogo

(HUD)


  Relatório Técnico / Artigo ◦  Passos seguidos para a análise de domínio na

ferramenta   Imagens e diagramas ◦  Lições aprendidas com o uso da ferramenta para a

análise de domínio   Pontos fortes   Pontos fracos   Sugestões e melhoria


  [Almeida, 2007] Almeida, E. S. "RiDE: The RiSE Process for Domain Engineering". (PhD thesis). Informatic Center, Federal University of Pernambuco (sandwich period at Universität Mannheim), Recife, 2007. 219 p.

  [Almeida et al., 2006] Almeida, E. S.Mascena, J. C. C. P.Cavalcanti, A. P. C.Alvaro, A.Garcia, V. C.Lucrédio, D.Meira, S. R. L. "The Domain Analysis Concept Revisited: A Practical Approach". The 9th International Conference on Software Reuse (ICSR). Torino, Italy: Lecture Notes in Computer Science, Springer-Verlag, 2006. p.

  [Barachisio, 2006] Barachisio, L. "A Systematic Review on Domain Analysis Tools". RiSE Seminars, Recife, PE, Brazil: RiSE Group, 2006. May, 2007, http://www.rise.com.br/seminars06.htm.

  [Becker, 2003] Becker, M. "Towards a General Model of Variability in Product Families". Proceedings of the 1st Workshop on Software Variability Management. Groningen, Netherlands. February, 2003. p.

  [Beuche et al., 2004] Beuche, D.Papajewski, H.Schröder-Preikschat, W. "Variability management with feature models". Science of Computer Programming, v.53, n.3, December, p.333--352. 2004.

  [Bosch et al., 2002] Bosch, J.Florijn, G.Greefhorst, D.Kuusela, J.Obbink, H.Pohl;, K. "Variability Issues in Software Product Lines". Proceedings of the 4th International Workshop on Product Family Engineering (PFE-4). Bilbao, Spain: Springer, Berlin Heidelberg New York. October 3–5, 2002. 13--21 p.

  (Bosch, 2002) J. Bosch, Maturity and Evolution in Software Product Lines: Approaches, Artefacts and Organization. In Software Product Line Conference (SPLC), San Diego, California, pp. 257-271, August, 2002.


  [Buschmann et al., 1996] Buschmann, F.Meunier, R.Rohnert, H.Sommerlad, P.Stal, M. Pattern-Oriented Software Architecture: A System of Patterns: Wiley & Sons. 1996

  [Clauss, 2001] Clauss, M. "Generic Modeling using UML extensions for variability". In Proceedings of OOPSLA Workshop on Domain-specific Visual Languages. Tampa, FL, USA, 2001. 11--18 p. (Clements & Northrop, 2001) P. Clements, L. Northrop, Software Product Lines: Practices and Patterns, Addison-Wesley, 2001, pp. 608.

  [Fritsch et al., 2002] Fritsch, C.Lehn, A.Strohm, T. "Evaluating Variability Implementation Mechanisms". In Proceedings of PLEES'02, 2002. p.

  [Gacek & Anastasopoules, 2001] Gacek, C. & Anastasopoules, M. "Implementing product line variabilities". Symposium on Software Reusability. Toronto, Ontario, Canada: ACM Press, 2001. 109 - 117 p.


  [Garg et al., 2003] Garg, A.Critchlow, M.Chen, P.Westhuizen, C. V. d.Hoek, A. v. d. "An Environment for Managing Evolving Product Line Architectures". Proceedings of the International Conference on Software Maintenance: IEEE Computer Society, 2003. 358 p.

  [Gomaa & Webber, 2004] Gomaa, H. & Webber, D. L. "Modeling Adaptive and Evolvable Software Product Lines Using the Variation Point Model". Proceedings of the 37th Annual Hawaii International Conference on System Sciences (HICSS'04) - Track 9: IEEE Computer Society, 2004. 90268.3 p.

  [Muthig et al., 2004] Muthig, D.; John, I.; Anastasopoulos, M.; Forster, T.; Doerr, J.; Schmid, K. GoPhone - A software product line in the mobile phone domain. Fraunhofer Institut Experimentelles IESE Software Engineering.

  [Griss et al., 1998] Griss, M. L.Favaro, J.d'Alessandro, M. "Integrating Feature Modeling with the RSEB". The Fifty International Conference on Software Reuse (ICSR). Victoria, Canada: IEEE/CS Press, 1998. 76--85 p.


  [Gurp et al., 2001] Gurp, J. V.Bosch, J.Svahnberg, M. "On the Notion of Variability in Software Product Lines". Working IEEE/IFIP Conference on Software Architecture (WICSA'01). Amsterdam, The Netherlands: IEEE Computer Society. August 28 - 31, 2001. 45 p.

  [Halmans & Pohl, 2003] Halmans, G. & Pohl, K. "Communicating the variability of a software-product family to customers". Software and Systems Modeling, v.2, n.1, March, p.15-36. 2003.

  [Hoek, 2000] Hoek, A. v. d. "Capturing Product Line Architectures". Fourth International Software Architecture Workshop. June, 2000. 95–99 p.

  [IBM, 2004] IBM. "Rational Rose XDE Developer Plus". IBM, 2004. 17 June 2004, http://www-306.ibm.com/software/awdtools/developer/plus/.

  [Jacobson et al., 1997] Jacobson, I.Griss, M.Jonsson, P. Software Reuse: Architecture, Process and Organization for Business Success: Addison-Wesley Professional. 1997. 497 p.


  [Kang et al., 1990] Kang, K. C.Cohen, S. G.Hess, J. A.Novak, W. E.Peterson, A. S. "Feature-Oriented Domain Analysis (FODA) Feasibility Study". Software Engineering Institute, Carnegie Mellon University. Pittsburgh. 1990

  [Morisio et al., 2000] Morisio, M.Travassos, G. H.Stark, M. E. "Extending UML to Support Domain Analysis". Proceedings of the 15th IEEE International Conference on Automated Software Engineering (ASE'00). Grenoble, France: IEEE Computer Society, 2000. 321 p.

  [Parsons et al., 1999] Parsons, D.Rashid, A.Speck, A.Telea, A. "A "Framework" for Object Oriented Frameworks Design". Technology of Object-Oriented Languages and Systems (TOOLS), p.141. 1999.

  [Pohl et al., 2005] Pohl, K.Böckle, G.Linden, F. J. v. d. Software Product Line Engineering - Foundations, Principles and Techniques: Springer. 2005. 468 p.

  [Pree, 1994] Pree, W. Design Patterns for Object-Oriented Software Development: Addison Wesley Longman. 1994. 268 p.


  [SEI, 2007] SEI. "A Framework for Software Product Line Practice, Version 4.2". Northrop, L. M.: SEI - Software Engineering Institute / Carnegie Mellon, 2007, http://www.sei.cmu.edu/productlines/framework.html.

  [Sochos et al., 2004] Sochos, P.Philippow, I.Riebisch, M. "Feature-Oriented Development of Software Product Lines: Mapping Feature Models to the Architecture". In: (Ed.). Object-Oriented and Internet-Based Technologies: Springer Berlin / Heidelberg, v.3263/2004, 2004. Feature-Oriented Development of Software Product Lines: Mapping Feature Models to the Architecture, p.138-152. (Lecture Notes in Computer Science)

  [SPLC, 2007a] SPLC. "11th International Software Product Line Conference (SPLC 2007), Sept. 10-14". Kyoto, Japan, 2007a. May 04, 2007, http://sec.ipa.go.jp/SPLC2007/.


  [SPLC, 2007b] SPLC. "Managing Variability for Software Product Lines". Clements, P. & Muthig, D., Kyoto, Japan, 2007b. May 04, 2007, http://sec.ipa.go.jp/SPLC2007/mvspl.php.

  [Succi et al., 2001] Succi, G.Yip, J.Pedrycz, W. "Holmes: an intelligent system to support software product line development". Proceedings of the 23rd International Conference on Software Engineering. Toronto, Ontario, Canada: IEEE Computer Society, 2001. 829--830 p.

  [Svahnberg & Bosch, 2000] Svahnberg, M. & Bosch, J. "Issues Concerning Variability in Software Product Lines". International Workshop on Software Architectures for Product Families (IW-SAPF-3). Lecture Notes In Computer Science; Vol. 1951: Springer-Verlag, 2000. 146--157 p.


  [Svahnberg et al., 2005] Svahnberg, M.Gurp, J. v.Bosch, J. "A taxonomy of variability realization techniques: Research Articles". Software—Practice & Experience, v.35, n.8, July, p.705--754. 2005.

  [Trigaux & Heymans, 2003] Trigaux, J. C. & Heymans, P. "Software Product Lines: State of the art". Institut d’Informatique FUNDP. Namur, Belgium: September. 2003

  [Weiss & Lai, 1999] Weiss, D. M. & Lai, C. T. R. Software Product-Line Engineering: A Family-Based Software Development Process: Addison-Wesley Professional; Har/Cdr edition. 1999. 384 p.


RiSE – Reuse in Software Engineering Labs ... · Hewlett-Packard Tempo de desenvolvimento...

Documents

Transcript of RiSE – Reuse in Software Engineering Labs ... · Hewlett-Packard Tempo de desenvolvimento...