Anlise Estruturada

ANLISE ESTRUTURADA Contedos: *DIAGRAMA DE FLUXO DE DADOS *DIAGRAMA DE ESTRUTURA DE DADOS *MINIESPECIFICAES *NORMALIZAO *DICIONRIO DE DADOS O Perfil do Analista de Sistemas Ponderando o que dissemos at aqui, podemos concluir que, 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. E sim, um de habilidade seria mais adequado para o bom desempenho na atividade de anlise de sistemas de informao administrativos: 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 uma viso 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, tornando exeqvel o concurso de vontade em cooperao. 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. 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 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. Primeira etapa (sncrise): partimos da observao da realidade, tentando obter uma viso global do assunto em estudo. , 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. 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. Terceira etapa (sntese): A ltima etapa ser, ento, aquela em que se iro propor hiptese de 1

Anlise Estruturada
soluo a serem adotadas. Ao final, teremos uma 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.

A MODELAGEM DE SISTEMAS Na especificao dos sistemas de informao, devem ser consideradas diversas perspectivas do problema como nas diversas plantas do exemplo da construo de uma 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. Assim, considerando que uma organizao empresarial pode ser entendida como sendo um sistema, ela 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. U modelo de dados: que apresenta uma viso dos dados que sero usados pela organizao. armazenados para serem

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 um certo conjunto de estmulos. O Ciclo de Vida do Sistema Um sistema pode ser entendido como um mecanismo composto por um conjunto de partes interrelacionadas, onde cada parte est sempre relacionada a, pelo menos, uma das outras. Como toda linha de produo, o desenvolvimento de sistemas pode envolver diversas frases. Ao encadeamento das frases 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.

Anlise Projeto Implementao

Por Anlise de sistemas entenderemos a fase do desenvolvimento em que se determinaro quais os requisitos dos sistemas, o que o 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.

Anlise Estruturada

Estudo Anlise Projeto Implementao Simulao Implantao

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 podemos denominar ciclo de vida do sistema, e faremos a seguinte figura:

Estudo Anlis Projeto Implementao Simulao Implantao Operao

Metodologias de Desenvolvimento de Sistemas 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. 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 e Diagrama de Transio de Estados. Cada ferramenta ir produzir um tipo de modelo. Embora as ferramentas de modelagem sejam extremamente importantes, por razes diversas, na 3

Manuteno

Anlise Estruturada
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-ia ao mesmo objetivo em tempo menor. Nossa opinio a de que esto equivocados. A experincia nos tem mostrado, at agora, que, sempre que h suspeio de que o desenvolvimento de um sistema foi lento por ter havido o uso de ferramentas de modelagem, estamos diante de trs hipteses em que pelo menos uma verdadeira. So elas: 1) 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 abstracionais mais altos-como sejam, 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 no teramos 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 Modelagem Funcional
Lista de Eventos A Lista de Eventos mostra todos os estmulos que ocorrem a partir do ambiente e aos quais o sistema deve responder. Os eventos classificam-se em: Orientados a fluxo (F): quando transportam dados; Temporais (T): quando acontecem periodicamente; como se o sistema tivesse um relgio interno. Ex.: Recibos devem ser gerados s 16:00 horas Condicionais (C): quando acontecem devido verificao de uma condio pelo sistema. Ex: Se o stock for baixo emitir nota de compra ao fornecedor De controle (D): assncrono, imprevisveis Ex.: interrupes Mais utilizado em sistemas de tempo real. So usados para Sinalizar o sistema quando uma aco imediata necessria N Nome do Evento Descrio Estmulo Tipo do Estimulo Ao Resposta

Publicar Artigo

Usurio publica um artigo Public_art

Publicar Artigo

art_public

Revisar Artigo

Revisor confere artigo publicado

Revis_Public F

Revisar Artigo Expirar Artigos

Public_revis

hora de expirar artigos

Expira artigos cpiados

exp_art

