ESTADO DE MINAS GERAIS UNIVERSIDADE ESTADUAL DE MONTES CLAROS CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS DEPARTAMENTO DE CIÊNCIAS DA COMPUTAÇÃO

Curso Seqüencial em Tecnologias da Informação Disciplina: Projeto de Sistemas de Informação Carga Horária: 80 horas Período: 3º Turma: _______ Ementa: Projeto Estruturado: Análise de transformação. Análise de transação. Modularidade. Coesão. Acoplamento. Ferramentas do projeto estruturado. Noções de projeto orientado a objetos. Bibliografia: PRESSMAN, Roger S. Engenharia de software. Ed. Makron Books, 1995. GANE, Chris.SARSON, Trish. Análise estruturada de sistemas. Ed. LTC, 1999 PÁDUA, Wilson. Engenharia de software: fundamentos, métodos e técnicas, Ed. LTC, 2003. Período: 07/03/2006 a 06/04/2006 Professor: __________________________________________________

ÍNDICE

1. INTRODUÇÃO ............................................................................................................................. 3

1.1 PROPOSTA PARA O PROJETO....................................................................................................... 3 1.2 OS FUNDAMENTOS DO PROJETO.................................................................................................. 4 1.2.1 CONTEXTO DO PROJETO ............................................................................................................. 4 1.2.2 PRINCIPAIS SINTOMAS DE UM PROJETO INADEQUADO................................................................ 4 1.3 CRITÉRIOS DE QUALIDADE DO PROJETO ................................................................................... 5 1.3.1 COMPLETEZA.............................................................................................................................. 5 1.3.2 MANUTENIBILIDADE .................................................................................................................. 5 1.3.3 PERFORMANCE ........................................................................................................................... 6 1.3.4 SEGURANÇA................................................................................................................................ 6 1.3.5 INTERATIBILIDADE/INTERATIVIDADE/OPERACIONALIDADE...................................................... 8 1.3.6 CONFIABILIDADE........................................................................................................................ 9 1.3.7 ECONOMIA................................................................................................................................ 13

2. FASES DO PROJETO ............................................................................................................... 14

2.1 MODELO DE IMPLEMENTAÇÃO DO SISTEMA ........................................................................... 14 2.1.1 MODELO DE PROCESSADOR...................................................................................................... 14 2.1.2 MODELO DE TAREFA ................................................................................................................ 15 2.2 MODELO DE IMPLEMENTAÇÃO DE PROGRAMA....................................................................... 16

3. DIAGRAMA DE ESTRUTURA MODULAR.......................................................................... 17

3.1 INTRODUÇÃO .............................................................................................................................. 17 3.2 COMPONENTES DO DEM ........................................................................................................... 17 3.2.1 MÓDULO................................................................................................................................... 18 3.2.2 HIERARQUIA DE MÓDULOS ...................................................................................................... 18 3.2.3 TIPOS DE MÓDULOS.................................................................................................................. 22 3.2.4 CONECTOR................................................................................................................................ 23 3.2.5 ESPECIFICAÇÃO DE MÓDULOS.................................................................................................. 25 3.3 CRITÉRIOS DE QUALIDADE DO DEM........................................................................................ 25 3.3.1 ACOPLAMENTO......................................................................................................................... 25 3.3.2 COMPARAÇÃO DOS TIPOS DE ACOPLAMENTO.......................................................................... 29 3.3.3 COESÃO .................................................................................................................................... 29 3.3.4 DETERMINAÇÃO DO TIPO DE COESÃO...................................................................................... 35 3.4 DIRETRIZES ADICIONAIS DO PROJETO..................................................................................... 36 3.4.1 FACTORING............................................................................................................................... 36 3.4.2 DIVISÃO DE DECISÃO ............................................................................................................... 36 3.4.3 FORMAS DE UM MODELO ......................................................................................................... 38 3.4.4 INFORMAÇÕES DE ERRO ........................................................................................................... 41 3.4.5 FAN-OUT E FAN-IN ............................................................................................................... 41 3.5 ESTRATÉGIA PARA DERIVAR O DFD PARA O DEM................................................................. 43 3.5.1 ANÁLISE DE TRANSFORMAÇÃO................................................................................................ 43 3.5.2 ANÁLISE DE TRANSAÇÃO ......................................................................................................... 45

2

1. INTRODUÇÃO

1.1 Proposta para o Projeto Projeto Estruturado de Sistemas é a atividade de transformação das necessidades do usuário, provenientes da fase de Análise, em um plano de implementação através da automação eletrônica. Nesta fase, deixa-se de ter a tecnologia perfeita, passando a levar em consideração o hardware e software com todas as suas limitações. Projeto estruturado é uma abordagem disciplinada de projeto de sistemas computadorizados, uma atividade que no passado foi notoriamente acidentada e cheia de problemas. O projeto estruturado é uma das respostas para as falhas do passado, possuindo cinco aspectos:

1) Permite que a forma do problema guie a forma da solução. 2) Procura a resolução da complexidade dos grandes sistemas através

