FATEC - FACULDADE DE TECNOLOGIA DO ESTADO DE SÃO PAULO EDINEI FABIANO FEDEL DOS SANTOS LÉIA LUCIA DE LEMOS

Transcrição

1 FATEC - FACULDADE DE TECNOLOGIA DO ESTADO DE SÃO PAULO EDINEI FABIANO FEDEL DOS SANTOS LÉIA LUCIA DE LEMOS DESENVOLVIMENTO ÁGIL DE SOFTWARE COM ARQUITETURA MULTICAMADAS PARA APLICAÇÕES JAVA WEB SÃO JOSÉ DOS CAMPOS 2010

2 i EDINEI FABIANO FEDEL DOS SANTOS LÉIA LUCIA DE LEMOS DESENVOLVIMENTO ÁGIL DE SOFTWARE COM ARQUITETURA MULTICAMADAS PARA APLICAÇÕES JAVA WEB. Trabalho de graduação apresentado à Faculdade de Tecnologia de São José dos Campos como parte dos requisitos necessários para obtenção do título de Tecnólogo em Banco de Dados. Orientador: Profº Rogério Marinke. SÃO JOSÉ DOS CAMPOS 2010

3 ii EDINEI FABIANO FEDEL DOS SANTOS LÉIA LUCIA DE LEMOS DESENVOLVIMENTO ÁGIL DE SOFTWARE COM ARQUITETURA MULTICAMADAS PARA APLICAÇÕES JAVA WEB. Trabalho de graduação apresentado à Faculdade de Tecnologia de São José dos Campos como parte dos requisitos necessários para obtenção do título de Tecnólogo em Banco de Dados. REINALDO ARAKAKI - DOUTOR CAIO MONTEIRO BARBOSA DA SILVA - MESTRE ROGÉRIO MARINKE - GRADUADO / / DATA DE APROVAÇÃO

4 iii RESUMO O objetivo deste trabalho é apresentar o desenvolvimento utilizando métodos ágeis para a construção de software com arquitetura multicamadas para aplicações Java Web guiado por soluções e tecnologias de apoio. O estudo de caso consiste no desenvolvimento dos módulos financeiro, compras, vendas e administrativo de uma aplicação ERP (Enterprise Resource Planning). ERP s são definidos como sistemas de informação integrados distribuídos na forma de pacotes comerciais que permitem a integração e as interações entre os diferentes setores e operações de uma empresa. Como estudo de caso foi adotado uma empresa distribuidora de alimentos da cidade de São José dos Campos/SP, onde a aplicação proposta será implantada. A metodologia adotada foi a XP (Extreme Programming), que permitiu utilizar a maior parte do tempo disponível para o desenvolvimento e testes da aplicação, ao contrário do que geralmente acontece quando se utiliza metodologias tradicionais. A arquitetura está baseada na utilização de frameworks para o auxílio no desenvolvimento e na reutilização de soluções já existentes conhecidas como padrões de projetos, com o objetivo de tornar o sistema modular, permitindo o reuso na construção dos componentes e capacitando a arquitetura ser estendida ou modificada de forma ágil e eficiente, bem como buscar atender a alta coesão e o baixo acoplamento entre os componentes. Palavras-chave: Java, Arquitetura, Frameworks, Padrões de Projeto, Extreme Programming, ERP.

5 iv ABSTRACT The aim of this paper is to present the software development using agile methodology based on multilayers architecture for Java Web Applications, guided by solutions and support technologies. The case study consists on development of modules for the departments financial, purchasing, sales and administrative for an ERP (Enterprise Resource Planning) application. ERPs are defined as integrated information systems distributed in the form of commercial software packages that allow the integration and interactions among different departments and operations of a company. As a case study was adopted a food distributor company from São José dos Campos/SP, where the proposed application will be deployed. The methodology adopted was XP (Extreme Programming), which allowed to use the most of the available time for development and testing of the application, contrary to what usually happens when using traditional methodologies. The architecture is based on using of frameworks for helping in the development and reuse of existing solutions well known as Design Patterns, with the goal of making the system modular, allowing the reuse in building of components and enabling the architecture to be extended and modified quickly and efficiently, and seek to attend the high cohesion and low coupling among the components. Keywords: Java, Architecture, Frameworks, Design Patterns, Extreme Programming, ERP.

6 v LISTA DE FIGURAS Figura 1 - Arquitetura JEE Figura 2 - Ciclo de vida da Servlet Figura 3 - IDE NetBeans Figura 4 - IDE Eclipse 3.5 Galileo Figura 5 - Visão geral dos módulos do Spring Framework Figura 6 - Diagrama de requisições ao servidor Figura 7 - A ferramenta de teste JUnit Figura 8 - Um teste unitário no TestNG Figura 9 - Ambiente StarUML Figura 10 - Ambiente JUDE/Community Figura 11 - Arquitetura n-camadas Figura 12 - Desenvolvimento incremental Figura 13 - Diagrama de caso de uso do Sistema Figura 14 - Cartões de história do usuário Figura 15 - Cartões de história das qualidades do sistema Figura 16 - Arquitetura do Sistema Figura 17 - Diagrama de Classe do Sistema Figura 18 - Modelo Relacional do Banco de Dados Figura 19 - Dados não centralizados Figura 20 - Arquitetura de um sistema ERP Figura 21 - Entidade Categoria mapeada Figura 22 - O arquivo persistence.xml Figura 23 - A interface DaoGenerico Figura 24 - Spring atuando no Dao Figura 25 - Teste unitário com Spring e TestNG Figura 26 - Estrutura básica de um projeto Maven Figura 27 - O arquivo pom.xml Figura 28 - Resultados da execução da fase package do Maven Figura 29 - Tela de Login

7 vi Figura 30 - Tags da tela Login e o Managed Bean usuariocontroller Figura 31 - A classe UsuarioController Figura 32 - O arquivo faces-config.xml Figura 33 - Tela de Login Figura 34 - Tela de Cadastro de Clientes Figura 35 - Tela de Pesquisa de Produtos Figura 36 - Tela de Cadastro de Produtos Figura 37 - Diagrama de seqüência cadastrar pedido Figura 38 - Diagrama de seqüência processar pedido Figura 39 - Diagrama de seqüência emitir nota fiscal Figura 40 - Diagrama de seqüência atualiza contas a receber

8 vii LISTA DE TABELAS Tabela 1 - Comparativo entre as IDE s Eclipse e NetBeans Tabela 2 - Especificação do caso de uso cadastrar pedido Tabela 3 - Especificação do caso de uso consultar produto Tabela 4 - Especificação do caso de uso editar dados do cliente Tabela 5 - Especificação do caso de uso cancelar pedido Tabela 6 - Especificação do caso de uso processar pedido Tabela 7 - Especificação do caso de uso emitir nota fiscal Tabela 8 - Especificação do caso de uso atualizar saída de produto Tabela 9 - Especificação do caso de uso atualizar entrada de produto

9 viii LISTA DE ABREVIATURAS E SIGLAS AJAX: Asynchronous Javascript and XML AOP: Aspect Oriented Programming API: Application Program Interface ASP: Active Server Pages CDK: Component Development Kit CGI: Common Gateway Interface CSS: Cascading Style Sheet DAO: Data Access Object DOM: Document Object Model EJB: Enterprise JavaBeans ERP: Enterprise Resource Planning GIF: Graphics Interchange Format GUI: Graphical User Interface HQL: Hibernate Query Language HTML: HyperText Markup Language HTTP: Hypertext Transfer Protocol IDE: Integrated Development Environment IoC: Inversion of Control JCA: J2EE Connector Architecture JCP: Java Community Process JDBC: Java Database Connectivity JDO: Java Data Objects JEE: Java Platform Enterprise Edition JEMS: JBoss Enterprise Middleware Suite JMS: Java Message Service JMX: Java Management Extensions JPA: Java Persistence API JSE: Java Standard Edition

10 ix JSF: JavaServer Faces JSP: JavaServer Pages JTA: Java Transaction API JVM: Java Virtual Machine MDA: Model Driven Architecture MVC: Model View Controller MRPII: Manufacturing Resource Planning OJB: ObJectRelationalBridge ORM: Object Relational Mapping PL/SQL: Procedural Language/Structured Query Language POM: Project Object Model POJO: Plain Old Java Objects RH: Recursos Humanos SGBD: Sistema Gerenciador de Banco de Dados SIG: Sistemas Integrados de Gestão SVN: Subversion SQL: Structured Query Language TDD: Test Driven Development UI: User Interface UML: Unified Modeling Language XHTML: extensible Hypertext Markup XML: extensible Markup Language XP: Extreme Programming

11 12 SUMÁRIO 1 INTRODUÇÃO MOTIVAÇÃO OBJETIVOS Objetivo Geral Objetivos Específicos METODOLOGIA ORGANIZAÇÃO DO TRABALHO TECNOLOGIAS EXISTENTES JAVA JEE Servlets JSP EJB Java Persistence API Java Database Connectivity AMBIENTE INTEGRADO DE DESENVOLVIMENTO Netbeans Eclipse FRAMEWORKS Frameworks de Regras de Negócio Struts Webwork Spring Frameworks de Persistência Oracle TopLink Hibernate Frameworks e Tecnologias de Apresentação JavaServer Faces Facelets RichFaces AJAX Frameworks de Teste... 33

12 JUnit TestNG FERRAMENTAS CASE StarUML JUDE/Community FERRAMENTAS PARA O PROCESSO DE CONSTRUÇÃO DE SOFTWARE Ant Maven CONTAINER WEB Tomcat SERVIDORES DE APLICAÇÃO WebSphere Glassfish JBoss Aplication Server BANCO DE DADOS Firebird MySQL Oracle 10g Express Edition PostgreSQL MODELAGEM E ARQUITETURA DE UM SISTEMA WEB PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Processo incremental Programação Extrema (XP) Práticas da XP PROCESSO INCREMENTAL PARA DESENVOLVIMENTO DE UM SISTEMA ERP Requisitos Funcionais Requisitos Não Funcionais Diagramas de caso de uso Documentos de casos de uso Diagrama de Seqüência PROCESSO XP PARA DESENVOLVIMENTO DE UM SISTEMA ERP Jogo de Planejamento Cartões de História (Story Cards) Qualidades do sistema DECISÕES DE PROJETO Banco de dados IDE... 57

13 Ferramenta Case Testes Processo de construção de software Container Persistência Objeto-Relacional Injeção de dependência Interface gráfica ARQUITETURA DO SISTEMA DIAGRAMA DE CLASSE MODELO DO BANCO DE DADOS ESTUDO DE CASO SISTEMAS ERP ARQUITETURA DE SISTEMAS ERP ANÁLISE E RESULTADOS DETALHES DE IMPLEMENTAÇÃO Entidades persistentes com JPA DAO Genérico O DAO e a integração Spring e JPA O Spring e o TestNG O Maven e o processo de construção de software O JSF e o padrão de projeto MVC TELAS DO SISTEMA CONSIDERAÇÕES FINAIS CONTRIBUIÇÕES E CONCLUSÕES TRABALHOS FUTUROS REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICES... 94

14 15 1 Introdução 1.1 Motivação Os sistemas de informação em geral são entidades que estão quase sempre em processo de mudanças. Essas alterações ocorrem pela necessidade na correção de falhas existentes ou na adição de novas funcionalidades. No entanto esse processo evolutivo do software pode ser causa de insucesso em projetos de desenvolvimento de software, como o atraso na entrega ou o custo acima do estimado (FOWLER, 2002). De acordo com uma pesquisa realizada em 2009 pela Standish Group, organização que realiza estatísticas periódicas sobre o sucesso e o fracasso de projetos de desenvolvimento de software, 32% dos projetos foram finalizados no tempo e custos previstos, 44% dos projetos atrasaram e 24% dos projetos foram cancelados antes de finalizarem. Paralelo a estes fatos o aumento da complexidade dos sistemas exigem um alto nível de abstração para projetar, codificar e realizar a comunicação entre os componentes de software. Portanto, um projeto de arquitetura é determinante para o sucesso do sistema e a presença de um plano arquitetural fornece benefícios em todas as fases do ciclo de vida do sistema, sobretudo por meio do reuso de componentes (ALUR et. al., 2003). A arquitetura de sistemas define e representa os componentes de software, as propriedades externamente visíveis desses componentes e as relações entre eles, ou seja, a arquitetura vai além de algoritmos e das estruturas de dados computacionais, ela pode ser entendida como a especificação e organização fundamental de um sistema (PRESSMAN, 2001). A definição da arquitetura é uma forma de encorajar o reuso e a padronização de componentes e estrutura através do uso de soluções e tecnologias existentes, guiando o ciclo de desenvolvimento de software, tornando-o mais ágil (SOMMERVILE, 2007). Portanto, este trabalho foi encorajado pela necessidade de uma arquitetura de sistema que fornecesse à reutilização de componentes e frameworks, em resposta a crescente demanda por desenvolvimento rápido e eficiente de softwares. Este trabalho segue o padrão arquitetural em camadas e está baseado em alguns padrões de projetos. Além disso, alguns frameworks de apoio ao desenvolvimento foram integrados a arquitetura, auxiliando o desenvolvimento e viabilizando a proposta do trabalho.

