Diagrama de entidades relacionamentos (abordado anteriormente) Diagrama de Fluxo de Dados (DFD)

Transcrição

1 Diagrama de entidades relacionamentos (abordado anteriormente) Prod_Forn N N 1 Stock 1 1 N Prod_Enc N 1 N 1 Fornecedor Movimento Encomenda Diagrama de Fluxo de Dados (DFD) Ferramenta de modelação gráfica, da análise estruturada, que permite representar um sistema como uma rede de actividades ligadas por canais e armazéns de dados. É uma das ferramentas mais usadas quando as actividades do sistema a modelar são mais complexas do que os dados que o sistema manipula. dá-nos uma só visão do sistema, a visão orientada por funções ou actividades A modelação funcional de um sistema permite responder a questões que podem ser formuladas de diferentes formas: Que funções têm de ser desempenhadas pelo sistema? Que interacções existem entre essas funções? Que transformações tem de ser efectuadas pelo sistema? Que entradas são transformadas em saídas? Que tipo de trabalho executa o sistema? Onde obtém informação para executar este trabalho? Onde é que a entrega de resultados se processa? Análise Estruturada 4

2 Componentes de um DFD Produção Guia de saída Requisição 1 Verificar e actualizar saídas Stock Movimento Terminadores ou Entidades Externas Categorias lógicas de coisas ou pessoas fora dos limites do sistema considerado, mas que interagem com ele. Representam uma origem ou destino de dados. Tipicamente são indivíduos, grupos de pessoas, departamentos ou divisões da organização, sistemas externos ou organizações externas. Exemplos: Produção (Departamento da organização, mas que não pertence ao sistema, supondo que o sistema a modelar engloba somente, por exemplo, a gestão de stocks) Fornecedor (Um fornecedor interage com o sistema através do envio de guias de remessa e facturas, mas está fora do controlo do sistema) Análise Estruturada 5

3 Depósito de dados Colecções ou elementos de dados que o sistema necessita de armazenar. Cada depósito de dados tem um nome que deve sugerir o respectivo conteúdo. Exemplos: Stock (Dados de stock de produtos a armazenar) Fornecedor (Dados de fornecedores a armazenar) Fluxo de dados Canal por onde circula informação. Representa movimentação de itens de dados de uma parte do sistema para outra, ao contrário dos depósitos de dados que representam dados estáticos. O nome de um fluxo deve permitir associar imediatamente o respectivo conteúdo. Exemplos: Requisição (Conjunto de dados que descrevem um pedido de um ou vários produtos ao armazém) Encomenda (Conjunto de dados que descrevem uma encomenda) Análise Estruturada 6

4 Processos Os processos são centros transformadores de fluxos de entrada em fluxos de saída. Representam actividades ou componentes funcionais do sistema a modelar. Os processos devem ser numerados e devem ter um nome. Os nomes a atribuir aos processos devem sugerir a tarefa que esse processo desempenha. Exemplo: Verificar e actualizar saídas (Processo que transforma o fluxo de entrada Requisição no fluxo de saída Guia_de_saída, através da verificação e actualização das existências em Stock e do registo da saída em Movimento, para cada produto contido no fluxo Requisição.) Note-se que a actualização das existências em Stock e o registo da saída em Movimento só ocorrem se o produto existir no stock. Contudo, este aspecto é um detalhe a descrever na especificação interna do processo. Análise Estruturada 7

5 Exemplo de DFD Sistema de Gestão de stock (simplificado) Guia de saída Produção Fornecedor Diálogo fornecimento 1 Requisição Novo produto 2 Verificar e actualizar saídas Stock Registar produto Fornecedor Movimento Prod_Forn 3 Registar entradas Encomenda Prod_Enc 4 Encomendar produtos Fornecedor Guia de remessa Fornecedor Encomenda Análise Estruturada 8

6 Aspectos importantes relativamente a terminadores A identificação e delimitação do sistema a modelar pressupõe a separação entre os elementos que são parte integrante do sistema e os elementos exteriores ao sistema. Contudo, elementos considerados exteriores comunicam com o sistema, sendo então necessário representar estes elementos, o que é feito através de terminadores. Assim sendo, podemos referir os seguintes aspectos: Os terminadores não pertencem ao sistema a modelar. Fluxos que ligam terminadores a processos representam interface entre o sistema e o ambiente; O analista não pode alterar o conteúdo, a organização ou procedimentos internos associados a terminadores, pois estes estão fora do seu controlo; Relacionamentos existentes entre terminadores não são representados pois não fazem parte do sistema. Se estes relacionamentos são essenciais para sistema a modelar, então os terminadores não são terminadores, mas sim partes integrantes do sistema a modelar; As ligações mais usuais entre os terminadores e o sistema a modelar são fluxos de dados. Contudo, um terminador pode ser outro sistema, com o qual é necessário comunicar, através de um depósito de dados externo. Neste caso, pode utilizar-se uma representação como a exemplificada seguidamente. Exemplo: Modelação de um sistema de gestão da produção. Sistema de gestão comercial: sistema já implementado, com o qual se comunica através do depósito de dados Encomenda Gestão Comercial Encomenda 1 Elaborar plano de produção Análise Estruturada 9

7 Aspectos importantes relativamente a fluxos e depósitos de dados Os Fluxos de dados: têm uma direcção que indica o sentido em que circulam; têm como origens e destinos todos os outros elementos de um DFD; têm um nome, que representa o significado dos dados que circulam, devendo este ser único e sugestivo. Fluxos de diálogo São fluxos especiais com 2 direcções e 2 nomes que permitem representar dois fluxos de dados do tipo pergunta e resposta. (Exemplo: Diálogo fornecimento) Algumas questões a que DFD não responde: Fluxos de entrada num processo representam pedidos de informação a outra parte do sistema, ou pedidos de leitura ao utilizador, ou envio de informação por outra parte do sistema por iniciativa da parte emissora? Fluxos de saída num processo representam pedidos de informação de outra parte do sistema, ou envio de informação para outra parte do sistema por iniciativa do processo? Quantos itens de dados existem em cada fluxo de dados? Em que sequência chegam as entradas? Em que sequência são produzidas as saídas? Quantas ocorrências de cada fluxo de dados de entrada são necessários para produzir uma saída? Estas questões envolvem detalhes a especificar na modelação interna dos processos. Análise Estruturada 10

8 Fluxos de dados ligados a depósitos de dados são interpretadas como operações sobre os dados do depósito. Estas operações podem ser de dois tipos, consoante o sentido dos fluxos: Operação de leitura não destrutiva (leitura ou consulta) Operação de alteração do depósito (alteração, inserção ou remoção) Sendo o significado de um fluxo de dados ligado a um depósitos de dados mais simples de interpretar, em que casos se pode omitir o nome de um fluxo? Existem 2 teorias : Fluxos de dados ligados a depósitos de dados não precisam de nome; Fluxos de dados cujo conteúdo coincide com uma instância completa de um depósitos de dados não necessitam de nome. A partir do sentido de um fluxo de dados ligado a um depósito de dados podemos representar dois tipos de operações. Contudo, considerando uma operação de consulta, os casos possíveis de existência de um fluxo de dados são: Consulta de uma instância completa; Consulta de um conjunto de instâncias completas que obedecem a um critério; Consulta de uma parte de uma instância; Consulta de uma parte de um conjunto de instâncias que obedecem a um critério. Análise Estruturada 11

9 Nem todas as questões têm resposta pela simples observação de um fluxo de dados. para conhecer todos os detalhes relacionados com um fluxo de dados é necessário examinar a especificação interna do processo ao qual o fluxo está ligado. Só existe uma certeza, um depósito de dados é um elemento passivo, logo, os dados não circulam de um depósitos através de um fluxo, a não ser que um processo os requisite. Exemplos de representação de operações sobre depósitos de dados: Operação Representação Inserção ou remoção de um cliente. Cliente Consulta do Nº de telefone de um cliente a partir do seu código. Cliente Nºtelefone Cliente Alteração do Nº de telefone de um cliente a partir do seu código. Cliente Nºtelefone Cliente #Cliente Nºtelefone Cliente Questão: Um depósitos de dados existe devido a requisito especificado por utilizador ou devido a aspecto conveniente de implementação? Um depósito de dados existe devido a desfasamento temporal na necessidade dos dados por dois ou mais processos que ocorrem em instantes diferentes. Análise Estruturada 12

