UNIVERSIDADE DO SUL DE SANTA CATARINA TAYSE CASCAES ARÊAS

Transcrição

1 UNIVERSIDADE DO SUL DE SANTA CATARINA TAYSE CASCAES ARÊAS DESENVOLVIMENTO DE UM GERADOR DE APLICAÇÕES WEB EM PHP QUE UTILIZAM OS FRAMEWORKS ZEND FRAMEWORK E DOCTRINE Palhoça 2011

2 TAYSE CASCAES ARÊAS DESENVOLVIMENTO DE UM GERADOR DE APLICAÇÕES WEB EM PHP QUE UTILIZAM OS FRAMEWORKS ZEND FRAMEWORK E DOCTRINE Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Sistemas de Informação, da Universidade do Sul de Santa Catarina, como requisito parcial para obtenção do título de Bacharel em Sistemas de Informação. Orientador: Prof. Ricardo Villarroel Dávalos, Dr. Palhoça 2011

3 TAYSE CASCAES ARÊAS DESENVOLVIMENTO DE UM GERADOR DE APLICAÇÕES WEB EM PHP QUE UTILIZAM OS FRAMEWORKS ZEND FRAMEWORK E DOCTRINE Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do título de Bacharel em Sistemas de Informação e aprovado em sua forma final pelo Curso de Sistemas de Informação, da Universidade do Sul de Santa Catarina. Palhoça, 30 de junho de Professor e orientador Ricardo Villarroel Dávalos, Dr. Universidade do Sul de Santa Catarina Professor Aran Bey Tcholakian Morales, Dr. Eng. Universidade do Sul de Santa Catarina Fernanda Laurentino Inácio, Bel. Serviço Nacional de Aprendizagem Industrial

4 RESUMO A web atende necessidades de diversos públicos, fazendo com que os desenvolvedores precisem estar atentos às regras de negócio específicas de cada sistema. Para ajudar nesse propósito, existem os frameworks, que subtraem do programador o trabalho de codificar funcionalidades comuns entre diversas aplicações. Uma das finalidades deste trabalho de conclusão de curso é colaborar com a redução do tempo de desenvolvimento de aplicações web que utilizem os frameworks Zend Framework (ZF) e Doctrine integrados. Esta proposta também visa a apoiar o aprendizado dessas tecnologias e, para que isso aconteça, encontra-se disponível num repositório de software livre para que possa ser adotada por profissionais interessados. Este trabalho está fundamentado teoricamente em materiais já publicados e, para tal, foi realizada uma pesquisa bibliográfica sobre geradores de aplicações, frameworks e, especificamente, sobre os frameworks ZF e Doctrine. O sistema tem a finalidade de gerar aplicações que trabalhem essencialmente com o gerenciamento de registros. As tecnologias utilizadas para o desenvolvimento do sistema foram: linguagem PHP, frameworks ZF e Doctrine e servidor Apache. A validação do sistema foi realizada a partir da geração de uma aplicação que utilizava o banco de dados MySQL, embora o sistema aceite outros. Para interação do usuário com o sistema gerador e a aplicação gerada, pode ser utilizado qualquer navegador de internet. Algumas contribuições deste trabalho foram: a agilidade na geração de aplicações, uma descrição sintética e organizada das funcionalidades dos frameworks utilizados, proporcionando aos leitores uma visão geral dos mesmos, e a geração de aplicações com código padronizado. Algumas características que se destacam no sistema são: ser um gerador de código que trabalha com dois frameworks juntos e sua interação com o usuário ser feita através de uma interface gráfica simples. Palavras-chave: Desenvolvimento web. Gerador de código. Frameworks.

5 ABSTRACT The web meets needs of different audiences, thus the developers need to be aware of the specific business rules for each system. To help in this matter, frameworks facilitate the work of programmers by decoding common functionalities across various applications. One of the purposes of completion of course work is to help reduce the development time of web applications using frameworks Zend Framework (ZF) and Doctrine integrated. The proposal also aims to support the learning of these technologies and, for that to happen, is available in a repository of free software that can be adopted by interested professionals. This work is theoretically based on material already published and to this end, we performed a literature search on generating applications, frameworks, and specifically on the frameworks ZF and Doctrine. The system aims to create applications that work primarily with records management. The technologies used for developing the system were: PHP, frameworks, ZF and Server Apache. The system validation was performed from the generation of an application using the MySQL database, although the system will accept others. For user interaction with the system generator and the generated application, you can use any web browser. Some contributions of this work were: to agility the generation of applications, and organized a concise description of the features of the frameworks used, giving readers an overview of these, and generating applications defaults code. Some characteristics that stand out in the system are: to be a code generator that works with two frameworks together and their interaction with the user is done through a simple graphical interface. Keywords: Web development. Code generator. Frameworks.

6 LISTA DE ILUSTRAÇÕES Figura 1 Aplicação gerada com o phpmyedit e dependente de seu gerador Figura 2 Tela de configuração da conexão com o banco de dados, do PHP-MySQL Wizard Figura 3 Tela de configuração das funcionalidades a serem geradas pelo PHP-MySQL Wizard Figura 4 Inversão de controle existente na aplicação de um framework...22 Fluxograma 1 Etapas metodológicas do trabalho...29 Figura 5 Proposta da solução...30 Figura 6 Estrutura tecnológica da proposta Figura 7 Diagramas definidos pela UML...34 Figura 8 Requisitos funcionais Quadro 1 Descrição dos requisitos funcionais Figura 9 Requisitos não funcionais Quadro 2 Descrição dos requisitos não funcionais...38 Diagrama 1 Diagrama de Atividades - Fluxo entre Usuário e Sistema...40 Diagrama 2 Diagrama de Atividades - Fluxo do Sistema Figura 10 Atores do sistema Quadro 3 Descritivo dos atores do sistema Diagrama 3 Diagrama de Casos de Uso Quadro 4 Descrição dos casos de uso...46 Diagrama 4 Diagrama de Sequência - Cadastrar Aplicação...48 Diagrama 5 Diagrama de Sequência - Gerar aplicação...49 Diagrama 6 Diagrama de Classes do sistema...51 Figura 11 Logotipos das ferramentas utilizadas...52 Figura 12 Componentes que trabalham com MVC...54 Figura 13 Ferramentas e componentes que trabalham com RAD...55 Figura 14 Componentes que trabalham com base de dados...55 Figura 15 Componentes que trabalham com internacionalização (i18n) e localização (l10n) Figura 16 Componentes que trabalham com autenticação, autorização de acesso e gerenciamento de sessão...56

7 Figura 17 Componentes que trabalham com web e web services...57 Figura 18 Componentes que trabalham com , formatos e pesquisa Figura 19 Componentes para infraestrutura básica de aplicações...58 Diagrama 7 Modelo E-R da aplicação a ser gerada...61 Figura 20 Tela do gerador: configurações iniciais da aplicação Figura 21 Tela do gerador: opções para geração do CRUD...63 Figura 22 Tela do gerador: opções para geração do CRUD (continuação)...64 Figura 23 Tela gerada pelo sistema: Lista de produtos Figura 24 Tela gerada pelo sistema: Editar produto...66 Figura 25 Tela gerada pelo sistema: Excluir produto...67 Figura 26 Página inicial do projeto no SourceForge Figura 27 Diretórios e arquivos publicados no SourceForge....70

8 LISTA DE SIGLAS CASE Computer-Aided Software Enginnering CRUD Create, Retrieve, Update e Delete DBAL Database Abstraction Layer DQL Doctrine Query Language EA Enterprise Architect HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol MER Modelo Entidade-Relacionamento MVC Model, View, Controller ORM Object Relational Mapper PDF Portable Document Format PDO PHP Data Objects PHP PHP Hypertext Preprocessor POO Programação Orientada a Objetos SGBD Sistema de Gerenciamento de Banco de Dados SQL Structured Query Language TI Tecnologia da Informação UML Unified Modeling Language ZF Zend Framework

9 SUMÁRIO 1 INTRODUÇÃO O PROBLEMA OBJETIVOS Objetivo geral Objetivos específicos JUSTIFICATIVA ESTRUTURA DA MONOGRAFIA REVISÃO BIBLIOGRÁFICA REUTILIZAÇÃO DE CÓDIGO GERADORES DE APLICAÇÕES GERADORES DE CÓDIGO PARA PHP FRAMEWORKS Definição Classificação Vantagens Desvantagens Instanciação FRAMEWORKS PARA PHP Zend Framework Vantagens Desvantagens Doctrine CONSIDERAÇÕES FINAIS DO CAPÍTULO MÉTODO CARACTERIZAÇÃO DO TIPO DE PESQUISA ETAPAS METODOLÓGICAS PROPOSTA DA SOLUÇÃO DELIMITAÇÕES CONSIDERAÇÕES FINAIS DO CAPÍTULO MODELAGEM DO SISTEMA LINGUAGEM DE MODELAGEM UNIFICADA (UML)...33

10 4.2 REQUISITOS DIAGRAMAS DE ATIVIDADES DIAGRAMA DE CASOS DE USO DIAGRAMAS DE SEQUÊNCIA DIAGRAMA DE CLASSES CONSIDERAÇÕES FINAIS DO CAPÍTULO DESENVOLVIMENTO TECNOLOGIAS E FERRAMENTAS Linguagem PHP Frameworks utilizados Componentes do framework ZF Componentes do framework Doctrine Servidor de aplicações Ferramenta CASE para modelagem HISTÓRICO DE DESENVOLVIMENTO APRESENTAÇÃO E VALIDAÇÃO DO SISTEMA Avaliação do sistema por voluntário externo DISPONIBILIZAÇÃO DA FERRAMENTA CONSIDERAÇÕES FINAIS DO CAPÍTULO CONCLUSÕES E TRABALHOS FUTUROS CONCLUSÕES FINAIS TRABALHOS FUTUROS...74 REFERÊNCIAS...75