15 16 É importante observar que a proposta do trabalho deve estar relacionada com a estratégia de especificação dos requisitos do sistema, ou seja, a arquitetura deve estar de acordo com o escopo necessário, mas suficientemente flexível e preparada para incorporar e absorver mudanças futuras. 1.2 Objetivos Objetivo Geral O objetivo deste trabalho é apresentar o desenvolvimento utilizando métodos ágeis para a construção de software com arquitetura multicamadas para aplicações Java Web Objetivos Específicos A seguir serão apresentados os objetivos específicos: a) Apresentar a modelagem utilizando o processo incremental de desenvolvimento de software; b) Apresentar a modelagem utilizando a metodologia ágil Extreme Programming; c) Utilizar frameworks e padrões de projeto viabilizando a arquitetura proposta; d) Utilizar o paradigma da metodologia ágil Extreme Programming no desenvolvimento do protótipo; e) Desenvolver um protótipo do módulo administrativo, financeiro, compras vendas de um sistema Enterprise Resource Planning (ERP). 1.3 Metodologia Como estudo de caso foi adotado uma empresa fornecedora de alimentos da cidade de SÃO JOSÉ DOS CAMPOS/SP. Com base nas entrevistas com o cliente foi possível levantar os requisitos funcionais do sistema, viabilizando a atividade de modelagem e a definição da arquitetura do sistema. Dos diagramas que compõem a UML, os escolhidos para modelagem foram: diagrama de classe, diagrama de caso de uso e diagrama de seqüência.

16 17 Na implementação utilizou-se tecnologias de desenvolvimento e a linguagem de programação Java para Web, que em conjunto com o padrão MVC (Model-View-Controller) tornou possível a separação da regra de negócios da interface gráfica do sistema. Na camada Model a integração do framework Hibernate com a especificação JPA visa reduzir a complexidade da programação orientada a objetos utilizando banco de dados relacionais. O JavaServer Faces e o Facelets facilitam a padronização de layouts na camada View. E o Spring Framework, localizado na camada Controller, permite o baixo acoplamento entre as classes através da Inversão de Controle. 1.4 Organização do Trabalho Este Trabalho está organizado por seis capítulos de seguinte maneira: Capítulo 1: Discorre-se sobre a problemática endereçada em termos de motivação, objetivo, metodologia e organização do trabalho. Capítulo 2: Tecnologias existentes, onde são apresentados os frameworks e tecnologias disponíveis para plataforma Java, abordando suas principais funcionalidades e características. Capítulo 3: Modelagem e arquitetura de um sistema Web, onde são abordados os processos de desenvolvimento incremental e XP, apresentando a modelagem de ambos e os seus artefatos, bem como as decisões de projeto e a arquitetura proposta do sistema. Capítulo 4: Estudo de caso, onde são apresentados os relatos sobre a empresa analisada, bem como a descrição do que são sistemas ERP s abordando suas principais características e funcionalidades. Capítulo 5: Análise e resultados, onde são apresentados os resultados provenientes do estudo de caso, demonstrando os principais aspectos da implementação e as telas do protótipo. Capítulo 6: Conclui o trabalho apontando os resultados alcançados e os trabalhos futuros.

17 18 2 Tecnologias Existentes Neste capítulo serão abordadas tecnologias existentes utilizadas na modelagem e desenvolvimento de software, apresentando os principais recursos e funcionalidades das mesmas. 2.1 Java Java é uma linguagem orientada a objetos desenvolvida pela Sun Microsystems, influenciada por C++. A linguagem Java foi projetada para ser pequena, simples e portátil entre diferentes plataformas e sistemas operacionais (LEMAY e PERKINS, 1996). Segundo o autor, JAVA possui as seguintes características: a) Simples: Java possui uma sintaxe simples similar a linguagens C e C++, porém muito da complexidade destas linguagens foram removidas de Java, tais como utilização de ponteiros, a fim de tornar JAVA mais fácil de ser utilizado e menos propenso a erros; b) Orientada a Objetos: permite utilizar todos os benefícios da orientação a objeto, tais como encapsulamento, herança e polimorfismo. Todo o código é encapsulado em classes, tornando o código JAVA modular, flexível e mais legível; c) Independente de plataforma: é uma de suas principais vantagens sobre outras linguagens, pois pode ser executada em diferentes plataformas, sem a necessidade de re-compilar ou reescrever o código JEE Java Platform Enterprise Edition (JEE) é uma plataforma para desenvolvimento Java de aplicações voltadas para internet, redes ou intranet, pois fornece bibliotecas para desenvolvimento de software distribuído e multicamadas que executam em um servidor de aplicações. O JEE incorpora outras especificações, incluindo a especificação Servlets e a especificação JSP, isto para um container Web, mas também inclui a especificação Enterprise JavaBeans para um container EJB (BASHAM, SIERRA e BATES, 2008). A Figura 1 apresenta a arquitetura JEE.

18 19 Figura 1 - Arquitetura JEE. Fonte: Adaptada de SUN (2009) Servlets Servlet é uma tecnologia Java em resposta ao Common Gateway Interface (CGI). As servlets são pequenos programas que rodam em um servidor, atuando na camada entre requisições HTTP vindas do cliente e o banco de dados. As Servlets levam vantagem sobre o CGI por ser multithread ao invés de exigir um novo processo para cada requisição, e também por ter acesso a ampla biblioteca Java (HALL, 2000). De acordo com Arulkumaran e Sivayini (2007) as servlets interceptam as solicitações vindas do cliente, como por exemplo, dados provenientes de um formulário Web, em seguida enviam as solicitações para um modelo de lógica (model), como por exemplo, o EJB, que por sua vez interage com o banco de dados e finalmente seleciona uma forma de exibição (view), que pode ser HTML, JSP, ou mesmo imagens GIF, para a entrega e apresentação do resultado ao cliente, atuando como o controlador (controller) do padrão de projeto MVC. O ciclo de vida de uma Servlet é controlado pelo Container Web. Esta é uma das principais responsabilidades do Container Web. Quando uma solicitação é entregue a uma servlet, o container executa os seguintes passos: a) Carrega a classe Servlet; b) Cria uma instância da Servlet; c) Inicializa a instância servlet criada anteriormente chamando o método init(); d) Chama o método service() tornando a servlet pronta para processar as solicitações. Neste passo as informações de solicitação e resposta são encapsuladas nos objetos ServletRequest e ServletResponse respectivamente, passados como parâmetro do método service() da servlet.

19 20 Quando o container determina a remoção da servlet, ele chama o método destroy () da instância servlet, permitindo que a servlet libere seus recursos, como por exemplo, fechar conexões com o banco de dados, e finalmente esteja qualificada para o coletor de lixo. Cada servlet tem o mesmo ciclo de vida e elas podem processar zero ou muitas solicitações dos clientes (BASHAM, SIERRA e BATES, 2008). A Figura 2 mostra o ciclo de vida de uma Servlet. Figura 2 - Ciclo de vida da Servlet. Fonte: Adaptada de Brill (2001) JSP A tecnologia JavaServer Pages (JSP) desenvolvida pela Sun é uma extensão da tecnologia Java Servlet, similar às tecnologias Active Server Pages (ASP) da Microsoft e PHP. As páginas JSP são usadas como uma camada de apresentação que combina HTML e código Java para produzir conteúdo web dinâmico (Arulkumaran e Sivayini, 2007). O JSP torna-se internamente em uma servlet como qualquer outra rodando na aplicação. Isso porque o Container traduz o JSP para um arquivo-fonte (.java) e depois o compila em uma servlet Java. A servlet compilada manipula as solicitações como qualquer outra servlet escrita, mas gerada pelo Container. Portanto, o JSP fornece uma forma mais conveniente de criar servlets, pois elas são criadas em tempo de execução (BASHAM, SIERRA e BATES, 2008).

20 EJB A arquitetura Enterprise JavaBeans (EJB) é uma arquitetura de componentes para desenvolvimento e implantação de componentes distribuídos baseados em aplicações de negócios. As aplicações escritas usando EJB são escaláveis, transacionais e multiusuários seguros. O container EJB define um conjunto de componentes que para serem executados em seu ambiente precisam atender as certas especificações. Um componente EJB possui três tipos fundamentais: Entity beans, Session Beans e Message Drive Beans. O Entity Beans é utilizado para modelar entidades de mundo real ou entidades que já estejam representadas em um banco de dados através de tabelas, ou seja, representam um objeto que vai persistir num banco de dados ou em outra unidade de armazenamento. O Session Beans representa um único cliente dentro de um servidor JEE, ele executa o trabalho para o seu cliente protegendo-o da complexidade através da execução de tarefas de negócios dentro do servidor. Um session bean não é compartilhado, o bean é único para cada cliente e quando uma sessão é finalizada o session bean morre, uma vez que seus dados não são armazenados em uma base de dados. O Message Drive Beans é um EJB que permite as aplicações JEE processarem mensagens de modo assíncrono. Age como um listener de mensagens Java Message Service (JMS) (BURKE e MONSON-HAEFEL, 2006) Java Persistence API A Java Persistence API (JPA) foi desenvolvida em meio aos trabalhos de especificação do EJB 3.0 e introduzida como uma API padrão na plataforma JEE 5. Padroniza o mapeamento objeto-relacional na plataforma Java e não depende de um container para funcionar. Até a especificação JEE 1.4, a plataforma Java não possuía uma forma simples de mapear objetos no banco de dados. A única opção era utilizar os Entity Beans que necessitavam de um container EJB. Entretanto, as aplicações que não envolviam EJB s precisavam utilizar frameworks de persistência não padronizadas como o Hibernate ou fazer a implementação da persistência de dados manualmente. Na JPA os objetos persistentes são denominados entidades (entities). Uma entidade é um objeto simples, rotulada através da que representa um conjunto de dados

21 22 persistindo no banco e são definidas por classes Java comuns, que podem ser abstratas ou herdar outras classes, sem restrições. As entidades possuem um identificador de persistência (descrito pela chave primaria), sendo assim, o atributo anotado representará a chave primária do banco de dados. A implementação da JPA é feita por um provedor de persistência. O provedor define como as coisas funcionam, através da implementação de todas as interfaces definidas pela especificação da JPA. Dessa forma, cada provedor decide a maneira e o momento de carregar, atualizar e armazenar as entidades, assim como sincronizar os dados com o banco de dados. As configurações utilizadas pelo provedor de uma determinada aplicação (conexão com o banco de dados, entidades que serão gerenciadas, tipos de transação etc.) são descritas em um persistence unit, que é configurado num arquivo especial denominado persistence.xml (JCP, 2009) Java Database Connectivity Java Database Connectivity ou JDBC é uma API Java que fornece uma interface comum para o acesso a sistemas de banco de dados. O JDBC facilita o envio de comandos SQL para os bancos de dados relacionais e suporta muitos dialetos SQL, além de interagir com outros tipos de fontes de dados, como arquivos contendo dados tabulados. A API JDBC permite que uma aplicação acesse qualquer fonte de dados e funcione em qualquer plataforma com uma Máquina Virtual Java. Em outras palavras, com o JDBC não é necessário escrever um programa para acessar um banco de dados Oracle, outro para acessar o PostgreSQL, e assim por diante. Uma aplicação simples que se utiliza o JDBC é capaz de enviar instruções SQL para qualquer banco de dados relacional (BRILL, 2001). 2.2 Ambiente Integrado de Desenvolvimento Ambiente integrado de desenvolvimento também conhecido como IDE (Integrated Development Environment) é uma aplicação que fornece um conjunto de ferramentas para auxiliar e facilitar o desenvolvimento de software (SUN, 2009). Uma IDE normalmente possui: a) Editor de código: Um editor texto para editar o código-fonte dos programas. Possui características como autocompletar, aninhar o código, etc;

