Apostila Blaschek de Análise de Sitemas

Departamento de Informática
Especialização em Análise,
Projeto e Gerência de Sistemas
Métodos de Análise de Sistemas

1ª edição – Julho de 98
Profº. José Roberto Blaschek
Especialização em
ANÁLISE, PROJETO E
GERÊNCIA DE SISTEMAS
MÉTODOS DE
ANÁLISE DE SISTEMAS
2ª edição – Maio de 95
Prof. José Roberto Blaschek
COORDENAÇÃO CENTRAL DE EXTENSÃO

MÉTODOS DE ANÁLISE DE SISTEMAS 1
ÍNDICE
Capítulo 1
Conceitos Básicos
1.1 Introdução -----------------------------------------------------------------------------03
1.2 Análise de Sistemas ----------------------------------------------------------------03
1.3 Metodologia ---------------------------------------------------------------------------04
1.4 Processo de Desenvolvimento de Sistemas de Informação ---------------04
1.5 Modelo ---------------------------------------------------------------------------------07
1.6 Dimensão de um Modelo ----------------------------------------------------------07
1.7 Nível de Abstração de um Modelo -----------------------------------------------07
1.8 Modelagem de Sistemas de Informação ---------------------------------------07
1.8.1 Modelagem de Sistemas de Informação ---------------------------08
1.8.2 Níveis de Abstração -----------------------------------------------------08
Capítulo 2
Análise Estruturada
2.1 Introdução ---------------------------------------------------------------------------- 09
2.1 Características da Metodologia --------------------------------------------------09
2.3 Princípios Utilizados na Solução de Problemas ------------------------------09
2.4 Modelos da Metodologia------------------------------------------------------------10
2.5 Diagrama de Fluxo de Dados (DFD) --------------------------------------------10
2.5.1 Processo ------------------------------------------------------------------10
2.5.2 Fluxo de Dados ----------------------------------------------------------11
2.5.3 Depósito de Dados ------------------------------------------------------11
2.5.4 Entidade Externa ---------------------------------------------------------12
2.6 Organização de DFD em Níveis -------------------------------------------------12
2.7 Recomendações para Construção de DFD -----------------------------------13
2.8 Diretivas da Metodologia -----------------------------------------------------------14
Capítulo 3
Dicionário de Dados
3.1 Introdução------------------------------------------------------------------------------17
3.2 Organização e Simbologia --------------------------------------------------------17
3.3 Estruturas das Definições ---------------------------------------------------------18
3.3.1 Depósitos de Dados, Entidades e Relacionamentos
com Atributo ----------------------------------------------------------------------19
3.3.2 Fluxos de Dados e Estruturas de Dados --------------------------20
3.3.3 Elementos de Dados ---------------------------------------------------21
Capítulo 4
Português Estruturado
4.1 Introdução -----------------------------------------------------------------------------22
4.2 Características da Especificação ------------------------------------------------22
2 MÉTODOS DE ANÁLISE DE SISTEMAS
4.3 Estruturas de Controle -------------------------------------------------------------23

4.3.1 Seqüência------------------------------------------------------------------23
4.3.2 Seleção --------------------------------------------------------------------23
4.3.3 Repetição ------------------------------------------------------------------24
4.4 Formato da Especificação ---------------------------------------------------------24
4.5 Exemplos de Especificação em Português Estruturado --------------------25
Capítulo 5
Diagrama de Transição de Estados
5.1 Introdução------------------------------------------------------------------------------32
5.2 Eventos ---------------------------------------------------------------------------------32
5.3 Estados ---------------------------------------------------------------------------------32
5.4 Condições------------------------------------------------------------------------------33
5.5 Notação Gráfica ----------------------------------------------------------------------33
Capítulo 6
Análise Essencial
6.1 Introdução------------------------------------------------------------------------------34
6.2 Conceitos Básicos -------------------------------------------------------------------34
6.2.1 Tecnologia Perfeita ------------------------------------------------------34
6.2.2 Requisitos Verdadeiro e Requisito Falso ---------------------------35
6.2.3 Sistema Interativo --------------------------------------------------------36
6.2.4 Evento e Resposta-------------------------------------------------------36
6.2.5 Atividade Essencial ------------------------------------------------------38
6.2.6 Memória Essencial-------------------------------------------------------39
6.3 Acesso das Atividades de Custódia à Memória Essencial -----------------40
6.4 Sistema Encarnado------------------------------------------------------------------41
6.5 Especificação da Essência do Sistema-----------------------------------------41
ÍNDICE DE FIGURAS
Figura 1 - Representação Gráfica de Processo---------------------------------------------10
Figura 2 - Representação Gráfica de Fluxo de Dados -------------------------------------11
Figura 3 - Convergência e Divergência de Fluxo de Dados ------------------------------11
Figura 4 - Representação Gráfica de Fluxo de Dados -------------------------------------12
Figura 5 - Semântica dos Acessos aos Depósitos de Dados ----------------------------12
Figura 6 - Representação Gráfica da Entidade Externa -----------------------------------13
Figura 7 - DFD Organizado em Níveis Hierárquicos ---------------------------------------12
Figura 8 - Notação para Diagrama de Transição de Estados ----------------------------33
Figura 9 - Sistema Interativo ---------------------------------------------------------------------36
Figura 10 - Sistema de Resposta Planejada -------------------------------------------------37
Figura 11 - Atividades Essenciais -------------------------------------------------------------39
Figura 12 - Modelo de Dados Genérico -------------------------------------------------------40
Figura 13 - Criar ou Excluir uma Ocorrência de R1 ----------------------------------------40
Figura 14 - Criar ou Excluir uma Ocorrência de R2 ----------------------------------------40
1
CONCEITOS BÁSICOS
1.1 Introdução
De uma maneira abrangente, Sistema é definido como “um conjunto de
elementos, interrelacionados, que possuem características comuns e que
podem ser entendidos como um todo”.
Dessa forma, podemos pensar no “Sistema Solar”, composto de vários
elementos como o Sol, os planetas, a força gravitacional, as órbitas, etc.
Podemos pensar também em um “Sistema Político” ou um “Sistema Digestivo”.
Os sistemas se dividem em Sistemas Naturais e Sistemas Construídos pelo
Homem. Nos sistemas construídos pelo homem, podemos identificar
claramente o propósito para o qual o sistema foi construído. Nos sistemas
naturais, esse propósito nem sempre é muito claro.
Os sistemas construídos pelo homem podem ser definidos como um conjunto
de componentes relacionados entre si, que podem ser vistos como um todo,
onde os componentes trabalham juntos na execução de um conjunto de
funções para alcançar um propósito. Assim, um sistema tem:
♦ componentes: partes básicas ou elementos que compõem o sistema;
♦ estrutura: maneira como os componentes estão organizados;
♦ comportamento: modificação dos componentes e da estrutura com o passar
do tempo;
♦ funções: transformações que o sistema executa; e
♦ propósito: objetivo que o sistema deve alcançar.
Dentre os sistemas construídos pelo homem, existem aqueles onde um dos
componentes fundamentais são informações. Esses sistemas, chamados
“Sistemas de Informação”, provêem procedimentos para armazenar e tornar
disponíveis informações, que são utilizadas em atividades relacionadas a uma
organização. Se os sistemas de informação utilizam computadores, eles são
denominados “Sistemas de Informação Automatizados”. Esse tipo de sistema é
o alvo principal de nosso curso.
1.2 Análise de Sistemas

É um processo de comunicação entre Analistas de Sistemas e Usuários do
Sistema, com o objetivo de definir o propósito e os requisitos de um sistema de
informação. Requisitos de um sistema é o conjunto de características que um
sistema deve possuir para atingir seu propósito.
A análise de um sistema é um processo de transformação de conhecimento.
Ela envolve três etapas: o aprendizado; a estruturação e a representação dos

requisitos do sistema; e a validação dos requisitos pelos usuários.
Ao longo do processo, o analista enfrenta o desafio de “lidar com a
complexidade”, isto é, situações complexas do mundo real devem ser
entendidas e representadas de forma simples, para facilitar a compreensão e
validação. Requer delimitar a área de estudo, subdividir o todo complexo em
partes inteligíveis e de tamanho gerenciável, extrair as características
essenciais da realidade e modelar essas características para mostrar o
relacionamento entre seus componentes. Pode-se afirmar que complexidade e
falta de estrutura caracterizam o ambiente da Análise de Sistemas.
1.3 Metodologia
As Metodologias são utilizadas para orientar e ordenar o trabalho do analista
de sistemas ao longo do processo de desenvolvimento de sistemas.
Uma boa metodologia deve definir o processo de desenvolvimento, possuir
modelos para representar abstrações e diretivas para orientação do trabalho.
1.4 Processo de Desenvolvimento de Sistemas de Informação

O Processo de Desenvolvimento de Sistemas, também chamado Ciclo de Vida
do Sistema, compreende todas as atividades necessárias para definir,
desenvolver, testar, operar e manter um sistema.
A definição de um processo de desenvolvimento tem como objetivo:
- definir as atividades a serem executadas ao longo do projeto;
- prover pontos de controle; e
- padronizar o processo de desenvolvimento na organização.
O Processo de Desenvolvimento estruturado, que tem como principal
característica a ausência de seqüência progressiva entre suas atividades, é
dividido nas seguintes etapas:
Etapa 1: Planejamento Estratégico (nível organização)

Tem como propósito definir os requisitos de informação de uma organização,
visando:
- definir a arquitetura de informação;
- identificar as aplicações a serem desenvolvidas, com as respectivas
prioridades;
- identificar as interfaces entre aplicações, vistas como partes de sistemas
maiores;
É importante ressaltar que as atividades de uma organização estão distribuídas
em três níveis distintos: nível estratégico, nível tático e nível operacional. Os
usuários de cada nível possuem necessidades
específicas, que devem ser atendidas pelos sistemas de informação da
organização. Um plano de sistemas bem elaborado, garante a integração dos
sistemas produzidos e que todos os usuários serão adequadamente atendidos,
independentemente de seu nível de atuação.
Etapa 2: Levantamentos Iniciais (início do nível aplicação)

Consome cerca de 5% a 10% do tempo e dos demais recursos do projeto da
aplicação. Tem como propósito compreender o problema do usuário e formular
alternativas de solução. Nessa etapa são realizadas as seguintes tarefas:
a) descrição do sistema atual:

Através de entrevistas com os usuários, o analista produz um texto em
português, descrevendo o que é feito no sistema atual, sem preocupar-se com
o como é feito. Essa descrição deve conter uma introdução onde é
apresentada a empresa, seu ramo de atuação, localização, porte e estrutura
organizacional.
A seguir, as atividades objeto do levantamento são citadas e descritas. A
descrição deve levar em consideração o fluxo normal da informação (origem,
processamento e destino).
b) construção do modelo do sistema atual:

O analista deve construir um modelo gráfico de alto nível do sistema atual,
visando possibilitar que ele passe a raciocinar com seus próprios modelos.
c) identificação dos problemas do sistema atual:

São coisas que o sistema atual faz, mas que não faz bem. São exemplos de
problemas software não manutenível, tempo de resposta inadequado, custos
excessivos, problemas de confiabilidade, problemas operacionais, deficiências
de interface com outros sistemas, falhas de informação (informações
desnecessárias, incorretas, redundantes e inconsistentes).
Todas as deficiências devem ser enunciadas em termos de causa e efeito
quantificado, como por exemplo: “como o cálculo do pagamento é feito
manualmente e exige consulta a três diferentes documentos, há muita demora,
em média dois dias, para se efetuar o cálculo e ocorrem muitos erros, em
média quatro por processo de cálculo”.
A relação de problemas deve ser submetida ao usuário para validação. A
seguir, ela é organizada, pelo usuário, em ordem decrescente de prioridade.
d) identificação das necessidades não atendidas pelo sistema atual:

São informações que o usuário gostaria de receber, mas que não são
fornecidas pelo sistema atual. Ao enunciá-las, o analista deve citar a
informação a ser fornecida e associá-la à atividade do negócio que será
apoiada por essa informação, como por exemplo: “relação dos clientes em
atraso, visando a possibilitar a cobrança por telefone”.
Essa lista também deve ser validada pelo usuário e organizada em ordem
decrescente de prioridade.
e) definição dos requisitos para um novo sistema:

Em linhas gerais, os requisitos para um novo sistema corresponderão ao que o
sistema atual faz, menos os seus problemas, mais as necessidades não
atendidas.
Os requisitos são expressos na forma de uma lista.
f) formulação de alternativas de solução:

O analista deverá formular alternativas de solução para o atendimento dos
requisitos listados na tarefa anterior. As alternativas devem propor desde
soluções mais simples, mais baratas e de execução mais rápida e que
atendam apenas aos requisitos mais prioritários, até a mais complexa,
possivelmente cara e demorada, mas que atenda a todos os requisitos.
Todas as alternativas devem apresentar, de forma detalhada, os custos
quantificados (hardware, software, mão de obra e tempo) e os benefícios
esperados (informações fornecidas, redução de custos, aumento de lucro,
qualidade de atendimento, etc.) que, se possível. Devem também ser
quantificados.
De posse dessas informações, o usuário seleciona uma das alternativas, a qual
passará a ser desenvolvida na fase de análise.
g) redação do plano do projeto:

O plano do projeto inclui as informações de custo e prazo da solução escolhida,
define as responsabilidades da gerência e descreve as demais etapas do
processo de desenvolvimento, os produtos de cada etapa, os requisitos de
qualidade e o cronograma do projeto.
Etapa 3: Análise
Atividade para a qual o analista deve dedicar a maior parte de seu tempo e
esforço. Sua principal tarefa consiste em definir e modelar o que o sistema irá
fazer, independente da tecnologia que será utilizada na implementação. É feita
uma reavaliação do plano do projeto, principalmente dos custos e benefícios
quantificados na fase anterior.
Etapa 4: Projeto
O objetivo desta etapa é definir a melhor alternativa para implementar, em um
dado ambiente computacional, todas as características do sistema definidas na
Análise. Os critérios utilizados na escolha das alternativas são: performance,
interatibilidade (facilidade de uso), manutenibilidade (facilidade de alteração),
segurança (contra acessos indevidos e perdas acidentais de dados) e
confiabilidade.
Etapa 5: Implementação
Consiste na codificação dos programas e criação dos arquivos de dados.
Etapa 6: Testes
Consiste na definição de casos de testes e na realização dos testes de
programas, testes de integração, teste do sistema e teste de aceitação.
Etapa 7: Implantação
Consiste em implantar o sistema nas instalações do usuário. Nessa etapa são
prontificados os manuais, os arquivos são carregados, o sistema é instalado e
os usuários treinados. Um bom planejamento dessas atividades é um fator
crítico para o sucesso do sistema.
Todo o trabalho executado no sistema após a sua implantação é denominado
manutenção, a qual pode ser corretiva (corrigir erros), adaptativa (adaptar o
sistema a um novo ambiente ou ao mesmo ambiente modificado) ou evolutiva
(dotar o sistema de novas capacidades).
1.5 Modelo
É uma representação de um sistema (ou de um objeto qualquer). Um modelo é
uma abstração da realidade, ou seja, representa uma seleção de
características do mundo real, que são relevantes para o propósito como qual o
modelo foi construído.
Razões para Modelar um Sistema:
- possibilitar o estudo do comportamento do sistema;
- possibilitar a discussão de correções e modificações com o usuário, a baixo
custo, minimizando o risco de não aceitação do produto final;
- facilitar a comunicação entre os componentes da equipe de
desenvolvimento; e
- formar uma documentação do sistema.
1.6 Dimensões de um Modelo

Conjunto de características da realidade que são enfatizados no modelo.
1.7 Nível de Abstração de um Modelo

Consiste no grau de detalhamento com que as características do sistema são
representadas no modelo. Em cada nível há uma ênfase seletiva nos detalhes
representados.
1.8 Modelagem de Sistemas de Informação

Ao longo do processo de desenvolvimento, um sistema é representado através
de vários modelos. Esses modelos representam o sistema em dimensões e
níveis de abstração distintos.
1.8.1 Dimensões do Mundo Real

Dado – aspecto estático e estrutural do sistema;
Controle – aspecto temporal e comportamental do sistema; e
Função – transformação de valores.
Os modelos de dados, controle e função de um mesmo sistema, devem ser
consistentes entre si.
1.8.2 Níveis de Abstração

Conceitual
Características do sistema independentes do ambiente computacional
(hardware e software) no qual será implementado o sistema. Essas
características são dependentes unicamente das necessidades do usuário.
Lógico
Características dependentes de um determinado tipo de sistema computacional
(não representa características de produtos específicos).
Físico
Características dependentes de um sistema computacional específico, isto é,
linguagem e compilador específicos, hardware de um determinado fabricante,
etc.
Nas primeiras etapas do processo de desenvolvimento, o analista representa o
sistema através de modelos conceituais. Nas etapas seguintes, as
características lógicas e físicas são representadas em novos modelos.
2
ANÁLISE ESTRUTURADA
2.1 Introdução
As técnicas estruturadas surgiram no sentido bottom-up, isto é, da
programação para a análise.
A programação estruturada, introduzida no final da década de 60, teve como
principal propósito a construção de programas mais fáceis de serem lidos e
compreendidos. Isso foi conseguido com o abandono do comando “GOTO” e
uso, na construção dos programas, de apenas três estruturas básicas de
controle (seqüência, seleção e repetição).
O projeto estruturado, introduzido em meados da década de 70, preocupou-se
com a organização dos programas. As recomendações do projeto estruturado
para organizar um sistema em módulos de tamanho reduzido, cada qual
executando uma única função específica, e sobre a maneira como os módulos
devem ser interligados, contribuíram para a manutenibilidade do sistema.
No final da década de 70, a análise estruturada possibilitou especificar os
requisitos lógicos do sistema em um modelo gráfico de alto nível, capaz de ser
compreendido pelos usuários e de ser mapeado para a arquitetura do projeto.
O modelo gráfico introduzido pela análise estruturada representa os dados
utilizados por um sistema, os fluxos que transportam e os processos que os
transformam.
2.2 Características da Metodologia

A análise estruturada possui as seguintes características:
♦ Utiliza linguagem gráfica com suporte de texto
♦ Fornece uma visão top-down e particionada do sistema
♦ Possibilita eliminar redundâncias
♦ Os instrumentos conseguem ser transparentes ao leitor
2.3 Princípios Utilizados na Solução de Problemas

Os seguintes princípios, quando utilizados, auxiliam o analista de sistemas a
lidar com suas limitações, na solução de problemas:
♦ Abstração: utilizado para separar aspectos que estão ligados a uma

determinada particularidade da realidade. Possibilita a construção de
modelos genéricos e simplificados do mundo real.
♦ Rigor e Formalidade: fornece uma abordagem metódica e rigorosa
para resolver um problema, ao contrário de uma abordagem ad-hoc, que
não permite o estabelecimento de controles.
♦ Dividir-para-Conquistar: um problema grande e complexo pode ser

dividido em um conjunto de problemas menores e independentes, mais
fáceis de serem compreendidos e resolvidos.
♦ Organização Hierárquica: os componentes da solução de um problema
podem ser organizados em uma estrutura hierárquica.
♦ Assim, a solução de um problema pode ser compreendida e construída
nível a nível. A cada nível são acrescentados mais detalhes.
2.4 Modelos da Metodologia

A análise estruturada utiliza os seguintes modelos para especificar os
requisitos lógicos do sistema.
♦ Diagrama de Fluxo de Dados (DFD): representa um sistema de
informações como uma rede de processos, interligados entre si por
fluxos e depósitos de dados.
♦ Dicionário de Dados (DD): contém a definição dos dados utilizados no
DFD.
♦ Especificação da Lógica dos Processos: especifica a lógica dos
processos representados no DFD.
2.5 Diagrama de Fluxo de Dados (DFD)

O Diagrama de Fluxo de Dados possui os seguintes componentes:
2.5.1 Processo
Representa as transformações ocorridas com os dados. Corresponde a uma
função ou atividade do sistema de informação.
Uma transformação significa uma ou mais: transformação do conteúdo variável
de um dado de entrada no conteúdo variável de um dado de saída; modificação
ou criação de dados armazenados, a partir do conteúdo (possivelmente
transformado) de dados de entrada; e transformação de dados previamente
armazenados no conteúdo variável de um dado de saída.
O nome do processo deve estar relacionado com uma atividade ou função do
negócio. Devem ser evitados nomes muito físicos (gravar, imprimir), muito
técnicos (deletar, becapear) ou nomes muito genéricos (processar). A figura 1
mostra a representação gráfica de processo, na notação proposta por DeMarco
(1978) e Gane (1979).
Notação DeMarco Notação Gane
Código identificador do processo
1
1 verificar
VERIFICAR pedido
PEDIDO cliente
CLIENTE
Nome do processo:=Verbo no Infinitivo + substantivo
+ (qualificador)
Figura 1- Representação Gráfica do Processo

2.5.2 Fluxo de Dados

É utilizado para representar a movimentação de dados pelo sistema.
Os dados transportados pelos fluxos são associados a um valor variável ou a
um conjunto de valores variáveis, definidos em um ponto discreto no tempo.
O nome do fluxo deve ser um substantivo que facilite a identificação do dado
ou pacote de dados transportado. Todo fluxo de dados possui direção (origem
e destino). A figura 2 mostra a representação gráfica de fluxos de dados, na
notação proposta por DeMarco (1978) e Gane (1979).
Notação DeMarco
Notação Gane
Pedido
(Fluxo de Entrada) Fatura
(Fluxo de Saída)
Fluxo de
Saída
Fluxo de
Entrada
Solicitação-Status-Item Status-Item Fluxo de
(fluxo de diálogo: consulta e Diálogo
resposta sobre estados da memória)
Figura 2 - Representação Gráfica de Fluxo de Dados
Conforme representado na figura 3, fluxos de dados podem convergir ou

divergir em um DFD, representando múltiplas fontes, múltiplos destinos ou
combinação/separação de conteúdo.
X
Todos os "X" podem ser fornecidos por uma ou outra origem
Z
X Dois subconjuntos de "X" são fornecidos por duas origens
X Todos os "X" são enviados aos dois destinos
X Z
Dois subconjuntos de "X" são enviados a dois destinos
Y
Figura 3 - Convergência e Divergência de Fluxo de Dados
2.5.3 Depósito de Dados

Representa uma coleção de dados em repouso. Pode ser considerada como
uma área destinada a armazenar dados, situada entre processos que são
executados em tempos diferentes.
Um depósito de dados pode ser visto fisicamente como uma fita magnética,
uma área em disco magnético, um caderno, um fichário, uma relação, uma
ficha, etc. A figura 4 ilustra a representação gráfica de depósitos de dados, na
notação proposta por DeMarco (1978) e Gane (1979).
Notação DeNarco Notação Gane
PEDIDOS DI PEDIDOS
Nome do depósito de dados

