2.6.2 - Documento de Arquitetura¶

1. Definição das camadas¶

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.
O padrão de nomenclatura para as classes Java é br.gov.mpog.dti.<xxx>.apresentacao, respectivamente para a apresentação web e para os serviços, onde <XXX> é o nome do módulo.
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 AngularJS. O código javascript integrará com o servidor enviando e recebendo mensagens no formato json via serviços REST providos pelo Spring MVC.

1.1.1 Tecnologias Utilizadas¶

• AngularJS 1.6.3
• Ui Router 1.0
• Spring MVC 4.2
• Spring Security 4.0.3.RELEASE

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.
O padrão de nomenclatura é br.gov.mpog.dti.<xxx>.servico, onde <xxx> é o nome do módulo.

1.2.1 Tecnologias Utilizadas¶

• Spring Boot 1.3.2.RELEASE

1.3 Camada de Domínio¶

Contém informações sobre o domínio do negócio. Mantém os objetos de negócio.
O padrão de nomenclatura é br.gov.mpog.dti.<XXX>.modelo, onde <XXX> é o nome do projeto.

1.3.1 Tecnologias Utilizadas¶

• POJO
• Hibernate Validation 5.1
• JPA

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.
O padrão de nomenclatura é br.gov.mpog.dti.<XXX>.infraestrutura, onde <XXX> é o nome do projeto.

1.4.1 Tecnologias Utilizadas¶

• Hibernate 4.3
• Hibernate Envers 4.3
• Spring Data 4.2

2. Requisitos Arquiteturais¶

Esta seção é um checklist cujo resultado final são os requisitos arquiteturais da aplicação.
Deve ser respondida, de forma sucinta, ao longo da execução do projeto. As questões que não se aplicam devem ser respondidas com “N/A”.

2.1 Desempenho¶

• Qual a velocidade de resposta esperada da aplicação?
• Há diferentes classes de operações para as quais os usuários têm expectativas diferentes?
• Existe janela batch? O que executa nela?
• Há batches com restrições de desempenho específicas? Em caso afirmativo, especifique.
• Há dados com alta taxa de acesso para leitura/gravação que podem ser mantidos em memória nas diferentes camadas da arquitetura?
• Quais são os gargalos de desempenho esperados?
  • CPU
  • Memória no cliente, no servidor ou em nós intermediários
  • Espaço em disco em cada nó
  • Links de comunicação
  • Banco de dados (acesso, pesquisa, joins complexos)
  • Interação com outros sistemas internos
  • Interação com sistemas externos

2.2 Escalabilidade¶

• Qual o máximo de usuários esperado realizando que tipos de operações?
• Qual a perspectiva de crescimento em quais tabelas críticas sem impactar o desempenho da aplicação?
• Há possibilidade de saturar um link de comunicação que não pode ter a capacidade/velocidade aumentada?
• Que dimensões podem ser escaladas? (por exemplo: CPU, memória, servidores, distribuição geográfica etc.)
• Qual a principal estratégia para escalar a aplicação: ampliando os nós de uma topologia fixa ou adicionando novos nós?

2.3 Disponibilidade¶

• Qual o percentual de disponibilidade requerido?
• A disponibilidade varia ao longo do dia, da semana, do mês ou do ano ou em função de localização?
• Há interrupções controladas planejadas? Qual a programação?

2.4 Confiabilidade¶

• Há componentes com confiabilidade menor que a requerida para o sistema?
• Que estratégias estão em curso para tornar mais confiáveis os recursos menos confiáveis?
• Qual o tempo médio de falha por severidade?
• Como a confiabilidade pode ser avaliada antes da implantação?

2.5 Segurança¶

• Quais operações precisam ser seguras?
  • Todas as operações não públicas (Públicas são as operações acessadas pela aplicação Portão do Cidadão), menos de login deverão ser protegidas
• Como os usuários serão administrados?
  • Através do SSO Acessos
• Como serão dadas permissões aos usuários para acessarem operações seguras?
  • Através do Acessos, que será a solução corporativo de gestão de acesso e de autorização do MPOG
• Quais os diferentes níveis de segurança e como mapear:
  • Segurança por operação
    • Serão protegidas utilizando as anotações padrão Java (JSR-250)
  • Segurança por tipo de objeto
    • Serão protegidas utilizando as anotações padrão Java (JSR-250)
  • Segurança por instância de objeto
    • Os objetos poderão ser filtrados por dados negociais, por exemplo dependendo da UF do usuário logado por exemplo. Esse filtro será aplicado às queries efetuadas no banco de dados.

2.6 Manutenibilidade¶

• Há facilidade de contratação de pessoas com as habilidades técnicas requeridas e de atraí-las para a área?
• Que tipos de mudanças são esperados na primeira rodada de manutenção? Quais são suas prioridades relativas?
• Que tipo de testes de regressão é necessário para garantir que as manutenções não degradem as funcionalidades existentes?

