前言

我们搞技术的有很多误区，比如经常陷入纯技术钻牛角尖的争辩，而全然不顾业务场景，技术活做太多，经验一箩筐，但是有时会疑惑，这些经验是否适合其他自己没有经历过的新系统呢？我们在技术设计路线上走得太久，容易迷失方向，什么是设计不足；什么是过度设计，如何把握这个度？

在对待项目上，有一种极端是认为每个项目都是特殊的，不可能和其他项目有共同之处；这算是一种经验主义吧。 甚至有些程序员唯大项目不做，认为只有大项目才能锻炼自己，做过大项目的认才是牛人。

这些误区都是因为我们软件基础知识的缺失，没有人告诉我们，大小不同项目是否有共同点？ 我们现在做的项目需求是处于所有项目需求领域中何种位置？为满足这个业务需求我高质量高效率完成了这个软件系统，那么在这个软件系统中体现的解决方案是否适合其他项目中其他类似的需求呢？

以前，通过设计模式我们已经完成了设计上重用，再通过重用框架，可以更高效粒度高大地更高质量地实现大部分系统， 但是，看上去同一个业务需求，在不同的项目，每次还是需要我们对这些框架进行重新组织设计，哪怕它们有些相同之处， 例如： 在电子购物系统中有商品和用户两种重要元素，商品本身是一个物，而且可能有层次类别区分；商品和用户必然发生关系；在论坛系统中也存在帖子和用户两个元素，帖子是一个物，本身也有 类别区分，每个帖子必然和一个用户发生联系。这两个系统使用J2EE实现，当我们进行建模分析时，发现彼此之间隐约有一些共同之处。具体架构时又会涉及到表现层、业务层和持久层设计，两者几乎都可以使用相同的架构如（Struts+Jdon+Hibernate） 等等。

那么，能不能省却我们在每个项目上都会这些类似相同的需求重新再做一次设计架构呢？如果设计模式重用是针对一个具体设计场景而实现的重用，现在我们几乎不再满足这种细粒度的低效重用效率，如果我们能抓助软件源头：业务需求，总结出某一类问题的共同之处，那么与之相联系的整个解决方案 也许就能够得到重用，这种重用粒度更大，从而更高带来开发效率。

但是，有一个问题：不同项目的业务需求之间到底是否有共同之处？大项目和小项目的业务需求是否有共同之处？ 我们每做一个项目，是否可以达到一叶知秋的效果呢？

业务需求在我们软件系统一般用Model来统指，笔者曾经提出：域建模、模式和框架是Java软件的三个大方面， 其中域建模起着关键龙头作用，如何分析业务需求，如何实现正确的类图（建模）表达，是决定整个系统成败所在。更有这样的观点：No model,no patterns ,then no framework Model代表业务场景，没有业务需求，就没有设计模式，也没有框架。

几年前诞生的MDA是在这个方向进行了探索，很多先驱大师更在这方面进行了理论探索，如果说OO是对现实世界的一种抽象，那么MDA是比OO更加抽象的一种技术或方法论。“我们在一个软件革命的开始，它象90年代我们看到的面向对象编程从传统过程语言中抽象出来一样。”

原型archetypes

原型一词来自于希腊语archetypo (arcetupo), 意味着 "original pattern." （原始模式）

比如英雄这个原型在美国或在中国看上去可能不一样，但是英雄就是英雄，我们还是能够很快地总结出英雄的一些特点。 因为原型是人类组织、总结和概括客观世界的基本概念，我们完全有理由在软件开发领域应用这些概念。

业务原型business archetypes

OO软件系统是对业务领域（business domain）的思考抽象并进行管理操作，注意业务领域这个概念，我们相信应该能在业务领域中发现原型，或者在软件系统；或者这些系统模型中。我们称这种原型类型为业务原型（business archetype）

一个业务原型应该是一个在业务领域或商业软件系统持续发生并且普遍存在的最初级的事物。

Party是一个业务原型例子，一个Party代表可标识的、可定位的单元或单位，这些单位有正常的 状态。 通常一个Party用来表示某个人或某个组织。所有商业系统都或多或少有Party概念。

