P. 1
coesao_acoplamento

coesao_acoplamento

|Views: 555|Likes:
Published by tcolsl

More info:

Published by: tcolsl on Oct 26, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

05/05/2013

pdf

text

original

Sections

  • 1. INTRODUÇÃO
  • 1.1 Proposta para o Projeto
  • 1.2 Os fundamentos do projeto
  • 1.2.1 Contexto do Projeto
  • 1.2.2 Principais sintomas de um projeto inadequado
  • 1.3 Critérios de Qualidade do Projeto
  • 1.3.1 Completeza
  • 1.3.2 Manutenibilidade
  • 1.3.3 Performance
  • 1.3.4 Segurança
  • 1.3.5 Interatibilidade
  • 1.3.6 Confiabilidade
  • 1.3.7 Economia
  • 2. FASES DO PROJETO
  • 2.1 Modelo de Implementação do Sistema
  • 2.1.1 Modelo de Processador
  • 2.1.2 Modelo de Tarefa
  • 2.2 Modelo de Implementação de Programa
  • 3. DIAGRAMA DE ESTRUTURA MODULAR
  • 3.1 Introdução
  • 3.2 Componentes do DEM
  • 3.2.1 Módulo
  • 3.2.2 Hierarquia de Módulos
  • Figura 3.D: Exemplo de uma Hierarquia entre Módulos
  • Figura 3.E: Chamada condicional de Módulos
  • Figura 3.G: Tipo de parâmetros entre Módulos
  • 3.2.3 Tipos de Módulos
  • Figura 3.H: Tipos de Módulos
  • 3.2.4 Conector
  • Figura 3.I: Simbologia para Conectores
  • Figura 3.K: Exemplo do uso de Conector de Página
  • 3.2.5 Especificação de Módulos
  • 3.3 Critérios de Qualidade do DEM
  • 3.3.1 Acoplamento
  • Figura 3.L:Exemplo de Acoplamento de Dados
  • Figura 3.M: Exemplo de Acoplamento de Imagem
  • Figura 3.N: Exemplo de Acoplamento de Controle
  • Figura 3.O: Exemplo de Acoplamento Comum
  • Figura 3.P: Exemplo de Acoplamento de Conteúdo
  • 3.3.2 Comparação dos Tipos de Acoplamento
  • 3.3.3 Coesão
  • Figura 3.R:Exemplo de Coesão Sequencial
  • Figura 3.S: Exemplo de Coesão Comunicacional
  • Figura 3.T: Exemplo de Coesão Procedural
  • Figura 3.U: Exemplo de Coesão Temporal
  • Figura 3.W: Exemplo de Coesão Coincidental
  • 3.3.4 Determinação do Tipo de Coesão
  • 3.4 Diretrizes Adicionais do Projeto
  • 3.4.1 Factoring
  • 3.4.2 Divisão de Decisão
  • Figura 3.Z: Exemplo de um Diagrama sem Divisão de Decisão
  • 3.4.3 Formas de um Modelo
  • Figura 3.AA: Formato de um modelo Input-Driven
  • Figura 3.BB: Formato de um modelo Output-Driven
  • Figura 3.CC: Formato de um modelo Balanceado
  • 3.4.4 Informações de Erro
  • 3.4.5 FAN-OUT e FAN-IN
  • Figura 3.DD: Exemplo de um modelo com alto FAN-OUT
  • Figura 3.HH: Exemplo de um DEM derivado a partir de um DFD

PROJETO ESTRUTURADO DE SISTEMAS

FACULDADE DE TECNOLOGIA DE BIRIGUÍ - SP ORÁCULO CONSULTORIA DE SISTEMAS - RJ

Organizada por Gustavo Miranda Araújo - 1996 Revista por Alfredo Martins Muradas - 1997

Projeto Estruturado de Sistemas

ÍNDICE
1. INTRODUÇÃO
1.1 Proposta para o Projeto 1.2 Os fundamentos do projeto 1.2.1 Contexto do Projeto 1.2.2 Principais sintomas de um projeto inadequado 1.3 Critérios de Qualidade do Projeto 1.3.1 Completeza 1.3.2 Manutenibilidade 1.3.3 Performance 1.3.4 Segurança 1.3.5 Interatibilidade 1.3.6 Confiabilidade 1.3.7 Economia

1
1 3 3 3 4 4 4 4 5 5 6 6

2. FASES DO PROJETO
2.1 Modelo de Implementação do Sistema 2.1.1 Modelo de Processador 2.1.2 Modelo de Tarefa 2.2 Modelo de Implementação de Programa

7
7 7 9 10

3. DIAGRAMA DE ESTRUTURA MODULAR
3.1 Introdução 3.2 Componentes do DEM 3.2.1 Módulo 3.2.2 Hierarquia de Módulos 3.2.3 Tipos de Módulos 3.2.4 Conector 3.2.5 Especificação de Módulos 3.3 Critérios de Qualidade do DEM 3.3.1 Acoplamento 3.3.2 Comparação dos Tipos de Acoplamento 3.3.3 Coesão 3.3.4 Determinação do Tipo de Coesão 3.4 Diretrizes Adicionais do Projeto 3.4.1 Factoring 3.4.2 Divisão de Decisão 3.4.3 Formas de um Modelo 3.4.4 Informações de Erro 3.4.5 FAN-OUT e FAN-IN

11
11 12 12 13 16 17 19 20 20 24 25 30 32 32 32 34 37 37

I

Projeto Estruturado de Sistemas 3.5 Estratégia para Derivar o DFD para o DEM 3.5.1 Análise de Transformação 3.5.2 Análise de Transação 40 40 43

II

Projeto Estruturado de Sistemas

