Analise de Sistemas

ANLISE
DE
SISTEMAS

PRONATEC/SEDUC-PI ANLISE DE SISTEMAS
2

3

PROGRAMA DE DISCIPLINA
ESCOLA OFERTANTE:

CURSO: TCNICO EM INFORMTICA

SEMESTRE: ANO:
DISCIPLINA: ANLISE DE SISTEMAS.
MDULO: 2
C/H TOTAL: 68h
C/H SEMANAL: 4h
I Objetivos
Conhecer as etapas para desenvolvimento de um software.
Conhecer as principais ferramentas de modelagem e estruturao de um projeto de software.

II Contedo
ANLISE DE SISTEMAS E A MODELAGEM DE SISTEMAS 10h
FERRAMENTAS DE MODELAGEM 6h
O DIAGRAMA DE CONTEXTO 8h
NIVELAMENTO E BALANCEAMENTO 8h
O DICIONRIO DE DADOS 8h
A ESPECIFICAO DOS PROCESSOS 12h
REGRAS PARA A CONSTRUO DE DFDS 16h

Metodologia
Aulas expositivas, tarefas e pesquisas bibliogrficas extraclasses e prticas de laboratrio
utilizando recursos computacionais (Hardware e Software) disponveis nos laboratrios didticos
de informtica;
Pesquisas em grupos e individuais;
Seminrios;
Avaliao
Provas escritas, seminrios, aulas prticas.
Nota valer de 0 (zero) a 10 (dez) pontos e para a aprovao ser necessrio obter nota igual ou
superior a 6 (seis) pontos e presena mnima de 75% das aulas.
III Bibliografia
Gane, Chris / Sarson, Trish - Anlise estruturada de Sistemas. Ed. LTC.
SILVA, Nelson Peres. Anlise e Estruturas de Sistemas de Informao. Ed. rica.
DENNIS, Alan. Anlise e Projeto de Sistemas. Ed. LTC.
WAZLAWICK, Raul. Anlise e Projetos de Sistemas Orientados a Objeto. Ed. Campus.
TONSIG, Sergio Luiz. Engenharia de Software: Anlise e Projeto de Sistema. Ed. Cincia Moderna.

4

Notas de Edio:

O assunto Anlise de Sistemas abordado nessa apostila baseado em vrios
trabalhos publicados nos Anais do Congresso XV Nacional de Informtica
Dependncias funcionais e dependncias de incluso: Aplicaes ao projeto lgico
de Banco de dado, Modelagem Conceitual de dado: da teoria pratica, A
integrao de dados e funes no desenvolvimento de sistemas, Modelagem
conceitual de dados: Uma comparao entre abordagens, todos de autoria
Severino Pompilho. Modificamos apenas as notaes utilizadasfazendoadaptaes
necessrias para facilitar o entendimento.
permitida a reproduo total ou parcial desse material, sem o pagamento de
direitos autorais, contanto que as cpias sejam feitas e distribudas sem fins
lucrativos. Vale salientar que os materiais foram adaptados para fins pedaggicos
no configurando assim tentativa de descaracterizao do material produzido pelos
autores.
Por fim, a equipe de elaboradores espera que a apostila ANLISE DE
SISTEMAS esteja dentro dos padres e necessidades dos alunos do
PRONATEC/PI.

5

Contedo
1 ANLISE DE SISTEMAS ................................................................................................................................ 6
1.1 introduo ................................................................................................................................................... 6
1.2Problemas no Desenvolvimento de Sistemas ........................................................................................ 6
1.4 Etapas desenvolvimento software ......................................................................................................... 11
1.5 O Perfil do Analista de Sistemas ........................................................................................................... 11
1.5.1 O Aprendizado e a Comunicao .................................................................................................. 13
2A MODELAGEM DE SISTEMAS .................................................................................................................. 18
2.1 Tcnicas de Levantamento requisitos de software ............................................................................. 20
2.1 O Ciclo de Vida do Sistema ................................................................................................................... 22
2.2 Metodologias de Desenvolvimento de Sistemas ................................................................................ 25
3. FERRAMENTAS DE MODELAGEM .......................................................................................................... 33
3.1 O diagrama de Fluxo de Dados(DFD) .................................................................................................. 33
3.1.1 O Conceito de Funo ..................................................................................................................... 34
3.2 O Fluxo de Dados .................................................................................................................................... 35
3.3Os Depsitos de Dados ........................................................................................................................... 36
3.4 As Entidades Externas ............................................................................................................................ 37
Identifique: ......................................................................................................................................................... 40
4 DIAGRAMA DE CONTEXTO ........................................................................................................................ 43
5 NIVELAMENTO E BALANCEAMENTO ..................................................................................................... 46
6 O DICIONRIO DE DADOS ......................................................................................................................... 52
6.1 Descries dos Fluxos de Dados .......................................................................................................... 53
6.2 Descrio dos Depsitos de Dados ...................................................................................................... 55
7 A ESPECIFICAO DOS PROCESSOS ................................................................................................... 58
7.1 Portugus Estruturado ............................................................................................................................ 59
7.2 Pseudocdigo ........................................................................................................................................... 62
7.3 Tabela de Deciso ................................................................................................................................... 62
7.4 rvore de Deciso ................................................................................................................................... 66
8 REGRAS PARA A CONSTRUO DE DFDS .......................................................................................... 68
9. REFERNCIAS .............................................................................................................................................. 78

6

1 ANLISE DE SISTEMAS

1.1 Introduo

O desenvolvimento de software uma atividade de crescente importncia na
sociedade contempornea. A utilizao de computadores nas mais diversas reas
do conhecimento humano tem gerado uma crescente demanda por solues
computadorizadas.
importante observar que, associada ao acrscimo da demanda, a evoluo
do hardware tem sido mais acentuadas, disponibilizando aos usurios mquinas
cada vez mais velozes e com maior capacidade de processamento. Neste contexto,
identificou-se, j na dcada de 70, uma situao crtica no desenvolvimento de
software, a chamada Crise do Software [Pressman], caracterizadapelos seguintes
fatos:
Demanda muito superior capacidade de desenvolvimento;
Qualidade insuficiente dos produtos;
Estimativas de custo e tempo raramente cumpridas nos projetos.
Visando melhorar a qualidade dos produtos de software e aumentar a
produtividade no processo de desenvolvimento, surgiu a rea de pesquisa
denominada Engenharia de Software.
A Engenharia de Software busca organizar esforos no desenvolvimento de
ferramentas, metodologias e ambientes de suporte ao desenvolvimento de software.
Dentre as principais atividades de um processo de desenvolvimento de software,
destaca-se a atividade de anlise e especificao de requisitos, na qual os requisitos
de um sistema so levantados e modelados, para s ento ser projetada e
implementada uma soluo (FALBO, 2002).

1.2Problemas no Desenvolvimento de Sistemas

O processo de informatizao das atividades administrativas de uma empresa
traz inmeras implicaes, que vo desde mudanas nas rotinas de trabalho at
reestruturaes organizacionais, com toda a problemtica que da, invariavelmente,
decorre.
7

Em certos casos, devido grande presso exercida pelos usurios, tenta-se
resolver o problema da informatizao atravs de uma viso mecanicista de
realidade. Esta soluo leva a tentativas de soluo, quase sempre, de natureza
instrumental, como acontece quando a direo da empresa convencida por um
fornecedor de hardware ou de software que lhe garante ser o produto, por ele
vendido, o remdio para todos os males que afligem a empresa. Isto, sem dvida,
no costuma dar certo, pois sabemos que a simples aquisio de tecnologia de
hardware ou de software no , por si s, suficiente para resolver certos
problemas que dependem fundamentalmente de um planejamento estratgico e
ttico, obviamente necessrio a uma boa administrao. Antes de escolher qualquer
produto, seja hardwareou software, temos de determinar quais so os sistemas de
que realmente a empresa necessita e quais so as suas caractersticas. Alis,
lembrando o filsofo Plato: Para a nave que no tem nenhum ponto de destino
qualquer vento bom (Embora possa haver alguma gratificao no movimento).
Em vista disso, a informatizao de uma organizao empresarial deve ter
como preocupao o conhecimento de todas as necessidades nos nveis
estratgicos, ttico e operacional, no apenas contempladas pelos sistemas atuais
mas tambm nos sistemas futuros sejam eles automatizados ou no. Portanto,
precisa-se de uma boa quantidade na especificao das necessidades, com
descries voltadas para a misso e os objetivos da organizao.
A tarefa de especificar os sistemas de informaes que compem uma
empresa uma das mais complexas e, em ltima anlise, um processo de soluo
de problemas. Para ser bem feita requer no apenas conhecimentos de
computaomas boa dose de vrios conhecimentos conexos, por seu carter
interdisciplinar.
A literatura de informtica cita uma srie de problemas de desenvolvimento de
sistemas que so a natureza tcnico-econmica, tais como: produtividade da equipe,
correo da especificao, confiabilidade do sistema, manutenbilidade do cdigo-
fonte, segurana dos dados, desempenho e portabilidade do sistema.
Evidentemente estes so problemas reais e importantes, que requerem um ateno
especial. A soluo para estes problemas est na adoo de um tratamento
sistemtico que viabilize, seno a sua eliminao, pelo menos a sua minimizao.
As metodologias de desenvolvimento de sistema com as que fazem uso das
tcnicas aqui apresentadas so um grande passo para resolver estes problemas,
8

como poder ser desejvel para os analistas de sistemas e a questo do
aprendizado e da comunicao.
Desde os primrdios da informtica, a instalao dos usurios com o
atendimento de suas necessidades de sistemas de informao causa de
transtornos para os profissionais da rea. Vrios autores internacionais
documentaram este fenmeno, valendo citar, por exemplo.
H evidncias e agrupamento tericos de que inadequao dos sistemas
comum, que os profissionais de informtica tendem, durante a fase de
desenvolvimento dos sistemas, a dar maior ateno aos aspectos relativos eficcia
ou adequao dos sistemas s necessidades dos usurios. Este tema costumava
ser relegado a um plano inferior e, infelizmente, essa ainda tem sido a regra em
algumas situaes, hoje em dia, Muitas vezes, encontramossolues brilhantes do
ponto de vista do desempenho da mquina, mas que no resolvem o problema do
usurio.
A conduta a ser adotada durante o desenvolvimento de sistemas deve ser tal
que conduza construo de sistemas efetivos, isto , sistemas que no sejam
apenas eficientes, mas tambm eficazes; que faam exatamente o que til e
necessrio para os usurios particularmente e para a empresa de modo global. Ou
seja, que no se d nfase apenas s preocupaes com o custo, mas que,
sobretudo, atente-se para aderncia do sistema s necessidades do usurio,
parmetro que serve para exprimir seu valor ou utilidade. Podemos dizer que entre
as razes pelas quais baixo o grau de satisfao dos usurios com os seus
sistemas automatizados sobressai inadequao da abordagem utilizada para a
fase de desenvolvimento para os usurios.
Entre as principais deficincias encontradas na maioria das abordagens
utilizadas no desenvolvimento de sistemas est o fato de elas enforcarem apenas
aspectos tcnico-econmicos em problemas que, normalmente, tm forte
componente psicossocial. Este , com frequncia e indevidamente, negligenciado.
Um claro exemplo das dificuldades enfrentadas pela tentativa de utilizao de
enfoque apenas tcnico-econmico est na proposta do uso de banco de dados
como fator de integrao de empresa. Tal proposta, embora muito atraente do ponto
de vista tcnico-econmico de difcil implementao pelo menos quando se quer o
preconizado na teoria. Note que estamos nos referindo a banco de dados como
ponto-chave da integrao dos sistemas, desde o seu nvel de especificao
9

conceitual, e no apenas como soluo de problemas de armazenamento de dados.
Isto acontece justamente porque um dos famosos donos do dado, o que, sem
dvida, no pode ser resolvido sem uma anlise do aspecto social da organizao.
Dados gerncias ou operacionais, quando representando informaes importantes,
so fontes de disputa de poder. Em razo desta constatao, apenas um
especialista em computadores.
A partir do advento dos microcomputadores, a tecnologia de hardwaree de
software evoluiu rapidamente, e hoje so oferecidas ao prprio usurio enormes
facilidades para o uso desses recursos. Em auxlio aos analistas, o avano
tecnolgico trouxe, entre outras facilidades, o surgimento dos softwares do tipo
CASE (Computer Aided Software Engineering) para apoio ao desenvolvimento de
sistemas. Estes softwares podem proporcionar um significativo aumento de
produtividade. Por tudo isto, fica cada vez mais evidente a necessidade de o analista
ter um perfil mais voltado para especificao dos requisitos do sistema e dos
negcios de empresa do que apenas para o conhecimento da programao e
operao de mquinas.

1.3 Sistemas de Informao nas Organizaes.

Sistemas de informao atualmente servem em todas as reas e nveis
dasorganizaes, sendo considerados como ferramenta essencial para o sucesso de
suas atividades. Isso nos permite classific-los de acordo com a responsabilidade
assumida por seus usurios dentro da organizao em quatro tipos principais
(LAUDON, 2001).
Sistemas de nvel operacional, que tratam da execuo, acompanhamento
e registro da operao diria da empresa, sendo geralmente sistemas
fortemente transacionais. Exemplos so sistemas de vendas, folha de
pagamento, etc.
Sistemas de nvel de conhecimento, que suportam as pessoas que
trabalham com dados e conhecimento dentro da organizao. Exemplos
simples de sistemas desse tipo so os processadores de texto e as planilhas
eletrnicas.
Sistemas de nvel gerencial, que utilizam dados da operao e outros dados
inseridos nesses sistemas para permitir a obteno de informaes que
10