原型之间是相互交互的，Party, Product, 和 Order是每个虚拟商业系统的基本概念，在这个商业系统中，你可以卖产品或服务。我们将这些原型之间的协作看成是业务原型模式(business archetype patterns).

业务原型模式business archetype pattern定义：它是在业务领域或商业软件系统持续发生并且普遍存在业务原型之间的协作。

原型（Archetypes）和分析类（analysis classes）区别

分析类（analysis class）是代表问题域中一种即时抽象，它对应真实世界的业务概念。
设计类（Design class）是一种达到可以实现程度的类。分析类是用于理解业务；而设计类用于理解技术解决方案，例如设计模式。分析类是从问题域（业务需求）中提取的，并没有具体实现特点； 而设计类包含来自问题域（业务需求）和解决域（e.g., J2EE, .NET, or Web services）的特性， 从设计模式的使用特点可以了解这些，有人曾经单纯拿出一段if else语句，而不考虑问题域； 就试图使用某个模式替代这段if else，这就是因为他没有认识道设计类的这个特点。

原型总是比正常的分析类更加抽象，属于位于目前抽象层次的更高端，因此，通常原型模式可以生成一个或多个分析类。

原型模式和分析模式的关系怎样，原型模式是分析模式吗？不是，从定义范围上看，原型模式有很多特性看上去要比分析模式多。分析模式是首先由Matin Fowler提出并定义如下："分析模式是一组概念，这些概念代表业务建模中一个普遍的构建，它也许和一个域相关；或跨越多个域。 其中并没有任何原型的概念。

原型模式比分析模式要更加丰富，体现以下几点：

原型模式可以使用UML来表达（Together中可以实现）； 原型模式可以作为一种平台独立Model（PIM）适合MDA开发流程； 而这些分析模式则都不可以。

四色原型

四色原型是诞生于90年代，现在被广泛使用的一种系统分析方法，如Borland的Together架构师版，准确地说，是由Peter Coad 和 Mark Mayfield首先提出[Coad92],然后由David North拓展[Coad95-97]

1. moment-interval
2. role
3. catalog-entry-like description
4. party, place or thing

前面已经说过，域建模是整个软件系统的龙头，在现代Java技术开始之前，我们都是需要领域建模，也就是在UML中画出类图，然后标记上类图四种关系（关联、依赖、继承和实现），但是这些只是UML图的表面，只是一种画图技巧，就象CAD画图一样，你可能没有被告知：这个类图是怎么出来的？为什么选用关联而不是依赖，这些实际都属于分析领域的知识，而四色图可以说为我们这种分析提炼提供了一种模板或分析框架，这样我们可以按图索骥去分析每个陌生的系统，我们拥有强大的分析方法工具。

moment-interval archetype

这是一个很重要的原型，重要在于时间概念上：某个时刻(moment)或一段很短时间(interval)内. 意味在某个时刻发生的事情因为业务要求或合法性原因需要跟踪；或者过一段时间以后，应该是很短的时间，可以帮助我们寻找到它。

卖东西是在某个时刻发生的，它有发生日期和时间。租赁行为是在一段时间内发生，从开始出租和归还所租物品；预定也是持续一段时间，什么时候预定；什么时候过期等。

这些我们都使用moment-interval原型来表达，UML图如下：

Moment-intervals是和组件模型捆绑在一起，代表了组件模块关注的核心和灵魂，在一个Model中，Moment-intervals经常封装的是最关键的方法，为让其显目，moment-interval的UML图我们使用粉红颜色表示。在代码上用@标识符标识：

/** @archetype moment-interval*/
public class Sale {
　　public BigDecimal calcTotal(){
　　}
　　private int number;
　　private Date date;
}

在任何领域中，我们都能寻找moment-intervals原型并且开始建模，在原材料资源管理系统中，我们可以这样对待从报价单（RFQ）到购买订单（PO）直至发票，在一个制造管理系统中，我们也就可以将一个计划的过程和步骤分析到实际过程和详细步骤。

原型在帮助指导建模方面一个有效方式是：它能标识那些被包含在Model模型中的类（Classes）以便于区分，原型不只是简化了类的区别；原型还可以区分类的行为职责（responsibilities），例如类的属性，方法等。

