arquitetura de software - ancineancine.gov.br/media/projeto_arquitetura_software_v_1_15.pdf ·...

Secretaria de Gestão Interna

Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 1/29"

Projeto de Arquitetura de Software

Versão do Documento: 1.15



Histórico de Revisão

Data Versão do

Documento Descrição Autor

1.1 Descrição da atividade realizada no documento.

Rodolfo Lace

06/01/2006 1.2 Descrição da atividade realizada no documento.

Flávio Junior


Flávio Junior


Flávio Junior


Flávio Junior


Flávio Junior / Miguel Garz

29/07/2006 1.7 Atualização de elementos arquiteturais: DisplayTag

Miguel Garz / Flávio Junior

29/08/2006 1.8 Atualização de elementos de boas práticas: Concatenação de query

Miguel Garz/ Flávio Junior

29/09/2006 1.9 Atualização das versões dos frameworks utilizados

Miguel Garz / Flávio Junior

29/10/2006 1.10 Inserção do requerimento de log de navegação

Miguel Garz / Daniel Bernd

16/11/2006 1.11

Inserção de requisitos de qualidade para sistemas em produção.

Miguel Garz / Daniel Bernd

13/12/2006 1.12

Inserção de boas práticas e requisitos de usabilidade referentes a problemas de dupla submissão de formulários.

Inserção do Ancine Batch Processing Framework

Atualização dos requisitos para recebimento de sistema.

Miguel Garz/ Daniel Bernd



06/08/2007 1.13 Atualização dos requisitos da fábrica de software

Miguel Garz /

Douglas Matheus

14/09/2007 1.14

Atualização de algumas regras após avaliação do SALIC e Fiscalização 1.3

- Forma de listagem

- Nomes de métodos na camada DAO.

Miguel Garz / Douglas Matheus

23/10/2008 1.15 Atualização das versões das tecnologias utilizadas

Carlos Alferes



Sumário

1. Introdução............................................................................................................................................6

2. Representação da Arquitetura...........................................................................................................6

3. Visão de Lógica...................................................................................................................................6

4. Visão de Implantação .........................................................................................................................7

5. Visão de Implementação ....................................................................................................................7

5.1 Introdução..............................................................................................................8

5.2 Modelagem do diagrama de seqüência .................................................................9

5.3 Metodologia de Desenvolvimento..........................................................................9 5.3.1 Data Access Object (DAO) e Hibernate...........................................................................9

5.3.1.1 Contexto......................................................................................................................9 5.3.1.2 Problema...................................................................................................................10 5.3.1.3 Solução .....................................................................................................................10 5.3.1.4 Benefícios .................................................................................................................11 5.3.1.5 Implantação ..............................................................................................................12

5.3.2 Struts ................................................................................................................................12 5.3.2.1 Contexto....................................................................................................................12 5.3.2.2 Problema...................................................................................................................12 5.3.2.3 Solução .....................................................................................................................13 5.3.2.4 Benefícios .................................................................................................................13 5.3.3 Log de atividades do usuário a nível de aplicação...................................................13 5.3.3.1 Contexto ...................................................................................................................13 5.3.3.2 Problema...................................................................................................................13 5.3.3.3 Solução .....................................................................................................................14 5.3.3.4 Benefícios .................................................................................................................14 5.3.4 Tratamento de Exceções e Log de aplicação...........................................................14 5.3.4.1 Contexto....................................................................................................................14 5.3.4.2 Problema...................................................................................................................14 5.3.4.3 Solução .....................................................................................................................15 5.3.4.4 Benefícios .................................................................................................................15

5.3.5 Segurança ........................................................................................................................16 5.3.5.1 Contexto....................................................................................................................16 5.3.5.2 Problema...................................................................................................................16 5.3.5.3 Solução .....................................................................................................................16 5.3.5.4 Benefícios .................................................................................................................16

5.3.6 Convenção de Código Java............................................................................................16 5.3.6.1 Contexto....................................................................................................................16 5.3.6.2 Problema...................................................................................................................17 5.3.6.3 Solução .....................................................................................................................17 5.3.6.4 Benefícios .................................................................................................................17

5.3.7 Identificação de páginas dinâmicas. .............................................................................17 5.3.7.1 Contexto....................................................................................................................17 5.3.7.2 Problema...................................................................................................................18 5.3.7.3 Solução .....................................................................................................................18 5.3.7.4 Benefícios .................................................................................................................18 5.3.8 Convenção de Empacotamento de Classes.............................................................19



5.3.9 Paginação.........................................................................................................................20 5.3.9.1 Contexto....................................................................................................................20 5.3.9.2 Problema...................................................................................................................20 5.3.9.3 Solução .....................................................................................................................20 5.3.9.4 Benefícios .................................................................................................................20

