一个房屋中介业务建模的实例分析

转自:http://blog.csdn.net/coffeewoo/archive/2008/11/18/3327592.aspx

一位名叫Midhael Yan的朋友给我发来一封信，信中谈到这样一个问题。我觉得很有代表性，因此公开发布到BLOG上。这位朋友的问题是这样的：

一个租房中介准备提供一个网上中介服务系统，主要包括以下服务：
给求租者发布求租信息，寻找房屋信息
给出租者注册一个店面，在小店里发布出租房信息，也支持寻找求租信息
使用该服务必须注册一个用户
对房屋有收藏和评论的需要
我和几个朋友初步探讨了一下，在业务建模阶段出现了争执
我的分析：
一个求租者业务角色
一个出租者业务角色
发布求租信息业务用例
找房屋信息业务用例
注册店面业务用例
发布出租房屋信息业务用例
注册用户业务用例
朋友的分析：
一个求租者业务角色
一个出租者业务角色
发布信息业务用例（注册店面业务用例也被合并进来了）
查询信息业务用例
注册用户业务用例
另外一个朋友的分析更简单：
客人业务角色
发布信息业务用例
查询信息业务用例
请您给出您的见解，谢谢！

非常有幸拜读你的文章，收益甚多，谢谢！
有几点问题，希望指正！
1、关于你的网上借书范例
对于你把图书管理员这样的业务工人定义成了业务角色有点不解
2、我模拟了一个网上中介系统的范例，遇到了一些两难问题，请教
一个租房中介准备提供一个网上中介服务系统，主要包括以下服务：
给求租者发布求租信息，寻找房屋信息
给出租者注册一个店面，在小店里发布出租房信息，也支持寻找求租信息
使用该服务必须注册一个用户
对房屋有收藏和评论的需要
我和几个朋友初步探讨了一下，在业务建模阶段出现了争执
我的分析：
一个求租者业务角色
一个出租者业务角色
发布求租信息业务用例
找房屋信息业务用例
注册店面业务用例
发布出租房屋信息业务用例
注册用户业务用例
朋友的分析：
一个求租者业务角色
一个出租者业务角色
发布信息业务用例（注册店面业务用例也被合并进来了）
查询信息业务用例
注册用户业务用例
另外一个朋友的分析更简单：
客人业务角色
发布信息业务用例
查询信息业务用例
请您给出您的见解，谢谢！
合适的话也希望把这个范例单独在您的BLOG上发布出来，供大家一起探讨，谢谢！

这个讨论很有代表性，把它贴出来：）

我对第一个问题是这样看的，在我平时工作中有意忽略business actor,actor,business worker,worker这样的区别。因为我觉得，虽然在UML概念上它们是不同的，这样定义有其道理。但是这种概念的差异太过于学术化。在实际工作中，大家都熟悉岗位，角色这样的概念，甚至用户对岗位，角色这样的定义都有非常好的认识。但对于不熟悉UML的人来说，如果试图去向他们解释什么是 worker什么是actor，什么是business actor...我认为这是件费力不讨好的事情，我曾经试过，很难让人理解这么些小人图到底有什么差别。做一个业务模型的目的是让所有相关人等看得明白看得懂，而不是是否符合UML的规定。我用UML的一个观点是适合的采用，不适合的修改甚至放弃。我承认UML的定义是有道理的，但我不认为在实际工作中这样做会带来好处。在我们说明需求的时候，如果就是不区分actor 和worker，我们就会说不清需求了吗？我相信不会，相反的，如果我们用岗位这个概念来做业务模型，用角色这个概念来做系统模型，那么对所有相关人等都会是很好很容易理解的。所以实际上，在我做业务建模的时候，虽然用了UML的元素，但实际我的概念是岗位、角色，我认为这两个概念足以支持业务分析，并且容易理解，而抛弃了UML拗口复杂的定义。这在实际工作中给我带来了很多方便。


