Com o detalhamento das principais classes funcionais do MultiPersOn, podemos então analisar mais cuidadosamente cada uma das classes estruturais que são manipuladas por elas e que guardam todas as informações necessárias para o funcionamento do frame- work.
Para representar os agentes que foram construídos, guardando as informações necessárias para suas execução, utiliza-se a classe AgentModel, mostrada na Figura 3.10. Ela apresenta apenas uma série de campos contendo as informações que foram extraí- das da ontologia, além dos métodos de acesso e modificação (getters e setters) de cada campo.
Como os agentes necessitam ser ativados para executar, foi também preciso definir o que ativaria (Trigger) cada um deles. Por isso, definiu-se que toda ativação po- deria ativar um conjunto de procedimentos dentro da lógica do agente, dependendo da especificação do identificador único do evento externo, eventID, e do identificador único do alvo dessa ação, targetID. Isto permite que determinados trechos da lógica do agente sejam executados apenas se certas condições específicas forem alcançadas, aumentando o nível de controle sobre o agente e tornando a solução mais robusta.
Assim como os ativadores, foi criada uma classe para representar os recursos das aplicações que podem interagir com o MultiPersOn. Desta forma, todo recurso, ins-
tância da classe Resource, é composto por uma string que identifica esse recurso e uma lista de hashs que servem para representar as possíveis propriedades desse recurso.
Além disso, foi necessário definir alguns escopos, isto é, uma delimitação para a aplicação de um determinado contexto, para possibilitar a associação correta dos re- cursos utilizados na lógica dos agentes. Assim, conforme se pode visualizar na classe CDSScope, foram definidos quatro diferentes escopos: document, patient, user, application.
Figura 3.10 - Diagrama de classe UML das classes estruturais que definem as informações neces- sárias para a execução dos agentes.
Após o agente ser construído e ativado, ou seja, possuir uma instância de A- gentModel e uma de Trigger, este deve ser então carregado, isto é, deve possuir um con- texto da aplicação que está usando o framework, bem como, ter sua lógica carregada. O contexto da aplicação é representado pela instância da classe IAppContext, enquanto que a lógica do agente carregada pelo JSR-223 é representada interface do ScriptEngine. Nes- se instante, a instância de AgentModel deve ser transformada em uma instância de A- gentWrapper. Este funciona como um invólucro que engloba a instância de AgentModel, associando a ele o contexto da aplicação, a lógica do agente e, ainda, modificando e a- crescentando alguns comportamentos.
Agora que o agente foi carregado, ou seja, encapsulado pelo AgentWrapper, este pode então ser executado. Para que todos os agentes executem sua lógica independente uns dos outros, um novo objeto deve ser criado para lidar com esse problema, o AgentT-
hread. Este objeto implementa a interface Runnable, permitindo assim que seu método run() seja executado por uma das threads do ExecutorService. Ao iniciar a execução, de- pendendo das configurações de ativação do agente, um ou mais procedimentos da sua lógica podem ser executados através do método invokeFunction(…). Durante cada ativa- ção três procedimentos podem ser executados consecutivamente, sendo o segundo obri- gatório e os demais opcionais. O primeiro deles, beforeActivate, visa carregar valores pre- viamente armazenados, o segundo , activate, visa realizar o processamento da lógica e o último, afterActivate, visa armazenar os valores processados para serem utilizados poste- riormente. Ao final, o método destroy(…) será chamado para que todos os valores alte- rados sejam resetados e o agente descartado. Vale a pena notar que os agentes são des- cartados com o propósito de otimizar a performace da aplicação, pois como cada agente corresponde a uma thread caso eles permanecessem em execução, haveria para cada u- suário várias threads, acarretando assim na sobrecarga da aplicação.
Entretanto, antes da sua execução finalizar, o agente pode enviar alguma in- formação ao ambiente externo. Para permitir isto, foi criada a classe Result (Figura 3.11) que representa a forma de interação do resultado, isto é, sobre que dado o evento deve ser aplicado, data, qual evento do CDS deve ser lançado, cdsEvent, e qual o nome desse evento, name. Assim, de acordo com as características descritas por cada um dos agentes na ontologia, seus eventos de CDS serão injetados na sua lógica, podendo ser referenci- ados, através do atributo name dos seus eventos.
Figura 3.11 – Diagrama de classe UML das classes estruturais que definem as informações refe- rentes aos eventos.
Desta maneira, é possível saber como e para quem a informação deve ser envi- ada, mas falta ainda saber qual informação. Isto foi resolvido com a classe Return que,
além de uma instância da classe Return, possui uma lista de objetos, List<Object>, para representar a mensagem que será enviada ao ambiente externo, bem como, um hash, Map<String, String>, para permitir a representação das propriedades dessa mensagem.
Mas, como o framework visa ser utilizado por diferentes linguagens de scripts, a permissão deliberada da criação da instância de Return dentro da lógica do agente seria confusa e despadronizada. Assim, a classe ReturnFactory foi desenvolvida e injetada den- tro da lógica dos agentes, possibilitando que instancias de Return fossem criadas a partir de referencias para os Result previamente injetados. Isto, não apenas amarra as instân- cias da classe Return a uma instância da classe Result válida, mas também facilita e pa- droniza a elaboração dos eventos de CDS para o ambiente externo. Com a referência do objeto Return em mãos, basta apenas retornar o objeto no procedimento em execução para que este seja encaminhado para o CDSResult tratar.
Por fim, não tendo relação direta com a geração dos eventos de CDS, mas cor- relacionado a ele, existe a classe Events (Figura 3.11) que serve para informar sobre um conceito, ou melhor, um Resource, quais são os eventos de CDS e do ambiente externo que podem ser lançados sobre ele. Isto é muito útil para possibilitar uma melhor reativi- dade da interface com o usuário, permitindo que ela seja construída de acordo com as características de cada conceito.
Em suma, a classe AgentWrapper contém uma série de atributos que visam re- presentar de forma genérica um agente, fomentando assim a flexibilidade e portabilida- de dos métodos de CDS. Ao ser englobada pela classe AgentWrapper, cada agente passa a ter um identificador unívoco, um escopo, uma lista de ativadores (Trigger), uma lista com as diferentes formas de interação dos resultados (Result), um contexto dentro da aplicação, uma lógica a ser executada e um mapeamento de atributos e valores que se- rão injetados dentro da sua lógica para representar suas informações contextuais. Além disso, contém uma descrição sobre o próprio agente, o nome da linguagem utilizada na sua lógica, o nome da classe de infra-estrutura utilizada, juntamente com os nomes dos métodos para serem executados quando o agente for ativado (beforeActivate, activate e afterActivate). Todas essas informações são obtidas segundo a descrição de cada um dos agentes na ontologia, com exceção do seu identificador que é gerado no instante da sua criação e da lógica dos agentes que é carregada a partir de um arquivo em separado.