复杂系统体系结构 课件 第八章复杂系统模型驱动体系结构

第八章2026年4月30日2024赵凯星复杂系统模型驱动体系结构目录2024复杂系统的属性01复杂系统的层级原理02复杂系统模型的分析要素0304基于DSM的建模与模组化设计第复杂系统模型驱动体系结构复杂系统模型驱动体系结构是一种软件体系结构，它以模型为基础，通过模型来描述和构建复杂系统。这种体系结构可以更好地应对系统复杂度提高的情况，因为模型可以更容易和直接地表达复杂的结构。01在复杂系统模型驱动体系结构中，模型是核心，它与程序语言的主要区别在于表达方式突破了“单一顺序”的限制。例如，二维表可以作为模型的一种形式，用于表达复杂的结构。此外，模型驱动体系结构还强调对系统进行有效的规划和构建，以达到“柔性”和可调整的目标。02这种体系结构的意义在于，它为企业应用系统的开发提供了新的思路和方法。企业系统要表述的主要是复杂的结构，而模型可以更好地应对这种情况。通过使用模型，开发人员可以更直观、准确地描述和理解系统的结构和行为，从而更好地进行系统的设计和实现。0301复杂系统的层级原理8.1.1层级理论的概念

诺贝尔奖获得者赫伯特A.西蒙曾论述到：“要构造一门关于复杂系统的比较正规的理论，有一条路就是求助于层级理论……我们可以期望，在一个复杂性必然是从简单性进化而来的世界中，复杂系统是层级结构的”。对于软件这样复杂的人造事务，发现层级和运用层级，是分析和构建的基本原则。图8-1给出了软件的体系结构是层级的概念。图8-1软件的体系结构是层级的粗略地观察一下软件表述方式（语言）的发展：从穿孔纸带（机器的语言）开始，首先是汇编语言，然后是高级语言，再往后有面向对象语言和所谓第四代语言（FGL）出现……应当留意：每一代的语言并不是在“取代”前一代语言，而是用上一代语言来“写”下一代语言。在这个自然的进化过程中，西蒙所论述的复杂体系的层级特征清晰地出现了。进一步看，在由简单到复杂的进化道路上，软件的体系结构、软件开发的体系结构、软件开发工具的体系结构等等，都呈现出层级的特征。“好”的软件体系具有更加清晰的层级。01复杂系统的层级原理8.1.1层级理论的概念一维语言之后是模型，与自然语言类似，现有的“程序设计语言”是单维的，它的基本语法是以前后顺序为基础的。当系统的复杂程度提高时，用这样的语言精确描述复杂系统变得越发困难，更遑论有效地修改维护；0102可视化开发平台、代码管理工具（甚至某种意义上共享组件也可包括在内）等的出现对此是一种补充，但仍然不是最终的解决方法。软件描述体系进化到这里，面临着一次突变，将有新的物种出现，这个新物种可能就是模型。03模型与程序语言主要的区别不在于图形化，也不在于抽象的程度，而在于表达方式突破了“单一顺序”的限制，最简单的例子就是二维表。模型可以更容易和直接地表达复杂的结构。01复杂系统的层级原理8.1.1层级理论的概念模型和语言都是对系统的描述，传统的编程语言和模型都是一种表述的体系，前者适合表述顺序过程，后者适合表述复杂结构。模型的必要性可以通过下面这个例子看出来：为了精确地复现，可以用语言精确地叙述一个立方体，甚至10个立方体组合的形状，但不会试图用语言描述一栋房子，适当的方式是用工程图纸。建立企业应用系统的情形可以从以上例子得到启发，企业系统要表述的，主要是复杂的结构，过程占的比重很小，因此，模型就变得更加重要乃至必要了。OMG组织的MDA战略，OMG最新的战略是建立模型驱动体系架构（ModelDrivenArchitecture,MDA），它的意义不是三言两语可以说清楚的，但从软件进化的角度来说，可能带有一种必然性，从上面的讨论，至少可以引申出两个理由：

