SISTEMA DE EDIO DE COMPONENTES E ESTADOS

PARA SIMULADOR DE MANUTENO MECNICA DE MOTORES DE F-16

DISSERTAO DE MESTRADO APRESENTADA POR ANDR FILIPE MONTEIRO PINHEIRO

Sob orientao dos Professores Doutores Leonel Caseiro Morgado e Hugo Alexandre Paredes Guedes da Silva

UNIVERSIDADE DE TRS-OS-MONTES E ALTO DOURO

ESCOLA DE CINCIAS E TECNOLOGIA

DEPARTAMENTO DE ENGENHARIAS

2013

Dissertao apresentada por Andr Filipe Monteiro Pinheiro Universidade de Trs-os-Montes e Alto Douro para o cumprimento dos requisitos necessrios obteno do grau de Mestre em Engenharia Informtica, sob a orientao dos Professores Doutores Leonel Caseiro Morgado e Hugo Alexandre Paredes Guedes da Silva.

RESUMO
Apesar de todos os avanos que tm vindo a ser feitos, o desenvolvimento de sistemas de simulao, atualmente, requer ainda um investimento significativo a vrios nveis: recursos humanos, fases de anlise e estudo do sistema a simular, planeamento e implementao final. Desta forma, o sistema final na maioria das vezes bastante rgido, dependente da plataforma e das tecnologias de implementao. A Universidade de Trs-os-Montes e Alto Douro e a Fora Area Portuguesa estabeleceram um protocolo onde acordaram uma colaborao entre as duas instituies no mbito do qual foi desenvolvido, por uma equipa que integrei, um prottipo de simulador multiutilizador de manuteno mecnica dos motores Pratt&Whitney F-100 utilizados nas aeronaves F-16, que permite aos utilizadores participar numa equipa que reproduz as tarefas de instalao de um motor dentro da fuselagem da aeronave. Apesar de este prottipo ter sido concebido sempre com o cuidado de separar a parte lgica da parte visual da simulao, o registo de cada componente, bem como as suas caractersticas e comportamento, tinham de ser implementados sempre por programadores. Esta dissertao permitiu expandir a separao entre a parte lgica e a parte visual, possibilitando a criao de um sistema que permite que o registo de componentes e comportamentos possa ser efetuado sem qualquer interveno de programadores, contribuindo assim, para a evoluo do conhecimento na rea da agilizao entre as fases de conceo e implementao de simuladores, e para a reduo dos custos de produo ou reformulao de simulaes, potenciando a sua aplicao em maior escala e em novos cenrios.

Palavras-chave mquinas de estados hierrquicas, mundos virtuais, ensino virtual, trabalho cooperativo, simulao, user-friendly

iii

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 Trs-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, userfriendly

AGRADECIMENTOS
A realizao da presente dissertao exigiu um grande esforo e dedicao, no entanto, a sua concretizao no seria possvel sem o auxlio 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 impossvel estar aqui. Deram-me a educao e carinho que todas as pessoas deveriam ter, fizeram enormes sacrifcios para que eu conseguisse alcanar tudo o que hoje tenho, sem nunca esquecer os princpios e valores que me incutiram, fazendo de mim a pessoa que sou hoje. A eles, devo-lhes tudo. Universidade de Trs-os-Montes e Alto Douro, pelas excelentes condies de trabalho que proporciona, e por todas as oportunidades de investigao concedidas. Os meus agradecimentos vo tambm para os meus orientadores, Professor Doutor Leonel Morgado e Professor Doutor Hugo Paredes, as suas orientaes, as suas ideias e toda a disponibilidade foram a chave para a realizao de todo este trabalho, ultrapassando todas as dificuldades que iam surgindo. Quero tambm 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 evoluo enquanto investigador. Quero fazer um agradecimento especial ao meu colega e amigo, Csar Meira. Os teus sbios conselhos e ideias foram cruciais para que conseguisse ultrapassar certos obstculos que foram surgindo. Obrigado por todo teu companheirismo, apoio e auxlio nesta etapa. Agradeo tambm aos meus colegas e amigos que estiveram sempre comigo ao longo desta ltima etapa, Filipe Fernandes, Antnio Correia, Jorge Freitas e Jorge Miguel. Obrigado a todos vocs, por todos os momentos de companheirismo, motivao e amizade. Quero tambm agradecer do fundo do corao aos meus amigos, que partilharam comigo grande parte da vida universitria. Antnio Botelho, Alexandra Vasques, Jos Mendona 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, vocs foram sem dvidas os meus pilares de apoio durante esta fase da minha vida. Por ltimo, mas no menos importante, quero agradecer minha irm, por toda a pacincia e apoio, bem como pela tua confiana nas minhas capacidades que foi determinante para eu ter conseguido levar todo este trabalho at ao fim.

vii

NDICE
Resumo......................................................................................................................................... iii Abstract ......................................................................................................................................... v Agradecimentos ............................................................................................................................ v Lista de figuras ..............................................................................................................................xi Lista de tabelas ............................................................................................................................. xii Lista de Grficos .......................................................................................................................... xiii Glossrio, acrnimos e abreviaturas ........................................................................................... xiv Captulo 1: Introduo................................................................................................................... 1 1.1 1.2 1.3 1.4 Enquadramento............................................................................................................. 2 Motivao e contribuies ............................................................................................ 3 Objetivos ....................................................................................................................... 3 Estrutura ........................................................................................................................ 4

Captulo 2: Contextualizao......................................................................................................... 7 2.1 Enquadramento do Projeto........................................................................................... 8 Plataforma Tecnolgica ....................................................................................... 10 Recolha de dados e especificao ....................................................................... 11 Prottipo ............................................................................................................. 16

2.1.1 2.1.2 2.1.3 2.2 2.3

Envolvente Conceptual ............................................................................................... 18 Trabalho Relacionado.................................................................................................. 20 Mtodo ................................................................................................................ 20 Trabalho relacionado .......................................................................................... 21

2.3.1 2.3.2

Captulo 3: Arquitetura-Base Apresentao e Anlise ............................................................. 25 3.1 3.2 3.3 3.4 Apresentao da Arquitetura ...................................................................................... 26 Sistema de Deciso e Controlo.................................................................................... 26 Script LSL como Mdulo View Genrico ..................................................................... 30 Protocolos de Comunicao ........................................................................................ 31

Captulo 4: Nova Arquitetura: Prottipo ..................................................................................... 35 4.1 4.2 4.3 4.4 4.5 Metodologia Adotada ................................................................................................. 36 Identificao do Problema .......................................................................................... 37 Especificao dos Novos Requisitos ............................................................................ 38 Evoluo do Sistema de Deciso e Controlo ............................................................... 38 Evoluo do Protocolo de Comunicao ..................................................................... 42 ix

4.6 4.7 4.8

Evoluo do Script LSL como Mdulo View Genrico ................................................. 44 Estrutura dos Dados .................................................................................................... 44 Interface Grfica .......................................................................................................... 47

Captulo 5: Testes com utilizadores ............................................................................................ 53 5.1 5.2 5.3 Ambiente de Testes..................................................................................................... 54 Caracterizao da amostra .......................................................................................... 55 Anlise de Resultados ................................................................................................. 61

Captulo 6: Concluses e trabalho futuro ................................................................................... 69 6.1 6.2 Concluso .................................................................................................................... 70 Reflexes Finais ........................................................................................................... 70

Referncias bibliogrficas ........................................................................................................... 73 Anexos ......................................................................................................................................... 79

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 mos direita e esquerda .............................. 17 Figura 11 - HUD em forma de setas para descer ou subir apoios ............................................... 18 Figura 12 Sistema de interao genrico (Fonseca et al., 2011) .............................................. 27 Figura 13 - Sistema de Deciso 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 bsico do Sistema de Deciso e Controlo .............. 41 Figura 20 - DTD do ficheiro de configurao dos objetos ........................................................... 45 Figura 21 - rvore de componentes do ficheiro de configurao dos objetos ........................... 45 Figura 22 - rvore de componentes do ficheiro de configurao da simulao ........................ 46 Figura 23 - DTD do ficheiro de configurao da simulao......................................................... 46 Figura 24 - Janela inicial e menu da simulao (Editor do sistema) ............................................ 47 Figura 25 - Janela de configurao dos objetos (Lista de objetos) ............................................. 47 Figura 26 Janela de configurao dos objetos (Registar novo objeto) .................................... 48 Figura 27 - Janela de configurao dos estados (lista de estados) ............................................. 49 Figura 28 - Janela de configurao dos estados (adicionar aes) ............................................. 49 Figura 29 - Janela de configurao dos estados (adicionar restries)....................................... 50 Figura 30 - Janela de configurao dos estados (adicionar tarefas) ........................................... 50

xi

LISTA DE TABELAS
Tabela 1 - Protocolo de comunicao: Sistema de Deciso Controlo Ambiente 3D................ 32 Tabela 2 - Protocolo de comunicao: Ambiente 3D Sistema de Deciso e Controlo (Objeto Criado) ......................................................................................................................................... 32 Tabela 3 - Protocolo de comunicao: Ambiente 3D Sistema de Deciso e Controlo ............. 33 Tabela 4 - Protocolo de comunicao: Ambiente 3D Ambiente 3D......................................... 33 Tabela 5 - Novo Protocolo de comunicao: Sistema de Deciso Controlo Ambiente 3D ...... 43 Tabela 6 - Exemplo de comunicao do tipo: Sistema de Deciso Controlo Ambiente 3D ..... 43

xii

LISTA DE GRFICOS
Grfico 1 - Classificao dos utilizadores quanto idade ........................................................... 55 Grfico 2 - Classificao dos utilizadores quanto frequncia com que usa o computador ..... 56 Grfico 3 - Classificao dos utilizadores quanto finalidade com que usam o computador.... 56 Grfico 4 - Classificao dos utilizadores quanto aos mundos virtuais que conhecem .............. 57 Grfico 5 - Classificao dos utilizadores quando utilizao de mundos virtuais .................... 57 Grfico 6 - Classificao dos utilizadores quanto aos mundos virtuais que utilizou .................. 58 Grfico 7 - Classificao dos utilizadores quanto finalizao com que usaram mundos virtuais ..................................................................................................................................................... 58 Grfico 8 - Classificao dos utilizadores quanto obteno de formao para utilizar mundos virtuais ......................................................................................................................................... 59 Grfico 9 - Classificao dos utilizadores quanto ao mundo virtual para o qual obtiveram formao ..................................................................................................................................... 59 Grfico 10 - Classificao dos utilizadores quanto capacidade de utilizao de mundos virtuais ..................................................................................................................................................... 60 Grfico 11 - Classificao dos utilizadores quanto obteno de formao para programar em mundos virtuais ........................................................................................................................... 60 Grfico 12 - Classificao dos utilizadores quanto capacidade de programao em mundos virtuais ......................................................................................................................................... 61 Grfico 13 - Anlise dos tempos de execuo das tarefas .......................................................... 62 Grfico 14 - Anlise das dvidas que surfiram na execuo das tarefas .................................... 63 Grfico 15 - Analise dos erros praticados na execuo das tarefas ............................................ 63 Grfico 16 - Classificao do sistema quanto facilidade de utilizao ..................................... 64 Grfico 17 - Classificao do sistema quanto intuitividade...................................................... 64 Grfico 18 - Classificao do sistema quanto facilidade de aprendizagem ............................. 65 Grfico 19 - Classificao do sistema quando facilidade de criao de contedo ................... 65 Grfico 20 - Classificao do sistema quanto a ser acessvel a qualquer pessoa que use computador ................................................................................................................................. 66 Grfico 21 - Classificao do sistema quanto ao potencial na criao de simulaes................ 66 Grfico 22 - Anlise das dificuldades sentidas ............................................................................ 67 Grfico 23 - Classificao do tipo de dificuldades ....................................................................... 67

xiii

GLOSSRIO, ACRNIMOS E ABREVIATURAS

BA5 Base Area n. 5 CFMTFA Centro de Formao Militar e Tcnica da Fora Area COTS Commercial Off The Shelf CVE Collaborative Virtual Environments DTD - Document Type Definition FAP Fora Area 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 Trs-os-Montes e Alto Douro XML Extensible Markup Language

xiv

CAPTULO 1: INTRODUO

Any sufficiently advanced technology is indistinguishable from magic. Arthur C. Clarke

Neste captulo introdutrio feito um enquadramento lgico do problema, bem como das contribuies e motivaes que me levaram escolha deste tema em concreto. So tambm definidos os objetivos gerais que se tencionam alcanar, assim como a estrutura desta dissertao, expondo resumidamente os aspetos que so abordados em cada um dos prximos captulos. 1

1.1

ENQUADRAMENTO

Atualmente, o desenvolvimento de sistemas de simulao requer investimento significativo em termos de recursos humanos, quer nas fases de anlise e estudo do sistema a simular, quer no planeamento, quer na implementao final. O sistema final , normalmente, rgido, dependente da plataforma e das tecnologias de implementao. No mbito da investigao em curso na Universidade de Trs-os-Montes e Alto Douro (UTAD), tm-se vindo a desenvolver abordagens de separao entre a implementao da lgica das simulaes e a concretizao das mesmas em plataformas como os mundos virtuais. A presente dissertao insere-se no trabalho em curso de colaborao entre a UTAD e a Fora Area Portuguesa (FAP), j alvo de publicao anterior por parte da equipa de orientao (Fonseca et al., 2011). Nesse contexto, existe um prottipo de simulador multiutilizador de manuteno mecnica dos motores Pratt&Whitney F-100 utilizados nas aeronaves F-16, que permite reproduzir as tarefas de instalao de um motor dentro da fuselagem da aeronave e sobre o qual j foram realizados testes de campo tendo sido j tambm alvo de publicao anterior (Pinheiro et al., 2012). Contudo, cada componente visual dessa simulao tem de ser concebido individualmente tarefa de design e modelao grfica e depois importado e adaptado por programadores. As caractersticas comportamentais dos componentes visuais no so necessariamente analisadas e estudadas por especialistas de desenvolvimento, mas preferencialmente por especialistas em manuteno mecnica ou formao. Contudo, no sistema de partida so tambm implementadas, obrigatoriamente, pelos programadores. Existem trabalhos prvios, em diversas reas, de agilizao do processo de colaborao entre projetistas/designers e implementadores. Refiram-se, por exemplo, trabalhos a nvel do desenvolvimento de pginas Web (Bulas-Cruz et al., 1998; Bulas-Cruz et al., 1999) ou mesmo a nvel da conceo e desenvolvimento de videojogos (Neves et al., 2010a; Neves et al., 2010b). No que concerne a simulaes baseadas em mundos virtuais, torna-se premente salientar abordagens a nvel de coordenao de movimentos (Lopes et al., 2008; Lopes et al., 2009a; Lopes et al., 2009b), bem como no domnio da sade com o treino de estudantes de medicina em situaes de reanimao cardiopulmonar (Creutzfeldt et al., 2010), medicina dentria (Phillips & Berge, 2009), e educao mdica (Wiecha et al., 2010). Este tipo de tecnologia pode fomentar o ensino distncia de prticas complexas de colaborao e possibilitar o uso de um conjunto de recursos para a comunicao em tempo real. No contexto militar, a preparao para atividades de combate exige treino ttico e operacional, aspetos onde o uso de simulaes assume um papel crucial para o sucesso de operaes. J na 2

vertente logstica e de suporte o uso menos generalizado, tendo o presente trabalho potencial significativo para o desenvolvimento da rea (Fonseca et al., 2011). A nvel das suas exigncias tcnicas, a utilizao atual de simuladores para atividades de combate cria um quadro de tecnologias de base e requisitos gerais para as organizaes militares, nomeadamente a nvel das tecnologias de comunicao e coordenao entre simuladores atravs 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

MOTIVAO E CONTRIBUIES

A nvel estritamente pessoal, esta uma rea que alm da sua utilidade me desperta uma grande motivao pessoal pelo facto de nos ltimos dois anos ter estado ligado aos trabalhos desenvolvidos nesta rea pela equipa de investigao da UTAD associada a desenvolvimento em mundos virtuais, rea essa em que antes do meu envolvimento neste projeto, em 2010, no tinha qualquer conhecimento ou preparao. Outra grande motivao foi o facto de este projeto ser em parceria com a FAP, uma instituio com enormes responsabilidades no pas e onde a margem para erros zero. Foi este ambiente desafiante que me deu ainda mais energia e motivao para avanar at ao estado atual do trabalho. Trabalhar com a FAP seria e foi algo que fiz com enorme orgulho. Alm de que a dissertao contribuir para a evoluo do conhecimento na rea da agilizao entre as fases de conceo e implementao de simuladores, alm de ter o potencial, para contribuir para a reduo dos custos de produo ou reformulao de simulaes, potenciando a sua aplicao em maior escala e em novos cenrios.

1.3

OBJETIVOS

Esta dissertao tem como objetivo primordial satisfazer a necessidade sentida pela FAP aquando da apresentao do prottipo supramencionado, de o mecnico formador poder durante uma simulao alterar comportamentos de componentes em tempo real de forma a analisar a reao dos formandos. De uma forma generalizada o objetivo desta dissertao passa por expandir a separao entre lgica e a plataforma, possibilitando que o registo de componentes e comportamentos possa ser efetuado sem interveno dos programadores, contribuindo assim para agilizar e flexibilizar o processo de desenvolvimento de simulaes e alterao das mesmas para adequao a novos requisitos.

Face ao conhecimento exaustivo que detinha acerca do estado de desenvolvimento do prottipo supramencionado, em virtude de ter feito desde sempre parte das equipas que efetuaram a sua conceo e desenvolvimento, tinha plena conscincia de que, para cumprir o objetivo acima referido, seria necessrio realizar uma anlise profunda a todo o sistema e com base nela, no apenas reformular o sistema j existente, mas sim agarrar no seu conceito terico de modo a idealizar e desenvolver de raiz um novo sistema mais robusto e flexvel. 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 dissertao foram: Enquadrar de forma mais aprofundada o tema no estado da arte da rea, de modo a sustentar e demonstrar de que forma esta dissertao contribui para o avano na resoluo de alguns problemas atuais; Realizar uma anlise pormenorizada a todo o sistema de forma a identificar limitaes e problemas. Formalizar novos requisitos do sistema em face do objetivo geral, de modo a colmatar as limitaes e os problemas encontrados; Conceber um modelo terico que permita concretizar um sistema face aos novos requisitos especificados; Implementar um prottipo que permita testar o modelo concebido; Analisar os resultados obtidos e perspetivar possveis linhas de trabalho futuro.

1.4

ESTRUTURA

A presente dissertao divide-se em seis captulos independentes estando no entanto ligados entre si, de uma forma coerente e sequencial. tambm de salientar que a mesma expe todo o trabalho prvio que serviu de base a este trabalho e no qual estive envolvido em todo o seu processo, sendo assim crucial a sua descrio. Assim, aps o presente captulo, a dissertao est organizada da seguinte forma: o Captulo 2 Contextualizao Apresentao do enquadramento do projeto no qual esta dissertao se insere e do estado em que o trabalho se encontrava aquando a iniciao da mesma.

Exposio de alguns conceitos genricos e trabalhos relacionados nesta rea, atravs da anlise de literatura. o Captulo 3 Arquitetura-Base Apresentao e Anlise Descrio e anlise da arquitetura que serviu de suporte a esta dissertao, evidenciando e detalhando os aspetos essenciais, de todos os componentes que fazem parte desta arquitetura. o Captulo 4 Nova Arquitetura: Prottipo Apresentao da metodologia de desenvolvimento escolhida para conceber um sistema que consiga cumprir os novos requisitos identificados com base nos resultados da anlise realizada anteriormente, e que permita test-lo e valid-lo com utilizadores. Descrio de toda a evoluo dos diferentes componentes do sistema, apresentao da estrutura de dados dos ficheiros de configurao do sistema e da interface grfica atualmente usada para a criao dos mesmos. o Captulo 5 Testes com utilizadores Exposio dos testes realizados e do que se pretendia auferir com estes, numa segunda parte so apresentados os resultados dos mesmos e destacadas as evidncias que se conseguiram extrair. o Captulo 6 Concluses e trabalho futuro Verificao do cumprimento dos objetivos propostos para esta dissertao e se esta trouxe ou no as contribuies esperadas, perspetivando caminhos de investigao futura com base nas limitaes e necessidades encontradas ao longo da investigao.

CAPTULO 2: CONTEXTUALIZAO

It's still magic even if you know how it's done. Terry Pratchett

Neste captulo apresentado todo o enquadramento do projeto onde esta dissertao se insere, bem como o estado em que o simulador se encontrava antes do trabalho de suporte dissertao. So referidas algumas definies presentes na literatura para explicar alguns conceitos genricos. Com base na anlise da literatura da ltima dcada so tambm apresentados trabalhos relacionados nesta rea. 7

2.1

ENQUADRAMENTO DO PROJETO

A Fora Area Portuguesa opera com aeronaves F-16, sendo a Base Area n. 5 (BA5), na Serra do Porto de Urso (Monte Real, Leiria), a especializada nestas aeronaves. Sendo tambm a nica no pas onde estas aeronaves esto situadas e onde efetuada toda a sua manuteno. As aeronaves F-16 da FAP esto equipadas com motores Pratt&Whitney F100-PW220E, sendo recomendado pelo fabricante a realizao de inspees peridicas, consoante o nmero de hora de voo. na BA5 que a generalidade desse trabalho executada. Antes e depois dos voos h sempre inspees, mas a chamada manuteno programada de um F-16 realizada de 300 em 300 horas de voo. Esta manuteno executada por mecnicos especializados da FAP, nos hangares da BA5 (Figura 1). Estes mecnicos tiveram que passar por todo um processo de formao. Esse processo iniciado logo aps a seleo da especialidade militar: numa primeira fase a formao realiza-se na base militar da Ota, no Centro de Formao Militar e Tcnica da Fora Area (CFMTFA); numa segunda fase, a formao realizase nas bases areas existentes em Portugal onde os mecnicos venham a ser colocados, tendo em conta a especialidade de cada uma (Vilela et al., 2012).

FIGURA 1 - HANGAR NA BA5

Os militares destacados para a seco de operaes da linha da frente, e para a manuteno dos motores que equipam as aeronaves F-16, os j mencionados Pratt&Whitney F100 (Figura 2), recebem inicialmente uma formao mais simples sobre as componentes gerais das aeronaves F-16. S posteriormente iniciam um curso de formao mais intensivo, 8

denominado Curso de Motor F100-PW-220E Nvel O. Esta formao constituda atualmente por duas partes: uma parte terica, onde so estudados todos os processos

FIGURA 2 - MOTOR PRATT&WHITNEY F100

descritos nos documentos tcnicos fornecidos pelo fabricante destes motores (designados Technical Orders ou TO), e por uma parte prtica, j mesmo no terreno, que requer o uso fsico de materiais, motores e aeronaves. Este uso fsico, alm do desgaste de materiais que provoca, faz com que esses materiais, motores e mesmo aeronaves fiquem indisponveis para qualquer tipo de misses ou emergncias durante todo o tempo da formao, atribuindo a estes momentos de formao um custo elevado. Alm de um momento de formao sobre o processo de instalao do motor na aeronave necessitar de bastante tempo (cerca de 6 horas), existe ainda como custo associado o envolvimento de formadores (mecnicos especializados), cuja disponibilidade poderia ser de valor acrescentado noutros servios. A manuteno mecnica de aeronaves F-16 algo extremamente complexo, rigoroso, delicado e exaustivo, que requer uma formao (acompanhada de treino) com preciso e rigor; alm de na maioria dos processos (como o processo j tido anteriormente como exemplo - instalao do motor na aeronave) existirem vrias tarefas colaborativas, exigindo uma equipa de pelo menos trs mecnicos. Especificamente, h tarefas que, embora individuais, requerem a validao por outra pessoa, com a preparao adequada; e outras que so impossveis de concretizar em segurana e com rigor sem a colaborao de mais do que um elemento. Para que a formao destes mecnicos possa tambm ser realizada em equipa, de forma colaborativa, necessrio encontrar disponibilidades comuns de horrio e alguma homogeneidade de preparao prvia, por parte dos mecnicos. Estes constrangimentos limitam as oportunidades para treino em equipa.

Durante uma reunio realizada h trs anos e meio entre os militares da BA5, responsveis pela formao, e os membros da equipa de investigao da UTAD (entre os quais eu), onde se procurava inquirir oportunidades de cooperao entre as entidades, tornou-se percetvel a existncia destes diversos constrangimentos e a sua importncia. Surgiu desta situao a proposta de desenvolver um sistema de simulao 3D, que fosse capaz de simular as tarefas de manuteno mecnica dos motores das aeronaves F-16, permitindo aos formandos treinar as etapas e os procedimentos dessas tarefas e tambm exercitar os aspetos de coordenao e colaborao em trabalho de equipa. O objetivo de realizar isto num ambiente simulado seria poderem praticar vrias vezes, a qualquer hora do dia, no 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 terica da formao e a parte prtica no terreno. Permitir-se-ia, desta forma, que os formandos fossem para o terreno j mais preparados. Por exemplo, j com uma noo mais precisa da aparncia de cada pea, do seu tamanho relativo, etc. Para dar suporte a esta colaborao, a UTAD e a FAP tinham estabelecido previamente um protocolo de cooperao com vista a suportar esforos conjuntos de investigao tecnolgica e desenvolvimento, ao abrigo do qual se desenvolvera essa reunio e decorreram as tarefas subsequentes de desenvolvimento, descritas nas seces seguintes desta dissertao. No existe, nem existiu financiamento especfico associado a este protocolo. As atividades desenrolaram-se no contexto de unidades curriculares de projeto ou de dissertao, fundamentalmente semestrais.

2.1.1 PLATAFORMA TECNOLGICA

Na sequncia do relatado na seco anterior, analisaram-se as plataformas existentes, propcias 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 milhes de utilizadores (World of Warcraft, Second Life, entre outros), permitem que o desenvolvimento desde tipo de sistemas seja efetuado excluindo a complexidade da gesto de comunicaes, sincronizao de estado em rede entre utilizadores e outros aspetos similares. Os games engines tambm permitem este desenvolvimento, inclusive com maior liberdade, mas obrigam o programador a gerir os aspetos de baixo nvel suprarreferidos, tornando assim mais complexo o desenvolvimento de prottipos. Estas plataformas permitem interligar utilizadores, mesmo que separados

10

fisicamente, possibilitando a comunicao entre eles, bem como a execuo de aes de forma colaborativa. Tendo em considerao que a curva de aprendizagem do desenvolvimento em mundos virtuais possivelmente mais rpida, devido complexidade dos aspetos de baixo nvel, e ao facto das atividades se desenrolarem em unidades curriculares fundamentalmente semestrais, o que originou a alterao regular dos elementos da equipa de desenvolvimento, optou-se poca pelos mundos virtuais como plataforma de desenvolvimento. Dentro dos mundos virtuais, devido a algumas condies impostas pela FAP, nomeadamente ao nvel de segurana (por exemplo, o simulador ficar dentro da sua prpria rede), e no existncia de financiamento, o mundo virtual escolhido para o desenvolvimento foi um autnomo, criado com a plataforma OpenSimulator (OpenSimulator, 2012a). O Opensimulator surgiu como plataforma alternativa a um dos mundos virtuais mais conhecidos, o Second Life (SL). Comeou por ser desenvolvido por retroengenharia do SL e mais rapidamente aps a Linden Lab ter tornado pblico o protocolo SLGOGP de comunicao entre servidores da SL Grid e o software cliente do SL, destacando-se do SL tambm por ser uma plataforma de cdigo-fonte aberto. Tal como o SL, o OpenSimulator possibilita a criao de contedo em tempo real pelos utilizadores e de forma imersiva, atravs de ferramentas prprias para utilizadores finais, possibilitando tambm a partilha de texto, imagens, vdeo, entre outros recursos (OpenSimulator, 2012b). Talvez por ser mais recente, o OpenSimulator ainda no uma plataforma de mundos virtuais to robusto como o SL, mas sendo de cdigofonte aberto permite que sejam acrescentadas, corrigidas ou personalizadas as suas funcionalidades.

