Pontifcia Universidade Catlica do Paran PUC/PR<Nome da Empresa>

Claudia Cristina de Oliveira Petry Jade Carlos de Oliveira Junior Raphael Luiz Nascimento Roberto Reinert

Gerenciador Financeiro Documento de Arquitetura de Software

Verso 1.0

Gerenciador Financeiro Documento de Arquitetura de Software

Version: 1.0 Date: 03/05/2008

Histrico da Reviso
Data 03/05/2008 Verso 1.0 Verso Inicial Descrio Autor Raphael Luiz Nascimento

Confidential

<Nome da Empresa>, 2009

Page 2 of 18

Gerenciador Financeiro Documento de Arquitetura de Software

Version: 1.0 Date: 03/05/2008

ndice Analtico
1. Introduo 1.1 Finalidade 1.2 Escopo 1.3 Definies, Acrnimos e Abreviaes 1.4 Referncias 1.5 Viso Geral Representao Arquitetural Metas e Restries da Arquitetura 5 5 5 5 5 5 5 5

2. 3.

Existem algumas restries de requisito e de sistema principais que tm uma relao significativa com a arquitetura. So elas: 4. Viso de Casos de Uso Os casos de uso deste sistema esto listados a seguir. Os casos de uso em negrito so muito importantes para a arquitetura. Uma descrio desses casos de uso pode ser encontrada posteriormente nesta seo. 4.1 Descrio dos casos de uso significativos 4.1.1 Visualizar movimentao financeira 4.1.2 Manter Movimentao financeira 4.1.3 Integrar Aparelho Mvel 4.1.4 Integrar Home Banking Viso Lgica 5.1 Viso Geral 5.2 Definio das Camadas 5.2.1 Camada de Apresentao 5.2.1.1 Adobe Flex 5.2.1.2 Processo de desenvolvimento 5.2.2 Camada de Negcio 5.2.3 Camada de Persistncia 5.2.4 Camada de Dados Viso de Processos Viso de Implantao Viso da Implementao Estrutura de Empacotamento Estrutura de Diretrios Estrutura de Pacotes

6 6

6 7 7 7 7 8 8 8 8 9 10 10 10 11 12 13 13 13 13 15 17

5.

6. 7. 8. 8.1 8.2 8.3

Confidential

<Nome da Empresa>, 2009

Page 3 of 18

Gerenciador Financeiro Documento de Arquitetura de Software

Version: 1.0 Date: 03/05/2008

8.4

Nomenclatura 8.5 Viso Geral 8.6 Camadas Tamanho e Desempenho Qualidade

17 Erro! Indicador no definido. Erro! Indicador no definido. 18 18

9. 10.

Confidential

<Nome da Empresa>, 2009

Page 4 of 18

Gerenciador Financeiro Documento de Arquitetura de Software

Version: 1.0 Date: 03/05/2008

Documento de Arquitetura de Software

1. Introduo
1.1 Finalidade

Este documento oferece uma viso geral arquitetural abrangente do sistema, usando diversas vises arquiteturais para representar diferentes aspectos do sistema. O objetivo deste documento capturar e comunicar as decises arquiteturais significativas que foram tomadas em relao ao sistema.

1.2

Escopo

Este documento de Arquitetura de Software se aplica ao sistema Gerenciador Financeiro.

1.3

Definies, Acrnimos e Abreviaes

As definies de todos os termos, acrnimos e abreviaes necessrias adequada interpretao deste documento podem ser encontradas no documento de Glossrio do Projeto.

1.4

Referncias

Titulo Glossrio do Projeto 1.5 Viso Geral

Link Glossrio.doc

Data de publicao 18/11/2007

2. Representao Arquitetural
Este documento apresenta a arquitetura como uma srie de vises: viso de casos de uso, viso de processos, viso de implantao e viso de implementao. Essas vises so apresentadas como Modelos da Linguagem Unificada de Modelagem (UML).

3. Metas e Restries da Arquitetura

Confidential

<Nome da Empresa>, 2009

Page 5 of 18

Gerenciador Financeiro Documento de Arquitetura de Software

Version: 1.0 Date: 03/05/2008

Existem algumas restries de requisito e de sistema principais que tm uma relao significativa com a arquitetura. So elas: D Dd D D D

4. Viso de Casos de Uso