5.3.10 Padronização de Nomes .................................................................................................21 5.3.10.1 Nome de Classes, JSP e Actions .............................................................................21 5.3.10.2 Estrutura de Diretórios ..............................................................................................21 5.3.10.3 Datasources..............................................................................................................21 5.3.10.4 Manipulação de Dados .............................................................................................21 5.3.11 Framework Ancine de Processamento Batch...........................................................22 5.3.11.1 Contexto....................................................................................................................22 5.3.11.2 Problema...................................................................................................................22 5.3.11.3 Solução .....................................................................................................................22 5.3.11.4 Benefícios .................................................................................................................22 5.3.12 Recepção de novos desenvolvimentos ....................................................................22 5.3.13 Requisitos de software para release de produção. ..................................................23 5.4 Requisitos não funcionais para recebimento de software da fábrica. ......................24 5.4.1 Pré-requisitos Gerais. ...............................................................................................24

5.5 Diagrama de Divisão de Camadas.......................................................................27

5.6 Diagrama de Seqüência de Implementação ........................................................28

6. Visão de Distribuição .......................................................................................................................29

7. Requisitos e Restrições da Arquitetura .........................................................................................29

8. Referências........................................................................................................................................29

9. Assinaturas........................................................................................................................................29



Projeto de Arquitetura

1. Introdução

Este documento apresenta a arquitetura proposta para todos os sistemas ANCINE. A

arquitetura é apresentada através de um conjunto de visões que juntas visam cobrir os principais

aspectos técnicos relativos ao desenvolvimento e implantação dos sistemas. O objetivo é capturar

e formalizar as principais decisões tomadas com relação à arquitetura dos sistemas.

2. Representação da Arquitetura

A arquitetura dos sistemas é representada através das seguintes visões arquiteturais:

• Visão de Lógica;

• Visão de Implantação;

• Visão de Implementação;

• Visão de Distribuição [utilizar esta visão somente se ela for aplicável ao projeto].

3. Visão de Lógica

Não se aplica neste documento. Toda visão lógica a ser implementada será anexada: definição

do sistema, caso de uso, diagrama de classe e de seqüência.



4. Visão de Implantação

5. Visão de Implementação

Esta visão provê como os componentes serão distribuídos em suas camadas. Está dividido em

dois diagramas, um de divisão de camadas, e outro de seqüência de implementação.

Foram adotadas essas camadas, para facilitar na implementação, delegar as atividades de uma

forma correta, atendendo os padrões da arquitetura, tornando assim um sistema de fácil

manutenção. Para cada objeto de negócio, será implementado um componente por camada. Todos

os sistemas da ANCINE são baseados na tecnologia Java, sendo utilizada atualmente a versão 1.5.

A versão do servidor de aplicação JBoss utilizada é a 4.0.3SP1 e a versão do banco de dados

Oracle Enterprise utilizada é 9.2.0.7.0.

-Beans -Struts & extensões -Hibernate -Helpers

<< Jdbc >>

-Javascript -AJAX

App Server (Jboss) Oracle Enterprise



5.1 Introdução

Visando atender uma necessidade de fácil criação, manutenção e a separação das camadas do aplicativo. Adotamos o padrão de projeto Model - View - Controller (MVC), para a plataforma Java. Estrutura do MVC:

Esta separação permite que múltiplos visualizadores compartilhem o mesmo modelo de dados, com isso o suporte a diferentes tipos de usuários é mais fácil de implementar, testar e manter. • Camada de Negócio ( Model ) – representa os dados corporativos e as regras de negócio que

governam o acesso e a atualização desses dados. Utilizaremos nessa camada os padrões: Data

Access Object (DAO) que na nossa arquitetura utilizamos a ferramenta Hibernate na vesão 3.1.3

Para acesso a dados, Transfer Object (TO), Busisness Object (BO), Actions e DispacthActions.

• Camada de Apresentação ( View ) – exibe o conteúdo de um modelo ao usuário. Nesta camada são

utilizados Java Server Pages (JSP’s) , TagLib(TagStruts) para a geração do código HTML.

• Camada de Controle ( Controller ) – transfere as interações entre a camada de apresentação e o

que deve ser executado pela camada de modelo. Nesta camada usamos o framework Struts / XML.



5.2 Modelagem do diagrama de seqüência

A principal função do diagrama de seqüência é comunicar a ordem dos eventos que devem ocorrer e

quais componentes devem processar tais eventos de forma a que o objetivo do caso de uso seja

concretizado. Existem diversas discussões sobre a abrangência da quantidade e forma de informações

que devem estar contidas no diagrama de seqüência. Estudiosos como Martin Fowler define três níveis

diferentes de utilização de um diagrama UML: Utilização como rascunho, Utilização como planta-baixa e

utilização como linguagem de programação. (Ver mais em:

http://www.martinfowler.com/bliki/UmlMode.html e http://www-

128.ibm.com/developerworks/rational/library/3101.html).