role archetype

角色原型比较容易理解，任何一个系统都需要人或某个组织介入运行，例如论坛系统需要注册者角色发言；销售订单需要业务员角色制定，等等。

这里有一个Party原型定义：它表示一个可标识、可定位的单元，这个单元有自己正常的状态并且能够自主控制自己的一些行为，通常情况下，人或组织是一种Party，但象护照，身份证等注册性标志等都可以作为Party。

注意，并不是说Party或人或组织就是Role原型，必须Party或人或组织参与一种活动后才为角色，就象张三在电影中表演皇帝，他只有参与电影表演才是皇帝角色；李四在XX公司的角色才是经理，他只有参与这家公司运作才是角色经理；否则他们只是一个Party原型。

所以，Role角色是Party扮演的（a role that a Party plays），Party是角色Role的扮演者（role-player）。

当我们在建模时，对于一个角色扮演者，可以有他自己的核心属性如名称、年龄（以人为例子），也可以有与业务相关的方法，比如一个小店，当店老板去收钱时，他的角色就是收银员（cashier），此时可以将与收银员角色相关业务特点加于其上；当然，同时他也可以是老板（Owner）角色。那么下图中authorizedFor方法就是参与每个角色的行为，当他作为某个角色被授权登录后，与此角色相关的业务特点就应用在他身上。

大家已经注意到了：角色原型在UML中是使用黄颜色标识的。角色模型是第二重要的原型，所以使用黄色。

我们已经知道，Party是一个又自主行为、能够控制自己行为的表示，如人或组织，还有其他没有自主行为的表示，也就是某个地方或位置或某个事情，我们一般称( place, or thing)，不但Party可以成为角色，而且 place或thing也可以成为角色，比如，一个商品Product可能又两种角色：在销售过程中商品；正在使用的商品。

party, place, or thing archetype

上面我们说过，party place或thing都可以成为角色原型，注意到角色原型中的UML图，party图是以绿色表达。

Party表示有自己正常的状态并且能够自主控制自己的一些行为，通常情况下，人或组织是一种Party，但象护照，身份证等注册性标志等都可以作为Party。

Place or thing表示一样不会说话没有行为的东西，例如商品，当然这个商品可以扮演不同角色，既可以是零售的一个电源插座；也可以批发系统中的一个电源插座，它是被卖的，可能在不同业务系统被卖的方式不一样。

description archetype

种类description原型其实是第三重要的原型，一般情况下，它类似目录级别catalog-entry-like的种类，例如某个商品电源插座属于家用电器这个种类，当然家用电器又属于电器这个目录，是一个树形的目录结构。例如论坛中帖子和回帖之间也是一种种类原型。

比如你的红色福克斯是福特生产的一辆轿车，它有车牌号、购买日期、颜色和里程表等，这些代表Thing原型，那么作为轿车这个种类来说，它有一些种类属性，例如：生产厂家、生产批号、适用颜色等，这些属性是轿车这类所有车辆都共有的。

在设计模式这个实现级别，我们通常使用组合模式来实现种类原型。

Description原型在UML中使用蓝色表达。

四色原型图

每个原型图有属性和连接（关联　依赖等关系）两个部分组成。

上一个章节我们谈论了四色原型的基本定义，四色原型好像是这样一个场景抽象：某人参与某活动对某事情操作，基本上我们人类的所有活动都可以用这段抽象来表达，这说明四色原型帮助我们更快地分析分辨事物。

下面我们以Java Modeling in Color with UML书中案例详细说明一下四色图深入意义，如下图：

我们按照某人对某东西做某事的思路来理解上图，不同的是，上图中研究的不是某人(party)如何，而是研究Thing，如图中绿色类图中<<thing>>的标识。这样，这张图表达的是某个东西在一个活动或流程中发生的一些行为。

