Você está na página 1de 28

FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I

1
Apostila2-AESI-FAP.doc

ANÁLISE ESTRUTURADA DE SISTEMAS I – 2o período – Sistemas de


Informação (2008/2)

ETAPA DE PROJETO E IMPLEMENTAÇÃO DO SISTEMA

Depois que o levantamento de dados relativo ao sistema foi efetuado e verificou-se


que o sistema é viável, o analista passa para a fase de análise do sistema. Nesta fase
deverá ser definido o que terá que ser feito, ou seja, é o momento de determinar o
modelo lógico do sistema.

Durante a fase de análise o analista deverá elaborar os seguintes documentos:


diagrama de fluxo de dados, diagrama de contexto, diagrama de entidade-
relacionamento, diagrama geral do sistema e dicionário de dados. Estes documentos
servirão de base para a fase seguinte do ciclo de desenvolvimento de sistemas, ou
seja, a fase projeto.

1. DIAGRAMA DE FLUXO DE DADOS (por Edward Yourdon)

O diagrama de fluxo de dados é uma ferramenta de modelagem que nos permite


imaginar um sistema como uma rede de processos funcionais, interligados por "dutos"
e "tanques de armazenamento" de dados. Na literatura do processamento de dados, e
em suas conversas com outros analistas de sistemas e usuários, você pode usar
qualquer um dos termos abaixo como sinônimo de diagrama de fluxo de dados:

• Diagrama de bolhas
• DFD (abreviatura)
• Modelo de processo
• Diagrama de fluxo de trabalho
• Modelo funcional

O diagrama de fluxo de dados é uma das mais utilizadas ferramentas de modelagem


de sistemas, principalmente para sistemas operativos nos quais as funções do sistema
sejam de fundamental importância.

1.1 OS COMPONENTES DE UM DFD

A figura 1 mostra um DFD típico de um pequeno sistema. Antes de analisarmos seus


componentes em detalhe, observe que:

• Ele não precisa de explicações; basta olharmos para ele para compreendê-lo.
Isso é especialmente importante quando lembramos quem supostamente
examinará a figura - não o analista de sistemas, mas o usuário.

• O diagrama acomoda-se facilmente em uma página.

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
2

pedidos
inválidos
DEPÓSITO
CLIENTES PEDIDOS

detalhes de detalhes de
livros
pedidos remessas
pedidos

nome do cliente,
1. endereço do cliente 2.
RECEBER REMETER
informações
PEDIDOS LIVROS
de
cobranças
CLIENT ES

nome do cliente,
FATURAS endereço do cliente
livros
f aturas,
declarações
detalhes de 3.
faturas COLETAR
PAGAMEN- pagamentos,
consultas
CLIENT ES
TOS

Figura 1 – Um DFD típico

Os componentes de um DFD são: processo, fluxo, depósito e fluxo. A seguir


explicaremos cada um deles.

• Processo: o primeiro componente de um DFD é conhecido como processo. Os


sinônimos mais conhecidos são bolha, função e transformação. O processo mostra
uma parte do sistema, a que transforma entradas em saídas - isto é, mostra como
uma ou mais entradas são convertidas em saídas. O processo é representado
graficamente por um círculo, como se vê na figura 2(a). Alguns analistas de
sistemas preferem usar um oval, ou um retângulo de vértices curvos, como
mostrado na figura 2(b); outros preferem ainda um retângulo, como na figura 2(c).
As diferenças entre esses três formatos são puramente cosméticas, embora seja
obviamente importante utilizar o mesmo formato de maneira consistente para
representar todas as funções do sistema. Em nossos exercícios utilizaremos a
representação da figura 2(a).

O processo é denominado ou descrito em uma sentença simples. O nome do


processo descreverá o que o processo faz e é composto por uma frase constituída
de um verbo e de um objeto, como VALIDAR ENTRADA ou CALCULAR VALOR
DO IMPOSTO.

CALCULAR CALCULAR CALCULAR


IMPOSTO IMPOSTO IMPOSTO
SOBRE SOBRE SOBRE
VENDAS VENDAS VENDAS

Figura 2(a) – Exemplo de processo Figura 2(b) – Representação Figura 2(c) - Outra
alternativa de um processo representação de um
processo

• Fluxo: um fluxo é graficamente representado por uma seta que entra ou sai de
um processo; a figura 3 representa um exemplo de fluxo. O fluxo é utilizado para
mostrar o movimento de fragmentos ou de pacotes de informações de um ponto a

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
3
outro do sistema. Desse modo, o fluxo representa dados em movimento, enquanto
os depósitos representam dados em repouso.
consulta de cliente

Figura 3 – Um exemplo de fluxo

O nome do fluxo representa o significado do pacote que se move pelo fluxo.

O fluxo também mostra direção: uma seta em uma das extremidades do fluxo
(ou em ambas) indica se os dados entram ou saem do processo (ou as duas
coisas).

• Depósito: o depósito é utilizado para se modelar uma coleção de pacotes de


dados em repouso. A representação para um depósito são duas linhas paralelas,
como na figura 4(a); uma notação alternativa é mostrada na figura 4(b); outra
representação é mostrada na figura 4(c). Normalmente o nome escolhido para
identificar o depósito é o plural do nome dos pacotes transportados pelos fluxos
para dentro e para fora do depósito.

Os depósitos são interligados aos processos por fluxos. Dessa maneira, o contexto
em que um depósito se apresenta em um DFD é um (ou ambos) dos seguintes:
• Um fluxo de um depósito
• Um fluxo para um depósito