da segmentação de um sistema em “caixas pretas”, e pela organização dessas “caixas pretas” em uma hierarquia conveniente para implementações computadorizadas.

3) Utiliza ferramentas, especialmente gráficas, para tornar os sistemas de fácil compreensão.

4) Oferece um conjunto de estratégias para desenvolver o projeto da solução de uma declaração bem definida do problema.

5) Oferece um conjunto de critérios para avaliar a qualidade de um dado projeto-solução com respeito ao problema a ser resolvido.

Para tornar fácil o entendimento o Projeto Estruturado se utiliza basicamente de duas ferramentas principais: O pseudocódigo e o Diagrama de Estruturas. O pseudocódigo é uma linguagem de especificação informal que não tem a intenção de ser executado em uma máquina, mas de ser usado na organização dos pensamentos dos programadores antes da codificação. 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. A outra ferramenta é o diagrama de estruturas que ilustra a segmentação de um sistema em módulos mostrando a sua hierarquia, organização e comunicação. A vantagem do uso do diagrama de estruturas, que é a principal ferramenta do projeto estruturado, estão no fato desta ferramenta ser:

• Gráfica • Particionável • Rigorosa, mas flexível

3

• Entrada usual para a implementação estruturada • Documentação do sistema • Um auxílio para a manutenção e modificações

Qualquer informação que não puder ser descrita pelo diagrama de estrutura pode ser suprida por pseudocódigo ou por alguma outra descrição de módulos do gráfico de estrutura. É interessante citar que o projeto estruturado entra em cena aonde a programação estruturada sai, ou seja, em sistemas de médio porte em diante. Além do mais, a fase de Projeto procura prover os sistemas de facilidades para:

• construção • testes • modificações • entendimento

1.2 Os fundamentos do projeto

1.2.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.2.2 Principais sintomas de um projeto inadequado Abaixo são apontados os principais sintomas de um projeto inadequado:

• Inadministráveis; • Insatisfatórios; • Insatisfatórios e improdutivos; • Não confiáveis; • Inflexíveis e de difícil manutencão; • Ineficientes;

4

• Qualquer combinação dos itens acima.

1.3 Critérios de Qualidade do Projeto

1.3.1 Completeza O Projeto não deve perder nada do que foi identificado na fase de análise como requisito essencial.

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, com cada módulo desempenhando funções bem definidas e coesas, e com baixo grau de interdependência ou acoplamento entre os mesmos. Ex: funcionamento de um microcomputador

• MODULARIZADO

C P U

IM P R E S S O R AV ÍD E OT E C L A D O

• NÃO MODULARIZADO

MICROCOMPUTADOR

Para melhorar a manutenibilidade pode ser necessário o “factoring” de um módulo, que separa funções do mesmo com o objetivo de:

• Reduzir o tamanho do módulo

5

• Melhorar o entendimento • Melhorar a reutilização de módulos • Separar trabalho de gerenciamento • Simplificar a implementação • Diminuir número de subordinados

Além disso, qualquer fato, convenção ou decisão de implementação, que tenha possibilidade de mudanças, deve ser isolado no menor número de módulos, o que irá facilitar a alterabilidade. Ex: Fato - nº de clientes Convenção - cor codificada com duas letras iniciais - código de cliente Decisão - diretório de acesso aos dados

1.3.3 Performance Performance está diretamente relacionada ao uso otimizado dos recursos de hardware, software e pessoal disponíveis. Como parâmetros de avaliação da Performance, temos:

• Tempo de processamento • Memória ocupada • Through-put - dados processados por unidade de tempo • Tempo de resposta

Dentre os fatores que afetam o desempenho, temos:

• Deficiência do projeto de interface • Tempo de acesso a discos e periféricos - devido ao tempo gasto em acesso

a discos ser muito maior do que operações na CPU deve-se prover o sistema de mecanismos que minimizem este tempo, empregando-se organizações de arquivos adequadas.

• Falta de reorganização de arquivos - em arquivos grandes e de muita utilização, deve-se verificar a possibilidade de limpezas periódicas, ou particionamento do mesmo gerando um arquivo atual e um histórico.

• Processos longos em horário de pique - deve-se evitar ao máximo a execução de processos batch de longa duração durante o horário de pique, tais como transferência de grandes arquivos, atualizações de grande volume de dados em banco de dados.

1.3.4 Segurança

6

Deve-se prover mecanismos para evitar acessos indevidos ao sistema. Como tipos de ameaças à segurança, temos:

• Infiltração intencional - roubo, sabotagem, grampeamento • Infiltração não intencional - linhas cruzadas, irradiações • Acidentes - erro do usuário, falha de hardware, falha de software

PROCEDIMENTOS DE SEGURANÇA

Recursos a serem protegidos: dados arquivos bibliotecas, volumes de discos, volumes de fitas, programas, transações, terminais, CPU e memória.

• CONTROLE DE ACESSO: identificar o usuário e terminal, autenticando-o e restringindo-o às operações autorizadas.