第二个问题，总的来说，我支持你的分析。我的理由是：

首先分为求租者和寻租者我是支持的，定位很准，而客人业务角色呢，我猜想你这位朋友带了抽象的思想在里面，实际上他的意思是不论求租者和寻租者在将来的 WEB应用程序看来都是通过同一个界面登录的，可能也是通过同一个界面管理的。所以从ID的角度说，他们是一样的。但我不支持在这个时候带着实现的思想，而要从业务角色的目的上去区分它们是否应该合并。显然，求租和寻租两者的目的是完全不同的，在业务角度说，他们没有任何可以合并的理由。至于到了系统用例阶段，由于他们可以共享同样的登录模块，同样的ID管理，抽象出一个客人角色是合理的，但在业务阶段这个抽象是不合适的。同一个参与者使用同一样用例却抱着不同的目的，这违反用例的基本定义。

其次，在业务用例的获取方面，可以参考我在第一篇文章里讲到的用例的四个特征，你的业务用例定义符合得很好。对于你第一个朋友的定义，发布信息这个业务用例，同时包含进了注册店面，我不大赞同。原因在于，业务用例带有“原子”特性，也就是说一个业务用例应该能够不依赖于别的业务用例而完成一个参与者的目的。如果按你第一个朋友的定义，会有这样一个结果，寻租者启动同一个用例，然后去做一件事情，而这件事情与用例中另一件事完全无关。例如这样一个场景，某个出租者，注册了店面，成功后就离开了，显然，他并没有做发布信息的事，发布信息并没有在这个场景中发挥任何作用，反之也一样。既然这两件事情可以独立存在，就应当独立成用例。我猜想你朋友的意思是，要发布信息，就要先注册店面，有无店面是发布信息的一个前置条件，因此把它包括进来。如果是这么想的，有其道理，但就这个事例来说我还是觉得不合适，我提出这几个问题：是否要发布信息就必须有房间？是否每发布一次信息都要注册一次房间？一个ID是否能够注册多个房间？如果房间有时限规定失效了以后怎么办？如果客人想注销房间呢？想想看，这些问题都是针对注册房间的，如果注册房间是发布信息用例的一部分，结果是什么呢？为了发布一条信息而已，客人被要求做那么多准备工作，开发人员写了N多if-else。可其实呢，以上的问题都不直接涉及到发布信息的过程啊，方法啊这些。可见，把两个原本独立的目标（一个客人上来，可以只发布信息，也可以只注册房间，未必都要做）合并，会造成混乱。如果要问，我提的那几个针对房间的问题，的确会影响到是否可以发布信息啊，还有信息发布到哪里啊？没错啊，是否可以发布是发布信息的前置条件，发布后被放到哪里是发布信息的后置条件，它们都是在发布信息之外的，换句话说，注册房间和发布信息之间有一些业务规则需要定义，仅此而已。这和我们不需要在每个用例里都去包括注册用户用例是一个道理，虽然没有正确的ID注册和登录不能做任何事情，其他用例也不必去包含注册ID的用例，因为客人的确可以注册完成以后什么事都不做。注册ID用例和其它业务用例有关系是因为业务规则，而不是因为客人的目的。第二个朋友的我就不细说了，原因大致同上，另一方面，由于我不赞同业务角色的获取，当然从它得出的业务用例我也不赞同。

有一点是值得讨论的，就是查询用例。这是一个比较特殊的东西，因为查询的目标可以很明确，也可以很模糊。比如，我就只是查查看而已，看完了什么也不做；也可能是因为我要租房，所以查询；还可以因为是我要查完后修改我已经发布的信息...类似这样的不同目标还有很多，显然我们不可能每一个目标都去定义一个查询XXX业务用例。同时，一个查询可能是跨越多个业务用例的，比如把求租、寻租和用户信息集中在一个查询结果里面。在这一点上我也不能断定你专门目标的用例：找房屋信息业务用例，和你朋友通用目标的用例：查询信息业务用例哪一个是正确的，事实上都是正确的，也都有道理，取决于客户需求中针对查询的要求，到底是专门目的，还是模糊目的。
coffeewoo 发表于:2006.11.08 13:52 ::分类: ( 系统分析、设计，UML及OO , ) ::阅读:(4077次) :: 评论 (10)
re: 一个房屋中介业务建模的实例分析 [回复]

