fasp - ams - 02 - análise essencial de sistemas

8/9/2019 FASP - AMS - 02 - Anlise Essencial de Sistemas

1/30

MANUAL TCNICO

AnliseEssencial deSistemas

Volume

1


2/30

ndice analtico

C A P T U L O 1

Sistemas 2

A Captao da Essncia 2

A Formao do Pessoal de Sistemas 3

A Cultura do Usurio 3

A Comunicao Analista X Usurio 3

A Documentao 4

Modelos 4

Ferramentas de Modelagem 5

Ferramentas de Modelagem Tradicionais 5

Fases do Desenvolvimento de Sistemas 5

Tabela de Produtos 10

C A P T U L O 2

Modelagem de Eventos 11

Algoritimo para Modelagem de Eventos 11

Eventos Relacionados 11

Determinando o Contexto de Sistema 12

Eventos Externos e Eventos Internos 12

Fluxo de Dados e Eventos 12

Documentando o Modelo Ambiental 12

CAPTULO 3

Produzindo o MER a partir da Lista deEventos 14

Eventos Custodiais 14

Anatomia do Processo Essencial 15

Derivando o Modelo de Processos 16

Nivelando o Modelo de Processos 16

O Conceito de Nivelamento 16

Balanceando o Modelo 17

Balanceando entre Projees 18

Balanceamento entre Nveis 18

C A P T U L O 4

Especificao de Composio de Dados 22

Especificao de Elemento de Dados 23

Especificao de Entidades 23

Especificao de Relacionamento 24

Especificao de Processo 24

Consideraes sobre Especificao de

Processo 24

Expresses e Operadores 25

Funes 26

Recebendo e Enviando Fluxos de Dados 26

Criando e Removendo Ocorrncias de

Objeto 26

Encontrando uma Ocorrncia do Objeto 27

Seleo 27

Construes de Repetio 27

BIBLIOGRAFIA 29


3/30

FASPFASPFASPFASP 2222

Os sistemas com os quais ns trabalhamos podem ser classificados como Sistemas deResposta Planejada e possuem as seguintes caractersticas:

H uma necessidade ou oportunidade de negcio que precisa ser atendidano mundo real; o sistema surge como resposta a essa necessidade ouoportunidade.

Todo sistema tem uma finalidade especfica: o que o sistema faz, earmazena, est diretamente relacionado com essa finalidade.

Os sistemas tm de fornecer respostas previsveis: h um conjunto deregras que o sistema deve obedecer, no sentido de responder a eventosexternos ao sistema, de acordo com sua finalidade.

Os sistema so transferveis: as regras que os regem precisam ser escritasde modo que os sistemas possam ser transferidos de um processador paraoutro, quer ele seja automatizado ou humano.

A fronteira do sistema caracterizada pelas entradas/origens dos dados epelas sadas/destinos das informaes; a determinao da fronteira de

um sistema uma boa ferramenta para caracteriz-lo.

O interior do sistema consiste de atividades e de dados armazenados, queso as engrenagens que respondem a eventos externos, de acordo com asfinalidades do sistema.

A essncia do sistema independe da tecnologia utilizada para implement-lo. Por exemplo: o sistema de contas correntes do Banco do Brasil omesmo desde sua fundao h mais de um sculo. O que tem mudado,muito rapidamente, a tecnologia de implementao do sistema.

O trabalho de anlise de um sistema consiste em conseguir captar a sua essncia: osfatos que ocorrem fora do sistema que causaro uma ao do sistema como resposta.Esse trabalho deve procurar filtrar todas as condies e caractersticas deimplementao, em busca da sua essncia. Essencial aquilo que o sistema deve ter.Se no tiver, o sistema no conseguir atingir seus objetivos.

Captulo

1Sistemas

A Captao daEssncia


4/30


Em geral, os profissionais de informtica so formados em Economia, Administraode Empresas, Engenharia, etc.. Em seus cursos de graduao tiveram contato com ainformtica em temas como Clculo Numrico.

A formao efetiva desses profissionais d-se por osmose dentro das empresas, portroca de experincias com profissionais mais tarimbados. Quando h treinamento,este executado pelo fabricante do equipamento utilizado e em ferramentas desoftware existentes e utilizadas na instalao. Dessa forma, depois de alguns anos, oprofissional promovido categoria senior e possui vasto conhecimento emsoftwares bsico, habitualmente denominados por trs ou quatro letras. As tcnicas deanlise de sistemas, de levantamento de dados, de projeto de sistemas, de codificao ede testes praticadas so aquelas que os outros j praticavam.

