Usando Cenários Para Identificar os Requisitos de Design de Ambientes Virtuais

1. Usando Cenários Para Identificar os Requisitos de Design de Ambientes Virtuais Apresentado por: Márcio Bueno Disciplina: Realidade Virtual e Multimídia

2. Sumário • Motivação • Introdução • Visão Geral • Requisitos de AV • Modelagem de Cenário • Análise de Requisitos • Interpretando os Requisitos • Ferramenta de Suporte: Primrose • De Requisitos para Design • Conclusões / Referências

3. Motivação • Projetar de Ambientes Virtuais (AV) é difícil, dada a característica de cada aplicação ser única. • A preocupação é normalmente simular o fenômeno do mundo real dentro das limitações de tecnologia de AV. • Requisitos precisam ser cuidadosamente considerados para a realização de tradeoff entre o que é requerido por um ambiente e o que pode realmente ser alcançado.

4. Motivação • Tipicamente, o processo usado para chegar no design é iterativo de prototipação e teste. • Contudo, o desenvolvedor não tem uma representação inicial de quais são os requisitos reais para um ambiente.

5. Introdução • Durante o processo de design de AV os desenvolvedores precisam realizar tradeoffs entre: • Requisitos Ideais; • Limitações Tecnológicas do AV. • O ponto chave para realizar estes tradeoffs com sucesso é manter os aspectos do ambiente que são críticos para os requisitos enquanto negligencia os que não são.

6. Introdução • A descoberta de que um AV satisfaz os requisitos é feita através de uma avaliação pós-implementação com os usuários finais. • Se o projetista não tem uma clara idéia do que estes requisitos são inicialmente, precisará de muitas ciclos de prototipação até que se chegue num design apropriado. • Pior ainda, utilizando apenas prototipação existe o risco de limitar o design de um AV com restrições do ambiente de implementação.

7. Visão Geral • A abordagem apresentada aqui suporta a modelagem de requisitos para um AV. • Isto é alcançado através da descrição de cenários utilizando diagramas de transição de estados. • Estes cenários são informalmente analisados e os fatores chaves que afetam os requisitos são capturados numa “árvores de requisitos”.

8. Visão Geral • Esta árvore de requisitos pode ser usada para projetar uma implementação e expor quaisquer tradoffs que precisem ser feitos. • O tradicional ciclo de prototipação pode então refinar estas decisões e suportar o teste com os usuários.

9. Requisitos de AV • Serão considerados quatro importantes requisitos que precisam ser examinados quando projetando um AV: • Aparência do Objeto • Decomposição do Objeto • Comportamento do Objeto • Comportamento do Usuário

10. Requisitos de AV Aparência do Objeto • A aparência de um objeto leva a implicações de performance tanto para o usuário quanto para o ambiente. • Devido a limitações tecnológicas, performance é reduzida à medida que a qualidade de renderização é aumentada. • Isto pode levar a uma restrição de usabilidade. • Requisitos de aparência precisam definir cuidadosamente o nível de renderização de cada objeto num AV.

11. Requisitos de AV Decomposição do Objeto • Um objeto do ambiente pode ser puramente estético, ou pode evoluir durante o tempo de vida do ambiente. • A maneira que um objeto precisa se comportar determina quais primitivas o objeto precisa ser decomposto.

12. Requisitos de AV Comportamento do Objeto • Se um objeto evolui durante o tempo de vida do ambiente, existem questões sobre como o objeto se comporta e os triggers que causam o comportamento. • O comportamento de um objeto pode ser realizado de várias maneiras. Por exemplo, podemos implementar como um evento discreto ou contínuo.

13. Requisitos de AV Comportamento do Usuário • AV são, por natureza, dirigidos por usuários. • Um dos grandes desafios de design de AV é prover o usuário com técnicas de interação que facilitem os requisitos da aplicação. • A diversidade de AV é tal que não existe padrões de-facto e técnicas de interação precisam ser moldadas cuidadosamente na visão dos requisitos.

14. Modelagem de Cenário • O uso de cenários é comum no design de sistemas interativos, pois eles forçam o projetista a considerar apropriadamente o design. • Embora o uso de cenários é uma prática aceitada para testar requisitos detalhados, também pode ser utilizado para entender requisitos informais e especificá-los inicialmente, quando são menos entendidos.

15. Modelagem de Cenário • O processo consiste em desenvolver cenários de tarefas do usuário para elicitar requisitos sobre o domínio em estudo. • Desenvolvimento de cenários é um exercício útil, pois ele expõe a faixa de possíveis interações e revela facilidades que podem ser necessárias. • Cenários provêm uma rica fonte de material para a construção de especificações de comportamento.

16. Modelagem de Cenário • Desenvolvendo cenários, podemos focar em comportamentos concretos de componentes do nosso AV, e ao mesmo tempo, podemos capturar requisitos “reais” necessários para o design. • Como cenários são descrições informais de eventos, muitas representações podem ser utilizadas para modelá-los. Neste contexto, será utilizado diagramas de transição de estados.

