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

一位名叫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还是记得完成《分析模型系列》哦
看了《用例分析系列》受益匪浅，这才是我想象中的软件工程啊。我对后面的大作报以很高希望呢。

我现在得先花工夫去改以前的例子啦，我图省事的办法误导不少人，再不改就变害人了。

谢谢你对我提出的案例做分析！

你文中提到的岗位和角色能否举例描述一下，也算是学习下你的实际经验

当然，我个人还是保留对UML的意见，RUP、UML毕竟是许多历史经验的总结，我一直认为是自身的认知程度还不够，还需要不段的理论、实践并与同行交流总结再回去认知才能升华

我现在对uml已经琢磨到了分析阶段，你的设计师之路的第一篇已拜读，关于实体、边界、控制产生了新的困解，特别是你拿它与事、物、规则做对照后，困解更大了

现在的问题是：
1、实体=M?、边界=V?、控制=C?
特别是当你把边界与事做对照后，这种困惑就更大了
图书管理员往系统里填写借阅人的基本资料，系统展示的界面形式（web or form)也就是V，和事是什么关系？
2、可能也是对MVC的理解问题
业务逻辑存在与实体OR控制中？还是都存在？在某些文章中甚至都有人对UML、OO提出了反对论
一个实体修改自身属性，同时在数据库也做了同步，这个同步操作是实体自己做还是控制类来完成？

等你《。。。设计之路》写完，还将继续探讨下中介的例子啊：）

岗位，角色是客户喜闻乐见的形式。他们对自己的岗位职责最清楚，所以如果画出一个名字等于他岗位的actor，他立刻明白是在说他呢。比如办公室主任，副总经理，总经理，谁看了都明白。而按UML的定义，一个主角是代表有共同特征的一批涉众的。这个定义就隐含了一个“抽象”概念在里面。假设前三者都能做审批文件的事情，在UML的定义下，自然而然会产生一个类似“文件审批者”这样的主角去完成“文件审批”这样一个业务用例。我的想法就是，这个抽象概念必要吗？“文件审批者”这样一个由系统分析员“创造”出来的东西，虽然非常符合UML的思想，但是用户，开发人员，测试人员，能够有很好的理解吗？如果用岗位来代替，实际上放弃了“抽象”的概念，对于审批文件这个业务用例来说，大不了三个岗位都指向它，就OK了。
抽象概念什么时候要？在做系统用例时，用角色这个已经用了很多年的词儿来替换actor。这个时候倒是有可能“文件审批者”这个抽象会出现，不过由于已经到了系统用例阶段，客户可以不参与，所以抽象就没那么大问题了。
其实我称之为岗位，角色，UML叫business actor,actor,还有worker，实际上做出来的差别是非常小的，甚至很多时候是重合的。所以我更觉得没必要去给用户解释什么是主角什么是业务主角，直接问他，这个岗位做什么。

关于MVC模式和人事物规则，和分析类的关系我在以后的文章里会讲到的。

赫赫，coffeewoo果然是个有责任心的啊。
我喜欢。
不要放弃哦

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

嘿嘿，好久没见你现身了，感谢一个先
totally agree with you!

另外，文章一时半会儿写不完，估计大家对我把边界和事做对照很迷惑，这里先小解释一下

一件事情，在一个准备做它的人看来，它是什么样儿的？一个做事人对一件事的理解不是这件事的内部概念，而是怎么去做，可以做什么，什么不能做。就比如开车我相信不会有人问什么是开车啊？而会问，怎么开车啊？于是你的解释不会是：开，是开车的开，车是开车的车，而会是：怎么把方向，怎么踩离合，怎么给油，对吧？

好了，不再多说，留点空间给大家考虑，就我上面的小解释，想想为什么我会把事和边界做对照

对uml的研究又前进了一点...

关于边界，举个例子，不知是否恰当？

比如你要去看电视，你看到电视机的所有表面，比如按钮、有限电视插口等都属于边界，而各个按钮可以干什么，是控制器，按钮按下以后会发生什么事情，首先，如果你看过说明书，那么你已经知道每个按钮做什么事情，说明书也应该属于边界，如果没有看过说明书，按钮按下后，发生的事情可以通过发生的结果而得知，比如关闭按钮，按下后，屏幕（也属于边界）什么也看不到，内部发生什么事情不用管它，对于电视机设计开发人员，他们知道内部的某些对象进行了交互，而后实现该按钮需要完成的事情

恭喜，其实这不仅是对uml的理解，而是对OO方法的理解。从接口的角度去理解事物，任何事物都需要有一个边界，各负其责，边界两边的对象只通过边界交互，双方绝对不会去试图存取对方的内部。这是OO思想的真正精髓，真正理解了这一点，什么设计模式，什么SOA，什么AOP之类的都只是一种技巧和应用了。
其实在OO世界里，只有两点是最重要的，不论是在需求，分析设计，实现还是观察系统，只要随时能从这两点去思考就是一个真正的OO思想者了，这两点就是：边界，职责。最好的抽象，就是找出最适当的边界，并且职责分工明确。

我在什么是用例一文中说用例就是一件事情。正好和这篇当中的事是对应起来的。用例图象什么样子？一个个鸡蛋？呵呵，很形象啊，actor看用例时只能看到蛋壳，蛋壳就是边界，就是这一件事的边界，你对鸡蛋的所有理解都是来自这个shell。如果你试图了解壳以内的世界，打破了边界，恩，的确看到了，不过很快就后悔了，鸡蛋被破坏了，一滩粘粘乎乎的蛋清弄脏了手，很难收拾。糟糕的设计就象一堆破了壳的鸡蛋，一片混乱

呵呵，比喻的很形象

设计和定义好的边界非常重要，职责是ENGINEER需要完成的事情，控制器也被边界给包容了，所以在设计和定义时必须非常的小心

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

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

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

注册用户用例
注册店面用例
发布出租信息用例
查找信息用例
发布评论用例
收藏房屋用例
发布求租信息用例
管理用例

你只说出了结果，不知道你的疑问在什么地方？如果仅就你的分析结果，我非常赞同。

针对需求描述,Midhael Yan的分析似乎不是很全面,缺少一些角色和用例,而您对这一点没有提出,所以我疑惑其他的角色和用例是不是有必要

原来是这样，这篇主要是做一些释疑的工作，讲为什么要这个角色而不是那个，为什么要这个用例而不是那个。呵呵，关注点在方法是否正确上，至于是否完备本篇倒是没怎么关注。

QQ朋友读得非常细致，并且你的分析结果是很准确的！感谢你的参与

哈哈，都是高手

,加入coffeewoo的fans行列.
拜读了用例分析的大作,深入浅出,比一些所谓的教程之类容易接受多了.谢谢coffee大哥.

coffeewoo的确是高人，而且也实在。不像有些人懂得多一些，但故弄玄虚。对于coffeewoo我只说一个字：高！

我也是一个UML新手，看了上面的，也觉得coffeewoo为人不错，水平不错！

标题

在此添加评论
表情符号:

称呼

邮箱地址（可选）

个人主页（可选）

记住我？ 验证码: