UNIVERSIDADE DO SUL DE SANTA CATARINA TAYSE CASCAES ARÊAS

Tamanho: px
Começar a partir da página:

Download "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.

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

Table 1. Dados do trabalho

Table 1. Dados do trabalho Título: Desenvolvimento de geradores de aplicação configuráveis por linguagens de padrões Aluno: Edison Kicho Shimabukuro Junior Orientador: Prof. Dr. Paulo Cesar Masiero Co-Orientadora: Prof a. Dr. Rosana

Leia mais

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE Aluno: Roberto Reinert Orientador: Everaldo A. Grahl Roteiro de apresentação Introdução Objetivos Fundamentação Teórica Workflow Processo

Leia mais

Sistema de Ordens de Serviço HDA Soluções em Informática

Sistema de Ordens de Serviço HDA Soluções em Informática UNIVERSIDADE CATÓLICA DE PELOTAS CENTRO POLITÉCNICO Curso Superior de Graduação em ANÁLISE E DESENVOLVIMENTO DE SISTEMAS Sistema de Ordens de Serviço HDA Soluções em Informática Por AUGUSTO CARRICONDE

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

Algumas propriedades dos objetos:

Algumas propriedades dos objetos: Orientação a Objetos Vivemos num mundo de objetos. Esses objetos existem na natureza, nas entidades feitas pelo homem, nos negócios e nos produtos que usamos. Eles podem ser categorizados, descritos, organizados,

Leia mais

SISTEMA DE GERENCIAMENTO E CONTROLE DE DOCUMENTOS DE TCC E ESTÁGIO

SISTEMA DE GERENCIAMENTO E CONTROLE DE DOCUMENTOS DE TCC E ESTÁGIO SISTEMA DE GERENCIAMENTO E CONTROLE DE DOCUMENTOS DE TCC E ESTÁGIO Marcelo Karpinski Brambila 1, Luiz Gustavo Galves Mahlmann 2 1 Acadêmico do Curso de Sistemas de Informação da ULBRA Guaíba < mkbrambila@terra.com.br

Leia mais

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA CAMPUS AVANÇADO DE ARACATI PROJETO DE PESQUISA

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA CAMPUS AVANÇADO DE ARACATI PROJETO DE PESQUISA INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA CAMPUS AVANÇADO DE ARACATI PROJETO DE PESQUISA IMPLEMENTAÇÃO DE SOLUÇÃO PARA AUTOMATIZAR O DESENVOLVIMENTO DE SOFTWARE UTILIZANDO A LINGUAGEM C#.NET

Leia mais

Zend. Framework. Flávio Gomes da Silva Lisboa. Novatec. Desenvolvendo em PHP 5 orientado a objetos com MVC

Zend. Framework. Flávio Gomes da Silva Lisboa. Novatec. Desenvolvendo em PHP 5 orientado a objetos com MVC Zend Framework Desenvolvendo em PHP 5 orientado a objetos com MVC Flávio Gomes da Silva Lisboa Novatec 1 Introdução CAPÍTULO O desenvolvimento de aplicações tornou-se uma atividade extremamente complexa

Leia mais

UML - Unified Modeling Language

UML - Unified Modeling Language UML - Unified Modeling Language Casos de Uso Marcio E. F. Maia Disciplina: Engenharia de Software Professora: Rossana M. C. Andrade Curso: Ciências da Computação Universidade Federal do Ceará 24 de abril

Leia mais

Resumo de TCC Desenvolvimento de um sistema ERP com foco nas tecnologias de software livre / código aberto

Resumo de TCC Desenvolvimento de um sistema ERP com foco nas tecnologias de software livre / código aberto UFSC - Universidade Federal de Santa Catarina CTC Centro Tecnológico INE Departamento de Informática e Estatística INE5631 Projetos I Prof. Renato Cislaghi Resumo de TCC Desenvolvimento de um sistema ERP

Leia mais

LEI DE ACESSO A INFORMAÇÃO DIREITO DO CIDADÃO

LEI DE ACESSO A INFORMAÇÃO DIREITO DO CIDADÃO DESCRIÇÃO DO SIGAI O SIGAI (Sistema Integrado de Gestão do Acesso à Informação) é uma solução de software que foi desenvolvida para automatizar os processos administrativos e operacionais visando a atender

Leia mais

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ ModeloPlanoProjeto_2007_04_24 SIGECO07_PlanoProjeto_2007_09_23 Página

Leia mais

A Linguagem de Modelagem Unificada (UML)

