软件体系结构-第3章(设计方法)
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
每一个客户的软件都有自身的特点，如何才能够设计
出符合客户利益的架构？ 软件中往往都充斥着众多的问题，在一开始就把所有 的问题都想清楚往往很难做到，但是如果不解决问题， 风险又居高不下
架构设计-架构源自需求（举例）
例1：城市中自来水管的架设是一项非常的复杂的 工程。为了需要满足每家每户的需要，自来水管 组成了一个庞大的网络。在这样一个复杂的网络 中，如何完成铺设的任务呢。一般的做法是，先 找出问题的根源，也就是水的源头。从水源铺设 一条管道通至城市，然后根据城市的区域划分， 设计出主管道，剩下的就是使用的问题了，每家 每户的管道最终都是连到主管道上的。因此，虽 然自来水网络庞大复杂。但是真正的主管道的非 常简单的。
经典的三层理论将应用划分为三个层次： 表示层（Presentation Layer），用于处理人机 交互。目前最主流的两种表示层是Windows格 式和WebBrowser格式。它主要的责任是处理 用户请求，例如鼠标点击、输入、HTTP请求 等。 领域逻辑层（Domain Logic Layer），模拟了 企业中的实际活动，也可以认为是企业活动的 模型。 数据层（Data source Layer），处理数据库、 消息系统、事务系统
每个子设计团队可以从别人那里吸取设计经验
总体架构规划的层次-子模块级、或是子 问题级（续）
子模块（子问题）间的耦合问题 ： 各个子模块间的耦合程度相对较小 子问题间的耦合程度就比较大 具体的做法： 为子模块（子问题）制定出合同接口（Contact Interface） 系统中的一些全局性的子问题最好是提到全局愿景中 考虑
软件需求各组成部分之间的关系
需求层次划分
业务级需求：包含客户要达到的业务目标、
预期投资、工期要求，以及要符合哪些标准、 对哪些遗留系统进行整合等约束条件 用户级需求：用户使用系统来辅助完成哪些 工作？对质量有何要求？用户群及所处的使 用环境方面有何特殊要求？ 开发级需求：开发人员需要实现什么？开发 期间、维护期间有何质量考虑？开发团队的 哪些情况反过来影响架构？
需要注意的问题
初步设计的目标是发现职责，初步设计无需
展开架构设计细节
高层分割பைடு நூலகம்实践法则
切系统为系统
切系统为子系统
架构设计-分层模式
分而治之的思想是计算机领域非常重要的思想
分层的优势 ： 上层的逻辑不需要了解所有的底层逻辑，它只需要了 解和它邻接的那一层的细节 不同层间的耦合度明显降低。通过严格的区分层次， 大大降低了层间的耦合度。 某一层次的下级层可以有不同的实现 同一个层次可以支持不同的上级层
架构设计阶段划分
架构设计前准备阶段（预备架构阶段）
概念架构设计阶段 精华架构设计阶段
预备架构阶段
最大误区：架构师是技术人员不必懂需求
实践要点：摒弃“需求列表”方式，建立二
维需求观。 思维工具：需求矩阵
概念架构
最大误区：概念架构=理想设计
实践要点：重大需求塑造概念架构 思维工具：鲁棒图、目标-场景-决策等
理解需求
建立需求大局观 确定架构设计方向
在预备架构总体工作内容
在架构设计之初，就全盘考虑架构设计要重
点支持的关键质量目标 在第一时间就判断这些“关键质量”之间有 没有冲突关系，并制定权衡取舍策略
预备架构阶段指导原则
需求结构化
分析约束影响 确定关键质量
确定关键功能
细化架构
最大误区：架构=模块+接口
实践要点：贴近实践的五视图法 思维工具：包图、包-接口图、灰盒包图、序
列图、目标-场景-决策表等
什么对架构设计成败非常关键？
功能需求、质量属性及约束共同决定了架构，
对这三类需求的把握是否到位、设计决策是 否对路，是架构设计成败的关键所在！
架构设计前准备阶段主要工作
总体架构的形成过程-使用架构模式
初步设计
初步设计的目标是发现职责，为高层切分奠
定基础 初步设计不是必须的，但当待设计系统对架 构师而言并无太多直接经验时，则强烈建议 进行初步设计 基于关键功能，借助鲁棒图进行初步设计
功能影响架构的基本原理：职责协作链
初步设计方法-鲁棒图分析
基于关键功能，进行初步设计
各阶段设计的任务
逻辑设计阶段 始于逻辑设计阶段。此阶段的任务是设计一个逻 辑体系结构，它应该体现能够满足技术要求阶段 所确定的使用用例和场景。
部署设计阶段 任务是创建一个反映部署方案与物理环境的映射 关系的部署体系结构。物理环境是指部署的网络 框架结构，它包括计算节点、每个节点的硬件要 求、防火墙以及网络上的其他设备。
最快的全库搜索----便捷 频率极高的新货上架----便捷 灵活的打折设置----实惠
概念架构阶段
概念架构设计的步骤 初步设计，基于关键功能，借助鲁棒图进行发现 职责为目的的初步设计 高层分割：对系统进行高层切分 考虑非功能需求
总体架构规划
总体架构应该能够提供软件全局视图，包括所有
各阶段设计的任务
实现阶段 在测试环境中创建和部署试验性和/或原型部署 设计和运行功能性测试来衡量与系统要求的符合 度 设计和运行负载测试来衡量峰值负载下的性能 创建生产部署，可能需要分阶段部署到生产中
架构设计-架构源自需求
为什么要从需求开始？
IT界的技术层出不穷，面对着如此之多的技术、平台、 框架、函数库，我们如何选择一组适合软件的技术？
为软件全局设置的架构愿景可以以原则、或是模
式名的方式体现，并用自然语言或伪代码描述。 需要强调的是总体架构规划的制定是根据不同的 应用环境而变化的
总体架构规划的层次-软件全局（续）
举例：在JAVA环境中
客户端采用前端浏览器界面。
业务逻辑采用servlet，配合JSP编写。 浏览器到服务器的数据采用集中处理，具体的方法是
架构设计分层模式
分层模式使用原则
案例
架构设计的过程模式
体系结构和循环
用例模型
设计模型
实现模型
分布模型
测试模型
内容
体系结构设计各阶段
实现架构 部署架构 逻辑架构 用例模型
业务架构
各阶段设计的任务
业务分析阶段的任务： 确定项目的业务目标和阐述实现该目标所必须满 足的业务要求。阐述业务要求时，应将可能会对 业务目标的实现能力产生影响的所有业务约束考 虑在内。在后面的技术要求阶段会用到该文档， 并会将其作为以后衡量部署设计是否成功的标准。 技术要求阶段的任务 以业务分析阶段中形成的业务要求为起点，任务 是将这些要求转化为可用来设计部署体系结构的 技术规范。
总体架构规划的层次-代码级的规划
严格的说这一层次的规划已经不是真正的愿景，
而是具体设计了 这一个层次的规划一般可以使用类图、接口来表 示。但在类图中，不需要标记出具体的属性、操 作，只需要规定出类的职责以及类之间的相互关 系就可以了 比较重要的工作在于问题如何分解和如何归并 分解主要是从两个维度来考虑
的重要部分，定义了各个部分的责任和之间的关 系，而且还定义了软件设计需要满足的原则。 总体架构的设计，应该是满足源自需求模式。 总体架构应该要能够满足架构的其它各种特点， 例如简单、可扩展性、抽象性 总体架构最大的用处就是保证设计的一致性和有 效性。
总体架构规划的层次-软件全局
软件全局的架构设计是我们设计中所最关心的 。
不同需求影响架构的原理不同
需求种类
功能需求：体现各级直接目标要求
质量属性：运行期质量 + 开发期质量 约束需求：业务环境质量 + 使用环境因素 +
构建环境因素 + 技术环境因素
需求结构化的原因
通过需求层次-需求方面矩阵，高屋建瓴地把
握复杂系统的需求大局：
将复杂的需求集合梳理得井井有条，可以全面理
总体架构规划的层次-子模块级、或是子 问题级
这里的架构规划制定本质上和全局的规划制定差
不多，但是要注意一点，不能够和全局规划相违 背。 在操作上，全局规划是设计团队共同制定出来的， 而子模块级的架构规划就可以分给设计子团队来 负责，而其审核则还是要设计团队的共同参与 好处：
确保各个子模块（子问题）间不至于相互冲突或出现 空白地带
架构设计-架构源自需求（续）
需求的划分
非功能需求：定义了一些性能、效率上的一些约束、 规则，决定技术架构。
功能需求：定义了软件能够做些什么？决定业务架构。
变化案例：变化案例是对未来可能发生的变化的一个 估计，决定架构的范围。
架构设计-架构源自需求（举例）
举例：我们打算开发一个字处理软件，功能需求 可以简单概括为格式化用户输入的文字，非功能 需求可能是格式化大小为1000K的一段文字的处 理速度不能低于10S，变化案例可能是推出多种 语言版本。那么我们在设计业务架构的时候，我 们会集中于如何表示文字、图象、媒体等要素， 我们该需要有另外的技术架构来处理速度问题， 比如缓冲技术，对于变化案例，我们也要考虑相 应的架构，比如把字体独立于程序包的设计。
问题大小维
时间长短维
总体架构的形成过程
总体架构规划的形成的源头是需求，需要特别指
出的是，这里的需求主要是那些针对系统基本面 的需求。 总体架构规划的主要目的就是为了能够在开发团 队中传播设计思路，因此，总体架构规划包括基 本的设计思路和基本的设计原则 总体架构规划可能会有多种的视角
软件体系结构
第三章 软件体系设计方法
本章要点
架构设计概述 架构设计过程 总体架构规划
架构设计分层模式
分层模式使用原则
案例
体系结构设计的目标
重用：为了避免重复劳动，为了降低成本，希望
能够重用之前的代码、之前的设计。 透明：有些时候，为了提高效率，把实现的细节 隐藏起来，仅把客户需求的接口呈现给客户。 扩展：对扩展的渴求源于需求的易变。 简明：一个复杂的架构不论是测试还是维护都是 困难的。 高效：不论是什么系统，都希望架构是高效的 安全：是架构的一个很重要的方面。
分析约束影响（推导法则）
分析约束影响（续）
分析约束影响（续）
分析约束影响（查漏法则）
确定关键质量的原则
分类合适 + 必要扩充
考虑多方涉众 检查性思维
识别矛盾 + 划定优先级
严格程度符合领域与规模特点
质量属性关系矩阵
确定关键功能的规则
核心功能 识别方法：业务层的接口要反映这些功能
架构设计-分层模式（续）
在企业应用中，有两个非常重要的概念：业务逻
辑和持久性 企业应用是围绕着业务逻辑进行开展的 ，从业 务逻辑的底层实现来看，业务逻辑其实是对业务 实体进行组织的过程 企业应用中大部分的数据都是需要可持久化的。 因此，基础组织支持持久性就显得非常的重要
架构设计-分层模式（续）
在业务逻辑和前端浏览器之间采用Front Control模 式，接受前端浏览器传送过来的数据，并指派给相应 的业务逻辑处理。 数据的合法性检验分为两个部分：
和业务逻辑无关的基本合法性验证在前端使用Java Script 处理。 和业务逻辑相关的合法性验证在业务逻辑层处理，可以使 用一个集中的servlet专门处理错误情况。
解需求的各个层次、各个方面 为分析不同需求之间联系，做出权衡折衷的依据 识别遗漏需求、发现延伸需求奠定基础
举例：大型B2C网站
象Amazon这样大型的B2C网站，架构的起步
阶段应如何规划呢？ 方法
需求结构化
分析约束影响 确定关键质量 确定关键功能
先梳理业务需求
再梳理重点用户需求
必做功能 识别方法：在用户愿景文档中的主要特征 高风险功能 独特功能
举例：确定关键质量与关键功能
确定关键质量
确定关键质量与关键功能（续）
确定必做功能
Amazon的特点在于它的专业、便捷、实惠，
最终体现这些特点的功能就是必做功能：
评价功能----专业
多角度关联信息----专业
架构设计的复杂性
架构设计是一种权衡
一个问题总是有多种的解决方案。而我们要确定 唯一的架构设计的解决方案，就意味着我们要在 不同的矛盾体之间做出一个权衡。 在设计的过程中总可以看到很多的矛盾体：
开放和整合
一致性和特殊化
稳定性和延展性
体系结构设计方法
架构设计概述 架构设计过程 总体架构规划
出符合客户利益的架构？ 软件中往往都充斥着众多的问题，在一开始就把所有 的问题都想清楚往往很难做到，但是如果不解决问题， 风险又居高不下
架构设计-架构源自需求（举例）
例1：城市中自来水管的架设是一项非常的复杂的 工程。为了需要满足每家每户的需要，自来水管 组成了一个庞大的网络。在这样一个复杂的网络 中，如何完成铺设的任务呢。一般的做法是，先 找出问题的根源，也就是水的源头。从水源铺设 一条管道通至城市，然后根据城市的区域划分， 设计出主管道，剩下的就是使用的问题了，每家 每户的管道最终都是连到主管道上的。因此，虽 然自来水网络庞大复杂。但是真正的主管道的非 常简单的。
经典的三层理论将应用划分为三个层次： 表示层（Presentation Layer），用于处理人机 交互。目前最主流的两种表示层是Windows格 式和WebBrowser格式。它主要的责任是处理 用户请求，例如鼠标点击、输入、HTTP请求 等。 领域逻辑层（Domain Logic Layer），模拟了 企业中的实际活动，也可以认为是企业活动的 模型。 数据层（Data source Layer），处理数据库、 消息系统、事务系统
每个子设计团队可以从别人那里吸取设计经验
总体架构规划的层次-子模块级、或是子 问题级（续）
子模块（子问题）间的耦合问题 ： 各个子模块间的耦合程度相对较小 子问题间的耦合程度就比较大 具体的做法： 为子模块（子问题）制定出合同接口（Contact Interface） 系统中的一些全局性的子问题最好是提到全局愿景中 考虑
软件需求各组成部分之间的关系
需求层次划分
业务级需求：包含客户要达到的业务目标、
预期投资、工期要求，以及要符合哪些标准、 对哪些遗留系统进行整合等约束条件 用户级需求：用户使用系统来辅助完成哪些 工作？对质量有何要求？用户群及所处的使 用环境方面有何特殊要求？ 开发级需求：开发人员需要实现什么？开发 期间、维护期间有何质量考虑？开发团队的 哪些情况反过来影响架构？
需要注意的问题
初步设计的目标是发现职责，初步设计无需
展开架构设计细节
高层分割பைடு நூலகம்实践法则
切系统为系统
切系统为子系统
架构设计-分层模式
分而治之的思想是计算机领域非常重要的思想
分层的优势 ： 上层的逻辑不需要了解所有的底层逻辑，它只需要了 解和它邻接的那一层的细节 不同层间的耦合度明显降低。通过严格的区分层次， 大大降低了层间的耦合度。 某一层次的下级层可以有不同的实现 同一个层次可以支持不同的上级层
架构设计阶段划分
架构设计前准备阶段（预备架构阶段）
概念架构设计阶段 精华架构设计阶段
预备架构阶段
最大误区：架构师是技术人员不必懂需求
实践要点：摒弃“需求列表”方式，建立二
维需求观。 思维工具：需求矩阵
概念架构
最大误区：概念架构=理想设计
实践要点：重大需求塑造概念架构 思维工具：鲁棒图、目标-场景-决策等
理解需求
建立需求大局观 确定架构设计方向
在预备架构总体工作内容
在架构设计之初，就全盘考虑架构设计要重
点支持的关键质量目标 在第一时间就判断这些“关键质量”之间有 没有冲突关系，并制定权衡取舍策略
预备架构阶段指导原则
需求结构化
分析约束影响 确定关键质量
确定关键功能
细化架构
最大误区：架构=模块+接口
实践要点：贴近实践的五视图法 思维工具：包图、包-接口图、灰盒包图、序
列图、目标-场景-决策表等
什么对架构设计成败非常关键？
功能需求、质量属性及约束共同决定了架构，
对这三类需求的把握是否到位、设计决策是 否对路，是架构设计成败的关键所在！
架构设计前准备阶段主要工作
总体架构的形成过程-使用架构模式
初步设计
初步设计的目标是发现职责，为高层切分奠
定基础 初步设计不是必须的，但当待设计系统对架 构师而言并无太多直接经验时，则强烈建议 进行初步设计 基于关键功能，借助鲁棒图进行初步设计
功能影响架构的基本原理：职责协作链
初步设计方法-鲁棒图分析
基于关键功能，进行初步设计
各阶段设计的任务
逻辑设计阶段 始于逻辑设计阶段。此阶段的任务是设计一个逻 辑体系结构，它应该体现能够满足技术要求阶段 所确定的使用用例和场景。
部署设计阶段 任务是创建一个反映部署方案与物理环境的映射 关系的部署体系结构。物理环境是指部署的网络 框架结构，它包括计算节点、每个节点的硬件要 求、防火墙以及网络上的其他设备。
最快的全库搜索----便捷 频率极高的新货上架----便捷 灵活的打折设置----实惠
概念架构阶段
概念架构设计的步骤 初步设计，基于关键功能，借助鲁棒图进行发现 职责为目的的初步设计 高层分割：对系统进行高层切分 考虑非功能需求
总体架构规划
总体架构应该能够提供软件全局视图，包括所有
各阶段设计的任务
实现阶段 在测试环境中创建和部署试验性和/或原型部署 设计和运行功能性测试来衡量与系统要求的符合 度 设计和运行负载测试来衡量峰值负载下的性能 创建生产部署，可能需要分阶段部署到生产中
架构设计-架构源自需求
为什么要从需求开始？
IT界的技术层出不穷，面对着如此之多的技术、平台、 框架、函数库，我们如何选择一组适合软件的技术？
为软件全局设置的架构愿景可以以原则、或是模
式名的方式体现，并用自然语言或伪代码描述。 需要强调的是总体架构规划的制定是根据不同的 应用环境而变化的
总体架构规划的层次-软件全局（续）
举例：在JAVA环境中
客户端采用前端浏览器界面。
业务逻辑采用servlet，配合JSP编写。 浏览器到服务器的数据采用集中处理，具体的方法是
架构设计分层模式
分层模式使用原则
案例
架构设计的过程模式
体系结构和循环
用例模型
设计模型
实现模型
分布模型
测试模型
内容
体系结构设计各阶段
实现架构 部署架构 逻辑架构 用例模型
业务架构
各阶段设计的任务
业务分析阶段的任务： 确定项目的业务目标和阐述实现该目标所必须满 足的业务要求。阐述业务要求时，应将可能会对 业务目标的实现能力产生影响的所有业务约束考 虑在内。在后面的技术要求阶段会用到该文档， 并会将其作为以后衡量部署设计是否成功的标准。 技术要求阶段的任务 以业务分析阶段中形成的业务要求为起点，任务 是将这些要求转化为可用来设计部署体系结构的 技术规范。
总体架构规划的层次-代码级的规划
严格的说这一层次的规划已经不是真正的愿景，
而是具体设计了 这一个层次的规划一般可以使用类图、接口来表 示。但在类图中，不需要标记出具体的属性、操 作，只需要规定出类的职责以及类之间的相互关 系就可以了 比较重要的工作在于问题如何分解和如何归并 分解主要是从两个维度来考虑
的重要部分，定义了各个部分的责任和之间的关 系，而且还定义了软件设计需要满足的原则。 总体架构的设计，应该是满足源自需求模式。 总体架构应该要能够满足架构的其它各种特点， 例如简单、可扩展性、抽象性 总体架构最大的用处就是保证设计的一致性和有 效性。
总体架构规划的层次-软件全局
软件全局的架构设计是我们设计中所最关心的 。
不同需求影响架构的原理不同
需求种类
功能需求：体现各级直接目标要求
质量属性：运行期质量 + 开发期质量 约束需求：业务环境质量 + 使用环境因素 +
构建环境因素 + 技术环境因素
需求结构化的原因
通过需求层次-需求方面矩阵，高屋建瓴地把
握复杂系统的需求大局：
将复杂的需求集合梳理得井井有条，可以全面理
总体架构规划的层次-子模块级、或是子 问题级
这里的架构规划制定本质上和全局的规划制定差
不多，但是要注意一点，不能够和全局规划相违 背。 在操作上，全局规划是设计团队共同制定出来的， 而子模块级的架构规划就可以分给设计子团队来 负责，而其审核则还是要设计团队的共同参与 好处：
确保各个子模块（子问题）间不至于相互冲突或出现 空白地带
架构设计-架构源自需求（续）
需求的划分
非功能需求：定义了一些性能、效率上的一些约束、 规则，决定技术架构。
功能需求：定义了软件能够做些什么？决定业务架构。
变化案例：变化案例是对未来可能发生的变化的一个 估计，决定架构的范围。
架构设计-架构源自需求（举例）
举例：我们打算开发一个字处理软件，功能需求 可以简单概括为格式化用户输入的文字，非功能 需求可能是格式化大小为1000K的一段文字的处 理速度不能低于10S，变化案例可能是推出多种 语言版本。那么我们在设计业务架构的时候，我 们会集中于如何表示文字、图象、媒体等要素， 我们该需要有另外的技术架构来处理速度问题， 比如缓冲技术，对于变化案例，我们也要考虑相 应的架构，比如把字体独立于程序包的设计。
问题大小维
时间长短维
总体架构的形成过程
总体架构规划的形成的源头是需求，需要特别指
出的是，这里的需求主要是那些针对系统基本面 的需求。 总体架构规划的主要目的就是为了能够在开发团 队中传播设计思路，因此，总体架构规划包括基 本的设计思路和基本的设计原则 总体架构规划可能会有多种的视角
软件体系结构
第三章 软件体系设计方法
本章要点
架构设计概述 架构设计过程 总体架构规划
架构设计分层模式
分层模式使用原则
案例
体系结构设计的目标
重用：为了避免重复劳动，为了降低成本，希望
能够重用之前的代码、之前的设计。 透明：有些时候，为了提高效率，把实现的细节 隐藏起来，仅把客户需求的接口呈现给客户。 扩展：对扩展的渴求源于需求的易变。 简明：一个复杂的架构不论是测试还是维护都是 困难的。 高效：不论是什么系统，都希望架构是高效的 安全：是架构的一个很重要的方面。
分析约束影响（推导法则）
分析约束影响（续）
分析约束影响（续）
分析约束影响（查漏法则）
确定关键质量的原则
分类合适 + 必要扩充
考虑多方涉众 检查性思维
识别矛盾 + 划定优先级
严格程度符合领域与规模特点
质量属性关系矩阵
确定关键功能的规则
核心功能 识别方法：业务层的接口要反映这些功能
架构设计-分层模式（续）
在企业应用中，有两个非常重要的概念：业务逻
辑和持久性 企业应用是围绕着业务逻辑进行开展的 ，从业 务逻辑的底层实现来看，业务逻辑其实是对业务 实体进行组织的过程 企业应用中大部分的数据都是需要可持久化的。 因此，基础组织支持持久性就显得非常的重要
架构设计-分层模式（续）
在业务逻辑和前端浏览器之间采用Front Control模 式，接受前端浏览器传送过来的数据，并指派给相应 的业务逻辑处理。 数据的合法性检验分为两个部分：
和业务逻辑无关的基本合法性验证在前端使用Java Script 处理。 和业务逻辑相关的合法性验证在业务逻辑层处理，可以使 用一个集中的servlet专门处理错误情况。
解需求的各个层次、各个方面 为分析不同需求之间联系，做出权衡折衷的依据 识别遗漏需求、发现延伸需求奠定基础
举例：大型B2C网站
象Amazon这样大型的B2C网站，架构的起步
阶段应如何规划呢？ 方法
需求结构化
分析约束影响 确定关键质量 确定关键功能
先梳理业务需求
再梳理重点用户需求
必做功能 识别方法：在用户愿景文档中的主要特征 高风险功能 独特功能
举例：确定关键质量与关键功能
确定关键质量
确定关键质量与关键功能（续）
确定必做功能
Amazon的特点在于它的专业、便捷、实惠，
最终体现这些特点的功能就是必做功能：
评价功能----专业
多角度关联信息----专业
架构设计的复杂性
架构设计是一种权衡
一个问题总是有多种的解决方案。而我们要确定 唯一的架构设计的解决方案，就意味着我们要在 不同的矛盾体之间做出一个权衡。 在设计的过程中总可以看到很多的矛盾体：
开放和整合
一致性和特殊化
稳定性和延展性
体系结构设计方法
架构设计概述 架构设计过程 总体架构规划