ESTADO DE MINAS GERAIS UNIVERSIDADE ESTADUAL DE MONTES CLAROS CENTRO DE CINCIAS EXATAS E TECNOLGICAS DEPARTAMENTO DE CINCIAS DA COMPUTAO

Curso Seqencial em Tecnologias da Informao

Disciplina: Projeto de Sistemas de Informao Carga Horria: 80 horas Perodo: 3 Turma: _______ Ementa: Projeto Estruturado: Anlise de transformao. Anlise de transao. Modularidade. Coeso. Acoplamento. Ferramentas do projeto estruturado. Noes de projeto orientado a objetos. Bibliografia: PRESSMAN, Roger S. Engenharia de software. Ed. Makron Books, 1995. GANE, Chris.SARSON, Trish. Anlise estruturada de sistemas. Ed. LTC, 1999 PDUA, Wilson. Engenharia de software: fundamentos, mtodos e tcnicas, Ed. LTC, 2003. Perodo: 07/03/2006 a 06/04/2006 Professor: __________________________________________________

NDICE
1. INTRODUO ............................................................................................................................. 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 CRITRIOS DE QUALIDADE DO PROJETO ................................................................................... 5 1.3.1 COMPLETEZA .............................................................................................................................. 5 1.3.2 MANUTENIBILIDADE .................................................................................................................. 5 1.3.3 PERFORMANCE ........................................................................................................................... 6 1.3.4 SEGURANA................................................................................................................................ 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 IMPLEMENTAO DO SISTEMA ........................................................................... 14 2.1.1 MODELO DE PROCESSADOR...................................................................................................... 14 2.1.2 MODELO DE TAREFA ................................................................................................................ 15 2.2 MODELO DE IMPLEMENTAO DE PROGRAMA ....................................................................... 16 3. DIAGRAMA DE ESTRUTURA MODULAR.......................................................................... 17 3.1 INTRODUO .............................................................................................................................. 17 3.2 COMPONENTES DO DEM ........................................................................................................... 17 3.2.1 MDULO ................................................................................................................................... 18 3.2.2 HIERARQUIA DE MDULOS ...................................................................................................... 18 3.2.3 TIPOS DE MDULOS .................................................................................................................. 22 3.2.4 CONECTOR ................................................................................................................................ 23 3.2.5 ESPECIFICAO DE MDULOS.................................................................................................. 25 3.3 CRITRIOS DE QUALIDADE DO DEM........................................................................................ 25 3.3.1 ACOPLAMENTO ......................................................................................................................... 25 3.3.2 COMPARAO DOS TIPOS DE ACOPLAMENTO.......................................................................... 29 3.3.3 COESO .................................................................................................................................... 29 3.3.4 DETERMINAO DO TIPO DE COESO ...................................................................................... 35 3.4 DIRETRIZES ADICIONAIS DO PROJETO..................................................................................... 36 3.4.1 FACTORING ............................................................................................................................... 36 3.4.2 DIVISO DE DECISO ............................................................................................................... 36 3.4.3 FORMAS DE UM MODELO ......................................................................................................... 38 3.4.4 INFORMAES DE ERRO ........................................................................................................... 41 3.4.5 FAN-OUT E FAN-IN ............................................................................................................... 41 3.5 ESTRATGIA PARA DERIVAR O DFD PARA O DEM ................................................................. 43 3.5.1 ANLISE DE TRANSFORMAO ................................................................................................ 43 3.5.2 ANLISE DE TRANSAO ......................................................................................................... 45

1. INTRODUO 1.1 Proposta para o Projeto

Projeto Estruturado de Sistemas a atividade de transformao das necessidades do usurio, provenientes da fase de Anlise, em um plano de implementao atravs da automao eletrnica. Nesta fase, deixa-se de ter a tecnologia perfeita, passando a levar em considerao o hardware e software com todas as suas limitaes. 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 soluo. 2) Procura a resoluo da complexidade dos grandes sistemas atravs da segmentao de um sistema em caixas pretas, e pela organizao dessas caixas pretas em uma hierarquia conveniente para implementaes computadorizadas. 3) Utiliza ferramentas, especialmente grficas, para tornar os sistemas de fcil compreenso. 4) Oferece um conjunto de estratgias para desenvolver o projeto da soluo de uma declarao bem definida do problema. 5) Oferece um conjunto de critrios para avaliar a qualidade de um dado projeto-soluo com respeito ao problema a ser resolvido. Para tornar fcil o entendimento o Projeto Estruturado se utiliza basicamente de duas ferramentas principais: O pseudocdigo e o Diagrama de Estruturas. O pseudocdigo uma linguagem de especificao informal que no tem a inteno de ser executado em uma mquina, mas de ser usado na organizao dos pensamentos dos programadores antes da codificao. Apesar de ser uma ferramenta da programao estruturada ela se torna muito til na especificao das rotinas detalhadas a serem executadas pelas caixas pretas. A outra ferramenta o diagrama de estruturas que ilustra a segmentao de um sistema em mdulos mostrando a sua hierarquia, organizao e comunicao. A vantagem do uso do diagrama de estruturas, que a principal ferramenta do projeto estruturado, esto no fato desta ferramenta ser: Grfica Particionvel Rigorosa, mas flexvel 3

