软件架构训练基础教程

      本文是软件架构的基础训练，它介绍了有效的软件架构所需要的基本工具。在军事中，基础训练用于挑战和激发军官学校学生，并示范军事生涯的要求和奖赏。同样地，软件架构必须由个人来推动，这些人必须渴望对抗软件开发工作中的技术领先阶层的挑战。但是，这样的动机还是不够的。软件架构必须等同于认识架构全景的智力手段。

　　本文提供了一条便利的方法，它不仅显示了行业中最好的架构经验，还提供了具体的现实例子和练习，以便把它提供的素材应用于整个软件行业的普通环境中。基本训练覆盖了软件技术的基本概念，它提供了软件架构的基础。软件技术已经向软件开发的很多趋势和可选的方法不断演化。目前，主流的软件实践从面向过程演化到面向对象，然后又演化到面向组件的开发（图1）。随着企业级Java和微软.Net不断采用，面向组件将成为下一个主要的范式。在共同开发中，大多数新开始的项目都采用了面向组件技术，因为它受到了多数商业开发环境的支持。本文的前面提到，面向对象的软件架构观念非常薄弱，这导致了一些严重的缺陷。正在形成中的面向组件的趋势正在利用架构设计的强大原理代替旧的方法。

图1.面向过程的技术（a）和面向对象的技术（b）

　　软件架构必须能够清晰地描述这些开发范式，同时允许技术适当地使用。在任何给定的项目中，折衷的混合的开发范式（包括关系数据库管理）对于获得最佳结果都是有用的。每个技术都提供了一些优点，包括成熟的开发工具。

　　目前大多数组织会发现它们的技术技巧基于正在使用的三种主要的技术之一：面向过程的、面向对象的或面向组件的。每个范式对于某个组织和它全部职员的技能都是非常明确的。面向过程和面向对象的范式都被编程语言的选择紧紧地约束了，但是面向组件就不同了，它与下层构造的选择的关系更加紧密。

　　面向过程的编程语言包括FORTRAN、COBOL、C、Pascal和BASIC。在面向过程的技术中，程序由执行不同算法的过程组成。过程与系统中的数据是分离的，而且过程通过直接访问操作（access operations）使用数据。这是存储过程编程系统的直接后果，而计算机技术就源于此。当程序和数据分离时，在程序的各部分之间存在很多潜在的内部依赖性。如果数据表现被改变了，程序的多个位置都可能受到冲击。

　　数据－过程分离的一个例子是2000年问题，在这个例子中简单地给日期表现添加一些数字会对面向过程的软件产生灾难性的后果。不幸的是，因为主流的系统都是使用面向过程的技术建立的，对这些数据表现的依赖可能会引起系统范围的程序错误，并引起了逐行检查、修改程序的必要性。

　　面向对象编程语言包括Smalltalk、 C++、 Java编程语言和C#（微软.Net开发环境中提供的一种语言）。这些语言按照抽象数据类型（通常称为类）的要求支持数据和操作代码的封装。在面向对象编程语言中，封装能力对于适度大小的程序是足够的。只要软件模块由单独的程序员维护，封装对于提供一些内在的优点就是完全足够的。但是，特定语言的封装不足以支持软件的重复使用和分布式系统。

　　在面向对象技术中，基本范例被改变为允许关系的分离。图1显示了面向对象技术的范式，在它里面程序被分成叫做对象（object）的更小的片段。每个对象都包含了系统的一些数据，并且程序封装了这些数据。换句话说，只有通过使用与该数据直接相关的程序才能访问这些数据。通过这种方法，系统被分离成独立改变的模块。数据表现的任何改变仅仅影响封装该数据的直接的对象。

　　对象使用消息彼此通讯。消息可能影响状态——换句话说就是改变数据——但是只能通过与本地数据密切相关的封装了的过程来改变它。对于小程序，对象范式对于隔离改变来说是有效的。但是，这个范式对于所有可能的使用情形来说并不是完美的。