22 23 b) Compilador: Uma ferramenta que transforma o código fonte escrito em uma determinada linguagem em linguagem de baixo nível ou linguagem de máquina, para se obter o programa executável; c) Depurador: Uma ferramenta para encontrar e corrigir erros no software. Para o desenvolvimento de software Java, existem inúmeras IDE s disponíveis no mercado, sejam elas proprietárias ou livres. IDE s proprietárias incluem IntelliJ IDEA, BEA WebLogic, MyEclipse, IBM Rational Application Developer, dentre outras. IDE s livres incluem BlueJ, Geany, e duas das principais IDE s gratuitas de código aberto: Eclipse e Netbeans. Como este trabalho enfatiza o desenvolvimento de software com ferramentas livres estas duas IDE s serão apresentadas a seguir Netbeans O Netbeans é um ambiente de desenvolvimento multiplataforma e multilíngüe escrito totalmente em Java pertencente a Sun Microsystems (JAVAWORLD, 2008). A IDE NetBeans possibilita o desenvolvimento de todos os tipos de aplicativos Java, dentre eles Java Standard Edition (JSE), Servlets, JSP, EJB e aplicativos móveis. Ela fornece uma base sólida para a criação de projetos, pois possui um grande conjunto de bibliotecas, módulos, protocolos e API s (Application Program Interface), além de uma vasta documentação. Entre outras características pode se ressaltar: suporte a XML, HTML, controle de versão e refatoração. Todas as funções da IDE NetBeans são fornecidas através de módulos. Cada módulo fornece uma função bem definida, como suporte a linguagem Java, edição, refatoração e SVN. Os módulos também permitem a extensão do NetBeans, como por exemplo suporte a outras linguagens. Um dos principais módulos integrado ao Netbeans é o projeto Matisse, um conjunto de ferramentas GUI (Graphical User Interface) que simplifica a criação de interfaces gráficas, utilizando os componentes existentes. No momento do desenvolvimento deste trabalho a IDE NetBeans se encontra na versão 6.8 e a Figura 3 exibe a IDE apresentada.

23 24 Figura 3 - IDE NetBeans Eclipse O Eclipse é um ambiente de desenvolvimento de software que inclui uma IDE multilíngüe e plug-ins para estendê-la. A IDE Eclipse é escrita em Java, de código aberto e pode ser usada para desenvolver aplicações em Java e, em outras linguagens, incluindo C, C + +, COBOL, Python, Perl, PHP e outras. Ela é distribuída sob a licença da Eclipse Public License (ECLIPSE.ORG, 2009). O Eclipse pode ser estendido para trabalhar com aplicações de rede, sistemas de gerenciamento de banco de dados, aplicações móveis, Web Services, dentre outras diversas opções, devido aos inúmeros plug-ins existentes. Com a exceção de seu pequeno kernel, tudo no Eclipse é um plug-in ou um conjunto de plug-ins, isso o torna totalmente extensível, pois novas funcionalidades podem ser facilmente adicionadas (GALLARDO, BURNETTE e MCGOVERN, 2003). O Eclipse fornece plug-ins para uma ampla variedade de funcionalidades, muitos deles de terceiros podendo ser livres ou comerciais. Exemplos de plug-ins incluem plug-in para diagramas UML, ferramentas de edição gráficas, relatórios, gráficos e muitos outros. O

24 25 Eclipse domina neste aspecto e quase todos plug-ins comerciais para Java são feitos primeiramente para o Eclipse, e pouco deles são migrados para o Netbeans. Curiosamente as versões do Eclipse acompanham o nome das luas de Júpiter e no momento do desenvolvimento deste trabalho a IDE Eclipse Galileo se encontra na versão 3.5. A Figura 4 exibe a IDE apresentada. Algumas das características das IDE s Eclipse e NetBeans podem ser conferidas na Tabela 1. Figura 4 - IDE Eclipse 3.5 Galileo.

25 26 Tabela 1 - Comparativo entre as IDE s Eclipse e NetBeans. IDE Licença JVM Plataformas GUI Plugins Debugger Última versão estável Eclipse EPL Sim Windows, Mac OS X, Linux, Solaris Não Sim Sim Dezembro 2009 NetBeans CDDL, GPL2 Sim Windows, Mac OS X, Linux, Solaris Sim Sim (Restrito) Sim Setembro Frameworks Um framework é um projeto reutilizável para um sistema ou subsistema, que engloba um conjunto de classes fornecendo uma solução genérica, na qual são customizadas para resolver problemas de um domínio específico. (FAYAD, SCHIMIDT e JOHNSON, 1999) Frameworks de Regras de Negócio Os frameworks de regras de negócios são responsáveis por controlarem toda a lógica de negócio da aplicação, as quais determinam de que maneira os dados serão utilizados. Isso se torna vantajoso, pois qualquer alteração necessária as regras de negócio poderá ser feito nesta camada, sem ter qualquer efeito sobre as outras (MSDN, 2009) Struts Struts é um framework open-source do grupo Apache para criar aplicações Java para Web e que encoraja os desenvolvedores a adotar o padrão de projeto MVC (STRUTS, 2009).

26 27 Em uma aplicação Web Java EE padrão, o cliente normalmente submete a informação ao servidor através de um formulário Web. A informação é então entregue a uma Servlet que a processa, interage com o banco de dados e produz uma resposta formatada em HTML, ou é entregue a um JSP que se obtém o mesmo resultado. Ambos são considerados úteis em alguns casos, porém são considerados inadequados para grandes projetos, porque eles misturam a lógica com a apresentação e tornam difícil a manutenção (HOLMES, 2007). O Struts soluciona este problema fornecendo um alicerce para a construção de uma aplicação orientada a MVC provendo bibliotecas e utilitários para tornar o desenvolvimento do MVC de maneira rápida e fácil. Portanto seu objetivo é separar de forma limpa o modelo (lógica da aplicação que interage com o banco de dados) da visão (páginas HTML apresentadas ao usuário) e o controlador (instância que passa a informação entre a visão e o modelo). O Struts fornece o controlador, uma servlet configurada no arquivo web.xml, conhecida como ActionServlet. Esta servlet é responsável por manipular todas as solicitações dos clientes e determinar qual Action processará cada solicitação. A ActionServlet usa a configuração definida no arquivo struts-config.xml para decidir o destino das solicitações Webwork O Webwork é um framework de desenvolvimento de código aberto para a construção de aplicações utilizando o MVC. Ele é baseado nas melhores práticas e padrões de projeto e foi desenvolvido pela OpenSymphony. Assim como Struts o WebWork inclui um controlador central e pode ser configurado através de seus arquivos. Quando o webwork inicia, a servlet ServletDispatcher é invocada. Este é o controlador principal do WebWork e lê vários arquivos de configuração, essa informação é usada para criar um objeto Action para processar a solicitação recebida. O Action, por sua vez cria os beans que acessam os dados ou realizam o trabalho real da aplicação. Uma vez que o Action é executado ele retorna a solicitação processada que é usada pela servlet ServletDispatcher que redirecionará a resposta a um componente de apresentação ou outra Action (WEBWORK, 2009).

27 Spring O Spring é um framework de código aberto que visa tornar mais fácil o desenvolvimento de aplicações JEE. Seu objetivo é ajudar a estruturar as aplicações de maneira consistente, reunindo as melhores práticas e padrões de projeto (JOHNSON, 2005). Diferentemente de outros frameworks como o Struts ou o Hibernate, e a maioria de outros frameworks, o Spring oferece serviços para uso em toda a aplicação e não apenas em uma simples camada arquitetural. Ele está organizado de uma maneira modular, e os módulos são essencialmente grupos conceituais de funcionalidades fornecidas pela extensa lista de pacotes e classes Java do Spring. Isso significa que é possível utilizar apenas os módulos desejados e introduzi-los a um projeto módulo a módulo. A Figura 5 apresenta os diversos módulos do Spring. Figura 5 - Visão geral dos módulos do Spring Framework. Fonte: Spring Framework (2009). As aplicações Java são compostas por diversos objetos que se comunicam e colaboram entre si formando a aplicação. Esta colaboração cria uma espécie de dependência entre os objetos. É nesta dependência que o principal módulo do Spring age. O módulo Core é a parte mais importante do Spring, pois fornece a Inversão de Controle (IoC) e Injeção de Dependência. O

28 29 conceito básico neste módulo é o BeanFactory, que fornece uma implementação sofisticada do padrão de projeto Factory e permite desacoplar a dependência entre os objetos (SPRING FRAMEWORK, 2009). A injeção de dependência é responsável por instanciar e fornecer os objetos necessários em tempo de execução, ao invés da instanciação explícita no código, ou seja, não é determinado diretamente pelo programador. Ao contrário disso o controle é delegado ao Spring Framework e ele controlará a dependência entre os objetos, injetando-os quando necessário, mantendo assim um baixo nível de acoplamento Frameworks de Persistência Os frameworks de persistência são responsáveis pelo acesso ao banco de dados, por armazenar e recuperar as informações. As mudanças que ocorrerem ao banco de dados ou em outros componentes relacionados não afetarão o restante da aplicação, porque a camada de acesso aos dados não permitirá que isto aconteça (MSDN, 2009) Oracle TopLink O Oracle TopLink é um framework para o mapeamento objeto relacional criado pela empresa americana Oracle Corporation. Este framework propicia a construção de aplicações de alto desempenho, persistindo dados orientados a objeto em um banco de dados relacional. De acordo com Bezerra (2006) o mapeamento objeto relacional é uma técnica de desenvolvimento utilizada para reduzir a complexidade da programação orientada a objetos utilizando bancos de dados relacionais, cujas tabelas do banco de dados são representadas através de classes e os registros de cada tabela são representados como instâncias das classes correspondentes. Oracle TopLink possui um extenso conjunto de ferramentas de desenvolvimento, dentre elas está o TopLink Workbench. O TopLink Workbench captura e define a fonte e a representação do objeto a ser salvo e os mapeia no formato de metadados, assim torna-se possível explorar as aplicações com um mapeamento de metadados e fornecer apoio em profundidade para o acesso aos dados, consultas e transações (Oracle TopLink Developer s Guide, 2006).

29 Hibernate O Hibernate é um framework de código fonte aberto utilizado para o mapeamento objeto relacional para aplicações Java. Ele não cuida somente do mapeamento de classes Java para tabelas de banco de dados, mas também fornece dados de consulta, atualização de informações e reduz significativamente o tempo de desenvolvimento gasto com a manipulação manual de dados em SQL e JDBC. O Hibernate suporta vários bancos de dados como o Oracle, DB2, MySQL, PostgreSQL dentre outros. Os bancos de dados são suportados via classes do SQL Dialect do Hibernate. A propriedade dialect informa ao Hibernate o dialeto SQL específico do banco de dados a ser utilizado, para que as declarações sejam corretamente convertidas para o SQL nativo. Basicamente o Hibernate trabalha com dois tipos de arquivos de configuração, o hibernate.cfg.xml responsável pela configuração da conexão e comportamento geral do Hibernate e o XML Mapping que contém os arquivos de mapeamento das classes Java e tabelas do banco de dados. O Hibernate utiliza uma poderosa linguagem de consulta, a HQL, semelhante em aparência a linguagem SQL, no entanto é totalmente orientada a objetos e compreende noções como: herança, polimorfismo e associação. É possível utilizar tanto a linguagem SQL quanto a HQL. A linguagem HQL permite executar os comandos SQL sobre as classes de persistência Java ao invés de tabelas no banco de dados, aumentando assim a distância entre o desenvolvimento da regra de negócios e o banco de dados (HIBERNATE, 2009) Frameworks e Tecnologias de Apresentação Os frameworks de apresentação são responsáveis por transformar os dados gerados pela camada de controle em dados compreensíveis e apresentá-los ao usuário final. As tecnologias utilizadas também padronizam e facilitam a interface na qual o usuário interagirá com o sistema (MSDN, 2009).

