第十讲 软件架构设计PPT课件

对于这些在架构方面具有重要影响的因素，需求分析 可供选择的办法并创建解决这些影响的解决方案。这 就是架构决策。
7
架构分析
软件系统的架构将系统描述为计算组件及组件之间的 交互
”组件“可以指子系统、框架（Framework）、模块、 类等不同程度的软件单元，它们可以担负不同的计算 职责。
8
软件架构的要素：组件及组件之 间的交互
P32 图2-17
23
架构设计的5视图法
好的方法如路标，对实践者有启发和指引作用。 软件架构师的工作：
要满足性能、持续可用性等方面的需求，架构师必须深入研究软件 系统运行期间的情况、制定相应的设计决策，这些需求被称为软件 的“运行期质量属性”；
而要满足可扩展性、可重用性等方面的需求，则要求架构师深入研 究软件系统开发期间的情况，制定相应的设计决策，这些需求被称 为软件的“开发期质量属性”；
系统” 类、模块、子系统、系统、集成系统，都是软件单元的具体形态，只
不过粒度不同罢了
14
P21 图2-7
15
P22 图2-8
16
框架是软件，架构不是软件 框架是一种特殊的软件，它并不能提供完整无缺的解
决方案，而是为你构建解决方案提供良好的基础。框 架是半成品。典型地，框架是系统或子系统的半成品 ；框架中的服务可以被最终应用系统直接调用，而框 架中的扩展点是供应用开发人员定制的“可变化点” 。 P24 图2-9
运行架构：运行架构关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等 问题。运行架构和开发架构的关系：开发架构一般偏重程序包在编译使其的静态依赖关系， 而这些程序运行起来之后会表现为对象、线程、进程，运行架构比较关注的是这些运行时单 元的交互问题
第十讲 软件架构设计
1
标题添加
点击此处输入相 关文本内容
前言
点击此处输入 相关文本内容
标题添加
点击此处输入相 关文本内容
点击此处输入 相关文本内容
2
目标
管窥架构设计现状 架构设计方法 如何确定架构驱动因素 非功能需求设计方法论
3
通用过程太笼统
4
架构分析
架构分析可以被视为需求分析的规格化，其关注强烈 影响”架构“的需求。例如，为系统识别高度安全方 面的需求。
架构分析的本质是要识别影响架构的因素，理解这些 因素的可变性和优先级，并且解决这些问题
为什么架构分析如此重要？因为它有助于：
降低在系统设计中丢失某些重要因素的风险。 避免在低优先级的问题上花费过多的精力 有助于产品与业务目标的一致
5
架构分析
架构分析（architecture analysis）是在功能性需求 （例如处理销售等）的语境中，识别和处理系统非功 能性需求（例如安全需求等）的活动。其包括识别变 化点和最具有可能性的进化点。
例：
可靠性和容错需求如何影响设计？ 采购子构建的许可费用如何影响收益率？ 可适应性和可配置性需求如何影响设计？ 商标名称的选择如何影响架构？
6
架构分析
识别和分析对架构有影响的非功能性需求。虽然与功 能性需求也有关系（特别是可变性方面），但是应该 对非功能性需求给予非常彻底的关注。通常，这些都 被称为架构因素（或者称为架构驱动者）
架构设计5视图，包含了逻辑架构、开发架构、运行架 构、物理架构、数据架构等5个架构设计视图
P64 图5-1
25
架构设计的5视图法
逻辑架构：逻辑架构关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提 供的“辅助功能模块”；它们可能是逻辑层、功能模块和类等
开发架构：开发架构关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方 SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。开发架构和逻辑 架构之间可能存在一定的映射关系：比如逻辑架构中的逻辑层一般会映射到开发结构中的多 个程序包；再比如开发架构中的源码文件可以包含逻辑架构中的一到多个类（在C++里一个源 码文件可以包含多个类，即使在Java里一个源码文件也可以同时包含一个类和几个内部类
11
P19 图2-4
12
P20 图2-5
13
P20 图2-6 对于面向对象的软件开发而言，经常有下列软件单元：
粒度最小的单元通常是“类” 几个类紧密协作形成“模块” 完成相对独立的功能的多个模块构成了“子系统” 多个子系统相互配合才能满足一个完整应用的需求，从而构成了软
件“系统” 一个大型企业往往使用多套系统，多套系统通过互操作形成“集成
约束是一类特殊的需求，带有一定强制性，架构师制定的架构决策 必须满足这些限制；
为了满足功能需求，架构师必须规划组成软件系统的所有模块，为 他们分配不同职责，使这些模块可以通过协作完成功能需求
24
架构设计的5视图法
软件架构师必须明确区分功能需求、约束、运行期质 量属性和开发期质量属性等不同种类的需求，基于多 视图的架构设计方法在一定程度上将各类需求分别对 待，通过不同的架构设计视图分别满足它们，从而确 保重要的需求一一被满足。
组件百度文库
交互
9
MVC架构作为”组件+交互“的例 子
View
创建
Controller
读取 通知
Model
调用服务
10
关注点分离之道
好的架构设计必须把变化点错落有致地封装到软件系 统的不同部分，为此，必须进行关注点分离
好的架构必须使每个关注点相互分离，也就是说系统 中的一部分发生了改变，不会影响其他部分。即使需 要改变，也能够清晰地识别出哪些部分需要改变。如 果需要扩展架构，影响将会最小化。已经可以工作的 每个部分都将继续工作。
17
框架和架构的关系
P25 图2-10
18
理解架构
真实的软件其实是“由组件递归组合而成”的：
组件的粒度可以很小，也可以很大；任何粒度的组件都 可以组合成粒度更大的整体。即所谓的粒度多样性问题
组件粒度的界定，必须在具体的实践上下文中才有意义 ；你的大粒度组件，对我而言可能是原子组件。即所谓 的粒度相对性问题
P27 图2-11 图2-12 作为复合整体的软件单元才有架构，架构规定了它如何
被设计的重要决策
19
回到实践
P28 图2-13
20
框架 VS. 类库
P29 图2-14
21
框架的分类
P31 图2-16
22
框架的开发过程
框架的整个开发过程，包括四个主要的阶段，即分析 阶段、设计阶段、实现阶段和稳定阶段。