第I部分 预想构架

软件构架源自何处？当然来自设计师的聪明才智。但究竟逛如何构想出来的呢？要能 够设计出软件构架，设计师应该具备什么样的素质？另外，到底什么是软件构架？软件构架与软件设计是否相同？如果相同，何必再用软件构架这个词呢？如果不同.釕哪些差异， 为什么说软件构架很歌要？

 

软件构架是软件系统的核心，其影响久远，并不随某个软件系统生命期的结束而终结。 在本书的第丨部分.我们将着重讨论软件设计师开始创建——或者说预想——软件系统的 这-核心时所用到的各种知识和技能。我们经常把软件设计看作是为保证软件系统能够按 照原来的设想疋常运行——给出正确的结果或提供预期的功能——而在各个环节上采取正确步骤。软件构架所耍考虑的问题则更为广泛。构架设计师面临的是诸多相互竞争的（如 果不是相互冲突的话）因素和需求，或许读者会惊讶地发现，其中涉及保证软件系统正确 运行的寥寥无几。组织和技术方面的环境对软件系统的幵发也有若干需求.有时是以比较 含蓄的形式出现的。虽然几乎从来没有写在书面上，但这些需求和书面表述的那些需求一 样.对软件开发实践具有重要影响。

 

同样让人感到惊讶的是，软件构架对从事软件开发的组织产生深远彫响的方式。在软 件开发中.当然不是提出一个构架绑定到要开发的软件系统上，交给开发此系统的部门后 就束之尚阁相反，构架和其开发组织就像跳复杂的华尔兹•样，相互影响.相厅帮助. 共同成长、发展，以登上新的台阶。

 

我们把上述这种华尔兹舞叫作构架商业周期.这是本书的主题，也足第丨章论述的重 点.第2章讲述的是软件构架研究的基础知识，将给出软件构架的概念，明确其在软件工 程领域中的位51,并给出一些概念性的研究工具。在所阐述的-系列概念中，占首要地位 的是软件构架由若干相互独立而又相互协同的结构组成，其中每个结构在系统幵发中都需 要权衡。

 

第3章给出了本书的第一个案例分析。该章的案例向读者展示了 -个特定的构架如何 解决设计师所面临的各种需求——此例是•个嵌入式实时航空电子系统.重点在于如何实 现长期的可修改性——并使读者更加深刻地理解前面已经阐明的概念^在此案例中.构成 构架的3个相互独立的结构-模块分解、使用和进程结构——相互作用，构成该系统的 完美的构架解决方案。

 

经过上述介绍后，下面开始讲述构架商业周期。

 

                                                    第一章    构架商业周期

 几十年来，软件设计者们接受的教导一直是完全按照系统的技术需求表述进行系统设 计。从概念上看，就好像某人将技术需求文档扔进设计室，然后设计者就必须按照这样的 需求文档给出令人满意的设计，即设计产生于需求，而系统又产生于设计。当然，现代的 软件开发方法认识到了这种模型的单向直接性，并提出了各种从设计者到分析员的反馈回 路。但实际上，这些现代设计方法仍然是基于设计是系统技术需求的产物这•假设。

 

作为设计过程的重要组成部分，现在已经提出了构架的概念。构架是本书的主题。“软 件构架”包含大型软件系统的结构。系统的构架视图是抽象的.它不考虑实现、算法和数据表示的细节,集中研究“黑盒”元素的行为和交互。在设计具有所期银属性的系统时. 幵发软件构架是第步。第2章将对软件构架进行详细讨论。现在我们提供如下定义.暂 时不做洋细讨论：

 

程序或计算系统的软件构架是该系统的一个（或多个）结构，它由软件元素、元素的 外部可见属性以及它们之间的关系组成.

 

本书的第2萆将给出软件构架的确切定义，并将构架与其他设计形式进行比较。构架 是软件系统之间进行交流、推理、分析和扩张的重要工具，本t5将详细进行阐述。但迄今 为止.业内对构架的讨论仍沿用了传统思想：如果知道了系统衢求，就可以为此系统构建 构架。

 

这种观点是缺乏远见的（参见引文“猫}典的瓦萨战舰”)，不能真正揭示出构架的重要 价值。试想下，如果把对某个系统的需求分析文档分别交给两个在不同组织工作的设计 师，结果会如何呢？这两个设计师是给出同一个构架，还是给出两个不同的构架呢？

 

这则关于瓦萨战舰的故事虽然发生在370多年前，但却很好地说明了构架商业周期的 概念：系统需求来自于企业目标，构架来自于系统需求，系统来自于构架。构架与设计师 的经验、当肘的技术水平有着密切的联系。'可怜的Hybertsson在设计瓦萨战舰时，无论从 他本人的经验还是从当时的技术水平来看，都不具备相应的条件„

 

本书将讲述Hybertsson本应用到的如下3方面的内容：

 

(I)能够满足苛刻需求的成功构架案例分析，以确定当前的技术水半 

(2 )在构建系统之前使用对所用构架进行评估的方法，以减小开发一个无先例的全 新系统所承担的风险.

(3)基于构架的增量开发技巧，以及时发现设计缺陷并加以改进。

 

我们的目标是给设计师提供一种能够摆脱设计两难境地的方法，从而使这位荷兰舰船 设计师的悲剧不再重演.现在，“出师未捷身先死”的情况不再像过去那样令人钦佩了 •

 

——PCC

 

答案是：一般情况下.会给出两个不同的构架。这一结果立刻就可以证明系统需求决 定构架的观点是错误的。显然，在形成构架的过程中，还有其他一些因素在起作用。如果 不找出这些因素，就只能依旧在黑喑中摸索。

 

我们关注的焦点问题是：系统的软件构架与构建系统时的环境及系统未来所处的环境 有什么关系？此问题的答案就是组织本书内容所遵循的原则。软件构架是技术、商业和社会等诸多因素作用的结果。而软件构架的存在反过來又会影响技术、商业和社会环境，从 而影响到未来的构架。我们把这种相互影响的周期——从环境到构架乂返回到环境——称 作构架商业周期（Architecture Businees Cycle, ABC)。

 

本苹将详细讲述ABC的概念.并为后续章节的阐述奠定基础.本书详细讨论构架商 业周期的如下方面：

•组织目标如何影响需求和开发策略

 

•如何从需求得出构架 

•如何对构架进行分析

•构架如何产生体现新的组织能力和需求的系统

 

1.1构架的产生

