_______________________________________________________________________________________

Documento de Arquitetura Base

Projetos
Verso 01.00 14 de April de 2015
Responsvel: Frank Leite Coelho

___________________________________________________________________________

Histrico de Revises
Data
06/08/2014

Verso Descrio
1.0
Elaborao do Documento

Arquitetura de Software RCP Software

Documento Interno.

Autor
Frank Coelho

1.

Introduo

Neste documento iremos detalhar as principais partes da arquitetura proposta para o

desenvolvimento de sistemas na SmartWay. A arquitetura formada por diversos padres de
projeto, principalmente, padres Orientados a Objetos com destaque no mercado. Iremos
destacar em cada parte da arquitetura o motivo da sua criao e o qual a sua influncia para
a criao de sistemas de alta coeso, mas com baixo acoplamento.

2.

Objetivos

O Documento de Arquitetura do Software prov uma viso geral da arquitetura,

usando um conjunto de vises arquiteturais para tratar aspectos diferentes do software.
Este documento serve como um meio de comunicao entre o Arquiteto de Software e
outros membros da equipe de projeto sobre as decises significativas que forem tomadas
durante o projeto.

3.

Consideraes Gerais

As definies arquiteturais de um projeto de desenvolvimento de software em geral

seguem as definies necessrias aos vrios projetos de uma organizao ou instituio e que
atenda a todas as necessidades do projeto, desde a segurana, regras de negcio, at a
persistncia dos dados. Essas definies do projeto em geral esto em um documento
parte, elaborado durante um trabalho de consultoria arquitetural.
As definies do projeto j documentadas at o presente momento devem guiar as
primeiras verses do Documento de Arquitetura do Software, que desenvolvido durante a
fase de Elaborao, uma vez que o propsito dessa fase estabelecer os fundamentos
arquiteturais para o projeto do software.

4.

Responsabilidades

O Arquiteto de Software o responsvel por elaborar este documento e por manter a

integridade do mesmo durante o processo de desenvolvimento do software. Ele deve:

Aprovar todas as mudanas arquiteturais significativas e document-las.

Fazer parte do comit que decide sobre os problemas que tenham algum impacto
arquitetural.

5.

Referncias

Arquitetura de Software RCP Software

Documento Interno.

1. Alarcn, R. and Fuller, D. Intelligent Awareness in Support of Collaborative Virtual Work

Groups. In: Haake, J. M. and Pino, J. A. (Eds.) CRIWG 2002, LNCS 2440, pp. 147 167,
Springer-Verlag, 2002
2. Aldunate, R. Nussbaum, M. and Gonzlez, R. An Agent Based Middleware for supporting
Spontaneous Collaboration among Co-Located, Mobile and not Necessarily Known People.
Workshop on Ad hoc Communications and Collaboration in Ubiquitous Computing
Environments, CSCW 2002, New Orleans, USA, November 2002.
3. Bergenti, F., Garijo, M., Poggi, A., Somacher, M. and Velasco J.R. Enhancing Collaborative
Work through Agents. VIII Convegno dell'Associazione Italiana per l'Intelligenza Artificiale,
2002.
4. Bourning, A. and Travers, M. Two approaches to casual Interaction on Computer and Video
Networks. Proceedings of International Networking Conference, 1991.
5. Dourish, P. and Bly, S. Portholes: Supporting Awareness in distributed Work Group.
Proceedings CHI, 1992.
6. Ellis, C.A., Barthelmess, P., Quan, B. e Wainer, J. NEEM: An Agent Based Meeting
Augmentation System. Technical Report CU-CS-937-02, University of Colorado at Boulder,
Computer Science Department, 2002.
7. Ellis, C.A. e Wainer, J. Groupware and Computer Supported Cooperative Work. In Weiss, G.
(Ed.) Multiagent, Systems, MIT Press, 1999.
8. Enembreck, F. and Barths, J. P. Personal Assistant to Improve CSCW. Proceedings of the
7th International CSCWD, Rio de Janeiro, 2002, pp 329 335.
9. Esborjrnsson, M. and stergren, M. Issues of Spontaneous Collaboration and Mobility.
Workshop on Supporting Spontaneous Interaction in Ubiquitous Computing Settings,
UBICOMP'02, Gteberg, Sweden, 2002.
10. Fish, R. S., Kraut R. E. and Chalfonte, B. L. The VideoWindow System in Informal
Communications. Proceedings CSCW, 1990.

