A estrutura das classes funcionais do MultiPersOn pode ser resumida, conforme mos- trado na Figura 3.4, nos seguintes elementos: CDSManager, CDSBuilder, CDSProperties, CDSEngine, CDSQuartz e CDSResult.
Inicialmente os agentes são construído a partir da descrição na ontologia (CDSBuilder), sendo então armazenados no CDSManager, através de um mapeamento dos agentes com seus ativadores (Trigger). Quando o CDSManager recebe uma notifica- ção de um evento externo, ele checa se algum agente é ativado por esse evento. Caso seja ativado, o agente será enviado para o CDSEngine e sua lógica será executada con- comitante com a de outros agentes já em execução. Durante a execução os agentes po- dem usar o CDSResult para notificar o acontecimento de certos eventos de CDS, permi- tindo assim a interação com os dispositivos externos ou outras aplicações.
Figura 3.4 - Diagrama de classe UML simplificado, contendo as principais classes funcionais do MultiPersOn.
Agora que já temos algum conhecimento sobre o funcionamento do MultiPer- sOn, estamos aptos a entender detalhadamente cada uma das classes encontradas na Figura 3.4, a fim de compreendermos melhor o papel específico de cada uma delas.
Primeiramente, vamos nos concentrar na classe central do framework, que está em destaque na Figura 3.5, a classe CDSManager. Ela é uma implementação da interface ICDSManager, possuindo instâncias de outras três classes: CDSBuilder, CDSQuartz e CD- SEngine. Ela é a responsável por armazenar a lista de agentes passivos construídos a par- tir da ontologia, através da instância de CDSBuilder, para serem executados pela instân- cia de CDSEngine quando estes forem ativados. Para armazenar, de maneira eficiente, qual evento externo ativa quais agentes, foi criado um hash, chamado triggerMap, que tem como chave as informações que descrevem o evento de ativação e como valor uma lista de agentes a serem ativados pelo evento. No caso dos agentes ativos, eles são en- caminhados para a instância de CDSQuartz, onde são agendados para serem executados pela instancia do CDSEngine num dado instante de tempo.
Além da implementação dos métodos da interface ICDSManager, a classe CDSManager ainda possui os métodos init( ) e remove( ) que devem ser chamados respec- tivamente para carregar e para encerrar corretamente o framework. E ainda, os métodos mapInfraStrutucture(…) e mapResult(…) que servem, respectivamente, para adicionar re- cursos de infra-estrutura aos agentes e preparar os agentes para encaminharem seus e- ventos para o ambiente externo, de acordo com o que foi descrito por cada um deles na ontologia.
Figura 3.5 – Diagrama de classe UML da classe principal classe do framework.
Para iniciar a construção dos agentes, deve-se invocar o método buildAgents- Model() da classe CDSBuilder, ilustrado na Figura 3.6. Durante esse processo, necessita-se saber o endereço das ontologias utilizadas para descrever os agentes. Conforme será ex- plicitado no capítulo seguinte, existem duas ontologias, uma que descreve os agentes e outra de configuração que descreve os recursos utilizados pelos agentes. Esses endereços são processados através da classe CDSProperties que procura o valor do atributo multi-
person.cds.ontology.config e multiperson.cds.ontology.agents num arquivo es-
pecífico, utilizando valores pré-definidos caso não encontre este arquivo. Sabendo onde se encontram as ontologias, elas são então carregadas através da interface IOntologyBuil- der, que visa carregar e converter as ontologias de OWL para OO, de acordo com a es- trutura da Figura 2.6, permitindo assim a construção dos agentes.
Figura 3.6 - Diagrama de classe UML mostrando as estruturas responsáveis por informar o ende- reço das ontologias e carregá-las para construir os agentes.
É importante ressaltar que nesta etapa todos os agentes independentemente do tipo, seja passivo ou ativo, são carregados a partir das informações contidas nas ontolo- gias. Entretanto, o CDSManager envia os agentes ativos para serem agendados, através do método scheduler(…) da instância da classe CDSQuartz, mostrada na Figura 3.7, que,
por sua vez, utiliza o framework do Quartz para realizar esse agendamento. Para que esse agendamento seja possível, é preciso passar como parâmetro uma instância de Date, que representa a data limite de repetição da condição de iteração, o intervalo de iteração no formato dos escalonadores de tarefas dos sistemas baseados em Unix (cron), o agente que deve ser agendado para a execução, as informações referentes à ativação do agente e a instância do CDSEngine responsável por sua execução.
Figura 3.7 – Diagrama de classe UML contendo a classe responsável pelo agendamento da exe- cução dos agentes passivos.
Independentemente da forma com que os agentes cheguem para ser executa- dos, seja pela ativação de um evento externo ou pelo agendamento do Quartz, eles irão de uma maneira ou de outra ser enviados para a execução pela instância de CDSEngine. Essa execução é realizada através de um recurso gerenciado pelo próprio Java que cria um pool de threads sob demanda e utiliza o algoritmo de escalonamento round-robin, sen- do inicializado junto da instância do CDSEngine por meio do método init( ), conforme explicitado na Figura 3.8. Para manter um maior controle e informar ao ambiente ex- terno quais agentes estão sendo executados, o CDSEngine guarda uma lista dos agentes em execução, isto é, List<AgentWrapper,> e possibilita o acesso a essa informação atra- vés do método getAgentsRunning( ).
Mas, antes de serem executados os agentes precisam ser encaminhados para o CDSEngine. Isto é feito por meio do método activateAgent(…), que se responsabiliza em carregar o agente, utilizando as suas informações de ativação. Estas informações são imprescindíveis para conseguir carregar corretamente seu contexto, loadContext(…), permitindo então prosseguir para sua execução.
Figura 3.8 – Diagrama de classe UML da classe responsável pela execução dos agentes.
Durante sua execução, os agentes podem enviar informações ao ambiente ex- terno, através de eventos gerados pelo framework de CDS. Para lidar com isto, a instân-
cia da classe CDSResult, ao receber cada informação enviada pelo agente, tem o papel de gerar e encaminhar os eventos de CDS para o ambiente externo. Como é mostrado na Figura 3.9, ela necessita para isso das informações sobre a forma de interação do resul- tado que deseja ser enviado, Result, a mensagem que deseja ser enviada, List<Object>, possíveis propriedades da mensagem, Map<String, String>, e o contexto da aplicação no qual a mensagem é direcionada, IAppContext.
Figura 3.9 – Diagrama de classe UML da classe responsável por gerar e encaminhar os eventos ao ambiente externo.
O entendimento dessas classes funcionais do MultiPersOn é primordial para compreender o propósito do framework, pois além de caracterizar todo o seu funciona- mento, elas operam sobre as classes estruturais do framework que serão vistas a seguir.