Arquitetura de Referência - JAVA¶
DRAFT >>
- Índice
- Arquitetura de Referência - JAVA
- 1. Introdução
- 2. Objetivo do documento
- 3. Público Alvo
- 4. Termos, abreviações e convenções adotadas
- 5. Restrições da arquitetura
- 6. Justificativas arquiteturais
- 7. Tecnologias adotadas
- 8. Definição da arquitetura de referência
- 9. Visão de Implementação
- 10. Visão de Deployment da Arquitetura
- 11. Arquitetura de Automação de Teste e QA
- 12. Padrões, regras e boas práticas
- 13.Roteiro para instalação e configuração ...
1. Introdução¶
Apresentamos neste documento a arquitetura de referência para o desenvolvimento do aplicações que utilizam a linguagem de programação Java. As seções e subseções do documento explicarão os detalhes pertinentes da arquitetura.
2. Objetivo do documento¶
O objetivo principal é especificar a arquitetura de software de referência a ser utilizada como padrão para o desenvolvimento aplicações Java. 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.
3. Público Alvo¶
O documento tem como público alvo principalmente arquitetos de software visando orientá-los da criação de artefatos para o desenvolvimento e evoluções. Além da criação de artefatos, o arquiteto de software deverá utilizar este documento como referência para instruir os profissionais que atuarão como desenvolvedores especializados nas tecnologias requeridas para esta arquitetura, como por exemplo: desenvolvedores Java/JEE.
Este documento também contém informações úteis a líderes de projetos, gerentes de projeto, analistas de negócios/requisitos, analistas de teste, testadores, administradores de dados, administradores de infraestrutura e, possivelmente, outros perfis.
4. Termos, abreviações e convenções adotadas¶
Apresentamos nesta seção uma tabela contendo os termos, abreviações e convenções adotadas no documento da arquitetura. A leitura prévia desta seção é fortemente recomendada para compreensão das demais seções.
Termo | Descrição |
Acessos | |
Angular | |
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 a 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. |
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. |
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. |
Deploy | Instalar/implantar uma aplicação de software em um servidor de aplicações. |
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. |
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. |
JSON | |
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. |
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. |
Single Sign On | |
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. |
SpringMVC | |
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. |
5. Restrições da arquitetura¶
TODO:
6. Justificativas arquiteturais¶
TODO:
7. Tecnologias adotadas¶
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.
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.
8. Definição da arquitetura de referência¶
8.1 Visão geral das camadas da arquitetura¶
8.1.1 Camada de Apresentação¶
Controla a interação entre usuário e aplicação. Contém componentes responsáveis pela lógica de apresentação da aplicação e tem as responsabilidades de capturar dados, apresentar os resultados e controlar a navegação.
No mesmo nível estão os serviços expostos pela aplicação para interagir com outras aplicações.
A parte de apresentação no que diz respeito aos componentes de interface e interação direta com o usuário serão efetuados na camada do cliente (navegador) com o Angular 5. O código javascript integrará com o servidor enviando e recebendo mensagens no formato JSON via serviços REST providos pelo Spring MVC.
Tecnologias Utilizadas¶
- Angular 5
- Ui Router 1.0
- Spring MVC 4.2
- Spring Security 4.0.3.RELEASE
8.1.2 Camada de Aplicação¶
Coordena a atividade da aplicação. Ela não contém regras de negócio nem mantém o estado dos objetos de negócio, mas pode manter o estado de uma tarefa em progresso.
Tecnologias Utilizadas¶
- Spring Boot 2.0
8.1.3 Camada de Domínio¶
Contém informações sobre o domínio do negócio. Mantém os objetos de negócio.
Tecnologias Utilizadas¶
- POJO
- Hibernate Validation 5.1
- JPA
8.1.4 Camada de Infraestrutura¶
Atua como uma biblioteca de suporte para as demais camadas, provendo comunicação entre elas, implementando persistência para os objetos de negócio, fornecendo bibliotecas para a camada de interface com o usuário etc.
Tecnologias Utilizadas¶
- Hibernate 4.3
- Hibernate Envers 4.3
- Spring Data 4.2
9. Visão de Implementação¶
10. Visão de Deployment da Arquitetura¶
Esta subseção tem o objetivo de apresentar os principais componentes envolvidos no processo de deploy do software.
11. Arquitetura de Automação de Teste e QA¶
Tecnologias utilizadas¶
- Junit
- Arquillian
- Selenium WebDriver
- PhatomJS
- Jasmine
- Karma
- Jacoco
- Serenity
- Protactor
- Cucumber
12. Padrões, regras e boas práticas¶
12.1 Padrões de nomenclatura e codificação¶
O padrão de nomenclatura para as classes Java da camada de apresentação é br.gov.mpog.dti.<xxx>.apresentacao, respectivamente para a apresentação web e para os serviços, onde <XXX> é o nome do módulo.
O padrão de nomenclatura para a camada de serviço é br.gov.mpog.dti.<xxx>.servico, onde <xxx> é o nome do módulo.
O padrão de nomenclatura para a camada de domínio é br.gov.mpog.dti.<XXX>.modelo, onde <XXX> é o nome do projeto.
O padrão de nomenclatura para a camada de infraestrutura é br.gov.mpog.dti.<XXX>.infraestrutura, onde <XXX> é o nome do projeto.
12.2 Regras¶
12.3 Boas práticas¶
13.Roteiro para instalação e configuração ...¶
Referências bibliográficas
Atualizado por Redmine Admin há aproximadamente 6 anos · 1 revisões