lnterets de la distribution de la loi nonnale

de sistemas multiatores foi desenvolvido M-D Simulation. Nele, interações

entre um gerente de projeto e um desenvolvedor de software são simuladas. Outro objetivo do projeto é servir como referência para implementação de simuladores multiatores baseados no framework.

Symlog: O modelo de personalidade adotado

Assim como no projeto SmartSim, o modelo de personalidade implementado nos atores foi baseado no Symlog [Bales e Cohen 1979]. Este modelo foi inicialmente desenvolvido para possibilitar uma melhor compreensão da liderança efetiva, dinâmica dos grupos e o desempenho de equipes de alta performance.

Amplamente difundido, o Symlog tem sido utilizado em diversas empresas como a Mercedes Benz, BASF, IBM e Microsoft, nos cincos continentes [Symlog 2008]. Classificando o comportamento e a interação dos grupos em um espaço tridimensional, o Symlog leva em consideração as

dimensões Dominância(U)/Submissividade(D), Amigável(P)/Não

Amigável(N) e Aceitação(A)/Não aceitação de autoridade e orientação à tarefa (B) [Silva et al. 2006a].

A primeira dimensão, Dominância(U)/Submissividade(D), classifica o indivíduo em relação ao seu comportamento frente ao grupo. Um indivíduo U é geralmente ativo e que normalmente demonstra uma tendência de impor seu ponto de vista ao grupo. Enquanto um indivíduo D normalmente é passivo, introvertido e submisso.

A segunda dimensão, Amigável(P)/Não Amigável(N), define o indivíduo em relação a sua socialização. Um indivíduo do tipo P possue normalmente um comportamento extrovertido, cooperativo e altruísta. Já um indivíduo N normalmente está associado a características de introversão, egocentrismo e auto-protecionismo.

Finalmente, a última dimensão, Aceitação(A)/Não aceitação de autoridade e orientação à tarefa (B) se refere a tendência que um indivíduo possui de aceitar ou rejeitar a autoridade de uma maneira geral. Um indivíduo do tipo A costuma aceitar respeitar e acatar a autoridade de outro

desacatar a autoridade de outro indivíduo. Modelagem dos Atores

Com base no modelo do Symlog, acima descrito, dois tipos de atores foram desenvolvidos, o Developer Actor e o Manager Actor. O primeiro simula o comportamento de um desenvolvedor de software enquanto que o segundo é um gerente de projeto. A seguir ambos os modelos serão detalhados.

Developer Actor

Criado para simular o comportamento de um desenvolvedor de software este ator possui diversos atributos necessários à simulação como mostra o Quadro 5.1. Sua personalidade é baseada nas três dimensões propostas pelo modelo Symlog. Seus atributos relativos ao conhecimento técnico em desenvolvimento de software são Elicitação/Análise de Requisitos (Analysis), Projeto de Arquitetura (Architecture) e Programação (Programming). Ele também possui o estado de seu relacionamento com os demais atores, indicando com quais ele possui mais afinidade. Outros atributos são a sua energia que é seu potencial para executar uma tarefa e sua motivação em relação a atividade de desenvolvimento de software . Por fim, ele também possui o seu nome, sua idade, seu sexo e seu salário.

Quadro 5.1 – Propriedades do Developer Actor.

Atributo Descrição

Skills Habilidades técnicas do ator

Analysis Capacidade de Elicitação/Análise de Requisitos

Architecture Aptidão para o projeto de Arquitetura de um software

Programming Competência para implementação (codificação)

Personality Modelo de personalidade baseado no Symlog

Power Dominância(U)/Submissividade(D)

Task Aceitação(A)/Não aceitação de autoridade(B) Outros Atributos

Energy Energia do ator, mede o quanto ele esta cansado

Motivation Força que impulsiona as ações ator

Name Nome do ator

Age Idade do ator

Sex Sexo do ator

Wage Salário do ator

Relationship Medida do relacionamento do ator com os demais membros da equipe.

Este ator pode, a cada momento, realizar uma das quatro ações descritas a seguir. São elas, (1) pedir descanso, (2) pedir ajuda para realizar uma tarefa, (3) trabalhar em uma tarefa e (4) reportar o conclusão de uma tarefa. Estas ações são tomadas levando em consideração tanto a personalidade do ator, quanto o estado de seus demais atributos. Com relação aos serviços oferecidos, esta entidade é responsável por prover os serviços de

Analysis, Architecture e Programming.

Manager Actor

Versão simplificada do Developer Actor, o Manager Actor é responsável pela simulação do comportamento de um gerente de um projeto. Ele possui a maioria dos atributos presentes no Developer Actor exceto pelas habilidades técnicas (Skills), motivação (Motivation) e energia (Energy). Entretanto, seu comportamento é completamente diferente. Suas ações são (1) delegar uma tarefa, (2) mandar o desenvolvedor descansar, (3) ajudar o desenvolvedor em uma tarefa, (4) dar opinião sobre uma tarefa realizada, ( 5) demitir o desenvolvedor. Assim como no Developer Actor¸ este ator tem a tomada de suas decisões realizadas através de seu modelo de personalidade e o estado de seus demais atributos. Com relação aos serviços oferecidos, esta entidade é responsável por prover apenas o serviço de Management.

Forge Flex, A biblioteca gráfica utilizada

O Forge16V [Madeira e Ramalho 2001; Rocha et al. 2003] é um motor gráfico para a implementação de jogos 2D e isométricos em C++. Sendo uma extensão do Forge16V, o Forge Flex [Silva et al. 2006b] foi criado durante o desenvolvimento do projeto SmartSim. Ele agrega diversas mudanças ao projeto bem como uma biblioteca de componentes gráficos. O Forge Flex foi selecionado para o desenvolvimento do M-D Simulation por dois motivos principais. Primeiro, é distribuído sobre a licença GNU GPL [GPL 2006]. Segundo, devido a experiência na utilização do mesmo pelos desenvolvedores da aplicação durante o projeto SmartSim.

Arquitetura do simulador

Constituída basicamente por 2 pacotes, a implementação do M-D

Simulation foi criada para atender a simulação dos modelos de atores

descritos anteriormente. Os pacotes que a compõem são Model e o GUI. O primeiro, Model, contém os modelos de atores e entidades da simulação. Enquanto que o segundo, GUI, agrupa as classes que compõem a interface gráfica da aplicação.

O Pacote Model

Criado para agrupar as entidades básicas da simulação, este pacote possui tanto os modelos de atores sintéticos adotados como as entidades presentes na simulação como o projeto e suas tarefas.

As classes que implementam os modelos de atores criados podem ser vistas na Figura 5.1. Nela esta presente a classe GenericActor que foi elaborada para conter todos os atributos comuns aos atores do simulador. Ela herda da classe SynteticActor presente no Fact além de ser uma das principais classes do M-D Simulation. Esta importância pode ser verificada já que as classes DeveloperActor, que representa a implementação do ator desenvolvedor, e a classe ManagerActor, que representa a implementação do

ator gerente, são subclasses de GenericActor. Ambas as classe,

DeveloperActor e ManagerActor, possuem apenas a implementação dos

comportamentos dos respectivos atores que elas representam.

Figura 5.1 – Classes que implementam os modelos de atores desenvolvidos para o MD-Simulation.

Já as demais entidades da simulação podem ser vistas na Figura 5.2. Nela está presente a classe Project que é responsável por representar um projeto de software no qual o gerente e o desenvolvedor irão trabalhar. Este projeto, por sua vez, é composto por um conjunto de atividades que concebidas por instâncias da classe Task. A classe MessageInfluence é responsável por guardar as influencias relevantes das mensagens troca das pelos agentes nos atributos destes. Por exemplo, quando um desenvolvedor é elogiado isto é bom para o seu relacionamento com o gerente além de também

uma mensagem enviada são guardadas em objetos do tipo MessageInfluence. Por fim, todas as classes presentes neste pacote foram desenvolvidas de maneira independeste da tecnologia utilizada para a criação da interface gráfica do ator, o que permite a utilização delas em conjunto com qualquer outra biblioteca gráfica.

Figura 5.2 – Demais entidades do MD-Simulation.

O pacote GUI

Desenvolvido para conter as classes da interface gráfica do simulador, este pacote possui um conjunto de entidades, Figura 5.3, que estão ligadas diretamente ao motor gráfico utilizado, no caso, o Forge Flex.

Representado pelo estado MainSimulationState, a interface do simulador é decomposta em 5 panels. Eles são responsáveis por exibir o informações dos atores, MagerPanel e DeveloperPanel. Além de mostrar informações sobre a tarefa em execução, TaskPanel, e informações sobre as

mensagens e suas influências nos atributos dos atores, MessagesPanel. Para expor as informações sobre o desenvolvedor do projeto o AboutPanel foi criado. Todos estes panels herdam da classe CF16VBasicPanel que é parte do

ForgeFlex. Além disso, as classes MainSimulationState e AboutPanel