蓝色的description种类原型负责寻找这类东西中一个实例（图中findAvailable方法）并计算可用实例的数量，这两种功能都需要和左边绿色party对象交互。绿色的thing是判断自己是否可用（图中isAvailable方法），如果可以就返回一个优化的值；如果不是，向蓝色的种类原型要求返回一个缺省值；黄色角色是判断这个东西是否适合它的角色，这几种方式都是和粉红的moment-intervals发生交互的。粉红的moment-intervals原型可以创建这样一个东西实例（图中makeMomentInterval方法，支持业务过程来创建）；增加细节（图中addDetail方法）或组成部分；并且计算总和(calcTotal)；它也接受外界消息查询当前活动是否完成或者取消了（图中Complete和Cancel方法）等等。

用途之一：有助于正确的域建模

当我们接到一个软件项目时，首先是了解业务需求，这个过程是一个交互逐步深入的过程，了解业务需求有多种方式，如国外普遍推崇的Use Case，画出用例图和客户反复确认；或者在中国，由于客户层次限制，我们可能使用界面驱动方式，美工制作员首先制作出界面流程，供客户直观确认，反正方式多种多样，这不在本文讨论范围之内。

本文关心的是，当你采集到正确的业务需求后，你是使用什么方式把它传导到软件系统中，或者说：如何保证软件系统解决的正是你的业务需求？如何保证这两者之间对接完全正确，因为对接传导不正确导致软件系统失败的案例太多了，最后表现为软件人员和客户互相推委，损失的是双方时间和精力，这是谁也不想看到的，可是难道没有可依赖的科学方法吗？

这正是域建模所要解决的，每个业务需求总是有一定的解决问题，一个业务需求不可能解决世界上所有问题，所以业务需求提出的是一定范围内的问题，是一种域问题，而随之解决方案软件系统也是一种域解决方案，所以，在这个域中正确将业务需求传导到软件系统很正确，这就取决于我们的域建模。

谈到域建模，有人会问：在域建模概念出现之前，我们也做软件系统，那时是用什么分析方法？很显然，我们是使用数据库建模（使用powerDesign这样传统工具），依靠分析人员对这个行业过去的经验和走过的路，设计出数据表结构，然后交给程序员写SQL等数据CRUD增删改查方法，这是一种完全依赖数据库的分析设计方法，笔者已经在“数据库时代终结”一文中指出过，这种方式已经过时，数据库建模不能完全反应系统的全部特性和需求，使用同样一套数据库，完全由两套优差不同的设计方案和代码，从JiveJdon3.0和JiveJdon2.5两个版本完全可以明白： http://cosoft.org.cn/project/showfiles.php?group_id=5298，这两个版本都是使用同一个数据库结构，但是却是完全截然不同的设计和代码，软件的维护型和可扩展性就完全不同。

数据库驱动分析不仅带来业务需求和软件系统对接不正确，导致软件系统失败，而且，这种分析方法过于依赖系统分析人员的经验背景，导致系统分析员都是业务人员，而非专门的建模专家，不懂设计的业务人员还是无法做到软件系统和业务需求的正确对接，还是范域范围不对的老问题。

还有一种观点认为，域建模不过就是使用UML画出类图，他以前设计过这个领域的数据表，换成类图就可以了，类图和数据库建模图似乎表面一样，好像都是静态关系表达，其实不然，类图其实是动态的，是一种隐形动态，使用四色图表达的类图则是一种包含顺序图的完全动态图，可以说类图是立体多维的，而数据库模型图则是完全静态的。

那么当我们进行系统分析设计时，如果有一个类，到底应该给它标记什么颜色呢？也就是说将其归类为哪个原型呢？通过这种归类上颜色可以确证我们这个类提取的是否正确？或者可以说，我们可以按照四色原型从业务需求中提取抽象类，从而画出类图。我们可以按照下面考虑顺序：

第一：它是不是依赖时间上瞬间或一段短时间存在的，是不是业务需求需要跟踪记录的对象？如果是，它就是momentinterval原型（简称MI）。

第二：然后，它是不是角色呢？如果是，就属于黄色Role原型。

第三：然后，它是不是属于一种目录式的种类性质对象，或者代表一组呢可以反复使用的概念，如果是，它就是蓝色description原型。

第四：最后，它是某人或组织？或者是某个地方或者某个东西？那它就是绿色的party, place, or thing （简称PPT）。

