Modelagem

Funcional
Essencial
Geraldo Xexo
DCC/IM/UFRJ
PESC/COPPE/UFRJ

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

Anlise
todos os mtodos de anlise devem ser
capazes de suportar 5 atividades:
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

Anlise Essencial
O objetivo da Anlise Essencial descobrir, e
documentar, todos os requisitos funcionais
verdadeiros de um sistema e apenas esses
requisitos.
Para que isso seja possvel, adotamos um
conjunto de princpios e conceitos que nos
permitem identificar esses requisitos dentro de
toda a informao levantada durante um
processo de anlise.

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 qual possamos definir uma resposta
planejada.

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?.

Princpios
Os princpios da modelagem essencial sero
os nossos guias no processo de anlise.
O que acontece nesse processo que vrias
vezes temos a opo de tomar dois ou mais
caminhos.
Na modelagem estruturada tradicional temos apenas
vagas recomendaes que nos auxiliam a escolher
esse caminho,

Na modelagem essencial temos princpios

especficos que nos orientam nessa escolha.

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.

O Oramento para a
Complexidade
Esse princpio nos orienta a modelar um
sistema que possamos compreender.
Para isso devemos manipular a complexidade
do modelo de forma a manter tanto o todo
como cada uma de suas partes em um nvel de
complexidade compatvel com a inteligncia
humana.

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.

10

72

Um das tcnicas mais citadas para controlar

a complexidade a de manter o nmero de
componentes de cada modelo ou submodelo 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.

11

Todo e Partes
Complexidade Total funo
Complexidade de cada parte
Complexidade do todo

Muitas vezes, alterar uma especificao tira complexidade de

uma fonte e coloca complexidade em outra.
No h conservao de complexidade

Essa transferncia pode diminuir a complexidade global

12

A Neutralidade Tecnolgica
Exige que um modelo essencial no inclua em
nenhuma de suas partes indcios da tecnologia
de implementao
Essa exigncia, apesar de importante, das mais
quebradas pelos analistas.
Isso acontece por que geralmente j sabemos qual a
tecnologia em que vamos implementar o sistema.

importante manter a neutralidade no s

para permitir uma anlise mais objetiva do
verdadeiro problema do usurio, mas tambm
para aumentar a durabilidade dessa anlise.

13

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 necessidade de se assumir algumas
premissas para obter solues mais eficientes.

14

A Neutralidade Tecnolgica
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.

15

A Neutralidade Tecnolgica
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 cada
ponto onde for encontrado esse
comprometimento para uma especificao
tecnologicamente neutra.

16

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

17

A Tecnologia Interna Perfeita

O sistema deve ser modelado com a suposio que a
tecnologia interna ao sistema perfeita.
Por tecnologia interna perfeita queremos dizer que
todos os recursos do sistema so ideais.
A velocidade do sistema perfeito infinita,
no h espera para conseguir um resultado.

A memria de um sistema perfeito tambm no possui

limitaes,
podendo guardar qualquer quantidade de informao por um
perodo indeterminado, sem nenhum atraso no tempo de busco.

O sistema perfeito nunca apresenta falhas ou

necessidade de manuteno.

18

A Tecnologia Interna Perfeita

Devemos, porm, lembrar que no fazemos essa
suposio sobre a tecnologia externa ao sistema,
apenas sobre a tecnologia interna ao sistema.
Alm disso, essa suposio s feita na fase de anlise,
sendo esquecida na fase de projeto, onde temas como
velocidade, tamanho de memria e gerncia de riscos passam
a fazer parte de nossas preocupaes, junto com outras
caractersticas que, apesar de no fazer parte da suposio de
um sistema perfeito, tambm so postergadas para a fase de
projeto, como controle de acesso (segurana).

Na prtica interessante imaginar o sistema como um

gnio da lmpada, capaz de fazer qualquer coisa em
tempo zero, se possuir a informao necessria.

19

20

Tecnologia Interna Perfeira

No faz backup
Liga e desliga sem custo
No existem clculos complicados demais
No existem dados grandes demais
Efeitos na modelagem conceitual de dados

No demora
Custa barato

21

O Modelo Essencial Mnimo

Os princpios anteriores vo definir claramente a nossa
forma de trabalho, porm muitas vezes sero inteis
para ajudar a escolher qual o o modelo essencial
entre dois modelos possveis.
Precisamos, porm, para garantir que nosso mtodo
tem uma resposta nica, ter uma forma de escolher,
entre dois modelos, qual o modelo essencial, mesmo
que eles cumpram todos os requisitos anteriores.
O princpio do modelo essencial mnimo exige que,
entre dois modelos possivelmente essenciais, a
definio menos complicada o modelo essencial.
Assim possumos uma forma clara de escolha
22

KISS
keep it simple, sir...

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

24

O Princpio da Ausncia de
Surpresas
O princpio conservado quando o produto:

Faz o que o usurio espera

Responde de forma previsvel e consistente aos
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-lo e
compatvel com a dificuldade da rea de aplicao.

25

A anlise essencial fornece

uma filosofia de anlise de
sistemas

26

A Essncia
A essncia do sistema tudo que precisaria
ser includo no sistema para que o mesmo
funcionasse quando implementado em um
ambiente de tecnologia perfeita.
Isso compreende velocidade infinita no processador,
tamanho infinito de memria, custo nulo para todas
as operaes, infalibilidade, etc.

Sistemas essenciais possuem dois tipos de

componentes: atividades e memrias.
Sistemas essenciais funcionam a partir de
Eventos Essenciais.
27

Eventos Essenciais
Na modelagem essencial tudo ocorre em funo de eventos.
Imaginamos que o sistema possui dois estados:
em atividade ou
esperando um evento.

28

Eventos Essenciais
o acontecimento do evento que faz com que
o sistema entre em funcionamento e ento
realize todas as tarefas necessrias para
atender aquele evento, ou seja, a atividade
essencial correspondente ao evento.
importante notar que o sistema s tem a
oportunidade de funcionar quando acontece
um evento.
Esses eventos, por definio, no so controlveis
pelo sistema

O sistema incapaz de gerar um evento.

29

Atividades
Cada tarefa que o sistema de tecnologia perfeita tem que
realizar para cumprir a finalidade do sistema uma atividade
essencial.
Requisitos funcionais

Essas atividades existem em duas formas: as atividades

fundamentais e as atividades custodiais.

30

Memrias
As atividades essenciais, para poderem
executar suas tarefas, precisam guardar
informao.
Requisitos de Informao

Essa informao guardada em memrias.

Modelo Conceitual de Dados

Cada atividade essencial, porm, pode ter

apenas uma viso parcial dessa memria, de
acordo com suas necessidades.

31

Atividades Fundamentais
So aquelas que justificam a existncia do sistema.
Certamente, ao comprar um sistema, precisamos
fundamentalmente das sadas que ele nos disponibilizar.

32

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 um agente
externo, um ser humano ou outro sistema que faz
parte do ambiente, interagindo com o sistema,
Podem estar guardados em uma memria.

33

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.

34

Atividades Custodiais
Atividades custodiais, fique bem claro, so
essenciais ao funcionamento do sistema.

Enquanto o usurio conhece a grande maioria das

atividades fundamentais que precisa, muitas
atividades custodiais ficam de fora de sua lista.
Ao analisar um sistema, devemos estar sempre
alerta para atividades custodiais necessrias para
manter nossas memrias em ordem.

Algumas atividades so custodiais e

fundamentais simultaneamente, sendo ento
chamadas de compostas ou mistas.

35

Viso Pragmtica
possvel ter uma viso menos funcional e
mais pragmtica, que perde muito da
qualidade filosfica, mas ganha em
simplicidade:
atividades fundamentais tm uma sada para o
mundo externo, enquanto
atividades custodiais alteram memrias.

Isso nos chama ateno que no existem

atividades que no sejam fundamentais ou
custodiais, isso , uma atividade deve pelo
menos escrever em uma memria ou fazer um
relatrio.
36

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.

37

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.

38

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.

39

Transportadores
O modelo essencial est interessado nos agentes
externos que detm realmente o controle dos 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.

40

Agentes x Transportadores
A verdadeira essncia de um sistema est
relacionada com sua funo no negcio em
que ele est inserido.
Devemos considerar como agentes externos
aquelas 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 ou
apenas um transportador, no contexto de um
negcio, perguntar se ele pode realizar, por
sua vontade, aquele evento.
41

Descrio
No estamos preocupados com os motivos dos
agentes externos, ou em modificar suas aes,
ou com o que eles fazem com os dados que
obtm do sistema.
Por isso eles no so estudados, definindo a
fronteira do sistema e os limites do trabalho de
anlise.

Normalmente agentes externos so descritos

