Apostila de An- ¦álise Funcional de Sistemas

APOSTILA

DE

ANÁLISE FUNCIONAL DE SISTEMAS

Professora GELLARS TAVARES


Professora Gellars Tavares

2

O Analista no Processo de Desenvolvimento de Sistemas

PROBLEMAS NO DESENVOLVIMENTO DE SISTEMAS y 1 - Entender as Necessidades do Usuário considerando:

y Todos os níveis da Organização y Conhecimento da Aplicação y Que para um adequado aprendizado é requerido tempo y Aspectos dinâmicos das necessidades colocados pelos usuários.

ESPECIFICAR BEM SIGNIFICA ENTENDER E DEFINIR AS NECESSIDADES DO

USUÁRIO, CONSIDERANDO A MISSÃO E OBJETIVOS DA ORGANIZAÇÃO. y 2 – Eficiência X Eficácia

y Excesso de abordagem técnica em detrimento dos aspectos de negócio;

y Prioridades devem ser definidas pelo usuário. y Processos mais importantes y Avaliação do Desempenho de Funções

TODO PROCESSO DE DESENVOLVIMENTO REQUER A PARTICIPAÇÃO INTENSA

DOS USUÁRIOS PARA COMPARTILHAR CONHECIMENTOS E DECISÕES.. y 3 - Visão Abrangente e detalhada do y negócio: y Tendência para programar logo

y Programar bem não é suficiente y Sistema requer interação entre componentes

yPOR ONDECOMEÇO? QueMetodologia detrabalho posso

utilizar ?



3

y É fundamental definir de forma clara e objetiva as fronteiras do sistema.

PARA RESOLVERMOS UM PROBLEMA INDEPENDENTE DE SUA COMPLEXIDADE

TEMOS QUE DIVIDÍ-LO EM PROBLEMAS MENORES BUSCANDO CONHECER SUAS INTERDEPENDÊNCIAS.

•4 - Falta de Planejamento

•Requer estimativas mais precisas • Pessoas, $, Tempo (tec. Adm.)

•Deve ser definido uma metodologia de desenvolvimento: •Buscar apoio na Engenharia de Software

• Técnicas, Métodos, Ferramentas e Métricas

QUALIDADE DO SISTEMA DEPENDE DA QUALIDADE DO PROCESSO

•5 - Produtividade •Novos Sistemas a serem desenvolvidos:

• Visíveis, invisíveis ,desconhecidos •Descontinuidade do desenvolvimento

• problemas técnicos • problemas gerencias • inexperiência da equipe • estrangulamento do tempo de desenvolvimento •

•6 - Confiabilidade •Inconsistências no processamento.

•7 - Manutenibilidade •Controle de versões; •Documentação e Correção de erros; •Aprimoramento de rotinas •Implementação de novas características

•8 - Eficiência •Taxa de desempenho (geralmente transações por segundo) •Tempo de resposta

•9 - Portabilidade •Instalação do sistema em outras plataformas

•10 - Segurança •Acessos não-autorizados ao sistema ou dados



4

DIAGNÓSTICO PARA SISTEMAS – TIME

•Participação Intensa do Usuário •Aprendizado e Comunicação

•Ferramental de Desenvolvimento •Biblioteca de Componentes

•Time motivado e comprometido •Infraestrutura Adequada •Atualização Constante

DIAGNÓSTICO PARA SISTEMAS- GERÊNCIA

§ Definir o Ciclo de Vida (Produção) § Líder como Gerente do Projeto § Técnicas de Gerência de Projetos

l PMBOOK • (Guia de Gerência Projetos)

l SQA (Software Quality Assurance) l CMM (Capability Maturity Model) l RUP (Rational Unified Process)

DIAGNÓSTICO PARA SISTEMAS – ANALISTA

§ Metodologias de Desenvolvimento de Sistemas

l Modelagem Funcional • Análise Estruturada

l Modelagem de Dados • Modelo Conceitual • Diagrama Entidade-Relacionamento

l Modelagem de Controle • Análise Essencial

l Modelagem de Objetos • A.P.O.O. / U.M.L.

l Padrões de Projeto e Documentação l Ferramentas CASE



5

CICLO DE VIDA DO PROJETO

Definição: o O ciclo de vida do projeto corresponde a definição de todos os

passos necessários para a implantação de um sistema, desde a sua concepção até a sua implementação e operacionalização

o A descrição da metodologia de trabalho a ser utilizada no desenvolvimento de um sistema.

Objetivos do Ciclo de Vida:

o Determinar os passos a serem seguidos no desenvolvimento de

sistemas o Manter a padronização no desenvolvimento de sistemas o Determinar etapas de validação do projeto

FASES DO CICLO DE VIDA DO PROJETO

Estudo de Viabilidade

o Identificar os usuários do atual e do futuro sistema o Definir um escopo inicial do sistema o Identificar as atuais deficiências de execução dos procedimentos o Estabelecer metas e objetivos para o novo sistema o Determinar a possibilidade de automatizar o sistema atual,

oferecendo alternativas o Elaborar uma previsão do projeto que irá orientar todo o

desenvolvimento

Análise do Sistema o modelagem do sistema

• diagrama de fluxo de dados (DFD) • Diagrama de Entidades-Relacionamentos (DER) • Diagramas de Transição de Estado (DTE)

o Elaboração de uma planilha de custos mais detalhada e precisa Projeto

o Definição de papéis dentro do sistema (atividades manuais e automáticas)

o Forma de comunicação entre os diversos módulos do sistema de forma a facilitar a implementação da especificação definida no passo anterior

o Elaboração do projeto de Banco de Dados a partir do DER definido no passo anterior

o Relacionamento dos principais problemas de implementação que serão encontrados pelos programadores



6

Implementação o Codificação e integração dos módulos definidos na fase de Análise

Geração de Testes de Validação

o Elaboração de rotinas de testes para validação da funcionalidade, segurança e confiabilidade do sistema

Documentação

o Reunir todos os documentos produzidos desde a primeira fase do projeto

o Gerar documentação para os módulos de procedimentos implementados e módulos de teste

o Gerar documentação de operação do sistema

Conversão do Banco de Dados o Quando houver

Instalação o Instalação do sistema o Treinamento de usuários

CICLO TRADICIONAL DE SOFTWARE Uma Metodologia de Desenvolvimento de Sistemas pressupõe a existência de um ciclo de vida para a realização das tarefas inerentes ao desenvolvimento de sistemas. Ciclo de vida é a sequência e a interação em que as atividades de desenvolvimento de sistemas são executadas. O ciclo de vida deve envolver todos os passos desde a concepção do sistema até sua implementação em termos de código executável testado e utilizável pelo usuário final. Os objetivos da adoção de um ciclo de vida pela organização podem ser definidos como:

►definir as atividades a serem executadas no desenvolvimento de sistemas; ►introduzir consistência entre muitos projetos de desenvolvimentos de sistemas dentro da organização; ►e introduzir pontos de verificação para o controle gerencial de decisões.



7

Existem vários paradigmas de Engenharia de Software, cada um com um ciclo de vida específico. Dentro do escopo proposto, analisaremos alguns ciclos de vida para as metodologias de desenvolvimento de sistemas estruturadas. O ciclo de vida clássico é aquele que requer uma abordagem sistemática e seqüencial do desenvolvimento, envolvendo as seguintes fases:

■ análise e engenharia de sistemas; ■ análise de requisitos de software; ■ projeto; ■ codificação; ■ testes; ■ e manutenção.

Fig. CICLO DE VIDA CLÁSSICO



8

► A fase de análise e engenharia de sistemas consiste em estabelecer os requisitos para todos os elementos do sistema e atribuir alguns destes requisitos ao software a ser desenvolvido. ► A fase de análise de requisitos de software consiste no detalhamento dos requisitos levantados na fase anterior, atendo-se mais especificamente aos elementos relacionados às partes informatizadas do sistema, buscando compreender o domínio da informação para o software, as funções, desempenho e interface necessários. ► A fase do projeto consiste em definir a estrutura de dados a ser usada como suporte para o sistema, a arquitetura do software, detalhes de procedimentos para a utilização do sistema e a caracterização da interface. Esta definição deve ser avaliada antes de iniciar-se a codificação, para assegurar a qualidade exigida. ► A fase de codificação consiste na geração dos programas correspondentes às funções do sistema. ► A fase de testes consiste em avaliar se todas as instruções geradas na codificação estão corretas, bem como se o sistema responde adequadamente às entradas do sistema no que diz respeito a sua funcionalidade. ► A manutenção corresponde à realização de mudanças no sistema provocadas pela descoberta de erros (manutenção corretiva) ou pela necessidade de adaptar-se a mudanças no ambiente ou na necessidade do usuário (manutenção adaptativa), ou ainda, pela necessidade de introduzirem-se novas funções para o usuário (manutenção evolutiva). No momento da manutenção, aplicam-se as mesmas fases do desenvolvimento de um novo sistema, com a única diferença sendo a aplicação destas fases a um sistema já existente.