Anlise Estruturada
O 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. Se adotarmos o mesmo procedimento para o outro exemplo apresentado, teremos:
Lista de Compras

Lista de Compras Diretoria

Lista de demanda Itens da Compra

Cadastrar Lista de Compras

Lista de Compras

Clientes

Lista de Produtos

Emitir Lista de Demanda

Razo Social

Produtos

Produto

Produtos

Cadastrar Produtos Fornecedores

Fornecedores

Fornecedores

Cadastrar Fornecedor es

Pedido de Cadastramento de Fornecedores

E chegaremos ao seguinte diagrama de contexto:

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; 2. Cadastrar Fornecedores; 3. Cadastrar Lista de Compras; 4. Emitir Lista de Demanda. Como conseqncia, 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.

Anlise Estruturada
-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 principio 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-Vidada

Passo n2: Desenhar todas as entidades externas que se comunica com o sistema.

CLIENTES

DEPTO. PLANEJ AMENTO

Cia. End-Vidada
FORNE CEDOR es DEPTO. FINAN CEIRO

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

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.

Anlise Estruturada
Diagrama de Fluxo de Dados (DFD) Um Diagrama de Fluxo de Dados (DFD) 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. 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 em Branco Nota de Dbito Preenchida

Preencher Nota de Dbito

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: Nota de Dbito em Branco Nota de Dbito Preenchida Nota de Dbito Digitada

Preencher Nota de Dbitos

Digitar Nota de Dbitos

Os 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, quard-lo e, num tempo posterior, digit-lo. Queremos representar dados que vo ficar armazenados como num arquivo. 7

Anlise Estruturada

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 em Branco Nota de Dbito Digitada

Preencher Nota de Dbitos

Nota de Dbito Preenchida

Digitar Nota de Dbitos Notas de Dbitos preenchidas

Nota de Dbito Preenchida

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 dada 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.

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 ou entidades 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. A ilustrao de tais elementos apresentada a seguir: Nota de Nota de Dbito em Dbito Preencher Digitar Branco Digitada Departamento Sistema de Nota de Nota de de Cobrana Cobrana

Dbitos

Dbitos

Nota de Dbito Preenchida

Notas de Dbitos preenchidas

Nota de Dbito Preenchida

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 8

Anlise Estruturada
componentes:
Lista de Compras

Lista de Compras Diretoria

Lista de demanda Itens da Compra

Cadastrar Lista de Compras

Lista de Compras

Clientes

Lista de Produtos

Emitir Lista de Demanda

Razo Social

Produtos

Produto

Produtos

Cadastrar Produtos Fornecedores

Fornecedores

Fornecedores

Cadastrar Fornecedor es

Pedido de Cadastramento de Fornecedores

Algumas consideraes: a) Os elementos componentes de um DFD so: -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.

Anlise Estruturada
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. Um dicionrio de dados um repositrio de informaes sobre os componentes do 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: Comentrio nulo; Peso = ** * peso do paciente * * unidades : quilogramas * * intervalo : 1-200 * EQUIVALENTE A ou COMPOSTO DE Significa E A =B+C Opcional endereo_cliente = (endereo-de-remessa) + (endereo-de-cobrana) Iteraes de (qualquer-ou) Pedido = nome-cliente + 1 {item} 8 *Nome do Cliente ter no mnimo 1 e no Maximo 8 interaes* Pedido = nome_cliente +1 {item} Pedido = nome_cliente + {item} Seleo (escolha uma das alternativas) Separador avaliao_crdito = [ O | B | P ] * O - timo * * B - bom * * P - protestado * avaliao_crdito = [O * timo* | B * bom * | P * protestado * ] Chave Identifica a chave primaria em um deposito de dados; Estoque-Loja = @NUM-LOJA @COD-LIVRO QTDE-EM-ESTOQUE NVEL-DE-REPOSIO

**

= + ()

{ }

[ ] |

