比如有这么一个用例图


填写订单
/
/
人 ---- 备货


现在我想描述 “填写订单”和“备货”之间的联系，该用
什么图好啊？

另外，我想描述“填写订单”用例内部的信息(也就是详细信息)，用什么图好？
我现在用 活动图，不知道合适吗？

先要把这两种过程稍加区分.

两个我都想问一下，谢谢

现在我都用活动图来描述，用例之间用 泳道 分开，这样合适吗？

另外还想问一下，描述用例用什么图比较好呢？

按照Cockburn的方法，
先设计一个概要级的用例。

关于用例"内部"的描述的问题,首先要明确这个"内部"到底是什么含义.
一个用例就是一个服务过程,用例的外部是申请服务的人,也就是主角(Actor),用例的内部是提供服务的人,也就是角色(Work).
就象你站在食堂的窗口外打饭,你在窗口外,是主角,打饭的师傅在窗口内,是角色.打饭就是一个用例.
那么,用例的"内部"指的是什么呢?
1.是用例所包含的主角交互过程?
2.是用例所包含的角色的工作过程?
什么?!二者有什么区别?为什么要区别二者?如果有此疑问,则要先去复习用例的定义和用例建模的目的.
打饭就是一个用例,站在打饭的窗口外看到的打饭过程就是这个用例的"外部",站在打饭的窗口里面看到的打饭过程就是这个用例的"内部".
所以,当你用到"用例内部"一词的时候要非常小心.你所指的到底是关于用例的主角交互过程的详细描述内容,还是用例内部对象协作过程的描述?一定要严格区分.有许多人根本不知道要区分,也不懂得如何区分,甚至认为不用区分就在那里大谈用例模型,遇到这种人要小心点.
对于用例模型,只需要描述"外部景象",对于用例的"内部景象",则需要用对象模型来描述.所谓"用例实现"就是用例的内部景象.
由于你提出的问题,并没有明确用例"内外"的疆界,所以,你的问题的答案还不能确定.

建议你先查一下我在论坛里有过的发言,也许会得到更多的启发.

谢谢！
就用打饭来举例吧

1.是用例所包含的主角交互过程
也就是打饭用例所包含的 客人和打饭的师傅 两个角色。
那么用什么图来描述这两个角色在打饭的过程呢？我现在是用
活动图来描述

2.是用例所包含的角色的工作过程
就以打饭的师傅为例，他在这个用例中所涉及的对象是勺子、饭碗，
那么用什么图来描述 对象勺子、饭碗呢？我还是用活动图

3.两个主角的描述，也就是打饭师傅和客户
我是用序列图来描述