Substantivo no plural)
Nome do depósito (substantivos Código do depósito de dados

no plural) Indica que o depósito de dados é desenhado
mais de uma vez no diagrama
Figura 4 - Representação Gráfica de Depósito de Dados
A Semântica dos Acessos aos depósitos de dados é ilustrado na figura 5.
PEDIDOS PEDIDOS
Leitura não destrutiva Inclusão, exclusão ou
do conteúdo do alteração do conteúdo
depósito de dados do depósito de dados
PEDIDOS
Leitura e modificação
do conteúdo do
depósito de dados
Figura 5 - Semântica dos Acessos aos Depósitos de Dados
2.5.4 Entidade Externa

É uma fonte ou destino de dados que se comunica com o sistema,
respectivamente fornecendo ou recebendo dados.
As entidades externas representam as interfaces do sistema. Situam-se fora do
controle do sistema e do domínio de análise do analista. Por esta razão, o DFD
não representa fluxos de dados entre entidades externas. A figura 6 ilustra a
representação gráfica de entidade externa, na notação proposta por DeMarco
(1978) e Gane (1979).
Notação Gane
Notação DeMarco
a código da entidade
externa
cliente cliente
Indica que a entidade externa

é desenhada mais de uma vez
nome da entidade externa no diagrama
nome da entidade externa
Figura 6 – Representação Gráfica da Entidade Externa
2.6 Organização de DFD em Níveis

Para evitar DFDs complexos, com um número muito elevado de processos –
mais do que 7 + 2 – e permitir uma visão top-down e particionada do sistema,
os diagramas são organizados em níveis hierárquicos, onde os diagramas de
nível inferior detalham processos de diagramas do nível superior.
O diagrama de mais alto nível hierárquico é denominado Diagrama de
Contexto, o qual representa o sistema como um único processo e suas
interações com o ambiente (o sistema, entidades externas e fluxos de entrada
e saída).
O diagrama imediatamente subordinado ao Diagrama de Contexto é
denominado Diagrama Zero, que representa as principais funções do sistema e
as interfaces entre elas. Os processos nesse diagrama recebem os números 1,
2, 3, etc.
A seguir, os diagramas são nomeados com o número e nome do processo que
está sendo detalhado no diagrama. Nesses diagramas os processos são
numerados com o número do processo que está sendo detalhado e um número
seqüencial, separados por um ponto. A figura 7 ilustra a organização do DFD
em níveis hierárquicos.
Diagrama de Contexto
Diagrama Zero
1
2
Diagrama 1 Diagrama 2
1.2 2.2
1.1
2.1
Especificação Processo Processo Processo Processo

da lógica dos 1.1 1.2 2.1 2.2
processos ______ _______ ________ _______
________ _____ _______ ______
Figura 7 - DFD Organizado em Níveis Hierárquicos

2.7 Recomendações para Construção de DFD

a) escolha nomes significativos para todos os objetivos do DFD. Utilize nomes
do próprio ambiente do usuário;
b) os processos devem ser numerados de acordo com o diagrama ao qual
pertencem;
c) evite desenhar DFDs complexos;
d) cuidado com as bolhas sem entrada ou sem saída;
e) cuidado com os processos e fluxos não nomeados;
f) cuidado com os depósitos de dados que só possuem fluxos de entrada ou
de saída;
g) fique atento ao princípio da conservação dos dados;
h) os fluxos que entram e saem em um nível devem entrar e sair no nível
inferior;
i) mostre um depósito de dados no nível mais alto em que ele faz interface
entre dois ou mais processos. Passe a representá-lo em todos os níveis
inferiores que detalham os processos da interface;
j) não perca tempo procurando um bom nome para um processo que só pode
chamar-se “processar dados”. Livre-se dele;
k) só represente fluxos de rejeição nos diagramas de mais baixo nível;
l) não represente no DFD fluxos de controle ou de material; e
m) só especifique a lógica dos processos primitivos, ou seja, dos processos
não explodidos em outros diagramas.
2.8 Diretivas da Metodologia

a) identificar as entidades externas envolvidas;
b) preparar uma lista com as entradas e saídas necessárias para que o
sistemas atinja o seu propósito. Assinale as entradas e saídas que estão
associadas a situações de erros ou execução;
c) identificar as consultas e os pedidos de informação ao sistemas que
possam surgir;
d) desenhar, a partir do canto esquerdo de uma folha de papel, as entidades
externas que fornecem dados ao sistema, os processos necessários para
transformar os dados de entrada nos dados de saída e os depósitos de
dados para manter dados em repouso. Termine com as entidades externas
que recebem informações do sistema.
e) Nesse primeiro diagrama não represente fluxos associados a erros ou
exceções;
f) Verificar se todas as entradas e saídas da lista forma incluídas no diagrama;
g) Produzir diagramas de nível inferior para detalhar os processos do primeiro
diagrama. Nesses novos diagramas, incluir os fluxos associados a erros ou
exceções.
ESTUDO DE CASO 1
LIVRARIA ABC
Descrição do Mini-Mundo
A Livraria ABC atua no mercado de livros há mais de 20 anos. Sua estratégia

de atuação não prevê a manutenção de livros em estoque.
Todos os livros solicitados por seus clientes são, semanalmente,
encomendados às editoras. As editoras e os livros oferecidos são selecionados
pela Direção da Livraria. Atualmente, a Livraria possui 1.200 clientes
cadastrados, fornece 170 livros e atende a uma média de 150 pedidos por
semana.
Os clientes enviam seus pedidos pelo correio. O pedido é aceito se o cliente e
os livros estiverem previamente cadastrados. Caso contrário, o pedido é
rejeitado e devolvido ao cliente.
Ao final da semana, a livraria emite requisições para as editoras, com base nos
pedidos recebidos.
Quando os livros são fornecidos, a livraria confere as notas fiscais das editoras
com as requisições, devolve as que contiverem erros e atende os pedidos dos
clientes, emitindo as respectivas faturas, que acompanham os livros. Uma
cópia da fatura é encaminhada à Tesouraria, onde é feito o controle de
pagamentos.
ESTUDO DE CASO 2
ASSINATURA DE REVISTAS
A editora Fofoca pública atualmente 6 revistas de distribuição nacional. Devido

ao número crescente de assinantes e a publicação em breve de novas revistas,
a direção da editora decidiu contratar os serviços de uma empresa de
informática para o desenvolvimento de um sistema, capaz de agilizar as
vendas de assinaturas.
Para se tornar assinante, as pessoas interessadas enviam um cupom contendo
o nome, CPF, endereço para entrega e o prazo da assinatura (6, 12 ou 24
meses).
O Departamento de Assinantes envia aos novos assinantes recibos para
pagamento da assinatura. O prazo para o pagamento é de 30 dias, a partir da
data da emissão do cupom.
O assinante paga sua assinatura em qualquer dos bancos autorizados.
Periodicamente, os bancos enviam à editora a Segunda via do recibo de
pagamento, devidamente quitado.
Após quinze dias de atraso no pagamento da assinatura, deverá ser enviada
uma carta ao assinante solicitando pagamento. Após trinta dias de atraso, a
assinatura deve ser automaticamente cancelada. O gerente do Departamento
de Assinantes deve ser informado de todos os cancelamentos.
Os assinantes podem alterar o endereço para entrega das revistas,
simplesmente informando ao Departamento de Assinantes o novo endereço.
Um mês antes do término do prazo da assinatura, deverão ser
automaticamente enviados aos assinantes novos cupons, para renovação da
assinatura. É prática da Editora conceder descontos para os assinantes por
ocasião da renovação de suas assinaturas. Mensalmente, a direção da editora
define os preços das assinaturas de cada revista.
No dia quinze de cada mês, devem ser emitidas as etiquetas de
endereçamento, para serem afixadas nos exemplares dos assinantes.
Sempre que solicitado, o sistema deverá ser capaz de informar o total de
assinantes de cada revista.
3
DICIONÁRIO DE DADOS
3.1 Introdução
O Dicionário de Dados é um modelo em texto utilizado para definir os dados do
sistema. Na fase de análise, o Dicionário de dados conterá os dados
representados no Diagrama Entidade-Relacionamento-Atributo (ERA),
Diagrama de Transição de Estados (DTE) e no Diagrama de Fluxo de Dados
(DFD). É organizado em uma única lista, a qual contém, em ordem alfabética,
as seguintes definições:
♦ depósitos de dados;
♦ entidades e relacionamentos com atributos (correspondem aos registros
dos depósitos de dados);
♦ fluxos de dados;
♦ estruturas de dados que compõem os registros dos depósitos de dados,
fluxos de dados ou uma outra estrutura de dados; e
♦ elementos de dados que compõem os registros dos depósitos de dados,
fluxos de dados e as estruturas de dados.
3.2 Organização e Simbologia

No dicionário de dados, todas as definições dos dados estarão organizadas em
uma mesma e única lista, sem que haja qualquer separação entre os tipos de
dados.
Na definição dos dados são utilizados os seguintes símbolos:
SÍMBOLO SIGNIFICADO
= é composto de
+ e
() dado ou estrutura opcional
[|] dados ou estruturas alternativas (ou exclusivo)
n{}m repetição de dados ou estruturas, onde n representa o
número mínimo de repetições e m o número máximo.
Quando n e/ou m não são especificados, significa zero ou
mais repetições.
** delimitador de comentário
@ ou ________ chave primária de depósito de dados
A seguir são apresentados alguns exemplos de utilização destes símbolos:
a) o registro do depósito de dados de clientes é composto, obrigatoriamente,

de código-cliente e nome-cliente e endereço-cliente e, opcionalmente, de
telefone-cliente, sendo código-cliente a chave do registro.
Cliente = *cliente da livraria*
código-cliente + nome cliente + endereço-cliente + (telefone-cliente)
b) o cliente pode não possuir telefone ou possuir mais de um telefone (o

negrito será utilizado para chamar a atenção sobre os detalhes, não
fazendo parte do padrão).
código-cliente + nome cliente + endereço-cliente + {telefone-cliente}
c) o cliente possui no mínimo um telefone, e no máximo três.

código-cliente + nome cliente + endereço-cliente + 1{telefone-cliente} 3
d) o cliente pode não possuir telefone ou possuir no máximo três.

código-cliente + nome cliente + endereço-cliente + {telefone-cliente} 3
e) o cliente possui no mínimo um telefone, podendo possuir vários outros.

código-cliente + nome cliente + endereço-cliente + 1 {telefone-cliente}
f) o cliente deve possuir um telefone, podendo ser comercial ou residencial.

código-cliente + nome cliente + endereço-cliente + [telefone-comercial
| telefone-residencial]
g) o cliente pode possuir telefone comercial, residencial ou ambos.

código-cliente + nome cliente + endereço-cliente + [telefone-comercial
| telefone-residencial / telefone-comercial + telefone-residencial]
3.3 Estrutura das Definições

Todas as definições do Dicionário de Dados contém o nome do dado, um
comentário sucinto sobre o significado do dado, sua composição - no caso de
dados compostos, ou suas características - no caso de dados elementares.
Quando o nome do dado for suficiente para indicar que a descrição está
completa e que não houve esquecimento, mantêm-se apenas os asteriscos no
lugar da especificação do significado.
Exemplo : Indica que o significado do dado não será especificado
Sexo = **
A seguir são apresentados as convenções utilizadas nas definições de cada

