aula_024 - modelagem funcional essencial

7/24/2019 Aula_024 - Modelagem Funcional Essencial

1/105

1

Contedo:

Modelagem

Funcional Essencial

Professor:

Geraldo Xexo

DCC/IM/UFRJ

PESC/COPPE/UFRJ

Aula 24


2/105

2

Modelo Funcional

O Modelo Funcional tem como objetivo definir

"o que" o sistema deve fazer, ou seja, as funes

que deve realizar para atender seus usurios.

No "como"


3/105

todos os mtodos de anlise devem ser capazes

de suportar 5 atividades:

3

Anlise

Representar e entender o domnio da informao

Definir as funes que o software deve executar

Representar o comportamento do software em

funo dos eventos externos

Particionar os modelos de informao

Prover a informao essencial em direo a

determinao dos detalhes de implementao


4/105

4

O objetivo da Anlise Essencial descobrir,

e documentar, todos os requisitos funcionais

verdadeirosde um sistema e apenas esses

requisitos.

Anlise Essencial

Para que isso seja possvel, adotamos um

conjunto de princpios e conceitos que nos

permitem identificar esses requisitos dentrode toda a informao levantada durante um

processo de anlise.


5/105

5

Respostas Planejadas

O Mtodo Essencial no eficaz em qualquer

tipo de projeto. Na verdade, estamos

preocupados basicamente com sistemas de

informao que sejam sistemas interativos

de respostas planejadas.

Esses sistemas funcionam sempre em resposta

a algum evento fora do seu controle para o qualpossamos definir uma resposta planejada.


6/105

6

Respostas Planejadas

Deve ficar claro que no estamos interessados

em eventos que exigem respostas ad-hoc, isto ,

caso a caso.

Usaremos o exemplo clssico do vendedor de passagens de

avio: podemos fazer um sistema capaz de responder as perguntas

tpicas como "qual o preo da passagem para So Paulo" ou

"Quando sai o prximo vo para Braslia", porm no podemos

considerar com esse mtodo um sistema que responda a

absolutamente todas as perguntas que um ser humano poderia

responder, como "Qual foi o resultado do ltimo jogo do

Amrica?".


7/105

7

Princpios

Os princpios da modelagem essencial seroos nossos guias no processo de anlise.

O que acontece nesse processo que vriasvezes temos a opo de tomar dois ou maiscaminhos.

Na modelagem essencial temos princpiosespecficos que nos orientam nessa escolha.

Na modelagem estruturada tradicional temos apenas vagasrecomendaes que nos auxiliam a escolher esse caminho,


8/105

8

Princpios

Os princpios da Anlise Essencial so:

O oramento para a complexidade

A neutralidade tecnolgica

A tecnologia interna perfeita

O modelo essencial mnimo

A esses princpios somaremos um quinto, j apresentado,

o princpio da ausncia de surpresas, por acreditarmos

que perfeitamente condizente com os princpios

essenciais.


9/105

9

O Oramento para a Complexidade

Esse princpio nos orienta a modelar umsistema que possamos compreender.

Para isso devemos manipular a complexidadedo modelo de forma a manter tanto o todo comocada uma de suas partes em um nvel de

complexidade compatvel com a intelignciahumana.


10/105

10

O Oramento para a Complexidade

Para isso utilizamos tcnicas de particionamento

do sistema e o controle de caractersticas que

aumento a complexidade do modelo, entre elas:

Controle do nmero de componentes de cada parte do modelo;

Controle da complexidade interna de cada parte do modelo;

Controle da complexidade da interface entre componentes;

Manuteno da qualidade dos nomes utilizados no modelo, e

Manuteno da qualidade da representao do modelo,

por exemplo, quanto clareza dos diagramas.


11/105

11

72

Um das tcnicas mais citadas para controlar

a complexidade a de manter o nmero de

componentes de cada modelo ou sub-modelo

entre 5 e 9.

Isso decorre de uma pesquisa que determinou

que o ser humano mdio tem a capacidade de se

concentrar em 7 elementos, com variao de 2.


12/105

12

Todo e Partes

Complexidade Total funo

Muitas vezes, alterar uma especificao tira

complexidade de uma "fonte" e coloca

complexidade em outra.

Complexidade de cada parte

Complexidade do todo

