NOME DO PROFESSOR: CLEITON FABIANO PATRICIO

COORDENADOR DE ENSINO TÉCNICO EM INFORMATICA: - NELSON FABBRI GERBELLI

ANALISE DE PROJETOS
EM
SISTEMAS DE INFORMAÇÃO

Aluno ___________________________________ Nº ___Turma ____ Habilitação _________

1
Para a disciplina: Analise de Projeto em Sistemas
Ano: 2°Modulo
Curso: Técnico em Informática

Prof.: Cleiton Fabiano Patricio

2
 INDICE

SISTEMAS ......................................................................................................... 4

1.1 Tipos De Sistema.............................................................................................................................4

1.1.1 Sistemas Naturais: ....................................................................................................................4
1.1.2 Sistemas Artificiais:..................................................................................................................4

1.2 Princípios Gerais Dos Sistemas .....................................................................................................5

1.2.1 Sistemas Automatizados (Sa’s) ................................................................................................6
1.2.2 O Sistema Empresa...................................................................................................................7
1.2.3 SISTEMAS DE INFORMAÇÃO (S.I.)....................................................................................8
1.2.3.1 TIPOS DE SISTEMAS DE INFORMAÇÃO ..........................................................................9
1.2.4 Dificuldades Na Automatização Dos Sistemas De Informação..............................................14

2 DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO....................... 15

3 ANALISE DE SISTEMAS .......................................................................... 20

4 DIAGRAMA DE FLUXO DE DADOS......................................................... 23

4.1.1 DIRETRIZES PARA A ELABORAÇÃO DE DFD ..............................................................26

5 DICIONÁRIO DE DADOS .......................................................................... 34

6 ESPECIFICAÇÃO DE PROCESSO........................................................... 41

7 TABELAS DE DECISÃO ........................................................................... 49

7.1 ÁRVORE DE DECISÃO .............................................................................................................52

3
 SISTEMAS

DEFINIÇÃO:
Conjunto uniforme de grupos de itens independentes em interação
regulamentada, tendo em vista a concretização de objetivo definidos.
Ou
Conjunto organizado de doutrinas, idéias ou princípios, normalmente com a
intenção de explicar a disposição ou um todo sistemático.

1.1 Tipos De Sistema

Tendo em conta que quase tudo com que contatamos pode ser visto como um
sistema, ou componente de um sistema, ou ainda ambas as coisas.
Podemos classificar os diversos sistemas segundo diferentes critérios:
1.1.1 Sistemas Naturais:
São sistemas que não tem qualquer interferência do homem para a sua
criação e engloba a maioria dos sistemas. Podemos, no entanto dividi-lo em dois
tipos:

• Sistemas Físicos: Sistemas astrais (Galáxias, Sistema Solar), Geológicos

(rios, cadeias montanhosas) ou sistemas moleculares (organização
complexa de átomos)

• Sistemas Vivos: Plantas ou animal incluindo o ser humano.

1.1.2 Sistemas Artificiais:
São sistemas construídos, organizados e mantidos pelo Homem.

Temos como exemplo:
a) Sistemas Sociais:
b) Sistemas Legislativos;
c) Sistemas de Transporte;
d) Sistemas de Comunicação;
e) Sistemas de Manufatura;
f) Sistemas Financeiros;
g) Sistemas de Informação.

4
 1.2 Princípios Gerais Dos Sistemas

1º Quanto mais especializado é o sistema menos capaz é de se adaptar a

circunstâncias diferentes.
2º Quanto maior for um sistema, maior o número de recursos que serão
destinados à sua manutenção diária.
3º Os Sistemas fazem sempre parte de sistemas maiores e podem ser
sempre divididos em sistemas menores.

5
1.2.1 Sistemas Automatizados (Sa’s)

São sistemas artificiais (construídos pelo homem) que interagem com

computadores, ou são controlados por um ou mais computadores.
Hoje em dia, muitos dos exemplos avançados sobre sistemas artificiais (SA’s)
incluem computadores.
Na realidade, muitos só existem graças aos computadores. Todavia, salienta-
se que tais sistema existem antes de haver computadores.
Alguns dos exemplos são totalmente não computadorizados (manuais) e
assim permanecerão nos próximos tempos. Outros incluem componentes
computadorizados e componentes manuais.

Componentes dos Sistemas Automatizados (SA’s)

Existem vários tipos de sistemas automatizados, mas todos têm componentes
em comum:
a) Equipamento computacional: Hardware (CPU, Terminais, Impressoras,
unidades magnéticas, etc.).
b) Suporte Lógico: Software (programas de sistemas, como sistemas
operacionais, sistemas de bancos de dados e programas de controlo de
telecomunicações, além dos programas aplicativos).
c) Pessoas: aquelas que operam com o sistema, que fornecem as entradas e
utilizam as saídas, e as que desempenham atividades de processamento
manual de um sistema.
d) Dados: as informações que o sistema conserva por um período de tempo.

6
1.2.2 O Sistema Empresa

A empresa constitui um sistema. Um sistema que, por sua vez pode ser visto
como um conjunto de três subconjuntos (subsistemas) inter-relacionados entre si.

1. SISTEMAS DE DECISÃO:
Sistemas com características homeostáticas atuando por medição das
variáveis de controlo do sistema; no qual decorre a definição das políticas, as
regras de gestão e as tomadas de decisão.
Ou seja é o sistema que determina os objetivo da empresa, descrevendo as
suas necessidades e formando todas as medidas (políticas e ações a seguir)
necessárias para que tais objetivo sejam alcançados.

2 SISTEMA DE EXECUÇÃO:
Sistemas onde se desenvolvem as atividades vocacionadas ao tratamento dos
acontecimentos elementares do sistema, e por onde fluem as informações de
entrada e saída deles decorrentes ou a eles associadas.
Ou seja. Sistema que formula e executa os caminhos a seguir e as ações a
tomar de acordo com as políticas definidas para que os objetivos previstos sejam
atingidos.

NOTA: Muitas empresa ainda possuem um outro subsistema que é o Sistema

Financeiro - Administrativo. Este estabelece as medidas a tomar de acordo com as
políticas definidas e também de acordo com o orçamento disponível para que os
objetivos sejam atingidos.

7
1.2.3 SISTEMAS DE INFORMAÇÃO (S.I.)

Sistema capaz de receber, processar, memorizar e produzir informação, de

modo a colocá-la à disposição dos utilizadores, quando e onde necessário.

SISTEMA DE INFORMAÇÃO

Sistema Sistema
Sistema
de De de
Decisão Comunicação Execução

Sistemas
Exteriores

O fluxo de informação entre os vários sistemas é assegurado pelo Sistema de

Comunicação, aqui representado como um subsistema do Sistema de Informação
da Empresa.

Características dos Sistemas de Informação:

1. Fornece aos seus utilizadores, sob forma de mensagens, representações da
realidade organizacional que não podem observar diretamente. Para isso o
sistema de Informação memoriza, trata e comunica os dados. (Função essencial
dos SI’s)
2. Na realidade organizacional produzem-se acontecimentos que transformam
tanto objetos concretos (produtos, matérias, imobilizados, pessoas, etc.), como
abstratos (encomendas, facturas, processos de recrutamento, etc.).
3. Os Dados são substitutos que permitem representar os valores que tomam as
propriedades das ocorrências bem definidas de objetos.
4. Pela Combinação de Dados, podem-se descrever os objetos e representá-los.
5. Os Objectos e as suas associações têm propriedades. Só se conhecem os
objectos e as suas propriedades indiretamente, por meio dos valores que
tomam as propriedades

8
 Para representar as diferentes situações da organização, é necessário descrever:

• Os Objetos, quer tomados isoladamente, quer considerados como

associações;

• Os Acontecimentos que traduzem as transformações sofridas pelos objetos,

ou as suas associações.

1.2.3.1 II. TIPOS DE SISTEMAS DE INFORMAÇÃO

1. SISTEMAS DE ACESSO DIRECTO (ON-LINE SYSTEMS);

2. SISTEMAS EM TEMPO REAL (REAL TIME SYSTEMS);
3. SISTEMAS DE APOIO À DECISÃO (DECISION-SUPPORT SYSTEMS);
4. SISTEMAS BASEADOS NO CONHECIMENTO (KNOWLEGE-BASED SYSTEMS).

1 SISTEMAS ON-LINE:
São sistemas que recebem entradas de informação diretamente do local onde
foi criada. São também os sistemas em que as saídas ou resultados do
processamento, são dirigidas diretamente para onde sejam necessárias.

PROCESSADOR

Os dados são
organizados de modo a
que possam ser
A saída é transmitida recuperados
para onde for necessário rapidamente

CARATERISTICAS:
a) Uma característica típica de um sistema On-Line é o fato de que os dados
são introduzidos no sistema de processamento e dele recebido
remotamente. Isto quer dizer que, os utilizadores do sistema de
processamento interagem com o computador através de terminais que
podem estar localizados a longas distâncias de outros terminais e do próprio
computador.
b) Os dados são armazenados e podem ser recuperados (consultados) e/ou
modificados rapidamente sem necessidade de aceder a outros dados do
sistema.
Ex.:
Registro de reserva de uma passagem aérea.
Registro individual sobre uma pessoa.

9
 Sistema On-Line, interage diretamente com as pessoas por isso é necessário
que o analista planeje cuidadosamente o interface Homem - Maquina.
Ex.:
Cartão de Crédito (Planear todas as operações perguntas e respostas e outras
possiveis situações).

2. SISTEMAS EM TEMPO REAL (REAL-TIME SYSTEMS)

