软件的架构与模式阎宏.docx
《软件的架构与模式阎宏.docx》由会员分享，可在线阅读，更多相关《软件的架构与模式阎宏.docx（22页珍藏版）》请在冰点文库上搜索。
软件的架构与模式阎宏
软件的架构与设计模式之什么是架构
·2005-06-0810:
31:
14·来源:
天极网
什么是软件系统的架构（Architecture）？
一般而言，架构有两个要素：
·它是一个软件系统从整体到部分的最高层次的划分。
一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。
详细地说，就是要包括架构元件（ArchitectureComponent）、联结器（Connector）、任务流（Task-flow）。
所谓架构元素，也就是组成系统的核心"砖瓦"，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。
·建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。
在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。
显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。
计算机软件的历史开始于五十年代，历史非常短暂，而相比之下建筑工程则从石器时代就开始了，人类在几千年的建筑设计实践中积累了大量的经验和教训。
建筑设计基本上包含两点，一是建筑风格，二是建筑模式。
独特的建筑风格和恰当选择的建筑模式，可以使一个独一无二。
下面的照片显示了中美洲古代玛雅建筑，Chichen-Itza大金字塔，九个巨大的石级堆垒而上，九十一级台阶（象征着四季的天数）夺路而出，塔顶的神殿耸入云天。
所有的数字都如日历般严谨，风格雄浑。
难以想象这是石器时代的建筑物。
图1、位于墨西哥Chichen-Itza（在玛雅语中chi意为嘴chen意为井）的古玛雅建筑。
（摄影：
作者）
软件与人类的关系是架构师必须面对的核心问题，也是自从软件进入历史舞台之后就出现的问题。
与此类似地，自从有了建筑以来，建筑与人类的关系就一直是建筑设计师必须面对的核心问题。
英国首相丘吉尔说，我们构造建筑物，然后建筑物构造我们（Weshapeourbuildings,andafterwardsourbuildingsshapeus）。
英国下议院的会议厅较狭窄，无法使所有的下议院议员面向同一个方向入座，而必须分成两侧入座。
丘吉尔认为，议员们入座的时候自然会选择与自己政见相同的人同时入座，而这就是英国政党制的起源。
Party这个词的原意就是"方"、"面"。
政党起源的关键就是建筑物对人的影响。
在软件设计界曾经有很多人认为功能是最为重要的，形式必须服从功能。
与此类似地，在建筑学界，现代主义建筑流派的开创人之一LouisSullivan也认为形式应当服从于功能（Formsfollowsfunction）。
几乎所有的软件设计理念都可以在浩如烟海的建筑学历史中找到更为遥远的历史回响。
最为著名的，当然就是模式理论和XP理论。
架构的目标是什么
正如同软件本身有其要达到的目标一样，架构设计要达到的目标是什么呢？
一般而言，软件架构设计要达到如下的目标：
·可靠性（Reliable）。
软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。
·安全行（Secure）。
软件系统所承担的交易的商业价值极高，系统的安全性非常重要。
·可扩展性（Scalable）。
软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。
只有这样，才能适应用户的市场扩展得可能性。
·可定制化（Customizable）。
同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。
·可扩展性（Extensible）。
在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展
·可维护性（Maintainable）。
软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。
一个易于维护的系统可以有效地降低技术支持的花费
·客户体验（CustomerExperience）。
软件系统必须易于使用。
·市场时机（TimetoMarket）。
软件用户要面临同业竞争，软件提供商也要面临同业竞争。
以最快的速度争夺市场先机非常重要。
架构的种类
根据我们关注的角度不同，可以将架构分成三种：
·逻辑架构、软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等。
比如下面就是笔者亲身经历过的一个软件系统的逻辑架构图
图2、一个逻辑架构的例子
从上面这张图中可以看出，此系统被划分成三个逻辑层次，即表象层次，商业层次和数据持久层次。
每一个层次都含有多个逻辑元件。
比如WEB服务器层次中有HTML服务元件、Session服务元件、安全服务元件、系统管理元件等。
·物理架构、软件元件是怎样放到硬件上的。
比如下面这张物理架构图描述了一个分布于北京和上海的分布式系统的物理架构，图中所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。
图3、一个物理架构的例子
·系统架构、系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。
系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作无疑是架构设计工作中最为困难的工作。
此外，从每一个角度上看，都可以看到架构的两要素：
元件划分和设计决定。
首先，一个软件系统中的元件首先是逻辑元件。
这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献，是非常重要的信息。
其次，进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特征。
这些决定中会有很多是一旦作出，就很难更改的。
根据作者的经验，一个基于数据库的系统架构，有多少个数据表，就会有多少页的架构设计文档。
比如一个中等的数据库应用系统通常含有一百个左右的数据表，这样的一个系统设计通常需要有一百页左右的架构设计文档。
架构师
软体设计师中有一些技术水平较高、经验较为丰富的人，他们需要承担软件系统的架构设计，也就是需要设计系统的元件如何划分、元件之间如何发生相互作用，以及系统中逻辑的、物理的、系统的重要决定的作出。
这样的人就是所谓的架构师（Architect）。
在很多公司中，架构师不是一个专门的和正式的职务。
通常在一个开发小组中，最有经验的程序员会负责一些架构方面的工作。
在一个部门中，最有经验的项目经理会负责一些架构方面的工作。
但是，越来越多的公司体认到架构工作的重要性，并且在不同的组织层次上设置专门的架构师位置，由他们负责不同层次上的逻辑架构、物理架构、系统架构的设计、配置、维护等工作。
软件的架构与设计模式之模式的种类
2005-06-0714:
35作者：
阎宏出处：
天极网责任编辑：
方舟
由于[GOF95]是论述软件模式的著作的第一本，也是OO设计理论著作中最流行的一本，因此有些人常常使用设计模式（DesignPattern）一词来指所有直接处理软件的架构、设计、程序实现的任何种类的模式。
另外一些人则强调要划分三种不同层次的模式：
架构模式（ArchitecturalPattern）、设计模式（DesignPattern）、成例（Idiom）。
成例有时称为代码模式（CodingPattern）。
这三者之间的区别在于三种不同的模式存在于它们各自的抽象层次和具体层次上。
架构模式是一个系统的高层次策略，涉及到大尺度的组件以及整体性质和力学。
架构模式的好坏可以影响到总体布局和框架性结构。
设计模式是中等尺度的结构策略。
这些中等尺度的结构实现了一些大尺度组件的行为和它们之间的关系。
模式的好坏不会影响到系统的总体布局和总体框架。
设计模式定义出子系统或组件的微观结构。
代码模式（或成例）是特定的范例和与特定语言有关的编程技巧。
代码模式的好坏会影响到一个中等尺度组件的内部、外部的结构或行为的底层细节，但不会影响到一个部件或子系统的中等尺度的结构，更不会影响到系统的总体布局和大尺度框架。
代码模式或成例（CodingPattern或Idiom）
代码模式（或成例）是较低层次的模式，并与编程语言密切相关。
代码模式描述怎样利用一个特定的编程语言的特点来实现一个组件的某些特定的方面或关系。
较为著名的代码模式的例子包括双检锁（Double-CheckLocking）模式等。
设计模式（DesignPattern）
一个设计模式提供一种提炼子系统或软件系统中的组件的，或者它们之间的关系的纲要设计。
设计模式描述普遍存在的在相互通讯的组件中重复出现的结构，这种结构解决在一定的背景中的具有一般性的设计问题。
设计模式常常划分成不同的种类，常见的种类有：
创建型设计模式，如工厂方法（FactoryMethod）模式、抽象工厂（AbstractFactory）模式、原型（Prototype）模式、单例（Singleton）模式，建造（Builder）模式等
结构型设计模式，如合成（Composite）模式、装饰（Decorator）模式、代理（Proxy）模式、享元（Flyweight）模式、门面（Facade）模式、桥梁（Bridge）模式等
行为型模式，如模版方法（TemplateMethod）模式、观察者（Observer）模式、迭代子（Iterator）模式、责任链（ChainofResponsibility）模式、备忘录（Memento）模式、命令（Command）模式、状态（State）模式、访问者（Visitor）模式等等。
以上是三种经典类型，实际上还有很多其他的类型，比如Fundamental型、Partition型，Relation型等等
设计模式在特定的编程语言中实现的时候，常常会用到代码模式。
比如单例（Singleton）模式的实现常常涉及到双检锁（Double-CheckLocking）模式等。
架构模式（ArchitecturalPattern）
一个架构模式描述软件系统里的基本的结构组织或纲要。
架构模式提供一些事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。
有些作者把这种架构模式叫做系统模式[STELTING02]。
一个架构模式常常可以分解成很多个设计模式的联合使用。
显然，MVC模式就是属于这一种模式。
MVC模式常常包括调停者（Mediator）模式、策略（Strategy）模式、合成（Composite）模式、观察者（Observer）模式等。
此外，常见的架构模式还有：
·Layers（分层）模式，有时也称Tiers模式
·Blackboard（黑板）模式
·Broker（中介）模式
·DistributedProcess（分散过程）模式
·Microkernel（微核）模式
架构模式常常划分成如下的几种：
一、FromMudtoStructure型。
帮助架构师将系统合理划分，避免形成一个对象的海洋（Aseaofobjects）。
包括Layers（分层）模式、Blackboard（黑板）模式、Pipes/Filters（管道/过滤器）模式等。
二、分散系统（DistributedSystems）型。
为分散式系统提供完整的架构设计，包括像Broker（中介）模式等。
三、人机互动（InteractiveSystems）型，支持包含有人机互动介面的系统的架构设计，例子包括MVC（Model-View-Controller）模式、PAC（Presentation-Abstraction-Control）模式等。
四、AdaptableSystems型，支持应用系统适应技术的变化、软件功能需求的变化。
如Reflection（反射）模式、Microkernel（微核）模式等。
软件的架构与模式之经典架构模式简介
2005-06-0714:
42作者：
阎宏出处：
天极网责任编辑：
方舟
根据LindaRising的《PatternAlmanac》一书，已知的架构模式有七十多种。
这是一个只多不少的统计，其中包括了很多通常认为是设计模式的模式，比如Bridge，Facade，Interpreter，Mediator等模式通常认为是设计模式，但是在许多情况下，也可以作为架构模式出现，因此也常常被当作架构模式。
Layers架构模式
在收集到用户对软件的要求之后，架构设计就开始了。
架构设计一个主要的目的，就是把系统划分成为很多"板块"。
划分的方式通常有两种，一种是横向的划分，一种是纵向划分。
横向划分将系统按照商业目的划分。
比如一个书店的管理系统可以划分成为进货、销售、库存管理、员工管理等等。
纵向划分则不同，它按照抽象层次的高低，将系统划分成"层"，或叫Layer。
比如一个公司的内网管理系统通常可以划分成为下面的几个Layer:
一、网页，也就是用户界面，负责显示数据、接受用户输入；
二、领域层，包括JavaBean或者COM对象、B2B服务等，封装了必要的商业逻辑，负责根据商业逻辑决定显示什么数据、以及如何根据用户输入的数据进行计算；
三、数据库，负责存储数据，按照查询要求提供所存储的数据。
四、操作系统层，比如WindowsNT或者Solaris等
五、硬件层，比如SUNE450服务器等
有人把这种Layer叫做Tier，但是Tier多带有物理含义，不同的Tier往往位于不同的计算机上，由网络连接起来，而Layer是纯粹逻辑的概念，与物理划分无关。
Layers架构模式的好处是：
第一、任何一层的变化都可以很好地局限于这一层，而不会影响到其他各层。
第二、更容易容纳新的技术和变化。
Layers架构模式容许任何一层变更所使用的技术
Fa?
ade架构模式
外部与一个子系统的通讯必须通过一个统一的门面（Facade）对象进行，这就是Facade模式。
现代的软件系统都是比较复杂的，设计模式的任务就是协助设计师处理复杂系统的设计。
设计师处理复杂系统的一个常见方法便是将其"分而治之"，把一个系统划分为几个较小的子系统。
但是这样做了以后，设计师往往仍然会发现一个子系统内仍然有太多的类型要处理。
而使用一个子系统的使用端往往只关注一些特定的功能，却要同时与子系统内部的许多对象打交道后才能达到目的，请见下面的对象图。
图4、Facade架构模式的结构图。
这就是一种不便，它使得系统的逻辑变得不必要的复杂，维护成本提高，复用率降低。
用一个范例说明，中国大陆的医院便是一个子系统，按照部门职能，这个系统可以划分为挂号、门诊、划价、化验、收银、取药等。
看病的病人要与这些部门打交道，就如同一个子系统的使用端与一个子系统的各个类型打交道一样，不是一件容易的事情。
首先病人必须先挂号，然后门诊。
如果医生要求化验，病人必须首先划价，然后缴款，才能到化验部门做化验。
化验后，再回到门诊室，请见下面的对象图。
图5、描述病人在医院里的体验。
图中的方框代表医院。
解决这种不便的方法便是引进Facade模式。
仍然通过医院的范例说明，可以设置一个接待员的位置，由接待员负责代为挂号、划价、缴费、取药等。
这个接待员就是Facade模式的体现，病人只接触接待员，由接待员负责与医院的各个部门打交道，请见下面的对象图。
图6、描述经过Facade模式的改装后，病人在医院里的体验。
图中的方框代表医院。
Facade模式要求一个子系统的外部与其内部的通讯必须通过一个统一的门面（Facade）对象进行。
Facade模式提供一个高等级的接口，使得子系统更易于使用。
使用了Facade模式之后，本章的第一个图中所描述的一个子系统的使用端对象所面对的复杂关系就可以简化为下面这个样子。
图7、Facade架构模式的结构图
描述经过Facade模式的改装后，一个子系统的使用端与子系统的关系。
图中的大方框代表一个子系统。
就如同医院的接待员一样，Facade模式的门面类型将使用端与子系统的内部复杂性分隔开，使得使用端只需要与门面对象打交道，而不需要与子系统内部的很多对象打交道。
Mediator架构模式
Mediator模式包装了一系列对象相互作用的方式，使得这些对象不必互相明显参照；从而使它们可以较松散地耦合。
当这些对象中的某些对象之间的相互作用发生改变时，不会立即影响到其它的一些对象之间的相互作用；从而可以保证这些相互作用可以彼此独立地变化。
在下面的示意图中有大量的对象，这些对象既会影响别的对象，又会被别的对象所影响，因此常常叫做同事（Colleague）对象。
这些同事对象通过彼此的相互作用形成系统的行为。
从图中可以看出，几乎每一个对象都需要与其它的对象发生相互作用，而这种相互作用表现为一个对象与另一个对象的直接耦合。
图8、这是一个过度耦合的系统
通过引入调停者对象（Mediator），可以将系统的网状结构变成以中介者为中心的星形结构，如下图所示。
在这个星形结构中，同事对象不再通过直接的联系与另一个对象发生相互作用；相反地，它通过调停者对象与另一个对象发生相互作用。
调停者对象的存在保证了对象结构上的稳定，也就是说，系统的结构不会因为新对象的引入造成大量的修改工作。
图9、这是一个使用了Mediator架构模式之后的结构图
比较传统的设计方法，面向对象的技术可以更好地协助设计师管理更为复杂的系统。
一个好的面向对象的设计可以使对象之间增加协作性（Collaboration），减少耦合度（Coupling）。
一个深思熟虑的设计会把一个系统分解为一群相互协作的同事对象，然后给每一个同事对象以独特的责任，恰当的配置它们之间的协作关系，使它们可以在一起工作。
在Mediator模式中，所有的成员对象都可以协调工作，但是又不直接相互管理。
这些对象都与一个处于中心地位的调停者对象发生紧密的关系，由这个调停者对象进行协调工作。
这个协调者对象叫做调停者（Mediator），而调停者所协调的成员对象称做同事（Colleague）对象。
在Colleague对象内部发生的事件会影响到所有的同事，但是这种影响不是以直接管理的方式直接传到其它的对象上的。
记住在小组的成员增加时，这样的相互作用关系是以比指数更快的方式增加的。
相反，这种影响仅仅直接影响到调停者对象，而调停者对象反过来会协调其它的同事，形成整个系统的行为。
如果小组的成员增加时，调停者对象可能会面临修改，而其它的同事则可以装做不知道这个新的成员一样，不必修改。
反过来，如果小组的成员之一被从系统中删除的话，调停者对象需要对此做出修改，而小组中其它的同事则不必改动。
Interpreter架构模式
给定一个语言之后，Interpreter模式可以定义出其文法的一种表示，并同时提供一个直译器；使用端可以使用这个直译器来解释这个语言中的句子。
如果某一类型问题一再地发生的话，那么一个有意义的做法就是将此类型问题的各个实例表达为一个简单语言中的语句。
这样就可以建造一个直译器，通过解释这些语句达到解决问题的目的。
例如，依照一个匹配模式搜寻字符串便是一个常见的问题。
与其为每一个匹配模式建造一个特定的算法，不如建造一个一般性的算法处理各种常规表达式。
当接到一个指定的常规表达式时，系统使用一个直译器解释这个常规表达式，从而对字符串进行匹配。
再比如VBA（VisualBasicforApplications）就不仅仅出现在微软的Office系列软件中，并且可以供第三厂家出产的软件嵌入使用；CrystalReports报表生成软件也包括了一个便于使用的宏语言，使用户可以执行较为复杂的命令操作。
一般而言，将VBA或者其它的语言软件嵌入到自己的软件产品中，可以使产品定制化（Customization）能力大大增强，但是这些宏语言引擎往往都很昂贵。
现在要介绍的Interpreter模式将描述怎样在有了一个简单的文法后，使用模式设计解释这些语句。
熟悉了这个模式以后，一个没有接收过形式语言和编译器的正规训练的设计师也可以自行设计一个简单的直译器，以便为使用端提供一个简单语言，或者在系统内部使用一个简单语言描述一个合适的问题。
语言、直译器和剖析器
Interpreter模式只描述直译器是怎样工作的，并不指明怎样在执行时创建新的直译器。
虽然广义地讲直译器不一定要有一个剖析器（Parser），但是使用剖析器仍然是最常见的建立直译器的办法。
一个剖析器可以从一个档或命令行读入文字性命令，并创建直译器。
剖析器是一种能够识别文字并将文字按照一定规则进行分解以便进一步处理的对象。
剖析器能够识别的字符串叫做语言。
通常建立的小型计算机语言是与环境无关的语言，也就是遵循一定的文法的文字模式，所谓文法，便是决定怎样将语言的元素组合起来的规则的集合。
剖析器便是根据组合规则将字符串分解的。
抽象地讲，语言并不一定是以字符串的形式表达的。
在Interpreter模式里面所提到的语言是指任何直译器对象能够解释的任何组合。
在Interpreter模式中，需要定义一个代表文法的命令类型的等级结构，也就是一系列的组合规则；每一个命令对象都有一个解释方法，代表对命令对象的解释。
命令对象的等级结构中的对象的任何排列组合都是一个语言，而剖析器的工作便是将一个文字性语言翻译成为等效的直译器语言。
因此，直译器往往需要剖析器。
认识Jack吗？
剖析器生成器（ParserGenerator），常常称为编译器的编译器（CompilerComplier）。
SunMicrosystem提供一个专为Java程序员发明的强大的剖析器生成器，最初叫做Jack，后来改名为JavaCC。
要使用JavaCC，必须使用它提供的脚本语言编写一个脚本，然后执行JavaCC生成Java源代码。
这生成的源代码就是所需的剖析器。
现在Sun已经不再负责JavaCC的研发，对JavaCC感兴趣的读者可以从据。
JavaCC最早命名为Jack是为了与一个早就广泛使用的剖析器生成器YACC谐音。
如果读者已经熟悉了YACC，可以使用YACC达到同样的目的；只是相比之下JavaCC更容易得到Java程序员的喜爱。
软件的架构与设计模式之层次原则
2005-06-0714:
49作者：
阎宏出处：
天极网责任编辑：
方舟
计算机软件工业是一个年轻的工业，它诞生于1950年，至今不过五十几年的历史。
相比之下，建筑设计则可以追溯到几千年前埃及金字塔时代，甚至更早。
因此，计算机软件设计师可以从建筑设计师那里学习到非常之多的经验和教训。
计算机软件系统的设计和建筑设计有很明显的相似之处。
如果读者到过纽约华尔街附近的话，会发现那里大量的古老雄伟的地标性建筑
升级会员 