A Linguagem de Modelagem Unificada (UML) Aécio Costa A Linguagem de Modelagem Unificada (UML) Percebeu-se a necessidade de um padrão para a modelagem de sistemas, que fosse aceito e utilizado amplamente. Surge a UML (Unified Modeling Language)

Leia mais

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB)

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) RELATÓRIO DE ENTREGA DO PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) PARA A ELABORAÇÃO DOS PLANOS MUNICIPAIS DE GESTÃO INTEGRADA DE RESÍDUOS SÓLIDOS PMGIRS PARA OS MUNICÍPIOS DE NOVO HORIZONTE, JUPIÁ, GALVÃO,

Leia mais

Documentação do Sistema de Reserva de Salas da Intranet do ICMC-USP

Documentação do Sistema de Reserva de Salas da Intranet do ICMC-USP UNIVERSIDADE DE SÃO PAULO Instituto de Ciências Matemáticas e de Computação Departamento de Ciências da Computação e Estatística Documentação do Sistema de Reserva de Salas da Intranet do ICMC-USP André

Leia mais

Ferramenta: Spider-CL. Manual do Usuário. Versão da Ferramenta: 1.1. www.ufpa.br/spider

Ferramenta: Spider-CL. Manual do Usuário. Versão da Ferramenta: 1.1. www.ufpa.br/spider Ferramenta: Spider-CL Manual do Usuário Versão da Ferramenta: 1.1 www.ufpa.br/spider Histórico de Revisões Data Versão Descrição Autor 14/07/2009 1.0 15/07/2009 1.1 16/07/2009 1.2 20/05/2010 1.3 Preenchimento

Leia mais

Unified Modeling Language UML - Notações

Unified Modeling Language UML - Notações Unified Modeling Language UML - Notações Prof. Ms. Elvio Gilberto da Silva elvio@fmr.edu.br UML Ponto de Vista É gerada com propósito geral de uma linguagem de modelagem visual usada para especificar,

Leia mais

Ambiente Web PHP Problemas Frameworks CakePHP Symfony Zend Framework Prado CodeIgniter Demonstração O livro

Ambiente Web PHP Problemas Frameworks CakePHP Symfony Zend Framework Prado CodeIgniter Demonstração O livro Desenvolvimento em PHP usando Frameworks Elton Luís Minetto Agenda Ambiente Web PHP Problemas Frameworks CakePHP Symfony Zend Framework Prado CodeIgniter Demonstração O livro Ambiente Web É o ambiente

Leia mais

Ambiente Web PHP Problemas Frameworks CakePHP Symfony Zend Framework Prado CodeIgniter Demonstração

Ambiente Web PHP Problemas Frameworks CakePHP Symfony Zend Framework Prado CodeIgniter Demonstração Desenvolvimento em PHP usando Frameworks Elton Luís Minetto Agenda Ambiente Web PHP Problemas Frameworks CakePHP Symfony Zend Framework Prado CodeIgniter Demonstração Ambiente Web É o ambiente formado

Leia mais

Uma Abordagem usando PU

Uma Abordagem usando PU Uma Abordagem usando PU Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Baseada em: Rational Software Corpotation G. Booch, Ivar Jacobson,

Leia mais

Palavras-Chaves: engenharia de requisitos, modelagem, UML.

Palavras-Chaves: engenharia de requisitos, modelagem, UML. APLICAÇÃO DA ENGENHARIA DE REQUISITOS PARA COMPREENSÃO DE DOMÍNIO DO PROBLEMA PARA SISTEMA DE CONTROLE COMERCIAL LEONARDO DE PAULA SANCHES Discente da AEMS Faculdades Integradas de Três Lagoas RENAN HENRIQUE

Leia mais

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade;

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; 1 ARQUITETURA E DESIGN DE SOFTWARE O que é Arquitetura? do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; do dicionário: Arte de projetar e construir prédios,

Leia mais

CURSO DESENVOLVEDOR JAVA Edição 2009

CURSO DESENVOLVEDOR JAVA Edição 2009 CURSO DESENVOLVEDOR JAVA Edição 2009 O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma Orientado a Objetos e com o uso

Leia mais

Modelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza

Modelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Modelagem OO com UML Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Departamento de Informática Centro Tecnológico Universidade Federal do Espírito Santo Modelos Maneira

Leia mais

Os casos de uso dão conta da maioria dos requisitos de um sistema computacional.

Os casos de uso dão conta da maioria dos requisitos de um sistema computacional. Unidade 3: Modelagem de requisitos e de soluções (Parte a) 1 Casos de uso 1.1 Conceitos básicos e parâmetros de descrição Os casos de uso dão conta da maioria dos requisitos de um sistema computacional.

Leia mais

