《软件架构设计》温昱 电子工业出版社
1
第一部分 软件架构概念与思想
王建民 mcswjm@https://www.doczj.com/doc/638238855.html, 2010年1月20日
内容提要
2
架构的基本概念 子系统、框架和架构概念及关系 软件架构在不同情况下的作用
《软件架构设计》温昱 电子工业出版社
第一章
3
解析软件架构概念
软件架构概念
定义：没有
《软件架构设计》温昱 电子工业出版社
软件架构概念
4
软件架构作为在研究和实践中不断发展演化的理论，加 上对软件过程中的各种制品没有形成真正意义上的准确 界定与标准名称，因此软件架构尚未形成一个公认的统 一定义； 业界中的定义归结而言可分为：组成派和决策派两大流 派
《软件架构设计》温昱 电子工业出版社
决策派
5
Booch、Rumbaugh和Jacobson的定义
架构是一系列重要决策的集合，这些决策与以下内 容有关：软件的组织，构成系统的及其接口的选 择，这些元素在相互协作中明确表现出的行为，这 些结构元素和行为元素进一步组合所构成的更大规 模的子系统，以及指导这一组织-包括这些元素及其 接口、它们的协作和它们的组合---架构风格
Eoin Woods的观点
软件架构是一系列设计决策，如果作了不正确的决 策，你的项目可能最终会被取消
《软件架构设计》温昱 电子工业出版社
组成派
6
Garlan和Shaw的定义
架构包括组件、连接件和约束三大要素。组件可以是一 组代码(例如程序模块)，也可以是独立的程序(例如数 据库服务器)。连接件可以是过程调用、管道和消息 等，用于表示组件之间的相互关系。“约束”一般为组 件连接时的条件
Perry和Wolf的定义
软件架构是一组具有特定形式的架构元素，这些元素分 为三类：负责完成数据加工的处理元素、作为被加工信 息的数据元素及用于把架构的不同部分组合在一起的连 接元素
《软件架构设计》温昱 电子工业出版社
组成派(续)
7
Boehm的定义
软件架构包括系统组件、连接件和约束的集合，反应 不同涉众需求的集合，以及原理的集合。其中的原 理，用于说明由组件、连接件和约束所定义的系统在 实现时，是如何满足不同涉众需求的
IEEE的定义
架构是以组件、组件之间的关系、组件与环境之间的 关系为内容的某一系统的基本组织结构，以及指导上 述内容设计与演化的原理
Bass(SEI)的定义
某个软件或计算机系统的软件架构是该系统的一个或 多个结构，每个结构均由软件元素、这些元素的外部 可见属性、这些元素之间的关系组成
《软件架构设计》温昱 电子工业出版社
软件架构概念
8
组成派的观点更关注软件，倾向于“组件+交互” 的思想： 决策派的观点更关注人，倾向于重大决策集合 的思想，除了结构和行为，还关注一些非功能 的因素
《软件架构设计》温昱 电子工业出版社
PM Tool案例：领会架构概念
9
PM Tool是一个项目管理系统，提供项目计划、任务管理和 资源管理等功能 需求：查看甘特图
用户要求“能够以甘特图方式查看任务的起始 时间、结束时间、任务承担者 等信息”
表格方式 甘特图方式
9 《软件架构设计》温昱 电子工业出版社
PM Tool案例：领会架构概念
10
任务是如何计划的？又具体分配给哪些项目成员？这些信 息和PM Tool采用何种方式来展现应当是没有关系的； 采用MVC架构，将业务逻辑和展现逻辑分开，如图1所示：
view 读取数据 model 图1 和具体技术无关的架构方案
《软件架构设计》温昱 电子工业出版社
PM Tool案例：领会架构概念
11
“甘特图绘制包”：自行开发 or 采用的第三方SDK。 分析要素：
用户不关心“甘特图绘制包”的问题，他们只在乎自己的需求是 否得到了满足； 项目工期很紧，自行开发“甘特图绘制包”势必增加其他工作的 压力 短期内决定采用的第三方“甘特图绘制包”可能并不是最优的， 所以并不希望PM Tool”绑死”在特定“甘特图绘制包”上；
《软件架构设计》温昱 电子工业出版社
PM Tool案例：领会架构概念
12
基于以上分析，架构师会决定：采用第三方SDK，但会 自主定义“甘特图绘制接口”将SDK隔离。如图2所示：
图2 和技术相关 的架构方案
《软件架构设计》温昱 电子工业出版社
PM Tool案例：领会架构概念
13
以上案例从组成派的观点看，业务层和展示层即组件， 交互则体现在读取数据上； 这里，我们主要从决策派的角度看以上实例所体现的架 构思想； 在软件架构中的设计决策是如何支持“使用、功能性、 性能、弹性、重用、可理解性、经济和技术的限制及权 衡，以及美学等”非功能需求的；
PM Tool案例：领会架构概念
14
以“弹性”为例，为了防止PM Tool”绑死”在特定甘 特图绘制包上，架构设计之时作了如下决策(参见图2)： 引入自主定义的GanttChart接口，让实现该接口的 GanttChartImpl转而调用第三方SDK; 这样一来，架构就有了弹性——当发现功能更强大的甘 特图程序包时(或决定直接调用Java 2D自行开发甘特图 绘制部分时)，可以方便地仅更改GanttChartImpl,而其 他组件不用更改(如图3所示)
《软件架构设计》温昱 电子工业出版社
PM Tool案例：领会架构概念
15
图3 软件架构 如何具有弹性
《软件架构设计》温昱 电子工业出版社
重要结论
16
组成派和决策派软件架构概念并不矛盾，它们 只不过是所站的角度不同罢了； 在具体的软件架构实践中，总是同时体现着这 两“派”的架构概念；
《软件架构设计》温昱 电子工业出版社
《软件架构设计》温昱 电子工业出版社
17
第二章 子系统、框架与架构
06软件工程（计算机应用软件） 黄珊珊 2010年1月20日
子系统、框架与架构
18
有两个概念和软件架构的基本概念是相伴 相生的，特别是在实践中，它们总是在软 件架构设计过程中出现—子系统和框架；
《软件架构设计》温昱 电子工业出版社
子系统、框架与架构
19
子系统：
子系统是随着软件复杂性的增长而日渐重要的一个概念，它和软 件架构密切相关； 软件系统的规模越来越大，所有软件系统都会被划分为多个模块 或子系统进行开发； 当子系统也足够复杂时，子系统本身的开发也需要经过架构设计 这一关。 另一方面，系统整合的趋势日渐强劲，对于大型企业来讲，直接 规划近一二十年的综合信息系统方案(它是多个相关软件系统组成 的“超系统”或称“系统的系统”)也不鲜见。于是，软件架构师 也应了解软件架构的层次(如软件超系统的架构、软件系统架构、 软件子系统架构等)以及不同层次的架构模式(如SOA和MVC就处于 不同的层次上)
运用架构模式
20
框架： 当前，基于框架的开发堪称一种文化。为了提高软件开 发的“起点”，以加快开发速度，提高产品质量，基于 框架进行开发已成为了一种普遍现象。一个项目采用一 个或多个第三方框架是很常见的事情， 例如Spring、Structs、Swing、.NET和MFC等都是流行 或曾经流行的框架，不一而足。
《软件架构设计》温昱 电子工业出版社
2.1子系统和框架在架构设计中的地位
21
关注点分离之道
通过职责划分来分离关注点.
面向对象设计的关键所在,就是职责的识别和分配.每个功能的完 成,都是通过一系列职责组成的“协作链条”完成的；当不同职责被 合理分离之后，为了实现新的功能只需要构造新的“协作链条”， 而需求变更也往往只会影响到少数职责的定义和实现。 无论是对象、模块，还是子系统，它们所承担的职责都应该具有 高内聚性，否则对象之间的松耦合性就失去了基础。
子系统和框架在架构设计中的地位
利用软件系统各部分的通用性的不同进行关注点分离
不同的通用程度意味着变化的可能性不同，将通用性不同的部分 分离有利于通用部分的重用，也便于对专用部分进行修改。
广为人知的框架技术可以用于分离通用部分，而元模型驱动方法 是另一种分离通用性部分的技术。
子系统和框架在架构设计中的地位
23
考虑大粒度的子系统，而暂时忽略子系统是如 何通过更小粒度的模块和类组成的。
在实际中，软件架构师常常将系统划分成一组子系统 ，并为子系统定义明确的接口，其中的细节将随其后 的开发工作慢慢展开。这样做可以避免陷入过多的细 节当中。 根据职责分离关注点、 根据通用性分离关注点、 根据不同粒度级别分离关注点 是3种位于不同“维度”的思维方式
子系统和框架在架构设计中的地位
24
职责划分
数 据 层
职责划分
业 务 层
展 现 层
技 领 域 通 通 用 用 部 部 分 分 通用 术
合成
子系统 定 应 模块 部 分 类 用
特
分解
图4 架构设计关注点分离原理
专用
子系统和框架在架构设计中的地位
25
子系统 组件技术 SOA技术 粒度
图5 流行技术所处的位置
子系统和框架在架构设计中的地位
26
无论是架构模式还是设计模式，重点关注的都是如何提供 一个“协作模型”，这个协作模型通过明确协作中不同角色 所担负的职责，达到“为特定上下文中的问题提供解决方 案”的目的； 现在的软件开发越来越倚重框架的使用，因此选择何种框 架，每个框架在整个架构中处在什么位置，都成为软件架 构设计的重要环节； Ivar Jacobson曾指出：“设计应该把类库和框架的用法反 映出来”； 框架技术有助于把通用关注点和专用关注点分离开来，结 果是带来了更好的易修改性和可重用性
元 框 模 架 型 技 技 术 术
软件界是新名词的制造 工厂，但在背后，深藏 着的是相对稳定的“解决 之道”，根据上面谈的关 注点的分离，归纳一些 流行技术所处的位置。
职责
架构模式 设计模式
通用性
2.2子系统与软件架构
27
了解子系统与软件架构的关系有两方面的意义 从解决问题的角度而言，了解子系统与软件架构的关系， 有助于避免软件架构设计不足的问题；软件架构要设计到 什么程度？为了使软件架构能够为软件开发提供足够的指 导和限制，软件架构师应该为复杂的子系统设计架构，而 不是保持其黑盒子的状态止步不前； 从经验的运用角度而言，了解子系统与软件架构的关系， 有助于充分利用架构设计技能。比如，有经验的软件架构 师都知道，分层、MVC和管道过滤器等架构模式很少单 独使用，而是结合使用或根据子系统的层次划分嵌套使 用，图6，就是一个分层架构模式和MVC架构模式结合使 用的例子
子系统与软件架构
28
展现层 View 业务层 Controller MVC架构 Model 数据层 图6 分层架构和 MVC架构结合使用 的例子
分层架构
不同粒度的软件单元
软件单元是如何组成粒度更大的整体的？ 在具体的架构实践中，一个软件系统往往首先 分解成几个子系统，子系统又继续分解…….
例如，一个系统，由3个子系统组成；每个子系统 ，又由组成它的多个类来实现；
子系统可以分配到开发组，每个类可以分配给 具体的工程师实现；
不同粒度的软件单元
作为架构师，要考虑“软件单元如何组成粒度更大的整 体”的问题 更广泛而言，构成软件的单元具有不同的粒度级别； 对面向对象软件开发而言，常有这些软件单元：
类：粒度最小的单元； 模块：几个类紧密协作形成； 子系统：完成相对独立的功能的多个模块构成； 系统：多个子系统相互配合以满足完整应用需求； 集成系统：大型企业往往使用多套系统，由多套系系统通 过互操作形成；
以上都是软件单元的具体形态，只不过粒度不同； 软件系统越复杂，不同粒度的分解层次就越多；
子系统也有架构
所谓系统，是指由多个元素组成的逻辑实体， 它完成一组特定的目标或担负一定的职责； 系统可以仅包含软件，也可以仅包含硬件，或 者是两者都包含； 子系统是特殊的系统---只不过在特定的上下文 中，这个系统作为更大的系统的一部分出现； 系统需要架构设计，而子系统如果足够复杂， 则也需要架构设计；
子系统不同，架构不同
不同类型的软件系统需要不同的软件架构设计 有时，一个系统的不同子系统也应当有不同的软 件架构 例如，目前已经有很多架构模式，但是这些架构 模式的运用并不是“放之各子系统而皆准”的，需 要根据具体的子系统选择合适的架构模式；
不同实践者眼中的粒度
粒度具有相对性，即同一软件单元，在不同场景下我们会 以不同的粒度看待； 是复杂事物还是简单事物，要视对谁而言； 因此，应当立足实践对待软件单元的粒度问题；
当进行高一级的架构设计时，子系统就是一个原子单元、一个 黑盒； 当进行子系统本身的设计时，它才变成一个结构复杂的白盒； 第三方组件一般被看作原子单元，只需关心其对外接口即可— 此时我们是使用它的服务； 但当使用来自第三方的框架作为某一级系统或子系统的架构基 础时，则应当仔细研究其结构—这是因为此时是使用它的结构 而不仅仅是服务；
2.3框架与软件架构
框架的概念 框架是可以通过某种回调机制进行扩展的软件 系统或子系统的半成品; 框架与所有软件组件的本质区别在于:框架是半 成品; 框架的智慧在于:为了追求重用所带来的价值量 最大化,将容易变化的部分封装成扩展点,并辅以 回调机制将它们纳入框架的控制范围之内,从而 在兼顾定制开销的同时使被重用的设计成果最 多;
框架的概念
Frank Buschmann等人在《面向模式的软件体 系结构(第一卷)》把框架定义为： 框架是一个可实例化的、部分完成的软件 系统或子系统，它为一组系统或子系统定义了 架构，并提供了构造系统的基本构造块，还为 实现特定功能定义了可调整点。在面向对象环 境中，框架由抽象类和具体类组成。
框架的概念
Erich Gamma等人在《设计模式》中把框架定 义为： 框架是一组相互协作的类，形成某类软件 的一个可复用设计。框架将设计划分为一组抽 象类，并定义它们各自的责任和相互之间的协 作，以此来指导体系结构级的设计。 开发者通过继承框架类中的类和组合其实例 来定制该框架以生成特定的应用。
架构和框架的区别
框架是软件，架构不是软件； 框架是一种特殊的软件，它并不能提供完整无 缺的解决方案，而是为你构建解决方案提供良 好的基础； 框架是半成品，典型地，框架是系统或子系统 的半成品；框架中的服务可以被最终应用系统 直接调用，而框架中的扩展点是供应用开发人 员定制的“可变化点”；
架构和框架的区别
软件架构不是软件，而是关于软件如何设计的重要决策； 软件架构决策涉及到如何将软件系统分解成不同的部分、 各部分之间的静态结构关系和动态交互关系等； 经过完整的开发过程之后，这些架构决策将体现在最终开 发出的软件系统中； 引入软件框架之后，整个开发过程变成了“分两步走”，而 架构决策往往会体现在框架之中；
软件架构是比具体代码高一个抽象层次的概念； 架构势必被代码所体现和遵循，但任何一段具体的代码都代表 不了架构；
架构和框架的联系
框架技术和架构技术的出现，都是为了解决软件系统日 益复杂所带来的困难而采取“分而治之”思维的结果----先 大局后局部，就出现了架构；先通用后专用，就出现了 框架； 架构是问题的抽象解决方案，它关注大局而忽略细节； 而框架是通用半成品，还必须根据具体需求进一步定制 开发才能变成应用系统；
起点
先构建通用半成品
先规划抽象解决方案 架构 将系统或子系 (抽象解决方案) 统架构框架化 再实现细节 框架也需架构设计 再实现特定部分
框架 (半成品) 图7 框架和架构的关系
最终完整 解决方案
架构和框架的联系
简而言之，框架和架构的关系可以总结为两句 话:
为了尽早验证架构设计，或者出于支持产品线开 发的目的，可以将关键的通用机制甚至整个架构以 框架的方式进行实现； 业界(及公司内部)可能存在大量可供重用的框架 ，这些框架或者已经实现了软件架构所需的重要架 构机制，或者为未来系统的某个子系统提供了可扩 展的半成品，所以最终的软件架构可以借助这些框 架来构造。