Documento de Arquitetura de Referencia de Software

Coordenação Geral de Tecnologia da Informação - CGTI

MAPA/SE/SPOA/CGTI, 2009 Página 1

MAPA - Ministério da Agricultura, Pecuária e Abastecimento

Documento de Arquitetura de Referência de Software

Versão 1.1


MAPA - Ministério da Agricultura, Pecuária e Abastecimento Versão 1.1

Documento de Arquitetura de Software Data: 30/3/2011


Histórico da Revisão

Data Versão Descrição Autor Revisor

25/02/2009 1.0 Criação do artefato. Ricardo Sousa Marques

José Roberto Vasconcelos

25/03/2009 1.1 Correção de figuras, detalhamento da visão de implementação


Francisco Menezes





Índice

1. INTRODUÇÃO ......................................................................................... 4 2. REPRESENTAÇÃO DA ARQUITETURA................................................ 4 3. METAS E RESTRIÇÕES DE ARQUITETURA ........................................ 6 4. VISÃO DE CASOS DE USO.................................................................... 8 5. VISÃO LÓGICA ....................................................................................... 9 6. VISÃO DE IMPLEMENTAÇÃO.............................................................. 11 7. VISÃO DE IMPLANTAÇÃO................................................................... 16 8. TAMANHO E DESEMPENHO ............................................................... 18 9. QUALIDADE .......................................................................................... 18





Documento de Arquitetura

1. Introdução

O documento de arquitetura apresenta uma visão geral abrangente da arquitetura e utiliza uma série de visões arquiteturais para ilustrar os diversos aspectos dos sistemas. Sua intenção é capturar e transmitir as decisões significativas do ponto de vista da arquitetura que foram tomadas pelo MAPA - Ministério da Agricultura, Pecuária e Abastecimento para o desenvolvimento de seus sistemas.

O objetivo deste documento é descrever uma arquitetura de referência para os projetos desenvolvidos no âmbito do Ministério da Agricultura Pecuária e Abastecimento tendo como foco sistemas desenvolvidos utilizando tecnologia J2EE.

Neste documento vamos contemplar o que é comum aos sistemas. Torna-se necessário que cada uma das aplicações, adote um documento com informações suplementares a este demonstrando as suas especificações de caso de uso arquiteturalmente significativas demonstrando também as diferenças implementadas e algum destaque que seja relevante ao processo de desenvolvimento.

Os projetos de sistema de informação desenvolvidos pelo MAPA têm um domínio similar, desta maneira, verificou-se que as decisões arquiteturais que aqui serão apresentadas podem ser aplicadas de maneira homogênea.

Tratam-se de aplicações com forte influência transacional, em ambiente WEB, utilizando o mesmo banco de dados, o mesmo ambiente de implantação (Servidores de aplicação/Servidores de banco de dados), com requisitos parecidos de performance, portabilidade, usabilidade e compartilhando a mesma infra-estrutura de apoio ao desenvolvimento, (segurança, autenticação e log).

1.1 Definições, Acrônimos e Abreviações

Vide MAPA – Glossário.

1.2 Referências

� MAPA – Glossário;

� MAPA – Especificação Suplementar;

� Especificação W3C para o HMTL 4.01 http://www.w3.org/TR/html401/

� Modelo de acessibilidade de Governo Eletrônico Versão 2.0 http://www.governoeletronico.gov.br/anexos/e15_1556emag-acessibilidade-de-governo-eletronico-modelo-v20.zip

2. Representação da Arquitetura

A modelagem, implementação e documentação de um sistema requerem que o sistema seja visualizado de diferentes perspectivas. Desse modo, a arquitetura proposta será apresentada conforme o modelo de visões 4+1, proposta por Philippe Kruchten (Kruchten, 1995),





utilizadas no RUP (Kruchten, 2000), que apresenta 5 diferentes visões: Visão de Casos de Uso, Visão Lógica, Visão de Processos, Visão de Implementação e Visão de Implantação.

