Mudanças entre as edições de "PJe2:Documento da Arquitetura de Referência"

De PJe
Ir para: navegação, pesquisa
(Restrições da arquitetura)
(Justificativas arquiteturais)
Linha 86: Linha 86:
  
 
== '''Justificativas arquiteturais''' ==  
 
== '''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.
+
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.
 
<br>
 
<br>
 
;Requisitos do projeto PJe 2.0.
 
;Requisitos do projeto PJe 2.0.

Edição das 10h25min de 28 de maio de 2015

Conteúdo

Introdução

Apresentamos neste documento a arquitetura de referência do software Processo Judicial Eletrônico - PJe 2.0. 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
Applet Applet é um software aplicativo que é executado no contexto de outro programa.
Browser Navegador web. Ex.: Firefox, Internet Explorer.
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 Internet.
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 Internet.
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.
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 Internet.
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 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. 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 (JEE): a escolha pela plataforma JEE se deu pela notória posição de destaque desta plataforma na construção de aplicações corporativas, com grande volume de acesso e necessidade de escalabilidade, robustez, segurança, controle de transação, processamento em batch, entre outras. Além disso, a plataforma JEE traz um conjunto expressivo de APIs que aumentam a produtividade da construção do sistema e encapsulam parte da complexidade inerente às funções que elas implementam.
  • Apache Maven: a escolha pelo Maven foi norteada pela necessidade de modularização do sistema e pela adoção da plataforma JEE, como também pelo consenso, na comunidade de desenvolvedores Java, de que o Maven é a melhor ferramenta para gerenciamento de builds e dependências na atualidade.
  • Git: a escolha pelo Git, enquanto sistema de controle de versão, se deu pela complexidade do ambiente de desenvolvimento do sistema PJe, onde se espera que várias equipes, em diferentes localidades (tribunais), estejam trabalhando, paralelamente, no desenvolvimento de diferentes módulos do sistema e, também, na manutenção dos módulos já implementados.
  • JBoss Enterprise Application Platform: a escolha pelo RedHat 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 EAP (enterprise), em particular, foi a escolhida porque permite a contratação do serviço de suporte da RedHat.
  • PostgreSQL: a escolha do PostgreSQL, como SGBD, se deve a este ser o sistema de gerenciamento de banco de dados open source, gratuito e objeto-relacional mais robusto disponível, além de ser amplamente utilizado pela comunidade de desenvolvedores de diversas linguagens mundo afora.


Arquitetura estruturada em camadas.
A escolha da arquitetura estruturada em camadas foi adotada por facilitar a interoperabilidade dos componentes de software, a distribuição dos módulos do software e a possibilidade de possuir diferentes interfaces de acesso ao software. Essa escolha também foi incentivada pelo uso do padrão arquitetural MVC.

Definição da arquitetura de referência

Esta seção descreve o modelo da arquitetura de referência definida para o software PJe 2.0 e suas evoluções futuras. A arquitetura é estruturada em camadas e essas camadas são fragmentadas em módulos. Cada camada da arquitetura equivale a um dos particionamentos lógicos dos diversos aspectos tratados pelo software e possuem responsabilidades distintas. Toda camada é logicamente separada da outra e (???????) não está estritamente acoplada com a camada adjacente (???????). A Figura 1 apresenta as camadas da arquitetura e as tecnologias utilizadas em cada uma delas. As responsabilidades de cada camada serão explicadas nas subseções subsequentes e as tecnologias definidas para uso em cada camada serão abordadas em outra seção deste documento.


TODO: colocar aqui o desenho da arq. com camadas e módulos



Camadas e módulos

A arquitetura de referência é estruturada nas seguintes camadas:

Camada de Apresentação
Esta camada é responsável por encapsular toda a lógica de apresentação exigida para servir aos clientes que acessam o software. Em resumo, essa lógica funciona assim: interceptar as requisições dos clientes, fornecer um único início de sessão HTTP, conduzir o gerenciamento dessa sessão, controlar o acesso aos serviços de negócio disponíveis, construir as respostas e as entregas aos clientes.
Camada de Serviços
XXXX
Camada de Negócio
yyyy


Visões da arquitetura

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.
Ferramentas pessoais
Espaços nominais

Variantes
Ações
Navegação
Informações Gerais
Aplicativos PJe
Manuais
Suporte
Ferramentas