 Adelino Moreira Marcial Neto  Alex A. Toniatto  Gabriela Santini.

Apresentação em tema: " Adelino Moreira Marcial Neto  Alex A. Toniatto  Gabriela Santini."— Transcrição da apresentação:

1

2  Adelino Moreira Marcial Neto  Alex A. Toniatto  Gabriela Santini

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

4  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.

5  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.

6  Maior produtividade;  Produtos com melhor qualidade, mais consistentes e padronizados;  Diminuição de custos e tempo gastos no desenvolvimento;

7  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;

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

9  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;

10  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;

11  Padrões de projetos (Design Patterns)  Frameworks  Componentes  Biblioteca de Classes

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

13  Diversas categorias: - Padrões de processo, - Padrões arquiteturais, - Padrões de análise, - Padrões de projeto, - Padrões de programação.

14  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

15  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)

16 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; };

17 class FloppyDisk: public Equipment{ public: FloppyDisk(const char*); virtual ~FloppyDisk(); virtual Watt Power(); virtual Currency NetPrice(); virtual Currency DiscountPrice(); };

18  É um conjunto de classes abstratas e concretas que fornecem uma infra- estrutura 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.

19  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

20  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.

21  Framework Caixa Branca - reuso provido por herança  Framework Caixa Preta - reuso provido por composição  Framework Caixa Cinza - mistura

22  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

23  Frameworks de Infra-estrutura do Sistema -Simplificam o desenvolvimento da infra- estrutura 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

24  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

25  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

26  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.

27  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

28  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.

29  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.

30  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;

31 › 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.

32  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 certificar que ele não tem erros?

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

34 OBRIGADO!!!