多变体建模在工业自动化中的应用-优快云博客

工业自动化管理中软件派生的多变体建模与实现

摘要

工业自动化管理（IAM）系统属于信息系统领域。IAM系统包含支持制造过程的软件组件。IAM的操作部分协调高度即插即用的硬件设备。这些功能导致了过程和拓扑变异性，从而在实践中给软件工程师带来了开发和复用方面的挑战。本文提出了一种方法，旨在改进西门子内部一个IAM软件族的开发与派生。该方法将特征建模与领域特定建模语言（ DSMLs）相结合，用于变异性表示。此外，通过结合代码生成技术，可变性模型的配置可用于自动化软件派生。我们报告了一项在实践中应用该方法的案例研究。结果表明，引入领域特定建模语言增强了变异性表示能力，并提升了软件派生自动化的水平。最后，我们总结了执行该案例研究过程中获得的经验教训。

关键词
基于模型的工程，领域特定建模，软件产品线，变体建模，软件派生，代码生成

引言

大型项目在软件与系统工程领域受到越来越多的关注。
高度集成的软件和硬件设备使得IT解决方案更加高效，同时也给开发带来了更高的复杂性。在本论文的背景下，我们聚焦于工业自动化管理（IAM）领域。这些系统是用于管理制造过程的信息系统。
并在工厂中协调分布式硬件设备，例如用于汽车或食品生产。
在此领域中，软件的开发与复用极具挑战性，因为其实现受到许多不同因素的影响，从客户需求到硬件分布的约束。
软件产品线工程（SPLE）是一组用于管理和维护核心资产，并在新软件产品开发过程中系统化地重用这些资产的技术。众多公司和组织已采用SPLE，并报告了显著的效益，例如降低了开发成本并缩短了上市时间[6]。本文阐述了如何在智能自动化制造（IAM）环境中应用SPLE，并进行必要的调整以支持变体建模和产品派生。最终目标是帮助开发团队在开发新软件系统时节省时间和精力。
SPLE可以通过两个过程来表征：产品族工程（也称为领域工程）和应用工程[15]。在产品族工程中，识别产品族的共性和变异性。开发并管理可重用制品作为核心资产，例如需求场景、可重用架构和可重用组件。在应用工程中，使用变体模型选择和配置可复用资产，以满足客户特定需求。
变异性是SPLE中的核心概念之一，因为它描述了产品之间的差异方式。许多变体建模技术已被提出并在学术界和实践中得到应用，例如特征建模、决策建模和正交变体建模[8]。
然而，IAM系统具有过程和拓扑变异性，这给变体建模与表示带来了困难。通用的变体技术（如特征建模）在表达这两种领域变体类型[12]方面存在局限性。在IAM系统中，过程变异性源于客户所需的可变制造过程，而拓扑变异性则来自制造工厂中硬件设备的灵活配置。当前实际中的IAM开发过程繁琐且耗时。建立一个派生基础设施以促进IAM开发被领域专家认为是有用的，正如我们在先前研究[13]中指出的那样。
本文提出了一种基于模型的方法，该方法将特征建模与用于表达过程和拓扑的领域特定建模语言（DSMLs）集成在一起。这三种类型的变体模型在技术解决方案空间中相互关联并得以实现，使我们能够提供半自动化支持以派生软件架构并生成源代码。我们报告了将该方法应用于西门子某仓库管理系统软件族的案例研究。案例研究结果表明，使用领域特定建模语言有助于实现以用户为中心的可变性表示。此外，将领域特定建模语言集成到派生过程中可实现更细粒度的复用。
本论文的贡献有两方面。首先，我们在一个复杂的软件领域中提出了一种基于多模型的工程方法。我们整合了多个模型，并利用代码生成技术加以实现，以节省软件开发的工作量。其次，我们报告了在工业级案例研究中应用该方法的结果。我们评估了多变异性建模的可行性、表达能力以及代码生成的改进情况，并总结了本研究中的经验教训。

2. 动机

本文的动机源于IAM系统的软件架构师和开发人员在开发过程中报告的不满。交付给客户的产品通常构成工厂的完整解决方案。此类解决方案包括软件和硬件系统，并涵盖整个生命周期，从分析、设计、开发到安装和维护。IAM系统不仅在实现客户的业务中发挥作用，还负责管理底层的软件和硬件系统。在这种情况下，需求的来源不仅仅是客户。硬件决策和限制也对软件实现产生重大影响。软件工程师需要理解并应对所有这些需求和限制，因此在开发过程中感到极具挑战性。
为解决这一问题，我们选择西门子开发的软件产品族—— 仓库管理系统作为案例研究，以实现面向IAM系统的基于模型的方法。仓库管理系统是工业自动化管理中的一个典型子领域。制造商、进口商、出口商和物流企业使用仓库进行货物或产品的存储。仓库管理系统具有类过程功能，如收货、存储、拣选、包装和发货。图1展示了一个小型仓库布局中执行这些任务的功能区域。该布局中的箭头表示物料流，在IAM领域中常用于表示制造材料在工厂中的运输、存储、供应和组装过程。

