DANIELLE POMPEU NORONHA PONTES

EVOLUO DE SOFTWARE BASEADA EM AVALIAO DE

ARQUITETURAS

SO PAULO
2012

DANIELLE POMPEU NORONHA PONTES

EVOLUO DE SOFTWARE BASEADA EM AVALIAO DE

ARQUITETURAS

Dissertao apresentada Escola

Politcnica da Universidade de So
Paulo para a obteno do ttulo de
Mestre em Engenharia.

rea de Concentrao:
Sistemas digitais.

Orientador:
Prof. Dr. Reginaldo Arakaki

SO PAULO
2012

Este exemplar foi revisado e alterado em relao verso original, sob

responsabilidade nica do autor e com a anuncia de seu orientador.
So Paulo, 09 de maio de 2012.

Assinatura do autor ____________________________

Assinatura do orientador _______________________

FICHA CATALOGRFICA
Pontes, Danielle Pompeu Noronha
Evoluo de software baseada em avaliao de arquiteturas /
D.P.N. Pontes. -- ed.rev. -- So Paulo, 2012.
99 p.
Dissertao (Mestrado) - Escola Politcnica da Universidade
de So Paulo. Departamento de Engenharia de Computao e
Sistemas Digitais.
1. Arquitetura de software (Avaliao) 2. Engenharia de
Software 3. Softwares (Evoluo) I. Universidade de So Paulo.
Escola Politcnica. Departamento de Engenharia de Computao e Sistemas Digitais II. t.

DEDICATRIA

Ao meu esposo Pontes Filho, pela compreenso.

s minhas filhas queridas Sofia e Clarissa
que alegram e iluminam todos os meus dias.
Aos meus pais que sonharam este sonho comigo
por muitos anos e a Deus que colocou
todos eles em minha vida.

AGRADECIMENTOS

Meus agradecimentos,

A DEUS, que com sua imensa grandeza me deu foras nesta jornada.
s minhas filhas Sofia e Clarissa, que sempre me proporcionou momentos de alegria
e ternura.
Ao meu esposo Pontes Filho pelo incentivo, pacincia e amor.
Ao meu orientador Prof. Reginaldo Arakaki pela dedicao e rigor na orientao
deste trabalho.
A meus pais, que me incentivaram a continuar.
Aos colegas da Dr Tech e da Universidade Estadual do Amazonas, pela amizade e
incentivo.
Aos professores do mestrado pelos valiosos conhecimentos e experincias
transmitidas para minha formao.
Aos colegas da turma pelo companheirismo e prazer de convvio.
A todos, que assim como eu, acreditam em um futuro melhor.

Eu pedi foras... E DEUS me deu dificuldades para me fazer forte.

Eu pedi sabedoria... E DEUS me deu problemas para resolver.
Eu pedi prosperidade... E DEUS me deu crebro e msculos para
trabalhar.
Eu pedi coragem... E DEUS me deu perigo para superar.
Eu pedi amor... E DEUS me deu pessoas com problemas para
ajudar.
Eu pedi favores... E DEUS me deu oportunidades.
Eu no recebi nada do que pedi... Mas recebi tudo que precisava.

Ao Senhor, Jesus Cris, Mestre Supremo,

meu eterno agradecimento.

RESUMO

Este trabalho discorre sobre o estudo da utilizao do mtodo de avaliao ATAM

como referncia para um roteiro para evoluo arquitetural. O estudo apresentado
est dividido em duas partes: a elaborao de um roteiro para evoluo de software
e a aplicao do roteiro em um ambiente real de um sistema para automao de
linhas areas. O objetivo avaliar o uso do mtodo de avaliao de arquitetura para
direcionar a evoluo do software. As diretrizes geradas neste trabalho orientam as
aes a serem tomadas com base em evidncias obtidas pela avaliao,
possibilitando ao software que exiba os atributos de qualidade desejados.

Palavras chaves: Arquitetura de Software. Evoluo de Software. ATAM. Requisitos

No-Funcionais. Avaliao Arquitetural.

ABSTRACT
This paper discusses the study of the use of ATAM evaluation method as a reference
to a roadmap for architectural evolution. The present study is divided into two parts:
the preparation of a roadmap for software development and implementation of the
roadmap in a real environment of a system for automation of airlines. The goal is to
evaluate the use of architecture evaluation method to direct the evolution of software.
The guidelines generated in this work have guided the actions to be taken based on
evidence obtained by the evaluation, enabling the software that displays the desired
quality attributes.
Word-key: Software Architecture. Software Evolution. ATAM. Non-functional
requirements. Architectural Evaluation.

LISTA DE ILUSTRAES

FIGURA 1 - ESTRUTURA DO ROTEIRO UTILIZADO NA PESQUISA ..........................................................................................53

FIGURA 2: ESQUEMA PARA APRESENTAO DO ATAM (PASSO 1)....................................................................................54
FIGURA 3: ESQUEMA PARA APRESENTAR OS OBJETIVOS DO NEGCIO (PASSO 2). ..................................................................55
FIGURA 4: ESQUEMA PARA APRESENTAR A ARQUITETURA (PASSO 3). ................................................................................56
FIGURA 5: ESQUEMA PARA IDENTIFICAR MTODOS ARQUITETURAIS (PASSO 4). ...................................................................57
FIGURA 6: ESQUEMA PARA GERAR RVORE DE UTILIDADE (PASSO 5). ..............................................................................58
FIGURA 7: ESQUEMA PARA ANLISE DOS MTODOS ARQUITETURAIS (PASSO 6) ...................................................................59
FIGURA 8: ESQUEMA PARA REALIZAR O BRAINSTORM E PRIORIZAO DE CENRIOS (PASSO 7). ................................................60

LISTA DE QUADROS

QUADRO 1 - RESUMO DO ESTADO DA ARTE ................................................................................................................22

QUADRO 2 - AS OITO LEIS DE EVOLUO DE SOFTWARE.................................................................................................39
QUADRO 3 - SUBCARACTERSTICAS IMPORTANTES AOS ATRIBUTOS DE QUALIDADE ................................................................45
QUADRO 4 - OS ATRIBUTOS DE NEGCIO. ..................................................................................................................46
QUADRO 5 - OS PASSOS DO ATAM. .........................................................................................................................51
QUADRO 6 - CENRIOS DE USURIO .........................................................................................................................65
QUADRO 7 - CENRIOS DE NEGCIO .........................................................................................................................66
QUADRO 8 - CLASSIFICAO DOS ARTEFATOS DA ARQUITETURA DO SOFTWARE ...................................................................67
QUADRO 9 - INFORMAES ADICIONAIS. ...................................................................................................................67
QUADRO 10 - ABORDAGENS ARQUITETURAIS IDENTIFICADAS. .........................................................................................68
QUADRO 11 - CLASSIFICAO DOS CENRIOS (1 VERSO DA RVORE DE UTILIDADE). ..........................................................69
QUADRO 12 - REQUISITOS X MECANISMOS EXISTENTES .................................................................................................71
QUADRO 13 - ANLISE DOS MECANISMOS ARQUITETURAIS() ........................................................................................74
QUADRO 14 - AGRUPAMENTO DOS CENRIOS SEMELHANTES. .........................................................................................74
QUADRO 15 - RVORE DE UTILIDADE REDUZIDA E COM PRIORIDADES. ...............................................................................75
QUADRO 16 - ANLISE ARQUITETURAL CENRIO AG1. ..............................................................................................77
QUADRO 17 - ANLISE ARQUITETURAL CENRIO AG5. ..............................................................................................78
QUADRO 18 - ANLISE ARQUITETURAL CENRIO U02. ...............................................................................................79
QUADRO 19 - ANLISE ARQUITETURAL CENRIO N11. ...............................................................................................80
QUADRO 20 - ANLISE ARQUITETURAL CENRIO N12. ...............................................................................................80
QUADRO 21 - TTICAS SUGERIDAS CLASSIFICADAS DE ACORDO COM OS PONTOS DE VISTAS ODP. ............................................84
QUADRO 22 - NMERO DE REQUISITOS POR ATRIBUTO DE QUALIDADE..................................................................................87

LISTA DE ABREVIATURAS, SIGLAS e TERMOS

AG

Agrupamento

ATAM

Architecture Tradeoff Analysis Method

AU

rvore de Utilidade, conjunto de Atributos de qualidades

relevantes ao sistema

DA

Deciso arquitetural

Eroso arquitetural

A degradao do software que acontece devido

violao da arquitetura por programadores.

HoPLAA

Holistic Product Line Architecture Assessment

IEC

International Electrotechnical Commission

ISO

International Organization for Standardization

ISO 42010

Systems and Software Engineering - Recommended

practice for architectural description of software-intensive
systems.

ISO/IEC 10746

Basic Reference Model of Open Distributed Processing.

ISO/IEC 10746-3

Basic Reference Model of Open Distributed Processing Part-3: Prescriptive Model.

ISO/IEC 9126-1:2007 Norma ISO para qualidade de produto de software.

ISO/IEEE 1471-2000 Recommended Practice for Architecture Description of
Software-Intensive Systems.
OO

Orientado Objetos

Origin Analysis

Mtodo para analisar mudanas estruturais do software.

(TU; GODFREY, 2002).

Phase out

Fase de descarte do sistema.

RM-ODP

Reference Model for Open Distributed Processing

RNF

Requisito no funcional

SAAM

Software Architecture Analysis Method

SAEV

Software arquitecture Evaluation, modelo proposto em

(SADOU; TAMZALIT; OUSSALAH, 2005).

SQL

Struct Query Langage

StagedModel

Modelo descritivo de evoluo de software.

Trade-off

Expresso que define uma situao em que h conflito de

escolha. Refere-se, a perder uma qualidade ou aspecto
de algo, mas ganhando em troca outra qualidade ou
aspecto.

VBSE

Value-Based Software Engineering

SUMRIO
1.

INTRODUO ................................................................................................... 14

1.1.

Objetivo ........................................................................................................... 17

1.2.

Justificativa ...................................................................................................... 18

1.3.

Escopo ............................................................................................................ 19

1.4.

Anlise Histrica .............................................................................................. 19

1.4.1 Evoluo de Software dentro do ciclo de desenvolvimento .............................. 20

1.4.2 Evoluo de Software a partir das funcionalidades .......................................... 20
1.4.3 Evoluo de Software a partir da arquitetura ................................................... 20
1.5.

Estado da Arte da Pesquisa ............................................................................ 22

1.6.

Contribuies................................................................................................... 24

1.7.

Estrutura e sumrio dos captulos ................................................................... 24

2. CONCEITOS .......................................................................................................25
2.1. Arquitetura de Software ...................................................................................... 25
2.1.1 Histrico da rea .............................................................................................. 25
2.1.2 Vises da Arquitetura ....................................................................................... 27
2.1.3 O modelo de referncia RM-ODP ISO/IEC 10746............................................ 29
2.1.4 Avaliao de Arquitetura .................................................................................. 31
2.1.5 Deciso Arquitetural ......................................................................................... 33
2.2. Evoluo de Software......................................................................................... 34
2.2.1. Manuteno de software ................................................................................ 35
2.2.2. O processo de envelhecimento de software .................................................... 36
2.2.3 Leis da Evoluo de Software .......................................................................... 38
2.3.

Requisitos no-funcionais e atributos de qualidade ........................................ 40

2.3.1. Requisitos no-funcionais ............................................................................... 41

2.3.2. Atributos de qualidade ..................................................................................... 42

2.3.3 Mtodo de Avaliao de Arquitetura por Trade-off (ATAM) .............................. 50

3.
3.1

ROTEIRO PARA AVALIAO DE ARQUITETURA ......................................... 53

Avaliao do sistema atravs do ATAM .......................................................... 53

3.1.1 FASE I Apresentao .................................................................................... 54

3.1.2 FASE 2 Investigao e Anlise ..................................................................... 56
3.1.3 FASE 3 Teste ................................................................................................ 59
3.1.4 FASE 4 Entrega............................................................................................. 61
3.2 Especificar o plano de evoluo para o Sistema ................................................. 62
4.

APLICAO DO ROTEIRO: UM EXEMPLO DE AVALIAO ........................ 64

4.1. Contextualizao ................................................................................................ 64

4.2. Execuo da Avaliao ...................................................................................... 65
4.2.1. Passo 4 Identificando mtodos arquiteturais ................................................ 67
4.2.2. Passo 5 Gerar a rvore de utilidade (Agrupamento e Priorizao dos
cenrios).................................................................................................................... 68
4.2.3. Passo 6 Anlise dos mtodos(abordagem) arquiteturais ............................ 70
4.2.4. Passo 7 Brainstorm e priorizao de cenrios ............................................ 73
4.2.5. Passo 8 Anlise dos mecanismos arquiteturais .......................................... 76
4.2.6. Passo 9 Consolidar resultados ..................................................................... 81
4.3 Aspectos do Plano de Ao para Evoluo ........................................................ 82
4.4 Resumo .............................................................................................................. 86
5.

CONCLUSES E TRABALHOS FUTUROS ..................................................... 89

6.

REFERNCIAS .................................................................................................. 92

14

1. INTRODUO

O xito em longo prazo de um software no determinado em uma nica

verso. Em vez disso, o sucesso definido pela facilidade com que o software
capaz de evoluir e continuar a atender s novas exigncias de mercado. No se
trata apenas das alteraes dos requisitos funcionais. Os requisitos de qualidade
tambm mudam com o tempo (SVAHNBERG,2003). Baseado nos autores (BASS et
al. 1998b), (BOSCH 2000) e (BENGTSSON 2002), o sucesso a longo prazo dos
sistemas de software determinado pelo atendimento dos requisitos de qualidade.
No incio da utilizao de um software, atributos de qualidade como
extensibilidade e adaptabilidade podem ser importantes para aumentar o nmero de
recursos suportados. Mais tarde, a solicitao de novas funcionalidades estabiliza e
as necessidades que surgem so relacionadas aos atributos de qualidade, como
confiabilidade e desempenho, por exemplo. Nesta fase, o produto concorre com
outros que possuem caractersticas semelhantes e, conseqentemente, os atributos
de qualidade oferecem uma vantagem competitiva. Eventualmente, um produto
substitudo por um mais novo que possui uma arquitetura mais compatvel com as
novas tecnologias. Nesta fase, o produto estvel em termos do nmero de
recursos e da qualidade. Outros fatores que podem tornar um software mais
competitivo no mercado esto relacionados a atributos de qualidades como custo de
produo e custo de plataforma de hardware, o qual influencia e restringe a atuao
do software no mercado. (SVAHNBERG,2003)
Como uma das solues para a problemtica da evoluo do software o autor
faz a seguinte colocao:
O software tornou-se mais e mais difcil de entender, manter ou adaptar, e
difcil de reusar e evoluir. Isso acontece devido ao aumento do tamanho e
complexidade dos softwares e pela rpida evoluo das tecnologias de
processamento de dados. A arquitetura de Software esta emergindo como
uma soluo para esta problemtica (SADOU; TAMZALIT; OUSSALAH,
2005, p.01, traduo nossa).

15

Na mesma linha de argumentao usada por Sadou, Chvez (2009) em seu

trabalho cita os autores Krutchen, Obbink e Staford (2006) que afirmam que do
ponto de vista prtico possvel controlar e supervisionar o desenvolvimento e
evoluo de sistemas atravs da arquitetura de software.
De acordo com Garlan e Perry em (GARLAN; PERRY, 1995) a arquitetura de
software pode expor as dimenses atravs das quais um sistema deve evoluir.
Dessa forma, ao torn-las explcitas, os mantenedores do sistema podem
compreender melhor as implicaes das mudanas e, assim, mais precisamente
estimar custos de modificaes. Alm disso, as descries da arquitetura podem
separar as preocupaes da funcionalidade de um componente da forma como este
componente est ligado a outros componentes. Isto permite que se altere o
mecanismo de conexo para lidar com problemas, tais como a evoluo do
desempenho, interoperabilidade, prototipagem e reutilizao.
Todo software est em um contnuo processo evolutivo. Essa evoluo surge
a partir de sucessivas mudanas: para consertar erros, aumentar desempenho ou
atender outros requisitos de qualidade necessrios para se adaptar a novos
ambientes. [(PORTER, 1997) p.120, Traduo nossa].
Sistemas que no so capazes de evoluir correm o risco de um desuso ou
descontinuidade prematura, pois o software est embutido em um ambiente de
constantes mudanas sejam elas ligadas a aspectos sociais ou ambientais
(GODFREY; GERMAN, 2008). As mudanas sociais geralmente envolvem
mudanas funcionais e as mudanas ambientais afetam mais frequentemente a
arquitetura

do

software.

Caractersticas

importantes

deste

processo

de

aprimoramento que ele seja constante, gil e que no gere degradao do

software ao longo da evoluo.
Um aspecto importante para evitar ou pelo menos atrasar essa eroso
arquitetural1 compreender a evoluo do software. Em outras palavras, em vez de
evoluir a arquitetura de software a cada nova mudana que ocorre, a arquitetura
original deve ser capaz de permitir os tipos mais comuns de evoluo.

Assim,

A eroso arquitetural acontece devido violao da arquitetura por programadores. Esse termo
apresentado por Perry e Wolf (1992)

16

poucas mudanas so necessrias na arquitetura e, portanto, a vida do sistema

prorrogada.
De forma geral os termos evoluo, manuteno e eroso so usados
indiferentemente quando se fala de software, existe uma importante diferena
semntica entre eles. Como Parnas (1994) e outros apontam, manuteno conota a
idia de manter um software existente rodando sem mudar o design, isso sugere a
mudana de partes desgastadas em caso de sistemas fsicos. Na prtica a
manuteno de software requer a mudana do design do sistema: corrigindo erros,
adaptando o sistema para uso em novos ambientes, adicionando novas
caractersticas. A eroso o efeito colateral gerado por manutenes feitas de forma
desordenada.
Evoluo subtende a idia de mudana essencial que no esta clara no termo
manuteno. A evoluo sugere novos designs evoluindo de sistemas antigos.
Finalmente pode ser argumentado que manuteno e evoluo oferecem diferentes
perspectivas da natureza da mudana. (GODFREY; GERMAN, 2008). a inovao
e no a preservao, que direciona a mudana de software: um sistema moderno
adaptado a novos ambientes evolui de um sistema antigo. (GODFREY; GERMAN,
2008).
Em (TU; GODFREY, 2002) os autores acreditam que um dos desafios na
pesquisa em evoluo de software como analisar as mudanas estruturais dos
sistemas. O autor utiliza o termo arquitetura de software para se referir a estrutura de
um sistema, enfatizando a organizao dos componentes e os relacionamentos
entre eles. Para obter o sucesso neste processo, a evoluo da arquitetura deve ser
identificada e gerenciada para manter a coerncia da arquitetura. (SADOU;
TAMZALIT; OUSSALAH, 2005). Desta forma, enquanto a manuteno degrada a
vida e a confiabilidade do software, a evoluo planeja mudanas que permitiro um
tempo de vida longo ao software.
Um dos efeitos colaterais originados pela confuso entre os termos
manuteno de software e evoluo de software tem sido a pouca ateno dada aos
modelos de processos que suportem uma evoluo continuada de sistemas de
longo tempo de vida. O clssico modelo em cascata trata a manuteno meramente
como um passo final do processo de desenvolvimento. Nem mesmo em modelos
mais recentes, como o iterativo incremental, existem estgios especficos para

17

manuteno e evoluo, nestes modelos, as consecutivas interaes modelam a

evoluo do software durante o seu desenvolvimento. (GODFREY; GERMAN, 2008).
Bennett e Rajlich (2000) apresentam um modelo descritivo de evoluo de
software chamado de StagedModel de manuteno e evoluo que sumarizam
muitas dessas idias. O modelo dividido em quatro estgios: Desenvolvimento
Inicial, Evoluo ativa, Servicing2 e Phase out3. (GODFREY, GERMAN, 2008).
Considerando o objeto dessa investigao, cumpre reportar-se ao estgio do
Phase out. Neste existe claramente a deciso de substituir ou eliminar o sistema
inteiramente por causa do alto custo de manuteno ou pelo surgimento de novas
solues tecnolgicas. Para tanto o autor da nfase a elaborao de uma estratgia
de sada. Diferentemente dessa perspectiva, esta pesquisa aponta, por fim, outra
direo: pensar em uma estratgia que planeje a criao de uma nova verso para
possibilitar a sobrevivncia do software no mercado.

1.1.

Objetivo

O Objetivo deste trabalho realizar um estudo sobre a utilizao do mtodo de

avaliao ATAM para apoiar a evoluo arquitetural de um sistema de software
atravs de um aplicao prtica.
Para realizar este estudo sero elaborados um roteiro de avaliao e um
exemplo prtico. O Roteiro para avaliao de arquitetura de software ter como
referncia o mtodo de avaliao de arquitetura de software ATAM e como objetivo,
gerar um plano de evoluo a partir de sua arquitetura, assegurando a longevidade
do sistema no mercado. O exemplo prtico da aplicao deste roteiro ser em um
ambiente real de uma empresa de aviao.
A contribuio deste trabalho est na aplicao da avaliao da arquitetura para
direcionar a criao de uma nova verso do sistema que atenda a novos requisitos
no funcionais, permitindo a manuteno ou recolocao do produto no mercado. A

2
3

Fase de manuteno do sistema com foco de mant-lo funcionando. Riscos e custos altos.
Fase de anlise da descontinuao do sistema. Migrao para outro sistema.

18

evoluo ser em passos lentos, mas planejados. Esse planejamento est

diretamente ligado ao planejamento estratgico da empresa.

1.2.

