31、面向目标的领域控制面板设计

面向目标的领域控制面板设计

1. 引言

多年来，基于模型的界面开发环境（MB - IDEs）很大程度上受一套典型模型的驱动和启发，包括任务、领域、用户、抽象用户界面、具体用户界面、最终用户界面、平台等模型。其中，领域和任务模型通常是开发过程的起点。领域模型在过去十年常被用于自动生成图形用户界面，而任务模型则是为解决一些不足而定义的，如今它是推动以用户为中心设计的最常用模型。这些模型在为特定类型的交互系统（如信息系统）设计用户界面时，展现出了一定的相关性、便利性和效率。信息系统的用户界面主要由预定义的表单、窗口、菜单栏、下拉菜单等组成，可在诸如 Microsoft Visual Basic、C++、Java 或 Web 应用等界面构建器中开发，传统的 MB - IDEs 已证明了这种方法对这类系统的可行性。

然而，当开发非信息系统的复杂可靠系统（如控制系统、模拟器）的用户界面，尤其是界面不能由具有预定义行为的预定义小部件组成时，重用同一套模型就变得困难。因为这些模型可能没有足够扩展以获取启动开发过程所需的信息，也许需要使用其他模型。

此外，任务模型在人机交互（HCI）领域被广泛认可和使用，但软件工程（SE）尤其是需求工程（RE）领域倾向于忽略该模型，而更愿意使用其领域中传统的模型。本文探讨了大多数 MB - IDEs 在开发复杂、可靠、时间受限的交互系统时的不足，是否可以通过基于另一套模型的基于模型的方法来解决。

在 HCI 中，任务模型通常通过递归分解任务为子任务，并使用时间运算符连接，最终得到叶子任务，来代表用户的观点。每个任务都与一个或多个需要实现的目标相关。而在 RE 中，目标模型通过将目标分解为子目标，并使用多种运算符连接，最终将叶子目标分配给代理，来代表系统的观点。

目标模型并非孤立存在，它还与对象模型、代理模型和操作模型相关，这些模型逐步捕获其他方面的相关信息，用于对人类代理界面设计的需求进行推理。在指定最终用户界面的组件（即要使用的小部件）时，小部件本体应重新审视，以提供一个丰富的框架，为每个代理选择最适合实现其目标的显示/控制组合。最后，动画器应提供面向代理的动画，就像传统 MB - IDEs 中可以模拟任务一样。

本文将以一个非平凡的火车系统为例进行说明，该系统基于现实世界铁路信号系统的实现，但为适应篇幅进行了简化。

2. 背景：面向目标的建模

本文使用 KAOS 语言进行面向目标的建模，该语言由 4 个模型组成：
- 目标模型 ：捕获和构建假设和所需的属性。
- 对象模型 ：捕获表达目标的相关词汇。
- 代理模型 ：以可实现的方式将目标分配给代理。
- 操作模型 ：在状态转换层面详细说明代理为实现其负责的目标必须执行的工作。

2.1 构建目标和对象模型

构建这 4 个模型的过程相互交织，通常从系统的一些关键属性开始。这些属性用目标来表达，目标是关于某个系统（现有或待建）的意图陈述，其实现通常需要构成该系统的一些代理的合作。代理是诸如人类、设备、遗留软件或待开发软件组件等活跃组件，它们在目标实现中发挥作用。一些代理定义软件，而另一些定义其环境。目标可分为功能性目标（指要提供的服务）和非功能性目标（指服务质量）。目标用自然语言进行非正式描述（InformalDef），并可选择用实时时态逻辑进行形式化（FormalDef）。

例如，在火车系统中，目标与运输安全相关，如避免火车之间、火车与其他车辆（特别是在铁路道口）的碰撞，以及确保乘客安全（如在火车行驶时关闭车门）。以下是一个目标的示例：

Goal Maintain[DoorsClosedWhileMoving]
InformalDef:
Doors should be closed when the train is moving.
FormalDef:
(∀tr : Train) tr.moving ⇒ tr.doorClosed

在上述表述中，我们识别出了火车实体及其移动和车门关闭属性，并将它们逐步添加到捕获被动（实体、关系和事件）和活跃对象（代理）的结构模型中。

与目标不同，领域属性是关于环境的描述性陈述，如物理定律、组织规范或政策等。例如，火车需要一定距离才能停下来（惯性定律）。

