MAC499-Trabalho de Formatura Supervisionado
Aluno: Jae Nam Choi
Professor Supervisor: Marco Dimas Gubitoso
1.Introdução
1.1 A Empresa:
A Fundação Cásper Líbero é um instituição sem fins lucrativos que
tem como principais unidades de negócio a TV GAZETA, a RÁDIO GAZETA AM/FM, a FACULDADE DE
COMUNICAÇÃO SOCIAL CÁSPER LÍBERO, os jornais A GAZETA e a GAZETA ESPORTIVA.NET
e a FCL NET , provedora de serviços de internet.
Desde fevereiro até outubro de 2006 atuei como funcionária nessa instituição, dentro da FCL NET,
trabalhando em alguns projetos.
O objetivo dessa monografia é descrever um dos projetos que me foi proposto : o
Sistema de Solicitação de Transportes.
1.2 O Sistema de Solicitação de Transportes:
A idéia do sistema surgiu da necessidade de "moralizar" a utilização dos veículos da fundação,
pelo motivo das solicitações de veículos serem feitas até então apenas com o preenchimento de
uma folha pelo funcionário, e isso tornava muito penoso o processo de obter informações sobre esses papéis
como um conjunto. Por isso, estava sendo difícil rastrear os gastos gerados no setor de transportes, principalmente pelo aumento no gasto com combustíveis.
Assim, levantamos requisitos para gerar um sistema que guardasse informações relevantes de cada solicitação gerada, e com
isso futuramente disponibilizar relatórios que mostrariam com que frequência eram utilizados os veículos,
qual departamento tinha mais solicitantes de transportes,etc.
1.3 Equipe:
A equipe era formada por mim, mais um programador e um analista de sistemas.As reuniões entre nós eram frequentes,
pelo menos três vezes por semana e a troca de emails também era constante.
1.4 Tecnologias utilizadas:
A linguagem de programação usada foi o PHP 4, o sistema gerenciador de banco de dados foi o Oracle 8i e o servidor web foi o Apache.
2.Conceitos e Tecnologias Estudadas
Aplicações Web são sistemas complexos baseados numa variedade de componentes de hardware e software, protocolos,
linguagens e padrões.
Segue a descrição de alguns dos principais conceitos e tecnologias que caracterizam uma Aplicação Web:
2.1 HTTP
O HTTP, ou mais conhecido como HyperText Transfer Protocol, é a tecnologia fundamental para a origem da Aplicação Web.
O HTTP é um protocolo da camada de aplicação que permite aos usuários fazer requisições por recursos em
servidores remotos.Sua origem remonta ao projeto World Wide Web (WWW),que começou em 1990 e teve como objetivo a
construção de um sistema de hipermídia distribuído para acessar, através de uma interface simples,
documentos, imagens, e, ajuda online, guardadas em servidores espalhados sobre uma rede TCP/IP.
Tecnicamente, o HTTP é um protocolo de aplicação cliente-servidor, que define as regras pelas quais o programa
cliente, chamado de browser, e o programa servidor, conhecido como servidor Web, interagem com o objetivo de trocarem
mensagens de requisições por recursos e respostas a essas requisições.
Na terminologia HTTP, o usuário agente (browser) envia uma requisição por
um determinado recurso ao servidor Web, que por sua vez, é um processo rodando continuamente e atendendo as requisições que chegam pela
rede; ao receber a requisição, o servidor localiza o recurso e envia uma resposta ao cliente.O recurso básico pedido por um cliente
é uma página HTML, que é um documento de texto representando um documento hipertexto multimídia.De forma geral,
a requisição de um cliente pode ser um arquivo de qualquer formato guardado no servidor Web,ou mesmo, a ativação de um programa
a ser executado no servidor.
Os recursos HTTP são identificados por meio das URLs (Uniform Resource Locators) que são strings estruturadas
no formato
http:// <host> [: <port>][<path>[? <path>]] , isto é,
após o prefixo fixo http://, a URL contém o nome do servidor ou endereço IP do servidor,
possivelmente seguido pelo número da porta, opcionalmente seguido pelo caminho no sistema de diretórios do servidor Web
apontando para o recurso pedido, opcionalmente seguido por um conjunto de parâmetros chamado query string.
As requisições HTTP tem um formato fixo que consiste de três partes: a linha da requisição, alguns
cabeçalhos de mensagens opcionais e o corpo da requisição.
A linha da requisição é uma string formatada que consiste de três partes: o método HTTP, a URL do recurso requisitado
e a versão do protocolo.Os mais importantes métodos HTTP são o GET e o POST que respectivamente fazem:
a submissão simples da requisição por um recurso do servidor Web
a submissão de uma requisição incluindo dados do usuário (por exemplo, um texto longo ou um arquivo)
Duas importantes observações a respeito do HTTP são :
HTTP é stateless:
Cada requisição HTTP é tratada como uma chamada atômica e independente.Não
há diferença entre uma sequência de duas requisições feitas por usuários diferentes ou pelo mesmo.
Como consequência, o HTTP é incapaz de manter qualquer informação entre duas requisições sucessivas
do mesmo usuário.Por isso, não existe a noção de sessão de um usuário no HTTP.
o HTTP é orientado pela chamada:
A interação ocorre somente quando um cliente chama o servidor.Não
é possível que o servidor chame o cliente de volta.Portanto, a notificação a clientes não pode ser implementado
usando HTTP apenas.
2.2 HTML
Os recursos mais requisitados na internet são as páginas HTML.Uma página HTML
é um arquivo texto escrito em Hypertext Markup Language.
O processamento dessa linguagem é centrado na idéia de inserir
marcas especiais, chamados tags, em documentos de texto, com o objetivo de delimitar porções selecionadas
do texto e expressar algumas propriedades desses trechos selecionados, tais como tipo de fonte, cor e tamanho.
O processamento das tags num documento é separado da criação do seu conteúdo
, e, é delegado a um processador,que recebe como entrada o texto com as tags e o transforma, ao interpretar o significado
dessas tags.Num contexto web, a edição de um documento HTML fica a cargo do produtor do conteúdo usando
qualquer editor de texto, e, o processamento é feito pelo browser.
Sintaticamente, as tags HTML são símbolos delimitados pelos sinais de maior e menor, como por exemplo
, <FONT> ou <TABLE>. Geralmente, as tags são usadas aos pares, porque elas devem delimitar uma porção de texto.
Nesse caso uma mesma tag tem duas variantes : a primeira tag é posicionada no começo do texto a ser delimitado
e segunda tag é posicionada ao final dele; essa segunda tag têm o mesmo nome da primeira, mas é precedido
pelo caracter "/".
O principal uso das tags hTML é o fornecimento de uma estrutura geral ao documento.O documento todo é
delimitado pela tag <HTML> que contém duas grandes seções : o cabeçalho delimitado pela tag
<HEAD>, e o corpo,delimitado pela tag <BODY>.Na seção do cabeçalho estão as
informações a respeito do documento,como por exemplo a tag <TITLE> que especifica seu título, usado pelo
browser para nomear a janela onde o documento é processado.Na seção do corpo
temos o conteúdo do documento.
Algumas das tags mais usadas são as tags<A> e <IMG>, que são usadas
para construir hipertextos multimedia.
A tag <A> delimita uma porção de texto,
que é interpretado pelo browser como um ponto de partida (âncora) para uma referência hipertexto.
Ao clicar nessa porção de texto, o browser faz uma requisição HTTP para
que um recurso seja mostrado.A URL do novo recurso, que é o alvo da referência hipertexto,
é especificado no atributo href da tag âncora.
Já tag <IMG> adiciona aspectos de multimídia ao HTML.Ela insere uma imagem no documento atravé da URL especificada
usando o atributo src.
2.3 PHP e a arquitetura de três camadas
O PHP pertence a uma classe de linguagens conhecida como middleware.Essas linguagens atuam junto ao
servidor Web para interpretar as requisições vindas da internet, processá-las, interagir com
outros programas do servidor para satisfazer as requisições, e finalmente, indicar ao servidor Web
exatamente o quê servir ao browser do cliente.
Alguns exemplos de linguagens similares ao PHP são o ASP,
o Perl, e o ColdFusion.
A arquitetura de três camadas é uma arquitetura de software que tem como principal característica
a existência de uma camada intermediária entre o cliente e a camada de dados, que centraliza os serviços do middleware
e a lógica de negócios da aplicação.A arquitetura de três camadas foi proposta como alternativa
à arquitetura de duas camadas no qual os programas cliente interagiam diretamente com o sistema de gerenciamento de banco
de dados ao fazer as queries, receber os resultados delas, e processá-las para serem apresentadas ao usuário.
A arquitetura de três camadas oferece um grau de escalabilidade maior que a arquitetura de duas camadas devido à
melhor distribuição e utilização da rede e a capacidade ilimitada para replicação e
distribuição de dados que a camada intermediária proporciona.
Uma característica distintiva dos servidores de aplicação Web (que são pertencentes
a camada intermediária) é a adoção de componentes orientados a objetos como elementos
atômicos da programação e execução da aplicação, e a consequente adoção
de protocolos de distribuição baseados em objetos, como por exemplo o SOAP (Simple Object Access Protocol).
2.4 Banco de Dados Relacional e SQL
O princípio da tecnologia relacional são os dados formatados em tabelas consistindo de linhas e colunas.Cada tabela
guarda os "fatos" sobre um determinado conceito do domínio de uma aplicação .
Para identificar de forma única os "fatos" guardados numa tabela é preciso definir um grupo
de colunas que formem uma chave dessa tabela.Essa definição implica que duas colunas não
podem coexistir numa mesma tabela se tiverem valores coincidentes para todas as colunas da chave.Assim,
a chave da tabela provê uma identidade única a cada uma das linhas da tabela.A noção de
chave é central no banco de dados relacional porque permite a expressão de relações
semânticas entre objetos de um doínio de aplicação.
A Structured Query Language (SQL) é a mais popular linguagem para extrair e manipular informações guardadas
em tabelas relacionais.O SQL oferece as declarações, SELECT, INSERT, DELETE e UPDATE para extrair a
informação desejada, inserir, apagar e mudar o conteúdo do banco de dados.
Uma query SQL pode ser feita diretamente pelo usuário usando uma interface gráfica dedicada.
Entretanto, tal uso é raro e as queries são normalmente colocadas dentro dos programas, que por sua vez
, interagem com a base de dados para extrair ou mudar seu conteúdo de acordo com lógica de negócios
da aplicação.A interação entre um programa externo e um processador de queries
de uma base de dados acontece dentro da Application Programming Interface (API) da base de dados, que oferece
procedimentos para enviar as queries para a base de dados e trazer as respostas delas.
2.5 Sessões:
Uma aplicação comum para PHP é o gerenciamento de sessões, uma vez que a
Web não guarda estados.
O gerenciamento de sessões permite identificar um usuário e tornar as informações a
seu respeito disponíveis.
Cada funcionário na fundação é identificado
por um número. A variável de sessão identifica os dados da sessão ( como email , departamento aonde o
funcionário atua, etc) daquele
funcionário toda vez que ele se loga na intranet.Com isso, o sistema filtra a qual grupo de usuário ele pertence,
que pode ser uma das três categorias a seguir (com diferentes permissões para agir) :
Solicitantes: terão permissão apenas para enviar solicitações de transportes.
Administradores : terão permissão para atribuir veículos, atender (liberar um carro) solicitações e status à solicitações.
Gestores : terão permissão para aprovar solicitações, emitir relatórios, atribuir status à solicitações e realizar consultas de solicitações.
3. Atividades Realizadas
3.1 Construção do Modelo de Dados
3.1.1 Levantamento dos requisitos do sistema - o Modelo Conceitual de Dados
Nesse modelo devemos representar os conceitos e características observadas em um dado ambiente,
voltando-nos simplesmente ao aspecto conceitual.Nesse modelo devemos ignorar quaisquer particularidades de implementação,
bem como desconsiderar qualquer preocupação com qual será o modo de implementação futura.
Nas reuniões iniciais, o objetivo foi discutir ao máximo e definir os eventos que
gostaríamos que estivessem comtemplados no sistema. Foi interessante observar que os colegas com mais
experiência, já possuindo o sistema antigo (com uso de papel) como referência de algo que não funcionava,
direcionavam a discussão para alternativas ao que ocorria de errado no sistema antigo.
Foram diversas reuniões não só com os menbros da equipe, mas também com os outros personagens que participam
do sistema: os funcionários do departamento de transportes-que cuidam da liberação dos carros, e, as chefias dos departamentos.
Ao final desse brainstorming, foi possivel levantar os
principais requisitos do sistema e chegar ao seu modelo conceitual :
- Solicitantes: terão permissão apenas para enviar solicitações de transportes.
- Administradores : terão permissão para atribuir veículos e status à solicitações, e ainda, atender solicitações (= liberar um carro).
- Gestores : terão permissão para aprovar solicitações, emitir relatórios, atribuir status à solicitações e realizar consultas de solicitações.
- Inclusão de Solicitação
O usuário solicitante incluirá uma solicitação de transporte para os passageiros utilizando o
formulário na intranet e informando os campos obrigatórios.No momento da inclusão o sistema agregará
à solicitação mais alguns campos ligados ao solicitante.
- Cancelamento de Solicitação
O administrador e o gestor poderão efetuar o cancelamento de uma solicitação.
- Baixa de Solicitação
O administrador atenderá à solicitação e no momento de liberação do veículo,
mudará o status da solicitação.O sistema por sua vez completará os campos necessários e
finalizará a solicitação.
- Consultas e Relatórios
O gestor poderá realizar consultas e emitir relatórios através do levantamento de dados nas tabelas.
- Agrupamento de Solicitações
As solicitações que se referirem a um mesmo endereço ou destino podem ser agrupadas, respeitando as
limitações do veículo e das circunstâncias.Será disponibilizado um botão "Agrupar" e
"Desagrupar" para que o administrador de transporte agrupe ou desagrupe uma solicitação existente à atual.
Neste momento o status daquela passa a ser "agrupada".
A operação pode ser repetida muitas vezes de modo que uma solicitação tenha várias agrupadas
a ela.
3.1.2 O Modelo Lógico
A modelagem lógica é uma representação da modelagem conceitual em um modelo de BD.
A partir do modelo conceitual conseguimos identificar as entidades e os relacionamentos entre essas entidades.
Uma entidade é uma abstração de um fato do mundo real para o qual se deseja manter seus dados no BD.
Um relacionamento é uma abstração de uma associação entre entidades.
Estes conceitos foram utilizados na construção do diagrama ER do Sistema de Solicitação de Transportes:
3.1.3 O Modelo Físico
3.1.3.1 Origem dos Dados
Algumas tabelas s ão vinculadas a sistemas já estabelecidos na fundação: um dos interesses
é a futura integração do nosso sistema com outros sistemas já em produção.
Tb_Solicitacao : inclusão manual pelo solicitante
Tb_Solicitante: Sistema RH
Tb_CCusto: Sistema Controladoria
Tb_Superintendencia: Sistema Controladoria
Tb_Veiculos: Sistema SISTEF
Tb_Destino: Inclusão manual pelo solicitante
TB_Motorista: Sistema SISTEF
A partir do modelo lógico conseguimos obter o modelo físico que é um modelo de implementação
de banco de dados, pois temos definido quais tabelas serão construídas, com que chaves primárias (PK), com quais
campos,
qual será o tipo de dado do campo (inteiro, longint, char, string, etc),
o tamanho atribuído a esses campos,além de termos definido elementos como as
triggers e constraints, que representam as restrições de integridade dessas tabelas.
Isto pode ser visualizado no diagrama físico do Sistema de Solicitação de Transportes a seguir:
3.2 Engenharia de Software
O paradigma de engenharia de software que adotamos foi uma mistura do modelo da prototipação e do modelo espiral.
Nós tínhamos como
meta construir um protótipo do sistema para funcionar primeiramente com um universo restrito de usuários
(os jornalistas da Gazeta Esportiva) e que mais tarde seria expandido para todos os departamentos.
A prototipação é um processo que capacita o desenvolvedor a criar um modelo do software que será
implementado.Uma das formas que o modelo pode assumir é a de um programa que executa parte ou toda a função
desejada, mas que tem outras características que serão melhoradas em um novo esforço de desenvolvimento.
A sequência de eventos para o paradigma de prototipação é:
- Coleta dos requisitos: o desenvolvedor e cliente reunem-se e definem os objetivos globais para o software, identificam
as exigências conhecidas e esboçam as áreas em que uma definição adicional é
obrigatória
- Projeto rápido: ocorre então a elaboração de um projeto rápido que concentra-se na
representação daqueles aspectos do software que serão visíveis ao usuário (isto é
abordagens de entrada e formatos de saída).
- Construção do protótipo: o projeto rápido leva à construção do protótipo que
é avaliado pelo cliente/usuário e é usado para refinar os requisitos para o software a ser desenvolvido
- Refinamento do protótipo
- Engenharia do produto
Ao final do processo o protótipo é descartado (ou parte dele) e o software real é projetado,levando-se em conta
a qualidade e a manutenibildiade.
O modelo espiral define quatro importantes atividades (correspondem a uma volta na espiral):
- Planejamento: determinação dos objetivos, alternativas e restrições
- Análise de Riscos: análise das alternativas e identificação /resolução dos riscos
- Engenharia: desenvolvimento do produto no "nível seguinte"
- Avaliação feita pelo cliente: avaliação dos resultados da engenharia
Ao se chegar aqui é feita uma avaliação dos riscos (baseado na reação do cliente)
para decidir se prossegue-se ou não numa nova "iteração ao redor da espiral", isto é, para que versões progressivamente
mais completas do software sejam construídas, ou, se os riscos forem muito grandes, para que o projeto seja encerrado.
Dentro dessa metodologia de trabalho as atividades que realizei foram:
Levantamento dos requisitos
Construcao das classes
Construcao do banco de dados e programação da camada responsável pela lógica de negócios
Testes
Liberação do sistema a um público restrito e manutenção
Sistema disponibilizado ao uso geral
4.Resultados e Produtos Obtidos
Após a fase de testes no sistema piloto, experimentado por um grupo restrito de funcionários-alguns jornalistas- durante cerca
de um mês, quando corrigimos alguns erros que não haviam sido percebidos, finalmente o sistema foi liberado
para uso nos outros departamentos.Esse período foi bastante proveitoso pela contribuição que as pessoas de fora do grupo de
desenvolvimento deram ao sistema fazendo observações pertinentes de usuário final, muitas vezes imperceptíveis aos
programadores.
4.1 Algumas telas do sistema:
formulário da solicitação : faz a inclusão da solicitação no sistema.Ao preenchê-la e clicar no
botão "enviar" o sistema fará as consistências necessárias e emitirá mensagem adequada.
Aprovação : o Gestor (Aprovador) possui uma tela de consulta com a listagem das solicitações pertinentes (em vermelho),
isto é, essas solicitações são de funcionários do departamento (centro de custo) no qual ele é chefe. Cada solicitação
possui um link "Detalhes" que traz uma tela com as informações dessa solicitação, e os botões "Aprovar" e "Reprovar".
Apenas ao clicar no botão "Aprovar" , a solicitação tornar-se visível ao departamento de transporte. Nesse momento o sistema gravará
os dados do aprovador e a data/hora da aprovação . Ao clicar no botão "Reprovar" , a solicitação vai para a listagem de baixo
das solicitações canceladas (em azul) onde ficarão por um período aguardando serem aprovadas ou não (serão
eliminadas nesse último caso).
Ao clicar em 'Detalhes', o gestor pode ver a solicitação do seu funcionário com mais detalhes:
Atendimento : o usuário administrador(do depto de transportes) possui uma tela de consulta com a listagem de todas as solicitações
aprovadas pela gerência.Ao clicar numa delas, ele pode ver as informações detalhadas e os botões "cancelar",
"autoriza impressão",
"atender" e "baixar"(=concluir).Esses botões ficam habilitados segundo o fluxo do diagrama de estados do item 3.3. Após a impressão
da solicitação o veículo estará pronto para a saída.O hodômetro de saída é preenchido pelo administrador
na tela dessa solicitação
Ao clicar em "Detalhes", ele visualiza uma tela com informações mais específicas da solicitação escolhida :
Retorno do veículo : Após retornar com o veículo, o motorista preenche o hodômetro de retorno e entrega
a solicitação impressa ao usuário administrador que processará a baixa.Para isso, ele escolherá a
solicitação , preencherá os dados restantes e fechará a solicitação .
A solicitação impressa
4.2 Diagrama do fluxo de estados de uma solicitação :
O percurso típico de uma solicitação no sistema:
O usuário preenche e submete uma solicitação de transporte,
a solicitação fica na espera do chefe do seu departamento aprová-la (o que ele faz ao clicar no botão 'Aprovar').
Em seguida,
o administrador do departamento de transportes muda o
status da solicitação para atendida ao liberar um carro (para isso, tendo clicado no botão
ATENDER).
Quando o carro retorna da viagem, o administrador muda o status da solicitação para
concluída ao clicar no botão BAIXAR.Ele pode ainda agrupar uma solicitação a outra, caso verifique que as duas solicitações pedem carros para ir a uma mesma localidade.
A cada mudança no status da solicitação é emitido um email ao usuário que iniciou a solicitação
avisando-o do estado em que está sua
solicitação.Ele recebe email após a sua solicitação ter sido criada, aprovada,atendida,concluída(=baixada)
e cancelada(= reprovada pelo gestor).
5.Conclusões
Durante as atividades na fundação pude perceber o quanto o conhecimento adquirido no ime me deu meios para focar no que era mais
relevante no decorrer de um projeto. Creio que sem isso poderia ter ficado perdendo horas em detalhes sem grande importância, o que seria
penoso dado que os prazos são curtos.
Relatório Subjetivo :
Desafios e frustrações encontrados:
Um desafio foi manter o equilíbrio entre a rotina de estudos no ime e o ritmo acelerado
no trabalho numa empresa, porque ambas exigem muita dedicação.
Uma frustração que senti foi o quanto a exigência em cumprir os prazos pode afetar na
produção de um software de qualidade.Muitas vezes, para o cliente era mais interessante
produzir uma solução o mais depressa possível e era difícil ter um
período para planejar o melhor sistema .
lista das disciplinas cursadas no BCC mais relevantes para o trabalho:
Considero estas como as disciplinas que mais ajudaram na elaboração dos meus projetos
pela boa base conceitual que me forneceram:
MAC 122 - Princípios de Desenvolvimento de Algoritmos
MAC 211 e MAC242 - Laboratório de Programação I e II
MAC323 - Estrutura de Dados
MAC426 - Sistemas de Banco de Dados
MAC441 - Programação Orientado a Objetos
MAC332 - Engenharia de Software
Interação com menbros da equipe que tenha agido como mentores:
O ambiente de trabalho foi bastante cordial e os menbros da minha equipe foram sempre muito abertos
a responderem minhas dúvidas.Tive bastante liberdade para colocar minhas idéias e também
aprendi bastante ouvindo suas experiências na empresa e observando a sua maneira de resolver problemas.
A pró-atividade era bastante incentivada e reconhecida.E também pelo fato de estar numa empresa
do ramo da comunicação me fez expandir minha visão de mundo ao adaptar
meus conhecimentos a serviço dela.
Diferenças entre a forma de cooperação com os colegas do BCC nas tarefas em grupo
das disciplinas e a forma de trabalho em conjunto na empresa:
Nos trabalhos em grupo do ime mesmo com a
divisão de tarefas precisamos estar a par de todas as etapas do projeto nos mínimos
detalhes, pois seremos cobrados quanto a isso nas provas, o que considero positivo.
Dentro de um projeto na empresa pelo fato de sermos cobrados com os prazos estabelecidos com o cliente
muitas vezes precisamos nos dividir de acordo com nossas especialidades, para otimizarmos o tempo.
E também era preciso aprender rápido para se adaptar a isso.
Observações sobre a aplicação de conceitos estudados nos cursos no contexto
prático de aplicações reais:
Acredito que todo o conhecimento aprendido no ime tenha contribuído de alguma forma
no desenvolvimento externo ao ime, e o fato do curso ser acadêmico e pouco adaptado a realidade
do mercado leva a que tenhamos
que realmente construir à nossa maneira alguma utlidade prática no que foi visto.
A vantagem de enxergar conceitualmente é que não precisamos nos prender aos detalhes
de uma ou outra tecnologia, apenas adaptamos nosso conhecimento a realidade dela.
Se o aluno fosse continuar atuando na área em que exerceu o estágio,
que passos tomaria para aprimorar os conhecimentos
técnicos/metodológicos/comerciais/científicos/etc relevantes para esta atividade?
Continuaria a estudar as novas tecnologias sem perder do foco a abordagem conceitual e matemática
que ganhamos no curso.
Agradecimentos:
Ao meu supervisor Professor Gubi, ao Professor Carlinhos, a minha família e amigos.
Bibliografia
Atkinson,Leon; Suraski,Zeev.Core PHP Programming,2004,Prentice Hall
Castagnetto, Jesus; Schumman,Sascha; Rawat,Harish; Scollo,Chris. Professional PHP Programming,2001, Makron Books
Ceri,Stefano;Fraternalli,Piero;Bongio,Aldo;Brambilia,Marco;Comai,Sara;Matera,Maristella.Designing Data Intensive
Web Applications,2003,Morgan Kaufmann Publishers
Páginas da Internet:
http://www.php.net
http://www.oracle.com
http://www.smarty.net