Nós da ANCINE decidimos por adotar a abordagem do diagrama de seqüência de implementação

como uma planta-baixa do caso de uso. Isto significa que o diagrama de seqüência deve refletir a

implementação de chamadas às classes do sistema de modo que o programador, ao receber o diagrama

de seqüência deva somente se preocupar em preencher a lógica dos métodos e não a criação dos

métodos.

5.3 Metodologia de Desenvolvimento 5.3.1 Data Access Object (DAO) e Hibernate

5.3.1.1 Contexto

O acesso a dados varia dependendo da origem dos dados. Do acesso ao armazenamento

persistente, como a um banco de dados, varia muito dependendo do tipo de armazenamento (banco

de dados relacionais, bancos de dados orientados a objetos, arquivos planos e assim por diante) e

da implementação do fornecedor.



5.3.1.2 Problema

Muitas aplicações J2EE do mundo real precisam utilizar dados persistentes em algum

momento. Para muitas aplicações, o armazenamento persistente é implementado com mecanismos

diferentes e há diferenças marcantes nas APIs utilizadas para acessá-las. Outras aplicações talvez

precisem acessar dados que residem em sistemas separados. Por exemplo, os dados podem residir

em um sistema mainframe, em repositórios de Lightweight Directory Access Protocol (LDAP).

Há uma variação maior com tipos diferentes de armazenamentos persistentes. Mecanismos

de acesso, suportados por APIs e recursos variam entre diferentes tipos de armazenamento

persistentes como o RDBMS, bancos de dados orientados a objetos, arquivos, planos e assim por

diante. As aplicações que precisam acessar dados de um sistema legado ou diferente (como um

mainframe ou um serviço B2B) são freqüentemente obrigadas a utilizar APIs que podem ser

exclusivas.

Dessa maneira, origens de dados diferentes oferecem desafios à aplicação e podem

potencialmente criar uma dependência direta entre o código da aplicação e código de acesso a

banco de dados. Quando componentes de negócios – beans de entidade, beans de sessão e ainda

componentes de apresentação como servlets e objetos auxiliares Java Server Pages (JSPs)

precisam acessar uma origem de dados, podem utilizar a API adequada para obter conectividade e

manipular a origem de dados. Mas incluir a conectividade e o código de acesso de dados dentro

desses componentes introduz um acoplamento estrito entre os componentes e a implementação da

origem de dados. Assim as dependências de códigos em componentes tornam a migração da

aplicação de um tipo de origem de dados para outro difícil e cansativa. Quando a origem de dados

muda, os componentes precisam ser alterados para tratar o novo tipo de origem de dados.

5.3.1.3 Solução

O uso do Hibernate um framework Open-Source que oferece uma gama de facilidades e

agilidade no desenvolvimento da camada de persistência. Oferecendo-nos a praticidade de apenas

mapear os atributos das Classes com os campos da tabela no Banco de Dados, sem precisar

implementar qualquer linda de código, além de oferecer uma linguagem para consulta chamada

HSQL para realizar filtros e busca de dados. O Hibernate é um dos Frameworks mais utilizados para

realizar a operação de persistência, sua implementação permite o uso de qualquer banco de dados.

A utilização de drivers JDBC para fazer a comunicação com o RDBMS sem qualquer alteração na

aplicação. Por isso optamos por utilizar esse framework como padrões para os projetos ANCINE.



5.3.1.4 Benefícios

• Permite a transparência: Os objetos de negócios podem utilizar a origem de dados sem

conhecer os detalhes específicos da implementação da origem de dados. O acesso é

transparente porque os detalhes da implementação estão ocultos dentro do DAO.

• Permite a migração mais Fácil: Uma camada de DAOs torna mais fácil para uma aplicação

migrar para uma implementação de banco de dados diferente. Os objetos de negócios não têm

nenhum conhecimento da implementação de dados subjacente. Assim, a migração envolve

alterações apenas para a camada de DAO, além disso, e empregar uma estratégia é possível

fornecer uma implementação de factory concreta para cada implementação de

armazenamento subjacente. Nesse caso, a migração para uma implementação de

armazenamento diferente significa fornecer uma nova implementação de factory para a

aplicação.

• Reduz a complexidade dos códigos nos objetos de negócios: Como os DAOs gerenciam

todas as complexidades de acesso a dados, simplifica os códigos nos objetos de negócios e

outros clientes de dados que utilizem os DAOs. Todas as implementações relativas a códigos

(como declarações SQL) estão contidas no DAO e não no objeto de negócios. Com isso a

legibilidade dos códigos juntamente com a produtividade do desenvolvimento é melhorada.

• Centraliza todo acesso de dados em uma camada separada: Como todas as operações de