Entrada usual para a implementao estruturada Documentao do sistema Um auxlio para a manuteno e modificaes

Qualquer informao que no puder ser descrita pelo diagrama de estrutura pode ser suprida por pseudocdigo ou por alguma outra descrio de mdulos do grfico de estrutura. interessante citar que o projeto estruturado entra em cena aonde a programao estruturada sai, ou seja, em sistemas de mdio porte em diante. Alm do mais, a fase de Projeto procura prover os sistemas de facilidades para: construo testes modificaes entendimento

1.2 Os fundamentos do projeto

1.2.1 Contexto do Projeto
Geralmente as sete fases de um sistema clssico so: Reconhecimento do Problema Estudo de viabilidade Anlise Projeto Implementao Testes Manuteno

1.2.2 Principais sintomas de um projeto inadequado

Abaixo so apontados os principais sintomas de um projeto inadequado: Inadministrveis; Insatisfatrios; Insatisfatrios e improdutivos; No confiveis; Inflexveis e de difcil manutenco; Ineficientes; 4

Qualquer combinao dos itens acima.

1.3 Critrios de Qualidade do Projeto

1.3.1 Completeza
O Projeto no deve perder nada do que foi identificado na fase de anlise como requisito essencial.

1.3.2 Manutenibilidade
Deve-se projetar o sistema de forma a permitir facilidades de alterao devido a: Erros do sistema Novas necessidades do usurio Alteraes do ambiente

Verifica-se que os sistemas mais fceis de alterar so aqueles construdos de forma modular, com cada mdulo desempenhando funes bem definidas e coesas, e com baixo grau de interdependncia ou acoplamento entre os mesmos. Ex: funcionamento de um microcomputador MODULARIZADO
CPU

TECLADO

V D E O

IM P R E S S O R A

NO MODULARIZADO

MICROCOMPUTADOR
Para melhorar a manutenibilidade pode ser necessrio o factoring de um mdulo, que separa funes do mesmo com o objetivo de: Reduzir o tamanho do mdulo 5

Melhorar o entendimento Melhorar a reutilizao de mdulos Separar trabalho de gerenciamento Simplificar a implementao Diminuir nmero de subordinados

Alm disso, qualquer fato, conveno ou deciso de implementao, que tenha possibilidade de mudanas, deve ser isolado no menor nmero de mdulos, o que ir facilitar a alterabilidade. Ex: Fato - n de clientes Conveno - cor codificada com duas letras iniciais - cdigo de cliente Deciso - diretrio de acesso aos dados

1.3.3 Performance
Performance est diretamente relacionada ao uso otimizado dos recursos de hardware, software e pessoal disponveis. Como parmetros de avaliao da Performance, temos: Tempo de processamento Memria ocupada Through-put - dados processados por unidade de tempo Tempo de resposta

Dentre os fatores que afetam o desempenho, temos: Deficincia do projeto de interface Tempo de acesso a discos e perifricos - devido ao tempo gasto em acesso a discos ser muito maior do que operaes na CPU deve-se prover o sistema de mecanismos que minimizem este tempo, empregando-se organizaes de arquivos adequadas. Falta de reorganizao de arquivos - em arquivos grandes e de muita utilizao, deve-se verificar a possibilidade de limpezas peridicas, ou particionamento do mesmo gerando um arquivo atual e um histrico. Processos longos em horrio de pique - deve-se evitar ao mximo a execuo de processos batch de longa durao durante o horrio de pique, tais como transferncia de grandes arquivos, atualizaes de grande volume de dados em banco de dados.

1.3.4 Segurana

Deve-se prover mecanismos para evitar acessos indevidos ao sistema. Como tipos de ameaas segurana, temos: Infiltrao intencional - roubo, sabotagem, grampeamento Infiltrao no intencional - linhas cruzadas, irradiaes Acidentes - erro do usurio, falha de hardware, falha de software PROCEDIMENTOS DE SEGURANA Recursos a serem protegidos: dados arquivos bibliotecas, volumes de discos, volumes de fitas, programas, transaes, terminais, CPU e memria. CONTROLE DE ACESSO: identificar o usurio e autenticando-o e restringindo-o s operaes autorizadas. IDENTIFICAO E AUTENTICAO: IDENTIFICAO: cdigo do usurio + terminal AUTENTICAO: senha, carto, impresso digital, voz, etc... OBS: Senha de uso exclusivo do usurio, devendo ser alterada por ele periodicamente. AUTORIZAO COMPARTIMENTAO: grupos de usurio (classes) Usurio X dados que podem ser lidos Usurio X dados que podem ser modificados Usurio X tipos de transao Usurio X mdulos de programas terminal,

PERFIL
AUTORIZADO

Para controle de acesso ao ambiente, o sistema deve identificar usurio e terminal, restringindo as operaes conforme a necessidade. Cada usurio deve possuir um nico e pessoal: Cdigo de identificao - cpf , identidade ou matrcula Cdigo de autenticao - para validar a identificao inicialmente informada (password, carto magntico, digital, voz, etc). Passwords devem ser secretas, ter de seis a oito caracteres e devem ser trocadas periodicamente. Alm disso, estes cdigos de autenticao nunca devem ser expostos no terminal, e deve ser limitado o nmero de tentativas seguidas sem sucesso de um usurio.