10 Hierarquia ou existência de vários níveis de detalhe em DFD s Os DFD s analisados até ao momento modelam sistemas simples ou foram apresentados parcialmente. Os sistemas reais a modelar são maiores e mais complexos. Questão: Como representar sistemas com muitos processos, sem abdicar da ausência de complexidade num DFD? A solução consiste em organizar um DFD em sucessivos níveis de refinamento, de forma a que cada nível proporcione mais detalhes acerca de uma parte do nível acima. Esta característica é única nos DFD e proporciona um mecanismo muito útil para representar vários níveis de detalhe. Cada processo num DFD pode, ou não, estar expandido num DFD de nível inferior, o que permite distinguir dois tipos de processos: Processos não primitivos Processos cujo detalhe é descrito utilizando um novo DFD de nível inferior. O DFD de nível inferior terá o mesmo número e nome do processo correspondente do nível superior. Processos Primitivos Não originam novos DFD s, sendo objecto de uma descrição utilizando uma linguagem apropriada. Esta descrição especifica a forma de transformação de fluxos de entrada em fluxos de saída e não deve ultrapassar um página. Análise Estruturada 13

11 Diagrama de fluxo de dados com múltiplos níveis Diagrama de contexto Sistema Visão muito geral do sistema: Possui um só processo que representa todo o sistema como uma caixa preta; Mostra interacção entre sistema e terminadores (fluxos e depósitos externos) Diagrama Visão global do sistema: Mostra os principais processos do sistema; Visualiza fluxos e depósitos de dados partilhados por processos; Mostra ainda a interacção entre sistema e terminadores. Diagrama Detalhe do processo 3 do Diagrama 0 (Os terminadores podem ser novamente incluídos nos diagramas de nível inferior, pois, essa redundância conduz a maior clareza na leitura do diagrama) A numeração de cada diagrama sugere assim o respectivo grau de detalhe. Contudo, a numeração não indica qualquer tipo de sequência entre a informação. A numeração é efectuada para identificação e estruturação de níveis. Análise Estruturada 14

12 Principais características dos DFD s Não modelam aspectos como o sincronismo e sequenciação Os DFD s são um modo de representação de fluxo de dados e processos assíncronos. Por outro lado, não representam a sequência de chegada de fluxos, nem a sequência em que são produzidas as saídas. Assim, o modelo das actividades fica livre de complexidade extra, tornando-o mais fácil de elaborar e manter. A este nível só interessa identificar processos e dados que circulam entre estes. Não especificam o funcionamento interno dos processos As componentes de um DFD dizem-nos como é um processo sem definir como este funciona. A especificação interna do processo, o suporte textual para as actividades de mais baixo nível, define o que as actividades devem fazer. Não são fluxogramas As decisões são tomadas dentro dos processos e nunca são representadas nos DFD s; Estruturam-se em vários níveis de detalhe Os DFD s dão uma visão do sistema do geral para o particular. A sucessão de vários diagramas sugere essa estruturação. São ferramentas de modelação lógica Os DFD s permitem representar aspectos lógicos, não físicos. A sua elaboração deve ser independente da tecnologia de implementação, devendo ignorar-se aspectos que são dependentes de restrições físicas de implementação. O modelo lógico também se designa por modelo essencial, ou seja, a essência do sistema. Análise Estruturada 15

13 Regras para a estruturação dos DFD s Os DFD s devem respeitar algumas regras, a saber: Número máximo de objectos Um DFD não deve ter mais do que 7 (+/- 2) processos (número de objectos que a mente humana é capaz de abarcar simultaneamente). Este número faz com que cada DFD caiba numa folha com formato A4. Consistência entre os vários níveis de detalhe Cada DFD deve estar equilibrado em relação ao processo que o originou, ou seja, o conjunto de fluxos de entrada e saída desse DFD, deve ser equivalente ao conjunto de fluxos de entrada e saída do processo que lhe deu origem. Consistência entre as várias ferramentas de modelação As várias ferramentas de modelação têm de ser consistentes e compatíveis entre si. A consistência entre DFD s e DER s é assegurada garantindo que cada depósito de dados de um DFD corresponde a uma das entidades do DER. Representação de depósitos de dados acedidos por vários processos Num DFD não é necessário representar depósitos de dados que apenas são relevantes no interior de cada um dos seus processos. Como corolário poderá dizer-se que, se um depósito de dados é utilizado por mais do que um processo do mesmo DFD, então esse depósito deve ser representado. Dimensão máxima da especificação de um processo primitivo A especificação de um processo primitivo não deve ultrapassar uma página. Se a especificação do processo possui uma dimensão superior a uma página, significa que este é complexo e que não é primitivo, e que é necessário detalhar o processo num DFD de nível inferior. Análise Estruturada 16

