Projeto Estruturado de Sistemas

Profa. Denise Franzotti Togneri

Sumrio

Projeto Relacional de Dados

Normalizao do Modelo Relacional
Modelo de Processadores
DFD de Projeto
Modelo de Tarefas
Projeto Modular de Programas

Denise F. Togneri

Projeto Relacional de Dados

Projeto de Dados O Modelo Relacional

O modelo relacional (Relational Model - RM) foi descrito pela

primeira vez, em 1969, num discurso publicado por Dr. E. F.
Codd, cientista de bancos de dados da IBM, que baseou o
modelo pela noo de conjuntos matemticos.
Este modelo, portanto, est fortemente baseado na teoria
matemtica sobre relaes; da o nome relacional.
Conjuntos de dados so representados por tabelas de valores.
Cada tabela, denominada relao, bidimensional, sendo
organizada em linhas e colunas.

Denise F. Togneri

Projeto de Dados O Modelo Relacional

De acordo com Codd definimos um sistema como relacional se,

e somente se, suportar pelo menos o seguinte:

Bancos de dados relacionais, isto , bancos de dados que

possam ser percebidos pelo usurio como tabelas, e nada
mais alm do que tabelas. Os dados so organizados em
conjuntos matemticos lgicos, numa estrutura tabular
(tabelas), cada qual designada por um nome nico.
Pelo menos as operaes de seleo, projeo e juno
(natural), sem necessitar de nenhuma pr-definio dos
percursos de acesso fsicos para suportar tais operaes.

Denise F. Togneri

Conceitos Bsicos

Relao
Tabela de valores bidimensional organizada em linhas e
colunas. Representa um conjunto de entidades do Modelo
E/R.
Grau da Relao
Nmero de colunas da tabela.
Linha (Tupla)
Representa uma entidade do conjunto de entidades.
Colunas
representam os vrios atributos do conjunto de entidades.
Clula
Item de dados elementar da linha i, coluna j.
Ex: 12/03/87 (contedo da linha 5, coluna 5)

Denise F. Togneri

Conceitos Bsicos

Chave Primria
Atributo ou combinao de atributos que possuem a
propriedade de identificar de forma nica uma linha da
tabela. Corresponde a um atributo determinante do Modelo
Conceitual.
Chaves Candidatas
Ocorrem quando em uma relao existe mais de uma
combinao de atributos possuindo a propriedade de
identificao nica. Ex: matrcula, CPF
Chave Estrangeira
Ocorre quando um atributo de uma relao for chave
primria em outra relao.
Denise F. Togneri

Conceitos Bsicos

Ligaes
Representam os relacionamentos do Modelo E/R. A ligao
entre duas relaes feita:
Para classe de relacionamento 1:1 ou 1:N: em geral,
transportando-se a chave de uma relao para outra
(item transposto);
Para classe de relacionamento N:N: criando-se uma nova
tabela, tendo como chave primria as chaves transpostas
das 2 relaes envolvidas

Denise F. Togneri

Propriedades do Modelo Relacional

Nenhum campo componente de uma chave primria pode ser nulo;

Cada clula de uma relao pode ser vazia (exceto de uma chave
primria), ou ao contrrio, conter no mximo um nico valor;

A ordem das linhas irrelevante;

No h duas linhas iguais;

Cada coluna tem um nome e colunas distintas devem ter nomes
distintos;

Usando-se os nomes para se fazer referncia s colunas, a ordem

destas torna-se irrelevante;

Denise F. Togneri

10

Propriedades do Modelo Relacional

Cada relao recebe um nome prprio distinto do nome de

qualquer outra relao da base de dados;
os valores de uma coluna so retirados todos de um mesmo
conjunto, denominado domnio da coluna;
Duas ou mais colunas distintas podem ser definidas sobre um
mesmo domnio;
um campo que seja uma chave estrangeira ou um item
transposto s pode assumir valor nulo ou um valor para o qual
exista um registro na tabela onde ela chave primria.

Denise F. Togneri

11

Diagrama Relacional

Representao grfica das ligaes entre tabelas de um modelo

relacional, na qual:

a) as relaes (tabelas) provenientes de conjunto de

entidades e dos agregados do Modelo E/R, so
representadas por retngulos, com uma referncia chave
primria da tabela em cima.
#matr

FUNCIONRIOS

Denise F. Togneri

12

Diagrama Relacional
b) as ligaes que derivam dos relacionamentos, so
representadas por linhas contnuas, associadas aos
smbolos abaixo:
Cardinalidade

Ligao

(0,1)
(1,1)
(0,N)
(1,N)
Denise F. Togneri

13

Diagrama Relacional
c) No caso de transposio de chave, representaremos a chave
transposta em cima do retngulo com um subscrito t.
d) Atributos no so representados nos diagramas, mas sim em um
dicionrio de tabelas do modelo relacional. Ex:
Tabelas:
Departamentos
#cdigo: string(3)
nome: string(40)
dt_criao: data
matrcula_chefe: inteiro(5)

Funcionrios
#matrcula: inteiro(5)
cpf: inteiro(11)
nome: string(30)

Denise F. Togneri

Normalizao do Modelo Relacional de

Banco de Dados

14

Normalizao do Modelo Relacional de

Banco de Dados

15

Inicialmente ser feita uma comparao entre os modelos conceitual,

lgico e fsico de dados.

Modelo Conceitual de Dados:

No modelo conceitual de dados os objetos, suas caractersticas e
relacionamentos tm a representao fiel ao ambiente observado,
independente de limitaes quaisquer impostas por tecnologias, tcnicas
de implementao ou dispositivos fsicos. Este modelo utilizado a nvel
de conversao, entendimento, transmisso, validao de conceitos,
mapeamento do ambiente, etc.

Neste nvel devem ser ignoradas quaisquer particularidades de

implementao, bem como desconsiderada qualquer preocupao com
qual ser o modo de implementao futura. Como j visto
anteriormente, o modelo conceitual surge na fase de Engenharia de
Requisitos e no na fase de projeto.
Denise F. Togneri

Normalizao do Modelo Relacional de

Banco de Dados

16

Modelo Lgico de Dados:

O modelo lgico de dados aquele em que os objetos, suas

caractersticas e relacionamentos tm a representao de acordo com as
regras de implementao e limitantes impostos por algum tipo de
tecnologia. Essa representao, por sua vez, independente dos
dispositivos ou meios de armazenamento fsico das estruturas de dados
por ela definida.

Este modelo deve ser o modelo elaborado respeitando-se e

