模板-用例规约
文档编号：5组
密级：内部
缤纷视频网项目
用例规约
二零一三年七月
关于本文档
项目名称×××项目
主题用例规约
说明该项目用于网上购物
适用对象该项目适用于代替以往的购物方式，改为网上购买食品的用户。
修订历史
版本章节类型日期作者说明1.0 C
说明：类型－创建（C）、修改（U）、删除（D）、增加（A）；
评审记录
角色签名日期说明
目录
1. 1.引言 (1)
1.1 1.1文档编制目的 (1)
1.2 1.2背景 (1)
1.3 1.3参考资料 (1)
2.用例结构.......................................................................................................................... 错误！未定义书签。
2.1 用例包结构.............................................................................................................. 错误！未定义书签。
2.2 用例列表.................................................................................................................. 错误！未定义书签。
3.用例规约1（编号/名称）.............................................................................................. 错误！未定义书签。
3.1 概述.......................................................................................................................... 错误！未定义书签。
3.2 事件流程.................................................................................................................. 错误！未定义书签。
3.2.1基本流程.......................................................................................................... 错误！未定义书签。
3.2.2备选流程.......................................................................................................... 错误！未定义书签。
3.3 特殊要求.................................................................................................................. 错误！未定义书签。
3.4 前置条件 (12)
3.5 后置条件 (12)
3.6 数据实体 (12)
3.7 扩展点 (12)
3.8 界面原型 (12)
3.9 其他说明 (13)
1.引言
1.1文档编制目的
本文档编写的目的是为了描述用户和系统之间相互作用，从外部角度描述系统的行为，表达系统应该做什么。本文档通过用例规约描述，来进一步说明该系统需求的需求，是下一阶段系统设计的基础，也是测试用例的重要依据。此用例是为了用户的使用。
1.2背景
本系统是用来进行网上便捷购物的，主要功能包括用户登录、个人信息维护、在线购物、商品信息管理、会员管理。随着着互联网技术于电子商务应用的的不断成熟于发展，网上购物在互联网中的实现，越来越多的人改变原来的购物方式，改为在网上购物，因此编写本文档使读者更清晰的了解这个系统。。
[叙述用例规约的目标、作用范围以及其他应向读者说明的理解本文档所需的背景，如与公司其它软件之间的联系等。]
1.3参考资料
[1] 郭真，王国辉,《Jsp应用教程》，人民邮电出版社,2008
[2]魏茂军张文建,姜云善刘全民,《JSP案例开发——项目开发风暴》，中国水利水电出版社,2005
[3]朱涛正，张文静,《jsp高级程序设计》，人民邮电出版社
2.用例描述
2.1.顾客/用户
2.1.1 会员注册
1.2 会员登录
1.3 个人信息维护用例名称：会员注册
用例ID：
角色：User
用例说明：User注册成网上购物商城系统
前置条件：User已经打开网上购物商城系统的页面
基本事件流： 1. User打开注册页面
2. User输入E-mail地址（作为用户名）、昵称、登录密码、再次输入登
录密码，
3. 单击“提交”；
4. 系统将验证登录用户名的有效性和重复行、密码的正确性，如果都正
确则显示“你已成功注册”，否则提示用户重新输入。
其它事件流：第三步：User 选择“重置”，系统将清空输入框信息；
第三步：User 选择“返回”，该页面将返回到网上购物商城系统主页面。异常事件流：第四步，系统注册时出现系统故障，例如网络故障，数据库服务器故障，系统弹出系统异常页面，提示会员注册失败
后置条件：
用例名称：会员登录
用例ID：
角色：User
用例说明：User注册成网上购物商城系统的会员
前置条件：User已经是网上购物商城系统的会员
基本事件流： 1. User请求进入网上购物商城系统
2. User打开登录页面
3. User输入E-mail地址（作为用户名）、登录密码，再选择“登录”；
4. 系统验证登录用户名和密码的正确性，如果正确则进入网上购物商城系
统，否则提示用户重新输入。
其它事件流：第三步：User 选择“重置”，系统将清空输入框信息；
第三步：User 选择“忘了密码”，该页面将跳转到找回密码的页面。
异常事件流：第五步，系统注册时出现系统故障，例如网络故障，数据库服务器故障，系统弹出系统异常页面，提示会员登录失败
后置条件：
用例名称：个人信息维护
用例ID：
角色：User
用例说明：用来维护会员的相关信息：昵称和密码……
前置条件：User登录了网上购物商城系统
基本事件流： 1. User打开个人信息维护页面
2.1 购物
流程模块
u s e r
添加商品
修改商品数量
删除选购商品
结账
2.1.1 添加购买商品信息
用例描述：
用例名称： 新增购物车商品信息 用例ID ： US_1 角色： user
用例说明： user 新增购物信息。 前置条件： User 已经登录OS 系统。
基本事件
1．User 获取选购商品信息，点击商品图片
2. User 输入你需要修改的昵称（可为空）、原密码、新密码、密码确认再选择“登录”；
3. 系统验证原密码的正确性、新密码与确认密码的一致性，如果正确则提示成功并返回主页面 ，否则提示用户重新输入。 其它事件流：
第三步：User 选择“重填”，系统将清空输入框信息；
第三步：User 选择“返回”，该页面将跳转回系统主页面页面。 异常事件流： 第四步，系统注册时出现系统故障，例如网络故障，数据库服务器故障，系统弹出系统异常页面，提示个人信息维护失败
后置条件：
流：2．系统打开用户选定商品的详细信息页面
3．系统显示商品信息，包括商品图片、市场价、会员价、库存量、商品描述，并选择“确认购买”，如果该商品库存量为0，则只能选择‘收
藏’，不购买，只有库存量大于0，方可购买
4．user选择继续购买
异常事件
流：
1．若网速出现故障，则页面无法打开
后置条件：无
2.1.2 删除购买商品信息
用例描述：
用例名
称：
修改购买商品信息
用例ID：TS_2
角色：user
用例说
明：
user删除选购商品信息
前置条
件：
user已经登录OS系统
基本事件流：1. user选择‘删除’按钮
2. OS系统打开确认删除对话框
https://www.wendangku.net/doc/d09948190.html,er点击‘确认’按钮，删除商品信息
4.系统删除选中的商品信息，并更新商品信息列表
其它事件流：
第3步，user选择“取消”，系统将取消删除操作，并返回商品列表页面
异常事件流：
第4步，系统删除商品信息时出现系统故障，例如网络故障，数据库服务器故障，系统弹出系统异常页面，提示user删除失败
后置条
件：
无
2.1.3 修改商品数量
用例描述：
用例名称：修改商品数量
用例ID：XS_3
角色：user
用例说明：user更改购物列表中商品数量信息
前置条件：user已经登录OS系统
基本事件流： 1. user更改选购的商品列表中数量文本框中的信息
2. user点击‘更新’按钮，更新修改信息，如果更新的数量小于
等于库存，系统将显示更新后的数量，价格和总价；如果更新的数量小
于库存，系统将提示库存不足。
其它事件流：无
异常事件流：第6步，系统保存商品数量时出现系统故障，例如网络故障，数据库服务器故障，系统弹出系统异常页面，提示user更改商品数量失败后置条件：系统更新商品数量信息。
2.1.4 结账
用例描述：
用例名称：结账
用例ID：GS_4
角色：user
用例说明：SM结账
前置条件：user已经登录OS系统
基本事件流： 1. user点击“进入结算中心”，前提是购物车中至少要有一件商品
2.OS系统打开订单页面，显示商品清单，包括商品名、市场价、会
员价、数量、总价、送货地址和配送方式等信息。
https://www.wendangku.net/doc/d09948190.html,er选择配送方式，只支持“货到付款”。
4.确认购买，点击“提交订单”
5．系统显示“您的订单已提交成功！”和订单总金额，购买完成。
6．系统保存结账信息，并返回到商城主页面。
其它事件流：第1步，user若没有登录系统，则提示用户先登录系统，同时若是用户没有注册账号，提示用户先注册账号
第2步．user选择‘修改’按钮，对已选购的商品信息进行修改
第2步．若用户是首次结账，需要填写送货地址，送货地址包括：姓名、本地/外地、通讯地址、邮政编码、电话号码。非首次结帐，显
示上次购物时的送货地址，并默认为本次的送货地址。
异常事件流：第6步，系统保存结账信息时出现系统故障，例如网络故障，数据库服务器故障，系统弹出系统异常页面，提示SM结账失败
后置条件：系统更新结账信息。
2.2 后台管理-商品目录管理
SM 添加商品目录
修改商品目录
删除商品目录
2.2.1 添加商品目录信息
用例描述：
用例名称：添加商品目录信息
用例ID：OS_U1
角色：SM
用例说明：SM添加商品目录信息
前置条件：SM已经登录OS系统。
基本事件流： 1.SM进入‘商品管理’页面，该页面包括商品目录列表和‘添加目录’栏目。
2．在添加目录一栏中，SM可以添加商品目录，商品目录信息包括：目录名、父目录(下拉列表框选择)、目录描述、目录图片。目录名
为必填项，父目录如不选表示新添加的目录为根目录；如选择了某一
目录，表示新建的目录是该目录的子目录。
3．SM选择‘添加’按钮
4．系统保存新建商品目录，并返回到商品目录页面
其它事件流：第4步．SM选择“重置”，系统清空添加目录中添加的商品信息第4步．当目录名为空时，系统会提示出错，并要求用户输入
异常事件流：1．系统保存新建商品目录时出现系统故障，例如网络故障，数据库服务器故障，系统弹出系统异常页面，提示SM保存失败
后置条件：商品目录信息保存到数据库中。
2.2.2 修改商品目录信息
用例描述
用例名称：修改商品目录信息
用例ID：OS_TS2
角色：SM
用例说明：SM修改商品目录信息
前置条件：SM已经登录OS系统
基本事件流： 1. SM进入商品管理页面
2.SM选择任意一个目录，然后点击“编辑目录”按钮可以修改
选定的目录信息
3.系统会以原始信息填充目录各属性信息，管理员可以对这些
信息进行修改
4．SM点击‘提交’按钮
5．提交后，系统将返回目录列表页面。
6.系统保存修改商品目录信息
其它事件流：第4步.SM选择‘重置’，系统回复原始商品目录信息
第4步．SM选择‘返回’按钮，取消修改操作，系统返回商品目录页面
第2步.系统更新前检查SM输入商品目录信息的正确性，若有错误，则系统提示不正确信息，请重新输入
异常事件流：第6步，系统保存商品目录信息时出现系统故障，例如网络故障，数据库服务器故障，系统弹出系统异常页面，提示SM修改商品目录
失败
后置条件：系统更新商品目录信息。
2.2.3 删除商品目录
用例描述：
用例名称：删除商品目录
用例ID：OS_C3
角色：SM
用例说明：SM删除商品目录
前置条件：SM已经登录OS系统
基本事件流： 1. SM点击进入商品目录管理页面
2. SM选择任意一个或多个目录，点击“删除目录”按钮
3.系统将会弹出删除确认对话框，询问是否确定删除目录
4.SM选择‘确认’，删除商品目录。如果该目录下有子目录，或该目录下有商品，将无法删除目录；否则，可以删除目录
其它事件流：第4步，SM
可选择‘取消’，以取消当前删除操作，系统并将返回
商品目录页面
异常事件流：第4步，系统删除商品目录时出现系统故障，例如网络故障，数据库服务器故障，系统弹出系统异常页面，提示SM删除失败
后置条件：系统删除用户选中的商品目录，并把该商品目录相关的数据如商品名，商品价格等从数据表中删除
2.3 后台管理-商品管理-
SM 添加商品信息
修改商品信息
删除商品信息
2.3.1 添加商品信息
用例描述：
用例名称：添加商品信息
用例ID：OS_US1
角色：SM
用例说明：SM添加商品信息
前置条件：SM已经登录OS系统。
基本事件流： 1.SM进入‘商品管理’页面，该页面商品目录列表。
2．SM点击任意一个目录名称，将展开该目录，显示该目录下的所有目录
3．SM点击某个终级目录名称，将展示该目录下的商品列表和“添加商品”栏目
4．SM在“添加商品”栏目中输入商品信息：商品名称、商品描述、商品图片、价格、库存量、即可添加商品。其中商品名称、价格、库存
量，当有任意一项为空时，系统将会提示出错，并要求输入
5.SM选择‘添加’，完成商品信息的添加
6.系统保存添加的商品信息。
其它事件流：第4步．SM选择“重置”，系统清空添加‘添加商品’栏目中添加的商品信息
第4步．当目录名为空时，系统会提示出错，并要求用户输入
异常事件流：1．系统保存新建商品信息时出现系统故障，例如网络故障，数据库服务器故障，系统弹出系统异常页面，提示SM保存失败
后置条件：商品信息保存到数据库中。
2.3.2 修改商品信息
用例描述：
用例名称：修改商品信息
用例ID：OS_TP2
角色：SM
用例说明：SM修改商品信息
前置条件：SM已经登录OS系统
基本事件流： 1. SM进入商品管理页面，商品列表将会展示该目录下所有商品的简要信息：图片、名称、价格
2.SM选择任意一个商品，然后点击“修改”按钮，可以修改选
定的商品信息
3.系统弹出确认修改对话框
4．SM点击‘提交’按钮，完成商品信息修改
5．提交后，系统将返回商品信息页面。
6.系统保存修改商品信息
其它事件流：第4步.SM选择‘取消’，系统回复原始商品信息，返回商品管理页面
第4步．SM选择‘返回’按钮，取消修改操作，系统返回商品管理页面
第2步.系统更新前检查SM输入商品信息的正确性，若有错误，则系统提示不正确信息，请重新输入
异常事件流：第6步，系统保存商品信息时出现系统故障，例如网络故障，数据库服务器故障，系统弹出系统异常页面，提示SM修改商品目录失
败
后置条件： 系统更新商品信息。
2.3.3 删除商品信息
用例描述： 用例名称： 删除商品信息
用例ID ：
OS_CP3 角色： SM
用例说明： SM 删除商品信息 前置条件： SM 已经登录OS 系统 基本事件流：
1. SM 点击进入商品管理页面
2. SM 选择任意一个商品，点击“删除”按钮
3. 系统将会弹出删除确认对话框，询问是否确定删除该商品信息
4. SM 选择‘确认’，删除商品信息。如果收藏夹中的商品或存在订单与该商品关联，将无法删除商品；否则可以删除商品
其它事件流：
第2步，SM 可选择‘返回’，取取消本次删除操作，系统返回商品管理页面
第4步，SM 可选择‘取消’，以取消当前删除操作，系统并将返回商品目录页面
异常事件流： 第4步，系统删除商品时出现系统故障，例如网络故障，数据库服务器故障，系统弹出系统异常页面，提示SM 删除失败
后置条件：
系统删除用户选中的商品信息，并把该商品信息相关的数据如商品名，商品价格等从数据表中删除
2.4 后台管理-会员管理
SM
查看会员信息
删除会员信息
user
2.4.1 查看会员信息
用例名称：查看会员信息
用例ID：OS_LP1
角色：SM，User
用例说明：用户查看会员信息
前置条件：用户已经登录OS系统
基本事件流： 1. 用户点击‘会员管理’栏目，进入会员管理页面，该页面将显示包括会员姓名，会员号，会员身份证号，会员电话号码，会员地址等信息
2. 用户查看个人信息
5．用户选择“返回”
6．系统返回到网购主界面。
其它事件流：无
异常事件流：第4步，系统获取会员信息时出现系统故障，例如网络故障，数据库服务器故障，系统弹出系统异常页面，提示用户读取会员信息失败后置条件：无
2.4.2 删除会员信息
用例描述：
用例名称：删除会员信息
用例ID：OS_CSP2
角色：SM
用例说明：SM删除会员信息
前置条件：SM已经登录OS系统
基本事件流： 1. SM点击‘会员管理’栏目，进入会员管理页面
2. SM选择目标会员信息，点击“删除”按钮
3.系统将会弹出删除确认对话框，询问是否确定删除该会员信
息
4.SM选择‘确认’，删除会员信息。当存在订单与该会员关
联时将无法删除会员
5.系统返回会员管理页面
其它事件流：第2步，SM可选择‘返回’，取取消本次删除操作，系统返回
会员管理页面
第4步，SM可选择‘取消’，以取消当前删除操作，系统并将
返回商品目录页面
异常事件流：第4步，系统删除会员信息时出现系统故障，例如网络故障，
数据库服务器故障，系统弹出系统异常页面，提示SM删除失败
后置条件：系统删除用户选中的会员信息，并把该会员信息相关的数据如
会员姓名，会员号等从数据表中删除
2.1前置条件
3.4.1登录：
用户执行订单状态查询用例之前先登录
3.4.2购买：
用户在购买之前，先进行登录或注册。
[前置条件是开始用例前所必需的系统及其环境的状态。]
2.2后置条件
3.5.1进入修改订单页面
用户看到订单修改或删除，点击进入订单修改页面
3.5.2进入付款页面
用户看到订单并确认正确但未付款，点击进入付款页面
3.5.3退出
[后置条件是用例结束后系统可能具备的状态。]
2.3数据实体
[说明用例中的数据实体的数据结构及效验逻辑。]
2.4扩展点
[定义在基本用例的哪些位置插入扩展用例。]
2.5界面原型
[描述用例涉及到的用户界面。如果这部分在“产品需求规格说明书”中已经描述清楚，这里可以略去。]
2.6其他说明
[描述与此用例相关的其他的说明。]
图书馆系统用例规约描述
用例规约描述Use Case Description 编号：TMP-UCD 版本
变更记录
填表说明 本文档的目的是依据《需求规格说明书》和原型，建立用例模型，并对用例模型进行具体描述。 《用例规约描述》是面向对象分析和设计的重要步骤。 《用例规约描述》需要进行评审。 《用例规约描述》是《需求规格说明书》的重要附件。
目录 1引言 ........................................ 错误!未定义书签。 目的....................................... 错误!未定义书签。 定义....................................... 错误!未定义书签。2用例描述 .................................... 错误!未定义书签。 用户管理................................... 错误!未定义书签。 用户创建 .............................. 错误!未定义书签。 用户导入 .............................. 错误!未定义书签。 个人信息修改 .......................... 错误!未定义书签。 用户权限修改 .......................... 错误!未定义书签。 用户作废 .............................. 错误!未定义书签。 图书管理................................... 错误!未定义书签。 批量导入图书信息 ...................... 错误!未定义书签。 ISBN新增单本图书信息 ................... 错误!未定义书签。 修改图书信息 .......................... 错误!未定义书签。 作废图书信息 .......................... 错误!未定义书签。 电子书上传 ............................ 错误!未定义书签。 电子书下载 ............................ 错误!未定义书签。 业务管理................................... 错误!未定义书签。 借书操作 .............................. 错误!未定义书签。
用例规约+活动图例子
一、用例规约作业 请根据中国工商银行网络银行的转账汇款的相关说明，试编写该用例的规格说明。要求从中体会业务规则的作用和分析，并在自己的课题中分析充分详尽的业务规则。 注：新发布的用例一章的课件中，有个取款相关的用例规格说明，可参考。 1.安全提示：为了您的资金安全，请勿轻信陌生人通过网络聊天群、直播、电话、短信等方式进行的诱导性“投资理财”、代办大额信用卡或高额贷款、网购客服或快递进行退货等非正规渠道要求进行转账汇款，谨防被骗。短信通知手续费将根据我行政策进行减免，请以实际扣款情况为准。 2.汇款类型：根据人民银行关于防范电信诈骗有关要求，我行为您提供“实时汇款、普通汇款、次日汇款”三种汇款方式选择。对于“普通汇款”和“次日汇款”，您可在限定时间内通过手机银行或网银“转账汇款-查询汇款明细”进行撤销。 3.到账时间：行内汇款一般实时到账，7*24小时受理。自2019年11月29日起100万元（含）以内跨行汇款，我行将优先通过网银互联系统汇出至收款行，一般实时到账，7*24小时受理。100万元以上跨行大额汇款，工作日交易时间（前一日20:30-当日17:15）一般实时到达收款行；工作日（周一至周四）非交易时间（17:15-20:30）提交，系统预约至当日20:30后汇出；非工作日，系统将做预约处理，待下一工作日交易时间（一般为节假日最后一天20:30后）汇出。准确时间以人民银行系统为准。 4.收款人信息：当您向其他银行汇款时，系统无法判断收款人信息是否准确，仅对信息格式进行校验，请您务必准确填写收款人户名、卡（账）号、收款行等信息，若因上述信息填写错误导致汇款失败，手续费不退回。汇款成功后收款人信息将自动添加至“我的收款人”，方便您再次汇款操作。您还可直接输入收款人户名、手机号向其汇款，若其手机号已绑定银行账户（含他行），则将实时汇入绑定账户；若其手机号未绑定银行账户，则系统将向收款人发送短信，根据收款人短信回复卡/账号汇入资金。 5.交易限额：各类转账认证方式（U盾、电子密码器、短信）交易限额，您可在“工银e支付-安全管理-认证管理”或“安全-认证管理”下查看、调整。向绑定工行账户手机号汇款交易限额受支付认证方式控制；向绑定他行账户手机号汇款，单笔最高100万元；向未绑定银行账户手机号汇款单笔最高5万元。（注：手机银行渠道可通过工银e支付办理最高单笔20万元、日累计100万元的转账） 6.汇款手续费：个人网银：本行（含同城和异地）汇款免收手续费；跨行汇款，每笔5000元（含）以下的免收手续费；5000元以上按柜面收费标准的五折收取。如您已购买结算套餐，将抵扣结算套餐并免收手续费。具体请参考我行门户网站“服务价目表”公布的收费标准及相关优惠活动。（注：手机银行境内人民币汇款目前暂不收费） 7.付款账户：自助注册卡无法使用U盾、密码器认证，若您已申领U盾或电子密码器，您可登录手机银行在“我的账户”下点击“功能升级”按钮，按照提示通过刷脸认证后将该卡升级为柜面注册卡。 8.其它说明：境内汇款不支持向16位财智账户卡汇款。国际借记卡、贷记卡外币账户作为收款账户可接收本人其他同币种外币账户转入的钞/汇；如作为付款账户，只可从外币现钞账户转出。
用例之间的关系(1)
3.4用例之间的关系 1、泛化关系Generalization 代表一般与特殊的关系。（类似于继承） 在用例泛化中，子用例表示父用例的特殊形式，子用例继承了父用例的行为和属性，也可以增加新的行为和属性或覆盖父用例中的行为。 例子：一个租赁或销售系统用例的部分内容，在此，父用例是“预定”，其两个子用例分别是“网上预定”和“电话预定”，这两个用例都继承了父用例的行为，并可以添加自己的行为。 2、包含关系Include 一个用例（基用例，基本用例）可以包含其他用例（包含用例）具有的行为，并把它所包含的用例行为作为自身用例的一部分，这被称为包含关系。 在UML中，包含关系表示为虚线箭头加版型《include》，箭头从基本用例指向包含用例。 例子：一个租赁或销售系统中，“填写电子表格”的功能在“网上预定”的过程中使用，不管如何处理“网上预定”用例，总是要运行“填写电子表格”用例，因此具有包含关系。3、扩展关系Extend 一个用例也可以定义为基本用例的增量扩展，这称作扩展关系，即扩展关系是把新的行为插入到已有的用例中的方法。在UML中，包含关系表示为虚线箭头加版型《extend》，箭头从扩展用例指向基本用例。 基本用例提供了一组扩展点，在这些新的扩展点中可以添加新的行为，而扩展用例提供了一组插入片段，这些片段能够被插入到基本用例的扩展点上。 扩展关系可以有控制条件，当用例实例执行到达一个扩展点时，控制条件决定是否执行扩展。一般情况下，基本用例的执行不会涉及到扩展用例，只有满足用例的控制条件时，扩展用例才被执行，因此扩展关系处理事件流的异常或者可选事件。同一个基本用例的几个扩展可以在一起使用。 基本用例不知道扩展的任何细节.没有扩展用例,基本用例是完整的。 例子：一个汽车租赁系统用例图的部分内容。在此，基本用例是“还车”，扩展用例是“交纳罚金”。如果一切顺利汽车可以被归还，那么执行“还车”用例即可。但是如果超过了还车的时间或汽车受损，按照规定客户要交纳一定的罚金，这时就不能执行提供的常规动作。若研讨修改用例“还车”，势必会增加系统的复杂性，因此可以在用例“还车”中增加扩展点，即特定条件为超时或损坏，如果满足条件，将执行扩展用例“交纳罚金”，这样显然可以使系统更容易被理解。 4、参与者与用例之间的关系：关联关系Association 关联关系描述参与者与用例之间的关系，在UML中它是两个或多个类元之间的关系，它描述了类元的实例间的联系。（类元，一种建模元素，常见类元包括类、参与者、构件、数据类型、接口、结点、信号、子系统以及用例等，其中类是最常见的类元。） 关联关系表示参与者和用例之间的通信。在UML中，关联关系用直线或箭头表示。关联中communicates版型是参与者和用例之间唯一的版型,一般省略不写。如果参与者启动了用例，箭头指向用例；如果参与者利用了用例提供的服务,箭头指向参与者。如果二者是互动的，则是直线。
用例规约(实例)
课程注册系统用例规约 版本<1.0>
查看成绩报告卡用例 1.简要说明 本用例允许学生查看他（她）刚结束学期的成绩报告卡。 本用例的 Actor 是学生。 2.事件流 当学生从主表格中选择“查看成绩报告卡”活动时，用例开始。 1.基本流—查看成绩报告卡 1.系统检索出学生上个学期所修完的每门课程的成绩信息。 2.系统准备、排版并显示成绩信息。
3.当学生完成查看成绩信息后，选择“关闭”。 2.备选流 1.没有可以查看的成绩信息 如果在基本流中，系统不能找到这个学生上个学期的任何成绩 信息，将会显示一个消息。学生确认这条消息后，用例终止。 3.特殊需求 没有和本用例有关的特殊需求。 4.前置条件 1. 登录 在本用例开始之前，学生要登录到系统。 5.后置条件 没有和本用例有关的后置条件。 6.扩展点 没有和本用例有关的扩展点。 课程注册用例 1. 简要说明 此用例允许学生登记当前学期的课程。如果在学期开始的选/退课期间情况发生一些变化，那么学生也可以修改或删除自己所选的课程。课程目录系统提供一个本学期所有课程的列表。 本用例主要的主角是学生。课程目录系统是用例中包含的一个主角。 2. 事件流 当学生从主窗体中选择“维护课程表”活动时，此用例就开始使用了。 1. 基本流—创建课程表 1.学生选择“创建课程表”。 2.系统会显示一张空白课程表。
3.系统从课程目录系统中检索可选课程的列表。 4.学生从可选课程列表中选择 4 门主修课程和 2 门选修课程。在完成选择后， 学生选择“提交”。 5.在此步骤中为每一门所选课程执行“添加课程”子流程。 6.系统保存该课程表。 2. 备选流 1. 修改课程表 1.学生选择“修改课程表”。 2.系统检索并显示学生现在的课程表（例如，本学期的课程表）。 3.系统从课程目录系统中检索本学期所有可选课程的列表。系统向学生显 示该列表。 4.这样，学生就可以通过删除或者添加新课程来修改所选的课程。学生从 可选课程列表中选择要添加的课程。学生也可以从目前的课程表中选择 要删除的课程。在完成编辑后，学生选择“提交”。 5.在此步骤中为每一门所选课程执行“添加课程”子流程。 6.系统保存该课程表。 2. 删除课程表 1.学生选择“删除课程表”活动。 2.系统检索并显示学生当前的课程表。 3.学生选择“删除”。 4.系统提示学生核实该删除操作。 5.学生核实删除操作。 6.系统删除课程表。 3. 保存课程表 在任何时候，学生都可以不提交而选择“保存”来保存课程表。课程表 将被保存，但是该学生的信息没有添加到所选课程中。所选的课程在课 程表中标记为“已选”。 4. 添加课程 系统核实学生符合所需的先决条件并且该课程人数未满。然后系统将学 生添加到所选的课程中。这样，该课程在课程表中标记为“已登记”。 5. 先决条件不满足或课程已经满员 如果在“添加课程”子流程中，系统确定学生没有满足必要的先决条件 或者所选择的课程人数已满，就会出现一个错误消息。学生可以选择另 一门课程，也可以取消本次操作，此时用例重新开始。
用例图和用例描述设计实例
用例图和用例描述设计实例 作者：ephyer 发表时间： 2004-09-09 18:01:35 更新时间： 2004-09-09 18:01:35 浏览：1954次 主题：电脑技 术 评论：0篇 地址：202.19 7.75.* :::栏目::: ? T hinkin g in jav a 学习 笔记 ? J A VA 基 础知识 ? U ML ? 软 件设计 师 ? 其 他类别 这里用我开发的一个家教网站来简单的分析用例图的画法和用例描述的 写法。这个网站我用UML 完整的分析一下，以下我提取了用例图和用例描述 的部分。这个家教网站分为前台客户系统和后台管理系统。 前台客户系统的用例图如下： 后台管理系统用例图如下： 对于用例描述，篇幅有限，我在这里只列了后台管理系统中的网站公告发布这个用例的描述。如下：
用例名称：用户登录 用例标识号：01 参与者：管理员、普通用户 简要说明： 参与者输入用户名、密码以及验证码，系统进行验证后，合法者登录系统，否则提供拒绝登录系统。 前置条件： 参与者已经打开系统的登录页面（login.jsp） 基本事件流： 1．参与者在用户名输入框里输入用户名 2．在密码框里输入密码 3．密码框下方显示验证码，验证码由4位数字构成，用户按原样输入验证码。 4．用户按登录后，系统验证参与者输入的有效性。 5．有效则进入系统的主界面。无效则提示相应错误给用户。 6．用例终止 其他事件流A1： 在按“登录”按钮之前，参与者可以随按“取消（或关闭）”按钮。 异常事件流： 1．提示错误信息，参与人确认 后置条件：进入的主界面main.jsp ,装载相应的数据 注释：（可选：记住用户）
用例规约模板
用例规约：<用例名称> [以下提供的模板用于用例规约，它包含以文本表示的用例特征。该文档和需求管理工具（如 Rational RequisitePro）一起使用，用于详细说明用例特征中的需求，并对这些需求进行标记] [用例图可在可视化建模工具（如 Rational Rose）中开发。用例报告（具有所有特征）可用 Rational SoDA 生成。有关详细信息，请参见 Rational Unified Process 中的工具向导。] 1.用例名称 1.1简要说明 [此说明应该简要介绍该用例的作用和目的。一个段落即足以作此说明。] 2.事件流 2.1基本流 [当主角有所行动时，此用例随即开始。总是由主角来带动用例。用例应说明主角的行为及系统的响应。应按照主角与系统进行对话的形式来逐步引入用例。 用例应说明的是系统内发生的事件，而不是事件发生的方式和原因。如果进行了信息交换，则需指出来回传递的具体信息。例如，只表述主角输入了客户信息就不够明确。最好明确地说主角输入了客户姓名和地址。通常可以利用词汇表让用例的复杂性保持在可控范围内?您最好在词汇表中定义客户信息等内容，使用例不至于陷入过多的细节。 简单的备选流可以在用例文本中提供。如果只需几句话就可说明存在备选流时将发生的事件，则可以直接在事件流一节中说明。如果备选流较为复杂，则需要用另外一节来单独说明。例如，备选流小节解释如何说明较复杂的备选流。 虽然清晰明了的叙述性文字是无可替代的，但有时一幅图要比千言短文更具说明性。只要表达得简洁明了，您就可以在用例中任意粘贴用户界面和流程的图形化显示方式，或是其他图形。如果流程图有助于描述复杂的决策流程，那么一定要充分利用它！同样，对于与状态相关的行为，状态转移图通常比数页文字更能清晰地描述系统的行为。根据问题来选用妥当的表示方法，但应慎用您的读者可能不太明了的术语、符号或图形。请切记，您的目的是要阐明问题，而不是混淆问题。] 2.2备选流 2.2.1<第一备选流> [较复杂的备选流应单独说明，这已在事件流一节的基本流小节中提及。将备选流小节当作备选行为? 在许多情况下，由于主事件流中发生异常事件，这时每个备选流都可代表备选行为。这些备选流的长度可以是说明与备选行为相关的事件所需的长度。当备选流结束时，除非另外说明，主事件流的事件将重新开始。] 2.2.1.1<备选分支流> [如果能使表达更明确，备选流又可再分为多个支流。] 2.2.2<第二备选流> [在一个用例中很可能会有多个备选流。为了使表达更清晰，应将各个备选流分开说明。使用备
OO系统分析员--用例规约的编写--业务规则和实体描述
OO系统分析员之路--用例规约的编写--业务规则和实体描述 上一篇我们图形化建模的部分基本上完成了，得到了业务用例模型，这帮助我们获得了功能性需求。得到了业务场景和用例场景，这帮助我们获得了面对业务的执行过程描述和概念（逻辑）模型，让我们知道业务将如何的运作。得到了用例实现以及领域模型，这帮助我们得知哪些业务用例将在系统中实现，对应这些用例，哪些业务实体将会被包括进来，以及它们如何帮助业务实现。上一篇我们也留下了悬念，对于业务执行过程来说，除了以上的成果，我们还需要知道业务规则，以及业务实例的属性。即我们要如何做以及做什么。这一篇就来讨论这些内容。 先说说业务规则。笔者习惯将业务规则分为三种。 一种是全局规则，这种规则一般与所有用例都相关而不是与特定用例相关，例如actor要操作用例必须获得相应的授权，用例的操作与授权级别相关，或者用户在系统中的所有操作都要被记录下来等等。这类规则笔者习惯于，并且也建议将它们写到用例的补充规约里面去，因为它们一般与具体的业务功能性要求没有直接关系。有时候，这类规则也被写到软件架构文档中。关于用例补充规约以后再讨论。 第二种是交互规则。这种规则产生于用例场景当中，例如当提交一份定单时，哪些数据是必须填写的，用户身份是否合法。当然也包括一般理解上的业务流程流转规则等，例如金额大于一万元的定单被定为VIP定单进入特殊流程等。这类规则一般要写到用例规约中。交互规则实际上还有两个是比较特殊的，一个入口条件，也称为前置条件，即actor满足什么条件才能启动用例;另一个是出口条件，也称为后置条件，即用例结束后会产生哪些后果。稍后参看示例。 第三种是内禀规则。所谓内禀规则是指业务实体本身具备的规则，并且不因为外部的交互而变化的规则。例如，每张定单至少要有一件商品，同一类商品数量不能大于5件等。同时也包括大家所熟悉的数据效验规则，例如身份证号必须是15或18位，邮编必须是6位等等。这类规则是业务实体的内在规则，因此应该写到领域模型文档中 读者或许对把规则这么分类有不同的习惯和理解，可能会觉得麻烦。但是笔者这么做有充分的理由。首先，全局规则与具体用例无关，它实际是系统应该具备的特性，这些规则把它分出来目的就是为了让系统去负责这些特性的实现。读者可以结合实际考虑一下，通常授权，事务，备份等特性都是由系统框架去实现的，具体的功能中并不去实现它们。如果读者有过基于某个框架开发应用的经历的话一定会认同笔者的话。其次，交互规则是在用例场景当中产生的，它们规定了满足什么条件后业务将如何反应。通常，这部分规则是最复杂，也最不稳定，最容易变化的。大家所说的需求经常变更相信绝大部分就来自于此。因此将这些规则单独列出来并给予关注和管理是很有必要的。同时这部分规则通常在系统中以Control类去实现，MVC模式如此，SOA架构中的BPEL也是如此。如果需求无可避免的要变更，那么，将交互规则单独提取出来，并设计成为扩展性很强的结构
用例之间的关系
用例之间的关系 1、泛化关系Generalization 代表一般与特殊的关系。（类似于继承） 在用例泛化中，子用例表示父用例的特殊形式，子用例继承了父用例的行为和属性，也可以增加新的行为和属性或覆盖父用例中的行为。 例子：一个租赁或销售系统用例的部分内容，在此，父用例是“预定”，其两个子用例分别是“网上预定”和“电话预定”，这两个用例都继承了父用例的行为，并可以添加自己的行为。 2、包含关系Include 一个用例（基用例，基本用例）可以包含其他用例（包含用例）具有的行为，并把它所包含的用例行为作为自身用例的一部分，这被称为包含关系。 在UML中，包含关系表示为虚线箭头加版型《include》，箭头从基本用例指向包含用例。 例子：一个租赁或销售系统中，“填写电子表格”的功能在“网上预定”的过程中使用，不管如何处理“网上预定”用例，总是要运行“填写电子表格”用例，因此具有包含关系。 3、扩展关系Extend 一个用例也可以定义为基本用例的增量扩展，这称作扩展关系，即扩展关系是把新的行为插入到已有的用例中的方法。在UML中，包含关系表示为虚线箭头加版型《extend》，箭头从扩展用例指向基本用例。 基本用例提供了一组扩展点，在这些新的扩展点中可以添加新的行为，而扩展用例提供了一组插入片段，这些片段能够被插入到基本用例的扩展点上。 扩展关系可以有控制条件，当用例实例执行到达一个扩展点时，控制条件决定是否执行扩展。一般情况下，基本用例的执行不会涉及到扩展用例，只有满足用例的控制条件时，扩展用例才被执行，因此扩展关系处理事件流的异常或者可选事件。同一个基本用例的几个扩展可以在一起使用。 基本用例不知道扩展的任何细节.没有扩展用例,基本用例是完整的。 例子：一个汽车租赁系统用例图的部分内容。在此，基本用例是“还车”，扩展用例是“交纳罚金”。如果一切顺利汽车可以被归还，那么执行“还车”用例即可。但是如果超过了还车的时间或汽车受损，按照规定客户要交纳一定的罚金，这时就不能执行提供的常规动作。若研讨修改用例“还车”，势必会增加系统的复杂性，因此可以在用例“还车”中增加扩展点，即特定条件为超时或损坏，如果满足条件，将执行扩展用例“交纳罚金”，这样显然可以使系统更容易被理解。 4、参与者与用例之间的关系：关联关系Association 关联关系描述参与者与用例之间的关系，在UML中它是两个或多个类元之间的关系，它描述了类元的实例间的联系。（类元，一种建模元素，常见类元包括类、参与者、构件、数据类型、接口、结点、信号、子系统以及用例等，其中类是最常见的类元。） 关联关系表示参与者和用例之间的通信。在UML中，关联关系用直线或箭头表示。关联中communicates版型是参与者和用例之间唯一的版型,一般省略不写。如果参与者启动了用例，箭头指向用例；如果参与者利用了用例提供的服务,箭头指向参与者。如果二者是互动的，则是直线。 关联关系表示参与者和用例之间的通信。不同的参与者可以访问相同的用例，一般说来它们和该用例的交互是不一样的，如果一样的话，说明他们的角色可能是相同的。如果两种交互的目的也相同，说明他们的角色是相同的，就应该将他们合并。
用例规约描述
用例规约描述babasport Use Case Description 编号：OnlineShop 版本1.0 作者：张东日期： 审批：日期：
变更记录 日期版本变更说明作者2009-5-6 1.0 创建张东
目录 引言 (4) 目的 (4) 概述 (4) 用户登录模块 (4) 用户注册模块 (4) 用例描述 (5) 登录 (5) 主动登录 (5) 被动登录 (6) 注册 (7) 用户注册 (7)
引言 《用例规约描述》是描述项目小组对项目进行需求分析得到的关于用户和系统之间交互作 用的文本性描述文档。 目的 用例是关于用户和系统之间相互作用的文本性描述，从外部角度描述系统的行为，表达 系统应该做什么。本文档通过用例规约描述，来进一步说明该系统需求，是下一阶段系统设计的基础，也是测试用例的重要依据。 定义 缩写、术语解释 actor 系统外部使用功能者 use case 系统功能单元的描述 概述 本项目主要实现为网站用户提供注册登录服务。 用户登录模块 在这个模块中，用户可以登录到网站获得会员的权限。登录的方式有两种： 1. 用户主动希望登录到网站获得会员权限。 用户可以通过主页的“登录”链接来进入登录页面，进行登录操作。 2. 用户希望使用需要会员权限模块时，被系统要求登录。 用户在未登录状态下点击“我的账户”或者“进入结账中心”链接，系统要求用户进行登录。 登录后，用户获得会员权限，可以进行会员操作。在两种模式中用户忘记密码可以选择 点击“忘记密码了？”链接，来找回密码。 用户注册模块 在这个模块中，用户可以注册一个或者多个会员身份。注册的入口也有两个：
用例图
顾客 顾客用户2.1 用例建模技术 2.1.1 参与者和用例 参与者（actor ）是系统外部与系统有交互的任何事物，是为了完成一个事件而与系统交互的外部实体。参与者主要用于描述系统的边界。例如，向银行提交贷款申请的顾客；通过因特网访问预订系统查询座位情况的旅行社，等等。在UML 中，参与者经常用人形符号表示，或者用类的构造型《actor 》表示，如图2-3所示。 图2-3 参与者的UML 表示符号 参与者并不一定是系统的用户。它们可能是外部系统、外部机构、外部设备和其它与系统有交互的任何外部实体。图2-4展示参与者是外部系统的例子。 图2-4参与者是外部系统的例子 当参与者是人时，它是指一个与系统有交互的用户所扮演的角色。一个参与者并不是指一个特定的人或一个特定的实体。例如，参与者“顾客”是对顾客的概念建模，而不是对张三这个特定的顾客建模。 一个用例并不仅局限于一个参与者; 参与某用例的参与者可能是多个。然而，一个用例况必须向至少一个参与者提供可度量的价值。参与某用例的多个参与者各有不同的角色和职责：一些负责接收用例提供的价值，一些则负责向用例提供服务，其它则负责触发或初始化用例。Ivar Jacobson[1992]将参与者划为两类：主要的和次要的。主要参与者(primary actor)是从系统获得可度量价值的用户。主要参与者的需求驱动了用例所表示的行为或功能。如果他们的需求或角色发生了变化，那么系统将必须有重大的修改。次要参与者(secondary actor)在用例中提供服务，并且不能脱离主要参与者而存在。在图2-4所示的例子中，顾客是主要参与者，而客户关系系统则是次要参与者。 顾客<
用例描述模板
实验一编写用例（以下给出用例描述模板），并画出用例图（编写时可参照下面的实例） 用例描述模板 是一种被广泛使用的用于发现和记录需求(特别是功能需求)的机制。写出用例是一种最好的理解和描述需求的技巧。 注意：这个模板列出可以定义用例的典型标题，但应当强调的是，实用上更重要的是专注于写出完整的可理解的事件路径，而不是按指定的模板填写每个部分。 名称 用例的名称应当用简短的动词短语表达，说明用户使用用例完成的任务。 概述或简要描述 单列一节概述该用例完成什么通常是有益的。 参与者 列出此用例涉及的参与者和负责发起此用例执行的主要参与者。 触发器 触发器是开始此用例的事件。触发者并不必须向该系统输入事件，例如，在预约系统示例中，“预约”用例的触发者可能是“一个潜在的客户打给餐馆的一个预约电话”。而在另一种情况下，触发者可能是此用例中第一个系统事件。 前置条件 前置条件概述在用例可以开始前，什么必须为真。通常前置条件说明在指定的一个用例运行前，另一个什么用例必须运行。典型的前
置条件可以是“用户已成功登陆”。 后置条件 后置条件概述当用例完成时什么是真。在许多情况下，这将依赖于在一个特定用例实例中发生的确切的一系列交互。区分“最低保证”和“成功保证”可能是实用的，前者描述在所有情况下发生什么和不发生什么，后者描述如果正常的事件路径成功地完成将会发生什么。 事件路径或脚本 基本的或正常的事件路径，通常应当作为不中止的交互序列出现。对事件路径中的交互通常加以编号，以便于以后的参考。 可选和例外事件路径 可选和例外事件路径可以完整地写出。然而通常只须在基本事件路径中的分叉点简单地指明可选事件流，对行为可能改变的位置予以编号，并指明导致分叉的事件。 扩展点 这一节应当列出在事件路径中可能发生扩展的位置，并给出确定扩展是否发生的条件或事件。扩展本身应当作为单独的用例写出；否则，可以指明可选的事件路径。 例如，订餐系统中“记录未预约顾客”的用例可以作为“记录达到”用例的扩展。（因为在“记录未预约顾客”中指定的交互不是在每次执行“记录达到”时都执行） 包含 这一节简单地概述包含在已定义的用例中的用例。在哪些地方包
用例说明模板
经典模板一 1.用例名称 1.1 简要说明 [简要说明用例的作用和目的。该小节的篇幅不要太长。] 2.上下文图 [在此小节中，有一个只包括本用例和所有与该用例相关的Actor和其它用例组成的，一个用例图的局部。] 3. 事件流 3.1 基本流 [当Actor采取行动时，用例也就随即开始。用例总是由Actor启动的，用例应说明Actor 的行为及系统的响应，可按照Actor与系统进行对话的形式来逐步引入用例。] [要注意的是，用例描述应该说明系统内发生的事情，而不是事件发生的方式与原因。如果进行了信息交换，则需指出来回传递的具体信息。例如，只表述主角输入了客户信息就不够明确。最好明确地说主角输入了客户姓名和地址。当然你也可以通过项目词汇表来定义这些信息，使得用例中的内容被简化，从而不致于让用例描述陷入过多的细节内容。] [如果存在一些相对比较简单的备选流，只需少数几句话就可以说明清楚，那么也可以直接在这一部分中描述。但是如果比较复杂，还是应该单独放在备选流小节中描述。] [一幅图胜过千言万语，因此建议在这一小节中，除了叙述性文字之外，你还可以引用UML中的活动图、顺序图、协作图、状态图等手段，对其进行补充说明。] 3.2 备选流 3.2.1 第一备选流 [正如前面所述，对于较复杂的备选流应单独地说明。] 3.2.1.1 备选支流
[如果能使表达更明确，备选流又可再分为多个支流。] 3.2.2 第二备选流 [在一个用例中很可能会有多个备选流。为了使表达更清晰，应将各个备选流分开说明。使用备选流可以提高用例的可读性，并防止将用例分解为过多的层次。应切记，用例只是文本说明，其主要目的是以清晰、简洁、易于理解的方式记录系统的行为。] 4. 非功能需求 [在这个小节中，主要对该用例所涉及的非功能性需求进行描述。由于其通常很难以在事件流中进行表述，因此单列为一小节进行阐述。这些需求通过包括法律法规、应用程序标准、质量属性（可用性、可靠性、性能、支持性等）、兼容性、可移植性，以及设计约束等方面的需求。在这些需求的描述方面，一定要注意使其可度量、可验证，否则就容易流于形式，形同摆设。] 5. 前置条件 [用例的前置条件是执行用例之前必须存在的系统状态。] 6. 后置条件 [用例的后置条件是用例一执行完毕系统可能处于的一组状态。] 经典模板二