tipo de dado:
3.3.1 Depósitos de Dados, Entidades e Relacionamentos com Atributo

A definição de um depósito de dados deve conter o significado do depósito,
volume inicial de dados armazenados, taxa de crescimento e o nome do
registro, o qual corresponderá a uma entidade ou a um relacionamento com
atributo do ERA. Os nomes dos depósitos de dados serão sempre escritos no
plural e com letras maiúsculas.
Exemplo:
nome do depósito de dados
LIVROS = *Cadastro de Livros da Livraria* significado

*volume inicial: 300 ocorrências*
*taxa de crescimento: 5 ocorrências por mês*
(livro)
Informações sobre
volume e taxa de
crescimento
Registro do Depósito de Dados
As chaves primárias dos depósitos de dados são assinaladas na definição do

registro do depósito.
Exemplo:
livro = *livro comercializado pela Livraria*
@código-livro + nome-livro + edição-livro
chave primária do depósito de dados LIVROS

@nome-cliente + data-nascimento + endereço + telefone
chave primária (composta) do depósito de
dados CLIENTES
O Dicionário de Dados pode ser utilizado para descrever a composição dos

Depósitos de Dados que correspondem às generalizações e especializações
do ERA.
Exemplo:
• Cod-leitor
0 Nome-leitor
aluno = *aluno da universidade*

leitor + endereço
LEITOR LEITORES = *leitor cadastrado na Biblioteca*
{[leitor | aluno | professor]}
leitor = *leitor da Biblioteca*
cod-leitor + nome leitor
0 Endereço 0 Sala professor = *professor da universidade*

leitor + sala
ALUNO PROFESSOR
3.3.2 Fluxos de Dados e Estruturas de Dados

A definição de um fluxo de dados ou de uma estrutura de dados contém o
significado e a composição do dado. No dicionário de dados, os nomes desses
dados são escritos com letras minúsculas.
Exemplo:
cliente-pedido = *cliente que encaminhou o pedido* estrutura de dados
nome-cliente + [endereço-cliente | telefone-cliente]
item-pedido = *item do pedido de um cliente* estrutura de dados

nome-item + quantidade-item
pedido-livro = *pedido de livros dos clientes da livraria* fluxo de dados

cliente-pedido + 1 {item-pedido}
Para que a composição dos fluxos e estruturas de dados sejam apresentados

de maneira top-down, o que facilita o seu entendimento, deve-se procurar
agrupar os elementos de dados em estruturas intermediárias.
Exemplo:
pedido-livro = *pedido de livro dos clientes da livraria*
Nome-cliente + endereço-cliente + (telefone-cliente) + 1{nome-item + quantidade-
item}
Composição do fluxo especificada sem estruturas

intermediárias (especificação ruim)
Pedido-livro = *pedido de livro dos clientes da livraria*
Cliente-pedido + 1{item-pedido}
Composição do fluxo especificada com estruturas

intermediárias (boa especificação)
Quando dois ou mais dados possuírem a mesma composição, suas definições

podem ser feitas por meio de referências cruzadas.
Exemplo:
endereço = **
rua + complemento + bairro + cep +cidade + estado
endereço-cliente = ** Endereço,
endereço endereço-cliente e
endereço-fornecedor = ** endereço-fornecedor
endereço são compostos dos
mesmos dados
As mensagens transportadas pelos fluxos de dados, quando definidas no

dicionário de dados, devem ser escritas entre aspas.
Exemplos:
pedido-inválido = *pedido rejeitado pela livraria*
“cliente sem crédito”
situação-aluno = *aproveitamento do aluno na disciplina*
[nota-aluno / “aluno reprovado”]
livro-indisponível = *livro indisponível para empréstimo*
nome-livro + [“livro emprestado”] / “livro reservado”]
3.3.3 Elementos de Dados

A definição de um elemento de dados contém, além do significado do dado,
informações sobre o tipo de dado, tamanho, formato, número de casas
decimais, unidade de medida, domínio de valores, significado dos valores do
domínio e sinônimos.
Exemplos: código-departamento = **
*domínio de valores: [10 | 20 | 30]
*significado dos valores: 10 - Administração
20 - Industrial
30 - Vendas*
preço-item = *preço de venda do livro*
*unidade de medida: CR$*
*tipo: numérico*
*tamanho: 10 posições*
*número de casas decimais: 2*
*sinônimo: preço-venda*
Dados que possuem as mesmas características, ou que sejam sinônimos (um

mesmo dado que é conhecido e tratado por mais de um nome), podem ser
definidos utilizando-se referências cruzadas.
Exemplos:
data =**
Data, data-fatura e data-pedido
*formato: dd/mm/aa*
data-fatura: *data de emissão de uma fatura* possuem as mesmas características
data
data-pedido = *data de emissão de um pedido*
data
4
PORTUGUÊS ESTRUTURADO
4.1 Introdução
O Português Estruturado é um subconjunto do Português, cujas sentenças são
organizadas segundo as três estruturas de controle, introduzidas pela
Programação Estruturada (seqüência, seleção e repetição).
A Análise Estruturada e a Análise Essencial utilizam o Português Estruturado
para especificar a lógica dos processos primitivos do DFD, isto é, dos
processos que não são detalhados em diagramas de nível inferior.
4.2 Características da Especificação

Uma especificação em Português Estruturado deve especificar apenas “o que o
processo deve fazer” e nunca “como o processo deve fazer”.
O exemplo abaixo caracteriza essa diferença:
Para registrar a matrícula de um aluno, o processo “Matricular Aluno” deve
atribuir um valor numérico e seqüencial para “código-matrícula”. No item
“a”, abaixo, está sendo especificado como o processo obtém o valor para
código-matrícula (como fazer). Já no item “b”, está sendo especificado
apenas o que o processo deve fazer.
a) especificação incorreta
“obter novo-aluno
localizar último registro de aluno em ALUNOS
ler matrícula-aluno do registro localizado
acrescente 1 a matrícula-aluno
armazene novo registro em ALUNOS com matrícula-aluno, nome-aluno e
endereço-aluno”
b) especificação correta
“obter novo-aluno
atribuir valor numérico seqüencial a matrícula-aluno
armazenar matrícula-aluno , nome-aluno e endereço-aluno em ALUNOS”
Uma especificação, em Português Estruturado, deve possuir as seguintes
características gerais:
♦ deve ser clara, concisa, completa e livre de ambigüidades;
♦ todos os dados citados na especificação e que estejam definidos no
dicionário de dados devem ser sublinhados;
♦ os dados definidos localmente não são sublinhados;
♦ os depósitos de dados, além de serem sublinhados, devem ser escritos com
letras maiúsculas e no plural;
♦ as palavras reservadas para as estruturas de controle são escritas
com letras maiúsculas; e
• suas estruturas devem estar identadas.
4.3 Estruturas de Controle

Uma especificação em Português Estruturado deve utilizar apenas as
seguintes estruturas de controle:
4.3.1 Seqüência
sentença – 1
sentença – 2
sentença – n
Exemplo:
ler nome-aluno em ALUNOS com matrícula-aluno de solicitação-nota ler nota-
aluno associada a matrícula-aluno em NOTAS acrescentar nome-aluno e nota-
aluno em nota-solicitada
4.3.2 Seleção
a) estrutura “SE” “ENTÃO
SE condição
sentença
FIM-SE
b) estrutura “SE” “ENTÃO” “SENÃO”

SE condição
sentença
SENÃO sentença
FIM-SE
c) estrutura “FAÇA-CASO”
FAÇA-CASO
CASO variável = valor 1
sentença
CASO variável = valor 2
sentença
CASO variável = valor n

sentença
SENÃO sentença
FIM-FAÇA-CASO
Exemplo:
localizar matrícula-aluno em ALUNOS
Se achou
ler nome-aluno em ALUNOS com matrícula-aluno de solicitação-nota
ler nota-aluno associada a matrícula-aluno em NOTAS
acrescentar mensagem nome-aluno e nota-aluno em nota-solicitada
SENÃO
acrescentar mensagem “aluno não matriculado” em nota-solicitada
FIM-SE
4.3.3 Repetição
a) estrutura “FAÇA ENQUANTO”
FAÇA ENQUANTO condição
sentença
FIM-ENQUANTO
b) estrutura “REPITA ATÉ”

REPITA
sentença
ATÉ condição
c) estrutura “PARA CADA” “FAÇA”

PARA CADA objeto FAÇA
sentença
FIM-PARA-CADA
Exemplo:
FAÇA ENQUANTO existir aluno em ALUNOS ordenado por nome-
aluno
ler próximo aluno
acrescentar matrícula-aluno e endereço-aluno em relação-aluno
FIM-ENQUANTO
4.4 Formato da Especificação

As especificações em Português Estruturado terão o seguinte formato:
nome e código do processo primitivo
comentário,
normalmente
especificando o Processo 1.1: Emitir Previsão de Receita com Matrícula
estímulo, quando * Ocorre ao final de cada semana*
este for um fluxo início do corpo da especificação
de controle INÍCIO
FAÇA ENQUANTO existir alunos em ALUNOS

obter próximo aluno
*calcular taxa de matrícula*
SE data-base <31/12/53
___taxa = 20
final da especificação SENÃO corpo da especificação, contendo
___taxa = 30 as sentenças do Português
FIMSE Estruturado. Os comentários, se
FIM necessários, são escritos entre
asteriscos
4.5 Exemplos de Especificações em Português Estruturado

a) especificar a lógica do processo 1.1 abaixo
FATURAS 1.1
EMITIR RELAÇÃO
FATURAS
VENCIDAS
relação-faturas vencidas
Processo 1.1: Emitir Relação Faturas Vencidas

*Ocorre quando existir fatura vencida *
INÍCIO
FAÇA ENQUANTO existir faturas com data-vencimento anterior
A data-atual e não relacionada a fatura-paga em FATURAS-PAGAS
ler próxima fatura com a condição acima
acrescentar uma linha em relação-faturas-vencidas com fatura
FIM ENQUANTO
enviar relação-faturas-vencidas
FIM
b) especificar a lógica do processo 1.2 abaixo
AUTORES
título-livro
1.2
FORNECER
DETALHES DE
LIVRO
LIVROS Detalhes-livro = título-livro +1{autor} +

editora
Processo 1.2: Fornecer Detalhes do Livro

INÍCIO
obter título-livro
ler editora em Livros com título-livro
acrescentar títula-livro e editora em detalhes-livro
FAÇA ENQUANTO existir autor em AUTORES relacionado com título-
livro
ler próximo autor com a condição acima
acrescentar autor em detalhes-livro
FIM ENQUANTO
enviar detalhes-livro
FIM
c) especificar a do processo 1.3 abaixo
ITENS PEDIDOS relação-vendas-do-dia = { número-pedido + nome-cliente +

valor-pedido} + total-dia
1.3
INFORMAR item-pedido = quantidade-pedida
VENDAS pedido = númer-pedido = data-pedido
DO DIA
item = nome-item + valor-item
cliente = nome-cliente + endereço-cliente

PEDIDOS ITENS CLIENTES
dado local (não definido

Processo 1.3: Informar Vendas do Dia no dicionário de dados)
*Ocorre ao final de cada dia*
INÍCIO
FAÇA ENQUANTO existir pedido em PEDIDOS com data-pedido = data-atual
ler número-pedido
ler nome-cliente em CLIENTES relacionado com o número-pedido
acrescentar número-pedido e nome-cliente em relaçãs-vendas-do-dia
FAÇA ENQUANTO existir item-pedido em ITENS PEDIDOS relacionado
com número-pedido
ler próxima quantidade
ler valor-item relacionado com quantidade em ITENS
FIM-ENQUANTO
acrescentar valor-pedido em relações-vendas-do-dia
total-dia = total-dia valor-pedido
FIM-ENQUANTO
acrescentar total-dia em relações-vendas-do-dia
enviar relação-vendas-do-dia
FIM
d) especificara lógica do processo 1.4 abaixo

relação-comissão = {nome-vendedor + {número-pedido +
comissão} + comissão-total-vendedor}
VENDEDORES
1.4
EMITIR RELAÇÃO
MENSAL DE
COMISSÃO DE
VENDAS
vendedor = nome-vendedor + taxa-comissão

PEDIDOS
pedido = número-pedido + data-pedido + valor-pedido
Processo 1.4: Emitir Relação Mensal de Comissão de Vendas

*Ocorre no final do mês *
INÍCIO
FAÇA ENQUANTO existir vendedor em VENDEDORES
ler próximo nome-vendedor e taxa-comissão
acrescentar nome-vendedor em relação-comissão
FAÇA ENQUANTO existir pedido em PEDIDOS relacionado a nome-
vendedor e data-pedido deste mês
ao próximo número-pedido e valor-pedido com a condição acima
Comissão = taxa-comissão valor-pedido
acrescentar número-pedido e comissão em relação-comissão
acumular comissão em comissão-total-vendedor
FIM ENQUANTO
acrescentar comissão-total-vendedor em relação-comissão
FIM ENQUANTO
enviar relação-comissão
FIM
e) especificar a lógica do processo 1.5 abaixo
Vagas-filial = Rel-candidatos-selecionados = nome-filial +

nome-filial + número-vagas-filial + {num-inscrição-candidato +
número-vagas-filial nome-candidato + endereço-candidato}
1.5
SELECIONAR
CANDIDATO
APROVADO
CANDIDATOS REALIZAÇÕES
Processo 1.5: Selecionar Candidato Aprovado

*Selecionar candidatos aprovados no concurso, para uma determinada filial da
empresa, em função do número de vagas fixadas para a filial, pela Diretoria*
INÍCIO
obter vagas-filial
acrescentar uma linha em rel-candidatos-selecionados com nome-filial e
número-de-vagas-filial de
vagas-filial
FAÇA ENQUANTO candidatos-selecionados =<número-de-vagas-filial
de vagas-filial
ler próximo-candidato em CANDIDATOS que possua a maior média
aritmética das notas relacionada a candidato e armazenadas em
REALIZAÇÕES e que não possua nenhuma nota relacionada <5,0
Se houver empate de média aritmética
ler primeiro candidato com maior-data-nascimento
FIM-SE
acrescentar uma linha em rel-candidatos-selecionados com num-

inscrição-candidato, nome-candidato,
endereço-candidato e média aritmética das notas armazenadas em
REALIZAÇÕES e relacionadas a candidato
acrescentar 1 a candidatos-selecionados
dado definido localmente
FIM-ENQUANTO (não sublinhado)
enviar rel-candidatos-selecionados
FIM
f) utilizando o ERA abaixo, especificar a lógica dos seguintes processos
ELABORA
CLIENTE PEDIDO
O endereço-cliente
O quantidade
O nome-cliente O data-pedido
• código-cliente ITEM • num-pedido
PEDIDO
• nome-livro
LIVRO
pedido-livro = num-pedido+ data-pedido +

código-cliente + {nome-livro +
quantidade}
f.1) pedido-livro
1.6
CADASTRAR
PEDIDO
ITENS-PEDIDO LIVRO
PEDIDOS
CLIENTES LIVROS
Processo 1.6: Cadastrar Pedido Livro

INÍCIO
obter pedido-livro
armazenar num-pedido e data-pedido de pedido-livro em PEDIDOS
associar num-pedido de PEDIDOS com código-cliente de pedido-livro
em CLIENTES
PARA CADA nome-livro e quantidade em pedido-livro FAÇA armazenar
quantidade em ITENS-PEDIDOS
associar quantidade de ITENS-PEDIDOS com num-pedido de pedido-livro em

PEDIDOS e com Nome-livro de pedido-livro em LIVROS
FIM-PARA-CADA
FIM
f.2) relação-pedido = {num-pedido +data-pedido +
1.7 código-cliente + {nome-livro +
GERAR
PEDIDOS quantidade}}
RELAÇÃO
PEDIDOS
ITENS-PEDIDOS
CLIENTES
LIVROS
Processo 1.7: Gerar Relação Pedidos

INÍCIO
FAÇA ENQUANTO existir pedido em PEDIDOS ordenado por data-
pedido
Ler próximo pedido
Ler codigo-cliente em CLIENTES associado a num-pedido
Acrescentar num-pedido, data-pedido e código-cliente em relação-
pedido
FAÇA ENQUANTO existir quantidade em ITENS-PEDIDOS associada a
num-pedido
Ler próxima quantidade
Ler nome-livro em LIVROS associada a quantidade
Acrescentar nome-livro e quantidade em relação-pedido
FIM-ENQUANTO
FIM-ENQUANTO
Enviar relação-pedido
FIM
f.3)
alteração-item = num-pedido + nome-livro
+ quantidade 1.8
ALTERAR
QUANTIDADE
ITEM PEDIDO
ITENS-PEDIDOS
Processo 1.8: Alterar Quantidade Item Pedido

INÍCIO
obter alteração-item
localizar quantidade em ITENS-PEDIDOS a num-pedido de alteração-
item em PEDIDOS e com nome-livro de alteração-item em LIVROS
substituir quantidade de ITENS-PEDIDOS por quantidade de alteração-

item
FIM
f.4)
pedido-cancelado = num-pedido 1.9
CANCELAR
PEDIDO ITENS-PEDIDOS
LIVRO
PEDIDOS
CLIENTE
LIVROS
Processo 1.9: Cancelar Pedido Livro

INÍCIO
Obter pedido-cancelado
Localizar num-pedido de pedido-cancelado em PEDIDOS
FAÇA ENQUANTO existir quantidade em ITENS-PEDIDOS associada a
num-pedido
Localizar próxima quantidade
Excluir quantidade de ITENS-PEDIDOS
FIM-ENQUANTO
Excluir num-pedido e data-padido de PEDIDOS
FIM
g)os exemplos a seguir utilizaram o ERA abaixo, onde

i)E1, E2, E3, E4 e E5 representam entidades genéricas;
ii) R1, R2, R3, R4 e R5 representam relacionamentos genéricos;
iii)A1e A2 representam agregações genéricas;
iv) “s” representa um atributo genérico do relacionamento R4;
v) ocorrências de E1, E2, E3 E4 e E5, são respectivamente denominadas e1,
e2, e3 e4 e e5;
vi) r1, r2, r3, r4 e r5 representam respectivamente ocorrências de R1, R2, R3,
R4 e R5.
A1 A2
E1 E2 E3
R1 R2
Os
R4
R3
R5
E4
E5
g.1) para recuperar uma ocorrência de E1 relacionada a E3, não é necessário

navegar por todas as entidades e relacionamentos que se encontram entre E1
e E3. É suficiente especificar como abaixo:
obter e3 emE3 associada a e1
g.2) em alguns casos, pode haver mais de um caminho entre as duas

entidades. Nesse caso, basta citar uma entidade ou relacionamento que
pertença exclusivamente ao caminho desejado:
obter e5 em E5 associado a e1 por R1.
g.3) criar uma ocorrência da entidade E5 e relacioná-la com as agregações A1

e A2 (notar que R4, por possuir atributo, será um depósito de dados do DFD,
ao passo que R2 não)
g.3.1) armazenar e5 em E5
relacionar e5 com r4 em R4 associado a e1 em E1 e a e4 em E4
g.3.2) armazenar e5 em E5
associar e5 com e2 em E2 e com e3 em E3.
5
DIAGRAMA DE TRANSIÇÃO DE ESTADOS
5.1 Introdução
O Diagrama de transição de Estados (DTE) é utilizado para modelar a

dimensão do controle, ou seja, a seqüência de operações em um sistema, que
ocorrem em resposta a estímulos externos. É um diagrama de grande utilidade
para a análise das mudanças ocorridas com as entidades e relacionamentos do
sistema, com o passar do tempo.
O DTE representa os eventos (estímulo externos) e estados (valores das
entidades e relacionamentos).
É importante ressaltar que o DTE representa a seqüência de operações do
sistema, que ocorre em resposta a estímulos externos, sem considerar, no
entanto, o que as operações fazem ou sobre que entidades elas atuam (esses
dois aspectos são representados no DFD).
5.2 Eventos
Um evento é um acontecimento que provoca reação do sistema. Quando um
evento ocorre, é produzido um estímulo para o sistema. Ao receber o estímulo,
o sistema reage executando alguma atividade ou ação.
Uma atividade é uma operação que consome tempo para ser executada, sendo
relevante representar a sua estrutura. A ação, por outro lado, é uma operação
instantânea – ou que consome um tempo insignificante para ser completada,
cuja estrutura não é relevante para o propósito do sistema.
Exemplo:
a) ”Emitir Requisição” é uma atividade, uma vez que consome tempo para ser
executada, e que o fluxo do controle durante a sua execução é relevante
para o propósito do sistema.
b) ”Apagar Sinal” pode ser considerada uma ação, por ser uma ação que
consome um tempo insignificante para ser completada e cuja estrutura não
é relevante para o propósito do sistema.
O estímulo pode transportar informações (atributos), que serão utilizados pela
atividade, ou por um simples “sinal”, indicando a ocorrência do evento.
As mudanças de estado das entidades são provocadas por eventos.
5.3 Estados
Um estado representa uma propriedade de uma entidade, associada a um
conjunto de valores de atributos e de relacionamentos da entidade. A
modificação de um estado para outro, provocada por um evento, é denominada
transição.
Exemplo: Quando o cliente efetua o pagamento de uma duplicata (evento), a

duplicata (entidade) muda do estado “duplicata a pagar” para o estado
“duplicata paga” (transição).
Um estado especifica a reação de uma entidade à ocorrência de um evento.
5.4 Condições
É uma função booleana de valores da entidade. As transições ocorrem
somente se uma determinada condição for verdadeira. Os estados podem ser
definidos em termos de uma condição.
Exemplo: quando chegar a data do vencimento (evento) e o pagamento não
tiver sido efetuada (condição), a duplicata está em atraso (estado
subsequente).
5.5 Notação Gráfica
O DTE é um grafo onde os estados são nós e os arcos direcionados são

transições rotuladas com o nome do evento.
Será constituído um DTE para cada entidade do sistema que possuir
comportamento significativo. A figura 8 representa a notação utilizada pelo
DTE.
Início Estado 1
faça: atividade
evento (atributos)
[condição] / ação
Estado 2
Fim
Figura 8: Notação para Diagrama de Transição de Estados

