Arquitetura de Software

Arquitetura de Software:
Avaliando a arquitetura
de seus sistemas
Conhea neste artigo um mtodo para avaliao
de arquitetura de software que ajuda nas tomadas
de deciso
laborar a arquitetura de um software pode ser

uma tarefa rdua para muitos profissionais. Dependendo do tamanho e da misso do sistema,
so milhares de linhas de cdigo, centenas de componentes, bibliotecas de terceiros, relatrios, integrao
com sistemas legados, servidores de aplicaes, tabelas
de banco de dados, segurana de acesso, alta disponibilidade e demais elementos que aumentam a complexidade
da arquitetura.
Como verificado, o desafio grande e desenvolver um
sistema sem o devido planejamento no a melhor soluo. Se j complicado para um arquiteto de software e
sua equipe colocarem todos esses artefatos funcionando
em situaes normais de operao, imagine em momentos de instabilidade como excesso de usurios, falha de
hardware, indisponibilidade de rede ou banco de dados,
etc. Agora, imagine como colocar um sistema semelhante
em funcionamento sem planejar sua arquitetura?
Durante o desenvolvimento de um sistema o arquiteto ir se deparar com perguntas como: Qual
componente deve ser utilizado para integrar com o
legado? Ser que a interface de comunicao com o
ERP dever ser feita com web services ou ser melhor utilizar uma API proprietria do fabricante que
possui um melhor desempenho? H restries legais
para fazer uso de cdigo open source? Qual ser o
comportamento do sistema se a conexo com o banco
de dados ficar indisponvel? Perguntas como estas
precisam ser respondidas para que seja definida a
arquitetura do sistema.
66
Fique por dentro

Este artigo til para arquitetos de software que desejam conhecer
tcnicas que lhes ajudem a avaliar a arquitetura de um sistema, identificando suas principais camadas, componentes e seus relacionamentos,
e como alter-los sem afetar a continuidade do negcio. Durante o ciclo de vida de um software, uma coisa certa: haver mudanas. Como
consequncia dessas mudanas, temos as decises, que precisam ser
tomadas para atender aos requisitos especificados, decises estas que
devem ser cuidadosamente estudadas para no impactar negativamente na arquitetura do software, trazendo prejuzos ao desempenho,
escalabilidade e outros atributos de qualidade do sistema.
Deste modo, o ideal que as respostas sejam obtidas de forma

consciente e racional, baseadas em boas prticas, padres e experincia do arquiteto e da equipe, avaliando para cada deciso
o risco envolvido. Porm, as respostas que esto corretas hoje
podem no mais representar a melhor escolha amanh, pois o
negcio do cliente exige mudanas frequentes. Sendo assim, como
avaliar o impacto dessas mudanas dentro da atual arquitetura?
A incluso de uma nova funcionalidade poder degradar o desempenho do sistema?
Felizmente, a busca pelas respostas de questes como estas no
necessita de adivinhaes ou outro tipo de inspirao que no
seja o conhecimento. Para ajudar a obter essas respostas deve-se
escolher um mtodo de avaliao arquitetural e aplic-lo em seu
trabalho. A adoo de um mtodo no exige grandes transformaes na empresa e, na maioria das vezes, sua utilizao se d de
modo direto, sem dispendiosas adaptaes ao modelo de negcio,
$PQZSJHIU1SPJCJEPDPQJBSPVEJTUSJCVJS5PEPTPTEJSFJUPTSFTFSWBEPTQBSB%FW.FEJB
e abrange qualquer tipo de sistema de diversos segmentos de

mercado. Entretanto, os mtodos divergem no estilo e forma de
trabalho, podendo um mtodo ser mais detalhista e levar mais
tempo na sua execuo em relao a outro.
Com base nisso, neste artigo ser apresentado um mtodo que
auxilia os arquitetos de software e suas equipes na avaliao
arquitetural e na tomada de decises sobre a arquitetura. Este
mtodo foi escolhido por ser mais adequado a times que utilizam
metodologias geis e desejam que o impacto da avaliao seja o
menor possvel no prazo e custo durante o desenvolvimento do
software.
O que arquitetura de software?

Todo sistema de software tem uma arquitetura. Talvez ela
no seja do conhecimento de todos os envolvidos e no esteja
documentada. Talvez no tenha sido planejada e tenha sido
evoluda mediante diversas modificaes durante o ciclo de
vida do software. Mesmo assim, ainda podemos assegurar
categoricamente que a afirmativa verdadeira.
Para iniciar o entendimento sobre o que arquitetura de software, usaremos a definio do livro Software Architecture in
Practice. Apesar disso, existem dezenas de outras definies publicadas por outros autores, mas que acabam por passar um mesmo
conceito: Arquitetura de software a estrutura (ou estruturas) de
um sistema, construda por elementos (componentes) de software,
suas propriedades visveis externamente e dos relacionamentos
entre esses elementos..
Nessa definio, vale destacar o trecho relacionamento