构架也是若干商业和技术决策的结果。构架的设计受诸多因素的彫响，而这些影响因素的实现又随构架所处环境的不同而异。即使是同-个设计师设计某个系统.在时间要求 I紧迫和时间耍求比较宽松的情况下，所做的决策也会有所+同。如果对设计没有时间限 IJ,他会做出不同的选择。即使在系统需求、硬件环境、支持软件和人力资源等方面的条 (=完全相同的情况下，某个设计师现在所能设计出的系统和他在5年前所能设计出的系统 i很可能是不一样的。

 

在任何一次开发中，系统需求都能够明确反映出对系统最终特性的某些期望。并不是 ;、统需求中的所有内容都和系统最终具备的特性直接相关。开发过程或某个工具的选用可 巨会受到系统潘求的制约.但对系统需求的表述仅仅是万里长征第-步。如果不能满足除 I统需求之外的W他鸣要求，所开发出来的系统很可能就像小能常运行的系统样一 C不值。

 

我们通过确定与构架有关的影响因素开始构建ABC^

 

.1.1构架受系统涉众的影响

 

很多人和组织都对构建软件系统感兴趣。我们把这样的人或组织称为涉众：客户、最 冬用户、开发人员、项目经理、维护人员以及那些对系统进行市场费销活动的人等等。这些涉众所关注的问题各不相同，但都要求系统能够在他们所关注的方面提供保证或优化。 这可能是耍求系统在运行时具有一定的特征、能够在特定的硬件平台上良好运行、用户能 谬轻松地定制系统、实现短的上市时间或较低的开发成本、使公司聘用到有专长的程序员 或提供广泛的功能.如此种种.不而足。图1.2给出了设计师采纳有帮助的涉众的“建 议"的情况。

 

一个得到各方认可的系统需要在以下方面达到相应要求：性能、可靠性、可用性、平 台兼容性、内存的利用、网络使用程度、安全性、可修改性、易用性，与其他系统的互操 作性以及行为。I-.述属性，以及其他一些属性，都会影响到接受此系统的某个涉众对该系 统的评价。

 

当然，最基本的问题是，每个涉众所关心的问题和期望的目标各不相同，而且有些是 相互矛盾的。然，可以把属性列在诸如需求文档这样的制品中’并对其进行讨论。但是. 很少有需求文档能够以一种可测试的细节捕获系统所有的质量需求。现实情况是设计师通 常不得不填补空白并协调冲突。

 

1.1.2构架受开发组织的影响

 

除了通过需求表示的组织目标外，构架还受开发组织的结构或本质的影响。例如，组 织中是否有足够多的有空闲时间且精通客户机/服务器通信的程序员？如果没有的话，就有充分理由抱绝采用基于客户机/服务器模式的构架。人员的技能也是•个影响因素，开发进 度和预算也会对构架产生影响。

 

开发组织对软件构架的影响可以分为3类，即直接影响、长远影响和组织结构的影响.

 

•    开发组织可能会对某些资产进行直接商业投资，如现有的构架和基于这些构架的 产品。开发项目的基础可能是所要开发的新系统是已有类似产品线的延续，其开 发成本中有很大一部分属于资产重用。

 

•    开发钳织可能希望对某个基础结构进行长期的商业投资以实现某些战略目标，并且可能会把要开发的系统视作为此基础结构融资或进一步扩展此基础结构的手段。

 

•    幵发组织本身的结构也会影响构架的形成。在第8章（飞行模拟：构架可集成性 案例分析）的案例分析中.我们将看到：某些子系统的开发转包给了其他开发组 织，这是由于这些组织刚好具备相应的专长。这时需耍对构架做功能上的划分， 以便使各部分能够相互独立，否则垃无法实现转包的。

 

1.13构架受设计师的素质和经验的影响

 

如果设计师在设计构架时使用过某种方法(如分布式对象或隐式调用）并且效果不错， 则在设计新系统时，很可能会想再沿用这种方法。相反，如果以前用某种方法的效果极差， 设计师可能就不会想用这种方法了。设计构架时所做的各种选择与设计师本人所受的教育 或培训背景，对其他成功构架的了解以及对某些性能极佳或极差的系统的了解有关。设计 构架时，设计师可能想实践•下某种构架模式.或者是尝试使用在某本书（例如本朽）上 或某门课程中所学到的技巧。

 

1.1.4构架受技术环境的影响

 

技术环境可以看作是对设计师素质和经验的特殊反映。设计某个构架时所处的技术环 境将会对构架的设计产生影响。这里所说的技术环境包括行业中的通常做法或在设计师所 属专业团体中占主导地位的软件工程技巧。在当今的技术环境下.如果釘哪个设计师根本 就不考虑用基于 Web、面向对象和支持中间件的方法来设计信息系统.我们就不得不佩服 他的勇气了。

 

1.1.5影响构架的其他因素

 

影响构架的因素有很多。一些只是隐含的，还有一些则很明显是冲突的。

软件开发者几乎从来没有真正理解过企业目标所要求的系统性能，更不必说完全实现 了。.确实，连客户的霈求都很少完全编成文档，这意味着还没有解决不同涉众目标之间不可避免的冲突。

 

然而，设计师需要尽早知道并理解特性、源以及对项目的限制的优先级。因此，设计 师必须确定出各类涉众，并积极促使他们表达出对系统的需求或期望。如果不做这样的工 作，在设计展开后.就会出现某些涉众要求设计师解释为什么不采用所提出的其他方案的 情况，这显然会影响项目的开发进度，降低工作效率。如果早期工作做得好.设计师就能 淸楚在设计构架时所应考虑的制约条件.调整对系统的期望，与有关各方商讨各因素的优 先级并进行权衡。构架评审（在第III部分论述）和迭代原型建立是实现此目标的两个手段。

 

要设计出好的构架，设计师仅具有高超的专业技术是不够的，这个道理显而易见。设 计师需耍不断地匈涉众解释针对不同属性所做的各种取舍，以及为何无法满足涉众的所有 要求。因此.成功的设计师还必须具备与人交往、谈判和交流的技巧^

 

图1.3给出了对设计师（因此也是对构架）的影响。如图所示.设计师会受到产品需 求（从涉众那儿获得）、所在幵发组织的结构和目标、可利用的技术环境及自為素质和经 验的影响。

 

1.1.6  构架对诸影响因素的反作用

 

本书的主旨就是耍阐明企业目标、产品需求、设计师的经验、构架和最终系统之间的 关系——它们构成带有反馈回路的、可由开发组织实施管理的周期。可由开发组织对这个周期 管理得好.就能够不断成长壮大，.拓展其经营范围，充分利用以前在构架和系统构建方面的投资。图1.4给出了该周期中的这些反馈回路。可以看到，有些反馈是来自构架本身的, 而有呰则来自根据构架所构建的系统。

 

下面我们就来看下该周期是如何运作的：

 

(1)构架影响着开发组织的结构。构架规定了系统的结构。特别地.就像我们将会 看到的•样.构架规定了必须实现（或获得）并集成在系统中的软件单元。这呰单元是开 发项目的结构的基础。每个软件单元都要由专门的开发小组来完成，开发、测试和集成工 作都是围绕这些单元展开的。同样.进度和预算也都要和这些组件相对应，并为之分配所 需的资源。如果某个开发公司擅长构建相类似的系列系统，它就会为每个小组进行适当的 投资，以保证各小组在其从事的领域达到较高的水准。这些小组也就成为该开发组织中不 可或缺的组成部分。这就是从构架到开发组织的反馈。

 

在第15章的软件产品线案例分析中，对于一系列产品，由单独的小组负责构建和维 护构架的某个部分。在组织采用的任何设计中，这些小组都强烈要求在系统分解中采用他 们所控制的部分。

 

(2)构架会影响开发组织的目标。成功地开发出一个系统，可以使开发公司在相应 的市场上占有一席之地。该系统的构架又可以为类似系统的有效生产和部署提供良好的机 会，组织可以调整其目标，以利用其新发现的技术来拓宽市场。这就是从该系统到开发组 织以及它所构建的系统的反馈.

 

(3)构架可能会影响客户对下一个系统的要求。这是因为与完全重新开始设计相比，利用己有的构架可使客户更为及时地获得更可靠、更经济的系统。从经济的免度考虑.容 户可能会愿怠放弃某些性能需求。套装软件提供给广大用户的解决方案并不是针对某个用 户开发的，但这种软件价格低廉，而且（综合考虑）质量较高。产品线对那些不能确切表 述自己在各种情况下的需求的用户也产生了类似的影响。在第15章(CelsuisTech：产品线 开发案例分析)，我们将会了解到产品线的构架如何影响客户’从而使之愉快地同怠改变 自己对系统的需求。这主要是因为通过这种方式，客户可以在很短的时间内拿到既能满足 其基本需求，又具有很高可靠性且价格相对低廉的高质麗软件系统。

 

(4)构造系统的过程丰富了整个开发团体的经验，从而将影响设计师对后继系统的 设计。如果在某个系统的开发中采用了某些工具，或封装好的有限状态机模型，并且取得 了极大的成功，那么.就会促使在未来类似系统的开发中也使用这些技巧。另一方面’如 果采用了某个构架但没有成功，至少在短期内不大可能再采用该构架。

 

(5)一些典型的系统会影响并实际改变软件工程的发展，也就是系统开发人员学习 和实践的技术环境。在20世纪60屯代和70年代初，最早的关系数据库、编译器生成程 序和基于表格的操作系统就起到了这种作用。％世纪80年代的软件开发则明显受到最早 的电子表格和窗口系统的影响。到20世纪90年代就是万维网了.第13章讲述了关于万 维网的案例分析。在21世纪的前十几年，产生影响的可能就J2EE 了，第16章将对其 进行讨论。这些先驱性系统的开发必然会影响到以后的系统

 

上述以及其他反馈机制构成我们所称的商业周期：图1-4所示的构架商业周期向 我们展示了开发组织的业务和文化对软件构架的影响。而构架反过来又成为影响所幵发系 统各方而厲性的决定性因素。但我们也应当认识到，构架商业周期还与精明的开发组织利 用幵发构架时所做的组织上的或技术经验上的效应有关，这些组织通常会适当调整企业经 费策略，以适应未来项目的开发。

 

1.2软件过程和构架商业周期

 

我们把对软件幵发活动的组织、规范和管理称为软件过程。在创建软件构架’使用该 构架实现设计，然后实现或管理目标系统或应用软件的演变的过程中，涉及到哪些活动？ 这些活动包括：

 

•为系统构建一个商业案例

 

•理解系统黹求

 

•创建或选择构架

 

•将构架编成文档，并与有关各方进行交流

 

•对此构架进行分析和评价 

•根据此构架实现系统

 

• 保证系统实现符合构架的要求

 

构架活动

 

就像构架商业周期的结构所显示的那样，这些活动之间存在着复杂的反馈关系。下面 我们就对这些活动逐一进行简单介绍。

 

为系统创建商业案例。创建商业案例的含义要比简单地评估某个系统的市场需求广泛 得多。这是创建并限制任何未来需求的重要一步。该软件系统定价将会是多少？其H标市 场是什么？预期于什么时间正式推出？是否需要与其他系统连接的接口？有什么必须要 遵从的限制条件？

 

上述问题的解决必须要有系统设计师的参与，当然这些决策不能仅靠设计师来制定， 但如果在创建商业案例的过程中没有设计师的参与.将无法实现这些商业目标。

 

理解需求。可以使用很多技巧获取涉众的需求。例如，在面向对象的分析中，可以使 用场景或“用例”来表达对系统的黹求。特别强调安全性的系统则使用诸如有限状态机模型或形式描述语言等更为严格的方法。第4章（理解质最属性）将介绍支持捕获系统质量需求的质量属性场景的集合。

 

关于某个待幵发系统的一个基本决策是该系统与某个已开发的系统之间有多大的相 似性。现在开发的任何一个系统儿乎都和某些已有系统相似，所以，要真正:理解系统需求， 就得先了解这些已有系统的特性.第14章（软件产品线：重用构架资产）讨论了产品线的构架含义。

 

创建原型是另一种有助于理解系统需求的有效方法。原型有助于对所期望的行为进行建模，有助于设计用户接口或分析资源使用情况。这可以使涉众对所开发的系统及早有 个“真实”的体验.从而促使很快做出关于系统的设计和其用户接口设计的决策。

 

在获取系统滞求时无论采用什么技巧，所要开发系统的期望的质量厲性都会确定其构 架的形状。设计师长期以来一直使用具体的战术来实现特定的质量厲性。第5章（实现质量属性）对其中的许多战术进行了讨论。构架设计包含了许多权衡，在指定需求时，并不 是所有这些权衡都是明显的。直到创建了构架后需求中的某些权衡才会变得明显，并迫使 确定出需求优先级。

 

创建或选择构架。在里程碑式的书籍《人月神话》中，Fred Brooks以令人信服的论证 淸楚地阐明：概念完整性是成功设计系统的关键，而只有通过以小组的形式共同设计系统 构架才能真正实现概念完整性。第5章（实现质煙属性）和第7章（设计构架）阐述了如 何创建构架.以实现其行为和质量滞求。

 

构架的交流..耍使构架真正成为系统设计的砥柱，就必须向与构架有关的所有涉众清 楚而准确地衣述构架。开发人员必须理解构架对他们的要求，测试人员必须淸楚自己所面 临的任务，管理层必须明确构架要求做出什么样的规划。为此.构架文档的信息必须丰富、 确切淸楚.要保证具有不同教育背景的相关人员都能理解。第9萆将讨论构架编档。

 

构架的分析和评价。在任何设计过程中都会有多个候选的设计方案。可以很快就否决 一些方案，然后对另外的方案进行仔细分析和权衡，选择出最合适的一个。以一种合理的 方式在这些方案中进行选择是设计师所面临的最大挑战之一。第3部分（分析构架）中的 章节对做出此类决策的方法进行了描述。

 

针对构架所支持的质量属性对构架进行评估对于确保采用该构架构造的系统满足了 其涉众的需要是基本的。现在，广泛使用的一种分析方法是对构架给予系统的质量属性进 行评估。基于场景的技巧提供了对构架进行评估的一个最有效也是最通用的方法。第11 萆讲述的构架权衡分析方法（ATAM)是最为成熟的一个评估方法，笫12章讲述的成木收 益分析方法（CBAM)说明了如何以经济的方式开发构架。

 