1.3.5 Interatibilidade/Interatividade/Operacionalidade
Corresponde a facilidade do usurio em interagir com o sistema. Para tal, deve-se ter cuidado na escolha da implementao de funes batch/on-line. Cuidados com lay-out de telas e relatrios devem ser observados. As telas devem ser padronizadas para menu; atualizao; consulta; entradas de parmetros; espera de processamentos longos e respostas de consulta. As teclas de funo vlidas em cada tela devem ser indicadas explicitamente. Telas devem ser providas dos dados, conforme o exemplo

Ex:

1. Data 2. Identificao do usurio 3. Cdigo da tela, programa ou mdulo 4. Verso do programa 5. Indicao da operao 6. rea de menu de opes e entrada de dados 7. rea de mensagem de erro relativos operao 8. rea de mensagens interativas com o decorrer da operao
1 2 N O M E D A E M PRESA 5 6 7 8 N O M E D O SISTEM A 3 4

A crtica 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 indicao do campo, se necessrio. Devem-se prover DEFAULTS para entradas padres e utilizao de teclas para acesso a tabelas em campos codificados. Linha de comando deve ser utilizada principalmente para sistemas com um alto nvel hierrquico de telas. Este recurso permite que os usurios atravs de um mneumnico de uma aplicao, tenham acesso a mesma sem a necessidade de navegao pelas telas.

1.3.6 Confiabilidade
Confiabilidade est relacionada a reduo do risco de interrupo no fluxo normal de processamento das informaes causadas por: Indisponibilidade de acesso - o sistema no oferece o servio no tempo estipulado ou desejado. Perda da integridade das informaes

Para aumentar a confiabilidade, algumas medidas podem ser tomadas: (A) RESTRIES DE INTEGRIDADE: podem ser feitas via programa ou diretamente no (SGBD) (Constraints). PREVENO: crtica a entrada de dados; controles temporais de seqencialidade de atualizaes; DETECO: auditoria de Banco de Dados; relatrios de controle; CORREO: programas de acertos que gerem ajustes.

(B) RECUPERAO DE FALHAS: o sistema computacional falvel em todos os seus componentes, cabendo ao projetista detectar as falhas que podero ser recuperadas. Toda recuperao tem um custo, que tem uma parte relativa a preveno, e outra correspondente recuperao propriamente dita. De acordo com a necessidade da aplicao (nvel de confiabilidade) deve ser levado em considerao o custo benefcio. CONCEITO DE TRANSAO (BD) uma seqncia de aes elementares sobre o BD, que devem ser tratadas como se fosse uma unidade atmica (ATOMICIDADE). As operaes recuperveis devem estar dentro de transaes. A transao leva o BD de um estado de consistncia a outro estado de consistncia (CONSISTNCIA). Ex: Suponha que um usurio apresente a seguinte atualizao a um BD utilizado para processar a compensao de cheques bancrios: Debite R$ 50,00 C/C de A Credite R$ 50,00 C/C de B

A - R$ 50,00

B + R$ 50,00

INCIO DO PROGRAMA BT (Begin Transaction) COMMIT (Final bem Sucedido) BT (Begin Transaction) ROLLBACK (Final mal Sucedido)

FIM DO PROGRAMA

PROPRIEDADES NECESSRIAS TRANSAO: seriabilidade e recuperao de suas aes elementares em caso de falha. Existem vrios tipos de falhas: FALHAS DE TRANSAO: ex: overflow aritmtico, run time errors, diviso por zero. O sistema deve forar o ROLLBACK (undo). FALHAS DE SISTEMA: ex: falhas de HW, falta de energia. As informaes do I/O buffers ficam perdidas, e as transaes em andamento no terminam. Para recuperar, o sistema tem que detectar a falha no reincio e restaurar a base de dados. FALHAS DE DISCO: ex: crash, erro na transferncia de dados para o disco. Restaurar a partir de backup e refazer as operaes perdidas (redo). FALHAS DE COMUNICAO: ex: interrupo anormal de uma sesso de comunicao cliente/servidor. O sistema deve forar ROLLBACK das transaes em andamento (undo). FALHA HUMANA: Ex: o operador utilizou uma fita errada para atualizao; o envio de fitas ou disquetes fora de ordem por ns remotos. Alm das crticas normais a campos, devem ser previstas as falhas humanas de operao do sistema. Devem ser utilizados HEADERS no meio magntico que controlem a operao; backup; log. PREVENO Backup uma cpia de segurana que feita para facilitar a recuperao de informaes. Pode ser dinmico ou esttico. Pode ser feito atravs de utilitrios do sistema operacional, ou atravs de programas especficos. Pode ser automtico, disparado por opo do menu, ou por comando do operador.

10

 Arquivo de Log (ata) onde so gravadas as aes elementares de uma transao que venham a modificar a base de dados. Permite desfazer (undo) ou refazer (redo) as aes elementares. TIPOS DE LOG Histrico incremental com informaes adiadas (at o commit).

LOG = Ident. transao + identificador do objeto fsico + novo valor Ex: T, Incio T, A, 170 T, B, 130 T, Fim

Em caso de falha, no precisa desfazer as aes, ignorando as no terminadas. Para refazer utilizar somente as bem sucedidas. VANTAGEM: no precisa desfazer as aes; DESVANTAGEM: consulta o objeto antes do COMMIT; overhead de duplo acesso ao BD. Histrico incremental com atualizao imediata

LOG = Ident. transao + Ident. do objeto Fsico + valor anterior + valor novo Ex: T, Incio T, A, 200, 170 T, B, 100, 130 T, Fim

Em caso de falha, deve-se desfazer as aes no terminadas. Para refazer (redo) utilizar o valor novo. VANTAGEM: no tem overhead de duplo acesso ao BD; DESVANTAGEM: necessidade de desfazer as operaes mal sucedidas; check-point: Evita que todo arquivo de log (seqencial) precise ser processado para saber as transaes a serem refeitas e/ou desfeitas. O CHECK-POINT garante que todas as operaes foram refletidas no BD. DETECO: flags (sada norma); auditoria;

11

RECUPERAO: utilizao de programa que desfaa ou refaa as operaes (recuperao de ndices, recuperao de arquivos). (C) CONTROLE DE CONCORRNCIA: As anomalias de sincronismo entre transaes concorrentes causam o acesso a dados inconsistentes e a perda de atualizaes.
TEM PO TRANSAO A TRANSAO B T1 L ER A = 100 ----T2 ----LER A = 100 T3 A - 50 = 50 ----T4 ----A - 10 = 90

Para evitar anomalias, dois mtodos podem ser implementados: pr-ordenao ou bloqueio. Em funo do melhor tempo de resposta, o mtodo de bloqueio o utilizado comercialmente. MTODO BASEADO EM BLOQUEIO As transaes antes de acessarem um objeto (lgico ou fsico) devem tentar adquirir um bloqueio sobre ele. O bloqueio pode ser a nvel de arquivo, pgina (segmento, partio), registro ou campo, o que d a granularidade do bloqueio. Quanto maior a granularidade, maior o nvel de concorrncia, e menor o overhead de controle. TIPOS DE BLOQUEIO: BLOQUEIO EXCLUSIVO: s acessado pela transao que executa o bloqueio; BLOQUEIO COMPARTILHADO: s acessado pelas transaes que executam uma ao de bloqueio compartilhado. FORMA DE BLOQUEIO: DEAD-LOCK: preveno, deteco e recuperao.

12

I ANTES DA LEITURA

II ANTES DA GRAVAO

III RELEITURA

N LOCK S LEITURA

LEITURA

EDIO LEITURA EDIO N LOCK N S EDIO LOCK S COMPARA <> = GRAVAO GRAVAO GRAVAO

UNLOCK PROBLEMA: performance se o usurio demorar na edio

UNLOCK PROBLEMA: integridade dos dados. s o ltimo ter a atualizao. tolerado em alteraes independentes de valores anteriores

UNLOCK

PROBLEMA: overhead de acesso e comparao

1.3.7 Economia
O custo do projeto deve ser balanceado de acordo com: Custo da tecnologia; Custo operacional; Custo de construo e manuteno

13

2. FASES DO PROJETO
Dois modelos so utilizados nas fases de projeto. O Modelo de Implementao do Sistema e o Modelo de Implementao de Programas.

2.1 Modelo de Implementao do Sistema

O Modelo de Implementao 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 anlise, bem como as atividades adicionais necessrias devido a limitao da tecnologia, devem, em tempo de projeto, ser alocadas a processadores. Dentre as possveis opes, verifica-se: Todo modelo essencial alocado a um nico processador. Esta opo conhecida como soluo mainframe; Principais funcionalidades de um diagrama nvel 0 de um DFD serem alocadas a diferentes processadores. Esta soluo costuma ser chamada de soluo distribuda; Pode ainda ser escolhida uma opo intermediria 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 distribuio de atividades essenciais e/ou containers por mais de um processador, ou mesmo, repetio de atividades essenciais e/ou containers em mais de um processador. Como a comunicao entre processadores mais lenta que a comunicao entre processos no mesmo processador, o projetista deve tentar agrupar processos e depsitos que tenham alto grau de comunicao em um mesmo processador. Os principais problemas encontrados so: Custo: dependendo da natureza do sistema, a implementao em um processador nico pode ser ou no a mais barata; Eficincia: a utilizao de mais de um processador pode levar a um melhor tempo de reposta bem como permitir a execuo paralela de atividades. Por outro lado, deve-se verificar uma possvel ineficincia na comunicao entre os processadores; 14

Segurana: por questes de segurana, pode ser necessrio a alocao de alguns processos e dados em processadores localizados em reas protegidas. Por outro lado, a comunicao entre processadores pode ser proibitiva pelos mesmos motivos; Confiabilidade: em funo da confiabilidade, o projetista pode decidir por configuraes que permitam que parte de um sistema fique disponvel ainda que outras partes estejam inoperantes. Pode-se utilizar processadores de reserva, bem como cpia de processos e dados em vrios processadores.

