Slides-8-ReusoDeSoftware (1)

Prévia do material em texto

Reuso de Software
1
Agenda da Aula
Introdução a Reuso de Software
Abordagens de Reuso
Padrões de Projeto
Frameworks
Reuso de Modelos
Reuso de Componentes
Linhas de Produtos de Software
Reuso de Software
Menor custo de produção e manutenção
Entrega mais rápida
Maior qualidade
Promovido para aumentar o retorno sobre o investimento em software
O movimento Open Source proporciona uma enorme base de código reusável a baixo custo
Reuso de Software
Abordagem de desenvolvimento com o objetivo de maximizar o uso de software pré-existente
Nos últimos 20 anos, muitas técnicas foram desenvolvidas para apoiar o reuso
Bibliotecas (API)
Classes de objetos
Componentes, etc.
Tipos de Reuso
Reuso de Sistema
Família de aplicações com uma arquitetura comum
O sistema pode ser usado por incorporação a outro sistema
Pode ser necessário customização
Reuso de Componentes
Reuso de média granularidade, como de um componente arquitetural ou subsistema
Reuso de Objetos e Funções
Tipo mais comum; ocorre nos últimos 40 anos
Vantagens de Reuso
Redução de tempo e custos
O sistema pode ser entregue em menor prazo, que também reduz os custos
Maior confiabilidade do produto
O software reusado já foi testado antes
Menor risco no processo
O custo de software existente é conhecido
Adequação aos padrões
Alguns padrões (exemplo, interface GUI) podem ser implementados como componentes reusáveis
Benefícios
Confiança aumentada
O software reusado, experimentado e testado em sistemas em funcionamento provavelmente são mais confiáveis do que um novo software. Seus defeitos de projeto e implementação devem ter sido encontrados e corrigidos.
Risco de processo reduzido
O custo do software existente já é conhecido. Esse é um fator importante para o gerenciamento de projeto, pois reduz a margem de erro de estimativa de custos. Particularmente verdadeiro quando componentes de software relativamente grandes, como subsistemas, são reusados.
Benefícios
Uso eficaz de especialistas
Em vez de repetir o mesmo trabalho, especialistas em aplicações podem desenvolver software reusável que encapsule seu conhecimento.
Conformidade com padrões
Alguns padrões, como interface do usuário, podem ser implementados como um conjunto de componentes reusáveis. Por exemplo, se os menus em uma interface forem implementados usando componentes reusáveis, todas as aplicações apresentarão o mesmo formato de menu. O uso de interface de usuário padrão melhora a confiança, pois os usuários cometem menos erros quando são apresentados a interface familiar.
Benefícios
Desenvolvimento acelerado
Muitas vezes os custos gerais de desenvolvimento não são tão importantes quanto entregar o sistema ao mercado o mais rápido possível. O reuso de um software pode acelerar a produção do sistema, pois pode reduzir o tempo de desenvolvimento e validação.
Problemas
Maior custo de manutenção
Se o código fonte de um sistema ou componente de software reusável não estiver disponível, o custo de manutenção pode ser maior, pois o elemento reusado pode tornar-se cada vez mais incompatível com as alterações do sistema.
Falta de ferramenta de suporte
Algumas ferramentas de software não suportam o desenvolvimento com reuso. Pode ser difícil ou impossível integrar essas ferramentas com um sistema de biblioteca de componentes.
O processo de software assumido por essas ferramentas pode não considerar o reuso.
Particularmente verdadeiro para as ferramentas que oferecem suporte a engenharia de sistemas embutidos.
Problemas
Síndrome de 'não-inventado-aqui’
Alguns engenheiros de software preferem reescrever componentes, pois acreditam em poder melhorá-los.
Aumentar a confiança.
Escrever software original é mais desafiador do que reusar software de outras pessoas.
Criação, manutenção e uso de uma biblioteca de componentes
Preencher uma biblioteca de componentes reusáveis e garantir que desenvolvedores de software possam utilizá-la pode ser caro. 
Processos de desenvolvimento precisam ser adaptados para garantir seu uso.
Problemas
Encontrar, compreender e adaptar os componentes reusáveis
Componentes de software precisam ser descobertos em uma biblioteca, compreendidos e, às vezes, adaptados para trabalhar em um novo ambiente.
Os engenheiros precisam estar confiantes de que encontrarão, na biblioteca, um componente, antes de incluírem a pesquisa como parte do processo normal de desenvolvimento.
Planejamento para Reuso
O reuso não ocorre por acaso
Ele deve ser planejado e incentivado em toda a organização
Muitas empresas desenvolvem sistemas de um mesmo domínio
Surgem situações potenciais para o reuso
Fatores do Planejamento
Alguns fatores a considerar no planejamento de reuso
Cronograma de desenvolvimento
Expectativa de duração do software
Conhecimento e experiência da equipe
Domínio da aplicação
Importância de requisitos não funcionais
A plataforma
Cronograma e Ciclo de Vida
Cronograma de Desenvolvimento
Se o cronograma de entrega é apertado, reusar pode agilizar a entrega do produto
Expectativa de duração do Software
Se o sistema terá vida longa e deve passar por muitas manutenções, reuso deve ser evitado
Componentes de terceiros podem ser de difícil manutenção (ou pode ser de código proprietário)
Equipe e Domínio
Conhecimento e experiência da equipe na abordagem de reuso
Muitas abordagens de reuso são difíceis de serem usadas e necessitam experiência da equipe
Domínio da aplicação
Em alguns domínios, é fácil encontrar componentes e bibliotecas para reuso
Em outros domínios, é mais complicado
Requisitos não funcionais e plataforma
Se o software tiver requisitos de desempenho rigorosos pode ser impossível usar estratégias como reuso baseado em geradores 	que levam a código ineficiente.
Componentes podem ser específicos para uma plataforma como, por exemplo, .NET que é específico para Microsoft.
Abordagens de Reuso
Abordagens de Reuso
Padrões de arquitetura
Padrões de arquitetura de software que oferecem suporte a tipos comuns de sistemas de aplicação são usados como base de aplicações. (caps. 6, 13 e 20)
Padrões de projeto
Abstrações genéricas que ocorrem em todas as aplicações são representadas como padrões de projeto, mostrando os objetos abstratos e concretos e as interações. (cap. 7)
Desenvolvimento baseado em componentes
Sistemas são desenvolvidos através da integração de componentes (coleções de objetos) que atendem a padrões de modelo e componente. (cap. 17)
Abordagens de Reuso
Framework de aplicações
Coleções de classes abstratas e concretas são adaptadas e estendidas para criar sistemas de aplicação.
Empacotamento de sistemas legados
Sistemas legados (veja o Capitulo 9) são 'empacotados' pela definição de um conjunto de interfaces para acesso a eles.
Sistemas orientados a serviços
Sistemas são desenvolvidos pela ligação de serviços compartilhados, que podem ser fornecidos externamente. São descritos no Capitulo 19.
Abordagens de Reuso
Linhas de produtos de software
Um tipo de aplicação é generalizado em torno de uma arquitetura comum para que esta possa ser adaptada para diferentes clientes.
Reuso de produto COTS (commercial off the shelf)
Sistemas são desenvolvidos pela configuração e integração de sistemas de aplicação existentes.
Sistemas de ERP (enterprise resource planning)
Sistemas de grande porte que sintetizam a funcionalidade e as regras de negócio genéricas são configurados para uma organização.
Abordagens de Reuso
Aplicações verticais configuráveis
Sistemas genéricos são projetados para poder ser configurados para as necessidades dos clientes de sistemas específicos.
Bibliotecas de programas
Bibliotecas de classe e funções que implementam abstrações comumente usadas são disponibilizadas para reuso.
Engenharia dirigida a modelos
O software é representado como modelo de domínio e modelo de implementação independentes. O código é gerado a partir desses modelos. São descritos no Capítulo 5.
Abordagens de Reuso
Geradores de programas
Um sistema gerador incorpora o conhecimento de um tipo de aplicação, e é usado para gerar sistemas nesse domínio apartir de um modelo de sistema fornecido pelo usuário.
Desenvolvimento de software orientado a aspectos
Quando o programa é compilado, os componentes compartilhados são integrados em uma aplicação em diferentes locais. São descritos no capítulo 21.
Padrões de Projeto
24
Padrões de Projeto
Um padrão é uma descrição do problema e a essência da sua solução
Documenta boas soluções para problemas recorrentes
Permite o reuso de conhecimento anterior documentados em boas práticas
Deve ser suficientemente abstrato para ser reusado em aplicações diferentes
Elementos de um Padrão
Nome
Um identificador significativo para o padrão
Descrição do problema
Descrição da solução
Um template de solução que pode ser instanciado em maneiras diferentes
Consequências
Os resultados e compromissos de aplicação do padrão
Exemplo de Problema
Padrão
Observador
Padrão Obsever
Nome
Observador
Descrição do problema
Separa o objeto de sua forma de apresentação
Descrição da solução (próximo slide)
Consequências
Otimizações para melhorar a atualização da apresentação
Solução do Observer
Frameworks de Aplicação
30
Framework
Frameworks são aplicações incompletas
São formados por interfaces, classes abstratas e classes concretas
O conjunto de classes e interfaces formam uma estrutura genérica
Um sistema é implementado pela adição de componentes para preencher partes do projeto
Por exemplo, pela implementação das classes abstratas no framework
Tipos de Frameworks
Frameworks de infra-estrutura
Apóiam a criação de infra-estruturas de sistemas, tais como comunicações, interfaces de usuário e compiladores
Frameworks de integração
Apóiam a comunicação e a troca de informações de componentes
Frameworks de aplicações
Apóiam o desenvolvimento de um tipo específico de aplicações
Extensão de Frameworks
Frameworks são entidades grandes que devem ser estendidas para serem reusados
Exemplos de extensão
Adição de classes concretas que herdam operações de classes abstratas
Adição (sobrescrita) de métodos que respondem os eventos conhecidos do framework
Principal Problema
Framework é uma entidade complexa
Leva um longo tempo para entendê-lo e usá-lo efetivamente
Framework de aplicações WEB
MVC
MVC
Permite a separação entre o estado da aplicação e a interface de usuário.
Oferece suporte à apresentação de dados de maneiras diferentes, e permite a interação com cada uma dessas apresentações.
Quando os dados são modificados por meio de uma das apresentações, o modelo de sistema é alterado e os controladores associados a cada visão atualizam sua apresentação.
Aplicações WEB
Normalmente incorporam um ou mais frameworks especializados, que oferecem suporte a recursos de aplicação específicos:
Proteção. Classes para ajudar a implementar a autenticação de usuário (login) e controle de acesso.
Páginas dinâmicas. As classes são fornecidas para ajudar na definição de templates de páginas e para preenchê-los dinamicamente.
Suporte de banco de dados. Classes que proporcionam uma interface abstrata para bancos de dados diferentes.
Gerenciamento de sessão.
Interação de usuário. Suporte a AJAX.
Reuso de Modelos e Geração de Código
38
Motivação
O reuso no nível de código é geralmente difícil 
Envolve vários detalhes específicos da solução ou da tecnologia adotada
Solução
Elevar o nível de abstração
O reuso passa ao nível de modelos
Reuso de código -> Reuso de modelos
Pelo uso de geradores, o programa é automaticamente gerado
Modelos x Código
Modelos têm vida útil mais longa
Modelos facilitam a comunicação entre desenvolvedores (e clientes)
Modelos são geralmente produzidos, mesmo que não se use um abordagem de geração de código
Desenvolvimento Dirigido por Modelos 
Propõe que o desenvolvimento, manutenção, evolução e reuso sejam feitos no nível de projeto
Reuso de modelos ainda é uma técnica pouco adotada
Se limitam a alguns domínios específicos ou em centros de pesquisa
Abordagem MDD
Os modelos são independentes de software
Assim como, código de alto nível é independente de hardware
Modelos Executáveis
Compilador de Modelos
Código de Alto Nível
Compilador de Código
Código de Baixo Nível
Abordagem MDD
Modelos podem ser compilados para várias linguagens de programação
Modelos podem ser parcialmente ou totalmente reusados em diferentes contextos
Modelos Executáveis
Compilador de Modelos
Código de Alto Nível
Compilador de Código
Código de Baixo Nível
O Processo MDD
Selecionar um modelo existente
Escolher partes do modelo que interessam ao sistema
Pode ser necessário projetar novos modelos ou adaptar os modelos existentes
Integrar as partes selecionadas ao modelo do sistema
Pegar uma tecnologia de implementação
Descrever (ou reusar) o mapeamento dos modelos para a implementação
Gerar o sistema
Potenciais Problemas
Imaturidade do desenvolvimento dirigido por modelos
Falta suporte de ferramentas e ambientes
Modelos são vistos como extras
Código seria o principal
Desenvolvedores são resistentes
Não gostam de “brincar” com figuras
Temem por seus empregos como programadores
Reuso de Componentes
47
CBSE
Engenharia de Software Baseada em Componentes
Reusar e integrar componentes pouco acoplados
Padrões devem ser seguidos para facilitar a integração
Componentes devem ser completamente especificados pelas suas interfaces
O Processo CBSE
Modelo de processo orientado ao reuso
Baseia-se na existência de um número significativo de componentes reusáveis
O processo se concentra na integração dos componentes
Especificação de Requisitos
Análise de Componentes
Modificação dos Requisitos
Projeto do Sistema com Reuso
Desenvolvimento e Integração
Validação do Sistema
Alinhar componentes aos requisitos
Análise de Componentes
Dada uma especificação, encontrar componentes que a atendam
Modificação dos Requisitos
Se possível, os requisitos são adaptados aos componentes existentes
Especificação de Requisitos
Análise de Componentes
Modificação dos Requisitos
Projeto do Sistema com Reuso
Desenvolvimento e Integração
Validação do Sistema
Integração dos Componentes
Projeto do Sistema com Reuso
Se necessário, projeta-se novos componentes reusáveis
Desenvolvimento e Integração
Desenvolvimento de novos componentes
Integração de todos os componentes
Especificação de Requisitos
Análise de Componentes
Modificação dos Requisitos
Projeto do Sistema com Reuso
Desenvolvimento e Integração
Validação do Sistema
Características de Componentes
Padronização
Devem seguir um padrão para facilitar integração
Independência
Devem ser auto suficientes com uma interface mínima
Substituível
Devem ser pensados para plugar ou remover
Bem documentado
Para permitir reuso efetivo, devem ter boa documentação
Componentes x Objetos
Componentes são geralmente implementados por uma linguagem OO
Mas, componentes e objetos não são a mesma coisa
Componentes estão prontos para serem implantados
Componentes não definem tipos
Mesmo desenvolvidos em linguagens diferentes, componentes são integráveis
Componentes são padronizados para integração
Notação de Componentes
Uma caixa com o nome do componente
Definem dois tipos de interfaces
Interfaces provedoras
Interfaces requeridas
Componente
<< interfaces provedoras >>
<< interfaces requeridas >>
Existem várias implementações para os modelos de componentes
CORBA da OMG, Enterprise Java Beans da Sun, COM+ da Microsoft, etc.
Interfaces
Interfaces provedoras
Publicam os serviços fornecidos pelo componente
Interfaces requeridas
Especificam os serviços requeridos para o completo funcionamento do componente
Vantagens de Componentes
Reduz a quantidade de software a ser desenvolvido
Espera-se reduzir os custos e os riscos
Espera-se uma entrega do produto mais rápida ao cliente
Potenciais Problemas
Pode-se desenvolver um produto que não atenda aos requisitos do cliente
Pode ser mais difícil evoluir os sistemas
Componentes de terceiros
A gerência de versões dos componentes pode ser complexa
Composição de Componentes
É o processo de montagem de componentes para criar o sistemaTipos de composição
Composição hierárquica
Composição sequencial
Composição aditiva
Composição Hierárquica
Um componente chama diretamente os serviços de outro componente
Uma interface provedora é composta diretamente a uma interface requerida
Composição Sequêncial
Serviços dos componentes constituintes são executados em sequência
Interfaces provedoras de dois componentes são compostas
Algum código extra
é necessário na composição
Composição Aditiva
Interfaces de dois ou mais componentes são compostas para criar um novo componente
A remoção de operações duplicadas pode ser necessária
Incompatibilidades
Durante a composição de componentes, podem ocorrer incompatibilidades
Tipos comuns de incompatibilidades são
Incompatibilidade de operação
Incompatibilidade de parâmetros
Operações incompletas
Incompatibilidade de Operação
Os nomes das operações nas interfaces provedoras e requeridas são diferentes
Exemplo
Requerida: 
public void debitar(double valor);
Provedora:
public void sacar(double valor);
Incompatibilidade de Parâmetros
As operações têm o mesmo nome nas interfaces, mas os parâmetros são diferentes
Exemplo
Requerida: 
public void debitar(double valor);
Provedora:
public void debitar(int conta, double valor);
Operações incompletas
As operações de uma interface provedora é um subconjunto das operações da interface requerida
Ou vice-versa
Exemplo
Provedora: debitar e creditar
Requerida: debitar
Componente Adaptador
Problemas de incompatibilidade são geralmente resolvidos usando um componente adaptador
Exemplos de adaptações
Adicionar ou remover operações (específicas da aplicação)
Renomear componentes ou elementos internos dos componentes, etc.
Representação do Adaptador
Um componente adaptador converte uma interface em outra
A implementação é mínima
Tipicamente, componentes adaptadores não implementam novos 
serviços
Tipos de Adaptadores
O tipo do adaptador depende da natureza da composição
Hierárquica, sequencial ou aditiva
Escolha da Solução
Em muitas situações, existem soluções variadas para o mesmo problema
Exemplo
Considere um sistema de coleta de dados de fontes diferentes e geração de relatórios a partir destes dados
Possíveis Soluções CBSE
Vantagens da Solução A
Os gerenciamentos dos dados e da geração de relatórios estão separados
Há maior flexibilidade para mudanças futuras
Tanto do componente de Gerenciamento de Dados quanto o Gerador de Relatórios podem ser substituídos de forma independente
Vantagens da Solução B
Um componente de Banco de Dados tem a geração de relatórios built-in
Semelhante ao que ocorre no MS Access
Menos componentes são necessários
O sistema pode ter melhor desempenho, pois evita o overhead de comunicação
Regras de integridade dos dados podem ser implementadas no mesmo componente
As regras são válidas tanto para os dados quanto para o relatório que apresenta os dados (menos replicação)
Resumo
CBSE é uma abordagem baseada em reuso para definir e implementar componentes fracamente acoplados nos sistemas
Um componente é uma unidade de software cuja funcionalidade e dependência são completamente definidas pelas suas interfaces
73
Resumo
Um modelo de componentes define um conjunto de padrões que os componentes devem seguir
Composição de componentes é o processo de junção de componentes para criar o sistema
Ao compor componentes reusáveis, é normalmente necessário escrever adaptadores
Linhas de Produtos de Software
75
Linha de Produtos
Conjunto de aplicações definidas sobre uma arquitetura comum e que compartilham componentes
Criada a partir de várias aplicações desenvolvidas sobre o mesmo domínio
Uma forma mais efetiva de reuso em larga escala
Usa outras técnicas de reuso
Frameworks, componentes, etc.
Extração da Linha
Processo de extração de uma linha de produtos
Cria uma aplicação
Cria outra aplicação no mesmo domínio 
Reusa algo da primeira aplicação na segunda
Cria uma terceira aplicação e reusa...
e assim por diante
Motivação
Especialização da plataforma
Ex. Android, IOS, Windows Phone. Windows, Linux, Mac OS.
Especialização do ambiente
Ex. Refletir a funcionalidade do sistema de comunicação
Especialização funcional
Ex. Biblioteca universitária ou pública
Especialização de processo
Ex. Centralizado distribuído
Processo de Desenvolvimento
Levantar os requisitos dos usuários
Escolher elementos da linha de produtos que atendem de forma aproximada os requisitos
Negociar os requisitos com o cliente para minimizar alterações
Adaptar o sistema para atender todos os requisitos
Integrar o novo membro à “família” 
Cada nova aplicação é um novo membro da linha de produtos
Componentes de uma Linha
Elementos mandatórios
Aquelas que são encontradas em todos os membros da linha de produto
Elementos variáveis
Opcionais: um produto pode ou não contê-los
Alternativos: um produto deve conter uma das alternativas
Exemplo de Linha de Produtos
Características Mandatórias
Todo produto deve permitir a visualização, adição, remoção e edição da legenda
View, Add, Delete, Edit Label
Características Opcionais
Os produtos não precisam conter outras características como
Capture Photo, Sort by Views, etc.
Características Alternativas
Os produtos devem considerar algum tamanho para a tela
Algumas Vantagens
Redução de custos
Redução do tempo de entrega
Redução de esforço de manutenção
Estimativas facilitadas 
Esforço, custos, prazos, etc.
Aumento da qualidade
Bibliografia Principal
Ian Sommerville. Engenharia de Software, 9ª Edição. Pearson Education, 2011.
Cap. 16 Reuso de Software
(Seções 16.1 a 16.5)
86
image1.jpg
image2.png
image3.jpg
image4.jpg
image5.emf
Comp A
Comp B
image6.emf
Comp A
Comp B
Extra
image7.emf
Comp A
Comp B
Extra 1
Extra 2
image8.emf
Sistema
Adaptador
Adaptado
image9.png
image10.png
image11.jpeg
image12.png
image13.png
image14.png
image15.png
image16.png
image17.png