Os casos de uso deste sistema esto listados a seguir. Os casos de uso em negrito so muito importantes para a arquitetura. Uma descrio desses casos de uso pode ser encontrada posteriormente nesta seo. 1. 2. 3. 4. 5. 6. 7. 8. 9. Exibir Grfico de Movimentaes Financeiras Visualizar Movimentaes Financeiras Manter Movimentaes Financeiras Efetuar Logoff Manter Usurios Efetuar Login Manter Pessoas Manter Feriados Manter Endereos

10. Manter Contatos 11. Manter Agncias Bancrias 12. Manter Formas de Pagamento 13. Manter Tipos de Conta 14. Manter Contas 15. Manter Grupos de Movimentao Financeira 16. Manter Vises 17. Manter Cotao de Moeda 18. Manter Vises 19. Manter Moedas 20. Manter Bancos 21. Integrar Aparelho Mvel 22. Integrar Home Banking

Os diagramas a seguir representam os casos de uso do sistema. Confidential <Nome da Empresa>, 2009 Page 6 of 18

Gerenciador Financeiro Documento de Arquitetura de Software

Version: 1.0 Date: 03/05/2008

Figura: Casos de uso do sistema 4.1 4.1.1 Descrio dos casos de uso significativos Visualizar movimentao financeira Este caso de uso permite ao usurio visualizar receitas e despesas que foram lanadas ou que esto agendadas para lanamento.

4.1.2

Manter Movimentao financeira

Este caso de uso permite o lanamento de despesas e receitas no sistema atravs das funes de incluso, excluso, alterao e consulta.

4.1.3

Integrar Aparelho Mvel

Este caso de uso permite que o usurio possa integrar as receitas e despesas lanadas pelo celular sejam integradas com o sistema instalado no sistema que est hospedado no servidor. Podendo assim o usurio posteriormente visualizar as despesas na interface WEB.

Confidential

<Nome da Empresa>, 2009

Page 7 of 18

Gerenciador Financeiro Documento de Arquitetura de Software

Version: 1.0 Date: 03/05/2008

4.1.4

Integrar Home Banking

Este caso de uso permite ao usurio integrar os arquivos no formato OFC que disponibilizado pelo banco registrando todos as movimentaes financeiras de uma determinada conta.

5. Viso Lgica
5.1 Viso Geral

A viso lgica define a estrutura lgica da arquitetura. Ela lista e descreve as camadas que compem a soluo definindo as responsabilidades de cada camada. Nessa seo, essa definio ser expandida para mencionar os frameworks que devem ser utilizados em cada camada e descrever a estrutura da arquitetura em termos dos padres (design patterns) que devem ser utilizados e como eles devem se relacionar.

Essas diferentes perspectivas ajudaro a melhor entender a arquitetura ao mesmo tempo em que estabelecero um forte padro em termos de camadas, frameworks e design patterns que compem a soluo.

5.2

Definio das Camadas

Nesta seo sero apresentadas as camadas da arquitetura proposta. Sero descritas as responsabilidades de cada camada quais tecnologias devem ser aplicadas a cada uma delas.

Nesta seo sero apresentadas as camadas da arquitetura proposta. Sero descritas as responsabilidades de cada camada quais tecnologias devem ser aplicadas a cada uma delas.

Camadas so divises lgicas separadas por responsabilidade. Para o caso em questo pode-se dizer que uma camada poder agrupar classes, pacotes e outros componentes que possuam funcionalidades em comum. Essa separao promove a coeso na medida que classes relacionadas esto juntas, e evita o acoplamento porque a comunicao entre camadas feita de maneira controlada. Idealmente, as camadas se comunicam apenas com camadas adjacentes. Comunicao entre camadas no vizinhas deve ser evitada.

No diagrama abaixo esto ilustradas cada uma das camadas que compem a arquitetura bsica proposta:

Confidential

<Nome da Empresa>, 2009

Page 8 of 18

Gerenciador Financeiro Documento de Arquitetura de Software

Version: 1.0 Date: 03/05/2008

Figura 1: Definio das camadas

5.2.1

Camada de Apresentao

Responsvel por controlar a interatividade entre o usurio e o sistema, expondo a lgica do negcio ao usurio utilizando-se de componentes grficos.