11 10 1 INTRODUÇÃO É inegável a grande importância da internet na sociedade atual, pois ela está presente no relacionamento entre pessoas nos negócios, no entretenimento, na educação e na comunicação de um modo geral. O mercado da internet tornou-se muito atrativo para diversos profissionais, tanto os próprios profissionais de Tecnologia da Informação (TI), como instituições e profissionais autônomos, que desejam divulgar seus serviços e se relacionar com clientes de modo rápido e relativamente barato. Como a web atende necessidades de diversos públicos, o desenvolvedor do software deve atentar às regras de negócio que cada sistema deve atender. Para esse propósito, existem ferramentas que auxiliam os programadores a desenvolver aplicações de forma mais rápida, com qualidade e padronização de código. Os chamados frameworks são conjuntos de classes codificadas, em determinada linguagem de programação, com o propósito de subtrair do programador o trabalho de codificar funcionalidades comuns entre diversas aplicações. A fim de também colaborar com o mundo do desenvolvimento web, este projeto vem a desenvolver um sistema que faça a geração automática de aplicações em linguagem PHP que utilizem o padrão modelo, visão, controlador model, view, controller (MVC) juntamente com os frameworks Zend Framework (ZF) e Doctrine. 1.1 O PROBLEMA Embora a utilização de frameworks auxilie muito o desenvolvimento de aplicações, os desenvolvedores, ainda, precisam criar classes de código, utilizando esses frameworks. Classes essas que, muitas vezes, repetem-se, tendo uma base muito parecida e com os mesmos objetivos, fazendo com que o programador faça cópia de código de uma classe para outra e altere as informações pertinentes a cada uma. Esse problema ocorre, principalmente, com aplicações que possuem muitas telas de cadastro: formulário, pesquisa e listagem de registros que seguem o mesmo padrão. O

12 11 desenvolvedor perde algum tempo montando essa estrutura, quando poderia estar se ocupando com regras de negócio mais específicas do sistema. Além da perda de tempo, um rival das empresas de software é a falta de padronização nos códigos das aplicações, o que dificulta a manutenção de software, sendo por parte do próprio desenvolvedor ou por outros, tendo custo de aprendizagem para compreender a arquitetura de determinado projeto. (LISBOA, 2008). Cada empresa pode adotar os padrões de codificação que preferir. No entanto, seria menos custoso, se um padrão fosse conhecido pela comunidade e um futuro colaborador já o utilizasse, trazendo, também, para a empresa o benefício de não precisar arquitetar um novo padrão, pois ele já estaria definido. 1.2 OBJETIVOS Objetivo geral Framework e Doctrine. Desenvolver um gerador de aplicações em PHP que utilizam os frameworks Zend Objetivos específicos Este projeto tem como objetivos específicos, os seguintes: a) facilitar o desenvolvimento de aplicações web orientadas a banco de dados, para profissionais que trabalham com as ferramentas apresentadas, criando aplicações a partir de uma estrutura previamente definida; b) facilitar a aprendizagem para iniciantes nos frameworks apresentados, para que tenham mais facilidade em desenvolver aplicações nessas tecnologias; c) disponibilizar uma arquitetura que possa ser adotada como padrão para projetos desenvolvidos com as citadas tecnologias; d) disponibilizar a ferramenta com código aberto para uso e colaboração da comunidade PHP.

13 JUSTIFICATIVA Este projeto tem sua importância para a comunidade de desenvolvedores PHP que utiliza ou deseja utilizar os frameworks ZF e Doctrine, tornando mais rápido o desenvolvimento básico ou inicial de aplicações baseadas em registros em bancos de dados. A idéia surgiu da necessidade de uma equipe de desenvolvimento web, que sentiu o problema de estar se ocupando com processos básicos de criação de cadastros simples, arquitetura e configuração da aplicação, enquanto poderia estar desenvolvendo regras de negócio mais complexas e específicas da aplicação. O projeto vem a atender a necessidade de pessoas que procuram entender como funcionam esses frameworks e sugerir uma arquitetura para suas aplicações. Por justificativa final, o projeto é fonte de estudo e de pesquisa tanto para instituições de setor privado ou público, como para estudantes e profissionais autônomos, que poderão economizar tempo com aprendizagem e planejamento de uma arquitetura para suas aplicações web em PHP. Esses casos são encontrados em fóruns e listas de discussão na internet, como no grupo PHPBR, do Google Groups (2010), em que um iniciante em ZF tem dificuldade em utilizar o framework e de compreender o padrão MVC e suas melhores práticas. 1.4 ESTRUTURA DA MONOGRAFIA Capítulo 1: Introdução A Introdução orienta o leitor quanto ao assunto abordado, o problema que se propõe resolver, os objetivos do trabalho e a justificativa para o desenvolvimento do mesmo. Capítulo 2: Revisão bibliográfica No capítulo 2 apresentam-se os conceitos de reutilização de código, geradores de aplicações e frameworks, com fundamentação teórica a partir de alguns autores. Neste capítulo, também, serão comentados os frameworks utilizados no projeto: ZF e Doctrine.

14 13 Capítulo 3: Método Neste capítulo, é definido o método de pesquisa que será utilizado, assim como a proposta e as definições do tipo de pesquisa. Capítulo 4: Modelagem do sistema O capítulo 4 apresenta os diagramas UML construídos para a modelagem da aplicação. Capítulo 5: Desenvolvimento Neste capítulo, serão descritos os recursos tecnológicos utilizados para a modelagem e o desenvolvimento da aplicação. O capítulo também se destina a fazer uma demonstração do sistema, utilizando-o em um caso fictício e a mostrar os resultados de uma avaliação do sistema, feita por um voluntário. Capítulo 6: Conclusões e trabalhos futuros Neste capítulo, serão apresentadas conclusões sobre o estudo feito, os resultados apresentados e considerações finais sobre o trabalho desenvolvido.

15 14 2 REVISÃO BIBLIOGRÁFICA Este capítulo apresenta uma pesquisa bibliográfica, visando a fundamentar, teoricamente, a proposta apresentada neste projeto. Serão abordados os assuntos: reutilização de código, geradores de aplicações e frameworks. 2.1 REUTILIZAÇÃO DE CÓDIGO Segundo Oliveira (2001), a importância da reutilização de código não é algo novo na área de desenvolvimento de software. Há 40 anos, passou-se a perceber as vantagens dessa técnica, que influencia na qualidade do produto e no rendimento dos profissionais, devido à reaplicação de conhecimento anteriormente adquirido, em um novo trabalho, evitando esforço recorrente. O autor cita alguns benefícios que essa abordagem traz: a) redução do tempo e do custo de desenvolvimento; b) diminuição de erros; c) padronização de código; d) formação de especialistas em domínios específicos e em reutilização de código; e) aumento da capacidade de produção, devido à redução do tempo de desenvolvimento. Um modelo de reutilização que está se tornando muito comum são as técnicas baseadas em sistemas gerativos. Essas técnicas são baseadas no conceito de programas que geram programas (OLIVEIRA, 2001, p. 19), dentro de uma especificação pré-estabelecida. Dentre as técnicas de sistemas gerativos citadas por Oliveira (2001), estão os Geradores de Aplicações, tema e objetivo principal desta monografia.

16 GERADORES DE APLICAÇÕES Oliveira (2001) explica que os geradores de aplicações (que também podem ser chamados de geradores de código) são softwares que auxiliam na construção de muitos outros softwares de uma mesma família, através de uma especificação inicial, automatizando grande parte do processo de codificação e agregando mais agilidade e facilidade na construção do produto, que o modo de implementação tradicional. Conforme as palavras do autor, são sistemas onde a aplicação final é gerada a partir de um padrão, definido internamente pelo gerador. (OLIVEIRA, 2001, p. 19). Utilizar um gerador na codificação de uma aplicação pode atribuir mais rapidez e menor índice de falhas causadas por erros humanos, pois os geradores produzem código de forma sistemática e mais segura. (SHIMABUKURO JUNIOR, 2006). Outra vantagem facilmente percebida é a padronização de código, que é um ponto forte ao se analisar a qualidade do software. Havendo um estilo único de programação, reduzse o tempo de aprendizado do software, se o mesmo for escrito por diversos programadores, pois todos compreenderão o que outros codificaram. Assim, há mais facilidade na compreensão do código para futuras manutenções. Além disso, o código gerado automaticamente sofre um aumento de qualidade com o tempo, pois os erros encontrados podem ser corrigidos na aplicação geradora e replicados para as aplicações a serem geradas. Com os geradores, em pouquíssimo tempo, uma grande quantidade de código de qualidade é criada, poupando horas de trabalho do desenvolvedor, que podem ser utilizadas em tarefas que exijam mais criatividade. Existem geradores de código que trabalham a partir de artefatos de modelagem, outros podem trabalhar orientados a banco de dados. Um exemplo muito bom de gerador de código são as ferramentas de Engenharia de Software Auxiliada por Computador Computer- Aided Software Enginnering (CASE). Essas ferramentas auxiliam os profissionais que trabalham diretamente com o desenvolvimento de sistemas, seja em fase de análise, modelagem ou codificação. Algumas ferramentas CASE tem a finalidade de facilitar a codificação feita pelo programador, são ferramentas de codificação, chamadas de Lower CASE. Outras auxiliam na análise do projeto, oferecendo um ambiente para modelagem de diagramas e artefatos diversos, chamadas de Upper CASE. Existem, ainda, as ferramentas

17 16 que possuem as duas funções, denominadas Integrated CASE, que permitem modelar o projeto e, através dos artefatos, geram parte do código da aplicação de forma automática. Para alguns profissionais, existe ainda uma barreira cultural quanto ao uso de geradores. Especialmente, entre profissionais experientes, é importante desenvolver a consciência de que geradores de código não são apenas para iniciantes. Eles podem ajudar, consideravelmente, a aumentar a produtividade e poupar trabalhos exaustivos. 2.3 GERADORES DE CÓDIGO PARA PHP A maioria dos geradores de código para PHP existentes faz a geração de código a partir de um banco de dados previamente construído, recuperando as informações estruturais através de uma conexão. Basicamente, existem dois tipos de geradores de código em PHP: ativo e passivo. No modelo ativo, depois de criada, a aplicação continua necessitando do gerador para seu funcionamento, fazendo-lhe chamadas. No modelo passivo, o gerador cria o código inicial da aplicação e, depois dessa etapa, a implementação de novas funcionalidades e a manutenção do funcionamento do software passa a ser de responsabilidade do desenvolvedor da aplicação final, o gerador não é mais necessário. Um exemplo de gerador de código PHP do tipo ativo é o phpmyedit, software livre disponível no site A aplicação é usuária constante do gerador, fazendo-lhe chamadas e adaptando, através de parâmetros, o que for necessário. Algo bastante semelhante ao conceito de framework. O phpmyedit é preparado para trabalhar apenas com funções do banco de dados MySQL. A Figura 1 apresenta uma aplicação que utiliza o gerador. A página apresentada é formada por chamadas ao gerador, ou seja, o código não pertence à aplicação.

18 17 Figura 1 Aplicação gerada com o phpmyedit e dependente de seu gerador. Fonte: phpmyedit (2010). Como gerador do tipo passivo, um exemplo que pode ser apresentado é o PHP MySQL Wizard, que pertence à empresa SoftGalaxy, cujo site oficial se encontra em e é gratuito para testar. Esse software gera o aplicativo web em PHP, criando todo o código necessário para trabalhar com persistência de dados, de acordo com informações de um banco de dados MySQL, que deve ser indicado pelo usuário. Depois de gerada, a aplicação é independente do gerador, sendo possível, inclusive, desfazer-se dele. Seguem, abaixo, duas figuras que mostram a aplicação em funcionamento. Na Figura 2, fica visível como informar ao gerador os dados de conexão com o banco de dados que deve ser utilizado pela aplicação a ser gerada. A Figura 3 ilustra algumas opções referentes às funcionalidades a serem geradas, como adicionar, editar, visualizar e excluir registros, entre outras.

19 18 Figura 2 Tela de configuração da conexão com o banco de dados, do PHP-MySQL Wizard. Fonte: SoftGalaxy (2010). Figura 3 Tela de configuração das funcionalidades a serem geradas pelo PHP-MySQL Wizard. Fonte: SoftGalaxy (2010).

20 19 Para fim de esclarecimento, o gerador a ser desenvolvido neste trabalho utilizará o modelo passivo, em que a aplicação receberá o código produzido e ficará independente do gerador. 2.4 FRAMEWORKS A partir da necessidade de reutilização de código que a indústria de software passou a apresentar há algumas décadas, por problemas de confiabilidade, flexibilidade e custo, começaram a surgir os frameworks, assunto que será abordado nos próximos itens Definição Segundo Melo e Nascimento (2007, p. 236), framework nada mais é do que um tipo especial de aplicativo, que oferece um conjunto básico de ferramentas e subsistemas que automatizam grande parte dos serviços que precisam ser implantados nos sistemas para usuários finais. Partindo para uma definição mais enxuta, Sauvé (2010) diz que um framework captura as funcionalidades comuns a várias aplicações, desde que tenham algo razoavelmente grande em comum. Complementando essa definição de framework, Johnson (1988, apud OLIVEIRA, 2001, p. 22) diz que um framework é um esqueleto de uma aplicação que deve ser parametrizado pelo desenvolvedor da aplicação. Um framework não é apenas uma biblioteca de classes, onde as classes são independentes umas das outras. No conceito de framework, as classes são ligadas entre si, trabalhando de forma colaborativa. (SAUVÉ, 2010). Assim, uma classe utiliza componentes de outra classe. Não sendo possível a adoção de apenas algumas classes, é preciso adotar todo o sistema de framework, ou módulos completos do mesmo e trabalhar sobre a sua estrutura.

21 Classificação Sauvé (2010) mostra que os frameworks são classificados a partir de duas dimensões: a) como o framework é usado; b) onde o framework é usado. Dependendo de como um framework é utilizado, Sauvé (2010) classifica-os nos seguintes tipos: a) inheritance-focused (remete à Herança): as funcionalidades do framework podem ser estendidas ou modificadas através da definição de subclasses com sobrescrita de métodos. Para isso, o reutilizador precisa ter profundo conhecimento de sua estrutura, bem como das colaborações dos objetos envolvidos. São comumente utilizados em conjunto com bibliotecas de componentes para facilitar o processo de instanciação. (OLIVEIRA, 2001, p. 29). Também conhecido como white-box; b) composition-focused (remete à Composição): o usuário do framework deve utilizar as funcionalidades já existentes, o funcionamento interno do framework não pode ser visto nem alterado. Também conhecido como blackbox; c) híbridos (ambos): junção dos dois tipos anteriores. O framework pode ser estendido e alterado, mas também contém funcionalidades prontas. Também conhecido como gray-box. Analisando onde o framework é utilizado, Sauvé (2010) classifica os frameworks quanto aos seguintes tipos: a) framework de suporte: trabalha em nível de sistema operacional, provendo serviços como acesso a arquivos e computação distribuída; b) framework de aplicação: encapsula conhecimento aplicável a uma vasta gama de aplicações, resolvendo parte dos problemas da mesma, sendo a outra parte a cargo do programador, que conhece as necessidades específicas da aplicação, relacionadas ao negócio;

22 21 c) framework de domínio: encapsula conhecimento aplicável a aplicações que pertençam a um domínio particular de problema, resolvendo grande parte das necessidades da aplicação, relativas ao próprio negócio Vantagens Segundo Melo e Nascimento (2007), todo sistema possui componentes comuns a outros, que são de uso padrão em uma família de aplicações, como restrições de acesso a usuários, utilização de funções de acesso a bancos de dados, leitura e escrita de arquivos, entre outros. Se o desenvolvedor optar pela utilização de um framework, não precisará ter o desgaste de criar tais componentes, sendo que estes estarão sujeitos a muitas falhas. Os autores ainda comentam que um framework é capaz de oferecer uma infra-estrutura completa para sustentação do sistema. (MELO; NASCIMENTO, 2007, p. 236). Com certeza, economiza-se muito trabalho ao adotar um bom framework. Tendo este enfoque, uma filosofia bastante utilizada na área de programação é: Não reinvente a roda, ou seja, se algo já está pronto, testado e validado por profissionais experientes e utilizado por muitos outros, é de bom senso que desenvolvedores de aplicações finais utilizem essas soluções prontas e possam se preocupar, quase que inteiramente, com as regras de negócio. Além disso, a adoção de um framework faz com que o programador adote um estilo mais legível e claro para manter seu código, uma vez que ele deve ser compatível com o modelo do framework escolhido. (MELO; NASCIMENTO, 2007, p. 237). Conforme Lisboa (2008, p. 16): Os frameworks de desenvolvimento (pelo menos os atuais), como parte de sua proposta, adotam a programação orientada a objetos e alguns padrões de projeto. Um dos padrões que merece maior destaque é o padrão MVC (Model, View, Controller), o qual sugere a divisão do projeto de software em camadas lógicas, de modo a separar as funcionalidades. Isso facilita gerenciar mudanças na aplicação e reaproveitar funcionalidades em outros projetos. Seguem alguns benefícios considerados essenciais nos frameworks, segundo Fayad (1999 apud OLIVEIRA, 2001): a) modularidade: o encapsulamento de detalhes de implementação feito pelo framework, através do uso de interfaces estáveis, torna o software mais modularizado e pode contribuir para o aumento da sua qualidade, uma vez que

23 22 o impacto das implementações são localizados, facilitando o entendimento e manutenção do código-fonte; b) reusabilidade: com a utilização de interfaces e componentes genéricos, os frameworks incentivam a reutilização de conhecimento; c) extensibilidade: frameworks são extensíveis desde que permitam a uma aplicação estender suas interfaces; d) inversão de controle: no contexto de framework, quem comanda o fluxo de controle é o artefato reutilizável, e não o artefato reutilizador. Essa abordagem permite que os objetos criados no framework executem um código que será definido posteriormente pelo desenvolvedor da aplicação final. A Figura 4 ilustra o fluxo. Figura 4 Inversão de controle existente na aplicação de um framework. Fonte: Oliveira (2001, p. 26) Desvantagens Alguns aspectos devem ser considerados antes de optar pela adoção de um sistema de framework: a) codificação rígida: a lógica de construção dos códigos deve obedecer ao padrão do framework; b) descontinuação: como é feito por terceiros, é aconselhável pesquisar se existem indícios que o desenvolvimento do framework possa ser abandonado; c) documentação: verifique se o framework possui uma boa documentação, para que você não perca mais tempo descobrindo como usá-lo do que se fizesse a seu modo;

24 23 d) mudança de cultura: como dito por Sauvé (2010), é preciso vencer "Not Made Here Syndrome", ou seja, não reescrever, ao seu modo, algo que o framework já contempla; e) curva de aprendizagem: é preciso considerar o tempo necessário para um desenvolvedor se tornar produtivo na utilização do framework e o custo desse aprendizado; f) eficiência: para garantir a extensibilidade e abstração, um framework geralmente faz várias chamadas indiretas através de mecanismos presentes nas linguagens orientadas a objetos, o que pode provocar queda na eficiência da aplicação final. (OLIVEIRA, 2001) Instanciação Instanciação é o processo de reutilização do framework, quando, conforme descrito por Oliveira (2001, p. 31), os pontos de extensão do framework são preenchidos para se obter a aplicação final. Durante esse processo, a aplicação deve ser construída de modo a incorporar as características impostas pelo framework. 2.5 FRAMEWORKS PARA PHP Como uma boa linguagem orientada a objetos, PHP possui frameworks muito bons e já em fase de maturidade, porém em constante aprimoramento. Nesta seção, serão abordados dois frameworks com finalidades distintas, que podem trabalhar em parceria Zend Framework O Zend Framework, conhecido também pela sigla ZF, é um framework de desenvolvimento livre do tipo híbrido, construído para a linguagem PHP. O ZF baseia-se em

25 24 componentes reutilizáveis. À medida que uma nova versão do framework é finalizada, novos componentes são liberados. (LISBOA, 2008, p. 21). Lisboa (2008) explica que, no ZF, os componentes podem ser utilizados de forma independente, devido a uma arquitetura muito simples de diretórios e classes, com nomenclaturas padronizadas, separados por módulos. O ZF trabalha com o padrão MVC, um paradigma de desenvolvimento que instrui a dividir a aplicação em três partes: modelo, visão e controlador. Um modelo é usado para gerenciar informação sobre um elemento de dados, respondendo a consultas sobre seu estado e a instruções de mudança de estado. A visão ou visualizador trabalha com a exposição das informações, de um ou mais elementos, ao usuário. É a camada mais superficial da aplicação. Um controlador tem a função de administrar a solicitação do usuário (entrada de dados) e instruir o modelo e o visualizador a trabalharem (processamento) em uma resposta (saída) para o usuário Vantagens Já citadas as vantagens na utilização de frameworks, em geral, seguem algumas vantagens da utilização do ZF, segundo Lisboa (2008): a) não é obrigatório o uso de todos os módulos do framework, isso permite ter uma base de código mais enxuta; b) não há regras em relação à nomenclatura de tabelas e campos dos bancos de dados, possibilitando o uso de bancos de dados legados; c) existem muitos recursos para implementação de segurança na aplicação; d) o ZF é mantido por uma grande empresa, a Zend Technologies, que garante a continuidade e a implementação de novas funcionalidades. Além disso, a linguagem PHP é praticamente mantida pela Zend; e) o framework evolui rapidamente devido ao desenvolvimento colaborativo entre a comunidade e a Zend Technologies, acompanhado sempre de uma boa documentação para dar mais segurança no uso dos componentes.

