四色原型

前言

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

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

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

　　以前，通过设计模式我们已经完成了设计上重用，再通过重用框架，可以更高效粒度高大地更高质量地实现大部分系统， 但是，看上去同一个业务需求，在不同的项目，每次还是需要我们对这些框架进行重新组织设计，哪怕它们有些相同之处， 例如： 在电子购物系统中有商品和用户两种重要元素，商品本身是一个物，而且可能有层次类别区分；商品和用户必然发生关系；在论坛系统中也存在帖子和用户两个元素，帖子是一个物，本身也有 类别区分，每个帖子必然和一个用户发生联系。这两个系统使用J2EE实现，当我墙?薪?７治鍪保?⑾直舜酥?湟?加幸恍┕餐??Α＞咛寮芄故庇只嵘婕暗奖硐植恪⒁滴癫愫统志貌闵杓疲?秸呒负醵伎梢允褂孟嗤?募芄谷纾⊿truts+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技术如JiveJdon3.0开始之前，我们都是需要领域建模，也就是在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中使用蓝色表达。

四色原型图

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

原文转自：http://www.ltesting.net