Coesao Acoplamento

PROJETO ESTRUTURADO DE SISTEMAS
FACULDADE DE TECNOLOGIA DE BIRIGUÍ - SP
ORÁCULO CONSULTORIA DE SISTEMAS - RJ
Organizada por Gustavo Miranda Araújo - 1996

Revista por Alfredo Martins Muradas - 1997
Projeto Estruturado de Sistemas
ÍNDICE
1. INTRODUÇÃO 1
1.1 Proposta para o Projeto 1
1.2 Os fundamentos do projeto 3

1.2.1 Contexto do Projeto 3
1.2.2 Principais sintomas de um projeto inadequado 3
1.3 Critérios de Qualidade do Projeto 4

1.3.1 Completeza 4
1.3.2 Manutenibilidade 4
1.3.3 Performance 4
1.3.4 Segurança 5
1.3.5 Interatibilidade 5
1.3.6 Confiabilidade 6
1.3.7 Economia 6
2. FASES DO PROJETO 7
2.1 Modelo de Implementação do Sistema 7

2.1.1 Modelo de Processador 7
2.1.2 Modelo de Tarefa 9
2.2 Modelo de Implementação de Programa 10
3. DIAGRAMA DE ESTRUTURA MODULAR 11
3.1 Introdução 11
3.2 Componentes do DEM 12

3.2.1 Módulo 12
3.2.2 Hierarquia de Módulos 13
3.2.3 Tipos de Módulos 16
3.2.4 Conector 17
3.2.5 Especificação de Módulos 19
3.3 Critérios de Qualidade do DEM 20

3.3.1 Acoplamento 20
3.3.2 Comparação dos Tipos de Acoplamento 24
3.3.3 Coesão 25
3.3.4 Determinação do Tipo de Coesão 30
3.4 Diretrizes Adicionais do Projeto 32

3.4.1 Factoring 32
3.4.2 Divisão de Decisão 32
3.4.3 Formas de um Modelo 34
3.4.4 Informações de Erro 37
3.4.5 FAN-OUT e FAN-IN 37
I
3.5 Estratégia para Derivar o DFD para o DEM 40

3.5.1 Análise de Transformação 40
3.5.2 Análise de Transação 43
II
LISTA DE FIGURAS
FIGURA 3.1: SIMBOLOGIA DE REPRESENTAÇÃO DE MÓDULO 12

FIGURA 3.2: SIMBOLOGIA DE REPRESENTAÇÃO DE MÓDULO PRÉ-DEFINIDO 12
FIGURA 3.3: HIERARQUIA DE MÓDULOS 13
FIGURA 3.4: EXEMPLO DE UMA HIERARQUIA ENTRE MÓDULOS 14
FIGURA 3.5: CHAMADA CONDICIONAL DE MÓDULOS 15
FIGURA 3.6: CHAMADA REPETITIVA DE MÓDULOS 15
FIGURA 3.7: TIPO DE PARÂMETROS ENTRE MÓDULOS 16
FIGURA 3.8: TIPOS DE MÓDULOS 17
FIGURA 3.9: SIMBOLOGIA PARA CONECTORES 18
FIGURA 3.10: EXEMPLO DE PARTE DE UM MODELO 18
FIGURA 3.11: EXEMPLO DO USO DE CONECTOR DE PÁGINA 19
FIGURA 3.12:EXEMPLO DE ACOPLAMENTO DE DADOS 21
FIGURA 3.13: EXEMPLO DE ACOPLAMENTO DE IMAGEM 21
FIGURA 3.14: EXEMPLO DE ACOPLAMENTO DE CONTROLE 22
FIGURA 3.15: EXEMPLO DE ACOPLAMENTO COMUM 23
FIGURA 3.16: EXEMPLO DE ACOPLAMENTO DE CONTEÚDO 24
FIGURA 3.17: EXEMPLO DE COESÃO FUNCIONAL 25
FIGURA 3.18:EXEMPLO DE COESÃO SEQUENCIAL 26
FIGURA 3.19: EXEMPLO DE COESÃO COMUNICACIONAL 27
FIGURA 3.20: EXEMPLO DE COESÃO PROCEDURAL 28
FIGURA 3.21: EXEMPLO DE COESÃO TEMPORAL 29
FIGURA 3.22: EXEMPLO DE COESÃO LÓGICA 29
FIGURA 3.23: EXEMPLO DE COESÃO COINCIDENTAL 30
FIGURA 3.24: ESTRATÉGIA PARA IDENTIFICAÇÃO DOS TIPOS DE COESÃO 30
FIGURA 3.25: EXEMPLO DE UM DIAGRAMA COM DIVISÃO DE DECISÃO 33
FIGURA 3.26: EXEMPLO DE UM DIAGRAMA SEM DIVISÃO DE DECISÃO 34
FIGURA 3.27: FORMATO DE UM MODELO INPUT-DRIVEN 35
FIGURA 3.28: FORMATO DE UM MODELO OUTPUT-DRIVEN 36
FIGURA 3.29: FORMATO DE UM MODELO BALANCEADO 37
FIGURA 3.30: EXEMPLO DE UM MODELO COM ALTO FAN-OUT 38
FIGURA 3.31: EXEMPLO DE UM MODELO COM ALTO FAN-IN 39
FIGURA 3.32: EXEMPLO DE DFD COM A IDENTIFICAÇÃO DO CENTRO DE TRANSFORMAÇÃO 41
FIGURA 3.33: EXEMPLO DE UM DEM DERIVADO A PARTIR DE UM DFD 42
FIGURA 3.34: EXEMPLO DE UM DEM DERIVADO A PARTIR DE UM DFD 43
FIGURA 3.35: EXEMPLO DE DFD COM LIGAÇÕES ENTRE PROCESSOS VIA DEPÓSITO DE
DADOS 44
FIGURA 3.36 FIGURA 3.36: EXEMPLO DE UTILIZAÇÃO DE ANÁLISE DE TRANSAÇÃO 44
III
1. INTRODUÇÃO
1.1 Proposta para o Projeto
Projeto Estruturado de Sistemas é a atividade de transformação das necessidades