A rigor, cada sistema desenvolvido, deve conter um documento de arquitetura informando as decisões arquiteturais mais significativas ao projeto.

A Visão de Caso de Uso e a Visão de Processos por se tratar de um item específico de cada sistema fará parte de um outro documento específico por sistema contendo esta informação.

A figura 1 apresenta a organização das perspectivas utilizadas. E em seguida é apresentada uma simples descrição das responsabilidades de cada uma das perspectivas.

Visão Lógica Visão de Componentes

Visão de ImplantaçãoVisão de Processos

Visão de Casos de Uso

Figura 1 - Modelo de Visão 4+1 (Philippe Kruchten, 1995)

Visão de Casos de Uso: O propósito desta visão é apresentar os casos de uso arquiteturalmente significativos para o sistema, ou seja, este será o conjunto de casos de uso que direcionarão a arquitetura do sistema como um todo. Esta visão usará diagramas de casos de uso para expor as funcionalidades e diagramas de seqüência para mostrar a interação entre objetos e o relacionamento entre os diversos elementos da arquitetura.

Visão Lógica: Esta visão irá apresentar as definições do sistema através de diagramas de classes, ou quaisquer outros diagramas que descrevam os serviços que o sistema fornecerá aos seus usuários. Esta visão será utilizada para apresentar a arquitetura num nível elevado de abstração.

Visão de Processos: Esta visão mostra a decomposição do sistema, bem como as formas de comunicação entre processos, passagem de mensagens, atividades entre componentes e seqüência de mensagem. Essa representação é feita através dos diagramas de seqüência, e opcionalmente pelos diagramas de colaboração e atividades.

Visão de Implementação: Esta visão irá descrever a organização dos subsistemas e componentes do sistema. Esta visão irá mostrar as diversas camadas do software, bem como as fronteiras entre essas camadas.

Visão de Implantação: Esta visão descreverá como o sistema será distribuído e implantado





nos nós físicos, nos quais será executado.

3. Metas e Restrições de Arquitetura

A arquitetura deve obedecer às metas e restrições impostas pelos requisitos funcionais e não funcionais. Com o propósito de enumerar alguns itens genérico enumeramos algumas das metas utilizadas como base para as decisões tomadas:

� Ganhos expressivos de produtividade no desenvolvimento dos sistemas;

� Garantir de evolução nos produtos utilizados como base da arquitetura;

� Aderência a padrões de mercado;

� Utilizar softwares que tenham seu código sob licença GPL ou equivalente com exceção do banco de dados e servidor de aplicação;

� Integrar aplicações;

� Reutilizar rotinas relacionadas a questões corporativas. Ex, alteração de senha, cadastro de usuários, etc;

� Implementar auditoria única nos sistemas;

� Disponibilizar um ponto único para acesso aos sistemas usando SSO;

� Padronizar o desenvolvimento para facilitar a manutenção, principalmente quando este é realizado por fábricas de software que porventura sejam contratas;

� Estar adequado à infra-estrutura já utilizada pelo MAPA;

� Conformidade com os requisitos de segurança (autenticação e autorização);

� Estimulo aos testes automatizados;

� Estímulo ao reuso.

Como itens restritivos de arquitetura, analisando-se genericamente o ambiente de desenvolvimento, enumeramos os itens a seguir:

� Utilização do SGBD corporativo (Oracle versão 10.2.0.4) seguindo os padrões de criação de tabelas existente no MAPA;

� Utilização de servidores de aplicação diferentes: OC4J para o desenvolvimento e o OAS como servidor nos ambientes de homologação/produção;

� Desenvolvimento em estações Windows e posterior disponibilização para homologação/produção cujo sistema operacional é Linux;

� Os sistemas desenvolvidos deverão ser homologados utilizando os seguintes navegadores: Internet Explorer 7.x e no Mozilla Firefox 3.x;

