Reúso

ENGENHARIA DE SOFTWARE
AVANÇADA - REÚSO

Diógenes Ricardo 1
Reuso - Engenharia de Software - Mestrado em
Eng. da Computação - POLI/UPE

2 21/11/2012

Roteiro
 Apresentar o reúso de software
 Descrever abordagens para
desenvolvimento em larga escala
 Linha de produtos de software(SPL).
 Vantagens e Desvantagens
 Frameworks
 Como desenvolver sistemas com COTS

Reuso - Engenharia de Software - Mestrado
em Eng. da Computação - POLI/UPE

3 21/11/2012

Introdução
 Não é tão novo...(McLROY,1968).
 Em 2000 se torna “norma” para novos
sistemas
 Por quê?
 Menor custo de produção
 Manutenção
 Velocidade
 Qualidade
 ROI

4 21/11/2012

Introdução

 Aumento do reuso como movimento Open source
 Custa?
 Como fazer?
 Adaptabilidade de sistemas já existentes
 Web Services.
 CEP, CPF, etc.


5 21/11/2012

Classificação
 Reúso de sistemas de aplicação
 Totalmente sem alteração.
 Configuração para diferentes clientes.
 COTS(Commercial Off-The-Shelf)
 Reúso de componentes
 De subsistemas até objetos
 Exemplos?
 Capítulo 17(Engenharia de software baseada
em componentes) e Capítulo 19 (Serviços
como componentes reusáveis)

6 21/11/2012

Classificação
 Reuso de objetos e funções
 Já fazemos isso ;)
 Bibliotecas com funções específicas, são
muito utilizadas em código recém-
desenvolvido
 Reuso de conceito
 Ideias, formas, padrões de projeto.


7 21/11/2012

Considerações(+)
 Confiança aumentada
 Risco de projeto reduzido
 Uso eficaz de especialistas
 Conformidade com padrões
 Desenvolvimento acelerado


8 21/11/2012

Considerações(-)
 Maiores custos de manutenção
 Falta de ferramentas de suporte
 Síndrome do “Não inventado aqui”
 Criação, manutenção e uso de uma
biblioteca de componentes
 Encontrar, compreender e adaptar os
componentes reusáveis


9 21/11/2012

Introdução
O processo de software precisa estar
adaptado ao reuso
 Requisitos
 Projeto
 Implementação
 Matsumoto(1984) e Cusamano(1989)
 HP(1995)
 Exemplos das impressoras.

10 21/11/2012

O panorama de reuso
 De funções até aplicações
 Planejando
 Depende do sistema
 Da tecnologia
 Disponibilidade dos artefatos
 Maturidade da equipe


11 21/11/2012

O panorama de reuso
na prática
 A sua empresa possui total controle sobre componentes e
bibliotecas de software utilizados nos sistemas
desenvolvidos?
 É possível identificar a dependência entre os
componentes?
 Você consegue garantir que não existem componentes
inseridos nos sistemas que não estão sendo utilizados?
 Você controla se um componente com licença open
source (GPL) foi inserido no software da sua empresa,
obrigando legalmente que o código do seu software
também seja distribuído com licença open source(GPL)?
 Sua empresa consegue gerenciar separadamente os
componentes open source baixados da internet, dos
componentes proprietários desenvolvidos na própria
empresa?

12 21/11/2012

Reusamos?


13 21/11/2012

Planejamento
 Cronograma
 Pouco tempo -> COTS
 Duração do software
 Software de longa vida -> Manutenção
 Conhecimento, habilidades e experiência da
equipe
 Importância do software e requisitos não
funcionais
 Certificações de segurança.
 Sistemas Críticos

14 21/11/2012

Planejamento
 Domínio da aplicação
 Já existe software?
 A plataforma em que o sistema será
executado
 Componentes .Net, as library para Linux.

 Conclusão
 Normalmente os gerentes não compreendem
os riscos associados ao reuso em relação ao
com desenvolvimento original, preferindo estes
últimos por serem conhecidos.

15 21/11/2012

Framework
 Objetos são normalmente muito
específicos
 Entender ou Reimplementar?
 Schimidt et al. (2004).
 "...um conjunto integrado de artefatos de
