Sistema de edição de componentes e estados para simulador de manutenção mecânica de motores de F-16

SISTEMA DE EDIÇÃO DE COMPONENTES E ESTADOS

PARA SIMULADOR DE MANUTENÇÃO MECÂNICA DE

MOTORES DE F-16

DISSERTAÇÃO DE MESTRADO APRESENTADA POR

ANDRÉ FILIPE MONTEIRO PINHEIRO

Sob orientação dos Professores Doutores

Leonel Caseiro Morgado e Hugo Alexandre Paredes Guedes da Silva

UNIVERSIDADE DE TRÁS-OS-MONTES E ALTO DOURO

ESCOLA DE CIÊNCIAS E TECNOLOGIA

DEPARTAMENTO DE ENGENHARIAS

2013

Dissertação apresentada por André Filipe Monteiro

Pinheiro à Universidade de Trás-os-Montes e Alto Douro para o

cumprimento dos requisitos necessários à obtenção do grau de

Mestre em Engenharia Informática, sob a orientação dos

Professores Doutores Leonel Caseiro Morgado e Hugo Alexandre

Paredes Guedes da Silva.

iii

RESUMO

Apesar de todos os avanços que têm vindo a ser feitos, o desenvolvimento de sistemas

de simulação, atualmente, requer ainda um investimento significativo a vários níveis: recursos

humanos, fases de análise e estudo do sistema a simular, planeamento e implementação final.

Desta forma, o sistema final é na maioria das vezes bastante rígido, dependente da plataforma

e das tecnologias de implementação.

A Universidade de Trás-os-Montes e Alto Douro e a Força Aérea Portuguesa

estabeleceram um protocolo onde acordaram uma colaboração entre as duas instituições no

âmbito do qual foi desenvolvido, por uma equipa que integrei, um protótipo de simulador

multiutilizador de manutenção mecânica dos motores Pratt&Whitney F-100 utilizados nas

aeronaves F-16, que permite aos utilizadores participar numa equipa que reproduz as tarefas

de instalação de um motor dentro da fuselagem da aeronave.

Apesar de este protótipo ter sido concebido sempre com o cuidado de separar a parte

lógica da parte visual da simulação, o registo de cada componente, bem como as suas

características e comportamento, tinham de ser implementados sempre por programadores.

Esta dissertação permitiu expandir a separação entre a parte lógica e a parte visual,

possibilitando a criação de um sistema que permite que o registo de componentes e

comportamentos possa ser efetuado sem qualquer intervenção de programadores,

contribuindo assim, para a evolução do conhecimento na área da agilização entre as fases de

conceção e implementação de simuladores, e para a redução dos custos de produção ou

reformulação de simulações, potenciando a sua aplicação em maior escala e em novos

cenários.

Palavras-chave

máquinas de estados hierárquicas, mundos virtuais, ensino virtual, trabalho cooperativo,

simulação, user-friendly

v

ABSTRACT

Despite all the advances that have been made on the development of simulation

systems, currently such development still requires significant investment at various levels:

human resources, analysis & study of system to simulate, development planning, and final

implementation. Therefore, the final system is most often quite rigid, dependent on the

development platform and associated technologies.

The University of Trás-os-Montes e Alto Douro and the Portuguese Air Force

established a cooperation protocol under which a team in which I participated developed a

multiuser simulator prototype for mechanical maintenance of the Pratt & Whitney F-100

engines used in F-16 aircraft. This simulator enables users to role-play as part of a team

performing the tasks for installation of an engine inside the fuselage of the aircraft.

Although this prototype was entirely designed with the care to separate the logic of

the visual parts of the simulation, the registration of each visual component, and its

characteristics and behavior, all were aspects that had to be implemented by programmers.

The work supporting this dissertation expanded the separation between the logical

and visual parts, enabling the creation of a system that allows the registration of visual

components and behaviors to be performed by a user without any intervention by

programmers, thereby contributing to the evolution of knowledge in the area of streamlining

between the stages of design and implementation of simulators, and potentially on the

reduction of costs on production or updating of simulations, which would enable their

application in a larger scale, to a wider range of scenarios.

Keywords

hierarchical state machines, virtual worlds, virtual learning, cooperative work, simulation, user-

friendly

vii

AGRADECIMENTOS

A realização da presente dissertação exigiu um grande esforço e dedicação, no

entanto, a sua concretização não seria possível sem o auxílio e apoio de algumas pessoas, às

quais gostaria de expressar os meus mais sinceros agradecimentos.

Em primeiro lugar quero agradecer aos meus pais. Sem eles hoje seria totalmente

impossível estar aqui. Deram-me a educação e carinho que todas as pessoas deveriam ter,

fizeram enormes sacrifícios para que eu conseguisse alcançar tudo o que hoje tenho, sem

nunca esquecer os princípios e valores que me incutiram, fazendo de mim a pessoa que sou

hoje. A eles, devo-lhes tudo.

À Universidade de Trás-os-Montes e Alto Douro, pelas excelentes condições de

trabalho que proporciona, e por todas as oportunidades de investigação concedidas. Os meus

agradecimentos vão também para os meus orientadores, Professor Doutor Leonel Morgado e

Professor Doutor Hugo Paredes, as suas orientações, as suas ideias e toda a disponibilidade

foram a chave para a realização de todo este trabalho, ultrapassando todas as dificuldades que

iam surgindo. Quero também agradecer aos restantes professores que me acompanharam

neste projeto desde 2010, Professor Doutor Benjamin Fonseca e Professor Doutor Paulo

Martins, que assim, fizeram parte da minha evolução enquanto investigador.

Quero fazer um agradecimento especial ao meu colega e amigo, César Meira. Os teus

sábios conselhos e ideias foram cruciais para que conseguisse ultrapassar certos obstáculos

que foram surgindo. Obrigado por todo teu companheirismo, apoio e auxílio nesta etapa.

Agradeço também aos meus colegas e amigos que estiveram sempre comigo ao longo

desta última etapa, Filipe Fernandes, António Correia, Jorge Freitas e Jorge Miguel. Obrigado a

todos vocês, por todos os momentos de companheirismo, motivação e amizade.

Quero também agradecer do fundo do coração aos meus amigos, que partilharam

comigo grande parte da vida universitária. António Botelho, Alexandra Vasques, José

Mendonça e Paulo Fernandes quero agradecer-vos por todos os momentos de amizade,

companheirismo e espirito de entreajuda com que me brindaram ao longo dos últimos anos,

vocês foram sem dúvidas os meus pilares de apoio durante esta fase da minha vida.

Por último, mas não menos importante, quero agradecer à minha irmã, por toda a

paciência e apoio, bem como pela tua confiança nas minhas capacidades que foi determinante

para eu ter conseguido levar todo este trabalho até ao fim.

ix

ÍNDICE

Resumo ......................................................................................................................................... iii

Abstract ......................................................................................................................................... v

Agradecimentos ............................................................................................................................ v

Lista de figuras .............................................................................................................................. xi

Lista de tabelas ............................................................................................................................. xii

Lista de Gráficos .......................................................................................................................... xiii

Glossário, acrónimos e abreviaturas ........................................................................................... xiv

Capítulo 1: Introdução................................................................................................................... 1

1.1 Enquadramento............................................................................................................. 2

1.2 Motivação e contribuições ............................................................................................ 3

1.3 Objetivos ....................................................................................................................... 3

1.4 Estrutura ........................................................................................................................ 4

Capítulo 2: Contextualização ......................................................................................................... 7

2.1 Enquadramento do Projeto ........................................................................................... 8

2.1.1 Plataforma Tecnológica ....................................................................................... 10

2.1.2 Recolha de dados e especificação ....................................................................... 11

2.1.3 Protótipo ............................................................................................................. 16

2.2 Envolvente Conceptual ............................................................................................... 18

2.3 Trabalho Relacionado .................................................................................................. 20

2.3.1 Método ................................................................................................................ 20

2.3.2 Trabalho relacionado .......................................................................................... 21

Capítulo 3: Arquitetura-Base – Apresentação e Análise ............................................................. 25

3.1 Apresentação da Arquitetura ...................................................................................... 26

3.2 Sistema de Decisão e Controlo .................................................................................... 26

3.3 Script LSL como Módulo View Genérico ..................................................................... 30

3.4 Protocolos de Comunicação ........................................................................................ 31

Capítulo 4: Nova Arquitetura: Protótipo ..................................................................................... 35

4.1 Metodologia Adotada ................................................................................................. 36

4.2 Identificação do Problema .......................................................................................... 37

4.3 Especificação dos Novos Requisitos ............................................................................ 38

4.4 Evolução do Sistema de Decisão e Controlo ............................................................... 38

4.5 Evolução do Protocolo de Comunicação ..................................................................... 42

x

4.6 Evolução do Script LSL como Módulo View Genérico ................................................. 44

4.7 Estrutura dos Dados .................................................................................................... 44

4.8 Interface Gráfica .......................................................................................................... 47

Capítulo 5: Testes com utilizadores ............................................................................................ 53

5.1 Ambiente de Testes ..................................................................................................... 54

5.2 Caracterização da amostra .......................................................................................... 55

5.3 Análise de Resultados ................................................................................................. 61

Capítulo 6: Conclusões e trabalho futuro ................................................................................... 69

6.1 Conclusão .................................................................................................................... 70

6.2 Reflexões Finais ........................................................................................................... 70

Referências bibliográficas ........................................................................................................... 73

Anexos ......................................................................................................................................... 79

xi

LISTA DE FIGURAS

Figura 1 - Hangar na BA5 ............................................................................................................... 8

Figura 2 - Motor Pratt&Whitney F100 .......................................................................................... 9

Figura 3 - Exemplo de uma imagem associada à parte de uma tarefa descrita nas TO ............. 12

Figura 4 - Diagrama de casos de uso para a tarefa "Elevar Motor" ............................................ 14

Figura 6 - Diagrama de estados para a tarefa "Elevar Motor" .................................................... 15

Figura 6 - Diagrama de atividades para a tarefa "Elevar Motor" ................................................ 15

Figura 7 - Diagrama de classes para a tarefa "Elevar Motor" ..................................................... 16

Figura 8 - Hangar (Ambiente 3D) ................................................................................................ 16

Figura 9 - Escadas de acesso à aeronave (Ambiente 3D) ............................................................ 17

Figura 10 - HUD que representa equipamento na mãos direita e esquerda .............................. 17

Figura 11 - HUD em forma de setas para descer ou subir apoios ............................................... 18

Figura 12 – Sistema de interação genérico (Fonseca et al., 2011) .............................................. 27

Figura 13 - Sistema de Decisão e Controlo .................................................................................. 27

Figura 14 - Diagrama E-R da base de dados (Fernandes, 2012) .................................................. 28

Figura 15 - Diagrama de classes .................................................................................................. 29

Figura 16 - Exemplo do funcionamento de um estado com mais que uma resposta diferente . 30

Figura 17 - Ciclos da metodologia Design Science (Hevner, 2007) ............................................. 36

Figura 18 – Diagrama de classes (nova arquitetura) ................................................................... 39

Figura 19 – Fluxograma do funcionamento básico do Sistema de Decisão e Controlo .............. 41

Figura 20 - DTD do ficheiro de configuração dos objetos ........................................................... 45

Figura 21 - Árvore de componentes do ficheiro de configuração dos objetos ........................... 45

Figura 22 - Árvore de componentes do ficheiro de configuração da simulação ........................ 46

Figura 23 - DTD do ficheiro de configuração da simulação ......................................................... 46

Figura 24 - Janela inicial e menu da simulação (Editor do sistema) ............................................ 47

Figura 25 - Janela de configuração dos objetos (Lista de objetos) ............................................. 47

Figura 26 – Janela de configuração dos objetos (Registar novo objeto) .................................... 48

Figura 27 - Janela de configuração dos estados (lista de estados) ............................................. 49

Figura 28 - Janela de configuração dos estados (adicionar ações) ............................................. 49

Figura 29 - Janela de configuração dos estados (adicionar restrições) ....................................... 50

Figura 30 - Janela de configuração dos estados (adicionar tarefas) ........................................... 50

xii

LISTA DE TABELAS

Tabela 1 - Protocolo de comunicação: Sistema de Decisão Controlo – Ambiente 3D ................ 32

Tabela 2 - Protocolo de comunicação: Ambiente 3D – Sistema de Decisão e Controlo (Objeto

Criado) ......................................................................................................................................... 32

Tabela 3 - Protocolo de comunicação: Ambiente 3D – Sistema de Decisão e Controlo ............. 33

Tabela 4 - Protocolo de comunicação: Ambiente 3D – Ambiente 3D ......................................... 33

Tabela 5 - Novo Protocolo de comunicação: Sistema de Decisão Controlo – Ambiente 3D ...... 43

Tabela 6 - Exemplo de comunicação do tipo: Sistema de Decisão Controlo – Ambiente 3D ..... 43

xiii

LISTA DE GRÁFICOS

Gráfico 1 - Classificação dos utilizadores quanto à idade ........................................................... 55

Gráfico 2 - Classificação dos utilizadores quanto à frequência com que usa o computador ..... 56

Gráfico 3 - Classificação dos utilizadores quanto à finalidade com que usam o computador.... 56

Gráfico 4 - Classificação dos utilizadores quanto aos mundos virtuais que conhecem .............. 57

Gráfico 5 - Classificação dos utilizadores quando à utilização de mundos virtuais .................... 57

Gráfico 6 - Classificação dos utilizadores quanto aos mundos virtuais que utilizou .................. 58

Gráfico 7 - Classificação dos utilizadores quanto à finalização com que usaram mundos virtuais

..................................................................................................................................................... 58

Gráfico 8 - Classificação dos utilizadores quanto à obtenção de formação para utilizar mundos

virtuais ......................................................................................................................................... 59

Gráfico 9 - Classificação dos utilizadores quanto ao mundo virtual para o qual obtiveram

formação ..................................................................................................................................... 59

Gráfico 10 - Classificação dos utilizadores quanto à capacidade de utilização de mundos virtuais

..................................................................................................................................................... 60

Gráfico 11 - Classificação dos utilizadores quanto à obtenção de formação para programar em

mundos virtuais ........................................................................................................................... 60

Gráfico 12 - Classificação dos utilizadores quanto à capacidade de programação em mundos

virtuais ......................................................................................................................................... 61

Gráfico 13 - Análise dos tempos de execução das tarefas .......................................................... 62

Gráfico 14 - Análise das dúvidas que surfiram na execução das tarefas .................................... 63

Gráfico 15 - Analise dos erros praticados na execução das tarefas ............................................ 63

Gráfico 16 - Classificação do sistema quanto à facilidade de utilização ..................................... 64

Gráfico 17 - Classificação do sistema quanto à intuitividade...................................................... 64

Gráfico 18 - Classificação do sistema quanto à facilidade de aprendizagem ............................. 65

Gráfico 19 - Classificação do sistema quando à facilidade de criação de conteúdo ................... 65

Gráfico 20 - Classificação do sistema quanto a ser acessível a qualquer pessoa que use

computador ................................................................................................................................. 66

Gráfico 21 - Classificação do sistema quanto ao potencial na criação de simulações ................ 66

Gráfico 22 - Análise das dificuldades sentidas ............................................................................ 67

Gráfico 23 - Classificação do tipo de dificuldades ....................................................................... 67

xiv

GLOSSÁRIO, ACRÓNIMOS E ABREVIATURAS

BA5 – Base Aérea n.º 5

CFMTFA – Centro de Formação Militar e Técnica da Força Aérea

COTS – Commercial Off The Shelf

CVE – Collaborative Virtual Environments

DTD - Document Type Definition

FAP – Força Aérea Portuguesa

HCI – Human-Computer Interaction

HLA – High-level Architecture

LMS – Learning Management Systems

LSL – Linden Scripting Language

MMORPG – Massive Multiplayer Online Role-Playing Games

SL – Second Life

SLOGP – Second Life Grid Open Grid Protocol

TO – Technical Orders

UTAD – Universidade de Trás-os-Montes e Alto Douro

XML – Extensible Markup Language

1

CAPÍTULO 1: INTRODUÇÃO

“Any sufficiently advanced technology is indistinguishable from magic.”

Arthur C. Clarke

Neste capítulo introdutório é feito um enquadramento lógico do problema, bem como

das contribuições e motivações que me levaram à escolha deste tema em concreto. São

também definidos os objetivos gerais que se tencionam alcançar, assim como a estrutura

desta dissertação, expondo resumidamente os aspetos que são abordados em cada um dos

próximos capítulos.

2

1.1 ENQUADRAMENTO

Atualmente, o desenvolvimento de sistemas de simulação requer investimento

significativo em termos de recursos humanos, quer nas fases de análise e estudo do sistema a

simular, quer no planeamento, quer na implementação final. O sistema final é, normalmente,

rígido, dependente da plataforma e das tecnologias de implementação.

No âmbito da investigação em curso na Universidade de Trás-os-Montes e Alto Douro

(UTAD), têm-se vindo a desenvolver abordagens de separação entre a implementação da

lógica das simulações e a concretização das mesmas em plataformas como os mundos virtuais.

A presente dissertação insere-se no trabalho em curso de colaboração entre a UTAD e a Força

Aérea Portuguesa (FAP), já alvo de publicação anterior por parte da equipa de orientação

(Fonseca et al., 2011). Nesse contexto, existe um protótipo de simulador multiutilizador de

manutenção mecânica dos motores Pratt&Whitney F-100 utilizados nas aeronaves F-16, que

permite reproduzir as tarefas de instalação de um motor dentro da fuselagem da aeronave e

