Você está na página 1de 29

Secretaria de Gesto Interna

Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 1/29







Projeto de Arquitetura de Software










Verso do Documento: 1.15









Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 2/29


Histrico de Reviso

Data
Verso do
Documento
Descrio Autor
1.1
Descrio da atividade realizada no
documento.
Rodolfo Lace
06/01/2006 1.2
Descrio da atividade realizada no
documento.
Flvio Junior
15/02/2006 1.3
Descrio da atividade realizada no
documento.
Flvio Junior
05/03/2006 1.4
Descrio da atividade realizada no
documento.
Flvio Junior
17/04/2006 1.5
Descrio da atividade realizada no
documento.
Flvio Junior
19/06/2006 1.6
Descrio da atividade realizada no
documento.
Flvio Junior / Miguel Garz
29/07/2006 1.7
Atualizao de elementos
arquiteturais: DisplayTag
Miguel Garz / Flvio Junior
29/08/2006 1.8
Atualizao de elementos de boas
prticas: Concatenao de query
Miguel Garz/ Flvio Junior
29/09/2006 1.9
Atualizao das verses dos
frameworks utilizados
Miguel Garz / Flvio Junior
29/10/2006 1.10
Insero do requerimento de log de
navegao
Miguel Garz / Daniel Bernd
16/11/2006 1.11
Insero de requisitos de qualidade
para sistemas em produo.

Miguel Garz / Daniel Bernd
13/12/2006 1.12
Insero de boas prticas e
requisitos de usabilidade
referentes a problemas de dupla
submisso de formulrios.

Insero do Ancine Batch
Processing Framework

Atualizao dos requisitos para
recebimento de sistema.
Miguel Garz/ Daniel Bernd






Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 3/29
06/08/2007 1.13
Atualizao dos requisitos da
fbrica de software
Miguel Garz /
Douglas Matheus
14/09/2007 1.14
Atualizao de algumas regras
aps avaliao do SALIC e
Fiscalizao 1.3
- Forma de listagem
- Nomes de mtodos na camada
DAO.
Miguel Garz / Douglas
Matheus
23/10/2008 1.15
Atualizao das verses das
tecnologias utilizadas
Carlos Alferes
























Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 4/29
Sumrio

1. Introduo............................................................................................................................................6
2. Representao da Arquitetura...........................................................................................................6
3. Viso de Lgica...................................................................................................................................6
4. Viso de Implantao .........................................................................................................................7
5. Viso de Implementao....................................................................................................................7
5.1 Introduo..............................................................................................................8
5.2 Modelagem do diagrama de seqncia .................................................................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 Soluo .....................................................................................................................10
5.3.1.4 Benefcios .................................................................................................................11
5.3.1.5 Implantao ..............................................................................................................12
5.3.2 Struts ................................................................................................................................12
5.3.2.1 Contexto....................................................................................................................12
5.3.2.2 Problema...................................................................................................................12
5.3.2.3 Soluo .....................................................................................................................13
5.3.2.4 Benefcios .................................................................................................................13
5.3.3 Log de atividades do usurio a nvel de aplicao...................................................13
5.3.3.1 Contexto ...................................................................................................................13
5.3.3.2 Problema...................................................................................................................13
5.3.3.3 Soluo .....................................................................................................................14
5.3.3.4 Benefcios .................................................................................................................14
5.3.4 Tratamento de Excees e Log de aplicao...........................................................14
5.3.4.1 Contexto....................................................................................................................14
5.3.4.2 Problema...................................................................................................................14
5.3.4.3 Soluo .....................................................................................................................15
5.3.4.4 Benefcios .................................................................................................................15
5.3.5 Segurana ........................................................................................................................16
5.3.5.1 Contexto....................................................................................................................16
5.3.5.2 Problema...................................................................................................................16
5.3.5.3 Soluo .....................................................................................................................16
5.3.5.4 Benefcios .................................................................................................................16
5.3.6 Conveno de Cdigo Java............................................................................................16
5.3.6.1 Contexto....................................................................................................................16
5.3.6.2 Problema...................................................................................................................17
5.3.6.3 Soluo .....................................................................................................................17
5.3.6.4 Benefcios .................................................................................................................17
5.3.7 Identificao de pginas dinmicas. .............................................................................17
5.3.7.1 Contexto....................................................................................................................17
5.3.7.2 Problema...................................................................................................................18
5.3.7.3 Soluo .....................................................................................................................18
5.3.7.4 Benefcios .................................................................................................................18
5.3.8 Conveno de Empacotamento de Classes.............................................................19






Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 5/29
5.3.9 Paginao.........................................................................................................................20
5.3.9.1 Contexto....................................................................................................................20
5.3.9.2 Problema...................................................................................................................20
5.3.9.3 Soluo .....................................................................................................................20
5.3.9.4 Benefcios .................................................................................................................20
5.3.10 Padronizao de Nomes.................................................................................................21
5.3.10.1 Nome de Classes, JSP e Actions .............................................................................21
5.3.10.2 Estrutura de Diretrios..............................................................................................21
5.3.10.3 Datasources..............................................................................................................21
5.3.10.4 Manipulao 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 Soluo .....................................................................................................................22
5.3.11.4 Benefcios .................................................................................................................22
5.3.12 Recepo de novos desenvolvimentos ....................................................................22
5.3.13 Requisitos de software para release de produo. ..................................................23
5.4 Requisitos no funcionais para recebimento de software da fbrica. ......................24
5.4.1 Pr-requisitos Gerais. ...............................................................................................24
5.5 Diagrama de Diviso de Camadas....................................................................... 27
5.6 Diagrama de Seqncia de Implementao ........................................................ 28
6. Viso de Distribuio .......................................................................................................................29
7. Requisitos e Restries da Arquitetura .........................................................................................29
8. Referncias........................................................................................................................................29
9. Assinaturas........................................................................................................................................29






Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 6/29
Projeto de Arquitetura

1. Introduo
Este documento apresenta a arquitetura proposta para todos os sistemas ANCINE. A
arquitetura apresentada atravs de um conjunto de vises que juntas visam cobrir os principais
aspectos tcnicos relativos ao desenvolvimento e implantao dos sistemas. O objetivo capturar
e formalizar as principais decises tomadas com relao arquitetura dos sistemas.

2. Representao da Arquitetura
A arquitetura dos sistemas representada atravs das seguintes vises arquiteturais:
Viso de Lgica;
Viso de Implantao;
Viso de Implementao;
Viso de Distribuio [utilizar esta viso somente se ela for aplicvel ao projeto].

3. Viso de Lgica
No se aplica neste documento. Toda viso lgica a ser implementada ser anexada: definio
do sistema, caso de uso, diagrama de classe e de seqncia.
























Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 7/29
4. Viso de Implantao


5. Viso de Implementao
Esta viso prov como os componentes sero distribudos em suas camadas. Est dividido em
dois diagramas, um de diviso de camadas, e outro de seqncia de implementao.
Foram adotadas essas camadas, para facilitar na implementao, delegar as atividades de uma
forma correta, atendendo os padres da arquitetura, tornando assim um sistema de fcil
manuteno. Para cada objeto de negcio, ser implementado um componente por camada. Todos
os sistemas da ANCINE so baseados na tecnologia Java, sendo utilizada atualmente a verso 1.5.
A verso do servidor de aplicao JBoss utilizada a 4.0.3SP1 e a verso do banco de dados
Oracle Enterprise utilizada 9.2.0.7.0.

















-Beans
-Struts & extenses
-Hibernate
-Helpers


<< Jdbc >>
-Javascript
-AJAX

App Server (Jboss) Oracle Enterprise







Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 8/29



5.1 Introduo

Visando atender uma necessidade de fcil criao, manuteno e a separao das camadas
do aplicativo. Adotamos o padro de projeto Model - View - Controller (MVC), para a plataforma
Java.

Estrutura do MVC:




Esta separao permite que mltiplos visualizadores compartilhem o mesmo modelo de dados, com
isso o suporte a diferentes tipos de usurios mais fcil de implementar, testar e manter.