Estimulo
Sistema
O
em AMBIENTE
Tempo Real
Resposta

Passagem
do Tempo

É o sistema que controla um ambiente pelo recebimento de dados, o seu

processmento e apresentação dos resultados com rapidez suficiente para afectar o
ambiente naquele momento.
Este sistema e o sistema On-Line são muito parecidos, a diferença está no
tempo de resposta ou no tempo de reacção por parte dos computadores. No caso
dos Sistemas On-Line é de 1 ou 2 segundos, no Sistema em Tempo-Real a reacção
é de milisegundos e ás vezes em microsegundos às entradas de dados recebidas.
Este sistema interage tanto com as pessoas como com o ambiente (Sistema
Informático), que é normalmente autónomo. A preocupação do analista é a rapidez
com que a resposta tem que ser enviada (instantaneamente) para que o ambiente
(SI’s) não se descontrole e provoque perda de dados que não se poderão
recuperar.

Ex.:

• Sistema de caixa automática (ATM) - as caixas electrónicas que usamos

para retirar e depositar dinheiro;

• Sistema de orientação de misseis - sistemas de processamento que

acompanha a trajectória de um missil e fazem continuos ajustamentos na
orientação e activação dos propulsores do missil;

• Sistema de comutação telefónica - sistemas de processamento que

monitoram voz e transmissão de dados entre milhares de chamadas
telefonicas, detectando os nºs discados, condições de no-gancho e fora-do-
gancho, assim como, as restantes condições de uma rede telefónica.

• Sistema de monitoração de pacientes - sistemas de processamento que

monitoram os diversos “sinais vitais”.

10
 CARACTERISTICAS:
a) Muitas actividades de processamento ocorrem em simultaneo;
b) Estabelecimento de diferentes prioridades para diferentes tarefas de
processamento;
c) Interrupção de uma tarefa de processamento antes de terminada, para que
outra tarefa com alta prioridade possa ser atendida.
d) Acesso simultaneo a dados de uso comum, tanto na memória principal
como na secundaria.
e) Uso dinâmico e alocação da memoria RAM no sistema de processamento,
visto não ser económico ocupar memória fixa para manipular situações de
pico de quantidade de dados.

3. SISTEMAS DE APOIO À DECISÃO ( DECISION-SUPPORT SYSTEM )

São sistemas de processamento que não tomam decisões por si próprios, mas
auxiliam gerentes e outros profissionais de uma organização a tomarem decisões
inteligentes e bem informadas sobre os vários aspectos da operação. Só são
utilizados quando existe necessidade.
CARACTERISTICAS:
a) Recuperam e apresentam dados. Executam diversas análises matemáticas e
estáticas sobre os dados.
b) Apresentam as informações sob varias formas gráficas (tabelas, diagramas).
Nota: Fornece informações relevantes em formatos adequados para que um
gerente possa tomar a decisão.
Ex.:
Folhas de Cálculo.

IDENTIFICAR
OPÇÕES ALTERNATIVAS

ESTABELECER
CRITÉRIOS DE AVALIAÇÃO

ESCALONAR AS OPÇÕES ALTERNATIVAS

CONFORME CRITÉRIOS

SELECCIONAR
A MELHOR OPÇÃO

11
4. SISTEMAS BASEADOS NO CONHECIMENTO (KNOWLEDGE-BASED
SYSTEMS)
São constituídos habitualmente para terem a capacidade de explicar as linhas
de raciocínio que conduzem às suas decisões. E alguns até explicam porque
rejeitaram certas sugestões e escolheram outras. Desta transparência surge a
credibilidade perante utilizador.
Ex.: Linhas de montagem automatizadas.

Nota: Também poder ser chamados por Sistemas Especializados.

III. GERAÇÕES DOS SISTEMAS DE INFORMAÇÃO

AUTOMATIZADOS

1ª GERAÇÃO:
Identificação dos Sistemas de Informação com as aplicações, implicando a
redundância dos dados; X
X X
SI1 SIn

PROGRAMAS PROGRAMAS
Mensagens Mensagens

R
E
... R
E
G G
I I
S S
T T
O O
S S

X X X
2ª GERAÇÃO:
Existência de ficheiros específicos para cada Sistema de Informação em
conjunção com as bases de dados partilhados por vários Sistemas de Informação;

BASE DE DADOS
X X
SI1 SIn

PROGRAMAS X PROGRAMAS
Mensagens Mensagens

R
E
... R
E
G G
I I
S S
T T
O O
S S

X X X 12
3ª GERAÇÃO:
Comunicação entre sistemas distintos através de mensagens.

BASE DE DADOS
X X
SI1 SIn

PROGRAMAS X PROGRAMAS
Mensagens Mensagens

R
E
... R
E
G G
I I
S S
T T
O O
S S

Mensagens Mensagens

X X X

BASE DE DADOS
X X
SIk1 SIkn

PROGRAMAS X PROGRAMAS
Mensagens Mensagens

R
E
... R
E
G G
I I
S S
T T
O O
S S

X X X

13
1.2.4 Dificuldades Na Automatização Dos Sistemas De Informação

As razões pelas quais os Sistemas de Informação não devem ser

automatizados são:

1. Custo - pode ser mais barato manter o antigo sistema manual de

execução de funções e armazenamento dos dados, do que adquirir
computadores que por vezes não são mais rápidos nem mais baratos que
o sistema anterior.
2. Conforto - Um sistema automatizado pode ocupar demasiado espaço,
fazer muito ruído, gerar muito calor ou consumir eletricidade demasiada.
3. Segurança - Se o sistema de informação mantém dados importantes e
confidenciais, o utilizador pode achar que o sistema automatizado não seja
suficientemente seguro, preferindo manter a capacidade de guardar
informações fisicamente e fechadas á chave.
4. Manutenção - O utilizador pode argumentar que o sistema
computadorizado é econômico, mas que não existe ninguém que possa
manter o Hardware e/ou o Software do computador, de forma que não
haveria ninguém capacitado para reparar o sistema ou efetuar
modificações ou mesmo melhoramentos no sistema.
5. Política - A comunidade de utilizadores pode achar que os computadores
são uma ameaça aos seus empregos ou que tornam o seu trabalho
mecânico. Mesmo que estas razões nos pareçam absurdas é certo que o
sistema pertence aos utilizadores e se estes não o aprovarem nem o
quiserem tudo farão para que o sistema fracasse.

14
 2 Desenvolvimento De Sistemas De Informação

Qualquer organização sente necessidade de alterar os seus objetivo,

aumentar, eliminar ou mesmo modificar os componentes dos sistemas que a
compõem.
Com os Sistemas de Informação acontece o mesmo. E como uma alteração no
Sistema de Informação afeta em profundidade o comportamento dos outros
sectores, tem que se ter muito cuidado com o seu desenvolvimento ou mesmo com
a alteração dos seus componentes.
Há que planificar e estruturar cuidadosamente o plano de desenvolvimento.

• CICLO DE DESENVOLVIMENTO
A análise, o projeto e a implementação de novos sistemas consiste em tomar
uma série de medidas e atitudes que em conjunto se dá o nome de ciclo de
desenvolvimento.
Existe normalmente uma equipa especial para realizar o ciclo de
desenvolvimento. Essa equipa, tem objetivo e organização próprios e é formada por
membros de cada uma das partes da organização que vão ser atingidas ou servidas
pelo sistema. Nela fazem partes especialistas em análise de sistemas, projectistas e
programadores vindos do departamento de processamento de dados.
Esta equipa está sujeita a uma observação periódica através de um grupo de
executivos, que determinam a continuidade do trabalho a desenvolver, a sua
interrupção, ou mesmo uma mudança nos seus objetivos.
O período de desenvolvimento está dividido em varias etapas:
A) Analise
1. Estudo do sistema;
2. Proposta de soluções;
3. Estudo de viabilidade;
B) Projeto
4. Definição das necessidades funcionais;
5. Preparação das especificações para a implementação;
C) Implementação
6. Programação;
7. Instalação;
8. Conversão.

Métodos do Ciclo de Desenvolvimento

As diversas etapas pelas quais o ciclo de desenvolvimento está dividido, estão
sujeitas a avaliação que permitem o seguimento ou a interrupção das mesmas
etapas.

15
ANALISE
1. Estudo do sistema
Concentra-se na revisão e análise das necessidades que foram previamente
identificados como problemas organizacionais e que foram ainda resolvidas pelos
sistemas existentes. São levantadas informações detalhadas sobre o fluxo das
informações e sobre decisões tácticas tomadas pelos sectores organizacionais
causadores dos problemas identificados ou que por eles foram afetados.
O objetivo é isolar e entender as causas dos problemas, e como eles levam a
ineficiência das operações, á perda de informação por decisões tácticas tomadas
pelos sectores da organização causadores de problemas.
O resultado é um Relatório de Estudo do sistema que documenta a analise
executada e recomendada ou a não continuação do ciclo de desenvolvimento.
Os estudos devem levar em conta os objetivo da organização, a sua estrutura
administrativa, os grupos de trabalho e os procedimentos formais e informais.
1º Passo
Determinar o que deve ser feito por uma determinada área para que possa
colaborar adequadamente com a organização para que assim como um todo, sejam
atingidos os seus objetivo.
2º Passo
Determinar Como é feito. Deve identificar as alternativas pelas quais as
mesmas coisas poderiam ser feitas e compará-las com o existente de forma a
esclarecer as ineficiências e identificar as melhorias que possam ser introduzidas.

2. Proposta de Soluções
Estabelecer as intenções, raio de ação e custos do novo sistema a ser
desenvolvido. O resultado final desta fase é o documento formal chamado Proposta.

