伟大架构师的秘密
发布日期： 10/13/2004 | 更新日期： 10/13/2004
By Don Awalt and Rick McUmber
RDA Corporation
摘要：所有伟大的架构师都掌握了在抽象的不同层次上概念化解决方案的技能。通过将解决方案组织到离散的层次，架构师可以专注于解决方案的单个方面而忽略所有剩余的复杂性。展示将抽象层次应用到 IT 解决方案的技术，并将其与其他工程学科相比较。
本页内容
将抽象层次应用到 IT 解决方案
企业架构师正受到其所面临的大量复杂性的挑战。开发一个能够自动处理企业任务的独立的部门应用程序是一回事。而设计并组成一个支持上万 IT 使用者的满是应用程序、服务器和数据库（全都支持多种企业活动）的 IT 实验室全球网络，则完全是另外一回事。要组合这些复杂性，IT 网络必须随时可用、响应迅速并保护企业宝贵的信息资产。除所有这些之外，IT 网络还必须足够灵活以支持企业永远变化的需要，并且采用出现的新技术。
一些架构师在这种复杂性方面明显非常出色，而且在不断进步。在我们的职业生涯中，能与一些真正伟大的分析师和架构师并肩工作是非常幸运的。反思这些经验，我们已经分析出是什么造就了杰出的架构师。
无一例外，所有伟大的架构师都掌握了在截然不同的抽象层次上概念化解决方案的技能。通过将解决方案组织到离散的层次，架构师可以将精力集中在解决方案的单个方面而忽略所有剩余的复杂性。他们一旦稳定了解决方案的某个部分，接下来就能继续处理其他方面，从而不断地将层次发展并完善到最终可以被实现的粘合模型中。
大多数软件开发人员懂得应该将解决方案分解到抽象层次。但是在实际的项目中，这是非常难于付诸实践的。当遇到第一个困难时，在急于开始编码时是很容易放弃这些层次的。伟大的架构师会经受这些挑战并在整个项目的生命周期中严格保持这些层次。他们意识到，如果不这样做，最终将淹没在复杂性中。
本文展示了将抽象层次应用到 IT 解决方案的技术。首先，我们会通过一个简单的示例演示此方法，然后提出一个基于正式抽象层次的系统产品的结构。
抽象层次：所有工程师的强大武器
其他的工程学科，比如土木工程师，几个世纪以来一直利用抽象层次复制复杂性。让我们学习一下其他更成熟的工程学科是如何应用抽象层次的，就从电子工程师开始吧，他们设计每次更新换代都变得更加复杂的计算机系统。
硬件工程师
系统设计师使用抽象层次为计算机系统建模。每个层次都是定义完善的，并提供了该系统的一个不同角度。许多系统是在三个主要层次上设计的：系统、子系统和组件，如图 1 所示。
分层使工程师能够将庞大数量的复杂性集成到一个单一的工作计算机系统中。在其原子部分的层次上确切了解一台计算机是不可能的。在单独一块 Intel Itanium_ 芯片上有大约 25,000,000 个晶体管。
对 IT 相关学科来说，这种把复杂性分解到抽象层的方法当然不是惟一的。类似的方法被用于从航空工程到微生物学的无数其他学科。
应用抽象层次时的核心原则
所有工程师在应用抽象层次时都遵循这套核心原则。当把抽象层次应用到软件时，这些原则也同样适用。
这些层次的数量和范围是定义完善的，以便工程师能够在复杂的系统上协作，所有团队成员必须共享对层次的同一理解。只要设计师做出设计决定，他们必须将那些决定归档到相应的细节层次。
三个抽象层次定义如下：
图 i. 定义的三个抽象层次
图 ii.抽象层次的一个简单框架
每个层次内的多个视图
一个单个层次内的复杂性可以变得非常多，以至于使人无法一次全部掌握。在这种情况下，工程师通过多个视图将设计展现于单个层次内。每个视图展现设计的一个单独方面，但保持在相同的抽象层次上。举例来说，母板工程师为板的每个层创建一个视图，从而为每层的连接路径的设计建模。
图 1. 计算机系统的抽象层次
必须保持层次间的一致性
为了让系统按预期方式运行，每个后续的层必须是其父层的适当改进。如果计算机系统设计师从 IDE 总线切换到 SCSI 总线，那么所有设备的接口规范也必须切换到 SCSI。如果层次没有同步，那么系统就不会按预期方式在顶层执行。
将抽象层次应用到 IT 系统
既然我们已经分析了其他学科是如何应用抽象层次的，现在就让我们将此技术应用于 IT 解决方案1。下列部分展示了应用抽象层次为典型 IT 应用程序的需求、设计和实现建模的技术。这些技术是通过一个针对假想零售商的简单的、指导性的在线定单系统示例来展示的。在我们的示例中，我们不仅包括了体系结构，而且扩展了范围以包括系统需求和业务环境 — 如同由零售业所定义的。
简单框架：四个抽象层次
我们的简单示例定义 IT 解决方案的如下四个抽象层次：
•
域
•
业务处理
•
逻辑
•
物理
在每个层次内，我们既展示了该特定层次行为的动态视图，又展示了其静态视图。动态视图为对象之间的消息建模，而静态视图为对象之间的结构和关系建模。
域抽象层次
应用了上面的范围规则，零售商就会作为域层次中的黑盒子中心的演员。客户作为外部的演员。域层次是从客户的角度来建模的。只为购买交互建模。用于完成购买的通讯形式不包括在这个层次，但是会在业务处理层次引入。
图 2. 关于从零售商处购买物品的域层次动态视图
图 3. 关于从零售商处购买物品的域层次静态视图
动态视图
域层次内的动态视图为客户和零售商之间的交互建模。下图汇总了域环境，并包含了简单的业务交互使用案例描述。
图 4. 关于从零售商处购买物品的业务处理层次动态视图
静态视图
域层次的静态视图为类结构和在使用案例中出现的它们的对象的关系建模。换句话说，它说明了在这个抽象层次上，为了完成购买交易客户需要了解什么对象。 图 5 展示了域层次静态视图的类关系图。
图 5. 关于从零售商处购买物品的业务处理层次静态视图
客户是 Person 的实例。客户和零售商之间的关系被具体化为 Account。所有的 Purchase 都与客户的 Account 相关。Purchase 与每个被购买的 Item 相关。每个 Item 都与特定的 Product 相关，这里 Product 遵循元类模式。Product 的实例实际上本身就是类。将其他 Product 添加到 Catalog 完全是一个数据驱动过程，而且不会对类模型产生影响，因此将 Product 建模为一个元类会使我们的模型更加灵活。围绕这些类，每个 Payment 都与其 Purchase 相关。
如您可能看到的，这个层次的模型对大多数零售商（无论类型为在线或传统，大型或小型）来说是有代表性的。这说明了为什么 [Industry] 域模型确实应该将公司定义为黑盒子中心的演员。同一个行业中的公司倾向于支持带有其外部演员的同一套业务交互。此外，域模型排除了公司的特定业务处理，这是因为在同一行业中的公司之间它们会有相当大的变化。
域层次严格集中在从外部演员的角度看到的业务交互。对此我们必须注意，不要将用于完成交互的实现机制包括进来。这些细节属于下一个抽象层次。因此，在本例中，我们只为浏览、选择、购买和支付建模。我们不为如何完成这些交互（通过电话、美国邮政、电子邮件、Web 应用程序、亲自前往、支票、信用卡或现金）建模。
业务处理抽象层次
下一个抽象层次为公司的业务处理建模，以实现在域层次捕获的交互。系统层次“内部缩放”公司的黑盒子，并标识为完成业务交易而协作的所有员工和系统。在这个层次，要开发的系统作为黑盒子中心的演员。
应用了系统层次的范围规则，在线定单系统就作为黑盒子中心的演员。客户和员工作为外部演员。系统层次是从客户和员工的角度来建模的。客户在线执行购买。支付是通过信用卡完成的。通过将物品运送到客户的收货地址履行定单。出货通知是由电子邮件发送的。
动态视图
动态视图重演了域层次购买交易，这次公开了零售商的内部业务处理。图 4 汇总了业务处理环境，并包含了关于系统及其演员之间的交互的简单使用案例描述。
静态视图
这个层次的静态视图对类模型做了改进，以捕获在业务处理层次使用案例中出现的对象。换句话说，“为了在线创建一个定单并履行该定单，客户和雇员需要理解哪些对象？”图 5 展示了业务处理层次静态视图的类关系图。我们修改域类模型以捕获在这个抽象层次上的角度。Person、Account 和 Company 抽象保持不变，Catalog 和 Product 也一样。但是，用 Order 替换了来自域模型的抽象 Purchase 事件。
Order 包括 LineItem，它与 Catalog 中的 Product 相关联。因为这个层次为公司的内部业务处理建模，所以我们需要获得现有的库存（最小库存单元 (SKU) 的一个属性，它表示在一个特定位置的物品的库存）。我们也为客户的 UserAccount 建模，它提供对在线系统的访问。Payment 是通过使用 CreditCardAccount 来完成的。Location 代表美国的一个地理位置，它作为账单邮寄地址，同时也作为 Order 的收货地址。Shipment 包含 Shipment 中包括的 Item。
我们在系统抽象层次创造方法来简化业务处理，因此该层次通常需要很多创造力。为此，通常使用业务处理层次上的若干不同形式来实现单个域层次交易。举例来说，一次购买可以通过在线、电话、邮件、传真一个定单表格或者亲自到零售店来完成。对于每一种形式，都需要在业务处理层次为其建模。请注意，尽管对零售商来说 Credit Authorizer 是一个外部演员，但是它还是在这个层次引入，这是因为只需要它实现在该层次首次出现的业务处理。
最后，请注意该系统是技术独立的。我们的在线购买系统可以用任何 Web 技术实现。在系统黑盒子内选择技术是一个体系结构决策。
逻辑抽象层次
逻辑层在系统黑盒子内缩放，从而公开高级别的系统设计。架构师选择技术并定义高级系统结构。在我们的简单示例中，系统是由承载表示层、业务层和数据访问层的 Microsoft IIS/Microsoft ASP.NET 服务器和承载持久性数据的 Microsoft SQL Server 数据库服务器组成的。
动态视图
逻辑层上的动态视图跟踪通过系统主要组件的消息流。如示例所示，在提交 ConfirmOrder Web 表单的时候，图 6 跟踪这一消息流。
图 6. 从零售商处在线购买物品的逻辑层次动态视图
静态视图
这个层次的静态视图也将我们的视角切换到系统内部。尽管业务处理层次为出现在业务处理中的真实抽象建立了模型，这个层次将抽象建模为其在系统中所要被表示的那样。在实际的系统中，架构师会为每个软件层（表示层、业务层和数据访问层）设计类。为了保持本文的简洁，图 7 只展示了业务层的静态设计，以便说明系统层抽象是如何针对设计进行改进的。
图 7. 从零售商处在线购买物品的逻辑层次静态视图
架构师对系统层类进行改进以设计业务层接口。
因为系统中的所有账户和客户都是零售商的，所以创建一个单一的 Company 实例并使其与所有账户相关联是不切实际的，因此该层次中省略了 Company。我们只是存储 Payment 所带的信用卡号和账单邮寄地址，并非为每个 CreditCardAccount 创建一个单独的实例。此外，对系统来说，为每个出售的 Item 创建一个实例是不切实际的，因此从模型中删除了 Item，并改为由模型跟踪 LineItem 中订购的物品数量以及在新 ShippedItems 类中附带的物品数量。
架构师还定义业务层公开的服务间隔。对于本示例，业务层为 Account、UserAccount、Order、Shipment 和 Catalog 导出了 Create、Read、Update 和 Delete (CRUD) 服务。椭圆形指出了 CRUD 间隔。
请注意，即使本层次的类不是业务处理类的合适超集，架构师也可以通过直接改进业务处理类、将视角由系统外部更改为系统内部来实现这个设计。
物理抽象层次
物理抽象层次捕获系统实现的结构。系统作为一个节点的网络实现，每个节点都配置有硬件和软件。逻辑视图中的三个软件层（表示层、业务层和数据层）是以代码形式被物理实现，并部署到这些节点上。逻辑视图中的持久类物理存储在 SQL Server 数据库的关系表中。
动态视图
动态视图跟踪经过物理配置节点的消息流。ConfirmOrder HTTP post 从客户的浏览器通过 Internet 通过零售商的防火墙流动到 Web 服务器，在那里 Microsoft Windows 将其转发到 IIS，IIS 又将其传递到 Microsoft ASP.NET，然后 ASP.NET 调度 ConfirmOrder.aspx。幸运的是，现代开发工具将我们与多数物理网络隔离开来。但是，架构师需要了解物理层以避免网络瓶颈和安全暴露。
静态视图
静态视图（图 8）将逻辑视图中的持久类改进为其物理表示形式。在我们的零售示例中，业务层类存储在下列 SQL Server 表中。
图 8. 从零售商处在线购买物品的物理层次静态视图
映射到关系表和属性的类作为列实现。一对一关系和一对多关系使用一个外键来实现。开放式并发通过给每个被“凝结”的父类分配一个 datetime 字段来实现。
在设计逻辑层次时，架构师主要集中关注于实现系统功能。在确信包含了系统功能之后，架构师就能够专注于在物理层次优化实现。
通过迭代发展层次
建立了这个框架后，架构师通过几次迭代对解决方案加以发展。每次迭代都合并额外的功能 — 发票、待交定单、亲自订购、电话订购等等。在每种情况下，架构师都更新适当的抽象层次，然后将这些更新改进到物理实现层。
重访抽象层次核心原则
让我们对照核心抽象层次原则来测试我们的示例。
•
这些层次的数量和范围是定义完善的：我们有四个不同的层次：公司黑盒子、系统黑盒子、系统内的逻辑设计以及物理实现。
•
每个层次内的多个视图：在这个简单示例中，我们在每个层次上展示了一个动态视图和静态视图。
•
必须保持层次间的一致性：如果对域模型作出了更改，则更改也一定会影响到较低层次。举例来说，如果零售商决定为其产品提供维护合同，分析师就会将MaintenanceContract 添加到域模型，并将其改进为其物理表现形式。对于维护大型系统来说，同步所有层次是很重要的。因为提交了增强请求，所以分析师执行对相应细节层次的影响评估。一些增强请求影响域层次（并且因此影响所有后续层次）。其他请求只影响物理层次。
扩展层次以支持企业解决方案
既然我们已经展示了带有四个抽象层次的简单示例，现在就让我们扩展这个方法来支持 IT 企业的解决方案。图 9 展示了一个 Rational 统一过程 (Rational Unified Process，RUP) 配置，它将项目产品组织到定义完善的抽象层次中。
表中的层次描述如下。
图 9. 将项目产品组织到定义完善的抽象层次中的 RUP 配置
•
域。域层次捕获项目的业务环境。
•
项目洞察力。项目洞察力对系统将会有的对企业的业务影响进行通讯。它以投资回报分析量化了这个影响。项目洞察力表示该项目的最高抽象层次。
•
业务处理。系统层次为公司内的业务处理建模。对于极其复杂的单位来说，这个层次可以再细分到子层次：部门、部门间以及部门内。
•
UI 规范。UI 规范设计了实现业务处理的用户界面。它是由 UI 设计文档和功能 UI 原型组成的。
•
详细要求。详细要求指定了系统要求的最低层次抽象。它包括诸如数据类型格式和详细业务规则等详细信息。它还包括专业性要求，例如，性能、可用性、安全性、国际化、配置、可扩展性和灵活性要求等。
•
体系结构。系统的体系结构被组织到六个视图中：
•
逻辑。定义软件层和执行系统功能的主要抽象。
•
并发。捕获系统的并行方面，包括交易、服务器场和资源争用。
•
安全性。定义用于身份验证、授权、保护机密和日志记录的方法。
•
部署。定义网络拓扑和系统的部署配置。
•
组件。定义系统组件、其接口以及依赖项。
•
数据。定义持久性数据的设计结构。
优点
将系统产品组织到离散的抽象层次有若干优点：
•
它将系统要求分离到三个不同的抽象层次：业务处理、UI 规范和详细要求。我们不会再用令企业用户感到不知所措的单个整体功能规范了。取而代之，我们在三个改进的详细层次中对系统要求进行通讯。
•
分析师和架构师可以将复杂性控制在一个单一的、集成的系统模型中。
•
架构师可以专注于系统的单个方面，并将那些决策集成到整个解决方案中。
•
抽象层次形成了系统产品的结构。举例来说，软件体系结构文档为每个视图专设了一个小节。
•
抽象层次提供从要求到设计再到实现的直接可跟踪能力。可跟踪能力使小组能够在评测更改请求时执行精确的影响评估。
•
在使用同一框架开发几个系统之后，会在每个抽象层次形成模式。单位可以编录这些模式和每个抽象层次内的其他最佳实践。这个最佳实践的目录会作为过程改进计划的基础。
小结
为了处理复杂性，所有工程学科都应用正式抽象层次。软件也不例外。为了实现抽象层次的优点，项目必须：
•
正式标识层次，每个层次都有定义完善的范围。
•
将一个层次内的复杂性分开到多个视图。
•
在层次间保持一致性。
通过一个简单的示例，本文演示了如何应用抽象层次，然后将该方法扩展到支持企业 IT 解决方案。它提供了一个 RUP 配置框架，该框架将系统产品组织到定义完善的抽象层次。
自我评估
•
您当前的项目是否应用了抽象层次？
•
层次是否定义完善？
•
项目团队是否很好地理解了这些层次？
•
如果复杂性在一个层次中变得过大，团队是否将其分离到视图中呢？
•
团队是否在层次间保持一致性？
•
您的项目会从抽象层次中获益吗？
伟大的架构师本能地遵循这些原则。我们其余的人就必须有意识地应用抽象层次，并运用规则在整个项目生命周期中保持这些层次。
资源
Cockburn, Alistair. Writing Effective Use Cases. New Jersey: Addison-Wesley, 2001
Kroll, Per and Kruchten, Philippe. The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP. Boston MA: Pearson Education and Addison-Wesley, 2003
DeMarco, Tom and Plauger, P J Structured Analysis and System Specification. Prentice Hall PTR, 1979
要获得 DoD 标准 2167A 的联机副本，请访问 http://www2.umassd.edu/SWPI/DOD/MIL-STD-2167A/DOD2167A.html。
脚注
1 很多人已经成功地将抽象层次应用于软件。Ed Yourdon 和 Tom DeMarco 在 1979 年提出了结构化分析和结构化系统设计的概念。美国政府的许多分支机构标准化了 DoD 的 2167A 标准，它要求系统由有层次的硬件和软件配置项组成。DBA 社区经常应用细节层次为关系数据库建模。特别地，Bachman 工具集和 James Martin 的信息工程方法学 (Information Engineering Methodology，IEM) 先为数据库逻辑建模，然后再为其物理建模。在 Google 上键入“software levels of abstraction”进行搜索会返回若干个结果，但其中大多数来自于学术社区，而且其内容看起来集中在正式计算机语言方面。
关于作者
Don Awalt 是 RDA Corporation 的创始人和 CEO，该公司是一家自定义软件工程公司，成立于 1988 年，在华盛顿特区、巴尔的摩、亚特兰大、费城和芝加哥都设有办事处。作为微软认证金牌伙伴 (Microsoft Gold Certified Partner)，该公司专注于使用 .NET Framework 开发企业 Web 和富客户端系统。Don 目前是 Microsoft 华盛顿特区的区域总监，他以前曾经担任费城首任区域总监。Don 经常在行业活动中演讲，这些活动包括 Tech Ed、Developer Days、MSDN 活动和各种 SQL Server 及 Windows 活动。他是 SQL Server Magazine 和 PC Tech Journal Magazine 的特约编辑，并且也为其它出版物撰写稿件。Don 所擅长的技术领域包括 Web 服务、SQL Server、现代编程语言的发展，以及在 Microsoft 的 Prescriptive Architecture Group (PAG) 中可以看到的许多体系结构和处理工作。可以通过 AWALT@rdacorp.com 联系到 Don。
Rick McUmber 是 RDA 的质量和最佳实践总监。他为 IBM 和 Rational Software Corporation 一共工作了 11 年，致力于为美国运输部、国防部、NASA 和加拿大国防部开发系统。从 1994 年以来，他一直在 RDA 工作，致力于为其客户开发业务解决方案。可以通过 McUmber@rdacorp.com 联系到 Rick。