O ciclo de vida clássico possui os seguintes problemas: ● os projetos reais raramente seguem o fluxo seqüencial que o modelo propõe; ● muitas vezes há dificuldades para que o usuário defina os requisitos do sistema de uma só vez, uma vez que o modelo não se adapta à incerteza natural que existe no início do processo de desenvolvimento de um sistema; ● e os primeiros resultados para o usuário somente serão percebidos nas fases mais avançadas do processo, quando muito tempo se passou, podendo ser inviável proceder alguma alteração, cuja necessidade é percebida tardiamente.



9

Outro paradigma é o ciclo de vida semi-estruturado. Este ciclo apresenta duas características inexistentes no ciclo de vida clássico: ● substituição da sequência bottom-up de codificação pela implementação top-down (os módulos de mais alto nível são codificados e testados antes dos de mais baixo nível); ● substituição do projeto clássico (desenho de lay-outs de arquivos, telas e relatórios) pelo Projeto Estruturado (o que é uma abordagem formal de projeto de sistemas)

Fig. CICLO DE VIDA SEMI-ESTRUTURADO



10

A implementação top-down, muitas vezes, leva à realimentação entre o processo de implementação e processo de análise.

Outro modelo é o ciclo de vida estruturado, que corresponde às fase do desenvolvimento de sistemas através da técnica conhecida como Análise Estruturada. A Análise Estruturada, juntamente com o Projeto Estruturado e a Programação Estruturada compõem um paradigma de Engenharia de Software, que é a Metodologia Estruturada de Desenvolvimento de Sistemas.

Fig. CICLO DE VIDA ESTRUTURADO



11

Há algumas vantagens em se adotar a metodologia estruturada, tais como: ● redução de custos de desenvolvimento, implantação e manutenção, em função da modularidade da metodologia; ● ganhos de produtividade, em função do aumento da velocidade de desenvolvimento; ● possibilidade de compreensão do sistema por diferentes analistas e usuários; ● boa parte da documentação do sistema é gerada na medida em que as atividades de desenvolvimento são realizadas; ● e a facilidade de manutenção, gerada pela possibilidade de ir direto ao ponto que precisa ser mudado, uma vez que as técnicas empregadas geram uma documentação eficiente e eficaz.

Dentre as características das metodologias estruturadas, destacam-se: ● particionamento (quebra da complexidade do sistema em módulos); ● funcionalidade (a análise é feita por função do sistema); ● abordagem top-down (partindo do geral para o específico); ● ênfase à modelagem conceitual ou lógica em relação à física (destaca-se o funcionamento do sistema e não quem executa e onde são executadas as funções do sistema); ● e ordenamento das questões “por quê?”, “o que?” e “como” (parte da definição dos objetivos, passando pelas funções, até chegar à lógica dos processos). Concluímos, uma Metodologia de Desenvolvimento de Sistemas apresenta vários elementos como resultado, a partir da execução das fases de seu ciclo de vida. Estes elementos estão descritos na Tabela.



12



13

FASES DO CICLO DE VIDA DO PROJETO

Entusiasmo Desilusão Pânico Busca dos Culpados Punição dos Inocentes Honra e Gloria aos não participantes

PROTOTIPAÇÃO

Definição: Execução de uma abordagem top-down radical que possibilita a produção de um sistema de demonstração semelhante ao real, a partir de um visão superficial do problema.

Ferramentas utilizadas na prototipação: o Dicionário de dados integrado o Gerador de telas o Gerador de relatórios o Linguagem de programação o Linguagem de consulta o Recursos poderosos de Banco de Dados

Projetos candidatos a prototipação: o Usuários com dificuldade de abstração para analisar modelos de

papel ou DFDs o Usuários com dificuldade de expressar suas reais necessidades o Sistemas on-line o Existência de poucos algoritmos

OBJETIVO DO ANALISTA DE SISTEMAS

“Desenvolver um sistema de informações útil e de alta qualidade, que satisfaça as exigências do usuário final.” Edward Yourdon



14

Análise de Sistemas

Definição de Análise: Estudo de um problema, com o objetivo de executar uma ação que o solucione da melhor forma.

Definição de Sistema:

Conjunto de ações que manipulam dados e geram informações e/ou dados, representando a organização e o funcionamento de uma atividade.

Definição de Análise de Sistemas:

Estudo da organização e funcionamento de seus processos, com o objetivo de gerar um conjunto de ações que utilizando dados geram informações, que solucione, da melhor forma possível, os problemas existentes.

Como justificar o investimento de informatização:

Viabilizando o aumento dos lucros; Antecipando-se aos concorrentes; Aumentando o nível das vendas; Diferenciando o tratamento dispensado aos clientes; Evitando as perdas de estoque.

QUE TIPOS DE SISTEMAS PODE OFERECER

DIFERENCIAIS

Sistema de vendas de medicamentos Locação de carros Sistema Federal de Arrecadação de Impostos Sistema integrado de Consultório Médico Controle Acadêmico Sistema de Apuração de Ponto Digital



15

IMPORTÂNCIA DA ANÁLISE DE SISTEMAS

Estudo do problema e de suas possibilidades de solução; Interação com o usuário final para adequação do sistema as suas

necessidades; Especificação da solução mais indicada; Avaliação prévia do custo-benefício; Análise da viabilidade de implantação; Total flexibilidade para desvios de rota sem grandes prejuízos; Forte documentação de todo o processo.

PESSOAS ENVOLVIDAS NA ANÁLISE

Usuários - pessoas para quem o sistema está sendo construído

o operadores o supervisores o executivos

Padronizadores: pessoas responsáveis pelas nomenclaturas utilizadas no

desenvolvimento dos sistema (telas, documentação, helps, menus, nomes de arquivos)

Analistas de Sistemas: pessoas responsáveis pela especificação do sistema

Programadores: pessoas responsáveis pela implementação, em uma

linguagem de programação específica, da especificação gerada pelos Analistas de Sistemas

Administradores de Dados : Responsáveis pela gestão e padronização

dos dados da aplicação

O ANALISTA DE SISTEMAS ...

Participa das etapas de levantamento de REQUISITOS e ANÁLISE do ciclo de desenvolvimento do sistema;

Interage diretamente com o usuário, levantando as suas necessidades. Especifica O QUE DEVE ser feito. Deve estudar e entender o negócio e a missão da empresa. Estuda a viabilidade do sistema.

o Técnica, Financeira, Prazos



16

Investir em seu próprio treinamento para poder sugerir diferenciais competitivos utilizando a informática

§ Visualizar os problemas por níveis de abstração.

Utiliza metodologias de fácil compreensão do usuário para especificar o

sistema a ser implementado.

PERFIL DO ANALISTA - Comunicação - Clareza de raciocínio - Percepção - Negociação - Flexibilidade - Persistência

- Visão Sistêmica - Criatividade - Determinação - Sensibilidade - Paciência - Eficácia

Recurso

Custo Benefício



17

CONHECIMENTOS DESEJÁVEIS PARA O ANALISTA DE SISTEMAS

§ Metodologias de Análise § Modelagem de Dados § Gerência de Projetos § Engenharia de Software § Administração, Economia, Estatística, Matemática, Inglês técnico ...

FERRAMENTAS DA ANÁLISE

§ Modelagem das Funções do Sistema

l Análise Estruturada • Diagrama de Fluxo de Dados, Contexto, Dicionário de Dados,

Especificações § Modelagem de Dados Armazenados

l Diagrama de Entidades e Relacionamentos • Entidades • Relacionamentos

§ Modelagem do Comportamento Dependente do Tempo l Análise Essencial

§ Modelagem sobre Objetos e suas Operações l Análise e Projeto Orientado a Objetos l Unified Modelling Language (UML)