• Natureza das mudanças

Define as funções a serem alteradas; descreve as novas atividades e o
pessoal que utilizará o novo sistema;
Compara os métodos do sistema corrente com os do sistema proposto.

• Descrição
Descreve os procedimentos operacionais propostos, tanto manuais como
automáticos; estabelece os objetivos a serem alcançados pelo novo sistema.

• Considerações econômicas
Identifica os custos de desenvolvimento e instalação do novo sistema, os
custos estimados da operação após a instalação e as eventuais economias
conseguidas com o novo sistema

• Plano de desenvolvimento
Estabelece um plano para os estágios subseqüentes do ciclo de
desenvolvimento.
Especifica as necessidades de pessoas, de programação e de
gerenciamento do desenvolvimento.

16
Nota: Através da avaliação da proposta é determinado se o sistema é conveniente
ou não.

3. Estudo de Viabilidade
A parte das “considerações econômicas” da proposta é alargada até aos mais
pequenos detalhes.
São feitas projeções do movimento de caixas de retorno do investimento e
outras considerações econômicas.
Os dados financeiros relevantes são analisados por especialistas de
administração para determinar o custo da implantação da proposta prevista para a
organização.
E verificar também através de especialistas financeiros os benefícios que
poderá trazer o novo sistema.

PROJETO:
4. Definição das necessidades funcionais
Produz um documento formal que contenha uma descrição mais detalhada da
proposta, com os seguintes pontos:
1. Descrição detalhada das funções:
Descrição de todas as principais funções a serem realizadas pelo sistema,
bem como o modo pelo qual elas se relacionam entre si e com os restantes
componentes da organização.
2. Performance desejada
Níveis esperados de precisão, tempos de respostas dos terminais de
computadores e limites para o tempo de processamento.
3. Entradas e Saídas desejadas
Documentos, formulários e transições executados pelos utilizadores e as
saídas a serem produzidas, incluindo detalhes dos itens de dados.
4. Ligações com outros sistemas de processamento de dados
Interdependências entre os diversos sistemas.
5. Disponibilidades de dados
Recurso necessário de avaliação e retenção dos registros e dos itens de
dados.
6. Volume de transações
Estimativa do volume de transações a serem executadas.

17
5. Preparação das Especificações para a Implementação
Aqui se produz um projeto detalhado do Sistema, especificando-se toda a
informação envolvida. Os registros e os dados são descritos, incluindo-se o
tamanho, tipo e valor que podem assumir individualmente, regras de validação e
para as relações com outros registros ou dados. As entradas e as saídas têm que
ser especificadas de forma a determinar a disposição de cada dado em formulários
ou em listagens.
Todos estes valores (validos de entrada e de saída), bem como as respostas
do sistema a cada entrada possível, são fornecidos ao utilizador.
Todos os procedimentos são escritos o mais claramente possível, com um
considerado nível de detalhe (Analise descendente TOP-DOWN), de modo a que
possam ser escritos os manuais e os programas de computadores.
Evitar as ambigüidades e a não especificação de detalhes.

IMPLEMENTAÇÃO
6. Programação

Todos os procedimentos a serem seguidos tanto pelos operadores quanto pela

máquinas tem que ser escritos.
São obtidos os seguintes resultados:
a) Programas de computadores:
Os programas são escritos e testados de forma a se garantir que o Hardware
aceite os dados, os processe, os armazene e que produza saídas conforme as
especificações para a implementação.
b) Procedimentos com o computador:
São produzidas instruções para a manutenção e operação dos novos
programas, revistas pelo pessoal responsável.
c) Procedimentos com o utilizador:
São produzidos e testados manuais para descrever os novos programas.
d) Cursos de Formação:
São preparados e aplicados cursos para a formação dos utilizadores do novo
sistema.
e) Documentação do Sistema:
Todo o material necessário para ajudar a perceber, usar ou modificar o novo
sistema que é desenvolvido e aprovado.
f) Planificação do teste:
São feitos detalhes sobre a forma de como será testado o sistema na fase de
implementação, as entradas a serem utilizadas e os resultados esperados.

18
7. Instalação
Instalação dos equipamentos, do Software e testes exaustivos de
funcionamento.
Nesta fase ambos os sistema ( novo e velho ) estão implantados sendo
testados paralelamente, podendo-se assim verificar a eficiência do novo sistema.
Se houver mal funcionamento do novo sistema revelado nos testes, há
necessidade de trabalho suplementar no projeto e na correção dos programas.

8. Conversão / Manutenção

Aqui dá-se a passagem do sistema antigo para o novo sistema novo.

É desejável que a equipa conhecedora dos dois sistemas esteja presente e
acompanhe os vários grupos de trabalho durante a transição.
Dois métodos para a conversão:

• Instantânea: Todos os utilizadores da empresa passam a utilizar o novo

sistema.

• Incremental: Grupos isolados de utilizadores ou de funções passam a ser

gradualmente atendidos pelo novo sistema.

19
 3 ANALISE DE SISTEMAS

ANALISE DE SISTEMAS: É o estudo dos objetivos do sistema como um todo, dos

procedimentos que o envolvem, da sua estrutura, dos fluxos de informação
que estabelece o seu desempenho e as suas deficiências.

Atividades da Analise do Sistema: Uma vez compreendido como um sistema

interage com os outros, o analista deve preocupar-se com o sistema em si.
Identificar cada um dos seus componentes, examinando-os com cuidado de
forma a levantar todos os detalhes respeitantes à sua natureza,
funcionamento e relação com outros componentes.
Etapas necessárias:
1. Determinação dos Objetivos: Antes de qualquer análise é necessário
estabelecer uma base para decidir o que se pretende que o sistema faça
tendo em conta os objetivos de cada um dos sectores da organização. Com
estes objetivos e as relações entre departamentos, pode-se estabelecer os
objetivos do sistema como um todo.
2. Levantamento de informações sobre os métodos utilizados: Antes de
se tirar conclusões sobre os problemas ou deficiências do sistema pré-
existente, deve-se compreender e documentar todos os fatos relacionados
à execução dos procedimentos, à manutenção das informações e ao
processo de tomada de decisão.
3. Análise das inter-relações: Os dados encontrados devem agora ser
organizados, analisados e comparados com os de sistemas similares, de
forma a serem facilmente entendidos. Os fatores críticos para o
desempenho da organização vão ser identificados e passar a merecer toda
a atenção.
4. Determinação dos dados necessários: Determinar a melhor disposição
do fluxo de informação. Quem precisa de qual informação? Quem fornece
os dados? Quem processa os dados e obtém os resultados? Fazer por quê?
5. Definição dos procedimentos necessários: São propostas várias
alternativas pelas quais os processos poderiam ser realizados; um ou mais
cursos de ação devem ser apresentados.
Ferramentas para a Análise de Sistemas:
Para se fazer uma análise é necessária se recorrer à utilização de ferramentas
e técnicas próprias, de forma a garantir a obtenção de dados completos e
acertados de modo a que se possa chegar a conclusões corretas. Estas são as
ferramentas freqüentemente utilizadas:

20
1. Entrevistas: Esta é a técnica mais utilizada para a obtenção de informação
sobre um sistema existente, através de entrevistas com os utilizadores do
sistema. Deve-se tentar extrair opiniões sobre as tarefas que desempenham, ou
que acham que deviam desempenhar e como a desempenham.
2. Questionário: Uma ferramenta bastante eficaz, pois pode obter informações
sobre os detalhes da organização, visto que os consultados permanecem
anônimos, o que possibilita respostas mais honestas e mais tempo para pensar
nas respostas.
3. Diagramas Funcionais: Técnica usada para identificar cada uma das partes de
um sistema. Apresenta um sistema decomposto nos seus componentes,
começando por uma descrição geral passando e por um detalhe contínuo de
cada um dos subsistemas, através da técnica (Top-Down).
O diagrama começa por um único bloco que identifica a função geral do sistema.
O nível inferior seguinte subdivide a função geral em outras menores, mas ainda
não detalhadas. Apartir dai, cada nível sucessivo subdivide cada vez mais a
função a que está ligado e o processo continua até que não haja necessidade
para mais detalhe. Quando o nível mais baixo estiver atingido, cada bloco
documenta uma função em entradas, saídas e etapas de processamento.
4. Diagramas de Fluxo de Dados: Determina o modo pelo qual a informação é
manipulada, bem como as transformações que sofre, e a documentação do fluxo
de dados entre os centros de processamento e os centros de tomada de
decisões.
Quando uma informação é alterada como resultado de um processamento ou de
uma decisão, diz-se que houve uma transformação.
Um conjunto completo de diagramas, mostra toda a rede de informações que é
toda a organização.
5. Mapas Estruturais: Estes mostram a movimentação dos dados e o controle
adequado das funções através das setas. As setas ligam um bloco superior aos
blocos subordinados indicam o controle das funções. A seta mais longa indica um
ciclo repetitivo e as setas menores mostram o fluxo dos dados de um módulo
para outro. Os círculos pequenos, em branco, indicam os dados, como o nome,
endereço, número de pedido e data. Os círculos cheios indicam que os dados
passam para o controle da informação (ex. o numero de vezes que uma
operação deve ser repetida).
6. Diagramas CPM e PERT: Definem a organização temporal das tarefas e as suas
inter-relações. Ex. para jantar, é necessário que antes este tenha sido
preparado. Por outro lado após ter jantado é necessário que sejam lavados os
pratos, talheres, etc. Existem dependências entre preparar o jantar, come-lo e
limpar a louça. Podemos escrever esta dependência pelo diagrama: Incluindo o
tempo necessário para a execução de cada um dos passos. Os círculos (nós)
Representam pontos onde as tarefas anteriores estão terminadas.
PERT- é um método para o controle regular de todas as partes responsáveis pelo
término das tarefas, para definir ou redefinir o caminho critico necessário.

