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.
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