Arquitetura de Referência de Software e Recursos de Java

Arquitetura de Referência de Software
e Recursos de Java do MCTI
Versão 1.3
MCTI
Histórico de Revisão
Versão
1.0
1.1
Data
25/02/2013
20/05/2013
1.2
15/06/2013
1.3
30/09/2013
Descrição
Criação do Documento
Alterações sugeridas pela Fábrica de
Software e Equipe do MCTI
Inclusão da Arquitetura de Recursos do
MCTI
Evoluções sugeridas pelo MCTI
Autor
Yuri Marx Pereira Gomes
Yuri Marx Pereira Gomes
Yuri Marx Pereira Gomes
Yuri Marx Pereira Gomes
Sumário
1 JUSTIFICATIVA
6
2 PROPÓSITO
6
3 ESCOPO
6
4 MODELO ARQUITETURAL 4+1
6
4.1 DESCRIÇÃO
6
5 VISÃO DO NEGÓCIO
7
5.1 DESCRIÇÃO
5.2 DOCUMENTAÇÃO DA VISÃO
7
7
6 VISÃO LÓGICA
7
6.1 DESCRIÇÃO
6.2 DOCUMENTAÇÃO DA VISÃO
6.3 DIAGRAMA DA VISÃO LÓGICA DOS SISTEMAS
6.4 VIEW - INTERFACE VISUAL
6.4.1 DESCRIÇÃO
6.4.2 RESPONSABILIDADES
6.5 CONTROL - CLASSE DE CONTROLE
6.5.1 DESCRIÇÃO
6.5.2 RESPONSABILIDADES
6.6 MODEL – CLASSE DE NEGÓCIO
6.6.1 DESCRIÇÃO
6.6.2 RESPONSABILIDADES
6.7 MODEL – CLASSE DE ENTIDADE
6.7.1 DESCRIÇÃO
6.7.2 RESPONSABILIDADES
6.8 EXEMPLO DE USO DA VISÃO LÓGICA DA ARQUITETURA DE REFERÊNCIA
6.9 TECNOLOGIAS DA VISÃO LÓGICA DA ARQUITETURA DE REFERÊNCIA
6.10 PRODUTOS DA VISÃO LÓGICA DA ARQUITETURA DE REFERÊNCIA
6.11 TECNOLOGIAS E PRODUTOS PARA RELATÓRIOS
6.12 PADRÕES DE PROJETO PARA A VISÃO LÓGICA
6.12.1 PADRÕES BÁSICOS
6.12.2 PADRÕES DE PROJETO PARA CLASSES JAVA DO GOF (GANG OF FOUR)
7
7
8
8
8
8
8
8
9
9
9
9
10
10
10
10
12
13
13
13
13
13
6.12.3 PADRÕES DE PROJETO JEE DO JAVA BLUEPRINTS
15
7 VISÃO FÍSICA
15
7.1 DESCRIÇÃO
7.2 DOCUMENTAÇÃO DA VISÃO
7.3 DIAGRAMA DAS CAMADAS FÍSICAS
7.4 CAMADA CLIENTE
7.4.1 DESCRIÇÃO
7.4.2 RESPONSABILIDADES
7.4.3 DIAGRAMA DA CAMADA CLIENTE
7.5 CAMADA MIDDLEWARE
7.5.1 DESCRIÇÃO
7.5.2 RESPONSABILIDADES
7.5.3 DIAGRAMA DA CAMADA MIDDLEWARE
7.6 CAMADA DE RECURSOS
7.6.1 DESCRIÇÃO
7.6.2 RESPONSABILIDADES
7.6.3 DIAGRAMA DA CAMADA DE RECURSOS
7.7 CAMADA OPERACIONAL
7.7.1 DESCRIÇÃO
7.7.2 RESPONSABILIDADES
7.7.3 DIAGRAMA DA CAMADA OPERACIONAL
7.8 CAMADA DE HARDWARE
7.8.1 DESCRIÇÃO
7.8.2 RESPONSABILIDADES
7.8.3 DIAGRAMA DA CAMADA DE HARDWARE
7.9 EXEMPLO DE USO DAS CAMADAS DA VISÃO LÓGICA DA ARQUITETURA DE REFERÊNCIA
7.10 PRODUTOS VISÃO FÍSICA DA ARQUITETURA DE REFERÊNCIA
15
15
16
16
16
16
16
17
17
17
17
17
17
17
17
18
18
18
18
18
18
19
19
19
20
8 VISÃO DE DESENVOLVIMENTO
20
8.1
8.2
8.3
8.4
8.5
8.6
8.7
8.8
8.9
8.10
20
21
21
21
22
22
23
23
23
24
DESCRIÇÃO
DOCUMENTAÇÃO DA VISÃO
ESTRUTURA DE PROJETOS E ARQUIVOS DA APLICAÇÃO JAVA
PROJETO WEB DA APLICAÇÃO JAVA
CONTEÚDO NÃO JAVA DO PROJETO WEB
PROJETO DE CLASSES E COMPONENTES DA CAMADA DE CONTROLE
PROJETO DE CLASSES E COMPONENTES DA CAMADA DE MODELO
PROJETO DE CLASSES UTILITÁRIAS
PROCESSO DE IMPLANTAÇÃO DE VERSÕES – DEPLOY
PARAMETRIZAÇÃO E CONFIGURAÇÃO DOS SISTEMAS
9 BARRAMENTO DE SERVIÇOS: COMO A ARQUITETURA JAVA SE ENCAIXA NA INICIATIVA SOA DO
MCTI NO PROJETO AQUARIUS
25
9.1
9.2
9.3
9.4
9.5
9.6
9.7
DEFINIÇÃO DE SOA (SERVICE ORIENTED ARCHITECTURE)
UNIDADE BÁSICA DO SOA E OS TIPOS DE SERVIÇO
ABORDAGEM DE DESENVOLVIMENTO DE SERVIÇOS
TECNOLOGIAS PARA O DESENVOLVIMENTO DE SERVIÇOS
BARRAMENTO DE INTEGRAÇÃO
LOCAL DE ARMAZENAMENTO DOS SERVIÇOS
ENTREGA DE SERVIÇOS NA INTRANET E INTERNET
25
25
26
26
26
26
27
10 TESTES DE SISTEMA
27
11 REQUISITOS NÃO FUNCIONAIS
27
11.1
11.2
11.3
11.4
DESCRIÇÃO
CLASSIFICAÇÃO DOS REQUISITOS NÃO FUNCIONAIS
REQUISITOS NÃO FUNCIONAIS NATIVOS DA ARQUITETURA DE REFERÊNCIA
REQUISITOS NÃO FUNCIONAIS DOS SISTEMAS JAVA DA ARQUITETURA
27
28
29
30
12 ARQUITETURA DE RECURSOS DE HOMOLOGAÇÃO E PRODUÇÃO
30
12.1 AMBIENTE DE PRODUÇÃO
12.2 AMBIENTE DE HOMOLOGAÇÃO
30
31
13 REFERÊNCIAS
32
1 Justificativa
É objetivo do MCTI padronizar o desenvolvimento dos seus sistemas corporativos web,
especialmente sistemas de médio e grande tamanho funcional, visando alcançar produtividade,
simplicidade, interoperabilidade, reuso, portabilidade em uma arquitetura aberta. Para isto, a exemplo
de outras instituições da Administração Pública Federal, adotou a linguagem de programação Java em
substituição à linguagem de programação PHP, seguindo a tendência mundial de desenvolver sistemas
corporativos em Java.
Hoje o Java é a linguagem de programação orientada a objetos mais utilizada do mundo (fonte:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html) . Além disso, conta com um
conjunto de APIs (Application Programming Interface) e frameworks (bibliotecas de uso específico para
abstrair atividades comuns como interação com o banco de dados ou segurança) em grande número,
tornando o desenvolvimento muito mais simples do que em outras linguagens.
2 Propósito
O propósito deste documento é fornecer uma visão geral da arquitetura dos sistemas
desenvolvidos com Java Web corporativos de médio e grande tamanho funcional no MCTI,
especialmente os sistemas corporativos. Para isto são definidas e descritas visões arquiteturais que
detalham diferentes aspectos dos sistemas Java construídos. O intuito é capturar e definir decisões
arquiteturais significantes dos sistemas Java e definir um modelo arquitetural para a arquitetura de cada
projeto Java do MCTI.
3 Escopo
Todos os sistemas construídos com Java devem ter seus documentos de arquitetura
referenciados e restritos a este documento. Sendo assim, neste documento são definidas as visões
arquiteturais, requisitos não funcionais e de qualidade, empacotamento e padrões de projeto que estes
sistemas em Java devem seguir.
Este documento não é a descrição de arquitetura de um sistema em específico, mas o guia para
isto, portanto, ele apenas direciona, restringe e assenta as definições arquiteturais que cada projeto
Java deve realizar. Assim, não encontraremos nele a visão 4+1 concretamente definida, mas requisitará
que o documento de arquitetura de um sistema Java o faça. Também não definirá quais são todos os
padrões de projeto a utilizar, mas indicará os padrões disponíveis para uso e estabelecerá padrões
obrigatórios a seguir para cada visão, pois são fundamentais para o sucesso dos projetos.
4 Modelo Arquitetural 4+1
4.1 Descrição
Esta Arquitetura de Referência utiliza o Modelo Arquitetural 4+1 de Philippe Kruchten para
definir a Arquitetura Java do MCTI. Este modelo “descreve a arquitetura de sistemas de software,
baseado no uso de visões múltiplas e concorrentes”. Estas visões são usadas para descrever o sistema
sob o ponto de vista de diferentes stakeholders, como usuários finais, arquitetos, desenvolvedores e
gerentes de projeto. As 4 visões do modelo são lógica, desenvolvimento, processo e física, que juntas
atendem à visão de negócio representada em casos de uso ou modelos de processos de negócio.
5 Visão do Negócio
5.1 Descrição
Esta visão representa a interação entre usuários e sistema e define as necessidades de uso e
funcionalidades-macro a serem atendidas.
5.2 Documentação da Visão
Todos os documentos de arquitetura de sistemas Java deverão possuir esta visão. Esta seção
deverá listar:

