内容


参考体系结构:最佳实践

Comments

我遇到过的许多项目花费大量杂乱的时间在研究、调查、考虑体系结构的确定上。如果以前的项目组花了时间记录他们的经验并且构建了参考体系结构,他们就可以为新项目组节省更多用来研究和决策的时间。但事实上,缺乏从积累的项目历史中学习的能力却给项目的时间表带来了更大的风险,这种风险很可能比其他许多因素的总和还要大。一个没有参考信息的项目并不一定就会失败,但是它需要项目组的某些部门付出更多的努力,而这些努力本可以更好的投入在项目的其他地方。只有意识到利用经过验证的良好的可重复的过程,该组织才能指望尽快的把软件交付到顾客的手中。

幸运地是,不需要花很多时间为参考体系结构去整理成功的分类学,这些参考体系结构能够显著的减少不正确方法的决定次数并且增加项目一开始就很顺利可能性。自从分布式的客户机/服务器(C/S) 的早期,这样的框架就成为成功组织的一大特点。随着系统变的越来越复杂,这种需求变的越来越迫切。

本文将会回顾在遵循RUP提供的指导方针的情况下,一个健壮的参考体系结构在软件开发项目中的作用。此外,本文还提出了一个实践性的分类方法,用以有效地收集、管理和使用参考体系结构。

好的书籍是这样说的:

根据RUP(参见工具条和图1),参考体系结构是:

……,本质上,一个预先确定的体系结构模式,或者模式的集合,可能部分地或者完全地用具体例证说明,设计,并证明在特殊的商业和技术环境下可用,以及支持先前的成果。通常,这些成果是从以前的项目中得到的。

在初始和精化阶段,RUP继续表明,项目组应当参考它的参考体系结构,作为新项目体系结构分析的一部分(参见图2中红色部分表示的区域)。然而,RUP进一步表明:“创造参考体系结构是一项组织应该考虑的问题,这超出了RUP的范围”。这并不是 RUP 中的一个疏忽。参考体系结构的结构、内容、管理应该基于组织独特的结构和需求。例如,小的组织,通常是在一个项目开发的大房间里,通过简单的方式、项目组成员之间面对面的切磋来进行交流和沟通,他们可能不需要许多正式的文档。较大的组织则可能在组织的企业内部网上维护一个知识库,这样在整个项目生命周期内项目组成员都可以参考。

Rational统一过程(RUP)

如图1所示,RUP由四个阶段和九个核心工作流组成。迭代过程是一个独特的活动序列,具有一个基线计划和评价准则,从而导致内部和外部两种发布。它贯穿九个核心工作流,延伸到每个核心工作流中用到的活动。任务的结果集包含周期计划。一个给定的阶段可能有多个迭代,迭代的数量通常是项目的技术复杂度和项目规模的因子。RUP给出了四个阶段的示例周期计划。

Figure 1: Phases and Iterations of the RUP
Figure 1: Phases and Iterations of the RUP

点击放大 图1:RUP的阶段和迭代

每个阶段的结束是由里程碑事件的完成来标记的。RUP四阶段的里程碑分别是:Lifecycle Objective(生命周期目标), Lifecycle Architecture(生命周期架构), Initial Operational Capability(初始操作能力), 与 Product Release(产品交付)。

与基于瀑布的过程模型不同,RUP模型认为范围广泛的核心工作流的活动实际上是在整个项目生命周期中并发的。

关于RUP的更多信息可以参考:

网址

Rational Unified Process 产品页面

书籍

《Rational统一过程介绍》,第二版。Philippe Kruchten著,Addison-Wesley出版社, 2000.

Figure 2: Architecture Analysis Activity in the Perform Architectural Synthesis Discipline

Figure 2: Architecture Analysis Activity in the Perform Architectural Synthesis Discipline
点击放大

图2:执行体系结构的综合核心工作流的执行体系结构的分析活动

参考体系结构看起来像什么样的?

RUP提出:参考体系结构应当按照不同层次的抽象,或者作为“视图”来定义,因此在使用时能够提供更多的适应性。理想情况下,这些视图对应于在RUP中描述的软件体系结构4+1视图(参见图3),并且在RUP软件体系结构的文档中有具体表达。

Figure 3: 4+1 Views of Software Architecture Contained in the RUP

Figure 3: 4+1 Views of Software Architecture Contained in the RUP
点击放大

图3:RUP中包含的软件体系结构4+1视图

注意:根据RUP,只有用例视图和逻辑视图是所有项目都需要的。如果被构建的系统需要他们,其他的视图也应该被使用。例如,当有多个控制线程时就需要进程视图;当系统将被多于一个节点而分布式访问时,就需要部署视图了。尽管肯定有许多方法来图形化的描述参考体系结构,但我更喜欢用一组熟悉的映射代4+1框架的逻辑视图的功能层次。我也喜欢扩展RUP关于参考体系结构的定义,将项目的技术兼容性和工具选择包括在内。