ANÁLISE ESSENCIAL
6.1 Introdução
Os conceitos introduzidos pela Análise Essencial endereçaram inicialmente as
duas principais dificuldades que os analistas enfrentavam com a duplicação da
Análise Estruturada: a distinção entre requisitos lógicos e físicos e a ausência
de uma abordagem para particicionar o sistema em partes tão independentes
quanto possível, de modo a facilitar o processo de análise.
Outra característica importante que diferencia as duas metodologias é que a
Análise Essencial constrói modelos distintos para representar as três
dimensões do mundo real: função, dado e controle.
Apesar de introduzir novos conceitos e novas abordagens, a Análise Essencial
preservou todos os métodos da Análise Estruturada – o Diagrama de Fluxo de
Dados, o Dicionário de dados e a Especificação da Lógica dos Processos.
Embora diferentes, a melhor maneira de abordar a Análise Essencial é encará-

la como uma evolução da Análise Estruturada.
6.2 Conceitos Básicos
6.2.1 Tecnologia Perfeita
A tecnologia utilizada na implementação de um sistema possui dois

componentes básicos: processadores, que executam atividades, e “containers”
que armazenam e transportam dados para os processadores. Esses dois
componentes da tecnologia necessitam ser projetados pelo analista (ou mais
especificamente pelo projetista), mas somente na fase de projeto. Durante a
fase de análise, o analista deve abstrair-se da tecnologia que deverá ser
utilizada na implementação do sistema.
Para orientar essa abstração, a Análise Estruturada recomenda que o analista,

durante a fase de análise, concentre-se apenas nos aspectos lógicos do
sistema, evitando pensar nos aspectos físicos. O problema dessa abordagem é
que a diferença entre o que é lógico e físico não é clara.
A tecnologia perfeita, por ser uma tecnologia de implementação, possui

também dois componentes: processador perfeito e “container” perfeito. No
entanto, diferente de qualquer tecnologia de implementação real, a tecnologia
perfeita não possui limitações.
O processador perfeito é capaz de executar qualquer custo, sem consumir

energia., sem ocupar espaço, sem gerar calor, sem jamais cometer erros ou
parar de funcionar.
O “container” perfeito não possui qualquer custo, sendo capaz de armazenar
quantidades infinitas de dados e ser acessado instantaneamente por qualquer
processador e da forma que lhe for mais conveniente, isto é, os dados estarão
sempre organizados da maneira que for mais conveniente ao processador.
Naturalmente, não existe uma tecnologia de implementação com tais
características. Qual é então a utilidade dessa abstração?
Quando o analista pensa em aspectos físicos, ele na verdade está tentando
identificar – e resolver – as limitações de uma determinada tecnologia.
Pensamentos típicos do gênero são: o quanto de espaço em disco vou
precisar? Qual o melhor método de acesso a esses dados, considerando essas
funções? Que capacidade de processamento devo necessitar? Na verdade,
nenhuma dessas preocupações são próprias da fase de análise.
Considerando agora que a tecnologia que será utilizada na implementação do
sistema é perfeita, todas as perguntas anteriores deixariam de ter importância ,
isto é, não preocupam mais o analista.
Assim sendo, para distinguir um requisito lógico de um requisito físico,
utilizando a abstração de tecnologia perfeita, formule a seguinte pergunta ao
identificar um requisito qualquer: “para atender ao seu propósito, o meu
sistema necessitará possuir essa capacidade ou essa característica, mesmo
considerando que ele será implementado em uma tecnologia perfeita?”
Se a resposta for sim, esses requisito é verdadeiro e deve ser representado no
DFD. Caso contrário, ele é falso e não deve ser representado no DFD.
6.2.2 Requisito Verdadeiro e Requisito Falso

Um requisito verdadeiro é definido como sendo uma capacidade ou
característica que o sistema deve possuir para atender ao seu propósito,
mesmo considerando que ele está implementado em uma tecnologia perfeita.
O conjunto dos requisitos verdadeiros forma a Essência do Sistema.
Um requisito falso, por outro lado, é uma capacidade ou uma característica que
o sistema não precisa possuir para atender ao seu propósito, caso ele
disponha de uma tecnologia de implementação perfeita.
Note que um requisito pode ser falso por duas razões. A primeira está ligada ao
propósito do sistema – requisito arbitrário – e a Segunda à abstração de
tecnologia perfeita – requisito tecnológico.
Um requisito é falso, do tipo arbitrário, se ele não necessita ser implementado
para que o sistema atenda ao seu propósito ou se ele corresponde a uma
organização das atividades do sistema, influenciada pelas ferramentas de
modelagem.
Um requisito é tecnológico quando o sistema não necessita possuir essa

capacidade ou característica, considerando que ele será implementado em
uma tecnologia perfeita. Embora importantes, os requisitos tecnológicos só
serão especificados na fase de projeto.
6.2.3 Sistema Interativo

É uma classe de sistemas construídos pelo homem, cuja característica mais
importante é a de serem interativos, isto é, agem sobre as coisas externas ao
sistema, as quais estão fora de seu controle, e essas coisas externas agem
sobre eles. Os sistemas construídos pelos analistas de sistemas são dessa
classe.
6.2.4 Eventos e Resposta

São nomes genéricos de interações entre o ambiente externo e o sistema. Um
evento é alguma mudança que ocorre no ambiente externo, à qual o sistema
deve responder para atender ao seu propósito. Uma resposta é o conjunto de
ações executadas pelo sistema quando um certo evento ocorre. Podemos
então dizer que um sistema interativo é um mecanismo evento-resposta.
Quando o sistema tem que “inventar” uma resposta para um evento, após a
sua ocorrência, dizemos que o sistema produz uma resposta “ad-hoc”.
Respostas desse tipo são produzidas pelo componente “ad-hoc” do sistema
interativo.
Quando as ações do sistema, executadas em resposta a um evento, foram
determinadas antes da ocorrência do evento, então dizemos que o sistema
produz uma resposta planejada. Essas respostas são produzidas pelo
componente de resposta planejada. Essas respostas são produzidas pelo
componente de resposta planejada do sistema interativo. Passaremos a
chamar o conjunto desses componentes de um sistema interativo de Sistema
de Resposta Planejada.
Uma outra característica dos sistemas interativos decorre do fato dos
componentes “ad-hoc” interagirem com os componentes de respostas
planejadas, para que determinadas respostas sejam produzidas. A figura 9
representa os componentes do sistema interativo.
resposta
componente ambiente do
de resposta componente sistema
ad-hoc
planejada interativo
estímulo
Figura 9 - Sistema Interativo

Apesar dos analistas desenvolverem sistemas que produzem tanto respostas

“ad-hoc” quanto respostas planejadas, a metodologia Análise Essencial
destina-se apenas ao desenvolvimento de Sistemas de Respostas Planejadas.
Isto significa que os componentes “ad-hoc” do sistema interativo estarão fora
do domínio de análise do analista, os quais farão parte do ambiente externo
que interage com o sistema de resposta planejada.
Podemos então concluir que um sistema de resposta planejada responde a um
conjunto de eventos predefinidos, que podem ser iniciados pelo componente
“ad-hoc” ou pelo ambiente externo do sistema interativo. A figura 10 representa
os componentes de resposta planejada. Note que o ambiente externo com o
qual o sistema de resposta planejada interage é composto do ambiente externo
do sistema interativo, acrescido de seu componente “ad-hoc”.
ambiente do
resposta
sistema
interativo
Componente estímulo Ambiente do
de resposta Sistema de
planejada Resposta
estímulo componente
Planejada
ad-hoc do
sistema
interativo
resposta
Figura 10 - Sistema de Resposta Planejada
As interações entre o sistema de resposta planejada e o ambiente podem

assim ser generalizadas: Quando um evento ocorre, é produzido um estímulo
para o sistema.. Ao receber o estímulo, o sistema inicia a execução do conjunto
de ações predefinidas, necessárias para responder ao evento. É importante
notar que nesse modelo de interação, toda ação que o sistema executa é uma
resposta a eventos, os quais são ocorrências externas e fora do controle do
sistema.
Os eventos são classificados em quatro tipos diferentes, dependendo da
maneira como ocorrem e da natureza do estímulo que produzem:
♦Evento Externo – é provocado por uma entidade externa, a qual envia dados
para o sistema. O estímulo produzido por esse tipo de evento é um fluxo de
dados. Os eventos externos são nomeados da seguinte forma:
Entidade externa que provocou o evento + ação + estímulo
♦Evento Externo de Solicitação – também é provocado por uma entidade

externa. No entanto, o estímulo produzido por esse tipo de evento é um fluxo
de controle, o qual apenas notifica o sistema da ocorrência do evento, sem
transmitir-lhe dados. Os eventos externos são nomeados da seguinte maneira:
Entidade externa que provocou o evento + ação + resposta

Exemplo: “Gerente solicita relação de clientes”
Note que o sistema para produzir uma relação dos clientes, ele não necessita
receber nenhuma informação do ambiente pois todas as informações
necessárias à resposta encontram-se armazenadas no próprio sistema. Assim
sendo, tudo o que o sistema precisa é conhecer o instante em que a resposta
deve ser produzida, o que lhe é sinalizado pelo estímulo (fluxo de controle).
♦Evento Temporal Fixo – ocorre única e exclusivamente em função da

passagem do tempo e em intervalos fixos de tempo. Esses eventos estimulam
as ações que o sistema tem que executar em datas previamente conhecidas,
isto é, diariamente, mensalmente, anualmente etc. (o tempo passa e chega o
momento do sistema fazer alguma coisa). Os eventos temporais fixos são
nomeados como abaixo:
É hora de + ação + resposta
Exemplo : “É hora de emitir contra-cheque”
♦Evento Temporal Relativo – também ocorre única e exclusivamente em

função da passagem do , tempo, mas a sua freqüência de execução não é
conhecida. Esse tipo de evento estimula as ações que o sistema tem que
executar quando uma determinada condição é satisfeita com o passar do
tempo. É importante frisar que a condição que determina a ocorrência do
evento temporal relativo é satisfeita única e exclusivamente com o passar do
tempo. Esses tipo de evento é nomeado com a própria condição que determina
a ocorrência do evento, ou da mesma forma que um evento temporal fixo.
Exemplo: “Empréstimo em atraso “ou” é hora de emitir relação de empréstimos
em atraso”
Nesse exemplo, a condição que determina a ocorrência do evento é a
existência de algum empréstimo em atraso (o empréstimo entra em atraso em
função da passagem do tempo).
Os estímulos produzidos pelos eventos temporais são sempre fluxos de
controle, isto é, eles apenas sinalizam que o sistema tem que executar alguma
ação.
6.2.5 Atividade Essencial

As atividades essenciais correspondem ao conjunto de ações executadas pelo
sistema, quando um certo evento ocorre, isto é, são todas as tarefas que o
sistema deve executar para atender completamente ao seu propósito, mesmo
considerando que ele será implementado em uma tecnologia perfeita.
As respostas produzidas pelas atividades essenciais são denominadas
respostas externas quando elas são fornecidas ao ambiente externo, que
interage com o sistema, e respostas internas quando elas são fornecidas ao
interior do próprio sistema, para criar ou atualizar a sua memória.
Toda atividade essencial é iniciada por um estímulo, produzido quando da
ocorrência de um evento. As circunstâncias em que a atividade é executada
depende da definição do estímulo.
Uma atividade essencial deve executar todo o conjunto de ações necessárias