6.

Arquitetura

O que ? E como composta?

A arquitetura foi desenvolvida para ser totalmente de alta coeso e baixo acoplamento,
e que ao mesmo tempo fosse independente de tecnologia de soluo existentes no mercado.
Portanto para que a arquitetura conseguisse esse seu objetivo foi desenvolvido o que
chamamos de ltima milha.

Arquitetura de Software RCP Software

Documento Interno.

6.1.

ltima Milha

A ltima milha, nome mais conhecido no mercado, um conjunto de classes que so

implementadas com o objetivo de ocultar as complexidades existentes nas tecnologias
adotadas no desenvolvimento, gerando muito mais conforto e facilidades para os
programadores. Com isso, o programador no precisa ter o conhecimento das tecnologias
utilizadas, mas sim, ter o conhecimento apenas da ltima milha desenvolvida. Com isso
conseguimos fazer um uso muito forte do encapsulamento, ou seja, conseguimos criar uma
camada, a qual nosso sistema foi construdo, independente de tecnologia. Conseguimos,
assim, criar uma equipe slida em seus conhecimentos e ao mesmo tempo produtiva.
Alm das classes que so pea-chave dentro da arquitetura, foi adicionada tambm
ltima milha, classes de apoio ao desenvolvimento, ou melhor, classes que fazem o papel de
ferramentas, onde possuem mtodos que sero utilizados da mesma forma em todos os
sistemas. Por exemplo, classes responsveis por fazer a leitura das propriedades do sistema,
classes que representam as constantes do sistema, classes que facilitaram a validao e a
formatao dos dados de entrada no sistema, entre outros.

6.2.

Elementos que compe a Arquitetura

Quais so os principais elementos da arquitetura?

A arquitetura composta por alguns elementos, entenda-se classes, que em conjunto

produzem o efeito desejado pela arquitetura como um produto final para o desenvolvimento.
Para uma descrio detalhada de como cada classe trabalha, faz parte de toda a metodologia
de desenvolvimento da ltima milha a criao do XML Doc, detalhando cada mtodo e
atributo existente, para que a curva de aprendizado na utilizao da ltima milha seja a
menor possvel.
Elementos pertencentes arquitetura:

Banco de dados
Repositrio
Controlador
Exceo
Fachada
WEB
o ASP.Net
o Java Script
o Ajax
o JQuery

Nos prximos captulos iremos discutir cada componente listado anteriormente e qual
o seu papel dentro da arquitetura como um todo, alm de discutir de forma sucinta a
tecnologia e/ou o padro adotado para a implementao do mesmo.

Arquitetura de Software RCP Software

Documento Interno.

6.3.

Banco de Dados

O que essa camada? E pra que serve?

No desenvolvimento de sistemas precisamos em muitas vezes fazer acesso a uma

determinada base de dados. Em algumas linguagens de programao, principalmente as
estruturadas, a separao real de funcionalidades na programao muito complexa de forma
que acessos a dados, consultas, entre outros elementos do sistema, acabam se misturando, o
que ocasiona um alto acoplamento para termos alta coeso. Com a programao orientada a
objetos isso j no ocorre em modelagens mais elaboradas. No caso da arquitetura
desenvolvida temos uma camada apenas de banco de dados ou camada de persistncia.
Nessa camada esto classes abstratas que implementam as principais funcionalidades
de conexo e outros controles que so iguais a todos os tipos de acessos a bancos de dados,
exigindo que essas classes sejam herdadas por classes mais especficas para cada banco de
dados. O acesso ao banco feito atravs de repositrios.
Com esse tipo de soluo conseguimos realmente separar das regras de negcio a
implementao de funcionalidades bsicas de acesso base de dados, controles transacionais
e gerenciadores de conexo.

6.4.

Repositrio

Qual a sua principal finalidade?

Quando estamos elaborando uma arquitetura para o desenvolvimento de sistemas,