30 JavaServer Faces JavaServer Faces (JSF) é um framework para construção de interfaces de usuário para aplicações Web. Esse framework foi desenhado para simplificar o desenvolvimento de aplicações Web, através do conceito baseado em componentes (component based). Seu conjunto de API s representa componentes User Interface (UI) e gerenciam o seu estado, manipulam eventos e apóiam a internacionalização e acessibilidade, separando a definição de um componente do seu processamento. Suas API s de componentes permitem estender o conjunto padrão de componentes e criar inteiramente novos componentes, oferecendo uma clara separação entre lógica e apresentação focada na camada view de uma arquitetura baseada em MVC. No JSF, o controle é composto por um servlet denominado FacesServlet, por arquivos de configuração e por um conjunto de manipuladores de ações e observadores de eventos. O FacesServlet é responsável por receber requisições da Web, redirecioná-las para o modelo e então remeter uma resposta. Os arquivos de configuração são responsáveis por realizar associações e mapeamentos de ações e pela definição de regras de navegação. Os manipuladores de eventos são responsáveis por receber os dados vindos da camada de visualização, acessar o modelo, e então devolver o resultado para o FacesServlet. O JSF oferece ganhos no desenvolvimento de aplicações Web, pois permite ao desenvolvedor criar UI s através de um conjunto de componentes, reutilizar componentes e utilizar um conjunto de tags JSP para acessar os componentes (SUN, 2009) Facelets Facelets é um framework de templates JavaServer Faces, baseado em alguns princípios simples, que transforma tags (X)HTML em páginas JSF, sem a necessidade de utilização total de suas tags. Cria uma árvore de objetos UIComponent e interliga o conteúdo com as requisições processadas pelo ciclo de vida JSF, através dessa ligação com JSF, o Facelets incorpora numerosas características amigáveis ao desenvolvedor entre eles a criação de uma árvore de objetos UIComponent e conteúdo entrelaçado completamente com o processo de ciclo de vida do JavaServer Faces, suporte a templates reutilizáveis, aumentando a produtividade na criação de numerosas páginas, criando uma base padrão, e a eliminação de tags JSF como <f:view/> e <f:subview/> (GONÇALVES, 2009).

31 RichFaces RichFaces é um framework open source que adiciona capacidade Ajax em aplicações JSF. A funcionalidade Ajax é definida pela biblioteca Core, sendo assim não é mais necessário escrever qualquer código JavaScript ou substituir componentes nas páginas existentes. Um evento invoca uma requisição Ajax e áreas da página passam a ser sincronizadas com a árvore de componentes JSF, logo após, os dados são alterados no servidor de acordo com os eventos disparados pelo cliente. A biblioteca UI RichFaces possui os componentes responsáveis por criar a interface gráfica para as aplicações JSF, e para sua criação foi utilizado o Component Development Kit (CDK). O CDK inclui código de facilidade de geração e instalação de templates usando sintaxe JSP e ajuda a evitar um processo rotineiro de criação de componentes. Além do suporte a funcionalidade Ajax, RichFaces fornece um suporte avançado para a gestão de recursos diversos como fotos, código JavaScript e folhas de estilo CSS. RichFaces vem com uma série de pré-skins para serem utilizadas, e facilitam a criação de skins personalizadas. Skin é um visual alternativo dado a um programa computacional, que tem por finalidade alterar a aparência incluindo formas e cores. Para o futuro, RichFaces contará com um sistema automatizado de testes. Os testes serão gerados para os componentes desenvolvidos, e não será apenas um teste para os componentes, mas também para qualquer outra funcionalidade do servidor do lado do cliente, incluindo código JavaScript (JBOSS, 2010) AJAX AJAX significa Asynchronous Javascript and XML (JavaScript e XML assíncrono) é um conceito de navegação e atualização de páginas Web que as tornam mais interativas com o usuário, utilizando-se de solicitações assíncronas de informações. AJAX não é uma tecnologia, é o conjunto de tecnologias trabalhando juntas. Dentre as tecnologias que compõem Ajax estão: XHTML como linguagem de marcação e CSS para definição dos estilos, DOM (Document Object Model) para exibição e interação, XML (Extensible Markup

32 33 Language) para troca de dados e o XMLHttpRequest funcionando de forma assíncrona na comunicação com o servidor e JavaScript para fundir e manipular todas as partes do processo. Em um modelo clássico de aplicação web as ações do usuário na interface disparam solicitações HTTP para o servidor web. O servidor processa as informações e então retorna uma página HTML para o cliente. Enquanto o servidor processa as informações o usuário aguarda. Uma vez que a interface está carregada, a interação do usuário não deveria parar cada vez que a aplicação precisasse de algo do servidor e é essa maior vantagem das aplicações AJAX, elas rodam no próprio navegador web. A figura 6 apresenta o diagrama do modelo clássico de uma aplicação web e o diagrama do modelo Ajax de uma aplicação web (SOARES, 2006). Figura 6 - Diagrama de requisições ao servidor. Fonte: Jess James Garret/ adptivepath.com (2009) Frameworks de Teste Frameworks de testes são utilizados para testar as funcionalidades do sistema, evitando pequenas falhas que são percebidas em outras etapas do desenvolvimento. Ao escrever os testes enquanto se escreve o código, pode ser verificado se o código funciona como esperado

33 34 e corrigir qualquer falha apresentada nesta etapa, reduzindo o tempo gasto para depurá-las e corrigi-las posteriormente (HUNT e THOMAS, 2003) JUnit O JUnit é um framework open-source de teste Java escrito por Erich Gamma, um dos autores populares de padrões de projeto, e por Kent Beck, o idealizador da metodologia XP. O JUnit é uma ferramenta amplamente utilizada para testes de unidades de código Java. Um teste de unidade é um código escrito para testar uma pequena funcionalidade do sistema, normalmente um método em algum contexto. Deste modo é verificado se determinado trecho de código faz o que o desenvolvedor esperaria fazer (MASSOL e HUSTED, 2004). A Figura 7 mostra uma captura de tela da interface da ferramenta JUnit realizando um teste de unidade. Figura 7 - A ferramenta de teste JUnit TestNG O TestNG é um framework de teste Java que visa auxiliar o desenvolvimento fornecendo uma ampla cobertura de testes, pois não abrange apenas testes de unidade, mas também testes de