Camada de Negcio ( Model ) representa os dados corporativos e as regras de negcio que
governam o acesso e a atualizao desses dados. Utilizaremos nessa camada os padres: Data
Access Object (DAO) que na nossa arquitetura utilizamos a ferramenta Hibernate na veso 3.1.3
Para acesso a dados, Transfer Object (TO), Busisness Object (BO), Actions e DispacthActions.

Camada de Apresentao ( View ) exibe o contedo de um modelo ao usurio. Nesta camada so
utilizados Java Server Pages (JSPs) , TagLib(TagStruts) para a gerao do cdigo HTML.

Camada de Controle ( Controller ) transfere as interaes entre a camada de apresentao e o
que deve ser executado pela camada de modelo. Nesta camada usamos o framework Struts / XML.













Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 9/29


5.2 Modelagem do diagrama de seqncia

A principal funo do diagrama de seqncia 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 discusses sobre a abrangncia da quantidade e forma de informaes
que devem estar contidas no diagrama de seqncia. Estudiosos como Martin Fowler define trs nveis
diferentes de utilizao de um diagrama UML: Utilizao como rascunho, Utilizao como planta-baixa e
utilizao como linguagem de programao. (Ver mais em:
http://www.martinfowler.com/bliki/UmlMode.html e http://www-
128.ibm.com/developerworks/rational/library/3101.html).
Ns da ANCINE decidimos por adotar a abordagem do diagrama de seqncia de implementao
como uma planta-baixa do caso de uso. Isto significa que o diagrama de seqncia deve refletir a
implementao de chamadas s classes do sistema de modo que o programador, ao receber o diagrama
de seqncia deva somente se preocupar em preencher a lgica dos mtodos e no a criao dos
mtodos.

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 implementao do fornecedor.














Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 10/29
5.3.1.2 Problema

Muitas aplicaes J2EE do mundo real precisam utilizar dados persistentes em algum
momento. Para muitas aplicaes, o armazenamento persistente implementado com mecanismos
diferentes e h diferenas marcantes nas APIs utilizadas para acess-las. Outras aplicaes talvez
precisem acessar dados que residem em sistemas separados. Por exemplo, os dados podem residir
em um sistema mainframe, em repositrios de Lightweight Directory Access Protocol (LDAP).
H uma variao 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 aplicaes que precisam acessar dados de um sistema legado ou diferente (como um
mainframe ou um servio B2B) so freqentemente obrigadas a utilizar APIs que podem ser
exclusivas.
Dessa maneira, origens de dados diferentes oferecem desafios aplicao e podem
potencialmente criar uma dependncia direta entre o cdigo da aplicao e cdigo de acesso a
banco de dados. Quando componentes de negcios beans de entidade, beans de sesso e ainda
componentes de apresentao 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 cdigo de acesso de dados dentro
desses componentes introduz um acoplamento estrito entre os componentes e a implementao da
origem de dados. Assim as dependncias de cdigos em componentes tornam a migrao da
aplicao de um tipo de origem de dados para outro difcil 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 Soluo

O uso do Hibernate um framework Open-Source que oferece uma gama de facilidades e
agilidade no desenvolvimento da camada de persistncia. 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 cdigo, alm 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 operao de persistncia, sua implementao permite o uso de qualquer banco de dados.
A utilizao de drivers JDBC para fazer a comunicao com o RDBMS sem qualquer alterao na
aplicao. Por isso optamos por utilizar esse framework como padres para os projetos ANCINE.


Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 11/29


5.3.1.4 Benefcios

Permite a transparncia: Os objetos de negcios podem utilizar a origem de dados sem
conhecer os detalhes especficos da implementao da origem de dados. O acesso
transparente porque os detalhes da implementao esto ocultos dentro do DAO.

Permite a migrao mais Fcil: Uma camada de DAOs torna mais fcil para uma aplicao
migrar para uma implementao de banco de dados diferente. Os objetos de negcios no tm
nenhum conhecimento da implementao de dados subjacente. Assim, a migrao envolve
alteraes apenas para a camada de DAO, alm disso, e empregar uma estratgia possvel
fornecer uma implementao de factory concreta para cada implementao de
armazenamento subjacente. Nesse caso, a migrao para uma implementao de
armazenamento diferente significa fornecer uma nova implementao de factory para a
aplicao.

