论文阅读笔记（二）

参考文献：
（基于案例的推理和系统设计：一种基于本体和偏好建模的集成方法）
[1]Bejarano, Cr J , Coudert, et al. Case-based reasoning and system design: An integrated approach based on ontology and preference modeling[J]. ARTIFICIAL INTELLIGENCE FOR ENGINEERING DESIGN ANALYSIS AND MANUFACTURING, 2014.

考虑到CBR过程非常适合解决系统设计中的一些问题，文章中讨论了系统设计中与基于案例推理（CBR）过程相关的需求和实现，所提出的方法涉及根据系统工程原理的集成CBR过程的定义。在定义了方法必须满足的需求之后，定义了一个本体，以在概念内利用有关设计的知识。基于本体，提供了用于需求和解决方案表示的模型。而后，提供了一个适用于系统设计的递归CBR过程。在需求定义、兼容的案例检索和解决方案定义步骤中，考虑了不确定性和设计者的偏好以及本体指导方针。这种方法的目的是在CBR过程中给予灵活性，并为设计人员提供指导方针。对以下问题进行联合处理：如何指导设计人员确保需求被正确定义并适合检索步骤，在没有可用的相似性度量时如何检索案例，以及如何在检索步骤期间扩大研究范围以获得足够的解决方案。最后，文章以航空领域的系统工程为例说明了所提出的方法。为了对检索算法进行性能评估，开发了一个测试平台，并开发了一个软件原型。这项工作的结果是一个递归的CBR过程，适合于工 程设计和兼容标准。 需求是通过灵活的约束来建模的，其中设计师的偏好被用来表达灵活性。即使特征之间的相似性度量不可用，也可以检索类似的解决方案。同时，本体论指南被用来指导这个过程，并帮助设计师表达喜好。

这篇论文分为四个部分。第一节为导言。在第二节中，介绍了模型、标准、学术设计过程以及CBR过程。然后，根据书目背景，讨论和定义的三个要求，提出了所提出的方法解决。在第三节中，介绍了系统设计知识表 示与需求有关的模型。递归CBR(RCBR)过程在第四节。第五节中，给出了一个例子来说明所提出的方法。并对检索算法进行了实验研究。结论和观点载于第六节。

第一节中，作者主要根据目前解决问题方法的不足点，将文章所要处理的三个宏观要求罗列出来：
① 定义本体论指南，以利用知识，并帮助工程师开发新的系统；
② 提出一种基于合适工程设计标准的系统设计的完全集成的CBR方法；
③ 在集成CBR方法的不同步骤中考虑不确定性、缺乏相似性度量和设计者偏好。

第二节中，这里主要解释一下系统设计的CBR：
用于系统设计的CBR：CBR模型认为先前问题的解决方案，必要时考虑问题描述的差异，作为目标问题的拟定解决方案。因此，这种方法试图通过检索和适应以前解决一个新问题的过程来解决一个新问题。通常，CBR系统通过主要阶段的周期来描述：问题定义、检索、检索、重复使用、修订和保留。这五个阶段的定义如下。

① 问题定义：当问题出现时，对其进行特征，以便与案例基础中的问题进行比较。
② 检索：根据新问题，CBR系统从案例库中检索到与新问题相当相似的先前案例。主要的挑战是定义CBR系统如何将新情况与之前的情况进行比较，特别是在仍然存在许多不确定性的情况下。
③ 重用：大多数情况下，必须适应满足新问题要求的检索案例的解决方案。其结果是一个已解决的案例。它通常被认为是一项关键活动。一些规则通常定义解决新问题的方法。由于不同问题的上下文不断变化，这些规则很难定义和使用。
④ 修订：解决的案例必须修改，转化为修改的案例，换句话说，建议的解决方案转化为确认的解决方案。
⑤ 保留：CBR系统可以通过纳入案例基础来了解新案例。

系统设计的CBR要求：
① CBR过程应与模块化和分层工程设计过程集成：应按照系统工程标准将系统重复使用。将系统分解为为定义子需求而产生的子系统应该用于从案例中检索类似的解决方案。这些解决方案应加以适应以满足子系统要求。每次需要分解时都应递归处理。
② 为了考虑到不确定性和相似度措施的不可用性，并扩大检索的范围，应使用根据客户的需求和设计者的偏好而定义的灵活的约束条件来对需求进行建模。应计算这些灵活的约束和解决方案之间的兼容性度量，以指导设计者检索类似的和合适的解决方案。
③ CBR过程应基于本体，以帮助需求定义过程，促进解决方案开发过程的标准化和可再用性，并促进检索步骤。应将概念与需求和解决方案关联起来，以便在设计过程中使用这些概念中嵌入的知识。检索步骤应连续分为两个阶段：基于概念相似度量和/或偏好选择解决方案，以及需求和预先选择的解决方案之间的深度比较。