Um fluxo que parte de um depósito é interpretado como uma leitura ou um


acesso feito às informações desse depósito. Um fluxo para um depósito é descrito
como uma escrita, uma atualização ou possivelmente uma eliminação. Por isso,
esses fluxos, não necessariamente, precisam ser rotulados.

D1 PEDIDOS PEDIDOS
PEDIDOS

Figura 4(a) – Representação Figura 4(b) – Uma representação Figura 4(c) – Outra
gráfica de um depósito alternativa para um depósito representação gráfica de um
depósito

• Terminador: o componente seguinte do DFD é o terminador; ele é


graficamente representado por um retângulo, como mostrado na figura 5. Os
terminadores representam entidades externas com as quais o sistema se
comunica. Tipicamente, o terminador é uma pessoa ou um grupo de pessoas, por
exemplo, uma organização externa ou uma empresa do governo ou um grupo ou
setor que esteja dentro da mesma companhia ou organização, mas fora do
controle do sistema que está sendo modelado. Em alguns casos, o terminador pode
ser outro sistema, por exemplo, algum outro sistema de processamento com o qual
nosso sistema se comunicará.

DEPARTAMENTO
DE
CONTABILIDADE

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
4
Figura 5 – Representação gráfica de um terminador

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
5
Existem três importantes aspectos a serem lembrados sobre terminadores:

1. Eles são externos ao sistema que estamos modelando; os fluxos que interligam os
terminadores aos diversos processos de nosso sistema representam a interface
entre o sistema e o mundo externo.

2. O analista de sistemas não pode modificar o conteúdo, ou a organização ou os


procedimentos relativos aos terminadores.

3. Qualquer relacionamento existente entre terminadores não será mostrado no DFD.


Alguns relacionamentos desse tipo podem existir de fato, mas, por definição, eles
não fazem parte do sistema que estamos estudando. Inversamente, se existirem
relacionamentos entre terminadores e for essencial que o analista de sistemas os
modele para documentar de forma correta os requisitos do sistema, então, por
definição, os terminadores são realmente parte do sistema e devem ser modelados
como processos.

1.2 DIRETRIZES PARA ELABORAÇÃO DE UM DFD

Existem algumas diretrizes adicionais necessárias para utilizar DFD com sucesso.
Algumas dessas diretrizes o auxiliarão a não construir DFD incorretos (isto é,
incompletos ou logicamente inconsistentes) e algumas outras se destinam a ajudá-lo a
desenhar DFD agradáveis à vista e, portanto com mais possibilidade de serem
examinados com atenção pelo usuário.

As diretrizes são as seguintes:

• Escolher nomes significativos para os processos, fluxos, depósitos e terminadores.

• Numerar os processos.

• Refazer o DFD tantas vezes quantas forem necessárias até obter uma boa estética.

• Evitar DFD complexos demais.

• Certificar-se de que o DFD seja internamente consistente além de manter a


consistência com os outros DFD.

• Escolher Nomes Significativos para os Processos, Fluxos,


Depósitos e Terminadores

Um bom método para nomes de processos é utilizar um verbo e um objeto. Isto é,


empregar um verbo que represente ação (um verbo transitivo, que exige um objeto) e
um objeto adequado formando uma sentença descritiva do processo. Eis alguns
exemplos de nomes de processos:

• CALCULAR TRAJETÓRIA DO MÍSSIL


• PRODUZIR RELATÓRIO DE INVENTÁRIO
• VALIDAR NÚMERO DE TELEFONE
• DESIGNAR ALUNOS PARA SALAS

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
6
Quando são utilizados verbos do tipo "elástico" (verbos cujo sentido pode ser
estendido para significar quase tudo), muitas vezes significa que o analista de
sistemas não está bem certo de qual função está sendo executada ou que várias
funções foram reunidas mas que não o deveriam ser. Eis alguns exemplos de maus
nomes de processos:

FAZER SERVIÇO
• FUNÇÕES DIVERSAS
• MANIPULAR ENTRADA
• CUIDAR DOS CLIENTES
• PROCESSAR DADOS
• EDIÇÃO GERAL

Os nomes escolhidos para os processos (e também para os fluxos e os terminadores)


devem provir de um vocabulário conhecido pelo usuário. Isto acontecerá naturalmente
se o DFD for desenhado como resultado de uma série de entrevistas com o usuário e
se o analista de sistemas tiver um mínimo conhecimento do objeto subjacente da
aplicação.

• Numerar os Processos

Como um método prático de referências os processos de um DFD, devemos numerar


cada bolha. Não importa a maneira de fazer isso - da esquerda para a direita, de baixo
para cima, ou de outra maneira qualquer - desde que você seja consistente no modo
como atribui os números.

A única coisa que você deve ter em mente é que o esquema de numeração implicará,
para os eventuais leitores do seu DFD, uma determinada seqüência de execução.

• Evitar DFD Complexos Demais

O propósito de um DFD é modelar corretamente as funções que um sistema deve


executar e as interações entre elas. Porém um outro objetivo do DFD é ser lido e
compreendido, não somente pelo analista de sistemas que elaborou o modelo, mas
também pelos usuários que são os conhecedores do assunto correlacionado. Isso
significa que o DFD deve ser prontamente compreendido, facilmente absorvido e
agradável aos olhos.

Não crie um DFD com demasiados processos, fluxos, depósitos e terminadores. A


