Análise Estruturada

1.

Introduo

1. ANLISE

ESTRUTURADA

Para entendermos o que significa Anlise Estruturada interessante definirmos o que Anlise. Anlise um estudo de um problema, que antecede uma ao. O seu propsito modelar um sistema de forma que ele possa ser entendido. Para falarmos sobre anlise de sistema bom termos uma idia clara do que seja um sistema. importante estar familiarizado com diferentes espcies de sistemas, pelo menos por dois motivos : Primeiro, mesmo que seu trabalho como analista se concentre em um tipo de um sistema automatizado de informaes, 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 paream ser totalmente diferentes, eles tm muitas semelhanas; existem princpios comuns , filosofias e teorias que se aplicam bem a todos os tipos de sistemas. Por exemplo , a lei da especializao, a qual diz que quanto mais adaptado for um organismo a um determinado ambiente, mais difcil ser este organismo a adaptao a outro. Isso ajuda a explicar o desaparecimento dos dinossauros quando o clima da terra modificou-se radicalmente; ajuda, tambm , aos analistas de sistemas a compreenderem que se otimizarem um sistema computadorizado de forma a tirar a mxima vantagem de uma determinada UCP, de uma linguagem de programao, podero vir a ter srios 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 anlise dever descrever O que precisa ser feito, sem restringir O como ser feito. Seu resultado deve ser o completo entendimento do domnio do problema que servir de preparao para a fase do Projeto. No domnio especfico do desenvolvimento de sistemas computacionais, anlise refere-se ao estudo de alguma rea de trabalho ou de uma aplicao, levando quase sempre especificao de um novo sistema. A ao que tomaremos mais tarde a implementao desse sistema. A Anlise tem caractersticas bastante diferenciadas do trabalho de projetar, programar e depurar sistemas computacionais, sendo as relaes interpessoais , particularmente as que envolvam usurios as mais complicadas e , algumas vezes at mesmo hostis. Anlise e Projeto Estruturado I 1

1.

Introduo

O produto mais importante da anlise de sistemas, a documentao de especificao ( Especificao Funcional), isto , o documento que estabelece os objetivos para o restante do projeto. Anlise de Sistema sob vrios aspectos, a parte mais difcil do desenvolvimento de um sistema de processamento de Dados. No simplesmente a dificuldade poltica que surgem, especialmente em projetos maiores em que o sistema atender a muitos grupos, cujos interesses so as vezes conflitantes. combinao de vrias dificuldades que torna a Anlise de Sistema to difcil e exigente. Na anlise de sistema as ferramentas de modelagem so utilizadas para : Focalizar a ateno nas caractersticas importantes do sistema , dando menos ateno s menos importantes; Discutir modificaes e correes nos requisitos do usurio com baixo custo e mnimo risco; Verificar se o analista conhece, corretamente, o ambiente do usurio e o documentou de tal maneira que os projetistas e programadores possam construir o sistema.

Os principais problemas da Anlise de Sistema Tradicional tipicamente so : era necessrio ler toda a especificao funcional, do princpio ao fim, para poder compreend-la. Eles eram redundantes a mesma informao era muitas vezes repetida em diversas partes diferentes do documento. o detalhamento dos requisitos do usurio podia Eles eram ambguos ser interpretado de modo diferente pelo usurio, pelo analista, pelo projetista e pelo programador. a especificao funcional quase sempre estava Manuteno difcil absoleta no final do processo de desenvolvimento. Eles eram monolticos Enquanto todos problemas estavam sendo debatidos, um conjunto complementar de idias j estavam sendo adotado na rea de programao e projeto. Essas idias, geralmente mencionadas como programao estruturada e projeto estruturado, prometiam grandes melhoras na organizao, codificao, testes e manuteno. O problema era que tnhamos como projetar sistema altamente modulares e excelentes programas , mas na realidade eles podiam est calcados em cima de uma soluo errada.

Anlise e Projeto Estruturado I

2

1.

Introduo

1.1.

Objetivos da Anlise Estruturada

Os produtos de anlise devem ter alta capacidade de manuteno, especialmente na documentao, isto aplica-se particularmente ao Documento Alvo; Os problemas quanto ao tamanho devem ser solucionados com a utilizao de um mtodo efetivo de particionamento; Grficos devem ser usados sempre que possvel; Diferenciar consideraes fsicas e lgicas , e distribuir responsabilidade; Construir um modelo lgico do sistema, de tal forma que o usurio familiarize-se com as caractersticas do sistema antes da implementao em si; Principais Problemas

1.2.

1.2.1. Produtividade 1.2.1.1. Visvel Invisvel Desconhecidos Demanda Reprimida (Backlog) So os novos sistemas solicitados oficialmente pelos usurios e que foram aceitos. Sistemas que os usurios sabem que precisam, mas que no se do ao trabalho de solicitar pelas vias oficiais. Sistemas que os usurios ainda no sabem que precisam.


3

1.

Introduo

1.2.1.1.

Tcnicas para Diminuir o Backlog

Contratao de programadores e analistas; Deixar que os usurios desenvolvam seus prprios sistemas; Utilizar tcnicas estruturadas : Programao Estruturada; Anlise Estruturada; Projeto Estruturado.

Utilizar ferramentas automatizadas Ferramentas CASE

1.2.2. Confiabilidade Erros de lgica na programao (3 a 5 a cada 100 comandos) 1.2.3. Manutenibilidade Alterao de hardware 50 a 80% dos trabalhos esto ligados codificao, converso, ao aperfeioamento ou a depurao


4

2.

Ferramentas da Anlise Estruturada

2. FERRAMENTAS DA ANLISE ESTRUTURADA A maior parte do trabalho do analista envolve a modelagem que o usurio deseja. Existem muitos diferentes tipos de modelos que podemos desenvolver. O termo modelo pode soar um tanto formal, porm representa um conceito usual em nossa vida, seno vejamos : Mapas Globos Desenho Arquitetnico - modelo bidimensional do mundo em que vivemos. - modelo tridimensional do mundo em que vivemos. - representaes esquemticas de um edifcio.

O analista usa ferramentas de modelagem para : Focalizar a ateno nas caractersticas importantes do sistema, dando menos ateno s menos importantes; Discutir modificaes e correes nos requisitos do usurio com baixo custo e mnimo risco; Verificar se o analista conhece, corretamente, os sistemas , o ambiente do usurio e se o documentou de tal maneira que os projetistas e programadores possam constru-los. Caractersticas Necessrias Para Uma Ferramenta

2.1.

Ser grfica, com adequado detalhamento textual de apoio. Deve permitir que o sistema possa ser visualizado de forma subdividida, na modalidade top-down. Deve ter mnima redundncia. Deve ajudar prognosticar o comportamento do sistema. Deve ser transparente.

2.1.1. Modelo Grficos A grande vantagem dos modelos grficos vem da justificativa de que Uma figura vale por mil palavra . Uma figura bem escolhida pode englobar uma imensa quantidade de informaes de forma concisa e compacta. Geralmente usamos grficos para identificar os componentes de um sistema e as interfaces entre eles; todos os outros detalhes ( isto , as respostas para perguntas como : Quantos ?, Em que seqncia , etc) so apresentados em documentos textuais de apoio. Os documentos textuais de apoio so a Especificao do Processo e o Dicionrio de Dados. Os grficos devem ser o principal documento a que o usurio dever recorrer para compreender o sistema; os documentos textuais devem servir como material de referncia e ser consultado quando necessrio.


5

2.


2.1.2. Modelos Subdivisveis em Modalidade Top-Down Uma boa ferramenta de modelagem deve retratar o sistema de forma subdividida top-down. Este mtodo de suma importncia para os grandes sistemas. Em conseqncia, ser impossvel para qualquer um , sejam eles usurios , analistas de sistemas ou programadores, focalizar todo o sistema de uma s vez. Nem seria possvel apresentar um modelo grfico de um grande e complexo sistema em uma simples folha de papel . As ferramentas de modelagem devem permitir retratar partes individuais do sistema de uma forma isolada , juntamente com um modo direto de passar de uma parte do modelo do sistema para outro. O modelo deve dar uma boa idia dos principais componentes de alto nvel e das interfaces do sistemas. As partes subsequentes forneceriam informaes sobre componentes de baixo nvel. 2.1.3. Modelo de Mnima Redundncia Os modelos so representaes de algum sistema do mundo real. O sistema pode ser : esttico (inalterado) dinmico. O ideal manter o modelo em uma forma correta e atual. Se o sistema se alterar, o modelo deve ser modificado para podermos mant-lo atualizado. Evidentemente, se somente um aspecto local do sistema for modificado, preferiramos modificar apenas um correspondente aspecto local do modelo, sem sermos forado a alterar qualquer outro aspecto dele. Na realidade, se forem necessrias mltiplas mudanas, existe uma boa possibilidade de que elas no sejam feitas , ou que elas sejam feitas de qualquer maneira. E isso significa que o modelo se tornar gradualmente menos correto. Ao desenharmos um sistema, devemos de preferncia considerar o aspecto local, pois caso haja modificao muito mais garantido mantermos o modelo atualizado do que quando temos de fazermos mltiplas mudanas. Outra preocupao que deveremos ter diminuirmos num modelo a redundncia , pois quanto maior for a redundncia que o modelo contiver , maior ser a dificuldade para mant-lo. Ao modelarmos alguma coisa que seja intrinsecamente linear e seqencial, tal como o fluxo de controle em um programa de processamento, devemos utilizar uma ferramenta de modelo textual. E para mudarmos alguma coisa que seja intrinsecamente multidimensional, com muitas atividades sendo executadas ao mesmo tempo , devemos utilizar uma ferramenta de modelagem grfica.


