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

一位名叫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: 一个房屋中介业务建模的实例分析 [回复]

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

WSP 评论于: 2008.10.13 15:55
开源可定制房产中介 ERP 解决方案: 开单大师是全国首家提供房产管理系统和房屋管理系统源代码的服务商,系统拥有功能完善的房源客源管理,同时提供完备的办公、财务、决策分析方案,内外一体全面打通。 开单大师100%开放的源代码,您可以自由掌控,定制开发属于您的专属功能。无店面和用户数限制,一次买断,永久使用。安全掌控您的软件服务器,隐私数据自己掌控。开单大师,为每家中介提供真正属于自己的房产中介管理系统。 整合微信平台:借力微信,快速分享。 开单大师内网管理ERP:功能全面,适合不同运营需求。 房客源管理:内外网同步,一站打通。 一体化外网同步设计思想:开单大师房产管理系统平台上搭建全部业务模块,不论是标准产品还是个性研发都遵循规范要求,包括取数规则,交互方式,界面样式和美工风格都全部有统一化标准。 产品特色: 技术方案成熟稳定,支持各类房产中介业务场景,开单大师房产管理系统平台集成内外网平台应用系统,帮您一站式快速搭建专属的房产中介平台。 房源管理:开单大师支持网络多门店,多人联网系统工作。中介网站无缝集成和微站无缝集成,提升中介门店服务能力,更高效。 权限和设置:各种角色和权限设置,不限门店,员工数量。可灵活设置每一位经纪人的权限,认证机器,可限制经纪人只能在门店内电脑登录。 全新智能激励辅助运营:根据个人业务动作所占成交比例预知业绩金额,发挥经纪人主观能动性,加速成交进程! 移动端应用:特色移动端应用,方便快捷查询管理。实时数据更新,事件准时提示。让您随心掌握,想改就改。 微信分享:经纪人可对自己的订单进行评价和分享,也可在微商城、圈子等多频道进行分享。 强大的财务报表分析中心:大数据智能分析业绩数据,了解业绩走势。门店损益状况一目了然,让门店运营状况尽在您的眼中! 在线客服:经纪人与客户随时沟通,轻松解决客户疑问,不在受疑难杂症的烦恼。 三大日志辅助运营:三大日志相辅相成,让一切尽在掌握,为您的数据安全提供优质的保护。 定制开发:开单大师为不同的要求,提供最适合的定制化解决方案。 除了以上特性,开单大师还用心为您准备了更多的贴心功能等待您的发现…… 常见问题: 1、开源可定制是什么意思 软件代码开放,懂技术的可以自己调整或者新增功能,如果自己对技术不太懂可以联系我们公司给您定制您需要的功能 2、开单大师只能用于房产吗 目前开单大师只针对写字楼、商铺、二手房、新楼盘、新房分销等做了不同的版本,包括运营版也是针对房产中介开发的,不过如果您需要其他行业的软件我们也可以给您定制开发 3、开单大师如何安装 解压压缩包后有一个名为开单大师4.0.9学习版的文件夹,打开文件夹中的4.0.9使用说明,里面有详细的安装步骤 更新日志: 1、微调了快捷链接的样式。 2、优化了学区列表 3、部分弹窗点击关闭时修改为不刷新父级页面 4、解决了用户列表打不开转房、转客页面的问题
房屋中介管理系统使用说明书 安装及配置 1.附加SQL Server 2000数据库 (1)将DataBase文件夹中的两个文件拷贝到SQL Server 2000安装路径下的Data文件夹中。 (2)打开SQL Server 2000中的“企业管理器”,然后展开本地服务器,在“数据库”数据项上单击鼠标右键,在弹出的快捷菜单中选择“所有任务”/“附加数据库”菜单项。 (3)将弹出“附加数据库”对话框,在该对话框中单击“ ”按钮,选择所要附加数据库的.mdf文件,单击“确定”按钮,即可完成数据库的附加操作。 2.配置 “killspid”存储过程建立在Master数据库中,用于备份还原数据库时杀死进程。该存储过程在附加数据库时不能随之附加,所以需要将“光盘\mingrisoft\房屋中介管理系统\houseAgency\houseAgency\database”文件夹中的“杀死进程的存储过程.sql”文件打开,将文件里的内容复制到SQL Server 2000“查询分析器内”单击【执行】按钮。如图1.1所示。 图1.1 查询分析器 程序使用说明 主要功能 房屋中介管理系统是一款非常实用的房屋中介软件。使用该软件,不仅可以详细地记录房源信息、用户信息等,同时还能够自动查找和客户需求相匹配的房源,在方便客户的同时又提高了使用者的工作质量和效率。本系统属于小型的数据库系统,可以对房源和租赁人等进行有效的管理。 操作注意事项 用户在使用《房屋中介管理系统》之前,应注意以下事项: (1)实例执行文件路径:光盘\ mr\houseAgency\houseAgency\bin\Debug\houseAgency.exe (2)本系统的初始用户名为mr,密码为mrsoft。 (3)在本系统中填写信息时,有时需要将五笔输入法的全角状态改为半角状态,否则程序可能会弹出错误提示,五笔输入法的全角状态和半角状态如图1.2所示。 图1.2 五笔输入法的全角与半角状态 (4)在“房源状态浏览”和“求租意向设置”模块中,输入完手机号后需要按一下回车键,才可执行相应的操作。 (5)在“求租意向设置”模块中设置完求租意向后,如果有匹配的房源信息,会提示找到相符信息,同样在录入房源时如果与某一求租意向匹配,也会提示找到相符信息。 (6)本程序中并没有直接提供修改房源信息的模块。在“求租管理”/“房源查询设置”模块中双击房源记录,弹出“房源设置”模块,在此模块中可以对房源信息进行修改。 (7)出租及预定的房源不可以进行修改。 (8)在“出租人员信息设置”模块中,录入完基本信息后,必须直接录入房源信息,否则此条出租人员信息无用处。 (9)在“录入员工信息”模块中添加完员工信息后,在“所有员工信息”模块中此员工的初始密码为“mrsoft”,如果想要修改密码,需要进行登录,然后选择“系统管理”/“口令设置”菜单项,对密码进行修改。 业务流程 在使用本系统时,请按照以下流程进行操作: (1)选择“员工信息”/“录入员工信息”菜单项,在弹出的模块中添加员工信息。 (2)选择“员工信息”/“所有员工信息”菜单项,在弹出的模块中可以查看、修改、删除所有员工信息。在“权限”下拉列表中有两个选项,其中“经理”代表管理员,“员工”代表普通用户。管理员与普通用户的区别在于,普通用户操作界面没有“员工信息”菜单项,不可以对员工进行管理。 (3)依次选择“出租管理”菜单中的子菜单项,对房屋其本信息进行设置。 (4)选择“用户信息管理”/“求租人员信息设置”菜单项,添加求租人员信息。 (5)选择“求租管理”/“求租意向设置”菜单项,设置求租意向。 (6)选择“用户信息管理”/“出租人员信息设置”菜单项,添加出租人员信息。添加成功后,接着录入房源信息。 (7)选择“用户信息管理”/“人员信息控制”菜单项,在此模块中可以查看、修改、删除求租人员信息和出租人员信息。 (8)选择“求租管理”/“房源查询设置”菜单项,在此模块中可以查询、修改及执行出租操作等。 (9)选择“求租管理”/“房源状态浏览”菜单项,在此模块中可以查看房屋状态,执行预订等操作。 (10)选择“交费管理”/“收费记录”菜单项,添加收费信息。 (11)选择“业务统计”/“成交业务量统计”菜单项,对成交业务量进行统计查看。 (12)选择“系统管理”/“数据库备份”菜单项,对数据库进行备份。 (13)选择“系统管理”/“数据库恢复”菜单项,对数据库进行恢复。 除此之外,本程序还提供了很多辅助功能,例如“常用工具”菜单项等。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值