Figure 4: Functional Layers Within the Logical View

Figure 4: Functional Layers Within the Logical View

图4:逻辑视图中的功能层次

除了图4中所示的层次,在有些情况下可能会出现层中层。例如,系统软件层包含体系结构的信息,这些信息既有关于数据库管理系统(DBMS)的,也有关于操作系统(OS)的。

决定如何为不同层次表达信息可能是一个挑战。一般而言,表达应当简明扼要。至少,组织需要公布简单的矩阵或者表格以利于快速检索和便于材料的交流(参见表1-4)。

我同样也愿意将从以前的努力中获得的真正的项目成果包括在下面的这个矩阵中。他们应当以文档和实际执行代码(组件)的方式,这样可以重用。

最后,我想将外部和内部资源的参考加到这个矩阵中。他们可能是书籍或者网络站点上描述最佳实践和设计策略的一段。这些资源也可能引用了公司内部的白皮书,它们详细讨论和回顾了不同体系结构的选择。

现在,让我们近距离的看一看这四个层次的每一个层:

用户界面层

用户界面层包括许多基础的东西,不仅仅是关于窗口小部件在屏幕中该怎样摆放的一组标准,还包括技术的选择以及旧技术向新技术(比如用XML作为一个表示工具,使用模型视图控制(MVC)模式来将表示与内容环境分离)演化的方面。这一层应该包括哪些部分的示例参见表1。1

表1:用户界面层(部分示例)
内容产品/服务/组件
布局风格和可用性
  1. 参考创新计算被称为“GUI指南”的产品,在2000年被组织购买。
  2. 所有的产品应当使用质量保证组建立的可用性实验室。该实验室提供测试阶段的音频和视频记录以及供用户完成的反馈表。
构造工具:
1. 语言
  1. IBM大型机:CICS BMS 图和Cobol II
  2. 非-IBM大型机:应当使用Java服务器页面(JSP)作为基于Java的解决方案的首选表示工具。
    Java Applet不是任何时候都允许使用。
  3. 非-IBM大型机:在.NET平台上应该使用活动服务器页面(Active Server Pages) 作为基于Microsoft的解决方案的首选表示工具。

    在HTML中的ActiveX/COM+控件的表示方法不是在任何时候都是允许的。
2. 集成开发环境(IDE)
  1. IBM大型机:TSO/SPF
  2. 非-IBM大型机:Borland JBuilder V7
  3. 非-IBM大型机:Microsoft VS.NET
3. 信息流(有效负载内容)
  1. IBM大型机:3270流在大型机与大型机之间通信 XML在大型机与非大型机之间的交互通信
  2. 非-IBM大型机:在合适的地方使用HTML 和 XML。
4. 设计策略
  1. 除非可以另外证明,当使信息视图外在化时,应用软件应当尽量使用MVC设计模式。更加详尽的描述参考Gamma等人的书《设计模式:可复用面向对象软件的基础》
  2. 非-IBM大型机Java应用:

    这些应用应当使用JSP和Java Servlets(在实现表示层和业务层的交互时应该使用Struts框架)。这在Java社区中也被称为Model 2

    例子:参考在Q42002中实现的订单项应用,这正是一个可以遵循的模板。
  3. 非-IBM大型机Microsoft应用:

    这些应用应该使用ASP.NET以及服务器端的控件的这种架构。虽然在Microsoft应用中,没有与struts框架对应的框架,回顾一下下面提到的应用示例将会给你一个很棒的指导。

    例子:参考Rene Becnel的关于在组织内使用ASP.NET的内部白皮书。
组件:
1. 将错误表达在用户界面
  1. 对于Java应用而言,Jakarta 项目组(jakarta.apache.org)的Struts 框架是将错误表达在用户界面以及在服务器端处理用户端输入装置的标准(参考struts框架业务层的讨论)。

业务

项目经常花费大量的时间在探索工具选择上面。此外,当设计应用的某些方面时,他们可能不知道采取那种方法最好。这正是参考体系结构最有价值的地方。项目组不仅可以获得对工具和语言的选择,而且如果他们是可获得的话,还有设计模式和先前构造的组件可以利用。在业务层存在着复用最大化的潜力。

表2:业务层(部分示例)
内容 产品/服务/组件
组件:
1. 语言
  1. IBM大型机: Cobol II
  2. 非-IBM大型机:Java 1.4
  3. 非-IBM大型机:VB.NET or C#
2. 集成开发环境(IDE)
  1. IBM大型机:TSO/SPF
  2. 非-IBM大型机:Borland JBuilder V7
  3. 非-IBM大型机:Microsoft VS.NET