Como forma de auxlio 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 tecnolgicas, tais como gerao de histrico, definio de perfil de usurio, 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 responsvel pelo gerenciamento de uma ou mais tarefas em um processador. A estratgia de agrupar atividades em tarefas consiste em verificar a forma de utilizao do sistema, e o tempo de resposta esperado para cada atividade. Deve-se entender como tarefa uma atividade independente e assncrona. Ao final do empacotamento tem-se a lista de tarefas por processadores. Como forma de auxlio para a elaborao do Modelo de Tarefas, sugerida a utilizao da lista da figura 2.2.

15

Figura 2.2: Lista de Tarefas para o Modelo de Tarefas

2.2 Modelo de Implementao de Programa

Nesta fase, o objetivo organizar o sistema em programas. Cada programa consiste em uma hierarquia composta por vrias hierarquias menores. Existem diversas propostas para chegar a uma estrutura de software hierrquica, onde destaca-se o Diagrama de Estrutura Modular proposto por Page-Jones que enfatiza a decomposio hierrquica de uma atividade em mdulos individuais que sejam reutilizveis. O Diagrama de Estrutura Modular, tambm conhecido como DEM, descrito em detalhes no prximo captulo.

16

3. DIAGRAMA DE ESTRUTURA MODULAR 3.1 Introduo

Uma das principais finalidades do DEM possibilitar a criao de sistemas que sejam mais confiveis e de fcil manuteno. Para isso, o modelo procura atingir os seguintes objetivos: Preciso - um mdulo deve fazer exatamente o que se espera dele; Solidez - capacidade de um mdulo manipular corretamente situaes inesperadas. Um mdulo slido no propaga erros; Extensibilidade - mdulos devem ser construdos de tal forma que uma nova funcionalidade possa ser adicionada sem a necessidade de se refazer o servio. Facilidade de adaptao - os mdulos devem ser de tal forma que possam ser facilmente adaptados a novas utilizaes; Reutilizao - os mdulos devem ser projetados de tal forma que possam ser utilizados em mais de uma aplicao. Com estratgia para alcanar os objetivos mencionados, os princpios descritos a seguir devem ser considerados: Ocultar informaes - o funcionamento interno de um mdulo deve estar oculto aos outros mdulos. Assim, mdulos podem utiilizar-se de outros mdulos e depender destes para realizar as tarefas esperadas sem se preocupar como devem ser realizadas tais tarefas; Poucas interfaces - um mdulo deve interagir com outros o mnimo possvel, pois quanto mais interfaces tiverem uns com os outros, mais difcil ser a manuteno dos mesmos; Pequenas interfaces - a interface de um mdulo deve precisar somente das informaes necessrias para que o mesmo complete a tarefa. Este princpio limita as ligaes que um mdulo tem com uma aplicao em particular, tornando-o mais fcil de ser reutilizado; Interfaces explcitas - as interfaces devem ser feitas de forma que todas as informaes pertinentes sejam claramente especificadas no cdigo fonte; Clareza - um mdulo deve ser dedicado a uma finalidade bem definida, e a funo desempenhada pelo mdulo no deve gerar nenhum efeito colateral inesperado. Uma vantagem da obedincia deste princpio a facilidade de depurao.

3.2 Componentes do DEM

A seguir sero apresentados os principais componentes do DEM e suas caractersticas sintticas.

17

3.2.1 Mdulo
o elemento separadamente enderevel em um sistema a menor parte do sistema que realiza uma funo completa independente de outras funes um conjunto de instrues de um programa que pode ser chamado por um nome, sendo ideal para que os outros mdulos sejam uma caixa preta

A simbologia utilizada para representar um mdulo ilustrada na Figura 3.1.

Figura 3.1: Simbologia de representao de Mdulo O nome do mdulo deve corresponder a declarao de uma funo, sendo normalmente formado por um verbo indicando uma ao. Pode-se utilizar em um modelo mdulos j pr-definidos, isto , mdulos j existentes que so reutilizados. A figura 3.2 apresenta a simbologia para um mdulo pr-definido.

Figura 3.2: Simbologia de representao de Mdulo Pr-Definido

3.2.2 Hierarquia de Mdulos

A hierarquia entre os mdulos representada na Figura 3.3. O mdulo A chama o mdulo B que executa sua funo e retorna ao mdulo A.

18

Figura 3.3: Hierarquia de Mdulos J a figura 3.4 ilustra uma outra hierarquia entre mdulos:

Figura 3.4: Exemplo de uma Hierarquia entre Mdulos A chamada de um determinado mdulo pode ser:

19

Incondicional - o mdulo subordinado sempre ser ativado pelo seu superior. Na figura 3.4, o mdulo B ativado atravs de uma chamada embutida na implementao do mdulo A. Condicional - corresponde a uma seleo ou deciso. A ativao de um mdulo subordinado determinada por uma condio embutida na implementao do mdulo superior. A figura 3.5 ilustra a simbologia referente a ativao condicional.

Figura 3.5: Chamada condicional de Mdulos Repetitiva - um mdulo subordinado pode ser ativado pelo seu superior mais de uma vez, em funo de uma condio. A figura 3.6 apresenta uma ativao repetitiva.

20