新作发表，值得祝贺。
不过coffeewoo还是记得完成《分析模型系列》哦
看了《用例分析系列》受益匪浅，这才是我想象中的软件工程啊。我对后面的大作报以很高希望呢。
lifeng 评论于: 2006.11.08 15:18
re: 一个房屋中介业务建模的实例分析 [回复]

赫赫，coffeewoo果然是个有责任心的啊。
我喜欢。
不要放弃哦
lifeng 评论于: 2006.11.09 09:31
re: 一个房屋中介业务建模的实例分析 [回复]

就回答一个最简单的问题：
业务用例阶段请不要做过多抽象，因为你是想描述需求，而不是在做分析
系统用例阶段请进行有必要的抽象，因为你是想描述人与系统间针对需求的交互，所以你在做分析
分析模型阶段请靠近代码级的抽象，因为你是想描述系统究竟是怎样完成人所提出的需求的，所以你在做分析和设计的过渡（这时候依靠的就是业务对象之间所进行的交互）
设计模型阶段请进行代码级的抽象，你会发现许多CLASS（业务对象、业务逻辑），于是你也会使用常见的时序图来表述
其实抓住这些重点，你就会发现在任何一个阶段你都有你的目标，做起事情来就清晰多了。
MVC属于构架体系的模式，如果理解为实体=M、边界=V、控制=C没有问题，问题的关键点在于对于一个用例实现你在设计时怎样将这三者清晰的分离，尤其针对的是BS结构。
rwyx 评论于: 2006.11.10 01:13
re: 一个房屋中介业务建模的实例分析 [回复]

首先很感谢你的文章,受益非浅!

关于这个案例的角色和用例分析,我有以下的想法,不知您是因为说明简化的原因没有提及,还是我想的有偏差,请指教!

出租者角色
求租者角色
管理员

注册用户用例
注册店面用例
发布出租信息用例
查找信息用例
发布评论用例
收藏房屋用例
发布求租信息用例
管理用例
QQ 评论于: 2007.03.15 18:41
re: 一个房屋中介业务建模的实例分析 [回复]

针对需求描述,Midhael Yan的分析似乎不是很全面,缺少一些角色和用例,而您对这一点没有提出,所以我疑惑其他的角色和用例是不是有必要
QQ 评论于: 2007.03.16 09:52
re: 一个房屋中介业务建模的实例分析 [回复]

哈哈，都是高手
lazy 评论于: 2007.05.04 11:16
re: 一个房屋中介业务建模的实例分析 [回复]

tongue,加入coffeewoo的fans行列.
拜读了用例分析的大作,深入浅出,比一些所谓的教程之类容易接受多了.谢谢coffee大哥.
小刀妹 评论于: 2007.08.21 23:45
re: 一个房屋中介业务建模的实例分析 [回复]

coffeewoo的确是高人，而且也实在。不像有些人懂得多一些，但故弄玄虚。对于coffeewoo我只说一个字：高！
IT老兵 评论于: 2007.09.17 12:34
re: 一个房屋中介业务建模的实例分析 [回复]

我也是一个UML新手，看了上面的，也觉得coffeewoo为人不错，水平不错！
独钓寒江雪 评论于: 2008.01.09 17:21
re: 一个房屋中介业务建模的实例分析 [回复]

针对于一个产品化的建模，有些无从下手。再暂时无法抽象成一个行业的需求个体时，不知道可否简单的完成建模，增加详细设计的工作