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

一位名叫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业务用例。同时，一个查询可能是跨越多个业务用例的，比如把求租、寻租和用户信息集中在一个查询结果里面。在这一点上我也不能断定你专门目标的用 例：找房屋信息业务用例，和你朋友通用目标的用例：查询信息业务用例哪一个是正确的，事实上都是正确的，也都有道理，取决于客户需求中针对查询的要求，到 底是专门目的，还是模糊目的。