implementam a interface IF16VActionListener para poderem captar eventos oriundos dos botões que possuem. Já classe ActorRepresentation é a uma especialização do modelo de representação gráfica para atores presentes no

Fact, a classe ActorRepresentation. Finalmente, a classe ApplicationStarte é

responsável por configurar e inicializar as objetos da simulação.

Figura 5.3 – Classes que compõem a interface gráfica do MD-Simulation.

Um exemplo de Interação

Nesta seção será abordado um exemplo de uma iteração entre os atores do simulador. Este exemplo, Figura 5.4 , se baseia no laço principal da simulação, onde o desenvolvedor trabalha em uma tarefa delegada pelo gerente.

Figura 5.4 - Exemplo de interação entre o desenvolvedor e seu gerente.

Na figura, podemos observar os atributos do gerente e do desenvolvedor nos lados direito e esquerdo, respectivamente. Já o centro mostra as últimas mensagens trocadas pelos atores além de suas influencias no estado dos atores. A interação se inicia na primeira mensagem, bola com o número 1 na figura. Ela demonstra do gerente solicitando ao seu desenvolvedor que trabalhe em uma tarefa. O gerente só sabe que o desenvolvedor é capaz de resolvê-la, pois ele consultou o gerenciador de serviços do Fact para tal.

No momento da solicitação de trabalho o desenvolvedor se encontrava motivado, com bastante energia e possuía um bom relacionamento com seu patrão. Assim, ele aceita a tarefa, como indicado pelo número 2 na figura, e então começa trabalhar nela. Quando o desenvolvedor termina o seu trabalho, ele informa o ocorrido ao seu gerente. Este último faz uma avaliação do trabalho realizado, levando em consideração o prazo de entrega estimado, o tempo de realização da atividade e o número d e erros encontrados. Neste caso, como os indicadores da tarefa estavam de acordo com o esperado os gerentes elogia o desempenho do seu subordinado, como mostrado pelo

1 2 3 4

número 4 na figura. Este elogio acaba por influenciar positiv amente o relacionamento entre os dois além da motivação do desenvolvedor.

Avaliação do Uso do FAct no MD-Simulation

As classes do FAct foram úteis em diversos momentos no desenvolvimento do simulador. Primeiramente, as classes que representam os atores da simulação herdam do modelo genérico presente no framework. Desta forma, as propriedades que ambos possuem são armazenadas na árvore de atributos citada anteriormente. Outra funcionalid ade utilizada no FAct, é o suporte a páginas brancas e amarelas. Assim, quando um ator é criado no MD-

Simluation, ele guarda os serviços que oferece, uma funcionalidade provida

pelo framework, além de registrá-los no gerenciador de serviços (páginas amarelas) que também faz parte do FAct. Isto facilita consideravelmente, por exemplo, a implementação da interação “pedir ajuda”, pois o ator que necessita de ajuda solicita ao gerenciador de serviços um ator capaz de fornecer tal serviço e, em seguida, só precisa iniciar o processo comunicação com o mesmo.

Já a comunicação entre os atores também é realizada através do FAct. Inicialmente, todas as mensagens trocadas entre os atores são instâncias da classe criada no framework para representar mensagens. Em seguida, elas também são enviadas através do gerenciador de comunicação desenvolvido no

FAct.

Na interface gráfica da simulação, as representações gráficas dos atores estendem o modelo proposto pelo FAct e são guardadas no gerenciador de representações do framework, o que facilita consideravelmente o processo de re-pintura das representações a cada ciclo da simulação.

O gerenciador de logs foi utilizado para imprimir no console todas as mensagens trocadas durante simulação. Por fim, vale ressaltar que o design

pattern Singleton foi utilizado no desenvolvimento da classe responsável por

A construção desta aplicação também permitiu a criação de um ambiente de simulação onde foi possível verificar a aplicabilidade do Symlog na simulação de atores em um ambiente de simulação. Além disto, também foi possível avaliar a real aplicabilidade do FAct para a construção de sistemas multiatores, através da verificação de quais dos seus módulos são utilizados mais freqüentemente e se o funcionamento dos mesmos está de acordo com o esperado.

Apesar dos execelentes resultados obtidos com o FAct no desenvolvimento do MD-Simulator mostrando que já era possível se construir simuladores multiatores com FAct, fazia-se necessário o desenvolvimento de novos simuladores, desta com o foco na anavalicação do real impacto do FAct na implementação de um simulador multiator. Em outras palavra s, em quando a utilização do FAct reduz a quantidade de código escrito em um simulador multiator.