1.

Introdução

1. ANÁLISE

ESTRUTURADA

Para entendermos o que significa ¨ Análise Estruturada ¨ é interessante definirmos o que é Análise. Análise é um estudo de um problema, que antecede uma ação. O seu propósito é modelar um sistema de forma que ele possa ser entendido. Para falarmos sobre análise de sistema é bom termos uma idéia clara do que seja um sistema. É importante estar familiarizado com diferentes espécies de sistemas, pelo menos por dois motivos : • Primeiro, mesmo que seu trabalho como analista se concentre em um tipo de um sistema automatizado de informações, computadorizado - ele , normalmente fará parte de um sistema maior, por exemplo, um sistema de pagamento é parte de um sistema maior de ¨ Recursos Humanos ¨. Assim , para que o seu sistema tenha sucesso, é preciso conhecer os outros sistemas com os quais ele vai interagir. • Segundo, embora muitos tipos de sistemas pareçam ser totalmente diferentes, eles têm muitas semelhanças; existem princípios comuns , filosofias e teorias que se aplicam bem a todos os tipos de sistemas. Por exemplo , a lei da especialização, a qual diz que quanto mais adaptado for um organismo a um determinado ambiente, mais difícil será este organismo a adaptação a outro. Isso ajuda a explicar o desaparecimento dos dinossauros quando o clima da terra modificou-se radicalmente; ajuda, também , aos analistas de sistemas a compreenderem que se otimizarem um sistema computadorizado de forma a tirar a máxima vantagem de uma determinada UCP, de uma linguagem de programação, poderão vir a ter sérios problemas em adaptar o sistema para ser processado em outra UCP ou com um diferente sistema de gerenciador de Banco de Dados. O modelo da análise deverá descrever ¨ O que ¨ precisa ser feito, sem restringir ¨ O como ¨ será feito. Seu resultado deve ser o completo entendimento do domínio do problema que servirá de preparação para a fase do Projeto. No domínio específico do desenvolvimento de sistemas computacionais, análise refere-se ao estudo de alguma área de trabalho ou de uma aplicação, levando quase sempre à especificação de um novo sistema. A ação que tomaremos mais tarde é a implementação desse sistema. A Análise tem características bastante diferenciadas do trabalho de projetar, programar e depurar sistemas computacionais, sendo as relações interpessoais , particularmente as que envolvam usuários as mais complicadas e , algumas vezes até mesmo hostis. Análise e Projeto Estruturado I 1

1.

Introdução

O produto mais importante da análise de sistemas, é a documentação de especificação ( Especificação Funcional), isto é , o documento que estabelece os objetivos para o restante do projeto. Análise de Sistema é sob vários aspectos, a parte mais difícil do desenvolvimento de um sistema de processamento de Dados. Não é simplesmente a dificuldade política que surgem, especialmente em projetos maiores em que o sistema atenderá a muitos grupos, cujos interesses são as vezes conflitantes. É combinação de várias dificuldades que torna a Análise de Sistema tão difícil e exigente. Na análise de sistema as ferramentas de modelagem são utilizadas para : • • • Focalizar a atenção nas características importantes do sistema , dando menos atenção às menos importantes; Discutir modificações e correções nos requisitos do usuário com baixo custo e mínimo risco; Verificar se o analista conhece, corretamente, o ambiente do usuário e o documentou de tal maneira que os projetistas e programadores possam construir o sistema.

Os principais problemas da Análise de Sistema Tradicional tipicamente são : era necessário ler toda a especificação funcional, do princípio ao fim, para poder compreendê-la. • Eles eram redundantes a mesma informação era muitas vezes repetida em diversas partes diferentes do documento. o detalhamento dos requisitos do usuário podia • Eles eram ambíguos ser interpretado de modo diferente pelo usuário, pelo analista, pelo projetista e pelo programador. a especificação funcional quase sempre estava • Manutenção difícil absoleta no final do processo de desenvolvimento. • Eles eram monolíticos Enquanto todos problemas estavam sendo debatidos, um conjunto complementar de idéias já estavam sendo adotado na área de programação e projeto. Essas idéias, geralmente mencionadas como programação estruturada e projeto estruturado, prometiam grandes melhoras na organização, codificação, testes e manutenção. O problema era que tínhamos como projetar sistema altamente modulares e excelentes programas , mas na realidade eles podiam está calcados em cima de uma solução errada.

Análise e Projeto Estruturado I

2

1.

Introdução

1.1. •

Objetivos da Análise Estruturada

Os produtos de análise devem ter alta capacidade de manutenção, especialmente na documentação, isto aplica-se particularmente ao Documento Alvo; Os problemas quanto ao tamanho devem ser solucionados com a utilização de um método efetivo de particionamento; Gráficos devem ser usados sempre que possível; Diferenciar considerações físicas e lógicas , e distribuir responsabilidade; Construir um modelo lógico do sistema, de tal forma que o usuário familiarize-se com as características do sistema antes da implementação em si; Principais Problemas

• • • •

1.2.

1.2.1. Produtividade 1.2.1.1. Visível Invisível Desconhecidos Demanda Reprimida (Backlog) São os novos sistemas solicitados oficialmente pelos usuários e que foram aceitos. Sistemas que os usuários sabem que precisam, mas que não se dão ao trabalho de solicitar pelas vias “oficiais”. Sistemas que os usuários ainda não sabem que precisam.

Análise e Projeto Estruturado I

3

Projeto Estruturado. ao aperfeiçoamento ou a depuração Análise e Projeto Estruturado I 4 . à conversão.2. Manutenibilidade • Alteração de hardware • 50 a 80% dos trabalhos estão ligados à codificação.2. Técnicas para Diminuir o Backlog • Contratação de programadores e analistas.3. Confiabilidade • Erros de lógica na programação (3 a 5 a cada 100 comandos) 1. Introdução 1. Análise Estruturada. • Utilizar técnicas estruturadas : ¬ ¬ ¬ Programação Estruturada. • Deixar que os usuários desenvolvam seus próprios sistemas. • Utilizar ferramentas automatizadas ¬ Ferramentas CASE 1.1.2.1.2.1.

todos os outros detalhes ( isto é. as respostas para perguntas como : ¨ Quantos ?¨. Uma figura bem escolhida pode englobar uma imensa quantidade de informações de forma concisa e compacta. Discutir modificações e correções nos requisitos do usuário com baixo custo e mínimo risco. Geralmente usamos gráficos para identificar os componentes de um sistema e as interfaces entre eles.modelo bidimensional do mundo em que vivemos. O termo modelo pode soar um tanto formal. Deve ajudar prognosticar o comportamento do sistema. ¨ Em que seqüência ¨.1.1.representações esquemáticas de um edifício.modelo tridimensional do mundo em que vivemos.2. Análise e Projeto Estruturado I 5 . Características Necessárias Para Uma Ferramenta 2. . • • • • • Ser gráfica. 2. Existem muitos diferentes tipos de modelos que podemos desenvolver. os sistemas . O analista usa ferramentas de modelagem para : • • • Focalizar a atenção nas características importantes do sistema. . corretamente. Deve ter mínima redundância. na modalidade top-down. etc) são apresentados em documentos textuais de apoio. os documentos textuais devem servir como material de referência e ser consultado quando necessário. Deve permitir que o sistema possa ser visualizado de forma subdividida. FERRAMENTAS DA ANÁLISE ESTRUTURADA A maior parte do trabalho do analista envolve a modelagem que o usuário deseja. o ambiente do usuário e se o documentou de tal maneira que os projetistas e programadores possam construí-los. Verificar se o analista conhece. senão vejamos : Mapas Globos Desenho Arquitetônico . porém representa um conceito usual em nossa vida. Ferramentas da Análise Estruturada 2. Modelo Gráficos A grande vantagem dos modelos gráficos vem da justificativa de que ¨ Uma figura vale por mil palavra ¨.1. com adequado detalhamento textual de apoio. Deve ser transparente. dando menos atenção às menos importantes. Os gráficos devem ser o principal documento a que o usuário deverá recorrer para compreender o sistema. Os documentos textuais de apoio são a Especificação do Processo e o Dicionário de Dados.