面向目标的需求工程的一个关键特征是目标是结构化的，并提供指导来发现和细化这种结构，直到找到能合作实现这些目标的代理。在 KAOS 中，目标以 AND/OR 细化 - 抽象层次结构组织，高层目标通常是战略性的、粗粒度的，涉及多个代理；而低层目标通常是技术性的、细粒度的，涉及较少的代理。AND 细化链接将一个目标与一组子目标（称为细化）相关联，可能还会结合领域属性，这意味着满足细化中的所有子目标是在该领域中满足目标的充分条件。OR 细化链接可能将一个目标与一组替代细化相关联。

2.2 代理模型

目标细化在每个子目标都能由分配给它的单个代理实现时结束，即这些子目标可以用代理可监控和控制的条件来表达。需求是待开发软件中代理负责的终端目标，期望是环境中代理负责的终端目标。

例如：
| 代理 | 类型 | 负责目标 | 监控 | 控制 |
| — | — | — | — | — |
| TrainDriver | Human | Maintain[DoorsClosedWhileMoving], Achieve[TrainProgress…] | Block.signal | Train.moving, Train.doorClosed, Train.blockOf |

在设计中，除了火车司机（人类）控制火车的移动状态和位置外，所有代理都是自动化系统的一部分。车门和电机控制器安装在火车上，而信号控制器和大门控制器是地面设备。在这个案例研究中，一个重要的问题是如何根据监控/控制需求传递地面和火车上的信息。代理界面视图展示了代理之间监控/控制信息的流动。

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(TrainDriver):::process -->|Monitors| B(Block.signal):::process
    A -->|Controls| C(Train.moving):::process
    A -->|Controls| D(Train.doorClosed):::process
    A -->|Controls| E(Train.blockOf):::process

2.3 操作模型

目标被操作化为实现它们的操作规范。操作是对象上的输入 - 输出关系，操作应用定义了沿着目标模型规定的行为的状态转换。操作规范包括必要的前置条件、目标状态的后置条件和充分的触发条件。还需要区分描述性的领域前置/后置条件和为实现某些底层目标所需的规定性前置、后置和触发条件。

例如，OpenDoors 操作的规范如下：

Operation OpenDoors
Input:
tr:Train/doorClosed
Output:
tr:Train/doorClosed
DomPre:
tr.doorClosed
DomPost:
¬tr.doorClosed
ReqPre:
for SafeRailroadCrossing ¬tr.moving
ReqTrig:
for FastPassengerTransfer (∃st : Station) at(tr, st)

一个目标的操作化是一组这样的规范。例如，为了完整实现 “DoorClosedWhileMoving” 目标的操作化，可能还需要加强 “StartTrain” 操作。

3. 控制面板设计过程概述

从正确细化和操作化的模型设计控制面板可以系统地进行，因为模型尤其是代理子模型捕获了所有相关信息。总体过程如下：
1. 对于目标模型中的每个人类代理，检索其负责的所有需求。
2. 对于代理模型中的每个人类代理，确定其为实现这些需求需要监控和控制的所有信息。
3. 对于操作模型中的每个人类代理，确定其执行的操作以及通过这些操作可能影响的受控元素。
4. 为每个监控元素选择合适的显示小部件，并将其映射到监控元素上。
5. 为每个受控元素选择合适的控制小部件，并将其映射到相关操作上。

例如，火车司机负责 “Maintain [DoorClosedWhileMoving]” 目标，代理模型显示他需要控制车门关闭状态和移动状态。火车司机还负责其他目标，如 “Maintain[ProgressWhenGoSignal]” 和 “Maintain[StopOnRedSignal]”，这需要监控信号并再次控制移动状态。对于受控部分，车门关闭和移动是布尔属性，通过 “Start/Stop” 和 “OpenDoors/CloseDoors” 操作对进行控制。在这种情况下，合适的控制小部件是一个二态开关，其每个转换在模型中都有对应的操作，并且能提供受控状态的反馈。