实现基于该构架的系统。这个阶段的主要任务是，保证开发人员在实际开发中忠实于 构架所规定的结构.遵守关于各部分之间交互的约定。表述淸楚并为各方所理解的构架是 保证实际设计与构架一致的首要条件。如果能有-个帮助设计人员创建并维护构架的环境 或基础结构.这一阶段的工作就会做得更好。

 

使构架符合原来的表述„最后,当构架己经创建完毕并投入使用时，幵发工作就进入 了维护阶段。在这-阶段，要始终保持淸醒的头脑，以保证构架符合原来的表述。尽管在 这个领域的工作还不成熟，但近些年来，该领域己明显活跃起来。第10章（软件构架重 构）表述了从现有系统中恢复构架，并确保它符合指定构架的当前状况。

 

1.3什么样的构架才算好

 

给出某个系统的相同技术需求，来自小'同开发组织的两个设计师将会给出两个完全不 同的构架，如何判定其中哪-个更合适呢？

 

构架并不是注定是好的或是坏的。各种构架总是能够或多或少地满足某些系统的要 求。一个分布式的、搖于客户机/服务器模式的3层构架可能刚好能够满足某大型企业财务管理系统的要求，但如果将这个构架应用于航空电子系统就完全错误了。如果希望得到的 仅是-个临时性的原型，则为实现优良的可修改性而精心设计的构架可能毫无意义。我们 可以对构架进行评估——这也是我们为什么要关心构架的原因之-——但必须要在针对 某些特定目标的情况下进行这种评估。这也是本书所要表达的观点之。

 

