一般的需求,我们利用用例图就可以表达清楚了,如果再复杂些,我们可能还得再配合序列图、状态图等加于说明。但是,在非常复杂的业务逻辑中,怎么样才能找出它们的联系?而且还能更好地拥抱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) 返回“非基本用药费用”,
| ||
|