maioria dos casos isso quer dizer que não se deve incluir mais de meia dúzia de
processos e depósitos, fluxos e terminadores a eles relacionados em um único
diagrama.

• Refazer o DFD Tantas Vezes Quantas Forem Necessárias

Em um projeto de análise de sistemas do mundo real, o DFD terá de ser feito, refeito e
novamente refeito, por dez ou mais vezes, até que esteja (1) tecnicamente correto,
(2) aceitável pelo usuário e (3) tão bem desenhado que você não fique constrangido
em mostrá-lo à junta de diretores de sua empresa.

• Certificar-se de que o DFD Seja Logicamente Consistente

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
7
Existem algumas diretrizes que são utilizadas para fazer com que o próprio DFD seja
consistente. As principais diretrizes para a consistência são estas:

• Evite os poços sem fundo, bolhas que têm entradas mas não têm saídas.
• Evite bolhas com geração espontânea; bolhas que têm saídas mas não entradas
são suspeitas e geralmente incorretas.
• Cuidado com processos sem rótulos. Isso geralmente é sinal de desatenção, mas
pode revelar erros mais sérios: às vezes o analista de sistemas omite o rótulo de
um processo porque simplesmente não conseguiu encontrar um nome satisfatório.
• Cuidado com depósitos de leitura-apenas ou escrita-apenas. Esta diretriz é análoga
à diretriz sobre processos de entrada-apenas ou de saída-apenas; um depósito
típico deve ter entradas e saídas. A única exceção a esta diretriz é o depósito
externo que serve como interface entre o sistema e o terminador externo.

EXEMPLO DE UM DFD

Para desenharmos um DFD é necessário que tenhamos feito o levantamento


de dados do sistema e que saibamos o que o usuário pretende com o sistema
que será desenvolvido. Isto está descrito no que chamamos de documento de
requisitos do sistema.

DOCUMENTO DE REQUISITOS

A empresa XYZ Ltda deseja um sistema para controlar o Departamento de


Recursos Humanos (RH). O sistema deve:
• Emitir crachá para os funcionários com os seguintes dados: matrícula, nome,
descrição do cargo, nome do departamento, número/série da carteira de trabalho.
O crachá será emitido pelo RH e será utilizado pelo funcionário, para identificação
do mesmo dentro da empresa.

• Emitir relatório de funcionários com nome do departamento, matrícula, nome, cargo


e valor do salário dos funcionários. O relatório deve ser agrupado por
departamento. Este relatório será utilizado pelo RH e pelo Gerente Administrativo.

• Controlar os eventos que cada funcionário participou: registrar a data de início e do


término do evento, o título do evento e em que cidade foi realizado o evento.
Entenda-se por evento: cursos, palestras, treinamentos, ...

• Emitir relatório dos eventos que o funcionário participou com todos os dados
descritos no item anterior, incluindo matrícula e nome do funcionário. Este relatório
será utilizado pelo RH.

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
8
• Emitir relatório dos eventos que estão programados para cada funcionário, com a
data de início, título do evento, matrícula e nome do funcionário, local do evento
(cidade). Este relatório será utilizado pelo RH.

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
9
DIAGRAMA DE FLUXO DE DADOS (DFD)

dados
funcionários
1
Cadastrar funcionários
funcionários

dados eventos
2 eventos
Cadastrar
eventos

RH

dados func p/ 3 func_eventos


evento Cadastrar
funcionários
por evento
solicita crachá funcionários

3
crachá Emitir
Funcionário crachá

solicita
rel.funcionários
RH 4
Emitir
rel.funcionários relatório
funcionários

rel.funcionários
Gerente ADM

5
solicita rel.eventos realiz.
Emitir funcionários
relatório
rel eventos eventos eventos
realizados realizados func_eventos
RH
solicita
rel.eventos
6
programados
Emitir
rel.eventos relatório
programados eventos
programados

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
10

1.3 DFD COM NÍVEIS

O DFD deve ser modelado em uma série de níveis de modo que a cada nível ofereça
sucessivamente mais detalhes sobre uma parte do nível que lhe seja superior.

A organização dos níveis de um DFD é mostrada conceitualmente na figura 6.

1 2
O
FIGURA 0
SISTEMA

3 4

DIAGRAMA DE CONTEXTO

3.1 3.2

FIGURA 3

3.3 3.4

Figura 6 – Diagramas de fluxo de dados em níveis

O DFD de nível mais alto consiste de uma única bolha, representando o sistema
inteiro; os fluxos de dados mostram as interfaces entre o sistema e os terminadores
externos. Esse DFD especial é conhecido como diagrama de contexto.

O DFD imediatamente abaixo do diagrama de contexto é conhecido como figura 0. Ele


representa a visão de mais alto nível das principais funções do sistema bem como as
principais interfaces entre essas funções. Cada uma dessas bolhas deve ser numerada
para mais fácil identificação.

Os números também servem como um meio prático de se relacionar uma bolha com o
DFD de nível imediatamente inferior que descreve essa bolha de modo mais completo.
Por exemplo:

• A bolha 2 da figura 0 está associada ao DFD de nível inferior conhecido


como figura 2. As bolhas da figura 2 são numeradas como 2.1, 2.2, 2.3 etc.

• A bolha 3 da figura 0 está associada ao DFD de nível inferior conhecido


como figura 3. As bolhas da figura 3 são numeradas como 3.1, 3.2, 3.3 etc.

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
11
• A bolha 2.2 da figura 2 está associada ao DFD de nível inferior conhecido como
figura 2.2. As bolhas da figura 2.2 são numeradas como 2.2.1, 2.2.2, 2.2.3 etc.