但是，在设计构架时必须遵循一些实践准则。当然，忽视某一条准则并不一定意味着

设计的构架将有致命的缺陷，但至少应当把准则当作-个警示，进行相皮的研究分析。

 

我们把从软件开发中所得到的经验分为两大类：关于过程的建议和关于产品（或结构） 的建议。我们所提出的关于过程的建议主要有如下几条：

 

•构架的设计应该由一位设计师来完成，或者由-个在某位设计师领导下的小组来 完成。

 

•设计师（成构架小组〉应全面掌握系统的功能需求，并且应有一份所设计构架应 满足的划分了优先级的质量属性列表（如安全性或可修改性〉

 

•构架的文裆应该完备，至少应有一个静态视图和-个动态视图（在第2 讲述）， 应该采用所有人员认可的文档形式，以保证所有涉众都能很袢易地理解这些文档。

 

•应该把构架设计方案交由各涉众传阅，应该让各涉众积极参与设计方案的评审。

 

• 应该对构架认真进行分析，得出可应用的量化度量指标（如最大吞吐量）。也应该 对质量属性进行正式评估，以避免出现发现问题时为时已晚的情况。

 

• 构架的设计应有助于增量式实现。为此，可先创建个粗略的、具备雏形但功能 最简单的系统.通过把这个骨架系统逐步细化、扩大来得到所期望的系统。这种 做法可简化集成和测试的工作（参见7.4节）

 