LISTA DE FIGURAS
FIGURA 3.1: SIMBOLOGIA DE REPRESENTAÇÃO DE MÓDULO FIGURA 3.2: SIMBOLOGIA DE REPRESENTAÇÃO DE MÓDULO PRÉ-DEFINIDO FIGURA 3.3: HIERARQUIA DE MÓDULOS FIGURA 3.4: EXEMPLO DE UMA HIERARQUIA ENTRE MÓDULOS FIGURA 3.5: CHAMADA CONDICIONAL DE MÓDULOS FIGURA 3.6: CHAMADA REPETITIVA DE MÓDULOS FIGURA 3.7: TIPO DE PARÂMETROS ENTRE MÓDULOS FIGURA 3.8: TIPOS DE MÓDULOS FIGURA 3.9: SIMBOLOGIA PARA CONECTORES FIGURA 3.10: EXEMPLO DE PARTE DE UM MODELO FIGURA 3.11: EXEMPLO DO USO DE CONECTOR DE PÁGINA FIGURA 3.12:EXEMPLO DE ACOPLAMENTO DE DADOS FIGURA 3.13: EXEMPLO DE ACOPLAMENTO DE IMAGEM FIGURA 3.14: EXEMPLO DE ACOPLAMENTO DE CONTROLE FIGURA 3.15: EXEMPLO DE ACOPLAMENTO COMUM FIGURA 3.16: EXEMPLO DE ACOPLAMENTO DE CONTEÚDO FIGURA 3.17: EXEMPLO DE COESÃO FUNCIONAL FIGURA 3.18:EXEMPLO DE COESÃO SEQUENCIAL FIGURA 3.19: EXEMPLO DE COESÃO COMUNICACIONAL FIGURA 3.20: EXEMPLO DE COESÃO PROCEDURAL FIGURA 3.21: EXEMPLO DE COESÃO TEMPORAL FIGURA 3.22: EXEMPLO DE COESÃO LÓGICA FIGURA 3.23: EXEMPLO DE COESÃO COINCIDENTAL FIGURA 3.24: ESTRATÉGIA PARA IDENTIFICAÇÃO DOS TIPOS DE COESÃO FIGURA 3.25: EXEMPLO DE UM DIAGRAMA COM DIVISÃO DE DECISÃO FIGURA 3.26: EXEMPLO DE UM DIAGRAMA SEM DIVISÃO DE DECISÃO FIGURA 3.27: FORMATO DE UM MODELO INPUT-DRIVEN FIGURA 3.28: FORMATO DE UM MODELO OUTPUT-DRIVEN FIGURA 3.29: FORMATO DE UM MODELO BALANCEADO FIGURA 3.30: EXEMPLO DE UM MODELO COM ALTO FAN-OUT FIGURA 3.31: EXEMPLO DE UM MODELO COM ALTO FAN-IN FIGURA 3.32: EXEMPLO DE DFD COM A IDENTIFICAÇÃO DO CENTRO DE TRANSFORMAÇÃO FIGURA 3.33: EXEMPLO DE UM DEM DERIVADO A PARTIR DE UM DFD FIGURA 3.34: EXEMPLO DE UM DEM DERIVADO A PARTIR DE UM DFD FIGURA 3.35: EXEMPLO DE DFD COM LIGAÇÕES ENTRE PROCESSOS VIA DEPÓSITO DE DADOS FIGURA 3.36 FIGURA 3.36: EXEMPLO DE UTILIZAÇÃO DE ANÁLISE DE TRANSAÇÃO 12 12 13 14 15 15 16 17 18 18 19 21 21 22 23 24 25 26 27 28 29 29 30 30 33 34 35 36 37 38 39 41 42 43 44 44

III

estão no fato desta ferramenta ser: • gráfica • particionável • rigorosa mas flexível • entrada usual para a implementação estruturada • documentação do sistema 1 . especialmente gráficas. 3) Utiliza ferramentas. 5) Oferece um conjunto de critérios para avaliar a qualidade de um dado projetosolução com respeito ao problema a ser resolvido. Projeto estruturado é uma abordagem disciplinada de projeto de sistemas computadorizados. e pela organização dessas “caixas pretas” em uma hierarquia conveniente para aimplementações computadorizadas. 4) Oferece um conjunto de estratégias para desenvolver o projeto da solução de uma declaração bem definida do problema. mas de ser usado na organização dos pensamentos dos programadores antes da codificação. 2) Procura a resolução da complexidade dos grandes sistemas através da segmentação de um sistema em “caixas pretas”. uma atividade que no passado foi notoriamente acidentada e cheia de problemas. A vantagem do uso do diagrama de estruturas.Projeto Estruturado de Sistemas 1.1 Proposta para o Projeto Projeto Estruturado de Sistemas é a atividade de transformação das necessidades do usuário. O projeto estruturado é uma das respostas para as falhas do passado. que é a principal ferramenta do projeto estruturado. Apesar de ser uma ferramenta da programação estruturada ela se torna muito útil na especificação das rotinas detalhadas a serem executadas pelas caixas pretas. provenientes da fase de Análise. O pseudo código é uma linguagem de especificação informal que não tem a intenção de ser executado em uma máquina. Nesta fase. possuindo cinco aspectos: 1) Permite que a forma do problema guie a forma da solução. passando a levar em consideração o hardware e software com todas as suas limitações. INTRODUÇÃO 1. organização e comunicação. Para tornar fácil o entendimento o Projeto Estruturado se utiliza basicamente de duas ferramentas principais: O pseudocódigo e o Diagrama de Estruturas. deixa-se de ter a tecnologia perfeita. em um plano de implementação através da automação eletrônica. para tornar os sistemas de fácil compreensão. A outra ferramenta é o diagrama de estruturas que ilustra a segmentação de um sistema em módulos mostrando a sua hierarquia.

Projeto Estruturado de Sistemas • um auxílio para a manutencão e modificações Qualquer informação que não puder ser descrita pelo diagrama de estrutura pode ser suprida por pseudo código ou por alguma outra descrição de módulos do gráfico de estrutura. a fase de Projeto procura prover os sistemas de facilidades para: • • • • construção testes modificações entendimento 2 . ou seja em sistemas de médio porte em diante. Além do mais. É interessante citar que o projeto estruturado entra em cena aonde a programação estruturada sai.

