Marcelo Henrique dos Santos

Transcrição

1 Marcelo Henrique dos Santos Mestrado em Educação (em andamento) MBA em Negócios em Mídias Digitais (em andamento) MBA em Marketing e Vendas Especialista em games Bacharel em Sistema de Informação marcelosantos@outlook.com REUSO DE SOFTWARE E COMPONENTES Marcelo Henrique dos Santos

2 AULA 03 Linha de Produto REUSO DE SOFTWARE E COMPONENTES Marcelo Henrique dos Santos

3 Introdução Um ponto crítico no projeto e na construção de todo o sistema de software é sua arquitetura: isto é, sua organização bruta como uma coleção de componentes de interação. Uma boa arquitetura pode permitir que um sistema satisfaça às exigências chaves em áreas como: o desempenho, a confiabilidade, a portabilidade, a escalabilidade, e a sua interoperabilidade. Uma arquitetura má pode ser desastrosa. 3

4 Introdução Apesar da existência de livros, artigos e ferramentas, a Arquitetura de Software todavia ainda está em uma fase pouco madura. REUSO DE SOFTWARE E COMPONENTES Marcelo Henrique dos Santos 4

5 A Crise de Software Dificuldades no Trabalho com Software Medidas pobres de eficiência e qualidade Insatisfação do usuário é frequente Pouco entendimento dos requisitos Problemas de Comunicação entre o usuário e o analista A qualidade do software é frequentemente suspeita Poucas medidas e critérios de qualidade 5

6 A Crise de Software Dificuldades no Trabalho com Software Software existente é muito difícil de manter E tem que ser mantido até ser substituído REUSO DE SOFTWARE E COMPONENTES Marcelo Henrique dos Santos 6

7 Causas A Crise de Software Introdução de erros no processo Má especificação Mau projeto Má implementação Testes incompletos ou mal feitos Problemas na comunicação homem-máquina REUSO DE SOFTWARE E COMPONENTES Marcelo Henrique dos Santos 7

8 A Crise de Software Causas Problemas na gerência Falta de treinamento em novas técnicas de desenvolvimento O processo está evoluindo muito rapidamente em função do aprendizado. É necessário reciclar REUSO DE SOFTWARE E COMPONENTES Marcelo Henrique dos Santos 8

9 Problemas Complexidade Especificar sistemas é uma atividade bastante complexa. Não se trata apenas de fazer uns programinhas. Insatisfação dos usuários usuários sentem-se frustrados com sistemas difíceis de serem operados e/ou cujo desenvolvimento se prolonga por vários anos. usuário precisa de sistemas funcionando de acordo com suas necessidades O valor de um sistema está em atender com precisão as necessidades de seus usuários. 9

10 Problemas Produtividade Costuma estar quase sempre aquém do desejado. Freqüentemente, a alocação de recursos e atividades são desbalanceadas. Algumas questões recebem consideração demasiada, enquanto outras são insuficientemente consideradas. Custos, tempo e recursos geralmente são subestimados 10

11 Problemas Confiabilidade do Sistema Há diversas estatísticas que provam a pouca confiabilidade de boa parte dos sistemas. depende do uso de métodos que possam garantir uma boa qualidade do produto construído Não basta que o sistema produza resultados solicitados pelo usuário.mas que também tenha o desempenho adequado. 11

12 Problemas Manutenibilidade Facilidade de se modificar um sistema para adaptar-se a circunstâncias novas, inexistentes à época da implantação. Sistemas recentemente implantados são substituídos por novos, devido ao alto custo para sua manutenção REUSO DE SOFTWARE E COMPONENTES Marcelo Henrique dos Santos 12

13 Custo de Mudanças Custo 1x 1,5 a 5X 60 a 100 X Definição Projeto Manutenção Fase Crítica 13

14 Problemas Porque leva tanto tempo para terminar programas e sistemas? Porque os custos são tão altos? Porque temos dificuldade de medir o progresso do desenvolvimento do software? Porque não conseguimos detectar todos os erros antes de entregar o software aos nossos clientes? 14

15 Problemas Porque os usuários estão sempre insatisfeitos com o software entregue? REUSO DE SOFTWARE E COMPONENTES Marcelo Henrique dos Santos 15

16 Mitos... da Gerência... Desatualizados, obsoletos Ferramentas modernas de software e hardware são suficientes O uso eficiente de ferramental exige conhecimento Manuais de Regras e Procedimentos Estamos atrasados Vamos alocar mais gente ao projeto! Custos de treinamento, gerência e entendimento do processo de trabalho 16

17 Mitos... do Desenvolvedor/Programador... Até que o programa esteja rodando não há como medir sua qualidade O único produto de um projeto de software é o conjunto de programas Especificação, projeto, plano de trabalho Programa escrito e testado! Acabei! Revisões anteriores à codificação Quanto mais cedo voce escrever o código, mais tempo irá demorar para completá-lo De 50 a 70 % do custo de produção de um software vai ser gasto para operacionalizá-lo para o usuário 17

18 Mitos... do Cliente... Uma lista de intenções (boas) é suficiente para começar a produzir o software Minhas necessidades vão mudar Mas mudanças são fáceis de introduzir porque software é bastante flexível A Especificação do Software é a fase mais crítica do processo Custo de mudanças é muito alto Erros na fase inicial têm um custo muito alto de correção 18

19 Ciclo de Vida de Software Definição dos requisitos Análise Projeto Documentos são gerados a cada fase e servem de entrada para a fase seguinte Implementação Teste/Avaliação Implantação Manutenção 19

20 Papéis Apesar de existirem numerosas definições sobre arquitetura do software, no núcleo de tudo está a noção de que a arquitetura de um sistema descreve sua estrutura bruta. Esta estrutura ilumina as decisões de projeto de alto nível, incluindo coisas como: o sistema é composto das peças de interação, onde estão os principais caminhos de interação Adicionalmente, uma descrição arquitetural inclui informação suficiente para permitir a análise de alto nível e crítica do sistema. REUSO DE SOFTWARE E COMPONENTES Marcelo Henrique dos Santos 20

21 Papéis Fornecendo uma descrição abstrata do sistema, a arquitetura expõe determinadas propriedades, ao mesmo tempo que esconde outras. Idealmente, esta representação fornece um guia de entendimento intelectual do sistema como um todo, permitindo aos projetistas raciocinar sobre a possibilidade do sistema satisfazer a determinadas exigências. REUSO DE SOFTWARE E COMPONENTES Marcelo Henrique dos Santos 21

22 Papéis Por exemplo: uma arquitetura para um aplicação de processamento de sinal, pode ser construída como uma rede do fluxo de dados em que os nós lêem vetores de entrada dos dados, transformam esses dados, e os escrevem aos vetores da saída. E aqui, os projetistas devem pensar em estruturas para este tipo de processamento. REUSO DE SOFTWARE E COMPONENTES Marcelo Henrique dos Santos 22

23 Papéis Na elaboração da Arquitetura de um software, 6 papéis são desempenhados: Compreensão, Reuso, Construção, Evolução, Análise e Gerência. REUSO DE SOFTWARE E COMPONENTES Marcelo Henrique dos Santos 23

24 Papéis: Compreensão A arquitetura do software simplifica nossa habilidade de entender grandes sistemas apresentando-os em um alto nível do abstração de forma a ser facilmente compreendido. Além disso, expõe as principais restrições do projeto do sistema, tanto quanto o aspecto racional para fazer escolhas arquiteturais específicas. 24

25 Papéis: Reuso Descrições de arquiteturas suportam reuso em múltiplos níveis. Trabalhos correntes focam geralmente em bibliotecas de componentes. Projetos de Arquiteturas, promovem reuso em grandes componentes e em Frameworks, onde seus componentes possam ser integrados. 25

26 Papéis: Construção A Construção de uma arquiterua oferece um norte para os desenvolvedores, indicando ou apresentando os maiors componentes e suas dependências. Por exemplo: as camadas de uma arquitetura tipicamente documentam as fronteiras da implementação, expondo os maiores componentes e suas interfaces, bem como as suas principais restrições. 26

27 Papéis: Evolução A arquitetura do software pode expor as dimensões na linha do tempo da possível evolução de um sistema. Deixa explícito "as paredes internas" de um sistema, os desenvolvedores do sistema podem melhor compreender as ramificações das mudanças, e estimar desse modo mais preciso o custo das modificações. REUSO DE SOFTWARE E COMPONENTES Marcelo Henrique dos Santos 27

28 Papéis: Evolução Além disso, as descrições arquiteturais separam interesses sobre as funcionalidade de um componente da forma com que esse componente é conectado (interage) a outros componentes. Esta separação permite mais facilmente aos mecanismos da conexão obter um maior reuso e interoperabilidade. REUSO DE SOFTWARE E COMPONENTES Marcelo Henrique dos Santos 28

29 Papéis: Análise As descrições arquiteturais fornecem novas facilidades para a tarefa de análise tais como: a consistência do sistema, o conformidade dos atributos da qualidade, a análise da dependência e A análises específicas de domínio para identificar arquiteturas semelhantes. REUSO DE SOFTWARE E COMPONENTES Marcelo Henrique dos Santos 29

30 Papéis: Gerência A avaliação crítica de uma arquitetura conduz tipicamente a uma grande compreensão das exigências, das estratégias da execução, e de riscos potenciais a serem enfrentados na implementação de um sistema de software. REUSO DE SOFTWARE E COMPONENTES Marcelo Henrique dos Santos 30

31 Linhas de Produtos e Padrões O que são linhas de produtos? São produtos que apresentam similaridades nas suas especificações. Entretanto, em uma abordagem de linha de produto, deve-se também considerar requisitos para a uma família de sistemas, e o relacionamento entre eles. REUSO DE SOFTWARE E COMPONENTES Marcelo Henrique dos Santos 31

32 Codificação e Disseminação Um problema inicial para o avanço de projetos arquiteturais como uma disciplina da engenharia de software era a falta do compartilhamento de conhecimento sobre arquiteturas e técnicas para desenvolver estas arquiteturas. Uma boa saída foi uso e padrões (pipes and filters, blackboard, MVC e outros). REUSO DE SOFTWARE E COMPONENTES Marcelo Henrique dos Santos 32

33 Linha de Produto de Software Por meio desta abordagem, é possível explorar as semelhanças dos seus produtos para aumentar o reúso de artefatos. A abordagem de LPS tem sido adotada na indústria de software. Vantagens: Maior reutilização de artefatos; Maximização de lucros; Diminuição do time to market; Diminuição de riscos; Produtos com maior qualidade; Contribuição para o aprimoramento; ROI; etc. 33

34 Linha de Produto de Software Atividades Essenciais de LPS Arquitetura da LPS Arquitetura de cada produto da LPS 34

35 Linha de Produto de Software A base de uma LPS é seu núcleo de artefatos. arquitetura da LPS, os componentes reusáveis, modelos de domínio, requisitos da LPS, modelos de características e planos de teste. Uma característica (feature) é uma capacidade do sistema que é relevante e visível para o usuário final. O modelo de características inclui todas as características de uma LPS e os seus interrelacionamentos. 35

36 Linha de Produto de Software A definição explícita de variabilidades em LPS é a diferença chave entre o desenvolvimento de sistemas únicos e o desenvolvimento de LPS. REUSO DE SOFTWARE E COMPONENTES Marcelo Henrique dos Santos 36

37 Linha de Produto de Software Exemplo de Modelo de Características Legenda: Característica Obrigatória Característica Opcional Mutualmente Inclusivas Mutualmente Exclusivas 37

38 Linha de Produto de Software Variabilidade é a forma como os membros de uma família de produtos podem se diferenciar entre si. O gerenciamento de variabilidades é uma das atividades mais importantes no gerenciamento de uma LPS. A variabilidade é descrita por pontos de variação e variantes. 38

39 Linha de Produto de Software Ponto de variação: Um local específico de um artefato em que uma decisão de projeto ainda não foi tomada; Variante: Corresponde a uma alternativa de projeto para resolver uma determinada variabilidade. Restrições entre variantes: define os relacionamentos entre duas ou mais variantes para que seja possível resolver um ponto de variação ou uma variabilidade. 39

40 Gerenciamento de Variabilidade Similaridades Artefato de uma Linha de Produto Variabilidade Pontos de Variação REUSO DE SOFTWARE E COMPONENTES Marcelo Henrique dos Santos 40

41 Gerenciamento de Variabilidade Artefato de uma Linha de Produto Variabilidade Variantes Pontos de Variação 41

42 Gerenciamento de Variabilidade Artefato de uma Linha de Produto Variabilidade Pontos de Variação 42

43 Restrições entre variantes Gerenciamento de Variabilidade Artefato de uma Linha de Produto Variabilidade Restrições entre variantes Pontos de Variação 43