　　现在面向对象技术已经被广泛地使用了。一般来说程序上的技术来自于学术界，但是面向对象技术事实上来自于商业组织。实际上面向对象技术有很多有趣的渊源，甚至于可以追溯到计算机科学的开端。现在对象技术是占有统治地位的商业软件范式。事实上每个软件生产商都提供了对象技术的解决方案，并一起提供了组件的下部构造，允许不同软件环境中的软件厂商之间交互操作。

　　面向对象的架构

　　对于主要的软件开发从业者来说，面向对象是缺乏软件架构方法的。在面向对象的方法和文化中，这种缺乏在很多方面都有表现。从通常被当作原始来源的OO（面向对象）思考、设计面向对象软件【Wirfs-Brock 1990】开始，已经有了软件架构的概念，包括通过观察协作图（collaboration diagram，它需要一个章节才能讲清楚）发现子系统（subsystem）。在接下来的十年中，在面向对象方法学社团中几乎没有写出什么有关架构的东西。主要的OO方法学的书本中关于架构的章节都很少，它们都是Wirfs-Brock的架构概念的一些模糊的反映。

　　由于实际上几乎没有关于架构的专著，大多数OO从业者都只有最基础的架构指导。他们没有理由认为架构很重要。这种态度导致OO项目中很大的混乱，因为小组成员必须尽全力去管理那些并非为他们设计的OO方法的复杂性和可伸缩性。

　　一般而言，OO方法包含了成功的对象模型技巧，在这些模型中大多数分解对象最终被转换为编程对象。这种方法叫做基于模型（model-based）的方法。为了了解架构，认为每个分解对象都不可避免地成为编程对象是所有OO开发人员都需要克服的一个主要障碍。在架构模型中，特定对象表现约束而不是编程对象。它们可能会，也可能不会被转换成编程对象，这是由开发人员的自行的决定。

　　 OO也在其它一些微小的地方与架构矛盾，这与项目文化相关。OO鼓励项目小组平等，这样所有的决定都是民主的。在这样的项目中就没有架构的角色了，因为在开发小组的成员之间作出的决定的差别是很小的。

　　 OO鼓励开发中的“bad-is-better”思考方式，实际上这是一种与架构思想背离的哲学。使用bad-is-better思想的时候，任务实现的外部表现远远超过了可以维护的的内部结构的任何需求。换句话说，快速迭代的原型处理，以及对架构原理的无情的漠视对于OO开发来说是一种正常的、健康的环境。

　　架构的话题只在最近的OO专著中与新发现的组件技术一起被重新提到的。现在大多数方法学的书本都习惯性地包含一个关于架构的象征性的章节，但是在OO的全盛时期，架构实际上是禁止使用的。从感觉上讲，组件是OO的缺点的反映。组件的强调较大“颗粒”的软件接口和模块，是向架构想法方向的改进步骤。

　　数据库和对象

　　数据库技术也朝对象的方向演化。数据库技术源于几个不同的模型。近些年，数据库的关系模型是最有影响力的。到最近，面向对象的数据库已经成为重要的技术市场，而联合了面向对象和关系概念的数据库也很平常。大多数主要的行业数据库，例如Oracle 9i和IBM的DB2数据库都包含了对象－关系能力。

　　数据库查询语言，例如结构化查询语言（SQL），都在标准的工作方面进行了扩展以支持面向对象的概念。发生这种情况的原因之一是人们正在建立的这类应用程序需要充分的、更多的适合显示需要的数据表现类型和查询算法类型以搜索和维护信息。

　　对象在主流技术中的地位

　　目前对象技术应用于大多数应用程序范围和垂直的市场中。政府组织和工商企业正在用对象技术运作大量的项目。对象技术的主要优点是它允许为组织提供竞争优势的新业务流程的实现。社会正在朝不断依赖信息技术的方向转变。对象技术的使用通过软件重复使用机制允许快速的系统实现和各种形式的劳动力的节省。尽管大量的软件代码仍然存在于面向过程的语言（例如COBOL）中，但是很清楚这种范式正在改变。

　　脚本语言

　　脚本语言的支持者声称使用脚本语言的编程人数比使用其它类型语言的编程人数都要多【Ousterhout 1998】。脚本语言，例如JavaScript语言、TCL shell编程语言和Visual Basic语序可以把先前存在的软件（例如组件）轻易地集成到应用程序构造中去。