Usando Cenários Para
Identificar os Requisitos de
Design de Ambientes Virtuais
Apresentado por:
Márcio Bueno
Disciplina:
Realidade Virtual e Multimídia
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
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.
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.
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.
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.
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”.
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.
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
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.
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.
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.
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.
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.
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.
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.
Modelagem de Cenário
O usuário está
sentado na
sua mesa
O usuário anda
para a janela
O usuário está
de pé na
janela
O usuário
abre a janela
A janela
está aberta
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.
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.
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.
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.
Análise de Requisitos
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.
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.
Ferramenta de Suporte: Primrose
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.
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.
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.
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.
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.
Ex. Flownet
Ex. Flownet
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.
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 HumanComputer Studies, 55(2), pp. 145-165, 2001.
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.