Exibir código-fonte para PJe2:Documento da Arquitetura de Referência


= '''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, boas práticas de programação que devem ser utilizadas no desenvolvimento do software, entre outros assuntos relevantes. 

Recomendamos que a leitura deste documento seja feita na ordem sequencial em que são apresentados os tópicos do sumário/índice do documento.

A metodologia de desenvolvimento do software definida será tratada em [[PJe2:Metodologia_de_desenvolvimento | 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.

{| {{table border=1}}
| align="center" style="background:#f0f0f0;"|'''Termo'''
| align="center" style="background:#f0f0f0;"|'''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.
|-
| ''CSS'' || Acrônimo para a expressão inglesa ''Cascading Style Sheets''; é uma linguagem de folhas de estilo utilizada para definir a apresentação de documentos escritos em uma linguagem de marcação, como ''HTML'' ou ''XML''. 
|-
| ''DAO'' || Acrônimo para a expressão inglesa ''Data Access Object''; é um padrão para persistência de dados que permite separar regras de negócio das regras de acesso ao SGBD.
|-
| ''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 ''Java Enterprise Edition'' (''JEE'').
|-
| ''Javascript'' || Linguagem de programação para navegadores web; é baseada em scripts, orientada a objetos e com sintaxe similar à linguagem de programação C.
|-
| 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'' || De acordo com a W3C, ''webservice'' é um sistema de software responsável por proporcionar a interação entre duas máquinas através de uma rede de computadores.
|-
| ''XHTML'' || Acrônimo para a expressão inglesa ''eXtensible Hypertext Markup Language'';  é uma reformulação da linguagem de marcação ''HTML'', baseada em XML. Combina as ''tags'' de marcação da linguagem ''HTML'' com regras da linguagem ''XML''.
|-
| ''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.
|-
| ''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.
|}

== '''Restrições da arquitetura''' ==

<font color=red> TODO: verificar se existem restrições impostas que foram obedecidas e digitá-las nesta seção. </font>

