Your SlideShare is downloading. ×
  • Like
Reutilização
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Reutilização

  • 3,966 views
Published

Reutilização Descrição

Reutilização Descrição

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
3,966
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
134
Comments
1
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Eduardo Manuel de Freitas Jorge [email_address] Reutilização sobre a ótica de Framework e Padrões de Projeto
  • 2. Tópicos Abordados
    • Contexto e Motivação
    • Reutilização no Paradigma Funcional e Orientado a Objetos
    • Framework e Padrões de Projeto
  • 3. 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 .
  • 4. 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;
  • 5. 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.
  • 6. Reutilização no Paradigma Funcional e Orientado a Objetos
  • 7. Como alcançar reutilização no Paradigma Funcional?
  • 8. 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.
  • 9. Como alcançar reutilização no Paradigma OO?
  • 10. 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”.
  • 11. 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
  • 12. 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.
  • 13. 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.
  • 14. 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
  • 15. Exemplo de Utilização de Herança
  • 16. Exemplo de Erro na Utilização de Herança
    • Solução Composição: Também se obtém reutilização
  • 17. 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
  • 18. 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.
  • 19. 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.
  • 20. Reutilização no Paradigma OO: Ferramenta RAD
  • 21.
    • 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
  • 22. Reutilização no Paradigma OO: Componente Subsistema 01 Subsistema 02 Subsistema 03 Acoplamento fraco Acoplamento fraco
  • 23. Resumo
    • Chama de Funções
    • Objetos
    • Na instância de classe
    • Herança de classe
    • Composição
    • Uso de Componentes
  • 24. 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?
  • 25.
    • 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
  • 26. 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]
  • 27. 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
  • 28. Framework:Hot-Spots
    • Pontos do Framework que variam em cada aplicação
    FRAMEWORK APLICAÇÃO 1 APLICAÇÃO 2
  • 29. Framework: Estrutura Framework
  • 30. 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.
  • 31. Framework – Princ. de Hollywood
    • “ Não nos chame. Nós chamamos você.”
    [LAN 1995] Framework Biblioteca Código feito pelo desenvolvedor Chamadas Chamadas
  • 32. 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
  • 33. Um Processo Voltado para o Desenvolvimento de Framework Orientado a Objeto
    • Requisitos e Análise ( I dentificação dos Requisitos)
    [LAN 1995]
  • 34. 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;
  • 35. Qual o tipo de reutilização alcançada com Framework?
  • 36. 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
  • 37. Quais as desvantagens da utilização de um Framework?
  • 38. 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
  • 39. Como tornar projetos mais reutilizáveis, com menos acoplamento e com um maior nível de reutilização? Tarefa para desenvolvedores experientes
  • 40. 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] .
  • 41. 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.
  • 42. 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.
  • 43. 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. 
  • 44. 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.
  • 45. 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
  • 46. 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
  • 47. 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
  • 48. 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 .
  • 49. 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?
  • 50. Refatoramento
  • 51. Fim
  • 52. 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.