1,268
社区成员
发帖
与我相关
我的任务
分享在UML中，如何表达usecase的时间顺序？
必须usecase1先发生，才会有usecase2的发生，请问如何表达？
另外一个usecase如果太大，需要分成几个小的usecase怎么表示？
我用的rose
另外一个usecase如果太大，需要分成几个小的usecase怎么表示？
我用的rose
...全文
请发表友善的回复…
发表回复
mach 2002-04-19
- 打赏
- 举报
通过包来组织是理想的方法，有的用例一开始笼统地想，会认为是一个功能，实际仔细看可能是一组功能，这时把它变为包就可以了。
loveam 2002-04-19
- 打赏
- 举报
时间问题我已经搞懂了，现在的问题是，大的usecase怎么和小的usecase联系？uml图怎么画？在rose中怎么做？
JeffHe 2002-04-19
- 打赏
- 举报
mach(照虎画猫) 有道理，登录后才能操作，
划分usecase时要有粒度，不是一定要划到很小的，要不就不叫usecase了
按照上面的方法划分就行，注意，要适可而止，要花精力在系统架构的建立和系统分析上
划分usecase时要有粒度，不是一定要划到很小的，要不就不叫usecase了
按照上面的方法划分就行，注意，要适可而止，要花精力在系统架构的建立和系统分析上
loveam 2002-04-19
- 打赏
- 举报
那么一个usecase应该是可以分成几个小的usecase了？在rose中怎么表达
tomboy123123123 2002-04-19
- 打赏
- 举报
usecases不考虑时间顺序
mach 2002-04-19
- 打赏
- 举报
to vegetablebird(失败到这个岁数还在当流氓)
不是完全对，其实可以在用例的事件流中指定这样的先后顺序，当然你后面说的活动图可以实现这样的逻辑，不过活动图比较麻烦，一般的简单情况并不画活动图。
举例：一个用例是登录，另一个是执行某业务操作，显然这两个用例有先后关系，需要先登录，然后才能执行业务操作，这可以在执行业务操作的用例的事件流中指定登录用例的执行为其前置条件。
不是完全对，其实可以在用例的事件流中指定这样的先后顺序，当然你后面说的活动图可以实现这样的逻辑，不过活动图比较麻烦，一般的简单情况并不画活动图。
举例：一个用例是登录，另一个是执行某业务操作，显然这两个用例有先后关系，需要先登录，然后才能执行业务操作，这可以在执行业务操作的用例的事件流中指定登录用例的执行为其前置条件。
VegetableBird 2002-04-19
- 打赏
- 举报
我认为如果你建模的时候出现了
“必须usecase1先发生，才会有usecase2的发生”
的情况，那绝对你得重新考虑你设计的Usecase是否合理了。
在UML中，如果要表达时间上的关系，可以使用活动(Activity）图，也可以使用顺序(Sequence)图。
“必须usecase1先发生，才会有usecase2的发生”
的情况，那绝对你得重新考虑你设计的Usecase是否合理了。
在UML中，如果要表达时间上的关系，可以使用活动(Activity）图，也可以使用顺序(Sequence)图。
loveam 2002-04-19
- 打赏
- 举报
呵呵，受益匪浅！实际情况是这样的:在业务建模的时候，我的actor已经建立了几个usecase,但其中一个usecase我个人感觉应该分为准备和实施两部分，准备和实施有时间上的先后顺序。我看usecase的定义好像有actor从进入系统到退出系统所独立完成的事件，所以我觉得准备和实施应该是两个usecase，由他们组成了上一级的大的usecase，经你们一说我觉得我的想法好像有错误，请你们再指教
WUYONG 2002-04-19
- 打赏
- 举报
不不不！
千万别有大的usecase、小的usecase的想法！
真的，换一种思路，放弃这种包含的想法。要坚信USE CASE看做是原子级的、不可再分的。这是RUP中强调的，也是我的经验教训。
你做usecase是为了整理需求，不是进行分析更不是进行设计。
所以，usecase之间有重叠也不要紧。它不象类一样要有清晰的、绝对的边界。
拜托你一定要信我呀！！！我在这里摔过大跟头。
千万别有大的usecase、小的usecase的想法！
真的，换一种思路，放弃这种包含的想法。要坚信USE CASE看做是原子级的、不可再分的。这是RUP中强调的，也是我的经验教训。
你做usecase是为了整理需求，不是进行分析更不是进行设计。
所以，usecase之间有重叠也不要紧。它不象类一样要有清晰的、绝对的边界。
拜托你一定要信我呀！！！我在这里摔过大跟头。
WUYONG 2002-04-18
- 打赏
- 举报
很对！
作为入门者，应该把USE CASE看做是原子级的、不可再分的。
开始可以根本不用理会《include》、《extend》。
惨痛教训！切记、勿忘！
另外，USE CASE图应该是非常简单的图。
在需求阶段，每个USE CASE所表示的内容应该用顺序图表示。
在分析阶段，USE CASE的实现应该用活动图表示。
不过，任何规则都有例外！
如果你是在整体的高度，描述不同的USE CASE的时间顺序，是可以用简单的图表示的。但是你自己心里一定要清楚这一点：你并不是用这种图去分析、构建某个具体的USE CASE。只是鸟瞰所有的USE CASE图而已！
作为入门者，应该把USE CASE看做是原子级的、不可再分的。
开始可以根本不用理会《include》、《extend》。
惨痛教训！切记、勿忘！
另外，USE CASE图应该是非常简单的图。
在需求阶段，每个USE CASE所表示的内容应该用顺序图表示。
在分析阶段，USE CASE的实现应该用活动图表示。
不过，任何规则都有例外！
如果你是在整体的高度，描述不同的USE CASE的时间顺序，是可以用简单的图表示的。但是你自己心里一定要清楚这一点：你并不是用这种图去分析、构建某个具体的USE CASE。只是鸟瞰所有的USE CASE图而已！
lcgong 2002-04-18
- 打赏
- 举报
不行，不行！
<<include>>和<<extend>>可没有这个时间的意思。
<<include>>基用例与包含用例的关系，包含Usecase的已定义的行为插入基usecase的行为中。对于<<extend>>则说明这种插入的条件性，只有某种条件发生时，这种包含usecase的行为才能插入基usecase中，如出错异常处理。
对于<<comunication>>则表达的role与usecase的方法或消息、事件上联系。
切忌usecase model仅仅表达who做了what!!!
如果想表达一个流程的东西建议使用活动图，更为深人表达的话，如果是业务建模，建议使用business object model(在此模型中可以，类图和交互图交叉不同层面的描述)。如果想表达系统内部实现，建议使用analysis model中使用boundary-control-entity地分析模式，利用类图和交互图不同视角的描述。
建模切忌在一张大图中完整地描述，这是不可能的。
为什么需要一个USECASE加上那几个视图呀！
<<include>>和<<extend>>可没有这个时间的意思。
<<include>>基用例与包含用例的关系，包含Usecase的已定义的行为插入基usecase的行为中。对于<<extend>>则说明这种插入的条件性，只有某种条件发生时，这种包含usecase的行为才能插入基usecase中，如出错异常处理。
对于<<comunication>>则表达的role与usecase的方法或消息、事件上联系。
切忌usecase model仅仅表达who做了what!!!
如果想表达一个流程的东西建议使用活动图，更为深人表达的话，如果是业务建模，建议使用business object model(在此模型中可以，类图和交互图交叉不同层面的描述)。如果想表达系统内部实现，建议使用analysis model中使用boundary-control-entity地分析模式，利用类图和交互图不同视角的描述。
建模切忌在一张大图中完整地描述，这是不可能的。
为什么需要一个USECASE加上那几个视图呀！
JeffHe 2002-04-18
- 打赏
- 举报
1、在usecase之间使用带方向的关系就行了
usecase1---------->usecase2
2、如果一个usecase太大，需要细分时，通常有：
1）使用package
2）使用《include》、《extend》关系进行划分
usecase1---------->usecase2
2、如果一个usecase太大，需要细分时，通常有：
1）使用package
2）使用《include》、《extend》关系进行划分
