XDE里面模式驱动地设计与设计(一)

摘要：

　　 软件模式，特别是设计模式在现今的软件开发中越来越重要。在许多的标准，工具，以及开发方法中都引入了模式的概念。本文介绍了如何在UML中对软件模式进行建模，并结合具体的工具Rational XDE，对如何定义，如何应用模式作了详细地介绍，并指出了一些相关的问题。

第一部分：模式的UML表示

　1.1 软件模式

　　 软件模式（Software Pattern）的概念由来已久，当初软件业从建筑业等其他的工程行业中汲取模式的概念，并把它演化成为软件模式的时候，无疑的是软件工程领域中一项革命的成果。而GoF对设计模式的分类与描述，更使得模式这一概念具体入微，能够被成熟的应用在软件开发之中。

　　 所谓模式，简单而言，是一种针对某一特定的，反复出现的问题的成功的解决方案。就问题本身而言，可以使任意领域和范畴的。在诸如建筑，音乐，写作，管理等等领域中，都有模式的概念存在。在软件领域中，模式被以一种约定的文档形式表现出来，以便于纪录，学习和交流。经验丰富的程序员，可以将他们的知识，通过模式这种更形式化的东西，传递给别人。因而，模式可以看作是一种具体化的，文档化的经验和知识。

　　 在将近十年的时间里，软件模式的有了很大的发展，它不仅仅只是一种经验的表达，现在已经能够作为程序开发的一种驱动力了。模式驱动的软件开发过程（Pattern Based Development），已经不是一种新事物。但是，在今天的软件开发领域中，一个开发思想，或者过程，如果没有一种强有力的工具支持，它就很难得到广泛的应用。

　　 软件模式，就其抽象的级别，可以分为体系结构模式，设计模式和Idiom三种。

　　 1、体系结构模式：提供对体系结构设计中所遇到的问题的解决方案。体系结构的例子包括有：Pipe-Filter模式，白板模式，MVC模式，ORB模式等等。体系结构模式并不一定是面向对象的，它的思想可以为任何开发方法所使用。因而，在利用UML进行描述的时候会有一些困难，而通常使用一些特定专有的描述方法，比如C2（Component-Connector）等。对它的工具支持比较的少，现在大多数尚处于研究阶段。

　　 2、设计模式：提供对面向对象的具体设计中的问题的解决方案，使得设计的结果更具有良好的可扩展性和重用性。通常所说的设计模式，是指的GoF一书中所分类的好了的23个模式。设计模式更具其设计功用，被分为构建型，结构型和行为型三类，包括桥接模式，工厂模式，组合模式等等。对这些模式的描述以及工具支持已经比较成熟。现在已经出现了一些支持设计模式的CASE工具，比如TogetherJ，Rational XDE等。其中以XDE对模式的支持最好。本文将在后面的文章中就XDE中的模式开发展开讨论。

　　 3、习惯用法（Idiom）：是针对具体语言的使用模式。主要涉及的问题是，如何用特定方法来解决程序代码编写过程中所遇到的问题，如何更优的编写程序代码。通常一种语言，比如Java，C++等，都会有相应的Idiom。这种模式的抽象层次比较低，且涉及到具体的语言，在这儿不予过多的讨论。

1.2 UML的模式机制--协作，参数化协作

　　 在早期的UML中，并没有提供对模式的支持。而随着模式的日益普及，OMG也终于在新版的UML引入了新的概念来提供对模式建模（主要是设计模式）的支持。

　　 稍稍熟悉UML的人，会对协作图（Collaboration Diagram）的非常地了解，协作图是UML的9大视图之一，主要用来提供对模型的动态描述。

　　 而协作（Collaboration）的概念同协作图其实并不太一样。在面向对象的模型中，一个特定的行为，是由一组对象以及对象之间的消息传递来实现的。这种模型信息就是由协作来表示。协作描叙了在一定的语境中一组对象以及用以实现特定行为的这些对象之间的相互作用。它包含结构和行为两个方面，结构方面与静态视图相似，包含一个对象（更为确切的说应该是角色）的集合和他们之间的关系。行为方面是一个消息的集合，这些消息在具有某一角色的各对象之间进行传递交换，也就是所谓的交互（Interaction）。协作的静态方面可以用类图来表示，协作图实际上也给出了一些静态的模型信息，而动态方面的描述通常使用顺序图（Sequence Diagram）或者协作图来表示。

　　 从这个角度来看，模式就是一种协作。对设计模式而言，它实质上描述的就是对象的结构以及对象之间的交互--并应用这样的一种协作来解决某一个问题。在UML中，模式使用的是一种特殊的协作，参数化的协作（parameterized collaboration）来表示的。

　　 在一个参数化的协作中，协作的参与者（比如类，也可以是关系等其它元素）可以是一个泛化的协作的参数。每当应用这个协作到一个具体的模型中去的时候，用具体的模型元素来替代这些参数。这样，在这个协作中参数之间的关系就被固定在这个模型中了。虽然对设计模式而言，它包含了比协作更多的含义。但是这样的一种参数化协作的建模方式，已经能够描述模式大部分的语义信息。模式还可以包括使用背景，使用指导，以及使用后果等其他的描述，这些内容可以作为注释写在单独的文本文件中。

　　 在使用UML来对模式进行建模的时候，可以遵循如下的步骤：

　　 1. 对一个重复出现的问题给出一种普遍的解决方案，并将其细化成一种机制。因为方案往往只是概念层次上的，要有具体的实现，才能够称其为模式。而普遍的含义更为重要，重复出现的问题，通常会有不同的问题背景，要在这些不同的背景中找出公共的问题域，也并不是一件容易的事情。

　　 2. 在抽象出的问题域中，将上述的机制建模为一个协作，即包含了其静态的结构和动态的交互的一个名称空间，这可以看作是一种抽象，模式也就是这种抽象的产物。

　　 3. 找出模式中必须要绑定到具体的应用中去的部分，将其建模为协作的参数。参数提供了对模式进行扩展以及实现的可能。正因为问题背景的复杂与不同，才需要具体的参数来订制模式。

　　 实际上对模式的捕捉以及实现，是一个很复杂的过程，已经超出了本文要讨论的范畴，这儿给出的步骤，也不一定就能够应用到所有的情况。这儿关注的是，如何用UML来表达一个模式的内容，下面来看一个例子。

　1.3 一个例子

　　 下面我们将试验一个简单的设计模式：命令（Command）模式，看如何将其用UML表示出来。并如何应用到一个具体的模型中去。这儿不再详述命令模式的具体的语义，如果有不太熟悉的地方可以参考GoF的《设计模式》一书。

　　 命令模式有如下的结构：


图1：命令模式的结构类图

　　 我们将其每一个部分都看作是一个协作的参数，得到如下的一个参数化协作：


图2：命令模式对应的参数化协作

　　 或者，我们还可以用一个额外的顺序图来表示这个模式的动态行为：


图3：命令模式的动态行为顺序图

　　 我们再来看一看模式的的应用，在一个具体的模型中，比如说EJB的模型，假如设计需要使用命令模式来完成一个Command的EJB调用层（关于EJB中的命令模式，具体可

[1] [2] 下一页