更有效地描述复杂系统的需要；系统复杂化带来的层级区分的需要。01复杂系统的层级原理8.1.2复杂系统的层级架构UML是“紧贴”高级软件语言（例如C++）的模型体系，其时效是在软件生命周期的开发期间，而不是运行期间，其描述的层级是在软件的组件、对象一级，典型要素是软件中的对象，软件上一个操作的动作等。UML复杂系统模型，例如企业模型（ARIS,CIM-OSA,GERAM等），典型的要素是组织，产品，过程等，它们是从企业的业务对象着眼的。二者在层级上有差距，而且企业模型追求的最终结果，是从“开发期模型”到达“运行期模型”，并且它最终应当是一种可进化的模型，这与UML的设计目标并不符合。复杂系统模型它们两者间并不相互排斥，而应当考虑它们的“层接”。OMG的MDA即使全面实现，也仍然不能做为或替代企业模型，但有可能成为企业模型的基础，这不是模型好坏或能力的问题，而是层级定位的问题。01复杂系统的层级原理8.1.2复杂系统的层级架构面向对象（ObjectOriented,OO）作为软件体系结构方面的一种演进而出现，也曾经被一些人误解为对过程化语言（或面向过程的体系结构）的取代，尽管OO反应了一种世界观，是一种思维的方式，但并不代表一切；且从层级和进化的观点上，也不应当将它看作是对既有东西的一种简单的取代。模型或模型驱动同样如此，它可能是继面向对象之后，软件体系结构的又一个重大的进化，但不是用来取代面向对象或结构化设计。对于企业信息系统这样复杂的系统，要想做到有效、可控制地规划与构建乃至具有“柔性”、可在运行期间不断地调整，模型是必须的，而且表达与构建复杂企业系统时所需的模型，可能是多层次的，所谓“通用企业平台上的专用执行系统”，就应当是一个由运行期模型驱动的系统。一般而言，复杂系统的层级架构可以用图8-2描述。图8-2复杂系统的层级架构02复杂系统模型的分析要素8.2.1模型的时效性模型的时效性（time-effectivenessofmodel）：关于这一点最重要的区分在于，是运行期模型（Run-TimeModel），还是开发期模型？这个区别，有点类似于解释的语言和编译的语言间的区别，但其意义却非同一般，运行期模型揭示了模型驱动的本质。01复杂系统模型的时效性是指随着时间的推移，模型对于系统的描述和预测能力会发生变化。由于复杂系统的动态性和不确定性，其模型通常只是一种近似描述，因此随着时间的推移，模型可能变得不准确或过时。02复杂系统模型的时效性取决于多种因素，包括系统的动态变化、环境因素的变化、数据的变化等。如果系统本身发生了变化，或者环境因素对系统的影响发生了变化，那么模型就需要更新或重新构建，以反映这些变化。0302复杂系统模型的分析要素8.2.1模型的时效性复杂系统模型的时效性可以具体表现为以下几个方面：模型预测能力的下降随着时间的推移，复杂系统本身可能发生了变化，例如系统中的元素可能发生了变化，或者系统中的关系可能发生了调整。这可能导致模型对于未来的预测能力下降，预测结果与实际结果之间的误差增大。模型解释能力的下降随着时间的推移，复杂系统中的某些元素或关系可能变得更为复杂或不确定，例如系统中出现了新的元素或者原有的关系发生了改变。这可能导致模型对于系统的解释能力下降，模型难以准确地描述系统的真实状态。模型适用范围的缩小随着时间的推移，复杂系统的环境和条件可能发生了变化，例如系统中的气候、环境、人口等因素可能发生了变化。这可能导致模型原来适用的范围变得不再适用，需要重新构建或更新模型以适应新的环境和条件。02复杂系统模型的分析要素8.2.1模型的时效性为了保持复杂系统模型的时效性，需要不断更新模型以反映系统的最新状态和变化。这可能需要收集新的数据、更新参数或重新进行模型验证和确认。此外，还需要对模型进行评估和改进，以确保其对于系统的描述和预测能力不断提高。例如，推荐系统是一个复杂系统，静态推荐系统存在以下问题：用户行为其实是非常多元化的，没有办法用一个静态的事情去描述这个用户的行为。01问题某一类用户的行为可能比较相似，但是行为本身发生了变化。02解决方案有：在推荐系统中加入实时特征工程，实现灵活推荐加入实时模型训练，最主要的目的是在动态特征的基础上，希望模型本身能够尽可能的贴合此时此刻用户行为的分布，同时希望能够缓解模型的退化。02复杂系统模型的分析要素8.2.2模型的可进化性模型的可进化性（evolutionablenessofmodel）：是否可以在系统的应用过程中，持续地适应应用环境与需求的变化，不断地由应用者或自适应地对模型进行改进？这是对模型“性能”的一种度量。根据复杂系统理论，适应性是进化的动力。但是如果从建模角度考虑，到底是谁进化了，是复杂系统，还是人类的认知？对复杂系统的认知也在不断进化，因为理解在不断加深，所以认知模型也需要进化复杂系统在适应环境中是不断进化的，因而反映复杂系统原理的模型也需要不断进化。客观上A主观上B这两个侧面，一个客观，一个主观，无论是复杂系统本身，还是我们对复杂系统的认知，其实都在进化。因而，认知也应该成为建模必须要考虑的核心问题之一02复杂系统模型的分析要素8.2.2模型的可进化性要理解这个问题，首先需要了解复杂系统的另一个重要性质——“反身性”。这是复杂系统的一个非常关键核心的性质，但被很多研究者所忽视。“反身性”是人也是系统的组成部分之一，人的任何行为（包括认知），都会对系统造成反作用，都会导致系统的状态发生改变，任何与人有关的复杂系统都具有这个特性。对于自然界中的系统，人对其影响不大，因此可以假设人不在系统之中。如，无论人们预测明天是否会下雨，都不会影响明天气象的自然规律。但是，如果证监会主席或某些重要的知情者评论股市，甚至是某人造出的谣言，就可能会影响股市的波动，因为人本身就属于股市所在的系统。这就是反身性。同样，战场上指挥员对战场态势的认知，也会构成对战场系统的影响。因此，复杂系统与认知是分不开的。对自然界中的简单系统，我们可以不考虑反身性的问题，但是只要是与人相关的复杂系统研究，就必须要体现认知的反身性影响。因此，模型的进化很自然就与系统本身和认知都有关系。进化是智能认知模型的固有属性。不会进化的模型，显然满足不了仿真的需要。同时，也可以得到一个推论：认知模型应该是动态的，也就是结构应该是不固定的。从结论和推论来看，人工神经元网络是比较符合这一特点的。如果模型要进化，还应解决“极限”和“方向”两个问题。“极限”探讨的是进化是否有尽头。人类现在已经进化成了直立行走的动物，但我们现在也不知道人类的行走方式是不是已经停止了进化，也不知道这是不是就是人类行走进化的极限。“方向”探讨的是进化方向是否是唯一确定的，也就是说，进化会不会有几种不同的结果？是不是都能从低手进化成高手？提出这个问题，是因为复杂系统有一个固有问题，即混沌从复杂系统来看，系统的演化可能会进化涌现出更有序的系统结构，也可能掉入混沌状态中去，进化的方向就会有很大的不确定性。02复杂系统模型的分析要素8.2.2模型的可进化性一般说来，对一个系统的认识和理解加深了，掌控它的程度也会更进一步。但是对于复杂系统而言，这个问题可能就不是那么简单，甚至还可能出现一个悖论：我们为了掌控复杂系统，就必须对它充分认识；但对它认识越多，却发现不是离真相越近，反而可能是越远了。这个悖论之所以产生，就是因为反身性原理，我们认知的本身会导致系统发生演化，而这种演化又具有非线性、不确定性等特点，而蝴蝶效应又会使结果具有很强的不可预测性。因此，当我们利用认知智能去解决社会、经济、战争等复杂系统问题时，是否会激发系统产生更复杂的演化，导致新的安全、社会等问题，就非常值得我们深入思考。02复杂系统模型的分析要素8.2.3模型的层级性模型的层级性（hierarchyofmodel）：正如语言有多个层次一样，没有理由认为模型只有一个层次，当系统足够复杂时，模型的层次划分将会是必要的。此外，复杂系统模型的层次性还具有一些特性。首先，低层次组分由于随机对称性破缺形成不可能仅从组分性质决定的涌现特征，这意味着在系统的层次结构中，较低层次的行为和结构可以影响和限定较高层次的行为和结构，但较高层次的行为和结构并不完全由较低层次的行为和结构所决定。复杂系统模型的层次性是指系统组分之间相互作用形成的多个层级结构，这些结构在模型中呈现出一种自组织的维度特性。具体来说，系统中的每一个层级都由规模不同的组分构成，这些组分之间相互影响、相互作用，从而形成了系统的层次结构。在复杂系统模型中，层次性是一个非常重要的概念。它有助于我们理解和描述系统中的各种现象和特性。例如，在生物系统中，细胞、组织和器官等不同层次的组分相互作用，形成了生命现象的复杂性和多样性；在社会系统中，个人、群体和组织等不同层次的组分相互作用，形成了社会现象的复杂性和多样性。030102其次，任一层次的行为和结构要与所有层次的观察结果保持一致。这种多纬度的自组织相比“组织整体”的优势之所在，正是这种维度差，才会让有自组织的组织比没有自组织的组织具有更强的负反馈能力（稳定性），且有更强的处理能源和信息的能力。04因此，在建立复杂系统模型时，需要考虑系统的层次性，并分析不同层次之间的相互作用和影响。通过了解系统的层次结构和特性，我们可以更好地理解和预测系统的行为和表现。02复杂系统模型的分析要素8.2.3模型的层级性MDA元模型层次（M0-M3）是好的范例。从二进制编码到汇编语言、高级语言、4GL的层级性，也是MDA喜欢的话题，称为“提升抽象层次”。这些都属于MDA提出时的基础。这里的一个关键是分层的原则，可以提出下面这些问题：PART01从二进制编码到例如企业/业务模型或领域模型、UML模型，中间到底应该有几层？PART03M0-M3的这种建模层次划分，和编程语言/软件平台的层次划分到底可以有怎样的关联？PART02什么是最合理或实质性的分层方案或原则？建立了复杂系统层级性的基本认识后，需要进一步明确：层级划分应当是必要的、内在独立的。一个笼统的原则是：层次越少越好。而层级性的关键课题是找到天然或必须的层次/分界的所在，或者发现目标确定、建构性的层次创建原则。03基于DSM的建模与模组化设计8.3.1领域建模的体系化思维软件工程师做的核心事情就是对现实世界的问题进行抽象然后用计算机的语言对其进行重新刻画，在通过信息化来提高生产力。而这其中一个关键环节就是如何对问题域进行建模，经常遇到一个问题是前期因为业务比较简单所以设计的模型在支撑时没有发现什么问题，而随着业务复杂度的增加就会发现需要对模型进行升级，如果是对模型关系维度的新增那还好，而如果是对原有模型关系的重构，那将会变的非常困难。关于如何建模并不是一个单一维度的问题而是一个体系化的工程，需要对其进行拆解然后逐个攻破，如何建好模并能顺利落地可以拆分为四个子问题，如图8-3所示。对需求进行功能建模。对业务进行领域建模。将领域模型映射到代码模型。根据代码模型落地数据模型。图8-3建模的四个子问题03基于DSM的建模与模组化设计8.3.1领域建模的体系化思维通过和产品及业务同学的沟通，结合行业经验和知识，明确用户的真实需求。需求模型以领域模型为基础，综合面向对象的各种设计技巧，完成类的设计。代码模型基于需求模型，提炼出领域相关的概念，为后面的面向对象设计打下基础。领域模型以代码模型类及类之间的关系，用ER图刻画数据的底层存储关系。数据模型建模的四个子问题03基于DSM的建模与模组化设计8.3.1领域建模的体系化思维领域建模并不是万能的，比如系统很简单，使用数据库的CRUD可能一个更好的方式(如图8-3中的虚线箭头)，如果做的是基础架构，比如开发一个RPC框架，也不需要用领域驱动。运用领域驱动的前提一定是业务足够复杂且多变，需要系统灵活支持。图8-4描述了领域建模与业务复杂度的关系图8-4领域建模与业务复杂度的关系03基于DSM的建模与模组化设计8.3.1领域建模的体系化思维一般而言，大多数场景都可以通过在需求用例中通过找名称的方式来最终刻画出领域模型，当然找到的名词后并不是所有的都符合要求，这时可以通过一条原则"一个名词或实体必有其属性和行为，一属性或行为也必归属于一个实体"来进行提炼，不符合这条原则的名词就是需求剔除的。总体来说建模一共分为四步：选名词：从用例中选出所有名词，在去伪存真选出符合要求的；找动词：找出所有动词，在判断这些动词属不属于上一步选出的名词所具有的行为；加属性：找出所有属性，在判断这些属性属不属于上一步选出的名词所具有的特征；连关系：确定实体和实体之间的协作关系；图8-5具有需求模型的领域建模03基于DSM的建模与模组化设计8.3.1领域建模的体系化思维归类分组，就是把具有相似性或相关联的信息，按照一定的标准进行分类，归为同一个逻辑范畴。“类”是一个极其重要的概念，可以看作本质相同或相似的事物的集合。分类就是按照一定的标准，根据对象属性、特征的共同点和不同点，将对象划分为不同的种类。分类时，需要对这些类别进行鉴定、描述和命名。如何用归类分组进行领域建模可以分为3个步骤，如图8-6所示。定义要建模的领域问题：也就是要清楚我们要解决的问题是什么。2对领域问题进行拆解：对问题进行分析拆解，形成平铺的多个子问题。

归类分组：对子问题进行归类，剪枝，将趋同的子问题，合并成一类（可以理解为产出实体）。图8-6基于归类分组的领域建模03基于DSM的建模与模组化设计8.3.1领域建模的体系化思维领域模型需要一直持续迭代，要在"变化的现实世界中寻找不变性"，希望寻找到一个稳定的领域模型，让系统流程可以灵活改变，模型不怎么变，但在实际中却很难完美的做到，这是为什么呢？（这里的迭代不是指对原有模型关系的重构，而是对模型新关系的升级）。意识问题在用户、产品人员、运营人员眼中，沟通的语音是"流程"而不是"模型"。开发人员在与他们的沟通过程中，慢慢就形成了以"流程"为主导，而不是以"模型"为主导的思维方式。这使得整个开发过程是"流程驱动"，而不是"领域驱动"。大家在讨论业务与系统解决方案的时候，大部分时间都花在了业务流程、业务规则上，而不是深刻挖掘流程背后的不变因素。现实世界的复杂性业务也就是我们的现实世界，灰度的、模棱两可的东西，比计算机的世界多得多，变化也多得多。很难确定有哪些东西是不怎么变的，什么东西是容易变的，而这恰恰是做建模的前提条件。迭代速度在稳固的模型，也不可能一成不变，毕竟现实世界一直在变。当现实世界变化到模型不能支撑的时候，要能马上修改模型才行。但实际情况是，因为开发效率的原因，工期赶不上，然后就会在旧的模型上进行打补丁，补丁一个接着一个打，最后整个系统臃肿不堪，开发效率进一步降低，如此恶性循环。领域模型是要对现实世界建模，既要去寻找不变性，又要为可能变化的地方留出扩展性。什么地方是不变的，要作为基础；什么地方是易变的，要留出扩展性，这其中并没有一个标准原则。另外，各家公司的业务规模、速度不一样，团队实施能力也不一样。所以在实践中，要么会"缺乏设计"，要么会"过度设计"。对火候的掌握，需要有悟性。只有反复思考，反复推翻自己之前的想法，再重建新的想法，才能在实践中不断找到领域模型、业务发展速度、技术团队能力之间的"最佳平衡点"。火候的掌握03基于DSM的建模与模组化设计8.3.1领域建模的体系化思维背后需要修炼的思维，上面这些都是术的表现，是借假修真，只有"真"才是修炼的道，也就是做事的思维，图8-7列举一些领域建模需要的思维。图8-7领域建模需要的思维03基于DSM的建模与模组化设计8.3.2结构矩阵模型设计DonaldSteward在1981年引入设计结构矩阵(DSM)来分析信息流，它是一个n阶方阵，用于显示矩阵中的各个元素的交互关系，有利于对复杂项目进行可视化分析[1][2]。依据不同的模型和待解决问题的属性，DSM矩阵可以在以下几个方面使用，显示的DSM矩阵的布置如下：设计结构矩阵是一个具有n行，n列的二元的方阵（矩阵中的元素仅为空格或为记号●）。系统的元素均以相同的顺序放在矩阵的最左边和最上边，如果元素i和元素j之间存在联系，则矩阵中的ij（i行j列）元素为●（或由数字1表示）；否则空格（或由数字0表示）。如图8-8所示。图8-8设计架构矩阵在由二元（0或1）表示的矩阵中，对角线上的元素一般不用来描述系统，用空格表示。二元矩阵有助于系统的建模，因为它能表示一对系统元素间的关系存在与否，与图形表示相比，它对整个系统元素提供整体的紧凑描绘，并为各项活动的信息需求，活动的顺序决策及活动迭代的控制提供有效的使用方法。03基于DSM的建模与模组化设计8.3.2结构矩阵模型设计DSM具有以下的特性：在DSM中，活动之间的串联关系是通过主对角线下方，紧邻主对角线的连续的非零元素表示。01主对角线以下的非零元素描述了从上游活动至下游活动方向的逻辑关系，是前

