Arquitetura_de_Software
262 pág.

Arquitetura_de_Software


DisciplinaAnálise de Sistemas II85 materiais1.124 seguidores
Pré-visualização50 páginas
of Architectural De-
sign Decisions in Software Intensive Systems [65] e The De-
cision View's Role in Software Architecture Practice [63], de
Kruchten et al e que são focados em descrever a arquitetura
como decisões arquiteturais e em montar um arcabouço con-
ceitual de como descrever decisões arquiteturais, propondo in-
clusive um ponto de vista neste sentido; Architecture Knowl-
edge Management: Challenges, Approaches, and Tools [9], de
Babar e Gorton, que mostram ferramentas para organizar e
documentar as decisões arquiteturais; e The Decision View of
Software Architecture [38], de Dueñas e Capilla, e Software
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
232
CHAPTER 8. DOCUMENTAÇÃO DA
ARQUITETURA
Architecture as a Set of Architectural Design Decisions [55],
de Jansen e Bosch, que mostram a importância das decisões
na arquitetura.
8.6.3 Visões e pontos de vista
Além dos trabalhos que apresentam conjuntos de pontos de
vista e que já foram referenciados na Seção &quot;Visões arquitetu-
rais&quot; (Section 8.3: Visões arquiteturais), podemos citar o livro
Software Design [22], de Budgen, que a\ufb01rma que diferentes rep-
resentações lidam com diferentes qualidades e interesses, além
de mostrar alguns benefícios de se documentar a arquitetura
por meio de visões. Já o artigo Four Metaphors of Architec-
ture in Software Organizations: Finding Out the Meaning of
Architecture in Practice [98], de Smolander, descreve como al-
guns stakeholders percebem a arquitetura na prática e assim
justi\ufb01ca o uso de visões arquiteturais. Por \ufb01m, citamos o livro
Applied Software Architecture [50], de Hofmeister et al, que
apresenta mais um conjunto de pontos de vista.
8.6.4 Ferramentas para análise
Em relação a análises baseadas em inspeções, citamos o livro
da série do SEI, Evaluating Software Architectures [33], de
Clements et al, que descreve os métodos SAAM, ATAM e
ARID, inclusive com estudos de casos.
Já sobre ADLs, citamos dois surveys sobre o assunto: um con-
duzido por Clements, A Survey of Architecture Description
Languages [29], e outro por Taylor e Medvidovic, A Classi\ufb01-
cation and Comparison Framework for Software Architecture
Description Languages [77].
E, \ufb01nalmente, apresentamos alguns trabalhos sobre veri\ufb01cação
de conformidade: Software Re\ufb02exion Models: Bridging The
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
233
Gap Between Design and Implementation [78] e Software Re-
\ufb02exion Models: Bridging The Gap Between Source and High-
Level Models [79], por Murphy et al; Bridging the Software
Architecture Gap [66], de Lindvall e Muthig; e Design tests:
An approach to programmatically check your code against de-
sign rules [21], de Brunet et al.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
234
GLOSSARY
Glossary
A arquitetura de
software
Arquitetura é a
organização
fundamental de
um sistema
incorporada em
seus componentes,
seus
relacionamentos
com o ambiente, e
os princípios que
conduzem seu
design e evolução.
atributo de
qualidade
É uma propriedade
de qualidade do
software ou de seu
ciclo de
desenvolvimento,
podendo se
manifestar como
características,
capacidades ou
restrições de uma
função especí\ufb01ca
ou de um conjunto
de funções do
software.
D decisão arquitetural
Uma escolha entre
as alternativas de
design
arquitetural. Essa
escolha se propõe a
alcançar um ou
mais atributos de
qualidade do
sistema, por meio
da(s) estrutura(s)
arquiteturais que
ela envolve ou
de\ufb01ne.
Mmodelo de qualidade
Modelo que de\ufb01ne e
organiza os
atributos do
software
importantes para a
avaliação de sua
qualidade.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
GLOSSARY 235
P ponto de vista
arquitetural
É um arcabouço
conceitual que
de\ufb01ne elementos,
conexões e técnicas
que compõem uma
visão arquitetural,
além especi\ufb01car
seu propósito de
acordo com seus
interessados.
R rastreamento de
requisitos
É o pro-
cesso/capacidade
de ligar requisitos
do sistema a
estruturas
arquiteturais.
requisito funcional
É a declaração de
uma função ou
comportamento
providos pelo
sistema sob
condições
especí\ufb01cas.
requisito
não-funcional de
processo
Requisito que
restringe o
processo de
desenvolvimento
do software.
requisito
não-funcional de
produto
Requisito que
especi\ufb01ca as
características que
um sistema ou
subsistema deve
possuir.
requisito
não-funcional
externo
Requisito derivado
do ambiente em
que o sistema é
desenvolvido, que
pode ser tanto do
produto quanto do
processo.
requisito
não-funcional
É a descrição de
propriedades,
características ou
restrições que o
software apresenta
exibidas por suas
funcionalidades.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
236
GLOSSARY
S stakeholder
\ufffdUm stakeholder em
uma arquitetura
de software é uma
pessoa, grupo ou
entidade com um
interesse ou
preocupações sobre
a realização da
arquitetura.\ufffd
13
V visão arquitetural
É a representação
do sistema ou de
parte dele da
perspectiva de um
conjunto de
interesses
relacionados.
A alternativa de design
Uma possibilidade
de solução
representada em
nível de
conhecimento.
D design arquitetural
Descreve a
arquitetura do
software ou, em
poucas palavras,
como o software é
decomposto e
organizado em
módulos e suas
relações.
design de software
&quot;É tanto o processo
de de\ufb01nição da
arquitetura,
módulos, interfaces
e outras
características de
um sistema quanto
o resultado desse
processo.\ufffd
14
design detalhado
Descreve o
comportamento
especí\ufb01co e em
detalhes dos
módulos que
compõem o design
arquitetural.
13
N. Rozanski and E. Woods. Software Systems Architecture: Working
With Stakeholders Using Viewpoints and Perspectives, Addison-Wesley
Professional 2005.
14
Freny Katki et al, editors. IEEE Standard Computer Dictionary:
Compilation of IEEE Standard Computer Glossaries. Institute of Elec-
trical and Electronics Engineers Inc., 1991.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
GLOSSARY 237
O objetivo de design
Aquilo que se
pretende alcançar
para resolver as
necessidades do
cliente.
R representação de
design
A linguagem do
processo de design
que representa o
produto do design
para sua
construção e
também dá
suporte ao
processo de design
como um todo.
requisito funcional
É a declaração de
uma função ou
comportamento
providos pelo
sistema sob
condições
especí\ufb01cas.
requisito
não-funcional
É a descrição de
propriedades,
características ou
restrições que o
software apresenta
exibidas por suas
funcionalidades.
restrição de design
A regra, requisito,
relação, convenção,
ou princípio que
de\ufb01ne o texto do
processo de design.
S solução do design
A descrição do
design que permite
a construção do
sistema de
software que
alcança os
objetivos do
design.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
238
BIBLIOGRAPHY
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
Bibliography
[1] IEEE Standard Computer Dictionary: Compilation of
IEEE Standard Computer Glossaries. Institute of Elec-
trical and Electronics Engineers Inc., The, 1991.
[2] Software Evolution. Springer, March 2008.
[3] IEEE Std 754-2008.