复杂系统体系结构 课件 第6-12章 系统体系结构概述- 复杂系统体系结构设计新范式的提出

第六章

系统体系结构概述

contents目录什么是系统体系结构01系统思维方法02软件系统体系结构分析方法036.1什么是系统体系结构202401什么是系统体系结构4系统体系结构是由结构要素和各种视图组成的综合模型，描述系统的整体设计与组织。定义作用通过综合不同观点，描述系统组件及其相互关系，全面展现系统的功能与结构特性。02系统体系结构的概念5系统模型组织视图行为视图共同构建为复杂系统设计提供战略性环境，解决关键设计问题并指导系统发展。重要性02系统体系结构的概念6体系结构研究领域体系结构研究起步晚，过去对其理解较为隐含、片面，直到90年代才开始系统研究。历史背景涵盖体系结构框架、技术参考模型、描述语言等领域，推动系统设计的规范化与高效化。主要研究方向02系统体系结构的概念7国际体系结构框架TOGAF：适用于各类企业，尤其是大型跨国公司和复杂架构管理。Zachman：适合架构文档化与思维结构化，适用于明确角色和责任的场景。DODAF：适合复杂系统集成，尤其在军事、航空航天、制造业中表现突出。FEAF：公共部门的标准，适合政府和政策执行场景。02系统体系结构的概念8体系结构的定义•描述系统及其组件的结构•组件协同工作以达成目标共识02系统体系结构的概念9体系结构与其框架体系结构定义系统的组成结构及其相互关系，提供设计和发展的指导原则。体系结构框架为体系结构设计提供规范化指南，确保设计过程的标准化和适用性。02系统体系结构的概念10体系结构描述语言（ADL）描述和呈现体系结构目的示例ACME、Wright、Rapide02系统体系结构的概念11DoDAF框架解决系统互通性问题背景和目的作战视图

系统视图技术标准视图02系统体系结构的概念RUP和4+1视图模型以系统重要构件的组织和交互为核心，支持需求和设计约束的表达。RUP中的体系结构4+1视图模型用例视图逻辑视图实现视图进程视图配置视图03系统体系结构的分类六类主要风格通过数据流动完成处理和传输，适用于流式大数据处理，强调并行性与灵活性。数据流系统调用-返回系统基于主程序与子程序、面向对象或层次结构，分而治之，提高模块化与可维护性。独立部件构件间通过消息传递或事件隐式调用交互，支持模块化设计和软件复用。虚拟机模拟硬件或应用的执行过程，典型形式包括解释器和基于规则的系统。以数据为中心的系统以数据库、黑板系统等共享数据源为核心，适用于知识处理和复杂问题求解。特殊领域风格面向特定领域的架构风格，如过程控制与模拟器，适合嵌入式系统与连续控制任务。03系统体系结构的分类数据流系统管道和过滤器特点顺序批处理数据被视为基本元素数据流体系结构处理单元并行处理数据03系统体系结构的分类调用-返回系统主程序和子程序：通过分而治之的策略，划分处理步骤，提高模块化和可维护性。面向对象系统：基于数据抽象和封装，增强系统的灵活性和资源完整性。层次结构：采用分层设计，上层依赖下层提供服务，支持抽象设计与功能扩展。03系统体系结构的分类主程序/子程序风格主程序/子程序风格采用调用与返回机制，通过分而治之策略将复杂任务分解为多个模块，提高系统的可维护性和模块化水平。特点03系统体系结构的分类主程序/子程序风格面向对象风格基于数据抽象和封装，构件由对象组成，对象维护自身完整性并通过方法交互，提升系统的灵活性和可扩展性。特点03系统体系结构的分类层次结构风格层次结构风格通过将系统组织成层次结构，每一层为上层提供服务并依赖下层，支持抽象设计、功能增强和模块重用。特点03系统体系结构的分类独立部件类型通信进程：构件为独立进程，通过消息传递方式交互，支持点对点、异步或远程调用。事件隐式调用：通过事件触发构件交互，构件不直接调用过程，增强模块复用和维护便捷性。03系统体系结构的分类通信进程构件是独立的进程消息传递作为连接件03系统体系结构的分类事件隐式调用触发或广播事件构件之间的隐式调用03系统体系结构的分类虚拟机解释器：通过解释引擎仿真程序执行，适合灵活性要求高的场景。基于规则的系统：由规则集和解释器组成，支持逻辑推理与决策，广泛应用于AI和DSS领域。03系统体系结构的分类解释器由解释引擎、代码存储区和工作状态数据结构组成，用于解释执行代码。组成应用仿真硬件执行过程，适合灵活性和适配性要求高的场景。03系统体系结构的分类基于规则的系统包括规则集、规则解释器、规则选择器和工作内存，用于逻辑推理与决策。组成应用广泛应用于人工智能和决策支持系统（DSS），实现复杂问题求解与优化。03系统体系结构的分类以数据为中心的系统以中央共享数据源为核心，独立处理单元通过操作共享数据实现功能数据库黑板系统知识源通过全局黑板进行交互，适用于信号处理、问题规划等不确定性算法场景。超文本系统基于网状链接的非线性信息组织，常用于互联网和集成开发环境。03系统体系结构的分类数据库系统中央共享数据源独立处理单元操作数据03系统体系结构的分类黑板系统由知识源、黑板和控制模块构成，知识源提供问题解决方案，黑板作为全局状态数据库，控制模块协调交互。组成应用广泛应用于信号处理、问题规划、编译器优化等复杂问题领域。03系统体系结构的分类超文本系统特点：构件通过网状链接方式连接，支持非线性信息组织和联想跳转。应用：广泛应用于互联网领域和现代集成编译环境，实现灵活的信息访问与导航。03系统体系结构的分类特殊领域风格过程控制器模拟器适用于嵌入式系统，强调连续的动作与状态，常用于操作物理系统的反馈循环。特点04典型的系统体系结构软件体系结构模式重要性：促进体系结构级的软件重用，提高设计效率和可靠性。体系结构风格：定义系统组织方式的惯用模式，为模块和子系统的组织提供结构和语义指导。04典型的系统体系结构分层系统体系结构系统按层次结构组织，每层提供抽象功能并服务于上层。特点优点支持递增抽象设计，增强系统功能，促进模块化和重用。04典型的系统体系结构C/S（Client/Server）系统体系结构基于资源不对等和共享需求，20世纪90年代发展成熟。背景组成包括数据库服务器、客户应用程序和网络，支持数据与应用分布式处理。优点减少网络传输量，提高系统并发性与性能。04典型的系统体系结构三层C/S系统体系结构分为表示层、功能层、数据层，提供清晰的层次分工组成中间件作为核心构件，负责数据传输和客户端与服务器的通信，实现灵活扩展与高效管理。客户端发出请求中间件查找数据源并转发请求服务器处理后将结果返回客户端04典型的系统体系结构B/S（Browser/Server）系统体系结构特点基于WWW浏览器技术，应用程序以网页形式运行，实现“零客户端”功能，无需复杂的客户端安装。优点易于维护和升级，所有修改集中在服务器端；提供异构环境下的统一服务与开放性基础，支持灵活扩展。6.2系统思维方法202401系统思维方法定义一种将原则性与灵活性相结合的基本思维方式，通过系统化视角理解事物的联系与功能。重要性系统体系结构设计中至关重要的方法，助力抓住整体与要害。01系统思维方法系统思维的概述一种全面看待事物的思维方式，将目标、流程及其优化视为整体系统。含义古代整体近代机械辩证系统现代复杂系统01系统思维方法系统思维的发展阶段古代整体系统思维方式近代机械系统思维方式辩证系统思维方式现代复杂系统思维方式以整体观为核心，强调事物的相互联系和整体性。以分解和还原为主，注重对系统的独立部分进行分析。融合整体与部分，关注系统内部矛盾及其转化关系。强调复杂性、动态性，结合多学科方法研究系统全局。01系统思维方法系统思维方法树展示系统思维从古代整体观到现代复杂系统思维方式的演进过程体现其对事物认知从简单到全面、从局部到全局的不断深化与发展02系统思维的特征系统思维的五大特征强调从整体与部分的关系出发，系统分析与综合并重，实现整体目标。整体性结构性聚焦系统的结构优化，探索结构对功能的决定性作用以实现最优性能。立体性结合纵向与横向思维，多维度把握系统对象的全貌与演化规律。动态性反映系统的生成、发展、变化过程，通过控制项实现系统从无序到有序的演化。综合性非线性思维方式，从多角度、多关系综合考察系统，达成整体大于部分之和的效果。02系统思维的特征含义将研究对象视为有机整体，全面考察其构成与联系。要求基于整体与部分的相互作用，明确整体目标并综合分析系统要素。整体性02系统思维的特征结构性通过系统结构理解其整体功能，强调结构与功能的紧密联系。含义聚焦系统结构，优化要素关系，提升整体性能。要求02系统思维的特征立体性立体性指通过纵向与横向交叉视角，全面思考和理解系统的开放型思维方式。含义要求在思维中结合对象的纵向发展历程与横向联系，全面准确地把握系统特性。02系统思维的特征动态性系统稳定性是相对的，需随时间变化考虑其演化特性。含义要求识别和掌控系统演化的关键控制项，推动向新的有序结构过渡。02系统思维的特征综合性系统稳定性是相对的，需随时间变化考虑其演化特性。含义要求识别和掌控系统演化的关键控制项，推动向新的有序结构过渡。03系统思维的方法系统思维的四种方法从全局和整体出发整体法🌏结构法️🗽注意系统内部结构的合理性要素法🫧考察和发挥系统各要素的作用功能法🎛️调整系统各部分的功能以优化整体6.3软件系统体系结构分析方法202401SAAM最早的软件体系结构分析方法场景开发体系结构描述单个场景评估场景交互评估总体评估02ATAM从SAAM发展而来关注多个质量属性之间的权衡场景和需求收集体系结构视图和场景实现属性模型构造分析03ALPSM需求申明体系结构描述专业技能知识历史维护数据ALPSM维护预测方法估计的维护成本标识维护任务分类合成场景分配权重估计元素大小编写场景脚本计算维护成本感谢观看！第七章2026年4月30日2024赵凯星复杂系统体系结构概述目录2024复杂系统的属性01复杂系统的属性