34 35 aceitação, funcionais e de integração. O TestNG foi o primeiro na abordagem baseada em anotações de testes em Java, posteriormente adotado pelo JUnit (BEUST e SULEIMAN, 2008). Para realizar um teste no TestNG, não é necessário estender nenhuma classe especial, apenas utilizar a para sinalizar ao framework os métodos da classe que serão testados. A Figura 8 mostra um teste simples utilizando o TestNG. package tests; import org.testng.annotations.test; import org.testng.assert; public class StringTest { String teste = "abcde"; public void teststring() { Assert.assertNotNull(teste); Assert.assertEquals(teste, new String("abcde")); } Figura 8 - Um teste unitário no TestNG. 2.4 Ferramentas Case O software usado para apoiar as atividades de processo de software, como engenharia de requisitos de projeto é dado o nome CASE (Computer-Aidade Software Engineering). As ferramentas CASE podem ser classificadas de várias formas e cada uma delas oferece uma perspectiva (SOMMERVILLE, 2007).

35 StarUML StarUML é um projeto open-source para o desenvolvimento de modelos UML que tem como objetivo prover uma ferramenta de modelagem de software. É um projeto multi linguagem, e não está preso a uma linguagem de programação especifica apesar de ser desenvolvida quase que em sua totalidade na linguagem Delphi. A ferramenta StarUML tem como características o suporte a diagramas UML 2.0 e a tecnologia Model Driven Architecture (MDA) e engenharia de código Java, C++ e C#, extensão de diagramas, geração de documentos Microsoft Office e suporte a padrões de projeto. A Figura 9 ilustra o ambiente de desenvolvido da StarUML (STARUML, 2010). Figura 9 - Ambiente StarUML.

36 JUDE/Community Criada pela Change Vision, a JUDE/Community é uma poderosa ferramenta de modelagem UML grátis. Desenvolvida para a modelagem de sistemas Java, disponibiliza a seus usuários classes e interfaces dos pacotes java.lang e java.util, assim, é possível agregar aos modelos algumas das funcionalidades de Java 5, tais como classes genéricas, listas, pilhas, árvores, dicionários, entre outras. Por ser rica em funcionalidades, oferece edição e impressão de diagramas UML 2.0, importação/exportação de código-fonte Java e criação de Javadoc a partir de diagrama de classes. A ferramenta tem se mostrado uma boa opção, principalmente, para a comunidade acadêmica e empresas de pequeno porte, por ser isenta de custos e bastante funcional. A Figura 10 ilustra o ambiente oferecido pela ferramenta JUDE/Community (JUDE, 2010). Figura 10 - Ambiente JUDE/Community.

37 Ferramentas para o processo de construção de software Entende-se por processo de construção (build) de software tarefas como compilação, testes, empacotamento e a distribuição da aplicação. Ter uma ferramenta para o processo de construção do software significa ter controle desde o código fonte, até as etapas de documentação e entrega do produto de forma automatizada (LOUGHRAN e HATCHER, 2007) Ant O Ant é uma ferramenta de construção (build tool) de código aberto, baseada em Java e mantida pela Apache Software Foundation e logo após seu lançamento tornou-se uma das ferramentas mais utilizadas para a construção de aplicações em ambientes Java. O Ant é uma ferramenta altamente extensível, principalmente pelo enorme conjunto de tarefas predefinidas e externas disponíveis, e que a tornam poderosa. Além disso, é possível escrever as próprias extensões personalizadas. O Ant utiliza arquivos XML chamados de build.xml que descrevem todo o processo de construção do projeto, e neste arquivo deve ser declarada todas as tarefas a serem executadas. Com o Ant é possível acelerar o desenvolvimento na execução de tarefas automatizadas como construção do projeto, implantação, execução de programas Java, criação do banco de dados, execução de testes, dentre outros (LOUGHRAN e HATCHER, 2007) Maven O Maven é uma ferramenta para construção e gerenciamento de projetos Java. Similar ao Ant o Maven é mantido pela Apache Software Foundation como um projeto de código aberto e tem como objetivo automatizar o processo de construção do projeto passando por todas as etapas, da compilação a distribuição. Embora possua algumas semelhanças ao Ant, o Maven não é apenas uma ferramenta de construção e nem um substituto ao Ant, o Maven fornece um conjunto de padrões para facilitar o gerenciamento de projetos através do reuso de estratégias comuns de construções de software, inclusive é possível utilizar scripts Ant existentes no projeto e usá-los através de plugins Maven. Os plugins permitem aos desenvolvedores adicionar um conjunto de funções extras dentro do ciclo de vida de construção do Maven.

38 39 A estrutura de um projeto Maven é declarado em um arquivo XML chamado de POM (Project Object Model). Neste arquivo são declaradas todas as tarefas (goals), plugins e dependências utilizadas no projeto. Uma das principais características do Maven é o gerenciamento de dependências. Em projetos Java é comum utilizar bibliotecas externas, e à medida que novas funcionalidades são adicionadas ao projeto, novas bibliotecas surgem, e a dificuldade para gerenciá-las também aumentam. Porém o Maven possui uma estratégia de gerenciamento de dependências ao baixar de um repositório central, novas dependências encontradas no POM e checar as versões das dependências existentes, evitando conflitos (MASSOL et. al., 2006). 2.6 Container Web Um container Web fornece um ambiente de execução para componentes Web, que inclui o gerenciamento da execução de páginas JSP, ciclo de vida das servlets, segurança, concorrência e outros serviços. Estes serviços fazem parte do contrato de componentes Web da arquitetura JEE (SUN, 2009) Tomcat O Apache Tomcat é um container Web baseado em Java desenvolvido pela Apache Software Foundation. Ele é gratuito e possui recursos completos de um container Web para processar Java Servlets e JSP s. O Tomcat é usado como referência da Sun para implementações de Container Web, por alcançar as especificações das API Servlet e JSP. Além disso, ele é um container relativamente leve que cresceu muito em popularidade nos últimos anos. No entanto ele é normalmente confundido como um servidor de aplicações, porém ele não é um servidor de aplicações JEE completo, por não dar suporte a muitas tecnologias JEE, como por exemplo, o EJB (CHOPRA, LI e GENENDER, 2007).

39 Servidores de aplicação Servidores de aplicação é um software que fornece um ambiente para a instalação e execução de aplicativos pela Web. Eles são responsáveis pela camada da lógica de negócios, em uma arquitetura n-camadas, cuja função é atuar sobre os dados, como por exemplo, recuperar, processar dados, e apresentá-los ao usuário. N-camadas se refere a três camadas envolvidas: cliente, servidor de aplicação e banco de dados. A Figura 11 apresenta uma arquitetura n-camadas. Os servidores de aplicação se popularizaram devido à plataforma Java e são freqüentemente relacionados aos servidores de aplicações JEE (BPC, ARTICLES AND GLOSSARY, 2009). Figura 11 - Arquitetura n-camadas. Fonte: Adaptada de Bpc, Articles and Glossary (2009) WebSphere O WebSphere Application Server é um dos principais servidores de aplicação produzido pela IBM, utilizado para a criação e execução de aplicações baseadas no padrão JEE. Ele suporta uma ampla gama de plataformas e tem uma fatia muito forte no mercado (SADTLER, 2006).

40 Glassfish O Glassfish é um servidor de aplicações de código-aberto e multiplataforma desenvolvido pela SUN baseado na plataforma JEE. Ele é um dos poucos servidores a dar suporte total as novas especificações JAVA, além disso, possui recursos como injeção de dependências, container Web, container EJB, e outros (SUN, 2009) JBoss Aplication Server O JBoss Application Server é um servidor de aplicações de código fonte aberto baseado na plataforma JEE implementado totalmente em JAVA e foi desenvolvido pela JBoss, uma nova divisão da empresa Red Hat. O JBoss começou como um simples container EJB, evoluiu e tornou-se então um servidor de aplicações competindo com grandes servidores de aplicação proprietários como o WebSphere e o WebLogic (JAMAE e JOHNSON, 2009). O JBoss possui um conjunto de tecnologias que são chamados JBoss Enterprise Middleware Suite (JEMS). Abaixo são apresentadas algumas das tecnologias JEMS: - JBoss Microcontainer: o microcontainer pode ser usado como um framework para injeção de dependência. - Hibernate: Uma ferramenta de mapeamento objeto-relacional usado para implementar a persistência da especificação EJB3. - JBoss Web Server: um Servidor Web nativo e rápido que permite usar as tecnologias Web, tais como servlet, JSP e JSF. - EJB Server: Uma implementação da especificação EJB Banco de Dados A seguir são apresentadas algumas opções de banco de dados gratuitos segundo a análise da revista SQL magazine, levando em consideração alguns fatores importantes para o desenvolvimento deste trabalho, como: limitações, recursos de desenvolvimento e ferramentas.

41 Firebird O Firebird é um Sistema Gerenciador de Banco de Dados (SGBD) baseado no código do InterBase da Borland de código aberto que roda em sistemas como Windows, Linux e uma variedade de sistemas Unix. Apesar da sua alta capacidade de armazenamento, cerca de 7TB (7 terabytes), é um banco extremamente leve. Ele suporta os principais recursos de um banco de dados, como trigger, stored procedures e functions, não possui ferramentas gráficas, embora existam inúmeras ferramentas gráficas gratuitas na comunidade Firebird para a manutenção e administração do banco de dados. O ponto fraco do Firebird é a segurança, pois não possui dispositivo de criptografia e segurança em nível de banco de dados MySQL O MySQL é um SGBD de código fonte aberto desenvolvido por MySQL AB e tem reconhecimento mundial devido sua facilidade de uso, confiabilidade e desempenho. Ele suporta uma ampla variedade de sistemas operacionais, tais como, Unix, Linux, FreeBSD, Windows, dentre outros, além disso o servidor MySQL tem um baixo consumo de memória, e é ajustável, permitindo reduzir ou aumentar, de acordo com requisitos de desempenho e demanda de dados. A empresa MySQL AB fornece diversas ferramentas gráficas gratuitas para a execução de comandos SQL, modelagem de dados e administração do banco de dados Oracle 10g Express Edition O Oracle 10g Express Edition é a versão gratuita de um dos bancos de dados líder de mercado, o Oracle 10g, traz recursos de performance, segurança e há total compatibilidade com a versão Oracle 10g. Ele oferece suporte à linguagem PL/SQL, permitindo desenvolver toda regra de negócio no próprio banco de dados, além de contar com uma poderosa ferramenta de backup e restore, o RMAN.

42 43 O ponto fraco do Oracle XE está relacionado com a limitação de hardware e de armazenamento, pois suporta apenas um processador e o tamanho máximo do banco de dados pode chegar a apenas 4 Gigabytes PostgreSQL PostgreSQL é um SGBD relacional de código aberto que oferece recursos eficientes de segurança e integridade de dados, e é concorrente direto aos melhores bancos de dados comerciais existentes, como o Oracle, DB2, SQL Server, por ser robusto e possuir conceitos similares ao Oracle. No que diz respeito a limitações de hardware e software, o PostgreSQL é bem flexível e suporta qualquer tipo de hardware e uma ampla gama de sistemas operacionais. Além disso, o PostGreSQL possui uma ferramenta gráfica livre e de código aberto para a administração de banco de dados e backup, o pgadmin. Ele permite a execução de SQL, criação de views, triggers, procedures, dentre outras tarefas.

43 44 3 Modelagem e Arquitetura de um Sistema Web Neste capítulo serão abordados os processos de desenvolvimento utilizados, a modelagem e os artefatos dos processos em questão, bem como as decisões de projeto, a arquitetura proposta e o estudo de caso. 3.1 Processo de desenvolvimento de software Todo projeto deve ter uma estrutura básica ou seguir uma metodologia, com a finalidade de auxiliar e melhorar a qualidade no desenvolvimento de software, de modo a atender as necessidades do cliente e cumprir corretamente os prazos definidos no contrato. Esta metodologia pode ser uma lista de verificação ou um processo mais formal. Existem diversos processos e cada um descreve uma variedade de tarefas ou atividades que devem ser seguidas (REZENDE, 2005). A seguir serão apresentados os processos utilizados neste trabalho Processo incremental É uma abordagem intermediária que combina as vantagens do modelo em cascada e do desenvolvimento evolucionário. O cliente identifica quais os serviços mais e menos importantes fornecidos pelo sistema e a partir dessa identificação, um número de incrementos é definido, fornecendo um subconjunto de funcionalidades do sistema. Após um incremento ser concluído ele é entregue ao cliente e ele pode colocá-lo em operação e à medida que novas funcionalidades são concluídas elas são integradas ao sistema já existente. O processo de desenvolvimento incremental tem uma série de vantagens, dentre elas podemos citar que o cliente não precisa esperar pela entrega do sistema completo para se beneficiar do uso, e pode utilizar as versões iniciais como protótipo (SOMMERVILE, 2007). A Figura 12 apresenta os principais estágios das atividades fundamentais do desenvolvimento incremental.

44 45 Figura 12 - Desenvolvimento incremental. Fonte: Adaptada de Sommerville (2007) Programação Extrema (XP) A Programação Extrema ou simplesmente XP é uma metodologia de desenvolvimento ágil desenvolvida no final da década de 90 por Kent Beck e Ward Cunningham, que promove um ciclo de desenvolvimento simples e ágil, baseado em seus valores de simplicidade, comunicação, feedback e coragem (XPROGRAMMING, 2009). Segundo Kent Beck (1999), a XP é recomendada para equipes pequenas e médias de desenvolvimento que produzem software baseado em requisitos genéricos e que mudam constantemente. As principais diferenças entre XP e outras metodologias de desenvolvimento é que a XP fornece freqüentes e precisos feedbacks aos usuários e uma abordagem incremental que consiste na entrega de pequenas versões funcionais do sistema ao cliente Práticas da XP A metodologia XP consiste em um conjunto de práticas responsáveis por facilitar o desenvolvimento e agregar qualidade ao projeto, bem como tornar o processo mais ágil e flexível (BECK, 1999). A seguir são apresentadas as 12 práticas da XP: Jogo do planejamento: Nesta fase o cliente expressa as funções do sistema (requisitos funcionais) através das histórias de usuários escritas nos cartões de histórias (story cards). A equipe de desenvolvimento junto com os clientes determinam as prioridades e as datas de

45 46 cada entrega do sistema (release). Como o próprio nome já diz, o jogo de planejamento é apenas um planejamento inicial e certamente sofrerá mudanças ao longo do desenvolvimento. Pequenas versões: Em cada versão a equipe implementa um conjunto de cartões de usuários, liberando pequenas versões funcionais do sistema ao cliente em um curto período de tempo. Portanto, o software é entregue ao cliente no final de cada iteração, permitindo-o usar e testar cada versão. Metáfora: O desenvolvimento é guiado por simples histórias de como o sistema funciona e ajuda na compreensão de todos os participantes, ou seja, sua principal função é melhorar a comunicação entre os envolvidos. Projeto Simples: Uma das regras do desenvolvimento incremental em XP é "faça o mais simples que poderia fazer". Isto implica não prever o futuro e implementar apenas o necessário e não antecipar requisitos. Testes: A equipe XP foca a validação do software a todo o momento. Os programadores escrevem testes unitários para todos os componentes do sistema, em uma prática conhecida como desenvolvimento dirigido a testes (Test-Driven Development - TDD), criada por Kent Beck, na qual os testes são escritos antes do código funcional. Refatoração: A equipe XP usa um processo de melhoria contínua, na qual os programadores reestruturam continuamente o código sem alterar seu comportamento a fim de tornar o software limpo, sem duplicação, com alta coesão e baixo acoplamento. Programação pareada: Todo o desenvolvimento na XP é feito por dois programadores, juntos em uma mesma máquina. Esta prática assegura que todo o código é avaliado por um ou outro programador, e que resulta em um melhor código e projeto, além de compartilhar o conhecimento em toda a equipe, devido a troca de experiências entre os programadores. Propriedade coletiva: Todo o código pertence a toda equipe, permitindo a qualquer desenvolvedor alterar ou adicionar alguma funcionalidade ao sistema, sem solicitar algum tipo de permissão. Na XP todos têm responsabilidades por todo o sistema.

46 47 Integração contínua: O código deve ser armazenado em um local compartilhado e a equipe XP compila e integra o novo código ao repositório várias vezes ao dia, eliminando problemas de integração e código quebrado onde ocorre em uma integração de menor freqüência. Ritmo sustentável: A equipe XP não faz excessivas horas-extras, pois se houver há algo de errado no projeto. O time precisa estar disposto e trabalha em um ritmo saudável (40 horas / semana), pois programadores cansados estão mais propensos a cometerem erros. Cliente junto aos desenvolvedores: Um usuário real do sistema deve fazer parte da equipe XP e estar disponível para esclarecer as dúvidas dos programadores, determinar requisitos e definir prioridades. O efeito de o cliente fazer parte do time é melhorar a comunicação e evitar surpresas por parte do cliente. Padronização do código: Os programadores escrevem todo o código de acordo com regras estabelecidas na fase inicial do projeto enfatizando a simplicidade e clareza do código. 3.2 Processo incremental para desenvolvimento de um sistema ERP Nesta seção serão demonstrados os resultados obtidos e a modelagem do sistema com a utilização da metodologia incremental Requisitos Funcionais A declaração de serviços que o sistema deve fornecer, como o sistema deve reagir e como ele deve se comportar em determinadas situações são classificados como requisitos funcionais. Os requisitos funcionais descrevem as funções detalhadamente de um sistema (SOMMERVILLE, 2007). A seguir são apresentados os requisitos funcionais do sistema ERP: RF01 - O sistema deve permitir o usuário se conectar ao sistema utilizando um ID válido e uma senha válida.

47 48 RF02 - O sistema deve permitir o administrador criar novos usuários. RF03 - O sistema deve permitir os usuários se desconectarem do sistema para finalizar a sessão atual. RF04 - O sistema deve permitir o usuário cadastrar novos clientes no sistema. RF05 - O sistema deve permitir o usuário consultar clientes por nome e CNPJ. RF06 - O sistema deve permitir o usuário cadastrar novos fornecedores no sistema. RF07 - O sistema deve permitir o usuário consultar fornecedores por nome e CNPJ. RF08 - O sistema deve permitir o usuário cadastrar novos produtos no sistema. RF09 - O sistema deve permitir o usuário consultar produtos por código ou nome do produto. RF10 - O cadastro de clientes, fornecedores e produtos devem ser mantidos em um módulo administrativo. RF11 - O sistema deve permitir o usuário gerar relatórios do módulo administrativo, como clientes, produtos e fornecedores cadastrados. RF12 - O sistema deve permitir o usuário alterar ou excluir os dados do cadastro no módulo administrativo. RF13 - O sistema deve manter um registro dos produtos cadastrados com um código de número seqüencial. RF14 - O sistema deve permitir o usuário solicitar relatórios sobre a quantidade de produtos em estoque. RF15 - O sistema deve permitir a saída automática de um produto do estoque quando houver venda. RF16 - O sistema deve permitir o usuário emitir uma nota fiscal a partir de um pedido de venda no módulo vendas. RF17 - O sistema deve permitir o usuário visualizar vendas ocorridas. RF18 - O sistema deve gerar um título no contas a pagar para o controle do módulo financeiro quando os produtos de uma NF de entrada forem cadastrados no módulo estoque. RF19 - O sistema deve gerar um título no contas a receber para o controle do módulo financeiro quando uma venda for realizada pelo módulo vendas. RF20 - O sistema deve permitir o usuário solicitar relatórios vendas por período ou vendas por produto. RF21 - O sistema deve permitir o usuário quitar títulos no contas a receber ou contas a pagar. RF22 - O sistema deve permitir o usuário pesquisar os títulos em aberto ou os títulos pagos no módulo financeiro informando a data inicial e final.

48 49 RF23 - O sistema deve permitir o usuário solicitar relatório de contas a receber e contas a pagar por período. RF24 - O sistema deve permitir controlar a entrada e saída de produtos do módulo estoque. RF25 - O sistema deve permitir o administrador ter controle de senhas dos usuários. RF26 - O sistema deve permitir o envio de s informando se os produtos estão abaixo do estoque mínimo Requisitos Não Funcionais Os requisitos não funcionais não estão diretamente relacionados às funções especificas do sistema. Eles estão relacionados às propriedades emergentes, como confiabilidade, tempo de resposta e espaço de armazenamento. São restrições fornecidas pelos serviços ou as funções fornecidas pelo sistema (SOMMERVILLE, 2007). Os requisitos não funcionais do sistema ERP são apresentados a seguir: RNF01 - O sistema deve ser flexível para rodar em diferentes sistemas operacionais. RNF02 - O sistema deve suportar múltiplos usuários simultâneos conectados. RNF03 - O sistema deve ser flexível para utilizar banco de dados relacionais diversos. RNF04 - Um container web é requerido inicialmente para executar a aplicação. RNF05 - Relatórios gerenciais devem ter tempos de resposta menores que 20 segundos. RNF06 - O sistema deve permitir a segurança e a integridade dos dados. RFN07 - No futuro o sistema deve ser escalável, permitindo acomodar componentes de negócios de um servidor de aplicações Diagramas de caso de uso De acordo com Bezerra (2006) o diagrama de caso de uso molda os requisitos funcionais do sistema e corresponde a uma visão externa do sistema, que tem por objetivo ilustrar em um nível alto de abstração quais elementos externos interagem com que funcionalidades do sistema. A Figura 13 apresenta o diagrama de caso uso do sistema.

49 Figura 13 - Diagrama de caso de uso do Sistema. 50

50 Documentos de casos de uso A UML não define uma estrutura especifica a ser utilizada na descrição de um caso de uso, existem diversas propostas e a equipe de desenvolvimento é responsável por identificar quais os itens de descrição que são realmente úteis (BEZERRA, 2006). No sistema ERP proposto, os itens de descrição escolhidos foram: a) Nome é o mesmo nome que aparece no diagrama de caso de uso; b) Contexto descrição do caso de uso; c) Ator primário nome do ator que inicia o caso de uso; d) Pré-condições - define quais hipóteses são assumidas como verdadeiras para que o caso de uso tenha inicio; e) Pós-condições é um estado que o sistema alcança após o caso de uso ser realizado; f) Cenário principal de sucesso - descreve o que normalmente acontece quando o caso de uso é realizado; g) Cenário alternativo - descreve o que acontece quando o ator faz uma escolha diferente da descrita no cenário principal para alcançar o seu objetivo. As especificações dos casos de uso do sistema ERP se encontram no Apêndice A, p Diagrama de Seqüência De acordo com Bezerra (2006) um diagrama de seqüência é um tipo de diagrama de interação. Os diagramas de interação ajudam a documentar e entender os aspectos dinâmicos do software, descrevendo a seqüência de mensagens enviadas e recebidas pelos objetos que participam em um caso de uso. No diagrama de seqüência a ênfase está na ordem temporal das mensagens trocadas entre os objetos. Os diagramas de seqüência do sistema ERP se encontram no Apêndice B, p