acesso a dados estão agora delegadas aos DAOs, a camada de acesso a dados separada pode

ser visualizada como a camada que pode isolar o resto da aplicação da implementação de

acesso a dados. Essa centralização torna mais fácil de manter e gerenciar.



5.3.1.5 Implantação

O padrão a ser seguido pela fábrica está descrito no link abaixo. DAOFactory.java • A interface do DAO, não deverá lançar exceptions especificas do Hibernate. Quando

necessário o lançamento de uma exception, deverá ser lançado DAOException.

• As querys sejam elas HSQL sejam SQL puro não podem ser concatenadas no código fonte. Ao invés disto deve ser utilizado o prepared statement ou então um formatador de strings através de parâmetros (parametrização de strings).

• Os nomes nos métodos das classes de acesso a dados (DAO) devem seguir as seguintes regras: + Qualquer método que faça uma pesquisa que retorne somente um elemento deve iniciar com a string “findBy”. O resto do método deve anunciar qual é o critério de pesquisa. Ex. findByPrimaryKey + Qualquer método que retorne uma coleção ou lista de entidades do banco de dados deve ser nomeada iniciando com a palavra “select”. O resto do método deve dizer as condições do select realizado caso haja. Ex. selectProjetosCadastrados; selectProjetosCadastradosPorMunicipios; selectObrasCadastradasDiretor.

• Cada entidade lógica deve possuir uma classe DAO, obedecendo a critérios de herança e o

pattern Template definido por Gamma (ver referência em 5.4.1.15).

5.3.2 Struts

5.3.2.1 Contexto

Nas aplicações Web a integração entre a camada de apresentação e de negócio é feita

através de mecanismos de controle, podendo ser gerenciados de forma centralizada ou

descentralizada. Outra necessidade é otimizar a transferência de dados entre as camadas.

5.3.2.2 Problema

As aplicações exigem um ponto de acesso que tratam as solicitações da camada de

apresentação para suportar a integração de serviços do sistema, recuperação de conteúdo,

gerenciamento e navegação de visualização. Quando não é utilizado um mecanismo centralizado,

dois problemas podem ocorrer:

• Cada visualização é solicitada a fornecer seus próprios serviços de sistema, resultando

freqüentemente em códigos duplicados.



• O controle distribuído é mais difícil de manter, visto que as alterações precisarão freqüentemente

ser feitas em diversos locais.

A transferência de dados entre a camada de apresentação e de negócio exige um esforço de

codificação, pois todos os campos devem ser preenchidos tanto no envio como no recebimento de

informações entre uma camada e outra.

5.3.2.3 Solução

O uso do Struts, framework baseado na arquitetura MVC fornece um ponto de entrada

centralizado que controla e gerencia o tratamento de solicitações da Web.

Centralizando pontos e controles de decisão, o Struts também ajuda a reduzir a quantidade

de códigos Java, denominada scriptlets, incluídos na JSP.

O controle centralizado reduz a lógica de negócios na visualização favorecendo a

reutilização de códigos através de solicitações. No Struts o controle é configurado através de arquivo

XML, não requerendo nenhum esforço de codificação nesta camada.

Para a transferência de dados entre a camada de apresentação e de negócio, o Struts

fornece uma infra-estrutura que simplifica o processo.

5.3.2.4 Benefícios

• Centraliza o controle: um controlador fornece um local central para tratar os serviços dos

sistemas e a lógica de negócios através de solicitações múltiplas. Ele gerencia o processamento

da lógica de negócios e o tratamento de solicitação. O acesso centralizado para uma aplicação

significa que as solicitações são facilmente rastreadas e acessadas.

• Melhora a capacidade de gerenciamento de segurança: Com o controle centralizado, é

promovido um ponto de restrição para tentativas de acessos ilícitos na aplicação.

5.3.3 Log de atividades do usuário a nível de aplicação

5.3.3.1 Contexto

Um erro intermitente é aquele que ocorre sem a possibilidade de reproduzi-lo através de uma simples navegação, sendo este conseqüência de um conjunto maior de atividades do usuário.

5.3.3.2 Problema

Definir o conjunto exato de atividades executadas que contribuíram para a degradação dos sistemas.



5.3.3.3 Solução

A utilização de um filtro para cada requisição realizando um log de informações tais como: - usuário logado - url requisitada - tempo da transação A classe de filtro está definida no pacote br.gov.ancine.commons.util.NavegationLogFilter dentro do projeto BiblioAncine. Para maiores informações sobre o uso ver javadoc da referida classe.

5.3.3.4 Benefícios

A utilização de um ponto central na aplicação para verificar quais são os caminhos utilizados que podem gerar uma exceção em tempo de execução prejudicando o serviço.

5.3.4 Tratamento de Exceções e Log de aplicação

5.3.4.1 Contexto

