1,268
社区成员
发帖
与我相关
我的任务
分享初学用例，我做的轮渡售票管理系统需求，请大家指教。
初学用例，请大家帮忙看看用例方法是否有问题，多谢了！
需求说明：
http://blog.csdn.net/mathematician/archive/2006/06/27/840891.aspx
需求说明：
http://blog.csdn.net/mathematician/archive/2006/06/27/840891.aspx
...全文
请发表友善的回复…
发表回复
xiaoliangwh 2006-09-01
- 打赏
- 举报
hao !
maseccc 2006-08-22
- 打赏
- 举报
mark
mathematician 2006-07-13
- 打赏
- 举报
为什么结了帖分数却显示不出来？点【管理】却能看到每个回帖的得分？
mathematician 2006-07-13
- 打赏
- 举报
感谢以上网友的讨论，呵呵。
mathematician 2006-07-06
- 打赏
- 举报
退票时要查询售票信息。退票用例里有说明：
扩展流
查询售票信息：
用户可以通过执行用例《查询售票信息》，查看可售票信息。
基本流：
1、售票员可选择查询售票信息，了解已售和未售船票状态。
扩展点
《查询售票信息》扩展点定义在基本流步骤2
扩展流
查询售票信息：
用户可以通过执行用例《查询售票信息》，查看可售票信息。
基本流：
1、售票员可选择查询售票信息，了解已售和未售船票状态。
扩展点
《查询售票信息》扩展点定义在基本流步骤2
usrsdh 2006-07-06
- 打赏
- 举报
1关于用例描述语言，系统显示查询售票信息界面。应该是主用角选择查询售票，系统初始化售票信息，进行显示。
2看了你用例描述，很明显，不是多用角，因为他们的场景是一样，那就不需要增加备选流，对应的公司领导和财务人员，本来就是用业务人员的角色在执行这个用例，如果是不同的场景才需要抽象出不同的角色，进行描述。
3你这种处理方式，跟前面一样，没有明确用户和角色的关系。这里是售票员这个用户承担了订票员的角色，所以，对业务系统来说，对应的角色应该是订票员，同理，售票这个用例才是售票员做的事。
总结：抽象用例和角色时，先从业务系统出发，再按角色，对场景描述，也就是用例的基本流和备选流。当然，如果不是主用角，也可以不进行描述，在业务规则进行说明则可。
2看了你用例描述，很明显，不是多用角，因为他们的场景是一样，那就不需要增加备选流，对应的公司领导和财务人员，本来就是用业务人员的角色在执行这个用例，如果是不同的场景才需要抽象出不同的角色，进行描述。
3你这种处理方式，跟前面一样，没有明确用户和角色的关系。这里是售票员这个用户承担了订票员的角色，所以，对业务系统来说，对应的角色应该是订票员，同理，售票这个用例才是售票员做的事。
总结：抽象用例和角色时，先从业务系统出发，再按角色，对场景描述，也就是用例的基本流和备选流。当然，如果不是主用角，也可以不进行描述，在业务规则进行说明则可。
mathematician 2006-07-06
- 打赏
- 举报
usrsdh(无恨)：谢谢指点。有几个问题请教：
1、“系统显示查询售票信息界面，这不是用例描述语言。”那应该怎么描述呢？我在sawin上看到一个领用资产的用例他一上来就这么说的，所以我照搬了，呵呵，见笑了。
2、“一个用例多个主角时，说明不够清楚。如查询售票信息用例。公司领导，公司财务人员查询售票信息，应该是不同的备选流，不同的场景进行区分。”多主角应该怎么说明呢？我觉得如果改成下面这样，似乎不合适。
查询售票信息用例
基本流
1、系统显示查询航次信息界面。
2、业务人员选择船舶（默认为香雪兰）。
3、业务人员选择查询的航次。
4、系统显示查询航次的信息。
备选流
备选流一：业务人员可以在基本流中的任何一步选择退出，用例结束。
备选流二：公司领导在基本流步骤2中选择查询船舶，步骤3中选择查询的航次，系统显示查询航次的信息。
备选流三：财务人员在基本流步骤2中选择查询船舶，步骤3中选择查询的航次，系统显示查询航次的信息。
3、订票是旅客发起的，不过旅客不会接触本系统。他通过电话、传真、email等方式通知售票员，然后售票员进入系统订票，所以我没有将订票和旅客进行通讯关联。这样的考虑不知当否，请指教。
1、“系统显示查询售票信息界面，这不是用例描述语言。”那应该怎么描述呢？我在sawin上看到一个领用资产的用例他一上来就这么说的，所以我照搬了，呵呵，见笑了。
2、“一个用例多个主角时，说明不够清楚。如查询售票信息用例。公司领导，公司财务人员查询售票信息，应该是不同的备选流，不同的场景进行区分。”多主角应该怎么说明呢？我觉得如果改成下面这样，似乎不合适。
查询售票信息用例
基本流
1、系统显示查询航次信息界面。
2、业务人员选择船舶（默认为香雪兰）。
3、业务人员选择查询的航次。
4、系统显示查询航次的信息。
备选流
备选流一：业务人员可以在基本流中的任何一步选择退出，用例结束。
备选流二：公司领导在基本流步骤2中选择查询船舶，步骤3中选择查询的航次，系统显示查询航次的信息。
备选流三：财务人员在基本流步骤2中选择查询船舶，步骤3中选择查询的航次，系统显示查询航次的信息。
3、订票是旅客发起的，不过旅客不会接触本系统。他通过电话、传真、email等方式通知售票员，然后售票员进入系统订票，所以我没有将订票和旅客进行通讯关联。这样的考虑不知当否，请指教。
usrsdh 2006-07-06
- 打赏
- 举报
另：include和extend不能用泛化的标记
用例说明，对应的触发事件说明也不正确如，订票的触发事件应该是旅客想要订票。
还有，用例图好象有问题，订票应该是旅客发起的吧，售票员只管售票才正确，如果按你描述的，订票应该是订票员，然后，售票员和订票员才从业务员那里一般化过来。
用例说明，对应的触发事件说明也不正确如，订票的触发事件应该是旅客想要订票。
还有，用例图好象有问题，订票应该是旅客发起的吧，售票员只管售票才正确，如果按你描述的，订票应该是订票员，然后，售票员和订票员才从业务员那里一般化过来。
usrsdh 2006-07-06
- 打赏
- 举报
一、用例说明问题较多，对用例来说，系统是透明的，主角应用主动语，如
1、 系统显示查询售票信息界面。
2、 选择船舶（默认为香雪兰）。
1系统显示，这不是用例描述语言。2选择船舶，是谁选择？不清楚。
二、一个用例多个主角时，说明不够清楚。
如查询售票信息用例。公司领导，公司财务人员查询售票信息，应该是不同的备选流，不同的场景进行区分。
三、include和extend关系不明
四、用例太粗，如订票应细分为email订票，电话订票，因为你的目标级别是业务级，而不是实现级。
1、 系统显示查询售票信息界面。
2、 选择船舶（默认为香雪兰）。
1系统显示，这不是用例描述语言。2选择船舶，是谁选择？不清楚。
二、一个用例多个主角时，说明不够清楚。
如查询售票信息用例。公司领导，公司财务人员查询售票信息，应该是不同的备选流，不同的场景进行区分。
三、include和extend关系不明
四、用例太粗，如订票应细分为email订票，电话订票，因为你的目标级别是业务级，而不是实现级。
jiezhi 2006-07-05
- 打赏
- 举报
必须售票后才可以退票，应该有联系！是一种先后顺序。只是这个联系应该怎么表达？
-----------
使用前置条件和后置条件,而不是使用关联.用例都有发生的前提条件的.
-----------
使用前置条件和后置条件,而不是使用关联.用例都有发生的前提条件的.
mathematician 2006-07-05
- 打赏
- 举报
上面又一个错误：
查询售票信息”和“售票”、“退票”存在扩展关系，更正。
查询售票信息”和“售票”、“退票”存在扩展关系，更正。
floatbear 2006-07-05
- 打赏
- 举报
--查询售票信息”和“售票”、“退票”存在扩展关系，更正。
似乎从逻辑上说不太通。售票、查询和退票属于一个操作序列的相关操作。为什么是扩展关系呢？查询对退票进行了什么扩展？
似乎从逻辑上说不太通。售票、查询和退票属于一个操作序列的相关操作。为什么是扩展关系呢？查询对退票进行了什么扩展？
floatbear 2006-07-05
- 打赏
- 举报
使用前置条件和后置条件表示顺序关系是可以的。不过用例图里面尽量少包含些顺序关系可能比较好。太多的操作细节最好放到系统内部。比如我感觉也许把售票作为一个用例比较好，其中可以使用订票、退票等相关用例。这样可以避免细节都暴露出来。个人意见，对本例不一定合适。
mathematician 2006-07-05
- 打赏
- 举报
终于来人了！happy ing...
“售票员”既然已经使用了“订票”，那么为什么还要直接使用“售票”（而订票是对售票的扩展）。
--------
可以先订票再售票，也可以直接进行售票。所以会分别有“订票”和“售票”两个用例。
另外，订票和售票之间好像应该有扩展关系吧？不确定。
“退票”为什么和“售票”没有任何关系？
--------
必须售票后才可以退票，应该有联系！是一种先后顺序。只是这个联系应该怎么表达？
“查询售票信息”用例扩展了太多的相关用例。这种情况应该避免。
-------------------------
“查询售票信息”仅和“售票”存在扩展关系，和“查询航次信息”之间是包含关系，不算太多吧？呵呵！
（2）没看明白，为什么“业务人员”和“售票员”有联系。
-------------------
售票员的所有工作，业务人员都可以做，所以他们之间是泛化关系。
（3）用例图似乎还没画完。
比如“添加航次信息”和其他部分的关系好象没画完吧。
----------------------
添加航次信息以后才可以进行订票、售票等操作，它们之间也存在先后顺序。只是不知道在用例图中应该如何表达这种关系？
“售票员”既然已经使用了“订票”，那么为什么还要直接使用“售票”（而订票是对售票的扩展）。
--------
可以先订票再售票，也可以直接进行售票。所以会分别有“订票”和“售票”两个用例。
另外，订票和售票之间好像应该有扩展关系吧？不确定。
“退票”为什么和“售票”没有任何关系？
--------
必须售票后才可以退票，应该有联系！是一种先后顺序。只是这个联系应该怎么表达？
“查询售票信息”用例扩展了太多的相关用例。这种情况应该避免。
-------------------------
“查询售票信息”仅和“售票”存在扩展关系，和“查询航次信息”之间是包含关系，不算太多吧？呵呵！
（2）没看明白，为什么“业务人员”和“售票员”有联系。
-------------------
售票员的所有工作，业务人员都可以做，所以他们之间是泛化关系。
（3）用例图似乎还没画完。
比如“添加航次信息”和其他部分的关系好象没画完吧。
----------------------
添加航次信息以后才可以进行订票、售票等操作，它们之间也存在先后顺序。只是不知道在用例图中应该如何表达这种关系？
mathematician 2006-07-05
- 打赏
- 举报
多谢jiezhi(风满袖)提醒！本来看书时感觉挺明白的，怎么写着写着就忘了，呵呵！
floatbear 2006-07-03
- 打赏
- 举报
不一定正确，说点个人看法：
（1）用例间的关系有点乱
比如“售票员”既然已经使用了“订票”，那么为什么还要直接使用“售票”（而订票是对售票的扩展）。
再比如“退票”为什么和“售票”没有任何关系？
还有，“查询售票信息”用例扩展了太多的相关用例。这种情况应该避免。
所以个人感觉第一个问题就是用例分解的似乎不是非常恰当。
（2）没看明白，为什么“业务人员”和“售票员”有联系。
（3）用例图似乎还没画完。
比如“添加航次信息”和其他部分的关系好象没画完吧。
个人观点，不一定正确。
（1）用例间的关系有点乱
比如“售票员”既然已经使用了“订票”，那么为什么还要直接使用“售票”（而订票是对售票的扩展）。
再比如“退票”为什么和“售票”没有任何关系？
还有，“查询售票信息”用例扩展了太多的相关用例。这种情况应该避免。
所以个人感觉第一个问题就是用例分解的似乎不是非常恰当。
（2）没看明白，为什么“业务人员”和“售票员”有联系。
（3）用例图似乎还没画完。
比如“添加航次信息”和其他部分的关系好象没画完吧。
个人观点，不一定正确。
mathematician 2006-07-03
- 打赏
- 举报
来人啊，我都没法结帖。