implementando-se conceitos tais como chaves de acesso, controles de
chaves duplicadas, itens de repetio (arrays), normalizao, ponteiros,
headers, integridade referencial, entre outros.
O modelo lgico de dados est associado fase de projeto do sistema
e sua obteno se dar pela aplicao de regras de derivao sobre um
modelo conceitual de dados j construdo.

Denise F. Togneri

Normalizao do Modelo Relacional de

Banco de Dados

17

Modelo Fsico de Dados:

O modelo fsico de dados aquele em que a representao dos objetos

feita sob o foco do nvel fsico de implementao das ocorrncias, ou
instncias das entidades e seus relacionamentos. O conhecimento do
modo fsico de implementao das estruturas de dados ponto bsico
para o domnio desse tipo de problema.

Cada SGBD diferente poder definir um modo diferente de

implementao fsica das caractersticas e recursos necessrios para o
armazenamento e manipulao das estruturas de dados. Em alguns
casos, um mesmo SGBD em diferentes ambientes de sistema
operacional (DOS, UNIX, MVS, VMS) poder ter diferentes mtodos de
armazenamento e manuseio das estruturas de dados e alocao fsica.

Denise F. Togneri

Derivao do Modelo Conceitual para o

Lgico

18

feita pela aplicao de um conjunto de regras bem definidas. Essas

regras atuaro, basicamente, em 2 grupos distintos de elementos:

as estruturas de relacionamento, agregao e especializao;

as entidades e seus atributos.

As regras a serem apresentadas visaro gerao de um modelo lgico
baseado na abordagem relacional.

PASSOS PARA DERIVAO DO MODELO LGICO

1. Obter o modelo relacional
2. Definir o tipo de implementao (hierrquico, relacional, OO, ...)
3. Aplicar as regras de derivao especficas, de acordo com o tipo de
implementao escolhido.
4. Adaptar o modelo lgico s necessidades.
Denise F. Togneri

Derivao do Modelo Conceitual para o

Lgico

19

ADAPTAES NO MODELO LGICO DERIVADO

Visa criar estruturas de implementao que atendam s

reais expectativas das aplicaes em aspectos tais como
desempenho, flexibilidade, independncia e segurana.
A insero proposital de pequenas doses de redundncia,
desnormalizao, seccionamento de modelos, etc, tm sido,
entre outros, os artifcios inseridos nos modelos adaptandoos para os aspectos prticos do dia-a-dia, artifcios estes
feitos em funo da imperfeio e limitaes da tecnologia.
importante observar que estes ajustes devem aparecer
to somente na fase final de acabamento dos modelos
lgicos.
Denise F. Togneri

Derivao do Modelo Conceitual para o

Lgico

20

REGRAS DE DERIVAO PARA O MODELO RELACIONAL

Para derivar um Modelo Relacional, deve-se executar 3 atividades:

Normalizao das estruturas de dados;
Derivao de estruturas de agregao e generalizaoespecializao;
Derivao dos relacionamentos.

Denise F. Togneri

10

Derivao do Modelo Conceitual para o

Lgico

21

NORMALIZAO
A normalizao no um processo com finalidade restritiva, mas sim com
carter organizativo.

Os objetivos gerais do processo de normalizao so (Date, 2000):

Eliminar certas espcies de redundncias;
Evitar certas anomalias de atualizao;
Produzir um projeto que seja uma boa representao do mundo
real isto , que seja intuitivamente fcil de entender e uma boa
base para crescimento futuro;
Simplificar a imposio de certas restries de integridade.

Denise F. Togneri

Derivao do Modelo Conceitual para o

Lgico

22

NORMALIZAO
A normalizao pode ocorrer em 3 instantes distintos:
1. durante o processo de concepo do modelo
conceitual: possvel, mas no obrigatrio;
2. durante a derivao do modelo lgico: o momento
ideal, se nos preocuparmos antecipadamente estaremos,
possivelmente, introduzindo dificuldades adicionais no
processo de modelagem conceitual; se deixarmos para
depois, teremos um processo de ajuste das estruturas das
tabelas j concebidas que tambm levar a preocupaes
adicionais;
3. normalizao aps o processo de derivao do
modelo lgico: um processo corretivo.
Denise F. Togneri

11

Normalizao -

1a.,

2a.

3a.

23

Formas Normais

PRIMEIRA FORMA NORMAL (1FN)

Um modelo est na primeira forma normal se (Cougo, 1997):
1. Est integrado por tabelas: modelo relacional definido em forma de
tabelas contendo linhas e colunas unicamente.
2. As linhas das tabelas so unvocas: significa definir as chaves
primrias da tabela de forma a proibir a existncia de 2 linhas iguais.
3. As linhas no contm itens repetitivos: ou seja, evitar uso de
estruturas de dado do tipo vetor, uma vez que no padro SQL ANSI.
4. Os atributos so atmicos: ou seja, no se pode usar itens de grupo.
5. Os atributos no contm valores nulos: uma definio formal no
modelo relacional. No entanto, do ponto de vista prtico atual, no h
restrio quanto existncia de valores nulos em colunas de uma tabela
para que ela esteja na primeira forma normal (1FN).
Denise F. Togneri

24

Normalizao - 1a., 2a. e 3a. Formas Normais

PRIMEIRA FORMA NORMAL (1FN)

Processo para Obteno da Primeira Forma Normal

1. Definir as chaves candidatas e escolher a chave primria da
tabela.
2. Transformar atributos compostos em atmicos.
3. Em cada tabela, eliminar grupos repetitivos gerando novas
linhas, uma para cada ocorrncia de item repetitivo,
mantendo os valores dos demais itens.

Denise F. Togneri

12

Normalizao -

1a.,

2a.

3a.

25

Formas Normais

SEGUNDA FORMA NORMAL (2FN)

Uma tabela est na segunda forma normal se est na 1FN e

cada uma das colunas no pertencentes chave primria no
for dependente parcialmente dessa chave (Cougo, 1997).
Ao analisar uma tabela, deveremos excluir de nossa anlise as colunas
formadoras da chave primria dessa tabela. Alm disto, a dependncia
parcial de uma chave s ser possvel se a chave primria for definida
por mais de uma coluna. Caso tenhamos s uma coluna definindo a
chave primria, essa tabela j estar, automaticamente, na segunda
forma normal.
O que significa dependncia parcial da chave? Dizemos que uma
coluna depende parcialmente da chave se, para que seu valor seja
determinado no necessitarmos conhecer a chave como um todo, mas
sim somente um ou alguns de seus valores.
Denise F. Togneri