Reduz a complexidade dos cdigos nos objetos de negcios: Como os DAOs gerenciam
todas as complexidades de acesso a dados, simplifica os cdigos nos objetos de negcios e
outros clientes de dados que utilizem os DAOs. Todas as implementaes relativas a cdigos
(como declaraes SQL) esto contidas no DAO e no no objeto de negcios. Com isso a
legibilidade dos cdigos juntamente com a produtividade do desenvolvimento melhorada.

Centraliza todo acesso de dados em uma camada separada: Como todas as operaes de
acesso a dados esto agora delegadas aos DAOs, a camada de acesso a dados separada pode
ser visualizada como a camada que pode isolar o resto da aplicao da implementao de
acesso a dados. Essa centralizao torna mais fcil de manter e gerenciar.



















Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 12/29



5.3.1.5 Implantao

O padro a ser seguido pela fbrica est descrito no link abaixo.

DAOFactory.java

A interface do DAO, no dever lanar exceptions especificas do Hibernate. Quando
necessrio o lanamento de uma exception, dever ser lanado DAOException.

As querys sejam elas HSQL sejam SQL puro no podem ser concatenadas no cdigo fonte. Ao
invs disto deve ser utilizado o prepared statement ou ento um formatador de strings atravs de
parmetros (parametrizao de strings).

Os nomes nos mtodos das classes de acesso a dados (DAO) devem seguir as seguintes regras:

+ Qualquer mtodo que faa uma pesquisa que retorne somente um elemento deve iniciar com a
string findBy. O resto do mtodo deve anunciar qual o critrio de pesquisa. Ex.
findByPrimaryKey

+ Qualquer mtodo que retorne uma coleo ou lista de entidades do banco de dados deve ser
nomeada iniciando com a palavra select. O resto do mtodo deve dizer as condies do select
realizado caso haja. Ex. selectProjetosCadastrados; selectProjetosCadastradosPorMunicipios;
selectObrasCadastradasDiretor.

Cada entidade lgica deve possuir uma classe DAO, obedecendo a critrios de herana e o
pattern Template definido por Gamma (ver referncia em 5.4.1.15).

5.3.2 Struts


5.3.2.1 Contexto

Nas aplicaes Web a integrao entre a camada de apresentao e de negcio feita
atravs de mecanismos de controle, podendo ser gerenciados de forma centralizada ou
descentralizada. Outra necessidade otimizar a transferncia de dados entre as camadas.


5.3.2.2 Problema

As aplicaes exigem um ponto de acesso que tratam as solicitaes da camada de
apresentao para suportar a integrao de servios do sistema, recuperao de contedo,
gerenciamento e navegao de visualizao. Quando no utilizado um mecanismo centralizado,
dois problemas podem ocorrer:

Cada visualizao solicitada a fornecer seus prprios servios de sistema, resultando
freqentemente em cdigos duplicados.


Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 13/29

O controle distribudo mais difcil de manter, visto que as alteraes precisaro freqentemente
ser feitas em diversos locais.

A transferncia de dados entre a camada de apresentao e de negcio exige um esforo de
codificao, pois todos os campos devem ser preenchidos tanto no envio como no recebimento de
informaes entre uma camada e outra.

5.3.2.3 Soluo

O uso do Struts, framework baseado na arquitetura MVC fornece um ponto de entrada
centralizado que controla e gerencia o tratamento de solicitaes da Web.
Centralizando pontos e controles de deciso, o Struts tambm ajuda a reduzir a quantidade
de cdigos Java, denominada scriptlets, includos na JSP.
O controle centralizado reduz a lgica de negcios na visualizao favorecendo a
reutilizao de cdigos atravs de solicitaes. No Struts o controle configurado atravs de arquivo
XML, no requerendo nenhum esforo de codificao nesta camada.
Para a transferncia de dados entre a camada de apresentao e de negcio, o Struts
fornece uma infra-estrutura que simplifica o processo.