permitam a gerncia da empresa, suportando a tomada de decises, o
controle e o monitoramento.
Sistemas de nvel estratgico, que so sistemas destinados a decises de
mais alto nvel (efeito estratgico) e utilizam dados de todos os sistemas
anteriores, normalmente de forma agregada e processada, sendo utilizados
pela alta gerncia (LAUDON, 2001).

Figura 1: Nveis dos sistemas de informao dentro de uma organizao (LAUDON, 2001, p.9).

Cada uma dessas perspectivas suportada por uma maneira de expressar a
realidade registrada por meio de um modelo que a descreve, segundo uma forma de
representao (POMPILHO, 2002).
Assim, considerando que uma organizao empresarial pode ser entendida
como sendo um sistema, ele pode ser bem compreendida se apresentarmos trs
modelos que, conceitualmente, a representam, a partir de trs perspectivas que se
complementam:
Um modelo funcional, que apresenta uma viso estruturada das funes ou
dos processos que compem a organizao;
Um modelo de dados, que apresenta uma viso dos dados que sero
armazenados para serem usados pela organizao;
Um modelo de controle, representando as transformaes de controle e
uma viso do comportamento da organizao em relao aos seus diferentes
estados vlidos, cada um dos quais sendo caracterizado por uma
determinada resposta fornecida quando a organizao estiver sujeita a certo
conjunto de estmulos.

11

1.4 Etapas desenvolvimento software

Um completo entendimento dos requisitos do software essencial para o
sucesso de um esforo de desenvolvimento de software. A atividade de anlise e
especificao de requisitos um processo de descoberta, refinamento, modelagem
e especificao. O escopo do software definido no planejamento do projeto
refinado em detalhe, as funes e o desempenho do software so especificados, as
interfaces com outros sistemas so indicadas e restries que o software deve
atender so estabelecidas. Modelos dos dados requeridos, do controle e do
comportamento operacional so construdos. Finalmente, critrios para a avaliao
da qualidade em atividades subsequentes so estabelecidos (FALBO, 2002).
Desenvolver software a atividade, de longo prazo, de criar um ou mais
programas de computador, um sistema, de forma a atender necessidades
especficas de um cliente ou grupo de clientes.
No desenvolvimento de software realizamos as atividades de descoberta das
necessidades e de criao do produto de software propriamente dito. Podemos
dividir as atividades do processo de desenvolvimento em alguns grandes grupos:
Atividades de Anlise, cuja finalidade descobrir o que deve ser feito;
Atividades de Projeto, cuja finalidade descobrir como o software deve ser
feito;
Atividades de Implementao, cuja finalidade produzir o produto de
software de acordocom as especificaes produzidas nas fases anteriores;
Atividades de Controle de Qualidade, onde se incluem todas as atividades
com objetivo de garantir a qualidade do produto, como testes e verificaes
(XEXO,2007).

1.5 O Perfil do Analista de Sistemas

Para ter boa probabilidade de sucesso o analista de sistemas deve possuir
uma formao que vai alm das disciplinas voltadas para o conhecimento de
computadores. No qual o seguinte conjunto de habilidade seria mais adequado para
o bom desempenho na atividade de anlise de sistemas de informao
administrativos:
12

Comunicao: entendida como capacidade para ouvir, redigir e expor idias
com clareza e preciso, aprender e expressar o contedo do aprendizado
com facilidade;
Capacidade de anlise: entendida como aptido para realizar operaes
mentais com abstraes sobre o recorte da realidade em estudo. Possuir
umaviso sistemtica e critica do contexto em anlise, alm de habilidade
para distinguir e conceituar categorias de significados de noes concretas e
abstratas associadas aos negcios da empresa;
Conhecimento da rea usuria: entendido, principalmente, como aquele
tipo de conhecimento que no pode ser obtido atravs de treinamento mas
adquirido por meio de experincia pessoal ao longo da vivncia com
operaes da empresa;
Capacidade de negociao: entendida como habilidade em obter resultado
desejado, ainda que em condies adversas, e capacidade de administrar
conflitos de interesses interpessoais que surjam durante o trabalho em grupo;
Administrao de projetos: entendido como noes sobre alocao de
tempo e recursos humanos, financeiros e materiais necessrios a projetos,
nos quais participam pessoas de formaes diferentes, num empreendimento
de caracterstica interdisciplinar, procurando sempre a efetividade, garantindo
no s a eficcia como tambm a eficcia do processo de obteno dos
resultados a serem alcanados;
Conhecimento Tcnico: entendido como capacidade de especificar sistemas
de informao, principalmente nas suas fases de nvel de abstrao mais alto,
utilizando ferramentas de modelagem, especialmente as adotadas pela
tcnica de anlise essencial. Pode ser til, ainda, o conhecimento das
estruturas lgicas do Sistema Gerenciador de Banco de Dados utilizados pela
empresa;
Os requisitos acima colocados constituem o perfil considerado por ns como
ideal. Reconhecemos, todavia, a dificuldade de se terem disposio
profissionaiscom essa capacitao. Para iniciar-se na atividade de anlise de
sistemas, no condio indispensvel a proficincia em todas as habilidades
mencionadas.
13

As funes de analista, projetista e programador so, s vezes, confundidas.
Para esclarecer este ponto, podemos dizer que, a rigor, o papel do analista de
sistemas especificar quais so os requisitos do sistema do ponto de vista eficcia,
ou seja, garantir que o sistema alcance os objetivos globais da empresa. Trata-se de
certificar-se de que o sistema far o que precisa ser feito, far o que certo ser feito,
independentemente da instrumentao que ser usada para chegar a esse objetivo.
Por sua vez, o projetista tem um papel voltado para eficincia, isto , voltando para a
obteno do melhor desempenho individual dos componentes do sistema. Por fim, o
papel do programador construir (implementar) o sistema de acordo com as
especificaes feitas pelo projetista.

1.5.1 O Aprendizado e a Comunicao

Para bem realizar a especificao de um sistema de informao, o primeiro
passo reconhecer que atividade de desenvolvimento de sistemas , em essncia,
um processo de soluo de problemas. E, como tal, esse processo compe-se em
de uma fase de aprendizado (entendimento dos requisitos dos sistemas) e outra de
comunicao (apresentao, da soluo encontrada para aprovao dos usurios).
Ambas as fases devem ser executadas, de modo interativo, por refinamentos
sucessivos, para se obter, por fim, o melhor resultado.
Normalmente, quando um analista inicia o desenvolvimento de um sistema,
ele sabe pouco ou quase nada sobre o sistema a ser desenvolvido. Portanto, o
desenvolvimento comea com uma fase de aprendizado. A obteno dos requisitos
necessrios ao sistema torna-se bastante dificultada, pois o usurio expe o seu
problema em linguagem natural, podendo ainda no ser capaz de expressar
adequadamente as suas necessidades. Isto pode resultar em problemas de
consistncia ou m interpretao, o que, sem duvida, ir acarretar erros
cujaaconsequncia poder ser muito cara. Por tudo isto, trata-se de uma tarefa
bastante delicada.
A fase do aprendizado de grande complexidade, e vrias so as teorias
sobre os mecanismos pelos quais ela se processa. Entre essas teorias, podemos
exemplificar:
Na primeira etapa, partimos da observao da realidade, tentando obter uma
viso global do assunto em estudo. Isto, na verdade, buscado atravs de um
14

processo no-estruturado e tem as caractersticas de uma coleta de conhecimentos,
que sero reunidos no tema abordado. a rigor um processo informal, atravs do
qual tentamos juntar todos os fatos relevantes a respeito do problema em questo e
descobrir os relacionamentos entre estes fatos. Geralmente, o analista, nesta fase,
de posse de todo o conhecimento coletado, tem dificuldade de separar o que
realmente relevante para o sistema.
Na segunda etapa(anlise), j partimos da viso global, obtida na fase
anterior. Nesta hora, o processo de aprendizagem passa pela construo de uma
espcie de maquete, o que consiste em identificar as variveis ou pontos-chave do
problema para construo de modelo simplificado com sua estrutura, com seus
elementos e relaes, possibilitando, destaque, que ai se faa, tendo como suporte
um modelo do problema. Ao final desta fase, o analista j tem uma idia do tudo e
de suas partes.
A ltima etapa ser, ento, aquela em que se iro propor hiptese de soluo
a serem adotadas. a etapa chamada sntese; ao final, tem - se idia de todo o
sistema, quais as suas partes e qual a soluo proposta para o problema. Cabe
assinalar que, diferentemente de algumas reas de cincia exatas, no estamos
tratando de um problema que tenha uma nica soluo correta, mas buscando uma
que seja aceitvel entre as solues possveis.
Como se pode observar, bastante complexo o processo de aprendizado.
Fica fcil entender porque se costuma errar tanto na hora de se prever um prazo
para o desenvolvimento de um sistema, especialmente o prazo para as primeiras
fases de especificao. muito difcil prever o tempo que algum vai levar para
compreender, com exatido, todos os requisitos de um sistema. Alm disso, o tempo
pare se aprender algum assunto varia muito de pessoa para pessoa. A capacidade
de aprender com eficincia tambm, em nossa opinio, uma habilidade considerar
da importante para os profissionais de desenvolvimento de sistemas. A
compreenso do domnio do problema a ser resolvido realmente um ponto crucial
da anlise de sistemas se compreendermos bem um problema j tem um grande
avano para a soluo.
Uma vez terminada a fase de aprendizado, entramos na fase de comunicao
com o usurio. Esta fase tambm tem fatores que dificultam. Os principais gargalos
num processo de comunicao ocorreram por conta de problemas das seguintes
naturezas:
15

Problemas psicolgicos: relacionados com percepo, ateno,
motivao, atitudes, memria, hbitos de pensamento;
Problemas semiolgicos: relacionados com o emprego de signos e
cdigos para comunicar: palavras, gestos, tom de voz, coisas escritas etc.
Problemas semnticos: relacionados com os significados das palavras,
dos objetos e das pessoas, assim como com sua interpretao;
Problemas sintticos: relacionados com a estrutura ou organizao dos
contedos e dos significados;
Problemas cibernticos: relacionados com retro informao e dilogo,
com a quantidade de idias transmitidas por diversos canais e com capacidade
destes para levarem sinais;
A literatura especfica de desenvolvimento de sistemas at que tem
reconhecido o problema da comunicao. Nesta literatura, tm sido apresentadas
vrias tcnicas, todas visando minimizar as dificuldades da comunicao entre os
desenvolvedores de sistemas e os usurios. Sabemos que o sucesso de um sistema
depender fundamentalmente de sua aceitao por parte do usurio. Para tanto,
devemos apresentar a soluo proposta a todos os que, de alguma forma, puderem
contribuir para a descoberta da soluo mais adequada ao ambiente no qual o
sistema ser implantado. Isto implica necessariamente de uma linguagem (forma de
expresso) comum a ser usada por profissionais de formaes diferentes, num
empreendimento de caracterstica interdisciplinar.

16

ATIVIDADE

1)Defina anlise de sistemas.

2)A anlise de sistemas um processo de transmisso de conhecimento e, assim
sendo, envolvem trs etapas, quais?

3)Qual a importncia da Anlise de Sistema para o desenvolvimento de Software?

4)De acordo com Pressman que fatos caracterizaram a chamada Crise do
Software?

5)De acordo com FALBO quais as principais atividades de um processo de
desenvolvimento de software?

6)Quais os principais problemas no desenvolvimento de sistemas ?

7)Como podemos classificar os Sistemas de Informao nas Organizaes?

8)Quais os Nveis dos sistemas de informao dentro de uma organizao? Explique
cada um deles.

9)Considerando que uma organizao empresarial pode ser entendida como sendo
um sistema, ele pode ser bem compreendido se apresentarmos trs modelos que,
conceitualmente, a representam, a partir de trs perspectivas que se
complementam, so eles :

10)Quais as etapas de desenvolvimento de software ?Especifique cada um deles.

11)Que habilidades seria mais adequado para o bom desempenho na atividade de
anlise de sistemas de informao por um analista ?

17

12)Diferencie as funes dos analistas, projetista e programador nas atividades de
analise de sistemas.

13)Para bem realizar a especificao de um sistema de informao, o primeiro
passo reconhecer que atividade de desenvolvimento de sistemas , em essncia,
um processo de soluo de problemas .Sobre a afirmativa incorreto afirmar que :

a)Esse processo compem-se em de uma fase de aprendizado (entendimento dos
requisitos do sistemas) e outra de comunicao (apresentao, da soluo
encontrada para aprovao dos usurios).

b)Normalmente, quando um analista inicia o desenvolvimento de um sistema, ele j
sabe tudo sobre o sistema a ser desenvolvido. Portanto, o desenvolvimento comea
com uma fase de soluo encontrada para aprovao dos usurios.

c)A obteno dos requisitos necessrios ao sistema torna-se bastante dificultada,
pois o usurio expem o seu problema em linguagem natural, podendo ainda no
ser capaz de expressar adequadamente as suas necessidades. Isto pode resultar
em problemas de consistncia ou m interpretao, o que, sem duvida, ir acarretar
erros cuja a consequncia poder ser muito cara.

d)Desenvolver software a atividade, de longo prazo, de criar um ou mais
programas de computador, um sistema, de forma a atender necessidades
especficas de um cliente ou grupo de clientes.

18

2 A MODELAGEM DE SISTEMAS

