UML建模之正式用例描述规范

    正式用列具有格式规范，包括：用例名、自然语言描述体、图例说明、范围、级别、主执行者、项目相关人员和利益、前置条件、最小保证、成功保证、触发事件、主成功场景、扩展场景和相关信息等项目，用例格式并不是硬性规定必须包括这此内容，只是为需求用例编写者提供正式用例编写格式参考，具体项目具体分析，以增减正式用例内容，更好地为需求分析服务；用例名、自然语言描述体、图例说明的编写方法同非正式用例，只是自然语言描述体只阐述不能在主成功场景和扩展场景中描述的部分，不必将场景全部说明。

范围
    范围（scope）用来描述项目开发人员负责的设计工作的边界，以便与应由其他人负责的设计工作或已经完成的设计工作相区别；范围应该是一个简单明确的名词，比如说需求人员正在对“固定资产”项目进行需求分析，则“范围”可以是“固定资产系统”。
级别
    级别分为三个目标层次：概要、用户目标、子功能，书写需求用例时，只能选择其一，下面对其具体说明：
    概要：包括多个用户目标，它有“显示相关目标的生命周期顺序”和“为低层用例提供一个目录表”的功能，概要用例通常需要执行几个小时、几天、几个星期、几个月、甚至几年。
    用户目标：它是主执行者努力使工作得以完成的目标，或是用户使用系统的目标，通常情况下指系统为用户提供的界面操作。
    子功能：指那些在实现用户目标时可能会被用到的目标，一般是指系统内部执行，而用户看不到界面的用例。
主执行者
    用例的主执行者是指任何具有行为的事物，主执行者通常是触发用例的执行者，可能是一个人、一个公司或组织、一个计算机程序或一个计算机系统，主执行者应该是一个主语名词，如“账务主管”、“总账系统”等。
项目相关人员和利益
    项目相关人员是对行为具有特定利益的人或物，他们的利益在系统执行的检查和确认中、在创建的日志中、以及在系统执行的动作中得以体现；项目相关人员是一个名词，紧接的利益是简明扼要的短语。
前置条件
    前置条件是指启动该用例之前系统必须满足的条件，通常，前置条件是已经通过其他用例的执行进行了设置，前置条件必须是由“主－谓－宾”构成的短语，如“用户已经登录系统”、“系统已经存在会计科目”。
最小保证
    最小保证是系统向项目相关人员作出的最低承诺，如“系统将错误信息写入系统日志”，从这个例子可以看出，最小保证也是由“主－谓－宾”短语所构成的。
成功保证
    成功保证说明了用例成功结束后项目相关人员的哪些利益得到了满足，用例可以通过执行主场景获得成功，也可以通过执行扩展场景可选路径获得成功，其格式同最小保证“主－谓－宾”形式，例如“系统保存记账凭证”。
触发事件
    触发事件指明了启动用例的事件，一般是肯定性的短语，如“总账启用后必须执行此用例进行设置”。
主成功场景
    自顶向下进行描述，这个描述包含一个容易理解的相当典型的场景，在该场景中，主执行者完成了目标，所有项目相关人员的利益都被满足，这个场景就是主成功场景，其他的成功场景和所有错误的处理，都会在主成功场景的扩展中进行描述，主成功场景包括场景编号、场景动作描述两部门，场景编号是以数字为基础的顺序编号。
主成功场景的书写规则如下：

• 使用简单的语法：“主－谓－宾”语法形式
• 明确地写出执行者
• 描述过程向前推移
• 描述执行者的意图而不是动作
• 确认”而不是“检查是否”
• 重复动作描述“循环执行步骤x到y，直到条件满足”

