Projeto Arquitetura Software v 1 15

Prévia do material em texto

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 
 
 
 
 
 
 
 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 2/29 
 
 
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 
15/02/2006 1.3 
Descrição da atividade realizada no 
documento. 
Flávio Junior 
05/03/2006 1.4 
Descrição da atividade realizada no 
documento. 
Flávio Junior 
17/04/2006 1.5 
Descrição da atividade realizada no 
documento. 
Flávio Junior 
19/06/2006 1.6 
Descrição da atividade realizada no 
documento. 
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 
 
 
 
 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 3/29 
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 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 4/29 
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............................................................................................165.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 
 
 
 
 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 5/29 
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 
 
 
 
 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 6/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. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 7/29 
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 
 
 
 
 
 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologiada Informação Projeto de Arquitetura de Software Página 8/29 
 
 
 
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. 
 
 
 
 
 
 
 
 
 
 
 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 9/29 
 
 
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. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 10/29 
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. 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 11/29 
 
 
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 camadaseparada: 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. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 12/29 
 
 
 
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. 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 13/29 
 
• 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. 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 14/29 
 
 
 
 
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. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 15/29 
 
 
 
 
 
 
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"> 
 <!-- 
 <% exceptionStackTrace.printStackTrace(new java.io.PrintWriter(out));%>--> 
 </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.
 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 16/29 
 
 
 
 
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. 
 
 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 17/29 
 
 
 
 
 
 
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. 
 
 
 
 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 18/29 
 
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.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 19/29 
 
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: 
 
 
 
 
 
 
 
 
 
 
 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 20/29 
 
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. 
 
 
 
 
 
 
 
 
 
 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 21/29 
 
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 naaplicação em UPPERCASE para poder realizar a 
consulta. 
 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 22/29 
 
 
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. 
 
 
 
 
 
 
 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 23/29 
 
 
 
 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. 
 
 
 
 
 
 
 
 
 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 24/29 
 
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. 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 25/29 
 
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 daclasse 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. 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 26/29 
 
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. 
 
 
 
 
 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 27/29 
 
 
5.5 Diagrama de Divisão de Camadas 
 
 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 28/29 
 
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
 
 
 
 
 
 
 
 
 
Secretaria de Gestão Interna 
Gerência de Tecnologia da Informação Projeto de Arquitetura de Software Página 29/29 
 
6. Visão de Distribuição 
Não se aplica neste documento. 
 
7. Requisitos e Restrições da Arquitetura 
Não se aplica neste documento. 
 
8. Referências 
Não se aplica neste documento. 
 
 
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