一般的需求，我们利用用例图就可以表达清楚了，如果再复杂些，我们可能还得再配合序列图、状态图等加于说明。但是，在非常复杂的业务逻辑中，怎么样才能找出它们的联系？而且还能更好地拥抱OO（面向对象），OO的优点不是我们本文的话题。
这里笔者介绍一种很灵活很实用的分析方法--四色原型图，也叫彩色UML。
（图片引自JDON的BANQ大师之手）
四个元素的介绍：
moment-interval ：
粉红色的时刻—时段：一个时刻或一个时段，您需要追踪它或做某事，通俗地说其实就是关键动词，就是服务，很容易在这里面抽象出事物逻辑类。
例如：计算、补偿、结算等。 mi-detail ：通常，粉红色的时刻时段会有一些组成部分，称为mi-detail（时
刻时段明细），
role ：
黄色的角色，角色不一定是人，这个很重要，可以理解为一些有行为的名词。
catalog-entry-like description ：
蓝色的描述（类似产品的目录项），可以在这里找出
值对象，持久化的对象。
party, place or thing ：
绿色的参与方—地点—物品，可以从这里找出模型、实体。
总体总结：“时刻时段”发生了，“事物”们扮演不同的“角色”参与进来“事物”变化的规
律和“描述”有关。
主要参考了BANQ的：http://www.jdon.com/mda/archetypes.html
和yananay的：http://www.iteye.com/topic/399672#1055483
下面说一下最近学习后用到项目中的一个例子：
1、一开始最主要的其实是找出最基本的原型MI，即红色，这里的原型是住院补偿。
2、然后慢慢找出与之相关的一些东西，计算住院补偿是有一个公式的，围绕着公式可以抽象出一些元素、比如总费用。
3、再涉及到的“非基本用药费用”的时候又可以找出一个计算的MI，再围绕MI继续抽取，最终可以抽取出以上详细的流程，也很符合面向对象的思维。
总结：类图可能大家会认为没能表达出状态和时序等时间上的概念，但是四色原型其实是蕴含着时间状态的，所以在设计分析复杂的业务的时候确实是一个好的工具，这里引用一下BANQ大师的另一个图：
我个人看法，四色原型也不是万能药，但是在分析复杂业务的时候他确实很直观，非常容易找出内在的一些需求，所以我个人认为在整个开发的过程中，四色原型用于复杂业务的分析非常有用。
个人写作的水平和能力有限，这里权当抛砖引玉，希望大家对我存在的不足批评指正，谢谢。
以下附上我的部分分析文档：
实体：
| 实体 |
描述 |
| 参合农民 |
新农合的主要参与者 |
| 病例清单 |
记录了患者治疗和用药的情况 |
| 医疗证 |
医疗证 |
| 家庭 |
参加新农合的家庭 |
功能详细说明：
| 功能序号 |
功能名称 |
子功能名称 |
功能描述 |
| MED_REC_MI_2 |
住院补偿 |
参合患者基本信息 |
§ 前置条件：参合患者个人编号 § 最终结果：查询参合患者个人信息、户信息、医疗证信息。 参合患者基本信息，根据参合患者的个人编号，获取其个人信息、户信息和医疗证信息。 1) 获取“参合患者的个人”，根据“参合患者个人编号”读取“农民个人基本数据D401”数据表。 2) 获取“户信息”，根据“参合患者个人编号”读取“家庭档案数据D301”。 3) 获取“医疗证信息”，根据“参合患者个人编号”读取“农民缴费及家庭帐户管理部分D601”。
|
| § |
|||
| 一般住院补偿 |
医院总医药费用
§ 前置条件：每一次住院费用清单 § 最后结果：医院总医药费用 医院总医药费用，根据“病例价格清单”计算总医药费用。 1) 读取病例价格清单信息。 2) 计算未得到补偿的住院费用。
非基本用药费用
§ 前置条件：医院药品价目单，基本用药目录，用药比例。 § 计算结果：非基本用药费用 非基本用药费用，就医药品价目单，基本用药目录和用药比例计算非基本用药费用。 1) 读取病例价格清单信息，获取药品名称、用药数量、药品单价。 2) 计算“总药费”，根据药品名称、用药数量和药品单价计算总药费。 3) 计算“基本用药费用”，用病例清单的药名和“基本用药目录”进行对比，把匹配的药品费用相加。 4) 计算“非基本用药费用”： 5) 返回“非基本用药费用”，
|
||
|
|