• IDENTIFICAÇÃO E AUTENTICAÇÃO:

IDENTIFICAÇÃO: código do usuário + terminal AUTENTICAÇÃO: senha, cartão, impressão digital, voz, etc... OBS: Senha de uso exclusivo do usuário, devendo ser alterada por ele periodicamente.

• AUTORIZAÇÃO

COMPARTIMENTAÇÃO: grupos de usuário (classes) Usuário X dados que podem ser lidos PERFIL Usuário X dados que podem ser modificados

Usuário X tipos de transação AUTORIZADO Usuário X módulos de programas

Para controle de acesso ao ambiente, o sistema deve identificar usuário e terminal, restringindo as operações conforme a necessidade. Cada usuário deve possuir um único e pessoal:

• Código de identificação - cpf , identidade ou matrícula • Código de autenticação - para validar a identificação inicialmente informada

(password, cartão magnético, digital, voz, etc). Passwords devem ser secretas, ter de seis a oito caracteres e devem ser trocadas periodicamente. Além disso, estes códigos de autenticação nunca devem ser expostos no terminal, e deve ser limitado o número de tentativas seguidas sem sucesso de um usuário.

7

1.3.5 Interatibilidade/Interatividade/Operacionalidade Corresponde a facilidade do usuário em interagir com o sistema. Para tal, deve-se ter cuidado na escolha da implementação de funções batch/on-line. Cuidados com lay-out de telas e relatórios devem ser observados. As telas devem ser padronizadas para menu; atualização; consulta; entradas de parâmetros; espera de processamentos longos e respostas de consulta. As teclas de função válidas em cada tela devem ser indicadas explicitamente. Telas devem ser providas dos dados, conforme o exemplo Ex: 1. Data 2. Identificação do usuário 3. Código da tela, programa ou módulo 4. Versão do programa 5. Indicação da operação 6. Área de menu de opções e entrada de dados 7. Área de mensagem de erro relativos à operação 8. Área de mensagens interativas com o decorrer da operação

NOM E DA EM PRESA

2

NOM E DO SISTEM A1 3

5 4

6

7

8

A crítica de campos pode ser feita campo a campo, tela cheia, ou por grupos de campos. Mensagens de erro devem ser padronizadas e devem deixar claro qual foi o erro, e a indicação do campo, se necessário. Devem-se prover DEFAULTS para entradas padrões e utilização de teclas para acesso a tabelas em campos codificados. Linha de comando deve ser utilizada principalmente para sistemas com um alto nível hierárquico de telas. Este recurso permite que os usuários através de um mneumônico de uma aplicação, tenham acesso a mesma sem a necessidade de navegação pelas telas.

8

1.3.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.

• Perda da integridade das informações Para aumentar a confiabilidade, algumas medidas podem ser tomadas: (A) RESTRIÇÕES DE INTEGRIDADE: podem ser feitas via programa ou diretamente no (SGBD) (Constraints).

• PREVENÇÃO: crítica a entrada de dados; controles temporais de seqüencialidade de atualizações;

• DETECÇÃO: auditoria de Banco de Dados; relatórios de controle; • CORREÇÃO: programas de acertos que gerem ajustes.

(B) RECUPERAÇÃO DE FALHAS: o sistema computacional é falível em todos os seus componentes, cabendo ao projetista detectar as falhas que poderão ser recuperadas. Toda recuperação tem um custo, que tem uma parte relativa a prevenção, e outra correspondente à recuperação propriamente dita. De acordo com a necessidade da aplicação (nível de confiabilidade) deve ser levado em consideração o custo benefício. CONCEITO DE TRANSAÇÃO (BD) É uma seqüência de ações elementares sobre o BD, que devem ser tratadas como se fosse uma unidade atômica (ATOMICIDADE). As operações recuperáveis devem estar dentro de transações. A transação leva o BD de um estado de consistência a outro estado de consistência (CONSISTÊNCIA).

Ex: Suponha que um usuário apresente a seguinte atualização a um BD utilizado para processar a compensação de cheques bancários:

⇒ Debite R$ 50,00 à C/C de A ⇒ Credite R$ 50,00 à C/C de B

9

INÍCIO DO PROGRAMA

FIM DO PROGRAMA

A

- R$ 50,00

B

+ R$ 50,00

BT(Begin Transaction)

COMMIT(Final bem Sucedido)

BT(Begin Transaction)

ROLLBACK(Final mal Sucedido)

PROPRIEDADES NECESSÁRIAS À TRANSAÇÃO: seriabilidade e recuperação de suas ações elementares em caso de falha. Existem vários tipos de falhas:

⇒ FALHAS DE TRANSAÇÃO: ex: overflow aritmético, run time errors,

divisão por zero. O sistema deve forçar o ROLLBACK (undo).

⇒ FALHAS DE SISTEMA: ex: falhas de HW, falta de energia. As informações do I/O buffers ficam perdidas, e as transações em andamento não terminam. Para recuperar, o sistema tem que detectar a falha no reinício e restaurar a base de dados.

