Revisões técnicas formais

III.2 PROJETO DE SISTEMA [Rumbaugh-94]

É durante o projeto de Sistemas que o sistema é organizado em sub-sistemas e são tomadas decisões estratégicas de alto nível.

Decisões a serem tomadas:

1. 
   Organizar o sistema em subsistemas
   

Cada um dos principais componentes de um sistema é denominado subsistema. Cada subsistema compartilha propriedades comuns como funcionalidade similar ou execução no mesmo tipo de hardware. Cada subsistema tem uma bem definida interface com o restante do sistema.

O relacionamento entre dois subsistemas pode ser do tipo cliente-servidor ou do tipo homogêneo.

Cliente-servidor: o cliente convoca o servidor, que executa algum serviço e fornece um resultado.

Homogêneo: cada um dos subsistemas pode chamar os outros. A comunicação de um sistema com outro não é necessariamente seguida por uma resposta imediata.

2. 
   Alocar subsistemas a processadores e tarefas
   

Cada subsistema concorrente deve ser alocado por exemplo a uma unidade de hardware ou a um processador de emprego geral.

Esta decisão dependerá de se necessitar de um desempenho melhor do que aquele dado por uma única CPU ou também pelo fato de certas tarefas serem necessárias em localizações físicas específicas.

Deve-se escolher a organização e a forma de conexões entre as unidades físicas.

3. 
   Escolher uma abordagem para o gerenciamento de depósitos de dados
   

Arquivos, SGDBs ?

4. 
   Determinar mecanismos para controlar acesso a recursos globais
   

Exemplos de recursos globais são unidades físicas, como processadores, unidades de fita e satélites de comunicação.

5. 
   Escolher uma implementação de controle de software
   

Exemplos de controle:

Sistemas seqüenciais baseados em procedimentos: o controle reside no código do programa.

Sistemas baseados em eventos: o controle reside em um despachante ou monitor provido pela linguagem, subsistema ou sistema operacional.

Sistemas concorrentes: o controle reside de modo concorrente em diversos objetos independentes, sendo cada um uma tarefa separada. Uma tarefa pode esperar pelas entradas, mas as outras continuam. O sistema operacional resolve os conflitos de escalonamento entre tarefas.

6. 
   Tratar das condições limites
   

Por exemplo, falhas: deve-se determinar as saídas para os casos de erros fatais.

7. 
   Ajustar o equilíbrio das prioridades
   

Deve-se determinar qual a importância relativa dos diversos critérios a serem adotados uma vez que há metas desejáveis mas inviáveis por algum motivo.
O documento de projeto de sistema gerado a partir desta etapa deverá conter a estrutura básica do sistema e as decisões estratégicas de alto nível

III.3 PROJETO DE ARQUITETURA

O Projeto de Arquitetura tem como objetivo principal o desenvolvimento de uma estrutura de programa modular e representar os relacionamentos de controle entre os módulos. Este projeto funde a estrutura de programa e a estrutura de dados, definindo interfaces que possibilitam que os dados fluam através do programa.

Os métodos de projeto encorajam o engenheiro de software a se concentrar no projeto arquitetural antes de se concentrar nos demais detalhes.
Cada método de projeto introduz uma heurística e uma notação únicas, bem como uma visão do que considera como qualidade de projeto. Contudo cada um desses métodos tem uma série de características em comum:

• 
  Um mecanismo para a tradução da representação do domínio da informação numa representação de projeto
  
• 
  Uma notação para representar os componentes funcionais e suas interfaces.
  
• 
  Heurísticas para refinamento e divisão em partições
  
• 
  Diretrizes para avaliação da qualidade
  

O método apresentado a seguir é o Projeto Estruturado descrito em [Page-Jones-88]

III.3.1 NOTAÇÃO PARA REPRESENTAR A ESTRUTURA DE UM PROGRAMA

Módulo:



Chamada:

A

Chefe (Módulo A chama módulo B)

Chamada

B

Subordinado (Módulo B executa sua função e o controle retorna ao comando em A imediato ao da chamada de B)

Continuação:






Iteração:

A

C1 Módulo A chama B enquanto C1 é verdadeira

B

Seleção:

A

C2 Se C2 for verdadeira então A chama B

B

Tipos de interface:

Item de dado Item de controle

A seguir é apresentado um exemplo de estrutura de programa utilizando a notação descrita acima. Módulos que contém duas linhas são módulos que estão sendo reusados.

III.3.2 QUALIDADE DE UM BOM PROJETO

A qualidade do projeto pode ser avaliada através dos seguintes critérios:

• 
  Coesão
  
• 
  Acoplamento
  
• 
  Fatoração
  
• 
  Divisão da decisão
  
• 
  Fan-out
  
• 
  Fan-in
  

