Analise-estruturada-moderna

Prévia do material em texto

Análise Estruturada Moderna 
 
 
(Apontamentos baseados na metodologia de Yourdon) 
 
 
 
 
 
 
 
 
 
1. INTRODUÇÃO....................................................................................................................................... 4 
2. A NATUREZA DOS SISTEMAS.......................................................................................................... 5 
2.1. CONCEITOS BÁSICOS ........................................................................................................................ 5 
2.2. TIPOS DE SISTEMAS.......................................................................................................................... 5 
2.3. SISTEMAS FEITOS PELO HOMEM ....................................................................................................... 6 
2.4. SISTEMAS DE INFORMAÇÃO ............................................................................................................. 6 
2.5. CLASSIFICAÇÃO QUANTO À FORMA DE PROCESSAMENTO................................................................. 7 
Sistemas Batch .......................................................................................................................................... 7 
Sistemas On-Line ...................................................................................................................................... 7 
Sistemas em Tempo Real........................................................................................................................... 7 
Sistemas Baseados em Conhecimento....................................................................................................... 7 
Sistemas Especialistas .............................................................................................................................. 7 
2.6. CLASSIFICAÇÃO QUANTO AO NÍVEL ORGANIZACIONAL .................................................................... 8 
Sistemas de Processamento de Transacções............................................................................................. 8 
Sistemas de Planeamento e Controlo Operacional................................................................................... 9 
Sistemas de Apoio à Decisão .................................................................................................................... 9 
Sistemas de Planeamento Estratégico .................................................................................................... 10 
2.7. PRINCÍPIOS GERAIS DOS SISTEMAS ................................................................................................ 10 
3. PARTICIPANTES NO DESENVOLVIMENTO DE SISTEMAS ................................................... 11 
3.1. UTILIZADORES ............................................................................................................................... 11 
Classificação por Tipo de Função .......................................................................................................... 11 
Classificação por Nível de Experiência.................................................................................................. 12 
3.2. GESTOR DE PROJECTO.................................................................................................................... 12 
3.3. AUDITORES, CONTROLO DE QUALIDADE E NORMALIZAÇÃO.......................................................... 12 
3.4. ANALISTA DE SISTEMAS................................................................................................................. 13 
3.5. PROJECTISTA DE SISTEMAS ............................................................................................................ 13 
3.6. PROGRAMADOR.............................................................................................................................. 14 
3.7. OPERADOR ..................................................................................................................................... 14 
4. PRINCIPAIS PROBLEMAS NO DESENVOLVIMENTO DE SISTEMAS .................................. 15 
4.1. PRODUTIVIDADE ............................................................................................................................ 15 
Demanda reprimida................................................................................................................................ 15 
Tempo de desenvolvimento ..................................................................................................................... 15 
4.2. CONFIABILIDADE ........................................................................................................................... 17 
4.3. MANUTENIBILIDADE ...................................................................................................................... 18 
4.4. QUALIDADE ................................................................................................................................... 18 
4.5. PORTABILIDADE............................................................................................................................. 19 
4.6. SEGURANÇA................................................................................................................................... 19 
4.7. PRINCIPAIS CAUSAS........................................................................................................................ 19 
5. CICLO DE VIDA DO PROJECTO DE DESENVOLVIMENTO ................................................... 20 
5.1. CONCEITO DE CICLO DE VIDA DE UM PROJECTO ............................................................................ 20 
5.2. OBJECTIVOS ................................................................................................................................... 20 
5.3. CICLO DE VIDA CLÁSSICO.............................................................................................................. 21 
5.4. CICLO DE VIDA SEMI-ESTRUTURADO ............................................................................................ 23 
5.5. CICLO DE VIDA ESTRUTURADO...................................................................................................... 24 
Levantamento.......................................................................................................................................... 24 
Análise .................................................................................................................................................... 25 
Projecto................................................................................................................................................... 25 
Implementação........................................................................................................................................ 25 
Geração de Testes de Aceitação ............................................................................................................. 26 
Controlo de Qualidade ........................................................................................................................... 26 
 1
Descrição dos Procedimentos................................................................................................................. 26 
Conversão das Bases de Dados .............................................................................................................. 26 
Instalação ............................................................................................................................................... 26 
5.6. ABORDAGEM RADICAL VERSUS CONSERVADORA.......................................................................... 26 
5.7. CICLO DE VIDA DA PROTOTIPAGEM ............................................................................................... 27 
6. MODIFICAÇÕES NA ANÁLISEDE SISTEMAS............................................................................ 29 
6.1. A PASSAGEM PARA A ANÁLISE ESTRUTURADA .............................................................................. 29 
6.2. MODIFICAÇÕES NA ANÁLISE ESTRUTURADA ................................................................................. 30 
6.3. SURGIMENTO DAS FERRAMENTAS AUTOMATIZADAS DE ANÁLISE ................................................. 31 
6.4. USO DA PROTOTIPAGEM................................................................................................................. 31 
7. DIAGRAMA DE FLUXO DE DADOS............................................................................................... 32 
7.1. COMPONENTES DE UM DFD ........................................................................................................... 32 
Processos ................................................................................................................................................ 32 
Fluxos de Dados ..................................................................................................................................... 32 
Depósitos de Dados ................................................................................................................................ 33 
Entidades Externas ................................................................................................................................. 34 
7.2. DIRECTRIZES PARA ELABORAÇÃO DE DFD .................................................................................... 35 
Escolher Nomes Significativos................................................................................................................ 35 
Devem-se numerar os Processos ............................................................................................................ 35 
Evitar DFD Complexos........................................................................................................................... 35 
Refazer tantas vezes quantas forem necessárias..................................................................................... 35 
Criar diagramas esteticamente agradáveis ............................................................................................ 36 
Certificar-se de que o DFD seja logicamente consistente ...................................................................... 36 
Posição dos elementos ............................................................................................................................ 36 
Duplicação de elementos ........................................................................................................................ 36 
7.3. DFD COM NÍVEIS ........................................................................................................................... 37 
Diagrama de Contexto............................................................................................................................ 37 
Diagrama Nível 0.................................................................................................................................... 37 
Diagrama de Níveis Intermédios ............................................................................................................ 38 
8. DICIONÁRIO DE DADOS.................................................................................................................. 39 
8.1. NOTAÇÃO....................................................................................................................................... 39 
8.2. DEFINIÇÕES.................................................................................................................................... 40 
8.3. ELEMENTOS OPCIONAIS.................................................................................................................. 40 
8.4. ITERAÇÃO ...................................................................................................................................... 40 
8.5. SELECÇÃO...................................................................................................................................... 41 
8.6. SINÓNIMO ...................................................................................................................................... 41 
8.7. DEFINIÇÃO DE DEPÓSITOS.............................................................................................................. 41 
9. DIAGRAMA DE ENTIDADES-RELACIONAMENTOS ................................................................ 42 
9.1. ENTIDADES .................................................................................................................................... 42 
9.2. RELACIONAMENTOS....................................................................................................................... 42 
Tipos de Relacionamentos ...................................................................................................................... 42 
Classificações adicionais........................................................................................................................ 43 
Cardinalidade ......................................................................................................................................... 43 
Casos especiais de relacionamentos....................................................................................................... 43 
10. DIAGRAMA DE TRANSIÇÕES DE ESTADO............................................................................ 44 
10.1. NOTAÇÃO....................................................................................................................................... 44 
Estado ..................................................................................................................................................... 44 
Mudanças de Estado............................................................................................................................... 44 
Condições e Acções ................................................................................................................................ 45 
10.2. DIAGRAMAS SUBDIVIDIDOS............................................................................................................ 46 
 2
10.3. CONSTRUINDO UM DTE ................................................................................................................. 47 
11. ESPECIFICAÇÕES DE PROCESSOS.......................................................................................... 48 
11.1. LINGUAGEM ESTRUTURADA .......................................................................................................... 48 
11.2. PRÉ/PÓS ......................................................................................................................................... 52 
Pré-Condições ........................................................................................................................................ 52 
Pós-Condições ........................................................................................................................................ 53 
11.3. TABELA DE DECISÃO...................................................................................................................... 54 
Estrutura de uma Tabela de Decisão...................................................................................................... 54 
Criar uma Tabela de Decisão................................................................................................................. 54 
11.4. ÁRVORE DE DECISÃO ..................................................................................................................... 55 
Criar uma Árvore de Decisão.................................................................................................................55 
12. O MODELO ESSENCIAL.............................................................................................................. 56 
12.1. A ABORDAGEM CLÁSSICA .............................................................................................................. 56 
Os quatro modelos .................................................................................................................................. 56 
Porque a abordagem clássica não funcionava ....................................................................................... 56 
12.2. O QUE É O MODELO ESSENCIAL ..................................................................................................... 56 
12.3. DIFICULDADES NA CONSTRUÇÃO DO MODELO ESSENCIAL............................................................. 57 
12.4. COMPONENTES DO MODELO ESSENCIAL........................................................................................ 57 
12.5. O MODELO AMBIENTAL................................................................................................................. 58 
12.6. O MODELO COMPORTAMENTAL PRELIMINAR ................................................................................ 58 
A Abordagem Clássica (Top-Down) ....................................................................................................... 58 
Particionamento por eventos .................................................................................................................. 58 
12.7. O MODELO COMPORTAMENTAL FINAL .......................................................................................... 59 
Nivelamento ............................................................................................................................................ 59 
Complementar Dicionário de Dados ...................................................................................................... 59 
Complementar as Especificações de Processos...................................................................................... 59 
Complementar o Modelo de Dados ........................................................................................................ 59 
 
 
 3