02复杂系统与简单系统设计的区别0304复杂系统的结构第复杂系统的环境第01复杂系统的属性7.1.1软件的复杂性在描述复杂系统的属性之前，首先需要理解为什么软件在本质上是复杂的？软件固有的复杂性有四个原因1.问题域的复杂性比如公共交通购票系统需求（经常出问题的12306，不仅要处理正常用户购票，还要抗住第三方软件的频繁抢票）。比如航天电子系统需求，从功能上就很难理解，还要加上所有的非功能需求，如可用性、性能、成本、健壮性和可靠性。有的客户只是对想要的软件系统有一个模糊的想法，和开发者之间存在沟通上的分歧。软件系统在开发过程中经常发生需求改变。软件开发过程中，需求变更是难以避免的，需求的不确定性会导致软件开发过程中的不可预测性和不可控性。01复杂系统的属性7.1.1软件的复杂性2.管理开发过程中的困难性假如前期开发管理不到位，测试阶段问题爆炸怎么处理？五线上问题多影响开发进度怎么办？六如何复盘和回溯问题不再重蹈覆辙？七人员协调困难，怎么合理安排人手，投入多少骨干和萌新，不同的开发者能承受多少工作量？一风险管控困难，怎么控制需求管道，不超出团队承受能力范围。怎么控制交付时间点，保证合理的开发和测试时间？二质量维护困难，怎么维持设计的一致性和完整性？三怎样沉淀团队经验和解决方案四01复杂系统的属性7.1.1软件的复杂性3.软件中随处可能出现的灵活性一千个人有一千个哈姆雷特，市场上解决某一问题的方法有多个，开发语言有java、c、python、golang等等，数据库方面有关系型数据库oracle、mysql、sqlserver，也有非关系型的NoSQL。怎样进行技术选型，怎样进行基础建模和算法选择？怎样实现团队内部语义的统一，概念设计怎么开展？技术的不成熟性也是软件复杂度的一个重要来源。技术的不成熟性包括技术的不稳定性、技术的不可靠性等，这些问题都会导致软件开发过程中的困难和挑战。软件设计的不完备性也是软件复杂度的一个重要来源。设计不完备性包括设计缺陷、设计矛盾、设计冗余等，这些问题都会导致软件开发过程中的困难和挑战。010201复杂系统的属性7.1.1软件的复杂性一千个人有一千个哈姆雷特，市场上解决某一问题的方法有多个，开发语言有java、c、python、golang等等，数据库方面有关系型数据库oracle、mysql、sqlserver，也有非关系型的NoSQL。怎样进行技术选型，怎样进行基础建模和算法选择？怎样实现团队内部语义的统一，概念设计怎么开展？

软件复杂度问题是不可能完全避免的，但是这并不能成为忽视软件复杂度的理由，有很多措施可以帮助尽量避免自身的需求分析，开发工作中引入问题代码而导致软件复杂。开发前通过需求梳理沉淀需求分析、架构设计等文档作为知识传递的载体。开发中需要强化系统架构理解，战略优先于战术，系统分层架构清晰统一，开发中接口设计要做到高内聚和低耦合同时保持良好代码注释的习惯。维护阶段进行代码重构，针对之前存在设计问题的代码，以新的思维和架构实现方案进行重构使得代码越来越清晰。01复杂系统的属性7.1.2复杂系统的5个属性

一般而言，复杂系统具有以下5个属性:1.层次结构复杂系统往往是由层次结构的形式存在，如果人有表层-肌肉-内脏一样。由一些相关的子系统构成，这些子系统往往又有它们自己的子系统，如此下去，直到最底层的基本组件。