26

Normalizao - 1a., 2a. e 3a. Formas Normais

SEGUNDA FORMA NORMAL (2FN)
Processo para Obteno da Segunda Forma Normal
1. Identificar as colunas que no participam da chave primria
da tabela
2. Para cada uma das colunas identificadas, analisar se seu
valor determinado por parte, ou pela totalidade da chave.
3. Para as colunas dependentes parcialmente da chave, (a)
criar novas tabelas onde a chave primria ser(o) a(s)
coluna(s) da chave primria original que determinou(aram)
o valor da coluna analisada e (b) excluir da tabela original
as colunas dependentes parcialmente da chave.

Denise F. Togneri

13

Normalizao -

1a.,

2a.

3a.

27

Formas Normais

TERCEIRA FORMA NORMAL (3FN)

Uma tabela est na terceira forma normal se est na 2FN, e se

nenhuma coluna no pertencente chave fica determinada
transitivamente por esta.
Este enunciado deixa claro que nessa atividade s devero ser
analisadas as colunas no pertencentes chave primria, independente
dela ser composta ou no.
A dependncia transitiva de uma chave s ser possvel se a tabela tiver
ao menos duas colunas no pertencentes chave. Caso tenhamos
somente uma coluna externa chave, essa tabela j estar
automaticamente na terceira forma normal.
O que significa uma dependncia transitiva da chave? Dizemos
que uma coluna depende transitivamente da chave se seu valor
determinado pelo contedo de uma coluna no chave que, por sua vez,
tambm j determinada pela chave primria da tabela.
Denise F. Togneri

28

Normalizao - 1a., 2a. e 3a. Formas Normais

TERCEIRA FORMA NORMAL (3FN)
Processo para Obteno da Terceira Forma Normal
1. Identificar as colunas que no participam da chave primria
da tabela.
2. Para cada uma das colunas identificadas, analisar se seu
valor determinado por alguma outra coluna no
pertencente chave
3. Para as colunas dependentes transitivamente de outra
coluna, (a) criar novas tabelas onde a chave primria
ser(o) a(s) coluna(s) que determinou(aram) o valor da
coluna analisada e (b) excluir da tabela de origem as
colunas dependentes transitivamente, mantendo, porm, a
coluna determinante da transitividade na tabela.

Denise F. Togneri

14

Modelo de Processadores

29

Recordar Viver ....

A tcnica da Anlise Essencial

30

A anlise essencial considera dois nveis de abstrao

(Pompilho, 1995):

nvel essencial: representado pelo chamado modelo

essencial; construdo na fase de anlise e
especificao de requisitos;
nvel de implementao: representado pelo chamado
modelo de implementao; construdo na fase de
projeto do sistema.

Denise F. Togneri

15

A Tcnica da Anlise Essencial

O Modelo Essencial

31

Apresenta o sistema num grau de abstrao completamente

independente de restries tecnolgicas (Pompilho, 1995). composto
dos seguintes modelos: o modelo ambiental e o modelo
comportamental.
Modelo Ambiental: Representa a descrio do ambiente no qual o
sistema opera (Xavier, 1995). composto dos seguintes produtos:
Declarao dos objetivos do sistema, Lista de Eventos e Diagrama
de Contexto do Sistema
Modelo Comportamental: representa o que o interior do sistema
deve fazer para atender ao ambiente. Deve gerar os seguintes
produtos:
DER, DFDs Particionados por Eventos, DTEs, DFDs Organizados em
Nveis Hierrquicos, DD, Especificao da Lgica dos Processos (ou
Miniespecificao de processos)
Denise F. Togneri

A Tcnica da Anlise Essencial

O Modelo de Implementao

32

Apresenta o sistema num grau de abstrao completamente dependente

de restries tecnolgicas; reflete todas as consideraes relativas
tecnologia imperfeita.
A Anlise Essencial prope que as atividades necessrias para
construo do modelo de implementao so (Pompilho, 1995):
construir o modelo lgico de dados;
especificar a interface homem-mquina;
determinar as caractersticas de processamento para cada
funo ou processo:
pode ser processamento batch, online, real-time, em
processadores distintos ou no
deve-se determinar, para cada processo, no apenas o modo de
processamento, mas tambm qual processador ir execut-lo.
Denise F. Togneri

16

33

Modelo de Processadores

Ponto em questo
Quais dispositivos com capacidade de armazenamento /
processamento vo ser utilizados no sistema que est sendo
projetado ?
Este estudo particularmente til para implementao em
plataforma cliente/servidor.
Conceito de Processador: um processador um dispositivo
qualquer que responda a um evento, executando uma atividade ou
parte dela.
O primeiro passo no modelo de implementao , ento, alocar (ou
empacotar) o modelo essencial, atribuindo o trabalho do sistema a
processadores.
Para representar este empacotamento, utilizar o modelo de
processadores, que consiste em um Quadro de Alocao de
Processadores (QAP).
Denise F. Togneri

34

Algumas questes a serem analisadas

O que alocar no servidor PC, no servidor Unix, nas estaes cliente, na

estao SUN ?
A parte de maior confiabilidade (que requer maior segurana,
recuperao, proteo) deve ficar em um sistema operacional mais
poderoso (ex. Unix)
Como os processos acessam os depsitos de dados ? O processo vai
ser executado no mesmo processador que o depsito de dados ?
Ser necessrio que o mesmo depsito de dados esteja representado
em mquinas diferentes ?
Ex: A tabela de clientes de um software a ser implantado em uma
rede de lojas de produtos veterinrios (ex. em Vitria, Cachoeiro,
Linhares, ....) dever estar localizada fisicamente em um nico local,
de forma centralizada, ou sero vrias tabelas fsicas ?
Do ponto de vista de programas, faz sentido ter o mesmo programa em
vrios processadores?
Resposta: SIM. Um processo do DFD pode ser executado em vrios
processadores diferentes.

Denise F. Togneri

17

Quadro de Alocao em Processadores

(QAP)

35

QUADRO DE ALOCAO EM PROCESSADORES (QAP)

ATIVIDADES ESSENCIAIS

ARQUIVOS LGICOS

N do
Processo ou
Evento

Nome da
Atividade
Essencial

Processador

Nome do
Arquivo

Servidor

(n processo
no DFD)

(nome do
processo
no DFD)

(tipo processador:
PC-cliente, Unix,
VAX, SUN, etc. )

(nomes das
tabelas no modelo
relacional)

(local fsico do
arquivo)