Exceções são desvios do fluxo normal durante a execução de programa. Toda exceção deve ser logada no sistema

5.3.4.2 Problema

Sem uma regra estabelecida para o tratamento de exceções e controle de logs, não há como

enumerar e controlar de forma adequada todas as variantes existentes.

5.3.4.3 Solução

Todas as exceções devem ser impressas no log, exibindo toda a sua “Stack Trace”. A seguir os passos para tratamentos de exceptions. Passo 1 => As exceptions geradas pelo Java, deverão ser lançadas até a última camada (Action). Passo 2 => As exceptions deverão ser mapeadas no "struts-config.xml". Ex.: <action path="/<seu_path>" type="br.gov.ancine.<nome_projeto>.web.action.<Sua_Class_Action><>" name="<nome_do_form>" scope="request" parameter="method" > <exception key="<chave_do_txt_no_"ApplicationResources.properties"> Ex.: mensagem.erro.cadastrousuario.usuarioCadastrado" type="<exception_gerada> Ex.: br.gov.ancine.controleacesso.ejb.exception.LoginEncontradoException" path="/jsp/msg/erro.jsp" /> <exception key="<chave_do_txt_no_"ApplicationResources.properties"> Ex.: mensagem.erro.exception" type="<exception_gerada> Ex.: java.lang.Exception" path="/jsp/msg/erro.jsp" /> </action> OBS.: O tratamento de exception "java.lang.Exception" é obrigatório, deverá sempre ser feito por último e em todas as Actions. Passo 3 => Ex.: <bean:define id="exceptionStackTrace" name="org.apache.struts.action.EXCEPTION" type="java.lang.Exception"/> <logic:notEmpty name="exceptionStackTrace">  </logic:notEmpty>

5.3.4.4 Benefícios

Utilizando essa solução o padrão é mantido no desenvolvimento, e no fluxo das exceções.

Em uma posterior manutenção o desenvolvedor não encontrará dificuldades para identificar

e corrigir o problema.



5.3.5 Segurança

5.3.5.1 Contexto

O Modelo de Segurança J2EE oferece diversas opções de segurança práticas e robustas,

desde uma simples Security Socket Layer (SSL) até mesmo ao controle de acesso a métodos de

Enterprise Java Beans (EJB) ou acesso à Servlets e Java Server Pages (JSP).

5.3.5.2 Problema

Em um ambiente computacional corporativo, existem muitos riscos de segurança para as

aplicações que estão em produção.

5.3.5.3 Solução

Definir um modelo de segurança único que atenda de forma otimizada, robusta e eficiente os

requisitos de segurança exigidos pela ANCINE. Para isso a aplicação deve ser aderente ao controle

de acesso e utilizar as taglibs definidas na biblioteca de controle de acesso, juntamente com a

biblioancine. Caso seja necessário adicionar alguma nova classe de segurança, documentar e

justificar.

5.3.5.4 Benefícios

• Controle de segurança totalmente declarativo através do uso de XML.

• Controle de autenticação e restrições de acesso à aplicação e seus componentes.

5.3.6 Convenção de Código Java

5.3.6.1 Contexto

Existem muitas maneiras de codificar uma aplicação.



5.3.6.2 Problema

Em uma equipe de desenvolvedores cada um tende a trabalhar à sua maneira tornando

uma posterior manutenção no código complicada, pois uma pessoa nem sempre consegue entender

de forma clara o que outra estava pensando no momento da fabricação do código.

5.3.6.3 Solução

No processo de utilização da linguagem Java existe diversos padrões que auxiliam o projeto

e o desenvolvimento de sistemas. A arquitetura adota o modelo MVC (Model-View-Controller)

abrangendo Struts, DAO (Persistência) utilizando o Hibernate e outros processos. Todo o esforço

para construir uma equipe e guiar seu processo de desenvolvimento no ciclo de vida é apresentado

como um padrão.

O empenho para se entregar tal produto chama-se projeto e o padrão de atividade dentro

da organização e dentro de seu projeto é chamado de processo aplicado. O padrão adotado para

convenção de codificação do projeto de sistema é o especificado pela Sun Microsystems (Anexo I),

podendo ser localizado no endereço: http://java.sun.com/docs/codeconv/ .

5.3.6.4 Benefícios

• Aumenta a legibilidade de código facilitando manutenção.

• Reduz tempo e esforço de treinamento.

• Nivela a linguagem de comunicação da equipe.

• Padroniza os recursos de pessoal aplicados.

5.3.7 Identificação de páginas dinâmicas.

5.3.7.1 Contexto

Atualmente com as novas tecnologias, as páginas jsps são dinâmicas.



5.3.7.2 Problema

Ao se depurar um erro visual na página ou quando se tem a necessidade de descobrir qual

a página jsp que deve ser alterada, muitas vezes por conta das novas tecnologias de jsp como struts

