Resultados Obtidos com o Uso do FAct
5.2 O BARIM Simulator
Uma forma simples e eficiente de se avaliar o impacto do framework no desenvolvimento de um simulador é a implementação do mesmo puramente em C++ e em seguida realizar uma nova implementação, desta vez com o FAct. Assim, seria possível realizar uma análise com relação às métricas de código, quantidade de linhas, número de classes, métodos e funções.
Para a realização deste experimento optou-se pela re-implementação do
BARIM Simulator, um simulador multiatores que foi desenvolvido por
Dominoni [Dominoni el al. 2007] na linguagem de programação Java [Deitel e Deitel 2007]. Ele tem como objetivo validar a aplicação do modelo de interações baseado na Teoria do Equilíbrio [Heider 1970] para a investigação da emergência de fenômenos de grupo. O modelo foi testado através da construção de uma ferramenta de simulação, com foco nos relacionamentos sociais emergentes de um grupo de atores agindo de acordo com o modelo.
Durante a simulação, atores com habilidades distintas trabalham cooperativamente para a realização de uma tarefa. No decorrer do desenvolvimento do FAct, este simulador foi implementado duas vezes a primeira, puramente em C++, enquanto a segunda foi desenvolvida utilizando o FAct.
Modelagem dos Atores
Os atores presentes no BARIM Simulator seguem um modelo baseados em três atributos, a saber (1) power, (2) skill e (3) motivation. O primeiro é quantidade de energia que o ator possui a realizar o seu trabalho. Já o segundo, skill, representa a capacidade que o ator possui para realizar as atividades que lhe são solicitadas durante a simulação. O último, motivation, representa estado atual da motivação do ator. Quanto mais motivado ele estiver, maior será o seu desempenho.
Devido à simplicidade deste modelo, na sua re-implementação optou-se por enriquecê-lo adicionando a dimensão neuroticism do modelo Big Five [Howard e Howard 1995] como forma de tornar a implementação mais complexa, podendo asssim utilizar melhor o framework. Esta dimensão representa a tendência que uma pessoa tem a apresentar emoções negativas, expressando raiva, angústia, depressão, por tudo isso ela também é conhecida como instabilidade emocional. No modelo de simulação adotado esta dimensão influencia no relacionamento entre os atores. Desta forma, quanto maior o seu valor mais difícil será o relacionamento de ator com os demais.
Implementação do BARIM Simulator
A arquitetura deste simulador, na sua versão implementada sobre o
FAct, é baseada em um reduzido conjunto de classes que representam tanto o
modelo de ator quanto as demais entidades da simulação, conforme mostrado na Figura 5.5.
Figura 5.5 – Classes que compõem o BARIM.
O modelo de ator é formado pela classe Agent, que contém seus atributos e os métodos responsáveis pela determinação do seu comportamento. Esta, por sua vez, herda da classe abstrata Thread, que permite a execução de cada agente em fluxo exclusivo, independente dos demais. Apesar desta independência de execução os atores se comunicam através de um modelo de mensagem, implementado pela classe Interaction, que estende o tipo mensagem proposto pelo FAct. Por fim, toda a lógica do desenvolvimento de uma tarefa por um ator é a grupada na classe
Avaliação do Uso do FAct no BARIM Simulator
Durante o desenvolvimento do BARIM Simulator diversas
funcionalidades do FAct puderam ser utilizadas. O gerenciador de atores e o gerenciador de comunicação foram aplicados no controle da comunicação dos atores, permitindo que um ator descobrisse os demais presentes na simulação , bem como o transporte de mensagens para os seus destinatários. Por sua vez, o modelo genérico de mensagem presente no FAct foi estendido adicionando os dados extras necessários ao contexto da simulação. Já a implementação genérica do padrão de projeto Singleton foi aplicada na classe TaskManager fazendo com que todos os atores pudesse compartilhar o mesmo objeto . Além disto, a ferramenta de modelagem de atores pôde ser aplicada no desenvolvimento dos atributos do atores resultando em arquivo um XML que era carregado pela classe DataLoader, responsável por instanciar tal arquivo em objetos que representam os atores durante a execução da simulação.
Porém, o principal resultado da implementação do BARIM Simulator sobre o FAct foi a análise comparativa da sua implementação puramente em C++ com a implementação realizada com FAct. O Quadro 5.2 mostra a análise comparativa das duas implementações.
Quadro 5.2 – Comparação entre a implementação do BARIM sem o FAct e com o FAct.
Métrica Sem o FAct Com o FAct Diferença
Linhas de Código 784 637 19% Classes 6 4 33% Métodos 65 39 40% Atributos 37 24 35% Enumerações 3 2 33% Pacotes 2 2 0% Funções 4 5 -25%
de Classes, 40% no número de métodos, 35% no número atributos e 33% na quantidade de enumerações. A redução no número de se deve ao fato de que as classes World e Logger presentes no simulador original foram substituídas respectivamente pelos serviços presentes em ActorsContainer e Logger do
FAct na segunda implementação. Já o número de métodos teve sua grande
redução devido ao uso da ferramenta de modelagem para atores . Desta forma, seus atributos puderam ser guardados na árvore genérica de atributos que o modelo de ator genérico do FAct possui. Isto significou que a maioria dos métodos de acesso aos atributos dos atores não se encontram presentes na segunda implementação do simulador. Por fim, a enumeração que o simulador baseado no framework não possui se deve ao modelo genérico da mensagem presente no projeto.
Contudo, um mesmo decrescimento não pode ser visto no número de linhas de código, que teve uma variação de apenas 19%. Diversos motivos justificam tal fato, o primeiro foi falta de um suporte para Threads [Lewis e Berg 1995] dentro do FAct, o que aumentou o tamanho da segunda implmentação em 45 linhas e introduziu uma classe a mais em seu código. Outro fator que não permitiu uma maior redução do número de linhas de código foi a própria natureza do BARIM Simulator, que por ser baseado em regras, não fez uso de diversas funcionalidades mais complexas do
framework, como o suporte a representações gráficas e o gerenciamento de
serviços que os atores provêem uns para os outros.
Já o número de pacotes permaneceu constante, pois não houve grandes diferenças do ponto vista arquitetural entre ambas as implementações. E o número de funções foi incrementado, visto que um método específico ao contexto do simulador e presente na classe World teve sua correspondência em uma função na segunda implementação.
Finalmente, a implementação do BARIM sobre FAct possibilitou a identificação de novas funcionalidades que foram incorporadas ao framework. As mais relevantes foram suporte a Threads a implementção da classe
DefaultActorFactory para ler arquivos com os modelos dos atores e uma
simplificação na forma de acesso aos atributos dos atores . Além disto, esta implementação permitiu a correção de pequenos bugs no FAct e a constatação de que mesmo quando aplicado no desenvolvimento de u m simulador relativamente simples, o FAct tem um impacto significativo nas métricas relativas ao código fonte do simulador.
5.3 Conclusões
No decorrer deste capítulo foram apresentados os dois simuladores desenvolvidos através do FAct: o MD-Simulation e o BARIM Simulatior. O primeiro simula interações entre um gerente e um desenvolvedor de software sendo construído para mostrar que é possível desenvolver um simulador multiator com FAct. Além disto, ele é o principal exemplo didático de um simulador construído sobre o framework. Enquanto que o BARIM Simulator foi implementado duas vezes, uma puramente em C++ e outra sobre o FAct. Tudo isto visando a realização de um experimento onde ambas as implementações foram comparadas, com relação às suas métricas de código.
Ao final do desenvolvimento do MD-Simulation e do BARIM Simulator pôde-se constatar não só que é possível construir simuladores multiatores com
FAct., mas também que o uso deste framework é relevante para a redução da
quantidade de código escrito durante a implementação de um simulador, influenciado assim a redução do tempo para o desenvolvimento de tais projetos e conseqüentemente seus custos.
73