Denise F. Togneri

Alocao (ou Empacotamento) em

Processadores

36

O Quadro de Alocao em Processadores (QAP) no

necessrio caso seja utilizado somente um processador.
Alocar as atividades (processos do DFD) e dados
(depsitos de dados) a processadores.
Levar em conta os ambientes de hardware e software
colocados como requisitos pelo usurio, que tem a palavra
final
fronteira de automatizao
restries relativas a freqncia de disparo das
atividades, volumes de dados, tempo de resposta,
restries tcnicas e ambientais, confiabilidade,
segurana, .... )
detalhes da interao homem-mquina

Denise F. Togneri

18

Alocao (ou Empacotamento) em

Processadores

37

Alocao de Processos
Questo a ser analisada: um processo n 1 em um determinado
nvel tambm representado de forma explodida em processos ns
1.1, 1.2, 1.3 ... no nvel subsequente

Na alocao de processos a processadores, deve-se pensar em

alocar o processo n 1 ou os processos 1.1, 1.2, 1.3 ... ?
Se houver paralelismo nos processos 1.1, 1.2, 1.3 ... aloc-los.
Se no houver e se os processos vo ser executados no mesmo
processador --> alocar o processo de nvel mais alto.
A alocao de processos deve ser feita no nvel dos processos que
correspondam a atividades essenciais.

Denise F. Togneri

Alocao (ou Empacotamento) em

Processadores

38

Alocao de Processos
Se uma atividade essencial necessitar ser distribuda por mais de
um processador, utilizar processos primitivos. Idem para dados.
Exemplo: Se o processo 1.1 for ser executado parte no cliente e
parte no servidor, em tempo de projeto deve-se explodi-lo em
mais um nvel do DFD.
possvel a repetio de atividades em mais de um processador.
Idem para dados.
Alocao de Dados
Levar em conta o volume de dados (tamanho de campos, nmero
de registros), carga inicial, taxa de crescimento, limpeza de bases
de dados;
Deve-se construir, ento, quadros estimativos de memria
secundria (QEMS).
Denise F. Togneri

19

Quadro de Estimativa de Memria

Secundria (QEMS)

39

QUADRO DE ESTIMATIVA DE MEMRIA SECUNDRIA (QEMS)

Processador/Servidor: __________________

Arquivo

Tamanho
Registro
(bytes)
(TR)

(2)

(3)

N inicial
registros
(NIR)

Tempo Estimado (TE):

(1)

Estimativa
de
Crescimento
(EC)

Tamanho
Arquivo
(Kbytes)
(TA)

%
arquivo
ndices
(PI)

Volume
estimado
final (VEF)

(4)

(5)

(6)

(7)

Estimativa de Memria no Processador (EMP)

(em Mbytes)

(8)
Denise F. Togneri

Transformao do DFD de Anlise em

DFD de Projeto

40

20

Transformao do DFD de Anlise em

DFD de Projeto

41

Bom momento para transformar o DFD de anlise em um

DFD de projeto, considerando o projeto de dados j
realizado e adicionando as atividades tecnolgicas.
Considerar os processos relativos segurana do sistema
(login, senha, controle de acesso, controle da poro do
sistema que se pode visualizar)
Avaliar necessidade de criao de vises para serem
acessadas por diferentes usurios.
Considerar todas as rotinas de backup, de totalizaes, de
fechamento.
Denise F. Togneri

Transformao do DFD de Anlise em

DFD de Projeto

As principais mudanas em relao ao DFD de anlise

dizem respeito principalmente a:

42

Interface (o que comunicado via interface)

Questes de gravao que dizem respeito ao agregado
(pode-se gravar s na tabela de agregado sem gravar
nas entidades associadas).

Portanto, em tempo de projeto fica mais natural fazer

primeiro o projeto de interface, a seguir o projeto de dados
e por ltimo o projeto procedimental.
Denise F. Togneri

21

Modelo de Tarefas

43

44

Modelo de Tarefas
CONCEITO DE TAREFA

Conjunto de atividades essenciais e tecnolgicas agrupadas em uma

unidade de execuo.
Ex: um arquivo executvel (.EXE) em um ambiente DOS seria uma
tarefa.
Em um ambiente multitarefa, uma tarefa pode ser disparada de
vrias estaes/terminais.

PADRO DE EMPACOTAMENTO DE TAREFAS

Agrupamento de atividades em uma nica tarefa por processador.

Denise F. Togneri

22

45

Modelo de Tarefas
QUANDO NO UTILIZAR O PADRO
1) Quando existir uma classe de usurios especfica, cujas
atividades autorizadas sejam de seu nico acesso e interesse.
Ex: usurios gerentes executam atividades diferentes dos usurios
comuns.
Quando a soluo para a questo acima for criar um nico
executvel que, dependendo do usurio, tem as funes
habilitadas/desabilitadas, est se criando uma nica tarefa porm com
as caractersticas do modelo de tarefas embutido.
Quando o processamento do sistema ocorre parte no cliente e parte
no servidor, so 2 tarefas.
2) Usurios dispersos geograficamente
alocao das atividades em diferentes computadores (tipicamente
com mesmo tipo de processador). Ex: a mesma tarefa em vrios PCs.

Denise F. Togneri

46

Modelo de Tarefas
QUANDO NO UTILIZAR O PADRO

3) Memria disponvel insuficiente para a tarefa.

Ex: funcionalidades menos usadas devem estar em separado das
mais usadas, sofrendo menos paginao.
4) Atividades que sero realizadas uma nica vez.
Ex: carga/converso dos dados do sistema.
As tarefas projetadas para estas atividades so chamadas
tarefas de pr-implantao.
No devem ser incorporadas tarefa.

Denise F. Togneri

23

Modelo de Tarefas: Estratgia para

Agrupamento das Atividades em Tarefas

47

Fazer um levantamento sobre o modo de utilizao do sistema