向流；而主对角线以上的非零元素描述了从下游活动反馈给上游活动的逻辑关系；是反

馈流；前向流和反馈流构成耦合。

02由全零元素组成的行或列称为端元素。全零行与输入端元素对应；全零列与输

出端元素对应。(4)也可以用有向图G(E，A)来表示过程系统，其中：顶点集E={E1，E2，…，En)表示过程中的刀个活动，边集A={a1，a2，…，锄)表示活动之间的逻辑关系。DSM是

有向图的节点邻接矩阵。

0303基于DSM的建模与模组化设计8.3.2结构矩阵模型设计1.设计结构矩阵的类型：Browning将设计结构矩阵主要分为两大类：静态设计结构矩阵(StaticDSM)和动

态设计结构矩阵(Time．basedDSM)，如图8-9所示。

静态DSM描述的是系统设计元素同时存在关系，比如产品结构中的组件或者组织机构中的部门等，通常用聚类算法(ClusteringAlgorithms)来分析；动态DSM是矩阵的行列元素按照一定的时间顺序排列的，即在设计过程中，上游的设计活动是优先于下游的设计活动被执行，排序算法是其典型的分析方法。根据设计结构矩阵的不同用途，比如产品研发、项目规划、项目管理、系统工程和

组织结构设计等，设计结构矩阵分为以下四类，如图8-9所示。