Exemplos: Dicionrio de Dados do Fluxo: F1 Nome do Fluxo F1: Informar aeroportos em cidades @Cod_Aeroporto *Cdigo usado para classificar o aeroporto* Nome_Aeroporto *Nome do aeroporto a cadastrar*; Cidade_Aeroporto *Cidade onde esta o aeroporto*; Ou @Cod_Aeroporto + Nome_Aeroporto + Cidade_Aeroporto; Gerente P2: Cadastrar Aeroporto

Descrio:

Origem Destino

Dicionrio de Dados do Fluxo: F3 Nome do Fluxo F3: informar dados do vo @Numero_vo *Numero de referencia do vo*; Origem_Vo *Cidade de origem do vo*; Destino_Vo *Cidade de Destino do vo*; Ou @Numero_vo + Origem_Vo + Destino_Vo; Gerente P1: cadastrar vo 10

Descrio:

Origem Destino

Anlise Estruturada
Dicionrio de Dados da Entidade: Gerente Nome Entidade Gerente Nome_Funcionario *Nome do Funcionrio*; (End_ Funcionario) *Endereo do Funcionrio*; Cargo = [G *Gerente* | V *Vendedor* | E *Estoquista*]; Ou @Cod_Funcionario + Nome_Funcionario + (End_ Funcionario) + Cargo = [G *Gerente* | V *Vendedor* | E *Estoquista*] F14: Relatrio de Reservas F1: Informar aeroportos em cidades F3: Informar dados dos vos

Descrio:

Fluxo de Entrada Fluxo de Saida

Dicionrio de Dados do Depsito de Dados: D1 Nome do Depsito D1: Aeroporto Descrio: @Cod_Aeroporto Cdigo para Classificar o Aeroporto*; Nome_Aeroporto *Nome do aeroporto*; Cidade_Aeroporto *Cidade onde esta o aeroporto*; Ou @Cod_Aeroporto + Nome_Aeroporto + Nome_Aeroporto; F2: Grava informaes do aeroporto;

Fluxo de Entrada Fluxo de Sada

11

Anlise Estruturada
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. Em termos de notao, entre outras formas, para representar uma funo ou um processo, comun usar: a) um crculo; b)uma figura ovalada; c)um retngulo de cantos arredondados

usar:

Em termos de notao, entre outras formas, para representar um fluxo de dados, comum b)uma seta em linha curva c)segmento de retas ortogonais terminados por setas

a)uma seta em linha reta

comum usar:

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

a)duas retas paralelas

b)um retngulo aberto do lado direito

comum usar:

Em termos de notao, entre outras formas, para representar uma entidade externa,

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 :

12

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

c) Modificar

d) Excluir

OBS: Em nome da facilidade de leitura do DFD, conveniente usar 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 integilibidade 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:

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 repetiuse 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 e de D5 a P3, poderamos, ainda, repetir o depsito de dados D4. Desta forma, 13

Anlise Estruturada
conseguiramos evitar todos os cruzamentos de linhas. A figura a seguir mostra como ficaria o trecho de DFD depois de modificado.

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.

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.

14

Anlise Estruturada

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 (de acordo com C.Gane e T. Sarson [ref.11]):

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; - 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, atualizarou 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, comum usarem-se nomes no plural, para significar um conjunto de registros; - representa uma estrutura de dados; - exemplo:Produtos, Encomendas-do-cliente, Listas-de-compras, Fornecedores. c)Nome de fluxo de dados: - usam-se substantivos simples ou compostos; 15

Anlise Estruturada
- representa uma estrutura de dados; - exemplo: Lista de demanda, Relatrio de vendas, Encomenda do cliente. d) Nome de entidades externas: - usam-se substantivos simples ou compostos; - representa o conjunto de entidades (pessoas, coisas, rgos, sistemas etc.) do ambiente externo que tem o mesmo tipo de interface com o sistema; - 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. - 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. * * *

16