A camada de apresentao ser baseada no conceito RIA (Rich Internet Applications), onde a aplicao web contm caractersticas e funcionalidades de uma aplicao desktop tradicional.

Para fornecer esta interface ser utilizada a tecnologia Adobe Flex, tecnologia que suporta o desenvolvimento de aplicaes RIA baseadas na plataforma Adobe Flash.

Para isolar as regras de apresentao da regras de negcio prope-se o padro de projeto ModelView-Controller(MVC). O padro de projeto MVC divide a aplicao em trs camadas: model, contm os objetos de negcio, view, contm as view e por fim o control contendo o controle da interface e das requisies.

Sendo assim as views flex somente possuiro componentes flex e seu controle ser efetuadas por classes ActionScripts que controlaro estas interfaces e os dados que devero ser exibidos. Os dados ficaro representados pela camada model.

Confidential

<Nome da Empresa>, 2009

Page 9 of 18

Gerenciador Financeiro Documento de Arquitetura de Software

Version: 1.0 Date: 03/05/2008

5.2.1.1 Adobe Flex

Adobe Flex um conjunto de tecnologias desenvolvidas pela Abobe Systems para o desenvolvimento , deployment i de aplicaes em qualquer plataforma e construo de interfaces RIA baseado na tecnologia proprietria Adobe Flash.

A verso inicial do Adobe Flex foi em Maro de 2004, originalmente lanada pela Macromedia, que inclua um Kit de desenvolvimento uma IDE e a integrao com J2EE conhecida com Flex Data Service. Em 2005 Adobe adquiriu a Macromedia e verses posteriores do flex no requerem a licena para a utilizao do Flex Data Service, tornando-se um produto separado e chamado de LiveCycle Data Services.

Em fevereiro de 2008 foi lanado a verso Flex 3, sendo esta licenciada com uma licena do tipo Open Source, esta licena baseada na licena do Mozilla (Mozilla Public License). Porm o Adobe Flash Player o player para as aplicaes Flex so instanciadas e carregadas continuam sendo proprietrias da Adobe.

Tambm sua IDE Adobe Flex Builder, software usado para a criao de aplicaes Flex continuam sendo proprietrias.

5.2.1.2 Processo de desenvolvimento

O processo de desenvolvimento de Aplicaes baseadas em flex segue os seguintes passos:

1. 2. 3. 4. 5. 6.

Define a interface da aplicao usando uma srie de componentes pr-definidos; Use estilos e temas para definir o design visual da tela; Adicione comportamentos dinmicos; Define e conecte com data service se preciso; Compile o cdigo fonte gerando um SWF que o tipo de arquivo que o Flash Player instancia. Execute o SWF gerado.

5.2.2

Camada de Negcio

Esta camada contm componentes responsveis pelas regras de negcio do sistema, ou seja, ela fornece os servios de domnio da soluo. Esses servios so disponibilizados atravs de uma interface <Nome da Empresa>, 2009

Confidential

Page 10 of 18

Gerenciador Financeiro Documento de Arquitetura de Software

Version: 1.0 Date: 03/05/2008

pblica, aqui implementada atravs da utilizao do padro de projeto: Session Facade. O objetivo da Facade fornecer uma camada de abstrao capaz de centralizar a complexidade da regras de negcio ao mesmo tempo em que esconde os detalhes de sua implementao. Em geral as Facades no possuem estado (Stateless), o que permite um ganho de performance considervel. A Facade pode ser invocada por qualquer tipo de cliente (objetos da camada web, WebServices, Unit Tests, ou mesmo uma aplicao Desktop) e utilizam entidades de negcio como objetos de comunicao entre as camadas.

O acesso a estes servios sempre disponibilizado atravs de classes que utilizam o padro de projeto Business Delegate, o objetivo deste padro de objeto controlar e proteger os servios de negcio da aplicao.

Sendo assim o Business Delegate encapsula o acesso a servios de negcio. Esconde os detalhes de implementao tais como lookup 1 e mecanismos de acesso.

Para realizar a busca destes componentes de servios necessrio realizar uma tarefa chamada Lookup ser utilizado o padro de projeto chamado Service Locator, este padro de projeto encapsula o servio e componente de lookup. Esconde detalhes de implementao do mecanismo de lookup e tambm encapsula as dependncias relacionadas a este procedimento. Outra caracterstica do Service Locator tambm o uso de cache que guarda referncias de servios que anteriormente foram utilizados, diminuindo assim chamadas para lookup que consomem recursos de rede.

