Reutilização
Upcoming SlideShare
Loading in...5
×
 

Reutilização

on

  • 6,287 views

Reutilização Descrição

Reutilização Descrição

Statistics

Views

Total Views
6,287
Views on SlideShare
6,267
Embed Views
20

Actions

Likes
1
Downloads
131
Comments
1

2 Embeds 20

http://www.slideshare.net 19
http://webcache.googleusercontent.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Reutilização Reutilização Presentation Transcript

    • Eduardo Manuel de Freitas Jorge [email_address] Reutilização sobre a ótica de Framework e Padrões de Projeto
    • Tópicos Abordados
      • Contexto e Motivação
      • Reutilização no Paradigma Funcional e Orientado a Objetos
      • Framework e Padrões de Projeto
    • Contexto
      • O desenvolvimento de projetos de software não é uma tarefa fácil.
        • têm que ser robustos;
        • atuar sobre problemas complexos;
        • estar implantados em curto prazo (“time-to-market”).
      • A reutilização é reconhecida como um importante modo para se alcançar aumento na produtividade em projetos de software,
        • possibilita agregar funcionalidades pré-existentes na produção de novos software .
    • O objetivo
      • O objetivo é discutir os vários níveis reutilização sobre a ótica de Framework e Padrões de Projeto.
        • Conhecimento;
        • Padrões;
        • Análise;
        • Projeto;
        • Código;
    • Motivação
      • A reutilização de pedaços de software garante uma maior qualidade ao projeto ,
        • visto que os blocos a serem reutilizados já estão testados e validados por uma ou mais aplicações.
      • O direcionamento no desenvolvimento de um projeto de software é para que não se construa nada que já exista e que possa ser reutilizado.
    • Reutilização no Paradigma Funcional e Orientado a Objetos
    • Como alcançar reutilização no Paradigma Funcional?
    • Reutilização no Paradigma Funcional
      • Reutilização no Paradigma Funcional
        • Chamada de Funções
      • A reutilização de pedaços é mais difícil usando paradigma Funcional ( modularização via funções) porque não é possível usar “coisas” pré-existentes tão facilmente.
    • Como alcançar reutilização no Paradigma OO?
    • Reutilização no Paradigma OO
      • Os primeiros registros da concepção dos conceitos de Orientação a Objetos surgiram com a linguagem Simula na década de 60, na Noruega, no centro de Norweigan Computin Center (NCC).
      • O cerne desse paradigma era a criação de um modelo computacional que fosse similar aos elementos do mundo real.
        • Formado essencialmente por objetos ou “coisas”.
    • Reutilização no Paradigma OO
      • OO agrega as formas de reutilização do Paradigma Funcional.
      • Dentre as diversas metodologias existentes
        • OO é reconhecido como o principal paradigma para a construção de software reutilizável.
        • Apesar do grande sucesso do paradigma OO, nem sempre os resultados, em relação a reutilização, são obtidos de forma fácil .
      Programa Funções Dados Classe Métodos Atributos P. Funcional P. O. O. Objeto Estado Métodos
    • Reutilização no Paradigma OO:Objeto
      • Objetos são pequenos módulos que agregam estado e comportamento.
        • Com objetos, posso dizer: "me dê dois daqueles" porque objetos têm estado.
        • Não posso fazer isso com funções porque elas não encapsulam estado.
    • Reutilização no Paradigma OO: Classe
      • Quando um objeto é instanciado a partir de uma classe herda todas as suas características.
        • Um objeto é gerado sempre a partir de uma classe (instância de classe), herdando todas as suas características atributos e métodos, adicionando mais o estado.
    • Reutilização no Paradigma OO:Herança
      • Reutilização com herança
        • Semelhante a herança genética do mundo real.
      • Deve ser utilizado com muito cuidado.
        • Erros são comuns na utilização de herança de classes
    • Exemplo de Utilização de Herança
    • Exemplo de Erro na Utilização de Herança
      • Solução Composição: Também se obtém reutilização
    • Reutilização no Paradigma OO: Conceito de Componente
      • O conceito de componente de software é entendido como uma composição de classes que juntas formam uma unidade para cumprir certas responsabilidades.
        • Componentes devem possuir uma interface pública para a comunicação com os blocos de código externos.
        • Eles têm como principal característica o funcionamento como caixas pretas , onde o desenvolvedor não precisa, necessariamente, conhecer os detalhes de sua implementação .(Abstração->redução de complexidade)
      Interface Publica
    • Reutilização no Paradigma OO: Conceito de Componente
      • Componentes visam a construção de projetos com alto grau de reutilização e compartilhamento de código
        • gerando uma redução no ciclo de desenvolvimento e facilitando as futuras manutenções corretivas e evolutivas.
        • Um ponto importante a ser analisado é que um software normalmente possui um custo mais alto de manutenção do que de desenvolvimento .
        • Desenvolvimento 3 a 6 meses / Manutenção 5 a 50 anos.
    • Reutilização no Paradigma OO: Componente
      • Os benefícios da reutilização de componentes puderam ser melhor observados através de ferramentas RAD ( Rapid Aplication Development )
        • Ampla utilização a partir da década de 90
        • Ajudou na popularização da OO ( saída do meio acadêmico )
      • Os mecanismos de construção de aplicações para o desenvolvedor na ferramenta RAD se dá através da reutilização de componentes visuais, previamente construídos,
        • Componentes que são manipulados e customizados para atender aos requisitos específicos da aplicação que está sendo construída.
        • São aplicadas, principalmente, na construção de elementos da camada de interface, tais como menus, botões , telas, tabelas, combos , etc.
      • Um exemplo clássico de ferramentas RAD são as IDE Visual Basic, Delphi, Centura, etc.
    • Reutilização no Paradigma OO: Ferramenta RAD
      • Apesar dos benefícios alcançados com a produtividade e facilidade no desenvolvimento de software diversos problemas relacionados com a construção de aplicações baseados em RAD são identificados.
      • Como as ferramentas RAD direcionam o desenvolvedor a construir software com um forte acoplamento entre a camada de aplicação e a camada de interface alguns problemas na manutenção podem ocorrer.
        • Por exemplo, o espalhamento de regras de negócio na telas, assim quando existe uma mudança é necessário alterar vários pontos do software.
      Reutilização no Paradigma OO: Componente Tela
    • Reutilização no Paradigma OO: Componente Subsistema 01 Subsistema 02 Subsistema 03 Acoplamento fraco Acoplamento fraco
    • Resumo
      • Chama de Funções
      • Objetos
      • Na instância de classe
      • Herança de classe
      • Composição
      • Uso de Componentes
    • Reutilização
      • A questão que se coloca é:
        • Como `encapsular’, em bibliotecas ou em componentes, comportamentos genéricos para um domínio de aplicação, que possam ser usados em software de mesmo domínio, só que com características específicas?
      • O conceito de Framework não é algo recente e desconhecido na engenharia de software.
        • Desde do final da década de 80, muitas pesquisas nesta área já tinham sido realizadas .
      • Então, porque só mais recentemente o conceito de framework tem sido largamente aceito?
        • À maturidade das linguagens orientadas a objeto (Java, C++, etc);
        • À demanda por projetos de software mais complexos e reutilizáveis;
        • Aos novos recursos da engenharia de software como padrões de projeto, processo interativo incremental, UML, etc.
      •     
      Framework: Introdução
    • Framework: Definições
      • Iniciamos com uma definição genérica: “Framework na sua essência pode ser definido como um conjunto de blocos de software que os programadores podem usar, estender, ou `customizar ´ , com pouco esforço, para um domínio específico de problema.” [IBM 99].
      • Já uma definição mais técnica determina que “ Um framework é um conjunto de classes colaborativas abstratas e concretas, que pode ser usado como um `template’ (gabarito) para resolver uma família de problemas relacionados. Ele é usualmente estendido através de subclasses, para obter-se o comportamento específico de uma aplicação. ” [LAR00]
    • Framework: Estrutura
      • O framework deve permitir construir uma aplicação quase que completamente, faltando apenas `pedaços´ para serem completados com as funcionalidades específicas das futuras aplicações.
        • Mais precisamente, a arquitetura do framework deve ser tal que possibilitará às aplicações que vierem a ser construídas utilizar a sua infra-estrutura.
      Framework Extensão Aplicação
    • Framework:Hot-Spots
      • Pontos do Framework que variam em cada aplicação
      FRAMEWORK APLICAÇÃO 1 APLICAÇÃO 2
    • Framework: Estrutura Framework
    • Framework X Biblioteca de Classes
      • A confusão entre os dois conceitos é uma incompreensão clássica entre desenvolvedores de software.
      • Framework ainda pode ser visto como uma espécie de biblioteca, só que o controle do fluxo de chamadas é bi-direcional , ou seja, tanto uma aplicação pode chamar métodos do framework como o framework pode invocar métodos da aplicação.
        • Isto é diferente de uma biblioteca de classes stricto sensu , em que o fluxo de chamadas é uni-direcional, da aplicação para a biblioteca.
        • A possibilidade de o framework chamar métodos da aplicação se dá através de chamadas “dynamic binding”, implementadas nas subclasses da extensão do framework para a aplicação.
    • Framework – Princ. de Hollywood
      • “ Não nos chame. Nós chamamos você.”
      [LAN 1995] Framework Biblioteca Código feito pelo desenvolvedor Chamadas Chamadas
    • Um Processo Voltado para o Desenvolvimento de Framework Orientado a Objeto
      • O projeto de um Framework difere de projetar uma aplicação convencional.
      • Necessidade de adotar-se um processo específico e voltada para a construção de Framework .
      • Segue o Processo Unificado (Iterativo e Incremental)
      • O objetivo maior é o de migrar o máximo de comportamento comum das aplicações para o framework.
      1.Análise de Domínio 2. Captura de Requisitos e Análise 3. Projeto do Framework Implementação do Framework Testes Análise da Aplicação Projeto da Aplicação Implementação da Aplicação Análise Projeto
    • Um Processo Voltado para o Desenvolvimento de Framework Orientado a Objeto
      • Requisitos e Análise ( I dentificação dos Requisitos)
      [LAN 1995]
    • Framework: Classificação e Tipos
      • Classificação
        • Caixa Branca (white-box) – É um framework em que o usuário tem um poder maior de personalização do mesmo, em compensação é necessário um maior entendimento de sua estrutura de classes.
        • Caixa Preta (black-box) – É utilizado através da composição de objetos, os seus componentes já estão prontos para serem utilizados o desenvolvedor deve apenas encaixar suas classes nos pontos do framework que necessitam de extensão (hotspots).
      • Tipos
        • Horizontal (Delphi, Visual Basic, Structs, J2EE, J2ME, Hibernate, JSP, etc)
          • ATHOS;
        • Vertical (E-Commerce, Gerencia de Rede, etc)
          • S-DW-E;
    • Qual o tipo de reutilização alcançada com Framework?
    • Framework: Reutilização
      • Framework provê reutilização em alto nível.
        • É possível construir projetos extensíveis, em que a reutilização está focada desde o domínio da aplicação.
        • Reutilização desde o projeto conceitual até o projeto de baixo nível.
        • Software bem testado
        • Boas práticas de programação
    • Quais as desvantagens da utilização de um Framework?
    • Desvantagens na utilização de Framework
      • Curva de aprendizado
      • Acoplamento com os conceitos e tecnologia encapsulados no Framework
      • Correção de problemas encapsulados no framework
    • Como tornar projetos mais reutilizáveis, com menos acoplamento e com um maior nível de reutilização? Tarefa para desenvolvedores experientes
    • Padrões de Projeto
      • A definição clássica para os Designs Patterns é a seguinte: "um Pattern descreve um problema que se repete várias vezes em um determinado meio, e em seguida descreve o núcleo da sua solução, de modo que esta solução possa ser usada milhares e milhares de vezes” [ALE77] .
    • Padrões de Projeto: Histórico
      • Os Designs Patterns originam-se no final dos anos 80,
        • quando Ward Cunningham e Kent Beck desenvolveram um conjunto de padrões para serem aplicados no desenvolvimento de interfaces do usuário elegantes em Smalltalk .
      • No mesmo período, Jim Coplien estava desenvolvendo um catálogo de padrões C++ chamados idiomas.
    • Padrões de Projeto: Histórico
      • Erich Gamma estava trabalhando em sua tese de doutorado sobre desenvolvimento de software orientado a objeto, e reconheceu a importância de acumular explicitamente as estruturas de projetos que se repetiam com frequência.
        • Em 1994, quatro autores – Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides - publicaram o primeiro catálogo de Design Patterns para programas orientado a objetos: Design Patterns – Elements of Reusable Object-Oriented software .
        • Esse livro descreve soluções simples para problema específicos no projeto de software orientado a objetos.
    • Padrões de Projeto: Aplicado em Outras Áreas
      • No seu livro - A Pattern Language : Towns, Buildings, Construction - mostra como patterns podem ser aplicados na construção de casas, assim como no planejamento de bairros e cidades. 
    • Padrões de Projetos mais Comuns em um projeto de um Framework
      • Padrões de Projetos mais comuns em um projeto de um framework
        • “ Façade”, “Command”, “Template Method”, e “Abstract Factory”.
      • “ Template Method” é a base para a construção de um framework.
    • Padrões Usados em Arquitetura JEE
      • ValueObject
        • Os clientes de aplicação precisam trocar dados com os EJB
          • Classe simples com os atributos e métodos get/set
          • A classe deve ser serializável
    • Padrões Usados em Arquitetura JEE
      • Session Facade
        • Fornece um ponto único e simples de entrada para beans de entidade compartilhados.
        • Utilizar um bean de Sessão como um facade para encapsular a complexidade das interações entre os objetos de negócio participantes em um fluxo de trabalho.
        • O Session Facade gerencia os objetos de negócios e fornece uma camada de acesso a serviços uniforme e de granulação grossa para os clientes.
          • Expõe um interface uniforme;Reduz o acoplamento; Reduz os métodos de granulação fina;Expõe menos interfaces remotas para o cliente; Amplia a reutilização
    • Padrões Usados em Arquitetura JEE
      • Data Access Object (DAO)
        • O acesso a dados varia e depende da origem dos dados.
        • Para extrair e encapsular todos os métodos de acessos à dados.
          • Transparência
          • Permite a migração mais fácil
          • Reduz a complexidade dos códigos de negócios
          • Centraliza todos o acesso de dados em uma camada separada
    • Vantagens na Utilização de Padrões de Projeto
      • Desenvolvedores iniciantes podem utilizar padrões de projetos catalogados por “experts” para obter conhecimento e experiência na construção de aplicações orientadas a objeto.
      • Com a boa utilização de padrões de projeto a comunicação entre desenvolvedores, e a manutenção de sistemas, tornam-se menos complexas.
      • Padrões de projeto podem ajudar a encontrar abstrações que tornem o software mais flexível e reutilizável .
    • Pergunta Final: Como programar rápido pensando na aplicação de padrões de projeto, na geração de uma aplicação reutilizável e com baixo acoplamento?
    • Refatoramento
    • Fim
    • Referencias Bibliográficas
      • [GAM94] GAMMA E. & HELM R. & JOHNSON R. & VLISSIDES J., Design Patterns Elements of Reusable Object-Oriented Software,. Addison-Wesley, 1994.
      • [GRA 1998] GRAND, Mark. Patterns in Java: a catalog of reusable design patterns illustrated with UML. New York: Wiley Computer Publishing, 1998. 467p.
      • [JOR 2001] JORGE, Eduardo M. Análise, Projeto e Implementação de um Servidor de DW Extensível . Campina Grande: UFPB, 2001. 140p. cap.3.
      • [LAN 1995] LANDIN, Niklas; NIKLASSON, Axel. Development of Object-Oriented Frameworks. Lund: Lund Institute of Technology, Lund Institute, 1995. 145p.
      • [LAR 2000] LARMAN, Craig. Utilizando UML e padrões : uma introdução à análise e ao projeto orientados a objetos. Porto Alegre: Bookman, 2000. 492p.
      • [RAT 2003]RATIONAL SOFTWARE CORPORATION. Rational Unified Process . Disponível em: http://www.rational.com/products/rup/index . jsp . Acesso em: 19 Fev 2003.