inflexíveis e de difícil manutencão.2 Os fundamentos do projeto 1.1 Contexto do Projeto Geralmente as sete fases de um sistema clássico são: • • • • • • • reconhecimento do Problema estudo de viabilidade análise projeto implementação testes manutenção 1. não confiáveis. qualquer combinação dos itens acima. insatisfatórios.2.2.2 Principais sintomas de um projeto inadequado Abaixo são apontadas os principais sintomas de um projeto inadequado: • • • • • • • inadministráveis. ineficientes.Projeto Estruturado de Sistemas 1. insatisfatórios e improdutivos. 3 .

Projeto Estruturado de Sistemas 1. 4 .3 Critérios de Qualidade do Projeto 1.1 Completeza O Projeto não deve perder nada do que foi identificado na fase de análise como requisito essencial.dados processados por unidade de tempo tempo de resposta Dentre os fatores que afetam o desempenho. Como parâmetros de avaliação da Performance.devido ao tempo gasto em acesso a discos ser muito maior do que operações na CPU. com cada módulo desempenhando funções bem definidas e coesas.3.3. deve-se prover o sistema de mecanismos que minimizem este tempo. e com baixo grau de interdependência ou acoplamento entre os mesmos. 1.3 Performance Performance está diretamente relacionada ao uso otimizado dos recursos de hardware. temos: • • • • tempo de processamento memória ocupada through-put . software e pessoal disponíveis. 1.3.2 Manutenibilidade Deve-se projetar o sistema de forma a permitir facilidades de alteração devido a: • erros do sistema • novas necessidades do usuário • alterações do ambiente Verifica-se que os sistemas mais fáceis de alterar são aqueles construídos de forma modular. temos: • deficiência do projeto de interface • tempo de acesso a discos e periféricos . empregando-se organizações de arquivos adequadas.