扩展场景
    扩展实质上是一个从主用例中被拆分的用例。扩展开始于一个与它相关的条件。它包含了一个执行步骤的序列，该序列描述了在这个条件下发生了什么。扩展以完成或放弃扩展目标作为结束。扩展是为了处理多个条件和转移，可能会遇到扩展中又包含扩展的情况。扩展分为扩展条件和处理动作描述两部分，扩展条件是指对应的主成功场景出现的不同情况，应该是一条肯定的条件短语，不能出现“如果……那么……”这种形式的语句；处理动作描述是指对扩展条件的处理。扩展同样需要进行编号，编号格式为［对应主成功场景编号］．［扩展条件编号］．［处理动作编号］，其中扩展条件编号以字母为序号，即a～z。如果处理动作只有唯一动作，其格式可以是“［扩展条件］：［处理动作］”，处理动作不唯一则必须换行编写。需求用例是子用例，并且被多处引用，但由于引用子用例的用例之间可能有不需要的成功场景，即存在特性主成功场景，此时编写子用例时，对特性的主成功场景可以写入扩展场景中，并做出相应的解释说明。
扩展场景的书写规则如下：

• 使用简单的语法：“主－谓－宾”语法形式
• 明确地写出执行者
• 描述过程根据主成功场景向前推移
• 描述执行者的意图而不是动作
• “确认”而不是“检查是否”
• 重复动作描述“循环执行步骤x到y，直到条件满足”
• 用“检测到什么”的方式来编写条件

相关信息
 解释说明
    解释说明业务词语或定义等，便于业务人员和软件设计人员理解。
 约束条件
    用例中的计算公式和约束限制等，有助于软件设计和程序设计人员进行软件设计。
 改进建议

    升级新版本时，对旧版本的改进建议，如果不存在旧版本，则可不存在此项目。

附件1 正式用例：   

用例名＜用例名应该是一个主动语态动词短语来表示的用例目标＞

描述体＜用自然语言描述需求用例，反映出主成功场景和扩展场景动作情况及业务流程，不需要详细说明，只要将无法在主成功场景或扩展场景说明的动作在此描述，还包括用例所需要的一些功能操作等＞

范    围：＜设计范围，在设计时将系统作为一个黑盒来考虑＞

级    别：＜概要、用户目标、子功能三者之一＞

主执行者：＜主执行者的角色名称或主执行者的描述＞

项目相关人员和利益：＜用例中的项目相关人员和关键利益的列表＞

       ＜相关人员＞：＜利益＞

前置条件：＜我们所希望的，周围环境已经达到的状态＞

最小保证：＜在所有退出操作前，如何保证得到必须的信息＞

成功保证：＜目标完成时环境的状态＞

触发事件：＜什么引发了用例，可能是时间事件＞

主成功场景：＜在这时写出从触发事件到目标完成以及清除的步骤＞

＜步骤编号［数字］＞＜动作描述＞

扩展：＜在这里写出扩展，每次写一个扩展，每一个扩展都指向主成功场景中的特定步骤＞

＜被改变步骤编号＞＜扩展步骤编号［字母］＞＜扩展场景发生条件描述＞

＜被改变步骤编号＞＜扩展步骤编号＞＜编号［数字］＞＜动作或子用例＞

相关信息：

n  解释说明＜解释说明业务词语或定义等＞

n  约束条件＜用例中的计算公式和约束限制等＞

n  改进建议＜升级新版本时，对旧版本的改进建议＞

说明：

1. 概要：包括多个用户目标，它有“显示相关目标的生命周期顺序”和“为低层用例提供一个目录表”的功能。

2. 用户目标：它是主执行者努力使工作得以完成的目标，或是用户使用系统的目标。

3. 子功能：指那些在实现用户目标时可能会被用到的目标。

4. 批注：必要时可以对公式、约束、名词、名词项目必须内容等编写注释说明。

5. 超链接：必要时可以对相关用例、子用例、名词解释等插入超链接。

6. 字体及颜色：对于不同内容，如功能操作、新系统用例等使用不同颜色进行区分。

7. 图表：对于较复杂的用例，可以用图例说明用例之间关系。

附件二、范例

期初资产录入用例
    系统建账后，固定资产会计必须进入固定资产系统，将建账月以前的资产卡片录入系统，实现手工账与计算机账的对接，使固定资产核算能够连续进行，并为固定资产的后续工作如工作量录入、折旧计提、折旧分摊等工作提供资产卡片基础数据。固定资产会计在操作此功能前需要保证资产类别、计量单位、存放地点、折旧方法 已经设置，因为资产卡片需要从上述用例中获取基础数据。基本功能包括增加、修改、删除等操作。

范    围：固定资产系统
级    别：用户目标
主执行者：固定资产会计
项目相关人员和利益：
    固定资产会计：资产卡片计算机管理，快速查看资产。
    系统：获取固定资产计提折旧依据。
前置条件：资产类别、计量单位、存放地点、折旧方法等基础信息已经设置。
最小保证：系统运行失败，将失败信息写入日志。
成功保证：系统保存固定资产卡片信息。
触发事件：系统建账后，固定资产会计必须将企业已有的固定资产录入系统；以后各期不需要录入，现系统未控制，新系统应有控制点。
主成功场景：
1. 固定资产会计增加操作，系统自动计算资产编号 并显示，将所有数值型数据置为0，显示用户设置默认的残值率
2. 固定资产会计输入：
—资产名称
—资产类别
—资产来源 
—计量单位
—存放地点
—所属部门
—启用日期
—是否计提
—折旧方法
3. 固定资产会计选择折旧方法为工作量法，预计工作量和已用工作量可用，而预计使用月数和已用月数不可用
4. 固定资产会计输入预计使用月数或预计工作量，系统根据折旧方法计算
—月折旧率
—月折旧额
—已提折旧 
—账面净值 
5. 固定资产会计输入已用月数或已用工作量，系统根据折旧方法计算
—月折旧率
—月折旧额
—已提折旧
—账面净值
6. 固定资产会计输入资产总额，系统根据折旧方法计算
—残值 
—月折旧额
—已提折旧
—账面净值
7. 固定资产会计输入残值率，系统根据折旧方法计算
—残值
—月折旧额
—已提折旧
—账面净值
8. 固定资产会计输入已提折旧，系统根据折旧方法计算
—账面净值
9. 系统验证通过后，保存资产卡片信息
扩展：
2.a. 系统验证启用日期大于等于当前操作日期
2.a.1. 系统告知用户，并提示用户重新输入
2.a.2. 用户重新输入，系统执行步骤2
2.a.3. 用户放弃输入，系统置为浏览状态
5.a. 系统验证已用月数大于预计使用月数
5.a.1. 系统告知用户，并提示用户重新输入
5.a.2. 用户重新输入，系统执行步骤2
5.a.3. 用户放弃输入，系统置为浏览状态
8.a. 系统验证已用工作量大于预计总工作量
8.a.1. 系统告知用户，并提示用户重新输入
8.a.2. 用户重新输入，系统执行步骤2
8.a.3. 用户放弃输入，系统置为浏览状态
9.a. 用户做修改操作，系统验证本月已经计提折旧
9.a.1. 系统告知用户，并提示用户做资产变动操作
9.b. 用户做删除操作，系统验证非本月增加
9.b.1. 系统告知用户，并提示用户做资产处置操作
相关信息：
解释说明
１． 资产来源是指企业获得资产的方式，包括：
—购置的固定资产
—自行建造的固定资产
２. 灰色表示对新系统建议
３．红色表示功能操作
约束条件
1. 已提折旧＝月折旧额＊已用月数
2. 账面净值＝资产总额－已提折旧
3. 残值＝资产总额＊残值率
改进建议
1. 本用例在期初建账后可以维护，只要有结账月，期初资产便不能录入；
2. 由于经济形式多种多样，对于资产的增加和减少无法预知未来会有其他什么样的增加或减少方式，所以建议将资产来源和资产减少方式以编码方式进行维护，以适应经济的发展；
3. 扩展2.b~2.f为建议扩展。