== '''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.
<br>
;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 (<font color=red> [TODO: colocar link para o plano, se for desejado]</font>). 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.
<br>
;Experiências prévias.
: Foram consideradas as seguintes experiências:
* Experiência prévia da equipe de arquitetos servidores do Poder Judiciário. Alguns dos arquitetos com experiência no software PJe 1.0.
* Foram analisadas arquiteturas de referência das seguintes instituições: TCU, STF, SERPRO, TJRO e TJPE.
* Estudos diversos foram realizados pela equipe de arquitetos na primeira ''Sprint'' do projeto.
<br>
;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 ''API''s que aumentam a produtividade da construção do software, encapsulam parte da complexidade inerente às funções que as ''API''s 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 EAP''): 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 ''API''s 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.
<br>

= '''Definição da arquitetura de referência''' =
Esta seção descrevemos a arquitetura de referência definida para o desenvolvimento do software PJe 2.0 e suas evoluções futuras. A sigla batizada para arquitetura de referência é '''ArqJus'''. Dentre os assuntos que serão tratados, podemos destacar: a forma como a arquitetura foi estruturada/organizada e as responsabilidades da arquitetura. É importante informarmos que, '''ArqJus''' também poderá ser reutilizada para outros projetos cujo domínio do negócio seja diferente do PJe.

'''ArqJus''' é 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"'''. Vejamos o significado desses dois conceitos importantes:
*'''Camada''': representa uma associação abstrata de elementos que atendem a um conjunto bem definido de responsabilidades dentro do contexto do software.
*'''Módulo''': são blocos de implementação (código-fonte, arquivos de configuração, arquivos de propriedades, arquivos de ''templates'' (ou modelos) de janelas gráficas, scripts de banco de dados, etc.) responsáveis por um ou mais serviços ofertados pelo software. Um módulo é classificado por um dos seguintes tipos assim definidos:
**'''Tipo 1''': é um módulo que representa abstrações do modelo de negócio inerente ao software, em outras palavras, um '''módulo do tipo 1''' agrupa classes Java que representam conceitos do domínio do negócio. Também o chamaremos de '''módulo de negócio'''. Um módulo do tipo 1 '''não pode conhecer''' um outro módulo do tipo 1, caso contrário, será violado a independência entre esses módulos. Todo módulo tipo 1 deve ter: uma única ''interface'' Java, local e/ou remota e a classe Java que implementa os serviços ofertados por essa ''interface''.
**'''Tipo 2''': é um módulo que representa abstrações da própria '''ArqJus''', em outras palavras, um '''módulo do tipo 2''' agrupa classes Java e um conjunto de arquivos que fazem parte da arquitetura. Exemplo desse conjunto de arquivos: ''XHTML'', ''CSS'', ''Javascript'', ''HTML'', ''XML'', etc.  Um módulo do tipo 2 '''pode conhecer''' um outro módulo do tipo 2.
Concretamente, cada módulo tornar-se-á um projeto específico gerenciado pelo aplicativo ''Maven''. Dessa forma, garantiremos o isolamento dos módulos do software. Além de ser gerenciado pelo ''Maven'', cada módulo é construído separadamente, com repositório próprio no aplicativo ''Git'' e com versionamento exclusivo, permitindo o isolamento do código-fonte e a especialização das equipes de desenvolvimento, contribuindo com o objetivo de facilitar a manutenção do software e minimizar os impactos de efeitos colaterais das diversas manutenções do software.
<br><br>
Explicaremos nas próximas subseções mais detalhes da '''ArqJus''' por meio de visões gráficas arquiteturais.
<br>
== '''Visão geral das camadas da arquitetura''' ==
A primeira visão da '''ArqJus''' é exibida na Figura 1 e a denominamos de '''Visão Geral das Camadas da Arquitetura'''. 
<br>
<font color=red> TODO: desenhar Figura 1 conforme Rascunho 1 e incluir aqui. Deve-se explicar 'qual camada conhece qual camada' na Figura 1</font>
<br>
'''Figura 1. Visão Geral das Camadas da Arquitetura.'''
[[imagem:Visao_Camadas_da_Arquitetura.jpg | '''Figura 1. Visão Geral das Camadas da Arquitetura.''']]

<br><br>
Conforme pode ser visto na Figura 1, há 5 '''camadas''' lógicas e a definição de cada uma dessas camadas é apresentada seguir:
#'''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 por meio das janelas gráficas do software, até o reconhecimento de ações realizadas nessas janelas gráficas.
#'''Camada de ''API''s''': encapsula o acesso aos módulos ofertados pelo software. Normalmente, nesta camada terão módulos do tipo 2.
#'''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''.
<font color=red> TODO: citar as tecnologias adotadas na ArqJus predominantes em cada uma das camadas</font>
<br>

