包含CRUD的用例该怎样描述呢。 用例编号:u1 用例名称:管理基本信息 执行者:业务人员 前置条件: 用户成功登录系统 后置条件: 系统已经保存用户录入、编辑、查询、删除的相关信息 涉众利益: 业务人员-方便、快捷的管理疏散信息 基本过程: 1. 用户选择信息管理功能 2. 系统显示信息管理界面 不知道后面该怎样描述了,大家帮忙啊
用例名称:管理危险品信息 执行者:业务人员 前置条件: 用户成功登录系统 后置条件: 系统已经保存用户录入、编辑、查询、删除的危险品信息 涉众利益: 业务人员-方便、快捷的管理危险品信息 基本过程: 1. 用户选择危险品信息管理功能 2. 系统显示危险品信息管理界面 一个典型的CRUD过程是怎样描述的呢,老兄可否给写个完整的过程? 另外用例中的步骤应该是“可观测”的,该如何衡量?象“系统验证口令通过”或“系统保存数据”等都可观测吗
现在的用户也在用技术术语和你交流,而且这种趋势在不断蔓延,更可悲的是,这些用户在描述他们的业务时又说不清,表面上他已经为我们的系统分析员考虑了很多,但实际上却是四不象,每碰上这样的客户,我就不知所措!!!
用例名称:管理危险品信息 执行者:业务人员 前置条件: 俱有管理权限的用户成功登录系统 后置条件: 修改结果保存到数据库中 涉众利益: 业务人员-方便、快捷的管理危险品信息 基本过程: 1. 用户单击"危险品信息管理"菜单或按钮 2. 系统显示危险品信息管理窗体 3.进行信息编辑 case 3.1 录入 3.2 编辑 3.3 查询 3.4 删除 end 4. 保存 5. 退出 可选路径 1.检查用户输入数据的合法性,如果非法提示重新输入 不知写得是否合适,请大家指教
是否该把录入、编辑、删除、查询都描述成include的形式?到底该怎样解决这类问题呢?另外我对用例如何划分越来越糊涂了,晕!
个人感觉抓住use case的本质目的是最重要的。就比如你所提到的“可观测性”,这其实是use case本质的一个体现而已。如果搞清本质,就不会对这个感到困惑。我个人理解是:把你自己想象成用户,他们在使用系统时的一个过程(对系统功能的使用,包括主动和被动的)就是用例。用例无需纠缠系统内部的实现及其中间过程,只需要tell能作什么就OK。 “象“系统验证口令通过”或“系统保存数据”等都可观测吗 ”,这个问题就不应该是问题了。个人认为这两个都可以包括进用例。但都不是恰当的描述方式。如果是我,我会描述成用户可以能够“看见”的方式。另外,好象典型的形式应该是动词+名词。这个我想也许你可以考虑一下。对uml理解很浅显,自己瞎说了一些自己的理解。多担待着。
前置条件: 基本流程: 可选流程: 非功能性需求: 补充说明: last updated on 2004-02-05 **.** History: 2003-12-25: firstdraft by **.** 2003-01-05: modify by **.**