Figura 3.6: Chamada repetitiva de Mdulos Quando um mdulo ativa outro mdulo, passa algumas informaes denominadas de parmetros da chamada. Desta forma, um mdulo pode tanto receber quanto passar parmetros. Os possveis tipos de parmetros so: Dado - corresponde a informaes existentes no mundo real, ou seja fazem parte do problema Controle - corresponde a informaes no existentes no mundo real, no tendo relevncia 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 mdulos. CPF indica um fluxo de dado, j EOF (end offile) corresponde a um controle.

21

Figura 3.7: Tipo de parmetros entre Mdulos

3.2.3 Tipos de Mdulos

Os mdulos dividem-se em quatro tipos bsicos, determinados pela direo do fluxo dos dados: Aferente - envia informao para seu superior de baixo para cima; Eferente - envia informao para seu subordinado de cima para baixo; Transformador - recebe informao de seu superior, faz algum tipo de transformao e retorna uma nova informao ao seu superior; Coordenador - coordena a comunicao de seus subordinados.

A Figura 3.8 ilustra os diferentes tipos de mdulos.

Figura 3.8: Tipos de Mdulos

22

3.2.4 Conector
Conector utilizado para representar mdulos repetidos ou referenciar mdulos localizados em pginas diferentes. O conector minimiza o emaranhado de traos. 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 mdulo obter data corrente pr-definido. Para deixar o modelo mais limpo, utilizado o conector DH, que faz referncia ao mdulo obter data corrente, que subordinado a mais de um mdulo. O conector ODC (obter detalhe cliente) referencia um mdulo localizado em outra pgina do modelo (figura 3.11).

23

Figura 3.10: Exemplo de parte de um modelo

Figura 3.11: Exemplo do uso de Conector de Pgina

24

3.2.5 Especificao de Mdulos

a forma de definir o funcionamento interno de cada mdulo, e sua especificao deve conter: Funo; Entradas e sadas; Lgica interna do mdulo. Esta lgica pode ser expressa de forma genrica (o que fazer) ou de forma detalhada atravs de pseudocdigo (como fazer).

3.3 Critrios de Qualidade do DEM

3.3.1 Acoplamento
O Acoplamento mede o grau de interdependncia entre os mdulos do diagrama. O que se deseja so mdulos de baixo acoplamento para diminuir o mximo possvel o efeito em cadeia quando um mdulo for alterado. Os tipos de Acoplamento so: Dados Imagem Controle Comum Contedo Acoplamento de Dados

1) Acoplamento de Dados Corresponde a comunicao de dados necessria entre mdulos. Uma vez que os mdulos tm que se comunicar, a ligao de dados inevitvel, e no crtica desde que mantidas as taxas mnimas. Deve-se tomar cuidado com o chamado dado migrante (um grupo de informaes que vagueia pelo sistema), indesejvel e sem sentido para a maioria dos mdulos 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 mdulos apresentam Acoplamento por Imagem se eles fazem referncia a uma mesma estrutura de dados. Este tipo de Acoplamento tende a fornecer mais dados do que o necessrio a um mdulo. 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 mdulos so acoplados por controle se um passa um grupo de dados (controle) para o outro para controlar sua lgica interna. A figura 3.14 ilustra um Acoplamento de Controle.

Figura 3.14: Exemplo de Acoplamento de Controle No primeiro exemplo, o acoplamento no to crtico uma vez que o controle indica uma validao, porm o segundo exemplo exige que o mdulo que enviou o controle (validar pedido) conhea o outro mdulo. 4) Acoplamento Comum Dois mdulos possuem Acoplamento Comum quando fazem referncia 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 no desejvel, pois: Um erro em uma rea global pode se propagar por diversos mdulos; Programas com muitos dados globais so de difcil entendimento; Fica difcil descobrir que mdulos devem ser alterados quando um dado modificado.

5) Acoplamento de Contedo Dois mdulos apresentam Acoplamento de Contedo (ou patolgico) se um faz referncia ou desvia a sequncia de instrues para o interior de um outro mdulo (GOTO). Tal Acoplamento torna o conceito de caixas-pretas sem sentido. A figura 3.16 ilustra um exemplo de Acoplamento de Contedo.

28

Figura 3.16: Exemplo de Acoplamento de Contedo

3.3.2 Comparao dos Tipos de Acoplamento

Os tipos de Acoplamento especificados abaixo so apresentados em ordem descrescente (do melhor para o pior tipo). Dados Imagem Controle Comum Contedo

3.3.3 Coeso
Coeso mede a intensidade da associao funcional dos elementos de um mdulo. Deseja-se mdulos altamente coesos, cujos elementos so relacionados um com os outros. Por outro lado, os elementos de um mdulo no devem ser fortemente relacionados com os elementos de outros mdulos, pois isto levaria a um forte acoplamento entre eles. Ter certeza de que todos os mdulos tm boa coeso a melhor forma de minimizar o acoplamento. Os tipos de Coeso so:

29

Funcional Sequencial Comunicacional Procedural Temporal Lgica Coincidental Coeso Funcional 1) Coeso Funcional

Um mdulo apresenta Coeso Funcional quando suas funes internas contribuem para a execuo de uma e apenas uma tarefa relacionada ao problema. A figura 3.17 ilustra mdulos com Coeso Funcional.