e jsf é mais difícil de encontrar exatamente qual a página que deve ser alterada para surtir o efeito

desejado da mudança.

5.3.7.3 Solução

Em cada página dinâmica da aplicação, deve-se inserir um comentário que não interfira no

código na primeira linha válida informando o nome da página. Este comentário deve ser visível para

consulta no browser ao se solicitar ao mesmo a visão do código fonte.

5.3.7.4 Benefícios

• Permite maior agilidade na identificação de erros em páginas HTMLs.

• Facilita a localização do código-fonte a ser alterado.



5.3.8 Convenção de Empacotamento de Classes

Visando uma melhor organização na classificação dos arquivos da aplicação a Sun

Microsystems criou o recurso de pacote, já implementado no Java 2. Esse recurso nos dá facilidade

de localizar, identificar e subentender o que cada fonte do aplicativo se propõe a fazer. Qualquer

pacote fora do padrão deve ser justificado.

A árvore de empacotamento adotada utilizando padrões universais, subdividido em pais,

organização, empresa, sistema e suas divisões:



5.3.9 Paginação

5.3.9.1 Contexto

A paginação de consultas do sistema é uma necessidade e pode ser realizada em várias

camadas diferentes, na model, na view ou na controller. Cada escolha tem prós e contra. Além disso,

a lógica de paginação é igual em todos os casos. Isto torna passível de utilizar um componente para

esta finalidade.

5.3.9.2 Problema

Em cada camada possível de ser responsável pela paginação, podemos encontrar prós e

contras. Através de estudos realizados e lições aprendidas, foi avaliado que a camada que

apresenta maior custo/benefícios ao realizar a paginação é a camada de model. Sendo assim fica

estabelecido que a paginação deve ser feita no Banco de dados.

5.3.9.3 Solução

A solução para a paginação é realizar a paginação no banco de dados. Deve ser feita a

paginação no banco de dados. Fica a critério do desenvolvedor como será feito isso. Entretanto

recomendamos utilizar as classes utilitárias disponibilizadas pela arquitetura da ANCINE.

5.3.9.4 Benefícios

• Menor consumo de memória ao prevenir instanciação de todos os objetos no Servidor de

Aplicação.



5.3.10 Padronização de Nomes

5.3.10.1 Nome de Classes, JSP e Actions

• NomeDaAcaoNomeDoCasoDeUsoAction.java

• NomeDaAcaoNomeDoCasoDeUsoForm.java

• nomeDaAcaoNomeDoCasoDeUso.jsp

• nomeDaAcaoECE.do

OBS: nome da ação + nome do caso de uso abreviado com todas as letras em caixa-alta.

Exemplos de ações:

Cadastrar, pesquisar, alterar, habilitar, selecionar, apagar, emitir, etc.

Exemplos de abreviações:

• pesquisarECE.do => pesquisar empresa contribuinte estrangeira.

• selecionarEENO => selecionar empresa estrangeira não optante.

5.3.10.2 Estrutura de Diretórios

• /jsp

• /jsp/nomeDoCasoDeUso

• /jsp/include

• /jsp/msg

5.3.10.3 Datasources

Os datasources utilizados para acessar o banco de dados devem conter as iniciais

“ds.”+nome da aplicação ex.: ds.controleacesso os datasources utilizam classes jdbc fornecidas

pela oracle junto com o seu client 9i o “ojdbc14.jar”. Utilizaremos o datasouce do Jboss utilizando o

arquivo oracle-ds.xml.

5.3.10.4 Manipulação de Dados

Todos os dados inseridos, atualizados e consultados nas Aplicações devem ser em

caixa alta “UPPERCASE”. As consultas de dados do tipo “caractere” podem ser feitas em

“case-insensitive”, devendo ser convertida na aplicação em UPPERCASE para poder realizar a

consulta.



5.3.11 Framework Ancine de Processamento Batch

5.3.11.1 Contexto

Existem algumas atividades dentro de uma aplicação que necessita de um processamento em um tempo mais longo, e muitas vezes não precisa de uma interação direta com o usuário. Para tais tipos de processamentos que podem onerar a CPU do servidor de aplicação principal deve se separar estas atividades da aplicação principal.

5.3.11.2 Problema

Um dos principais problemas referentes a este tipo de processamento de aplicação é o fato da mesma geralmente ocupar grande parcela da CPU do sistema e sob o aspecto da arquitetura da aplicação, estar diretamente dependente da operação do servidor de aplicação. Um problema acarretado por isso é, por exemplo, o envio de e-mail fica comprometido caso o servidor de aplicação tenha que ser parado.

5.3.11.3 Solução

Caso seja necessário realizar algum processamento batch pelas aplicações em um servidor de aplicação java, deve ser utilizado o framework Ancine de processamento batch. A idéia é separar o processamento batch das aplicações Java.