6

2.


As trs principais modelagens do sistemas so : Diagrama de Fluxo de Dados Diagrama de Entidade e Relacionamento Diagrama de Transies de Estado Ao fazermos uma modelagem devemos descrever : Que funes deve o sistema executar ? Quais so as interaes entre as funes ? Que transformaes deve executar o sistema ? Que entradas so transformadas em sada ? Que espcie de trabalho faz o sistema ? Onde ele obtm as informaes para faz-lo ? Para onde ele remete os resultados do trabalho ? A ferramenta utilizada para transformar entrada em sada o Diagrama de Fluxo de Dados. 2.2. Ferramentas de Modelagem (DFD) (DER) (DTE)

2.2.1. Diagrama de Fluxo De Dados O DFD uma representao em rede de um sistema . O sistema pode ser automatizado, manual ou misto . O DFD retrata o sistema em termo de suas partes componentes , com todas as interfaces entre os componentes indicados. O DFD nos d um particionamento muito benfico do sistema, oferecendo-nos um particionamento funcional , isto , as interfaces entre as partes so reduzidas ao mnimo. O uso do DFD nos leva a apresentar uma situao do ponto de vista dos dados, ao invs de apresent-lo do ponto de vista de qualquer pessoa ou empresa. A vantagem desta abordagem que os dados do uma viso da imagem total, enquanto que as pessoas, mquinas e empresas que trabalham com dados do uma viso de somente uma parte daquilo que acontece . bom frisar que o DFD mostra o Fluxo de Dados, no de controle. Esta a diferena entre DFD e Fluxogramas. O DFD retrata uma situao sob o ponto de vista dos dados, enquanto o Fluxograma representa uma situao sob o ponto de vista do que age sobre os dados. Uma importante vantagem do DFD deixar visvel ao usurio quando a anlise est errado, isto porque o DFD mostra um grfico global que far com que o usurio sinta falta de algum processo que lhe seja familiar. Anlise e Projeto Estruturado I 7

2.


O Diagrama de Fluxo de Dados consistem em : processos , depsitos de dados, fluxos e entidades. EXEMPLOD 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 oC lie n te

D ad os d o C lie n te

F a tu r a s

2.2.2. Dicionrio de Dados Dicionrio de Dados um depsito de dados sobre dados. uma parte integrante da Especificao Estruturada ; sem o DD os DFD so apenas imagens que transmitem alguma idia do que est acontecendo com o sistema . S quando todo elemento do DFD for rigorosamente definido que o conjunto todo pode constituir uma especificao . Este conjunto de definies esto no DD. Os DFDs e o DD devem ser considerados juntos. Sem o DD , os diagramas perdem o rigor, sem os DFDs , o DD no tem nenhuma utilidade. Ento podemos dizer que existe uma entrada no Dicionrio de Dados para cada Fluxo de Dados nico que aparece em qualquer lugar do DFD, para cada Depsito e para cada primitivo funcional. 2.2.3. Especificao de Processo A Especificao de Processos deve ser expressa de forma que possa ser efetivamente expressa de forma que possa ser entendida pelos usurios e pelos analistas. As ferramentas utilizadas so : rvore de Deciso Tabela de Deciso Portugus Estruturado 2.2.4. Diagrama de Entidade-Relacionamento Embora o Diagrama de Fluxo de Dados seja, de fato, uma ferramenta til para a modelagem do sistema ele somente enfatiza um aspecto principal de um sistema : suas funes. A notao de depsito de dados no DFD diz muito pouco acerca de detalhes de dados.


8

2.


Todos os sistemas armazenam e usam informaes sobre o ambiente com o qual interagem. No querendo saber, em detalhes, que informaes est contida em cada depsito de dados, mas tambm que relacionamentos existem entre os depsitos de dados. Esse aspecto no est realado pelo Diagrama de Fluxo de Dados , mas est ativamente retratado por uma outra ferramenta de modelagem : o Diagrama de Entidade-Relacionamentos. O Diagrama componentes: de Entidade-Relacionamento possui dois importantes

Tipos de objetos que representam uma coleo ou objetos do mundo real. Eles podem ser identificados de forma nica, podendo serem descritos por um ou mais fatos. Relacionamento que representa um conjunto de conexes ou associaes , entre os tipos do objetos. 2.2.5. Diagrama de Transies de Estado. Um terceiro aspecto de muitos sistemas complexos o comportamento tempodependente, a seqncia na qual se tem acesso aos dados e em que as funes sero executadas . A ferramenta de modelagem que usamos para descrever esse aspecto do comportamento de um sistema o Diagrama de Transies de Estado. 2.2.6. Diagrama de Estrutura . O Diagrama de Estrutura uma ferramenta de modelagem grfica usada para representar uma hierarquia de software.


9

3. Diagrama de Fluxo de Dados

3. DIAGRAMA DE FLUXO DE DADOS Diagrama de Fluxo de Dados a ferramenta de modelagem de uma situao do ponto de vista dos dados. A primeira coisa que realizamos com DFD compor o retrato significativo de um sistema ou de uma parte de um sistema. O DFD mostra as origens e os destinos dos dados ( e, por implicao, as fronteiras do sistema), identifica e denomina as Funes Lgicas, identifica e denomina os Grupos de Elementos de Dados que ligam uma funo a outra e identifica os Depsitos de Dados que elas acessam. Cada Fluxo de Dados analisado e suas estruturas e definies de seus Elementos de Dados componentes so armazenados no Dicionrio de Dados. Cada Funo Lgica pode ser subdividida em um Diagrama de Fluxo de Dados mais detalhados. Quando no mais til subdividir funo lgica, sua lgica externa de negcio expressa utilizando rvore de Decises , Portugus Estruturado ou outras ferramentas. As caractersticas de um DFD so : Ser Grficos Particionamento Multidimensionais Enfatizar Fluxo de Dados No enfatizar controle Os Componentes de um Diagrama de Fluxo de Dados

3.1.

3.1.1. Terminador / Entidade

Uma entidade uma pessoa ou empresa, que fica fora do contexto do sistema, que o originador ou o receptor de dados do sistema. So categorias lgicas de coisas ou pessoas uma fonte ou destino para transaes. Quando um sistema recebe Dados de um outro sistema ou fornece Dados a ele, o outro sistema considerado entidade externa.

Anlise e Projeto Estruturado IMaria Auxiliadora Freire

10

3. Diagrama de Fluxo de Dados Aspecto Importante : Entidades so externas ao sistema que estamos modelando; os fluxos que interligam as entidades dos diversos processos representam a interface entre o sistema do mundo externo; O analista e/ou projetista no podem modificar o contedo de uma Entidade; Qualquer relacionamento existentes entre Entidades no ser mostrado no DFD. 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, ento, por definio, as Entidades Externas so realmente parte do sistema e devem ser modeladas como processos

3.1.2. Fluxos de Dados

Um Fluxo de Dados retrata alguma interface entre componentes de um DFD. A maior parte do Fluxo de Dados movimenta-se entre processos, mas eles tambm podem fluir p/ dentro ou p/ fora de arquivos. Em todos os casos, utilizamos o smbolo de um vetor com um nome, para mostrar a interface. O Fluxo representa dados em movimento. Algumas convenes podem ser adotadas para notaes de Fluxo de Dados: Nomes ligados por hfens em maisculo; Nomes escolhidos para representarem no apenas os dados que fluem; mas tambm para sabermos sobre os dados; Se o fluxo de dados est sem rtulo e est se dirigindo a um depsito, significa que toda a instncia ( registro) est sendo introduzido ou retirado do depsito, caso contrrio revela erro. Os detalhes procedurais a respeito de um processo no so tratados atravs de Fluxos de Dados, para trat-los deve-se utilizar outra ferramenta de modelagem, como portugus estruturado, por exemplo. Procure fazer Fluxos de Dados o mais reto possvel e evite que eles se cruzem. claro que isso s ser possvel depois de se refazer o DFD vrias vezes. 11



