商业架构概念的完成，能够有效地帮助系统架构人员全面、清晰、准确地构建一个商 业所涉及的内部及外部各种重要的概念：组织结构划分、人员角色及职能分工、业务流程 组成、业务活动顺序、业务信息交换与信息依赖、业务规则要求等静态及动态商业特征。 通过商业架构概念的构建，系统架构人员已经完全具备了该商业领域的相关运作及管理概 念，从而为应用架构概念阶段的工作做好了铺垫。
虽然在第4.1节中，通过架构工作中的第一个环节——构建商业架构概念，我们己经梳 理了基本的商业运作情形及目前运作时的结构，但是我们依然不能回答这样一系列问题，如：
•当要求我们构建和设计的新系统投入正常商业运作后，整个商业运行情况会是什么 情况？
•新系统的投入运营，对商业组织结构有怎样的影响？
•人员角色和职责是否有变化，会如何变化？
•商业以往的业务活动和业务流程会有怎样的变化？
•商业既定的规则会因新系统的投产而发生怎样的变化？
为了解决这些问题，我们必须认真而详细地做一些工作，也就是业界通常称之为构建 所谓的“应用架构概念”。我们还是用流程卡的方式，来看看在一般实践中架构师是以怎样 的流程来构建应用架构概念，如表4-2所示。
表4~2应用架构概念构建流程卡
|
目标描述：
建立商业应用模型，就是系统化地规范下述活动：当新系统投入使用后，构想其商业运行的各种重要环节及信息交换 发生的变化（例如：组织结构关系、商业功能及商业活动、商业流程、信息交互及依赖、商业结构地理分布、商业规则和 约束条件、商业目的、战略决策），并最终淸晰定位系统边界，建立系统基线架构的工作基础，从而为后续逐步构建系统 基线架构提供概念级的帮助。
|
|
|
负责人员：
•软件系统总架构师
|
...
|
|
.....
|
...
|
从上述流程卡来看，似乎需要执行的子流程/活动与商业概念构建阶段基本一致，那么 我们为什么又要重新执行一遍相同的动作呢？
业界普遍使用的所谓构建“应用架构概念”,有时也被称为构建“架构远景(Architecture Vision)”或“应用远景（Application Vision)”。无论冠以怎样的名词，此阶段的主要目的 是一致的：就是让架构人员、设计人员、各个Stakeho丨ders对未来投产的系统有一个稳定、 清晰、准确的认知和概念。具体地讲’应用架构概念与商业架构概念的区别在于应用架构 概念着重考虑如下方面：
当新系统或各个子系统按照时间表投入商业运作后，最高层面的业务将如何运作。
新系统的投产’会使原来的商业组织结构有怎样的变化或重新划分。
随着新系统取代了一些以往的商业运作职能，商业运作节点的分布会发生怎样的变 化，各个节点（此时已经包括了新系统）间的信息又是如何交换和依粕的。
作为未来重要的一些商业节点’商业运作时事件的传递又会出现怎样的变化。
未来新系统的运行必然使以往的一些商北运作活动/洗程发生重大变化。那么有哪些 依旧按照以往的活动顺序，而又有哪些商业活动/流程会发生变化。
商业运作从一个扶态转换为另外一种状态，必然会受到新投产系统的影响。
商业运作时，数据交换已经从原先的流动顺序，变为了必须考虑新系统参与其中的 一种交换过程。
商北数据模型也会随着系统的运行而发生根本变化。
随着新系统的介入，原先的一些商业运作规则及约束已经为新系统所取代，相应的 一些新的规則需要建立。
从这些角度出发，重新构建一个未来系统投入商业运行后完整的商业运行概念，就是 我们称之为“应用架构概念”的本意。
114.3礴立和稳定架构基线
前期“商业架构概念”及“应用架构概念”的构建，已经为我们继续完成后续的架构 工作提供了详尽的概念参考模型。我们已经完全了解了一个商业在当前状态下是怎样进行 商业运作的；我们也能够清晰地回答当要进行构建的系统在成功实施后，整个商业会如何 转变运行模式的问题。
但是，系统架构构建的工作不能只是停留在上述两项工作上，架构师还得继续回答如 下一系列问题，例如：
•整个复杂系统到底能够切分为哪些功能性的子系统？
•这些子系统如何分布在不同的商业运行节点上或者物理地点上？
•这些分散的子系统会提供怎样的接口，从而进行交互操作？
•各个子系统间需要交互哪些数据？
•这些单独的子系统，各自需要实现的功能有哪些？
•整个系统及各个子系统在提供的功能上有哪些性能或质童上的要求？
要回答这些问题，我们还需要进行下一步极为重要的工作，即“鷂立和稳定架构基线”。 之所以用“基线”（Baseline)这样的词汇来表述，主要有两个方面的原因：第一，这个阶 段进行的工作，要做出很多重大的架构及设计方面的决策（Architecture and Design Decision),这些决策对未来的开发工作有着决定性的指导意义，同时这些重大决策将影响 后续的开发工作。一旦做出架构及设计方面的重大决策，那么在后续的架构、设计和开发 过程中，非特殊情况下都不允许发生架构的重大漂移。第二，这个阶段完成的工作，本身 就是系统架构构建阶段的一个重要结果。这个结果是现阶段得到大家广泛认同、需要集体遵守带有强制约束力的一个重要基线。虽然这样的架构基线会随着一个系统整个生命周期(系统设计开发、演化、成熟等）不同阶段而逐步细化及变化。但是，在系统初创时期必须 确立一个这样的架构基线。
为了逐步确立这样一个“架构基线”，需要我们在整个系统的层面上构建出一个架构模型, 从而圆满回答那些系统级的、最高层面的、需要架构人员回答的问题。通常，我们会通过下述 流程卡中介绍的活动，来完成这样一个确立和稳定系统级架构基线的工作，如表4>3所示。
表4*3架构基线构建流程卡
|
目标描述：
逐步确立系统架构模型.全面规划一个架构基线，为后续设计及实*提供强制性架构约束•这样的目标，要求淸晰地 构建出：整个系统的切分、系统的功能划分、切分系统的分布、系统间的接口及交互、系统间物理通信结构、系统间功能 协同、系统物理数据模型、整个系统及各个子系统的质量要求、系统功能演化计划、系统架构/设计/实施所参照的标准。 该基线的完成.能够有效地为后续展开的设计工作提供帮助.
|
参与人员：
• Stakeholders 代表
•技术经理
•架构师
•子系统架构师
•构件设计/开发人员
•系统测试人员
•系统集成测试人员
•子系统测试人员
•子系统集成测试人员
|
|
负责人员：
•软件系统总架构师
|
|
|
输入：
•修订的产品颂目倌息概览
•修订的商业及系统术语字典
•商业运作总体概念
•商业组织结构
•商业运作节点及信息交换
•商业运作事件踢踪横型
•商业运作活动模型
•商业运作状态变化模型
•商业数据交换矩阵
•商业数据模型
•商业运作规则及约束
|
输入事件：
应用架构概念构建结束，
收到架构基线构建请求
|
|
活动描述：
系统架构基线阶段，校验界定前期的产品/项目信息概览，确定产品/项目的范围、目的、最终用户、商业背景等重要 初始信息，修订或补充相应信息。
继续修订和增补商业及系统术语字典，以便系统架构基线阶段的术语可以汇总进前期的术语宇典中：确保架构与设计 人员对系统架构*线的描述有一致的认知，
将整个系统要求的功能进行拆分.并分解到不同的运行节点上；将整个系统构建为不同的系统集群和子系统.并分配 到不间的运行节点上；在系统全局范围内规划系统集群及子系统间的接口和交互。
为了方便地检索和浏览.汇总整个系统范围内各个系统/子系统间的接口信息.
规划整个系统范围内各个运行节点，各个子系统间的通倌链路、通信路径.通行网络等信息传输媒介.
将“应用架构概念”中汇总的各个商业任务/职能中的商业活动与系统分解出来的各个子系统中的功能进行对应，从 而使规划的系统/子系统功能满足商业业务活动的要求
分析各个系统/子系统在运行期间动态协作时要交互的信息，
构建和模拟整个系统在投入商业运营时期的动态特性：规划全系统内部状态变化过程、触发事件及约束条件。
洋细汇总各子系统间信息传递的过程、传递的信息内容及其他辅助信息要求.
在“应用架构概念”中数据横型的基础之上，构建系统级物理数据模型。
汇总质置方面对整个系统的要求，并将整体质撒要求分解、细化、量化映射到规划的各个子系统上及相应的软件及硬件上。 构建整个系统及每个子系统的演化计划：制作系统/子系统功能堆加、整合，移除、替代等方面随时间变化的路线图计划.
规划及汇总支撑系统/子系统的各项应用技术，并按固定时段预测技术的演化.
分辨及汇总系统/子系统架构、设计、实施等阶段必须遵循的国际、国家、行业等技术标准.
将“应用架构概念”阶段汇总的商业规则及约束，映射到系统及各个子系统，并增补系统架构基线阶段的IT系统级 规则和约束.
|
|
|
•修订的产品/项目信息概览
•修订的商业及系统术语字典
•系统/子系统/功能的分布及接口
•系统/子系统间接口汇总
•节点间/物理位置间/节点内通信网络
。商业任务/活动与系统功能间的映射关系
•系统间事件跟踪模型
•系统状态变化横型
•系统间数据交互矩阵
•系统物理数据模型
•系统质量要求列表
•系统功能演化
•系统应用技术/产品演化
•系统使用标准及模型汇总
•系统规则及约束
|
|
1.系统/子系统/功能的分布及接口
应用架构概念的建立，帮助我们分析收集了全方位的各种商业运作信息。同时，这些 信息已经在各个Stakeholders及系统架构人员之间完全达成了一致的商业及运作的概念模 型基线。这个商业模型基线保证了我们可以准确、完整地完成系统架构基线的构建。
通常，我们会以“系统/子系统/功能的分布及接口”作为系统架构基线的第一个主要的 动作。这个阶段的工作，主要解决了这样一系例问题：
•整个系统范围内，可以划分为哪些功能呢？即我们需要完成哪些系统功能？
•这些功能可以在哪些子系统内集成，从而提供特定的功能集或服务集？
•这些子系统又是分布在哪些商业运作节点/物理地点？
•这些子系统提供各自的哪些接口，如何衔接？
通过应用架构的构建，我们能够清晰而准确地定位一个商业运行有哪些主要的运作节 点。同时，我们也汇总了每个节点内的主要商业活动。这些信息有助于我们分辨和汇总出 每个商业运作节点中需要完成的系统功能。在实际工作中，我们可以借用如图‘17所示的 模板分析汇总系统功能。
当我们汇总了整个系统内各种需要提供的功能及其所属商业运作节点/物理地点后，我 们还需要系统化地将这些零散堆积在各个节点内的功能分析汇总进不同的子系统内（这是 一个架构决策的很好的例子)。当然，哪些功能应该归分并拢收进哪些子系统内，这需要系 统的分析方法和丰富的实际经验。在实际工作中，我们可以参考使用如图冬18所示的模板。
.png)
.png)
我们可以用一个系统架构基线的实例，来看看实际工作中功能及子系统划分的细节。 图4-19是某公司为了构建某国高速铁路架构基线而构建的一张子系统及功能划分图。
.png)
截至目前，我们己经构建出系统/子系统集群与各个系统功能间的分配关系。但是，还 需要继续规划出各个节点/地理位置之间、子系统与其他子系统的接口关联关系。这样可以 帮助我们逐步细化子系统间的接口及关联关系。在实际工作中可以参考使用如图4-20所示 的模板。
.png)
这时，我们发现还有一个重要的关联关系没有界定出来，即一个节点/地理位置内各个 子系统间的接口及关联，如图4-21所示。
可以看出，上述四个步骤是环环相扣、逐步深入和细化的系统构建过程。只有这样， 我们才能对当前整个系统的功能划分、子系统划分、系统接口、子系统间接口这些系统级 任务进行清晰完整的规划和构建。
“系统/子系统/功能的分布及接口”阶段的工作，有这样一个非常明显的特征：“在建造 一个系统之前会有很多的重要决策需要事先做出，而一旦系统开始进行详细设计建造，这 些决策就很难更改甚至无法更改。显然，这样的决定必定是有关系统构建成敗的最重要决策，必须经过非常慎重的考虑。
.png)
2.系统/子系统间接口汇总
作为一个汇总步骤，“系统/子系统接口”阶段的主要任务是将第一阶段分解出来的各 个子系统间的接口信息进行汇总，从而为系统构建和设计阶段提供一个有关系统接口信息 的纵览。同时，这也是一个系统/子系统接口整理和澄清的过程^这样可以保证汇总的系统 接口完全满足各种要求，例如：保密/安全的要求、接口标准的要求（SOAP over HTTP) 等。我们可以通过如图4-22所示的系统/子系统矩阵的方式进行汇总。
需要说明的是，我们可以在上述矩阵中使用不同的标记来标注子系统间接口的一些属 性，例如：圆圈代表一般接口，方框代表需要安全措施的接口，三角形代表了无接口关系等。
3.节点间/物理位置间/节点内通信网络
作为整个系统架构基线的一部分，我们必然会涉及有关信息交互媒介方面的的规划， 这一般包括整个系统可能利用的通信链路（物理连接，将一个系统链接到另外一个系统)、通信系统（交换机、路由器、通信卫星等），通信路径（为了连接两端的子系统，整个通信 经过的通信链路及相关的通信系统）甚至是通信网络（有多个通信路径的网络)。
.png)
图4-22系统间接口关系汇总图
对于我们的架构基线来讲，需要澄清这样两种通信媒介的规划：首先，我们可以借用 如图4-23所示的模板来规划节点/物理位置间的通信媒介。
.png)
图123节点间通信网络图
在该模板中，黑色线代表了通信链路，方块代表了通信系统（路由器、卫星系统)。通 信链路与通信系统可以组成各种通信路径，从而形成了网络状通信网络系统。同时，与外部系统的通信链接也需要在图中清晰地标记出来。
其次，我们不单单要完成各个节点/物理位置间的通信媒介，还要澄淸每个节点/物驾位 置内的各个子系统间的通信机制。在实际工作中可以使用如图4-24所示的模板。
.png)
只有通过上述这样两种通信网络的规划，才可以保证系统全局范围内节点与节点、节 点内子系统与子系统间的通信媒介得以完整构建和淸晰汇总。
4.商业任务/活动与系统功能间的映射关系
这个阶段的主要任务是将一个商业运行中需要完成的商业任务及其操作活动，与我们 已经界定出来的运行在各个节点上的子系统进行对照映射。这样做，一方面可以汇总和澄 清商业任务/活动与系统功能这两者之间的关系。另一方面，为后续的子系统架构构建提供 参考依据。
为了淸晰地汇总商业任务/活动与系统功能之间的关系，通常我们可以参考如图士25 所示的模板。
.png)
图4-25商业活动与系统功能汇总图
我们可以注意到，模板中的商业任务/活动与系统功能之间的关系使用了不同形状的标 记来表述映射关系。在实际工作中，我们也可以规范使用自定义的形状标记来汇总不同的 映射关系’例如：三角形代表系统架构基线中•己经计划实现该商业活动的功能：方框代 表系统架构基线准备实现部分该商业活动的功能：圆圈代表了历史的其他系统已经实现了 该商业活动的功能，现在只是需要集成等。
在我们使用上述模板时，有两个方面的问题需要引起我们的注意：首先，现阶段该表 中汇总的活动/流程应该与应用架构概念构建的“商业运作活动/流程模型”中分辨出来的活 动/流程一一对应；其次，系统架构基线阶段汇总的活动/流程属于“商业运作活动/流程模 型”中较高层次的那些活动/流程（主要是那些横向流程）。更细的纵向活动/流程会在子系 统架构构建时期与子系统内各个不同的构件进行映射。
5.系统间亊件跟踪模型
到目前为止，我们对子系统的划分、子系统间的接口、子系统间的通信网络、各个子 系统应实现的功能有了非常清晰和完整的构建。但是，我们还需要进一步构建整个系统内 各个子系统间是以怎样动态交互的方式进行信息交换的。与应用架构概念阶段不同的是， 现在我们开始整理的不是运行节点间的交互，而是系统间的交互，如图4-26所示。
.png)
6.系统状态变化模型
作为一个重要的分析和构建手段，运用系统状态变化模型可以严格地界定一个子系统 受到不同的内部或外部事件驱动时所采取的不同功能性动作及相应系统状态的变化。这样 的动态构建手段有着下述重要的意义：
•严格界定了各个子系统相关的事件、时序、状态、动作，为后续的子系统构建阶段 的工作提供了强制架构约束。
•帮助汇总了整个系统范围内各个子系统与状态变化相关的规则及条件约束。
•这种分析及构建手段，本身也是一种系统架构动态特性的有效模拟和校验过程。
在实际工作中，我们可以参考应用架构概念阶段“商业运作状态变化模型”中的工作 模板。不同的是，这时我们针对的是各个子系统而非商业运行节点或商业活动。所以，我 们会对每个子系统进行系统状态变化模型的构建。
7.系统间数据交互矩阵
应用架构概念构建时期，在“商业数据交换矩阵”阶段，我们已经总结了商业运作节 点或商业活动/流程节点间的信息交互。其相应产出的“商业数据交换矩阵”是我们现阶段 组织和汇总全系统范围内各个子系统间数据交换的基础。不过，现在的主要任务是汇总那 些需要各个子系统配合、子系统间自动交互的数据，而不是那些需要人工参与传递的信息 (例如：口头命令)。
为了有效汇总这种系统间的信息交互，我们可以参考如图4-27所示的模板进行组织。
.png)
8.系统物理数据横型
随着系统架构基线的深入确立，到现阶段，我们面临着进一步将应用架构概念中的“商 业数据模型”向系统物理数据模型转化的任务。这种系统物理数据模型就是日后我们进行 系统实施时的物理数据模型。
现在我们已经可以开始将一些数据关系整理进“系统物理数据模型’，中.例如：目前 我们已经淸晰地汇总了子系统间的数据传递，这些数据可以组织进系统物理数据模型中： 各个子系统所要求的功能已与商业功能/商业活动建立了对应关系，而每个商业功_业活 动的数据（例如：输入、数据处理逻辑、输出等）已经在“商业数据模型”进行了初步汇 总，可以帮助我们从IT系统的角度重新组织这些数据关系。
在现阶段，我们还只是在“商业数据模型”的基础上进行整理，那些非系统实现的数 据关系自然不是我们考虑的重点。另外需要说明的是，由于还没有进入子系统的架构工作， 我们当前构建的一些数据模型（包括系统文件存储结构、子系统交互信息的格式等）在子系统架构构建时，还需要进一步的补充、修改和确认。
在实际工作中’我们可以继续沿用应用架构概念中的“商业数据模型”中提供的模板 进行系统物理数据模型的构建。
9.系统质量要求列表
系统架构基线阶段的另外一个任务，就是将针对整个系统范围内的所有技术质童要求 进行分解：将系统要求分解到不同系统集群（运行在各个节点上)，再将质量要求进一步分 解到节点上的每个子系统’然后将子系统的要求分解到最终的系统内构件上。从而在系统 高、中、低各个层面上强制要求后续的子系统架构、构件设计满足整体系统的质童要求。
针对当前阶段’我们需要将合理拆分和界定的技术质量要求落实到每个子系统上。很 明显，这样一个“系统质量要求列表”会要求在后续子系统架构和构件设计阶段进行逐步 完莕和落实。在实际工作中，我们可以参照如图4-28所示的模板对每个子系统的质量要求进行拆分和汇总。
10.系统功能演化
通常，大规模复杂系统在系统架构基线构建时期，需要为整个系统及相关的各个子系 统制定一个系统功能演化的计划，有时我们也将这样的计划称作系统演化路线團（System Evolution Roadmap)。从而在相当长的时间段内明确整个系统的发展和变化，为后续的工作提供初步的规划。
按照系统演化的一般规律，一个系统通常会有两种形式的演化过程：第一种，为了适 应功能的变化、质量的需要（例如增强灵活的可配置能力）、市场的发展、技术的更新等而 进行的功能性的拓展；第二种，将原先的系统功能进一步整合（例如去掉那些为了提高灵 活性的功能)、精简、降低性能要求，从而将系统演化为经济且性价比较较高的系统。
.png)
图4-28系统质量要求汇总图
在现实中，在一个商业系统产品研发型企业内，这样两种系统演化经常是同时存在的。 针对第一种拓展功能的系统演化方式，我们可以参考使用如图4-29所示的模板a
.png)
针对第二种整合功能的系统演化方式，我们可以参考使用如图4-30所示的模板。
.png)
一需要说明的是，我们不光应该利用上述模板对整个系统进行功能路线图的规划工作， 同时，每个子系统也应该制定相应的路线图。这样，才能保证整体路线图可以分解落实到各个子系统的不同功能上〃
11.系统应用技术/产品演化
需要注意，系统目前计划使用的技术/产品、当前流行的技术/产品、未来可能出现的大 量应用技术趋势，对我们整个系统以及各个子系统的架构构建都会有着非常重要的影响。 甚至有些技术或第三方产品对有些系统或子系统架构有着决定性的影响。所以，做系统架 构基线的另外一个任务，就是汇总那些支撑或未来影响我们系统构建的技术/产品，并将其 定位到系统范围内的各个子系统、各个通信网络，甚至是各个功能上
通常，我们会将这些技术或产品因素分解为软件、硬件及通信这样几个大的类型。每 个类型下会分别类聚汇总各自技术领域的详细分类，例如软件就可以分为操作系统、中间 件、商业应用层、用户界面等不同技术视角。对于预测时段，也可以设定合适的时间区间 进行区别（建议参考以6个月为间隔，分为短期、中期及长期）。
如图4-31所示的模板，可以用来在系统全局范围内汇总和预测最高层面的技术/产品 信息。同时，各个子系统也可以利用类似的模板完成演化信息汇总。
.png)
12.系统使用标准及横型汇总
与系统应用的各种技术或产品对架构基线的影响相似，系统架构基线的构建也同样受 制于那些相关的国际、国家、行业标准或模型。这些标准和模型不单单会影响架构基线 的构建，对后续子系统构建、构件设计、编码开发甚至是测试都有着重要的影响和强制约 束力。
在实际工作中，可以参考使用如图4-32所示的模板汇总信息^
.png)
13.系统规则及约束
应用架构概念构建中所汇总的商业意义上的那些强制约束及商业规则，只是我们的一 个工作基础。我们还需要从IT系统这样的视角出发，严格地约束和界定整个系统及系统内 各子系统的执行情况^换句话说，当一个事件发生，或者一个状态发生变化，或者一个条 件得到满足，会要求一个系统、子系统甚至是一个构件必须完成某些特定的动作，而不能 去做其他的动作。
进入系统架构基线阶段，除了前期汇总的这些约束及规则，还需要进行如下三个步骤
的工作，从而将这些商业规则及约束完整地转化为系统规则及约束。
首先，可以借用如图4-33所示的模板，将商业约束及规则映射到系统、系统集群、单 个子系统上。
.png)
其次，系统架构人员需要将这些商业视角的约束及规则转化或分解为系统视角的各种 系统约束及规则语言，例如：If (条件1) and (条件2)满足，Then (执行动作5) and (执行动作6)。
最后，需要把系统架构基线各个阶段中所建立或细化的一些额外的系统级约束和规则， 汇总并映射到各个子系统上
完成了上述13步动作之后，我们已经完成了一个系统的架构基线的构建工作。从这些 步骤来看，其实就是一个逐步分解、逐渐细化的过程。我们已经把一个庞大复杂的系统分 解为不同的系统集群（运行在不同的节点上)，每个集群又分解为不同的子系统，每个子系 统又分配了不同的功能。另外，我们也构建出分解系统之间的通信和交互机制。配合这样 的架构基线，整个系统及各个子系统所涉及的实现技术、所遵循的技术标准、所要求的质 量特性、所必须遵循的约束和规则等都己经非常淸晰明确，而后续的工作就是在这样一个 经过重大决策后稳定下来的基线上进一步展开的
4.4子系统架构友设计
通过上述章节中描述的主要动作，已经在系统全范围内形成了一个重要的架构基线。
子系统架构和设计的工作，就是基于这样一个系统大构架之下、基于架构基线这样的强制 约束背景下展开的。从现在开始，系统总架构师作为主角开始淡出，而各个子系统架构 师开始成为主角。他们现阶段的工作就是继续分解、细化、设计各个子系统（Subsystem), 从而逐步回答那些更为细节的问题，为后续构件（Component)的设计和编码做准备， 例如：
•系统架构基线构建期，划归给该子系统负责实现的功能是否可行？
•整个子系统内，划归实现的功能又可以分解为哪些子功能？
•整个子系统内，应该规划出哪些构件，从而将子功能在不同的构件内集成？
•这些规划的构件及构件内的功能是如何衔接和协作的？
•这些规划的构件及构件内的功能是如何与其他子系统的构件与功能进行接口衔接
和协作的？
很显然，如果没有各个子系统架构师进一步进行工作来回答上述的问题，后续设计人 员就无法进行设计、编码和实施。
其实，我们可以把每个子系统看做是一个个系统，甚至也可以参考系统架构基线的工 作思路和方式进行子系统的架构构建。但是，由于工作的范围、任务的细节程度发生了明 显的变化，我们必须采取相应不同的角度和流程来完成子系统级的工作任务。举例来讲， 建筑行业把选择建筑物的地点、周边环境与建筑物的和谐、建筑物的外观风格、建筑物结 构组成及用途等方面的工作称之为建筑架构；对建筑内各个组成结构承受多大的重力、需 要多少承重梁、需要多少号水泥称之为设计。严格地讲，子系统架构方面的工作是介于“架 构”与“设计”之间的工作•所以在现实工程中，我们会看到有些人把这样的工作称之为 “子系统设计”，而有些人却称之为“子系统架构”。
实际子系统架构构建和设计可以参考下面的流程卡，如表4-4所示。
表4«4子系统架构及设计流程卡
|
目标描述：
遵照系统架构基线的要求.为后续构件设计及编码实施掸供强制性架构及设计约束*为此*要淸晰地构建出：分析及分 解子系统的功能、将子系统切分为适当的构件、定义构件间的接口及交互、规划构件间物理通信结构、设计子系统物理数据 模型、分解和落实子系统及构件的貭量要求。这样一个子系统的架构基线，有效地为后续展开的构件设计工作提供了帮助
|
|
|
负责人员：
子系统架构师
|
|
|
输入：
•修订的产品/项目信息橛览
•修订的商业及系统术语字典
•系统/子系统/功能的分布及接口
•系统/子系统间接口汇总
•节点间/物理位置间/节点内通信网络
• 商业任务/活动与系统功能间的映射关系
•系统间事件用踪模塱
•系统状态变化横型
•系统间数据交互矩阵
•系统物理数据横型
•系统貭*要求列表
•系统功能演化
•系统应用技术/产品演化
•系统使用标准及横a汇总
•系统规則及约束
(注释：本流程的输入倍息.只是“系统架构基线”中与该子 系统相关的那些倌息，其他子系统信息不作为该子系统流程 的输入倌息，）
|
输入事件：
系统架构基线构建结束，
收到子系统架构构建请求
|
|
•修订和堆补商业及系统术语宇典，确保子系统架构与构件设计人员对所负责的子系统的描述有统一的认知
•将分配到该子系统的功能进行分析和拆分：将子系统构建为不同的构件，并规划构件间的内部接口及构件与外部其他 子系统的接口：将拆解的功能分配到子系统内各个构件上，并建立构件间功能之间及构件内功能之间的接口及关联
• 为了方便检索和浏览，汇总子系统范围内各构件间的接口信息
•针对整个系统架构基线对该子系统的功能规划、接口规划、通信网络规划等进行可行性研究及校验，并提出建议
•规划子系统范围内各个构件间进行通信的链路、路径、网络等信息传输媒介
•将“系统架构基线"中分配到该子系统的商业任务能中的底层商业活动与系统分解出来的构件中的各个功能进行 对应，从而使计划的子系统/构件的功能满足商业业务活动的要求
•分析子系统内各个构件在运行期间动态协作时需要交互的信息
•构建和模拟各个构件在投入商业运营时期的动态特性：规划子系统内部构件状态变化过程、触发事件及约束条件
•详细汇总各构件间信息传递的过程、传递的信息内容及其他辅助信息要求*
•基于“系统架构基线”中有关该子系统的物理数据模型，细化子系统及构件的物理数据模
•将“系统架构基线”中有关该子系统的整体质量要求分解、细化、量化并映射到子系统上的各个构件及相应功能上•
•将“系统架构基线”阶段有关该子系统的商业规则及约束映射到各个构件.并壜关该子系统及构件的各种规则和约束。
|
|
|
•修订的商业及系统术语字典
•子系统/ft件/功能的分布及接口
•子系统内构件间接口汇总
•子系统/构件通信网络
•商业任务/活动与构件及其功能间的映射关系
•子系统各构件间事件跟踪模型
•子系统内各构件状态变化模型
•子系统内构件间数据交互矩阵
•子系统及构件物理数据模型
•子系统及构件质置要求列表
•子系统规则及约束
|
|
从工作流程上来看，子系统架构和设计的工作顺序与系统架构基线构建的思路非常相 似，完成的步骤也相仿。但是，侧重点放在了子系统内部的各个构件及接口关系上。我们 就以“子系统架构和设计”工作的第一步“子系统/构件/功能的分布及接口”为例，来看看具体的工作步骤。
“子系统/构件/功能的分布及接口”阶段工作的第一步，就是要将架构基线分配给该子 系统的每一个功能进一步分解为子功能（有些子功能属于商业功能，但是有些属于系统级 功能。例如“货币转换及汇率计算”是一个商业功能，但是“插件安装/注册功能”就是一 个丨T系统功能)，从而设计成为如图4-34所示的功能树
.png)
为了帮助子系统架构师将一个系统功能拆分为合理的子功能，并及时校验拆分的有效 性，我们可以借助时序图来构建各个功能/子功能间的协同和信息传递。
接下来，一个需要子系统架构师考虑并设计的重点，就是整个子系统由哪些子系统构 件组成，这些构件之间的接口关系怎样，以及部分构件与外部其他子系统的接口关系怎样。
为了清晰地表述构件、构件间接口、构件的外部接口，我们可以参考下述一个实例作为我们的模板。该模板中的实例，描述了某公司参加欧盟的全欧公路网自动计费收费系统 时，所负责的子系统“电子公路收费后端ETBO (Electronic Toll Charging Back Office)" 的构件及接口图。从图4-35中，我们可以清晰地看到各个规划设计出的构件、各个构件相 互接口以及某些构件与外部子系统（例如车载计费单元子系统OBU，即〇n-Board Unit) 的接口关系。这时我们发现，子系统架构师现阶段的工作，已经把“系统架构基线”中界 定的粗线条子系统间的接口关系进一步分解细化到了子系统内的各个构件上。
.png)
但是，只是停留在子系统内构件间的接口关系，依然不能满足后续构件设计人员的设 计工作，还需要子系统架构师进一步进行分解。即，将汇总分解的子系统功能/子功能分配 到各个构件当中，并且给出各个功能/子功能间的接口关系。只有这样，才能在真正意义上 规范和约束构件设计人员的工作。
在实际工作中，我们可以参考如图4-36所示的模板。
.png)
自然，每一个构件内的各个功能间的接口关系也需要界定出来，从而使构件设计人员 遵循子系统架构师所规划的接口来进行构件设计。使用的模板请参照“系统架构基线”中 节点内子系统间关系的模板，只需要将运行节点改为构件，将节点内的子系统改为构件即可，
“子系统/构件/功能分布及接口”阶段的工作，同样也有很多决策需要事先做出，通常 我们称之为设计决策（Design Decision)。这样的设计决策’需要构件设计人员及编码人 员进行有效性的校验<«但是，一旦设计决策确定后，后续进行的实施工作如果在没有合理罝疑的前提下，都箝要遵循这些设计决策。
“子系统架构和设计”阶段的其他工作，与“系统架构基线”阶段基本一致，此处就不 再赘述了，只不过是各项后续任务的重点都转变为以子系统及构件为主了，例如：
•设计子系统内构件间通信链路、通信路径、通信网络。
•将商业任务/活动与子系统内构件功能进行映射。
•子系统内各个构件间亊件跟踪*
•子系统内各构件状态转换模型。
•子系统构件间数据交互矩阵。
•子系统及构件物理数据模甩。
•子系统及构件的质量要求列表。
•对应并且完善系统规则及约束。
4.5构件与单元设计
进入构件设计阶段，整个系统实施己经进入到了通常我们非常熟悉的详细设计（Detail Design)阶段。这时虽然已经不需要复杂的设计工作流程来指导工作，但是从这个阶段开 始，需要进行功能设计及接口设计的工作*
我们可以参考使用下述流程卡来进行构件设计工作，如表+5所示。
|
目标描述：
子系统架构及设计阶段的工作，己经严格界定了构件设计工作必须遵循的设计约束.在这样的强制性设计规則下，要 求淸晰地设计出一个构件的内部结构、底层商业及系统功能的实现机制、各个构件内的结构单元的接口或调用关系。这样 一个构件的详细设计，最终将有力地保陣后续编码工作能够按照既定的要求进行„
|
|
|
负责人员：
•构件设计人员
|
参与人员：
•子系统架构师
•子系统测试人员
•子系统集成测试人员
•单元测试人员
•高级构件编码人员
|
|
输入：
•修订的商业及系统术语字典
•子系统/构件/功能的分布及接口
子系统/构件间接口汇总
•子系统/构件通信网络
•商业任务/活动与构件及其功能间的映射关系
子系统各构件间亊件跟踪模型
•子系统内各构件状态变化模型
•子系统内构件间数据交互矩阵
•子系统及构件物理数据換型
•子系统及构件质釐要求列表
•子系统规则及约束
(注释：本流程的输入信息，
只是“子系统架构及设计”中与
该构件相关的那些信息，
其他构件信息不作为该子系统流程的输入信息）
|
输入事件：
子系统架构及设计结束，收到构件设计请求
|
|
活动描述:
•对子系统架构与设计阶段中针对该构件及功能的界定进行细化和校验。
•将子系统架构与设计阶段分配到该构件的商业及系统功能进一步分解为更为详细的底层商业及系统功能
•设计构成该构件的各个构件结构单元，并将分解的商业及系统功能划分到这些构件结构单元上
•设计构件结构单元实现各个商业及系统功能的机制.
•根据商业及系统功能的实现机制，最终限定构件内各个构件结构单元之间的接口或调用关系，并界定构件结构单元与外 部其他构件之间的接U或调用关系
•进行必要的构件重构及优化构件设计，
•为后续编码工作估计实现工作量及技术要求。
|
|
|
输出：
•构件内各构件结构单元及功能的分布、关系及实现机制的设计
•底层商业任务/活动与构件结构单元内功能间的映射关系 •构件内各构件结构单元间事件跟踪模型
•构件物理数据设计
|
|
4.6架构/设计流程中的兔色和职责
一个商业业务流程一般是由主线流程、分支流程、流程中的任务、流程中的角色、流 程控制检查点等组成。作为系统架构与流程设计的重要组成部分，我们还需要对流程中重 要的角色和职责加以界定。
通常，—个项目或产品的软件架构和设计流程中所涉及的主要角色是以图冬37的方式 进行协作和沟通的。
从图4-37中我们可以清晰地辨别出，系统架构师（System Architect)或者架构组 (Architecture Team)是处于协作和沟通的核心位置。他们一方面需要就软件系统与上游各 个stakeholders进行诠释、说服、平衡等工作，以实现上游的要求；同时还需要构建出整 个系统的商业架构概念、应用架构概念以及系统架构基线，并将具体的子系统架构、构件 和单元设计分解给子系统架构师（Subsystem Architect)、构件设计开发人员（例如构件项 目组长PLC，即Project Leader Component、幵发人员Developers等）等去设计.同时， 架构师或架构组还需要与下游的各个产品设计与开发角色进行解释、验证等工作。
结合软件架构与设计流程，我们可用如图4-38所示更加直观的方式来表述各个主要角 色在软件架构和设计流程中担负的职责。
其中 E(xecute)、R(esponsible)、C(ontribute)、l(nformed), A(ccept>的含义描述如表 4-6所示。
.png)
.png)
.png)