此处的层次是Hierarchic，不是Layer。系统可以自顶向下，逐层分解。3.分离关注组件内的联系通常比组件间的联系更强，实际上将组件中高频率的动作（涉及组件的内部结构）和低频率的动作（涉及组件间的相互作用）分离开来。由于组件内部作用和组件间作用的差异，可以在系统的不同部分之间实现“分离关注”，可以以相对隔离的方式来研究每一个部分。可以根据高内聚，低耦合的原则，将系统分解，实现“分而治之”。5.稳定的中间形式一般来说，复杂的系统是不断随着时间而演变，如果存在稳定的中间形式，那么从简单系统到复杂系统的演变将更快。复杂的系统毫无例外都是从能工作的简单系统演变而来的，从头设计的复杂系统根本不能工作，也不能通过打补丁的方式使其工作。必须从头开始，从能工作的简单系统开始。在这个过程中，如果存在稳定的中间形式，将会大大提升演变效率。复杂系统实现时，可在不同层次复用成熟的基础对象。2.相对本原复杂系统基础组件的本质，选择哪些作为系统的基础组件比较随意，很大程度上依赖于观察者的判断。对于一个观察者是基础组件，可能对于另外的观察者而言就是一个很高的抽象层次。从不同层次观察系统，得到的模型粒度是不一样的。例如：对于一只狗，圈养者可能关注于狗的吃穿，样貌。而对于动物学家，他们可能关注的就是狗的内部构成。它的血液，骨骼等。4.共同模式许多复杂系统都是以一种经济的表达方式来实现的，层次结构通常只是由少数不同类型的子系统按照不同的组合和安排方式构成的。实际上，系统开发都是不断累积的，不同的系统中间一定有共同的东西，当前系统就有可能有前面系统的模式。换言之，复杂系统具有共同的模式。这些模式可能涉及小组件的复用，设计时，系统或子系统的结构可采用许多成熟的模式。02复杂系统与简单系统设计的区别7.2.1复杂系统与简单系统的基本区别

复杂系统和简单系统之间的区别主要在于复杂性和可预测性。复杂系统则是指那些内部结构复杂，输入和输出之间没有明确对应关系的系统。在复杂系统中，输入和输出之间的关系是非线性的，即输出不是输入的线性组合。因此，对于复杂系统，我们无法利用简单的数学工具进行建模和分析。此外，复杂系统还具有自组织性、自相似性、随机性和非线性等特性。简单系统是指那些内部结构相对简单，输入和输出之间有明确对应关系的系统。在简单系统中，输入和输出之间的关系是线性的，即输出是输入的线性组合。因此，对于简单系统，我们可以利用线性代数和微积分等数学工具进行建模和分析。简单系统复杂系统因此，简单系统和复杂系统之间的区别主要在于它们的复杂性和可预测性。简单系统相对简单且可预测性强，而复杂系统则更加复杂且可预测性差。02复杂系统与简单系统设计的区别7.2.1复杂系统与简单系统的基本区别

具体而言，复杂系统和简单系统的主要区别体现在以下几个方面：简单系统通常由较少的、易于理解和跟踪的元素组成，而复杂系统则由大量的、多种类型的、相互作用强烈的元素组成。复杂系统的结构往往比简单系统更为复杂和精细。01组成部分和结构简单系统的动态行为和演化往往比较简单和容易预测。复杂系统的动态行为和演化则更为复杂和难以预测，这是因为复杂系统中存在着更多的交互作用和反馈机制。02动态行为和演化在简单系统中，信息和通信通常是直线的、单向的或者简单的交互，而在复杂系统中，信息和通信网络则更为复杂，具有多个层次和节点，存在着各种形式的交互和反馈。03信息和通信简单系统往往只能适应较为稳定的环境，而复杂系统则具有较强的适应性和演化能力，能够在不断变化的环境中生存和发展。04演化和适应简单系统往往不具备学习和演化的能力，而复杂系统则能够在不断地学习和演化中适应新的环境和挑战。05学习和演化02复杂系统与简单系统设计的区别7.2.2复杂系统与简单系统设计的不同

架构设计存在两类系统的设计：大型系统和简单系统的架构设计。如何进行大型系统设计？首先，需要思考几个问题。PART01大型系统和简单系统设计有什么区别？PART03如何进行大型系统设计？PART02大型系统设计就是分布式设计吗？02复杂系统与简单系统设计的区别7.2.2复杂系统与简单系统设计的不同

1.大型系统与简单系统设计的区别：从系统的简易程度可以将系统分为复杂系统或简单系统。这里称复杂系统为大型系统，大型系统是复杂系统，一般是指规模大、复杂度高的系统。而简单系统是指规模小，复杂度也不高的系统，一般是单体，也可能是分布式架构的简单系统。简单的对比如表7-1。对比项/对比类型大型系统简单系统系统类型分布式系统一般是单体系统业务复杂度复杂简单规模复杂度复杂简单技术复杂度复杂简单资源投入多少表7-1大型系统与简单系统对比2.大型系统设计就是分布式设计吗？通俗讲，大型系统是有多个单体系统或简单系统组成的，一般都是分布式系统，为什么不用分布式系统呢？因为分布式已经到了技术层面，而系统的设计，应该从非技术到技术，而不是本末倒置。02复杂系统与简单系统设计的区别7.2.2复杂系统与简单系统设计的不同

