四色原型是诞生于90年代,现在被广泛使用的一种系统分析方法,如Borland的Together架构师版,准确地说,是由Peter Coad 和 Mark Mayfield首先提出[Coad92],然后由David North拓展[Coad95-97]
- moment-interval
- role
- catalog-entry-like description
- 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中使用蓝色表达。
四色原型图
每个原型图有属性和连接(关联 依赖等关系)两个部分组成。
=====================分割线====================
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. 特征
特征是一个具有客户价值的功能。
特征描述的模板:
<action> the <result> <by | for | of | to> a(n) <object>
object表示一个人、地点或物品,即包括角色、时刻时段、分类目录条目的描述。
例如:
Calculate the total of a sale(计算一次销售的总额)。
Calculate the total purchase by a customer(计算一个客户总采购额)。
4.2. 特征集
特征集是一组业务上相关的特征。
特征集描述的模板:
<action><-ing> a(n) <object>
<object> management
例如:
making a product sale(进行一次产品销售)。
5. 为什么需要四色原型分析
一个模块,必须有活动(MI)、参加活动的对象(Role),以及活动资源(PPT),才能组成一个有业务含义的模块。