Post on 08-Nov-2018
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............................................................................................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
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 Tecnologia da 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 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.
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 na aplicaçã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 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.
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