Arquitetura_de_Software
262 pág.

Arquitetura_de_Software


DisciplinaAnálise de Sistemas II85 materiais1.124 seguidores
Pré-visualização50 páginas
tirando proveito de diversas técnicas como
caching, processamento assíncrono, replicação, entre
outras.
Exemplo 4.25
Um requisito desejável em um jogo de videogame é que
ele esteja disponível para diversas plataformas de en-
tretenimento. Como diferentes plataformas têm difer-
entes especi\ufb01cações ou ainda usam diferentes tipos de
hardware, atingir a portabilidade pode não ser triv-
ial. Entre as técnicas de portabilidade, a mais us-
ada acaba sendo a abstração dos aspectos especí\ufb01cos à
plataforma \ufffd principalmente o hardware, mais especi-
\ufb01camente primitivas de desenho em tela ou armazena-
mento em disco \ufffd da lógica do jogo. Assim, toda ou
boa parte da camada lógica é reusada, enquanto as ca-
madas de níveis mais baixos de abstração são portadas
para as diferentes plataformas.
Já atributos de qualidade organizacionais, por outro lado, são
consequência de políticas ou procedimentos organizacionais.
Em outras palavras, o sistema deve respeitar padrões ou re-
gras impostas por uma ou mais organizações envolvidas para
atender a esses requisitos.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
84
CHAPTER 4. FUNDAMENTOS DE
ARQUITETURA DE SOFTWARE
Exemplo 4.26
Se um sistema que servirá de infraestrutura será pro-
duzido para uma organização ou empresa que já possui
diversos sistemas que implementam o padrãoWeb Ser-
vice Distributed Management (Gerência Distribuída de
Web Services), a adoção desse padrão na arquitetura
do novo sistema é um requisito a ser atendido, por ser
imposto pela organização em questão. A adoção desse
padrão implica na disponibilização viaWeb Service de
serviços de ativação, consulta e desativação do sistema
ou parte dele, que terá impacto na arquitetura do sis-
tema como um todo.
Por \ufb01m, restam os chamados atributos de qualidade externos,
que não são impostos pelo processo de desenvolvimento nem
pelo projeto do sistema. Neles se encaixam leis impostas sobre
software ou requisitos de interoperabilidade entre sistemas.
Exemplo 4.27
Para o SASF atrair usuários de outros sistemas (p.
ex., redes sociais), percebeu-se que ele deve ser capaz
de agregar o per\ufb01l do usuário existente nos outros sis-
temas. Esse tipo de agregação (que permitiria não só a
visualização dos per\ufb01s compartilhados entre os diver-
sos serviços, mas também sua edição), impactará pro-
fundamente na arquitetura do sistema, uma vez que
será necessário organizar dados locais e dados compar-
tilhados por terceiros, além de manter todos os dados
sincronizados ao longo do tempo e das eventuais mod-
i\ufb01cações.
4.7.3.1 Medindo atributos de qualidade
É importante notar que para se de\ufb01nir o sucesso do software em
relação aos atributos de qualidade, precisamos medir o quanto
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
85
o sistema satisfaz esses atributos. Em primeiro momento, essa
medição de sucesso parece simples: \ufffdbasta considerar o valor
esperado do atributo de qualidade, digamos, `o sistema deve
estar disponível 99,999% do tempo'; medir se ele atinge os val-
ores esperados, `num período de 1 ano, o sistema esteve parado
por 1 hora'; e, por \ufb01m, atestar seu sucesso ou fracasso: `1 hora
equivale a 0,0114% e, portanto, o sistema não atendeu ao req-
uisito de disponibilidade.\ufffd ' No entanto, não é fácil estabele-
cer métricas quantitativas para atributos de qualidade como
testabilidade, usabilidade, ou manutenibilidade são bem mais
difíceis de estabelecer métricas quantitativas e, portanto, não
é fácil atestar o sucesso em relação a esses atributos.
4.7.3.2 Relacionando atributos de qualidade
Além de serem difíceis de medir, atributos de qualidade se
relacionam entre si de forma que um pode permitir, ajudar ou
mesmo di\ufb01cultar o atendimento de outros. Essas relações entre
atributos acontecem mesmo que eles sejam de tipos diferentes.
No Exemplo 4.28, notamos que o atributo de qualidade desem-
penho está afetando os níveis de testabilidade e entendimento
do sistema.
Exemplo 4.28
Uma forma de aumentar o desempenho do sistema é
diminuir os níveis de indireção usados na comunicação
entre dois elementos quaisquer no SASF. Um caso sim-
ples seria fazer com que algumas chamadas presentes
na camada de apresentação usassem diretamente a ca-
mada de persistência, sem usar a lógica de negócio.
Essa medida tornaria as chamadas da apresentação
mais rápidas, uma vez que menos chamadas remotas
seriam executadas. No entanto, quando diminuímos
as camadas de abstração entre dois elementos inicial-
mente distintos, aumentamos o acoplamento entre eles
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
86
CHAPTER 4. FUNDAMENTOS DE
ARQUITETURA DE SOFTWARE
e, portanto, di\ufb01cultamos seu entendimento ou mesmo
sua testabilidade.
Já no exemplo a seguir, o atributo de segurança afeta dois
atributos distintos: o desempenho e a usabilidade do sistema.
Exemplo 4.29
Uma forma de aumentar a segurança de um sistema
operacional é requerer autorização do usuário para a
realização de certas operações. No entanto, o processo
de veri\ufb01cação do usuário (além de todos os elemen-
tos e abstrações do sistema relacionados à segurança:
unidade certi\ufb01cadora, unidade veri\ufb01cadora, listas de
controle de acesso, entre outros.) deteriorará o desem-
penho da aplicação, dado que consumirá recursos que
poderiam ser destinados à operação em si - não a um
aspecto dito não-funcional dela. Além disso, o sistema
vai \ufb01car menos usável, uma vez que pedirá uma ver-
i\ufb01cação, seja senha, impressão digital, ou certi\ufb01cado,
para cada operação sensível a ser executada.
O principal motivo que faz com que atributos de qualidade con-
\ufb02item é por eles serem impostos por mais de um interessado no
software. Assim, como preocupações de diferentes interessados
podem con\ufb02itar, os atributos de qualidade também con\ufb02itarão.
Assim, cabe à arquitetura resolver, ponderar, ou ao menos me-
diar esses con\ufb02itos, considerando assim os diversos trade-o\ufb00s
envolvidos para se alcançar os objetivos do software. O exem-
plo seguinte mostra atributos de desempenho e portabilidade
con\ufb02itando.
Exemplo 4.30
Um cliente de um jogo para celular requisitou que o
jogo tivesse um bom desempenho nos diversos apar-
elhos disponíveis no mercado. No entanto, o gerente
de projeto sugere que o tempo gasto para portar o
software de um aparelho para outro seja mínimo, uma
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
87
vez que o prazo do projeto em questão é curto. Pode-
mos então observar dois requisitos con\ufb02itantes: desem-
penho e portabilidade.
Esse con\ufb02ito ocorre porque as técnicas para alcançar
ambos os requisitos são divergentes. Para alcançar
portabilidade, normalmente é necessário o uso de diver-
sas camadas de abstração, principalmente de hardware.
No entanto, a adição dessas camadas de abstração sig-
ni\ufb01ca uma perda em desempenho, uma vez que aumen-
tará o número de chamadas necessárias para se realizar
qualquer operação. E isso se torna ainda mais signi-
\ufb01cativo no caso dos aparelhos celulares, que podem ser
limitados em termos de recursos computacionais como
processador ou memória.
Assim, a arquitetura do sistema terá que ponderar en-
tre as técnicas disponíveis de modo que atenda em
parte cada requisito e, assim, ambos os interessados
\ufb01quem satisfeitos.
Dois outros atributos de qualidade que normalmente con\ufb02itam
são os atributos usabilidade e segurança, como veremos no ex-
emplo a seguir. Nesse caso, ambos os atributos foram requisi-
tados pelo mesmo interessado, o usuário, e, mesmo assim, se
tornaram con\ufb02itantes.
Exemplo 4.31
Quando usando um sistema operacional,