Outra responsabilidade desta camada o controle de transao, para isto ser utilizado tanto para implementar o padro Session Facade e o controle de transao a tecnologia da SUN chamada de Sun Enterprise Bean na verso 3.0, onde ser utilizado Session Bean do tipo Statless onde sua principal caracterstica e prover o controle da transao, acesso a objetos remotos, mapeamento da segurana entre outras.

5.2.3

Camada de Persistncia

A camada de persistncia possui componentes responsveis pela lgica inerente persistncia e recuperao de informaes desde o sistema de armazenamento. O objetivo dessa camada fornecer uma abstrao capaz de encapsular toda a lgica de acesso a dados, deixando transparente a camada de negcio como so realizadas tais operaes. O tipo de sistema de armazenamento (base de dados, XML, sistemas legados e etc) utilizado seria de conhecimento exclusivo da camada de persistncia, sendo irrelevante para

Lookup: Procura por um determinado servio podendo ser um Recurso, uma conexo com base de dados, Servios EJB.

Confidential

<Nome da Empresa>, 2009

Page 11 of 18

Gerenciador Financeiro Documento de Arquitetura de Software

Version: 1.0 Date: 03/05/2008

as outras camadas da arquitetura. Isso permite que o sistema de armazenamento seja alterado (XML para Banco de Dados, por exemplo), sem alteraes nas demais camadas da aplicao, o que facilitaria, em muito, uma possvel manuteno nesse sentido.

O padro utilizado para se conseguir tal objetivo o Data Access Object Design Pattern (DAO). O padro DAO implementa o mecanismo de acesso requerido para trabalhar com a estrutura de dados. Esta camada utiliza-se de API proprietrias da estrutura de dados. Esta API utiliza-se da tecnologia java chamada JDBC ( Java Database Connectivity), onde detalhes especficos do Banco de dados so implementados dentro desta API e fornece um padro de comunicao que a camada de persistncia consegue interagir, desacoplando assim a camada de negcio de banco de dados proprietrios.

A representao do dado oriundo da base de dados ser feita de uma maneira Orientada a Objetos atravs da tecnologia JPA (Java Persistence API). Objetivo principal desta tecnologia mapear os nosso objetos para o banco de dados e os objetos do banco de dados para objetos Java.

JPA nos fornece os seguintes servios: Mapeamento objeto/Relacional; Modelagem de domnio permitindo herana e polimofisrmo; Linguagem padro para realizao de pesquisa(Java Persistence Query Language); Mapeamento atravs de Annotations;

5.2.4

Camada de Dados

Representam as classes do domnio da soluo, os objetos de negcio. Esses objetos compem o modelo de dados OO do sistema. Eles so manipulados por todas as camadas da arquitetura e por isso devem ser capazes de trafegar atravs delas. A camada de apresentao usa os objetos dessa camada para apresentar as informaes na tela e para popular objetos que sero passados camada de negcio; esta, por sua vez, manipula esses objetos aplicando as regras de negcio sobre eles e, por ltimo, a camada de persistncia, efetivamente, persiste ou recupera esses objetos a partir do sistema de armazenamento.

Em uma aplicao onde o sistema de armazenamento uma base relacional, esses objetos so o resultado do mapeamento objeto/relacional que torna possvel que o sistema seja desenvolvido seguindo o paradigma OO.

Para prover esse caminho entre as camadas ser utilizado o padro de projeto Data Transfer Object, Ao invs de enviar ou receber elementos individuais, um Data Transfer Object contm todos os Confidential <Nome da Empresa>, 2009 Page 12 of 18

Gerenciador Financeiro Documento de Arquitetura de Software

Version: 1.0 Date: 03/05/2008

elementos em uma nica estrutura requerida por uma requisio ou uma resposta. Ser um tipo de objeto que tem como caracterstica principal a possibilidade de ser serializado. Um objeto serializado capaz de ser enviado entre camadas da aplicao sendo estas num mesmo container ou no.