由于人类代理存在诸多限制，检查所考虑信息的有效可监控性/可控制性很重要。缺乏可监控性可能是由于感知能力限制（如高速行驶时错过或误解轨道信息的危险）、注意力有限（如同时关注轨道信号和火车上的控制）等原因。缺乏可控制性可能是由于响应时间限制（如高速行驶时的紧急制动）、高负载等原因。可以使用一些可用技术（如障碍分析、代理策略）来考虑这些特定属性，以评估系统设计的可实现性。例如，在考虑轨道占用的可监控性时，高速行驶时直接物理感知轨道信号是困难的，这可以通过更完善的系统设计（如车内报告和依靠地面 - 车内通信）来解决。人类代理还可能遗忘事情和犯错，KAOS 框架可以使用目标公式中的 “knows/belief” 谓词来建模和推理这些情况，推理可以在细化时直接进行，或者更优选地在后期对理想模型进行障碍分析，以评估可能的后果并减轻影响。

4. 构建小部件分类法

为了便于根据底层目标模型设计交互式面板，研究了多个领域（如交通、工业控制和家庭使用）的实际控制面板。这些研究有助于定义一个基于目标（如能够监控/控制状态、报告危险等）而非直接基于数据或任务的小部件分类法。此前的一些小部件分类法基于领域模型或任务模型，这些分类法根据小部件可操作的底层数据或领域模型对其进行分类，但没有区分数据是作为输入、输出，还是对系统目标的影响。而本分类法可以直接将先前确定的目标和子目标（尤其是叶子目标）映射到最能代表它们的小部件上。

得到的分类法结构与 KAOS 模型类似，第一层是一个通用模型，捕获用户界面应解决的目标。每个目标被细化，直到确定相关的小部件类，然后这些小部件类基于更传统的数据类型层次结构进行组织。在分类法的底部，展示了一些典型实例。

在得到的分类法中，确定了一些概念属性，如显示/控制/警报类型（目标级别）和显示的数据类型（数据级别）。基于对多个小部件实例的研究，还确定了一些不属于分类法的图形属性，这些属性有助于调整视觉方面，如布局、分区、标签、单位等。例如，对于速度计表盘，概念属性包括显示方式、连续数据范围；图形属性包括角度布局、分区、单位。所有这些特征由一个单一概念捕获，即该小部件和其他具有相同概念属性的 “表盘” 小部件的 “计算机版本”，并由相应的类实现。在这项工作中，使用了 Java 语言、JavaBeans 接口机制和 Swing 图形工具包。

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(通用目标模型):::process --> B(目标1):::process
    A --> C(目标2):::process
    B --> D(小部件类1):::process
    B --> E(小部件类2):::process
    C --> F(小部件类3):::process
    D --> G(典型实例1):::process
    E --> H(典型实例2):::process
    F --> I(典型实例3):::process

5. 在需求动画器上的部署

从开发过程开始就使用模型的一个重要方面是，能够以某种方式执行提取的模型，为未来系统的验证目的对其第一版本进行动画演示。因此，底层模型必须足够表达，以获得一个可运行的界面。例如，Visual Task Model Builder 主要利用任务模型来动画演示任务的时间顺序，但不够详细，无法获得一个可执行的工作原型来展示非平凡的交互会话。同样，在 CTTE 中，可以动画演示任务模型以查看任务的可能时间顺序，但任务模型不足以展示任务的完整执行。

为了实现这一目的，我们希望利用第 2 节中介绍的所有底层模型，以获得一个无需额外编码或建模就能真正工作的动画器。FAUST 需求动画器支持 KAOS 面向目标的模型的动画演示，它依赖于 Objectiver RE 平台，有助于系统模型的设计，能够生成和重放执行轨迹，并通过允许领域专家使用熟悉的用户界面与可执行模型进行交互来进行验证。现有的动画器支持将操作化的目标模型编译为有限状态机（FSM），然后在服务器上的模拟器引擎中运行。多个客户端参与者可以连接到该模拟器，以多用户方式与模型进行交互，从而进行有趣的验证场景。动画器还配有一个监视器，用于报告目标违规情况。

目前，动画器存在三个重要缺点：
1. 缺乏使用领域特定界面的控制。
2. 缺乏一致的基于代理的用户界面（目前动画器参与者与模型中的代理没有特别绑定，可能提供的监控/控制不足或过多）。
3. 缺乏对开发此类界面的支持。

前两点在前面的章节中已经解决。在工具方面，通过一个可视化工具支持组合和映射，该工具允许动画设计师通过查询小部件库来组装面板，将每个相关变量进行映射。该工具使用 Java 和 Swing 图形库实现，支持通过拖放组件到面板上进行组合。一个基于 JavaBeans 的属性编辑器可用于实例化可用的小部件并调整其图形渲染。还为汽车、铁路、航空航天和工业控制等领域提供了一些常见的小部件。

