1.简介
目前我们日常生活中使用的绝大多数系统都是软件密集型系统，这意味着它们的组件中有很大一部分是软件类型的。由于不断变化的需求，软件元素使这些系统变得复杂，并需要频繁维护。复杂性和需求管理是软件组件开发中需要适当解决的方面，因为它们都与系统的可靠性有关。将更改应用于过于复杂的软件产品可能很容易导致引入回归错误。如文献所述（参见，例如[1,2])由于所需的工作以及需求变更对可靠性和软件成本的影响，需求定义和分析是软件组件开发中最关键的活动。 可靠性是所谓关键系统的一个关键特性，即系统的故障或故障可能导致严重后果。在[三]，作者将关键系统分类为（类似的简化分类也可在[4])安全关键的（可能导致人员死亡、严重人身伤害或自然环境破坏），任务关键型（可能导致无法完成整个系统或项目目标），业务关键型（可能导致重大的有形或无形经济成本）和安全关键型（可能会因盗窃或意外丢失而导致敏感数据丢失）。 本文提出了一种面向过程的需求定义和关键系统中软件组件的分析方法，重点是业务关键型个。特别是，该方法支持定义一个正式的标准模型，该模型通过使用几个标准（即业务流程模型和符号（BPMN））将需求、流程和数据链接起来[5]，系统建模语言（SysML）[6]决策模型和符号（DMN）[7]以及共享数据模型和符号（SDMN）[8]. 这四种形式的集成使得可以指定需求和满足需求的过程元素之间的关系，以及这些过程元素所消耗/产生的数据。此外，生成的模型实现了完整的系统规范，包括处理功能方面规范的行为视图和处理静态数据相关方面规范的结构视图。
这两个视图的适当集成是系统工程和软件工程中的一个众所周知的问题[4]. 当寻址系统批评的，每个视图必须使用不同类型的UML/SysML图以单独的方式仔细建模，统一视图的问题在稍后阶段通过分析两个模型之间的交互来解决，例如。，通过使用序列图，在给定的执行场景中，将活动分配到结构元素上进行建模。
在本文中，我们重点关注行为视图的规范，该规范用所谓的ad hoc属性进行注释（根据[9])，以便在SysML中驱动更详细的系统规范。提议的贡献引入了一种逐步细化系统规范的阶梯式方法，从更高抽象级别的模型（有效地用于帮助利益相关者定义自己的需求）到更详细的模型，它提供了用于支持后续系统开发和维护活动的需求规范。具体来说，该方法将使用特殊属性注释的BPMN模型作为输入，并集成DMN和SDMN模型，最终生成SysML中指定的系统模型作为输出。 因此，最初对行为视图的关注，只使用正确执行给定场景所需的数据进行注释，并不排除随后使用执行时所消耗/生成的数据的完整细节对数据模型进行细化。
集成模型是有效需求管理的关键要素，特别是在可追溯性和V&V（验证和确认）方面。所提议的模型确实能够采用基于仿真的方法，这些方法是所谓的数字孪生兄弟是M.Grieves引入的一个概念，表示实际系统的虚拟副本，与物理副本紧密耦合，用于高效的系统管理[10]. 数字孪生模型确实包括系统模型和实际系统之间的连续数据交换，从而使模型和系统保持一致[11]. 从系统收集的实时数据既可用于监控系统执行，也可用于向模型提供准确、最新的参数，以便使用基于仿真的方法“执行”模型。反过来，系统仿真提供了这些预测能力，这些能力对于明智的决策和对系统故障或性能降级的快速反应至关重要。因此，建议的模型可以被视为开发数字孪生模型的第一步，在正确监控和指导实际系统方面具有显著优势。 论文的其余部分组织如下。第2节提供了一些有关本文中使用的主要标准的背景资料，而第3节总结了相关工作。第4节描述了建议的方法，然后在第5节通过使用正在运行的示例应用程序。最后，第6节讨论所提出的方法并给出结论。 2.背景
本节概述了构建拟议方法所使用的主要标准符号，以便于理解论文贡献。
2.1. 业务流程建模符号
在业务流程管理上下文中业务流程模型和符号（BPMN）是业务流程高级规范的标准[5]. BPMN的主要目标是定义一个符号，该符号必须易于业务流程自动化领域中的各种人员阅读，从指定业务流程的业务分析师和设计师，到实现指定流程的IT开发人员。 这个决策模型和符号（DMN)是一种建模语言和符号，用于精确规范业务决策和业务规则[7]. DMN与BPMN一起使用并扩展了BPMN，以提供一种方法来建模与BPMN中指定的流程相关联的复杂决策规则。业务规则在DMN中使用简单但明确的决策表指定。 最后共享数据模型和符号（SDMN）为所谓的共享数据模型，它们是数据存储库，为所有数据元素（命名为数据项在SDMN术语中）跨相关模型使用，如BPMN或DMN模型。此类库将作为开发BPMN和DMN模型引用的数据元素的中心源，从而允许轻松、集中地更新在这些模型开发期间可能更改的数据元素。
本文利用上述三个标准为面向过程的需求的简单而完整的定义提供了一种机制。
2.2. 系统建模语言（SysML）
这个系统建模语言（SysML）是在系统工程领域广泛使用的通用建模语言，用于指定、分析、设计和验证系统，这些系统可能包括硬件、软件、信息、人员、过程和设施[6]. 该语言源于UML的定制，以适应系统工程领域，并通过添加新的图类型（如需求图和参数图）重用某些类型的UML图。 具体来说，本文提出的方法利用了块定义图，通过描述系统层次结构和组件分类来表示系统结构，以及需求图，指定基于文本的需求，并将其与满足或验证需求的块定义图元素相关联。此外，第5节还提到了参数化图表，表示对系统属性值（如性能、可靠性）的约束，并用作将规范和设计模型与系统分析模型集成的手段。 3.相关工作
大量文献涵盖了系统工程和软件工程领域中处理需求定义和分析的方法[12]. 本节并不打算对这些方法进行详尽的审查，而是比较和激励类似工程的拟议贡献。 众所周知，需求定义在软件开发和维护阶段都是一项关键活动，因为错误需求在整个软件生命周期中对修复成本具有重大影响。可能导致在需求中引入缺陷的相关错误源可以追溯到有助于定义需求的不同角色，从具有应用领域专业知识但没有特定软件工程技能的利益相关者和业务分析师，到负责将高级需求转化为操作系统的工程师和IT开发人员[13]. 对要开发的系统及其要求的不同观点，以及非常不同的技术背景，可能很容易导致误解和含糊不清，这意味着需要努力和耗时的返工活动。基于模型的方法已经显示出巨大的潜力，它是解决这些问题的有效方法，它引入了半正式需求定义方法，这种方法介于基于自然语言的易于使用的非正式方法（因此容易产生歧义）和昂贵的正式方法之间，基于数学规范的使用，在许多情况下需要业务分析师和开发人员不熟悉的技能[14]. 在这方面[9]作者建议在需求引出阶段引入特殊数据模型，以便利益相关者易于理解和验证此类需求，同时IT开发人员也能明确这些需求。本文利用这一思想将特殊注释引入BPMN模型，该模型定义了所提方法的起点。 为了正确管理需求，一旦定义了需求，就必须能够描述和跟踪其在开发和维护时的使用，无论是向前还是向后。这个能力被命名为需求可追溯性在基于模型的系统工程（MBSE）中发挥着重要作用。系统工程领域的一些工作通过使用MBSE和SysML实现了需求跟踪（参见，例如[15,16]). 在[17]作者提出了一种可跟踪性方法，通过将SysML与BPMN和DMN相结合来支持决策需求。SysML用于对系统的某些方面进行建模，流程和决策活动分别根据BPMN和DMN标准进行定义。这样的结果提供了有用的输入，以通过DMN和SDMN模型将BPMN模型的行为视图与SysML模型的结构视图适当地集成。 4.三步法
如中所述第3节，本文的面向流程的需求分析方法受到了中提出的轻量级BPMN扩展的启发[9]，其中特殊属性（AHA）定义为一组关键属性得到一个特定的图形表示法在待开发系统的BPMN模型中视觉提示这使得阅读和理解这些属性如何指导执行流和需求满足变得更加容易。特殊属性又可能是需求或合成/衍生属性，非开发人员更容易理解，但通过潜在的复杂算法正式链接到底层的实际系统数据模型。通过这种方式，涉众可以获得简化的更高级别和面向需求的系统视图，这更容易验证，而开发人员可以轻松地将这种视图映射到实际系统，以便开发需求实现。 我们的方法将经过特殊属性扩展的BPMN模型映射到一个正式的标准模型，该模型通过使用以下几种标准将需求、流程和数据链接起来：BPMN 2.0[5]系统建模语言（SysML）[6]，决策模型和符号（DMN）1.3[7]以及共享数据模型和符号（SDMN）[8]. 之所以选择从AHA注释模型开始，是因为它们关注系统的行为视图，这得益于与BPMN标准的兼容性，以及它们与数据的轻量级集成，这是由特殊属性提供的。这使得整个过程在需求规范级别上很容易被各种利益相关者访问，另一方面，它也简化了与上述其他标准的集成。
该方法包括以下三个步骤：
步骤1：从BPMN-AHA模型到BPMN和DMN模型。在第一步中，需求建模为[9]通过标准BPMN和DMN模型的组合表示。特别是，数据对象，即变量集，用于表示任务所消耗和产生的信息，以及指示DMN决策表中使用的数据。此外，为了处理adhoc数据模型[9]，还可以使用其他数据对象对动态实体与BPMN流程的特定片段的执行相关。换句话说，仅在流程执行时创建和使用的临时实体不会持久化。此外，中引入的视觉提示[9]通常表示为应用于BPMN模型区域的颜色，由一个特殊的业务规则任务确定，该任务更新包含此类信息的特定数据对象。每个BPMN业务规则任务都附加到相应的DMN决策表，该决策表在给定输入数据对象的情况下，应用其业务知识模型来生成或更新输出数据对象中的数据。 第2步：用SDMN表示数据BPMN模型中涉及的所有数据对象和DMN模型中的所有数据元素都应具有通用的形式化，例如通过UML类图。然后，此类正式数据表示被映射到SDMN DataItems，并链接到BPMN和DMN Item Definitions，从而定义单个共享和正式数据表示。
步骤3:SysML模型规范最后，在最后一步中，使用SysML需求图和块定义图将前面步骤中定义的所有元素适当地链接在一起。特别是，需求图用于规范化需求之间的关系和层次结构，而块定义图用于表示过程元素、数据、它们之间的关系以及需求。
下一节将详细介绍这三个步骤，其中介绍了一个简单而全面的案例研究，该案例研究用作所建议方法的运行示例应用程序。
最后，值得注意的是，我们在这里提出的流程严格来说是单向的：任何利益相关者在任何中间步骤中提出的任何更改都会决定流程本身的重置，即更改必须反映在初始模型上，并且必须再次执行以下集成步骤。实际上，这种约束来自我们所处理的系统的固有性质，即关键系统，在系统设计和开发的任何点引入更改都应触发对系统本身（或至少是对包含的子系统（如果系统架构良好））的全面重新分析，因为它可能决定其他地方的危险副作用。
5.应用示例
让我们考虑一下客户请求银行贷款的情况，即发源地中给出的示例[7]. 特别是，让我们满足以下要求： - R1级
如果申请人不满18岁或是风险得分低于80的现有客户（如原始示例规范中所述，风险得分越低，风险水平越高[7])，申请被拒绝。如果申请人是现有客户，其风险评分在80到110之间，则对申请进行初步分析。最后，所有申请都要经过审查，以决定其是否接受。 - R2级
申请程序必须在3天内处理，否则必须发送延迟通知。
5.1. 采用AHA方法的轻量级模型
通过应用AHA方法，这些需求通过BPMN流程清晰建模，如图1使用中描述的adhoc数据模型表1在后者中应用实体包含主导地位属性，通过关联的颜色表示从上述需求（1）派生的所有可能的应用程序审查和决策状态。这个申请人实体只填充了可能派生的申请人信息，这些信息是简单地派生上述状态所需的，即他的年龄，他的风险评分还有一面旗帜，表明他是不是现有客户. 在流程开始时，我们分别收集应用程序和申请人实体中的应用程序数据和申请人数据。然后是否继续进行应用程序审查？网关使用应用程序地位属性派生自表1将流重定向到拒绝申请任务（如果状态为红色）(下降)，到初步局分析任务（如果状态为黄色）(局)或直接发送到审查申请任务（如果状态为蓝色）(通过). 审查后，更新了地位最终用于是否接受负载？gateway决定拒绝（红色）或接受（绿色）应用程序任务。 5.2. 带有BPMN、DMN和SDMN的中等重量模型
从这个轻量级即席模型开始，我们可以通过使用数据对象来丰富给定的BPMN流程，以表示每个任务中涉及的数据，从而生成一个中等规模的正式模型，数据关联表示调用DMN决策模型的数据流和业务规则任务，以封装AHA模型的BPMN扩展语义。生成的BPMN如所示图2可以如下描述。 这里，在流开始时，应用程序通过相应的应用程序包含请求的产品，申请人名称和应用程序地位。然后，流程分为两个可能的流程：在第一个流程中，3天后，将向申请人通知延迟（使用应用程序数据对象），过程结束。否则收集应用程序数据任务使用应用程序数据对象和客户和产品数据存储以生成申请人（姓名、年龄、现有客户、风险评分）和请求的产品（类型、数量）数据对象。接下来是业务规则任务评估应用程序将最后两个数据对象作为输入，并应用上面的要求（1）。为此，与此任务关联的决策表使用产品类型，申请人年龄，申请人风险评分和申请人现有客户属性，并生成输出应用程序状态，该状态写入应用程序数据对象。特别是，相应的业务知识模型遵循中所示的决策表图3: 无论风险评分和现有客户价值如何，如果年龄值小于18岁，则状态为下降;
无论客户年龄如何，如果风险评分小于80，则状态为下降;
如果年龄值大于或等于18，风险得分大于或等于110，并且客户已知（现有），则状态为通过（即，应用程序可以跳过初步分析）；
在所有其他情况下，无论年龄、风险评分和现有客户如何，状态都是局即，应用程序需要进行初步分析。
接下来是业务规则任务确定应用程序颜色将更新后的应用程序数据对象作为输入，并将其与应用程序中写入的颜色相关联颜色属性。特别是，相应的业务知识模型使用状态到颜色决策表如所示图4。它需要应用程序地位并生成输出应用程序颜色数据对象，其中颜色为红色如果状态为下降,绿色对于接受,蓝色对于通过和黄色的对于局. 值得在此回顾的是应用程序颜色是AHA模型中引入的一种方便的视觉辅助工具，用于快速识别实际指导过程演变的数据及其判别值。为了可读性，我们觉得在以下集成步骤中维护和跟踪这种合成属性也很有用。然而，这里描述的程序并不严格需要它，因此它只能留在AHA模型中，并从以下模型中省略。
此时，网关是否继续进行应用程序审查？使用上面设计的颜色属性可以激活三种可能的场景之一：
红色（拒绝）激活拒绝申请发送任务；
黄色的（局）激活初步局分析用户任务，其中，从申请人数据对象，则在局分析数据对象，尤其是其风险类别和破产属性。然后，水流继续流向审查申请下一点中描述的用户任务；
蓝色（通过）直接到达审查申请用户任务，其中三个数据对象请求的产品,申请人和局分析用于对更新状态的应用程序执行最终检查。
如果流尚未终止（红色），则下一步总是另一个步骤确定应用程序颜色业务规则任务，它使用相同的状态到颜色更新业务知识模型应用程序颜色基于更新的应用程序状态.
最后是否接受负载？gateway使用这种颜色来确定最终应用结果：
红色（拒绝）激活拒绝申请发送任务；
绿色（接受）激活接受申请发送任务。
在上面的BPMN中，我们引用了几个数据对象。我们可以假设其中一些，即申请人、应用程序和产品，对应于实际系统实现中包含的实际持久性实体。因此，我们假设这些对象已经（或从源代码重构）了形式化，如中所示的UML类图图5a.特别是： 申请人从继承基本属性人并添加了现有客户和风险_核心.
客户还从Person继承基本属性并添加开始_日期指示此人开始成为银行客户的日期的属性。此属性用于派生现有客户的属性申请人，如果后者是（现有）客户。
应用程序是贷款申请请求产品,应用程序名称,数量和地位属性。
产品通过其名称和类型属性。每个应用程序仅引用其中一个产品。
BPMN模型中涉及的其他数据对象。，请求的产品（由收集申请人数据任务）和应用程序颜色，显然是流程内部的，并且仅在其执行期间存在。我们给他们打电话动态实体。为了简单起见，我们在类图中包含了此类实体的形式化，如图5b、 尽管它们在系统实现中不存在。总之，一般来说，我们不会对动态实体的此类类图的可用性做出硬性假设。 最后，使用SDMN图将此类结构模型链接到BPMN和DMN项定义，如所示图6，其中动态实体以白色背景描述，静态（持久）实体以灰色背景描述。根据SDMN规范，图形元素使用的背景色为白色，但符号可以扩展为使用其他背景色用于特定目的（例如，突出显示不同类型的实体，如本文所述）。 5.3. 使用SysML进行重量级形式化
在提议流程的最后阶段，我们在SysML的帮助下将形式化向前推进了一步，并实现了一个重量级的形式化，为需求管理、可追溯性和验证铺平了道路。特别是，我们使用SysML需求图和块定义图将需求链接到过程元素和数据项。
贷款申请示例考虑的两个需求可以用中所示的需求图建模图7图定义了一个名为原始报表包含流程必须满足的所有要求。这些要求包含原子要求时间和化合物要求应用程序评估，其中又包含初步分析和审查正如我们将要展示的，这个需求层次结构有助于可视化从需求到依赖于它们的系统模型元素的可追溯性。 中引入的UML类图第5.2节(图5)将与持久和动态实体对应的过程数据形式化，可以将其转换为块定义图，而不会丢失任何信息，如所示图8a、 b，我们在哪里使用值类型以对过程中的数据项可能采用的值进行建模。 为了将SysML模型的元素与BPMN模型中的元素链接起来，我们采用了与[17]. 我们引入一个轮廓并定义刻板印象用于满足我们要求的BPMN元素。图9显示了我们需要的刻板印象： 通过定义的原型，我们可以使用块在SysML模型中建模BPMN元素。我们通过以下方式将这些块与需求连接起来满足关系，以显示流程的哪些元素满足哪些要求。此外，我们在表示BPMN元素的块之间使用项目流来间接地将数据项与需求关联起来。图10显示了表示满足贷款申请原子需求的BPMN元素的块，以及它们之间的项目流。 这种重量级的形式化在需求分析和管理方面提供了一系列优势。满足关系和刻板印象有助于追踪BPMN元素到需求，反之亦然，从而记录与需求相关的流程设计选择。SysML模型以及BPMN、DMN和SDMN模型可以成为支持更改管理的软件系统中唯一的真实来源，例如，通过自动确定哪些需求可能会受到流程或数据更改的影响。
5.4. 约束形式化与需求验证
重量级形式化也可以为自动需求验证奠定基础。确实，使用约束块可以定义形式和/或非正式方程来验证给定的需求是否得到满足。在我们的上下文中，可以验证我们的要求并在方程式中充当参数的属性是过程参数，例如任务的持续时间、过程的持续时间或事件发生的次数。
例如图7可能是约束块中显示的延迟如所示图11.给，是整个流程的执行时间（以小时为单位），是3天后触发中间计时器捕获事件是发送任务的次数通知延迟已运行。等式右侧表示，当且仅当流程持续72小时以上（即3天）时，才会触发事件并运行任务。这个由方程式计算的变量告诉我们是否满足时间要求。图12显示了流程元素块的修订版本，添加了新的块和属性，用于建模与约束方程变量相关的流程参数。 最后，使用参数化图表可以将这样的约束变量连接到BPMN元素块的属性，并可视化验证时间要求和的属性过程块，如所示图13. 如果每个需求都有一个类似的设置，并且有一个系统可以评估给定过程属性值的约束，那么就可以自动验证需求。此外，通过使用基于业务流程模拟（BPSim）的流程模拟工具[18]标准中，可以将约束中涉及的块属性映射到等效的BPSim参数，然后使用仿真生成用于需求验证的值。然后可以使用过程模拟来执行不同类型的分析，从评估过程更改对需求的影响，到识别导致需求冲突的边缘案例。 值得注意的是，集成系统模型的形式化允许使用模型驱动方法将验证步骤大体自动化，这些方法将系统模型作为输入，并将准备执行的相应仿真模型作为输出，如[19,20]. 6.结论
在本文中，我们提出了一种方法，该方法支持定义连接需求、过程和数据的正式标准模型。
特别是，我们提出了一种三步方法，从使用AHA-BPMN（轻量级BPMN扩展）形式化的需求定义开始，并将其转换为标准BPMN、DMN决策模型和数据对象的组合。然后使用UML类图进一步形式化数据对象，并通过SDMN图链接到BPMN和DMN工件。最后，我们使用SysML块定义图将这些元素链接到通过需求图建模的需求。
最终的形式化有助于跟踪BPMN元素到需求，并可以用作基于仿真的自动需求验证的基础，这将是我们未来研究的主要部分。在这方面，建议的方法可以被视为开发数字孪生兄弟的第一步，这将在物理系统的适当监控和指导方面带来显著优势。
该方法是通过一个简单但有效的案例研究提出的，然而，该案例研究并不排除其应用于可能包括关键路径、错误和异常的更复杂过程。事实上，BPMN标准引入了几个元素来建模如何在流程中管理错误和异常，例如边界事件和事件子流程。模型的复杂性（以元素数量衡量）可以通过中描述的分层建模风格等方法进行控制[21]. 同时，可以将最后一步中使用的SysML图视为与系统需求和满足这些需求的BPMN元素无关。 此外，所提出的方法可以以增量和迭代的方式处理模型，例如，从成功路径开始，逐步添加更多元素来表示过程中的其他路径。事实上，支持我们方法的软件工具的实现工作正在进行中。此类工具将包括一个工具，用于导航模型的不同级别，以及在考虑到相关数量的异常后，管理BPMN模型中可能显示的大量路径。
有了这样一个工具的帮助，我们将能够将我们的方法应用于更广泛的各种不同的现实案例研究，以验证其通用性，并收集有助于提出一些有效性度量的数据。事实上，正如已经指出的那样，我们的“重量级模型”可以被视为实现关键业务流程的数字孪生的基础；因此，我们的想法是利用数字孪生质量指标，例如[22]进行评估。