Casos de uso ou Cenários do Modelo de Casos de Uso arquiteturalmente relevantes; ou;

Cenários e Mapa de Processos de Negócio arquiteturalmente relevantes; ou;

Especificações Funcionais de Serviços Candidatos arquiteturalmente relevantes.
Para ser considerado arquiteturalmente relevante, uma descrição do negócio deve exercitar
vários aspectos arquiteturais do sistema e ter abrangência e grande relevância funcional.
6 Visão Lógica
6.1 Descrição
A visão lógica descreve por meio de uso de diagramas de classe, sequencia, e modelo TO-BE de
processos de negócio o projeto lógico do sistema para atender às necessidades do sistema
documentados em documentos de visão, casos de uso, mapas de processo e em quaisquer dos artefatos
da visão de negócio.
6.2 Documentação da Visão
Esta visão deve ser documentada utilizando-se diagramas de classe e sequencia, bem como modelos
entidade e relacionamento e/ou modelos de processo de negócio em nível analítico ou de automação. A
seguir o diagrama de classes básico para uma funcionalidade a ser representada na visão lógica.
6.3 Diagrama da Visão Lógica dos Sistemas
Figura 1 - Padrão de Projeto MVC (Model - View - Controller)
6.4 View - Interface Visual
6.4.1
Descrição
A interface visual (tela) é o elemento da Arquitetura responsável por interagir diretamente com
o usuário final por meio de telas compostas de campos de informação e controles de ação que
executam as operações de negócio sob as informações existentes nos campos de informação conforme
as necessidades do usuário. Existem duas opções de interface visual:


6.4.2




Interfaces Visuais de Negócio: estas interfaces visuais possuem funcionalidades de inclusão,
exclusão, alteração e consulta de dados de dados e informações de negócio.
Interfaces Visuais de Relatório: estas interfaces visuais possuem funcionalidades de
renderização de dados e de informações na forma de relatórios.
Responsabilidades
Receber requisições do usuário.
Realizar validações, formatações e lógica de execução de interface visual.
Delegar para a camada de interface a requisição do usuário.
Renderizar e apresentar no formato de interfaces visuais ou relatórios as respostas da aplicação
ao usuário.
6.5 Control - Classe de Controle
6.5.1
Descrição
A classe de controle é o elemento da Arquitetura que realiza a ligação entre Interface Visual e os
elementos de modelo da aplicação. Também podem determinar a lógica de navegação entre as
interfaces visuais e regras de validação do negócio no lado servidor da aplicação. Sem a classe de
controle, as telas não conseguiriam disparar as operações de negócio e também não conseguiriam
visualizar as informações apresentadas nos campos de informação. Existem dois tipos de classes de
controle:


6.5.2




Classe de Controle de Negócio: intermedia as operações e necessidades de informação para
Interfaces visuais de negócio.
Classe de Controle de Relatório: intermedia as necessidades de informação para interfaces
visuais de relatório.
Responsabilidades
Intermediar requisições e respostas entre as camadas de view e de model.
Receber as requisições da interface visual com os valores digitados na tela para repassar para a
camada de negócio.
Realizar validações de campos e de regras de navegação e de interface visual no lado servidor.
Expor para a interface visual os valores retornados da camada de negócio.
6.6 Model – Classe de Negócio
6.6.1
Descrição
A classe de negócio é o elemento da Arquitetura que contém toda a lógica de negócio para
atender aos requisitos de negócio. Nela estarão as operações de inclusão, alteração, exclusão, consulta,
processamento, cálculos e validações das informações de negócio representadas pelas classes de
entidade. Costumo definir que para cada especificação de caso de uso é definida uma classe de negócio
para atender a este caso de uso. Existem 03 tipos de classes de negócio:



6.6.2



Classe de Negócio síncrona sem estado: encapsula todo o comportamento de negócio de um
caso de uso ou de um conjunto de requisitos funcionais ou necessidades sem guardar as
informações processadas entre uma ou mais chamadas às operações da classe. O consumidor
da classe de negócio sempre que realiza uma chamada à classe de negócio, espera pela resposta
no retorno.
Classe de Negócio síncrona com estado: encapsula todo o comportamento de negócio de um
caso de uso ou de um conjunto de requisitos funcionais ou necessidades armazenando em
memória as informações processadas entre uma ou mais chamadas às operações da classe.
Muito útil para encapsular funcionalidades como carrinho de compras de websites de compras
virtuais, por exemplo. O consumidor da classe de negócio sempre que realiza uma chamada à
classe de negócio, espera pela resposta no retorno.
Classe de Negócio assíncrona: encapsula todo o comportamento de negócio de um caso de uso
ou de um conjunto de requisitos funcionais ou necessidades sem guardar as informações
processadas entre uma ou mais chamadas às operações da classe. O consumidor da classe de
negócio sempre que realiza uma chamada à classe de negócio, não espera pela resposta no
retorno, portanto, é a opção mais performática para o consumidor da classe. Cenários onde se
pode entrar em uma fila de processamento são ideais para este tipo de classe.
Responsabilidades
Executar todo o comportamento de negócio de acordo com as necessidades do usuário.
Executar as regras de negócio definidas.
Executar os comandos de criar, atualizar, consultar, excluir e processar informações de negócio
encapsuladas nas classes de entidade.
6.7 Model – Classe de Entidade
6.7.1
Descrição
Este elemento da Arquitetura é responsável por representar a estrutura de dados do negócio na
forma de classes, por isto é conhecida como classe de entidade. Exemplo, para representar os campos
de informação de um cadastro de pessoas, pode ser criada a classe de entidade Pessoa.
As classes de entidade são visíveis a todas as demais classes da Arquitetura, visto que passa pela
missão de das mesmas ou renderizar as informações de negócio, ou processar as mesmas na camada
web ou na camada de negócio.
A classe de entidade é uma classe Java convencional, uma classe POJO (Plain Old Java Object)
com a lista de campos de informação e operações de get e set para obter ou atribuir valores.
6.7.2



Responsabilidades
Abstrair do desenvolvedor o modelo relacional, de forma que as classes de negócio sejam
totalmente orientadas a objeto.
Mapear o modelo relacional de banco de dados em classes de entidade.
Executar os comandos SQL correspondentes aos comandos orientados a objeto.
6.8 Exemplo de uso da Visão Lógica da Arquitetura de Referência
Vamos tomar como exemplo um caso de uso chamado “Cadastrar Fornecedores”, este caso de
uso possui os seguintes cenários:




Cadastrar Fornecedor
Excluir Fornecedor
Consultar Fornecedor
Imprimir Lista de Fornecedores
O caso de uso também prevê os seguintes campos de informação de fornecedor:







CNPJ
Razão Social
Nome Fantasia
Segmento
Telefone
Endereço
Produtos Comercializados
Dados os cenários e os campos de informação, teríamos o seguinte diagrama de classes da
Arquitetura para atender o caso de uso:
Figura 2 - Exemplo de Projeto de Classes MVC
As classes foram desenhadas desta forma com o seguinte propósito:






CadastroFornecedorUI: é uma classe de visão que irá renderizar a tela HTML para o usuário final
cadastrar, excluir, consultar e imprimir a lista de fornecedores.
CadastroFornecedorControl: é a classe utilizada para receber as requisições disparadas pelo
usuário nos botões de gravar, excluir, consultar ou imprimir e convertê-las em chamadas para as
classes de modelo.
FornecedorService: encapsula todo o negócio referente a Fornecedor nas aplicações, de forma
que quaisquer operações de negócio, como gravar, excluir ou consultar estejam concentradas
em apenas um ponto.
Fornecedor: classe Java que representa os campos de negócio da entidade Fornecedor.
Endereco: é a classe que encapsula dados de endereço nas aplicações, não somente de
endereço de fornecedor, mas também de clientes ou de quaisquer outras entidades que
precisem ter informações de endereço. Como o Fornecedor pode ter apenas 1 endereço, o
relacionamento entre Fornecedor e Endereço é 1 para 1.
Produto: é a classe que encapsula dados de produto nas aplicações, não somente de produto de
fornecedor, mas também de produtos de um pedido ou de uma nota fiscal ou de quaisquer
outras entidades que precisem ter informações de produto. Um Fornecedor pode ter 1 ou mais
produtos, sendo então o relacionamento entre Fornecedor e Produto é 1 para muitos (0..*).
Percebam como é fácil representar toda complexidade de um caso de uso ou especificação
funcional em poucas classes e de forma bem clara. Perceba também que cada tipo de classe tem um
conjunto de responsabilidades bem definido e especializado, facilitando a manutenção, o reuso das
classes e a facilidade no entendimento da solução.
6.9 Tecnologias da Visão Lógica da Arquitetura de Referência
Para cada uma das camadas e elementos da Arquitetura temos tecnologias definidas por JSRs
(Java Specification Request) para atender de forma padronizada, oficial e adequada as necessidades de
desenvolvimento produtivo e fácil. São as tecnologias:
JSR
JSR-314 – JSF
2.0
JSR-220 – EJB
3.0
JSR-317 – JPA
2.0
Elemento da
Arquitetura
Interface Visual e Classe
de Controle
Classe de Negócio
Classe de Modelo
Descrição
Desenvolvimento MVC orientado a componentes de
interfaces visuais em Java, utilizando tags
Desenvolvimento de Classes com serviços de negócio
expostos localmente e/ou remotamente para consumo
por classes cliente
Mapeamento Objeto-Relacional para persistência e
consulta de informações de negócio originárias de bancos
de dados SQL
Estas tecnologias especificaram funcionalidades que os frameworks dos fabricantes devem
possuir para atender aos elementos da Arquitetura, conforme o diagrama a seguir:
JSF 2 - Managed Bean
<<control>>
Classe de Controle
EJB 3
Stateless Session Bean
Stateful Session Bean
Message Driven Bean
<<view>>
Interface Visual
JPA 2 - Classe de Entidade POJO
JSF 2 - Anotações para configuração
<<model>>
Classe de Entidade
<<model>>
Classe de Negócio
Figura 3 - Tecnologias para cada Camada MVC
Este diagrama de classes apresenta como cada tecnologia atende a cada elemento da
Arquitetura, segue a explicação para este diagrama:

Interface Visual – JSF 2.0: a tecnologia de JSF define que os frameworks de desenvolvimento
web devem armazenar em arquivo XML a descrição da aparência, dos campos, dos controles, de
validações e chamadas de ações nas telas. Toda a aparência e estrutura da tela está especificada
em XML padronizado que pode ser estendido com tags específicas de cada implementação de
JSF.



Classe de Controle – JSF 2.0: a tecnologia de JSF define uma classe Java chamada ManagedBean
como uma classe configurada a anotação @ManagedBean existente para lidar com requisições
oriundas das interfaces visuais.
Classe de Negócio – EJB 3.0: a tecnologia EJB define o SessionBean como classe de negócio sem
estado e síncrona, StatefulSessionBean como classe de negócio com estado e
MessageDrivenBean como classe de negócio assíncrona.
Classe de Entidade – JPA 2.0: define classes Java POJO para mapear como será a persistência de
tabelas de banco de dados em classes de entidade que possuem propriedades correspondentes
em suas classes.
6.10 Produtos da Visão Lógica da Arquitetura de Referência
Os JSRs não definem produtos concretos, apenas definem o conjunto de funcionalidades e
regras que os mesmos devem seguir. Assim é necessário ao Arquiteto escolher o produto que
implementa cada uma das especificações. A arquitetura define os seguintes produtos:
JSR
JSR-314 – JSF 2.0
JSR-220 – EJB 3.0
JSR-317 – JPA 2.0
Produto de Implementação
Oracle ADF 11g Release 2.0 ou superior
Container EJB 3.0 ou superior do servidor de aplicação escolhido pela arquitetura
Oracle Toplink Essentials 11g ou superior
6.11 Tecnologias e Produtos para relatórios
Para os relatórios das aplicações são utilizados dois produtos:

IDE de desenvolvimento de relatórios IReport 5.0 ou superior.

Jasperreports 5.0 para renderização em tempo de execução dos relatórios criados no IReport.

Jasperreports Server Community Edition 5.0 ou superior para servidor/repositório central de
relatórios.
6.12 Padrões de Projeto para a Visão Lógica
6.12.1 Padrões Básicos
O padrão de projeto básico para descrever e definir a visão lógica, como se viu acima, é o MVC,
não sendo necessário à primeira vista utilizar GoF ou outros padrões JEE já documentados, no entanto, a
Arquitetura está aberta ao se uso, caso se faça necessário, mas limitados aos padrões a seguir.
6.12.2 Padrões de Projeto para Classes Java do GoF (Gang of Four)
Sempre que necessário o Arquiteto poderá utilizar os seguintes padrões de projeto do GoF,
observadas as implementações já existentes no Java e Java EE:
Padrão de Projeto
Abstract Factory
Tipo
Criacional
Descrição
Criação de famílias de objetos relacionados ou dependentes
por meio de uma única interface e sem que a classe concreta
Builder
Prototype
Singleton
Factory Method
Adapter
Composite
Flyweight
Bridge
Estrutural
Decorator
Proxy
Facade
Chain of
Responsibility
Iterator
State
Command
Mediator
Strategy
Interpreter
Memento
Template Method
Comportamento
seja especificada
Permite a separação da construção de um objeto complexo
da sua representação, de forma que o mesmo processo de
construção possa criar diferentes representações
Permite a criação de objetos a partir de um modelo original,
ou protótipo
Este padrão garante a existência de apenas uma instância de
uma classe
Permite as classes delegar para subclasses decidirem. O
factory method permite delegar a instanciação para as
subclasses
Este padrão é utilizado para 'adaptar' a interface de uma
classe. O Adapter permite que classes com interfaces
incompatíveis possam interagir
Utilizado para representar um objeto que é constituído pela
composição de objetos similares a ele
Apropriado quando vários objetos devem ser manipulados, e
esses não suportam dados adicionais
Utilizado quando é desejável que uma interface (abstração)
possa variar independentemente das suas implementações
Permite adicionar um comportamento a um objeto já
existente em tempo de execução
Um proxy, em sua forma mais geral, é uma classe que
funciona como uma interface para outra classe
Um façade (fachada em francês) ou facade em inglês é um
objeto que disponibiliza uma interface simplificada para uma
das funcionalidades de uma API
Representa um encadeamento de objetos receptores para o
processamento de uma série de solicitações diferentes
é um objeto que permite a um programador examinar um
container percorrendo seus itens
Usado quando o comportamento de um objeto muda,
dependendo do seu estado
Encapsular uma solicitação como um objeto, desta forma
permitindo que clientes parametrizem diferentes
solicitações, enfileirem ou façam o registro (log) de
solicitações e suportem operações que podem ser desfeitas
Desacopla e gerencia as colaborações entre um grupo de
objetos
Permite definir novas operações sem alterar as classes dos
elementos sobre os quais opera
Utilizado para representar e resolver problemas recorrentes
que possam ser expressos sob a forma de uma linguagem
formal simples
Permite armazenar o estado interno de um objeto em um
determinado momento, para que seja possível retorná-lo a
este estado, caso necessário
Auxilia na definição de um algoritmo com partes do mesmo
definidos por Método abstratos. As subclasses devem se
responsabilizar por estas partes abstratas, deste algoritmo,
que serão implementadas, possivelmente de várias formas,
Observer
Visitor
ou seja, cada subclasse irá implementar à sua necessidade e
oferecer um comportamento concreto construindo todo o
algoritmo
Um objeto que possua agregações deve permitir que seus
elementos sejam acessados sem que a sua estrutura interna
seja exposta. De uma maneira geral pode-se desejar que
estes elementos sejam percorridos em várias ordens
É uma solução para separar o algoritmo da estrutura. Uma
das vantagens desse padrão é a habilidade de adicionar
novas operações a uma estrutura já existente
6.12.3 Padrões de Projeto JEE do Java Blueprints
Os padrões de projeto JEE do Java Blueprints documentam padrões de projeto para JSF, Web
Services, EJB e JPA. Os mesmos estão documentados em:

