Transcript Reuso de Software


Adelino Moreira Marcial Neto

Alex A. Toniatto

Gabriela Santini
A crescente busca por melhorias e
soluções na área de desenvolvimento
de software tem estimulado o estudo e
construção de melhores formas de
trabalho.
A utilização do reuso de software de
maneira eficiente tem trazido grandes
benefícios e demonstrado ser um
excelente diferencial competitivo para
as empresas.

Reuso de software
› É o processo de criar sistemas de software a
partir de software que já existe, ao invés de
construí-lo desde a fase zero.

O principal objetivo do reuso de
software é evitar se refazer o trabalho no
desenvolvimento de um novo projeto,
capitalizando trabalhos anteriores,
fazendo com que as soluções já
desenvolvidas sejam imediatamente
implementadas em novos contextos.

Maior produtividade;

Produtos com melhor qualidade, mais
consistentes e padronizados;

Diminuição de custos e tempo gastos no
desenvolvimento;

Facilidade na manutenção e evolução
da estrutura do software produzido;

Desenvolvimento com menos perda de
tempo;

Conformidade aos padrões, diminuindo
os erros cometidos pelo usuário;
Os engenheiros de software tem
observado que de 40% a 60% dos
códigos de programação são reusáveis
(em aplicações); 75% das funções são
comuns a mais de um programa e
somente 15% dos códigos são únicos.

Identificação, recuperação e
modificação de sistemas reutilizáveis;

Compreensão dos sistemas
recuperados;

Qualidade de sistemas reutilizáveis;

Criação de aplicações a partir de
componentes reutilizáveis;

Maior custo de manutenção;

Poucas ferramentas de apoio;

Barreiras psicológicas, legais e
econômicas;

É necessário uma política de incentivos
à reutilização;

Padrões de projetos (Design Patterns)

Frameworks

Componentes

Biblioteca de Classes
Descreve soluções para problemas
recorrentes no desenvolvimento de
sistemas de software.
Visa facilitar a reutilização de soluções
de desenho, isto é, soluções na fase de
projeto do software, sem considerar
reutilização de códigos. Também acarreta
um vocabulário comum de desenhos,
facilitando a comunicação,
documentação e aprendizado do sistema
de software.

Diversas categorias:
- Padrões de processo,
- Padrões arquiteturais,
- Padrões de análise,
- Padrões de projeto,
- Padrões de programação.
Leaf: representa objetos “folha” na
composição; define o comportamento para
objetos primitivos na composição
 Composite: define o comportamento para
componentes que têm filhos; armazena
componentes filhos e implementa operações
relacionadas aos filhos na interface
Component
 Client: manipula objetos na composição
através da interface Component

Reuso de soluções encontradas por
especialistas experientes -> aumento de
produtividade e qualidade
 Melhoria na comunicação entre
projetistas
 Uniformidade na estrutura do software
 Menor complexidade (blocos
construtivos)

class Equipment{
public:
virtual ~Equipment();
const char* Name(){return_name;}
virtual Watt Power();
virtual Currency NetPrice();
virtual Currency DiscountPrice();
virtual void Add(Equipment*);
virtual voidRemove(Equipment*);
virtual Iterator* CreateIterator();
protected:
Equipment(const char*);
private:
const char* _name;
};
class CompositeEquipment: public
Equipment{
public:
virtual ~CompositeEquipment();
virtual Watt Power();
virtual Currency NetPrice();
virtual Currency DiscountPrice();
virtual void Add(Equipment*);
virtual voidRemove(Equipment*);
virtual Iterator* CreateIterator();
protected:
CompositeEquipment(const char*);
private:
List_equipment;
};
class FloppyDisk: public Equipment{
public:
FloppyDisk(const char*);
virtual ~FloppyDisk();
virtual Watt Power();
virtual Currency NetPrice();
virtual Currency DiscountPrice();
};
É um conjunto de classes abstratas e
concretas que fornecem uma infraestrutura genérica de soluções para um
conjunto de problemas.
 Contribuem para a reutilização porque
possuem uma base bem definida para
construção de software ou
componentes, e podem ser divididos em
duas categorias: frozen spots e hot spots.