26 Desvantagens Lisboa (2008) cita, em seu livro, algumas condições que podem ser desfavoráveis ao uso do ZF, como a falta de ferramentas de geração de código e a falta de documentação em português. Na opinião do autor, a falta de geradores de código não é tão grave, pois é complicado criar um gerador eficiente. No entanto, ele considera a falta de documentação em português como um grande problema Doctrine Doctrine é um framework livre, também, desenvolvido para a linguagem PHP, que se responsabiliza pelo mapeamento objeto relacional. Esse tipo de framework é conhecido pela sigla ORM, do inglês Object Relational Mapper (Mapeador Objeto Relacional). A função primordial de um ORM é transformar dados vindos de um banco de dados relacional em objetos, sendo o oposto, também, verdadeiro, ou seja, transformar objetos em instruções SQL que interagem com o banco de dados, tornando isso transparente ao usuário, desenvolvedor do software. O usuário passa a trabalhar com objetos e com as classes, funções e atributos referentes ao mesmo, e não se preocupa com a linguagem nativa do Sistema de Gerenciamento de Banco de Dados (SGBD). A partir desse paradigma, algumas vantagens podem ser obtidas, como despreocupação com o tipo de SGBD e agilidade no desenvolvimento. Como em qualquer solução, um ORM apresenta algumas desvantagens de uso, uma delas seria o desempenho um pouco reduzido para a aplicação, devido à quantidade de operações que ocorrem no processo de mapeamento. Existem alguns modos de fazer o mapeamento entre objetos e banco de dados. O Doctrine trabalha com três possibilidades: a) o usuário cria as classes de modelo e, a partir delas, o Doctrine cria o banco de dados; b) o usuário cria um arquivo de definição do modelo, que será lido e interpretado pelo Doctrine, a partir disso, ele criará as classes de modelo e o banco de dados;

27 26 c) o usuário cria todo o banco de dados, com os devidos relacionamentos, e o Doctrine cria os modelos a partir da estrutura do banco de dados. Esse é o modo que será utilizado neste projeto. 2.6 CONSIDERAÇÕES FINAIS DO CAPÍTULO Existem muitas ferramentas para melhorar a produtividade no desenvolvimento de software. PHP está se igualando a outras linguagens mais poderosas, como Java, ao ter ótimos frameworks e geradores de código para alguns deles. Ainda não foi desenvolvido um gerador de código que una os dois frameworks apresentados: ZF e Doctrine. Talvez esse seja um dos motivos pela pouca difusão dessas ferramentas. Pode-se perceber, por fim, as vantagens da utilização de geradores de código e de frameworks e a importância da escolha de um bom framework. A partir dessas constatações, fica claro que um gerador de código preparado especificamente para a utilização dessas ferramentas traria benefícios para o mercado de desenvolvimento de software web, em PHP.

28 27 3 MÉTODO Este capítulo se destina a apresentar os procedimentos que foram ou serão executados para a realização do projeto, classificando-o quanto ao tipo de pesquisa, mostrando as etapas necessárias para alcançar os objetivos propostos e as delimitações do projeto. 3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA Pesquisa é um conjunto de ações, propostas para encontrar a solução para um problema, que têm por base procedimentos racionais e sistemáticos. A pesquisa é realizada quando se tem um problema e não se tem informações para solucioná-lo. (SILVA; MENEZES, 2005, p. 20) Existem diversos tipos de pesquisa. A pesquisa feita para a confecção desta monografia é classificada como pesquisa aplicada, pois, segundo Silva e Menezes (2005, p. 20), esse tipo de pesquisa objetiva gerar conhecimentos para aplicação prática e dirigidos à solução de problemas específicos. Este projeto se propõe a resolver problemas como o trabalho repetitivo e a falta de padronização de código e de estrutura das aplicações, assim como reduzir o tempo de aprendizado com os frameworks ZF e Doctrine. Outra classificação que cabe ao trabalho, aqui proposto, é a de pesquisa bibliográfica, pois ele está fundamentado teoricamente em materiais já publicados, e segundo o conceito de Gil (1991 apud SILVA; MENEZES, 2005, p. 21), a pesquisa bibliográfica ocorre quando elaborada a partir de material já publicado, constituído principalmente de livros, artigos de periódicos e atualmente com material disponibilizado na Internet.

29 ETAPAS METODOLÓGICAS Para Silva e Menezes (2001, p.22), o planejamento de uma pesquisa dependerá basicamente de três fases: a) fase decisória: referente à escolha do tema, à definição e à delimitação do problema de pesquisa; b) fase construtiva: referente à construção de um plano de pesquisa e à execução da pesquisa propriamente dita; c) fase redacional: referente à análise dos dados e das informações obtidas na fase construtiva. É a organização das idéias de forma sistematizada visando à elaboração do relatório final. As principais etapas metodológicas referentes ao desenvolvimento deste projeto estão distribuídas no Fluxograma 1.

30 29 Fluxograma 1 Etapas metodológicas do trabalho. Fonte: Elaboração do autor (2010). Segue o detalhamento das etapas apresentadas acima: a) a pesquisa bibliográfica foi realizada nos capítulos 2 e 5 deste trabalho, onde foram pesquisadas informações já publicadas sobre geradores de aplicações, frameworks e ferramentas de apoio ao desenvolvimento de sistemas; b) a avaliação das ferramentas, a serem utilizadas no projeto que será desenvolvido, foi feita no início do desenvolvimento deste trabalho e inserida no capítulo 5, onde foi realizada uma pesquisa bibliográfica específica para cada ferramenta que será adotada;

31 30 c) a modelagem da aplicação será realizada no capítulo 4, utilizando alguns diagramas definidos pela UML; d) o desenvolvimento da aplicação será feito após a etapa de modelagem; e) será realizada a validação do sistema para verificar se o funcionamento está de acordo com o especificado na modelagem da aplicação; f) se algo não estiver de acordo, o sistema voltará para a etapa de desenvolvimento até que o funcionamento esteja de acordo com a modelagem; g) serão realizados testes de cada funcionalidade do software, se encontrado um ou mais problemas, a funcionalidade voltará para a etapa de desenvolvimento até que não sejam encontrados erros; h) quando o software estiver funcionando conforme esperado, será gerada uma aplicação através do sistema, a fim de demonstrar o seu funcionamento; i) após a demonstração, este trabalho estará concluído. 3.3 PROPOSTA DA SOLUÇÃO Conforme a proposta da solução ilustrada na Figura 5, a aplicação funcionará de forma que a entrada do sistema será o banco de dados criado e a saída será uma aplicação gerada a partir da estrutura do banco de dados. Figura 5 Proposta da solução. Fonte: Elaboração do autor (2010). A Figura 6 ilustra a estrutura tecnológica do sistema proposto. O sistema se baseará em um banco de dados previamente criado e gerará uma aplicação, utilizando os frameworks ZF e Doctrine, que utilizam a linguagem PHP, que será executada através do servidor web Apache. Após esse processo, a aplicação gerada pode ser visualizada pelo usuário no seu navegador de internet.

32 31 Figura 6 Estrutura tecnológica da proposta. Fonte: Elaboração do autor (2010). 3.4 DELIMITAÇÕES O sistema proposto nesta monografia terá a finalidade de gerar aplicações que trabalhem essencialmente com gerenciamento de registros, como catálogos de produtos e portais de notícias. O sistema não gerará outras funcionalidades que não as de cadastro, recuperação, alteração e exclusão de registros create, retrieve, update e delete (CRUD), além da estrutura básica necessária para utilização da aplicação, como a navegação entre as páginas e as configurações necessárias. Os principais módulos a serem utilizados do framework ZF serão os módulos responsáveis pela organização MVC e pela infraestrutura básica da aplicação, conforme serão apresentados no capítulo 5. Quanto aos módulos do framework Doctrine, serão utilizados aqueles responsáveis pela geração de classes de modelo através de uma conexão com um banco de dados e pelo gerenciamento de registros (funcionalidades CRUD).

33 CONSIDERAÇÕES FINAIS DO CAPÍTULO Segundo apresentado no capítulo, o trabalho é uma pesquisa aplicada e bibliográfica, pois se fundamenta teoricamente em materiais já publicados, para a criação de uma aplicação prática. O sistema proposto consiste na geração de funcionalidades de cadastro e gerenciamento de registros, em uma aplicação web, a partir de um banco de dados criado para tal aplicação.

34 33 4 MODELAGEM DO SISTEMA Neste capítulo será apresentada a modelagem da aplicação proposta. Serão expostos os requisitos funcionais e não funcionais e os diagramas de casos de uso, classes, sequência e atividades. 4.1 LINGUAGEM DE MODELAGEM UNIFICADA (UML) A linguagem de modelagem unificada unified modeling language (UML) é uma linguagem de modelagem para construção de artefatos de softwares orientados a objetos, a modelagem permite a compreensão de um sistema. (BOOCH; RUMBAUGH; JACOBSON, 2000, p. 14). A UML é livre, ou seja, não é preciso pagar direitos autorais para usá-la. Segundo Bezerra (2002), muitos métodos de análise e projeto de softwares orientados a objetos surgiram no final da década de 80 e início da década de 90. A UML é a união de diversas notações preexistentes, sendo que alguns elementos foram removidos e outros adicionados. A UML é independente de linguagem de programação e de processo de desenvolvimento. Bezerra (2002) explica que a utilização da UML envolve diversos documentos, denominados artefatos de software, que podem ser textuais ou gráficos. Para a construção dos artefatos gráficos, existem diversos diagramas definidos na linguagem UML. Esses diagramas existem para que o sistema possa ser visualizado de várias perspectivas, ampliando sua capacidade de compreensão. Na Figura 7, são listados os diagramas existentes na UML. Os retângulos com cantos retos representam agrupamentos (tipos) de diagramas, enquanto que os retângulos com cantos arredondados são os diagramas em si (o artefato).