Ao desenharmos um sistema. Evidentemente. pois caso haja modificação é muito mais garantido mantermos o modelo atualizado do que quando temos de fazermos múltiplas mudanças. Outra preocupação que deveremos ter é diminuirmos num modelo a redundância . o modelo deve ser modificado para podermos mantê-lo atualizado. O ideal é manter o modelo em uma forma correta e atual. preferiríamos modificar apenas um correspondente aspecto local do modelo. devemos utilizar uma ferramenta de modelo textual. Em conseqüência. analistas de sistemas ou programadores. devemos utilizar uma ferramenta de modelagem gráfica.2. E para mudarmos alguma coisa que seja intrinsecamente multidimensional. ou que elas sejam feitas de qualquer maneira. E isso significa que o modelo se tornará gradualmente menos correto. devemos de preferência considerar o aspecto local. Se o sistema se alterar. sem sermos forçado a alterar qualquer outro aspecto dele. 2.2. Análise e Projeto Estruturado I 6 .3. com muitas atividades sendo executadas ao mesmo tempo . O sistema pode ser : • estático (inalterado) • dinâmico. juntamente com um modo direto de passar de uma parte do modelo do sistema para outro. maior será a dificuldade para mantê-lo. existe uma boa possibilidade de que elas não sejam feitas . Na realidade.1. O modelo deve dar uma boa idéia dos principais componentes de alto nível e das interfaces do sistemas. Este método é de suma importância para os grandes sistemas. Modelo de Mínima Redundância Os modelos são representações de algum sistema do mundo real. será impossível para qualquer um . As ferramentas de modelagem devem permitir retratar partes individuais do sistema de uma forma isolada . pois quanto maior for a redundância que o modelo contiver . Ferramentas da Análise Estruturada 2. se somente um aspecto local do sistema for modificado. focalizar todo o sistema de uma só vez. tal como o fluxo de controle em um programa de processamento. Modelos Subdivisíveis em Modalidade Top-Down Uma boa ferramenta de modelagem deve retratar o sistema de forma subdividida top-down. Nem seria possível apresentar um modelo gráfico de um grande e complexo sistema em uma simples folha de papel . se forem necessárias múltiplas mudanças. sejam eles usuários . Ao modelarmos alguma coisa que seja intrinsecamente linear e seqüencial. As partes subsequentes forneceriam informações sobre componentes de baixo nível.1.

enquanto que as pessoas. O DFD retrata o sistema em termo de suas partes componentes . Ferramentas de Modelagem (DFD) (DER) (DTE) 2. as interfaces entre as partes são reduzidas ao mínimo. Diagrama de Fluxo De Dados O DFD é uma representação em rede de um sistema . enquanto o Fluxograma representa uma situação sob o ponto de vista do que age sobre os dados. máquinas e empresas que trabalham com dados dão uma visão de somente uma parte daquilo que acontece . Uma importante vantagem do DFD é deixar visível ao usuário quando a análise está errado. Análise e Projeto Estruturado I 7 . isto é.2. com todas as interfaces entre os componentes indicados.2. ao invés de apresentá-lo do ponto de vista de qualquer pessoa ou empresa.1. O DFD nos dá um particionamento muito benéfico do sistema. 2. oferecendo-nos um particionamento ¨ funcional ¨. Ferramentas da Análise Estruturada As três principais modelagens do sistemas são : • Diagrama de Fluxo de Dados • Diagrama de Entidade e Relacionamento • Diagrama de Transições de Estado Ao fazermos uma modelagem devemos descrever : • Que funções deve o sistema executar ? Quais são as interações entre as funções ? • Que transformações deve executar o sistema ? Que entradas são transformadas em saída ? • Que espécie de trabalho faz o sistema ? Onde ele obtêm as informações para fazê-lo ? Para onde ele remete os resultados do trabalho ? A ferramenta utilizada para transformar entrada em saída é o Diagrama de Fluxo de Dados. Esta é a diferença entre DFD e Fluxogramas.2. É bom frisar que o DFD mostra o Fluxo de Dados. manual ou misto . A vantagem desta abordagem é que os dados dão uma visão da imagem total. O sistema pode ser automatizado. O uso do DFD nos leva a apresentar uma situação do ponto de vista dos dados. isto porque o DFD mostra um gráfico global que fará com que o usuário sinta falta de algum processo que lhe seja familiar. não de controle. O DFD retrata uma situação sob o ponto de vista dos dados.

Este conjunto de definições estão no DD. depósitos de dados. para cada Depósito e para cada primitivo funcional. de fato.2. Então podemos dizer que existe uma entrada no Dicionário de Dados para cada Fluxo de Dados único que aparece em qualquer lugar do DFD.2. o DD não tem nenhuma utilidade.3. Especificação de Processo A Especificação de Processos deve ser expressa de forma que possa ser efetivamente expressa de forma que possa ser entendida pelos usuários e pelos analistas. Só quando todo elemento do DFD for rigorosamente definido é que o conjunto todo pode constituir uma ¨ especificação ¨. A notação de depósito de dados no DFD diz muito pouco acerca de detalhes de dados. É uma parte integrante da Especificação Estruturada . fluxos e entidades. As ferramentas utilizadas são : • Árvore de Decisão • Tabela de Decisão • Português Estruturado 2. 2. sem os DFD´s . EXEMPLO D 1 D a d o s d o L iv r o P ro cessa r P e d id o s S itu a ç ã o D 2 de C ré d ito s P e d id o C lie n te D ad os d o C lie n te F a tu r a s 2. Diagrama de Entidade-Relacionamento Embora o Diagrama de Fluxo de Dados seja. Os DFD´s e o DD devem ser considerados juntos.4. Sem o DD . uma ferramenta útil para a modelagem do sistema ele somente enfatiza um aspecto principal de um sistema : suas funções. Ferramentas da Análise Estruturada O Diagrama de Fluxo de Dados consistem em : processos . Dicionário de Dados Dicionário de Dados é um depósito de dados sobre dados.2.2.2. Análise e Projeto Estruturado I 8 . os diagramas perdem o rigor. sem o DD os DFD são apenas imagens que transmitem alguma idéia do que está acontecendo com o sistema .

2. 2. A ferramenta de modelagem que usamos para descrever esse aspecto do comportamento de um sistema é o Diagrama de Transições de Estado. entre os tipos do objetos. que informações está contida em cada depósito de dados. 2. Diagrama de Transições de Estado. em detalhes.6. Análise e Projeto Estruturado I 9 . a seqüência na qual se tem acesso aos dados e em que as funções serão executadas .2. Esse aspecto não está realçado pelo Diagrama de Fluxo de Dados . mas está ativamente retratado por uma outra ferramenta de modelagem : o Diagrama de Entidade-Relacionamentos. Um terceiro aspecto de muitos sistemas complexos é o comportamento tempodependente. O Diagrama de Estrutura é uma ferramenta de modelagem gráfica usada para representar uma hierarquia de software. podendo serem descritos por um ou mais fatos.2. Diagrama de Estrutura . Não querendo saber. O Diagrama componentes: de Entidade-Relacionamento possui dois importantes • Tipos de objetos que representam uma coleção ou objetos do mundo real.5. • Relacionamento que representa um conjunto de conexões ou associações . Eles podem ser identificados de forma única. Ferramentas da Análise Estruturada Todos os sistemas armazenam e usam informações sobre o ambiente com o qual interagem. mas também que relacionamentos existem entre os depósitos de dados.

Quando não é mais útil subdividir função lógica. As características de um DFD são : • • • • • Ser Gráficos Particionamento Multidimensionais Enfatizar Fluxo de Dados Não enfatizar controle Os Componentes de um Diagrama de Fluxo de Dados 3. Análise e Projeto Estruturado I Maria Auxiliadora Freire 10 . São categorias lógicas de coisas ou pessoas uma fonte ou destino para transações. Português Estruturado ou outras ferramentas.1. que fica fora do contexto do sistema. O DFD mostra as origens e os destinos dos dados ( e. DIAGRAMA DE FLUXO DE DADOS Diagrama de Fluxo de Dados é a ferramenta de modelagem de uma situação do ponto de vista dos dados. as fronteiras do sistema).1. identifica e denomina os Grupos de Elementos de Dados que ligam uma função a outra e identifica os Depósitos de Dados que elas acessam. o outro sistema é considerado entidade externa. Terminador / Entidade Uma entidade é uma pessoa ou empresa. 3.3. por implicação. Quando um sistema recebe Dados de um outro sistema ou fornece Dados a ele. Cada Função Lógica pode ser subdividida em um Diagrama de Fluxo de Dados mais detalhados. Cada Fluxo de Dados é analisado e suas estruturas e definições de seus Elementos de Dados componentes são armazenados no Dicionário de Dados. que é o originador ou o receptor de dados do sistema. identifica e denomina as Funções Lógicas.1. Diagrama de Fluxo de Dados 3. sua lógica externa de negócio é expressa utilizando Árvore de Decisões . A primeira coisa que realizamos com DFD é compor o retrato significativo de um sistema ou de uma parte de um sistema.

para tratá-los deve-se utilizar outra ferramenta de modelagem. Diagrama de Fluxo de Dados Aspecto Importante : • Entidades são externas ao sistema que estamos modelando. • O analista e/ou projetista não podem modificar o conteúdo de uma Entidade. A maior parte do Fluxo de Dados movimenta-se entre processos. Procure fazer Fluxos de Dados o mais reto possível e evite que eles se cruzem. as Entidades Externas são realmente parte do sistema e devem ser modeladas como processos 3. É claro que isso só será possível depois de se refazer o DFD várias vezes.3. utilizamos o símbolo de um vetor com um nome.1. • Se existirem relacionamentos entre Entidades Externas e for essencial que o Analista de Sistemas os modele para documentar de forma correta os requisitos do sistema. os fluxos que interligam as entidades dos diversos processos representam a interface entre o sistema do mundo externo. • Os detalhes procedurais a respeito de um processo não são tratados através de Fluxos de Dados. • Se o fluxo de dados está sem rótulo e está se dirigindo a um depósito. mas eles também podem fluir p/ dentro ou p/ fora de arquivos. como português estruturado. por definição. caso contrário revela erro. mas também para sabermos sobre os dados. Algumas convenções podem ser adotadas para notações de Fluxo de Dados: • Nomes ligados por hífens em maiúsculo. para mostrar a interface. 11 • Análise e Projeto Estruturado I . significa que toda a instância ( registro) está sendo introduzido ou retirado do depósito. Fluxos de Dados Um Fluxo de Dados retrata alguma interface entre componentes de um DFD. • Qualquer relacionamento existentes entre Entidades não será mostrado no DFD. por exemplo. Em todos os casos. • Nomes escolhidos para representarem não apenas os dados que fluem. então. O Fluxo representa dados em movimento.2.