2.1.2 RECOLHA DE DADOS E ESPECIFICAO

Foram realizadas vrias reunies entre a UTAD e a FAP, especificamente com a BA5, com o intuito de se identificar, concretamente, como seria a colaborao entre estas duas entidades. No decorrer destas reunies surgiram quatro alternativas possveis, tendo sido a simulao da instalao 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 responsveis da BA5. O que se pretendia com esta simulao era que os formandos ficassem familiarizados com o processo de simulao em si e com o ambiente que iriam encontrar, ou seja, que os formandos quando chegassem ao local fsico conseguissem, rapidamente, identificar onde e como devem atuar, de modo a que a sua evoluo e coordenao em equipa seja muito mais 11

fluda. Para isto, todo o processo deve ser o mais prximo possvel da realidade, num ambiente totalmente imersivo, que permita ao formando ter uma noo clara do espao e de todo o meio envolvente. Sendo tudo isto uma nova realidade para a equipa de desenvolvimento que integrei desde o incio do processo, o volume de dados e informaes necessrias para se proceder definio de requisitos foi enorme, a recolha feita atravs de: fotografias e filmagens ao vivo de todo o processo, em vrios ngulos e reunies na BA5, complementadas atravs de esclarecimentos regulares, em conversas informais com os intervenientes, ao longo de todo o processo. Posteriormente, foi feita uma anlise exaustiva a estes dados, com base na qual foi produzido um manual de instalao, clarificando as tarefas dos vrios mecnicos e complementando as instrues das TO (Figura 3). Esta anlise permitiu tambm concluir que a manuteno destes motores efetuada sempre nos mesmos espaos e que a instalao dos mesmos realizada por trs mecnicos, com a obrigatoriedade de haver um responsvel por supervisionar e verificar todo o processo (podendo um mecnico acumular estas funes, ou estas funes passarem para um quarto elemento).

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

12

Esta recolha e anlise de informao foram realizadas por outras colegas de licenciatura e de mestrado, com a colaborao 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 dissertao (Pinto & Teixeira, 2010a, 2010b). Desta anlise retiraram-se alguns aspetos importantes, onde se destacam: o Cada mecnico tem as suas ferramentas; o Existem procedimentos em que a cooperao, a colaborao e o trabalho em equipa so obrigatrios; o Os mecnicos comunicam entre si durante todo o processo, usando a linguagem verbal como principal meio de comunicao; o O processo de instalao exige toda uma sequncia de passos, no sendo possvel realizar uma determinada tarefa sem que a anterior tenha sido concluda; o Aps uma primeira fase, em que existe apenas uma sequncia de tarefas e em que necessria a presena e a colaborao de todos os membros da equipa, a sequncia original divide-se em trs sequncias de tarefas paralelas e independentes entre si; o Os mecnicos no tm qualquer limitao de movimentos podendo caminhar livremente por todo o hangar; o Cada mecnico tem um determinado conjunto de tarefas que s cabe a si executar, no podendo efetuar qualquer outra tarefa que pertena a outro elemento da equipa, a no ser que tal lhe seja solicitado por esse elemento. o As TO podem sofrer alteraes de acordo com ordens do fabricante e as suas indicaes nem sempre so seguidas na ntegra.

Tendo em considerao estes aspetos, obtiveram-se os seguintes conjuntos de requisitos principais, que circunscreveram o desenvolvimento da plataforma-base: o Requisitos no funcionais: Limitao a nvel de rede para formao, a BA5 no possui boa ligao de rede ao exterior; Cada mecnico tem um conjunto de aes que apenas ele pode realizar; Todo o processo tem etapas onde algumas no podero ser executadas sem que a etapa anterior esteja concluda.

13

o Requisitos funcionais: Possibilidade de uma equipa, em simultneo, treinar o processo de instalao de um motor Pratt&Whitney F100 numa aeronave F-16; A simulao ter de cumprir uma sequncia lgica de passos para a instalao do motor; Possibilidade de colaborao e cooperao no trabalho em equipa e em simultneo; O utilizador ter de estar equipado com algumas ferramentas especficas para a realizao de certas tarefas.

No guio de instalao ento produzido (Pinto & Teixeira, 2010a), so descritas trinta e trs tarefas necessrias para completar todo o processo de instalao do motor na fuselagem de uma aeronave F-16. Cada uma destas tarefas foi analisada e especificada pela equipa de projeto de ento. Foram criados diagramas de casos de uso, de estados, de atividades e de classes, para cada uma das tarefas. A ttulo exemplificativo, na Figura 4, Figura 6, Figura 6 e Figura 7 so apresentados os respetivos diagramas de uma tarefa especfica, neste caso especfica, a elevao do motor.

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

14

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

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

15

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

2.1.3 PROTTIPO
Como mencionado anteriormente, pretendia-se que os formandos se sentissem familiarizados com a simulao existente e com o ambiente que vo 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) idntico ao que se pode encontrar na BA5, alm dos objetos essenciais a toda a simulao foram tambm modelados alguns objetos que podem ser encontrados no local, como por exemplo extintores, sistemas de incndio, escadas de acesso aeronave (Figura 9), etc.

FIGURA 8 - HANGAR (AMBIENTE 3D)

16

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

Aps estar modelado todo o ambiente 3D, foi implementado um prottipo experimental. Este prottipo simulava todas as tarefas at insero do motor na fuselagem da aeronave F-16. Aps ser realizado um primeiro teste com os utilizadores finais, este prottipo demonstrava algumas limitaes, assim como alguns erros de implementao. As ferramentas usadas pelos avatares, aps anexadas, no podiam ser desanexadas, os mecnicos teriam de seguir todos a mesma sequncia (no processo real no) e a sequncia de tarefas no processo de instalao do motor estava incorreto. Face a esta situao, foram identificados pormenorizadamente os problemas e elaborados novos requisitos com base nesta, sendo depois desenvolvido um segundo prottipo sustentado nestes novos requisitos. Este segundo prottipo (Figura 10 e Figura 11) simula alm das tarefas anteriores, as tarefas de segurana do motor na fuselagem e remoo do carrinho e material de apoio insero do motor.

FIGURA 10 - HUD QUE REPRESENTA EQUIPAMENTO NA MOS DIREITA E ESQUERDA

17

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

Este segundo prottipo tambm 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 prtica da formao (Fernandes, 2012).

2.2

ENVOLVENTE C ONCEPTUAL

Num contexto tecnolgico onde as necessidades do utilizador final esto em constante transformao e em que so necessrias solues robustas que suportem a interao de forma eficaz entre humanos e mquinas, a Interao Humano-Computador (Human-Computer Interaction HCI, na terminologia anglo-saxnica) pode ser entendida como uma disciplina que considera os aspetos relacionados com o design, avaliao e implementao de sistemas computacionais interativos para uso humano, bem como o estudo dos fenmenos circundantes (Hewet et al., 1992). Segundo Schmidt e Simone (1996), o trabalho cooperativo constitudo pela interdependncia de mltiplos atores a interagir atravs da alterao do estado de um campo comum de trabalho, onde o seu carcter distribudo depende de fatores como a distribuio de atividades no tempo e espao, o nmero de participantes em contextos de cooperao, a complexidade estrutural constituda pela rea de trabalho (interaes e heterogeneidade), o nvel de especializao ou experincia dos participantes, e a variedade de heursticas envolvidas, exigindo um trabalho de articulao efetivo para unir os esforos cooperativos nas atividades realizadas de forma distribuda atravs de artefactos especficos.

18

Na perspetiva dos sistemas colaborativos que fornecem o respetivo suporte s dinmicas de trabalho cooperativo, o termo groupware pode subentender-se como o conjunto de sistemas computacionais que suportam indivduos envolvidos numa tarefa (ou objetivo) comum e fornecem uma interface para um ambiente partilhado (Ellis et al., 1991). Alguns exemplos mais concretos neste segmento so os sistemas Microsoft SharePoint e o BCSCW. Os Ambientes Virtuais Colaborativos (Collaborative Virtual Environments CVE) podem ser descritos como mundos virtuais compartilhados pelos participantes atravs de uma rede de computadores e espaos tridimensionais habitados que suportam mltiplos contextos de interao, incluindo aprendizagem colaborativa, trabalho cooperativo, e jogos de natureza social (Benford et al., 2001). Segundo Morgado (2009), os mundos virtuais so um tipo especfico de ambientes virtuais. Para definir um ambiente virtual como um mundo virtual existem dois aspetos essenciais que tm de estar presentes: multiutilizao e imersividade. Ou seja, um ambiente que possibilite a conexo de vrios 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 trs tipos distintos, do ponto de vista da utilizao em contexto educativo ou de formao: o Simulao 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 contedo e competncias desse ensino; o o Sociais - espaos de socializao e de criao de comunidades virtuais; 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 computao grfica 2D ou 3D, que so partilhados por pessoas fisicamente e geograficamente distantes e que se conectam via rede. Este autor j tem uma classificao diferente, alm dos tipos suprarreferidos, classifica-os em mais dois tipos: o o Expresso Poltica servem como fruns de expresso poltica e de debate; Treino Militar espaos criados para aes de simulao de treino militar. O conceito de fluxo de trabalho, tambm conhecido como workflow, definido por Xiao (2005) como o conjunto de processos criados para coordenar as atividades de mltiplas pessoas e, desta forma, assegurar a concluso do trabalho com xito e aumentar a eficincia dos colaboradores. Os procedimentos funcionais padronizados podem influenciar o carcter

19

das atividades coordenadas, fomentando assim a integrao de tecnologia colaborativa dentro do fluxo de trabalho de uma organizao. As mquinas de estados so definidas por servios, servidores, e linguagens de programao estruturadas para suportar a modularidade. Uma mquina de estados consiste em variveis de estado que codificam o seu estado, e por comandos que transformam o seu estado. Cada comando implementado por um programa determinstico, e a execuo do comando atmica em relao aos outros comandos, modificando o estado das variveis ou produzindo certos tipos de resultados. Um cliente de uma mquina de estados faz um pedido para executar um comando. O pedido nomeia uma mquina de estados, o comando a ser executado, e contm qualquer informao 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 perifrico (e.g., um disco ou terminal), ou a clientes que aguardam resposta a partir de pedidos prvios (Schneider, 1990).

2.3

TRABALHO RELACIONADO 2.3.1 MTODO

O mtodo de pesquisa utilizado foi adaptado de Kitchenham et al. (2009) e Stapi et al. (2012), o qual se estabelece numa reviso sistemtica da literatura especificando um conjunto de questes de investigao para as quais necessrio fazer uma escolha de estudos com base em critrios de seleo, por forma a extrair evidncias significativas. Contudo, esta abordagem metodolgica foi apenas seguida at se encontrar a informao pretendida, o que acabou por ocorrer com alguma rapidez, servindo apenas como diretriz no processo de pesquisa e anlise bibliogrfica. Aps um processo de reflexo estimulado pela leitura de publicaes cientficas, representativas de trabalhos similares feitos na rea, formularam-se as seguintes questes de investigao: Q Na ltima dcada, o que foi feito ao nvel da agilizao entre as fases de conceo e implementao de ambientes de simulao, sem interveno de programadores? Q1 Quais os mundos virtuais usados para criar ambientes de simulao? Q2 Quais as limitaes existentes? Q3 O que j foi feito ao nvel do 3D com recurso a mquinas de estados hierrquicas?

20

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 atravs do programa Publish or Perish) com ligao s bases de dados IEEE Xplore, Springerlink libraries, e ACM Digital Library. Foram ainda analisadas as referncias de cada artigo (atravs do mtodo Bola de Neve) para verificar diferentes fontes e cruzar informao relevante. A amostra reporta-se essencialmente ltima dcada (2003-2012) de investigao em mundos virtuais e ambientes virtuais imersivos, partindo do ano de introduo do Second Life. Outros fatores que definem esta amostra, caracterizam-se pela natureza atual da informao e apresentao dos desafios que permanecem sem resoluo no contexto cientfico. Os fatores de excluso reportam-se a artigos que se focam em Realidade Virtual ou Realidade Aumentada, ao invs de ambientes virtuais imersivos. Tambm foram excludos vrios artigos que se focam apenas em aspetos de usabilidade, acessibilidade, etc. O processo de extrao de evidncias foi suportado pela investigao desenvolvida em ambientes virtuais colaborativos tridimensionais (Correia et al., 2012), bem como, pela anlise e filtragem de publicaes segundo os critrios previamente estabelecidos, tendo em conta os objetivos especficos deste trabalho. Complementarmente, so ainda discutidos trabalhos de natureza similar, identificados a partir da anlise ao estado do conhecimento neste domnio.

2.3.2 TRABALHO RELACIONADO

De acordo com Grudin e Poltrock (2012), os ambientes virtuais colaborativos imersivos tm vindo a sofrer alteraes constantes em termos de interesse e representao, no suporte a atividades de natureza colaborativa baseadas em simulao. No contexto atual, verifica-se uma necessidade de criar solues pouco dispendiosas e personalizadas a situaes com diferentes nveis de complexidade e riscos associados, onde estes ambientes constituem uma alternativa consistente, aplicando a Realidade Virtual em cenrios multidisciplinares como aprendizagem distncia, treino, tratamentos teraputicos, e interao social em torno de necessidades reais. Numa meta-anlise apresentada por Correia et al. (2012) foram identificadas vrias lacunas, e oportunidades de investigao, em mundos virtuais com particular enfoque sobre as dinmicas de aprendizagem colaborativa, na medida em que esperado um impacto amplo e crescente destas plataformas no ensino superior (Hew & Cheung, 2010), bem como aplicaes possveis nas reas de sade, treino militar, economia, planeamento urbano, arquitetura e engenharia (Jarmon et al., 2009). A experincia possibilitada por estes ambientes virtuais colaborativos de carter imersivo pode ultrapassar 21

