Marcelo Henrique dos Santos

(1)

REUSO DE SOFTWARE E COMPONENTES

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 Email: marcelosantos@outlook.com

(2)

AULA 03

Linha de Produto

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

(4)

Introdução

• Apesar da existência de livros, artigos e

ferramentas, a Arquitetura de Software

todavia ainda está em uma fase pouco

madura.

(5)

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

(6)

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

(7)

7

A Crise de Software

• Causas

– 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

(8)

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

(9)

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

(10)

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

(11)

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.

“Não é suficiente que o sistema seja eficiente. É necessário ainda que ele seja eficaz”

(12)

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

(13)

13

Custo de Mudanças

Custo 1x 1,5 a 5X 60 a 100 X

Definição Projeto Manutenção

Fase Crítica

(14)

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?

(15)

15

Problemas

• Porque

os

usuários

estão

sempre

insatisfeitos

com o software entregue?

(16)

16

Mitos...

• da Gerência...

Manuais de Regras e Procedimentos Ferramentas modernas de software e hardware são suficientes Estamos atrasados… Vamos alocar

mais gente ao projeto!

Desatualizados, obsoletos

O uso eficiente de ferramental exige conhecimento

Custos de treinamento, gerência e

entendimento do processo de trabalho

(17)

17

Mitos...

• do Desenvolvedor/Programador...

Programa escrito e testado! Acabei! 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

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

Revisões anteriores à codificação

Especificação, projeto, plano de trabalho

(18)

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

Custo de mudanças é muito alto

A Especificação do Software é a fase mais crítica do processo

Erros na fase inicial têm um custo muito alto de

(19)

19

Ciclo de Vida de

Software

Definição dos requisitos

Análise Projeto Implementação Teste/Avaliação Implantação Manutenção

Documentos são gerados a cada fase e servem de

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

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

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

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

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

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

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

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

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

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

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

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

(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).

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

(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 inter-relacionamentos.

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

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

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

(40)

Gerenciamento de

Variabilidade

Similaridades

Pontos de Variação

Artefato de uma Linha de Produto Variabilidade

(41)

Gerenciamento de

Variabilidade

Variantes Artefato de uma Linha de Produto

Variabilidade

(42)

Gerenciamento de

Variabilidade

Artefato de uma Linha de Produto Variabilidade

(43)

Gerenciamento de

Variabilidade

Artefato de uma Linha de Produto Variabilidade Restrições entre variantes Restrições entre variantes 43

(44)

Gerenciamento de

Variabilidade

Restrições entre variantes

Mutualmente exclusivas

(alternativa - XOR) – apenas uma delas

deve ser selecionada.

Opcionais – podem ser selecionadas ou não. Ou – uma ou mais

podem ser selecionadas.

(45)

Gerenciamento de

Variabilidade

Possíveis produtos da LPS

(46)

Gerenciamento de

Variabilidade

Possíveis produtos da LPS Ou – uma ou mais podem ser selecionadas. Opcionais – podem ser selecionadas ou não. (alternativa - XOR) – apenas uma delas

deve ser selecionada.

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

(48)

Mapeamento de Características

na arquitetura da LPS

Exemplo de Interface com Interesses associados usando estereótipos UML

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

Metodologia Usada em PSS

• Application Engineering

– 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

(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) 289-309.

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) 17-24.

Clements, P., Northrop, L.: Software Product Lines: Practices and Patterns. Addison-Wesley, Boston, MA, USA (2002).

Software Product Lines. http://www.sei.cmu.edu/productlines/

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, 2004.

(52)

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:143– 168, 1998.

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 127–136, Washington, DC, USA, 2004. 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, 2008. p. 177-188.

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