18

CICLO DE TRABALHO DO ANALISTA

OBJETIVOS DA DISCIPLINA

Fornecer uma visão teórica e prática sobre os procedimentos

envolvidos na análise e no projeto de sistemas de software, em sintonia com o ciclo de vida do sistema.

Identifica o Problema Analisa e Ordena Idéias

Vende a idéia

Motivar Avalia e Corrige

Obter Info.

Estabelece um Plano

Implanta e Acompanha



19

ANÁLISE ESTRUTURADA

• Características da Metodologia

– utiliza linguagem gráfica com suporte de texto; – fornece uma visão top-down e particionada do sistema; – possibilita eliminar redundâncias; – os instrumentos conseguem ser transparentes ao leitor

• No final da década de 70, a análise estruturada possibilitou especificar os requisitos lógicos do sistema em um modelo gráfico de alto nível, capaz de ser compreendido pelos usuários e de ser mapeado para a arquitetura do projeto. O modelo gráfico introduzido pela análise estruturada representa os dados utilizados por um sistema, os fluxos que transportam e os processos que os transformam.

• A análise estruturada é uma abordagem sistemática para fazer a análise de um sistema de modo a produzir a uma especificação funcional.

• A especificação funcional define as funções e estruturas de dados que constituem o sistema. • A análise estruturada usa técnicas:

– gráficas simples, modulares, complementares • É necessário que o analista saiba se comunicar com os clientes e garantir clareza de ideias

colocadas por eles.

PROCESSO

– Componentes de sistemas que transformam dados de entrada em dados de saída. – “Caixa preta”:

• ligações de entrada e de saída (interfaces); • se conhecermos os elementos de entrada, podemos determinar exatamente a

saída que será produzida em função deles; • em suma: sabemos o que é feito, não necessariamente como é feito.

Componentes do Modelo ESTRUTURADO:

– Diagrama de Fluxo de Dados (DFD): representação gráfica da rede de processos

interligados; – Dicionário de Dados: descrição das interfaces; – Especificação dos Processos: descrição do que cada processo faz.

DIAGRAMA DE FLUXO DE DADOS (DFD):

– forma gráfica de mostrar: • a interdependência dos processos que compõem um sistema; • os fluxos de dados entre elas. • arquivos lógicos de dados - depósito de dados; • entidades externas.



20

CARACTERÍSTICAS DE UM DFD

• Simplicidade (intuitivo) - acessível ao utilizador / cliente

• Abordagem “Top-Down”, dá uma visão do sistema do geral para o particular apresentando os detalhes através de níveis hierárquicos

• O Desenvolvimento é iterativo - aperfeiçoamento sucessivo de uma versão inicial

• O DFD não é procedimental – não tenta representar processamento condicional ou ciclos com esta forma

diagramática. Simplesmente mostra o fluxo dos dados. – não há indicação explicita da sequência de processamento ou condição lógica é

fornecida pelo diagrama

• Os DFDs representam fluxo de informação e não fluxo de controle - O DFD não é um fluxograma

• O DFD não contém informação temporal

DFDS DESENVOLVIDOS EM NÍVEIS HIERÁRQUICOS

• Um DFD não deve ter mais de 7+/-2 processos (folha A4) - limite de elementos que a mente humana consegue visualizar simultaneamente

• O DFD de um Sistema de Informação é desenvolvido de acordo com uma decomposição

hierárquica nos seguintes níveis (diagramas): – Diagrama de Contexto visão geral do sistema.

• É o diagrama de visão mais elevada e consiste num único processo representando o sistema inteiro e os fluxos de dados representam as interfaces com o exterior (Entidades Externas)

– Diagrama 0 - visão global do sistema. • Diagrama que representa uma visão de alto nível dos principais processos do

sistema e as principais ligações entre esses processos. – DFDs de nível n-1 - detalhe do sistema

• Sistema de complexidade baixa => 2 a 3 níveis • Sistema de complexidade média => 3 a 6 níveis • Sistema de complexo => 5 a 8 níveis



21

ALGUMAS CONSIDERAÇÕES:

– Os elementos componentes de um DFD são:

• processos; • fluxos de dados; • depósitos de dados; • entidades externas.

– componentes externos: • entidades externas;

– componentes internos: • processos, fluxos de dados e depósitos.

– componentes ativos: • processos

– componentes estáticos: • depósitos de dados.

– as informações num DFD se apresentam: • em movimento:

– nos fluxos de dados. • estáticas:

– nos depósitos de dados. – um fluxo de dados liga:

• uma entidade externa a um processo; • um processo a um depósito de dados; • um processo a outro processo

– um fluxo de dados representa um conjunto de dados, não o seu suporte material –

FLUXO DE DADOS:

Registrar nota de débito

Inf. notas de débito



22

DEPÓSITO DE DADOS:

ENTIDADES EXTERNAS:

Dados. Nota de

débito Registrar nota de débito

Processar nota débito

débito

Notas de débito

Nota de débito

Departamento de cobrança

Sistema de cobrança

Inf- débito

dados-notas de

débito


Nota de débito

Processar nota

de débito

débito

Notas de débito

Inf-débito



23

FRONTEIRA DO SISTEMA:

DIAGRAMA DE CONTEXTO:

ABORDAGEM“TOP-DOWN”:

Dados Nota de débito


Processar nota de débito

débito

Notas de débito

Nota de débito



Inf- débito

Fronteira

Dados. nota de débito

débito



Sistema de Cobrança



24

NÍVEL CONTEXTO

NÍVEL 0

NÍVEL 1

E1

E4E2

E3

Sistema

E1

E4E2

E3

P2 P4

P1 P3

P2

E4P1

P3.1 P3.3

P3.4 P3.2



25

REGRAS PARA A CONSTRUÇÃO DE DFDS • Processo:

• nome de função ou processo: – sentença imperativo: verbo no infinitivo + complemento:

• Processar vendas, Escolher a melhor proposta, verificar recebimento, Gerar relatórios de vendas, Emitir recibo de pagamento

– procurar nomear a partir da saída que ela produz. – não associar processos aos seus executores – numerar processos

• fluxo de dados:

• nome de fluxo de dados: – substantivo (simples ou composto)

• Lista de pedidos, Pedidos pendentes, Níveis de estoque, Solicitação de fechamento do caixa, Cardápio.

– não agrupar ítens de natureza diferente: • Solicitação cadastro, Resposta entrevista

• depósito de dados:

D1

• nome de depósitos de dados: – substantivos simples ou composto, no plural:

• Produtos, Encomendas do cliente, Fornecedores, Pedidos em andamento – não interessa o meio de armazenamento; – não chamar de arquivo..., cadastro...

1 1

1 1



26

• entidade externa:

• nome de entidades externas:

– substantivos simples ou compostos: • Cliente, Sistema de Crédito, Gerência, Marketing

– representa o conjunto de entidades do ambiente externo que alimenta ou recebe informações dos processos

• acesso à memória:

• acesso à memória:

Incluir (gravar) Consultar (ler)

Excluir Modificar



27

REGRAS PARA A CONSTRUÇÃO DE UM DFD

• Depósitos de dados

– Dados não podem mover-se diretamente de um depósito de dados para outro depósito de dados.

• Os dados têm de ser movidos por um processo. – Os dados não podem mover-se diretamente de uma Entidade Externa para um

depósito de dados. • Os dados têm de ser movidos por um processo que recebe os dados da

Entidade Externa e coloca-os no depósito de dados – Os dados não podem mover-se diretamente de um depósito de dados para uma

Entidade Externa. • Os dados têm de ser movidos por um processo

– Um depósito de dados é identificado por um substantivo/nome que deve sugerir o respectivo conteúdo

• Dados do Mercado; Clientes; Pagamentos em atraso; Encomendas pendentes – Não é obrigatória a atribuição de nomes aos fluxos de e para depósitos de dados

• Entidades Externas

– os dados não podem mover-se direamente entre duas Entidades Externas • têm de ser movidos por um processo se os dados são de algum interesse para

o sistema. • Caso contrário, o fluxo de dados não é mostrado no DFD

– Uma Entidade externa é identificada por um substantivo/nome

• Fornecedores; Armazém; Administração; Utilizadores; ...

• Fluxos de dados

