四色原型（二）
下面我们以Java Modeling in Color with UML书中案例详细说明一下四色图深入意义，如下图：
我们按照某人对某东西做某事的思路来理解上图，不同的是，上图中研究的不是某人(party)如何，而是研究Thing，如图中绿色类图中<<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种复合组件是：
| Make a Buy Sell Relate CoordinateandSupport MaterialResourceMgmt ProductSaleMgmt HumanResourceMgmt ProjectActivityMgmt FaclilityMgmt CashSakeMgmt RelationshipMgmt AccountingMgmt ManufacturingMgmt CustomerAccountMgmt DocumentMgmt InventoryMgmt |
需要详细了解这些原型组件可参考Java Modeling in Color with UML一书。
Jdon框架应用
Jdon Framework作为一个新兴的开源框架，可能有很多人对其是否能够承受复杂应用表示怀疑，其实这些我们都是可以从四色图理论上进行论坛证。
以Jdon框架应用JiveJdon3.0为例，该系统使用Jdon框架其实已经完成了四色图需求，如下图
这已经说明使用Jdon框架可以完成一个四色图需求实现，而根据DNC理论，复杂的系统基本是由多个四色图重复组成，因此，我们完全可以反复使用Jdon框架，通过完成一个个四色图这样的基本单元，从而以组件拼装方式完成一个较为复杂的应用系统。
四色图和DNC理论实际上是我们面对大型纷繁复杂需求时的一个定心丸，同时也是检验一些新兴理论开放框架的一个基础平台。从此我们可以轻松地使用四色图分解出项目需求，从而确保项目系统实现完全符合原始需求，跨越项目需求和项目实现不对接这个鸿沟，也许以后我们不再会发生下面的情况：当我们辛辛苦苦用最新绚丽的技术完成软件系统后，兴致勃勃介绍给用户时，用户却说：这不是我想要的东西。