Professor:

Aula 24

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

Contedo:
Modelagem
Funcional Essencial

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
3

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

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

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

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

Exemplos
A Tecnologia Interna Perfeita
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

Professor:
"keep it simple, sir..."

Contedo:
KISS

23

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

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.

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

49

49

49

49

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

* O professor fala "dentro para fora", mas o correto o

escrito no slide.

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 "no-evento" pode causar confuso. Um no-evento
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

60

60

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.

67

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!
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 no-evento correspondente?
So no-esperados ou no agendados?
So uma solicitao?
Possuem 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 no-eventos?
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

73

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.s.
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:
77

Proprietrio mantm produtos

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

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.

86

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.

87

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?

88

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

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

Para onde vai cada sada?

90

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?

91

Why? Por que?

Porque o evento acontece?
Porque alguns dados so necessrios?

92

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

93

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?

94

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

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.

96

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
pr-condies 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.

97

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.

98

99

Professor:

Aula 24

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

Contedo:
FIM: Modelagem
Funcional Essencial

100