UML软件工程组织

　　摘要：

　　软件模式，特别是设计模式在现今的软件开发中越来越重要。在许多的标准，工具，以及开发方法中都引入了模式的概念。本文介绍了如何在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中的命令模式，具体可以参见《EJB模式语言》一书，这而为了简便起见，作了一些的简化。）根据命令模式的语义，可以对模板参数作如下的绑定：

模板参数绑定对象

Invoker Containerr

Command Command（自动生成）

ConcreteCommand ConcreteCommand（自动生成）

Receiver Bean Context

State State（自动生成）

Client Remote

表一：命令模式到EJB模型的绑定

　　在UML中，模式的绑定表示为构造型为<<bind>>的依赖关系，从被绑定的协作指向模式所代表的参数话协作。可以可选的在依赖关系上给出绑定的结果。如下图所示：

图4：模式的绑定之一

　　可以用UML来表示具体的绑定结果：为了生成协作而绑定模式用虚线椭圆表示，椭圆中包含了模式的名称；在从椭圆到每一个参与协作的类之间画一条虚线，并在虚线上标明参数的名称。

图5：模式的绑定之二

　　绑定之后，模型中引入的命令模式的语义，得到这样的一个结果：

图6：绑定的结果

　　1.4 关于协作的一些后续话题

　　协作说明了众多参与者之间的交互方式，而这些参与者，并不仅仅局限于类或者接口。它可以是一个类元或者链。实际上，在协作中的参与者，并非是类或者，接口，是一种新的建模元素，称之为协作角色。协作角色代表了一个对象结构中的命名槽（slot），表示出在特定语境中的元素的行为。它并不表示实际存在的对象或者链，而是当协作实例化时，对象或者链被替代的位置。从这种意义上讲，协作角色相当于一个函数中的参数。

　　一个类元也拥有具体的类型，比如说类，接口，或者子系统等等。就像函数调用时提供给其的参数值要满足参数的类型一样，在应用模式时，类元的类型也需要得到满足。比如，你不能够把一个接口类型的类元角色绑定到一个类上去。从传统意义上的类或者接口，到协作中的协作角色，可以说是一种建模思想上的变化。角色这个词，也很好的体现了这个概念。可以用它同电影中的角色进行类比，只要任何人，瞒住了角色所提出的要求（比如性别，年龄，演技，等等），都可以充当这个角色的扮演者。而角色并不是一个具体的对象，而是由一个对象来承担。在这一点上，同Java中的接口的概念比较类似，但更为抽象。

　　协作角色包括类元角色和关联角色。对这一点，后面还会提到，在XDE中，角色的概念已经被扩充，而不仅仅只是能标是类元或者关联，而能够表示任何合法的UML模型元素。比如属性，方法，甚至视图。这样，模式的表达能力被大大地增强了，模式也能够拥有更为丰富的语义。

　　在后续的系列中，我们会使用Rational公司最新的XDE工具来实现对模式的建模与使用。XDE是最新的集建模与编码于一体的IDE，在很大程度上代表了今后IDE的发展方向，它所提供的强大的模式机制，能够将UML中对模式的建模能力，现实的转化为提高软件生产率的有效工具。让我们在下一期的系列文章中再见吧。