⇒ FALHAS DE DISCO: ex: crash, erro na transferência de dados para o disco. Restaurar a partir de backup e refazer as operações perdidas (redo).

⇒ FALHAS DE COMUNICAÇÃO: ex: interrupção anormal de uma sessão de comunicação cliente/servidor. O sistema deve forçar ROLLBACK das transações em andamento (undo).

⇒ FALHA HUMANA: Ex: o operador utilizou uma fita errada para atualização; o envio de fitas ou disquetes fora de ordem por nós remotos.

Além das críticas normais a campos, devem ser previstas as falhas humanas de operação do sistema. Devem ser utilizados HEADERS no meio magnético que controlem a operação; backup; log. PREVENÇÃO

⇒ Backup é uma cópia de segurança que é feita para facilitar a recuperação de informações. Pode ser dinâmico ou estático. Pode ser feito através de utilitários do sistema operacional, ou através de programas específicos. Pode ser automático, disparado por opção do menu, ou por comando do operador.

10

⇒ Arquivo de Log (ata) onde são gravadas as ações elementares de uma transação que venham a modificar a base de dados. Permite desfazer (undo) ou refazer (redo) as ações elementares.

TIPOS DE LOG • Histórico incremental com informações adiadas (até o commit).

LOG = Ident. transação + identificador do objeto físico + novo valor Ex: T, Início T, A, 170 T, B, 130 T, Fim Em caso de falha, não precisa desfazer as ações, ignorando as não terminadas. Para refazer utilizar somente as bem sucedidas. VANTAGEM: não precisa desfazer as ações; DESVANTAGEM: consulta o objeto antes do COMMIT; “overhead” de duplo acesso ao BD.

• Histórico incremental com atualização imediata LOG = Ident. transação + Ident. do objeto Físico + valor anterior + valor novo Ex: T, Início T, A, 200, 170 T, B, 100, 130 T, Fim Em caso de falha, deve-se desfazer as ações não terminadas. Para refazer (redo) utilizar o valor novo. VANTAGEM: não tem “overhead” de duplo acesso ao BD; DESVANTAGEM: necessidade de desfazer as operações mal sucedidas;

⇒ check-point: Evita que todo arquivo de log (seqüencial) precise ser processado para saber as transações a serem refeitas e/ou desfeitas. O CHECK-POINT garante que todas as operações foram refletidas no BD.

DETECÇÃO: flags (saída norma); auditoria;

11

RECUPERAÇÃO: utilização de programa que desfaça ou refaça as operações (recuperação de índices, recuperação de arquivos).

(C) CONTROLE DE CONCORRÊNCIA: As anomalias de sincronismo entre transações concorrentes causam o acesso a dados inconsistentes e a perda de atualizações.

T R A N S A Ç Ã O A

T R A N S A Ç Ã O B

L E R A = 1 00

-----

-----

L E R A = 10 0 -----

A - 50 = 50 -----

A - 1 0 = 90

T E M P O T 1 T 2 T 3 T 4

Para evitar anomalias, dois métodos podem ser implementados: pré-ordenação ou bloqueio. Em função do melhor tempo de resposta, o método de bloqueio é o utilizado comercialmente. MÉTODO BASEADO EM BLOQUEIO As transações antes de acessarem um objeto (lógico ou físico) devem tentar adquirir um bloqueio sobre ele. O bloqueio pode ser a nível de arquivo, página (segmento, partição), registro ou campo, o que dá a granularidade do bloqueio. Quanto maior a granularidade, maior o nível de concorrência, e menor o “overhead” de controle. TIPOS DE BLOQUEIO: ⇒ BLOQUEIO EXCLUSIVO: só é acessado pela transação que executa o

bloqueio; ⇒ BLOQUEIO COMPARTILHADO: só é acessado pelas transações que executam uma ação de bloqueio compartilhado. FORMA DE BLOQUEIO: DEAD-LOCK: prevenção, detecção e recuperação.

12

ANTES DA LEITURA

LOCK

LEITURA

EDIÇÃO

GRAVAÇÃO

UNLOCK

N

S

I

PROBLEMA: performance seo usuário demorar na edição

ANTES DA GRAVAÇÃO

LOCK

LEITURA

EDIÇÃO

GRAVAÇÃO

UNLOCK

N

S

II

PROBLEMA: integridade dos dados.só o último terá a atualização. tolerado emalterações independentes de valores anteriores

RELEITURA

LOCK

LEITURA

EDIÇÃO

GRAVAÇÃO

UNLOCK

N

S

III

PROBLEMA: overhead de acesso ecomparação

COMPARA<>

=

1.3.7 Economia O custo do projeto deve ser balanceado de acordo com:

• Custo da tecnologia; • Custo operacional; • Custo de construção e manutenção

13

2. FASES DO PROJETO Dois modelos são utilizados nas fases de projeto. O Modelo de Implementação do Sistema e o Modelo de Implementação de Programas.