as barreiras temporais, espaciais, culturais e sociais atravs de diferentes formas de interao (Anstadt et al., 2011). Neste sentido, as suas funcionalidades e canais de comunicao (por exemplo, texto, udio, cones grficos, gestos, e entradas multissensoriais) e cooperao (atravs da capacidade de integrar aplicaes partilhadas e manipular objetos digitais) permitem coordenar aes, produzir artefactos, e suportar a interao social. Apoiados na metfora do mundo real mas sem as suas limitaes fsicas ((Davis et al., 2009), os metaversos ou mundos virtuais tridimensionais imersivos tm sido investigados em atividades de aprendizagem experimental (Jarmon et al., 2009), bem como operaes, tticas e estratgias militares que requerem tecnologias sofisticadas com o intuito de preparar tropas para cenrios de combate real (Pierzchaa et al., 2011). As vantagens associadas simulao de tarefas neste tipo de ambientes virtuais estabelecem-se maioritariamente pela reduo de custos e pelo aumento da eficincia, segurana, socializao e escalabilidade (Grimstead et al., 2005), quando comparados com os sistemas colaborativos multiutilizador convencionais. Os investigadores tm identificado algumas potencialidades relacionadas a um aumento da noo de presena partilhada e perceo perifrica (Bentley et al., 1992), bem como a baixos nveis de ansiedade e limitaes 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 interao para a aprendizagem distncia que vm corroborar estas vantagens. Complementarmente, a adio de ferramentas hpticas em ambientes virtuais colaborativos tridimensionais pode aumentar a noo de copresena (Bailenson & Yee, 2008), introduzindo um modo diferente de imerso. Numa comparao entre ambientes virtuais colaborativos orientados aprendizagem (Rajaei & Aldhalaan, 2011), foi possvel analisar os sistemas Active Worlds, CVGE, WebOnCOLL, TOUCH, Americas Army, Full Spectrum Warrior e ASCIT Sick Children a nvel de arquitetura da tecnologia (grelha, ponto-a-ponto, cliente-servidor, e multi-servidor), modo de representao (avatar ou vdeo), caratersticas ao nvel da expresso facial, perceo social, disponibilidade, acessibilidade e compatibilidade, bem como formas de comunicao sncrona (chat, vdeo, e udio). A interao sncrona entre participantes em configuraes de treino tem vindo a ser permitida em ambientes laboratoriais virtuais com flexibilidade, para simular experincias onde instrutores, alunos e assistentes interagem no processo de aprendizagem. Laboratrios virtuais criados para simular atividades de ensino e descoberta em reas como qumica, fsica, biologia, mecnica e astronomia tm sido explorados a nvel acadmico, onde um exemplo conhecido o Virtual ChemLab da Brigham Young University (Aziz et al., 2013). As suas particularidades so conhecidas ao nvel da capacidade de interao com objetos digitais (e.g., 22

tubos de ensaio com solues moleculares) num ambiente laboratorial simulado que possibilita aos participantes misturar produtos qumicos em provetas virtuais e observar as reaes qumicas resultantes. A nvel dos sistemas de treino baseado em simulao, esto em desenvolvimento simuladores que podem permitir aos cirurgies manipular rgos humanos virtuais em tempo real, para adquirir competncias sem colocar em risco a vida humana, necessitando para o efeito de uma base de dados de grande dimenso composta por modelos virtuais de anatomia. Para alm disso, est ainda a ser equacionado o uso de interfaces hpticas, como o dispositivo Phantom da empresa SensAble Technologies ou as solues 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 situaes, incluindo a criao de uma experincia colaborativa e pedaggica para a pesquisa sobre a colaborao de utilizadores em ambientes virtuais 3D (Hmlinen et al., 2006), e a anlise do seu potencial para o uso de simulaes tticas 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 projeo atravs de displays em compartimentos com mltiplos ecrs. Este tambm serviu de base pesquisa para conseguir melhorias no controlador de interface humana e robtica, em contexto de interao urbana e com robs de resgate (Wang et al., 2003). O projeto Cell Biology, desenvolvido na Universidade do Arizona, permitiu aos alunos recolherem dados de clulas e us-los para calcular a durao de cada fase na diviso das clulas. Vrias plataformas de jogos (e.g., Bell & Fogler, 2003) foram utilizadas para desenvolver simulaes virtuais em situaes de emergncia como acidentes em laboratrios e treino orientado ao uso eficiente de camies, equipamentos e pessoal no combate aos incndios (DHS Student, 2007). O HumanSim foi criado pela Virtual Heroes, Inc. e utilizado para desenvolver uma simulao 3D de instruo para procedimentos de cirurgia cardaca utilizando a tecnologia Unreal Engine 3, integrando-a com um modelo fisiolgico e farmacolgico de alta-fidelidade para aprendizagem experimental. Os cenrios de simulao foram programados para os processos aprendendo-fazendo, fornecendo treino e proficincia em tarefas raras, complicadas, ou no suscetveis a erros. Estes procedimentos mostraram novos tratamentos para a fibrilao no corao, com animaes referentes aos seus processos (Aziz et al., 2013).

23

CAPTULO 3: ARQUITETURA-BASE APRESENTAO E ANLISE

Computers themselves, and software yet to be developed, will revolutionize the way we learn. Steve Jobs

Neste captulo apresenta-se a arquitetura do prottipo apresentado anteriormente, que serviu de base a este projeto. So apresentados e analisados os aspetos importantes que foram desenvolvidos ao longo de trs anos, tendo como principal preocupao a separao entre a componente lgica e a componente visual do sistema, tornando assim possvel, por exemplo, o acompanhamento da evoluo da tecnologia que utilizamos na componente visual, de modo a ter cada vez mais grficos poderosos e realistas, de forma fcil, rpida e simples. 25

3.1

APRESENTAO DA ARQUITETURA

Tendo em considerao os requisitos especificados na subseco 2.1 e analisados os aspetos importantes mencionados nesta mesma seco, constatou-se que as TO nem sempre so seguidas de forma exata, pois o processo de instalao do motor na aeronave decorre sob uma abordagem de melhoria contnua, a um ritmo necessariamente mais dinmico e local do que a evoluo das TO, logo as tarefas do processo de instalao do motor na fuselagem de uma aeronave F-16 podem frequentemente sofrer alteraes face ao registado nas TO. O prottipo apresentado na subseco 2.1 foi desenvolvido de modo a cumprir os requisitos apresentados nesta mesma subseco, mas que no entanto, quando fosse necessrio proceder alterao de tarefas ou mesmo alterar o seu ambiente 3D, no fosse praticamente como refaz-lo de raiz, exigindo assim um esforo enorme de tempo e de programao. Ou seja, foi desenvolvido de forma a cumprir os requisitos pretendidos. Ao mesmo tempo, esta oportunidade foi aproveitada para conceber um modelo tecnolgico slido e robusto, que possibilitasse alterar o funcionamento do simulador, alterar o ambiente 3D e adequar o sistema a novos requisitos de forma mais rpida e simples, assim sendo, este modelo conseguir-se-ia adaptar a vrios e diversos cenrios de simulao. Tendo em considerao este objetivo, bem como a superao da adversidade mencionada no primeiro pargrafo desta subseco, optou-se por conceber um modelo tecnolgico onde se separasse o sistema de controlo e deciso do sistema de visualizao (neste caso a componente 3D). Neste sentido, o modelo tecnolgico concebido constitudo pelos seguintes elementos: um sistema de controlo e deciso (implementado atravs de uma mquina de estados hierrquica), um protocolo de comunicao e um mdulo view genrico (script em LSL).

3.2

SISTEMA DE DECISO E C ONTROLO

A implementao da mquina de estados hierrquica para o simulador de instalao de motores Pratt&Whitney F100 em aeronaves F-16, tem portanto como objetivos principais (1) garantir a independncia dos mecanismos de coordenao e interao que esto disponveis no espao virtual 3D, assegurando a separao entre a interface grfica e o sistema de deciso; (2) permitir que sejam adicionadas mudanas no processo de instalao do motor na aeronave, mudanas que possam ser introduzidas tanto pelo fabricante como pelos formadores (por exemplo: a introduo de um erro propositado); (3) ser multiplataforma, para 26

que no seja aplicvel apenas em Opensimulator, mas em vrios outros mundos virtuais ou outras plataformas 3D. O sistema de controlo e deciso, alm da mquina de estados constitudo por uma base de dados, onde armazenada informao relativa aos objetos que intervm na simulao, bem como, o estado atual de cada avatar e o estado atual do sistema em si. Para a comunicao e interao entre o sistema de visualizao e o sistema de deciso e controlo foi definido um sistema de interao genrico como se pode observar na Figura 12.

FIGURA 12 SISTEMA DE INTERAO GENRICO (FONSECA ET AL., 2011)

Como est representado na Figura 12, neste sistema de interao est definido que: quando um avatar interage com um objeto (tocando nele), este comunica a ao ao sistema de deciso e controlo, que por sua vez, baseado na ao recebida e aps 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 no de estado e responde ao objeto enviando o(s) comando(s) a ser(em) executado(s).

FIGURA 13 - SISTEMA DE DECISO E CONTROLO

27

Para que este sistema de interao funcione necessrio que o sistema de deciso e controlo (Figura 13) consiga gerir corretamente todas as transies com base nas aes despoletadas no mundo virtual. O sistema de deciso e controlo foi implementado na plataforma ASP.NET e baseia-se, como j referido, no conceito de mquinas de estados hierrquicas. O funcionamento deste bastante simples, definido um nico ponto de entrada (um mtodo genrico), que recebe todas as aes reportadas do sistema de visualizao (neste caso, o OpenSimulator), alm disso, como o sistema mantm o controlo sobre o seu estado atual e o estado atual de cada objeto (atravs 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 visualizao, este capaz de inferir, a qualquer momento, quais so as aes possveis e se pode ou no transitar de estado.

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

Na Figura 14, apresentado o diagrama entidade-relacionamento da base de dados que constitui o sistema de deciso e controlo, como se pode verificar pela Figura 14, faz parte desta: a tabela TabelaEstados, onde so guardados todos os estados necessrios para todo o processo, tanto os estados do sistema como os estados dos avatares; a tabela Avatar, onde so 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 limitao de os trs mecnicos poderem seguir caminhos diferentes, permitindo desta forma criar nesta tabela vrios postos de trabalho, ou seja, vrios caminhos por onde a simulao pode seguir de forma independente. Para relacionar estes postos de

28

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

FIGURA 15 - DIAGRAMA DE CLASSES

Analisando mais exaustivamente o sistema de deciso e controlo verifica-se que cada um dos estados (etapas a simular) que o prottipo (apresentado na subseco 2.1) possui, corresponde implementao de uma classe derivada da classe Estado (Figura 15), contando o sistema, atualmente, com aproximadamente 40 classes. Cada uma destas classes tem um mtodo chamado gerarTarefa(), que executado assim que o sistema transita para o estado correspondente a esta classe, mtodo este onde definida (programada em cdigo) a resposta a enviar para o OpenSimulator, sendo usadas estruturas condicionais para este estado poder ter mais que uma resposta diferente, caso contrrio apenas poder ter uma nica resposta (Figura 16). Constata-se ainda que a simulao pode ter apenas um caminho (sequncia de tarefas) possvel ou ter vrios independentes ao mesmo tempo (quatro, neste caso). Por exemplo: um mecnico fazer as ligaes do lado direito e outro do lado esquerdo em simultneo. Em consequncia, no sistema esto definidas e so inicializadas cinco variveis do tipo Estado (classe genrica): uma para os avatares e as outras para os diferentes caminhos da simulao. Tendo como base a ao reportada pelo OpenSimulator, assim como no objeto que reportou 29

esta ao executada uma deciso numa estrutura switch em C#. Mediante ela, usada a varivel do tipo Estado correspondente (uma das mencionadas anteriormente), para invocar o mtodo que tratar da ao (Despachar ou DespacharSistema). Para que este mtodo trate/processe a ao reportada so percorridos os Despachantes pertencentes ao estado que chama este mtodo (lista de delegates que recebe como parmetro a ao reportada).

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

Para terminar, verifica-se que: tanto as aes como as tarefas possveis so definidas atravs de uma enumerao; para o sistema funcionar corretamente, algumas informaes tm de ser previamente inseridas na base de dados; para tal, so usadas estruturas condicionais para verificar vrios aspetos, como sejam: o nmero de vezes que aquela mesma tarefa teria de ser executada, para o sistema poder transitar de estado; o nmero de mecnicos necessrios; o tempo de realizao da tarefa; entre outros.

3.3

SCRIPT LSL COMO MDULO VIEW GENRICO

Conforme j foi mencionado, um dos objetivos principais era conseguir criar um sistema em que o ambiente 3D (sistema de visualizao) estivesse completamente separado do sistema de deciso e controlo, para assim ser possvel alterar o ambiente 3D sem haver necessidade de efetuar alteraes no cdigo do sistema de deciso e controlo. Para isto, o sistema tridimensional no podia tomar nenhuma deciso, todos os objetos presentes no ambiente 3D apenas comunicam que ao ocorreu e quem disparou essa mesma ao ao 30

sistema de deciso e controlo, e aguarda por uma ou mais tarefas para executar. Neste sentido, todos os objetos que tm interao no processo de instalao do motor, possuem um script (desenvolvido na linguagem LSL) que permite comunicar mquina de estados a ao que ocorreu e interpretar qualquer tipo de resposta(s) dada(s) pelo sistema de deciso 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 aes e reagir de forma completamente diferente, dependendo do objeto onde se encontra e da(s) tarefa(s) enviada(s) pelo sistema de deciso e controlo. Este script, alm 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 tambm realizarem tarefas, caso fosse essa a ordem recebida do sistema de deciso e controlo. Com este script nico para todos os objetos, deixando de ser necessrio programar um script diferente consoante o tipo de objeto e o tipo de resposta que este vai receber, estava alcanada a desejada separao entre o sistema de visualizao e o sistema de deciso e controlo.

3.4

PROTOCOLOS DE COMUNICAO

Depois de concluda a separao entre o sistema de visualizao e o sistema de deciso e controlo, foi necessrio idealizar e definir mecanismos de comunicao entre os mesmos. Desta forma, devido ao elevado nmero de comunicaes que vo ser realizadas entre os sistemas e a necessidade das comunicaes ficarem genricas, para que no futuro, caso seja necessrio efetuar alguma alterao, ou acrescentar alguma funcionalidade, seja bastante mais fcil e rpido, foi imprescindvel a criao de um protocolo de comunicao genrico/standard especfico para o nosso sistema. Aps esta necessidade tentaram-se perspetivar as situaes de comunicao diferentes que podiam surgir. No entanto, chegou-se concluso que s aps a implementao de uma sequncia de alguns passos concretos, que se conseguiria ter uma noo mais concreta e correta destas diferentes situaes. Concluiu-se que, para se integrar os dois sistemas, eram necessrios trs tipos de protocolos de comunicao: Sistema de Deciso e Controlo Ambiente 3D; (Tabela 1)

31

 Ambiente 3D Sistema de Deciso 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 aes) Ambiente 3D Ambiente 3D (pois existem situaes em que um objeto ter de falar com outro e comunicar-lhe tarefas a realizar) (Tabela 4).

Parmetro

Tipo

Funo Corresponde ao nmero de tarefas que o Sistema de Deciso e Controlo envia como resposta Corresponde a uma tarefa a realizar, ex: 1-Falar, 2- Mover Corresponde ao nmero de parmetros que a tarefa vai ter Corresponde aos parmetros especficos de uma determinada tarefa

Parmetro 1

Nmero inteiro

Parmetro 2

Nmero inteiro

Parmetro 3

Nmero inteiro

Parmetro 4, 5,, n

String

TABELA 1 - PROTOCOLO DE COMUNICAO: SISTEMA DE DECISO CONTROLO AMBIENTE 3D

Parmetro Parmetro 1 String

Tipo

Funo Corresponde ao nome da ao que aconteceu, neste caso Objcriado Corresponde ao nome do objeto Contm a key deste objeto Contm a posio deste objeto, ou seja, as suas coordenadas Contm a rotao do objeto

Parmetro 2 Parmetro 3 Parmetro 4

String String String

Parmetro 5

String

TABELA 2 - PROTOCOLO DE COMUNICAO: AMBIENTE 3D SISTEMA DE DECISO E CONTROLO (OBJETO CRIADO)

32

Parmetro Parmetro 1 String

Tipo

Funo Corresponde ao nome da ao que aconteceu, ex: tocado, attached Contm a key do objeto Contm a key do avatar ou objeto que interagiu com este Contm a nova posio do objeto, ou seja, as suas coordenadas Contm a nova rotao do objeto

Parmetro 2 Parmetro 3

String String

Parmetro 4

String

Parmetro 5

String

TABELA 3 - PROTOCOLO DE COMUNICAO: AMBIENTE 3D SISTEMA DE DECISO E CONTROLO

Parmetro Parmetro 1

Tipo Nmero Inteiro

Funo Corresponde nmero do canal pelo qual vamos comunicar Contm a key do objeto que est a comunicar Corresponde a uma aco a realizar, ex: 1-Falar, 2- Mover, 3-Escrever Contm a informao a enviar, ex: se a ao for mudar dever conter as coordenadas que o objeto dever assumir

Parmetro 2

String

Parmetro 3

Nmero Inteiro

Parmetro 4

String

TABELA 4 - PROTOCOLO DE COMUNICAO: AMBIENTE 3D AMBIENTE 3D

Atravs da utilizao destes protocolos de comunicao, conseguiu-se implementar uma estrutura de comunicao genrica entre os dois sistemas, permitindo que esta arquitetura seja menos falvel e possua uma manuteno bastante mais facilitada e rpida.

33

CAPTULO 4: NOVA ARQUITETURA: PROTTIPO

"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 captulo, 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. tambm apresentada, neste captulo, toda a evoluo dos diferentes componentes do sistema, nomeadamente, um sistema de deciso e controlo totalmente novo e remodelado, as alteraes necessrias ao script LSL nico, bem como ao protocolo de comunicao. ainda apresentada a estrutura de dados dos ficheiros de configurao do sistema e a interface grfica atualmente usada para a criao dos mesmos. 35

4.1

METODOLOGIA ADOTADA

Durante o processo de desenvolvimento do trabalho da presente dissertao, adotouse a metodologia Design Science.

FIGURA 17 - CICLOS DA METODOLOGIA DESIGN SCIENCE (HEVNER, 2007)

Como podemos observar na Figura 17, segundo Hevner (2007), na metodologia Design Science o processo de desenvolvimento composto por trs fases interligadas entre si, atravs de atividades. No ciclo da relevncia analisado o ambiente contextual do projeto de pesquisa e feita uma ponte para as atividades de design (conceo). O ciclo do rigor liga as atividades de conceo experiencia e ao conhecimento baseado em fundamentos cientficos. O ciclo de conceo alterna entre atividades de construo e avaliao dos produtos concebidos. Com base nesta metodologia, o ciclo de relevncia, que incide sobre o ambiente, descrito ao longo da seco de contextualizao (subseco 2.1). Os resultados desse ciclo so essencialmente os requisitos, que foram evoluindo e cuja especificao apresentada ao longo da subseco 4.3. Para o ciclo do rigor, foram realizadas vrias pesquisas de artigos cientficos, 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 subseco 2.3. Tudo isto permitiu criar uma ponte para a conceo dos produtos e processos descritos ao longo deste captulo. Estes produtos foram sofrendo constantes avaliaes, de modo a detetar e corrigir o maior nmero de possveis falhas. Com um prottipo j implementado, foram realizados alguns testes com utilizadores, expostos na seco 5. Entrando-se novamente no ciclo da relevncia, onde foram detetados novos problemas e de onde surgiram novos requisitos.

36

4.2

IDENTIFICAO DO PROBLEMA

No sistema utilizado para conceber o prottipo (apresentado ao longo da subseco 2.1), cujo funcionamento apresentado ao longo da seco 3, para introduzir uma nova pea/componente na simulao necessrio efetuar a sua modelao e fazer o upload para o OpenSimulator. Em seguida para que este componente fique integrado com a simulao imprescindvel que se aplique um script, tendo esse que ser editado de forma a colocar algumas informaes relativas a esse mesmo componente (nomeadamente, posio inicial na simulao, rotao, etc.), sendo esta edio do script um dos passos que era necessrio alterar, de modo a no ser preciso efetuar alteraes no cdigo. Para atribuir comportamentos a este mesmo componente (conforme podemos verificar na subseco 3.2), necessrio: criar e implementar uma nova classe que derive da classe Estado (Figura 15); nesta classe, no mtodo gerarTarefa(), programar a resposta, ou respostas (com recurso a estruturas de deciso como podemos ver na Figura 16), a enviar ao OpenSimulator quando o sistema entra neste estado, e caso essas respostas contenham tarefas que so necessrias realizar mais do que uma vez, ou com mais do que um interveniente, ainda necessrio programar essas verificaes; implementar os

Despachantes (lista de delegates que recebe como parmetro a ao reportada) para as aes a que este estado vai responder, e qual o estado resultante para cada uma delas. Por fim, era necessrio adicionar este estado tabela, na base de dados, que contm todos os estados necessrios para a simulao. Era necessrio alterar todos estes passos, de modo a que se pudessem atribuir comportamentos, sem ser preciso efetuar alteraes no cdigo do sistema de deciso e controlo, nem lidar diretamente com base de dados. ainda possvel verificar na subseco 3.2, mais propriamente na Figura 16, que o sistema recebe uma ao, e s aps este transitar para um novo estado que o mtodo gerarTarefa() chamado, sendo que s nesse momento que enviada a resposta ao reportada pelo OpenSimulator, ou seja, o sistema transita para um novo estado quer as tarefas dadas ao OpenSimulator sejam ou no executadas, mesmo que o OpenSimulator nem receba a resposta ao (por exemplo: por problemas de comunicao) o estado do sistema ou do avatar j ser outro, como se as mesmas tivessem sido realizadas. Era necessrio eliminar este problema de modo a ter um sistema mais fivel. Desta forma, conforme mencionado anteriormente, o prottipo apresentado ao longo da subseco 2.1, permite reproduzir as tarefas de instalao 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 caractersticas 37

comportamentais so tambm implementadas, obrigatoriamente, pelos programadores, o que impossibilita a concretizao do objetivo desta dissertao.

4.3

ESPECIFICAO DOS NOVOS REQUISITOS

Face a esta situao e tendo em considerao o conhecimento adquirido com a anlise ao funcionamento desse mesmo prottipo, apresentado ao longo da seco 3, bem como a concretizao dos objetivos primordiais definidos e j referenciados previamente, obtiveramse ento os seguintes requisitos: o Requisitos no funcionais: A criao e personalizao de qualquer tipo de definies deve ser fcil e intuitiva para os utilizadores; O sistema deve ser independente do ambiente 3D utilizado, devendo ser adaptvel a plataformas 3D existentes; o Requisitos funcionais: Permitir definir a lista de objetos intervenientes na simulao, e as suas informaes; Permitir definir a lista de estados (etapas) que constituem a simulao; Permitir definir, para cada estado, a lista de aes disponveis e o(s) estado(s) resultante(s) para cada uma destas; Possibilitar definir para cada ao disponvel em cada estado, a lista de tarefas a enviar como resposta; Possibilitar definir para cada ao disponvel em cada estado, restries para o sistema transitar de estado; O sistema deve ser verstil, conseguindo carregar e gerar um servio com qualquer tipo de definies presentes nos ficheiros de configurao; O sistema deve ainda, transitar apenas de estado aps ter a confirmao que as tarefas a realizar foram recebidas.

4.4

EVOLUO DO SISTEMA DE DECISO E C ONTROLO

Anteriormente, o objetivo alm de englobar o desenvolvimento de um simulador com os devidos requisitos, procurava tambm conceber um modelo tecnolgico slido e robusto, que possibilita-se alterar o funcionamento do simulador, alterar o ambiente 3D e adequar o 38

sistema a novos requisitos de forma mais rpida e simples. No entanto, agora o objetivo tornou-se mais ambicioso: conceber um modelo tecnolgico que permita gerar o funcionamento do simulador a partir de ficheiros de configurao personalizados por utilizadores, cumprindo assim tambm o objetivo primordial desta dissertao. Face a estes requisitos, optou-se ento por uma abordagem onde o modelo tecnolgico era constitudo por programas/sistemas distintos, um responsvel por oferecer uma interface de fcil utilizao e intuitiva, para o utilizador criar e personalizar, os ficheiros de configurao com as definies desejadas e o outro que seria ento o sistema de deciso de controlo, responsvel por aplicar ao ambiente 3D toda a lgica funcional presente nesses mesmos ficheiros de configurao.

FIGURA 18 DIAGRAMA DE CLASSES (NOVA ARQUITETURA)

39

De modo a facilitar a comunicao/ligao ao ambiente 3D, o novo sistema de deciso e controlo foi implementado atravs de um webservice desenvolvido na plataforma ASP.NET, e para a facilitar esta implementao foi conceptualizada uma representao da estrutura e relao das vrias classes integrantes no sistema. Este modelo define todas as classes que o sistema necessita incorporar, as suas relaes, os seus elementos e funes. Na Figura 18, apresentado o diagrama de classes idealizado para o sistema de deciso e controlo. Como se pode apurar pela figura 18, so necessrias sete classes para o sistema de deciso e controlo funcionar. A classe principal do sistema, ou seja, a que responsvel por gerir todo o funcionamento do sistema a classe Manager, foi implementada segundo o padro de software Singleton. Usou-se este padro de software com o objetivo de garantir que todos os pedidos efetuados ao sistema acedessem mesma instncia desta classe, e deste modo assegurar que ao longo dos pedidos no havia perda de dados, e que estes eram processados sempre em funo de dados atualizados. Esta classe contm uma lista dos objetos intervenientes na simulao e uma lista de todos os estados (etapas) possveis da simulao, bem como a informao do(s) estado(s) atual do sistema e do estado atual do(s) avatar(es). Esta possui ainda dois mtodos, um que processa qualquer ao reportada pelo ambiente 3D e outro que recebe todas as confirmaes relativamente execuo das tarefas enviadas para o ambiente 3D como resposta s aes anteriormente reportadas. A classe Object tem como nico propsito armazenar toda a informao necessria, relativamente a cada um dos objetos intervenientes na simulao. A classe State tem como principal objetivo armazenar toda a informao sobre cada um dos estados (etapas) possveis da simulao, em especial, a que aes no ambiente 3D, este estado vai responder. Esta classe contm ainda dois mtodos, um que verifica se este estado responde ao reportada pelo ambiente 3D, e em caso afirmativo invoca um mtodo que avalia se esto cumpridos todos os requisitos para que esta ao seja processada pelo sistema, e outro, para tratar da ao reportada pelo ambiente 3D, enviando como resposta a esta, as tarefas a serem executadas. A classe ForwardingAgent responsvel pelo armazenamento de diversos tipos de informao relativamente a cada ao que um determinado estado responde, nomeadamente, o estado que resulta desta ao, ou seja, o estado para que o sistema transita como resultado a esta ao, quais as restries para esta transio ocorrer, quais as tarefas a enviar como resposta ao ambiente 3D, o nmero de vezes que essas tarefas tm de ser executadas, com quantos participantes e qual o tempo mximo para tal. Esta classe possui ainda um mtodo

40

que avalia se esto cumpridos todos os requisitos para que esta ao seja processada pelo sistema. A classe Response tem com funo armazenar e gerir a lista de tarefas a enviar como resposta a aes reportadas pelo ambiente 3D. Possuindo tambm dois mtodos, um que permite adicionar facilmente mais uma tarefa lista, e outro que transforma a lista de tarefas numa string com um determinado padro definido no protocolo de comunicao. A classe Task apenas tem como funo armazenar, sobre cada tarefa, qual o tipo e quais os parmetros de cada uma. A classe TaskItem apenas responsvel por armazenar a informao sobre cada tipo de tarefa.

FIGURA 19 FLUXOGRAMA DO FUNCIONAMENTO BSICO DO SISTEMA DE DECISO E CONTROLO

41

De modo a entender o funcionamento do sistema de deciso e controlo mais detalhadamente e de forma mas simples e rpida, foi criado um fluxograma facilitando assim a sua explicao. Como se pode verificar atravs da Figura 19, assim que o sistema (webservice) iniciado, so carregadas todas as definies presentes nos ficheiros de configurao, ou seja, todo o funcionamento da simulao gerado a partir do que est presente nesses mesmos ficheiros. A partir desse momento o sistema de deciso 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 verificao que o sistema vai realizar ver se o avatar que praticou a ao novo para o sistema, ou seja, se este ainda no est registado no sistema, comprovando-se isto, este avatar registado e -lhe atribudo 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 ao, consegue lidar com essa mesma ao. No 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 ao, 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 ao que confirmada, se algum estado j cumpre todos os requisitos, transita para um outro, caso ainda no seja possvel, 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 ao confirmada, continuando sempre a aguardar novos pedidos do ambiente 3D.

4.5

EVOLUO DO PROTOCOLO DE COMUNICAO

Com a implementao deste novo sistema de deciso e controlo, e as alteraes ao mdulo view genrico, perspetivou-se que seria possvel obter uma maior generalizao nas comunicaes, o que levou a definir esta generalizao como um novo requisito. Provocando assim, a realizao de algumas alteraes, essencialmente em resposta a este mesmo requisito, passando a haver apenas dois dos quatro tipos de protocolo anteriormente definidos, e tornando o protocolo de comunicao mais homogneo. Com este novo sistema de deciso e controlo, e estando todos objetos intervenientes na simulao definidos no 42

ficheiro de configurao, identificou-se a necessidade de nas respostas ao ambiente 3D, informar se para aquelas tarefas so para usar, ou no, coordenadas globais, devido ao facto de poder existir objetos compostos por vrios objetos e nesses casos o tipo de coordenadas a utilizar so diferentes. Face a esta necessidade definiu-se como novo requisito, a reformulao do protocolo de comunicao, de modo a este integrar a informao do uso, ou no, de coordenadas globais. Assim, os dois tipos de protocolo utilizados so: Sistema de Deciso 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 Deciso e Controlo (Tabela 3), deixamos de ter os dois subtipos diferentes deste tipo de protocolo; Parmetro Parmetro 1 Parmetro 2 Parmetro 3 Parmetro 4 Parmetro 5, 6,, n Tipo Nmero inteiro Nmero inteiro Nmero inteiro Nmero inteiro String Funo Corresponde ao nmero de tarefas que o Sistema de Deciso e Controlo envia como resposta Corresponde se nestas tarefas para usar coordenadas globais Corresponde a uma tarefa a realizar, ex: 1-Falar, 2- Mover Corresponde ao nmero de parmetros que a tarefa vai ter Corresponde aos parmetros especficos de uma determinada tarefa

TABELA 5 - NOVO PROTOCOLO DE COMUNICAO: SISTEMA DE DECISO CONTROLO AMBIENTE 3D

De modo a entender mais facilmente o protocolo usado para comunicaes enviadas do sistema de deciso e controlo para o ambiente 3D, apresentada em seguida uma hipottica resposta desse tipo, e posteriormente, explicado cada um dos campos da mesma.

Bom dia

1001

www.google.com

TABELA 6 - EXEMPLO DE COMUNICAO DO TIPO: SISTEMA DE DECISO CONTROLO AMBIENTE 3D

Tomando este exemplo, como uma resposta real para o ambiente 3D, este interpretaria a mensagem da seguinte forma: 2 = Nmero de tarefas a serem executadas; 0 = No para usar coordenadas globais; 0 = Gnero da 1 tarefa, neste caso 0 corresponde tarefa de falar; 2 = Nmero de parmetros desta primeira tarefa; 43

0 = Canal em que ter que falar, neste caso 0 significa canal pblico; Bom dia = Mensagem a comunicar; 1001 = Gnero da 2 tarefa, neste caso 1001 corresponde tarefa de carregar uma pgina; 1 = Nmero de parmetros desta segunda tarefa; www.google.pt = A pgina a carregar.

4.6

EVOLUO DO SCRIPT LSL COMO MDULO VIEW GENRICO

Ao nvel do mdulo view genrico (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 aps ter a confirmao que as tarefas a realizar foram recebidas, e o novo requisito identificado na subseco anterior, da reformulao do protocolo de comunicao, de modo a este integrar a informao do uso, ou no, de coordenadas globais, foi no entanto necessrio realizar algumas alteraes ao mdulo view genrico. Desta forma, foi alterado no script o modo de comunicao com os outros objetos, passando esta comunicao a ter uma estrutura mais idntica com a comunicao que o sistema de deciso e controlo tem com o ambiente 3D, estrutura essa que ser apresentada e explicada detalhadamente no prximo subcaptulo. Com o intuito de satisfazer o requisito anteriormente mencionado, de o sistema apenas transitar de estado aps ter a confirmao que as tarefas a realizar foram recebidas, foi realizada uma outra alterao significativa a este script, a implementao de um pedido ao sistema de deciso de controlo, aps terem sido executadas todas as tarefas recebidas como resposta a uma ao reportada, de modo a este tomar conhecimento sobre o sucedido.

4.7

ESTRUTURA DOS DADOS

Para que a personalizao e criao de todo o funcionamento da simulao fosse realizado de forma simples e intuitiva, e posteriormente o sistema de deciso e controlo funcionasse, na sua plenitude, sem correr quaisquer riscos de falhas ao nvel do carregamento das definies presentes nos ficheiros de configurao, foi necessrio definir para os ficheiros de configurao um estrutura slida e robusta, mas ao mesmo tempo verstil, capaz de guardar detalhadamente todas as definies. Para estes ficheiros de configurao optou-se pelo uso de uma linguagem de anotao, baseada em XML, pois um tipo de formato usado para a criao de documentos com dados organizados de forma hierrquica.

44

Deste modo, tem-se dois tipos de estruturas distintos, uma para o ficheiro de configurao relativo aos objetos e outra para o ficheiro de configurao relativo ao funcionamento da simulao. Estas estruturas so expostas em seguida, atravs da apresentao dos respetivos DTD, bem como a rvore de componentes, correspondente a cada um deles para uma mais fcil interpretao.

<?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 CONFIGURAO DOS OBJETOS

FIGURA 21 - RVORE DE COMPONENTES DO FICHEIRO DE CONFIGURAO DOS OBJETOS

45

<?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 CONFIGURAO DA SIMULAO

FIGURA 22 - RVORE DE COMPONENTES DO FICHEIRO DE CONFIGURAO DA SIMULAO

46

4.8

INTERFACE GRFICA

Para a criao dos ficheiros de configurao poder ser realizvel por utilizadores finais, de forma rpida e simples, sem ter necessariamente conhecimentos de programao, foi desenvolvida uma interface grfica simples mas funcional, permitindo no apenas a criao como tambm a modificao de ficheiros de configurao j criados anteriormente, possibilitando desta forma testar o prottipo criado.

FIGURA 24 - JANELA INICIAL E MENU DA SIMULAO (EDITOR DO SISTEMA)

Assim que a aplicao iniciada, surge a janela inicial (Figura 24), que contm duas opes: criar uma nova simulao ou editar uma simulao j criada anteriormente. Para criar uma nova simulao o utilizador apenas tem de clicar na opo New Simulation, surgindo de imediato a janela referente ao menu dessa mesma simulao, que permite ao utilizador abrir quer a janela de configurao dos objetos, quer a janela de configurao dos estados da simulao (onde so atribudos comportamentos aos objetos).

FIGURA 25 - JANELA DE CONFIGURAO DOS OBJETOS (LISTA DE OBJETOS)

47

No ser possvel ao utilizador abrir a janela de configurao dos estados, se ainda no tiver definido os objetos para a simulao. Para registar os objetos intervenientes na simulao o utilizador deve clicar na opo Manage Objects, que abrir a janela de configurao dos objetos. Esta janela composta por duas seces: uma (Figura 25) onde apresentada a lista de todos os objetos j registados e onde se encontra a opo de guardar esta mesma lista; e outra (Figura 26) que permite registar um novo objeto. Para efetuar este registo necessrio introduzir algumas informaes relativas ao objeto, tais como: o seu nome, o seu identificador nico, as suas coordenadas no mundo virtual; estas informaes podem ainda ser completadas pela introduo da rotao, bem como pela indicao se este objeto um elemento independente, ou se parte integrante de um outro objeto. Para obter todas estas informaes necessrio ir ao mundo virtual, consultar as propriedades do objeto.

FIGURA 26 JANELA DE CONFIGURAO DOS OBJETOS (REGISTAR NOVO OBJETO)

Aps estarem registados todos os objetos necessrios para a simulao, o utilizador deve guardar a lista, clicando na opo Save Objects List. Em seguida, j possvel ao utilizador abrir a janela de configurao dos estados clicando na opo Manage States. Esta janela constituda por quatro seces: uma (Figura 27) onde possvel criar novos estados, onde apresentada a lista de todos os estados j criados e onde se encontra a opo de guardar esta mesma lista; outra (Figura 28) onde possvel para cada estado adicionar as aes exequveis bem como definir qual o estado que resulta dessa ao, ou seja, permite definir as aes a que esse estado responde e o estado para o qual o sistema transita quando esta ao ocorre; outra (Figura 29) que permite adicionar restries s aes, ou seja, definir para cada ao requisitos que tm de ser cumpridos para que essa ao possa ser processada; 48

e por fim uma outra seco (Figura 30) que permite adicionar para cada ao de um determinado estado, quais as tarefas a enviar como resposta para o mundo virtual.

FIGURA 27 - JANELA DE CONFIGURAO DOS ESTADOS (LISTA DE ESTADOS)

Em primeiro lugar, na seco onde possvel criar novos estados (Figura 27), o utilizador deve definir todos os estados (etapas) necessrios para a simulao pretendida. Numa segunda fase, o utilizador deve na seco de adicionar aes (Figura 28), definir para cada estado, as aes possveis para o mesmo. Para isto, o utilizador deve: selecionar o estado ao qual vai adicionar a ao; em seguida, selecionar se a ao vai ou no ser colaborativa, caso seja, definir quantas vezes esta ao tem de ser realizada, quantos elementos so necessrios e qual o tempo mximo para os mesmos a realizarem; selecionar dentro dos eventos

FIGURA 28 - JANELA DE CONFIGURAO DOS ESTADOS (ADICIONAR AES)

49

disponveis qual o pretendido; selecionar sobre qual objeto a ao vai ser praticada; e por fim, selecionar qual o estado que resulta dessa mesma ao.

FIGURA 29 - JANELA DE CONFIGURAO DOS ESTADOS (ADICIONAR RESTRIES)

Aps ter definido para todos os estados, todas as aes possveis, o utilizador deve em seguida definir restries para as aes a que isto se aplica (por exemplo: apertar um parafuso no pode ser feito sem antes pegar na chave apropriada). Para isto, o utilizador deve na seco para este efeito (Figura 29), selecionar o estado, e mediante isso, a ao desse mesmo estado a que quer adicionar a restrio, e por fim selecionar a restrio que pretende. Por fim, o utilizador deve adicionar para todas as aes, de todos os estados, quais as tarefas a enviar como resposta. Assim em primeiro lugar, na seco de adicionar as tarefas

FIGURA 30 - JANELA DE CONFIGURAO DOS ESTADOS (ADICIONAR TAREFAS)

50

(Figura 30) o utilizador deve: selecionar um estado; em seguida, selecionar uma ao desse mesmo estado; aps isto, deve dentro das tarefas disponveis, escolher a desejada; por fim, depois de ter adicionado essa tarefa, o utilizador deve clicar nela de modo a especificar alguns parmetros relacionados com a mesma (por exemplo: se a tarefa for anexar alguma ferramenta ao avatar, especificar a que mo esta se deve anexar). Assim que o utilizador tiver todos os comportamentos definidos para a simulao, este deve voltar seco onde apresentada a lista de todos os estados (etapas) da simulao e guardar esta lista, clicando na opo Save States List, tornando possvel de imediato realizar esta mesma simulao.

51

CAPTULO 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 captulo referente realizao de testes com utilizadores, numa fase inicial so expostos os testes realizados e o que se pretendia auferir com eles, e em seguida so apresentados os resultados dos mesmos, bem como as evidncias que se conseguiram extrair com os resultados obtidos. 53

5.1

AMBIENTE DE TESTES

De forma a conseguir aferir se o sistema estaria acessvel a qualquer utilizador e a detetar possveis erros no estado atual do mesmo, foram realizados testes ao prottipo desenvolvido com diversos utilizadores. Estes testes de utilizao revelaram-se bastante produtivos, pois ajudaram a detetar pequenos erros na interface grfica, bem como perceber o que poderia ser melhorado para o sistema ficar mais acessvel aos utilizadores em geral. Para estes testes foram construdos os seguintes instrumentos: o Termo de consentimento; o Questionrio de caracterizao de perfil; o Questionrio de satisfao; o Meio de suporte recolha de dados complementares.

O questionrio de caracterizao de perfil foi elaborado com o objetivo de aferir o conhecimento dos utilizadores em mundos virtuais, e experincias prvias neste tipo de ambientes. J o questionrio de satisfao foi elaborado com o objetivo de aferir a opinio dos utilizadores relativamente a vrios 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 execuo, erros resultantes da ao dos utilizadores, as dvidas surgidas e todas as observaes que fossem necessrias. Uma vez que a recolha de dados seria realizada com recurso a questionrios, foi criado um termo de consentimento onde se pedia a autorizao para a anlise e utilizao dos dados. Pode-se observar com mais detalhe este termo de consentimento no anexo 1, bem como o questionrio de caraterizao de perfil e o questionrio de satisfao nos anexos 2 e 3 respetivamente. Os testes foram realizados numa sala com algum grau de isolamento do ambiente exterior, sonoro, para que fossem mnimas as interferncias. Foi inicialmente explicado a cada utilizador qual o propsito do teste, em que projeto se inseria, assim como o objetivo da aplicao que iam testar. Aps este momento, foi pedido ao utilizador que respondesse ao questionrio de caracterizao do perfil, logo aps, foi realizada uma breve explicao ao utilizador de como utilizar a aplicao, tendo sido descrito para que servia cada controlo e como se interagia com ela. Em seguida, foi tambm fornecido ao utilizador um documento com o objetivo pretendido e com algumas instrues sobre as aes que o utilizador tinha que executar durante o teste. 54

Enquanto o utilizador executava as tarefas pretendidas, eram ento registados alguns dados complementares, nomeadamente: o tempo de execuo de cada uma, o nmero de erros efetuados pelo utilizador, bem como o nmero de dvidas. Aps serem executadas todas as tarefas, era demonstrado ao utilizador o resultado do que tinha criado, ou seja, era realizada a simulao criada por ele. Por fim, era pedido que este preenchesse o questionrio de satisfao sobre o sistema utilizado.

5.2

CARACTERIZAO DA AMOSTRA

De forma a avaliar a satisfao dos utilizadores na utilizao do sistema, a sua opinio relativamente a vrios aspetos do sistema, bem como detetar possveis melhorias para o mesmo, foi preparado um questionrio com um conjunto de perguntas e um meio de suporte recolha de dados complementares, para anotar os tempos de execuo, os erros e as dvidas para cada uma dessas tarefas a executar pelos utilizadores. Foram efetuados testes a uma populao de 12 indivduos, todos eles do sexo masculino e com idades compreendidas entre 18 e 30 anos.

GRFICO 1 - CLASSIFICAO DOS UTILIZADORES QUANTO IDADE

Destes utilizadores, 5 tinham idades compreendidas entre 18 e 24 anos, o que equivale a 42% do total de indivduos que fizeram avaliao. Por sua vez, 7 utilizadores tinham idades compreendidas entre 25 e 30 anos que equivale a 58%, como mostra o Grfico 1. Para avaliar a experincia do utilizador a nvel informtico, foi perguntado a todos os indivduos que efetuaram o teste se usam computador, com que frequncia o usam e com que finalidades. Todos os utilizadores responderam que usam o computador, o que equivale a

55

100% do total de indivduos que fizeram avaliao, variando apenas a frequncia com que o utilizam.

GRFICO 2 - CLASSIFICAO DOS UTILIZADORES QUANTO FREQUNCIA COM QUE USA O COMPUTADOR

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 vrias vezes ao longo do dia, sendo de salientar ainda que nenhum dos utilizadores o utiliza apenas semanalmente, como mostra o Grfico 2. As finalidades com que cada utilizador utiliza o computador so bastante diversas.

GRFICO 3 - CLASSIFICAO DOS UTILIZADORES QUANTO FINALIDADE COM QUE USAM O COMPUTADOR

Como se pode observar pelo Grfico 3 so diversas as finalidades do uso do computador, sendo de salientar que 7 dos utilizadores (a maior parte) utiliza-o como meio de

56

trabalho, e ainda 5 utilizadores responderam que o utiliza para todas as finalidades apresentadas. Indo de encontro a questes mais especficas da presente dissertao, foi perguntado a todos os indivduos 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 formao quer para utilizao quer para programao em mundos virtuais, sobre quais tinham tido essa formao, e por fim, como classificavam a sua capacidade quanto utilizao ou programao em mundos virtuais, para avaliar a experincia do utilizador relativamente a estes.

GRFICO 4 - CLASSIFICAO DOS UTILIZADORES QUANTO AOS MUNDOS VIRTUAIS QUE CONHECEM

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 alm destes, como mostra o Grfico 4.

GRFICO 5 - CLASSIFICAO DOS UTILIZADORES QUANDO UTILIZAO DE MUNDOS VIRTUAIS

57

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 questo, como mostra o Grfico 5.

GRFICO 6 - CLASSIFICAO DOS UTILIZADORES QUANTO AOS MUNDOS VIRTUAIS QUE UTILIZOU

Como se pode observar no Grfico 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 tambm o Opensimulator.

GRFICO 7 - CLASSIFICAO DOS UTILIZADORES QUANTO FINALIZAO COM QUE USARAM MUNDOS VIRTUAIS

Relativamente finalidade com que os utilizadores usaram os mundos virtuais, podese verificar que 8 deles (a grande maioria) o utilizou como trabalho, 3 desses utilizadores j 58

usaram para formao, apenas 3 utilizadores j usaram como forma de entretimento, e 3 como forma de socializao, sendo de salientar ainda que 2 utilizadores j usaram para todas as finalidades apresentadas, como mostra o Grfico 7.

GRFICO 8 - CLASSIFICAO DOS UTILIZADORES QUANTO OBTENO DE FORMAO PARA UTILIZAR MUNDOS VIRTUAIS

Quanto ao facto de j ter tido algum tipo de formao para a utilizao 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 formao para a utilizao dos mesmos, como mostra o Grfico 8.

GRFICO 9 - CLASSIFICAO DOS UTILIZADORES QUANTO AO MUNDO VIRTUAL PARA O QUAL OBTIVERAM FORMAO

Como se pode observar no Grfico 9, todos os utilizadores que anteriormente afirmaram j ter tido algum tipo de formao para a utilizao de mundos virtuais 3D, 59

responderam ter tido essa formao para utilizar o Seconde Life, sendo que apenas 3 desses utilizadores mencionaram terem tambm tido formao para utilizar o Opensimulator.

GRFICO 10 - CLASSIFICAO DOS UTILIZADORES QUANTO CAPACIDADE DE UTILIZAO DE MUNDOS VIRTUAIS

Dos utilizadores que afirmaram j ter tido algum tipo de formao para a utilizao de mundos virtuais 3D, 5 deles classificaram a sua capacidade de utilizao como sendo boa, o que equivale a 72% dos utilizadores que obtiveram formao, no entanto 1 desses utilizadores classificou a sua capacidade de utilizao como medocre e ainda 1 deles classificou como muito m, como mostra o Grfico 10.

GRFICO 11 - CLASSIFICAO DOS UTILIZADORES QUANTO OBTENO DE FORMAO PARA PROGRAMAR EM MUNDOS VIRTUAIS

Quanto ao facto de j ter tido algum tipo de formao para a programao em mundos virtuais 3D, todos os utilizadores que anteriormente responderam de forma positiva quanto formao para a utilizao dos mesmos, responderam aqui de igual modo. Sendo que desses 7 60

utilizadores todos mencionaram ter sido o Second Life o mundo virtual para o qual obtiveram a formao para programar, e apenas 4 desses utilizadores responderam que tiveram essa formao tambm para o mundo virtual Opensimulator, como mostra o Grfico 11.

GRFICO 12 - CLASSIFICAO DOS UTILIZADORES QUANTO CAPACIDADE DE PROGRAMAO EM MUNDOS VIRTUAIS

Como se pode observar no Grfico 12, dos utilizadores que afirmaram j ter tido algum tipo de formao para programar em mundos virtuais 3D, apenas 3 deles classificaram a sua capacidade de programao em mundos virtuais como sendo boa, o que equivale a 43% dos utilizadores que obtiveram esse tipo de formao, sendo que 3 desses utilizadores classificou a sua capacidade de programao nos mesmo como medocre, o que equivale a 43%, e ainda 1 deles classificou a sua capacidade de programao como muito m.

5.3

ANLISE DE RESULTADOS

Dos questionrios de satisfao, bem como dos dados complementares recolhidos aps os testes realizados pelos utilizadores, resultou uma anlise informao obtida, com o objetivo de poder concluir acerca do sucesso do sistema. A sntese desses resultados apresentada de seguida. Para testar o sistema tal como mencionado na subseco 5.1, foi elaborada uma pequena lista com onze tarefas, a serem executadas pelo utilizador, sendo retirados, para cada uma delas, os tempos de execuo, erros resultantes da ao dos utilizadores, as dvidas surgidas e todas as observaes que fossem necessrias. Assim sendo, segue-se a lista das onze tarefas que o utilizador teve que executar: 1. Abrir a aplicao e criar uma nova simulao. 61

2. Abrir a janela de configurao dos objetos da simulao. 3. Registar o objeto Aparafusadora na simulao. 4. Registar o objeto Carrinho na simulao. 5. Guardar o ficheiro de configurao dos objetos. 6. Abrir a janela de configurao da simulao. 7. Registar os estados da simulao/etapas a simular (CarrinhoNormal,

CarrinhoMovido, MaosLivres, AparafusadoraEquipada). 8. No Estado MaosLivres adicionar a ao do toque na Aparafusadora, e no Estado CarrinhoNormal adicionar a ao do toque no Carrinho. 9. No Estado CarrinhoNormal, a ao de toque no carrinho, configurada anteriormente, ter a restrio de ter que ter a aparafusadora equipada 10. No Estado MaosLivres, na ao do toque na Aparafusadora adicionar a resposta a esta ao. E no estado CarrinhoNormal na ao do toque no Carrinho adicionar a resposta a esta ao. 11.Guardar o ficheiro de configurao da simulao.

GRFICO 13 - ANLISE DOS TEMPOS DE EXECUO DAS TAREFAS

No Grfico 13 est presente o tempo mnimo, mximo e mdio resultante de todos os testes analisados para cada tarefa. Observando este grfico relativo anlise dos tempos de execuo de cada tarefa, pode-se concluir que mesmo existindo uma variao significativa entre o tempo mnimo e o mximo de cada tarefa, a oscilao entre eles idntica, ou seja, as tarefas mais demoradas, bem como as mais rpidas foram as mesmas quer para os tempos de execuo mnimos e mximos. Pode-se concluir ainda que no houve nenhuma tarefa em que

62

a mdia ultrapassasse os 80 segundos (1 minutos e 20 segundos), o que leva a acreditar que nenhuma tarefa era de carcter extremamente difcil ou complexo.

GRFICO 14 - ANLISE DAS DVIDAS QUE SURFIRAM NA EXECUO DAS TAREFAS

Como se pode observar no Grfico 14, em alguns dos testes no existiu qualquer dvida, pode se verificar ainda que o mximo de dvidas que houve relativamente a uma tarefa foram 2 e em uma nica tarefa, tendo ficado todas as tarefas com uma mdia de dvidas inferior a 0,5, podendo-se concluir tambm aqui que as tarefas no eram demasiado complexas e o prprio sistema no levantava grandes dvidas.

GRFICO 15 - ANALISE DOS ERROS PRATICADOS NA EXECUO DAS TAREFAS

Ao nvel dos erros cometidos pelos utilizadores na execuo das tarefas, tal como podemos observar no Grfico 15, praticamente no existiram em nenhuma tarefa, exceo

63

de duas, onde houve como mximo 1 erro cometido, este erro pode estar relacionado com alguma ansiedade por parte dos utilizadores. A quase inexistncia de erros vem mais uma vez provar que as tarefas no eram demasiado complexas e o prprio sistema no levantava grandes dvidas.

GRFICO 16 - CLASSIFICAO DO SISTEMA QUANTO FACILIDADE DE UTILIZAO

Como se pode observar no Grfico 16, no questionrio de satisfao, 9 utilizadores classificaram o sistema como fcil de utilizar, o que corresponde a 75% da amostra, havendo ainda 3 utilizadores que classificaram o mesmo como muito fcil de utilizar, o que corresponde a 25% da amostra.

GRFICO 17 - CLASSIFICAO DO SISTEMA QUANTO INTUITIVIDADE

Relativamente intuitividade do sistema, 8 utilizadores classificaram o mesmo como intuitivo, o que representa 67% da amostra, tendo ainda 2 utilizadores classificado como muito 64

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 Grfico 17.

GRFICO 18 - CLASSIFICAO DO SISTEMA QUANTO FACILIDADE DE APRENDIZAGEM

J quanto facilidade de aprendizagem, 7 dos utilizadores classificaram o sistema como fcil, o que corresponde a 58% da amostra, tendo ainda 4 utilizadores classificado o mesmo quanto aprendizagem como muito fcil, o que equivale a 34% da amostra, tendo apenas 1 utilizador que corresponde a 8% da amostra, classificado de difcil aprendizagem, como mostra o Grfico 18.

GRFICO 19 - CLASSIFICAO DO SISTEMA QUANDO FACILIDADE DE CRIAO DE CONTEDO

Como podemos observar no Grfico 19, todos os utilizadores acharam que, no mnimo, o sistema facilita a criao de contedo nos mundos virtuais 3D, sendo que 6 dos utilizadores responderam que facilita, o que corresponde a 50% da amostra, e os restantes 6 utilizadores 65

responderam que o sistema facilita muito a criao de contedo em mundos virtuais, o que equivale a 50% da amostra.

GRFICO 20 - CLASSIFICAO DO SISTEMA QUANTO A SER ACESSVEL A QUALQUER PESSOA QUE USE COMPUTADOR

Os utilizadores quando questionados sobre o sistema ser acessvel a qualquer pessoa que use frequentemente o computador, 5 deles responderam como sendo muito acessvel, o que corresponde a 41% da amostra, 4 responderam que era acessvel, o que corresponde a 42% da amostra, sendo que apenas 2 responderam que era pouco acessvel, o que equivale a 17% da amostra, como mostra o Grfico 20.

GRFICO 21 - CLASSIFICAO DO SISTEMA QUANTO AO POTENCIAL NA CRIAO DE SIMULAES

Como podemos observar no Grfico 21, todos os utilizadores acharam que este sistema tem potencial na criao de simulaes, sendo que 9 utilizadores responderam que achavam que o sistema tinha muito potencial, o que corresponde a 75% da amostra, e os 66

restantes 3 utilizadores responderam que achavam que o sistema tinha algum potencial, o que equivale a 25% da amostra.

GRFICO 22 - ANLISE DAS DIFICULDADES SENTIDAS

Quanto a terem sentido alguma dificuldade durante a realizao do teste, 8 dos utilizadores, o que corresponde a 67% da amostra, respondeu que no tinha sentido qualquer dificuldade, tendo apenas 4 utilizadores respondido que sentiram alguma dificuldade o que equivale a 33% da amostra, como mostra o Grfico 22.

GRFICO 23 - CLASSIFICAO DO TIPO DE DIFICULDADES

Como podemos observar no Grfico 23, dos utilizadores que anteriormente mencionaram ter sentido alguma dificuldade durante a realizao do teste, 3 deles responderam ter dificuldades relativas ao sistema apresentado, o que equivale a 75% dos

67

utilizadores que tiveram dvidas, e 1 utilizador responde ter dificuldades relativas ao mundo virtuais, o que equivale a 25% da amostra. No final das perguntas de escolha mltipla, do questionrio de satisfao, 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 opinies estavam relacionadas com melhorar a forma de como so registados os objetos no sistema, de modo a que o processo fosse um pouco mais automtico; uma outra melhoria sugerida era relativa interface grfica com que interagiram.

68

CAPTULO 6: CONCLUSES E TRABALHO FUTURO

We're changing the world with technology. Bill Gates

Neste captulo faz-se uma anlise ao cumprimento dos objetivos propostos para esta dissertao e procura-se aferir se trouxe ou no as contribuies esperadas. Por fim, termina com a referncia a possveis focos de trabalho futuro com base nas limitaes e necessidades existentes. 69

6.1

CONCLUSO

O objetivo primordial desta dissertao satisfazer a necessidade sentida pela FAP aquando a apresentao do prottipo mencionado na subseco 2.1, que consiste em o mecnico formador poder durante uma simulao alterar comportamentos de componentes em tempo real, de forma a analisar a reao dos formandos. Isto passava por desenvolver um prottipo de sistema capaz de possibilitar que o registo de componentes e comportamentos, pudesse ser efetuado de forma prtica e simples, atravs de uma interface acessvel a qualquer utilizador; sendo ainda objetivo desta dissertao a realizao de alguns testes com utilizadores. Pela anlise 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 no ter formao para os mesmos, e a maioria dos que mencionaram ter, no avaliarem a sua capacidade de os utilizar, como boa, seria uma mais-valia a realizao de testes mais aprofundados com utilizadores finais. Existe neste momento um prottipo funcional que cumpre os objetivos propostos, nomeadamente, a capacidade de registar componentes e comportamentos, de forma rpida e prtica atravs de uma interface grfica. Foi construdo, no apenas um sistema capaz de registar componentes e comportamentos relativos a esta rea da simulao de manuteno mecnica de motores de F-16, mas tambm capaz de ser aplicado a outras situaes, noutras reas, possibilitando a construo de situaes de simulao, rapidamente, sem a necessidade de programao especfica.

6.2

REFLEXES FINAIS

A nvel estritamente pessoal, tal como mencionado na seco introdutria, este projeto teve o seu incio em 2010, tendo eu estado sempre ligado desde ento equipa de investigao da UTAD associada a desenvolvimento em mundos virtuais. No tinha qualquer conhecimento ou preparao, pelo que tudo era novidade para mim. Sendo uma rea bastante interessante, desencadeou em mim uma grande motivao e uma grande energia para seguir em frente. Este projeto fez-me evoluir tanto como pessoa como a nvel profissional. Obrigou-me a abrir a mente e procurar solues de cariz tcnico onde supostamente no existiam, fazendo desta forma com que cimentasse todos os conhecimentos adquiridos durante o curso. 70

Embora esta dissertao tenha cumprido todos os objetivos definidos, existe a ambio de otimizar o produto desenvolvido e todas as funcionalidades associadas. Um dos aspetos a resolver so as melhorias apontadas pelos utilizadores na realizao 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 simulaes com algum grau de complexidade; alterar a interface de forma a simplificar ainda mais alguns processos, tornando assim a utilizao do sistema ainda mas intuitiva. Sendo este sistema destinado formao e sendo o Moodle o LMS usado pela FAP, a sua integrao com o sistema seria tambm de valor acrescentado. Assim, faria tambm sentido a produo de um relatrio de tudo o que feito pelos formando durante a simulao, e enviado para o Moodle de modo a ser consultado pelos seus responsveis. Seria ainda uma mais-valia tornar este sistema capaz de gerar toda a simulao, no apenas para o mundo virtual OpenSimulator, mas sim para qualquer ambiente grfico, onde um utilizador pudesse escolher qual o ambiente grfico onde queria que a simulao fosse realizada. A nvel do simulador seria de enorme valor acrescentar a inteligncia artificial para que os formadores possam treinar todo o processo, sem ser necessrio outras pessoas estarem presentes. J houve um colega com trabalho inicial nesta rea, dar-lhe seguimento representaria tambm uma mais-valia (Vilela, 2012).

71

REFERNCIAS BIBLIOGRFICAS
Amaral, I. A. (2008). A@ migrao para o Ciberespao: a Dimenso 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 multiuser 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.

73

Creutzfeldt, J., Hedman, L., Medin, C., Heinrichs, W. L., & Fellnder-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). Implementao de um Sistema de Formao para Mecnicos da Fora Area Portuguesa. (Mestrado), Universidade de Trs-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. Hmlinen, R., Manninen, T., Jrvel, S., & Hkkinen, 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.

74

Hew, K. F., & Cheung, W. S. (2010). Use of threedimensional (3D) immersive virtual worlds in K12 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&amp;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), 7982. 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 engineeringa 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 criao de movimentos de Andebol em Second Life para Formao 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 multiagent-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. Educao & Cultura Contempornea, 13 (6), 35-48. 75