guia prático 2a Edição Gilleanes T.A. Guedes Novatec

guia prático 2a Edição Gilleanes T.A. Guedes Novatec guia prático 2a Edição Gilleanes T.A. Guedes Novatec Copyright 2007, 2014 da Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta

Leia mais

CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias

CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma Orientado a Objetos

Leia mais

Universidade Federal Rural de Pernambuco. Bacharelado em Sistemas de Informação. Disciplina: Análise e Projeto de Sistemas de Informação

Universidade Federal Rural de Pernambuco. Bacharelado em Sistemas de Informação. Disciplina: Análise e Projeto de Sistemas de Informação Universidade Federal Rural de Pernambuco Bacharelado em Sistemas de Informação Disciplina: Análise e Projeto de Sistemas de Informação Docente: Rodrigo Aluna: Thays Melo de Moraes Diagramas do Projeto

Leia mais

SISTEMA GERENCIAL TRATORPLAN

SISTEMA GERENCIAL TRATORPLAN SISTEMA GERENCIAL TRATORPLAN SIGET Fabrício Pereira Santana¹, Jaime William Dias¹, ², Ricardo de Melo Germano¹ ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil fabricioblack@gmail.com germano@unipar.br

Leia mais

CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011

CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011 CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011 O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma

Leia mais

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS RESUMO Este artigo apresenta a especificação de um sistema gerenciador de workflow, o ExPSEE, de acordo com a abordagem de desenvolvimento baseado

Leia mais

UML 2. Guia Prático. Gilleanes T.A. Guedes. Novatec. Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2

