Projeto Estruturado 1

Projeto Estruturado

Critérios de Avaliação
 Projeto Estruturado 2

•  É um método de construção da organização modular do

sistema a partir de fluxos de dados

•  Produto:
•  Um gráfico de estruturas (Diagrama de Estrutura Modular)
complementado com as especificações (pseudo-códigos) de cada
módulo;
 Projeto Estruturado 3

Módulo ou Caixa Preta:

•  Conhece-se os elementos de
Módulo 1
entrada (input);
•  Conhece-se os elementos de
saída (output);
•  Conhece-se sua função (o que Entrada
de dados
a caixa preta faz para que os
elementos de entrada
produzam os elementos de
saída). Módulo 1.1 Módulo 1.2 Módulo 1,3

Saída de Decisão
dados

Módulo 1.2.1 Módulo 1.2.2 Módulo 1.2.3

 Projeto Estruturado 4

<nome do
módulo> = módulo

<nome do = módulo pré-definido (não será especificado porque

módulo> já exite em sistemas ou bibliotecas de aplicações)

= chamada de módulo (B é chamado por A)

B

= chamada iterativa, repetição (N é chamado

iterativamente por M)
N
 Projeto Estruturado 5

= decisão

X = conector e referência para continuação de página

X = conector de mesma página

= entrada/saída de dados (dados são processados)

= flag de controle ou descritivo (controles são testados)

 Projeto Estruturado 6

Controlar
Contas Cliente

dados conta-atrasada
conta EOF

Processar
Obter Dados
Conta Não
Conta
Paga
data-atual 1

detalhes-cliente,
detalhes-cliente,
atraso-pequeno
atraso-grande
detalhes-cliente
atraso-médio
Gerar
Gerar Aviso Gerar
Tratamento
data Gentil Advertência
Legal
atual

data
Obter atual
Data Atual
 Projeto Estruturado 7

detalhes-cliente

Obter
Detalhes
Cliente
 Projeto Estruturado 8

procedimento ControlarContasClientes
data-atual <- ObterDataAtual;
enquanto não é final de arquivo faça
dados-conta <- ObterDadosConta;
se conta atrasada então
ProcessarContaNãoPaga(dados-conta);
fim se
fim enquanto

procedimento ProcessarContaNãoPaga
entrada: conta
detalhes-cliente <- ObterDetalhesCliente;
se atraso-pequeno então
GerarAvisoGentil(detalhes-cliente, conta);
senão se atraso-médio então
GerarAdvertência(detalhes-cliente, conta);
senão se atraso-grande então
GerarTratamentoLegal(detalhes-cliente, conta);
fim se
 Projeto Estruturado 9

A Controlar
Contas Cliente
data-atual

dados
conta-atrasada
Obter A conta
Data Atual EOF

Processar
Obter Dados
Conta Não
Conta
Paga
1

detalhes-cliente,
atraso-pequeno detalhes-cliente,
atraso-grande
detalhes-cliente,
atraso-médio
Gerar
Gerar Aviso Gerar
Tratamento
Gentil Advertência
Legal

A A A
 Projeto Estruturado 10

•  Com relação às chamadas e retornos, os módulos de um

DEM podem ser classificados em:

•  Módulo Aferente

•  Módulo Eferente

•  Módulo Transformador

•  Módulo Coordenador
 Projeto Estruturado 11

•  Envia informação de baixo (B) para cima (A – para o módulo

chamador ou chefe)
A
•  Ex. (C++):
X
void A() {
… Módulo
x = Aferente(); Aferente
…
} X

int Aferente() { B
…
x = B();
…
return x;
}
 Projeto Estruturado 12

•  Envia informação de cima (A) para baixo (B – para os

módulos chamados ou subordinados)
A
•  Ex. (C++):
X

void A() {
… Módulo
Eferente
Eferente(x);
… X
}
void Eferente(int x) { B
…
B(x);
…
}
 Projeto Estruturado 13

•  Recebe informação de seu superior (A), transforma-a e a a

envia de volta.

•  Ex. (C++): A

void A() { X Y
…
y = Transformador(x); Módulo
… Transformador
}
int Transformador(int x) {
…
x *= 3 + 1;
return x;
}
 Projeto Estruturado 14

•  Organiza a comunicação de seus subordinados (A e B),

passando os dados de uma para outro.