35 34 Figura 7 Diagramas definidos pela UML. Fonte: Bezerra (2002, p.17). 4.2 REQUISITOS O levantamento de requisitos é a etapa que compreende a especificação das necessidades que o sistema deve atender. Basicamente, existem dois tipos de requisitos, listados a seguir, segundo Bezerra (2002): a) requisitos funcionais: definem as funcionalidades do sistema, ou seja, o que o sistema deve fazer de prático; b) requisitos não funcionais: indicam as características de qualidade que o sistema deve possuir, como confiabilidade, desempenho e segurança. A Figura 8 apresenta de forma visual os requisitos funcionais do projeto proposto e no Quadro 1 há informações quanto à descrição de cada requisito.

36 35 Figura 8 Requisitos funcionais. Fonte: Elaboração do autor (2010). RF01 Cadastrar aplicação Descrição: Através de dados informados pelo usuário, o sistema criará um arquivo de configuração em um diretório de arquivos temporários e armazenará informações de banco de dados e diretório da aplicação. RF02 Verificar conexão com o banco de dados Descrição: O sistema deve verificar se é possível a conexão com o banco de dados informado. Caso ocorra algum erro na conexão com o banco de dados, o sistema deve informar ao usuário sem que sejam perdidos os dados postados. RF03 Verificar existência do diretório Descrição: O sistema deve verificar se o diretório informado existe, pois, se não existir, o sistema irá gerá-lo. RF04 Verificar permissão do diretório Descrição: O sistema deve verificar se o diretório da aplicação existe e se possui permissão de escrita. Caso o diretório informado não possua permissão de escrita, o sistema deve informar ao usuário, para que corrija o problema, sem que sejam perdidos os dados

37 postados. RF05 Verificar existência de arquivos no diretório Descrição: O sistema deve verificar se já existe conteúdo dentro do diretório da aplicação e se tal conteúdo pode ser substituído. Se sim, o sistema excluirá o conteúdo, se não, solicitará outro diretório. RF06 Escolher opções de geração Descrição: O usuário irá selecionar algumas opções do gerador: para quais tabelas devem ser criados os cadastros; quais campos de cada tabela devem aparecer nos cadastros; quais campos possuem relacionamento com outras tabelas; legenda dos campos nos formulários que serão criados; legenda para cada tabela (se optar por criar cadastro da mesma); escolha de um campo da tabela que será utilizado como nomenclatura para os registros. (Ex.: campo NOME para a tabela ALUNO, é o campo que será mostrado na listagem dos registros). RF07 Armazenar opções de geração Descrição: O sistema deve armazenar, no arquivo de configurações, as opções selecionadas pelo usuário quanto à criação dos cadastros. RF08 Gerar aplicação Descrição: Após salvar as opções de geração, o sistema irá gerar o código da aplicação de acordo com as escolhas do usuário. RF09 Gerenciar etapas de geração Descrição: O sistema deve gerar a aplicação por etapas, para que não se torne um processo muito demorado. RF10 Informar usuário constantemente Descrição: Manter o usuário informado do andamento da geração, a cada etapa concluída, e da conclusão do processo, assim como de possíveis falhas que vierem a ocorrer. Quadro 1 Descrição dos requisitos funcionais. Fonte: Elaboração do autor (2010). 36 A Figura 9 apresenta de forma visual os requisitos não funcionais do projeto proposto e, no Quadro 2, há informações quanto à descrição de cada requisito.

38 37 Figura 9 Requisitos não funcionais. Fonte: Elaboração do autor (2010). RNF01 Linguagem de programação Descrição: O software será desenvolvido, utilizando a linguagem de programação PHP. RNF02 Frameworks utilizados Descrição: Devem ser utilizados os frameworks ZF e Doctrine. RNF03 Plataforma Descrição: A aplicação rodará em ambiente web e será independente de sistema operacional, podendo ser acessada e visualizada corretamente nos navegadores Firefox, Internet Explorer, Safari, Opera e Google Chrome. RNF04 Usabilidade Descrição: O software deve ser simples e usável. RNF05 Tempo máximo para cada etapa de geração Descrição: Cada etapa de geração não deve demorar mais de 5 segundos. RNF06 Entrada de dados Descrição: O usuário digitará as informações necessárias em formulários HTML. RNF07 Alinhamento e legenda dos campos

39 Descrição: Todos os campos de formulários devem estar alinhados à esquerda da tela e devem possuir legenda compreensível. RNF08 Indicar formato de entrada de dados Descrição: Para os campos dos formulários que possuem um formato específico, o formato deve ser indicado através de um hint (dica) de ajuda. RNF09 As mensagens de falha e sucesso devem ser diferenciadas por cores Descrição: As mensagens de sucesso devem ter cor verde e as mensagens de falha devem ter cor vermelha. RNF10 Validação dos dados submetidos Descrição: A validação dos dados deve ser feita utilizando a linguagem PHP e não linguagens de script. Quadro 2 Descrição dos requisitos não funcionais. Fonte: Elaboração do autor (2010) DIAGRAMAS DE ATIVIDADES Um diagrama de atividade é essencialmente um gráfico de fluxo, mostrando o fluxo de controle de uma atividade para outra. (BOOCH; RUMBAUGH; JACOBSON, 2000, p. 255). Segundo Bezerra (2002, p. 228), os elementos de um diagrama de atividade podem ser divididos em dois grupos: os que são utilizados para representar fluxos de controle sequenciais e os que são utilizados para representar fluxos de controle paralelos. Os elementos usados no controle sequencial estão descritos a seguir, de acordo com Bezerra (2002): a) estado ação e estado atividade: cada estado no diagrama corresponde a um passo, em que o sistema está realizando algo. A diferença entre o estado atividade e o estado ação é que o último é realizado instantaneamente, enquanto que o primeiro leva algum tempo; b) estados inicial e final e condição de guarda: o estado inicial indica, como o nome diz, o início do diagrama de atividade. Ele pode ter vários estados finais ou nenhum, se o processo for cíclico, e várias condições de guarda associadas a transições;

40 c) transições de término: ligam um estado a outro, indicando o término de um passo e o início de outro. Simbolizadas por uma seta, na qual a direção se dá a partir do estado concluído para o estado a ser iniciado em seguida; d) pontos de ramificação e de união: pontos de ramificação possuem uma transição de entrada e várias transições de saída. Somente uma das transições de saída será seguida, dependendo da resposta à condição de guarda associada ao ponto. Os pontos de união funcionam de forma inversa, eles reúnem diversas transições que levam ao mesmo resultado e que possuem um ponto de ramificação em comum. Os fluxos de controle paralelos indicam que pode haver vários fluxos de controle sendo executados simultaneamente no diagrama de atividades. A sincronização de dois ou mais fluxos paralelos são possibilitadas através de barras de sincronização, que podem ser do tipo barra de bifurcação e barra de junção. A barra de bifurcação recebe uma transição e alguns fluxos de controle paralelos. A barra de junção recebe transições de entrada e as une em um único fluxo. (BEZERRA, 2002). Algumas vezes, é necessário distribuir as atividades de um processo entre as entidades que o executarão. As raias de natação [conhecidas no termo em inglês como swim lanes] dividem o diagrama de atividades em compartimentos. Cada compartimento contém atividades que são realizadas por uma entidade. (BEZERRA, 2002, p. 230). Bezerra (2002, p. 230) traz a seguinte comparação: Tanto o diagrama de interação quanto o diagrama de atividade são usados para modelar o comportamento do sistema. Enquanto o diagrama de atividade mostra o fluxo de controle sem fazer referência aos objetos do sistema, o diagrama de interação exibe esses objetos e a troca de mensagens entre eles. 39 O Diagrama 1 ilustra o fluxo de atividades entre usuário (desenvolvedor de aplicações que está utilizando o sistema) e o sistema, mostrando cada interação entre os mesmos.

41 40 Diagrama 1 Diagrama de Atividades - Fluxo entre Usuário e Sistema. Fonte: Elaboração do autor (2011). O Diagrama 2 ilustra o fluxo de atividades que acontece dentro do sistema, mostrando superficialmente as atividades que ocorrem nas telas de cadastro e geração.

42 41 Diagrama 2 Diagrama de Atividades - Fluxo do Sistema. Fonte: Elaboração do autor (2011). 4.4 DIAGRAMA DE CASOS DE USO Conforme Bezerra (2002, p. 45), o modelo de casos de uso é uma representação das funcionalidades externamente observáveis do sistema e dos elementos externos ao sistema que interagem com ele. Esse modelo, representado através de um Diagrama de Casos de Uso, tornou-se muito popular desde que foi incorporado à UML, devido a sua notação gráfica simples e descrição em linguagem natural, o que facilita a comunicação entre desenvolvedores e usuários. (BEZERRA, 2002, p. 14). Os componentes do modelo de casos de uso são: os casos de uso (funcionalidades do sistema), os atores (interagem com o sistema) e os relacionamentos entre eles. Um caso de uso define como utilizar uma funcionalidade do sistema, sem entrar em detalhes internos de estrutura ou implementação. Funciona como uma descrição, através de texto narrativo, das interações entre o sistema e elementos externos, que podem ser representadas no diagrama. Essa descrição, feita através de uma sequência de passos,

43 42 denomina-se cenário, e um caso de uso, então, é um conjunto de cenários amarrados por um objetivo comum de um usuário. (FOWLER; SCOTT, 2000, p. 49). Bezerra (2002, p. 51) explica que um ator é um papel representado no sistema, como um cliente, um funcionário ou um fornecedor, e é necessariamente um elemento externo que interage com o sistema, ou seja, não faz parte dele, apenas troca informações com o sistema. Para haver interação entre casos de usos e atores, é necessário definir relacionamentos entre eles. Podem existir relacionamentos de atores, de casos de uso, e de atores com casos de uso. Segundo Bezerra (2002), os tipos de relacionamentos são: a) comunicação: demonstra a associação entre um ator e um caso de uso com o qual ele interage; b) inclusão: quando um mesmo comportamento se repete em mais de um caso de uso, é criado um caso de uso para esse comportamento comum, para que ele seja incluído por outros, não sendo preciso descrevê-lo a cada caso de uso; c) extensão: descreve um comportamento opcional de um caso de uso; d) herança: utilizado se um caso de uso ou ator possuir o mesmo comportamento de outro caso de uso ou ator (respectivamente), porém mais específico. Para compreender o funcionamento desse diagrama, segue um exemplo: um funcionário da empresa solicita ao sistema a informação sobre um determinado cliente. Nesse caso, o ator seria o funcionário, o caso de uso poderia ser pesquisar cliente ou obter informações sobre cliente e haveria um relacionamento de comunicação entre ator e caso de uso. No detalhamento dos possíveis cenários do caso de uso, haveria a descrição passo-apasso de como acontece essa interação. Um diagrama de casos de uso, normalmente, contém diversos casos de uso e pode conter mais de um ator. A seguir, serão apresentados os atores e casos de uso do sistema proposto, conforme o padrão UML. A Figura 10 mostra os atores do sistema, e o Quadro 3 contém informações relevantes sobre tais atores.