Rotular os processos em termo de suas entrada / saída. Numerar os processos 12 Análise e Projeto Estruturado I . mas. • • O que o Fluxo de Dados não é : • Uma representação de fluxo de controle. Um processo é uma transformação do(s) Fluxo(s) de Dados de entrada em Fluxo(s) de Dados de saída. O Processo pode ser representado em Círculo ou Retângulo Arredondado dividido em três áreas : • nome do processo deve dar idéia do que faz o processo . mostram algum trabalho executado em cima dos dados. Processo Os processos. quando isso ocorrer. invariavelmente. rotule de modo a identificar as funções que o sistema executa. certamente estará faltando um processo entre os dois. Diagrama de Fluxo de Dados • Cuidado com os Fluxos de Dados sem nome. pode-se estar omitindo o nome do Fluxo simplesmente porque não se conseguiu encontrar um nome satisfatório. Ás vezes. • • • • Ao escolher nome de um processo evite usar nomes de pessoas . 3.1.3.3. para que tenhamos êxito em transmitir a imagem total com o DFD. fluxo de consciência do computador ou da pessoa que processa os dados. às vezes. isso deve ser evitado. Um Fluxo não deve ligar uma entidade externa a um depósito de dados. o nome foi omitido por que a informação do nome é óbvia. Reparticione para evitar processo sem nomes. Os Fluxos de Dados que chegam e saem de entidades externas representam as interfaces do sistema com o mundo externo.

Deve-se utilizar terminologias que sejam compreensíveis por um número maior de pessoas. Temos a tentação de utilizar nomes vagos como FAZER SERVIÇO. Diagrama de Fluxo de Dados • Um bom nome de processo geralmente é composto por uma frase constituída de um verbo e de um objeto. Os termos ROTINA. Isto torna o DFD muito pessoal. Isso ocorre tanto para os processos quanto para os fluxos que eles descrevem. Por exemplo : Calcular Valor do Imposto. MANIPULAR ENTRADA e PROCESSAR DADOS. • • • • • Análise e Projeto Estruturado I 13 . Deve-se evitar geração espontânea. SUBSISTEMA e FUNÇÃO geralmente não têm significados no mundo do usuário. Muitas vezes isso significa que o Analista de Sistemas não está bem certo de qual função está sendo executada. processos que têm saídas mas não tem entradas. Validar Entrada.3. A menos que você ouça os usuários utilizarem estas palavras em conversas entre eles mesmos. Deve-se evitar poços sem fundo. evite-as nos DFD. Existe uma tendência natural por parte dos usuários em utilizar as abreviações e siglas que lhes sejam familiares. processos que têm entradas mas não tem saídas. Receber Pedidos.

O processo indica através do Fluxo de Dados onde está armazenado os dados ou lendo dados. prevendo que eventualmente o usuário poderá querer consultá-las ( prevendo assim uma necessidade futura do usuário ). Diagrama de Fluxo de Dados 3. Um Depósito pode existir por um requisito básico do usuário ou por um aspecto de implementação : ¬ Um depósito que é requisito básico do usuário estará no sistema por que o usuário necessita deste depósito independente da tecnologia que está ou será utilizada. MERCADORIAS.1. Depósito de Dados Lugar onde necessitamos definir dados como armazenados entre processo (depósito temporário de dados). ♦ o Analista de Sistemas resolveu armazenar as informações. caso seja necessário especificar o argumento de pesquisa. ¬ Um depósito de implementação existe quando : ♦ não há memória suficiente no computador para acomodar vários processos ao mesmo tempo. este pode ser ilustrado de lado oposto da descrição do Fluxo de Dados.4. necessitando-se de um depósito para possível recuperação de informações. ♦ dois processos que utilizam as mesmas informações serão implementados por grupos de programadores diferentes. • Análise e Projeto Estruturado I 14 .3. ♦ a configuração de hardware não é totalmente confiável. CLIENTES. que são Normalmente o nome escolhido para identificar o Depósito é o plural dos pacotes transportados pelos fluxos para dentro e para fora do Depósito. O Depósito de Dados existe como uma necessidade de armazenamento entre os dois processos que ocorrem em momentos diferentes. Por exemplo : PEDIDOS. Considerações importantes a respeito de Depósitos de Dados : • • Os Depósitos de Dados só são mostrados dentro da divisa criados / processados apenas por este processo.

uma alteração ou ainda uma eliminação. • Níveis intermediários. os fluxos de dados mostram as interfaces entre o sistema e as entidades externas.1. representando o sistema inteiro. N. é a parte não particionada. Os fluxos que saem e chegam a Depósitos só podem transportar informações que o depósito pode aceitar. chamada de primitivos funcionais. O DFD de nível mais alto consiste de uma única bolha.3. Os níveis do DFD são três: • Parte superior.2. etc. O primitivo funcional não pode ser mais decomposto. N. Esse DFD especial é conhecido como Diagrama de Contexto.. Ele representa a visão de mais alto nível das principais funções do sistema. que retratam a divisão de parte ou de toda uma área em uma rede de componente que devem ser divididos.3. Níveis do DFD • 3. Análise e Projeto Estruturado I 15 . • Parte inferior. As bolhas inferiores são numeradas como N. Um fluxo que chega ao depósito deve ser interpretado como uma escrita.. que é o Diagrama de Contexto que serve para delinear o âmbito do estudo. Diagrama de Fluxo de Dados • Um fluxo que parte de um depósito deve ser interpretado como uma leitura.. bem com as principais interfaces entre essas funções. Todas as bolhas devem ser numeradas para facilitar a identificação e também servirem como meio prático de se relacionar uma bolha com o DFD de nível imediatamente inferior que descreve esta bolha de modo mais completo. E1 Sistema E2 E3 Diagrama de Contexto O DFD imediatamente abaixo do Diagrama de Contexto é conhecido como FIGURA 0.2.

Diagrama de Fluxo de Dados Os nomes das bolhas são transportadas para as figuras de níveis imediatamente abaixo.3. Figura 0 1 Processo 2 Processo Fluxo E1 Fluxo Fluxo Fluxo E2 Fluxo 3 Processo Fluxo Fluxo 4 Processo Fluxo Fluxo 2 Dados E3 33 Análise e Projeto Estruturado I 16 .

porque estarão dentro do processo no nível superior. tendo o cuidado de não utilizar nomes específicos da empresa ( ex. • Identifique todos os Fluxo de Dados em rede de E / S . O ideal é em número de 7 (sete) processos . Análise e Projeto Estruturado I 17 .D deve ser refeito por quantas vezes for necessário. fluxos depósito e entidade em um único DFD. e um sistema grande terá de cinco a oito níveis. Formulário Nº 7) e deveremos ter cuidado para não utilizarmos termos proveniente da atividade de programação ( ex. entidades externas e depósitos são repetidos no nível inferior. O nome ideal deverá ser compreensível para todos os que trabalham no mesmo ramo.3. Normas P/ Desenhar um DFD • Não crie um DFD com demasiados processos . até obter uma boa estética. encontram-se provavelmente dois ou três níveis. • Esteja preparado p/ recomeçar. utilizados apenas pelos processos de uma figura de nível inferior não serão mostrados nos níveis superiores. um sistema de médio porte apresenta costumeiramente de três a seis níveis. • Em uma explosão.F. aceitável pelo usuário e tão bem desenhado que você não fique constrangido de mostrá-lo em uma apresentação.3. refaça os DFD´s tantas vezes quanta as forem necessárias . • Os nomes escolhidos para os processos ( e também para os fluxos e entidades ) devem provir de um vocabulário conhecido pelo usuários. até que esteja tecnicamente correto. fluxos depósitos e entidades . • D. Diagrama de Fluxo de Dados 3. Trace-os em torno da parte externa de seu diagrama. • Os depósitos locais. • Em um sistema simples. • Algumas partes de um sistema podem ser mais complexas que outras e podem exigir a subdivisão em mais de um ou dois níveis. • Os fluxos de dados que entram e saem de um processo em um nível devem corresponder aos fluxos que entram e saem de uma figura inteira do nível imediatamente inferior que descreve aquele processo. os processos não. Rotina).

Usamos para esta avaliação as seguintes técnicas: • Teste quanto à correção : mostra com certeza que um DFD está errado. Processos. Não se pode considerar a fase de análise terminada até que a principal interface entre pessoas e máquinas esteja estabelecida e documentada. pode estar faltando Fluxos de Dados. • Teste quanto à utilidade : indicam que um DFD. Depósito de Dados . • Abordagens de reinicio : são métodos mecânicos para sair com uma versão aperfeiçoada. causas do tipo.3. Para isto verifique as bolhas com interface e tente diminuir sua complexidade. está muito complicado e difícil de entender. que entendemos mal o usuário. embora possa estar tecnicamente correto. Análise e Projeto Estruturado I 18 . Diagrama de Fluxo de Dados Ao finalizarmos um DFD devemos fazer uma avaliação p/ aperfeiçoar o DFD.