6. Viso de Processos
Esta seo define o sistema em tempo de execuo, ou seja, em termos de processo ou threads que controlam o sistema. Na arquitetura proposta maioria dos processos so controlados por threads estas threads so controladas pelo prprio container do servidor (Jboss) de aplicaes. Neste caso nenhum controle adicional necessrio.

7. Viso de Implantao
Esta viso define o ambiente de implantao onde a aplicao ser publicada/instalada. O servidor de aplicao a ser utilizado o Jboss Enterprise Application Platafform. Jboss um servidor de aplicaes baseado na plataforma J2EE implementada completamente na linguagem de programao Java. http://artigos.tekever.eu/ver/?161

8. Viso da Implementao
A viso de implementao aborda a arquitetura sobre a perspectiva do projeto estrutural os componentes do sistema, ou seja, como o sistema e cada um de seus componentes so organizados em termos de diretrios e pacotes e como o sistema, como um todo, empacotado para publicao (deployment).

8.1 Estrutura de Empacotamento

Na arquitetura proposta teremos componentes de negcio fornecida pela tecnologia EJB 3.0, componentes de persistncia fornecidas pela tecnologia JPA e por fim componentes de apresentao fornecida pela tecnologia FLEX 3.0.

Para empacotar todas estas tecnologias e facilitar a instalao/deployment da aplicao nos servidores, foram definidos que a aplicao como um todo seja empacotada em um nico arquivo .ear composto por:

Mdulo EJB: So programas que utilizam da tecnologia EJB ou JPA e precisam ser empacotados como mdulo EJB para que o servidor de aplicao utilizada carregue este

Confidential

<Nome da Empresa>, 2009

Page 13 of 18

Gerenciador Financeiro Documento de Arquitetura de Software

Version: 1.0 Date: 03/05/2008

mdulo como um mdulo EJB ou JPA. Este mdulo representado por um arquivo compactado na extenso jar onde contm todos os programas compiliados que utilizam da tecnologia acima descritas. Mdulo WEB: So programas que utilizam da tecnologia WEB, comumente atravs de Servlets ou JSPs. Este mdulo representando por um arquivo compactado possuindo a extenso .war onde contm todas as interfaces e programas que precisam utilizar informaes da camada View. Mdulo JAVA: So programas que utilizam somente da tecnologia java. Composto tambm por arquivos na extenso .jar onde engloba os programas compilados em java.

Alm destes arquivos necessrio juntamente com o arquivo .ear um descritor dos mdulos que devero ser carregados pelo servidor de aplicaes. Abaixo segue um exemplo do descritor que deve ser chamado de application.xml.

<?xml version="1.0" encoding="UTF-8"?> <application> <display-name>Simple example of application</display-name> <description>Simple example</description> <module> <ejb>ejb1.jar</ejb> </module> <module> <ejb>ejb2.jar</ejb> </module> <module> <java>modulo.jar</java> </module> <module> <web> <web-uri>web.war</web-uri> <context-root>web</context-root> </web> </module> </application>

Finalmente a estrutura de um arquivo .ear como um todo pode ser visualizada na figura abaixo.

Confidential

<Nome da Empresa>, 2009

Page 14 of 18

Gerenciador Financeiro Documento de Arquitetura de Software

Version: 1.0 Date: 03/05/2008

Figura 2: Estrutura arquivo Ear. Este arquivo ento ser instalado no servidor de aplicaes Jboss onde o carregamento, configurao e instalao da aplicao ser efetuada por este servidor.

8.2 Estrutura de Diretrios

A Arquitetura de Referncia prope que seja utilizado o Maven 2 como ferramenta de construo (build tool). Maven uma ferramenta de construo para projetos Java corporativos, projetada para automatizar o processo de empacotamento de aplicaes. O Maven usa uma abordagem declarativa, onde so descritos a estrutura do projeto e seu contedo, ao invs da abordagem task-based usada pelo Ant ou em make files, por exemplo. Isso ajuda a garantir a utilizao dos padres de desenvolvimento e reduz o tempo necessrio para escrever e manter scripts de empacotamento (build scripts).

O corao de um projeto Maven 2 o Project Object Model (POM). Ele contm uma descrio detalhada de seu projeto, incluindo informaes sobre versionamento, gerncia de configurao, dependncias, testes, membros da equipe, estrutura fsica e muito mais. O POM um arquivo XML (pom.xml), localizado na raiz do diretrio do projeto.