Se uma bolha possuir um nome (e de fato deve possui-lo!), então esse nome é
transportado para a figura de nível imediatamente abaixo. Assim, se a bolha 2.2 tem o
nome CALCULAR TAXA DE VENDAS, então a figura 2.2, que subdivide a bolha 2.2
mais detalhadamente, deve ser rotulada como "figura 2.2: CALCULAR TAXA DE
VENDAS".

Como se pode ver, esse é um modo bastante direto de se organizar um


potencialmente enorme diagrama de fluxo de dados em um grupo de partes
manipuláveis. Mas existem algumas 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 ? Cada figura de DFD deve ter não
mais de meia dúzia de bolhas e de depósitos a elas relacionados. Assim, se você
tiver subdividido um sistema grande em três níveis, mas o DFD de nível mais baixo
ainda contêm 50 bolhas cada um, você deve estabelecer pelo menos mais um nível
abaixo desse.

2. Existem diretrizes sobre o número de níveis que devem ser esperados em um


sistema típico? Em um sistema simples, encontram-se provavelmente dois ou três
níveis; um sistema de médio porte apresenta costumeiramente de três a seis
níveis; e um sistema grande terá de cinco a oito níveis. Deve-se ter cautela com
pessoas que afirmam que qualquer sistema pode ser modelado em exatamente
três níveis - alguém assim também vai tentar vender-lhe a ponte Rio-Niterói. Por
outro lado, lembre-se de que o número total de bolhas cresce exponencialmente
quando se passa de um nível para o imediatamente inferior. Se, por exemplo, cada
figura tiver sete bolhas, então haverá 343 bolhas no terceiro nível, 16.807 bolhas
no quinto nível e 40.353.607 de bolhas no nono nível.

.4. Todas as partes do sistema devem ser subdivididas até o mesmo nível de
detalhamento? A resposta é "Não". Algumas partes de um sistema podem ser mais
complexas que outras e podem exigir a subdivisão em mais um ou dois níveis.

5. Como se mostram esses níveis para o usuário? Muitos usuários só desejarão ver um
diagrama. Um usuário executivo de alto nível pode querer ver apenas o diagrama
de contexto ou talvez a figura 0; um usuário de nível operativo pode querer ver
apenas a figura que descreve a área do sistema em que ele esteja interessado.
Mas se alguém quiser ver uma grande parte do sistema ou talvez o sistema inteiro,
então faz sentido apresentar-lhe os diagramas na metodologia top-down:
começando pelo diagrama de contexto e descendo aos níveis inferiores de maior
detalhamento.

6. Como garantir que os níveis dos DFD sejam consistentes entre si? Os fluxos de
dados que entram e saem de uma bolha em um nível devem corresponder aos
fluxos que entram e saem de uma figura inteira do nível imediatamente inferior
que descreve aquela bolha. A figura 7(a) mostra um exemplo de diagrama de fluxo
de dados equilibrado; a figura 7(b) mostra dois níveis de um DFD não-equilibrado.

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
12

A X

1 2 B 3.1 3.2
O B Y
A X
SISTEMA

3 Z 4 3.3 3.4
C
Z Y
C

DIAGRAMA DE FIGURA 0 FIGURA 3


CONTEXTO
Figura 7(a) – Um fragmento de DFD equilibrado

A P

1 2 B 3.1 3.2
D
O B Y
A X
SISTEMA

3 Z 4 3.3 3.4
C
Z Y
C
DIAGRAMA DE FIGURA 3
CONTEXTO FIGURA 0

Figura 7(b) – Um fragmento de DFD desequilibrado

7. Como mostrar depósitos nos diversos níveis? Esta é uma área em que a
redundância é deliberadamente introduzida no modelo. A diretriz é a seguinte:
mostre um depósito no nível mais alto onde ele serve primeiramente como
interface entre duas ou mais bolhas; em seguida, mostre-o novamente em CADA
diagrama de nível inferior que descreva (ou subdivida) as bolhas interfaceadas. A
figura 8 mostra um depósito compartilhado por dois processos de alto nível, A e B;
o depósito seria novamente mostrado nas figuras de nível mais baixo, que ampliam
a descrição de A e B.

A X A.1 X B.1 X

B A.2 B.2

Figura 8 – A exibição de depósitos nos níveis inferiores

8. Como realmente se faz a subdivisão dos DFD em níveis? A abordagem top-down é


intuitivamente muito atraente. Pode-se imaginar começar pelo diagrama de
contexto e depois desenvolver a figura 0 e, em seguida, descer metodicamente
aos níveis inferiores de detalhamento. Entretanto, existem problemas nessa

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
13
abordagem; uma abordagem mais bem-sucedida é identificar primeiramente os
eventos externos aos quais o sistema deve reagir e usar esses eventos para criar
um esboço do DFD.

EXEMPLO DE UM DFD COM NÍVEIS

Vamos usar o mesmo exemplo utilizado anteriormente, só que dessa vez o


DFD será desenhado com níveis. O DFD possuirá a figura 0, a figura 1 (onde
serão representados os cadastros) e a figura 2 (onde serão representados os
relatórios).

DIAGRAMA DE FLUXO DE DADOS

FIGURA 0

dados cadastrais 1

Efetuar
cadastros
func_eventos

RH solicita relatórios funcionários

eventos
2

relatórios
Emitir relatórios

rel.funcionários
Gerente ADM

crachá

Funcionário

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
14

FIGURA 1: EFETUAR CADASTROS

dados funcionários 1.1


funcionários

Cadastrar
funcionários

1.2
dados eventos
RH eventos
Cadastrar
eventos

dados func/evento
1.3

Cadastrar
funcionários func_eventos
por evento

funcionários

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
15

FIGURA 2: EMITIR RELATÓRIOS

crachá
Funcionário 2.1

Emitir crachá
solicita crachá

funcionários
solicita rel.funcionários

RH 2.2

rel.funcionários
Emitir relatório
funcionários
rel.funcionários

Gerente ADM

2.3
solicita rel.eventos realizados
Emitir relatório
eventos func_eventos
rel.eventos realizados
funcionários
realizados
eventos
RH
solicita rel.eventos 2.4
programados
Emitir relatório
eventos
rel.eventos programados programados

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
16

2. DIAGRAMA DE CONTEXTO (Edward Yourdon)

O diagrama de contexto é um caso especial do diagrama de fluxo de dados, no qual


uma única bolha representa o sistema inteiro.

Exemplo de um diagrama de contexto para um sistema de pedidos de livros:

pedidos de
GRÁFICAS
CLIENT ES reimpressão

pedidos
livros que
chegam ao
depósito
fatura Sistema
de
Pedidos de
situação de
Livros crédito

fatura
DIREÇÃO
relatórios de CONTABILIDADE
vendas

O diagrama de contexto realça diversas características importantes do sistema:

• As pessoas, organizações ou sistemas com os quais nosso sistema comunica-


se. Esses elementos são conhecidos como terminadores.
• Os dados que nosso sistema recebe do mundo exterior e que devem ser
processados de alguma maneira.
• Os dados produzidos pelo nosso sistema e enviados para o mundo exterior.
• Os depósitos de dados que são compartilhados por nosso sistema e os
terminadores. Esses depósitos de dados ou são criados na parte externa do
sistema e usados por nosso sistema ou são criados por nosso sistema e
usados externamente ao sistema.

2.1 A CONSTRUÇÃO DO DIAGRAMA DE CONTEXTO

O diagrama de contexto compõe-se de terminadores, fluxos de dados, depósitos de


dados (somente externos) e um único processo representando todo o sistema.
Estudaremos cada um deles a seguir:

O processo consiste em uma única bolha. O nome dentro da bolha é normalmente o


nome do sistema ou um “apelido” convencionado para o sistema.

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
17

Sistema
PROJETO
de
GX-20
Contabilidade

E, no caso mais extremo, o novo sistema pode representar toda uma organização;
nesse casos, o nome do processo seria, normalmente, o da própria organização.

AJAX
LTDA.

Os terminadores são representados por um retângulo. Eles comunicam-se


diretamente com o sistema através de fluxos de dados ou através de depósitos de
dados externos.

CLIENTE
AJAX
LTDA

pedido

AJAX Dados Pesquisa


Mercado
LTDA

FIRMAS DE
PESQUISA

Três outras observações devem ser feitas sobre os terminadores:

1. Alguns terminadores podem ter um grande número de entradas e saídas. Para


evitar um diagrama desnecessariamente congestionado, pode ser conveniente
desenhar o terminador mais de uma vez, como mostrado na figura 1. Observe que os
terminadores duplicados são marcados com um asterisco; uma convenção alternativa
é representar os terminadores duplicados com uma linha diagonal, como mostrado na
figura 2.

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
18

FORNECEDORES
CLIENTE
*

AGÊNCIA
AJAX
DE CLIENTE
ANÚNCIOS
LTDA.
*

SEGUROS CONTABILIDADE

BANCOS

Figura 1 – Diagrama de contexto com terminador CLIENTE repetido.

CLIENTE

Figura 2 – Convenção alternativa para representar repetição.

2. Quando o terminador é uma só pessoa, é preferível indicar o papel que a pessoa


desempenha, em vez de indicar a identidade da pessoa; desse modo, a figura 3a é
melhor que a figura 3b. Existem dois motivos para isso: primeiro, a pessoa que
executa o papel pode ser substituída em um determinado momento, e é desejável que
o diagrama de contexto permaneça estável e correto, mesmo que ocorram mudanças
no pessoal. E, segundo, uma só pessoa pode desempenhar diversos diferentes papéis
no sistema; ao invés de mostrar um terminador rotulado “João Souza” com diversos
fluxos não interrelacionados de entrada e de saída, é mais significativo apresentar os
vários papéis que João Souza desempenha, cada um como um terminador separado.

ENCARREGADO
JOÃO SOUZA
DE REMESSAS

Figura 3a Figura 3b

3. Todos os terminadores representados no diagrama de contexto devem estar


presentes no diagrama de fluxo de dados, e vice-versa.

Os fluxos mostrados no diagrama de contexto modelam os dados que chegam ao


sistema e os que são transportados para fora dele.

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
19

EXEMPLO DE UM DIAGRAMA DE CONTEXTO

Vamos desenhar o diagrama de contexto do exemplo que utilizamos


anteriormente.

DIAGRAMA DE CONTEXTO

dados cadastrais;

solicita relatórios

rel.funcionários
RH SISTEMA DE Gerente ADM
CONTROLE
relatórios DE RH

crachá

Funcionário

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
20

3. CONCEITOS BÁSICOS DE DIAGRAMA DE ENTIDADE-