5.3.2.4 Benefcios

Centraliza o controle: um controlador fornece um local central para tratar os servios dos
sistemas e a lgica de negcios atravs de solicitaes mltiplas. Ele gerencia o processamento
da lgica de negcios e o tratamento de solicitao. O acesso centralizado para uma aplicao
significa que as solicitaes so facilmente rastreadas e acessadas.

Melhora a capacidade de gerenciamento de segurana: Com o controle centralizado,
promovido um ponto de restrio para tentativas de acessos ilcitos na aplicao.


5.3.3 Log de atividades do usurio a nvel de aplicao

5.3.3.1 Contexto

Um erro intermitente aquele que ocorre sem a possibilidade de reproduzi-lo atravs de uma
simples navegao, sendo este conseqncia de um conjunto maior de atividades do usurio.

5.3.3.2 Problema

Definir o conjunto exato de atividades executadas que contriburam para a degradao dos
sistemas.


Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 14/29




5.3.3.3 Soluo

A utilizao de um filtro para cada requisio realizando um log de informaes tais como:
- usurio logado
- url requisitada
- tempo da transao

A classe de filtro est definida no pacote br.gov.ancine.commons.util.NavegationLogFilter
dentro do projeto BiblioAncine. Para maiores informaes sobre o uso ver javadoc da referida
classe.


5.3.3.4 Benefcios

A utilizao de um ponto central na aplicao para verificar quais so os caminhos utilizados
que podem gerar uma exceo em tempo de execuo prejudicando o servio.



5.3.4 Tratamento de Excees e Log de aplicao

5.3.4.1 Contexto

Excees so desvios do fluxo normal durante a execuo de programa. Toda exceo deve
ser logada no sistema


5.3.4.2 Problema

Sem uma regra estabelecida para o tratamento de excees e controle de logs, no h como
enumerar e controlar de forma adequada todas as variantes existentes.


















Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 15/29






5.3.4.3 Soluo

Todas as excees 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, devero ser lanadas at a ltima camada (Action).
Passo 2 => As exceptions devero 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" obrigatrio, 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 Benefcios

Utilizando essa soluo o padro mantido no desenvolvimento, e no fluxo das excees.
Em uma posterior manuteno o desenvolvedor no encontrar dificuldades para identificar
e corrigir o problema.



Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 16/29




5.3.5 Segurana


5.3.5.1 Contexto

O Modelo de Segurana J2EE oferece diversas opes de segurana prticas e robustas,
desde uma simples Security Socket Layer (SSL) at mesmo ao controle de acesso a mtodos 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 segurana para as
aplicaes que esto em produo.


5.3.5.3 Soluo

Definir um modelo de segurana nico que atenda de forma otimizada, robusta e eficiente os
requisitos de segurana exigidos pela ANCINE. Para isso a aplicao deve ser aderente ao controle
de acesso e utilizar as taglibs definidas na biblioteca de controle de acesso, juntamente com a
biblioancine. Caso seja necessrio adicionar alguma nova classe de segurana, documentar e
justificar.


5.3.5.4 Benefcios

Controle de segurana totalmente declarativo atravs do uso de XML.
Controle de autenticao e restries de acesso aplicao e seus componentes.


5.3.6 Conveno de Cdigo Java


5.3.6.1 Contexto

Existem muitas maneiras de codificar uma aplicao.




Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 17/29






5.3.6.2 Problema

Em uma equipe de desenvolvedores cada um tende a trabalhar sua maneira tornando
uma posterior manuteno no cdigo complicada, pois uma pessoa nem sempre consegue entender
de forma clara o que outra estava pensando no momento da fabricao do cdigo.


5.3.6.3 Soluo

