Anda di halaman 1dari 101

Professor:

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

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

1
0

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.

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.

1
1

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

1
2

A Neutralidade Tecnolgica

1
3

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.

A Neutralidade Tecnolgica

1
4

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.

A Neutralidade Tecnolgica

1
5

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.

A Neutralidade Tecnolgica

1
6

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.

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

1
7

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.

1
8

A Tecnologia Interna Perfeita

1
9

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.

2
0

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

2
1

O Modelo Essencial Mnimo

2
2

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

Professor:
keep it simple, sir...

Contedo:

KISS

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

2
4

O Princpio da Ausncia de
Surpresas

2
5

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.

2
6

A anlise essencial fornece


uma filosofia de anlise de
sistemas

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.

2
7

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

2
8

Eventos Essenciais

2
9

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.

Atividades

3
0

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.

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.

3
1

Atividades Fundamentais

3
2

So aquelas que justificam a existncia


do sistema.
Certamente, ao comprar um sistema,
precisamos fundamentalmente das
sadas que ele nos disponibilizar.

Atividades Fundamentais

3
3

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.

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.

3
4

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.

3
5

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.

3
6

Agentes Externos

3
7

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

3
8

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

3
9

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.

4
0

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.

4
1

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.

4
2

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.

4
3

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.

4
4

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.

4
5

Eventos e Atividades

4
6

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

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.

4
7

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.

4
8

4
9

Evento
Sadas
Sistema
Parado

Atividade (Sist. em funcionamento)


Sadas

Tempo

Sistema
Parado

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.

5
0

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.

5
1

Eventos Internos

5
2

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.

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

5
3

Tipos de Eventos

5
4

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.

Tipos de Eventos Temporais

5
5

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

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.

5
6

5
7

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.

No-Eventos

5
8

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.

No-Eventos

5
9

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.

Eventos Essenciais
Eventos Externos
Esperados
Agendados
No Esperados
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.

6
1

Descrevendo

6
2

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.

Sintaxe

6
3

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.

Sintaxe

6
4

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.

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

6
5

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.

6
6

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.

6
7

Erros!

6
8

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

Classificando os Eventos

6
9

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

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?

7
0

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?

7
1

Classificando Eventos

7
2

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.

Encontrando Eventos

7
4

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.

Encontrando Eventos

7
5

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.

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

7
6

Simplificando Eventos

7
7

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

As Respostas aos Eventos

7
8

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.

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.

7
9

As Respostas aos Eventos

8
0

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.

As Respostas aos Eventos

8
1

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.

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.

8
2

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.

8
3

Confundindo eventos e respostas:


casos especiais

8
4

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.

Confundindo eventos e respostas:


casos especiais

8
5

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.

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.

8
6

A Memria do Sistema

8
7

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.

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.

8
8

Who? Ou Quem?

8
9

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?

9
0

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?

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

9
1

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?

9
2

Why? Por que?

9
3

Porque o evento acontece?


Porque alguns dados so necessrios?

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

9
4

How much? Qual o valor? Quanto


custa?

9
5

Quanto custa implementar o evento?


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

O Dicionrio de Eventos

9
6

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.

O Dicionrio de Eventos

9
7

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.

O Dicionrio de Eventos

9
8

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.

O Dicionrio de Eventos

9
9

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.

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

Contedo:

FIM: Modelagem
Funcional Essencial