saídas. • Descrevendo a composição de pacotes agregados de dados que se movimentam pelos fluxos. Dicionário de Dados 4. sem os diagramas. e elementos de dados simples são definidos em termos das unidades válidas e dos valores que eles podem assumir. pacotes complexos (estruturas de dados) que podem ser divididos em itens mais elementares (elementos de dados). componentes de depósitos e cálculos intermediários. todas as entradas / saídas 2. Por que Precisamos de DD Para que os analistas e os usuários possam conhecer : 1. componentes dos depósitos de dados 3. DICIONÁRIO DE DADOS Dicionário de Dados é uma listagem organizada de todos os elementos de dados pertinentes ao sistema.1. com definições precisas e rigorosas para que o usuário e o analista possam conhecer todas as entradas. Só quando cada e qualquer elemento do DFD for rigorosamente definido é que o conjunto todo pode constituir uma ‘especificação’. O Dicionário de Dados é uma parte integrante da Especificação Estruturada. sem ele os DFD’s são apenas imagens que transmitem alguma idéia do que está acontecendo em um sistema. Os DFD’s e o DD devem ser considerados juntos. 4.1. • Descrevendo a composição de pacotes de dados nos depósitos. Em um Dicionário de Dados.1. cálculos intermediários Análise e Projeto Estruturado I 19 . Sem o DD. 4. os diagramas perdem o rigor. isto é. Definição de um Dicionário de Dados O Dicionário de Dados define os elementos de dados da seguinte maneira : • Descrevendo o significado dos fluxos e depósitos mostrados nos diagramas de fluxos de dados. o DD não tem nenhum utilidade.4. • Especificando os relevantes valores e unidades de partes elementares de informações dos fluxos de dados e depósitos de dados. os elementos de dados complexos são definidos em termos de elementos de dados mais simples.

