ARQUITETURA DO SISTEMA ERP PEGASUS

Transcrição

1 ARQUITETURA DO SISTEMA ERP PEGASUS Elaborado por: Bruno Duarte Nogueira Arquiteto de Software Data: 05/03/2012 1

2 Sumário 1. Introdução Tecnologias Web Tier Facelets JSF DWR JQuery Business Tier EJB JUnit Persistence Tier EJB JPA Ferramentas Eclipse Indigo Apache Maven VisualSVN Oracle GlassFish ireport PostgreSQL Padrões de Códigos Formatação de código Nomes de Variáveis Nomes de Métodos Documentação de Métodos Estrutura de Pacotes Nomenclaturas de JavaScript Nomenclaturas em geral Testes Unitários SVN Estrutura de diretórios Regras para versionamento Visão geral da Arquitetura

3 1. Introdução Projeto Pegasus Arquitetura do Sistema Versão Este documento tem como objetivo descrever a arquitetura do ERP Pegasus, bem como definir a política de normas e padrões adotados no decorrer do desenvolvimento. De maneira geral, serão retratados tópicos como formatação de código, testes unitários, tecnologias e ferramentas utilizadas, estrutura do projeto, entre outros. 2. Tecnologias O projeto Pegasus utilizará as seguintes tecnologias: 2.1. Web Tier Facelets Será utilizado apenas o recurso de templates do facelets, a fim de agilizar a criação das páginas do sistema JSF 1.2 As requisições síncronas serão realizadas através do JSF, sem o uso de extensões para este. Sua função será única e exclusivamente transferir os dados inseridos na tela para o(s) objeto(s) contido(s) no managed bean DWR 3.0 As requisições assíncronas serão realizadas através do DWR (Direct Web Remoting). A escolha desta tecnologia se deu pela agilidade que a mesma traz ao utilizar o Ajax. Os dados transferidos nestas requisições respeitarão o padrão JSON (JavaScript Object Notation) JQuery As iterações e efeitos entre os componentes da tela serão implementadas com o auxílio do JQuery, por possuir complexos recursos javascript abstraídos em funções fáceis de utilizar Business Tier EJB 3.0 Serão utilizados beans de sessão com intuito de disponibilizar regras de negócio para os módulos Web de maneira independente, ou seja, poderão haver vários módulos acessando 3

4 a mesma regra. Estes EJBs serão globais no servidor, fornecendo, com alta disponibilidade, recursos para todas as requisições feitas a ele. O acesso aos mesmos seguirá a especificação JSR-299 do J2EE JUnit 4.82 O primeiro nível de garantia de qualidade do código desenvolvido será contemplado através da criação de testes unitários baseados na camada Business. Desta forma, diminuiremos significativamente a probabilidade de erros durante a homologação do sistema. Estes testes unitários serão disparados pelo Apache Maven a cada compilação do projeto Persistence Tier EJB 3.0 Serão utilizados beans de sessão com intuito de disponibilizar regras de persistência para os módulos de negócio de maneira independente, ou seja, poderão haver vários módulos acessando a mesma regra. Estes EJBs serão globais no servidor, fornecendo, com alta disponibilidade, recursos para todas as requisições feitas a ele. O acesso aos mesmos seguirá a especificação JSR-299 do J2EE JPA 1.0 Será utilizada a API de persistência nativa do Java, pois a mesma oferece todos os requisitos necessários para viabilização do módulo de persistência do projeto, como gerenciamento de transações, recursos de lock e isolamento, controle de consistência das informações, entre outros. 3. Ferramentas Serão utilizadas as seguintes ferramentas para desenvolvimento do ERP: 3.1. Eclipse Indigo O Eclipse será adotado como a IDE para o desenvolvimento do projeto pelo fato de, além de ser padrão de mercado, é uma ferramenta flexível no que diz respeito à instalação de plugins para utilização de outras tecnologias. Outro fator importante é a integração que o Maven possui com ele Apache Maven O ERP será estruturado com o Apache Maven para, além da compilação e execução automatizada dos testes unitários, será utilizado como facilitador na geração do pacote do 4

5 projeto, utilização de plug-ins para o desenvolvimento e conexão com ferramentas de integração contínua VisualSVN Foi o serviço de versionamento adotado no projeto por já ser utilizado na companhia Oracle GlassFish 3.1 Será utilizado por não ter custos de licenças e contemplar todos os recursos da especificação J2EE ireport A escolha desta ferramenta para geração de relatórios foi influenciada por sua integração com recursos externos, como geração de código de barras, por sua completa documentação e total auxílio da comunidade Java PostgreSQL Banco de dados grátis e robusto, comumente utilizado em órgãos públicos. 4. Padrões de Códigos As principais vantagens de seguir padrões são: Código limpo e organizado. Fácil assimilação e manutenção. Maior qualidade do código produzido. Menos conflitos no SVN. Abaixo estão descritos os padrões de codificação que deverão ser rigorosamente seguidos durante a implementação do sistema Formatação de código Antes de subir uma classe Java ou uma JSP para o SVN, a mesma deverá ser formatada, utilizando o atalho [Ctrl] + [Shift] + F do eclipse. Para classes Java, as importações de outras classes deverão ser organizadas, utilizando o atalho [Ctrl] + [Shift] + O Nomes de Variáveis Os nomes das variáveis deverão ser suficientemente claros a fim de saber sua função apenas pelo seu nome, por exemplo: 5