Desde que foi percebido pelos profissionais de informtica que grande parte
das deficincias nas especificaes de sistemas era devida problemtica de
comunicao, um esforo considervel tem sido realizado no sentido de se superar
este problema. Para tanto, construram-se vrias propostas metodolgicas, que
enfatizam a necessidade de uma linguagem a ser empregada pelos analistas de
sistemas, linguagem essa que pudesse ser compreendida tambm pelos usurios.
Dentro desta linha, desenvolveram-se linguagens que passaram a incluir os
recursos necessrios para definir as necessidades do usurio, independentemente
de qualquer restrio relativa implementao. Ou seja, linguagens de
especificao que,se tornem mais inteligveis ao usurio no-tcnico e por outro
lado, permaneam suficientemente precisas, para permitir que se produza uma
especificao que seja base para um subsequente projeto operacional dos sistemas
de informao necessrios.
Este tipo de linguagem deve possuir recursos que permitam produzir uma
especificao que possa ser apresentada ao usurio e com ele discutida. Um erro
muito comum no passado, entre os profissionais de informtica, era a crena de que
todas as necessidades de informaes seriam conhecidas apriori pelos usurios. A
prtica mostrou que isto no era verdade, o que faz com que est restrio deva ser
considerado com devido cuidado na soluo do problema da linguagem.
O fato do usurio no saber a priori todos os requisitos do sistema ser
construdo no uma caracterstica exclusiva de problemas da rea de
desenvolvimento de sistemas. Na verdade, isto comum em qualquer ramo de
atividades onde haja complexidade que exija especificao, na qual seja necessrio
mostrar claramente o que se quer construir, para que todos aqueles afetados pelo
produto final do trabalho possam certificar-se de que se est no caminho certo.
Duas abordagens complementares so bastante utilizadas sempre que nos
deparamos com problemas muito complexos. A primeira tentar decompor o
problema em subproblemas que possuam menor complexidade que o problema
original, no se esquecendo de utilizar um mtodo de decomposio que nos
garanta a possibilidade de, a partir dos subprogramas, reconstituir o todo.
evidente que se devem fazer parte integrante do mtodo o reconhecimento
e a descrio dos elementos de ligao entre os subprogramas constituintes do
19

todo. Assim, no caso do projeto de uma casa, poderamos dizer que ela se compe
de uma sala, trs quartos, dois banheiros, etc.
A outra abordagem consiste em decompor o problema no por partes, como
um mosaico, mais por pontos de vista diferentes. Nesta abordagem diramos que a
casa compe-se de planta de instalao eltrica, uma planta de instalao hidrulica
etc.., onde todas as plantas referem-se casa e no apenas uma das partes.
Novamente, a integrao entre os componentes do problema original se faz
necessria, visto que as plantas componentes da casa no podem ser tratadas
isoladamente. Por exemplo, o que aconteceria se, por falta de integrao, a planta
de instalao eltrica determinasse a passagem de um cabo eltrica justamente pelo
mesmo local onde a planta de instalao hidrulica especificasse a passagem de um
cano dgua?
O exemplo apresentando apenas tem por objetivo ilustrar algumas das
dificuldades enfrentadas na soluo de problemas complexos, e chamamos a
ateno do leitor para a utilidade de uma planta para descrever o projeto
mencionado, a qual possibilita a resoluo de algumas questes de natureza
tcnica, antes do incio da construo, o que se traduz em economia no custo total.
Os requisitos do futuro usurio da casa, quanto s suas necessidades, podero ser
discutidos fazendo-se uso da planta, o que ajuda a garantir a adequao do projeto
s necessidades do usurio. Desta forma, a planta funciona como um modelo
reduzido e mais barato da casa e serve ainda como mecanismo (leia-se, linguagem)
de comunicao entre tcnicos e entre usurios e tcnicos, pois, em problemas
complexos, a soluo ideal s ser alcanada se os tcnicos tiverem forte interao
com os usurios e, para tanto, um modelo do empreendimento dever ser produzido.
Do que foi expresso fica absolutamente claro que o exemplo da casa, antes
de se construir um sistema de informaes, deve-se elaborar um modelo que seja
capaz de expressar com a mxima fidelidade possvel o conhecimento que se tem
do ambiente onde o sistema ser implantado, de modo a satisfazer a todos os
requisitos necessrios. Se, por um lado, o custo de um sistema funo do
desempenho de seus componentes, por outro, o valor deste mesmo sistema
funo da utilidade que ele tenha para seus usurios. A boa tcnica de anlise dos
sistemas de uma empresa preconiza uma boa interao, vale dizer, comunicao -
entre os usurios e os tcnicos de informtica.
20

O principal produto da anlise so modelos que daro origem aos sistemas.
Entre as utilidades de um modelo, sedestaca as seguintes:
Estabelecer uma viso comum. (entre usurios e analista) do ambiente antes
da automao;
Servir como suporte para negociao e especificao de requisitos e
possibilidades futuras para o sistema;
Representar, avaliar e refinar conceitos do projeto;
Escalonar a informatizao em frases, com produtos bem - definidos e
dependncia mnima entre as fases;
Tratar a complexidade do problema por nveis de abstrao, comeando pela
viso mais abstrata e descendo a vises progressivamente mais detalhadas;
Promover indicaes quantitativas do escopo e da complexidade do
problema;
Prover facilidades para gerao de testes de aceitao;
Alm disso, sabe-se que, na especificao dos sistemas de informao,
devem ser consideradas diversas perspectivas do problema como nas diversas
plantas do exemplo da construo da casa. As modernas abordagens enfatizam a
perspectiva dos dados, no ignorando, entretanto, a importncia da perspectiva das
funes bem como a dos controles do sistema.
Cada uma dessas perspectivas suportada por uma maneira de expressar a
realidade registrada por meio de um modelo que a descreve, segundo uma forma de
representao.

2.1 Tcnicas de Levantamento requisitos de software

O incio para toda a atividade de desenvolvimento de software o
levantamento de requisitos, sendo esta atividade repetida em todas as demais
etapas da engenharia de requisitos.
Anlise e levantamento de requisitos so deextrema importncia serve para
um bomDocumento de Requisitos de Software possvel visualizar e interferir em
umsistema sem causar problemas aplicaoexistente. Alm disso, o esforo gasto
nalocalizao de qualquer tipo de modificaoouimplementao se torna aceitvel
(SOMMERVILLE, 2003).
21

Figura 2.1:disponvel em http://scott.yang.id.au/2003/08/software-development-life-cycle/

Sommerville (2003) prope um processo genrico de levantamento e anlise
que contm as seguintes atividades:
Compreenso do domnio: Os analistas devem desenvolver sua
compreenso do domnio da aplicao;
Coleta de requisitos: o processo de interagir com os usurios do sistema
para descobrir seus requisitos;
Classificao: Essa atividade considera o conjunto no estruturado dos
requisitos e os organiza em grupos coerentes;
Resoluo de conflitos: Quando mltiplos usurios esto envolvidos, os
requisitos apresentaro conflitos. Essa atividade tem por objetivo solucionar
esses conflitos;
Definio das prioridades: Em qualquer conjunto de requisitos, alguns sero
mais importantes do que outros. Esse estgio envolve interao com os
usurios para a definio dos requisitos mais importantes;
22

Verificao de requisitos: Os requisitos so verificados para descobrir se
esto completos e consistentes e se esto em concordncia com o que os
clientes desejam do sistema.
O levantamento e anlise de requisitos um processo iterativo, com uma
contnua validao de uma atividade para outra, conforme exemplificado pela Figura
2.2:

Figura 2.2: Processo de levantamento e anlise de requisitos (SOMMERVILLE, 2003)

2.1 O Ciclo de Vida do Sistema

Um sistema pode ser entendido como um mecanismo composto por um
conjunto de partes inter-relacionadas, onde cada parte est sempre relacionada a,
pelo menos, uma das outras.
Como toda linha de produo, o desenvolvimento de sistemas pode envolver
diversas fases. Ao encadeamento das fases para a construo do sistema
denominamos ciclo de vida de desenvolvimento de sistemas - H na literatura da
rea diversos enfoques propostos para o ciclo de vida de um sistema. Entre estes, o
enfoque em cascata e o da prototipao. Adotaremos para nossa explicao o
primeiro destes. Simplificadamente,toma-se como base um ciclo de vida de
desenvolvimento que ter as seguintes frases, na ordem apresentada a seguir:

23

ANLISE

IMPLEMENTAO

Anlise de sistemas ea fase do desenvolvimento em que se
determinaro quais os requisitos dos sistemas, o queo sistema deve fazer, em
termos essenciais. A fase de anlise tem por objetivo interpretar e definir uma
estrutura para um problema ainda no estruturado. Diz respeito eficcia do
sistema, ainda sem preocupaes de performance.
Por Projeto de Sistemas entenderemos a fase do desenvolvimento em
que se determinar como o sistema funcionar para atender aos requisitos
especificados na fase de anlise. Diz respeito eficincia do sistema, j com
preocupaes de performance. O objetivo desta fase modelar o sistema de
modo a implementar a soluo idealizada na fase de anlise, mas de acordo com
os recursos tecnolgicos existentes na empresa.
Por implementao de Sistemas entenderemos a fase do
desenvolvimento em que ser efetuada a construo do sistema de acordo com o
modelo de funcionamento especificado na fase de projeto. Faz uso dos recursos
tecnolgicos existentes na empresa para atividades como a programao de
computadores.
O ciclo de vida ilustrado acima um ciclo compulsrio. Todo o ciclo de
desenvolvimento de sistemas ter pelo menos estas fases. H quem inclua no ciclo
de desenvolvimento uma fase de estudo, anterior fase de anlise, e duas outras
fases aps a implementao: so elas a simulao e a implantao do sistema.
Neste caso, o ciclo de desenvolvimento ficaria assim:

PROJETO

24

Uma vez implantando o sistema, duas outras fases surgem: operao e
manuteno. Ao ciclo de atividades que inclui, alm das fases de desenvolvimento,
a operao e a manuteno de um sistema que podemos denominar ciclo de vida
do sistema, e faremos a seguinte figura:

Podemos ento dizer que um sistema, uma vez implantado, entra em
operaes e, at que seja desativado, poder sofrer manutenes, sejam elas
corretivas por acrscimos de novos elementos. Vale ressaltar que o
desenvolvimento de sistemas, na prtica, no ocorre de maneira to linear no tempo,
como possa parecer pela figura do ciclo da vida. Na prtica, possvel acontecer
uma certa superposio de fases, principalmente entre as consecutivas, ainda que
tal superposio deva ser reduzida. Por exemplo: pode ser que j se esteja na fase
de projeto e seja necessrio, por alguma contingncia, rever uma parte da fase de
anlise.
ESTUDO
ANLISE
PROJETO
IMPLEMENTAO
SIMULAO
IMPLANTAO
ESTUDO
ANLISE
PROJETO
IMPLEMENTAO
SIMULAO
IMPLANTAO
OPERAO
MANUTENO
25

2.2 Metodologias de Desenvolvimento de Sistemas

Para haver sucesso no desenvolvimento de sistemas, torna-se necessria a
utilizao de uma metodologia de trabalho.
Uma metodologia pode ser entendida como uma dissertao sobre a
maneira de se utilizar um conjunto coerente e coordenado de mtodos para atingir
um objetivo, de modo que se evite, tanto quanto possvel, a subjetividade na
execuo do trabalho.
Um mtodo pode ser entendido como um procedimento a ser adotado para
se atingir um objetivo. Para tanto, o mtodo se vale de um conjunto de tcnicas.
Uma tcnica pode ser entendida como sendo um modo apropriado de se
investigar sistematicamente um determinado universo de interesse ou domnio de
um problema. Para se expressar, uma tcnica faz uso de uma notao.
Uma notao um conjunto de caracteres, smbolos e sinais formando um
sistema a melhor maneira de se resolverem os problemas da atividade de
desenvolvimento. Deve ser definido o ciclo de vida do sistema adotado, ou seja,
quais as fases de trabalho a serem executadas. Uma boa metodologia deve tambm
apresentar definio clara de quem faz o qu, quando, como, e at
mesmo onde, para todos os que estejam envolvidos diretamente ou no com o
desenvolvimento de sistemas. Deve definir tambm qual o papel dos tcnicos de
informtica, o dos usurios e o da administrao da empresa no processo de
desenvolvimento. Alm disso, deve instituir um conjunto de padres
preestabelecidos, de modo a se evitar a subjetividade na abordagem, a fim de
garantir a facilidade de integrao de sistemas de desenvolvidos por grupos de
pessoas diferentes em pocas distintas. As tcnicas adotadas que devem ser
estveis, e no os tcnicos. Deve, assim, evitar um problema muito comum. Em
algumas instalaes: onde tcnicos se comportam como verdadeiros donos de
determinados sistemas, pois s eles os conhecem bem e s eles so capazes de
alter-los sem riscos, o que sem dvida indesejvel para a administrao da
empresa. Tudo isto permite uma maior mobilidade na alocao dos recursos-
humanos, materiais, financeiros e tempo- envolvidos na atividade e d condies
direo do projeto de melhor controlar o trabalho em curso.
26