principalmente orientado a objetos, temos que nos preocupar com a separao real das
camadas pertencentes arquitetura. nesse contexto que comeamos a discutir os principais
elementos da arquitetura, sendo que agora iremos comear detalhar o Cadastro e seu
contexto dentro da arquitetura.
O repositrio uma classe pertencente camada de negcio, responsvel por tratar as
regras referentes manipulao de dados com algum mecanismo de persistncia,
manipulao essa feita atravs do uso de interface entre a camada de negcios e a camada
de persistncia, acessando o banco como desejado. Dessa forma, as principais
funcionalidades que um cadastro deve controlar so: insero, excluso, alterao e consulta.
Com a criao do repositrio, separamos da regra de negcio o controle de acesso a
elementos de persistncia, assim como o controle e a manipulao dos dados que so
retornados de um banco de dados. Por exemplo, o cadastro pode implementar regras para o
controle de ltima alterao ou data de incluso.
O Repositrio acessa a camada de persistncia utilizando-se de uma interface,
conhecida como interface negcio-dados. Essa interface proporciona uma separao total
entre as camadas de negcio e dados.

Arquitetura de Software RCP Software

Documento Interno.

6.5.

Controlador

Onde implementada a regra de negcio?

Todo sistema formado por um conjunto de regras de negcio, ou seja, um fluxo

lgico que deve ser processado para que tenhamos o resultado desejado. Uma regra de
negcio representada na UML (linguagem de modelagem de sistemas orientada a objetos)
atravs de um caso de uso (modelagem da regra de negcio). Com a anlise orientada a
objetos a preocupao com a separao real da regra de negcio das demais funcionalidades
do sistema constante e essencial para termos um sistema de baixo acoplamento e de fcil
manuteno e extenso.
Por esse motivo foi criado o elemento chamado Controlador dentro da arquitetura. Um
controlador responsvel pela execuo de um ou mais fluxos de execuo que so
modeladas em um caso de uso, ou seja, podemos dizer que o controlador em si a
implementao da regra de negcio. O mesmo pode ser modularizado, quando existem
algumas particularidades dentro da implementao das regras, em classes que chamamos de
RN (regras de negcio). O controlador faz uso do cadastro para obter as informaes
necessrias para o seu processamento.
Com isso temos para cada caso de uso existente no sistema um controlador
responsvel por implement-lo, assim temos um controle transacional muito mais robusto
(por caso de uso ou pela interao entre eles), por exemplo, cada mtodo dentro do
controlador estar sempre sobre o mesmo contexto transacional.

6.6.

Excees

Para que servem?

Em .Net temos um recurso que muito utilizado e importante no desenvolvimento de

sistemas, que o recurso de Exceptions, ou melhor, excees. Plataforma .Net nos prov
vrios tipos de excees j existentes, sendo essas excees verificadas, excees de tempo
de execuo e excees fatais do sistema. Alm das excees, existe todo um mecanismo
para que possamos trat-las e dar continuidade no fluxo de execuo conforme desejamos.
Com isso houve a necessidade de criarmos algumas excees com mais recursos
dentro da nossa arquitetura. Algumas excees criadas so apenas o encapsulamento de
excees j existentes, s que, com mais recursos que facilitaro o desenvolvimento dos
sistemas dentro da arquitetura e outras excees so novas, e foram criadas para estarem
dentro do contexto da arquitetura.

6.7.

Fachada

A porta de entrada para as regras de negcio.

At agora s falamos dos principais elementos que compem a camada de regras de

negcio, ou seja, no falamos nada de interface grfica ou at mesmo de interaes externas
com as mesmas. ai que entra o papel fundamental da fachada.

Arquitetura de Software RCP Software

Documento Interno.

A fachada a diviso entre as camadas superiores s regras de negcio (Controlador)

e as regras propriamente ditas. Ela a entrada nica, tanto das interfaces grficas do usurio
como de outros sistemas, para o acesso as regras de negcio. Com a fachada, conseguimos
ento ter uma independncia de interface grfica, como tambm podemos proteger e
controlar o acesso s regras de negcio. Assim, por exemplo, podemos ter um sistema
totalmente desenvolvido utilizando a tecnologia Ajax (recurso usado para a elaborao de
interfaces grficas clientes em .Net) e um sistema totalmente desenvolvido para WEB
(usando Asp.Net) utilizando as mesmas regras de negcio. Conseguimos tambm facilitar e
controlar o acesso s regras de negcio por outros sistemas atravs da fachada.
De uma forma sucinta podemos descrever a fachada como sendo a porta de entrada
para um conjunto de casos de usos, que possuem afinidades, que sero acessadas por
elementos externos como interfaces grficas e/ou sistemas. Podemos ter, por exemplo, mais
de uma fachada por sistema.