•允许构架带来一定的（少量的）资源争用.但应淸楚地给出这些资源争用的解决 方案，告之于有关各方，并保证这些解决方案切实可行。例如.若网络占用是要 考虑的问题，设计师就要为每个开发小组制定出将网络占用减少到最低限度的指 导原则，并保证这些原则得以贯彻。如果系统性能是所考虑的主要问题.设计师 就要为各主要线程规定出执行时间的限制，并保证在实现中切实达到该要求。

 

我们所提出的关于结构的建议主要有如下几条：

 

•构架应采用定义良好的模块，各模块的功能责任划分应基于信息隐藏和相互独立 的原则。信息隐藏模块应该包括那些封装了计算基础结构特性的模块，以将大部 分软件与计箅基础结构的变化隔离幵。

 

•应该使用特定于毎个厲性的众所周知的构架战术来实现质量厲性，如第5章（实 现质殷属性）所述。

 

•构架绝对不可以依赖于某个特定版本的商业产品或工具。如果确实依赖于某个商 业产品，则嬰合理设计构架，使得当所依赖的商业产品发生变化时，能够方便、 经济地适应。

 

•应将产生数据的模块和使用数据的模块分离开。未来的变化往往仅限于数据的产 生或数据的使用，所以，这样做一般可以提高系统的可修改性。如果系统中需要 添加新数据，则这两个部分都耍做相应的修改，但如果这两个部分是相互独立的，就可以对系统进行分阶段逐步（增量式）升级。

 

