4.4 架构定义过程
4.4.1 目的
正如ISO/IEC/IEEE 15288所述：
架构定义过程的目的是生成系统架构备选方案，选择出能够框定相关方关注点且满足系统需求的一个或多个备选方案，并以一系列一致的视图对备选方案进行表达。
4.4.2 概述
架构（Architecture）一词来源于建筑界，如哥特式建筑、斗拱飞檐式建筑、穹顶式建筑等。但建筑物的“架构”不仅仅指外观的风格，还反映出建筑物的突出特征，尤其是其功能特征。例如：斜拉索桥和悬索桥就是不同的桥梁架构，桥面的基本受力情况是不同的；民用住宅的框架式和砖混式架构，墙体的承重情况是不同的。这些差异无论是对建造者还是使用者，都有重大的现实意义。系统功能灵活、可扩展、可进化，往往体现了用户的价值主张。这些特性通常是由系统架构决定的。
架构一词往往让人直接想到系统外在可见的结构特征，但事实上它同时隐含着某种特有结构所承载的特有的功能性特征。这种形式与功能之间的关联关系才是架构的本质，是架构的内核。局限于结构特征来理解架构是不合适的。
架构定义是从解决方案空间向设计空间过渡的环节，是连接系统功能与系统形式的环节。可以将架构定义理解为一个分水岭，在架构之前重点研究和描述系统功能和行为逻辑而不描述系统实体，在架构之后主要研究和描述系统实体。架构定义的重要价值在于将两者有效衔接起来。架构定义既关注系统功能，又关注系统实体，但仅限于系统的高层级功能和系统内的主要系统元素以及系统和系统元素的主要特征，并对系统实体如何实现系统的高层级功能做出必要的设计、分析和描述。
架构定义可以采用自顶向下与自底向上相结合的方式。架构定义过程并不总是处于需求定义过程与设计定义过程之间，也可以超越特定的系统研发项目，作为预先研究项目单独实施。例如，针对战斗机机载电子系统架构研究的“宝石柱计划”（Pave Pillar）就是先于F-22飞机的研制独立实施的，而且同样的架构可以应用到不同的系统中。
系统架构定义和设计活动需要密切协同配合，基于统一的原则、概念和特性来构建全局解决方案。在较早的《INCOSE系统工程手册》中架构定义和设计定义是综合在一起的，架构向上要能满足系统需求及生存周期概念所表达的特征、特性，设计向下要能够通过一系列切实可行的技术（如机械、电子、软件、服务与程序等）来实现。两者之间密切协同，但还是有明显区别的，一个在逻辑域，一个在物理域。因此在《INCOSE系统工程手册4.0》中将这两个过程分开描述。系统架构是对系统和系统元素更高一层的抽象表达，系统架构使用系统逻辑元素描述系统，关注有系统元素交互所涌现出的整体特性及特性实现的路径和基本原则，不关注具体如何实现；而系统设计将转向物理层面聚焦于如何从技术上实现和实现到多好。
架构定义过程用于通过多种视图和模型来创建系统架构，并针对架构中系统元素提供多种可行的技术方案及方案组合，从而建立不同备选的架构，通过综合权衡分析来评估这些备选方案的特性，并选择构成系统的合适的技术元素或技术系统元素。在工程实践中，这一活动通常被称为完成系统顶层构型。
4.4.3 活动描述
图4-26所示为根据《INCOSE系统工程手册》架构定义过程IPO图改编的架构定义过程图。
根据ISO/IEC/IEEE 15288：2015，架构定义过程包含以下活动：
（1）架构定义准备
1）审查相关信息并识别架构的关键因素。
2）识别相关方关注点。
3）定义架构定义路线、方法与策略。
4）定义基于相关方的关注点和关键需求的评估标准。
5）识别并计划必要的使能系统与服务以支持架构定义过程。
6）获得或购买使能系统或服务的使用权。
图4-26 架构定义过程
（2）开发架构视角
1）基于相关方关注点选择、调整或开发架构视角与模型类型。
2）建立或识别潜在的架构框架用于开发模型和视图。
3）获取选择架构、视角和模型类型的理由。
4）选择或开发支持建模的技术和工具。
（3）开发候选架构模型和视图
1）根据接口及与外部实体的交互定义系统上下文和边界。
2）识别架构实体和实体之间的关系，解决关键的相关方关注点和关键系统需求。
3）分配概念、属性、特征、行为、功能或约束（这些对系统架构决策至关重要）到架构实体。
4）选择、调整或开发系统候选架构的模型。
5）使用架构视图（由确定的视角模型构成）来表达架构如何应对相关方关注点，并满足相关方需求和系统需求。
6）使每一个架构模型和视图协调。
（4）架构关联设计
1）识别关联到架构实体的系统元素以及这些关系的本质。
2）定义系统元素之间以及系统元素同外部实体之间的接口与交互。
3）分隔、调整和分配需求到架构实体和系统元素。
4）将系统元素和架构实体映射到设计特性。
5）定义系统设计与进化原则。
（5）评估候选架构方案
1）根据约束和需求评估每个候选架构。
2）使用评估标准根据相关方关注点评估每一个候选架构。
3）选择首选架构并捕捉关键决策和理由。
4）建立所选架构的架构基线。
（6）管理所选架构
1）形式化架构治理方法并说明治理相关的角色、职责、职责描述和管理当局(与设计、质量、安全、保密等相关)。
2）通过相关方获得明确的架构验收。
3）维护架构实体及其架构特性的一致性和完整性。
4）组织、评估和控制架构模型和视图的演化。
5）维护架构定义和评估策略。
6）维护架构的可追溯性。
7）为基线提供已选定的关键信息项。
4.4.4 关键要素解析
1.架构视角与视图
企业架构的主要用处是在企业或组织的各个相关方之间建立起一座无障碍沟通的桥梁，因而“沟通”是企业架构的主要精神之一。这里所说的“沟通”，不单单指的是人与人之间的沟通，业务信息系统本身也可以被看作是“相关方”，只不过它们所需要的企业架构的描述信息在抽象程度上比自然人更加精细、所使用的语义也更加规范罢了。即便不考虑各种干系人中的自然人与信息系统之间的不同，不同相关方之间由于其背景、责任的差异，其对于企业的关注点也具有很大的不同，而这些不同也造就了各种不同的视角（View Point）。通过不同视角观察所得的关于系统对象的某一侧面形象就产生了此视角之下的一份视图（View）。诗句中的“横看”“侧看”就是不同的视角，而“岭”和“峰”就是在对应视角下的各自所形成视图。一言以蔽之，视角用于描述从何处看，而视图则是看到的内容，视角是视图的模式，而视图是视角的实例化结果。我们日常所说的功能架构，就是从功能视角观察系统对象得到的架构视图，逻辑架构就是从接口、交互与逻辑的视角观察系统对象得到的视图，而物理架构就是从物理构型的视角观察系统对象获得的视图。
TOGAF 9对视角与视图给出了以下定义：
（1）视角（View Point） 一个针对某视图所采用的观察角度的定义，是构建和使用某视图的规约的描述（通常采用一个适当的模式或模版的形式）。通俗地说，视图描述了所看到的内容；而视角则描述了站在何处进行观察——一个能够决定你所能看到事物的制高点或角度。
（2）视图（View） 针对一系列相互关联的关注点的表达。一个视图描述了采用某个视角后所看到的事物。架构视图可以通过模型来进行表述，从而为不同的相关方根据各自针对架构的关注点而分别提供描述。一个视图从本质上讲不一定以可视化或图形化的方式进行展示。
（3）架构视角 为特定系统关注点框架的架构视图的构建、解释与使用建立规约的工作产品。
（4）架构视图 从某一个特定的系统关注的角度表达系统架构的工作产品。
2.功能架构—逻辑架构—物理架构
因为一个系统的架构通常是比较复杂的，所以通常需要从多个视角对架构进行分析和描述，这就是我们日常所说的各种架构，如功能架构、逻辑架构、物理架构等。
（1）功能架构 在FBSE（基于功能的系统工程）方法中的关键要素。作为在需求文档或规范中定义的功能集，每一层都具有被分配到该层的功能、性能和限制需求（极端情况下，在最顶层，唯一的功能就是系统本身，且所有需求都被分配给该系统）。开发并评价功能架构的下一个更低层级，以确定是否需要进一步分解。若是，则通过一系列层级来迭代该过程，直到功能架构完成。
功能架构的开发需要迭代地开展：
1）为满足更高层级的功能需求，要定义所需的相继的更低层级的功能，并且定义功能需求的备选集合。
2）用需求定义去定义任务和环境驱动的性能并确定更高层级需求得到满足。
3）让性能需求和设计约束向下游流动。
4）用架构和设计去细化产品和过程解决方案的定义。
在每个层级都要考虑并评价每个功能的备选分解和分配，并选择一个单一版本。所有功能被识别后，要建立被分解的子功能的所有内部和外部的接口。
功能架构的目的在于开发满足系统所有功能需求的FFBD（功能流框图）层级结构，也就是常说的功能分解结构（FBS）。然而，需要注意的是，功能分解结构（FBS）只是功能架构的一部分，只有当所有性能需求和约束需求已被适当地分解并分配给功能分解结构（FBS）的元素后，功能架构才完成。
功能分解结构（FBS）中每个功能的描述，应该包括以下内容：
1）其在网络（如FFBD或IDEF 0/1图)中的位置描述与该层级上其他功能的相互关系的特征。
2）已被分配到层级结构上且定义它做什么的功能需求集合。
3）其内部和外部的输入及输出。
OOSEM（面向对象的系统工程方法）综合面向对象的概念和基于模型的、传统的SE方法，以帮助架构适应技术不断演进和需求不断变化的灵活的、可扩展的系统。OOSEM支持系统的规范、分析、设计和验证。
在OOSEM中，系统被建模为“黑盒”来表达与外部系统和用户的相互作用。使用用例和场景反映系统的运行概念。通过“泳道”活动图来表达“白盒”系统、用户和外部系统，推导“黑盒”系统的功能需求、接口需求、数据需求和性能需求。通过逻辑架构定义将系统划分为多个逻辑元素，通过逻辑元素相互作用以满足系统需求。
在OOSEM中，逻辑架构定义活动包括将系统分解并划分成多个逻辑元素，逻辑元素之间相互作用，以满足系统需求并捕获系统功能性。
（2）逻辑架构
逻辑架构/设计的存在可以缓解需求和技术变化对系统设计的影响。逻辑元素的功能经逻辑场景导出，以支持“黑盒”系统功能。逻辑场景是通过“泳道”活动图来表达的，因此每一个“泳道图”对应一个逻辑元素。逻辑元素的功能性和数据可能基于诸如内聚、耦合、面向变化的设计、可靠性和性能等其他准则来进行重新区划。
（3）物理架构
物理架构描述物理系统元素（包括硬件、软件、数据、人员和程序）之间的关系。将逻辑元素分配给物理元素。系统架构被继续细化，以应对与软件、硬件和数据架构相关的关注点。对每个物理元素的需求可追溯到系统需求，并保存在需求管理数据库中。
功能架构需要在每一层级完成定义系统做什么的功能需求集合，并定义内外部输出；而逻辑架构中需要基于诸如内聚、耦合、面向变化的设计、可靠性和性能等来区划逻辑元素的功能性，并描述逻辑元素之间的相互作用。两者实质上是一回事。
因此，在IBM的统一软件开发过程（Rational Unified Process，RUP）中，功能架构也被称为逻辑视图，也就是将系统按功能进行分层、分组件，并描述这些层及组件之间的关系。
在Systems Engineering Fundamentals：2001中，需求分析与分配过程的输出结果就是功能架构。功能架构是描述系统在逻辑上应该做什么以及所需要的性能，功能架构包含了逻辑上的描述。在OOSEM中基于“泳道”活动图进行场景描述的系统需求分析的基础上提出了逻辑架构定义，明确了系统功能区划与逻辑架构的关系，再后来，Dassault公司将这些关系用RFLP（需求、功能、逻辑、实体）进行了概括性描述。本质上，功能架构与逻辑架构是一回事，后来逐渐将二者进行了区分。如果非要指定哪一个模型表达了系统的功能架构，哪一个模型表达了逻辑架构，那么，笔者认为，SysML中的BDD图（块定义图）大致相当于功能架构，对应FBS的顶层节点；而IBD图（内部块图）相当于逻辑架构，描述内外部关系与接口；物理架构相当于解决方案中的顶层构型，是架构权衡后确定的实体组合。
3.接口与功能划分
术语“接口”是指“在事物之间做事情”。因此，接口的基本方面是功能性的，且被定义为功能的输入和输出。因为功能是通过物理元素实施的，所以功能的输入/输出也通过物理接口的物理元素来实施。其结果是，功能方面和物理方面都被考虑到接口的观念之中。
系统与环境（包括其他系统）之间的交互发生在各种系统的边界，这样的边界被称为系统的外部接口。
在系统内部，各个组件之间的边界构成了系统的内部接口。内部接口的定义是系统工程师所关注的，内部接口的定义和实现通常包括考虑权衡影响这两个组件的设计。
耦合矩阵图，也被写为N2图或N二次方图，是在一个矩阵中描述系统元素之间的功能或物理的接口。它被用来系统地识别、定义、制表、设计、分析功能和物理接口。N2图适用于系统接口以及硬件和（或）软件接口。
因此，在系统功能架构定义过程中，需要完成系统功能的划分，形成系统不同的功能架构元素。对系统功能的划分，通常要遵循两个原则：一是按照功能相似性划分功能；二是接口尽量简单。
在工程实践中，尤其是在MBSE建模过程中，使用泳道图来完成相似功能划分，使用耦合矩阵（N2图）分析系统元素之间的接口关系，理论上有可能使某一层级系统元素之间的一部分接口变为该层级系统元素的内部接口，从而简化该层级系统元素之间的接口（图4-27）。
图4-27 使用耦合矩阵让接口简单
接口的简单性可以是备用架构候选方案之间的区分特征和选择准则。耦合矩阵还用于优化聚集定义及接口的验证。
4.涌现性
涌现是系统元素通过相互作用呈现某种功能或特性的现象。这些功能或特性仅对于系统整体才可能呈现出来，而不可能由任何一个系统元素独自发挥作用即能呈现。人类活动系统的每一个模型都是从其组件活动及其结构导出的全部实体来呈现特性，但并不能将其还原到这些组件活动和结构(Checkland，1998)。
系统元素之间进行交互，并且可产生期望的或不期望的现象被称作“涌现性”，如任何特性的抑制、干扰、谐振或增强等。系统架构的定义包括对系统元素之间交互的分析，以抑制不期望的涌现并增强期望的涌现。
在架构和设计期间使用涌现性的观念，以强调必须导出的功能及内部物理的或环境约束。当相应导出的需求影响SoI时，应将它们添加到系统需求基线中。
正是由于系统元素之间存在关联关系，系统才得以存在。如果系统元素之间的关系是确定且稳定的，那么由此形成的功能也是确定且稳定的，这类涌现是可设计的。例如钟表内部的齿轮之间存在确定且稳定的啮合关系和传动比，涌现出的功能是分针与时针能共同指示时间；假如只有分针而没有时针，则钟表就丧失了指示时间的功能。
另外一种类型的涌现会让人感到“惊诧”，如由一些未知的关系、不确定性的关系、非线性关系、系统元素失效、系统参数的随机性、环境参数的随机性等原因导致的涌现。
“未知”是指“没想到”，事实上是应该想到的。人的思维能力毕竟是有局限性的，尤其不善于对复杂系统的状态做遍历性的思考和分析。对于这种情况，常常有必要建立数字模型，借助计算机进行分析。
不确定性关系或非线性关系导致的涌现，往往使系统的构造者“无能为力”。
对于系统参数随机性和环境参数随机性导致的涌现，就需要有针对性地对系统做必要的误差分析，采取必要的误差控制措施。这时需要借助概率论作为理论工具。
对于系统元素失效导致的涌现，需要做必要的预计和合理的设计。例如牵引车对拖车的制动控制，往往采用气压制动。如果气路漏气导致失压，则拖车的制动系统会自动启动制动，这涉及正逻辑和反逻辑策略。试想一下，假如采用相反的逻辑会如何——气路内低压时拖车正常行驶，牵引车提供高压时启动拖车制动？一旦气路故障导致失压，拖车的制动系统就会彻底失效。
让人“惊诧”的涌现并非都是坏事，事实上越是灵活的系统，往往越容易让人“惊诧”；反之，永远不会让人“惊诧”的系统，往往也意味着它不够灵活，缺乏适应性，在变化的环境和威胁中会显得生存力不足。毕竟世界是不停变化的，某些系统的适应性甚至是建造者重点追求的特征。
涌现现象尤其常见地发生在体系（System of Systems，SoS）中。SoS与系统的重要差别在于，SoS不存在稳定的边界，SoS内成员系统的类型和数量都可能会动态变化，成员系统之间的关联关系也会动态变化。这些特征决定了SoS中的涌现可能是非常常见、非常丰富的。
4.4.5 案例——导弹系统架构定义（MBSE方法）
在导弹系统案例（图4-28）中，使用基于模型的系统工程方法进行导弹系统的架构定义，其中包括从功能视角完成功能架构定义、从逻辑视角完成逻辑架构定义、从物理构成视角完成物理架构定义。
图4-28 导弹系统
功能架构包含了一系列的模型，如图4-29所示。在功能架构定义过程中，可以根据黑盒活动图，使用泳道图进行功能分配，按照功能相似性与交互的原则进行功能划分，形成功能架构。这个过程通常在MBSE建模活动中不涉及，因为现在所开发的系统对象，通常都不是从零开始开发的，借鉴过去的经验，功能架构完全可以通过经验获得。功能架构定义并不是在架构定义才开始的，是从系统需求定义开始的，不断地持续完善。
图4-29 功能架构示意（图片来源：索为公司）
逻辑架构定义就是要定义各个功能块之间的逻辑、交互与接口，以及系统与外部环境的交互与接口，如图4-30所示。正如在功能架构-逻辑架构-物理架构章节所描述的那样，功能架构与逻辑架构没有很明确的界限，IBM在RUP中甚至将功能架构也称为逻辑视图。同样，逻辑架构也包含了一系列的模型，与功能架构中的模型有很多重叠，如果非要指定一个模型，那么IBD更具有代表性。
而物理架构则基本反映了系统的物理构型。需要考虑每一个逻辑构成元素可行的技术方案，然后对每一种可行的技术方案进行权衡分析。图4-31展示了在本案例中针对不同逻辑构成元素的可行技术方案的权衡分析过程示意，案例中仅列举了基于性能指标的权衡，工程实践中将考虑多种因素进行综合权衡。
传统的权衡分析过程一般是由专家根据经验对不同的技术方案进行分析、打分，选择最优配置。随着信息技术的发展，可以借用更多的仿真分析技术参与到权衡分析过程中，从而使得权衡分析过程更为科学、准确。
根据权衡分析结果，形成本案例的物理架构，如图4-32所示。
架构定义过程是最能体现创造性的过程，系统涌现性在这一过程中得到充分的体现。图4-33描述了在整个系统定义过程中的应用模式创新与技术创新。右上方点画线框描述了架构定义中的应用模式创新，左边点画线框是技术创新，中间较粗点画线框中的内容反映了架构定义中应用模式创新与技术创新的关系。架构定义本身既包含了应用模式创新的内容，也包含了技术创新的内容。当新的架构要素加入到系统时，新要素与其他要素的交互会涌现出新的特性，新特性部分就是该系统的创新部分；同时，在考虑采用什么技术方案实现的过程中，引入了技术创新内容。
图4-30 逻辑结构示意（图片来源：索为公司）
图4-31 技术方案权衡分析表（图片来源：索为公司）
图4-32 系统物理架构示意
图4-33 架构定义与创新
架构定义过程是连接抽象逻辑层面定义与设计实现的关键环节。因此，在工程实践中的架构定义需要同系统需求定义以及后面的设计定义过程进行持续迭代。在架构定义过程中，需要针对每一个逻辑元素描述相应的可选技术方案，这一过程，需要设计定义过程密切配合。架构定义与设计定义一起完成系统的顶层构型，形成物理架构。