do usuário, provenientes da fase de Análise, em um plano de implementação através da
automação eletrônica.
Nesta fase, deixa-se de ter a tecnologia perfeita, passando a levar em

consideração o hardware e software com todas as suas limitações.
Projeto estruturado é uma abordagem disciplinada de projeto de sistemas

computadorizados, uma atividade que no passado foi notoriamente acidentada e cheia de
problemas. O projeto estruturado é uma das respostas para as falhas do passado,
possuindo cinco aspectos:
1) Permite que a forma do problema guie a forma da solução.

2) Procura a resolução da complexidade dos grandes sistemas através da
segmentação de um sistema em “caixas pretas”, e pela organização dessas “caixas pretas”
em uma hierarquia conveniente para aimplementações computadorizadas.
3) Utiliza ferramentas, especialmente gráficas, para tornar os sistemas de fácil
compreensão.
4) Oferece um conjunto de estratégias para desenvolver o projeto da solução de
uma declaração bem definida do problema.
5) Oferece um conjunto de critérios para avaliar a qualidade de um dado projeto-
solução com respeito ao problema a ser resolvido.
Para tornar fácil o entendimento o Projeto Estruturado se utiliza basicamente de

duas ferramentas principais: O pseudocódigo e o Diagrama de Estruturas.
O pseudo código é uma linguagem de especificação informal que não tem a
intenção de ser executado em uma máquina, mas de ser usado na organização dos
pensamentos dos programadores antes da codificação. Apesar de ser uma ferramenta da
programação estruturada ela se torna muito útil na especificação das rotinas detalhadas a
serem executadas pelas caixas pretas.
A outra ferramenta é o diagrama de estruturas que ilustra a segmentação de um
sistema em módulos mostrando a sua hierarquia, organização e comunicação. A
vantagem do uso do diagrama de estruturas, que é a principal ferramenta do projeto
estruturado, estão no fato desta ferramenta ser:
• gráfica
• particionável
• rigorosa mas flexível
• entrada usual para a implementação estruturada
• documentação do sistema
1
• um auxílio para a manutencão e modificações
Qualquer informação que não puder ser descrita pelo diagrama de estrutura pode
ser suprida por pseudo código ou por alguma outra descrição de módulos do gráfico de
estrutura.
É interessante citar que o projeto estruturado entra em cena aonde a programação
estruturada sai, ou seja em sistemas de médio porte em diante.
Além do mais, a fase de Projeto procura prover os sistemas de facilidades para:
• construção
• testes
• modificações
• entendimento
2
1.2 Os fundamentos do projeto
1.2.1 Contexto do Projeto
Geralmente as sete fases de um sistema clássico são:
• reconhecimento do Problema
• estudo de viabilidade
• análise
• projeto
• implementação
• testes
• manutenção
1.2.2 Principais sintomas de um projeto inadequado
Abaixo são apontadas os principais sintomas de um projeto inadequado:
• inadministráveis;
• insatisfatórios;
• insatisfatórios e improdutivos;
• não confiáveis;
• inflexíveis e de difícil manutencão;
• ineficientes;
• qualquer combinação dos itens acima.
3
1.3 Critérios de Qualidade do Projeto
1.3.1 Completeza
O Projeto não deve perder nada do que foi identificado na fase de análise como
requisito essencial.
1.3.2 Manutenibilidade
Deve-se projetar o sistema de forma a permitir facilidades de alteração devido a:
• erros do sistema
• novas necessidades do usuário
• alterações do ambiente
Verifica-se que os sistemas mais fáceis de alterar são aqueles construídos de

forma modular, com cada módulo desempenhando funções bem definidas e coesas, e
com baixo grau de interdependência ou acoplamento entre os mesmos.
1.3.3 Performance
Performance está diretamente relacionada ao uso otimizado dos recursos de

hardware, software e pessoal disponíveis.
Como parâmetros de avaliação da Performance, temos:
• tempo de processamento
• memória ocupada
• through-put - dados processados por unidade de tempo
• tempo de resposta
Dentre os fatores que afetam o desempenho, temos:
• deficiência do projeto de interface
• tempo de acesso a discos e periféricos - devido ao tempo gasto em acesso a

discos ser muito maior do que operações na CPU, deve-se prover o sistema de
mecanismos que minimizem este tempo, empregando-se organizações de
arquivos adequadas.
4
• falta de reorganização de arquivos - em arquivos grandes e de muita utilização,

deve-se verficar a possibilidade de limpezas periódicas, ou particionamento do
mesmo gerando um arquivo atual e um histórico.
• processos longos em horário de pique - deve-se evitar ao máximo a execução

de processos batch de longa duração durante o horário de pique, tais como
transferência de grandes arquivos, atualizações de grande volume de dados em
banco de dados.
1.3.4 Segurança
Deve-se prover mecanismos para evitar acessos indevidos ao sistema.
Como tipos de ameaças a segurança temos:
• infiltração intencional - roubo, sabotagem, grampeamento

• infiltração não intencional - linhas cruzadas, irradiações
• acidentes - erro do usuário, falha de hardware, falha de software
Para controle de acesso ao ambiente, o sistema deve identificar usuário e terminal,

restringindo as operações conforme a necessidade.
Cada usuário deve possuir um único e pessoal:
• código de identificação - cpf , identidade ou matrícula

• código de autenticação - para validar a identificação inicialmente informada
(password, cartão magnético, digital, voz, etc). Passwords devem ser secretas,
ter de seis a oito caracteres e devem ser trocadas periodicamente. Além disso,
estes códigos de autenticação nunca devem ser expostos no terminal, e deve ser
limitado o número de tentativas seguidas sem sucesso de um usuário.
1.3.5 Interatibilidade
Corresponde a facilidade do usuário em interagir com o sistema. Para tal, deve-se

ter cuidado na escolha da implementação de funções batch/on-line.
Cuidados com lay-out de telas e relatórios devem ser observados. As telas devem
ser padronizadas para menu; atualização, consulta; entradas de parâmetros; espera de
processamentos longos e respostas de consulta. As teclas de função válidas em cada tela
devem ser indicadas explicitamente.
Telas devem ser providas de:
• data
5
• identificação do usuário
• código da tela
• identificação da operação referente a tela
• área de menu de opções e entrada de dados
• área de mensagens de erro relativos às operações
• área de mensagens interativas com o decorrer da operação
A crítica de campos pode ser feita campo a campo, tela cheia, ou por grupos de
campos. Mensagens de erro devem ser padronizadas e devem deixar claro qual foi o erro,
e a indicação do campo, se necessário. Deve-se prover DEFAULTS para entradas padrões
e utilização de teclas para acesso a tabelas em campos codificados.
Linha de comando deve ser utilizada principalmente para sistemas com um alto
nível hierárquico de telas. Este recurso permite que os usuários através de um
mneumônico de uma aplicação, tenham acesso a mesma sem a necessidade de navegação
pelas telas.
1.3.6 Confiabilidade
Confiabilidade está relacionada a redução do risco de interrupção no fluxo normal

de processamento das informações causadas por:
• indisponibilidade de acesso - o sistema não oferece o serviço no tempo

estipulado ou desejado.
• perda da integridade das informações
Como medidas para aumentar a confiabilidade temos:
• restrições de integridade que podem ser feitas via programa ou definidas no

próprio SGBD, quando este possui esta facilidade;
• crítica a entrada de dados;
• programas de acertos que geram ajustes, estornos, cancelamentos ou correções;
Mecanismos de recuperação de falhas devem ser utilizados de acordo com o nível

de confiabilidade da aplicação, tais como back-up e Log.
1.3.7 Economia
O custo do projeto deve ser balanceado de acordo com:
• custo da tecnologia;
• custo operacional;
• custo de construção e manutenção
6
2. FASES DO PROJETO
Dois modelos são utilizados nas fases de projeto. O Modelo de Implementação do

Sistema e o Modelo de Implementação de Programas.
2.1 Modelo de Implementação do Sistema
O Modelo de Implementação de Sistemas subdivide-se em um Modelo de

Processador e um Modelo de Tarefa.
2.1.1 Modelo de Processador
As atividades essenciais identificadas na fase de análise, bem como as atividades

adicionais necessárias devido a limitação da tecnologia, devem, em tempo de projeto, ser
alocadas a processadores.
Dentre as possíveis opções, verifica-se:
• todo modelo essencial alocado a um único processador. Esta opção é

conhecida como solução mainframe;
• principais funcionalidades de um diagrama nível 0 de um DFD serem alocadas

a diferentes processadores. Esta solução costuma ser chamada de solução
distribuída;
• pode ainda ser escolhida uma opção intermediária entre as duas citadas
anteriormente, com o objetivo de minimizar custos, maximizar a
confiabilidade.
Desta forma, o empacotamento de atividades e dados pode levar a uma

distribuição de atividades essenciais e/ou containers por mais de um processador, ou
mesmo, repetição de atividades essenciais e/ou containers em mais de um processador.
Como a comunicação entre processadores é mais lenta que a comunicação entre
processos no mesmo processador, o projetista deve tentar agrupar processos e depósitos
que tenham alto grau de comunicação em um mesmo processador. Os principais
problemas encontrados são:
• custo: dependendo da natureza do sistema, a implementação em um

processador único pode ser ou não a mais barata;
• eficiência: a utilização de mais de um processador pode levar a um melhor

tempo de reposta bem como permitir a execução paralela de atividades. Por
7
outro lado, deve-se verificar uma possível ineficiência na comunicação entre os

processadores;
• segurança: por questões de segurança, pode ser necessário a alocação de

alguns processos e dados em processadores localizados em áreas protegidas.
Por outro lado, a comunicação entre processadores pode ser proibitiva pelos
mesmos motivos;
• confiabilidade: em função da confiabilidade, o projetista pode decidir por

configurações que permitam que parte de um sistema fique disponível ainda
que outras partes estejam inoperantes. Pode-se utilizar processadores de
reserva, bem como cópia de processos e dados em vários processadores.
Como forma de auxílio para a montagem do modelo de processador, é sugerida a

montagem de uma lista, no formato da Figura 2.1, com as atividades essenciais acrescida
das atividades tecnológicas, tais como geração de histórico, definição de perfil de usuário,
etc.
Evento Processo Arquivos Lógicos Volume Frequên Processa

Estimado cia dor
vendedor efetua 3.2 venda - 300/dia P1
uma venda vendedor
item
.
Figura 2.1: Lista de Atividades para o Modelo de Processador
8
2.1.2 Modelo de Tarefa
A partir do Modelo de Processador, deve-se fazer o empacotamento das

atividades em tarefas “on-line”, “batch” e “real time”.
O sistema operacional é responsável pelo gerenciamento de uma ou mais tarefas

em um processador. A estratégia de agrupar atividades em tarefas consiste em verificar a
forma de utilização do sistema, e o tempo de resposta esperado para cada atividade.
Deve-se entender como tarefa uma atividade independente e assíncrona.
Ao final do empacotamento tem-se a lista de tarefas por processadores. Como

forma de auxílio para a elaboração do Modelo de Tarefas, é sugerida a utilização da lista
da figura 2.2.
Processador: Tarefa: Tipo:
Evento Processo Atividade(s) Classe do Usuário
Figura 2.2: Lista de Tarefas para o Modelo de Tarefas
9
2.2 Modelo de Implementação de Programa
Neste fase, o objetivo é organizar o sistema em programas. Cada programa

consiste em uma hierarquia composta por várias hierarquias menores.
Existem diversas propostas para chegar a uma estrutura de software hierárquica,

onde destaca-se o Diagrama de Estrutura Modular proposto por Page-Jones que enfatiza a
decomposição hierárquica de uma atividade em módulos individuais que sejam
reutilizáveis.
O Diagrama de Estrutura Modular, também conhecido como DEM, é descrito em

detalhes no próximo capítulo.
10
3. DIAGRAMA DE ESTRUTURA MODULAR
3.1 Introdução
Uma das principais finalidades do DEM é possibilitar a criação de sistemas que

sejam mais confiáveis e de fácil manutenção. Para isso, o modelo procura atingir os
seguintes objetivos:
• precisão - um módulo deve fazer exatamente o que se espera dele;

• solidez - capacidade de um módulo manipular corretamente situações
inesperadas. Um módulo sólido não propaga erros;
• extensibilidade - módulos devem ser construídos de tal forma que uma nova
funcionalidade possa ser adicionada sem a necessidade de se refazer o serviço.
• facilidade de adaptação - os módulos devem ser de tal forma que possam ser
facilmente adaptados a novas utilizações;
• reutilização - os módulos devem ser projetados de tal forma que possam ser
utilizados em mais de uma aplicação.
Com estratégia para alcançar os objetivos mencionados, os princípios descritos a

seguir devem ser considerados:
• ocultar informações - o funcionamento interno de um módulo deve estar oculto

aos outros módulos. Assim, módulos podem utiilizar-se de outros módulos e
depender destes para realizar as tarefas esperadas sem se preocupar como devem
ser realizadas tais tarefas;
• poucas interfaces - um módulo deve interagir com outros o mínimo possível, pois
quanto mais interfaces tiverem uns com os outros, mais difícil será a manutenção
dos mesmos;
• pequenas interfaces - a interface de um módulo deve precisar somente das

informações necessárias para que o mesmo complete a tarefa. Este princípio
limita as ligações que um módulo tem com uma aplicação em particular,
tornando-o mais fácil de ser reutilizado;
• interfaces explícitas - as interfaces devem ser feitas de forma que todas as

informações pertinentes sejam claramente especificadas no código fonte;
• clareza - um módulo deve ser dedicado a uma finalidade bem definida, e a função
desempenhada pelo módulo não deve gerar nenhum “efeito colateral” inesperado.
Uma vantagem da obediência deste princípio é a facilidade de depuração.
11
3.2 Componentes do DEM
A seguir serão apresentados os principais componentes do DEM e suas

características sintáticas.
3.2.1 Módulo
“É o elemento separadamente endereçável em um sistema”
“É a menor parte do sistema que realiza uma função completa independente de

outras funções”
“É um conjunto de instruções de um programa que pode ser chamado por um

nome, sendo ideal para que os outros módulos sejam uma caixa preta”
A simbologia utilizada para representar um módulo é ilustrada na Figura 3.1.
Calcular
Salário
Líquido
Figura 3.A: Simbologia de representação de Módulo
O nome do módulo deve corresponder a declaração de uma função, sendo

normalmente formado por um verbo indicando uma ação.
Pode-se utilizar em um modelo módulos já pré-definidos, isto é, módulos já

existentes que são reutilizados. A figura 3.2 apresenta a simbologia para um módulo pré-
definido.
Validar
CPF
Figura 3.B: Simbologia de representação de Módulo Pré-Definido
12
3.2.2 Hierarquia de Módulos
A hierarquia entre os módulos é representada na Figura 3.3. O módulo A chama o

módulo B que executa sua função e retorna ao módulo A.
Figura 3.C: Hierarquia de Módulos
13
Já a figura 3.4 ilustra uma outra hierarquia entre módulos:
B G H
C F I J
D E
Figura 3.D: Exemplo de uma Hierarquia entre Módulos
A chamada de um determinado módulo pode ser:

• incondicional - o módulo subordinado sempre será ativado pelo seu superior. Na
figura 3.4, o módulo B é ativado através de uma chamada embutida na
implementação do módulo A.
• condicional - corresponde a uma seleção ou decisão. A ativação de um módulo

subordinado é determinada por uma condição embutida na implementação do
módulo superior. A figura 3.5 ilustra a simbologia referente a ativação
condicional.
14
B C
Figura 3.E: Chamada condicional de Módulos
• repetitiva - um módulo subordinado pode ser ativado pelo seu superior mais de
uma vez, em função de uma condição. A figura 3.6 apresenta uma ativação
repetitiva.
B C
Figura 3.F: Chamada repetitiva de Módulos
15
Quando um módulo ativa outro módulo, passa algumas informações denominadas

de parâmetros da chamada. Desta forma, um módulo pode tanto receber quanto passar
parâmetros.
Os possíveis tipos de parâmetros são:
• dado - corresponde a informações existentes no mundo real, ou seja fazem

parte do problema
• controle - corresponde a informações não existentes no mundo real, não tendo
relevância para o mundo externo, apenas para o funcionamento do sistema
A figura 3.7 ilustra a simbologia utilizada para representar no diagrama os dados e

controles que fluem entre os módulos. CPF indica um fluxo de dado, já EOF (“end of
file”) corresponde a um controle.
CPF
EOF
Figura 3.G: Tipo de parâmetros entre Módulos
3.2.3 Tipos de Módulos
Os módulos dividem-se em quatro tipos básicos, determinados pela direção do

fluxo dos dados:
• Aferente - envia informação para seu superior de baixo para cima;

• Eferente - envia informação para seu subordinado de cima para baixo;
• Transformador - recebe informação de seu superior, faz algum tipo de
transformação e retorna uma nova informação ao seu superior;
• Coordenador - coordena a comunicação de seus subordinados.
A Figura 3.8 ilustra os diferentes tipos de módulos.
16
Módulo
Módulo
Aferente
Eferente
Módulo de
Coordenação
Módulo de
Transforma-
ção
Figura 3.H: Tipos de Módulos
3.2.4 Conector
Conector é utilizado para representar módulos repetidos ou referenciar módulos

localizados em páginas diferentes. O conector minimiza o emaranhado de traços.
A figura 3.9 ilustra os dois tipos de conectores.
17
Conector para
Conector de uma mesma
página página
Figura 3.I: Simbologia para Conectores

A figura 3.10 ilustra um exemplo de parte de um modelo. Note que o módulo
obter data corrente é pré-definido. Para deixar o modelo mais “limpo”, é utilizado o
conector DH, que faz referência ao módulo obter data corrente, que é subordinado a
mais de um módulo. O conector ODC (obter detalhe cliente ) referencia um módulo
localizado em outra página do modelo (figura 3.11).
Controlar
Contas
Cliente
data-corrente dados
conta conta-atrasada
EOF
Obter Obter Processar

Data Dados Conta
Corrente da Conta não Paga
atraso-pequeno atraso-demasiado
ODC
DH atraso-grande
Gerar Gerar Gerar

Aviso Advertência Tratamento
Obter Gentil Legal
Data
Corrente
DH DH DH
Figura 3.J: Exemplo de parte de um modelo
18
ODC
Obter
Detalhe
Cliente
Figura 3.K: Exemplo do uso de Conector de Página
3.2.5 Especificação de Módulos
É a forma de definir o funcionamento interno de cada módulo, e sua especificação

deve conter:
• função;
• entradas e saídas;
• lógica interna do módulo. Esta lógica pode ser expressa de forma genérica (o
que fazer) ou de forma detalhada através de pseudo-código (como fazer).
19
3.3 Critérios de Qualidade do DEM
3.3.1 Acoplamento
O Acoplamento mede o grau de interdependência entre os módulos do diagrama.

O que se deseja são módulos de baixo acoplamento para diminuir o máximo possível o
efeito em cadeia quando um módulo for alterado.
Os tipos de Acoplamento são:
• Dados
• Imagem
• Controle
• Comum
• Conteúdo
• Acoplamento de Dados
Corresponde a comunicação de dados necessária entre módulos. Uma vez que os

módulos têm que se comunicar, a ligação de dados é inevitável, e não é crítica desde que
mantidas as taxas mínimas.
Deve-se tomar cuidado com o chamado dado migrante (um grupo de informações
que vagueia pelo sistema), indesejável e sem sentido para a maioria dos módulos pelos
quais passa.
A figura 3.12 ilustra um Acoplamento de Dados.
Gerar
Guia de
IPTU
área
valor-taxa
Calcular
Taxa
20
Figura 3.L:Exemplo de Acoplamento de Dados

• Acoplamento de Imagem
Dois módulos apresentam Acoplamento por Imagem se eles fazem referência a

uma mesma estrutura de dados. Este tipo de Acoplamento tende a fornecer mais dados do
que o necessário a um módulo.
A figura 3.13 ilustra um exemplo de Acoplamento por Imagem.
Calcular
Valor
Aluguel
registro custo
aluguel combustível
valor registro
aluguel aluguel
Obter Calcular
Aluguel do Gasto de
Carro Combustível
Figura 3.M: Exemplo de Acoplamento de Imagem
• Acoplamento de Controle
Dois módulos são acoplados por controle se um passa um grupo de dados

(controle) para o outro para controlar sua lógica interna.
A figura 3.14 ilustra um Acoplamento de Controle.
21
Gerar Validar
Folha Pedido
Pagamento
CPF FLAG tipo-erro
Imprimir
Validar
Mensagem
CPF
Erro
Figura 3.N: Exemplo de Acoplamento de Controle
No primeiro exemplo, o acoplamento não é tão crítico uma vez que o controle
indica uma validação, porém o segundo exemplo exige que o módulo que enviou o
controle (validar pedido) conheça o outro módulo.
• Acoplamento Comum
Dois módulos possuem Acoplamento Comum quando fazem referência a uma

área global de dados (ex. Working Storage Section da linguagem Cobol).
A figura 3.15 apresenta um exemplo de Acoplamento Comum.
22
Obter Atualizar
dados Estoque
Peça
Quantidade
Retirada
Nome Quantidade
Peça Atual
Estoque de Peças
Figura 3.O: Exemplo de Acoplamento Comum
Este tipo de Acoplamento não é desejável pois:
um erro em uma área global pode se propagar por diversos módulos;

programas com muitos dados globais são de difícil entendimento;
fica difícil descobrir que módulos devem ser alterados quando um dado é
modificado.
• Acoplamento de Conteúdo
Dois módulos apresentam Acoplamento de Conteúdo (ou patológico) se um faz

referência ou desvia a sequência de instruções para o interior de um outro módulo (GO
TO). Tal Acoplamento torna o conceito de caixas-pretas sem sentido.
A figura 3.16 ilustra um exemplo de Acoplamento de Conteúdo.
23
Módulo A
<instruções>
Valor = Valor * percentual
Se Valor > 1000
GO TO P1
Fim-se
<instruções>
Módulo B
<instruções>.
P1. Efetuar desconto
<instruções>
Figura 3.P: Exemplo de Acoplamento de Conteúdo
3.3.2 Comparação dos Tipos de Acoplamento
Os tipos de Acoplamento especificados abaixo são apresentados em ordem

descrescente (do melhor para o pior tipo).
Dados
Imagem
Controle
Comum
Conteúdo
24
3.3.3 Coesão
Coesão mede a intensidade da associação funcional dos elementos de um módulo.

Deseja-se módulos altamente coesos, cujos elementos são relacionados um com os
outros.
Por outro lado, os elementos de um módulo não devem ser fortemente

relacionados com os elementos de outros módulos, pois isto levaria a um forte
acoplamento entre eles. Ter certeza de que todos os módulos têm boa coesão é a melhor
forma de minimizar o acoplamento.
Os tipos de Coesão são:
• Funcional
• Sequencial
• Comunicacional
• Procedural
• Temporal
• Lógica
• Coincidental
• Coesão Funcional
Um módulo apresenta Coesão Funcional quando suas funções internas contribuem

para a execução de uma e apenas uma tarefa relacionada ao problema.
A figura 3.17 ilustra módulos com Coesão Funcional.
Num-Conta Nome Num-Conta Dados

Cliente Empréstimo
Obter Obter
Nome Dados
Cliente Empréstimo
Figura 3.Q: Exemplo de Coesão Funcional
25
• Coesão Sequencial
Um módulo apresenta Coesão Sequencial quando suas funções internas estão

envolvidas em atividades de tal forma, que os dados de saída de uma atividade sirvam
como dados de entrada para a próxima.
Este fluxo estabelece uma sequência de execução das funções, no entanto, não se
pode caracterizar o conjunto delas como uma única tarefa.
A Figura 3.18 ilustra um módulo com Coesão Sequencial. No exemplo, verifica-

se que exibir consulta executa duas atividades bem distintas e que poderiam ser
representadas pelos módulos:
obter registro
exibir dados
Num-Conta
Exibir
Consulta
Figura 3.R:Exemplo de Coesão Sequencial
Um módulo com Coesão Sequencial caracteriza-se por ser de fácil manutenção

porém de baixa reutilização, pois contém atividades que são utilizadas juntas.
• Coesão Comunicacional
Um módulo possui Coesão Comunicacional quando suas funções internas estão

relacionadas por utilizarem as mesmas informações, ou seja, utilizam a mesma entrada ou
mesma saída. Nesta situação o módulo fornece mais informações que o necessário.
A figura 3.19 ilustra um módulo com Coesão Comunicacional. No exemplo

Obter Detalhes Cliente recebe um mesmo parâmetro de entrada Num-Conta e executa
duas atividades distintas que poderiam ser representadas pelos módulos:
26
obter nome cliente

obter resultado empréstimo
Data-Vencimento
Num-Conta Saldo-Empréstimo
Limite-Empréstimo
Obter
Detalhes
Cliente
Figura 3.S: Exemplo de Coesão Comunicacional
Módulos com Coesão Comunicacional e Sequencial são semelhantes, pois ambos

contém atividades organizadas em torno dos dados do problema original.
A principal diferença entre eles é que um módulo sequencialmente coeso opera

como uma linha de montagem onde suas atividades são executadas em uma ordem
específica. Já em um módulo com coesão comunicacional a ordem de execução não é
importante.
• Coesão Procedural
Um módulo possui Coesão Procedural quando suas funções internas executam

atividades diferentes e não correlacionadas, exceto por serem executadas em uma mesma
ordem, nas quais o controle flui ( e não os dados ) de uma atividade para outra.
É comum em um módulo com Coesão Procedural que os dados de entrada e saída
tenham pouca relação. É típico também que tais módulos devolvam resultados parciais,
tais como: flags, chaves, etc.
27
A figura 3.20 ilustra o módulo Tratar Saque isolado (parte esquerda da figura)
com Coesão Procedural, e sua fatoração para módulos funcionalmente coesos na parte
mais a direita da figura.
valor num-conta
Tratar
Saque
num-
Valor num-
conta
valor conta
Num-Conta num- valor
conta
flag
Verificar Bloquear Efetuar

Tratar
Limite Saque Saque
Saque
Crédito
Figura 3.T: Exemplo de Coesão Procedural
• Coesão Temporal
Um módulo possui Coesão Temporal quando suas funções internas executam

atividades que estão relacionadas apenas com o tempo (as atividades não estão
relacionadas entre si). A ordem de execução de atividades é mais importante em módulos
procedurais do que em módulos temporais.
A Figura 3.21 ilustra um módulo com Coesão Temporal.
Finalizar
28
Figura 3.U: Exemplo de Coesão Temporal
• Coesão Lógica
Um módulo possui Coesão Lógica quando suas funções internas contribuem para
atividades da mesma categoria geral, onde a atividade é selecionada fora do módulo.
Desta forma, módulos logicamente coesos apresentam uma interface descaracterizada.
A figura 3.22 ilustra um módulo com Coesão Lógica.
flag
reg-material
reg-cliente
status
reg-fornecedor atualização
Rotina
Geral de
Atualização
Figura 3.V: Exemplo de Coesão Lógica
• Coesão Coincidental
Um módulo possui Coesão Coincidental quando suas funções não possuem

nenhuma correlação entre si, não há uma ordem específica de execução, nem sempre
todas as funções são ativadas e a ativação das funções é decidida fora do módulo. A
figura 3.23 ilustra uma Coesão Coincidental.
29
venda
nome-
num- material
material
conta saldo
Calcular Saldo
Validar
Material
Figura 3.W: Exemplo de Coesão Coincidental
3.3.4 Determinação do Tipo de Coesão
A figura 3.24 mostra uma estratégia para identificar o tipo de Coesão de um

determinado módulo.
1. FUNCIONAL
SIM
O MÓDULO PODE SER A SEQÜÊNCIA SIM
2.SEQÜENCIAL
CONSIDERADO COMO É IMPORTANTE ?
EXECUTANDO UMA DADOS NÃO 3.COMUNICACIONAL
FUNÇÃO RELACIONA- NÃO
DA AO PROBLEMA
O QUE RELACIONA FLUXO DE SIM 4.PROCEDURAL

CONTROLE A SEQÜÊNCIA
AS ATIVIDADES DO É IMPORTANTE ?
MÓDULO 5.TEMPORAL
NÃO
NENHUM
DELES AS ATIVIDADES SIM 6.LÓGICA
ESTÃO NA MESMA
CATEGORIA GERAL ?
7.COINCIDENTAL
NÃO
Figura 3.X: Estratégia para identificação dos tipos de Coesão
30
Comparando os tipos de Coesão, podemos classificá-los em ordem, como

descrito abaixo ( do melhor para o pior tipo ):
• Funcional
• Sequencial
• Comunicacional
• Procedural
• Temporal
• Lógica
• Coincidental
31
3.4 Diretrizes Adicionais do Projeto
Além do Acoplamento e Coesão devemos considerar outras diretrizes dentro do