图8-9设计结构矩阵的分类03基于DSM的建模与模组化设计8.3.2结构矩阵模型设计基于零部件的DSM(Component．BasedDSM)或结构DSM(ArchitectureDSM)，

其主要用于基于零部件、子系统以及它们之间关系的系统结构建模；该模型被用于分析

基于参数交互的系统结构，它通过明确定义待分解的系统元素和交互关系来构建，在对

系统间的各种交互类型的分类的基础上，对交互关系再附予适当的权重，使建立的DSM更准确。为了减少整个系统协调的复杂性，必须对基于参数的DSM矩阵的元素进行聚类分析使其成为若干子系统。

基于团队的DSM(Team．BasedDSM)或组织DSM(OrganizationDSM)，其

主要用于基于人员、部门以及它们的相互作用的组织结构建模；在基于信息流的组织分

析和设计中，若分析的对象涉及一个项目中的个体或群体，则需采用基于团队的DSM，

该方法被用于各种组织实体中。基于团队的DSM通过识别需要的信息流和信息流的方

向来构造相应的设计团队。在建模过程中，设计人员必须明白团队间信息流的意义，才能建造正确的模型。同样，为了形成较高交互紧密的工作团队，减小团队的内部交互空间范围，还应该对已形成的基于团队的DSM矩阵进行变换。基于任务的DSM(Task-BasedDSM)或规划DSM(ScheduleDSM)，其主要