a) Coesão

É a medida de quanto os elementos de um módulo estão relacionados.

A idéia é que os componentes de um sistema reunidos num módulo sejam muito relacionados entre si.
Tipos de coesão:

• 
  Coincidental:
  

Os elementos não se relacionam, parecendo que foram organizados de forma arbitrária. O motivo pode ser, por exemplo, para se ter um tempo de resposta melhor.

• 
  Lógica:
  

Os elementos foram logicamente colocados juntos. Isto é eles executam uma classe de funções similares ou relacionadas,.

Ex: módulo de entrada de dados, de tratamento de erros, de validação

Conseqüência: Passagem de parâmetros de controle. Provoca acoplamento de controle.

• 
  Temporal:
  

Os elementos do módulo estão relacionados logicamente no tempo, ou seja, estão reunidos por serem realizados num mesmo momento. Esta coesão é melhor que a lógica porque neste caso todos os elementos são executados.

• 
  Procedimental:
  

Os elementos do módulo realizam funções diferentes e estão unidos por afinidade de controle. Os elementos estão juntos para aproveitar por exemplo um loop. Os dados passados e os dados recebidos possuem pouca ou nenhuma relação entre si.

• 
  Comunicacional:
  

Os elementos do módulo operam o mesmo arquivo ou dados de entrada e saída.

Requer passagem de controle.

Ex: módulo que lê, inclui, exclui e modifica registro em um arquivo.

Atividades do módulo podem ser independentes e executadas em qualquer ordem.

• 
  Seqüencial:
  

Os elementos cumprem funções diferentes nas quais os dados de saída de um elemento são a entrada para o elemento seguinte.

Ex: ler dados, calcular salário e imprimir

• 
  Funcional:
  

Os elementos executam uma só função.

Ex: calcular fatorial

b) Acoplamento

É o grau de interdependência entre dois módulos.

O objetivo é minimizar o acoplamento, tornando os módulos tão independentes quanto possível. Um acoplamento baixo, entre módulos, indica um sistema bem particionado.

Pode ser obtido de 3 maneiras:

• 
  Eliminando relações desnecessárias
  
• 
  Reduzindo o número de relações necessárias
  
• 
  Enfraquecendo a dependência das relações necessárias
  

Para que se quer acoplamento fraco ?

• 
  Quanto menos conexões entre módulos, menor a chance do efeito em cadeia (um erro num módulo aparece como sintoma num outro).
  
• 
  Queremos ser capazes de trocar um módulo com um mínimo de risco de trocar outro módulo
  

Tipos de acoplamento:

• 
  Dados
  

Quando os módulos se comunicam por parâmetros, sendo cada parâmetro um dado único ou uma tabela homogênea (uma tabela na qual cada entrada contém o mesmo tipo de informação)

• 
  Imagem
  

Dois módulos são ligados por imagem se eles se referem à mesma estrutura de dados (um grupo composto de dados, como um registro)

Problema: quando envio para um módulo um registro completo no qual só alguns itens de dados serão usados estou arriscando que os outros itens sofram alteração. O ideal é enviar somente o que é necessário a cada módulo.

• 
  Controle
  

Dois módulos são acoplados por controle se um passa para o outro um grupo de dados destinados a controlar a lógica interna do outro.

• 
  Comum
  

Quando dois módulos se referem a mesma área de dados. O fato de vários módulos poderem acessar a mesma área de dados dificulta a manutenção já que quando há um erro fica difícil saber quem foi o responsável. Dificulta também a reutilização porque o módulo usa um nome de variável fixo.

Se o tamanho de um dado global tem que ser mudado, como saber os módulos que serão afetados ?

• 
  Conteúdo
  

Quando um módulo desvia a seqüência de instruções para dentro de outro ou quando um módulo altera um comando do outro.
c) Fatoração:

É a separação de uma função contida em um módulo em um novo módulo próprio.

Objetivos:

• 
  Evitar de se ter a mesma função em mais de um módulo
  
• 
  Tornar o sistema mais compreensível
  
• 
  Permitir modificações mais localizadas
  

d) Divisão da decisão

Uma decisão tem duas partes:

• 
  O reconhecimento de qual ação tomar
  
• 
  A execução da ação
  

Quando o reconhecimento e a ação não se encontram no mesmo módulo há uma divisão da decisão.

Recomendação: A execução deve ser mantida tão perto quanto possível do reconhecimento para que a informação reconhecida não tenha que percorrer um longo caminho (normalmente como um flag migrante) para ser processada.
e) Fan-out

Representa o número de subordinados de um módulo. Recomenda-se um número de 7 + 2 subordinados.

f) Fan-in

Representa o número de superiores imediatos que um módulo possui. Quanto maior o número de superiores melhor.