29、交互式虚拟环境的基于模型的设计方法与工具

prometheus9mon

于 2025-10-22 10:20:00 发布

阅读量19

点赞数

CC 4.0 BY-SA版权

分类专栏：交互设计的跨学科探索文章标签：交互式虚拟环境基于模型的设计 ConcurTaskTree

本文链接：https://blog.youkuaiyun.com/prometheus9mon/article/details/153871718

交互设计的跨学科探索专栏收录该内容

32 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

交互式虚拟环境的基于模型的设计方法与工具

1 现有工具挑战与设计要求

在虚拟和增强现实开发领域，现有的开发工具包缺乏明显的共同特征。当前开发工具面临的主要问题是种类繁多，每个工具包都专注于最终应用的特定部分，导致多个工具包的组合使用并不容易，一个工具的输出往往不能直接作为另一个工具的输入。因此，将多个设计问题集成到同一个工具中十分重要。

在设计过程方面，面临着定义正式流程和实现快速原型设计的挑战，以便能够快速试验用户界面的不同变体。

综合设计过程和开发工具的优势与需求，基于模型的设计过程和支持工具应满足以下要求：
1. 渐进式发展 ：从抽象的（用户任务）描述和高级模型逐步演变为具体的界面和低级代码。
2. 迭代性 ：生成并评估原型用户界面后，设计师应能够修改模型并重新生成界面。
3. 交互技术设计 ：由于交互式虚拟环境（IVE）包含多种直接操作技术，应能够通过额外的描述模型来设计这些交互技术，即交互描述模型（IDM）。
4. 代码自动生成 ：为了让非程序员也能使用，该过程应能自动生成所描述的IVE的代码。
5. 手动编辑代码保留 ：在某些模型修改后重新生成代码时，必须保留手动编辑的代码。
6. 图形工具支持 ：为了便于使用，应提供图形工具支持和辅助，以设计高级描述模型并检查其正确性。

2 基于模型的IVE开发过程

2.1 任务模型创建

基于上述需求，提出了一种基于模型的IVE设计和开发方法。该过程的第一步是创建IVE的任务模型，使用ConcurTaskTree（CTT）符号来完成。CTT符号由Paternò提出，是一种广泛使用的符号，采用图形语法，具有层次结构，并支持指定任务之间的时间关系。

CTT符号支持四种类型的任务：
1. 应用任务 ：完全由应用程序执行的任务。
2. 用户任务 ：由用户执行的任务，通常是重要的认知活动。
3. 交互任务 ：用户通过某些交互技术与系统进行交互的任务。
4. 抽象任务 ：需要复杂活动且执行方式无法明确分配的任务。