3.如何进行大型系统设计？面对复杂问题，一般采用“分而治之”的思想，将大问题分解为小问题，解决掉小问题，大问题自然迎刃而解。对于系统设计来说，就是将系统拆分到适当的粒度，再组合的过程。分布式系统，微服务架构都是“分而治之”思想的体现。事物是变化的，深一点讲，如果掌握了事物的本质，自然不必为问题而烦恼了。一般系统的设计，需要考虑几个层面：业务层面，系统层面，技术层面。业务层面是把要解决的问题搞清楚，系统层面进行系统的设计，技术层面确定使用什么使用实现。简单系统遇到的问题类型类似，但是设计的深度不一样，规模不一样。比如管理一个公司和一个国家，都是管理，两者的管理不一样。大型系统的设计步骤可以描述如下。大型复杂系统的设计不是一开始就进行架构设计，核心也不完全是分布式技术架构。而是要从业务开始，进行逐步设计的过程。其实简单系统也是类似的逻辑，这也就是麻雀虽小，五脏俱全的道理吧。02复杂系统与简单系统设计的区别7.2.2复杂系统与简单系统设计的不同

3.如何进行大型系统设计？图7-1复杂系统的设计步骤业务架构设计，系统架构设计，技术架构设计，输出解决方案，其中系统架构又包括应用架构和数据架构，以上统称为企业架构。在进行了以上设计的基础上，才会进入单系统的设计（以RUP4+1视图为参考）。02复杂系统与简单系统设计的区别7.2.2复杂系统与简单系统设计的不同

1.业务架构设计

系统建设是为业务服务的，所有的系统建设都是为了解决业务问题。因此，首先做的是进行战略分析和业务架构设计。

业务架构是企业治理结构、商业能力与价值流的正式蓝图。明确定义了企业的治理结构，业务能力，业务流程、业务数据。业务能力定义企业做什么，业务流程定义企业怎么做。图7-2业务架构设计企业治理结构指组织架构，包括组织结构，业务渠道和合作伙伴。业务能力包括价值链，功能域和功能子域。业务流程可以细分为主干流程，分支流程和业务规则。业务数据是支撑业务的数据梳理，包括数据域，数据模型和数据规则。02复杂系统与简单系统设计的区别7.2.2复杂系统与简单系统设计的不同

2.应用架构设计

应用架构是一组应用系统及其交互关系的描述，每个应用系统都是一个“逻辑功能组”，用于支撑业务功能、管理数据资产。从服务层面对业务进行支撑，主要是识别功能和服务，划分应用系统，并完成应用系统的交互设计以及应用相关的管理工作。（1）应用架构不关注应用内部的结构，主要是识别业务和数据需要哪些系统支撑。（2）应用架构很好的体现了“分而治之”的思想，在将功能识别后，分配到不同的应用。（3）分析业务需要支撑的功能和服务，将功能和服务分配到组件和应用，设计应用之间的交互和协作。图7-3应用架构设计02复杂系统与简单系统设计的区别7.2.2复杂系统与简单系统设计的不同

3.数据架构设计

数据架构是设计数据资产管理蓝图，用于指导如何分析数据需求，如何进行数据架构设计。包括数据的分类和来源，逻辑数据资产，物理数据资产，数据管理，以及数据的结构和交互。简单讲就是建立数据模型，数据存储和分布设计，进行数据的管理。图7-4数据架构设计02复杂系统与简单系统设计的区别7.2.2复杂系统与简单系统设计的不同

3.技术架构设计

确定系统建设的技术体系，包括技术需求，技术选型，技术架构设计和技术管理等。图7-5技术架构设计技术选型：平台选型（运行平台，开发平台），技术产品（框架，中间件，产品），物理选型（硬件，网络）等；架构设计：组件架构，网络架构，部署架构等；技术管理：技术大图，选型标准，技术案例等；03复杂系统的结构7.3.1复杂系统的递阶结构

复杂系统的递阶结构是指系统的各个组成部分之间按照不同的层次和组织结构进行排列和连接。这些层次和组织结构可以是物理的、数学的、生物的、社会的等等，具体的类型取决于所研究的系统。在复杂系统中，各个组成部分之间的相互作用和影响可以被组织成不同的层次。这些层次可以是递进的，也可以是并行的。在递进结构中，较低层次上的变化会直接或间接地影响较高层次，而在并行结构中，各个层次上的变化可能相互独立或影响有限。递阶结构的特点是具有明显的层次性。每个层次都有自己的功能和作用，并且会影响它所包含的下一层次的内容。同时，每个层次都受到上一层次的控制和影响。此外，复杂系统的递阶结构还具有非线性和自组织性。这意味着系统中的各个组成部分之间的相互作用不是简单的线性关系，而是具有复杂的、不确定性和随机性的因素。同时，系统具有自我组织和自我适应的能力，可以在没有外部控制的情况下保持稳定和有序。复杂系统的递阶结构是指系统中的各个组成部分之间按照不同的层次和组织结构进行排列和连接，这种结构具有一定的非线性和自组织性。通过研究这种结构，可以帮助我们更好地理解和掌握复杂系统的本质和规律。03复杂系统的结构7.3.1复杂系统的递阶结构

具体而言，复杂系统的递阶架构体现在以下几个方面：复杂系统被分解为多个层次，每个层次都有自己的功能和作用，层次之间存在支配和被支配的关系01层次性层次之间的相互作用不是简单的线性关系，而是复杂的、非线性的关系。04集合性03每个层次中的元素或子系统之间相互作用、相互影响，形成一个复杂的网络结构。相关性复杂系统的递阶结构可能存在多个目标或准则，这些目标或准则之间可能存在冲突和协调的关系。07多目标性递阶结构具有自我组织和自我适应的能力，可以在没有外部控制的情况下保持稳定和有序。05自组织性递阶结构是动态的，可以随着时间和环境的变化而发生变化。06动态性02非线性性每个层次都包含一些元素或子系统，这些元素或子系统按照某种方式组合在一起。总之，复杂系统的递阶结构是一个多层次、多维度的网络结构，具有复杂性、动态性、非线性和自组织性等特点。对于复杂系统的研究和分析需要借助一定的理论和方法，如系统分析、系统工程、控制论、自组织理论等。03复杂系统的结构7.3.2功能构建模块

功能构建模块是复杂系统中的一个基本单元，它代表了系统中的某个特定功能或任务，通常由一些相互关联的组成部分或子系统构成。这些功能构建模块可以被组织成不同的层次和结构，以实现系统的整体功能和目标。具体而言，功能构建模块通常包括以下三个基本实体：指全部知识和通信的内容，包括数据、消息、信号、指令等。这些信息在系统内部传递和交流，协调各个组成部分和子系统的运作。信息材料指全部物理对象的物质，包括各种零件、部件、设备等。这些材料构成了系统的实体结构，并提供了系统运行所需的能量和动力。能源指赋予全部活动系统组件运行和移动所需的能量，包括电力、燃料、化学能等。这些能源为系统的运行提供了动力，并驱动着系统的动态行为。03复杂系统的结构7.3.2功能构建模块功能构建模块是复杂系统中的基本单元，它包含了系统实现其功能所需的信息、材料和能源等基本要素，并通过不同的方式进行组织和分类。通过对功能构建模块的研究和分析，可以帮助我们更好地理解和掌握复杂系统的结构和功能特性。功能构建模块还可以通过不同的方式进行分类和组织。例如，根据其功能特点，可以将功能构建模块分为输入模块、处理模块和输出模块等不同类型；根据其组织结构，可以将功能构建模块分为集中式模块和分布式模块等不同形式。03复杂系统的结构7.3.2功能构建模块复杂系统的功能构建模块具有以下特点：功能构建模块还可以通过不同的方式进行分类和组织。例如，根据其功能特点，可以将功能构建模块分为输入模块、处理模块和输出模块等不同类型；根据其组织结构，可以将功能构建模块分为集中式模块和分布式模块等不同形式。复杂系统的功能构建模块之间相互关联，形成了复杂的网络结构。这些模块之间的相互作用和影响是系统整体功能和行为的基础。相互关联功能构建模块之间的相互作用不是简单的线性关系，而是复杂的、非线性的关系。这些相互作用和影响可以产生协同作用或涌现出新的性质和行为。非线性性复杂系统的功能构建模块具有多样性和异构性，不同的模块可能具有不同的功能、结构、性质和行为，这些差异可以产生多样性和创新性。多样性复杂系统的功能构建模块可以按照不同的层次进行组织和排列。这些层次可以是物理的、数学的、生物的、社会的等等，取决于所研究的系统。层次性复杂系统的功能构建模块具有自适应性和自我组织的能力，可以在没有外部控制的情况下自我调整和优化，以适应环境和条件的变化。自适应性复杂系统的功能构建模块是开放性的，可以与外部环境进行信息和能量的交换和互动，以获取更多的资源、信息和支持。开放性复杂系统的功能构建模块是动态的，可以随着时间和环境的变化而发生变化。这些变化可以是自发的或由外部因素引起的，可以产生新的结构和行为。动态性