学UML有一段时间了，可是仍然处在模糊状态，最近有点醒悟了，希望
babituo能多多指教，看看我用的这些图对不对？
对了，这些图主要是用在软件开发阶段，不是业务需求阶段了。
业务需求阶段现在还是觉得流程图能更一目了然 :(

你需要首先着重区分一下"主角"和"角色"这两个基本概念.
说得白一点:
站在计算机外面操作软件的用户就是主角;
在计算机里面运行的软件中的对象就是角色;
软件是为用户服务的,所以我们要找到用户,又要找到软件要提供的服务.
一定要找到服务的边界并明确刻画出来,这样开发软件才有明确的目标和范围.
用例模型首先就是要做这个用的,这个用不明确,就会造成混乱.
比如,你把打饭的过程看成是客人和打饭的师傅两个角色甚至包括锅碗瓢盆共同协作来完成的,这并没有错,但一味想讲清楚整个流程,把用户的行为和打饭师傅及锅碗瓢盆的作用混在一起描述,就会淹没了哪些是该提供的服务,哪个是享受服务的人的信息.没法定义出服务的边界,也就没有办法实现服务.
换句话说,不纯粹地站在软件的外面仔细地描述软件的外貌和应有的外部行为,而把软件内部的操作混在一起描述,就得不到软件边界的定义,软件内部的实现就没有验收的标准.
你还没有重视一定要把"打饭的窗口"表达出来的意义,这一点你认识不到的话,谈用什么图表达什么过程是有些早,因为我们连表达的对象是否要划分,如何划分都还没有达成一致的理解.
我想,这也许是你和大多数UML爱好者思想模糊的主要原因之一.

babituo 你好，看了你的帖子，我又自己琢磨了一下，
对于 打饭的过程 ，我这么描述用例对不对：

主角是 打饭的人 和 打饭的师傅
用例是 打饭的过程

打饭的过程 所包含的角色就是 锅碗瓢盆

这么理解对吗？
　

假设我们把这个服务的边界理解为打饭的窗口.
你再重新理解一次看看是什么结果?

把这个服务的边界理解为打饭的窗口,那么用例的描述应该是：

主角是 打饭的人， 用例是 打饭
打饭所包含的角色就是 打饭师傅、锅碗瓢盆。

这么理解对吗？

各种看法和理解都没有错,都符合实际情况,
如果要从用例的本意来看,突出服务是最佳的选择.
现在假设我们站在打饭的窗口外面,只能看到窗口上和窗口外发生的一切,你能描述一下所看到的过程吗?

过程应该是：

打饭的人交钱-->得到饭-->得到找回的零钱

对吗？

如果现在的软件给打饭师傅做的，那么
主角就是 打饭的师傅，买饭的人就成了用例里的一个角色

如果现在的软件是给买饭的人做的，那么
主角就是 买饭的人，打饭的师傅就成了用例里的一个角色

如果软件是给 打饭的师傅和买饭的人做的
那么主角就是 打饭的师傅和买饭的人

这么理解对吗？

 问题在于你如何定义服务的边界
　

---

我举"打饭"的例子,并没有假设我们要开发一个软件辅助打饭,只是为了表明用例就是服务,用例就是要用来表达服务的边界的概念.

我的意思是:如果"打饭"就是一个服务,而且这个服务的"界面"就是打饭的窗口,那么这个服务就应该定义为:
"主角就是买饭的人，打饭的师傅就成了用例里的一个角色",这个用例就叫"打饭".
我们站在打饭窗口外面看到的过程,就是这个用例应该描述的事件流.而在打饭窗口外面看不到的内部过程(甚至连打饭的师傅都看不到),在做用例模型的时候,是不需要在这个用例中来表达的.
只有在做对象模型的时候,当你已经找到内部的对象(比方你站到了打饭窗口的里面看到了打饭师傅和菜盆,打菜勺,菜,菜票箱等),你才可以用这些内部对象的行为来描述这个用例内部是如何被实现的.而此时,你不必关心窗口外发生的过程.
描述某个用例的内部对象模型(是系统对象模型的一个子集)就是这个用例的"用例实现".

"打饭的人交钱-->得到饭-->得到找回的零钱"显然不够细致.
比如:

1.轮到打饭人到窗口,用例开始.
2.打饭人递进打饭菜盆;
3.窗口内传出一个声音:"您吃点什么?";
4.打饭人说出要吃的饭菜名;
5.窗口内又传出一个声音:"请付5元钱,谢谢";
6.打饭人给进6元菜票;
7.窗口内递出打满饭菜的盆子;
8.打饭人朝窗口说:"请找我1元钱";
9.窗口内递出1元菜票.
10.打饭人拿走打好的饭和找回的菜票;
11.用例结束.

当然,其中可能会发生各种意外,如:第9步可能是:
窗口内传出一个声音:"我不是找过你了吗?"
接着就会发生其他的事情,
也许最后窗口里面会飞出一个菜勺打中打菜人的脸也说不定.
这就是用例的例外描述,也不可少.

我希望你能比我更勤快些,把在窗口里面看到的过程也详细地描述一遍.

窗口里的过程应该是：
1。打饭师傅接到钱
2。听到“我要一两饭”
3。拿起饭碗
4。装上一两饭
5。把饭送出去
6。因为一两饭是2毛钱，所以找回8毛钱
7。打饭完毕

其中涉及到的角色就是 打饭师傅，饭碗，和钱

可是我看的那本UML书，没有讲需要描述用例外的活动，也就是
主角和用例的活动，就是你上面讲的 那个过程，那本书只是说
要描述用例内部的对象，和用例之间的活动。
有点迷惑啊......

你现在至少已经知道,用例内部描述和外部描述是有区别的了,那本书没有说到用例外部需要描述,也没有说用例外部不需要描述呀!你现在的迷惑已经不是分不清用例的内外有别了,而仅仅只是外部描述是否有必要了,假设就算你现在不同意我的看法:需要描述用例外部的过程,那么,你以后描述用例的时候,也不会把外部的过程和内部的过程混在一起来描述了,你至少已经知道,混在一起描述的问题,就会使得不到用户验收的明确标准,这已经是一个进步了.
从认识事物是从外到内的这个简单的道理出发,我们也不会肯定地认为:用例主角的外部交互行为是不需要描述的.相反,我们会认为,对用例主角的外部交互行为的描述是描述用例内部对象协作的前提.因为,内部对象协作的目的,就是要让外部主角交互时,应该在系统界面上该发生的事情发生.主角的需求才能满足,我们也就不会做一些与外部主角需求无关的内部协作.
只要你仔细品味一下,”用例建模方法意味着从以系统为中心的设计思想到以用户为中心的设计思想的转变”这句话的含义,你也许会明白从外部描述用例的重要性.
我把用例比作系统开发的”门”是贴切的,所谓”闭门造车”也可以理解为:不问用例外面的主角需要系统发生什么事情,潜心设计用例内部的对象协作,等设计实现完了也许是一个精巧的系统,可找不到想进入系统的用户和用户想进入系统的门.

谢谢 babituo 的指点！

那么能不能指点一下描述用例外部的主角用什么图呢？
我那本书上说用 活动图，不过它对用活动图的解释是：
活动图适合描述多个用例交互的过程。
那么对于主角的活动该用什么图呢？

现在我们可以讨论视图的用法了,对于用例外部主角交互行为的描述主要用(这是建立用例模型时要做的):
1. 活动图(一般不带泳道或只带”主角”和”系统”两个泳道);
2. 事件流描述;
3. 用例示例板(带界面操作元素以及操作导航信息的事件流描述).
对于用例内部角色交互行为的描述主要用(这是建立对象模型时要做的):
1. 活动图(带多个参与的对象的泳道);
2. 顺序图;
3. 协作图;
4. 类-关联图;
5. 类的状态图.
用例内部对象模型完全是为了实现用例外部主角与系统的交互需求的,因此,在用例模型中的每一个用例,都可以找到对象模型中适当的对象以及他们之间的协作关系组成的内部表达,这些内部表达,就是所谓的”用例实现”,理论上”用例实现”是需求跟踪的手段,但我们完全可以用”用例实现”反过来来开发对象模型.
不仅仅是用例主角的事件流需要实现,用例模型中用例之间的关联,同样也需要在对象模型中有所”实现”,这也许就是你看的那本书说的"活动图是用来描术多个用例之间的活动的"的所指.确切地说,应该说"可以用来...".
　

谢谢，谢谢老师指点了！
以后有不明白的我就直接给你写信问了 :)

 回复: 怎么没说道业务用例和系统用例
　

---

babituo，

我有一点疑问，在系统用例中角色，和业务用例中的主角，角色，怎么区分的啊？
我怎么是越来越迷糊了～