� Funcionamento do servidor de aplicação de produção em cluster de forma a ter maior disponibilidade e gerenciamento de recursos norteando assim as soluções adotadas de cache e variáveis de sessão;

� As trilhas de auditoria serão construídas utilizando elementos de banco de dados (triggers);

� Aderente aos padrões visuais definidos pelo MAPA e em consonância com os padrões governamentais de acessibilidade e usabilidades.





3.1 Restrição de Ambiente

No MAPA estão definidos os seguintes ambientes para o desenvolvimento de projetos:

� Desenvolvimento

� Homologação

� Produção

Os ambientes possuem gestores para sua administração e todas as requisições de criação e disponibilização tem que passar por um processo formal já definido na CGTI.

Na produção o servidor de banco de dados e servidor de aplicação estão em cluster, o que não acontece nos outros ambientes (desenvolvimento e homologação). Os testes e treinamento de usuários podem ser feitos utilizando o ambiente de homologação.

3.1.1 Sistemas Operacionais

� Desenvolvimento : Windows XP SP2

� Homologação: Linux Redhat 3

� Produção: Linux Redhat 4 update 7

3.1.2 Gerenciador de Banco de Dados

Oracle database

� Desenvolvimento versão 10.2.0.4

� Homologação versão 10.2.0.4

� Produção versão 10.2.0.4

3.1.3 IDE de desenvolvimento

� Eclipse versão 3.4.1

3.1.4 Gerenciador de Aplicação

� Desenvolvimento: OC4J versão 10.1.3.4

� Homologação: Oracle Application Server versão 10.1.3.4

� Produção: Oracle Application Server versão 10.1.3.4

3.1.5 Navegadores Internet

� Firefox 3.0 ou superior nas suas sub-versões;

� Internet Explorer 7.0 ou superior nas suas sub-versões.





3.1.6 Java Virtual Machine

� Java JDK 1.5

Os recursos tecnológicos utilizados pelo MAPA - Ministério da Agricultura, Pecuária e Abastecimento são relacionados a seguir, são eles:

Recursos Tecnológicos

Nome Descrição Versão Fornecedor Tipo

Struts Framework de apresentação utilizada para resolver controle de ações, lógicas de apresentação e disponibilização de visões.

2.1.6 Apache Software Foundation

Framework

EJB (Enterprise

JavaBeans)

Framework responsável em gerenciar a persistência, processamento transacional, controle de concorrência, segurança de acesso e lógica de negócio.

3.0

Sun Microsystems

Framework

Hibernate Framework de persistência utilizada para realizar mapeamento objeto relacional, persistência e consultas.

3.2.6 JBoss / Red Hat.

Framework

JasperReports Biblioteca responsável em gerar relatórios em PDF.

3.0.0 JasperSoft

Biblioteca

JFreeChart Biblioteca responsável em gerar gráficos. 1.0.10 JFree Biblioteca

JPA(Java

Persistence API) Padrão para persistência. 1.0

Sun Microsystem

Padrão

JSTL Biblioteca que encapsula tags simples para ser utilizada provendo muitas funcionalidades nas aplicações

1.2 Sun Microsystem Biblioteca

Tiles

Framework templating para desenvolvimento web que permite a junção de vários pedaços HTML gerados em partes da mesma aplicação em um única página final renderizada.

2.1.2

Apache Software Foundation Biblioteca

DisplayTags

Biblioteca que facilita a navegação em listas de resultados com funcionalidades de paginação, ordenação, exportação, agrupamento.

1.2

Projeto disponível no sourceforge

Biblioteca

IReport IDE para design de relatórios 3.0.0 JasperSoft IDE

Tabela 1 - Tabela com lista de recursos tecnológicos

4. Visão de Casos de Uso

Nesta seção há definição dos principais casos de uso que representam um grande risco arquitetural, no entanto, com a proposta desse documento é de âmbito mais amplo, essas definições estarão contempladas em um documento de especificação suplementar de arquitetura, por parte de cada projeto.