1. Introdução 
 
“A análise [de sistemas] é frustrante, repleta de relacionamentos entre pessoas, indefinida 
e difícil. Resumindo, é fascinante. Depois que você é fisgado, os velhos e fáceis prazeres da 
construção de sistemas nunca mais serão suficientes para satisfazê-lo” 
Tom DeMarco, 1978, Structured Analysis and Systems Specification 
 
 
Um analista de sistemas, além de saber construir modelos, deve ser conhecedor ou 
aprofundar-se no que está a modelar, seja um sistema de matrícula, vendas, controlo de 
stock, bancário, etc. Durante a modelação o analista muitas vezes torna-se um especialista 
na área. 
 4
2. A natureza dos Sistemas 
Muitos dos sistemas baseados em computador são substituições ou implementacções de 
sistemas não-computadorizados. 
Um sistema computadorizado normalmente faz parte de um sistema maior 
(computadorizado ou não) e interage com outros sistemas. 
Existem princípios, filosofias e teorias que se aplicam a todos os tipos de sistemas. Um 
bom exemplo, é a lei da especialização de organismos (Biologia). Quanto mais bem 
adaptados às condições de um ambiente, mais difícil será a adaptação a outro ambiente. 
Esta lei também vale para sistemas computadorizados. 
2.1. Conceitos básicos 
Sistema: 
• Um grupo de itens que interagem entre si ou que sejam interdependentes, formando um 
todo unificado, orientado para atender objectivos específicos. 
• Um conjunto organizado de doutrinas, ideias ou princípios, habitualmente previstos 
para explicar a organização ou o funcionamento de um conjunto sistemático. 
Exemplos: 
• Sistema gravitacional 
• Sistema digestivo 
• Sistema rodoviário 
• Sistema bancário 
2.2. Tipos de Sistemas 
• Sistemas Naturais 
• Sistemas Físicos 
• Sistemas estelares: galáxias, sistemas solares, etc. 
• Sistemas geológicos: rios, cadeias de montanhas, etc. 
• Sistemas moleculares: organizações complexas de átomos. 
• Sistemas Vivos 
 5
• Animais 
• Vegetais 
• Espécie humana 
• Sistemas feitos pelo Homem 
• Sistemas sociais: organizações de leis, doutrinas, costumes, etc. 
• Sistemas de transporte: redes rodoviárias, canais, linhas aéreas, petroleiros, etc. 
• Sistemas de comunicações: telefone, sinais de fumaça, etc. 
• Sistemas financeiros: contabilidade, inventários, controlo de stocks, entre outros. 
2.3. Sistemas feitos pelo Homem 
O analista de sistemas deve modelar o comportamento básico para depois seleccionar o que 
deve ser executado pelo computador. Para isso, ele leva em conta variáveis como: 
• Custo 
• Conforto 
• Segurança 
• Manutenibilidade 
• Política 
2.4. Sistemas de Informação 
Um sistema de informação é um conjunto de elementos inter-relacionados, processos, 
dados e tecnologia, cuja finalidade é alimentar os centros de decisão com as informações 
necessárias à escolha de directrizes de acção que permitam o atingimento dos objectivos da 
organização. 
Dados: 
São sequências ordenadas de símbolos dos quais se pode extrair informação. Porém, não 
contêm nenhum significado quando analisados isoladamente. 
Informação: 
São dados tratados, analisados ou processados, capazes de transmitir algum conhecimento 
ao receptor. 
 6
Componentes de um Sistema de informação: 
• Hardware 
• Software 
• Pessoas 
• Dados 
• Procedimentos 
2.5. Classificação quanto à forma de processamento 
Sistemas Batch 
O utilizador normalmente não interage com o computador por terminal e as informações 
são processadas em lotes, de forma sequencial. 
Sistemas On-Line 
O utilizador interage com o computador por terminal, os dados de entrada são fornecidos 
directamente do local onde eles foram criados e os resultados do processamento são 
dirigidos directamente para onde sejam necessários. 
Sistemas em Tempo Real 
Controla um ambiente pelo recebimento de dados, seu processamento e apresentação dos 
resultados com rapidez suficiente para afectar o ambiente naquele momento. 
Sistemas Baseados em Conhecimento 
Estes sistemas estão associados ao campo da inteligência artificial. Contêm grande 
quantidade de conhecimentos variados para utilização em determinadas tarefas. 
Sistemas Especialistas 
São uma espécie de sistemas baseados em conhecimento. Têm embutidos o conhecimento e 
a capacidade que os tornam capazes de funcionar como um especialista. 
 7
2.6. Classificação quanto ao nível organizacional 
 
 
Sistemas de Processamento de Transacções 
• Nível operacional 
• Apoia operações rotineiras da empresa 
• Regista transacções 
• Origem dos dados: operações internas 
• Grau de agregação dos dados: dados analíticos, reais e precisos 
• Volumes manipulados: grandes 
• Saídas: relatórios analíticos, alguns sintéticos 
• Frequência: periódica 
• Exemplos: facturação, stock, contabilidade, etc. 
 8
Sistemas de Planeamento e Controlo Operacional 
• Nível táctico (supervisão) 
• Apoia o planeamento e controlo operacional 
• Colecta informações sobre o realizado e compara com o previsto 
• Origem dos dados: operações internas 
• Grau de agregação dos dados: médio 
• Volumes manipulados: médios 
• Saídas: relatórios consolidados 
• Frequência: periódica 
• Exemplos: custos, planeamento e controlo de produção, planeamento e controlo de 
projectos 
Sistemas de Apoio à Decisão 
• Nível táctico (média gestão) 
• Apoia processos decisórios 
• Trabalha com análise matemática e estatística dos dados 
• Origem dos dados: operações internas e fontes externas 
• Grau de agregação dos dados: alto 
• Volumes manipulados: pequenos 
• Saídas: gráficos e tabelas 
• Frequência: a pedido (ad hoc) 
• Exemplos: análise deinvestimentos, análise estatística, simulação de cenários. 
 9
Sistemas de Planeamento Estratégico 
• Nível estratégico (alta gestão) 
• Apoia a análise de factores críticos de sucesso da empresa: desempenho, mercado e 
concorrência 
• Trabalha com projecções a longo prazo e tendências do mercado 
• Origem dos dados: operações internas e, sobretudo, fontes externas 
• Grau de agregação dos dados: alto 
• Volumes manipulados: pequenos 
• Saídas: gráficos e tabelas sofisticados 
• Frequência: a pedido (ad hoc) 
• Exemplo: sistemas de informação executiva 
2.7. Princípios Gerais dos Sistemas 
• Quanto mais especializado é um sistema, menos capaz é de se adaptar a circunstâncias 
diferentes. 
• Quanto maior for um sistema, maior é o número dos seus recursos que serão destinados 
à manutenção diária. 
• Os sistemas fazem sempre parte de sistemas maiores e podem sempre ser divididos em 
sistemas menores. 
• Os sistemas crescem. 
 10
3. Participantes no Desenvolvimento de Sistemas 
Cada projecto possui um elenco diferente de pessoas envolvidas. Um analista de sistemas 
precisa ter aptidões interpessoais (além do conhecimento da tecnologia e, 
preferencialmente, também do negócio), ou seja, deve falar com outras pessoas usando uma 
“linguagem” diferente. 
3.1. Utilizadores 
É a pessoa ou grupo de pessoas para quem o sistema é construído. Para que o 
desenvolvimento do sistema seja bem sucedido, é necessário que o analista estabeleça um 
contacto directo com o utilizador. 
O analista de sistemas deve fazer reuniões regulares com os utilizadores (também 
chamados de clientes ou proprietários). O ideal seria ter utilizadores dedicados 
integralmente ao projecto. Alguns defendem que os próprios utilizadores deveriam fazer o 
projecto. 
Classificação por Tipo de Função 
• Operativos 
• Têm visão local, isto é, não conhecem o processo de forma global 
• Responsáveis por executar as funções do sistema 
• Têm uma visão física do sistema, ou seja, imaginam o funcionamento do sistema 
considerando a tecnologia de implementação 
• Supervisores 
• Podem ou não ter uma visão local 
• Geralmente conhecem as operações pois muitos já foram Utilizadores Operativos. 
Além disso, têm que supervisionar os Utilizadores Operativos 
• Orientado por considerações orçamentais (reduzir o quadro de funcionários ou 
aproveitá-los melhor) 
• Normalmente agem como intermediários em relação aos níveis mais elevados 
• Executivos 
• Não têm experiência operativa 
• Têm a iniciativa do projecto 
 11