21
7. Diagrama Entidade-Relação: Descreve em detalhes a informação que está
contida nos arquivos de dados e também as relações que existem entre eles.
Importantes componentes:
Tipos de objetos, representados por um retângulo. Uns objetos representam uma
coleção, um conjunto ou coisas do mundo real que desempenham um papel no
sistema.
Relações, são representados por losangos. Uma relação representa um conjunto
de conexões ou associações, entre os tipos de objetos interligados por setas às
relações. É necessário se proceder a um detalhe do DER com informações
textuais.

22
 4 DIAGRAMA DE FLUXO DE DADOS

Os DFD podem ser usados não só para modelar sistemas de processamento de

informações, mas também como um meio de se modelar organizações inteiras, isto
é como uma ferramenta para o planejamento comercial e estratégico.
Vamos formular diretrizes para a construção de diagramas de fluxos de dados para
que se possa minimizar possibilidade de construirmos um DFD confuso, incorretos
ou inconsistentes. Vamos também discutir o conceito de DFD’s nivelados como um
método de modular sistemas complexos.

COMPONENTES DE UM DFD:
• Não necessita de explicações; basta olharmos para ele para compreendê-lo. A
representação é simples e sem intrusões e, de certa forma, bastante intuitivo.
• O diagrama acomoda-se facilmente numa página. Isso tem dois significados. 1º:
Uma pessoa pode examinar o diagrama sem se confundir e, 2º: o sistema que
está a ser moldado não é muito complexo. Que fazer se o sistema for tão
complexo que haverá centenas de círculos e linhas no diagrama?
• Um diagrama desenhado por computador é mais exato e mais padronizado do
que se fosse desenhado á mão e as alterações podem ser feitas e novas versões
podem ser produzidas em questão de minutos.

1. O Processo,
O primeiro componente de um DFD é conhecido como processo. O processo
mostra uma parte do sistema, que transforma entradas em saídas - ou seja,
mostra uma ou mais entradas que são convertidas em saídas. O Processo é
representado por:

Calcular
Imposto
sobre
Renda

1. Processo
O processo é denominado ou descrito com uma única palavra ou sentença simples.
A designação do processo descreve o que o processo faz. Um bom nome é
geralmente composto por uma frase constituída de um verbo e de um objeto, tal
como VALIDAR ENTRADA ou CALCULAR VALOR IMPOSTO.
O processo contém o nome de uma pessoa ou de um grupo de pessoas (um
departamento ou divisão de uma empresa), ou de um computador ou de um
dispositivo mecânico. Ou seja, o processo às vezes descreve quem ou o que o
executa o processo, em vez de descrever o que o processo é.

23
2. O Fluxo,
O fluxo é graficamente representado por uma seta que entra ou sai de um
processo. O fluxo é utilizado para mostrar o movimento de fragmentos ou pacotes
de informações de um ponto a outro do sistema, Deste modo, o fluxo representa
dados em movimento, enquanto os arquivos representam dados em repouso.

2. Fluxo de dados
Na maioria dos sistemas os Fluxos, representam dados, isto é, bits, caracteres,
mensagens, números de ponto flutuante e os diversos tipos de informação com que
lida o computador. Os DFD’s podem também ser utilizados para moldar uma linha
de montagem onde não haja componentes computadorizados.
Nas figuras abaixo estão representados os fluxos que têm nomes. O nome
representa o significado do pacote que se move no fluxo. O fluxo transporta apenas
um tipo de pacote, o que é indicado pelo nome do fluxo. Não se deve atribuir a um
fluxo de dados um nome como MAÇÃS E LARANJAS E VARIAS OUTRAS
COISAS. Podemos ter no entanto um fluxo de dados denominado VEGETAIS, em
vez de vários fluxos diferentes rotulados como BATATAS, CEBOLAS e ERVILHAS.

Mistura para Bolos

Ovos
Leite Preparar Bolo
Bolo
Açúcar

3. Fluxos de materiais

Não será demais dizer que o mesmo conteúdo pode ter significados diferentes em
pontos diferentes do sistema.
O fragmento de dados (ex. 212 4456), tem um significado quando passa pelo fluxo
com o nome de NUMERO-DE-TELEFONE e outro quando passa pelo fluxo
denominado por NUMERO-DE-TELEFONE-VALIDO. No primeiro caso indica que o
número de telefono pode ser valido ou não, enquanto que o segundo indica que o
número de telefone é valido dentro do contexto.

NUMERO-DE-TELFONE-VALIDO
VALIDAR
NUMERO-DE-TELFONE NUMERO
DE
TELEFONE

NUMERO-DE-TELFONE-INVALIDO

4. Um DFD típico

24
Podemos dizer que o fluxo denominado “numero de telefone” é capaz de permitir a
passagem indiscriminada de números de telefone validos ou inválidos, através dele,
enquanto que o fluxo “NUMERO-DE-TELEFONE-VALIDO” é mais discriminativo,
permitindo que passe por ele apenas um conjunto definido de dados.

3. Arquivo,
O arquivo é utilizado para moldar uma colecção de pacotes de dados em repouso. A
representação gráfica de um arquivo é um rectângulo como mostra na figura 5. O
nome escolhido para o arquivo é geralmente o plural dos nomes dos pacotes
transportados pelos fluxos de dados para dentro e para fora do arquivo.

D1 PEDIDOS

5. Representação de Arquivo
Os arquivos são muitas vezes implementados em sistemas computadorizados; mas
um arquivo pode também conter dados armazenados em cartões perfurados,
microfilmes, microfichas, discos ópticos, etc.

• Arquivo existe como uma necessidade de armazenamento de espera entre dois

processos que ocorrem em momentos diferentes.

• O arquivo permite que a entrada de pedidos seja feita em momentos diferentes

do processo de consulta a pedidos.

DETALHE DE PEDIDOS
CONSULTA

PEDIDO PEDIDO
INTRODUZIR
PEDIDOS RESPONDER
PEDIDO PEDIDO

RESPOSTA

6. Um arquivo necessário.
Um arquivo apresenta-se num DFD como:

• Um fluxo de um arquivo;
• Um fluxo para um arquivo.
Um fluxo é normalmente interpretado como uma leitura ou acesso feito às
informações desse arquivo, Isto pode significar que:
Fluxo de um arquivo:

• Um registro isolado de dados foi recuperado do arquivo; um fluxo que sai do

arquivo envolve a recuperação do registro de informação;

• Mais de um registro foi recuperado do arquivo, podem-se recuperar registros

de vários clientes ao mesmo tempo;

• Apenas parte do registro foi recuperado do arquivo. Apenas se quer o número

do telefone;

• São recuperadas mais que uma parte de vários registros. Clientes com o
código postal x.
Fluxo para um arquivo:

25
 • Um ou mais registros podem ser introduzidos no mesmo arquivo;
• Um ou mais registros podem ser eliminados ou removidos no mesmo arquivo;
• Um ou mais registros podem ser alterados ou modificados no mesmo arquivo,
pode ser alterado parte ou a totalidade do registro;

4. Entidades Externas (Terminadores),

Entidade Externa é representada graficamente por um retângulo. Estas
comunicam com o sistema. Normalmente é uma pessoa ou um grupo de pessoas,
uma empresa do governo, um grupo ou sector que esteja dentro da mesma
organização, mas fora do controle do sistema que está a ser moldado. Em alguns
casos também as entidades externas podem ser outro sistema. Ex. Um sistema de
processamento com o qual o nosso sistema comunica. Três aspectos a ter em
conta:
a) Elas são externas ao sistema que estamos a moldar; os fluxos que interligam as
entidades aos diversos processos do nosso sistema representam uma interface
entre o mundo exterior e o sistema.
b) As entidades não podem ser alteradas nem modificadas o seu conteúdo ou nem
mesmo o modo de como funciona. O analista não pode modificar o conteúdo ou
a organização ou mesmo os procedimentos relativos às entidades externas.
c) Qualquer relacionamento existente entre as entidades externas não constará
nos DFD’s. Alguns relacionamentos podem existir, mas, por definição elas não
podem fazer parte do sistema que se está a investigar. Por outro lado se
existirem relacionamentos entre entidades externas e se for essencial que o
analista de sistemas os molde para documentar de forma corretas os requisitos
do sistema, então por definição as entidades externas devem ser moldadas como
processos.

4.1.1 DIRETRIZES PARA A ELABORAÇÃO DE DFD

As diretrizes ajudam-nos a construir DFD’s corretos, a desenhar DFD’s agradáveis á

vista, assim podem ser examinados pelos utilizadores com mais atenção.
As diretrizes são as seguintes:
1. Escolher nomes significativos para os processos, fluxos, arquivos e entidades
externas.
2. Numerar os processos.
3. Refazer os DFD tantas vezes quantas forem necessárias até obter uma boa
estética.
4. Evitar DFD complexos demais.
5. Certificar-se de que o DFD seja internamente consistente além de manter a
consistência com os outros DFD.

26
 DIRETRIZES PARA ELABORAÇÃO DE DFD´s

1. ESCOLHER NOMES SIGNIFICATIVOS PARA OS PROCESSOS, FLUXOS,

ARQUIVOS E ENTIDADES EXTERNAS

Um processo representa uma função que está a ser executada ou pode indicar
como a função vai ser executada. É necessário que se rotule (dar nome) o
processo para que os utilizadores sejam capazes de identificar os mesmos e que
estes aprovem o modelo escolhido.
É de evitar nomes de pessoas de grupos ou funções políticas.
Devem-se rotular os processos com as funções que o sistema executa.
O melhor método para o nome do processo é utilizar o verbo e um objetos.
Encontrar um verbo que represente a ação e uns objetos adequados de modo a
formar uma frase descritiva do processo.
Ex.:

• Calcular Trajetória do Míssil;

• Produzir Relatório de Inventario;
• Validar Número de Telefone;
• Designar Alunos para Salas.

Os nomes escolhidos para os processos, para os fluxos e entidades externas devem

surgir de um vocabulário usado pelo utilizador. Isto acontece naturalmente depois
da série de entrevistas feitas ao o utilizador.
Devem ser tomadas duas precauções:
a) Devem ser evitadas expressões típicas dos utilizadores de modo a que o DFD
possa ser lido por pessoas de sistemas diferentes.
Ex.:
Se for um banco, é importante que os trabalhadores de outros bancos
compreendam o desenho do DFD.
b) Se o desenho do DFD for feito por um programador este usará expressões tais
como: Rotina, Subsistema e Função. Esta situação deve ser evitada a não ser
quem for desenhar o DFD ouça os utilizadores a usarem tais expressões.
2. NUMERAR PROCESSOS
Método mais prático de referenciar os processos é numerá-los sem regra precisa -
desde que seja consistente no modo como se atribui os n.ºs.
A numeração do DFD representa para o leitor uma seqüência de execução. O que
não é verdade, pois o DFD é uma rede de processos assíncronos que se
intercomunicam. Numa certa seqüência pode-se ver uma presença ou ausência de
dados (Ex.: pode ser visível que o processo 2 não possa executar a sua função
antes de receber dados do processo 1), mas o esquema de numeração nada tem a
ver com isso.

27
Os processos são numerados, para que seja mais fácil a sua identificação. Ainda
mais importante, os números são a base para o esquema de numeração hierárquica
quando representamos diagramas de fluxo de dados nivelados.

3. EVITAR DFD´s COMPLEXOS

Os objetos de um DFD é moldar corretamente as funções que um sistema deve
executar e as iterações entre elas. E também ser lido e compreendido, não somente
pelo analista como pelos seus utilizadores.
Isto quer dizer que um DFD deve ser compreendido e facilmente absorvido e
agradável ao olhar.
Não criar um DFD com demasiados processos, arquivos, fluxos e entidades
externas. Isto quer dizer que não deve incluir mais de uma dúzia de processos,
fluxos, arquivos e entidades externas a eles relacionadas num único DFD. Ou seja,
tudo isto tem que ser acomodado confortavelmente numa folha de papel A4.
A não ser que se fale nos diagramas de contexto onde estão representadas as
entidades externas e um único processo.

4. REFAZER O DFD TANTAS VEZES QUANTAS FOREM NECESSÁRIAS

O DFD terá que ser feito, refeito e novamente refeito, até que seja:
4.1. Tecnicamente correto;
4.2. Aceitável pelo utilizador;
4.3. Tão bem desenhado que não nos sentimos constrangidos ao mostrá-lo a
outras pessoas.
O que torna o DFD esteticamente agradável depende da opinião e gosto pessoal e,
também de determinados padrões estabelecidos pela empresa ou pelas
características de algum pacote automatizado.

Problemas que podem surgir:

a) Tamanho e forma dos processos:
Os processos devem ter todos os mesmo tamanhos. Caso um circulo do
processo seja maior que outro, pode dar a entender que o circulo maior é mais
importante que o menor.
b) Fluxos de dados curvos versus fluxos de dados retos:
Depende de uma opinião pessoal, mas convém que sejam retos e que não se
verifique cruzamento entre os fluxos.
c) Diagramas desenhados à mão versus diagramas gerados por maquina:
Dentro de poucos anos o desenho dos diagramas será feito por sistemas de
processamento gráfico. No entanto hoje em dia os diagramas ainda são
desenhados á mão.
O problema é a reação do utilizador, pois alguns preferem os DFD’s desenhados
pela máquina pois parecem mais limpos enquanto outros preferem as figuras
desenhadas á mão, porque lhes dá a sensação de que o desenho dos
diagramas não está terminado e que podem aceitar alterações.

28
5. Certificar-se de que o DFD seja logicamente consistente:
Algumas diretrizes para um DFD consistente:
a) Evitar os poços sem fundo – círculos que têm entradas mas não têm saídas.

a x
PROCESSAR

CONTEÚDO
b y

c) Evitar círculos com geração espontânea – círculos que não têm entradas e
só têm saídas, são geralmente incorretas. Um exemplo aceitável seria um
gerador aleatório de números.

a PROCESSAR x

CONTEÚDO

c) Cuidado com fluxos e processos sem nome:

No caso de um fluxo, pode significar que vários elementos de dados não
relacionados foram arbitrariamente reunidos.
No caso de um processo, pode significar falta de atenção ou tentativa de disfarçar
uma situação anômala no DFD.

b) Cuidado com arquivos de leitura - apenas ou de escrita - apenas:

Um arquivo deve ter sempre entradas e saídas. A exceção está apenas quando se
trata de um arquivo externo.

Arquivo apenas de escrita

Arquivo apenas de Leitura

29
 DFD COM NIVEIS

Para que se possa solucionar o problema de DFD’s complexos, divide-se o DFD em

vários níveis, para que desta forma cada nível inferior ofereça mais detalhe sobre a
parte do nível superior.
O nível mais alto consiste num único círculo, que representa o sistema inteiro; os
fluxos de dados mostram as interfaces entre o sistema e as entidades externas.
Este DFD especial é conhecido como Diagrama de Contexto.
O DFD imediatamente abaixo do Diagrama de Contexto é conhecido como figura 0.
Ele representa a visão do mais alto nível das principais funções do sistema bem
como as principais interfaces entre essas funções.
Os números servem para se relacionar um círculo (processo) com o DFD de nível
imediatamente inferior que descreve esse processo de um modo mais complexo.
Ex.: (Fig.1)

• O processo da figura 1 está associado ao DFD de nível inferior conhecido como

figura 2. Os processos da figura 2 são numerados como 2.1, 2.2, 2.3, etc..

• O processo 2.2 da figura 2 está associado ao DFD de nível inferior conhecido

como figura 2.2.
Os processos da figura 3 são numerados 3.1, 3.2, 3.3, etc..

• Se o processo tiver um nome (o que deve acontecer), então esse nome é

transportado para a figura de nível imediatamente abaixo. Assim se o processo
2.2 tiver o nome de CALCULAR TAXA DE VENDAS, então a figura 2.2, que
subdivide o processo 2.2 mais detalhadamente, deve ter o nome de “Figura 2.2:
CALCULAR TAXA DE VENDAS”.
Apesar de este modo ser bastante direto de se organizar o DFD existe outras
coisas que devem ser acrescentadas a essa descrição da subdivisão em níveis:
1. Como saber quantos níveis deve ter um DFD?
A figura do DFD não deve ter mais de meia dúzia de processos e de arquivos
a eles relacionados. Assim se já tivermos o sistema subdividido em três níveis
e no nível mais baixo do DFD ainda tivermos 5 processos em cada um, deve
ser estabelecido pelo menos mais de um nível abaixo desse. Outra forma
seria a especificação de processos.
2. Existem diretrizes sobre o número de níveis que devem ser esperados
num sistema típico?
Um sistema simples encontra-se provavelmente dividido em três níveis ou
mesmo dois. Os níveis aumentam mediante a complexidade do sistema,
sabendo que o número total de processos cresce exponencialmente quando
passa para o nível imediatamente inferior.
3. Todas as partes do sistema devem ser subdivididas até ao mesmo
nível de detalhe?
Não, pois alguma parte de um sistema podem ser mais complexas que
outras e podem exigir também a subdivisão em mais partes ou dois níveis.
No entanto não é aconselhável que haja uma disparidade muito grande de
subdivisão de processos.
Ex.:
30
Se o processo 2 da figura 0 do nível mais elevado for primitiva, enquanto o
processo 3 requer uma subdivisão em sete níveis, isto quer dizer que o
modelo geral é assimétrico e foi provavelmente mal organizado. Há que
transferir algumas partes do processo 3 para outro processo separado ou
talvez redesenhá-lo no processo 2.

O
SISTEMA
1 2

DIAGRAMA DE CONTEXTO 3 4

FIGURA 0

3. 3.
1 2

Fig. 1 - DFD com níveis

3. 3.
3 4

FIGURA 3

