O documento discute os vários níveis de reutilização na perspectiva de frameworks e padrões de projeto. Aborda a reutilização nos paradigmas funcional e orientado a objetos, conceitos como classe, herança, composição e componentes. Também discute frameworks, tipos, vantagens e desvantagens, além de padrões de projeto comuns em frameworks como Template Method e Abstract Factory.

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.