• Possuem uma visão global 
• Têm preocupações estratégicas 
• Capazes de lidar com modelos abstractos 
Classificação por Nível de Experiência 
• Amador 
• Nunca trabalhou com um computador 
• Tem dificuldade para entender os modelos produzidos pelos analistas 
• Receia ser substituído pelo sistema ou ter sua importância minimizada 
• Novato arrogante 
• Participou de alguns projectos 
• Possui ou trabalha com computadores 
• Por conhecer algumas ferramentas, gosta de opinar sobre as tecnologias a serem 
usadas para implementar o sistema 
• Experiente 
• Conhecem a análise de sistemas 
• Têm experiência de outros projectos 
• Discutem sobre as técnicas de modelação sendo utilizadas 
3.2. Gestor de Projecto 
As principais funções de um gestor de projecto são: 
• Gerir e alocar recursos de toda a equipa técnica 
• Prestar contas junto da administração superior 
• Encaminhar problemas identificados no decorrer do projecto 
3.3. Auditores, Controlo de Qualidade e Normalização 
Responsáveis por garantir que o sistema seja desenvolvido de acordo com os vários padrões 
internos e externos da organização, especialmente aqueles focados na segurança e no 
controlo de qualidade do produto final. 
 12
Alguns problemas que devem ser considerados: 
• Normalmente não se envolvem no projecto até que ele tenha sido concluído. Neste 
ponto, modificar o sistema é muito mais difícil 
• Às vezes não estão habituados à notação utilizada 
• Geralmente, estão mais interessados na forma do que na substância 
3.4. Analista de Sistemas 
O analista desempenha as seguintes funções: 
• Arqueólogo e escriba: deve trazer à luz os detalhes e documentar as actividades cujos 
detalhes passam de geração em geração de utilizadores. 
• Inovador: não se limitar apenas a implementar as funções actuais do sistema mas 
ajudar a encontrar produtos e mercados novos. 
• Mediador: como os utilizadores dificilmente chegam a um consenso, o analista deve 
usar a arte da diplomacia e da negociação. O sistema deve ser feito da forma como os 
utilizadores solicitaram. 
• Líder de projecto: Como o analista entrou antes no projecto, frequentemente também 
é o projectista e normalmente é uma pessoa mais experiente, existe uma tendência 
natural de que ele assuma o papel de gestor de projecto. 
Um analista deve ter: 
• Habilidade com pessoas 
• Conhecimento de aplicações (ajuda a compreender a empresa do utilizador) 
• Habilidade em tecnologia 
• Mente lógica e organizada (visualizar o sistema sob diferentes perspectivas) 
3.5. Projectista de Sistemas 
Tem a função de transformar os requisitos dos utilizadores, modelados pelos analistas de 
sistemas, num projecto implementável em computador. 
Normalmente o analista e o projectista são a mesma pessoa, ou membros do mesmo grupo 
de pessoas. 
O analista de sistemas deve fornecer informações suficientemente detalhadas para que o 
projectista elabore um projecto tecnologicamente bom. 
 13
O projectista deve fornecer informações suficientes para que o analista possa dizer se os 
requisitos dos utilizadores podem ser completamente atendidos ou devem ser modificados. 
3.6. Programador 
Responsável por codificar e testar (usando uma linguagem de programação) os módulos do 
sistemas modelados pelos projectistas. 
Num cenário ideal, o programador não deveria ter contacto com o analista já que se baseia 
apenas no trabalho feito pelo projectista. 
Há programadores que são responsáveis apenas por dar manutenção em um sistema. 
Segundo Nicholas Zvegintzov: 
Até ao presente momento, o principal profissional da computacção era alguém que 
podia aprender o suficiente sobre as necessidades das empresas para expressá-las na 
linguagem dos computadores. No futuro, quando a nossa sociedade se tornar 
irreversivelmente computadorizada, o principal profissional será alguém que possa 
aprender o suficiente sobre sistemas computadorizados para expressá-los em 
linguagem humana. Sem essa pessoa, teremos perdido o controlo da nossa sociedade. 
Esse alguém é o engenheiro às avessas. Os mantenedores de software são os 
engenheiros às avessas da sociedade. 
3.7. Operador 
Pessoa encarregada de operar os computadores, da rede, da segurança do hardware e das 
bases de dados, da execução dos programas e da saída das impressoras. 
 14
4. Principais Problemas no Desenvolvimento de Sistemas 
Para desenvolver sistemas úteis, de alta qualidade e que realmente satisfaçam as 
necessidades dos utilizadores, é necessário considerar os seguintes aspectos: 
• Produtividade; 
• Confiabilidade; 
• Manutenibilidade. 
4.1. Produtividade 
Os dois aspectos mais importantes deste problema são: 
• A demanda reprimida (backlog) por novos sistemas 
• O tempo necessário para construir um novo sistema 
Demanda reprimida 
O backlog dos sistemas pode ser dividido em três categorias: 
Visível: 
• Solicitados oficialmente pelos utilizadores e que foram aceites e tiveram suas verbas 
aproveitadas pela gestão. 
• Ainda não foram iniciados por falta de recursos humanos (analistas, programadores, 
etc.) 
Invisível: 
• Sistemas que os utilizadores sabem que precisam, mas não se dão ao trabalho de 
solicitar oficialmente porque ainda estão a aguardar outros projectos 
Desconhecido: 
• Sistemasque os utilizadores ainda não sabem que precisam mas que emergirão logo 
que sejam concluídos outros sistemas dos backlogs visível e invisível. 
Num estudo realizado em 1982, descobriu-se que a demanda do backlog invisível era 5,35 
vezes maior que o visível. 
Tempo de desenvolvimento 
Há uma preocupação não apenas com o backlog global mas com a perda de oportunidades 
de negócios devido à incapacidade de desenvolver os sistemas de apoio necessários. 
 15
Muitos projectos nem são terminados. Dentre os principais motivos, pode-se citar: 
• Problemas técnicos 
• Problemas de gestão 
• Inexperiência da equipa 
• Falta de tempo para análise e projecto 
• Escasso envolvimento por parte da gestão ou utilizadores 
O tempo necessário para criar um sistema pode ser reduzido através de algumas técnicas: 
• Contratação de mais programadores e analistas de sistemas 
• Contratação de programadores e analistas de sistemas mais talentosos, oferecendo-lhes 
melhores condições de trabalho 
• Deixar que os utilizadores desenvolvam seus próprios sistemas 
• Melhores linguagens de programação 
• Atacar o problema da manutenção 
• Controlos de Engenharia de Software 
• Ferramentas automatizadas de desenvolvimento (CASE) 
Razões para os analistas terem consciência dos problemas de produtividade: 
• A produtividade e a qualidade do trabalho dos programadores está directamente ligada 
ao serviço feito pelo analista 
• Algumas das técnicas de aumento de produtividade têm importância directa para os 
analistas 
• A produtividade da análise é um problema politicamente sensível 
• Utilizadores e gestor têm ansiedade pelo início da programação 
• Utilizadores não entendem a importância da especificação 
 16
4.2. Confiabilidade 
Os erros em sistemas podem passar despercebidos (uma impressão de um número não 
formatada correctamente) ou causar graves acidentes (problema em sistema de tráfego 
aéreo). 
Os erros em software são difíceis de serem extintos porque: 
• É difícil descobrir como solucionar o erro 
• Deve-se encontrar todos os pontos de correcção 
• Alta probabilidade de introduzir novos erros (efeitos colaterais) 
• Nem sempre são reportados pelos utilizadores 
• Dificuldade de reproduzir o erro 
A figura abaixo mostra o número de erros encontrados em função do tempo decorrido. 
 
Figura 1 – Erros descobertos em função do tempo 
Sobre a curva acima é importante notar: 
• Inicialmente o nº de erros encontrados é pequeno (utilizadores sem segurança para 
apontar erros), como indica T1. 
• À medida que os utilizadores se familiarizam com sistema os erros são percebidos e 
reportados (entre T1 e T2). 
• Após um tempo (após T2) o nº de erros encontrados começa a diminuir (sistema 
começa a tornar-se mais estável). 
 17
• O número de erros volta a crescer devido a correcções ou modificações que introduzem 
novos erros (após T3). 
• A curva nunca atinge zero. 
4.3. Manutenibilidade 
A correcção de erros é apenas um dos aspectos da manutenção de sistemas. A manutenção 
também está vinculada a factores como: 
• Modificações no hardware 
• Novos dispositivos 
• Necessidade de melhorar o desempenho 
• Garantir maior confiabilidade 
• Alterações dos requisitos 
A manutenção de um sistema deve ser sempre acompanhada de modificações na 
especificação do sistema. Entretanto, isso nem sempre ocorre devido a factores como: 
• Analista alocado a outro projecto 
• Urgência na implantação das modificações 
• Inexistência de uma política que valorize a manutenção da especificação 
4.4. Qualidade 
A qualidade de um sistema pode ser mensurada considerando a eficácia e a eficiência 
obtidas: 
Eficácia = Resultados Obtidos / Resultados Pretendidos 
Eficiência = Resultados Obtidos / Recurso Consumido 
Problemas que denotam falta de qualidade em sistemas: 
• Não contribuem para os objectivos da empresa; 
• Não atendem às necessidades dos utilizadores; 
• Não são confiáveis; 
• São ineficientes; 
 18