– Um fluxo de dados tem uma única direção de fluxo entre símbolos. • Pode fluir nas duas direções entre um processo e um depósito de dados para

mostrar uma leitura antes de uma atualização. O último é usualmente indicado por duas setas separadas já que isto acontece em tempos diferentes

– Todos os detalhes dos fluxos de e para depósitos de dados são definidos ao nível da Especificação dos Processos

– Os fluxos de dados representam o deslocamento de informações entre:

• um Processo e uma Entidade Externa • dois processos • um Processo e um Depósito de Dados

– Não são permitidos os fluxos de dados entre: • duas Entidades Externas • dois depósitos de Dados • uma Entidade Externa e um Depósito de Dados



28

POSSÍVEIS ERROS NA GERAÇÃO DE UM DFD

• duplicação de entidades externas:

• duplicação de depósitos de dados:

• cruzamento de fluxos:

• orientação geral do DFD:

RECOMENDAÇÕES

• adotar os mesmos nomes utilizados pelos usuários; • de preferência, um DFD deve ter de cinco a nove processos; • cada DFD deve ocupa apenas uma página; • o DFD deve ser submetido à aprovação das pessoas que conhecem o sistema.



29

DIAGRAMA DE CONTEXTO

DIAGRAMA NÍVEL 0

Especificação de Processos

• descreve a forma como os dados de entrada são transformados nos dados de saída. • independe da forma como a função é executada (manualmente ou automatizada) • usa-se: - português estruturado

- pseudocódigo

Pag-Cliente

Ped-Cliente Cliente

Fatura-Cli

Fornecedor

Rel-Fin

Com-Vend_

Pag-Fornec

Encomenda

Fatura-Fornec

Sistema de vendas

Depto_ Pla- nejamento

Depto_ R-H

Loja Atualizar Estoque

Loja

CadastrarLoja

CadastrarLivro

Gerência Operacional

Loja

Estoque Loja

Livro



30

Português Estruturado

• versão / adaptação do português: – verbos no modo imperativo; – termos definidos no dicionário de dados; – palavras “reservadas” para descrever a lógica da função.

• pouco uso de adjetivos e advérbios; • construções típicas da programação estruturada:

– seqüências – decisões – repetições.

Pseudocódigo

ABRIR avaliações-de-alunos, disciplinas, alunos e ender-alunos DEFINIR quant_reprovações = 0 LER alunos REPETIR-ENQUANTO existam alunos: PESQUISAR primeira ocorrência da chave matr-aluno (de alunos) em avaliações-de-alunos REPETIR-ENQUANTO existam em avaliações-de-alunos registro para a chave matr-aluno (de alunos) pesquisada: SE média-final for MENOR QUE 5 INCREMENTAR quant_reprovações PESQUISAR cod-disciplina em disciplinas LER próximo registro em avaliações-de-alunos FIM REPETIR IMPRIMIR aviso_de-situação-do aluno LER próximo registro em alunos FIM-REPETIR

PORTUGUÊS ESTRUTURADO

orientado para procedimentos usa termos familiares ao usuário

(linguagem do negócio da empresa)

o objetivo é um alto nível de comunicação

PSEUDOCÓDIGO orientado para a implementação. lembra linguagem de

programação o objetivo é facilitar a

programação



31

Dicionário de Dados

Vimos, até agora, a construção de DFD como ferramenta para análise estruturada

de um sistema. Dentre os componentes que utilizamos está o fluxo de dados, que mostra a movimentação de “pacotes” de dados ou informações que transitam no sistema. Mas para melhorar a compreensão sobre essas informações vamos utilizar uma ferramenta chamada Dicionário de Dados, que mostrará a descrição detalhada dos “pacotes” e as informações nele contidas em relação ao sistema estudado.

Segundo Yourdon sem o Dicionário de Dados o modelo de requisitos do usuário não pode ser considerado completo e será apenas um esboço grosseiro ou uma representação artística do sistema.

O Dicionário de Dados é uma listagem organizada de todos os elementos de dados pertinentes ao sistema, com definições precisas e rigorosas para que o usuário e o analista de sistemas possam conhecer todas as entradas, saídas, componentes de depósitos e cálculos intermediários. Ele define os elementos de dados da seguinte maneira:

• Descrevendo o significado dos fluxos e depósitos mostrados nos DFD. • Descrevendo a composição de pacotes agregados de dados que se

movimentam pelos fluxos, isto é, pacotes complexos. • Descrevendo a composição dos pacotes de dados nos depósitos. • Especificando os relevantes valores e unidades de partes elementares de

informações dos fluxos de dados e depósito de dados. • Descrevendo os detalhes dos relacionamentos entre os depósitos realçados

em um DER.

Notação do Dicionário de Dados Existem vários esquemas de notação para o Dicionário de Dados. Vamos seguir o

proposto pelo Livro Análise Estruturada Moderna (YOURDON, 1990), que é um dos mais comuns.

= é composto de + e ( ) opcional (pode estar presente ou não) { } iteração [ ] escolha uma das opções alternativas ** comentário @ identificador

| separa opções alternativas na construção [ ]



32

Exemplo: nome = título-cortesia + primeiro-nome + (nome intermediário) + último-nome título-cortesia = [Sr.|Srta.|Sra.|Sras.|Dr.|Professor] primeiro-nome = {caracter-válido} nome-intermediário = {caracter-válido} último-nome = {caracter-válido} caracter-válido = [A-Z | a-z | 0-9 | ‘ | - | |]

Definições Uma definição de elemento de dados é apresentada com o símbolo “=”; neste

contexto, o “=” é lido “é definido como”, ou “é composto de”, ou simplesmente “significa”. A = B + C

poderia ser lida como: Sempre que dissermos A, queremos dizer B e C A compõe-se de B e C A é definido como B e C

Para definir completamente um elemento de dados, nossa definição incluirá o seguinte:

• O significado do elemento de dados no contexto desta aplicação do usuário. Isto é normalmente apresentado como um comentário, usando-se a notação “**”

• A composição do elemento de dados, se ele for composto por

componentes elementares significativos.

• Os valores que o elemento de dados poderá assumir, se ele for um elemento de dados elementar que não possa ser decomposto.

Exemplo:

peso = *peso do paciente ao chegar ao hospital * *unidades: quilogramas; intervalo: 1-200 *

Altura = *altura do paciente ao chegar ao hospital * *unidades: centímetros; intervalo: 20-200 *



33

Elementos de Dados Elementares

São aqueles para os quais não existe decomposição significativa no contexto do usuário. Isto é uma questão de interpretação. Veja o caso do elemento nome, no exemplo anterior. Talvez não seja necessário decompor.

Existem casos em que o elemento é tão óbvio que não há necessidade de se explicar o significado. Quando isto acontece utiliza-se a seguinte forma:

altura-atual = ** *unidades: centímetros; intervalo: 1-300 * peso-atual = ** *unidades: kilogramas; intervalo: 1-196 *

Elementos de Dados Opcionais Um elemento de dados opcional, é o que pode estar ou não presente como um

componente de um elemento de dados composto.

Exemplo: endereço-cliente = rua + número + (complemento) + bairro

telefone-cliente = ddd + telefone + (ramal)

Iteração A interação é usada para indicar a ocorrência repetida de um componente de um

elemento de dados. Ela é lida como “zero ou mais ocorrências de”. Deste modo a notação pedido = nome-do-cliente + endereço-de-remessa + {item}

significa que um pedido deve conter , além do nome do cliente e o endereço, uma lista de itens contendo 0, 1 ou mais itens. É comum que o usuário deseje especificar limites mínimos e máximos de iterações. Por exemplo, pode-se querer que exista, pelo menos, 1 item no pedido e no máximo 50 itens. A definição seria da seguinte forma:

pedido = nome-do-cliente + endereço-de-remessa + 1{item} 50 Obs: é possível, ainda, determinar apenas um limite inferior ou apenas um limite superior.



34

Especificações dos Processos A Especificação dos Processos é a descrição do que ocorre dentro de cada bolha

primitiva, ou seja, as olhas do último nível. Portanto, só se faz a especificação dos processos das bolhas do último nível de DFD desenhado.

Qualquer que seja o nome, o propósito de uma especificação é sempre direto: ele define o que deve ser feito para transformar entradas em saídas, é uma descrição detalhada da orientação empresarial do usuário executada pelas bolhas.