•  Ex. (C++):
Módulo
void Coordenador() { Coordenador
…
x = A(); X Y
…
B(x * 2); A B
…
}
int A() {
…
return x;
}
 Projeto Estruturado 15

•  Simplificando um sistema [1/2]

•  O método projeto estruturado procura vencer a complexidade de
sistemas de duas maneiras: pela segmentação e organização
hierárquica.

•  Segmentação – Utilização de caixas pretas:

•  Vantagens do “particionamento” de um sistema em caixas pretas bem

definidas (cada uma tem seu papel):
•  O sistema é mais fácil de ser entendido, programado, testado, depurado e
modificado do que um sistema monolítico (não particionado);
 Projeto Estruturado 16

•  Simplificando um sistema [2/2]

•  Organização Hierárquica – Analogia (organização em uma empresa e

em um projeto de sistema de computador):
•  trabalho e administração devem ser separados;
•  todo departamento na empresa deve ter uma função bem definida (delegar
funções);
•  toda tarefa deve ser alocada ao departamento apropriado;
•  um administrador deve fornecer a um subordinado somente a quantidade de
informação necessária para o cumprimento de seu trabalho.
 Projeto Estruturado 17

•  Utilizando ferramentas gráficas

•  Um projeto estruturado usa as ferramentas: Diagrama de Estrutura
Modular (DEM) e Pseudocódigo:

•  DEM: ilustra a segmentação de um sistema em módulos (caixas pretas),

mostrando sua hierarquia, organização e comunicação;
•  O nível superior do DEM descreve as principais funções do sistema e suas
interfaces; já o nível inferior descreve os detalhes do DEM;

•  Pseudocódigo: utilizado para esclarecer a rotina detalhada de

procedimentos das caixas pretas do DEM
 Projeto Estruturado 18

•  Elaborando uma solução projetada

•  Um projeto estruturado oferece um conjunto de estratégias para
desenvolver uma solução de projeto a partir de uma declaração bem
definida do problema;
•  Problema apresentado por meio de um DFD => Estratégias: análise de
transformação e análise de transação.

•  Avaliando uma solução projetada

•  Um projeto estruturado oferece um conjunto de critérios para avaliar a
qualidade de uma dada solução projetada referente ao problema a ser
resolvido.
 Projeto Estruturado 19

•  O método Projeto Estruturado oferece uma abordagem

sistemática para a derivação de uma estrutura de programa a
partir do fluxo de dados => Diagrama de Estrutura Modular
(DEM);

•  Tipos de fluxos de informação:

•  Fluxo de Transformação;
•  Fluxo de Transação.
 Projeto Estruturado 20

1.  Os dados “entram” no sistema por caminhos que transformam dados

externos em uma forma interna (fluxo de entrada);
2.  Os dados atravessam um centro de transformações;
3.  Os dados se movimentam para “fora” do software (fluxo de saída)

1: Fluxo de 3: Fluxo de
Representação saída
entrada
externa
Informação

2: Fluxo de
transformações

Representação
interna
Tempo
 Projeto Estruturado 21

•  Exemplo – DFD:

Funcionários
dados-fun

Descontos
matrícula 3.1

impostos
RH sal-bruto
Calcular
Salário Fluxo de
Bruto transformação
Fluxo de 3.2
entrada Calcular dados-salariais
Fluxo de Salário Fluxo de
transformação Líquido saída
3.3
Emitir contra-cheque
Contra-
cheque
Funcionário
 Projeto Estruturado 22

Controlador de
Transformação

•  Exemplo – DEM:
Pagar Entrada Processamento Saída
Funcionário

dados-fun
matr-inválida
dados-
sal-liq
fun
dados-fun dados-fun sal-bru sal-liq erro de impressão
sal-bru

Calcular Sal. Calcular Sal. Emitir Contra-

Obter Dados cheque
Bruto Líquido

dados-fun impostos
matr-inválida
matr
matr dados-fun

Obter
Obter Obter
Dados
Matrícula Descontos
Fun.
 Projeto Estruturado 23

•  Exemplo – Código C++ (meramente ilustrativo) [1/2]:

void PagarFuncionario() {
…
dados_fun = ObterDadosFun();
…
sal_bru = CalcSalBru(dados_fun);
…
sal_liq = CalcSalLiq(dados_fun, sal_bru);
…
if (EmitirContraCheque(dados_fun, sal_liq))
…
}
 Projeto Estruturado 24

•  Exemplo – Código C++ (meramente ilustrativo) [2/2]:

struct dadosfun ObterDados() {

…
matricula = ObterMatricula();
…
retorno = ObterDadosFun(matricula);
…
}
int ObterMatricula() { … }
struct dadosfun ObterDadosFun(int matr) { … }
float CalcSalBru(struct dadosfun fun) { … }
float CalcSalLiq(struct dadosfun fun, float liq) { … }
int EmitirContraCheque() { … }
 Projeto Estruturado 25

•  Os dados se movimentam ao longo de um caminho de entrada;

•  Existe um despachante (centro de transação) que dispara outro fluxo de
dados ao longo de um dentre muitos caminhos.

Transação …
(dados)
… Caminhos de ação
Despachante D …
(Centro de
Transação)
…

…
…

•  Em um DFD, tanto o fluxo de transformação como o de transação podem estar

presentes;
•  Existem estratégias para derivar a estrutura de programa a partir de fluxos de
dados: Análise de Transformação e Análise de Transação
 Projeto Estruturado 26

•  Exemplo – DFD:
comprovante
dados-cartão

4.1
4.2
Escolher
Cliente pag pag-cartão Receber
Tipo de
em Cartão
Pagamento
Centro de
Transação
pag-espécie
Caminho 1
valor

Caminho 2
4.3 valor
troco
Receber Vendas
em Espécie

comprovante
 Projeto Estruturado 27

Despachante
de Transação

pag
•  Exemplo – DEM:
Receber Obter
Transação 1 Transação 2
Pagamento Transação

pag-cancelado
pag
pag
tipo-pag transação- troco
recusada

Obter Tipo de Receber Receber

Pagamento Cartão Espécie

valor pag

pag
resultado-
transação

Comunicar Registrar
TEF Pagamento
 Projeto Estruturado 28

•  Exemplo – Código C++ (meramente ilustrativo) [1/2]:

int ReceberPagamento(struct pgto pag) {

…
tipo_pag = ObterTipoPagamento();
if (tipo_pag == 1) {
ok = ReceberCartao(pag);
…
} else if (tipo_pag == 2) {
troco = ReceberEspecie(pag);
…
} else
…
}
 Projeto Estruturado 29

•  Exemplo – Código C++ (meramente ilustrativo) [2/2]:

void ReceberCartao(struct pgto pag) {

…
result = ComunicarTef(pag.valor);
…
if (result == 1) {
RegistrarPagamento(pag);
…
}
else
…
}
void ReceberEspecie(struct pgto pag) {
…
RegistrarPagamento(pag);
…
}
 Projeto Estruturado 30

•  Etapa 1: Reveja o Modelo de Sistema Fundamental

•  função de avaliar a especificação do sistema.

•  Etapa 2: Reveja e Refine os DFDs (se necessário)

•  cada bolha, em níveis inferiores, costuma ter única função que pode ser
implementada como um módulo do software;

•  Etapa 3: Determine se o DFD tem características de fluxo de

transformações ou de transações
•  o projetista seleciona uma característica de fluxo global baseado na
natureza predominante do DFD;
 Projeto Estruturado 31

•  Etapa 4: Isole o centro de transformações ao especificar as

fronteiras de fluxo de entrada e de saída
•  Uma maneira de encontrar o centro de transformação é identificar o
centro do DFD pela eliminação de seus ramos de entrada e saída;

•  Etapa 5: Execute uma “Fatoração de Primeiro Nível” [1/2]

•  A estrutura de programa representa uma distribuição top-down do
controle:
•  Módulos de alto nível executam tomadas de decisão;
•  Módulos de baixo nível realizam a maior parte do trabalho de entrada, de
computação e de saída;
•  Módulos de nível médio realizam algum controle e realizam um número
moderado de trabalhos;
 Projeto Estruturado 32

•  Etapa 5: Execute uma “Fatoração de Primeiro Nível” [2/2]

•  Fatoração de primeiro nível: um controlador principal encontra-se no topo
da estrutura do programa e serve para coordenar as funções de controle
subordinadas: controlador do fluxo de entrada; controlador do fluxo de
transformações; controlador do fluxo de saída.

Fluxo de entrada Fluxo de transformações Fluxo de saída

DEM Controlador de
Fluxo de Entrada
•  Cada módulo de controle recebe
Controlador Controlador de
Principal Fluxo de Transformações
um nome que implica a função
dos módulos subordinados
Controlador de
Fluxo de Saída que ele controla.
 Projeto Estruturado 33