44 43 Figura 10 Atores do sistema. Fonte: Elaboração do autor (2010). Nº Ator Descrição 1 Desenvolvedor de aplicações Definição: indivíduo que pretende gerar sua aplicação através do gerador de código. Frequência de uso: esporádica. Conhecimento em informática: bom conhecimento em desenvolvimento e uso de aplicativos e internet, podendo, ainda, ter conhecimento sobre sistemas operacionais e servidores. Conhecimento no processo: tem domínio em processos de desenvolvimento de software. Grau de escolaridade: de técnico a pós-graduado. Permissões de acesso: acesso completo a todas as funcionalidades do sistema e ao código-fonte, disponível para download. Quadro 3 Descritivo dos atores do sistema. Fonte: Elaboração do autor (2010). O Diagrama 3 contém a representação gráfica dos casos de uso, que serão descritos, logo abaixo, no Quadro 4.

45 44 Diagrama 3 Diagrama de Casos de Uso. Fonte: Elaboração do autor (2010). Caso de uso: Cadastrar aplicação Identificador: CSU001 Ator: Desenvolvedor de aplicações Descrição: O desenvolvedor informa as configurações básicas de sua aplicação. Pré-condição: Banco de dados da aplicação pronto. Fluxo principal: 1. O desenvolvedor informa os dados de conexão com o banco de dados. 2. O desenvolvedor informa o diretório de destino da aplicação. 3. O desenvolvedor submete o formulário preenchido e o sistema armazena os dados de configuração. 4. O sistema gera a estrutura de diretórios e arquivos que compõem a infraestrutura básica para funcionamento de todas as aplicações. 5. O sistema emite uma mensagem ao usuário quando esta etapa estiver concluída e disponibiliza a opção de passar para a próxima etapa. Fluxo alternativo: 1.a. Se o sistema verificar a indisponibilidade de conexão com o banco de dados, o desenvolvedor deve resolver o problema e retornar ao passo 1, se for necessário alterar alguma informação, e submeter novamente o formulário (passo 3). 2.a. Se o diretório for inexistente, será criado pelo sistema. 2.b. Se o sistema verificar que o diretório não possui permissão de escrita, necessária para a criação dos arquivos da aplicação, solicitará ao desenvolvedor para que realize essa configuração no diretório. Após isso, o formulário deve ser submetido novamente (passo 3).

46 45 2.c. Se o sistema verificar a existência de arquivos no diretório informado, renomeará o diretório atual para o nome do diretório acrescido da data e horário atuais (para manter backup). Em seguida, o sistema criará um novo diretório, com o nome informado pelo desenvolvedor, e gerará a aplicação neste. Pós-condições: A aplicação possuirá as primeiras configurações armazenadas e a estrutura de diretórios criada. Caso de uso: Gerar aplicação Identificador: CSU002 Ator: Desenvolvedor de aplicações Descrição: A aplicação será gerada pelo sistema de acordo com algumas opções escolhidas pelo desenvolvedor. Pré-condição: As configurações de banco de dados e estrutura inicial da aplicação devem estar prontas. Fluxo principal: 1. O desenvolvedor escolhe as opções de geração apresentadas pelo sistema, segundo consulta feita à base de dados: para quais tabelas devem ser criados os cadastros; quais campos de cada tabela devem aparecer nos cadastros; quais campos possuem relacionamento com outras tabelas; legenda dos campos nos formulários que serão criados; legenda para cada tabela (se optar por criar cadastro da mesma); escolha de um campo da tabela que será utilizado como nomenclatura para os registros. (Ex.: campo NOME para a tabela ALUNO, é o campo que será mostrado na listagem dos registros). 2. O desenvolvedor submete o formulário com as opções e o sistema salva as configurações. 3. O sistema gera os arquivos necessários para o gerenciamento de registros das tabelas escolhidas, de acordo com as opções selecionadas pelo desenvolvedor. 4. O sistema informa que o processo foi concluído e que toda a aplicação já foi gerada. Fluxo alternativo: 2.a. Se o formulário for postado completamente em branco, o sistema emitirá um aviso e pausará o processo até que informações válidas sejam inseridas. Desenvolvedor retorna ao passo 1. 3.a. Caso ocorra uma falha durante a geração da aplicação, o desenvolvedor deve retornar

47 46 ao passo 1. Pós-condições: Aplicação gerada e pronta para uso. Quadro 4 Descrição dos casos de uso. Fonte: Elaboração do autor (2010). 4.5 DIAGRAMAS DE SEQUÊNCIA O Diagrama de Sequência é um diagrama de interação. Diagramas de interação representam como o sistema age internamente para que um ator atinja seu objetivo na realização de um caso de uso. (BEZERRA, 2002, p. 147). Bezerra (2002, p. 148) explica que um diagrama de interação modela a troca de mensagens entre objetos de um cenário ou parte dele e que o enfoque do diagrama de sequência está em como as mensagens são enviadas no decorrer do tempo. Os elementos de um diagrama de sequência são: atores, objetos, classes, linhas de vida, mensagens e focos de controle. Esses elementos seguem descritos, a seguir, segundo Bezerra (2002): a) atores: os atores do caso de uso podem aparecer no diagrama de sequência; b) objetos: objetos que participam de um caso de uso devem ser inseridos no diagrama de sequência correspondente; c) classes: quando a mensagem for endereçada a uma classe, e não à sua instância, a própria classe deve aparecer no diagrama, e não o objeto. No entanto, isso não é muito comum; d) linhas de vida: é uma linha vertical tracejada que, no diagrama de sequência, aparece abaixo da representação do objeto, indicando em que momento o objeto inicia e conclui sua participação no diagrama; e) mensagens: A notação para uma mensagem em um diagrama de sequência é uma flecha horizontal ligando uma linha de vida a outra. O objeto do qual parte a seta é aquele que está enviando a mensagem (objeto remetente). O objeto ao qual a seta aponta é aquele que está recebendo a mensagem (objeto receptor). [...] A passagem de tempo é percebida no diagrama de sequência observando-se a direção vertical no sentido de cima para baixo. Quanto mais abaixo uma mensagem aparece no diagrama, mais tarde no tempo esta mensagem foi enviada. (BEZERRA, 2002, p. 150); f) focos de controle: no diagrama, os focos de controle são representados por blocos retangulares que ficam sobre a linha de vida de um objeto enquanto o

48 47 mesmo realiza uma ação. No início do bloco, o objeto recebe uma mensagem, ao longo do bloco, ele trabalha com a mensagem, e o final do bloco de controle indica o término da operação. Para uma melhor compreensão, na Figura 16, há um exemplo de diagrama de sequência. Serão exibidos, nesta seção, os diagramas de sequência correspondentes a cada caso de uso apresentado na seção anterior. Neles, é possível ver, a cada ação do usuário, quais as mensagens internas que o sistema realiza para atender ao caso de uso. O Diagrama 4 corresponde ao caso de uso Cadastrar aplicação.

49 48 Diagrama 4 Diagrama de Sequência - Cadastrar Aplicação. Fonte: Elaboração do autor (2011). O Diagrama 5 corresponde ao caso de uso Gerar aplicação.

50 Diagrama 5 Diagrama de Sequência - Gerar aplicação. Fonte: Elaboração do autor (2011). 49

51 DIAGRAMA DE CLASSES Segundo Fowler e Scott (2000, p. 57), um diagrama de classes descreve os tipos de objetos no sistema e os vários tipos de relacionamento estático que existem entre eles. [...] Há dois tipos principais de relacionamento estático: Associações e Subtipos. Associações representam relações entre classes. Exemplo: um funcionário trabalha para uma empresa. Numa associação, a multiplicidade informa a quantidade de instâncias que podem estar associadas a outra instância. Exemplo: um funcionário trabalha para apenas uma empresa, e uma empresa pode ter um ou mais funcionários. Uma associação possui sua navegabilidade representada por uma seta, indicando que uma classe possui informação sobre outra. Exemplo: uma seta, apontando do funcionário para a empresa, significa que o funcionário tem a informação sobre qual empresa o emprega. Uma seta bidirecional indicaria que, além do funcionário ter essa informação, a empresa, também, tem conhecimento sobre quais funcionários ela emprega. Subtipos representam classes que possuem os mesmos atributos e operações de outras classes, mas que possuem algo a mais, que pode ser um comportamento especial e/ou atributos mais específicos. Portanto, os elementos de um Diagrama de Classes são: as classes (com atributos e operações) do sistema, as interfaces dessas classes (se houver) e a representação dos relacionamentos entre elas. O Diagrama 6 apresentará o diagrama de classes do sistema.

52 51 Diagrama 6 Diagrama de Classes do sistema. Fonte: Elaboração do autor (2011). Como se pode perceber, as classes de inicialização, controlador e formulário, utilizadas no sistema, herdam classes que pertencem ao framework ZF CONSIDERAÇÕES FINAIS DO CAPÍTULO Na modelagem, a adoção de alguns diagramas UML se fez necessária para essa aplicação, no entanto, nem todos os diagramas eram adequados. Através dos artefatos de modelagem expostos no capítulo, é possível perceber a simplicidade do sistema: será utilizado apenas por um tipo de usuário, implementará dois casos de uso, pois a geração da aplicação ocorrerá em duas etapas, e possui poucas classes, devido à utilização de frameworks. 1 Não foram inseridas especificações das classes pertencentes ao framework.

53 52 5 DESENVOLVIMENTO Neste capítulo, serão apresentados detalhes sobre o desenvolvimento do projeto: as tecnologias e ferramentas utilizadas, o histórico de desenvolvimento, a apresentação e validação do sistema. 5.1 TECNOLOGIAS E FERRAMENTAS Esta seção apresenta conceitos básicos sobre as principais tecnologias utilizadas no sistema desenvolvido, são elas: a linguagem de programação PHP, os frameworks ZF e Doctrine, o servidor de aplicações web Apache e a ferramenta CASE Enterprise Architect. O banco de dados MySQL foi utilizado apenas na aplicação gerada pelo sistema, que será citada como exemplo mais adiante, e o navegador de internet Mozilla Firefox foi utilizado para interação do usuário tanto com o sistema gerador quanto com o sistema gerado. A Figura 11 ilustra a utilização de todas as ferramentas. Figura 11 Logotipos das ferramentas utilizadas. Fonte: Elaboração do autor (2011).