51 Processo XP para desenvolvimento de um sistema ERP Na seção anterior foram apresentadas as práticas e os artefatos utilizados na metodologia XP, nesta seção serão demonstrados os resultados obtidos e a modelagem do sistema com a utilização de uma metodologia ágil Jogo de Planejamento Conforme mencionado na seção anterior, na metodologia XP o projeto começa com uma curta fase exploratória reunindo desenvolvedores e clientes para determinar os requisitos iniciais através de pequenas histórias Cartões de História (Story Cards) Os cartões de histórias apresentados na Figura 14 têm propósitos semelhantes aos casos de uso, utilizado na metodologia tradicional, porém as histórias de usuário tendem a ser mais curtas que os casos de uso, por exemplo, entre uma e três frases cada. Os detalhes restantes podem ser discutidos entre desenvolvedores e clientes, quando a implementação começar, por isso o termo "participação ativa do cliente".

52 53

53 54

54 55 Figura 14 - Cartões de história do usuário Qualidades do sistema A Figura 15 apresenta os cartões de história das qualidades do sistema:

55 56 Figura 15 - Cartões de história das qualidades do sistema. 3.4 Decisões de Projeto Apresentados os cartões de história e as qualidades do sistema, serão necessárias tecnologias que ofereçam simplicidade e produtividade para o seu desenvolvimento. O estudo de caso nos levará a um contexto prático dessas tecnologias, como por exemplo, o desenvolvimento de componentes reutilizáveis para a arquitetura JEE e quais padrões de projetos adequados para utilizar tais tecnologias, porém nesta seção serão apenas apresentadas as tecnologias escolhidas, baseado nos requisitos levantados, a começar do repositório de dados até a interface gráfica Banco de dados Para o gerenciamento e armazenamento dos dados, o PostgreSQL será utilizado como o banco de dados, devido ao desempenho e robustez deste SGBD, por ser gratuito, possuir documentação em português e além da facilidade de instalação, configuração e uso. Como

56 57 possui suporte a diversas plataformas e sistemas operacionais, ele facilitará a portabilidade, caso necessário (MECENAS et. al., 2004) IDE Após a análise das ferramentas Eclipse e Netbeans no capítulo anterior, conclui-se que o Netbeans é intuitivo e de fácil manipulação, no entanto carece de funcionalidades e plugins. Como o trabalho foca o desenvolvimento de uma aplicação JEE, serão necessários plugins para os diversos frameworks e o Eclipse é o mais indicado por contar com muitos plugins disponíveis (JAVAWORLD, 2008) Ferramenta Case As ferramentas Case são fundamentais para a criação dos modelos UML no processo de modelagem de um sistema. Após a analise das ferramentas StarUML e JUDE/Community no capitulo anterior, observou-se que a ferramenta StarUML se mostra bastante completa, atendendo necessidades básicas de criação dos diagramas UML, porém o seu ambiente de desenvolvimento é bastante complexo para a manipulação e criação dos diagramas. Como o trabalho foca em desenvolvimento ágil optou-se pela ferramenta JUDE/Community que possui um ambiente de desenvolvimento de fácil manipulação e atende as necessidades básicas de criação de diagramas UML Testes Uma das principais práticas da XP é a validação do software a todo momento através de testes. Portanto, uma ferramenta é necessária para a escrita e execução de testes automatizados. Desse modo o TestNG será utilizado como framework de testes no projeto por abranger toda a funcionalidade do JUnit, além de fornecer testes de aceitação, funcionais e de integração, e não apenas testes unitários (BEUST e SULEIMAN, 2008).

57 Processo de construção de software Ter uma ferramenta para automatizar o processo de construção do software é fundamental para um rápido desenvolvimento usando Java. O Ant é uma ferramenta bastante flexível, pois permite descrever toda a construção do sistema, isso quer dizer que cada projeto pode ter um processo de construção diferente. Por outro lado o Maven possui formas padrão na construção dos projetos e pode ser considerado menos flexível do que o Ant. No entanto a decisão pelo Maven é justamente pela padronização de como lidar com os projetos, mas principalmente pelo gerenciamento de dependências, característica não encontrada no Ant. Além disso, o Maven integra-se facilmente com o TestNG (MASSOL et. al., 2006) Container Alguns containers EJB como o JBoss ou Glassfish poderiam ser utilizados como servidores Web para a execução da aplicação. Porém, como exigência um container web é requerido inicialmente (cartão n.º 30), e o Tomcat é uma boa escolha inicial, por ser gratuito, possuir uma extensa documentação e ser a implementação de referência da Sun de containers Web (SUN, 2009) Persistência Objeto-Relacional Para a persistência dos dados, o JDBC pode tornar o desenvolvimento trabalhoso devido ao uso de comandos SQL, além disso, existe uma dependência de um banco de dados específico, violando uma das qualidades do sistema (cartão n.º 29) que visa à independência do banco de dados. Os Entity Beans só funcionam dentro de containers EJB, porém estão também em desacordo com uma das exigências (cartão n.º 30) de inicialmente a aplicação rodar em um container web (BURKE e MONSON-HAEFEL, 2006). A JPA neste caso se faz mais adequada por ser o padrão de persistência da SUN substituindo os Entity Beans, interagindo bem com o EJB 3, quando este for necessário, porém com a capacidade de ser utilizada fora de containers EJB, e por ser independente do banco de dados utilizado, atendendo os cartões n.º 29, 30, 33. A escolha da JPA implica também na escolha de um provedor de persistência, neste caso o Hibernate será utilizado, por ser estável e bem

58 59 documentado facilitando o aprendizado e auxiliando o desenvolvimento ágil (HIBERNATE, 2009) Injeção de dependência A especificação do EJB 3 cobre a injeção de dependências, mas o uso de EJB em um projeto significa a necessidade de pesados containers. Com a utilização de uma metodologia ágil de desenvolvimento, as decisões de projetos guiaram para containers e frameworks leves, e não especificações complexas que exijam servidores de aplicativos para que estes recursos sejam utilizados. O Spring se mostrou mais adequado por possuir características semelhantes aos EJB como, por exemplo, a Injeção de Dependência e o modelo de programação baseados em POJO (Plain Old Java Objects), sem a necessidade de um container EJB. Além disso, o Spring se integra com outros frameworks como o Hibernate, JPA e também com o JSF, possibilitando o código ser gerenciado de forma limpa e eficiente (HEMRAJANI, 2006) Interface gráfica Para a construção de componentes de interface de usuário, será utilizado o JSF, a especificação da Sun para o desenvolvimento de aplicações Web, baseado em componentes. O JSF fornece um conjunto vasto de API s para o tratamento de eventos, validação de dados e componentes de interface, possibilitando a comunicação desses componentes a objetos de negócio de forma simplificada (GONÇALVES, 2009). Outro framework utilizado na interface gráfica é o Facelets, pois permite integrar com facilidade ao JSF. O uso do Facelets facilita a criação de templates, padronizando o layout, além de evitar a repetição de código HTML. O objetivo de utilizar JSF em conjunto com Facelets é permitir que novos componentes gráficos sejam criados, padronizados e reutilizados por toda a aplicação.

59 Arquitetura do Sistema A importância na definição de um padrão arquitetural é uma maneira de fazer reuso de código e componentes, bem como na padronização da estrutura, devido à utilização de frameworks e soluções existentes. Além disso, uma arquitetura de software reutilizável auxilia o desenvolvimento ágil de sistemas (SOMMERVILE, 2007). A arquitetura do sistema ERP proposto será uma arquitetura Web de três camadas padrão, com a camada cliente (navegador Web), camada de aplicação (servidor de aplicativos) e a camada de dados (banco de dados). O modelo em camadas organiza o sistema em camadas cada uma das quais fornecendo um conjunto de serviços, apoiando o desenvolvimento incremental, tornando a arquitetura modificável e portável. A Figura 16 mostra a arquitetura do sistema ERP. No desenvolvimento de sistemas orientados a objetos, existem soluções simples e elegantes para problemas específicos, estas soluções são conhecidas como Padrões de Projetos (Design Patterns). Os Padrões de Projetos descrevem soluções desenvolvidas, evoluídas e testadas ao longo do tempo, que permitem personalizá-las para resolver problemas de projetos num contexto particular (GAMMA et. al., 2000). Na arquitetura do sistema proposto, foram utilizados alguns padrões de projetos que serão explicados no decorrer desta seção. O padrão Front Controller define um simples componente que é responsável por processar todas as solicitações do cliente, ou seja, o Front Controller é um canal de entrada das solicitações, ele recebe as solicitações, decide o tipo de ação tomar e delega a um comando para realizar a ação (ALUR et. al., 2003). Neste caso o controlador do sistema é uma Servlet fornecida pelo JSF, o FacesServlet, que reage as solicitações dos clientes, processando a ação e os eventos de alteração de valores, enquanto delega o código para os controladores atualizarem o modelo ou a apresentação (GONÇALVES, 2008).