RELACIONAMENTO
Neste tópico estudaremos os conceitos básicos de um diagrama de entidade-
relacionamento (DER). Esse assunto será estudado com detalhes na disciplina de
Banco de Dados I, no próximo semestre. Portanto, neste momento, será passado
somente o que é necessário para que possamos entender o que esse diagrama
influencia nos demais diagramas que estudaremos em nossa disciplina de Análise
Estruturada de Sistemas.

A técnica de modelagem de dados mais difundida e utilizada é a abordagem entidade-


relacionamento (ER). Nesta técnica o modelo de dados é representado através de um
modelo entidade-relacionamento (modelo ER). Usualmente, um modelo ER é
representado graficamente, através de um diagrama de entidade-relacionamento
(DER). Alguns conceitos são fundamentais para a construção de um DER: entidade,
relacionamento, cardinalidade de relacionamento, atributo e entidade associativa.
Esses conceitos serão apresentados a seguir.

1. ENTIDADE

Entidade representa um conjunto de objetos sobre os quais se deseja guardar


informações. Exemplos de entidades: produtos, clientes, vendas, compras. Em um
DER, uma entidade é representada através de um retângulo que contém o nome da
entidade, sendo que esse nome deve estar no singular.

Produto Cliente Venda

2. RELACIONAMENTO

Relacionamentos são conexões entre duas ou mais entidades. É representado por um


losango, ligado por linhas aos retângulos representativos das entidades que
participam do relacionamento.

Produto Venda Cliente

3. CARDINALIDADE DE RELACIONAMENTO

Uma propriedade importante de um relacionamento é a de quantas ocorrências de


uma entidade podem estar associadas a uma determinada ocorrência através do
relacionamento. Esta propriedade é chamada de cardinalidade de uma entidade em
um relacionamento. As cardinalidades podem ser:

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
21

• Um para Um – 1:1
Um cliente pode estar
Exemplo1: relacionado a somente 1
1 1 endereço.
Cliente Endereço Um endereço pode ter
somente 1 cliente
relacionado a ele.

• Um para Muitos – 1:N


Exemplo 2: Uma compra pode ter somente
1 N 1 fornecedor relacionado a ela.
Fornecedor Compra Um fornecedor pode estar
relacionado a várias compras.

• Muitos para Muitos – N:N


Exemplo 3: Um médico pode estar
N N relacionado a várias
Médico med_esp Especialidade especialidades.
Uma especialidade pode estar
relacionada a vários médicos.

Para fazermos a leitura do modelo, partimos de determinada entidade e a


cardinalidade correspondente a essa entidade é representada no lado oposto. No
exemplo 2, a cardinalidade N faz referência a FORNECEDOR, já a cardinalidade 1, faz
referência a COMPRA. Isso significa que:

• Uma ocorrência de fornecedor pode estar associada a várias ocorrências de


compra (o fornecedor poderia estar associado a uma ou mais ocorrências de
compra e, neste caso, prevalece o maior valor, ou seja, o N);

• Uma ocorrência de compra está associada a APENAS uma ocorrência de fornecedor


(em uma compra é possível ter somente um fornecedor – observe uma nota fiscal,
no cabeçalho da mesma, há espaço para preencher somente os dados de um
fornecedor e não de vários).

OBSERVAÇÃO: toda vez que tivermos um relacionamento com cardinalidade N:N, este
relacionamento deve ser nomeado, como representado no exemplo 3 acima.
Normalmente o nome do relacionamento é a junção das entidades que o compõe.

Exemplo 4:
N N N 1
Produto prod/venda Venda Cliente

Neste exemplo 4 temos que:


• Uma venda pode estar relacionada a SOMENTE um cliente;
• Um cliente pode estar relacionado a VÁRIAS vendas, ou seja, a empresa pode vender para
o mesmo cliente hoje, amanhã, no próximo mês e assim por diante;
• Uma venda pode estar relacionada a VÁRIOS produtos, ou seja, em uma venda é possível
que tenhamos um, dois, três, vinte, ..., produtos;

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
22
• Um produto pode estar relacionado a VÁRIAS vendas. Por exemplo, a empresa tem
quantidade 10 em estoque de determinado produto. É possível que ela faça, por exemplo, 5
vendas de 2 unidades desse produto.

4. ATRIBUTO

É uma característica relevante associada a cada ocorrência de entidade ou


relacionamento (no caso de relacionamento, este somente poderá possuir atributos
quando a cardinalidade for N:N).

Exemplos:

Cliente {RG, CPF, nome, sexo}

Produto {Código, descrição, marca, quantidade_estoque}

4.1 CHAVE PRIMÁRIA (PK – PRIMARY KEY)

É um atributo ou um conjunto de atributos que identificam unicamente uma


ocorrência em uma entidade. Para indicar qual (is) atributo(s) é a chave primária,
iremos sublinhar este(s) atributo(s). Vale ressaltar que toda entidade deve possuir
uma chave primária (PK). Por exemplo, no caso da entidade produto definida acima,
iremos definir que a chave primária (PK) será o código. Portanto, a representação fica
assim:

Produto {Código, descrição, marca, quantidade_estoque}

4.2 CHAVE ESTRANGEIRA (FK – FOREIGN KEY)

Quando temos um relacionamento com cardinalidade 1:N, a entidade do lado N


recebe a chave primária (PK) da entidade do lado 1 como chave estrangeira (FK). Ou
seja, quando a chave primária de uma entidade é levada para outra entidade, nesta
outra entidade ela é tida como chave estrangeira. Por exemplo:

1 N
Fornecedor Compra