54 Linguagem PHP A linguagem adotada no sistema será PHP. PHP é uma linguagem de programação orientada a objetos, que trabalha especificamente em ambiente web. Ela pode ser inserida junto à linguagem de marcação de hipertexto hypertext markup language (HTML) para que seja executada quando determinada página for acessada, ou então pode ser utilizada em um arquivo apenas com código PHP. A finalidade sempre será de gerar uma saída HTML ou outro tipo de saída que possa ser mostrada ao usuário através do navegador de internet. (WELLING; THOMSON, 2003, p. XXVI). PHP é uma linguagem de pré-processamento de hipertexto, ou, como esclarecido no parágrafo anterior, geração de HTML. Hipertexto refere-se aos links em uma página web que levam a outras páginas e, assim, vão formando uma árvore de links. A linguagem foi criada em 1994 por Rasmus Lerdof, embora tenha sido reescrita três vezes e passado por constantes atualizações e aperfeiçoamentos. É um produto de distribuição livre e código-fonte aberto, o que significa que qualquer pessoa pode usá-lo sem custo, alterá-lo a fim de colaborar com a melhoria da linguagem e redistribuí-lo para a comunidade. (WELLING; THOMSON, 2003) Frameworks utilizados Aqui, serão abordadas algumas informações relevantes, referentes aos frameworks ZF e Doctrine, utilizados no gerador de código desenvolvido nesta monografia. Foram utilizadas as versões do ZF 1.10 e do Doctrine 1.2. Estas são as versões utilizadas pela equipe que deu início à ideia do desenvolvimento deste projeto. Essas versões, hoje, não são as mais atuais, mas estão próximas das últimas versões. O desenvolvimento do gerador se iniciou com tais versões e, devido ao tempo limitado para o desenvolvimento do trabalho de conclusão de curso, não era viável adaptar o projeto a cada versão lançada.

55 Componentes do framework ZF A seguir, estão os componentes do ZF, separados em grupos de funcionalidades pela Zend Technologies Ltd. (2010, tradução nossa): a) model-view-controller (MVC): o MVC é uma norma padrão da indústria de design de aplicações web e permite aos desenvolvedores e web designers separarem seus interesses e habilidades, tornando a implementação de código e design mais fácil e claramente separada. Isso elimina a confusão ou a necessidade de ambos os conjuntos de habilidades em uma mesma pessoa. Os componentes do ZF que trabalham com o padrão MVC estão agrupados na Figura 12. Model-View-Controller.. (MVC) Recursos para trabalhar com a parte de Visão do MVC e modelo (layout) da aplicação Zend_Layout Zend_View Zend_View_Filter Zend_View_Helper Simplifica a criação e manipulação de formulários Zend_Form Recursos de inicialização da aplicação, carregamento de classes e módulos, configuração do ambiente PHP Zend_Application Zend_Application_Module Zend_Application_Resource Zend_Application_Bootstrap Todas as requisições são interceptadas pelo controlador frontal e expedidas para controladores de ação individual com base na URL solicitada. Zend_Controller_Front Zend_Controller_Plugin Zend_Controller_Dispatcher Zend_Controller_Action Zend_Controller_Router Figura 12 Componentes que trabalham com MVC. Fonte: Elaboração do autor (2010). b) ferramentas e desenvolvimento rápido de aplicações (RAD): são ferramentas de apoio e um cliente de linha de comando que permite gerar a estrutura de projeto e os artefatos MVC. A Figura 13 indica os elementos que participam dessa classe;

56 55 Ferramentas e Desenvolvimento Rápido de Aplicações (RAD) Ferramentas para expor as funcionalidades da aplicação e controlá-las Zend_Tool_Framework Zend_Tool_Project Oferece facilidades para gerar código, usando uma interface orientada a objetos Zend_Code_Generator Extensão do componente de Reflexão do PHP, com métodos adicionais para a recuperação de artefatos Zend_Reflection Figura 13 Ferramentas e componentes que trabalham com RAD. Fonte: Elaboração do autor (2010). c) base de dados: o ZF possui adaptadores para abstração de todos os principais bancos de dados do mercado. Os componentes responsáveis por essas operações são mostrados na Figura 14; Base de Dados Fornecem uma interface simples de banco de dados SQL para o ZF Zend_Db Zend_Db_Select Zend_Db_Adapter Zend_Db_Table Zend_Db_Profiler Figura 14 Componentes que trabalham com base de dados. Fonte: Elaboração do autor (2010). d) internacionalização (i18n) e localização (l10n): os componentes que garantem facilidade para a internacionalização e localização estão agrupados na Figura 15;

57 56 Internacionalização (i18n) e Localização (l10n) Recurso para formatação de nomes, apelidos, títulos, números, datas, horários, moedas, etc, de acordo com as convenções Zend_Locale Recurso para trabalhar com medições, de acordo com a língua nativa do usuário Zend_Measure Lida com todas as questões relacionadas à moeda, representação do dinheiro, formatação, troca de serviços e de cálculo Zend_Currency Solução do ZF para aplicações multilíngues Zend_Translate Manipulação de datas e horários Zend_Date Figura 15 Componentes que trabalham com internacionalização (i18n) e localização (l10n). Fonte: Elaboração do autor (2010). e) autenticação, autorização e gerenciamento de sessão: os componentes que permitem a implementação de restrições de acesso e gerenciamento de sessão podem ser visualizados na Figura 16; Autenticação, Autorização e f) Gerenciamento de Sessão Recurso para Lista de Controle de Acesso para controle de privilégios de usuários Zend_Acl Recurso para autenticação de usuários Zend_Auth Gerenciamento de sessões de usuários Zend_Session Figura 16 Componentes que trabalham com autenticação, autorização de acesso e gerenciamento de sessão. Fonte: Elaboração do autor (2010). g) web e web services: atualmente, o ZF oferece serviços web em parceria com Google, Microsoft e Strikelron, e eles estão construindo o suporte para os seus serviços para o ZF. Na Figura 17, são mostrados os componentes do ZF que trabalham com web services;

58 57 Web e Web Services Oferecem serviços Consomem serviços Zend_Server_Reflection Zend_Soap_Server Zend_Json_Server Zend_Feed Zend_Gdata Zend_Server_Definition Zend_Http_Client Zend_Rest_Client Zend_XmlRpc_Server Zend_Service Zend_XmlRpc_Client Zend_Amf_Server Zend_Rest_Server Figura 17 Componentes que trabalham com web e web services. Fonte: Elaboração do autor (2010). h) , formatos e pesquisa: o ZF dá suporte para Ajax, geração de arquivos no formato de documentos portável portable document format (PDF), envio de s e busca através dos componentes disponíveis na Figura 18; , Formatos e Pesquisa Manipulação de documentos em formato PDF Zend_Pdf Motor de busca de texto Serialização nativa do PHP para JSON e decodificação JSON para o PHP nativo Zend_Json Envio de s e manipulação de mensagens MIME Zend_Search_Lucene Zend_Mail Zend_Mime Figura 18 Componentes que trabalham com , formatos e pesquisa. Fonte: Elaboração do autor (2010). i) infraestrutura básica: ZF é uma biblioteca ampla e fracamente acoplada, que suporta muitos recursos necessários em uma aplicação web, desde o registro ao rastreamento e depuração da aplicação em produção, armazenamento de cache, filtragem para aplicações mais seguras e muitas outras necessidades pequenas, que facilitam a vida de um desenvolvedor de aplicações web. A Figura 19 mostra os componentes que trabalham com a infraestrutura básica.

59 58 Infraestrutura básica Recursos de infraestrutura básica para aplicações Zend_Cache Zend_Config Zend_Debug Zend_Filter Zend_Loader Zend_Console_Getopt Zend_Loader_Autoloader Zend_Log Zend_Memory Zend_Registry Zend_Validate Zend_Version Figura 19 Componentes para infraestrutura básica de aplicações. Fonte: Elaboração do autor (2010) Componentes do framework Doctrine Doctrine é um mapeador objeto relacional para PHP que fica sobre uma camada de abstração de banco de dados database abstraction layer (DBAL) e fornece persistência transparente para objetos PHP. Uma de suas principais características é a opção de escrever consultas de banco de dados através de uma Linguagem de Consulta Estruturada Structured Query Language (SQL) orientada a objetos, chamada de Linguagem de Consulta Doctrine Doctrine Query Language (DQL), inspirada no Hibernate HQL. Dessa forma, desenvolvedores podem criar consultas de forma simples e flexível. (DOCTRINE, 2010, tradução nossa). A tarefa primária de um ORM é a tradução transparente entre objetos PHP e linhas de dados relacionais. Doctrine visa a simplificar a tradução entre as linhas do banco de dados e o modelo de objetos PHP. Os principais casos de uso para Doctrine são, portanto, aplicações que utilizam o paradigma de Programação Orientada a Objetos (POO). Para aplicações que não trabalham principalmente com objetos, Doctrine não é adequado. (DOCTRINE, 2010, tradução nossa). Doctrine está dividido em três pacotes principais, segundo Doctrine (2010, tradução nossa): a) Common: contém componentes altamente reutilizáveis, que não tem dependências além do pacote em si e do PHP; b) DBAL (inclui Common): contém uma camada de abstração de dados maior em cima do PHP Data Objects (PDO);

60 59 c) ORM (inclui DBAL+Common): contém o kit de ferramentas ORM que fornece persistência relacional transparente de objetos simples do PHP. A utilização dessa abstração que o ORM oferece se dá da seguinte forma: existindo a tabela noticias, por exemplo, alguns campos da tabela podem ser: codigo, data, titulo e texto. Com Doctrine, é possível tratar a tabela como uma classe e seus campos como sendo seus atributos de instância. A instância dessa classe possuirá também algumas operações embutidas, como: método para salvar um registro, método para excluir um registro, entre outros. São métodos que transformam uma simples chamada, através do objeto, para comandos SQL, compreensíveis pelo banco de dados, de forma invisível ao usuário Servidor de aplicações Um servidor web é um computador onde ficam armazenados os arquivos fontes de determinado site disponível na internet. Esse computador deve ter um software instalado para gerenciar as requisições feitas a ele, por navegadores, através do protocolo de transferência de hipertexto hypertext transfer protocol (HTTP). Ao software, também se dá o nome de servidor web. Assim, o conceito de servidor web seria uma máquina com um software responsável por responder a requisições HTTP. O servidor web, utilizado neste projeto, é o servidor Apache, que é um servidor livre e, segundo dados da empresa inglesa Netcraft (2010), é o servidor mais utilizado no mundo todo, atingindo a 56% dos domínios hospedados na internet Ferramenta CASE para modelagem A ferramenta CASE utilizada para modelagem deste projeto foi o Enterprise Architect (EA). O EA é um software proprietário da empresa Sparx Systems. A seguir, serão abordadas superficialmente algumas funcionalidades disponíveis na ferramenta, segundo informações oficiais da Sparx Systems (2010, tradução nossa): a) o EA possui recursos de gerenciamento de requisitos que podem ser utilizados para organizar o modelo de requisitos hierárquicos, traçar a aplicação dos

