1,265
社区成员
发帖
与我相关
我的任务
分享在uml的用例图中如何描述用例的行为？
在系统需求分析阶段建立的用例图，
应该不要注重于系统行为的细节，
但是用例的动态行为还是应该描述的吧，
当然在以后的交互图中可以有详细描述，
而在开发的初始阶段应该如何描述呢？
在用例的documentation窗口里吗？（我用的是rose）
事件流可以用到吧，
那么事件流应该放在什么地方呢？
应该不要注重于系统行为的细节，
但是用例的动态行为还是应该描述的吧，
当然在以后的交互图中可以有详细描述，
而在开发的初始阶段应该如何描述呢？
在用例的documentation窗口里吗？（我用的是rose）
事件流可以用到吧，
那么事件流应该放在什么地方呢？
...全文
请发表友善的回复…
发表回复
BirdGu 2003-11-13
- 打赏
- 举报
建议另外用一个文档（Word或Text）存放用例的描述。
rose中的documentation窗口太小。
rose中的documentation窗口太小。
jeffyan77 2003-11-13
- 打赏
- 举报
一般而言，系统的功能性需求和一小部分非功能性需求由用例图描述，大部分非功能性需求由附加的文档描述。文档放在那里都可以，看你喜欢和公司的规定。
事件流可以先写在文件里面，然后转换为Activity图。Activity图几乎就是经典的flowchart流程图，当然概念不同。
得到Activity图之后，将里面的圈圈按照owner分成泳道（swimlane）。每一个泳道相当于一个对象，由此可以得到初步的Sequence图。Sequence图就描述了你要的行为，每一个用例可以用一个Sequence图实现。
这就是Use Case Realization实际操作的过程。辨认泳道的过程是从用例模型转换到设计模式的转折点，是从没有对象到有对象的转折点。辨认泳道的过程需要想象力和经验，不同人会得出不同的结果，因此无法自动化。
事件流可以先写在文件里面，然后转换为Activity图。Activity图几乎就是经典的flowchart流程图，当然概念不同。
得到Activity图之后，将里面的圈圈按照owner分成泳道（swimlane）。每一个泳道相当于一个对象，由此可以得到初步的Sequence图。Sequence图就描述了你要的行为，每一个用例可以用一个Sequence图实现。
这就是Use Case Realization实际操作的过程。辨认泳道的过程是从用例模型转换到设计模式的转折点，是从没有对象到有对象的转折点。辨认泳道的过程需要想象力和经验，不同人会得出不同的结果，因此无法自动化。
jeffyan77 2003-11-13
- 打赏
- 举报
ozzzzzz说得很对，用例不一定要用UML表述。
一般来说建模的顺序如下：
Business Use Case Model
Ivar Jacobson说任何一个业务组织流程都可以用Use case Diagram描述，Rose里面特别提供了一套符号表述这些Business Use Case。
Use Case Model
Use Case Model可以从Business Use Case Model中提取出来，如同一个子系统一样。如同ozzzzzz所说，Use Case图中并没有对象。
建立Activity图可以描述事件发生的顺序和关系，这个图也不是描述对象的。即便建立了泳道，也没有对象可言，每个泳道不过就是一个逻辑划分，可以是任何东西。
但是如果泳道描述的是事件的owner的话，那么Activity图看上去就像极了Sequence图。只要把泳道用对象代替，时间顺序搞对，Sequence图就呼之欲出了。
Design Model
如我第一个帖子所说，从没有对象到有对象是人的创造过程。Sequence是第一个基于对象的UML图，是第一个Design Model的描述。这是Design Model的起点。
注意Sequence图和Collaboration图是完全等价的，可以使用Rose自动转换。所以如果当初不从Activity图到泳道、到Sequence图的话，也完全可以使用从Activity图直接到Collaboration图，细节就不再是泳道了（我本人更喜欢Sequence图，所以对这里的细节没有考虑过）。
有了对象还不意味着有了类，要导出类需要进一步分析Sequence图或者Collaboration图，这个时候可以参考Ivar Jacobson为类建立的Stereotypes，边界类、实体类、控制类等，逐步辨认。
有了类，就有了类图。有了类图，就可以反过来为Sequence图或者Collaboration图加上类型，因为最初的Sequence图中只有对象，没有类型。这时候，这个时候Use case被实现了，Use Case Model被转换成了一个初步的Design Model，直到所有的Use Case Path都被Activity图覆盖，而所有的Activity图都给对类图生成做出了贡献。一个循环完成了。
这个过程要循环进行很多次，这就是从行为模型到静态模型的转换。从只有对象到有类的转变。这一循环中间必然会有问题，譬如你发现Sequence图中的某个对象太大，应当进一步划分等等。这时候就进入下一轮循环。
...
这是一个理想化的描述，实际工作中会有各种妥协和捷径，不可教条主义。
UML只是一个描述语言而已，你完全可以使用文字而不是UML图形完成上面的过程。
一般来说建模的顺序如下：
Business Use Case Model
Ivar Jacobson说任何一个业务组织流程都可以用Use case Diagram描述，Rose里面特别提供了一套符号表述这些Business Use Case。
Use Case Model
Use Case Model可以从Business Use Case Model中提取出来，如同一个子系统一样。如同ozzzzzz所说，Use Case图中并没有对象。
建立Activity图可以描述事件发生的顺序和关系，这个图也不是描述对象的。即便建立了泳道，也没有对象可言，每个泳道不过就是一个逻辑划分，可以是任何东西。
但是如果泳道描述的是事件的owner的话，那么Activity图看上去就像极了Sequence图。只要把泳道用对象代替，时间顺序搞对，Sequence图就呼之欲出了。
Design Model
如我第一个帖子所说，从没有对象到有对象是人的创造过程。Sequence是第一个基于对象的UML图，是第一个Design Model的描述。这是Design Model的起点。
注意Sequence图和Collaboration图是完全等价的，可以使用Rose自动转换。所以如果当初不从Activity图到泳道、到Sequence图的话，也完全可以使用从Activity图直接到Collaboration图，细节就不再是泳道了（我本人更喜欢Sequence图，所以对这里的细节没有考虑过）。
有了对象还不意味着有了类，要导出类需要进一步分析Sequence图或者Collaboration图，这个时候可以参考Ivar Jacobson为类建立的Stereotypes，边界类、实体类、控制类等，逐步辨认。
有了类，就有了类图。有了类图，就可以反过来为Sequence图或者Collaboration图加上类型，因为最初的Sequence图中只有对象，没有类型。这时候，这个时候Use case被实现了，Use Case Model被转换成了一个初步的Design Model，直到所有的Use Case Path都被Activity图覆盖，而所有的Activity图都给对类图生成做出了贡献。一个循环完成了。
这个过程要循环进行很多次，这就是从行为模型到静态模型的转换。从只有对象到有类的转变。这一循环中间必然会有问题，譬如你发现Sequence图中的某个对象太大，应当进一步划分等等。这时候就进入下一轮循环。
...
这是一个理想化的描述，实际工作中会有各种妥协和捷径，不可教条主义。
UML只是一个描述语言而已，你完全可以使用文字而不是UML图形完成上面的过程。
hauck 2003-11-13
- 打赏
- 举报
还有人来谈一下看法吗？
webcat 2003-11-13
- 打赏
- 举报
UML规范中是包含USE Case的，交互图是获得系统行为的方法，应该在分析阶段开始花了，来分析系统的事件。
BinaryTreeEx 2003-11-13
- 打赏
- 举报
应该描述用例的流程。这个流程可以用活动图来描述。但是要注意业务建模和系统建模的区别。搞混了就不好了。建议你先搞清楚业务的流程然后确定用例，如果一定先要出用例那个就是业务建模的用例了。我觉得业务建模用uml不太好，idef0更好。
hauck 2003-11-13
- 打赏
- 举报
谢谢阎博！
建立完用例图后，接着就建活动图吗？
在整个开发过程中这些UML框图建立的顺序是怎样的？
建立完用例图后，接着就建活动图吗？
在整个开发过程中这些UML框图建立的顺序是怎样的？
ozzzzzz 2003-11-13
- 打赏
- 举报
USE CASE不是USE CASE DIAGRAM。你是不是使用USE CASE和你是不是画UML图可以说没有任何关系，就更不用说你用不用ROSE之类的CASE了。
USE CASE是一种格式化的文档，最初出现的时候就是文字化的文档。现在你可以利用各种图示（UML就很好，阎博士已经告诉你怎么做了）去说明USE CASE所表现的流程和内容,但是不管怎么说它还是一个文档的形式。
从某种意义上说USE CASE DIAGRAM是不应该出现在UML中的。它不是面向对象的，它也不是能反映全部USE CASE内容的。
USE CASE是一种格式化的文档，最初出现的时候就是文字化的文档。现在你可以利用各种图示（UML就很好，阎博士已经告诉你怎么做了）去说明USE CASE所表现的流程和内容,但是不管怎么说它还是一个文档的形式。
从某种意义上说USE CASE DIAGRAM是不应该出现在UML中的。它不是面向对象的，它也不是能反映全部USE CASE内容的。