roubo. Telas devem ser providas de: • data 5 . ou particionamento do mesmo gerando um arquivo atual e um histórico. entradas de parâmetros. consulta. etc). atualizações de grande volume de dados em banco de dados. o sistema deve identificar usuário e terminal.para validar a identificação inicialmente informada (password.4 Segurança Deve-se prover mecanismos para evitar acessos indevidos ao sistema. e deve ser limitado o número de tentativas seguidas sem sucesso de um usuário. estes códigos de autenticação nunca devem ser expostos no terminal. ter de seis a oito caracteres e devem ser trocadas periodicamente. grampeamento • infiltração não intencional . Para tal.linhas cruzadas.3. Além disso. falha de software Para controle de acesso ao ambiente.deve-se evitar ao máximo a execução de processos batch de longa duração durante o horário de pique. cartão magnético. deve-se verficar a possibilidade de limpezas periódicas. As teclas de função válidas em cada tela devem ser indicadas explicitamente. atualização. espera de processamentos longos e respostas de consulta.5 Interatibilidade Corresponde a facilidade do usuário em interagir com o sistema. voz.erro do usuário.3. 1. Cada usuário deve possuir um único e pessoal: • código de identificação . Passwords devem ser secretas. identidade ou matrícula • código de autenticação . tais como transferência de grandes arquivos. As telas devem ser padronizadas para menu. restringindo as operações conforme a necessidade. • processos longos em horário de pique .cpf . irradiações • acidentes . digital. falha de hardware.Projeto Estruturado de Sistemas • falta de reorganização de arquivos . Como tipos de ameaças a segurança temos: • infiltração intencional . deve-se ter cuidado na escolha da implementação de funções batch/on-line. sabotagem. Cuidados com lay-out de telas e relatórios devem ser observados.em arquivos grandes e de muita utilização. 1.

estornos. Linha de comando deve ser utilizada principalmente para sistemas com um alto nível hierárquico de telas. • perda da integridade das informações Como medidas para aumentar a confiabilidade temos: • restrições de integridade que podem ser feitas via programa ou definidas no próprio SGBD. quando este possui esta facilidade. ou por grupos de campos. e a indicação do campo. tenham acesso a mesma sem a necessidade de navegação pelas telas. Mecanismos de recuperação de falhas devem ser utilizados de acordo com o nível de confiabilidade da aplicação. Este recurso permite que os usuários através de um mneumônico de uma aplicação. Mensagens de erro devem ser padronizadas e devem deixar claro qual foi o erro.3. • programas de acertos que geram ajustes. cancelamentos ou correções. 1.Projeto Estruturado de Sistemas • identificação do usuário • código da tela • identificação da operação referente a tela • área de menu de opções e entrada de dados • área de mensagens de erro relativos às operações • área de mensagens interativas com o decorrer da operação A crítica de campos pode ser feita campo a campo. • custo operacional. Deve-se prover DEFAULTS para entradas padrões e utilização de teclas para acesso a tabelas em campos codificados. • custo de construção e manutenção 6 .3. tais como back-up e Log.7 Economia O custo do projeto deve ser balanceado de acordo com: • custo da tecnologia. tela cheia. 1.6 Confiabilidade Confiabilidade está relacionada a redução do risco de interrupção no fluxo normal de processamento das informações causadas por: • indisponibilidade de acesso .o sistema não oferece o serviço no tempo estipulado ou desejado. se necessário. • crítica a entrada de dados.

O Modelo de Implementação do Sistema e o Modelo de Implementação de Programas.1. • principais funcionalidades de um diagrama nível 0 de um DFD serem alocadas a diferentes processadores. o projetista deve tentar agrupar processos e depósitos que tenham alto grau de comunicação em um mesmo processador. Por 7 . • eficiência: a utilização de mais de um processador pode levar a um melhor tempo de reposta bem como permitir a execução paralela de atividades. Esta opção é conhecida como solução mainframe. repetição de atividades essenciais e/ou containers em mais de um processador. Esta solução costuma ser chamada de solução distribuída. Como a comunicação entre processadores é mais lenta que a comunicação entre processos no mesmo processador. em tempo de projeto. o empacotamento de atividades e dados pode levar a uma distribuição de atividades essenciais e/ou containers por mais de um processador. devem.1 Modelo de Implementação do Sistema O Modelo de Implementação de Sistemas subdivide-se em um Modelo de Processador e um Modelo de Tarefa. 2. com o objetivo de minimizar custos.1 Modelo de Processador As atividades essenciais identificadas na fase de análise. maximizar a confiabilidade. a implementação em um processador único pode ser ou não a mais barata. ou mesmo. 2. Dentre as possíveis opções. ser alocadas a processadores.Projeto Estruturado de Sistemas 2. verifica-se: • todo modelo essencial alocado a um único processador. • pode ainda ser escolhida uma opção intermediária entre as duas citadas anteriormente. Os principais problemas encontrados são: • custo: dependendo da natureza do sistema. Desta forma. FASES DO PROJETO Dois modelos são utilizados nas fases de projeto. bem como as atividades adicionais necessárias devido a limitação da tecnologia.

a comunicação entre processadores pode ser proibitiva pelos mesmos motivos. tais como geração de histórico. no formato da Figura 2. é sugerida a montagem de uma lista. deve-se verificar uma possível ineficiência na comunicação entre os processadores.1: Lista de Atividades para o Modelo de Processador 8 . definição de perfil de usuário.2 uma venda . bem como cópia de processos e dados em vários processadores. etc. Evento Processo Arquivos Lógicos venda vendedor item - vendedor efetua 3. Pode-se utilizar processadores de reserva. Volume Estimado Frequên Processa cia dor 300/dia P1 Figura 2. Por outro lado. pode ser necessário a alocação de alguns processos e dados em processadores localizados em áreas protegidas. com as atividades essenciais acrescida das atividades tecnológicas. • confiabilidade: em função da confiabilidade.1. o projetista pode decidir por configurações que permitam que parte de um sistema fique disponível ainda que outras partes estejam inoperantes. • segurança: por questões de segurança. Como forma de auxílio para a montagem do modelo de processador.Projeto Estruturado de Sistemas outro lado.

O sistema operacional é responsável pelo gerenciamento de uma ou mais tarefas em um processador. é sugerida a utilização da lista da figura 2. e o tempo de resposta esperado para cada atividade. Ao final do empacotamento tem-se a lista de tarefas por processadores.2: Lista de Tarefas para o Modelo de Tarefas 9 . deve-se fazer o empacotamento das atividades em tarefas “on-line”.2.2 Modelo de Tarefa A partir do Modelo de Processador. Como forma de auxílio para a elaboração do Modelo de Tarefas.Projeto Estruturado de Sistemas 2. A estratégia de agrupar atividades em tarefas consiste em verificar a forma de utilização do sistema.1. Deve-se entender como tarefa uma atividade independente e assíncrona. Processador: Evento Processo Tarefa: Atividade(s) Tipo: Classe do Usuário Figura 2. “batch” e “real time”.

Projeto Estruturado de Sistemas 2. 10 . O Diagrama de Estrutura Modular. também conhecido como DEM. onde destaca-se o Diagrama de Estrutura Modular proposto por Page-Jones que enfatiza a decomposição hierárquica de uma atividade em módulos individuais que sejam reutilizáveis.2 Modelo de Implementação de Programa Neste fase. o objetivo é organizar o sistema em programas. é descrito em detalhes no próximo capítulo. Cada programa consiste em uma hierarquia composta por várias hierarquias menores. Existem diversas propostas para chegar a uma estrutura de software hierárquica.

e a função desempenhada pelo módulo não deve gerar nenhum “efeito colateral” inesperado. pois quanto mais interfaces tiverem uns com os outros. Uma vantagem da obediência deste princípio é a facilidade de depuração. 11 .os módulos devem ser de tal forma que possam ser facilmente adaptados a novas utilizações. os princípios descritos a seguir devem ser considerados: • ocultar informações .o funcionamento interno de um módulo deve estar oculto aos outros módulos. o modelo procura atingir os seguintes objetivos: • precisão .capacidade de um módulo manipular corretamente situações inesperadas.um módulo deve fazer exatamente o que se espera dele. Assim.os módulos devem ser projetados de tal forma que possam ser utilizados em mais de uma aplicação. DIAGRAMA DE ESTRUTURA MODULAR 3.Projeto Estruturado de Sistemas 3. Este princípio limita as ligações que um módulo tem com uma aplicação em particular. • pequenas interfaces .um módulo deve ser dedicado a uma finalidade bem definida.a interface de um módulo deve precisar somente das informações necessárias para que o mesmo complete a tarefa. • solidez . • reutilização . • clareza . • interfaces explícitas . tornando-o mais fácil de ser reutilizado. Para isso. • facilidade de adaptação .1 Introdução Uma das principais finalidades do DEM é possibilitar a criação de sistemas que sejam mais confiáveis e de fácil manutenção.módulos devem ser construídos de tal forma que uma nova funcionalidade possa ser adicionada sem a necessidade de se refazer o serviço. módulos podem utiilizar-se de outros módulos e depender destes para realizar as tarefas esperadas sem se preocupar como devem ser realizadas tais tarefas.um módulo deve interagir com outros o mínimo possível. mais difícil será a manutenção dos mesmos. • poucas interfaces .as interfaces devem ser feitas de forma que todas as informações pertinentes sejam claramente especificadas no código fonte. Um módulo sólido não propaga erros. • extensibilidade . Com estratégia para alcançar os objetivos mencionados.

1. 3. Pode-se utilizar em um modelo módulos já pré-definidos.A: Simbologia de representação de Módulo O nome do módulo deve corresponder a declaração de uma função. sendo normalmente formado por um verbo indicando uma ação. Calcular Salário Líquido Figura 3. isto é.Projeto Estruturado de Sistemas 3. Validar CPF Figura 3.2 apresenta a simbologia para um módulo prédefinido. módulos já existentes que são reutilizados. A figura 3.2.B: Simbologia de representação de Módulo Pré-Definido 12 . sendo ideal para que os outros módulos sejam uma caixa preta” A simbologia utilizada para representar um módulo é ilustrada na Figura 3.2 Componentes do DEM A seguir serão apresentados os principais componentes do DEM e suas características sintáticas.1 Módulo “É o elemento separadamente endereçável em um sistema” “É a menor parte do sistema que realiza uma função completa independente de outras funções” “É um conjunto de instruções de um programa que pode ser chamado por um nome.

2 Hierarquia de Módulos A hierarquia entre os módulos é representada na Figura 3.2.C: Hierarquia de Módulos 13 .3. A B Figura 3. O módulo A chama o módulo B que executa sua função e retorna ao módulo A.Projeto Estruturado de Sistemas 3.

D: Exemplo de uma Hierarquia entre Módulos A chamada de um determinado módulo pode ser: • incondicional .corresponde a uma seleção ou decisão.4. 14 . o módulo B é ativado através de uma chamada embutida na implementação do módulo A.4 ilustra uma outra hierarquia entre módulos: A B G H C F I J D E Figura 3. A ativação de um módulo subordinado é determinada por uma condição embutida na implementação do módulo superior.o módulo subordinado sempre será ativado pelo seu superior. Na figura 3. A figura 3. • condicional .Projeto Estruturado de Sistemas Já a figura 3.5 ilustra a simbologia referente a ativação condicional.

Projeto Estruturado de Sistemas A B C Figura 3.um módulo subordinado pode ser ativado pelo seu superior mais de uma vez.F: Chamada repetitiva de Módulos 15 . A B C Figura 3. A figura 3.E: Chamada condicional de Módulos • repetitiva . em função de uma condição.6 apresenta uma ativação repetitiva.

determinados pela direção do fluxo dos dados: • Aferente .coordena a comunicação de seus subordinados.envia informação para seu superior de baixo para cima. • Coordenador . • Transformador . 16 .corresponde a informações não existentes no mundo real.Projeto Estruturado de Sistemas Quando um módulo ativa outro módulo.envia informação para seu subordinado de cima para baixo. um módulo pode tanto receber quanto passar parâmetros. já EOF (“end of file”) corresponde a um controle.3 Tipos de Módulos Os módulos dividem-se em quatro tipos básicos. ou seja fazem parte do problema • controle .recebe informação de seu superior.G: Tipo de parâmetros entre Módulos 3. apenas para o funcionamento do sistema A figura 3.corresponde a informações existentes no mundo real. • Eferente . passa algumas informações denominadas de parâmetros da chamada. CPF indica um fluxo de dado.8 ilustra os diferentes tipos de módulos. CPF EOF Figura 3.7 ilustra a simbologia utilizada para representar no diagrama os dados e controles que fluem entre os módulos. faz algum tipo de transformação e retorna uma nova informação ao seu superior. A Figura 3. não tendo relevância para o mundo externo.2. Os possíveis tipos de parâmetros são: • dado . Desta forma.

O conector minimiza o emaranhado de traços.2.9 ilustra os dois tipos de conectores. A figura 3.Projeto Estruturado de Sistemas Módulo Eferente Módulo Aferente Módulo de Coordenação Módulo de Transformação Figura 3.4 Conector Conector é utilizado para representar módulos repetidos ou referenciar módulos localizados em páginas diferentes.H: Tipos de Módulos 3. 17 .

O conector ODC (obter detalhe cliente ) referencia um módulo localizado em outra página do modelo (figura 3.10 ilustra um exemplo de parte de um modelo. é utilizado o conector DH.J: Exemplo de parte de um modelo 18 .Projeto Estruturado de Sistemas Conector de página Conector para uma mesma página Figura 3. Para deixar o modelo mais “limpo”. que é subordinado a mais de um módulo. que faz referência ao módulo obter data corrente. Note que o módulo obter data corrente é pré-definido. Controlar Contas Cliente data-corrente dados conta EOF Obter Dados da Conta conta-atrasada Obter Data Corrente Processar Conta não Paga atraso-pequeno atraso-demasiado ODC DH Gerar Aviso Gentil atraso-grande Gerar Advertência Gerar Tratamento Legal Obter Data Corrente DH DH DH Figura 3.I: Simbologia para Conectores A figura 3.11).

e sua especificação deve conter: • função. 19 . • entradas e saídas. • lógica interna do módulo.K: Exemplo do uso de Conector de Página 3.2. Esta lógica pode ser expressa de forma genérica (o que fazer) ou de forma detalhada através de pseudo-código (como fazer).Projeto Estruturado de Sistemas ODC Obter Detalhe Cliente Figura 3.5 Especificação de Módulos É a forma de definir o funcionamento interno de cada módulo.

Deve-se tomar cuidado com o chamado dado migrante (um grupo de informações que vagueia pelo sistema). A figura 3. Os tipos de Acoplamento são: • • • • • Dados Imagem Controle Comum Conteúdo • Acoplamento de Dados Corresponde a comunicação de dados necessária entre módulos. indesejável e sem sentido para a maioria dos módulos pelos quais passa. Uma vez que os módulos têm que se comunicar.3. Gerar Guia de IPTU área valor-taxa Calcular Taxa 20 .1 Acoplamento O Acoplamento mede o grau de interdependência entre os módulos do diagrama. O que se deseja são módulos de baixo acoplamento para diminuir o máximo possível o efeito em cadeia quando um módulo for alterado.12 ilustra um Acoplamento de Dados. a ligação de dados é inevitável. e não é crítica desde que mantidas as taxas mínimas.Projeto Estruturado de Sistemas 3.3 Critérios de Qualidade do DEM 3.

21 .13 ilustra um exemplo de Acoplamento por Imagem.L:Exemplo de Acoplamento de Dados • Acoplamento de Imagem Dois módulos apresentam Acoplamento por Imagem se eles fazem referência a uma mesma estrutura de dados.Projeto Estruturado de Sistemas Figura 3. Este tipo de Acoplamento tende a fornecer mais dados do que o necessário a um módulo. Calcular Valor Aluguel registro aluguel custo combustível valor registro aluguel aluguel Obter Aluguel do Carro Calcular Gasto de Combustível Figura 3.14 ilustra um Acoplamento de Controle. A figura 3. A figura 3.M: Exemplo de Acoplamento de Imagem • Acoplamento de Controle Dois módulos são acoplados por controle se um passa um grupo de dados (controle) para o outro para controlar sua lógica interna.

A figura 3. o acoplamento não é tão crítico uma vez que o controle indica uma validação.15 apresenta um exemplo de Acoplamento Comum. • Acoplamento Comum Dois módulos possuem Acoplamento Comum quando fazem referência a uma área global de dados (ex.N: Exemplo de Acoplamento de Controle No primeiro exemplo. Working Storage Section da linguagem Cobol). 22 . porém o segundo exemplo exige que o módulo que enviou o controle (validar pedido) conheça o outro módulo.Projeto Estruturado de Sistemas Gerar Folha Pagamento Validar Pedido CPF FLAG tipo-erro Validar CPF Imprimir Mensagem Erro Figura 3.

A figura 3. programas com muitos dados globais são de difícil entendimento.16 ilustra um exemplo de Acoplamento de Conteúdo. Tal Acoplamento torna o conceito de caixas-pretas sem sentido. 23 .Projeto Estruturado de Sistemas Obter dados Peça Quantidade Retirada Nome Peça Atualizar Estoque Quantidade Atual Estoque de Peças Figura 3. fica difícil descobrir que módulos devem ser alterados quando um dado é modificado. • Acoplamento de Conteúdo Dois módulos apresentam Acoplamento de Conteúdo (ou patológico) se um faz referência ou desvia a sequência de instruções para o interior de um outro módulo (GO TO).O: Exemplo de Acoplamento Comum Este tipo de Acoplamento não é desejável pois: um erro em uma área global pode se propagar por diversos módulos.

P: Exemplo de Acoplamento de Conteúdo 3.Projeto Estruturado de Sistemas Módulo A <instruções> Valor = Valor * percentual Se Valor > 1000 GO TO P1 Fim-se <instruções> <instruções>.3.2 Comparação dos Tipos de Acoplamento Os tipos de Acoplamento especificados abaixo são apresentados em ordem descrescente (do melhor para o pior tipo). Dados Imagem Controle Comum Conteúdo 24 . Efetuar desconto <instruções> Módulo B Figura 3. P1.

17 ilustra módulos com Coesão Funcional. Deseja-se módulos altamente coesos. Ter certeza de que todos os módulos têm boa coesão é a melhor forma de minimizar o acoplamento.Q: Exemplo de Coesão Funcional 25 . pois isto levaria a um forte acoplamento entre eles. Os tipos de Coesão são: • • • • • • • Funcional Sequencial Comunicacional Procedural Temporal Lógica Coincidental • Coesão Funcional Um módulo apresenta Coesão Funcional quando suas funções internas contribuem para a execução de uma e apenas uma tarefa relacionada ao problema. os elementos de um módulo não devem ser fortemente relacionados com os elementos de outros módulos.3 Coesão Coesão mede a intensidade da associação funcional dos elementos de um módulo. Por outro lado.Projeto Estruturado de Sistemas 3. cujos elementos são relacionados um com os outros.3. A figura 3. Num-Conta Obter Nome Cliente Nome Cliente Num-Conta Dados Empréstimo Obter Dados Empréstimo Figura 3.

No exemplo Obter Detalhes Cliente recebe um mesmo parâmetro de entrada Num-Conta e executa duas atividades distintas que poderiam ser representadas pelos módulos: 26 . Nesta situação o módulo fornece mais informações que o necessário.R:Exemplo de Coesão Sequencial Um módulo com Coesão Sequencial caracteriza-se por ser de fácil manutenção porém de baixa reutilização. A figura 3. ou seja. • Coesão Comunicacional Um módulo possui Coesão Comunicacional quando suas funções internas estão relacionadas por utilizarem as mesmas informações.18 ilustra um módulo com Coesão Sequencial.Projeto Estruturado de Sistemas • Coesão Sequencial Um módulo apresenta Coesão Sequencial quando suas funções internas estão envolvidas em atividades de tal forma. que os dados de saída de uma atividade sirvam como dados de entrada para a próxima. A Figura 3. No exemplo. pois contém atividades que são utilizadas juntas. Este fluxo estabelece uma sequência de execução das funções. verificase que exibir consulta executa duas atividades bem distintas e que poderiam ser representadas pelos módulos: obter registro exibir dados Num-Conta Exibir Consulta Figura 3. não se pode caracterizar o conjunto delas como uma única tarefa. no entanto. utilizam a mesma entrada ou mesma saída.19 ilustra um módulo com Coesão Comunicacional.

• Coesão Procedural Um módulo possui Coesão Procedural quando suas funções internas executam atividades diferentes e não correlacionadas. nas quais o controle flui ( e não os dados ) de uma atividade para outra. pois ambos contém atividades organizadas em torno dos dados do problema original. É típico também que tais módulos devolvam resultados parciais.S: Exemplo de Coesão Comunicacional Módulos com Coesão Comunicacional e Sequencial são semelhantes. 27 . É comum em um módulo com Coesão Procedural que os dados de entrada e saída tenham pouca relação. tais como: flags. A principal diferença entre eles é que um módulo sequencialmente coeso opera como uma linha de montagem onde suas atividades são executadas em uma ordem específica. chaves. exceto por serem executadas em uma mesma ordem.Projeto Estruturado de Sistemas obter nome cliente obter resultado empréstimo Data-Vencimento Num-Conta Saldo-Empréstimo Limite-Empréstimo Obter Detalhes Cliente Figura 3. Já em um módulo com coesão comunicacional a ordem de execução não é importante. etc.

21 ilustra um módulo com Coesão Temporal. e sua fatoração para módulos funcionalmente coesos na parte mais a direita da figura. A ordem de execução de atividades é mais importante em módulos procedurais do que em módulos temporais. Finalizar 28 . valor num-conta Valor valor Num-Conta numconta Tratar Saque numconta numconta Bloquear Saque valor flag Tratar Saque Verificar Limite Crédito Efetuar Saque Figura 3.Projeto Estruturado de Sistemas A figura 3.20 ilustra o módulo Tratar Saque isolado (parte esquerda da figura) com Coesão Procedural.T: Exemplo de Coesão Procedural • Coesão Temporal Um módulo possui Coesão Temporal quando suas funções internas executam atividades que estão relacionadas apenas com o tempo (as atividades não estão relacionadas entre si). A Figura 3.

22 ilustra um módulo com Coesão Lógica. não há uma ordem específica de execução. nem sempre todas as funções são ativadas e a ativação das funções é decidida fora do módulo.U: Exemplo de Coesão Temporal • Coesão Lógica Um módulo possui Coesão Lógica quando suas funções internas contribuem para atividades da mesma categoria geral.V: Exemplo de Coesão Lógica • Coesão Coincidental Um módulo possui Coesão Coincidental quando suas funções não possuem nenhuma correlação entre si. flag reg-material reg-cliente reg-fornecedor status atualização Rotina Geral de Atualização Figura 3. módulos logicamente coesos apresentam uma interface descaracterizada.23 ilustra uma Coesão Coincidental. Desta forma. A figura 3. A figura 3. onde a atividade é selecionada fora do módulo. 29 .Projeto Estruturado de Sistemas Figura 3.

W: Exemplo de Coesão Coincidental 3.X: Estratégia para identificação dos tipos de Coesão 30 .TEMPORAL NÃO NENHUM DELES AS ATIVIDADES ESTÃO NA MESMA CATEGORIA GERAL ? NÃO SIM 6.COMUNICACIONAL NÃO O QUE RELACIONA AS ATIVIDADES DO MÓDULO FLUXO DE CONTROLE A SEQÜÊNCIA É IMPORTANTE ? SIM 4.24 mostra uma estratégia para identificar o tipo de Coesão de um determinado módulo.4 Determinação do Tipo de Coesão A figura 3.Projeto Estruturado de Sistemas venda nummaterial conta nomematerial saldo Calcular Saldo Validar Material Figura 3. FUNCIONAL SIM O MÓDULO PODE SER CONSIDERADO COMO EXECUTANDO UMA FUNÇÃO RELACIONADA AO PROBLEMA NÃO DADOS A SEQÜÊNCIA É IMPORTANTE ? SIM 2.COINCIDENTAL Figura 3. 1.SEQÜENCIAL 3.3.LÓGICA 7.PROCEDURAL 5.

Projeto Estruturado de Sistemas Comparando os tipos de Coesão. podemos classificá-los em ordem. como descrito abaixo ( do melhor para o pior tipo ): • • • • • • • Funcional Sequencial Comunicacional Procedural Temporal Lógica Coincidental 31 .

Projeto Estruturado de Sistemas 3. Este separação pode ter com objetivo: • reduzir o tamanho do módulo. • obter as vantagens modulares de um projeto top-down. Fan-Out. Fan-In. a fim de que a informação reconhecida não tenha que percorrer um longo caminho para ser processada (dado migrante). • evitar a codificação de uma mesma função em mais de um módulo.26).4. 3. 3. Escopo de Controle: conjunto formado por um módulo e todos os seus subordinados. deve-se elaborar uma nova organização dos módulos com o objetivo de aproximar o reconhecimento da execução (figura 3.2 Divisão de Decisão Uma decisão é constituída de duas partes: o reconhecimento da ação a ser tomada e a execução desta ação.4 Diretrizes Adicionais do Projeto Além do Acoplamento e Coesão devemos considerar outras diretrizes dentro do Projeto tais como Factoring. já apresentada. Divisão de Decisão.25). É importante que o Escopo de Efeito de uma Decisão de um módulo seja um subconjunto do Escopo de Controle deste módulo. A parte referente a execução da decisão deve ser mantida o mais próximo possível da parte referente ao reconhecimento. passando-a para um novo módulo. tornando o sistema mais compreensível e permitindo modificações mais localizadas.20. A figura 3. A fatoração de um módulo grande deve ser efetuada se não diminuir a Coesão e não aumentar o Acoplamento do módulo original.1 Factoring Corresponde a separação de uma função contida em um módulo. • prover módulos de utilização mais genérica. • simplificar a implementação. Deve-se evitar ao máximo a divisão de decisão. Escopo de Efeito de uma Decisão: conjunto de todos os módulos cujo seu procedimento depende da decisão. 32 . Sempre que esta regra for violada (figura 3. ilustra uma fatoração. etc.4.

Y: Exemplo de um diagrama com Divisão de Decisão 33 .Projeto Estruturado de Sistemas Notação Efeito A Decisão C B D E X F G Figura 3.

Projeto Estruturado de Sistemas Notação Efeito A Decisão C B D E X F G Figura 3. A figura 3.Z: Exemplo de um Diagrama sem Divisão de Decisão 3. 34 .3 Formas de um Modelo • Input-Driven Corresponde ao modelo que realiza pouco processamento em seu lado aferente. Esta forma não é desejável pois muitos módulos no topo do sistema estão relacionados com o formato físico da entrada.27 ilustra o formato de um modelo Input-Driven.4. de modo que os módulos superiores lidam com dados físicos e não refinados.

AA: Formato de um modelo Input-Driven • Output-Driven Esta forma é mais rara de se verificar.Projeto Estruturado de Sistemas A B C E D F H G Figura 3.28 ilustra o formato de um modelo Output-Driven. porém também é desaconselhável uma vez que módulos superiores ficam presos a condições físicas de saída. A figura 3. 35 .

o dado é independente de qualquer formato especial de saída desejado pelo usuário. No lado eferente.29 ilustra o formato de um modelo Balanceado. deixando de depender da forma de entrada no sistema. No lado aferente o dado é inicialmente editado e desblocado. A figura 3.Projeto Estruturado de Sistemas A B G I C F H D E Figura 3. 36 .BB: Formato de um modelo Output-Driven • Balanceado Ocorre quando os módulos superiores lidam com dados de natureza lógica e não física.

a codificação não fica tão compreensível.4 Informações de Erro Erros devem ser relatados pelo módulo que os detectou e que conhece sua natureza. 3.4.CC: Formato de um modelo Balanceado 3. é necessário um número artificial de mensagem para acessá-la.4.5 FAN-OUT e FAN-IN 37 . Mensagens de erro juntas em um módulo tem as seguintes vantagens e desvantagens: • • • • é mais fácil de manter o texto e o formato da mensagem. é mais fácil evitar mensagens duplicadas.Projeto Estruturado de Sistemas A B G H C F I J D E Figura 3.

A Figura 3.Projeto Estruturado de Sistemas FAN-OUT corresponde ao número de subordinados imediatos de um módulo. A Figura 3. Para corrigir um alto FANOUT pode-se utilizar o Factoring de módulos. Existem duas regras para restringir o FAN-IN: • módulos com FAN-IN devem ter coesão funcional. Um alto FAN-IN acarretando reutilização de módulos. ou no mínimo coesão comunicacional ou sequencial. Deve-se limitar o FAN-OUT de um módulo em torno de sete.DD: Exemplo de um modelo com alto FAN-OUT FAN-IN corresponde ao número de módulos superiores de um módulo. A B G H J K L M Figura 3. 38 .31 apresenta um modelo com alto FAN-IN. • a interface deve ter os mesmos números e tipos de parâmetros.30 ilustra um modelo com um alto FAN-OUT.

Projeto Estruturado de Sistemas A B G H J I Figura 3.EE: Exemplo de um modelo com alto FAN-IN 39 .

5 Estratégia para Derivar o DFD para o DEM A passagem da especificação produzida na fase de análise para a fase de projeto é feita através de duas estratégias. • ramo eferente corresponde aos elementos já alterados para a saída. o ramo eferente. A figura 3. onde : • ramo aferente corresponde aos elementos considerados como entradas. A figura 3. Esta estratégia baseia-se em: Passo 1: identificar o ramo aferente.Projeto Estruturado de Sistemas 3.32 apresenta um DFD já com a identificação do centro de transformação. Já a figura 3. Se há um bom candidato para chefe no Centro de Transformação Então escolha o chefe e deixe os demais subordinados a ele Senão promova um novo chefe.1 Análise de Transformação A Análise de Transformação é aplicada no nível do DFD que apresenta ligação direta entre processos através de fluxos de dados. utilizadas de acordo com as características dos DFDs a serem transformados.33 ilustra a derivação para o DEM a partir da escolha do processo P4 como “chefe”. • ramo de transformação corresponde a fase em que os dados passam de aferente para eferente. considere o centro de transformação como uma única bolha do DFD e subordine a transformação central e cada ramo aferente e eferente ao novo chefe. São elas: • Análise de Transformação • Análise de Transação 3.34 apresenta um novo diagrama onde o módulo “chefe” não corresponde a nenhum processo do DFD. 40 . Passo 2: considerar cada processo como um módulo e adotar o algorítmo a seguir para escolha do módulo de mais alto nível da hieraquia (escolha do chefe). e o centro de transformação do nível do DFD.5.

FF: Exemplo de DFD com a identificação do centro de Transformação 41 .Projeto Estruturado de Sistemas A D P1 P3 F P4 H P6 K B G E J I L P2 P5 P7 C Figura 3.

GG: Exemplo de um DEM derivado a partir de um DFD 42 .Projeto Estruturado de Sistemas P4 P3 P5 P6 P1 P2 P7 Exibir K Obter A Obter B Obter C Exibir L Figura 3.

3. • para cada módulo individual aplicar Análise de Transformação ou Análise de Transação. checar critérios de projeto. efetuar factoring. • utilizar um módulo para selecionar a transação desejada.2 Análise de Transação A Análise de Transação é aplicada no nível do DFD que apresenta ligação de processos via depósito de dados.5.HH: Exemplo de um DEM derivado a partir de um DFD Passo 3: Prover o diagrama de novas capacidades: • • • • adicionar módulos de leitura e/ou gravação. adicionar módulos de manipulação de erros.Projeto Estruturado de Sistemas CHEFE P3 P4 P1 P2 P5 P6 Obter A Obter B Obter C P7 Exibir K Exibir L Figura 3. A aplicação da Análise de Transação deve seguir os seguintes passos: • selecionar como módulo raíz o processo que originou o nível em análise. 43 . se houver explosão do mesmo.

JJ Figura 3.35 ilustra um DFD que após a aplicação da Análise de Transação resulta o diagrama da figura 3.II: Exemplo de DFD com ligações entre processos via depósito de dados PX transação Obter Transação P1 P2 P3 Figura 3.36: Exemplo de utilização de Análise de Transação 44 .36.Projeto Estruturado de Sistemas A figura 3. Diagrama Nível X EXT1 f1 f2 f3 f7 EXT3 P1 P3 f6 dep2 dep1 dep3 f4 P2 f5 EXT2 Figura 3.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->