Frozen Spots :
Definem a arquitetura geral de um
sistema, com seus componentes básicos
e o relacionamento entre eles, que se
mantém intacta em qualquer
instanciação do framework de
aplicação

Hot Spots
Representam as partes do framework
de aplicação que são específicas para
cada sistema de software. São
projetadas para serem genéricos e
adaptáveis às necessidades da
aplicação desenvolvida.
Framework Caixa Branca
- reuso provido por herança
 Framework Caixa Preta
- reuso provido por composição
 Framework Caixa Cinza
- mistura

Framework caixa branca é mais fácil de projetar
 Framework caixa preta é mais fácil de usar
 Frameworks caixa-branca evoluem para se tornar
mais caixa preta
•Aumenta o numero de objetos, mas eles ficam
menores
•Complexidade está na interconexão
•Objetos compostos de objetos menores
•O “Scripting” fica mais importante e as linguagens
visuais tornam-se possíveis


Frameworks de Infra-estrutura do Sistema
-Simplificam o desenvolvimento da infraestrutura de sistemas portáveis e eficientes,
-Exemplos: sistemas operacionais,
comunicação, interfaces com o usuário e
ferramentas de processamento de
linguagem
-Em geral são usados internamente em uma
organização de software e não são
vendidos a clientes diretamente

Frameworks de Integração de Middleware
- usados em geral para integrar aplicações e
componentes distribuídos.
- projetados para melhorar a habilidade de
desenvolvedores em modularizar, reutilizar e
estender sua infra-estrutura de software para
funcionar “sem costuras” em um ambiente
distribuído
- exemplos: Object Request Broker(ORB),
middleware orientado a mensagens e bases de
dados transacionais

Frameworks de Aplicação Empresarial
- Voltados a domínios de aplicação mais amplos
e são a pedra fundamental para atividades de
negócios das empresas.
- Exemplos: telecomunicações, aviação,
manufatura e engenharia financeira.
-São mais caros para desenvolver ou comprar,
mas podem dar um retorno substancial do
investimento, já que permitem o
desenvolvimento de aplicações e produtos
diretamente

Um componente pode ser definido
como uma unidade de software
independente, que encapsula, dentro
de si, seu projeto e implementação, e
oferece serviços, por meio de interfaces
bem definidas, para o meio externo.

Objetivo: quebra de blocos monolíticos em
componentes inter-operáveis

Um componente provê um conjunto de
serviços acessíveis por meio de uma interface
bem definida

Motivações: desenvolvimento da
Internet/WWW, arquitetura cliente/servidor,
computação distribuída, Orientação a Objetos,
Componentware, dentre outros

Componentes são reutilizáveis;

Alguns são de uso mais geral e outros
têm uso mais específico, mas todos são
genéricos dentro do escopo
considerado;

Componentes interagem com outros
componentes.
Classes de uso genérico podem ser
disponibilizadas para reuso e importadas
em múltiplas aplicações
 Em geral são incorporadas ao código
final da aplicação, ou seja, são
compiladas juntamente com o restante
do código.


Questões a serem consideradas:
› Faça seu componente o mais geral possível,
prevendo condições similares às que
podem ocorrer;
› Separe as dependências de forma que
seções modificáveis sejam isoladas das que
devem permanecer iguais;
› Mantenha a interface geral e bem-definida;
› Inclua informações sobre problemas
encontrados e resolvidos;
› Use convenções claras para nomeação;
› Documente as estruturas de dados e
algoritmos;
› Separe as seções de comunicação e
tratamento de erros.

Perguntas a serem feitas:
- O componente executa a função e fornece
os dados que você precisa?
- Se forem necessárias mudanças mínimas,
trata-se de menos esforço do que construir o
componente do zero?
- O componente está bem documentado, de
forma que possa ser estendido sem ter que
entender linha por linha do código?
- Existe um registro completo do teste do
componente e histórico da revisão, para
O reuso de software nos projetos tem
contribuído para o ganho de
produtividade e diminuição de
retrabalho nos projetos desenvolvidos
pelas equipes. Além disso, os projetos
estão cada vez mais confiáveis e com
melhor qualidade, já que os erros
anteriormente existentes são corrigidos.
OBRIGADO!!!