Avaliando a arquitetura
de seus sistemas
Conhea neste artigo um mtodo para avaliao
de arquitetura de software que ajuda nas tomadas
de deciso
66
$PQZSJHIU1SPJCJEPDPQJBSPVEJTUSJCVJS5PEPTPTEJSFJUPTSFTFSWBEPTQBSB%FW.FEJB
$PQZSJHIU1SPJCJEPDPQJBSPVEJTUSJCVJS5PEPTPTEJSFJUPTSFTFSWBEPTQBSB%FW.FEJB
67 67
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.
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.
$PQZSJHIU1SPJCJEPDPQJBSPVEJTUSJCVJS5PEPTPTEJSFJUPTSFTFSWBEPTQBSB%FW.FEJB
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.
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.
$PQZSJHIU1SPJCJEPDPQJBSPVEJTUSJCVJS5PEPTPTEJSFJUPTSFTFSWBEPTQBSB%FW.FEJB
69 69
Introduo ao DCAR
sd Dynamic View
Passo 1: Preparao
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
$PQZSJHIU1SPJCJEPDPQJBSPVEJTUSJCVJS5PEPTPTEJSFJUPTSFTFSWBEPTQBSB%FW.FEJB
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.
$PQZSJHIU1SPJCJEPDPQJBSPVEJTUSJCVJS5PEPTPTEJSFJUPTSFTFSWBEPTQBSB%FW.FEJB
71
Figura 2%JBHSBNBEFSFMBDJPOBNFOUPEFEFDJTP
72
$PQZSJHIU1SPJCJEPDPQJBSPVEJTUSJCVJS5PEPTPTEJSFJUPTSFTFSWBEPTQBSB%FW.FEJB
Nome
Redundncia de servidores
Problema
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.
t*NQMFNFOUBPNBJTGDJMFDPNNFOPSDVTUP
TFDPNQBSBEBTPMVPBMUFSOBUJWB
t1PEFTFSFTUFOEJEPGBDJMNFOUFQBSBPVUSBTWFSTFTEPTJTUFNB
POEFBSFEVOEODJBOPVUJMJ[BEB
t4FNJODJEODJBEFDVTUPTBEJDJPOBJT
t0QSPDFTTPEFUSPDBEFTFSWJEPSFTMFOUP
t%JGJDVMEBEFFNPGFSFDFSBMUBEJTQPOJCJMJEBEFNBJPSRVFBBUVBM
RVFEF
Classificao
Verde
Amarelo
Amarelo
Vermelho
Justificativa
A soluo proposta
aceitvel
Soluo baseada em um
padro reconhecido. Disponibilidade pode vir a ser
um problema no futuro.
Tabela 1&YFNQMPEFEPDVNFOUBPEFEFDJTPEP%$"3
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.
$PQZSJHIU1SPJCJEPDPQJBSPVEJTUSJCVJS5PEPTPTEJSFJUPTSFTFSWBEPTQBSB%FW.FEJB
73
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$#$%
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
$PQZSJHIU1SPJCJEPDPQJBSPVEJTUSJCVJS5PEPTPTEJSFJUPTSFTFSWBEPTQBSB%FW.FEJB