RiSE Reuse in Software Engineering Labs

Transcrição

1 RiSE Reuse in Software Engineering Labs

2 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 2

3 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 3

4 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] 4

5 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 "Postit" com um logotipo de uma companhia ou marcadores para selecionar páginas em livros, etc. [Cooper et al. 2001] 5

6 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] 6

7 7

8 "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] Pré-requisitos Habilitar tecnologias Maturidade do processo Características do domínio e expertise 8

9 Nem tudo é uma linha de produto Considerar os níveis de maturidade é importante [Bosch, 2002] 9

10 10

11 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. 11

12 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. 12

13 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. 13

14 14

15 Linhas de Produtos da Nokia 15

16 16

17 Grande complexidade gerenciada 17

18 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 18

19 Exemplos de componentes Idioma Padrão Observer adotado 19

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

21 Exemplos de componentes Interface com usuário... for (int a = 0; a<=10; a++)... AddProfileMenu(MenuArray[a]); 21

22 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. 22

23 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 23

24 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 24

25 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 25

26 26

27 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 27

28 plug-in A extension point P contributes plug-in B extension interface I implements class C creates, calls 28

29 29

30 30

31 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. 31

32 32

33 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 33

34 34

35 [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 35

36 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 36

37 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 37

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

39 39

40 40

41 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 41

42 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 42

43 Validar o domínio Documentar features Documentar o domínio Validar consistência do domínio 43

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

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

46 Variabilidade em diagramas de casos de uso. Diferenciação Sistemas únicos SPL 46

47 Existem algumas ferramentas que auxiliam no gerenciamento de variabilidades ToolDAy [Barachisio, 2006] pure:variants [Beuche et al., 2004] 47

48 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 48

49 49

50 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 50

51 Mapa de produtos 51

52 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. 52

53 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 53

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

55 Glossário 55

56 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 ( eclipse.org). 56

57 pure:variants 57

58 58

59 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 59

60 Software Product Line Engineering: Foundations, Principles, and Techniques [2005] by Klaus Pohl, Gunter Bockle, Frank van der Linden 60

61 61

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

63 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) 63

64 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 64

65 [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, 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, p. [Barachisio, 2006] Barachisio, L. "A Systematic Review on Domain Analysis Tools". RiSE Seminars, Recife, PE, Brazil: RiSE Group, May, 2007, 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, 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 [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, 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 , August,

66 [Buschmann et al., 1996] Buschmann, F.Meunier, R.Rohnert, H.Sommerlad, P.Stal, M. Pattern-Oriented Software Architecture: A System of Patterns: Wiley & Sons [Clauss, 2001] Clauss, M. "Generic Modeling using UML extensions for variability". In Proceedings of OOPSLA Workshop on Domain-specific Visual Languages. Tampa, FL, USA, p. (Clements & Northrop, 2001) P. Clements, L. Northrop, Software Product Lines: Practices and Patterns, Addison-Wesley, 2001, pp [Fritsch et al., 2002] Fritsch, C.Lehn, A.Strohm, T. "Evaluating Variability Implementation Mechanisms". In Proceedings of PLEES'02, p. [Gacek & Anastasopoules, 2001] Gacek, C. & Anastasopoules, M. "Implementing product line variabilities". Symposium on Software Reusability. Toronto, Ontario, Canada: ACM Press, p. 66

67 [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, 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, 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, p. 67

68 [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, 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 [Hoek, 2000] Hoek, A. v. d. "Capturing Product Line Architectures". Fourth International Software Architecture Workshop. June, p. [IBM, 2004] IBM. "Rational Rose XDE Developer Plus". IBM, June 2004, developer/plus/. [Jacobson et al., 1997] Jacobson, I.Griss, M.Jonsson, P. Software Reuse: Architecture, Process and Organization for Business Success: Addison-Wesley Professional p. 68

69 [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 [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, 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 [Pohl et al., 2005] Pohl, K.Böckle, G.Linden, F. J. v. d. Software Product Line Engineering - Foundations, Principles and Techniques: Springer p. [Pree, 1994] Pree, W. Design Patterns for Object-Oriented Software Development: Addison Wesley Longman p. 69

70 [SEI, 2007] SEI. "A Framework for Software Product Line Practice, Version 4.2". Northrop, L. M.: SEI - Software Engineering Institute / Carnegie Mellon, 2007, [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, Feature- Oriented Development of Software Product Lines: Mapping Feature Models to the Architecture, p (Lecture Notes in Computer Science) [SPLC, 2007a] SPLC. "11th International Software Product Line Conference (SPLC 2007), Sept ". Kyoto, Japan, 2007a. May 04, 2007,

71 [SPLC, 2007b] SPLC. "Managing Variability for Software Product Lines". Clements, P. & Muthig, D., Kyoto, Japan, 2007b. May 04, 2007, [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, 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, p. 71

72 [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 [Trigaux & Heymans, 2003] Trigaux, J. C. & Heymans, P. "Software Product Lines: State of the art". Institut d Informatique FUNDP. Namur, Belgium: September [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 p. 72