6.8.

WEB

Como dividida? Quais seus principais elementos?

Ns j detalhamos bem a camada de regra de negcio e persistncia de dados, agora

iremos detalhar a camada de interface com o usurio. Nesse primeiro momento iremos falar
sobre interfaces web, como ela foi dividida e o que foi envolvido na criao da mesma.
O IIS um servidor de aplicaes .Net para web. O IIS robusto e eficiente o
suficiente para ser utilizado mesmo em um ambiente de produo.
Tecnicamente, o IIS um Container Web, parte da plataforma corporativa Microsoft,
integrada e com alta compatibilidade com SO e segurana. O IIS tem a capacidade de atuar
tambm como servidor web/HTTP.

6.9.

Definio das camadas

Definio e finalidade?

Os sistemas devero seguir o exposto tendo como princpio a separao arquitetural de

no mnimo trs camadas fsicas e logicas, abstraindo o conceito de arquitetura MVC.

As trs camadas...
A camada de apresentao cuida da interao entre o usurio e o software. Pode ser
to simples quanto um sistema de linha de comando, ou um cliente rico com interface grfica
ou ainda um sistema baseado em navegadores de Internet. As responsabilidades primrias da
camada de apresentao so exibir a informao para o usurio e interpretar os comandos
emitidos pelo usurio em aes para as camadas de domnio e de dados.
A camada de dados cuida de toda interao com SGBDs e outras fontes de dados. Pode
ser um monitor de transaes, outras aplicaes, sistemas de mensagens e assim por diante.
Para a maior parte das aplicaes corporativas, a fonte de dados um banco de dados cuja
responsabilidade a persistncia de dados no volteis.

Arquitetura de Software RCP Software

Documento Interno.

A camada de lgica de domnio, tambm chamada de camada de negcio, cuida das

necessidades da aplicao no domnio em que ela se insere. Envolve clculos baseados em
dados digitados e em informaes armazenadas, validao de informaes vindas da camada
de apresentao, e qual fonte de dados deve ser acionada, baseado em comandos recebidos
do usurio.
Camada

Responsabilidades

Apresentao

Provisionamento de servios, exibio de informaes

Domnio / Negcio

Lgica particular ao sistema

Dados

Comunicao com bancos de dados, sistemas de mensagens,

monitores de transao

A camada de domnio pode ser arranjada de tal maneira que se interponha separando
as outras duas. Contudo, pode ser tambm que a camada de apresentao faa acesso
camada de dados diretamente. Apesar de ser menos puro, pode ser prtico em alguns
casos.
Uma aplicao pode possuir vrias interfaces em cada uma das trs camadas. Por exemplo,
pode existir uma interface da camada de apresentao para ser utilizada por usurios da
aplicao como linha de comando e outra para usurios da aplicao como interface grfica,
ou mesmo uma interface para ser utilizada por outro sistema, como um Web Service. O
mesmo se aplica s demais camadas, permitindo abstrair fontes de dados e/ou permitir a
aplicao de conjuntos diversos de regras de negcios. A construo de aplicaes deste
modo, todavia, no trivial, e seu desenvolvimento deve considerar questes de custo,
tempo de desenvolvimento, desempenho, entre outras.
Junto com a separao em camadas caminha uma regra importante sobre
dependncias: as camadas de domnio e de dados nunca devem ser dependentes da
camada de apresentao. Esta regra facilita a utilizao de diferentes camadas de
apresentao baseados na mesma fundao, sem srias alteraes. O relacionamento entre
domnio e dados mais complexo e depende dos padres de arquitetura utilizados para a
camada de dados. Uma das tarefas mais rduas reconhecer o que lgica de domnio e o
que outra forma de lgica. Um teste informal adicionar uma camada radicalmente
diferente aplicao, como uma interface de linha de comando a uma aplicao Web. Se
houver alguma funcionalidade que precise ser duplicada, sinal que a lgica de domnio
vazou para a camada de apresentao. Similarmente, necessrio duplicar algum cdigo ao
substituir o banco de dados relacional por arquivos XML?