2.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.1.1 Modelo de Processador As atividades essenciais identificadas na fase de análise, bem como as atividades adicionais necessárias devido a limitação da tecnologia, devem, em tempo de projeto, ser alocadas a processadores. Dentre as possíveis opções, verifica-se:

• Todo modelo essencial alocado a um único processador. Esta opção é conhecida como solução mainframe;

• Principais funcionalidades de um diagrama nível 0 de um DFD serem alocadas a diferentes processadores. Esta solução costuma ser chamada de solução distribuída;

• Pode ainda ser escolhida uma opção intermediária entre as duas citadas anteriormente, com o objetivo de minimizar custos, maximizar a confiabilidade.

Desta forma, o empacotamento de atividades e dados pode levar a uma distribuição de atividades essenciais e/ou containers por mais de um processador, ou mesmo, repetição de atividades essenciais e/ou containers em mais de um processador. Como a comunicação entre processadores é mais lenta que a comunicação entre processos no mesmo processador, o projetista deve tentar agrupar processos e depósitos que tenham alto grau de comunicação em um mesmo processador. Os principais problemas encontrados são:

• Custo: dependendo da natureza do sistema, a implementação em um processador único pode ser ou não a mais barata;

• 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. Por outro lado, deve-se verificar uma possível ineficiência na comunicação entre os processadores;

14

• Segurança: por questões de segurança, pode ser necessário a alocação de alguns processos e dados em processadores localizados em áreas protegidas. Por outro lado, a comunicação entre processadores pode ser proibitiva pelos mesmos motivos;

• Confiabilidade: em função da confiabilidade, o projetista pode decidir por configurações que permitam que parte de um sistema fique disponível ainda que outras partes estejam inoperantes. Pode-se utilizar processadores de reserva, bem como cópia de processos e dados em vários processadores.

Como forma de auxílio para a montagem do modelo de processador, é sugerida a montagem de uma lista, no formato da Figura 2.1, com as atividades essenciais acrescida das atividades tecnológicas, tais como geração de histórico, definição de perfil de usuário, etc.

Figura 2.1: Lista de Atividades para o Modelo de Processador

2.1.2 Modelo de Tarefa A partir do Modelo de Processador, deve-se fazer o empacotamento das atividades em tarefas “on-line”, “batch” e “real time”. O sistema operacional é responsável pelo gerenciamento de uma ou mais tarefas em um processador. A estratégia de agrupar atividades em tarefas consiste em verificar a forma de utilização do sistema, e o tempo de resposta esperado para cada atividade. Deve-se entender como tarefa uma atividade independente e assíncrona. Ao final do empacotamento tem-se a lista de tarefas por processadores. Como forma de auxílio para a elaboração do Modelo de Tarefas, é sugerida a utilização da lista da figura 2.2.

15

Figura 2.2: Lista de Tarefas para o Modelo de Tarefas

2.2 Modelo de Implementação de Programa Nesta fase, o objetivo é organizar o sistema em programas. Cada programa consiste em uma hierarquia composta por várias hierarquias menores. Existem diversas propostas para chegar a uma estrutura de software hierárquica, 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. O Diagrama de Estrutura Modular, também conhecido como DEM, é descrito em detalhes no próximo capítulo.

16

3. DIAGRAMA DE ESTRUTURA MODULAR

3.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. Para isso, o modelo procura atingir os seguintes objetivos:

• Precisão - um módulo deve fazer exatamente o que se espera dele; • Solidez - capacidade de um módulo manipular corretamente situações

inesperadas. Um módulo sólido não propaga erros; • Extensibilidade - 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.

• Facilidade de adaptação - os módulos devem ser de tal forma que possam ser facilmente adaptados a novas utilizações;

• Reutilização - os módulos devem ser projetados de tal forma que possam ser utilizados em mais de uma aplicação.

• Com estratégia para alcançar os objetivos mencionados, 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. Assim, 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;

• Poucas interfaces - um módulo deve interagir com outros o mínimo possível, pois quanto mais interfaces tiverem uns com os outros, mais difícil será a manutenção dos mesmos;

• Pequenas interfaces - a interface de um módulo deve precisar somente das informações necessárias para que o mesmo complete a tarefa. Este princípio limita as ligações que um módulo tem com uma aplicação em particular, tornando-o mais fácil de ser reutilizado;

• Interfaces explícitas - as interfaces devem ser feitas de forma que todas as informações pertinentes sejam claramente especificadas no código fonte;

• Clareza - um módulo deve ser dedicado a uma finalidade bem definida, e a função desempenhada pelo módulo não deve gerar nenhum “efeito colateral” inesperado. Uma vantagem da obediência deste princípio é a facilidade de depuração.

3.2 Componentes do DEM A seguir serão apresentados os principais componentes do DEM e suas características sintáticas.

17

3.2.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, sendo ideal para que os outros módulos sejam uma caixa preta” A simbologia utilizada para representar um módulo é ilustrada na Figura 3.1.