Cuidado com os Fluxos de Dados sem nome. s vezes, o nome foi omitido por que a informao do nome bvia, mas, s vezes, pode-se estar omitindo o nome do Fluxo simplesmente porque no se conseguiu encontrar um nome satisfatrio, isso deve ser evitado. Um Fluxo no deve ligar uma entidade externa a um depsito de dados, quando isso ocorrer, certamente estar faltando um processo entre os dois. Os Fluxos de Dados que chegam e saem de entidades externas representam as interfaces do sistema com o mundo externo.

O que o Fluxo de Dados no : Uma representao de fluxo de controle, fluxo de conscincia do computador ou da pessoa que processa os dados. 3.1.3. Processo

Os processos, invariavelmente, mostram algum trabalho executado em cima dos dados. Um processo uma transformao do(s) Fluxo(s) de Dados de entrada em Fluxo(s) de Dados de sada. O Processo pode ser representado em Crculo ou Retngulo Arredondado dividido em trs reas : nome do processo deve dar idia do que faz o processo , para que tenhamos

xito em transmitir a imagem total com o DFD.

Ao escolher nome de um processo evite usar nomes de pessoas , rotule de modo a identificar as funes que o sistema executa. Rotular os processos em termo de suas entrada / sada. Reparticione para evitar processo sem nomes. Numerar os processos 12



Um bom nome de processo geralmente composto por uma frase constituda de um verbo e de um objeto. Por exemplo : Calcular Valor do Imposto, Validar Entrada, Receber Pedidos. Temos a tentao de utilizar nomes vagos como FAZER SERVIO, MANIPULAR ENTRADA e PROCESSAR DADOS. Muitas vezes isso significa que o Analista de Sistemas no est bem certo de qual funo est sendo executada. Existe uma tendncia natural por parte dos usurios em utilizar as abreviaes e siglas que lhes sejam familiares. Isso ocorre tanto para os processos quanto para os fluxos que eles descrevem. Isto torna o DFD muito pessoal. Deve-se utilizar terminologias que sejam compreensveis por um nmero maior de pessoas. Os termos ROTINA, SUBSISTEMA e FUNO geralmente no tm significados no mundo do usurio. A menos que voc oua os usurios utilizarem estas palavras em conversas entre eles mesmos; evite-as nos DFD. Deve-se evitar poos sem fundo; processos que tm entradas mas no tem sadas. Deve-se evitar gerao espontnea; processos que tm sadas mas no tem entradas.


13


3.1.4. Depsito de Dados

Lugar onde necessitamos definir dados como armazenados entre processo (depsito temporrio de dados). O processo indica atravs do Fluxo de Dados onde est armazenado os dados ou lendo dados, caso seja necessrio especificar o argumento de pesquisa, este pode ser ilustrado de lado oposto da descrio do Fluxo de Dados. O Depsito de Dados existe como uma necessidade de armazenamento entre os dois processos que ocorrem em momentos diferentes. Consideraes importantes a respeito de Depsitos de Dados : Os Depsitos de Dados s so mostrados dentro da divisa criados / processados apenas por este processo. que so

Normalmente o nome escolhido para identificar o Depsito o plural dos pacotes transportados pelos fluxos para dentro e para fora do Depsito. Por exemplo : PEDIDOS, CLIENTES, MERCADORIAS. Um Depsito pode existir por um requisito bsico do usurio ou por um aspecto de implementao : Um depsito que requisito bsico do usurio estar no sistema por que o usurio necessita deste depsito independente da tecnologia que est ou ser utilizada. Um depsito de implementao existe quando : no h memria suficiente no computador para acomodar vrios processos ao mesmo tempo; a configurao de hardware no totalmente confivel, necessitando-se de um depsito para possvel recuperao de informaes; dois processos que utilizam as mesmas informaes sero implementados por grupos de programadores diferentes; o Analista de Sistemas resolveu armazenar as informaes, prevendo que eventualmente o usurio poder querer consult-las ( prevendo assim uma necessidade futura do usurio ).


14


Um fluxo que parte de um depsito deve ser interpretado como uma leitura. Um fluxo que chega ao depsito deve ser interpretado como uma escrita, uma alterao ou ainda uma eliminao. Os fluxos que saem e chegam a Depsitos s podem transportar informaes que o depsito pode aceitar. Nveis do DFD

3.2.

O DFD de nvel mais alto consiste de uma nica bolha, representando o sistema inteiro; os fluxos de dados mostram as interfaces entre o sistema e as entidades externas. Esse DFD especial conhecido como Diagrama de Contexto.

E1

Sistema

E2

E3Diagrama de ContextoO DFD imediatamente abaixo do Diagrama de Contexto conhecido como FIGURA 0. Ele representa a viso de mais alto nvel das principais funes do sistema, bem com as principais interfaces entre essas funes. Todas as bolhas devem ser numeradas para facilitar a identificao e tambm servirem como meio prtico de se relacionar uma bolha com o DFD de nvel imediatamente inferior que descreve esta bolha de modo mais completo. As bolhas inferiores so numeradas como N.1, N.2, N.3.... etc. Os nveis do DFD so trs: Parte superior, que o Diagrama de Contexto que serve para delinear o mbito do estudo; Parte inferior, a parte no particionada, chamada de primitivos funcionais. O primitivo funcional no pode ser mais decomposto; Nveis intermedirios, que retratam a diviso de parte ou de toda uma rea em uma rede de componente que devem ser divididos.


15


Os nomes das bolhas so transportadas para as figuras de nveis imediatamente abaixo.

Figura 01 Processo 2 ProcessoFluxo

E1

Fluxo

Fluxo

Fluxo

E2

Fluxo

3 ProcessoFluxo Fluxo

4 Processo

Fluxo Fluxo

2 Dados

E3 33


16


3.3.

Normas P/ Desenhar um DFD

No crie um DFD com demasiados processos , fluxos depsitos e entidades . O ideal em nmero de 7 (sete) processos , fluxos depsito e entidade em um nico DFD; Em um sistema simples, encontram-se provavelmente dois ou trs nveis; um sistema de mdio porte apresenta costumeiramente de trs a seis nveis; e um sistema grande ter de cinco a oito nveis; Algumas partes de um sistema podem ser mais complexas que outras e podem exigir a subdiviso em mais de um ou dois nveis; Os fluxos de dados que entram e saem de um processo em um nvel devem corresponder aos fluxos que entram e saem de uma figura inteira do nvel imediatamente inferior que descreve aquele processo; Os depsitos locais, utilizados apenas pelos processos de uma figura de nvel inferior no sero mostrados nos nveis superiores, porque estaro dentro do processo no nvel superior; D.F.D deve ser refeito por quantas vezes for necessrio, at que esteja tecnicamente correto, aceitvel pelo usurio e to bem desenhado que voc no fique constrangido de mostr-lo em uma apresentao; Em uma exploso, entidades externas e depsitos so repetidos no nvel inferior, os processos no; Identifique todos os Fluxo de Dados em rede de E / S . Trace-os em torno da parte externa de seu diagrama; Os nomes escolhidos para os processos ( e tambm para os fluxos e entidades ) devem provir de um vocabulrio conhecido pelo usurios, tendo o cuidado de no utilizar nomes especficos da empresa ( ex. Formulrio N 7) e deveremos ter cuidado para no utilizarmos termos proveniente da atividade de programao ( ex. Rotina). O nome ideal dever ser compreensvel para todos os que trabalham no mesmo ramo; Esteja preparado p/ recomear, refaa os DFDs tantas vezes quanta as forem necessrias , at obter uma boa esttica.


17

3. Diagrama de Fluxo de Dados Ao finalizarmos um DFD devemos fazer uma avaliao p/ aperfeioar o DFD. Usamos para esta avaliao as seguintes tcnicas: Teste quanto correo : mostra com certeza que um DFD est errado, que entendemos mal o usurio, causas do tipo, pode estar faltando Fluxos de Dados, Processos, Depsito de Dados ; Teste quanto utilidade : indicam que um DFD, embora possa estar tecnicamente correto, est muito complicado e difcil de entender. Para isto verifique as bolhas com interface e tente diminuir sua complexidade; Abordagens de reinicio : so mtodos mecnicos para sair com uma verso aperfeioada. No se pode considerar a fase de anlise terminada at que a principal interface entre pessoas e mquinas esteja estabelecida e documentada.