Projeto tais como Factoring, Divisão de Decisão, Fan-In, Fan-Out, etc.
3.4.1 Factoring
Corresponde a separação de uma função contida em um módulo, passando-a para

um novo módulo. Este separação pode ter com objetivo:
• reduzir o tamanho do módulo;

• obter as vantagens modulares de um projeto top-down, tornando o sistema
mais compreensível e permitindo modificações mais localizadas;
• evitar a codificação de uma mesma função em mais de um módulo;
• prover módulos de utilização mais genérica;
• simplificar a implementação.
A fatoração de um módulo grande deve ser efetuada se não diminuir a Coesão e

não aumentar o Acoplamento do módulo original. A figura 3.20, já apresentada, ilustra
uma fatoração.
3.4.2 Divisão de Decisão
Uma decisão é constituída de duas partes: o reconhecimento da ação a ser tomada

e a execução desta ação.
Deve-se evitar ao máximo a divisão de decisão. A parte referente a execução da
decisão deve ser mantida o mais próximo possível da parte referente ao reconhecimento,
a fim de que a informação reconhecida não tenha que percorrer um longo caminho para
ser processada (dado migrante).
Escopo de Controle: conjunto formado por um módulo e todos os seus

subordinados;
Escopo de Efeito de uma Decisão: conjunto de todos os módulos cujo seu
procedimento depende da decisão.
É importante que o Escopo de Efeito de uma Decisão de um módulo seja um

subconjunto do Escopo de Controle deste módulo. Sempre que esta regra for violada
(figura 3.25), deve-se elaborar uma nova organização dos módulos com o objetivo de
aproximar o reconhecimento da execução (figura 3.26).
32
Notação
Efeito A
Decisão
C B
D E X
F G
Figura 3.Y: Exemplo de um diagrama com Divisão de Decisão
33
Notação
Efeito A
Decisão
C B
D E X
F G
Figura 3.Z: Exemplo de um Diagrama sem Divisão de Decisão
3.4.3 Formas de um Modelo
• Input-Driven
Corresponde ao modelo que realiza pouco processamento em seu lado aferente,
de modo que os módulos superiores lidam com dados físicos e não refinados. Esta forma
não é desejável pois muitos módulos no topo do sistema estão relacionados com o
formato físico da entrada.
A figura 3.27 ilustra o formato de um modelo Input-Driven.
34
B C E
D F H
Figura 3.AA: Formato de um modelo Input-Driven
• Output-Driven
Esta forma é mais rara de se verificar, porém também é desaconselhável uma vez
que módulos superiores ficam presos a condições físicas de saída.
A figura 3.28 ilustra o formato de um modelo Output-Driven.
35
B G I
C F H
D E
Figura 3.BB: Formato de um modelo Output-Driven
• Balanceado
Ocorre quando os módulos superiores lidam com dados de natureza lógica e não
física. No lado aferente o dado é inicialmente editado e desblocado, deixando de depender
da forma de entrada no sistema. No lado eferente, o dado é independente de qualquer
formato especial de saída desejado pelo usuário.
A figura 3.29 ilustra o formato de um modelo Balanceado.
36
B G H
C F I J
D E
Figura 3.CC: Formato de um modelo Balanceado
3.4.4 Informações de Erro
Erros devem ser relatados pelo módulo que os detectou e que conhece sua
natureza.
Mensagens de erro juntas em um módulo tem as seguintes vantagens e
desvantagens:
• é mais fácil de manter o texto e o formato da mensagem;

• é mais fácil evitar mensagens duplicadas;
• é necessário um número artificial de mensagem para acessá-la;
• a codificação não fica tão compreensível.
3.4.5 FAN-OUT e FAN-IN
37
FAN-OUT corresponde ao número de subordinados imediatos de um módulo.

Deve-se limitar o FAN-OUT de um módulo em torno de sete. Para corrigir um alto FAN-
OUT pode-se utilizar o Factoring de módulos.
A Figura 3.30 ilustra um modelo com um alto FAN-OUT.
B G H J K L M
Figura 3.DD: Exemplo de um modelo com alto FAN-OUT
FAN-IN corresponde ao número de módulos superiores de um módulo. Um alto

FAN-IN acarretando reutilização de módulos.
Existem duas regras para restringir o FAN-IN:
• módulos com FAN-IN devem ter coesão funcional, ou no mínimo coesão

comunicacional ou sequencial;
• a interface deve ter os mesmos números e tipos de parâmetros.
A Figura 3.31 apresenta um modelo com alto FAN-IN.
38
B G H J
Figura 3.EE: Exemplo de um modelo com alto FAN-IN
39
3.5 Estratégia para Derivar o DFD para o DEM
A passagem da especificação produzida na fase de análise para a fase de projeto é

feita através de duas estratégias, utilizadas de acordo com as características dos DFDs a
serem transformados. São elas:
• Análise de Transformação
• Análise de Transação
3.5.1 Análise de Transformação
A Análise de Transformação é aplicada no nível do DFD que apresenta ligação

direta entre processos através de fluxos de dados. Esta estratégia baseia-se em:
Passo 1: identificar o ramo aferente, o ramo eferente, e o centro de transformação

do nível do DFD, onde :
• ramo aferente corresponde aos elementos considerados como entradas;
• ramo eferente corresponde aos elementos já alterados para a saída;
• ramo de transformação corresponde a fase em que os dados passam de aferente
para eferente.
Passo 2: considerar cada processo como um módulo e adotar o algorítmo a seguir

para escolha do módulo de mais alto nível da hieraquia (escolha do chefe).
Se há um bom candidato para chefe no Centro de Transformação

Então escolha o chefe e deixe os demais subordinados a ele
Senão promova um novo chefe, considere o centro de transformação
como uma única bolha do DFD e subordine a transformação
central e cada ramo aferente e eferente ao novo chefe.
A figura 3.32 apresenta um DFD já com a identificação do centro de