Figura 3.1: 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. Pode-se utilizar em um modelo módulos já pré-definidos, isto é, módulos já existentes que são reutilizados. A figura 3.2 apresenta a simbologia para um módulo pré-definido.

Figura 3.2: Simbologia de representação de Módulo Pré-Definido

3.2.2 Hierarquia de Módulos A hierarquia entre os módulos é representada na Figura 3.3. O módulo A chama o módulo B que executa sua função e retorna ao módulo A.

18

Figura 3.3: Hierarquia de Módulos

Já a figura 3.4 ilustra uma outra hierarquia entre módulos:

Figura 3.4: Exemplo de uma Hierarquia entre Módulos A chamada de um determinado módulo pode ser:

19

• Incondicional - o módulo subordinado sempre será ativado pelo seu superior. Na figura 3.4, o módulo B é ativado através de uma chamada embutida na implementação do módulo A.

• Condicional - corresponde a uma seleção ou decisão. A ativação de um módulo subordinado é determinada por uma condição embutida na implementação do módulo superior. A figura 3.5 ilustra a simbologia referente a ativação condicional.

Figura 3.5: Chamada condicional de Módulos

• Repetitiva - um módulo subordinado pode ser ativado pelo seu superior mais de uma vez, em função de uma condição. A figura 3.6 apresenta uma ativação repetitiva.

20

Figura 3.6: Chamada repetitiva de Módulos Quando um módulo ativa outro módulo, passa algumas informações denominadas de parâmetros da chamada. Desta forma, um módulo pode tanto receber quanto passar parâmetros. Os possíveis tipos de parâmetros são:

• Dado - corresponde a informações existentes no mundo real, ou seja fazem parte do problema

• Controle - corresponde a informações não existentes no mundo real, não tendo relevância para o mundo externo, apenas para o funcionamento do sistema

A figura 3.7 ilustra a simbologia utilizada para representar no diagrama os dados e controles que fluem entre os módulos. CPF indica um fluxo de dado, já EOF (“end offile”) corresponde a um controle.

21

Figura 3.7: Tipo de parâmetros entre Módulos

3.2.3 Tipos de Módulos Os módulos dividem-se em quatro tipos básicos, determinados pela direção do fluxo dos dados:

• Aferente - envia informação para seu superior de baixo para cima; • Eferente - envia informação para seu subordinado de cima para baixo; • Transformador - recebe informação de seu superior, faz algum tipo de

transformação e retorna uma nova informação ao seu superior; • Coordenador - coordena a comunicação de seus subordinados.

A Figura 3.8 ilustra os diferentes tipos de módulos.

Figura 3.8: Tipos de Módulos

22

3.2.4 Conector Conector é utilizado para representar módulos repetidos ou referenciar módulos localizados em páginas diferentes. O conector minimiza o emaranhado de traços. A figura 3.9 ilustra os dois tipos de conectores.

Figura 3.9: Simbologia para Conectores A figura 3.10 ilustra um exemplo de parte de um modelo. Note que o módulo obter data corrente é pré-definido. Para deixar o modelo mais “limpo”, é utilizado o conector DH, que faz referência ao módulo obter data corrente, que é subordinado a mais de um módulo. O conector ODC (obter detalhe cliente) referencia um módulo localizado em outra página do modelo (figura 3.11).

23

Figura 3.10: Exemplo de parte de um modelo

Figura 3.11: Exemplo do uso de Conector de Página

24

3.2.5 Especificação de Módulos É a forma de definir o funcionamento interno de cada módulo, e sua especificação deve conter:

• Função; • Entradas e saídas; • Lógica interna do módulo. Esta lógica pode ser expressa de forma genérica

(o que fazer) ou de forma detalhada através de pseudocódigo (como fazer).

3.3 Critérios de Qualidade do DEM

3.3.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. Os tipos de Acoplamento são:

• Dados • Imagem • Controle • Comum • Conteúdo • Acoplamento de Dados

1) Acoplamento de Dados Corresponde a comunicação de dados necessária entre módulos. Uma vez que os módulos têm que se comunicar, a ligação de dados é inevitável, e não é crítica desde que mantidas as taxas mínimas. Deve-se tomar cuidado com o chamado dado migrante (um grupo de informações que vagueia pelo sistema), indesejável e sem sentido para a maioria dos módulos pelos quais passa. A figura 3.12 ilustra um Acoplamento de Dados.

25

Figura 3.12:Exemplo de Acoplamento de Dados

2) Acoplamento de Imagem

Dois módulos apresentam Acoplamento por Imagem se eles fazem referência a uma mesma estrutura de dados. Este tipo de Acoplamento tende a fornecer mais dados do que o necessário a um módulo. A figura 3.13 ilustra um exemplo de Acoplamento por Imagem.

Figura 3.13: Exemplo de Acoplamento de Imagem

26

3) 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.14 ilustra um Acoplamento de Controle.

Figura 3.14: Exemplo de Acoplamento de Controle

No primeiro exemplo, o acoplamento não é tão crítico uma vez que o controle indica uma validação, porém o segundo exemplo exige que o módulo que enviou o controle (validar pedido) conheça o outro módulo.