5. Visão Lógica

Esta visão descreve em que arquitetura o software será construído, abordando aspectos de organização dos pacotes, como responsabilidades, topologia e a forma de comunicação e dependência entre os pacotes.

5.1 Visão Geral

Os diagramas abaixo mostram as classes, os pacotes e as camadas mais significativas do ponto de vista arquitetural do framework de arquitetura.





class Arquitetura Padrão MAPA

Camada de Negócio

Camada de Apresentação

«BD»Business Delegate

«EJB»Business Serv ices

Application Serv ice

«BO»Business Object

Serv ice Locator

«view»View

Camada de Integração

«Action»Action

«DAO»Data Access Object

«DAO»Data Access Object Abstrato

«entitity»Entidade

«bind»

«use»

«use»«association»

«use»

«association»

«association»

«use»

«call»

«association»

«use»

Figura 2 - Representação das camadas e dos respectivos padrões de projeto.





5.2 Pacotes Significativos do Ponto de Vista da Arquitetura

Apresentação

Na camada de apresentação são utilizados Struts 2 e Tiles. São utilizados os seguintes padrões de projeto:

� MVC (Model-View-Controller) – Responsável em controlar as requisições dos usuários, disponibilizando visões e lógica de negócio apropriada;

� Service Locator – Responsável em localizar os componentes de negócio (EJB);

� Business Delegate – Responsável em delegar a regra de negócio e tratar as exceções oriundas da camada de negócio, como resultado minimiza o acoplamento entre a camada de apresentação e a camada de negócio.

Negócio

Na camada de negócio é utilizado EJB 3(Enterprise JavaBeans) para gerenciamento de transações declarativas, pool de objetos e para segurança declarativa. São utilizados os seguintes padrões de projeto:

� Facade/Business Service – Responsável em prover um ponto único de acesso aos componentes de negócio, prover controle transacional e de segurança;

� Application Service – Responsável em conter as regras de negócio por caso de uso e invocar todos os objetos de negócio necessários ao caso de uso;

� Business Object – Responsável em conter as regras de negócio por entidade de negócio;

Integração

Na camada de integração é utilizado Hibernate 3 para a persistência e recuperação de dados. É utilizado o seguinte padrão de projeto:

� DAO (Data Access Object) – Responsável em realizar a persistência e consulta aos dados.

� Entidades – Responsável pela representação dos dados persistentes da aplicação.

5.3 Estratégia de Reuso

Existem duas estratégias de reuso adotadas para o MAPA - Ministério da Agricultura, Pecuária e Abastecimento, são elas:

� Desenvolver com granularidade em nível de entidade, para possibilitar o reuso aos casos de uso dos sistemas a serem desenvolvidos;

� Permitir o reuso através de componentes, que por sua vez disponibilizam serviços para atender aos sistemas do MAPA.

6. Visão de Implementação

Esta visão detalha as camadas dos sistemas, componentes, suas responsabilidades, fronteiras e nomenclatura.





Camada Controle e

Apresentação

Camada de Lógica de Negócio

Camada de Acesso aos Dados

Componentes de Persistência DAO

Hibernate

Páginas HTML (.jsp)

Actions (Struts 2)

Business Delegate

Serviços de Aplicação

Oracle

Entidades de N

egócio

Serviços de Negócio

Controle

Figura 3 – Arquitetura em camadas

6.1 Visão Geral

Os sistemas devem ser desenvolvidos no estilo arquitetural de camadas (3-Tier)

A estrutura em camadas será dividia em:

• Camada de Controle e Apresentação;

• Camada de Lógica de Negócio;

• Camada de Acesso a Dados;

6.2 Camada de Controle e Apresentação

Na sua maioria os sistemas do MAPA terão sua camada de apresentação baseada em WEB utilizando um “Front Controller”, porém da forma que esta nova arquitetura foi pensada, ela está preparada para que possa também ser utilizada por aplicações em PDAs, Celulares, processos BPM, Web Services, etc.