用于基于任务及其信息流和与其他任务依赖关系的过程和任务节点建模；DSM矩阵包含

了组成项目的各项任务及其各任务间信息交换的方式，从中可以发现某项任务开始时需

要哪些信息和一个任务产生的信息将提供给哪些任务。在图8-8中，从某一行上可以发现该行的所有输入信息任务，就是处对应的列所表示的任务；从某一列上可以看出该活

动的输出信息由哪些任务(即处对应的行所表示的活动)吸收。在对角线下方的表示信

息的前馈，而对角线上方表示的是反馈信息，即信息是从由后进行的任务(下游任务)向前进行的任务(上游任务)流动。这意味着前期的任务不得不依据新的信息而重作。基于参数的DSM(Parameter-BasedDSM)或底层规划DSM，其主要用于底

层设计决策与设计参数、系统平衡和子设计参数变更的相互联系建模。03基于DSM的建模与模组化设计8.3.2结构矩阵模型设计2.设计结构矩阵的分析方法

目前，国内外许多学者对设计结构矩阵的分析方法做了广泛地研究。Yassine将设计结构矩阵的分析方法归结为六条，即分解(Partitioning)、割裂(Tearing)、绑定(Banding)、聚类(Clustering)、仿真(Simulation)和特征值分析(EigenvalueAnalysis)。其中，分解是对DSM行列元素重新排序的过程，其目的是减少或消除设计的反馈，并使DSM变

为下三角矩阵；割裂是通过去除DSM矩阵中一组反馈节点(或矩阵再分解)使设计矩

阵下三角化；绑定要在不考虑反馈的情况下，根据相邻元素之间的信息依赖情况，对元素在DSM模型中对应的行进行绑定，从而找出相对并行活动和瓶颈活动；聚类是把DSM模型中联系紧密的行列元素归入同一类型的过程，从而使得聚类内部各元素之间的联系强度很高，而聚类之间的联系强度很低；仿真是指运用信息流DSM模型、信息变化概率DSM模型以及变化冲击DSM模型来对整个过程的持续时间和成本进行仿真。表8-1对设计结构矩阵的类型、分析方法以及应用分类作了概括[3][4][5]。表8-1设计结构矩阵类型、分析方法及应用分类03基于DSM的建模与模组化设计8.3.2结构矩阵模型设计3.设计活动联系的基本类型

用过程和系统的观点可把企业看成是一系列过程系统的集合，例如营销过程系统、

生产制造过程系统、产品开发过程系统等是企业中一些典型的过程系统。企业过程系统

的构成要素是活动，活动承担某项具体的业务，涉及资源的输～输出、人员的参与等。

活动之间一般有4种典型的逻辑关系：并行、串行、耦合或循环、绕行。

如果完成活动B需要活动A的输出，则称任务B依赖于任务A。串行关系并不是说后面的任务不能在前面的任务完成前开始。通常，后面的任务在获得前面任务输出的一部分信息后就可以开始，但是一般只能在前面的任务完成之后才能完成；耦合关系的存在可能是由于开发过程中不断有新信息出现。例如：发现了错误，输入有变化或者补充了新的要求等。耦合关系分为有意耦合和无意耦合，有意耦合是可以预见的，并可以通过计划和控制使之有利于项目的进行；而无意耦合则是不可预见的，会导致任务的反复，

例如修改和返工等，从而延长项目周期。03基于DSM的建模与模组化设计8.3.2结构矩阵模型设计3.设计活动联系的基本类型

实际的企业过程系统往往是上述4种逻辑关系交织在一起的结果，它们构成了过程

系统的结构。根据系统的结构和功能的关系原理，系统的结构影响了系统的效率或效力。

因此在过程优化之前，首先要了解活动之间的联系，即过程系统的结构。建立过程系

统的结构模型是了解过程系统结构的有效方法。DSM模型描述了过程系统的组成和结构，并且可以通过各种基于矩阵的算法，分析和协调各活动之间的逻辑关系，从而使定性分析和定量分析相结合，为过程系统优化提供更为有力的支持方法[6][7][8]。图8-11活动逻辑关系间DSM表示03基于DSM的建模与模组化设计8.3.3模组化设计基于设计结构矩阵（DSM）的模组化设计是一种将模组化设计与设计结构矩阵相结合的方法。设计结构矩阵是一种用于表示产品或系统中各个部件之间关系的矩阵，其中行和列分别表示各个部件，矩阵中的元素表示部件之间的关系。其次，可以采用DSM模组化设计的方法，将基本组成部件进行模块化设计，以便于扩展和替换。具体来说，可以将各个部件划分为不同的模组，每个模组具有特定的功能和接口，可以与其他模组进行组合和替换0102在基于设计结构矩阵的模组化设计中，首先需要确定产品或系统的基本组成部件，并将它们作为设计结构矩阵的行和列。然后，根据各个部件之间的关系，将它们连接起来，形成一个完整的矩阵。03基于DSM的建模与模组化设计8.3.3模组化设计基于设计结构矩阵的模组化设计的优点在于：01可以清晰地表示产品或系统中各个部件之间的关系，便于进行系统的设计和分析。采用模组化的设计方法，可以使得产品或系统的扩展和替换更加灵活和方便，提高了设计的可维护性和可重用性。03基于设计结构矩阵的模组化设计是一种将模组化设计与设计结构矩阵相结合的方法，可以用于产品或系统的设计和生产中，提高设计的可维护性、可重用性和效率。02通过将基本组成部件进行模块化设计，可以使得产品或系统的设计和生产更加高效和可靠，降低了成本和风险。03基于DSM的建模与模组化设计8.3.3模组化设计具体而言，基于设计结构矩阵的模组化设计方法可以按照以下步骤进行：确定基本组成部件首先需要明确产品或系统的基本组成部件，这些部件是构成整个产品或系统的基石。构建设计结构矩阵根据基本组成部件之间的关系，构建一个设计结构矩阵。矩阵的行和列分别表示基本组成部件，矩阵中的元素表示它们之间的关系。进行模组化设计：对于每个基本组成部件，可以将其划分为不同的模组，每个模组具有特定的功能和接口。模组化设计的好处是可以使得产品或系统的扩展和替换更加灵活和方便。定义模组接口为了实现各个模组之间的互操作，需要定义统一的模组接口。模组接口应该规范、标准化，以便于各个模组之间的连接和通信。组合和替换模组：通过组合不同的模组，可以构成不同的产品或系统，以满足不同的需求。当需要修改或升级某个模组时，可以方便地将其替换掉，而不会影响到其他模组和整个产品或系统。验证设计对于基于设计结构矩阵的模组化设计，需要进行验证以确保设计的正确性和可靠性。可以采用仿真、原型等方式进行验证，以便及时发现和解决问题。优化设计根据验证结果，对设计进行优化，以提高产品或系统的性能和效率。重复以上步骤当产品或系统的需求发生变化时，可以重复以上步骤，以适应新的需求和市场变化。综上所述，基于设计结构矩阵的模组化设计方法是一种系统化的设计方法，它通过将基本组成部件划分为不同的模组，并定义统一的接口来实现各个模组之间的互操作。这种方法可以提高设计的可维护性、可重用性和效率，降低成本和风险。03基于DSM的建模与模组化设计8.3.4变更管理基于设计结构矩阵能够清晰明了地根据零部件的内部关系建立复杂的多零部件系统的模型，而这种清晰的依赖关系正是分析变更问题的重要前提，因为传统的变更管理正是由于没有系统的建立整个模型的依赖关系，导致到开发过程后期由于忽视了某些依赖关系而导致变更管理复杂化。