6.10. Modelo de domnio

Arquitetura de Software RCP Software

Documento Interno.

O modelo completo (Domain Logic) envolve a modelagem de objetos de negcio e o

desenvolvimento da aplicao seguindo-se o padro tradicional de orientao a objetos e
componentizao clssica. Por ser um modelo mais completo em termos de suas
preocupaes com reutilizao, e mais puro no tocante ao uso de recursos da orientao a
objetos, tambm se apresenta com maior complexidade e exige um processo de concepo
mais apurado.

6.11. Desenho Geral da arquitetura

Arquitetura de Software RCP Software

Documento Interno.

10

7.

Padres de Projeto

Os padres de projeto possibilitam a reutilizao de tcnicas comprovadas com o objetivo

de atender requisitos tcnicos relacionados ao projeto de um sistema. Para o SSAA, foram
analisados alguns padres de projeto e selecionados aqueles que poderiam ser
satisfatoriamente aplicados.

7.1.

Facade

O padro de projeto Facade oferece um ponto centralizado e unificado para um

conjunto de interfaces em um subsistema ou do sistema como um todo, que representa o
conjunto de servios oferecidos. O Projeto implementa a Fachada como um ponto de
acesso nico para as funcionalidades, isolando os diversos componentes do sistema.

7.2.

PDC

O PDC Persistent Data Collection um padro de projeto que destrincha cada

coleo persistente de dados em duas classes e uma interface: uma classe Cadastro da
coleo propriamente dita (e diretamente ligada classe Cadastro da anlise) e uma
classe Repositrio que implementa uma forma de persistncia fsica especfica, em
conjunto com uma interface para isol-la do Cadastro.

Arquitetura de Software RCP Software

Documento Interno.

11

7.3.

Singleton

Assegura que a classe ter uma nica instncia e prov um ponto nico de acesso a
ela. O padro Singleton usado, portanto, dentro da classe Fachada, para limitar a sua
instncia, acessvel a partir de um nico ponto especfico. Isto importante por que a
Fachada que serve de ponto de acesso a todos os servios oferecidos pelo SETA, e que
dispe do conjunto de dados que ser compartilhado entre os usurios.

8.

Objetivos e Restries Arquiteturais

Esta seo descreve os requisitos e objetivos do software que tm algum impacto na

arquitetura, tais como: segurana, proteo de dados, privacidade, portabilidade, distribuio,
reuso. Tambm so descritos nesta seo restries arquiteturais que se aplicam ao projeto,
tais como: estratgias de modelagem e implementao, ferramentas de desenvolvimento,
sistemas legados.

8.1.

Requisitos bsicos

A arquitetura deve seguir o padro Plataforma .Net.

Windows 7 ou 8 como sistema operacional do ambiente de produo.

IIS como servidor WEB (continer WEB)

O modelo de interface dever ser WEB responsiva de forma a suportar todos os tipos
de browsers Internet Explorer, Chrome e etc.

Padro de Interface Web dever ser W3C

8.2.

Estratgias de implementao

1. A linguagem de codificao padronizada para a maioria dos casos C Sharp 4.0x.

2. Biblioteca Web Asp.Net 4.0x, sempre que possvel usar controles nativos da
plataforma para lado servidor e controles Ajax para lado cliente.
3. Persistncia de tipagem (ex: formato de CPF, Data) devem ser feitos no cliente via
JavaScript, JQuery e etc.
4. Persistncia de obrigatoriedade, como verificar se todos os campos obrigatrios de um
formulrio foram preenchidos pode ser feito no cliente via JavaScript.
5. Para manuteno estado, usar Session do lado do servidor e Viewstate do lado cliente.
6. Padro de codificao e nomenclatura o recomendado para plataforma.
7. Todas as funcionalidades devero ser desenvolvidas com seus respectivos testes
unitrios.
8. Desenvolvimento de servios Web ser preferencialmente no modelo WCF.
Arquitetura de Software RCP Software
Documento Interno.

12

Arquitetura de Software RCP Software

Documento Interno.

13