• Têm manutenção constante, difícil e onerosa. 
4.5. Portabilidade 
Consiste em escrever sistemas que podem ser transferidos para outras plataformas. 
Apesar de não ser um problema da alçada do analista, ele deve especificar que há essa 
necessidade. 
A portabilidade geralmente provoca ineficiência já que recursos disponíveis de determinada 
plataforma não são aproveitados. 
4.6. Segurança 
À medida que os sistemas de informação crescem em número e importância, o risco de 
violações aumenta. 
A segurança de sistemas de informação consiste basicamente em: 
• Impedir o acesso de pessoas não autorizadas; 
• Conceder acesso a certas funcionalidades apenas a algumas pessoas. 
4.7. Principais causas 
• Ausência de Planeamento de Sistemas; 
• Ausência de Administração de Dados; 
• Não utilização de Métodos e Técnicas Formais de Desenvolvimento; 
• Não utilização de Técnicas e Ferramentas; 
• Adopção de Metodologias não ambientadas à realidade da empresa; 
• Falta de definição precisa dos objectivos e requisitos do sistema; 
• Dificuldade de comunicação e/ou falta de entrosamento entre as pessoas envolvidas no 
processo; 
• Dificuldade de comunicação entre Utilizadores e Desenvolvedores (linguagem); 
• Rivalidade entre utilizadores; 
• Falta de precisão e clareza na especificação dos sistemas. 
 19
5. Ciclo de Vida do Projecto de Desenvolvimento 
Um ciclo de vida de projecto bem definido oferece mecanismos para planejar e acompanhar 
actividades de forma mais precisa, possibilitando a detecção de problemas de forma mais 
rápida. 
5.1. Conceito de Ciclo de Vida de um Projecto 
Nas pequenas organizações os projectos são caracterizados por: 
• Serem iniciados após um entendimento verbal entre os utilizadores e a equipa de 
projecto; 
• O trabalho de desenvolvimento é feito sem muito estardalhaço. 
Já nas grandes organizações os projectos têm as seguintes características: 
• Tudo é feito de maneira mais formal; 
• As comunicações entre os utilizadores, a gestão e a equipa de projecto são 
documentadas; 
• Todos estão cientes da existência de várias fases; 
• Normalmente o gestor é responsável por definir as fases e as actividades do projecto. 
Algumas organizações (pequenas ou grandes) definem para todos os projectos um único 
ciclo de vida, também conhecido como plano de projecto ou metodologia de 
desenvolvimento de sistemas. 
Outras organizações adoptam um ciclo de vida existente (criado por outra organização) e 
adaptam às suas necessidades. 
5.2. Objectivos 
• Definir as actividades a serem executadas num projecto de desenvolvimento de 
sistemas. 
• Facilita a adaptação de pessoas novas; 
• Participantes têm uma visão do que estão a fazer no projecto e qual a importância. 
• Manter consistência entre projectos de uma mesma organização. 
• Facilita a supervisão do projecto pelos níveis mais altos de gestão 
• Introduz pontos de verificação para o controlo de gestão de decisões 
 20
• Permite identificar se o projecto está atrasado e como corrigir o problema 
5.3. Ciclo de Vida Clássico 
O ciclo de vida de um projecto clássico ou convencional é mostrado na figura abaixo: 
 
Pontos de divergência que normalmente existem nas organizações mas que não 
descaracterizam o ciclo de vida clássico: 
• Levantamento e Análise são fundidas (tudo que o utilizador solicita é considerado 
viável); 
• Pode não haver o Estudo de Hardware se o sistema não deve causar sérios impactos e 
há disponibilidade; 
 21
• Projecto preliminar e Projecto detalhado são reunidos numa única fase (Projecto); 
• As fases de teste podem ser reunidas e até feitas junto com a codificação. 
As duas características (e fraquezas) que definem um ciclo de vida clássico são: 
• Implementação Bottom-Up 
• Nada está terminado até que esteja totalmente pronto 
• Os erros triviaissão encontrados no início do período de teste e os erros mais sérios 
são encontrados no final. 
• A depuração tende a ser extremamente difícil durante os estádios finais dos testes 
do sistema; 
• A necessidade de tempo para testes normalmente aumenta exponencialmente 
durante os estádios finais do projecto. 
• Progressão Sequencial 
• As fases são seguidas de forma sequencial; 
• As especificações produzidas em cada fase são "congeladas"; 
• Apesar de ser uma tendência humana (terminar uma fase para começar a seguinte), 
não representa a realidade dos projectos por várias razões: 
• Os requisitos mudam; 
• Erros são encontrados na especificação e devem ser corrigidos. 
 22
5.4. Ciclo de Vida Semi-Estruturado 
 
O ciclo de vida semi-estruturado (mostrado na figura acima) tem as seguintes 
características: 
• Implementação Top-Down é usada no lugar da Botton-Up 
• O utilizador pode testar o sistema antes que esteja todo pronto 
• Utilização do projecto estruturado no lugar do clássico (como mostra a figura abaixo). 
Projectistas precisam transformar um documento narrativo (monolítico, ambíguo e 
redundante) em um modelo contendo: 
• Diagramas de Fluxo de Dados 
• Dicionário de Dados 
• Diagramas de Entidades-Relacionamentos 
• Especificações de Processos. 
 23
 
5.5. Ciclo de Vida Estruturado 
A seguir encontram-se as descrições das 9 (nove) actividades do Ciclo de Vida Estruturado: 
Levantamento 
• Também conhecida como estudo de viabilidade ou estudo inicial das actividades. 
• Normalmente é iniciado quando o utilizador solicita que algo seja automatizado. 
• É uma importante peça na tomada de decisão e no planeamento do sistema. 
• Principais objectivos: 
• Identificar os utilizadores responsáveis e desenvolver um "escopo" inicial do 
sistema: 
• Diagrama de Contexto 
• Diagrama(s) de Fluxo de Dados 
 24
• Identificar as actuais deficiências no ambiente do utilizador. 
• Estabelecer metas e objectivos para um novo sistema 
• Determinar se é possível automatizar o sistema e se assim for, sugerir alguns esquemas 
aceitáveis (custo, benefício e cronograma). 
• Preparar uma previsão do projecto que será usada para conduzir o restante do projecto 
Análise 
• Gerar uma especificação estruturada do projecto do sistema a partir do critério do 
utilizador e da previsão do projecto. 
• Isso envolve a modelação do ambiente do utilizador usando as seguintes técnicas: 
• Diagramas de Fluxo de Dados (DFD). 
• Diagramas de Entidades-Relacionamentos(DER). 
• Diagramas de Transições de Estado. 
• Envolve o desenvolvimento de um modelo ambiental e um comportamental. 
Projecto 
• Alocação de partes da especificação (modelo essencial) aos processadores apropriados 
(pessoas ou máquinas). 
• Desenvolvimento de uma hierarquia de módulos de programas e interfaces entre esses 
módulos. 
• Transformação do modelo de dados num projecto de bases de dados (dependente da 
tecnologia adoptada). 
• Deve ser desenvolvido o modelo de implementação do utilizador (fronteira homem-
máquina e interface homem-máquina). 
Implementação 
• Codificação e integração dos módulos. 
• Programação Estruturada e Implementação Top-Down. 
• O sistema vai ficando completo progressivamente. 
 25
Geração de Testes de Aceitação 
• Criar os testes de aceitação a partir da especificação estruturada. 
• Pode ser feita paralelamente ao projecto e à implementação. 
Controlo de Qualidade 
• Também chamada de teste final ou teste de aceitação. 
• Exige como entrada os testes de aceitação e um sistema integrado. 
Descrição dos Procedimentos 
• Descrição formal das partes manuais do novo sistema. 
• Descrição de como será a interacção com o utilizador (parte automatizada). 
Conversão das Bases de Dados 
• Desenvolver programas para converter os dados existentes para a nova base de dados. 
Instalação 
• Passagem imediata versus gradual. 
• Formação dos utilizadores. 
5.6. Abordagem Radical versus Conservadora 
• Abordagem Radical do ciclo de vida: 
• As actividades do projecto são executadas em paralelo (a codificação começa no 
primeiro dia). 
• Abordagem Conservadora do ciclo de vida: 
• Uma actvidade só é iniciada quando a anterior foi concluída. 
• Ambas as abordagens são perigosas pois são os extremos. 
• Podem ser adoptadas abordagens intermediárias: 
• Iniciar uma fase quando 75% ou 50% da anterior estiver concluída. 
• Executar duas actividades em paralelo (levantamento e análise). 
 26