44 Restrições entre variantes Gerenciamento de Variabilidade Opcionais podem ser selecionadas ou não. Ou uma ou mais podem ser selecionadas. Restrições entre variantes Mutualmente exclusivas (alternativa - XOR) apenas uma delas deve ser selecionada. 44

45 Gerenciamento de Variabilidade Possíveis produtos da LPS 45

46 Gerenciamento de Variabilidade Possíveis produtos da LPS Ou uma ou mais podem ser selecionadas. (alternativa - XOR) apenas uma delas deve ser selecionada. Opcionais podem ser selecionadas ou não. 46

47 Mapeamento de Características na arquitetura da LPS Uma das formas de se implementar características de LPS é tratando cada uma delas como um interesse presente na família. Interesses correspondem a requisitos, funcionais ou não, que devem estar presentes no sistema. Alguns são naturalmente transversais e, por isso, se espalham em vários pontos dentro do software. Quanto mais modularizado um interesse estiver dentro do projeto do software mais reusável será o seu projeto. Os interesses podem ser mapeados em artefatos da LPS usando estereótipos UML. 47

48 Mapeamento de Características na arquitetura da LPS Exemplo de Interface com Interesses associados usando estereótipos UML REUSO DE SOFTWARE E COMPONENTES Marcelo Henrique dos Santos 48

49 Metodologia Usada em PSS Use Case Descriptions Nome do Caso de Uso Categoria do Reuso obrigatório, opcional, alternativo Descrição Atores Dependências Estende Caso de Uso X Pré-condições Fluxo Principal Fluxos Alternativos Fluxos de Exceção Pontos de Variação Estruturas de Dados Regras de Negócio 49

50 Application Engineering Metodologia Usada em PSS Documento de como derivar produto Instruções para Derivação Indicar que artefatos (use cases, diagramas, classes) pertencem ao kernel e a cada feature Arquivo de Configuração Arquivo de Propriedades Arquivo XML do Spring Instanciação Automática GenArch Apresentar produto derivado 50

51 Referências Atkinson, C., Bayer, J., Muthig, D.: Component-based product line development: The kobra approach. In Donohoe, P., ed.: Proceedings of thefirstsoftware Product Line Conference. (2000) Cirilo, E., Kulesza, U., Lucena, C.: GenArch: A Model-Based Product Derivation Tool. In: Proceedings of the 1º Simpósio Brasileiro de Componentes, Arquiteturas e Reutilização de Software (SBCARS 2007), Campinas, Brazil (2007) Clements, P., Northrop, L.: Software Product Lines: Practices and Patterns. Addison- Wesley, Boston, MA, USA (2002). Software Product Lines. Czarnecki, K., Eisenecker, U.: Generative Programming: Methods, Tools, and Applications. Addison Wesley Longman (2000). Gomaa H. Designing Software Product Lines with UML: From Use Cases to Pattern- Based Software Architectures. Addison Wesley Longman Publishing Co., Inc., Redwood City, CA, USA,

52 Referências Kang K. C., Kim S., Lee J., Kim K., Shin E., and Huh M.. Form: A feature-oriented reuse method with domain-specific reference architectures. Ann. Softw. Eng., 5: , Matinlassi M. Comparison of software product line architecture design methods: Copa, fast, form, kobra and qada. In ICSE 04: Proceedings of the 26th International Conference on Software Engineering, pages , Washington, DC, USA, IEEE Computer Society. Nunes I., Nunes C., Kulesza U., and Lucena C. Developing and Evolving a Multi-Agent System Product Line: An Exploratory Study. In: 9th International Workshop on Agent-Oriented Software Engineering, 2008, Estoril. 9th International Workshop on Agent-Oriented Software Engineering, p Pohl, K., Bckle, G., van der Linden, F.J.: Software Product Line Engineering: Foundations, Principles and Techniques. Springer-Verlag, New York,USA (2005). Weiss D. M., Lai C. T. R.: Software Product-line Engineering: A Family-Based Software Development Process, Addison-Wesley,

53 ATIVIDADE 04 Leia o artigo Linhas de Produto de Software: riscos e vantagens de sua implantação e explique o conceito do modelo de linhas de produto de software, suas vantagens e desvantagens, assim como os riscos de sua implantação. (2 ou 3 alunos) 53

54 ATIVIDADE 05 Pense em um exemplo de projeto de software que possa ser uma linha de produtos. Quais seriam os produtos gerados por essa linha? (2 ou 3 alunos) 54