== '''Visão modular da arquitetura''' ==
A segunda visão da '''ArqJus''' é exibida na Figura 2 e a denominamos de '''Visão Modular da Arquitetura'''. 
<br><br>
'''Figura 2. Visão Modular da Arquitetura.'''
[[imagem:Visao_Modular_da_Arquitetura.jpg | '''Figura 2. Visão Modular da Arquitetura.'''| 1200px]]
<br>
Na Figura 2 apresentamos uma visão da '''ArqJus''' contemplando os conceitos já explicados: camadas e módulos. Nessa visão também demonstramos um exemplo de uso da arquitetura. Observando a Figura 2 no sentido 'de cima para baixo', explicaremos, a seguir, a estrutura da '''ArqJus''':
# Um módulo tipo 2 que denominamos de '''Módulo WEB'''. Esse módulo no aplicativo ''Maven'' é denominado '''pje-web'''. Nesse módulo inclui-se:
## Uma pasta denominada '''recursos''' que contém um conjunto de arquivos. Exemplos desses arquivos: ''XHTML'', ''CSS'', ''Javascript'', imagens, entre outros.
## Um pacote denominado '''controlador''' que contém classes Java que realizam o trabalho definido pela Camada de Apresentação do software. Somente as classes desse pacote têm acesso ao conjunto de arquivos da pasta '''recursos'''. Também poderemos chamá-las de classes controladoras (ou ''backbeans''). Essas classes também têm acesso às ''interfaces'' Java do '''Módulo Orquestrador'''. Também podem ter acesso às ''interfaces'' Java de módulos do tipo 1 (módulo de negócio) que existirem no software, por exemplo: na Figura 2, a classe Java 'MinhaEntidadeAOperacaoCtrl' acessa o módulo 'Meu negócio A' por meio de sua ''interface'' Java.<br>
# Um módulo tipo 2 que denominamos de '''Módulo Orquestrador'''. Esse módulo no aplicativo ''Maven'' é denominado '''pje-service'''. Nesse módulo inclui-se:
## Um pacote denominado '''api''' que contém ''interfaces'' Java que representam o trabalho definido pela Camada de ''API''s'' do software.
## Um pacote denominado '''impl''' que contém classes Java que implementam o trabalho definido pela Camada de Serviços do software. Em outras palavras, uma classe Java do pacote '''impl''' implementa os serviços ofertados por uma ''interface'' Java do pacote '''api''' correspondente. <br>Uma classe do pacote '''impl''' não, necessariamente, implementa por completo um determinado serviço o qual ela é responsável. Logo, é possível que essa classe obtenha o resultado de 'partes desse serviço' por meio de um outro módulo da '''ArqJus'''. Um exemplo: na Figura 2 temos um ou mais serviços da classe 'MeuServicoSrv' fazendo uso de serviços disponíveis nas ''interfaces'' Java 'IMeuNegocioASrv' do módulo 'Meu negócio A' e 'IMeuNegocioBSrv' do módulo 'Meu negócio B'.<br>
# 'Meu Negócio A' é exemplo de como pode ser estruturado um módulo tipo 1 no software. Nesse exemplo, inclui-se:
## Uma ''interface'' Java denominada 'IMeuNegocioASrv'; essa ''interface'' representa o trabalho definido pela Camada de ''API''s'' do módulo 'Meu Negócio A'.
## Uma classe Java denominada 'MeuNegocioASrv'; essa classe implementa os serviços ofertados pela Camada de Serviços do módulo 'Meu Negócio A'. Em outras palavras, a classe 'MeuNegocioASrv' implementa os serviços ofertados pela ''interface'' Java 'IMeuNegocioASrv'.
## Uma ou mais classes Java que implementam o trabalho definido pela Camada de Negócio do módulo 'Meu Negócio A'. Exemplos: na Figura 2 temos as classes 'MinhaEntidadeAManager' e 'MinhaEntidadeCManager' e as suas classes ''DAO'' correspondentes. <br>
# 'Meu Negócio B' é exemplo de como pode ser estruturado um módulo tipo 1 no software. Nesse exemplo, inclui-se:
## Uma ''interface'' Java denominada 'IMeuNegocioBSrv'; essa ''interface'' representa o trabalho definido pela Camada de ''API''s'' do módulo 'Meu Negócio B'.
## Uma classe Java denominada 'MeuNegocioBSrv'; essa classe implementa os serviços ofertados pela Camada de Serviços do módulo 'Meu Negócio B'. Em outras palavras, a classe 'MeuNegocioBSrv' implementa os serviços ofertados pela ''interface'' Java 'IMeuNegocioBSrv'.
## Uma ou mais classes Java que implementam o trabalho definido pela Camada de Negócio do módulo 'Meu Negócio B'. Exemplos: na Figura 2 temos as classes 'MinhaEntidadeBManager' e sua classe ''DAO'' correspondente. <br>
# Um módulo tipo 2 que denominamos de '''Módulo Modelo'''. Esse módulo no aplicativo ''Maven'' é denominado '''pje-modelo'''. Nesse módulo inclui-se:
## Um pacote denominado '''modelo''' que contém classes Java que realizam o trabalho definido pela Camada de Domínio do software. Por exemplo: na Figura 2 temos as classes 'MinhaEntidadeA', 'MinhaEntidadeB' e 'MinhaEntidadeC'. Todos os módulos do software (tanto módulo do tipo quanto do tipo 2) têm acesso às classes do pacote '''modelo'''.