31
4. Como se mostram esses níveis para o utilizador?
Muitos utilizadores só querem ver um diagrama. Um utilizador executivo
de alto nível pode querer ver apenas o diagrama de contexto ou talvez
a figura 0, enquanto que um utilizador de nível operativo pode querer
ver apenas a figura que descreve a área do sistema em que esteja
interessado. Se alguém estiver interessado em ver grande parte do
sistema ou o sistema inteiro, são lhe apresentados os diagramas na
metodologia Top-Down: começando pelo diagrama de contexto,
descendo aos níveis de mais detalhe.
É prático ter os dois diagramas lado a lado para se poder mostrar.
5. Como garantir que os níveis dos DFD’s são consistentes entre si?
O aspecto de consistência é muito importante porque os diversos níveis
dos DFD’s são normalmente desenvolvidos por pessoas diferentes nos
projetos do mundo real.
Para garantir a consistência com a figura do nível superior, existe uma
regra simples: os fluxos de dados que entram e saem de uma figura
inteira do nível imediatamente superior devem corresponder aos fluxos
que entram e saem de uma figura imediatamente inferior que descreve
aquele processo.
Exemplo explicativo na Fig. 2.
6. Como mostrar os arquivos nos diversos níveis?
Existe a seguinte diretriz: mostrar um arquivo no nível mais alto onde
serve como interface entre dois ou mais processos; em seguida mostrá-
lo em cada diagrama de nível inferior que descreva (ou subdivida) os
processos em interface. Fig. 3.
Um corolário: os arquivos locais, utilizados apenas pelos processos de
uma figura de nível inferior, não serão mostrados nos níveis superiores,
porque estarão incluídos num processo de nível imediatamente superior.
7. Como realmente se faz a subdivisão dos DFD’s em níveis?
É típico que os DFD’s sejam apresentados segundo a metodologia Top-
Down, esta é intuitiva e atraente. Mas neste caso podem existir
problemas na abordagem desta metodologia, por isso é melhor que se
identifique primeiro os eventos externos aos quais o sistema deve reagir
e usar estes eventos para criar em esboço do DFD. Podendo a
subdivisão ser feita Down-Top (para os níveis mais altos) e Top-Down
(para os níveis mais baixos).

32
 A
B
A B
O 1 2
SISTEMA

C
x
y

DIAGRAMA DE CONTEXTO 3 4
z
C

x FIGURA 0

3. 3.
1 2

3. 3.
3 4
y
z

FIGURA 3
4.1.1.1.1.1.1.1
4.1.1.1.1.1.1.2 Fig. 2: Fragmento de um DFD equilibrado

A.1 A B.1

X X X

A.2 B B.2

Fig. 3: Exibição de arquivos nos níveis inferiores.

33
 5 DICIONÁRIO DE DADOS

Dicionário de dados:
É uma listagem organizada de todos os elementos dos dados que fazem parte do
sistema, com definições precisas e rigorosas para que o utilizador e o analista de
sistemas possam conhecer todas as entradas, saídas, componentes do arquivo e
cálculos intermédios.
Os elementos dos dados são definidos da seguinte forma:

• Descrever o significado dos fluxos e arquivos que aparecem nos diagramas de

fluxo de dados.

• Descrever a composição dos pacotes de dados que se movimentam pelos fluxos,

ou seja, pacotes complexos (como endereço de cliente) que podem ser divididos
em itens mais elementares (como cidade, código de postal e pais).

• Descrever a composição dos pacotes de dados nos arquivos.

• Especificar os valores e unidades de partes elementares da informação dos
fluxos de dados e arquivos de dados relevantes.

• Descrever os detalhes dos relacionamentos entre os arquivos de um diagrama

de entidade-relacionamento.

1. A NECESSIDADE DA CONOTAÇÃO DO DICIONÁRIO DE DADOS

Os elementos de dados complexos são definidos em termos de elementos de dados
simples, e os elementos de dados simples são definidos em termos das unidades
válidas e dos valores que eles podem assumir.
Pode-se dar como exemplo um problema sobre o significado do nome de uma
pessoa.

• O nome será constituído pelo primeiro nome e o ultimo?

• O nome para além do primeiro e último nome dever-se-á incluir um nome
intermédio?

• Poderá o último nome ter caracteres de pontuação, exemplo D’Arcy?

• Como se poderá lidar com os sufixos, que por vezes acompanham o ultimo
nome? Exemplo “Duarte Silva Jr.”. Deve-se considerar uma nova categoria?
Nenhuma destas perguntas influenciará a maneira como as informações serão
armazenadas no computador, mas ajudam a determinar a validade do nome para
fins comerciais.

34
2. CONOTAÇÃO DO DICIONÁRIO DE DADOS
Símbolos d conotação para o dicionário de dados:

SIMBOLOS DESCRIÇÃO

= é composto de

+ e

() Opcional (pode estar presente ou ausente)

{} Iteração

[] Escolha uma das opções alternativas

** Comentário

@ Identificador (campo chave) de um arquivo

| Separa opções alternativas na construção [ ]

Para exemplificar, podemos definir nome da seguinte maneira:

Nome = titulo_cortesia + primeiro_nome + (nome_intermédio) +
ultimo_nome
titulo_cortesia = [Sr. |Sra. |Sr.as. |Dr. | Professor]
primeiro_nome = {carácter_válido}
nome_intermédio = {carácter_válido}
ultimo_nome ={carácter_válido}
carácter_válido = [A-Z|a-z|0-9|’|_| |]

35
2.1. Definições
Uma definição de um elemento de dados é apresentada com o símbolo “=”; neste
contexto, o ”=” é lido como “é definido como”, ou “é composto de”, ou
simplesmente 2significa”. Então a conotação
A=B+C
poderíamos lê-la das seguintes maneiras:

• Sempre que dissermos A, queremos dizer B e C.

• A compõe-se de B e C
• A é definido como B e C.

Para definirmos completamente um elemento de dados, deveremos incluir o

seguinte na definição:
a) O significado do elemento de dados no contexto desta aplicação do utilizador.
Normalmente é apresentado e como comentário, usando-se a conotação “**”.
b) A composição do elemento de dados, se ele for composto por componentes
elementares significativos.
c) Os valores que o elemento de dados poderá assumir, se ele for um elemento de
dados elementar que não possa ser decomposto.
Desta forma, se construir um sistema médico que controlam pacientes, podíamos
definir os termos peso e altura da seguinte forma:
peso = *peso do paciente ao chegar ao hospital*
*unidades: quilogramas; intervalo: 1-200*
altura = *altura do paciente ao chegar ao hospital*
*unidades: centímetros; intervalo: 20-200*

Assim são descritas as unidades e os intervalos relevantes com caracteres “*”

correspondentes.
Para além das unidades e os intervalos, podemos também precisar especificar com
exatidão ou a precisão com que o elemento de dados é medido. Para um dado
como o preço, por exemplo, é importante indicar se os valores serão expressos na
forma inteira, até ao ultimo centavo etc. E, algumas aplicações de engenharia e
científicas, são importantes indicar o número de dígitos significativos no valor dos
elementos de dados.
2.1. Elementos de dados elementares

Elementos de dados elementares são aqueles para os quais não existe

decomposição significativa no contexto no ambiente do utilizador. Pode ser uma
questão de interpretação e que deve explorada cuidadosamente pelo utilizador.
No exemplo que vimos anteriormente sobre o nome, este poderia ser decomposto
pelo ultimo-nome, primeiro-nome, nome-intermádio e titulo-cortesia. Estas
decomposições noutros ambientes podem não ter qualquer significado relevante
nem significativo.

36
Quando os itens dos dados elementares estiverem a ser identificados, devem ser
introduzidos no dicionário de dados e neste deve aparecer um pequeno comentário
narrativo, entre os caracteres “*”, descrevendo o significado do termo no contexto
do utilizador. Podem no entanto surgir termos que sejam auto-explicativos.
Os seguintes termos podem ser considerados como auto-explicativos:
altura - atual
peso - atual
data - de - nascimento
sexo
telefone - residência
Nenhum destes termos necessita de comentário narrativo. Podemos utilizar a
conotação “**” para indicar um comentário nulo, quando o é elemento auto-
explicativo
altura - atual = * *
*unidades: centímetros; intervalo: 1 - 220*
peso - atual =* *
*unidades: kilos; intervalo:1-96*
data - de - nascimento =**
*unidades: dias desde 1, jan, 1900; intervalo: 0-36500*
sexo = **
*valores: [M|F]*

37
2.3. Elementos de dados opcionais
Este pode estar ou não presente como um componente de um elemento de dados
composto.

• Um nome de cliente poderá ou não incluir o nome intermédio

• O endereço de cliente pode ou não incluir alguma informação secundária como o
número do apartamento.

• Um pedido de cliente pode ou não conter um endereço de cobrança, endereço

para remessas ou ambos.
Situação como a ultima referida devem ser conferidas cuidadosamente com o
utilizador e cuidadosamente documentadas no dicionário de dados.
Por exemplo:
Endereço_cliente = (endereço_de_remessa) + (endereço_de_cobrança)
Significa, que o endereço do cliente pode ser constituído por:

• apenas o endereço de remessas;

ou

• apenas o endereço de cobrança;

ou

• o endereço de remessas e o endereço de cobrança;

ou ainda,

• nenhum dos endereços.

Esta última possibilidade é muito duvidosa, visto ser bastante provável que o
utilizador queira alguma referência de endereço do cliente escolhendo assim uma
das restantes possibilidades.
Resultado:
Endereço_de_cliente = [endereço_de_remessas | endereço_de_cobrança
endereço_de_carga + endereço_de cobrança]
Por fim podemos constatar que é sempre necessário o endereço de remessa para
onde deve ser enviado o pedido do cliente e o endereço de cobrança separado que
pode ser opcional (ex. departamento de contabilidade).
Endereço_de_cliente = endereço_de_remessas + (endereço_de_cobrança)
É necessário que se explique as implicações das diferentes notações mostradas.
2.4. Iteração

Esta notação é usada para indicar a ocorrência repetida de um componente de um

elemento de dados. Ela é lida como “zero ou mais ocorrências de”.
A notação é:
pedido = nome_do_cliente + endereço_de_remessa + {item}
Nota: item = produto a pedir
Isto significa que um pedido deve conter sempre o nome do cliente e o endereço de
remessa (entrega), e conter, também zero ou mais ocorrências de um item. Desta