No h "conservao de complexidade"

Essa transferncia pode diminuir a complexidade

global


13/105


14/105

14

A Neutralidade Tecnolgica

Alguns autores j criticam a neutralidade

tecnolgica, ou simplesmente "passam por

cima" dessa questo, colocando preocupaes

de tecnologia j nessa fase.

A questo tem relao com a necessidadede se assumir algumas premissas para obter

solues mais eficientes.


15/105

15


Em todo caso, na definio de sistemas de

informao, a metfora evento-atividade-memria

fornecida pela anlise essencial na maioria dos

casos suficiente para fornecer todo o arcabouo

necessrio para uma boa anlise de requisitos.


16/105

16


Devemos ento no s seguir esse princpio,

mas tambm us-lo como ferramenta de

conferncia em cada um dos nossos passos,

verificando se h ou no comprometimento

com uma tecnologia especfica, corrigindo cadaponto onde for encontrado esse comprometimento

para uma especificao tecnologicamente neutra.


17/105

17

Tcnicas para Evitar a Influncia de

Tecnologia

Sistema capaz de ler mentes

Sistema funciona pelo correio, com cartas e pessoas

Sistema funciona via Web

Sistema funciona via Celular e Telefonistas

Sistema funciona s com papel


18/105

18

A Tecnologia Interna Perfeita

O sistema deve ser modelado com a suposioque a tecnologia interna ao sistema perfeita.

A velocidade do sistema perfeito infinita,

Por tecnologia interna perfeita queremos dizerque todos os recursos do sistema so ideais.

O sistema perfeito nunca apresenta falhas ou

necessidade de manuteno.

no h espera para conseguir um resultado.

A memria de um sistema perfeito tambm

no possui limitaes,

podendo guardar qualquer quantidade deinformao por um perodo indeterminado,

sem nenhum atraso no tempo de busco.


19/105


20/105

20


21/105

21

Tecnologia Interna Perfeira

No faz backup

Liga e desliga sem custo

No existem clculos complicados demais

No existem dados grandes demais

No demora

Custa barato

Efeitos na modelagem conceitual de dados


22/105

22

O Modelo Essencial Mnimo

Precisamos, porm, para garantir que nossomtodo tem uma resposta nica, ter uma formade escolher, entre dois modelos, qual o modeloessencial, mesmo que eles cumpram todos osrequisitos anteriores.

Os princpios anteriores vo definir claramentea nossa forma de trabalho, porm muitas vezessero inteis para ajudar a escolher qual o o

modelo essencial entre dois modelos possveis.

O princpio do modelo essencial mnimo exige que,entre dois modelos possivelmente essenciais, adefinio menos complicada o modelo essencial.

Assim possumos uma forma clara de escolha


23/105

23

Contedo:

KISS

Professor:

"keep it simple, sir..."


24/105

24

Mnimo?

Discutir o que mnimo pode ser um pouco mais

difcil do que parece

As alternativas podem alterar a complexidade

em pontos distintos do sistema


25/105

25

O Princpio da Ausncia de Surpresas

O princpio conservado quando o produto:

Faz o que o usurio espera

Responde de forma previsvel e consistenteaos estmulos.

Comporta-se de forma limitada a sua razo

de existncia. regular e mnimo, apesar de completo.

Quando falha, o faz de forma graciosa e

recupervel. Quando a dificuldade de utiliz-lo ou modific-loe compatvel com a dificuldade da rea de

aplicao.


26/105

26


27/105

27

A Essncia

A essncia do sistema tudo que precisariaser includo no sistema para que o mesmofuncionasse quando implementado em um

ambiente de tecnologia perfeita.

Sistemas essenciais possuem dois tipos de

componentes: atividades e memrias.

Isso compreende velocidade infinita no processador, tamanhoinfinito de memria, custo nulo para todas as operaes,

infalibilidade, etc.


28/105

28

Eventos Essenciais

Na modelagem essencial tudo ocorre em funode eventos.

Imaginamos que o sistema possui dois estados:

em atividade ou

esperando um evento.


29/105

29

Eventos Essenciais

o acontecimento do evento que faz com queo sistema entre em funcionamento e entorealize todas as tarefas necessrias para

atender aquele evento, ou seja, a atividadeessencial correspondente ao evento.