pois não requer um trabalho braçal do analista e possibilita nos garantir a atualização do sistema.1. C2 então A = B1 + B2 + C1 +C2. etc) • Procedimento Automatizado • Procedimento misto Necessidades p/ Implementação de DD • • • • Definições acessíveis pelo nome. Fazendo a descrição da classe que contém a palavra e distinguindo-a de todos os outros membros da classe. isto é: Se A é composto de B e C sendo. no caso de não dispor de um pacote automatizado é preferível utilizarmos um sistema convencional (editores de texto.4. B composto de B1 e B2 e C composto de C1. Organização de um Dicionário de Dados • Procedimento Manual este processo manual (de uso de fichário com índice. Dicionário de Dados 4. Deve ser algo simples de fazer atualização em um DD. O Dicionário de Dados é composto de definições de : • • • • • Fluxo de Dados Depósito de Dados Processos Elemento de Dados Entidade A definição no Dicionário de Dados é um particionamento ‘ top-down’. Definições no Dicionário de Dados 4.2. Definições devem ser direta e ortogonal. este é o processo ideal. Não deve haver redundância. geradores de relatório. Um Dicionário de Dados é um conjunto de definições de termos usados em um DFD. só utilizando-o em último caso. folhas removíveis) devem hoje ser totalmente desprezado. Análise e Projeto Estruturado I 20 .2.

Pedido = nome-cliente + 8{ item }1 : pedido pode ter de 1 a 8 itens {} [] | Seleção (escolha uma das alternativas) Separador (separa opções alternativas na construção [ ] ) Sexo = [ masc | fem ] Uma preocupação que devemos ter ao fazermos a definição no Dicionário de Dados é evitar redundância. Endereço_cliente = (endereço-de-remessa) + (endereço-de-cobrança) () iterações de (qualquer-ou) . * unidades : quilogramas. (Quais são seus componentes e como eles se inter-relacionam) entram ao Dicionário de Dados. os elementos de dados mais complexos são definidos em termos de elementos de dados simples . e depois definimos seus subordinados.2. Convenção da Notação = é EQUIVALENTE A ou é COMPOSTO DE + significa E A =B+C A é definido como B e C Peso = * peso do paciente. Dicionário de Dados particularmente. Análise e Projeto Estruturado I 21 . 4.2. quando um Fluxo de Dados é complexo. isto é. ** @ Comentário ( quando não se coloca comentários os elementos de dados são considerados auto. é essencial que : • Informações sobre a composição de itens de dados.4. definimos em termo de subordinados de mais alto nível significativos.2. das unidades e dos valores que eles podem assumir.ocorrência repetida de um componente de um elemento de dados. intervalo : 1-200* opcional .1. identificador (campo chave) de um Depósito de Dados 4.explicativos.pode está ou não presente como um componente de um elemento de dados. Como Evitar Redundância A fim de evitar redundância nos e entre os Elementos da Especificação Estruturada.

4. Dicionário de Dados • Informações sobre o conteúdo e processamento de itens de dados (como seus valores são estabelecidos) entram na descrição do processo. • Informações sobre a determinação do roteiro de itens de dados entram no Diagrama de Fluxo de Dados. À medida que se trabalha com estas linhas de orientação, o problema de redundância desaparecerá. Os nomes devem refletir o significado e importância do item, não fornecer informações sobre como ele é construído ou qual a sua fonte e destino. O processo de definição deve parar em algum ponto. O ideal é parar com a definição quando todos no projeto entendam o que significa o termo, e /ou quando este termo se autodefina. Ex : Idade. Ao construir um Dicionário de Dados o analista preocupações : deve ter as seguintes

• Todos os fluxos do DFD foram definidos no Dicionário de Dados ? • Todos os componentes dos elementos de dados compostos foram definidos ? • Algum elemento de dados foi definido mais de uma vez ? • Foi utilizada a notação correta. • Existe algum elemento de dados no Dicionário de Dados que não esteja referenciado nos DFD’s, nos Diagrama E-R ou nos Diagramas de Transições de Estado. • Há um fluxo de dados especificado sem uma fonte ou sem um destino ? • Há algum elemento de dado especificado em qualquer depósito de dados que não tenha como chegar até lá, já que não faz parte dos fluxos de dados de entrada ? • Existe algum trecho de lógica de processo em que um elemento de dado seja usado embora não faça parte de nenhuma das entradas ao processo ? • Há algum elemento de dado, em qualquer fluxo de dados, que se dirija a um ou mais processos, mas que não é usado e/ou que aparece na saída do(s) processo(s) ? Análise e Projeto Estruturado I 22

4. Dicionário de Dados

4.3.

Como Implementar Um Dicionário De Dados

O Dicionário de Dados pode ser organizado por ordem alfabética dos elementos ou podemos descrever por entradas de : • • • • • Fluxo de Dados Elementos de Dados Depósito de Dados Processos Entidades

Ao criar as tabelas do DD devemos ter em vista alguns campos básicos : Nome Cognome sinônimo para um item de dado ; isto se dar por três razões : • Diferentes usuários possuem nomes diferentes para o mesmo documento. • Um analista introduz inadvertidamente, ao descer o nível. • Dois analista trabalham com o mesmo fluxo de dados, mas lhe dão nomes diferentes.

Análise e Projeto Estruturado I

23

4. Dicionário de Dados

4.3.1. Fluxo de Dados. Nome do Fluxo de Dados Dados do Paciente Cognome Composição Lista de todas as estruturas e elementos que compõem o fluxo de dados. Exemplo: nome-paciente ,endereço, telefone, CPF, seguro-saúde,data-denasc, sexo Nome do processo, depósito ou entidade origem externa de onde o fluxo de dados se originou Nome do processo, depósito ou entidade destino externa aonde o fluxo de dados está chegando 4.3.2. Elementos de Dados Como o elemento de dados são indivisíveis , para defini-los basta determinar que valores eles podem empregar e quais os significados destes valores. Estes elementos podem ser : discreto e contínuos. Nome do Elemento de Dados : sexo Cognome Valores e Significados [F/M] F- feminino M- masculino Notas nome p/ ser acessado a definição dos valores, e seus significados

Análise e Projeto Estruturado I

24

telefone. 4.4.3. etc.endereço. a necessidade de sua existência. Dicionário de Dados 4.3. No caso de Banco de Dados faz-se referência ao Diagrama de Estrutura de Dados . seguro-saúde. Lista de todos os fluxos que saem do processo Análise e Projeto Estruturado I 25 .data-denasc.3. sexo Processos com os quais se relacionam : • Consultar Paciente • Controlar Cliente Fluxo de entrada Fluxo de saída Lista com o nome de todos os fluxos que chegam ao depósito Lista com o nome de todos os fluxos que saem do depósito. Depósitos de Dados Nome do Depósito de Dados Pacientes Cognome Composição : Lista de todas as estruturas e elementos que compõem o fluxo de dados Exemplo : nome-paciente . : organização do arquivo. e o nome do elemento. pelo qual está organizado . Fluxo de entrada Fluxo de saída Lista de todos os fluxos que chegam ao processo.4. Processo Nome do Processo No do Processo Descrição do Processo 1 Uma explicação resumida detalhando o que faz o processo. CPF. PS.

Dicionário de Dados 4. podemos então providenciar uma listagem resumo. etc. • Habilidade de cruzar referência . Fluxo entrada Lista de todos os fluxos que chegam da entidade externa Lista de todos os fluxos que saem da entidade externa Fluxo saída 4.4.3.sabermos onde utilizarmos os dados é de suma importância para fazermos qualquer modificação. Pesquisa pela palavra-chave ou seqüência compostas de partes de palavra-chave Análise e Projeto Estruturado I 26 . Dicionário de Dados Automático • Entradas de todas as entradas e saídas com detalhes. Esta listagem se torna extensa. Listagem Resumo ◊ • Relatório composto . Entidades Nome de Entidade Cognome Descrição : Paciente Uma explicação resumida detalhando o que é a entidade externa. bem como os detalhes de cada elemento. a necessidade de sua existência. Listagem Total ◊ fornece todos os detalhes em ordem alfabética por nome.conhecer o conteúdo da estrutura de dados. fornece todas as entradas em ordem alfabética.5. mostrando somente o resumo da descrição. • Encontrar o nome a partir da descrição.4.

• Fluxo de dados dirigido p/ um processo. tipo : • Existe Fluxo de Dados sem fonte e / ou destino. • Elemento de dados de um Depósito que não tenham como chegar até lá. dados usados no processo . mas não é usado. • Obtenção das entradas do Dicionário de Dados. Análise e Projeto Estruturado I 27 . isto é. mas não especificação .4. Dicionário de Dados Averiguação da consistência e integridade. • Dados usado no processo. mas que não faz parte do fluxo de dados. através de programas já existentes. já que não faz parte do fluxo de dados de entrada.

que faz uso de um vocabulário limitado e uma sintaxe limitada. O vocabulário de Português Estruturado consiste apenas em: • • • • • • Verbos no imperativo ( entre 40 a 50 verbos). • Deve ser expressa de modo que possa ser entendida por toda a comunidade envolvida. Algumas palavras reservadas para formulação lógica. as palavras chaves devem ter um padrão da instalação. concisa e não ambígua .1. ESPECIFICAÇÕES DE PROCESSO A especificação de Processo define o que deve ser feito para transformar Entradas em Saídas. Português Estruturado Português estruturado é uma linguagem com estrutura. Análise e Projeto Estruturado I 28 . Especificações de Processo 5. mas não um método para implementar este programa de ação. Termos definidos no Dicionário de Dados. • método para descrever miniespecificação deveria ser altamente ortogonal. • Cada miniespecificação deve descrever o programa de ação fundamental que governa a transformação . A especificação tem como principais objetivos : • Deve haver uma miniespecificação para cada primitivo funcional no conjunto do Diagrama de Fluxo de Dados. Uma especificação deve ser clara. isto é. 5. É uma linguagem de especificação.1. e completa( nenhum elemento essencial é deixado sem especificação).5. fornecer uma e somente uma forma possível para escrever determinado programa. • Cada miniespecificação deve descrever regras que governam a transformação de Fluxos de Dados que chegam no primitivo associado em Fluxo de Dados que o deixam. comentários delimitado com asterisco ¨*¨. estrutura hierárquica. • A miniespecificação deve determinar o programa de ação de transformação sem introduzir redundância de qualquer tipo na Especificação Estruturada.1. Ferramentas Para Modelar uma Especificação de Processos 5.

: executar cálculo-deduções. • não use mais de três níveis de aninhamento. Ex. • restrinja a especificação de processo em linguagem estruturada a uma página. executar emitir-contracheque. ¬ construção de repetição. • as palavras chaves devem ser escrita em maiúsculo. Análise e Projeto Estruturado I 29 .5. Na linguagem estruturada são utilizadas as seguintes construções da programação estruturada: SEQUÊNCIA consiste em um ou mais programas de ação subordinadas ( partes de todo o programa de ação ) que são aplicados um após outro sem interrupção. que não tenha repetição ou ramificação englobada nela própria. ou grupo de instruções. Sequencia Esta estrutura cobre qualquer instrução. Especificações de Processo • usa-se parêntese para evitar ambigüidades ¬ ¬ ¬ ¬ Se A e B e C Se A e ( B ou C ) ou Se ( A e B ) ou C. • A sintaxe está limitada em : ¬ sentenças declarativa simples. ¬ construção de decisão. • as palavras que estão no DD devem ser em maiúsculo e sublinhadas.

Especificações de Processo REPETIÇÃO - um programa de ação subordinada que é feito repetidas vezes dentro de algum limite. tipo ¨ caso ¨ Caso variável = valor-1 sentença-1 Caso variável = valor-2 sentença-2 Análise e Projeto Estruturado I 30 . : tipo ¨ se ¨ Se condição-1 Então Ação-1 Senão ( Ñ-condiçao-1) Logo Ação-2. apenas um deles se aplica em qualquer caso determinado. : Do While condição-1 sentença-1 Enddo DECISÃO consiste em dois ou mais programas de ação subordinados. Repetição Esta estrutura é aplicada a qualquer situação em que uma instrução. d e c is ã o Esta estrutura é aplicada a qualquer uma instrução do tipo ¨se¨ ou do tipo ¨caso¨ Ex. é repetida até que o resultado desejado seja obtido. Ex.5. ou grupo de instruções.

• Vantagens do Português Estruturado Ele sobrevive à vida do projeto. ¨igual a ¨. durante a fase do projeto de módulo. As descrições tendem a ser simples e fáceis de serem lidas. pode ser empregado para descrever a lógica. menos os ruidosamente sem significado como ¨ processar ¨/ ¨ manipular ¨. até que “. Português Estruturado é o que existe de mais próximo de uma linguagem de especificação formal. Pode assustar o usuário. Especificações de Processo Em resumo o vocabulário do Português Estruturado é composto por : • Verbos.1. ele tende a querer ver o português arcaico. pode ser usado para descrever programa de ação .5.1. lutando para reduzir redundância. Mas não há garantia de estarem corretas. Para que o Português Estruturado tenha alguma utilidade para o analista . tais como . tem que ser aceito pelo usuário. ¨ enquanto ¨. é conciso. Inicialmente . 5. Pode ser feito conciso. Pode ser feito sob medida para o usuário.1. Pode ser mantido em forma automatizada. desde que se construa alguma facilidade na composição em Português Estruturado. Desvantagens do Português Estruturado • • • • • 5. Português Estruturado não é uma linguagem de Especificação Formal.1. ¨e¨.1. é importante que as ferramentas sejam flexíveis. • • Análise e Projeto Estruturado I 31 . Pode ser ajustado ao DD e DFD para verificar a consistência ( verificação léxica). e para viver dentro dos limites da sintaxe e vocabulário. • Atributos relacionais . ¨ se ¨. Pode ser escrito rápida e naturalmente. • Leva-se algum tempo para adquirir fluência em Português Estruturado. Não é rigoroso . Durante a fase da análise. tais como . você se verá lutando para distinguir entre programa de ação e procedimento. • Conjunções . ¨ou¨. Parece ser mais formal do que é .2. preciso e legível.

• Ela nos fornece uma maneira objetiva de identificar todas as combinações possíveis.1.2.5. • Os usuários não estão familiarizados com a Tabela. A Tabela de Decisão ajuda a considerar um programa de ação em sua composição. • As Tabelas de Decisões são confusas para aqueles que nunca tenham-na visto antes. 5. • Ela não nos fornece um quadro nítido da estrutura. Desvantagens da Tabelas de Decisão • Difícil saber algumas vezes quando iniciar uma formulação na Tabela de Decisão. para avaliá-lo quanto à perfeição e consistência. Vantagens da Tabela de Decisão • Ajuda a considerar um programa de ação em sua composição. e ajudam a encontrar situações que não foram totalmente especificada. para avaliá-lo quanto à perfeição e consistência. 5.1. Ela nos fornece uma maneira objetiva de identificar todas as combinações possíveis.1.1.2. • Deve ser usada quando a seleção de subprograma de ação dependendo de combinações de condições. Análise e Projeto Estruturado I 32 . A Tabela de Decisão deve ser usada quando a seleção de subprograma de ação depende de combinações de condições. • Ajuda a documentar o entendimento do analista com o usuário • Ajuda a encontrar situações que não foram totalmente especificada.2.2. Especificações de Processo 5. A vantagem da Tabela de Decisão é ajudar a documentar o entendimento do analista com o usuário. Tabelas de Decisão A Tabela de Decisão é a ferramenta mais utilizada quando o processo deve produzir alguma saída ou executar ações com base em decisões complementares.

Calcular o número total de regras -> N1 x N2 x Nn condições) ( onde Ni = nº de 2.EXEMPLO DE TABELAS DE ENTRADA LIMITADA CONDIÇÕES AÇõES C1 C2 C3 A1 A2 Mais de um milhão por ano ? Bom histórico de pagamento ? Conosco a mais de 20 anos ? Tratamento prioritário Tratamento normal S S S X S S N X S S N N N N S S S N S N X X X X N N N N S N X X Obs. 1. CONDIÇÕES AÇÕES 3. Especificações de Processo EXEMPLOS : 1. Considerar a última condição e alternar suas possibilidades ao longo de toda linha CONDIÇÕES AÇÕES S N S N S Análise e Projeto Estruturado I 33 . : S/N X -> eqüivale a ¨se¨ -> eqüivale a ¨então¨ Existe várias maneiras de nos certificarmos de que todas as possibilidades foram cobertas e que nenhuma tenha sido repetida. Criar as linhas de condição e ação e números de colunas para todas as regras.5.

exceto em uma. 3. Substituir o par por uma regra e usar o símbolo de indiferença. Juntar as diferenças C1 C2 C3 A1 A2 1 S S S X 2 S S N X 3 S N S X 4 S N N X 5 N S S X 6 N S N X 7/8 N N X S S S X S S N X S N S X S N N X N S S X N S N X N N S X N N N X Logo para consolidarmos a Tabela de Decisão temos : 1. 2. • os valores de condição sejam os mesmos. Análise e Projeto Estruturado I 34 . Observar quantas vezes o padrão se repete. Considerar a condição imediatamente acima e cobrir cada padrão com um valor para esta próxima condição ( e assim sucessivamente) C1 C2 C3 A1 A2 S S S S S N S N S S N N N S S N S N N N S N N N 5. Repetir para qualquer par que atenda os critérios. Combinações de condições ligadas às ações C1 C2 C3 A1 A2 6. Encontrar um par de regras para as quais : • a ação seja a mesma .5. Especificações de Processo 4.

Destino de A .terrestre L .Peso C4 .aéreo T .local S .5.Serviço Obs.norte do RJ L .leve ( LE2) M . ( C1.Aéreo + C2 .normal ( Nº DE LINHA = 2 x 3 x 2 = 36) C1 C2 C3 C4 A1 A2 A3 A4 A5 A6 A L L R A L L N A L M R A L M N A L P R A L P N A S L R A S L N A S M R A S M N A S P R A S P N A N L R A N L N A N M R A N M N A N P R A N P N T L L R C3 .pesado ( GT20) R .Rápido N . Observar as combinações inerentemente impossíveis.médio ( GT2 e LE20 ) P . Especificações de Processo 2.sul do RJ N .Método Remessa C2 .Local ) Análise e Projeto Estruturado I 35 .EXEMPLO DE TABELAS DE ENTRADA AMPLIADA Neste caso as condições tem mais de dois valores : C1 .

5. Devido à sua aparência familiar e apresentação gráfica . uma Árvore de Decisão funciona como uma ferramenta autodidática.1. nada mais . Árvore de Decisão Árvore de Decisão é a representação gráfica de uma Tabela de Decisão .3. Especificações de Processo 5. nada menos. A representação gráfica do exemplo seria : Mais de 1 milhão por ano Bom histórico de pagamento Conosco há mais de 20 anos Conosco há 20 anos ou menos Tratamento Prioritário Tratamento Prioritário Mau histórico de pagamento Tratamento Normal 1 milhão ou menos Tratamento Normal AÉREA TERRESTRE LE2 GT2/LE20 GT20 LOCAL FORA do LOCAL 6 exato 3 unidade / libra 60 exato + 2 para cada libra acima de 20 normal rápido 2 u/l rápido GT20 2 u/l LE20 3 u/l normal 2 u/l Análise e Projeto Estruturado I 36 .

também são úteis para mostrar uma Tabela de Decisão para o usuário. Vantagens / Desvantagens das Ferramentas USO Verificação Lógica Exibir Estrutura Lógica Simplicidade Verificação por Usuário Especificação de Prog. melhor para problemas que envolva combinação seqüencial de ações com decisões ou ciclos. 5. procurar representá-la como uma Árvore . usar uma Tabela de Decisão quando o número de ações for grande e ocorram muitas combinações de condições.4.1. 2. Utilizar Árvore de Decisão quando o número de decisões for pequeno e nem toda combinação de condições for possível. pelo Computador Alterabilidade ÁRVORE DE DECISÃO ÁRVORE DE DECISÃO Moderado Muito Bom (decisão) Muito Bom Bom Moderado Pobre Pobre Moderado TABELAS DE DECISÃO Muito Bom Moderado ( Decisão) Pobre Pobre Muito Bom Muito Bom Muito Bom Pobre PORTUGUÊS ESTRUTURADO Bom Bom Moderado Moderado Muito Bom Muito Bom Moderado Bom melhor para verificação lógica ou decisões moderadas ( até 15 ações). Tabelas de Decisão X Árvores de Decisão 1. As Tabelas de Decisões podem lidar com qualquer números de ações. Leitura pelo Computador Averig. TABELA DE DECISÃO PORTUGUÊS ESTRUTURADO Análise e Projeto Estruturado I 37 . melhor em problemas de combinações complexas ( até 6 condições). 3.5.1. Utilizar uma Tabela de Decisão se existirem dúvidas de que a Árvore de Decisão mostra toda a complexidade do problema. Mesmo que utilize-se a Tabela de Decisão para se descobrir a lógica . Especificações de Processo 5. grande número de condições dificulta o manuseio.5. desde que a norma 1 não seja violada.

que modela o comportamento tempodependente de um sistema. O Diagrama E-R é inteiramente diferente de um Diagrama de Fluxo de Dados. O modelo E-R propõe que a realidade seja visualizada sob três ponto de vista : • os objetos que a compõem .1. mas eles podem ser refletidos em um modelo que represente todos os produtos e os tipos de informações ou de características que se conhece sobre eles. Graficamente uma Entidade é representada por um ¨ retângulo¨ . os produtos de uma organização não são idênticos. Cliente Análise e Projeto Estruturado I 38 . • os tipos de informações ou características que se deseja conhecer sobre eles. com o nome da Entidade dentro com a 1º letra em maiúsculo.6. • forma como eles interagem entre si. e é diferente do Diagrama de Transição de Estado. o qual modela as funções executadas por um sistema . Este modelo é constituído por : • Conjuntos de Entidades • Conjuntos de Relacionamentos • Conjuntos de Atributos 6. Entidades ( tipos de objetos) (Relacionamento Indicadores Associativo de Objetos) ( supertipos / subtipos) O primeiro conceito estático do modelo E-R é o conceito de Entidade. pois possuem características diferentes. Outro aspecto importante no conceito de Entidade é a possibilidade de individualização de cada um dos objetos que compõe o padrão. Por exemplo. Diagrama de E-R 6. DIAGRAMA DE E-R O Diagrama de Entidades-Relacionamentos é um modelo em rede que descreve a diagramação dos dados armazenados de um sistema em alto nível de abstração. Uma Entidade é uma representação de um ¨objeto¨ do mundo real.O principal objetivo é se chegar num modelo teoricamente independente da máquina.

Então podemos dizer . podemos considerar algumas características do Empregado Engenheiro que não se aplica a categoria de Motorista. No exemplo acima. Os subtipos são criados quando alguns elementos de dados não se aplicam a todas as instâncias de um tipo de objeto. Análise e Projeto Estruturado I 39 .6. neste caso é preciso criar um supertipo e designar os elementos de dados comuns para o supertipo. chamada “Entidade Fraca” Ex : Entidade Dependente Esta entidade depende da Funcionário Já as entidades tipo “Generalização” é o particionamento de uma Entidade “supertipo” em várias Entidades subordinadas “subtipo”. Funcionário tipo Engenheiro Motorista Os tipos de objetos subtipo/supertipo consistem em um objeto e uma ou mais subcategorias. que durante o processo de refinamento de um Diagrama de E-R pode ocorrer que entidades diferentes descrevam elementos de dados comuns. e vice-versa.Entretanto. ou seja. depende da existência de uma outra Entidade. A categoria supertipo ( Funcionário) é descrita por elementos da dados que se aplicam a todos os subtipos. Algumas Entidades não existem por si só. interligadas por um relacionamento. cada subtipo (Engenheiro/Motorista) é descrito por diferentes elementos de dados. deve-se impor que cada “objeto” do mundo real seja representado por uma única entidade de um único conjunto de Entidades. Diagrama de E-R Para evitar redundância na representação das informações.

Local rua númer o CEP Análise e Projeto Estruturado I 40 . Nome . Ex.6. Essas características de mesmo tipo são utilizadas pela Organização para contratar . um salário. Tipos de Atributos 1. no qual são classificados todos os funcionários da Organização.1.assume um único valor . etc. Ex. Estes tipos de características são denominados ¨ Atributos¨ de uma Entidade. 6.2. A função de um atributo é mapear um conjunto de Entidades de um domínio. MONOVALORADO 2. No entanto . Por exemplo.2. Diagrama de E-R Exemplo : Dado as entidades : Cliente Cartão-deCrédito Cliente CartãoDinheiro Podemos definir : Cliente Cartão-deCrédito Cliente Cartão-deCrédito Cliente Cartão-deCrédito 6. MULTIVALORADO 3.são composto de um ou mais sub-atributos. COMPOSTO . Atributo A Entidade ¨ Funcionários¨ representa um tipo. cada indivíduo possui características próprias que devem ser diferenciadas. Ex. pagar e desligar funcionários.assume vários valores. administrar. um cargo. Telefone . cada funcionário possui um nome.

6. Diagrama de E-R 4. DETERMINANTE Funcionários . chamamos este Atributo de ¨ Chave Primária¨ ou Atributo Determinante¨. CGC Endereço Nome Telefones CGC Nº CEP Rua O Atributo é a menor decomposição de uma informação dentro de uma classe de dados. Quando temos um Atributo ou Grupos de Atributos que juntos assumem um valor único e identifica uma Entidade.quando assume um único valor . ¨ Ex.Este valor não pode ser nulo. Funcionários matricula ( 1atributo) triaatributo) Dependentes matric + sequecial ( 2 atributos) Análise e Projeto Estruturado I 41 . Ex.

A cardinalidade indica a relação existente entre todas as linhas de uma Entidade “A” com todas as linhas de uma Entidade “B”. O Relacionamento indica a dinâmica dos negócios . também. Sua representação é um losango .3. Análise e Projeto Estruturado I 42 .6. Cardinalidade dos Relacionamentos O modelo E-R. além de representar as relações de posse. sendo útil para extrair daí regras de consistência e integridade dos dados.3. não é a própria realidade. Cada instância do Relacionamento representa uma associação entre zero ou mais ocorrências de um objeto e zero ou mais ocorrências de outro objeto. O Relacionamento refletem as rotas lógicas de acesso às informações .1. O Relacionamento representa alguma coisa que deve ser recordada pelo sistema alguma coisa que não pode ser calculada. 6. incorporou. Ex. Relacionamento É a relação existente entre duas ou mais Entidades. mas foi desenvolvido para estar o mais próximo dela. Por isso. Este conceito é chamado de ¨ Cardinalidade do Relacionamento¨. composição e geração. como toda representação. Diagrama de E-R 6. Clientes Compra Itens É importante reconhecer que o Relacionamento representa um conjunto de conexões. e o nome deve ser um verbo . A cardinalidade define o número de ocorrências de uma Entidade que pode estar envolvida em um relacionamento. que são obtidas sobre vários objetos do mundo real. um outro conceito para melhorar o conhecimento sobre as políticas e regras dos negócios. bem como as regras e políticas que os regem. envolvimento.

• Uma propriedade importante neste tipo de relacionamento é que os conjuntos (domínios e imagens) podem ser fundidos em um só. Funcionários N lota 1 Departamento Análise e Projeto Estruturado I 43 .6. Um-para-muitos (1 : N) Muitos-para-um (N: 1) • Indica que uma ocorrência de uma entidade pode se relacionar com muitas ocorrências de outra entidade. 1. Um-para-um (1: 1). determinando o mínimo e o máximo de ocorrências. No entanto. Classe de um Relacionamento De acordo com a cardinalidade. unicidade e multiplicidade dos relacionamento entre duas Entidades. 6.3. • A chave da entidade ¨UM¨ é parte da tabela que descreve a entidade ¨MUITOS¨. existem três tipos básicos de Relacionamento entre Entidades.2. gerencia Funcionários Departamento 2. a questão é ¨As duas entidades são realmente distintas ou elas podem ser unidas?¨. (Um caso particular é o relacionamento 1 : 1) • Cada entidade contém uma tabela contendo seus atributos. no caso de toda informação a respeito das entidades não forem distintas. Diagrama de E-R A cardinalidade é um indicador de opcionalidade. a recíproca não é verdadeira. • Indica que uma única ocorrência de uma Entidade pode se relacionar com apenas uma única ocorrência de outra Entidade.

Diagrama de E-R 3. e um produto pode ser vendidos por diversos pedidos. criada para simplificar o relacionamento Muitos-para-Muitos. Geralmente. Análise e Projeto Estruturado I 44 . Muitos-para-muitos (N : N) Indica que várias ocorrências de uma entidade podem se relacionar com várias ocorrências de outra entidade.6. Pedidos N vende N Produtos Em cada pedido. onde a chave primária é composta das chaves primárias das entidades do relacionamento N:N. Simplificando-se tem : Pedido 1 possui N Item-Pedido N vende 1 Produto cod-ped __ped possui cod-ped + cod-prod vende cod-prod Item-pedido é uma Entidade Associativa. um relacionamento deste tipo pode ser convertido e simplificado pela criação de uma entidade intermediária e de dois relacionamento Um-paraMuitos (Entidade-Associativa). pode ser vendidos muitos produtos diferentes.

mas nem todo (0) departamento é lotado por funcionários ♦ Relacionamento Recursivos ou Auto-Relacionamento • Os auto-relacionamentos são casos especiais onde uma Entidade se relaciona com si própria.6.3.quando todo o elemento da entidade está obrigatoriamente no relacionamento. Um-para-Muitos ou Muitos-para-Muitos. Análise e Projeto Estruturado I 45 . Diagrama de E-R 6.3. Funcionario N lota 1 Departamento Todo funcionário obrigatoriamente ( | ) lota um departamento. • Os auto-relacionamentos podem ser de tipo Um-para-Um. caso contrário temos um relacionamento parcial. Natureza do Relacionamento • • • • • Relacionamento Parcionais e Totais Relacionamento Recursivos ou Auto-Relacionamento Relacionamento Múltiplos Agregação Relacionamento Parcionais e Totais Total . Funcionario G ERE NCIA 1 N G EREN CIA DO G erencia Funcionário desempenha o papel de gerente ou de subordinado.

sem oferecer quaisquer informações sobre as funções que criam ou utilizam os dados. Diagrama de E-R ♦ Relacionamento Múltiplos É a associação que envolve mais de duas Entidades. Análise e Projeto Estruturado I 46 . Ele é inteiramente voltado para os relacionamentos de dados. N Professor ensina N Disciplina N cursa N Aluno O modelo E-R é uma ferramenta valiosa para qualquer sistema com múltiplos depósitos (objetos) e complexos relacionamentos de dados. Professor N N ensina N Aluno Disciplina Obs.6. Ao associarmos um conjunto de Entidades e um Relacionamento temos uma Agregação. : Para entendermos este relacionamento devemos cortar uma das arestas e fazermos um relacionamento binário.

6. • Os itens no Dicionário de Dados devem aplicar-se tanto no modelo E-R como ao DFD. Diagrama de E-R O equilíbrio do modelo E-R em relação ao DFD.ou a uma Entidade Associativa do DER. Análise e Projeto Estruturado I 47 . Se houver um depósito no DFD que não apareça no DER. também há algum errado. • Os nomes das Entidades no DER e os dos Depósitos de dados no DFD devem coincidir. • Cada depósito do DFD deve corresponder a um tipo de Entidade ou a um Relacionamento. e se houver uma Entidade ou um Relacionamento no DER que não apareça no DFD. algo está errado.

eliminando grupos repetitivos.4. a normalização consiste em descobrir o lugar certo para cada coisa e colocar cada coisa em seu devido lugar. Normalização Normalização é um processo formal passo-a-passo que examina os atributos de uma Entidade. colaborando significamente para a estabilidade do modelo. Em resumo. dados redundantes e dependência multivaloradas. uma tabela deve conter apenas informações que se refiram a um mesmo tipo de dados. é necessário que as tuplas sejam analisadas de forma a verificar se seus atributos apresentam relações não-normalizadas submetendo-se aos conceitos subsequentes de cinco tipos de tabelas normalizadas. dependências transitivas. todas as colunas da tabela devem depender funcionalmente da chave primária. Para se atingir este estágio. ou seja. Este processo causa a simplificação dos atributos dentro da respectiva tupla.Dependência indireta entre dois ou mais atributo • Dependência Funcional Parcial • Dependência Transitiva Análise e Projeto Estruturado I 48 .Quando um atributo depende de parte da chave primária (chave composta) . Portanto. dependências parcionais de chaves concatenadas. . A normalização é um mecanismo para transformar estruturas complexas de dados em sua forma mais simples. Assim. Diagrama de E-R 6.6. reduzindo-se consideravelmente as necessidades de manutenção.Conjunto de atributos de uma entidade que ocorre múltiplas vezes para cada ocorrência da Entidade. Os três principais casos de anomalias que caracterizam uma estrutura desnormalização são : • Grupo Repetitivo . Simplicidade de uma estrutura pode ser definida como a existência de apenas dependência funcional. diz-se que uma estrutura de dados está “normalizada” quando está em seu estágio de maior simplicidade.

6. A 4FN e 5FN surgiram em 1977 num estudo feito por FAGIN. Diagrama de E-R O conceito de normalização no modelo relacional foi introduzida por Codd em 1970. Para introduzimos os conceitos ligados exemplo prático : Considere uma relação não normalizada : Número da ordem Código do cliente Nome do cliente Endereço Cidade UF CEP Data de Despacho Observações Código Item Descrição Quantidade Embalagem Preço Unitário Valor Total Impostos Total Geral Partindo da relação não-normalizada colocamos na 1FN. sendo posteriormente a 3FN aperfeiçoada por DATE. às formas normas utilizaremos um Análise e Projeto Estruturado I 49 .

ou seja. Então. Na Primeira Forma Normal retira-se as repetições. Diagrama de E-R 6. estabelecendo relacionamento natural entre as entidades. para cada chave há a ocorrência de uma e somente uma informação de cada atributo. Primeira Forma Normal (1FN). deve-se inserir como parte da chave primária em primeiro nível de importância. Análise e Projeto Estruturado I 50 . (ocorrências repetidas). Então podemos dizer que : Uma relação está na 1FN se todo os atributos básicos de uma tabela contiverem somente um valor para cada tupla.6.4. • Identificar o atributo que permita uma dependência funcional direta ou indireta dos outros atributos em relação a ele (chave primária) • Para conservar a propriedade reversível desta projeção. ficarão separados em duas relações os atributos simples e múltiplas ocorrências. a chave da relação fonte.1. podemos afirmar que uma tupla na primeira forma normal só apresenta atributos com ocorrência mínima de 0 (se opcional) ou de 1 (se obrigatório). A maneira prática de encontrarmos a 1FN é : • Separar em uma relação os atributos que tenham mais de um valor no documento fonte. (tirar as repetições) É a normalização da tupla. Em função da presente definição. neste caso cria-se uma nova entidade que herdará a chave primária da primeira (chave estrangeira) que fará parte de sua chave primária. de forma que o relacionamento entre a sua chave e os seus atributos seja unívoca.

Diagrama de E-R RELAÇÃO NÃO NORMALIZADA CP* Número da ordem Código do Cliente Nome do Cliente Endereço Cidade UF CEP Data de Despacho Observações Código Item Descrição Quantidade Embalagem Preço Unitário Valor Total Impostos Total Geral Múltiplas Ocorrências Múltiplas Ocorrências Código Item Descrição Quantidade Embalagem Preço Unitário Análise e Projeto Estruturado I 51 .6.

6. Diagrama de E-R (1FN) PRIMEIRA FORMA NORMAL (tirar as repetições) Simples Ocorrências CP* Número da ordem Código do cliente Nome do cliente Endereço Cidade UF CEP Data de Despacho Observações Valor Total Impostos Total Geral Múltiplas Ocorrências Número da Ordem Código Item Descrição Quantidade Embalagem Preço Unitário Valor CP* * CE CE Análise e Projeto Estruturado I 52 .

2. 1.6. Na 2FN todos os atributos depende unicamente da chave concatenada ou não concatenada. A dependência funcional normalmente não é garantida quando a chave primária é composta. Separar as chaves dependentes • Examinar a relação do ponto de vista de chave primária. verificar se existe atributos que dependam parcialmente da chave e neste caso criar uma nova entidade para estes atributos. Análise e Projeto Estruturado I 53 .2. Diagrama de E-R 6. ou que compõem uma chave primária forem funcionalmente dependente total da chave-primária. • Verificar se tem chave concatenada • Encontrar as chave dependentes. Dizemos que uma relação está na 2FN se todos os atributos que não são chaves. Os atributos não-chave primária devem sempre estar em Dependência Funcional-Total na 2FN em todas as múltiplas ocorrências.4. Caso haja chave concatenada (formada por mais de um atributos). Na 2FN deveremos nos preocupar com as ocorrências múltiplas. Segunda Forma Normal (2FN) (Verificar se há dependência entre chaves) A Entidade deverá está na 1FN. Gerar uma nova relação onde um atributo dependa da chave primária através de uma chave dependentes.

6. Diagrama de E-R 1FN DEPENDÊNCIA FUNCIOANAL Simples Ocorrências CP* Número da Ordem Código do Cliente Nome do Cliente Endereço Cidade UF CEP Data de Despacho Observações Valor Total Impostos Total Geral Múltiplas Ocorrências Número da Ordem Código Item Descrição Quantidade Embalagem Preço Unitário Valor CP* * CE CE (PROJEÇÃO) Código Item Descrição Embalagem Preço Unitário CP* Análise e Projeto Estruturado I 54 .

6. Diagrama de E-R (2FN) SEGUNDA FORMA NORMAL SIMPLES OCORRÊNCIA CP* Número da Ordem Código do Cliente Nome do Cliente Endereço Cidade UF CEP Data de Despacho Observações Valor Total Impostos Total Geral MÚLTIPLAS OCORRÊNCIAS CP* Número da Ordem Código do Item Quantidade Valor SIMPLES OCORRÊNCIAS CP* Código Item Descrição Embalagem Preço Unitário Análise e Projeto Estruturado I 55 .

Diagrama de E-R 6. • Deve-se criar tantas relações quantas chaves alternativas sejam encontradas. Terceira Forma Normal (3FN) (verificar se há dependência entre atributos) A Entidade deverá está na 2FN . 4.4. onde alguns atributos dependem da chave primária através de uma chave alternativa. que dependam de atributos não chave.6. 3. Eliminar as dependências transitivas criando novas relações. deverá ser criada uma nova entidade que será formada por estes atributos dependentes. Olhar para as relações de simples ocorrências. 2. Eliminar atributos obtidos por cálculos a partir de outros atributos. A dependência transitiva normalmente encontra-se em relações de simples ocorrências. e a chave primária será o atributo não chave da entidade original. Cada nova relação será composta pelos atributos que dependam funcionalmente da chave alternativa. 5.3. • A chave alternativa deve-se conservar na relação fonte como chave estrangeira ( propriedade reversível). Verificar se tem atributos que sejam dependentes de outros . Caso haja atributos em uma entidade. Uma relação está na 3FN se todos os atributos não-chave forem dependentes diretos não transitivos da chave primária. Na 3FN deveremos : 1. Análise e Projeto Estruturado I 56 .

6. Diagrama de E-R 2FN BUSCA AS DEPENDÊNCIAS TRANSITIVAS Simples Ocorrências CP* Número da Ordem Código do Cliente Nome do Cliente Endereço Cidade UF CEP Data de Despacho Observações Valor Total Impostos Total Geral MÚLTIPLAS OCORRÊNCIAS CP* Número da Ordem Código do Item Quantidade Valor Dependência Transitiva Código do Cliente Nome do Cliente Endereço Cidade UF CEP SIMPLES OCORRÊNCIAS CP* Código Item Descrição Embalagem Preço Unitário Análise e Projeto Estruturado I 57 .

6. Diagrama de E-R (3FN) TERCEIRA FORMA NORMAL CADASTRO DE CLIENTE Código de Cliente CP* Nome do Cliente Endereço Cidade UF CEP CADASTRO DE ORDEM Número de Ordem CE Código do Cliente Data de Despacho Observações Valor Total Impostos Total Geral CP* CP* CADASTRO PEÇAS Código Item DE CP* CADASTRO DE PEDIDOS Número da Ordem CE* Descrição Embalagem Preço Unitário * Código do Item Quantidade Valor CE* Análise e Projeto Estruturado I 58 .

: Entidades com Dependência Multivalorada Fornecedor Peça Comprador F1 P1 C1 F1 P2 C1 F1 P3 C2 Passando para 4FN teremos : Fornecedor / Peça Cod-peça Cod-forn Fornecedor/Compr ador Cod-forn Cod-comp Análise e Projeto Estruturado I 59 . sendo ¨n¨ igual ao número de atributos não -chaves constante da tupla original qual apresentem multivaloração. associados ao mesmo valor da chave. Quarta Forma Normal (4FN) Uma tabela de 3FN também está na 4FN se ela não contiver mais do que um fato multivalorado a respeito da entidade descrita pela tabela.4. criando novas tuplas individualizadas. herdando também a chave original. Verificar se existe atributos não chaves multivalorados e independentes. Diagrama de E-R 6. residentes em entidades distintas. 1. para cada um deles. Cada uma das novas tuplas herdará também a chave inicial. Ex.6. residentes em ¨n¨ entidades. Desfazer os atributos não-chaves multivalorados. 2. Quando aplicamos a 4FN desmembramos em ¨n¨ tuplas .4.

Aquecendo uma mistura química.7. São exemplos de estados típicos : • • • • • Aguardando que o usuário introduza uma senha. Diagrama de Transições de Estado 7.1. Análise e Projeto Estruturado I 60 . Acelerando o motor. DIAGRAMA DE TRANSIÇÕES DE ESTADO Diagrama de Transições de Estado é a ferramenta de modelagem que enfatiza o comportamento tempo-dependente do sistema 7. Misturando ingredientes. Estados do Sistema Um Estado do Sistema é caracterizado por uma pessoa ou objeto em determinado momento.1. Enchendo o tanque. Os Componentes de um Diagrama de Transições de Estado 7.1.

7. Mudanças de Estados As Mudanças de Estados são representadas por uma seta interligando os pares de Estado relevantes. Ex. INATIVO Aguardando Chamada Gravando Mensagem Rebobinando Tocando as Mensagens Respondendo Chamada Análise e Projeto Estruturado I 61 .2.1. Diagrama de Transições de Estado 7.

7. Diagrama de Transições de Estado 7. Condições e Ações ESTADO 1 Condição Ação ESTADO 2 Uma Condição no DTE representa um evento no ambiente externo que o sistema seja capaz de detectar. • Fazer a consistência do DTE considerando: ¬ Todos os estados foram definidos? ¬ Todos os estados podem ser atingidos? ¬ Todos os estados têm saída? Análise e Projeto Estruturado I 62 .3. Interligar os estados representado as mudanças de estado entre os retângulos. como por exemplo : apresentar uma mensagem no terminal do usuário.2.1. uma interrupção ou a chegada de um pacote de dados. o sistema normalmente empreenderá uma ou mais ações.7. podendo ser um sinal. etc. Para cada mudança de estado. efetuar um cálculo. • • Normas P/ Desenhar um DTE Identificar todos os estados possíveis do sistema. • Começar o DTE pelo estado inicial.

Sign up to vote on this title
UsefulNot useful