É importante destacar que:
* O módulo de negócio 'Meu Negócio A' '''não conhece''' o módulo de negócio 'Meu Negócio B', logo, está consistente com a definição de módulo tipo 1.
* Uma classe Java pertencente à Camada de Negócio pode acessar uma outra classe da Camada de Negócio desde que, ambas classes, pertençam ao mesmo módulo de negócio.
* Classes Java da Camada de Negócio podem ser acessadas por classes Java da Camada de Serviços somente dentro de um mesmo módulo de negócio.

== '''Organização dos projetos no ''Maven''''' ==
Nesta subseção, apresentamos a organização dos projetos no aplicativo ''Maven'', consolidando os módulos citados no decorrer da explicação da Figura 2 e outros módulos necessários para estruturação da '''ArqJus'''.

* '''pje-pom''': projeto que contém as dependências que são comuns entre todos os demais projetos. Não deve conter código-fonte, apenas as configurações dessas dependências. O aplicativo ''Maven'' exige a presença do arquivo ''POM'' (''Project Object Model'').
* '''pje-modelo''': projeto que contém todas as entidades de domínio do negócio mapeadas de acordo com o padrão ''JPA'' (''Java Persistence API'').
* '''pje-comum''': projeto que contém todas as classes Java utilitárias do software. Também é classificado como um módulo tipo 2. Exemplos de classes Java desse projeto: classes que implementam os registros de auditoria das operações do software (também chamado de registro de ''log''), classes que implementam o controle de acesso, o tratamento de exceções, entre outras classes responsáveis pela infraestrutura do software.
* '''pje-service''': projeto que contém as classes do '''Módulo Orquestrador''' das funcionalidades que envolvam mais de um módulo de negócio.
* '''pje-web''': projeto que contém todo o código-fonte associado à Camada de Apresentação, exemplos: classes controladoras (também conhecidas por ''back-beans''), arquivos ''HTML'', ''XHTML'', ''CSS'' e scripts ''JavaScript''.

A nomenclatura de cada projeto específico no aplicativo ''Maven'' obedece o padrão '''pje<modulo>''', em 'modulo' deve conter o nome do módulo correspondente.

Os projetos no ''Maven'' serão empacotados em arquivos com extensão ''jar'' (''Java ARchive''), com exceção do projeto "pje-web", que será empacotado em um arquivo com extensão ''war'' (''Web application ARchive''). 

Para cada módulo do software, independente do tipo do módulo, será preciso criar três arquivos com extensão ''jar'', vejamos:
# pje-modulo-X.Y.Z.jar: este arquivo contém todas as classes Java do módulo e será utilizado no momento da instalação (''deploy'') do módulo. 
# pje-modulo-X.Y.Z-api.jar: este arquivo contém apenas as ''interfaces'' Java do respectivo módulo e será utilizado como dependência na implementação dos módulos "pje-web" e "pje-service". Lembrando que, os módulos "pje-web" e "pje-service" somente terão acesso à Camada  de ''APIs'' do módulo em questão. 
# pje-modulo-X.Y.Z-sources.jar: este arquivo contém o código-fonte do módulo e será utilizado para fins de depuração do código-fonte (ou ''debug'').

= '''Padrões, regras e boas práticas''' =
Esta seção tem o objetivo de apresentar os padrões estabelecidos, as regras definidas e algumas boas práticas de programação para construção do software sob a consonância com os requisitos da '''ArqJus'''. As explicações serão divididas nas subseções desta seção.