Morgado, L. (2012). Caractersticas e desafios tecnolgicos dos mundos virtuais no ensino. Sumrio pormenorizado do seminrio apresentado no mbito de provas de agregao. Universidade de Trs-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 - Florianpolis, 6067. Neves, P., Zagalo, N., & Morgado, L. (2010b). Expressive Productivity in Videogames: Benefits from Applied Research in Normative Studies. Actas da 3 Conferncia de Cincias e Artes dos Videojogos, 99-108. OpenSimulator. (2012a). Open Wonderland Home. http://opensimulator.org/wiki/Main_Page OpenSimulator. (2012b). Sobre o OpenSimulator. http://opensimulator.org/wiki/PT Phillips, J., & Berge, Z. L. (2009). Second life for dental education. Journal of dental education, 73(11), 1260-1264. Pierzchaa, D., Dyk, M., & Szydowski, A. (2011). Distributed military simulation augmented by computational collective intelligence Computational Collective Intelligence. Retrieved 10708/2012, from Retrieved 10/08/2012, from

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 instalao de motor em aeronave F16. documento tcnico da disciplina Projecto da Licenciatura em Tecnologias de Informao e Comunicao. Universidade de Trs-os-Montes e Alto Douro. Vila Real. Pinto, I., & Teixeira, L. (2010b). Projecto de preparao de motores para instalao em aeronaves F16 - Desenvolvido para a Fora Area Portuguesa - Requisitos funcionais. documento tcnico da disciplina Projecto da Licenciatura em Tecnologias de Informao e Comunicao. Universidade de Trs-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. 76

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., Lpez, E. G., Cabot, A. G., de Marcos Ortega, L., & Strahonja, V. (2012). Performing Systematic Literature Review in Software Engineering. Vilela, A. (2012). Aplicao de agentes inteligentes capazes de desempenhar o papel de membros na execuo de trabalhos em equipa, em ambiente virtual 3D OpenSimulator. (Mestrado), Universidade de Trs-os-Montes e Alto Douro, Vila Real. Vilela, A., Marques, A., Costa, H., Rafael, J., Prada, R. F. F., & Morgado, L. (2012). Aplicao de avatares autnomos para desempenhar o papel de membros na execuo 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), 2633.