• Para cada projecto, uma abordagem diferente pode ser usada, baseada nos seguintes 
factores: 
• Quão inconstantes são os utilizadores? 
• Utilizadores inconstantes ou inexperientes requerem uma abordagem mais 
radical. 
• Utilizadores veteranos adequam-se mais a uma abordagem mais conservadora. 
• Pressão para produzir resultados imediatos e palpáveis. 
• Pressão sobre o gestor do projecto para produzir um cronograma, um orçamento e 
uma avaliação de pessoas e outros recursos: 
• Mais radical (precoces) => maior erro. 
• Mais conservadora => menor erro. 
• Perigo em cometer um erro técnico (implementação inviável). 
5.7. Ciclo de Vida da Prototipagem 
• Na prototipagem cada necessidade levantada é simulada no protótipo, que é expandido 
e refinado gradualmente. 
• Também conhecido como desenvolvimento heurístico. 
• É uma alternativa atraente para lidar com a incerteza, a ambiguidade e a inconstância 
dos projectos. 
• No final da modelação o protótipo será desprezado e substituído por um programa real 
pois ele é apenas um modelo. 
• Os prototipadores normalmente utilizam os seguintes tipos de ferramentas: 
• Dicionário de dados integrado. 
• Gerador de ecrãs. 
• Gerador de relatórios não-procedural. 
• Linguagem de programação de quarta geração. 
• Linguagem de consultas não-procedural. 
• Recursos poderosos de gestão de bases de dados. 
 27
• Projectos que são bons candidatos para a abordagem de prototipagem têm as seguintes 
características: 
• O utilizador é incapaz ou não deseja examinar modelos abstractos de papel como 
DFD's. 
• O utilizador é incapaz de exprimir os seus requisitos, podendo identificá-los através 
de tentativas e erros ("Eu não sei o que quero, mas eu saberei, se o vir"). 
• O sistema está previsto para ser on-line (a maioria das ferramentas de apoio são 
orientadas para a abordagem on-line). 
• Não exige a especificação de grandes quantidades de detalhamento algorítmico. 
• O utilizador está mais interessado no formato e na diagramacção da entrada e da 
saída. 
• A abordagem da prototipagem pode ser combinada com a análise estruturada como uma 
forma de auxiliar a descoberta/especificação dos requisitos. 
• A abordagem Top-Down pode funcionar como uma forma de prototipagem, na qual 
cada versão contém mais funcionalidades e está mais próxima do desejo do utilizador. 
• O risco em adoptar o protótipo como um sistema de produção é grande e pode ser 
desastroso porque: 
• Não foi preparado para manipular eficientemente grandes volumes de transacções. 
• Carece de detalhes operativos como: 
• Recuperação de erros. 
• Auditoria. 
• Backup/Recuperação. 
• Documentação do utilizador. 
• Procedimento de conversão. 
• O projecto pode terminar (quando o protótipo for substituído pelo sistema) sem que 
tenha sido produzida qualquer documentação formal, que deveria ser mantida ao 
longo da vida do sistema. 
 28
6. Modificações na Análise de Sistemas 
• É necessário estar ciente das técnicas actuais e das modificações ocorridas com o passar 
do tempo. 
• Há basicamente três motivos para conhecer a evolução da análise de sistemas: 
• Ajuda a perceber a evolução de uma empresa 
• Mudar de emprego 
• Sugerir a evolução 
• Ocupar cargos de liderança para alavancar as mudanças 
• É importante conhecer a abordagem anteriormenteadoptada pela organização e se 
há algum tipo de transição em andamento 
• A noção de transição é importante pois a análise de sistemas é dinâmica: 
• Novas técnicas 
• Modificações em ciclos de vida 
6.1. A passagem para a Análise Estruturada 
• Até o final da década de 70, os requisitos dos utilizadores eram documentados através 
de uma narrativa no idioma adequado. 
• Os primeiros autores sobre Análise Estruturada mostraram que esta forma de 
especificação padecia de grandes problemas. 
• Monolíticos: Era necessário ler todo o documento para entender. Isso dificultava a 
compreensão se fosse necessário estudar apenas uma parte. 
• Redundantes: A dificuldade de actualizar e rever o documento conduz à 
inconsistência. 
• Ambíguos: utilizadores, analistas, projectistas e programadores têm interpretações 
diferentes do documento. 
• Manutenção impossível: A especificação estava obsoleta antes mesmo do final do 
projecto. 
• Como consequência, não se tem ideia do que muitos sistemas desenvolvidos nas 
décadas de 60 e 70 fazem porque os analistas e programadores que os desenvolveram 
não estão mais presentes. 
 29
• Apesar das técnicas de Programação Estruturada e Projecto Estruturado terem sido 
adoptadas, era necessário que houvesse uma evolução na forma de especificar os 
Requisitos do Utilizador. 
• "Poderia chegar-se a um desastre com mais rapidez do que nunca". 
• A especificação dos requisitos deveria ser: 
• Gráfica 
• Particionada 
• Sem redundância 
6.2. Modificações na Análise Estruturada 
• Alguns anos de experiência prática indicaram que eram necessárias algumas alterações, 
cujas principais são: 
• Evitar a construção de modelos "físicos" e "lógicos" do sistema actual. 
• Politicamente perigosa (muito tempo gasto com algo que vai ser descontinuado) 
• A distinção vaga entre os modelos lógico e físico (dependente da tecnologia) 
• Modelo lógico => Modelo essencial (essência do sistema) 
• Modelo físico => Modelo de implementação (considera aspectos tecnológicos) 
• Carência de técnicas de modelação para construir sistemas de tempo-real 
• Introdução dos Diagramas de Transição de Estado (DTE) 
• Necessidade de modelar as estruturas de dados do sistemas 
• Introdução dos Diagramas de Entidades-Relacionamentos 
• Melhor integração entre as técnicas (DFD, DER, DTE e DD) 
• Utilização da subdivisão (particionamento) por eventos no lugar do Diagrama de 
Contexto 
 30
6.3. Surgimento das Ferramentas Automatizadas de Análise 
• Trabalho artístico de criar os diagramas 
• O grande problema é fazer a manutenção dos diagramas 
• Muitas modificações durante a análise 
• Grande quantidade de diagramas 
• Dificultou a aceitação da Análise Estruturada Trabalho artístico de criar os diagramas 
• Analista preferia deixar o diagrama desactualizado 
• Analista não subdividia o modelo do sistema em modelos de nível mais baixo 
• Os Projectistas e Programadores não mantinham os diagramas actualizados durante 
a implementação 
• Não havia verificação automática de consistência nos diagramas (era necessário fazer 
inspecções visuais) 
• Custo elevado das ferramentas e dos terminais gráficos 
6.4. Uso da Prototipagem 
• Surgimento de ferramentas de Prototipagem 
• A Análise Estruturada levava muito tempo: 
• Modelação do sistema novo só começa após a do sistema actual 
• Como os Diagramas não geravam código, suspeitava-se que o tempo gasto na 
implementação seria igual 
• Os primeiros projectos levavam mais tempo pois os Analistas não estavam 
acostumados com as técnicas 
• muita da programação seria o mesmo se não fosse feita análise 
• A prototipagem concentra-se na definição da interface homem-máquina 
• Evita os detalhes que são capturados através da Análise e do Projecto 
 31
7. Diagrama de Fluxo de Dados 
• Principal técnica de modelação funcional 
• Modela o sistema como uma rede de processos funcionais, interligados por dutos e 
tanques de armazenamento 
• Pode ser usado para descrever processos computadorizados e não computadorizados 
• Também chamado de DFD (abreviatura), Diagrama de Bolhas, Modelo de Processo, 
Diagrama de Fluxo de Trabalho e Modelo Funcional 
• Um DFD é composto de Processos, Fluxos de Dados, Depósitos de Dados e Entidades 
Externas 
7.1. Componentes de um DFD 
Processos 
• Também conhecido como bolha, função ou transformação 
• Representam transformações de fluxo(s) de dados de entrada em fluxo(s) de dados 
de saída 
• O nome do processo deve descrever o que ele faz 
• Geralmente provoca mudanças de estrutura, conteúdo ou estado 
• Representações gráficas possíveis: 
 
Fluxos de Dados 
• Representam caminhos por onde passam os dados 
• São representados através de setas que indicam o destino do dado 
• Têm nomes que devem constar no dicionário de dados 
• Um mesmo fragmento de dados pode ter significados diferentes em pontos distintos 
de um DFD (CPF-Válido e CPF-Inválido) 
• Um fluxo apenas não modifica os dados durante o transporte 
 32
• Transportam dados entre os elementos do DFD 
• Processo ⇔ Processo 
• Entidade Externa ⇔ Processo 
• Depósito de Dados ⇔ Processo 
• Tipos de fluxos 
• Fluxo externo: entre Entidade Externa e Processo 
• Fluxo interno: entre dois Processos 
• Fluxo de acesso à memória: entre Processo e Depósito 
• Fluxo de erro ou rejeição: para fora de um Processo 
• Nomenclatura: 
• Cada fluxo deve ter um único nome 
• O nome deve identificar os dados transportados pelo fluxo 
• Exemplos: Dados-Factura, Recibo-Pagamento, Dados-Cliente 
Depósitos de Dados 
• Representa uma colecção de pacotes de dados em repouso 
• Nem sempre um depósito de dados é um arquivo ou SGBD. Pode representar 
microfilmes, pastas de arquivos em papel e diversas outras formas não 
computadorizadas 
• Representações gráficas de um depósito de dados: 
 