sobre o qual já foram realizados testes de campo tendo sido já também alvo de publicação

anterior (Pinheiro et al., 2012).

Contudo, cada componente visual dessa simulação tem de ser concebido

individualmente – tarefa de design e modelação gráfica – e depois importado e adaptado por

programadores. As características comportamentais dos componentes visuais não são

necessariamente analisadas e estudadas por especialistas de desenvolvimento, mas

preferencialmente por especialistas em manutenção mecânica ou formação. Contudo, no

sistema de partida são também implementadas, obrigatoriamente, pelos programadores.

Existem trabalhos prévios, em diversas áreas, de agilização do processo de colaboração

entre projetistas/designers e implementadores. Refiram-se, por exemplo, trabalhos a nível do

desenvolvimento de páginas Web (Bulas-Cruz et al., 1998; Bulas-Cruz et al., 1999) ou mesmo a

nível da conceção e desenvolvimento de videojogos (Neves et al., 2010a; Neves et al., 2010b).

No que concerne a simulações baseadas em mundos virtuais, torna-se premente

salientar abordagens a nível de coordenação de movimentos (Lopes et al., 2008; Lopes et al.,

2009a; Lopes et al., 2009b), bem como no domínio da saúde com o treino de estudantes de

medicina em situações de reanimação cardiopulmonar (Creutzfeldt et al., 2010), medicina

dentária (Phillips & Berge, 2009), e educação médica (Wiecha et al., 2010). Este tipo de

tecnologia pode fomentar o ensino à distância de práticas complexas de colaboração e

possibilitar o uso de um conjunto de recursos para a comunicação em tempo real. No contexto

militar, a preparação para atividades de combate exige treino tático e operacional, aspetos

onde o uso de simulações assume um papel crucial para o sucesso de operações. Já na

3

vertente logística e de suporte o uso é menos generalizado, tendo o presente trabalho

potencial significativo para o desenvolvimento da área (Fonseca et al., 2011). A nível das suas

exigências técnicas, a utilização atual de simuladores para atividades de combate cria um

quadro de tecnologias de base e requisitos gerais para as organizações militares,

nomeadamente a nível das tecnologias de comunicação e coordenação entre simuladores

através de normas como a High-level Architecture (HLA) (IEEE Std, 2010), a qual se afigura no

contexto atual como a mais usada pelo setor.

1.2 MOTIVAÇÃO E CONTRIBUIÇÕES

A nível estritamente pessoal, esta é uma área que além da sua utilidade me desperta

uma grande motivação pessoal pelo facto de nos últimos dois anos ter estado ligado aos

trabalhos desenvolvidos nesta área pela equipa de investigação da UTAD associada a

desenvolvimento em mundos virtuais, área essa em que antes do meu envolvimento neste

projeto, em 2010, não tinha qualquer conhecimento ou preparação. Outra grande motivação

foi o facto de este projeto ser em parceria com a FAP, uma instituição com enormes

responsabilidades no país e onde a margem para erros é zero. Foi este ambiente desafiante

que me deu ainda mais energia e motivação para avançar até ao estado atual do trabalho.

Trabalhar com a FAP seria e foi algo que fiz com enorme orgulho.

Além de que a dissertação contribuirá para a evolução do conhecimento na área da

agilização entre as fases de conceção e implementação de simuladores, além de ter o

potencial, para contribuir para a redução dos custos de produção ou reformulação de

simulações, potenciando a sua aplicação em maior escala e em novos cenários.

1.3 OBJETIVOS

Esta dissertação tem como objetivo primordial satisfazer a necessidade sentida pela

FAP aquando da apresentação do protótipo supramencionado, de o mecânico formador poder

durante uma simulação alterar comportamentos de componentes em tempo real de forma a

analisar a reação dos formandos. De uma forma generalizada o objetivo desta dissertação

passa por expandir a separação entre lógica e a plataforma, possibilitando que o registo de

componentes e comportamentos possa ser efetuado sem intervenção dos programadores,

contribuindo assim para agilizar e flexibilizar o processo de desenvolvimento de simulações e

alteração das mesmas para adequação a novos requisitos.

4

Face ao conhecimento exaustivo que detinha acerca do estado de desenvolvimento do

protótipo supramencionado, em virtude de ter feito desde sempre parte das equipas que

efetuaram a sua conceção e desenvolvimento, tinha plena consciência de que, para cumprir o

objetivo acima referido, seria necessário realizar uma análise profunda a todo o sistema e com

base nela, não apenas reformular o sistema já existente, mas sim agarrar no seu conceito

teórico de modo a idealizar e desenvolver de raiz um novo sistema mais robusto e flexível.

Utilizando a metodologia Design Science (Hevner, 2007; Hevner et al., 2004),

pretendeu-se conceber um sistema que concretizasse as ideias expostas anteriormente,

permitindo testá-las com utilizadores. Desta forma, as fases de desenvolvimento dos trabalhos

de suporte a esta dissertação foram:

Enquadrar de forma mais aprofundada o tema no estado da arte da área, de modo

a sustentar e demonstrar de que forma esta dissertação contribui para o avanço na resolução

de alguns problemas atuais;

Realizar uma análise pormenorizada a todo o sistema de forma a identificar

limitações e problemas.

Formalizar novos requisitos do sistema em face do objetivo geral, de modo a

colmatar as limitações e os problemas encontrados;

Conceber um modelo teórico que permita concretizar um sistema face aos novos

requisitos especificados;

Implementar um protótipo que permita testar o modelo concebido;

Analisar os resultados obtidos e perspetivar possíveis linhas de trabalho futuro.

1.4 ESTRUTURA

A presente dissertação divide-se em seis capítulos independentes estando no entanto

ligados entre si, de uma forma coerente e sequencial. É também de salientar que a mesma

expõe todo o trabalho prévio que serviu de base a este trabalho e no qual estive envolvido em

todo o seu processo, sendo assim crucial a sua descrição. Assim, após o presente capítulo, a

dissertação está organizada da seguinte forma:

o Capítulo 2

Contextualização

Apresentação do enquadramento do projeto no qual esta dissertação se insere

e do estado em que o trabalho se encontrava aquando a iniciação da mesma.

5

Exposição de alguns conceitos genéricos e trabalhos relacionados nesta área,

através da análise de literatura.

o Capítulo 3

Arquitetura-Base – Apresentação e Análise

Descrição e análise da arquitetura que serviu de suporte a esta dissertação,

evidenciando e detalhando os aspetos essenciais, de todos os componentes que

fazem parte desta arquitetura.

o Capítulo 4

Nova Arquitetura: Protótipo

Apresentação da metodologia de desenvolvimento escolhida para conceber

um sistema que consiga cumprir os novos requisitos identificados com base nos

resultados da análise realizada anteriormente, e que permita testá-lo e validá-lo

com utilizadores. Descrição de toda a evolução dos diferentes componentes do

sistema, apresentação da estrutura de dados dos ficheiros de configuração do

sistema e da interface gráfica atualmente usada para a criação dos mesmos.

o Capítulo 5

Testes com utilizadores

Exposição dos testes realizados e do que se pretendia auferir com estes, numa

segunda parte são apresentados os resultados dos mesmos e destacadas as

evidências que se conseguiram extrair.

o Capítulo 6

Conclusões e trabalho futuro

Verificação do cumprimento dos objetivos propostos para esta dissertação e se

esta trouxe ou não as contribuições esperadas, perspetivando caminhos de

investigação futura com base nas limitações e necessidades encontradas ao longo

da investigação.

7

CAPÍTULO 2: CONTEXTUALIZAÇÃO

“It's still magic even if you know how it's done.”

Terry Pratchett

Neste capítulo é apresentado todo o enquadramento do projeto onde esta dissertação

se insere, bem como o estado em que o simulador se encontrava antes do trabalho de suporte

à dissertação. São referidas algumas definições presentes na literatura para explicar alguns

conceitos genéricos. Com base na análise da literatura da última década são também

apresentados trabalhos relacionados nesta área.

8

2.1 ENQUADRAMENTO DO PROJETO

A Força Aérea Portuguesa opera com aeronaves F-16, sendo a Base Aérea n.º 5 (BA5),

na Serra do Porto de Urso (Monte Real, Leiria), a especializada nestas aeronaves. Sendo

também a única no país onde estas aeronaves estão situadas e onde é efetuada toda a sua

manutenção.

As aeronaves F-16 da FAP estão equipadas com motores Pratt&Whitney F100-PW-

220E, sendo recomendado pelo fabricante a realização de inspeções periódicas, consoante o

número de hora de voo. É na BA5 que a generalidade desse trabalho é executada. Antes e

depois dos voos há sempre inspeções, mas a chamada “manutenção programada” de um F-16

é realizada de 300 em 300 horas de voo. Esta manutenção é executada por mecânicos

especializados da FAP, nos hangares da BA5 (Figura 1). Estes mecânicos tiveram que passar por

todo um processo de formação. Esse processo é iniciado logo após a seleção da especialidade

militar: numa primeira fase a formação realiza-se na base militar da Ota, no Centro de

Formação Militar e Técnica da Força Aérea (CFMTFA); numa segunda fase, a formação realiza-

se nas bases aéreas existentes em Portugal onde os mecânicos venham a ser colocados, tendo

em conta a especialidade de cada uma (Vilela et al., 2012).

Os militares destacados para a secção de operações da linha da frente, e para a

manutenção dos motores que equipam as aeronaves F-16, os já mencionados Pratt&Whitney

F100 (Figura 2), recebem inicialmente uma formação mais simples sobre as componentes

gerais das aeronaves F-16. Só posteriormente iniciam um curso de formação mais intensivo,

FIGURA 1 - HANGAR NA BA5

9

denominado “Curso de Motor F100-PW-220E Nível O”. Esta formação é constituída

atualmente por duas partes: uma parte teórica, onde são estudados todos os processos

descritos nos documentos técnicos fornecidos pelo fabricante destes motores (designados

“Technical Orders” ou TO), e por uma parte prática, já mesmo no terreno, que requer o uso

físico de materiais, motores e aeronaves. Este uso físico, além do desgaste de materiais que

provoca, faz com que esses materiais, motores e mesmo aeronaves fiquem indisponíveis para

qualquer tipo de missões ou emergências durante todo o tempo da formação, atribuindo a

estes momentos de formação um custo elevado. Além de um momento de formação sobre o

processo de instalação do motor na aeronave necessitar de bastante tempo (cerca de 6 horas),

existe ainda como custo associado o envolvimento de formadores (mecânicos especializados),

cuja disponibilidade poderia ser de valor acrescentado noutros serviços.

A manutenção mecânica de aeronaves F-16 é algo extremamente complexo, rigoroso,

delicado e exaustivo, que requer uma formação (acompanhada de treino) com precisão e

rigor; além de na maioria dos processos (como o processo já tido anteriormente como

exemplo - instalação do motor na aeronave) existirem várias tarefas colaborativas, exigindo

uma equipa de pelo menos três mecânicos. Especificamente, há tarefas que, embora

individuais, requerem a validação por outra pessoa, com a preparação adequada; e outras que

são impossíveis de concretizar em segurança e com rigor sem a colaboração de mais do que

um elemento. Para que a formação destes mecânicos possa também ser realizada em equipa,

de forma colaborativa, é necessário encontrar disponibilidades comuns de horário e alguma

homogeneidade de preparação prévia, por parte dos mecânicos. Estes constrangimentos

limitam as oportunidades para treino em equipa.

FIGURA 2 - MOTOR PRATT&WHITNEY F100

10

Durante uma reunião realizada há três anos e meio entre os militares da BA5,

responsáveis pela formação, e os membros da equipa de investigação da UTAD (entre os quais

eu), onde se procurava inquirir oportunidades de cooperação entre as entidades, tornou-se

percetível a existência destes diversos constrangimentos e a sua importância. Surgiu desta

situação a proposta de desenvolver um sistema de simulação 3D, que fosse capaz de simular

as tarefas de manutenção mecânica dos motores das aeronaves F-16, permitindo aos

formandos treinar as etapas e os procedimentos dessas tarefas e também exercitar os aspetos

de coordenação e colaboração em trabalho de equipa. O objetivo de realizar isto num

ambiente simulado seria poderem praticar várias vezes, a qualquer hora do dia, não

necessitando de materiais, motores nem aeronaves reais para o fazer, bastando apenas um

computador ligado à rede da BA5 e o respetivo software, criando assim uma ponte entre a

parte teórica da formação e a parte prática no terreno. Permitir-se-ia, desta forma, que os

formandos fossem para o terreno já mais preparados. Por exemplo, já com uma noção mais

precisa da aparência de cada peça, do seu tamanho relativo, etc.

Para dar suporte a esta colaboração, a UTAD e a FAP tinham estabelecido previamente

um protocolo de cooperação com vista a suportar esforços conjuntos de investigação

tecnológica e desenvolvimento, ao abrigo do qual se desenvolvera essa reunião e decorreram

as tarefas subsequentes de desenvolvimento, descritas nas secções seguintes desta

dissertação. Não existe, nem existiu financiamento específico associado a este protocolo. As

atividades desenrolaram-se no contexto de unidades curriculares de projeto ou de dissertação,

fundamentalmente semestrais.

2.1.1 PLATAFORMA TECNOLÓGICA

Na sequência do relatado na secção anterior, analisaram-se as plataformas existentes,

propícias para o desenvolvimento de sistemas multiutilizador 3D, onde se destacam os

mundos virtuais e os game engines. Os mundos virtuais, mais conhecidos como produtos

comerciais de entretenimento utilizados por milhões de utilizadores (World of Warcraft,

Second Life, entre outros), permitem que o desenvolvimento desde tipo de sistemas seja

efetuado excluindo a complexidade da gestão de comunicações, sincronização de estado em

rede entre utilizadores e outros aspetos similares. Os games engines também permitem este

desenvolvimento, inclusive com maior liberdade, mas obrigam o programador a gerir os

aspetos de baixo nível suprarreferidos, tornando assim mais complexo o desenvolvimento de

protótipos. Estas plataformas permitem interligar utilizadores, mesmo que separados

11

fisicamente, possibilitando a comunicação entre eles, bem como a execução de ações de

forma colaborativa.

Tendo em consideração que a curva de aprendizagem do desenvolvimento em mundos

virtuais é possivelmente mais rápida, devido à complexidade dos aspetos de baixo nível, e ao

facto das atividades se desenrolarem em unidades curriculares fundamentalmente semestrais,

o que originou a alteração regular dos elementos da equipa de desenvolvimento, optou-se à

época pelos mundos virtuais como plataforma de desenvolvimento.

Dentro dos mundos virtuais, devido a algumas condições impostas pela FAP,

nomeadamente ao nível de segurança (por exemplo, o simulador ficar dentro da sua própria

rede), e à não existência de financiamento, o mundo virtual escolhido para o desenvolvimento

foi um autónomo, criado com a plataforma OpenSimulator (OpenSimulator, 2012a).

O Opensimulator surgiu como plataforma alternativa a um dos mundos virtuais mais

conhecidos, o Second Life (SL). Começou por ser desenvolvido por retroengenharia do SL e

mais rapidamente após a Linden Lab ter tornado público o protocolo SLGOGP de comunicação

entre servidores da SL Grid e o software cliente do SL, destacando-se do SL também por ser

uma plataforma de código-fonte aberto. Tal como o SL, o OpenSimulator possibilita a criação

de conteúdo em tempo real pelos utilizadores e de forma imersiva, através de ferramentas

próprias para utilizadores finais, possibilitando também a partilha de texto, imagens, vídeo,

entre outros recursos (OpenSimulator, 2012b). Talvez por ser mais recente, o OpenSimulator

ainda não é uma plataforma de mundos virtuais tão robusto como o SL, mas sendo de código-

fonte aberto permite que sejam acrescentadas, corrigidas ou personalizadas as suas

funcionalidades.

2.1.2 RECOLHA DE DADOS E ESPECIFICAÇÃO

Foram realizadas várias reuniões entre a UTAD e a FAP, especificamente com a BA5,

com o intuito de se identificar, concretamente, como seria a colaboração entre estas duas

entidades. No decorrer destas reuniões surgiram quatro alternativas possíveis, tendo sido a

simulação da instalação do motor na fuselagem da aeronave F-16 a alternativa escolhida de

forma ad hoc pela equipa de desenvolvimento, em face de liberdade de escolha dada pelos

responsáveis da BA5.

O que se pretendia com esta simulação era que os formandos ficassem familiarizados

com o processo de simulação em si e com o ambiente que iriam encontrar, ou seja, que os

formandos quando chegassem ao local físico conseguissem, rapidamente, identificar onde e

como devem atuar, de modo a que a sua evolução e coordenação em equipa seja muito mais

12

fluída. Para isto, todo o processo deve ser o mais próximo possível da realidade, num ambiente

totalmente imersivo, que permita ao formando ter uma noção clara do espaço e de todo o

meio envolvente.

Sendo tudo isto uma nova realidade para a equipa de desenvolvimento que integrei

desde o início do processo, o volume de dados e informações necessárias para se proceder à

definição de requisitos foi enorme, a recolha feita através de: fotografias e filmagens ao vivo

de todo o processo, em vários ângulos e reuniões na BA5, complementadas através de

esclarecimentos regulares, em conversas informais com os intervenientes, ao longo de todo o

processo.

Posteriormente, foi feita uma análise exaustiva a estes dados, com base na qual foi

produzido um manual de instalação, clarificando as tarefas dos vários mecânicos e

complementando as instruções das TO (Figura 3). Esta análise permitiu também concluir que a

manutenção destes motores é efetuada sempre nos mesmos espaços e que a instalação dos