示意图0

2.1 建模的多变异性变体类型

变异性是指“软件系统或工件在特定上下文中能够被高效扩展、更改、定制或配置的能力”[24]。应用工程活动依赖于可变性配置。基于变体模型的可变性配置，可以高效地派生出新软件产品以满足客户需求。
许多变体建模技术已被提出并在学术界和实践中得到应用[8]。在所有现有的变异性建模技术中，特征和决策建模受到了最多的关注[10]。特征或决策模型能够表示类似的变体，例如必选、可选、替代、多重性和基数性。在本研究的背景下，我们将这些变异性称为类特征变体。IAM系统具有此类类特征变体，许多其他软件产品线也普遍存在这种情况。此外，IAM系统还具有拓扑和流程变异性。

拓扑变异性

图2显示了两个不同客户的仓库厂房中收货区的简化布局。左侧， Customer 1配备了一台自动入库叉车和一个手动入库工作站，而右侧， Customer 2至少配备了三个手动入库工作站。可以看出，各种设备安装在厂房地面的不同位置。这些设备在客户之间具有高度可复用性和即插即用性。这种变异性源于所有这些设备的灵活组合，因为理想情况下，所有设备都可以直接接线或通过通信网络连接。

示意图1

流程变异性

在上述示例中，两位客户具有两种不同的拓扑配置，并且他们都要求在各自的工厂中采用手动收货过程。图3展示了一个在客户之间共享的非正式过程描述。其中 Quality Control是该过程中的可选活动。此外， Receive Goods’ Notifica-tion活动必须绑定到每个客户项目的特定拓扑配置。只有当软件系统接收到箱子到达相应位置的通知时，此过程才能被触发。

示意图2

拓扑和流程变异性是领域特定变异性类型。当尝试使用通用变异性建模技术来表达它们时，会导致困难[12]。为了为目标领域提出系统的软件产品线工程方法，对拓扑变异性、流程变异性及其相互关系进行建模至关重要。

2.2 派生过程和利益相关者

Software product derivation包括选择和配置现有工件以创建新产品来满足客户特定需求的活动。特征建模通常用于实现软件产品衍生。
然而，智能自动化制造中的产品派生具有其特殊的顺序。
我们确定了三种派生相关方角色，包括需求工程师、面向硬件的工程师和软件开发者。这三种角色的相关方参与了智能自动化制造开发中的顺序推导过程：
1. 需求工程师主要关注过程变体。过程作为非正式行为模型，描述了系统的行为，这些行为更接近物料流，能够直接反映现实世界工厂中应发生的情况。
2. 面向硬件的工程师关注拓扑可变性问题。在实际环境中，他们通常不仅是来自硬件团队的关键工程师，也来自需求和开发团队。他们会共同参加会议，沟通拓扑配置。分布式硬件设备与IT信息系统最终需要集成以执行实际的制造任务。因此，面向硬件的工程师在软件和硬件团队之间起到“桥梁”作用。
3. 软件开发者需要理解利益相关者的另外两个角色。他们还需要了解所需应用程序的过程和拓扑配置，以便将它们整合在一起并实现最终的IAM系统。

2.3 挑战分析

由于IAM系统的软件族具有显著的共性，我们期望引入 SPLE技术以实现复用，从而为软件开发组织带来显著效益。
为了开发一种系统性的方法，必须解决两个主要挑战：（1）需要进行以用户为中心的变体建模；（2）需要自动化派生过程。
首先，智能自动化制造的软件产品线工程方法应支持在产品派生相关方的语言中表示变异性[22]。基于模型的技术，特别是领域特定建模语言（DSMLs），在超越软件系统抽象层次的级别上对其进行规约代码，使用更接近问题空间[28]的表示法。同时，使用针对领域的定制化语言有可能带来改善三个已识别利益相关者之间沟通的好处[25, 19]。鉴于这些预期的好处，希望将领域特定建模语言集成到该方法中，以表达过程和拓扑变异性，实现以用户为中心的变异性建模。
其次，当在应用工程阶段涉及多种可变性模型来配置系统时，重要的是将它们系统地集成到顺序推导过程中。通过这样做，派生过程可以利用多可变性模型的优势，实现更高水平的自动化和更优的效率。