http://www.oracle.com/technetwork/java/index-jsp-136701.html
Os padrões para J2EE não devem mais ser utilizados em hipótese alguma, sendo válido apenas
os padrões para JEE e mesmo assim excepcionalmente, visto que o padrão MVC com os recursos já
existentes nas tecnologias acima apontadas já atendem a 99% dos cenários.
7 Visão Física
7.1 Descrição
A visão física define descreve os componentes de sistemas operacionais, recursos de LDAP,
Banco de Dados e outros recursos corporativos utilizados pelos sistemas, e camadas de processamento
de negócio e dispositivos utilizados pelos usuários do sistema.
7.2 Documentação da Visão
Esta visão deve ser documentada com Diagrama de Implantação nos Documentos de Arquitetura dos
Sistemas, mas respeitando as definições a seguir.
7.3 Diagrama das Camadas Físicas
Camada Cliente
Camada Middleware
Camada de Recursos
Camada Operacional
Camada de Hardware
Figura 4 - Diagrama com o conjunto de camadas físicas da arquitetura
7.4 Camada Cliente
7.4.1
Descrição
É responsável por disponibilizar meios de acesso do usuário a aplicação. Está incluída nesta
categoria navegador web presentes em computadores e dispositivos móveis.
7.4.2


Responsabilidades
Disponibilizar hardware para permitir a interação entre usuário e sistema.
Disponibilizar software para permitir a interação entre o hardware do cliente e os comandos
enviados ao mesmo com a aplicação. Nesta categoria, temos os navegadores web, por exemplo.
7.4.3
Diagrama da Camada Cliente
PC
Dispositivo Móvel
Outros
Navegador Web
Servidores de Aplicação
Hardware Cliente
Software Cliente
Servidores Web
Middleware
Figura 5 - Diagrama dos Componentes da Camada Cliente
7.5 Camada Middleware
7.5.1
Descrição
A camada de middleware englobam produtos de servidores de aplicação, servidores web e
produtos e frameworks instalados nestes servidores para processar a lógica de negócio dos
componentes e aplicações.
7.5.2




Responsabilidades
Receber e responder as requisições da camada cliente.
Hospedar os componentes de negócio.
Fornecer frameworks e infraestrutura para os componentes de negócio.
Interagir com a camada de recursos visando integrações, persistência em banco de dados e
comunicação com recursos corporativos.
7.5.3
Diagrama da Camada Middleware
Serviços
Aplicações
Espaços de Trabalho
Componentes Corporativos
Servidor de Aplicação
Portal
Negócio
Base
Figura 6 – Diagrama dos Componentes da Camada de Middleware
7.6 Camada de Recursos
7.6.1
Descrição
A camada de recursos possui todos os recursos de apoio à operação da camada de negócio. Isto
inclui servidor de banco de dados, de LDAP, dentre outros.
7.6.2



Responsabilidades
Recebe requisições da camada de negócio e as executa.
Disponibiliza os recursos necessários ao negócio.
Persiste o processamento do negócio.
7.6.3
Diagrama da Camada de Recursos
Servidor de Aplicação
Banco de Dados
LDAP
Mensageria
Virtualização
FTP
Middleware
Email
Legados
Sistema Operacional
Recursos
Operacional
Figura 7 - Diagrama dos Componentes da Camada de Recursos
7.7 Camada Operacional
7.7.1
Descrição
A camada operacional provê os serviços de sistema operacional para todos os recursos e
produtos de middleware, veja diretamente ou via virtualização, que a estratégia preferida.
7.7.2


Responsabilidades
Virtualizar os produtos e recursos, visando melhor aproveitamento dos recursos de hardware.
Oferecer um sistema operacional para a camada de recursos e middleware.
7.7.3
Diagrama da Camada Operacional
Software de Virtualização
Sistema Operacional
Hardware
Virtualização
Sistema
Operacional
Hardware
Figura 8 - Diagrama dos Componentes da Camada Operacional
7.8 Camada de Hardware
7.8.1
Descrição
A camada de hardware oferece todos os dispositivos físicos digitais para processamento das
requisições solicitadas pelo sistema operacional.
7.8.2



Responsabilidades
Realizar o processamento das requisições dos sistemas operacionais.
Realizar o armazenamento físico das informações processadas pelo sistema operacional.
Fornecer meios físicos para troca de informações entre as camadas.
7.8.3
Diagrama da Camada de Hardware
Virtualização
Servidores
Sistema Operacional
Dispositivos de Rede
Dispositivos de Armazenamento
Figura 9 - Diagrama de Componentes da Camada de Hardware
7.9 Exemplo de uso das Camadas da Visão Lógica da Arquitetura de
Referência
Vamos tomar, por exemplo, a necessidade não funcional de alta disponibilidade, escalabilidade
e desempenho críticos. Neste caso é necessário montar as camadas físicas em cluster ativo-ativo. Veja o
diagrama de implantação:
Figura 10 - Diagrama UML de Implantação de Exemplo

A camada cliente hospeda o navegador.

Um hardware de balanceamento realiza o balanceamento de carga.

02 servidores físicos diferentes executam diferentes instâncias da aplicação.

Em cada servidor físico temos 02 servidores virtualizados.

A aplicação é instalada em 04 instâncias de servidor, possibilitando atender a maior número de
requisições e com melhor performance, pois a carga é repartida igualmente entre as instâncias.

A alta disponibilidade também é atendida, pois se um das instâncias deixa de responder, o
hardware de balanceamento não envia mais requisições para a instância off-line.

O banco de dados na camada de recursos é acessível de qualquer node.

A camada operacional é Linux e é utilizado virtualização.
7.10 Produtos Visão Física da Arquitetura de Referência
Para cada uma das camadas e elementos da Arquitetura temos produtos definidos para atender
de forma padronizada, oficial e adequada os requisitos não funcionais. São os produtos:
Produto
Navegador
Web com
suporte a
HTML 4 e
HTML 5
Servidor
Glassfish 3.1
ou superior
PostgreSQL 9.2
ou superior
CentOS 4 ou
superior
XEN
Servidores
Redundantes
Intel
Storage
Elemento da
Arquitetura
Camada Cliente
Camada de
Middleware
Camada de
Recursos
Camada
Operacional
Camada
Operacional
Camada de
Hardware
Camada de
Hardware
Modalidade
Descrição
Navegadores de
mercado e
freewares
As aplicações previstas na arquitetura são
web e acessíveis por navegadores que
renderizam HTML 4 e 5
Freeware com
versão de
suporte pago
Freeware com
versão de
suporte pago
Freeware
Servidor de aplicação que suporta JSF 1.2 e
2.0, EJB 3.0 e JPA 2.0
Produto de banco de dados da arquitetura,
suporta SQL ANSI e 99
Freeware
Sistema operacional da arquitetura para
middleware e banco de dados
Software de virtualização da Arquitetura
-
Sugestão de arquitetura de máquina
-
Sugestão de máquina para banco de dados
8 Visão de Desenvolvimento
8.1 Descrição
Esta visão ilustra o sistema do ponto de vista do programador e é voltado para a gestão de
configuração e mudanças, sendo uma visão de implementação.
8.2 Documentação da Visão
Esta visão deve ser documentada na arquitetura de sistemas Java com o diagrama de
componentes e/ou com a árvore de projetos e arquivos da aplicação, mas limitado às definições a seguir
da arquitetura de referência.
8.3 Estrutura de Projetos e Arquivos da Aplicação Java
Estrutura