18

4. Dicionrio de Dados 4. DICIONRIO DE DADOS Dicionrio de Dados uma listagem organizada de todos os elementos de dados pertinentes ao sistema, com definies precisas e rigorosas para que o usurio e o analista possam conhecer todas as entradas, sadas, componentes de depsitos e clculos intermedirios. 4.1. Definio de um Dicionrio de Dados

O Dicionrio de Dados define os elementos de dados da seguinte maneira : Descrevendo o significado dos fluxos e depsitos mostrados nos diagramas de fluxos de dados. Descrevendo a composio de pacotes agregados de dados que se movimentam pelos fluxos, isto , pacotes complexos (estruturas de dados) que podem ser divididos em itens mais elementares (elementos de dados). Descrevendo a composio de pacotes de dados nos depsitos. Especificando os relevantes valores e unidades de partes elementares de informaes dos fluxos de dados e depsitos de dados. Em um Dicionrio de Dados, os elementos de dados complexos so definidos em termos de elementos de dados mais simples, e elementos de dados simples so definidos em termos das unidades vlidas e dos valores que eles podem assumir. O Dicionrio de Dados uma parte integrante da Especificao Estruturada; sem ele os DFDs so apenas imagens que transmitem alguma idia do que est acontecendo em um sistema. S quando cada e qualquer elemento do DFD for rigorosamente definido que o conjunto todo pode constituir uma especificao. Os DFDs e o DD devem ser considerados juntos. Sem o DD, os diagramas perdem o rigor, sem os diagramas, o DD no tem nenhum utilidade. 4.1.1. Por que Precisamos de DD Para que os analistas e os usurios possam conhecer : 1. todas as entradas / sadas 2. componentes dos depsitos de dados 3. clculos intermedirios


19

4. Dicionrio de Dados 4.1.2. Organizao de um Dicionrio de Dados Procedimento Manual este processo manual (de uso de fichrio com ndice, folhas removveis) devem hoje ser totalmente desprezado, s utilizando-o em ltimo caso. este o processo ideal, pois no requer um trabalho braal do analista e possibilita nos garantir a atualizao do sistema. no caso de no dispor de um pacote automatizado prefervel utilizarmos um sistema convencional (editores de texto, geradores de relatrio, etc)

Procedimento Automatizado Procedimento misto

Necessidades p/ Implementao de DD Definies acessveis pelo nome; No deve haver redundncia; Deve ser algo simples de fazer atualizao em um DD; Definies devem ser direta e ortogonal. Definies no Dicionrio de Dados

4.2.

Um Dicionrio de Dados um conjunto de definies de termos usados em um DFD. Fazendo a descrio da classe que contm a palavra e distinguindo-a de todos os outros membros da classe. O Dicionrio de Dados composto de definies de : Fluxo de Dados Depsito de Dados Processos Elemento de Dados Entidade

A definio no Dicionrio de Dados um particionamento top-down, isto : Se A composto de B e C sendo, B composto de B1 e B2 e C composto de C1, C2 ento A = B1 + B2 + C1 +C2.


20

4. Dicionrio de Dados particularmente, quando um Fluxo de Dados complexo, definimos em termo de subordinados de mais alto nvel significativos, e depois definimos seus subordinados, isto , os elementos de dados mais complexos so definidos em termos de elementos de dados simples , das unidades e dos valores que eles podem assumir. 4.2.1. Conveno da Notao = EQUIVALENTE A ou COMPOSTO DE + significa E A =B+C A definido como B e C Peso = * peso do paciente. * unidades : quilogramas; intervalo : 1-200* opcional - pode est ou no presente como um componente de um elemento de dados. Endereo_cliente = (endereo-de-remessa) + (endereo-de-cobrana) () iteraes de (qualquer-ou) - ocorrncia repetida de um componente de um elemento de dados. Pedido = nome-cliente + 8{ item }1 : pedido pode ter de 1 a 8 itens {} [] | Seleo (escolha uma das alternativas) Separador (separa opes alternativas na construo [ ] ) Sexo = [ masc | fem ]