• Quando um pacote de dados é recuperado (ou inserido) por completo do depósito de 
dados, pode-se omitir o rótulo do fluxo 
• Nomenclatura: 
• Deve estar no plural 
• Pode receber o nome do fluxo de dados (no plural) 
 33
Entidades Externas 
• Também chamados de Terminadores 
• São as fontes/destinatários das informações que entram/saem do sistema 
• Os procedimentos executados pelas entidades externas não são especificados no 
modelo por não fazerem parte do sistema 
• Normalmente é uma pessoa, um grupo de pessoas, uma organização externa, um 
sector dentro de uma empresa 
• Pode representar um outro sistema 
• Representação gráfica de uma Entidade Externa: 
 
• Nomenclatura: 
• No plural quando se referir a um grupo de pessoas (Clientes) 
• Deve conter o nome do sector ou organização externa (Directoria de Negócios) 
• Deve ser incluída a palavra sistema quando se tratar de um sistema (Sistema de 
Contabilidade) 
 
 34
7.2. Directrizes para elaboração de DFD 
• Existem algumas directrizes que auxiliam a criar DFD's com sucesso, ou seja, evitam a 
criação de: 
• DFD's incorrectos (incompletos ou logicamente inconsistentes) 
• DFD's agradáveis (facilmente examinados pelo utilizador) 
Escolher Nomes Significativos 
• Evitar nomes para processos como: Fazer serviço, Manipular entrada, Cuidar dos 
clientes e Processar dados 
Devem-se numerar os Processos 
• A numeração tem basicamente duas utilidades: 
• Permitir localizar os processos no diagrama facilmente 
• Facilita a identificação, a partir dos diagramas mais detalhados, do processo que foi 
explodido 
• Não importa a maneira desde que seja consistente 
• A numeração não indica sequência pois o DFD é uma rede de processos assíncronos 
que se intercomunicam 
Evitar DFD Complexos 
• Evitar colocar elementos demais no digrama 
• Deve caber facilmente numa página 
• O DFD deve modelar correctamente as funções que um sistema deve executar e asinteracções entre elas. 
• Deve ser lido e entendido facilmente pelos utilizadores 
Refazer tantas vezes quantas forem necessárias 
• Um DFD deve ser refeito até que: 
• Esteja tecnicamente correcto 
• Aceitável pelo utilizador 
• O Analista não tenha vergonha de apresentá-lo à directoria. 
 35
Criar diagramas esteticamente agradáveis 
• Manter consistentes o tamanho e a forma das bolhas 
• Fluxo de dados cursos versus rectos (questão de gosto) 
• Diagramas desenhados à mão versus gerados por máquina 
• Os desenhados à mão passam a sensação de que ainda podem ser modificados 
• Os gerados por máquina são mais limpos 
Certificar-se de que o DFD seja logicamente consistente 
• Evitar "poços sem fundo" (processos que só recebem entradas) 
• Evitar processos com geração espontânea (processos que não recebem entrada mas 
produzem saídas) 
• Cuidado com fluxos e processos sem rótulos 
• Cuidado com depósitos que tenham somente leitura ou escrita 
Posição dos elementos 
• O processo origem deve ficar à esquerda ou acima do processo destino 
• As entidades externas devem ser desenhadas nas bordas do desenho: 
• As de entrada, à esquerda ou acima 
• As de saída, à direita ou abaixo 
• Os depósitos de dados devem ser distribuídos no meio do desenho, entre os processos 
Duplicação de elementos 
• Pode-se duplicar Entidades e Depósitos para evitar cruzamento de fluxos e melhorar a 
organização do diagrama 
• Um mesmo fluxo de dados pode aparecer mais de uma vez no mesmo DFD 
• Não faz sentido duplicar processos 
 36
7.3. DFD com Níveis 
• O DFD de sistemas não triviais é muito complexo 
• Para evitar que tudo seja definido num único diagrama (difícil de ser entendido e 
mantido), criam-se DFD's que detalham um processo de um nível mais alto 
Diagrama de Contexto 
• É o DFD de nível mais alto 
• Dá a visão das principais funções do sistema 
• Contém um processo (representa o sistema), os fluxos externos e as entidades externas 
 
Diagrama Nível 0 
• É o primeiro detalhamento do diagrama de contexto 
• Contém as macro-funções do sistema 
 37
 
Diagrama de Níveis Intermédios 
• São os diagramas que mostram a decomposição (detalhamento ou explosão) de cada 
processo de nível mais alto 
• A quantidade de níveis depende de factores como complexidade e porte do sistema 
• Em geral, a decomposição deve terminar quando for possível especificar o processo 
numa página 
 
 
 38
8. Dicionário de Dados 
• É necessário descrever a composição dos dados de alguma forma. 
• A forma narrativa é longa e sujeita a erros 
• É necessário usar uma notação compacta e concisa 
• Elementos de dados são dados que não necessitam de decomposição 
• Estrutura de dados são composições de elementos de dados e/ou de outras estruturas 
de dados 
• A definição no DD é feita de forma Top Down 
• O dicionário de dados define os elementos de dados descrevendo: 
• O significado de fluxos e depósitos 
• A composição de pacotes agregados de dados que se movimentam pelos fluxos (Ex: 
Endereço pode ser divido em itens elementares como cidade, estado, etc.) 
• A composição dos pacotes de dados nos depósitos 
• Os valores e unidades relevantes de partes elementares de informações dos fluxos e 
depósitos 
• Os detalhes dos relacionamentos entre os depósitos realçados num DER 
8.1. Notação 
• Há vários esquemas de notação. Porém, o mais comum é o seguinte: 
= É composto de 
+ E (concatenação) 
( ) Opcional 
{ } Iteração 
[ ] Escolha de uma das opções alternativas 
* Delimitador de comentário 
@ Identificador (campo chave) de um depósito 
| Separa opções alternativas na construção [ ] 
 39