importante notar que o sistema s tem aoportunidade de funcionar quando aconteceum evento.

O sistema incapaz de gerar um evento.

Esses eventos, por definio, no socontrolveis pelo sistema

A i id d


30/105

30

Atividades

Cada tarefa que o sistema de tecnologia perfeitatem que realizar para cumprir a finalidade dosistema uma atividade essencial.

Essas atividades existem em duas formas: asatividades fundamentaise as atividadescustodiais.

Requisitos funcionais

M i


31/105

31

Memrias

As atividades essenciais, para poderem

executar suas tarefas, precisam guardar

informao.

Essa informao guardada em memrias.

Cada atividade essencial, porm, pode ter

apenas uma viso parcial dessa memria, de

acordo com suas necessidades.

Modelo Conceitual de Dados

Requisitos de Informao

Ati id d F d t i


32/105

32

Atividades Fundamentais

So aquelas que justificam a existncia do sistema.

Certamente, ao comprar um sistema, precisamos

fundamentalmente das sadas que ele nos

disponibilizar.

Ati id d F d t i


33/105

33

Atividades Fundamentais

Assim, atividades fundamentais precisam

incluir alguma sada para agentes externos.

As atividades fundamentais necessitam de

dados para funcionar,

podem ser fornecidos diretamente por umagente externo, um ser humano ou outrosistema que faz parte do ambiente, interagindo

com o sistema,

Podem estar guardados em uma memria.

Ati id d C t di i


34/105

34

Atividades Custodiais

Se destinam a criar e manter as memrias

necessrias para o funcionamento das atividades

fundamentais.

Um sistema, mesmo de tecnologia perfeita, no

pode criar dados sozinho.



35/105

35


Atividades custodiais, fique bem claro, so

essenciais ao funcionamento do sistema.

Enquanto o usurio conhece a grandemaioria das atividades fundamentais queprecisa, muitas atividades custodiais ficamde fora de sua lista.

Ao analisar um sistema, devemos estarsempre alerta para atividades custodiaisnecessrias para manter nossas memrias

em ordem.

Algumas atividades so custodiais e

fundamentais simultaneamente, sendo ento

chamadas de compostas ou mistas.

Viso Pragmtica


36/105

36

Viso Pragmtica

possvel ter uma viso menos funcionale mais pragmtica, que perde muito da qualidadefilosfica, mas ganha em simplicidade:

Isso nos chama ateno que no existem

atividades que no sejam fundamentais oucustodiais, isso , uma atividade deve pelomenos escrever em uma memria ou fazerum relatrio.

atividades fundamentais tm uma sadapara o mundo externo, enquanto

atividades custodiais alteram memrias.

Agentes Externos


37/105

37

Agentes Externos

Representamos as pessoas, departamentos,

empresas, mquinas ou sistemas que interagem

com o sistema sendo analisado, enviando ou

recebendo dados, por meio de agente externos,

Agentes externos, tambm so chamados de

entidades externas ou terminadores.

Agentes Externos


38/105

38

Agentes Externos

Normalmente agentes externos representam

pessoas, pois a maioria das funes de um

sistema de informao se d por meio da

interao com uma ou mais pessoas.

Eventualmente um sistema de informao

interage com outro sistema, recebendo ou

enviando dados, ou ainda com sensor ou com

um atuador.

Agentes Externos


39/105

39

Agentes Externos

Os agentes externos controlam o funcionamento

do sistema.

detm o poder de iniciar as atividades essenciais,

ao enviar um estmulo ao sistema.

recebem todas as respostas emitidas pelo sistema.

Transportadores


40/105

40

Transportadores

O modelo essencial est interessado nosagentes externos que detm realmente o controledos estmulos ou que realmente recebem a

informao.Alguns usurios do sistema implementado,

como digitadores, no so modelados na

anlise essencial.Usurios do sistema que apenas servem como

interlocutores dos verdadeiros agentes externos

so considerados transportadores de dados.Ao documentar um evento devemos

documentar a existncia de transportadores,

como veremos no dicionrio de eventos.

Agentes x Transportadores


41/105

41

Agentes x Transportadores

A verdadeira essncia de um sistema estrelacionada com sua funo no negcio emque ele est inserido.

Devemos considerar como agentes externosaquelas pessoas ou artefatos tecnolgicos que

detm o poder de iniciar o evento.

Um bom teste para verificar se o agente

externo o verdadeiro iniciador do evento ouapenas um transportador, no contexto de umnegcio, perguntar se ele pode realizar, por

sua vontade, aquele evento.

Descrio


42/105

42

Descrio

No estamos preocupados com os motivosdos agentes externos, ou em modificar suasaes, ou com o que eles fazem com os dados

que obtm do sistema.

No estamos preocupados com os motivosdos agentes externos, ou em modificar suasaes, ou com o que eles fazem com os dadosque obtm do sistema.

Por isso eles no so estudados, definindo

a fronteira do sistema e os limites do trabalhode anlise.

Descrio


43/105

43

Descrio

Outro tipo comum de agente externo aqueleque representa uma instituio ou departamentoexterno ao ambiente de uso do sistema.

Existem os agentes externos que so mquinas,como sensores, ou sistemas,

nomeado com o nome desse departamentoou da instituio (ou ainda, do tipo dainstituio).

nomeados diretamente com o nome dos mesmos.

Agentes Externos e Memria


44/105

44


importante perceber que muitos agentes

devem ser representados no s fora do sistema,

mas tambm em sua memria.

Isso acontece quando o sistema deve guardar

dados sobre um agente externo, de forma a

poder reconhecer ou referenciar um agente

externo, por exemplo, enviando uma conta parao agente externo.



45/105

45

Nesse caso, haver pelo menos uma entidade

no modelo de dados representando no total ou

parcialmente o agente externo.

Isso no se aplica, porm, no caso da segurana

e acesso, pois essa no tratada na anlise

essencial.

Eventos e Atividades


46/105

46

Cada atividade iniciada com um nico evento,

que define um estmulo, e compreende todo o

conjunto de aes efetuado pelo sistema para

executar a atividade, ou seja, a resposta

planejada.A atividade relativa a um evento compreende

toda a cadeia de aes causada por esse evento,

at que o sistema tenha que parar porque todos

os fluxos de dados atingiram seus objetivos

(agentes ou memrias).


47/105

Eventos: Gatilhos


48/105

48

e tos Gat os

O evento funciona como um gatilho, disparando

uma reao em cadeia, que para apenas pela

impossibilidade de realizar qualquer outra

atividade. Nessa reao em cadeia no devemos

nos preocupar no modo como as aes ocorrem nosistema existente, na encarnao atual, pois elas

podem sofrer interrupes esprias, que dividem

um evento entre vrios processadores.


49/105

49


50/105

49


51/105

49


52/105

49


53/105

49

Dilogos


54/105

50

Muitas vezes o iniciante na anlise essencialimagina que ser travado um dilogo com o

usurio durante a atividade.

O estmulo relacionado ao evento, isto , ofluxo de dados que parte do agente externo

em direo atividade, possui toda a informao

necessria para realizar a atividade,

Esse dilogo interno a uma atividade noexiste na anlise essencial.

incluindo partes opcionais.

Dilogos


55/105

51

Caso o dilogo seja realmente necessrio parao funcionamento do sistema, ento temos na

verdade dois, ou mais, eventos e suas respectivas

atividades

A regra que usamos : se o sistema para, s

pode voltar a funcionar com um evento.

Isso acontece porque uma atividade, por

definio, no pode ficar "esperando" poruma entrada de dados.

O mesmo raciocnio se aplica quandofalamos de vrios agentes externos.

Eventos Internos


56/105

52

Segundo a anlise essencial, no existemeventos internos ao sistema,

A anlise essencial parte do conceito que

eventos iniciam atividadesessenciais e queessas atividades so executadas at que todasas respostas necessrias sejam geradas.

no dizemos que um processo do sistema se inicia porcausa de um evento causado por outro processo.

Devemos ter bastante ateno regra que uma atividadecontm a resposta completa para um evento (e apenas paraum nico evento), pois ela que vai definir o particionamentodo sistema sendo modelado.

Reviso


57/105

53

Os eventos acontecem fora do sistema,correspondem a um estmulo que cruza a fronteirado sistema de fora para dentro* e so vistos e

descritos na perspectiva de um ser imaginrioque habita sistema.

Atividades essenciais no se comunicamdiretamente, isto , no se comunicam por meio

