Your SlideShare is downloading. ×
Proposta de Arquitetura de Desenvolvimento Web Baseada em PHP Utilizando Design Patterns. Um Estudo de Caso
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Proposta de Arquitetura de Desenvolvimento Web Baseada em PHP Utilizando Design Patterns. Um Estudo de Caso

7,763
views

Published on

Trabalho de Conclusão de Curso submetido ao Centro de Ensino Superior de Foz do Iguaçu.

Trabalho de Conclusão de Curso submetido ao Centro de Ensino Superior de Foz do Iguaçu.

Published in: Technology

2 Comments
6 Likes
Statistics
Notes
No Downloads
Views
Total Views
7,763
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
261
Comments
2
Likes
6
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. CENTRO DE ENSINO SUPERIOR DE FOZ DO IGUACU ¸ ˆ ¸˜ CURSO DE CIENCIA DA COMPUTACAO TRABALHO DE CURSO PROPOSTA DE ARQUITETURA DE DESENVOLVIMENTO WEB BASEADA EM PHP UTILIZANDO DESIGN PATTERNS. UM ESTUDO DE CASO FERNANDO GERALDO MANTOAN FOZ DO IGUACU - PR ¸ 2009
  • 2. FERNANDO GERALDO MANTOAN PROPOSTA DE ARQUITETURA DE DESENVOLVIMENTO WEB BASEADA EM PHP UTILIZANDO DESIGN PATTERNS. UM ESTUDO DE CASO Trabalho de Conclus˜o de Curso submetido a ao Centro de Ensino Superior de Foz do Igua¸u como parte dos requisitos para a c obten¸ao do grau de bacharel em Ciˆncia da c˜ e Computa¸˜o. ca Orientador: Prof. Gildomiro Bairros FOZ DO IGUACU - PR ¸ 2009
  • 3. ¸˜ TERMO DE APROVACAO FERNANDO GERALDO MANTOAN PROPOSTA DE ARQUITETURA DE DESENVOLVIMENTO WEB BASEADA EM PHP UTILIZANDO DESIGN PATTERNS. UM ESTUDO DE CASO Este trabalho foi julgado adequado para a obten¸˜o do grau de bacharel em Ciˆncia ca e da Computa¸ao e aprovado em sua forma final pelas disciplinas de Trabalho de Curso I e c˜ II. BANCA EXAMINADORA Prof. Arlete T. Beuren Prof. Samuel Bellido FOZ DO IGUACU - PR ¸ 2009
  • 4. A todos os meus familiares, em especial ` a minha m˜e por todo amor, apoio e carinho a dado nesta longa jornada, esta conquista a ` ´ a forma de demonstrar-lhe gratid˜o. A e todos os meus amigos e ` comunidade PHP. a
  • 5. Agradecimentos Primeiramente a Deus, por sempre me iluminar e ser o meu apoio nas horas mais dif´ ıceis, sempre sou muito grato pela ajuda que o Senhor me d´. a Aos meus pais, em especial a minha m˜e, pelo incentivo e apoio, apesar de n˜o parecer ` a a vocˆ sempre foi minha fonte de inspira¸ao e motiva¸˜o. e c˜ ca Tamb´m a todos os professores que estiveram nesta jornada de quatro anos, eles e foram uma otima fonte de conhecimento e tiveram suma importˆncia na minha carreira ´ a acadˆmica e profissional. e Agrade¸o tamb´m ao meu orientador, Prof. Gildomiro, que, al´m de ser um grande c e e amigo e ex-colega de trabalho, tamb´m ´ um de meus professores, por todo apoio, id´ias, e e e paciˆncia e amizade. e Agrade¸o aos meus colegas, pelos momentos de estudo, divers˜o e discuss˜es. c a o
  • 6. “Procure ser um homem de valor, em vez de ser um homem de sucesso.” Albert Einstein
  • 7. Resumo A presente monografia apresenta a proposta de uma arquitetura de desenvolvimento web baseada em PHP que utiliza design patterns. A arquitetura foi constru´ utilizando ıda Orienta¸ao a Objetos, o que permite a utiliza¸ao dos diversos design patterns que s˜o c˜ c˜ a voltados a solu¸ao de problemas de projetos orientados a objetos. O principal objetivo da ` c˜ arquitetura ´ fornecer uma estrutura organizada, altamente reutiliz´vel e produtiva; onde e a o ciclo de vida de uma aplica¸ao pode ser prolongado, gra¸as a alta manutenibilidade c˜ c fornecida por esta arquitetura. Ao longo deste documento ´ feito um estudo sobre o con- e ceito de arquiteturas de software, sobre design patterns e sobre o PHP e seus frameworks, al´m dele conter todos os detalhes da arquitetura definida e do estudo de caso de uma e aplica¸˜o de controle de bibliotecas. ca Palavras-chave: Arquitetura de Software, Design Patterns, PHP, Frameworks, Zend Framework.
  • 8. Abstract The present monograph represents a proposal of a PHP based web development ar- chitecture that uses design patterns. The architecture was built using Object Oriented programming, which allows the use of the many existing design patterns that have the purpose of solving the object-oriented project problems. The main goal of the architecture is to provide an organized structure, highly reusable and productive; where the life cycle of an application can be increased, thanks to the high maintainability that the architecture provides. Through this document there will be a study about the concept of software architectures, design patterns and PHP and its frameworks, and furthermore, it will have every detail of the defined architecture and the case study of a library control application. Key-words: Software Architecture, Design Patterns, PHP, Frameworks, Zend Frame- work.
  • 9. Lista de Figuras 2.1 Modelo em Cascata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2 Modelo de 7 Camadas OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.1 Relacionamentos entre os padr˜es de projeto o . . . . . . . . . . . . . . . . 26 3.2 MVC Cl´ssico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 a 3.3 Data Mapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.4 Table Data Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.1 Requisi¸˜o CakePHP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 ca 4.2 Requisi¸˜o do Code Igniter . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 ca 6.1 Camadas da Arquitetura de Software. . . . . . . . . . . . . . . . . . . . . . 53 7.1 Diagrama de Casos de Uso. . . . . . . . . . . . . . . . . . . . . . . . . . . 56 7.2 Diagrama de Classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 7.3 Modelo de Entidades e Relacionamentos. . . . . . . . . . . . . . . . . . . . 58 7.4 Estrutura de Diret´rios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 o 7.5 Tela de listagem de empr´stimos. . . . . . . . . . . . . . . . . . . . . . . . 68 e 7.6 Tela de cria¸˜o de um empr´stimo. . . . . . . . . . . . . . . . . . . . . . . 69 ca e 7.7 Tela de devolu¸˜o de item de empr´stimo. . . . . . . . . . . . . . . . . . . 69 ca e
  • 10. Lista de Tabelas 7.1 Especifica¸˜o dos casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . 57 ca
  • 11. Lista de Listagens 7.1 Arquivo de Configura¸ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 c˜ 7.2 Facade de Empr´stimo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 e 7.3 Factory de Facades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 7.4 Data Mapper de Empr´stimo . . . . . . . . . . . . . . . . . . . . . . . . . 62 e 7.5 Table Data Gateway de Empr´stimo . . . . . . . . . . . . . . . . . . . . . 63 e 7.6 Model da entidade Empr´stimo . . . . . . . . . . . . . . . . . . . . . . . . 63 e 7.7 Classe Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 7.8 Classe Observable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.9 Controller de Empr´stimo . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 e 7.10 View de Listagem de Empr´stimos . . . . . . . . . . . . . . . . . . . . . . 67 e 7.11 Formul´rio de Empr´stimo . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 a e
  • 12. Lista de Abreviaturas e Siglas AJAX Asynchronous Javascript And XML DRY Don’t Repeat Yourself GOF Gang of Four HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol JSON JavaScript Object Notation MVC Model-View-Controller PHP Hypertext Preprocessor PHP/FI Personal Home Pages/Forms Interpreter REST Representational State Transfer RSS Really Simple Sindication SGBD Sistema Gerenciador de Banco de Dados SOAP Simple Object Access Protocol SQL Structured Query Language UML Unified Modeling Language URL Uniform Resource Locator XML Extensible Markup Language XSS Cross-site Scripting
  • 13. Sum´rio a 1 Introdu¸˜o ca 16 1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.1.1 Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.1.2 Espec´ ıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2 Arquiteturas de Software 20 2.1 A Importˆncia de uma Arquitetura de Software . . . . . . . . . . . . . . . 21 a 2.2 Arquitetura de Software no processo de desenvolvimento de sistemas . . . 21 2.3 Arquitetura em Camadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3 Design Patterns 25 3.1 Padr˜es de Cria¸ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 o c˜ 3.1.1 Abstract Factory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.1.2 Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.1.3 Factory Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.1.4 Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.1.5 Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.2 Padr˜es Estruturais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 o 3.2.1 Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2.2 Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
  • 14. 3.2.3 Composite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2.4 Decorator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.2.5 Facade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.2.6 Flyweight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.2.7 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3 Padr˜es Comportamentais . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 o 3.3.1 Chain of Responsibility . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3.2 Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.3.3 Interpreter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.3.4 Iterator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.3.5 Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.3.6 Memento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.3.7 Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.3.8 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.3.9 Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.3.10 Template Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.3.11 Visitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.4 Design Patterns Arquiteturais . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.4.1 Model-View-Controller . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.4.2 Data Mapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.4.3 Table Data Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4 PHP 39 4.1 Hist´rico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 o 4.2 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.2.1 Zend Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.2.2 CakePHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
  • 15. 4.2.3 Prado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.2.4 Code Igniter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5 Ambiente Experimental 47 5.1 Tecnologias Envolvidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.1.1 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.1.2 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.1.3 Apache HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.1.4 HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.1.5 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.2 Padr˜es Envolvidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 o 5.2.1 Programa¸˜o Orientada a Objetos . . . . . . . . . . . . . . . . . . . 49 ca 5.2.2 Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.3 Estrutura F´ ısica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.3.1 Ambiente F´ ısico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.3.2 Configura¸oes de Hardware c˜ . . . . . . . . . . . . . . . . . . . . . . 50 5.4 Estrutura L´gica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 o 5.4.1 Sistema Operacional . . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.4.2 Aplicativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.4.2.1 Astah* Community . . . . . . . . . . . . . . . . . . . . . . 51 5.4.2.2 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.4.2.3 phpMyAdmin . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.4.3 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.4.3.1 Zend Framework . . . . . . . . . . . . . . . . . . . . . . . 52 6 Arquitetura Definida 53 6.1 Fluxo da Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
  • 16. 7 Implementa¸˜o ca 55 7.1 Documenta¸ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 c˜ 7.1.1 Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 7.1.2 Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . 57 7.1.3 Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 7.2 Desenvolvimento da Aplica¸˜o . . . . . . . . . . . . . . . . . . . . . . . . . 59 ca 7.2.1 Neg´cio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 o 7.2.1.1 Facade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 7.2.1.2 Factory Method . . . . . . . . . . . . . . . . . . . . . . . . 61 7.2.1.3 Data Mapper e Table Data Gateway . . . . . . . . . . . . 62 7.2.1.4 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 7.2.1.5 Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 7.2.2 Camada de Mais Alto N´ ıvel . . . . . . . . . . . . . . . . . . . . . . 65 8 Considera¸˜es Finais co 70 8.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Referˆncias Bibliogr´ficas e a 72
  • 17. 16 1 Introdu¸˜o ca Os padr˜es de projeto (design patterns), originaram-se na area de constru¸ao civil, o ´ c˜ onde Christopher Alexander e seus colegas proporam a id´ia de utilizar uma linguagem e padronizada para arquitetar edif´ ıcios e cidades. A Gang of Four (GOF), composta por 4 programadores: Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides; viu que o conceito por tr´s dos padr˜es de projetos tamb´m se aplicava ` area de inform´tica, o a o e a´ a que resultou em um livro com as especifica¸˜es de vinte e trˆs padr˜es de projeto para co e o sistemas orientados a objeto. Os design patterns foram especificados para prover uma solu¸ao reutiliz´vel a um problema de software comum a diversos projetos. (GAMMA et c˜ a al., 1995) O Hypertext Preprocessor (PHP) ´ uma das linguagens de script mais populares dos e ultimos anos. Um dos principais motivos desta popularidade ´ a baixa curva de aprendiza- ´ e gem. Esta facilidade da linguagem pode acarretar em c´digos sem padroniza¸˜o. Com o ca isso, quando um projeto PHP tem um aumento em sua complexidade e em seu tamanho, mais dif´ de se dar manuten¸˜o ele se torna. Com a orienta¸˜o a objetos, aprimorada ıcil ca ca na vers˜o 5 da linguagem, foi poss´ se obter uma melhor codifica¸˜o e reutiliza¸˜o de a ıvel ca ca c´digo. (HAYDER, 2007) o Al´m da orienta¸˜o a objetos, pode-se aumentar ainda mais o ciclo de vida e a e ca padroniza¸ao de uma aplica¸˜o utilizando uma arquitetura de software. Segundo Bass, c˜ ca Clements e Kazman (2003), uma arquitetura de software ´ uma abstra¸ao de um sistema e c˜ que suprime detalhes dos elementos que n˜o afetam como eles utilizam, s˜o utilizados por, a a se relacionam com, ou interagem com outros elementos. Tendo estas premissas em vista, a proposta deste trabalho ´ fazer um estudo sobre e os diversos design patterns especificados pela GOF, para propor uma arquitetura para desenvolvimento de aplica¸˜es web que contenha os patterns que auxiliem numa maior co estrutura organizacional. Esta arquitetura ser´ baseada em frameworks dispon´ a ıveis para PHP, focando o princ´ ıpio Don’t Repeat Yourself (DRY) de se reaproveitar estruturas j´ a
  • 18. 17 prontas para se trabalhar. Procurando-se definir estes padr˜es de projeto e escolher os melhores frameworks para o PHP pode-se levantar as seguintes quest˜es: entre todos os design patterns existentes, o como escolher os mais adequados, sem que haja um anti-pattern na arquitetura? Como modificar um framework PHP existente, aplicando-se design patterns para melhorar a organiza¸˜o do mesmo? ca Para auxiliar na escolha dos design patterns ´ necess´rio uma an´lise nos frameworks e a a que utilizam design patterns mais famosos da linguagem PHP e nos design patterns mais utilizados por desenvolvedores web experientes, separando-se os que mais se aplicarem a ` arquitetura proposta. A escolha do framework que ir´ compor o n´cleo da arquitetura ser´ feita com base a u a em um estudo entre os principais frameworks Model-View-Controller (MVC) feitos para a linguagem PHP, escolhendo-se o que mais oferece componentes, helpers e uma estrutura organizacional flex´ ıvel. 1.1 Objetivos 1.1.1 Geral Propor uma arquitetura de desenvolvimento de aplica¸oes em PHP contendo design c˜ patterns que forne¸a uma maior estrutura organizacional, padroniza¸˜o de programa¸˜o, c ca ca facilidade de manuten¸ao, menos repeti¸ao de c´digo e que evite bad smell 1 . c˜ c˜ o 1.1.2 Espec´ ıficos • Explicar os conceitos e a importˆncia das arquiteturas de software; a • Explanar o conceito de design patterns, descrevendo os vinte e trˆs design patterns e definidos pela GOF; • Apresentar a linguagem PHP e detalhar seus principais frameworks; • Propor uma arquitetura de software, detalhando os design patterns e frameworks escolhidos para compˆ-la; o 1 Termo criado por Kent Beck e Martin Fowler, quando existe um “mal cheiro” no c´digo isto significa o que algo est´ errado, e que ele precisa ser refatorado, por exemplo, quando uma solu¸˜o poderia ser a ca simples e ´ implementada utilizando muitas linhas de c´digo desnecess´rias e o a
  • 19. 18 • Realizar um estudo de caso na elabora¸˜o de uma aplica¸ao de cadastro de livros, ca c˜ utilizando a arquitetura de software proposta. 1.2 Justificativa “A importˆncia de utilizar padr˜es se torna mais clara quando se passa a enxergar a o que um projeto pode se tornar invi´vel, seja por custo ou tempo, se o c´digo tiver de ser a o escrito do zero toda vez e sem crit´rios.” (MELO; NASCIMENTO, 2007, p. 188) e Baseando-se em Gamma et al. (1995), os padr˜es de projeto tornam f´cil a reuti- o a liza¸ao de projetos e arquiteturas, eles provˆem alternativas de projeto que tornem um c˜ e sistema reutiliz´vel e que n˜o comprometam a reusabilidade. Eles tamb´m aumentam a a a e documenta¸˜o e a manuten¸˜o de sistemas j´ prontos, por fornecerem uma especifica¸ao ca ca a c˜ expl´ ıcita de classes e intera¸oes de objetos e suas inten¸oes subjacentes. c˜ c˜ 1.3 Metodologia Quanto a natureza da pesquisa ela pode ser classificada como aplicada pois “[...] ´ ` e feita a partir de objetivos que visam sua utiliza¸ao pr´tica. Valem-se essas pesquisas das c˜ a contribui¸˜es das teorias e leis j´ existentes.” (PARRA; SANTOS, 2002, p.101) co a Quanto aos objetivos, esta pesquisa classifica-se como explorat´ria pois “[...] tˆm o e como objetivo proporcionar maior familiaridade com o problema, com vistas a torn´-lo a mais expl´ ıcito ou a constituir hip´teses.” (GIL, 2002, p.41) o Tratando-se dos procedimentos de pesquisa ser´ utilizado, inicialmente, a pesquisa a bibliogr´fica, por ser “[...] desenvolvida com base em material j´ elaborado constitu´ a a ıdo principalmente de livros e artigos cient´ ıficos.” (GIL, 2002, p.44). Posterior a etapa da ` pesquisa bibliogr´fica, ser´ adotada a pesquisa experimental porque, segundo Gil (2002), a a consiste em determinar um objeto de estudo, selecionar as vari´veis que seriam capazes a de influenci´-lo, definir as formas de controle e de observa¸ao dos efeitos que a vari´vel a c˜ a produz no objeto. Na etapa de desenvolvimento do software de controle de estoque ser´ utilizado o a modelo de an´lise Orientado a Objetos, que segundo Hayder (2007, p.12) “[...] permite a que um problema seja divido em outros problemas menores que s˜o comparativamente a mais f´ceis de compreender.”. Ao se fazer representa¸ao de dados, ser´ utilizada a Unified a c˜ a
  • 20. 19 Modeling Language (UML). A UML ´ uma linguagem visual, criada durante a d´cada e e de 1990, que visa fazer a modelagem de sistemas orientados a objeto, utilizando-se de v´rios elementos gr´ficos para construir diagramas que representem as v´rias vis˜es de a a a o um sistema (MELO; NASCIMENTO, 2007).
  • 21. 20 2 Arquiteturas de Software Uma arquitetura ´ o resultado de uma s´rie de decis˜es de neg´cio e t´cnicas. Existem e e o o e diversas influˆncias para se trabalhar em um projeto, e a realiza¸ao destas influˆncias mu- e c˜ e dar˜o de acordo com o ambiente que a arquitetura dever´ atuar. Um arquiteto projetando a a um sistema no qual os prazos sejam curtos far´ uma s´rie de escolhas, enquanto que o a e mesmo arquiteto projetando um sistema similar, por´m com prazos maiores, poder´ fazer e a diferentes escolhas para o projeto. Mesmo que os requisitos, hardware, software de suporte e recursos humanos dispon´ ıveis sejam parecidos, um projeto de software desenvolvido por um arquiteto nos dias atuais poder´ ser diferente de um desenvolvido a cinco anos atr´s. a a (BASS; CLEMENTS; KAZMAN, 2003) A arquitetura ´ a representa¸ao que permite ao engenheiro de software analisar a e c˜ efetividade do projeto em satisfazer seus requisitos declarados, considerar alternativas arquiteturais num est´gio em que fazer modifica¸˜es de projeto ´ ainda relativamente a co e f´cil e reduzir os riscos associados com a constru¸ao do software. (PRESSMAN, 2002) a c˜ Segundo Bass, Clements e Kazman (2003) uma arquitetura ´, principalmente, uma e abstra¸ao de um sistema que suprime detalhes de elementos que n˜o afetam como eles c˜ a utilizam, s˜o utilizados por, se relacionam com ou interagem com outros elementos. Em a quase todos os sistemas modernos, elementos interagem entre si a partir de interfaces que particionam detalhes sobre um elemento em partes p´blicas e privadas. A arquitetura est´ u a preocupada com a parte p´blica desta divis˜o; detalhes privados n˜o s˜o arquiteturais. u a a a Tratando-se do projeto arquitetural, um componente de software pode ser t˜o simples a quanto um m´dulo de um programa, mas tamb´m pode ser ampliado contendo bases de o e dados e middleware que permite a configura¸˜o de uma rede de clientes e servidores. As ca rela¸oes entre componentes podem ser simples como uma chamada de procedimento de c˜ um m´dulo, como tamb´m podem ser complexas como um protocolo de acesso a base de o e dados. (PRESSMAN, 2002)
  • 22. 21 2.1 A Importˆncia de uma Arquitetura de Software a Para Bass, Clements e Kazman (2003) quando se trata da perspectiva t´cnica, existem e trˆs raz˜es para a importˆncia da arquitetura de software, que s˜o: e o a a • Comunica¸˜o entre os envolvidos no projeto. A arquitetura de software rep- ca resenta uma abstra¸ao comum de um sistema que muitos, se n˜o todos, dos envolvi- c˜ a dos no projeto podem utilizar como a base de um m´tuo entendimento, negocia¸ao, u c˜ consenso e comunica¸ao; c˜ • Decis˜es de in´ o ıcio de projeto. Uma arquitetura de software manifesta as decis˜es o iniciais de um sistema, estas possuindo profundo impacto com as pr´ximas etapas, o como o restante do desenvolvimento, o deploy do sistema, e o ciclo de manuten¸ao. c˜ Este tamb´m ´ o ponto inicial onde decis˜es de projeto espec´ e e o ıficas sobre o sistema a ser desenvolvido podem ser analisadas; • Abstra¸˜o transfer´ ca ıvel de um sistema. A arquitetura constitui um modelo rel- ativamente pequeno e intelectualmente intelig´ de como um sistema ´ estruturado ıvel e e como seus elementos trabalham em conjunto, e este modelo ´ transfer´ entre os e ıvel sistemas. Em particular, ela pode ser aplicada a outros sistemas que exibam atrib- utos de qualidade e requisitos funcionais similares, podendo promover reutiliza¸˜o ca em larga escala. 2.2 Arquitetura de Software no processo de desen- volvimento de sistemas Segundo Sommerville (2003) no processo cl´ssico de desenvolvimento de software a chamado de modelo em cascata, existe uma sequˆncia de fases a se seguir, onde cada e fase depende de sua anterior. Ele pode ser visto na Figura 2.1.
  • 23. 22 Figura 2.1: Modelo em Cascata (SOMMERVILLE, 2003) Apesar da execu¸˜o rigorosa das fases de engenharia de requisitos e de an´lise, ´ pos- ca a e s´ notar uma lacuna de informa¸oes a serem especificadas para que se possa prosseguir ıvel c˜ com a fase de projeto. Isto significa que especificar e modelar as funcionalidades de um sistema n˜o ´ o suficiente para saber como o sistema deve ser estruturado e organizado, a e visando atender aos requisitos funcionais e atributos de qualidade. (VAROTO, 2002) A arquitetura de software prop˜e diversas atividades que tentam cobrir esta lacuna o entre as fases de an´lise e projeto, dentre elas a elabora¸ao de um modelo de dom´ a c˜ ınio que ressalta o escopo do sistema, a identifica¸˜o das dependˆncias de constru¸ao e o ca e c˜ mapeamento dos requisitos n˜o funcionais que o sistema deve atender e que n˜o foram a a totalmente especificados na fase de engenharia de requisitos. A diferen¸a entre as fases c de an´lise e de projeto e as atividades de arquitetura s˜o evidentes quando se trata de a a sistemas grandes e complexos, principalmente por, nestes casos, o entendimento claro, o escopo e as poss´ ıveis evolu¸oes serem mais d´ c˜ ıficeis de identificar, dado o tamanho da incerteza resultante da falta de conhecimento do neg´cio. (VAROTO, 2002) o A constru¸ao da arquitetura deve objetivar o sistema como um todo, mas com os c˜ elementos m´ ınimos necess´rios para realizar a implementa¸ao da primeira vers˜o. Se a a c˜ a arquitetura for focada apenas nas funcionalidades priorizadas para a primeira vers˜o, a a incorpora¸ao de mudan¸as ou novas funcionalidades para a pr´xima vers˜o pode exigir c˜ c o a uma altera¸ao t˜o grande que seja necess´rio refazer toda a arquitetura, implicando em c˜ a a tempo e custos adicionais. (VAROTO, 2002)
  • 24. 23 2.3 Arquitetura em Camadas Em uma arquitetura em camadas um certo n´mero de camadas diferentes s˜o u a definidas, cada uma realizando opera¸oes que se tornam progressivamente mais pr´xi- c˜ o mas do conjunto de instru¸oes de m´quina. Na camada exterior, os componentes operam c˜ a na interface com o usu´rio. Na camada mais interna os componentes realizam a inter- a face com o sistema operacional. As camadas intermedi´rias fornecem servi¸os utilit´rios a c a e fun¸˜es do software de aplica¸ao. (PRESSMAN, 2002) co c˜ Protocolos de rede s˜o os exemplos mais conhecidos de arquitetura em camadas. Cada a protocolo consiste em uma s´rie de regras e conven¸˜es que descrevem como programas e co de computadores se comunicam sobre as fronteiras de m´quinas. O formato, conte´do a u e significado de todas as mensagens s˜o definidos. Todos os cen´rios s˜o descritos em a a a detalhes, geralmente atrav´s de gr´ficos de sequˆncia. O protocolo especifica acordos em e a e uma variedade de camadas de abstra¸˜o, indo desde detalhes da transmiss˜o de bits at´ a ca a e l´gica da aplica¸˜o de mais alto n´ o ca ıvel. Portanto projetistas usam diversos subprotocolos e organizam eles em camadas. Cada camada lida com um aspecto espec´ ıfico de comunica¸ao c˜ e usa o servi¸o da pr´xima camada mais baixa. Um exemplo de utiliza¸˜o de arquitetura c o ca em camadas ´ o Modelo de 7 Camadas OSI, utilizado em redes de computadores, este ´ e e apresentado na Figura 2.2. (BUSCHMANN et al., 1996) Figura 2.2: Modelo de 7 Camadas OSI (BUSCHMANN et al., 1996 apud TANENBAUM, 1992) Adaptada. Uma abordagem em camadas ´ considerada de melhor pr´tica do que a implementa¸ao e a c˜
  • 25. 24 do protocolo como um bloco monol´ 1 , porque a implementa¸ao separada de proble- ıtico c˜ mas que possuem conceitos distintos resulta em diversos benef´ ıcios, como, por exemplo, possibilidade de desenvolvimento em equipes. A utiliza¸˜o de partes semi-independentes ca tamb´m fornece a possibilidade de se trocar com mais facilidade partes individuais poste- e riormente. Melhores tecnologias de implementa¸ao como novas linguagens ou algoritmos c˜ podem ser incorporadas, simplesmente re-escrevendo uma se¸ao de c´digo delimitada. c˜ o (BUSCHMANN et al., 1996) 1 diz-se dos elementos que formam um todo r´ ıgido, homogˆneo. e
  • 26. 25 3 Design Patterns Segundo Gamma et al. (apud ALEXANDER et al., 1977), cada padr˜o de projeto a (design pattern) descreve um problema que ocorre constantemente no ambiente de tra- balho, e ent˜o descreve o n´cleo da solu¸ao para aquele problema, de uma maneira que a u c˜ possa-se utilizar esta solu¸ao milhares de vezes, nunca precisando fazer a mesma coisa c˜ mais de uma vez. Este conceito definido por Alexander era direcionado a padr˜es de constru¸˜o civil, o ca por´m ele tamb´m se torna verdadeiro em projetos de software orientados a objeto. As e e solu¸oes s˜o expressas em termos de objetos e interfaces ao inv´s de paredes e portas, c˜ a e mas no n´celo dos dois tipos de padr˜es encontra-se uma solu¸˜o de um problema em um u o ca determinado contexto. (GAMMA et al., 1995). Assim, segundo Gamma et al. (1995), um padr˜o de projeto nomeia, abstrai e identi- a fica os principais aspectos de uma estrutura de projeto comum, tornando esta estrutura util para a cria¸ao de um projeto que seja orientado a objetos e reutiliz´vel. O padr˜o ´ c˜ a a de projeto identifica as classes e instˆncias participantes, suas regras e colabora¸˜es e a a co distribui¸ao de responsabilidades. Cada padr˜o de projeto est´ focado em um problema c˜ a a de projeto orientado a objeto particular. Ele descreve quando ´ aplicado, se pode ser e aplicado visando outras restri¸˜es do projeto e as consequˆncias de seu uso. co e Padr˜es de projeto tornam f´cil de se reutilizar projetos e arquiteturas e ajudam na o a escolha de alternativas de projetos que tornam um sistema reutiliz´vel e evitam alterna- a tivas que comprometem a reusabilidade. Eles podem ainda melhorar a documenta¸ao e c˜ manuten¸ao de sistemas existentes por eles proporcionarem uma especifica¸ao expl´ c˜ c˜ ıcita de classes e intera¸˜s de objetos e suas inten¸˜es subjacentes. Apresentando de uma maneira co co mais simples, padr˜es de projeto ajudam um projetista a definir um projeto muito mais o rapidamente. (GAMMA et al., 1995) Os padr˜es de projeto possuem formas de classifica¸ao a partir de seu prop´sito que, o c˜ o segundo Gamma et al. (1995), pode ser de cria¸˜o, de estrutura¸˜o ou de comporta- ca ca
  • 27. 26 mento: • Padr˜es de cria¸ao est˜o focados no processo de cria¸ao de objetos; o c˜ a c˜ • Padr˜es estruturais cuidam da composi¸ao de classes ou de objetos; o c˜ • Padr˜es comportamentais caracterizam os meios em que as classes ou os objetos o ir˜o interagir e distribuir responsabilidades. a A Figura 3.1 ilustra os design patterns, os relacionamentos que eles possuem entre si e a classifica¸ao de cada um. c˜ Figura 3.1: Relacionamentos entre os padr˜es de projeto o Gamma et al. (1995, p. 12) Adaptada.
  • 28. 27 3.1 Padr˜es de Cria¸˜o o ca Os padr˜es de projeto de cria¸˜o abstraem o processo de instancia¸˜o. Eles ajudam a o ca ca fazer com que um sistema seja independente de como seus objetos s˜o criados, compostos a e representados. Um padr˜o de cria¸˜o de classes utiliza heran¸a para variar a classe que a ca c ´ instanciada, enquanto que um padr˜o de cria¸˜o de objetos delegar´ a instancia¸˜o a e a ca a ca outro objeto. (GAMMA et al., 1995) 3.1.1 Abstract Factory O int´ito do padr˜o Abstract Factory ´ prover uma interface para a cria¸ao de fam´ u a e c˜ ılias de objetos relacionados ou dependentes entre si, sem a necessidade de se especificar suas classes concretas. (GAMMA et al., 1995) Um dos principais benef´ ıcios que o Abstract Factory traz ´ seu aux´ no controle de e ılio classes e objetos que uma aplica¸˜o cria. Devido a uma factory encapsular a responsabil- ca idade e o processo de cria¸˜o de objetos, ela isola clientes de implementar classes. Eles ca manipular˜o instˆncias atrav´s de suas interfaces abstratas. (GAMMA et al., 1995) a a e 3.1.2 Builder Segundo Gamma et al. (1995), o objetivo do padr˜o de projeto Builder ´ separar a e a constru¸˜o de um objeto complexo de sua representa¸ao, fazendo com que o mesmo ca c˜ processo de constru¸ao possa criar diferentes representa¸˜es. c˜ co O Builder melhora a modularidade por encapsular a forma com que um objeto com- plexo ´ constru´ e representado. Os clientes n˜o precisam saber nada sobre as classes e ıdo a que definem a estrutura interna de um produto, estas classes n˜o aparecem na interface a deste padr˜o de projeto. Cada Builder concreto cont´m o c´digo para criar e montar um a e o tipo particular de produto. (GAMMA et al., 1995) 3.1.3 Factory Method Este padr˜o de projeto define uma interface para a cria¸˜o de um objeto, mas deixa a ca que sub-classes decidam qual classe instanciar. O Factory Method deixa que uma classe delegue a instancia¸˜o para as subclasses. (GAMMA et al., 1995) ca Segundo Gamma et al. (1995), ao utilizar o Factory Method pode-se eliminar a neces-
  • 29. 28 sidade de se ligar classes espec´ ıficas da aplica¸ao ao c´digo. O c´digo apenas lidar´ com c˜ o o a a interface da classe; portanto ele poder´ trabalhar com qualquer classe concreta definida a pelo usu´rio. a 3.1.4 Prototype O Prototype especifica os tipos de objetos a se criar utilizando uma instˆncia como a prot´tipo, e cria novos objetos copiando-se este prot´tipo. (GAMMA et al., 1995) o o Assim como os padr˜es Abstract Factory e Builder, o Prototype encapsula as classes o concretas do cliente, dessa forma reduzindo o n´mero de nomes que os clientes conhecem. u Al´m disso, estes padr˜es permitem que um cliente trabalhe com classes espec´ e o ıficas da aplica¸˜o sem modifica¸˜es. (GAMMA et al., 1995) ca co 3.1.5 Singleton O principal objetivo do padr˜o de projeto Singleton, segundo Gamma et al. (1995), a ´ garantir que uma classe tenha somente uma instˆncia, e forne¸a um ponto global de e a c acesso a ela. Alguns dos benef´ ıcios que este padr˜o traz s˜o: a a • Acesso controlado a uma unica instˆncia: Devido ` classe Singleton encapsular ´ a a sua unica instˆncia, pode-se obter um controle restrito em torno de como e quando ´ a clientes a acessar˜o; a • Espa¸o de nomes reduzido: O padr˜o Singleton ´ uma melhoria de vari´veis c a e a globais. Ele evita a polui¸˜o do espa¸o de nomes com vari´vels globais que ar- ca c a mazenam instˆncias unicas. (GAMMA et al., 1995) a ´ 3.2 Padr˜es Estruturais o Segundo Gamma et al. (1995), padr˜es classificados como estruturais est˜o preocu- o a pados em como classes e objetos s˜o compostos para formar estruturas maiores. Padr˜es a o estruturais de classe usam heran¸a para compor interfaces ou implementa¸oes. Padr˜es c c˜ o estruturais de objeto descrevem caminhos para compor objetos para se chegar a novas funcionalidades. A flexibilidade de composi¸ao de objetos ´ poss´ devido ` habilidade c˜ e ıvel a
  • 30. 29 de se mudar a composi¸ao em tempo de execu¸ao, o que ´ imposs´ em uma composi¸˜o c˜ c˜ e ıvel ca de classes est´ticas. a 3.2.1 Adapter Adapter, ´ um padr˜o de projeto que tem como principal objetivo converter a interface e a de uma classe em uma outra interface esperada por clientes. O Adapter permite que classes que n˜o poderiam trabalhar em conjunto, devido a incompatibilidade de suas a ` interfaces, se comuniquem entre si. (GAMMA et al., 1995) Uma classe adaptadora possibilita a sobrescrita de m´todos da classe a ser adaptada, e devido a uma adaptadora extendˆ-la. Ela tamb´m inicia somente um objeto, e nenhum e e apontador adicional ´ necess´rio para se obter a classe adaptada. (GAMMA et al., 1995) e a Um objeto adaptador permite a um unico Adapter a possibilidade de se trabalhar ´ com v´rias classes adaptadas, ou seja, a pr´pria classe que deve ser adaptada e todas a a o suas subclasses (se elas existirem). O Adapter tamb´m pode adicionar funcionalidades e para todas as classes adaptadas de uma vez. (GAMMA et al., 1995) 3.2.2 Bridge O int´ito do Bridge, segundo Gamma et al. (1995), ´ desacoplar uma abstra¸˜o de u e ca sua implementa¸ao para que as duas possam variar independentemente. c˜ Entre seus principais benef´ ıcios, o Bridge traz uma melhoria significante de extensibil- idade. Pode-se extender a hierarquia de Abstra¸ao e Implementa¸˜o independentemente. c˜ ca Ele tamb´m garante que uma implementa¸ao n˜o esteja ligada permanentemente a uma e c˜ a interface. A implementa¸ao de uma abstra¸ao pode ser configurada em tempo de exe- c˜ c˜ cu¸˜o. (GAMMA et al., 1995) ca 3.2.3 Composite O padr˜o Composite tem como objetivo, baseando-se em Gamma et al. (1995), compor a objetos em estruturas de arvore para representar hierarquias parcialmente completas. ´ O Composite permite que clientes tratem objetos individuais e composi¸oes de objetos c˜ uniformemente. Uma das consequˆncias de se utilizar o padr˜o Composite, segundo Gamma et al. e a (1995), ´ a hierarquia de classes que ele fornece, sendo esta hierarquia composta de objetos e
  • 31. 30 primitivos e objetos compostos. Os objetos primitivos podem ser utilizados para compor objetos mais complexos, que tamb´m podem formar outras composi¸oes, e assim por e c˜ diante. Onde quer que o c´digo cliente espere um objeto primitivo, ele tamb´m pode o e pegar um objeto composto. 3.2.4 Decorator Segundo Gamma et al. (1995), o principal objetivo do padr˜o Decorator ´ incorporar a e responsabilidades adicionais a um objeto dinamicamente. Objetos “decoradores” fornecem uma alternativa flex´ a utiliza¸˜o de heran¸as, para se extender funcionalidades. ıvel ` ca c O padr˜o Decorator fornece uma maneira mais flex´ a ıvel para se adicionar respons- abilidades a objetos do que a que se pode ter com heran¸a est´tica (m´ltipla). Com c a u decoradores, responsabilidades podem ser adicionadas e removidas em tempo de execu¸˜o ca simplesmente incorporando e desincorporando-as. Em contraste, para se realizar a her- an¸a ´ necess´ria a cria¸˜o de uma nova classe para cada responsabilidade adicional. Isso c e a ca traz o crescimento de classes e aumenta a complexidade de um sistema. (GAMMA et al., 1995) 3.2.5 Facade O padr˜o de projeto Facade fornece uma interface unica para um conjunto de inter- a ´ faces de um subsistema. Uma Facade define uma interface de mais alto n´ que torne o ıvel subsistema mais f´cil de ser utilizado. (GAMMA et al., 1995) a Um dos benef´ ıcios que o padr˜o Facade fornece ´ a prote¸˜o dos componentes de um a e ca subsistema, abstraindo-o dos c´digos clientes, dessa forma ele reduz o n´mero de objetos o u que clientes precisam lidar e torna o subsistema mais f´cil de se utilizar. Outro benef´ a ıcio ´ que ele diminui o acoplamento entre o subsistema e seus clientes. Constantemente os e componentes em um subsistema s˜o fortemente acoplados. (GAMMA et al., 1995) a 3.2.6 Flyweight Este padr˜o utiliza-se de compartilhamento para suportar de maneira eficiente um a grande n´mero de objetos de granularidade fina. (GAMMA et al., 1995) u Flyweights podem trazer custos em tempo de execu¸ao associados a transferˆncia, c˜ e busca, e outros estados extr´ ınsecos de computa¸˜o, especialmente se ele antigamente ca
  • 32. 31 foi guardado como um estado intr´ ınseco. No entanto, estes custos s˜o compensados a com economias no espa¸o, que aumentam quanto mais Flyweights s˜o compartilhados. c a (GAMMA et al., 1995) 3.2.7 Proxy O intu´ do padr˜o Proxy, segundo Gamma et al. (1995), ´ prover um substituto ou ıto a e marcador de localiza¸ao de outro objeto para control´-lo e acess´-lo. c˜ a a O padr˜o Proxy provˆ uma camada indireta para quando for feito o acesso a um a e objeto. Ele tamb´m possui outra otimiza¸ao para esconder do cliente, ela ´ chamada e c˜ e de “copie-na-escrita” e ´ relacionada a cria¸ao de acordo com a demanda. Copiar um e c˜ objeto grande e complicado pode ser uma opera¸ao ´rdua. Se a c´pia nunca ´ modificada, c˜ a o e ent˜o n˜o existe necessidade deste custo ocorrer. Ao se utilizar um proxy para retardar o a a processo de c´pia, garante-se que se pague o pre¸o da c´pia deste objeto somente quando o c o ele for modificado. (GAMMA et al., 1995) 3.3 Padr˜es Comportamentais o Padr˜es comportamentais est˜o preocupados com algoritmos e com a atribui¸˜o de re- o a ca sponsabilidades entre objetos. Padr˜es comportamentais descrevem n˜o somente padr˜es o a o de objetos ou classes mas tamb´m os padr˜es de comunica¸˜o entre eles. Estes padr˜es e o ca o caracterizam controle complexo de fluxo que ´ dificil de se acompanhar em tempo de ex- e ecu¸˜o. Eles tiram o foco do controle de fluxo para que possa-se concentrar somente na ca maneira como objetos s˜o interconectados. (GAMMA et al., 1995) a 3.3.1 Chain of Responsibility O padr˜o Chain of Responsibility tem como objetivo evitar o acoplamento do reme- a tente de uma requisi¸˜o com seu destinat´rio ao dar chances de se tratar a requisi¸ao a ca a c˜ mais de um objeto. Ele cria uma corrente com os objetos recebedores e passa a requisi¸ao c˜ para a corrente at´ que um objeto manipule-a. (GAMMA et al., 1995) e Com o Chain of Responsibility pode-se reduzir o acoplamento. Este padr˜o libera um a objeto de conhecer quais outros objetos manipulam uma requisi¸˜o. Um objeto apenas ca deve saber que uma requisi¸˜o ser´ manipulada adequadamente. O padr˜o tamb´m adi- ca a a e ciona mais flexibilidade por atribuir responsabilidades entre os objetos. Pode-se adicionar
  • 33. 32 ou modificar responsabilidades para a manipula¸ao de uma requisi¸ao por adicionar ou c˜ c˜ modificar a corrente em tempo de execu¸ao. (GAMMA et al., 1995) c˜ 3.3.2 Command O principal int´ito do Command ´ encapsular uma requisi¸˜o como um objeto, dessa u e ca forma deixando que os clientes parametrizem diferentes requisi¸oes, filas de espera ou c˜ requisi¸oes de log, tamb´m dando suporte a opera¸oes que podem ser desfeitas. (GAMMA c˜ e c˜ et al., 1995) O padr˜o Command possui as seguintes consequˆncias: a e • Ele desacopla o objeto que invoca a opera¸ao do objeto que sabe como execut´-la; c˜ a • Commands s˜o objetos de primeira classe. Eles podem ser manipulados e extendidos a assim como qualquer outro objeto; • Adicionar novos Commands ´ uma tarefa f´cil, porque n˜o ´ necess´ria a modifica¸˜o e a a e a ca de classes j´ existentes. (GAMMA et al., 1995) a 3.3.3 Interpreter Dada uma linguagem, o padr˜o Interpreter define uma representa¸ao para a sua a c˜ gram´tica juntamente com um interpretador que utiliza a representa¸˜o para interpre- a ca tar senten¸as na linguagem. (GAMMA et al., 1995) c Entre os principais benef´ ıcios do padr˜o Interpreter, segundo Gamma et al. (1995), a pode-se destacar a facilididade de se modificar e extender a gram´tica de uma linguagem, a devido ao padr˜o utilizar classes para representar regras de gram´tica, pode-se utilizar a a heran¸a para modificar ou extender a gram´tica. Express˜es existentes podem ser mod- c a o ificadas incrementalmente, e novas express˜es podem ser definidas como varia¸oes de o c˜ express˜es antigas. o 3.3.4 Iterator Segundo Gamma et al. (1995), este padr˜o provˆ uma forma de acessar elementos de a e um objeto agregado sequencialmente sem expor a representa¸˜o interna deste objeto. ca
  • 34. 33 O padr˜o Iterator simplifica uma interface agregada. Sua interface travessa evidencia a a necessidade de uma interface similar na agrega¸˜o, desta forma simplificando a interface ca agregada. (GAMMA et al., 1995) 3.3.5 Mediator O objetivo do padr˜o Mediator, segundo Gamma et al. (1995), ´ definir um objeto a e que encapsula a forma como um conjunto de objetos interage. O Mediator promove um fraco acoplamento por evitar que objetos refiram-se uns aos outros explicitamente, e ele permite que a intera¸ao destes objetos possa variar de maneira independente. c˜ Este padr˜o limita a cria¸ao de subclasses, pois ele localiza comportamentos que de a c˜ outra forma seriam distribu´ ıdos atrav´s de diversos objetos. A modifica¸ao deste compor- e c˜ tamento requere que as subclasses extendam o Mediator. O Mediator tamb´m simplifica e protocolos de objeto, ele sobrescreve intera¸oes muitos-para-muitos com intera¸˜es um- c˜ co para-muitos entre o mediador e seus “colegas”. (GAMMA et al., 1995) 3.3.6 Memento Sem violar o encapsulmento, captura e externaliza o estado interno de um objeto para que, futuramente, o objeto possa ser restaurado para este estado. (GAMMA et al., 1995) O Memento evita a exposi¸ao de informa¸oes que somente um “originador” deve geren- c˜ c˜ ciar mas que no entanto devem ser armazenadas fora do originador. O padr˜o protege a outros objetos da complexidade interna do Originator, preservando desta forma os limites da encapsula¸˜o. (GAMMA et al., 1995) ca 3.3.7 Observer O padr˜o Observer define uma dependˆncia um-para-muitos entre objetos para que a e quando o estado de um objeto seja modificado, todos os seus dependentes sejam notificados e atualizados automaticamente. (GAMMA et al., 1995) Com este padr˜o ´ poss´ a e ıvel modificar de forma independentente assuntos e obser- vadores. Pode-se reutilizar assuntos sem reutilizar seus observadores e vice-versa. Ele permite que se adicione observadores sem modificar o assunto ou outros observadores. (GAMMA et al., 1995)
  • 35. 34 Outro benef´ de sua utiliza¸˜o ´ o acoplamento abstrato entre Subject e Observer, ıcio ca e ou seja, tudo que um assunto sabe ´ que ele possui uma lista de observadores, cada um e estando nos conformes da interface simples da classe abstrata Observer. O assunto n˜o a sabe a classe concreta de nenhum dos observadores. Assim o acoplamento entre assuntos e observadores ´ abstrato e m´ e ınimo. (GAMMA et al., 1995) 3.3.8 State O padr˜o de projeto State, segundo Gamma et al. (1995), permite que um objeto a altere seu comportamento quando seu estado interno for modificado. O objeto aparecer´ a para modificar sua classe. O padr˜o State coloca em um objeto todos os comportamentos associados com um a estado particular. Devido a todo o c´digo espec´ o ıfico de estado estar em uma subclasse de um State, novos estados e transi¸˜es podem ser adicionados facilmente atrav´s da defini¸ao co e c˜ de novas subclasses. (GAMMA et al., 1995) Ele tamb´m faz com que transi¸˜es de estado sejam expl´ e co ıcitas. Quando um objeto define seu estado atual a partir de valores de dados internos, suas transi¸oes de estados c˜ n˜o possuem representa¸oes expl´ a c˜ ıcitas; elas apenas aparecem como defini¸˜es a algumas co vari´veis. As transi¸˜es se tornam mais expl´ a co ıcitas ao se introduzir objetos separados para diferentes estados. (GAMMA et al., 1995) 3.3.9 Strategy Baseando-se em Gamma et al. (1995), o Strategy define uma fam´ de algoritmos, ılia encapsula cada um, e faz com que eles sejam intercambi´veis. Ele permite que o algoritmo a seja alterado independentemente pelos clientes que o utilizam. O Strategy define fam´ ılias de algoritmos relacionados. Hierarquias de classes Strat- egy definem uma fam´ de algoritmos ou comportamentos de diferentes contextos para ılia reutiliz´-la. A Heran¸a pode ajudar a se retirar funcionalidades comuns dos algoritmos. a c (GAMMA et al., 1995) Segundo Gamma et al. (1995), ele tamb´m fornece uma maneira alternativa a sub- e ` classes. A heran¸a fornece outra maneira de suportar uma variedade de algoritmos ou c comportamentos. Por´m ela pode misturar a implementa¸ao do algoritmo de uma classe, e c˜ tornando-a mais dif´ de se entender, manter, e extender. Tamb´m n˜o se pode modificar ıcil e a
  • 36. 35 o algoritmo dinamicamente. Ao se encapsular o algoritmo em classes Strategy separadas, pode-se alterar o algoritmo independentemente de seu contexto, tornando-o f´cil de se a modificar, entender e extender. 3.3.10 Template Method O Template Method define o esqueleto de um algoritmo em uma opera¸ao, permitindo c˜ que subclasses possam, posteriormente, prover funcionalidades espec´ ıficas. Ele permite que subclasses redefinam certas etapas de um algoritmo sem modificar a estrutura dele. (GAMMA et al., 1995) Template Method ´ uma t´cnica fundamental para a reutiliza¸˜o de c´digo. Eles e e ca o s˜o particularmente importantes em bibliotecas de classes, porque eles s˜o o meio de se a a fatorar comportamentos comuns em uma biblioteca de classes. Este padr˜o faz com que a se tenha um controle de estrutura inverso, ou seja, a maneira como uma classe pai chama a opera¸ao de uma subclasse e n˜o o contr´rio. (GAMMA et al., 1995) c˜ a a ´ E importante para Template Methods especificar quais opera¸˜es podem ser sobre- co scritas e quais opera¸oes devem ser sobrescritas. Para se reutilizar efetivamente uma c˜ classe abstrata, escritores de subclasses devem entender quais opera¸˜es s˜o projetadas co a para a reescrita. (GAMMA et al., 1995) 3.3.11 Visitor O padr˜o de projeto Visitor, baseando-se em Gamma et al. (1995), representa uma a opera¸˜o a ser executada sobre os elementos de uma estrutura de objetos. O Visitor ca permite a defini¸ao de uma nova opera¸˜o sem modificar as classes dos elementos sobre c˜ ca os quais opera. Com este padr˜o, facilita-se a adi¸˜o de opera¸oes que dependam dos componentes a ca c˜ de objetos complexos. Pode-se definir uma nova opera¸˜o sobre a estrutura de um objeto ca simplismente adicionando um novo Visitor. Em contraste, se a funcionalidade ´ espalhada e em diversas classes, ent˜o deve-se modificar cada classe para definir uma nova opera¸˜o. a ca (GAMMA et al., 1995) Comportamento relacionado n˜o ´ espalhado sobre as classes que definem a estrutura a e do objeto; ele ´ localizado em um Visitor. Conjuntos de comportamentos n˜o-relacionados e a s˜o particionados nas subclasses de seus pr´prios Visitors. (GAMMA et al., 1995) a o
  • 37. 36 3.4 Design Patterns Arquiteturais Al´m dos design patterns criados pela GOF, surgiram outros patterns com o objetivo e de melhorar a estrutura organizacional utilizada no desenvolvimento de software. Segundo Fowler et al. (2002), sistemas com uma alta complexidade s˜o comumente divididos em a camadas l´gicas, onde os principais subsistemas do software poder˜o estar em camadas o a distintas, onde cada camada superior se comunicar´ com a inferior. Estas camadas pos- a suem fun¸˜es variadas e, gra¸as ao conceito por tr´s dos design patterns, as camadas co c a comumente utilizadas pelos desenvolvedores puderam ser catalogadas para se tornarem design patterns reutiliz´veis. a 3.4.1 Model-View-Controller O MVC foi planejado pela primeira vez em meados da d´cada de 70 por Trygve e Reenskaug, destinado ` linguagem de programa¸˜o Smalltalk. Desde ent˜o, este pattern a ca a evoluiu e diversas outras implementa¸oes surgiram. Apesar de se ter muito debate sobre c˜ o MVC e suas evolu¸oes, seu principal objetivo continua sendo o de separar o c´digo da c˜ o interface com o usu´rio em trˆs areas separadas. Estas trˆs ´reas que o MVC define s˜o: a e ´ e a a Model, View e Controller, ilustradas na Figura 3.2. (POPE, 2009) Figura 3.2: MVC Cl´ssico a Melo e Nascimento (2007, p. 231) Adaptada. O Model ´ a camada que cont´m a l´gica da aplica¸ao e a parte de manipula¸˜o e e o c˜ ca dos dados. Esta camada n˜o tem a responsabilidade de processar, por exemplo, requi- a si¸˜es HTTP ou lidar com vari´veis passadas por requisi¸˜es deste tipo. (MELO; NASCI- co a co
  • 38. 37 MENTO, 2007) A View tem a responsabilidade de gerenciar os aspectos de visualiza¸ao. Ela refletir´ c˜ a os dados de uma classe Model e ir´ format´-los em uma p´gina web, em uma tela de a a a um sistema desktop, em Extensible Markup Language (XML) ou qualquer outro tipo de apresenta¸˜o de dados. (MELO; NASCIMENTO, 2007) ca E o Controller ir´ fazer o controle da aplica¸˜o, onde ele ir´ manipular o fluxo entre a ca a um recurso e outro. Al´m disso, ele tamb´m ser´ o intermediador entre a View e o Model, e e a j´ que ambos n˜o podem se comunicar diretamente. (MELO; NASCIMENTO, 2007) a a Os principais benef´ ıcios de se separar a aplica¸ao desta forma s˜o: simplicidade na c˜ a adi¸ao, edi¸ao e exclus˜o de interfaces com o usu´rio; possuir m´ltiplas Views para apre- c˜ c˜ a a u sentar o mesmo dado; facilidade na modifica¸ao do controle l´gico e ajudar o desenvolvedor c˜ o a evitar repeti¸ao de c´digo. (POPE, 2009) c˜ o 3.4.2 Data Mapper O principal conceito do Data Mapper ´ o de prover uma camada de mapeadores que e movem dados entre objetos e um banco de dados, enquanto mant´m eles independentes e entre si e, tamb´m, do pr´prio mapeador. A Figura 3.3 demonstra por meio de diagramas e o este conceito. (FOWLER et al., 2002) Figura 3.3: Data Mapper Fowler et al. (2002, p. 165) Adaptada. Objetos e bancos de dados relacionais possuem mecanismos diferentes de se estruturar dados. Muitas partes de um objeto, como cole¸˜es e heran¸a, n˜o est˜o presentes em co c a a bancos de dados relacionais. Quando se constr´i um modelo de objeto com muita l´gica o o de neg´cio, ´ de grande valia utilizar estes mecanismos para organizar melhor os dados e o e o comportamento que vai com ele. Fazer isso resulta em esquemas variantes, ou seja, o esquema de objeto e o esquema relacional n˜o correspondem. (FOWLER et al., 2002) a O Data Mapper ´ uma camada de software que separa objetos em mem´ria e um e o
  • 39. 38 banco de dados. Sua responsabilidade ´ transferir dados entre estes dois e tamb´m isol´- e e a los de cada um. Com o Data Mapper os objetos em mem´ria: n˜o precisar˜o saber que o a a existe um banco de dados presente; n˜o precisar˜o de c´digo SQL; e, certamente, n˜o a a o a ter˜o conhecimento do esquema do banco de dados. E, al´m disso, o Data Mapper em si a e ´ desconhecido para a camada de dom´ e ınio. (FOWLER et al., 2002) 3.4.3 Table Data Gateway O principal objetivo de um Table Data Gateway ´ o de servir como um ponto de e entrada para uma tabela do banco de dados. Uma instˆncia de um Table Data Gateway a ir´ manusear todos os registros de uma tabela. (FOWLER et al., 2002) a Misturar instru¸oes SQL a l´gica de uma aplica¸˜o pode causar diversos problemas. c˜ ` o ca Muitos desenvolvedores podem n˜o dominar SQL, e outros que a dominam podem n˜o a a escrevˆ-la corretamente. Administradores de banco de dados precisam ser capazes de en- e contrar facilmente a parte que lida com SQL da aplica¸˜o, para que eles possam melhorar ca e escrever novos c´digos para a comunica¸ao com o banco de dados. (FOWLER et al., o c˜ 2002) Um Table Data Gateway possui todo SQL utilizado para se efetuar as opera¸˜es de co um banco de dados de uma tabela, como, por exemplo: sele¸˜es de dados, inser¸oes, co c˜ atualiza¸oes e exclus˜es. Este conceito ´ ilustrado na Figura 3.4. Al´m destas opera¸oes, c˜ o e e c˜ este tipo de objeto agrega todas as demais opera¸˜es que interagem com o banco de dados. co (FOWLER et al., 2002) Figura 3.4: Table Data Gateway Fowler et al. (2002, p. 144) Adaptada.
  • 40. 39 4 PHP PHP ´ um acrˆnimo recursivo para Hypertext Preprocessor (Pr´-processador de Hiper- e o e ´ texto). E uma linguagem de script de c´digo aberto, que tem como objetivo prim´rio a o a gera¸˜o de c´digo dinˆmico para p´ginas da internet. Isto significa que ´ poss´ escrever ca o a a e ıvel Hypertext Markup Language (HTML) com c´digo PHP embutido para gerar conte´do o u dinˆmico. O c´digo-fonte de scripts PHP n˜o pode ser visto pelo internauta, ele apenas a o a ter´ acesso ao HTML resultante dos scripts. (MELO; NASCIMENTO, 2007) a 4.1 Hist´rico o O PHP foi criado no outono de 1994 por Rasmus Lerdorf. Inicialmente a linguagem era formada por um conjunto de scripts voltados ` cria¸˜o de p´ginas dinˆmicas que a ca a a Rasmus utilizava para monitorar o acesso ao seu curr´ ıculo na internet. Ap´s o crescimento o das funcionalidades da linguagem, Rasmus escreveu uma implementa¸ao em C, a qual c˜ permitia as pessoas desenvolverem de forma muito mais simples suas aplica¸oes web. Em ` c˜ 1995 Rasmus nomeou essa vers˜o de Personal Home Pages/Forms Interpreter (PHP/FI) a e disponibilizou seu c´digo na web, para compartilhar com outras pessoas, bem como o receber ajuda e corre¸oes de bugs. (DALL’OGLIO, 2007) c˜ Em 1997 a segunda vers˜o do PHP/FI (PHP/FI 2.0) obteve apoio e reconhecimento de a milhares de usu´rios ao redor do mundo. Aproximadamente 50.000 dom´ a ınios reportavam sua instala¸ao e uso, construindo assim uma base de 1% dos dom´ c˜ ınios da internet. Esta vers˜o ganhou contribui¸oes de c´digo de milhares de pessoas e foi rapidamente substitu´ a c˜ o ıda pelas releases alfas do PHP 3.0. (MELO; NASCIMENTO, 2007) Andi Gutmans e Zeev Suraski descobriram que o PHP/FI 2.0 era uma linguagem vers´til e que poderia ser utilizada para seus projetos acadˆmicos de com´rcio eletrˆnico. a e e o Em um esfor¸o conjunto a partir da base de usu´rios PHP/FI existentes, Andi, Rasmus c a e Zeev decidiram se unir e anunciaram em Junho de 1998 o PHP 3.0 como uma vers˜o a
  • 41. 40 oficial e sucessora do PHP/FI 2.0, que foi descontinuado pelos desenvolvedores. Nesta vers˜o PHP passou a ser um acrˆnimo para Hypertext Preprocessor. Entre os principais a o recursos desta vers˜o destacam-se: suporte a diversos bancos de dados, protocolos e APIs, a suporte a Orienta¸ao Objetos (bastante limitado) e uma grande extensibilidade. Nesta ` c˜ vers˜o o PHP estava presente em aproximadamente 10% dos servidores web da internet. a (MELO; NASCIMENTO, 2007) No inverno de 1998, ap´s o lan¸amento do PHP 3, Zeev e Andi come¸aram e tra- o c c balhar em uma reescrita do n´cleo do PHP, tendo em vista melhorar sua performance u e modularidade em aplica¸oes complexas. Para tanto, batirazam este n´cleo de Zend c˜ u Engine (Mecanismo Zend), onde Zend era uma mistura entre os nomes Zeev + Andi. O PHP 4, baseado neste mecanismo, foi lan¸ado oficialmente em Maio de 2000, trazendo c muitas melhorias e recursos novos, como se¸˜es, suporte a diversos servidores web, al´m co e da abstra¸ao de sua API, permitindo inclusive ser utilizado como linguagem para shell c˜ script. Nesse momento, o PHP j´ aparecia em cerca de 20% dos dom´ a ınios da internet. (DALL’OGLIO, 2007) A vers˜o 5 do PHP foi marcada pela quebra de paradigmas da linguagem, pois ela a ganhou suporte a Orienta¸ao a Objetos de forma muito mais consistente. Esta vers˜o c˜ a ´ baseada na Zend Engine 2, e foi lan¸ada oficialmente em Junho de 2004. Ela trouxe e c como novidades o suporte melhorado da manipula¸ao de arquivos XML, manipula¸ao c˜ c˜ de webservices Simple Object Access Protocol (SOAP) e Representational State Transfer (REST), suporte melhorado ao MySQL via extens˜o MySQLi, novas bibliotecas SQLite, a Tidy, aperfei¸oamento da integra¸˜o com a linguagem Perl, melhorias no gerenciamento de c ca mem´ria e fim do suporte ao sistema operacional Windows 95. (MELO; NASCIMENTO, o 2007) 4.2 Frameworks Segundo Melo e Nascimento (2007) um framework ´ um tipo especial de aplicativo, e que oferece um conjunto b´sico de ferramentas e subsistemas que automatizam grande a parte dos servi¸os que se necessita implementar em sistemas para usu´rios finais. Alguns c a exemplos pr´ticos s˜o: cadastro de clientes, site de not´ a a ıcias, gest˜o de estoque e etc. a A utiliza¸ao de um framework ´ baseada na id´ia de que, independente do sistema c˜ e e final do usu´rio, sempre existir´ uma s´rie de componentes padr˜es, como: controle de a a e o usu´rios, sess˜es de p´ginas, logging de a¸oes efetuadas, template engines, mecanismos de a o a c˜
  • 42. 41 acesso ao banco de dados e etc. Ao inv´s de se criar as aplica¸˜es do zero, reinventado e co a roda todas as vezes, pode-se optar pela ado¸ao de um framework, de modo que este c˜ ofere¸a uma infra-estrutura completa para sustenta¸ao de um sistema. A partir desta c c˜ premissa, pode-se dedicar o tempo de trabalho apenas no desenvolvimento do n´cleo da u aplica¸˜o, como, por exemplo, as regras de neg´cio. (MELO; NASCIMENTO, 2007) ca o Com certeza desta forma tem-se uma enorme economia de tempo e trabalho para o desenvolvimento. Esta ´, ali´s, a filosofia Don’t Repeat Yourself (DRY), que prega e a que elementos estruturais n˜o devem ser reescritos a cada nova aplica¸˜o. Al´m disso, a a ca e ado¸˜o de um framework faz com que o programador adote um estilo mais leg´ e claro ca ıvel para manter seu c´digo, uma vez que ele deve ser compat´ com o modelo do framework o ıvel escolhido. (MELO; NASCIMENTO, 2007) Diversas linguagens de programa¸˜o contam com uma s´rie de frameworks, constru´ ca e ı- dos e disponibilizados gratuitamente na internet. O mesmo ocorre com o PHP, onde entre os tipos de frameworks mais utilizados encontram-se: persistˆncia de dados, tem- e plate engines, frameworks MVC e de integra¸˜o com Asynchronous Javascript And XML ca (AJAX). 4.2.1 Zend Framework O Zend Framework ´ um framework de c´digo aberto para desenvolvimento de apli- e o ca¸oes e servi¸os web com PHP5. Ele foi implementado utilizando c´digo 100% orientado c˜ c o a objetos. A estrutura de componentes do Zend Framework ´ de certo modo unica; cada e ´ componente ´ projetado com poucas dependˆncias de outros componentes. Esta arquite- e e tura fracamente acoplada permite aos desenvolvedores utilizar componentes de maneira individual. A companhia Zend ´ a principal patrocinadora deste framework, por´m diver- e e sas outras companhias contribuem com componentes ou recursos significantes, como, por exemplo, Google, Microsoft e etc. (ZEND, 2009) A arquitetura do Zend Framework possui componentes que abrangem 80% das fun- cionalidades necess´rias a projetos de software e ela possui como principal filosofia a pos- a sibilidade de se criar componentes que sejam f´ceis de utilizar para que se possa chegar a aos 20% restantes das funcionalidades de um software, geralmente estes sendo os requi- sitos de neg´cio de um determinado projeto em quest˜o. Tendo em foco as necessidades o a mais comuns destes projetos e mantendo o esp´ ırito da programa¸ao PHP, este framework c˜ possui uma baixa curva de apredinzagem, o que tamb´m reduz os custos de treinamentos. e (ZEND, 2009)
  • 43. 42 De acordo com a Zend (2009), os principais recursos para desenvolvimento web forneci- dos pelo framework s˜o: a • Suporte a AJAX atrav´s de JavaScript Object Notation (JSON); e • Vers˜o nativa para PHP do mecanismo de busca Lucene; a • Suportar os formatos de dados de sindica¸oes como, por exemplo Really Simple c˜ Sindication (RSS), e manipul´-los; a • Webservices, consumir e distribuir servi¸os web; c • Biblioteca de classes de alta qualidade escritas em PHP 5, visando as melhores pr´ticas como design patterns, testes unit´rios e etc. a a Entre os diversos componentes que o Zend Framework possui, existem os que aplicam o MVC, visando a independˆncia de trabalho entre os web designers e os programadores; e os componentes para bancos de dados, que utilizam abstra¸˜o de Structured Query Lan- ca guage (SQL) e escondem detalhes diversos sobre os Sistemas Gerenciadores de Bancos de Dados (SGBDs); componentes de internacionaliza¸˜o e localiza¸˜o, que prometem fa- ca ca cilitar o suporte a m´ltiplos-idiomas de uma aplica¸ao; e diversos outros componentes u c˜ como Autentica¸ao, Web Services, Email, Buscas e tamb´m os componentes do n´cleo do c˜ e u framework. (ZEND, 2009) 4.2.2 CakePHP O CakePHP ´ um framework gratuito e de c´digo-aberto para desenvolvimento ´gil e o a de aplica¸oes em PHP. Ele fornece toda a estrutura funcional para que programadores c˜ possam criar aplica¸˜es web. O principal objetivo do CakePHP ´ fornecer uma maneira co e de se trabalhar padronizadamente e com agilidade no desenvolvimento - sem perca de flexibilidade. Com esta premissa, os desenvolvedores podem se focar somente na l´gica o espec´ ıfica das aplica¸˜es. (CAKESOFTWAREFOUNDATION, 2009) co Alguns dos principais recursos, segundo CakeSoftwareFoundation (2009), s˜o: a • Compatibilidade com as vers˜es 4 e 5 do PHP; o • Arquitetura MVC;
  • 44. 43 • Scaffolding (opera¸oes b´sicas de qualquer aplica¸ao em tempo de execu¸ao) de c˜ a c˜ c˜ Aplica¸oes; c˜ • Gerador de C´digo; o • Endere¸os web amig´veis; c a • Valida¸˜o nativa. ca O CakePHP possui uma arquitetura j´ definida para se trabalhar o que obriga o de- a senvolvedor a seguir conven¸oes de programa¸ao. Entre estas conven¸˜es est˜o a nomen- c˜ c˜ co a clatura e estrutura de pastas dos Controllers, Models e Views para que suas requisi¸˜es co possam funcionar da maneira correta. Figura 4.1: Requisi¸˜o CakePHP. ca (CAKESOFTWAREFOUNDATION, 2009) Uma requisi¸˜o com o CakePHP ´ ilustrada na Figura 4.1, onde o usu´rio faz uma ca e a requisi¸ao, o dispatcher passa essa requisi¸ao para as rotas, as rotas lˆem a Uniform c˜ c˜ e Resource Locator (URL) e extraem os parˆmetros dela (controller, a¸˜o e argumentos a ca utilizados em uma a¸ao), o Controller pode utilizar o Model para acessar dados do banco c˜ de dados, o Controller pode utilizar componentes para refinar os dados ou realizar outras opera¸˜es, o Controller passa a reposta para a View adequada que ´ apresentada no co e navegador do usu´rio. (CAKESOFTWAREFOUNDATION, 2009) a
  • 45. 44 4.2.3 Prado A inspira¸ao original do Prado veio da Apache Tapestry. Durante o projeto e a c˜ constru¸ao do framework, foram copiadas diversas id´ias do Borland Delphi e do Microsoft c˜ e ASP.NET. A primeira vers˜o do Prado foi lan¸ada em Junho de 2004, escrita em PHP 4. a c Para concorrer no concurso de codifica¸˜o PHP 5 da Zend, o Prado foi reescrito utilizando ca os recursos avan¸ados de orienta¸ao a objetos desta nova vers˜o da linguagem, onde a c c˜ a vers˜o reescrita do framework venceu o concurso. O Prado foi hospedado na SourceForge a como um projeto de c´digo aberto em Agosto de 2004. Ap´s um grande suporte do time o o de desenvolvimento e dos usu´rios do Prado, em 2005 foi lan¸ada a vers˜o 2.0 do projeto. a c a Em Maio de 2005 os desenvolvedores decidiram reescrever completamente o framework, para incluir algumas funcionalidades interessantes do Microsoft ASP.NET 2.0 e para a corre¸ao de bugs, resultando na vers˜o 3.0 lan¸ada em Abril de 2006. (XUE; ZHUO, 2009) c˜ a c A arquitetura do Prado ´ baseada em componentes e eventos e um de seus principais e objetivos ´ habilitar ao m´ximo a reusabilidade no desenvolvimento web. N˜o somente e a a reutilizar os c´digos pr´prios do desenvolvedor e sim c´digos de diversas pessoas. O o o o conceito de componentes ´ utilizado para este prop´sito. O Prado utiliza-se do paradigma e o de programa¸ao orientada a eventos para facilitar a intera¸˜o com os componentes. (XUE; c˜ ca ZHUO, 2009) Segundo Xue e Zhuo (2009) alguns dos principais recursos do Prado s˜o: a • Reusabilidade; • Programa¸˜o orientada a eventos; ca • Integra¸˜o da equipe de programadores; ca • Controles Web Poderosos; • Suporte a AJAX. 4.2.4 Code Igniter O Code Igniter ´ um conjunto de ferramentas para desenvolvimento de aplica¸˜es e co web utilizando PHP. Seu objetivo ´ permitir um aumento na agilidade de desenvolvi- e mento de projetos, fornecendo uma biblioteca de componentes para as tarefas comumente
  • 46. 45 necess´rias, e uma estrutura l´gica para acessar estes componentes. Com ele o desenvolve- a o dor pode focar no neg´cio exigido pelo projeto, pois o framework minimiza a quantidade o de c´digo exigida para uma determinada tarefa. (CODEIGNITER, 2009) o As licen¸as do Code Igniter s˜o de c´digo aberto e bastante flex´ c a o ıveis, pois ele ´ dis- e tribu´ sob licen¸as Apache/BSD, o que permite utiliz´-lo para qualquer fim. Ele ´ ıdo c a e compat´ com o PHP4 e 5, apesar de n˜o tirar proveito de todos os recursos avan¸ados ıvel a c de orienta¸˜o a objetos desta ultima vers˜o. Ele ´ um framework muito leve e seu n´cleo ca ´ a e u n˜o exige muitas bibliotecas. (CODEIGNITER, 2009) a Entre os principais recursos do Code Igniter, destacam-se: arquitetura baseada no pattern MVC, gera¸ao de endere¸os web amig´veis, classes de abstra¸ao com o banco de c˜ c a c˜ dados, valida¸˜o de dados e formul´rios, alta extensibilidade, seguran¸a e filtragem de ca a c Cross-site Scripting (XSS), entre outras. (CODEIGNITER, 2009) Figura 4.2: Requisi¸˜o do Code Igniter ca CODEIGNITER (2009). A Figura 4.2 ilustra o fluxo de uma requisi¸ao com o Code Igniter. c˜ Segundo CODEIGNITER (2009) o framework processa as requisi¸oes da seguinte forma: c˜ • O Front Controller (index.php) inicia os recursos necess´rios para executar o frame- a work ; • A requisi¸ao HTTP ´ analisada pelo Router para determinar o que dever´ ser feito; c˜ e a • Se existe um arquivo em cache, ele ´ apresentado diretamente ao browser, evitando e o resto de processamento da requisi¸ao; c˜ • Antes do Controller ser executado, a requisi¸ao HTTP e qualquer dado submetido c˜ pelo usu´rio ´ filtrado por quest˜es de seguran¸a; a e o c • O Controller carrega o Model, bibliotecas do n´cleo do framework, plugins, helpers, u e demais recursos necess´rios da requisi¸ao; a c˜
  • 47. 46 • A View resultante ´ renderizada e enviada ao browser para poder ser visualizada. e Se o recurso de caching est´ habilitado ela ´ armazenada para que em requisi¸˜es a e co posteriores o framework possa parar o fluxo na terceira etapa deste processamento.
  • 48. 47 5 Ambiente Experimental O objetivo deste cap´ ıtulo ´ descrever sucintamente o ambiente em que foram feitos os e testes, os experimentos, as implementa¸˜es e demais etapas envolvidas no desenvolvimento co da arquitetura e da aplica¸ao de gest˜o de bibliotecas. O ambiente experimental descrito c˜ a vai desde ferramentas para cria¸˜o da documenta¸˜o da aplica¸˜o at´ o ambiente de ca ca ca e servidor onde ´ armazenado o banco de dados e demais tecnologias necess´rias para o e a correto funcionamento da aplica¸˜o. ca 5.1 Tecnologias Envolvidas 5.1.1 UML A UML ´ um modelo descritivo de objetos largamente utilizado na Engenharia de e Software. Ela ´ uma linguagem visual e constitui-se de v´rios elementos gr´ficos que e a a permitem construir diagramas para representar as v´rias vis˜es de um sistema. (MELO; a o NASCIMENTO, 2007) Ela foi utilizada na constru¸˜o da documenta¸ao das implementa¸oes realizadas. Para ca c˜ c˜ desenvolver a UML foi utilizada uma ferramenta visual, Astah*, descrita na parte de aplicativos. 5.1.2 PHP O PHP ´ uma linguagem de script amplamente utilizada que ´ destinada ao desen- e e volvimento web e pode ser misturada com HTML. Ele foi criado por Rasmus Lerdorf e hoje ´ mantido pela companhia Zend e, tamb´m, pela comunidade. O que mais chama a e e aten¸ao no PHP ´ que ele ´ extremamente simples para iniciantes, por´m pode fornecer c˜ e e e muitos recursos avan¸ados para programadores profissionais. (PHP, 2009) c Como este projeto exige um forte suporte ao paradigma de programa¸˜o orientada a ca
  • 49. 48 objetos, ´ necess´rio utilizar os pacotes mais recentes da linguagem, a partir da vers˜o 5. e a a A vers˜o utilizada ´ a 5.2.10. a e 5.1.3 Apache HTTP O projeto Apache HTTP ´ um esfor¸o de se desenvolver um servidor Hypertext Trans- e c fer Protocol (HTTP) de c´digo aberto para sistemas operacionais modernos, como UNIX o e Windows NT. O objetivo do projeto ´ prover um servidor que seja seguro, eficiente e e extens´ ıvel, e que forne¸a servi¸os HTTP em sincronia com o padr˜o atual deste protocolo. c c a (APACHE, 2009) O servidor Apache foi instalado na m´quina servidora da aplica¸˜o, a vers˜o escolhida a ca a ´ a 2.2.12. e 5.1.4 HTML HTML ´ um acrˆnimo de HyperText Markup Language, traduzido como Linguagem e o c˜ ´ de Marca¸ao para HiperTexto. E uma linguagem destinada ` escrita de documentos que a possam ser lidos por softwares genericamente chamados de agentes de usu´rio, como, a por exemplo, um navegador ou um leitor de tela. CSS ´ a abrevia¸˜o de Cascading Style e ca Sheet, que significa Folhas de Estilo em Cascata, e ´ um mecanismo simples para adicionar e estiliza¸ao aos documentos web escritos em HTML. (SILVA, 2008) c˜ A interface com o usu´rio da aplica¸ao foi constru´ utilizando HTML e CSS, e as a c˜ ıda premissas da parte visual ´ focar na simplicidade e usabilidade do sistema. e 5.1.5 MySQL O MySQL ´ o software de banco de dados de c´digo aberto mais popular do mundo, e o com milh˜es de distribui¸oes j´ feitas pela internet. o c˜ a Entre seus principais recursos, destacam-se: performance, confiabilidade e facilidade de uso ele se tornou a escolha preferida para sistemas que rodam na web. Atualmente ele pertence a Sun Microsys- ` tems. (MYSQL, 2009) A vers˜o do MySQL utilizada no projeto ´ a 5.1.37. a e
  • 50. 49 5.2 Padr˜es Envolvidos o 5.2.1 Programa¸˜o Orientada a Objetos ca A orienta¸ao a objetos ´ um paradigma de programa¸ao, da mesma forma como a pro- c˜ e c˜ grama¸ao estruturada. A principal diferen¸a s˜o nos conceitos que envolvem a orienta¸˜o c˜ c a ca a objetos. Segundo Dall’Oglio (2007), os principais conceitos da orienta¸ao a objetos s˜o: c˜ a ´ • Classes: E uma estrutura que define um tipo de dados, que pode conter atributos (vari´veis) e fun¸oes (m´todos) para manipular estes atributos; a c˜ e • Objetos: Um objeto cont´m exatamente a mesma estrutura e as propriedades de e uma classe, no entanto sua estrutura ´ dinˆmica, seus atributos podem mudar de e a valor durante a execu¸˜o do programa e pode-se declarar diversos objetos oriundos ca da mesma classe; • Atributos: Representam as caracter´ ısticas de um objeto e definem a estrutura do mesmo; • M´todos: A¸oes ou servi¸os que um objeto pode executar; e c˜ c • Modificadores de Acesso: Referem-se aos modificadores Public, Private e Pro- tected, e definem o n´ de encapsulamento de um determinado atributo ou m´todo. ıvel e Devido aos design patterns serem direcionados e desenvolvidos para projetos que uti- lizam orienta¸ao a objetos, este paradigma foi obrigat´rio no experimento deste projeto. c˜ o 5.2.2 Design Patterns Com o intuito de se prover uma arquitetura de software para desenvolver diversos tipos de aplica¸ao, de uma forma mais padronizada, ´ necess´rio se aplicar os design c˜ e a patterns, para resolver problemas com solu¸oes reutiliz´veis e para definir formas mais c˜ a organizadas de se trabalhar. Na implementa¸ao foram aplicados diversos patterns, abaixo c˜ encontra-se uma lista deles, junto com uma breve defini¸˜o retirada da fundamenta¸ao ca c˜ te´rica deste trabalho: o • Singleton: Garante que apenas uma instˆncia de determinada classe seja permitida a na aplica¸ao; c˜
  • 51. 50 • Factory : Centraliza a instancia¸ao de determinados objetos da aplica¸ao; c˜ c˜ • Facade: Esconde de camadas superiores longos trechos de c´digos de subsistemas; o • Observer : Toma a¸oes ao ser notificado de que algum evento ocorreu em classes c˜ observ´veis; a • Data Mapper : Faz o mapeamento entre os dados do banco de dados com os objetos da aplica¸ao; c˜ • Table Data Gateway : Age como uma porta de entrada para uma tabela do banco de dados. Ir´ lidar com todas as linhas da tabela; a • MVC: Divide a aplica¸˜o em trˆs camadas: Model que possuir´ a l´gica de neg´cio, ca e a o o View que apresentar´ os dados e Controller que interligar´ as outras duas camadas. a a 5.3 Estrutura F´ ısica 5.3.1 Ambiente F´ ısico O ambiente onde foram feitos os experimentos fica a cargo de uma m´quina dom´stica a e convencional para armazenar a aplica¸˜o e de uma m´quina com um navegador de internet ca a para acessar a aplica¸˜o. A rede utilizada possui apenas um hub para permitir acesso entre ca os computadores, e a velocidade da conex˜o ´ Fast Ethernet 100. a e 5.3.2 Configura¸oes de Hardware c˜ As m´quinas que ser˜o utilizadas nos experimentos possuem as seguintes configu- a a ra¸˜es: co • Servidor - M´quina Dom´stica a e – CPU Sempron 3800+; – 512 MB de mem´ria DDR 400MHz; o – HD de 80 GB PATA. • Cliente - Notebook SempToshiba IS1525 – CPU Pentium Dual Core T2130 1.86GHz;
  • 52. 51 – 2 GB de mem´ria DDR2 667MHz; o – HD de 160 GB SATA. 5.4 Estrutura L´gica o 5.4.1 Sistema Operacional O sistema operacional que ser´ utilizado em ambas as m´quinas ´ o GNU/Linux a a e Ubuntu 9.10 Karmic Koala, com todas as atualiza¸˜es dispon´ co ıveis j´ instaladas. O kernel a utilizado ´ o 2.6.31-14-generic. Os pacotes utilizados s˜o: e a • apache2 - Vers˜o 2.2.12; a • php5 - Vers˜o 5.2.10; a • pdo-mysql - Vers˜o 5.1.37; a • mysql-server-5.1 - Vers˜o 5.1.37. a 5.4.2 Aplicativos 5.4.2.1 Astah* Community Astah* ´ um editor UML que fornece diversos recursos, entre eles Mapas Mentais, e diagramas de classes, casos de uso e sequˆncia entre outros. Todos os diagramas criados e no Astah* s˜o consistentemente guardados em um modelo, o que pode dar mais eficiˆncia a e a comunica¸ao entre membros da equipe de desenvolvimento. O Astah* possui as vers˜es: ` c˜ o Community, UML, Professional e Share, onde a Community e a Share s˜o gratuitas, e a a UML e Professional pagas. (CHANGEVISION, 2009) O Astah* Community foi escolhido principalmente pela interoperabilidade, pelos re- cursos oferecidos e por ser um software gratuito, a vers˜o utilizada ´ a 6.0, por ser a a e ultima vers˜o est´vel do software. ´ a a 5.4.2.2 Eclipse O Eclipse ´ um ambiente de desenvolvimento integrado (Integrated Development En- e vironment) focado principalmente no desenvolvimento de aplica¸˜es Java, que pode ser co facilmente extendido para oferecer suporte a outras linguagens, como o PHP, a partir
  • 53. 52 de plugins. O projeto Eclipse foi criado originalmente pela IBM em Novembro de 2001, tornando-se independente ap´s a cria¸ao da Eclipse Foundation, em Janeiro de 2004. O o c˜ Eclipse ´ distribu´ como software livre e ´ um ambiente desenvolvido na linguagem e ıdo e Java, fornecendo interoperabilidade, necessitando apenas de uma m´quina virtual Java a para ser executado. O Eclipse utilizado ´ um pacote espec´ e ıfico para programa¸ao de aplica¸oes em PHP, c˜ c˜ o Eclipse PDT, e a vers˜o do pacote ´ a 2.1. a e 5.4.2.3 phpMyAdmin O phpMyAdmin ´ uma ferramenta gratuita escrita em PHP com o objetivo de ad- e ministrar bancos de dados MySQL. Este ferramenta suporta diversas opera¸˜es com o co MySQL. Sua interface com o usu´rio suporta as opera¸oes mais utilizadas, como: admin- a c˜ istrar bancos de dados, tabelas, campos, relacionamentos, ´ ındices, usu´rios, permiss˜es, a o etc. Al´m de existir a possibilidade de se executar diretamente instru¸oes SQL a partir e c˜ de um mini-terminal web. (PHPMYADMIN, 2009) Ele foi selecionado por ser interoper´vel e pr´tico, sendo a vers˜o utilizada a 3.2.3. a a a 5.4.3 Frameworks 5.4.3.1 Zend Framework O Zend Framework foi desenvolvido com o foco em se ter uma ferramenta de extrema simplicidade e produtividade, que possua os ultimos recursos dispon´ ´ ıveis da web 2.0 e que possua um c´digo bem testado, garantindo tamb´m a agilidade nesses testes, onde o e empresas possam depender deste c´digo sem maiores problemas. (ZEND, 2009) o O framework fornece uma biblioteca de componentes de baixo acoplamento que provˆ e 80% das funcionalidades que os desenvolvedores necessitam e que permite aos desenvolve- dores a customiza¸ao dos 20% restantes para atingir os requisitos espec´ c˜ ıficos necess´rios. a Ele tamb´m possui os seguintes recursos dispon´ e ıveis: suporte a AJAX atrav´s de JSON, e mecanismo Lucene para realizar buscas, sindica¸oes de dados, web services e utiliza¸ao de c˜ c˜ todos os recursos avan¸ados de orienta¸˜o a objetos da linguagem PHP a partir da vers˜o c ca a 5. (ZEND, 2009) O Zend Framework ´ o n´cleo da arquitetura, a partir dele foram aplicados os design e u patterns selecionados e foi constru´ a aplica¸ao. A vers˜o utilizada ´ a 1.9.5. ıda c˜ a e
  • 54. 53 6 Arquitetura Definida A arquitetura de software definida ´ uma arquitetura N-camadas, onde s˜o delegadas e a responsabilidades distintas para cada uma destas camadas. Estas camadas s˜o camadas a l´gicas, sendo feita esta divis˜o para facilitar a distribui¸ao dos componentes da aplica¸ao. o a c˜ c˜ A Figura 6.1 apresenta as camadas da arquitetura e a rela¸˜o que elas possuem entre si. ca Figura 6.1: Camadas da Arquitetura de Software. 6.1 Fluxo da Arquitetura O fluxo definido por esta arquitetura segue o padr˜o definido pelo Zend Framework a e, tamb´m, possui algumas customiza¸˜es para a comunica¸ao entre cada camada. A e co c˜ estrutura base do framework ´ baseada no pattern MVC, o que divide a aplica¸ao em e c˜
  • 55. 54 Model, View e Controller. Na arquitetura, conforme apresentado na Figura 6.1, ainda existem as camadas: Facade, Data Mapper e Table Data Gateway. Todo o fluxo inicia-se por uma requisi¸˜o feita por um usu´rio, o framework definir´ ca a a qual o Controller requerido, este ent˜o ser´ respons´vel por tratar a requisi¸ao e, uti- a a a c˜ lizando o pattern Factory Method, o Controller obt´m a Facade ligada ao caso de uso a e que ele corresponde e ent˜o delega para esta camada o processamento da l´gica referente a o a regra de neg´cio. o A Facade poder´ utilizar um Data Mapper para obter dados do banco de dados, ou a para fazer opera¸oes a registros do banco. O Data Mapper ir´ utilizar o Table Data c˜ a Gateway para efetuar as opera¸oes SQL, que ´ a linguagem compreendida pelo banco de c˜ e dados. Ele tamb´m poder´ mapear os dados vindos do Table Data Gateway para objetos e a Model, que representam em forma de objetos as entidades do banco de dados. Existe ainda a implementa¸˜o do Observer e Observable, que fazem parte do design ca pattern Observer. Uma classe Observable possuir´ m´todos para se conectar a Observers e a e para notificar cada um deles. A classe Observer ir´ fazer um log das opera¸oes notificadas a c˜ pela Observable, gravando este log em banco de dados, no formato JSON, para permitir uma consulta posterior. Ap´s todo o processamento das camadas inferiores ser conclu´ o ıdo, o Controller ir´ a continuar o fluxo da aplica¸ao, exibindo a View para o usu´rio, que pode conter os dados c˜ a pegos pelo Data Mapper, ou os formul´rios definidos pelos componentes Zend Form para a obter dados para algum registro, ou mensagens relevantes para informar ao usu´rio. a O design pattern Singleton ´ implementado por diversos componentes do Zend Frame- e work, como, por exemplo, o Zend Auth que ´ utilizado na autentica¸ao de usu´rios. Com e c˜ a este pattern ´ poss´ manter os objetos durante a aplica¸˜o e por apenas um ponto de e ıvel ca entrada. Isto garante a consistˆncia deste objeto, sabendo sempre o que esperar dele. e
  • 56. 55 7 Implementa¸˜o ca Para demonstrar o uso da arquitetura proposta foi implementada uma aplica¸ao de c˜ controle de bibliotecas, com alguns casos de uso que poderiam ser utilizados por bibliotecas reais. Este cap´ ıtulo descreve esta implementa¸˜o, contendo a documenta¸ao do sistema e ca c˜ a aplica¸ao em si. c˜ Para implementar a arquitetura de software proposta neste trabalho, foi especificado um sistema de biblioteca para um cliente fict´ ıcio, este sendo uma biblioteca. Com a automa¸ao que sistemas computacionais visam fornecer a clientes e os casos de uso im- c˜ plementados, alguns problemas encontrados em bibliotecas foram solucionados, utilizando uma implementa¸˜o bem estruturada gra¸as aos design patterns. ca c 7.1 Documenta¸˜o ca Uma an´lise sucinta foi utilizada para documentar o que foi desenvolvido no sistema, a utilizando diagramas UML. 7.1.1 Casos de Uso Foi elaborado um diagrama de casos de uso que demonstra cada funcionalidade que um administrador da biblioteca poder´ realizar. Este encontra-se na Figura 7.1. a
  • 57. 56 Figura 7.1: Diagrama de Casos de Uso. Na tabela 7.1 encontra-se a especifica¸ao de cada caso de uso, descrevendo o que cada c˜ caso de uso representa no escopo das funcionalidades do sistema.
  • 58. 57 Nome do Caso de Uso Descri¸˜o ca Login Processo de autoriza¸ao dos usu´rios do sistema. c˜ a Manter Usu´rios a Cadastro, Altera¸˜o, Visualiza¸˜o, Listagem e Exclus˜o ca ca a dos usu´rios aptos a utilizar o sistema. a Manter Membros Cadastro, Altera¸˜o, Visualiza¸˜o, Listagem e Exclus˜o ca ca a dos membros da biblioteca. Manter Editoras Cadastro, Altera¸˜o, Visualiza¸˜o, Listagem e Exclus˜o ca ca a de editoras de livros. Manter Autores Cadastro, Altera¸˜o, Visualiza¸˜o, Listagem e Exclus˜o ca ca a de autores de livros. Manter Livros Cadastro, Altera¸˜o, Visualiza¸˜o, Listagem e Exclus˜o ca ca a dos livros que comp˜em o acervo da biblioteca. o Realizar Empr´stimo e Processo de empr´stimo de um ou v´rios livros de um e a membro da biblioteca. Realizar Devolu¸˜o ca Faz a devolu¸˜o de um ou mais livros que foram em- ca prestados a um determinado membro. Cobrar Juros Caso a devolu¸˜o seja feita a uma data acima da prevista ca de devolu¸ao, ´ cobrado uma taxa de juros ao membro. c˜ e Tabela 7.1: Especifica¸ao dos casos de uso c˜ 7.1.2 Diagrama de Classes Ap´s ter uma especifica¸˜o de cada funcionalidade que o sistema deve prever, foi elab- o ca orado um diagrama de classes. Este diagrama ´ referente somente as classes que formam e o dom´ de neg´cio do sistema, ou seja, objetos que representam entidades utilizadas ao ınio o longo do sistema como, por exemplo, Livro ou Empr´stimo, e que s˜o espec´ e a ıficas da apli- ca¸ao em quest˜o. As classes de dom´ c˜ a ınio de neg´cio possuem somente as caracter´ o ısticas do objeto em quest˜o. Este diagrama de classes encontra-se na figura 7.2. a
  • 59. 58 Figura 7.2: Diagrama de Classes. 7.1.3 Banco de Dados Como descrito no cap´ ıtulo de ambiente experimental o SGBD utilizado foi o MySQL. Para armazenar os dados da aplica¸ao foram definidas as tabelas utilizadas por cada caso c˜ de uso, tabelas estas que seguem a 3a Forma Normal de bancos de dados relacionais. Foi gerado um documento de Modelo de Entidades e Relacionamentos (MER), este modelo ´ e apresentado na figura 7.3. Figura 7.3: Modelo de Entidades e Relacionamentos.
  • 60. 59 7.2 Desenvolvimento da Aplica¸˜o ca O Zend Framework fornece uma estrutura padr˜o para se organizar cada parte de uma a aplica¸˜o. Baseando-se nesta conven¸˜o, foi estruturada uma hierarquia customizada para ca ca se aplicar os design patterns da arquitetura. Al´m dos pacotes de cada camada, ainda e existem pacotes para helpers, configura¸˜es e internacionaliza¸˜o. A Figura 7.4 demonstra co ca a hierarquia de pastas definida para a aplica¸ao. c˜ Figura 7.4: Estrutura de Diret´rios. o A Listagem 7.1 ´ o arquivo de configura¸˜o utilizado para definir alguns parˆmetros e ca a de componentes, assim como os dados de acesso a banco de dados. O arquivo ´ baseado e na sintaxe INI utilizada para estrutura¸˜o de arquivos de configura¸˜o no geral. ca ca Listagem 7.1: Arquivo de Configura¸ao c˜ 1 [ production ] 2 i n c l u d e P a t h s . l i b r a r y = APPLICATION PATH " / . . / l i b r a r y " 3 bootstrap . c l a s s = " Bootstrap " 4 r e s o u r c e s . f r o n t C o n t r o l l e r . c o n t r o l l e r D i r e c t o r y = APPLICATION PATH " / c o n t r o l l e r s " 5 resources . frontController . defaultControllerName = " emprestimo " 6 # Banco d e d a d o s 7 r e s o u r c e s . db . a d a p t e r = " P D O _ M Y S Q L " 8 r e s o u r c e s . db . params . h o s t = " l o c a l h o s t " 9 r e s o u r c e s . db . params . username = " r o o t " 10 r e s o u r c e s . db . params . p a s s w o r d = " " 11 r e s o u r c e s . db . params . dbname = " m o n o g r a f i a _ b i b l i o t e c a "
  • 61. 60 7.2.1 Neg´cio o A camada de neg´cio ´ respons´vel pelas regras de neg´cio que a aplica¸ao necessitar´ o e a o c˜ a assim como acesso a banco de dados, valida¸˜es e demais opera¸oes de mais baixo n´ co c˜ ıvel. 7.2.1.1 Facade Como j´ dito, a Facade conter´ l´gica de neg´cio, escondendo c´digo das camadas a a o o o superiores. As Facades s˜o instanciadas a partir do uso de uma Factory, que ´ apresentada a e mais adiante. A Listagem 7.2 apresenta o c´digo da Facade de Empr´stimos que, nesta o e aplica¸˜o, ´ a que mais possui regras de neg´cio. ca e o Listagem 7.2: Facade de Empr´stimo e 1 class Biblioteca Business Facade Emprestimo { 2 p r o t e c t e d $ mapper ; 3 p r o t e c t e d $ mapperItem ; 4 5 public function construct () { 6 $ t h i s −> mapper = new B i b l i o t e c a B u s i n e s s D a t a M a p p e r E m p r e s t i m o ( ) ; 7 $ t h i s −> ma pperI te m = new B i b l i o t e c a B u s i n e s s D a t a M a p p e r I t e m E m p r e s t i m o ( ) ; 8 } 9 public function c a l c u l a J u r o s B u s i n e s s ( $id , $data devolucao ) { 10 $ i t e m = $ t h i s −> mapperItem −>g e t ( $ i d ) ; 11 $ d a t e v a l i d a t o r = new Z e n d V a l i d a t e D a t e ( ) ; 12 if ( $ d a t e v a l i d a t o r −> i s V a l i d ( $ d a t a d e v o l u c a o ) ) { 13 $ v a l o r j u r o s = $item −>g e t E m p r e s t i m o ( )−>g e t V a l o r J u r o s ( ) ; 14 $ d a t a p r e v i s t a = $item −>g e t D a t a P r e v i s t a ( ) ; 15 16 $ t i m e s t a m p d a t a d e v o l u c a o = mktime ( 0 , 0 , 0 , substr ( $ d a t a d e v o l u c a o , 5 , 2) , substr ( $ d a t a d e v o l u c a o , 8 , 2 ) , substr ( $ d a t a d e v o l u c a o , 0 , 4) ) ; 17 $ t i m e s t a m p d a t a p r e v i s t a = mktime ( 0 , 0 , 0 , substr ( $ d a t a p r e v i s t a , 5 , 2 ) , substr ( $data prevista , 8 , 2 ) , substr ( $ d a t a p r e v i s t a , 0 , 4) ) ; 18 19 $diferenca = ( $timestamp data devolucao − $timestamp data prevista ) ; 20 if ( $ d i f e r e n c a <= 0 ) { 21 return 0; 22 } 23 else { 24 $ d i a s d e c o r r i d o s = c e i l ( $ d i f e r e n c a / 86400) ; 25 return $valor juros ∗ $dias decorridos ; 26 } 27 } 28 return false ; 29 } 30 public function d e v o l v e I t e m B u s i n e s s ( $data , $form ) { 31 if ( $form−> i s V a l i d ( $ d a t a ) ) { 32 $ i d = $form−>g e t V a l u e ( ’ i d ’ ) ; 33 $ d a t a d e v o l v i d a = $form−>g e t V a l u e ( ’ d a t a _ d e v o l v i d a ’ ) ; 34 $ v a l o r p a g o = $ t h i s −>c a l c u l a J u r o s B u s i n e s s ( $ i d , $data devolvida ) ; 35 36 $ t h i s −> mapperItem −>d e v o l u c a o ( $ i d , $data devolvida , $valor pago ) ; 37 38 r e t u r n true ; 39 } 40 else { 41 return false ; 42 } 43 } 44 protected function verificaItemEmprestadoBusiness ( $isbn ) { 45 if ( $ i t e m = $ t h i s −> mapperItem −>g e t B y I s b n ( $ i s b n ) ) { 46 if ( i s n u l l ( $item −>g e t D a t a D e v o l v i d a ( ) ) ) { 47 r e t u r n true ;
  • 62. 61 48 } 49 return false ; 50 } 51 return false ; 52 } 53 } A partir deste c´digo pode-se ver o conceito deste pattern em a¸˜o, o c´digo de uma o ca o Facade pode acabar sendo extenso, mas ele fica concentrado em um ponto, onde sua fun¸˜o ca ´ realmente ser extenso para que outras camadas acabem ficando com menos c´digo. Esta e o Facade est´ resumida, pois ainda existem os m´todos relativos ` adi¸˜o, edi¸ao e exclus˜o a e a ca c˜ a de itens. 7.2.1.2 Factory Method O pattern Factory Method foi utilizado para abstrair a instancia¸ao de Facades pelo c˜ Controller. O c´digo da Factory ´ mostrado na Listagem 7.3. o e Listagem 7.3: Factory de Facades 1 class FactoryFacade { 2 c o n s t FACADE EDITORA = 1 ; 3 c o n s t FACADE AUTOR = 2 ; 4 c o n s t FACADE LIVRO = 3 ; 5 c o n s t FACADE EMPRESTIMO = 4 ; 6 c o n s t FACADE USUARIO = 5 ; 7 c o n s t FACADE MEMBRO = 6 ; 8 c o n s t FACADE AUTH = 7 ; 9 10 public static function obterFacade ( $facade ) { 11 switch ( $ f a c a d e ) { 12 case s e l f : : FACADE EDITORA : 13 r e t u r n new B i b l i o t e c a B u s i n e s s F a c a d e E d i t o r a ( ) ; 14 break ; 15 case s e l f : : FACADE AUTOR: 16 r e t u r n new B i b l i o t e c a B u s i n e s s F a c a d e A u t o r ( ) ; 17 break ; 18 case s e l f : : FACADE LIVRO : 19 r e t u r n new B i b l i o t e c a B u s i n e s s F a c a d e L i v r o ( ) ; 20 break ; 21 case s e l f : : FACADE EMPRESTIMO : 22 r e t u r n new B i b l i o t e c a B u s i n e s s F a c a d e E m p r e s t i m o ( ) ; 23 break ; 24 case s e l f : : FACADE USUARIO : 25 r e t u r n new B i b l i o t e c a B u s i n e s s F a c a d e U s u a r i o ( ) ; 26 break ; 27 case s e l f : : FACADE MEMBRO: 28 r e t u r n new B i b l i o t e c a B u s i n e s s F a c a d e M e m b r o ( ) ; 29 break ; 30 case s e l f : : FACADE AUTH : 31 r e t u r n new B i b l i o t e c a B u s i n e s s F a c a d e A u t h ( ) ; 32 break ; 33 default : 34 throw new E x c e p t i o n ( ’ F a c a d e invalida ! ’) ; 35 break ; 36 } 37 } 38 }
  • 63. 62 Baseando-se em flags definidas na Factory, pode-se saber qual a Facade que se deseja instanciar e ap´s a instancia¸ao basta retorn´-la para as camadas que a exigiram. o c˜ a 7.2.1.3 Data Mapper e Table Data Gateway Ambos est˜o relacionados com a parte de banco de dados da aplica¸ao, onde o Data a c˜ Mapper mapear´ dados vindos do Table Data Gateway que se comunica diretamente com a o banco de dados. O Table Data Gateway herda de um componente do Zend Framework, o Zend Db Table, todos os m´todos referentes a persistˆncia, abstraindo ainda mais a e e SQL do desenvolvedor. Nas listagens 7.4 e 7.5 ´ poss´ verificar, respectivamente, um Data Mapper e um e ıvel Table Data Gateway. Listagem 7.4: Data Mapper de Empr´stimo e 1 class Biblioteca Business DataMapper Emprestimo { 2 protected $ dbTable ; 3 4 public function construct () { 5 $ t h i s −>s e t D b T a b l e ( new B i b l i o t e c a B u s i n e s s D b T a b l e E m p r e s t i m o ( ) ) ; 6 $ t h i s −>getDbTable ( )−>a t t a c h O b s e r v e r ( " B i b l i o t e c a U t i l s _ O b s e r v e r _ O b s e r v e r " ) ; 7 } 8 private function setDbTable ( B i b l i o t e c a B u s i n e s s D b T a b l e E m p r e s t i m o $dbtable ) { 9 $ t h i s −> d b T a b l e = $ d b t a b l e ; 10 } 11 private f u n c t i o n getDbTable ( ) { 12 return $ t h i s −> d b T a b l e ; 13 } 14 public f u n c t i o n add ( $ d a t a e m p r e s t i m o , $membro id , $valor juros ) { 15 $ d a t a = array ( 16 ’ d a t a _ e m p r e s t i m o ’ = $data emprestimo , > 17 ’ m e m b r o _ i d ’ = $membro id , > 18 ’ valor_juros ’ => $valor juros 19 ); 20 $ i d = $ t h i s −>getDbTable ( )−> i n s e r t ( $ d a t a ) ; 21 return $id ; 22 } 23 public function get ( $id , $array = false ) { 24 $row = $ t h i s −>getDbTable ( )−>fetchRow ( ’ i d = ’ . ( int ) $id ) ; 25 if ( $row ) { 26 $membro = $row−>f i n d P a r e n t R o w ( ’ B i b l i o t e c a _ B u s i n e s s _ D b T a b l e _ M e m b r o ’ )−>t o A r r a y ( ) ; 27 $ d a t a = $row−>t o A r r a y ( ) ; 28 if ( $array ) { 29 array push ( $data , array ( ’ m e m b r o ’ = $membro ) ) ; > 30 r e t u r n $data ; 31 } 32 $model = new B i b l i o t e c a B u s i n e s s M o d e l E m p r e s t i m o ( ) ; 33 $model membro = new B i b l i o t e c a B u s i n e s s M o d e l M e m b r o ( ) ; 34 $model membro−> s e t I d ( $membro [ ’ i d ’ ] ) 35 −>s e t E n d e r e c o ( $membro [ ’ e n d e r e c o ’ ] ) 36 −>setNome ( $membro [ ’ n o m e ’ ] ) 37 −> s e t T e l e f o n e ( $membro [ ’ t e l e f o n e ’ ] ) ; 38 $model−> s e t I d ( $ d a t a [ ’ i d ’ ] ) 39 −>setMembro ( $model membro ) 40 −>s e t D a t a E m p r e s t i m o ( $ d a t a [ ’ d a t a _ e m p r e s t i m o ’ ] ) 41 −> s e t V a l o r J u r o s ( $ d a t a [ ’ v a l o r _ j u r o s ’ ] ) ; 42 r e t u r n $model ; 43 } 44 return false ; 45 } 46 }
  • 64. 63 O m´todo get() demonstra o conceito do Data Mapper onde ele mapeia os dados e vindos do banco para um Model da aplica¸ao. c˜ Listagem 7.5: Table Data Gateway de Empr´stimo e 1 class Biblioteca Business DbTable Emprestimo extends BibliotecaUtils Observer Observable { 2 p r o t e c t e d $ name = ’ e m p r e s t i m o ’ ; 3 protected $ r e f e r e n c e M a p = array ( 4 ’ M e m b r o ’ = array ( > 5 ’ c o l u m n s ’ = array ( ’ m e m b r o _ i d ’ ) , > 6 ’ refTableClass ’ => ’ Biblioteca_Business_DbTable_Membro ’ , 7 ’ refColumns ’ => ’ id ’ 8 ) 9 ); 10 } A partir da Listagem 7.5 ´ poss´ perceber a abstra¸˜o de todo c´digo pertinente ao e ıvel ca o acesso a banco. A classe Observable, detalhada posteriormente, herda de Zend Db Table, e, um Table Data Gateway possuir´ todos os m´todos de um Observable e, tamb´m, de a e e um Zend Db Table. 7.2.1.4 Model O Model possui apenas os atributos que definem uma entidade do banco e os m´todos e acessores a estes atributos. A listagem 7.6 demonstra um Model utilizado na aplica¸˜o. ca Listagem 7.6: Model da entidade Empr´stimo e 1 class Biblioteca Business Model Emprestimo { 2 private $ id ; 3 p r i v a t e $ membro ; 4 private $ data emprestimo ; 5 private $ valor juros ; 6 7 public function getId () { 8 return $ t h i s −> i d ; 9 } 10 public function setId ( $id ) { 11 $ t h i s −> i d = $ i d ; 12 return $this ; 13 } 14 public f u n c t i o n getMembro ( ) { 15 return $ t h i s −> membro ; 16 } 17 public f u n c t i o n setMembro ( B i b l i o t e c a B u s i n e s s M o d e l M e m b r o $membro ) { 18 $ t h i s −> membro = $membro ; 19 return $this ; 20 } 21 public f u n c t i o n getDataEmprestimo ( ) { 22 return $ t h i s −> d a t a e m p r e s t i m o ; 23 } 24 public f u n c t i o n setDataEmprestimo ( $data emprestimo ) { 25 $ t h i s −> d a t a e m p r e s t i m o = $ d a t a e m p r e s t i m o ; 26 return $this ; 27 } 28 public function getValorJuros () { 29 return $ t h i s −> v a l o r j u r o s ; 30 } 31 public function setValorJuros ( $valor juros ) { 32 $ t h i s −> v a l o r j u r o s = $ v a l o r j u r o s ; 33 return $this ; 34 }
  • 65. 64 35 } 7.2.1.5 Observer O Observer trabalha com o conceito de observadores e observ´veis, que na arquite- a tura s˜o representados, respectivamente, pelas classes: Observer e Observable. Ambas a encontram-se nas Listagens: 7.7 e 7.8. Listagem 7.7: Classe Observer 1 class BibliotecaUtils Observer Observer { 2 protected $ data ; 3 protected $ logger ; 4 5 protected function s e t L o g g e r ( Zend Log $ l o g g e r ) { 6 $ t h i s −> l o g g e r = $ l o g g e r ; 7 } 8 protected function getLogger () { 9 return $ t h i s −> l o g g e r ; 10 } 11 protected function setData ( $data ) { 12 $ t h i s −> d a t a = $ d a t a ; 13 } 14 protected function getData ( ) { 15 return $ t h i s −> d a t a ; 16 } 17 protected function initLog () { 18 $db = Z e n d D b T a b l e : : g e t D e f a u l t A d a p t e r ( ) ; 19 $ c o lum ns = $ t h i s −>p a r s e C o l u m n s ( ) ; 20 $ w r i t e r = new Z e n d L o g W r i t e r D b ( $db , ’ h i s t o r i c o ’ , $ c o lu mns ) ; 21 $ t h i s −>s e t L o g g e r ( new Zend Log ( $ w r i t e r ) ) ; 22 } 23 protected function createData ( $event , $class ) { 24 $ d a t a = array ( ) ; 25 $ d a t a [ ’ o p e r a c a o ’ ] = ( $ e v e n t == ’ i n s e r t ’ ) ? " N o v o " : " Atualizacao " ; 26 if ( $ e v e n t != ’ d e l e t e ’ ) { 27 foreach ( $ c l a s s −>d a t a a s $key => $value ) { 28 $ d a t a [ $key ] = $ v a l u e ; 29 } 30 } 31 else { 32 $data [ ’ o p e r a c a o ’ ] = " E x c l u s a o " ; 33 } 34 if ( $ e v e n t != ’ i n s e r t ’ ) { 35 $where = explode ( ’ = ’ , $ c l a s s −>where ) ; 36 $ d a t a [ ’ i d ’ ] = trim ( $where [ 1 ] ) ; 37 } 38 $ u s u a r i o = Zend Auth : : g e t I n s t a n c e ( )−> g e t I d e n t i t y ( ) ; 39 $ d a t a [ ’ e f e t u a d o _ p o r ’ ] = $ u s u a r i o −>i d ; 40 $ t h i s −>s e t D a t a ( Z e n d J s o n : : e n c o d e ( $ d a t a ) ) ; 41 } 42 protected f u n c t i o n parseColumns ( ) { 43 $ c o lum ns = array ( ’ p r i o r i d a d e ’ => ’ priority ’ , ’ mensagem ’ => ’ message ’) ; 44 r e t u r n $ c o lumn s ; 45 } 46 protected function logMessage ( ) { 47 $ t h i s −>g e t L o g g e r ( )−> i n f o ( $ t h i s −>g e t D a t a ( ) ) ; 48 } 49 public function observeTable ( $event , $class ) { 50 $ t h i s −>c r e a t e D a t a ( $ e v e n t , $class ) ; 51 $ t h i s −>i n i t L o g ( ) ; 52 $ t h i s −>l o g M e s s a g e ( ) ; 53 } 54 }
  • 66. 65 A classe Observer utiliza o componente Zend Log para guardar um log das opera¸˜es co em banco de dados, permitindo uma consulta posterior, no caso de necessitar de backups para recupera¸ao de dados, ou para manter um hist´rico dos usu´rios. c˜ o a Listagem 7.8: Classe Observable 1 class BibliotecaUtils Observer Observable extends Zend Db Table Abstract { 2 public $data ; 3 p u b l i c $where ; 4 protected static $ o b s e r v e r s = array ( ) ; 5 6 public static function attachObserver ( $ c l a s s ) { 7 if (! is string ( $class ) || ! class exists ( $class ) || ! i s c a l l a b l e ( array ( $ c l a s s , ’ observeTable ’) ) ) { 8 return false ; 9 } 10 if (! isset ( s e l f : : $ observers [ $class ]) ) { 11 s e l f : : $ o b s e r v e r s [ $ c l a s s ] = true ; 12 } 13 r e t u r n true ; 14 } 15 protected function n o t i f y O b s e r v e r s ( $event ) { 16 if ( ! empty ( s e l f : : $ o b s e r v e r s ) ) { 17 foreach ( array keys ( s e l f : : $ o b s e r v e r s ) a s $observer ) { 18 $ o b j o b s e r v e r = new $ o b s e r v e r ( ) ; 19 c a l l u s e r f u n c ( array ( $ o b j o b s e r v e r , ’ o b s e r v e T a b l e ’ ) , $event , $this ) ; 20 } 21 } 22 } 23 public function i n s e r t ( $data ) { 24 $ l a s t i d = parent : : i n s e r t ( $data ) ; 25 if ( $ l a s t i d > 0) { 26 $ t h i s −>d a t a = $ d a t a ; 27 $ t h i s −>d a t a [ ’ i d ’ ] = $ l a s t i d ; 28 $ t h i s −> n o t i f y O b s e r v e r s ( " i n s e r t " ) ; 29 } 30 return $last id ; 31 } 32 public f u n c t i o n u p d a t e ( $data , $where ) { 33 p a r e n t : : u p d a t e ( $data , $where ) ; 34 $ t h i s −>where = $where ; 35 $ t h i s −>d a t a = $ d a t a ; 36 $ t h i s −> n o t i f y O b s e r v e r s ( " u p d a t e " ) ; 37 } 38 public function d e l e t e ( $where ) { 39 $ t h i s −>where = $where ; 40 $ l a s t i d = p a r e n t : : d e l e t e ( $ t h i s −>where ) ; 41 if ( $ l a s t i d > 0) { 42 $ t h i s −> n o t i f y O b s e r v e r s ( " d e l e t e " ) ; 43 } 44 return $last id ; 45 } 46 } As classes observ´veis s˜o classes Table Data Gateway. A diferen¸a ´ que a classe a a c e Observable utiliza o polimorfismo para sobrescrever o comportamento padr˜o dos m´todos a e de persistˆncia, para incluir a notifica¸ao de um determinado evento ao observador. e c˜ 7.2.2 Camada de Mais Alto N´ ıvel A camada de neg´cio ´ a mais complexa e que necessitou de mais patterns para o e abstrair as partes que comp˜em uma aplica¸˜o. A camada de mais alto n´ ´ composta o ca ıvel e
  • 67. 66 pelo Controller e pela View, e possui c´digo muito mais simplificado. o Na listagem 7.9, ´ exibido o c´digo de um Controller, onde ele ´ baseado em actions e o e para determinar qual opera¸˜o est´ sendo requisitada pelo usu´rio. ca a a Listagem 7.9: Controller de Empr´stimo e 1 class EmprestimoController extends Zend Controller Action { 2 public function init () { 3 if ( ! Zend Auth : : g e t I n s t a n c e ( )−> h a s I d e n t i t y ( ) ) { 4 $ t h i s −> r e d i r e c t ( ’ / a u t h ’ ) ; 5 } 6 $ t h i s −>f a c a d e = F a c t o r y F a c a d e : : o b t e r F a c a d e ( F a c t o r y F a c a d e : : FACADE EMPRESTIMO) ; 7 } 8 public function indexAction () { 9 $ t h i s −>view −>h e a d T i t l e ( ’ E m p r e s t i m o s ’ , ’ P R E P E N D ’ ) ; 10 $ t h i s −>view −>e m p r e s t i m o s = $ t h i s −>f a c a d e −> l i s t B u s i n e s s ( ) ; 11 } 12 public function adicionarAction () { 13 $ t h i s −>view −>h e a d T i t l e ( ’ N o v o Emprestimo ’ , ’ PREPEND ’) ; 14 $form = new B i b l i o t e c a F o r m E m p r e s t i m o ( ) ; 15 $ t h i s −>view −>form = $form ; 16 if ( $ t h i s −>g e t R e q u e s t ( )−> i s P o s t ( ) ) { 17 $ d a t a = $ t h i s −>g e t R e q u e s t ( )−>g e t P o s t ( ) ; 18 if ( $ i d = $ t h i s −>f a c a d e −>a d d B u s i n e s s ( $data , $form ) ) { 19 $ t h i s −> h e l p e r −>F l a s h M e s s e n g e r ( ’ E m p r e s t i m o adicionado , insira agora os itens deste emprestimo .’) ; 20 $ t h i s −> r e d i r e c t ( ’ / e m p r e s t i m o / a d i c i o n a r i t e n s / i d / ’ . $id ) ; 21 } 22 else { 23 $form−>p o p u l a t e ( $ d a t a ) ; 24 } 25 } 26 } 27 public function adicionaritensAction () { 28 $ t h i s −>view −>h e a d T i t l e ( ’ A d i c i o n a r Itens de Emprestimo ’ , ’ PREPEND ’) ; 29 $ i d = $ t h i s −> g e t P a r a m ( ’ i d ’ , 0 ) ; 30 $form = new B i b l i o t e c a F o r m I t e m E m p r e s t i m o ( ) ; 31 $form−>g e t E l e m e n t ( ’ e m p r e s t i m o _ i d ’ )−>s e t V a l u e ( $ i d ) ; 32 $ t h i s −>view −>form = $form ; 33 if ( ! $ d a t a = $ t h i s −>f a c a d e −>v i e w B u s i n e s s ( $ i d ) ) { 34 $ t h i s −> r e d i r e c t ( ’ / e m p r e s t i m o ’ ) ; 35 } 36 else { 37 $ t h i s −>view −> i t e n s = $ t h i s −>f a c a d e −> l i s t I t e n s B u s i n e s s ( $ i d ) ; 38 $ t h i s −>view −>e m p r e s t i m o = $ d a t a ; 39 } 40 if ( $ t h i s −>g e t R e q u e s t ( )−> i s P o s t ( ) ) { 41 $ d a t a p o s t = $ t h i s −>g e t R e q u e s t ( )−>g e t P o s t ( ) ; 42 if ( $ t h i s −>f a c a d e −>a d d I t e m B u s i n e s s ( $ d a t a p o s t , $form ) ) { 43 $ t h i s −> h e l p e r −>F l a s h M e s s e n g e r ( ’ I t e m adicionado com sucesso ! ’) ; 44 $ t h i s −> h e l p e r −> r e d i r e c t o r −>goToRoute ( 45 array ( 46 ’ controller ’ => ’ emprestimo ’ , 47 ’ action ’ => ’ adicionaritens ’ , 48 ’ id ’ => $id 49 ) 50 ); 51 } 52 else { 53 $form−>p o p u l a t e ( $ d a t a p o s t ) ; 54 } 55 } 56 } 57 public function deletarAction () { 58 if ( $ t h i s −>f a c a d e −> d e l e t e B u s i n e s s ( $ t h i s −> g e t P a r a m ( ’ i d ’ ) ) ) { 59 $ t h i s −> h e l p e r −>F l a s h M e s s e n g e r ( ’ E m p r e s t i m o excluido com sucesso ! ’) ; 60 } 61 $ t h i s −> r e d i r e c t ( ’ / e m p r e s t i m o ’ ) ; 62 } 63 }
  • 68. 67 A View ficou, com c´digo HTML e apenas alguns trechos de c´digo PHP. Como o o toda a l´gica est´ definida em camadas mais baixas, a apresenta¸ao com o usu´rio exige o a c˜ a apenas fun¸oes PHP simples, como, por exemplo, la¸os para percorrer dados e m´todos c˜ c e para imprimir estes dados. A listagem 7.10 refere-se a View de listagem de empr´stimos e e ilustra melhor o que ´ utilizado nas Views. e Listagem 7.10: View de Listagem de Empr´stimos e 1 <h2>L i s t a n d o Empr&e a c u t e ; s t i m o s </h2> 2 <p> 3 <a h r e f=" < ? p h p echo $ t h i s - > u r l ( a r r a y ( ’ a c t i o n ’ = > ’ a d i c i o n a r ’) ) ; ? > " c l a s s=" b u t t o n _ t o p ">Novo Empr&e a c u t e ; s t i m o </a> 4 </p> 5 <t a b l e c l a s s=" g r i d "> 6 <thead> 7 <t r > 8 <t h s c o p e=" c o l ">Membro</th> 9 <t h s c o p e=" c o l ">Data do Empr&e a c u t e ; s t i m o </th> 10 <t h s c o p e=" c o l ">V a l o r do J u r o s </th> 11 <t h s c o p e=" c o l ">E x c l u i r </th> 12 </t r > 13 </thead> 14 <tbody> 15 <?php i f ( s i z e o f ( $ t h i s −>e m p r e s t i m o s ) == 0 ) : ?> 16 <t r > 17 <t d c o l s p a n=" 4 ">Nenhum r e g i s t r o e n c o n t r a d o . </ td> 18 </t r > 19 <?php e l s e : ?> 20 <?php foreach ( $ t h i s −>e m p r e s t i m o s a s $ e m p r e s t i m o ) : ?> 21 <t r > 22 <td><a h r e f=" < ? p h p echo $this - > url ( array ( ’ action ’ = > ’ a d i c i o n a r i t e n s ’, ’ id ’ = > $ e m p r e s t i m o - > g e t I d ( ) ) ) ; ? > "><?php echo $emprestimo −>getMembro ( )−>getNome ( ) ; ?></a></td> 23 <td><?php echo $emprestimo −>getDataEmprestimo ( ) ; ?></td> 24 <td>R$<?php echo $emprestimo −>g e t V a l o r J u r o s ( ) ; ?></td> 25 <td><a h r e f=" < ? p h p echo $this - > url ( array ( ’ action ’ = > ’ d e l e t a r ’, ’ id ’ = > $emprestimo - > getId () ) ) ; ? > " o n c l i c k=" r e t u r n d e l e t a r ( t h i s . h r e f ) ; ">E x c l u i r </ a></td> 26 </t r > 27 <?php e n d f o r e a c h ; ?> 28 <?php e n d i f ; ?> 29 </tbody> 30 </ t a b l e > O componente Zend Form abstraiu a parte de cria¸˜o de formul´rios e de valida¸ao. ca a c˜ Com o Zend Form basta criar uma classe que herda deste componente e definir os elemen- tos do formul´rio, junto com as valida¸˜es para cada elemento. O c´digo do formul´rio a co o a de cadastro de um novo empr´stimo ´ apresentado na listagem 7.11. e e Listagem 7.11: Formul´rio de Empr´stimo a e 1 class B i b l i o t e c a F o r m E m p r e s t i m o e x t e n d s Zend Form { 2 private $editar = false ; 3 public function init () { 4 r e q u i r e o n c e APPLICATION PATH . ’/ configs / translations / pt_BR . php ’ ; 5 $ t r a n s l a t e = new Z e n d T r a n s l a t e ( ’ a r r a y ’ , $translationStrings , ’ pt ’ ) ; 6 $ t h i s −>s e t T r a n s l a t o r ( $ t r a n s l a t e ) ; 7 $ t h i s −>a d d E l e m e n t P r e f i x P a t h ( ’ B i b l i o t e c a _ V a l i d a t e ’ , ’ B i b l i o t e c a / V a l i d a t e / ’ , ’ v a l i d a t e ’ ) ; 8 $ t h i s −>setName ( ’ e m p r e s t i m o ’ ) ; 9 $ i d = new Z e n d F o r m E l e m e n t H i d d e n ( ’ i d ’ ) ; 10 $ d a t a e m p r e s t i m o = new Z e n d F o r m E l e m e n t T e x t ( ’ d a t a _ e m p r e s t i m o ’ ) ; 11 $ d a t a e m p r e s t i m o −>s e t L a b e l ( ’ D a t a do Emprestimo :’) 12 −>s e t R e q u i r e d ( true )
  • 69. 68 13 −> a d d F i l t e r ( ’ S t r i p T a g s ’ ) 14 −> a d d F i l t e r ( ’ S t r i n g T r i m ’ ) 15 −>a d d V a l i d a t o r ( ’ N o t E m p t y ’ ) 16 −>a d d V a l i d a t o r ( ’ D a t e ’ ) ; 17 $membroFacade = new B i b l i o t e c a B u s i n e s s F a c a d e M e m b r o ( ) ; 18 $ m e m b r o s o p t i o n s = $membroFacade−>h t m l s e l e c t B u s i n e s s ( ) ; 19 $membro id = new Z e n d F o r m E l e m e n t S e l e c t ( ’ m e m b r o _ i d ’ ) ; 20 $membro id−>a d d M u l t i O p t i o n ( ’ ’ , ’ E s c o l h a um Membro ’) ; 21 if ( s i ze of ( $membros options ) > 0) { 22 foreach ( $ m e m b r o s o p t i o n s a s $membro ) { 23 $membro id−>a d d M u l t i O p t i o n ( $membro [ ’ i d ’ ] , $membro [ ’ n o m e ’ ] ) ; 24 } 25 } 26 $membro id−>s e t L a b e l ( ’ M e m b r o : ’ ) 27 −>s e t R e q u i r e d ( true ) 28 −> a d d F i l t e r ( ’ S t r i p T a g s ’ ) 29 −> a d d F i l t e r ( ’ S t r i n g T r i m ’ ) 30 −>a d d V a l i d a t o r ( ’ N o t E m p t y ’ ) ; 31 $ v a l o r j u r o s = new Z e n d F o r m E l e m e n t T e x t ( ’ v a l o r _ j u r o s ’ ) ; 32 $ v a l o r j u r o s −>s e t L a b e l ( ’ V a l o r do Juros : R$ ’ ) 33 −>s e t R e q u i r e d ( true ) 34 −> a d d F i l t e r ( ’ S t r i p T a g s ’ ) 35 −> a d d F i l t e r ( ’ S t r i n g T r i m ’ ) 36 −>a d d V a l i d a t o r ( ’ N o t E m p t y ’ ) 37 −>a d d V a l i d a t o r ( ’ F l o a t ’ ) ; 38 $ s u b m i t = new Z e n d F o r m E l e m e n t S u b m i t ( ’ s u b m i t ’ ) ; 39 $submit −>s e t L a b e l ( ’ S a l v a r ’ ) 40 −> s e t A t t r i b ( ’ i d ’ , ’ s u b m i t b u t t o n ’ ) ; 41 $ t h i s −>addElements ( array ( $ i d , $data emprestimo , $membro id , $valor juros , $submit ) ) ; 42 } 43 } A parte de interface com o usu´rio foi estilizada com CSS, as figuras 7.5, 7.6 e 7.7 a mostram telas referentes a listagem dos empr´stimos, cria¸˜o de um empr´stimo e de- e ca e volu¸˜o de itens, respectivamente. ca Figura 7.5: Tela de listagem de empr´stimos. e
  • 70. 69 Figura 7.6: Tela de cria¸˜o de um empr´stimo. ca e Figura 7.7: Tela de devolu¸˜o de item de empr´stimo. ca e
  • 71. 70 8 Considera¸˜es Finais co O ciclo de vida de um software ´ composto de v´rias etapas, que vai desde sua com- e a posi¸ao at´ a manuten¸ao do mesmo. Com a implementa¸ao utilizada neste trabalho c˜ e c˜ c˜ pˆde-se notar que as arquiteturas de software tornam a etapa de elabora¸ao de um sis- o c˜ tema muito mais organizada, pois partindo-se de conven¸oes e de padroniza¸oes exigidas c˜ c˜ por ela, programadores saber˜o a forma de nomear componentes, identar c´digo e onde a o encontrar funcionalidades espec´ ıficas. Junto com os benef´ ıcios de uma arquitetura de software, a arquitetura proposta traz tamb´m diversos benef´ e ıcios de reusabilidade, gra¸as aos design patterns. Com eles, proble- c mas que o sistema apresentou puderam ser resolvidos de uma maneira altamente aceitada por programadores. Al´m destes design patterns, tamb´m foram utilizados patterns cria- e e dos para melhorar a legibilidade e organiza¸ao dos c´digos, como o Table Data Gateway c˜ o e Data Mapper, estes n˜o pertencendo ao cat´logo escrito pela GOF, que, em conjunto a a com o MVC separam a arquitetura em camadas l´gicas. o Com isto, nota-se a extrema importˆncia que uma arquitetura de software com design a patterns tem no desenvolvimento de um sistema, por´m ainda existe uma outra etapa do e sistema que deve ser levada em considera¸ao: a manuten¸˜o. Com a especifica¸ao dos c˜ ca c˜ design patterns e uma boa documenta¸ao da arquitetura, a manutenibilidade do sistema c˜ ser´ muito mais vi´vel, pois bastar´ ao desenvolvedor entender as regras da arquitetura e a a a conhecer o conceito dos patterns utilizados para poder alterar ou incluir novos c´digos a o sistemas j´ prontos. a Pode-se concluir ent˜o que sistemas podem possuir um ciclo de vida bastante prolon- a gado gra¸as a uni˜o de arquiteturas de software e design patterns, beneficiando os clientes c a e, tamb´m os desenvolvedores. e
  • 72. 71 8.1 Trabalhos Futuros Devido a aplica¸˜o de design patterns depender muito do escopo do projeto, um dos ca trabalhos futuros ´ a sele¸ao de novos patterns, ou a remo¸˜o dos definidos neste trabalho, e c˜ ca para que a arquitetura solucione os problemas de projeto que possam surgir em outros softwares. Al´m disso, desacoplar a arquitetura definida do Zend Framework tamb´m ´ um e e e trabalho futuro. Assim, a mesma arquitetura poderia ser independente de framework, facilitando a migra¸ao entre os diversos frameworks dispon´ c˜ ıveis para PHP. Outro trabalho futuro ´ modificar a estrutura da arquitetura para que ela seja baseada e em plugins. Assim a tarefa de adicionar e editar funcionalidades se torna muito mais pr´tica e consistente. a
  • 73. 72 Referˆncias Bibliogr´ficas e a APACHE. Site Oficial do projeto Apache HTTP. 2009. Dispon´ ıvel em: <http://httpd.apache.org/>. Acesso em: 21 nov. 2009. BASS, L.; CLEMENTS, P.; KAZMAN, R. Software Architecture in Practice. 2. ed. Boston: Addison Wesley, 2003. BUSCHMANN, F. et al. Pattern-Oriented Software Architeture. Chichester: Wiley, 1996. CAKESOFTWAREFOUNDATION. Cake Software Foundation. 2009. Dispon´ em: ıvel <http://cakephp.org>. Acesso em: 31 mai. 2009. CHANGEVISION. Astah* Site Oficial. 2009. Dispon´ em: <http://astah.change- ıvel vision.com>. Acesso em: 21 nov. 2009. CODEIGNITER. Code Igniter Site Oficial. 2009. Dispon´ ıvel em: <http://codeigniter.com/user guide>. Acesso em: 21 nov. 2009. DALL’OGLIO, P. PHP - Programando com Orienta¸˜o a Objetos. S˜o Paulo: Novatec, ca a 2007. FOWLER, M. et al. Patterns of Enterprise Application Architecture. Indianapolis: Addison-Wesley, 2002. GAMMA, E. et al. Design Patterns, Elements of Reusable Object-Oriented Software. Indianapolis: Addison-Wesley, 1995. GIL, A. C. Como elaborar projetos de pesquisa. 4. ed. S˜o Paulo: Atlas, 2002. a HAYDER, H. Object-Oriented Programming with PHP5. UK: Packt Publishing, 2007. MELO, A. A. de; NASCIMENTO, M. G. F. do. PHP Profissional. S˜o Paulo: Novatec, a 2007. MYSQL. MySQL Site Oficial. 2009. Dispon´ em: <http://www.mysql.com/about>. ıvel Acesso em: 21 nov. 2009. PARRA, D. F.; SANTOS, J. A. Metodologia Cient´fica. 4. ed. S˜o Paulo: Futura, 2002. ı a PHP. Site Oficial da linguagem PHP. 2009. Dispon´ em: <http://www.php.net>. ıvel Acesso em: 21 nov. 2009. PHPMYADMIN. phpMyAdmin Site Oficial. 2009. Dispon´ ıvel em: <http://www.phpmyadmin.net>. Acesso em: 21 nov. 2009. POPE, K. Zend Framework 1.8 Web Application Development. UK: Packt Publishing, 2009.
  • 74. 73 PRESSMAN, R. S. Engenharia de Software. 5. ed. Rio de Janeiro: McGraw-Hill, 2002. SILVA, M. S. Construindo sites com CSS e (X)HTML. S˜o Paulo: Novatec, 2008. a SOMMERVILLE, I. Engenharia de Software. 6. ed. S˜o Paulo: Addison Wesley, 2003. a VAROTO, A. C. Vis˜es em Arquitetura de software. S˜o Paulo: [s.n.], 2002. o a XUE, Q.; ZHUO, X. W. Prado QuickStart Tutorial. 2009. Dispon´ ıvel em: <http://www.pradosoft.com>. Acesso em: 31 mai. 2009. ZEND. Zend Framework. 2009. Dispon´ em: <http://framework.zend.com>. Acesso ıvel em: 20 nov. 2009.

×