2.7 Flexibilidade¶

• Há algum comportamento do sistema que precisa ser alterado regularmente sem necessidade de alteração na aplicação?
  • Isso pode estar contido em uma base de dados?
  • Há regras que podem ser aplicadas em tempo de execução por um motor de regras?
  • Há funções executadas por meio de scripts do usuário? Caso afirmativo, como será realizada a garantia de qualidade desses?

2.8 Usabilidade¶

• Qual o perfil dos usuários da aplicação?
• Há operações que devem ser realizadas o mais rapidamente possível, por meio da redução de ações do usuário?
• Há operações que requerem apresentações específicas para ajudar o usuário a realizá-las?
• Como é resolvido o equilíbrio entre integridade de dados e a habilidade de cancelar uma operação em andamento?
• Que tipos de treinamentos são esperados?
• Há algum sistema de ajuda incluído?

2.9 Configuração¶

• Quais os parâmetros cuja configuração é necessária nas máquinas que hospedarão a solução?

2.10 Personalização¶

• Que aspectos do sistema podem ser personalizados pelo usuário?
• Como o usuário realiza essa configuração?
• Qual a estratégia para definir os padrões?

2.11 Portabilidade¶

• Portabilidade de dados entre a aplicação e outras soluções?
  • Não
• Portabilidade entre diferentes versões de um único banco de dados?
  • Não
• Portabilidade para um banco de dados de outro fabricante? Caso afirmativo, qual/quais e em que situação?
  • Não
• Portabilidade de browser? Quais marcas e versões?
  • Não
• Portabilidade de sistema operacional?
  • Sim

2.12 Conformidade com padrões¶

• Quais padrões legais se aplicam?
• Quais padrões técnicos se aplicam?
• Quais outros padrões se aplicam?
• Quais padrões de desenvolvimento se aplicam?
  • Nomenclatura de bases de dados
  • Padrões arquiteturais internos
  • Padrões de linguagem e de codificação
  • Padrões de testes e de revisões
  • Padrões de apresentação
  • Modelos ou metodologias de ciclo de vida

2.13 Internacionalização¶

• Quais os idiomas suportados?
  • Português do Brasil (pt_BR)
• Em que ordem?
• Tipo de codificação de caracteres? Simples ou multi?
  • Todos os arquivos serão salvos utilizando a codificação UTF-8.

2.14 Interoperabilidade¶

• Com que soluções a aplicação interagirá imediatamente?
  • O Acessos, sistema de Single Sign On; Sistema e-Sic via WebService
• Que outras soluções estão previstas?
  • Não há por enquanto
• Com que categorias de aplicações internas e externas pode ser necessário interagir?
  • Através de webservices REST
• Que funcionalidades da aplicação serão expostas como um serviço?
  • Não tem nenhuma funcionalidade a disponibilizar como serviço ainda
• Que funcionalidades da aplicação precisam ser expostas como web service ou via um portal?
  • Não tem nenhuma funcionalidade a disponibilizar como serviço ainda
  • Digrama de Implantação com as Integrações conhecidas do Módulo SGC.
    • 

2.15 Auditoria e rastreabilidade¶

• Existe a necessidade de auditar ou rastrear as ações dos usuários na aplicação?
  • Sim
• Quais as ações e informações serão registradas?
  • Situação anterior da tupla do banco de dados (Usando Hibernate Envers para auditoria), IP, Usuário Logado e tipo da operação
• Por quanto tempo, no mínimo, o registro de quem fez o que deve ser mantido?
  • Indeterminado

2.16 Transações¶

• Quais as fronteiras mais importantes das transações de banco de dados e aplicação?
  • A abertura e fechamento das transações (commit/roollback) se dará na camada de aplicação com anotações @Transactional
• O padrão otimista de locking é apropriado ou é necessário algo mais complexo em alguma ou todas as situações?
  • Não há necessidade com os requisitos atuais

2.17 Administração¶

• Que tipos de intervenções “ao vivo” são requeridos?
• Há necessidade de realizar configuração remota da aplicação?
• Há consoles de administração que serão usadas para gerenciar a aplicação?

3. Visão de Implementação¶

Nesta seção descreva sucintamente a estrutura geral do modelo de implementação, a divisão do software em camadas e subsistemas no modelo de implementação e todos os componentes significativos do ponto de vista da arquitetura.

3.1 Pacotes de Design Significativos do Ponto de Vista da Arquitetura¶

Para cada pacote significativo, inclua uma subseção com o respectivo nome, uma breve descrição e um diagrama com todos os pacotes e classes significativos nele contidos.
Para cada classe significativa no pacote, inclua o respectivo nome, uma breve descrição e, opcionalmente, uma descrição de algumas das suas principais responsabilidades, operações e atributos.

3.2 Componentes¶

Lista dos subsistemas localizados em cada camada e o diagrama de componentes.

4. Diagrama do Banco de Dados¶