entre esses elementos, ou seja, como ocorre a interao entre
as partes, pois a arquitetura precisa ser elaborada buscando o
baixo acoplamento para facilitar a substituio dessas partes,
quando necessrio, e no acarretar em elevados custos de
manuteno na reescrita de cdigo. Em sistemas modernos, a
interao ocorre atravs de interfaces, o que proporciona um
baixo acoplamento, visto que um componente no precisa conhecer os detalhes de implementao de outro para estabelecer
uma comunicao.
Para guiar a arquitetura do sistema possvel adotar alguns
padres, como client-server e 3-tier. Como recomendao para a
escolha de um padro arquitetural deve-se levar em considerao,
principalmente, os requisitos no funcionais, pois esto associados
a atributos de qualidade do sistema, como disponibilidade, manutenibilidade, flexibilidade, segurana, entre outros, e que por
vezes so difceis de identificar ou no esto bem documentados
quando comparados aos requisitos funcionais.
Alm disso, usar os requisitos no funcionais como ponto de
partida na definio de uma arquitetura traz benefcios, afinal,
no h uma regra que determine que uma arquitetura seja melhor do que outra sem que haja uma anlise de tais requisitos.
Por exemplo, para um sistema de e-commerce, escalabilidade e
portabilidade de plataformas so essenciais devido a sua caracterstica de acesso realizada por qualquer computador conectado
internet. Isso permite que um grande nmero de usurios acesse
67 67
Edio 137 tJava Magazine
Arquitetura de Software: Avaliando a arquitetura de seus sistemas
o sistema simultaneamente utilizando um navegador web em

plataformas heterogneas (Windows, Linux, Mac). Neste cenrio,
uma arquitetura 3-camadas forte candidata como padro arquitetural da soluo, visto que a separao das camadas cliente e
negcios (servios) proporciona a utilizao de uma interface web
acessvel a qualquer navegador, alcanando assim a portabilidade
desejada, como tambm proporciona a escalabilidade da camada
de negcios utilizando servidores em cluster para atender a demanda dos usurios simultneos.
Por sua vez, um sistema batch que precisa importar informaes de arquivos texto para um banco de dados relacional tem
como requisitos fundamentais trabalhar com grandes volumes
de dados e ter baixa latncia de rede. Neste cenrio, uma arquitetura client-server poder ser o padro escolhido para atender
s necessidades da soluo.
Portanto, importante que a escolha de um padro arquitetural
seja cuidadosa, para evitar que seja tomada uma deciso equivocada e que pode levar a uma mudana muito cara no futuro.
Avaliao arquitetural
sabido que alteraes em sistemas so mais baratas se forem
realizadas no incio. Quanto mais cedo forem encontrados os
problemas, menor ser o custo envolvido na correo dos mesmos.
Esta mxima tambm vlida para a arquitetura de software,
pois tentar incluir qualidade posteriormente a um sistema um
grande desafio, de maneira que a qualidade deve estar incorporada desde o princpio.
Sendo assim, avaliar a arquitetura de um software no uma
tarefa a ser realizada somente no incio do desenvolvimento
do sistema. A avaliao deve ocorrer durante todo o seu ciclo
de vida.
medida que um software necessita de mudanas para atender
ao negcio do cliente, a arquitetura precisa ser reavaliada para
ajudar na tomada de deciso sobre onde e como devem ser realizadas essas mudanas, de modo que no haja degradao nos
atributos de qualidade do software.
Uma arquitetura mal projetada ou que no tenha recebido a
devida ateno pode levar um projeto ao fracasso. Se um sistema
construdo com uma arquitetura que no permita a escalabilidade,
ele poder funcionar bem para uma dezena de usurios simultneos. Entretanto, se este mesmo sistema necessitar de expanso
para atender a milhares de usurios, podem ocorrer problemas
se no houver uma avaliao arquitetural adequada para viabilizar esta mudana. Afinal, a arquitetura no foi projetada para
este novo cenrio e o sistema no funcionar adequadamente e
apresentar falhas como lentido e indisponibilidade para seus
usurios, trazendo prejuzos e insatisfao ao cliente.
Analisando cuidadosamente as alteraes necessrias para evitar
problemas como os mencionados, certamente sero observados
benefcios que justificam o investimento de tempo na avaliao
de uma arquitetura. Entre eles, podemos destacar:
Financeiro: em mdia, estima-se que uma avaliao arquitetural
resulte na reduo de 10% dos custos de um projeto;
68
Compreenso: a tarefa de analisar a arquitetura fora os envolvidos a documentar e compreender a arquitetura do sistema,
convergindo o conhecimento da equipe;
Justificar decises: se um arquiteto questionado sobre um
sistema no possuir alta disponibilidade, fcil justificar a deciso
desse requisito no ter sido includo na arquitetura por algum
fator limitante (ex.: custo do projeto). Logo, as decises tomadas
e registradas pelo arquiteto com base em documentos e reunies
durante a fase de definio da arquitetura do sistema esto embasadas em critrios tcnicos e de conhecimento de todos;
Detectar problemas com antecedncia: identificar os principais problemas na fase inicial, reduzindo os custos de correo
no futuro;
Validao dos requisitos: possibilita confrontar a arquitetura
com os requisitos especificados, de modo a verificar a sua aderncia;
Melhoria contnua: a constante avaliao arquitetural proporcionar empresa o domnio das tcnicas de avaliao e maior
conhecimento por parte da equipe. Deste modo, resultar em
arquiteturas com maior qualidade, alm de disseminar a cultura
entre os desenvolvedores.
Apesar dos benefcios citados, boa parte das empresas ainda
no pratica a avaliao arquitetural em seus sistemas. Um dos
principais fatores para que isso ocorra a grande adoo de metodologias geis, que no encorajam a utilizao de mtodos de
avaliao arquitetural por acreditar que ser consumido muito
tempo e recurso.
Mtodos de avaliao arquitetural