60 61 Figura 16 - Arquitetura do Sistema. Também importante é o uso do padrão de projetos MVC ou modelo-visão-controlador (Model-View-Controller), como encontrado na maioria das estruturas Web atuais baseadas em Java. O MVC tem como objetivo separar a lógica de negócio da apresentação, permitindo a comunicação entre elas através de um controlador, a fim de desacoplar as camadas provendo maior flexibilidade, pois o modelo lida com os dados, que são obtidos pelo controlador e passados a interface (view) para gerar a apresentação (BASHAM, SIERRA e BATES, 2008). Outro padrão de projeto muito utilizado em desenvolvimento de sistemas Java EE é o Data Access Object (DAO). O DAO é uma interface que encapsula todo o acesso aos dados armazenados em um banco de dados. Ele também é responsável por gerenciar as conexões com banco de dados para a recuperação e armazenamento dos dados (ALUR, 2003). Com a utilização do DAO genérico o desenvolvimento é orientado a interface, onde são definidos métodos de manipulação de dados, e os serviços acessam as interfaces, desconhecendo a implementação utilizada. Na camada intermediária estão os frameworks Spring e Hibernate. O Hibernate torna a persistência do banco de dados mais fácil, reduz esforços do desenvolvedor com códigos SQL

61 62 e desacopla a dependência com banco de dados. O Hibernate permite referenciar tabelas e registros de banco de dados como simples objetos Java, também conhecidos como POJO (HEMRAJANI, 2006). O Spring por sua vez utiliza o padrão de injeção de dependência, que tem por finalidade desacoplar a dependência entre os objetos, fornecendo esta dependência em tempo de execução e retirando dependências do código fonte, diminuindo o vínculo entre as classes. O objetivo desta arquitetura é tornar o sistema modular, permitindo o reuso na construção dos componentes, bem como buscar atender a alta coesão e o baixo acoplamento entre estes componentes. 3.6 Diagrama de Classe Diagrama de classes na engenharia de software é um tipo de estrutura que representa as classes do sistema, seus relacionamentos, suas ações e atributos. Os diagramas de classes são amplamente utilizados na construção do modelo de classes desde o nível de análise até o nível de especificação, por possuir um rico detalhamento em termos de notação (BEZERRA, 2006). Após a descrição dos casos de uso, é possível realizar a identificação de classes. As classes identificadas são refatoradas para retirar inconsistências e redundâncias. Então as classes são documentadas e o diagrama de classes inicial é construído. A Figura 17 é apresenta o resultado do modelo de classes do domínio.

62 Figura 17 - Diagrama de Classe do Sistema. 63

63 Modelo do Banco de Dados A modelagem de dados se refere à atividade de especificação das estruturas de dados e regras de negócio necessárias para o entendimento e documentação dos requisitos de dados (ELMASRI e NAVATHE, 2005). Uma vez que todos os requisitos tenham sido levantados e analisados, um modelo conceitual é criado. Este modelo é um projeto de alto nível que contêm uma descrição concisa dos requisitos de dados dos usuários, sem detalhes de implementação. A próxima etapa é a implementação real do banco de dados utilizando um Sistema Gerenciador de Banco de Dados (SGBD) que é representado pelo modelo relacional. O modelo relacional representa o banco de dados como uma coleção de tabelas, e cada tabela possui um conjunto de valores, representadas por linhas e colunas. A Figura 18 apresenta o modelo relacional do sistema, e seu resultado é um esquema do banco de dados no modelo de dados de implementação do SGBD.

64 Figura 18 - Modelo Relacional do Banco de Dados. 65

65 66 4 Estudo de Caso O estudo de caso utilizado nesse trabalho é realizado sob o protótipo da aplicação ERP desenvolvida para a empresa distribuidora de alimentos Triunfante Comércio de Alimentos Ltda, com o objetivo de validar a integração entre frameworks e padrões de projeto utilizados na arquitetura do sistema proposto. A proposta foi desenvolver um sistema ERP baseado nos requisitos levantados junto à empresa distribuidora, os quais definiram os módulos do sistema ERP a serem desenvolvidos. Foram definidos os seguintes módulos: administrativo, financeiro, compras e vendas. O módulo administrativo engloba todos os cadastros necessários para o funcionamento do sistema. O modulo financeiro é formando pelas contas a pagar e contas a receber. Contas a pagar são obrigações assumidas pela empresa, que devem ser saldadas dentro do vencimento enquanto contas a receber são as vendas realizadas pela empresa que devem ser saldadas pelos compradores. O módulo compras gerencia o estoque e as compras realizadas. O módulo vendas é responsável por todo o gerenciamento de vendas ocorridas e pela emissão de notas fiscais. 4.1 Sistemas ERP Antes da década de 90, as empresas não contavam com uma tecnologia de apoio para a integração dos dados e, na maioria das vezes, uma mesma empresa desenvolvia ferramentas internas para diferentes setores a fim de manter e gerenciar as informações (OLIVEIRA e RAMOS, 2002). Desta forma as informações se dividiam entre diferentes sistemas, causando problemas de disponibilidade, confiabilidade e integridade. A Figura 19 apresenta este cenário.

66 67 Figura 19 - Dados não centralizados. Neste contexto surgiram os sistemas Enterprise Resource Planning (ERP) ou Sistemas Integrados de Gestão (SIG) explorando uma necessidade e prometendo solucionar estes problemas ao integrar os diversos departamentos de uma empresa em um único sistema e coordenar todos os processos administrativos desta empresa, armazenando de forma centralizada, consistente e segura os dados (DAVENPORT, 1998). De acordo com Souza e Zwicker (2000) os sistemas ERP podem ser definidos como sistemas de informação integrados distribuídos na forma de pacotes comerciais, para suportar os diferentes setores e operações de uma empresa. Eles são divididos em módulos compartilhando um único banco de dados centralizado, garantindo a consistência dos dados, além de permitir a utilização de ferramentas de análise e planejamento para tomadas de decisão em setores, tais como finanças, recursos humanos e outros. Os sistemas ERP prometem a integração de todo o fluxo de informações impondo sua própria lógica na estratégia, organização e cultura de uma empresa. Este tipo de sistema surgiu de um problema: a fragmentação da informação em grandes organizações, pois as companhias não as armazenavam em um simples repositório, ao invés disso as informações ficavam espalhadas em dezenas ou centenas de sistemas distintos, lidando com um enorme custo ao armazenar e processar dados redundantes (DAVENPORT, 1998). Segundo Wood Jr. (1999) estes sistemas não são desenvolvidos para solucionar problemas específicos, mas para atender requisitos genéricos das empresas, permitindo ser

67 68 implementados com pequenas adaptações a qualquer empresa. O autor diz que os sistemas ERP são capazes de agilizar o processo de tomadas de decisão por permitir a integração e as interações entre as diferentes operações dentro de uma empresa, além de permitir uma análise do desempenho da empresa em tempo real. 4.2 Arquitetura de Sistemas ERP A arquitetura do sistema ERP é uma evolução do MRPII (Manufacturing Resource Planning), uma poderosa ferramenta de gestão, planejamento e controle de produção utilizada nos anos 80. No entanto, os sistemas MPRII se limitavam apenas a soluções para sistemas produtivos no setor de manufatura. Nos anos 90 uma nova classe de soluções expandida do MRPII surgiu na promessa de integração não apenas nos limites do setor de manufatura, mas aos demais setores dentro das organizações. Esta nova solução foi re-batizada de ERP (CORRÊA e GIANESI, 2001). Davenport (1998) apresenta as funcionalidades dos sistemas ERP divididas em módulos. Isso permite as empresas implementar o sistema de acordo com sua necessidade, implementando apenas as funções de que necessita. Alguns exemplos do módulo financeiro seriam contas a pagar, contas a receber e contabilidade. O módulo de vendas consistiria de funções como previsões, análise de vendas e processamento de pedidos. Funções do módulo de gestão de recursos humanos seriam RH e folha de pagamentos. O autor diz que no centro do ERP está o banco de dados que recebe e fornece dados de uma série de aplicações suportando os diferentes módulos de uma empresa. Quando informações relacionadas a determinado módulo são inseridas, todo o sistema é atualizado, devido ao banco de dados centralizado, agilizando completamente o fluxo de informações. A Figura 20 apresenta a arquitetura de um ERP.

68 69 Figura 20 - Arquitetura de um sistema ERP. Fonte: Adaptada de Davenport (1998).

69 70 5 Análise e Resultados Neste capítulo serão demonstrados os detalhes de implementação, protótipos e os resultados provenientes do desenvolvimento de um sistema ERP. 5.1 Detalhes de implementação O objetivo desta seção é demonstrar os aspectos principais da implementação, destacando os frameworks e padrões de projetos utilizados Entidades persistentes com JPA A JPA é baseada no conceito de POJO, que são classes simples, representando os objetos persistentes como entidades. Como as entidades são definidas por classes Java comuns, é possível herdar de outras classes ou torná-las abstratas, sem restrições, por não dependerem de outros frameworks ou bibliotecas. A chave primária indica um conceito importante nas entidades, pois identifica um objeto persistente e seu estado. Além disso, para que as entidades se tornem persistentes, é necessário estar associadas a um contexto de persistência que fornece a conexão entre os objetos e o banco de dados. A Figura 21 mostra a entidade Categoria, destacando o mapeamento objeto/relacional utilizando a JPA. A utilização de Anotações Java para o mapeamento, disponibilizadas por interfaces da JPA localizadas no pacote javax.persistence, dispensa os inúmeros descritores XML para cada uma das entidades. As Anotações são tipos especiais em Java com o intuito de fornecer informações extras ao compilador, como metadados. Uma anotação é precedida por um símbolo

70 71 Na Figura 21 a especifica que a classe é uma especifica a tabela primária para a entidade identifica um atributo como a chave primária da tabela define uma estratégia para a chave define um gerador de chaves primárias por meio de uma Sequência define uma relação um-para-muitos utilizado em banco de dados relacional = "categoria") public class Categoria implements = GenerationType.SEQUENCE, generator = = "categoria_seq", sequencename = "categoria_seq", allocationsize = 1) private Integer id; private String nome; private String = FetchType.LAZY, mappedby = "categoria") private Set<Produto> produtos; public Categoria() { } } //getters e setters omitidos Figura 21 - Entidade Categoria mapeada. Como dito anteriormente as entidades precisam estar associadas a um contexto de persistência. E este contexto precisa ser configurado no arquivo persistence.xml. A Figura 22 mostra esse arquivo. Este arquivo descreve informações importantes quanto às entidades e o banco de dados através da tag <persistence-unit>. A tag <provider> especifica um provedor de persistência, neste caso o Hibernate. As tags definidas em <properties> contém informações relativas ao banco de dados, como a string de conexão com o banco, nome de usuário, senha, dialeto e driver JDBC do banco de dados utilizado. No caso, a configuração está utilizando o driver do PostgreSQL (HIBERNATE, 2010).

71 DAO Genérico Embora o DAO seja um padrão de projetos responsável por encapsular todo o acesso ao banco de dados, ele pode ser simplificado com a utilização do DAO Genérico. Sabendo que o DAO repete métodos para as operações básicas como inserção, consulta e deleção dos dados, com a utilização de genéricos no Java é possível isolar tais métodos e reutilizá-los criando o DAO Genérico. Isso possibilita que novas entidades utilizem genericamente os métodos, sem repetição de código. A Figura 23 mostra a interface DAO genérico. <?xml version="1.0" encoding="utf-8"?> <persistence version="1.0" xmlns=" xmlns:xsi=" xsi:schemalocation=" <persistence-unit name="erp_fatec"> <provider>org.hibernate.ejb.hibernatepersistence</provider> <class>br.com.erp.fatec.entities.categoria</class> <!--Demais classes omitidas--> <properties> <property name="hibernate.connection.driver_class" value="org.postgresql.driver"/> <property name="hibernate.connection.url" value="jdbc:postgresql://localhost:5432/erp_fatec"/> <property name="hibernate.connection.username" value="fatec" /> <property name="hibernate.connection.password" value="1" /> <property name="hibernate.dialect" value="org.hibernate.dialect.postgresqldialect" /> <property name="hibernate.show_sql" value="true"/> <property name="hibernate.format_sql" value="true" /> </properties> </persistence-unit> </persistence> Figura 22 - O arquivo persistence.xml.