mesmos é realizada por três mecânicos, com a obrigatoriedade de haver um responsável por

supervisionar e verificar todo o processo (podendo um mecânico acumular estas funções, ou

estas funções passarem para um quarto elemento).

FIGURA 3 - EXEMPLO DE UMA IMAGEM ASSOCIADA À PARTE DE UMA TAREFA DESCRITA NAS TO

13

Esta recolha e análise de informação foram realizadas por outras colegas de

licenciatura e de mestrado, com a colaboração da equipa de desenvolvimento, em trabalhos

do projeto final de licenciatura e projetos do primeiro ano de mestrado, que serviram de

suporte ao trabalho no qual se baseia esta dissertação (Pinto & Teixeira, 2010a, 2010b). Desta

análise retiraram-se alguns aspetos importantes, onde se destacam:

o Cada mecânico tem as suas ferramentas;

o Existem procedimentos em que a cooperação, a colaboração e o trabalho em

equipa são obrigatórios;

o Os mecânicos comunicam entre si durante todo o processo, usando a linguagem

verbal como principal meio de comunicação;

o O processo de instalação exige toda uma sequência de passos, não sendo possível

realizar uma determinada tarefa sem que a anterior tenha sido concluída;

o Após uma primeira fase, em que existe apenas uma sequência de tarefas e em que

é necessária a presença e a colaboração de todos os membros da equipa, a

sequência original divide-se em três sequências de tarefas paralelas e

independentes entre si;

o Os mecânicos não têm qualquer limitação de movimentos podendo caminhar

livremente por todo o hangar;

o Cada mecânico tem um determinado conjunto de tarefas que só cabe a si executar,

não podendo efetuar qualquer outra tarefa que pertença a outro elemento da

equipa, a não ser que tal lhe seja solicitado por esse elemento.

o As TO podem sofrer alterações de acordo com ordens do fabricante e as suas

indicações nem sempre são seguidas na íntegra.

Tendo em consideração estes aspetos, obtiveram-se os seguintes conjuntos de

requisitos principais, que circunscreveram o desenvolvimento da plataforma-base:

o Requisitos não funcionais:

Limitação a nível de rede para formação, a BA5 não possui boa ligação de rede

ao exterior;

Cada mecânico tem um conjunto de ações que apenas ele pode realizar;

Todo o processo tem etapas onde algumas não poderão ser executadas sem

que a etapa anterior esteja concluída.

14

o Requisitos funcionais:

Possibilidade de uma equipa, em simultâneo, treinar o processo de instalação

de um motor Pratt&Whitney F100 numa aeronave F-16;

A simulação terá de cumprir uma sequência lógica de passos para a instalação

do motor;

Possibilidade de colaboração e cooperação no trabalho em equipa e em

simultâneo;

O utilizador terá de estar equipado com algumas ferramentas específicas para

a realização de certas tarefas.

No guião de instalação então produzido (Pinto & Teixeira, 2010a), são descritas trinta e

três tarefas necessárias para completar todo o processo de instalação do motor na fuselagem

de uma aeronave F-16. Cada uma destas tarefas foi analisada e especificada pela equipa de

projeto de então. Foram criados diagramas de casos de uso, de estados, de atividades e de

classes, para cada uma das tarefas.

A título exemplificativo, na Figura 4, Figura 6, Figura 6 e Figura 7 são apresentados os

respetivos diagramas de uma tarefa específica, neste caso específica, a elevação do motor.

FIGURA 4 - DIAGRAMA DE CASOS DE USO PARA A TAREFA "ELEVAR MOTOR"

15

FIGURA 6 - DIAGRAMA DE ESTADOS PARA A TAREFA "ELEVAR MOTOR"

FIGURA 6 - DIAGRAMA DE ATIVIDADES PARA A TAREFA "ELEVAR MOTOR"

16

2.1.3 PROTÓTIPO

Como mencionado anteriormente, pretendia-se que os formandos se sentissem

familiarizados com a simulação existente e com o ambiente que vão encontrar. Para cumprir

este requisito foi modelado todo o ambiente 3D, tornando-o parecido com o que se encontra

na BA5. Foi modelado pelo projeto original um hangar (Figura 8) idêntico ao que se pode

encontrar na BA5, além dos objetos essenciais a toda a simulação foram também modelados

alguns objetos que podem ser encontrados no local, como por exemplo extintores, sistemas de

incêndio, escadas de acesso à aeronave (Figura 9), etc.

FIGURA 7 - DIAGRAMA DE CLASSES PARA A TAREFA "ELEVAR MOTOR"

FIGURA 8 - HANGAR (AMBIENTE 3D)

17

Após estar modelado todo o ambiente 3D, foi implementado um protótipo

experimental. Este protótipo simulava todas as tarefas até à inserção do motor na fuselagem

da aeronave F-16. Após ser realizado um primeiro teste com os utilizadores finais, este

protótipo demonstrava algumas limitações, assim como alguns erros de implementação. As

ferramentas usadas pelos avatares, após anexadas, não podiam ser desanexadas, os

mecânicos teriam de seguir todos a mesma sequência (no processo real não) e a sequência de

tarefas no processo de instalação do motor estava incorreto. Face a esta situação, foram

identificados pormenorizadamente os problemas e elaborados novos requisitos com base

nesta, sendo depois desenvolvido um segundo protótipo sustentado nestes novos requisitos.

Este segundo protótipo (Figura 10 e Figura 11) simula além das tarefas anteriores, as tarefas de

segurança do motor na fuselagem e remoção do carrinho e material de apoio à inserção do

motor.

FIGURA 9 - ESCADAS DE ACESSO À AERONAVE (AMBIENTE 3D)

FIGURA 10 - HUD QUE REPRESENTA EQUIPAMENTO NA MÃOS DIREITA E ESQUERDA

18

~

Este segundo protótipo também foi alvo de teste com os utilizadores finais, onde ainda

se detetaram alguns erros no processo simulado, no entanto, no que diz respeito à utilidade

do simulador, todos os entrevistados referiam ser bastante útil, servindo de apoio à parte

prática da formação (Fernandes, 2012).

2.2 ENVOLVENTE CONCEPTUAL

Num contexto tecnológico onde as necessidades do utilizador final estão em constante

transformação e em que são necessárias soluções robustas que suportem a interação de forma

eficaz entre humanos e máquinas, a Interação Humano-Computador (Human-Computer

Interaction – HCI, na terminologia anglo-saxónica) pode ser entendida como uma disciplina

que considera os aspetos relacionados com o design, avaliação e implementação de sistemas

computacionais interativos para uso humano, bem como o estudo dos fenómenos

circundantes (Hewet et al., 1992).

Segundo Schmidt e Simone (1996), “o trabalho cooperativo é constituído pela

interdependência de múltiplos atores a interagir através da alteração do estado de um campo

comum de trabalho”, onde o seu carácter distribuído depende de fatores como a distribuição

de atividades no tempo e espaço, o número de participantes em contextos de cooperação, a

complexidade estrutural constituída pela área de trabalho (interações e heterogeneidade), o

nível de especialização ou experiência dos participantes, e a variedade de heurísticas

envolvidas, exigindo um trabalho de articulação efetivo para unir os esforços cooperativos nas

atividades realizadas de forma distribuída através de artefactos específicos.

FIGURA 11 - HUD EM FORMA DE SETAS PARA DESCER OU SUBIR APOIOS

19

Na perspetiva dos sistemas colaborativos que fornecem o respetivo suporte às

dinâmicas de trabalho cooperativo, o termo groupware pode subentender-se como “o

conjunto de sistemas computacionais que suportam indivíduos envolvidos numa tarefa (ou

objetivo) comum e fornecem uma interface para um ambiente partilhado” (Ellis et al., 1991).

Alguns exemplos mais concretos neste segmento são os sistemas Microsoft SharePoint e o

BCSCW.

Os Ambientes Virtuais Colaborativos (Collaborative Virtual Environments – CVE) podem

ser descritos como “mundos virtuais compartilhados pelos participantes através de uma rede

de computadores” e espaços tridimensionais habitados que suportam múltiplos contextos de

interação, incluindo aprendizagem colaborativa, trabalho cooperativo, e jogos de natureza

social (Benford et al., 2001).

Segundo Morgado (2009), os mundos virtuais são um tipo específico de ambientes

virtuais. Para definir um ambiente virtual como um mundo virtual existem dois aspetos

essenciais que têm de estar presentes: multiutilização e imersividade. Ou seja, um ambiente

que possibilite a conexão de vários utilizadores e que no qual estes estejam representados no

interior desse ambiente. Morgado (2012) afirma ainda que se pode pensar nos mundos

virtuais como sendo de três tipos distintos, do ponto de vista da utilização em contexto

educativo ou de formação:

o Simulação da realidade, sob a perspetiva de os ver como forma de enriquecer o

contexto em que decorre o ensino, aproximando-o dos contextos em que se pretende

exercer posteriormente o conteúdo e competências desse ensino;

o Sociais - espaços de socialização e de criação de comunidades virtuais;

o Jogos com objetivos, como os Massive Multiplayer Online Role-Playing Games

(MMORPG).

Segundo Amaral (2008), os mundos virtuais caracterizam-se por serem ambientes

gerados por computação gráfica – 2D ou 3D, que são partilhados por pessoas fisicamente e

geograficamente distantes e que se conectam via rede. Este autor já tem uma classificação

diferente, além dos tipos suprarreferidos, classifica-os em mais dois tipos:

o Expressão Política – servem como fóruns de expressão política e de debate;

o Treino Militar – espaços criados para ações de simulação de treino militar.

O conceito de fluxo de trabalho, também conhecido como workflow, é definido por

Xiao (2005) como o conjunto de processos criados para coordenar as atividades de múltiplas

pessoas e, desta forma, assegurar a conclusão do trabalho com êxito e aumentar a eficiência

dos colaboradores. Os procedimentos funcionais padronizados podem influenciar o carácter

20

das atividades coordenadas, fomentando assim a integração de tecnologia colaborativa dentro

do fluxo de trabalho de uma organização.

As máquinas de estados são definidas por serviços, servidores, e linguagens de

programação estruturadas para suportar a modularidade. Uma máquina de estados consiste

em variáveis de estado que codificam o seu estado, e por comandos que transformam o seu

estado. Cada comando é implementado por um programa determinístico, e a execução do

comando é atómica em relação aos outros comandos, modificando o estado das variáveis ou

produzindo certos tipos de resultados. Um cliente de uma máquina de estados faz um pedido

para executar um comando. O pedido nomeia uma máquina de estados, o comando a ser

executado, e contém qualquer informação exigida pelo comando. O resultado do

processamento de pedidos pode ser direcionado ao atuador (e.g., num sistema de controlo de

processos), a outro dispositivo periférico (e.g., um disco ou terminal), ou a clientes que

aguardam resposta a partir de pedidos prévios (Schneider, 1990).

2.3 TRABALHO RELACIONADO

2.3.1 MÉTODO

O método de pesquisa utilizado foi adaptado de Kitchenham et al. (2009) e Stapić et al.

(2012), o qual se estabelece numa revisão sistemática da literatura especificando um conjunto

de questões de investigação para as quais é necessário fazer uma escolha de estudos com base

em critérios de seleção, por forma a extrair evidências significativas. Contudo, esta abordagem

metodológica foi apenas seguida até se encontrar a informação pretendida, o que acabou por

ocorrer com alguma rapidez, servindo apenas como diretriz no processo de pesquisa e análise

bibliográfica. Após um processo de reflexão estimulado pela leitura de publicações científicas,

representativas de trabalhos similares feitos na área, formularam-se as seguintes questões de

investigação:

Q – Na última década, o que foi feito ao nível da agilização entre as fases de conceção

e implementação de ambientes de simulação, sem intervenção de programadores?

Q1 – Quais os mundos virtuais usados para criar ambientes de simulação?

Q2 – Quais as limitações existentes?

Q3 – O que já foi feito ao nível do 3D com recurso a máquinas de estados hierárquicas?

21

Relativamente ao processo de pesquisa, o conjunto de palavras-chaves definido foi:

“hierarchical state machines” AND “virtual worlds simulations”, “hierarchical state machines”,

“virtual worlds simulations”. Neste contexto, foi usado o Google Scholar (mais concretamente

através do programa Publish or Perish) com ligação às bases de dados IEEE Xplore, Springerlink

libraries, e ACM Digital Library. Foram ainda analisadas as referências de cada artigo (através

do método “Bola de Neve”) para verificar diferentes fontes e cruzar informação relevante.

A amostra reporta-se essencialmente à última década (2003-2012) de investigação em

mundos virtuais e ambientes virtuais imersivos, partindo do ano de introdução do Second Life.

Outros fatores que definem esta amostra, caracterizam-se pela natureza atual da informação e

apresentação dos desafios que permanecem sem resolução no contexto científico. Os fatores

de exclusão reportam-se a artigos que se focam em Realidade Virtual ou Realidade

Aumentada, ao invés de ambientes virtuais imersivos. Também foram excluídos vários artigos

que se focam apenas em aspetos de usabilidade, acessibilidade, etc.

O processo de extração de evidências foi suportado pela investigação desenvolvida em

ambientes virtuais colaborativos tridimensionais (Correia et al., 2012), bem como, pela análise

e filtragem de publicações segundo os critérios previamente estabelecidos, tendo em conta os

objetivos específicos deste trabalho. Complementarmente, são ainda discutidos trabalhos de

natureza similar, identificados a partir da análise ao estado do conhecimento neste domínio.

2.3.2 TRABALHO RELACIONADO

De acordo com Grudin e Poltrock (2012), os ambientes virtuais colaborativos imersivos

têm vindo a sofrer alterações constantes em termos de interesse e representação, no suporte

a atividades de natureza colaborativa baseadas em simulação. No contexto atual, verifica-se

uma necessidade de criar soluções pouco dispendiosas e personalizadas a situações com

diferentes níveis de complexidade e riscos associados, onde estes ambientes constituem uma

alternativa consistente, aplicando a Realidade Virtual em cenários multidisciplinares como

aprendizagem à distância, treino, tratamentos terapêuticos, e interação social em torno de

necessidades reais. Numa meta-análise apresentada por Correia et al. (2012) foram

identificadas várias lacunas, e oportunidades de investigação, em mundos virtuais com

particular enfoque sobre as dinâmicas de aprendizagem colaborativa, na medida em que é

esperado um impacto amplo e crescente destas plataformas no ensino superior (Hew &

Cheung, 2010), bem como aplicações possíveis nas áreas de saúde, treino militar, economia,

planeamento urbano, arquitetura e engenharia (Jarmon et al., 2009). A experiência

possibilitada por estes ambientes virtuais colaborativos de caráter imersivo pode ultrapassar

22

as barreiras temporais, espaciais, culturais e sociais através de diferentes formas de interação

(Anstadt et al., 2011). Neste sentido, as suas funcionalidades e canais de comunicação (por

exemplo, texto, áudio, ícones gráficos, gestos, e entradas multissensoriais) e cooperação

(através da capacidade de integrar aplicações partilhadas e manipular objetos digitais)

permitem coordenar ações, produzir artefactos, e suportar a interação social.