通过一个映射组件实现与动画器的集成，该组件管理底层概念模型（即生成的 FSM 的状态和转换）与动画的用户界面（控制和显示）之间的一致性。为了实现最大的灵活性，可以在类型级别定义并在实例级别进行调整。映射大致如下：
- 显示小部件映射到状态元素（这些元素也与对象模型的实例相关联），小部件的类型和底层状态应兼容。

面向目标的领域控制面板设计

6. 映射组件的详细说明

为了更好地理解映射组件在集成过程中的作用，下面详细说明其工作机制。映射组件就像是一座桥梁，连接着底层概念模型和用户界面。它确保了在动画演示过程中，用户界面能够准确反映概念模型的状态变化，同时用户在界面上的操作也能正确地影响概念模型。

具体来说，映射组件主要完成以下几个关键任务：

任务	描述
状态同步	实时监测概念模型的状态变化，并将这些变化同步到对应的显示小部件上。例如，当火车的移动状态在概念模型中发生改变时，映射组件会立即更新用户界面上显示火车移动状态的小部件。
操作传递	将用户在控制小部件上的操作传递给概念模型中的相关操作。比如，用户在二态开关上进行操作时，映射组件会将这个操作转换为概念模型中对应的 “Start/Stop” 或 “OpenDoors/CloseDoors” 操作。
兼容性检查	在进行映射时，检查显示小部件和状态元素、控制小部件和相关操作之间的兼容性。如果不兼容，会发出提示信息，确保映射的准确性。

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(概念模型):::process -->|状态变化| B(映射组件):::process
    B -->|更新显示| C(显示小部件):::process
    D(控制小部件):::process -->|用户操作| B
    B -->|执行操作| A

7. 实际应用案例分析

为了更直观地展示上述方法在实际中的应用，我们以火车系统为例进行详细分析。

7.1 火车司机的操作场景

火车司机在驾驶火车过程中，需要完成多个任务以确保火车的安全运行。根据前面的设计过程，我们来分析他在不同场景下的操作。

目标	监控信息	控制信息	操作	小部件选择
Maintain [DoorsClosedWhileMoving]	无（主要依赖系统自动监测）	车门关闭状态、移动状态	Start/Stop、OpenDoors/CloseDoors	二态开关
Maintain[ProgressWhenGoSignal]	信号状态	移动状态	Start/Stop	二态开关
Maintain[StopOnRedSignal]	信号状态	移动状态	Start/Stop	二态开关

在这些场景中，火车司机通过监控信号和控制火车的移动状态、车门状态来实现相应的目标。二态开关作为控制小部件，能够方便地实现对火车状态的控制，并且提供反馈信息。

7.2 系统的可监控性和可控制性分析

在实际运行中，火车系统面临着各种挑战，尤其是在可监控性和可控制性方面。

• 可监控性挑战 ：高速行驶时，火车司机可能无法及时准确地获取轨道信号信息。为了解决这个问题，系统采用了车内报告和地面 - 车内通信的方式，确保司机能够及时了解轨道情况。
• 可控制性挑战 ：高速行驶时的紧急制动需要一定的响应时间，这可能会影响系统的安全性。通过优化系统设计，如提前预警和自动制动系统，可以提高系统的可控制性。

8. 总结与展望

通过上述方法，我们实现了从面向目标的模型设计到用户界面开发的完整流程。这种方法利用了 KAOS 语言的四个模型，系统地设计了控制面板，并通过映射组件将模型与用户界面进行了有效集成。在需求动画器上的部署，使得我们能够对系统进行验证和测试，提高了开发效率和系统的可靠性。

然而，这种方法仍然存在一些不足之处。例如，在处理复杂系统时，模型的构建和维护可能会变得困难。未来的研究可以朝着以下方向发展：
1. 进一步优化模型的构建和维护方法，提高其可扩展性和灵活性。
2. 探索更智能的小部件选择和映射方法，减少人工干预。
3. 加强对人类代理行为的建模和分析，提高系统的适应性和安全性。

总之，面向目标的领域控制面板设计方法为复杂系统的用户界面开发提供了一种有效的途径，未来的研究将不断完善和拓展这一方法，使其在更多领域得到应用。