4) Acoplamento Comum

Dois módulos possuem Acoplamento Comum quando fazem referência a uma área global de dados (ex. Working Storage Section da linguagem Cobol). A figura 3.15 apresenta um exemplo de Acoplamento Comum.

27

Figura 3.15: 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; • Programas com muitos dados globais são de difícil entendimento; • Fica difícil descobrir que módulos devem ser alterados quando um dado é

modificado.

5) 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 (GOTO). Tal Acoplamento torna o conceito de caixas-pretas sem sentido. A figura 3.16 ilustra um exemplo de Acoplamento de Conteúdo.

28

Figura 3.16: Exemplo de Acoplamento de Conteúdo

3.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

3.3.3 Coesão Coesão mede a intensidade da associação funcional dos elementos de um módulo. Deseja-se módulos altamente coesos, cujos elementos são relacionados um com os outros. Por outro lado, os elementos de um módulo não devem ser fortemente relacionados com os elementos de outros módulos, pois isto levaria a um forte acoplamento entre eles. Ter certeza de que todos os módulos têm boa coesão é a melhor forma de minimizar o acoplamento. Os tipos de Coesão são:

29

• Funcional • Sequencial • Comunicacional • Procedural • Temporal • Lógica • Coincidental • Coesão Funcional

1) 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. A figura 3.17 ilustra módulos com Coesão Funcional.

Figura 3.17: Exemplo de Coesão Funcional

2) Coesão Seqüencial

Um módulo apresenta Coesão Seqüencial 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. Este fluxo estabelece uma seqüência de execução das funções, no entanto, não se pode caracterizar o conjunto delas como uma única tarefa.

30

A Figura 3.18 ilustra um módulo com Coesão Seqüencial. No exemplo, verifica-se que exibir consulta executa duas atividades bem distintas e que poderiam ser representadas pelos módulos:

• Obter registro • Exibir dados

Figura 3.18: Exemplo de Coesão Seqüencial

Um módulo com Coesão Seqüencial caracteriza-se por ser de fácil manutenção porém de baixa reutilização, pois contém atividades que são utilizadas juntas.

3) Coesão Comunicacional

Um módulo possui Coesão Comunicacional quando suas funções internas estão relacionadas por utilizarem as mesmas informações, ou seja, utilizam a mesma entrada ou mesma saída. Nesta situação o módulo fornece mais informações que o necessário. A figura 3.19 ilustra um módulo com Coesão Comunicacional. 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:

• Obter nome cliente • Obter resultado empréstimo

31

Figura 3.19: Exemplo de Coesão Comunicacional Módulos com Coesão Comunicacional e Sequencial são semelhantes, pois ambos contém atividades organizadas em torno dos dados do problema original. 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. Já em um módulo com coesão comunicacional a ordem de execução não é importante.

4) Coesão Procedural Um módulo possui Coesão Procedural quando suas funções internas executam atividades diferentes e não correlacionadas, exceto por serem executadas em uma mesma ordem, nas quais o controle flui ( e não os dados ) de uma atividade para outra. É comum em um módulo com Coesão Procedural que os dados de entrada e saída tenham pouca relação. É típico também que tais módulos devolvam resultados parciais, tais como: flags, chaves, etc. A figura 3.20 ilustra o módulo Tratar Saque isolado (parte esquerda da figura) com Coesão Procedural, e sua fatoração para módulos funcionalmente coesos na parte mais a direita da figura.

32

Figura 3.20: Exemplo de Coesão Procedural

5) 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 ordem de execução de atividades é mais importante em módulos procedurais do que em módulos temporais. A Figura 3.21 ilustra um módulo com Coesão Temporal.

Figura 3.21: Exemplo de Coesão Temporal

6) Coesão Lógica Um módulo possui Coesão Lógica quando suas funções internas contribuem para atividades da mesma categoria geral, onde a atividade é selecionada fora do módulo.

33

Desta forma, módulos logicamente coesos apresentam uma interface descaracterizada. A figura 3.22 ilustra um módulo com Coesão Lógica.

Figura 3.22: Exemplo de Coesão Lógica

7) Coesão Coincidental Um módulo possui Coesão Coincidental quando suas funções não possuem nenhuma correlação entre si, 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. A figura 3.23 ilustra uma Coesão Coincidental.

34

Figura 3.23 Exemplo de Coesão Coincidental

3.3.4 Determinação do Tipo de Coesão A figura 3.24 mostra uma estratégia para identificar o tipo de Coesão de um determinado módulo.

35

Figura 3.24: Estratégia para identificação dos tipos de Coesão 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

3.4 Diretrizes Adicionais do Projeto Além do Acoplamento e Coesão devemos considerar outras diretrizes dentro do Projeto tais como Factoring, Divisão de Decisão, Fan-In, Fan-Out, etc.

3.4.1 Factoring Corresponde a separação de uma função contida em um módulo, passando-a para um novo módulo. Este separação pode ter com objetivo:

• Reduzir o tamanho do módulo; • Obter as vantagens modulares de um projeto top-down, tornando o sistema

mais compreensível e permitindo modificações mais localizadas; • Evitar a codificação de uma mesma função em mais de um módulo; • Prover módulos de utilização mais genérica; • Simplificar a implementação.

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. A figura 3.20, já apresentada, ilustra uma fatoração.

3.4.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. Deve-se evitar ao máximo a divisão de decisão. A parte referente a execução da decisão deve ser mantida o mais próximo possível da parte referente ao

36

reconhecimento, a fim de que a informação reconhecida não tenha que percorrer um longo caminho para ser processada (dado migrante).

• Escopo de Controle: conjunto formado por um módulo e todos os seus subordinados;

• Escopo de Efeito de uma Decisão: conjunto de todos os módulos cujo seu procedimento depende da decisão.

É importante que o Escopo de Efeito de uma Decisão de um módulo seja um subconjunto do Escopo de Controle deste módulo. Sempre que esta regra for violada (figura 3.25), deve-se elaborar uma nova organização dos módulos com o objetivo de aproximar o reconhecimento da execução (figura 3.26).

Figura 3.25: Exemplo de um diagrama com Divisão de Decisão

37

Figura 3.26: Exemplo de um Diagrama sem Divisão de Decisão

3.4.3 Formas de um Modelo

• Input-Driven Corresponde ao modelo que realiza pouco processamento em seu lado aferente, de modo que os módulos superiores lidam com dados físicos e não refinados. Esta forma não é desejável, pois muitos módulos no topo do sistema estão relacionados com o formato físico da entrada. A figura 3.27 ilustra o formato de um modelo Input-Driven.

38

Figura 3.27: Formato de um modelo Input-Driven

• Output-Driven Esta forma é mais rara de se verificar, 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.28 ilustra o formato de um modelo Output-Driven.

39

Figura 3.28: 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. No lado aferente o dado é inicialmente editado e desblocado, deixando de depender da forma de entrada no sistema. No lado eferente, o dado é independente de qualquer formato especial de saída desejado pelo usuário. A figura 3.29 ilustra o formato de um modelo Balanceado.

40

Figura 3.29: Formato de um modelo Balanceado

3.4.4 Informações de Erro Erros devem ser relatados pelo módulo que os detectou e que conhece sua natureza. 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; • É necessário um número artificial de mensagem para acessá-la; • A codificação não fica tão compreensível.

3.4.5 FAN-OUT e FAN-IN FAN-OUT corresponde ao número de subordinados imediatos de um módulo.

41

Deve-se limitar o FAN-OUT de um módulo em torno de sete. Para corrigir um alto FAN-OUT pode-se utilizar o Factoring de módulos. A Figura 3.30 ilustra um modelo com um alto FAN-OUT.

Figura 3.30: Exemplo de um modelo com alto FAN-OUT FAN-IN corresponde ao número de módulos superiores de um módulo. Um alto FAN-IN acarretando reutilização de módulos. Existem duas regras para restringir o FAN-IN:

• Módulos com FAN-IN devem ter coesão funcional, ou no mínimo coesão comunicacional ou sequencial;

• A interface deve ter os mesmos números e tipos de parâmetros. A Figura 3.31 apresenta um modelo com alto FAN-IN.

42

Figura 3.31: Exemplo de um modelo com alto FAN-IN

3.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, utilizadas de acordo com as características dos DFDs a serem transformados. São elas:

• Análise de Transformação • Análise de Transação

3.5.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. Esta estratégia baseia-se em: Passo 1: identificar o ramo aferente, o ramo eferente, e o centro de transformação do nível do DFD, onde:

• Ramo aferente corresponde aos elementos considerados como entradas; • Ramo eferente corresponde aos elementos já alterados para a saída; • Ramo de transformação corresponde a fase em que os dados passam de

aferente para eferente.

Passo 2: considerar cada processo como um módulo e adotar o algoritmo a seguir para escolha do módulo de mais alto nível da hierarquia (escolha do chefe). 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, 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.

A figura 3.32 apresenta um DFD já com a identificação do centro de transformação. A figura 3.33 ilustra a derivação para o DEM a partir da escolha do processo P4 como “chefe”. Já a figura 3.34 apresenta um novo diagrama onde o módulo “chefe” não corresponde a nenhum processo do DFD.

43

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

44

Figura 3.34: 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; • Efetuar factoring; • Adicionar módulos de manipulação de erros; • Checar critérios de projeto.

3.5.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. 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; • Utilizar um módulo para selecionar a transação desejada; • Para cada módulo individual aplicar Análise de Transformação ou Análise

de Transação, se houver explosão do mesmo.

45

A figura 3.35 ilustra um DFD que após a aplicação da Análise de Transação resulta o diagrama da figura 3.36.

Figura 3.35: Exemplo de DFD com ligações entre processos via depósito de dados PX

Figura 3.36: Exemplo de utilização de Análise de Transação

46