Upload
leonel-morgado
View
560
Download
1
Embed Size (px)
DESCRIPTION
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.
Citation preview
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 Tipo Função
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 Tipo Função
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 Tipo Função
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 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 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
NOTA: Para esta questão poderá apenas responder a uma alternativa. Se respondeu “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:
__________________________________________________________
NOTA: Para esta questão poderá responder a mais do que uma alternativa.
84
4.2 Já utilizou algum mundo virtual 3D?
Sim Não
NOTA: Para esta questão poderá apenas responder a uma alternativa. Se respondeu “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:
________________________________________________________
NOTA: Para esta questão poderá responder a mais do que uma alternativa.
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:
_____________________________________________________________________
NOTA: Para esta questão poderá responder a mais do que uma alternativa.
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:
__________________________________________________________
NOTA: Para esta questão poderá responder a mais do que uma alternativa.
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:
__________________________________________________________
NOTA: Para esta questão poderá responder a mais do que uma alternativa.
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!