5.3.11.4 Benefícios

Independência dos procedimentos batch para com o servidor de aplicação.

5.3.12 Recepção de novos desenvolvimentos

Um dos problemas recorrentes da ANCINE é realizar o rápido mapeamento entre as

funcionalidades implementadas pelo caso de uso e seus correspondentes artefatos. Mesmo o

desenvolvedor de apoio localizado na ANCINE ou qualquer interessado em mapear rapidamente as

mudanças necessárias em cada caso de uso despende de grande tempo para entender onde cada

elemento de qual caso de uso está.

Para solucionar tal problema a solução adotada é a criação de um diagrama de componente

para cada caso de uso implementado. Tal diagrama deve informar quais componentes ele utiliza para a

execução de seu trabalho. A partir da leitura deste, deve ser claro quais EJB, páginas, Actions, DAOs e

outros elementos são utilizados.

Na atividade de recebimento de produtos do processo de gerência de software da ANCINE,

juntamente com o código-fonte do aplicativo deve ser enviado o conjunto de diagramas que representam

para cada caso de uso, os artefatos utilizados.



Abaixo segue um exemplo de diagrama de componentes que deve ser seguido:

5.3.13 Requisitos de software para release de produção.

A gerência de arquitetura de sistemas e qualidade da ANCINE tem como parâmetro de

qualidade para passagem de um sistema para o ambiente de produção que os sistemas devem

obedecer às seguintes especificações:

1. A utilização do sistema em produção sob condições de configurações corretas da aplicação não

deve gerar exceção.

2. Uma funcionalidade qualquer não deve exceder o tempo de execução de 20.000 milissegundos.

Caso por algum motivo como processamento intensivo, cálculos complexos ou envio de e-mails

deve ser documentada previamente tal funcionalidade e comunicada à equipe de arquitetura

para verificação da melhor implementação possível. (Considerar processamento intensivo,

algoritmos que possuam uma complexidade maior que O(n)).

3. Fica a cargo do pessoal de homologação avaliar os itens acima.



5.4 Requisitos não funcionais para recebimento de software da fábrica.

A gerência de arquitetura de sistemas e qualidade da ANCINE tem como parâmetro de

qualidade para passagem de um sistema para o ambiente de desenvolvimento da ANCINE através do

fornecimento do código-fonte. Este deve vir da referida fábrica de software contendo:

1. Instrução de instalação quando possuir alguma especificidade que justifique.

2. Código fonte da aplicação.

3. Scripts necessários para a configuração inicial da aplicação, quando necessário.

4. Arquivos de parâmetros e propriedades da aplicação, necessários para o funcionamento do

sistema, quando pertinente.

5. Arquivos e scripts necessários para a montagem e empacotamento da aplicação.

5.4.1 Pré-requisitos Gerais.

5.4.1.1 Não serão permitidos métodos deprecate.

5.4.1.2 Não serão permitidas regras de negócio nas Actions.

5.4.1.3 Toda BO deverá ter uma interface e será instanciada a partir de uma BOFactory.java.

5.4.1.4 A classe DAOFactory, deverá ser: DAOFactory.java.

5.4.1.5 A classe BOFactory, deverá ser: BOFactory.java.

5.4.1.6 Todas as críticas de valores obrigatórios deverão ser feitas com javascript, mas as

mesmas também deverão existir na camada de BO.

5.4.1.7 Tais regras que utilizarem javascript, deverão ser feitas a partir do validation.xml do Struts.

5.4.1.8 É proibido o uso de scriptlet, devendo utilizar Tags do Struts e JSTL.

5.4.1.9 Todas as exceptions geradas pela camada de BO, deverão ser encapsuladas em uma

exception do tipo BOException. Lembrando que a exception original deverá sempre ser

passada no construtor da classe para que mantenhamos a stacktrace atualizada.

5.4.1.10 Deverá haver controle de Lock Otimista para classes de cadastramento e caso seja

levantado uma exceção, o usuário deverá receber uma mensagem: “Os dados desse registro

já estão sendo atualizados pelo usuário: ” + var_NomeLogin. O tratamento desta exceção

deverá manter os mesmos dados digitados pelo usuário nos campos das páginas a fim de

oferecer uma nova tentativa de confirmação sem que o usuário tenha de repetir a digitação.

As páginas dos Sistemas desenvolvidos devem implementar uma solução de TOKEN para impedir a submissão repetitiva das mesmas. Um exemplo de código pode ser encontrado no livro Core J2EE patterns, também disponível no site da SUN pelo link: http://java.sun.com/blueprints/patterns/. Existe uma implementação de exemplo da proposta de refactoring “synchronizer token”, provida pela equipe de arquitetura da ANCINE na biblioteca de objetos ANCINE. Para maiores informações verificar o Javadoc da biblioteca.