77

ANEXOS

79

Anexo 1
Testes de Utilizao ____________________________________________________

O teste de utilizao que se ir realizar, enquadra-se no mbito do protocolo entre a Universidade de Trs-os-Montes e Alto Douro e a Fora Area Portuguesa, com vista ao desenvolvimento de um simulador 3D para o treino de mecnicos na instalao de motores em aeronaves F-16. Este teste tem como objetivo avaliar a utilizao do sistema de edio de componentes e estados desenvolvido, com vista aferio de dificuldades, limitaes e (des)vantagens do mesmo para incrementao de melhorias. O teste ser aplicado a voluntrios que se ofereceram para efetuar a realizao do mesmo. A recolha de dados ser feita com recurso a diferentes tcnicas e instrumentos de recolha, nomeadamente observao e questionrio. A confidencialidade dos dados garantida. Pede-se autorizao para a captura, anlise e utilizao dos mesmos no mbito do protocolo suprarreferido, com vista aos objetivos enunciados.

80

Termo de Consentimento
_____________________________________________________________________

Afirmo que participarei por minha prpria vontade nos testes de utilizao e que fui informado(a) dos objetivos dos mesmos. Fui igualmente informado(a) dos mtodos de recolha de dados utilizados para o efeito. Fui ainda informado(a) que fica salvaguardada e assegurada a confidencialidade das informaes concedidas e recolhidas, restringindo-se a sua utilizao ao trabalho no mbito do protocolo estabelecido entre a Universidade de Trs-os-Montes e Alto Douro e a Fora Area Portuguesa, nomeadamente em eventuais futuros trabalhos de produo cientfica, que a ocorrerem tero sempre lugar sem divulgao das fontes.

