Anais do CONCISTEC'14

2014, copyright by IFSP

5 Congresso Cientfico da Semana Tecnolgica IFSP

20-24 de outubro de 2014, Bragana Paulista, SP, Brasil

APLICANDO ATAM NA ARQUITETURA DO SISTEMA DE

INFORMAES DE PREFEITURAS
Paulo Lima, pcdl1970@gmail.com
Adriana Carniello, adrianacarniello@ifsp.edu.br
Andreia Carniello, andreiacarniello@ifsp.edu.br
Instituto Federal de Educao, Cincia e Tecnologia de So Paulo IFSP Campus Guarulhos

RESUMO. A importncia da arquitetura de software nos sistemas de informaes atuais cada vez mais evidente.
Existem diversos mtodos propostos para avaliao da arquitetura a fim de verificar e validar a soluo proposta com
relao ao atendimento das expectativas de negcio e dos requisitos de qualidade. Vrios trabalhos avaliaram estes
mtodos na busca de uma abordagem holstica que possa ser aplicada s diversas modalidades de sistemas. Por meio da
pesquisa dos principais mtodos de avaliao de arquitetura de software e da seleo de um conjunto destes mtodos
(SAAM, ATAM, CBAM), este trabalho analisa as caractersticas, propostas e indicaes do conjunto de mtodos
selecionado para utilizao como apoio tomada de deciso na escolha de arquiteturas de software. Como estudo de
caso, foi aplicado o mtodo ATAM no sistema de informaes de prefeituras INFOPREFEITURA. Ao final deste
estudo de caso, foi apresentada a arquitetura de software proposta para atender aos direcionadores do negcio e aos
principais atributos de qualidades de acordo com a pontuao final de importncia de cada uma das categorias de
requisitos no funcionais, seguindo os cenrios indicados pelas partes interessadas. A realizao deste trabalho
permitiu propor a utilizao de mtodos baseados em cenrios para avaliao de arquiteturas de software e afirmar que
o balanceamento dos requisitos de qualidade conflitantes direciona para uma abordagem assertiva na deciso da
arquitetura.
Palavras-chave: Arquitetura de Software. Verificao. Validao. Sistemas.
1. INTRODUO
Hoje em dia, a Arquitetura de um Software um ativo chave para organizaes que constroem sistemas complexos
intensivamente baseados em software. A arquitetura criada no comeo do desenvolvimento e fornece aos
desenvolvedores meios para criar um projeto de alto nvel do sistema de forma a assegurar que seja possvel
implementar todos os requisitos que precisam ser atendidos. Existem vrias definies para Arquitetura de Software,
com poucas diferenas de acordo com o domnio e a experincia das pessoas.
A arquitetura descreve quais componentes de alto nvel compem um software, bem como quais responsabilidades
esses componentes assumem em relao a outros componentes no sistema. Tambm descreve a organizao dos
componentes tanto no nvel conceitual quanto em detalhes, visto que cada componente pode ter sua prpria estrutura de
arquitetura. Por fim, a arquitetura define quais interfaces os componentes expem aos demais e quais as interfaces e
componentes que eles, por sua vez, usam. A arquitetura criada com base em um conjunto de requisitos obtidos junto
aos stakeholders (usurios, desenvolvedores, etc.).
Requisitos funcionais descrevem o que o sistema deve fazer e requisitos de qualidade descrevem um conjunto de
caractersticas que o sistema deve apresentar (por exemplo, quanto tempo o sistema pode levar para concluir uma
operao, grau de facilidade para manuteno do sistema, etc.). Para auxiliar os desenvolvedores de software a garantir
que a arquitetura do software atenda aos atributos de qualidade, vrios mtodos foram propostos na literatura. Este
artigo tem como objetivo avaliar os mtodos SAAM, ATAM, CBAM e indicar um mtodo para ser utilizado na
avaliao da arquitetura de software do sistema de Informao de Prefeituras dos municpios brasileiros, o
INFOPREFEITURA, como proposta de validao e verificao dos requisitos que sero implementados no projeto.
2. Mtodos de Avaliao de Arquitetura de Software
A arquitetura de um software a descrio da estrutura do sistema, que compreende os elementos de software, o
relacionamento entre estes elementos e as propriedades externamente visveis destes elementos. A arquitetura o
primeiro artefato que pode ser analisado para determinar o quo bem os seus atributos de qualidade esto sendo
alcanados. A arquitetura serve como o plano do projeto e tambm como um veculo de comunicao, pois a
manifestao das primeiras decises do projeto e uma abstrao reutilizvel que pode ser transferida para sistemas
futuros (BASS; CLEMENTS; KAZMAN, 2012).
Atualmente existem mtodos de avaliao de arquitetura de software baseados em cenrios. Vrios desses mtodos
so baseados no SAAM ou no ATAM, ambos criados a partir da iniciativa e pesquisa do Carnegie Mellon Institute
(CMI). Esses mtodos normalmente so propostos para algum tipo de sistema e para um conjunto especfico de
qualidades ou requisitos no-funcionais (RNF) especficos.
A maioria dos mtodos foram desenvolvidos a partir de outro existente, propondo uma evoluo ou extenso do
mtodo tomado como base. Com relao avaliao da eficcia destes mtodos, observa-se que no tem havido muito

Anais do CONCISTEC'14
2014, copyright by IFSP

5 Congresso Cientfico da Semana Tecnolgica IFSP

20-24 de outubro de 2014, Bragana Paulista, SP, Brasil

esforo nesta direo. No entanto, existe uma iniciativa do grupo de trabalho internacional Software Architecture
Review and Assessment (SARA) na publicao da reviso dos mtodos de avaliao existentes (IONITA; HAMMER;
OBBINK,2002).
A qualidade do software definida como o grau em que o software possui uma desejada combinao de atributos.
Os requisitos de qualidade que um software deve satisfazer so comumente divididos em dois grupos: Qualidades de
Desenvolvimento (manutenibilidade, entedibilidade e flexibilidade) e Qualidades Operacionais (desempenho e
usabilidade). Durante o processo de desenvolvimento da arquitetura importante validar que a arquitetura tem os
atributos de qualidade necessrios. Isso feito usualmente utilizando uma ou mais avaliaes da arquitetura
(MATTSON; GRAHN; MRTENSSON, 2006). Os atributos de qualidade em foco so:
Manutenibilidade Grau de Facilidade para modificar, corrigir ou melhorar um componente ou um sistema de
software;
Desempenho O grau com o qual um sistema pode completar suas funes dentro de determinadas restries (tais
como velocidade, preciso, uso de memria, etc.);
Testabilidade Grau de facilidade com o qual pode-se estabelecer critrios de teste e testes de desempenho para
saber se os requisitos foram atendidos;
Portabilidade Facilidade com a qual um sistema pode ser transferido entre ambientes de hardware ou software.
Neste trabalho, avaliam-se os seguintes mtodos de anlise dos atributos de qualidade de arquiteturas de software:
1. SAAM, Software Architecture Analysis Method;
2. ATAM, Architecture Trade-off Analysis Method;
3. CBAM, Cost Benefit Analysis Method.
2.1. SAAM
Foi o primeiro mtodo de anlise de arquitetura de software baseado em cenrios amplamente divulgado. Foi criado
para avaliar a modificabilidade da arquitetura em vrios aspectos. Foi proposto como mtodo para expressar diversas
reivindicaes de arquitetura atravs de cenrios e a partir da avaliao confrontando cenrios atuais. Na prtica SAAM
tem provado ser til para avaliao rpida de muitos atributos de qualidade como modificabilidade, portabilidade,
extensibilidade, integralidade, assim como requisitos funcionais. Na anlise de uma nica arquitetura, SAAM indica os
pontos fracos ou fortes, juntamente com os pontos onde a arquitetura falha no atendimento aos requisitos de
modificabilidade. Se duas ou mais arquiteturas candidatas, que forneam as mesmas funcionalidades, so comparadas
com relao modificabilidade, SAAM pode produzir um ranking relativo entre essas.
O mtodo consiste em cinco passos, comeando com a documentao da arquitetura de uma forma que todos os
participantes da avaliao consigam entender. Depois, cenrios que descrevam o uso pretendido do sistema so criados.
Os cenrios devem representar os interesses de todos os stakeholders. Os cenrios so avaliados e um conjunto que
representa os aspectos que devem ser avaliados selecionado. Cenrios que interagem entre si so identificados como
uma maneira de medir a modularidade da arquitetura. Os cenrios so ordenados de acordo com a prioridade e impacto
previsto na arquitetura.
2.2. ATAM
Segundo o trabalho de (IONITA; HAMMER; OBBINK, 2002), o Architecture Trade-off Analysis Method (ATAM),
um mtodo de arquitetura baseado em cenrios para avaliao de atributos de qualidade como modificabilidade,
portabilidade, extensibilidade, e integralidade. Alm disso, explora a interao entre os atributos de qualidade e suas
interdependncias destacando o mecanismo de balanceamento e oportunidades entre as diferentes qualidades.
Para a conduo com sucesso de uma sesso de avaliao do ATAM, os participantes deste mtodo devem satisfazer
ao seguinte conjunto inicial de pr-requisitos:
Os avaliadores devem entender a arquitetura do sistema, reconhecer os parmetros arquiteturais, definir
suas implicaes com relao aos atributos de qualidade do sistema, e confrontar estas implicaes com os
requisitos;
As reas problemas so chamadas pontos de sensibilidade, contrapontos e riscos;
Os atributos de qualidade devem ser entendidos atravs de cenrios descritivos para avaliao dos atributos
de qualidade;
Uma sesso de avaliao do ATAM utiliza como entradas os requisitos iniciais do sistema e a descrio da
arquitetura de software do sistema.
O mtodo ATAM consiste de quatro fases: apresentao, investigao e anlise, teste e relatrio. Cada fase consiste
em uma coleo de passos. A fase de apresentao envolve a troca de informaes entre as apresentaes. A fase de
investigao e anlise se preocupa com a avaliao dos requisitos de atributos chaves de qualidade versus as abordagens
arquiteturais. A fase de teste compara os resultados das fases anteriores para as necessidades das partes interessadas
mais relevantes. Finalmente, a fase de relatrio sumariza os resultados do ATAM.
2.3. CBAM

Anais do CONCISTEC'14
2014, copyright by IFSP

5 Congresso Cientfico da Semana Tecnolgica IFSP

20-24 de outubro de 2014, Bragana Paulista, SP, Brasil

O CBAM quantifica benefcios usando valores de utilidade que representam preferncia do projeto, determinados
por votos ou consenso entre as partes interessadas. O benefcio que ser adicionado ao sistema atravs da
implementao de uma Estratgia de Software (ES) referido como de utilidade. Cada ES oferece um nvel especfico
de utilidade para os interessados, e cada ES tem implicaes de custo e cronograma. Mas, desde que o valor de utilidade
de um projeto determinado de forma independente, no podemos garantir que o valor seja razovel. Alm disso, a
tomada de deciso por consenso da importncia dos RNF no incio do processo, pode no refletir o conhecimento de
cada parte interessada, pode gerar muita incerteza na deciso de projeto. Alm disso, uma vez que as partes interessadas
devem considerar vrios tipos de informao de deciso simultaneamente e de forma independente, a possibilidade de
erro de julgamento alta.
3. Descrio do sistema INFOPREFEITURA
O escopo do INFOPREFEITURA criar uma Homepage para Prefeituras a fim de atender a demanda da Lei
Federal n 9755/98, adicionando ainda informaes sobre o municpio e outros servios para a populao.
A Homepage da Prefeitura visa informar os cidados, turistas e prestadores sobre os mais diversos tipos de
servios e demandas da cidade.
Utiliza informaes em tempo real, conectando diretamente com o Banco de Dados da Prefeitura, podendo assim
executar tarefas agilmente, como solicitaes dos muncipes acerca dos mais diversos pedidos, como limpeza pblica,
transporte, energia, gua, etc.
Apresenta, tambm, dados demogrficos, estatsticos e pontos tursticos, tambm acessando banco de dados da
Prefeitura e do Censo, apresentando inclusive imagens de arquivos digitalizadas.
Disponibiliza informaes on-line para licitaes e cadastramento de prestadores de servios, visando, assim,
agilizar os processos de aquisio de bens e servios, sendo as partes interessadas (stakeholders):
Contribuintes: So usurios que buscam informaes e obteno de documentos referentes aos impostos,
relatrios de gesto, certides, etc.
Fornecedores: So aqueles que possuam contratos de prestao de servios e/ou materiais com o Municpio,
com participaes em licitaes;
rgos pblicos: So rgos ligados Prefeitura, autarquias que se submetem a ela;
Visitantes: So usurio comuns que acessam o site apenas para obter informaes da cidade, como, por
exemplo, turistas;
Atendentes: So funcionrios que acessam a Homepage para prestar a orientao ao cidado.
Como Requisitos No-Funcionais constam:

Confiabilidade: RNF001 O sistema deve estar disponvel e operacional; RNF002 Deve possuir um sistema
de backup, apto a entrar em operao caso acontea falha no servidor principal;
Segurana e privacidade: RNF003 O Sistema deve garantir ao usurio que seus dados estejam seguros na
base de dados, bem como suas informaes s possam ser acessadas por ele ou por quem possuir autorizao
prvia;
Desempenho: RNF004 O Sistema deve garantir um fluxo de informao estvel e contnuo, ainda que dentro
de um limite pr-estabelecido; RNF005 O tempo de resposta h uma transao no deve exceder o tempo
mnimo pr-estabelecido; RNF006 Caso o limite de alguma funo estiver excedido, o usurio dever
receber informao instantaneamente; RNF007 O Sistema deve trabalhar com uso mximo de 75% da
capacidade de processamento do servidor, 75% da memria RAM e 75% da conexo de rede, a fim de evitar
sobrecarga no sistema computacional;
Qualidade: RNF008 O Sistema deve seguir os mesmos padres e linguagem em todos os seus recursos, a fim
de facilitar a interao do usurio;
RNF009 O cdigo-fonte do sistema deve ser padronizado e documentado, a fim de facilitar possveis ajustes
por outros funcionrios;
Usabilidade: RNF010 O Sistema deve possuir recurso de ajuda ao usurio e e-mail para contato; RNF011
Deve possuir auxlio para pessoas portadoras de necessidades especiais;
Portabilidade: RNF012 Deve ser possvel acessar o site em qualquer navegador de internet; RNF013 O
acesso ao sistema no poder depender do Sistema Operacional, ou seja, deve ser desenvolvido com linguagem
multiplataforma; RNF014 O acesso deve estar disponvel para quaisquer dispositivos, seja PC, Tablet ou
Smartphone.

Anais do CONCISTEC'14
2014, copyright by IFSP

5 Congresso Cientfico da Semana Tecnolgica IFSP

20-24 de outubro de 2014, Bragana Paulista, SP, Brasil

4. A escolha do mtodo de Arquitetura para o Sistema INFOPREFEITURA

O mtodo ATAM analisa quo bem a arquitetura de software satisfaz objetivos particulares de qualidade. Ele
tambm fornece direes sobre interdependncias dos atributos de qualidade - o que significa como trade-off contra o
outro. O ATAM baseado no Mtodo de Anlise de Arquitetura de Software (SAAM) e considerado uma evoluo
desse mtodo. O ATAM um mtodo de arquitetura baseado em cenrios para avaliao de atributos de qualidade
como modificabilidade, portabilidade, extensibilidade e integralidade. Alm disso, explora a interao entre os atributos
de qualidade e suas interdependncias destacando o mecanismo de balanceamento e oportunidades entre as diferentes
qualidades.
O CBAM prioriza aspectos no abordados no ATAM, pois trata-se de um mtodo de arquitetura centrado em
analisar os custos, benefcios e implicaes no cronograma de decises de arquitetura. O CBAM tambm avalia o nvel
de incerteza associado essas decises. O CBAM um mtodo centrado na arquitetura para a anlise das implicaes
dos custos, benefcios e prazo das decises de arquitetura. Ele tambm permite a avaliao da incerteza em torno das
decises de custos e benefcios, proporcionando assim uma base para a tomada de deciso informada sobre projeto
arquitetural e sua evoluo.
Devido s caractersticas do sistema INFOPREFEITURA que prioriza os aspectos tcnicos e qualidades sistmicas,
e considerando que o ATAM mais abrangente que o SAAM, alm disso, pelo fato do foco do sistema no est
relacionado com os aspectos de custo e prazos que o ponto forte do CBAM, ser adotado o mtodo ATAM no estudo
de caso proposto.
Seguem as fases e os passos do ATAM aplicados no estudo de caso INFOPREFEITURA:
Fase Apresentao:
ATAM Passo 1 apresentando ATAM
ATAM foi apresentado para os participantes:
Chefes de sees envolvidos no projeto;
Lderes tcnicos envolvidos no desenvolvimento;
Gerncia de projeto.
ATAM Passo 2 Apresentao dos direcionadores de negcio
A gerncia de projeto apresenta os objetivos do sistema INFOPREFEITURA e enfatiza os indicadores dos requisitos
de qualidade de arquitetura, conforme descritivos dos requisitos no-funcionais (RNF) listados: Confiabilidade;
Segurana; Desempenho; Qualidade; Usabilidade; Portabilidade.
ATAM Passo 3 Apresentao da arquitetura
O arquiteto apresenta a arquitetura de software do sistema focando em como enderea os direcionadores de negcio
apresentados no passo anterior.
Fase Investigao e Anlise:
ATAM Passo 4 Identificar as abordagens Arquiteturais:
As abordagens arquiteturais consideradas para o INFOPREFEITURA so:
.NET Framework MVC
PHP MVC
Java EE
ATAM Passo 5 Gerar rvore Utilidade de Atributo de Qualidade:
As interessadas listaram e quantificaram (Quantidade RNF) os fatores de qualidade do sistema de acordo com as
categorias de requisitos abaixo:
Confiabilidade,
Segurana,
Desempenho,
Qualidade,
Usabilidade,
Portabilidade.
Para cada categoria de requisito de qualidade do sistema (RNF) foi atribudo um grau de importncia atravs de
uma escala numrica, na qual o menos relevante foi atribuindo o peso um (menos importante) e o mais relevante foi
atribudo o peso cinco (mais importante) de acordo com as expectativas e consideraes dos envolvidos na definio
dos requisitos do sistema.
Foram analisados os cenrios de caso de uso e a ocorrncia dos requisitos de qualidade e a importncia de cada um
no contexto do comportamento e resultado esperados no sistema. A partir desta anlise obteve-se a quantidade de cada

Anais do CONCISTEC'14
2014, copyright by IFSP

5 Congresso Cientfico da Semana Tecnolgica IFSP

20-24 de outubro de 2014, Bragana Paulista, SP, Brasil

RNF por categoria cuja importncia est representada por um o indicador final que Indicador Final corresponde ao
produto da quantidade de RNF multiplicada pelo peso atribuda categoria do requisito. Deste modo o Indicador Final
obtido pela expresso: Indicador Final = Quantidade RNF x Peso.
Tabela1 dos atributos de qualidade que compreendem o sistema INFOPREFEITURA:
Categoria Requisito
Quantidade RNF
Peso (1 a 5)
Indicador Final

Confiabilidade

Segurana

Desempenho

20

Qualidade

10

Usabilidade

Portabilidade

15

ATAM Passo 6 Analisar Abordagens Arquiteturais

Baseados nos cenrios mais prioritrios identificados no passo anterior, as abordagens arquiteturais que endeream
esses cenrios foram elicitadas e analisadas. Durante este passo os riscos potenciais, possveis no-riscos, os pontos de
sensibilidade e contrapontos foram identificados. As abordagens arquiteturais avaliadas como possveis opes so:

.NET Framework MVC

Java EE

Fase de Teste:
ATAM Passo 7 Avaliar e priorizar cenrios
Os cenrios foram priorizados por votao com relao ao peso de cada um para atendimento aos requisitos de
qualidade do INFOPREFEITURA. Os resultados foram pontuados na coluna Indicador Final.
ATAM Passo 8 Reanalisar Abordagens Arquiteturais
Os cenrios priorizados foram utilizados para reiteraes do Passo 6 com objetivo de selecionar a abordagem
arquitetural mais indicada para INFOPREFEITURA.
Fase Relatrio:
ATAM Passo 9 Apresentao Resultados
A abordagem arquitetural escolhida para atendimento aos requisitos de qualidade do sistema INFOPREFEITURA
foi o padro de arquitetura Java EE.

Anais do CONCISTEC'14
2014, copyright by IFSP

5 Congresso Cientfico da Semana Tecnolgica IFSP

20-24 de outubro de 2014, Bragana Paulista, SP, Brasil

Segue na Figura 1 a arquitetura de software proposta para soluo do INFOPREFEITURA:

Figura 1. Diagrama de arquitetura em camadas do sistema INFOPREFEITURA

Segundo JUNEAU (2013), Java uma linguagem de programao madura, que tem sido aperfeioada ao longo dos
anos em uma linguagem produtiva amplamente utilizada no desenvolvimento de aplicaes corporativas. A plataforma
Java EE 7 abrange as solues utilizando as mais atuais tecnologias Java Enterprise e permite desenvolver muito mais
rpido do que com as tecnologias mais antigas.
5. Proof-of-Concept (PoC)
Segundo EELES e CRIPPS (2009), depois de tomar as decises sobre as tecnologias especficas a serem utilizadas
na arquitetura, muitas vezes faz sentido provar a arquitetura atravs da criao de uma Proof-of-Concept (PoC) de
arquitetura. A Prova de Conceito arquitetural (opcionalmente) desenvolvida na fase inicial para ajudar a determinar a
viabilidade do projeto, avaliar os riscos tcnicos inerentes ao seu desenvolvimento, e formular e refinar os requisitos
arquitetonicamente significativos.
A Prova de Conceito de arquitetura (PoC) pode assumir vrias formas, por exemplo:
Uma lista de tecnologias conhecidas (frameworks, padres, arquiteturas executveis) que parecem
apropriadas para a soluo;
um esboo de um modelo conceitual de uma soluo usando uma notao, como UML;
uma simulao de uma soluo;
um prottipo executvel.
Neste projeto de pesquisa, prope-se a realizao da Prova de Conceito (PoC) implementando uma arquitetura de
referncia atravs da implementao em camadas desta arquitetura a fim de validar a arquitetura proposta.
Considerando a Prova de Conceito (PoC) na sua forma de realizao atravs de tecnologias, neste projeto de
pesquisa, pretende-se aplicar a plataforma Java EE 7 na validao da arquitetura do sistema proposto, demonstrando,
assim, como realizar PoC atravs de implementao de parte do sistema para corroborar na verificao e validao da
arquitetura proposta para soluo do sistema que ser desenvolvido.

Anais do CONCISTEC'14
2014, copyright by IFSP

5 Congresso Cientfico da Semana Tecnolgica IFSP

20-24 de outubro de 2014, Bragana Paulista, SP, Brasil

6. CONCLUSES
A arquitetura de um sistema de software tem sido um aspecto importante do desenvolvimento de software. Uma boa
arquitetura deve melhorar a probabilidade de que o sistema atenda aos seus requisitos. Muitos dos mtodos somente
abordam um atributo de qualidade e poucos avaliam vrios atributos simultaneamente no mesmo framework ou mtodo.
Especificamente, somente o mtodo ATAM inclui anlise de trade-off (perde-e-ganha).
A partir da pesquisa dos principais mtodos de avaliao de arquitetura de software e da seleo do mtodo ATAM,
este trabalho analisou suas caractersticas, propostas e indicaes para utilizao como apoio tomada de deciso na
escolha de arquiteturas de software. O mtodo ATAM foi aplicado como apoio a tomada de deciso da arquitetura
proposta no sistema de informaes de prefeituras INFOPREFEITURA. Foi justificada a deciso da arquitetura de
software proposta pelo atendimento aos direcionadores do negcio e aos principais atributos de qualidades de acordo
com a pontuao final de importncia de cada uma das categorias de requisitos no-funcionais, seguindo os cenrios
indicados pelas partes interessadas. A realizao deste trabalho permitiu propor a utilizao do mtodo ATAM baseado
em cenrios para avaliao da arquitetura de software e afirmar que o balanceamento dos requisitos de qualidade
conflitantes direciona para uma abordagem assertiva na deciso da arquitetura.
Para projetos futuros seria interessante avaliar uma combinao dos mtodos introduzidos neste artigo e a
elaborao de uma PoC, a fim de ajudar a avaliar a viabilidade de implementao da arquitetura proposta na plataforma
indicada e da produtividade das equipes envolvidas nessa arquitetura para atendimento dos prazos, custos e eficcia
esperados no projeto.
7. REFERNCIAS
BASS, L.; CLEMENTS, P.; KAZMAN, R. Software architecture in practice (3rd Edition) (SEI Series in Software
Engineering). Addison-Wesley Professional, 2012.
EELES, P.; CRIPPS, P. The process of software architecting. [s.l.] Pearson Education, 2009.
IONITA, M. T.; HAMMER, D. K.; OBBINK, H. Scenario-based software architecture evaluation methods: An
overview. ICSE/SARA, Eindhoven (HOL), 2002.
JUNEAU, J. Java EE 7 Recipes: A problem-solution approach. Apress, 2013.
MATTSON, M.; GRAHN H.; MRTENSSON. Software Architecture Evaluation Methods for Performance,
Maintainability, Testability, and Portability. Blekinge Institute of Technology, Ronneby(SUE), 2006.
LEE, J.; KANG, S.; KIM, C. Software architecture evaluation methods based on cost benefit analysis and
quantitative decision making. Springer Science and Business Media, 2008.

8. NOTA DE RESPONSABILIDADE
Os autores so os nicos responsveis pelo contedo deste artigo.