UML 2. Guia Prático. Gilleanes T.A. Guedes. Novatec. Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2 UML 2 Guia Prático Gilleanes T.A. Guedes Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2 Novatec capítulo 1 Introdução à UML A UML (Unified Modeling Language ou Linguagem de Modelagem

Leia mais

Figura 1 - Arquitetura multi-camadas do SIE

Figura 1 - Arquitetura multi-camadas do SIE Um estudo sobre os aspectos de desenvolvimento e distribuição do SIE Fernando Pires Barbosa¹, Equipe Técnica do SIE¹ ¹Centro de Processamento de Dados, Universidade Federal de Santa Maria fernando.barbosa@cpd.ufsm.br

Leia mais

Moodle FTEC Versão 2.0 Manual do Usuário Acesse a área de LOGIN do site da FTEC www.ftec.com.br

Moodle FTEC Versão 2.0 Manual do Usuário Acesse a área de LOGIN do site da FTEC www.ftec.com.br Moodle FTEC Versão 2.0 Manual do Usuário Acesse a área de LOGIN do site da FTEC www.ftec.com.br Índice Como acessar o Moodle Editando seu PERFIL Editando o curso / disciplina no Moodle Incluindo Recursos

Leia mais

Engenharia de Software III

Engenharia de Software III Engenharia de Software III Casos de uso http://dl.dropbox.com/u/3025380/es3/aula6.pdf (flavio.ceci@unisul.br) 09/09/2010 O que são casos de uso? Um caso de uso procura documentar as ações necessárias,

Leia mais

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES w w w. i d e a l o g i c. c o m. b r INDICE 1.APRESENTAÇÃO 2.ESPECIFICAÇÃO DOS RECURSOS DO SOFTWARE SAXES 2.1. Funcionalidades comuns a outras ferramentas similares 2.2. Funcionalidades próprias do software

Leia mais

Documento de Arquitetura

Documento de Arquitetura Documento de Arquitetura A2MEPonto - SISTEMA DE PONTO ELETRÔNICO A2MEPonto - SISTEMA DE PONTO ELETRÔNICO #1 Pág. 1 de 11 HISTÓRICO DE REVISÕES Data Versão Descrição Autor 28/10/2010 1 Elaboração do documento

Leia mais

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Tópicos Motivação e Objetivos LP e SOA Processo ADESE

Leia mais

Curso de Aprendizado Industrial Desenvolvedor WEB

Curso de Aprendizado Industrial Desenvolvedor WEB Curso de Aprendizado Industrial Desenvolvedor WEB Disciplina: Programação Orientada a Objetos II Professor: Cheli dos S. Mendes da Costa Modelo Cliente- Servidor Modelo de Aplicação Cliente-servidor Os

Leia mais

Ferramenta para Geração de Código a partir da Especialização do Diagrama de Classes

Ferramenta para Geração de Código a partir da Especialização do Diagrama de Classes Ferramenta para Geração de Código a partir da Especialização do Diagrama de Classes Alexandro Deschamps (Ápice) alexandro@apicesoft.com Everaldo Artur Grahl (FURB/DSC) egrahl@furb.br Resumo. Uma das grandes

Leia mais

UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO. Contribuições do MDA para o desenvolvimento de software

UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO. Contribuições do MDA para o desenvolvimento de software UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO Contribuições do MDA para o desenvolvimento de software Anna Carla Mohr Verner Helder Eugenio dos Santos Puia Florianópolis,

Leia mais

SISTEMA PARA CONTROLE DE RESERVA DE EQUIPAMENTOS MULTIMEIOS E AMBIENTES DE APRENDIZAGEM

SISTEMA PARA CONTROLE DE RESERVA DE EQUIPAMENTOS MULTIMEIOS E AMBIENTES DE APRENDIZAGEM SISTEMA PARA CONTROLE DE RESERVA DE EQUIPAMENTOS MULTIMEIOS E AMBIENTES DE APRENDIZAGEM Marcelo Karpinski Brambila Acadêmico em Sistemas de Informação Universidade Luterana do Brasil Guaíba mkbrambila@connect-rs.com.br

Leia mais

Unisant Anna Gestão Empresarial com ERP 2014 Modelagem de Sistemas - UML e MER

Unisant Anna Gestão Empresarial com ERP 2014 Modelagem de Sistemas - UML e MER Objetivo dessa aula é descrever as características e a simbologia dos diagramas UML e MER na modelagem de sistemas de informação de uma forma a permitir a comunicação entre técnicos e gestores. Modelagem

Leia mais

Artur Petean Bove Júnior Tecnologia SJC

Artur Petean Bove Júnior Tecnologia SJC Artur Petean Bove Júnior Tecnologia SJC Objetivo O objetivo do projeto é especificar o desenvolvimento de um software livre com a finalidade de automatizar a criação de WEBSITES através do armazenamento

Leia mais

Versão <1.0> Documento de Requisitos. Documento de Requisitos. Equipe:

Versão <1.0> Documento de Requisitos. Documento de Requisitos. Equipe: Versão Documento de Requisitos Documento de Requisitos Equipe: Bruno Harada (bhhc) Edilson Augusto Junior (easj) José Ivson Soares da Silva (jiss) Pedro Rodolfo da Silva Gonçalves (prsg) Raphael

Leia mais

ANEXO 11. Framework é um conjunto de classes que colaboram para realizar uma responsabilidade para um domínio de um subsistema da aplicação.

ANEXO 11. Framework é um conjunto de classes que colaboram para realizar uma responsabilidade para um domínio de um subsistema da aplicação. ANEXO 11 O MATRIZ Para o desenvolvimento de sites, objeto deste edital, a empresa contratada obrigatoriamente utilizará o framework MATRIZ desenvolvido pela PROCERGS e disponibilizado no início do trabalho.

Leia mais

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - MÓDULO 3 - MODELAGEM DE SISTEMAS ORIENTADA A OBJETOS COM UML 1. INTRODUÇÃO A partir de 1980, diversos métodos de desenvolvimento de sistemas surgiram para apoiar o paradigma orientado a objetos com uma

Leia mais

PROJETO DA DISCIPLINA. PES II Processo de Engenharia de Software II

PROJETO DA DISCIPLINA. PES II Processo de Engenharia de Software II UNIOESTE - Universidade Estadual do Oeste do Paraná CCET - Centro de Ciências Exatas e Tecnológicas Colegiado de Informática Curso de Bacharelado em Informática PROJETO DA DISCIPLINA PES II Processo de

Leia mais

Documentação de um Produto de Software

Documentação de um Produto de Software Documentação de um Produto de Software Versão 3.0 Autora: Profª Ana Paula Gonçalves Serra Revisor: Prof. Fernando Giorno 2005 ÍNDICE DETALHADO PREFÁCIO... 4 1. INTRODUÇÃO AO DOCUMENTO... 6 1.1. TEMA...

Leia mais

5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância

5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância 5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância O capítulo anterior apresentou uma discussão sobre a inclusão dos chamados learning services no processo

Leia mais

Automação do Processo de Instalação de Softwares

Automação do Processo de Instalação de Softwares Automação do Processo de Instalação de Softwares Aislan Nogueira Diogo Avelino João Rafael Azevedo Milene Moreira Companhia Siderúrgica Nacional - CSN RESUMO Este artigo tem como finalidade apresentar

Leia mais

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de

Leia mais

PRD Tecnologia de Gestão Ltda. Julho/2008

PRD Tecnologia de Gestão Ltda. Julho/2008 O Processo de Desenvolvimento Telescope Julho/2008 Página 1 Sumário Introdução...3 O desenvolvimento de software tradicional...3 O problema da produtividade...3 O problema da portabilidade...6 O problema

Leia mais

Desenvolvendo e Integrando Serviços Multiplataforma de TV Digital Interativa

Desenvolvendo e Integrando Serviços Multiplataforma de TV Digital Interativa Desenvolvendo e Integrando Serviços Multiplataforma de TV Digital Interativa Agenda Introdução Aplicações interativas de TV Digital Desafios de layout e usabilidade Laboratório de usabilidade Desafios

Leia mais

Projeto Disciplinar de Infra-Estrutura de Software SISPA FACULDADE SENAC

Projeto Disciplinar de Infra-Estrutura de Software SISPA FACULDADE SENAC 1 Projeto Disciplinar de Infra-Estrutura de Software SISPA FACULDADE SENAC Edilberto Silva 1, André Luiz (1012545), Andreia Pereira da Silva (1012547) Carlos Alberto (1012206), Humberto César de Carvalho

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento

Leia mais

FACULDADE DE CIÊNCIAS SOCIAIS E APLICADAS DO PARANÁ. Sistema de Gestão Escolar PROJETO FINAL Schola Ratio Versão 8

FACULDADE DE CIÊNCIAS SOCIAIS E APLICADAS DO PARANÁ. Sistema de Gestão Escolar PROJETO FINAL Schola Ratio Versão 8 FACULDADE DE CIÊNCIAS SOCIAIS E APLICADAS DO PARANÁ Sistema de Gestão Escolar PROJETO FINAL Schola Ratio Versão 8 CURITIBA Nov 2012 DJULLES IKEDA OSNIR FERREIRA DA CUNHA Sistema de Gestão Escolar PROJETO

Leia mais

Palavras-Chaves: Arquitetura, Modelagem Orientada a Objetos, UML.

Palavras-Chaves: Arquitetura, Modelagem Orientada a Objetos, UML. MODELAGEM ORIENTADA A OBJETOS APLICADA À ANÁLISE E AO PROJETO DE SISTEMA DE VENDAS ALTEMIR FERNANDES DE ARAÚJO Discente da AEMS Faculdades Integradas de Três Lagoas ANDRE LUIZ DA CUNHA DIAS Discente da

Leia mais

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI Dr. George SILVA; Dr. Gilbert SILVA; Gabriel GUIMARÃES; Rodrigo MEDEIROS; Tiago ROSSINI; Centro Federal de Educação Tecnológica do Rio Grande do

Leia mais

Ferramenta de apoio a gerência de configuração de software. Aluno: Rodrigo Furlaneto Orientador: Everaldo Artur Grahl

Ferramenta de apoio a gerência de configuração de software. Aluno: Rodrigo Furlaneto Orientador: Everaldo Artur Grahl Ferramenta de apoio a gerência de configuração de software Aluno: Rodrigo Furlaneto Orientador: Everaldo Artur Grahl Roteiro de apresentação Introdução Objetivos Fundamentação Teórica Gerência de Configuração

Leia mais

Unioeste Universidade Estadual do Oeste do Paraná

Unioeste Universidade Estadual do Oeste do Paraná Unioeste Universidade Estadual do Oeste do Paraná CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS Colegiado de Informática Curso de Bacharelado em Informática Especificação de Requisitos e Modelagem Orientada

Leia mais

WebUML: Uma Ferramenta Colaborativa de Apoio ao Projeto e Análise de Sistemas Descritos em Classes UML

WebUML: Uma Ferramenta Colaborativa de Apoio ao Projeto e Análise de Sistemas Descritos em Classes UML Carlos Henrique Pereira WebUML: Uma Ferramenta Colaborativa de Apoio ao Projeto e Análise de Sistemas Descritos em Classes UML Florianópolis - SC 2007 / 2 Resumo O objetivo deste trabalho é especificar

Leia mais

DOCUMENTO DE REQUISITOS

DOCUMENTO DE REQUISITOS DOCUMENTO DE REQUISITOS ID documento: Data: / / Versão : Responsável pelo documento: ID Projeto: HISTÓRICO DE REVISÕES Data de criação/ atualização Descrição da(s) Mudança(s) Ocorrida(s) Autor Versão do

Leia mais

A linguagem UML. UML e Diagramas de Casos de Uso e Classes. Por que usar UML? O que é modelagem?

A linguagem UML. UML e Diagramas de Casos de Uso e Classes. Por que usar UML? O que é modelagem? UML e Diagramas de Casos de Uso e Classes Prof. Ms. Luiz Alberto Contato: lasf.bel@gmail.com A linguagem UML UML (Unified Modeling Language) Linguagem de Modelagem Unificada É uma linguagem de modelagem

Leia mais

Diretrizes para criação de um padrão de desenvolvimento de sistemas de informação baseados em cots

Diretrizes para criação de um padrão de desenvolvimento de sistemas de informação baseados em cots Diretrizes para criação de um padrão de desenvolvimento de sistemas de informação baseados em cots Roosewelt Sanie Da Silva¹ 1 Ciência da Computação Universidade Presidente Antônio Carlos (UNIPAC) Rodovia

Leia mais

Reuso. Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior

Reuso. Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Reuso Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Reutilização de Software Na maioria das áreas de engenharia de software, sistemas são desenvolvidos

Leia mais

Planejamento da disciplina: Modelagem de processos de negócio

Planejamento da disciplina: Modelagem de processos de negócio UNIVERSIDADE FEDERAL DE MINAS GERAIS / INSTITUTO DE CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO Planejamento da disciplina: Modelagem de processos de negócio Professor: Clarindo Isaías Pereira

Leia mais

UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS

UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS Edi Carlos Siniciato ¹, William Magalhães¹ ¹ Universidade Paranaense (Unipar) Paranavaí PR Brasil edysiniciato@gmail.com,

Leia mais

Gerenciador Financeiro CITi. Gerenciador Financeiro CITi

Gerenciador Financeiro CITi. Gerenciador Financeiro CITi (Sistema de Gerenciamento Financeiro) Especificação dos Requisitos do Software Gerenciador Financeiro CITi Versão 1.0 Autores: Bruno Medeiros de Oliveira Igor Rafael Medeiros Pedro Araújo de Melo Tiago

Leia mais

PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS

PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS Élysson Mendes Rezende Bacharelando em Sistemas de Informação Bolsista de Iniciação Científica

Leia mais

Engenharia de Software na Prática Hélio Engholm Jr.

Engenharia de Software na Prática Hélio Engholm Jr. Engenharia de Software na Prática Hélio Engholm Jr. Novatec Sumário Agradecimentos... 17 Sobre o autor... 18 Prefácio... 19 Capítulo 1 Desenvolvimento de software para o valor de negócios... 20 1.1 Qualidade

Leia mais

Estudo de Caso Sistema de Caixa Automático

Estudo de Caso Sistema de Caixa Automático Estudo de Caso Sistema de Caixa Automático Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Notas de Aula Ulrich Schiel Notas de Aula Ariadne

Leia mais

Projeto Disciplinar de Infra-Estrutura de Software ECOFROTA TRIBUNAL THEMIS

Projeto Disciplinar de Infra-Estrutura de Software ECOFROTA TRIBUNAL THEMIS 1 Projeto Disciplinar de Infra-Estrutura de Software ECOFROTA TRIBUNAL THEMIS EDILBERTO SILVA 1, AQUILA ISRAEL (1316079) 2, CYNTHIA FERREIRA (1316079) 2, MARKO DE CASTRO (1316119) 2, RAFAELA ALMEIDA (1316189)

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação SOFT DISCIPLINA: Engenharia de software AULA NÚMERO: 08 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir conceitos relacionados a modelos e especificações. Nesta aula

Leia mais

4 O Workflow e a Máquina de Regras

4 O Workflow e a Máquina de Regras 4 O Workflow e a Máquina de Regras O objetivo do workflow e da máquina de regras é definir um conjunto de passos e regras configuráveis. Ao longo de sua execução, um usuário consegue simplificar o seu

Leia mais

Roteiro 2 Conceitos Gerais

Roteiro 2 Conceitos Gerais Roteiro 2 Conceitos Gerais Objetivos: UC Projeto de Banco de Dados Explorar conceitos gerais de bancos de dados; o Arquitetura de bancos de dados: esquemas, categorias de modelos de dados, linguagens e

Leia mais

Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional

Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional Juarez Bachmann Orientador: Alexander Roberto Valdameri Roteiro Introdução Objetivos Fundamentação teórica Desenvolvimento

Leia mais

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio 32 3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio Este capítulo apresenta o framework orientado a aspectos para monitoramento e análise de processos de negócio

Leia mais

Portal Web para empresa de materiais de construção civil CasaMais

Portal Web para empresa de materiais de construção civil CasaMais Portal Web para empresa de materiais de construção civil CasaMais Gilberto Leonel Dias Pereira nº 26634 Trabalho realizado sob a orientação de: Professor João Paulo Ribeiro Pereira Informática de Gestão

Leia mais

Eduardo Bezerra. Editora Campus/Elsevier

Eduardo Bezerra. Editora Campus/Elsevier Princípios de Análise e Projeto de Sistemas com UML 2ª edição Eduardo Bezerra Editora Campus/Elsevier Capítulo 11 Arquitetura do sistema Nada que é visto, é visto de uma vez e por completo. --EUCLIDES

Leia mais

Sistema Gerenciador de Hotel. Adriano Douglas Girardello. Ana Paula Fredrich. Tiago Alexandre Schulz Sippert

Sistema Gerenciador de Hotel. Adriano Douglas Girardello. Ana Paula Fredrich. Tiago Alexandre Schulz Sippert UNIOESTE Universidade Estadual do Oeste do Paraná CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS Colegiado de Informática Curso de Bacharelado em Informática Sistema Gerenciador de Hotel Adriano Douglas Girardello

Leia mais

ARQUITETURA DE SISTEMAS. Cleviton Monteiro (cleviton@gmail.com)

ARQUITETURA DE SISTEMAS. Cleviton Monteiro (cleviton@gmail.com) ARQUITETURA DE SISTEMAS Cleviton Monteiro (cleviton@gmail.com) Roteiro Definição Documento de arquitetura Modelos de representação da arquitetura Estilos arquiteturais Arquitetura de sistemas web Arquitetura

Leia mais

Criando Aplicações PHP com. Zend e Dojo. Flávio Gomes da Silva Lisboa. Novatec

Criando Aplicações PHP com. Zend e Dojo. Flávio Gomes da Silva Lisboa. Novatec Criando Aplicações PHP com Zend e Dojo Flávio Gomes da Silva Lisboa Novatec Copyright 2013 da Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a

Leia mais

Engenharia de Requisitos Estudo de Caso

Engenharia de Requisitos Estudo de Caso Engenharia de Requisitos Estudo de Caso Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2007 Slide 1 Engenharia de Requisitos Exemplo 1 Reserva de Hotel 1. INTRODUÇÃO Este

Leia mais

MODELAGEM DE PROCESSOS

MODELAGEM DE PROCESSOS MODELAGEM DE PROCESSOS a a a PRODUZIDO POR CARLOS PORTELA csp3@cin.ufpe.br AGENDA Definição Objetivos e Vantagens Linguagens de Modelagem BPMN SPEM Ferramentas Considerações Finais Referências 2 DEFINIÇÃO:

Leia mais

GeCA: Uma Ferramenta de Engenharia Reversa e Geração Automática de Código

GeCA: Uma Ferramenta de Engenharia Reversa e Geração Automática de Código GeCA: Uma Ferramenta de Engenharia Reversa e Geração Automática de Código Igor Steinmacher 1, Éderson Fernando Amorim 1, Flávio Luiz Schiavoni 1, Elisa Hatsue Moriya Huzita 1 1 Departamento de Informática

Leia mais

RESUMO DA SOLUÇÃO CA ERwin Modeling. Como eu posso gerenciar a complexidade dos dados e aumentar a agilidade dos negócios?

RESUMO DA SOLUÇÃO CA ERwin Modeling. Como eu posso gerenciar a complexidade dos dados e aumentar a agilidade dos negócios? RESUMO DA SOLUÇÃO CA ERwin Modeling Como eu posso gerenciar a complexidade dos dados e aumentar a agilidade dos negócios? O CA ERwin Modeling fornece uma visão centralizada das principais definições de

Leia mais

EMISSÃO DE CERTIFICADOS ELETRÔNICOS NOS EVENTOS DO INSTITUTO FEDERAL CATARINENSE CÂMPUS VIDEIRA

EMISSÃO DE CERTIFICADOS ELETRÔNICOS NOS EVENTOS DO INSTITUTO FEDERAL CATARINENSE CÂMPUS VIDEIRA EMISSÃO DE CERTIFICADOS ELETRÔNICOS NOS EVENTOS DO INSTITUTO FEDERAL CATARINENSE CÂMPUS VIDEIRA Jeferson Boesing 1 ; Tiago Heineck 2 ; Angela Maria Crotti da Rosa 3 ; Leila Lisiane Rossi 4 INTRODUÇÃO Alunos

Leia mais

Casos de Uso O que é. Casos de Uso. Objetivos de um Caso de Uso. Atores. Atores e Casos de Uso. Diagramas de Caso de Uso

Casos de Uso O que é. Casos de Uso. Objetivos de um Caso de Uso. Atores. Atores e Casos de Uso. Diagramas de Caso de Uso Casos de Uso O que é Casos de Uso Descrições narrativas de processos do domínio da aplicação Documentam a seqüência de eventos de um ator (um agente externo) usando o sistema para completar, do início

Leia mais

SAPENS - Sistema Automático de Páginas de Ensino

SAPENS - Sistema Automático de Páginas de Ensino SAPENS - Sistema Automático de Páginas de Ensino Eduardo Kokubo kokubo@inf.univali.br Fabiane Barreto Vavassori, MSc fabiane@inf.univali.br Universidade do Vale do Itajaí - UNIVALI Centro de Ensino Superior

Leia mais

Essencial ao Desenvolvimento de Software

Essencial ao Desenvolvimento de Software Documento de Requisitos Essencial ao Desenvolvimento de Software De que se trata o artigo? Apresenta o documento de requisitos de software, destacando-o como um dos principais documentos pertinentes ao

Leia mais

EMISSÃO DE CERTIFICADOS ELETRÔNICOS NOS EVENTOS DO INSTITUTO FEDERAL CATARINENSE CÂMPUS VIDEIRA

EMISSÃO DE CERTIFICADOS ELETRÔNICOS NOS EVENTOS DO INSTITUTO FEDERAL CATARINENSE CÂMPUS VIDEIRA EMISSÃO DE CERTIFICADOS ELETRÔNICOS NOS EVENTOS DO INSTITUTO FEDERAL CATARINENSE CÂMPUS VIDEIRA Autores : Jeferson BOESING; Tiago HEINECK; Angela Maria Crotti da ROSA; Leila Lisiane ROSSI Identificação

Leia mais

FERRAMENTA PARA CONSTRUÇÃO DE INTERFACES DE SOFTWARE A PARTIR DE DIAGRAMA DE CLASSES

FERRAMENTA PARA CONSTRUÇÃO DE INTERFACES DE SOFTWARE A PARTIR DE DIAGRAMA DE CLASSES FERRAMENTA PARA CONSTRUÇÃO DE INTERFACES DE SOFTWARE A PARTIR DE DIAGRAMA DE CLASSES Aluno: André Luis Becker Orientador: Prof. Everaldo Artur Grahl. Mestre Orientador, FURB Roteiro da Apresentação Introdução;

Leia mais

Desenvolvendo Aplicações Web com NetBeans

Desenvolvendo Aplicações Web com NetBeans Desenvolvendo Aplicações Web com NetBeans Aula 3 Cap. 4 Trabalhando com Banco de Dados Prof.: Marcelo Ferreira Ortega Introdução O trabalho com banco de dados utilizando o NetBeans se desenvolveu ao longo

Leia mais

Notas de Aula 05: Aplicação de um caso de uso

Notas de Aula 05: Aplicação de um caso de uso Notas de Aula 05: Aplicação de um caso de uso Objetivos da aula: Aprender a aplicar a técnica de casos de uso em um pequeno problema real Identificar as variáveis relevantes a serem consideradas Modelar

Leia mais

CONTRA CONTROLE DE ACESSOS E MODULARIZADOR DE SISTEMAS

CONTRA CONTROLE DE ACESSOS E MODULARIZADOR DE SISTEMAS MINISTÉRIO DO DESENVOLVIMENTO AGRÁRIO SUBSECRETARIA DE PLANEJAMENTO, ORÇAMENTO E ADMINISTRAÇÃO COORDENAÇÃO-GERAL DE MODERNIZAÇÃO E INFORMÁTICA CONTRA CONTROLE DE ACESSOS E MODULARIZADOR DE SISTEMAS MANUAL

Leia mais

MONITORAMENTO REMOTO DO CONSUMO DE ÁGUA UTILIZANDO SOFTWARE DE INTERFACE HOMEM-MÁQUINA - HIDROAER

MONITORAMENTO REMOTO DO CONSUMO DE ÁGUA UTILIZANDO SOFTWARE DE INTERFACE HOMEM-MÁQUINA - HIDROAER MONITORAMENTO REMOTO DO CONSUMO DE ÁGUA UTILIZANDO SOFTWARE DE INTERFACE HOMEM-MÁQUINA - HIDROAER Alex Lage de Morais 1 ; Wilson Cabral de Sousa Jr. 2 ;Elaine Nolasco Ribeiro 3 RESUMO - Uma parte do projeto

Leia mais

PROGRAMAÇÃO MVC E ZEND FRAMEWORK

PROGRAMAÇÃO MVC E ZEND FRAMEWORK PROGRAMAÇÃO MVC E ZEND FRAMEWORK MVC PROGRAMMING AND ZEND FRAMEWORK Rodolfo Vinícius Moimas Dias Centro Universitário Filadélfia de Londrina UniFil Rafael Francovig Cavicchioli Centro Universitário Filadélfia

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais