任务:定义系统环境
此任务定义了如何创建显示系统及其参与者之间顶级协作的系统环境图。
规程:分析和设计
用途
  • 在用例模型的基础上创建顶级协作,用于显示系统(建模为顶级子系统)、系统接口以及系统与其参与者(包括参与者与系统间流动的外部 I/O 实体)之间关系。
关系
步骤
简介

尽管用例模型显示了系统的行为环境,然而在此任务中,将在系统环境中创建系统的逻辑模型,方法是使用工作产品:用例模型工作产品:补充规范,在环境图中进行描述:

  • 将由系统实现的接口(包括系统提供的操作、支持的关联协议、系统实现的状态变量存储,以及具有技术性能度量特征的属性)。
  • 在系统及其参与者之间流动的 I/O 实体
  • 系统为获得适当的性能所需的接口(将由与该系统交互的参与者实现)。通常,如果参与者代表系统必须与其通信的现有系统,则这些所需的接口只反映由其他系统施加的约束。

环境图显示系统及其参与者之间的顶级协作。这是按照系统用例模型的结构模拟。该协作是在分析模型中创建的。

I/O 实体(被表示为用于建模的构造型为“I/O”的类,这些类带有属性,但无操作)描述流入和流出系统的事物,在一般系统情况下,可包含数据、规模、精力或物理部件。I/O 实体与参与者-系统对关联(建模期间),这表示这些特定 I/O 实体在参与者与系统之间流动。它们可以在图上显示,或是与参与者关联,而流动的方向由关联上的构造型“发送”或“接收”表示,这表示方向是相对于参与者而言的。

系统操作是对象可请求来实现某种行为的服务。操作指定用于调用相关联行为的名称、类型、参数和约束。根据考虑的(子)系统的主要职责围绕接口对操作进行分组。系统操作调用表示,同与用例实例的交互相比,与系统的交互更为细化,而用例实例是操作调用和响应的组合。

状态变量和存储是在由系统实现的接口上定义的属性。这些属性是抽象的,它们需要与属性的类型和多重性相应的系统维护信息,并允许对这些信息进行存储、检索和修改。这并不表示系统中的某个属性与在接口上定义的属性直接对应。状态变量和存储之间的差异不是内在的,它只是反映了将属性用于控制系统(抽象)状态机操作的方式。“状态”可持续一段时间,这和在某个时刻发生的事件(例如信号的到达)不同。在这里提到的状态机是有限状态机,对“状态”的描绘通常由相对较少的变量决定;例如,当前状态可由枚举类型的单个属性的值确定。但是,系统对事件的反应可能不但依赖于事件的性质(例如,事件的操作参数中携带的信息)、当前状态,而且还依赖于其他(可能很多)属性的值。

“技术性能度量”(TPM)是选自“补充规范”或“用例模型”的关键技术属性,用作系统效能的重要指标,若未达到,则系统开发将处于超支、逾时或超出性能约束的风险。此类属性的新增值将在项目生存期中进行追踪。例如,将系统的交付权重保持在特定界限下可能很重要,而完成此目标需要在设计和构造时进行追踪。交付时的系统权重显然是系统实例的一个属性(该属性可以多种方式检测),且不必等同于开发期间的目标权重(对于将启动以正常运行的系统,您可能希望它小一些)。UML 标注值可用于注解 TPM 属性,以表明性能目标,例如:

"TPM" weight {maximum_weight = 1000kg}

“技术性能度量”也可应用于其他非结构化特征(例如操作响应时间)。 标注值可应用于系统操作或系统本身,以对这些内容进行记录。

创建初始环境图

以下步骤显示了系统在环境中不断变化的详细级别。所述的示例是关于安全系统的,用以保护资产免遭未经授权的侵入,它可以发出声音警报,也可以向某种响应服务报告违规情况。 

随着您对“用例模型”执行演化,并向其添加更多详细信息(发现参与者;或者如果已执行了“业务建模”,且已确定了参与者并且还可能确定了操作,则详细描述其交互),您可以创建初始协作并使用“环境图”进行说明。可如所示的那样开始使用已在很大程度上抽象的系统接口来创建环境图。系统描绘为顶级子系统(构造型为“system”),它最终可实现几个接口。参与者及其关联也将再次显示(初始无详细信息)。

环境图(初始)

环境图(初始)

优化关联和接口

下一步,优化参与者、系统和系统接口之间的关联。您可以开始推断在任务:查找参与者和用例(随后:任务:详细描述用例)中出现的系统操作和系统属性。请注意,系统现在通过显示接口呈现给参与者。如果您需要,可以显示此过程的实现(在环境图中以虚线圆高亮显示),但是也可以将其省略而不会丢失很多信息。

在此阶段,基于领域知识和之前在企业级别实现用例过程中完成的任何工作,只尝试确定 I/O 实体。请注意,在图中显示 I/O 实体并不是必需的,但是这对于推断参与者-系统交互可能很有帮助。

因此,您可以开始描绘参与者与系统之间的连接(例如,记录所需的协议)并记录在它们之间流动的实体。

环境图(初步)

环境图(初步)

详细描述系统操作和其他系统特征

在此步骤中,开始构造用例场景(用例的实例),您可以在这些场景中描述系统操作(已提供且是必需的)。这些场景可通过交互或活动图说明。用例中的每个黑盒步骤都表示与系统更为细化的交互,并映射到一个操作调用(但是不一定是一个唯一操作;其他黑盒步骤可以使用同一操作)。在环境图中(然后在分析模型中)定义系统操作的同时,还对用例进行了注释,以便跟踪所调用的操作。操作还继承任何性能需求或其他已分配到黑盒步骤的非功能需求。随着您检查在场景中执行的每个黑盒步骤,您会发现使用的名称可能暗示系统必须为执行用例场景而维护的状态变量和存储。您还可以优化必需的 I/O 实体,并将这些实体与操作调用关联,以形成在参与者和系统之间发送的信号。 

它可能有助于理解将系统接口分为更多具体接口;实际上,在“补充规范”中可能有促成此划分的接口需求。虽然这不是固定的规定,但是下面的说明显示了针对每个参与者类型的系统接口到“提供的系统接口”的发展。多个参与者可以共享一个接口,或者一个参与者可以使用多个接口。

此分析还可以确定系统必需的接口,即:必须受参与者支持(用以处理来自该系统的消息)的接口。这些接口可按对称方式添加到图中(例如,请参阅下图中由“紧急服务”参与者实现的 IE 服务/ESS“必需的系统接口”)。同样,(虽然该点未显示)一个参与者可以支持(实现)多个接口。

需要将操作、存储等添加到所显示接口(在属性和操作的间隔中)的扩展形式。该图只能局部详述(由于空间的缘故)。并未展开物理环境接口、参与者等。此外,可省略所提供的系统接口的实现而不会丢失很多信息。

环境图(最终)

环境图(最终)。

“环境图”中获取的该顶级协作使得接口、连接、流入和流出系统的对象以及相关的性能特征可以进行严格指定,支持系统开发在某种程度上独立于系统环境中的其他元素而进行。