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

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