四色原型图

四色原型是诞生于90年代，现在被广泛使用的一种系统分析方法，如Borland的Together架构师版，准确地说，是由Peter Coad 和 Mark Mayfield首先提出[Coad92],然后由David North拓展[Coad95-97]
moment-interval
role
catalog-entry-like description
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中使用蓝色表达。
四色原型图

每个原型图有属性和连接（关联　依赖等关系）两个部分组成。
=====================分割线====================
2.5. 举例
比如，“人”就是一个Desc，而“亚洲人”、“黄种人”也是一个Desc，亚洲人和黄种人都属于“人”这个Desc的子Desc，即Desc可以是一个树结构。
具体到每一个人的时候，“张三”、“李四”就是一个PPT了。因为张三和李四是独一无二的，他们都有唯一标识符可以被识别、区分（比如身份証号、指纹等，视不同的系统需求采用不同的唯一标识）。

2.6. 总结
如果以PPT为中心，那么以上概念可以总结为：什么东西（人或事物）通过什么方式（身份）进行什么操作（业务）。
即当 PPT是Role时，可以调用MI。例如当张三是学生时，可以去上课。
如果以Desc为中心，那么以上概念可以总结为：什么什么类型的东西进行什么操作（业务）。
即MI调用Desc。例如人都可以睡觉。
规则1：PPT不能直接与 MI打交道，它必须通过Role或者Desc才能操纵MI。
为什么要隔绝MI直接访问 PPT？
如果MI直接访问PPT会带来以下问题：
1. PPT如果直接参与MI，那么PPT就会拥有MI 环境中的属性，比如电脑在维修时必须记录维修结果，在销售时必须记录售价，那么PPT随着MI的增加会不断地膨胀，每增加一种MI，PPT就要修改一次。
2. 两个MI之间业务是完全不同的，PPT中有些属性对某一个MI来说，根本是无用的。例如电脑的价格，对维修来说是无用的。
3. MI直接使用PPT，还会带来MI之间的资料隔绝性问题。有些PPT的属性对某一MI是不允许访问的，如果MI直接使用PPT，那么就无法保密资料。
例如，电脑的折扣可能是保密的，不应该让维修知道。
增加Role之后，上述问题迎刃而解：
每增加一种PPT，就相应地增加一个 Role，凡是与此MI相关的属性，都放在Role中。这样既避免了PPT的频繁修改，也避免了资料访问的问题。
可以这么描述Role：只有当事物（PPT）具有某个身份（Role）时，它才拥有与业务（MI）相关的属性（字段和方法）。

4. 特征驱动开发
4.1. 特征
特征是一个具有客户价值的功能。
特征描述的模板：
 the   a(n)