Mudanças entre as edições de "PJe2:Documento da Arquitetura de Referência"
De PJe
(→Definição da arquitetura de referência) |
(→Definição da arquitetura de referência) |
||
| Linha 151: | Linha 151: | ||
<font color=red> TODO: desenhar Figura 1 conforme Rascunho 1 e incluir aqui </font> | <font color=red> TODO: desenhar Figura 1 conforme Rascunho 1 e incluir aqui </font> | ||
<br> | <br> | ||
| − | '''Figura 1. Visão | + | '''Figura 1. Visão Geral das Camadas da Arquitetura''' |
| − | [[imagem: | + | [[imagem:Visao_Camadas_da_Arquitetura.jpg | '''Figura 1. Visão Geral das Camadas da Arquitetura''']] |
<br><br> | <br><br> | ||
Edição das 18h45min de 1 de junho de 2015
Conteúdo |
Introdução
Apresentamos neste documento a arquitetura de referência para o desenvolvimento do software Processo Judicial Eletrônico versão 2.0 (PJe 2.0) e suas evoluções futuras. As seções e subseções do documento explicarão os detalhes pertinentes da arquitetura.
Objetivo do documento
O objetivo principal é especificar a arquitetura de software de referência a ser utilizada como padrão para o desenvolvimento do PJe 2.0 e suas evoluções futuras. Nesta especificação está incluído: a estruturação do projeto do software, a organização das camadas do software, os componentes e arcabouços utilizados no software, a definição das principais tecnologias e ferramentas a serem utilizadas, os padrões de projeto e boas práticas de programação que devem ser utilizadas no desenvolvimento do software. A metodologia de desenvolvimento do software proposta será tratada em outro documento.
Termos, abreviações e convenções adotadas
Explicitamos nesta seção, uma tabela contendo os termos, abreviações e convenções adotadas no documento da arquitetura de referência do PJe 2.0. A leitura prévia desta seção é fortemente recomendada para compreensão das demais seções.
[TODO: citar as ref. bib. nos termos necessários]
| Termo | Descrição |
| Apache Maven | É um software capaz de gerenciar componentes de software e as dependências entres esses componentes, de prover a integração contínua desses componentes, de gerenciar a construção do projeto do software e de documentar e reportar informações inerentes à essa construção. |
| API | Acrônimo para a expressão inglesa Application Programming Interface ou interface de programação de aplicativos; essa interface é composta por um conjunto de rotinas, protocolos, padrões de programação e ferramentas que permitem a construção de aplicativos de software. |
| Applet | Applet é um software aplicativo que é executado no contexto de outro programa. |
| Batch | Termo usado para expressar processamento de dados que ocorre através de um lote (batch) de tarefas enfileiradas, de modo que o software responsável por esse processamento somente processa a próxima tarefa após o término completo da tarefa anterior. |
| Browser | Navegador web. Ex.: Firefox, Internet Explorer. |
| Build | Termo do inglês que significa 'construir', isto é, é o ato de realizar a compilação de todos os componentes de um ou mais projetos de software envolvidos cujo intuito é deixar pronta a aplicação de software para ser instalada em um ambiente real, por exemplo, em um servidor de aplicações. |
| Cache | É um dispositivo de acesso rápido, interno a um sistema, que serve de intermediário entre um operador de um processo e o dispositivo de armazenamento ao qual esse operador concede autorização. |
| CRUD | Sigla para Create (Criar), Read (Ler), Update (Atualizar) e Delete (Remover): são operações básicas utilizadas em um software que gerencia bancos de dados. |
| DBA | Database Administrator ou administrador de bancos de dados. |
| Deploy | Instalar/implantar uma aplicação de software em um servidor de aplicações. |
| DHTML | Dynamic HTML, ou DHTML, é a união das tecnologias HTML, Javascript e uma linguagem de apresentação. |
| DOM | Document Object Model ou Modelo de Objetos de Documentos é uma especificação da W3C, independente de plataforma e linguagem, onde se pode dinamicamente alterar e editar a estrutura, conteúdo e estilo de um documento eletrônico. |
| EJB | Enterprise Java Bean. É um componente do tipo servidor da plataforma Java EE que executa no container do servidor de aplicação. |
| HTML | Acrônimo para a expressão inglesa HyperText Markup Language (ou linguagem de marcação de hipertexto); essa linguagem de marcação é utilizada para produzir páginas para web. |
| HTTP | Acrônimo para a expressão inglesa Hypertext Transfer Protocol (ou protocolo de transferência de hipertexto); é um protocolo de comunicação entre sistemas de informação o qual permite a transferência de dados entre redes de computadores, principalmente na web. |
| IDE | Integrated Development Environment ou ambiente integrado para desenvolvimento de software. |
| Java | Linguagem de programação orientada a objetos. |
| Java EE | Plataforma de desenvolvimento Java voltada para ambientes corporativos/empresariais. Também chamada de JEE. |
| Login | Ato de fornecer credenciais a um determinado sistema, de modo a acessar suas funcionalidades. |
| MVC | Model-View-Controller é um padrão de arquitetura de software que visa isolar a lógica (Model) do negócio da apresentação da tela (View) e do controle de navegação (Controller) da tela. |
| Query | É a operação de consulta realizada em um SGBD. |
| Servidor de aplicação | Software responsável por disponibilizar e gerenciar um ambiente para a instalação e execução de certas aplicações de software, centralizando e dispensando a instalação nos computadores dos usuários clientes dessas aplicações. Ex.: Jboss, Tomcat, entre outros. |
| Sessão HTTP | Sessão HTTP provém um modo de armazenar, no servidor de aplicação web, dados importantes relativos a um determinado usuário de uma aplicação. |
| RAD | Rapid application development (RAD), também conhecido como desenvolvimento rápido de aplicação; é um modelo de processo de desenvolvimento de software iterativo e incremental que enfatiza um ciclo de desenvolvimento extremamente curto. |
| SCRUM | É uma metodologia ágil para planejamento e gestão de projetos de software. |
| SGBD | Sistema gerenciador de bancos de dados. Ex.: Oracle, PostgreSQL, entre outros. |
| SQL | Structured Query Language ou linguagem de consulta estruturada; é a linguagem de declarativa padrão para bancos de dados relacionais. |
| SOA | Service Oriented Architecture ou arquitetura orientada a serviços; é um estilo de arquitetura de software cujo princípio fundamental preconiza que as funcionalidades implementadas pelas aplicações devem ser disponibilizadas na forma de serviços. |
| Sprint | Um sprint é a unidade básica de desenvolvimento em conforme a metodologia ágil SCRUM. |
| Stored procedure | Procedimento armazenado ou stored procedure é uma coleção de comandos da linguagem SQL para gerenciamento de bancos de dados. |
| SUN | Empresa criadora da plataforma Java. |
| WAP | Sigla para Wireless Application Protocol ou protocolo para aplicações sem fio. |
| Webservice | TODO: explicar |
| W3C | World Wide Web Consortium é um consórcio de empresas de tecnologia que desenvolve padrões para a criação e a interpretação dos conteúdos para web. |
| XML | eXtensible Markup Language é uma linguagem de marcação, recomendada pela W3C, que define um conjunto de regras para a codificação de documentos. |
| XSLT | XSL Transformations é uma linguagem de marcação XML usada para transformar documentos XML em outros documentos XML ou em outros formatos. |
Restrições da arquitetura
TODO: verificar se existem restrições impostas que foram obedecidas.
Justificativas arquiteturais
Nesta seção, explicitamos o conjunto de memorandos (técnicos, gerenciais, institucionais) que justificam as decisões arquiteturais da arquitetura de referência do PJe 2.0. Esses memorandos são resumos das discussões e estudos os quais balizam este trabalho.
- Requisitos do projeto PJe 2.0.
- O conjunto completo de premissas e requisitos (funcionais e não funcionais) consta no Plano Geral do Projeto PJe 2.0 ( [TODO: colocar link para o plano, se for desejado]). A saber, explicitamos apenas um resumo desse conjunto:
- Isolamento dos módulos de negócio (ou seja, módulos responsáveis pela lógica de negócio do software PJe) a fim de evitar efeitos colaterais indesejáveis provenientes das modificações no código-fonte.
- Permitir que o desenvolvimento dos módulos de negócio seja realizado isoladamente, inclusive com equipes distribuídas.
- Permitir que a implementação de um módulo de negócio qualquer seja totalmente substituída por nova implementação, sem prejudicar o funcionamento dos demais módulos.
- Isolamento das camadas lógicas do software, para evitar ao máximo o embaralhamento da lógica de negócio do software PJe e a dificuldade de leitura e compreensão do código-fonte
- Permitir que os módulos mais exigentes, quanto ao consumo de recursos de infraestrutura, possam ser "instalados" (deploy) mais de uma vez.
- Experiências prévias.
- Foram consideradas as seguintes experiências:
- Experiência prévia da equipe de arquitetos servidores do Poder Judiciário.
- Foram analisadas arquiteturas de referência de outras instituições (TCU, STF, SERPRO, TJRO, TJPE).
- Estudos diversos foram realizados pela equipe de arquitetos na primeira Sprint do projeto.
- Tecnologias adotadas.
- As tecnologias e/ou ferramentas adotadas para a implementação foram selecionadas a partir da análise dos requisitos do projeto PJe 2.0:
- Java Enterprise Edition Platform specification (JEE): a escolha pela plataforma JEE foi um consenso dada a notória posição de destaque dessa plataforma na construção de aplicações corporativas com grande volume de acesso e necessidade de escalabilidade, de robustez, de segurança, de controle de transação e de processamento em batch, entre outras necessidades. Além disso, a plataforma JEE traz um conjunto expressivo de APIs que aumentam a produtividade da construção do software, encapsulam parte da complexidade inerente às funções que as APIs implementam, promovem a definição de padrões de desenvolvimento, contemplando independência de servidor de aplicações.
- Apache Maven: a escolha pela ferramenta Maven foi norteada pela necessidade de modularização do software e pela adoção da plataforma JEE, como também pelo consenso, na comunidade de desenvolvedores Java, de que a ferramenta Maven é a melhor ferramenta para gerenciamento de builds e dependências na atualidade.
- Git: a escolha pela ferramenta Git (um software de controle de versões de código-fonte) se deu pela complexidade do ambiente de desenvolvimento do software PJe no qual é desejável que várias equipes, em diferentes localidades (Tribunais de Justiça), estejam trabalhando, paralelamente, no desenvolvimento de diferentes módulos do software PJe e, também, na manutenção dos módulos já implementados.
- JBoss Enterprise Application Platform (JBoss): a escolha pelo servidor de aplicações Red Hat JBoss é justificada pela reconhecida posição de destaque, entre a comunidade de desenvolvedores JEE, deste servidor de aplicação que oferece a completa implementação das APIs da plataforma JEE. Além disso, a versão do JBoss denominada EAP (Enterprise Application Platform), em particular, foi a escolhida porque permite a contratação do serviço de suporte da empresa Red Hat. É importante destacar que, o uso do servidor de aplicações JBoss é adotado como o servidor de aplicação padrão do projeto e, para o uso de outro servidor de aplicação diferente, explicaremos em outra seção deste documento as diretrizes de configuração que precisarão ser feitas.
- PostgreSQL: a escolha do SGBD PostgreSQL deve-se pelo fato deste SGBD ser de uso gratuito e open source (ou seja, é um software cujo código-fonte está aberto para comunidade), implementar o padrão objeto-relacional com a robustez desejada pelo projeto. Além de, ser um SGBD amplamente utilizado pela comunidade de desenvolvedores de diversas linguagens de programação. É importante destacar que, o uso do SGBD PostgreSQL é adotado como o SGBD padrão do projeto e, para o uso de outro SGBD diferente, explicaremos em outra seção deste documento as diretrizes de configuração que precisarão ser feitas.
Definição da arquitetura de referência
Esta seção e subseções descrevem os detalhes da arquitetura de referência definida para o desenvolvimento do software PJe 2.0 e suas evoluções futuras. Dentre os detalhes, podemos destacar: a forma como a arquitetura foi estruturada/organizada e as responsabilidades da arquitetura. Vale informar que, a arquitetura também poderá ser reutilizada para outros projetos de domínio diferente do PJe.
A arquitetura é formada por 5 camadas lógicas relacionadas entre si e, além das camadas, é possível agruparmos logicamente elementos da arquitetura por meio de módulos.
Explicaremos a arquitetura por meio de visões gráficas arquiteturais, são elas:
1. A primeira visão é exibida na Figura 1 e a denominamos de Visão Geral das Camadas da Arquitetura.
TODO: desenhar Figura 1 conforme Rascunho 1 e incluir aqui
Figura 1. Visão Geral das Camadas da Arquitetura
Figura 1. Visão Geral das Camadas da Arquitetura
Conforme pode ser visto na Figura 1, há 5 camadas lógicas e cada camada representa uma associação de elementos que atendem a um conjunto bem definido de responsabilidades dentro do contexto do software. Vejamos a definição de cada uma dessas camadas:
- Camada de Apresentação: encapsula toda a lógica de interação com usuários, desde a exibição de informações, passando pela captura de dados informados pelos usuários, até o reconhecimento de ações realizadas nas janelas gráficas.
- Camada de APIs: encapsula o acesso aos módulos do software. Cada módulo é responsável por um ou mais serviços ofertados pelo software.
- Camada de Negócio: encapsula toda a lógica do domínio de negócio do software, ou seja, as regras de manipulação dos dados e informações controlados pelo software.
- Camada de Domínio: encapsula as representações dos dados e informações inerentes ao domínio de negócio do software, em outras palavras, esta camada é responsável pela realização do mapeamento objeto-relacional.
- Camada de Serviços: encapsula toda a lógica de acesso ao software, servindo como porta de entrada de requisições dos diversos clientes do software, por exemplo: requisições de usuários por meio de janelas gráficas; requisições de outros softwares por meio de webservices.
2. A segunda visão é exibida na Figura 2 e a denominamos de Visão Modular da Arquitetura.
Figura 2. Visão Modular da Arquitetura
Conforme apresentamos na Figura 2...
Um módulo é
Boas práticas
Problemas conhecidos e preocupações
Instruções de montagem do ambiente de desenvolvimento
Referências bibliográficas
1. World Wide Web Consortium (W3C) disponível em http://www.w3.org/, último acesso em 26/05/2015. 2. Maven – Welcome to Apache Maven disponível em https://maven.apache.org/, último acesso em 28/05/2015.