No processo de utilizao da linguagem Java existe diversos padres que auxiliam o projeto
e o desenvolvimento de sistemas. A arquitetura adota o modelo MVC (Model-View-Controller)
abrangendo Struts, DAO (Persistncia) utilizando o Hibernate e outros processos. Todo o esforo
para construir uma equipe e guiar seu processo de desenvolvimento no ciclo de vida apresentado
como um padro.
O empenho para se entregar tal produto chama-se projeto e o padro de atividade dentro
da organizao e dentro de seu projeto chamado de processo aplicado. O padro adotado para
conveno de codificao do projeto de sistema o especificado pela Sun Microsystems (Anexo I),
podendo ser localizado no endereo: http://java.sun.com/docs/codeconv/ .


5.3.6.4 Benefcios

Aumenta a legibilidade de cdigo facilitando manuteno.
Reduz tempo e esforo de treinamento.
Nivela a linguagem de comunicao da equipe.
Padroniza os recursos de pessoal aplicados.


5.3.7 Identificao de pginas dinmicas.


5.3.7.1 Contexto

Atualmente com as novas tecnologias, as pginas jsps so dinmicas.






Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 18/29

5.3.7.2 Problema

Ao se depurar um erro visual na pgina ou quando se tem a necessidade de descobrir qual
a pgina jsp que deve ser alterada, muitas vezes por conta das novas tecnologias de jsp como struts
e jsf mais difcil de encontrar exatamente qual a pgina que deve ser alterada para surtir o efeito
desejado da mudana.


5.3.7.3 Soluo

Em cada pgina dinmica da aplicao, deve-se inserir um comentrio que no interfira no
cdigo na primeira linha vlida informando o nome da pgina. Este comentrio deve ser visvel para
consulta no browser ao se solicitar ao mesmo a viso do cdigo fonte.

5.3.7.4 Benefcios

Permite maior agilidade na identificao de erros em pginas HTMLs.
Facilita a localizao do cdigo-fonte a ser alterado.






























Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 19/29

5.3.8 Conveno de Empacotamento de Classes



Visando uma melhor organizao na classificao dos arquivos da aplicao 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 prope a fazer. Qualquer
pacote fora do padro deve ser justificado.
A rvore de empacotamento adotada utilizando padres universais, subdividido em pais,
organizao, empresa, sistema e suas divises:













Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 20/29

5.3.9 Paginao


5.3.9.1 Contexto

A paginao de consultas do sistema uma necessidade e pode ser realizada em vrias
camadas diferentes, na model, na view ou na controller. Cada escolha tem prs e contra. Alm disso,
a lgica de paginao igual em todos os casos. Isto torna passvel de utilizar um componente para
esta finalidade.


5.3.9.2 Problema

Em cada camada possvel de ser responsvel pela paginao, podemos encontrar prs e
contras. Atravs de estudos realizados e lies aprendidas, foi avaliado que a camada que
apresenta maior custo/benefcios ao realizar a paginao a camada de model. Sendo assim fica
estabelecido que a paginao deve ser feita no Banco de dados.


5.3.9.3 Soluo

A soluo para a paginao realizar a paginao no banco de dados. Deve ser feita a
paginao no banco de dados. Fica a critrio do desenvolvedor como ser feito isso. Entretanto
recomendamos utilizar as classes utilitrias disponibilizadas pela arquitetura da ANCINE.


5.3.9.4 Benefcios

Menor consumo de memria ao prevenir instanciao de todos os objetos no Servidor de
Aplicao.












Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 21/29

5.3.10 Padronizao de Nomes


5.3.10.1 Nome de Classes, JSP e Actions

NomeDaAcaoNomeDoCasoDeUsoAction.java
NomeDaAcaoNomeDoCasoDeUsoForm.java
nomeDaAcaoNomeDoCasoDeUso.jsp
nomeDaAcaoECE.do
OBS: nome da ao + nome do caso de uso abreviado com todas as letras em caixa-alta.

Exemplos de aes:

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

Exemplos de abreviaes:

pesquisarECE.do => pesquisar empresa contribuinte estrangeira.
selecionarEENO => selecionar empresa estrangeira no optante.


5.3.10.2 Estrutura de Diretrios