Apoiados na “metáfora do mundo real mas sem as suas limitações físicas” ((Davis et

al., 2009), os metaversos ou mundos virtuais tridimensionais imersivos têm sido investigados

em atividades de aprendizagem experimental (Jarmon et al., 2009), bem como operações,

táticas e estratégias militares que requerem tecnologias sofisticadas com o intuito de preparar

tropas para cenários de combate real (Pierzchała et al., 2011). As vantagens associadas à

simulação de tarefas neste tipo de ambientes virtuais estabelecem-se maioritariamente pela

redução de custos e pelo aumento da eficiência, segurança, socialização e escalabilidade

(Grimstead et al., 2005), quando comparados com os sistemas colaborativos multiutilizador

convencionais. Os investigadores têm identificado algumas potencialidades relacionadas a um

aumento da noção de presença partilhada e perceção periférica (Bentley et al., 1992), bem

como a baixos níveis de ansiedade e limitações sociais parcialmente eliminadas (Correia et al.,

2012). Neste sentido, sistemas como o Collaborative Learning Environment with Virtual Reality

(Jarmon et al., 2009) ou Educators Coop (Jarmon & Sanchez, 2009) constituem-se como meios

de interação para a aprendizagem à distância que vêm corroborar estas vantagens.

Complementarmente, a adição de ferramentas hápticas em ambientes virtuais colaborativos

tridimensionais pode aumentar a noção de copresença (Bailenson & Yee, 2008), introduzindo

um modo diferente de imersão.

Numa comparação entre ambientes virtuais colaborativos orientados à aprendizagem

(Rajaei & Aldhalaan, 2011), foi possível analisar os sistemas Active Worlds, CVGE, WebOnCOLL,

TOUCH, America’s Army, Full Spectrum Warrior e ASCIT Sick Children a nível de arquitetura da

tecnologia (grelha, ponto-a-ponto, cliente-servidor, e multi-servidor), modo de representação

(avatar ou vídeo), caraterísticas ao nível da expressão facial, perceção social, disponibilidade,

acessibilidade e compatibilidade, bem como formas de comunicação síncrona (chat, vídeo, e

áudio). A interação síncrona entre participantes em configurações de treino tem vindo a ser

permitida em ambientes laboratoriais virtuais com flexibilidade, para simular experiências

onde instrutores, alunos e assistentes interagem no processo de aprendizagem. Laboratórios

virtuais criados para simular atividades de ensino e descoberta em áreas como química, física,

biologia, mecânica e astronomia têm sido explorados a nível académico, onde um exemplo

conhecido é o Virtual ChemLab da Brigham Young University (Aziz et al., 2013). As suas

particularidades são conhecidas ao nível da capacidade de interação com objetos digitais (e.g.,

23

tubos de ensaio com soluções moleculares) num “ambiente laboratorial simulado” que

possibilita aos participantes misturar produtos químicos em provetas virtuais e observar as

reações químicas resultantes.

A nível dos sistemas de treino baseado em simulação, estão em desenvolvimento

simuladores que podem permitir aos cirurgiões manipular órgãos humanos virtuais em tempo

real, para adquirir competências sem colocar em risco a vida humana, necessitando para o

efeito de uma base de dados de grande dimensão composta por modelos virtuais de anatomia.

Para além disso, está ainda a ser equacionado o uso de interfaces hápticas, como o dispositivo

Phantom da empresa SensAble Technologies ou as soluções CyberGlove para a captura de

movimentos 3D (Aziz et al., 2013). No contexto militar, Fong (2004) introduziu um simulador

que faz uso de jogos Commercial Off The Shelf (COTS) aplicados em atividades educacionais. O

motor de jogo Unreal tem vindo a ser usado em diversas situações, incluindo a criação de uma

experiência colaborativa e pedagógica para a pesquisa sobre a colaboração de utilizadores em

ambientes virtuais 3D (Hämäläinen et al., 2006), e a análise do seu potencial para o uso de

simulações táticas multiagente (Manojlovich et al., 2003) como software de treino. No projeto

open-source CaveUT (Jacobson & Lewis, 2005), este motor de jogo foi usado para permitir uma

alternativa de Realidade Virtual com alto desempenho e baixo custo baseada em projeção

através de displays em compartimentos com múltiplos ecrãs. Este também serviu de base à

pesquisa para conseguir melhorias no controlador de interface humana e robótica, em

contexto de interação urbana e com robôs de resgate (Wang et al., 2003).

O projeto Cell Biology, desenvolvido na Universidade do Arizona, permitiu aos alunos

recolherem dados de células e usá-los para calcular a duração de cada fase na divisão das

células. Várias plataformas de jogos (e.g., Bell & Fogler, 2003) foram utilizadas para

desenvolver simulações virtuais em situações de emergência como acidentes em laboratórios

e treino orientado ao uso eficiente de camiões, equipamentos e pessoal no combate aos

incêndios (DHS Student, 2007). O HumanSim foi criado pela Virtual Heroes, Inc. e utilizado para

desenvolver uma simulação 3D de instrução para procedimentos de cirurgia cardíaca

utilizando a tecnologia Unreal Engine 3, integrando-a com um modelo fisiológico e

farmacológico de alta-fidelidade para aprendizagem experimental. Os cenários de simulação

foram programados para os processos “aprendendo-fazendo”, fornecendo treino e

proficiência em tarefas raras, complicadas, ou não suscetíveis a erros. Estes procedimentos

mostraram novos tratamentos para a fibrilação no coração, com animações referentes aos

seus processos (Aziz et al., 2013).

25

CAPÍTULO 3: ARQUITETURA-BASE – APRESENTAÇÃO E ANÁLISE

“Computers themselves, and software yet to be developed, will revolutionize

the way we learn.”

Steve Jobs

Neste capítulo apresenta-se a arquitetura do protótipo apresentado anteriormente,

que serviu de base a este projeto. São apresentados e analisados os aspetos importantes que

foram desenvolvidos ao longo de três anos, tendo como principal preocupação a separação

entre a componente lógica e a componente visual do sistema, tornando assim possível, por

exemplo, o acompanhamento da evolução da tecnologia que utilizamos na componente visual,

de modo a ter cada vez mais gráficos poderosos e realistas, de forma fácil, rápida e simples.

26

3.1 APRESENTAÇÃO DA ARQUITETURA

Tendo em consideração os requisitos especificados na subsecção 2.1 e analisados os

aspetos importantes mencionados nesta mesma secção, constatou-se que as TO nem sempre

são seguidas de forma exata, pois o processo de instalação do motor na aeronave decorre sob

uma abordagem de melhoria contínua, a um ritmo necessariamente mais dinâmico e local do

que a evolução das TO, logo as tarefas do processo de instalação do motor na fuselagem de

uma aeronave F-16 podem frequentemente sofrer alterações face ao registado nas TO.

O protótipo apresentado na subsecção 2.1 foi desenvolvido de modo a cumprir os

requisitos apresentados nesta mesma subsecção, mas que no entanto, quando fosse

necessário proceder à alteração de tarefas ou mesmo alterar o seu ambiente 3D, não fosse

praticamente como refazê-lo de raiz, exigindo assim um esforço enorme de tempo e de

programação. Ou seja, foi desenvolvido de forma a cumprir os requisitos pretendidos. Ao

mesmo tempo, esta oportunidade foi aproveitada para conceber um modelo tecnológico

sólido e robusto, que possibilitasse alterar o funcionamento do simulador, alterar o ambiente

3D e adequar o sistema a novos requisitos de forma mais rápida e simples, assim sendo, este

modelo conseguir-se-ia adaptar a vários e diversos cenários de simulação.

Tendo em consideração este objetivo, bem como a superação da adversidade

mencionada no primeiro parágrafo desta subsecção, optou-se por conceber um modelo

tecnológico onde se separasse o sistema de controlo e decisão do sistema de visualização

(neste caso a componente 3D). Neste sentido, o modelo tecnológico concebido é constituído

pelos seguintes elementos: um sistema de controlo e decisão (implementado através de uma

máquina de estados hierárquica), um protocolo de comunicação e um módulo view genérico

(script em LSL).

3.2 SISTEMA DE DECISÃO E CONTROLO

A implementação da máquina de estados hierárquica para o simulador de instalação

de motores Pratt&Whitney F100 em aeronaves F-16, tem portanto como objetivos principais

(1) garantir a independência dos mecanismos de coordenação e interação que estão

disponíveis no espaço virtual 3D, assegurando a separação entre a interface gráfica e o sistema

de decisão; (2) permitir que sejam adicionadas mudanças no processo de instalação do motor

na aeronave, mudanças que possam ser introduzidas tanto pelo fabricante como pelos

formadores (por exemplo: a introdução de um erro propositado); (3) ser multiplataforma, para

27

que não seja aplicável apenas em Opensimulator, mas em vários outros mundos virtuais ou

outras plataformas 3D.

O sistema de controlo e decisão, além da máquina de estados é constituído por uma

base de dados, onde é armazenada informação relativa aos objetos que intervêm na

simulação, bem como, o estado atual de cada avatar e o estado atual do sistema em si. Para a

comunicação e interação entre o sistema de visualização e o sistema de decisão e controlo foi

definido um sistema de interação genérico como se pode observar na Figura 12.

Como está representado na Figura 12, neste sistema de interação está definido que:

quando um avatar interage com um objeto (tocando nele), este comunica a ação ao sistema de

decisão e controlo, que por sua vez, baseado na ação recebida e após ter efetuado uma

consulta à base de dados (com o objetivo de ficar a conhecer qual o estado atual do sistema e

do avatar que interagiu), transita ou não de estado e responde ao objeto enviando o(s)

comando(s) a ser(em) executado(s).

FIGURA 12 – SISTEMA DE INTERAÇÃO GENÉRICO (FONSECA ET AL., 2011)

FIGURA 13 - SISTEMA DE DECISÃO E CONTROLO

28

Para que este sistema de interação funcione é necessário que o sistema de decisão e

controlo (Figura 13) consiga gerir corretamente todas as transições com base nas ações

despoletadas no mundo virtual. O sistema de decisão e controlo foi implementado na

plataforma ASP.NET e baseia-se, como já referido, no conceito de máquinas de estados

hierárquicas. O funcionamento deste é bastante simples, é definido um único ponto de

entrada (um método genérico), que recebe todas as ações reportadas do sistema de

visualização (neste caso, o OpenSimulator), além disso, como o sistema mantém o controlo

sobre o seu estado atual e o estado atual de cada objeto (através da base de dados, Figura 14),

e cada estado tem todo o conhecimento acerca si, sabendo para que estados seguintes pode

transitar e (quando este é assumido como estado atual) que tipo de resposta(s) deve dar ao

sistema de visualização, este é capaz de inferir, a qualquer momento, quais são as ações

possíveis e se pode ou não transitar de estado.

Na Figura 14, é apresentado o diagrama entidade-relacionamento da base de dados

que constitui o sistema de decisão e controlo, como se pode verificar pela Figura 14, faz parte

desta: a tabela “TabelaEstados”, onde são guardados todos os estados necessários para todo o

processo, tanto os estados do sistema como os estados dos avatares; a tabela “Avatar”, onde

são guardados os dados de cada avatar; a tabela “AvatarContemEstados” que relaciona os

estados do avatar com a tabela de estados geral; a tabela “PostoTrabalho” que foi criada de

modo a solucionar a limitação de os três mecânicos poderem seguir caminhos diferentes,

permitindo desta forma criar nesta tabela vários postos de trabalho, ou seja, vários caminhos

por onde a simulação pode seguir de forma independente. Para relacionar estes postos de

FIGURA 14 - DIAGRAMA E-R DA BASE DE DADOS (FERNANDES, 2012)

29

FIGURA 15 - DIAGRAMA DE CLASSES

trabalho com os estados presentes, existe ainda uma tabela de relacionamento

“PTContemEstado”.

Analisando mais exaustivamente o sistema de decisão e controlo verifica-se que cada

um dos estados (etapas a simular) que o protótipo (apresentado na subsecção 2.1) possui,

corresponde à implementação de uma classe derivada da classe “Estado” (Figura 15),

contando o sistema, atualmente, com aproximadamente 40 classes. Cada uma destas classes

tem um método chamado “gerarTarefa()”, que é executado assim que o sistema transita para

o estado correspondente a esta classe, método este onde é definida (programada em código)

a resposta a enviar para o OpenSimulator, sendo usadas estruturas condicionais para este

estado poder ter mais que uma resposta diferente, caso contrário apenas poderá ter uma

única resposta (Figura 16).

Constata-se ainda que a simulação pode ter apenas um caminho (sequência de tarefas)

possível ou ter vários independentes ao mesmo tempo (quatro, neste caso). Por exemplo: um

mecânico fazer as ligações do lado direito e outro do lado esquerdo em simultâneo. Em

consequência, no sistema estão definidas e são inicializadas cinco variáveis do tipo “Estado”

(classe genérica): uma para os avatares e as outras para os diferentes caminhos da simulação.

Tendo como base a ação reportada pelo OpenSimulator, assim como no objeto que reportou

30

esta ação é executada uma decisão numa estrutura switch em C#. Mediante ela, é usada a

variável do tipo “Estado” correspondente (uma das mencionadas anteriormente), para invocar

o método que tratará da ação (“Despachar” ou “DespacharSistema”). Para que este método

trate/processe a ação reportada são percorridos os “Despachantes” pertencentes ao estado

que chama este método (lista de delegates que recebe como parâmetro a ação reportada).

Para terminar, verifica-se que: tanto as ações como as tarefas possíveis são definidas

através de uma enumeração; para o sistema funcionar corretamente, algumas informações

têm de ser previamente inseridas na base de dados; para tal, são usadas estruturas

condicionais para verificar vários aspetos, como sejam: o número de vezes que aquela mesma

tarefa teria de ser executada, para o sistema poder transitar de estado; o número de

mecânicos necessários; o tempo de realização da tarefa; entre outros.

3.3 SCRIPT LSL COMO MÓDULO VIEW GENÉRICO

Conforme já foi mencionado, um dos objetivos principais era conseguir criar um

sistema em que o ambiente 3D (sistema de visualização) estivesse completamente separado

do sistema de decisão e controlo, para assim ser possível alterar o ambiente 3D sem haver

necessidade de efetuar alterações no código do sistema de decisão e controlo. Para isto, o

sistema tridimensional não podia tomar nenhuma decisão, todos os objetos presentes no

ambiente 3D apenas comunicam que ação ocorreu e quem disparou essa mesma ação ao

FIGURA 16 - EXEMPLO DO FUNCIONAMENTO DE UM ESTADO COM MAIS QUE UMA RESPOSTA DIFERENTE

31

sistema de decisão e controlo, e aguarda por uma ou mais tarefas para executar. Neste

sentido, todos os objetos que têm interação no processo de instalação do motor, possuem um

script (desenvolvido na linguagem LSL) que permite comunicar à máquina de estados a ação

que ocorreu e interpretar qualquer tipo de resposta(s) dada(s) pelo sistema de decisão e

controlo.

A grande dificuldade e ao mesmo tempo o grande desafio, foi conseguir idealizar e

conceber um script único para todos os objetos, capaz de reportar todos os diferentes tipos de

ações e reagir de forma completamente diferente, dependendo do objeto onde se encontra e

da(s) tarefa(s) enviada(s) pelo sistema de decisão e controlo. Este script, além de conseguir

executar qualquer tarefa recebida para o objeto onde se encontra, necessitava ainda de ter a

capacidade de comunicar com outros objetos, a fim de estes também realizarem tarefas, caso

fosse essa a ordem recebida do sistema de decisão e controlo.

Com este script único para todos os objetos, deixando de ser necessário programar um

script diferente consoante o tipo de objeto e o tipo de resposta que este vai receber, estava

alcançada a desejada separação entre o sistema de visualização e o sistema de decisão e

controlo.

3.4 PROTOCOLOS DE COMUNICAÇÃO

Depois de concluída a separação entre o sistema de visualização e o sistema de

decisão e controlo, foi necessário idealizar e definir mecanismos de comunicação entre os

mesmos. Desta forma, devido ao elevado número de comunicações que vão ser realizadas

entre os sistemas e a necessidade das comunicações ficarem genéricas, para que no futuro,

caso seja necessário efetuar alguma alteração, ou acrescentar alguma funcionalidade, seja

bastante mais fácil e rápido, foi imprescindível a criação de um protocolo de comunicação

genérico/standard específico para o nosso sistema.

Após esta necessidade tentaram-se perspetivar as situações de comunicação

diferentes que podiam surgir. No entanto, chegou-se à conclusão que só após a

implementação de uma sequência de alguns passos concretos, é que se conseguiria ter uma

noção mais concreta e correta destas diferentes situações. Concluiu-se que, para se integrar os

dois sistemas, eram necessários três tipos de protocolos de comunicação:

Sistema de Decisão e Controlo – Ambiente 3D; (Tabela 1)

32

Ambiente 3D – Sistema de Decisão e Controlo (Tabela 2 e Tabela 3), onde se terá

dois subtipos diferentes de protocolo (um que serve para registar os dados de um

objeto quando é criado no ambiente 3D e outro para as restantes ações)

Ambiente 3D – Ambiente 3D (pois existem situações em que um objeto terá de

“falar” com outro e comunicar-lhe tarefas a realizar) (Tabela 4).

Parâmetro Tipo Função

Parâmetro 1 Número inteiro

Corresponde ao número de tarefas que o Sistema de Decisão e Controlo envia como resposta

Parâmetro 2 Número inteiro Corresponde a uma tarefa a realizar, ex: 1-Falar, 2- Mover

Parâmetro 3 Número inteiro Corresponde ao número de parâmetros que a tarefa vai ter

Parâmetro 4, 5,…, n String Corresponde aos parâmetros específicos de uma determinada tarefa

TABELA 1 - PROTOCOLO DE COMUNICAÇÃO: SISTEMA DE DECISÃO CONTROLO – AMBIENTE 3D


Parâmetro 1 String Corresponde ao nome da ação que aconteceu, neste caso “Objcriado”

Parâmetro 2 String Corresponde ao nome do objeto

Parâmetro 3 String Contém a key deste objeto

Parâmetro 4 String Contém a posição deste objeto, ou seja, as suas coordenadas

Parâmetro 5 String Contém a rotação do objeto

TABELA 2 - PROTOCOLO DE COMUNICAÇÃO: AMBIENTE 3D – SISTEMA DE DECISÃO E CONTROLO (OBJETO CRIADO)

33


Parâmetro 1 Número Inteiro Corresponde número do canal pelo qual vamos comunicar

Parâmetro 2 String Contém a key do objeto que está a comunicar

Parâmetro 3 Número Inteiro Corresponde a uma “acção” a realizar, ex: 1-Falar, 2- Mover, 3-Escrever

Parâmetro 4 String

Contém a informação a enviar, ex: se a ação for “mudar” deverá conter as coordenadas que o objeto deverá assumir

TABELA 4 - PROTOCOLO DE COMUNICAÇÃO: AMBIENTE 3D – AMBIENTE 3D

Através da utilização destes protocolos de comunicação, conseguiu-se implementar

uma estrutura de comunicação genérica entre os dois sistemas, permitindo que esta

arquitetura seja menos falível e possua uma manutenção bastante mais facilitada e rápida.


Parâmetro 1 String Corresponde ao nome da ação que aconteceu, ex: tocado, attached

Parâmetro 2 String Contém a key do objeto

Parâmetro 3 String Contém a key do avatar ou objeto que interagiu com este

Parâmetro 4 String Contém a nova posição do objeto, ou seja, as suas coordenadas

Parâmetro 5 String Contém a nova rotação do objeto

TABELA 3 - PROTOCOLO DE COMUNICAÇÃO: AMBIENTE 3D – SISTEMA DE DECISÃO E CONTROLO

35

CAPÍTULO 4: NOVA ARQUITETURA: PROTÓTIPO

"Software is a great combination between artistry and engineering. When you finally

get done and get to appreciate what you have done it is like a part of yourself that you've put

together…”

Bill Gates

Neste capítulo, aborda-se a metodologia de desenvolvimento escolhida para conceber

um sistema que concretizasse todos os novos requisitos aqui referidos, permitindo testá-lo e

validá-lo com utilizadores. É também apresentada, neste capítulo, toda a evolução dos

diferentes componentes do sistema, nomeadamente, um sistema de decisão e controlo

totalmente novo e remodelado, as alterações necessárias ao script LSL único, bem como ao

protocolo de comunicação. É ainda apresentada a estrutura de dados dos ficheiros de

configuração do sistema e a interface gráfica atualmente usada para a criação dos mesmos.

36

4.1 METODOLOGIA ADOTADA

Durante o processo de desenvolvimento do trabalho da presente dissertação, adotou-

se a metodologia Design Science.

Como podemos observar na Figura 17, segundo Hevner (2007), na metodologia Design

Science o processo de desenvolvimento é composto por três fases interligadas entre si, através

de atividades. No ciclo da relevância é analisado o ambiente contextual do projeto de pesquisa

e feita uma ponte para as atividades de design (conceção). O ciclo do rigor liga as atividades de

conceção à experiencia e ao conhecimento baseado em fundamentos científicos. O ciclo de

conceção alterna entre atividades de construção e avaliação dos produtos concebidos.

Com base nesta metodologia, o ciclo de relevância, que incide sobre o ambiente, é

descrito ao longo da secção de contextualização (subsecção 2.1). Os resultados desse ciclo são

essencialmente os requisitos, que foram evoluindo e cuja especificação é apresentada ao

longo da subsecção 4.3. Para o ciclo do rigor, foram realizadas várias pesquisas de artigos

científicos, de forma a conhecer as diversas abordagens já realizadas nesta área e os pontos

fortes e fracos de cada uma delas, descritas ao longo da subsecção 2.3. Tudo isto permitiu criar

uma ponte para a conceção dos produtos e processos descritos ao longo deste capítulo. Estes

produtos foram “sofrendo” constantes avaliações, de modo a detetar e corrigir o maior

número de possíveis falhas. Com um protótipo já implementado, foram realizados alguns

testes com utilizadores, expostos na secção 5. Entrando-se novamente no ciclo da relevância,

onde foram detetados novos problemas e de onde surgiram novos requisitos.

FIGURA 17 - CICLOS DA METODOLOGIA DESIGN SCIENCE (HEVNER, 2007)

37

4.2 IDENTIFICAÇÃO DO PROBLEMA

No sistema utilizado para conceber o protótipo (apresentado ao longo da subsecção

2.1), cujo funcionamento é apresentado ao longo da secção 3, para introduzir uma nova

peça/componente na simulação é necessário efetuar a sua modelação e fazer o upload para o

OpenSimulator. Em seguida para que este componente fique integrado com a simulação é

imprescindível que se aplique um script, tendo esse que ser editado de forma a colocar

algumas informações relativas a esse mesmo componente (nomeadamente, posição inicial na

simulação, rotação, etc.), sendo esta edição do script um dos passos que era necessário

alterar, de modo a não ser preciso efetuar alterações no código.

Para atribuir comportamentos a este mesmo componente (conforme podemos

verificar na subsecção 3.2), é necessário: criar e implementar uma nova classe que derive da

classe “Estado” (Figura 15); nesta classe, no método “gerarTarefa()”, programar a resposta, ou

respostas (com recurso a estruturas de decisão como podemos ver na Figura 16), a enviar ao

OpenSimulator quando o sistema entra neste estado, e caso essas respostas contenham

tarefas que são necessárias realizar mais do que uma vez, ou com mais do que um

interveniente, é ainda necessário programar essas verificações; implementar os

“Despachantes” (lista de delegates que recebe como parâmetro a ação reportada) para as

ações a que este estado vai responder, e qual o estado resultante para cada uma delas. Por

fim, era necessário adicionar este estado à tabela, na base de dados, que contém todos os

estados necessários para a simulação. Era necessário alterar todos estes passos, de modo a

que se pudessem atribuir comportamentos, sem ser preciso efetuar alterações no código do

sistema de decisão e controlo, nem lidar diretamente com base de dados.

É ainda possível verificar na subsecção 3.2, mais propriamente na Figura 16, que o

sistema recebe uma ação, e só após este transitar para um novo estado é que o método

“gerarTarefa()” é chamado, sendo que só nesse momento é que é enviada a resposta à ação

reportada pelo OpenSimulator, ou seja, o sistema transita para um novo estado quer as tarefas

dadas ao OpenSimulator sejam ou não executadas, mesmo que o OpenSimulator nem receba a

resposta à ação (por exemplo: por problemas de comunicação) o estado do sistema ou do

avatar já será outro, como se as mesmas tivessem sido realizadas. Era necessário eliminar este

problema de modo a ter um sistema mais fiável.

Desta forma, conforme mencionado anteriormente, o protótipo apresentado ao longo

da subsecção 2.1, permite reproduzir as tarefas de instalação de um motor dentro da

fuselagem da aeronave, contudo, cada componente tem de ser concebido individualmente e

depois importado e adaptado por programadores, inclusive as características

38

comportamentais são também implementadas, obrigatoriamente, pelos programadores, o que

impossibilita a concretização do objetivo desta dissertação.

4.3 ESPECIFICAÇÃO DOS NOVOS REQUISITOS

Face a esta situação e tendo em consideração o conhecimento adquirido com a análise

ao funcionamento desse mesmo protótipo, apresentado ao longo da secção 3, bem como a

concretização dos objetivos primordiais definidos e já referenciados previamente, obtiveram-

se então os seguintes requisitos:

o Requisitos não funcionais:

A criação e personalização de qualquer tipo de definições deve ser fácil e

intuitiva para os utilizadores;

O sistema deve ser independente do ambiente 3D utilizado, devendo ser

adaptável a plataformas 3D existentes;

o Requisitos funcionais:

Permitir definir a lista de objetos intervenientes na simulação, e as suas

informações;

Permitir definir a lista de estados (etapas) que constituem a simulação;

Permitir definir, para cada estado, a lista de ações disponíveis e o(s) estado(s)

resultante(s) para cada uma destas;

Possibilitar definir para cada ação disponível em cada estado, a lista de tarefas

a enviar como resposta;

Possibilitar definir para cada ação disponível em cada estado, restrições para o

sistema transitar de estado;

O sistema deve ser versátil, conseguindo carregar e gerar um serviço com

qualquer tipo de definições presentes nos ficheiros de configuração;

O sistema deve ainda, transitar apenas de estado após ter a confirmação que as

tarefas a realizar foram recebidas.

4.4 EVOLUÇÃO DO SISTEMA DE DECISÃO E CONTROLO

Anteriormente, o objetivo além de englobar o desenvolvimento de um simulador com

os devidos requisitos, procurava também conceber um modelo tecnológico sólido e robusto,

que possibilita-se alterar o funcionamento do simulador, alterar o ambiente 3D e adequar o

39

sistema a novos requisitos de forma mais rápida e simples. No entanto, agora o objetivo

tornou-se mais ambicioso: conceber um modelo tecnológico que permita gerar o

funcionamento do simulador a partir de ficheiros de configuração personalizados por

utilizadores, cumprindo assim também o objetivo primordial desta dissertação.

Face a estes requisitos, optou-se então por uma abordagem onde o modelo

tecnológico era constituído por programas/sistemas distintos, um responsável por oferecer

uma interface de fácil utilização e intuitiva, para o utilizador criar e personalizar, os ficheiros de

configuração com as definições desejadas e o outro que seria então o sistema de decisão de

controlo, responsável por aplicar ao ambiente 3D toda a lógica funcional presente nesses

mesmos ficheiros de configuração.

FIGURA 18 – DIAGRAMA DE CLASSES (NOVA ARQUITETURA)

40

De modo a facilitar a comunicação/ligação ao ambiente 3D, o novo sistema de decisão

e controlo foi implementado através de um webservice desenvolvido na plataforma ASP.NET, e

para a facilitar esta implementação foi conceptualizada uma representação da estrutura e

relação das várias classes integrantes no sistema. Este modelo define todas as classes que o

sistema necessita incorporar, as suas relações, os seus elementos e funções. Na Figura 18, é

apresentado o diagrama de classes idealizado para o sistema de decisão e controlo.

Como se pode apurar pela figura 18, são necessárias sete classes para o sistema de

decisão e controlo funcionar.

A classe principal do sistema, ou seja, a que é responsável por gerir todo o

funcionamento do sistema é a classe “Manager”, foi implementada segundo o padrão de

software “Singleton”. Usou-se este padrão de software com o objetivo de garantir que todos

os pedidos efetuados ao sistema acedessem à mesma instância desta classe, e deste modo

assegurar que ao longo dos pedidos não havia perda de dados, e que estes eram processados

sempre em função de dados atualizados. Esta classe contém uma lista dos objetos

intervenientes na simulação e uma lista de todos os estados (etapas) possíveis da simulação,

bem como a informação do(s) estado(s) atual do sistema e do estado atual do(s) avatar(es).

Esta possui ainda dois métodos, um que processa qualquer ação reportada pelo ambiente 3D e

outro que recebe todas as confirmações relativamente à execução das tarefas enviadas para o

ambiente 3D como resposta às ações anteriormente reportadas.

A classe “Object” tem como único propósito armazenar toda a informação necessária,

relativamente a cada um dos objetos intervenientes na simulação.

A classe “State” tem como principal objetivo armazenar toda a informação sobre cada

um dos estados (etapas) possíveis da simulação, em especial, a que ações no ambiente 3D,

este estado vai responder. Esta classe contém ainda dois métodos, um que verifica se este

estado responde à ação reportada pelo ambiente 3D, e em caso afirmativo invoca um método

que avalia se estão cumpridos todos os requisitos para que esta ação seja processada pelo

sistema, e outro, para tratar da ação reportada pelo ambiente 3D, enviando como resposta a

esta, as tarefas a serem executadas.

A classe “ForwardingAgent” é responsável pelo armazenamento de diversos tipos de

informação relativamente a cada ação que um determinado estado responde, nomeadamente,

o estado que resulta desta ação, ou seja, o estado para que o sistema transita como resultado

a esta ação, quais as restrições para esta transição ocorrer, quais as tarefas a enviar como

resposta ao ambiente 3D, o número de vezes que essas tarefas têm de ser executadas, com

quantos participantes e qual o tempo máximo para tal. Esta classe possui ainda um método

41

que avalia se estão cumpridos todos os requisitos para que esta ação seja processada pelo

sistema.

A classe “Response” tem com função armazenar e gerir a lista de tarefas a enviar como

resposta a ações reportadas pelo ambiente 3D. Possuindo também dois métodos, um que

permite adicionar facilmente mais uma tarefa à lista, e outro que transforma a lista de tarefas

numa string com um determinado padrão definido no protocolo de comunicação.

A classe “Task” apenas tem como função armazenar, sobre cada tarefa, qual o tipo e

quais os parâmetros de cada uma.

A classe “TaskItem” é apenas responsável por armazenar a informação sobre cada tipo

de tarefa.

FIGURA 19 – FLUXOGRAMA DO FUNCIONAMENTO BÁSICO DO SISTEMA DE DECISÃO E CONTROLO

42

De modo a entender o funcionamento do sistema de decisão e controlo mais

detalhadamente e de forma mas simples e rápida, foi criado um fluxograma facilitando assim a

sua explicação.

Como se pode verificar através da Figura 19, assim que o sistema (webservice) é

iniciado, são carregadas todas as definições presentes nos ficheiros de configuração, ou seja,

todo o funcionamento da simulação é gerado a partir do que está presente nesses mesmos

ficheiros. A partir desse momento o sistema de decisão e controlo está pronto para receber os

pedidos do ambiente 3D, e estará sempre à espera dos mesmos, pois, a partir daí, todo o seu

funcionamento terá como base esses mesmos pedidos.

Caso o pedido efetuado pelo ambiente 3D seja do tipo “Action Reported”, a primeira

verificação que o sistema vai realizar é ver se o avatar que praticou a ação é “novo” para o

sistema, ou seja, se este ainda não está registado no sistema, comprovando-se isto, este

avatar é registado e é-lhe atribuído o estado que está predefinido como sendo o estado inicial

para os avatares. Em seguida, o sistema vai verificar se o seu estado atual, ou o estado atual

do avatar que praticou a ação, consegue lidar com essa mesma ação. Não conseguindo, o

sistema enviará uma resposta vazia ao ambiente 3D, continuando a aguardar mais pedidos por

parte deste. Caso um dos estados consiga lidar com a ação, o sistema irá processá-la, e de

seguida, como resposta, enviará ao ambiente 3D uma lista de tarefas a executar, continuando

constantemente a aguardar por pedidos do ambiente 3D.

Caso o pedido efetuado seja do tipo “Action Confirmed”, o sistema verifica se o estado

atual está “completo”, ou seja, mediante a ação que é confirmada, se algum estado já cumpre

todos os requisitos, transita para um outro, caso ainda não seja possível, o sistema apenas

continua a aguardar mais pedidos por parte do ambiente 3D, caso se verifique que o estado já

se encontra “completo”, o sistema transita de estado passando para o estado resultante da

ação confirmada, continuando sempre a aguardar novos pedidos do ambiente 3D.

4.5 EVOLUÇÃO DO PROTOCOLO DE COMUNICAÇÃO

Com a implementação deste novo sistema de decisão e controlo, e as alterações ao

módulo view genérico, perspetivou-se que seria possível obter uma maior generalização nas

comunicações, o que levou a definir esta generalização como um novo requisito. Provocando

assim, a realização de algumas alterações, essencialmente em resposta a este mesmo

requisito, passando a haver apenas dois dos quatro tipos de protocolo anteriormente

definidos, e tornando o protocolo de comunicação mais homogéneo. Com este novo sistema

de decisão e controlo, e estando todos objetos intervenientes na simulação definidos no

43

ficheiro de configuração, identificou-se a necessidade de nas respostas ao ambiente 3D,

informar se para aquelas tarefas são para usar, ou não, coordenadas globais, devido ao facto

de poder existir objetos compostos por vários objetos e nesses casos o tipo de coordenadas a

utilizar são diferentes. Face a esta necessidade definiu-se como novo requisito, a reformulação

do protocolo de comunicação, de modo a este integrar a informação do uso, ou não, de

coordenadas globais.

Assim, os dois tipos de protocolo utilizados são:

Sistema de Decisão e Controlo – Ambiente 3D (Tabela 5), teve-se como base o

anterior (Tabela 1) reformulando-se de forma a satisfazer o novo requisito apresentado acima;

Ambiente 3D – Sistema de Decisão e Controlo (Tabela 3), deixamos de ter os dois

subtipos diferentes deste tipo de protocolo;

De modo a entender mais facilmente o protocolo usado para comunicações enviadas

do sistema de decisão e controlo para o ambiente 3D, é apresentada em seguida uma

hipotética resposta desse tipo, e posteriormente, explicado cada um dos campos da mesma.

2 0 0 2 0 Bom dia 1001 1 www.google.com

TABELA 6 - EXEMPLO DE COMUNICAÇÃO DO TIPO: SISTEMA DE DECISÃO CONTROLO – AMBIENTE 3D

Tomando este exemplo, como uma resposta real para o ambiente 3D, este

interpretaria a mensagem da seguinte forma:

2 = Número de tarefas a serem executadas;

0 = Não é para usar coordenadas globais;

0 = Género da 1ª tarefa, neste caso 0 corresponde à tarefa de falar;

2 = Número de parâmetros desta primeira tarefa;

TABELA 5 - NOVO PROTOCOLO DE COMUNICAÇÃO: SISTEMA DE DECISÃO CONTROLO – AMBIENTE 3D


Parâmetro 1 Número inteiro Corresponde ao número de tarefas que o Sistema de Decisão e Controlo envia

como resposta

Parâmetro 2 Número inteiro Corresponde se nestas tarefas é para

usar coordenadas globais

Parâmetro 3 Número inteiro Corresponde a uma tarefa a realizar, ex:

1-Falar, 2- Mover

Parâmetro 4 Número inteiro Corresponde ao número de parâmetros

que a tarefa vai ter

Parâmetro 5, 6,…, n String Corresponde aos parâmetros

específicos de uma determinada tarefa

44

0 = Canal em que terá que falar, neste caso 0 significa canal público;

Bom dia = Mensagem a comunicar;

1001 = Género da 2ª tarefa, neste caso 1001 corresponde à tarefa de carregar uma página;

1 = Número de parâmetros desta segunda tarefa;

www.google.pt = A página a carregar.

4.6 EVOLUÇÃO DO SCRIPT LSL COMO MÓDULO VIEW GENÉRICO

Ao nível do módulo view genérico (script desenvolvido em LSL) a estrutura do que já

havia sido criado, manteve-se quase na sua totalidade. De modo a satisfazer o requisito de o

sistema apenas transitar de estado após ter a confirmação que as tarefas a realizar foram

recebidas, e o novo requisito identificado na subsecção anterior, da reformulação do protocolo

de comunicação, de modo a este integrar a informação do uso, ou não, de coordenadas

globais, foi no entanto necessário realizar algumas alterações ao módulo view genérico.

Desta forma, foi alterado no script o modo de comunicação com os outros objetos,

passando esta comunicação a ter uma estrutura mais idêntica com a comunicação que o

sistema de decisão e controlo tem com o ambiente 3D, estrutura essa que será apresentada e

explicada detalhadamente no próximo subcapítulo.

Com o intuito de satisfazer o requisito anteriormente mencionado, de o sistema

apenas transitar de estado após ter a confirmação que as tarefas a realizar foram recebidas, foi

realizada uma outra alteração significativa a este script, a implementação de um pedido ao

sistema de decisão de controlo, após terem sido executadas todas as tarefas recebidas como

resposta a uma ação reportada, de modo a este tomar conhecimento sobre o sucedido.

4.7 ESTRUTURA DOS DADOS

Para que a personalização e criação de todo o funcionamento da simulação fosse

realizado de forma simples e intuitiva, e posteriormente o sistema de decisão e controlo

funcionasse, na sua plenitude, sem correr quaisquer riscos de falhas ao nível do carregamento

das definições presentes nos ficheiros de configuração, foi necessário definir para os ficheiros

de configuração um estrutura sólida e robusta, mas ao mesmo tempo versátil, capaz de

guardar detalhadamente todas as definições. Para estes ficheiros de configuração optou-se

pelo uso de uma linguagem de anotação, baseada em XML, pois é um tipo de formato usado

para a criação de documentos com dados organizados de forma hierárquica.

45

Deste modo, tem-se dois tipos de estruturas distintos, uma para o ficheiro de

configuração relativo aos objetos e outra para o ficheiro de configuração relativo ao

funcionamento da simulação. Estas estruturas são expostas em seguida, através da

apresentação dos respetivos DTD, bem como a árvore de componentes, correspondente a

cada um deles para uma mais fácil interpretação.

<?xml version="1.0" encoding="UTF-8"?>

<!ELEMENT Name (#PCDATA)>

<!ELEMENT Key (#PCDATA)>

<!ELEMENT IsLinked (#PCDATA)>

<!ELEMENT Coordinates (#PCDATA)>

<!ELEMENT Rotation (#PCDATA)>

<!ELEMENT Object ((Name, Key, IsLinked, Coordinates, Rotation))>

<!ELEMENT ArrayOfObject ((Object+))>

<!ATTLIST ArrayOfObject

xmlns:xsd CDATA #FIXED "http://www.w3.org/2001/XMLSchema"

xmlns:xsi CDATA #FIXED "http://www.w3.org/2001/XMLSchema-instance"

>

FIGURA 20 - DTD DO FICHEIRO DE CONFIGURAÇÃO DOS OBJETOS

FIGURA 21 - ÁRVORE DE COMPONENTES DO FICHEIRO DE CONFIGURAÇÃO DOS OBJETOS

46

<?xml version="1.0" encoding="UTF-8"?>

<!ELEMENT string (#PCDATA)>

<!ELEMENT TasksOfResponse ((Task))>

<!ELEMENT TaskID ((Name, ID))>

<!ELEMENT Task ((TaskID, Parameters))>

<!ELEMENT State ((ForwardingAgents, Name))>

<!ELEMENT ResultStateName (#PCDATA)>

<!ELEMENT Restrictions EMPTY>

<!ELEMENT Reply ((TasksOfResponse))>

<!ELEMENT Parameters ((string+))>

<!ELEMENT Operators (#PCDATA)>

<!ELEMENT Operations (#PCDATA)>

<!ELEMENT ObjectName (#PCDATA)>

<!ELEMENT Name (#PCDATA)>

<!ELEMENT MaxTime (#PCDATA)>

<!ELEMENT ID (#PCDATA)>

<!ELEMENT ForwardingAgents ((ForwardingAgent))>

<!ELEMENT ForwardingAgent ((Reply, Restrictions, Name, ObjectName, ResultStateName,

Operations, MaxTime, Operators))>

<!ELEMENT ArrayOfState ((State))>

<!ATTLIST ArrayOfState

xmlns:xsd CDATA #FIXED "http://www.w3.org/2001/XMLSchema"

xmlns:xsi CDATA #FIXED "http://www.w3.org/2001/XMLSchema-instance"

>

FIGURA 23 - DTD DO FICHEIRO DE CONFIGURAÇÃO DA SIMULAÇÃO

FIGURA 22 - ÁRVORE DE COMPONENTES DO FICHEIRO DE CONFIGURAÇÃO DA SIMULAÇÃO

47

4.8 INTERFACE GRÁFICA

Para a criação dos ficheiros de configuração poder ser realizável por utilizadores finais,

de forma rápida e simples, sem ter necessariamente conhecimentos de programação, foi

desenvolvida uma interface gráfica simples mas funcional, permitindo não apenas a criação

como também a modificação de ficheiros de configuração já criados anteriormente,

possibilitando desta forma testar o protótipo criado.

Assim que a aplicação é iniciada, surge a janela inicial (Figura 24), que contém duas

opções: criar uma nova simulação ou editar uma simulação já criada anteriormente. Para criar

uma nova simulação o utilizador apenas tem de clicar na opção “New Simulation”, surgindo de

imediato a janela referente ao menu dessa mesma simulação, que permite ao utilizador abrir

quer a janela de configuração dos objetos, quer a janela de configuração dos estados da

simulação (onde são atribuídos comportamentos aos objetos).

FIGURA 24 - JANELA INICIAL E MENU DA SIMULAÇÃO (EDITOR DO SISTEMA)

FIGURA 25 - JANELA DE CONFIGURAÇÃO DOS OBJETOS (LISTA DE OBJETOS)

48

Não será possível ao utilizador abrir a janela de configuração dos estados, se ainda não

tiver definido os objetos para a simulação. Para registar os objetos intervenientes na simulação

o utilizador deve clicar na opção “Manage Objects”, que abrirá a janela de configuração dos

objetos. Esta janela é composta por duas secções: uma (Figura 25) onde é apresentada a lista

de todos os objetos já registados e onde se encontra a opção de guardar esta mesma lista; e

outra (Figura 26) que permite registar um novo objeto. Para efetuar este registo é necessário

introduzir algumas informações relativas ao objeto, tais como: o seu nome, o seu identificador

único, as suas coordenadas no mundo virtual; estas informações podem ainda ser completadas

pela introdução da rotação, bem como pela indicação se este objeto é um elemento

independente, ou se é parte integrante de um outro objeto. Para obter todas estas

informações é necessário ir ao mundo virtual, consultar as propriedades do objeto.

Após estarem registados todos os objetos necessários para a simulação, o utilizador

deve guardar a lista, clicando na opção “Save Objects List”. Em seguida, já é possível ao

utilizador abrir a janela de configuração dos estados clicando na opção “Manage States”. Esta

janela é constituída por quatro secções: uma (Figura 27) onde é possível criar novos estados,

onde é apresentada a lista de todos os estados já criados e onde se encontra a opção de

guardar esta mesma lista; outra (Figura 28) onde é possível para cada estado adicionar as

ações exequíveis bem como definir qual o estado que resulta dessa ação, ou seja, permite

definir as ações a que esse estado responde e o estado para o qual o sistema transita quando

esta ação ocorre; outra (Figura 29) que permite adicionar restrições às ações, ou seja, definir

para cada ação requisitos que têm de ser cumpridos para que essa ação possa ser processada;

FIGURA 26 – JANELA DE CONFIGURAÇÃO DOS OBJETOS (REGISTAR NOVO OBJETO)

49

e por fim uma outra secção (Figura 30) que permite adicionar para cada ação de um

determinado estado, quais as tarefas a enviar como resposta para o mundo virtual.

Em primeiro lugar, na secção onde é possível criar novos estados (Figura 27), o

utilizador deve definir todos os estados (etapas) necessários para a simulação pretendida.

Numa segunda fase, o utilizador deve na secção de “adicionar ações” (Figura 28), definir para

cada estado, as ações possíveis para o mesmo. Para isto, o utilizador deve: selecionar o estado

ao qual vai adicionar a ação; em seguida, selecionar se a ação vai ou não ser colaborativa, caso

seja, definir quantas vezes esta ação tem de ser realizada, quantos elementos são necessários

e qual o tempo máximo para os mesmos a realizarem; selecionar dentro dos eventos

FIGURA 27 - JANELA DE CONFIGURAÇÃO DOS ESTADOS (LISTA DE ESTADOS)

FIGURA 28 - JANELA DE CONFIGURAÇÃO DOS ESTADOS (ADICIONAR AÇÕES)

50

disponíveis qual o pretendido; selecionar sobre qual objeto a ação vai ser praticada; e por fim,

selecionar qual o estado que resulta dessa mesma ação.

Após ter definido para todos os estados, todas as ações possíveis, o utilizador deve em

seguida definir restrições para as ações a que isto se aplica (por exemplo: apertar um parafuso

não pode ser feito sem antes pegar na chave apropriada). Para isto, o utilizador deve na secção

para este efeito (Figura 29), selecionar o estado, e mediante isso, a ação desse mesmo estado

a que quer adicionar a restrição, e por fim selecionar a restrição que pretende.

Por fim, o utilizador deve adicionar para todas as ações, de todos os estados, quais as

tarefas a enviar como resposta. Assim em primeiro lugar, na secção de adicionar as tarefas

FIGURA 29 - JANELA DE CONFIGURAÇÃO DOS ESTADOS (ADICIONAR RESTRIÇÕES)

FIGURA 30 - JANELA DE CONFIGURAÇÃO DOS ESTADOS (ADICIONAR TAREFAS)

51

(Figura 30) o utilizador deve: selecionar um estado; em seguida, selecionar uma ação desse

mesmo estado; após isto, deve dentro das tarefas disponíveis, escolher a desejada; por fim,

depois de ter adicionado essa tarefa, o utilizador deve clicar nela de modo a especificar alguns

parâmetros relacionados com a mesma (por exemplo: se a tarefa for anexar alguma

ferramenta ao “avatar”, especificar a que mão esta se deve anexar).

Assim que o utilizador tiver todos os comportamentos definidos para a simulação, este

deve voltar à secção onde é apresentada a lista de todos os estados (etapas) da simulação e

guardar esta lista, clicando na opção “Save States List”, tornando possível de imediato realizar

esta mesma simulação.

53

CAPÍTULO 5: TESTES COM UTILIZADORES

“Technology is a gift of God. After the gift of life it is perhaps the greatest of God's

gifts. It is the mother of civilizations, of arts and of sciences.”

Freeman Dyson

Este capítulo é referente à realização de testes com utilizadores, numa fase inicial são

expostos os testes realizados e o que se pretendia auferir com eles, e em seguida são

apresentados os resultados dos mesmos, bem como as evidências que se conseguiram extrair

com os resultados obtidos.

54

5.1 AMBIENTE DE TESTES

De forma a conseguir aferir se o sistema estaria acessível a qualquer utilizador e a

detetar possíveis erros no estado atual do mesmo, foram realizados testes ao protótipo

desenvolvido com diversos utilizadores. Estes testes de utilização revelaram-se bastante

produtivos, pois ajudaram a detetar pequenos erros na interface gráfica, bem como perceber

o que poderia ser melhorado para o sistema ficar mais acessível aos utilizadores em geral.

Para estes testes foram construídos os seguintes instrumentos:

o Termo de consentimento;

o Questionário de caracterização de perfil;

o Questionário de satisfação;

o Meio de suporte à recolha de dados complementares.

O questionário de caracterização de perfil foi elaborado com o objetivo de aferir o

conhecimento dos utilizadores em mundos virtuais, e experiências prévias neste tipo de

ambientes. Já o questionário de satisfação foi elaborado com o objetivo de aferir a opinião dos

utilizadores relativamente a vários aspetos do sistema e quais as melhorias que sugeriam.

Foi elaborada uma lista com onze tarefas, a serem executadas pelo utilizador, tendo

sido criado o meio de suporte à recolha de dados complementares, de forma a anotar

devidamente, para cada uma dessas tarefas, os tempos de execução, erros resultantes da ação

dos utilizadores, as dúvidas surgidas e todas as observações que fossem necessárias.

Uma vez que a recolha de dados seria realizada com recurso a questionários, foi criado

um termo de consentimento onde se pedia a autorização para a análise e utilização dos dados.

Pode-se observar com mais detalhe este termo de consentimento no anexo 1, bem como o

questionário de caraterização de perfil e o questionário de satisfação nos anexos 2 e 3

respetivamente.

Os testes foram realizados numa sala com algum grau de isolamento do ambiente

exterior, sonoro, para que fossem mínimas as interferências. Foi inicialmente explicado a cada

utilizador qual o propósito do teste, em que projeto se inseria, assim como o objetivo da

aplicação que iam testar. Após este momento, foi pedido ao utilizador que respondesse ao

questionário de caracterização do perfil, logo após, foi realizada uma breve explicação ao

utilizador de como utilizar a aplicação, tendo sido descrito para que servia cada controlo e

como se interagia com ela. Em seguida, foi também fornecido ao utilizador um documento

com o objetivo pretendido e com algumas instruções sobre as ações que o utilizador tinha que

executar durante o teste.

55

Enquanto o utilizador executava as tarefas pretendidas, eram então registados alguns

dados complementares, nomeadamente: o tempo de execução de cada uma, o número de

erros efetuados pelo utilizador, bem como o número de dúvidas. Após serem executadas todas

as tarefas, era demonstrado ao utilizador o resultado do que tinha criado, ou seja, era

realizada a simulação criada por ele. Por fim, era pedido que este preenchesse o questionário

de satisfação sobre o sistema utilizado.

5.2 CARACTERIZAÇÃO DA AMOSTRA

De forma a avaliar a satisfação dos utilizadores na utilização do sistema, a sua opinião

relativamente a vários aspetos do sistema, bem como detetar possíveis melhorias para o

mesmo, foi preparado um questionário com um conjunto de perguntas e um meio de suporte

à recolha de dados complementares, para anotar os tempos de execução, os erros e as dúvidas

para cada uma dessas tarefas a executar pelos utilizadores. Foram efetuados testes a uma

população de 12 indivíduos, todos eles do sexo masculino e com idades compreendidas entre

18 e 30 anos.

Destes utilizadores, 5 tinham idades compreendidas entre 18 e 24 anos, o que equivale

a 42% do total de indivíduos que fizeram avaliação. Por sua vez, 7 utilizadores tinham idades

compreendidas entre 25 e 30 anos que equivale a 58%, como mostra o Gráfico 1.

Para avaliar a experiência do utilizador a nível informático, foi perguntado a todos os

indivíduos que efetuaram o teste se usam computador, com que frequência o usam e com que

finalidades. Todos os utilizadores responderam que usam o computador, o que equivale a

GRÁFICO 1 - CLASSIFICAÇÃO DOS UTILIZADORES QUANTO À IDADE

56

100% do total de indivíduos que fizeram avaliação, variando apenas a frequência com que o

utilizam.

Constata-se que apenas 17% dos utilizadores utiliza o computador diariamente, no

entanto, apenas uma vez por dia, enquanto 83% dos utilizadores (grande maioria), utiliza-o

diariamente mas várias vezes ao longo do dia, sendo de salientar ainda que nenhum dos

utilizadores o utiliza apenas semanalmente, como mostra o Gráfico 2. As finalidades com que

cada utilizador utiliza o computador são bastante diversas.

Como se pode observar pelo Gráfico 3 são diversas as finalidades do uso do

computador, sendo de salientar que 7 dos utilizadores (a maior parte) utiliza-o como meio de

GRÁFICO 2 - CLASSIFICAÇÃO DOS UTILIZADORES QUANTO À FREQUÊNCIA COM QUE USA O COMPUTADOR

GRÁFICO 3 - CLASSIFICAÇÃO DOS UTILIZADORES QUANTO À FINALIDADE COM QUE USAM O COMPUTADOR

57

trabalho, e ainda 5 utilizadores responderam que o utiliza para todas as finalidades

apresentadas.

Indo de encontro a questões mais específicas da presente dissertação, foi perguntado

a todos os indivíduos que efetuaram o teste, se conheciam mundos virtuais, quais conheciam,

se já os tinham utilizado, quais tinham utilizado e com que finalidades, se já tinham tido algum

tipo de formação quer para utilização quer para programação em mundos virtuais, sobre quais

tinham tido essa formação, e por fim, como classificavam a sua capacidade quanto à utilização

ou programação em mundos virtuais, para avaliar a experiência do utilizador relativamente a

estes.

Todos os utilizadores responderam que conheciam algum mundo virtual, sendo que,

todos eles afirmaram conhecer o Second Life, apenas 9 dos utilizadores disse conhecer o

Opensimulator, e apenas um deles mencionou conhecer outro mundo virtual para além

destes, como mostra o Gráfico 4.

GRÁFICO 5 - CLASSIFICAÇÃO DOS UTILIZADORES QUANDO À UTILIZAÇÃO DE MUNDOS VIRTUAIS

GRÁFICO 4 - CLASSIFICAÇÃO DOS UTILIZADORES QUANTO AOS MUNDOS VIRTUAIS QUE CONHECEM

58

Quanto ao facto de já ter utilizado algum mundo virtual, apenas 1 utilizador, que

corresponde a 8% da amostra, disse nunca ter utilizado um mundo virtual, tendo os restantes

11 utilizadores, que corresponde a 92% da amostra, respondido afirmativamente a esta

questão, como mostra o Gráfico 5.

Como se pode observar no Gráfico 6, todos os utilizadores que responderam ter usado

algum mundo virtual, dizem ter usado o Second Life, sendo que apenas 7 desses utilizadores

indicam já ter usado também o Opensimulator.

Relativamente à finalidade com que os utilizadores usaram os mundos virtuais, pode-

se verificar que 8 deles (a grande maioria) o utilizou como trabalho, 3 desses utilizadores já

GRÁFICO 6 - CLASSIFICAÇÃO DOS UTILIZADORES QUANTO AOS MUNDOS VIRTUAIS QUE UTILIZOU

GRÁFICO 7 - CLASSIFICAÇÃO DOS UTILIZADORES QUANTO À FINALIZAÇÃO COM QUE USARAM MUNDOS VIRTUAIS

59

usaram para formação, apenas 3 utilizadores já usaram como forma de entretimento, e 3

como forma de socialização, sendo de salientar ainda que 2 utilizadores já usaram para todas

as finalidades apresentadas, como mostra o Gráfico 7.

Quanto ao facto de já ter tido algum tipo de formação para a utilização de mundos

virtuais 3D, apenas 7 utilizadores responderam positivamente, o que corresponde a 58%

amostra, sendo que os restantes 5 utilizadores, que correspondem a 42% da amostra

afirmaram nunca ter tido nenhum tipo de formação para a utilização dos mesmos, como

mostra o Gráfico 8.

Como se pode observar no Gráfico 9, todos os utilizadores que anteriormente

afirmaram já ter tido algum tipo de formação para a utilização de mundos virtuais 3D,

GRÁFICO 8 - CLASSIFICAÇÃO DOS UTILIZADORES QUANTO À OBTENÇÃO DE FORMAÇÃO PARA UTILIZAR MUNDOS VIRTUAIS

GRÁFICO 9 - CLASSIFICAÇÃO DOS UTILIZADORES QUANTO AO MUNDO VIRTUAL PARA O QUAL OBTIVERAM FORMAÇÃO

60

responderam ter tido essa formação para utilizar o Seconde Life, sendo que apenas 3 desses

utilizadores mencionaram terem também tido formação para utilizar o Opensimulator.

Dos utilizadores que afirmaram já ter tido algum tipo de formação para a utilização de

mundos virtuais 3D, 5 deles classificaram a sua capacidade de utilização como sendo boa, o

que equivale a 72% dos utilizadores que obtiveram formação, no entanto 1 desses utilizadores

classificou a sua capacidade de utilização como medíocre e ainda 1 deles classificou como

muito má, como mostra o Gráfico 10.

Quanto ao facto de já ter tido algum tipo de formação para a programação em mundos

virtuais 3D, todos os utilizadores que anteriormente responderam de forma positiva quanto à

formação para a utilização dos mesmos, responderam aqui de igual modo. Sendo que desses 7

GRÁFICO 10 - CLASSIFICAÇÃO DOS UTILIZADORES QUANTO À CAPACIDADE DE UTILIZAÇÃO DE MUNDOS VIRTUAIS

GRÁFICO 11 - CLASSIFICAÇÃO DOS UTILIZADORES QUANTO À OBTENÇÃO DE FORMAÇÃO PARA PROGRAMAR EM MUNDOS VIRTUAIS

61

utilizadores todos mencionaram ter sido o Second Life o mundo virtual para o qual obtiveram a

formação para programar, e apenas 4 desses utilizadores responderam que tiveram essa

formação também para o mundo virtual Opensimulator, como mostra o Gráfico 11.

Como se pode observar no Gráfico 12, dos utilizadores que afirmaram já ter tido algum

tipo de formação para programar em mundos virtuais 3D, apenas 3 deles classificaram a sua

capacidade de programação em mundos virtuais como sendo boa, o que equivale a 43% dos

utilizadores que obtiveram esse tipo de formação, sendo que 3 desses utilizadores classificou a

sua capacidade de programação nos mesmo como medíocre, o que equivale a 43%, e ainda 1

deles classificou a sua capacidade de programação como muito má.

5.3 ANÁLISE DE RESULTADOS

Dos questionários de satisfação, bem como dos dados complementares recolhidos

após os testes realizados pelos utilizadores, resultou uma análise à informação obtida, com o

objetivo de poder concluir acerca do sucesso do sistema. A síntese desses resultados é

apresentada de seguida.

Para testar o sistema tal como mencionado na subsecção 5.1, foi elaborada uma

pequena lista com onze tarefas, a serem executadas pelo utilizador, sendo retirados, para cada

uma delas, os tempos de execução, erros resultantes da ação dos utilizadores, as dúvidas

surgidas e todas as observações que fossem necessárias. Assim sendo, segue-se a lista das

onze tarefas que o utilizador teve que executar:

1. Abrir a aplicação e criar uma nova simulação.

GRÁFICO 12 - CLASSIFICAÇÃO DOS UTILIZADORES QUANTO À CAPACIDADE DE PROGRAMAÇÃO EM MUNDOS VIRTUAIS

62

2. Abrir a janela de configuração dos objetos da simulação.

3. Registar o objeto “Aparafusadora” na simulação.

4. Registar o objeto “Carrinho” na simulação.

5. Guardar o ficheiro de configuração dos objetos.

6. Abrir a janela de configuração da simulação.

7. Registar os estados da simulação/etapas a simular (CarrinhoNormal,

CarrinhoMovido, MaosLivres, AparafusadoraEquipada).

8. No Estado “MaosLivres” adicionar a ação do toque na Aparafusadora, e no Estado

“CarrinhoNormal” adicionar a ação do toque no Carrinho.

9. No Estado “CarrinhoNormal”, a ação de toque no carrinho, configurada

anteriormente, terá a restrição de ter que ter a aparafusadora equipada

10. No Estado “MaosLivres”, na ação do toque na Aparafusadora adicionar a resposta a

esta ação. E no estado “CarrinhoNormal” na ação do toque no Carrinho adicionar a resposta a

esta ação.

11. Guardar o ficheiro de configuração da simulação.

No Gráfico 13 está presente o tempo mínimo, máximo e médio resultante de todos os

testes analisados para cada tarefa. Observando este gráfico relativo à análise dos tempos de

execução de cada tarefa, pode-se concluir que mesmo existindo uma variação significativa

entre o tempo mínimo e o máximo de cada tarefa, a oscilação entre eles é idêntica, ou seja, as

tarefas mais demoradas, bem como as mais rápidas foram as mesmas quer para os tempos de

execução mínimos e máximos. Pode-se concluir ainda que não houve nenhuma tarefa em que

GRÁFICO 13 - ANÁLISE DOS TEMPOS DE EXECUÇÃO DAS TAREFAS

63

a média ultrapassasse os 80 segundos (1 minutos e 20 segundos), o que leva a acreditar que

nenhuma tarefa era de carácter extremamente difícil ou complexo.

Como se pode observar no Gráfico 14, em alguns dos testes não existiu qualquer

dúvida, pode se verificar ainda que o máximo de dúvidas que houve relativamente a uma

tarefa foram 2 e em uma única tarefa, tendo ficado todas as tarefas com uma média de

dúvidas inferior a 0,5, podendo-se concluir também aqui que as tarefas não eram demasiado

complexas e o próprio sistema não levantava grandes dúvidas.

Ao nível dos erros cometidos pelos utilizadores na execução das tarefas, tal como

podemos observar no Gráfico 15, praticamente não existiram em nenhuma tarefa, à exceção

GRÁFICO 14 - ANÁLISE DAS DÚVIDAS QUE SURFIRAM NA EXECUÇÃO DAS TAREFAS

GRÁFICO 15 - ANALISE DOS ERROS PRATICADOS NA EXECUÇÃO DAS TAREFAS

64

de duas, onde houve como máximo 1 erro cometido, este erro pode estar relacionado com

alguma ansiedade por parte dos utilizadores. A quase inexistência de erros vem mais uma vez

provar que as tarefas não eram demasiado complexas e o próprio sistema não levantava

grandes dúvidas.

Como se pode observar no Gráfico 16, no questionário de satisfação, 9 utilizadores

classificaram o sistema como fácil de utilizar, o que corresponde a 75% da amostra, havendo

ainda 3 utilizadores que classificaram o mesmo como muito fácil de utilizar, o que corresponde

a 25% da amostra.

Relativamente à intuitividade do sistema, 8 utilizadores classificaram o mesmo como

intuitivo, o que representa 67% da amostra, tendo ainda 2 utilizadores classificado como muito

GRÁFICO 16 - CLASSIFICAÇÃO DO SISTEMA QUANTO À FACILIDADE DE UTILIZAÇÃO

GRÁFICO 17 - CLASSIFICAÇÃO DO SISTEMA QUANTO À INTUITIVIDADE

65

intuitivo, o que equivale a 17% da amostra, e apenas 2 dos utilizadores que equivalem a 17%

classificaram o sistema como pouco intuitivo, como mostra o Gráfico 17.

Já quanto à facilidade de aprendizagem, 7 dos utilizadores classificaram o sistema

como fácil, o que corresponde a 58% da amostra, tendo ainda 4 utilizadores classificado o

mesmo quanto à aprendizagem como muito fácil, o que equivale a 34% da amostra, tendo

apenas 1 utilizador que corresponde a 8% da amostra, classificado de difícil aprendizagem,

como mostra o Gráfico 18.

Como podemos observar no Gráfico 19, todos os utilizadores acharam que, no mínimo,

o sistema facilita a criação de conteúdo nos mundos virtuais 3D, sendo que 6 dos utilizadores

responderam que facilita, o que corresponde a 50% da amostra, e os restantes 6 utilizadores

GRÁFICO 18 - CLASSIFICAÇÃO DO SISTEMA QUANTO À FACILIDADE DE APRENDIZAGEM

GRÁFICO 19 - CLASSIFICAÇÃO DO SISTEMA QUANDO À FACILIDADE DE CRIAÇÃO DE CONTEÚDO

66

responderam que o sistema facilita muito a criação de conteúdo em mundos virtuais, o que

equivale a 50% da amostra.

Os utilizadores quando questionados sobre o sistema ser acessível a qualquer pessoa

que use frequentemente o computador, 5 deles responderam como sendo muito acessível, o

que corresponde a 41% da amostra, 4 responderam que era acessível, o que corresponde a

42% da amostra, sendo que apenas 2 responderam que era pouco acessível, o que equivale a

17% da amostra, como mostra o Gráfico 20.

Como podemos observar no Gráfico 21, todos os utilizadores acharam que este

sistema tem potencial na criação de simulações, sendo que 9 utilizadores responderam que

achavam que o sistema tinha muito potencial, o que corresponde a 75% da amostra, e os

GRÁFICO 20 - CLASSIFICAÇÃO DO SISTEMA QUANTO A SER ACESSÍVEL A QUALQUER PESSOA QUE USE COMPUTADOR

GRÁFICO 21 - CLASSIFICAÇÃO DO SISTEMA QUANTO AO POTENCIAL NA CRIAÇÃO DE SIMULAÇÕES

67

restantes 3 utilizadores responderam que achavam que o sistema tinha algum potencial, o que

equivale a 25% da amostra.

Quanto a terem sentido alguma dificuldade durante a realização do teste, 8 dos

utilizadores, o que corresponde a 67% da amostra, respondeu que não tinha sentido qualquer

dificuldade, tendo apenas 4 utilizadores respondido que sentiram alguma dificuldade o que

equivale a 33% da amostra, como mostra o Gráfico 22.

Como podemos observar no Gráfico 23, dos utilizadores que anteriormente

mencionaram ter sentido alguma dificuldade durante a realização do teste, 3 deles

responderam ter dificuldades relativas ao sistema apresentado, o que equivale a 75% dos

GRÁFICO 22 - ANÁLISE DAS DIFICULDADES SENTIDAS

GRÁFICO 23 - CLASSIFICAÇÃO DO TIPO DE DIFICULDADES

68

utilizadores que tiveram dúvidas, e 1 utilizador responde ter dificuldades relativas ao mundo

virtuais, o que equivale a 25% da amostra.

No final das perguntas de escolha múltipla, do questionário de satisfação, era ainda

pedido aos utilizadores para responderem a uma pergunta de resposta aberta. Onde era

perguntado quais as melhorias que podiam ser adicionadas ao sistema. Apenas 6 dos

utilizadores responderam a essa pergunta, o que equivale a 50% da amostra. Quase todas as

opiniões estavam relacionadas com melhorar a forma de como são registados os objetos no

sistema, de modo a que o processo fosse um pouco mais automático; uma outra melhoria

sugerida era relativa à interface gráfica com que interagiram.

69

CAPÍTULO 6: CONCLUSÕES E TRABALHO FUTURO

“We're changing the world with technology.”

Bill Gates

Neste capítulo faz-se uma análise ao cumprimento dos objetivos propostos para esta

dissertação e procura-se aferir se trouxe ou não as contribuições esperadas. Por fim, termina

com a referência a possíveis focos de trabalho futuro com base nas limitações e necessidades

existentes.

70

6.1 CONCLUSÃO

O objetivo primordial desta dissertação é satisfazer a necessidade sentida pela FAP

aquando a apresentação do protótipo mencionado na subsecção 2.1, que consiste em o

mecânico formador poder durante uma simulação alterar comportamentos de componentes

em tempo real, de forma a analisar a reação dos formandos. Isto passava por desenvolver um

protótipo de sistema capaz de possibilitar que o registo de componentes e comportamentos,

pudesse ser efetuado de forma prática e simples, através de uma interface acessível a

qualquer utilizador; sendo ainda objetivo desta dissertação a realização de alguns testes com

utilizadores.

Pela análise dos resultados obtidos dos testes realizados com utilizadores, conclui-se

que os resultados foram adequados. Contudo, os utilizadores detinham algum conhecimento

acerca dos mundos virtuais, apesar de alguns mencionarem não ter formação para os mesmos,

e a maioria dos que mencionaram ter, não avaliarem a sua capacidade de os utilizar, como

boa, seria uma mais-valia a realização de testes mais aprofundados com utilizadores finais.

Existe neste momento um protótipo funcional que cumpre os objetivos propostos,

nomeadamente, a capacidade de registar componentes e comportamentos, de forma rápida e

prática através de uma interface gráfica.

Foi construído, não apenas um sistema capaz de registar componentes e

comportamentos relativos a esta área da simulação de manutenção mecânica de motores de

F-16, mas também capaz de ser aplicado a outras situações, noutras áreas, possibilitando a

construção de situações de simulação, rapidamente, sem a necessidade de programação

específica.

6.2 REFLEXÕES FINAIS

A nível estritamente pessoal, tal como mencionado na secção introdutória, este

projeto teve o seu início em 2010, tendo eu estado sempre ligado desde então à equipa de

investigação da UTAD associada a desenvolvimento em mundos virtuais. Não tinha qualquer

conhecimento ou preparação, pelo que tudo era novidade para mim. Sendo uma área

bastante interessante, desencadeou em mim uma grande motivação e uma grande energia

para seguir em frente. Este projeto fez-me evoluir tanto como pessoa como a nível

profissional. “Obrigou-me” a abrir a mente e procurar soluções de cariz técnico onde

supostamente não existiam, fazendo desta forma com que cimentasse todos os

conhecimentos adquiridos durante o curso.

71

Embora esta dissertação tenha cumprido todos os objetivos definidos, existe a

ambição de otimizar o produto desenvolvido e todas as funcionalidades associadas. Um dos

aspetos a resolver são as melhorias apontadas pelos utilizadores na realização dos testes,

nomeadamente: alterar o registo de objetos de forma a ficar um processo mais automatizado,

deixando de representar uma tarefa demorada e penosa, no caso de simulações com algum

grau de complexidade; alterar a interface de forma a simplificar ainda mais alguns processos,

tornando assim a utilização do sistema ainda mas intuitiva.

Sendo este sistema destinado à formação e sendo o Moodle o LMS usado pela FAP, a

sua integração com o sistema seria também de valor acrescentado. Assim, faria também

sentido a produção de um relatório de tudo o que é feito pelos formando durante a simulação,

e enviado para o Moodle de modo a ser consultado pelos seus responsáveis.

Seria ainda uma mais-valia tornar este sistema capaz de gerar toda a simulação, não

apenas para o mundo virtual OpenSimulator, mas sim para qualquer ambiente gráfico, onde

um utilizador pudesse escolher qual o ambiente gráfico onde queria que a simulação fosse

realizada.

A nível do simulador seria de enorme valor acrescentar a “inteligência artificial” para

que os formadores possam treinar todo o processo, sem ser necessário outras pessoas

estarem presentes. Já houve um colega com trabalho inicial nesta área, dar-lhe seguimento

representaria também uma mais-valia (Vilela, 2012).

73

REFERÊNCIAS BIBLIOGRÁFICAS

Amaral, I. A. (2008). A@ migração para o Ciberespaço: a Dimensão Social dos Mundos Virtuais.

Observatorio (OBS*), 2(2).

Anstadt, S. P., Burnette, A., & Bradley, S. (2011). Towards a research agenda for social work

practice in virtual worlds. Advances in Social Work, 12(2), 289-300.

Aziz, E. S. S., Chang, Y., Esche, S. K., & Chassapis, C. (2013). A multi‐user virtual laboratory

environment for gear train design. Computer Applications in Engineering Education.

Bailenson, J. N., & Yee, N. (2008). Virtual interpersonal touch: Haptic interaction and

copresence in collaborative virtual environments. Multimedia Tools and Applications,

37(1), 5-14.

Bell, J. T., & Fogler, H. S. (2003). Implementing virtual reality laboratory accidents using the

Half-Life game engine, WorldUp, and Java3D. Paper presented at the Proceedings of

the 2003 ASEE Annual Conference and Exposition.

Benford, S., Greenhalgh, C., Rodden, T., & Pycock, J. (2001). Collaborative virtual

environments. Communications of the ACM, 44(7), 79-85.

Bentley, R., Hughes, J. A., Randall, D., Rodden, T., Sawyer, P., Shapiro, D., & Sommerville, I.

(1992). Ethnographically-informed systems design for air traffic control. Paper

presented at the Proceedings of the 1992 ACM conference on Computer-supported

cooperative work.

Bulas-Cruz, J., Morgado, L., Barbosa, L., Reis, A., Barroso, J., Melo-Pinto, P., & Henriques, P.

(1998). The specification of geometrical dynamic behavior in Web page design. Recent

Advances in Information Science and Technology, 129-135.

Bulas-Cruz, J., Morgado, L., Melo-Pinto, P., Abreu, M., Lobo, H., Guedes, M., Santos, A., Borges,

J., Bicho, J., & Barroso, J. (1999). Beyond traditional Web page designs-a

communication language between designers and web page developers. In New

Techniques for Old times - CAA 98 - Computer Applications and Quantitative Methods

in Archaeology - Proceedings of the 26th Conference, Barcelona, 367-368.

Correia, A., Cassola, F., Azevedo, D., Pinheiro, A., Morgado, L., Martins, P., Fonseca, B., &

Paredes, H. (2012). An Exploratory Research Agenda for 3-D Virtual Worlds as

Collaborative Learning Ecosystems: Extracting Evidences from Literature.

SLACTIONS2012, 8.

74

Creutzfeldt, J., Hedman, L., Medin, C., Heinrichs, W. L., & Felländer-Tsai, L. (2010). Exploring

virtual worlds for scenario-based repeated team training of cardiopulmonary

resuscitation in medical students. Journal of medical Internet research, 12(3).

Davis, A., Murphy, J., Owens, D., Khazanchi, D., & Zigurs, I. (2009). Avatars, people, and virtual

worlds: Foundations for research in metaverses. Journal of the Association for

Information Systems, 10(2), 90-117.

DHS Student. (2007). Safety of chemical plants, imports, transportation part of CREATE

mission, DHS Student Alumni Network. Retrieved from

http://www.dydan.rutgers.edu/Files/DHSJuly2007networknewsletter.pdf

Ellis, C. A., Gibbs, S. J., & Rein, G. (1991). Groupware: some issues and experiences.

Communications of the ACM, 34(1), 39-58.

Fernandes, P. (2012). Implementação de um Sistema de Formação para Mecânicos da Força

Aérea Portuguesa. (Mestrado), Universidade de Trás-os-Montes e Alto Douro, Vila

Real.

Fong, G. (2004). Adapting COTS games for military simulation. Paper presented at the

Proceedings of the 2004 ACM SIGGRAPH international conference on Virtual Reality

continuum and its applications in industry.

Fonseca, B., Paredes, H., Rafael, L. J., Morgado, L., & Martins, P. (2011). A software

architecture for collaborative training in virtual worlds: F-16 airplane engine

maintenance Collaboration and Technology (pp. 102-109): Springer.

Grimstead, I. J., Walker, D. W., & Avis, N. J. (2005). Collaborative visualization: A review and

taxonomy. Paper presented at the Distributed Simulation and Real-Time Applications,

2005. DS-RT 2005 Proceedings. Ninth IEEE International Symposium on.

Grudin, J., & Poltrock, S. (2012). Taxonomy and theory in computer supported cooperative

work. The Oxford Handbook of Industrial and Organizational Psychology. Oxford

University Press, New York.

Hämäläinen, R., Manninen, T., Järvelä, S., & Häkkinen, P. (2006). Learning to collaborate:

Designing collaboration in a 3-D game environment. The Internet and Higher

Education, 9(1), 47-61.

Hevner, A. R. (2007). The three cycle view of design science research. Scandinavian journal of

information systems, 19(2), 87.

Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design science in information systems

research. MIS quarterly, 28(1), 75-105.

75

Hew, K. F., & Cheung, W. S. (2010). Use of three‐dimensional (3‐D) immersive virtual worlds in

K‐12 and higher education settings: A review of the research. British Journal of

Educational Technology, 41(1), 33-55.

Hewet, T., Baecker, R., Card, S., Carey, T., Gasen, J., Mantei, M., Perlman, G., Strong, G., &

Verplank, W. (1992). ACM SIGCHI curricula for human-computer interaction (pp. 162):

ACM.

IEEE Std. (2010). IEEE Standard for Modeling and Simulation (M&S) High Level

Architecture (HLA)-- Framework and Rules. IEEE Std 1516-2010 (Revision of IEEE Std

1516-2000), 1-38. doi: 10.1109/IEEESTD.2010.5553440

Jacobson, J., & Lewis, M. (2005). Game engine virtual reality with CaveUT. Computer, 38(4), 79-

82.

Jarmon, L., & Sanchez, J. (2009). The educators coop experience in Second Life: A model for

collaboration. Journal of the Research Center for Educational Technology, 4(2), 66-82.

Jarmon, L., Traphagan, T., Mayrath, M., & Trivedi, A. (2009). Virtual world teaching,

experiential learning, and assessment: An interdisciplinary communication course in

Second Life. Computers & Education, 53(1), 169-182.

Kitchenham, B., Pearl Brereton, O., Budgen, D., Turner, M., Bailey, J., & Linkman, S. (2009).

Systematic literature reviews in software engineering–a systematic literature review.

Information and software technology, 51(1), 7-15.

Lopes, A., Pires, B., Cardoso, M., Santos, A., Peixinho, F., Sequeira, P., & Morgado, L. (2008).

Sistema de criação de movimentos de Andebol em Second Life para Formação de

Treinadores. Prisma. com, 6, 33-49.

Lopes, A., Pires, B., Cardoso, M., Santos, A., Peixinho, F., Sequeira, P., & Morgado, L. (2009a).

System for Defining and Reproducing Handball Strategies in Second Life On-Demand

for Handball Coaches’ Education. Paper presented at the World Conference on

Educational Multimedia, Hypermedia and Telecommunications.

Lopes, A., Pires, B., Cardoso, M., Santos, A., Peixinho, F., Sequeira, P., Morgado, L., Paredes, H.,

& Foguet, O. (2009b). Use of a virtual world system in sports coach education for

reproducing team handball movements. Journal of Virtual Worlds Research, 2(1).

Manojlovich, J., Prasithsangaree, P., Hughes, S., Chen, J., & Lewis, M. (2003). Utsaf: a multi-

agent-based framework for supporting military-based distributed interactive

simulations in 3d virtual environments. Paper presented at the Simulation Conference,

2003. Proceedings of the 2003 Winter.

Morgado, L. (2009). Os mundos virtuais e o ensino-aprendizagem de procedimentos. Educação

& Cultura Contemporânea, 13 (6), 35-48.

76

Morgado, L. (2012). Características e desafios tecnológicos dos mundos virtuais no ensino.

Sumário pormenorizado do seminário apresentado no âmbito de provas de agregação.

Universidade de Trás-os-Montes e Alto Douro. Vila Real.

Neves, P., Morgado, L., & Zagalo, N. (2010a). For a Normative-Expressive Baseline Model in

Videogame Design. In Proceedings do SBGames 2010 - IX SBGames - Florianópolis, 60-

67.

Neves, P., Zagalo, N., & Morgado, L. (2010b). Expressive Productivity in Videogames: Benefits

from Applied Research in Normative Studies. Actas da 3ª Conferência de Ciências e

Artes dos Videojogos, 99-108.

OpenSimulator. (2012a). Open Wonderland Home. Retrieved 10/08/2012, from

http://opensimulator.org/wiki/Main_Page

OpenSimulator. (2012b). Sobre o OpenSimulator. Retrieved 10708/2012, from

http://opensimulator.org/wiki/PT

Phillips, J., & Berge, Z. L. (2009). Second life for dental education. Journal of dental education,

73(11), 1260-1264.

Pierzchała, D., Dyk, M., & Szydłowski, A. (2011). Distributed military simulation augmented by

computational collective intelligence Computational Collective Intelligence.

Technologies and Applications (pp. 399-408): Springer.

Pinheiro, A., Fernandes, P., Maia, A., Cruz, G., Pedrosa, D., Fonseca, B., Paredes, H., Martins, P.,

Morgado, L., & Rafael, J. (2012). Development of a mechanical maintenance training

simulator in OpenSimulator for F-16 aircraft engines. Procedia Computer Science, 15,

248-255.

Pinto, I., & Teixeira, L. (2010a). Guia de instalação de motor em aeronave F16. documento

técnico da disciplina Projecto da Licenciatura em Tecnologias de Informação e

Comunicação. Universidade de Trás-os-Montes e Alto Douro. Vila Real.

Pinto, I., & Teixeira, L. (2010b). Projecto de preparação de motores para instalação em

aeronaves F16 - Desenvolvido para a Força Aérea Portuguesa - Requisitos funcionais.

documento técnico da disciplina Projecto da Licenciatura em Tecnologias de

Informação e Comunicação. Universidade de Trás-os-Montes e Alto Douro. Vila Real.

Rajaei, H., & Aldhalaan, A. (2011). Advances in virtual learning environments and classrooms.

Paper presented at the Proceedings of the 14th Communications and Networking

Symposium.

Schmidt, K., & Simonee, C. (1996). Coordination mechanisms: Towards a conceptual

foundation of CSCW systems design. Computer Supported Cooperative Work (CSCW),

5(2-3), 155-200.

77

Schneider, F. B. (1990). Implementing fault-tolerant services using the state machine approach:

A tutorial. ACM Computing Surveys (CSUR), 22(4), 299-319.

Stapić, Z., López, E. G., Cabot, A. G., de Marcos Ortega, L., & Strahonja, V. (2012). Performing

Systematic Literature Review in Software Engineering.

Vilela, A. (2012). Aplicação de agentes inteligentes capazes de desempenhar o papel de

membros na execução de trabalhos em equipa, em ambiente virtual 3D

OpenSimulator. (Mestrado), Universidade de Trás-os-Montes e Alto Douro, Vila Real.

Vilela, A., Marques, A., Costa, H., Rafael, J., Prada, R. F. F., & Morgado, L. (2012). Aplicação de

avatares autónomos para desempenhar o papel de membros na execução de

trabalhos em equipa.

Wang, J., Lewis, M., & Gennari, J. (2003). A game engine based simulation of the NIST urban

search and rescue arenas. Paper presented at the Simulation Conference, 2003.

Proceedings of the 2003 Winter.

Wiecha, J., Heyden, R., Sternthal, E., & Merialdi, M. (2010). Learning in a virtual world:

experience with using second life for medical education. Journal of medical Internet

research, 12(1).

Xiao, Y. (2005). Artifacts and collaborative work in healthcare: methodological, theoretical, and

technological implications of the tangible. Journal of biomedical informatics, 38(1), 26-

33.

79

ANEXOS

80

.

Anexo 1

Testes de Utilização

____________________________________________________

O teste de utilização que se irá realizar, enquadra-se no âmbito do protocolo

entre a Universidade de Trás-os-Montes e Alto Douro e a Força Aérea Portuguesa, com

vista ao desenvolvimento de um simulador 3D para o treino de mecânicos na

instalação de motores em aeronaves F-16.

Este teste tem como objetivo avaliar a utilização do sistema de edição de

componentes e estados desenvolvido, com vista à aferição de dificuldades, limitações

e (des)vantagens do mesmo para incrementação de melhorias.

O teste será aplicado a voluntários que se ofereceram para efetuar a realização

do mesmo.

A recolha de dados será feita com recurso a diferentes técnicas e instrumentos

de recolha, nomeadamente observação e questionário.

A confidencialidade dos dados é garantida. Pede-se autorização para a captura,

análise e utilização dos mesmos no âmbito do protocolo suprarreferido, com vista aos

objetivos enunciados.

81

Termo de Consentimento

_____________________________________________________________________

Afirmo que participarei por minha própria vontade nos testes de utilização e

que fui informado(a) dos objetivos dos mesmos.

Fui igualmente informado(a) dos métodos de recolha de dados utilizados para o

efeito.

Fui ainda informado(a) que fica salvaguardada e assegurada a confidencialidade

das informações concedidas e recolhidas, restringindo-se a sua utilização ao trabalho

no âmbito do protocolo estabelecido entre a Universidade de Trás-os-Montes e Alto

Douro e a Força Aérea Portuguesa, nomeadamente em eventuais futuros trabalhos de

produção científica, que a ocorrerem terão sempre lugar sem divulgação das fontes.

Vila Real, 21 de Outubro de 2013, O utilizador:

_______________________________

Investigador

André Pinheiro

Mestrado em Engenharia Informática (UTAD)

82

Anexo 2

Questionário de caracterização do perfil

O presente questionário visa aferir o perfil dos utilizadores que integram o teste de

utilização ao sistema de edição de componentes e estados para o simulador de manutenção

mecânica de motores de F-16, construído ao abrigo do protocolo estabelecido entre a

Universidade de Trás-os-Montes e Alto Douro e a Força Aérea Portuguesa.

Pretende-se aferir o conhecimento dos utilizadores em mundos virtuais e experiências

prévias neste tipo de ambientes.

Pede-se que o utilizador leia atentamente cada questão, escolhendo a opção que

melhor se adequa à sua resposta através de uma cruz (X).

Agradecemos a sua colaboração.

_____________________________________________________________________

Parte I - Utilização do computador

1. Usa computador?

Sim Não

NOTA: Para esta questão poderá apenas responder a uma alternativa. Se respondeu “Não”

acima, siga para a Parte II do questionário.

2. Com que frequência usa computador?

Diariamente (1 vez por dia)

Diariamente (várias vezes por dia)

Semanalmente ( de 1 a 6 vezes por semana)

NOTA: Para esta questão poderá apenas responder a uma alternativa

83

3. Utiliza o computador com a finalidade de:

Socialização

Pesquisa de informação

Partilha de informação

Formação

Trabalho

Entretenimento

Outra:

______________________________________________________________

NOTA: Para esta questão poderá responder a mais do que uma alternativa.

Parte II - Utilização de mundos virtuais 3D

4. Conhece algum mundo virtual 3D?

Sim Não


acima siga para a Parte III do questionário.

4.1 Qual(quais) o(s) mundo(s) virtual(ais) 3D que conhece?

Opensimulator

Second Life

Active Worlds

Cyberworlds

Coke Studios

Dreamville

Outro:

__________________________________________________________


84

4.2 Já utilizou algum mundo virtual 3D?

Sim Não


acima siga para a Parte III do questionário.

4.3. Qual(quais) o(s) mundo(s) virtual(ais) 3D que utilizou:

Opensimulator

Second Life

Active Worlds

Cyberworlds

Coke Studios

Dreamville

Outro:

________________________________________________________


4.4. Para que finalidade utilizou esse(s) mundo(s) virtual(ais):

Socialização

Pesquisa de informação

Partilha de informação

Formação

Trabalho

Entretenimento

Outra:

_____________________________________________________________________


5. Já obteve algum tipo de formação para a utilização de mundos virtuais 3D?

Sim Não

NOTA: Se respondeu “Não” acima siga para a Parte III do questionário.

85

5.1 Para qual(ais) mundo(s) virtual(ais) 3D obteve essa formação?

Opensimulator

Second Life

Active Worlds

Cyberworlds

Coke Studios

Dreamville

Outro:

__________________________________________________________


5.2. Como classifica a sua capacidade de utilização de mundos virtuais 3D?

Muito Má Medíocre Boa Muito Boa

NOTA: Para esta questão poderá apenas responder a uma alternativa.

6. Já obteve algum tipo de formação para a programação em mundos virtuais 3D?

Sim Não

NOTA: Se respondeu “Não” acima siga para a Parte III do questionário.

6.1 Para qual(ais) mundo(s) virtual(ais) 3D obteve essa formação?

Opensimulator

Second Life

Active Worlds

Cyberworlds

Coke Studios

Dreamville

Outro:

__________________________________________________________


86

6.2. Como classifica a sua capacidade de programação em mundos virtuais 3D?

Muito Boa Boa Medíocre Muito Má

NOTA: Para esta questão poderá apenas responder a uma alternativa.

Parte III - Dados demográficos

7. Sexo:

Feminino Masculino

8. Idade:

________ anos

Obrigada pela participação!

87

Anexo 3

Questionário Satisfação

Tento em conta o teste que realizou no sistema de edição de componentes e estados

para o simulador de manutenção mecânica de motores de F-16, responda às seguintes

questões relativamente à sua experiência de utilização do software:

Pede-se que o utilizador leia atentamente cada questão, escolhendo a opção que

melhor se adequa à sua resposta através de uma cruz (X).

Agradecemos a sua colaboração.

_____________________________________________________________________

1. Como classifica o sistema quanto à facilidade de utilização?

Muito Difícil Difícil Fácil Muito Fácil

2. Como classifica o sistema em relação à sua intuitividade?

Muito Intuitivo Intuitivo Pouco Intuitivo Nada Intuitivo

3. Como classifica o sistema em termos de facilidade de aprendizagem?

Muito Fácil Fácil Difícil Muito Difícil

4. Acha que este sistema facilita a criação de conteúdo nos mundos virtuais 3D?

Não Facilita Facilita Pouco Facilita Facilita Muito

88

5. Acha este sistema acessível a qualquer pessoa que use frequentemente computadores?

Muito Acessível Acessível Pouco Acessível Nada Acessível

6. O que acha do potencial deste sistema na criação de simulações?

Nenhum Pouco Algum Muito

7. Sentiu alguma dificuldade?

Sim Não

7.1. Se sim, foi relativo ao:

Mundo Virtual

Sistema em si

Ambas

8. Que melhorias poderiam ser adicionadas no sistema?

_____________________________________________________________________________

_____________________________________________________________________________

_____________________________________________________________________________

_____________________________________________________________________________

________________________________

Obrigada pela participação!

Documents

Sistema de edição de componentes e estados para simulador de manutenção mecânica de motores de F-16