Arquitetura_de_Software
262 pág.

Arquitetura_de_Software


DisciplinaAnálise de Sistemas II85 materiais1.123 seguidores
Pré-visualização50 páginas
Isso quer dizer que os dados submetidos a ele não serão
guardados em um único servidor, mas em vários. De
forma simpli\ufb01cada, o design do HBase de\ufb01ne dois tipos
de entidades no sistema: o data node, que é o subsis-
tema que armazena os dados, e o master node, que é
o subsistema que sabe em quais data nodes os dados
foram escritos e podem ser recuperados. Na primeira
versão do HBase, só existia um master node que co-
ordenava todos os data nodes. Assim, para recuperar
ou escrever dados no HBase, um cliente realizava os
seguintes passos: primeiro, o cliente se comunicava com
o master node a \ufb01m de conseguir, de acordo com uma
chave
3
, o endereço do data node em que ele pode re-
alizar a operação desejada (leitura ou escrita). Em
seguida, o master node, que coordena onde os dados
devem \ufb01car, retorna o endereço do data node que dev-
eria possuir dados para referida chave. A partir daí, o
cliente, já com o endereço, se comunicava diretamente
com o data node e realizava a operação desejada (es-
crita ou leitura).
2
Apache HBase: urlhttp://hbase.org
3
Os dados são inseridos no HBase na forma (chave,valor).
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
12
CHAPTER 2. INTRODUÇÃO A
DESIGN DE SOFTWARE
Se avaliarmos este design, podemos perceber duas car-
acterísticas do HBase. A primeira, é que ele não adota
o uso de um cliente magro (thin client). Com isso, a
implementação e con\ufb01guração do cliente se torna mais
complexa, uma vez que o cliente precisa conhecer o pro-
tocolo de escrita e leitura do HBase, além de precisar
acessar tanto o master node quanto os data nodes. Isto
di\ufb01culta o desenvolvimento, a operabilidade e a even-
tual evolução do software, uma vez que mudanças no
protocolo afetam clientes e servidores. Além disso, por
possuir apenas um master node, a funcionalidade do
HBase \ufb01ca condicionada à sua disponibilidade. A\ufb01nal,
se o master node estiver inacessível, nenhum cliente
poderá ler ou escrever no sistema, o que o torna um
ponto único de falhas.
2.1.1 O que é Design de Software
Para de\ufb01nir design de software, alguns autores o fazem em dois
sentidos distintos: quando design de software é usado como
produto e quando é usado como processo. Quando usado no
primeiro sentido, o termo design de software indica o produto
que emerge do ato (ou processo) de projetar um sistema de
software e sendo assim algum documento ou outro tipo de rep-
resentação do desejo do projetista (ou designer). Esse produto
é o resultado das decisões do designer para formar uma ab-
stração do sistema que é desejado no mundo real. Existem di-
versas formas de como representar essa abstração do sistema.
Podemos citar, por exemplo, desenhos usando caixas e setas,
textos descritivo, ou ainda uso de linguagens ou ferramentas
criadas para este propósito, como linguagens de modelagem
de software, redes de petri, pseudocódigo, etc. Já quando o
termo é usado no segundo sentido, fazer design indica o pro-
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
13
cesso seguido para se obter um projeto. Esse é um processo que
faz parte do processo de desenvolvimento e que é orientado aos
objetivos do software. Ele deve ser realizado tendo em mente
os diversos stakeholders do sistema e deve ser fundamentado
no conhecimento do designer sobre o domínio do problema.
A partir da visão de design como artefato, podemos observar
que ele deve descrever diversos aspectos do software para que,
assim, possibilite sua construção. Entre estes aspectos, estão:
\u2022 a estrutura estática do sistema, incluindo a hierarquia de
seus módulos;
\u2022 a descrição dos dados a serem usados;
\u2022 os algoritmos a serem usados;
\u2022 o empacotamento do sistema, em termos de como os mó-
dulos estão agrupados em unidades de compilação; e
\u2022 as interações entre módulos, incluindo as regras de como
elas devem acontecer e porque elas acontecem.
Podemos perceber que, apesar dos exemplos anteriores de-
screverem apenas parte do design de dois sistemas, eles
mostram boa parte dos aspectos que esperamos no design de
um software.
Por \ufb01m, citamos uma de\ufb01nição de design que engloba todos
estes aspectos:
De\ufb01nição 2.1: 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
4
4
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>
14
CHAPTER 2. INTRODUÇÃO A
DESIGN DE SOFTWARE
2.1.2 Características de Design de Software
Projetar os diversos aspectos de um sistema de software é um
processo trabalhoso. No entanto, pode proporcionar diversos
benefícios.
Design de software permite avaliação prévia. Como desen-
volver software custa tempo e dinheiro, não parece sensato
alguém investir seus recursos no desenvolvimento de um sis-
tema que não soluciona os problemas propostos pelos interes-
sados. Dessa maneira, a avaliação prévia do sistema se torna
imprescindível para garantir que ele alcance os objetivos desses
interessados. Como o design descreve diversos aspectos que es-
tarão presentes no sistema quando construído, ele permite esse
tipo de avaliação. Além disso, fazer o design de um sistema é,
geralmente, mais barato que construí-lo.
Exemplo 2.2
Considerando o sistema do Exemplo 2.1 e que um
de seus objetivos fosse a alta disponibilidade, pode-
mos avaliar que design apresentado não seria a melhor
solução para o objetivo proposto. Isso ocorre porque
seu design possui um ponto único de falhas, que é uma
característica indesejável para sistemas que buscam
alta disponibilidade. Note ainda que não foi necessário
ter o HBase desenvolvido para percebermos esse prob-
lema (na época em que implementava tal design, ele
possuía cerca de cem mil linhas de código e alguns anos
de desenvolvimento e, portanto, não sendo um software
de desenvolvimento trivial), bastou apenas estudarmos
seu design.
Design de software estimula modelagem. Ao modelar um sis-
tema, o designer se concentra no domínio do problema, igno-
rando temporariamente detalhes menos signi\ufb01cativos para se
alcançar a solução. Isso facilita na separação da complexidade
essencial da complexidade acidental do problema. E, como já
Available for free at Connexions
<http://cnx.org/content/col10722/1.9>
15
dito por Fred Brooks em The Mythical Man-Month, essa sep-
aração é bené\ufb01ca para a qualidade \ufb01nal do sistema projetado.
Design de software envolve planejamento. Uma vez que o de-
sign serve de guia para a construção do sistema, o designer deve
então antecipar o que será necessário para tanto. Esse plane-
jamento ajuda na estimativa dos diversos custos envolvidos no
desenvolvimento do sistema. Entre esses custos, podemos citar:
\u2022 Quanto tempo durará todo o desenvolvimento,
\u2022 Quantos desenvolvedores serão necessários para o módulo
A,
\u2022 Se comprado, quanto custará o módulo B, e se for imple-
mentado,
\u2022 Ou qual será o custo total do desenvolvimento do sistema.
Design de software facilita a comunicação, pois contém con-
hecimento sobre o sistema que pode ser gravado, transmitido
e discutido entre os interessados. Um caso bem comum é o de
apresentar um sistema a novos membros de um time de desen-
volvimento. Informações valiosas, como por exemplo, quais os
principais módulos e seus diversos comportamentos, lhes po-
dem ser passadas através do design do sistema antes de mostrá-
los o código-fonte. Dessa maneira, essas informações de alto
nível de abstração ajudarão