software(como classes, objetos e
componentes) que colaboram para
fornecer uma arquitetura reusável para
uma família de aplicações relacionadas".

16 21/11/2012

Tipos de frameworks
 Frameworks de Infraestrutura
 Compiladores, interface com usuário,
comunicação
 Frameworks de Middleware
 Componentes padronizados
 .Netda Microsoft.
 Enterprise Java Beans(EBJ).

 Frameworks de Aplicações corporativas
 Telecomunicações e Sistemas financeiros

17 21/11/2012

Tipos de frameworks
 Frameworks de Aplicações WEB (WAFs).
 Normalmente baseado no padrão
Composite do MVC


18 21/11/2012

MVC (Model View Controller)
 Década de 80
 MVC ~= Observer + Strategy + Composite
+ ...
 Um framework é um padrão na prática!


19 21/11/2012

WAF
 Engloba vários frameworks.
 Proteção
 Páginas WEB dinâmicas
 Suporte a Banco de Dados
 Gerenciamento de sessões
 Interação de usuário – AJAX
 Testes Unitários (Junit)


20 21/11/2012


21 21/11/2012

Funcionamento
 Normalmente não se altera o código
 Adicionamos classes concretas.
 Callbacks
 Métodos chamados em respostas a eventos do
framework
 Controladores, ao invés de objetos específicos
da aplicação
 As aplicações pode ser construídas para o
reuso futuro(Linha de Produtos de Software)

22 21/11/2012

Abordagens
 Frameworks X SPL (Software Product Line).
 No framework criamos diferentes tipos de
aplicações “únicas”.
 Em uma SPL criamos diferentes tipos de
aplicações semelhantes.
 Curva de aprendizagem
 Pode ser caro para introduzir um framework
em um processo de desenvolvimento
 Qual o melhor?
 Difícil debugar.

23 21/11/2012

Frameworks e SPL
 Dependem de  Não são
recursos de OO necessariamente
 Normalmente não é dependentes de OO
modificado  Os componentes são
 Apoio técnico alterados, deletados
 Software ou reescritos
 Apoio ao domínio
 Software e Hardware


24 21/11/2012

Linha de Produtos de Software


25 21/11/2012

o Já utilizamos?
o Quando construímos um sistema e depois
aparece um outro projeto parecido...
o Normalmente o que acontece...
o Novas instancias baseadas em produtos
existentes tende a corromper a
estrutura(especializa).
o O que SPL faz...
o Identifica funcionalidade comum e aplica em
uma plataforma estruturada para simplificar e o
reuso e a configuração

26 21/11/2012

Conceitos base
 Core assets
 Feature
 Variabilidade
 Variantes
 Pontos de variação
 Variação
 Mecanismo de Variabilidade
 Dependência de Variantes
 Restrições de dependência
 Requerida
 Exclusiva

27 21/11/2012

Conceitos base
 Tipo de variantes  Classificação das
 Comum variantes
 Variável  Mandatória
 Específica do  Opcional
produto  Alternativa inclusiva
 Níveis de variabilidade  Alternativa exclusiva
 Da SPL  Alternativa
 Do produto mutualmente
inclusiva
 Dos componentes
 Dos subcomponentes
 De código


28 21/11/2012

 O que é?
 É um conjunto de aplicações com uma arquitetura comum e
componentes compartilhados, sendo cada aplicação
especializada para refletir necessidades diferentes.
Uma linha de produtos de software é um conjunto de
sistemas com uso intensivo de reúso software que
compartilham um conjunto de features comuns e
gerenciáveis, que satisfazem às necessidades específicas
de um segmento de mercado particular ou missão, e
que são desenvolvidos a partir de um conjunto de core
assets comuns, de modo planejado.
(CLEMENTS E NORTHROP, 2001, p. 05).

 O núcleo é projetado para ser configurado e adaptado para
atender necessidades de clientes diferentes
 Configurar, Implementar, modificar.
 Customização em massa.

29 21/11/2012

Customização em massa


30 21/11/2012

Funcionamento da SPL

Quanto mais abstrato mais rápido e mais
barato para o cliente.

31 21/11/2012

Quando usar?