6.2.1 Responsabilidade

� Prover ao usuário final a interface gráfica (GUI) de utilização da aplicação;

� Captar dados do usuário ou de outras fontes externas;

� Realizar validações básicas de entrada de dados, como por exemplo, datas e valores. A validação nesta camada não pode ser considerada a única validação;

� Formatar os dados para o usuário do sistema, como por exemplo, máscara para os campos data, números formatados, CNPJ, etc;

� Paginar resultados de pesquisa que retornem uma grande quantidade de elementos;

� Formatar erros repassados pelas camadas inferiores, realizando o tratamento adequado para





apresentação do erro ao usuário final;

� Mediar e coordenar os pedidos feitos utilizando o Business Delegate repassando a resposta dada através da camada de Negócio;

� Mediar e coordenar os pedidos feitos através da camada de Apresentação e resposta dada através da camada de Negócio;

� Gerenciar as exceções recebidas do negócio e transformá-las em exceções amigáveis;

� Prover o conceito de internacionalização para a apresentação.

6.2.2 Conteúdo

A camada de apresentação é tipicamente formada por páginas WEB que são visualizadas por navegador internet:

� As interfaces WEB podem receber vários elementos compatíveis com o navegador (browser), por exemplo, arquivos PDF, imagens, etc.

� As páginas HTML são formatadas através de estilos CSS – Cascade Style Sheet.

� Modelos (template) de relatórios utilizados por frameworks de mercado, por exemplo, JasperReports;

� Para geração dinâmica das interfaces WEB, será utilizada a tecnologia de JSP;

� Mecanismo para paginação padrão de mercado, a exemplo o DisplayTag;

� O menu do usuário na aplicação é construído de acordo com suas permissões;

� Com a utilização do tiles, a confeção das páginas de um mesmo sistema será baseada em template de forma a maximizar o padrão de tela definido e maximizar a produtividade, permitindo assim que só as partes que interessam da página principal sejam renderizadas pela aplicação;

� A interação com a tela (HTML) utiliza controladores Actions que neste modelo trabalho como um orquestrador de requisições à camada de negócio.

6.2.3 Relacionamento com a camada de Lógica de Negócio

� A camada de apresentação se relaciona com a camada de negócio utilizando um pattern J2EE denominado Business Delegate.

� O Business Delegate se comporta como uma fachada para acesso aos serviços disponibilizados nos componentes de negócio.

6.2.4 Nomenclatura

� Controladores de visão são representados por uma classe extendida de ActionSupport, cuja sua nomenclatura deverá seguir o seguinte padrão Nome + sufixo (Action), exemplo LoginAction;

� A interface de comunicação entre as Actions e a Camada de Negócio, será representada por uma classe relacionada ao pattern Business Delegate, cujo padrão de nomenclatura será Nome + sufixo (BD), exemplo SegurancaBD.





6.3 Camada de Lógica de Negócio

A camada de negócio encapsula todas as regras de negócio da aplicação disponibilizando para a requisição das aplicações interfaces de serviços. Estes serviços são métodos disponibilizados para acesso.


� Disponibilizar a camada de apresentação um conjunto de métodos que representam operações de negócio ou eventos demandados por casos de uso do sistema.

� Mediar e coordenar os pedidos feitos através da camada de Apresentação e resposta dada através da camada de Negócio;

� Desacoplar a camada de Apresentação da camada de Negócio;

� Cumprir a lógica de aplicação, ou seja, a lógica envolvida na mediação e coordenação de operações de negócio que suprem as necessidades de um ou mais casos de uso

� Executar tarefas “técnicas” que não são responsabilidade da camada de apresentação, como por exemplo, envio de e-mail, geração de arquivos, exemplo relatórios PDF.

� Repassar à camada de Apresentação o retorno das invocações solicitadas, inclusive erros apontados no processamento da requisição, como, por exemplo, Exceções de Negócio;