17. Modelagem de Cenário O usuário está sentado na sua mesa O usuário está de pé na janela O usuário anda para a janela O usuário abre a janela A janela está aberta

18. Análise de Requisitos • Depois de modelar cenários, eles são analisados para determinar como o seu conteúdo influencia os quatro tipos de requisitos de um AV discutidos. • Este processo é informal, mas o resultado da análise, os requisitos do AV, são estruturados usando a “árvore de requisitos” (AR). • Antes da análise, existem dois nós na AR: o ambiente (raiz) e o usuário que é um ramo da raiz.

19. Análise de Requisitos • O relacionamento entre um nó pai e um filho na AR deve ser lido como “consiste de”. • Assim, inicialmente um ambiente consiste de um usuário. • Existem dois tipos de nós que podem ser adicionados à AR durante a análise dos cenários: • Nós Objetos – que descrevem objetos físicos no AV • Nós Comportamentais – que descrevem o comportamento de um objeto ou interação do usuário.

20. Análise de Requisitos • Para cada objeto adicionado à AR é necessário definir o seu papel no AV: • Background - não são críticos para o cenário • Contextual - são parte do cenário, mas não o foco. • Task - são centrais para o cenário. • Durante o processo de analisar um cenário, pode acontecer de um objeto ser inicialmente ser descrito como uma abstração, e a medida que o cenário desenvolve, seja evoluída para outra.

21. Análise de Requisitos • O processo de analise dos cenários, para construir a AR, inicia no começo de cada cenário e, para cada estado e transição, considera-se como estas descrições influenciam os requisitos.

22. Análise de Requisitos

23. Interpretando os Requisitos • Mesmo para um simples cenário a AR é uma rica descrição dos requisitos em um AV. • O processo de transferir o conhecimento a partir dos cenários para a AR remove a ordem estipulada nos cenários individuais, e coleta as informãções pertinentes ao fenômeno comum (i.e., o comportamento do usuário). • Isto significa que um ambiente suportando os requisitos da AR, enquanto facilita os cenários, não é restringido por eles.

24. Interpretando os Requisitos • Em termos da Aparência do Objeto, a AR define a importância relativa de cada objeto no AV (background, contextual ou task). • A decomposição do objeto está bem definida na AR. • Apesar do comportamento dos objetos e do usuário serem menos concretamente definidos do que os outros aspectos do AV, a AR dá uma indicação clara de que objetos devem suportar que comportamentos e quais devem ser suportados pela interação do usuário.

25. Ferramenta de Suporte: Primrose

26. De Requisitos para Design • Usando o processo descrito, e a ferramenta Primrose, os quatro tipos de requisitos podem ser determinados. • O próximo passo é fazer o design do sistema para acomodar estes requisitos. • Isto pode ser realizado da maneira tradicional, onde a aparência dos objetos e suas decomposições são modeladas usando ferramentas 3D como 3DStudio, e os comportamentos são adicionados usando códigos de implementação.

27. De Requisitos para Design • Por exemplo, enquanto a aparência de uma janela pode ser comparada a fotografia de uma janela, não temos a mesma facilidade em relacionar comportamento de abrir uma janela com os requisitos. • Uma abordagem alternativa é fazer o design do comportamento usando também abstrações orientadas a requisitos.

28. De Requisitos para Design • O formalismo Flownets foi projetado para este propósito e se baseia na filosofia que o comportamento de um AV deve ser modelado como um híbrido de componentes contínuos e discretos. • Flownets suportam a descrição do comportamento tanto do usuário, quanto dos objetos.

29. De Requisitos para Design • Uma vez usando uma ferramenta 3D e o comportamento do AV ter sido projetado usando Flownetes, é necessário prototipar o design. • Apesar do processo cuidadoso de descrever os requisitos, e fazer o desining do AV para satisfazer os requisitos, é provável que tenha iterações no processo de prototipação.

30. De Requisitos para Design • O Marigold toolset suporta o processo de rapidamente mover de modelos 3D e designs Flownet para um implementação. • O módulo de geração de código do Marigold cria código Maverick/C, entretanto o Marigold é independente de qualquer implementação específica. • Marigold também suporta verificações limitadas da especificação Flownet.

32. Ex. Flownet

33. Ex. Flownet

34. Conclusões • Motiva a necessidade de design orientado a requisitos de AV. • Através da construção de cenários, os requisitos são capturados e armazenados de uma forma coerente e útil na estrutura de AR. • Requisitos podem ser utilizados para guiar o processo de design utilizando o Marigold toolset.

35. Referências • James S. Willans, Michael D. Harrison and Shamus P. Smith, Using scenarios to identify the design requirements of virtual environments, Technical report YCS 333, University of York, 2001. • James S. Willans and Michael D. Harrison, A toolset supported approach for designing and testing virtual environment interaction techniques, International Journal of Human-Computer Studies, 55(2), pp. 145-165, 2001.

36. Referências • Shamus Smith and David Duke, "Virtual environments as hybrid systems", Proceedings of Eurographics UK 17th Annual Conference: EG-UK99, Cambridge, UK : Eurographics UK Chapter.