3. 方法

图4展示了该方法的概览。它包含三个主要元素：多变体建模、多变异性实现以及集成推导过程。我们简要描述这三个主要元素。接下来的三个小节将通过在我们的仓库管理系统案例研究中的应用，分别对它们进行详细阐述：

示意图3

multi-variability modeling 包含三种必需的变体类型、它们的元模型以及元元素之间的关联。
multi-variability realization 解决变异性在技术上的实现方式，以便通过使用变体模型来选择和配置软件工件。为此，变体模型中的元元素需要与产品线核心资产中的软件工件（如组件和源代码）相关联。
在我们的方法中， semi-automated derivation process 可以进一步分为三个阶段：准备、配置和生成，如图4 所示。手动配置阶段由工具支持，使利益相关者能够专注于自身的变异性问题和配置。

图4还表明，这两个解决方案部分位于产品族工程中，而派生过程位于应用工程中。但是，支持派生过程的派生基础设施的开发也是在产品族工程中完成的。在软件产品线工程方法中，通常在产品族工程上投入更多精力，以在应用工程中获得生产力和复用性。
该方法的创建、开发和工业应用受到仓库管理和汽车制造系统的启发。在本研究中，我们专注于使该方法适用于所选的西门子仓库案例研究。原因是所开发的领域特定建模语言、语言编辑器和变异性实现都是领域特定的。

3.1 多变体建模

图5展示了多变体建模框架的架构，该架构遵循元对象设施（MOF）[2]定义的四层架构。该框架包括用于表示通用软件共性和变异性的特征建模，以及两个用于表示拓扑和过程的领域特定建模语言。我们将在本节余下部分介绍在M2层中开发的元模型。

示意图4

3.1.1 特征元建模

特征模型是一种树结构，由一组特征节点和特征节点之间的关系集组成。由于特征建模是一种事实上的变异性建模技术，许多研究人员提出了可用的元模型作为特征建模的 “方言”。图6a展示了我们方法中所使用的特征元模型的一个片段。它包括 Features和 Feature Relationships（具体的特征关系子类型，即必选、可选、替代、或关系，为简洁起见未列出）。图6b展示了特征树的典型表示法。不同的关系类型用空心圆和实心圆以及弧线表示。

3.1.2 拓扑元建模

拓扑模型包含工厂某一区域内的若干拓扑元素及其关系。
所开发的拓扑元模型由两部分组成：核心元模型和补充元模型。
图7展示了核心元模型，其中拓扑模型可以拥有任意数量的拓扑元素。一个Topology Element可以被分配到另一个元素。
Transporter Element和 Stationary Element是 Topology Element的两个子类型。传输器指工厂中用于运输的元素，例如传送带，用于将工作单元从一个位置运送到另一个位置。静态元素通常是固定设备，负责在工厂中实际执行具体的制造任务。这些制造任务可以完全自动化、半自动化，或由人工操作员手动完成。

图8展示了补充拓扑元模型的一个片段，其中包含 Transporter Element、Stationary Element 的子类型。这些补充元素是仓库管理系统子领域特有的。其他子领域（例如汽车或食品生产）可能共享其中一些元素，也可能需要其他元素。

3.1.3 过程元建模

过程模型包含一组动作节点和边，用于描述系统功能的行为流。图9展示了所开发的过程元模型，其中我们区分了不同类型的动作以描述过程。有些动作是信息系统中典型的，例如 Computational Action和 Human-System Interaction。还有一些领域特定的动作。 ManualAction可用于建模由人工工人执行的手动步骤，这在制造工厂的非自动化任务中很常见。
Automatic Action用于表示由硬件设备执行的自动化任务，但通常这些任务由Software Actions进行协调或触发。
Periodic Action通常具有循环时间以重新执行。

3.1.4 分层关联元模型

出于表示目的而建立多个（领域）变体模型并非此方法的最终目标。它们之间的关联是必不可少的，以便它们可以在派生过程中被系统地实例化和集成。图10 显示了在我们的方法中特征、过程和拓扑（元）元素是如何关联的。