== '''Padrões de nomenclatura e codificação''' ==
* Padrões de nomenclatura para '''classes Java''':
** Classes do Módulo Web (também chamaremos de "controladores/controlador(a)" ou de ''backbeans''): <Entidade><operação>Ctrl.java
** ''Interfaces'' Java do Módulo Orquestrador (também chamaremos de "orquestradores/orquestrador(a)"): I<Serviço>Srv.java
** Implementações dos orquestradores: <Serviço>Srv.java
** ''Interfaces'' Java dos módulos: I<Módulo>Srv.java
** Implementações dos módulos: <Módulo>Srv.java
** Classes de negócio (também chamaremos de "''managers''/''manager''"): <Entidade>Manager.java
** Classes de acesso aos dados: <Entidade>DAO.java
** Entidades: <Entidade>.java
<br>
* Padrões de nomenclatura para '''pacotes Java''':
** br.jus.cnj.pje.web.controlador: todos os controladores do software devem pertencer a este pacote.
** br.jus.cnj.pje.service.api: todas as ''interfaces'' Java dos orquestradores do software devem pertencer a este pacote.
** br.jus.cnj.pje.service.impl: todas as implementações das ''interfaces'' Java dos orquestradores devem pertencer a este pacote.
** br.jus.cnj.pje.<negócio>.api: a ''interface'' Java do módulo deve pertencer a este pacote. Entende-se por <negócio> o nome do módulo de negócio.
** br.jus.cnj.pje.<negócio>.impl: a implementação da ''interface'' Java do módulo deve pertencer a este pacote. Entende-se por <negócio> o nome do módulo de negócio.
** br.jus.cnj.pje.<negócio>.manager: todas as classes de negócio (''managers'') do módulo de negócio devem pertencer a este pacote. Entende-se por <negócio> o nome do módulo de negócio.
** br.jus.cnj.pje.<negócio>.dao: todas as classes de acesso aos dados inerentes ao módulo de negócio devem pertencer a este pacote. Entende-se por <negócio> o nome do módulo de negócio.
** br.jus.cnj.pje.modelo: todas as classes das entidades mapeadas no padrão ''JPA'' devem pertencer a este pacote.
<br>
* Padrões de nomenclatura para '''arquivos ''XHTML''''':
** <entidade><operação>.xhtml: entende-se por <entidade> o nome da principal da entidade manipulada pela janela gráfica (ou tela), e por <operação> a principal manipulação que se deseja realizar a partir desta tela (visualizar, excluir, alterar, desativar, cadastrar, etc). 
<br>
É importante ressaltar que, os padrões apresentados no decorrer da explicação da Figura 2 também foram considerados.

Além dos padrões definidos nesta subseção, recomendamos a adoção do padrão de codificação Java, disponível no endereço http://www.oracle.com/technetwork/java/codeconvtoc-136057.html.

== '''Regras definidas''' ==

'''<u>Sobre o relacionamento entre classes:</u>'''

É permitido na '''ArqJus''' o relacionamento entre as diversas classes do software distribuídas nos módulos e nas camadas lógicas, logo, esse relacionamento deve obedecer as seguintes regras:
# Um orquestrador deve ser criado sempre que houver a necessidade de uma operação no Módulo Controlador que envolva mais de um módulo de negócio.
# As classes dos controladores apenas terão acesso às ''interfaces'' Java dos serviços ofertados pelos orquestradores e módulos de negócio.
# Para cada tela (ou arquivo ''XHTML'') deve haver um controlador específico e único.
# Todas as operações que um módulo de negócio disponibilizará devem ser expostas através de sua Camada de ''API'' (ou ''interface'' Java).
# Os módulos de negócio não podem, em hipótese alguma, acessar funcionalidades e/ou classes de outros módulos de negócio. Somente poderão acessar classes e funcionalidades disponíveis nos projetos '''pje-modelo''' e '''pje-comum'''.
# As classes managers de um módulo só podem ser acessadas pela classe que implementa a ''interface'' Java desse módulo em questão, ou pelos demais ''managers'' do mesmo módulo.
# As regras de negócio devem ser implementadas exclusivamente nas classes ''managers'' correspondentes.
# Para cada classe ''manager'' deve haver uma, e apenas uma, classe no padrão ''DAO''.
# Cada classe ''DAO'' só deve ser acessada pela sua classe ''manager'' correspondente.
# Validações dos atributos que caracterizam uma classe ''manager'' (por exemplo: não nulo, não vazio, restrição de tamanho, restrição de valores) devem ser realizadas na própria classe ''manager'', por meio das anotações disponíveis na ''API Bean Validation'' da especificação ''JEE''.