para responder completamente e somente um evento. As atividades essenciais
subdividem-se em atividades fundamentais e atividades de custódia.
Uma atividade é fundamental quando ela produz uma informação que é parte
do propósito declarado do sistema. Isso significa dizer que o propósito do
sistema é atendido pelas atividades fundamentais, as quais produzem as
respostas externas do sistema.
A atividade de custódia cria e mantém a memória necessária à execução das
atividades fundamentais, adquirindo dados do ambiente externo ao sistema e
os armazenando nos depósitos de dados. As respostas internas são
produzidas pelas atividades de custódia do sistema.
Quando uma atividade executa tarefas dos dois tipos, ela é denominada
atividade composta. As atividades compostas produzem respostas internas e
respostas externas.
Os diferentes tipos de atividade essencial estão representados na figura 11
estímulo estímulo estímulo
resposta
externa resposta
Atividade Atividade Atividade externa
Fundamental de Custódia Composta
resposta resposta
interna interna
Memória Memória Memória
Figura 11 - Atividades Essenciais
Como as atividades essenciais só produzem respostas externas ou internas e

respondem completamente a um e somente um evento, a comunicação entre
elas será feita sempre via memória e nunca diretamente. Essa característica da
comunicação entre atividades essenciais torna o particionamento por eventos
uma abordagem adequada para dividir o problema em partes independentes.
6.2.6 Memória Essencial

Consiste no conjunto mínimo de dados que deve ser armazenado pelo sistema,
para atender ao seu propósito, considerando que ele será implementado em
uma tecnologia perfeita. No DFD, a memória essencial é representada pelos
depósitos de dados.
Para que a memória essencial possa atender às suas finalidades, é necessário
conhecer como o sistema adquire os dados que devem ser armazenados e
como ele garante que os dados estão suficientemente atualizados para servir
às atividades fundamentais. Essas duas tarefas – adquirir e atualizar os dados
– são executadas pelas atividades de custódia.
Um dos modelos utilizados para modelar a memória essencial é o Diagrama
Entidade-Relacionamento-Atributo (ERA). Para derivar os depósitos de dados
do DFDa partir do ERA, utilize a seguinte correspondência: cada entidade e
relacionamento com atributo do ERA será um depósito de dados do DFD.
A essência do sistema pode ser também definida como sendo o conjunto das
atividades essenciais e da memória essencial.
6.3 Acesso das Atividades de Custódia à Memória Essencial

Para manter a abstração de tecnologia perfeita consistentes, os depósitos de
dados não armazenam chaves estrangeiras para representar o relacionamento
entre objetos, pois essa é uma característica específica dos bancos de dados
relacionais – lembre-se que na fase de análise a tecnologia de implementação
ainda não foi selecionada.
Para indicar que o relacionamento entre objetos existe, sem no entanto definir
como ele será implementado, a representação dos acessos das atividades de
custódia à memória essencial devem obedecer à seguinte regra geral: ao criar
ou excluir uma ocorrência de um objeto que participa de relacionamento,
mostre acesso aos depósitos de dados que correspondem ao relacionamento e
às entidades que participam do relacionamento.
As figuras 12 a 14 mostram a representação gráfica desses acessos.
0s
E1 R1 E2
R2
Figura 12 - Modelo de Dados Genérico
Atividade Atividade
Essencial Essencial
E1 R1 E2 E1 E2
Figura 13 - Criar ou excluir uma Figura 14 - Criar ou Excluir uma

ocorrência de R1 ocorrência de R2
6.4 Sistema Encarnado

Um sistema é dito encarnado quando ele se encontra implementado em uma
determinada tecnologia.
Quando analisamos o sistema atual, na fase de levantamentos iniciais,
estamos analisando um sistema encarnado em uma determinada tecnologia,
que pode ser manual, computadorizada, equipamento de grande porte, micro
etc.
Toda tecnologia possui características e limitações que influenciam na sua
seleção – custo, capacidade, tolerância a falhas etc. Dessa forma, ao
analisarmos um sistema encarnado, deparamos com características que são
importantes para que o sistema atenda ao seu propósito e com características
que foram “introduzidas” para que o sistema pudesse superar as limitações da
tecnologia na qual ele foi implementado. Alguns exemplos de características
que existem nos sistemas encarnados para atender a limitações da tecnologia
são:
♦Fragmentação: partes diferentes de uma atividade essencial são executadas

por processadores diferentes.
♦Redundância: dados redundantes armazenados na memória do sistema ou

uma mesma atividade sendo executada por mais de um processador.
Extrinsecalidade: atividades e dados cuja finalidade é tratar as limitações da
tecnologia.
♦Conglomeração: ocorre quando fragmentos de várias atividades essenciais

são alocados a um mesmo processador ou quando elementos não
relacionados da memória essencial são alocados no “container”.
É importante que o analista seja capaz de reconhecer essas características, as
quais, por não pertencerem à essência do sistema atual, não devem influenciar
a essência e implementação do novo sistema.
6.5 Especificação da Essência do Sistema

A especificação da essência do sistema, produto da fase de análise, é
composta dos seguintes modelos:
♦Modelo Ambiental - representa o que sistema deve fazer para atender ao

ambiente. É composto dos seguintes modelos:
Propósito do Sistema – enuncia, tanto de forma genérica quanto de
forma específica, qual a finalidade do sistema. Normalmente, um único
parágrafo é suficiente para enuncia o propósito genérico. O propósito
específico corresponde a uma lista das informações que devem ser
produzidas pelo sistema.
Exemplo:
Propósito Genérico: o sistema tem com propósito tornar mais eficiente
o atendimento dos pedidos dos clientes da livraria e a emissão das
requisições de livros às editoras.
Propósitos Específicos: a) Emitir requisições de livros para as editoras
b) Emitir fatura de cobrança para os clientes
etc.
Lista de Eventos – lista de eventos aos quais o sistema deve responder. Deve
conter o nome do evento, o estímulo e a resposta externa do sistema.
Exemplo:
Evento Estímulo Fluxo de Dados Resposta

Externa
1- Cliente envia pedido Pedido -
2 - É hora de emitor requisição - Requisição
3 - Editora envia nota fiscal Nota Fiscal Fatura
Para identificar os eventos, formule uma ou mais das seguintes perguntas,

após Ter identificado um evento qualquer:
a) existem variações significativas nesse evento?
b) o “oposto’ ou o ‘negativo” desse evento é importante para o sistema?
c) Há eventos que devam anteceder a esse evento?
d) Há eventos que devam se seguir a esse evento?
Diagrama de Contexto
representa o sistema com um único processo e suas interações com o
ambiente
♦Modelo Comportamental
- representa o que o interior do sistema deve fazer para atender ao ambiente. É
composto de:
Diagrama de Entidade – relacionamento – Atributo (ERA)

- representa a estrutura estática dos dados do sistema. Modela a memória
essencial do sistema, isto é, a memória mínima necessária para que o sistema
atinja seu propósito, considerando que ele será implementado em uma
tecnologia perfeita.
Diagrama de Fluxo de Dados Particionado por Eventos

- diagrama em que cada processo representa uma atividade essencial. Como
para cada evento será construído um diagrama contendo uma atividade
essencial, a quantidade de diagramas do DFD particionado por eventos é
equivalente ao número de eventos da lista de eventos.
Diagrama de Transição de Estados (DTE)

- representa o comportamento dos objetos do sistema em função da passagem
do tempo. Será construído um DTE para cada entidade ou relacionamento com
atributo do ERA que possuir comportamento significativo, isto é, possuir mais
de um estado ao longo de seu ciclo de vida.
Diagrama de Fluxo de Dados Organizado em Níveis Hierárquicos

- representa os processos em níveis hierárquicos, a partir do diagrama zero. Os
processo do diagrama zero são obtidos através da agregação das atividades
essenciais do DFD particionado por eventos. Para agregar atividades
essenciais as seguintes heurísticas podem ser utilizadas, em conjunto ou em
separado:
a) procurar agregar em único processo todas as atividades essenciais que
acessam um determinado depósito de dados. Verificar se o processo
resultante dessa agregação é adequado para representar uma das funções
do sistema.
b) agregar todas as atividades de custódia que acessam exclusivamente um
único depósito de dados.
c) procurar identificar uma função do sistema agregando atividades essenciais
que interagem com uma mesma entidade externa
d) representar no DFD um processo para cada uma das funções do negócio,
as quais, muitas das vezes, correspondem a setores da própria estrutura
organizacional. Agregar as atividades essenciais aos processos para os
quais as suas ações mais contribuam.
Observe que as três primeiras heurísticas seguem uma abordagem bottom-
up, enquanto a Quarta segue uma abordagem top-down.
Dicionário de Dados
- descreve os dados representados no ERA, no DFD e no DTE.
Especificação da Lógica dos Processos
- descreve a lógica dos processos do DFD que não foram detalhados em

diagramas de nível inferior (lógica dos processos primitivos).
ESTUDO DE CASO 3
Para cada situação descrita a seguir, identificar os eventos (Nome, Tipo,

Estímulo e Respostas) e construir o DFD Particionado por Eventos. Na solução
do problema, utilizar o seguinte ERA simplificado:
•Cod
o Nome
matricula • Nome
o End
(0,N)
Aluno Disciplina
possui
(0,N)
(0,2)
(0,N)
o Valor
(1,1) o Sala
(0,N)
nota Avaliação locação
(0,N)
o Data
• Número Horário
• Hora
• Dia
a) trimestralmente a secretária informa ao sistema o horário e a saída de cada

disciplina.
b) os alunos são cadastrados quando a secretária informa o resultado do
processo de seleção.
c) os alunos efetuam suas matrículas preenchendo o formulário para
matrículas
d) os professores informam as notas de seus alunos até quinze dias após a
data de realização de cada prova
e) os alunos que possuem disciplinas com média (parcial ou final) inferior a 5.0
(cinco) devem ser notificados
f) os alunos podem solicitar o cancelamento de matrículas até quinze dias
após a data de início do curso.
g) após a revisão de prova, os professores informam as alterações de notas.
ESTUDO DE CASO 4
BIBLIOTECA ESCOLA
Descrição do Mini-Mundo:
A direção da Biblioteca do Departamento de Informática deseja desenvolver um

sistema para automatizar o controle de empréstimos de livros aos alunos.
A Biblioteca só empresta livros a alunos previamente cadastrados. O

cadastramento é feito mediante a apresentação da ficha de matrícula na
secretaria da Biblioteca e o preenchimento do formulário para cadastramento
de aluno, contendo nome, endereço e telefone. De posse desse formulário, a
Secretária preenche o cartão de usuário, que é imediatamente entregue ao
aluno. O formulário preenchido é arquivado no cadastro de alunos, para
atender a consultas futuras. A Biblioteca possui atualmente cerca de 200
alunos cadastrados.
Sempre que um fornecedor entrega os livros, a Secretária confere a nota fiscal

e preenche as fichas de livro e uma ficha de empréstimo, que fica armazenada
na contra capa do livro. A cada semestre são adquiridos cerca de 40 novos
títulos.
Quando um professor adota uma obra como livro texto de uma disciplina, ele
pode efetuar um bloqueio de livro. Para cadastrar um professor, a direção da
Biblioteca informa à secretaria seu nome, sala e telefone. Cada professor pode
bloquear até 7 obras. Enquanto durar o bloqueio, os livros não poderão ser
emprestados e os alunos somente poderão consultá-los na própria Biblioteca.
Para bloquear um livro, o professor envia à secretaria um formulário de
bloqueio, que permanece arquivado na pasta de bloqueio.
No final de cada semestre, a secretaria envia a cada professor, a relação de