/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 aplicao 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 Manipulao de Dados
Todos os dados inseridos, atualizados e consultados nas Aplicaes devem ser em
caixa alta UPPERCASE. As consultas de dados do tipo caractere podem ser feitas em
case-insensitive, devendo ser convertida na aplicao em UPPERCASE para poder realizar a
consulta.



Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 22/29


5.3.11 Framework Ancine de Processamento Batch

5.3.11.1 Contexto
Existem algumas atividades dentro de uma aplicao que necessita de um processamento em
um tempo mais longo, e muitas vezes no precisa de uma interao direta com o usurio. Para tais tipos
de processamentos que podem onerar a CPU do servidor de aplicao principal deve se separar estas
atividades da aplicao principal.

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

5.3.11.3 Soluo
Caso seja necessrio realizar algum processamento batch pelas aplicaes em um servidor de
aplicao java, deve ser utilizado o framework Ancine de processamento batch. A idia separar o
processamento batch das aplicaes Java.

5.3.11.4 Benefcios
Independncia dos procedimentos batch para com o servidor de aplicao.

5.3.12 Recepo de novos desenvolvimentos

Um dos problemas recorrentes da ANCINE realizar o rpido 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
mudanas necessrias 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 soluo adotada a criao de um diagrama de componente
para cada caso de uso implementado. Tal diagrama deve informar quais componentes ele utiliza para a
execuo de seu trabalho. A partir da leitura deste, deve ser claro quais EJB, pginas, Actions, DAOs e
outros elementos so utilizados.
Na atividade de recebimento de produtos do processo de gerncia de software da ANCINE,
juntamente com o cdigo-fonte do aplicativo deve ser enviado o conjunto de diagramas que representam
para cada caso de uso, os artefatos utilizados.









Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 23/29



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














5.3.13 Requisitos de software para release de produo.

A gerncia de arquitetura de sistemas e qualidade da ANCINE tem como parmetro de
qualidade para passagem de um sistema para o ambiente de produo que os sistemas devem
obedecer s seguintes especificaes:

1. A utilizao do sistema em produo sob condies de configuraes corretas da aplicao no
deve gerar exceo.
2. Uma funcionalidade qualquer no deve exceder o tempo de execuo de 20.000 milissegundos.
Caso por algum motivo como processamento intensivo, clculos complexos ou envio de e-mails
deve ser documentada previamente tal funcionalidade e comunicada equipe de arquitetura
para verificao da melhor implementao possvel. (Considerar processamento intensivo,
algoritmos que possuam uma complexidade maior que O(n)).
3. Fica a cargo do pessoal de homologao avaliar os itens acima.











Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 24/29

5.4 Requisitos no funcionais para recebimento de software da fbrica.

A gerncia de arquitetura de sistemas e qualidade da ANCINE tem como parmetro de
qualidade para passagem de um sistema para o ambiente de desenvolvimento da ANCINE atravs do
fornecimento do cdigo-fonte. Este deve vir da referida fbrica de software contendo:

1. Instruo de instalao quando possuir alguma especificidade que justifique.
2. Cdigo fonte da aplicao.
3. Scripts necessrios para a configurao inicial da aplicao, quando necessrio.
4. Arquivos de parmetros e propriedades da aplicao, necessrios para o funcionamento do
sistema, quando pertinente.
5. Arquivos e scripts necessrios para a montagem e empacotamento da aplicao.


5.4.1 Pr-requisitos Gerais.