Em face do que j foi dito, uma metodologia deve definir quais as fases de
trabalho previstas no desenvolvimento de sistemas. Para cada fase, quais as
tcnicas adotadas. So exemplos de tcnicas:
Anlise Estruturada;
Anlise Essencial e Projeto Estruturado.
A metodologia deve ainda, para cada tcnica adotada, definir quais as
ferramentas utilizadas. So exemplos de ferramentas:
Diagrama de Fluxo de Dados;
Diagrama de Entidade-Relacionamento;
Diagrama de Transio de Estados.
Cada ferramenta ir produzir um tipo de modelo. So exemplos de modelos:
Modelo Funcional
Modelo Conceitual de Dados;
Modelo de Controle.
A metodologia deve estabelecer ainda quais os pontos de controle e padres
de qualidade, alm da responsabilidade do pessoal envolvido nos controles e
mtricas.
Tais tcnicas fazem uso de ferramentas que do origem a modelos que
representam as principais perspectivas de um sistema. Entre estas, principalmente
nos ambientes de sistemas de informao administrativos, as ferramentas de
modelagem como as que so usadas em tcnicas do tipo de Anlise Estruturada e
Projeto Estruturado tornaram-se bastante conhecidas.
O quadro a seguir, apresentado em (IBPI, 1990), mostra as principais
ferramentas de modelagem utilizadas na fase de anlise de sistemas por trs
tcnicas:
Anlise de Sistemas

TCNICAS ABORDAGENS FERRAMENTAS

ANLISE
TRADICIONAL

*FUNCIONAL

*TEXTOS
*FLUXOGRAMAS

ANLISE
ESTRUTURADA

*FUNCIONAL
*DADOS

*DIAGRAMA DE FLUXO DE DADOS
*DIAGRAMA DE ESTRUTURA DE DADOS
*MINIESPECIFICAES
27

*NORMALIZAO
*DICIONRIO DE DADOS

ANLISE
ESSENCIAL

*FUNCIONAL
*DADOS
*CONTROLE

*TABELA DE EVENTOS
*DIAGRAMA DE FLUXO DE DADOS
*DIAGRAMA DE ENTIDADE-RELACIONAMENTO
*DIAGRAMA DE TRANSIO DE ESTADOS
*DIAGRAMA DE ESTRUTURA DE DADOS
*NORMALIZAO
*MINIESPECIFICAES
*DICIONRIO DE DADOS

O quadro anterior mostra tambm uma espcie de evoluo histrica das
tcnicas de anlise. O que estamos denominando por Anlise Tradicional a tcnica
que costumava ser usada para a fase de anlise, antes do surgimento da Anlise
Estruturada. Basicamente, produzia um documento que, alm de texto, usava, de
vez em quando, uma ferramenta bastante popular denominada fluxograma. A
abordagem usada era quase que exclusivamente voltada para a perspectiva das
funes do sistema.
Com o advento da Anlise Estruturada, como se pode notar, passou-se a
fazer um uso maior das ferramentas de modelagem, e a abordagem passou a
contemplar tambm a perspectiva dos dados, alm da perspectiva das funes.
Finalmente, a Anlise Essencial faz amplo uso das ferramentas de
modelagem e opta por uma abordagem que contempla tambm a perspectiva dos
controles, alm da perspectiva das funes e dos dados. Assim, medida que foram
evoluindo as tcnicas de anlise, maior quantidade de ferramentas de modelagem
passou a ser utilizada.
Embora as ferramentas de modelagem sejam extremamente importantes, por
razes diversas, na prtica, algumas empresas ainda relutam na sua adoo. A titulo
de exemplo vale mencionar que uma das queixas muito comuns entre os que
relutam em usar ferramentas de modelagem refere-se ao fator tempo. que, em
suas avaliaes, acreditam que, com a adoo destas tcnicas, o desenvolvimento
dos sistemas estende-se muito longamente. Segundo esses queixosos, fazendo-se
uso de mtodos mais tradicionais, chegar-se ao mesmo objetivo em tempo menor.As
vantagens do uso de ferramentas de modelagem so:
28

1)Identificar se o prazo para o desenvolvimento foi realmente mal estimado,
sendo que, neste caso, mesmo com mtodos tradicionais, no se teria acertado na
previso do tempo;
2) Os profissionais que atuam no desenvolvimento do sistema ainda no
dominavam a utilizao das ferramentas adotadas pela tcnica. Neste caso, a
suposta lentido se deve falta de proficincia dos tcnicos no uso das ferramentas;
3) O diagnstico que aponta perda de tempo distoro de parmetro. Isto
porque, com a utilizao de ferramentas que permitem um mecanismo rigoroso de
verificao, muitas situaes especficas de nveis mais altos-como: as fases
conceitual e lgica do sistema - foram corretamente analisadas. Ora, no se pode
comparar o tempo que tal anlise demanda com aquele que se consumiria nas
anlises realizadas pelos mtodos tradicionais, porquanto ai no teriam contemplado
uma srie de situaes que as ferramentas de modelagem apontam. Anlises mais
pobres podem at economizar tempo, mas no cobrem a riqueza de situaes que
se devem identificar em anlises extremamente mais abrangentes e aderentes ao
mundo real.
A chave do problema est, principalmente, no item (3). Via de regra, a
utilizao de mtodos tradicionais deixa escapar de sua anlise situaes que,
pouco tempo aps a implantao, fazem com que o sistema comece a sofrer
manuteno. Esta escolha pode ser enquadrada na categoria de solues de curto
prazo que acarretam problemas de longo prazo. Uma concluso importante, de tudo
quanto temos observado, diz que um sistema menos sujeito a necessidade de
manuteno quando mais altos, se fez uso de mtodos mais formais (menos
empricos), permitindo identificar, antecipadamente, problemas que s seriam
percebidos nas fases finais do desenvolvimento ou aps a implantao do sistema.
Outros problemas, tambm citados na utilizao de ferramentas de
modelagem, so o volume de documentao produzida e a dificuldade de mant-la
atualizada.
Quanto ao primeiro problema, podemos afirmar que, para o mesmo volume
de documentao, a utilizao de uma ferramenta de modelagem registra uma
quantidade de conhecimento (informao) maior do que a registrada por mtodos
tradicionais. Isto se deve, entre outros fatores, ao fato de as tcnicas de modelagem
fazerem uso de linguagens grficas (bidimensionais), enquanto que as tcnicas
tradicionais usam a linguagem textual (que linear). Alm disso, caracterstica da
29

prpria ferramenta de modelagem buscar a no redundncia de informaes, o que,
normalmente, no ocorre nos mtodos tradicionais.
Quanto dificuldade de se manter a documentao atualizada, cabe dizer
que, com qualquer tcnica que se use, isto sempre foi difcil. Todavia, com o
surgimento dos softwares para apoio ao desenvolvimento de sistemas (do tipo
CASE), esse problema foi bastante minorado.
No que diz respeito ao desenvolvimento de sistemas, vimos que a proposta
de se estabelecerem modelos para cada um dos aspectos ou perspectivas do
sistema pode ser de extrema utilidade. A dificuldade neste campo reside em se
decidir quais os aspectos do sistema a serem apresentados em uma especificao.
Dissemos que a maioria dos sistemas pode ter sua especificao bem
compreendida se apresentarmos trs modelos que conceitualmente representam o
sistema a partir de trs perspectivas que se completam: modelo funcional, modelo
de dados, e modelo controle. Os sistemas podem, ainda ser classificados de acordo
com a importncia relativa de cada um dos trs modelos para sua especificao.
Desta forma, poderamos classificar os sistemas em centrados nas funes,
centrados nos dados e centrados nos controles. verdade que haveria uma srie de
sistemas hbridos, os quais no seriam to claramente definidos assim. Para
exemplificar, chamaremos de sistema centrado nos dados aqueles cuja
precaues(na especificao e implementao) deve ser maior em relao aos
dados e seus inter-relacionamento do que em relao s operaes. As aplicaes
de robtica so um exemplo de sistemas mis centrado nos controles e processos,
enquanto que as aplicaes de consulta generalizada so o extremo de sistemas
centrados nos dados. O principal objeto de nosso estudo sero os sistemas de
informao administrativos cujas principais perspectivas so a das funes e dos
dados, especialmente esta ltima.
A tcnica da Analise Essencial tem como uma de suas fundamentais usar-se
os eventos como base para o particionamento dos sistemas. Assim sendo, em nosso
trabalho, mostraremos como efetuar a decomposio tanto das funes como dos
dados do sistema a partir dos eventos, garantindo, dessa forma, que o modelo de
dados e o de funes possam ser construdos simultaneamente, estando assim
integrados, por construo.
Podemos afirmar, sem receio de errar, que ao adotado a tcnica da Anlise
Essencial, como apresentada neste livro, o leitor poder produzir sistemas muito
30

mais efetivos, e em tempo hbil do que se usar qualquer outra tcnica tradicional.
Quando se tem o mtodo adequado para resolver um problema, facilmente se
encontra a soluo.
A tcnica da Anlise Estruturada Moderna. Para compreender os conceitos da
Anlise Essencial, necessrio antes conhecer como se elabora a Modelagem
Funcional e a Modelagem de Dados.

ATIVIDADE

1)Quais os principais objetivos dos modelos no desenvolvimento de sistemas?

2) Quais as fases do ciclo de vida de desenvolvimento de sistemas depois de
implantado?

3) Analise as seguintes sentenas sobre modelagem de sistemas . Quantas
sentenas esto incorretas
a )0 b)1 c)2 d )3
I. Um modelo enfatiza um conjunto de caractersticas da realidade, que corresponde
dimenso do modelo. Alm da dimenso que um modelo enfatiza, modelos
possuem nveis de abstrao.
II.O nvel de abstrao de um modelo diz respeito ao grau de detalhamento com que
as caractersticas do sistema so representadas.
III. Em cada nvel h uma nfase seletiva nos detalhes representados.
IV.No caso dos sistemas de informao, geralmente, so considerados trs nveis:
conceitual, lgico, fsico

4)Pesquise sobre o conceito dos seguintes nveis dos sistemas de informao.

5)No contexto de Metodologias de Desenvolvimento de Sistemas, podemos definir
que metodologia pode ser entendida como:
a)Uma dissertao sobre a maneira de se utilizar um conjunto coerente e
coordenado de mtodos para atingir um objetivo, de modo que se evite, tanto quanto
possvel, a subjetividade na execuo do trabalho.
31

b) Um procedimento a ser adotado para se atingir um objetivo. Para tanto, o mtodo
se vale de um conjunto de tcnicas.
c)Um modo apropriado de se investigar sistematicamente um determinado universo
de interesse ou domnio de um problema. Para se expressar, uma tcnica faz uso de
uma notao.
d)Um conjunto de caracteres, smbolos e sinais formando um sistema a melhor
maneira de se resolverem os problemas da atividade de desenvolvimento. Deve ser
definido o ciclo de vida do sistema adotado, ou seja, quais as fases de trabalho a
serem executadas.

6)Quais as tcnicas adotadas em uma metodologia para definir quais as fases de
trabalho previstas no desenvolvimento de sistemas?

7)Quais as ferramentas adotadas para definir a metodologia de Desenvolvimento de
Sistemas?

8)Quais as principais ferramentas de modelagem utilizadas na fase de anlise de
sistemas por as seguintes tcnicas:
a)Anlise Tradicional
b)Anlise Estruturada
c)Anlise Essencial

9)Quais as principais atividades executadas em um processo de levantamento de
requisitos de anlise de Software.

10)Quais as principais tcnicas de especificao?

11) Faa o relacionamento a seguir:
a)rvore de deciso
b)pseudocdigo.
c)portugus estruturado
d)Tabela de deciso
32

( )Uma forma textual alternativa, e mais popular, da se descrever mini espcies,
quase idntica ao portugus estruturado, porm mais prxima das linguagens de
programao.
( ) uma maneira de expressar, em forma de tabela, qual o conjunto de condies
que necessrio ocorrer para que um determinado conjunto de aes deva ser
executado.
( ) uma representao de uma tabela de deciso sob a forma de uma rvore.
Tem a mesma utilidade da tabela de deciso.
( ) Constitui-se em uma verso adaptada de nosso prprio idioma, com nfase em
algumas classes gramaticais (no caso, verbos, de preferncia no modo imperativo)
acrescida de construes tpicas das estruturas de controle existentes nas
linguagens de programao (sequncias, decises e repeties).

12)Como composto uma tabela de deciso em um DFD ?

13)Faa uma comparao entre as Tcnicas de especificaes abaixo ,para
descrever como elas so representadas em um DFD.

PORTUQUS ESTRUTURADO PSEUDOCDIGO

33

3. FERRAMENTAS DE MODELAGEM

Como parte dos requisitos do sistema e da atividade de projetos, o sistema
precisa ser modelado como um conjunto de componentes e de relaes entre esses
componentes. Frequentemente a modelagem de software usa algum tipo de notao
grfica e so apoiados pelo uso de ferramentas case.
Modelagem de softwares normalmente implica a construo de modelos
grficos que simbolizam os artefatos de software utilizados e seus inter-
relacionamentos. Uma forma comum de modelagem de programas procedurais (no
orientados a objeto) atravs de fluxogramas, enquanto que a modelagem de
programas orientados a objeto normalmente usam a linguagem grfica
UML(Linguagem de Modelagem Unificada) a qual os fabricantes lderes de
modelagem esto dando suporte. Na criao de sistemas com qualidade
necessrio a utilizao de uma boa metodologia para a modelagem tanto do
software, como de seu banco de dados. Algumas ferramentas j auxiliam na
automao da escrita de cdigo e na implementao da estrutura dos bancos de
dados. Os banco de dados so modelados atravs do modelo de Entidade
Relacionamento.O principal objetivo facilitar o projeto de banco de dados,
possibilitando especificar a estrutura geral do banco de dados. Funciona para
modelos conceituais relacionais, objeto-relacionais ou orientado a objetos. As
ferramentas de modelagem, surgiram para facilitar a criao dos modelos, as mais
avanadas permitem a gerao de uma parte do cdigo-fonte do software a partir do
modelo e at a gerao do banco de dados a partir do modelo de entidade
relacionamento.

