Você está na página 1de 60

CURSO DE TECNLOGO EM PROCESSAMENTO

DE DADOS

Prof. Srgio Luiz Tonsig

2000

Anlise e Projeto de Sistemas II

FACULDADE DE TECNOLOGIA DA ALTA


NOROESTE
Curso de Tecnlogo em Processamento de Dados

Disciplina: Anlise e Projeto de Sistemas II

Prof.: Srgio Luiz Tonsig*

Ementa:
Desenvolver a especificao de sistemas, atravs de estudos de casos,
propiciar uma viso geral sobre as etapas que devem ser seguidas para o
efetivo desenvolvimento de um projeto e seus aspectos gerenciais.

Docente da Faculdade de Tecnologia da Alta Noroeste. Especialista em Sistemas de


Informao pela Universidade Federal de So Carlos. Mestrando em Gerncia de Sistemas
de Informao de PUC Campinas.

Prof. Srgio Luiz Tonsig

Pgina: 2

Anlise e Projeto de Sistemas II

Sumrio
1. Caminho do desenvolvimento.....................................................................
1.1. A Anlise Essencial..............................................................................
1.1.1. Modelo Ambiental.....................................................................
1.1.2. Modelo Comportamental...........................................................
1.1.3. Um estudo de caso.....................................................................
1.1.3.1. Declarao de Objetivos do Sistema..........................
1.1.3.2. Diagrama de Contexto................................................
1.1.3.3. Lista de Eventos..........................................................
1.1.3.4. DFD Particionado por Evento.....................................
1.1.3.5. A Especificao dos Processos....................................
1.1.3.6. Modelagem de Dados..................................................
1.1.3.7. Diagrama Hierrquico de Macro Atividades...............
1.1.3.8. Dicionrio de Dados....................................................
1.1.3.9. CASE...........................................................................

04
04
05
06
08
10
10
11
12
13
25
27
28
30

2. Projeto (Design)............................................................................................
2.1. Critrio de qualidade de projeto............................................................
2.2. Modelo de Alocao de Processadores..................................................
2.3. Consideraes sobre segurana e controle de sistemas.........................
2.4. Diagrama Hierrquico do Sistema.........................................................
2.5. Lay-Out de Telas/Relatrios..................................................................

31
33
33
36
38
39

3. Gerncia de Projeto.......................................................................................
3.1. Problemas em Planejamento de Sistemas..............................................
3.1.1. Relacionado com a rpida evoluo tecnolgica........................
3.1.2. Relacionado com pessoas...........................................................
3.1.3. Outros problemas gerenciais.......................................................
3.1.4. Dificuldade de aferir progresso...................................................
3.1.5. A crise do software......................................................................

41
41
41
42
42
43
43

4. Processo de gerncia de projeto....................................................................


4.1. Definio de objetivos............................................................................
4.2. Planejamento..........................................................................................
4.3. Organizao / Coordenao....................................................................
4.4. Avaliao do Progresso..........................................................................
4.5. Reviso e Registro Histrico..................................................................

45
46
47
53
55
58

5. Bibliografia....................................................................................................

59

Prof. Srgio Luiz Tonsig

Pgina: 3

Anlise e Projeto de Sistemas II

1. O Caminho do Desenvolvimento de Sistemas


Antes de se enfatizar qualquer aspecto relativo a Projeto de Sistema, especialmente em
nossa etapa atual de formao profissional, fundamental resgatar, atravs de uma
sntese (visto que foi objeto de estudo do semestre anterior), o caminho que um Analista
de Sistemas dever seguir, ao utilizar o mtodo da anlise essencial.

1.1. A Anlise Essencial


Declarao
Dos Objetivos

Modelo
Ambiental

Diagrama
De Contexto

Lista de
Eventos
Anlise
Essencial
DFD Particion
por Eventos

Modelo
Comportamental

Diagr. Entidade
Relacionamento

Normalizao

D
i
c
i
o
n
a
r
i
o
D
e
d
a
d
o
s

A premissa bsica para o mtodo de anlise essencial descrever o sistema de maneira


independente de restries tecnolgicas.
Isto implica dizer que devemos considerar na confeco do modelo essencial a existncia
de uma tecnologia perfeita.
Devemos entender este aspecto como uma abstrao em que se supe uma tecnologia
ideal, sem limitaes, onde:

Prof. Srgio Luiz Tonsig

Pgina: 4

Anlise e Projeto de Sistemas II


a)
b)
c)
d)
e)

Os custos, consumo e desgaste dos equipamentos so zero


A capacidade de armazenamento de dados do sistema infinita
A velocidade dos processadores infinita
O tempo de acesso a dados instantneo
Zero Erro (no ocorrem falhas)

Atravs deste mtodo faz-se um exame do domnio do problema (levantamento de dados


acerca do sistema que ser feito) inicialmente enfocando os aspectos mais essenciais
pertinentes ao problema. A anlise essencial, constituda basicamente por duas fases ou
modelos: Ambiental e o Comportamental.
Modelo Ambiental
No modelo ambiental tem-se a especificao macro do sistema (como se fosse uma caixa
preta) inserido em um meio ambiente, busca-se representar a relao do sistema com o
meio onde ele est, atravs de estmulos provenientes do meio e respostas a estes
estmulos, que podero ser internas ao sistema ou ainda serem devolvidas para o meio
ambiente. Trs grandes atividades so elaboradas neste modelo: Declarao dos
Objetivos do Sistema, a elaborao do Diagrama de Contexto e a especificao da lista de
eventos.
Declarao de Objetivos
Trata-se da especificao daquilo que o sistema dever fazer, frente aos problemas
existentes na organizao para o qual ele ser feito. Deve tambm, tanto quanto possvel,
refletir os desejos do usurio no que diz respeito as solicitaes que ele tenha apresentado
como alternativas de soluo dos problemas.
Naturalmente antes da elaborao dos objetivos do sistema, o Analista dever ter
efetuado um minucioso levantamento de dados (checando inclusive requisitos do
sistema), conhecendo profundamente o chamado domnio do problema. Se o sistema for
referente a controle de uma biblioteca, o Analista precisa saber tudo sobre bibliotecas,
regras gerais, linguagem utilizada, detalhes e excees.
Diagrama de Contexto
Aps a especificao formal dos objetivos do sistema, o Analista j estar em condies
mais apropriadas para elaborar o diagrama de contexto. Ele reflete graficamente a relao
do sistema com o meio ambiente onde est inserido. Esta relao d-se atravs do
recebimento de estmulos do meio ambiente, os quais ativam processos, e estes, por sua
vez geram respostas, que podem vir a ser respostas externas ao sistema, ou seja, resposta
ao meio ambiente.

Prof. Srgio Luiz Tonsig

Pgina: 5

Anlise e Projeto de Sistemas II


Lista de Eventos
Trata-se da especificao das atividades (processos) essenciais que o sistema ter . Elas
so ativadas por estmulos (fluxo de dados, fluxo temporal ou de controle), fazem algum
processamento e geram respostas. No h uma precedncia estabelecida para a
elaborao da lista de eventos e o diagrama de contexto, so atividade que podem estar
acontecendo paralelamente inclusive.
Modelo Comportamental
O modelo comportamental a fase em que o Analista passa a olhar para dentro do
sistema. Ir detalhar como cada atividade existente na lista de eventos se comporta (como
ela deve funcionar). Tambm far um modelo de dados sobre o qual o sistema atuar,
observando critrios para conseguir boa performance na sua utilizao (atravs da
normalizao de dados). Acompanhando mais efetivamente este modelo (muito embora
j possa existir antes dele) cria-se o dicionrio de dados. Tambm nesta fase elabora-se o
D.F.D. Hierrquico, que nada mais do que o agrupamento de atividades essenciais afins
(sncronas), que enfocam determinado aspecto no sistema.
Diagrama de Fluxo de Dados Particionado por Evento
Para cada item da lista de eventos o Analista de Sistemas far um Diagrama de Fluxo de
Dados, representando de forma grfica, individualmente, cada evento existente no
sistema. Desta forma, haver tantos diagramas de fluxo de dados particionado por
eventos, quantos forem os itens existentes na lista de eventos.

Prof. Srgio Luiz Tonsig

Pgina: 6

Anlise e Projeto de Sistemas II

Diagrama Entidade Relacionamento


Para modelagem de dados, o Analista de Sistemas far inicialmente o D.E.R.
Com este diagrama ter um poderoso instrumento para mapear como os dados esto
organizados e como eles se relacionam. Em cima deste modelo, pode ser aplicado a teoria
da Normalizao, que permitir extrair melhor performance quando da utilizao da
estrutura dos dados.
Diagrama Hierrquico de Macro Atividades
Trata-se de um D.F.D. onde se propiciar uma viso de Macro Atividades. Pega-se os
diagramas de fluxo de dados particionados por eventos e verifica-se quais so aquelas
atividades afins (sncronas que tratam determinado assunto). Estes processos so
aglutinados em um nico, de tal forma que se obter uma viso mais sinttica da
representao do sistema, cuja finalidade , alm da documentacional a possibilidade de
examinar e definir interfaces e locais de processamento. A fim de facilitar a construo
do DFD Hierrquico (atravs de uma viso mais global do sistema), pode-se antes
elaborar o chamado Diagrama Preliminar, que consiste em pegar todos os DFDs
particionados por evento e torn-lo um s (viso nica de um DFD com todos os
processos existentes).
Dicionrio de Dados
Todos os dados referenciados na construo do sistema, deve ter sua definio no
dicionrio de dados.
Para a construo do dicionrio existem alguns padres, dos quais, vamos adotar o segue:
Smbolo

Significado

=
+
( )
{ }
[ ]
* *
@
| ou /

composto de
E
Opcional (pode estar presente ou ausente)
Iterao (Repetio)
Escolha uma das opes
Comentrio
Indica campo chave
Separa Alternativas na construo [ ]

Prof. Srgio Luiz Tonsig

Pgina: 7

Anlise e Projeto de Sistemas II

1.1.3. Um Estudo de Caso


Domnio do Problema
A primeira grande misso do Analista de Sistema, ao ser chamado a desenvolver um
sistema, o de delimitar a rea fronteiria deste sistema a ser desenvolvido. Exatamente o
que se deseja e at onde dever ser feito tal coisa. Para iniciar este processo de
identificao uma boa dica comear pela pergunta fundamental: Por que tal sistema
deveria existir ? naturalmente quem contratou seu servio est apto a responder este
questionamento com uma riqueza de detalhes muito grande.
Em nosso estudo de caso, tem-se um sistema hoteleiro. Nesta fase de exame do domnio
do problema, estabeleceu-se que o objetivo apenas o controle da disponibilidade de
quartos do hotel (no envolve qualquer outro aspecto, tais como: controle financeiro,
contbil, etc...).
Uma vez claramente estabelecido o domnio do problema depois de um intenso
levantamento de dados (que comeou pela pergunta acima: por que este sistema deveria
existir ?), o Analista de Sistema deve se concentrar unicamente no domnio do problema,
eventuais interfaces e nos requisitos necessrios ao desenvolvimento do sistema,
passando para a etapa seguinte.
Rigoroso Levantamento de Dados
Aps um rigoroso levantamento de dados, que pode envolver, exame e cpia de
documentos originais, acompanhamento do fluxo de trabalho, entrevistas com usurios e
at mesmo estgio no local objeto do levantamento de dados. O Analista de Sistemas
deve sair desta fase conhecendo todos os detalhes do negcio, suas regras, excees,
linguagem empregada e eventuais particularidades da organizao sobre o negcio.

Se o Analista ignorar esta fase ou desenvolve-la superficialmente, assumindo que j


possui conhecimentos suficientes sobre o assunto, provavelmente, estabelecer requisitos
confusos ou invlidos, fracassando j no incio de seu sistema.

Prof. Srgio Luiz Tonsig

Pgina: 8

Anlise e Projeto de Sistemas II

Em nosso estudo de caso, aps estes procedimentos iniciais, chegou-se a um


conhecimento acerca do que deveria ser feito. As informaes colhidas encontram-se no
enunciado que segue:
Estudo de Caso - Sistema Hoteleiro - Controle de Disponibilidades de Quartos
Deseja-se desenvolver um sistema para um pequeno hotel que atenda aos seguintes
requisitos:
-

Quando o cliente telefona ou vem at o hotel e pede para reservar um quarto, o


funcionrio verifica se existe quarto disponvel no perodo solicitado. Caso
afirmativo, feita a reserva do quarto. Caso negativo, informado ao cliente a no
disponibilidade do quarto.

Quando o cliente no mais desejar o quarto reservado o funcionrio providencia o


cancelamento da reserva, disponibilizando novamente o quarto.

Quando o cliente no comparecer ao hotel para hospedar-se at s 12:00 horas do dia


da reserva, deve ser cancelado a sua reserva.

Quando o cliente ocupar um quarto, reservado previamente, o funcionrio faz o


registro do cliente. Caso o quarto no esteja reservado uma mensagem de rejeio
ser emitida. Caso contrrio, um pacote com informaes teis e a confirmao sero
fornecidos ao cliente.

Quando o cliente deixar o hotel, notificando sua sada, ser fornecido a conta, e o
quarto ser disponibilizado para limpeza.

O cliente pode pagar a conta vista, ou usando carto de crdito. Caso use carto de
crdito, verificado sua situao para aceitar ou no o carto.

Quando o quarto estiver limpo, aps uma ocupao, o gerente torna-o disponvel para
nova locao.

De posse destas informaes, em nosso estudo de caso, segue um descritivo da anlise do


problema e a descrio da soluo escolhida pelo Analista de Sistemas, diante, claro,
alm das informaes, os desejos manifestados pelo usurio (e possveis de serem
desenvolvidos).

Prof. Srgio Luiz Tonsig

Pgina: 9

Anlise e Projeto de Sistemas II


Descritivo da Soluo Escolhida
Depois de estudar o volume de dados processado pelo sistema atual e considerando o
tempo de resposta requerido, chego a concluso que o sistema novo precisar de quatro
pessoas e um pequeno computador comercial.
Dever ser atribudo tanto trabalho quanto for possvel ao computador de modo a poder
minimizar os custos de processamento. Porm, no ser correr o risco de perder clientes
por fora-lo a um contato direto com o computador (considerando a situao atual da
interface homem/mquina); consequentemente, optou-se por alocar tudo ao computador,
exceto as partes das atividades essenciais que envolvem um contato direto com os
clientes do hotel.
Uma atividade essencial, Cancelar no comparecimento, no requer nenhum contato
direto com o cliente e, portanto, pode ser desempenhado diretamente pelo computador.
O que vem a seguir a especificao tcnica do projeto do sistema, comeando
inicialmente pelo modelo ambiental.
1.1.3.1. Declarao do Objetivo do Sistema
Controlar o servio de reservas, registros e cobrana de quartos de um sistema
hoteleiro.
1.1.3.2. Diagrama de Contexto
Cli_Pac_Entr
Cli_Rejeit
Cli_Ent
Cliente

Cli_Reserva

Cli_Cancel

Sistema
Hoteleiro

Cli_Sai
Cliente
Cli_Conta

Ger_Lib
Gerncia
Ger_Can

Prof. Srgio Luiz Tonsig

Cli_Paga

Pgina: 10

Anlise e Projeto de Sistemas II


1.1.3.3. Lista de Eventos do Estudo de Caso

N Evento

Descrio do Evento

Estmulo

01 Cliente
Reserva
Quarto

Quando o cliente telefona ou vem


at o hotel e pede para reservar um
quarto, o funcionrio executa um
procedimento padro
Quando o cliente no comparecer
ao hotel para hospedar-se at as
12:00 horas do dia da reserva
Cliente faz o registro para a
ocupao do quarto, reservado
previamente. Caso no reservado
uma mensagem de rejeio ser
emitido, caso contrrio um pacote
com informaes ser fornecido
Quando o cliente deixar o hotel
este solicita que providencie o
fechamento de sua conta, havendo
a disponibilidade do quarto para
limpeza
Cliente
paga
a
quantia
correspondente ao aluguel do
quarto e s despesas efetuadas
durante sua estadia
Quando o cliente no mais desejar
o quarto reservado e comunicar o
fato, ser cancelado a reserva,
disponibilizando
o
quarto
novamente
Quando o quarto estiver limpo o
gerente torna-o disponvel

Cli_Reserva

Tipo
Ao
Estmulo
F
Efetuar Reserva

Cancelar
Reserva Ger_Cancel
Automaticamente

Cli_Ent

Registrar Cliente

Cli_Pac_Ent ou
Cli_Rej

Cli_Sai

Fechar Quarto

Cli_Conta

Cli_Paga

Registrar Pagamento

Cli_Recibo

Cli_Cancel

Cancelar Reserva
Solicitao

Ger_Lib

Liberar Quarto

Gerncia inclui, exclui ou modifica Ger_Cad


dados do quarto

Manipular
quarto

02 hora de
cancelar
reserva
03 Cliente
registrase
no
hotel

04 Cliente
solicita
sada do
hotel
05 Cliente
paga
a
conta
06 Cliente
cancela a
reserva

07 Gerncia
disponibiliza
quarto
08 Gerncia
cadastra
quarto

Resposta
Cli_Reservado
ou Cli_Indisp

por Cli_Canc

Msg_01

cadastro

de Msg_02

Como voc sabe, deve haver entre a lista de eventos e o diagrama de contexto uma
consistncia. importante lembrar tambm que a Lista de Eventos ou Diagrama de
Contexto podem ser desenvolvidos paralelamente.
Exerccio:
Cheque ambos (Lista de Eventos X Diagrama de Contexto) e acerte as possveis
inconsistncias encontradas.
(eventuais alteraes faa sobre o prprio manual, no local adequado, a fim de que voc
tenha o material completo para estudo)

Prof. Srgio Luiz Tonsig

Pgina: 11

Anlise e Projeto de Sistemas II


1.1.3.4. DFD Particionado por Evento
Depois que a lista de eventos estiver concluda ( claro que as vezes voc esquecer um
ou outro evento, que depois podem ser acrescentados, mas, com certeza os eventos
essenciais estaro l), voc dever fazer o Diagrama de Fluxo de Dados particionados por
Eventos, tambm conhecido como Diagrama das Atividade Essenciais.
Em nosso estudo de caso, conforme nossa lista de eventos, dever haver oito DFDs
particionados por evento. Abaixo, como exemplo, segue o Diagrama correspondente ao
primeiro evento da lista.

Evento 01 Cliente Reserva Quarto


CadReser
va

CadClien

Cli_Reserva

Efetuar
Reserva
CadQuarto

Cliente
Cli_Reservado ou
Cli_Indisp

Exerccio:
Faa o D.F.D. particionado por eventos para os demais itens da lista de eventos.
(antes porm, a seguir, d uma olhada no modelo de dados completo que utilizado neste
estudo de caso pg. 21)

Prof. Srgio Luiz Tonsig

Pgina: 12

Anlise e Projeto de Sistemas II

1.1.3.5. A Especificao dos Processos


Como voc observou no diagrama da pgina anterior (DFD particionado por evento
referente ao evento 01 da lista de eventos ), tudo que se enxerga que existe um processo
que vai tratar determinado evento (Cliente reserva quarto), o qual mexe com
determinados arquivos.
Tem-se portanto, claramente, o que acontece, porm, precisa-se saber, como tal coisa
acontece. Veja que o diagrama no expressa, por exemplo, nenhuma regra do negcio, a
qual, se no for documentada, o desenvolvedor far um programa de reserva de quarto
invlido.
Veja, neste hotel do nosso estudo de caso, um cliente s pode reservar um quarto se o
mesmo estiver liberado, aps ter passado por uma faxina (QuaSit = 0). Isto pode parecer
bvio, mas como expressar essa regra do negcio, a fim de que o programador, ao
desenvolver o mdulo que vai tratar da reserva, possa saber que isto deve ser checado ?
Outro exemplo de regra do negcio :
O cliente que efetuar nova reserva no mximo 15 dias aps sua ltima hospedagem,
ter um desconto de 10 %.
Isto de alguma forma tem que ser documentado e o programador, ao fazer o processo de
fechamento da conta deve aplicar a regra, caso contrrio o sistema no ser vlido.
Portanto tem-se que fazer a especificao funcional do mdulo (como ele deve
funcionar), permitindo que exista uma documentao formal das regras do negcio, bem
como algum possa implementar isto no sistema.
H apenas alguns anos, esta especificao era extremamente formal, cuidando de
mnimos detalhes, basicamente, um programa era escrito para que depois um
programador apenas codificasse. Como por exemplo, o pedao de especificao
mostrada abaixo:
Limpe a Tela
Abra o arquivo CadCli
MostreMensagem Digite o C.G.C.:
Aguarde a digitao
Consistir o C.G.C. conforme rotina CONF_CGC
.
.
.

Prof. Srgio Luiz Tonsig

Pgina: 13

Anlise e Projeto de Sistemas II

Miniespecificaes

Atualmente o enfoque para que haja apenas uma miniespecificao. Uma


miniespecificao vai tratar apenas das linhas genricas do processo enfatizando os
aspectos essenciais e aqueles que referem-se as regras do negcio. De tal maneira que se
no houver esta especificao um programador no far satisfatoriamente o programa, ou
seja, ele no ser um programa vlido, de acordo com a realidade que deve atender.
Portanto ningum sair ditando como fazer um programa para incluir, alterar, excluir ou
consultar cadastros, salvo se houver detalhes de implementao proveniente das regras do
negcio. E, neste caso, haver um miniespecificao acerca daquele aspecto.

O homem observa a montanha, atrs da esposa, com binculo.


Quem estava com o binculo ?
Quem estava atrs da esposa ?

Observe que em uma narrativa comum, pode haver uma srie de ambigidades. Para
tentar eliminar interpretaes diferenciadas de um texto, atravs do qual ser expresso
regras de um negcio, criou-se algumas ferramentas.

Ferramentas para Miniespecificaes

Portugus Estruturado
um texto em portugus, desenvolvido dentro de uma hierarquia. Pode-se empregar
palavras chaves para delimitar esta hierarquia, bem como simultaneamente, indentar
(margens diferenciadas) o texto.
Admite uma certa liberdade de expresso, com relao a tamanho e contedo do texto,
no h critrios rigorosamente estabelecidos. desejvel, porm, que se possa transmitir
algo sem ambigidade de uma maneira bem sinttica.

Prof. Srgio Luiz Tonsig

Pgina: 14

Anlise e Projeto de Sistemas II


Exemplo de portugus estruturado:

DFD Particionado Por Evento - Evento 01 Cliente Reserva Quarto

CadReser
va

CadClien

Cli_Reserva

Reservar
Quarto
CadQuarto

Cliente
Cli_Reservado ou
Cli_Indisp

Miniespecificao
PEGAR dados Cli_Reserva
SE cliente inexistente, faa seu cadastro (para campo Cli_Sit jogar 0 )
PARA reservar quarto, faa:
MOSTRAR lista de quartos livres para reserva ( todos que tiverem Qua_Sit = 0 )
SE no existir pelo menos um quarto livre, faa:
Mensagem Desculpe, Hotel totalmente ocupado.
Encerrar
FIM SE
QUANDO escolhido um quarto livre, faa:
MARCAR quarto como reservado (jogar 1 para campo Qua_Sit)
MARCAR cliente como solicitado reserva (jogar 1 para Cli_Sit)
FIM QUANDO
FIM PARA

Prof. Srgio Luiz Tonsig

Pgina: 15

Anlise e Projeto de Sistemas II


Pseudocdigo
Basicamente, pseudocdigo e portugus estruturado no trazem grande diferena,
contudo possvel distinguir entre ambos (algumas vezes os termos so usados
indistintamente como sinnimos).
O pseudocdigo usa notao mais formal, mais orientada ao profissional
de
processamento de dados, empregando as palavras chaves e tentando seguir uma sintaxe
bem mais prxima de uma linguagem de programao.
Usa-se palavras-chaves para realar o que seriam comandos utilizadas nas linguagens de
programao; por exemplo: SE, SENO, ENTO, FIMSE, REPETIR, ENQUANTO,
REPETIRAT, FIMREPETIR, ENCERRAR.
Com relao as expresses lgicas, emprega-se a mesma gama de signos: >, <, =, <=, >=,
E, OU.
A grande desvantagem em se utilizar pseudocdigo, no lugar do portugus estruturado,
que neste, se possibilita no prprio texto uma explicao mais detalhada acerca do
processo que est sendo especificado. No pseudocdigo, tambm possvel agregar
explicao, porm deve seguir como se fosse um comentrio em uma linguagem de
programao, devendo ficar entre /* */.
/* um comentrio qualquer em pseudocdigo */

Vamos examinar a seguir, como fica o exemplo feito em portugus estruturado referente
ao evento essencial 01, agora refeito em pseudocdigo

Prof. Srgio Luiz Tonsig

Pgina: 16

Anlise e Projeto de Sistemas II

CadReser
va

CadClien

Cli_Reserva

Efetuar
Reserva
CadQuarto

Cliente
Cli_Reservado ou
Cli_Indisp

Miniespecificao
PEGAR Cli_Reserva
SE cliente = inexistente ENTO EXECUTAR Cadastro_Cliente
SE reservar = VERDADEIRO ENTO:
EXECUTAR Lista_Quartos_Livres
SE quarto = inexistente ENTO:
Mensagem Desculpe, Hotel totalmente ocupado.
ENCERRAR
FIM SE
SE quarto = escolhido ENTO:
Qua_Sit = 1.
Cli_Sit = 1.
FIM SE
FIM SE

Prof. Srgio Luiz Tonsig

Pgina: 17

Anlise e Projeto de Sistemas II


Ferramentas Auxiliares de Miniespecificaes
Duas outras tcnicas de especificao podem ser utilizadas para expressar situaes de
lgica complexa ou no.
rvores e Tabelas de Deciso
Uma rvore de deciso um modelo de uma funo na qual determinado o valor de
uma varivel, com base neste valor, alguma ao executada.
A ao pode ser para a escolha de outra varivel a ter seu valor calculado ou a sada da
funo. Ento, cada ao executada depende do valor atual da varivel que est sendo
testada e de todas as aes anteriores que foram executadas. Em uma rvore de deciso
definida formalmente, uma varivel s testada uma vez em qualquer caminho atravs da
rvore. Esta restrio feita para evitar testes redundantes.
Exemplo de rvore de deciso.
< 15 dias
< 30 dias
< 45 dias
< 90 dias
+90 dias

Ultima Compra
Pessoa
Fsica

Emitir Congratulaes
Emitir uma pesquisa
Enviar catlogos
Enviar Convite
Enviar telegrama
Enviar Catlogos

Clientes

n
Pessoa
Jurdica

Saldo Devedor
?
s
Enviar Carta Cobrana

Raiz

Tronco

Tronco

Tronco

Folhas

Exerccio Desenvolva uma rvore de deciso para o enunciado que segue.


Se cliente for maior de 18 anos, pode fazer assinatura da revista. Os menores de 18,
apenas com uma declarao dos pais. A assinatura pode ser feita para 6 meses, 9 meses,
12 meses ou 24 meses. Caso seja paga com carto, ter um desconto de 2% (6 meses),
3% (9meses), 5%(12 meses) e 10% (para 24 meses).
rvores de deciso no so indicadas para expressar lgica complexa, neste caso,
prefervel as tabelas de decises.
Uma rvore comea sempre em uma raiz, a partir da qual, sempre ter no mnimo dois
troncos, que daro origem a outros troncos ou folhas. Em cada tronco, pode surgir no
mnimo dois e no mximo n outro troncos. Um tronco de um galho no pode ligar-se a
outro tronco em outro galho. Uma rvore sempre terminar em suas folhas.

Prof. Srgio Luiz Tonsig

Pgina: 18

Anlise e Projeto de Sistemas II

Tabelas de Deciso
Tem a mesma finalidade das rvores de deciso, porm abrem mo do aspecto grfico e
proporcionam uma forma tabular. Pode-se por elas construir lgicas complexas. As
tabelas de deciso possuem os seguintes componentes:

Condies
/Aes

Regras

01

02

Condio 2

Condio n

Ao 1

Ao n

Condio 1

03

04

05

06

07

...

Tem-se trs elementos distintos na tabela de deciso: As condies, as regras de deciso e


as aes.
A leitura da tabela de deciso deve ocorrer a partir da regra de deciso n 1. Deve-se ler
no sentido vertical.
No exemplo acima, l-se a condio 1. Se a resposta for S, passar para a condio
seguinte. Se a resposta no for S, pula-se para a regra de deciso n 2 (e inicia-se da
mesma forma).
A cada condio existente, verifica-se se a resposta obtida aquela assinalada, se
afirmativo, seguir para a condio seguinte. Se esta regra for totalmente satisfeita, ou
seja, as respostas dadas as condies sejam de acordo com o que foi assinalado (s, n),
checa-se os cursos de ao. Cada ao que estiver assinalada com X, ser executada.
Uma vez satisfeita totalmente uma regra de deciso, a aplicao da tabela se encerra. Se
pelo menos uma condio da regra no for satisfeita, pula-se para a prxima regra de
deciso e assim sucessivamente.
Veja na prxima pgina um exemplo de tabela de deciso.

Prof. Srgio Luiz Tonsig

Pgina: 19

Anlise e Projeto de Sistemas II

Condies
e aes
a

01
S
S

02
S
N

03
S
N

04
S
N

Regras de Deciso
05 06 07
08
S
N
N
N
-

Cliente Pessoa Fsica ?


Ultima Compra foi feita
menos que 15 dias ?
Ultima Compra foi feita
menos que 30 dias ?
Ultima Compra foi feita
menos que 45 dias ?
Ultima Compra foi feita
menos que 90 dias ?
Ultima Compra foi feita
mais de 90 dias ?
Saldo Devedor ?
Emitir Congratulaes
Emitir uma pesquisa
Enviar Catlogo
Enviar Convite
Enviar Telegrama
Enviar carta cobrana

09

10

11

12

X
X
X

X
X
X
X

Exerccio
Para o mesmo enunciado do exerccio existente na pgina 17, construa uma tabela de
deciso.

Prof. Srgio Luiz Tonsig

Pgina: 20

Anlise e Projeto de Sistemas II


Miniespecificao de Processos
Orientao e Padronizao para aplicao no T.C.C.

Uma miniespecificao vai tratar apenas das linhas genricas do processo, enfatizando os
aspectos essenciais e aqueles que referem-se as regras do negcio, de tal maneira que, se
no houver esta especificao, um programador no far satisfatoriamente o programa, ou
seja, ele no ser um programa vlido, de acordo com a realidade que deve atender.

Portanto ningum sair ditando detalhadamente como fazer um programa para incluir,
alterar, excluir ou consultar cadastros, dever ser apresentado apenas a sntese do objetivo
global do processo, salvo se houver detalhes de implementao proveniente das regras do
negcio, neste caso, haver um miniespecificao um pouco mais ampla.

Para qualquer miniespecificao sugere-se a utilizao de uma ferramenta que tente evitar
ao mximo ambigidades de interpretao, com relao as idias que esto sendo
expressas. Neste sentido emprega-se: Portugus Estruturado, Pseudocdigo, Tabelas de
Deciso ou rvores de Deciso.

O mtodo da anlise essencial indica estas ferramentas para a miniespecificao, porm,


deixa em aberto o formato de apresentao da miniespecificao. Muitos autores,
influenciados pela fase estruturalista da anlise, normalmente exemplificam uma
miniespecificao de forma estruturada, conforme exemplo a seguir:

Prof. Srgio Luiz Tonsig

Pgina: 21

Anlise e Projeto de Sistemas II

CadReser
va

CadClien

Cli_Reserva

Efetuar
Reserva
CadQuarto

Cliente
Qua_Reservado ou
Qua_Indisp
PEGAR Cli_Reserva
SE cliente = inexistente ENTO EXECUTAR Cadastro_Cliente
SE reservar = VERDADEIRO ENTO:
MOSTRAR Lista_Quartos para escolha de um
SE quartos escolhidos = ocupados ENTO:
Mensagem Desculpe, Hotel totalmente ocupado. (Qua_Indisp)
ENCERRAR
FIM SE
SE quarto = livre ENTO:
Qua_Sit = 1. /* marcar quarto como ocupado */
Cli_Sit = 1. /* marcar cliente com reserva feita */
Mensagem Reserva Concluda. (Qua_Reservado)
FIM SE
FIM SE

Verifica-se contudo, que perfeitamente livre a criao de uma miniespecificao em


outros formatos, propiciando formas mais abstratas, sem a idia de uma estruturao.
Este fator de fundamental importncia, j que, com um formato mais abstrato, tem-se
uma anlise imparcial com relao a linguagem de implementao.
Um modelo mais abstrato de miniespecificao, possibilita sem qualquer tipo de
influncia, que o Analista se decida por implementar utilizando uma linguagem
estruturada, linguagem de quarta gerao, ou orientao a objetos.
Dentro desta perspectiva, com intuito de estabelecer um nico formato para as
miniespecificaes dos TCCs, ser adotado o formato mais abstrato. Segue exemplo e
algumas observaes a serem consideradas, com relao ao formato proposto. O exemplo
a seguir o mesmo mostrado anteriormente, porm, utilizando a forma que dever ser
empregada nos TCCs.

Prof. Srgio Luiz Tonsig

Pgina: 22

Anlise e Projeto de Sistemas II

CadReser
va

CadClien

Cli_Reserva

Efetuar
Reserva
CadQuarto

Cliente
Qua_Reservado ou
Qua_Indisp
PEGAR Cli_Reserva
EFETUAR cadastro do Cliente
RESERVAR quarto SE houver disponibilidade
RETORNAR mensagem ao cliente de acordo com resultado da operao

Acima um exemplo com o mesmo contedo mostrado anteriormente, porm, utilizando a


forma que dever ser empregada nos TCCs. Esta forma no induz a uma lgica especfica
para implementao que poder vir a ser de forma estruturada, orientada a eventos,
orientada a objetos ou ainda um mix destes paradigmas.

Consideraes Gerais sobre o exemplo

O fluxo de dados Cli_Reserva, Qua_Reservado e Qua_Indisp, e os depsitos CadClien,


CadReserva, CadQuarto devem estar descritos no dicionrio de dados. Com estas
descries, mais a modelagem de dados, a miniespecificao acima de fcil
implementao em qualquer linguagem.

Prof. Srgio Luiz Tonsig

Pgina: 23

Anlise e Projeto de Sistemas II


Observaes para a construo do modelo proposto.
1. No deve aparecer na miniespecificao qualquer descrio que j exista na lista de
eventos.
2. Se uma regra de negcio j foi estabelecida e descrita a nvel de dicionrio de dados,
no deve ser objeto de descrio na miniespecificao. Exemplo: No aceitar
cadastro de clientes menores que 18 anos. Se no campo cliente.idade, no dicionrio
de dados, j foi mencionado que o contedo do mesmo deve ser >= 18; ento, no h
motivos para especificar isto novamente na miniespecificao (evitar qualquer
redundncia). Detalhes com relao ao contedo de campos e seu significado devem
necessariamente estar no dicionrio de dados.

3. Iniciar as sentenas com um verbo sempre no infinitivo. O verbo deve dar a idia da
operao que se deseja realizar. Uma vez utilizado um verbo para determinada
operao, ele sempre deve ser empregado quando se tratar daquela operao
(padronizao especfica).

4. O complemento da sentena possui contedo livre, desde que: seja claro, sem
ambigidades e o mais sinttico possvel. Pode ser empregado outros verbos no
complemento da sentena para facilitar a expresso da idia.

Prof. Srgio Luiz Tonsig

Pgina: 24

Anlise e Projeto de Sistemas II

1.1.3.6. Modelagem de Dados do Estudo de Caso


O Analista verificou que havia uma relao entre Clientes e Quartos (Reserva), sobre a
qual deveria armazenar informaes.
Desta forma, o Analista de Sistemas gerou o Diagrama de Entidade Relacionamento,
fazendo uma modelagem lgica de dados, conforme segue:

Cli_cpf

Qua_Nr

Cli_nome
Cli_End

CadClien

Res_DataIn

Reserva

Res_DataFi

Qua_Descr
Qua_Sit
Qua_Val

CadQuarto

CadRese

Cli_Sit
Cli_Ult_Data

claro que antes de se chegar a este modelo de dados (D.E.R.), para cada depsito de
dados que existia nos DFDs particionados por evento, foi elaborado uma lista de
atributos, e eleito a chave principal. Depois, ao modelo inicialmente obtido, foi aplicado a
teoria da normalizao (1, 2 e 3 formas normais). O passo seguinte a partir da
modelagem lgica dos dados, gerar sua modelagem fsica, ou seja, criar um modelo de
dados com uma forma a partir da qual os dados sero implementados de fato. Para tanto,
gera-se o Diagrama de Estrutura de Dados.
Aqueles relacionamentos existentes do DER, para os quais foi verificado a necessidade
do armazenamento de atributos, no DED sero transformados em uma Entidade (depsito
de dados), conforme visto a seguir.

Prof. Srgio Luiz Tonsig

Pgina: 25

Anlise e Projeto de Sistemas II

Cli_cpf

Qua_Nr

Cli_nome
Cli_End

CadClien

Res_DataIn Res_DataFi

CadReser

Qua_Descr
Qua_Sit
Qua_Val

CadQuarto

Cli_Sit
Cli_Ult_Data

Portanto, para modelo fsico, o analista designou o nome CadClien para o arquivo ou
tabela onde iria ser armazenado os dados do cliente, de igual forma CadQuarto para os
dados do quarto e CadReser para os dados da reserva.

Prof. Srgio Luiz Tonsig

Pgina: 26

Anlise e Projeto de Sistemas II


1.1.3.7. Diagrama Hierrquico de Macro Atividades
Uma vez concludo os DFDs particionados por evento, pode-se desenvolver este
diagrama. Ele consiste em um DFD que agregar eventos relativos a um mesmo assunto,
permitindo uma viso simplificada do sistema.
Cli_Reserva
Cli_Reservado ou Cli_Indisp
Clientes

1, 2, 6

Cli_Canc

Tratar
Reserva

Cli_Cancel

CadClien

CadReser

Ger_Cancel

CadQuarto
Msg_01

Gerncia

Msg_02
Cli_Ent
Cli_Cancel
Clientes

3,4
Tratar
Cliente

Cli_Sai

Cli_Reserva

Prof. Srgio Luiz Tonsig

7,8
Tratar
Quarto

Ger_Lib
Ger_Cad

Cli_Conta

Cli_Paga

Clientes

Pgina: 27

Anlise e Projeto de Sistemas II


1.1.3.8 Dicionrio de Dados (parcial) do Estudo de Caso

Caracter_Valido = * Conjunto de caracteres que podero ser utilizados *


Tipo: Alfanumrico
Tamanho: 01
[A-Z | 0 9 | @ | & | / | a z | , | . | - | * ]
Cli_Cpf

= * Conter o Cdigo do Cadastro de Pessoa Fsica (CIC) *


Formato: 999.999.999-99

Cli_Nom

= * Nome do Cliente *
Tipo: Alfanumrico
Tamanho: 40
Contedo: {Caracter_Valido}

Cli_Rua

= * Rua, Avenida, Praa, e n. onde reside o Cliente *


Tipo: Alfanumrico
Tamanho: 40
Contedo: {Caracter_Valido}

Cli_Bairro

= * Nome do Bairro onde reside o cliente *


Tipo: Alfanumrico
Tamanho: 20
Contedo: {Caracter_Valido}

Cli_Cidade

= * Nome da Cidade onde reside o Cliente *


Tipo: Alfanumrico
Tamanho: 20
Contedo: {Caracter_Valido}

Cli_UF

= * Sigla do Estado onde se encontra a cidade do cliente *


Tipo: Alfanumrico
Tamanho: 02

Cli_Cep

= * Cdigo do endereamento postal de onde reside o cliente *


Formato: 99999-999

Cli_End

= * Endereo completo de residncia do cliente *


Cli_Rua + Cli_Bairro + Cli_Cid + Cli_UF + Cli_Cep

Prof. Srgio Luiz Tonsig

Pgina: 28

Anlise e Projeto de Sistemas II


Cli_Sit

= * Indicar se o cliente encontra-se hospedado ou no *


Tipo: Inteiro
Tamanho: 01
Contedo: 0 * No est Hospedado *
1 * Encontra-se com Reserva Feita *
2 * Encontra-se Hospedado *

Cli_Ult_Data

= * Dever Ter a ltima data em que o cliente hospedou-se *


Formato: 99/99/9999

Cli_Registro

= * Tupla do Cliente *
@Cli_cpf + Cli_Nom + Cli_End + Cli_Sit + Cli_Ult_Data

CadCli

= {Cli_Registro}

Observe que o exemplo deste pequeno dicionrio de dados acima, compatvel com a
entidade CadCli do modelo de dados mostrado anteriormente.
Lembre-se de que no dicionrio deve estar todos os dados tratados no modelo de dados,
bem como os Fluxos de Dados e Mensagens especificadas na lista de eventos.
Exerccio:
Refaa o dicionrio de dados (parcial) mostrado como exemplo, tentando diminuir seu
tamanho sem perder o seu contedo. (Otimize o jeito de escreve-lo utilizando os recursos
de sintaxe disponveis)

No Esquea
At este ponto (desde de o levantamento de Dados, modelo Ambiental e modelo
Comportamental ) tem-se os processos e resultados da Anlise do Sistema.
Na continuao do processo de desenvolvimento do sistema, dever ser elaborado o
chamado design

Prof. Srgio Luiz Tonsig

Pgina: 29

Anlise e Projeto de Sistemas II


1.1.3.9. CASE - (Computer Aided Software Engineering)
Engenharia de Software Auxiliada por Computador
Este termo foi criado no comeo dos anos 80, atribudo a qualquer software que busca
auxiliar o Analista na construo de sistemas.
Teoricamente, para uma ferramenta ser considerada um software CASE, ela deve
incorporar e suportar toda a trajetria e tcnicas de especificao e construo de um
sistema de acordo com determinado mtodo.
Deve ainda gerar o cdigo fonte de acordo com uma linguagem escolhida, compativel
com o mtodo empregado.
No caso de Orientao a Objeto, dever gerar o cdigo fonte em uma linguagem OO, ou
trabalhar integrado a um repositrio de metadados de um banco de objetos.
Pelo fato de existir softwares de apoio ao desenvolvimento de sistemas, que no atendem
na integra a definio terica de CASE, foi criado termos para classifica-los, tais como
UPPER-CASE, LOW-CASE.
Se um software auxilia o analista apenas na parte inicial da metodologia, onde so
tratados os aspectos lgicos (especificao/documentao) dito que ele um UPPERCASE, porm, se o software auxilia na modelagem lgica e fsica, propiciando at a
possibilidade criao da base de dados, pode-se classific-lo como um LOW-CASE.

Prof. Srgio Luiz Tonsig

Pgina: 30

Anlise e Projeto de Sistemas II

2. Projeto (design)
Project do Ingls
maior do que aquele representado pela nossa palavra projeto. Project leva em
considerao fases anteriores ao nosso projeto, abordando tarefas de planejamento,

O projeto, de que vamos tratar a partir deste ponto, portanto, o projeto propriamente
dito (no ingls encontramos mais adequadamente a palavra
).
O Projeto Estruturado Moderno de Sistemas a atividade de transformao das
implementao atravs da automao eletrnica.
O objetivo modelar o sistema determinando
implementar, num ambiente em
que deixa-se de ter a tecnologia perfeita, passando a levar em considerao o hardware

As restries de implementao, da tecnologia no ideal e imperfeita sero incorporadas


atravs de atividades de infra-estrutura e administrativas.

Completeza
O projeto no deve perder nada do que foi identificado na fase de anlise como requisito

Manutenibilidade
Deve-se projetar um sistema de forma a permitir facilidades de alteraes, provenientes

Erros do Sistema
Novas necessidades do usurio

(observa-se que os sistemas mais fceis de alterar so aqueles construdos de forma


modular
desempenhando funes bem definidas e coesas)

Ela est diretamente relacionada ao uso otimizado dos recursos de hardware, software e
pessoal disponveis.

Prof. Srgio Luiz Tonsig

31

Anlise e Projeto de Sistemas II


Com relao aos fatores que afetam o desempenho, temos:
Deficincia do Projeto de Interface
Vrios cuidados devem ser tomados quando se projeta uma interface (superfcie entre
duas faces), mecanismos pelo qual ocorre a comunicao atual homem-mquina.
A interface deve permitir que a comunicao se estabelea no sentido homem-mquina e
vice-versa, devendo ser um mecanismo de mo dupla, permitindo ao homem no apenas
ser o agente deflagrador de um processo comunicativo, mas contemplar o desenrolar do
mesmo; intervindo, requerendo ou sendo requisitado.
Quando houver entradas de dados referentes a um documento fonte original, a partir do
qual as informaes esto sendo transcritas, a ordem dos campos na tela (quando for o
caso de um vdeo) deve obedecer a mesmo ordem dos campos existentes no documento,
principalmente quando se tratar de um grande volume de transao. O analista de sistema
deve estar atento e acompanhado o nascimento de novos meios para o input de dados nos
computadores (voz, ondas cerebrais e outros), adequando sempre a interface segundo o
novo contexto.
Tempo de acesso a disco e perifricos
Observe que para este tpico, deve-se conhecer muito bem o ambiento topolgico do
hardware em que se est trabalhando e sua periferia (de perifricos), alm claro do
hardware que est sobre esta estrutura.
Devido ao tempo gasto em acesso a discos (que atualmente muito maior do que as
operaes na CPU), deve-se prover o sistema de mecanismos que minimizem este tempo,
empregando-se organizaes de arquivos adequadas, ou ajustando o parque de hardware.
Falta de Reorganizao de Arquivos
Em arquivos grandes de muita utilizao, deve-se verificar a possibilidade de limpezas
peridicas, ou particionamento do arquivo, gerando um atual e um outro histrico.
Processos longos em horrio de pique
Evite ao mximo a execuo de processos batch de longa durao (transferncias de
grandes arquivos, atualizao de grande volume de dados) durante o horrio de pique.

Prof. Srgio Luiz Tonsig

Pgina: 32

Segurana
Criar mecanismos que evitem acessos indevidos (ou no desejados) ao sistema.

-Infiltrao no intencional (linhas cruzadas, irradiaes)


-Acidentes erro do usurio, falha de hardware, falha de software

Est relacionada a reduo do risco de interrupo no fluxo normal de processamento das


informaes, que pode ser causada por:
indisponibilidade de acesso o sistema no oferece o servio no tempo estipulado
perda da integridade da informao

Deve haver uma admissvel distribuio de custos entre os aspectos que seguem:
- custo da tecnologia
- custo operacional
- custo de construo e manuteno

2.2 Modelo de alocao de processadores

define quem

quem, entende-se computador ou pessoas (processadores

Em relao aos modos de processamento de um sistema, h um espectro razoavelmente


grande de possibilidades, que vai desde um processamento inteiramente manual at um

Pode-se ir desde a total centralizao em um nico processador at uma soluo que


utilize uma complexa rede de processamento distribudo. Na verdade, todo sistema possui

Tem-se aqui o objetivo de alocar as atividades essenciais (segundo a lista de eventos) aos
processadores que as executaro. Deve-se tambm alocar atividades adicionais

Prof. Srgio Luiz Tonsig

Pgina:

Anlise e Projeto de Sistemas II


Portanto, necessrio responder a estas questes:
-Quais os processos manuais e quais os automticos ?
-Qual o processador de cada processo essencial (segundo a lista de eventos) ?
-Qual o processador de cada processo adicional (visto a limitao de tecnologia) ?
-Qual o modo de processamento de cada processo ?
-Qual a freqncia de execuo de cada processo ?
Um maneira de mostrar essas caractersticas do sistema atravs de um quadro de
referncia como a seguir:
FREQUNCIA
Minuto

Hora

Dirio

Semanal

Mensal

Batch
Processador A
On-Line
Batch

P1/P2
PT01

Processador B
On-Line
Sistema
.
.
.
Batch
Processador n
On-Line

Prof. Srgio Luiz Tonsig

Pgina: 34

Anlise e Projeto de Sistemas II


H vrias formas que podem ser apresentadas para satisfazer visualmente a alocao de

Processador
PC-01

PC-02
Pentium 133

Processo

Evento

Tipo Processamento Frequncia

P01

Cliente Reserva Quarto

P02

hora de cancelar reserva

Batch

Dirio

PT01

Executar Antivrus

Batch

Semanal

P07

Quando Quarto estiver


gerente disponibiliza-o
PT01 Executar Antivrus

Diria

limpo On-Line

Dirio

Batch

Semanal

PT02

Backup dos Dados

Batch

Dirio

PT03

Reorganizao de Arquivos

Batch

Anual

.
.
.

Pnn
PTn

= Atividade Essencial da lista de eventos


= Processo de restrio Tecnolgica

O exemplo acima leva vantagens sobre o anterior, notadamente pelo fato de que pode ser
aplicado a pequenas ou grandes quantidades da relao processador X processo. No
modelo anterior, fica muito difcil a representao de vrios processos a serem
executados em um mesmo processador num mesmo perodo.

Prof. Srgio Luiz Tonsig

35

Anlise e Projeto de Sistemas II

2.3.1 Verificao e Validao


Em 22 de Julho de 1962, o foguete espacial Mariner I foi lanado em um primeiro
desviou de sua rota e o controle terrestre deu a ordem para explodi-lo. Posteriormente,
uma investigao revelou que o software apresentava erros. A omisso de um simples
fracasso de toda a misso. O custo para o contribuinte fiscal foi de 18,5 milhes de
dlares (MARTIN & MCCLURE, 1991:737).

comparado ao Mariner I, contudo, poder se enquadrar nas mesmas propores


catastrficas, quanto aos possveis erros que venha a apresentar.

desenvolvidos, apesar dos esforos especiais que se tem empregado para se atingir a
perfeio. A preocupao com tais fatos, se deve ao prejuzo econmico que eles podem

Certamente que a proeza de se conseguir um software 100% correto no momento de sua


elaborao, nem sempre uma tarefa possvel, mas isto seria o ideal.

verificao e validao, fazendo uso de tcnicas dirigidas.


Um questionamento sempre levantado sobre tais atividades, refere-se ao momento ideal
durante o mesmo ?
Constata-se que a correo deve ser aplicada por todo o ciclo de desenvolvimento,

Verificao a demonstrao da consistncia, completeza e correo do software


medida que ele evolui... Validao a demonstrao de que o sistema de software
& MCCLURE, 1991:734).
Nota-se ento, que a verificao busca corrigir o software etapa por etapa, durante o ciclo
finalizado.

Pgina: 36

Anlise e Projeto de Sistemas II


Alm do software final livre de erros, a economia monetria e de tempo que se pode obter
quando se utiliza as atividades de verificao e validao, so considerveis.
A trajetria bsica e mnima que se espera que o Analista deva seguir sugerido abaixo:
Com relao a Verificao
Efetuar testes de unidade a cada mdulo do software desenvolvido, verificando se este
atinge seus objetos sem apresentar qualquer anomalia na execuo e no desempenho
lgico.
Lembre-se de que teste deve ser a incansvel busca de erros, e a depurao, a eficiente
eliminao dos erros encontrados.
Com relao a Validao
Primeiro efetuar um teste funcional do sistema, onde, aps todos os mdulos terem
passado pelo teste de unidade, verifica-se como se comportam quando executados em
conjunto.
Submeter, este processo de teste funcional, a um rigoroso exame pelo usurio, a fim de
que se manifeste sobre a validade do produto.

Segurana de Dados
Por incrvel que parea, muitos daqueles diretamente ligados a tecnologia da informao,
tais como tecnolgos, analistas, programadores, raramente, ao editar um texto, por
exemplo, tem a preocupao de efetuar um backup. O que pensar ento de um usurio
mais leigo ?
fundamental, em qualquer sistema de informao, sob qualquer aspecto, que haja
mecanismos para salvaguardar os dados manipulados no sistema. Tais mecanismos
podem ser desde meras rotinas dirias de backup, at sofisticados hardwares com o meio
de armazenamento espelhado e componentes redundantes, ou ainda tcnicas de
replicagens da informao.
Para a transao da informao tambm h absoluta necessidade de segurana. Sob este
aspecto podemos considerar dois fatos:
1) Duas ou mais operaes acionadas em um processo que, para manter a integridade da
informao, todas as operaes devem ser corretamente concludas. Havendo falha de
uma, todo o processo deve ser revertido (Roll-Back).
2) Casos em que uma informao em trnsito poder exigir sua mais absoluta
inviolabilidade deve passar pelo processo de criptografia.

Prof. Srgio Luiz Tonsig

Pgina: 37

Anlise e Projeto de Sistemas II


Outra caracterstica de segurana de dados a ser tratada o acesso aos mesmos. Tanto
quanto necessrio, checar identificao e senhas de acesso conforme o caso exigir.
Segurana de Hardware
Sabe-se que para um hardware funcionar perfeitamente, existe algumas especificaes a
serem observadas. Via de regra, ignora-se tal fato, visto que existem muitos lugares onde,
por exemplo, o pino terra da alimentao eltrica no utilizado. Outros fatores
importantes como a estabilidade da tenso eltrica e a temperatura ambiental so fatores
encarados como totalmente secundrios.
As instalaes para utilizao do hardware deve atender as suas especificaes. Caso
contrrio, o seu sistema j comea com alto risco de erro.

2.4 Diagrama hierrquico do sistema


Mais como um mecanismo de estabelecimento da organizao hierrquica do sistema, o
diagrama tambm um documento de interface, j que um esboo do que vir a ser o
menu do sistema.
Desta forma ele tambm parte integrante da documentao do sistema, uma vez que se
pode recorrer a ele para identificar posies ou seqncia de caminho at se chegar a
uma determinada opo.
Menu
Principal

Cadastros

Movimentao

Quartos

Clientes

Consultas

Segurana

Reserva
Quarto

Quartos Livres

Registro
Cliente

Clientes
Hospedados

Backup

Cancela
Reserva

Fecha
Conta

Libera
Quarto

Prof. Srgio Luiz Tonsig

Pgina: 38

Anlise e Projeto de Sistemas II

Observa-se que podem haver outros programas no sistema, porm, sua execuo d-se
em funo de outros fatos, que no sejam da escolha de um usurio. Como exemplo
pode-se citar: programa de converso de valor para extenso, programas cujo estmulo seja
um fluxo temporal (rodar todo dias as 12h).
Estas chamadas de programas estaro documentadas nas miniespecificaes dos
programas chamadores. Por exemplo, em um programa que emita um recibo, cujo valor
deve ser convertido para extenso, dever conter em sua miniespecificao a chamada a
esta subrotina ou programa.

2.5 Lay-Out de telas / relatrios


Qualquer sistema de informao utiliza interfaces e cuida do meio pelo qual este
mecanismo opera.
Na construo dos sistemas de informao, necessrio um cuidado especial com relao
aos requisitos exigidos por cada uma das partes (homem-mquina) que se ligam pela
interface.
Para a mquina basta que o meio fsico esteja em perfeita condio de funcionamento,
pois assim, os dados do input estando corretos, o resultado certamente estar (sob ponto
de vista do hardware).
O homem por sua vez, ao receber uma informao proveniente da mquina, deve
visualiz-la de uma forma amigvel e de fcil entendimento. Este aspecto pode ter muita
influncia na negociao poltica de venda do produto para o usurio.
Em certos momentos a forma mais amigvel e de fcil entendimento, ser aquela que o
usurio deseja ver, independente do que voc tenha estudado sobre interfaces e
ergonometria (no se esquea disto).
O fato que uma vez definido um relatrio ou uma tela, tente seguir aquele modelo como
padro para os demais.
Por que padronizar ? Ora, voc estar universalizando funes, bem como diminuindo o
tempo de aprendizado e uso de seu sistema. No reinvente a roda. Se j existe um certo
padro de mercado, emprega-o .
Veja por exemplo, se voc fizer hoje um software para utilizao em um
microcomputador IBM-PC, qual a tecla mais indicada para ser utilizada como help do seu
sistema ? Por qu ?

Prof. Srgio Luiz Tonsig

Pgina: 39

Anlise e Projeto de Sistemas II

mencione:
Nome da tela/Relatrio
Data / Hora
Pgina

no caso de um desenvolvimento para o ambiente WINDOWS, voc deve respeitar todas


as caractersticas de interface j definidas.

Atualmente existe um leque muito grande de recursos para tornar amigvel a interface
homem-mquina.

atualmente melhor esto sendo empregadas, j que uma forma bastante amigvel de
enviar e receber informaes.

como sons, imagens estticas, animadas ou filmadas e outros elementos de multimdia.


Multimdia a combinao de texto, som e vdeo para apresentar informaes por
muda a maneira como as pessoas usam os computadores... (JAMSA, 1993:XIII).
Por exemplo, em um sistema de controle de biblioteca, poderia-se ter alm da opo de
na lngua previamente escolhida, e tambm, a seu critrio, poderia ver as imagens
relativas a estria que estaria sendo narrada.

possibilidade futura da inexistncia de um vdeo como hoje o concebemos, mas a


projeo de imagens hologrficas, propiciando a interao atravs de uma realidade
circunstncias normais ( como por exemplo, caminhar dentro de um vulco ou tapar sua
chamin e verificar o resultado, segundo as leis da fsica ).

Pgina: 40

Anlise e Projeto de Sistemas II

3. Gerncia de Projetos

A partir deste ponto vamos tratar de projeto (Project) no sentido do empreendimento


global, diferente portanto de projeto (design) que apenas uma fase dentro deste
empreendimento.
Exceto pela execuo das atividades de desenvolvimento propriamente dito, que
envolvem metodologias, tcnicas e ferramentas de desenvolvimento, tudo mais em um
projeto de sistemas ao de gerncia.
Assim deve-se ter em mente o que segue, como definio do nosso empreendimento
global:

Projeto de Sistemas = estabelecimento de OBJETIVOS +


Planejar e executar ATIVIDADES +
Administrar PRAZOS +
Gerenciar RECURSOS +
Conviver com RISCOS/INCERTEZAS

3.1 Problemas em projetos de sistemas

3.1.1 Relacionados com a rpida evoluo da tecnologia

Proliferao desordenada de microcomputadores


Vida til do Hardware
Grande quantidade de software no integrado
Aumento dos nveis de expectativa devido divulgao instantnea das inovaes
Ferramentas de desenvolvimento muito recentes, ainda no consolidadas

Prof. Srgio Luiz Tonsig

Pgina: 41

Anlise e Projeto de Sistemas II

3.1.2 Relacionados com pessoas

As pessoas freqentemente no sabem o que realmente querem ou necessitam


desenvolvimento de sistemas exige muita comunicao:
- No. De interaes dois a dois = N(N 1) / 2
- Muitas pessoas falam bem, pouqussimas ouvem bem
- Palavras tem diferentes significados

muito comum desenvolvedores no ouvirem os usurios e raramente constrem o


que necessrio
Desenvolvedores no aceitam mudana no seu prprio domnio (paradigma de
comportamento)
Conflitos sempre existiro. Cabe ao gerente administrar adequadamente

3.1.3. Outros problemas Gerenciais


Imprevisibilidade previsvel
Frias de elementos da equipe
Baixa disponibilidade de recursos de hardware
Alocao temporria de pessoal para outro sistema
Mudana de prioridades da organizao
Seleo de pessoal
Quantidade X Qualidade
Nvel do profissional (conhecimento X experincia X dinamismo )
A somatria destes dois fatores trs como conseqncia um terceiro:
Dificuldade de estimar prazos e recursos

Prof. Srgio Luiz Tonsig

Pgina: 42

Anlise e Projeto de Sistemas II

3.1.4. Dificuldade de aferir progresso


100 %

Tempo
99 %

SINDROME DOS 99 %

No h frmulas mgicas para evitar atrasos em projetos de sistemas (No silver bullet
no tem bala de prata)
A nica maneira de monitorar o progresso de um projeto, atravs do estabelecimento de
marcos ou pontos de controle, ao longo das fases e atividades que o compem, que se
constituem em etapas sobre as quais podemos afirmar com certeza: est 100% concluda.
3.1.5. A Crise do Software
Em 1993 foi feito uma estimativa sobre das metodologias, tcnicas e ferramentas de
desenvolvimento de sistemas existentes na poca (que foram uma somatria evolutiva
dos 25 anos anteriores), e pode-se concluir que:
Se todos os sistemas necessrios tivessem que ser implementados nos prximos dez
anos com a tecnologia de software disponvel, mais da metade da populao do mundo
teria que ser de programadores .
O recente advento dos gerenciadores de bancos de dados, das ferramentas CASE
(Computer Aided Software Engineering ) , das linguagens de programao visuais e da
orientao a objeto tem contribudo para melhorar a produtividade no desenvolvimento
de sistemas. Porm, apenas uma gerncia adequada do uso dessas ferramentas tornar
possvel a superao da crise do software ainda existente.
Muitas pessoas acreditam que desenvolver um sistema simplesmente programar.

Prof. Srgio Luiz Tonsig

Pgina: 43

Anlise e Projeto de Sistemas II

Como se fosse possvel aplicar a sistemas complexos do mundo real, as mesmas decises
de projeto, utilizadas na resoluo de problemas que esto ao alcance da compreenso de
um nico programador.

Prof. Srgio Luiz Tonsig

Pgina: 44

Anlise e Projeto de Sistemas II

4. Processo de Gerncia de Projeto

1
Objetivos
2
Planejamento
3
Organizao /
Coordenao
4
Avaliao
Progresso

do
5
Reviso
e
registro histrico

1. Defina os objetivos do projeto

Repetir
2.
3.
4.
5.

Planejar as tarefas para alcanar os objetivos


Organizar / Coordenar os recursos colocar as tarefas em execuo
Avaliar o progresso em relao ao plano at alcanar os objetivos
Revisar o planejamento, a organizao dos objetivos, conforme necessrio.
Registrar o histrico do projeto

FimRepetir

Prof. Srgio Luiz Tonsig

Pgina: 45

4.1.
O primeiro princpio de gerncia de projetos estabelecer um conjunto claro de objetivos
e requisitos do projeto, bem como obter informaes que permitam decidir sobre a

Objetivos tcnicos ou meta do projeto


Especificaes do produto, lista de padres aplicveis, restries assumidas

Prazos: sempre um fator limitante


Oramento: Quase sem um fator limitante

Muitas vezes, estas informaes para serem uma base segura sobre a qual seja possvel
estabelecer um contrato de desenvolvimento, devem estar reunidas em um documento,
Proposta de Desenvolvimento de Sistema.

Organizao da Proposta de Desenvolvimento de Sistema

antecipar respostas a perguntas que surgiro durante o desenvolvimento.


Contedo:

Descrio do sistema a ser desenvolvido, definindo seus objetivos, requisitos, as


necessidades e expectativas dos usurios bem como as vantagens do sistema proposto;

proposto

Prof. Srgio Luiz Tonsig

Pgina:

Anlise e Projeto de Sistemas II

Para que a proposta cumpra seu papel, ela deve ser:

Macroscpica, de forma a exigir um mnimo de detalhe;


Fidedigna, sem omitir ou exagerar fatos;
Imparcial;
Realista e vivel;

Em uma estrutura organizacional mais simples, a proposta de desenvolvimento acaba se


resumindo num documento interno do tipo Ordem de Servio, em outras organizaes
menores ainda, simples reunies com o desenvolvedor, de forma verbal, se elabora todo
este contexto acima exposto referente a proposta de desenvolvimento.

4.2. Planejamento

Um planejamento bem feito deve primeiro definir quais atividades devem ser realizadas
(O QUE), devidamente justificadas (POR QUE), em que ordem (QUANDO) devem ser
feitas, com que tcnicas (COMO), empregando quais recursos humanos (QUEM),
trabalhando em que lugar (ONDE).
Esta matriz O QUE x ( POR QUE, QUANDO, COMO, QUEM, ONDE), permitir
estimar QUANTO ser despendido em cada atividade, nas fases e no projeto como um
todo, em termos de TEMPO e CUSTO.
Na prtica, o planejamento no to cartesiano como aparenta. O grau de complexidade
e preciso depende do estgio em que se est planejando. Nos estgios iniciais, ele mais
simples e impreciso, nos estgios mais avanados mais complexo e detalhado. Ao longo
do desenvolvimento, o objetivo do planejamento um alvo mvel.
Portanto, segundo dizem, a nica certeza sobre um plano que as coisas no ocorrero
conforme planejado; ainda assim, tenha um plano, ruim com ele, muito pior ainda sem.

Prof. Srgio Luiz Tonsig

Pgina: 47

Anlise e Projeto de Sistemas II


Exemplo de Tabela de Planejamento

O
qu
Atividades

Por
Que ?

Quem
Far

Quando

Como
ferramentas e Quanto
mtodos
Custa ?

Onde

Quanto
Tempo ?

Outra forma de efetuar um planejamento a utilizao e um organograma, conforme


exemplo abaixo:
Publicar
Jornal
1
Obter
Verba

4
Encomendar
Des.Artstico

Comprar
Material

5
Fazer
Fotos

Produzir
Jornal

3
Comprar
Papel

Comprar
Mat.Foto

Produzir
Texto

7
Editar
Texto

Prof. Srgio Luiz Tonsig

Produzir
Verso Final

8
Revisar
Texto

Integrar
Des./Foto

Pgina: 48

Imprimir