Aliado a esse fato, existe outro: o profissional de informtica, em geral, fortementereacionrio e resistente a novas tcnicas que causem qualquer mudana em sua rotinadiria e em seu comportamento pessoal.

No podemos esquecer que a informtica uma cincia nova, que est em constantee rpida evoluo.

Como promotor da entrada da tecnologia na empresa, o profissional de informticano deve ser ele prprio reativo s novas tecnologias.

Os usurios tm a formao de acordo com sua rea de atuao. Assim, claro que oDepartamento Jurdico est repleto de advogados, a Contabilidade formada porcontadores e o Departamento Financeiro comandado por economistas.

Os usurios, ao longo dos anos, tm tido algumas ms experincias com a informtica.Sistemas desenvolvidos para eles que no funcionaram adequadamente, sistemas quenunca ficaram prontos, sistemas que no se adaptam s mudanas em sua rea,sistemas que acabam acrescentando trabalho ao seu dia-a-dia. Apesar disso, ele aindaacredita na informtica e quer, cada vez mais, apoio de sistemas em suas atividades. Odifcil conseguir que o pessoal l da informtica o atenda. Por isso vemos, com tantafreqncia, usurios montando verdadeiros CPDs paralelos para terem um mnimode apoio informatizado em seus negcios.

Os usurios conhecem o problema, os negcios, muito melhor que os analistas. Osanalistas conhecem tcnicas para resolver os problemas. O trabalho de anlise deveproduzir uma soluo para o problema. Geralmente a linguagem do usurio

impregnada de termos do vocabulrio tcnico do assunto do problema que os analistasno entendem completamente. Por outro lado, ao expor a soluo, os analistasutilizam uma linguagem tcnica derivada do informatiqus que o usuriodesconhece.

A Formao do

Pessoal de

Sistemas

A Cultura do

Usurio

A Comunicao

Analista X Usurio


5/30


A qualidade da soluo fortemente influenciada pela qualidade de sua validao pelosusurios. Ser que ns entendemos corretamente o problema? Ser que a soluo vivel?

importante que o trabalho seja feito em conjunto e que se utilize de vocabulrioprprio, comum a todos os participantes. Analistas e usurios trabalhando no mesmotime, em busca da melhor soluo. Trabalhar junto leva ao entendimento, melhorcomunicao e sinergia.

Para possibilitar essa comunicao h a necessidade de documentarmos oentendimento obtido. Essa documentao servir de base, num momento posterior,ao trabalho de manuteno do sistema j instalado.

Para que a documentao seja til, importante que ela seja produzida durante o

trabalho, que seja completa e que esteja atualizada. Uma documentao desatualizadano serve para nada.

Sistemas com documentao incompleta ou desatualizada precisam de arquelogos,especialistas que vasculham fragmentos de cdigo, arquivos e dumps com o objetivode construir hipteses a respeito de pra que serve isso? no sistema. Alm dosarquelogos, o sistema precisar ser atendido por pediatras, profissionais que sochamados a qualquer hora, principalmente de madrugada ou aos fins de semana, todavez que o sistema passa mal.

Um modelo uma representao abstrata de algo real. O modelo tem o objetivo deimitar a realidade para possibilitar que esta seja estudada quanto ao seucomportamento.

Tradicionalmente, a engenharia tem empregado modelos em escala, plantas, desenhosde circuitos, prottipos.

O uso de modelos torna o estudo mais barato e seguro: muito mais rpido e baratoconstruir um modelo que construir a coisa real.

O objetivo do modelo mostrar como ser o sistema, para permitir sua inspeo everificao, de modo a poder receber alteraes e adaptaes antes de ficar pronto.

Qualquer modelo reala certos aspectos do que est sendo modelado em detrimentode outros.

A ferramenta que usamos para modelar influi diretamente na forma como pensamossobre a realidade e determina quais aspectos sero mostrados e quais ficaroescondidos.

A Documentao

Modelos


6/30


Para modelarmos sistemas, necessitamos de ferramentas com as seguintescaractersticas:

Grficas, com apoio de textos, como um mapa: legveis, concisas e

padronizadas. A parte grfica particiona o sistema em componentesinterrelacionados, sem as restries de um texto linear. A parte textualdescreve os componentes e suas interconexes;

Particionveis, do geral para o especfico, como um atlas geogrfico,tornando o modelo mais fcil de entender. Precisamos ser capazes de ter aviso geral do sistema sem nos preocuparmos com detalhes e, termos aviso do detalhe sem perdermos a noo do todo;