Figura 3.17: Exemplo de Coeso Funcional 2) Coeso Seqencial Um mdulo apresenta Coeso Seqencial quando suas funes internas esto envolvidas em atividades de tal forma, que os dados de sada de uma atividade sirvam como dados de entrada para a prxima. Este fluxo estabelece uma seqncia de execuo das funes, no entanto, no se pode caracterizar o conjunto delas como uma nica tarefa.

30

A Figura 3.18 ilustra um mdulo com Coeso Seqencial. No exemplo, verifica-se que exibir consulta executa duas atividades bem distintas e que poderiam ser representadas pelos mdulos: Obter registro Exibir dados

Figura 3.18: Exemplo de Coeso Seqencial Um mdulo com Coeso Seqencial caracteriza-se por ser de fcil manuteno porm de baixa reutilizao, pois contm atividades que so utilizadas juntas. 3) Coeso Comunicacional Um mdulo possui Coeso Comunicacional quando suas funes internas esto relacionadas por utilizarem as mesmas informaes, ou seja, utilizam a mesma entrada ou mesma sada. Nesta situao o mdulo fornece mais informaes que o necessrio. A figura 3.19 ilustra um mdulo com Coeso Comunicacional. No exemplo Obter Detalhes Cliente recebe um mesmo parmetro de entrada Num-Conta e executa duas atividades distintas que poderiam ser representadas pelos mdulos: Obter nome cliente Obter resultado emprstimo

31

Figura 3.19: Exemplo de Coeso Comunicacional Mdulos com Coeso Comunicacional e Sequencial so semelhantes, pois ambos contm atividades organizadas em torno dos dados do problema original. A principal diferena entre eles que um mdulo sequencialmente coeso opera como uma linha de montagem onde suas atividades so executadas em uma ordem especfica. J em um mdulo com coeso comunicacional a ordem de execuo no importante. 4) Coeso Procedural Um mdulo possui Coeso Procedural quando suas funes internas executam atividades diferentes e no correlacionadas, exceto por serem executadas em uma mesma ordem, nas quais o controle flui ( e no os dados ) de uma atividade para outra. comum em um mdulo com Coeso Procedural que os dados de entrada e sada tenham pouca relao. tpico tambm que tais mdulos devolvam resultados parciais, tais como: flags, chaves, etc. A figura 3.20 ilustra o mdulo Tratar Saque isolado (parte esquerda da figura) com Coeso Procedural, e sua fatorao para mdulos funcionalmente coesos na parte mais a direita da figura.

32

Figura 3.20: Exemplo de Coeso Procedural 5) Coeso Temporal Um mdulo possui Coeso Temporal quando suas funes internas executam atividades que esto relacionadas apenas com o tempo (as atividades no esto relacionadas entre si). A ordem de execuo de atividades mais importante em mdulos procedurais do que em mdulos temporais. A Figura 3.21 ilustra um mdulo com Coeso Temporal.

Figura 3.21: Exemplo de Coeso Temporal 6) Coeso Lgica Um mdulo possui Coeso Lgica quando suas funes internas contribuem para atividades da mesma categoria geral, onde a atividade selecionada fora do mdulo. 33

Desta forma, mdulos descaracterizada.

logicamente

coesos

apresentam

uma

interface

A figura 3.22 ilustra um mdulo com Coeso Lgica.

Figura 3.22: Exemplo de Coeso Lgica 7) Coeso Coincidental Um mdulo possui Coeso Coincidental quando suas funes no possuem nenhuma correlao entre si, no h uma ordem especfica de execuo, nem sempre todas as funes so ativadas e a ativao das funes decidida fora do mdulo. A figura 3.23 ilustra uma Coeso Coincidental.

34

Figura 3.23 Exemplo de Coeso Coincidental

3.3.4 Determinao do Tipo de Coeso

A figura 3.24 mostra uma estratgia para identificar o tipo de Coeso de um determinado mdulo.

35

Figura 3.24: Estratgia para identificao dos tipos de Coeso Comparando os tipos de Coeso, podemos classific-los em ordem, como descrito abaixo (do melhor para o pior tipo ): Funcional Sequencial Comunicacional Procedural Temporal Lgica Coincidental

3.4 Diretrizes Adicionais do Projeto

Alm do Acoplamento e Coeso devemos considerar outras diretrizes dentro do Projeto tais como Factoring, Diviso de Deciso, Fan-In, Fan-Out, etc.

3.4.1 Factoring
Corresponde a separao de uma funo contida em um mdulo, passando-a para um novo mdulo. Este separao pode ter com objetivo: Reduzir o tamanho do mdulo; Obter as vantagens modulares de um projeto top-down, tornando o sistema mais compreensvel e permitindo modificaes mais localizadas; Evitar a codificao de uma mesma funo em mais de um mdulo; Prover mdulos de utilizao mais genrica; Simplificar a implementao.

A fatorao de um mdulo grande deve ser efetuada se no diminuir a Coeso e no aumentar o Acoplamento do mdulo original. A figura 3.20, j apresentada, ilustra uma fatorao.

3.4.2 Diviso de Deciso