Justificativa

O mercado de desenvolvimento de software tem apresentado mudanas

significativas no que diz respeito construo de sistemas. Atualmente encontramse sistemas complexos instanciados nos mais diversos ramos de atividade o que
dificulta qualquer tentativa de substituio de plataforma, sistema ou fornecedor.
Entretanto o processo de envelhecimento de um software natural e inevitvel, o
que gera uma necessidade constante de evoluo dos sistemas que esperam e
precisam ser mantidos ativos por um perodo grande de tempo. Outro fator relevante
a ser apontado que parte dos sistemas coorporativos instanciados no mercado
apresenta problemas estruturais que afetam negativamente alguns requisitos
fundamentais de qualidade, o que demanda uma evoluo estrutural para adequar a
novas exigncias do usurio. Mudar sistemas sem tcnica prejudica alguns aspectos
de qualidade da arquitetura. Para decidir como implementar mudanas, preciso
usar um mtodo que permita o controle de qualidade da arquitetura.
Adaptar os sistemas as novas necessidades do mercado tais como:
integrao, flexibilidade, federao, transparncia, qualidade do servio e segurana
pode ser apontada como uma maneira de aumentar o tempo de vida de um sistema.
Esta rea de estudo tem evoludo significativamente.
Durante a tentativa de atender as necessidades de mercado situaes nas
quais h conflito de escolha (trade-off) sempre surgem. Um mtodo estruturado
ajuda a garantir que questes importantes sero tratadas mais cedo, durante os
estgios de anlise de requisitos e projeto quando os problemas podem ser
resolvidos de forma mais barata. Dentro do processo proposto para evoluo de
software optou-se por utilizar o mtodo de avaliao ATAM para apoiar a evoluo
arquitetural. Este mtodo orienta os seus usurios, a descobrirem os conflitos entre
os requisitos e apontar as melhores solues para arquitetura de software.

19

Este trabalho parte do conceito que a evoluo de software acontece com a

evoluo arquitetural do sistema. Por isso, estar focado na anlise dos requisitos
no-funcionais desconsiderando a evoluo do software a partir da insero de
novas funcionalidades (requisitos funcionais). Como mtodo de apoio para desenhar
a evoluo ser utilizado o mtodo de avaliao arquitetural - ATAM.

1.3.

Escopo

Este trabalho estar focado na anlise dos requisitos no-funcionais como um

meio de planejar a evoluo de um software atravs de mecanismos arquiteturais.
Como referencia a ISO 10746, a ISO 9126 e mtodos cientficos como o ATAM so
utilizados para suportar as atividades desta pesquisa.
Bass Graff em (GRAAF, 2007) distingue claramente dois tipos de
transformaes durante a vida de um software. Segundo o autor os modelos e
processos existentes envolvem tipicamente transformaes verticais, do abstrato
para o concreto, como acontece no ciclo de desenvolvimento de software. Por outro
lado atividades como manuteno e evoluo, tpicas em qualquer software,
envolvem transformaes horizontais como a migrao do sistema de uma
plataforma para outra. Este trabalho prope o planejamento para execuo de
transformaes horizontais que envolvem aspectos arquiteturais do sistema.

1.4.

Anlise Histrica

A evoluo de Software bem estudada no livro editado por Mens e

Demeyer, Software Evolution (MENS; DEMEYER, 2008) e nos trabalhos de Parnas
(PARNAS, 1994), Van Gurp e Bosch (GURP; BOSCH, 2002) e Eick et al (EICK et
al., 2001).

Outros trabalhos importantes para a contextualizao do tema so

(MENS; WERMELINGER; DUCASSE, 2005), (GODFREY, GERMAN, 2008),

(NIKORA; MUNSON, 2003).

20

No estudo bibliogrfico realizado neste trabalho foi possvel distinguir trs

tipos de iniciativas para tratar a evoluo.

1.4.1 Evoluo de Software dentro do ciclo de desenvolvimento

Muitos autores analisam a evoluo do software durante o processo de

desenvolvimento. Chvez (2009) em Um Processo para o controle da evoluo da
Arquitetura de Software Baseado em ODP. discute sobre o processo de evoluo
da arquitetura de software considerando o seu desenvolvimento, projeto, construo
e manuteno, como um conjunto de passos evolutivos no seu ciclo de vida, cujas
iteraes esto associadas ao ciclo de vida do software. Em cada etapa do processo
de desenvolvimento so geradas novas expectativas que a arquitetura de software
precisa satisfazer, gerando em cada iterao, novas verses dos modelos ou
mesmo refinamentos dos anteriores.

1.4.2 Evoluo de Software a partir das funcionalidades

Evoluo originada do incremento de novas funcionalidades no software.

Estas iniciativas esto muito relacionadas com o termo manuteno de software e as
leis de Lehman (LEHMAN M., 1996).

1.4.3 Evoluo de Software a partir da arquitetura

Neste tipo de iniciativa h uma maior preocupao com o estudo da evoluo

da arquitetura atravs do uso de tcnicas ou elementos arquiteturais, para se
adequar a novos ambientes operacionais e requisitos no-funcionais.

21

Alguns estudos propem o uso de mtodos de avaliao arquitetural. O

objetivo do trabalho apresentado em (GUIMARAES, 2008) fornecer um mtodo
que auxilie a manuteno de sistemas que se tornaram inadequados aliando a
arquitetura de software com a manuteno na forma de fases interativas e com o
uso de tcnicas arquiteturais como avaliao de arquitetura.
Na tese de doutorado de Mikael Svahnberg (2003) o autor apresenta um
estudo sobre evoluo de arquiteturas de software e o que pode ser feito para apoiar
esta evoluo. Esse estudo se concentra em trs aspectos especficos de apoio a
evoluo: como garantir que a combinao correta de atributos de qualidade seja
satisfeita (seleo de arquitetural), os meios tcnicos disponveis para apoiar as
mudanas no sistema de software (variabilidade), e que tipos de mudanas podem
ocorrer durante a evoluo (categorias de evoluo). introduzido um mtodo de
avaliao e seleo de arquitetura, baseado no ATAM e no SAAM (Software
Architecture Analysis Method, que se concentram em garantir que a arquitetura de

software selecionada a arquitetura candidata com o maior potencial para o

cumprimento de um conjunto especial de atributos de qualidade. (SVAHANBERG03,
2003).
Muitas iniciativas propem o desenvolvimento de ferramentas que auxiliem
nesse processo de evoluo. A maioria das ferramentas que exploram a evoluo da
arquitetura de um sistema utiliza um mtodo baseado no tempo, o qual mostra como
um sistema tem mudado em um dado intervalo de tempo. Alguns deles esto em
(MCNAIR; GERMAN; WEBER-JAHNKE, 2007), (RANK, 2005) e (HINDLE et al,
2007). Em (RANK, 2005) proposto um ambiente de engenharia de software
reflexiva. Esse ambiente permite a produo de software que seja fcil de usar. A
criao do software ir manipular uma coleo de vises, incluindo cdigo de baixo
nvel e viso arquitetural de alto nvel que sero interligados atravs de reflexes.
Em (HINDLE et al, 2007) descrito um mtodo e uma ferramenta para modelar,
extrair e animar evoluo arquitetural. Toma como base as mudanas no cdigo
para extrair as mudanas e utiliza animao para visualizar.
Em (TU; GODFREY, 2002) os autores desenvolveram um mtodo para
analisar mudanas estruturais do software chamado Origin Analysis. Por sua vez
em (SADOU; TAMZALIT; OUSSALAH, 2005) os autores propem um modelo de
evoluo de arquitetura de software (SAEV).

22

No quadro 1 possvel observar um resumo do estado da arte apresentado.

Quadro 1-Resumo do estado da arte

Tipo de Evoluo
Ciclo de desenvolvimento
Funcional

Arquitetural

1.5.

Subtipo
_
Mdulos
Leis de Lehman
Avaliao
Modelo
Ferramentas
Mtodo

Referencias
(CHAVEZ, 2009)
(GALL, H. et al., 1997)
(LEHMAN, 1997), (LEHMAN, 1996)
(SVAHANBERG, 2003), (GUIMARAES, 2008)
(GRAAF, 2007),
(SADOU; TAMZALIT; OUSSALAH, 2005)
(MCNAIR, 2009), (RANK, 2005), (HINDLE et al, 2007)
(GODFREY; GERMAN, 2008),( BENNETT E;
RAJLICH,2000)

Estado da Arte da Pesquisa

Considerando os trabalhos em torno de avaliao de arquitetura de software

foram encontradas as seguintes pesquisa.
Em (OLUMOFIN; MISIC, 2005) os autores ampliam o mtodo ATAM para a
avaliao de arquiteturas de software de famlias de produtos. Neste trabalho
apresentado o mtodo HoPLAA (Holistic Product Line Architecture Assessment) que
estende o ATAM com o tratamento qualitativo de anlise de pontos de variao e da
gerao dependente do contexto, classificao e priorizao de cenrios de
atributos de qualidade. uma abordagem holstica que analisa as vantagens e
desvantagens dos atributos de qualidade no s para a arquitetura de linha de
produto, mas considera ainda as arquiteturas de produtos individuais. Alm disso,
prescreve um tratamento qualitativo da anlise de pontos de variao com base em
cenrios. Com este estudo os autores incrementam corpo de pesquisas existentes e
experincias industriais na avaliao de arquiteturas de um nico produto, ao definir
o foco sobre a especificidade de arquiteturas de software de linha de produtos.
Em (RIVA; ROSSO, 2006) os autores trabalharam no domnio de famlia de
produtos de software incluindo evoluo do software e experincias de avaliaes
de arquitetura de software para uma famlia de produtos de software (MACCARI,
2002; ROSSO,2005; ROSSO,2006).

23

Em (BARBACCI et al.2003) os autores descrevem uma avaliao ATAM da

arquitetura de software de sistemas avinicos desenvolvido para o Technology
Applications Program Office of the U.S. Army . O sistema e chamado de Common
Avionics Architecture System, desenvolvido por Rockwell Collins em Cedar Rapids,
Iowa. Considerando que a arquitetura de software um dos fatores determinantes
da qualidade do software, de fundamental importncia para uma organizao
como o Departamento de Defesa, a capacidade de avaliar arquiteturas de software
antes que eles sejam finalizados. Desta forma possvel reduzir substancialmente o
risco de que os sistemas entregues no atinjam suas metas de qualidade. Este
trabalho no tem como foco a evoluo da arquitetura de um software j existente.
O artigo (ROSSO, 2006) apresenta um trabalho dentro do contexto de
avaliao de arquitetura para evoluo de software. Neste trabalho o autor discute
as experincias adquiridas na aplicao de trs diferentes tcnicas de avaliao,
dentre elas o ATAM. As tcnicas apresentadas incluem cenrio de avaliao
baseada em arquitetura de software, avaliao de desempenho e software baseado
em experincia de avaliao. Segundo o autor, as vrias tcnicas de avaliao
estudadas so complementares e, quando utilizadas em conjunto, constituem uma
ferramenta eficaz para que o arquiteto de software possa manter e evoluir um
sistema de software de grande intensidade.
Em um trabalho mais recente,

(DIAS, 2010) apresentado um roteiro que

prope a utilizao das ferramentas da arquitetura de software e da engenharia de

software guiada por valor, ou VBSE (Value-Based Software Engineering), para apoiar o
processo decisrio e justificar a evoluo tecnolgica atravs da atualizao da
arquitetura. O propsito contrir para que o sistema continue adicionando valor
organizao por mais tempo. O trabalho se concentra em unir a fora das ferramentas
de avaliao e medio de arquitetura (como o ATAM) com os princpios da VBSE,
trazendo foco ao negcio e ao valor gerado pelo sistema organizao usuria, sem
perder o rigor dos processos da engenharia de software.

24

1.6.

Contribuies

A contribuio deste trabalho ajudar na compreenso de:

- como a evoluo arquitetural ocorre em um sistema de software,
- como avaliar e selecionar uma arquitetura de software que rena um
conjunto especial de atributos de qualidade.
O roteiro apresentado neste trabalho contribui para que um software baseado
em uma arquitetura se adapta s exigncias de qualidade do ambiente em que esta
inserido, sendo capaz de evoluir com sucesso e consequentemente se mantendo
no mercado por mais tempo.

1.7.

Estrutura e sumrio dos captulos

O restante do trabalho est organizado da seguinte forma: no Captulo 2

apresentam-se os conceitos e definies necessrios para a compreenso da
arquitetura de software e evoluo de software. No Captulo 3 descrito o roteiro
utilizado para avaliao da arquitetura e elaborao do plano de evoluo que o
foco principal desta pesquisa. No Captulo 4 descreve-se a aplicao do exemplo
desenvolvido nesta pesquisa para a compreenso da evoluo do processo de
avaliao. O Captulo 5 apresenta os resultados e as discusses desta pesquisa e,
finalmente, no Captulo 6 so apresentadas as referncias bibliogrficas utilizadas
na pesquisa.

25

2. CONCEITOS

2.1. Arquitetura de Software

Arquitetura de software a ponte entre os objetivos de negcio e o sistema

realizado (CLEMENTS et al., 2002). Para que o sistema se torne adequado, a
arquitetura deve ser moldada de forma a atender uma srie de requisitos funcionais
e requisitos de qualidade (no funcionais) que reflitam os objetivos do negcio.
O projeto arquitetural de grandes sistemas tem sido determinante no sucesso
de um sistema: a escolha de uma arquitetura inapropriada pode ter efeitos
desastrosos (GARLAN; PERRY, 1995).

2.1.1 Histrico da rea

A nfase em Arquitetura de Software como disciplina aconteceu apenas

durante a dcada de 1990 com autores como Perry e Wolf (1992) e Garlan e Shaw
(1994).
Perry e Wolf tiveram uma grande contribuio introduzindo a definio para
arquitetura de software em seu artigo seminal Foundations for the Study of Software
Architecture (1992).
A definio que eles propem consiste na frmula:
Arquitetura = (Elementos, Organizao, Decises)
De acordo com essa definio, a arquitetura de software um conjunto de
elementos arquiteturais que possuem alguma organizao. Os elementos e sua
organizao so definidos por decises tomadas para satisfazer objetivos e
restries.

26

A viso sobre arquitetura de software de Garlan e Shaw (1994) tornou-se

importante por conter trs aspectos.
O primeiro por eles serem explcitos em quando devem ser aplicados os
conhecimentos de arquitetura de software: quando o tamanho e a complexidade dos
sistemas de software crescem.
O segundo por serem claros na separao de tarefas entre o projeto
detalhado e o projeto arquitetural. O projeto detalhado se preocupa com algoritmos e
estruturas de dados. O projeto arquitetural se preocupa com os elementos e
organizao do sistema como um todo, envolvendo: decises sobre as estruturas, a
estrutura global de controle que ser usada, protocolos de comunicao,
sincronizao e acesso a dados, atribuio de funcionalidade a elementos do
sistema e ainda a distribuio fsica dos elementos.
O terceiro aspecto cita que o processo de projeto da arquitetura precisa se
preocupar com atributos de qualidade do sistema envolvendo decises que
impactaro no comportamento do sistema em termos de escala e desempenho,
entre outros atributos de qualidade.
A viso de Bass e outros (BASS; CLEMENTS; KAZMAN, 2003) explcita
quanto ao papel da abstrao na arquitetura (quando fala de propriedades
externamente visveis), e tambm quanto ao papel das mltiplas vises arquiteturais
(estruturas do sistema), deixando clara a importncia das vises arquiteturais muito
usadas em modelos arquiteturais como o RM-ODP por exemplo.
Por fim importante mencionar o padro ISO/IEEE 1471-2000. O propsito
da criao deste padro foi o de ajudar no consenso entre autores, estudantes e
profissionais sobre o que e para que serve a arquitetura de software.
Sua definio de arquitetura de software a seguinte: Arquitetura a
organizao fundamental de um sistema incorporada em seus componentes, seus
relacionamentos com o ambiente, e os princpios que conduzem seu design e
evoluo.
A definio acima consistente com as anteriores por tambm mencionar que
arquitetura compreende estrutura (ou elementos ou componentes), relaes, e
decises (ou princpios). No entanto, ela vai alm ao adicionar mais uma
preocupao arquitetura: conduzir a evoluo do software.

27

Outras definies so encontradas na literatura, mas para esta pesquisa

essas trs definies so importantes e complementares, pois colocam importantes
conceitos como decises, preocupao com atributos de qualidade do sistema e
evoluo que so conceitos bsicos para o desenvolvimento deste trabalho.

2.1.2 Vises da Arquitetura

Viso um dos mais importantes conceitos associados com arquitetura de

software. Segundo Len Bass e outros viso uma representao de um conjunto
coerente de elementos arquiteturais e as relaes entre eles. As vises so
mecanismos que permite separar conceitos enquanto a arquitetura de um sistema
construda ou analisada. (BASS; CLEMENTS; KAZMAN, 2003)
Clements et. al. (2002), afirma que a arquitetura de software uma entidade
abstrata e complexa, que no pode ser descrita e compreendida por todos os
participantes apenas valendo-se de um nico modelo ou mecanismo de
representao. Para tanto, as vises permitem considerar uma arquitetura a partir de
diferentes perspectivas.
Por exemplo, considere as preocupaes de dois diferentes interessados no
sistema: o implementador e o responsvel pela disponibilidade do sistema em
produo. O primeiro est preocupado com elementos como: mdulos, classes e
algoritmos que ele e seu time tero que construir, como e com quais subsistemas
esses mdulos iro se comunicar ou ainda quais restries de comunicao foram
impostas em seu design. Por outro lado, o responsvel pela disponibilidade est
preocupado em como o software est distribudo entre as mquinas, que
funcionalidades sero afetadas caso um conjunto especfico de mquinas deixe de
funcionar, ou como ser possvel realizar a troca de um servidor sem afetar o tempo
de incio de uma transmisso de vdeo.
possvel observar que h preocupaes distintas entre os dois interessados
e assim perceber que dimenses diferentes da arquitetura so necessrias para
satisfaz-los.

28

Para o primeiro, a arquitetura deve mostrar que mdulos lgicos (pacotes,

classes, bibliotecas) compem o sistema, alm das relaes de comunicao e
restrio entre eles. J para o segundo, a arquitetura deve mostrar como o sistema
est dividido fisicamente, quais partes do sistema esto executando em quais
computadores, quais os links fsicos entre esses computadores, etc.
Clements e outros citam que vises arquiteturais comuns incluem:
Vises Funcionais ou lgicas: uma abstrao das funes do sistema e
seus relacionamentos. Exemplos de componentes so: abstraes do sistema e
elementos de domnio. Exemplos de relacionamentos so dependncias e fluxo de
dados entre os componentes.
Vises de Concorrncia ou dinmicas: Mostra que processos ou threads
sero criados e como eles iro se comunicar e compartilhar recursos. Exemplos:
processos, threads e protocolos presentes no sistema,
Vises de Cdigo: a viso que interessa ao programador. Os componentes
dessa viso so classes, objetos, procedures, e funes e suas abstraes em
componentes, camadas ou mdulos. O relacionamento chamado de invocao de
mtodos.
Vises de desenvolvimento ou implementao: Tambm de interesse do
desenvolvedor. a viso que estrutura o cdigo fonte em repositrios que os
desenvolvedores criam, modificam e gerenciam, Os componentes desta viso so
tipicamente, arquivos e diretrios e o principal relacionamento entre eles e o est
contido em.
Vises fsicas: definir onde as partes dinmicas executaro, ou seja, onde e
em quais mquinas os diversos executveis do software estaro implantados, alm
de como eles vo se comunicar.
Algumas referncias importantes sobre vises arquiteturais so: The 4+1
View Model of Architecture de Kruchten (1995), Documenting Software Architectures:
Views and Beyond de Clements et al (2002) e o padro ISO/IEEE 1471-2000.
A Norma ISO 42010 (ISO/IEC 2007 apud CHVEZ, 2009) organiza os
conceitos de representao de arquiteturas. De acordo com a norma, as descries
da arquitetura de software esto conformadas pelo conjunto de vises que

29

representam de forma concreta os pontos de vista e os interesses associados a

cada participante. As vises so representadas atravs de modelos, os quais so
abstraes, normalmente representadas de forma grfica de acordo com uma
linguagem de modelagem ou notao. (CHVEZ, 2009)
Nesta pesquisa consideramos as vises utilizando o modelo de referncia
ODP.

2.1.3 O modelo de referncia RM-ODP ISO/IEC 10746

O Modelo de referncia para Processamento Distribudo Aberto (RM-ODP)

um framework para a especificao de sistemas distribudos baseado em cinco
pontos de vista. De acordo com o padro ISO 42010 (ISO/IEC 2007 apud CHAVEZ,
2009) um ponto de vista fornecem um padro ou template, a partir do qual possvel
desenvolver vises individuais, estabelecer os objetivos e a audincia para uma
viso e as tcnicas para sua criao e anlise. (CHVEZ, 2009).
O RM-ODP representa vrios aspectos e caractersticas de sistemas atravs
destas cinco abstraes que so: empresa, informao, computao, engenharia e
tecnologia. Esses pontos de vista so independentes entre si, mas complementares.
Jorge Becerra (1998) explica a origem dos cinco nveis de abstrao com a seguinte
colocao:
A Norma ISO/IEC 10746-3 contm as informaes relacionadas com a
definio das especificaes dos cinco pontos de vista, com as funes ODP e com
as transparncias a implementar. Estas informaes contm as caractersticas que
qualificam o sistema distribudo como aberto. (BECERRA, 1998)
Com base nas definies de Becerra (1998) e de Chvez (2009), os pontos
de vistas so definidos da seguinte maneira:
Ponto de vista de empresa: Este ponto de vista especifica o modelo de
negcios da empresa definindo os requisitos do sistema. Ele especifica quais
necessidades de negcio so satisfeitas pela arquitetura. um documento utilizado
para validao com o cliente. Segundo Becerra (1998), neste ponto de vista so

30

definidos o objetivo e escopo da empresa, as polticas que define a atuao do

sistema, e as polticas que definem o inter-relacionamento da empresa com
entidades externas.
Ponto de vista de informao: O ponto de vista de informao especificado
atravs do uso de esquemas, os quais descrevem o estado (semntica do
processamento) e a estrutura (semntica da informao) de um objeto. Ele captura o
estado e a estrutura de um objeto num instante especfico do tempo.
Em (BECERRA, 1998) o autor disserta que a estrutura do ponto de vista da
informao ou a semntica da informao definida dentro de trs tipos de
esquemas:
- Esquema invariante: conjunto de condies ou predicados que sempre so
verdadeiros aplicados a um ou a um conjunto de objetos informao. Estas
condies regulamentam os possveis estados ou mudanas de estados dos objetos
informao.
- Esquema esttico: a especificao de um estado de um objeto ou conjunto
de objetos informao, em um ponto especfico dentro do tempo de processamento.
- Esquema dinmico: define todos os estados de um objeto ou conjunto de
objetos informao dentro do tempo de processamento.
Ponto de vista de computao: O ponto de vista de computao utilizado
para especificar as funcionalidades de uma aplicao. baseado em objetos que
possuem caractersticas como o encapsulamento de dados e processamento. Uma
especificao computacional define os objetos do sistema suas atividades e as
interaes que ocorrem entre eles. Os objetos esto conectados por ligaes
atravs das quais as interaes acontecem ou por outros objetos (de ligao) que
descrevem interaes complexas entre objetos. (CHVEZ, 2009). Neste ponto de
vista existe a preocupao com a distribuio das aplicaes dentro do sistema, sem
se preocupar com a infra-estrutura de comunicao (BECERRA, 1998)
Ponto de vista de engenharia: O ponto de vista de engenharia usado para
especificar os aspectos da distribuio de um sistema. Ele define o modelo que
conforma uma infra-estrutura de sistemas distribudos. As entidades principais deste
ponto de vista so os objetos e os canais. (CHVEZ, 2009). Os objetos so
classificados e dois tipos: objetos bsicos de engenharia (correspondentes com os

31

objetos do ponto de vista de computao) e os objetos de infra-estrutura como, por

exemplo, o objeto protocolo de comunicao. Um canal corresponde a uma ligao
ou a um objeto de ligao no ponto de vista de computao.
Ponto de vista de tecnologia: Descreve a implementao do sistema e as
informaes requeridas para seus testes. O padro ODP tem poucas regras
aplicveis especificao de tecnologia.

2.1.4 Avaliao de Arquitetura

A avaliao arquitetural consiste em caracterizar e avaliar os documentos

arquiteturais atravs de mtodos ou procedimentos sistemticos (BAHSOON e
EMMERICH, 2003). Essa avaliao verifica principalmente se as informaes
descritas no documento esto consistentes e se a arquitetura nele representada
atende aos requisitos especificados para o produto (BARCELOS, 2006). Avaliao
arquitetural um dos aspectos entre muitos outros que garantem o sucesso do
software, pois asseguram o controle de qualidade e a garantida de qualidade do
sistema. O resultado de uma avaliao arquitetural forma a base para tomada de
decises sobre como continuar, ou no, com o desenvolvimento da arquitetura de
software. Tais decises so necessrias em todas as fases do desenvolvimento do
software, como por exemplo, na fase de elicitao de requisitos, criao e projeto da
arquitetura, planejamento da manuteno. Em (CLEMENTS et al., 2002) os autores
apontam duas possveis fases de avaliao arquitetural, em estgios iniciais e em
estgios finais do clico de vida do software:
- Avaliao de arquiteturas que so executadas para auxiliar a tomada de
decises durante os estgios iniciais do desenvolvimento do software, neste caso a
avaliao feita para aumentar o entendimento da arquitetura de software, dos
atributos de qualidade requeridos. As bases principais desse tipo de avaliao so a
experincia dos desenvolvedores e cenrios baseados em requisitos que esto nos
documentos de requisitos.
- Avaliaes que so conduzidas durante estgios mais avanados do ciclo
de vida do Software. Neste caso j existe, ao menos, um projeto detalhado

32

disponvel no qual mtricas concretas podem ser coletadas para avaliar a arquitetura
de software com respeito a um ou mais atributos de qualidade.
Outra distino pode ser feita levando em considerao as tcnicas usadas
por diferentes mtodos de avaliao arquitetural. Em (CLEMENTS et al., 2002) os
autores distingue as tcnicas entre questionamentos e raciocnio.
Entre os mtodos existentes o ATAM se destaca por estar centrado na
identificao de pontos de Trade-off4 da arquitetura a partir da perspectiva das
exigncias de qualidade do produto.
O

ATAM tem um bom histrico de aplicaes bem sucedidas na prtica

[(BARBACCI et al. 2003), (BASS 2003)], alm disso, sua caracterstica mais
relevante, e que no encontrada em outros mtodos, a anlise de tradeoff entre
os atributos de qualidade diferentes (OLUMOFIN;MISIC 2005). A avaliao da
qualidade de arquiteturas de sistemas como o avaliado neste trabalho requer que os
requisitos especficos de arquiteturas sejam contabilizados.
No processo executado neste trabalho o foca esta na avaliao em estgios
finais com o objetivo de avaliar o sistema atual para delinear as mudanas
necessrias para a nova verso. Entre as diversas tcnicas existentes a mais
adequada para o uso no processo proposto a tcnica de avaliao de arquitetura
com base em cenrios e entre os mtodos que utilizam esta tcnica optou-se pelo
ATAM como meio de apoiar as decises arquiteturais. O ATAM alm de ser baseado
em cenrios tambm uma tcnica de raciocnio usando sadas quantitativas.
Rafael Barcelos em sua dissertao (BARCELOS, 2006) apresenta uma
reviso sistemtica onde realiza uma comparao entre 27 abordagens de avaliao de
arquiteturas. Nesta comparao possvel observar que o mtodo ATAM um dos

mtodos de avaliao mais completos. A completude do mtodo no razo

suficiente para sua escolha o fato relevante que o ATAM se concentra principalmente
em identificar as abordagens e os estilos arquiteturais utilizados na especificao da
arquitetura analisada, pois eles representam a forma que o arquiteto utilizou para adequar a
arquitetura aos requisitos de qualidade especificados.

Um ponto de trade-off uma propriedade que afeta mais que um atributo e um ponto sensitivo
para pelo menos um atributo de qualidade. (DOBRICA; NIEMELA, 2002).

33

Em (BAHSOON;EMMERICH, 2003) os autores fazem um levantamento sobre

os mtodos de avaliao de software de arquitetura. Em seguida, focam para uma
classe emergente de mtodos que avalia arquiteturas de software para alcanarem
estabilidade e evoluo. O artigo define a estabilidade da arquitetura e formula o
problema de avaliar arquiteturas de software para a estabilidade e evoluo.
Segundo os autores, de uma perspectiva evolutiva, as revises so atividades
preventivas para retardar a decomposio (como referido por Parnas) e limitar o
efeito de envelhecimento software (PARNAS,1994]. Avaliaes de arquitetura
representam um esforo de sbios de reduo de risco e so relativamente baratos
(CLEMENTS,2002).
Segundo os autores o ATAM no s revela o quanto uma arquitetura satisfaz
os requisitos de qualidade, mas tambm revela como esses requisitos de qualidade
interagem uns com os outros a partir dos trade-offs. O ATAM um mtodo de
avaliao de arquitetura baseado em cenrios. Um cenrio descreve a interao do
sistema a partir do ponto de vista do usurio.

2.1.5 Deciso Arquitetural

No processo de desenvolvimento de arquitetura de software as decises no

so explicitamente documentadas, mas esto implcitas nos modelos e arquiteturais
construdas.
Apoio a decises de engenharia de software um complemento para
reutilizao de experincias em uma organizao de desenvolvimento. O foco de
mtodos de apoio deciso estruturar experincias para formar uma imagem mais
clara, para que uma deciso possa ser tomada.
Algumas justificativas para o uso de tcnicas de apoio deciso so:

Problemas de deciso so muitas vezes mal compreendidos e/ou

descrito.

As decises so feitas no ltimo momento e / ou sob presso de

tempo.

34

As decises no se baseiam em modelos empiricamente avaliados, o

melhor conhecimento e experincia e uma boa metodologia.

As decises so tomadas sem levar em conta as perspectivas de todas

as partes envolvidas.

As decises no so explicadas aos envolvidos.

2.2. Evoluo de Software

Um sistema adequado aquele que possui uma arquitetura moldada para

implementar uma srie de requisitos funcionais e requisitos de qualidade (requisitos
no funcionais) necessrios para atender os objetivos de negcio para o qual o
sistema foi proposto. Um sistema pode se tornar inadequado ao longo do tempo
devido eroso. Esse fenmeno tambm conhecido como, envelhecimento de
software (Software Aging) (PERRY;WOLF, 1992) ou eroso de arquitetura
(JAKTMAN;LEANEY;IU, 1999).
Essencialmente o problema acontece devido necessidade de evoluo do
software. A evoluo consiste na realizao de alteraes para atender novos
requisitos consertar defeitos ou otimizar atributos de qualidade (manutenes
adaptativas, corretivas e de aperfeioamento) (SWANSON, 1976).
Os autores TU. Q e GODFREY. M. W., definem a evoluo de software em
"An Integrated Approach for Studying Architectural Evolution", da seguinte forma:
A Evoluo de Software, uma das disciplinas emergente da engenharia de
software, explora os mecanismos que afetam mudanas e fornece
guidelines para melhorar o processo de evoluo de software. [(TU;
GODFREY, 2002), traduo nossa].

Esta pesquisa est essencialmente ligada evoluo de software no contexto

da evoluo da arquitetura de sistemas que fazem parte de uma linha de produto
com o objetivo de dar suporte para construo de uma nova verso do software. A
seguir feito uma descrio das caractersticas e conceitos fundamentais da
evoluo de software.

35

Evoluo de software o fenmeno de mudana que ocorre no software ao

longo dos anos e das mltiplas verses, desde seu incio at o completo abandono
do sistema.
PORTER em Fundamental Laws and Assumptions of Software Maintenance
(1997) afirma que todo software esta em um contnuo processo evolutivo. Essa
evoluo surge a partir de sucessivas alteraes: para consertar erros, aumentar
desempenho ou atender outros requisitos de qualidade e se adaptara novos
ambientes. importante salientar que essas mudanas no esto somente
relacionadas com a adio e remoo de funcionalidades, mas tambm esto
relacionadas com a manuteno do cdigo ao longo do ciclo de vida do software. A
manuteno pode aprimorar ou deteriorar tanto atributos externos de qualidade do
software (percebidos pelos usurios), como por exemplo, desempenho, tolerncia a
falhas, disponibilidade, quanto atributos internos (percebidos pelos envolvidos no
desenvolvimento) como, por exemplo, testabilidade, legibilidade, reusabilidade.

2.2.1. Manuteno de software

No atual estgio de maturidade, a engenharia de software passa a dedicar

maior ateno atividade de manuteno de software. Essa postura decorre, em
parte, da crescente quantidade de software em funcionamento nas organizaes ao
redor de todo globo, que por representarem investimentos significativos, precisam
continuar em funcionamento atravs dos anos, momento no qual surge a
necessidade de manuteno de software.( PADUELLI, 2007).
A atividade de manuteno de software caracterizada pela modificao de
um produto de software j entregue ao cliente, para a correo de eventuais erros,
melhora em seu desempenho, ou qualquer outro atributo, ou ainda para adaptao
desse produto a um ambiente modificado (IEEE, 1998).
Embora a definio trate genericamente qualquer produto de software,
existem diferenas entre a manuteno de softwares com propsitos distintos. Essa
distino explicada por Pfleeger (2001), que estabelece trs categorias de
sistemas.

36

A primeira categoria classifica softwares construdos com base em

especificaes rgidas e bem definidos. Nesse tipo de software dificilmente haver
necessidade de manuteno. A segunda categoria agrupa softwares que constituem
implementaes de solues aproximadas para problemas do mundo real o
desenvolvimento da soluo desejada descreve o problema de forma abstrata e
define os requisitos de software a partir dessa abstrao. A terceira categoria
considera mudanas no ambiente onde o software vai ser utilizado.
Atividades de manuteno de software so caracterizadas por intervenes
no produto de software de forma a evitar a sua deteriorao. Um software no se
desgasta como peas de um equipamento, mas se deteriora no sentido de os
objetivos de suas funcionalidades cada vez menos se adequarem ao ambiente
externo.

2.2.2. O processo de envelhecimento de software

Segundo CHRISTOPH (2004), acreditar que uma vez que um software realize
corretamente os requisitos estabelecidos para os quais ele foi construdo, ele nunca
mais precisar ser modificado, um erro, pois sistemas sofrem de um processo
semelhante ao envelhecimento humano. Isso impulsionado pelo fato de que o
mundo real est em constante mudana, e sistemas so feitos para refletir
comportamentos do mundo real (GALL, H. et al., 1997), desta forma necessrio
que o software acompanhe as mudanas de requisitos impostas pelo ambiente na
qual ele est inserido. O no acompanhamento dessas mudanas pode implicar em
perda de qualidade por parte do software ou at mesmo na descontinuidade do
mesmo.
PARNAS em Software Aging (1994) afirma que entender as causas do
envelhecimento de software se faz necessrio para que seja possvel tomar medidas
para limitar seus efeitos, temporariamente reverter os danos causados por ele e se
preparar para o dia em que este software no seja mais vivel.

37

Segundo o autor:
Existem dois tipos de envelhecimento de software: o primeiro ocorre quando
h falhas na adaptao do software para atender os novos requisitos, e o
segundo ocorre devido ao resultado provocado pela forma como as
mudanas so realizadas no software (PARNAS, 1994 p 279).

No primeiro caso o software precisa passar por uma mudana estrutural para
se adequar h um novo ambiente operacional. O segundo caso gerado por
manutenes inadequadas que afetam a estrutura, com o passar do tempo novas
mudanas se tornar mais difcil e cara. Caso no seja feita uma reestruturao do
software, este chegar a um ponto onde novas atualizaes ficaro inviveis.
As desvantagens causadas pelo envelhecimento de um software so a perda
de desempenho devido a modificaes no adequadas na sua estrutura interna,
nmero crescente de novos erros devidos a alteraes indevidas no cdigo e perda
de usurios devido falta de meios para concorrer com verses mais recentes de
sistemas semelhantes. Os efeitos do envelhecimento podem ser atrasados ou
minimizados, desde que sejam tomados alguns cuidados no desenvolvimento e
evoluo do software em questo. Segundo PARNAS (1994) os cuidados mais
importantes so:

1.

Estruturar o software para a evoluo: Sempre que um software tenha

uma expectativa de vida longa, sua estrutura deve ser feita visando facilitar a
evoluo. Como no possvel saber com exatido quais mudanas sero feitas no
futuro, devem ser avaliadas as partes do software que estaro mais sujeitas a
mudanas no decorrer de sua vida til e desenvolv-las de forma que estas
mudanas ocorram mais facilmente.

2.

Documentar adequadamente: Nem sempre a documentao de um

projeto escrita pela pessoa mais qualificada para tanto, e mesmo que esta venha a
ser escrita adequadamente, sempre necessrio que seja atualizada a contento
medida que novas mudanas forem sendo feitas no cdigo.

3.

Revisar a estrutura: Sempre que a estimativa de vida til do software

seja longa, revises da estrutura so fundamentais. As revises devem comear

38

antes mesmo da codificao, tais revises so baratas, rpidas e podem poupar

muito tempo e recursos no futuro.
O processo de envelhecimento de um software inevitvel, o que gera uma
necessidade constante de evoluo por parte de todos os sistemas que esperam se
manter ativos por um longo perodo. Para entender o processo evolutivo em
questo, necessrio entender as oito leis da evoluo de software, estas leis
tambm so conhecidas pelo nome de Leis de Lehman (LEHMAN, 1996).

2.2.3 Leis da Evoluo de Software

As oito leis da evoluo de software, tambm conhecidas por Leis de

Lehman, comearam a ser formuladas entre as dcadas de 70 e 90, com a anlise
do processo de programao da IBM, (LEHMAN, 2001, 1996).

A princpio

imaginavam que todas as leis se aplicassem a qualquer evoluo de software, mas

estudos como apresentados em (TU; GODFREY, 2002) com o Software Livre,
mostram que nem sempre isto verdade. Neste artigo o autor mostra que o
crescimento evolutivo de um software diminui ao longo do tempo e parte do
crescimento vem de adies de novas funcionalidades e suporte a novas
arquiteturas, e no de simples correes de erros de verses anteriores.
Tambm foi observado por Godfrey (2002) que projetos como o do Linux
parece no obedecerem terceira lei de Lehman, e que o esforo incremental gasto
em cada verso no permanece constante durante a vida do sistema como diz a lei.
Como evidencia verifica-se a grande discrepncia na variao de tamanho entre os
arquivos fontes de uma verso para outra (variando de alguns bytes a alguns
megabytes em cada verso) e o aparecimento de novos arquivos fontes adicionados
ao software. Percebe-se ainda, que o subsistema responsvel pelos drivers possui
um crescimento bem superior aos demais subsistemas, o que mostra que muito
deste esforo incremental adicional vem do fato do surgimento de novos drivers para
dar suporte a novos equipamentos.

39

O Quadro 2 apresenta as oito leis.

Quadro 2 - As oito leis de Evoluo de Software

Mudana contnua

Um sistema de informao que usado deve ser continuamente

adaptado, caso contrrio se torna progressivamente menos satisfatrio,
medida que um programa alterado, sua complexidade cresce a
menos que um trabalho seja feito para mant-la ou diminu-la.
O processo de evoluo de software auto-regulado prximo
distribuio normal com relao s medidas de produtos e atributos de
processos.
A taxa de atividade global efetiva mdia em um sistema em evoluo
constante sobre o tempo de vida do produto.
Durante a vida produtiva de um programa em evoluo, o ndice de
alteraes em verses sucessivas estatisticamente invariante.
O contedo funcional de um programa deve ser continuamente
aumentado para manter a satisfao do usurio durante seu tempo de
vida.
Programas apresentaro qualidade decrescente a menos que sejam
rigorosamente mantidos e adaptados s mudanas no ambiente
operacional.
Processos de programao de software constituem sistemas de multiloop,multi-level e devem ser tratados como tais para serem modificados e
melhorados com sucesso.

Complexidade crescente
Auto-regulao

Conservao da estabilidade
organizacional
Conservao da Familiaridade
Crescimento contnuo

Qualidade decrescente

Sistema de retorno

As leis de Lehman ajudam a compreender como ocorre o processo evolutivo

de um Software no seu aspecto funcional. No entanto devido ao avano das
tcnicas, processos e prticas de desenvolvimento e manuteno de software nos
ltimos 10 anos, alm do aumento de projetos de software livre no cenrio mundial,
verificou-se a partir de alguns estudos de casos que as leis da evoluo de software
necessitam de uma reviso profunda. Um dos fatos que talvez levem a esta reviso,
que os estudos que levaram as formulaes das leis usaram como base processos
de

desenvolvimento

de

sistemas baseados em sistemas centralizados e

corporativos, com cdigo fechado e de grande porte com poucos concorrentes no

mercado e para uso de grandes corporaes. Tais caractersticas em nada se
assemelham a sistemas atuais (como por exemplo, os projetos de software livre) que
so geralmente feitos e mantidos em sistemas descentralizados e coletivamente por
uma comunidade ou mesmo uma equipe de desenvolvimento distribuda.
(SCACCHI, 2004).
Considerando que um dos principais objetivos de se projetar uma arquitetura
o de atingir a qualidade desejada pelos interessados no sistema, fica claro o papel
da arquitetura em conduzir a evoluo do software, uma vez que ela conter

40

decises que contribuiro para a preservao da qualidade do sistema durante seu

ciclo de vida.

2.3.

Requisitos no-funcionais e atributos de qualidade

Um software tem como objetivo atender aos seus requisitos funcionais e nofuncionais. Os requisitos funcionais descrevem as funes que o software deve ser
capaz de realizar, ou seja, o que o sistema faz. J os requisitos no-funcionais
descrevem as qualidades e restries de como o sistema realiza suas funes, ou
seja, como o sistema funciona. Um software, portanto, deve exibir atributos de
qualidade que atendam aos seus requisitos.
A arquitetura de software descreve como o software atende aos requisitos
no-funcionais para alcanar os atributos de qualidade atravs das diversas
decises presentes na arquitetura. Para conceber essas decises arquiteturais e,
portanto, para projetar a arquitetura, de fundamental importncia que o arquiteto
conhea tanto os objetivos a serem alcanados pelo software, quanto s
ferramentas para alcan-los. Em outras palavras essencial que ele conhea tanto
os atributos de qualidade, quanto tcnicas e padres de design arquitetural que, ao
serem implementados, possibilitam ao software que exiba os atributos de qualidade
desejados.
Nesta seo, ser apresentada uma viso geral do assunto, abordando
diversos atributos que devem ser alcanados tendo como objetivos:

Identificar o que so atributos de qualidade e qual sua influncia na

arquitetura de software;

Relacionar atributos de qualidade a decises arquiteturais que os

proporcionam;

relacionam.

Entender que os atributos de qualidade se relacionam e como eles se

41

2.3.1. Requisitos no-funcionais

Os requisitos no-funcionais esto relacionados qualidade da realizao

dos requisitos funcionais, ou seja, como essas funes so realizadas, e por isso
podem ser identificados nas colocaes dos diversos stakeholders sobre os
requisitos funcionais ou podem ser explicitamente impostos pelos diversos
stakeholders do software.
Requisito no-funcional pode ser definido como a descrio de propriedades,
caractersticas ou restries que o software apresenta exibidas por suas
funcionalidades.
Exemplo de requisitos no-funcionais:
(RNF01): O sistema deve permitir o chek-in de passageiro por diversas interfaces
diferentes: navegador de internet, celular, aplicao-cliente compatvel com os
sistemas operacionais Windows e Linux;
(RNF02): O sistema deve suportar at 3 mil atendimentos de passageiros por dia
em operaes de 2 minutos;
As restries feitas pelos requisitos no-funcionais so vrias e podem incluir
restries ao processo de desenvolvimento, restries para atingir ou manter
compatibilidade, e restries legais, econmicas ou de interoperabilidade.
As restries ao processo de desenvolvimento podem ser feitas pela
imposio de padres ou linguagens de desenvolvimento. Por exemplo, um requisito
no-funcional de um sistema pode ser determinar que o software seja implementado
em uma determinada linguagem, dado que a equipe responsvel pela operao e
manuteno seja experiente nessa linguagem.
Os requisitos no-funcionais podem ainda ser divididos em trs tipos:
Requisito no-funcional de produto: Requisito que especifica as caractersticas
que um sistema ou subsistema deve possuir. Esto relacionados qualidade do
software e so alcanados pelos atributos de qualidade. Por exemplo, grau de
confiabilidade,

nvel

de

eficincia,

portabilidade

para

diversos

operacionais, so atributos de qualidade que o software deve exibir.

sistemas

42
Requisito no-funcional de processo: Requisito que restringe o processo de
desenvolvimento do software. Esse tipo de requisito encontrado em empresas
ou organizaes que possuem um processo j definido.
Requisitos no-funcionais externos: Requisito derivado do ambiente em que o
sistema desenvolvido, que pode ser tanto do produto quanto do processo. O
ambiente pode ser tanto a organizao, como polticas que devem ser seguidas,
quanto legislao vigente do pas em que o sistema est operando.
Os livros Software Engineering, de Sommerville (2004), Requirements
Engineering: Processes and Techniques, de Sommerville e Kotonya (KOTONYA;
SOMMERVILLE, 2008), Software Engineering: A Practitioner's Approach de
Pressman (1994), dedicam alguns captulos a este assunto. No entanto, o foco
desses livros no papel dos requisitos de software no processo de desenvolvimento.
J o artigo Defining Non-Functional Requirements, de Malan e Bredemeyer (MALAN;
BREDEMEYER, 2001), mais voltado influncia dos requisitos na arquitetura.

2.3.2. Atributos de qualidade

Bass e outros no livro Software Architecture in Practice, mostra o papel dos

atributos de qualidade na arquitetura de software. Alm dele, Gorton (GORTON,
2006) faz uma pequena introduo a este assunto ao tratar do estudo de caso
presente em Essential Software Architecture. Os livros Software Systems
Architecture, de Rozanski (ROZANSKI,1995), e Code Complete, de Steve
McConnell, tambm dedicam sees aos atributos de qualidade de software, sendo
o primeiro em nvel de design arquitetural e o segundo em nvel de design
detalhado.
comum encontrar a afirmao que o software possui requisitos nofuncionais a serem atendidos, que exibe atributos de qualidade que atendem aos
requisitos em questo. Portanto, atributos de qualidade esto mais relacionados aos
objetivos j alcanados, enquanto requisitos so os objetivos propostos.

43

Segundo Dobrica (2002), Um atributo de qualidade uma caracterstica nofuncional de um componente e sistema (DOBRICA, 2002 p. 639).
A arquitetura permite que o software atenda aos atributos de qualidade
especificados. J que a especificao dos atributos feita pelos requisitos
(normalmente no-funcionais), requisitos e atributos de qualidade partilham diversas
caractersticas. Alguns autores usam ambas as expresses com o mesmo sentido.
Assim como acontece com os requisitos no funcionais, os atributos no
existem isoladamente e, por afetarem partes em comum da arquitetura, afetam
tambm outros atributos de qualidade. Eis que surgem os trade-offs entre os
atributos de qualidade. papel do arquiteto, conhecer e resolver os trade-offs entre
os atributos de qualidade durante as fases de design e implementao.
Uma das principais preocupaes da arquitetura o atendimento aos
atributos de qualidade do sistema, tambm referenciados como Requisitos No
Funcionais. Atributos de qualidade determinam a maneira como o sistema executar
suas funcionalidades. Esses atributos so impostos pelos diversos interessados no
sistema e podem ser classificados em trs tipos: atributos do produto, atributos
organizacionais, e atributos externos.
Atributos de qualidade do produto so aqueles que ditam como o sistema vai
se comportar. A seguir relacionamos os atributos de qualidade que sero usados
como referncia para avaliao arquitetural realizada neste trabalho.
Atributos de qualidade organizacionais so consequncias de polticas ou
procedimentos organizacionais. Em outras palavras, o sistema deve respeitar
padres ou regras impostas por uma ou mais organizaes envolvidas para atender
a esses requisitos.

2.3.2.1 Padro ISO/IEC 9126-1:2007

O Padro ISO/IEC 9126-1:2007 um padro internacional para avaliao de

software. Na primeira parte do padro so apresentadas as qualidades internas e
externas do software. Essas qualidades so apresentadas na forma de uma lista

44

exaustiva de caractersticas ou atributos de qualidade. Os atributos que um software

deve possuir para que possamos dizer que ele de qualidade so os seguintes:

Funcionalidade: a capacidade do software de realizar as funes que

foram especificadas. Apesar de parecer bvio, seu propsito claro quando

avaliado se esse sistema faz menos do que esperado dele. Neste caso ele no
serve, mesmo que o pouco que ele faa, seja feito de forma usvel e confivel ou
eficientemente.

Confiabilidade: Um sistema confivel, quando capaz de manter algum

nvel de desempenho quando funcionando sob circunstncias determinadas. A

confiabilidade normalmente definida sob perodos de tempo. Vale observar que, a
medida de confiabilidade pode ser sazonal, definidas a partir de cenrios crticos que
acontecem em uma determinada poca do ano.

Usabilidade: Usabilidade a medida da facilidade de o usurio executar

alguma funcionalidade do sistema. Essa facilidade est ligada diretamente

compreensibilidade, facilidade de aprendizado, operabilidade, a quanto o usurio
se sente atrado pelo sistema e adeso de padres de usabilidade, que so as
subcaractersticas desse atributo de qualidade.

Eficincia: A eficincia ou desempenho talvez a qualidade mais buscada

durante o desenvolvimento de software, uma vez que ela a mais percebida pelos
usurios. Ela a qualidade relacionada ao uso de recursos do sistema quando esse
prov funcionalidade e tambm a com que os desenvolvedores mais se
preocupam.

Manutenibilidade: uma qualidade, s vezes, negligenciada pelos usurios,

mas muito importante aos desenvolvedores. Ela a capacidade de o software ser

modificado em seu processo de evoluo.

Portabilidade: O ltimo atributo de qualidade presente no padro ISO/IEC

9126-1:2007 o de portabilidade. Esse atributo a medida de adaptaes

necessrias para que o sistema tenha seus requisitos ou ambientes de execuo
modificados, podendo ser o ambiente de software, de hardware ou organizacional.
Esse atributo importante, por exemplo, para jogos e aplicativos para celulares, uma
vez que desejvel que eles sejam capazes de executar no maior nmero de
plataformas e modelos diferentes, mas tambm desejvel que o custo para tornar
isso possvel seja baixo. Portanto, no faz sentido que o mesmo aplicativo seja

45

reimplementado diversas vezes, mas sim que seja projetado de forma a minimizar o
esforo para alterar o ambiente de hardware.
importante enfatizar que essa lista tem como objetivo ser exaustiva. Portanto, de
acordo com a norma, todas as qualidades que venham a ser requisitadas ao
software esto presentes nessa lista. No padro, cada caracterstica ainda
quebrada em subcaractersticas, que so mais especficas, a fim de facilitar o
entendimento e a avaliao. Algumas subcaractersticas importantes a cada atributo
de qualidade esto apresentadas no Quadro 3:
Quadro 3 - Subcaractersticas importantes aos atributos de qualidade

Funcionalidade

FUNCIONALIDADE

Adequao

Capacidade de prover as funes necessrias para os objetivos dos usurios.

Preciso
Interoperabilidade
Segurana

Capacidade de prover os resultados com o grau de preciso adequado.

Capacidade de interagir com outros sistemas.
Capacidade de funcionar segundo os princpios de autenticao, autorizao,
integridade e no repudiao.
Capacidade de se prevenir de falhas resultantes de faltas de software.

Confiabilidade

Maturidade,
Tolerncia a falhas,
Recuperabilidade,

Usabilidade

Compreensibilidade

Facilidade de aprendizado

Manutenibilidade

Eficincia

Operabilidade
Desempenho

Portabilidade

REQUISITO

Capacidade de manter alguma qualidade de servio em caso de faltas de

software ou comportamento imprevisto de usurios, software ou hardware.
Ou resilincia, a capacidade do sistema voltar ao nvel de desempenho
anterior as falhas de software, hardware ou devido ao comportamento
imprevisto de usurios, e recuperar os dados afetados, caso existam.
Capacidade de o usurio entender o sistema.

Est ligada diretamente compreensibilidade. No entanto, neste caso, a

qualidade a de o usurio aprender a usar o software, caso ele saiba que o
software serve para ele.
Capacidade de o usurio operar ou controlar o sistema.
Comportamento no tempo, ou a capacidade do sistema de alcanar a resposta
dentro do perodo de tempo especificado

Uso de recursos

Ou escalabilidade capacidade de o software exigir mais ou menos recursos de

acordo com suas condies de uso.

Analisabilidade

Grau de facilidade com que podemos procurar por deficincias no software ou

por partes que devem ser modificadas para algum fim.

Modificabilidade

Capacidade de realizar mudanas de implementao no sistema

Testabilidade

Capacidade de o software ter suas mudanas validadas.

Adaptabilidade

Capacidade de o software ser portado para outro ambiente sem precisar de

modificaes alm das previstas.

Instalabilidade
Co-existncia

Capacidade de o software ser instalado em algum ambiente especfico.

Capacidade de o software compartilhar recursos em um mesmo ambiente com
outros sistemas.

46

2.3.2.2 Atributos de Negcio

Alm dos atributos de qualidade apresentados existem ainda alguns atributos

adicionais que merecem ser citados. So chamados os atributos de qualidade de
negcio, que, apesar de no serem ligados diretamente ao software, tm grande
influncia sobre sua arquitetura. Eles so importantes porque influenciam
principalmente as decises de resoluo de conflitos dos atributos apresentados
anteriormente.
Os atributos de negcio so apresentados no Quadro 4.
Quadro 4 - Os atributos de negcio.
Mercado-alvo

Atributos de Negcio

Time-to-market

Custo e benefcio

Vida til

Agenda
lanamento

de

O arquiteto s capaz de priorizar os atributos de qualidade em seu design se conhecer o

pblico e o mercado para o qual o software est sendo construdo. Por exemplo, se o alvo
o publico geral portabilidade e funcionalidade so importantes. Por outro lado, para
sistemas especialistas, possvel priorizar a eficincia em detrimento da portabilidade ou da
usabilidade, uma vez que os usurios comuns desse sistema so operadores qualificados.
o tempo entre a concepo do software e sua entrega no mercado. Esse atributo se torna
importante, principalmente, quando a janela de oportunidade pequena devido a produtos
concorrentes.
Como os recursos financeiros para se desenvolver o software so limitados, cada deciso
arquitetural deve ter seu custo e o benefcio proporcionado analisados e, com base nessa
anlise, priorizados ou at mesmo descartados. Essa anlise deve levar em conta o
ambiente de desenvolvimento em questo: capacidades do time de desenvolvimento,
ferramentas disponveis para o reuso e os objetivos do software.
O design de sistemas de grande vida til deve priorizar diferentes atributos de qualidade se
os compararmos com o design de sistemas de vida mais curta, como prottipos. No
primeiro tipo de sistemas, atributos de manutenibilidade e portabilidade so mais
valorizados; no segundo, so priorizados atributos de eficincia e funcionalidade.
O design do software muito dependente de como ele vai ser disponibilizado a pblico. Por
exemplo, se o software ser disponibilizado em fases distintas que englobaro diferentes
conjuntos de funcionalidades, ele deve ser dividido de modo que funcione sem as partes
que ainda no foram disponibilizadas, mas facilite tanto a modificabilidade, facilitando a
adio de novas funcionalidades, quanto interoperabilidade entre diferentes verses. J
se o software ser disponibilizado sem possibilidade de posterior atualizao, como
acontece em muitos sistemas embarcados, preocupaes de modificabilidade e
interoperabilidade entre verses podem ser descartadas.

Informaes sobre atributos de qualidade de negcio podem ser encontradas

nos livros Software Architecture in Practice, de Bass et al, e Beyond Software
Architecture de Hohmann (HOHMANN, 2003).

47

2.3.2.3 Conflitos

Dois ou mais requisitos podem reforar o mesmo atributo de qualidade, caso

isso ocorra, o design da soluo que atenda a um dos requisitos afetar apenas
positivamente o design da soluo que atenda aos outros requisitos. Por outro lado
os requisitos de software podem gerar impacto em um ou mais atributos de
qualidade, relacionados a requisitos diferentes. Quando isso ocorre, o impacto pode
resultar em reforo do atributo ou em conflito.
O principal motivo que faz com que atributos de qualidade conflitem por eles
serem impostos por stackholders diferentes. As preocupaes conflitantes entre
diferentes interessados podem gerar conflitos nos atributos de qualidade. tarefa do
arquiteto resolver, ponderar, ou ao menos mediar esses conflitos, considerando
assim os diversos trade-offs envolvidos para se alcanar os objetivos do software,
atravs da arquitetura.
Resumindo, atributos de qualidade se relacionam de forma que um pode
ajudar ou mesmo dificultar o atendimento de outros, gerando conflitos. Essas
relaes entre atributos acontecem mesmo que eles sejam de tipos diferentes. Por
exemplo, em um sistema de mensagens instantneas com os seguintes requisitos:
(RNF-A): O sistema de check-in deve permitir a autenticao dos usurios.
(RNF-B): Uma passagem vendida por uma agencia no pode ser alterada por
outra.
Observe que os requisitos RNF-A e RNF-B se relacionam, uma vez que
afetam a alguns aspectos de segurana do sistema. Eles se reforam visto que
possvel encontrar uma soluo para RNF-A que facilite RNF-B e vice-versa. A
soluo no caso a utilizao criptografia de chave pblica: tanto ela pode ser
usada para autenticao de usurios quanto pode ser usada para encriptao de
mensagens.
Por outro lado, requisitos conflitantes so mais comuns e adicionam
dificuldade durante o design das solues. Isso ocorre porque a soluo para um
requisito conflitante afeta negativamente outro requisito. Assim, o design do software

48

ter que considerar diversos trade-offs a fim satisfazer melhor aos requisitos mais
importantes, j que atender a todos de forma tima no possvel.
Adicionando alguns requisitos de usabilidade ao sistema de envio de
mensagem esses novos requisitos certamente afetaro negativamente soluo
apresentada. Isso ocorre porque comum que solues de segurana afetem aos
requisitos de usabilidade, visto que essas solues adicionam conceitos no
familiares aos usurios (por exemplo, chaves criptogrficas) ou adicionam mais
passos para que os usurios realizem suas tarefas (por exemplo, inserir login e
senha)
Outro exemplo de conflito: o atributo de qualidade desempenho pode afetar
os nveis de testabilidade e entendimento do sistema (usabilidade).

Cenrio: (Desempenho X Testabilidade)

Uma forma de melhorar o desempenho do sistema diminuir os nveis de
indireo usados na comunicao entre dois elementos. Uma maneira simples
fazer com que algumas chamadas presentes na camada de apresentao
usassem diretamente a camada de persistncia, sem usar a regra de negcio.
Desta forma as chamadas da apresentao ficam mais rpidas, uma vez que
menos chamadas remotas seriam executadas. No entanto, quando diminui a
camada de abstrao entre dois elementos inicialmente distintos, aumenta o
acoplamento entre eles e, portanto, dificulta o entendimento ou mesmo a
testabilidade.

Como outro exemplo observe que o atributo de segurana afeta dois atributos
distintos: o desempenho e a usabilidade do sistema.

49

Cenrio: (Segurana X Desempenho)

Uma forma de aumentar a segurana de um sistema operacional requerer
autorizao do usurio para a realizao de certas operaes. No entanto, o
processo de verificao do usurio (alm de todos os elementos e abstraes
do sistema relacionado segurana: unidade certificadora, unidade verificadora,
listas de controle de acesso, entre outros.) deteriorar o desempenho da
aplicao, dado que consumir recursos que poderiam ser destinados
operao em si - no a um aspecto dito no-funcional dela. Alm disso, o
sistema vai ficar menos usvel, uma vez que pedir uma verificao, seja
senha, impresso digital, ou certificado, para cada operao sensvel a ser
executada.

Os atributos de desempenho e portabilidade tambm podem ser conflitantes

observe o seguinte cenrio:

Cenrio: (Desempenho X Portabilidade)

Um cliente de um jogo para celular requisitou que o jogo tivesse um bom
desempenho nos diversos aparelhos disponveis no mercado. No entanto, o
gerente de projeto sugere que o tempo gasto para portar o software de um
aparelho para outro seja mnimo, uma vez que o prazo do projeto em questo
curto. Podemos ento observar dois requisitos conflitantes: desempenho e
portabilidade.
Esse conflito ocorre porque as tcnicas para alcanar ambos os requisitos so
divergentes. Para Alcanar portabilidade, normalmente necessrio o uso de
diversas camadas de abstrao, principalmente de hardware. No entanto, a
adio dessas camadas de abstrao significa uma perda em desempenho, uma
vez que aumentar o nmero de chamadas necessrias para se realizar qualquer
operao. E isso se torna ainda mais significativo no caso dos aparelhos
celulares, que podem ser limitados em termos de recursos computacionais como
processador ou memria. Assim, a arquitetura do sistema ter que ponderar entre
as tcnicas disponveis de modo que atenda em parte cada requisito e, assim,
ambos os interessados fiquem satisfeitos.

Dois outros atributos de qualidade que normalmente conflitam so os

atributos usabilidade e segurana, como veremos no cenrio a seguir. Nesse caso,
ambos os atributos foram requisitados pelo mesmo interessado, o usurio, e, mesmo
assim, se tornaram conflitantes.

50

Cenrio: (Usabilidade X Segurana)

Quando usando um sistema operacional, um mesmo usurio procura atributos de
segurana e usabilidade para suas operaes. Para segurana, ele deseja que suas
operaes no sistema ou seus resultados no sejam afetados por aes de outros
usurios. Esse atributo, que na arquitetura implicar em solues de autenticao,
verificao, listas de permisses, etc., impor que as tarefas realizadas por qualquer
usurio eventualmente tero sua autenticidade e permisso verificadas. Essa
interrupo para realizar as devidas autorizaes deteriora o atendimento do
atributo de usabilidade, uma vez que o usurio ter suas atividades interrompidas
por algo que no gera resultado para ele.

Assim como os interesses de cada stakeholder no so isolados e podem

afetar os de outro por meio dos requisitos no-funcionais, os atributos de qualidade
no surgem isolados no software. Uma deciso arquitetural feita com o objetivo de
alcanar um atributo de qualidade pode ter efeito em outros atributos. Por uma
deciso arquitetural nunca ser isolada no design da arquitetura, o arquiteto deve
sempre entender quais atributos a deciso afeta, seja positivamente ou
negativamente, e fazer as devidas concesses caso ela afete atributos de qualidade
conflitantes. As tcnicas de design arquitetural no afetem cada atributo de software
isoladamente o que leva aos conflitos.

2.3.3 Mtodo de Avaliao de Arquitetura por Trade-off (ATAM)

O ATAM um mtodo de avaliao que estende a anlise de sistemas

permitindo que ela seja repetvel e transacional. Tendo um mtodo estruturado ajuda
a garantir que as questes importantes sobre a arquitetura so levantadas o mais
cedo possvel. Durante os estgios de levantamento de requisitos e projeto podem
ser descobertos problemas que descobertos mais cedo so mais baratos para
resolver. Este mtodo guia os stakholders na observao dos conflitos e para
resoluo destes conflitos na arquitetura de Software.

51

O Quadro 5 apresentada a seguir mostra os passos do ATAM

Quadro 5- Os passos do ATAM.

ETAPAS

DOC

ANALISE

CENARIO
ARQ.

APRESENTAO

1 - APRESENTAR O ATAM

2 - APRESENTAR BUSINESS
DRIVERS

3 - APRESENTAR
ARQUITETURA

RESUTADO

Esclarecer aos
stakeholders

Especialista
apresenta
situao crtica de
negcio
High-level
alinhado com
plano de negcio

4 - IDENTIFICAR
ABORDAGEM
ARQUITETURAL

Solues
diferentes so
destacadas e
discutidas

5 - GERAR RVORE DE
UTILIDADE.

Core business x
requisitos
tcnicos mapa
cenrio

6 ANLISE E ELEMENTOS
ARQUITETURA

Cada cenrio
analisado e
priorizado
Criticidade
Sensibilidade

7 BRAINSTORM PARA
PRIORIZAO DE CENRIOS

Grupo de
stakeholders
Expanso de
cenrios

8 ANALISA SOLUES
ARQUITETURA

Repete item 6

9 FORNECEM
DOCUMENTOS PARA
STAKEHOLDERS

Comunicao

DESCRIO
Neste passo realizada uma reunio onde descrito o
mtodo para os participantes do projeto
(stakeholders), apresentando as expectativas da
avaliao, aprender sobre os as metas de qualidades
principais para o sistema e conhecer junto ao arquiteto
a arquitetura inicial do negcio e os principais cenrios.
Neste passo comea o ATAM propriamente dito. So
reunidos os stakeholders mais importantes do sistema
para facilitar a gerao de idias de cenrios de
usurios, falhas, e antecipar mudanas.
A arquitetura apresentada em detalhes e os cenrios
mais importantes e ilustrativos so traados sobre a
arquitetura, ajudando a entender o sistema e, em
particular, como dados e fluxos so controlados. Os
analistas tentam identificar e sondar as ramificaes
de estilos arquitetnicos aqui.
utilizado um conjunto de padres de qualidade e
questes de atributos especficos para garantir que os
requisitos de qualidade so atendidos pelos cenrios.
Em particular ns observamos se as condies limites
tenham sido consideradas
Os stakeholders votam nos cenrios que acham mais
importantes. Durante esta fase eles podem sugerir
agrupamentos de cenrios. Depois que a votao esta
completa, os avaliadores determinam um ponto de
corte com at 15 cenrios.
Neste passo o arquiteto observa cada atributo de
qualidade estratgico dos cenrios especificados,
mostrando como eles afetam a arquitetura e como a
arquitetura responde a esses atributos (por exemplo,
para atributos como desempenho, segurana e
disponibilidade).
O arquiteto guia a analise mostrando porque a
arquitetura atende a os requisitos do atributo, como
iluminado pelo cenrio de interesse. O analista
constri modelos de cada atributo de qualidade
baseado nas informaes do arquiteto.
Para achar os pontos de conflitos necessrio localizar
todos os elementos arquiteturais importantes onde
existem mltiplos pontos sensitivos.
Esse plano um conjunto de recomendaes para
reestruturar a arquitetura sob a luz dos resultados da
analise. Adicionalmente devem ser levantadas
questes sobre a documentao como: informao
arquitetural, cenrios, informao ambiental, detalhes
de restries e justificativas para os requisitos de
qualidade.

O mtodo dividido em 9 etapas, o primeiro passo introduz o mtodo para os

participantes em duas etapas, que apresentam os objetivos do negcio e as
solues arquiteturais respectivamente.

52

A etapa 4 identifica as principais abordagens de arquitetura responsvel pela

qualidade do sistema.
A etapa 5 cria a rvore utilidade (AU), que refina os direcionamentos de
negcio em metas de qualidade e em cenrios concretos que representem os
objetivos.
As etapas finais identificam a sensibilidade de arquitetura (deciso
arquiteturais chave para um atributo de qualidade especfico) pontos de trade-offs
(decises arquiteturais que envolvem mltiplos atributos de qualidade) e riscos.
(COLQUITT; LEANEY, 2007).

53

3. ROTEIRO PARA AVALIAO DE ARQUITETURA

O processo utilizado para criao do plano de evoluo tem como referncia

o mtodo de avaliao de arquiteturas ATAM. A figura 1 apresenta um esquema
do processo.

Figura 1 - Estrutura do roteiro utilizado na pesquisa

O roteiro inicia com a aplicao dos 9 passos do mtodo de avaliao ATAM.

O resultado gerado ser resumido em um relatrio contendo os novos requisitos de
qualidade, os riscos, no riscos, pontos crticos, pontos de conflitos, monitoramento
e as Decises Arquiteturais que foram levantadas. Estes dados sero analisados
pelos avaliadores e Estratgias sero elaboradas para cada ponto de vista do
modelo de referncia ODP. Desta avaliao ser gerado o Plano de evoluo que
orientaro as aes que devem ser executadas pelos envolvidos em cada ponto de
vista.

Nas sees seguintes so apresentadas as atividades executada em cada passo

com base no mtodo de referncia.

3.1

Avaliao do sistema atravs do ATAM

O mtodo de avaliao ATAM possui 9 passos bem definidos. O processo

utilizado neste trabalho toma como base os 9 passos realizando adaptaes nas

54

atividades executadas em cada passo no sentido de observar as leis de evoluo do

software. Os passos foram agrupados nas fases relacionadas a seguir:
3.1.1 FASE I Apresentao

A apresentao envolve a troca de informao entre os participantes. O objetivo

que os envolvidos conheam e entendam sobre o mtodo usado para avaliao e
a equipe de avaliadores conhea a arquitetura do sistema avaliado. Esta fase
composta pelos passos 1, 2 e 3 detalhados a seguir.

3.1.1.1

Passo 1 Apresentar o ATAM

O lder da avaliao descreve o mtodo da avaliao para os participantes

(CLEMENTS; KAZMAN; KLEIN, 2009). A figura 2 resume os artefatos utilizados
neste passo, as atividades desenvolvidas e as sadas. Este passo tem como objetivo
esclarecer o processo aos envolvidos, que pode ser feito por memorandos, reunies
ou conferncias. Como sada devem ser registradas evidncias da realizao das
atividades.

Figura 2: Esquema para apresentao do ATAM (Passo 1).

55

No caso de impossibilidades na reunio do stakholders deve ser preparado

um documento explicando o processo , os envolvidos e o papel de cada envolvidos
e deve ser enviado aos participantes.

3.1.1.2

Passo 2 Apresentar os objetivos de negcio

O representante do projeto descreve quais so os objetivos de negcio que

motivam os esforos da equipe, o que resultam nas caractersticas de qualidade de
interesse do sistema (CLEMENTS; KAZMAN; KLEIN, 2009). A figura 3 resume os
artefatos utilizados neste passo, as atividades desenvolvidas e as sadas. So
apresentadas as documentaes do sistema e suas principais caractersticas e
restries. As sadas sero necessrias para o desenvolvimento dos prximos
passos.

Figura 3: Esquema para apresentar os objetivos do negcio (Passo 2).

Como sada importante destacar os objetivos de negcios atravs de

cenrios que representem os objetivos do cliente.

56

3.1.1.3

Passo 3 Apresentao da arquitetura

O arquiteto descreve a arquitetura do sistema dando nfase a como atendem

aos objetivos de negcio requeridos (CLEMENTS; KAZMAN; KLEIN, 2009). A figura
4 resume os artefatos utilizados neste passo, as atividades desenvolvidas e as
sadas. So necessrios para a execuo destas atividades: o escopo do sistema, a
lista de objetivos de negcios e de atributos de qualidade. O resultado deste passo
uma documentao mais completa da arquitetura do sistema. Estendendo o mtodo
original este roteiro propes que a documentao seja organizada de acordo com as
vises ODP com o objetivo de facilitar posteriormente as aes corretivas e
evolutivas para reestruturao da arquitetura.

Figura 4: Esquema para apresentar a arquitetura (Passo 3).

Nesta fase sugerido que sejam tiradas todas as dvidas em relao a arquitetura
atual do sistema.
3.1.2 FASE 2 Investigao e Anlise

Composta pelos passos 4, 5 e 6 envolve um estudo da arquitetura e das

necessidades. A seguir so detalhados os passos.
3.1.2.1 Passo 4 Identificando mtodos arquiteturais

57

Neste passo so extrados os elementos (mtodos e estilos) arquiteturais

existentes na estrutura arquitetural atual pelo time de avaliadores, mas eles no so
analisados (CLEMENTS; KAZMAN; KLEIN, 2009). O objetivo a verificao da
cobertura dos cenrios. A figura 5 resume os artefatos utilizados neste passo, as
atividades desenvolvidas e as sadas. O resultado deste passo uma
documentao dos mtodos e estilos encontrados.

Figura 5: Esquema para identificar mtodos arquiteturais (Passo 4).

3.1.2.2 Passo 5 Gerar a rvore de utilidade

Nesta aplicao o passo 5 concentra na gerao da AU a partir dos cenrios

apresentados no passo 3. Os atributos de qualidade so extrados dos cenrios
especificados anteriormente. O detalhamento dos cenrios com a identificao dos
estmulos e respostas, agrupamentos e priorizaes sugeridos em (CLEMENTS;
KAZMAN; KLEIN, 2009) ficam para os prximos passos.
Os requisitos identificados no passo 3 devem ser classificados em uma AU
onde so definidos os atributos de qualidades requeridos. importante nesta fase

58

que os cenrios sejam detalhados com informaes complementares que permitam

uma aferio e verificao do que estava sendo requerido.
A Figura 6 resume os artefatos utilizados neste passo, as atividades
desenvolvidas e as sadas. Caso a equipe de arquitetos tenha uma rvore de
utilidade primria ela dever constar como entrada. Isso acontece em equipes que j
trabalham com o mtodo. O resultado deste passo uma documentao da rvore
de utilidade elaborada pelos avaliadores.

Figura 6: Esquema para Gerar rvore de Utilidade (Passo 5).

3.1.2.3 Passo 6 Anlise dos mtodos arquiteturais

Assim como no passo anterior a execuo do trabalho dever levar em

considerao todos os cenrios (requisitos) levantados. Neste passo dever ser
realizada uma anlise das abordagens existentes na arquitetura em relao aos
cenrios elicitados no passo 3, informando quais cenrios so atendidos
parcialmente, totalmente ou no so atendidos. A Figura 7 resume os artefatos
utilizados neste passo, as atividades desenvolvidas e as sadas.

59

Figura 7: Esquema para anlise dos mtodos arquiteturais (Passo 6)

3.1.3 FASE 3 Teste

Composta pelos passos 7 e 8, esta fase envolve um estudo da arquitetura e das

necessidades. A seguir so detalhados os passos.

3.1.3.1 Passo 7 Brainstorm e priorizao de cenrios

O passo 7 rene as atividades de maior importncia dentro do processo.

Sugere-se que um brainstorm seja realizado com todos os stakholders em busca de
cenrios adicionais. Em seguida dever ser realizada, a partir da AU, uma anlise
dos mecanismos arquiteturais

que pode ser representado atravs de um mapa

tendo como objetivo visualizar os cenrios semelhantes ou conflitantes. Aqueles

que forem semelhantes podem gerar um agrupamento. Este agrupamento ir reduzir
a rvore de utilidade. A atividade seguinte a priorizao dos cenrios que deve ser
feito atravs de votao.
Na priorizao os principais cenrios de um sistema so categorizados de
acordo com os atributos de qualidade a que esto relacionados e ento classificados
em funo de sua importncia e complexidade, considerando a percepo de

60

negcio e arquitetura. As duas variveis de priorizao podem ser classificadas em

alta (A), mdias (M) e baixas (A) de acordo com as caractersticas dos requisitos.
Entre os cenrios de alta prioridade podem aparecer conflitos que exigiro uma
tomada de deciso por parte dos interessados. A Figura 8 resume os artefatos
utilizados neste passo, as atividades desenvolvidas e as sadas. Nesta aplicao a
lista de riscos tratada nos passos posteriores.

Figura 8: Esquema para realizar o brainstorm e priorizao de cenrios (Passo 7).

3.1.3.2 Passo 8 Anlise dos mtodos arquiteturais

Este passo reitera as atividades do passo 6 e usa os cenrios prioritrios do

passo 7.
A

anlise

arquitetural

formulada

atravs

de

um

template

(CLEMENTS,2003), onde so descritos o estmulo, resposta e abordagem

arquitetural existente e ser realizada para cada cenrio de alta prioridade definidos
no passo.
Neste passo, os mecanismos so analisados segundo o seguinte mtodo
(CLEMENTE, 2003): atributos de qualidade so realizados por tticas arquiteturais
que direcionam os mecanismos de arquitetura.

61

3.1.4 FASE 4 Entrega

3.1.4.1 Passo 9 Consolidar os resultados

Baseados nos resultados so elaborados relatrios que so apresentados aos

envolvidos. Todas as informaes coletadas, as anlises e as decises so
documentadas e entregues.
Com base nas informaes coletadas durante a avaliao so apresentados
os resultados aos envolvidos. Informaes como analise arquitetural dos cenrios
prioritrios, pontos sensitivos e trade-offs

so consolidados em um documento.

Os artefatos resultantes do processo de avaliao atravs do ATAM so

adequados para pautar a estratgia da evoluo do software.

Conjunto de Requisitos de Qualidade;

Conjunto de Riscos e no riscos;

Conjunto de Pontos sensitivos e crticos;

Pontos de Conflitos;

Plano de Monitoramento de Riscos

Com base nas informaes coletadas durante a avaliao so apresentados

os resultados aos envolvidos. Informaes como analise arquitetural dos cenrios
prioritrios,

pontos sensitivos e trade-offs

so consolidados

em um nico

documento que ir pautar a estratgia da evoluo do software.

Observando os cenrios prioritrios que se destacaram no processo os
avaliadores determinam a linha de ao. Vo destacar os pontos sensitivos e os
Trade-offs.
Cada risco, no-risco, ponto sensitivo, trade-off identificados esta associado
com o alcance de um ou mais refinamento do atributo de qualidade na rvore de
utilidade. Os riscos e no riscos devem constar no plano de monitoramento dos
riscos.

62

3.2 Especificar o plano de evoluo para o Sistema

De posse dos resultados da avaliao realizada uma anlise dos resultados

no sentido de elaborar o plano de evoluo. Todos os resultados citados a seguir
so referncias para o plano de evoluo.

Conjunto de Requisitos de Qualidade

Conjunto de Riscos e no riscos

Conjunto de Pontos sensitivos e crticos

Pontos de conflitos

Plano de Monitoramento de Riscos

Os avaliadores iro analisar cada requisito e as tticas resultantes do

processo iro direcionar as aes que devem ser tomadas para evoluo do
software de acordo com os requisitos colocados como meta. Os trade-offs iro
indicar quais as perdas e ganhos entre as tticas conflitantes. E por fim os riscos
apontam os fatores e variveis que devem ser observados, monitorados e
controlados durante o processo de evoluo. Este conjunto de resultados forma as
decises arquiteturais que sero analisadas com o objetivo de traar as diretivas
para evoluo de cada ponto de vista ODP de acordo com o seu nvel de abstrao.
Desta forma o arquiteto e sua equipe podero elaborar um planejamento estratgico
para o desenvolvimento da nova verso do produto direcionado a partir dos pontos
de vista ODP ,que so:

Ponto de Vista de Empresa

Ponto de Vista Tecnologia

Ponto de vista de Informao

Ponto de Vista de Engenharia

Ponto de Vista de Computao

63

Estas informaes iro compor a estratgia da empresa na elaborao do

plano para evoluo do software.
O documento final do resultado da avaliao ser a base para a
estratgia da evoluo a ser adotada pela empresa. Este documento identifica
pontos crticos na arquitetura do sistema que devero ser trabalhados para atender
as exigncias do mercado garantindo a sua estabilidade e sobrevivncia.

64

4. APLICAO DO ROTEIRO: UM EXEMPLO DE AVALIAO

4.1. Contextualizao

Neste captulo ser apresentado um exemplo de aplicao do mtodo de

avaliao de arquitetura de software ATAM em um ambiente real de um sistema
para aviao com o objetivo de gerar um plano de evoluo para assegurar a
longevidade do sistema no mercado. Algumas informaes foram alteradas para
proteger a identidade e a propriedade intelectual do produto e dos envolvidos.
O sistema avaliado tem como contexto a Gesto de Companhias Areas,
consiste em um sistema integrado para gesto de linhas reas que contempla todos
os setores da companhia. A empresa responsvel por manter, comercializar e
desenvolver o produto ser chamada de Empresa E e os clientes da empresa E
sero referenciados por Clientes de E.
O sistema atualmente utilizado por 7 empresas entre linhas areas e taxi
areo. O sistema j possui 8 anos de existncia e os proprietrios querem realizar
uma evoluo planejada e controlada. Para este estudou os esforos foram
concentrados no mdulo de Controle Tcnico e Manuteno.
O objetivo da avaliao gerar informao que possa guiar o lanamento de
uma nova verso do software que atenda as necessidades estratgicas das
gerencias e dos atuais clientes no sentido de alcanar a continuidade do software no
mercado atual e futuro.
Os participantes da avaliao e do planejamento de evoluo so:
- Arquiteto da Empresa E: um dos principais desenvolvedores do produto
tendo participado do projeto de desenvolvimento desde seu incio como estagirio
de programao e atualmente e gerente de projeto. Fica localizado no escritrio da
matriz em Manaus. Ser referenciado como Arquiteto.
- Scio Diretor da Empresa E: Analista de Sistema com larga experincia na
rea de desenvolvimento. Responsvel por toda a anlise do sistema desde o incio.

65

Experiente em consultoria para empresas de aviao e conhecedor do negcio, est

muito prximo dos clientes nas implantaes e solicitaes de manutenes. Fica na
filial da empresa no Rio de Janeiro. Ser referenciado como Contratante.
- Clientes de E: Engenheiros e tcnicos das empresas Clientes. Eles so as
principais fontes das necessidades e falhas dos sistemas. Esto sempre solicitando
mudanas, melhorias e inovaes. A maioria est localizada nos estados do Rio de
Janeiro, outros no Exterior e em outros estados. Ser referenciado como Cliente
- Especialista na Avaliao: Pessoa que ir intermediar as interaes e
realizar a avaliao. Estar localizada na Matriz em Manaus. Ser referenciado
como Avaliador.

4.2. Execuo da Avaliao

De acordo com as fases do ATAM descritas em (CLEMENTS, 2002) a

avaliao tem incio com uma reunio entre o lder do time de avaliadores com as
pessoas chave do cliente e o arquiteto do cliente. O passo seguinte consiste em
identificar os objetivos de Negcio. Dentro deste propsito foram identificadas duas
fontes de requisitos baseadas nas expectativas dos clientes de E e do scio diretor.
Era de suma importncia abordar esses dois conjuntos de stakeholders, pois os
clientes possuem informaes acerca das deficincias do sistema e o Scio possui
uma viso estratgica do mercado.
As atividades destes passos tiveram como resultados os cenrios descritos
no Quadro 6 e 7. O Quadro 6 apresenta os cenrios colocados pelos clientes e so
referenciados por Cenrios de Usurios por tratar dos requisitos dos usurios do
sistema.
Quadro 6- Cenrios de Usurio
U01: O sistema deve permitir o rastreamento da execuo da manuteno
U02: As transaes do sistema de manuteno no podem ser executadas no tempo maior que 5 segundos
U03: Ao ocorrer uma falha o sistema deve ser capaz de reconhec-la
U04: O sistema deve ser intuitivo e de fcil aprendizagem.
U05: O sistema deve permitir a insero de novas funes de forma rpida e barata
U06: O sistema deve se manter estvel durante o registro das manutenes
U07: Garantir a integridade do numero de horas e ciclos voados durante a insero do relatrio de vo, atravs de uma verificao

66

Neste quadro os cenrios falam da deficincia do sistema na sua operao,

como o U02 que trata do tempo das transaes do sistema de manuteno. Devido
experincia dos envolvidos, alguns requisitos no esto tecnicamente completos.
Nos passos seguintes eles sero trabalhados para tratarem a real necessidade dos
clientes.
O quadro 7 apresenta um conjunto de cenrios que esto relacionados com
atributos de negcio, para distinguir dos cenrios anteriores, esses so tratados por
Cenrios de Negcios.
Quadro 7 - Cenrios de Negcio
N01: O sistema tem que permitir o desenvolvimento de mdulos independentes por equipes geograficamente distantes.
Sem que perda qualidade de produto e da execuo do processo.
N02: O sistema dever ser executado por qualquer browser sem precisar de instalaes
N03: O sistema dever permitir testar as funes correlatas a uma que foi modificada.
N04: Outros produtos devem ser construdos de forma que se integrem com este produto
N05: A integrao de subsistemas deve ser completa de forma rpida.
N06: O sistema deve ser de fcil instalao
N07: O sistema deve ser portado para uma nova linguagem de forma automtica sem necessitar de programao adicional
ou replicao de cdigo.
N08: Novas funcionalidades devem ser inseridas de forma rpida e sem gerar efeitos colaterais
N09: O sistema deve possibilitar que novos produtos sejam gerados com reuso de mais de 60% do ncleo.
N10: O sistema deve permitir incremento de plataforma(hardware, banco) sem tirar o sistema do ar.
N11: O sistema deve ser compatvel com as mais diversas plataformas ( Banco de dados, Sistemas operacionais
N12: A nova verso do sistema deve estar no mercado em 3 anos
N13: O sistema deve permitir o desenvolvimento distribudo das funcionalidades evolutivas e manter o processo de
desenvolvimento.
N14: O sistema tem que permitir a comunicao (interao) com outros sistemas.

Neste caso a preocupao esta baseada em requisitos que permitem uma

longevidade do sistema.
O processo de obteno dos cenrios de negcio permitiu que partes
interessadas dessem suas contribuies com os cenrios que refletem seus
interesses e passassem para a equipe de avaliadores a compreenso de como a
arquitetura acomodar suas necessidades. Os cenrios foram coletados sem que
nenhuma desaprovao e quase nenhum esclarecimento fossem fornecidos. Os
cenrios tendem a refletir a nfase particular e os interesses imediatos dos
indivduos, desta forma, uma variedade de cenrios era do interesse particular aos
dois grupos montado (clientes e scio).

67

O Quadro 8 expe a classificao dos cenrios levantados de acordo com os

atributos de qualidade. Esta uma primeira verso da rvore de utilidade, nos
passos a seguir ela ser complementada com outras informaes.
Cumprindo os requisitos do Passo 3 a equipe de desenvolvimento e o
arquiteto do cliente apresentaram a arquitetura atual da ferramenta e uma srie de
documentos da arquitetura do sistema.
De acordo com o padro ODP a documentao apresentada pode ser
classificada como apresenta o Quadro 8:
Quadro 8 - Classificao dos Artefatos da Arquitetura do Software
Viso
Ponto de Vista de Empresa
Ponto de Vista Tecnologia
Ponto de vista de Informao
Ponto de Vista de Engenharia

Ponto de Vista de Computao

Artefato
Caderno de encargos desatualizado
Plataforma e Tecnologias
Modelo Entidade e Relacionamento
Caderno de encargos desatualizado
Esquema de distribuio dos mdulos
Esquema de mdulos ( diviso )
Esquemas de infra-estrutura
Caderno de encargos desatualizado

Como frequente, a documentao inicial apresentada era muito vaga e

documentao arquitetural adicional foi solicitada. Assim, informaes adicionais
foram pedidas, sob a forma de perguntas (Quadro 9), no sentido de esclarecer as
dvidas remanescentes da documentao. Entre o primeiro e o segundo dia da
avaliao o contratante respondeu a muitas destas perguntas e produziu uma
documentao arquitetural mais completa.
Quadro 9 - Informaes adicionais.
Como as funcionalidades so divididas nos termos dos mdulos, das funes, dos APIs, das camadas,
etc.?
Quais so as facilidades existentes na arquitetura de software para o autoteste e o monitoramento de
componentes de software?
Quais facilidades existem na arquitetura de software para a redundncia, monitorao, e como a
consistncia de dados mantida?
Que dependncias funcionais existem entre o software e os componentes?
Quais dados so mantidos na base de dados, qual o tamanho, quanto ele muda?
Qual a frequncia e o volume de dados so transmitidos entre os componentes de sistema?

4.2.1. Passo 4 Identificando mtodos arquiteturais

O mtodo ATAM auxilia na identificao das abordagens e estilos
arquiteturais porque atravs deles possvel entender como a arquitetura
implementa os atributos de qualidades prioritrios.

68

Os mtodos arquiteturais definem a estrutura do sistema e descreve as

maneiras como ela pode crescer, responder as mudanas, se integrar com outros
sistemas assim por diante.
A abordagem arquitetural inclui uma descrio dos tipos de
componentes e sua topologia, uma descrio dos padres de dados e controle
interaes entre os componentes, e uma descrio informal dos benefcios do uso
deste estilo.
Os estilos e as abordagens arquiteturais identificados esto relatados
no Quadro 10:
Quadro 10 - Abordagens arquiteturais identificadas.
Abordagem Arquitetural
O sistema utiliza a tecnologia OO em 2 camadas
O software utiliza um pacote padro para definio de interface.
O sistema prev controle de mudana com mapeamento das alteraes realizadas e componentes afetados.
O sistema utiliza banco de dados relacional com uso de triggers e procedures.
O sistema esta baseado na filosofia cliente/servidor.
O sistema permite acesso simultneo.
O sistema possui mdulo de segurana com controle de acesso e log de operaes.
O sistema possui mecanismo para tolerncia a falhas operacionais e de banco.
Parte do sistema foi desenvolvida atravs de uma metodologia certificada, o que garante a padronizao da
documentao

O Quadro 10 lista as abordagens arquiteturais existentes na arquitetura do

sistema

essas

abordagens

tratam

pontos

arquiteturais importantes,

como

manutenibilidade e segurana, mas no so suficientes para a nova realidade de

requisitos.

4.2.2. Passo 5 Gerar a rvore de utilidade (Agrupamento e Priorizao

dos cenrios)

Nesta aplicao foi definido um mtodo de trabalho com os requisitos

identificados no passo 3, classificando-os em uma rvore de utilidade onde so
definidos os atributos de qualidades requeridos. Nesta fase os requisitos foram
detalhados

com

informaes complementares que permitiam uma aferio e

verificao do que estava sendo requerido. O Quadro 11 apresenta a primeira

verso da rvore de utilidades que classifica os cenrios de acordo com os atributos
de qualidade.

69

Adequao

N1: O sistema deve abranger 100% das funcionalidades da verso

anterior

Preciso

U07: Garantir a integridade do nmero de horas e ciclos voados durante

a insero do relatrio de vo, com verificao atravs de clculos com
porcentagem de acerto de 99,9998% das operaes.

Tolerncia a falhas

U08: O sistema deve ser capaz de proteger os dados de entradas

incorretas atravs de um controle de ocorrncia de falhas
Frmula: (# falhas evitadas / # casos de teste)
Interpretao: 0 x 1; quanto mais prximo de 1, melhor
Entradas: relatrios de teste e de operao

Recuperabilidade,

U03: Ao ocorrer uma falha o sistema deve ser capaz de reconhecer a

falha e recuperar o estado do sistema anterior falha, a partir do
nmero de falhas previstas e evitadas no cdigo
Frmula: (# falhas evitadas / # casos de teste)
Interpretao: 0 x 1; quanto mais prximo de 1, melhor
Entradas: relatrios de teste e de operao

Compreensibilidade

U04: O sistema deve ser intuitivo e de fcil aprendizagem,

os usurios operadores devem ser capaz de operar o sistema com 3
horas de treinamento

Desempenho

U2 As transaes do sistema de manuteno no podem ser executadas

no tempo maior que 5 segs

Analisabilidade

U01: O sistema deve permitir o rastreamento da execuo da

manuteno da aeronave atendendo o prazo de no mximo 15 minutos
aps a solicitao.
N08: Novas funcionalidades devem ser inseridas em no mximo 5 dias e
sem gerar efeitos colaterais

Eficincia

Usabilidade

Confiabilidade

Funcionalidade

Quadro 11 - Classificao dos Cenrios (1 verso da rvore de Utilidade).

Manutenibilidade

Modificabilidade

U05: O sistema deve permitir a insero de novas funes no prazo

mximo de 5 dias.
U06: O sistema deve se manter estvel durante o registro das
manutenes

Portabilidade

Testabilidade

N10: O sistema deve permitir o incremento de plataforma (hardware e

software) sem tirar o sistema do ar.
N03: O sistema dever permitir testar as funes correlatas a uma que
foi modificada no prazo de 1 dia.

Adaptabilidade

N02: O sistema dever ser executado pelos browsers Firefox, internet

explorer, ophera e safari, sem precisar de instalaes.
N11: O sistema deve ser compatvel com os banco de dados: SQL Server,
Oracle, my SQL e com os sistemas operacionais Linux, Windows e Mac
OS

Instalabilidade

N06: O sistema deve ser de fcil instalao com tempo mximo de

instalao de 15 minutos.

Co-existncia

N04: Outros produtos devem ser construdos de forma que se integrem

com este produto
N05: A integrao de subsistemas deve ser completa em no mximo 5
dias.

70

N09: O sistema deve possibilitar que novos produtos sejam gerados

com reuso de mais de 60% do ncleo.

Atributos de Negcio

N07: O sistema deve ser portado para uma nova linguagem de forma
automtica sem necessitar de programao adicional ou replicao de
cdigo.
Time-to-market

Custo e benefcio

N12: A nova verso do sistema deve estar no mercado em 3 anos.

N01: O sistema tem que permitir o desenvolvimento de mdulos
independentes por equipes geograficamente distantes. Sem que perda
qualidade de produto e da execuo do processo.
N13: O sistema deve permitir o desenvolvimento distribudo das
funcionalidades evolutivas e manter o processo de desenvolvimento.

4.2.3. Passo 6 Anlise dos mtodos(abordagem) arquiteturais

A anlise arquitetural formulada para identificar como os requisitos da

rvore de utilidade so atendidos pelos mecanismos da arquitetura, comentados na
coluna Abordagem Arquitetural Existente do quadro 12.

O foco neste momento identificar os mtodos arquiteturais ou

decises que implementam os novos requisitos na arquitetura atual. Para tanto a
equipe de avaliadores analisou as novas as abordagens arquiteturais existentes
levantadas no passo anterior e os novos requisitos para identificar quais destes no
so atendidos ou so atendidos parcialmente. O quadro 12 resume esta tarefa
relacionado em duas colunas os novos requisitos e a abordagem arquitetural
existente. Em alguns casos existem mecanismos que atendem parcialmente ao
requisito, mas precisam de algum ajuste, como por exemplo o tempo de resposta.

71

Quadro 12 - Requisitos x Mecanismos existentes

Novos Requisitos

N1: O sistema deve abranger 100% das

funcionalidades da verso anterior

Abordagem Arquitetural Existente

NO SE APLICA

U07: Garantir a integridade do numero de horas ATENDE PARCIALMENTE:

e ciclos voados durante a insero do relatrio de Atualmente o sistema no implementa as regras
vo, atravs de uma verificao.
de negcios que garantam a integridade das
horas voadas durante a insero dos relatrios de
vos. Mas o sistema utiliza a implementao no
banco que facilita a verificao de regras de
negcios.
U08: O sistema deve ser capaz de proteger os
ATENDE PARCIALMENTE:
dados de entradas incorretas atravs de um
Cerca de 40% das interfaces possuem algum tipo
controle de ocorrncia de falhas.
de verificao para proteo do sistema. No
Frmula: (# falhas evitadas / # casos de
existe um mecanismo automatizado para essa
teste)
verificao
Interpretao: 0 x 1; quanto mais
prximo de 1, melhor
Entradas: relatrios de teste e de
operao
U03: Ao ocorrer uma falha o sistema deve ser
ATENDE:
capaz de reconhecer a falha e recuperar o estado A arquitetura atual prev a ocorrncia de falhas
do sistema anterior falha, a partir do nmero
de banco e de execuo.
de falhas previstas e evitadas no cdigo
Frmula: (# falhas evitadas / # casos de
teste)
Interpretao: 0 x 1; quanto mais
prximo de 1, melhor
Entradas: relatrios de teste e de
operao
U04: O sistema deve ser intuitivo e de fcil
NO ATENDE:
aprendizagem com medida atravs do nmero de A arquitetura atual no possui nenhum
funes evidentes com o propsito de medir a
dispositivo, mecanismo ou estratgia que gere
proporo de funes que so evidentes ao
interfaces intuitivas.
utilizador
Frmula: (# funes evidentes / #
funes)
U2: As transaes do sistema de manuteno no
podem ser executadas no tempo maior que 5
segundos
U01: O sistema deve permitir o rastreamento da
execuo da manuteno da aeronave
atendendo o prazo de no mximo 15 minutos
aps a solicitao.
N08: Novas funcionalidades devem ser inseridas
em no mximo 5 dias e sem gerar efeitos
colaterais

NO ATENDE:
A arquitetura atual no permite este tipo de
controle
ATENDE PARCIALMENTE:
A arquitetura atual armazena log de todas as
operaes realizadas no sistema
ATENDE PARCIALMENTE:
O processo de desenvolvimento adotado agiliza a
insero de novas funcionalidades com controle
das funes afetadas

72

U05: O sistema deve permitir a insero de novas ATENDE PARCIALMENTE:

funes no prazo mximo de 5 dias.
O processo de desenvolvimento adotado agiliza a
insero de novas funcionalidades com controle
das funes afetadas
U06: O sistema deve se manter estvel durante o ATENDE PARCIALMENTE:
registro das manutenes
O processo de desenvolvimento adotado agiliza a
insero de novas funcionalidades com controle
das funes afetadas
N10: O sistema deve permitir o incremento de
ATENDE PARCIALMENTE:
plataforma (hardware e software) sem tirar o
A arquitetura atual esta implementada em
sistema do ar.
plataforma Borland compatvel com o Windows
com banco de dados Oracle
N03: O sistema dever permitir testar as funes ATENDE PARCIALMENTE:
correlatas a uma que foi modificada no prazo de O processo de desenvolvimento adotado agiliza a
1 dia.
insero de novas funcionalidades com controle
das funes afetadas
N02: O sistema dever ser executado pelos
NO ATENDE:
browsers Firefox, internet explorer, ophera e
A arquitetura atual no compatvel com a
safari, sem precisar de instalaes.
plataforma web
N11: O sistema deve ser compatvel com os banco de dados:
SQL Server, Oracle, my SQL e com os sistemas operacionais
Linux, Windows e Mac OS

N04: Outros produtos devem ser construdos de forma que

se integrem com este produto

ATENDE PARCIALMENTE:
A arquitetura atual compatvel com o Windows com banco
de dados Oracle. EM 90% das operaes utiliza SQL PADRO
sendo compatvel com 90% dos banco de dados relacionais
NO ATENDE:
Atualmente o sistema leva cerca de 30 minutos para ser
instalado em uma operao complexa.
NO ATENDE:
Toda integrao realizada de forma manual.

N05: A integrao de subsistemas deve ser completa em no

mximo 5 dias.

NO ATENDE:
A Integrao manual cara e demorada

N09: O sistema deve possibilitar que novos produtos sejam

gerados com reuso de mais de 60% do ncleo.

ATENDE PARCIALMENTE:
O sistema possui uma poltica de reutilizao de classes mas
de forma desorganizada o que pode comprometer a
integridade do sistema
NO ATENDE:
A arquitetura atual no esta preparada para este requisito

N06: O sistema deve ser de fcil instalao com tempo

mximo de instalao de 15 minutos.

N07: O sistema deve ser portado para uma nova linguagem

de forma automtica sem necessitar de programao
adicional ou replicao de cdigo.
N12: A nova verso do sistema deve estar no mercado em 3
anos.
N01: O sistema tem que permitir o desenvolvimento de
mdulos independentes por equipes geograficamente
distantes. Sem que perda qualidade de produto e da
execuo do processo.
N13: O sistema deve permitir o desenvolvimento distribudo
das funcionalidades evolutivas e manter o processo de
desenvolvimento.

NO ATENDE:
Com a arquitetural atual ser muito difcil atender a este
prazo
ATENDE PARCIALMENTE:
O processo de desenvolvimento da empresa auxilia no
cumprimento deste requisito
ATENDE PARCIALMENTE:
O processo de desenvolvimento da empresa auxilia no
cumprimento deste requisito

73

4.2.4. Passo 7 Brainstorm e priorizao de cenrios

Alm dos cenrios apresentados na rvore de utilidade, o processo de

elicitao de cenrio no Passo 7 permite que o grupo maior de interessados em
contribuir com cenrios adicionais possa entender como a arquitetura ir acomodar
suas preocupaes. Os cenrios que aparecem na rvore de utilidade so
desenvolvidos de cima para baixo, os cenrios gerados por um grupo maior de
interessados so desenvolvidos de baixo para cima. A combinao de abordagens
oferece alguma garantia de que os cenrios de alta prioridade vieram tona. Um
cenrio em particular pode, de fato, ter implicaes em muitas partes: uma das
partes interessadas pode estar preocupada com a dificuldade de uma mudana e
seu impacto no desempenho, enquanto outra parte pode estar interessada em como
a mudana afetar a "integrabilidade" da arquitetura.
Neste exemplo de aplicao no foi necessrio fazer um novo levantamento
de cenrios. Entretanto foi necessrio realizar um agrupamento de cenrios e a
priorizao.
De posse da rvore de utilidade foi produzido um mtodo para capturar os
cenrios semelhantes atravs de uma matriz identificada por Mapa de Cenrios
apresentado no Quadro 13. O objetivo deste mapa visualizar a princpio os
cenrios semelhantes, facilitando um possvel agrupamento.
Avaliando as semelhanas entre os cenrios e identificando atravs do sinal
de semelhana na posio linha e coluna dos respectivos cenrios, foi possvel
observar que era possvel realizar alguns agrupamentos. O Quadro 14 apresenta os
agrupamentos realizados.
Uma vez reduzidos os cenrios possvel finalizar a rvore de utilidade
definindo a priorizao dos cenrios. Desta forma os cenrios mais importantes
sero tratados dentro do perodo limitado para avaliao.

74

CONFIAB./MANUT.

U1

EFICIENCIA

U2

CONFIABILIDADE

U3

USABILIDADE

U4

MANUTENIBILIDADE

U5

MANUTENIBILIDADE

U6

FUNCIONALIDADE

U7

CONFIABILIDADE

U8

FUNC./ATRIB.NEGOCIO

N1

FUNC./PORTABILIDADE

N2

MANUTENIBILIDADE

N3

PORTABILIDADE

N4

PORTABILIDADE

N5

PORTABILIDADE

N6

FUNC./ATRIB.NEGOCIO

N7

MANUTENIBILIDADE

N8

PORTABILIDADE

N9

MANUTENIBILIDADE

N10

PORTABILIDADE

N11

ATRIB.NEGOCIO

N12

ATRIB.NEGOCIO

N13

FUNCIONALIDADE

N14

CONFIAB. MANUT

EFICIENCIA

CONFIABILIDADE

USABILIDADE

MANUTENIBILIDADE

MANUTENIBILIDADE

FUNCIONALIDADE

CONFIABILIDADE

FUNC./ATRIB.NEGOCIO

FUNC./PORTABILIDADE

MANUENIBILIDADE

PORTABILIDADE

PORTABILIDADE

PORTABILIDADE

FUNC./ATRIB.NEGOCIO

MANUTENIBILIDADE

PORTABILIDADE

MANUTENIBILIDADE

PORTABILIDADE

ATRIB.NEGOCIO

ATRIB.NEGOCIO

FUNCIONALIDADE

Quadro 13 - Anlise dos mecanismos arquiteturais()

U1

U2

U3

U4

U5

U6

U7

U8

N1

N2

N3

N4

N5

N6

N7

N8

N9

N10

N11

N12

N13

N14

Quadro 14 - Agrupamento dos cenrios semelhantes.

AG1

AG2

N3 N08
N3 U05
logo
n3 n08 u05
N04 N09

AG3

N01 N13

AG4

N02 N06

AG5

U03 U08

O sistema deve permitir a insero ou modificao de funcionalidades de forma

rpida barata e sem gerar efeitos colaterais permitindo testes das funes correlatas
no prazo mximo de 1 dia.
Outros produtos devem ser construdos de forma que se integrem com este produto
e com reuso de mais de 60% do ncleo.
O sistema tem que permitir o desenvolvimento de mdulos independentes por
equipes geograficamente distantes. Sem que perda qualidade de produto e da
execuo do processo mantendo o processo de desenvolvimento.
O sistema dever ser executado pelos browsers Firefox, internet explorer, ophera e
safari, sem precisar de instalaes sem precisar de instalaes.
Ao ocorrer uma falha o sistema deve ser capaz de reconhec-la e de proteger os
dados de em caso de entradas incorretas, atravs de um controle de ocorrncia de
falhas.
Frmula: (# falhas evitadas / # casos de teste)
Interpretao: 0 x 1; quanto mais prximo de 1, melhor
Entradas: relatrios de teste e de operao

75

Na priorizao os principais cenrios de um sistema so categorizados de

acordo com os atributos de qualidade a que esto relacionados e ento classificados
em funo de sua importncia e complexidade, considerando a percepo de
negcio e arquitetura (Quadro 15). As duas variveis de priorizao Importncia e
Complexidade, apresentadas nas colunas IMP. e COM. respectivamente foram
classificadas em alta (A), mdias (M) e baixas (A) de acordo com as caractersticas
dos requisitos.
Quadro 15 - rvore de utilidade reduzida e com prioridades.
Atributos de Qualidade

Eficincia Usabilidade Funcionalidade

Adequao
Preciso
Recuperabilidade,

Compreensibilidade

COM.

N1: O sistema deve abranger 100% das funcionalidades da verso anterior

U07: Garantir a integridade do numero de horas e ciclos voados durante a
insero do relatrio de vo, atravs de uma verificao.
AG5: Ao ocorrer uma falha o sistema deve ser capaz de reconhec-la e de
proteger os dados de em caso de entradas incorretas, atravs de um
controle de ocorrncia de falhas.
Frmula: (# falhas evitadas / # casos de teste)
Interpretao: 0 x 1; quanto mais prximo de 1, melhor
Entradas: relatrios de teste e de operao
U04: O sistema deve ser intuitivo e de fcil aprendizagem com medida
atravs do nmero de funes evidentes com o propsito de medir a
proporo de funes que so evidentes ao utilizador
Frmula: (# funes evidentes / # funes)
U2 As transaes do sistema de manuteno no podem ser executadas no
tempo maior que 5 segs
A

Manutenibilidade

Modificabilidade

Adaptabilidade

Portabilidade

IMP.

Desempenho

Analisabilidade

Co-existncia

U01: O sistema deve permitir o rastreamento da execuo da manuteno

da aeronave atendendo o prazo de no mximo 15 minutos aps a
solicitao.
AG1: O sistema deve permitir a insero ou modificao de funcionalidades
no prazo mximo de 5 dias e sem gerar efeitos colaterais permitindo testes
das funes correlatas no prazo mximo de 1 dia
U06: O sistema deve se manter estvel durante o registro das
manutenes
N10: O sistema deve permitir o incremento de plataforma (hardware e
software) sem tirar o sistema do ar.

AG4: O sistema dever ser executado pelos browsers Firefox, internet

explorer, ophera e safari, sem precisar de instalaes sem precisar de
instalaes
N11: O sistema deve ser compatvel com os bancos de dados: SQL Server,
Oracle, MY SQL e com os sistemas operacionais Linux, Windows e Mac OS.

N07: O sistema deve ser portado para uma nova linguagem de forma
automtica sem necessitar de programao adicional ou replicao de
cdigo.
AG2: Outros produtos devem ser construdos de forma que se integrem
com este produto e com reuso de mais de 60% do ncleo

N05: A integrao de subsistemas deve ser completa em no mximo 5 dias.

Time-to-market

Atributos de
Negcio

Cenrios

N12: A nova verso do sistema deve estar no mercado em 3 anos.

AG3: O sistema tem que permitir o desenvolvimento de mdulos

independentes por equipes geograficamente distantes. Sem que perda
qualidade de produto e da execuo do processo mantendo o processo de
desenvolvimento.

76

4.2.5. Passo 8 Anlise dos mecanismos arquiteturais

A anlise arquitetural formulada atravs de um template (CLEMENTS),

onde so descritos o estmulo, resposta e abordagem arquitetural existente e ser
realizada para cada cenrio de alta prioridade definidos no passo anterior e
apresentados no Quadro 10.
Neste passo, os mecanismos so analisados segundo o seguinte mtodo
(CLEMENTE, 2003): atributos de qualidade so realizados por tticas arquiteturais
que direcionam os mecanismos de arquitetura.
Os cenrios envolvidos dizem respeitos aos atributos de qualidade: eficincia,
manutenibilidade, funcionalidade/atributo de negocio, confiabilidade e portabilidade.
Os quadros 16

a 20 detalham a anlise arquitetural de cada cenrio

prioritrio. Neste detalhamento possvel observar o ambiente, o estmulo, a

resposta e abordagem arquitetural existente para atender o requisito. Nesta fase
inclumos tambm o levantamento dos riscos envolvidos em cada cenrio e as
sugestes em relao ao monitoramento destes riscos.
O quadro 16 apresenta a anlise arquitetural do Cenrio AG1, onde a
preocupao do usurio est no prazo, no custo e no efeito colateral das
modificaes. O processo de desenvolvimento adotado, agiliza a insero de novas
funcionalidades e garante a integridade das funes correlatas que foi alterada ou
modificada. Entretanto o processo de teste e verificao pode comprometer a
velocidade de entrega das solicitaes.
Trs estratgias arquiteturais so indicadas para alcanar a modificabilidade,
ou seja, para controlar quanto ser propagado os efeitos da mudana, so elas
indireo, encapsulamento e separao.
Indireo: Envolve o uso de mediadores para permitir que produtores e
consumidores de dados se comuniquem sem ter um conhecimento direto um do
outro. Somente o mediador conhece a necessidade de dados de cada um.
Consequentemente produtores ou consumidores adicionais podem ser adicionados
sem mudanas para os j existentes.

77

Encapsulamento: similar a indireo; uma interface faz o papel do

mediador, separando os detalhes de implementao.
Separao: isola os aspectos ortogonais de uma arquitetura para outra. Por
exemplo, separando dados a partir de vises de dados, a criao de novas vises
pode ser independente de outras vises existentes. Separando comandos de dados
permite que novos comandos sejam adicionados sem afetar os comandos
existentes.
Uma deciso importante incide em alterar o processo para simplificar os
testes ou diminuir a coeso das funcionalidades relacionadas ou seja manter baixo
acoplamento e Alta coeso do software.
Quadro 16 - Anlise Arquitetural Cenrio AG1.
Anlise Arquitetural
Cenrio: AG1

O sistema deve permitir a insero ou modificao de funcionalidades de forma rpida barata e

sem gerar efeitos colaterais permitindo testes das funes correlatas no prazo mximo de 1 dia.

Atributo

MANUTENIBILIDADE

Ambiente

Operao normal

Estimulo
Resposta

Solicitao de nova funcionalidade pelo cliente

Tempo e custo de desenvolvimento da funcionalidade

Abordagem
Arquitetural Existente
Riscos

O processo de desenvolvimento adotado agiliza a insero de novas funcionalidades com

controle das funes afetadas
M definio da alterao do requisito

Monitoramento dos
Riscos
Tticas Sugeridas

Fazer validao da alterao do requisito.

Encapsulamento
DA 1.1 Padronizao de interface atravs de template
DA1.2.Criar componentes/classes para desenvolver interface padro
Separao:
DA.1.3.Modelagem da base de dados flexvel atravs de normalizao
DA.1.6.Manter Baixo acoplamento
DA.1.7.Manter Alta coeso do software
DA.1.4.Realizar e manter a documentao do sistema
DA.1.5.Manter check list de teste dos componentes utilizados ou novos
D.A.1.8.Executar teste e homologao da nova funcionalidade
D.A.1.9.Realizar controle de verso

O quadro 17 apresenta a anlise arquitetural do cenrio AG5 onde, a partir da

entrada de dados. Ao ocorrer uma falha o sistema deve ser capaz de reconhec-la e
de proteger os dados em caso de entradas incorretas, atravs de um controle de
ocorrncia de falhas com coeficiente de falhas evitadas / casos de teste prximo de
1. Cerca de 40% das interfaces atuais possuem algum tipo de verificao para

78

proteo do sistema e a arquitetura atual prev a ocorrncia de falhas de banco e de

execuo Porm no existe um mecanismo automatizado para essa verificao.

Quadro 17 - Anlise Arquitetural Cenrio AG5.

Atributo
Ambiente

Anlise Arquitetural
Ao ocorrer uma falha o sistema deve ser capaz de reconhec-la e de proteger os dados em caso de
entradas incorretas, atravs de um controle de ocorrncia de falhas.
Frmula: (# falhas evitadas / # casos de teste)
Interpretao: 0 x 1; quanto mais prximo de 1, melhor
Entradas: relatrios de teste e de operao
CONFIABILIDADE
Operao Normal

Estimulo

Entrada de dados

Resposta

Telas de resposta ao usurio impossibilitando a entrada de dados

Abordagem
Arquitetural
Existente

Cerca de 40% das interfaces possuem algum tipo de verificao para proteo do sistema. No
existe um mecanismo automatizado para essa verificao

Cenrio: AG5

A arquitetura atual prev a ocorrncia de falhas de banco e de execuo

Ameaa de vrus

Riscos
Monitoramento dos
Riscos
Tticas Sugeridas

Antivirus
DA.2.1. Controle e tratamento de falhas ( banco, cdigo, entrada de dados).

O processo de desenvolvimento adotado possui uma estrutura de testes

eficiente que pode ser trabalhada para controlar a incidncia de falhas previstas e
evitadas. Como deciso arquitetural possvel propor rotina de teste especfica para
as entradas e ainda criar um mecanismo para criao de rotinas de verificao.
O quadro 18 trata da anlise arquitetural do Cenrio U02. Neste caso a
arquitetural atual no garante que as transaes do sistema de manuteno sejam
executadas no tempo maior que 5 segundos, pois no existe nenhuma aferio do
tempo necessrio para execuo das rotinas de manuteno das aeronaves. Como
deciso necessrio executar a aferio do tempo gasto, atualmente, para ento
realizar analise no cdigo e das funcionalidades.
Como decises arquiteturais so sugerias trs, como programao no banco
de dados e algumas iniciativas referente implementao das telas do sistema.

79

Quadro 18 - Anlise Arquitetural Cenrio U02.

Cenrio: U02

Anlise Arquitetural
As transaes do sistema de manuteno no podem ser executadas no tempo maior que 5
segundos .

Atributo

EFICINCIA

Ambiente

Operao Normal

Estimulo
Abordagem
Arquitetural
Existente
Riscos

Tempo de resposta das funes do sistema

A arquitetura atual no permite este tipo de controle

Monitoramento dos
Riscos
Tticas Sugeridas

Programar cronograma de ajustes e manuteno dos componentes da infraestrutura como

computadores e rede
DA.3.1. Programao no banco de dados para agilizar o tempo de resposta
DA.3.2. Implementar telas limpas e simplificadas
.
DA.3.3. Carregar apenas informaes necessrias, e conforme forem sendo solicitadas.

Infra estrutura prejudicar o tempo de respostas

O quadro 19 trata da anlise arquitetural do Cenrio N11. A partir do

surgimento de novas demandas quanto a plataforma o sistema deve ser compatvel
com os banco de dados: SQL Server, Oracle, MY SQL e com os sistemas
operacionais Linux, Windows e Mac OS.

A arquitetura atual atende parcialmente a essa demanda pois compatvel

com o Windows e com banco de dados Oracle e 90% dos demais banco de dados
relacionais. Somente 10% das operaes no utilizam SQL PADRO disponveis
em todos os bancos de dados relacionais. Como deciso arquitetural sugere-se que
seja realizada uma traduo das consultas que no esto em SQL Padro para os
bancos de dados citados. No caso dos sistemas operacionais ser necessria uma
anlise mais detalhada das linguagens e tcnicas disponveis para que o sistema
seja compatvel com os sistemas operacionais citados.

80
Quadro 19 - Anlise Arquitetural Cenrio N11.
Analise Arquitetural
Cenrio: N11

N11: O sistema deve ser compatvel com os bancos de dados: SQL Server, Oracle, MY SQL e com
os sistemas operacionais Linux, Windows e Mac OS.

Atributo
Ambiente
Estimulo
Resposta
Abordagem
Arquitetural
Existente
Riscos

PORTABILIDADE
Desenvolvimento
Surgimento de novas demandas quanto a plataforma
No se Aplica
A arquitetura atual compatvel com o Windows com banco de dados Oracle. EM 90% das
operaes utiliza SQL PADRO sendo compatvel com 90% dos bancos de dados relacionais

Monitoramento dos
Riscos
Tticas Sugerida

Monitorar o surgimento de novas tecnologias e estudar melhorias continua da arquitetura atual.

Surgimento de nova tecnologia de Banco de dados

DA.4.1. Utilizar tecnologias populares e robustas como Java.

DA.4.2. Utilizar SQL padro
.
DA.4.3. Utilizar paradigma OO

O quadro 20 trata da anlise arquitetural do Cenrio N12. Para alcanar

novos mercados necessrio que a nova verso do sistema deva estar no mercado
em 3 anos, tempo em que se alcance a execuo satisfatria dos testes do novo
sistema. A arquitetural atual no atende a todos os cenrios analisados e uma
reestruturao da arquitetura ser necessria. Para atender o prazo estipulado ser
necessrio encontrar uma tecnologia gil que atenda principalmente os cenrios
U02 e N11 simultaneamente sem perder de focos os demais cenrios prioritrios.

Quadro 20 - Anlise Arquitetural Cenrio N12.

Cenrio: N12

Anlise Arquitetural
A nova verso do sistema deve estar no mercado em 3 anos

Atributo

ATRIBUTO DE NEGCIO

Ambiente

Desenvolvimento

Estimulo

Novos mercados

Resposta

Execuo satisfatria dos testes do novo sistema

Abordagem
Arquitetural
Existente
Riscos

Com a arquitetural atual ser muito difcil atender a este prazo

Monitoramento dos
Riscos
Tticas Sugeridas

Iniciar a curto prazo o estudo de tecnologias que atenda o cenrio proposto.

No encontrar tecnologia adequada a tempo

DA.5.1. Iniciar pesquisa por linguagens mais adequadas e gerador de cdigo

DA.5.2. Treinamento da equipe
.
DA.5.3. Utilizao do processo certificado.

81

4.2.6. Passo 9 Consolidar resultados

Com base nas informaes coletadas durante a avaliao so
apresentados os resultados aos envolvidos. Informaes como analise arquitetural
dos cenrios prioritrios, pontos sensitivos e trade-offs

so consolidados em um

documento. Os artefatos resultantes do processo de avaliao atravs do ATAM

so adequados para pautar a estratgia da evoluo do software.

Conjunto de Requisitos de Qualidade;

Conjunto de Riscos e no riscos;

Conjunto de Pontos sensitivos e crticos;

Pontos de Conflitos;

Plano de Monitoramento de Riscos.

Observando os cenrios prioritrios destacam-se os requisitos de

qualidades que

dizem respeito eficincia, manutenibilidade, funcionalidade e

atributo de negcio, confiabilidade e portabilidade.

Ponto sensitivo uma propriedade de um ou mais componentes de
atributos de qualidade. Os valores particulares de um ponto sensitivo pode se tornar
um risco quando identificados em uma arquitetura. Dentro do trabalho podem ser
destacados dois pontos sensitivos:

S.1.2. Estratgias de normalizao podem degradar a performance.

S.1.1 O aumento do nmero de componentes pode degradar a

performance .
Outro ponto importante da avaliao a identificao dos Trade-offs.

Um ponto de trade-off uma deciso arquitetural que afeta mais de um atributo e

um ponto sensitivo para mais de um atributo. Levando em considerao todos os
requisitos da rvore de utilidade, foram identificados 13 trade-off dos quais 5 podem
ser considerados pontos sensitivos pois afetam requisitos que foram considerados
com alta prioridade pelos stakeholders. Os 5 trade-offs identificados foram:

82

Eficincia x Confiabilidade: as constantes verificaes de segurana do

sistema e registros de log afetam a agilidade no uso e o tempo de
resposta do sistema.

Manutenibilidade x Confiabilidade: o rastreamento da execuo da

manuteno ir levar a uma demora no teste dos mdulos
inviabilizando a insero rpida de novas funcionalidades.

Funcionalidade e atributo de negcio x Eficincia: a portabilidade do

sistema e a compatibilidade do mesmo com diversas linguagens pode
degradar a performance do sistema devido ao nmero de camadas
necessrias para implementar a portabilidade.

Portabilidade x Eficincia: as inmeras possibilidades que o sistema

dever reconhecer e tratar gera um gasto de tempo na resposta do
sistema.

Manutenibilidade x Portabilidade: as inmeras possibilidades que

devem ser tratadas pelo sistema comprometem a agilidade na insero
de

novas

funcionalidades

aumentando

tempo

custo

de

desenvolvimento.
Cada risco, no-risco,

ponto sensitivo, trade-off identificados esta

associado com o alcance de um ou mais refinamento do atributo de qualidade na

rvore de utilidade. Os riscos e no riscos devem constar no plano de
monitoramento dos riscos.

4.3 Aspectos do Plano de Ao para Evoluo

O foco da avaliao est na evoluo estrutural de um sistema que

atualmente atende as necessidades dos usurios.

O documento final do resultado

da avaliao ser a base para a estratgia da evoluo a ser adotada pela empresa.
Este documento identifica pontos crticos na arquitetura do sistema que devero ser
trabalhados para atender as exigncias do mercado garantindo a sua estabilidade e
sobrevivncia.

83

Neste ponto importante observar e acompanhar as decises

arquiteturais sugeridas nos quadros de

16 a 20.

Somente acatar as decises

arquiteturais resultantes da avaliao no ir resolver as questes da evoluo.

Muitas vezes uma deciso arquitetural afeta o atendimento de outro requisito. Na
maioria das vezes necessrio fazer escolhas entre as decises a serem aceitas.
Quando consideramos a evoluo de software a partir da perspectiva
arquitetural necessrio determinar se uma arquitetura requer mudanas

subseqentemente como executar estas mudanas. Desta forma a avaliao

arquitetural se faz necessria para responder estas perguntas. Em casos de
arquiteturas complexas onde esto envolvidos vrios sistemas e subsistemas ou
uma linha de produto se faz necessria uma anlise mais consistente nas escolhas
utilizadas e nos efeitos que elas provocam nos sistemas envolvidos.
Os artefatos resultantes do processo de avaliao atravs do ATAM
so adequados para pautar a estratgia da evoluo do software. O plano de
evoluo dever ter como base os seguintes itens:

Conjunto de Requisitos de Qualidade;

Conjunto de Riscos e no riscos;

Conjunto de Pontos sensitivos e crticos;

Pontos de Conflitos;

Plano de Monitoramento de Riscos.

As tticas sugeridas direcionam as aes que devem ser tomadas para

evoluo do software de acordo com os requisitos colocados como meta. Os tradeoffs indicam quais as perdas e ganhos entre tticas conflitantes. E por fim os riscos
apontam os fatores e variveis que devem ser observados, monitorados e
controlados durante o processo de evoluo.

Estas decises arquiteturais

so

analisadas com o objetivo de traar as diretivas para evoluo de cada ponto de

vista ODP de acordo com o seu nvel de abstrao. Desta forma o arquiteto e sua
equipe podero elaborar um planejamento estratgico para o desenvolvimento da
nova verso do produto. Estas informaes iro compor a estratgia da empresa na
elaborao do plano para evoluo do software.

84

Quadro 21 - Tticas Sugeridas classificadas de acordo com os pontos de vistas ODP.

Ponto de
Vista
Empresa

Tecnologia

Informao
Engenharia
o
Computao

Ttica Arquitetural
DA.5.3. Utilizao do processo certificado.
DA.5.2. Treinamento da equipe
.
DA.1.5. Manter check list de teste dos componentes utilizados ou novos.
DA.1.8. Executar teste e homologao da nova funcionalidade.
DA.1.9. Realizar controle de verso.
DA.5.1. Iniciar pesquisa por linguagens mais adequadas e gerador de cdigo .
DA.4.1. Utilizar tecnologias populares e robustas como Java.
DA.4.2. Utilizar SQL padro
.
DA.4.3. Utilizar paradigma OO
.
DA.3.1. Programao no banco de dados para agilizar o tempo de resposta.
DA.1.4. Realizar e manter a documentao do sistema.
DA.1.3. Modelagem da base de dados flexvel atravs de normalizao.
DA.1.6. Manter Baixo acoplamento.
DA.1.7. Manter Alta coeso do software.
DA.2.1. Controle e tratamento de falhas ( banco, cdigo, entrada de dados).
DA.1.1. Padronizao de interface atravs de template.
DA.3.2. Implementar telas limpas e simplificadas
.
DA.1.2. Criar componentes/classes para desenvolver interface padro.
DA.3.3. Carregar apenas informaes necessrias, e conforme forem sendo solicitadas.

Dentro do contexto da aplicao exemplo, o quadro 21 mostra as tticas

classificadas de acordo com os pontos de vista ODP. Esta classificao facilitar a
ao das diversas competncias da empresa, cada uma na sua rea especfica. No
exemplo em questo essa diviso facilitou a separao das tarefas e monitoramento
da execuo de cada uma pelos seus responsveis.
Os responsveis pelos pontos de vistas devem traar um plano de ao para
cada ttica sugerida, e acompanhar sua evoluo. Deve ser elaborado um
cronograma que considere como tempo mximo o perodo determinado pelo cenrio
N12 que diz que o lanamento de uma nova verso no deve ultrapassar 3 anos.
A equipe da empresa analisou cada uma das tticas sugeridas e criou um
cronograma de ao de acordo com a ordem de prioridade das atividades. Foram
observadas prioridade e relacionamentos do tipo dependncia entre as tticas.
Nesta aplicao exemplo no surgiram tticas conflitantes, pois os conflitos
foram solucionados em uma etapa anterior. Mas ainda necessria uma fase de
brainstorm e divulgao de decises tomadas a partir das tticas sugeridas.
importante a atuao da gerncia do projeto para acompanhar o
cumprimento das decises tomadas como, por exemplo, acompanhar se os analistas
e programadores esto mantendo a deciso de manter um baixo acoplamento e

85

uma alta coeso ( DA1.7 e 1.6). Ou ainda se esto mantendo a documentao do

sistema atualizada como determina a deciso arquitetural 1.4.
Observe que os envolvidos no ponto de vista de tecnologia devem executar
algumas aes importantes como escolher a linguagem e a tecnologia que deve ser
adotada. Desta deciso depende uma srie de outras.
possvel notar que os envolvidos no ponto de vista de empresa ficam
responsveis pelas aes de gerenciamento.
O desenvolvimento do processo deixou algumas lies importantes no uso do
mtodo ATAM como base para avaliao de arquiteturas, como:
Melhorias de Documentao: No incio da avaliao, a documentao
arquitetural estava incompleta. A avaliao permitiu a atualizao de partes
consideradas importantes melhorando o projeto de arquitetura.
Coleta de Cenrio e foco da avaliao:

O mtodo adotado estimula aos

usurios a definir e manter o foco da avaliao. Isto se mostra muito positivo quando
necessrio resolver conflitos de requisitos. A identificao de pontos sensitivos e
de trade-off d aos stakholders esta possibilidade.
O envolvimento dos stakeholders na coleta de cenrios e definio dos
cenrios prioritrios auxilia no desenvolvimento do projeto diminuindo as possveis
divergncias. A avaliao de mbito muito vasto perderia a sua eficcia, dando
resultados vagos, enquanto um foco muito estreito permite identificar as principais
preocupaes.
Problema descobertos durante todo o ciclo de vida de software:

mtodo de avaliao de cenrios podem ser aplicados durante todo o ciclo de vida
do software.
A vantagem de us-lo no incio das atividades de reestruturao do sistema
ou at no incio do desenvolvimento

a possibilidade de descobrir problemas de

projeto numa fase que ainda possvel tomar as decises adequadas. No entanto,
quando o volume de trabalho feito grande, reverter s alteraes, ou perceber que
a arquitetura no adequada para a evoluo pode ser muito caro.

86

Para reduzir os riscos associados com a evoluo de software, o mtodo de

avaliao baseada em cenrios pode ser usado para melhorar a arquitetura de
sistema durante o ciclo de vida do sistema inteiro.
Melhorias para a famlia de produtos de software:

O processo de

avaliao descrita no especfico para famlias de produtos de software e pode ser

aplicada a qualquer arquitetura de software. No entanto, temos vindo a utilizar o
mtodo para avaliar a famlia de produtos de software arquiteturas e descrevemos
abaixo os principais benefcios e lies que aprendemos.
No contexto de uma arquitetura de software da famlia de produtos, a
avaliao deve\ considerar a evoluo para o conjunto dos produtos da famlia. Nas
avaliaes com base no cenrio de cada etapa do processo so afetados por esta
dimenso.
A fase de seleo de cenrios inclui a anlise dos produtos da famlia e
como os recursos, facultativo ou obrigatrio, so afetados pela avaliao.
exemplo

apresentado,

nfase

foi

colocada

sobre

portabilidade

No
e

manutenibilidade do produto.
O fato de que o arquiteto chefe da famlia de produtos de software
sempre foi includo em nossa lista das partes interessadas garantiu que a avaliao
levasse em considerao no apenas o software especfico componentes, mas
tambm a arquitetura de software da famlia de produtos. Alm disso, durante todo o
processo, a equipe de avaliao tinha de considerar o software do produto na
dimenso da arquitetura da famlia.

4.4 Resumo

A aplicao do mtodo comeou com 7 cenrios de usurios e 14 cenrios de

negcios que foram levantados na identificao dos objetivos do negcio junto ao
cliente. Os cenrios dos usurios foram resultados das demandas dos usurios do
sistema que possuam informaes acerca das deficincias do sistema e os cenrios
de negcio vieram da leitura da viso estratgica do cliente.

No Quadro 22

est resumido o nmero de cenrios levantados para cada atributo de qualidade.

87

Quadro 22 - Nmero de requisitos por atributo de qualidade.

Categorias
Funcionalidade
Confiabilidade
Usabilidade
Eficincia
Manutenibilidade

Portabilidade

Atributos de Negcio

Atributos de Qualidade
Adequao
Preciso
Tolerncia a falhas
Recuperabilidade,
Compreensibilidade
Desempenho
Analisabilidade
Modificabilidade
Testabilidade
Adaptabilidade
Instalabilidade
Co-existncia
Time-to-market
Custo e benefcio

Qtd
1
1
1
1
1
1
1
4
1
2
1
4
2
1

Durante a fase de anlise das abordagens existentes para atender os 22 novos

requisitos foram detectados que dentre as abordagens arquiteturais existentes
atende totalmente somente 1 cenrio, atende parcialmente a 11 cenrios e no
atende a 8 cenrios. Esses nmeros comprovam a necessidade da reestruturao
da arquitetura para adequar as novas necessidades.
No passo 7 foi realizado um Brainstorm e priorizao de cenrios para levantar
dentre o grupo cenrios prioritrios, mas foi observado durante a reunio que alguns
cenrios eram semelhantes e poderiam ser agrupados. De posse da rvore de
utilidade foi elaborado uma matriz identificada por Mapa de Cenrios. O objetivo
deste mapa visualizar a princpio os cenrios semelhantes, facilitando um possvel
agrupamento. Este passo de agrupamento foi incorporado pelos avaliadores para
facilitar a resoluo de conflitos que poderiam surgir. Com o agrupamento o nmero
de cenrios caiu de 22 para 16.
Na priorizao os principais cenrios de um sistema so classificados em
funo de sua importncia e complexidade, considerando a percepo de negcio e
arquitetura. As duas variveis de priorizao Importncia e Complexidade foram
classificadas em alta (A), mdia (M) e baixa (B) de acordo com as caractersticas
dos requisitos. Cinco cenrios foram classificados como alta prioridade.
Levando em considerao todos os requisitos da rvore de utilidade e
analisando as tticas sugeridas, foram identificados 13 trade-off dos quais 5 podem
ser considerados pontos de sensibilidades pois afetam requisitos que foram
considerados com alta prioridade pelos stakeholders. Esses conflitos envolveram

88

cenrios das mais diversas classificaes tais como: Eficincia x Confiabilidade,

Manutenibilidade x Confiabilidade, Funcionalidade e Atributo de negcio
Eficincia, Portabilidade x Eficincia, Manutenibilidade x Portabilidade.

89

5. CONCLUSES E TRABALHOS FUTUROS

Este trabalho apresenta um roteiro que busca direcionar as aes de
evoluo do software em um sistema real. A aplicao do roteiro em um exemplo
prtico mostrou que os passos do roteiro geram informaes relevantes para o
direcionar as aes de evoluo do problema em questo. Este trabalho no se
prope a revelar um processo sistemtico para evoluo de software.
O estudo da utilizao do mtodo de avaliao ATAM no apoio a evoluo
arquitetural atravs de um roteiro que tem como referncia os passos do ATAM mais
o desenvolvimento de um exemplo da aplicao deste roteiro permitiu verificar de
que o mtodo de avaliao selecionado ajuda ao arquiteto conhecer tanto os
objetivos a serem alcanados pelo software, quanto as ferramentas compatveis
com a organizao para alcan-los, possibilitando ao software que exiba os
atributos de qualidade desejados.
Os requisitos no-funcionais descrevem as qualidades e restries de como
o sistema realiza suas funes, ou seja, como o sistema funciona. Um software,
portanto, deve exibir atributos de qualidade que atendam aos seus requisitos. A
arquitetura de software contm a descrio de como o sistema alcana aos atributos
de qualidade desejados. Essa descrio de como o software atende aos requisitos
no-funcionais feita pelas diversas decises presentes na arquitetura. Para
conceber essas decises arquiteturais e, portanto, para projetar a arquitetura
de fundamental importncia que o arquiteto conhea tanto os objetivos a serem
alcanados pelo software, quanto s ferramentas para alcan-los. Em outras
palavras, essencial que ele conhea

tanto os atributos de qualidade, quanto

tcnicas e padres de projeto arquitetural que, ao serem implementados,

possibilitam ao software que exiba os atributos de qualidade desejados.
No estudo desenvolvido a arquitetura do software define o potencial global que
possui um sistema de software para cumprir certos atributos de qualidade de acordo
com o que esta sitado em [Bosch & Molin 1999] e [Dobrica & Niemel 2002].
Durante o desenvolvimento do exemplo, o roteiro proposto permitiu identificar e
direcionar as aes necessrias para alcanara evoluo do sistema de software.
Isso pode ser observado atravs das anlise das tticas sugeridas para evoluo do

90

produto. Estas tticas e as demais informaes compem dados que podem nortear
o planejamento estratgico da organizao no que diz respeito a contratao de
pessoal, aquisio de tecnologia e mercado alvo.
A aplicao do mtodo foi eficiente quando se trata de evoluo do software,
uma vez que permite nortear a avaliao a partir da arquitetura atual do software e
dos cenrios que o requisitante deseja alcanar. A aplicao foi bem sucedida na
avaliao da arquitetura atual mesmo quando ela no possui documentao e na
questo de traar estratgias de atuao considerando a opinio e a necessidade de
todos os envolvidos (stakholders).
Em relao s praticas sem mtodo, fica claro a vantagem do uso de um
mtodo estruturado que conduza a avaliao. Os resultados so concretos e
passveis de serem utilizados pela equipe do cliente.
Outras concluses foram obtidas durante o desenvolvimento do exemplo:

O uso do mtodo ATAM como referncia mostrou-se uma ferramenta eficiente

na descoberta de falhas, no atendimento dos atributos de qualidade
permitindo aos envolvidos na avaliao um entendimento claro da localizao
dos problemas da arquitetura.

Por muitas vezes o mtodo facilitou o direcionamento das decises

arquiteturais permitindo apoiar a evoluo do software.

Os resultados obtidos com o ATAM geram documentos importantes para o

processo de evoluo em curto, mdio e longo prazo. Essa documentao
tem papel importante na evoluo do software e de sua arquitetura.

Foi possvel observar que as alteraes que envolvem os requisitos nofuncionais afetam de maneira mais drstica a arquitetura do software
tornando a evoluo arquitetural mais lenta e cara. Muitas vezes essas
mudanas

comprometem

continuidade

do

software

devido

descontinuidade de uma plataforma, por exemplo.

Uma arquitetura de software estruturada permite que a evoluo funcional

(originadas das mudanas nos requisitos funcionais) seja realizada de forma
mais eficiente, sem causar grandes danos ou efeitos colaterais ao sistema.

O uso dos pontos de vista ODP constitui uma importante ferramenta para a
especificao de arquiteturas e, aliado a um mecanismo de descrio

91

compatvel, facilita o processo de especificao, definio e controle da

evoluo arquitetura.

Dentro do contexto de uma fbrica de software o plano de evoluo de um

sistema alinha-se com o planejamento estratgico da empresa.

A identificao de relaes entre o resultado da avaliao e a reestruturao

da arquitetura de acordo com o padro ODP.

A contextualizao da evoluo de software atravs do relacionamento com o

processo de avaliao de software

Como trabalhos futuros podem ser destacados os seguintes pontos:

Estudo dos efeitos das mudanas dos requisitos no-funcionais sobre a

evoluo arquitetural.

A adaptao do roteiro para realizar uma experimentao de acordo com os

conceitos de Engenharia de Software Experimental

92

6. REFERNCIAS

BARCELOS, R. F. Uma abordagem para inspeo de documentos arquiteturais baseada em

checklist [Rio de Janeiro] 2006 VIII, 175 p., 29,7 cm (COPPE/UFRJ, M.Sc., Engenharia de
Sistemas e Computao, 2006) Dissertao Universidade Federal do Rio de Janeiro,
COPPE.

BAHSOON, R., EMMERICH, W., "Evaluating software architectures: development,

stability, and evolution". In: Book of Abstracts of the ACS/IEEE International
Conference on Computer Systems and Applications, pp. 47, Tunis, Tunisia, July,
2003.

BARBACCI M., CLEMENT P. , LATTANZE A. ,NORTHROP L., and WOOD W.

Using the Architecture Tradeoff Analysis Method (ATAM) to evaluate the software
architecture for a product line of avionics systems: A case study. CMU SEI Technical
Note CMU/SEI-2003-TN-012, Software Engineering Institue, Pittsburgh, PA, 2003.

BASS L., CLEMENTS P., and R. Kazman. Software Architecture in Practice. The SEI
Series in Software Engineering. Addison-Wesley, Reading, MA, 2nd edition, 2002.

BASS. L.; CLEMENTS, P.; Kazman, R. Software Architecture in Practice.

Addison-Wesley Professional, 2 edio, Abril 2003.

BECERRA, J. Aplicabilidade do padro de processamento distribudo e aberto

nos projetos de sistemas de automao. Tese (Doutorado), Universidade de So
Paulo, So Paulo, 1998.

BENGTSSON, PO.
Architecture-Level Modifiability Analysis. 2002. Tese
(Doutorado), Blekinge Institute of Technology, Sweden, Dissertation series No 20022, 2002.
BENNETT K. , RAJLICH V., Software maintenance and evolution: A roadmap. In:
Proc. of the Conference on The Future of Software Engineering, Limerick,
Ireland, May 2000.
BOSCH J. Design & Use of Software Architectures - Adopting and Evolving a
Product Line Approach, Addison-Wesley, Harlow UK, 2000.

93

BOSCH J., MOLIN P., Software Architecture Design: Evaluation and

Transformation, in: Proceedings of the 1999 IEEE Engineering of Computer
Based Systems Symposium (ECBS99), IEEE Computer Society, Los Alamitos CA,
1999.
CHVEZ, M. Um Processo para o controle da evoluo da Arquitetura de
Software Baseado em ODP. 2009. Dissertao (Mestrado) - Universidade de So
Paulo. So Paulo, 2009.

CHRISTOPH, H. R. Engenharia de software para software livre. 2009.

Dissertao (mestrado) PUC. Rio de Janeiro, 2004. 118 p.

CLEMENTS, P et al. Documenting Software Architectures: views and beyond.

Addison-Wesley Professional, Setembro 2002.

CLEMENTS, P; KAZMAN, R; KLEIN, M. Evaluating software architecture:

Methods and case studies. SEI, 8 edio, Abril 2009.

COLQUITT. D.; LEANEY. J. Expanding the view on Complexity within the

Architecture Trade-off Analysis Method. In: Proceedings of the 14th Annual IEEE
International Conference and Workshops on the Engineering of ComputerBased Systems, 2007

DIAS, S.; Roteiro para atualizao tecnolgica de sistemas legados baseado na

avaliao arquitetural e engenharia guiada por valor. 2010. Dissertao
(mestrado). 2010 Instituto de Pesquisas Tecnolgicas do Estado de So Paulo Brasil, 2010
DOBRICA, L.; NIEMELA, E. A Survey on software architecture analysis methods.
IEEE Transactions on Software Engineering, v. 28, n. 7, p. 638-653. 2002

EICK, S. G. et al. Does code decay? Assessing the evidence from change
management data. In: IEEE Transactions on Software Engineering, v. 27, n. 1,
p.112, 2001.

GALL, H. et al. Software evolution observations based on product release history. In:
International Conference on Software Maintenance, p160-166, 1997, Bari, Itlia,
1997.

94

GARLAN, D; SHAW, M. An introduction to software architecture. Technical report

CMU-CS-94-166, Carnegie Mellon University, Pittsburgh, January 1994.

GARLAN. D.;
PERRY. D. Introduction to the Special Issue on Software
Architecture," IEEE Transactions on Software Engineering, vol. 21, no. 4, p. 269274, Abril. 1995

GODFREY, M.W.; GERMAN, D.M.; The past, present, and future of software
evolution, In: Frontiers of Software Maintenance. p. 129-138; Beijing. Setembro
2008

GORTON, I. Essential Software Architecture. Springer, Junho 2006.

GRAAF.
B.; Model-Driven Evolution of Software Architectures,"Software
Maintenance and Reengineering, European Conference on. v. 0; p. 357-360,
2007. Los Alamitos, CA, USA
GUIMARAES, J. H.; Mtodo para manuteno de sistemas de software
utilizando tcnicas arquiteturais. 2008. Dissertao (Mestrado) - Universidade de
So Paulo. So Paulo, 2008.

GURP, J. V.; BOSCH, J., Design erosion: problems and causes. Journal of
Systems and Software, v. 61, n. 2, p.119, Maro 2002.

HINDLE, A. et al. YARN: Animating software evolution. In: 4th Workshop on

Visualizing Software for Understanding and Analysis, 2007. IEEE International,
Banff, Ont. P. 129-136, 2007
HOHMANN, L. Beyond software architecture: creating and sustaining winning
solutions. Addison-Wesley Professional, Janeiro 2003.
IEEE, Institute. IEEE Std 1219-1998. IEEE Standard for Software Maintenance.
New York: Institute of Electrical and Eletronic Engineers. Inc., 1998, 52p.

JAKTMAN, C. B.; LEANEY, J.; LIU, M. Structural Analysis of the Software

Architecture A Maintenance Assessment Case Study. In: Proceedings of the TC2
First Working IFIP. v. 140, p. 455-479, 1999. Apresentado a Conference on
Software Architecture.1999

95

KAZMAN, R et al, Experience with performing architecture tradeoff analysis. In:

Proceedings of the 21st international conference on Software engineering, 1999, p.
54-63, Los Angeles CA, 1999.

KAZMAN, R. et al, The Architecture tradeoff analysis method. In: Proceedings

Fourth Int'l Conf. Eng. of Complex Computer Systems, ICECCS '98, Agosto
1998.
KOTONYA, G; SOMMERVILLE, I.; Requirements engineering: processes and
techniques. John Wiley & Sons, September 1998.
KRUCHTEN, P. B. The 4+1 view model of architecture. Software, IEEE, v.12, n. 6, p
42-50, Novembro 1995.

KRUCHTEN, P.; OBBINK, H.; STANFORD, J. The past, present, and future for
software architecture. Software, IEEE, v. 23, n.2, p. 22-30, 2006.

LEHMAN, M. M et al, Metrics and Laws of Software Evolution - The Nineties View,
In: Proc. Fourth Int. Symp. on Software Metrics, Metrics 97, Albuquerque, New
Mexico, p 20-32; 1997.

LEHMAN, M. M.; Laws of Software Evolution Revisited.; Lecture Notes In

Computer Science - Proceedings of the 5th European Workshop on Software
Process Technology; v. 1149, p. 108 124, Publisher Springer-Verlag London,
UK;1996

LEHMAN, M. M; DE Perry and JF Ramil ; Implications of Evolution Metrics on

Software Maintenance, In: Proc. Int. Conf. on Soft. Maintenance (ICSM'98),
Bethesda, MD, p. 208-217, 1998.

LEHMAN, M. M; JF Ramil ; An Approach to a Theory of Software Evolution, In:

Proceedings of the 4th International Workshop on Principles of Software
Evolution, p. 70 - 74. Apresentado a International Conference on Software
Engineering 2001, Vienna, Setembro 2001.

MACCARI A. Experiences in assessing product family architecture for evolution.

Proceedings of the 23rd International conference on Software Engineering (ICSE).
ACM Press: New York NY, 2002; 585592.

MALAN,

R;

BREDEMEYER,

D.

Defining

non-functional

requirements.

96

BREDEMEYER
CONSULTING
WHITE PAPER
2001
Disponvel
http://www.bredemeyer.com/pdf_fies/NonFunctReq. Acesso em: 30 ago. 2009.

em:

MCNAIR. A.; GERMAN. D. M.; WEBER-JAHNKE. J.; Visualizing Software

Architecture Evolution using Change-sets. In: 14th Working Conference on
Reverse Engineering, p. 130-139, 2007.

MENS, T. et al; Challenges in Software Evolution, In: Proceedings of the 2005

Eighth International Workshop on Principles of Software Evolution, p. 13-22,
Setembro 2005.
MENS. T.; DEMEYER, S.; Software Evolution. Springer, Maro 2008

NIKORA, A.P.; MUNSON, J.C.; Understanding the nature of software evolution. In:
Proceedings. International Conference on Software Maintenance, 2003. p. 8393, 2003.

OLUMOFIN F, MISIC V. Extending the ATAM architecture evaluation to product line

architectures. Proceedings 5th IEEE/IFIP Working Conference on Software
Architecture (WICSA). IEEE Computer Society Press: Los Alamitos CA, 2005; 4556
PADUELLE, M. M. Manuteno de Software: problemas tpicos e diretrizes para
uma disciplina especfica. 2007. 144 p. Dissertao (Mestrado) Instituto de
Cincias Matemticas e de Computao, Universidade de S Paulo, So Carlos, Sp,
2007.

PARNAS, D. L. Software aging. In ICSE '94: Proceedings of the 16th international

conference on Software engineering, pp. 279 - 287 , Los Alamitos, CA, USA ,
1994. IEEE Computer Society Press.
PERRY, D. E.; WOLF, A.L.. Foundations for the study of software architecture.
SIGSOFT Software Engineering Notes, v.17, n. 4, p 40-52. ACM New York, NY,
USA , Outubro 1992.

PORTES, A. A. Fundamental Laws and Assumptions of Software Maintenance,

Empirical Software Engineering, v. 2, n. 2, p. 119-131, Kluwer Academic
Publishers, Hingham,USA, 1997
PRESSMAN, R. Software engineering: a practitioner's approach. McGraw-Hill
Science/Engineering/Math, 6 edition, Abril 2004.

97

RANK. S. Architectural Reflection for Software Evolution, In: 2nd ECOOP Workshop
on Reflection, AOP and Meta-Data for Software Evolution, Glasgow, UK. 2005.

RIVA C, ROSSO D. C. Experiences with software product family evolution.

Proceedings of the 6th International Workshop on Principles of Software Evolution.
ACM Press: New York NY, 2003; 161169

ROSSO D. C. Dynamic memory management for software product family

architectures in embedded real-time systems. Proceedings 5th Working IEEE/IFIP
Conference on Software Architecture (WICSA05). IEEE Computer Society Press:
Los Alamitos CA, 2005; 211212.

ROSSO D. C. Experiences of performance tuning software product family

architectures using a scenario-driven approach. Proceedings of the 10th International
Conference on Evaluation and Assessment in Software Engineering (EASE). British
Computer Society: Swindon, 2006; 3039.

ROSSO, C. D.Continuous evolution through software architecture evaluation: a case

study. 2006, JOURNAL OF SOFTWARE MAINTENANCE AND EVOLUTION:
RESEARCH AND PRACTICE J. Softw. Maint. Evol.: Res. Pract. 2006; 18:351383.

ROZANSKI, N.; Software systems architecture: working with stakeholders using

view-points and perspectives. Addison-Wesley Professional, Abril 2005.

SADOU, N.; TAMZALIT D.; OUSSALAH M. A unified Approach for Software

Architecture Evolution at different abstraction levels, In: Proceedings of the 2005
Eighth International Workshop on Principles of Software Evolution, p. 65-70,
IEEE Computer Society Washington, DC, USA,. 2005.
SCACCHI W. Understanding open source software evolution. In: Software
Evolution, Madhavji NH, Lehman MM, Ramil JF, Perry D (eds.). Wiley: New York
NY, 2004.

SOMMERVILLE, I. ENGENHARIA DE SOFTWARE. (8TH EDIO). ADDISON

WESLEY, MAIO 2007.

98

SVAHNBERG. M.; Supporting software architecture evolution. 2003.

(doutorado). 2003 Blekinge Institute of Technology - Sucia, 2003.

Tese

SWANSON, E. B. The dimensions of maintenance, In: Proceedings of the 2nd

international conference on software engineering, IEEE Computer Society Press:
Los Alamitos, p. 492-97. 1976.

TU. Q, GODFREY. M. W., "An Integrated Approach for Studying Architectural

Evolution", In: 10th International Workshop on Program Comprehension, p.127,
Paris, France, 2002.