5.4.1.11 As páginas devem desabilitar o botão de submissão de página após ser pressionado, a

fim de impedir que a mesma página seja solicitada mais de uma vez. Isto deve ser realizado

na camada de apresentação.



5.4.1.12 As telas que realizam pesquisas em campos tipo String, como por exemplo, “nome da

obra” devem validar o campo de pesquisa em questão para esta conter no mínimo três

caracteres. Isto serve para evitar pesquisas intensas como, por exemplo, pesquisar todas as

obras que tenham a letra “A” no nome.

5.4.1.13 Todos os sistemas desenvolvidos devem seguir os padrões propostos pela SUN. Estes

podem ser encontrados no seguinte site: http://java.sun.com/blueprints/patterns/

5.4.1.14 Na modelagem dos sistemas, devem ser levados em consideração os patterns propostos

pelo GOF (Gang Of Four) localizados no livro:

GAMMA, Erich

HELM, Richard

JOHNSON, Ralph

VILISSIDES, John

Padrões de Projeto: soluções reutilizáveis de software orientados a objetos

Bookman, Porto Alegre, 2000

5.4.1.15 Todas as exceptions geradas pela camada de DAO, deverão ser encapsuladas em uma

exception do tipo DAOException. Lembrando que a exception original deverá sempre ser

passada no construtor da classe para que mantenhamos a stacktrace atualizada.

5.4.1.16 Toda regra escrita em um BO, deverá seguir a seguinte ordem:

+Instanciar CLASS necessárias;

+Validar campos que fazem parte do processo;

+Processar regra de negocio

+Lançar possíveis exceptions geradas, incluindo na string de texto da exceção, o Nome do

Sistema, o método executado e parâmetro passado se houver.

5.4.1.17 Quando houver Agregação ou Associação no Hibernate, deverá ser habilitado o recurso

“LAZY”.

5.4.1.18 Não vamos aplicar o Pattern Facade, pois o BO desempenha o papel do mesmo.

5.4.1.19 Quando uma regra X de um determinado BO1 tiver como pré-condição ou pós-condição

uma regra Y pertencente a um BO2, o BO1 pode fazer referência ao BO2 para cumprir a pré-

condição ou pós-condição. Com isso estaremos estabelecendo um relacionamento entre

BOs. Isto não significa que, não podemos instanciar dois BOs dentro de uma mesma Action.

Se para executar uma ação (Action), seja necessário mais de um BO com objetivos

totalmente diferentes e independentes, este é um caso que se assume duas instancias de

BOs diferentes na mesma Action.

5.4.1.20 Existe uma biblioteca de métodos comuns que deverá ser fornecida à fábrica de software

e consultada antes de se criar métodos de apoio às aplicações. Sua localização e nome são:

../server/default/lib/ancine-commons.jar.

5.4.1.21 Deixamos como sugestão a utilização da JPA como camada de persistência junto com o

aproveitamento do recurso “Annotations” nas classes POJO´s para o mapeamento objeto-

relacional.



5.4.1.22 Não é permitido métodos vazios ou que retornam null não executando nenhum

processamento. Entenda-se por processamento código que realize alguma operação que

agregue funcionalidade à aplicação.

5.4.1.23 Para as páginas de listagem de entidades é necessária a utilização de objetos POJOs

para o preenchimento das mesmas. Nestes devem existir somente os campos a serem

exibidos na tela, não pode ter referências a outros objetos e não pode ter nenhum campo

lazy. Paralelamente estes objetos devem ser mapeados para views correspondentes com os

campos a serem exibidos na tela.

5.4.1.24 Todos os erros de banco de dados referentes à primary key, foreing key e unique key

devem ser tratados na aplicação e exibir retorno ao usuário explicando o problema com o

código do erro.



5.5 Diagrama de Divisão de Camadas



5.6 Diagrama de Seqüência de Implementação

JSP/Tags(View) ActionServlet ActionForm ActionX Transfer ObjectBusiness Object

DAO Database

post/get

validar

dados validados

execute

dados



6. Visão de Distribuição

Não se aplica neste documento.

7. Requisitos e Restrições da Arquitetura


8. Referências


9. Assinaturas

Os abaixo assinados estão de acordo com o conteúdo do documento “Projeto de Arquitetura”.

Data: ___/___/_____

Data: ___/___/_____

Sergio Augusto Santos de Moraes

Coordenador Técnico

GTI

Roberto Souza de Holanda

Coordenador Técnico

GTI

Data: ___/___/_____

Data: ___/___/_____

Carlos Júlio Ferreira Alferes

Arquiteto de Sistemas

GTI

Leandro Paranhos Carvalho de Souza

Arquiteto de Sistemas

GTI

arquitetura de software - ancineancine.gov.br/media/projeto_arquitetura_software_v_1_15.pdf ·...

Documents