Vila Real, 21 de Outubro de 2013, O utilizador:

_______________________________

Investigador Andr Pinheiro

Mestrado em Engenharia Informtica (UTAD)

81

Anexo 2

Questionrio de caracterizao do perfil

O presente questionrio visa aferir o perfil dos utilizadores que integram o teste de utilizao ao sistema de edio de componentes e estados para o simulador de manuteno mecnica de motores de F-16, construdo ao abrigo do protocolo estabelecido entre a Universidade de Trs-os-Montes e Alto Douro e a Fora Area Portuguesa. Pretende-se aferir o conhecimento dos utilizadores em mundos virtuais e experincias prvias neste tipo de ambientes.

Pede-se que o utilizador leia atentamente cada questo, escolhendo a opo que melhor se adequa sua resposta atravs de uma cruz (X). Agradecemos a sua colaborao. _____________________________________________________________________

Parte I - Utilizao do computador

1. Usa computador? Sim No

NOTA: Para esta questo poder apenas responder a uma alternativa. Se respondeu No acima, siga para a Parte II do questionrio.

2. Com que frequncia usa computador?

Diariamente (1 vez por dia) Diariamente (vrias vezes por dia) Semanalmente ( de 1 a 6 vezes por semana)

NOTA: Para esta questo poder apenas responder a uma alternativa

