Arquitetura_de_Software
262 pág.

Arquitetura_de_Software


DisciplinaAnálise de Sistemas II85 materiais1.124 seguidores
Pré-visualização50 páginas
formato de vídeo
amplamente adotado por reprodutores de mídia. Essa
decisão exclui até o que antes era a necessidade: imple-
mentar um reprodutor de \ufb01lmes próprio, mas também
melhora a usabilidade, uma vez que agora o usuário
está livre para assistir a \ufb01lmes com o reprodutor que
desejar.
A desconsideração de apenas um grupo de interessados
causou mudanças profundas tanto nos atributos de se-
gurança, quanto nos de usabilidade do sistema e, como
consequência, causou mudanças também na arquite-
tura. Se continuarmos a simpli\ufb01cação de nosso cenário
e desconsiderarmos o cliente do software, poderemos
então descartar a necessidade de um baixo custo de
desenvolvimento e operação. Assim, para alcançarmos
2
Digital Rights Management (DRM)
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
109
desempenho esperado pelos consumidores de \ufb01lmes, a
arquitetura do SSF poderia adotar uma técnica sim-
ples, porém cara: para servir mais rápido, basta apenas
dispor de mais recursos computacionais, por exemplo,
processadores, HDs, memória e conexões maiores, mais
rápidos e em maior número. Com essa decisão de au-
mentar os recursos não se importando com o preço, o
SSF poderá não só servir os usuários mais rápido, como
também servir a mais usuários.
3
Essa abordagem de
apenas melhorar o hardware para servir a uma maior
demanda é o que no próximo capítulo chamamos de es-
calabilidade vertical. A escalabilidade vertical costuma
ser bem cara e ter um limite menor de crescimento em
relação à sua alternativa, que é a escalabilidade hor-
izontal. Nesse segundo tipo de escalabilidade, a or-
ganização do software e como ele se comunica realiza
um papel essencial para atender à grande demanda de
usuários, mesmo quando executando em hardware de
menor capacidade. Em outras palavras, há um melhor
aproveitamento dos recursos disponíveis, algo que só
pode ser alcançado por meio de uma arquitetura bem
pensada.
É importante lembrar que dentro de um mesmo grupo de in-
teressados podem existir interesses con\ufb02itantes entre si. A\ufb01-
nal, um grupo pode se organizar em subgrupos de interesses
comuns, mas um subgrupo pode demonstrar interesses con\ufb02i-
tantes com outro subgrupo. Portanto, subgrupos diferentes de
usuários ou de desenvolvedores resultam em requisitos difer-
entes, que signi\ufb01cam atributos de qualidade diferentes e que
são frutos de arquiteturas diferentes. Podemos observar isso
3
Desempenho é um atributo comumente esperado pelos usuários, que
nunca querem esperar pelo serviço. Já escalabilidade não é um atrib-
uto requerido explicitamente por eles, mas se torna necessária quando o
número de usuários aumenta e não se aceita que o desempenho degrade.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
110
CHAPTER 5. STAKEHOLDERS
no estudo de caso (também citado no Exemplo 5.1), quando
o grupo de usuários se organiza em dois subgrupos: os que se
cadastram no sistema para alugar \ufb01lmes e as distribuidoras de
\ufb01lmes. O resultado dessa divisão e o con\ufb02ito podem também
ser observados no exemplo (e na Figura 5.1). Por um lado, as
distribuidoras impõem seus requisitos de proteção aos direitos
autorais. Por outro, os usuários têm a forma de interação com o
sistema modi\ufb01cada, uma vez que devem usar um reprodutor de
\ufb01lmes especí\ufb01co para que os requisitos das distribuidoras sejam
alcançados. Em resumo, mesmo fazendo parte de um mesmo
grupo de envolvidos, a in\ufb02uência de cada subgrupo não pode
ser desconsiderada, uma vez que ela pode ser grande o bas-
tante para modi\ufb01car, inclusive, a forma de outros subgrupos
interagirem com o sistema.
Figura 5.1: Stakeholders de um mesmo grupo, mas di-
vergindo nos requisitos.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
111
5.1.1 Importância dos interessados
Podemos observar por meio do Exemplo 5.1 que a presença
ou ausência de um interessado tem grande in\ufb02uência na ar-
quitetura. Além disso, é comum que sua ausência dê espaço
para simpli\ufb01cações nas decisões arquiteturais.
4
Entretanto,
no mundo real, os envolvidos não se limitam a usuários e de-
senvolvedores. Há diversos outros tipos de envolvidos que in-
\ufb02uenciam o desenvolvimento do software de diversas maneiras
diferentes. Esses envolvidos que in\ufb02uenciam o ciclo de vida
do software também são chamados stakeholders. Devido ao
conceito de stakeholder ser bastante amplo e transcender a
Engenharia de Software, preocupamo-nos apenas com aqueles
que impactam a arquitetura e, por isso, usamos a de\ufb01nição
dada por Rozanski e Woods:
De\ufb01nição 5.1: 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
5
Alguns stakeholders têm diferentes responsabilidades durante
o ciclo de vida do software. Entre as responsabilidades, pode-
mos citar \ufb01nanciamento, projeto, desenvolvimento, teste, uso,
manutenção e até passagem de conhecimento sobre ele. Outros
stakeholders, por sua vez, esperam que o software funcione de
alguma forma especí\ufb01ca: eles têm necessidades em relação ao
software. Por exemplo, é comum para um usuário esperar que
o resultado alcançado pelo software seja con\ufb01ável ou que seja
alcançado em um tempo hábil. Quando estamos no espaço do
problema, costumamos chamar essas responsabilidades e neces-
sidades de requisitos do software. Por outro lado, quando esta-
4
Note que uma arquitetura mais simples não necessariamente signi\ufb01ca
um produto com desenvolvimento mais barato ou execução mais rápida.
5
N. Rozanski and E. Woods. Software Systems Architecture: Working
With Stakeholders Using Viewpoints and Perspectives, Addison-Wesley
Professional 2005.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
112
CHAPTER 5. STAKEHOLDERS
mos no espaço da solução, costumamos chamá-las de atributos
de qualidade. Logo, os stakeholders têm forte in\ufb02uência so-
bre a arquitetura de um software porque ela é uma ferramenta
essencial para proporcionar seus atributos de qualidade e aten-
der aos requisitos, como, por exemplo: custo, reusabilidade,
testabilidade, manutenibilidade, legibilidade, desempenho, es-
calabilidade, segurança, con\ufb01abilidade, entre outros.
5.2 Tipos de stakeholders e sua relação
com os atributos de qualidade
Entre os diversos tipos de stakeholders que in\ufb02uenciam a ar-
quitetura, podemos citar os usuários, os desenvolvedores, os
gerentes, os testadores, os clientes (que podem ou não ser
usuários), os designers de outros sistemas e os mantenedores,
além dos analistas e o próprio arquiteto do sistema. Con-
siderando que esse é um conjunto heterogêneo de papéis, é
natural que cada papel possua diferentes necessidades e re-
sponsabilidades que têm efeito sobre a arquitetura e que, even-
tualmente, resultem em con\ufb02itos.
Resolver con\ufb02itos de interesses entre stakeholders está entre as
obrigações de um arquiteto de software. Ele deve ser consciente
de que muitas vezes não será possível agradar perfeitamente a
todos os interessados, uma vez que esses con\ufb02itos podem im-
pedir o projeto de uma solução ótima. Portanto, sua obrigação
será a de produzir uma arquitetura boa o su\ufb01ciente e que faça
todos os stakeholders \ufb01carem satisfeitos. Por isso, é importante
que cada envolvido seja informado de como a solução de seu
interesse foi restringida pelos interesses de outros envolvidos.
A seguir, podemos observar duas situações de divergências en-
tre stakeholders que resultam em con\ufb02itos entre os atributos
de qualidade.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
113
Exemplo 5.2
As distribuidoras