Figura 1: Custo para desenvolver N tipos de sistemas comparando o
SSD com SPLE. Adaptada de Pohl (2005, p.10)


32 21/11/2012


Figura 2: Principais atividades para SPLE adaptada de (NORTHROP e
CLEMENTS, 2007)


33 21/11/2012


Figura 3: Os subprocessos da Engenharia de Domínio e Engenharia de
Aplicação. Figura adaptada de (POHL et. al., 2005)

34 21/11/2012


Figura 4: Principais abordagens de gerenciamento de variabilidade.
(CHEN et. al., 2009)


35 21/11/2012


36 21/11/2012

Sistemas de solução COTS
 Sistemas para um domínio simples até um
ERP
 Suposições de forma de trabalho do
domínio
 Dificuldades com situações específicas
 Sistemas ERP o processo de configuração
exige conhecimento detalhado do
negócio
 Consultores e clientes.

37 21/11/2012

O número de
módulos oferecem
suporte para
funções diferentes
 Há um conjunto de
processos
associados a cada
módulo


38 21/11/2012

 Uma forma amplamente usada em reuso
de software
 Limitação óbvia.
 Restrição a configuração
A configuração envolve:
 Seleção de funcionalidades
 Estabelecimento de um modelo de dados
 Definição das regras de negócio serão
aplicadas nesses dados

39 21/11/2012

 A configuração envolve ainda:
 Criação de formulários de entrada e relatórios
de saída
 Novos processos de negócio estarão em
conformidade como modelo de processos
suportado pelo sistema?
 Configuração de parâmetros que definam
como o sistema é implantado internamente
 Após a configuração o sistema está pronto
para o teste.
 Problemas?

40 21/11/2012

Sistemas Integrados COTS
 Quando usar?
 Unir dois COTS ou integrar um COTS ao meu
sistema.
 De que forma?
 Por meio de API (application programming
interfaces)
 Interfaces de Serviços
 Conexão entre saída de um e entrada de outro
 Atualização dos banco de dados


41 21/11/2012

 Decisões:
 Qual produto oferece a funcionalidade
mais adequada?
 Como os dados serão trocados?
 Adaptadores

 Quais características serão realmente
usadas?


42 21/11/2012

 Boehm e Abts(1999)
 Falta de controle de funcionalidade e
desempenho
 De que lado está a culpa?
 Problemas com a interoperabilidade com
vários sistemas COTS
A falta de normalização das interfaces torna
difícil a integração com o aumento do
número de sistemas.

43 21/11/2012

 Boehm e Abts(1999)
 Não há controle sobre a evolução do sistema
 Novas versões podem ser incompatíveis, ou com
funcionalidades indesejadas e versões anteriores
pode ficar indisponíveis e sem suporte

Isto
acontece?


44 21/11/2012



45 21/11/2012

Referências
 CHEN, Lianping; MUHAMMAD, Ali Babar, CAWLEY Ciaran; A Status Report on
the Evaluation of Variability Management Approaches Lero, the Irish Software
Engineering Research Centre, University of Limerick, Ireland, 2009b
 CLEMENTS P. e NORTHROP L., Software Product Lines: Practices and Patterns,
Addison-Wesley, pp. 608, 2001.
 NORTHROP, L. M. e CLEMENTS, P.C. A Framework for Software Product Line
Practice. Version 5.0. Pittsburg. Software Engineering Institute, 2007. Disponível
em: < http://www.sei.cmu.edu/productlines/framework.html >. Acesso em: 28
fev. 2010 às 10:24.
 POHL, K.; BÖCKLE, G.; VAN DER LINDEN, F.: Software Product Line Engineering –
Foundations, Principles, and Techniques. Springer, Heidelberg 2005.
 OLIVEIRA, D. R. F.; Um estudo sobre gerenciamento de variabilidade de
requisitos em linha de produtos de software trabalho de conclusão de curso,
UPE, 2011.
 SOMMERVILLE, Ian; Software Engineering, Ninth Edition, Pearson Education
Limited, 2011


46 21/11/2012


Reúso

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (12)

Similar to Reúso

Similar to Reúso (20)

More from Diogenes Freitas

More from Diogenes Freitas (12)

Reúso