6 4.3. Nomes de Métodos Nomes de métodos deverão ser suficientemente claros a fim de saber sua função apenas pelo seu nome, por exemplo: Os nomes dos métodos deverão possuir um verbo no infinitivo representando a função que será executada e um complemento para distinguir onde a operação terá efeito, como mostra o trecho abaixo: O quê? Cadastro. Onde? Usuário. Método: cadastrarusuario() Documentação de Métodos Todos os métodos do sistema deverão possuir JavaDoc, a fim de identificar a função do método, quem o implementou e quando foi criado, facilitando a comunicação entre o time com relação à eventuais dúvidas que possam surgir sobre o código desenvolvido. Segue um modelo: 4.5. Estrutura de Pacotes A estrutura de pacotes principal será net.goldsystem.erp.<modulo>, onde <modulo> pode ser persistence. business. web.<nome> (<nome> será substituído por cemitério, financeiro, planos, etc). Sub pacotes: 6

7 Entidades JPA: pojo. Beans de sessão. o Interfaces: ejb. o Implementação das interfaces: ejb.impl. Exceções: exception. Classes Utilitárias (constantes, formatações, máscaras, etc): util. Data Transfer Object: dto. Managed Beans: mbean. Enums: enum. Servlet Filter: filter. Facade Classes: facade. Stub Classes: stub Nomenclaturas de JavaScript Os arquivos com extensão *.js possuirão a seguintes regras de nomes: <prefixo>.<módulo>.<função>-<versão>.js, onde prefixo: possuirá o valor fixo gs. módulo: representará o módulo ao qual o arquivo JavaScript se refere, por exemplo, usuário. função: representará qual a tarefa exercida pelo JavaScript, por exemplo, cadastro. versão: representará a versão do arquivo, por exemplo, 1.0. O arquivo JavaScript para a tela de cadastro de usuários se chamaria, portanto: gs.usuario.cadastro-1.0.js 4.7. Nomenclaturas em geral Abaixo seguem os padrões, representados em exemplos, das nomenclaturas para o projeto Pegasus: cadastrarusuario.xhtml: Página utilizada para cadastro de usuários. BusinessException: Exceção que será utilizada no módulo de negócios da aplicação. UsuarioFacade.java: Classe que possuirá os métodos de faixada para utilização do DWR. UsuarioMBean.java: Managed Bean usado para controle dos componentes da página de cadastro de usuário no nível servidor. UsuarioBusinessEJB.java: Classe que conterá todas as regras de negócio atreladas ao módulo de usuário. TipoLovEnum: Enum que conterá todas as constantes que envolverão os tipos de listas de valores do sistema. 7

8 UsuarioPersistenceEJB.java: Classe que terá todas as operações de persistência envolvidas no módulo de usuário. Usuario.java: Classe que representa a entidade Usuário, possuindo todos os atributos comuns de usuário. UsuarioDTO: Classe que receberá todas as informações referentes a usuário, podendo representar uma estrutura que contemple uma ou mais entidades. FiltroAcesso: Representa o filtro que controlará as regras de acesso ao sistema. FormatacaoUtil.java: Classe que terá todos os métodos utilitários para formatação de dados na aplicação. BuscaCepStub.java: Classe que terá a chamada ao webservice de busca de endereços. BaseUsuario.java: Classe pai de usuário. Todas as classes genéricas ou pais, deverão conter o prefixo Base. 5. Testes Unitários Os testes unitários serão criados na camada Business, utilizando a tecnologia JUnit, respeitando as seguintes regras: Um JUnit para cada bean de sessão. A classe JUnit deverá ter o mesmo nome do bean de sessão ao qual ela corresponde, com o prefixo Teste. 6. SVN As políticas adotadas para a gestão do repositório do projeto seguirá as premissas abaixo: 6.1. Estrutura de diretórios O repositório possuirá a seguinte estrutura de diretórios: + branches --- PegasusERP_<OS> + tags --+ release --- PegasusERP-<VERSÃO> --+ sprint --- PegasusERP-<SPRINT> + trunk --+ PegasusERP --- AnaliseDesign --- Dettec --- PegasusERP 8

9 Abaixo estão descritos os detalhes de cada item dentro do SVN: branches > PegasusERP-<OS>, onde <OS> será o número da solicitação de mudança/correção que gerou a branch. tags > release > PegasusERP-<VERSÃO>, onde <VERSÃO> representará a versão da release, por exemplo, r tags > sprint > PegasusERP-<SPRINT>, onde <SPRINT> representará o número do Sprint que a tag em questão representa, por exemplo, s001. trunk > PegasusERP > AnaliseDesign: local onde serão armazenados os artefatos referentes à análise do sistema, como documento de requisitos, diagramas de casos de uso, estudo de viabilidade, protótipos, etc. trunk > PegasusERP > Dettec: local onde serão armazenados os artefatos referentes ao detalhamento técnico do sistema, como documentos de arquitetura e configuração de ambiente, scripts de banco de dados, dumps, bibliotecas, etc. trunk > PegasusERP > Fontes: local onde serão armazenados os fontes do sistema Regras para versionamento A cada final de Sprint, uma tag será gerada para o mesmo, conforme tópico 6.1 deste documento. A cada release entregue, uma tag será gerada para a mesma. A tag deverá ser gerada apenas após o aceite do Product Owner, no caso de Sprint, e aceite do solicitante, no caso de release. Uma branch deverá ser criada para cada solicitação de mudança e/ou correção que houver no sistema. Depois de finalizada a solicitação, a codificação da mesma deverá ser integrada ao código fonte, realizando um merge no trunk e/ou tag que necessitou de alteração. 7. Visão geral da Arquitetura Abaixo segue a ilustração da arquitetura proposta para o ERP Pegasus: 9

10 10