Fornecedor {Código, razão_social, endereço, cidade, UF, fone, e-mail}

Compra {Numero_NF, data_compra, CFOP, cód_fornecedor}


(FK)
estrangeira
Chave

5. ENTIDADE ASSOCIATIVA

Todo relacionamento N:N dá origem a dois relacionamentos 1:N através de uma nova
entidade denominada entidade associativa. A chave primária (PK) dessa nova
entidade normalmente é a concatenação das chaves primárias das entidades

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
23
principais. No exemplo 3, temos um relacionamento N:N entre médico e
especialidade. Vejamos como ficaria esse exemplo:

Exemplo 3:

N N
Médico med_esp Especialidade

O relacionamento méd_esp é uma entidade associativa e deve receber as chaves


primárias de Médico e de Especialidade.

Médico {CRM, nome, endereço, cidade, UF, CEP, celular, fone_residencial}

Especialidade {Código, descrição}

Méd_esp {CRM, Cód_especialidade}

Como foi dito acima, o relacionamento N:N dá origem a dois relacionamentos 1:N,
portanto, poderíamos desenhar o DER assim:

1 med_esp/ N N med_esp/ 1
Médico Med_Esp Especialidade
medico espec

A lista de entidades com as definições dos seus atributos chamaremos de Dicionário


de Dados Simplificado. No caso do exemplo do sistema para controlar o departamento
de Recursos Humanos da empresa XYZ que estamos usando, temos o seguinte DER e
Dicionário de Dados Simplificado.

DIAGRAMA DE ENTIDADE-RELACIONAMENTO

N N
Funcionário func_evento Evento

Uma outra forma de representar o Der acima é a seguinte:

1 N N 1
func_ evento_
Funcionário Func_Evento Evento
func_evento func_evento

DICIONÁRIO DE DADOS SIMPLIFICADO

• Funcionário {matricula, nome, cargo, departamento, num_CT, serie_CT,


vlr_salário}

• Evento {codigo, titulo, data_inicio, data_fim, local}

FK FK
• Func_Evento {matricula, cód_evento}

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
24

4. DIAGRAMA GERAL DO SISTEMA


Também conhecido por Diagrama de Módulos, apresenta os módulos do sistema, as
ligações entre eles, os seus submódulos e/ou itens.
Sistema de
Controle de
Estoque

Cadastros Movimentações Relatórios Sair

Grupos
Compras Gerais
Produtos

Cadastro
Produtos Clientes
Pedido

Cancelam ento
Clientes Fornecedores
Pedido

Emissão
Vendedores Vendedores
Pedido

Condições de
Vendas Produtos
Pagamento

Cadastro
Fornecedores Lista Precos
Nota Fiscal

Cancelam ento
Estoque Atual
Nota Fiscal

Emissão Produtos mais


Nota Fiscal Vendidos

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
25

5. DICIONÁRIO DE DADOS

O dicionário de dados é uma coleção de informações a respeito de dados. Para cada


elemento, são registradas as seguintes informações:
• ATRIBUTO  indica o nome do elemento. Este nome pode ser abreviado.
Evitar usar acentuação, pois alguns bancos de dados não aceitam nomes de
atributos acentuados;
• TIPO  indica o tipo do atributo. O padrão ANSI (American National Standards
Institute) determina que os tipos possíveis que um campo pode assumir são:
caracter, inteiro, real, data, hora;
• TAMANHO  Colocar o tamanho do campo quando o mesmo for do tipo
caracter, inteiro ou real. Quando o campo for do tipo real, colocar o tamanho da
parte inteira seguida do sinal de + e o tamanho da parte decimal. Por exemplo:
5+2, significa que o campo terá 5 dígitos na parte inteira e dois dígitos na parte
decimal;
• OBRIGATÓRIO  informar SIM caso seja obrigatório o preenchimento deste
campo e colocar NÃO, caso contrário. Essa informação vai ser utilizada pelo
programador quando ele for implementar o programa referente a esta tabela
(arquivo). Se o campo estiver com SIM, significa que não pode deixar passar
com branco ou zero, ou seja, o programa deve emitir uma mensagem de erro,
caso isto aconteça;
• DESCRIÇÃO  informar, de forma clara, uma descrição textual explicando o
atributo;
• ÍNDICES  mostrar quais são os índices do arquivo. O primeiro índice será,
obrigatoriamente, a chave primária (PK – primary key) do arquivo. Caso existam
chaves secundárias, informar como 2, 3, ...
• DOMÍNIOS DISCRETOS  um atributo terá domínio discreto quando ele
somente puder assumir valores previamente definidos pelo analista de
sistemas. Neste caso, no quadro de domínio discreto, deverá aparecer o
atributo, os valores que podem ser assumidos pelo atributo e uma descrição
explicativa.
• CHAVE(S) ESTRANGEIRA(S)  quando o arquivo possuir chave estrangeira
(FK – foreign key), informar o atributo do arquivo em questão que é chave
estrangeira e a referência, ou seja, em qual arquivo este atributo é chave
primária e o nome do atributo.
Durante a análise o dicionário de dados ajuda o analista a organizar informações a
respeito delas. Além disso, o dicionário de dados serve de auxílio à memória. Certas
informações-chaves terão que ser registradas para cada elemento; a informação em
falta alerta claramente o analista para uma necessidade a conhecer.
O dicionário de dados pode ser utilizado para gerar formatos de registro, arquivo e
base de dados durante o projeto do sistema. Durante a implementação o dicionário de
dados serve como base comum em relação à qual todos os programadores que
estiverem trabalhando em um sistema podem comparar suas descrições de dados.
Após a implementação, o dicionário fornece ao programador de manutenção uma
clara idéia de como um elemento de dados em particular é utilizado, informação
preciosa quando um programa precisa ser modificado.

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
26
O dicionário de dados pode ter implicações amplas. Considere, por exemplo, um
grande programa envolvendo os esforços de diversos programadores. Se todos os
programadores tiverem que desenvolver descrições de dados a partir de um dicionário
de dados comum, vários problemas potencialmente graves poderão ser evitados. A
um nível mais alto, sistemas diferentes terão que ser vinculados ou interfaceados. Em
geral, o dicionário de dados pode ajudar a melhorar as comunicações entre amplos
segmentos de uma organização, simplesmente pela fixação de um conjunto de
definições consistentes para os dados.
Enquanto a nova aplicação estiver sendo desenvolvida, o analista de sistemas pode
conferir os elementos de dados necessários em relação ao dicionário de dados central
da organização. Alguns elementos de dados já existirão, e utilizando os nomes e
formatos estabelecidos podem economizar ao analista uma boa parcela de trabalho.
Ao destacar elementos já existentes, o dicionário de dados pode ajudar o analista a
evitar redundância de dados, um problema que ocorre quando um elemento de dado
determinado estiver armazenado fisicamente em diversos lugares diferentes, sob
diversos formatos diferentes, e com níveis ligeiramente diferentes de controle.