transformação.
A figura 3.33 ilustra a derivação para o DEM a partir da escolha do processo P4 como
“chefe”. Já a figura 3.34 apresenta um novo diagrama onde o módulo “chefe” não
corresponde a nenhum processo do DFD.
40
D F H
P1 P3 K
P4 P6
B G
I
E
J
L
P2 P5
P7
Figura 3.FF: Exemplo de DFD com a identificação do centro de

Transformação
41
P4
P3 P5 P6
P1 P2 P7 Exibir K
Obter A Obter B Obter C Exibir L
Figura 3.GG: Exemplo de um DEM derivado a partir de um DFD
42
CHEFE
P3 P4
P1 P2 P5 P6
Obter A Obter B Obter C P7 Exibir K
Exibir L
Figura 3.HH: Exemplo de um DEM derivado a partir de um DFD
Passo 3: Prover o diagrama de novas capacidades:
• adicionar módulos de leitura e/ou gravação;

• efetuar factoring;
• adicionar módulos de manipulação de erros;
• checar critérios de projeto.
3.5.2 Análise de Transação
A Análise de Transação é aplicada no nível do DFD que apresenta ligação de

processos via depósito de dados.
A aplicação da Análise de Transação deve seguir os seguintes passos:

• selecionar como módulo raíz o processo que originou o nível em análise;
• utilizar um módulo para selecionar a transação desejada;
• para cada módulo individual aplicar Análise de Transformação ou Análise de
Transação, se houver explosão do mesmo.
43
A figura 3.35 ilustra um DFD que após a aplicação da Análise de Transação

resulta o diagrama da figura 3.36.
Diagrama Nível X
f1 f7
EXT1
EXT3
f2
f3
P1 P3
f6
dep2
dep1
dep3
f4 P2
f5
EXT2
Figura 3.II: Exemplo de DFD com ligações entre processos via depósito de dados
PX
transação
Obter
Transação P1 P2 P3
Figura 3.JJ Figura 3.36: Exemplo de utilização de Análise de Transação
44

Coesao Acoplamento

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Coesao Acoplamento

Загружено:

Авторское право:

Доступные форматы

PROJETO ESTRUTURADO DE SISTEMAS

FACULDADE DE TECNOLOGIA DE BIRIGUÍ - SP

ORÁCULO CONSULTORIA DE SISTEMAS - RJ

Organizada por Gustavo Miranda Araújo - 1996

1.1 Proposta para o Projeto 1

1.2 Os fundamentos do projeto 3

1.3 Critérios de Qualidade do Projeto 4

2.1 Modelo de Implementação do Sistema 7

2.2 Modelo de Implementação de Programa 10

3. DIAGRAMA DE ESTRUTURA MODULAR 11

3.2 Componentes do DEM 12

3.3 Critérios de Qualidade do DEM 20

3.4 Diretrizes Adicionais do Projeto 32

3.5 Estratégia para Derivar o DFD para o DEM 40

FIGURA 3.1: SIMBOLOGIA DE REPRESENTAÇÃO DE MÓDULO 12

1.1 Proposta para o Projeto

Projeto Estruturado de Sistemas é a atividade de transformação das necessidades

Nesta fase, deixa-se de ter a tecnologia perfeita, passando a levar em

Projeto estruturado é uma abordagem disciplinada de projeto de sistemas

1) Permite que a forma do problema guie a forma da solução.

Para tornar fácil o entendimento o Projeto Estruturado se utiliza basicamente de

• um auxílio para a manutencão e modificações

1.2 Os fundamentos do projeto

1.2.1 Contexto do Projeto

Geralmente as sete fases de um sistema clássico são:

1.2.2 Principais sintomas de um projeto inadequado

Abaixo são apontadas os principais sintomas de um projeto inadequado:

1.3 Critérios de Qualidade do Projeto

Deve-se projetar o sistema de forma a permitir facilidades de alteração devido a:

Verifica-se que os sistemas mais fáceis de alterar são aqueles construídos de

Performance está diretamente relacionada ao uso otimizado dos recursos de

Como parâmetros de avaliação da Performance, temos:

Dentre os fatores que afetam o desempenho, temos:

• deficiência do projeto de interface

• tempo de acesso a discos e periféricos - devido ao tempo gasto em acesso a

• falta de reorganização de arquivos - em arquivos grandes e de muita utilização,

• processos longos em horário de pique - deve-se evitar ao máximo a execução

Deve-se prover mecanismos para evitar acessos indevidos ao sistema.

Como tipos de ameaças a segurança temos:

• infiltração intencional - roubo, sabotagem, grampeamento

Para controle de acesso ao ambiente, o sistema deve identificar usuário e terminal,

Cada usuário deve possuir um único e pessoal:

• código de identificação - cpf , identidade ou matrícula

Corresponde a facilidade do usuário em interagir com o sistema. Para tal, deve-se

Telas devem ser providas de:

Confiabilidade está relacionada a redução do risco de interrupção no fluxo normal

• indisponibilidade de acesso - o sistema não oferece o serviço no tempo

Como medidas para aumentar a confiabilidade temos:

• restrições de integridade que podem ser feitas via programa ou definidas no

Mecanismos de recuperação de falhas devem ser utilizados de acordo com o nível

O custo do projeto deve ser balanceado de acordo com:

Dois modelos são utilizados nas fases de projeto. O Modelo de Implementação do

2.1 Modelo de Implementação do Sistema

O Modelo de Implementação de Sistemas subdivide-se em um Modelo de

2.1.1 Modelo de Processador

As atividades essenciais identificadas na fase de análise, bem como as atividades

Dentre as possíveis opções, verifica-se:

• todo modelo essencial alocado a um único processador. Esta opção é

• principais funcionalidades de um diagrama nível 0 de um DFD serem alocadas

Desta forma, o empacotamento de atividades e dados pode levar a uma

• custo: dependendo da natureza do sistema, a implementação em um

• eficiência: a utilização de mais de um processador pode levar a um melhor

outro lado, deve-se verificar uma possível ineficiência na comunicação entre os