� Executar as regras de negócio vinculadas aos conceitos específicos do negócio;

� Manter a integridade dos dados através de mecanismos de validação das regras de negócio quanto à inclusão e exclusão.

� Implementação dos algoritmos com as regras de negócio. Problemas de desempenho quando detectados deverão ser tratados pontualmente.

� Orquestração das varias regras que podem envolver um determinado caso de uso.

6.3.2 Conteúdo

Esta camada contém basicamente os seguintes objetos:

Business Services: Centraliza as chamadas aos applications services funcionando como ponto único de acesso.

Objetos de Negócio BO que representam os conceitos de negócio aplicados a um domínio.

Estes objetos podem estar associados com outros Objetos de Negócio em uma relação de dependência. Estes relacionamentos podem ser feitos por associações diretas, através de agregações/composições, delegação ou herança.

6.3.3 Relacionamento com a camada de Negócio

� Através do Business Delegate passando e recebendo entidades, objetos e tipos primitivos.

� Vale ressaltar que existirá apenas um BD por aplicação.





6.3.4 Nomenclatura

� Controladores de Caso de Uso devem terminar com a palavra “APS”, exemplo ManterUsuarioAPS;

� As interfaces do Beans devem possuir concatenado ao seu nome o prefixo I (letra i) e ao sufixo a palavra “Remote” ou “Local” de acordo com o tipo de interface, exemplo ISegurancaRemote ou ISegurancaLocal;

� Para o Bean (EJB) será composto do nome e do sufixo “Bean”, exemplo SegurancaBean;

� Para as classe que representam as regras de domínio relacionadas ao pattern Business Object, o padrão de nomenclatura seguirá Nome do Domínio + sufixo (BO), exemplo UsuarioBO.

6.4 Camada de Dados

Em projetos orientados a objeto esta camada faz a transformação entre o modelo entidade-relacionamento dos bancos relacionais para um modelo OO de forma transparente para a aplicação.


� Mapeamento das entidades de negócio no banco de dados

� Controle de cache de dados recuperados do banco

� Centralização de acesso a dados nas diversas pesquisas

� Permite um reaproveitamento das consultas utilizadas pela aplicação

6.4.2 Conteúdo

Entidades, Objetos que tramitam entre a camada de negócio e camada de dados transportando valores recuperados de tabelas mapeadas no banco de dados.

Data Access Object DAO, permite separar regras de negócio das regras de acesso a banco de dados.

Todos os DAOs do sistema devem estender a classe EntidadeDAO, assim garante-se a reutilização de código, pois esta já possui todo mecanismo necessário para incluir, alterar e excluir.

Responsável por solicitar ao meio persistente a persistência e recuperação do estado dos objetos de negócio; Executam as operações de CRUD.

6.4.3 Nomenclatura

� Classes que contêm operações para manipulação de dados persistentes devem ter como sufixo o complemento DAO ao seu nome, exemplo UsuárioDAO;

� As entidades refletem o nome da tabela mapeada no banco e os nomes de suas colunas respectivas.





7. Visão de Implantação

Esta é a visão arquitetural que ilustra a distribuição do processamento nos nós computacionais, incluindo a distribuição física de processos e threads. O detalhamento desta visão está condicionado aos levantamentos a serem efetuados com a equipe de rede do MAPA.

Figura 4 - Visão física da rede

A Figura 4 representa a infra-estrutura física do ambiente de produção do mapa. Não há nenhum ambiente de teste/homologação que simule este ambiente no MAPA.

O deployment da aplicação será efetuado nos servidores de aplicação em um único container do OAS que é replicado nos outros servidores do cluster.





cmp Components

«artefato»aplicacao.ear

«artefato»aplicacao_ejb.jar

«session bean»aplicacaoEJB.jar

«Enti ty Hibernate»aplicacaoEntity.j ar

«artefato»aplicacao_web.war

Dispatcher

«JSP».j sp

«artefato».tld, .gif, .html, etc

«use»

