Perceived Academic Pressure - Instruments for Independent Variables

2. Methods

2.5 Independent Variables

2.5.1 Instruments for Independent Variables

2.5.1.5 Perceived Academic Pressure

Como foi explicado, na seção anterior, a camada de visualização serve para o usuário montar a aplicação visual baseada em RV apenas por PV. A proposta do CyberMedVPS é que o resultado final do SPV gere algo computacionalmente válido para

frameworks com recursos baseados em RV. Com base nessa necessidade, foi projetada

a camada de comunicação que tem como objetivo solucionar o problema do diálogo entre os frameworks em RV e a aplicação visual gerada no SPV. Portanto, a camada de comunicação será a ponte de comunicação entre a camada de visualização e os interpretadores dos frameworks.

De acordo com a Figura 38, a camada de visualização é subdividida em duas partes: a camada de validação e a camada de montagem. A camada de validação (Figura 38a) refere-se às classes responsáveis por garantir que as informações geradas na codificação da aplicação visual para aplicação computacional estejam válidas para

65 execução. A camada de montagem (Figura 38b) é responsável por interpretar a aplicação computacional e disponibilizar os parâmetros definidos pelos usuários para os interpretadores dos frameworks em RV.

Figura 38. Classes que compõem a Camada de Comunicação do CyberMedVPS.

O processo de codificação da aplicação visual para aplicação computacional ocorre a partir das informações registradas nas classes Object, Scene, HapticScene,

Interator, Collision e View que correspondem às características de cada objeto da

aplicação visual. Todas essas classes estão associadas à classe ManagerXML que solicita os métodos de leitura de cada um dos componentes associados (Figura 39). Esses métodos de leitura (readObj, readSce, readHap, readInt, readCol e readVie) são responsáveis por avaliar a legitimidade do valor atribuído pelo usuário para determinado objeto.

Figura 39. Diagrama de classes da camada de validação.

Se o usuário definir um valor que não seja condizente com o atributo do componente relacionado, a classe ManagerXML, por meio do método writeData (Figura 39), é responsável por atribuir um valor padrão para tal característica do componente em

(a)

66 análise. Vale salientar que esse processo acontece por meio de uma avaliação individual de cada componente da aplicação visual. Após a validação, o método writeData fica responsável por codificar todas as informações em uma linguagem computacional.

A codificação tem como resultado uma linguagem computacionalmente genérica e compatível com interpretadores para frameworks baseados em RV. Baseado nisso, a linguagem escolhida para aplicação genérica foi o XML, devido a fatores como: a) ser uma linguagem de marcação com licença de código aberto, b) possuir integração de dados de diferentes fontes, c) ter escalabilidade, d) ser manipulada por diversas APIs na linguagem Java e e) separar o conteúdo da formatação (SALMINEN e TOMPA, 2011) (SCHNEIDER e GIBSON, 2008).

Quadro 4. Gramática do XML gerada pelo CyberMedVPS.

< ?xm l version= "1.0" encoding= "UTF- 8" st andalone= "no" ?>

< /m odel> <visual_scene>

< /inst rum ent> <collision>

< /collision> <hapt ic_scene> <t ype> < /t ype> < /hapt ic_scene> <exhibit ion> <nam e> < /nam e> < /exhibit ion> < /com ponent>

(a)

(b)

(c)

(d)

(e)

(f)

67 A estrutura adotada no XML do CyberMedVPS é composta por sete tags diferentes, como pode ser na gramática do Quadro 4. Essas tags obedecem à especificação dos componentes definida na aplicação visual. O principal elemento é a tag

component que indica as configurações de uma aplicação visual. Dentro dessa tag,

existem seis tipos de informações no XML do CyberMedVPS.

A primeira tag interna refere-se ao model e tem como função informar as características do objeto visual Modelo. Além disso, essa tag pode aparecer mais de uma vez na aplicação visual, por isso precisa ser identificada por número de identificação (ID). As subtags relacionadas à tag model (Quadro 4a) refere-se a informações sobre opções de rotação e translação do modelo dentro do ambiente virtual, no eixo x, y e z, e a localização do arquivo que representa o modelo.