Existem diversas ferramentas que podemos utilizar para produzir uma especificação de processos: tabelas de decisão, linguagem estruturada, condições pré/pós. Fluxogramas, e outras. Embora a maioria dos analistas de sistemas prefiram a linguagem estruturada não devemos esquecer que podemos utilizar qualquer método, desde que ele satisfaça dois requisitos:

• A especificação de processos deve ser expressa de uma forma que possa ser verificada pelo usuário e pelo analista de sistemas.

• A especificação de processos deve ser expressa de uma forma que possa ser efetivamente comunicada aos diversos participantes do sistema.

A maioria das empresas e analistas de sistema costuma utilizar apenas uma dessas formas para especificação de processos, mas é permitido que se utilize outra formas de especificação na análise de um mesmo sistema.

Estima-se que, 40 a 50 “verbos” são suficientes para descrever qualquer especificação de processos.

Obs: verbos são os comandos em linguagem estruturada.

Vejamos um exemplos de descrição de um processo que examina uma série de registros de pedidos no depósito PEDIDOS para calcular um total diário:

total-diário = 0

ENQUANTO existirem mais pedidos em PEDIDOS como data-fatura = data-hoje

LER próximo pedido em PEDIDOS como data-fatura = data-hoje

ESCREVER em Contab número-fatura, nome-cliente, total-geral

Total-diário = total-diário + total-geral

FIMENQUANTO

ESCREVER em Contab total-diário



35

PORTUGUÊS ESTRUTURADO

É um subconjunto da linguagem normal, atendendo as regras de construção de algoritmos. Suas sentenças podem ser equações matemáticas, ou ações indicadas pelos verbos a seguir : . Obter . Ler . Escrever . Exibir

. Localizar . Somar . Subtrair . Multiplicar

. Dividir . Calcular . Apagar . Validar

. Mover . Atualizar . Classificar Obs.: A lista acima é uma sugestão, o critério a ser observado é que os verbos devem ser claros, precisos e sugerir bem o nível de abstração no qual se enquadra a especificação de processos (conceitual). Em suma, os verbos escolhidos devem exprimir com fidelidade o que o processo executa ao transformar os fluxos de entrada em fluxo(s) de saída, como também caracterizar o nível conceitual. Representação das Estruturas de Controle Estruturas de Seleção: a) Se (condição)

Então (Comando ou grupo de comandos) Senão (Comando ou grupo de comandos)) Fim-Se

b) Caso (condição 1) : (comando ou grupo de comandos 1) (condição 2) : (comando ou grupo de comandos 2) (condição 3) : (comando ou grupo de comandos 3)

Fim-Caso

Estruturas de Repetição: a) Enquanto (condição) Faça

(comando ou grupo de comandos) Fim-Enquanto

b) Repita (comando ou grupo de comandos) até (condição) c) Variando i de <vini> até <vfim> Passo <incremento>

(comando ou grupo de comandos) Fim-Variando Obs: Os nomes mencionados na especificação que façam parte do dicionário de dados devem ser grifados a fim de facilitar a compreensão do processo.



36

Diretrizes para elaboração da especificação utilizando o Português Estruturado 1) Restringir a especificação a no máximo 1 folha (66 linhas. Se isso não for possível,

deve-se tentar outro algoritmo, se a complexidade continuar com o novo algoritmo então deve-se avaliar a possibilidade do processo não ser um primitivo funcional, ou seja, verificar se o processo não pode ser subdividido em uma rede de subprocessos.

2) Nunca utilize mais de três níveis de aninhamento. Se seu processo exigir muitos níveis

de aninhamento de decisões opte imediatamente por uma tabela ou árvore de decisão. 3) Idente sua especificação a fim de evitar confusões sobre o níveis de aninhamento das

estruturas de seleção. Exemplo: processo CADASTRAR PEDIDO realizado em resposta ao evento “Cliente envia Pedido” que ocorre numa Livraria que vende livros sob encomenda.

Cliente

CADASTRARPEDIDO

Clientes

Itens-Pedidos

Pedidos Livros

pedido-cliente

pedido-recusado

1.1



37

Processo 1.1: cadastrar pedido INICIO Obter dados de pedido-cliente Localizar cliente em Clientes com nome-cli de pedido-cliente SE não existir cliente ENTÃO Acrescentar em pedido-recusado a mensagem “Cliente não cadastrado” SENÃO FAÇA ENQUANTO existir titulo-livro em pedido-cliente Localizar livro em Livros com titulo-livro de pedido-cliente SE não existir livro ENTÃO

Acrescentar em pedido-recusado a mensagem “Livro não cadastrado”

FIM_SE obter próximo título-livro de pedido-cliente FIM_ENQUANTO FIM-SE SE não houver pedido recusado ENTÃO armazenar pedido em Pedidos com num-ped = último num-ped incrementado de 1, cod_cli de cliente, data-ped = data do dia, sit-ped = “P” ENQUANTO existir titulo-livro em pedido-cliente Localizar livro em Livros com título-livro de pedido-cliente Armazenar item-pedido em Itens-pedidos com Num-ped de pedido, Cod-livro de livro, qtde de pedido-cliente, Num-req = nulo, Sit-item = “P” Obter próximo título-livro em pedido-cliente FIM -ENQUANTO

FIM-SE FIM.



38

Diagrama de Transições de Estado

Vimos até agora diagramas que modelas as funções do sistema. O Diagrama de Transições de Estado, também conhecido como DTE, é uma ferramenta de modelagem que enfatiza o comportamento tempo-dependente do sistema.

Normalmente o DTE é utilizado para descrever o comportamento de sistemas de tempo-real, ou seja, que necessitam dar respostas rápidas quando solicitados. Um exemplo seria a obtenção de dados metereológicos precisos de um satélite. Sistemas deste tipo trabalham com fontes externas de dados de alta velocidade e devem produzir respostas e dados de saída com suficiente rapidez para interagir com o ambiente externo. Uma parte importante da especificação desses sistemas é a descrição do que acontece quando.

No caso de sistemas orientados para o comércio, esse problema não tem sido tão importante. As entradas podem chegar ao sistema de muitas fontes diferentes e em velocidades relativamente altas, porém essas entradas podem habitualmente ser retardadas se o sistema estiver ocupado com alguma outra coisa. Um sistema de pagamento, por exemplo, não tem que se preocupar com interrupções, nem com um sistema externo qualquer.

Entretanto, novos problemas a serem resolvidos, com alta complexidade mostram a necessidade de se utilizar modelos dependentes do tempo.

Notação do Diagrama de Transições de Estado

Os principais componentes de um DTE são os estados e as setas que representam

alterações de estado. Existem diversas notações alternativas para se construir um DTE. Para facilitar o estudo usaremos a seguinte notação:

Estados do Sistema

Um estado do sistema pode estar será representado por um retângulo com seu

“rótulo” no centro da figura.

Aguardando que o usuário introduza

uma senha

Ocioso

Aquecendo a mistura química

Aguardando o próximo comando



39

Mudanças de Estado

Os sistemas que estudamos, normalmente, podem ter dúzias de estados

diferentes. Mas como um sistema passa de um estado para o outro? Se o sistema tiver normas dirigindo o seu comportamento, então somente certos tipos de mudanças de estado serão significativas e válidas.

As modificações válidas de estado no DTE são mostradas interligando-se por uma seta os pares de estados relevantes.

O estado inicial do sistema deve ser desenhado no alto do diagrama, embora isso

não seja obrigatório e o estado final normalmente é desenhado na base do diagrama. O sistema só pode ter um estado inicial; entretanto ele pode ter vários estados

finais; esses estados finais são mutuamente exclusivos, o que quer dizer que apenas um deles pode ocorrer durante a execução do sistema.

ESTADO 2

ESTADO 1

ESTADO 3

ESTADO 5

ESTADO 4



40

Condições e Ações

Para tornar completo nosso diagrama de transições de estado, precisamos

acrescentar mais duas coisas: as condições que causam uma mudança de estado e as ações que o sistema empreende quando muda de estado. As condições e ações são exibidas junto à seta que liga os dois estados inter-relacionados.

Uma condição é um evento no ambiente externo que o sistema seja capaz de

detectar, podendo ser um sinal, uma interrupção ou a chegada de um pacote de dados. Isso normalmente fará o sistema passar do estado de aguardando X para o estado de aguardando Y ou de executando a atividade X para executando a atividade Y.