可以将一个复杂的系统划分成一块一块，从而有助于设计实现，当我们一个系统有好几百个类图时，如果不采取四色原型进行归类，那么无疑很混乱，甚至类图提取不正确，概念重复，甚至只有在系统代码实现时才会发现如此严重问题，这对于分析设计来说无疑时重大打击。

Domain-Neutral Component(DNC)

一个业务系统是由多个四色图反复拼装而成，我们称为这种现象是Domain-Neutral Component模式，如下图（图片来自Step10）所示：

这样，我们可以将一个复杂可能是成千上万个类的类图划分成一个个小碎块，达到清晰分类的目的。你可以使用这种基于语义的类图模板进行任何系统的域建模，DNC最好的优点是异常的简单好用，你不必将你的模型Model填入DNC，而是DNC指导帮助更加完整地建模。

很多人认为类图是静态的；而顺序图是动态的，其实类图是隐形的动态；而顺序图只是显式的动态，顺序图是将动态执行过程完全表现出来，而我们从类图上好像看不到这点，其实你可以在四色类图中发现更多顺序图的影子，四色图中几乎无需另外使用顺序图来补充表达，而整个DNC内部的所有交互都是这样的，这无疑是令人激动的，也就是说，使用包含四色图的DNC已经可以完全表达一个系统了。

我们先看看类图中是如何虚拟表达业务三维系统中的联合association：

如图中上半部分，左边和右边两个类的关系association是用0..*表达，这说明是一个一对多关系，实际意思是图中下半部分，一个左边对应右边多个，所以，我们要从图中表达看到更加深远的意思，上半部分比下半部分表示更加节省空间，也只是空间上简化。

那么，如果左边的对象向右边的对象发送消息，形成交互动作了，是不是一定要使用方法method和顺序图来表示，为什么我们不能象上面空间简化一样进行动态简化，如下图：

我们可以在类图中表达顺序交互动作，这就是DNC作出的一个贡献。所以从一张DNC图的关系中，我们可以清楚的表达前后发生的循序调用。比如上面DNC图中一旦一个PartyRole访问Momentinterval，将首先访问PriorMI，还有MomentintervalDetails（当然，该图中没有列出方法，所以具体确切走向无法得知）。

十二种复合组件(Compound Components)

这12种复合组件是所有企业业务系统的抽象，说白一点，所有企业系统业务需求分析到最后，基本上都可以用这12种复合组件代表，换句话说：搞懂这12个组件模型，你就基本能迅速分析弄懂几乎的企业系统，从而进行快速的设计编码，这12种组件可以说是业务需求的复用，从而能使我们站在前人的基础上更快更准进入企业软件系统的分析和设计开发。

这12种复合组件是：

需要详细了解这些原型组件可参考Java Modeling in Color with UML一书。

Jdon框架应用

Jdon Framework作为一个新兴的开源框架，可能有很多人对其是否能够承受复杂应用表示怀疑，其实这些我们都是可以从四色图理论上进行论坛证。

以Jdon框架应用JiveJdon3.0为例，该系统使用Jdon框架其实已经完成了四色图需求，如下图

这已经说明使用Jdon框架可以完成一个四色图需求实现，而根据DNC理论，复杂的系统基本是由多个四色图重复组成，因此，我们完全可以反复使用Jdon框架，通过完成一个个四色图这样的基本单元，从而以组件拼装方式完成一个较为复杂的应用系统。

四色图和DNC理论实际上是我们面对大型纷繁复杂需求时的一个定心丸，同时也是检验一些新兴理论开放框架的一个基础平台。从此我们可以轻松地使用四色图分解出项目需求，从而确保项目系统实现完全符合原始需求，跨越项目需求和项目实现不对接这个鸿沟，也许以后我们不再会发生下面的情况：当我们辛辛苦苦用最新绚丽的技术完成软件系统后，兴致勃勃介绍给用户时，用户却说：这不是我想要的东西。

参考文章

http://www.step-10.com/notes/index.html

http://www.devshed.com/c/a/Practices/Design-with-ArgoUML/6/

Observations on the DNC(David Anderson)

Developing a UI Design from a UML Color Model