3.1 O diagrama de Fluxo de Dados (DFD)

Uma importante perspectiva a ser descrita a respeito de um sistema de
informaes a de suas funes. Afinal de contas, todo sistema de informaes
armazena e transforma dados de entrada em dados de sada. Estas transformaes
so realizadas pelas suas funes.
Todo modelo funcional de um sistema pode ser visto como sendo formada
por uma representao grfica - uma rede de funes ou processos interligados-,
acompanhada de uma descrio de cada funo e das suas interfaces. A
34

representao grfica do modelo funcional costuma ser expresso atravs de um
diagrama denominado diagrama de fluxo de dados, abreviadamente, DFD.
Um diagrama de fluxo de dados uma forma grfica de mostrar a
interdependncia das funes que compem um sistema, apresentando fluxos de
dados entre elas. Mostra ainda os arquivos lgicos de dados, que so denominados
depsitos de dados, como veremos mais adiante, bem como as entidades externas,
denominao dada tanto origem dos fluxos de dados que chegam ao sistema,
como ao destino dos fluxos que delem partem.
Portanto, precisamos definir cada componente do DFD. Comearemos, na
seo seguinte, definindo o que vem a ser uma funo.

3.1.1 O Conceito de Funo

Idealmente, podemos definir uma funo de um sistema analogamente de
caixa-preta encontrando na literatura de algumas modalidades de engenharia. Uma
caixa-preta pode ser entendida como uma caixa onde:
h ligaes de entrada e de sada da caixa;
Conhecem-se os elementos de entrada da caixa
Conhecem-se os elementos de sada da caixa;
Sabe-se o que a caixa realiza (o que a caixa faz para que, a partir dos
elementos de entrada, sejam produzidos os elementos de sada);
No se precisa conhecer como a caixa realiza suas operaes e nem em que
ordem.
Desta forma, uma funo pode entendida como um componente de um
sistema onde somente os dados de entrada e os dados de entrada e os dados de
sada so conhecidos. No se conhece explicitamente nada a respeito do processo
interno de transformao dos dados de sada. As funes representam as aes que
o sistema executa. Ressalte-se que, em qualquer sistema de informaes, nem
todas as funes so automatizadas; sempre teremos funes que sero
executadas manualmente. Isto significa que devemos representar todas as funes,
independentemente de maneira como sero executadas. Convm enfatizar que
estamos falando de funes de transformao de dados. No texto deste livro,
usaremos s vezes, a palavra processo como sinnimo de funo.
35

3.2 O Fluxo de Dados

Imagine uma tarefa bem simples, como, por exemplo, o preenchimento
manual de um formulrio denominado NOTA DE DBITO. Neste caso, podemos
dizer que a funo a ser executada PREENCHER NOTA DE DBITO. Conforme
dissemos, para que a funo seja executada, necessria que haja dados de
entrada; no caso, um formulrio de nota de dbito em branco. A sada desta funo
ser uma nota de dbito preenchida. O diagrama a seguir representa esta situao:

Nota de dbito Preencher Nota de dbito
em branco nota de dbito preenchida

Na figura anterior, a funo est sendo representada por uma forma oval, com
uma seta de entrada e uma de sada. As setas esto representando o que
chamaremos de fluxo de dados de entrada e de sada. Esta denominao tem por
objetivo dar a idia de dados em movimento. Fluxos de dados so condutos que
levam informao de um ponto de sistema para outro; mostram como os dados
fluem atravs do sistema, o caminho percorrido pelos dados no sistema para outro;
mostram como os dados fluem atravs do sistema, o caminho percorrido pelos
dados no sistema. e no o suporte material onde um fluxo de dados representa um
conjunto de dados e no o suporte material onde identificamos o conjunto de dados.
Trata-se de fluxo de dados e no de fluxo de material. Portanto, no devemos
confundir a nota de dbito com o formulrio onde os dados so preenchidos.
Quando estamos escrevendo no fluxo de dados Nota de dbito estamos nos
referindo ao contedo do formulrio (os dados formulrio) e no ao formulrio em si.

Se acrescentarmos ao nosso pequeno sistema a funo DIGITAR NOTA DE
DBITO, teremos o seguinte diagrama:

36

3.3Os Depsitos de Dados

No DFD anterior, temos duas funes em sequncia, onde a sada da
primeira funo a entrada da segunda. Desta forma a entrada da funo DIGITAR
NOTA DE DBITO a sada da funo PREENCHER NOTA DE DBITO. Assim
sendo, para que a funo DIGITAR NOTA DE DBITO seja executada antes dela.
Podemos ento perguntar: para que a 2 funo seja executada, necessrio
que a 1 funo seja executada imediatamente antes? fcil responder que no,
pois, na verdade, o que precisamos para executar DIGITAR NOTA DE DBITO do
formulrio NOTA DE DBITO preenchido.
Evidentemente, podemos preencher um formulrio em um determinado
momento, guard-lo e, num tempo posterior, digit-lo. Queremos representar dados
que vo ficar armazenados como num arquivo.
Ao conjunto de dados armazenados denominaremos depsito de dados.
Constituem a memria do sistema. Note que, em vez de representar um
determinado conjunto de dados que estejam em movimento, o caso dos fluxos de
dados, devemos criar uma maneira de representar dados em estado de repouso.
Para tanto, usaremos a representao adiante.

Nota de
dbito

preenchida
Nota de dbito
em branco
Preencher
nota de dbito
Nota de dbito

digitada
Digitar
nota de
dbito
Nota de dbito
em branco
Preencher
nota de dbito
Nota de
dbito

preenchida
Digitar
nota de
dbito
Nota de
dbito

preenchida
Nota de
dbito

digitada
37

Uma das maneiras usadas para identificar num DFD os pontos de reteno
de dados, locais onde os dados esto armazenados, ou seja, os depsitos de dados,
atravs de duas barras paralelas, em posio vertical ou horizontal. Portanto, uma
determinada funo (PREENCHER NOTA DE DBITO) produz como sada um
determinado conjunto de dados. A seguir, uma outra funo (DIGITAR NOTA DE
DBITO) obtm (l) como dados de entrada o contedo do depsito de dados nota
de dbito preenchida e produz como sada um outro conjunto de dados (nota de
dbito digitada), que conduzido pelo fluxo de dados nota de dbito digitada. Vale
sublinhar que estamos nos referindo a depsitos de dados a no a arquivos fsicos.
Estamos nos referindo s estruturas de dados lgicas e no aos meios fsicos
(fichrios, arquivos magnticos etc.) que possam vir a ser usados na fase de
implementao para suport-las.

3.4 As Entidades Externas

At aqui, j vimos como representar uma funo, suas entradas e suas
sadas, bem como dados que devam ser armazenados para posterior utilizao.
Entretanto, todo sistema est inserindo em algum ambiente com o qual ele interage,
de onde partem os fluxos de dados de entrada e para onde vo os fluxos de dados
de sada do sistema. Mas o que se entende por ambiente?
Um ambiente de um sistema pode ser entendido como o meio externo ou
em torno do sistema. delimitado pelos elementos externos que exercem influncia
sobre o comportamento do sistema.
Se observarmos o pequeno sistema que descrevemos, podemos perguntar:
*De onde vem o fluxo de dados notas de dbito?
*Para onde vai o fluxo de dados nota de dbito digitada?
De modo a responder s perguntas acima, precisamos representar os
elementos externos, que enviam e recebem informaes do sistema. A esses
elementos denominaremos terminais ouentidades externas. So as fontes ou
destinos dos fluxos de dados que chegam e saem do sistema com o ambiente em
que ele est inserido. Uma entidade externa pode ser, por exemplo: um rgo ou
uma atividade de uma empresa ou entidade governamental, um outro sistema etc.

38

A ilustrao de tais elementos apresentada a seguir:

ARTAMENTO
DE
COBRANA Preencher Digitar
Nota de dbito nota de Nota de dbito nota de dbito nota de nota de dbito
em branco dbito preenchida preenchida dbito digitada

Na figura anterior, usamos uma das maneiras de representar as entidades
externas. No caso, quadrilteros, normalmente, retngulos ou quadrados.
A seguir, apresentamos um DFD um pouco maior onde se podem ver todos
os seus elementos componentes:

CLIENTE Lista de compras CADASTRAR
LISTA DE
DIRETORIA COMPRAS
LISTA DE COMPRAS Lista de compras
Lista
de item de compra
demanda

EMITIR
LISTA DE Produto PRODUTOS Produto CADASTRAR
DEMANDA PRODUTOS

Razo
social Lista de

FORNECEDORES Fornecedores CADASTRAR Pedido de FORNECEDOR
FORNECEDORES Cadastramento
Fornecedores

SISTEMA
DE
COBRANA

DEPARTAMENTO DE
COBRANA
RAZO
SOCIAL

LISTA DE
PRODUTOS
39

Atividade:
a)Quais os elementos componentes de um DFD?
-funes ou processos;
-fluxos de dados;
-depsitos de dados;
-entidades externas.

b) Um DFD apresenta componentes externos (terminais ou entidades externas) e
componentes internos (funes, fluxos de dados e depsitos de dados).

c) Um DFD apresenta componentes ativos (as funes) e componentes estticos
(depsitos de dados).

d) Um DFD pode ser visto como um modelo que apresenta as funes de um
sistema

e) As informaes de um sistema podem ser apresentar em termos estticos
(depsitos de dados) ou em movimento (fluxo de dados).

f) Um fluxo de dados liga:
-uma entidade externa a uma funo
-uma funo a uma entidade externa;
-uma funo a um depsito de dados;
-um depsito de dados a uma funo.
-uma funo a outra funo.

40

ATIVIDADE

1)Em analise de Essencial, como podemos definir o modelo funcional de dados?
2)No modelo funcional, que tipo de representao utilizada para representar suas
funes?
3)Quais os elementos componentes de um DFD?
4)Defina diagrama de fluxo de dados .
5)Qual o objetivo principal do Diagrama de Fluxo de Dados (DFD)?
6)O que representam os fluxos de dados de um diagrama de fluxo de Dados?
7)Nos Diagramas de Fluxo de Dados (DFD) , que tipo de notao utilizada para
representar seus componentes ?
8)Nos Diagramas de Fluxo de Dados (DFD) , o que so os Depsitos de Dados?
9) Que regras deveremos adotar para a construo de DFD?
10)De acordo com o DFD da figura abaixo:

Identifique:
a)Quais so os processos deste DFD? E quais so as entidades externais?
b)Quais so os depsitos de dados deste DFD? E quais so os fluxos de dados?
c)Existem fluxos de dados invlidos neste DFD? Quais so eles? Por que eles so
invlidos?
41

11) O que significa a seguinte afirmao: A continuidade do fluxo de informao
deve ser mantida entre os diferentes nveis de detalhamento (refinamento) de um
DFD?
12) Descreva o funcionamento do processo mostrado no DFD parcial dado a seguir

13) Verifique quais os erros existentes nos trechos de DFD a seguir

14) Identifique no DFD a seguir cada componente e tente, usando as denominaes
dadas aos componentes, avaliar seu objetivo

42

15) DFD diagrama de fluxo de dados: Analise o seguinte DFD e responda s
questes colocadas

a) com base no DFD representado, indique se este possui alguma incorreo de
representao.
b) refaa o DFD, com as correes que achar necessrias.
c) para o arquivo de dados clientes e a entidade FORNECEDOR descreva a
respectiva entrada de dados no dicionrio de dados.
43

SISTEMA DE
COBRANA
4 DIAGRAMA DE CONTEXTO

Se considerarmos que todo sistema est circunscrito a um universo de
interesse e que cada entidade extrema estabelece uma fronteira entre o sistema e o
ambiente em que ele est inserido, poderemos afirmar que uma nica possvel
representao de um sistema aquela em que ele apresenta como uma nica
grande funo, cercada pelas entidades externas que com ele interagem. Por
intermdio de fluxos de dados.
Para ilustrar esta idia, voltemos ao sistema que se suponha a produzir o
fluxo de dados nota de dbito digitada. Se observarmos a figura a seguir, podemos
com, por exemplo, uma linha dupla estabelecer a fronteira do sistema:

Preencher

Como consequncia, pode-se expressar tal sistema como o diagrama:

DEPARTAMENTO Obter SISTEMA
DE Nota de dbito nota de Nota de dbito DE
COBRANA em branco dbito digitada COBRANA

O diagrama anterior, que representa apenas um sistema e suas interfaces,
denominado Diagrama de Contexto.
DEPARTAMENTO
DE
COBRANA
Nota de dbito
em branco
Preencher
nota de
dbito
Nota de
dbito
preenchida
Nota de
dbito
preenchida
Digitar
nota de
dbito
Nota de
dbito
digitada
44

Se adotarmos o mesmo procedimento para o outro exemplo apresentado,
teremos:

CLIENTE Lista de compras CADASTRAR
LISTA DE
COMPRAS

DIRETORIA LISTA DE COMPRAS Lista de Compras
Lista De item
de compra
demanda

Emitir
Lista de produto PRODUTOS produto CADASTRAR
Demandas PRODUTOS

Razo
Social lista de
produtos

FORNECEDOR fornecedores CADASTRAR Pedido de FORNECEDOR
FORNECEDORES cadastramento de fornecedores

E chegaremos ao seguinte diagrama de contexto:

CLIENTE
Lista de Compras

DIRETORIA
Lista de fornecedor Sistema de Acompanhamento da
Demanda de Produtos
Lista de
produtos

Pedido de
Cadastramento de FORNECEDOR

Ao analisar as duas situaes mostradas, podemos concluir que:
a) O sistema Obter Nota de Dbito Digita pode ser decomposto em duas funes:
1)Preencher Nota de Dbito;
2)Digitar Nota de Dbito.
b) O Sistema de Acompanhamento de demanda de Produtos pode ser decomposto
em quatro funes:
1)Cadastrar Produtos;
45

2)Cadastrar Fornecedores;
3)Cadastrar Lista de Compras;
4)Emitir Lista de Demanda.

Como consequncia, podemos concluir que:
-Um DFD uma representao de um sistema sob a forma de uma rede que
mostra os componentes ativos do sistema e as interfaces de dados entre eles.
-Todo sistema pode, a partir do Diagrama de Contexto, ser decomposto em
diversas funes que se interligam. Note que as entidades externas no diagrama
expandido (DFD que apresenta as funes do sistema) so as mesmas do Diagrama
de Contexto, no qual, entretanto, so mostrados apenas os fluxos de dados que
representam a interface do sistema com as entidades externas.
-para cada funo do sistema, podemos aplicar esse mesmo prncipio e
decomp-la em funes mais simples, ou seja, subfunes.
Todo sistema pode ser representado como um grande processo, interagindo
como o ambiente em que est inserindo.Isto significa que a primeira viso de um
sistema o diagrama de contexto.
Como desenhar um diagrama de contexto?
Passo n1)Desenhar um nico processo ou funo para representar o
sistema inteiro.

CIA.
END- VIDA

Passo n2)Desenhar todas as entidades externas que se comunicam com o
sistema.

DEPTO.
PLANE-
JAMENTO
46

CLIENTE
CIA.
END- VIDADA

FORNE- DEPTO-
CEDOR FINAN-
CEIRO

Passo n3)Para cada entidade externa, desenhar o fluxo de dados que
mostra sua comunicao com o sistema

PAGAMENTO
CLIENTE
DEPTO.
PLANE-
CLIENTE PEDIDO JAMENTO
CLIENTE
CIA.. RELATRIO
FATURA-CLIENTE END- VIDADA FINANCEIRO

ENCOMENDA COMISSO DOS
VENDEDORES

FATURA DO
FORNECEDOR DEPTO.
FORNE FINAN-
CEDOR PAGAMENTO CEIRO
FORNECEDOR

H quem discuta se, em um Diagrama de Contexto, J poderiam aparecer
depsitos de dados ou no. Particularmente, preferimos no apresent-los neste
nvel. Acreditamos que em um Diagrama de Contexto deve-se representar apenas
um sistema e suas interfaces com as entidades externas.

5 NIVELAMENTO E BALANCEAMENTO

47

Do que nos foi apresentado at agora, somos levados a considerar que
estamos diante de um processo de decomposio sucessiva e hierrquica, que toma
a forma de uma rede onde cada n (funo ou processo) pai pode ser decomposto
em outra rede de funes filhas com os respectivos fluxos de dados e depsitos de
dados do nvel imediatamente inferior, e assim sucessivamente, at que no possa
mais ser decomposta. A funo que no possa mais ser decomposta denominada
funo primitiva, ou primitiva funcional. Trata-se de uma funo bsica ou
atmica - que no mais possa ser subdividida. Em resumo, todo DFD pode ser
decomposto em DFDs de nvel inferior, recursivamente, at alcanarem-se as
primitivas funcionais. Trata-se de uma fatorao hierrquica. A ilustrao a seguir
nos mostra esta situao.

E1 E3
FD1 FD7
SISTEMA Nvel
FD2 FD8 Contexto
E2 E4

SISTEMA
E1 E3
FD1
P2 FD7
FD5 Nvel 0
FD6 P4
E2 FD2 FD3
P1 FD4 P3 FD8 E4

P3

P2
FD6 P3.1 P3.3
Nvel 1
P1 FD4 P3.2
P3.4 FD8 E4

Apresentamos, inicialmente, um Diagrama de Contexto do sistema, onde:

-as entidades externas esto representadas por E1, E2, E3 e E4;
48

-os fluxos de dados so representados como FD1, FD2, FD7, e FD8.
No passo seguinte, exibido o primeiro nvel de particionamento do sistema, onde:
-os processos (funes) do sistema so representados por P1, P2, P3, e P4.
-alm dos fluxos de dados j apresentados, aparecem ainda FD3, FD4, FD5 e FD6
Em seguida, ilustrada a decomposio do processo P3,onde:
-aparecem processos com as denominaes P3.1, P3.2, P3.4.
- apresentado ainda um depsito de dados entre os processos P3.1 e P3.3.
-aparecem entidades externas com as denominaes P1, P2 e E4.
Algumas observaes se fazem necessrias:
a) Um sistema de tamanho razovel, normalmente, no deve ser modelado em nico
DFD, pois o modelo poderia ficar ininteligvel.
b)Para resolver este problema, so construdos vrios DFDs representando o
sistema em sucessivos nveis de detalhe, chamados nveis de abstrao. A esta
estratgia costuma-se chamar nivelamento. Na figura anterior foram apresentados
trs nveis de abstrao. Cada DFD representa o detalhamento (exploso) do DFD
de um nvel imediatamente superior. Uma maneira de identificar os nveis de
abstrao numer-los em ordem sequencial, tal como nvel zero, nvel 1, nvel 2,
nvel3 etc.
A abordagem em que efetuamos a decomposio do sistema, partindo do
diagrama de contexto (nvel mais geral) e descendo passo a passo a nveis mais
baixo (mais detalhados), denominada abordagem top-down. Foi a abordagem
preconizada pela tcnica de anlise denominada Anlise Estruturada, muito popular
desde o final da dcada de 1970 at meados da dcada de 1980. Uma outra
abordagem possvel, oposta top down, denominada bottom-up parte do nvel
mais detalhado para o nvel mais geral. Outras abordagens tambm conhecidas so
as denominadas outside-in, inside-out, ou ainda midle-out.
Numa decomposio do tipo top-down, possvel que, em um determinado
nvel algumas funes j sejam primitivas funcionais, enquanto outras ainda no o
so. Estas ainda daro origem a DFDs mais detalhados (de nvel mais baixo). Uma
imagem que pode ser adotada a de se considerarem as primitivas funcionais como
sendo tomos que ao se agregarem vo formar as molculas de uma substncia.
conveniente que, em cada nvel de abstrao, as funes estejam em grau
de detalhamento prximo, ou seja, no convm que em um dos nveis do DFD uma
das funes ainda precise ser decomposta em sub-funes de muitos nveis de
49

abstrao inferiores at chegar primitiva funcional, enquanto outras funes do
mesmo DFD j so primitivas. Cada DFD deve apresentar um nvel de detalhe
equilibrado. Os processos que tratam de rotinas de erros e de excees devem ser
expressos nos nveis mais baixos.
Para alguns autores, cada nvel de DFD deve ter de 5 a 9 funes. Segundo
os defensores desta idia, esta uma boa maneira de se tratar a complexidade do
sistema, visto que um DFD com inmeras funes tornar-se-ia de difcil leitura.
c)Sempre que ocorre particionamento, deve ser garantida a consistncia
entre as entradas e sadas de cada dois nveis de particionamento sucessivos. Em
outras palavras, h uma espcie de conservao de energia ou conservao dos
dados, no sistema. A esta necessidade costuma-se chamar balanceamento.
Ao particionar um processo, qualquer fluxo de dados, depsito de dados ou
entidade externa que aparea a ele ligado no nvel de cima tem de aparecer no DFD
do nvel imediatamente inferior.
Do ponto de vista de quem observa o sistema a partir do exterior, no pode
haver fluxos de dados de entrada ou de sada no nvel inferior que no existam no
de cima. Tanto no Diagrama de Contexto como no nvel imediatamente inferior,
temos os mesmos fluxos de dados servindo de interface entre o sistema e o seu
exterior, temos os mesmos fluxos de dados servindo de interface entre o sistema e o
seu exterior, ou seja F1, F2, F7, e F8. Da mesma forma, no particionamento do
processo P3, notam-se os mesmos fluxos de dados de entrada e sada, no caso,
FD6, FD4 e FD8.
d) Ao particionarmos um processo, como o caso de P3, uma boa conduta
reconhecer que, do ponto de vista de P3, os processos P1 e P2 so considerados
entidades externas. Esta conduta nos ajuda a garantir a consistncia entre os
diversos nveis de particionamento. Note que estamos chamando P1e P2 de
entidades externas, apenas em relao exploso do processo P3; mas no para o
sistema como um todo.
e)A maneira usada para expressar a correspondncia entre os nveis pais e
nveis filhos da especificao estruturada foi a designao numrica mostrando a
que diagrama pai corresponde um diagrama filho. Em consequncia, P3.1, P3.2 e
P3.3 so processo filhos do processo pai P3. Se, por exemplo, o processo P3.2
ainda no fosse uma primitiva funcional, seus processos filhos seriam numerados
50

por P3.2.1, P3.2.2, P3.2.3, e assim por diante. Ao analisar a figura anterior, trs
problemas afloram:
no lera)Qual o critrio de particionamento de uma funo que deve ser
usado?
Por ora, podemos responder que, luz dos conhecimentos atuais sobre este
assunto, o melhor critrio o de particionar uma funo de tal forma que nos DFD
resultante as sub-funes componentes tenham a mnima quantidade de interfaces
possvel. Voltaremos a este ponto mais tarde, quando, esperamos, este assunto
ficar mais claro.
b)O modelo das funes compe-se apenas de uma representao
diagramtica?
No. A especificao do modelo das funes (especificao funcional) inicia-
se com a decomposio do diagrama de contexto em sucessivos DFDs, cada vez
mais detalhados, at que se chegue s funes primitivas. Apenas os desenhos no
so suficientes para que se possa compreender o modelo das funes. Dessa
maneira, falta ainda descrever o contedo dos fluxos de dados e dos depsitos de
dados. Isto se faz atravs de uma linguagem de descrio apropriada para esta
necessidade, a qual veremos no momento oportuno. Por outro lado, ao de chegar s
funes primitivas, passa-se a especificar de forma descritiva, fazendo uso das
tcnicas estruturadas de especificao.
Em uma especificao funcional, apenas as descries das funes primitivas
so apresentadas e so chamadas miniespecificaes (miniespecs). Mais adiante
veremos como se faz isto.
c) At quando se deve continuar particionando as funes?
Poderamos dizer que cada n pai deva ser particionado em uma rede de ns
filhos at que o nvel desejado de detalhe seja alcanado, e ai estaramos diante de
funes primitivas. Entretanto, qual deve ser o nvel de detalhe desejado? Aqui
reside um problema, pois no h uma medida precisa sobre se uma funo ainda
deve ser decomposta ou no.Como regra puramente prtica, pode-se dizer que uma
funo primitiva aquela que:

51

-pode ser descrita em apenas uma pgina, quer esta pgina represente a
descrio de um pequeno procedimento manual ou um mdulo de um programa de
computador, ou;
-sua descrio, em pseudocdigo, no ultrapassa 50 a 100 linhas.
Para armazenar as descries mencionadas, necessrio um procedimento
especfico para este objetivo. Isto apresentado no captulo seguinte.

52

6 O DICIONRIO DE DADOS

Conforme dissemos, o modelo funcional composto de uma representao
grfica e uma descrio dos componentes do modelo-entidades externas, funes,
fluxos de dados e depsitos de dados. Logo, uma vez identificados os componentes
do modelo, devemos descrev-los. Para tanto, conforme proposto pela literatura,
usado um sistema, que vai guardar informaes sobre os componentes dos
sistemas. Para tanto, conforme proposto pela literatura, usado um sistema, que vai
guardar informaes (metadados) sobre os sistemas de nosso interesse,
denominado dicionrio de dados. Um dicionrio de dados um repositrio de
informaes sobre os componentes dos sistemas. Para descrever os componentes
de sistema, devemos adotar uma linguagem apropriada. Vrias formas podem ser
usadas para, por exemplo, apresentar os dados de um fluxo de dados. Utilizaremos
os seguintes smbolos:

SMBOLO SIGNIFICADO
= equivalente a
{ } Ou
*(min-max) Repeties
[ ] Opcional
@ Chave
% % Comentrio

53

6.1 Descries dos Fluxos de Dados

Seja mostrar a composio do fluxo de dados denominados FATURA-
CLIENTE de o DFD a seguir:

PAGAMENTO DO CLIENTE DEPTO.
CLIENTE PLANEJA-
PEDIDO-CLIENTE MENTO

RELATRIO
FINANCEIRO
CIA.
FATURA-CLIENTE END-VIDADA

ENCOMENDA COMISSO DOS VENDEDORES
FATURA DO
FORNECEDOR DEPTO
FINAN-
FORNE- PAGAMENTO AO FORNECEDOR CEIRO
CEDOR

fatura-cliente = NUM-FATURA
cod-cliente
ender-cliente
produto *(1-10)
VALOR-TOTAL-FATURA

produto = COD-PRODUTO
PREO-UNITRIO
QTDE-PEDIDA
VALOR-TOTAL-PRODUTO

ender-cliente = RUA
NMERO
COMPLEMENTO
NOME-BAIRRO
[CEP]
SIGLA-UF% sigla da unidade da Federao%
TELEFONE% telefone para contato, inclui DDD%

cod-cliente = {CPF-CLIENTE%CPF, se pessoa fsica ou %
CGC(cadastro geral contribuinte)-CLIENTE}%CGC, se pessoa jurdica %

Como se pode notar, foram usadas letras maisculas para identificar dados
elementares (que no podem ser decompostos), ao passo que foram usadas letras
minsculas para identificar os casos em que temos uma estrutura de dados (caso
em que temos, na verdade, um agregado de outros dados, como, por exemplo,
54

ender-cliente). Vale ressaltar que este tipo de procedimento recursivo, ou seja,
uma estrutura de dados pode ser decomposta,ou ainda, uma combinao dos dois.

A leitura da descrio nos d conta de que:
Fatura-cliente e ender-cliente so estruturas de dados, enquanto que
VALOR-TOTAL-FATURA e RUA so dados elementares;
Produto uma estrutura que pode ocorrer no mnimo uma vez at o
mximo de dez vezes em cada fatura-cliente;
No caso de CEP, vemos que foi definido como sendo um dado elementar
opcional na estrutura de ender-cliente;
Ao lado de SIGLA-UF foi colocada uma explicao para ilustrar o uso do
smbolo que expressa um comentrio;
para exemplificar a utilizao do smbolo que serve para expressar o caso em
que apenas uma das alternativas vlida, foi apresentada a definio de cod-
cliente que dependendo do tipo de cliente, pode ser identificado pelo CPFou
pelo CGC.
Pode-se imaginar um dicionrio de dados como um sistema de apoio
especificao do sistema em desenvolvimento, uma vez que todas as definies dos
componentes do sistema ali estaro armazenadas.
De maneira rudimentar, pode-se imaginar o dicionrio de dados como sendo
um fichrio que contm uma ficha para cada componente do sistema, como na figura
a seguir.

DICIONRIO DE DADOS

Fluxo de dados : Nome-cliente

Depsito de dados : Clientes

Dado elementar: Cidade

Estrutura de dados: Endereo
55

Por ora, estamos colocando no dicionrio de dados apenas os componentes
do modelo de funes. Todavia, para ser completo, ele deveria, ainda, conter os
componentes de dados e do modelo de controle, que veremos em prximos
captulos, alm de informaes adicionais que se fizessem necessrias. Como
dissemos, o dicionrio de dados deve ser um sistema que descreve o sistema de
nosso interesse. Hoje em dia, existem no mercado diversos sistemas automatizados
de dicionrio de dados, com inmeros recursos disponveis. O leitor no precisa se
preocupar em desenvolver um. Basta apenas conhecer o conceito e usar o que
esteja disponvel em sua instalao. Alm disso, com a evoluo dos softwaresdo
tipo CASE (Computer Aided Software Engeneering), que servem de apoio ao
desenvolvimento de sistemas, j se pode ter um auxlio bastante grande na tarefa de
documentao.

6.2 Descrio dos Depsitos de Dados

Seja o trecho de DFD mostrado na figura a seguir:

Gerncia
Operacional

Cadastrar Cadastrar
Loja livro

Loja Livro

Incrementar
Estoque

Sistema
de
Compras

Estoque Loja

56

Para descrever os depsitos de dados, usando-se a linguagem de descrio
de dados, por ns definida, teremos:
loja = NUM-LOJA
ender-loja

livro = @COD-LIVRO
TTULO-LIVRO
NOME-AUTOR-PRINCIPAL
NUM-EDIO
PREO-UNITRIO

estoque-loja = @NUM-LOJA
@COD-LIVRO
QTDE-EM-ESTOQUE
NVEL-DE-REPOSIO

ender-loja = RUA
NMERO
COMPLEMENTO
NOME-BAIRRO
[CEP]
SIGLA-UF% da unidade de Federao %
TELEFONE % telefone para contato, inclui DDD%

No se esquecer de que, como um depsito de dados representa um conjunto
de dados como se fora um arquivo(note que no estamos nos referindo a arquivos
fsicos do sistema, pois ainda no os protejamos nesta fase do desenvolvimento),
podemos imaginar os depsitos de dados como sendo compostos de registros com
as estruturas anteriormente definidas. Cabe ressaltar que para se ter acesso a cada
registro individualizado de cada depsito de dados foi usado o conceito de chave
de acesso, sendo usado o smbolo @para assinalar os elementos ou estrutura de
dados que tenham esse papel. Resulta da que a chave para acesso ao depsito de
dados livro COD-LIVRO; a chave do depsito loja NUM-LOJA, enquanto que a
chave para o depsito estoque-loja composta pela concatenao de NUM-LOJA e
COD-LIVRO, pois somente assim poderemos saber qual a quantidade de um
determinado livro em uma determinada loja.
Uma forma diferente e mais sinttica de apresentar a composio de um
depsito de dados ou de um fluxo de dados atravs de um conjunto de campos
(dados elementares ou estruturas de dados) separados por vrgulas, onde os
campos (dados elementares ou estruturas de dados) separados por vrgulas, onde
os campos que formam a chave dos depsitos esto sublinhados.
57

loja = {NUM-LOJA, RUA, NMERO, COMPLEMENTO, NOME-BAIRRO, CEP,
SIGLA-UF, TELEFONE}

livro = {COD-LIVRO, TTULO-LIVRO, NOME-AUTOR-PRINCIPAL, NUM-EDIO,
PREO-UNITRIO}

estoque-loja = {NUM-LOJA, COD-LIVRO, QTDE-EM-ESTOQUE, NIVEL-DE-
REPOSIO}

58

7 A ESPECIFICAO DOS PROCESSOS

Ao chegar ao nvel das funes primitivas, encontramo-nos diante do
problema de como descrever tais funes, com clareza e preciso. Alm disso,
temos de considerar que a descrio da funo primitiva dever ser lida pelos
analistas de sistemas e pelos futuros usurios do sistema em desenvolvimento, os
quais, no necessariamente, tm formao que permita entender, por exemplo, o
jargo tcnico da informtica. Portanto, no podemos usar a linguagemcomum, pois
notrio que tal opo d margem a toda subjetividade de quem descreve, com
todas as possibilidades de ser produzido um texto redundante, ambguo, confuso,
inconsistente e incompleto.
Para solucionar este problema, e lembrando que a descrio de uma primitiva
funcional no pode ser bem compreendida sem se ter idia do contexto em que se
acha inserida, devemos estabelecer algum balizamento sobre os seguintes
aspectos:
O que deve e o que no deve ser descrito;
Que tipo de tcnica deve-se usar na descrio.
Em relao ao primeiro aspecto, temos a considerar:

NaEspecificao dos Processos no necessrio repetir o que jfoi
definido nos DFDs e no dicionrio de dados, como o caso das descries
dos fluxos de dados e dos depsitos de dados, redundncia de deve ser
evitada, sempre que possvel;
Toda especificao deprocessos deve definir a forma pela qual os fluxos de
dados de entrada so transformados em fluxos de dados de sada,
independentemente do fato de a funo ser executada manualmente ou
por qualquer outra forma de implementao;
Em relao ao segundo aspecto, as principais tcnicas de especificao
so:
Portugus estruturado
Pseudocdigo
Tabela de deciso
rvore de deciso

59

7.1 Portugus Estruturado

Seja o trecho de DFD com a primitiva funcional a seguir, que representa uma
funo de um sistema escolar que executada ao final do perodo de aulas:

DISCIPLINAS

ALUNOS APROVADO

EMITIR
AVISO EM RECUPERAO
DE SITUAO
DO ALUNO

REPROVADO
AVALIAES-DE-ALUNOS

Sejam os seguintes os depsitos de dados:

ALUNOS = @MATR-ALUNO
NOME-ALUNO
ender-aluno

ender-aluno = RUA
NMERO
COMPLEMENTO
NOME-BAIRRO
[CEP]
SIGLA-UF% sigla da unidade da Federao%
TELEFONE% telefone para contato, inclui DDD%

AVALIAES-DE-ALUNOS = @MATR-ALUNO
@COD-DISCIPLINA
MDIA-FINAL

DISCIPLINAS =@COD-DISCIPLINA
NOME-DISCIPLINA
CONTEDO-PROGRAMTICO

Precisamos descrever qual o procedimento a ser adotado para emitir o aviso
sobre a situao do aluno. A tcnica que usaremos denomina-se portugus
estruturado e constitui-se em uma verso adaptada de nosso prprio idioma, com
nfase em algumas classes gramaticais (no caso, verbos, de preferncia no modo
imperativo) em detrimento de outras (normalmente adjetivos e advrbios, pois estas
60

classes do margem a confuses que devem ser evitadas em nome da clareza e
preciso) acrescida de construes tpicas das estruturas de controle existentes nas
linguagens de programao (sequncias, decises e repeties). Busca estabelecer
comunicao de alto nvel com o usurio, atravs de termos que lhe so familiares, e
Assim, teremos:

EMITIR AVISO DE SITUAO DO ALUNO

PARA CADA aluno no arquivo de alunos: (condies pr e ps-condies)

1. Coloque a matrcula, o nome e o endereo do aluno no formulrio de aviso.
2. PARA CADA cod-disciplina, cursada pelo aluno, existente no arquivo de
avaliaes:
2.1 Obtenha, a partir do arquivo de disciplinas, o nome da disciplina.
2.2 Obtenha, a partir do arquivo de avaliaes, a mdia final do aluno na disciplina.
2.3 Coloqueno formulrio de aviso o cdigo, o nome e a mdia final da disciplina
cursada pelo aluno.
3. Calcule o total de disciplinas em que o aluno obteve mdia final menor do que 5.
3.1 (CASO 1) nenhuma disciplina com mdia final menor do que 5.
3.1.1Coloque no formulrio com a expresso APROVADO.

3.2 (CASO2) mais de trs disciplinas com mdias finais menores do que 5
3.2.1Coloque no formulrio a expresso REPROVADO.
3.3 (CASO3) menos de quatro disciplinas com mdias finais menores do que 5
3.3.1 Coloque no formulrio a expresso EM RECUPERAO.

Como se pode observar, usamos aqui construes anlogas a estruturas
tpicas das linguagens de programao, como repetio (PARA CADA....), sequncia
(coloque, calcule etc...), e seleo (CASO1; CASO2;...). Esta ltima parte da
especificao tambm poderia ser expressa por estruturas ainda mais comuns nas
linguagens de programao, quando se quer exprimir a noo de seleo. E, ento,
poderamos ter algo parecido com o if-then-else, como o seguinte trecho:

3.Calcule o total de disciplinas em que o aluno obteve mdia final menor do que 5.
61

SE em nenhuma disciplina a mdia final foi menor do que 5,
Coloque no formulrio de aviso a expresso APROVADO.

SE NO, SE em mais de trs disciplinas houve mdia final menor do que 5,
Coloque no formulrio a expresso REPROVADO.
SE NO, Coloque no formulrio a expressoEM RECUPERAO

Como se pode ver, usamos uma tcnica de redao bastante estruturada, e
fizemos uso das construes que citamos e cuja sintaxe pode ser vista na tabela a
seguir:

SINTAXE PORTUQUS ESTRUTURADO
Sequncia de instrues Obtenha....;Calcule....;Coloque...;Co
pie...;etc...
Repetio de instrues PARA CADA... Faao que se segue:
Seleo entre instrues SE.... SE NO faa o que se segue:
CASO 1:...faa o que se segue:
CASO 2:...faa o que se segue:
.................................................:
CASO N:....faa o que se segue:

No se pode esquecer que, ao se especificar uma funo, fundamental
definir com clareza o objetivo dela. Por exemplo:

EMITIR AVISO DE SITUAO DO ALUNO

Objetivo: Emitir aviso a ser enviado para o aluno, indicando o desempenho
em cada disciplina,alm da avaliao global, que indica a sua situao em relao
ao perodo cursado.
Em resumo, o portugus estruturado consiste em:
Verbos no modo imperativo;
Termos definidos no dicionrio de dados;
Determinadas palavras reservadas para descrever a lgica da funo

62

7.2 Pseudocdigo

Uma forma textual alternativa, e mais popular, da se descrever fluxos, quase
idntica ao portugus estruturado, porm mais prxima das linguagens de
programao, o chamado pseudocdigo. Contm:
verbos (LER; OBTER; IMPRIMIR; GRVAR; etc.)
substantivos (elementos do dicionrio de dados)
estruturas de controle (SE; ENQUANTO; REPETIR; CASO)
operadores de relao (IGUAL; MAIOR QUE; MENOR QUEetc.)
Uma possvel comparao entre os dois modos de descrio apresentado
no quadro abaixo:
PORTUQUS ESTRUTURADO PSEUDOCDIGO
Orientado para os procedimentos Orientado para implementao
usa termos familiares ao usurio
(linguagem do negcio da empresa)
Lembra linguagem de programao
o objetivo um alto nvel de
comunicao
o objetivo facilitar a programao

Exemplo de uso de pseudocdigo:
EMITIR FATURAS-MENSAIS DE CARTES-DE-CRDITO

Inicializar programa (abrir arquivos, acertar contadores)
Ler registro-de-carto-de crdito
REPETIR-ENQUANTOexistam registros-de-carto-de-crdito
REPETIR-ENQUANTO existam itens-de-compra-no-carto-de-crdito
Calcular total-de-item
Somar total-de item ao total-da-fatura-mensal
FIM REPETIR
Calcular desconto
Calcular fatura-lquida; total-a-pagar
Imprimir fatura-mensal
Gravar faturano arquivo faturas
Ler registro-de-carto de crdito
FIM REPETIR
Terminar programa

7.3 Tabela de Deciso

Tabela de deciso uma maneira de expressar, em forma de tabela, qual o
conjunto de condies que necessrio ocorrer para que um determinado conjunto
63