e o tempo de resposta esperado em cada atividade.
Exemplificando: verificar o que separar na tarefa para que fique com
bom tempo de resposta;
estudar o caso de atividades pesadas serem executadas em outro
processador ou horrio (ex. folha de pagamento deve rodar batch,
`a noite --> estas funes formam outras tarefas).
Cada step de uma rede diria batch uma tarefa.
Levar em considerao:
os estimuladores: classes de usurios autorizados a executar uma
atividade (ex. gerente, operador, ...)
o tamanho/nmero de atividades
segurana (controle sobre quem pode acessar tarefas A, B, ...)
facilidade de uso
Denise F. Togneri

Modelo de Tarefas
Atividades ou Processos Tecnolgicos

48

As atividades ou processos tecnolgicos so acrescentados a cada tarefa

de acordo com as necessidades do sistema, decorrentes das
imperfeies e limitaes da tecnologia.
Atividade tecnolgica um conjunto de aes executadas pelo sistema
em funo do estmulo decorrente de um evento tecnolgico.
Toda atividade tecnolgica projetada decorrente de um requisito
tecnolgico acrescido ao sistema, mas nem todo requisito tecnolgico
implicar uma atividade tecnolgica [Xavier95]. Exemplo:
gravao, no Log, de informaes para possibilitar recuperao de
operaes decorrentes de falhas --> no atividade tecnolgica pois
no possui evento associado a ela.
No faz sentido um evento: hora de gravar Log
Para gerao do log, as instrues de gravao j esto inseridas
nas atividades essenciais que atualizam o banco de dados.
Surge, ento, o conceito de procedimentos tecnolgicos.
Denise F. Togneri

24

Modelo de Tarefas
Procedimentos Tecnolgicos

49

So acrescentados especificao de um ou mais processos

(essenciais ou tecnolgicos) do sistema para considerar um requisito
tecnolgico.

Denise F. Togneri

Modelo de Tarefas
Exemplos de Atividades Tecnolgicas

50

Atendendo ao critrio de performance

Limpeza de arquivos
Histrico de arquivos
Reorganizao de arquivos
Reorganizao de ndices
Atendendo ao critrio de segurana
Incluso de usurio
Autenticao ou validao de usurios: controle de acesso
Auditorias: consultas sobre utilizao do sistema (que operaes
foram efetuadas, quem as efetuou e quando).

Denise F. Togneri

25

Modelo de Tarefas
Exemplos de Atividades Tecnolgicas

51

Atendendo ao critrio de confiabilidade

Backup (ser um novo processo no DFD se o DBA no fizer; idem
para os demais)
Restaurao de arquivos (restore): procedimento inverso ao do
backup.
Recuperao de arquivos (recovery)
Atendendo ao critrio de interatividade
customizao: por exemplo, para trocar cabealhos de relatrios,
mudar cor da tela, ativar ou no o som em caso de erro de
operao.
Help: incluir ajuda on-line
Atendendo ao critrio da economia
recepo de dados: tranferncia de dados entre processadores,
por exemplo.
Denise F. Togneri

Matrizes CRUD
(CREATE-READ-UPDATE-DELETE)

52

USURIOS x ATIVIDADE (OU PROCESSO)

PROCESSOS

USURIOS
Usurio 1

Processo 1

Usurio 2

Processo 2

Processo 3

Processo 4

.............

.
.
.
.
Denise F. Togneri

26

53

PROCESSO x TABELA
PROCESSOS

TABELAS
Tabela 1

Tabela 2

Tabela 3

Processo 1

CRUD

RU

Processo 2

CRU

Processo 3

Processo 4

.............

RU

.
.
.
.
Denise F. Togneri

Quadro de Alocao em Tarefas (QAT)

(Xavier, 1995)

54

QUADRO DE ALOCAO EM TAREFA (QAT)

Cdigo: (1)

Nome da Tarefa: (2)

Processador: (3)

N do Processo
ou Evento

Atividade(s)

Frequncia

(n processo
no DFD)

(nome do processo
no DFD)

(frequncia mdia de
utilizao da atividade
em relao ao tempo)
Ex: 3/dia, 2/ms, ...

Estimulador(es
)

(1) Cdigo da Tarefa: identificar a tarefa por um cdigo de quatro a seis caracteres
alfanumricos facilita mais tarde sua associao com o Diagrama de Estrutura Modular.
(2) Nome da Tarefa: deve sintetizar o propsito da tarefa, ou seja, as funes realizadas
por suas atividades.
(3) Tipo de Processador constante do QAP

Denise F. Togneri

27

Projeto Modular de Programas

55

Projeto Modular de Programas

Conceitos Bsicos

56

PROJETO MODULAR DE PROGRAMAS

uma coleo de orientaes, tcnicas, estratgias e heursticas
que geralmente levam a bons projetos de programas.
OBJETIVO PRINCIPAL
Desenvolver programas com menor complexidade, aumentando a
produtividade do programador
PRINCPIO
Fracionar para simplificar
RESULTADOS DE UM BOM PROJETO DE PROGRAMAS
Facilidade na leitura de programas (maior legibilidade)
Maior rapidez na depurao de programas nas fases de testes
Facilidade de modificao de programas na fase de manuteno
(maior alterabilidade)
IDIA BSICA
Estruturar os programas em termos de mdulos e conexes entre
estes mdulos
Denise F. Togneri

28

Projeto Modular de Programas

Conceitos Bsicos

57

MDULO
Conjunto de instrues que desempenham funes especficas
dentro de um programa. definido por: entrada/sada, funo,
lgica e dados internos.
CONEXO ENTRE MDULOS
Forma como os mdulos interagem entre si.

Denise F. Togneri

Projeto Modular de Programas

Conceitos Bsicos

58

ASPECTOS PRINCIPAIS PARA O PROJETO DE PROGRAMAS

Permite que a forma da soluo seja guiada pela forma do
problema.
Procura solucionar sistemas complexos atravs da segmentao
deste sistema em caixas pretas, e pela organizao destas
caixas pretas em uma hierarquia conveniente para uma
implementao computadorizada.
Utiliza ferramentas, especialmente as grficas, que tornam os
sistemas de fcil compreenso.
Oferece um conjunto de estratgias para desenvolver o projeto de
soluo a partir de uma declarao bem definida do problema.
Oferece um conjunto de critrios para avaliao da qualidade de
um determinado projeto-soluo com respeito ao problema ser
resolvido.
Denise F. Togneri

29

Projeto Modular de Programas

Objetivos

59

Segundo Falbo, os objetivos so:

Permitir a construo de programas mais simples

Obter mdulos independentes

Permitir testes por partes

Ter menos cdigo a analisar em uma manuteno

Servir de guia para a programao estruturada

Construir mdulos com uma nica funo

Permitir reutilizao
Segundo Xavier, os objetivos so:

Preciso: medida da aderncia de um mdulo a sua especificao

Solidez: capacidade de um mdulo de manipular corretamente

situaes inesperadas

Extensibilidade: nova funcionalidade pode ser adicionada sem

necessidade de se refazer o servio

facilidade de adaptao

possibilidade de reutilizao
Denise F. Togneri

Projeto Modular de Programas

Princpios da Modularizao

60

Os princpios da modularizao descrevem o que se deve fazer para atingir

os objetivos propostos, ou seja, descrevem as limitaes necessrias
que devem ser atendidas para se atingir os objetivos. So eles:

Ocultamento de Informaes: o funcionamento interno de um

mdulo deve estar oculto aos outros mdulos. Tambm chamado de a
arte de criao de caixas-pretas.
Pequenas interfaces: a interface de um mdulo deve precisar
somente das informaes necessrias para que o mdulo complete a
tarefa.
Interfaces Explcitas: as interfaces devem ser feitas de modo que
todas as informaes pertinentes sejam claramente especificadas no
cdigo-fonte. Valores de variveis necessrias ou alteradas devem ser
passadas como parmetro em uma funo.
Clareza: um mdulo deve ser dedicado a uma finalidade bem definida
Denise F. Togneri

30

Projeto Modular de Programas

Princpios da Modularizao

61

Os sistemas mais fceis de alterar so aqueles construdos

com mdulos pequenos, fceis de entender, que
implementam funes bem definidas e que funcionam da
maneira mais independente possvel uns dos outros, para
que possam ser removidos, alterados e recolocados, sem
afetar o bom funcionamento do resto do sistema (Xavier,
1995).

Denise F. Togneri

Projeto Modular de Programas

Simplificando um Sistema

62

O Projeto Modular procura simplificar um sistema complexo,

particionando-o e organizando-o hierarquicamente.
O sistema subdividido em caixas-pretas que so organizadas em
uma hierarquia conveniente.
Caixa-preta: no se conhece como ela trabalha, mas apenas como
utiliz-la.
CARACTERSTICAS DE UMA CAIXA-PRETA
sabemos como devem ser os elementos de entrada, isto , as
informaes necessrias para seu processamento;
sabemos como devem ser os elementos de sada, isto , os
resultados oriundos do seu processamento;
conhecemos a sua funo, isto , que processamento ela faz sobre
os dados de entrada para que sejam produzidos os resultados
no precisamos conhecer como ela realiza as operaes, nem to
pouco seus procedimentos internos, para podermos utiliz-la.

Denise F. Togneri

31

Projeto Modular de Programas

Simplificando um Sistema

63

METAS A SEREM ATINGIDAS

cada caixa-preta deve resolver uma parte bem definida do
problema
a funo de cada caixa-preta deve ser facilmente compreendida
conexes entre caixas-pretas devem refletir apenas conexes
entre partes do problema;
as conexes devem ser to simples e independentes quanto
possveis

Denise F. Togneri

Projeto Modular de Programas

Hierarquia de Caixas-pretas

64

PRESIDENTE

A
X

C
P

Y
Z

Figura 1 - Organograma da empresa 1

O vice-presidente A, os gerentes X e Y possuem tarefas triviais, pois tem

como responsabilidade gerenciar apenas um subordinado. Todo o
servio realizado pelo funcionrio Z. O vice-presidente B no tem
atribuies.
Denise F. Togneri

32

Projeto Modular de Programas

Hierarquia de Caixas-pretas

65

PRESIDENTE

FUNC1

FUNC2

FUNC3

FUNC90

.........

Figura 2 - Organograma da empresa 2

O presidente est sobrecarregado.

Denise F. Togneri

Projeto Modular de Programas

Hierarquia de Caixas-pretas

66

PRESIDENTE

A1

A2

B1

B2

C1

C2

Figura 3 - Organograma da empresa 3

O organograma da empresa 3 parece mais equilibrado.Cada gerente

gerencia um nmero apropriado de subordinados.
As estruturas de um programa, ou de um sistema, podem ser
discutidas de maneira anloga questo dos organogramas.
Os mdulos (caixas-pretas) devem ser dispostos em uma
hierarquia de modo a, por um lado, no provocar sobrecarga de
processamento e, de outro, no criar mdulos apenas
intermedirios, sem desempenhar nenhuma funo.
Denise F. Togneri

33

67

Projeto Modular de Programas

H vrios tipos de diagramas hierrquicos para o projeto de

programas (Martin et al., 1991).
Sero explorados dois deles:
o Diagrama Hierrquico de Funes (DHF), usado
principalmente para o projeto arquitetural do sistema;
o Diagrama de Estrutura Modular (DEM), usado para
o projeto detalhado de mdulos.

Diferena bsica entre eles:

o DHF no representa o fluxo de dados e controles entre
mdulos, nem aspectos relacionados com detalhes lgicos
de um mdulo, tais como estruturas de repetio (laos)
e condio.
Estas informaes so capturadas em um DEM.

Denise F. Togneri

Diagrama Hierrquico de Funes (DHF)

68

define a arquitetura global de um programa ou sistema, mostrando

mdulos e suas inter-relaes (Martin et al., 1991).
Cada mdulo pode representar um subsistema, programa ou mdulo
de programa.
Sua finalidade mostrar os componentes funcionais gerais
(arquitetura do sistema) e fazer referncia a diagramas detalhados
(tipicamente Diagramas de Estrutura Modular).
Um DHF no mostra o fluxo de dados entre componentes funcionais
ou qualquer informao de estruturas de controle, tais como laos
(loops) ou condies.

Denise F. Togneri

34

Diagrama Hierrquico de Funes (DHF)

69

A estrutura de um DHF tem como ponto de partida um

mdulo inicial, localizado no topo da hierarquia, que
detm o controle sobre os demais mdulos do diagrama,
ditos seus mdulos-filhos.
Um mdulo-filho, por sua vez, pode ser pai de outros
mdulos, indicando que ele detm o controle sobre esses
mdulos.

Denise F. Togneri

Diagrama Hierrquico de Funes (DHF)

70

A construo de um DHF pode ser bastante facilitada se existir um

diagrama de casos de uso do sistema. De fato, consideraes
anlogas s feitas no projeto da Componente de Gerncia de Tarefas
podem ser aplicadas no projeto arquitetural usando DHFs.
Cada executvel deve dar origem a um DHF. Os casos de uso
controlados por esse executvel devem ser mdulos-filhos do
mdulo inicial do diagrama.
Cenrios de um caso de uso (ou casos de uso de nvel mnimo) podem
ser representados como mdulos-filhos do mdulo correspondente.
Para sistemas de mdio a grande porte, contudo, representar todos os
casos de uso e seus cenrios em um nico diagrama pode torn-lo
muito complexo. Assim, novos DHFs poderiam ser elaborados para
cada caso de uso, ou para alguns casos de uso.
Denise F. Togneri

35

Diagrama Hierrquico de Funes (DHF)

Exemplo

71

Diagrama de Casos de Uso de um Sistema de Entrega de Refeies Domiclio

Denise F. Togneri

Diagrama Hierrquico de Funes (DHF)

Exemplo

72

Com base no Diagrama de Casos de Uso, pode-se construir o DHF

mostrado a seguir.
Nesse diagrama, optou-se por no representar os cenrios do caso de
uso Controlar Pedido, uma vez que este um caso de uso bastante
complexo, com vrios cenrios, o que traria uma complexidade
indesejada para o DHF.
Assim, alm do diagrama apresentado a seguir, um outro, cujo
mdulo inicial seria Controlar Pedido, deveria ser elaborado.
Vale ressaltar que um DHF pode ser usado como um guia para o
projeto das interfaces com o usurio, apoiando a definio de janelas,
estruturas de menu, etc.
Denise F. Togneri

36

Diagrama Hierrquico de Funes (DHF)

73

Um Diagrama Hierrquico de
Funes para o Sistema de
Entrega de Refeies

Denise F. Togneri

Diagrama de Estrutura Modular (DEM)

ou Mapa Estruturado ou Diagrama de
Estrutura (DE)

Um DEM mostra:
o particionamento de um sistema em mdulos (caixas-pretas);
a hierarquia e organizao dos mdulos;
as interfaces de comunicao entre mdulos (entrada/sada);
as funes dos mdulos, dadas por seus nomes.
Um DEM NO mostra:
a lgica e
os dados internos dos mdulos.
Portanto, o DEM deve ser acompanhado de uma descrio dos mdulos,
mostrando os detalhes internos dos procedimentos das caixas-pretas.
Pode-se utilizar como ferramenta: Portugus Estruturado, Pseudocdigo,
Tabelas de Deciso e rvores de Deciso, entre outras.

Denise F. Togneri

37

75

DEM - Simbologia e Convenes

Um mdulo definido como uma coleo de instrues de programa

com quatro atributos bsicos:
entrada e sada: so, respectivamente, as informaes que um
mdulo necessita e fornece;
funo: o que o mdulo faz para produzir, a partir da entrada, a
sada;
lgica: a descrio dos algoritmos que executam a funo;
dados internos: so aqueles referenciados apenas dentro do mdulo.
Entradas, sadas e funo fornecem a viso externa do mdulo e ,
portanto, apenas estes aspectos so representados no DEM.
Lgica e dados internos representam a viso interna do mdulo e so
descritos com as tcnicas de especificao de programas j citadas
acima.
Denise F. Togneri

76

DEM - Representaes Grficas de Mdulos

MDULO
Nome do Mdulo
(Verbo + Objeto + {Qualificador})

MDULO PR-DEFINIDO
- no tem que ser descrito; j existe em uma biblioteca
de mdulos.

Denise F. Togneri

38

77

DEM - Representaes Grficas de Mdulos

CONEXES ENTRE MDULOS
A

X, Y
(parmetros)

Mdulo
Chamador
Z
Mdulo
Chamado

O mdulo A chama o mdulo B passando como parmetros X e Y. O

mdulo B executa sua funo e retorna o controle a A, no ponto
imediatamente aps a chamada de B, passando o resultado Z.
Denise F. Togneri

78

DEM - Representaes Grficas de Mdulos

COMUNICAO ENTRE MDULOS

Dados

Controles (flags)

As informaes passadas entre mdulos podem ser dados

ou controles. Os controles normalmente so variveis do
tipo boleano.
Denise F. Togneri

39

79

DEM - Representaes Grficas de Mdulos

COMUNICAO ENTRE MDULOS - EXEMPLO
Obter detalhes
cliente
Nmero

Nome
Cd_retorno

Pesquisar nome
cliente

Denise F. Togneri

80

DEM - Representaes Grficas de Mdulos

CHAMADAS CONDICIONAIS

A
A pode ou no
chamar B

A pode chamar
B ou C
B

Em muitos casos, um mdulo s ser ativado se uma condio

for satisfeita. Nestes casos, temos chamadas condicionais.
Denise F. Togneri

40

81

DEM - Representaes Grficas de Mdulos

CHAMADAS CONDICIONAIS - EXEMPLO
Cadastrar
Cliente

Incluir
Cliente

Alterar
Cliente

Excluir
Cliente

Consultar
Cliente

Esta hierarquia baseada no menu do sistema.

Denise F. Togneri

82

DEM - Representaes Grficas de Mdulos

CHAMADAS ITERATIVAS OU REPETIDAS
A
at condio

Os mdulos B e C so chamados repetidas vezes pelo

mdulo A, at que a condio seja verdadeira.

Denise F. Togneri

41

83

DEM - Representaes Grficas de Mdulos

CONECTORES
A

Alguns mdulos so
chamados por mais de um
mdulo. Nesta situao
no devemos desenhar
duas vezes um mesmo
mdulo, mas sim utilizar
conectores.

Denise F. Togneri

84

DEM - Tcnicas de Desenho

Os mdulos devem ser desenhados na ordem de execuo, da

esquerda para a direita.
Cada mdulo s deve aparecer um nica vez no diagrama.
Para se evitar cruzamento de linhas, deve-se usar conectores.
No segmentar demais.
DICA: Ao lado de cada mdulo, pode-se colocar um cdigo para
representar se ele uma window (W), um item de menu (M), uma
funo (F) .....

Denise F. Togneri

42

Seqncia de
Chamada/navegao de um DEM

85

Mdulo A

Mdulo B

Mdulo C

Mdulo E

Mdulo D

Mdulo F

Trace da Navegao: A B A C E C F C A D A

Denise F. Togneri

86

Estrutura Geral de um DEM

Mdulo
Principal
Ent. Vlida

Obter
Entrada
Ent.

Ler
Entrada

Ent.

Sada

Transformar
Dados
Ok/NOk

Validar
Entrada

Sada
Formatar
Sada

Gerar
Sada
Sada
Format.

Sada
Formatada

Emitir
Sada

Denise F. Togneri

43

Projeto Modular Efetivo

(Critrios de Qualidade de Projetos)

87

O principal objetivo do projeto modular de programas permitir que

um sistema complexo seja particionado em mdulos simples.
vital que a partio seja feita de tal forma que os mdulos sejam
to independentes quanto possvel e que cada um deles
execute uma nica funo. A independncia medida usando,
ento, 2 critrios de qualidade que so, respectivamente,
acoplamento e coeso.
A independncia funcional a chave para um bom projeto e o
projeto a chave para a qualidade do software.

Denise F. Togneri

88

Acoplamento

uma medida da interconexo entre mdulos dentro de um estrutura

de programa (PRESSMAN, 2002).
Diz respeito ao grau de interdependncia entre dois mdulos. Quanto
maior a interdependncia, maior o acoplamento.
a possibilidade que a modificao de um mdulo provoque
alteraes em outro mdulo.
Objetivo: minimizar o acoplamento (baixo grau de acoplamento bem particionado), isto , tornar os mdulos to independentes
quanto possvel.
Como obter um baixo acoplamento:
eliminando relaes desnecessrias
enfraquecendo a dependncia das relaes necessrias
Denise F. Togneri

44

89

Acoplamento

Razes para minimizar o acoplamento:

quanto menos conexes houver entre dois mdulos, menor ser

a chance de um problema ocorrido em um deles se refletir em
outros.
Uma alterao do usurio deve afetar o menor nmero de
mdulos possvel, isto , uma alterao em um mdulo no deve
implicar em alteraes em outros mdulos.
Ao dar manuteno em um mdulo, no devemos nos preocupar
com detalhes de codificao de outros mdulos.

Denise F. Togneri

90

Acoplamento

Aspectos principais do acoplamento:

Tipo de conexo: forma como uma conexo estabelecida; a

comunicao deve ser atravs de chamadas a subrotinas, cada
uma delas fazendo uso somente de variveis locais.
Tamanho da conexo: quando menor o nmero de
informaes trafegando de um mdulo a outro, menor ser o
acoplamento.
O que comunicado entre os mdulos: ideal ter
acoplamento apenas de dados (e no de controles). Se
necessrio, fazer sem mscaras .
Denise F. Togneri

45

91

Acoplamento
Principal
Registro
Flag-EOF

Ler Registro

Se o mdulo de leitura detectar que o arquivo acabou no

indicado mover brancos para o Registro para indicar tal fato e
sim setar o controle Flag-EOF com valor apropriado.
A movimentao de brancos para o Registro considerada
uma mscara do controle.
Denise F. Togneri

Acoplamento - Observaes Importantes

92

O mdulo chamador no deve nunca enviar um controle ao mdulo

chamado. Isto significa que o mdulo chamador est dizendo o que o
mdulo chamado deve fazer (qual parte do cdigo executar),
caracterizando portanto, que o mdulo chamado no uni-funcional.
S utilizar controles de baixo para cima. O mdulo chamado avisa que
no conseguiu executar sua funo, mas no deve dizer ao chamador o
que fazer.
Evitar o uso de dados globais. Sempre que possvel, utilizar variveis
locais. Varivel global mascara o acoplamento.
inadimissvel que um mdulo se refira a uma parte interna de outro
(acoplamento de contedo)
Denise F. Togneri

46

93

Acoplamento
O acoplamento pode ser representado sobre um espectro, como
mostrado abaixo:

Denise F. Togneri

94

Acoplamento - Concluses

Para minimizar o acoplamento deve-se:

Passar o menor nmero possvel de parmetros e de preferncia

apenas dados. Quando for necessrio passar controles, faz-lo
apenas de baixo para cima.
Ter pontos nicos de entrada e sada de um mdulo.
Exemplo: um programa Fortran pode ter vrios pontos de
entrada (pois possvel executar pores de cdigo).
Sempre que possvel, utilizar programas compilados
separadamente.
Exemplo: Gerar executveis por perfil do usurio.

Denise F. Togneri

47

95

Coeso

Define como as atividades de um mdulo esto relacionadas umas

com as outras.
a fora que mantm unidos os elementos de um mdulo.
Objetivo: ter alta coeso, isto , seus elementos internos devem
estar fortemente relacionados uns com os outros.
Vale a pena ressaltar que coeso e acoplamento so
interdependentes e, portanto, uma boa coeso deve levar a um
pequeno acoplamento.

Denise F. Togneri

96

Coeso
Baixa Coeso

Baixa Coeso

Fbrica
Pepsi

CST
Alto
Acoplamento

Vila Velha

Conjunto Habitacional
CST

Serra
Trfego
Intenso

Fbrica
Fbrica
Garrafas
Garrafas

Denise F. Togneri

48

Coeso
Alta Coeso

Alta Coeso

Fbrica
Pepsi

CST
Baixo
Acoplamento

Vila Velha

Fbrica
Garrafas

Serra
Pouco
Trfego

Conjunto
Fbrica
Garrafas
Habitacional CST

O grau de coeso de um mdulo tem um impacto direto na qualidade do

software produzido, sobretudo no que tange alterabilidade,
manutenibilidade, legibilidade e capacidade de reutilizao.
O ideal que tenhamos apenas coeso funcional, isto , que todos os
elementos de um mdulo estejam contribuindo para a execuo de uma
e somente uma funo do sistema.
Denise F. Togneri

Coeso

98

A coeso pode ser representada sobre um espectro, como

mostrado abaixo:

Denise F. Togneri

49

Heursticas de Projeto para uma

Modularidade Efetiva

99

Nmero de mdulo subordinados imediatos (fan-out): um nmero

baixo ou alto indica um projeto pobre. Razovel: at 9.
Alto: difcil de reutilizar.
Baixo: complexo

Denise F. Togneri

Heursticas de Projeto para uma

Modularidade Efetiva

Nmero de mdulo superiores imediatos (fan-in): quanto mais,

melhor, evitando duplicao de cdigo. Indica reutilizao.

Denise F. Togneri

50

101

Referncias

COUGO, Paulo. Modelagem Conceitual e Projeto de Bancos de Dados. Rio

de Janeiro: Campus, 1997.
DATE, C. J. Introduo a sistemas de bancos de dados: traduo da 7a.
edio americana. Rio de Janeiro: Campus, 2000.
FALBO, Ricardo de A. Notas de aula da disciplina Projeto de Sistemas Curso de graduao em Cincia da Computao. UFES, 1999.
POMPILHO, S. Anlise Essencial. Rio de Janeiro: Infobook, 1995.
PRESSMAN, Roger S. Engenharia de Software. 5.ed. Rio de Janeiro: McGrawHill, 2002. Cap. 13.
XAVIER, Carlos M. da S., PORTILHO, Carla. Projetando com qualidade a
tecnologia em sistemas de informao. Rio de Janeiro: LTC, 1995.
Denise F. Togneri

51