5.4.1.1 No sero permitidos mtodos deprecate.
5.4.1.2 No sero permitidas regras de negcio 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 crticas de valores obrigatrios devero ser feitas com javascript, mas as
mesmas tambm devero existir na camada de BO.
5.4.1.7 Tais regras que utilizarem javascript, devero 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, devero 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 exceo, o usurio dever receber uma mensagem: Os dados desse registro
j esto sendo atualizados pelo usurio: + var_NomeLogin. O tratamento desta exceo
dever manter os mesmos dados digitados pelo usurio nos campos das pginas a fim de
oferecer uma nova tentativa de confirmao sem que o usurio tenha de repetir a digitao.
As pginas dos Sistemas desenvolvidos devem implementar uma soluo de TOKEN para impedir a
submisso repetitiva das mesmas. Um exemplo de cdigo pode ser encontrado no livro Core J2EE
patterns, tambm disponvel no site da SUN pelo link: http://java.sun.com/blueprints/patterns/.
Existe uma implementao de exemplo da proposta de refactoring synchronizer token, provida pela
equipe de arquitetura da ANCINE na biblioteca de objetos ANCINE. Para maiores informaes verificar o
Javadoc da biblioteca.
5.4.1.11 As pginas devem desabilitar o boto de submisso de pgina aps ser pressionado, a
fim de impedir que a mesma pgina seja solicitada mais de uma vez. Isto deve ser realizado
na camada de apresentao.

Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 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 questo para esta conter no mnimo trs
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 padres 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 considerao os patterns propostos
pelo GOF (Gang Of Four) localizados no livro:
GAMMA, Erich
HELM, Richard
JOHNSON, Ralph
VILISSIDES, John
Padres de Projeto: solues reutilizveis de software orientados a objetos
Bookman, Porto Alegre, 2000
5.4.1.15 Todas as exceptions geradas pela camada de DAO, devero 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 necessrias;
+Validar campos que fazem parte do processo;
+Processar regra de negocio
+Lanar possveis exceptions geradas, incluindo na string de texto da exceo, o Nome do
Sistema, o mtodo executado e parmetro passado se houver.
5.4.1.17 Quando houver Agregao ou Associao no Hibernate, dever ser habilitado o recurso
LAZY.
5.4.1.18 No 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-condio ou ps-condio
uma regra Y pertencente a um BO2, o BO1 pode fazer referncia ao BO2 para cumprir a pr-
condio ou ps-condio. Com isso estaremos estabelecendo um relacionamento entre
BOs. Isto no significa que, no podemos instanciar dois BOs dentro de uma mesma Action.
Se para executar uma ao (Action), seja necessrio 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 mtodos comuns que dever ser fornecida fbrica de software
e consultada antes de se criar mtodos de apoio s aplicaes. Sua localizao e nome so:
../server/default/lib/ancine-commons.jar.
5.4.1.21 Deixamos como sugesto a utilizao da JPA como camada de persistncia junto com o
aproveitamento do recurso Annotations nas classes POJOs para o mapeamento objeto-
relacional.

Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 26/29

5.4.1.22 No permitido mtodos vazios ou que retornam null no executando nenhum
processamento. Entenda-se por processamento cdigo que realize alguma operao que
agregue funcionalidade aplicao.
5.4.1.23 Para as pginas de listagem de entidades necessria a utilizao de objetos POJOs
para o preenchimento das mesmas. Nestes devem existir somente os campos a serem
exibidos na tela, no pode ter referncias a outros objetos e no 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 aplicao e exibir retorno ao usurio explicando o problema com o
cdigo do erro.








Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 27/29


5.5 Diagrama de Diviso de Camadas




Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 28/29

5.6 Diagrama de Seqncia de Implementao
JSP/Tags(Vi ew) Acti onServl et ActionForm Acti onX Transfer Obj ect Busi ness
Object
DAO Database
post/get
val i dar
dados val i dados
execute
dados










Secretaria de Gesto Interna
Gerncia de Tecnologia da Informao Projeto de Arquitetura de Software Pgina 29/29

6. Viso de Distribuio
No se aplica neste documento.

7. Requisitos e Restries da Arquitetura
No se aplica neste documento.

8. Referncias
No se aplica neste documento.


9. Assinaturas

Os abaixo assinados esto de acordo com o contedo do documento Projeto de Arquitetura.



Data: ___/___/_____




Data: ___/___/_____



Sergio Augusto Santos de Moraes
Coordenador Tcnico
GTI
Roberto Souza de Holanda
Coordenador Tcnico
GTI



Data: ___/___/_____




Data: ___/___/_____



Carlos Jlio Ferreira Alferes
Arquiteto de Sistemas
GTI
Leandro Paranhos Carvalho de Souza
Arquiteto de Sistemas
GTI

Você também pode gostar