40 Engenharia de Software Magazine - Ciclo de Vida da Gesto em Arquitetura de Software

Eros Viggiano
eros.viggiano@arkhi.com.br
No ramo de TI desde 1991, trabalha com
consultoria e ensino de arquitetura de sof-
tware. Atua principalmente nas reas de te-
lecomunicaes e finanas como arquiteto de
software. coordenador e professor do curso
de Estratgias em Arquitetura de Sistemas no
IGTI e professor do IEC/PUC Minas. bacharel
em Cincia da Computao (DCC/UFMG) e es-
pecialista em Engenharia de Software (DCC/
UFMG). Algumas certificaes profissionais
relevantes: Sun Certified Enterprise Architect
(SCEA), IBM Rational Unified Process 7 (RUP).
Marco Aurlio S. Mendes
marco.mendes@arkhi.com.br
No ramo de TI desde 1990, trabalha com con-
sultoria e ensino de engenharia de software.
Possui treze anos de experincia Java e atua
profissionalmente nas reas de melhoria
de processos de software e arquitetura de
software. coordenador e professor do curso
de Estratgias em Arquitetura de Sistemas
no IGTI e professor do IEC/PUC Minas. Possui
formao como bacharel e mestre em Cin-
cia da Computao (DCC/UFMG). Algumas
certificaes profissionais relevantes: IBM
SOA Certified Solution Designer, IBM Rational
Unified Process 7 (RUP).
De que se trata o artigo?
O artigo apresenta um ciclo de vida para a gesto
das atividades de arquitetura de software em um
projeto, de forma a gerar maior valor de negcios
para um projeto, produto ou empresa.
Para que serve?
Conhecer e aplicar as atividades essenciais da arqui-
tetura de software em um projeto, tais como: garan-
tir o alinhamento tcnico do projeto organizao,
atender s restries de custo, tempo e qualidade
de um projeto, identifcar e desenvolver requisitos
arquiteturalmente signifcativos, antecipar e mitigar
riscos tcnicos, realizar a anlise e desenho arqui-
tetural, construir provas de conceito, gerar cdigo
executvel, orientar e acompanhar o time tcnico,
validar a estabilidade da arquitetura executvel e
coletar lies aprendidas para o prximo ciclo de
atividades arquiteturais.
Em que situao o tema til?
No desenvolvimento de projetos de software
no triviais, na montagem de novos produtos, na
evoluo de tecnologias de produtos, em manu-
tenes evolutivas complexas e, sobretudo, em
esforo de aumento de alinhamento das aes de
TI com as reas de negcio de uma organizao.
Ciclo de Vida da Gesto em
Arquitetura de Software
Maximizando a gerao de valor de projetos e produtos com arquiteturas de software
A
arquitetura de software uma
rea recente dentro da enge-
nharia de software, tendo seus
primrdios na literatura no comeo da
dcada de 90. No obstante, ela tem
obtido cada vez mais visibilidade nos
projetos de TI no Brasil. cada vez mais
comum que empresas e projetos tenham
pessoas ou times exercendo o papel do
arquiteto de software e atividades em
cronogramas relacionadas ao desenho
de uma arquitetura de software. Mas o
que a arquitetura de software e quais
so as atividades que devem ser rea-
lizadas pelo arquiteto de software? A
arquitetura uma atividade puramente
tcnica? Criar uma arquitetura de sof-
tware apenas modelar diagramas e
implementar provas de conceito? A ar-
quitetura de software produz realmente
valor de negcio para um projeto? E
como poderamos organizar as ativi-
dades de arquitetura de software para
gerar valor concreto para um projeto,
produto ou organizao?
Este artigo enderea estas e outras
questes sobre as atividades de arqui-
tetura de software e prope um ciclo de
Edio 14 - Engenharia de Software Magazine 41
ARQUI TETURA DE SOFTWARE
vida para organizao e ordenao temporal destas atividades
em projetos de software de qualquer natureza, com o uso de
qualquer tipo de processo de software.
primeira vista, podemos imaginar que arquitetar um software
escolher que tecnologias um projeto ir adotar, como por exemplo,
Java EE ou .NET. Esta viso mope, difundida por arquitetos empi-
lhadores de frameworks, no pode estar mais longe da realidade.
Em uma segunda anlise, podemos imaginar que a arquitetura de
software consiste de montarmos modelos em linguagens sofisti-
cadas como UML2. Esta viso estrbica difundida por arquitetos
de papel tambm est bem longe da verdade.
Coloquemos lentes de correo na viso de arquitetura de
software, que foi inicialmente delineada no excelente livro
Software Architecture: Perspectives on an Emerging Discipli-
ne, ainda em 1996. A arquitetura de software tem por objetivo
fazer o melhor uso dos recursos tcnicos de um projeto para
garantir a maior eficincia possvel aos objetivos do projeto,
produto e mesmo viso e misso de uma empresa.
Podemos identificar, nesta viso, atividades tais como:
garantir o alinhamento tcnico do projeto s diretrizes e
estratgias tecnolgicas de uma rea ou organizao, bem
como sua cultura organizacional;
atender as restries gerenciais de um projeto tais como
custo, prazo e competncias tcnicas da equipe;
identificar e detalhar requisitos significativos para a arqui-
tetura de software;
antecipar e mitigar os riscos tcnicos de um projeto;
realizar a anlise e desenho tcnico da arquitetura atravs
de tcnicas de modelagem arquitetural;
construir provas de conceito e gerar cdigo executvel para
os principais pontos de risco do projeto;
orientar e acompanhar o time tcnico para garantir a aderncia
do cdigo construdo s diretrizes arquiteturais do projeto;
validar a estabilidade e objetivos da arquitetura do produto;
coletar lies aprendidas e promover um novo ciclo de
melhorias.
Em verdade, o ciclo de vida da arquitetura de software deve
ser compreendido atravs de um processo mais amplo que
aspectos puramente tcnicos, que denominamos aqui como a
gesto da arquitetura de software.
Arquiteturas de software so sempre desenvolvidas dentro de um
contexto de negcios como, por exemplo, a criao ou evoluo de
um produto, a automao de processos de negcio ou a integrao
entre sistemas de fornecedores distintos. Assim como a arquitetura
de software realiza tecnicamente objetivos organizacionais, ela deve
prover feedback do mundo real conforme mostrado na Figura 1.
Ciclo de Vida da Gesto da Arquitetura de Software
O ciclo de vida de um projeto organiza as fases do incio ao
fim das atividades, conforme mostrado na Figura 2. Tipicamen-
te as transies entre fases so caracterizadas por algum tipo
de entrega e sua respectiva reviso. Para cada fase, o ciclo de
vida do projeto permite definir trabalho realizado, entregas,
envolvidos e critrios de aprovao e controle [1].
Figura 1. |nfluencias sobre a gestao da arquitetura de software
Figura 2. Fases tpicas de um projeto
No caso de projetos de desenvolvimento de software, o ciclo
de vida do projeto geralmente respeita um processo de desen-
volvimento de software como o IBM Rational Unified Process
(RUP). Mais adiante, abordaremos a relao dos processos de
desenvolvimento com a gesto da arquitetura de software.
Apresentaremos o ciclo de vida da gesto da arquitetura de sof-
tware alinhado ao ciclo de vida do projeto. Situaremos as principais
atividades desempenhadas pelo time de arquitetura durante toda
a execuo do projeto de desenvolvimento de software. Entretanto,
lembramos que a arquitetura de software pode abranger o escopo de
um produto, isto , alm do ciclo do projeto conforme mostrado no
quadro Ciclo de vida do produto versus ciclo de vida do projeto.
Ciclo de vida do produto versus ciclo de vida do projeto
O ciclo de vida do produto mais abrangente que o do projeto. Um produto pode ser criado e
evoludo por vrios projetos (ver Figura 3).
Figura 3. Pelaao entre produto e ciclo de vida de pro|eto (Ponte: PM8OK |l|)
As atividades da gesto da arquitetura de software so um
subconjunto das atividades executadas em um projeto de sof-
tware. A Figura 4 define os grupos de atividades do ciclo de
vida da gesto da arquitetura que evidenciamos como IDEA
(Iniciao-Definio-Edificao-Avaliao).
Figura 4. Grupos de atividades de |DLA, ciclo
de vida da gesto da arquitetura de software
42 Engenharia de Software Magazine - Ciclo de Vida da Gesto em Arquitetura de Software
Em um tpico projeto de desenvolvimento de software, as ativida-
des do grupo I (Iniciao) coincidem com as fases iniciais do projeto
e caracterizam o incio dos trabalhos arquiteturais. Os grupos D
(Definio) e E (Edificao) se intercalam nas fases intermedirias,
sendo que D visa definir e validar arquiteturas candidatas e, em E,
procura-se garantir que as arquiteturas esto sendo adequadamente
realizadas. Enfim, as atividades do grupo A (Anlise) ocorrem no fim
do projeto e tem por objetivo analisar e aprender com os resultados,
objetivando a melhoria de processos e prticas arquiteturais.
A Figura 5 representa a projeo do ciclo de vida de um projeto
tpico sobre o ciclo de vida da gesto de arquitetura de software.
Figura 5. Projeo do ciclo de vida da gesto de
arquitetura de software sobre o ciclo de vida do projeto
De uma forma geral, a literatura especializada trata princi-
palmente das atividades relacionadas definio da arquite-
tura, em especial, da modelagem e da avaliao arquiteturais.
Entretanto, na prtica, a disciplina de arquitetura de software
requer uma gesto mais complexa. As atividades do arquiteto
tendem a envolver questes mais estratgicas que merecem ser
contextualizadas no ciclo de vida do projeto.
Dentre aqueles que defendem uma participao mais es-
tratgica do arquiteto de software, destacamos os mtodos
arquiteturais VAP [2] de Dana Bredemeyer e o CFCAR [3] de
Gerrit Muller. A iniciativa de arquitetura de software do SEI,
denominada SAT, tambm ressalta o envolvimento do arqui-
teto no alinhamento estratgico do produto e trata o business
case como um insumo para a arquitetura de software.
O ciclo de vida IDEA serve como uma espcie de moldura
para instanciar processos de arquitetura de software. Para
projetos que visam o desenvolvimento de um novo produto, o
escopo do nosso artigo, sugerimos o processo diagramado na
Figura 6. Repare que, em termos gerais, o processo arquitetural
segue o ciclo de PDCA (Plan, Do, Check, Act).
A Tabela 1 enumera as atividades e os produtos de trabalho
sugeridos pelo IDEA.
Na seo Atividades da gesto em arquitetura de software,
exemplificaremos as atividades e seus produtos de trabalho
com um nvel um pouco maior de detalhes.
IDEA e Processos de Desenvolvimento de Software
O IDEA pode ser aplicado sobre qualquer processo de de-
senvolvimento de software e seu uso tende a ser mais natural
em processos iterativos. A seguir, apresentamos simulaes de
projetos para diferentes processos considerando o ciclo IDEA.
Projetos conduzidos pelo IBM RUP (Rational Unified Process) so
marcados pelas fases Iniciao (por vezes, denominada de Concep-
o), Elaborao, Construo e Transio [2]. A Figura 7 exercita uma
projeo hipottica do ciclo IDEA sobre o ciclo de vida de um projeto
dirigido pelo RUP. As atividades da gesto da arquitetura tendem a
ser organizadas da seguinte forma nas fases do RUP [3]:
Iniciao: objetiva definir o escopo e aferir a viabilidade do
projeto. Coincide com as atividades iniciais (I) da gesto de
arquitetura de software e, muitas vezes, um esforo mnimo de
definio da arquitetura candidata (D). As atividades de arqui-
tetura devem subsidiar a anlise de viabilidade do projeto;
Figura 6. Processo arquitetural para um
novo produto de software baseado no |DLA
Grupo Atividade Produtos de trabalho
Iniciao Definir a viso arquitetural Viso arquitetural
Formular a estratgia arquitetural Diretrizes arquiteturais
Anlise de viabilidade tcnica
Estratgia arquitetura
Definio Planejar a definio arquitetural Plano arquitetural
Desenvolver requisitos arquiteturais Requisitos arquiteturais detalhados
Modelar a arquitetura Modelo da arquitetura
Avaliar a arquitetura Avaliao da arquitetura
Edificao Realizar a arquitetura do software Arquitetura executvel
Anlise Avaliar e aprender com os resultados Lies aprendidas
Sugestes de melhorias
Tabela 1.Atividades e produtos de trabalho da gesto da arquitetura de software
Figura 7. Pro|eao hipotetica do ciclo |DLA sobre o ciclo de vida de um pro|eto dirigido pelo PUP
Edio 14 - Engenharia de Software Magazine 43
ARQUI TETURA DE SOFTWARE
Elaborao: seu principal objetivo estabilizar a arquitetura do
sistema, conhecida, nesse ponto, como arquitetura executvel. As-
sim, na Elaborao, as atividades de definio da arquitetura (D)
se intensificam e h uma forte preocupao em edific-la (E);
Construo: nesta fase, o projeto est em franco carter
construtivo do software. Ocorre o predomnio de atividades
relacionadas realizao da arquitetura (E). O arquiteto deve
garantir que a arquitetura bem compreendida por desenvol-
vedores, engenheiros de testes, integradores, etc.;
Transio: enfoca a liberao do produto. O arquiteto apia
as aes de qualidade e implantao (E). Na transio, ocorrem
as atividades finais da arquitetura, caracterizadas pela anlise
e aprendizado dos resultados (A).
Atualmente, existe uma aparente tenso entre a comunidade de
praticantes de mtodos geis e arquitetos de software ortodoxos [3].
Os chamados agilistas entendem que os arquitetos produzem muito
papel, enquanto que mudana nos requisitos (principalmente arqui-
teturais) provoca incmodo em alguns arquitetos de software em
qualquer estgio do projeto. Comentaremos rapidamente alguns
mitos de agilidade versus arquitetura de software na Tabela 2.
Nossa experincia diz que a disciplina de arquitetura de software
pode contribuir para a reduo de riscos tcnicos mesmo em pro-
jetos que empreguem mtodos geis. Para tal, em primeiro lugar,
os trabalhos arquiteturais devem respeitar a natureza evolutiva
de tais projetos. Em segundo, deve se ater a comunicar modelos
arquiteturais apenas na medida exigida pelo mtodo. Por exemplo,
se a filosofia de desenvolvimento prega abandonar diagramas aps
a realizao no modelo atravs do cdigo, o arquiteto assim deve
proceder. Outra situao: caso a equipe no faa uso de ferramentas
CASE ou de modelagem avanadas, o arquiteto pode considerar a
modelagem coletiva usando um quadro branco ou flip chart.
O ciclo de vida de gesto da arquitetura que apresentamos aco-
moda perfeitamente os projetos geis. Na Figura 8, apresentamos
uma projeo hipottica do ciclo IDEA sobre um projeto gil diri-
gido pelo SCRUM ou XP. Como pode ser percebido, os grupos de
definio (D) e edificao (E) arquiteturais se revezam constante-
mente durante as iteraes intermedirias do projeto. E, mesmo
nas ltimas iteraes, a descoberta ou mudana de um requisito
arquitetural pode implicar em redefinio (D) na arquitetura.
As iteraes do SCRUM so denominadas sprints. As primeiras
iteraes do XP compem as fases de Explorao e Planejamento.
O ciclo de vida IDEA e o processo exposto na Figura 6 comportam
a realizao parcial da arquitetura, isto , prova-se com cdigo
mesmo que a arquitetura no esteja completamente definida. Esta
abordagem totalmente aderente filosofia dos mtodos geis.
Por fim, mesmo que todo o senso moderno da engenharia de sof-
tware no recomende processos em cascata, possvel vislumbrar
uma possvel aplicao do ciclo de vida IDEA nessa situao (nossa
experincia em gesto arquitetural limitada a projetos baseados
no Processo Unificado e em mtodos geis. A aplicao descrita
para processos em cascata meramente especulativa. Ainda hoje,
existem alguns projetos - principalmente aqueles derivados de
editais pblicos que sustentam este tipo de desenvolvimento.). A
Figura 9 demonstra esta situao, apesar de um tanto inusitada.
Mito Quem costuma acreditar nisto Realidade
Arquitetura de software produz muito papel. Alguns adeptos de mtodos geis. O processo de software adotado determina quais documentos so realmente necessrios.
Comunica-se somente o estritamente necessrio.
Arquiteturadesoftwareimplicaembigdesignupfront[4]
(intenodecriar todososmodelosnoinciodoprojeto).
Alguns agilistas e arquitetos. A arquitetura deve respeitar a natureza do mtodo. Em projetos geis, a arquitetura do
software deve ser evolutiva [5].
Requisitos arquiteturais no podem mudar a partir
de um certo momento.
Alguns arquitetos e engenheiros de processos. Mtodos geis aceitammudanas a qualquer momento, tendo impacto ou no sobre a arquitetura. O
clientedevesempreestarcientedasconsequnciasdeumamudananorequisito(arquitetural ouno).
Softwares desenvolvidos com mtodos geis no
tm arquitetura.
Pessoas envolvidas no desenvolvimento do software. Todosoftwaretemumaarquitetura,independentesealgumaprojetouintencionalmenteouno[6].
Arquiteto de software somente um novo e pomposo
ttulo que programadores pedem para ter em seus
cartes.Projetos geis no precisam do arquiteto.
Alguns adeptos de mtodos geis. Vrios mtodos geis prescindem de papis.Mesmo que ningum na equipe tenha o papel
ou cargo de arquiteto de software, convm planejar a arquitetura.
Toda a arquitetura deve ser modelada no incio do
projeto.
Alguns arquitetos de software. O arquiteto deve respeitar a natureza do projeto. Se o mtodo prescreve prove com cdigo
sempre que possvel, interessante realizar a arquitetura em software executvel mesmo
que no esteja completamente modelada.
Tabela 2. Mitos sobre mtodos geis versus arquitetura de software
Figura 8. Pro|eao hipotetica do ciclo |DLA sobre o ciclo de vida de um pro|eto agil
Figura 9. Aplicaao hipotetica do |DLA em processo cascata
44 Engenharia de Software Magazine - Ciclo de Vida da Gesto em Arquitetura de Software
Atividades da Gesto de Arquitetura de Software
Iremos ilustrar as atividades do ciclo de vida do IDEA atravs
de um exemplo fictcio no contexto de emprstimos bancrios
na modalidade de crdito consignado, um emprstimo com
desconto em folha de pagamento do trabalhador e, portanto
um emprstimo de menor risco.
Definio do Problema Viso do Produto
recomendvel que o produto a ser modelado tenha uma
viso definida. Uma viso um documento que fornece as
diretrizes e funcionalidades bsicas do produto que deve ser
construdo. Fornecemos aqui um extrato da viso do produto
de emprstimo bancrio, resumido na Tabela 3.
O problema de demora e ineficincia na anlise e concesso de crdito consignado.
Afeta
trabalhadores aposentados, servidores pblicos, funcionrios da iniciativa
privada, diretoria e acionistas do banco Optimus.
Impacto
atual
pequenosvolumesdeemprstimosrealizados,grandedemoraparaosclientes,custos
maisaltosdefinanciamento,perdadeclientesparaoutrasfinanceirasebancos.
Uma soluo
de TI bem
sucedida
seria
a automao do processo de anlise e concesso de crdito consignado
atravs da criao de uma soluo de portal que integre os clientes de
emprstimo, as bases de dados com as informaes histricas destes
clientes e informaes de clientes disponveis em bases de dados de
terceiros tais como SERASA e Secretaria da Receita Federal
Benefcios
esperados
+ameate ae aamere ae .eaa+..
reduo dos custos de suporte com TI.
evoluo facilitada.
Tabela 3. Definiao do problema de credito consignado do banco Optimus
Inclumos na Tabela 4 as principais necessidades de negcio
do produto a ser modelado, que tambm fariam parte do do-
cumento de viso do produto.
Necessidades Prioridade Caractersticas Planejamento
para Liberao
Portal Web para
Automao da
Anlise e Concesso
de Emprstimos de
Crdito Consignado
Alta .+||||a+ae l+c|||t+a+
:e||c|t+1e ae |mjre.t|me
||ertar+ ae emjre.t|me
|cemj+a|+meate ae emjre.t|me
:|ma|+ee. ae l|a+ac|+meate
|a1||.e ae r|.ce
teace..1e ae |mjre.t|me
|cemj+a|+meate ae |++meate.
1.0
Eliminao de
formulrios manuais
Alta t+a+.tre aa|l|c+ae ae c||eate.
|erma|1r|e aa|l|c+ae j+r+
solicitao de emprstimo
1.0
Portal para
dispositivos mveis.
Baixa

Abertura e acompanhamento de
solicitaes de emprstimo
2.0
Interface EDI para
conveniados
Baixa ||ertar+ e +cemj+a|+meate
de solicitaes de emprstimo
por conveniados
2.0
Tabela 4. Definiao das principais necessidades de credito consignado
do banco Optimus
Iniciao
As tarefas iniciais do time de arquitetura devem garantir o alinha-
mento tcnico da arquitetura de software com a viso do produto
e demais premissas organizacionais (restries oramentrias e
temporais, conhecimentos da equipe e cultura organizacional). Para
isso, devemos desenvolver a viso e estratgia arquiteturais.
Viso Arquitetural
A viso arquitetural nasce a partir da viso do produto e dos
princpios tcnicos do projeto, isto , os objetivos primrios da
arquitetura de software. Por exemplo, no nosso contexto ban-
crio poderamos ter o conjunto de princpios da Figura 10.
Figura 10. Princpios arquiteturais do sistema de crdito consignado
Esses princpios norteiam qualquer atividade tcnica do
projeto. Por exemplo, ao avaliar uma determinada soluo,
framework ou tcnica, os confrontamos com os princpios
arquiteturais. Solues ou tcnicas que promovam mais se-
gurana ou eficincia operacional teriam preferncia sobre
solues menos seguras ou menos eficientes.
A viso arquitetural exprime o plano arquitetural e apre-
senta uma primeira visualizao arquitetural, a visualizao
de negcio. A visualizao de negcio resumida para o nosso
produto expressa na Figura 11.
Figura 11. visualizaao de negocio do sistema de credito consignado
Edio 14 - Engenharia de Software Magazine 45
ARQUI TETURA DE SOFTWARE
Estratgia Arquitetural
A formulao da estratgia arquitetural a outra atividade
do grupo de iniciao do IDEA. Em suma, o arquiteto deve
realizar uma anlise estratgica e desenvolver a estratgia da
arquitetura de software.
Um dos produtos de trabalho da formulao estratgica
a identificao das diretrizes arquiteturais. As diretrizes
arquiteturais so os requisitos em alto nvel significa-
tivos para o time de arquitetura de software e refletem
decises que so difceis de serem revertidas. Diretrizes
arquiteturais devem ser identificadas explicitamente pelo
time de arquitetura de software com apoio dos analistas
de negcio, analistas de requisitos e demais interessados
tcnicos do projeto.
Geralmente no encontramos um nmero muito grande
de diretrizes arquiteturais no incio de um projeto de
software (valores tpicos entre 5 a 20). Essas diretrizes
normalmente refletem o subconjunto de requisitos prio-
ritrios (na tica dos interessados do produto) e de alta
complexidade tcnica. interessante notar que as diretri-
zes arquiteturais podem advir de requisitos funcionais,
de requisitos no-funcionais (atributos de qualidade) e de
restries tecnolgicas.
No nosso exemplo, foram identificadas as seguintes dire-
trizes arquiteturais (As diretrizes foram propositadamente
simplificadas e contm palavras ambguas como excelente e
alta disponibilidade. Em projetos reais, mtodos de verificao
da qualidade de escrita de requisitos como o SMART ou m-
todos de desenvolvimento formais de requisitos arquiteturais
como o SEI QAW poderiam ser usados para apoio ao time de
arquitetura):
Suporte a 1000 usurios simultneos em perodos de pico;
Tempo de resposta inferior a sete segundos;
Alta disponibilidade em horrio comercial;
Solicitao de emprstimo;
Simulaes de financiamento;
Anlise de risco de emprstimo;
Portal para a hospedagem de pginas e elementos visuais;
Portal para dispositivos mveis;
Operao em plataforma .NET;
Segurana com autenticao baseada em LDAP/Kerberos e
transporte seguro para comunicao com clientes;
Suporte aos navegadores Internet Explorer 6.0/7.0 e Firefox 3.0;
Interoperabilidade com SGBD Sybase;
Interoperabilidade com plataforma alta (CICS/COBOL).
O time de arquitetura deve tambm elencar e analisar os
principais riscos tcnicos do projeto que, na nossa abordagem,
chamamos de riscos arquiteturais. Exemplos de riscos que
poderiam compor o problema:
Conhecimento da equipe na plataforma .NET no avanado;
Conhecimento da equipe na plataforma .NET para ambientes
mveis precrio;
No existe experincia prvia do Banco Optimus em inte-
grao com plataforma alta (CICS/COBOL).
O time de arquitetura tambm pode enderear oportunidades
para a empresa com o desenvolvimento de uma arquitetura de
software robusta para o produto. Exemplos de oportunidades
poderiam incluir:
Aumento da segurana da informao com o aprendizado
do protocolo Kerberos e outros aspectos de segurana da in-
formao, o que pode eliminar riscos de auditoria e elevar o
valor do banco para diretores e acionistas;
Capacitao do time tcnico em tecnologias mveis.
A estratgia arquitetural tambm enderea aspectos como o
estilo arquitetural e a metfora sistmica. O estilo arquitetural,
como na arquitetura da construo civil, classifica um produto
quanto ao seu estilo primrio.
A metfora sistmica, idia originria da metodologia XP,
um recurso visual e muitas vezes ldico para explicar a arquite-
tura a pessoas com poucos conhecimentos tcnicos. Um exem-
plo para metfora sistmica representado na Figura 12.
O estilo e a metfora sistmica do nosso exemplo esto re-
presentados na Tabela 5.
Estilo
Arquitetural
O nosso sistema um sistema de informao com diferentes tipos de
visualizaes (portais Web e mveis) e interoperabilidade com sistemas
legados.Portanto,o estilo arquitetural associado ao nosso sistema um sistema
n-tier,ancorado no padro arquitetural MVC (Model View Controller).
Metfora
Sistmica
O nosso sistema est desenhado conforme um bolo em camadas
(camada visual, camada de negcios e camada de interoperabilidade
com banco de dados e legados).
Tabela 5. Estilo arquitetural e metfora do sistema de crdito consignado
Figura 12. Metafora Sistemica
Definio
A definio o grupo de atividades do IDEA que lida com
anlise e desenho arquitetural dos requisitos sob anlise.
Grande parte do trabalho que arquitetos usualmente praticam,
principalmente a modelagem arquitetural, est situada neste
grupo de atividades. No artigo corrente, abordaremos a defini-
o arquitetural com um nvel muito superficial de detalhes.
A definio no IDEA, entretanto, tende a ser mais ampla e
lida com:
O planejamento das atividades de definio da arquitetura
para a iterao ou fase atual do projeto. Arquiteturas de softwa-
re so naturalmente evolucionrias (o conceito de arquiteturas
evolucionria descrito em processos como o OpenUP ou no
46 Engenharia de Software Magazine - Ciclo de Vida da Gesto em Arquitetura de Software
mtodo de Arquiteturas geis (Agile Architectures) de Scott
Ambler) e evolutivas e, portanto, o ciclo de definio parte
para o endereamento de um determinado subconjunto dos
requisitos arquiteturais.
O desenvolvimento dos requisitos a partir das diretrizes
arquiteturais. Tcnicas como o FURPS+ [9], a ISO SQUARE
[10] e o modelo SMART [11] podem ser usadas para apoiar
neste processo de detalhamento de requisitos tcnicos. O
uso de cenrios [12] pode ser til para representar requisitos
arquiteturais refinados. comum encontrarmos sistemas com
vrias dezenas de requisitos arquiteturais discretos.
A modelagem arquitetural atravs do uso de mltiplas vi-
sualizaes. Tcnicas como o modelo de visualizaes 4+1 [9],
de Phillipe Kruchten, ou o modelo SEI conhecido por V&B [10]
poderiam ser usados aqui.
O detalhamento das tticas arquiteturais. Uma ttica arqui-
tetural lida com um determinado aspecto da arquitetura. Por
exemplo, poderamos enderear uma ttica para autenticao
e single sign-on com o LDAP/Kerberos.
A explorao de alternativas de anlise e desenho. A avaliao e
comparao destas alternativas e a proposta da arquitetura parcial
para o conjunto de requisitos endereados at o momento.
Exemplos de visualizaes para o modelo do nosso exemplo
so fornecidos nas Figuras 12, 13, 14 e 15. A Figura 12 apresenta
o conceito da metfora arquitetural derivada de escolas geis
como o XP. No nosso exemplo, o padro referenciado o pa-
dro camadas (Layers), que denota uma organizao em nveis
de apresentao, domnio e interoperabilidade com sistemas
legados e bancos de dados.
A Figura 13 apresenta uma visualizao lgica, que cap-
tura os grandes agrupamentos do domnio da aplicao.
Cada grande elemento capturado como um pacote UML,
que pode apresentar ou requerer dependncias de outros
pacotes. Esta viso fornece um primeiro diagrama de
contexto para iniciados no projeto e tambm permitir
expressas dependncias para a montagem de um crono-
grama de trabalho.
A Figura 14 apresenta uma visualizao de componentes (que
so elementos fsicos como DLLs Windows ou .JARs em Java).
Esta viso captura a gesto de configurao dos elementos
centrais a serem produzidos pelo time de projeto e dependn-
cias para a sua operao em produo. Por exemplo, vemos
nesta figura que o domnio que cuida do processo de negcio
de consignao de crdito depende do servidor de integrao
(MS BizTalk), que por sua vez depende de um adaptador de
fila de mensagens para que as mensagens sejam enviadas ao
sistema do Banco Central do Brasil.
Finalmente, vemos uma viso de provisionamento (mquinas
e servidores de infra-estrutura) do nosso software na Figura 15.
Vemos, por exemplo, que teremos um servidor dedicado para
hospedar o banco de dados e um servidor dedicado para
hospedar o cdigo.
Estes modelos, em verdade, seriam um pequeno fragmento
de uma soluo completa para este exemplo hipottico. Um
modelo arquitetural completo no apresentado aqui, natu-
ralmente, por questes de espao.
No mundo real, um dos trabalhos de um arquiteto de sistemas
definir que vises so ou no aplicveis conforme os riscos
tcnicos e requisitos do projeto sendo endereado.
Figura 13. visualizaao logica do sistema de credito consignado
Edio 14 - Engenharia de Software Magazine 47
ARQUI TETURA DE SOFTWARE
As atividades do grupo de definio arquitetural so encade-
adas em um ciclo. Cada execuo do ciclo produz uma arqui-
tetura candidata que, potencialmente, pode ser realizada em
cdigo (atividade do grupo de Edificao). O ciclo se repete at
que se considere que uma arquitetura estvel foi atingida.
Figura 15. visualizaao de implantaao do sistema de credito consignado
Figura 14. visualizaao de implementaao do sistema de credito consignado
Nota do DevMan
Ciclo PDCA
O ciclo PDCA, tambm conhecido por ciclo de Shewhart ou ciclo de Deming, um
processo em quatro passos para soluo de problemas. O PDCA foi criado por Walter
Shewhart e popularizado por W. Edwards Deming. Resumidamente, as fases significam:
Plan (planejamento): estabelece objetivos e processos para atingir os resultados;
Do (execuo): execuo das atividades planejadas;
Check (verificao): monitorao ou estudo peridico dos resultados, consolidan-
do-os com o planejado;
Act (ao): agir conforme o estudo promovido pela verificao com fins de melho-
rar a qualidade, a eficincia e a eficcia.
48 Engenharia de Software Magazine - Ciclo de Vida da Gesto em Arquitetura de Software
Edificao
At este momento temos normalmente uma arquitetura
candidata, i.e, uma arquitetura baseada em estudos e experi-
ncia do time e tambm na anlise de alternativas. Entretanto,
devemos provar a arquitetura com cdigo robusto.
O IDEA prope, neste particular, um conjunto de atividades
de edificao. A edificao realiza a arquitetura, isto , fornece
evidncias concretas atravs de cdigo executvel que a arqui-
tetura acomoda os requisitos do projeto.
A edificao realizada atravs do esforo conjunto do
time de arquitetura do projeto (arquiteto e desenvolvedores
especialistas). O resultado da edificao uma arquitetural
executvel, que poderia ser gerada em pequenos incrementos
(builds) nas fases iniciais de um projeto.
No nosso exemplo, poderamos elencar um plano de builds
(cdigos com maturidade Alfa - um produto alfa um c-
digo executvel, mas que ainda no possui estabilidade de
produo. Ele pode (e deve) ser usado para validar requisitos
arquiteturais com usurios chave, estabelecer nveis maio-
res de confiana e reduzir riscos tcnicos do projeto) a ser
construdo para provar aspectos da arquitetura com cdigo
executvel. Seis builds so mostrados para exemplificar nosso
produto bancrio:
Alfa 1 Prova de Conceito Single Sign On Kerberos;
Alfa 2 Prova de conceito com o fluxo de solicitao, abertura
e acompanhamento de emprstimos;
Alfa 3 Prova de conceito de interoperabilidade e troca de infor-
maes (EDI) com Microsoft MQSeries para o Banco Central;
Alfa 4 Prova de conceito de escalabilidade para 1000 usu-
rios simultneos;
Alfa 5 Implementao do conjunto de casos de uso de
solicitao e abertura de emprstimo;
Alfa 6 - Implementao do conjunto de casos de uso de
simulaes de financiamento.
Ao final do ciclo de atividades de edificao, temos uma
arquitetura provada para os mecanismos centrais elencados
na fase de definio.
O trabalho de arquitetura no se encerra ao termos uma
arquitetura executvel e estvel. muito fcil quebrar uma
arquitetura definida e, portanto, o arquiteto deve acompanhar
o time na resoluo contnua de dvidas e na verificao do
cdigo sendo construdo.
Alm do trabalho junto ao time de desenvolvimento, o arquiteto tam-
bm apia outros profissionais como o engenheiro de testes, o analista
de integrao, gerente de configurao, etc. O objetivo garantir que
todos compreendam perfeitamente a arquitetura definida.
Avaliao
O IDEA est inspirado nas idias clssicas do PDCA e como tal
possui um ciclo de atividades para anlise de lies aprendidas. A
avaliao deve ser ampla e envolver o time tcnico, time gerencial,
time de analistas e demais interessados no projeto. As aes de
arquitetura devem ser avaliadas e os erros e lies aprendidas
devem ser discutidas e comunicadas para toda a equipe.
D seu feedback sobre esta edio!
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
Para isso, precisamos saber o que voc, leitor, acha da revista!
D seu voto sobre este artigo, atravs do link:
www.devmedia.com.br/esmag/feedback
D

s
e
u
Feedbac
k
s
o
b
r
e

e
s
t
a
e
d i o
1. Project Management Institute. [PMBOK] A Guide to the Project Management Body of
Knowledge. s.l. : Project Management Institute, 2004.
2. Malan, Ruth and Bredemeyer, Dana. Architecture as a Business Competency. [Online] http://
www.bredemeyer.com/pdf_files/WhitePapers/ArchitectureAsBusinessCompetency.PDF.
3. Muller, Gerrit. CAFCR: A Multi-view Method for Embedded Systems Architecting; Balancing
Genericity and Specificity. [Online] http://www.gaudisite.nl/info/Thesis.info.html.
4. IBM. IBM Rational Unified Process 7.5. s.l. : IBM.
5. Rozanski, Nick and Woods, Eoin. Software Systems Architecture: Working with Stakeholders
Using Viewpoints and Perspectives. s.l. : Addison-Wesley Professional, 2005.
6. Ambler, Scott. Big Modeling Up Front (BMUF) Anti-Pattern. Agile Modeling. [Online] 2007.
[Cited: 04 02, 2009.] http://www.agilemodeling.com/essays/bmuf.htm.
7. InfoQ. Paulo Merson on Documenting Application Architectures Using UML 2.0. [Online]
InfoQ, 11 27, 2008. [Cited: 04 02, 2009.] http://www.infoq.com/news/2008/11/paulo-merson-
architecture.
8. IBM Rational Quality Manager. Entrevista: Grady Booch e Scott W. Ambler - Architecture?
Agile Dont Need No Architecture! [Online] 2009. [Cited: 04 02, 2009.] http://www.facebook.
com/video/video.php?v=1090941519721.
9. Grady, Robert. Practical software metrics for project management and process improvement.
Upper Saddle River, NJ, USA : Prentice-Hall, Inc., 1992. ISBN:0-13-720384-5.
10. ISO. Software Engineering -- Software product Quality Requirements and Evaluation
(SQuaRE) -- Guide to SQuaRE. ISO/IEC 25000:2005. [Online] 2005. http://www.iso.org/iso/
iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=35683.
11. Mannion, Mike and Keepence, Barry. SMART requirements. ACM SIGSOFT Software
Engineering Notes. 1995, Vol. 20, 2.
12. Bass, Len, Clements, Paul and Kazman, Rick. Software Architecture in Practice. 2nd. s.l. :
Addison-Wesley, 2003.
13. Kruchten, Phillippe.The 4+1 View Model of Architecture. IEEE Software. 6, 1995, Vol. 12, 6.
14. Clements, Paul, et al. Documenting software architectures: views and beyond. ICSE 03:
Proceedings of the 25th International Conference on Software Engineering . 2003.
Referncias
A arquitetura, como pea estratgica em uma empresa, deve
gerar informaes para a gesto do conhecimento corporativo
e promover cada vez mais alinhamento entre as aes tcnicas
e as necessidades de negcio de uma organizao.
Concluses
A disciplina de arquitetura de software tende a ser mais
eficaz se aplicada em um contexto mais amplo e responsvel
a gesto da arquitetura de software. IDEA, o ciclo de vida
da gesto da arquitetura de software, encadeia as atividades
de arquitetura de software de uma forma compreensvel e
organizada.
O artigo corrente concentrou-se no processo de arquitetura
de software para a criao de um produto, mas, de uma forma
anloga, os conceitos podem ser aplicados para famlias de
produtos e arquiteturas de referncia.