Como parte da mudança do estado, o sistema normalmente empreenderá uma ou mais ações; produzirá uma saída, apresentará uma mensagem no terminal do usuário, efetuará um cálculo etc. Portanto, as ações mostradas no DTE ou são respostas enviadas ao ambiente externo ou são cálculos cujos resultados são memorizados pelo sistema (depósito de dados) para reagir a algum evento futuro.

Diagramas Subdivididos

Num sistema complexo pode haver dúzias de estados distintos: tentar mostra-los

todos no mesmo diagrama seria difícil, senão impossível. Assim, da mesma forma que utilizamos níveis e sub-níveis nos DFD, podemos subdividir o DTE.

Observe que nesse caso, qualquer estado individual de um diagrama de nível mais elevado pode tornar-se o estado inicial de um diagrama de nível inferior que descreva mais detalhadamente aquele estado de nível mais elevado; e o(s) estado(s) final(finais) de um diagrama de nível mais baixo corresponde(m) às condições de saída do estado associado de nível superior. Em outros casos, o analista pode precisar mostrar, explicitamente, como um DTE de nível inferior sai para um ponto adequado do diagrama superior.

ESTADO 1

ESTADO 2

Condição

Ação



41

Exemplo: DTE de um caixa automático



42

Construção do Diagrama de Transições de Estado Existem duas formas de iniciar a construção do DTE:

1. Identificar todos os estado possíveis do sistema, colocar no papel e explorar as possíveis conexões significativas (mudanças de estados);

2. Começar pelo estado inicial, tentando fazer o caminho para os estados seguintes.

A abordagem que você vai adotar será, em muitos casos, ditada pelo usuário com

quem você estiver trabalhando, principalmente se ele for o único familiarizado com o comportamento tempo-dependente do sistema.

Após ter terminado de elaborar o DTE preliminar, você deve executar as seguintes diretrizes de verificação de consistência: •Foram definidos todos os estados? Examine cuidadosamente o sistema para verificar se há qualquer outro comportamento observável ou qualquer outra condição em que o sistema possa estar além daqueles que você tiver identificado •Todos os estados podem ser atingidos? Algum estado foi definido sem que haja caminhos que levem a ele? •Todos os estados têm saída? Como já dissemos, o sistema pode ter um ou mais estados finais com múltiplas entradas; mas todos os outros estados devem ter um estado sucessor. •Em cada estado, o sistema reage adequadamente a todas as condições possíveis? Este é o erro mais comum na elaboração de um diagrama de transições de estado: o analista de sistemas identifica as mudanças de estado quando ocorrem as condições normais, mas esquece de especificar o comportamento do sistema em condições inesperadas.



43

DIAGRAMA DE ENTIDADE-RELACIONAMENTO (DER)

Modelo Entidade-Relacionamento, um modelo conceitual de dados de alto nível, freqüentemente usado para o projeto conceitual de aplicações de bases de dados. Ele baseia-se na percepção de um universo constituído por um grupo básico de objetos chamado entidades, e por relacionamentos entre eles. ENTIDADES E ATRIBUTOS

Uma entidade é um objeto que existe e é distinguível de outros objetos. Uma entidade pode ser um objeto com uma existência física (entidade concreta) – um empregado, pessoa, carro, casa em particular – ou conceitual (entidade abstrata) – uma companhia, um emprego, um curso universitário.

Um conjunto de entidades é um grupo de entidades do mesmo tipo. Por exemplo: o conjunto de todas as pessoas que possuem cadastro em uma biblioteca pode ser definido como o conjunto de entidades Usuário; de maneira similar, o conjunto de entidades Cadastro pode representar o conjunto de todos os cadastros em uma biblioteca em particular. Tais conjuntos não precisam ser independentes: é possível definir o conjunto de entidades de todos os empregados de um banco (Empregado) e o conjunto de entidades de todos os clientes do mesmo banco (Clientes). Uma entidade Pessoa pode ser uma entidade Empregado, uma entidade Cliente, ambas ou nenhuma delas.

Cada entidade tem atributos – propriedades particulares que a descrevem. Por exemplo, uma entidade Aluno pode ser descrito pelos atributos “nome”, “R.A.” e “curso”. Uma base de dados compreende uma coleção de conjuntos de entidades, contendo cada um certo número de entidades do mesmo tipo. Uma entidade em particular possui um valor para cada um de seus atributos. Os valores de atributos que descrevem cada entidade compõem a maior parte dos dados armazenados em uma base de dados.

RELACIONAMENTOS

Um relacionamento é uma associação entre dias ou mais entidades. Por exemplo, podemos definir uma relação que associe um aluno particular com uma certa disciplina; isto especifica que ele é um aluno da universidade, cursando aquela disciplina.

Um conjunto de relacionamentos é um grupo de relacionamentos do mesmo tipo. Para ilustrar isto, considere duas entidades Usuário e Cadastro; definimos o conjunto de relacionamentos CadastroUsuário para denotar a associação entre todos os usuários da biblioteca e seus cadastros guardados lá. Este é um exemplo de um conjunto de relacionamentos binário (que envolve dois conjuntos de entidades): a maior parte dos conjuntos de relacionamentos num sistema de base de dados é binária; ocasionalmente, há conjuntos de relacionamentos que envolvem mais do que dois conjuntos de entidades.



44

Um relacionamento pode também possuir atributos descritivos. Por exemplo, o conjunto de relacionamentos ClienteConta define a associação entre clientes de um banco e suas contas bancárias; “data” pode ser um atributo de ClienteConta, especificando a data em que um cliente abriu sua conta.

Seja o seguinte banco de dados de pessoas, representados pelas classes de entidades EMPREGADO e DEPARTAMENTO: Classe de entidades Classe de entidades EMPREGADO DEPARTAMENTO TEMOS:

- Os empregados João e Maria pertencem ao Departamento A; - Os empregados Luiz e Ana pertencem ao Departamento B; - Os empregados Afonso, José e Pedro pertencem ao Departamento C.

A cada entidade da classe EMPREGADO pode estar associado apenas uma única entidade da classe DEPARTAMENTO . Por outro lado, a cada entidade da classe DEPARTAMENTO corresponde pelo menos uma entidade de classe EMPREGADO.

JOÃO LUIZ MARIA AFONSO JOSE PEDRO ANA

DEPTO A DEPTO B DEPTO C



45

PREMISSAS BÁSICAS: 1- Somente classe de entidades possuem atributos.

2- Toda classe de entidades possui pelo menos um atributo ou conjunto de atributos que

sirva como identificador.

3- Em toda classe de entidades não haverá atributos que não sejam exclusivos daquela

classe. Uma exceção é feita para os atributos que servirem como elementos de

ligação (atributos relacionantes ou referenciais) com outras classes de entidades, os

quais poderão ser comuns. Por exemplo, é através do atributo COD-DEPTO – comum

às duas classes – que a classe de entidade EMPREGADO se referencia à classe

DEPARTAMENTO.

4- No contexto de um sistema, nenhuma classe de entidades a ele pertencente existe

isoladamente. Deverá sempre estar ligada a pelo menos uma outra classe de

entidade, através de um relacionamento, o qual é materializado através de atributos

comuns.

5- Entre cada duas classes de entidades deverá ser expresso um único relacionamento.

6- Não ocorre auto-relacionamento.

EMPREGADOS DEPARTAMENTOS



46

♦ Os retângulos representam classes de entidades. Assim, Empregado e Departamento

são classes de entidades.

♦ As linhas que ligam uma classe de entidade a outra representam os relacionamentos entre as classes de entidades. Os símbolos que representam o tipo de mapeamento e seu respectivo significado:

Cada entidade da classe “A” está associada a quantas entidades da classe “B” ?

Mínimo

Máximo

1

1

Cada entidade da classe “A” está associada a uma única entidade da classe “B”.

1

Várias

Cada entidade “A” está associada a uma ou várias entidades da classe “B”.

0

1

Cada entidade da classe “A” está associada a zero ou a uma única entidade da classe “B”.

0

Várias

Cada entidade da classe “A” está associada a zero, a uma ou várias entidades da classe “B”.

A B

A B

A B

A B



47

EXEMPLO: A) A cada empregado deve, obrigatoriamente, estar associado um único departamento.

B) A cada departamento deve, obrigatoriamente, estar associado pelo menos um