72 O DAO e a integração Spring e JPA Por meio do Spring é possível delegá-lo a responsabilidade no controle de transações, evitando o controle manual na abertura e fechamento de transações. Isso quer dizer que se tudo ocorrer bem no método salvar() da interface DaoGenerico por exemplo, os dados são enviados e persistidos no banco de dados. Caso uma exceção seja lançada, um rollback, gerenciado pelo Spring desfaz a operação (SPRING FRAMEWORK, 2010). A Figura 24 mostra algumas das características do Spring atuando no DAO. public interface DaoGenerico<T, ID extends Serializable> { Class<T> getobjectclass(); T salvar(t object); T atualizar(t object); void remover(t object); T pesquisarporid(id id); List<T> pesquisartodos(); List<T> pesquisarporparametros(string query, Map<String, Object> params); List<T> pesquisarporexemplo(t example); } T pesquisarresultadounico(string query, Map<String, Object>params); Figura 23 - A interface DaoGenerico. A e a presença da tag <tx:annotation-driven> no arquivo de configuração do Spring concede automaticamente a classe o comportamento transacional. Outra característica importante do Spring na integração com a JPA é a injeção de EntityManager no serviço quando instanciado através da de javax.persistence, característica similar aos do EJB 3. Na interface EntityManager é onde se encontra os principais métodos para inserção, consulta, atualização e deleção das informações no banco de dados.

73 O Spring e o TestNG O Spring oferece alguns dos benefícios já citados na realização de testes integrados ao framework de teste TestNG. Com a injeção de dependências o Spring carrega o contexto da aplicação na realização dos testes, permitindo a utilização de objetos da camada de acesso ao banco de dados ou objetos controladores, de maneira a isolar ainda mais os testes unitários. A Figura 25 apresenta a classe de testes unitários CategoriaDaoTest, simulando o acesso a camada de dados para a persistência, atualização e remoção de objetos do tipo = true, propagation = Propagation.REQUIRED) public class DaoGenericoImpl<T, ID extends Serializable> implements DaoGenerico<T, ID> { private EntityManager public void setentitymanager(entitymanager em) { this.entitymanager = em; } = false, propagation = Propagation.REQUIRED) public T salvar(t object) { getentitymanager().clear(); getentitymanager().merge(object); return object; } //outros métodos omitidos Figura 24 - Spring atuando no Dao. A classe abstrata AbstractTestNGSpringContextTests fornecida pelo Spring Framework é responsável pela integração TestNG e Spring. A é utilizada para definir o local do arquivo de configuração do Spring e carregar o contexto da define um atributo ou um método setter para a injeção de dependências (SPRING FRAMEWORK, 2010). A fornecida pelo TestNG é utilizada para marcar uma classe ou método como parte do teste (TESTNG, 2010).

74 O Maven e o processo de construção de software O Maven possui uma estrutura bem definida nos projetos em ambientes de desenvolvimento, separando com clareza pacotes com códigos-fonte, testes e recursos como imagens, xml e outros tipos de arquivos utilizados pela aplicação. A Figura 26 mostra a estrutura básica de um projeto = { "/applicationcontext.xml" }) public class CategoriaDaoTest extends AbstractTestNGSpringContextTests CategoriaDao public void testsalvar() { Categoria categoria = categoriadao.salvar(criarcategoria()); Assert.assertNotNull(categoria); Assert.assertEquals(categoria.getNome(), "Sucos"); } public void testpesquisarporexemplo() { Categoria categoria = criarcategoria(); List<Categoria> listacategorias = categoriadao.pesquisarporexemplo(categoria); Assert.assertNotNull(listaCategorias); for (Categoria c : listacategorias) { Assert.assertEquals(c.getNome(), "Sucos"); } } //outros métodos omitidos Figura 25 - Teste unitário com Spring e TestNG. As etapas de projeto como compilação, testes, distribuição da aplicação, dentre outras são definidas através de fases do ciclo de vida do Maven. Por exemplo ao usar a fase package do Maven, isto significa que ele validará o projeto, tentará compilar o código-fonte, executará os testes e por fim empacotará a aplicação de forma automatizada (MAVEN, 2010). O gerenciamento de dependências externas é feito pelo Maven, e é uma de suas principais características. As dependências são declaradas no arquivo pom.xml como mostrado na Figura

75 Com isso evita-se a necessidade de descobrir e especificar as dependências transitivas que o projeto necessita, incluindo-as automaticamente. Além disso o Maven integra-se facilmente com o TestNG. A Figura 28 mostra o Maven executando a fase package, os resultados dos testes e pacote JAR criado. Figura 26 - Estrutura básica de um projeto Maven O JSF e o padrão de projeto MVC O JSF além de fornecer ferramentas para criação de apresentação visual, como componentes de interface e validadores de dados, ele é responsável por interagir com o usuário, fornecendo recursos para a aplicação lógica e a lógica de negócios de uma aplicação Web (GONÇALVES, 2008). Portanto, a separação das camadas do modelo arquitetural MVC é obtida através do JSF, por meio da servlet FacesServlet e pelos ManagedBeans. Os Managed Beans são objetos simples que expõe objetos de negócios para a apresentação e estabelece regras de navegação para ações de conclusão de uma página. Com isso o JSF conecta a apresentação ao modelo, permitindo um componente de apresentação ser unido a uma propriedade de um objeto modelo, além de fornecer um controlador, que reage as solicitações dos clientes, processando a ação e os eventos de alteração de valores, enquanto delega o código para atualizar o modelo ou a apresentação. A Figura 29 exibe a tela de login e a Figura 30 detalha as tags utilizadas,

76 77 exemplificando a utilização de um Managed Bean (usuariocontroller), responsável pela comunicação entre a apresentação e o modelo. As tags recebem um id, na qual determina o nome do componente e no atributo value recebe os delimitadores #{..} conhecidos como JSF EL (JavaServer Faces Expression Language), expressões que indicam o Managed Bean na qual ligam o componente JSF ao atributo get correspondente do objeto modelo. <project xmlns=" xmlns:xsi=" xsi:schemalocation=" <modelversion>4.0.0</modelversion> <groupid>br.com.fatec.erp</groupid> <artifactid>erp-domain</artifactid> <version>1.0-snapshot</version> <dependencies> <dependency> <groupid>postgresql</groupid> <artifactid>postgresql</artifactid> <version> jdbc4</version> </dependency> <dependency> <groupid>org.springframework</groupid> <artifactid>spring</artifactid> <version>2.5.6</version> </dependency> <dependency> <groupid>org.hibernate</groupid> <artifactid>hibernate-core</artifactid> <version>3.3.2.ga</version> </dependency> <!--Demais dependências omitidas--> </dependencies> </project> Figura 27 - O arquivo pom.xml. A classe UsuarioController apresentada na Figura 31 exibe alguns atributos, métodos de regras de controle e anotações referentes ao Spring integrando-se aos Managed Beans do JavaServer Faces. A define o nome do bean JSF indicando que a classe será utilizada como controlador na aplicação (SPRING FRAMEWORK, 2010). Este é o nome

77 78 dado ao elemento <managed-bean-name>, que será adicionado no arquivo faces-config.xml. A utilizada pelo Spring é responsável por determinar o escopo do bean, que também deve ser o mesmo do elemento <managed-bean-escope/> de faces-config.xml. O escopo de um bean pode ter as seguintes durações: sessão, requisição ou aplicação. C:\work_eclipse\Erp_domain>mvn package [INFO] Scanning for projects... [INFO] [INFO] Building Unnamed - br.com.fatec.erp:erp-domain:jar:1.0-snapshot [INFO] task-segment: [package] [INFO] [INFO] [resources:resources {execution: default-resources}] [INFO] Copying 3 resources T E S T S Running TestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: sec Results : Tests run: 6, Failures: 0, Errors: 0, Skipped: 0 [INFO] [jar:jar {execution: default-jar}] [INFO] Building jar: C:\work_eclipse\Erp_domain\target\erp-domain-1.0- SNAPSHOT.jar [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Tue May 04 22:08:46 BRT 2010 [INFO] Final Memory: 10M/19M [INFO] C:\work_eclipse\Erp_domain> Figura 28 - Resultados da execução da fase package do Maven. Há outro importante arquivo do JavaServer Faces utilizado na implementação do MVC, o faces-config.xml, como mostrado na Figura 32. O faces-config.xml possui diversas configurações da aplicação, como definição dos Managed Beans, validadores, conversores e regras de navegação (SUN, 2010). A tag <managed-bean-name> define o nome do bean que será acessado pelas páginas JSF e a tag <managed-bean-class> define o nome da classe

78 79 utilizada, neste caso UsuarioController. O elemento <navigation-rule> define a navegação entre as páginas, dependendo da mensagem retornada pelo controlador. No exemplo mostrado na Figura 31 o método login() retorna uma String logado em caso de sucesso ou null em caso de falha. Portanto, se o login retornar logado a página será redirecionada para /logado.xhtml, senão apenas uma mensagem de erro é exibida ao usuário. Figura 29 - Tela de Login.

79 80 <fieldset> <legend>login</legend> <label jsfc="h:outputlabel" for="nomeusuario">nome de usuário:</label> </fieldset> <input jsfc="h:inputtext" id="login" styleclass="field" value="#{usuariocontroller.usuario.login}" required="true" requiredmessage="login obrigatório" style=" width : 215px;"/> <br/><br/><br/> <label jsfc="h:outputlabel" for="senha">senha:</label> <input jsfc="h:inputsecret" id="senha" styleclass="field" value="#{usuariocontroller.usuario.senha}" required="true" requiredmessage="senha obrigatória" style=" width : 216px;"/> <br/><br/><br/> <input jsfc="h:commandbutton" type="submit" action="#{usuariocontroller.login}" id="logar" value="entrar no Sistema" style=" width : 325px;"/> Figura 30 - Tags da tela Login e o Managed Bean usuariocontroller.

80 81 public class UsuarioController private DaoGenerico<Usuario, Integer> Autowired private DaoGenerico<Pedido, Integer> Autowired private DaoGenerico<ItensPedido, Integer> itenspedidodao; private Pedido pedido; private ItensPedido itens; private Usuario usuario; //captura sessão do contexto criado pelo JavaServer Faces FacesContext fc = FacesContext.getCurrentInstance(); HttpSession session = (HttpSession) fc.getexternalcontext().getsession(false); private Usuario verificarusuario(string login) { String query = "SELECT u FROM Usuario u WHERE u.login=:login"; Map<String, Object> params = new HashMap<String, Object>(); params.put("login", login); return usuariodao.pesquisarresultadounico(query, params); } } // executa o login no sistema e direciona o usuário ao local indicado public String login() { Usuario u = verificarusuario(usuario.getlogin()); if (u!= null && u.getsenha().equals(usuario.getsenha())) { session.setattribute("user", usuario.getlogin()); usuario = u; if (session.getattribute("msg")!= null) { session.removeattribute("msg"); } // redireciona para a área do usuário return "logado"; } else { FacesUtils.mensErro("Usuário ou senha inválidos"); } return null; } //demais métodos e atributos omitidos Figura 31 - A classe UsuarioController.

81 82 <?xml version="1.0" encoding="utf-8"?> <faces-config version="1.2" xmlns=" xmlns:xi=" xmlns:xsi=" xsi:schemalocation=" <!-- Gerencia o Usuário --> <managed-bean> <managed-bean-name>usuariocontroller</managed-bean-name> <managed-bean-class> br.com.integrator.controller.usuariocontroller </managed-bean-class> <managed-bean-scope>session</managed-bean-scope> </managed-bean> <!-- Navegação para a área do usuário --> <navigation-rule> <from-view-id>*</from-view-id> <navigation-case> <from-outcome>logado</from-outcome> <to-view-id>/logado.xhtml</to-view-id> </navigation-case> </navigation-rule> <!--Demais elementos omitidos--> </faces-config> Figura 32 - O arquivo faces-config.xml. 5.2 Telas do Sistema O objetivo desta seção é apresentar algumas das telas do sistema. A Figura 33 apresenta a tela de login do sistema.

82 Figura 33 - Tela de Login. 83

83 84 A Figura 34 apresenta a tela de Cadastro de Clientes. Figura 34 - Tela de Cadastro de Clientes.

84 85 A Figura 35 apresenta a tela de pesquisa de produtos. Figura 35 - Tela de Pesquisa de Produtos.

85 86 A Figura 36 apresenta a tela de cadastro de produtos. Figura 36 - Tela de Cadastro de Produtos.