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