特征可以分层包含子特性。它们与组件和子组件相关联，用于描述软件产品线架构。当某个组件具有进一步的过程或拓扑变异性时，相应的变体模型将被添加到模型套件中。这样的模型套件包含了变体模型的名称、类型等信息。每个涉及的模型都可以拥有在产品族工程期间提取的模型模板。在应用工程过程中，这些模型通过适当的模板进行实例化，以作为基础配置，帮助推导相关方实现更高的配置效率。
Features和领域特定的变异性 Models之间也可能存在隐性关系和依赖性。例如，一个特征可能对另一个特征产生弱建议——或者可能需要在过程模型配置中进行更详细的描述。已有研究提出了针对这类关系[30, 14]的解决方案。在我们的目标系统中，我们识别出过程和拓扑模型之间的领域特定关系。
在过程模型中，可能存在某些与特定拓扑位置绑定的动作（见图3中的示例）。为了在模型中描述这种情况，我们需要 Action和 Topology Element之间的 boundToLocations关系，如图10所示。

3.2 多变体实现

基于已建立的多变体元模型及其关联关系，我们进一步提出了其实现我们方法在技术实现空间中的多变异性。通过变体实现，可以通过实例化和配置变体模型最终选择和配置可复用软件构件。
变体实现可能出现在两个不同的抽象层次上[29]：
- 架构级别：典型的可复用资产包括产品线架构、组件和框架。变体可能是可选组件或架构重组[24]。
- 代码级别：共性是软件产品线中的类集合。可变部分 “嵌入”在代码片段中，需要通过组合这些代码片段 [29, 24],来实现变异性。

在架构级别，我们目标领域的变体实现与其他软件产品线类似。在此级别上，类特征变体在组件包含或排除中起着最重要的作用，这一点已被诸如[29]等一些现有方法所提出。图 11展示了一个小示例，说明了在架构派生过程中通常如何解决类特征变体问题。 Pick by Light是一个可选组件。当在配置中选择了对应的特征时，派生基础设施会在架构派生期间包含 Pick by Light的源代码，并将其实例连接到 Pick Logic组件的适当实例。在此示例中，组件的参数（例如 Pick Logic的 mode）也可以通过选择并配置对应特征的值来进行配置。

在代码级别，智能自动化制造系统的变体实现需要解决过程和拓扑可变性。图12的上部显示了所涉及的可变性建模构造，部分内容已在图10中介绍。下部展示了以代码生成形式呈现的可变性实现机制，以实现软件派生的自动化，这是我们工作的主要目标之一。

如图12所示，我们提出了多变异性模型中元素之间的三种关联类型。以下将对每种类型的实现进行解释和说明：
- 推导相关方或建模者在过程模型中指定行为序列。过程模型中的操作隐含了顺序关系[30]。在此背景下，可重用制品是每个操作的独立实现。实现这种关系需要根据过程配置中的顺序 assemble可复用的操作代码。该组装通过生成调用所需的“胶水代码”来实现。
- 该关系已在图10中引入。建立此关系的目的是表示某个动作需要在工厂内的特定位置执行。该关系的实现依赖于装配和值遍历。
- Logical Group: 以对软件服务与其相应的拓扑元素之间的逻辑关联进行建模。建立这种关联的原因是软件服务需要管理和监控不同的拓扑元素。图13显示了两个逻辑组。对于组1，两条迷你装卸传送带和两个缓冲区属于位置跟踪组件的逻辑组，该组件用于监控箱体的运输进度。对于组2，缓冲区管理组件在此示例中仅协调这两个缓冲区。每个逻辑组内拓扑元素的基数导致了变异性。我们通过拓扑模型内模型实例的 type traverse或 value traverse来实现这种变异性。

3.3 半自动派生过程

基于多变体建模与实现，我们建立了如图14所示的派生方法。该过程的初始版本已在我们的先前研究[13]中报道过。我们的方法包括三个主要阶段：准备、配置和生成。准备和生成是两个（半）自动化阶段，旨在减少派生相关方的工作量。配置阶段仍为手动但工具支持，在该阶段中，过程变异性、拓扑变异性及其相互关系由三种不同角色的利益相关者根据其关注点进行配置（见第2.2节）。通过这种方式，我们实现了以用户为中心的变体建模。