Rigorosas, como as escalas de uma planta. O modelo do sistema deve serpreciso, sem erros, incompletudes e redundncias. Mas deve ser flexvel,

fcil de mudar, pois o sistema est sempre em constante evoluo;

Capazes de predizer o comportamento do sistema, como umprottipo. O modelo deve ser capaz de nos dizer o que bom e o que ruim no sistema, em termos objetivos, antes que o sistema sejaimplementado. O modelo deve nos permitir simular o comportamento dosistema.

Capazes de mostrar os aspectos crticos do sistema, como fotos devrios ngulos, com simplicidade. Cada modelo deve ser uma projeo dosistema em um espao simplificado.

As ferramentas tradicionais de modelagem de sistemas levam a modelos redundantes,contraditrios e difceis de checar quanto sua completude e preciso. necessrioque utilizemos ferramentas de modelagem substancialmente diferentes daquelasanteriormente utilizadas pelos mtodos tradicionais.

O Desenvolvimento de sistemas com Anlise Essencial se d sempre de maneira a seobter mais conhecimento e qualidade a cada passo, atravs de refinamentos sucessivos.O primeiro passo construir o Modelo do Ambiente do sistema, composto peloDiagrama de Contexto e pela Lista de Eventos Externos. A finalidade desse modelo determinar a abrangncia do sistema pela especificao dos eventos que motivam a suaao, das entradas e suas origens e das sadas e seus destinos.

A partir da Lista de Eventos Externos, do Modelo do Ambiente, deve ser construdo oModelo do Comportamento do sistema, que especifica de que forma o sistema estruturado em termos de dados e funes para atingir aos objetivos estabelecidos epara responder aos eventos do Modelo do Ambiente. A Figura SDS 1 - O

Ferramentas de

Modelagem

Ferramentas de

Modelagem

Tradicionais

Fases do

Desenvolvimentode Sistemas


7/30


desenvolvimento de sistemas com Anlise Essencial, mostra o contexto dodesenvolvimento de sistemas visto, ele prprio, como um sistema.

Figura SDS 1 - O desenvolvimento de sistemas com Anlise Essencial

DesenvolverSistemas

PessoalInfo

Pessoal

PessoalInfo

Modelo Essencial

Modelo deImplementao

Conhecimento daTecnologia de

Automao

Conhecimento doAssunto do Sistema

Resties deImplementao

Objetivos doSistema

O desenvolvimento de sistemas interage com o pessoal de informtica, que detm oconhecimento da tecnologia de automao; com o usurio, responsvel pela definiodos objetivos e restries do sistema e profundo conhecedor do assunto e do ambientedo sistema. A empresa a beneficiria do trabalho, recebendo o produto dodesenvolvimento: o sistema.

A Figura 0 - Desenvolver Sistemas, mostra os dois principais processos dodesenvolvimento de sistemas.

Figura 0 - Desenvolver Sistemas

1.Criar oModelo

Essencial

2.Derivar oModelo de

Implementao

Modelo Essencial


Objetivos do Sistema

Restries deImplementao

Conhecimento daTecnologia de

Implementao

Modelo de

Implementao


8/30


A Figura 1 - Criar o Modelo Essencial detalha o processo de modelagem essencial.Em primeiro lugar fazemos a modelagem do Ambiente do Sistema: a quais eventosexternos o sistema deve responder; quais os fluxos de dados fornecidos pelo ambienteao sistema; de onde vm esses dados; quais as informaes que o sistema deve

produzir; quem so os usurios dessas informaes.

Figura 1 - Criar o Modelo Essencial

1.

Modelar o

Ambiente do

Sistema

2.

Derivar o

Modelo de

Implementao

Modelo do Ambiente



Conhecimento do

Assunto do

Sistema

Modelo do

Comportamento

Modelo Essencial

Modelo de Ambiente

Modelo de Comportamento

A partir do Modelo do Ambiente derivado o Comportamento do Sistema: quais so

as estruturas de dados e quais so os processos internos do sistema necessrios paragarantir que o sistema atinja seus objetivos.

A Figura 1.1 - Modelar o Ambiente do Sistema, mostra que essa tarefa feita peladeterminao do Contexto do Sistema e pela identificao de Eventos Externos. Essastarefas so executadas em conjunto, uma subsidiando a outra.


9/30


Figura 1.1 - Modelar o Ambiente do Sistema

Conhecimento do