Pesquisadores de universidades e institutos internacionais realizam pesquisas com o intuito de criar mtodos para avaliao
arquitetural de software e ento aplic-los em projetos reais de
diferentes segmentos e tamanhos. Atravs desses estudos, tais
mtodos so testados e melhorados para atender ao mercado.
Infelizmente, no existe um mtodo que atenda a todas as equipes e metodologias de desenvolvimento de software. preciso
experimentar alguns at encontrar aquele que mais se adapte ao
seu cenrio e sua forma de trabalho para que seja produtivo e
ajude a resolver problemas ao invs de causar prejuzos.
Dentre as dezenas de mtodos disponveis, podemos destacar
o j consagrado ATAM e o recm-desenvolvido DCAR. Ambos
sero abordados rapidamente neste artigo, e o foco principal ser
dado ao DCAR, por apresentar uma proposta mais prxima s
metodologias utilizadas atualmente nas empresas desenvolvedoras de software.
ATAM
Dentre os vrios mtodos que podem ser adotados para avaliar
uma arquitetura de software, um dos mais conhecidos o ATAM
(Architecture Tradeoff Analysis Method), desenvolvido em 2000 pelo
Software Engineering Institute (SEI) da Universidade Carnegie
Mellon.
Seu principal foco est em realizar uma avaliao da arquitetura

considerando os atributos relacionados qualidade de software.
Tem como caracterstica ser um mtodo baseado em cenrios, onde
so criadas situaes de uso do sistema. Por exemplo, elabora-se
um cenrio no qual o sistema precise processar 10 mil transaes por segundo e ento se avalia o comportamento do sistema
nesse contexto. Se o sistema no atingir o atributo de qualidade
de desempenho, ento se estuda a arquitetura para realizar as
mudanas que permitam que o cenrio se concretize.
Neste exemplo, ao tentar alcanar o desempenho desejado, o
arquiteto perceber que isto somente ser vivel se o sistema
perder a flexibilidade na gerao de queries dinmicas em algumas partes. Esta situao demonstra que ocorreu um conflito
entre os atributos flexibilidade e desempenho, o que chamamos
de tradeoff. Em momentos como esse o arquiteto deve resolver
o tradeoff, optando por diminuir a flexibilidade do sistema para
conseguir o desempenho necessrio caso esta seja a deciso mais
adequada para o negcio.
O tempo de avalio de uma arquitetura, segundo dados do
ATAM, de trs a quatro dias, contando com uma equipe de
avaliadores treinados, arquitetos e interessados no sistema que
possam contribuir com a avaliao.
DCAR
Um mtodo de avaliao arquitetural mais recente o DCAR
(Decision-Centric Architecture Reviews). Esse mtodo promete ser
uma alternativa ao ATAM, sendo ideal para projetos que trabalham com metodologias geis, na tentativa de aproximar as equipes de desenvolvimento da prtica de avaliao arquitetural.
A proposta do DCAR ser um mtodo leve, de baixo impacto

no tempo e nos recursos do projeto e permitir a avaliao da
arquitetura com base em decises arquiteturais, sem a necessidade de testar a arquitetura em cenrios.
Segundo estimativas, as sesses de avaliao do DCAR so
curtas (metade de um dia de trabalho), contando com a presena de trs a cinco participantes, incluindo o arquiteto. Assim,
acaba sendo uma opo para projetos com tempo e oramento
limitados ou quando os interessados no tm disponibilidade
total para participar das reunies.
Neste artigo, por ser mais recente do que o ATAM e mais adequado s equipes que utilizam metodologias geis em seu ciclo
de desenvolvimento de sistemas de software, ser apresentado
o mtodo DCAR para avaliao arquitetural.
Momento de deciso
Ao desenvolver um sistema a equipe ter que tomar uma srie
de decises para a construo deste. As escolhas vo desde a
linguagem a ser adotada, o gerenciador de banco de dados,
frameworks e se sero utilizados componentes open source.
Basicamente, essas decises arquiteturais so as escolhas
que um arquiteto de software dever tomar baseado em foras como custo e segurana que atuam no projeto. Tais foras
exercem influncia direta, mas nem sempre esto claras para
os interessados.
A equipe responsvel pelo sistema no deve analisar isoladamente uma deciso, pois ela pode estar inter-relacionada a
outras. Assim, deve-se analisar o conjunto e procurar combinlas para atingirem um mesmo objetivo.
69 69
Edio 137 tJava Magazine
Um exemplo dessa influncia a opo por utilizar um banco

de dados em memria para obter um rpido tempo de resposta.
Note que esta deciso gera um impacto negativo na confiabilidade, pois caso o sistema entre em colapso pode ocorrer perda de
informao. Para minimizar o problema o arquiteto poder optar
por manter uma rplica dos dados.
Compreender essa relao entre as decises de grande importncia, pois auxilia na identificao de decises que sofrem
influncias de outras e podem ter consequncias em grande parte
da arquitetura.
Portanto, toda deciso que for identificada precisa ser avaliada
pela equipe. Ao analis-las, restries como riscos, consideraes
da organizao, preferncias pessoais, experincia e objetivos
de negcios influenciaro nas decises arquiteturais, sendo o
arquiteto o responsvel por resolver possveis conflitos, sempre
buscando o consenso para chegar a uma deciso final.
importante ressaltar que tais foras no so imutveis. Sendo
assim, durante a execuo do projeto uma fora pode perder relevncia por mudanas em requisitos ou fatores externos empresa,
como leis e regulamentaes impostas pelo governo.
Nesse contexto, o DCAR ir ajudar apoiando a anlise das decises arquiteturais. E como detalhamento disso, sero mostrados
seus passos, templates e sua dinmica na avaliao arquitetural
de um sistema de software.
Introduo ao DCAR
sd Dynamic View
Passo 1: Preparao
Passo 2: Introduo ao DCAR
Passo 3: Apresentao do negcio
Passo 4: Apresentao da arquitetura
Passo 5: Refinamento das foras e decises
Passo 6: Priorizao das decises
O DCAR um mtodo sequencial composto por apenas nove

passos bem definidos que guiam a sua execuo. Cada um desses
passos similar a um processo, onde so definidas as entradas,
os participantes e as sadas que serviro de entrada para o passo
seguinte. A Figura 1 mostra o fluxo desse mtodo.
Esse diagrama demonstra que o DCAR um mtodo iterativo,
sendo cada iterao representada por um passo. Isso torna o
mtodo simples de aplicar, pois ele segue um fluxo contnuo,
direto, sem desvios.
Outro ponto positivo sobre o DCAR que se trata de um mtodo enxuto, que exige uma equipe reduzida para sua execuo.
Alm disso, em muitos dos passos as equipes no precisam estar
reunidas ao mesmo tempo, permitindo com isso uma otimizao
dos recursos humanos envolvidos.
Passo 7: Documentao das decises
Passo 8: Av aliao das decises
Passo 9: Retrospectiv a e relatrio final
Figura 11BTTPTEPNUPEP%$"3
Basicamente, recomenda-se a participao do arquiteto e um
ou dois membros do time de desenvolvimento que tenham diferentes papis ou responsabilidades. Por exemplo, podem participar um desenvolvedor e um analista de requisitos. Tambm
importante que algum represente o papel do cliente, podendo
ser o Product Owner de uma equipe gil, pois ele possui um
amplo conhecimento do negcio do cliente e poder identificar
as foras do ponto de vista do negcio que influenciaro nas
70 Java Magazine t Edio 137
70
decises da arquitetura, como a fora time-to-market, que

sinaliza o tempo entre o planejamento de um sistema e sua
disponibilizao no mercado.
Note que em cada passo do diagrama do DCAR h uma tarefa
de reviso das decises que foram escolhidas. Para as revises,
a equipe responsvel deve ser externa ao time, podendo ser
da mesma organizao ou de uma consultoria especializada.
importante que essa equipe de revisores tenha boa experincia
em projetos de arquitetura. Se possurem conhecimentos na mesma rea de domnio a qual o sistema est sendo desenvolvido,
excelente, mas isso no imprescindvel.
A seguir sero abordados com mais detalhes cada passo do
DCAR apresentado no diagrama.
Passo 1 - Preparao
Este passo bem simples e no h necessidade de realizar uma
reunio entre os envolvidos. Nele, o arquiteto deve preparar uma
apresentao do sistema a ser avaliado contendo os pontos mais
relevantes da arquitetura, numa viso de alto nvel. Para ajudar
na compreenso da informao pela equipe recomendvel que
o arquiteto utilize padres e tecnologias conhecidas ou previstas na arquitetura, como servidores de aplicao e de banco de
dados, de modo a ilustrar o problema com artefatos comuns e
que j fazem parte do conhecimento das pessoas, e apresente as
principais decises tomadas durante o design da arquitetura, as
mudanas esperadas, os riscos, etc.
O representante do cliente (Product Owner, por exemplo) deve
preparar uma apresentao mostrando a perspectiva do cliente,
buscando descrever as principais caractersticas do produto,
diferenciais para o negcio, possveis restries e atributos de
qualidade desejveis, como desempenho, disponibilidade, segurana, capacidade de mudana, interoperabilidade, etc.
O time de reviso deve receber essas apresentaes antes
da prxima etapa para que possam estud-las e avali-las.
O objetivo encontrar potenciais decises que ajudem a definir
a arquitetura e as principais foras que atuam sobre o sistema.
Se existirem documentaes adicionais sobre o sistema, estas
podero ser encaminhadas para o time de reviso para ajudar
na compreenso.
Passo 2 - Introduo ao DCAR

O objetivo aqui apresentar o mtodo DCAR a todos os envolvidos. Para isso, realiza-se uma breve introduo ao DCAR,
explicao do fluxo dos nove passos do mtodo, denominao
dos papis e atribuio das responsabilidades a cada participante. A ideia fazer com que todos os participantes conheam
como o mtodo funciona, a importncia de cada um dentro do
processo e a dedicao que ser necessria.
Evidentemente, esta introduo muito importante para as
primeiras experincias com o DCAR. medida que o mtodo
torna-se parte integrante do processo de desenvolvimento e as
pessoas envolvidas j estejam habituadas, este passo pode ser
pulado ou reduzido sem prejuzos ao projeto.
Passo 3 - Apresentao do negcio

A apresentao do negcio um passo importante da avaliao. Atravs dele, o representante do cliente vai mostrar a
todos os membros da equipe qual a importncia do sistema
do ponto de vista do negcio, utilizando os slides elaborados
no primeiro passo.
O objetivo identificar as principais foras de deciso que
esto relacionadas ao negcio e que devem ser consideradas durante a avaliao. Ou seja, trabalha-se para encontrar foras que
vo exigir da arquitetura solues para resolver questes como
reduo de custos de implementao, alta disponibilidade,
escalabilidade para atender a picos de demanda, entre outras
foras ligadas ao negcio do cliente. Uma dica sempre associar
essas foras a uma possvel perda financeira caso a arquitetura
no cumpra o papel exigido para resolver esses problemas,
pois se o impacto financeiro maior, maiores so as chances
de investimento da empresa na soluo do problema.
Durante um perodo de aproximadamente 20 minutos de
apresentao o time de revisores pode tirar dvidas, anotando
potenciais foras apresentadas e identificando outras novas
com base em suas experincias.
Aps a apresentao no h necessidade do representante do
cliente permanecer na sesso, mas poder ficar caso considere
que ajudar com esclarecimentos.
O resultado deste passo a elaborao de uma lista com as foras
que influenciaro as decises arquiteturais do prximo passo.
Passo 4 - Apresentao da arquitetura

Utilizando os slides gerados no Passo 1 - Preparao, o arquiteto
apresenta a arquitetura para os participantes durante aproximadamente 50 minutos. A ideia principal demonstrar uma
viso geral da arquitetura proposta. Assim como ocorre na
apresentao do negcio, o time de reviso dever questionar
a arquitetura para esclarecer pontos identificados durante a
anlise dos slides que todos os envolvidos receberam antecipadamente ao final do primeiro passo.
Nessa etapa do mtodo importante que a equipe de reviso
tenha experincia em identificar decises arquiteturais para
poder question-las junto ao arquiteto. Deve-se trabalhar com
foco na identificao das tecnologias utilizadas propostas pela
arquitetura, como servidores, linguagens, frameworks e componentes de terceiros, e na busca de padres arquiteturais.
Ao final desse passo, os revisores devero elaborar uma
lista com as foras e decises identificadas nos passos 1, 3 e 4,
pois a equipe j teve seu primeiro contato com a arquitetura
proposta e os requisitos do negcio. Essa lista ser revisitada
no passo seguinte.
Passo 5 - Refinamento das foras e decises

De posse das informaes levantadas anteriormente, o objetivo
identificar a relao entre as decises arquiteturais e resolver
conflitos que possam ocorrer entre os demais relacionamentos
definidos nos passos anteriores.
71
Para ajudar nessa etapa, um diagrama UML pode ser utilizado

como ferramenta para ilustrar essa relao entre as decises,
pois sem uma ferramenta desse tipo pode ser muito difcil de
captur-las, visualiz-las. Na Figura 2 temos um exemplo de
diagrama que mostra os relacionamentos. Cada elipse representa uma deciso contendo uma breve descrio para facilitar
a identificao.
O diagrama de relacionamento de deciso deve ser ajustado e
criticado pelos envolvidos at que todos os participantes tenham
uma compreenso clara das decises e de seus impactos na arquitetura. Enquanto houver dvidas sobre os relacionamentos ou as
pessoas do time no chegarem a um acordo se uma deciso deve
ser realmente descartada, o grupo deve alterar o diagrama at que
haja consenso sobre as decises e os relacionamentos.
Vale ressaltar que uma deciso arquitetural pode surgir influenciada por outra, como tambm pode perder importncia porque
outra deciso inviabilizou sua escolha. Apesar de existirem diferentes tipos de relacionamentos, as relaes caused by e depends on
exercero maior influncia nas decises arquiteturais que sero
escolhidas ao final.
Alm disso, importante reforar que para cada deciso deve
haver uma ou mais foras que justifiquem a sua escolha, pois as
foras esto diretamente associadas ao negcio. E se a arquitetura
no atende ao negcio, o resultado no trar os benefcios esperados

pelo cliente.
preciso ter conhecimento sobre quais foras determinada
deciso ataca. Para isso, elas precisam estar detalhadas considerando o ponto de vista do negcio, no havendo ambiguidades. Nesse contexto, a utilizao de termos que fazem parte
do domnio do cliente ajuda a evitar erros de interpretao.
Sendo assim, prefira descrever as foras como emisso de 120
notas fiscais por segundo, em vez de cinco mil transaes
por segundo.
Nota
As relaes caused by indicam que uma deciso surgiu por influncia de outra. Por exemplo, no
diagrama decidiu-se pela utilizao de EJB 3.1 devido relao causada pelo uso de JPA no
mapeamento objeto/relacional. Porm, seria possvel utilizar JPA com Hibernate ao invs de EJB.
Assim, a deciso causadora (JPA) exerce influncia pelo uso de EJB, mas permite alternativas com
considervel grau de flexibilidade.
As relaes depends on so mais rgidas quando comparadas s caused by. No exemplo, ao
decidir sobre o uso de EJB, automaticamente criou-se a dependncia de um container Java EE 6,
sendo o GlassFish o escolhido. Mesmo que fosse utilizado outro container, este deveria suportar a
especificao Java EE 6 do mesmo modo que o GlassFish para permitir a execuo de componentes
EJB. Assim, a flexibilidade limitada ou, em alguns casos, at mesmo nula.
Figura 2%JBHSBNBEFSFMBDJPOBNFOUPEFEFDJTP
72
Nome
Redundncia de servidores
Problema
A aplicao deve executar mesmo se o servidor falhar
Soluo ou descrio da
deciso
O sistema implantado em dois servidores com a mesma configurao, porm um est ativo e outro inativo. O servidor ativo
prov todos os servios do sistema, enquanto o segundo servidor atua em modo passivo, nos bastidores. Quando o servidor ativo
falhar, o inativo passa a ser o ativo e assume as atividades. Durante a operao do sistema uma atualizao dos dados ser realizada
periodicamente entre os servidores para manter o status das informaes. A soluo proposta segue o padro de redundncia de
funcionalidade.
Solues alternativas
consideradas
Ambos os servidores esto ativos. Externamente, h um balanceamento de carga que decide qual dos servidores atender as requisies dos servios. Entretanto, esta soluo causar mudanas maiores no sistema. Apesar do aumento da disponibilidade oferecido
pela soluo, isso causar um impacto nos custos no qual o cliente no est preparado para assumir. Alm disso, o mecanismo de
balanceamento de carga pode apresentar um ponto de falha nico. Por esses motivos, esta alternativa foi descartada.
Foras a favor da deciso
t*NQMFNFOUBPNBJTGDJMFDPNNFOPSDVTUP TFDPNQBSBEBTPMVPBMUFSOBUJWB
t1PEFTFSFTUFOEJEPGBDJMNFOUFQBSBPVUSBTWFSTFTEPTJTUFNB POEFBSFEVOEODJBOPVUJMJ[BEB
t4FNJODJEODJBEFDVTUPTBEJDJPOBJT
Foras contra a deciso
t0QSPDFTTPEFUSPDBEFTFSWJEPSFTMFOUP
t%JGJDVMEBEFFNPGFSFDFSBMUBEJTQPOJCJMJEBEFNBJPSRVFBBUVBM RVFEF
Classificao
Verde
Amarelo
Amarelo
Vermelho
Justificativa
A soluo proposta
aceitvel
Preocupa o tempo de troca

dos servidores em caso
de falha
Soluo baseada em um
padro reconhecido. Disponibilidade pode vir a ser
um problema no futuro.
Essa deciso precisa ser reavaliada, pois

o prximo release do sistema possui
requisitos de alta disponibilidade.
Tabela 1&YFNQMPEFEPDVNFOUBPEFEFDJTPEP%$"3
Passo 6 - Priorizao das decises

Dependendo do tamanho e da complexidade do sistema que se
est estudando a arquitetura, a lista de decises pode ficar um
pouco grande para ser analisada, podendo passar de uma centena
de decises. Deste modo, torna-se praticamente invivel analisar
todas as decises, pois demandar muito tempo e dificilmente o
grupo chegar a um consenso. Assim, haver a necessidade de realizar uma negociao para eleger as decises mais prioritrias.
Um bom critrio para priorizar as decises considerar aquelas
de misso crtica, de alto risco e que tenham um impacto maior
no custo do projeto e maior retorno financeiro.
Para auxiliar nesse processo de priorizao, deve-se fazer uma
votao das decises, onde cada participante ter 100 pontos para
distribuir entre as decises listadas considerando os critrios de
priorizao. Ao final, levam-se para o prximo passo entre sete e
dez decises com maior pontuao.
Passo 7 - Documentao das decises

o momento de documentar as decises que receberam pontuao mais alta no passo anterior. Para isso, o arquiteto e demais
participantes devem dividi-las entre si de modo que cada participante tenha de duas a trs decises para documentar dentro da
arquitetura. Vale ressaltar que os participantes devem documentar
as decises que eles possuam mais conhecimento sobre o assunto.
Por exemplo, se uma deciso for sobre a utilizao de um banco
de dados NoSQL, ento a pessoa da equipe que ir document-la
deve conhecer o assunto bancos de dados no relacionais.
Neste documento, a equipe deve descrever a soluo arquitetural adotada, o problema que essa deciso prope solucionar,
demonstrar alternativas viveis e as foras que devem ser consideradas para avaliao da deciso. A lista de foras utilizadas
a que foi elaborada no passo 5, mas novas foras podem ser
adicionadas caso seja necessrio. Na Tabela 1 apresentado
um modelo para documentao das decises do DCAR.
As decises so documentadas conforme o modelo da Tabela 1.
Para cada deciso deve haver informaes como nome, o
problema ao qual ela pretende solucionar, a soluo proposta,
uma soluo alternativa e foras que vo pesar a favor e contra
essa deciso. Depois de documentadas, as decises passam ao
prximo passo para serem classificadas e justificadas.
Passo 8 - Avaliao das decises

Aps a documentao das decises necessrio avali-las
conforme sua escala de prioridades. Nesta etapa, cada participante responsvel por documentar a deciso de acordo com
seu grau de experincia dever apresentar a soluo para os
demais. Nesse momento, todos os envolvidos devem ouvir a
explicao e a soluo proposta pelo membro da equipe. Havendo necessidade, possvel ajustar o documento durante a
explicao para corrigir alguns pontos que no ficaram claros
na escrita.
Em seguida, os participantes avaliam a soluo proposta levando
em considerao as foras que atuam a favor e contra a deciso.
Com base nessas informaes, cada participante que est avalian-
73
do a soluo dever dar o seu parecer escolhendo uma cor da linha

de classificao e apresentando a sua justificativa.
As cores da classificao (verde, amarelo e vermelho) iro indicar
se a soluo ser implementada ou ter que ser revista. A cor verde
indica que o avaliador considerou a soluo boa e que deve ser
adotada. O amarelo indica que a soluo aceitvel, mas existem
algumas observaes que precisam ser tratadas. E o vermelho
indica que a soluo deve ser reavaliada.
Se houver alguma situao em que os avaliadores classifiquem
a soluo com cores diferentes, ou seja, no existindo uma unanimidade por parte da equipe, ento a deciso discutida por
cerca de 20 minutos. Durante esse tempo, se ainda no houver
um consenso, a soluo dever aguardar mais alguns instantes e
ser reavaliada em um segundo momento.
Esse passo tem uma caracterstica diferente dos demais passos
do mtodo DCAR porque possui um loop. Isso sinaliza que o
processo s poder seguir para o passo seguinte aps todas as
decises prioritrias terem sido avaliadas e terem alcanado um
consenso. Enquanto existir uma deciso em estudo pelos avaliadores, o processo permanecer nesta etapa.
Esses benefcios vo desde uma melhor compreenso dos requisitos no funcionais por parte da equipe de desenvolvimento, at
uma reduo de custos do projeto e uma melhoria da qualidade
do sistema.
A partir do mtodo DCAR, a realizao da avaliao arquitetural pode ser feita de forma simples, rpida e sem altos custos
de execuo. Estatsticas apontam que a avaliao de um sistema
com 600 mil linhas de cdigo pode ser feita por uma equipe com
oito pessoas consumindo em mdia 40 horas por integrante. Com
base nestes nmeros no difcil convencer o cliente ou o patrocinador do projeto a realizar a avaliao da arquitetura durante
ciclo de vida do sistema, tendo em vista os resultados que podem
ser alcanados.
Alm disso, a avaliao auxilia na criao indolor da documentao da arquitetura, que de grande importncia para o arquiteto
quando o mesmo for questionado sobre as decises tomadas no
passado e tambm o ajudar a implementar solues no futuro
para atender a novas necessidades de negcio.
Autor
Regis Santos
regisan@gmail.com
%FTFOWPMWFEPS+BWBDPNNBJTEFBOPTEFFYQFSJODJBFQT
HSBEVBPFN"SRVJUFUVSBEF4PMVFT1PTTVJDFSUJGJDBFTOB
QMBUBGPSNB+BWB 4$+1 4$8$%F4$#$%

Passo 9 - Retrospectiva e relatrio final

Nessa ltima etapa, todas as decises de maior prioridade j
foram documentadas e avaliadas. Todos os documentos de deciso elaborados, planilhas com as votaes de priorizao das
decises e outros documentos importantes para a definio da
arquitetura que foram gerados durante a execuo do mtodo
DCAR, sero compilados em um relatrio pelo time de reviso e
ser apresentado ao arquiteto do sistema em at duas semanas,
no devendo se estender mais do que esse perodo para no comprometer o andamento e o custo do projeto. Nesse novo encontro
entre o arquiteto e o time de reviso, sero checadas as decises e
as solues escolhidas para serem implementadas. Eventualmente,
algum refinamento pode ser realizado ainda neste passo para
melhoria da soluo.
Enfim, vale ressaltar que a realizao da avaliao arquitetural
pode trazer reais benefcios para a construo de um sistema
de software, seja qual for a linguagem, plataforma ou tipo de
negcio do cliente.
74
Links:
Decision-Centric Architecture Evaluation.
http://www.dcar-evaluation.com/
Artigo Decision-Centric Architecture Reviews
http://www.cs.rug.nl/paris/papers/IEEESW14b.pdf
Voc gostou deste artigo?

%TFVWPUPFNwww.devmedia.com.br/javamagazine/feedback
"KVEFOPTBNBOUFSBRVBMJEBEFEBSFWJTUB

Arquitetura de Software

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Arquitetura de Software

Diunggah oleh

Hak Cipta:

Format Tersedia

Arquitetura de Software:

laborar a arquitetura de um software pode ser

Fique por dentro

Deste modo, o ideal que as respostas sejam obtidas de forma

e abrange qualquer tipo de sistema de diversos segmentos de

O que arquitetura de software?

Nessa definio, vale destacar o trecho relacionamento

Edio 137 tJava Magazine

Arquitetura de Software: Avaliando a arquitetura de seus sistemas

o sistema simultaneamente utilizando um navegador web em

Mtodos de avaliao arquitetural

Seu principal foco est em realizar uma avaliao da arquitetura

A proposta do DCAR ser um mtodo leve, de baixo impacto

Edio 137 tJava Magazine

Arquitetura de Software: Avaliando a arquitetura de seus sistemas

Um exemplo dessa influncia a opo por utilizar um banco

Passo 2: Introduo ao DCAR

Passo 3: Apresentao do negcio

Passo 4: Apresentao da arquitetura

Passo 5: Refinamento das foras e decises

Passo 6: Priorizao das decises

O DCAR um mtodo sequencial composto por apenas nove

Passo 7: Documentao das decises

Passo 8: Av aliao das decises

Passo 9: Retrospectiv a e relatrio final

70 Java Magazine t Edio 137

decises da arquitetura, como a fora time-to-market, que

Passo 2 - Introduo ao DCAR

Passo 3 - Apresentao do negcio

Passo 4 - Apresentao da arquitetura

Passo 5 - Refinamento das foras e decises

Arquitetura de Software: Avaliando a arquitetura de seus sistemas

Para ajudar nessa etapa, um diagrama UML pode ser utilizado

no atende ao negcio, o resultado no trar os benefcios esperados

A aplicao deve executar mesmo se o servidor falhar

Foras a favor da deciso

Foras contra a deciso

Preocupa o tempo de troca

Essa deciso precisa ser reavaliada, pois

Passo 6 - Priorizao das decises

Passo 7 - Documentao das decises

Passo 8 - Avaliao das decises

Arquitetura de Software: Avaliando a arquitetura de seus sistemas

do a soluo dever dar o seu parecer escolhendo uma cor da linha

Passo 9 - Retrospectiva e relatrio final

Voc gostou deste artigo?

Anda mungkin juga menyukai