empregado.

C) A cada dependente deve, obrigatoriamente, estar associado um único empregado.

D) A cada empregado podem estar associados vários dependentes.

E) Um determinado empregado pode não estar associado a nenhum dependente.

F) A cada cônjuge deve, obrigatoriamente, estar associado um único empregado.

G) A cada empregado pode estar associado um único cônjuge.

H) Um determinado empregado pode não estar associado a nenhum cônjuge.

DEPARTAMENTOS EMPREGADOS

DEPENDENTES

CÔNJUGES



48

♦ Pode-se ainda apresentar no DER os atributos de cada classe de entidades: EX: As linhas que apontam para atributos que fazem parte do identificador da classe de

entidade têm, na sua extremidade, um círculo cheio, enquanto que as linhas que apontam

para atributos que não fazem parte do identificador terão um círculo vazio. O identificador

da classe de entidades EMPREGADO é o atributo Num-Matrícula.

CLASSIFICAÇÃO DAS ENTIDADES: Uma maneira de se classificar as entidades, será feito em função dos atributos usados para identificá-los. Tudo que existe ou existe em si e por si é concebido ou deve ser concebido a partir de outras coisas. Assim, as entidades e suas classes podem ser classificadas em três tipos distintos: primária, dependente ou associativa. ♦ ENTIDADE PRIMÁRIA – quando existe em si e por si é concebida, isto é, aquilo cujo conceito não carece do conceito de outra a partir do qual deva ser formado. Sua identificação é feita, exclusivamente, através de seus próprios atributos. EX: Uma entidade da classe ALUNO precisa de um único atributo para identificá-lo, que é o número de matrícula. EX: Uma entidade da classe DEPARTAMENTO pode ser identificada pelo código do departamento ou pela sigla do departamento.

EMPREGADOSNum-matrículaNome-empEnder-emp



49

♦ ENTIDADE DEPENDENTE – quando não existe por si só e sua existência está condicionada à existência de uma única outra entidade da qual ela depende. A entidade dependente pode ser chamada de entidade fraca. Sua identificação completa só pode ser feita através de seu relacionamento com outra entidade. EX: ⇒ O identificador para a entidade da classe FUNCIONÁRIO é Matr-func e o identificador para a entidade da classe FILHO DE FUNCIONÁRIO é formado por Matr-func, juntamente com Nome-filho. ♦ ENTIDADE ASSOCIATIVA – quando não existe por si só e sua existência está condicionada à existência de duas ou mais entidades, a partir das quais ela é concebida. Resulta da associação entre duas ou mais entidades. Seu identificador é formado pela concatenação dos identificadores das entidades que se associam para lhe dar origem. EX: ⇒ O identificador para entidade da classe ALUNO é Matr e o identificador para uma entidade da classe CURSO é Cód-curso. O identificador para a entidade APROVEITAMENTO é formado por Matr juntamente com Cód-curso; o atributo NOTA não faz parte do identificador e representa a nota obtida por um determinado aluno em um determinado curso.

FILHOS DE FUNCIONÁRIOS

FUNCIONÁRIOS

Matr-func

Nome-func

Ender-func

Matr-func

Nome-filho

Data-nasc

D

ALUNOS APROVEITAMENTOS CURSOS

A A



50

CLASSIFICAÇÃO DOS RELACIONAMENTOS: Um relacionamento é sempre uma associação entre duas e somente duas classes de entidades. Ele é sempre estabelecido através dos valores (domínio) de atributos comuns às duas classes de entidades que se interrelacionam.

EX: O relacionamento do DER entre as entidades das classes EMPREGADO e

DEPARTAMENTO é estabelecido pelo atributo Sigla-depto, ou seja, por exemplo, se a

sigla do Depto. Do Empregado de Matrícula número 1234 é DDS, então o Departamento

DDS deve ser uma das entidades da classe DEPARTAMENTO.

♦ RELACIONAMENTO DO TIPO DEPENDÊNCIA – Ocorre quando temos um

relacionamento entre uma determinada classe de entidades e outra classe que dela seja

dependente.


EMITENTES NOTAS-FISCAIS

D



51

♦ RELACIONAMENTO DO TIPO ASSOCIATIVO – Ocorre entre uma entidade

associativa e cada uma das entidades que deram origem a sua formação.

Para que exista uma classe de entidade associativa, é condição necessária que esta

possua pelo menos um atributo que não lhe seja identificador, é o caso de Qtde-horas-

trabalhadas que só ocorre na entidade ALOCAÇÃO.

♦ RELACIONAMENTO DO TIPO CATEGORIA A classe de entidades mais geral representa a união das subclasses obtidas por um tipo

de categorização.

No exemplo, podemos dizer que estamos particionando o cinjunto de funcionários por um

tipo de categorização denominado cargo. Assim, a classe de entidades FUNCIONÁRIO

possui apenas os atributos que são comuns a todos os funcionários, enquanto que nas

subclasses ENGENHEIRO, DIGITADIO e MOTORISTA, além dos atributos comuns a

qualquer funcionário, temos ainda os atributos exclusivos às suas categorias.

PROJETOS ALOCAÇÕES EMPREGADOS

A A

ENGENHEIROS FUNCIONÁRIOS

DIGITADORES

MOTORISTAS

C

C

C



52

♦ RELACIONAMENTO DO TIPO PAPEL

É um caso particular do relacionamento do tipo Categoria. Ocorre quando uma

determinada classe de entidades é particionada por um tipo de categorização que a divide

em apenas duas subclasses, de acordo com o seguinte critério: um grupo de entidades

que possui determinadas características e outro que não as possui.

♦ RELACIONAMENTO DO TIPO NORMAL

Quando o relacionamento entre classes de entidades não pode ser enquadrado em

nenhum dos outros quatro, trata-se de um relacionamento do tipo normal.

INSTRUTORES FUNCIONÁRIOS

GERENTES

ACIONISTAS

P

P

P

TREINANDOSP




53

ANÁLISE ESSENCIAL

Análise Estruturada •A análise estruturada é uma abordagem sistêmica para fazer a análise de um sistema de modo a produzir a uma especificação funcional. •A especificação funcional define as funções e estruturas de dados que constituem o sistema. •A análise estruturada usa técnicas: gráficas, simples, modulares, complementares. •É necessário que o analista saiba se comunicar com os clientes buscando garantir clareza e entendimento dos requerimentos colocados. ANÁLISE ESSENCIAL

• Considera os eventos como a pedra fundamental dos sistemas, e determina que a especificação de um sistema deve começar pela identificação dos eventos que é representada pela LISTA DE EVENTOS

• Pontos de Vista: – Abordagem => funções, dados, controle – Grau de Abstração => nível essencial

nível de implementação

• Modelo Essencial Apresenta o sistema em um grau de abstração independente de restrições tecnológicas. Corresponde ao modelo lógico proposto da análise estruturada.

• Modelo de Implementação Apresenta o sistema em um grau de abstração dependente de restrições tecnológicas, sendo derivado do modelo essencial. Corresponde ao modelo físico proposto da análise estruturada.



54

VANTAGENS DA ANÁLISE ESSENCIAL Começa pelo modelo essencial, o que corresponde ao modelo lógico proposto da análise estruturada.

– Aborda as três perspectivas do problema (funções, dados e controle). – Particiona o sistema em eventos. – Permite a construção dos modelos de dados e de funções em paralelo.



55

ANÁLISE DE EVENTOS Um sistema é formado por um conjunto de eventos estimulados através de fluxos de dados (estímulos), que produzem as respostas apropriadas.

Eventos

Estímulos

Sistema

Respostas

RespostasEntidades Externas

Depósitos

( E )

( I )

EVENTO é um acontecimento do mundo exterior, que determina, obrigatoriamente, uma resposta do sistema.

– Estímulo é a conseqüência da ocorrência do evento. É o que chega ao sistema e ativa a execução de uma função (fluxo de dados).

– Resposta é o resultado gerado pelo sistema, em função de um estímulo. Pode ser: fluxo de dado para entidade externa

mudança de estado (atualização) em dep. de dados EXEMPLO DE EVENTOS

– Secretaria cadastra os cursos; – Cliente entrega pedido; – Vendedor efetua venda; – Relatório de vendas é emitido; – Gerência autoriza compra; – Nível de ressuprimento é atingido.

TIPOS DE ESTÍMULOS