61 60 requisitos do sistema para os elementos do modelo e realizar análise de impacto das mudanças propostas nos requisitos. É possível ter um controle eficaz, validação e análise de impacto imediato em todo o ciclo de vida do projeto, usando recursos como a matriz de relacionamentos e visualização de hierarquia; b) a ferramenta permite construir a modelagem da aplicação e, a partir dessa modelagem, gerar o código-fonte automaticamente. O EA trabalha atualmente com mais de 14 linguagens; c) o EA permite construir, testar, depurar, rodar e executar scripts de implantação dentro do ambiente de desenvolvimento da própria ferramenta. O EA é capaz de gerar classes de testes a partir de classes de origem; d) além de fazer a modelagem de dados, fornece uma mapeamento dos conceitos de bases de dados de tabelas e relacionamentos para os conceitos UML de classes e associações. O EA suporta a modelagem do esquema de banco de dados e geração automática de scripts para 11 bancos de dados; e) o EA torna mais fácil avaliar a complexidade relativa do projeto, com base no número e tipo de casos de uso, o tipo de projeto e as capacidades do ambiente de desenvolvimento. Com a experiência, as métricas de casos de uso fornecem uma grande maneira de avaliar, rapidamente, o escopo de um projeto. 5.2 HISTÓRICO DE DESENVOLVIMENTO Para o desenvolvimento do sistema, inicialmente, não foi utilizado um procedimento previamente definido. O desenvolvimento iniciou-se a partir da realização de alguns testes de geração de modelos com o Doctrine e da geração da estrutura de diretórios da aplicação. Verificando que era possível prosseguir com o projeto, foram criados alguns artefatos de modelagem definidos na UML (apresentados no capítulo 4), a fim de prever o funcionamento e a interação do sistema com o usuário e organizar o seu desenvolvimento. Quando atingido o objetivo de gerar a parte de gerenciamento de registros (CRUD) das aplicações, com ZF e Doctrine, passaram a ser implementadas algumas melhorias, como validações nos formulários, melhorias de layout e organização de código.

62 61 Não foi definida uma metodologia de desenvolvimento específica, mas, com o decorrer do desenvolvimento do sistema, percebeu-se que foram utilizados alguns princípios da abordagem ágil, como atualizar requisitos de acordo com as necessidades que foram sendo encontradas e criar artefatos de modelagem a cada nova etapa de implementação da ferramenta. 5.3 APRESENTAÇÃO E VALIDAÇÃO DO SISTEMA Serão expostas as telas do sistema em funcionamento, para a criação de uma aplicação de exemplo, que visa ao gerenciamento de um catálogo de produtos. Como o gerador de aplicações é baseado no banco de dados da aplicação, primeiro será apresentado o Modelo Entidade-Relacionamento (MER), que ilustra a modelagem do banco de dados do catálogo de produtos, no Diagrama 7. Diagrama 7 Modelo E-R da aplicação a ser gerada. Fonte: Elaboração do autor (2011). A primeira tela do sistema a ser apresentada, na Figura 20, mostra o formulário que deve ser preenchido com as informações iniciais da aplicação.

63 62 Figura 20 Tela do gerador: configurações iniciais da aplicação. Fonte: Elaboração do autor (2011). Assim que o sistema informar a conclusão da primeira etapa, o usuário poderá prosseguir para a próxima etapa, clicando no link que é disponibilizado na tela. Na etapa seguinte, como mostra a Figura 21, há outras configurações a serem feitas para que a aplicação seja gerada de acordo com a necessidade do usuário. São exibidas opções de geração, de acordo com a estrutura encontrada na conexão com o banco de dados informada no passo anterior. Com as informações corretamente preenchidas, o usuário deverá clicar no botão Criar CRUD. O sistema gerará os arquivos e classes necessários para o gerenciamento dos registros das tabelas selecionadas, com os campos escolhidos pelo usuário, e emitirá uma mensagem informando a conclusão do processo.

64 Figura 21 Tela do gerador: opções para geração do CRUD. Fonte: Elaboração do autor (2011). 63

65 A Figura 22 contém a continuação da tela apresentada na Figura 21. Por ser muito grande, fez-se necessário dividir a imagem em duas. 64 Figura 22 Tela do gerador: opções para geração do CRUD (continuação). Fonte: Elaboração do autor (2011). Concluídas as etapas de criação, a nova aplicação pode ser acessada no navegador de internet. Lembrando que ela conterá apenas as funcionalidades administrativas, ou seja, gerenciamento de registros. Como visto através do MER da aplicação e das telas do gerador, que foram preenchidas com as opções de geração, a aplicação gerada como exemplo terá as funcionalidades CRUD para o gerenciamento de produtos e categorias de produtos. A seguir, algumas telas dessa aplicação serão mostradas. A Figura 23 mostra a tela principal do CRUD de produtos. Essa tela possui essencialmente: a) um link para a inclusão de um novo produto; b) um formulário para busca de produtos cadastrados; c) a listagem de produtos cadastrados, exibida de acordo com os dados filtrados na busca; d) um link único (para cada registro de produto) para: detalhar suas informações, editar seus dados e excluir o registro.

66 65 Figura 23 Tela gerada pelo sistema: Lista de produtos. Fonte: Elaboração do autor (2011). A Figura 24 mostra a tela de edição de um produto. A tela de inclusão possui os mesmos campos, por isso não será apresentada.

67 66 Figura 24 Tela gerada pelo sistema: Editar produto. Fonte: Elaboração do autor (2011). A Figura 25 mostra a tela de exclusão de um produto. Essa tela exibe as informações do produto a ser excluído e pede ao usuário que confirme a exclusão. A tela de detalhes do registro possui as mesmas informações exceto a confirmação de exclusão, por isso não será apresentada.

68 67 Figura 25 Tela gerada pelo sistema: Excluir produto. Fonte: Elaboração do autor (2011). Esse padrão de telas será seguido para todos os cadastros do sistema. O CRUD de categorias possui os mesmos tipos de telas, porém com os campos correspondentes à tabela de categorias. É exatamente esse o objetivo do sistema: criar, automaticamente, telas que costumam se repetir nos sistemas que possuem gerenciamento de registros Avaliação do sistema por voluntário externo Um voluntário, que trabalha diariamente com o desenvolvimento de aplicações que utilizam os frameworks supracitados, realizou uma validação do sistema. Seguem os quesitos avaliados e os comentários correspondentes a cada um: a) quanto à necessidade do sistema, o voluntário diz que a necessidade é pertinente, pois, mesmo usando os frameworks ZF e Doctrine, que visam o aumento da produtividade da equipe, o processo de desenvolvimento de CRUD é um pouco repetitivo, e poderia ser automatizado por uma ferramenta que gerasse o CRUD básico. Depois, o desenvolvedor adicionaria as regras de negócio mais complexas, necessárias para o fluxo da aplicação;

69 68 b) quanto à usabilidade do sistema, a opinião do voluntário é que o sistema está bem simples. Em poucos passos e sem dificuldade, o usuário consegue criar a sua aplicação e fazer o gerenciamento dos registros do seu banco de dados; c) quanto à qualidade da aplicação gerada pelo sistema, o voluntário comenta que a aplicação está com boa qualidade de código e possui as validações necessárias para os campos gerados nos formulários, de acordo com o tipo de campo no banco de dados. No entanto, o voluntário sente a falta de documentação no código gerado (documentação de classes, métodos e variáveis). Ele comenta, também, que algumas funções internas da aplicação que estão sendo feitas na classe de controlador poderiam ser realizadas através das classes de modelo, para que o código fique mais organizado e modularizado. O voluntário, ainda, contribui com uma sugestão de implementação futura para o sistema: a possibilidade de integrar a aplicação com ferramentas de desenvolvimento (como Netbeans) e utilizá-la através de linha de comando. Apesar de perder algumas vantagens da interface gráfica, especialmente as possibilidades de personalização dos campos, o voluntário acredita que essa integração poderia ser atrativa para profissionais que estão acostumados a usar aplicações por linha de comando. 5.4 DISPONIBILIZAÇÃO DA FERRAMENTA Para atendimento dos objetivos específicos deste projeto de conclusão de curso, a ferramenta foi disponibilizada na internet para acesso irrestrito. O sistema desenvolvido foi publicado no site SourceForge O SourceForge funciona como um repositório de código-fonte para projetos Open Source (projetos de código aberto). Através dele é possível promover o desenvolvimento colaborativo de um projeto de software. Pessoas interessadas podem fazer download do projeto, utilizá-lo, trocar conhecimentos, reportar problemas, sugestões e juntar-se à equipe de desenvolvimento para contribuir com o aprimoramento do software.

70 69 O gerador de aplicações desenvolvido neste projeto está publicado no endereço eletrônico sob o título: Gerador de aplicações ZF + Doctrine, como mostra a Figura 26. Figura 26 Página inicial do projeto no SourceForge. Fonte: Elaboração do autor (2011). SourceForge. A Figura 27 mostra a estrutura de diretórios do projeto, publicada no site

71 70 Figura 27 Diretórios e arquivos publicados no SourceForge. Fonte: Elaboração do autor (2011). 5.5 CONSIDERAÇÕES FINAIS DO CAPÍTULO Os recursos computacionais utilizados são os mais atuais para o desenvolvimento de aplicações web na linguagem PHP. A linguagem foi escolhida pela simplicidade e por estar em constante expansão no mercado. Os frameworks foram selecionados devido à necessidade que surgiu em uma equipe de desenvolvimento, citada na justificativa desta monografia, e, também, são bastante vantajosos para o desenvolvimento de software. A escolha da ferramenta CASE Enterprise Architect se deu pela ampla gama de soluções em modelagem de artefatos que a ferramenta oferece.