seus bloqueios. Com base nessa relação, os professores informam à secretaria
os bloqueios que devem permanecer, sem o que são automaticamente
cancelados. Os professores também podem cancelar um bloqueio a qualquer
momento, simplesmente informando o fato à secretaria. O número de obras
bloqueadas é, em média, igual a 20 por semestre.
Quando a direção da Biblioteca informa a exclusão de um professor do corpo

docente, seus bloqueios são automaticamente cancelados.
Cada aluno cadastrado pode retirar, por empréstimo, até 5 livros desde que
não estejam bloqueados por nenhum professor e que o aluno não esteja com
a devolução de nenhum livro em atraso.
Ao emprestar um livro, a Secretária confere o cartão de usuário do aluno,

verifica a situação do livro na pasta de bloqueio e a situação do aluno na
relação de livros em atraso. Se o empréstimo for possível, ela preenche a ficha
de empréstimo, que é então arquivada no fichário de livros emprestados. Essa
ficha possui o código do livro , o código do aluno, a data de empréstimo, a data
prevista para a devolução e a data em que ela ocorreu. Quando o aluno
devolve o livro, a Secretária lança a data de devolução na ficha de empréstimo,
que retorna à contra capa do livro. São emprestadas, em média, 50 obras por
mês.
O prazo máximo de empréstimo de um livro é de uma semana. Toda Sexta-

feira, a Secretária pesquisa a pasta de empréstimos e envia para a direção da
Biblioteca a relação de livros em atraso. Esse procedimento só é executado
uma vez por semana, por ser muito demorado e trabalhoso.
As exclusões de alunos e livros são informadas pela Direção da Biblioteca.

ESTUDO DE CASO 5
COOPERATIVA DE ALIMENTOS
Descrição do Mini-Mundo:
A Cooperativa de Alimentos Amizade é uma organização que fornece aos seus

associados alimentos a preços reduzidos. Para conseguir isso, a cooperativa
adquire alimentos, em grandes quantidades, de fazendeiros e atacadistas da
região. A diretoria da cooperativa está considerando a possibilidade de
automatizar alguns processos administrativos, especialmente os que se
referem à compra e distribuição de alimentos e ao controle de pagamentos e
recebimentos relativos às operações.
A cooperativa funciona em ciclos semanais. Os associados podem enviar (ou
entregar pessoalmente), de Segunda a Quinta-feira, lista de compras,
utilizando o formulário pré-impresso distribuído pela cooperativa.
Toda Sexta-feira, a diretoria recebe uma relação contendo a demanda total de
cada item. De posse dessas demandas, ela negocia, junto aos fornecedores
cadastrados, as condições de compra mais econômicas. Selecionados os
fornecedores, são feitas as encomendas, inicialmente pelo telefone e
posteriormente formalizadas através do envio de um pedido ao fornecedor.
Dependendo do volume de itens a ser adquirido, mais de um fornecedor pode
fornecer um mesmo item. Esse fato faz com que o item possa ter mais de um
preço. A Diretoria nem sempre consegue adquirir todos os itens selecionados.
As encomendas são entregues à cooperativa no Domingo pela manhã, quando
então os pedidos são conferidos com a nota fiscal de cada fornecedor. Após a
conferência, as notas fiscais são certificadas e as duplicatas permanecem
arquivadas, aguardando pagamento, nos prazos anteriormente negociados
pela Diretoria.
Ainda no Domingo, em hora determinada pela diretoria, tem início a montagem
das cestas de cada associado, com base nas listas de compras e nas notas
fiscais. A prioridade de cada associado é definida pela ordem de chegada de
sua lista. As cestas são entregues na própria cooperativa, acompanhadas das
Notas de Entrega.
Os associados podem, desde que estejam com todos os seus pagamentos em
dia, inclusive a mensalidade, efetuar pedidos de compra para pagamento no
final do mês,. Infelizmente, como alguns associados não saldaram seus
débitos, a diretoria se viu forçada a estabelecer, como condição básica para
aceitação de uma lista de compras, a quitação de todos os débitos anteriores.
Exemplos de Possíveis Problemas do Sistema Atual
1- Muita demora, em média 5 horas por semana, para consolidar o pedido de

todos os associados, tendo em vista que o processamento é manual e exige
consulta a todos os pedidos da semana;
2- Cerca de 15 mensalidades deixam de ser cobradas a cada mês, em virtude

do cadastro de associados não estar devidamente atualizado; e
3- Há muita demora, em média 3 horas por semana, e ocorrem muitos erros,

em média 5 por semana, no processo de cálculo do preço final a ser
cobrado dos associados, em virtude do cálculo ser manual e exigir a
realização de várias operações aritméticas.
Exemplos de Possíveis Necessidades não Atendidas pelo Sistema Atual
1- Informações históricas dos preços cobrados pelos fornecedores, visando a

orientar as negociações, nas compras semanais da Cooperativa;
2- Informações históricas sobre encomendas não atendidas por cada

fornecedor, visando a identificação dos fornecedores mais confiáveis; e
3- Informação mensal sobre o volume de compras de cada associado, visando

a orientar a adoção de uma política de incentivo ao uso da Cooperativa.
ESTUDO DE CASO 6
ACADEMIA DE GINÁSTICA
Descrição do Mini-Mundo
Uma academia de ginástica oferece atividades esportivas (natação, ginástica

aeróbica, dança, musculação etc.) em várias filiais.
As atividades oferecidas em cada filial, bem como o horário e o número de
vagas, são definidos pela Coordenação Esportiva.
O valor das mensalidades é fixado mensalmente pela Coordenação
Administrativa, em função do tipo de atividade, época do ano, índices
inflacionários, valores cobrados pelos concorrentes e localização da filial.
A contratação de professores é feita pela Coordenação Esportiva. A
remuneração dos professores corresponde a 30% do valor das mensalidades
efetivamente pagas pelos seus alunos. O valor a paga a cada professor é
calculado no dia 5 de cada mês, com base nos valores efetivamente pagos
pelos alunos no mês anterior (inclusive multa).
As mensalidades vencem sempre no dia 20. Todo dia 10 devem ser emitidos
avisos de cobrança para os alunos, os quais são remetidos pelo correio. As
mensalidades são pagas na própria filial.
A taxa de matrícula corresponde à mensalidade do mês corrente, a qual é
cobrada no ato da matrícula.
Alunos com mensalidade em atraso são impedidos de participar da atividade,
até a regularização do débito. O valor de uma mensalidade em atraso é
calculado com base no valor da mensalidade vigente no dia do pagamento,
acrescido de multa de 20%.
Alunos com 15 dias de atraso no pagamento de uma mensalidade devem
receber uma solicitação de regularização de débito. Com 30 dias de atraso, o
aluno tem sua matrícula cancelada, sendo notificado do fato.
No final do dia, a Coordenação Administrativa deve receber um relatório,
organizado por filial, contendo matrículas efetuadas no dia, matrículas
canceladas no dia e o número de vagas ainda disponíveis em cada atividade.
Ao final do mês deve ser gerado um relatório consolidando o movimento
mensal de matrículas de cada filial. Esses relatórios são utilizados para avaliar
a performance do gerente da filial.
REFERÊNCIAS BIBLIOGRÁFICAS
DeMarco,T; “Análise Estruturada e Especificação de Sistemas”; Rio de Janeiro;

Campus, 1978.
Grane, C, & Sarson, T; “Análise Estruturada de Sistemas’; Rio de Janeiro; LTC,
1979.
McMenamim, S. M. & Palmer; J. F.; “Análise Essencial de Sistemas”, São
Paulo; McGraw-Hill, 1984.
Ward,P. T; “Desenvolvendo Sistemas sem Complicação”; Rio de Janeiro; LTC;
1987.
Yourdon, E. “Modern Structured Analysis”!; New Jersey; Prentice Hall, 1989.

Apostila Blaschek de Análise de Sitemas

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Apostila Blaschek de Análise de Sitemas

Caricato da

Copyright:

Formati disponibili

Departamento de Informática

Métodos de Análise de Sistemas

COORDENAÇÃO CENTRAL DE EXTENSÃO

4.3 Estruturas de Controle -------------------------------------------------------------23

1.2 Análise de Sistemas

Ela envolve três etapas: o aprendizado; a estruturação e a representação dos

1.4 Processo de Desenvolvimento de Sistemas de Informação

Etapa 1: Planejamento Estratégico (nível organização)

Etapa 2: Levantamentos Iniciais (início do nível aplicação)

a) descrição do sistema atual:

b) construção do modelo do sistema atual:

c) identificação dos problemas do sistema atual:

d) identificação das necessidades não atendidas pelo sistema atual:

e) definição dos requisitos para um novo sistema:

f) formulação de alternativas de solução:

g) redação do plano do projeto:

1.6 Dimensões de um Modelo

1.7 Nível de Abstração de um Modelo

1.8 Modelagem de Sistemas de Informação

1.8.1 Dimensões do Mundo Real

1.8.2 Níveis de Abstração

2.2 Características da Metodologia

2.3 Princípios Utilizados na Solução de Problemas

♦ Abstração: utilizado para separar aspectos que estão ligados a uma

♦ Dividir-para-Conquistar: um problema grande e complexo pode ser

2.4 Modelos da Metodologia

2.5 Diagrama de Fluxo de Dados (DFD)

Figura 1- Representação Gráfica do Processo

2.5.2 Fluxo de Dados

Figura 2 - Representação Gráfica de Fluxo de Dados

Conforme representado na figura 3, fluxos de dados podem convergir ou

X Todos os "X" são enviados aos dois destinos

2.5.3 Depósito de Dados

Notação DeNarco Notação Gane

Nome do depósito de dados

Nome do depósito (substantivos Código do depósito de dados

Figura 4 - Representação Gráfica de Depósito de Dados

A Semântica dos Acessos aos depósitos de dados é ilustrado na figura 5.

2.5.4 Entidade Externa

Indica que a entidade externa

2.6 Organização de DFD em Níveis

Especificação Processo Processo Processo Processo

Figura 7 - DFD Organizado em Níveis Hierárquicos

2.7 Recomendações para Construção de DFD

2.8 Diretivas da Metodologia

A Livraria ABC atua no mercado de livros há mais de 20 anos. Sua estratégia

A editora Fofoca pública atualmente 6 revistas de distribuição nacional. Devido

3.2 Organização e Simbologia

A seguir são apresentados alguns exemplos de utilização destes símbolos:

a) o registro do depósito de dados de clientes é composto, obrigatoriamente,

b) o cliente pode não possuir telefone ou possuir mais de um telefone (o

c) o cliente possui no mínimo um telefone, e no máximo três.

d) o cliente pode não possuir telefone ou possuir no máximo três.

e) o cliente possui no mínimo um telefone, podendo possuir vários outros.

f) o cliente deve possuir um telefone, podendo ser comercial ou residencial.

g) o cliente pode possuir telefone comercial, residencial ou ambos.

3.3 Estrutura das Definições

A seguir são apresentados as convenções utilizadas nas definições de cada

3.3.1 Depósitos de Dados, Entidades e Relacionamentos com Atributo

LIVROS = *Cadastro de Livros da Livraria* significado

As chaves primárias dos depósitos de dados são assinaladas na definição do

chave primária do depósito de dados LIVROS

Cliente = *cliente da livraria*

LIVROS = Cadastro de Livros da Livraria significado

Cliente = cliente da livraria

aluno = aluno da universidade

0 Endereço 0 Sala professor = professor da universidade

item-pedido = item do pedido de um cliente estrutura de dados

pedido-livro = pedido de livros dos clientes da livraria fluxo de dados