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 :
    1. Solicitantes: terão permissão apenas para enviar solicitações de transportes.
    2. Administradores : terão permissão para atribuir veículos e status à solicitações, e ainda, atender solicitações (= liberar um carro).
    3. Gestores : terão permissão para aprovar solicitações, emitir relatórios, atribuir status à solicitações e realizar consultas de solicitações.
    1. Inclusão de Solicitação

    2. 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.

    3. Cancelamento de Solicitação

    4. O administrador e o gestor poderão efetuar o cancelamento de uma solicitação.

    5. Baixa de Solicitação

    6. 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.

    7. Consultas e Relatórios

    8. O gestor poderá realizar consultas e emitir relatórios através do levantamento de dados nas tabelas.

    9. Agrupamento de Solicitações

    10. 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 é:
    1. 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
    2. 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).
    3. 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
    4. Refinamento do protótipo
    5. 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):
    1. Planejamento: determinação dos objetivos, alternativas e restrições
    2. Análise de Riscos: análise das alternativas e identificação /resolução dos riscos
    3. Engenharia: desenvolvimento do produto no "nível seguinte"
    4. 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