提供高效的帮助和引导。具体而言，架构师的工作内容主要包括:
♦冷静和系统地平衡功能与性能的要求，分析软件系统盾量的要求和其他系统特征。
#控制和处理有关系统粒度、范围、包含、连接和耦合的问題。
澄清接口策略，制定接口架构约束原則。
^计划系统资源分配与调度原则。
•稳定业务关系模型（实体、关系、协同动作)。
制定系统身份识别、认证、命名、存取控制的策略。
规划系统静态特征和动态行为转化模型。
确立系统级的基础框架组成，穗定架构基线。
按照外界环境与内在制约因素选择相应的开发流程，规划开发环境、开发工具、测 试工具、版本控制工具等。
确定监控与报告流程，选择有效的汇总、统计、分析、报告工具。
为软件设计与开发制定架构约束及架构原则，并确保后续的开发遵守了这些原则。 软件系统许可证/软件key的规划及策略。
软件系统的部署、初始化、装栽顺序、卸栽顺序、运行监控等系统运行时的规划。
软件系统测试、交付的原则及计划。
按照外界环境与内在制约因素选择相应的开发技术。
规划软件系统哪些部分自主开发，哪些部分外包开发或外购产品。
从上述这些工作来看，有些是针对商业方面的问题，这些问题是核心问题，也是架构 师的目标。还有些问题是专门针对系统级别方面的，有些则是针对技术方面的问题。我们 可以把这些问题整合归类为如下一些方面，如图3-1所示。
.png)
■ 3.1解决商业问题
我们先来看看如何解决商业方面的问题。架构师要从诸多Stakeholders那里汇总杂乱 无章的信息，这些信息包括整体商业目标、整个商业运作模型、商业运作规则、商业运作 信息交换规则、商业组织内部结构、商业组织与外部机构的联系、软件系统部署及关联要 求、软件系统功能要求、性能的要求、安全的要求、容错的要求、异常处理的要求、系统 自我恢复的要求、数据或信息交互的标准、商业活动流程、流程角色、人员职责等。客观 地讲，针对如此多的信息，没有一种理想的工具或手段来正式地、一丝不苟地记录、汇总、 分析这些问题，更没有什么智能化的工具帮助架构师从中自动产生软件系统的架构。
但是，依然有一些办法可以有效地帮助架构师系统化地组织上面这些重要信息，这就 需要引入“商业概念模型”（Business Concept Model)这种有效分析和建模手段。一个有 效的商业分析模型，有助于架构师理解整个商业问题，建立一个软件系统存活的最高层面 的大背景，并且详细记录和分析模型中各个元素及元素间的关系。
这远不是画几个用例（Use Case)就能解决的问题。举一个生活中的例子，当我们要 做一个台球的模拟软件系统时，如果用“击球手用球杆击打黑色的母球，使黑色母球达到 一定的速度并且朝着一个红色的子球方向滚动。当母球以特定的角度撞击了子球后，子球 向洞口方向以一定的速度滚动，最终子球落进了球桌边的球洞中Z这样的Use-Case来描 述这些表面的特征，恐怕很难让架构人员成功地构建出你所希望的台球模拟软件。我们必 须深入分析商业背后的那些模糊的、界定不淸、关系不明的深层次原因’从而完全清晰地 了解商业存在的问题，并且尽量将问题简化。
我们以美国国防部为例，来讲述“商业概念模型”的作用。图3-2是美国国防部为了 构建海军作战管理系统而创建的一张最高层面的概念模型图。
图3-2虽然只是一个最抽象的、并且是最高层面的概念模型图，但是清晰地描述了完 整的海军作战模型。例如精准地表述了有哪些参战单位、各参战单位的工作边界、部署位 置、组织协同关系、工作依赖关系、通信方式、活动、工作次序以及活动的时序关系等。 更重要的是以动态的方式表达了上述重要信息，即高质量的“商业模型”所具有的一个明 显的特征是该模型具备动态表述能力。
当然，为了实现完整而一丝不苟的建模风格，配合这张作战模型图的其他各项子图就 有几十张之多，而且都属于抽象层面的图。可以想象，其他细节的模型图就更数不胜数。 这样精致的“商业概念模型”，当然保证了系统架构构建的完整性、正确性和高质量。需要 强调的一点是，正如一位架构界的巨人说过的“It is important to remember that a concept model is a human artifact”，即“商业概念模型是人类智慧的结晶' 模型中包含了大量对 问题的理解、思考、权衡等非工程化因素。所以目前还没有什么完整的软件工具集或者软 件建模语言可以完全替代这种经验性的分析活动。
虽然说“商业概念模型”的构建是一项典型的经验型分析活动，但是人们已经开始逐 渐将商业概念建模的以往经验进行了总结。这些总结出来的经典商业经验已经被越来越多
3.2解决架构问题
商业概念模型的准确确立，为软件架构师进入软件系统架构阶段的工作做好了良好的 铺垫。接着，架构师就开始着手解决系统级方面的问题，即“系统架构构建”。从本节开始 所列举出的系统级问题中，我们就能看到架构师要面对功能方面、质量方面、系统灵活性、 系统演化等诸多问题。那么工作在这个阶段的架构师可以利用怎样的手段，才能圆满地完 成这些有挑战性的任务呢？
还是用一个实际工程中的例子来看看现实中大规模复杂系统在进入解决系统级问题时 所采用的办法。我们还是以美国国防部构建海军作战管理系统为例，看看他们制定的系统 级问题解决手段的指导说明，如表3-1所示。
表3-1系统级问题解决手段的指导说明（部分）
.png)
.png)
.png)
我们能够注意到，美国国防部这样的官方机构，
并没有在系统问题解决指导说明里给 出很多空洞的、
让人摸不着边际的废话，
而是非常明确地给出了实际可参考的具体问题解 决
手段——“架构棋式”（Architecture Pattern)的使用指导说明。
那么到底什么是“架构模式” ？ “架构模式”又有什么样的作用呢？
我们可以引用这 方面的权威Frank Buschmann和Michael Stal的著名论述来进行说明。
“一个架构模式表达了一个软件系统基本的组织结构方式或系统构成方式。
该架构模式帮助界定了子系统的组成，指定了各子系统的职责，并且包括了组织各子系统间
关联关系的规則或指南”。
如果我们查询美国国防部海军作战管理系统中界定的系统问题解决指导说明，
我们就 能看到很多架构模式，
这些也是典型的架构模式（有时也叫“架构风格”，即Architecture
Style)(作者注：本书重点不是进行架构模式的讨论。有关架构模式的详细研究，
请参见 《架构之美》系列丛书之《设计模式的艺术》)
•客户端-服务器架构风格
•分布式计算风格
对等计算架构风格
黑板架构风格
•隐式调用架构风格
Pipes and filters 架构风格
插件架构风格
整体化架构风格（Monolithic application)
三层架构风格
结构化的风格（基于模块化）
系统构件（Component)化风格（基于模块化的系统构建，每个模块内结合面向对 象的编程技术）
面向服务的架构风格（SOA、SCA)
Search-oriented 架构风格
基于空间的架构风格（Space based architecture style)
Shared nothing架构风格（应用程序没有自己的数据缓存，数据完全依赖对數据库的存取）
从上述这些实际工程中应用的架构模式，我们可以看到，这些架构模式无一例外地能 够为系统级构建阶段提供有力的参考手段，精准地满足了 “架构模式”的经典定义，成为 后人构建新系统时可以借鉴前人问题解决经验的一个重要渠道。
当整个系统架构构建完全稳定下来之后，整个系统的构建工作就进入了下一个重要的 阶段一“子系统级和构件级的设计阶段”。这个阶段主要解决的问题包括：
•子系统内部如何组成、如何工作的设计。
各个子系统是如何进行交互或通信的设计。
每个构件内部如何组成、如何工作的设计。
各个构件是如何进行交互或通信的设计。
可以看到，我们已经开始从先前大量使用“架构”一词，开始转换使用一些“设计” 这样的词汇来进行描述。需要澄清的一点是，在计算机工程与科学行业中，严格来讲，“系 统架构”（System Architecture)与“系统设计”（System Design)是完全不同的两个词。 它们针对的系统层面大不相同，要处理的问题也完全不一样，问题的解决方案对系统或应 用影响的'氾围也完全不一样。为了严格区分这样两个概念的差异与联系，Amnon H. Eden 和Rick Kazman在2003年的研究著作《架构、设计、实施》中进行了很好的剖析，提出 著名的Intension与Locality评价区分标准，就是从系统的不同层面、不同层面所需应对的 问题、问题的解决方案对系统或应用影响的范围这3个方面来进行区分。
3.3解决设计问题
为了看看现实工程中的真实设计工作，我们可以查阅美国国防部为开发海军作战管理 系统而制定的设计问题指导说明，它与先前提到的系统级问题解决手段的指导说明完全不 同（即包含了一些架构模式，但大量的是设计模式），如表3-2所示.
表3-2美国国防部设计问題指导说明（部分)
设计指导
|
设计模式名称
|
作用说明
|
|
Facade
|
Provide a unified interface to a set of interfaces In a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
|
|
Leader- Follower
|
Provides an efficient concurrency model where multiple threads take turns sharing a set oT event sources in order to (tetect, demultiplex, dtepatch, and process service requests that occur on these event sources..
|
|
Command
Processor
|
Separates the request for a service from Hs execution, manages requests as separate objects, schedules their execution, and provides addltkxiaJ services, e.g.. storing request objects for a later undo.
|
|
Fonwarder-Receiver
|
Provide transparent interprocess communication for soflwaro systems with a peer-tc>peer interaction model. Forwarders and receiverB decouple peers from the underlying communication mechanisms.
|
|
Publisher-Subscriber
|
Keep the state of cooperating components synchronized by enabling one-way propagation of changes. One publisher notifies any number of subscribers about changes to its state
|
续表
|
设计指导
|
|
|
设计模式名称
|
作用说明
|
|
Whole-Part
|
An aggregate component (the whole) encapsulates constituent components (the parts), organizes their collaboration, and provides a common interface to the functionality. Direct access to the parts is not allowed.
|
|
Maste 卜 Slave
|
Handle computation of replicated services in a system to achieve fault tolerance and robustness. Separate independent slave components that together provide the same service to a master component, which is responsible for invoking them and for selecting a result. Clients communicate only with the master functions (subsystems).
|
从这些具有明确实践意义的设计指导说明中，我们能够清晰地看出美国国防部在自己 各项软件系统设计阶段的活动中，力图进行设计活动的强制约束，即通过大量使用“设计 棋式”来保证设计阶段出现的问题能够得到高质量的解决。
可以这么说，这些设计阶段的问题，早已不是第一次出现在人类软件工程的设计阶段。 在先前其他各种系统设计的实践设计活动中，为了高质量地解决上面这些问题，前人已总 结出了很多实践手段，我们当然要参照前人的工程设计经验，即“设计糢式”（Design Pattern )o
那么什么是“设计棋式” ？ “设计模式”又有什么样的作用呢？我们还是引用这方面 的权威Frank Buschmann和Michael Stal的著名论述来说明。
“一个设计模式提供了构造和优化一个子系统内部结构或一个构件内部结构的参 I考框架。同时也是一个构造和优化构件间关系的参考框架。设计模式表述了在一种特 I定的场景下，为了解决设计时反复出现的有关构件设计和构件间交互这些设计问題而 :可以参考的通用经验实践。”
只要提及“设计模式”，我们就一定会想到Gang of Four经典的23个设计模式。Gang of Four开创了提炼和总结设计实践经验的先河，而后人在这个研究方向上进行了大量的实 践和总结（作者注：本书重点不是进行设计模式的讨论。有关设计模式的详细研究，请参见《架构之美》系列丛书之《设计模式的艺术》)，基于设计经验提炼出了多种设计模式。
分布式基础框架模式-例如Broker
应用基础框架模式-例如 Presentation-Abstraction-Control
构件组合模式-例如Half-Object plus Protocol
并发问題设计模式-例如Half-Sync/Half-Asyr»c
同步问题设计模式-例如Thread-Safe Interface
事件处理设计模式-如Acceptor-Connector
结构灵治性设计模式-例如Wrapper Fagade
构件交互设计模式-例如Chain of Responsibility
构件行为设计模式-例如Objects for States
资源管理设计模式-例如Cashing
创建与撤销设计模式-例如Builder
行业设计模式-例如电信行业（Dennis L DeBailer的实践经验）、公司财务 (Martin Fowler的实践经验)、航空工业（Doug Lea的实践经验)等设计模式
回到现实的软件工程行业，我们可以来看看IT行业的巨头旧M公司为电子商务系自 的设计所界定的设计模式类型。
商业设计模式-这些设计模式用来识别商业麥与者，帮助界定在不同的商业场景下他们之间的交互关系。
•集成设计模式——这些设计模式将各个商业设计模式集成为一体，形成统一的商北 解决方案，并且识别了商业问題、商业流程和规則。
组合设计模式一这些设计模式帮助准确地识别商业模式与集成模式的选用条件和组合形式。
应用设计模式一个商业和集成模式可以被一个或多个应用模式来实现，一个应用 设计模式代表了应用的粗粒度的结构，例如主要构件的组成、处理功能的分布、數 据的部署等
运行时设计模式一应用设计模型可以被很多运行时设计模式来实现，但是这些运 行时设计模式主要用来保障质量方面的要求，例如性能、容量、有效性等。
无论是IBM这样的IT公司，或者是美国国防部这样的国家权力机构，还是软件设计 行业的权威专家，也无论它们以怎样的分类原则对设计模式进行分类，从上述设计模式的 实质就可以看出，具有丰富工程经验的设计人员己经在很多方面的系统设计中进行了总结。 我们可以引用出自Siemens公司的一句经典用语来说明设计模式的目的：“提炼经驗、尽 量复用、加速设计、保证设计质量。”当然，作为一个合格的设计人员，掌握设计模式这样 的设计手段是必备的条件。
3.4解决编码实际问题
在软件系统的开发过程中，无论前期在系统架构的构建上如何成功，在子系统和构件 的设计上如何经典，如果在系统编码实施上不能采用一些有效的手段，再好的架构和设计 也不能实现最终的目标。这就要求架构和设计人员借用一些手段来帮助和指导编码实施阶 段的工作。进入实施阶段的软件系统，已经在架构和设计方面完全稳定了下来，软件系统的问题主要转向了技术方面。
同样，我们可以先来看看美国国防部为开发海军作战管理系统而制定的实施技术机制指导说明（部分)。
Error Handling, Exception Handling, Logging.
Process, Tasks, Threads.
Configuration Management, Packages, Components, Files, Objects, Modules, Interfaces.
Signaling, Messaging, Call Back scheduling, Notification, Active Data, Watchdogs, Time-outs.
Locking, Semaphores, Transactions, Checkpoints, Deadlock Detection, Role Back.
Identification, Naming, Data Model, Registry, Configuration Database, Inheritance, Scoping.
Resource Management, Allocation, Fragmentation Prevention, Garbage Collection. Persistence, Caching, Versioning, Prefetching, Lazy Evaluation.
Bootstrap, Discovery, Negotiation.
Call graphs, message tracing, object tracing.
Distribution, Allocation, Transparancy;
Component, Client / Server, Multitier model.
可以试想，架构师或者设计人员如果在上述技术层面没有过深入的实践经验，就无法 正确地沟通和配合编码实现人员的开发工作。幸好，技术层面也同样有一些经典的经验可 以借鉴——“IDIOM设计棋式”。
什么是IDIOM?其作用又是怎样的呢？设计模式大师Frank Buschmann和Michael Stal做过这样的论述。
“一个IDIOM!设计模式是与某种编程语言（供知：C++)密切结合的一种低晨次 的设计模式。一个丨DIOM可以華助我们实现一个构件内特定的某方面的功能，或者帮助实现构件间特定的关系。当然，这是由于那种编程语言具有的特性所决定的这种能力。”
简单地说，熟练使用一些编程语言的开发人员，对编程语言使用的实践，使他们总结 出了一些编程语言的使用技巧。当然，这些技巧与某种编程语言是紧密结合的，如果你想 在其他编程语言中使用同样的技巧，有时就做不到。举例来说，C++面向对象编程肘，一 个C++Object会获取一个Object外的资源，但是我们经常只牢记了获取和使用资源，通 常忘记了资源的释放，这就会造成应用系统资源方面的死锁。那么我们可以利用C++语言 中Object销毁时的特点，有意识地在析构方法中加入资源释放代码。这样，当Object被 销毁时，C++就会自动调用析构函数，从而也就自动地执行了资源释放的动作。
与设计模式相同，有经验的编程人员通过自己长年的编程实践，已经提炼出了大量编 程语言的 “IDIOM 设计模式”，其中有 James 0. Coplien 的 C++、Doug Lea 的 Java、Kent Beck的SmallTalk等（作者注：本书重点不是进行丨DIOM设计模式的讨论。有关设计模 式的详细研究，请参见《架构之美》系列丛书之《设计模式的艺术》)。一些IDIOM设计模 式所涉及的方面包括：
内存管理与参数/引用：例如 ResourceReleases、lmmutableCollection。
对象创建与初始化：例如 EncapsulateMultiStageConstruction、ParameterClasses。
枚举与集合：例如 UseEnumerationsNotForLoops、FlyweightEnum
接口应用：例如 Maskinglnterfaces、丨mmutable丨nterface。
异常处理：例如 DontThrowGenericExceptions、BouncerPattem。
并发处理：例如 PrivateMutex、ValueObjectsShouldBelmmutabfe
类型安全：例如 BuildlnterfacelmplementationPairs、Rangedlnt。
性能处理：例如 CheckDontCatch、BetterForLoopConstruct。
文档和注释：例如FixmeComment。
到了系统编码实施阶段，我们己经带领大家走完了系统构建的重要阶段（当然，还有 单元测试、集成测试、系统测试、系统交付等阶段，这些不是本书讨论的重点）。我们跨过 了模型建立、系统架构、系统设计、实现编程等阶段，看到了不同阶段架构师和设计人员 可以借鉴和参考的手段。总结如下：
概念摸型与分析模型帮助架构师捕获商业结构、商业流程及商业规則。
架构摸式帮助架构师定义软件系统和各子系统的结构骨架。
设计摸式帮助设计人员构建构件（Component)结构及其联系。
D丨0M设计禊式这种底层经验能够确保编程实现的质量。
3.6运用架构框架及工具
除了沟通这种有效的架构手段，“架构框架（Architecture Framework)及工具”也是 一种帮助架构师完成工作的非常有效的手段。每当提及架构框架(有时也叫架构参考模型)， 我们可能马上联想到目前那些流行的框架,例如Sun公司J2EE框架、Microsoft公司的.NET 框架、OSGI联盟的OSG丨框架等。但是，我们这里介绍的不是这些应用幵发框架或其他 应用开发平台，而是专门进行架构构建的框架体系。那么什么是“架构框架”呢？ “架构框架”到底有怎样的作用和意义呢？
在回答这些问题之前，我们不得不先来介绍一下具有里程碑意义的ANSI/IEEE联合制 定的著名的 ANSI/IEEE 1471-2000 标准：IEEE STD 1471-2000, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems。按照 IEEE 的描述， 1471-2000标准主要提供了一些重要的参考实践，以便架构人员可以借鉴这种实践来开发 那些以一系列密集软件功能为支撑的系统。ANSI/IEEE 1471-2000标准是以所谓的“架构 描述（Architecture Description)”来记录这种类型系统的商业分析、架构构建等活动。
所谓的“架构描述”是指以一种正式的方式来记录和描述准备构建的系统。这样的记 录和描述可以将系统的结构完整、精确地表述出来。因为架构描述要求记录系统内有哪些 角色、子系统或构件、流程、数据依赖，以及这些系统组成部分之间如何进行交互和相互 依赖，这样就组成了一个完整的架构体系结构。只有运用了这种正式、清晰的架构描述， 才能方便管理层进行开发或外购的决策，才能使管理层淸楚自己的IT投资是否满足了苴商业目标。同样，系统实施人员也能淸楚自己设计和实现的目标。
受到ANSI/旧EE 1471-2000的启发和推动，很多机构和公司开始运用架构描述这样的 手段，制定和开发自己的“架构框架”。他们不约而同地将自己的架构框架的目标定位如下:
架构框架会简化和加速软件系统架构的构建，并且要确保架构方案和设计方案记录
的完整性。同时，所选择的架构方案和设计方案还要满足商北发展所带来的扩展演 化要求。
架构框架要提供一套工具，这样.的工具可以满足各种不同类型系统开发的要求。.
架构框架要提供一种采用这套工具的方法论或流程，这样的方法论或流程能够严格 界定各种类型软件系统的内部结构组成。
架构框架可以清晰地表述系统环境内各个元素间的有序关系。
架构框架要维护一套通用的词汇表，以便于沟通。
架构框架尽可能列举一些参考标准和实践经验示例。
架构框架要包含实现系统内各构件的产品列表或者替代实现手段。
为了实现上述目标，一些公司参照了 ANSI/旧EE 1471-2000标准，制定出一些有实践 参考意义的架构框架，并且在公司或机构范围内推行应用。其中比较著名的有：
RM-ODP ( Reference Model of Open Distributed Processing) Catalysis
TOGAF (The Open Group Architectural Framework)
ZIFA (Zachman Institute for Framework Advancement)
EA ( Federal Enterprise Architecture )
MODAF
DODAF
很明显，这些公司或机构就是借用架构框架作为自己重要的管理和技术手段，实现自 己在大规模软件系统开发时的风险管理。当然从表面上来看，这些公司或机构大规模应用 这种架构框架是要付出巨大的代价，例如会花费大量的时间、精力、金钱，而且让各个管 理层及技术层都要接受这样的巨变也有高昂的代价但是一旦经历过一次这样痛苦的蜕变， 整个经验就得到了积累，并且也沉淀了很多可复用的基础，以后的实施就会变得容易并且 付出的代价急剧降低。尤其对面向产品线开发的企业来讲，这种优点就更加显现了出来n
如果我们是一个中小型企业或机构，无论是从财力的保障、市场要求的反应速度，还 是从公司的组织结构来看，虽然完整地实施一套架构框架不一定具备条件，难道就不能借 用ANSI/IEEE 1471-2000标准这样的实践参考吗？答案当然是可以。一定程度上通过对一 些经典架构框架进行适当的裁减和借用，同时配合使用一些性价比适中的架构工具，就完 全可以满足中小型企业或机构的需求。比较有名的架构工具有：
ARTiSAN Software Tools Studio
Casewise Extension
ARIS Defense Solution
Rational Rose
MagicDraw plugin
System Architect
netViz DoDAF
Proforma Provision Enterprise Pro
ACART - DoD EA Systems Compliance Assessment Solution Telelogic
Troux Technologies
Vitech Corporation
Wizdom DoDAFLive
Enterprise Elements Repository
综上所述，我们己经全面完整地看到，平时工作中的架构师可以采用的一套完整的、 经过实践检验过的有效手段，如图3-3所示。
.png)
这样的一套方法，需要架构师持续不懈地在软件系统生产的整个阶段里进行选择和运 用。其中有些是人类软件工程中的最佳实践，例如一系列架构风格、设计模式，这需要架 构师有着非常强的实践经验，才能将前人的经验恰当地运用到自己的架构活动中。还有一 些弹性较强的实用工具有助于架构师的日常工作，例如各种沟通技巧。无论是怎样的知识、 工具、手段，都要求架构师在自己日常的工作中，慢慢地积累实战经验，只有这样才能 真正应对大规模系统所带来的高复杂性，从而系统性地降低由于天真和缺乏经验所带来 的风险。