de fluxos de dados.

Assim eles so descritos tendo como sujeito o agente

externo que os iniciam, como em "Aluno solicita matrcula"

Toda comunicao entre atividades essenciais feitapor meio do uso da memria do sistema

* O professor fala "dentro para fora", mas o correto oescrito no slide.

Tipos de Eventos


58/105

54

Um evento externoquando parte doambiente para dentro do sistema. Um comandoou um pedido do usurio, por exemplo.

Um evento temporalquando provocadopor uma mudana no tempo, como um alarmede relgio ou uma data no calendrio.

Tipos de Eventos Temporais


59/105

55

Um evento temporal relativoquando definidoem funo do decorrer de um prazo depois doacontecimento de outro evento.

Eventos temporais absolutosocorrem emfuno unicamente do calendrio e do relgio.

Um evento temporal ocorre porque o sistema

tem um contrato para entregar informao a umagente em um momento especfico

Eventos Externos Agendado


60/105

56

Um evento externo agendado quandosabemos que ele vai acontecer em um instanteespecfico, ou que tem um limite de prazo para

acontecer. Ele pode tambm ser chamado deevento agendado.

Eventos Externos No-Agendados


61/105

57

Um evento externo no-agendado quandono podemos determinar momento ou limitepara seu acontecimento.

Ele pode tambm ser chamado de evento no agendado.

Os nomes "esperado" e "no-esperado" podem causar

alguma confuso. O sistema, na realidade, espera queambos os tipos de eventos ocorram. Porm, alguns tmum prazo ou data para ocorrer. Por isso podemos usar,com mais preciso, o termo "agendado".

No-Eventos


62/105

58

Eventos esperados formam uma categoriaimportante, pois sabemos que no mundo real,quando um evento esperado no acontece (o

pagamento de uma conta, por exemplo), podeser necessrio tomar uma atitude especfica.

Dizemos ento que eventos esperados podem

necessitar que sejam definidos no-eventos.

O nome "no-evento" pode causar confuso. Um no-evento um evento, em especial, um evento temporal relativo.

Esse o nome que damos para eventos queacontecem em funo de outro no ter acontecido,

possivelmente a partir de um prazo,

No-Eventos


63/105

59

Um s evento esperado pode necessitar devrios no eventos, que ocorrem normalmenteem prazos distintos.

Um no-evento um evento temporal relativoque deve acontecer se um evento esperado no

ocorre, possivelmente considerando um prazo.

Assim, se temos um evento esperado "cliente paga conta,at o dia 30 do ms", podemos ter vrios no eventos paraos prazos de 1 dia, 1 semana, 1 ms, 3 meses e 1 ano, por

exemplo.


64/105

60


65/105

60

Descrevendo


66/105

61

Um evento externo sempre caracterizadopela existncia de agente externo, que apessoa ou um outro sistema que faz com que

o evento acontea, enviando para o sistema oestmulo correspondente.

Assim, na nossa descrio de um evento externo sempre

devemos colocar o nome do agente externo que o causa.

Descrevendo


67/105

62

No caso de eventos temporais, devemos colocaro fato que faz o evento acontecer.

Alguns estmulos so bastante complicados,

contendo dezenas ou centenas de dados, outrosso bastante simples, contendo apenas umcomando ou solicitao ao sistema.

Eventos temporais no possuem um agente externo quefornea o estmulo.

Eventos cujo estmulo apenas um comando de execuopodem ser chamados eventos de controle.

Sintaxe


68/105

63

A sintaxe para definir eventos externos :

Como em: "Cliente solicita lista de produtos".

,

Opcionalmente, no caso de um evento esperado,pode ser usado o seguinte padro:

Onde prazo pode ser absoluto ou relativo aoutro evento ou resposta de evento. Como em:"Fornecedor envia produtos pedidos, at 30 dias

depois do pedido".

Sintaxe


69/105

64

A sintaxe para definir eventos temporais :

ou simplesmente

, (hora|dia|etc.) de

,

Como em: "Todo dia 30, dia enviar

declarao de vendas" ou "dia 30, enviardeclarao de vendas".

Sintaxe


70/105

65

A sintaxe para um no evento :

Como em: "Fornecedor no enviou produtos

pedidos, depois de 30 dias do pedido, avisarcomprador"

,

, ,

Sintaxe


71/105

66

O objeto da orao normalmente um objetodireto que, de alguma forma, representa umainformao tratada pelo sistema, e possivelmente

tambm um objeto indireto indicando para quemou para onde a informao enviada.

Exemplos

Cliente envia pedido de compra


72/105

67

Cliente envia pedido de compra.

Fornecedor entrega mercadoria

Fornecedor entrega mercadoria, at 10 diasdepois do pedido.

Vendedor solicita mercadoria.

Filial envia vendas dirias.

Cliente aluga fita. Ao final do ms, imprimir folha de pagamento.

Ao fim do dia, imprimir resumo de vendas.

Gerente solicita relatrio de produo.

Caso o cliente no pague a conta, 20 dias depois,invocar departamento jurdico.

Caso o aluno no apresente o boletim assinado,10 dias depois, enviar aviso aos pais.

Erros!


73/105

68

Vejamos agora alguns eventos descritos deforma incorreta:

Enviar pedido (sem agente externo ou indicaode tempo)

Gerente imprime relatrio (quem imprime osistema, o gerente solicita, alm disso, "relatrio" um termo muito vago).

Classificando os Eventos


74/105

69

Apesar de termos descrito os eventos comopodendo ser de vrios tipos, no extremamentenecessrio identificar todos os eventos.

Porm, fazer isso traz a vantagem de podermostestar a forma como o evento est descrito



75/105

70

Eventos externos:.

So esperados ou agendados?

So no-esperados ou no agendados?

So uma solicitao?

Possuem dados?

Se esperados, possuem um no-evento correspondente?



76/105

71

Eventos temporais:

S ocorrem dessa forma?

So realmente temporais ou podem ser calculados antes(sendo, nesse caso, uma sada do sistema)?

So Relativos?

O evento original existe sempre?

So no-eventos?

Qual o evento original?

Classificando Eventos


77/105

72

Opcionalmente, podemos construir uma tabelade classificao de eventos, como a apresentadaa seguir.

Todo evento deve ser facilmente classificado.

A dificuldade de classificar um evento demonstra que ele

no foi compreendido e indica que ele pode no estar correto,tanto na sua interpretao ou na sua descrio, ou at queseja um requisito falso.

Alm disso, a tabela permite que verifiquemos setodos os eventos esperados possuem um ou maisno eventos correspondentes.


78/105

73

Encontrando Eventos


79/105

74

Os principais eventos so os pedidos que sofeitos ao sistema. Eles normalmente podem serencontrados em formulrios, memorandos,documentos que chegam e observando oatendimento que os usurios do sistema prestam.

Relatrios devem ser gerados por algum evento.Eles, porm, so as respostas aos eventos e no

os eventos propriamente ditos. Todo eventoexterno esperado deve precisar de um e podeprecisar de mais no eventos.

No mundo real encontramos ainda outrascaractersticas que indicam novos eventos:

Pedidos normalmente podem ser cancelados.

Encontrando Eventos


80/105

75

O que enviado pode retornar, exigindo umaao especfica.

Documentos podem ser perdidos e segundas

vias podem ser necessrias Fiscais (ICMS, ISS, Trabalho,...) podem aparecere solicitar relatrios (que podem ser obrigatrios

em um sistema). Processos que ocorrem em uma ordem podemter que ser "acelerados" para atender um cliente

preferencial. Pagamentos podem ser feitos com o valor errado,para menos ou para mais, exigindo emisso de

novas cobranas ou de crditos.

Simplificando Eventos


81/105

76

Segundo a anlise essencial original, asoperaes de incluir, eliminar e alterar umamemria exigiriam pelo menos trs eventos

distintos, como em:

Proprietrio cadastra produto

Proprietrio altera produto

Proprietrio apaga produto

Simplificando Eventos


82/105

77

Isso, porm, pode no representar a verdadee ser muito complicado em alguns sistemas.

Em primeiro lugar, no criamos atividades

custodiais que no so necessrias.s.

Na vida real fcil termos um sistema com 30 a 40entidades. Isso exigiria no mnimo 90 eventos para cumprir

as necessidades de manter a memria. No fazemosisso na prtica.

Isso acontece quando a memria j gerenciada emuma atividade fundamental.

Em segundo lugar, quando uma memrianecessita de uma funcionalidade que permitatratar esses trs casos, podemos utilizar umanotao mais simples:

Proprietrio mantm produtos

As Respostas aos Eventos


83/105

78

Para cada evento o sistema deve executar uma resposta.Essa resposta representada pela atividade essencialcorrespondente ao evento e produz dois tipos de resultados:alteraes no estado do sistema e emisso de informaopara o ambiente (alteraes do estado do ambiente).

Uma alterao no estado do sistema significa que uma oumais memrias foram alteradas. Nisso inclumos a criao deregistros, a mudana de valores dentro de registros e a

eliminao de registros.

Como emisso de informao temos vrias formas deemisso de relatrios, feedback para os agentes externos e

comandos para atuadores externos.



84/105

79

Cada evento pode exigir uma ou mais repostas,obrigatrias ou opcionais, do sistema. Oprocessamento de todas essas respostas,

juntas a atividade essencial.



85/105

80

Algumas respostas a eventos so bvias apartir do nome do evento, como por exemplo,em "Gerente solicita relatrio de vendas". Uma

resposta bvia "relatrio de vendas". Porm,poderamos, em um caso real, ter outras respostas,como por exemplo, "aviso ao diretor".



86/105

81

Logo aps levantar a lista de eventos importante levantar a lista de respostas paracada evento. Apesar de no ser importante

classificar cada resposta, recomendvelque o analista saiba se a resposta opcionalou obrigatria, e, caso seja opcional, estarpreparado para fornecer, mais tarde, as regrasque indicam sua necessidade.

Confundindo eventos e respostas


87/105

82

muito comum tambm que o iniciante confundauma resposta a um evento com um evento.

Para isso podemos usar uma ttica deverificao: perguntar por que um evento acontece.

Confundindo eventos e respostas

Se a resposta for "Esse evento acontece i X i d d " "


88/105

83

porque o usurio X enviou um dado" ou "porquese passaram X dias", estamos em um bomcaminho e provavelmente temos um evento.

Porm, se respondermos com algo do tipo "Esseevento acontece porque o sistema..." ou "Esseevento acontece quando verdade que..." ento

estamos em um mau caminho, pois no existemeventos gerados pelo sistema para o sistema..

Outra coisa importante verificar se existe algum

motivo para o sistema comear a funcionar sozinho(o evento). Se no existe, provavelmente escolhemoscomo evento algo que resposta para outro evento.

Confundindo eventos e respostas:casos especiais


89/105

84

Um exemplo muito comum acontece em"casos especiais".

Vamos supor que temos um sistema que deveproduzir um relatrio a cada 100 vendas informadas

por cada vendedor. A resposta correta ter um evento "Vendedorinforma venda", com uma sada (alm das outras

necessrias) "Relatrio de Vendas".Geralmente analistas iniciantes "inventam" umevento especial "Vendedor faz centsima venda".

Confundindo eventos e respostas:casos especiais


90/105

85

Esse raciocnio pode ser aplicado em todos oscasos em que temos uma sada opcional.

interessante notar que, em um DFD, as sadase entradas em um processo no so obrigatrias,mas opcionais.

a lgica do processo que vai decidir se elasexistem ou no.Assim, podemos incluir em um evento todos os

casos especiais que so identificveis pelo sistema.Obviamente, se o sistema no tiver um meio dedescobrir que um caso especial, ento devemos

ter outro evento.

A Memria do Sistema

Como memria do modelo essencial deve ser


91/105

86

Como memria do modelo essencial deve serutilizado o modelo de entidades e relacionamentos,descrito no Captulo VII.

Para cada evento e atividade essencial importante definir que memrias sero utilizadas.Isso pode ser feito por meio de uma Matriz CRUDou por meio de DFDs e mini-especificaes.

Entendendo um Evento

Para garantir que entendemos completamente


92/105

87

Para garantir que entendemos completamenteum evento, devemos nos perguntar as seteperguntas do mtodo 5W2H: Who, When, Where,

What, Why, How, How Much.

Who? Ou Quem?

Quem so os agentes externos?


93/105

88

Quem so os agentes externos?

Quem o iniciador?

Quem o transportador?

Existem outras pessoas ou sistemas envolvidos

nesse evento?

Essa atividade precisa de mais agentes externos?

When? Quando?

Quando ocorre essa atividade?


94/105

89

Quando ocorre essa atividade?

Alguma coisa precisa acontecer antes dessaatividade?

Alguma coisa deve acontecer depois dessaatividade?

Essa atividade est limitada no tempo por algumoutro evento? Por exemplo, s podemos vender apsa loja abrir e at a loja fechar.

Quando os dados (de entrada ou de sada) sonecessrios?

Where? Onde?

Onde ocorre a atividade em que setor ou


95/105

90

Onde ocorre a atividade, em que setor oudepartamento?

De onde vem o estmulo?

Para onde vai cada sada?

What? O que?

O que deve ser feito pela atividade?


96/105

91

O que deve ser feito pela atividade?

Que dados devem vir no evento externo?

Que sadas devem ser feitas?

Que dados so necessrios?

Why? Por que?

Porque o evento acontece?


97/105

92

Porque o evento acontece?

Porque alguns dados so necessrios?

How? Como?

Como a atividade acontece detalhadamente?


98/105

93

Como a atividade acontece detalhadamente?

Como so as sadas (relatrios) e entradas?

How much? Qual o valor? Quanto custa?

Quanto custa implementar o evento?


99/105

94

Quanto custa implementar o evento?

Quanto custa o evento para a empresa cliente?

Quanto custa um erro na atividade que realiza oevento?

O Dicionrio de Eventos

Com o tempo a Lista de Eventos entendidadi i i d t d


100/105

95

Com o tempo, a Lista de Eventos entendidapara um dicionrio de eventos, que descrevedetalhadamente as caractersticas de cadaevento.

Cada entrada no Dicionrio de Eventos composta de:

Identificador do evento, um nmero nico identificar doevento. Esse nmero obrigatrio.

Nmero de seqncia do evento no tempo, se existe.Novamente um nmero, porm indicando a ordem doevento no tempo, se existir. O nmero opcional. Vrioseventos podem possuir a mesma ordem (pois aconteceriamno mesmo intervalo de tempo).

Nome do evento, uma sentena que identifica o evento,de acordo com as regras anlise essencial.


Descrio do evento, uma descrio mais longa do evento,possivelmente contendo informaes no essenciais (como a


101/105

96

, uma descrio mais longa do evento,possivelmente contendo informaes no essenciais (como amotivao do agente externo), porm que aumentam acompreenso do evento. um resumo do que o evento.

Classificao do evento(externo (E/NE), temporal (R/A),No-evento.

Iniciador, o agente externo que envia o estmulo. Transportador, i.e., quem inserir os dados no sistema

Dados presentes no estmulo, descritos segundo alguma linguagemde dicionrio de dados, como a descrita nesse texto.


Atividade, descrio sucinta da atividade, por meio de algumalinguagem Possivelmente uma descrio algortmica em portugus


102/105

97

p glinguagem. Possivelmente uma descrio algortmica em portugusestruturado ou como uma seqncia de passos. Uma soluointeressante e descrever a atividade de acordo com suaspr-condies e ps-condies, possivelmente em uma linguagemformal como VDM ou Z.

Informao emitida na atividade, efeito da atividade no ambiente,

descrio de cada sada do sistema de acordo com uma linguagemde dicionrio de dados ou equivalente.


Efeito da atividade no sistema, descrio em linguagem naturalou em outra linguagem das modificaes que ocorrem no estado


103/105

98

ou em outra linguagem das modificaes que ocorrem no estadoglobal do sistema, ou com entidades especficas, com a execuoda atividade.

Tempo, limites de tempo do evento, ligado aos eventosesperados, quando devem acontecer.

Lista de entidades utilizadas(tiradas do modelo conceitual de dados),ou Matriz CRUD.

Efeitos colaterais das atividades so descritos aqui.Por exemplo: a atividade pode cadastrar um cliente na listade clientes inadimplentes, um efeito seria "o cliente estproibido de realizar outros gastos na empresa".


104/105

99

Professor:

Geraldo XexoDCC/IM/UFRJAula 24


105/105

100

Contedo:

FIM: Modelagem

Funcional Essencial

DCC/IM/UFRJ

PESC/COPPE/UFRJ

Aula 24

aula_024 - modelagem funcional essencial

Documents