在CTT的分解层次结构中，同一级别的兄弟任务可以通过时间运算符（如选择（ [] ）、启用（ >> ）、禁用（ [> ））连接。

由于是设计交互式虚拟环境，将重点关注应用程序中的交互任务。例如，在CTT的叶节点中，对象选择是一种交互任务。在2D用户界面中，用户通过鼠标从给定列表中选择项目是一项简单的任务；但在IVE中，由于虚拟环境中的交互技术不限于键盘和鼠标输入，这项任务变得更具挑战性。常见的选择技术包括抓取、射线投射和gogo选择等。

2.2 交互描述模型

由于3D环境中大多数交互任务的复杂性，建议使用图形符号来更详细地描述这些交互技术。将交互描述模型（IDM）附加到CTT中的交互任务有两个优点：
1. 设计灵活性 ：IDM为交互任务提供了更改所使用的交互技术的可能性，而无需调整任务模型或设计过程中的任何其他模型。
2. 设计相似性 ：通过使用IDM定义特定的交互任务，IVE的任务模型设计变得与2D用户界面的设计相似。

2.3 对话模型提取

设计好任务模型后，可以使用Luyten等人描述的算法从CTT中自动提取应用程序的对话模型。对话模型基于从应用程序任务模型派生的启用任务集（ETS）。ETS被定义为“在同一时间段内逻辑上可以开始执行的一组任务”。生成的ETS可以映射到不同的应用程序状态，每个状态包含在该状态下可以执行的所有交互任务。应用程序状态之间的转换与表示对话模型的状态转换网络中的转换相同。

2.4 模型合并与代码生成

提取对话模型后，将应用程序的不同状态与IDM定义的交互技术相连接。此外，设计师需要将对话模型与表示模型合并。在该过程中，表示模型由VRIXML表示，这是一种用于指定最终IVE界面元素的描述语言。

完成整个设计过程后，使用指定的模型自动生成虚拟环境应用程序的运行时二进制文件。此外，该过程还会生成一些存储库文件，应用程序在运行时可以解释这些文件。这些存储库文件提供了更大的灵活性，通常包含用户界面元素的描述（VRIXML文件），以便在应用程序生成后仍能对其进行更改。

为了满足提供图形工具支持和辅助的要求，创建了一个支持上述设计过程的开发环境。

以下是该设计过程的mermaid流程图：

graph LR
    A[创建任务模型（CTT）] --> B[设计交互描述模型（IDM）]
    B --> C[提取对话模型]
    C --> D[连接状态与交互技术]
    D --> E[合并对话模型与表示模型（VRIXML）]
    E --> F[自动生成运行时二进制文件和存储库文件]

3 基于模型的IVE开发工具支持

为了评估上述方法的实际应用，开发了一个名为CoGenIVE（交互式虚拟环境代码生成）的设计工具，并以VirtuaShop应用程序作为案例研究。VirtuaShop应用程序包含多个状态，用户可以在商店中导航、选择并将对象拖入购物车，并通过用户界面元素查看产品的属性。

3.1 工具实现基础

第3节中介绍的过程描述了一种用于IVE应用程序的增量式自上而下的设计和开发过程。该方法的实现基于De Boeck等人提出的事件驱动框架，这种自下而上的方法允许逐步扩展工具，添加额外的高级描述和模型，同时工具的基本版本涵盖了代码生成等基本设计开发步骤。

3.2 图形工具支持

根据之前确定的需求，强烈建议为描述语言或模型提供图形工具支持。特别是在创建表示模型时，CoGenIVE支持用户界面元素的图形设计。在工具内部，可以绘制界面元素，结果会自动保存为VRIXML文件格式。

使用VRIXML为应用程序设计师提供了更大的灵活性，因为在应用程序创建后，仍可以更改用户界面元素的设计和行为。

3.3 对话模型支持

在设计表示模型之后，为CoGenIVE添加了对话模型支持。使用该模型，设计师可以指定不同的程序状态、这些状态之间的可能转换以及用户在每个状态下可用的任务。设计师还可以将创建的用户界面元素之一附加到每个状态。

3.4 代码生成过程

工具开发的下一步是支持基于模型的代码生成过程。生成的应用程序代码基于事件驱动框架，可以无需进一步编辑代码即可执行应用程序。然而，应用程序开发人员可能需要进行一些小的更改或添加特定于应用程序的代码。这些调整最好使用传统的软件开发工具进行。为了支持这些生成后的调整，CoGenIVE会生成一个MS Visual C++项目文件，可用于进一步开发。

为了支持迭代设计过程，工具的设计确保在更新模型并重新生成应用程序时保留手动代码更改。

以下是VirtuaShop应用程序的状态和相关用户界面元素的示例表格：
| 应用程序状态 | 关联的用户界面元素 |
| — | — |
| 状态1 | 菜单 |
| 状态2 | 对话框 |
| 状态3 | 列表 |
| 状态4 | 按钮 |

4 初步结果与正在进行的工作

4.1 开发效率提升

VirtuaShop应用程序约有2500行代码，其中2000行是完全自动生成的。另外500行包含交互技术的实现、某些对话框行为以及特定于应用程序的任务的实现。应用程序的设计（需求分析、讨论和在CoGenIVE中创建模型）大约花费了半天时间，而手动实现和调试应用程序细节又花费了一天半时间。因此，总共创建VirtuaShop应用程序大约花费了两天时间。相比之下，不使用CoGenIVE工具开发这样的应用程序可能需要长达两周的时间。

4.2 待解决问题与未来计划

目前，CoGenIVE还不支持交互技术的规范，因此需要手动实现这些技术。不过，一旦开发出合适的交互描述模型并集成到CoGenIVE中，大部分代码也将能够自动生成。

当前正在评估一些现有的符号，如InTml、ICon和Statecharts，以找到一种可以作为交互描述模型的符号。此外，还在通过集成ConcurTaskTree符号和Luyten等人描述的对话模型提取算法来扩展CoGenIVE。

5 结论

提出了一种基于模型的交互式虚拟环境设计方法，并开发了支持该设计过程的工具CoGenIVE。该工具的开发考虑了现有基于模型的设计过程和VR工具或工具包的典型需求。通过VirtuaShop应用程序的案例研究，早期评估表明，基于应用程序的对话和表示模型，已经可以自动生成大部分应用程序代码。当前版本的CoGenIVE已经满足了大多数确定的需求，但为了最大化生成代码的数量，仍需要实现一些需求。

6 ConcurTaskTrees与UML 2.0的映射

6.1 任务建模与UML的现状

任务建模在人机交互（HCI）中是核心且常见的概念，但在面向对象软件工程（OOSE）中却很少使用。任务模型详细描述了用户的目标以及为实现这些目标所采用的策略，包括用户执行的操作、涉及的对象以及活动的底层顺序。任务模型捕获了交互的对话模型，对于实现基于模型的交互式系统构建方法至关重要。

UML在交互设计方面的不足已被广泛认可，将任务模型集成到UML中是解决其局限性的一步。ConcurTaskTree（CTT）符号是最广泛用于任务建模的符号之一，专门为基于模型的用户界面设计而定制，将其与UML集成已被认为是一个理想的目标。

6.2 集成CTT与UML的方法

集成CTT与UML通常可以通过以下两种方法实现：
- 使用UML扩展机制（配置文件） ：用现有的UML符号表示CTT模型的元素和运算符。这种方法是可行的，曾有人提出将CTT表示为带构造型的类图。
- 扩展UML元模型 ：引入一个单独的用户任务模型，并建立CTT元素与现有UML元素之间的关系。

6.3 基于UML 2.0 Activity Diagrams的分析

本文的目的是研究UML 2.0 Activity Diagrams中控制和数据流规范在表示CTT语义方面的优缺点。分析是通过为CTT中的时间运算符定义基于模式的活动来驱动的。

提出了一种扩展UML 2.0抽象语法的方法，该方法完全支持CTT背后的概念，并为类似UML的表示提供了一种适配的图形符号。

以下是一个简单的mermaid流程图，展示了CTT与UML 2.0集成的大致流程：

graph LR
    A[CTT任务模型] --> B[分析CTT时间运算符]
    B --> C[定义UML 2.0 Activity Diagrams模式]
    C --> D[扩展UML 2.0抽象语法]
    D --> E[实现CTT与UML 2.0集成]

6.4 总结与展望

通过将CTT与UML 2.0集成，可以将任务建模的优势引入到UML的设计流程中，提高交互式系统设计的效率和质量。虽然目前已经提出了一些集成方法和分析思路，但仍需要进一步的研究和实践来完善这种集成，使其能够更好地服务于实际的软件开发项目。

未来可以在以下几个方面进行深入探索：
1. 进一步优化UML 2.0对CTT语义的表示，确保能够准确表达CTT中的各种任务关系和时间约束。
2. 开发更多的工具和辅助功能，支持CTT与UML 2.0的集成过程，降低开发人员的使用门槛。
3. 通过更多的实际案例验证集成方法的有效性和实用性，不断改进和完善集成方案。

总之，CTT与UML 2.0的集成是一个有潜力的研究方向，有望为交互式系统的设计和开发带来新的思路和方法。