让技术人员看得懂的流程(3)
——领域模型
按照一般的项目管理过程,“需求”之后是“分析”,那么在分析阶段对应的技术流程又是哪个?如何将需求阶段和分析阶段联系起来呢?答案就是“领域模型”
什么是“领域模型”呢?只要抓住“领域(Domain)”二字就可以理解,也就是说领域模型是帮助我们理解相关领域知识的模型。
进一步来问:为什么需要领域模型?前面不是有“用例模型”吗,看起来用例模型好像就是描述相关领域知识的,是否完成用例模型就可以进行设计了?
如果你曾经写过用例文档,或者仔细看过用例文档,那么你肯定知道“用例”本身和“面向对象”、“类”这些都没有关系,用例就是纯自然的语言(比如英语、汉语)写的,因为用例实际上由客户口述给我们、然后由我们形成文档化的用例文档,客户才不管我们是什么面向对象还是面向过程还是阿猫阿狗的。
因此,单纯从用例来看,是没有类的概念的,无法完成从自然语言到面向对象语言的转换。但是,既然我们已经完成了用例模型,那么就必须基于用例模型进行分析(否则用例模型岂不是白做了),而“领域模型”就是自然语言向面向对象语言的一座桥梁。
让我们来看看“领域模型”阶段我们要做什么、该怎么做。其实很简单,简单概括就是“找名词”,分为四个步骤:(1)找出用例模型中的名词,(2)然后识别这些名词本身的相关信息,(3)以及名词之间的相互关联关系,(4)用UML画出领域模型。
我们来看在“用例模型”章节中的POST用例如何得出领域模型。
第一步:找出用例模型中的名词
原有用例如下,用蓝色加黑标出名词(重复的就不标了):
1)顾客携带商品到收银台;
2)收银员扫描商品条形码;
3)系统根据条形码获取并显示商品信息;
4)收银员重复2~3步,直到所有商品扫描完毕;
5)系统计算商品总额;
。。。。。。。。。。。。。。。。。。。。
n)系统打出商品清单,完成交易。
这个用例中的名词有“顾客”、“商品”、“收银台”、“收银员”、“商品条形码”、“系统”、“商品信息”、“商品总额”、“商品清单”、“交易”。稍加整理:
1)“顾客”、“收银员”是系统的外部对象,不需要我们进行设计,但这些对象要和系统进行交互;
2)“商品”、“商品条形码”、“商品信息”、“商品总额”、“商品清单”、“交易”是领域对象,但“商品条形码”、“商品信息”可以算作“商品”的属性、“商品总额”可以算作“交易”的属性,最后从这个用例总结出来的领域对象有“商品”、“商品清单”、“交易”三个。
第二步:识别这些名词本身的相关信息
一个对象的属性可能分布在多个用例中,因此可以通过迭代不断的完善一个对象的属性,大家可以看到,我们在第一步中的样例就已经分析了一部分了:“商品条形码”、“商品信息”可以算作“商品”的属性。
对象除了属性外,还有一些约束或者限制,这些在用例中可能有,也可能没有,这就需要分析人员来发现了。比如说交易金额必须大于0.1元小于99999元这种约束,用例中不一定会体现,可能需要分析人员向客户咨询。
第三步:识别对象间的关系
面向对象设计就是依靠对象间的互相协作来配合完成相应的功能,因此识别出对象和对象本身的属性外,还要识别对象间的关系,例如1对多、1对1、依赖等,详细的各种关系可以参考UML的标准定义。
我们以第一步识别的三个对象为例:“商品清单”包含多个“商品”、一次“交易”对应一个“商品清单”、一个“商品”只能属于一个“交易”等。
第四步:画出领域模型UML图
UML这里就不啰嗦了,我们结合前三步的分析,画出这个样例的UML领域模型图:
(由于CSDN关闭了图片上传功能,因此无法贴出,大家可以根据前三步自己画一个)
大家可以看到,经过“领域模型”的分析后,已经完成了自然语言到面向对象语言的初步转化了,领域对象已经识别出来,面向对象已经初具雏形。
需要提醒的是:领域模型过程中识别出来的对象和具体的语言无关,也没有方法。换句话说,public、private、函数这些面向对象的属性在领域模型阶段不需要分析出来。