Capítulo IX. Modelo Funcional Essencial Modelagem Estruturada
IX.7 Eventos Essenciais
Na modelagem essencial tudo ocorre em função de eventos. Isso acontece porque imaginamos que o sistema possui dois estados: em atividade ou esperando um evento. É o acontecimento do evento que faz com que o sistema entre em
71 Atualmente é fácil entender como o vendedor pode ser substituído por uma interface Web e o sistema
manter sua essência.
funcionamento e então realize todas as tarefas necessárias 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 definição, não são controláveis pelo sistema, ou seja: o sistema é incapaz de gerar um evento73.
Cada atividade é iniciada com um único evento, que define um estímulo, e compreende todo o conjunto de ações efetuado pelo sistema para executar a
atividade, ou seja, a resposta planejada. A atividade relativa a um evento
compreende toda a cadeia de ações causada por esse evento, até que o sistema tenha que parar porque todos os fluxos de dados atingiram seus objetivos (agentes ou memórias). Como apenas um evento inicia a atividade, então apenas um único
agente externo pode enviar informações para uma atividade74. Isso é uma regra
importante da análise essencial, pois indica como o sistema será particionado.
O evento funciona como um gatilho, disparando uma reação em cadeia, que para apenas pela impossibilidade de realizar qualquer outra atividade. Nessa reação em cadeia não devemos nos preocupar no modo como as ações ocorrem no sistema existente, na encarnação atual, pois elas podem sofrer interrupções espúrias, que dividem um evento entre vários processadores.
Tempo Sistema em Funcionamento Saídas Saídas Sistema Parado Sistema Parado
Evento
Figura 109. O esquema mostra como o sistema reage a um evento. Um Sistema parado só pode começar a funcionar ao receber um
evento. A partir desse evento, realiza uma série de processamentos que podem envolver saídas para o mundo externo, até parar novamente. Não podem existir outros eventos ou entradas do mundo externo durante o funcionamento, porém é
possível consultar as memórias, que são internas ao sistema.
Muitas vezes o iniciante na análise essencial imagina que será travado um diálogo com o usuário durante a atividade. Esse diálogo interno a uma atividade não existe na análise essencial. O estímulo relacionado ao evento, isto é, o fluxo de dados que parte do agente externo em direção à atividade, possui toda a informação necessária para realizar a atividade, incluindo partes opcionais. Caso o diálogo seja realmente necessário para o funcionamento do sistema, então temos na verdade dois, ou mais, eventos e suas respectivas atividades. Isso acontece porque uma atividade,
73 Não existem, logo, eventos essenciais internos ao sistema.
74 Yourdon não obedece essa regra, permitindo que algumas entidades externas forneçam informações sob
por definição, não 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 raciocínio se aplica quando falamos de vários agentes externos.
Segundo a análise essencial, não existem eventos internos ao sistema, isto é, não dizemos que um processo do sistema se inicia por causa de um evento causado por outro processo. A análise essencial parte do conceito que eventos iniciam
atividades essenciais e que essas atividades são executadas até que todas as respostas
necessárias sejam geradas. O sistema então para e fica esperando pelo acontecimento de outro evento de essencial para voltar a funcionar. Devemos ter bastante atenção à regra que uma atividade contém a resposta completa para um evento (e apenas para um único evento), pois é ela que vai definir o particionamento do sistema sendo modelado.
Outra característica da análise essencial é que os eventos são vistos por dentro do sistema. Assim eles são descritos tendo como sujeito o agente externo que os iniciam, como em “Aluno solicita matrícula”75.
Recapitulando, os eventos acontecem fora do sistema, correspondem a um estímulo que cruza a fronteira do sistema de fora para dentro e são vistos e descritos na perspectiva de um ser imaginário que habita sistema.
Também é importante frisar que atividades essenciais não se comunicam
diretamente, isto é, não se comunicam por meio de fluxos de dados. Toda
comunicação entre atividades essenciais é feita por meio do uso da memória do sistema
IX.7.1 Propriedades dos eventos
Um evento pode ser caracterizados pelas seguintes propriedades76: • Um evento deve ocorrer em um momento específico no tempo. • Um evento deveocorrer no ambiente e não dentro do sistema.
• A ocorrência do evento deve estar sob o controle do ambiente e não do sistema.
• O sistema pode detectar que o evento ocorre.
• O evento é relevante, isto é, o sistema deve fazer alguma quando ele ocorre.
IX.7.2 Tipos de Eventos
Cada evento pode ser externo ou temporal. Um evento é externo quando parte do ambiente para dentro do sistema. Um comando ou um pedido do usuário, por exemplo. Um evento é temporal quando é provocado por uma mudança no tempo, como um alarme de relógio ou uma data no calendário.
75 A frase pode ser lida como significando “Aluno solicita matrícula ao sistema”.
76 Ruble, D.A. Use Cases that Work: Using Event Modelling to infuse rigor and discipline in Use Case
Analysis. White Paper. Olumpic Consulting Group.
Originalmente só tratávamos esses dois tipos de eventos (externos e temporais). Com o tempo, porém, fomos aprendendo a trabalhar e a classificá-los mais detalhadamente de forma a melhorar nosso trabalho.
Eventos temporais podem ser absolutos ou relativos. Um evento é relativo quando é definido em função do decorrer de um prazo depois do acontecimento de outro evento. Eventos absolutos ocorrem em função unicamente do calendário e do relógio77. Um evento temporal ocorre porque o sistema tem um contrato para entregar
informação a um agente em um momento específico [B34].
Eventos externos podem ser: agendados ou não-agendados. Um evento é
agendado quando sabemos que ele vai acontecer em um instante específico, ou que
tem um limite de prazo para acontecer. Ele pode também ser chamado de evento
esperado. Um evento é não-agendado quando não podemos determinar momento ou
limite para seu acontecimento. Eles podem também ser chamados de eventos
não-esperados. Os nomes “esperado” e “não-esperado” podem causar alguma
confusão, pois na verdade esperamos que todos aconteçam, mas é encontrado na literatura. O sistema, na realidade, espera que ambos os tipos de eventos ocorram. Porém, alguns têm um prazo ou data para ocorrer. Por isso podemos usar, com mais precisão, o termo “agendado”.
Não-Eventos
Eventos agendados formam uma categoria importante, pois sabemos que no mundo real, quando um evento agendado não acontece (o pagamento de uma conta, por exemplo), pode ser necessário tomar uma atitude específica. Dizemos então que eventos agendados podem necessitar que sejam definidos não-eventos. Esse é o nome que damos para eventos que acontecem em função de outro não ter acontecido, possivelmente a partir de um prazo, como na sentença: “uma semana após esgotar o prazo de pagamento, enviar lembrete”. Novamente, o nome “não-evento” pode causar confusão. Um não-evento é um evento, em especial, é um evento temporal relativo.
Um só evento agendado pode necessitar de vários não eventos, que ocorrem normalmente em prazos distintos. Assim, se temos um evento agendado “cliente paga conta, até o dia 30 do mês”, podemos ter vários não eventos para os prazos de 1 dia, 1 semana, 1 mês, 3 meses e 1 ano, por exemplo.
Um não-evento é um evento temporal relativo que deve acontecer se um evento agendado (agendado) não ocorre,
possivelmente considerando um prazo.
77 eventos temporais podem ser implementados como eventos internos, mas não necessariamente. Isso
costuma causar confusão, pois temos o hábito imediato de pensar na implementação e de associar a proibição de eventos internos na análise como a proibição de eventos internos na implementação. Exigimos apenas, na análise essencial, que não existam eventos essenciais internos. A implementação não está limitada por essa regra.
Figura 110. Tipos de eventos essenciais e seus subtipos.
IX.7.3 Um Exemplo
Vamos tentar entender melhor a motivação para termos uma regra tão rígida sobre um evento só receber dado de um agente externo.
Imagine um sistema para uma loja de automóveis onde o mecânico, um agente externo, faz um pedido de peça. Esse pedido é anotado e repassado, pelo sistema, para outro sistema, o sistema de estoque, que é outro agente externo, que responderá se a peça está disponível ou não. Quando o sistema de estoque responder, então avisaremos o mecânico da disponibilidade da peça.
Segundo nossa regra, temos os seguintes eventos: • Mecânico solicita peça
4. Nesse evento é enviado um pedido de peça para o Sistema de Estoque
• Sistema de Estoque avisa disponibilidade de peça
5. Nesse evento o mecânico recebe um aviso da disponibilidade Já segundo alguns autores, fazendo uma interpretação simplificada, mas, porém não essencial, apenas o primeiro evento é necessário, pois nesse evento o Sistema de Estoque é consultado.
Agora vamos nos lembrar de nossos princípios da análise essencial. Não podemos considerar a tecnologia do sistema. Também, seguindo nossa definição de evento, não podemos controlar quando o mundo externo faz alguma coisa.
Dessa forma, não podemos controlar quando o Sistema de Estoque vai responder a pergunta que fizemos. Isso é, devemos esperar por um evento de resposta.
Quanto à tecnologia, podemos usar várias tecnologias como teste da “essencialidade” de uma solução. A solução essencial deve permitir que o pedido seja enviado ao estoque com qualquer tecnologia, por exemplo, cartas, telefone, pombo- correio ou computadores ligados na Internet. Porém, fica claro ao analisar um pedido feito por cartas que o sistema ficará parado esperando a resposta, logo a resposta é outro evento, que faz com que o sistema volte a funcionar.