![关闭 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
我遇到过的许多项目花费大量杂乱的时间在研究、调查、考虑体系结构的确定上。如果以前的项目组花了时间记录他们的经验并且构建了参考体系结构，他们就可以为新项目组节省更多用来研究和决策的时间。但事实上，缺乏从积累的项目历史中学习的能力却给项目的时间表带来了更大的风险，这种风险很可能比其他许多因素的总和还要大。一个没有参考信息的项目并不一定就会失败，但是它需要项目组的某些部门付出更多的努力，而这些努力本可以更好的投入在项目的其他地方。只有意识到利用经过验证的良好的可重复的过程，该组织才能指望尽快的把软件交付到顾客的手中。
幸运地是，不需要花很多时间为参考体系结构去整理成功的分类学，这些参考体系结构能够显著的减少不正确方法的决定次数并且增加项目一开始就很顺利可能性。自从分布式的客户机/服务器(C/S) 的早期，这样的框架就成为成功组织的一大特点。随着系统变的越来越复杂，这种需求变的越来越迫切。
本文将会回顾在遵循RUP提供的指导方针的情况下，一个健壮的参考体系结构在软件开发项目中的作用。此外，本文还提出了一个实践性的分类方法，用以有效地收集、管理和使用参考体系结构。
根据RUP(参见工具条和图1)，参考体系结构是:
……，本质上，一个预先确定的体系结构模式，或者模式的集合，可能部分地或者完全地用具体例证说明，设计，并证明在特殊的商业和技术环境下可用，以及支持先前的成果。通常，这些成果是从以前的项目中得到的。
在初始和精化阶段，RUP继续表明，项目组应当参考它的参考体系结构，作为新项目体系结构分析的一部分(参见图2中红色部分表示的区域)。然而，RUP进一步表明:“创造参考体系结构是一项组织应该考虑的问题，这超出了RUP的范围”。这并不是 RUP 中的一个疏忽。参考体系结构的结构、内容、管理应该基于组织独特的结构和需求。例如，小的组织，通常是在一个项目开发的大房间里，通过简单的方式、项目组成员之间面对面的切磋来进行交流和沟通，他们可能不需要许多正式的文档。较大的组织则可能在组织的企业内部网上维护一个知识库，这样在整个项目生命周期内项目组成员都可以参考。
|
点击放大
RUP提出:参考体系结构应当按照不同层次的抽象，或者作为“视图”来定义，因此在使用时能够提供更多的适应性。理想情况下，这些视图对应于在RUP中描述的软件体系结构4+1视图（参见图3），并且在RUP软件体系结构的文档中有具体表达。
点击放大
注意:根据RUP，只有用例视图和逻辑视图是所有项目都需要的。如果被构建的系统需要他们，其他的视图也应该被使用。例如，当有多个控制线程时就需要进程视图；当系统将被多于一个节点而分布式访问时，就需要部署视图了。尽管肯定有许多方法来图形化的描述参考体系结构，但我更喜欢用一组熟悉的映射代4+1框架的逻辑视图的功能层次。我也喜欢扩展RUP关于参考体系结构的定义，将项目的技术兼容性和工具选择包括在内。
除了图4中所示的层次，在有些情况下可能会出现层中层。例如，系统软件层包含体系结构的信息，这些信息既有关于数据库管理系统(DBMS)的，也有关于操作系统(OS)的。
决定如何为不同层次表达信息可能是一个挑战。一般而言，表达应当简明扼要。至少，组织需要公布简单的矩阵或者表格以利于快速检索和便于材料的交流（参见表1-4）。
我同样也愿意将从以前的努力中获得的真正的项目成果包括在下面的这个矩阵中。他们应当以文档和实际执行代码（组件）的方式，这样可以重用。
最后，我想将外部和内部资源的参考加到这个矩阵中。他们可能是书籍或者网络站点上描述最佳实践和设计策略的一段。这些资源也可能引用了公司内部的白皮书，它们详细讨论和回顾了不同体系结构的选择。
现在，让我们近距离的看一看这四个层次的每一个层:
用户界面层包括许多基础的东西，不仅仅是关于窗口小部件在屏幕中该怎样摆放的一组标准，还包括技术的选择以及旧技术向新技术(比如用XML作为一个表示工具，使用模型视图控制(MVC)模式来将表示与内容环境分离)演化的方面。这一层应该包括哪些部分的示例参见表1。 1
| ||||||||||||||||||
项目经常花费大量的时间在探索工具选择上面。此外，当设计应用的某些方面时，他们可能不知道采取那种方法最好。这正是参考体系结构最有价值的地方。项目组不仅可以获得对工具和语言的选择，而且如果他们是可获得的话，还有设计模式和先前构造的组件可以利用。在业务层存在着复用最大化的潜力。
| ||||||||||||||||||||||||||||||
中间件层可以被认为是一个纯粹的服务层。虽然当讨论到体系结构，中间件这个术语现在被滥用，正是这一层经常在整个组织的架构中扮演中最大的横向作用。（使用横向这个词，我的意思是此项几乎应用于所有的应用，正在开发的，还未开发的和已经购买的）.
|
系统软件层通常是最容易通信的。新的项目不需要指定组织支持的新的操作系统。就许可(license)费用而言，系统软件层通常是最昂贵的层。组织应当利用那些使得选择最小化的健壮的参考体系结构。
|
关于参考体系结构，还存在一些类似鸡和蛋的关系的问题。我们已经定义了什么是参考体系结构以及其结构看起来是怎么样的，甚至给出了部分示例。然而，我们还没有首先讨论参考体系结构是如何创造出来的。
挑战典型地来自体系结构组。通常，我不是那些正式的，永久地指定的体系结构组的狂热者。在这些组里的人往往精于技术，但是忽视了业务需求以及人们是如何需要所使用的技术的。一个更有效的方法是建立一个非正式的体系结构组，包括来自各种各样IT组织部门(例如开发、支持、运营)的代表。商业代表也应该是这个组的一部分。对于非正式的体系结构组，挑战在于保证有足够的管理支持并且贯彻到底。指定一个人去提醒大家各自的义务和责任也许是有效的。
使用图4中表示的层次化的参考体系结构，体系结构组可以简化填写以上各表的空白，利用他们对组织技术的知识和大量的最佳实践，他们可以从所有项目中看得更加长远。
总而言之，构建一个参考体系结构需要结合有效的工具、技术、组织内正在使用的方法(即从以前项目成果中获得的），并且融入最佳实践和推荐的模式以及组织认为能够使项目更好、更成功的那些方法。
在早期的创造性项目的观点中，有必要对在其他已经投入生产的商业案例对本项目的影响以及参考体系结构能给本项目带来的好处进行估算。
在RUP中，这就是体系结构分析活动（在图2中描述和概括）所期望的结果，它真正完全地利用了参考体系结构。组织会发现需要调整参考体系结构来适应早期的评估。例如，需求必须指出一个已有参考体系结构中没有关联的新中间件服务。
例如，假定组织的商业案例需要实施一个Web服务的应用，该应用集成两个异构的遗留应用。Web服务需要基于可扩展标记语言XML的消息的交换以及对于协议（简单对象访问协议(SOAP)和可扩展标记语言(XML)－远过程调用(RPC) )的取舍。如果这个参考体系结构目前没有提出这些技术中的任何一个，那么问题将转化为将采用哪一种标准（例如，微软的Web服务、Java对Web服务的支持等等）。如果参考体系结构没有指明优先采用哪一种开发语言――可能是Java――那么将需要做的决定比较少，但是附加到考体系结构的东西仍然是需要的（例如，现在我们有一个需要在参考体系结构布置的首选SOAP实现标准）。
此外，这些新的参考项可能层叠并且影响已经建立的体系结构的标准。再一次，我们使用前面的例子说明，因为Web服务的安全问题不像那样传统应用程序安全问题那样的清晰，组织将不得不回顾或者可能调整它的标准安全策略。
通常，第一个项目遇到参考体系结构中没有涉及的体系结构问题时，默认地将会为以后的项目设定一个新的体系结构标准。然而，参考体系结构能够不破坏所有以前的标准而吸收新加入的标准也是极其重要的。监视连锁反应并且仔细监视任何改变标准的决定是重要的。
对每个项目，开发历史连同基准对于保持参考体系结构不陈旧过时都是很关键的。在RUP中，为了项目竣工的准备活动（形成于产品化阶段），需要对参考体系结构的更新。
参考体系结构的另一个有价值的附加物是在项目随后实施过程中的经验描述。项目团队应当评估应用的体系结构中将会在生产环境下导致麻烦的地方的可靠性。虽然项目组作出的决定可能都是正确的，系统的技术组合可能太难而难以支持。注意，增加这一个智慧与在项目生命周期的结尾阶段获得参考体系结构的成果是不同的。
例如，假定你已经实施过几个一客户为中心的应用。可能体系结构是有效的并且应用是按照规约来工作的，但是支持问题，比如软件的发布和软件版本的同步是存在问题的。针对以上的问题，参考体系结构可以要求，在将来的应用中，应用体系结构应当遵循瘦客户端的模型，除非有证据证明这样不可行。在这样的情况下，直接的维护问题将会对参考体系结构产生深远的影响。然而，不会有大量的数据关于直接的维护问题直到它们很好的融入应用的维护周期中。
最终，维护和持续更新参考体系结构的责任依赖于前线项目管理和体系结构组的支持。 项目经理必须认真对待体系结构分析活动（资产消耗）和准备项目竣工的活动，前者活动是RUP建议在起始和精化阶段实施的，后者是RUP建议在产品化阶段实施的。如RUP所声明的，正是在项目竣工阶段收获了体系结构的成果。然而，像我们前面讨论的，真正有用的是， 参考体系结构必须持续的更新和精化，这不止是先前的项目成果中的信息，还包括从在生产环境下管理应用软件收集到的数据。
高级管理人员必须往更远处看短期的构造和维护参考基础结构的战术成本以及看到拥有这样合适的参考体系结构的重要战略意义和远期的回报。虽然创造、维护一个参考体系结构需要资源――它们帮助提高项目的适应性并增加潜在的公共组件――当需要服务的时候，这些资源可以通过已有的项目简化矩阵。
最后，组织不希望项目组受到该使用什么编程语言或者什么日志API的困扰。他们不希望当有需求要分离外化的信息及其内部状态的时候，项目组尝试着去估计应用哪一种模式最好。他们也不希望他们的项目组在开发J2EE应用时，还在为该使用Model 1还是Model 2而犹豫不决。对于每一个从参考体系结构抽取的项目，这些决定应当已经做出了。如果确实需要再做决定，通过参考体系结构，这些选项应当是很少而且清晰描述的。
参考体系结构并不意味着扼杀创造性，而是强制项目之间的一些共同的东西。最后，终极目标是降低组织中技术使用所有权的总成本。组织报告表明，当前项目间垂直的重用很普遍。在应用程序之间的水平重用更少，尤其在大中型组织当中。这里有一个低垂的成熟果实等待摘取。
对于一个组织，引入一项技术类似于用药。紧密地监视反应和预见副作用是重要的。 构建会不断进化产生的参考体系结构的基础设施将是确保副作用会大大易于管理的一种途径。
《Rational统一过程介绍》第二版，Philippe Kruchten著，Addison-Wesley出版，2000年
《Rational统一过程》，2002年
《利用UML进行面向对象的分析与设计》Paul R. Reed, Jr.,著，Seminar Material出版，1993-2002年
《利用Java和UML开发应用》，Paul R. Reed, Jr著，Addison-Wesley出版，2002年
《利用VB和UML开发应用》，Paul R. Reed, Jr著，Addison-Wesley出版，2001年
1 注意较大的组织可能更倾向于在将表1－4中列出的信息放置在一些其他政策的文档中而不是参考体系结构中。如果没有较小的组织或者没有标准的组织，那么参考体系结构就是一个合适的选择，就像那些问题影响体系结构的决定一样。
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
标签
使用 滑动条 调节标签的数量。
热门标签 显示了特定专区最受欢迎的标签（例如 Java technology，Linux，WebSphere）。
我的标签 显示了特定专区您标记的标签（例如 Java technology，Linux，WebSphere）。