== '''Boas práticas''' ==
<font color=red> [TODO: citar e explicar as boas práticas recomendadas para construção do software.]</font>


=== '''Problemas conhecidos e preocupações''' ===
<font color=red> [TODO: citar e explicar, caso tenham: problemas conhecidos e como resolvê-los, lições aprendidas, preocupações futuras]</font>

= '''Instruções de montagem do ambiente de desenvolvimento''' =

Nesta seção, apresentamos os roteiros/instruções para instalação e configuração do ambiente de desenvolvimento. As explicações serão divididas nas subseções desta seção, e, recomendamos que a leitura seja obedecida na ordem em que serão apresentadas as subseções.

== '''Roteiro para instalação e configuração do ''Eclipse''''' ==

* Realizar o ''download'' da ferramenta ''Eclipse Platform Runtime Binary'' (''latest release'', 32 ou 64 bits, dependendo do SO (Sistema Operacional) utilizado) disponível no endereço ''http://download.eclipse.org/eclipse/downloads/''. Após o ''download'', realizar a instalação. Esta versão é a mais básica e simples do ''Eclipse'', logo, será preciso realizar também a instalação do ''marketplace'' no ''Eclipse''.
* Para instalar o ''marketplace'', é necessário abrir o ''Eclipse'' e acessar o menu "''Help > Install New Software...''". Na janela aberta (vide Figura 3), selecionar "''All Available Sites''" na lista "''Work with''". Em seguida, digitar "''marketplace''" no campo texto "''type filter text''" e, depois, selecionar a opção do ''marketplace'' e prosseguir com a instalação.
<br>
'''Figura 3. Instalar ''marketplace''.'''<br>
[[imagem:Install_AvaliableSoftware.jpg | '''Figura 3. Instalar ''marketplace''.'''| 700px]]
<br>
<br>
* Após instalar o "''marketplace''" deve ser realizada a instalação do ''JBoss Tools'' no ''Eclipse''. Com o ''Eclipse'' aberto, acessar o menu "''Help > Eclipse Marketplace...''". Na janela aberta (vide Figura 4), na aba "''Search''", digitar "''jboss tools''" no campo "''Find''" e pressionar a tecla ''Enter''. Em seguida, selecionar a versão mais recente do ''JBoss Tools'' compatível com a versão do ''Eclipse'' utilizada.
<br>
'''Figura 4. Instalar ''JBoss Tools''.'''<br>
[[imagem:Install_JbossTools.jpg | '''Figura 4. Instalar ''JBoss Tools''.'''| 700px]]
<br>
<br>
* Configurar no ''Eclipse'' a codificação do projeto para utilizar o padrão "''UTF8''": acessar o menu "''Window > Preferences''" e escolher a opção "''UTF8''" para o campo "''Text file encoding''".
<br>
<br>

== '''Roteiro para instalação e configuração do ''PostgreSQL''''' == 
<font color=red>TODO:<br>
- Explicar roteiro para instalar e configurar PostgreSQL. <br>
</font>


=== '''Diretrizes de configuração caso use um SGBD diferente do ''PostgreSQL''''' ===
<font color=red>TODO:<br>
- Incluir as diretrizes de configuração que precisarão ser feitas caso use um SGBD diferente do PostgreSQL. <br>
</font>



== '''Roteiro para instalação e configuração do ''JBoss EAP''''' == 

