Arquitetura_de_Software
262 pág.

Arquitetura_de_Software


DisciplinaAnálise de Sistemas II85 materiais1.124 seguidores
Pré-visualização50 páginas
para a implementação dos mó-
dulos ou qual ferramenta deve ser utilizada para integração,
caso seja uma decisão executiva.
A descrição pode ser representada usando diversas linguagens,
podendo ser textuais ou grá\ufb01cas e formais ou informais. A es-
colha da linguagem que será utilizada na descrição depende dos
objetivos da decisão e dos stakeholders interessados. Se, entre
os seus objetivos, queremos que a decisão permita também ger-
ação automática de parte da implementação, análise baseada
em modelos ou simulações, ou veri\ufb01cação de conformidade, a
descrição deve utilizar linguagens formais ou semiformais que
facilitam estas atividades. Por outro lado, se esperamos que a
decisão apenas informe que elementos devem estar na arquite-
tura e suas características, mas não esperamos geração, análise
ou veri\ufb01cação automáticas, linguagens semiformais ou mesmo
informais podem ser utilizadas, como a língua Portuguesa ou
diagramas \ufffdcaixas e setas\ufffd, desde que a ambiguidade seja evi-
tada por meio de legendas ou explicações mais detalhadas.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
214
CHAPTER 8. DOCUMENTAÇÃO DA
ARQUITETURA
Vale observar que tanto a utilização de linguagens formais,
quanto a utilização de linguagens informais na descrição pro-
porcionam vantagens e desvantagens que devem ser consid-
eradas durante o processo de documentação. Ao utilizarmos
linguagens formais, permitimos a automatização de processos,
que podem poupar bastante trabalho durante o desenvolvi-
mento. Por outro lado, não são todos os stakeholders que as
entendem perfeitamente, podendo restringir assim o entendi-
mento da decisão.
As linguagens informais, por sua vez, têm como vantagem a
maior facilidade de entendimento por parte dos stakeholders
(inclusive não-técnicos, como gerentes, clientes e até usuários).
No entanto, o entendimento só é facilitado se a descrição evitar
ambiguidades, que são comuns em linguagens informais.
Uma forma de se conseguir mais vantagens nas decisões se-
ria utilizar tanto linguagens formais quanto informais nas de-
scrições das decisões. Nada impede que isso seja feito, obtendo
assim precisão na descrição, possibilidade de atividades autom-
atizadas, e entendimento por parte dos stakeholders técnicos
e não-técnicos. O problema reside apenas na grande quanti-
dade trabalho empregado ao descrever cada decisão com duas
ou mais linguagens e, ainda por cima, ter que manter a con-
sistência da descrição entre elas.
A seguir, mostramos a descrição da decisão arquitetural já ap-
resentada no Exemplo 10 do capítulo de fundamentos (Exem-
plo 4.10) usando diferentes linguagens diferentes. O primeiro
exemplo mostra a decisão escrita em Português.
Exemplo 8.13
[Decisão Arquitetural 001] A arquitetura do SASF é
dividida em três camadas lógicas: apresentação, lógica
de negócio e persistência de dados. A camada de apre-
sentação se comunica apenas com a lógica de negócio e
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
215
apenas a lógica de negócio de comunica com a camada
de persistência de dados.
Já o exemplo a seguir mostra a descrição usando também um
código que pode ser interpretado pela ferramenta DesignWiz-
ard
9
e que permite a veri\ufb01cação automática de conformidade
do código implementado com a arquitetura.
Exemplo 8.14
[Decisão Arquitetural 001] A arquitetura do SASF é
dividida em três camadas lógicas: apresentação, lógica
de negócio e persistência de dados, que serão mapeadas
respectivamente para os pacotes: com.sasf.webui,
com.sasf.service, com.sasf.storage. Os testes presentes
na listagem a seguir (p. 215), que podem ser execu-
tados usando o DesignWizard, descrevem as regras de
comunicação entre as camadas.
public class ThreeTierDesignTest extends TestCase {
public void test_communication_web_ui_and_services() {
String sasfClassesDir =
System.getProperties(&quot;sasf.classes.directory&quot;);
DesignWizard dw = new DesignWizard(sasfClassesDir);
PackageNode services =
dw.getPackage(&quot;com.sasf.service&quot;);
PackageNode webUI = dw.getPackage(&quot;com.sasf.webui&quot;);
Set<PackageNode> callers =
services.getCallerPackages();
for (PackageNode caller : callers) {
assertTrue(caller.equals(webUI));
}
}
9
O artigo Design tests: An approach to programmatically check your
code against design rules [21], de Brunet et al contém mais informações
sobre o DesignWizard.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
216
CHAPTER 8. DOCUMENTAÇÃO DA
ARQUITETURA
public void test_communication_services_and_storage() {
String sasfClassesDir =
System.getProperties(&quot;sasf.classes.directory&quot;);
DesignWizard dw = new DesignWizard(sasfClassesDir);
PackageNode services =
dw.getPackage(&quot;com.sasf.service&quot;);
PackageNode storage =
dw.getPackage(&quot;com.sasf.storage&quot;);
Set<PackageNode> callers =
storage.getCallerPackages();
for (PackageNode caller : callers) {
assertTrue(caller.equals(services));
}
}
}Testes para comunicação entre tiers.
8.2.4.2 Objetivo
O objetivo da decisão serve para registrarmos o motivo da de-
cisão estar sendo tomada. Como decisões de design são con-
duzidas por requisitos, sejam eles funcionais ou de qualidade, a
identi\ufb01cação dos requisitos deve estar presente neste atributo.
Os objetivos das decisões arquiteturais ajudam na rastreabili-
dade da arquitetura.
No Exemplo 8.15, percebemos duas formas de menção aos req-
uisitos implementados pela decisão. A primeira forma é pre-
sença o identi\ufb01cador do requisito de qualidade, RNF-01. Já a
outra forma é uma breve descrição do requisito alcançado.
Exemplo 8.15
(continuação da [Decisão Arquitetural 001])
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
217
Objetivo: Atendimento ao requisito não-funcional:
RNF-01. Esta divisão diminui o acoplamento entre os
elementos internos da arquitetura, facilitando o desen-
volvimento e a manutenção.
8.2.4.3 Fundamentação
Uma decisão arquitetural deve ser tomada com alguma fun-
damentação, seja ela uma análise das alternativas de design,
baseada na experiência prévia do arquiteto, ou baseada em
padrões de design. Esta fundamentação resulta no julgamento
das vantagens e desvantagens das alternativas e servem para
justi\ufb01car a solução proposta.
No atributo fundamentação, registramos a justi\ufb01cativa da de-
cisão para que haja um registro histórico das motivações e
considerações feitas pelo arquiteto para chegar à solução de
design. Este registro é essencial para que este tipo de infor-
mação não seja esquecido ao longo do ciclo de vida do software,
pois é importante para o seu processo de evolução.
Por exemplo, durante uma atividade de refatoração do código,
um novo desenvolvedor pode se interessar pelo motivo de um
módulo ter sido criado aparentemente de forma desnecessária.
Se não existir algum tipo de registro do motivo para existência
do módulo em questão, o novo desenvolvedor pode, simples-
mente, modi\ufb01cá-lo ou mesmo removê-lo ignorante dos efeitos
que pode causar no design.
A fundamentação é normalmente feita por meio de uma de-
scrição textual, mas deve possuir referências a outros documen-
tos e a outras decisões arquiteturais relacionadas. O exemplo
a seguir ilustra a fundamentação de uma decisão arquitetural.
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
218
CHAPTER 8. DOCUMENTAÇÃO DA
ARQUITETURA
Exemplo 8.16
(continuação da [Decisão Arquitetural 001])
Motivação: Projetar os elementos internos do sistema
de modo que cada um pertença a apenas uma camada
lógica ajuda a aumentar a coesão e diminuir o acopla-
mento. A coesão aumenta,