38
forma podemos lidar com um cliente que apresente um pedido que envolva apenas
um ou mais produtos.
Na realidade o utilizador pode querer especificar o limite inferior e superior da
iteração. Pois não faz sentido que um cliente faça um pedido de zero produtos,
devendo então haver pelo menos um produto no pedido. O utilizador pode também
querer especificar um limite superior de produtos num pedido; talvez 10 produtos
sejam o máximo permitido.
Podemos indicar o limite inferior e superior da seguinte forma:
{item}
pedido = nome_de_cliente + endereço_de_remessa + 1{ }10

Pode-se especificar também somente o limite superior ou só o limite inferior, ou

ambos, ou nenhum.
Exemplos:
{b}
a = 1{ }
a = {b}
}10
{b}
a = 1{ }10
a = {b}
}

39
2.5. Seleção

Esta notação indica que o elemento de dados consiste em exactamente uma

escolha de um conjunto de opções alternativas. As operações são limitadas pelos
parêntesis rectos “(” e “)” e separadas pelo caracter de barra vertical “|”.
Exemplo:
sexo = [Masculino | Feminino]
tipo - de - cliente = [Governo | Industria | Comercio | Particular | Outro ]
É importante rever todas as opções com o utilizador para que nenhuma tenha sido
esquecida.

2.6. Sinônimos
É um nome alternativo para um elemento de dados. É uma situação comum quando
se lida com um grupo diversificado de utilizadores, muitas vezes de departamentos
diferentes que insistem em dar nomes diferentes para indicar a mesma coisa. O
sinônimo é incluído no dicionário de dados só por uma questão de completar a
informação, e deve ter uma referência com o nome principal ou oficial do dado.
Exemplo:
cliente = *sinônimo de cliente*
Nesta não existe definição do cliente e não mostra a sua composição. Todos os
detalhes devem ser fornecidos somente no nome principal.
No entanto deve-se evitar o uso de sinônimos sempre que possível.

3. APRESENTAÇÃO DO DICIONÁRIO DE DADOS AO UTILIZADOR

O utilizador deve ser capaz de ler e compreender o dicionário de dados para
conferir o modelo, ajudando na correção do mesmo, só assim poderá verificar se
está completo, consistente e sem contradições.

4. A IMPLEMENTAÇÃO DO DICIONÁRIO DE DADOS

Dada a existência de centenas de entradas de dados, é necessário que se possa
fazer uma abordagem.

40
 6 ESPECIFICAÇÃO DE PROCESSO

A especificação de processos define o que deve ser feito para transformar entradas
em saídas. É uma descrição detalhada da orientação empresarial executada pelos
processos.
Existem diversas ferramentas que podemos utilizar para produzir uma especificação
de processos: Tabelas de decisão, Linguagem estruturada, condições pré/pós,
Fluxogramas e outras.
A especificação de processos deve satisfazer dois requisitos essenciais:
1. A especificação de processos deve ser expressa de uma forma que possa ser
verificada pelo utilizador e pelo analista de sistemas. É por essa razão que se
evita a linguagem comum como ferramenta de especificação, ela é ambígua,
principalmente quando se descreve as acções (decisões) alternativas e
repetitivas (laços/ciclos). Tende a causar grande confusão ao expressar
condições booleanas compostas (condições dos operadores booleanos AND, OR
e NOT).
2. A especificação de processos deve ser expressa de uma forma que possa ser
efetivamente comunicada às diversas audiências pretendidas (Utilizadores,
gerentes, auditores, controladores de qualidade, etc.).
Para elaboração das especificações devem ser usadas uma combinação de
ferramentas de especificação, dependendo:
a) da preferência do utilizador;
b) das suas próprias preferências;
c) da natureza dos diversos projetos.
Deve no entanto possuir uma terceira característica:
Não deve impor (ou implicar) decisões arbitrárias de projetos e de implementação.
Isto no entanto é bastante difícil, porque o utilizador, de quem se depende para
estabelecer a “política” seguida em cada processo no DFD, está disposto a
descrever a orientação como ela é executada.
O analista deve escolher a melhor apresentação da essência do que seja a
orientação e não como ela é executada.
Segundo o exemplo:
Desenvolver uma especificação para o processo com o nome
CALCULAR FACTOR HIPOTÉTICO.
Depois de entrevistado o utilizador, descobre-se que o cálculo de fatores hipotéticos
para qualquer entrada de X é:
1. O fator não é calculado de uma forma simples. Temos que começar por uma
suposição. O utilizador disse que gosta muito dos 14 como suposições inicial.
2. Em seguida, faz-se outra suposição. Divide-se o número X com que
começamos, pela suposição corrente.
3. Toma-se o resultado desse cálculo e subtrairmos a suposições correntes.
4. Toma-se o resultado da alínea 3 e dividimo-lo por 2. Essa é uma nova
suposição.