14 Sugestões para a construção de DFD s Escolher nomes sugestivos para processos, fluxos, depósitos e terminadores. Não usar nomes de pessoas, mas sim a designação do papel que representam; Não usar nomes de mecanismos, dispositivos ou meios físicos usados para transportar dados. Exemplo: Em vez de Telefonema usar Pedido e em vez de Operador de entrada de dados usar Cliente, ou seja a origem; A política utilizada para dar nomes a processos consiste em utilizar um verbo e um objecto, ou seja, a actividade e o objecto associado. Não se deve usar, contudo, nomes ambíguos do tipo: processar dados, tratar entradas e funções variadas. Não desenhar DFD s complexos Desenhar DFD com poucos objectos, para facilitar a sua leitura; Minimizar cruzamentos entre fluxos de dados, da seguinte forma: 1º redesenhar o diagrama distribuindo objectos da forma mais favorável; 2º se necessário, duplicar terminadores (assinalar com traço na diagonal); 3º se necessário, duplicar os depósitos de dados ( ); 4º permitir o cruzamento de fluxos de dados, desde que não exista nenhuma estrutura que reduza as intersecções. Para simplificar diagramas de contexto, cuja elaboração pressupõe a representação de todas as interacções com o exterior, quando estes apresentam uma leitura difícil: consolidar fluxos de dados com terminadores comuns; desenhar diagramas de contexto diferentes para grupos com interesses diferentes, omitindo aspectos não relevantes para cada grupo. Análise Estruturada 17

15 Assegurar alguma consistência entre profundidade dos níveis de detalhe das várias partes do sistema. Se o processo 2 requer 3 níveis de detalhe (por exemplo 2., 2.1. e ) os restantes processos 1, 3, etc. também devem ter 3 níveis de detalhe? Não, mas se, por exemplo, o processo 2 é primitivo e o processo 3 possui 7 níveis de detalhe, podemos concluir que o sistema não foi bem organizado. Redesenhar o DFD as vezes que forem necessárias. A construção de um DFD é um processo iterativo. Assim sendo, um DFD deve ser redesenhado várias vezes, de forma a garantir: a modelação adequada do sistema em estudo; correcção técnica; estética agradável; consistência interna e em relação a outros modelos utilizados, como DER, DTE, DD e especificação de processos. Concentrar a elaboração do DFD na política subjacente que tem de ser levada a cabo e não nos procedimentos usados para sustentar essa política, ou seja, na essência do sistema. Análise Estruturada 18

16 Extensão de DFD s para modelar sistemas em tempo real Sistemas em tempo real Sistemas que controlam o ambiente através da recepção de dados, seu processamento e devolução de resultados em tempo suficientemente curto, de forma a afectar o ambiente no momento. Sistemas em tempo real VS Sistemas on-line Os sistemas em tempo real distinguem-se dos sistemas on-line pela necessidade de um tempo de resposta menor. Por outro lado, ao contrário dos sistemas online que normalmente interagem com pessoas, os sistemas em tempo real também interagem com o ambiente, reagindo e captando dados, e/ou controlando o ambiente. Exemplos: Sistemas de aquisição de dados de alta velocidade, sistemas de controlo de processos, etc. Devido a necessidade de tratar sinais e interrupções do ambiente, bem como, de controlar e sincronizar actividades, para estes sistemas necessitamos de modelar: Fluxos de controlo Processos de controlo Fluxo de controlo Representa um canal que transporta um sinal binário, que é enviado de um processo para outro, ou de um terminador para um processo, com o intuito de activar um processo que se encontra suspenso. Análise Estruturada 19

17 Processo de controlo (supervisor ou executivo) É um processo supervisor cuja única função é coordenar e sincronizar as actividades de outros processos de um DFD. As suas saídas e entradas consistem somente em fluxos de controlo. As saídas são usadas para acordar outros processos. As entradas significam que outro processo terminou a sua tarefa, ou que surgiu uma situação extraordinária que deve ser notificada ao processo. Representação de fluxos e processos de controlo Os fluxos e processos de controlo são representados num DFD a tracejado. Processo normal VS processo de controlo Um processo normal, que possui um fluxo de controlo de entrada, depois de acordado comporta-se como um processo normal. O comportamento de um processo de controlo é diferente, sendo modelado por um diagrama de transição de estados, que mostra os vários estados que o sistema pode ter e as circunstâncias que levam à alteração de estado. Exemplo: Sinal X activar processo 2 1 X P.C. Sinal Y activar processo 3 Y 2 3 Análise Estruturada 20