•对于并行处理系统，构架应该采用定义良好的进程或任务，它们未必反映模块分 解结构。也就是说，有些进程的运行涉及到若干个模块.而模块中的某个过程可 能也要为若干个进程所调用（第3章的A-7E案例分析是采用该原则的一个示例)。

 

•每个任务或进程的编写都要考虑到与特定处理器的关系.并保证（甚至在运行时） 能够方便地改变这种关系。

 

•构架应该采用少量的、简单的交互模式（参见第5章)。即在整个运行过程中，系 统的功能应保持一致。这可使系统易于理解，有助于缩短开发时间、提高可靠性、 增强可修改性。它还应该展示构架中的概念完整性——虽然无法度量，但却有利 于系统开发的顺利进行。

 

本书给出的毎个案例都成功解决了一个极富挑战性的构架主题,，在分析这些案例时， 要注意在各种情况下是如何遵从这些实践准则的。虽然这里给出的准则并不完整.也不是 绝对应该遵循的，但对想要提高构架设计技巧的设计师来说，可以将其作为指导原则。

 

1.4小 结

 

本章明确了构架不仅仅是系统功能需求的结果。它同样受到设计师的素质、所处的技术环境、出资方的商业目标等因素的影响。构架的成功开发又丰富了技术内容，为公司提 供了新的商机，所以，构架反过来也影响着开发环境。我们提出了构架商业周期的概念， 并将其作为本书的核心内容。但读者应当明确地认识到：本章仅简单给出了构架商业周期 的概念.在后续章节中还将做进一步的阐述。

 

在本章的最后.我们提出了一组实践准则。一般地，遵循这些准则才能设计出完美的 构架.而忽视这些准则只能带来危害。

 

下-章开始讲述关于软件构架的内容。

 

1.5讨论题

 

(1)您所在的开发组织的类型是如何影响所开发的构架的？这些构架又是如何影响组 织类型的？

 

(2)您所在的组织在创建软件构架时，（曾经）受到过什么样的商业目标的影响？

 

(3)您所在的组织在设计软件系统的构架时，哪些涉众的影响坡大？他们的目标是什 么？他们的目标是否冲突？