Figura 11 - Projetos de uma Aplicação
da Arquitetura


Regras da Estrutura
A aplicação deve possuir o nome da sigla do sistema.
O pacote raiz deve ser br.gov.mcti.nomeaplicacao
Dentro da aplicação devemos criar os dois projetos sugeridos
pela IDE, Model e ViewController. O projeto Model irá conter
as classes de negócio e de entidade. O projeto ViewController
as classes de controle e visão.
A aplicação deve utilizar o projeto template do MCTI:
MCTITemplateApp
A aplicação deve utilizar o tema do MCTI na criação das
interfaces visuais.
8.4 Projeto Web da Aplicação Java
Estrutura de Pastas






Figura 12 - Estrutura de Pastas do Projeto Web
de uma Aplicação da Arquitetura

Regras de Formação da Estrutura de Pastas e Arquivos
A pasta raiz para páginas deve estar dentro de Web
Content e se chamar pages.
Abaixo de pages devem ficar as pastas com os nomes de
caso de uso com palavras em minúsculo e separadas por _.
Exemplo: manter_sistema
As páginas do caso de uso devem refletir os cenários do
caso de uso. Caso todos os cenários se concentrem em
uma página apenas, o nome da página será principal.
Para nomear uma página com o nome do cenário escolha o
nome do cenário ou o código do cenário com as palavras
todas em minúsculo e separadas por _.
A pasta raiz para relatórios deve estar dentro de Web
Content e se chamar reports.
Abaixo de reports devem ficar as pastas com os nomes de
caso de uso com palavras em minúsculo e separadas por _.
Exemplo: manter_sistema
Nomeie o relatório com o nome do cenário com as palavras
em minúsculo e separado por _.
8.5 Conteúdo não Java do Projeto Web
Estrutura de Pastas




Regras
Arquivos CSS customizados ficam na pasta CSS na pasta
raiz Web Content.
Os arquivos de imagem são armazenados na pasta images
na pasta raiz Web Content.
Os arquivos de JavaScript são armazenados na pasta js em
Web Content.
Demais arquivos não Java, como arquivos html são
organizados na pasta raiz Web Content, sendo permitido
criar subpastas para organizar este conteúdo.
Figura 13 - Estrutura de Pastas e Arquivos
de Arquivos não Java
8.6 Projeto de Classes e Componentes da Camada de Controle
Estrutura de Pastas
Figura 14 - Estrutura de Pastas das Classes Java
da Camada de Controle
Regras de Formação da Estrutura de Pastas e Arquivos
 O pacote raiz de todos os sistemas que seguem a
arquitetura deve ser br.gov.mcti.
 Embaixo deste pacote deve ser criado o pacote com
a sigla do sistema.view.
 Embaixo do pacote sistema.view devemos colocar o
pacote mbean. Neste pacote devemos ter uma
classe de Managed Bean para cada caso de uso. O
nome da classe deve corresponder ao nome do caso
de uso e seguir as regras padrão de nomenclatura de
classe Java com o pós-fixo Bean.
 No pacote scope deve colocar Managed Beans de
Aplicação e Sessão com o nome do escopo e
terminação Bean.
8.7 Projeto de Classes e Componentes da Camada de Modelo
Estrutura de Pastas
Regras de Formação da Estrutura de Pastas e
Arquivos
 O pacote raiz de todos os sistemas que
seguem a arquitetura deve ser br.gov.mcti.
 Embaixo deste pacote deve ser criado o
pacote com a sigla do sistema.model.
 Embaixo de model existe o pacote entity para
as classes de domínio/entidade e um pacote
service para as classes de negócio.
 As classes de entidade/domínio devem
possuir o nome do tópico de negócio ao qual
se referem e devem seguir a nomenclatura
padrão do Java sem pré ou pós-fixo.
 As classes de negócio devem possuir o nome
do tópico de negócio seguido do pós-fixo
Service. Suas interfaces local e remota devem
possuir as terminações ServiceLocal e
ServiceRemote respectivamente.
 Sempre que houver grande quantidade de
entidades e classes de negócio, é obrigatório
criar pacotes com nomes que correspondam
ao módulo do sistema dentro dos pacotes
entity e model.
Figura 15 - Estrutura de Classes da Camada de Modelo
8.8 Projeto de Classes Utilitárias
Classes utilitárias do sistema devem ser alocadas em projeto do tipo Java chamado Util,
conforme a figura a seguir:
Figura 16 - Projeto Utilitário para Aplicações da Arquitetura
8.9 Processo de Implantação de Versões – Deploy
O processo de implantação pode ocorrer de duas formas:
1) A partir da IDE de Desenvolvimento: após configurar a conexão da IDE Jdeveloper com o
servidor de aplicação, basta comandar a implantação conforme a figura a seguir:
Figura 17 - Procedimento de Implantação de Aplicações da Arquitetura
2) A partir da IDE gerar o arquivo EAR para entrega ao Administrador de Servidor de Aplicação para
implantação a partir da ferramenta de administração do servidor de Aplicação, para isto basta
comandar a geração do arquivo conforme a seguir:
Passo 01
Figura 18 - Menu de Implantação
Passo 02
Figura 19 - Tela de confirmação da implantação
Os gerentes de configuração e mudança estão autorizados a utilizar Maven, ANT e outras
ferramentas de integração contínua para automatizar a geração de versões. Uma vez que o JDeveloper e
a Arquitetura suportam a utilização de disto tudo.
8.10 Parametrização e Configuração dos Sistemas
A parametrização e configuração é preferencialmente realizada em arquivo de properties no
diretório-raiz do código-fonte, conforme a figura a seguir:
Figura 20 - Local do Arquivo de Parametrização da Aplicação
Para carregar os valores do arquivo utilize o seguinte trecho de código-fonte:
Properties prop = new Properties();
try {
//load a properties file from class path, inside static method
prop.load(App.class.getClassLoader().getResourceAsStream("config.properties");));
//get the property value and print it out
System.out.println(prop.getProperty("database"));
System.out.println(prop.getProperty("dbuser"));
System.out.println(prop.getProperty("dbpassword"));
} catch (IOException ex) {
ex.printStackTrace();
}
9 Barramento de Serviços: Como a Arquitetura Java se encaixa na
iniciativa SOA do MCTI no Projeto Aquarius
9.1 Definição de SOA (Service Oriented Architecture)
SOA é uma abordagem arquitetural corporativa que permite a criação de serviços de negócio
interoperáveis que podem facilmente ser reutilizados e compartilhados entre aplicações e empresas.
(Gartner Group).
9.2 Unidade básica do SOA e os tipos de serviço
O Serviço é a unidade básica de SOA, assim como uma classe é a unidade básica do Java. Os
serviços, fisicamente representados, são classes Java utilitárias e de negócio expostas ao mundo externo
geralmente como serviços web visando o reuso corporativo de funcionalidades de negócio
automatizadas nestes serviços.
Estes serviços podem ser classificados como:

Serviços Utilitários: são serviços agnósticos ao negócio e de grande reuso pelos serviços de
negócio para consumir funcionalidades genéricas como serviços de auditoria, segurança
corporativa, gestão documental, LDAP dentre outros serviços conhecidos como utilitários.

Serviços de Entidade: são serviços que expõem as funcionalidades de negócio da Instituição
para consumo corporativo. Frequentemente utilizam serviços utilitários para realizar atividades
complementares como gravar o log das operações ou gravar arquivos no storage.

Serviços de Tarefa: são serviços que compõem vários serviços de negócio para realizar um
cenário de negócio completo. Geralmente o BPEL e o BPM são utilizados para isto.
9.3 Abordagem de Desenvolvimento de Serviços
Existem duas abordagens básicas no desenvolvimento de serviços:

Contract First: as operações e a estrutura de dados dos serviços são desenvolvidos primeiro e
então o esqueleto da classe Java é gerada a partir do WSDL e XSDs escritos. Uma vez gerada a
classe, o desenvolvedor deve marcar a mesma com a anotação @WebService e @Stateless ou
@Stateful para que o serviço também seja um EJB.

Implementation First: as operações e a estrutura de dados do serviço são escritas em Java
utilizando as anotações de JAX-WS. Em tempo de compilação o WSDL e XSDs são gerados. Esta
segunda opção costuma ser desaconselhada pela Arquitetura SOA, mas é uma opção válida para
a arquitetura Java, principalmente para classes Java já existentes e legadas.
9.4 Tecnologias para o Desenvolvimento de Serviços
Existem basicamente duas tecnologias de desenvolvimento de serviços:

Baseado em contratos: no Java são implementados utilizando as anotações de JAX-WS e partem
da geração das classes Java a partir dos contratos (WSDL e XSDs).

REST: serviços baseados nas operações e na tecnologia da especificação HTTP como forma de
oferecer as funcionalidades. Na arquitetura Java as classes para implementar este tipo de
serviço devem ser marcadas com anotações de JAX-RS.
9.5 Barramento de Integração
Projetos de SOA geralmente também utilizam barramentos de serviço por diversos motivos. A
Arquitetura SOA do MCT que deve definir o produto os padrões de barramento de integração. No
entanto, estes produtos de barramento de integração devem suportar o consumo direto de EJBs, não se
limitando somente a WSDL e REST.
9.6 Local de Armazenamento dos Serviços
Estrutura de Pastas
Regras





Os contratos dos serviços são armazenados na pasta raiz
WSDL.
A estrutura de dados dos serviços são armazenados na
pasta schemas.
Podem ser criadas subpastas para organizar
funcionalmente os serviços.
A implementação dos serviços está no próprio código Java
que já possui seu empacotamento definido neste
documento.
É interessante que uma vez implantada a aplicação, os
serviços expostos sejam virtualizados em barramentos de
serviço.
Figura 21 - Local para os Serviços Web
9.7 Entrega de Serviços na Intranet e Internet
A Arquitetura SOA deve definir se serviços devem ou não ser entregues na Internet ou Intranet.
A tecnologia utilizada para cada tipo de serviço também é definida na Arquitetura SOA, mas geralmente
serviços de Intranet são serviços JAX-WS e serviços de Internet JAX-RS (REST).
10 Testes de Sistema
Os testes automatizados na arquitetura utilizam JUnit e o plug-in do JUnit para o JDeveloper. Os
procedimentos para teste se encontram nos artigos a seguir:

https://blogs.oracle.com/bwb/resource/JUnit_Testing/Unit_Testing_with_JUnit_and_JDevelope
r_11g.html

http://www.oracle.com/technetwork/articles/adf/part5-083468.html
Para maior cobertura funcional os testes devem focar nas classes de negócio do sistema, não
sendo necessário criar testes unitários para classes utilitárias, de modelo ou de controle. Outros
procedimentos de qualidade e teste automatizado devem ser definidos nos Planos de Teste e na
Metodologia de Qualidade do MCTI.
11 Requisitos Não Funcionais
11.1 Descrição
São os requisitos relacionados ao uso da aplicação em termos de desempenho, usabilidade,
confiabilidade, segurança, disponibilidade, manutenibilidade e tecnologias envolvidas. Em geral,
requisitos não-funcionais podem constituir restrições aos requisitos funcionais e não é preciso o cliente
dizer sobre eles, pois eles são características mínimas de um software de qualidade.
Os requisitos não funcionais se caracterizam por:

Demonstram qualidade e ou restrições acerca dos serviços ou funções disponibilizadas pelo
sistema. Ex.: restrições de tempo, restrições sobre o processo de desenvolvimento, padrões, etc.

Surgem conforme a necessidade dos usuários, em razão de restrições de orçamento e outros
fatores.

Podem estar relacionados à confiabilidade, tempo de resposta e espaço nas mídias de
armazenamento disponíveis.

Caso ocorra falha do não atendimento a um requisito não funcional, poderá tornar todo o
sistema ineficaz. Ex.: requisito confiabilidade em um sistema de controle de voos.
11.2 Classificação dos Requisitos Não Funcionais
Os requisitos não funcionais mais conhecidos são listados na tabela a seguir, no entanto,
quaisquer requisitos dos stakeholders que não se refiram a usos e necessidades do sistema pelo usuário,
mas sim a SLAs, exigências de comportamento, operação, sustentação e demais situações não
funcionais devem ser descritos na Arquitetura do Sistema e tratadas.

Requisitos de produtos: Requisitos que especificam o comportamento do produto.Ex.
portabilidade; tempo na execução; confiabilidade,mobilidade, etc.

Requisitos da organização: Requisitos decorrentes de políticas e procedimentos corporativos.
Ex. padrões, infra-estrutura,etc.

Requisitos externos: Requisitos decorrentes de fatores externos ao sistema e ao processo de
desenvolvimento. Ex. requisitos de interoperabilidade, legislação,localização geográfica etc.

Requisitos de facilidade de uso. Ex.: usuários deverão operar o sistema após um determinado
tempo de treinamento.

Requisitos de eficiência. Ex.: o sistema deverá processar n requisições por um determinado
tempo.

Requisitos de confiabilidade. Ex.: o sistema deverá ter alta disponibilidade, p.exemplo, 99% do
tempo.

Requisitos de portabilidade. Ex.: o sistema deverá rodar em qualquer plataforma.

Requisitos de entrega. Ex.: um relatório de acompanhamento deverá ser fornecido toda
segunda-feira.

Requisitos de implementação: Ex.: o sistema deverá ser desenvolvido na linguagem Java.