de aes deva ser executado. Na tabela de deciso a denominada regra de
deciso, a qual define o conjunto de aes a ser tomado, apartir de um conjunto de
condies.
Formato de uma tabela de deciso:

CONDIES
Regra de
deciso1
Regra de
deciso2
...............
...............
Regra de
deciso
Condio1:
Condio2:
................
................
CondioN:

AES

Ao1:
Ao2:
..............
..............
..............
AoN:

Uma tabela de deciso composta de:
uma rea de condies, onde so relacionadas as condies que devem
ser verificadas para que seja executado um conjunto de aes.
uma rea de aes, que exibe o conjunto de aes que deve ser executado
caso um determinado conjunto de condies ocorra.
regras de deciso, representadas pelas colunas, apresentam a combinao
das condies com as aes a serem executadas.

CONDIES Regra de
deciso1
Regra de
deciso2
Regra de
deciso3
Regra de
deciso4
Condio1: S S N N
Condio2: S N S N

AES

Ao1: X
Ao2: X X
Ao3: X X X
onde S = sim; N = no; X = ao a ser executada.
64

Por exemplo, a tabela anterior lida da seguinte maneira:

Regra de deciso 1: caso as condies 1e 2 ocorram, devero ser
executados as aes1 e 3.
Regra de deciso 2: caso a condio 1 ocorra e a condio 2 no ocorra,
somente dever ser executada a ao 2.
Regra de deciso 3: caso a condio 1 no ocorra e a condio 2 ocorre
devero ser executadas as aes 2 e 3.
Regra de deciso 4: caso as condies 1 e 2 no ocorram, dever ser
executada somente a ao 3.
Uma das caractersticas importantes de uma tabela deciso a de se poder
determinar com exatido a quantidade de regras de deciso que far parte da
tabela. Isto se obtm a partir do produto do conjunto de possibilidades para cada
condio. Por exemplo: caso haja um conjunto de trs condies, onde cada uma
delas tenha duas possibilidades, teremos:
Condio 1: tem duas possibilidades

O que d um total de 2 x 2 x 2 = 8 regras de deciso. A tabela a seguir ilustra este
fato.

CONDIES
Regra
1
Regra
2
Regra
3
Regra
4
Regra
5
Regra
6
Regra
7
Regra
8
Condio1: S S S S N N N N
Condio2: S S N N S S N N
Condio3: S N S N S N S N

AES

Ao1: X X
Ao2: X X
.......... X X
AoN: X X X

onde: S = sim; N = no; X = ao a ser executada.
65

Seja a descrio de um processo que determina qual o tipo de exame mdico
peridico a que um empregado de uma determinada empresa deve ser submetido:

CONDIES
Regra
1
Regra
2
Regra
3
Regra
4
Regra
5
Regra
6
Regra
7
Regra
8
Ocupa cargo de
chefia?

S

S

S

S

N

N

N

N
Idade maior
que 40 anos?

S

S

N

N

S

S

N

N
Mais de 2anos
no cargo?

S

N

S

N

S

N

S

N

AES

Exame especial X X X X X
Exame normal X X X

onde: S = sim; N = no; X = ao a ser executada.
Seja um processo que visa decidir quais as aces a serem tomadas a
respeito de condicionamento fsico de, por exemplo, empregados de uma firma. Trs
condies so consideradas:

Condio 1:sexo: a ser preenchida com as letras:
M= sexo masculino
F = sexo feminino
Condio 2: altura a ser preenchida com as letras:
A= altura maior que 1,60m
B= altura at 1,60m
Condio 3: atividade fsica: a ser preenchida com as letras:
S= sedentrio
R= prtica atividade fsica mais de 3 vezes por semana
I= prtica atividade fsica mais de 3 vezes por semana

Portanto, teremos:

Condio1: tem duas possibilidades
Condio2: tem duas possibilidades
66

Condio3: tem trs possibilidades

O que d um total de 2 x 2 x 3 =12 regras de deciso. A tabela a seguir ilustra este
fato.
Uma vantagem do uso da tabela de deciso que, como podemos conhecer,
a priori, regras de deciso necessrias, temos como verificar se foram estabelecidas
as aes correspondentes a todas as regras de deciso

CONDIES R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12
Condio1: M M M M M M F F F F F F
Condio2: A A A B B B A A A B B B
Condio3: S R I S R I S R I S R I

AES

Ao1: X X
Ao2: X X X X
Ao3: X X X X
Ao4: X X X X X

7.4 rvore de Deciso

Uma rvore de deciso uma representao de uma tabela de deciso sob
a forma de umarvore. Tem a mesma utilidade da tabela de deciso. Trata-se de
uma maneira alternativa de expressar as mesmas regras que so obtidas quando se
constria tabela.
Seja a tabela de deciso da figura anterior. Neste caso, teramos a seguinte
rvore de deciso:

67

SEXO ALTURA ATIVIDADE AO
FSICA

S 4
A R 2 e 4
I 3
M
S 3
B R 2
I 2

S 3 e 4
A R 1
I 3

F
S 2
B R 1 e 4
I 4

Seja a especificao do processo de clculo do valor da conta de energia
eltrica. Uma rvore de deciso para expressar tal problema seria

consumo valor a pagar

de zero a 15KWH valor = R$11,00 x consumo

acima de 15kwth at 50kwh valor = (R$11,00 x 15) + R$19,00 x (consumo-15)

acima de 50KWH valor = (R$11,00 x 15) + (R$19,00 x 35) + R 32,00 x (consumo)

68

8 REGRAS PARA A CONSTRUO DE DFDS

A literatura referente construo de DFDs no apresenta um padro
de notao, havendo mesmo razovel variao quanto forma grfica a ser usada
para representar cada componente do diagrama. No Brasil, Tornaram-se mais
populares as formas grficas existentes nos livros das notaes mais populares e
descreveremos regras para a construo de DFDs, de acordo com os autores destas
notaes.

Em termos de notao, entre outras formas, para representar uma funo ou um
processo, comum usar:

a) um crculo; b)uma figura ovalada; c)um retngulo de
cantos arredondados

Em termos de notao, entre outras formas, para representar um fluxo de dados,
comum usar:

a)uma seta b)uma seta c)segmento de retas
em linha reta em linha curva ortogonais terminados
por setas

Em termos de notao, entre outras formas, para representar um depsito de
dados, comum usar:

69

a)duas retas b)um retngulo
paralelas aberto do lado direito

Em termos de notao, entre outras formas, para representar uma entidade
externa, comum usar:
a)um quadrado b)um retngulo

Como exemplo, podemos ter:

Em termos de notao, para representar um fluxo de acesso memria (depsito de
dados), comum usar :

70

a)Consultar b)incluir
(Ler) (Gravar)

c) Modificar d) Excluir

OBS: Em nome da facilidade de leitura do DFD, convenienteusar sempre a mesma
notao para cada um de seus componentes.
Muitas vezes, ao desenhar um DFD complexo, nos deparamos com a
possibilidade de cruzamento de linhas que representamos fluxos de dados, o que
dificulta o entendimento do diagrama. Para resolver esse problema, a sada costuma
ser repetio, em outro ponto do DFD, de algumas das figuras que representam os
seus componentes, da seguinte forma:

a)Para a duplicao de entidades externas, costuma-se acrescentar a o smbolo
tantas diagonais quantas forem as repeties utilizadas, como a seguir:

b)Para duplicao de depsitos de dados, costuma-se acrescentar ao smbolo
tantas linhas paralelas quantas forem as repeties utilizadas, como a seguir:

71

c)Nos casos em que for inevitvel o cruzamento de linhas, um expediente que pode
ser usado o desenhar um arco, como a seguir:

d)No faz sentido duplicar processos. Isto geraria confuso quanto ao entendimento
do diagrama.
Para ilustrar as situaes acima descritas, observar o DFD a seguir:

Como se pode notar. Para evitar o cruzamento de linhas de fluxo de dados
repetiu-se a entidade externa E1 e o depsito de dados D2. Para evitar o
cruzamento das linhas que representam os fluxos de dados D4 a P4 ede D5 a P3,
poderamos, ainda, repetir o depsito de dados D4. Desta forma, conseguiramos
evitar todos os cruzamentos de linhas. A figura a seguir mostra como ficaria o trecho
de DFD depois de modificado.

72

Orientao geral do leiaute de um DFD
a) O fluxo geral dos dados deve seguir uma orientao de cima para baixo e
da esquerda para a direita.

73

b) As entidades externas devem ficar, de preferncia, nas bordas do desenho:

c) Os depsitos de dados devem estar posicionados:
-se forem de entrada: esquerda ou acima da funo que recebe seus
dados;
-se forem de sada: direita ou abaixo da funo que lhe fornece
dados.

74

d) Os processos podem estar ligados:
-diretamente, atravs de fluxos de dados;
-indiretamente, com um depsito de dados entre eles.
O processo de origem deve ficar esquerda ou acima do processo de
destino.

Nomeao dos componentes do DFD
a) Nome de funo ou processo:
-deve ser formado por um verbo transitivo (significa a ao a ser executada) no
modo infinitivo seguido de um complemento;

-os nomes das funes no se confundem com os de seus executores;

-deve descrever o objetivo da funo;

-toda funo deve ser nomeada a partir da sada que ela produz;

75

-os verbos usados para denominar uma funo de transformao de dados no
podem ser ambguos ou muito genricos; portanto, no servem verbos tais como
controlar, gerenciar, processar, atualizar ou revisar etc.. Isto significaria que
no temos ainda uma idia precisa da ao a ser executada;

-verbos como produzir, emitir, cadastrar, extrair, criar, calcular, computar
so melhores para nomear uma funo;

-exemplos: Emitir lista de demanda ou Cadastrar fornecedores so bons nomes
para funes de transformao de dados. Observe que, em ambos os casos, temos
a idia exata do que vai ser produzido pelas funes. Por isso que costumamos
dizer que uma funo deve ser nomeada a partir do que ela produz; desta forma,
no corremos o risco de a nomearmos de maneira inadequada.

b) Nome de depsito de dados:

-usam-se substantivos simples ou compostos;

-como representa a memria do sistema, ou seja, arquivos, comun usarem-se
nomes no plural, para significar um conjunto de registros;

-representa uma estrutura de dados;

-exemplo:Podutos, Encomendas-do-cliente, Listas-de-compras, Fornecedores.

c)Nome de fluxo de dados:
-representa uma estrutura de dados;
-exemplo: Lista de demanda, Relatrio de vendas, Encomenda do cliente.

d) Nome de entidades externas:
-representa o conjunto de entidades (pessoas, coisas, rgos, sistemas etc.) do
ambiente externo que tem o mesmo tipo de interface com o sistema;
76

-exemplo: Cliente, Sistema de crdito, Fornecedor, Diretoria.

Consideraes gerais sobre DFDs

-Adotar os mesmos nomes utilizados pelos usurios.
-Manter padres grficos (forma, tamanho e estilo).
-Todos os fluxos de dados, depsitos de dados e processos devem ser nomeados
com preciso.
-Todos os nomes que aparecerem nos DFDs devem estar registrados no dicionrio
de dados.
-Equilibrar o cruzamento de linhas com repeties de componentes do DFD.
-Balancear fluxos dos DFDs com seus processos pai.
-Equilibrar nveis de decomposio de processos.
-Especificar todos os processos primitivos do DFD.
-Desenhar DFDs, de preferncia, entre cinco e nove processos.
-Cada diagrama deve ocupar apenas uma pgina.
-As pessoas que conhecem as funes do sistema devem aprovar o modelo
apresentado.

Consideraes especificas sobre DFDs

a)Em relao a processos
-Evitar associar nomes dos processos a seus executores.
-Evitar nomes de processos com verbos genricos.
-Todos os processos devem, de preferncia, ser numerados.
-Processos devem, de preferncia, ser numerados.
-Todos os dados devem, de preferncia, ser numerados.
-Processos devem ter sempre fluxos de dados de entrada e de sada.
-Todos os dados de sada de um processo devem ser derivados dos dados de
entrada.

b)Em relao a fluxo de dados
-Os fluxos de dados devem ser nomeados consistentemente atravs de todos os
nveis de DFD.
77

-Todos os fluxos de dados dos nveis superiores devem aparecer usados nos nveis
inferiores.

c)Em relao a depsito de dados
-Os depsitos de dados devem ser mostrados em todos os nveis em que forem
necessrios.
-Todo depsito de dados deve ter sempre fluxos de dados de entrada e de sada.
-Um depsito de dados surge nos DFDs na primeira vez quem estiver entre dois
processos.

78

9. REFERNCIAS

BORDENAVE, J.; Pereira, A; Estratgias de Ensino-Aprendizagem: Editora Vozes
2007.

FALBO, R; Anlise de Sistemas - Notas de Aula:UFES - Universidade Federal do
Esprito Santo, 2002.

IBPI, Apostila do curso Anlise Essencial; IBPI.

KENDALL, K.E; Systems Analysisand Design: Prentice Hall, 1992.

LAUDON, K.; Essentials of Management Information Systems:, 4th ed. Prentice
Hall, 2001.

MARCO, T.; Controlling Software Projects:Editora Press, 1990.

POMPILHO,S;Anlise essencial Guia prtico de Anlise de Sistemas: Editora
Cincia Moderna. 2002.

PRESSMAN, Roger S;Engenharia de software: So Paulo: Makron Books, 2003.

XEXO,Geraldo;Modelagem de Sistemas de Informao:Da anlise de
requisitos ao modelo de interface. Edio 2007.

Analise de Sistemas

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Analise de Sistemas

Enviado por

Direitos autorais:

Formatos disponíveis

ANLISE

Você também pode gostar