Uma preocupao que devemos ter ao fazermos a definio no Dicionrio de Dados evitar redundncia. ** @ Comentrio ( quando no se coloca comentrios os elementos de dados so considerados auto- explicativos. identificador (campo chave) de um Depsito de Dados

4.2.2. Como Evitar Redundncia A fim de evitar redundncia nos e entre os Elementos da Especificao Estruturada, essencial que : Informaes sobre a composio de itens de dados. (Quais so seus componentes e como eles se inter-relacionam) entram ao Dicionrio de Dados.


21

4. Dicionrio de Dados Informaes sobre o contedo e processamento de itens de dados (como seus valores so estabelecidos) entram na descrio do processo. Informaes sobre a determinao do roteiro de itens de dados entram no Diagrama de Fluxo de Dados. medida que se trabalha com estas linhas de orientao, o problema de redundncia desaparecer. Os nomes devem refletir o significado e importncia do item, no fornecer informaes sobre como ele construdo ou qual a sua fonte e destino. O processo de definio deve parar em algum ponto. O ideal parar com a definio quando todos no projeto entendam o que significa o termo, e /ou quando este termo se autodefina. Ex : Idade. Ao construir um Dicionrio de Dados o analista preocupaes : deve ter as seguintes

Todos os fluxos do DFD foram definidos no Dicionrio 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 notao correta. Existe algum elemento de dados no Dicionrio de Dados que no esteja referenciado nos DFDs, nos Diagrama E-R ou nos Diagramas de Transies de Estado. H um fluxo de dados especificado sem uma fonte ou sem um destino ? H algum elemento de dado especificado em qualquer depsito de dados que no tenha como chegar at l, j que no faz parte dos fluxos de dados de entrada ? Existe algum trecho de lgica de processo em que um elemento de dado seja usado embora no faa 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 no usado e/ou que aparece na sada do(s) processo(s) ? Anlise e Projeto Estruturado I 22

4. Dicionrio de Dados

4.3.

Como Implementar Um Dicionrio De Dados

O Dicionrio de Dados pode ser organizado por ordem alfabtica dos elementos ou podemos descrever por entradas de : Fluxo de Dados Elementos de Dados Depsito de Dados Processos Entidades

Ao criar as tabelas do DD devemos ter em vista alguns campos bsicos : Nome Cognome sinnimo para um item de dado ; isto se dar por trs razes : Diferentes usurios possuem nomes diferentes para o mesmo documento. Um analista introduz inadvertidamente, ao descer o nvel. Dois analista trabalham com o mesmo fluxo de dados, mas lhe do nomes diferentes.


23


4.3.1. Fluxo de Dados. Nome do Fluxo de Dados Dados do Paciente Cognome Composio Lista de todas as estruturas e elementos que compem o fluxo de dados. Exemplo: nome-paciente ,endereo, telefone, CPF, seguro-sade,data-denasc, sexo Nome do processo, depsito ou entidade origem externa de onde o fluxo de dados se originou Nome do processo, depsito ou entidade destino externa aonde o fluxo de dados est chegando 4.3.2. Elementos de Dados Como o elemento de dados so indivisveis , para defini-los basta determinar que valores eles podem empregar e quais os significados destes valores. Estes elementos podem ser : discreto e contnuos. Nome do Elemento de Dados : sexo Cognome Valores e Significados [F/M] F- feminino M- masculino Notas nome p/ ser acessado a definio dos valores, e seus significados


24

4. Dicionrio de Dados 4.3.3. Depsitos de Dados Nome do Depsito de Dados Pacientes Cognome Composio : Lista de todas as estruturas e elementos que compem o fluxo de dados Exemplo : nome-paciente ,endereo, telefone, CPF, seguro-sade,data-denasc, sexo Processos com os quais se relacionam : Consultar Paciente Controlar Cliente Fluxo de entrada Fluxo de sada Lista com o nome de todos os fluxos que chegam ao depsito Lista com o nome de todos os fluxos que saem do depsito.

PS. : organizao do arquivo, e o nome do elemento, pelo qual est organizado . No caso de Banco de Dados faz-se referncia ao Diagrama de Estrutura de Dados . 4.3.4. Processo Nome do Processo No do Processo Descrio do Processo

1

Uma explicao resumida detalhando o que faz o processo, a necessidade de sua existncia, etc. Fluxo de entrada Fluxo de sada Lista de todos os fluxos que chegam ao processo. Lista de todos os fluxos que saem do processo


25


4.3.5. Entidades Nome de Entidade Cognome Descrio : Paciente

Uma explicao resumida detalhando o que a entidade externa, a necessidade de sua existncia, etc. Fluxo entrada

Lista de todos os fluxos que chegam da entidade externa Lista de todos os fluxos que saem da entidade externa

Fluxo sada

4.4.

Dicionrio de Dados Automtico

Entradas de todas as entradas e sadas com detalhes. Listagem Total fornece todos os detalhes em ordem alfabtica por nome. Esta listagem se torna extensa, podemos ento providenciar uma listagem resumo. fornece todas as entradas em ordem alfabtica, mostrando somente o resumo da descrio.

Listagem Resumo

Relatrio composto - conhecer o contedo da estrutura de dados, bem como os detalhes de cada elemento. Habilidade de cruzar referncia - sabermos onde utilizarmos os dados de suma importncia para fazermos qualquer modificao. Encontrar o nome a partir da descrio. Pesquisa pela palavra-chave ou seqncia compostas de partes de palavra-chave


26

4. Dicionrio de Dados Averiguao da consistncia e integridade, tipo : Existe Fluxo de Dados sem fonte e / ou destino; Dados usado no processo, mas no especificao , isto , dados usados no processo , mas que no faz parte do fluxo de dados; Fluxo de dados dirigido p/ um processo, mas no usado; Elemento de dados de um Depsito que no tenham como chegar at l, j que no faz parte do fluxo de dados de entrada. Obteno das entradas do Dicionrio de Dados, atravs de programas j existentes.


27

5.

Especificaes de Processo

5. ESPECIFICAES DE PROCESSO A especificao de Processo define o que deve ser feito para transformar Entradas em Sadas. Uma especificao deve ser clara, concisa e no ambgua , e completa( nenhum elemento essencial deixado sem especificao). A especificao tem como principais objetivos : Deve haver uma miniespecificao para cada primitivo funcional no conjunto do Diagrama de Fluxo de Dados. Cada miniespecificao deve descrever regras que governam a transformao de Fluxos de Dados que chegam no primitivo associado em Fluxo de Dados que o deixam. Cada miniespecificao deve descrever o programa de ao fundamental que governa a transformao , mas no um mtodo para implementar este programa de ao. A miniespecificao deve determinar o programa de ao de transformao sem introduzir redundncia de qualquer tipo na Especificao Estruturada. mtodo para descrever miniespecificao deveria ser altamente ortogonal, isto , fornecer uma e somente uma forma possvel para escrever determinado programa. Deve ser expressa de modo que possa ser entendida por toda a comunidade envolvida; 5.1. Ferramentas Para Modelar uma Especificao de Processos

5.1.1. Portugus Estruturado Portugus estruturado uma linguagem com estrutura. uma linguagem de especificao, que faz uso de um vocabulrio limitado e uma sintaxe limitada. O vocabulrio de Portugus Estruturado consiste apenas em: Verbos no imperativo ( entre 40 a 50 verbos); Termos definidos no Dicionrio de Dados; Algumas palavras reservadas para formulao lgica; estrutura hierrquica; as palavras chaves devem ter um padro da instalao; comentrios delimitado com asterisco *.


28

5.


usa-se parntese para evitar ambigidades Se A e B e C Se A e ( B ou C ) ou Se ( A e B ) ou C.

as palavras chaves devem ser escrita em maisculo; as palavras que esto no DD devem ser em maisculo e sublinhadas; restrinja a especificao de processo em linguagem estruturada a uma pgina; no use mais de trs nveis de aninhamento; A sintaxe est limitada em : sentenas declarativa simples; construo de deciso; construo de repetio. Na linguagem estruturada so utilizadas as seguintes construes da programao estruturada: SEQUNCIA consiste em um ou mais programas de ao subordinadas ( partes de todo o programa de ao ) que so aplicados um aps outro sem interrupo.

Sequencia

Esta estrutura cobre qualquer instruo, ou grupo de instrues, que no tenha repetio ou ramificao englobada nela prpria. Ex. : executar clculo-dedues; executar emitir-contracheque.


29

5.


REPETIO -

um programa de ao subordinada que feito repetidas vezes dentro de algum limite.

Repetio

Esta estrutura aplicada a qualquer situao em que uma instruo, ou grupo de instrues, repetida at que o resultado desejado seja obtido. Ex. : Do While condio-1 sentena-1 Enddo DECISO consiste em dois ou mais programas de ao subordinados, apenas um deles se aplica em qualquer caso determinado.

d e c is o

Esta estrutura aplicada a qualquer uma instruo do tipo se ou do tipo caso Ex. : tipo se Se condio-1 Ento Ao-1 Seno ( -condiao-1) Logo Ao-2. tipo caso Caso varivel = valor-1 sentena-1 Caso varivel = valor-2 sentena-2


30

5.


Em resumo o vocabulrio do Portugus Estruturado composto por : Verbos, menos os ruidosamente sem significado como processar / manipular ; Conjunes , tais como , se , enquanto , at que ; Atributos relacionais , tais como , igual a , e, ou. 5.1.1.1. Vantagens do Portugus Estruturado

Ele sobrevive vida do projeto. Durante a fase da anlise, pode ser usado para descrever programa de ao ; durante a fase do projeto de mdulo, pode ser empregado para descrever a lgica. Pode ser mantido em forma automatizada. Pode ser feito conciso, preciso e legvel. Portugus Estruturado o que existe de mais prximo de uma linguagem de especificao formal. Pode ser feito sob medida para o usurio; importante que as ferramentas sejam flexveis. Pode ser ajustado ao DD e DFD para verificar a consistncia ( verificao lxica). Pode ser escrito rpida e naturalmente, desde que se construa alguma facilidade na composio em Portugus Estruturado. Desvantagens do Portugus Estruturado

5.1.1.2.

Leva-se algum tempo para adquirir fluncia em Portugus Estruturado. Inicialmente , voc se ver lutando para distinguir entre programa de ao e procedimento, lutando para reduzir redundncia, e para viver dentro dos limites da sintaxe e vocabulrio; Parece ser mais formal do que . Portugus Estruturado no uma linguagem de Especificao Formal. No rigoroso , conciso. As descries tendem a ser simples e fceis de serem lidas. Mas no h garantia de estarem corretas. Pode assustar o usurio, ele tende a querer ver o portugus arcaico. Para que o Portugus Estruturado tenha alguma utilidade para o analista , tem que ser aceito pelo usurio.


31

5.


5.1.2. Tabelas de Deciso A Tabela de Deciso a ferramenta mais utilizada quando o processo deve produzir alguma sada ou executar aes com base em decises complementares. A Tabela de Deciso ajuda a considerar um programa de ao em sua composio, para avali-lo quanto perfeio e consistncia. Ela nos fornece uma maneira objetiva de identificar todas as combinaes possveis. A Tabela de Deciso deve ser usada quando a seleo de subprograma de ao depende de combinaes de condies. A vantagem da Tabela de Deciso ajudar a documentar o entendimento do analista com o usurio, e ajudam a encontrar situaes que no foram totalmente especificada. 5.1.2.1. Vantagens da Tabela de Deciso

Ajuda a considerar um programa de ao em sua composio, para avali-lo quanto perfeio e consistncia. Ela nos fornece uma maneira objetiva de identificar todas as combinaes possveis. Deve ser usada quando a seleo de subprograma de ao dependendo de combinaes de condies. Ajuda a documentar o entendimento do analista com o usurio Ajuda a encontrar situaes que no foram totalmente especificada. 5.1.2.2. Desvantagens da Tabelas de Deciso

Difcil saber algumas vezes quando iniciar uma formulao na Tabela de Deciso. Os usurios no esto familiarizados com a Tabela. Ela no nos fornece um quadro ntido da estrutura. As Tabelas de Decises so confusas para aqueles que nunca tenham-na visto antes.


32

5.


EXEMPLOS : 1- EXEMPLO DE TABELAS DE ENTRADA LIMITADA CONDIES AES C1 C2 C3 A1 A2 Mais de um milho por ano ? Bom histrico de pagamento ? Conosco a mais de 20 anos ? Tratamento prioritrio 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. : S/N

X

-> eqivale a se -> eqivale a ento

Existe vrias maneiras de nos certificarmos de que todas as possibilidades foram cobertas e que nenhuma tenha sido repetida. 1. Calcular o nmero total de regras -> N1 x N2 x Nn condies) ( onde Ni = n de

2. Criar as linhas de condio e ao e nmeros de colunas para todas as regras. CONDIES AES 3. Considerar a ltima condio e alternar suas possibilidades ao longo de toda linha CONDIES AES S N S N S


33

5.


4. Observar quantas vezes o padro se repete. Considerar a condio imediatamente acima e cobrir cada padro com um valor para esta prxima condio ( 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. Combinaes de condies ligadas s aes C1 C2 C3 A1 A2 6. Juntar as diferenas 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 Deciso temos : 1. Encontrar um par de regras para as quais : a ao seja a mesma ; os valores de condio sejam os mesmos, exceto em uma. 2. Substituir o par por uma regra e usar o smbolo de indiferena; 3. Repetir para qualquer par que atenda os critrios.


34

5.


2- EXEMPLO DE TABELAS DE ENTRADA AMPLIADA Neste caso as condies tem mais de dois valores : C1 - Mtodo Remessa C2 - Destino de A - areo T - terrestre L - local S - sul do RJ N - norte do RJ L - leve ( LE2) M - mdio ( GT2 e LE20 ) P - pesado ( GT20) R - Rpido N - 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 - Peso

C4 - Servio

Obs. Observar as combinaes inerentemente impossveis, ( C1- Areo + C2 - Local )


35

5.


5.1.3. rvore de Deciso rvore de Deciso a representao grfica de uma Tabela de Deciso , nada mais , nada menos. Devido sua aparncia familiar e apresentao grfica , uma rvore de Deciso funciona como uma ferramenta autodidtica. A representao grfica do exemplo seria :

Mais de 1 milho por ano

Bom histrico de pagamento Conosco h mais de 20 anos Conosco h 20 anos ou menos

Tratamento Prioritrio

Tratamento Prioritrio

Mau histrico de pagamento

Tratamento Normal

1 milho ou menos

Tratamento Normal

AREA TERRESTRE

LE2 GT2/LE20 GT20 LOCAL FORA do LOCAL

6 exato 3 unidade / libra 60 exato + 2 para cada libra acima de 20 normal rpido 2 u/l rpido GT20 2 u/l LE20 3 u/l normal 2 u/l


36

5.


5.1.4. Tabelas de Deciso X rvores de Deciso 1. Utilizar rvore de Deciso quando o nmero de decises for pequeno e nem toda combinao de condies for possvel; usar uma Tabela de Deciso quando o nmero de aes for grande e ocorram muitas combinaes de condies. 2. Utilizar uma Tabela de Deciso se existirem dvidas de que a rvore de Deciso mostra toda a complexidade do problema. 3. Mesmo que utilize-se a Tabela de Deciso para se descobrir a lgica , procurar represent-la como uma rvore , desde que a norma 1 no seja violada. 5.1.5. Vantagens / Desvantagens das Ferramentas USO Verificao Lgica Exibir Estrutura Lgica Simplicidade Verificao por Usurio Especificao de Prog. Leitura pelo Computador Averig. pelo Computador Alterabilidade RVORE DE DECISO RVORE DE DECISO Moderado Muito Bom (deciso) Muito Bom Bom Moderado Pobre Pobre Moderado TABELAS DE DECISO Muito Bom Moderado ( Deciso) Pobre Pobre Muito Bom Muito Bom Muito Bom Pobre PORTUGUS ESTRUTURADO Bom Bom Moderado Moderado Muito Bom Muito Bom Moderado Bom

melhor para verificao lgica ou decises moderadas ( at 15 aes), tambm so teis para mostrar uma Tabela de Deciso para o usurio. melhor em problemas de combinaes complexas ( at 6 condies). As Tabelas de Decises podem lidar com qualquer nmeros de aes; grande nmero de condies dificulta o manuseio. melhor para problemas que envolva combinao seqencial de aes com decises ou ciclos.

TABELA DE DECISO

PORTUGUS ESTRUTURADO


37

6.

Diagrama de E-R

6. DIAGRAMA DE E-R O Diagrama de Entidades-Relacionamentos um modelo em rede que descreve a diagramao dos dados armazenados de um sistema em alto nvel de abstrao. O modelo E-R prope que a realidade seja visualizada sob trs ponto de vista : os objetos que a compem ; os tipos de informaes ou caractersticas que se deseja conhecer sobre eles; forma como eles interagem entre si. O Diagrama E-R inteiramente diferente de um Diagrama de Fluxo de Dados, o qual modela as funes executadas por um sistema , e diferente do Diagrama de Transio de Estado, que modela o comportamento tempodependente de um sistema.O principal objetivo se chegar num modelo teoricamente independente da mquina. Este modelo constitudo por : Conjuntos de Entidades Conjuntos de Relacionamentos Conjuntos de Atributos 6.1. Entidades ( tipos de objetos) (Relacionamento Indicadores Associativo de Objetos) ( supertipos / subtipos)

O primeiro conceito esttico do modelo E-R o conceito de Entidade. Uma Entidade uma representao de um objeto do mundo real. Por exemplo, os produtos de uma organizao no so idnticos, pois possuem caractersticas diferentes, mas eles podem ser refletidos em um modelo que represente todos os produtos e os tipos de informaes ou de caractersticas que se conhece sobre eles. Outro aspecto importante no conceito de Entidade a possibilidade de individualizao de cada um dos objetos que compe o padro. Graficamente uma Entidade representada por um retngulo , com o nome da Entidade dentro com a 1 letra em maisculo.Cliente


38

6.

Diagrama de E-R

Para evitar redundncia na representao das informaes, deve-se impor que cada objeto do mundo real seja representado por uma nica entidade de um nico conjunto de Entidades. Algumas Entidades no existem por si s, ou seja, depende da existncia de uma outra Entidade, chamada Entidade Fraca Ex : EntidadeDependente

Esta

entidade

depende

da

Funcionrio

J as entidades tipo Generalizao o particionamento de uma Entidade supertipo em vrias Entidades subordinadas subtipo.Funcionrio

tipo

Engenheiro

Motorista

Os tipos de objetos subtipo/supertipo consistem em um objeto e uma ou mais subcategorias, interligadas por um relacionamento. A categoria supertipo ( Funcionrio) descrita por elementos da dados que se aplicam a todos os subtipos.Entretanto, cada subtipo (Engenheiro/Motorista) descrito por diferentes elementos de dados. Os subtipos so criados quando alguns elementos de dados no se aplicam a todas as instncias de um tipo de objeto. No exemplo acima, podemos considerar algumas caractersticas do Empregado Engenheiro que no se aplica a categoria de Motorista, e vice-versa. Ento podemos dizer , que durante o processo de refinamento de um Diagrama de E-R pode ocorrer que entidades diferentes descrevam elementos de dados comuns, neste caso preciso criar um supertipo e designar os elementos de dados comuns para o supertipo.


39

6.

Diagrama de E-R

Exemplo : Dado as entidades :Cliente Carto-deCrdito Cliente CartoDinheiro

Podemos definir :Cliente Carto-deCrdito

Cliente Carto-deCrdito

Cliente Carto-deCrdito

6.2.

Atributo

A Entidade Funcionrios representa um tipo, no qual so classificados todos os funcionrios da Organizao. No entanto , cada indivduo possui caractersticas prprias que devem ser diferenciadas. Por exemplo, cada funcionrio possui um nome, um salrio, um cargo, etc. Essas caractersticas de mesmo tipo so utilizadas pela Organizao para contratar , administrar, pagar e desligar funcionrios. Estes tipos de caractersticas so denominados Atributos de uma Entidade. A funo de um atributo mapear um conjunto de Entidades de um domnio. 6.2.1. Tipos de Atributos 1. MONOVALORADO 2. MULTIVALORADO 3. COMPOSTO - assume um nico valor . Ex. Nome - assume vrios valores. Ex. Telefone - so composto de um ou mais sub-atributos. Ex. Local

rua nmer o CEP


40

6.

Diagrama de E-R

4. DETERMINANTEFuncionrios

- quando assume um nico valor . Ex. CGC

Endereo Nome Telefones

CGC

N CEP Rua

O Atributo a menor decomposio de uma informao dentro de uma classe de dados. Quando temos um Atributo ou Grupos de Atributos que juntos assumem um valor nico e identifica uma Entidade, chamamos este Atributo de Chave Primria ou Atributo Determinante.Este valor no pode ser nulo.

Ex.Funcionriosmatricula ( 1atributo) triaatributo) Dependentes matric + sequecial ( 2 atributos)


41

6.

Diagrama de E-R

6.3.

Relacionamento

a relao existente entre duas ou mais Entidades. O Relacionamento indica a dinmica dos negcios , bem como as regras e polticas que os regem. O Relacionamento refletem as rotas lgicas de acesso s informaes , que so obtidas sobre vrios objetos do mundo real. Sua representao um losango , e o nome deve ser um verbo ;

Ex.

Clientes

Compra

Itens

importante reconhecer que o Relacionamento representa um conjunto de conexes. Cada instncia do Relacionamento representa uma associao entre zero ou mais ocorrncias de um objeto e zero ou mais ocorrncias de outro objeto. O Relacionamento representa alguma coisa que deve ser recordada pelo sistema alguma coisa que no pode ser calculada. 6.3.1. Cardinalidade dos Relacionamentos O modelo E-R, como toda representao, no a prpria realidade, mas foi desenvolvido para estar o mais prximo dela. Por isso, alm de representar as relaes de posse, envolvimento, composio e gerao, incorporou, tambm, um outro conceito para melhorar o conhecimento sobre as polticas e regras dos negcios. Este conceito chamado de Cardinalidade do Relacionamento. A cardinalidade define o nmero de ocorrncias de uma Entidade que pode estar envolvida em um relacionamento, sendo til para extrair da regras de consistncia e integridade dos dados. A cardinalidade indica a relao existente entre todas as linhas de uma Entidade A com todas as linhas de uma Entidade B.


42

6.

Diagrama de E-R

A cardinalidade um indicador de opcionalidade, unicidade e multiplicidade dos relacionamento entre duas Entidades, determinando o mnimo e o mximo de ocorrncias. 6.3.2. Classe de um Relacionamento De acordo com a cardinalidade, existem trs tipos bsicos de Relacionamento entre Entidades. 1. Um-para-um (1: 1).

Indica que uma nica ocorrncia de uma Entidade pode se relacionar com apenas uma nica ocorrncia de outra Entidade, a questo As duas entidades so realmente distintas ou elas podem ser unidas?. Uma propriedade importante neste tipo de relacionamento que os conjuntos (domnios e imagens) podem ser fundidos em um s, no caso de toda informao a respeito das entidades no forem distintas.gerencia

Funcionrios

Departamento

2.

Um-para-muitos (1 : N) Muitos-para-um (N: 1)

Indica que uma ocorrncia de uma entidade pode se relacionar com muitas ocorrncias de outra entidade. No entanto, a recproca no verdadeira. (Um caso particular o relacionamento 1 : 1) Cada entidade contm uma tabela contendo seus atributos. A chave da entidade UM parte da tabela que descreve a entidade MUITOS.

Funcionrios

N

lota

1

Departamento


43

6.

Diagrama de E-R

3.

Muitos-para-muitos

(N : N)

Indica que vrias ocorrncias de uma entidade podem se relacionar com vrias ocorrncias de outra entidade. Geralmente, um relacionamento deste tipo pode ser convertido e simplificado pela criao de uma entidade intermediria e de dois relacionamento Um-paraMuitos (Entidade-Associativa).

Pedidos

N

vende

N

Produtos

Em cada pedido, pode ser vendidos muitos produtos diferentes, e um produto pode ser vendidos por diversos pedidos. 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, criada para simplificar o relacionamento Muitos-para-Muitos, onde a chave primria composta das chaves primrias das entidades do relacionamento N:N.


44

6.

Diagrama de E-R

6.3.3. Natureza do Relacionamento Relacionamento Parcionais e Totais Relacionamento Recursivos ou Auto-Relacionamento Relacionamento Mltiplos Agregao Relacionamento Parcionais e Totais

Total - quando todo o elemento da entidade est obrigatoriamente no relacionamento, caso contrrio temos um relacionamento parcial.Funcionario N lota 1 Departamento

Todo funcionrio obrigatoriamente ( | ) lota um departamento, mas nem todo (0) departamento lotado por funcionrios Relacionamento Recursivos ou Auto-Relacionamento Os auto-relacionamentos so casos especiais onde uma Entidade se relaciona com si prpria. Os auto-relacionamentos podem ser de tipo Um-para-Um, Um-para-Muitos ou Muitos-para-Muitos.Funcionario

G ERE NCIA

1

N

G EREN CIA DO

G erencia

Funcionrio desempenha o papel de gerente ou de subordinado.


45

6.

Diagrama de E-R

Relacionamento Mltiplos a associao que envolve mais de duas Entidades.ProfessorN N

ensinaN Aluno

Disciplina

Obs. : Para entendermos este relacionamento devemos cortar uma das arestas e fazermos um relacionamento binrio. Ao associarmos um conjunto de Entidades e um Relacionamento temos uma Agregao.N Professor ensina N Disciplina

N cursa

N Aluno

O modelo E-R uma ferramenta valiosa para qualquer sistema com mltiplos depsitos (objetos) e complexos relacionamentos de dados. Ele inteiramente voltado para os relacionamentos de dados, sem oferecer quaisquer informaes sobre as funes que criam ou utilizam os dados.


46

6.

Diagrama de E-R

O equilbrio do modelo E-R em relao ao DFD. Cada depsito do DFD deve corresponder a um tipo de Entidade ou a um Relacionamento,ou a uma Entidade Associativa do DER. Se houver um depsito no DFD que no aparea no DER, algo est errado; e se houver uma Entidade ou um Relacionamento no DER que no aparea no DFD, tambm h algum errado; Os nomes das Entidades no DER e os dos Depsitos de dados no DFD devem coincidir. Os itens no Dicionrio de Dados devem aplicar-se tanto no modelo E-R como ao DFD.


47

6.

Diagrama de E-R

6.4.

Normalizao

Normalizao um processo formal passo-a-passo que examina os atributos de uma Entidade. Este processo causa a simplificao dos atributos dentro da respectiva tupla, eliminando grupos repetitivos, dependncias parcionais de chaves concatenadas, dependncias transitivas, dados redundantes e dependncia multivaloradas, colaborando significamente para a estabilidade do modelo, reduzindo-se consideravelmente as necessidades de manuteno. Para se atingir este estgio, necessrio que as tuplas sejam analisadas de forma a verificar se seus atributos apresentam relaes no-normalizadas submetendo-se aos conceitos subsequentes de cinco tipos de tabelas normalizadas. A normalizao um mecanismo para transformar estruturas complexas de dados em sua forma mais simples. Portanto, diz-se que uma estrutura de dados est normalizada quando est em seu estgio de maior simplicidade. Simplicidade de uma estrutura pode ser definida como a existncia de apenas dependncia funcional. Assim, uma tabela deve conter apenas informaes que se refiram a um mesmo tipo de dados, ou seja, todas as colunas da tabela devem depender funcionalmente da chave primria. Em resumo, a normalizao consiste em descobrir o lugar certo para cada coisa e colocar cada coisa em seu devido lugar. Os trs principais casos de anomalias que caracterizam uma estrutura desnormalizao so : Grupo Repetitivo - Conjunto de atributos de uma entidade que ocorre mltiplas vezes para cada ocorrncia da Entidade. - Quando um atributo depende de parte da chave primria (chave composta) - Dependncia indireta entre dois ou mais atributo

Dependncia Funcional Parcial Dependncia Transitiva


48

6.

Diagrama de E-R

O conceito de normalizao no modelo relacional foi introduzida por Codd em 1970, sendo posteriormente a 3FN aperfeioada por DATE. A 4FN e 5FN surgiram em 1977 num estudo feito por FAGIN. Para introduzimos os conceitos ligados exemplo prtico : Considere uma relao no normalizada : Nmero da ordem Cdigo do cliente Nome do cliente Endereo Cidade UF CEP Data de Despacho Observaes Cdigo Item Descrio Quantidade Embalagem Preo Unitrio Valor Total Impostos Total Geral Partindo da relao no-normalizada colocamos na 1FN. s formas normas utilizaremos um


49

6.

Diagrama de E-R

6.4.1. Primeira Forma Normal (1FN).

(tirar as repeties)

a normalizao da tupla, de forma que o relacionamento entre a sua chave e os seus atributos seja unvoca, ou seja, para cada chave h a ocorrncia de uma e somente uma informao de cada atributo. Em funo da presente definio, podemos afirmar que uma tupla na primeira forma normal s apresenta atributos com ocorrncia mnima de 0 (se opcional) ou de 1 (se obrigatrio). Na Primeira Forma Normal retira-se as repeties, neste caso cria-se uma nova entidade que herdar a chave primria da primeira (chave estrangeira) que far parte de sua chave primria. Ento podemos dizer que : Uma relao est na 1FN se todo os atributos bsicos de uma tabela contiverem somente um valor para cada tupla. A maneira prtica de encontrarmos a 1FN : Separar em uma relao os atributos que tenham mais de um valor no documento fonte, (ocorrncias repetidas). Identificar o atributo que permita uma dependncia funcional direta ou indireta dos outros atributos em relao a ele (chave primria) Para conservar a propriedade reversvel desta projeo, deve-se inserir como parte da chave primria em primeiro nvel de importncia, a chave da relao fonte, estabelecendo relacionamento natural entre as entidades. Ento, ficaro separados em duas relaes os atributos simples e mltiplas ocorrncias.


50

6.

Diagrama de E-R

RELAO NO NORMALIZADA CP* Nmero da ordem Cdigo do Cliente Nome do Cliente Endereo Cidade UF CEP Data de Despacho Observaes Cdigo Item Descrio Quantidade Embalagem Preo Unitrio Valor Total Impostos Total Geral

Mltiplas Ocorrncias

Mltiplas Ocorrncias Cdigo Item Descrio Quantidade Embalagem Preo Unitrio


51

6.

Diagrama de E-R

(1FN) PRIMEIRA FORMA NORMAL (tirar as repeties) Simples Ocorrncias CP* Nmero da ordem Cdigo do cliente Nome do cliente Endereo Cidade UF CEP Data de Despacho Observaes Valor Total Impostos Total Geral Mltiplas Ocorrncias Nmero da Ordem Cdigo Item Descrio Quantidade Embalagem Preo Unitrio Valor

CP* *

CE CE


52

6.

Diagrama de E-R

6.4.2. Segunda Forma Normal (2FN) (Verificar se h dependncia entre chaves) A Entidade dever est na 1FN. Caso haja chave concatenada (formada por mais de um atributos), verificar se existe atributos que dependam parcialmente da chave e neste caso criar uma nova entidade para estes atributos. Dizemos que uma relao est na 2FN se todos os atributos que no so chaves, ou que compem uma chave primria forem funcionalmente dependente total da chave-primria. A dependncia funcional normalmente no garantida quando a chave primria composta. Na 2FN deveremos nos preocupar com as ocorrncias mltiplas. 1. Separar as chaves dependentes Examinar a relao do ponto de vista de chave primria. Verificar se tem chave concatenada Encontrar as chave dependentes. 2. Gerar uma nova relao onde um atributo dependa da chave primria atravs de uma chave dependentes. Os atributos no-chave primria devem sempre estar em Dependncia Funcional-Total na 2FN em todas as mltiplas ocorrncias. Na 2FN todos os atributos depende unicamente da chave concatenada ou no concatenada.


53

6.

Diagrama de E-R

1FN DEPENDNCIA FUNCIOANAL Simples Ocorrncias CP* Nmero da Ordem Cdigo do Cliente Nome do Cliente Endereo Cidade UF CEP Data de Despacho Observaes Valor Total Impostos Total Geral Mltiplas Ocorrncias Nmero da Ordem Cdigo Item Descrio Quantidade Embalagem Preo Unitrio Valor

CP* *

CE CE

(PROJEO) Cdigo Item Descrio Embalagem Preo Unitrio

CP*


54

6.

Diagrama de E-R

(2FN) SEGUNDA FORMA NORMAL

SIMPLES OCORRNCIA CP* Nmero da Ordem Cdigo do Cliente Nome do Cliente Endereo Cidade UF CEP Data de Despacho Observaes Valor Total Impostos Total Geral

MLTIPLAS OCORRNCIAS CP* Nmero da Ordem Cdigo do Item Quantidade Valor

SIMPLES OCORRNCIAS CP* Cdigo Item Descrio Embalagem Preo Unitrio


55

6.

Diagrama de E-R

6.4.3. Terceira Forma Normal (3FN) (verificar se h dependncia entre atributos) A Entidade dever est na 2FN . Caso haja atributos em uma entidade, que dependam de atributos no chave, dever ser criada uma nova entidade que ser formada por estes atributos dependentes, e a chave primria ser o atributo no chave da entidade original. Uma relao est na 3FN se todos os atributos no-chave forem dependentes diretos no transitivos da chave primria. A dependncia transitiva normalmente encontra-se em relaes de simples ocorrncias, onde alguns atributos dependem da chave primria atravs de uma chave alternativa. Na 3FN deveremos : 1. Olhar para as relaes de simples ocorrncias; 2. Verificar se tem atributos que sejam dependentes de outros ; 3. Eliminar as dependncias transitivas criando novas relaes; 4. Eliminar atributos obtidos por clculos a partir de outros atributos; 5. Cada nova relao ser composta pelos atributos que dependam funcionalmente da chave alternativa. Deve-se criar tantas relaes quantas chaves alternativas sejam encontradas; A chave alternativa deve-se conservar na relao fonte como chave estrangeira ( propriedade reversvel).


56

6.

Diagrama de E-R

2FN BUSCA AS DEPENDNCIAS TRANSITIVAS Simples Ocorrncias CP* Nmero da Ordem Cdigo do Cliente Nome do Cliente Endereo Cidade UF CEP Data de Despacho Observaes Valor Total Impostos Total Geral MLTIPLAS OCORRNCIAS CP* Nmero da Ordem Cdigo do Item Quantidade Valor

Dependncia Transitiva Cdigo do Cliente Nome do Cliente Endereo Cidade UF CEP

SIMPLES OCORRNCIAS CP* Cdigo Item Descrio Embalagem Preo Unitrio


57

6.

Diagrama de E-R

(3FN) TERCEIRA FORMA NORMAL CADASTRO DE CLIENTE Cdigo de Cliente CP* Nome do Cliente Endereo Cidade UF CEP CADASTRO DE ORDEM Nmero de Ordem CE Cdigo do Cliente Data de Despacho Observaes Valor Total Impostos Total Geral

CP*

CP*

CADASTRO PEAS Cdigo Item

DE CP*

CADASTRO DE PEDIDOS Nmero da Ordem CE*

Descrio Embalagem Preo Unitrio

*

Cdigo do Item Quantidade Valor

CE*


58

6.

Diagrama de E-R

6.4.4. Quarta Forma Normal (4FN) Uma tabela de 3FN tambm est na 4FN se ela no contiver mais do que um fato multivalorado a respeito da entidade descrita pela tabela. Quando aplicamos a 4FN desmembramos em n tuplas , residentes em n entidades, sendo n igual ao nmero de atributos no -chaves constante da tupla original qual apresentem multivalorao. Cada uma das novas tuplas herdar tambm a chave inicial. 1. Verificar se existe atributos no chaves multivalorados e independentes, associados ao mesmo valor da chave; 2. Desfazer os atributos no-chaves multivalorados, criando novas tuplas individualizadas, para cada um deles, residentes em entidades distintas, herdando tambm a chave original. Ex. : Entidades com Dependncia Multivalorada Fornecedor Pea Comprador F1 P1 C1 F1 P2 C1 F1 P3 C2 Passando para 4FN teremos : Fornecedor / Pea Cod-pea Cod-forn Fornecedor/Compr ador Cod-forn Cod-comp


59

7. Diagrama de Transies de Estado

7. DIAGRAMA DE TRANSIES DE ESTADO Diagrama de Transies de Estado a ferramenta de modelagem que enfatiza o comportamento tempo-dependente do sistema 7.1. Os Componentes de um Diagrama de Transies de Estado

7.1.1. Estados do Sistema

Um Estado do Sistema caracterizado por uma pessoa ou objeto em determinado momento. So exemplos de estados tpicos : Aguardando que o usurio introduza uma senha. Aquecendo uma mistura qumica. Acelerando o motor. Misturando ingredientes. Enchendo o tanque.


60


7.1.2. Mudanas de Estados

As Mudanas de Estados so representadas por uma seta interligando os pares de Estado relevantes. Ex.

INATIVO

Aguardando Chamada

Gravando Mensagem

Rebobinando

Tocando as Mensagens

Respondendo Chamada


61


7.1.3. Condies e Aes

ESTADO

1

Condio AoESTADO

2

Uma Condio no DTE representa um evento no ambiente externo que o sistema seja capaz de detectar, podendo ser um sinal, uma interrupo ou a chegada de um pacote de dados. Para cada mudana de estado, o sistema normalmente empreender uma ou mais aes, como por exemplo : apresentar uma mensagem no terminal do usurio, efetuar um clculo, etc. 7.2. Normas P/ Desenhar um DTE

Identificar todos os estados possveis do sistema; Interligar os estados representado as mudanas de estado entre os retngulos; Comear o DTE pelo estado inicial; Fazer a consistncia do DTE considerando: Todos os estados foram definidos? Todos os estados podem ser atingidos? Todos os estados tm sada?


62

Documents

Análise Estruturada