Trading House Automation System Dfd

1 Design de Software Orientado a Função (continuação) Palestra 6 Prof. R. Mall Departamento de CSE, IIT, Kharagpur. Apresentação no tema: 1 Design de Software Orientado a Função (continuação) Palestra 6 Prof. R. Mall Departamento de CSE, IIT, Kharagpur. Transcrição de apresentação: 1 1 Design de software orientado a função (continuação) Palestra 6 Prof. R. Mall Departamento de CSE, IIT, Kharagpur 2 2 Exemplo 3: Sistema de automação de casas de comércio (TAS) Uma grande casa de negociação quer que desenvolvamos uma Software: para automatizar atividades de manutenção de livros associadas ao seu negócio. Tem muitos clientes regulares: quem faz pedidos para vários tipos de mercadorias. 3 3 Exemplo 3: Sistema de Automação de Câmbio (TAS) A casa de negociação mantém nomes e endereços de seus clientes regulares. Cada cliente recebe um número de identificação de cliente exclusivo (CIN). De acordo com a prática atual quando um cliente coloca ordem: o departamento de contas primeiro verifica o mérito do cliente. 4 4 Exemplo: Sistema de Automação de Câmbio (TAS) O valor de crédito de um cliente é determinado: Analisando o histórico de seus pagamentos às contas enviadas para ele no passado. Se um cliente não é digno de crédito: Suas ordens não são processadas mais adiante. Uma mensagem de rejeição de ordem apropriada é gerada para o cliente. 5 5 Exemplo: Sistema de automação de casas de câmbio (TAS) Se um cliente é digno de crédito: os itens que ele ordenou são verificados em relação à lista de itens que a casa comercial trata. Os itens que a casa comercial não lida com: Não são processados ​​mais adiante. Uma mensagem apropriada para o cliente para esses itens é gerada. 6 6 Exemplo: Trading-House Automation System (TAS) Os itens em uma ordem de clientes que a casa comercial trata: São verificados quanto à disponibilidade no inventário. Se os itens estiverem disponíveis no inventário nas quantidades desejadas: uma conta com o endereço de encaminhamento do cliente é impressa. Um impresso de problema material é impresso. 7 7 Exemplo: Sistema de automação de casas comerciais (TAS) O cliente pode produzir o boletim de emissão material na loja: pegue a entrega dos itens. Dados de estoque ajustados para refletir a venda ao cliente. 8 8 Exemplo: Sistema de automação de casas de câmbio (TAS) Se um item ordenado não estiver disponível no inventário em quantidade suficiente: Para poder atender pedidos pendentes, armazene detalhes em um arquivo de ordem pendente. Itens fora do estoque juntamente com a quantidade encomendada. Número de identificação do cliente 9 9 Exemplo: Sistema de automação da casa comercial (TAS) O departamento de compras: emitir periodicamente comandos para gerar recortes. Quando o comando gerar indícios é emitido: o sistema deve examinar o arquivo de ordem pendente Determinar os pedidos pendentes quantidade total necessária para cada um dos itens. 10 10 Exemplo: Sistema de automação de casa comercial (TAS) O TAS deve descobrir os endereços dos fornecedores que fornecem os itens necessários: Examine o arquivo contendo detalhes do fornecedor (seu endereço, itens que eles fornecem, etc.) Imprima os recortes para esses vendedores. 11 11 Exemplo: Sistema de Automação de Câmbio (TAS) O TAS também deve responder consultas gerenciais: Estatísticas de diferentes itens vendidos em qualquer período de tempo Correspondente da quantidade vendida e do preço realizado. 12 12 Diagrama de Contexto Trading - House - Automation - System 0 Manager CustomerPurchase - Estatísticas de consulta do Departamento resposta da ordem Gerar - indent indent 13 13 Nível 1 DFD Aceitar-order 0.1 Process-order 0.2 Handle - indent-request 0.4 Handle - query 0.3 pending-order Inventário de estatísticas de vendas Lista de fornecedores Arquivo do cliente Arquivo do item Histórico do cliente Excesso de indentação Solicitação de estatísticas de solicitação de pedidos aceitos Número da conta de emissão de material 14 14 Exemplo: Resposta do dicionário de dados: material de conta-edição-deslizamento, mensagem de rejeição Consulta: consulta de período do gerente em relação ao período de estatísticas de vendas: datado, mês, ano, data do dia: ano mês dia ano: mês inteiro: dia inteiro: ordem inteira: customer-id pedido-aceito: encomendar itens solicitados disponíveis no inventário rejeitar-mensagem : Mensagem de rejeição de mensagem de ordem pendente-ordens: customer-id endereço do cliente: namehousestreetcitypin 15 15 Exemplo: Data Dictionary item-name: string house: string street: string city: string pin: i Nteger customer-id: contagem de números inteiros: quantidade total de material de endereço do cliente-issue-slip: quantidade de item de mensagem mensagem de endereço de cliente: estatísticas de string: statistics de vendas: quantity: integer 16 16 Observação Dos exemplos, Observe que DFDs ajudam a criar : Modelo de dados Modelo de função 17 17 Observação Como um DFD é refinado em maiores níveis de detalhe: o analista executa uma decomposição funcional implícita. Ao mesmo tempo, os refinamentos de dados ocorrem. 18 18 Diretrizes para a construção de DFDs O diagrama de contexto deve representar o sistema como uma única bolha: muitos iniciantes cometem o erro de desenhar mais do que uma bolha no diagrama de contexto. 19 19 Diretrizes para a construção de DFDs Todas as entidades externas devem ser representadas no diagrama de contexto: entidades externas não devem aparecer em nenhum outro nível de DFD. Apenas de 3 a 7 bolhas por diagrama devem ser permitidas: cada bolha deve ser decomposta para entre 3 e 7 bolhas. 20 20 Diretrizes para a construção de DFDs Um erro comum cometido por muitos iniciantes: tentando representar informações de controle em um DFD. por exemplo. Tentando representar a ordem em que diferentes funções são executadas. 21 21 Diretrizes para a construção de DFDs Um DFD não representa informações de controle: Quando ou em que ordem são invocadas diferentes funções (processos) As condições em que diferentes funções são invocadas não são representadas. Por exemplo, uma função pode invocar uma função ou outra dependendo de alguma condição. Muitos iniciantes tentam representar esse aspecto desenhando uma flecha entre as bolhas correspondentes. 22 22 Exemplo-1 Verifique o valor de entrada: Se o valor de entrada for menor ou maior do que gerar uma mensagem de erro, caso contrário, procure o número Chec k numb er Generado Erro Searc número de mensagem do número h encontrado, não encontrado 23 23 Diretrizes para Construindo DFDs Se uma bolha A invoca bolha B ou bolha C dependendo de algumas condições: representa os dados que flui da bolha A para a bolha B e as bolhas A para C não as condições dependendo de qual processo é invocado. 24 24 Exemplo 2 Uma função aceita o nome do livro a ser pesquisado do usuário Se o nome do livro inserido não for um nome válido do livro Gera uma mensagem de erro, Se o nome do livro for válido, Procura o nome do livro no banco de dados. Get-book-name Print-err - mensagem Search-book Error - message Nome do livro Good-book - name Book-details 25 25 Diretrizes para a construção de DFDs Todas as funções do sistema devem ser capturadas no modelo DFD: Nenhuma função especificada em O documento SRS deve ser ignorado. Somente as funções especificadas no documento SRS devem ser representadas: não assumir funcionalidades extras do sistema não especificadas pelo documento SRS. 26 26 Erros comumente feitos DFD não desequilibrados Esquecendo de mencionar os nomes dos fluxos de dados Funções ou dados não representados Fontes externas aparecendo em DFDs de nível superior Tentando representar aspectos de controle Diagrama de contexto com mais de uma bolha Uma bolha decomposta em muitas bolhas no próximo nível Terminando a decomposição demasiado cedo Nouns utilizados na denominação de bolhas 27 27 As deficiências dos modelos DFD modelo DFD sofrem de várias deficiências: os DFDs deixam ampla margem para ser imprecisos. Em um modelo DFD, inferimos sobre a função realizada por uma bolha de seu rótulo. Um rótulo pode não capturar toda a funcionalidade de uma bolha. 28 28 Falhas do modelo DFD Por exemplo, uma bolha chamada find-book-position tem apenas um significado intuitivo: não especifica várias coisas: o que acontece quando algumas informações de entrada estão faltando ou estão incorretas. Não transmite nada sobre o que acontece quando o livro não é encontrado ou o que acontece se houver livros de diferentes autores com o mesmo título de livro. 29 29 As falhas das informações do DFD Model Control não estão representadas: por exemplo, a ordem em que as entradas são consumidas e as saídas produzidas não são especificadas. Aceitar - order Process-order Arquivo do cliente Item-arquivo Histórico do cliente Aceito - pedidos ordem inventário 30 30 Falhas do DFD Modelo A DFD não especifica aspectos de sincronização: Por exemplo, o DFD no exemplo TAS não especifica: A ordem pode aguardar até que a ordem de aceitação produza dados Se a ordem de aceitação e a ordem de manipulação podem prosseguir simultaneamente com algum mecanismo de buffer entre eles. 31 31 TAS: Nível 1 DFD Aceitar - order Process-order Handle - indent - request Handle - consulta pendente-order Vendas-estatísticas inventário Lista de fornecedores Arquivo do cliente Arquivo do item Histórico do cliente Indent-request Indents Aceito - ordens consulta estatísticas de ordem 32 32 Falhas do modelo DFD A forma como a decomposição é realizada para chegar aos níveis sucessivos de DFD é subjetiva. O nível final ao qual a decomposição é realizada é subjetivo: Depende da escolha e do julgamento do analista. Mesmo para o mesmo problema, várias representações DFD alternativas são possíveis: muitas vezes não é possível dizer qual representação DFD é superior ou preferível. 33 33 As deficiências da técnica DFD modelo DFD não fornecem: qualquer orientação clara sobre como exatamente deve-se fazer uma decomposição de uma função: é preciso usar julgamento subjetivo para realizar a decomposição. As técnicas de análise estruturada não especificam quando parar um processo de decomposição: a que comprimento a decomposição precisa ser realizada. 34 34 Extensão da técnica DFD para sistemas em tempo real Para sistemas em tempo real (sistemas com limites de tempo em suas ações), Essencial para o fluxo de controle do modelo e eventos. Técnica amplamente aceita: técnica de Ward e Mellor. É introduzido um tipo de processo (bolhas) que lida somente com fluxos de controle. Esses processos são representados usando círculos tracejados. 35 35 Projeto estruturado O objetivo do projeto estruturado Transformar os resultados da análise estruturada (ou seja, uma representação DFD) em um gráfico de estrutura. Um gráfico de estrutura representa a arquitetura do software: vários módulos que compõem o sistema, dependência do módulo (ou seja, qual módulo chama quais outros módulos), parâmetros passados ​​entre diferentes módulos. 36 36 Gráfico de estrutura Representação da estrutura gráfica Facilmente implementável usando linguagens de programação. Foco principal de um gráfico de estrutura: Definir a estrutura do módulo de um software, Interação entre diferentes módulos, Os aspectos processuais (por exemplo, como uma funcionalidade específica é alcançada) não são representados. 37 37 Blocos de construção básicos da estrutura Caixa rectangular: uma caixa retangular representa um módulo. Anotado com o nome do módulo que representa. Ordem de processo 38 38 Setas Uma seta entre dois módulos implica: Durante o controle de execução é passado de um módulo para o outro na direção da seta. Process-orderHandle-indent root Handle-query 39 39 Fluxo de dados Arrows As setas de fluxo de dados representam: Dados que passam de um módulo para outro na direção da seta. Ordem de raiz de ordem de processo 40 40 Módulos de biblioteca Os módulos de biblioteca representam módulos freqüentemente chamados: um retângulo com bordas laterais duplas. Simplifica o desenho quando um módulo é chamado por vários módulos. Quick-sort 41 41 Seleção O símbolo de diamante representa: Um módulo de vários módulos conectados ao símbolo de diamante é invocado dependendo de alguma condição. Process-orderHandle-indent root Handle-query 42 42 Repetição Um loop em torno das setas de fluxo de controle indica que os módulos em questão são invocados repetidamente. Process-orderHandle-indent root Handle-query 43 43 Gráfico de estrutura Existe apenas um módulo na parte superior: o módulo raiz. Existe no máximo uma relação de controle entre dois módulos: se o módulo A invoca o módulo B, o Módulo B não pode invocar o módulo A. O principal motivo por trás dessa restrição: considere módulos em um gráfico de estrutura a serem organizados em camadas ou níveis. 44 44 Gráfico de estrutura O princípio da abstração: não permite que módulos de nível inferior invocem módulos de nível superior: Mas, dois módulos de nível superior podem invocar o mesmo módulo de nível inferior. 45 45 Exemplo de raiz Get-good-data Solução de computação Solução de exibição Dados de obtenção Dados de validação Valores-válidos rms 47 47 Falhas da estrutura Gráfico Ao olhar para um gráfico de estrutura: não podemos dizer se um módulo chama outro módulo apenas uma vez Ou muitas vezes. Além disso, olhando para um gráfico de estrutura: não podemos dizer a ordem em que os diferentes módulos são invocados. 48 48 Fluxograma (além) Estamos todos familiarizados com as representações do diagrama de fluxo: o gráfico de fluxo é uma técnica conveniente para representar o fluxo de controle em um sistema. AB se (c 100) P20 mais p 80 enquanto (p20) imprime (marca do aluno) AB P20P80 Imprimir sim não simbólico sim não 20) imprimir (marca do aluno) AB P20P80 Imprimir sim não manequim sim não 49 49 Fluxograma versus estrutura Gráfico A O gráfico de estrutura difere de um fluxograma de três maneiras principais: é difícil identificar módulos de um software a partir da representação do fluxograma. O intercâmbio de dados entre os módulos não está representado em um fluxograma. A ordenação sequencial de tarefas inerentes a um fluxograma é suprimida em um gráfico de estrutura. 50 50 Transformação de um modelo DFD em diagrama de estrutura Duas estratégias existem para orientar a transformação de um DFD em um gráfico de estrutura: Análise de transformação Análise de transação 51 51 Análise de transformação O primeiro passo na análise de transformação: Divida o DFD em 3 partes: entrada, processamento lógico , Saída. 52 52 Porção de Entrada de Análise de Transformação no DFD: processos que convertem dados de entrada de forma física a lógica. por exemplo. Leia caracteres do terminal e armazene em tabelas ou listas internas. Cada porção de entrada: chamado ramo aferente. Possível ter mais de um ramo aferente em um DFD. 53 53 Transform Analysis Output portion of DFD: transforma os dados de saída da forma lógica para a forma física. por exemplo. Da lista ou da matriz em caracteres de saída. Cada porção de saída: chamado de ramo eferente. As porções restantes de um DFD chamado transformada central 54 54 Análise de transformação Derivam o gráfico de estrutura desenhando um componente funcional para: a transformada central, cada ramo aferente, cada ramo eferente. 55 55 Análise de transformação Identificando as transformações de entrada e saída de nível mais alto: requer experiência e habilidade. Algumas diretrizes: Trace as entradas até encontrar uma bolha cuja saída não pode ser deduzida das entradas sozinhas. Processos que validam a entrada não são transformações centrais. Os processos que classificam dados de entrada ou filtro são. 56 56 Análise de transformação Primeiro nível de gráfico de estrutura: desenhe uma caixa para cada entrada e unidades de saída Uma caixa para a transformação central. Em seguida, aperfeiçoe o gráfico de estrutura: adicione as subfunções requeridas por cada módulo de alto nível. Muitos níveis de módulos podem ser adicionados. 57 57 Factoring O processo de quebrar componentes funcionais em subcomponentes. O factoring inclui a adição: módulos de leitura e escrita, módulos de tratamento de erros, módulos de inicialização e terminação, etc. Finalmente verifique: se todas as bolhas foram mapeadas para módulos. 58 58 Exemplo 1: RMS Cálculo de Software Compute - RMS 0 Dados de Usuário - resultado de itens Diagrama de Contexto 59 59 Exemplo 1: RMS Cálculo de Software De uma análise superficial da descrição do problema, é fácil ver que o sistema precisa executar: aceitar os números de entrada Do usuário, valide os números, calcule o quadrado médio da raiz dos números de entrada, exiba o resultado. 60 60 Exemplo 1: RMS Cálculo de Software Dados - resultado dos itens Lido-números 0,1 Validar-números 0,2 Calculadores 0,3 Visor 0,4 RMS números Válido - números erro 61 61 Exemplo 1: RMS Cálculo de Software Ao observar o Nível 1 DFD: Identificar leitura - Número e número de números de validação como o ramo aferente exibir como o ramo eferente. 62 62 Exemplo 1: RMS Cálculo da raiz do software Get-good-data Compute-solution Display-solution Dados obtidos Validar dados Válidos rms 63 63 Exemplo 2: Tic-Tac-Toe Computer Game Assim que qualquer um dos jogadores humanos Ou o computador ganha, uma mensagem que felicita o vencedor deve ser exibida. Se nenhum dos dois jogadores consegue obter três marcas consecutivas ao longo de uma linha reta, e todos os quadrados do quadro estão preenchidos, então o jogo é desenhado. O computador sempre tenta ganhar um jogo. 65 65 Placa DFD de nível 1 Placa de exibição Vencimento de cheque Validar - mover Jogo de jogada de movimento mover 66 66 Estrutura Gráfico raiz Get-good-moveCompute-gameDisplay Get-move Validar - mover play-move Cheque-vencedor 67 67 Análise de transações Útil Para projetar programas de processamento de transações. Sistemas centrados em transformação: caracterizados por etapas de processamento semelhantes para cada item de dados processado por bolhas de entrada, processo e saída. Sistemas orientados por transação, Um dos vários caminhos possíveis através do DFD é percorrido de acordo com o valor de dados de entrada. 68 68 Transação de transação de transação: qualquer valor de dados de entrada que aciona uma ação: por exemplo, as opções de menu selecionadas podem desencadear funções diferentes. Representado por uma etiqueta identificando seu tipo. A análise de transações usa essa tag para dividir o sistema em: Vários módulos de transações Um módulo de centro de transação. 69 69 Análise de transação Centro de transações trans 1 trans 2 trans 3 tipo 1tipo 2tipo 3 70 70 Nível 1 DFD para TAS Aceptar ordem Ordem de processo Solicitação de indução de manípulo Pega-consulta pendente-ordem Inventário de estatísticas de vendas Lista de fornecedores Cliente - Arquivo Arquivo de itens Histórico do cliente Excesso de recuo Execções Estatísticas de pedidos de consulta de pedidos aceitos 71 71 Estrutura Gráfico raiz Ordem de manobraInstalação de manequim Consulta de solicitação Get-order Aceitar-pedirProcessar pedido travessão de consulta de pedido 72 72 Resumo Discutimos primeiro a análise estruturada de um Maior problema. Definimos algumas diretrizes gerais para a construção de um modelo DFD satisfatório. O modelo DFD, embora simples e útil, tem várias saídas curtas. Em seguida, começamos a discutir o design estruturado. 73 73 Resumo Objetivo do projeto estruturado: Transformar uma representação DFD em um gráfico de estrutura. O gráfico de estrutura representa: estrutura do módulo Interação entre diferentes módulos, os aspectos processuais não são representados. 74 74 Resumo O design estruturado fornece duas estratégias para transformar um DFD em um gráfico de estrutura: Análise de transformação Análise de transações 75 75 Resumo Discutimos três exemplos de design estruturado. É preciso muita prática para se tornar um bom designer de software: tente resolver todos os problemas listados na sua folha de atribuição, não apenas os que você deve enviar. Projeto de software orientado a funcionalidade (continuação): Palestra 6 Dr. R . Centro comercial. 2 Organização desta Palestra zBrief revisão de palestras anteriores zA exemplo maior de Análise Estruturada zStructured Design yA principal objetivo desta palestra é que você deve ser capaz de desenvolver design estruturado a partir de qualquer modelo DFD. ZExamples zSummary 3 Revisão da última conferência zLast conferência iniciamos a discussão sobre a técnica estruturada de estrutura estruturada (SA SD): incorpora recursos de algumas metodologias de design importantes. O zSA SD consiste em duas partes importantes: análise estruturada e design estruturado. 4 Análise da última leitura zO objetivo da análise estruturada: decomposição funcional do yperform. Você representa usando Diagramas de fluxo de dados (DFDs). Os zDFDs são um modelo hierárquico: nós examinamos por que qualquer modelo hierárquico é fácil de entender. O número 7 é chamado de número mágico. 5 Análise da última leitura zDuração da análise estruturada: a decomposição funcional ocorre além do yin, ocorre a decomposição dos dados. ZA o nível mais abstrato: diagrama ycontext erefined para níveis mais detalhados. ZNós discutimos dois pequenos exemplos: software de cálculo de yRMS software de jogo de computador itic-tac-toe 6 Revisão da última leitura zSeveral CASE ferramentas estão disponíveis yhelp em atividades de design: yhelp mantenha o dicionário de dados, verifique se DFDs são balanceados, etc. modelo zDFD: ydifficult Para implementar usando uma linguagem de programação: os eneeds devem ser transformados em design estruturado. 7 Exemplo 3: Sistema de Automação de Câmbio (TAS) zA grande casa de negociação quer que desenvolvamos um software: para automatizar atividades de manutenção de livros associadas ao seu negócio. ZIt tem muitos clientes regulares: você faz pedidos para vários tipos de mercadorias. 8 Exemplo 3: Sistema de Automação de Câmbio (TAS) zA casa comercial mantém nomes e endereços de seus clientes regulares. ZTodos os clientes recebem um número de identificação de cliente exclusivo (CIN). ZAs por prática atual quando um cliente coloca ordem: o departamento de contas primeiro verifica o mérito do cliente. 9 Exemplo: Trading-House Automation System (TAS) z A credibilidade de um cliente é determinada: analisando o histórico de seus pagamentos nas contas enviadas para ele no passado. ZIf um cliente não é digno de crédito: suas ordens não são processadas mais, e uma mensagem apropriada de rejeição de ordem é gerada para o cliente. 10 Exemplo: sistema de automação da casa de câmbio (TAS) zSe um cliente é digno de crédito: os pedidos que ele ordenou são verificados em relação à lista de itens que a casa comercial trata. ZOs itens com os quais a casa de negociação não lida: você não processou mais nenhuma mensagem adicional para o cliente para esses itens. 11 Exemplo: Sistema de automação de casa de câmbio (TAS) zOs itens em uma ordem de clientes que a casa de negociação lida com: y são verificados quanto à disponibilidade no inventário. Z Se os itens estiverem disponíveis no inventário nas quantidades desejadas: a conta do sítio com o endereço de encaminhamento do cliente é impressa. O impresso de assunto material é impresso. 12 Exemplo: sistema de automação da casa comercial (TAS) z O cliente pode produzir o boletim de problema material na loja: entrega dos itens. Dados do Yinventory ajustados para refletir a venda ao cliente. 13 Exemplo: Sistema de automação de casas de câmbio (TAS) z Se um item encomendado não estiver disponível no inventário em quantidade suficiente: para poder realizar pedidos pendentes, armazene detalhes em um arquivo de ordem pendente. Itens de xout-of-stock, juntamente com a quantidade encomendada. Xcustomer number number 14 Exemplo: Trading-House Automation System (TAS) zO departamento de compras: emitir periodicamente comandos para gerar recortes. ZQuando gerar indentação, o comando é emitido: o sistema deve examinar o arquivo de ordem pendente, determine as ordens que estão pendentes da quantidade total necessária para cada um dos itens. 15 Exemplo: Sistema de automação de casas de câmbio (TAS) O zTAS deve descobrir os endereços dos fornecedores que fornecem os itens necessários: leia o arquivo contendo os detalhes do vendedor (seu endereço, itens que eles fornecem, etc.) imprime os vendedores para esses vendedores. 16 Exemplo: Sistema de automação de casa comercial (TAS) O zTAS também deve responder a consultas gerenciais: estimativas de itens diferentes vendidos em qualquer período de tempo, conforme a quantidade vendida e o preço realizado. 17 Diagrama de Contexto Trading-House - Automação - Sistema 0 Gerente CustomerPurchase - Departamento de estatísticas de consulta resposta de ordem Gerar-travessão travessão 18 Nível 1 DFD Aceitar-ordem 0,1 Processar-ordem 0,2 Handle - indent-request 0,4 Handle - consulta 0,3 pendente-order Sales - Inventário de estatísticas Lista de fornecedores Arquivo de clientes Arquivo de itens Histórico de clientes Excesso de indentação Pedido de estatísticas de consulta de pedidos aceitos Projeto de lei de material-emissão-deslizamento 19 Exemplo: Dicionário de dados zresponse: material de conta-edição-deslizamento, mensagem de rejeição zquery: período Consulta do gerente em relação às estatísticas de vendas zperiod: dateate, month, year, day zdate: ano mês dia zyear: integer zmonth: integer zday: integer zorder: customer-id zaccepted-order: ordem itens solicitados disponíveis no inventário zreject-message: order message Mensagem de rejeição zpending-orders: customer-id zcustomer-address: namehousestreetcitypin 20 Exemplo: Dicionário de dados zitem-name: string zhouse: string zstreet: string zcity: string zpin: integer zcusto Mer-id: inteiro zbill: total-quantidade endereço do cliente zmaterial-issue-slip: quantidade do item da mensagem endereço do cliente zmessage: string zstatistics: zsales-statistics: zquantity: integer 21 Observação zNos exemplos, eobserve que DFDs ajudam a criar: xdata Modelo modelo xfalogia 22 Observação zAs DFD é refinado em maiores níveis de detalhe: o analista executa uma decomposição funcional implícita. Ao mesmo tempo, os refinamentos de dados ocorrem. 23 Diretrizes para a construção de DFDs O diagrama do zContext deve representar o sistema como uma única bolha: muitos novatos cometem o erro de desenhar mais do que uma bolha no diagrama de contexto. 24 Diretrizes para a construção de DFDs z Todas as entidades externas devem ser representadas no diagrama de contexto: as entidades externas não devem aparecer em nenhum outro nível de DFD. ZOnly 3 a 7 bolhas por diagrama devem ser permitidas: a bolha de Yeach deve ser decomposta para entre 3 e 7 bolhas. 25 Diretrizes para a construção de DFDs z Erro comum cometido por muitos iniciantes: tentando representar informações de controle em um DFD. Ye. g. Tentando representar a ordem em que diferentes funções são executadas. 26 Diretrizes para a construção de DFDs zA DFD não representa informações de controle: ywhen ou em que ordem diferentes funções (processos) são invocadas e as condições em que as diferentes funções são invocadas não são representadas. Por exemplo, uma função pode invocar uma função ou outra dependendo de alguma condição. Muitos novatos tentam representar esse aspecto desenhando uma flecha entre as bolhas correspondentes. 27 Exemplo-1 zVerifique o valor de entrada: y Se o valor de entrada for menor ou maior do que gerar uma mensagem de erro, procure o número Chec k numb er Generado Erro Searc número de mensagem do número h encontrado, não encontrado 28 Diretrizes para a construção de DFDs Z Se uma bolha A invoca bolha B ou bolha C dependendo de algumas condições: represente os dados que flui da bolha A para a bolha B e as bolhas A para C e não as condições dependendo de qual processo é invocado. 29 Exemplo-2 A função zA aceita o nome do livro a ser procurado a partir do usuário. Se o nome do livro inserido não for um nome de livro válido egenerates uma mensagem de erro, zSe o nome do livro for válido, você pesquisará o nome do livro no banco de dados. Get-book-name Print-err - mensagem Search-book Error-message Nome do livro Good-book-name Book-details 30 Diretrizes para a construção de DFDs zTodas as funções do sistema devem ser capturadas no modelo DFD: a função yno especificada no O documento SRS deve ser ignorado. ZOnly as funções especificadas no documento SRS devem ser representadas: você não assume funcionalidade adicional do sistema não especificado pelo documento SRS. 31 Erros comumente cometidos zDiferentes DF equilibrados zEscreva-se para mencionar os nomes dos fluxos de dados. Funções ou dados representados. Entidades zExternal aparecendo em DFDs de nível superior. ZTrying para representar aspectos de controle. Diagrama zContext com mais de uma bolha. Bolha zA em decomposição em muitas bolhas no próximo nível zTerminando Decomposição muito cedo ZNouns utilizados na nomeação de bolhas 32 Falhas dos Modelos DFD Modelos zDFD sofrem de várias deficiências: os ZDFDs deixam ampla margem para ser imprecisos. Y Em um modelo DFD, inferimos sobre a função realizada por uma bolha de seu rótulo. Um rótulo pode não capturar toda a funcionalidade de uma bolha. 33 Falhas do modelo DFD Exemplo de zFor, uma bolha chamada find-book-position tem apenas um significado intuitivo: você não especifica várias coisas: x o que acontece quando algumas informações de entrada estão faltando ou estão incorretas. XDoes não transmite nada sobre o que acontece quando o livro não é encontrado xor o que acontece se houver livros de diferentes autores com o mesmo título de livro. 34 Falhas do modelo DFD As informações de zControl não estão representadas: yPara exemplo, a ordem em que as entradas são consumidas e as saídas produzidas não são especificadas. Aceito - ordem Processo-pedido Arquivo do cliente Arquivo do item Histórico do cliente Inventário de pedidos de pedidos aceitos 35 Falhas do Modelo DFD zA O DFD não especifica aspectos de sincronização: por exemplo, o exemplo DFD no TAS não especifica: xwhether process-order Pode esperar até que a ordem de aceitação produz dados x se a ordem de aceitação e a ordem de manipulação podem prosseguir simultaneamente com algum mecanismo de buffer entre eles. 36 TAS: Nível 1 DFD Aceitar - ordem Ordem do processo Manipular-indent-request Handle - consulta pendente-pedido Inventário de estatísticas de vendas Lista de fornecedores Arquivo do cliente Arquivo do item Histórico do cliente Indent-request Indents Pedido de estatísticas de consulta de pedidos aceitos 37 Falhas do Modelo DFD A maneira como a decomposição é realizada para chegar aos níveis sucessivos de um DFD é subjetiva. Z O último nível ao qual a decomposição é realizada é subjetivo: dependem da escolha e do julgamento do analista. Por outro lado, para o mesmo problema, são possíveis várias representações DFD alternativas: muitas vezes não é possível dizer qual representação DFD é superior ou preferível. 38 As deficiências da técnica do modelo DFD zDFD não fornecem: uma orientação clara sobre a maneira como exatamente deve ocorrer uma decomposição de uma função: você precisa usar julgamento subjetivo para realizar a decomposição. As técnicas de análise zStructured não especificam quando parar um processo de decomposição: o que comprimento de decomposição precisa ser realizado. 39 Extensão da técnica DFD para sistemas em tempo real zFor sistemas em tempo real (sistemas com limites de tempo em suas ações), fluxo de controle e eventos do modelo para o modelo. Técnica bem aceita: técnica de Ward e Mellor. O tipo de processo xa (bolhas) que manipula apenas fluxos de controle é introduzido. XEsses processos são representados usando círculos tracejados. 40 Projeto estruturado zO objetivo do projeto estruturado etransformar os resultados da análise estruturada (ou seja, uma representação DFD) em um gráfico de estrutura. O gráfico de estrutura do zA representa a arquitetura do software: módulos variados que compõem o sistema, dependência do módulo y (ou seja, qual módulo chama quais outros módulos), eparâmetros passados ​​entre diferentes módulos. 41 Gráfico de estrutura A representação do gráfico zStructure é implementável usando linguagens de programação. ZMain foco de um gráfico de estrutura: define a estrutura do módulo de um software, a interação entre diferentes módulos, os aspectos eprocedurais (por exemplo, como uma funcionalidade específica é alcançada) não são representados. 42 Blocos de construção básicos do gráfico de estrutura caixa zRectangular: uma caixa retangular representa um módulo. Eannotado com o nome do módulo que representa. Ordem de processo 43 Setas A flecha zAn entre dois módulos implica: o controle de execução é passado de um módulo para o outro na direção da seta. Process-orderHandle-indent root Handle-query 44 Fluxo de dados Arrows zData flow flows representam: ydata passando de um módulo para outro na direção da seta. Ordem de ordem de ordem de processo 45 Módulos de biblioteca Os módulos de zLibrary representam módulos freqüentemente chamados: y um retângulo com bordas laterais duplas. ySimplifies drawing when a module is called by several modules. Quick-sort 46 Selection zThe diamond symbol represents: yone module of several modules connected to the diamond symbol is invoked depending on some condition. Process-orderHandle-indent root Handle-query 47 Repetition zA loop around control flow arrows denotes that the concerned modules are invoked repeatedly. Process-orderHandle-indent root Handle-query 48 Structure Chart zThere is only one module at the top: ythe root module. zThere is at most one control relationship between any two modules: yif module A invokes module B, ymodule B cannot invoke module A. zThe main reason behind this restriction: yconsider modules in a structure chart to be arranged in layers or levels. 49 Structure Chart zThe principle of abstraction: ydoes not allow lower-level modules to invoke higher - level modules: yBut, two higher-level modules can invoke the same lower-level module. 50 Example root Get-good-dataCompute-solutionDisplay-solution Get-data Validate-data Valid-numbers rms 52 Shortcomings of Structure Chart zBy looking at a structure chart: ywe can not say whether a module calls another module just once or many times. zAlso, by looking at a structure chart: ywe can not tell the order in which the different modules are invoked. 53 Flow Chart (Aside) zWe are all familiar with the flow chart representations: yFlow chart is a convenient technique to represent the flow of control in a system. zAB zif(c 100) z P20 zelse p 80 zwhile(p20) z print(student mark) AB P20P80 Print yes no dummy yes no 20) z print(student mark) AB P20P80 Print yes no dummy yes no 54 Flow Chart versus Structure Chart zA structure chart differs from a flow chart in three principal ways: yIt is difficult to identify modules of a software from its flow chart representation. yData interchange among the modules is not represented in a flow chart. ySequential ordering of tasks inherent in a flow chart is suppressed in a structure chart. 55 Transformation of a DFD Model into Structure Chart zTwo strategies exist to guide transformation of a DFD into a structure chart: yTransform Analysis yTransaction Analysis 56 Transform Analysis zThe first step in transform analysis: ydivide the DFD into 3 types of parts: xinput, xlogical processing, xoutput. 57 Transform Analysis zInput portion in the DFD: yprocesses which convert input data from physical to logical form. ye. g. read characters from the terminal and store in internal tables or lists. zEach input portion: ycalled an afferent branch. yPossible to have more than one afferent branch in a DFD. 58 Transform Analysis zOutput portion of a DFD: ytransforms output data from logical form to physical form. xe. g. from list or array into output characters. yEach output portion: xcalled an efferent branch. zThe remaining portions of a DFD ycalled central transform 59 Transform Analysis zDerive structure chart by drawing one functional component for: ythe central transform, yeach afferent branch, yeach efferent branch. 60 Transform Analysis zIdentifying the highest level input and output transforms: yrequires experience and skill. zSome guidelines: ytrace the inputs until a bubble is found whose output cannot be deduced from the inputs alone. yProcesses which validate input are not central transforms. yProcesses which sort input or filter data from it are. 61 Transform Analysis zFirst level of structure chart: ydraw a box for each input and output units ya box for the central transform. zNext, refine the structure chart: yadd subfunctions required by each high-level module. yMany levels of modules may required to be added. 62 Factoring zThe process of breaking functional components into subcomponents. zFactoring includes adding: yread and write modules, yerror-handling modules, yinitialization and termination modules, etc. zFinally check: ywhether all bubbles have been mapped to modules. 63 Example 1: RMS Calculating Software Compute - RMS 0 User Data - items result Context Diagram 64 Example 1: RMS Calculating Software zFrom a cursory analysis of the problem description, yeasy to see that the system needs to perform: xaccept the input numbers from the user, xvalidate the numbers, xcalculate the root mean square of the input numbers, xdisplay the result. 65 Example 1: RMS Calculating Software Data - items result Read - numbers 0.1 Validate - numbers 0.2 Compute - rms 0.3 Display 0.4 RMS numbers Valid - numbers error 66 Example 1: RMS Calculating Software zBy observing the level 1 DFD: yidentify read-number and validate-number bubbles as the afferent branch ydisplay as the efferent branch. 67 Example 1: RMS Calculating Software root Get-good-dataCompute-solutionDisplay-solution Get-data Validate-data Valid-numbers rms 68 Example 2: Tic-Tac-Toe Computer Game zAs soon as either of the human player or the computer wins, ya message congratulating the winner should be displayed. zIf neither player manages to get three consecutive marks along a straight line, yand all the squares on the board are filled up, ythen the game is drawn. zThe computer always tries to win a game. 70 Level 1 DFD board Display - board Check - winner Validate - move Play - move move result game 71 Structure Chart root Get-good-moveCompute-gameDisplay Get-move Validate - move play-move Check - winner 72 Transaction Analysis zUseful for designing transaction processing programs. yTransform-centered systems: xcharacterized by similar processing steps for every data item processed by input, process, and output bubbles. yTransaction-driven systems, xone of several possible paths through the DFD is traversed depending upon the input data value. 73 Transaction Analysis zTransaction: yany input data value that triggers an action: yFor example, selected menu options might trigger different functions. yRepresented by a tag identifying its type. zTransaction analysis uses this tag to divide the system into: yseveral transaction modules yone transaction-center module. 74 Transaction analysis Transaction - center trans 1 trans 2 trans 3 type 1type 2type 3 75 Level 1 DFD for TAS Accept - order Process - order Handle - indent - request Handle - query pending-order Sales-statistics inventory Vendor-list Customer-file Item-file Customer-history Indent-request Indents Accepted-orders query order statistics 76 Structure Chart root Handle-orderHandle-indentHandle-query Get-order Accept-orderProcess - order order query indent 77 Summary zWe first discussed structured analysis of a larger problem. zWe defined some general guidelines yfor constructing a satisfactory DFD model. zThe DFD model though simple and useful ydoes have several short comings. zWe then started discussing structured design. 78 Summary zAim of structured design: ytransform a DFD representation into a structure chart. zStructure chart represents: ymodule structure yinteraction among different modules, yprocedural aspects are not represented. 79 Summary zStructured design provides two strategies to transform a DFD into a structure chart: yTransform Analysis yTransaction Analysis 80 Summary zWe Discussed three examples of structured design. zIt takes a lot of practice to become a good software designer: yPlease try to solve all the problems listed in your assignment sheet, y not only the ones you are expected to submit.