Exemplo: definição de um nome (estrutura de dados) 
nome = * Nome completo do cliente * 
título-cortesia + primeiro-nome + (nome-intermédio) + 
último-nome 
título-cortesia = [Sr.|Srta.|Sra.|Sras.|Dr.|Professor] 
primeiro-nome = {carácter-válido} 
nome-intermédio = {carácter-válido} 
último-nome = {carácter-válido} 
carácter-válido = [A-Z|a-z|0-9|'| ] 
8.2. Definições 
• Uma definição de um item de dados é apresentada com o símbolo "=", que deve ser lido 
como "é definido como", ou "é composto de", ou simplesmente "significa" 
• A notação A = B + C, significa A é composto de B e C 
• O significado do dado no contexto da aplicação deve ser colocado na forma de 
comentário 
8.3. Elementos opcionais 
• Um elemento de dados é opcional quando a sua presença no elemento de dados 
composto não é obrigatória 
Exemplo: um cliente deve ter um endereço e pode informar um endereço de remessa 
Cliente = Endereço + (Endereço-Remessa) 
8.4. Iteração 
• Usado para indicar a ocorrência repetida de um componente de um elemento de dados 
Exemplo 1: um pedido que é composto de um nome do cliente, um endereço de remessa e 
zero ou mais itens 
Pedido = Nome-do-Cliente + Endereço-Remessa + {Item} 
Exemplo 2: um pedido que é composto de um nome do cliente, um endereço de remessa e 
de 1 a 10 itens 
Pedido = Nome-do-Cliente + Endereço-Remessa + 1{Item}10 
Exemplo 3: um pedido que é composto de um nome do cliente, um endereço de remessa e 
pelo menos um item 
 40
Pedido = Nome-do-Cliente + Endereço-Remessa + 1{Item} 
Exemplo 4: um pedido que é composto de um nome do cliente, um endereço de remessa e 
no máximo 10 itens 
Pedido = Nome-do-Cliente + Endereço-Remessa + {Item}10 
8.5. Selecção 
• Indica que deve ser seleccionada uma das opções apresentadas 
Exemplo: definindo o estado civil 
Estado-Civil = [Solteiro | Casado | Divorciado | Separado | Outro] 
8.6. Sinónimo 
• É necessário quando os utilizadores usam termos diferentes para um mesmo dado 
Exemplo: 
Número-do-Item = 1{Dígito}5 
Número-da-Peça = * Sinónimo de Número do Item * 
Dígito = [0 | 1 | 2 | 3] 
8.7. Definição de Depósitos 
• A definição deve vir entre {} para indicar a existência de 0 a n ocorrências 
• Coloca-se o caractere @ antes do item de dado que identifica uma ocorrência 
(instância) do depósito 
Exemplo: definindo depósitos de Clientes e Funcionários 
Clientes = { @CPF-CNPJ + Nome + Data-cadastro + Endereço } 
Funcionários = { @Matrícula + Nome + Data-contratação + Endereço + 
 {@Telefone + Descrição} + {@RG-Dependente + Nome} } 
 
 41
9. Diagrama de Entidades-Relacionamentos 
• O DER serve para modelar os dados de um sistema 
• Um DER é interessante quando se deseja: 
• Especificar os dados que são necessários 
• Mostrar a quem pertencem os dados 
• Identificar os relacionamentos entre os dados 
• Diferença entre Administrador de Dados (AD) e Administrador de Bases de Dados 
(ABD) 
9.1. Entidades 
• Uma Entidade representa uma colecção de objectos ou eventos cujos membros 
individuais (exemplares ou instâncias) têm as seguintes características: 
• Cada um só pode ser identificado de uma única forma 
• Cada um exerce um papel fundamental no sistema de informação. 
• Cada um pode ser descrito por um ou mais elementos de dados 
• O nome da entidade deve estar no singular 
• Devem ser descritas no Dicionário de Dados 
• Exemplos: Cliente, Automóvel, Disciplina e Contratação de Funcionário 
9.2. Relacionamentos 
• Representam as associações entre entidades 
• Um relacionamento está sujeito à existência das entidades que associa 
• Devem ser descritas no Dicionário de Dados 
Tipos de Relacionamentos 
• Podem ser classificados em: Obrigatórios, Opcionais, Múltiplos e Unitários 
 42
 
Classificações adicionais 
• Entidades fracas ou dependentes: As entidades fracas dependem da existência de uma 
ocorrência da entidade principal. Exemplo: Cliente e Dependente 
• Subtipos e Supertipos: Os Subtipos possuem, além dos seus atributos específicos, os 
atributos de seu Supertipo. Exemplo: Cliente, Cliente Pessoa Física e Cliente Pessoa 
Jurídica. 
• EntidadesAssociativas: São fruto de relacionamentos M para N, ou 1 para N, com 
informações próprias. São identificados através das chaves das Entidades que relaciona. 
Exemplo: Produto - Venda - Cliente 
Cardinalidade 
• Representam o número de ocorrências de cada entidade associadas num relacionamento 
• Podem ser 1:1 (um para um), 1:N (um para N) e M:N (M para N) 
Casos especiais de relacionamentos 
• Relacionamentos entre várias Entidades 
• Auto-Relacionamento 
• Racionamento em paralelo 
 43
10. Diagrama de Transições de Estado 
• Modela o comportamento dependente do tempo 
• Empregado em sistemas de tempo real 
• Interagem com fontes de dados externas de alta velocidade 
• Devem produzir respostas e dados de saída rapidamente para interagir com 
ambiente externo 
• Exemplos: Sistemas de controlo de processos, Sistemas de controlo militares, 
Sistemas de navegação em automóveis, etc. 
10.1. Notação 
• Os principais componentes de um DTE são os rectângulos que representam os estados 
e as setas que representam as alterações de estado 
Estado 
• Um estado é uma situação em que o sistema se encontra e que pode durar por um 
determinado período de tempo 
• É representado por um rectângulo 
• Exemplos: A aguardar o próximo comando; A executar transacção; A esperar a 
digitação da senha; A acelerar o motor; etc. 
• Em geral os estados apresentam situações em que o sistema está aguardando pela 
ocorrência de um evento ou está fazendo algo 
Mudanças de Estado 
• São as transições de um estado para outro 
• Indicam, para cada estado, os seus possíveis estados subsequentes 
• Geralmente apontam os estados iniciais e finais 
• O estado inicial normalmente é desenhado na parte de cima do diagrama. É identificado 
através de uma seta que chega a ele sem partir de outro estado 
• Um estado final normalmente é desenhado na parte de baixo do diagrama e não possui 
setas que partem dele 
• Um DTE pode ter vários estados finais 
 44
Condições e Acções 
• Num DTE também é possível incluir as condições que causam uma mudança de estado 
e as acções que o sistema empreende quando muda de estado 
• São exibidas junto à seta que indica a mudança de estado (a condição acima e a acção 
abaixo, separadas por uma linha) 
• Exemplo de diagrama de transições de estados (browser web) 
 
 45
10.2. Diagramas subdivididos 
• Em sistemas complexos é difícil (ou até impossível) representar todos os estados num 
único DTE. 
• É permitido criar um DTE de alto nível e detalhar cada estado num outro DTE (mais 
detalhado) 
• No DTE mais detalhado há um estado inicial e um ou mais estados finais 
• Exemplo: 
 
 46
10.3. Construindo um DTE 
• Para construir um DTE pode-se utilizar as seguintes abordagens: 
• Abordagem 1: 
• Identificar todos os possíveis estados do sistema 
• Descobrir as transições significativas entre os estados 
• Abordagem 2: 
• Identificar o estado inicial 
• Descobrir quais são os estados seguintes e os caminhos possíveis 
• Repetir o passo anterior para cada um dos estados seguintes 
• Após elaborar o DTE, verifica-se a sua consistência através dos seguintes testes: 
• Todos os estados são atingíveis? 
• Todos os estados foram especificados? 
• Todos os estados não finais têm transição de saída? 
• Em cada estado, o sistema reage adequadamente a todas as condições possíveis? 
• As condições de excepção estão representadas? 
 47
11. Especificações de Processos 
• Tem como propósito definir o que deve ser feito para transformar as entradas de um 
processo em saídas. 
• Há várias formas de se especificar um processo, dentre as quais pode-se destacar: 
• Linguagem Estruturada 
• Condições Pré/Pós 
• Tabela de Decisão 
• Árvore de Decisão 
• Os principais problemas da linguagem natural são: 
• Ambiguidade (condições booleanas) 
• Riqueza de formas (mais de uma forma de definição) 
• Imprecisão de limites (não especificação de casos especiais) 
• Qualquer forma de especificar processos é válida desde que: 
• Seja expressa de uma forma que possa ser verificada pelo utilizador e pelo analista. 
• Possa ser efectivamente entendida por todos os envolvidos no projecto (utilizadores, 
gestores, auditores, etc.) 
• O analista deve conhecer as técnicas para que possa seleccionar a mais apropriada para 
cada situação 
11.1. Linguagem Estruturada 
• Subconjunto da linguagem normal com algumas restrições sobre as sentenças quanto: 
• Tipo de sentenças que podem ser utilizadas 
• Formas como podem ser utilizadas 
• Formas como podem ser reunidas 
• Equilíbrio entre a precisão de uma linguagem de programação formal e a informalidade 
e a legibilidade da língua normalmente utilizada 
 48
• O vocabulário da Linguagem Estruturada consiste em: 
• Verbos no imperativo: 
• RECEBER (fluxo) 
• ENVIAR (fluxo) 
• MOVIMENTAR (dados) 
• ACEDER (depósito de dados) 
• Palavras reservadas (estruturas de controlo) 
• Termos definidos no Dicionário de Dados 
• Termos locais 
• Numerais e valores booleanos 
• Estruturas de controlo 
• Sequência: uma ou mais sentenças executadas em sequência sem interrupção 
• Selecção: SE e FAÇA-CASO 
• Repetição: FAÇA-ENQUANTO e REPITA 
• Sintaxe e exemplo do comando de selecção SE 
SE <condição> 
 Sentença A 
SENÃO 
 Sentença B 
FIM-SE 
---------------------- 
SE idade-cliente < 18 
 categoria = 'Menor' 
SENÃO 
 categoria = 'Maior' 
FIM-SE 
 49
• Sintaxe e exemplo do comando de selecção FAÇA-CASO 
FAÇA-CASO 
 CASO <condição> 
 Sentença A 
 CASO <condição> 
 Sentença B 
 ... 
 CASO-CONTRÁRIO 
 Sentença X 
FIM-CASO 
-------------------------- 
FAÇA-CASO 
 CASO situacao = 1 
 risco = 'Pequeno' 
 CASO situacao = 2 
 risco = 'Moderado' 
 CASO situacao = 3 
 risco = 'Alto' 
 CASO-CONTRÁRIO 
 Risco = 'Indefinido' 
FIM-CASO 
• Sintaxe e exemplo do comando de repetição FAÇA-ENQUANTO 
FAÇA-ENQUANTO <condição> 
 Acção A 
FIM-ENQUANTO 
------------------------------------------- 
total = 0 
FAÇA-ENQUANTO há mais pedidos 
 LER próximo pedido de PEDIDOS 
 total = preço-unitário * quantidade-item 
FIM-ENQUANTO 
EXIBIR total 
 50
• Sintaxe e exemplo do comando de repetição REPITA 
REPITA 
 Acção A 
ATÉ-QUE <condição> 
------------------------------------------- 
total = 0 
REPITA 
 LER próximo pedido de PEDIDOS 
 total = preço-unitário * quantidade-item 
ATÉ-QUE não haja mais pedidos 
EXIBIR total 
• Algumas sugestões 
• Uma especificação de processo em linguagem estruturada deve caber numa folha de 
papel 
• Não usar mais de três níveis de aninhamento, principalmente em selecções 
• Evitar confusões sobre os níveis de aninhamento, utilizando indentação 
• Examinar os documentos com as especificações, várias vezes, para garantir que os 
utilizadores os entenderão 
• Verificar a consistência da especificação do processo com o DFD e o DD 
 51
11.2. Pré/Pós 
• São um modo prático de descrever um processo, sem que seja necessário detalhar o 
algoritmo que será utilizado. 
• Tem duas partes: pré-condições e pós-condições e é útil quando: 
• O utilizador tende a especificar um algoritmo muito específico e particularizado que 
vem sendo utilizado há muito tempo 
• O analista está seguro de que existem muitos algoritmos que podem ser usados 
• O analista deseja deixar a definição do algoritmo para o programador, não se 
preocupando em defini-lo com o utilizador 
Pré-Condições 
• Definem o que deve ser verdade antes do início da execução do processo. 
• Podem ser consideradas como uma garantia do utilizador. 
• Normalmente, as pré-condições descrevem o seguinte: 
• Que entradas devem estar disponíveis para que o processo seja activado 
• "O elemento de dados X ocorre" 
• Que relacionamentos devem existirentre as entradas ou no interior delas 
• "Detalhes de pedidos e detalhes de remessas com o mesmo número de conta" 
• "Ocorre um pedido com data de entrega superior a 60 dias" 
• Que relacionamentos devem existir entre entradas e depósitos de dados 
• "Existe um pedido-de-cliente com um número-de-conta-de-cliente que coincide 
com um número-de-conta-de-cliente no depósito de clientes" 
• Que relacionamentos devem existir entre diferentes depósitos ou no interior de um 
depósito 
• "Existe um pedido no depósito de pedidos cujo número-de-conta-de-cliente 
coincide com o número-de-conta-de-cliente no depósito de clientes" 
• "Existe um pedido no depósito de pedidos com uma data-de-embarque igual à 
data actual" 
 52
Pós-Condições 
• Descrevem o que deve ser verdadeiro quando o processo terminar. 
• Podem ser consideradas como uma garantia do sistema para o utilizador. 
• Normalmente, as pós-condições descrevem o seguinte: 
• As saídas que serão geradas ou produzidas por um processo 
• "Será produzida uma factura" 
• Os relacionamentos que existirão entre os valores de saída e os valores originais de 
entrada 
• "O total-facturado foi calculado como soma dos preços-unitários-de-item mais 
taxa-de-embarque" 
• Os relacionamentos que existirão entre os valores de saída e os valores num ou mais 
depósitos. 
• "O balanço-pendente no depósito inventário será aumentado pelo valor-recebido 
e o novo inventário-pendente será produzido como saída deste processo" 
• As alterações que deverão ser feitas nos depósitos 
• "O pedido será acrescentado ao depósito pedidos" 
• "O registo cliente será eliminado do depósito clientes" 
• Exemplo: 
Pré-Condição 1 
- O Cliente apresenta-se com um número-de-conta coincidente com um número 
de conta em Contas, cujo código-de-status está ajustado em "válido" 
Pós-Condição 1 
- A factura é emitida contendo número-de-conta e valor-da-venda 
Pré-Condição 2 
- A pré-condição falha por algum motivo (o número-de-conta não é 
encontrado em Contas ou código-de-estados não é igual a válido 
Pós-Condição 2 
- É emitida uma mensagem de erro 
 53
11.3. Tabela de Decisão 
• É uma técnica não-procedural que permite especificar processos que produzem uma 
saída ou acção dependendo da avaliação de condições complexas 
• Utiliza um formato tabular que facilita a visualização e compreensão do problema 
• O processo representado normalmente requer IF's aninhados e/ou CASE's 
• Não implica uma implementação específica (programador tem liberdade de escolha) 
Estrutura de uma Tabela de Decisão 
• Uma tabela de decisão é composta por: 
• Secção de Condições - (Superior esquerdo) 
• Secção de Acções - (Inferior esquerdo) 
• Entrada de Condições - (Superior direito) 
• Entrada de Acções - (Inferior direito) 
 
Condições 1 2 3 4 
Idade > 21 S S N N 
Sexo M F M F 
Acções 
Exame físico simples X 
Exame físico completo X X 
Exame prático X 
Exame psicológico X 
 
Criar uma Tabela de Decisão 
• Identificar todas as condições ou variáveis na especificação 
• Identificar todos os valores possíveis para cada condição ou variável 
 54
• Calcular o número de combinações possíveis 
• Identificar as acções 
• Criar uma tabela de decisões vazia 
• Preencher as condições e as acções na parte esquerda da tabela 
• Especificar as acções adequadas de acordo com as condições especificadas na coluna 
• Identificar omissões e ambiguidades existentes na especificação do problema e discuti-
las com o utilizador 
11.4. Árvore de Decisão 
• Útil quando nem todas as combinações de condições são possíveis 
• Permite representar graficamente tomadas de decisões complexas 
• Por ser uma técnica gráfica, torna mais fácil compreender e discutir 
Criar uma Árvore de Decisão 
• Identificar as condições 
• Identificar os valores de cada condição 
• Determinar o número de regras do problema (ramos da árvore) 
• Identificar as acções 
• Fazer as simplificações necessárias (podar a árvore) 
 
 55
12. O Modelo Essencial 
12.1. A abordagem clássica 
Os quatro modelos 
• Modelo físico actual 
• Modelo lógico actual 
• Novo modelo lógico (80 a 90% igual ao modelo lógico actual) 
• Novo modelo físico 
Porque a abordagem clássica não funcionava 
• Algumas suposições equivocadas: 
• O analista precisava entender o sistema actual. Para isso, utilizava o modelo físico 
actual 
• O utilizador talvez não queira ou não pode trabalhar como o novo modelo lógico no 
início do projecto 
• Desconfiança da capacidade do analista 
• Dificuldade em lidar com modelos abstractos 
• A transformação do modelo lógico actual num novo modelo lógico não exige muito 
trabalho nem desperdício de trabalho 
12.2. O que é o Modelo Essencial 
• Indica o que o sistema deve fazer, mencionando o mínimo possível sobre como será 
implementado 
• Tecnologia perfeita 
• Tudo pode ser obtido a custo zero 
• Não associar processos a pessoas ou sistemas existentes 
 56
12.3. Dificuldades na construção do Modelo Essencial 
• Dificuldade de eliminar completamente do modelo essencial todos os detalhes de 
implementação 
• Sequência arbitrária de actividades num modelo de fluxo de dados 
• Arquivos desnecessários (devido à tecnologia imperfeita) 
• Processamento em batch 
• Backup/Recuperação 
• Desnecessárias verificações de erros e validação de erros e processos dentro do sistema 
• Dados redundantes ou derivados 
• Desempenho 
12.4. Componentes do Modelo Essencial 
• Composto pelo Modelo Ambiental e pelo Modelo Comportamental 
• O Modelo Ambiental 
• Define a fronteira entre o sistema e o resto do mundo 
• Composto por: 
• Declaração de Objectivos 
• Diagrama de Contexto 
• Lista de Eventos 
• DD com as definições dos fluxos e depósitos externos (opcionalmente) 
• DER dos depósitos externos (opcionalmente) 
• O Modelo Comportamental 
• Descreve o comportamento do interior do sistema, necessário para interagir com 
sucesso com o ambiente 
• Composto por DFD, DER, DTE, DD e Especificação de Processos 
 57
12.5. O Modelo Ambiental 
• Declaração de Objectivos 
• Diagrama de Contexto 
• Lista de Eventos 
• Eventos Orientados por Fluxos 
• Eventos Temporais 
• Exemplos: 
• Cliente entrega pedido (F) 
• Cliente cancela pedido (F) 
• Direcção solicita relatório de vendas (T) 
• Contabilidade precisa (mensalmente) do relatório de comissões de vendas (T) 
12.6. O Modelo Comportamental Preliminar 
• Modelar o comportamento interno para que o sistema possa interagir com o ambiente 
• DFD 
• DER 
• Itens Iniciais do DD 
A Abordagem Clássica (Top-Down) 
• Diagrama de Contexto ⇒ DFD nível 0 ⇒ Detalhamento dos processos do nível 0 até 
chegar a processos atómicos 
• Desta forma, a divisão fica arbitrária 
Particionamento por eventos 
• Envolve 4 etapas: 
• Desenhar um processo para cada evento da Lista de Eventos 
• Dar um nome ao processo de acordo com a resposta que o sistema deve dar ao 
evento 
 58
 59
• Desenhar entradas, saídas e depósitos 
• Verificar o DFD inicial em relação ao Diagrama de Contexto e à Lista de Eventos 
12.7. O Modelo Comportamental Final 
Nivelamento 
• Criar níveis superiores de DFD (ascendente) 
• Directrizes: 
• Agrupar processos que produzem respostas relacionadas 
• Agrupar processos que compartilham depósitos, permitindo ocultá-los no nível mais 
alto 
• Manter o número de processos em 7 ± 2 
• Criar níveis inferiores de DFD (descendente) 
• Quando o processo do DFD preliminar não puder ser especificado numa página 
• Directrizes: 
• Decomposição funcional 
• Decomposição pelos fluxos de entrada/saída 
Complementar Dicionário de Dados 
• Incluir os fluxos e os depósitos encontrados através do nivelamento 
Complementar as Especificações de Processos 
• Provavelmente ainda não haverá