Requisitos de padrões: Ex. uso de programação orientada a objeto sob a plataforma A.

Requisitos de interoperabilidade: Ex. o sistema deverá se comunicar com o SQL Server.

Requisitos éticos. Ex.: o sistema não apresentará aos usuários quaisquer dados de cunho
privativo.

Requisitos legais. Ex.: o sistema deverá atender às normas legais, tais como padrões, leis, etc.

Requisitos de Integração. Ex.: o sistema integra com outra aplicação.
11.3 Requisitos Não Funcionais nativos da Arquitetura de Referência
Os seguintes requisitos não funcionais são atendidos nativamente para os sistemas Java
construídos com esta Arquitetura de Referência:
Requisito Não Funcional
Requisitos de produtos
Requisitos da organização
Requisitos externos
Requisitos de facilidade de
uso
Requisitos de eficiência
Requisitos de
confiabilidade
Requisitos de
portabilidade
Requisitos de entrega
Requisitos de
implementação e Padrão
Requisitos de
interoperabilidade e
integração
Como a Arquitetura Atende
Sistemas portáveis para quaisquer sistemas operacionais e servidores de
banco de dados SQL e de aplicação Java. O tempo de execução das
chamadas varia entre 1 e 15 segundos. Os sistemas podem ser utilizados
em dispositivos móveis e apresentando grande confiabilidade e
disponibilidade, por estar em cluster e ter todo o controle de transações
gerenciado pelo servidor de aplicação.
A Arquitetura segue os requisitos da organização de utilizar elementos
gratuitos, ser portável, produtiva, fácil de utilizar e manter e ser
compatível com BPM, SOA e ECM e segue o processo de desenvolvimento
do MCTI e os padrões de interface visual do Ministério.
A Arquitetura é interoperável, pode atuar em ambientes de internet ou
intranet, totalmente web, não sendo necessário instalar componentes nas
máquinas cliente, passível de integração com outros órgãos
governamentais e privados e suportar e-Ping.
A interface visual dos sistemas que seguem a arquitetura são interfaces
ricas, intuitivas e com suporte a validação e ajuda online.
O tempo de processamento médio de requisições será em torno de 4
segundos, mas pode variar entre 1 e 20 segundos.
A arquitetura está preparada para operar em alta disponibilidade e
suporta crescimento vertical e horizontal de recursos para crescer. Além
disto possui gestão de transações implementado pelo próprio servidor de
aplicações.
Suporta Windows, Linux, Unix, Mac e quaisquer outros sistemas
operacionais suportados pelo Glassfish. Também suporta quaisquer banco
de dados SQL ANSI, tais como PostgreeSQL, MySQL, Oracle, dentre outros.
Por fim, está preparado para operar com qualquer servidor de aplicação
JEE 5 ou superior, além de suportar Internet Explorer 7 ou superior,
Firefox 5 ou superior, Chrome, Safari e navegadores do Android e iOS, no
entanto é melhor visualizado com navegadores que suportem HTML 5.
São definidos nos Plano de Projeto, mas os sistemas projetados na
arquitetura possuem produtividade (com o uso completo da metodologia)
de 8 horas por ponto de função.
Os sistemas Java devem se restringir às definições arquiteturais deste
documento.
Os sistemas Java desta Arquitetura suportam comunicação via EJB remoto,
JMS e Web Services REST ou SOAP
11.4 Requisitos Não Funcionais dos Sistemas Java da Arquitetura
Os sistemas Java possuem seus próprios requisitos não funcionais que devem ser documentados
no Documento de Arquitetura do Sistema ou em Documento de Especificação Suplementar. Os
requisitos acima descritos apenas reportam quais requisitos não funcionais já são atendidos
automaticamente ao se adotar a Arquitetura de Referência corretamente e integralmente.
12 Arquitetura de Recursos de Homologação e Produção
12.1 Ambiente de Produção
Figura 22 - Topologia do Ambiente de Produção
O ambiente de produção possui balanceador de carga para distribuir as requisições de usuário
oriundas de estações de trabalho, notebooks e aparelhos portáteis na Internet e Intranet do MCTI. Este
balanceador de carga utiliza o mod_proxy do Apache Server que distribui a carga igualmente entre os
servidores virtuais (VM 01 e VM 02).
Ao receber as requisições do balanceador as VMs com 04 cores, 16 GB de RAM e 300 GB de HD
com CentOS como sistema operacional e Glassfish como servidor de aplicações, acessam o banco de
dados PostGreeSQL (ainda não clusterizados com PG_Pool) e montam o retorno. Balanceador envia o
retorno para o navegador do usuário para apresentar a resposta à requisição.
A Arquitetura suporta o crescimento vertical e horizontal desta topologia, podendo crescer a
quantidade de núcleos de processamento, memória e HD ou aumentar a quantidade de VMs, conforme
o crescimento das requisições.
No futuro, se prevê a clusterização também do banco de dados com PG_Pool.
12.2 Ambiente de Homologação
Figura 23 - Topologia do Ambiente de Homologação
O ambiente de homologação é mais simples do que o de produção, pois não possui balanceador
de carga, tem apenas uma VM que requisições de usuário oriundas de estações de trabalho, notebooks
e aparelhos portáteis na Internet e Intranet do MCTI.
Ao receber as requisições a VM de homologação com 04 cores, 16 GB de RAM e 300 GB de HD
com CentOS como sistema operacional e Glassfish como servidor de aplicações, acessam o banco de
dados PostGreeSQL e monta o retorno, enviando o mesmo para o navegador do usuário para apresentar
a resposta à requisição.
13 Referências
KRUCHTEN, Philippe. Architectural Blueprints — The “4+1” View Model of Software Architecture. IEEE
Software. 1995.
GAMMA Erich; HELM, Richard; JOHNSON, Ralph; VLISSIDES, John. Design Patterns: Elements of
Reusable Object-Oriented Software. 1 ed. Estados Unidos: Addison-Wesley, 1995.
LARMAN, Craig. Utilizando UML e Padrões. 3ª Edição. Estados Unidos: Bookman, 2007.
CRUPI, John; MALKS, Dan; ALUR, Deepak. Core J2EE Patterns. Estados Unidos: Campus, 2004.
MASSOL, Vincent; HUSTED Ted. JUnit em ação. Brasil: Ciência Moderna, 2005.
MILLS Duncan; KOLETZKE, Peter, ROY-FADERMAN, Avrom. Oracle JDeveloper 11g Handbook : A Guide
to Fusion Web Development. Estados Unidos: McGraw Hill Professional, 2009.
ERL, Thomas. Principles of the Service Design. Canadá: Editora Prentice Hall, 2010.
TIOBE. Ranking das Linguagens de Programação. 2013. Disponível em:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html. Acesso em 31/10/2013.