Uma deciso constituda de duas partes: o reconhecimento da ao a ser tomada e a execuo desta ao. Deve-se evitar ao mximo a diviso de deciso. A parte referente a execuo da deciso deve ser mantida o mais prximo possvel da parte referente ao

36

reconhecimento, a fim de que a informao reconhecida no tenha que percorrer um longo caminho para ser processada (dado migrante). Escopo de Controle: conjunto formado por um mdulo e todos os seus subordinados; Escopo de Efeito de uma Deciso: conjunto de todos os mdulos cujo seu procedimento depende da deciso.

importante que o Escopo de Efeito de uma Deciso de um mdulo seja um subconjunto do Escopo de Controle deste mdulo. Sempre que esta regra for violada (figura 3.25), deve-se elaborar uma nova organizao dos mdulos com o objetivo de aproximar o reconhecimento da execuo (figura 3.26).

Figura 3.25: Exemplo de um diagrama com Diviso de Deciso

37

Figura 3.26: Exemplo de um Diagrama sem Diviso de Deciso

3.4.3 Formas de um Modelo

Input-Driven

Corresponde ao modelo que realiza pouco processamento em seu lado aferente, de modo que os mdulos superiores lidam com dados fsicos e no refinados. Esta forma no desejvel, pois muitos mdulos no topo do sistema esto relacionados com o formato fsico 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, porm tambm desaconselhvel uma vez que mdulos superiores ficam presos a condies fsicas de sada. 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 mdulos superiores lidam com dados de natureza lgica e no fsica. 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 sada desejado pelo usurio. A figura 3.29 ilustra o formato de um modelo Balanceado.

40

Figura 3.29: Formato de um modelo Balanceado

3.4.4 Informaes de Erro

Erros devem ser relatados pelo mdulo que os detectou e que conhece sua natureza. Mensagens de erro, juntas em um mdulo, tem as seguintes vantagens e desvantagens: mais fcil de manter o texto e o formato da mensagem; mais fcil evitar mensagens duplicadas; necessrio um nmero artificial de mensagem para acess-la; A codificao no fica to compreensvel.

3.4.5 FAN-OUT e FAN-IN

FAN-OUT corresponde ao nmero de subordinados imediatos de um mdulo.

41

Deve-se limitar o FAN-OUT de um mdulo em torno de sete. Para corrigir um alto FAN-OUT pode-se utilizar o Factoring de mdulos. 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 nmero de mdulos superiores de um mdulo. Um alto FAN-IN acarretando reutilizao de mdulos. Existem duas regras para restringir o FAN-IN: Mdulos com FAN-IN devem ter coeso funcional, ou no mnimo coeso comunicacional ou sequencial; A interface deve ter os mesmos nmeros e tipos de parmetros.

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 Estratgia para Derivar o DFD para o DEM

A passagem da especificao produzida na fase de anlise para a fase de projeto feita atravs de duas estratgias, utilizadas de acordo com as caractersticas dos DFDs a serem transformados. So elas: Anlise de Transformao Anlise de Transao

3.5.1 Anlise de Transformao

A Anlise de Transformao aplicada no nvel do DFD que apresenta ligao direta entre processos atravs de fluxos de dados. Esta estratgia baseia-se em: Passo 1: identificar o ramo aferente, o ramo eferente, e o centro de transformao do nvel do DFD, onde: Ramo aferente corresponde aos elementos considerados como entradas; Ramo eferente corresponde aos elementos j alterados para a sada; Ramo de transformao corresponde a fase em que os dados passam de aferente para eferente.

Passo 2: considerar cada processo como um mdulo e adotar o algoritmo a seguir para escolha do mdulo de mais alto nvel da hierarquia (escolha do chefe). Se h um bom candidato para chefe no Centro de Transformao Ento escolha o chefe e deixe os demais subordinados a ele Seno promova um novo chefe, considere o centro de transformao como uma nica bolha do DFD e subordine a transformao central e cada ramo aferente e eferente ao novo chefe. A figura 3.32 apresenta um DFD j com a identificao do centro de transformao. A figura 3.33 ilustra a derivao para o DEM a partir da escolha do processo P4 como chefe. J a figura 3.34 apresenta um novo diagrama onde o mdulo chefe no corresponde a nenhum processo do DFD.

43

Figura 3.32: Exemplo de DFD com a identificao do centro de Transformao

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 mdulos de leitura e/ou gravao; Efetuar factoring; Adicionar mdulos de manipulao de erros; Checar critrios de projeto.

3.5.2 Anlise de Transao

A Anlise de Transao aplicada no nvel do DFD que apresenta ligao de processos via depsito de dados. A aplicao da Anlise de Transao deve seguir os seguintes passos: Selecionar como mdulo raz o processo que originou o nvel em anlise; Utilizar um mdulo para selecionar a transao desejada; Para cada mdulo individual aplicar Anlise de Transformao ou Anlise de Transao, se houver exploso do mesmo.

45

A figura 3.35 ilustra um DFD que aps a aplicao da Anlise de Transao resulta o diagrama da figura 3.36.

Figura 3.35: Exemplo de DFD com ligaes entre processos via depsito de dados PX

Figura 3.36: Exemplo de utilizao de Anlise de Transao

46