EXEMPLOS:

Entidade Descrição
CIDADE Contém as cidades de todos os clientes/fornecedores da
empresa.

ATRIBUTOS
ATRIBUTO TIPO TAMANHO OBRIGATÓRIO DESCRIÇÃO
CÓDIGO Inteiro 4 Sim Código da cidade
NM_CID Caracter 50 Sim Nome da cidade
DDD_CID Caracter 4 Não DDD da cidade

ÍNDICE(S)
Nº ATRIBUTO
1 (pk) CÓDIGO

Entidade Descrição
CLIENTE Contém os clientes da empresa com todos os dados pessoais.

ATRIBUTOS
ATRIBUTO TIPO TAMANHO OBRIGATÓRIO DESCRIÇÃO
CD_CLI Inteiro 5 Sim Código do cliente
NM_CLI Caracter 50 Sim Nome do cliente
DT_NASC Data --- Não Data de nascimento do cliente
Sexo do cliente (ver Domínios
SEXO_CLI Caracter 1 Sim
Discretos)
Tipo de cliente (ver Domínios
TIPO_CLI Caracter 1 Sim
Discretos)
END_CLI Caracter 50 Sim Endereço do cliente

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
27

COD_CID Inteiro 4 Sim Código da cidade do cliente

ÍNDICE(S)
Nº ATRIBUTO

1 (pk) CD_CLI

DOMÍNIO(S) DISCRETO(S)
ATRIBUTO VALORES DESCRIÇÃO
M Masculino
SEXO_CLI
F Feminino
F Pessoa Física
TIPO_CLI
J Pessoa Jurídica

CHAVE(S) ESTRANGEIRA(S)
ATRIBUTO REFERÊNCIA
COD_CID CIDADE.CODIGO

BIBLIOGRAFIA

YOURDON, E. Análise Estruturada Moderna. Rio de Janeiro: Campus, 1990.

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE
FAP – Faculdade de Apucarana Disciplina: Análise Estruturada de Sistemas I
28

LEMBRETES IMPORTANTES
(para desenhar corretamente o DFD)

1. No DFD, o nome dos depósitos de dados deve estar no plural.


2. Todos os fluxos que saem do terminador para o processo devem ser rotulados (por
exemplo: dados de produtos, solicita consulta livros, solicita relatório de leitores). E
todo fluxo que sai do processo para o terminador deve, também, ser rotulado (por
exemplo: relatório de leitores, consulta de livros). Estes são os únicos casos em
que é obrigatório colocar nome nos fluxos no DFD.
3. O processo deve:
• ter um número que o identifica (este número deve aparecer na parte
superior da bolha – dentro da bolha).
• ter um nome, sendo que este nome deve ser um verbo (no infinitivo) +
um objeto.
4. No DFD, deve ser evitado o cruzamento de fluxos. Caso seja necessário, pode-se
repetir o terminador ou o depósito de dados, para que o desenho não fique
complexo demais.
5. Se um determinado processo no DFD estiver fazendo leitura ou leitura/gravação de
mais de um depósito de dados, pode-se desenhar estes depósitos “grudados” e
colocar somente um fluxo de leitura saindo, obrigatoriamente, do primeiro
depósito.
6. No DFD, quando estiver sendo efetuado um cadastro de um depósito que possui
uma FK (chave estrangeira), deve-se, obrigatoriamente, fazer uma leitura do
depósito onde esta chave estrangeira é PK (chave primária), para garantir a
integridade da base de dados (integridade referencial).
7. No DFD, em caso de relatórios, devem ser verificadas quais informações são
pedidas que sejam impressas. E aí, deve-se representar a leitura dos depósitos
onde estas informações estão armazenadas. O mesmo vale para as consultas.
8. No DFD em níveis, todos os depósitos de dados que aparecem no nível mais
inferior devem aparecer também nos níveis superiores, no processo referente ao
nível mais baixo. O mesmo vale para os terminadores.

Professora: Márcia Cristina Dadalto Pascutti – pascutti@fap.com.br 2º


BIMESTRE