准备：这是一个半自动化的活动。此步骤通过可复用的模型模板和模型片段准备基础配置，以帮助派生相关方，使他们无需从头开始“构建”一个复
- 1.1: 作为第一步，派生相关方可能已经将基于特征的变异性（特别是更高抽象层次的全局特征）进行了绑定。
- 1.2: 派生基础设施会解释与组件相关联的已配置特征（参见图10中所示的关联），然后自动生成一个建模空间，并实例化所需的流程和拓扑模型实例，以准备进一步的配置。
配置：在我们的目标领域中，不同变体类型的手动配置通常以迭代方式进行，特别是当过程和拓扑可变性相互交织时。
- 2.1: 推导相关方配置来自步骤1.2的已实例化的过程和拓扑模型。
- 2.1.1: 需求工程师配置过程模型实例以指定目标系统的行为。
- 2.1.2: 面向硬件的工程师配置拓扑模型实例，以描述目标系统的配置。
- 2.2: 软件开发者细化已配置的过程和拓扑模型，将过程元素与拓扑元素关联，并在必要时添加细节或纠正错误。
生成：根据已配置的特征、过程和拓扑模型，此派生活动会自动生成特定应用架构和源代码作为（部分）产品。
- 3.1: 代码生成引擎在架构层面实现变体性，主要通过组件的包含与排除。此步骤的输出是最终推导步骤的中间工作流。
- 3.2: 代码生成引擎使用在3.1中创建的中间工作流，并派生应用程序。

由于我们的目标系统属于灵活的软件产品线类别，因此我们预计始终需要一个特定应用开发阶段，以最终满足所有客户需求。软件架构师、开发人员和测试人员可能都需要参与特定应用开发。

4. 案例研究

进行此项案例研究的总体目标是从实际环境的角度理解所提出方法的可行性，并评估其在实际环境中的改进情况。
我们选择西门子仓库管理系统中的一个复杂组件作为本案例研究的对象，因为该组件在领域复杂性方面具有典型代表性，能够得出有意义的结果。该选定组件包含七个子组件，其中两个为可选组件。根据领域专家的经验以及对遗留项目的分析，该组件的规模通常在10000代码行数（LOC）左右。在此软件族中，高度可复用的实用功能（如日志记录或数据访问）已由软件族的基础设施处理。目前，针对每个项目，该选定组件的代码均为手工编写。
该案例研究根据[23],进行规划，其中包含规划、执行、收集数据以及最终报告结果的任务。我们计划从以下三个方面对结果进行表征和评估：
除了特征模型外，我们还引入了两种用于建模过程和拓扑的领域特定建模语言。我们期望通过使用多变异性建模与实现，能够建模和表达组件的更多需求。所期望的结果是理解并刻画选定组件在多大程度上依赖于三种变体类型。
该方法应应用于现实世界环境和场景中。在使用该方法时所付出的努力，尤其是在产品族工程期间，应是可承受且合理的。
该方法提供了一种半自动化的软件派生过程，支持模型实例化和代码生成。我们期望该方法能够提高派生与开发的效率。

4.1 执行流程

本小节描述了在选定主题上进行案例研究的过程。遵循软件产品线工程中的产品族工程和应用工程过程，我们的案例研究过程也分为两个阶段。

4.1.1 家族工程流程

在开始此案例研究之前，我们已按照第3.1节中介绍的方法进行了领域分析和语言工程。我们在建模平台 MagicDraw[1]之上开发了两个领域专用建模编辑器。该实现基于UML配置文件，在其中将元类定义为构造型。此外，我们建立了派生方法的基础设施。整个开发过程分布在15个月的时间跨度内。我们的方法旨在覆盖仓库管理系统领域的更广泛的范围。特别是，我们验证了西门子内部和外部仓库管理系统中的领域特定建模语言，共有7位领域专家参与。我们估计这些工作耗时约为7‐10人月。
在此基础上，一位具有基于模型的开发经验的工程师和一位来自西门子的仓库管理系统架构师参与了该案例研究的执行。
关于选定组件的流程分为三个步骤：
- FE1. 确定架构 ：不同客户的多个遗留项目中均存在此组件的变体。尽管这些项目由同一团队开发，但在结构上仍存在细微差异。我们基于其中最成熟的组件变体开发了可重用架构。
- FE2. 识别并定位代码中的变异性 ：在执行此步骤期间，我们识别并建立了可变性（元）模型与技术解决方案空间之间的追溯关系。例如，我们将可选子组件与特征相关联。在子组件内部，我们定位了具有关键可变性类型的源代码片段，并将相应的模型作为核心资产的一部分进行添加。
- FE3. 提取可重用代码资产 ：没有变异性的类可以直接添加到核心资产库中。对于具有变异性的类，需要进行重构步骤，以分离公共部分和可变部分。在简单情况下，通过类特征变体实现来包含可变的实现部分（参见第 3.2节）。对于过程和拓扑变异性，提取了代码模板，遵循组装、值遍历、类型遍历或混合组合的实现模式（参见第3.2节）。

在步骤F3中，为了开发和提取可复用的代码资产，我们应用了[18],中建议的几种重构模式，例如钩子方法、移动类、在方法末尾添加。在本案例研究中，我们使用Xpand作为模板语言来实现变异性[3]。