总之，复杂系统的功能构建模块具有相互关联、层次性、非线性性、自适应性、多样性、开放性和动态性等特点。这些特点使得复杂系统具有高度的复杂性、动态性和创新性，难以预测和控制。通过对功能构建模块的研究和分析，可以帮助我们更好地理解和掌握复杂系统的本质和规律。04复杂系统的环境7.4.1环境的定义系统环境是指存在于系统外且与系统发生作用的各种因素的总称，亦即为系统提供输入或接受它的输出的各种因素的集合。它可能是物理环境、社会环境或组织环境，亦或是自然环境等。一个系统的环境可以被描述为与该系统直接或间接相关的一切事物。以下是系统环境的三个主要组成部分：物理环境是系统的基础，它包括与系统直接相关的所有物理因素，如气候、地形、地理位置、自然资源等。这些因素对系统的运行和性能产生重要影响。。物理环境社会环境是系统中人与人之间的交互和关系。这包括文化、信仰、价值观、法律和法规、社会经济条件、政府政策、市场状况等。这些因素可以影响系统的决策、行为和结果。社会环境技术环境是指系统中使用的技术、工具和设备。这包括计算机硬件和软件、通信技术、传感器和执行器等。技术环境对系统的性能、可靠性和适应性具有重要影响。技术环境需要注意的是，系统的环境是一个动态的、变化的过程，随着时间的变化和系统的演进，环境也会发生变化。因此，系统和环境之间的交互作用是复杂系统的核心特征之一。04复杂系统的环境7.4.1环境的定义复杂系统一般存在于一个特定的环境中，这个环境可以是自然环境、社会环境或组织环境。具体的描述可能会因人而异，但以下是一些可能的环境因素：01自然环境02社会环境这包括文化、信仰、价值观、传统习俗、社会结构、人口分布和流动性、经济状况等03组织环境这包括各种类型的组织机构，例如企业、政府、非政府组织、学术机构等。这些组织的内部结构和运作方式，以及它们与外部环境的互动，都可以被视为复杂系统的一部分。这包括气候（温度、湿度、雨量等）、地理位置（地形、地貌、地质条件等）、生物多样性（植物、动物、微生物等）、自然资源（水、土地、矿产、能源等）以及其他自然现象（如地震、火山喷发、潮汐等）。这些环境因素可以单独影响一个复杂系统，也可以互相影响，产生更复杂的影响。例如，自然环境的变化可能会影响社会经济，从而影响一个组织的运营；而一个组织的改变可能会影响其所在的社区，从而影响社会环境和自然环境。04复杂系统的环境7.4.2环境交互作用的形式系统环境交互作用的形式可以包括以下几个方面：02系统根据其内部结构和机制，以及从环境中接收到的输入，进行决策和行为。这些决策和行为可能对环境产生影响，并受到环境的反馈和调整。决策和行为04系统通过与环境的交互作用，不断学习和适应其环境的变化。这种学习和适应可能包括系统的结构、行为和决策的调整，以及与环境的交互方式的改变。学习和适应01系统从其环境中获取所需的资源，如原材料、能源、人力等，以支持其运行和演化。这些资源可能来自于物理环境（如自然资源）、社会环境（如人力资源）或技术环境（如软件和信息）。资源输入03系统将其决策和行为的结果输出到环境中，这些结果可能对环境产生积极或消极的影响。同时，环境也会对系统的输出产生反馈和调整。输出和影响05环境对系统的输出结果产生反馈，这种反馈可能影响系统的未来决策和行为。同时，系统也会根据其与环境的交互作用进行调整，以更好地适应环境的变化。反馈和调整04复杂系统的环境7.4.2环境交互作用的形式系统环境交互作用的形式并不是线性的，而是具有复杂性和动态性。系统与环境的交互作用是一个持续的过程，随着时间的推移和系统的演进，交互作用的形式和程度也会发生变化。复杂系统环境交互作用的形式具有以下特点：复杂系统由多个层次组成，每个层次都有其特定的环境和交互作用方式。例如，生态系统中的生物群落和物种之间的交互作用，社会系统中不同阶层和文化之间的交互作用等。多层次性复杂系统的各个组成部分和环境因素具有不同的性质和特征，它们之间的交互作用也具有多样性。例如，自然环境中的气候、地形、土壤等因素，社会环境中的文化、价值观、政策法规等因素，都可能对系统产生影响。异质性复杂系统中的各个组成部分和环境因素之间相互作用、相互影响，构成了一个复杂的网络。这种相互作用可能具有直接或间接、正向或负向、线性或非线性等特点。相互作用复杂系统是一个动态演化的系统，其环境因素和交互作用方式也会随着时间的推移而发生变化。例如，自然环境中的气候变化、社会环境中的政策法规变化等都可能对系统的行为和演化产生重要影响动态性复杂系统具有自组织和适应性的特点，能够根据环境的变化自主地调整自身的结构和行为方式，以适应环境的变化。例如，生态系统中的生物种群能够根据环境的变化自主地调整自身的数量和分布方式，以适应生态环境的改变。自组织和适应性需要注意的是，复杂系统环境交互作用的形式是一个复杂而动态的过程，需要综合考虑多种因素和采用多学科的方法进行研究。04复杂系统的环境7.4.3接口系统接口定义为两个或多个系统之间进行交互和信息交换的界面。它可以是硬件接口，也可以是软件接口，或者两者兼有。硬件接口是物理设备之间的连接方式，例如USB接口、HDMI接口等；软件接口是不同软件系统之间进行数据传输和信息交换的方式，例如API接口、Web服务接口等。接口在复杂系统中，系统接口通常指软件接口，它们是不同系统之间进行信息交互和集成的主要手段。通过系统接口，不同的系统可以相互连接、共享信息、协调工作，实现更高效的信息处理和决策支持。例如，企业资源计划（ERP）系统与生产管理系统（PMS）之间的接口可以实现生产计划、物料需求计划、生产执行等功能的集成，提高生产效率和资源利用率。系统接口的设计和实现是系统集成的重要环节，需要考虑接口的标准化、开放性、安全性等因素。随着云计算、物联网、大数据等技术的发展，系统接口的种类和数量也在不断增加，为不同系统的集成提供了更多的选择和灵活性。04复杂系统的环境7.4.3接口复杂系统的接口设计是复杂系统构建的重要环节，它涉及到不同系统之间如何进行信息交互和集成。以下是一些具体步骤：首先需要明确每个系统之间的信息交互需求，包括数据的类型、格式、传输方式、访问权限等，以及接口需要实现的功能和性能要求。选择接口类型：根据实际需求，选择适合的接口类型。常见的接口类型包括API接口、Web服务接口、消息队列接口等。确定接口需求根据接口需求和选择的接口类型，设计相应的接口规范。接口规范应包括接口的名称、地址、请求方法、请求参数和返回结果的格式、数据类型等详细信息。设计接口规范按照接口规范，开发相应的接口实现代码。这包括编写接口的客户端和服务端代码，并对其进行测试和调试，确保接口的功能和性能符合要求。开发接口实现将开发好的接口服务部署到相应的服务器或云平台上，并对其进行监控和维护，确保接口服务的稳定性和可用性。部署接口服务0102030404复杂系统的环境7.4.3接口外部接口是提供给其他系统或应用调用的接口，通常需要遵循一定的接口协议和标准，以确保信息的正确传输和互操作性。例如，在一个智能交通系统中，外部接口可能需要提供给交通管理部门、地图服务商、用户等外部实体调用，以实现交通信息的共享、查询、规划等功能。在复杂系统中，外部接口和内部接口的设计和实现都需要遵循一定的规范和标准，以确保信息的正确性和安全性。同时，它们也需要经过严格的测试和验证，以确保其功能和性能能够满足系统的需求。此外，随着系统的不断升级和发展，外部接口和内部接口也可能会进行相应的调整和升级调用接口：通过相应的客户端程序调用接口服务，实现不同系统之间的信息交互和集成。客户端程序需要根据接口规范来编写，并使用相应的请求参数和返回结果进行通信。0103复杂系统的接口设计是一个复杂而细致的过程，需要考虑的因素很多，包括接口的性能、可靠性、安全性、标准化等。同时，还需要与系统的整体架构和业务需求相匹配，以确保系统的正常运行和信息交互的顺利进行。在复杂系统中，外部接口和内部接口的概念也适用。0502内部接口则是系统内部组件或子系统之间进行信息交互和调用的接口。这些接口通常需要考虑系统架构、模块划分、数据共享等问题，以确保系统内部的稳定性和可维护性。例如，在一个银行系统中，内部接口可能是不同部门之间进行数据交互和信息共享的接口，如贷款部门与风险管理部门之间的接口等。0404参考文献[1]鄂大伟.软件工程视域下的软件复杂性研究[J].复杂系统与复杂性科学,2005(4):1672-3813.[2]万江平，杨建梅.软件过程改进的复杂性工作程序研究[M].科学出版社,2004.[3]车宏安.复杂系统的层级结构—兼讨论相互作用的规律性[J].系统工程理论与实践，2008(6):1000-6788.[4]司马贺.人工科学--复杂性面面观[M].武夷山译.上海科技教育出版社，2004.ThanksNorthwesternPolytechnicalUniversity基础扎实工作踏实作风朴实开拓创新第八章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