•  Etapa 6: Execute uma “Fatoração de Segundo Nível” [2/2]

•  Fatoração de segundo nível: colocar as bolhas do DFD como funções de

módulos apropriados dentro da estrutura do programa.

B A
Controlador de
Fluxo de Entrada
A B
Controlador D C
Principal
C D
DEM

•  Obs:
•  Duas, ou até mesmo três bolhas, podem ser combinadas e representadas como um
módulo;
•  Uma única bolha pode ser ampliada em dois ou mais módulos;
•  Considerações práticas e critérios da qualidade de projeto determinam o resultado
da fatoração do segundo nível.
 Projeto Estruturado 34

•  Etapa 7: Refine o DEM usando os Critérios de Projeto para

obter uma melhor qualidade de software
•  Módulos são explodidos ou implodidos para produzir boa coesão,
mínimo acoplamento, fatoração coerente, alcance de efeito dentro do
alcance de controle.
 Projeto Estruturado 35

•  Característica principal: um único item de dados dispara um

ou uma série de fluxos de informação que afeta uma função
inferida no acionamento de item de dados (transação);

•  Exemplo de fluxo de dados orientado a transações é o “tipo de

comando”;

•  As etapas de projeto para análise de transação são semelhantes às

etapas de análise de transformação
•  Uma importante diferença é o mapeamento do DFD para o DEM (Diagrama
de Estrutura Modular);
 Projeto Estruturado 36

•  Etapa 1: Reveja o Modelo do Sistema Fundamental

•  Etapa 2: Reveja e Refine os DFD’s (se necessário)

•  Etapa 3: Determine se o DFD tem as características de fluxo

de transformação ou de transação

•  Etapa 4: Identifique o centro de transações e as

características ao longo de cada caminho de ação
•  O centro de transações encontra-se na origem de uma série de
caminhos de ação que fluem a partir dele;
•  O caminho de entrada e todos os caminhos de ação devem ser
isolados;
 Projeto Estruturado 37

•  Etapa 5: Faça o mapeamento do DFD em um DEM receptivo

ao processamento de transações
•  O fluxo de transações leva a um DEM com um ramal de entrada e um
ramal de despacho;
•  O ramal de despacho contém um módulo despachante que controla
todos os controladores de caminhos de ação subordinados;
Caminho de
Entrada Controle de transações
a Entrada recepção

b Despachante
Processa- b d
mento
d p
a c1
q
Despa- r
chante q r s

s Saída Organização
p do DEM
 Projeto Estruturado 38

•  Etapa 6: Fatore e Refine a estrutura de transações e a

estrutura de cada caminho de ação
•  Cada caminho de ação do DFD tem suas próprias características de
fluxo de informações (pode possuir fluxos de transformação ou fluxos de
transação);

•  Etapa 7: Refine o DEM usando os Critérios de Projeto para

obter uma melhor qualidade de software
 Critérios de Avaliação 39

Obtém a transação Uma das transações

(opção) desejada será realizada
Critérios de Avaliação 40
Critérios de Avaliação 41
Critérios de Avaliação 42
 Critérios de Avaliação 43

Critérios de
Avaliação de
Qualidade de um
Projeto Estruturado Projeto Estruturado

Critérios de Avaliação
 Critérios de Avaliação 44

•  Um dos princípios fundamentais do projeto estruturado:

•  Um sistema deve ser particionado em módulos mais simplificados;

•  Essa partição deve ser feita de tal maneira que:

•  1) Os módulos sejam tão independentes quanto possível (critério de
acoplamento);
•  2) Cada módulo execute uma única função (critério de coesão);

•  Entretanto, existem outros critérios para avaliar a qualidade de

uma solução projeto, tais como:
•  Fan-in;
•  Fan-out;
•  Alcance de efeito;
•  Alcance de controle.
 Critérios de Avaliação 45

•  Refere-se ao grau de interdependência entre dois módulos;

•  Objetivo: minimizar o acoplamento, isto é, tornar os módulos

tão independentes quanto possível;
•  Quanto menos conexões existirem entre módulos, menor a chance de
um efeito em cadeia
•  um erro em um módulo aparecer como sintoma em outro;
•  Cada mudança do usuário deve afetar o mínimo de módulos possível;

•  Acoplamento baixo/fraco = sistema bem particionado:

•  Nenhum módulo tem que se preocupar com detalhes da construção
particular interna de qualquer outro;
•  Os módulos são vistos pela sua função e “aparência externa”
•  caixas pretas – considera-se apenas o que entra e o que sai
•  parâmetros/argumentos e retornos;
 Critérios de Avaliação 46

•  Refere-se à intensidade da associação funcional dos

elementos em um módulo;
•  Objetivo: ter módulos fortes, altamente coesos, cujos elementos são
relacionados uns aos outros;

•  A certeza de que todos os módulos têm boa coesão é a

melhor forma de minimizar o acoplamento entre os módulos;

•  Boa coesão = as funções do sistema refletem as funções do

problema original;
 Critérios de Avaliação 47

•  O fan-in de um módulo é o número de superiores imediatos

que ele possui;
•  Ex: fan-in do módulo D = 3 A B C

•  Alto fan-in = ter uma função chamada por muitos superiores;

•  Evita a necessidade de codificar praticamente a mesma função em vários
lugares (em tempo de programação);
•  A função dupla de alteração é eliminada (em tempo de manutenção);
•  Quanto maior o fan-in, maior é o grau de reutilização do módulo e
consequentemente, menor será a complexidade da organização por
conter menos módulos individuais;
 Critérios de Avaliação 48

1.  Módulos com fan-in devem ter boa coesão funcional ou no

mínimo coesão comunicacional / coesão sequencial;

•  Coesão Funcional:
•  Todas as partes de um módulo trabalham em conjunto para executar
uma tarefa bem definida.

•  Coesão Comunicacional:
•  Partes internas de um módulo operam os mesmos dados de entrada ou
de saída, fazendo sentido agrupá-los, pois existe uma forte relação
entre eles.

•  Coesão Sequencial:
•  Os resultados de um componente de um módulo são a entrada para o
próximo componente do mesmo módulo.
 Critérios de Avaliação 49

2.  Cada interface para um único módulo deve ter os mesmos

tipos e número de parâmetros;

A
A
B L
P R

A
Módulo Interface
muito B C D
confuso
fan-out do módulo A = 3
•  O fan-out de um módulo é o número de subordinados imediatos para
aquele módulo.
 Critérios de Avaliação 50

•  Fan-out muito alto ou muito baixo é indicador de um projeto

pobre;
•  Quanto mais alto o fan-out, mais difícil será reutilizar o
módulo; Calcular
pagamento
líquido

Calcular Calcular Calcular Calcular

Calcular Calcular Calcular
Obter dados pagamento honorários impostos deduções
preço bruto impostos deduções
pagamento bruto trabalhado- trabalhado- trabalhado-
horistas normais normais
mensalistas res externos res externos res externos

•  Omissão do nível intermediário => o alto fan-out é corrigido

pela da fatoração de módulos de médio gerenciamento com
forte coesão e fraco acoplamento.
 Critérios de Avaliação 51

Módulos de médio
Móduos não Calcular gerenciamento
realocados pagamento
líquido fatorados

Calcular
Calcular Calcular
Obter dados pagamento líquido
pagamento líquido pagamento líquido
pagamento trabalhadores
horistas mensalistas
externos

Calcular Calcular Calcular Calcular

Calcular Calcular Calcular
pagamento honorários impostos deduções
preço bruto impostos deduções
bruto trabalhado- trabalhado- trabalhado-
horistas normais normais
mensalistas res externos res externos res externos

Móduos realocados
 Critérios de Avaliação 52

•  Avalie o DEM para reduzir o acoplamento e melhorar a coesão

•  Assim que uma estrutura de programa é desenvolvida, módulos podem ser
explodidos ou implodidos com o objetivo de melhoria da independência modular;

•  Tente minimizar estruturas com elevado fan-out e esforce-se para obter

fan-in à medida que a profundidade aumentar
•  DEM com módulos de controle e módulos altamente utilitários nos níveis mais
baixos;

Evite esta
estrutura Lute por esta estrutura
 Critérios de Avaliação 53

Todos os módulos que são

afetados por uma decisão tomada
em um determinado módulo

•  Mantenha o alcance de efeito de um módulo dentro do

alcance de controle desse módulo
Todos os módulos subordinados
a um determinado módulo, os
demais subordinados a estes, e
assim sucessivamente

Tomada de
decisão
Efeito da Tomada de
decisão decisão

Efeito da decisão Alcance de controle do

(alcance de efeito) módulo da tomada de decisão

Violação da heurística Modificação para satisfazer a heurística