图15展示了一个代码模板示例，用于通过钩子方法组装类，以实现流程变异性中的顺序关系。该模板从其目标包中选择所有 PeriodicAction类型的操作。它为每个操作生成一个类（第7行）。在生成的类中， WakeUp和 NextStep方法分别分离当前操作的业务逻辑以及调用下一个操作的胶水代码。可复用的业务逻辑通过专用模板引入（第10行）。在第17行，代码模板搜索操作的输出边，并生成代码以“唤醒” 下一个操作。
Xpand支持的模板语言允许对元素进行过滤和迭代的其他组合，我们利用这些组合实现了与位置绑定的关系和逻辑组。
最后，我们将开发的可复用代码模板作为核心资产添加到派生中。

4.1.2 应用工程Procedure

在应用工程中，根据第3.3节中提出的派生过程，使用特征、过程和拓扑模型来配置系统和派生产品。理想的验证方法是将采用所提出方法与不采用该方法在面对全新客户需求时的开发时间进行比较。由于这在实际中不可行，我们转而重放了派生过程基于先前执行项目的原始需求进行派生。派生步骤如下：
- AE1. 准备 ：我们首先配置了特征，派生基础设施实例化了需要进一步配置的过程和拓扑模型。图16的左侧展示了一些这些模型的示例。
- AE2. 配置 ：我们使用开发的过程和拓扑编辑器来配置已实例化的模型。图16还展示了两个编辑器的截图，示例中显示了将一个动作绑定到其通知位置的过程。
- AE3. 生成 ：派生基础设施采用所有已配置模型来生成特定于应用的架构和源代码。我们使用原始项目中的适用单元测试（根据需要进行调整）以及代码审查来验证生成的代码。

4.2 案例研究报告

完成上述步骤后，我们收集了数据以获取用于表征、评估和讨论的证据。本节报告了相关结果。

4.2.1 表征变体模型

表1展示了为选定复杂组件识别出的可重用可变性元素类型。我们识别了16个特征，包括决定组件包含的与架构相关的特性以及代码级特性。对于过程，识别出8个带有过程模板的可复用过程模型，共计31个可实例化的可重用操作。对于拓扑，该选定组件需要一个拓扑模型，可能包含8种不同类型的拓扑元素。基于这些结果，可以看出这两种领域特定建模语言显著丰富了变异性表示的建模空间。

	特征	过程		拓扑
	编号	模型	操作	模型	元素
编号	16	8	31	1	8

在七个子组件中，有两个是高度过程可变的，两个是高度拓扑可变的。其余三个子组件则具有或多或少分散的变体类型。一些代码部分包含了两种或三种交织在一起的关键可变性类型方式。根据我们的经验，减少代码中变体类型的纠缠可使代码模板的提取更容易，但会增加重构的工作量。
我们观察到，工厂中所建模的拓扑元素对软件派生的重要性各不相同。Discussion:在多个不同的 logical groups中频繁出现，这意味着它们比Transporter Elements更常被软件组件观察或交互。其原因是它们的事件更有可能触发过程或业务逻辑。相比之下，Transporter Elements通常仅由监控服务跟踪，涉及较少的业务逻辑。

4.2.2 评估可行性

如产品族工程流程中所述（参见第4.1.1节），我们的案例研究基于已开发的领域特定建模语言、语言编辑器和派生基础设施，这些成果旨在覆盖仓库管理系统领域的更广泛的范围。
该案例研究在产品族工程上花费的时间略少于100小时。
这包括以下活动：(F1) 确定架构，(F2) 识别并定位变异性，以及 (F3) 提取代码模板（参见第4.1节）。参与的软件架构师表示，实现此类组件通常每个项目需要2到3人月。他确认该案例研究能够展示在实际环境中应用该方法的可行性。此次经验相当令人鼓舞，意味着有很大可能将该方法进一步应用于该软件族中的其他复杂组件。
Discussion:多个因素已被证明对这种软件产品线工程方法的可行性至关重要：
- 参考架构的成熟度 ：在我们的案例研究中，针对可复用组件架构的决策过程相当迅速，工作量大约为1天。原因是该组件现有的参考架构已经较为稳定，并且在复用方面表现令人满意。在这方面，组件的成熟度水平至关重要。每个软件族、每个组件，甚至同一系统内的每个工件，其成熟度水平都可能各不相同[6]。提高目标系统或组件的成熟度可能需要大量投入，这将增加所需的重构工作量，而在最坏的情况下，可能导致该方法在经济上不可行。
- 该领域的成熟度如何 ：博世[6]指出，并非所有系统都需要或能够提升其成熟度水平。这取决于该领域的变异性程度，以及变体模型能否简洁地捕捉需求和实现中的变异性。仓库管理是西门子业务中一个相对成熟的领域。负责该产品系列的工程师已积累了丰富的领域和技术知识。
- 产品族工程开发过程中的可访问资源 ：事实证明，仓库管理系统的架构师参与决策和变异性挖掘步骤至关重要。此外，建模和代码生成方面的专业知识也非常重要。这可能会带来另一个风险，因为并非所有开发团队都常规具备此类专业知识。

4.2.3 评估派生的自动化程度

表2展示了所开发的可复用资产库的类型和规模。在我们的场景中，与代码相关的资产包括用于可变代码的Xpand模板以及不含变异性的C#类。此外，针对派生基础设施，我们开发了用于模型实例化和代码生成所需的工作流和脚本文件（参见第3.3节中的自动化步骤），这些作为派生基础设施的输入，支持自动化。

资产类型	格式	LOC
具有可变性的代码	Xpand代码模板	5130
直接可复用类	C#	2399
基础设施的输入	MWE工作流程和构建	513
总计		8042

按照应用工程的案例研究流程，我们根据两个遗留项目的已知需求，选择了特征，配置了实例化的过程和拓扑模型，并派生了代码。目标是评估自动派生和代码生成的效果。表3展示了项目1（P1）和项目2（P2）中已配置的特征、复用的过程操作、实例化的拓扑元素以及自动生成的源代码。

	特征配置。	过程	拓扑	具体代码行数
	特征配置。	操作	实例	具体代码行数
P1	16	29	51	5027
P2	12	24	67	4194

派生项目‐P1和P2的原始手工编写代码行数分别为11530和9869。
将表2中显示的共用2399代码行数与表3中的派生项目特定代码行数相加，这两个项目的生成代码可达到 7000+和 6000+ 代码行数。需要强调的是，由于在产品族工程中进行了重构，生成的代码不能直接等同于手工编写的代码。因此，我们进行了进一步的代码审查。审查结果表明，对于P1和P2，生成的代码均可替换超过60%的原始手工编写代码行数，这是一个令人满意的代码替换结果。
请注意，仍有四个类的复用可能性非常低，我们只能在其中添加一些桩方法。生成。此外，我们认识到该案例研究的结果也包含显著的主观因素。特别是，在改进代码模板上投入更多精力，甚至重构软件架构，都将对结果产生重大影响。
我们观察到，具有拓扑可变性的组件可以达到几乎完全自动生成的程度，而过程可变组件则无法达到相同的自动化水平。参与的架构师反馈称，这种情况实际上符合他的预期。
拓扑可变性的实现基于类型或值遍历，这些在模板语言中得到了良好支持。而过程的实现需要组装资产中的可复用代码片段。因此，对于过程可变工件，他期望生成更多的“胶水代码”，特别是当过程中指定的操作在资产中找不到可复用的匹配时。在这些情况下，开发人员必须手动实现业务逻辑。

4.3 经验教训

首先，我们发现最终确定的可重用架构与该选定组件的文档化参考架构存在差异。文档化的参考架构缺乏足够的细节来支持代码生成。其次，重构要求将可变代码集中到特定位置，例如代码模板中，从而“凸显”了架构中的非可变代码。由于这一点，我们能够找出表2中列出的直接可复用类，这些类之前是手工编写的，但实际上早已具备可复用性。第三，我们也认识到，为复用而开发的架构并非降低代码复杂度的最优解决方案。核心资产中的代码生成模板旨在覆盖大量变体，因此在一定程度上必须牺牲软件架构和代码的可理解性，以换取可生成性。
Using the DSMLs improves the willingness of modeling。
领域特定建模语言能够实现问题空间中的需求与解决方案空间中的技术实现之间的细粒度关联。这成为“建模者”在手动配置期间指定 pro- 的动机。
架构师指出，需要在过程和拓扑上投入更多的精力和关注。
他强调，采用这种方法，建模的输出结果会对最终系统产生影响。这相较于当前实践状态是一个显著改进，在当前实践中，需求工程师仅以非正式方式描述过程，并将其交给面向硬件的工程师和软件工程师，而这些过程仅被视为需要理解的输入。与这一情况相比，我们的方法实际上鼓励利益相关者产出更高质量的模型。
我们案例研究的最初目标是将所有可生成的代码与手写代码严格分离，以优化代码生成率。在重构过程中，结果表明需要做出重大权衡。尽管存在一些已知的模式，例如钩子方法、重写机制或局部类，但这些模式通常仅对规模较大的代码块才具有价值。因此，我们仅追求在一定程度上实现复用，避免过于细粒度的复用，从而避免增加架构的复杂性。
在我们的情况下，答案取决于建模的目的。在DSML工程阶段，我们倾向于引入更多的拓扑补充元元素（参见图8）。
例如，可能存在多种不同类型的传感器、电机等。很快我们认识到，在目标领域中，并非所有现实世界元素都需要为软件派生这一目的而建模。当主要目标是表示该领域时，更全面的模型是可取的。然而，当已配置模型的输出作为软件派生的输入 “语言”时，限制领域特定建模语言的规模和复杂性就显得尤为重要。并非所有来自现实世界建模的信息和实体都对软件派生是必要的。