– Fluxo de dados – Fluxo de controle – Temporal



56

Os eventos são classificados de acordo com o tipo de estímulo que enviam ao sistema

Evento orientado por fluxo de dado

– O estímulo é a chegada ao sistema de um fluxo de dado enviado por uma entidade externa.

– Obrigatoriamente deve ser gerada uma resposta. – Sujeito + verbo transitivo (voz ativa) + complemento verbal – Exempos:

• Cliente paga prestação • Cliente cancela pedido

Evento orientado por controle

– O estímulo é a chegada ao sistema de um fluxo de controle, oriundo de uma entidade externa, ou de uma função interna do sistema.

– Obrigatoriamente deve ser gerada uma resposta. – Sujeito + verbo transitivo (voz ativa) + complemento verbal – Sujeito + verbo (voz passiva) – Exempos:

• Diretoria autoriza compra • 8º cheque é emitido

EVENTO ORIENTADO POR TEMPO (TEMPORAL) O estímulo é a chegada ao sistema da informação de ter decorrido um determinado intervalo de tempo.

– Obrigatoriamente deve ser gerada uma resposta. – Substantivo + verbo no infinitivo + complemento verbal) – Exemplo: ....... Mensalmente deve ser gerado quais os clientes devedores ......

• relatório de devedores é gerado FLUXOS E PROCESSOS DE CONTROLE Um fluxo de controle pode ser originado ou de uma entidade externa ou de um processo interno ao sistema.

– Um processo de controle não modifica dados. Suas entradas e saídas são fluxo de controle.

– Os fluxos e processos de controle não são representados no DFD tradicional. – Para os casos em que o entendimento dos processos de controle seja fundamental

para o entendimento do sistema, pode ser possível a utilização de DFD’s estendido.



57

FLUXOS E PROCESSOS DE CONTROLE

Gerar relatórioinadimplentes

Cliente

Saldo Bancário

Clientes

R-clientes-GRI

Inf-Saldo

R-saldo

Ban

cário

-GRI

A LISTA DE EVENTOS Lista de Eventos sob a forma de Tabela

– Uma forma bem elaborada de apresentar a lista de eventos, é sob a forma de uma tabela.

– As colunas são as seguintes:

RESPOSTAAÇÃOESTÍMULOTIPODESCRIÇÃOEVENTONO

ANÁLISE ESSENCIAL



58

O MODELO ESSENCIAL Descreve o Sistema de maneira independente de restrições tecnológicas = > tecnologia perfeita.

– Elabora o modelo ideal, descrevendo quais os requisitos que o sistema deve atender, sem se preocupar em como o sistema vai atender.

– É composto de dois modelos: • Modelo Ambiental • Modelo Comportamental

COMPOSIÇÃO DO MODELO ESSENCIAL - Modelo Ambiental => Voltado para fora do sistema. Mostra a interação do sistema com os elementos externos a ele. - Modelo Comportamental => Voltado para dentro do sistema. Mostra como o sistema deve reagir aos estímulos oriundos do ambiente externo. O MODELO AMBIENTAL Os componentes do Modelo Ambiental são:

Diagrama de Contexto do Sistema Declaração dos Objetivos do Sistema Lista de Eventos que afetam o Sistema

Normalmente, uma boa seqüência para se chegar a cada um dos componentes do modelo ambiental seria: construir a lista de eventos, desenhar o diagrama de contexto, e finalmente, elaborar a Declaração de Objetivos do Sistema. LISTA DE EVENTOS DO SISTEMA

• As finalidades de um sistema são atender a determinadas necessidades, que são decorrentes de eventos que ocorrem no mundo exterior ao sistema.

• A construção da Lista de Eventos está intrinsecamente ligada às finalidades de um sistema.

DIAGRAMA DE CONTEXTO DO SISTEMA

• O objetivo do Diagrama de Contexto é representar o sistema por um único processo e suas interações com as entidades externas.

• A construção do Diagrama de Contexto é feita a partir da lista de eventos e baseada nos

estímulos e resposta aos eventos.



59

E1 P1F1 (R1)

EVENTO 1E1 P1F1 (R1)

EVENTO 1

E2 P2F2

R2E3EVENTO 2

(R3)E2 P2

F2

R2E3EVENTO 2

(R3)

E3 P3F3

R6E1

(R4)

(R5) EVENTO 3

E3 P3F3

R6E1

(R4)

(R5) EVENTO 3

EntidadeFluxo

Processo

Resposta

E1F1

E2

F2

R2E3

F3

R6 SISTEMAE1

F1

E2

F2

R2E3

F3

R6 SISTEMA



60

DECLARAÇÃO DOS OBJETIVOS

• A Declaração dos Objetivos do Sistema deve ser elaborada em poucas frases, simples e precisa, em linguagem destituída de jargão técnico.

• Deve concentrar-se em o que o sistema deve fazer, sem se preocupar em como será deve ser feito.

• Sua construção é facilitada se forem considerados a Lista de Eventos e o Diagrama de Contexto do Sistema.

MODELO COMPORTAMENTAL Os componentes do Modelo Comportamental são:

DFD’s particionados por evento DFD de nível zero Devemos ter em mente que o objetivo do modelo comportamental é entender o funcionamento interno do sistema. Para isso, devemos verificar quais são as bolhas primitivas, para que possamos chegar às mini-especificações dos processos primitivos. PARTICIONAMENTO POR EVENTOS DFD’s particionados por Evento

• Também conhecido como DFD de resposta aos eventos. Para cada evento, representar os processos, as entidades externas, os depósitos de dados, os fluxos e respostas, na forma de um DFD.

• A inclusão dos depósitos de dados se faz necessária porque os eventos podem ser assíncronos, ou seja, os dados produzidos por um evento não são necessariamente utilizados no mesmo instante por outro evento.

EVENTO 1

No evento Descriçãoevento

Tipo Estimulo Ação Resposta

EVENTO No 2

Noevento

Nomeevento

tipo Estímulo Ação Resposta

2ClienteCancelapedido

FCancelar pedido

Dados cancelamento

E :Pedidocancelado

I:pedidos-cp



61

clienteDadoscancelamento

G=pedidios-cp

pedidos

Pedidocancelado

cliente

Cancelarpedido

2

EVENTO No 6

Noevento

Nomeevento


6 C

verificar PedidoEm atraso

----------------- E :Pedido ematraso

PedidosEm atrasoSão verificados

R=pedidos-vpa

pedidos

Pedido ematraso

clienteVerificarPedidoEm atraso

6



62

EVENTO No 7

Noevento

Nomeevento


7 T

verificar Pedidoatendidos

----------------- E :Pedido atendidos

PedidosAtendidosNo dia

R=pedidos-vpa

pedidos

Pedido atendidos Gerente

Comercial

VerificarPedidoatendidos

6

ANÁLISE ESSENCIAL

E1 P1 F1 (R1)

EVENTO 1(D1)

E2 P2 F2

R2 E3 EVENTO 2

(R3)

(D2)

E3 P3 F3

R6 E1

(R4)

(R5) EVENTO 3(D1)

(D3)



63

Entidade

FluxoResposta

Depósito

Processo

Entidade

FluxoResposta

Depósito

Processo

D.F.D. NIVEL ZERO

• A Análise Estruturada preconiza uma abordagem de projeto top-down, ou seja, partindo-se do Diagrama de Contexto chega-se ao DFD de nível zero e aos DFD’s de nível mais baixo, pela explosão dos processos.

• A Análise Essencial utiliza a abordagem midle-out. Parte de uma situação intermediária (o

DFD particionados), para os níveis mais baixos (abordagem top-down) e para o Diagrama de Nível Zero (abordagem botton-up)

DFD Nível Zero

Entidade

FluxoResposta

Depósito

Processo

Entidade

FluxoResposta

Depósito

Processo

• Na prática, como as AÇÕES realizadas pertencem a eventos diferentes, uma maneira bem coerente de verificar a ligação entre eles é através dos depósitos de dados que são acessados e que na realidade se transformam na espinha dorsal do SISTEMA.

E1 P1F1 (R1)

E3

P2F2

R2

E2

(R3)

P3F3

R6

(R5)

(R4) (D1)

(D2)

(D3)

Apostila de An- ¦álise Funcional de Sistemas

Documents

Transcript of Apostila de An- ¦álise Funcional de Sistemas