O principal ganho obtido com o Maven, vem dos padres que ele encoraja. Um desenvolvedor que j tenha trabalhado com Maven vai, imediatamente, se sentir familiar com a estrutura e a organizao do novo projeto.

A estrutura de diretrios proposta nesta arquitetura seguir as seguintes definies.

Confidential

<Nome da Empresa>, 2009

Page 15 of 18

Gerenciador Financeiro Documento de Arquitetura de Software

Version: 1.0 Date: 03/05/2008

Figura 3: Estrutura diretrios do Projeto

Como podemos visualizar na figura acima temos os seguintes diretrios: Application: Diretrio onde conter a aplicao a ser distribuda no formato .ear. Flex: Diretrio onde conter os mdulos flex. Flex/app/: Diretrio onde conter os casos de uso implementados na linguagem flex, como por exemplo maintainContact. Confidential <Nome da Empresa>, 2009 Page 16 of 18

Gerenciador Financeiro Documento de Arquitetura de Software

Version: 1.0 Date: 03/05/2008

Flex/common: Diretrio onde conter programas flex que sero utilizados por um ou mais casos de usos. Java: Diretrio onde conter os mdulo java. Java/app: Diretrio onde conter os casos de uso implementados na linguagem java, como por exemplo maintainContact. Java/common: Diretrio onde conter programas java que sero utilizados comumente por um ou mais casos de usos. Java/core: Diretrio onde conter programas java que sero base para a codificao dos casos de uso.

8.3 Estrutura de Pacotes

A Arquitetura aqui proposta estabelece que o sistema deve ser dividido em componentes de negcio e esses componentes podem ser divididos em sub-componentes. Assim, a Arquitetura de Referncia fornece a seguinte hierarquia de pacotes:

net.sf.mybudget.<componente>[.<sub-componente>]

Como se pode notar, a estrutura de pacotes citada acima termina com um componente ou um subcomponente (caso seja necessrio). Internamente a cada componente tem-se uma organizao de pacotes estruturada em termos do papel de cada classe dentro do sistema.

8.4 Nomenclatura
A arquitetura aqui proposta estabelece um padro de nomenclatura cujo objetivo padronizar os nomes das classes em funo de seu papel no sistema. Isso permite que os arquitetos, projetistas e desenvolvedores identifiquem rapidamente as classes em funo de seu nome. Abaixo segue o padro proposto: Session Beans: Devem utilizar o sufixo ServiceBean, por exemplo

AccountServiceBean. Entidades Persistentes : Devem ser nomeadas somente com o nome da entidade a ser persistida, por exemplo a entidade Account deve ser nomeada somente Account. Interfaces DAO: Devem utilizar o sufixo DAO e prefixo o nome da entidade, por exemplo para a entidade Account deve ser nomeada AccountDAO.

Confidential

<Nome da Empresa>, 2009

Page 17 of 18

Gerenciador Financeiro Documento de Arquitetura de Software

Version: 1.0 Date: 03/05/2008

Implementaes da Interface DAO: Devem utilizar o sufixo DAOImpl, por exemplo para a interface AccountDAO deve ser nomeada AccountDAOImpl. Classes Utilitrias: Classes que fornece funes utilitrias para a realizao de alguma outra tarefa, e que tenham caractersticas de reutilizao 1 ou mais outras classes. Devem utilizar o sufixo Utils, por exemplo uma classe utilitria para trabalhar com Strings dever ser chamada de StringUtils.

Delegates: Devero possuir o sufixo ServiceDelegate, por exemplo o delegate para o ServiceBean AccountServiceBean dever ser nomeado com

AccountServiceDelegate.

9. Tamanho e Desempenho
[Uma descrio das principais caractersticas de dimensionamento do software que tm um impacto na arquitetura, bem como as restries do desempenho desejado.]

10. Qualidade
[Uma descrio de como a arquitetura do software contribui para todos os recursos (exceto a funcionalidade) do sistema: extensibilidade, confiabilidade, portabilidade e assim por diante. Se essas caractersticas possurem significado especial, como implicaes de segurana, garantia ou privacidade, elas devero ser delineadas claramente.]
i

Deployment: Termo tcnico utilizado para definir a distribuio de uma aplicao.

Confidential

<Nome da Empresa>, 2009

Page 18 of 18