A segunda tag refere-se ao visual_scene, que corresponde ao objeto Ambiente Visual da aplicação visual. As subtags relacionadas à tag model (Quadro 4b) refere-se a informações sobre a posição do modelo dentro do ambiente virtual, no eixo x, y e z, e o tipo de visualização do modelo.

Em seguida, é descrita a tag instrument que possui informações do Instrumento como, por exemplo, o tipo de interação e em qual objeto o Instrumento está vinculado pelo ID. As subtags relacionadas ao instrument (Quadro 4c) referem-se a informações sobre o tipo de dispositivo de interação e o arquivo do modelo virtual que representa o instrumento.

A quarta tag, chamada de collision refere-se ao objeto Toque e também é identificado por um número ID para identificar qual instrumento exerce ação sobre qual modelo. Suas subtags (Quadro 4d) referem-se ao tipo de deformação e ao tipo de colisão que devem ser oferecidas.

A seguir, surge a tag haptic_scene que se refere ao objeto Ambiente Tátil. Suas

subtags (Quadro 4e) referem-se a um tipo de dispositivo de interação não-convencional.

E, por fim, existe a tag chamada de exhibition que é responsável pelas informações finais da aplicação visual e representa o objeto Exibição. A subtag relacionada ao exhibition (Quadro 4f) refere-se ao nome da janela da aplicação em RV.

Vale ressaltar que o objeto Agregador não possui uma tag que o descreva diretamente na linguagem genérica (XML) porque se trata de um componente lógico, ou seja, ele é responsável por atribuir as mesmas características de toque, de deformação, por exemplo, a diversos frameworks. Assim, tal objeto não apresenta parâmetros distintos, mas replica características para quem estiver vinculado ao mesmo.

68 O conjunto de bibliotecas nativas do pacote javax.xml.* foi responsável pela montagem da estrutura do XML na classe ManagerXML do CyberMedVPS. Para gravação foi necessário apenas instanciar uma classe nativa chamada de

DocumentBuilderFactory que é responsável por inserir os dados no arquivo de extensão

“.xml”. No processo de leitura foi criado o método readData que tem como atributo o nome da tag e a característica pesquisada. Após concretizar a criação do arquivo XML com as configurações na aplicação visual, é necessário habilitar a camada de montagem classes que entendam a linguagem genérica e consigam codificar essas informações para um interpretador para framework em RV.

Portanto, é possível inferir que a camada de comunicação passa por dois processos distintos de transformação de linguagem: o primeiro ocorre na camada de validação e serve para traduzir a aplicação visual em aplicação genérica (XML) (Figura 40a). E o segundo processo ocorre por meio da codificação de uma aplicação genérica em outra linguagem computacional previamente definida (Figura 40b), ou código fonte.

Figura 40. Dinâmica das linguagens no CyberMedVPS.

Na camada de montagem foram criadas duas classes de leitura. A primeira é uma classe tradutora para frameworks baseados em RV que são compatíveis com a linguagem C e C++ chamada de TranslaterCpp. A outra é uma classe tradutora, chamada de

TranslaterJava, compatível com frameworks implementados na linguagem Java.

O processo de tradução na camada de montagem se inicia a partir do momento em que uma dessas classes de codificação chama o método de leitura readData da classe ManagerXML. Cada leitura armazena os parâmetros obtidos em variáveis estáticas públicas da classe do tradutor.

Após o processo de tradução no CyberMedVPS, as classes de interpretação, externas ao SPV, definem as bibliotecas que são utilizadas no código final das aplicações compatíveis ao framework em RV. Dessa forma, é preciso solicitar variáveis públicas adequadas, que estão dentro dos tradutores, para executar a montagem da aplicação final em linguagem de programação quando classes interpretadoras e externas ao CyberMedVPS precisarem se comunicar com os tradutores da camada de montagem.

(b)

(a)

Tradutor

_{Interpretador}

CyberMedVPS Externo ao CyberMedVPS

In document The psychosocial predictors of psychological distress and life satisfaction in a cohort of Norwegian students (sider 31-0)