Assunto do Sistema

1.1.1Determinar o

Contexto do

Sistema

1.1.2

Identificar os

Eventos

Essenciais

Diagrama de

Contexto Preliminar


Conhecimento do

Assunto do

Sistema

Lista de Eventos

Preliminar

Lista de Eventos

Diagrama de

Contexto


Modelo de Ambiente

Diagrama de Conrtexto

Lista de Eventos Externos

Especificao de Estmulos e Sadas

A figura 1.2 - Derivar o Comportamento do Sistema - ilustra que essa tarefa constituda de trs partes: A modelagem dos dados, a modelagem das atividadesessenciais e a especificao dos detalhes em um dicionrio de dados.

Figura 1.2 - Derivar o Comportamento do Sistema

Conhecimento do

Assunto do

Sistema


Modelo de Comportamento

Modelo Entidades e Relacionamentos

Modelo de Atividades Essenciais

Especificaes Textuais

Conhecimento do

Assunto do Sistema

1.2.2

Modelar

os Dados

Armazenados

1.2.1Modelar as

Atividades

EssenciaisDFD

Preliminar

MER

Preliminar

Especificaes

Textuais

Modelo de

Ambiente

1.2.3

Especcificar

Detalhes

DFD

(Atividades Essenciais)MER

Preliminar



10/30


A Figura 2 - Derivar o Modelo de Implementao, consiste, em primeiro lugar, nadeterminao do Modelo de Processadores, onde as atividades essenciais so alocadasa processadores, que so os agentes que executaro cada uma das atividadesimplementadas, fisicamente(entenda-se, aqui, por exemplo, computadores e pessoas);

na derivao do Modelo de Tarefas, onde as atividades so organizadas, porprocessador, em seqncias ou grupos de operao que fazem trabalho til para ousurio (tarefas), e na derivao do Modelo de Arquitetura de Cdigo, onde as mesmasatividades so divididas em objetos ou mdulos funcionais (dependendo do ambientede hardware), com o mximo de coeso interna e o mnimo de interdependncia entremdulos.

Figura 2 - Derivar o Modelo de Implementao

Conhecimento da

Tecnologia de Automao



Modelo de Implementao

Modelo de ProcessadoresModelo de Tarefas

Modelo de Arquitetura de Cdigo

Conhecimento daTecnologia de Automao

2.1Derivar o

Modelo deProcessadores

2.2

Modelo de

Tarefas

Moelo deProcessadores

Modelo deArquitetura de Cdigo

ModeloEssencial

2.3Derivar o

Modelo deArquiteturade Cdigo

Modelo deTarefas

Conhecimento daTecnologia de Automao



11/30


12/30

C O N S T R U I N D O O M O D E L O A M B I E N T A L


A construo do Modelo Ambiental se d atravs da Definio do Contexto doSistema e da Modelagem da Lista de Eventos Externos.

Um evento externo algo que ocorre no ambiente (fora dos limites do sistema) e queprovoca uma resposta do sistema, como conseqncia. Um evento pode ser sinalizadopor um fluxo de dados ou ser localizado em um determinado instante no tempo.

Analisar eventos , basicamente, identificar fatos que ocorrem no meio ambiente queinterage com o sistema e que exigem uma resposta do mesmo. Esta resposta pode ser,

por exemplo, o armazenamento de uma informao ou a produo de um resultado.

Analise o ambiente do sistema e ponha no papel todo fato que, a princpio, pareadeterminar uma ao do sistema. Cada evento deve ser escrito em uma orao.Lembre-se que uma orao uma construo gramatical que expressa uma idiacompleta. Deve possuir um sujeito, um verbo e um objeto.

Para cada evento identificado, responda as perguntas abaixo. A resposta a essasperguntas levar identificao de outros eventos. Para cada um desses novos eventos,responda novamente as perguntas. Repita esse processo exaustivamente, at que ociclo se feche.

Existe algum evento que seja uma variao significativa do eventoidentificado? Normalmente esses eventos podem ser escritos com asmesmas palavras do evento original, trocando-se apenas o verbo.

Existe algum evento oposto ao evento identificado? Por exemplo: opostoa vender comprar; oposto a pagar receber (antnimos).

H algum evento negativo do evento identificado? Consiste na negao doevento. Negativo de pagar no pagar.

Existe algum evento que deve preceder o evento identificado?Normalmente esses eventos so pr-requisitos do evento em questo. Porexemplo, para que seja feito um pagamento, necessrio que tenha sidofeita uma compra.

Captulo

2Modelagem de

Eventos

Algoritmo para

Modelagem de

Eventos

Eventos

Relacionados


13/30



H algum evento que seja conseqncia do evento identificado? Esteseventos devem acontecer, como conseqncia, aps o evento em questo.

O Diagrama de Contexto a representao grfica doAmbiente do Sistema. Nele,o sistema como um todo representado por um crculo, com o seu nome. Osusurios (fornecedores e receptores de informaes) so representados por retngulos,rotulados pelo nome do agente externo e as informaes trocadas so as setasidentificadas pelo nome do pacote de informaes que fluem entre o sistema e seususurios.

Na modelagem do ambiente,preocupamo-nos apenas com oseventos externos, isto , aquelesque ocorrem fora do sistema.

Eventos internos sorepresentados por oraes onde osujeito o sistema ou porrespostas do sistema a eventosexternos.

Nem todo evento sinalizado porum fluxo de dados. Os eventos temporais, por exemplo, no possuem um fluxo dedados de entrada como estmulo.

Nem todo evento possui um fluxo de sada correspondente. Um evento pode causar,apenas, que algum dado seja armazenado.

Eventos diferentes podem estar associados a um mesmo fluxo de dados.

O Modelo Ambiental deve ser documentado atravs das seguintes especificaes:

Objetivos do Sistema. uma lista de objetivos que o sistema deveatender. Essa lista ser a baliza que nortear o conceito de essencial ouno, onde essencial tudo aquilo que necessrio para atingir umdeterminado objetivo.

Lista de Problemas. Essa lista ajudar na construo da Lista de

Objetivos. Os objetivos de um sistema podem ser de duas categorias: osque so ligados s necessidades futuras do usurio e os que so ligados soluo de problemas que o usurio enfrenta atualmente.

Lista de Eventos Externos. Constar da especificao, para cada evento,do fluxo de estmulo e sua origem, da resposta que o sistema deve dar aoevento e do fluxo de sada produzido pelo sistema, com seu destino.

Determinando oContexto do

Sistema

Eventos Externose Eventos Internos Manuten o

Sistema

Bye Bye Brazil

Dados de Filme

Fluxos de Dados eEventos

Documentando o

Modelo Ambiental


14/30



Diagrama de Contexto. Consiste na representao grfica dos elementosidentificados na Lista de Eventos Externos, representando as origens eseus estmulos, aos destinos e suas sadas, alm do sistema que os recebe /produz, sem nenhuma especificao de detalhes.

Dicionrio de Dados. Uma entrada para cada dado identificado comofluxo de estmulo ou de sada do sistema (Ver Captulo EspecificaesTextuais).


15/30

E S P E C I F I C A E S T E X T U A I S


Aps a determinao do Modelo de Ambiente, deve ser derivado o Modelo deDados do Sistema, atravs da tcnica de Modelagem de Entidades eRelacionamentos (ver manual especfico).

A modelagem dos dados determina os depsitos de dados, que o sistema utilizar paracustodiar as informaes que lhe so essenciais.

Os dados sero derivados do Modelo de Ambiente e, portanto, para passar aoprximo item, tenha-o mo.

Para cada evento do Modelo de Ambiente, produza o MERconforme a seqnciaabaixo:

Evento = o sujeito e o objeto do evento so candidatos a entidades e overbo, candidato a relacionamento.

Estmulo = verificar se os dados devem ser armazenados e onde (sujeito,objeto ou outra entidade).

Ao / Resposta = conhecimento do sistema (regras); quais Entidadesou Relacionamento so criados, usados, modificados ou removidos

Sada = verificar onde (Entidade ou Relacionameto) os dados devem serobtidos.

Obs.: Lembrar que Eventos Temporais no tm estmulo e nem sempre so escritoscom sujeito, verbo e objeto.

Os Eventos Essenciais so divididos em dois tipos:

Fundamentais - tm a ver com o negcio do sistema, o dia-a-dia comumdo(s) usurio(s);

Custodiais - tomam conta da base de informaes da organizao,garantindo o funcionamento das respostas planejadas para os EventosFundamentais.

Captulo

3Produzindo o MER

a partir da Lista de

Eventos

Eventos

Custodiais


16/30


17/30



Com o Modelo de Ambiente e o Modelo de Dados mo, faa os seguintes passos,para cada evento e respectivos desenhos em folha nica.

Passo 1: Identifique os Processos = para cada evento, crie umProcesso (representado por uma bolha no DFD) rotulado com o nomeda resposta que o sistema d ao evento.

Passo 2: Adicione os Fluxos de Dados = adicione o Fluxo deEstmulo, representando-o como uma seta entrando no Processo eadicione o(s) Fluxo(s) de Sada(s), representando-o(s) como seta(s)saindo do Processo.

Passo 3: Adicione os Depsitos de Dados = considere a lgica do

Processo e adicione os Depsitos de Dados criados, removidos ouatualizados pelo processo, representando-os por duas linhas horizontais,com o seu nome tirado do Modelo de Dados e por uma seta saindo doprocesso e entrando no referido depsito. Adicione os Depsitos deDados lidos pelo processo, representando-os por duas linhas horizontaiscom o seu nome tirado do Modelo de Dados e por uma seta saindo dodepsito e entrando no processo.

O modelo produzido ter tantos processos quantos forem os eventos. bvio queesse modelo no bom para apresentao, validao e compreenso do sistema. Porisso, ele dever ser nivelado.

Nivelar o Modelo de Processos consiste em organiz-lo em vrios DFD's, ondecada um deles apresenta um determinado nvel de detalhe. Assim, como num atlas,haver um modelo que representa o sistema e outro que representa os subsistemas.Cada processo do DFD nvel 1 (aquele que representa os subsistemas) pode serdetalhado em outro DFD que o considera como se aquele processo fosse o sistema.Este nivelamento deve ser feito at que todos os processos sejam representados emseu mais baixo nvel, ou seja, seu detalhamento feito atravs de especificao delgica de processo, ao invs de por outro DFD.

Um DFD, que representa um conjunto de transformaes graficamente conectadas,pode ser desenhado atravs de uma nica transformao, com o mesmo conjunto deentradas e sadas.

Derivando o

Modelo de

Processos

Nivelando oModelo de

Processos

O Conceito de

Nivelamento


18/30



Vrias transformaes podem ser juntadas em uma nica, num nvel mais alto. Damesma maneira, uma transformao pode ser dividida em um grupo detransformaes, num nvel mais baixo.

O menor nvel de transformaes determina o modelo completo do sistema. Astransformaes de mais alto nvel servem apenas como abreviaes e nos ajudam alidar com a complexidade dos diagramas de mais baixo nvel.

Desde que a nica diferena entre um nvel e outro o grau de detalhe mostrado, sescrevemos especificaes textuais para as transformaes de mais baixo nvel: asprimitivas funcionais.

A organizao do modelo grfico muito mais do que uma questo de convivncia.

Um DFD ou DER complexo pode sobrecarregar o leitor pela apresentao de maisdetalhes do que sua mente pode absorver.

Contexto

Figura 3

Figura 0

1

2

3

Figura 2

2.1

Figura 1

Figura 3.1 Figura 1.3

3.1 3.2

3.3

3.1.1

3.1.2

3.1.3

1.3.1

1.3.2

1.1

1.21.3

Balanceando o

Modelo


19/30



Desde que a correo do modelo depende de sua compreensibilidade, o processo debalanceamento e reviso essencial para assegurar a qualidade do processo dedesenvolvimento de sistemas.

Pesquisas sobre a memria e percepo humanas sugerem que um diagrama quecontenha 7 elementos, com uma variao de mais ou menos 2, ir sobrecarregar amaioria dos leitores.

Uma regra objetiva : um DFD inteligvel um DFD com poucos fluxos de dados,que no deve ter mais que meia dziade transformaes.

O modelo de processos e o modelo de dados esto balanceados quando:

cada elemento de dados, de cada entidade no DER, usado por uma oumais transformaes ou requerido por consultas ad-hoc;

cada relacionamento no DER usado por uma ou mais transformaesou requerido por consultas ad-hoc;

cada elemento de dados, de cada entidade ou entidade associativa no

DER, carregado por uma ou mais transformaes e

cada relacionamento do DER criado por uma ou mais transformaes.

Os modelos de dados e de processos devem fornecer um modelo nico e consistentedo sistema.

Balanceando entre

Projees

Balanceamento

entre Nveis


20/30



Precisamos assegurar que cada nvel do modelo exatamente eqivalente aos demaisnveis.

Regra de balanceamento

Cada processo pai deve ter exatamente as mesmas entradas e sadas que o diagramafilho, que est no nvel imediatamente abaixo.

Balanceamento visual de fluxos

Se ns no nivelarmos os fluxos, obalanceamento ser fcil: a bolha pai e odiagrama filho tero exatamente os mesmosnomes de fluxos.

Balanceamento via especificaes textuais

Quando nivelamos fluxos, usamos asespecificaes textuais (Dicionrio de Dados)para estabelecer a equivalncia dos fluxos pai efluxos filhos.

Balanceando Depsitos de Dados

Um depsito de dados aparece pelaprimeira vez, no nvel em que ele compartilhado entre dois processos. Abaixo desse nvel, o depsitoaparece sempre que for referenciado.

2.a

b

c

d

d's

d's

a

b

x

b

2.1

2.2

2.3

2.

a

b

c

d d's

d's

z

2.1

2.2

2.3

X

y

b

y

W

k

a = x + y + zc = K + w

1.1 1.2x

1.1.11.2.1

x

x

yz

1.1.2 1.2.2


21/30



Depsitos de dados podem ser

nivelados da mesma forma queprocessos e fluxos.

Nivelando o Modelo Essencial

A derivao das projees grficas, a partir da lista de eventos, produz um modelo queno bem particionado.

Para reorganizar o modelo,junte os processos deacordo com os depsitosde dados referenciadospor eles.

1.1 1.2x

1.1.1

1.1.2

1.2.1

1.2.2

a

b

a

b

= a + b


22/30


23/30



Nossa inteno escrever o mnimo de texto, para especificarmos o sistema demaneira formal e rigorosa.

Para isso, vamos, em um Dicionrio de Dados, especificar:

Composio de Dados (Grupos de Dados);

Elementos de Dados;

Entidades;

Relacionamentos e

Processos.

Objetivo

Definir sintaticamente a composio de dados no elementares.

Ocorrncias

Uma para cada depsito de dados e fluxo no elementar em um DFD euma para cada entidade em um DER.

Exemplo

Scios = nmero_scio + endereo_scio + (fone_scio) +(fone_comercial) + CPF_scio + RG_scio

Dados_artsticos = nome_ator + {/participaes/ nome_filme +gnero_filme + nome_personagem + ano_produo}

Preferncia = [cod_filme |ator | gnero | ttulo]

Dados_pessoais_alterados =

Captulo

4

Especificao de

Composio deDados


24/30



Sintaxe

Smbolo Significado

= composto de

+ e

{ } vrias ocorrncias de

[ ] apenas um dentre

qualquer conjunto dentre

| ou

/ / nome (rtulo) de grupo repetitivo

( ) opcional

** comentrio

@ identificador

Objetivos

documentar o significado de cada elemento;

especificar o significado do item;

especificar o domnio do elemento pela enumerao ou especificao deseus limites;

especificar se o elemento discreto ou contnuo e

especificar a implementao fsica adotada em tempo de implementao.

Ocorrncias

uma para cada fluxo elementar no DFD, e

uma para cada elemento em uma especificao de composio de dados.

Objetivos

definir o significado da entidade atravs da descrio de seu papel nosistema;

Especificao de

Elemento deDados

Especificao de

Entidade


25/30



a especificao deve explicitar o critrio de incluso, ou seja, qual a regraou conceito que faz com que um determinado objeto seja consideradocomo pertinente a este conjunto;

deve especificar, tambm, o critrio de excluso: o que faz com que umobjeto deixe de pertencer a este conjunto e

adicionalmente, se adequado, definir tambm os estados que umaocorrncia da entidade pode assumir, atravs dos eventos que a colocamnesses estados.

Ocorrncias

uma por entidade no DER.

Objetivos

descrever o significado do relacionamento e

especificar a cardinalidade e a totalidade do relacionamento.

Ocorrncias

uma por relacionamento no DER.Objetivo

documentar a lgica dos processos.

Ocorrncias

uma para cada processo primitivo funcional.

Fonte : Rpida e Limpa, FG&A

Cada processo deve ser completamente especificado pela ao executada para:

manipular os fluxos de dados de entrada;

produzir os fluxos de dados de sada e

atualizar a memria do sistema.

Especificao deRelacionamento

Especificao de

Processo

Consideraessobre

Especificao de

Processo


26/30



Para produzir especificaes consistentes e sem ambigidades, voc podeusar NRDE's (elementos de dados no armazenados) e atributos. Porexemplo:

cliente.nome,

.endereo

fornecedor_cdigo

Sempre que voc usar um elemento de dados dentro de uma especificao deprocesso, ele ser considerado importado pelo processo. Um atributo tambm considerado importado se fizer parte do dicionrio de dados.