5. 相关工作

本节讨论相关工作，重点是解决多种变体类型的方法。我们之前的一项工作[13]报告了一种技术推导基础设施以及派生过程的初始版本（参见第3.3节）。本文与之前的工作不同，侧重于变异性建模与实现，并且还报告了在实际环境中应用该方法的案例研究。
许多现有研究提出了针对拓扑或流程变异性的方法。在建模拓扑变异性方面，Behjati等人提出了Simpl[4]作为一种方法论，为用户提供多个视图来指定集成控制系统（ICS）。
在Simpl中，软件、硬件及其之间的依赖关系的变异性在不同视图中呈现。Urli等人提出了SpineFM[27],，这是一种工具支持的方法，将领域模型与特征模型相互关联。SpineF M通过传播机制实现无序配置过程，帮助用户执行任务。
Berger等人区分了特征或决策类变异性与拓扑变异性，并通过火灾报警系统领域的案例研究[5]报告了使用建模方法处理拓扑变异性的适用性与挑战。Dhungana等人提出使用领域建模来表达变异性产品族的层次结构和多重性[11]。我们受到这些方法的启发，例如Simpl和SpineFM。然而，这些方法均未明确地处理特征、拓扑和流程变异性，并将其与IAM系统中常见的复杂派生过程集成。
也存在一些旨在解决流程变异性的现有研究。例如，Gr¨ oner等人提出了一种针对业务流程族的配置与验证方法，该方法将特征模型、流程模型模板以及这两类模型中元素之间的映射关联起来[14]。这些业务流程通常具有可直接在工作流引擎上运行的执行语义。然而，业务流程并未涉及智能自动化制造（IAM）领域中的物料流问题。如果不扩展现有的表示法，则无法表达IAM领域特有的变异性，例如过程与位置之间的绑定到位置关系。布朗等人提出将行为模型附加到特征节点上，以弥补特征建模的表示局限性[7]。海因策曼和贝克尔提出采用统一建模语言（UML）的改进概念——机电一体化 UML（MechatronicUML），以实现复杂软件组件在自适应机电系统中的分层重构[16]。皮莱等人提出一种应用于打印机纸张处理的基于模型的方法，用于控制软件生成[21]。特拉斯克等人将模型与无线电领域的软件产品线工程（SPLE）相结合[26]。上述方法在IAM领域中的局限性在于未考虑拓扑变异性。
多种模型类型之间的约束和一致性检查有可能提高手动配置阶段的效率，但尚未集成到我们的方法中。例如，科瓦尔和谢弗提出了一种增量一致性检查方法。他们指出，一致性检查具有多个范围和层次[17]。聂等人提出了针对信息物理系统背景下产品配置的自动化支持[20]。

6. 结论与未来工作

我们提出了一种基于模型的方法，以应对工业自动化领域中信息系统复杂的变异性。该方法包含三个主要部分：首先，该方法利用特征模型来表示常见的变体类型，并采用两种领域特定建模语言来表达过程和拓扑可变性；其次，这三类变体模型与可重用架构和代码制品相关联，为软件派生做好准备；第三，一个半自动化的派生过程集成了特征建模的配置以及两种领域特定建模语言，以提高派生效率。
我们报告了一项案例研究，通过在西门子仓库管理系统软件族中选定的复杂组件上应用我们的方法。结果表明，使用领域特定建模语言可以提升变异性表示的表达能力。通过配置特征、过程和拓扑模型，派生和生成也能达到满意的自动化水平。该方法的可行性已在案例研究的背景下得到验证。
作为贡献的一部分，我们报告了所获得的经验教训。
在未来的工作中，我们计划将案例研究扩展到IAM系统的其他子领域，以进一步评估所提出方法的通用性。我们还计划采访领域专家，了解他们对采用该方法潜力的看法。