UML全程统一建模语言,是专门为面向对象建模的设计语言。
在我们讨论UML之前,我们先来看看面向对象和面向过程的区别。
假设我们要为一个公司制作一个业务系统,这个系统会有许多部门各个岗位的人参与,
那么,面向过程和面向对象分别是怎么设计的呢?
我们先来看看面向过程的调研思路:
首先弄清楚有多少业务流程,然后画出业务流程图,
然后顺藤摸瓜,找出没一个步骤参与的部门和岗位,
弄清楚参与者所做的事情和填写表单的情况,然后怎么
把表单传到下一个环节。
面向对象:
弄清楚有多少部门,多少岗位;
找到每一个岗位的业务代表,问类似问题:
你平时都做些什么?这件事是谁交办的?
做完了需要通知或传达谁吗?
做这件事情需要填写什么表格吗?
下面我们就来看一下UML的一些基本概念:
1)参与者(actor)
参与者是整个建模的中心,再好的设计不符合客户需求也等于零。
参与者代表了现实世界中的“人”。
2)用例(use case)
用例表示驱动的业务目标,也就是参与者想要做什么并且获得什么。
用例代表了现实世界中的“事”。
3)业务工人(business worker)
这里我们经常会与参与者搞混。
事实上,业务工人是系统中的被动参与者。
如果要区分actor与business worker,我们通常可以问2个问题就能区分了:
1)系统是为谁服务的?
2)这个人会主动发出动作吗?
我们下面来看一个用例场景,如 下:
小王带着钱去银行开户,向大厅经理询问了办理手续,填写好表单后,
交给柜台职员,柜台职员帮小王办理手续,小王拿到存折。
在上面这个场景中,谁是参与者,谁是业务工人呢?
很明显:
参与者: 小王
业务工人:大厅经理,柜台职员
理由:系统是为小王服务的,小王主动发出动作,大厅经理和柜台职员是被动的,他们不会
主动发出请求。
有人常常会有这样的错误概念:认为参与者必须是人。
事实上,这种想法是错误的, 参与者有时候也可以是物。
我们来看这样一个场 景;
每天自动统计网页访问量,生成自动报表,将报表发送至相关人员信箱。
很明显,这个场景中没有人。
那么参与者是谁呢?
我们说,是“计时器”。
因为它在每天的固定时间启动这个需求。
关于用例,我们经常会有误导,那就是
把它和具体业务操作混淆起来。
我们可以用这样一句话来加以区分:
用例是有意义的,它代表了参与者的愿望,
不能完整达到参与者愿望的不能称为用例。
我们还是看上面这个小王去银行开户的场景。
在这个场景中,我们可以提炼出来的动作有:
银行开户,询问手续,填写表单,办理手续,拿到存折
在以上动作中,只有银行开户才是真正的用例,其它都是该用例的具体操作。
就拿填写表单来说,填写表单是小王的愿望吗?显示不是,小王去银行又不是为了
填写表单,他是为了开户,但是银行规定这么做,如果能够不填写表单就直接办理
开户,小王当然高兴了。
所以,我们说:
用例必须代表参与者完整的愿望。
以上场景的用例图如下:
在我们讨论UML之前,我们先来看看面向对象和面向过程的区别。
假设我们要为一个公司制作一个业务系统,这个系统会有许多部门各个岗位的人参与,
那么,面向过程和面向对象分别是怎么设计的呢?
我们先来看看面向过程的调研思路:
首先弄清楚有多少业务流程,然后画出业务流程图,
然后顺藤摸瓜,找出没一个步骤参与的部门和岗位,
弄清楚参与者所做的事情和填写表单的情况,然后怎么
把表单传到下一个环节。
面向对象:
弄清楚有多少部门,多少岗位;
找到每一个岗位的业务代表,问类似问题:
你平时都做些什么?这件事是谁交办的?
做完了需要通知或传达谁吗?
做这件事情需要填写什么表格吗?
下面我们就来看一下UML的一些基本概念:
1)参与者(actor)
参与者是整个建模的中心,再好的设计不符合客户需求也等于零。
参与者代表了现实世界中的“人”。
2)用例(use case)
用例表示驱动的业务目标,也就是参与者想要做什么并且获得什么。
用例代表了现实世界中的“事”。
3)业务工人(business worker)
这里我们经常会与参与者搞混。
事实上,业务工人是系统中的被动参与者。
如果要区分actor与business worker,我们通常可以问2个问题就能区分了:
1)系统是为谁服务的?
2)这个人会主动发出动作吗?
我们下面来看一个用例场景,如 下:
小王带着钱去银行开户,向大厅经理询问了办理手续,填写好表单后,
交给柜台职员,柜台职员帮小王办理手续,小王拿到存折。
在上面这个场景中,谁是参与者,谁是业务工人呢?
很明显:
参与者: 小王
业务工人:大厅经理,柜台职员
理由:系统是为小王服务的,小王主动发出动作,大厅经理和柜台职员是被动的,他们不会
主动发出请求。
有人常常会有这样的错误概念:认为参与者必须是人。
事实上,这种想法是错误的, 参与者有时候也可以是物。
我们来看这样一个场 景;
每天自动统计网页访问量,生成自动报表,将报表发送至相关人员信箱。
很明显,这个场景中没有人。
那么参与者是谁呢?
我们说,是“计时器”。
因为它在每天的固定时间启动这个需求。
关于用例,我们经常会有误导,那就是
把它和具体业务操作混淆起来。
我们可以用这样一句话来加以区分:
用例是有意义的,它代表了参与者的愿望,
不能完整达到参与者愿望的不能称为用例。
我们还是看上面这个小王去银行开户的场景。
在这个场景中,我们可以提炼出来的动作有:
银行开户,询问手续,填写表单,办理手续,拿到存折
在以上动作中,只有银行开户才是真正的用例,其它都是该用例的具体操作。
就拿填写表单来说,填写表单是小王的愿望吗?显示不是,小王去银行又不是为了
填写表单,他是为了开户,但是银行规定这么做,如果能够不填写表单就直接办理
开户,小王当然高兴了。
所以,我们说:
用例必须代表参与者完整的愿望。
以上场景的用例图如下: