por identificar o destinat´ario da mensagem, rencaminhando-a caso n˜ao seja o destinat´ario final, ou processando-a caso contr´ario. O processamento da mensagem implica em filtrar as mensagens de controle, processando-as diretamente, ou executando o m´etodoprocessCommand(Command cmd).
Esse m´etodo, implementado pelo usu´ario, permite que comandos espec´ıficos do componente sejam executados. Por exemplo, um Servidor de Eventos de movimenta¸c˜ao pode tratar uma mensagem do agente solicitando uma mudan¸ca de posi¸c˜ao.
3.5 CICLO DE VIDA 41 Musical (o registro do EventHandler ´e mostrado de forma simplificada, mais detalhes podem ser encontrados na se¸c˜ao 3.6.4).
:EnvironmentAgent
:MusicalAgent :World
:EventHandler
:CheckRegister
:EventServer
loop EH
10 AGENT_REGISTER()
addEntity()
register()
EVENT_REGISTER()
registerEventHandler() EVENT_REGISTER_ACK()
confirmRegistration()
eventHandlerRegistered()
AGENT_READY()
AGENT_READY_ACK()
Figura 3.6:Inicializa¸c˜ao de um Agente Musical no processamento em lote
Inicialmente, o agente envia uma solicita¸c˜ao de registros ao Agente Ambiente atrav´es do co-mandoAGENT_REGISTER, que ir´a adicionar o agente ao mundo virtual (m´etodoaddEntity()). Em seguida, o agente inicia um processo paralelo CheckRegister, respons´avel por verificar que todos os EventHandlers foram registrados, e come¸ca a registrar cada um de seus atuadores e sensores (re-peti¸c˜oes do fragmentoloopEH).
Para cada EventHandler, um comandoEVENT_REGISTER ´e enviado ao ambiente, que ir´a re-gistrar o Atuador ou Sensor correspondente no respectivo EventServer e retornar um comando EVENT_REGISTER_ACKconfirmando o registro. O Agente Musical avisa oEventHandler em ques-t˜ao da confirma¸c˜ao no ambiente, que termina sua configura¸c˜ao e indica o fato ao agente, para que o processo CheckRegister consiga controlar quais objetosEventHandler foram registrados.
Finalmente, depois que todos os objetos do tipo EventHandler tenham sido registrados no am-biente, um comando AGENT_READY ´e enviado ao ambiente. Este confirma o recebimento atrav´es do comando EVENT_REGISTER_ACK, fazendo com o que o Agente Musical aguarde o in´ıcio do pr´oximo turno para iniciar o seu processamento.
3.5.3 Ciclo de Vida de um Componente
Todos os componentes do Ensemble (agentes, componentes musicais, servidores de eventos, in-terfaces de comunica¸c˜ao, representa¸c˜oes do mundo e leis) implementam a interfaceLifeCycle como forma de uniformizar o ciclo de vida desses componentes. Essa abordagem permite uma maior fle-xibilidade para a extens˜ao de componentes, enquanto assegura o controle que o arcabou¸co necessita.
A execu¸c˜ao dos m´etodos fica a cargo de quem est´a criando o componente. Por exemplo, ao se
Tabela 3.3: Ciclo de vida de um componente do arcabou¸co
setParameters() → configure() →start() →init() →
<Todos> processCommand() parameterUpdated() Reasoning process()
newSense(),needAction()
eventHandlerRegistered(),eventHandlerDeregistered() Sensor, Actuator process()
registerListener(),deregisterListener() EventServer process()
processAction(),actuatorRegistered(),actuatorDeregistered() processSense(),sensorRegistered(),sensorDeregistered()
→ stop() → finit()
adicionar umSensor a umMusicalAgent, o ´ultimo ´e respons´avel pela correta chamada de todos os m´etodos da interfaceLifeCycle. Os m´etodos da interface s˜ao os seguintes, em ordem de chamada:
• setParameters(Parameters parameters): respons´avel por passar os parˆametros necess´arios para a configura¸c˜ao do componente, armazenando um objeto da classeParameters;
• configure(): implementado pelo usu´ario para fazer qualquer tipo de mudan¸ca na configura¸c˜ao do componente antes de sua inicializa¸c˜ao;
• start(): chamado pelo arcabou¸co para executar as tarefas internas de inicializa¸c˜ao do compo-nente;
• init(): inicializa¸c˜ao implementada pelo usu´ario, chamada automaticamente porstart();
• parameterUpdate(String name, String newValue): chamado pelo arcabou¸co quando o valor de um parˆametro de nomename ´e atualizado com um novo valornewValue;
• stop(): usado pelo arcabou¸co para executar as tarefas internas de finaliza¸c˜ao do componente;
• finit(): finaliza¸c˜ao implementada pelo usu´ario, chamada automaticamente porstop().
Durante a execu¸c˜ao de uma simula¸c˜ao, ´e poss´ıvel controlar v´arios aspectos do sistema atrav´es de comandos de controle, como criar agentes musicais, adicionar componentes, ou alterar parˆametros de execu¸c˜ao. Os comandos podem ser emitidos internamente pelos pr´oprios agentes, ou ent˜ao por um agente externo. O mecanismo utilizado para essa troca de comandos est´a detalhado na se¸c˜ao 3.4.1.
A tabela 3.3 ilustra a ordem com que os m´etodos da interface LifeCycle s˜ao chamados e os m´etodos (em negrito) que podem ser implementados pelo usu´ario em cada tipo de componente de forma a customizar sua aplica¸c˜ao.
3.5.4 Modo de Execu¸c˜ao em Lote
No caso do in´ıcio da simula¸c˜ao, quando o Agente Ambiente est´a esperando o registro de todos os agentes, ele tamb´em mant´em um processo paralelo do tipo CheckRegister. Assim que todos os Agentes Musicais foram registrados, o rel´ogio virtual ´e atualizado, iniciando a simula¸c˜ao.
3.5 CICLO DE VIDA 43 O fluxo de funcionamento do processamento em lote durante um turno ´e ilustrado no diagrama de sequˆencia da figura3.7. De forma a simplificar o diagrama, apenas um agente est´a presente, mas o fragmentopar Agents indica que o mesmo procedimento ´e feito para todos os Agentes Musicais de forma paralela.
:MusicalAgent :EnvironmentAgent
:Reasoning :EventServer
:CheckEndTurn :CheckEndTurn
:ReasonBatch
:VirtualClockService
par AGENTS
loop REASONING
loop ES run()
reasoningProcessDone() setWakeUp()
BATCH_TURN(num_events)
process() eventProcessed()
preUpdateClock()
updateClock()
Figura 3.7: Processamento de um turno no processamento em lote
Ao in´ıcio de um novo turno, as tarefas dos racioc´ınios programadas para executar nesse turno (ReasonBatch) s˜ao despertadas pelo servi¸co de agendamento de tarefas do rel´ogio virtual, e execu-tam o respectivo m´etodoprocess()de seu racioc´ınio. Os racioc´ınios, ao terminarem o processamento e poss´ıvelmente atuarem no ambiente enviando eventos, avisam o seu Agente Musical atrav´es do m´etodoreasoningProcessDone().
O Agente Musical mant´em um processo paralelo CheckEndTurn que aguarda a finaliza¸c˜ao do processamento de todos os racioc´ınios, enviando um comando BATCH_TURNao ambiente para in-dicar que o processamento do agente nesse turno terminou. Ele tamb´em ´e respons´avel por agendar a execu¸c˜ao do racioc´ınio para o pr´oximo turno, atrav´es do m´etodosetWakeUp().
Assim que todos os Agentes Musicais informaram que terminaram o turno e os Eventos foram processados, o Agente Ambiente inicia o processamento de cada Servidor de Eventos, indicado pelo fragmento loop ES, atrav´es da chamada ao m´etodo process(). Durante o processamento, os Servidores podem enviar eventos de resposta para os Agentes Musicais, caso necess´ario.
Em seguida, o Agente Ambiente deve aguardar o final do processamento, por parte dos Agentes Musicais, de todos os eventos de resposta enviados pelos Servidores de Evento. Esse passo pode ser omitido caso n˜ao existam eventos de resposta.
Finalmente, o Agente Ambiente executa o m´etodopreUpdateClock(), em que pode ser feita a atualiza¸c˜ao da interface gr´afica ou algum processamento global, e executa o m´etodoupdateClock(), finalizando esse turno.
3.5.5 Finaliza¸c˜ao de um Agente Musical
A finaliza¸c˜ao de um Agente Musical deve retirar do registro todos os seus sensores e atuadores antes de elimin´a-lo do ambiente. A figura 3.8 mostra o diagrama de sequˆencia do procedimento feito por cada Agente Musical.
:MusicalAgent :EnvironmentAgent :EventServer
:EventHandler
:CheckEndTurn :CheckDeregister
:KillAgent
:Deregister
loop EH
KILL_AGENT()
deregister()
EVENT_DEREGISTER()
deregisterEventHandler() EVENT_DEREGISTER_ACK()
confirmDeregistration()
AGENT_DEREGISTER()
stop()
Figura 3.8:Finaliza¸c˜ao de um Agente Musical no processamento em lote
O Agente Ambiente inicia o processo de finaliza¸c˜ao de um agente ao enviar o comando KILL_AGENT ao agente em quest˜ao. O Agente Musical, ao receber o comando, cria um processo paralelo, CheckEndTurn, para aguardar a finaliza¸c˜ao do turno atual. Este processo, por sua vez, ao detectar o fim do turno, cria dois novos processos paralelos, CheckDeregister e Deregister. O primeiro ´e respons´avel por aguardar a retirada do registro de todos os sensores e atuadores e o segundo pela retirada propriamente dita.
O fragmento loop EH, executado para cada sensor e atuador, chama o m´etododeregister() do EventHandler, que envia o comandoEVENT_DEREGISTER para o Agente Ambiente. Este, por sua vez, informa o Servidor de Eventos respons´avel, que retira oEventHandler do registro e confirma a a¸c˜ao enviando o comando EVENT_DEREGISTER_ACKpara o Agente Musical.
Uma vez que todos os EventHandler foram retirados do registro, o processo CheckDeregister aciona um novo processoKillAgent que ir´a finalizar o ciclo de vida do Agente Musical, retirando-o