Recherche de solutions

A avaliação sobre as reais necessidades dos profissionais de saúde em

frameworks baseados em RV mostrou que a maioria da amostra tem interesse em utilizar

sistemas em RV independente de qual seja. Mas, outra parte dos entrevistados afirmou que só utilizaria esse mesmo tipo de sistema se fosse de fácil interação. Portanto, para atender a todos os perfis dos usuários de saúde avaliados, foi definido que o SPV deve:

a) ser um sistema de criação de aplicações em RV para área de saúde; b) ter uma interface visual baseada nos princípios de usabilidade e PV; c) ser um sistema de execução de aplicações em RV para saúde;

43 d) permitir que o usuário de saúde crie suas próprias aplicações em RV;

e) permitir que o usuário salve as suas aplicações visuais(ou fluxogramas); f) permitir que o usuário abra as aplicações visuais salvas;

g) permitir que as aplicações sejam montadas apenas pelo modo gráfico;

h) ser um SPV compatível com diversos frameworks em RV para área de saúde; i) gerar um código computacional genérico, ou seja, uma linguagem de

programação como resultado final que possa ser compatível com frameworks de RV.

Além de o SPV prover a criação e a execução de aplicações com recursos em RV, o sistema tem como funcionalidades: abrir e salvar aplicações visuais(fluxogramas), garantir que aplicação final seja válida em termos de parâmetros e relacionamentos, gerar um código-fonte genérico da aplicação visual criada, gerar um arquivo de registro sobre as ações do usuário, ser compatível com diversos frameworks da área de saúde, mostrar mensagens de feedback e de dicas do sistema para o usuário. Com relação às funções do usuário no SPV, é importante ressaltar que ele deve:

a) interagir com o sistema baseado em PV;

b) compreender a função dos componentes que compõem a aplicação visual; c) inserir parâmetros de configuração dos componentes pelo modo gráfico; d) visualizar registros de suas ações pelo modo gráfico;

e) salvar a aplicação visual;

f) abrir uma aplicação visual salva;

g) entender as mensagens de comunicação com o usuário e de dicas do sistema; h) executar a aplicação visual.

Além do levantamento das funcionalidades, é necessário realizar uma definição formal dos requisitos funcionais do CyberMedVPS. Tais requisitos podem ser vistos no Quadro 3, que se baseia na norma NBR:ISO/IEC 9126, que pode ser usada para especificar requisitos funcionais e não-funcionais do cliente e do usuário.

44 Quadro 3. Requisitos funcionais do Sistema de Programação Visual.

Funcionalidade que gera aplicações computacionais baseadas em RV para usuários O SPV será um sistema de desenvolvimento de aplicações visuais da área de saúde

Usabilidade Apresentará recursos baseados nos princípios do design de interface _{e adotará técnicas de PV} Confiabilidade O SPV é capaz de validar as aplicações visuais montadas

Eficiência O sistema deve responder as ações do usuário em tempo de _execução

Manutenabilidade As modificações realizadas pelo usuário serão executadas apenas _{pelo modo gráfico}

Portabilidade O SPV será compatível com diversos frameworks que geram _{aplicações em RV e será multiplataforma}

Em relação aos requisitos não-funcionais do sistema, há um ponto que pode ser ressaltado: a) o SPV deve ser multiplataforma. Assim, o Sistema Operacional (SO) não é um problema adicional durante o processo de desenvolvimento de aplicações em RV pelo usuário no SPV.

3.4 Arquitetura do SPV

Para o SPV ser compatível com diversos frameworks baseados em RV e da área de saúde, foi preciso que sua arquitetura garantisse dois pontos fundamentais. São eles:

a) a interação com frameworks de RV deve ser um processo imperceptível para o usuário que utiliza o SPV, ou seja, a lógica de desenvolvimento da aplicação visual será a mesma para o usuário independentemente de qual framework baseado em RV que o SPV esteja utilizando;

b) todo o processo de desenvolvimento e execução da aplicação visual deve ocorrer apenas pelo modo gráfico, por meio de PV.

Além dos aspectos relatados, foi imprescindível garantir o desacoplamento da estrutura do SPV com os frameworks em RV. Portanto, foi definido que a arquitetura de PV é formada por dois módulos principais: a Camada de Visualização e a Camada de Comunicação. A arquitetura dessas camadas pode ser vista na Figura 22 e adotou o modelo arquitetural baseado em camadas.

45 Figura 22. Arquitetura do SPV.

Fonte: Morais e Machadoa, 2011, pg 5.

A Camada de Visualização é a única camada na qual o usuário tem contato direto no SPV. Todas as interações de entrada e saída do SPV com o usuário ocorrem nesse módulo. Além disso, é nessa camada que a estrutura de PV está implementada e onde a aplicação visual será montada pelo usuário. Vale ressaltar também que o modelo de padrão de projeto utilizado na camada de Visualização foi o MVC,que é um padrão de projeto de software que isola a parte lógica, da UI . Esse padrão foi escolhido devido a características como o isolamento entre a interface visual e o domínio lógico, para garantir a flexibilidade do sistema.

A outra camada é chamada de Camada de Comunicação. Esse módulo é responsável por traduzir a aplicação visual em uma linguagem computacional genérica. Além disso, tem como função habilitar a comunicação desse código com o framework de RV. Todo esse processo descrito ocorre de modo transparente para o usuário durante a execução do SPV. Como mostra a Figura 22, a Camada de Comunicação é subdividida em dois pacotes internos:

a) camada de Validação: essa camada garante que a aplicação visual, gerada por PV, tem seus parâmetros e operações validados e é traduzida em uma linguagem genérica pelo SPV;

b) camada de Montagem: nessa camada, a linguagem genérica é traduzida e tem seus parâmetros disponibilizados para geradores de código-fonte que obedecem à sintaxe dos frameworks em RV.

A camada do framework refere-se ao framework que geram aplicações em RV e aos componentes responsáveis por gerar o código-fonte de sintaxe compatível com tais

46

frameworks em RV. Dessa forma, esse código-fonte gerado é utilizado na execução final

da aplicação em RV.

Algumas restrições arquiteturais foram previstas no SPV. A primeira delas é se o usuário quiser inserir dados, por meio de linguagem de programação, dentro da aplicação de RV, usando o SPV. Essa ação não é permitida, pois um dos requisitos previstos nesta arquitetura é que todo o processo de desenvolvimento seria utilizando apenas PV. A única solução forma de realizar essa ação seria acessando diretamente o código-fonte da aplicação em RV sem intermédio do SPV.

As outras limitações arquiteturais dizem respeito às restrições dos próprios

frameworks de RV, como por exemplo, se o framework não é multiplataforma ou se ele

não possui suporte de algum recurso em RV (sensibilidade háptica, estereoscopia, colisão, deformação, por exemplo). As soluções para essas restrições foram realizar um estudo prévio das limitações do framework utilizado e a tentativa de correção, quando for necessário.