41
5. Se a nova suposição e a suposição corrente estão muito próximas uma da
outra, dentro de o intervalo 0,0001, pode parar, a nova suposição é o fator
hipotético. Caso contrário volta á alínea 2 e começa tudo novamente.
Desta forma pode-se argumentar que esta especificação de processo é bastante
difícil de ser lida e compreendida, porque está escrita em linguagem narrativa. A
definição seguinte é muito mais esclarecedora (pois são usadas as barras verticais
“|” na clausula UNTIL (ENQUANTO) que significam o “valor absoluto” da
expressão entre elas.
Factor_hipo0 = 14
REPITA para N = 0 em saltos de 1
Fator-hipoN+1 = (Fator_hipoN - (X/Fator_hipoN))/2
ATÉ | Fator-hipoN+1 – Fator_hipoN | < 0,0001

Ou

N=0
Factor_hipo0 = 14
ENQUANTO |Fator_hipoN+1 – Fator_hipoN| < 0,0001 FAZER
Fator_hipoN+1 = (Fator_hipoN - (X/Fator_hipoN))/2
N incrementa 1
FIM FAZER

X CALCULAR
FATOR Factor_hipo(X)
HIPOTETICO

Calcular Fator_Hipotético

As especificações de processos só são desenvolvidas para processos do nível mais

baixo dos DFD com níveis. Como se pode verificar na figura abaixo, todos os
processos de um determinado nível inferior seguinte. Ou seja, a especificação de
processos para um processo de um nível é o DFD de um nível imediatamente
inferior.

42
Existem três principais ferramentas de especificação de processo:

1. Linguagem Estruturada (Português Estruturado).

2. Tabelas de Decisão.
3. Arvores de Decisão.
1. PORTUGUÊS ESTRUTURADO

Definição:
É uma linguagem de especificação, que usa um vocabulário limitado e uma sintaxe
limitada.
O vocabulário consiste em:

• Verbos na língua portuguesa;

• Termos definidos no Dicionário de Dados;
• Algumas palavras reservadas para formulação lógica.

A Sintaxe de uma afirmação em Português Estruturado está limitada pelas

seguintes estruturas de controlo:
• Seqüencial;
• Repetição;
• Decisão.

Os verbos podem ser escolhidos segundo esta lista:

• LER ou ACEDER (GET - ACCEPT ou READ)
• ESCERVER (PUT - SEARCH - LOCATE)
• ADICIONAR (ADD)
• SUBTRAIR (SUBTRACT)
• MULTIPLICAR (MULTIPLY)
• DIVIDIR (DIVIDE)
• COMPUTAR (COMPUTE)
• APAGAR (DELETE)
• LOCATIZAR (FIND)
• VALIDAR (VALIDATE)
• MOVER (MOVE)
• SUBSTITUIR (REPLACE)
• COLOCAR (SET)
• ESCOLHER (SORT).

43
Os objetos devem ser compostos apenas por elementos de dados que tenham sido
definidos no Dicionário de Dados ou em termos locais. Termos locais são palavras
explicitamente definidas na especificação de um processo individual. Elas só são
conhecidas, relevantes e significativas nessa especificação de processo.
Ex.:
Calculo intermédio de uma operação. Examina uma série de registros no arquivo
Pedidos para calcular um total diário.

Total_Diário = 0
ENQUANTO existirem mais pedidos em Pedidos como data_fatura = Data_hoje
FAZER
ESCREVER em Contab. Numero_fatura, nome cliente, total_geral
Total_diário = total_diário + total_geral
FIMFAZER
ESCERVER em Contab. Total_diário

CONSTRUÇÃO DAS ESTRUTURAS DE CONTROLE:

1. SE - ENTÃO - SENÃO(IF-THEN-ELSE)
A estrutura SE - ENTÃO - SENÃO (IF-THEN-ELSE), é utilizada para descrever
ações alternativas que devem ser executadas de acordo com o resultado de uma
condição (verdadeira - Falsa )

SE < condição > ENTÃO

< ação >
FIMSE

ou

SE < condição > ENTÃO

< acção1 >
SENÃO
< acção2 >
FIMSE

Ex.:

SE idade_cliente maior que 65 ENTÃO

COLOCAR categoria_cobrança em categoria_sénior
SENÃO
COLOCAR categoria_cobrança em categoria_normal
FIMSE

44
2. CASO (CASE)
A estrutura CASO (CASE) é utilizada para descrever ações alternativas a serem
executadas com base no resultado de uma condição com vários valores (diferente
da condição binária que ocorre na estrutura SE-ENTÃO). A estrutura CASO
assume a forma geral:

FAZER CASO
CASO < condição 1 = valor 1>
< ação 1 >
CASO < condição n = valor n>
< ação n >
CASOCONTRARIO
< ação n+1>
FIMCASO

Ex.:

1º
FAZER CASO
CASO idade_cliente < 13
COLOCAR categoria_cobrança em categoria_infantil
CASO idade_cliente > 12 e idade_cliente < 20
COLOCAR categoria_cobrança em categoria_adulto
CASO idade_cliente >19 e idade_cliente <65
COLOCAR categoria_cobrança em categoria_adulto
CASOCONTRARIO
COLOCAR categoria_cobrança em categoria_sénior
FIMCASO

2º
FAZER CASO
CASO Pais = “GB”
COLOCAR Taxa_Vendas em 0.0825
CASO Pais = “FRN”
COLOCAR Taxa_Vendas em 0.07
CASO pais = “ESP”
COLOCAR Taxa_Vendas em 0.05
CASOCONTRARIO
COLOCAR Taxa_Vendas em 0
FIMCASO

45
3. ENQUANTO - FAZER ( DO - WHILE ou WHILE - DO )
A estrutura ENQUANTO - FAZER ( DO - WHILE ou WHILE - DO ) é usada para
descrever uma ação que deve ser executada repetidamente até que uma
determinada condição booleana seja Falsa. O teste á condição é feito antes da
execução da 1ª ação; assim sendo, se a condição não for satisfeita a condição não
é executada. Procedendo-se ao termino da condição.

ENQUANTO < condição >

FAZER
< ação 1 >
FIMFAZER

Ex.:

ENQUANTO houver mais itens no pedido do cliente

FAZER
preço = preço_unit * quant_item
FIMFAZER

4. REPETIR – ATÉ (REPEAT – UNTIL)

Outra estrutura de controlo de repetição é REPETIR - ATÉ que repete uma
condição enquanto esta for Falsa e termina quando for Verdadeira. A condição e
executado pelo menos uma vez mesmo pois o teste é feito no final das ações terem
sido executadas.
REPETIR
< ação 1 >
< ação 2 >

< ação n >

ATÉ < condição >

CONSTRUÇÃO DE ESTRUTURAS COMPOSTAS

Para a construção de estruturas compostas a partir de combinações estruturais
simples, acima apresentadas, existem algumas regras:
1. Uma estrutura linear de ações simples é equivalente a uma estrutura seqüencial.
< ação 1 >
< ação 2 >

< ação n >

é equivalente a uma estrutura condicional (1) ou de repetição (2):
(1)
SE < condição > ENTÃO
< ação 1 >
< ação 2 >

46
 < ação m>
SENÃO
< ação a>
< ação b>
< ação n>
FIMSE

(2)
ENQUANTO < condição >
FAZER
< ação 1 >
< ação 2 >
< ação n >
FIM FAZER

2. Uma estrutura SE - ENTÃO - SENÃO permite que sejam encadeadas dentro de

outras estruturas SE - ENTÃO - SENÃO, ou dentro de estruturas ENQUANTO -
FAZER ou CASO.
Ex.:
SE < condição 1 > ENTÃO
< ação 1 >
SE < condição 2 > ENTÃO
< ação 2 >
< ação 3 >
SENTÃO
< ação 4 >
< ação 5 >
FIMSE
< ação 6 >
SENÃO
SE < condição 3 > ENTÃO
< ação 7 >
FIMSE
FIMSE

3. As estruturas de controlo de repetição ENQUANTO - FAZER, pode ser

encadeado dentro de outras estruturas ENQUANTO - FAZER ou mesmo dentro
da estrutura CASO.
Ex.:
Total_geral = 0
ENQUANTO houver pedidos a serem processados
FAZER
Total_faturas = 0
LER próximo pedido em PEDIDOS
ENQUANTO houver itens no pedido
FAZER
Total_faturas = total_faturas + valor_item
FIMFAZER
ESCERVER numero_fatura, total_fatura
Total_geral = total_faturas + total_faturas
FIMFAZER
ESCREVER total_geral
47
4. A estrutura CASO pode estar encadeada dentro de outras estruturas CASO, ou
dentro de estruturas SE - ENTÃO - SENÃO ou mesmo dentro das estruturas
ENQUANTO - FAZER.

RESUMO:
Como se viu, é possível se construir estruturas de controlo bastante complexam. No
entanto há que ter muita atenção com essa complexidade, pois pode servir como
desvantagem caso o utilizador não a conseguir compreender nem mesmo fazer a
sua verificação e correção. Nesse caso tudo o projeto será um fracasso, deste modo
devem ser evitadas as seguintes três diretrizes:
1. Restringir a linguagem de estrutura a uma só página de texto. Se for necessário
utilizar mais que uma página, deve-se então tentar alterar para algoritmos mais
simples. Senão quer dizer que o DFD correspondente é muito complexo, dever-
se-á subdividi-lo em processos mais simples de nível mais baixo.
2. Não usar mais de três níveis de encadeamento das estruturas de controlo (SE -
ENTÃO - SENÃO ou CASO). Principalmente se for a estrutura SE - SENÃO -
SENÃO, mais que dois níveis de encadeamento representa a necessidade da
especificação de uma tabela de decisões.
3. Evitar confusões relativamente aos encadeamentos recorrendo-se à
identificação, como foi visto nos exemplos anteriores. Desta forma torna-se
mais fácil a sua visualização e a sua correção.

48
 7 TABELAS DE DECISÃO
Definição:
É uma ferramenta que distingue e especifica um conjunto de n ações, em que
apenas uma delas é aplicada a cada uma das condições dadas.
Esta ferramenta é usada em situações em que deve produzir alguma saída ou
executar acções com base em condições (decisões) complexas. Se as acções forem
baseadas em diversas variáveis (por Ex.: elemento de dados de entrada), e se
essas variáveis poderem assumir muitos valores diferentes, então a lógica expressa
pela linguagem estruturada poderá ser provavelmente tão complexa que o
utilizador não a compreenderá.
Numa TABELA DE DECISÃO estão relacionadas todas as variáveis relevantes ou
condições e todas as ações relevantes, estas encontram-se posicionadas no lado
esquerdo da Tabela de Decisão. Nas colunas do lado direito estão descritas as
normas (regras).
Uma norma descreve a ação ou ações que devem ser tomadas para uma específica
combinação de valores de variáveis. Deve pelo menos ser especificada uma acção
para cada norma, isto é, para cada coluna vertical na Tabela de Decisão, ou o
comportamento do sistema para aquela situação não será especificada.
O número de normas existente na Tabela de Decisão depende das condições
existentes na mesma.
• Como escolher o número de normas existentes na Tabela de Decisão:
1. Se as variáveis dependentes, tiverem n valores binários (Falso/Verdadeiro),
então teremos 2n normas distintas.
Ex.:
Se tivermos 3 condições então teremos 23 normas que equivale a 8 normas.

2. Se as variáveis de condição tiverem valores associados então o número de

normas será igual á multiplicação do número dos valores associados das
várias variáveis de condição.
Ex.:
Se tivermos três variáveis de condição e se duas delas tiverem dois valores
associados e a outra três, então teremos 2*2*3 normas, ou seja, teremos12
normas.

Regra:
“O número de normas necessárias para completar uma Tabela de Decisão é igual
ao produto entre os números de valores para todas as variáveis de condição.”

49
Etapas para a criação de uma Tabela de Decisão para uma especificação de
processos:

1. Identificar todas as condições ou variáveis na especificação.

Identificar todos os valores que cada variável pode assumir.
2. Calcular o número de normas (combinação de condições) existentes na
especificação.
3. Identificar cada acção possível na especificação.
4. Criar uma Tabela de Decisão “vazia”, relacionando todas as condições e ações
no lado esquerdo e numerando as combinações de condições no topo da tabela.
5. Relacionar todas as combinações de condições, para cada coluna vertical da
tabela.
6. Examinar cada norma (coluna vertical) e identificar as ações adequadas a serem
tomadas a cabo.
7. Identificar todas as omissões, contradições e ambigüidades da especificação.
Ex.:
Normas da Tabela de Decisão para as quais a especificação não indica que
ações devem ser tomadas.
8. Discutir as omissões, contradições e ambigüidades com o utilizador.

Exemplo de uma Tabela de Decisão:

Dadas as seguintes variáveis de condição

Variáveis de Condição Valores Associados

Sim – S
Idade > 21
Não – N

Masculino – M
Sexo
Feminino – F

Sim – S
Peso > 150
Não - N

Nota:
Todas as Variáveis de Condição são binárias, pois admitem como valores
associados apenas dois.
Pode-se verificar que na seguinte Tabela de Decisão teremos três condições cujas
variáveis são de tipo binário (Sim/Não), neste caso n é igual a 3.

Calculo do número de normas:

3
2 =8 , normas = 8.

50
 1 2 3 4 5 6 7 8

Idade > 21 S S S S N N N N

Sexo M M F F M M F F

Peso S N S N S N S N

Medicação 1 X X X

Medicação 2 X X

Medicação 3 X X X

Nenhuma
X X
Medicação

51
 7.1 ÁRVORE DE DECISÃO

Definição:
É a representação gráfica de uma Tabela de Decisão.

Esta ferramenta é usada quando o utilizador não conseguir compreender a Tabela

de Decisão. Esta é por vezes mais facilmente compreendida pelo utilizador, pois é
uma estrutura que lhe parece mais familiar.
Nela estão representadas as condições e as ações existentes na especificação, e
também o modo como elas se relacionam. Exatamente como nas Tabelas de
Decisão.
Vejamos então um exemplo:
Árvore de Decisão sobre o exemplo representado no Ponto anterior (Tabelas de
Decisões).

Idade > 21 Sexo Peso > Medicação

150
S 1
M

N 2
S
S 3
F
PROGRAMA
DE N N
MEDICAÇÃO 1,2
S
M

N N 3

S N
F

N 1,3

52