首页 新闻 论坛 群组 Blog 文档 下载 读书 Tag 网摘 搜索 开源 FAQ 第二书店 博文视点 程序员
频道: 研发 数据库 中间件 信息化 视频 .NET Java 游戏 移动 服务: 人才 外包 培训
    图书品种:235680
       
热门搜索: ASP.NET Ajax Spring Hibernate Java

复杂性是层次化的。——Frederick P. Brooks,《人月神话》

自从软件系统首次被分成许多模块,模块之间有相互作用,组合起来有整体的属性,就具有了体系结构。

——张友生,《软件体系结构的概念》

好的架构必须使每个关注点相互分离……

——Ivar Jacobson,《AOSD中文版》

有两个概念和软件架构的基本概念是相伴相生的。特别是在实践中,它们总是在软件架构设计过程中出现。

第一个是子系统的概念。子系统是随着软件复杂性的增长而日渐重要的一个概念,它和软件架构密切相关;软件产业发展到今天,软件系统的规模也越来越大,所有软件系统都会被划分为多个模块或子系统进行开发;当子系统也足够复杂时,子系统本身的开发也需要经过架构设计这一关。另一方面,系统整合的趋势日渐强劲,对于大型企业来讲,直接规划近一二十年的综合信息系统方案(它是多个相关软件系统组成的“超系统”或称“系统的系统”)也并不鲜见。于是,软件架构师也应了解软件架构的层次(如软件超系统的架构、软件系统架构、软件子系统架构等)以及不同层次的架构模式(如SOA和MVC就处在不同的层次上)。

第二个就是框架。当前,基于框架的开发堪称一种文化。为了提高软件开发的“起点”,以加快开发速度,提高产品质量,基于框架进行开发已成为了一种普遍现象。一个项目采用一个或多个第三方框架是很常见的事情,例如Spring、Struts、Swing、.NET和MFC等都是流行或曾经流行的框架,不一而足。了解相关技术领域或业务领域的框架已成为软件架构师的必修课。

本章将结合实践,讲述子系统和框架在软件架构设计中的地位。

2.1  子系统和框架在架构设计中的地位

2.1.1  关注点分离之道

好的架构设计必须把变化点错落有致地封装到软件系统的不同部分,为此,必须进行关注点分离。Ivar Jacobson在《AOSD中文版》中写道:

好的架构必须使每个关注点相互分离,也就是说系统中的一部分发生了改变,不会影响其他部分。即使需要改变,也能够清晰地识别出哪些部分需要改变。如果需要扩展架构,影响将会最小化。已经可以工作的每个部分都将继续工作。

那么,如何通过关注点分离来达到“系统中的一部分发生了改变,不会影响其他部分”的目标呢?

首先,可以通过职责划分来分离关注点。面向对象设计的关键所在,就是职责的识别和分配。每个功能的完成,都是通过一系列职责组成的“协作链条”完成的;当不同职责被合理分离之后,为了实现新的功能只需构造新的“协作链条”,而需求变更也往往只会影响到少数职责的定义和实现。无论是对象、模块,还是子系统,它们所承担的职责都应该具有高内聚性,否则对象之间的松耦合性就失去了基础,成为空谈。架构模式和设计模式为特定上下文中重复出现的问题提供了通用的职责划分方案。

其次,可以利用软件系统各部分的通用性的不同进行关注点分离。不同的通用程度意味着变化的可能性不同,将通用性不同的部分分离有利于通用部分的重用,也便于对专用部分进行修改。打个比方,一座高楼大厦要想稳固,必须考虑不同部分的热胀冷缩系数的差异,将不同“膨胀比”的部分硬连在一起容易引起“开裂”,这个比喻很好地说明了“稳固的架构”的含义。广为人知的框架技术可以用于分离通用部分,而元模型驱动方法是另一种分离通用性部分的技术。

另外,还可以先考虑大粒度的子系统,而暂时忽略子系统是如何通过更小粒度的模块和类组成的。在实际中,软件架构师常常将系统划分为一组子系统,并为子系统定义明确的接口,其中的细节将随其后的开发工作慢慢展开。这样做可以避免陷入过多的细节当中,所谓“忘却是一种能力”,就是指架构师必须有在更高层面思考的能力(第19章将以继承为例说明如何突破OOP思维的限制)。

图2-1总结了上述的架构设计关注点分离原理。可以说,根据职责分离关注点、根据通用性分离关注点、根据不同粒度级别分离关注点是3种位于不同“维度”的思维方式,所以在实际工作中必须综合运用这些手段。

图2-1  架构设计关注点分离原理

2.1.2  子系统和框架在架构设计中的地位

软件界是新名词制造工厂,这可能是其他任何产业都难以望其项背的。但在这背后,深藏着的是相对稳定的“解决之道”。根据我们上一节讲述的关注点分离原理,归纳了一些流行技术所处的位置,如图2-2所示。

图2-2  技术谱

例如,无论是架构模式还是设计模式,重点关注的都是如何提供一个“协作模型”,这个协作模型通过明确协作中不同角色所担负的职责,达到“为特定上下文中的问题提供解决方案”的目的。来看看抽象工厂(Abstract Factory)设计模式,它是常见的设计模式之一。图2-3以“上下文-问题-解决方案”的形式总结了抽象工厂设计模式:我们遇到的设计问题是如何实现一系列对象的实例化,并且问题所处的上下文是“不同的应用场景需要不同系列的对象实例”;最终,抽象工厂的解决方案是“为创建系列对象提供统一接口,为如何实际创建提供不同实现”。显然,如果没有“不同的应用场景需要不同系列的对象实例”上下文限制,我们的设计可能仅仅是个普通的对象工厂。

图2-3  抽象工厂设计模式

抽象工厂(Abstract Factory)模式

关键字:不同系列的对象实例

支持变化:便于切换不同系列的对象实例,便于修改对象实例的具体创建过程。

结构:

(图片来源:《设计模式》)

于是,我们就不难理解本章将重点讨论的子系统和框架技术在架构设计中的重要地位了。例如,现在的软件开发越来越倚重框架的使用,因此选择何种框架,每个框架在整个架构中处在什么位置,都成为软件架构设计的重要环节。Ivar Jacobson就曾指出,“设计应该把类库和框架的用法反映出来”。框架技术有助于把通用关注点和专用关注点分离开来,结果是带来了更好的易修改性和可重用性。如图2-4所示,框架支持我们引入一个全新的关注点分离维度,并且它和分层架构有很好的结合。

图2-4  框架引入一个全新的关注点分离维度

查看所有评论(0)条】

最近评论



正在载入评论列表...
热点评论