Anlise e Projeto de Sistemas II


Exemplo de planejamento, utilizando aplicao de chaves

Obter Verba
Comprar Papel
Comprar Material
Comprar Mat. Fotogrfico

Encomendar Des. Artstico


Publicar
Jornal

Fazer Fotos

Editar Texto
Produzir Texto
Revisar Texto
Produzir Jornal
Produzir
Verso Final

Integrar Desenho
Foto
Imprimir

Prof. Srgio Luiz Tonsig

Pgina: 49

Anlise e Projeto de Sistemas II

Publicar Jornal
1. Obter Verba
2. Comprar Material
2.2. Comprar Mat. Fotogrfico
3. Encomendar Des. Artstico

5. Produzir Jornal
5.1 Produzir Texto
5.1.2 Revisar Texto
5.2 Produzir Verso Final
5.2.2 Imprimir

Exerccio: Fazer um DFD para expressar o planejamento de acordo com os exemplos

Pgina: 50

Anlise e Projeto de Sistemas II


Exemplo do planejamento com lista de atividades, incluindo durao e seqncia

Atividades
(a) Obter Verba
(b) Comprar Papel
(c) Comprar Material Fotogrfico
(d) Encomendar Desenho Artstico
(e) Fazer Fotos
Anterior
(a)
(a)
(a)
(c)
(f)
(e) (d) (g)
(b) (h)

(f) Editar Texto


(g) Revisar Texto
(h) Integrar Foto/Desenho
(i) Imprimir

Atividade
(a)
(b)
(c)
(d)
(e)
(f)
(g)
(h)
(i)

Posterior
(b) (c) (d)
(i)
(e)
(h)
(h)
(g)
(h)
(i)
-

Durao
3
2
1
7
3
5
5
1
1

Planejamento utilizando o diagrama de GANTT


ATIVIDADES
01
(a) Obter Verba
(b) Comprar Papel
(c) Comprar Mat.Fotog.
(d) Encom.Des.Artist.
(e) Fazer fotos
(f) Editar Texto
(g) Revisar Texto
(h) Integrar Desc./Foto
(i) Imprimir

Prof. Srgio Luiz Tonsig

02

03

04

05

06

07

08 09

10 11 12

Pgina: 51

Anlise e Projeto de Sistemas II

Atividades
(a) Obter Verba
(b) Comprar Papel

(g) Revisar Texto


(h) Integrar Foto/Desenho
i) Imprimir

(d) Encomendar Desenho Artstico


(e) Fazer Fotos

01

03

04

06

07

09

10

12

HUMANOS
(h)
EDITOR

(i)
(b)

(c)

(d)

(e)
(f)

REVISOR

Lembre-se que onde existe a numerao, pode-se trocar por Datas.

Prof. Srgio Luiz Tonsig

52

Anlise e Projeto de Sistemas II

4.3. Organizao / Coordenao


A tarefa de organizar pode ser vista como montar um time: dado um grupo de pessoas e
uma meta comum, qual o melhor papel para cada indivduo, e como as
responsabilidades devem ser divididas ? Como motivar estas pessoas ? Como gerar uma
sinergia ?
Veja como no existe a priore, respostas para estas questes, dissociadas de um contexto
onde aplica-las (pessoas com seus interesses, viso de mundo, qualificao, experincias
diferenciadas). Portanto, a tarefa de coordenao no fcil (para um tcnico, pior ainda,
se no tiver um mnimo de formao voltada para cincias humanas/administrativas).
Objetivos da Organizao / Coordenao
Combinar conhecimentos tcnicos de cada pessoa com as tarefas que ela vai realizar
Reduzir ao mnimo as horas ociosas das pessoas
Designar cada pessoa para apenas uma tarefa de cada vez
Obtenha no apenas o envolvimento, mas o comprometimento das pessoas

Prof. Srgio Luiz Tonsig

Pgina: 53

Anlise e Projeto de Sistemas II


Diferena entre envolvimento e comprometimento.
Na floresta, numa linha manh ensolarada, a coruja, a galinha e o porco se encontram:
CORUJA: Vamos fazer um omelete ?
TODOS: Vamos !!!
CORUJA: Bom, eu posso entrar com a frigideira .
A galinha pensou, pensou, pensou...
GALINHA: Eu posso entrar com os ovos.
CORUJA: Legal !
Por alguns segundos a coruja e a galinha entreolharam-se e simultaneamente, voltaram-se
ao porco...
GALINHA e CORUJA: Voc entra com o bacon...

Moral da estria: A galinha estava envolvida o porco comprometido.

Fatores Humanos
Tenha sempre em mente que as Pessoas so o mais importante recurso em projetos de
sistemas (s vezes o nico alm do tempo).
Sero tambm as pessoas que iro julgar a utilidade dos softwares desenvolvidos,
portanto, fundamental que se entenda um pouco de fatores humanos (psicologia da
personalidade, motivao, comunicao)
Aspectos chaves:
Trabalho em grupos pequenos
Liderana tcnica por competncia
Local de trabalho adequado
Benefcios:
Reduo de problemas de comunicao
Padro de qualidade
Aprendizado mtuo
Sociabilizao do trabalho

Prof. Srgio Luiz Tonsig

Pgina: 54

Anlise e Projeto de Sistemas II

Avaliao do Progresso

acordo com pontos de controles especificados (Milestones


Dois nveis de controle:

Informal

equipe; no gera relatrios.


Um controle informal efetivo, minimiza a freqncia e as sobrecarga (
reunies e relatrios.

) de

Requer relatrios peridicos gerados por revises sobre andamento do projeto.


Normalmente, so de dois tipos:
reunies realizadas em cada ponto de controle com todo o grupo
de desenvolvimento; gerando um relatrio de progresso (com a narrativa do ponto atual e

Revises Tcnicas voltadas para aspectos especficos dentro das etapas existentes,
objetivo eliminar problemas de transcurso, mantendo um registro sobre isto relatrio
tcnico.

Pgina: 55

Anlise e Projeto de Sistemas II

Exemplo de um projeto com pontos de controle

FASE
100
110

ATIVIDADE
Avaliao Preliminar
Estudo do Projeto

199
300
310
330
340
350

PONTOS DE CONTROLE

Fase 100 Concluda

Esboo das Funes do Sistema


Avaliao de Recursos Tecnolgicos
Anlise de
Reviso e Aprovao
Ponto de Reviso

Fase 300 concluda

DESENVOLVIMENTO
510
520
540
700
710

Projeto Lgico (
Comportamtal) Atividade 520 concluda
Projeto Fsico (Implementao)
Fase 500 concluda

Planejamento da Implantao
Teste Piloto

730
Instalao e Treinamento
740

Prof. Srgio Luiz Tonsig

Fase 700 concluda


(encerramento do projeto)

Pgina: 56

Anlise e Projeto de Sistemas II


Um exemplo de pauta para reunies referente as revises gerenciais
Que pode ser aplicada em qualquer momento dentro da evoluo do projeto:
01
02
03
04
05
06
07
08
09

Atividades Desenvolvidas
Fases e Atividades em curso
Problemas Encontrados
Solues Propostas
Atividades a serem desenvolvidas
Ocorrncia de Contingncias
Consideraes sobre os prazos
Providncias
Concluso da Reunio

Revises Tcnicas
Com relao as Revises Tcnicas, se prope:
01

Reviso de Requisitos
Motivao principal: Assegurar que, se os desenvolvedores construrem um
sistema que satisfaa os requisitos, ele satisfar as necessidades dos usurios.
Avaliao dos aspectos:
Incorreo:
requisitos que demandam algo que os usurios no querem.
Imcompleteza:
a especificao falha em dizer algo que algum usurio
necessita.
Ambigidade:
requisitos que so imprecisos a ponto de admitir muitas
possveis interpretaes.
Inconsistncia:
requisitos que se contradizem um ao outro

02

Reviso de design
O design satisfaz os requisitos ?
O design consistente ?
O design completo ?

Prof. Srgio Luiz Tonsig

Pgina: 57

Anlise e Projeto de Sistemas II


Fazendo parte deste elenco, aplicar
verificao)

(inspees para validao e

desenvolvimento. Na fase de anlise de requisitos, o objetivo a validao do sistema,


em geral envolvendo usurios.

Nas fases subsequentes, o objetivo a verificao do desenvolvimento, como pressuposto


de que os requisitos esto vlidos.

4.5
Revisar um projeto o processo de fazer mudanas a fim de resolver os desvios do
planejamento.

alvo mvel do projeto.


So cinco as boas razes usuais para se fazer reviso:
Perda de prazo para o trmino de tarefas
Tarefas mal feitas
Tarefas no realizadas
Mudanas imprevistas de pessoal
Corte de recursos inicialmente previstos

Prof. Srgio Luiz Tonsig

58

Anlise e Projeto de Sistemas II

5. BIBLIOGRAFIA
Kugler, Aguinaldo Aragon Fernandes & Kugler, Jos Luiz Carlos.
Gerncia de Projeto de Sistemas. Rio de Janeiro, LTC, 1990.

Martin, James & McClur, Carma.


Tcnicas Estruturadas e Case. So Paulo. Makron, 1991.

McMenamin, Stephen M. & Palmer, John F.


Anlise Essencial de Sistemas. So Paulo, McGraw-Hill, 1991.

Pompilho, S.
Anlise Essencial. Rio de Janeiro. Infobook, 1994.

Prof. Srgio Luiz Tonsig

Pgina: 59

Anlise e Projeto de Sistemas II

Prof. Srgio Luiz Tonsig

60