82

3. Utiliza o computador com a finalidade de: Socializao Pesquisa de informao Partilha de informao Formao Trabalho Entretenimento Outra: ______________________________________________________________ NOTA: Para esta questo poder responder a mais do que uma alternativa.

Parte II - Utilizao de mundos virtuais 3D

4. Conhece algum mundo virtual 3D? Sim No

NOTA: Para esta questo poder apenas responder a uma alternativa. Se respondeu No acima siga para a Parte III do questionrio.

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 questo poder responder a mais do que uma alternativa.

83

4.2 J utilizou algum mundo virtual 3D? Sim No

NOTA: Para esta questo poder apenas responder a uma alternativa. Se respondeu No acima siga para a Parte III do questionrio.

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 questo poder responder a mais do que uma alternativa.

4.4. Para que finalidade utilizou esse(s) mundo(s) virtual(ais): Socializao Pesquisa de informao Partilha de informao Formao Trabalho Entretenimento Outra:

_____________________________________________________________________ NOTA: Para esta questo poder responder a mais do que uma alternativa.

5. J obteve algum tipo de formao para a utilizao de mundos virtuais 3D? Sim No

NOTA: Se respondeu No acima siga para a Parte III do questionrio.

84

5.1 Para qual(ais) mundo(s) virtual(ais) 3D obteve essa formao? Opensimulator Second Life Active Worlds Cyberworlds Coke Studios Dreamville Outro:

__________________________________________________________ NOTA: Para esta questo poder responder a mais do que uma alternativa.

5.2. Como classifica a sua capacidade de utilizao de mundos virtuais 3D? Muito M Medocre Boa Muito Boa

NOTA: Para esta questo poder apenas responder a uma alternativa.

6. J obteve algum tipo de formao para a programao em mundos virtuais 3D? Sim No

NOTA: Se respondeu No acima siga para a Parte III do questionrio. 6.1 Para qual(ais) mundo(s) virtual(ais) 3D obteve essa formao? Opensimulator Second Life Active Worlds Cyberworlds Coke Studios Dreamville Outro:

__________________________________________________________ NOTA: Para esta questo poder responder a mais do que uma alternativa.

85

6.2. Como classifica a sua capacidade de programao em mundos virtuais 3D? Muito Boa Boa Medocre Muito M

NOTA: Para esta questo poder apenas responder a uma alternativa.

Parte III - Dados demogrficos

7. Sexo: Feminino Masculino

8. Idade: ________ anos

Obrigada pela participao!

86

Anexo 3

Questionrio Satisfao

Tento em conta o teste que realizou no sistema de edio de componentes e estados para o simulador de manuteno mecnica de motores de F-16, responda s seguintes questes relativamente sua experincia de utilizao do software:

Pede-se que o utilizador leia atentamente cada questo, escolhendo a opo que melhor se adequa sua resposta atravs de uma cruz (X). Agradecemos a sua colaborao. _____________________________________________________________________

1. Como classifica o sistema quanto facilidade de utilizao? Muito Difcil Difcil Fcil Muito Fcil

2. Como classifica o sistema em relao sua intuitividade? Muito Intuitivo Intuitivo Pouco Intuitivo Nada Intuitivo

3. Como classifica o sistema em termos de facilidade de aprendizagem? Muito Fcil Fcil Difcil Muito Difcil

4. Acha que este sistema facilita a criao de contedo nos mundos virtuais 3D? No Facilita Facilita Pouco Facilita Facilita Muito

87

5. Acha este sistema acessvel a qualquer pessoa que use frequentemente computadores? Muito Acessvel Acessvel Pouco Acessvel Nada Acessvel

6. O que acha do potencial deste sistema na criao de simulaes? Nenhum Pouco Algum Muito

7. Sentiu alguma dificuldade? Sim No

7.1. Se sim, foi relativo ao:

Mundo Virtual Sistema em si Ambas

8. Que melhorias poderiam ser adicionadas no sistema? _____________________________________________________________________________ _____________________________________________________________________________ _____________________________________________________________________________ _____________________________________________________________________________ ________________________________

Obrigada pela participao!

88