第三节中，提出了一个本体，系统建模，解决方案建模以及案例建模。
所提出的本体是一种表示分类法的概念的层次结构。本体的根是最普遍的概念，被称为系统。这个系统的概念没有父母关系。这些概念由表示泛化/专门化关系的边缘连接起来。任何概念都继承了其父母的所有特征。有些模型继承自祖先，另一些则是特定的。
本题中概念特征的类图如下：

系统由一组需求和一个或多个解决方案组成。
① 需求建模：对于要设计的系统，通过需求概念(RC)、与其域相关的需求变量和需求约束来定义需求集。需求变量可以是来自RC的变量模型的副本，也可以是由设计者为更好地描述需求而添加的新需求变量。变量域是域的模型的副本或新添加的需求变量的域的副本。需求约束可以是概念约束模型的副本，或者是设计者为表示特定客户需求而添加的新需求约束。需求约束与一个或多个有序的需求变量相关联，并且一个需求变量可以涉及到许多需求约束中。因此，通过选择一个概念并将其与需求联系起来，设计者知道什么是概念需求变量及其领域以及概念需求约束。这些信息指导设计者引出需求，并通过约束条件将它们正式化。由于需求概念的特征是通用的和抽象的，因此设计者可以添加其他需求变量和约束来正确地定义系统需求。

② 解决方案建模：通过解的感知、解的变量及其域、要满足的解的约束和解的变量的值等方法来表示。
Ⅰ. 解决方案概念：系统中的解决方案与一个名为解决方案概念(SoC)的概念相关联，它是该解决方案的一个抽象视图。每个解决方案都与自己的解决方案概念相关联。
Ⅱ. 解决方案变量集包含用于描述解决方案特定需求和变量的所有需求变量的副本（特定于SoC的概念变量模型和添加的解决方案变量的副本）。
Ⅲ. 解决方案约束：在解决方案中，解决方案约束集包含来自SoC（概念解决方案约束）的概念约束模型的副本、添加的需求约束的副本和添加的解决方案约束。当从解决方案本身推导出一个约束时，设计者可以在解决方案中添加一个约束。
Ⅳ. 解决方案变量的值：在一个解决方案中，在设计过程中，设计者必须为每个解决方案变量确定一个必须属于其域的值，并满足所有的解决方案约束（因此，需求约束）。因此，一个n个元组的值表示解决方案。若要验证它，值的n个元组必须满足所有的约束条件。

③ 案例建模：每个系统开发活动的结果必须在案例基础中大写以进一步重用。在解决方案开发过程中，系统可以分解为子系统。因此，案例的结构也是分层的。一个案例收集有关系统、其需求集和解决方案集的信息。因此，如果要重用的解决方案由多个子系统组成，则会对每个子系统执行CBR进程，以确保子用例可以被重用。

第四节，主要描述RCBR子过程。
① 需求定义过程：本体和基于偏好的方法。
客户和/或其他利益相关者所表达的一套需求必须转化为技术要求。最早，在本体中选择与未来要开发的系统相对应的RC。设计师（或负责需求定义的团队）必须收集尽可能多的信息，同时考虑到本体中嵌入的知识人自己的偏好。该过程的输入要么是一组客户/利益攸关方需求， 要么是一组子系统需求。 对于后者，实现了需求定义过程，用于开发将集成到更高级别系统的子系统。
② 兼容案例检索流程：从需求定义过程中表达的兼容概念和灵活的离散约束，可以进行兼容的案例检索过程。其目的是从案例基础上确定关于兼容概念集和灵活约束条件的兼容解决方案。检索过程由两个顺序的任务组成：预选和兼容解决方案的选择。
③ 解决方案定义过程：从来自兼容案例检索过程的近似兼容的解决方案集中，必须开发与新需求对应的一个或多个解决方案。检索到的解决方案很少可以直接用作合适的解决方案。它们通常需要自适应才能应用于新的要求。
④ 验证、验证和资本化过程：最后的过程涉及对为满足需求而开发的整套解决方案的验证/验证。对于每个解决方案，都需要根据需求约束来评估值的n个元组。必须满足每个约束条件，才能验证该解决方案。如果某些值违反了约束条件，则必须更改它们。

第五节的实例及第六节的结论在这篇笔记中不再描述，具体参考笔记头部的引文。