基于设计结构矩阵的聚类方法对于系统的分解和子系统的集成都十分方便，将强联系的零部件聚类成一个模块能够简化零部件分析的复杂性。在考虑变更影响分析时，对某一产品的变更影响能够很容易的地分析，某一产品的传播影响也能很快速的发现。010203基于DSM的建模与模组化设计8.3.4变更管理1.产品开发周期和变更评价标准

决定变更的一个主要因素是变更在产品开发周期中出现的时间。许多学者称

之为“十倍规则”（RuleofTen）,指的是在产品开发周期的后期进行的变更是前

一阶段进行变更的开销。Jarratt提出一般产品开发周期,如图8-12所示,从产品系统设计阶段到产品大量生产阶段都包含有工程变更的过程，而且在不同的十倍阶段工程变更的影响程度是不一样的。在产品初始设计阶段由于产品更改的可能性空间较大，涉及到的资源，人员和材料相对较少，因而更改的成本是相对较低，但到了产品生产阶段，由于产品设计的更改必然导致大量关联的资源变动，变更的成本也增加。图8-12产品开发周期03基于DSM的建模与模组化设计8.3.4变更管理1.产品开发周期和变更评价标准

工程变更分析模型另外一个要考虑的因素是工程变更影响的评价标准，不同

的评价标准对工程变更最后影响是不一样的。比如从产品重量上来评估变更后的

影响和从产品开发时间上来评估，两者的结果是不同的，因此需要从多个不同的

因素去分析变更影响，然后给设计决策者一个综合的变更评价结果，从而设计决

策者能从产品设计的整体角度去决定工程变更实施的步骤，变更的程度以及设计资源的分配。图8-13不同变更时期和标准的影响因此，在设计本项目变更影响分析预测模型的时候，要考虑到变更周期和变

更评价标准对变更影响结果的影响，在下一节建立的变更模型对象中，这两个对

象起着十分关键的作用，这两个对象贯穿了整个变更分析的始终。03基于DSM的建模与模组化设计8.3.4变更管理2.变更影响分析对象模型和流程

根据设计结构矩阵的原理，在以上的分析考虑产品设计生命周期和不同评价标准对工程变更分析的结果影响，一个基本的变更影响模型如图8-14所

示。其中包括的对象有：图8-14工程变更分析对象模型03基于DSM的建模与模组化设计8.3.4变更管理2.变更影响分析对象模型和流程

根据设计结构矩阵的原理，在以上的分析考虑产品设计生命周期和不同评价标准对工程变更分析的结果影响，一个基本的变更影响模型如图8-14所

示。其中包括的对象有：通常一个模型为一个变更工程，比如某个产品的变更。如果

变更工程的规模过大，也将子项目作为模型，其中的细粒度需要由变更设计分析

人员依据情况决定。变更模型一般来说，根据以上提到设计结构矩阵的四种不同形式，将变更领域分为基于零件、团队、活动和参数，也可根据实际情况设定其他的变更领域。

变更领域指变更所设计到具体活动，其中包括了变更项目所属的变更

模型和变更领域，以及变更的详细描述情况。由于许多变更项目的更多信息是从

其他工程设计知识库中导入的，比如PDM中的知识，CAD中的造型知识，因此

增加了项目细节扩展，方便导入外部的知识。变更项目工程变更的等级，由变更设计人员定义。z变更标准：确定工程变更影响的具体标准。变更等级根据不同的变更类型、等级和标准确定工程变更的影响数值。变更影响确定产品工程变更设计周期的不同阶段。工程变更设计设计生命周期不同阶段对变更影响不同，因此，确定合理的设计生

命周期对正确预测变更结果起着十分关键的作用。生命周期工程变更的类型，由设计人员定义变更类型由于变更传播的存在，某一变更会传播到另一变更，由此就建立了二者的依赖关系，这种依赖关系是构成设计结构矩阵的基础。变更依赖1234567803基于DSM的建模与模组化设计8.3.4变更管理2.变更影响分析对象模型和流程

在确定了工程变更的模型对象之后，便可定义具体的工程变更影响分析流程，流程具体分三个阶段：初始分析，具体变更实例分析，执行变更。具体过程如图8-15所示。图8-15工程变更分析流程1.建立产品模型

在进行产品分析前必须把产品分解成子系统，把产品看作彼此相互影响的零件的集合。一个子系统是整个产品的一部分，根据它所在位置，功能和来源或者其他相关的区分特征来描述。由于设计者和管理者非常熟悉原始设计，通常由他们将整个系统分成合适数量的子系统。这需要在子系统所需细节程度和随后构成的模型的成本之间做个平衡。建议一个模型少于50个部件。2.建立依赖

分解开的