模式使用-业务脚本
1. 在运行时应用程序不知道将要创造的示例的准确类型。
  1. 工厂模式――应当在所有资源查找和动态生成资源的应用中使用该模式

    对于使用BEA的Java应用而言,对资源的定义来自部署描述符。

    例子:参考Q22002中实现的的订单项应用的例子。对于资源和对象查找,它广泛地使用了工厂模式。

    对于 .NET应用而言,对资源的定义被保存在配置文件中(.confg files)。

    例子:参考Q12002中实现的市场预测的例子,它使用了.NET配置文件。
2. 每个用例表达了工作的多条路径,为了便于复用,在实施过程中,这些路径应该高内聚、低耦合。 1. 外观模式――更加明确的,这种用例设计模式应当被使用。每个用例具有一个独立的外观来降低耦合和简化工作设置的事务控制单元。
3. 信息的外部表示是多样化的,所以如何表示信息和如何实际存储信息两者的依赖应当少。
  1. 模型/视图/控制器模式(MVC)――所有的应用必须使用MVC架构来分离信息的格式化和信息实际的存储和对象关系。

    对于Java平台,Model 2体系结构必须使用。
    (参考前面的关于用户界面和使用MVC的讨论)
服务组件:
1. 安全
  1. IBM大型机:RACF exits
  2. 非-IBM大型机: IBM Secure Way
2. 日志
  1. IBM大型机:Module TE06LOG
  2. 非-IBM大型机(Java平台):Log4J

    例子:参考Log4J框架的网络参考 http://jakarta.apache.org/
  3. 非-IBM大型机:Microsoft VS.NET-Logger Assembly (logit.dll)
3. 从用户界面到业务层,请求的路由
  1. 对于Java应用,Jakarta 项目组(jakarta.apache.org)的Struts框架成为一个标准,被用作请求从用户界面到最终同业务层的交互之间的路由。对于一个给定的事务性的请求,Struts使用命令模式来对逻辑的执行进行解耦。
数据访问组件
1. 存储过程
  1. 除非正确的解决了应用的性能问题,存储过程相当不能令人满意的。即便是那样,在使用存储过程之前,应当尝试所有替代的应用调整方法。
2. 数据传递
  1. 应当尽可能的使用值对象(即静态的、对象的数据快照) 和数据访问对象(即实际执行SQL语句的对象)

    例子:关于值对象和数据访问对象的使用,参考Q42002实施的订单项的应用。

中间件层

中间件层可以被认为是一个纯粹的服务层。虽然当讨论到体系结构,中间件这个术语现在被滥用,正是这一层经常在整个组织的架构中扮演中最大的横向作用。(使用横向这个词,我的意思是此项几乎应用于所有的应用,正在开发的,还未开发的和已经购买的).

表3:中间件层(部分示例)
内容 产品/服务/组件
消息服务:
  1. IBM大型机: MQ Series
  2. 非-IBM大型机(Java平台): JMS/MQ Series Interface
  3. 非-IBM大型机(Microsoft平台): (Microsoft) MSMQ/MQ Series Interface
目录服务:
  1. IBM大型机: Secureway LDAP Interface
  2. 非-IBM大型机(Java平台): JNDI and Netscape LDAP Directory
  3. 非-IBM大型机(Microsoft平台): Active Directory/LDAP
数据分布策略
  1. 都不支持分布的两阶段的提交处理。
  2. 总是鼓励集中的数据访问。数据存储将被按照服务器和/或地理位置进行分割。然而,即便是在这些情况下,集中访问仍然是优先访问模式。
数据访问API:
  1. IBM大型机- Embedded SQL
  2. 非-IBM大型机(Java平台) - JDBC V3
  3. 非-IBM大型机(Microsoft平台) - ADO.NET

系统软件层

系统软件层通常是最容易通信的。新的项目不需要指定组织支持的新的操作系统。就许可(license)费用而言,系统软件层通常是最昂贵的层。组织应当利用那些使得选择最小化的健壮的参考体系结构。

表4:系统软件层(部分示例)
内容 产品/服务/组件
操作系统
  1. IBM大型机: ES/9000
  2. 非-IBM大型机: Windows 2000 Server
数据库策略
  1. 产品-关系
  1. IBM大型机: DB2
  2. 非-IBM大型机: Microsoft SQL Server 2000

创造参考体系结构

关于参考体系结构,还存在一些类似鸡和蛋的关系的问题。我们已经定义了什么是参考体系结构以及其结构看起来是怎么样的,甚至给出了部分示例。然而,我们还没有首先讨论参考体系结构是如何创造出来的。

挑战典型地来自体系结构组。通常,我不是那些正式的,永久地指定的体系结构组的狂热者。在这些组里的人往往精于技术,但是忽视了业务需求以及人们是如何需要所使用的技术的。一个更有效的方法是建立一个非正式的体系结构组,包括来自各种各样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 全球站点上的 英文原文

评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=205063
ArticleTitle=参考体系结构:最佳实践
publish-date=03302005