«manifest»

«manifest»

«manifest»

«manifest»

«manifest»«manifest»

Figura 5 - A figura abaixo ilustra a forma geral de deployment dos componentes de arquitetura.

O diagrama de componentes abaixo representa a dependência de componentes do sistema.

cmp Componentes da Arquitetura

«framework»Struts2

«framework»Hibernate

«framework»EJ B3

«library»JasperReports

«library»JFreeChart

«executable»Mapa .Ear

«trace»«trace»

«trace» «trace» «trace»

Figura 6 – Representação dos respectivos componentes de software.





8. TAMANHO E DESEMPENHO

Este item vai ser especificado no documento de arquitetura suplementar de cada um dos sistemas.

9. QUALIDADE

De acordo com o IEEE Task Force, os três principais fatores que influenciam a qualidade de projetos de TI baseados na WEB são confiabilidade, usabilidade e segurança. Além destes, alguns fatores importantes seriam disponibilidade, escalabilidade e manutenabilidade. Com a arquitetura apresentada para servir de base aos sistemas do MAPA esperamos atender a estes requisitos não funcionais:

Confiabilidade – A arquitetura garante a confiança de que a aplicação sempre retornará aquilo que é esperado da mesma. Mantendo a separação das funcionalidades, acesso ao banco, regras de negócio e apresentação, é possível diminuir a ocorrência de erros e a falta de clareza de conceitos.

Usabilidade – A interface com o usuário será definida da forma mais intuitiva respeitando critérios de acessibilidade possibilitando facilitar o treinamento dos usuários e a gestão de mudança. Como há uma camada especialmente definida para isso, o foco será mantido na solução desta questão separadamente, sem a mistura com outras questões de responsabilidade de outras camadas.

Segurança – A utilização de mecanismos de autorização/autenticação unificados em conjunto com uma padronização do sistema de log e auditoria torna possível incrementar a segurança facilitando o desenvolvimento e estabelecendo normas com um baixo esforço dos programadores.

Disponibilidade – Este requisito tem o benefício da robustez do desenvolvimento de arquiteturas JAVA usando servidores em cluster. Combinado à separação de responsabilidade das camadas, o que reduz a quantidade de erros, chega-se a garantir a disponibilidade do sistema para atendimento das necessidades.

Escalabilidade – Um dos grandes benefícios da separação em camadas consiste em permitir que o sistema possa evoluir naturalmente com o crescimento da demanda sem esforços desproporcionais. As camadas podem ser alteradas, observando-se as interfaces, de modo a manter a atualização necessária do ciclo de vida do produto.

Manutenabilidade – Talvez o maior benefício da arquitetura n-tier, uma vez que o código está separado em especialidades, tornando assim bem mais fácil a depuração de erros e a construção de novas funcionalidades.

Vide MAPA – Especificação Suplementar para informações de critérios adicionais de qualidade e as características dos requisitos não funcionais que norteiam a arquitetura.

Percebe-se, portanto, que a arquitetura escolhida traz grandes benefícios para o projeto. Assim, a qualidade do sistema está garantida mantendo-se foco no processo, na produção da documentação atualizada e na qualidade dos testes.





Marcelo Fiadeiro

Área: CGTI

Cargo:

Coordenador Geral de Tecnologia da Informação

Matricula:

Data:

Rosângela Gomes

Área: CGTI

Cargo:

Coordenador de Sistemas de Informação

Matricula:

Data:

Kleber Simão

Área: CGTI

Cargo:

Chefe da Divisão de Sistemas e Gestão de Banco de Dados

Matricula:

Data:

Francisco Menezes

Área:

CGTI

Cargo:

Arquiteto do Projeto Migração - MAPA

Matricula:

Data:

Assinatura:


Área:

Consórcio BPM

Cargo:

Arquiteto do Projeto Migração – B2Br

Matricula:

-

Data:

Assinatura:

Documents

Documento de Arquitetura de Referencia de Software