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

Slides:



Advertisements
Apresentações semelhantes
TIPOS ABSTRATOS DE DADOS
Advertisements

Desenvolvimento de aplicativos Orientados a Objetos: Definição e Características THIAGO IDEALI.
Manutenção em software Conceitos básicos
ABSTRAÇÃO processo de representar um grupo de entidades através de seus atributos comuns feita a abstração, cada entidade particular (instância) do grupo.
Carlos Roberto Marques Junior
Rational Unified Process
Fundamentos de Engenharia de SW
Técnicas de Teste de Software
UNIVERSIDADE ESTADUAL DE MATO GROSSO DO SUL SISTEMAS DE INFORMAÇÃO ENGENHARIA DE SOFTWARE Métricas de Software Prof.ª Adriana dos Santos Caparróz Carvalho.
Engenharia de Software
Engenharia de Software
Orientação por Objectos > Modelo de Processo OO > Identificação de Classe e Objectos Aula 12.
Introdução ao paradigma de programação: Orientado a Objetos
Análise Estruturada O mais amplamente usado dos métodos de modelagem de requisitos Modelos que retratam fluxo e o conteúdo da informação (dados e controle)
Engenharia Reversa É o processo de derivar as especificações lógicas dos componentes do sistema a partir de sua descrição física com auxílio de ferramentas.
Análise e Projeto de Sistemas
Implementação de Sistemas
TIPOS DE TESTES APLICÁVEIS E NÃO APLICÁVEIS AO PROJETO
Aspectos Avançados em Engenharia de Software Aula 3 Fernanda Campos
TSDD Teste de segurança durante o desenvolvimento.
TÉCNICAS DE PROGRAMAÇÃO II
Configuração de manutenção
DIAGRAMA DE COMPONENTES
Middleware e Sistemas Distribuídos
Seminário de Engenharia de Usabilidade
Aula 1 Minicurso: Astah Ministrantes: André Martins; Camila Brondani;
Frameworks - Introdução
Linguagens Orientadas a Objeto
Desenvolvimento de Sistemas Orientados a Aspectos
Análise e Projeto de Sistemas
Métodos de Construção de Software: Orientação a Objetos
Análise e Projeto de Sistemas
Tipos Abstratos de Dados
Estudo de Caso: um editor de documentos
Desenvolvimento Rápido de Aplicação (RAD)
Gerência de Configuração - GC
Orientação a Objetos Parte I
Programação Orientada à Objetos
Prof. Silvestri – todos os direitos reservados SISTEMAS DISTRIBUIDOS Aula 5 Eduardo Silvestri
INTRODUÇÃO À ORIENTAÇÃO A OBJETOS EM JAVA
SISTEMAS DISTRIBUIDOS Aula 4
Documentação de Software
O que é? É o processo de investigação técnica com intuito de identificar a qualidade, a segurança e a exatidão do software desenvolvido. A validação do.
RUP - Cap. 4 – Processo Centrado na Arquitetura
METODOLOGIA, MÉTODOS E FERRAMENTAS
Laboratório de Programação
Integração de Ferramentas CASE
Padrões de Projeto Abstract Factory.
UML e a Ferramenta Astah
Padrão de desenvolvimento
© 2007 by Pearson Education ©Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 18 Slide 1 Reuso de Software.
Design Patterns A adoção dos padrões terá um efeito profundo e duradouro sobre a forma de escrevermos programas Ward Cunningham e Ralph Johnson.
Infra-Estrutura para Computação Distribuída
1 Padrões: Composite (p. 163) Objetivo: compor objetos em estruturas de árvores para representar relações de parte/todo. “Composite” permite tratar objetos.
Padrões de projeto M.Sc. Sílvio Bacalá Jr..
Padrão Composite Definição
Objetos Distribuídos Frameworks Orientados a Objetos.
Desenvolvimento Global de Software
Frameworks e Componentes Daniel Fernando Pavelec.
Processo e Qualidade.
Estilos Arquiteturais
Introdução à Programação Orientada a Objeto
Módulo II Capítulo 1: Orientação a Objetos
Padrões de Projetos Orientados a Objetos I Wolley W. Silva.
PADROES DE PROJETO PROF. OSIEL MARLON. PADRÕES DE PROJETO INTRODUÇÃO Padrões de projeto têm emergido como uma das mais promissoras abordagens para a melhoria.
TÉCNICAS DE ESTIMATIVAS
SugarloafPLoP 2004 – Fortaleza - CE
Eduardo C. Nicácio ITIL v3 Foundation Certified.  As melhores práticas do ITIL abrangem cinco processos de suporte a serviços, além do papel do Service.
Engenharia de Software Orientada a Objetos Professor: Guilherme Timóteo Aula 3: – Modelagem de Classes (parte 2)
O Processo Unificado (PU). 2 O que é o Processo Unificado (PU)? É um modelo de processo de software baseado no modelo incremental, visando a construção.
Transcrição da apresentação:

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

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

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

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!!!