* Realizar o ''download'' do ''JBoss EAP'' versão 6.4 disponível no endereço ''http://www.jboss.org/products/eap/download/''. A utilização do ''JDK'' (''Java Development Kit'') é obrigatória na versão 1.6 (''JDK6'') ou superior. Após o ''download'', realizar a instalação. 
* Realizar o ''download'' da versão 4 do ''driver JDBC'' do ''PostgreSQL'' (''JDBC4 Postgresql Driver'') disponível no endereço ''https://jdbc.postgresql.org/download.html''. Essa versão 4 é compatível com a versão do ''JDK6''.
* Configurar o ''driver JDBC'' do ''PostgreSQL'' como módulo do ''JBoss'', obedecendo os passos a seguir:
** Passo 1: Criar a pasta "''JBOSS_HOME/modules/system/layers/base/org/postgresql/main''".
** Passo 2: Criar o arquivo "''module.xml''" na pasta criada no passo 1; nesse arquivo deve conter o nome correto do arquivo com extensão ''jar'' do ''driver JDBC'' do ''PostgreSQL''. Veja, a seguir, como é o conteúdo do arquivo "''module.xml''":
<code> 
   <?xml version="1.0" encoding="UTF‐8"?>
   <module xmlns="urn:jboss:module:1.1" name="org.postgresql">
       <resources>
           <resource‐root path="postgresql‐9.3‐1101.jdbc4.jar"/>
       </resources>
       <dependencies>
           <module name="javax.api"/>
           <module name="javax.transaction.api"/>
       </dependencies>
   </module>
</code> 
** Passo 3: Copiar o arquivo com extensão ''jar'' do ''driver JDBC'' do ''PostgreSQL'' para a mesma pasta do arquivo "''module.xml''" criada no passo 1.
** Passo 4: Incluir no arquivo "''JBOSS_HOME/standalone/configuration/standalone.xml''", dentro da ''tag'' "<''datasources''>" contendo o código:
<code> 
   <drivers>
       <driver name="postgresql‐jdbc4" module="org.postgresql"/>
   </drivers>
</code>
* Configurar o datasouce da aplicação:
** Incluir dentro da ''tag'' "<''datasources''>" no arquivo "''JBOSS_HOME/standalone/configuration/standalone.xml''" o código:
<code>

<datasource jta="true" jndi‐name="java:jboss/datasources/pjeDS" pool‐name="pjeDS" enabled="true" use‐java‐context="true" useccm=" true">
  <connection‐url>jdbc:postgresql://hostname:5432/bdname</connection‐url>
  <driver‐class>org.postgresql.Driver</driver‐class>
  <driver>postgresql‐jdbc4</driver>
  <pool>
    <min‐pool‐size>2</min‐pool‐size>
    <max‐pool‐size>20</max‐pool‐size>  
    <prefill>true</prefill>
  </pool>
  <security>
    <user‐name>usuario</user‐name>
    <password>senha</password>
  </security>
  <validation>
    <check‐valid‐connection‐sql>SELECT 1</check‐valid‐connection‐sql>
    <validate‐on‐match>false</validate‐on‐match>
    <background‐validation>false</background‐validation>
    <use‐fast‐fail>false</use‐fast‐fail>
  </validation>
</datasource>

</code>

Lembre-se de informar corretamente o nome do servidor do SGBD, o nome do esquema do banco de dados, o usuário e a senha para acesso ao banco de dados.
* Essas configurações consideram que o ''JBoss'' será utilizado no modo "''standalone''". Caso o modo escolhido seja "''domain''", é necessário que as modificações no arquivo "''standalone.xml''" sejam também realizadas no arquivo "''domain.xml''" do diretório "''JBOSS_HOME/domain/configuration/''".


=== '''Diretrizes de configuração caso use um servidor de aplicação diferente do ''JBoss EAP''''' ===
<font color=red>TODO
<br> - Explicar as diretrizes de configuração que precisarão ser feitas caso use um servidor de aplicação diferente do JBoss.
</font>


<font color=red>TODO:<br>
- Incluir novas seções para explicar as diretrizes extras de configuração que surgirem. <br>
</font>

= '''Referências bibliográficas''' =

<!-- 
<div class="references-small">
    <references/>
</div> 
-->

 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.
 3. Code Conventions disponível em http://www.oracle.com/technetwork/java/codeconvtoc-136057.html, último acesso em 02/06/2015. 

[[Category:PJe2]]