De qualquer maneira, existem casos em que um elemento de dados usado paramanter algum resultado intermedirio exclusivamente dentro do processo. Taiselementos de dados so chamados de elementos de dados locais. Como sugesto,inicie o nome de todos os elementos de dados locais com uma arroba (@ ). Porexemplo:

@@e:= produto.valor * .quantidade

produto.valor = @preco_por_unidade * pedido.quantidade

As expresses so escritas usando a notao pr-fixada convencional de linguagem de

programao. Por exemplo:

x+=y x := x + y

x-=y x := x - y

x*=y x := x * y

x/=y x := x / y

Sempre que voc atribuir um valor a um elemento de dados, ele consideradoexportado pelo processo. Um atributo tambm exportado se ele fizer parte dealgum fluxo de dados recebido pelo processo.

Para comparar valores pode-se usar os operadores =, >>, =,


27/30



Voc pode usar funes usando um nome seguido por parnteses. Se houverargumentos, estes devem estar entre parnteses e separados por vrgula. Por exemplo:

novo_saldo:=ajuste(saldo_anterior, fator_classificador)

No existe pr-definio de funes. Quando se determina uma nova funo, estadeve ser, necessariamente, definida como um processo.

A construo receba (receive) usada para receber um fluxo de dados. Por exemplo:

receba pedido_usurio

Voc pode tambm receber parte de um fluxo de dados. Por exemplo:

receba item de pedido

Neste caso, item deve ser rtulo de um grupo de dados.

A construoproduza (produce) usada para enviar fluxos de dados de sada ou partedeles. Por exemplo:

produza nota_de_autorizao e

produza item de fatura

A construo crie (create) cria novas ocorrncias de um objeto. Por exemplo:

crie cliente.

Como os objetos so inter-relacionados, existe uma forma especial de utilizar aconstruo crie, que, da mesma maneira, especifica os atributos apontadores paraalguns seletores de ocorrncia. Por exemplo:

@BULLET = crie fatura. de cliente., vendedor.

exatamente igual a:

crie fatura.

fatura.cliente := cliente.

fatura.vendedor:= vendedor.

Funes

Recebendo e

Enviando Fluxosde Dados

Criando e

RemovendoOcorrncias de

Objeto


28/30



A construo remova (remove) usada para remover a ocorrncia do objeto corrente.Por exemplo:

remova fatura.

Use a construo encontre (find ) para encontrar uma ocorrncia particular de umobjeto. Por exemplo:

encontre cliente. com .nome = nome_pedido

Voc pode usar uma forma especial da construo encontre, para encontrar aocorrncia do objeto apontada por um outro:

encontre cliente. com cliente. = fatura.cliente

A construo se (if) permite especificar uma seleo entre alternativas:

se cliente.saldo >> 100000crdito:=aprovado

f_se

se cliente.saldo 5000crdito := aprovado

se_no_se cliente.saldo >> 1000crdito := reviso

se_nocrdito:=rejeitado

f_se

A nica construo de iterao permitida apara_cada (for_each ), que pode seraplicada em diversas situaes. O uso mais comum do para_cada para especificarum grupo de aes, que deve ser executado para cada tipo do objeto:

para_cada cliente.classificao := cliente.classe

Encontrando uma

Ocorrncia do

Objeto

Seleo

Construes de

Repetio


29/30



produza item do relatriof_para

Podemos especificar um critrio de classificao:

para_cada cliente. com .tipo = revendedorou .tipo = distribuidor

em_ordem_de cliente.cep ascendente,.nome descendente

classificao:= cliente.classeproduza item do relatorio

f_para

Existe ainda uma forma de classificao manual para objetos inter-relacionados. Porexemplo:

para_cada fatura. de cliente.........

f_para

para_cada fatura. de cliente. com fatura.estado = pendente............

f_para

Finalmente, existe uma forma de manipular itens repetitivos em fluxos de dados de

entrada:

para_cada item em fornecedor_pedido............f_para

Neste caso, item deve ser um rtulo de um grupo de dados.


30/30

R E F E R N C I A S D E A P O I O

1.Anlise Essencial de Sistemas

Stephen M. McMenamim / J. Palmer2.Anlise Estruturada Moderna

Edward Yourdon

3.Anlise Estruturada e Especificao de Sistemas

Tom de Marco

4. Desenvolvendo Sistemas sem Complicao

Paul T. Ward

5.Anlise Estruturada de Sistemas

Chris Gane / Trish Sarson

Bibliografia

Bibliografia

fasp - ams - 02 - análise essencial de sistemas

Documents