Analise-estruturada-moderna

Texto

(1)Análise Estruturada Moderna (Apontamentos baseados na metodologia de Yourdon).

(2) 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.

(3) 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ÁLISE DE SISTEMAS............................................................................ 29 6.1. 6.2. 6.3. 6.4.. 7.. A PASSAGEM PARA A ANÁLISE ESTRUTURADA .............................................................................. 29 MODIFICAÇÕES NA ANÁLISE ESTRUTURADA ................................................................................. 30 SURGIMENTO DAS FERRAMENTAS AUTOMATIZADAS DE ANÁLISE ................................................. 31 USO DA PROTOTIPAGEM ................................................................................................................. 31. 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. 8.2. 8.3. 8.4. 8.5. 8.6. 8.7.. 9.. NOTAÇÃO ....................................................................................................................................... 39 DEFINIÇÕES .................................................................................................................................... 40 ELEMENTOS OPCIONAIS .................................................................................................................. 40 ITERAÇÃO ...................................................................................................................................... 40 SELECÇÃO ...................................................................................................................................... 41 SINÓNIMO ...................................................................................................................................... 41 DEFINIÇÃO DE DEPÓSITOS.............................................................................................................. 41. 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.

(4) 10.3. 11.. CONSTRUINDO UM DTE ................................................................................................................. 47 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.

(5) 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.

(6) 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 (computadorizado ou não) e interage com outros sistemas.. de. um. sistema. maior. 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.

(7) •. •. 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.

(8) 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.

(9) 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.

(10) 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 de investimentos, análise estatística, simulação de cenários.. 9.

(11) 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.

(12) 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.

(13) •. 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.

(14) 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.

(15) 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.

(16) 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: •. Sistemas que 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.

(17) 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.

(18) 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.

(19) •. 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.

(20) •. 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.

(21) 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. •. •. 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. •. •. Objectivos. 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.

(22) •. 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.

(23) •. 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 triviais sã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.

(24) 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.

(25) 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.

(26) •. 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 homemmá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.

(27) 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 do ciclo de vida: •. •. Abordagem Radical versus Conservadora. 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.

(28) •. 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.

(29) •. 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.

(30) 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 anteriormente adoptada 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.

(31) •. 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. •. •. •. 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 •. •. Politicamente perigosa (muito tempo gasto com algo que vai ser descontinuado). 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.

(32) 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.

(33) 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.

(34) •. •. •. 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.

(35) 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.

(36) 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 as interacçõ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.

(37) 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.

(38) 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.

(39) 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.

(40) 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.

(41) 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 =. 8.4. •. Endereço + (Endereço-Remessa). 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.

(42) 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 =. 8.5. •. Nome-do-Cliente + Endereço-Remessa + {Item}10. Selecção. Indica que deve ser seleccionada uma das opções apresentadas. Exemplo: definindo o estado civil Estado-Civil =. 8.6. •. [Solteiro | Casado | Divorciado | Separado | Outro]. 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.

(43) 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.

(44) 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.. •. Entidades Associativas: 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.

(45) 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.