por nomes que representam classes ou tipos
de usurio dentro de um negcio.

42

Descrio
Outro tipo comum de agente externo aquele
que representa uma instituio ou
departamento externo ao ambiente de uso do
sistema.
nomeado com o nome desse departamento ou da
instituio (ou ainda, do tipo da instituio).

Existem os agentes externos que so

mquinas, como sensores, ou sistemas,
nomeados diretamente com o nome dos mesmos.

43

Agentes Externos e Memria

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
para o agente externo.

44

Agentes Externos e Memria

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.

45

Eventos e Atividades
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).

46

Eventos e Atividades
Como apenas um evento inicia a atividade, ento apenas um
nico agente externo pode enviar informaes para uma
atividade.
Isso uma regra importante da anlise essencial, pois indica
como o sistema ser particionado.

47

Eventos: Gatilhos
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 no sistema existente,
na encarnao atual, pois elas podem sofrer
interrupes esprias, que dividem um evento
entre vrios processadores.

48

Evento
Sadas
Sistema
Parado

Atividade (Sist. em funcionamento)

Sistema
Parado

Sadas

Tempo

49

Dilogos
Muitas vezes o iniciante na anlise essencial imagina
que ser travado um dilogo com o usurio durante a
atividade.
Esse dilogo interno a uma atividade no existe na anlise
essencial.

O estmulo relacionado ao evento, isto , o fluxo de

dados que parte do agente externo em direo
atividade, possui toda a informao necessria para
realizar a atividade,
incluindo partes opcionais.

50

Dilogos
Caso o dilogo seja realmente necessrio para o
funcionamento do sistema, ento temos na verdade
dois, ou mais, eventos e suas respectivas atividades
Isso acontece porque uma atividade, por definio, no pode
ficar esperando por uma entrada de dados.

A regra que usamos : se o sistema para, s pode

voltar a funcionar com um evento.
O mesmo raciocnio se aplica quando falamos de vrios
agentes externos.

51

Eventos Internos
Segundo a anlise essencial, no existem eventos
internos ao sistema,
no dizemos que um processo do sistema se inicia por causa
de um evento causado por outro processo.

A anlise essencial parte do conceito que eventos

iniciam atividades essenciais e que essas atividades
so executadas at que todas as respostas
necessrias sejam geradas.
Devemos ter bastante ateno regra que uma atividade
contm a resposta completa para um evento (e apenas para
um nico evento), pois ela que vai definir o particionamento
do sistema sendo modelado.

52

Reviso
Os eventos acontecem fora do sistema,
correspondem a um estmulo que cruza a
fronteira do sistema de fora para dentro e so
vistos e descritos na perspectiva de um ser
imaginrio que habita sistema.
Assim eles so descritos tendo como sujeito o
agente externo que os iniciam, como em Aluno
solicita matrcula

Atividades essenciais no se comunicam

diretamente, isto , no se comunicam por
meio de fluxos de dados.
Toda comunicao entre atividades essenciais
feita por meio do uso da memria do sistema

53

Tipos de Eventos
Um evento externo quando parte do ambiente para dentro
do sistema. Um comando ou um pedido do usurio, por
exemplo.
Um evento temporal quando provocado por uma mudana
no tempo, como um alarme de relgio ou uma data no
calendrio.

54

Tipos de Eventos Temporais

Um evento temporal relativo quando
definido em funo do decorrer de um prazo
depois do acontecimento de outro evento.
Eventos temporais absolutos ocorrem em
funo unicamente do calendrio e do relgio.
Um evento temporal ocorre porque o sistema
tem um contrato para entregar informao a
um agente em um momento especfico

55

Eventos Externos Agendado

Um evento externo agendado quando sabemos que ele vai
acontecer em um instante especfico, ou que tem um limite de
prazo para acontecer. Ele pode tambm ser chamado de
evento agendado.

56

Eventos Externos No-Agendados

Um evento externo no-agendado quando
no podemos determinar momento ou limite
para 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 que ambos os tipos de eventos ocorram.
Porm, alguns tm um prazo ou data para ocorrer.
Por isso podemos usar, com mais preciso, o termo
agendado.

57

No-Eventos
Eventos esperados formam uma categoria importante,
pois sabemos que no mundo real, quando um evento
esperado no acontece (o pagamento de uma conta,
por exemplo), pode ser necessrio tomar uma atitude
especfica.
Dizemos ento que eventos esperados podem
necessitar que sejam definidos no-eventos.
Esse o nome que damos para eventos que
acontecem em funo de outro no ter acontecido,
possivelmente a partir de um prazo,
O nome noevento pode causar confuso. Um noevento
um evento, em especial, um evento temporal relativo.

58

No-Eventos
Um s evento esperado pode necessitar de
vrios no eventos, que ocorrem normalmente
em prazos distintos.
Assim, se temos um evento esperado cliente paga
conta, at o dia 30 do ms, podemos ter vrios no
eventos para os prazos de 1 dia, 1 semana, 1 ms,
3 meses e 1 ano, por exemplo.

Um no-evento um evento temporal relativo

que deve acontecer se um evento esperado
no ocorre, possivelmente considerando um
prazo.
59

Eventos Essenciais
Eventos Externos
Agendados
No Agendados
Eventos Temporais
Absolutos
Relativos
No- Evento

Descrevendo
Um evento externo sempre caracterizado
pela existncia de agente externo, que a
pessoa ou um outro sistema que faz com que o
evento acontea, enviando para o sistema o
estmulo correspondente.
Assim, na nossa descrio de um evento externo
sempre devemos colocar o nome do agente externo
que o causa.

61

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

Eventos temporais no possuem um agente externo

que fornea o estmulo.

Alguns estmulos so bastante complicados,

contendo dezenas ou centenas de dados,
outros so bastante simples, contendo apenas
um comando ou solicitao ao sistema.

Eventos cujo estmulo apenas um comando de

execuo podem ser chamados eventos de controle.

62

Sintaxe
A sintaxe para definir eventos externos :

<agente externo - sujeito> <verbo no presente>

<objeto direto>

Como em: Cliente solicita lista de produtos.

Opcionalmente, no caso de um evento
esperado, pode ser usado o seguinte padro:
<agente externo - sujeito> <verbo no presente>
<objeto direto> , <prazo>

Onde prazo pode ser absoluto ou relativo a

outro evento ou resposta de evento. Como em:
Fornecedor envia produtos pedidos, at 30
dias depois do pedido.
63

Sintaxe
A sintaxe para definir eventos temporais :
<condio temporal>, (hora|dia|etc.) de <verbo no
infinitivo> <objeto>

ou simplesmente
<condio temporal>, <verbo no infinitivo> <objeto>

Como em: Todo dia 30, dia enviar

declarao de vendas ou dia 30, enviar
declarao de vendas.

64

Sintaxe
A sintaxe para um no evento :
<condio de no acontecimento de um evento>, <prazo ou condio
temporal>, <verbo no infinitivo>, <objeto>

Como em: Fornecedor no enviou produtos pedidos, depois

de 30 dias do pedido, avisar comprador

65

Sintaxe
O objeto da orao normalmente um objeto direto que, de
alguma forma, representa uma informao tratada pelo
sistema, e possivelmente tambm um objeto indireto indicando
para quem ou para onde a informao enviada.

66

Exemplos

Cliente envia pedido de compra.

Fornecedor entrega mercadoria
Fornecedor entrega mercadoria, at 10 dias depois 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.

67

Erros!
Vejamos agora alguns eventos descritos de forma incorreta:
Enviar pedido (sem agente externo ou indicao de tempo)
Gerente imprime relatrio (quem imprime o sistema, o
gerente solicita, alm disso, relatrio um termo muito vago).

68

Classificando os Eventos
Apesar de termos descrito os eventos como podendo ser de
vrios tipos, no extremamente necessrio identificar todos
os eventos.
Porm, fazer isso traz a vantagem de podermos testar a forma
como o evento est descrito

69

Classificando os Eventos
Eventos externos:
So esperados ou agendados?
Se esperados, possuem um noevento correspondente?

So no-esperados ou no agendados?
So uma solicitao?
Ppossuem dados?

70

Classificando os Eventos
Eventos temporais:
S ocorrem dessa forma?
So realmente temporais ou podem ser calculados
antes (sendo, nesse caso, uma sada do sistema)?
So Relativos?
So noeventos?
Qual o evento original?

O evento original existe sempre?

71

Classificando Eventos
Opcionalmente, podemos construir uma tabela
de classificao de eventos, como a
apresentada a 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 que seja um requisito falso.

Alm disso, a tabela permite que verifiquemos

se todos os eventos esperados possuem um
ou mais no eventos correspondentes.

72

Encontrando Eventos
Os principais eventos so os pedidos que so feitos ao
sistema. Eles normalmente podem ser encontrados em
formulrios, memorandos, documentos que chegam e
observando o atendimento 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 evento externo esperado
deve precisar de um e pode precisar de mais no
eventos.
No mundo real encontramos ainda outras
caractersticas que indicam novos eventos:
Pedidos normalmente podem ser cancelados.

74

Encontrando Eventos
O que enviado pode retornar, exigindo uma ao
especfica.
Documentos podem ser perdidos e segundas vias
podem ser necessrias
Fiscais (ICMS, ISS, Trabalho,...) podem aparecer e
solicitar relatrios (que podem ser obrigatrios em um
sistema).
Processos que ocorrem em uma ordem podem ter 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.

75

Simplificando Eventos
Segundo a anlise essencial original, as operaes de incluir,
eliminar e alterar uma memria exigiriam pelo menos trs
eventos distintos, como em:
Proprietrio cadastra produto
Proprietrio altera produto
Proprietrio apaga produto

76

Simplificando Eventos
Isso, porm, pode no representar a verdade e ser
muito complicado em alguns sistemas.

Na vida real fcil termos um sistema com 30 a 40 entidades.

Isso exigiria no mnimo 90 eventos para cumprir as
necessidades de manter a memria. No fazemos isso na
prtica.

Em primeiro lugar, no criamos atividades custodiais

que no so necessrias.
Isso acontece quando a memria j gerenciada em uma
atividade fundamental.

Em segundo lugar, quando uma memria necessita de

uma funcionalidade que permita tratar esses trs
casos, podemos utilizar uma notao mais simples:
Proprietrio mantm produtos

77

As Respostas aos Eventos

Para cada evento o sistema deve executar uma
resposta. Essa resposta representada pela atividade
essencial correspondente ao evento e produz dois
tipos de resultados: alteraes no estado do sistema e
emisso de informao para o ambiente (alteraes do
estado do ambiente).
Uma alterao no estado do sistema significa que uma
ou mais memrias foram alteradas. Nisso inclumos a
criao de registros, a mudana de valores dentro de
registros e a eliminao de registros.
Como emisso de informao temos vrias formas de
emisso de relatrios, feedback para os agentes
externos e comandos para atuadores externos.

78

As Respostas aos Eventos

Cada evento pode exigir uma ou mais repostas, obrigatrias ou
opcionais, do sistema. O processamento de todas essas
respostas, juntas a atividade essencial.

79

As Respostas aos Eventos

Algumas respostas a eventos so bvias a partir 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.

80

As Respostas aos Eventos

Logo aps levantar a lista de eventos
importante levantar a lista de respostas para
cada evento. Apesar de no ser importante
classificar cada resposta, recomendvel que
o analista saiba se a resposta opcional ou
obrigatria, e, caso seja opcional, estar
preparado para fornecer, mais tarde, as regras
que indicam sua necessidade.

81

Confundindo eventos e
respostas

muito comum tambm que o iniciante confunda uma

resposta a um evento com um evento.
Para isso podemos usar uma ttica de verificao: perguntar
por que um evento acontece.

82

Confundindo eventos e respostas

Se a resposta for Esse evento acontece porque o
usurio X enviou um dado ou porque se passaram X
dias, estamos em um bom caminho e provavelmente
temos um evento.
Porm, se respondermos com algo do tipo Esse
evento acontece porque o sistema... ou Esse evento
acontece quando verdade que... ento estamos em
um mau caminho, pois no existem eventos 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 escolhemos
como evento algo que resposta para outro evento.
83

Confundindo eventos e respostas:

casos especiais
Um exemplo muito comum acontece em
casos especiais.
Vamos supor que temos um sistema que deve
produzir um relatrio a cada 100 vendas
informadas por cada vendedor.
A resposta correta ter um evento Vendedor
informa venda, com uma sada (alm das
outras necessrias) Relatrio de Vendas.
Geralmente analistas iniciantes inventam um
evento especial Vendedor faz centsima
venda.

84

Confundindo eventos e respostas:

casos especiais
Vamos tentar aplicar nossos princpios. Temos um que
diz No surpreenda o usurio.
Seria uma surpresa para o usurio ter que usar uma tela
diferente e ele mesmo controlar sua centsima venda.
Muito mais natural seria que o sistema controlasse isso. Outro
princpio diz: tecnologia interna perfeita.
Ora, se a tecnologia interna perfeita no nos custa nada
fazer toda a lgica necessria para esse controle, tambm um
bom sinal.
Finalmente, o princpio da soluo mnima nos indica que
melhor ter apenas um evento do que dois.

85

Confundindo eventos e respostas:

casos especiais
Esse raciocnio pode ser aplicado em todos os casos
em que temos uma sada opcional.
interessante notar que, em um DFD, as sadas e
entradas em um processo no so obrigatrias, mas
opcionais.
a lgica do processo que vai decidir se elas existem
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 de
descobrir que um caso especial, ento devemos ter
outro evento.
86

A Memria do Sistema
Como memria do modelo essencial deve ser utilizado 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 CRUD ou por meio de DFDs e mini-especificaes.

87

Entendendo um Evento
Para garantir que entendemos completamente um evento,
devemos nos perguntar as sete perguntas do mtodo 5W2H:
Who, When, Where, What, Why, How, How Much.

88

Who? Ou Quem?
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?

89

When? Quando?
Quando ocorre essa atividade?
Alguma coisa precisa acontecer antes dessa
atividade?
Alguma coisa deve acontecer depois dessa
atividade?
Essa atividade est limitada no tempo por
algum outro evento? Por exemplo, s podemos
vender aps a loja abrir e at a loja fechar.
Quando os dados (de entrada ou de sada) so
necessrios?

90

Where? Onde?
Onde ocorre a atividade, em que setor ou departamento?
De onde vem o estmulo?
Para onde vai cada sada?

91

What? O que?
O que deve ser feito pela atividade?
Que dados devem vir no evento externo?
Que sadas devem ser feitas?
Que dados so necessrios?

92

Why? Por que?

Porque o evento acontece?
Porque alguns dados so necessrios?

93

How? Como?
Como a atividade acontece detalhadamente?
Como so as sadas (relatrios) e entradas?

94

How much? Qual o valor? Quanto

custa?
Quanto custa implementar o evento?
Quanto custa o evento para a empresa cliente?
Quanto custa um erro na atividade que realiza o evento?

95

O Dicionrio de Eventos
Com o tempo, a Lista de Eventos entendida para um
dicionrio de eventos, que descreve detalhadamente
as caractersticas de cada evento.
Cada entrada no Dicionrio de Eventos composta de:
Identificador do evento, um nmero nico identificar do
evento. Esse nmero obrigatrio.
Nmero de seqncia do evento no tempo, se existe.
Novamente um nmero, porm indicando a ordem do evento
no tempo, se existir. O nmero opcional. Vrios eventos
podem possuir a mesma ordem (pois aconteceriam no mesmo
intervalo de tempo).
Nome do evento, uma sentena que identifica o evento, de
acordo com as regras anlise essencial.

96

O Dicionrio de Eventos
Descrio do evento, uma descrio mais longa do
evento, possivelmente contendo informaes no
essenciais (como a motivao do agente externo),
porm que aumentam a compreenso 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 linguagem de dicionrio de dados, como a
descrita nesse texto.

97

O Dicionrio de Eventos
Atividade, descrio sucinta da atividade, por meio
de alguma linguagem. Possivelmente uma descrio
algortmica em portugus estruturado ou como uma
seqncia de passos. Uma soluo interessante e
descrever a atividade de acordo com suas prcondies e ps-condies, possivelmente em uma
linguagem formal como VDM ou Z.
Informao emitida na atividade, efeito da
atividade no ambiente, descrio de cada sada do
sistema de acordo com uma linguagem de dicionrio
de dados ou equivalente.

98

O Dicionrio de Eventos
Efeito da atividade no sistema, descrio em
linguagem natural ou em outra linguagem das
modificaes que ocorrem no estado global do
sistema, ou com entidades especficas, com a
execuo da atividade.
Efeitos colaterais das atividades so descritos aqui. Por
exemplo: a atividade pode cadastrar um cliente na lista de
clientes inadimplentes, um efeito seria o cliente est
proibido de realizar outros gastos na empresa.

Tempo, limites de tempo do evento, ligado aos

eventos esperados, quando devem acontecer.
Lista de entidades utilizadas (tiradas do modelo
conceitual de dados), ou Matriz CRUD.

99

Geraldo Xexo

FIM: Modelagem
Funcional
Essencial
DCC/IM/UFRJ

PESC/COPPE/UFRJ