如何阐述用例——基于Rose的全程建模实例之三

[青润]

这段文字是在我的文章《基于Rose的全程建模实例之三》中的一段，现在拿出来让大家批评批评！

下面是如何阐述用例部分的内容，大家觉得这段文字有没有什么没有解决的问题，还需要什么说明？

2.4 如何阐述用例
2.4.1 目的
用例阐述是为了通过语言来描述用户的实际需求。这是对用例进行分析的第一个步骤，也就是进入需求分析的第一步。
完成用例阐述的用例，就可以开始交互建模（为界面建模做准备）的工作了，接着是分析模型的开发。
2.4.2 基本要求
用例阐述的基本要求如下：
① 简明扼要的描述出该用例的具体工作流程；
② 用词要准确，不能有模糊性的词语；
③ 对于一些还没有调研清楚的过程，可以临时通过注释的方式来表述，以便于今后的修改；
④ 对于提交进行审核的用例阐述不能继续保留注释的内容，否则，就只能说明这个用例阐述仍然没有开发完成；
用例阐述的描述要一句描述操作者的操作，一句描述系统的响应。
先排列用例阐述的基本要求（包括RUP中的阐述），然后对它们进行解释。
2.4.3 用例阐述的模版
2.4.3.1 关于模版的说明
这一小节将对用例阐述中使用的模板进行诠释，有利于大家对用例阐述中需要填写的内容的理解，后面将在2.4.4中举一个实际的例子进行说明。
下面的模版，是笔者根据项目的特点，对RUP中的用例阐述模版进行修改后在公司的实际项目中使用的，这里仅仅作为推荐，因为不同的项目会有不同的特点，笔者不认为一个模版就可以通用所有的项目，这是需要根据开发团队的特点和项目的特征进行修改，否则，就可能会出现一些问题。
当然，如果你的项目中使用用例仅仅是一个理解需求的过程，对后面没有太大的影响，比如说：在项目的设计过程中的需求变动，你们的项目仅仅是直接修改设计或者编码，而不再从需求文档开始的话，那么，你就可以使用这样一个通用的模版，而不进行什么细节的调整。
2.4.3.2 用例阐述的格式
下面是笔者使用的用例阐述的模版，放在这里供大家参考：

2.4.4 参与人员建议
2.4.4.1 主要开发人员
行业专家、业务建模人员、用例阐述人员、美工（一位，最好是需求调研人员中有人具有美工的基本知识）
注意：一般来说业务建模人员和用例阐述人员是同一组人。
2.4.4.2 主要评审人员
用户代表、用户、行业专家、项目经理、设计实现人员
注意：一般来说用例阐述人员和设计实现人员可能是同一组人，如果是，那么评审人员中的这部分角色应该有相应能力的开发人员来承担。
2.4.5 例子
例2.4.4.1是笔者自己写过的一个实际的用例阐述的例子：
1. Manage ContractPayment
中文名称：合同付款管理。
合同付款管理包括**合同、**合同、**合同、**合同、**合同、**合同的付款管理。
1.1 简要说明
下面将对合同付款管理的流程进行统一的描述，这包括合同的创建、修改、查询和删除，然后将在附加说明中阐述各个合同的特殊性和需要说明的点。
1.2 事件流
1.2.1 基本流
操作者希望进行合同付款管理的时候启动此用例：
1. 操作者选择合同付款选项；
2. 系统显示操作者可以进行付款的合同列表；
3. 操作者选择要付款的合同；
4. 系统显示其基本信息及付款信息，并根据需要提示该合同的其他明细信息；
5. 根据用户的选择执行如下相应的操作：
- 用户选择付款操作，系统执行合同付款子流；
- 用户选择添加付款明细操作，系统执行合同付款明细添加子流；
- 用户选择修改付款明细操作，系统执行合同付款明细修改子流；
- 用户选择删除付款明细操作，系统执行合同付款明细删除子流；
6. 当用户选择其他操作时，系统结束此用例。
1.2.1.1 合同付款子流
1. 系统显示合同可付款明细和付款明细状态；
2. 根据合同的类型，用户可能进行下面两种操作：
- 非零星购置类合同，用户将输入付款信息，并确认操作；
- 零星购置类合同，用户将在付款列表中选中一条付款信息，并确认付款；
- 用户不做选择，则系统返回基本流步骤6；
3. 系统自动将本期合同付款金额数按照每条明细单项工程的应付金额在该合同的所有明细项目的金额总和中所占的比例进行分配。
4. 系统返回步骤1。
1.2.1.2 合同付款明细添加子流
1. 系统显示合同付款明细输入界面；
2. 用户可能进行下面两种操作：
- 用户选择返回，则执行步骤4；
- 输入付款信息，并确认操作；
3. 系统保存用户输入的信息，并返回步骤1。
4. 系统返回基本流步骤6。
1.2.1.3 合同付款明细修改子流
1. 系统显示合同付款明细界面；
2. 用户可能进行下面两种操作：
- 用户选择返回，则执行步骤6；
- 用户选择某条付款信息，并确认操作；
3. 系统显示该付款信息修改界面；
4. 用户修改付款信息并确认保存；
5. 系统保存用户输入的信息，并返回步骤1。
6. 系统返回基本流步骤6。
1.2.1.4 合同付款明细删除子流
1. 系统显示合同付款明细删除界面；
2. 用户可能进行下面两种操作：
- 用户选择返回，则执行步骤4；
- 用户选择要删除的付款明细，并确认操作；
3. 系统删除用户选择的付款信息，并返回步骤1。
4. 系统返回基本流步骤6。
1.2.2 备选流
1.2.2.1 备选流一
1. 如果新建付款失败，系统提示用户合同付款失败，请用户与管理员联系；
2. 用户确认后系统退回到付款前的状态；
1.2.2.2 备选流二
1. 如果付款信息已经通过审核，用户再试图编辑或者删除该付款信息时，系统提示用户该付款信息已经通过审核，用户不能进行修改或者删除操作；
2. 用户确认后退出用例流程。
1.3 特殊需求
1.3.1 第一特殊需求
付款金额只能输入数字和小数点，不允许输入其它字符。
1.4 前置条件
1.4.1 前置条件一
用户必须登录系统，通过身份验证后才能进行本用例操作。
1.4.2 前置条件二
该用户有权限进行付款操作。
1.4.3 前置条件三
经过合同审核流程才可以进入合同付款管理流程。
1.5 后置条件
合同付款添加后必须进入合同付款审核流程。
1.6 扩展点
没有与此相关的内容。
1.7 附加说明
没有与此相关的内容。
例2.4.4.1 一个笔者撰写的用例阐述的例子
注：为了避讳一些内容，在例2.4.4.1中笔者删除了一些行业相关内容，删除的内容并不影响用例阐述的整体表述。
要注意：这里阐述的每一步都要在分析模型中展现出来，所以，一定要求描述准确，语言精炼，层次顺序要明晰。
2.4.6 常见的问题
下面描述的是在用例阐述中经常出现的问题，也是笔者在工作中经常解释的问题。这里列在下面供大家参考：
2.4.6.1 不要超过四层
不要让用例阐述超过四层分支，如果出现了，那么你要考虑两个方面的问题：
一、 你对用例的阐述是否过于冗长，没有达到语言精炼，描述准确的要求；
如果你认为你的描述相当准确，没有冗余存在，那么你需要考虑下面这个问题：
二、 你的用例是否需要拆分；
不超过四层也就是说，只能进行如下的拆分：
主流->子流->分支流->子分支流
如果你发现在子分支流下还需要继续划分下级分支，那就一定是出现了上面两个原因中的一种。
声明：这个说法目前只对MIS系统有效，笔者目前还没有在其他的系统中进行过实践，所以这里不能对其他系统做任何结论。
2.4.6.2 用例阐述的用词和语言
用例阐述的用词要准确，不能含糊其词，所有的用词都要精确，例2.4.5.2.1是某个用例阐述中描述保存失败的语言：
1.2.2.1.1 保存失败
- 如果系统检测到必须填写的内容不完整，提示用户“数据录入不完整” ，用户确认后，系统返回保存前的状态，用户重新输入正确的数据；
例2.4.5.2.1 一个实际用例阐述的片段
上面这段描述中就有一些问题，它没有明确的写明哪些内容是必填内容，因为这些应该是在需求调研过程中已经获取到的信息，如果没有获取到，在这里就应该找用户进行确认这些必要的信息。
另外，在进行用例阐述的时候，不要这样写：提示用户“数据录入不完整”——因为这样的书写，会限制界面设计人员进行界面设计时的思路，应该写成：提示用户数据录入不完整。按照惯例，被引号括起来的内容是属于固定不变的内容，而界面设计人员也许会认为：“您的数据信息录入不完整”，这样的描述会更贴切一些，而认为“数据录入不完整”过于生硬。所以，这里就是一个用词的问题了。
对于上面的例子，笔者建议的描述请看例2.4.5.2.2。
1.2.2.1.1 保存失败
- 如果系统检测到该页面上必须填写的内容填写不完整，应该提示用户数据录入不完整 ，用户认可后，系统返回保存前的状态，用户可以重新输入/修改数据；
必须填写的内容：包括名称、类别、项目编号和起始日期。
例2.4.5.2.2 笔者建议的对该片段修改后的描述
后面还应该注明类别有哪些类别，项目编号的格式和定义，起始日期的格式。因为这些可能属于在所有的用例阐述中都存在的，所以，可以将它们放入到词汇表中，对它们进行统一管理下的解释。
对于类似“提示用户‘数据录入不完整’”这样的用语，应该在交互建模中进行实现，关于交互建模的内容，请参看“2.5如何进行交互建模”这一节的内容。
注意：这里有一个描述的度的问题，如果描述不好，就会写得过于详细，请看例2.4.5.2.3。过于详细，就会影响到后面界面设计人员的思路，使他们的设计受限于你在用例阐述中的描述而无法形成更有竞争力更美观实用的界面。而过于简单，就会出现如例2.4.5.2.1中的现象使得需求无法得到更准确的描述，使得用户的要求被忽略。

[青润]

是需要单独的文档来阐述的。
因为这部分工作后期是需要界面设计人员参与的，所以，不一定所有的都只能在ROSE中使用。

[wltsui]

楼主：界面设计人员也可以看rose 模型呀，这样不是又要维护一份word文档吗？

[wltsui]

mark...

[yestoall]

乱说一下，对用例阐述的要求包括：
1、只记录“可观测”的；
2、使用主动语句；
3、以参与者或系统作为主语；
4、关注业务逻辑的处理；
5、不要涉及界面细节。

大家不要骂我。

[青润]

to yestoall:
在阐述的时候，每一句话都是要经过斟酌的。
每一条要求也都应该有针对阐述中具体的某一段。
因为这样的过程是非常格式化的，而不是一个自由发挥的空间，在格式限定的范围内描述你的业务实现过程才可能是合理的。
你的第2条，我知道是针对用户操作行为的，当然是主动与句。
你的第3条在我上面的描述重视有对应内容的。
你的第4条就是需要描述的内容，也就是业务逻辑的相关处理。
你的第5条很实际，不过我也做了相应的描述，因为界面细节应该在交互建模中进行阐述，文中有：“注意：这里有一个描述的度的问题，如果描述不好，就会写得过于详细，请看例2.4.5.2.3。过于详细，就会影响到后面界面设计人员的思路，使他们的设计受限于你在用例阐述中的描述而无法形成更有竞争力更美观实用的界面。而过于简单，就会出现如例2.4.5.2.1中的现象使得需求无法得到更准确的描述，使得用户的要求被忽略。”

而第1条相对无法确定，不知道你想要表达的是什么意思？还望指教！

[zgpp]

请问楼主用例阐述是该在rose里写，还是要单独的文档来阐述？
谢谢您！

[mach]

to qingrun
为什么不考虑在use case的document中阐述用例呢？如果要给UI开发人员看，可以用SoDa生成文档。
采用附加文档当然也是可行的，但是要同步维护rose模型中的用例和另外一个文档中的用例阐述也是一件麻烦的事。
另外其实是否要把用例阐述得如此具体也是一个需要具体案例具体分析的事情，不是一定都要达到如此的精确程度的。

[青润]

to mach：
mach兄，在use case的document中阐述用例的问题，我也思考过。
不过，use case的document的功能实在太弱小了，用她做一些注释性的说明还可以，用于描述比较复杂的用例中表现的业务关系和流程就实在是太困难了。后来，也就不得不放弃了。至少2002中还不可以，2003刚刚下载到，估计rational公司毕竟不是做文本编辑工具的公司，所以，可能性还是不大，否则，就没有必要制造soda这么一个工具了。
另外，soda工具的使用的确比较困难，用它来定义模板的时候，选择的窗口太小，而且操作非常的不容易识别，所以，我现在用得也不是很好，只能说生成一些说明性文档，而很复杂的定义方式还比较困难。不知道国内有没有用的比较好的人？至少csdn上还没有遇到。

如果说到用例阐述，我觉得：如果你的项目只有五六十万，那也就没有必要这么做了。这样详细的阐述需要一定的人力和时间的投入，还需要详尽的调研过程和结果，我个人觉得：至少你的项目周期要在三个月以上，项目的合同开发金额要在五十万以上，这样做才值得。否则的话，可能……呵呵，我就不说了。
当然，如果说这个项目你们打算做二期和三期的开发的话，我也建议：要阐述的这么详细，否则就失去意义了。对于今后的开发反而会成为鸡肋！

不知道这样的解释合理么？欢迎大家来批评指教！

[青润]

哦，不好意思，刚才漏掉了一个问题：
“采用附加文档当然也是可行的，但是要同步维护rose模型中的用例和另外一个文档中的用例阐述也是一件麻烦的事。”
——这个问题，其实我在我的第一篇文章中已经作了描述。rose中可以直接插入文档的连接（最好与配置管理工具协同使用）。这样就可以很方便的进行后续的工作了。
因为你在开发分析模型和设计模型的时候，是必须要参考你的用例阐述的，所以，这样链接进来也有利于工作的开展。修改和补充都可以让设计人员直接看到结果。
这样的用法是很方便的。

[mach]

to qingrun
在rose中插入文档连接的方法我也用过。其实用例阐述放在word文档里，还是rose模型里，倒不是什么大问题，两种方法我都尝试过。
至于用例阐述的精确程度，的确如你所言，是否要有完备周密的用例阐述要看项目的规模、性质以及对需求/业务的了解程度而定，如果时间允许（不过通常时间都是不充裕的：）），用例阐述的越完备越好。
总之你的文章写得不错，期待你的下文。

[mach]

补充一点，这里只是说了如何来阐述一个用例，但是更重要的是如何来确定系统范围、如何找出真正需要的用例、以及如何确定用例的粒度？

[青润]

to mach
谢谢夸奖。也同意你的观点。

对，你说得很对，关于这部分的描述，在这一节的前面几节中，还有关于系统范围的确定和用例粒度确定的内容，也就是需求范围的确定和用例的查找。

我会找个时间把相关的内容贴出来让大家批评一下的。

btw:这里无法贴图，是个很大的问题，我在文中使用了很多图和表格来描述问题。那些相关内容看来只有通过程序员杂志来正式发布了。

[yestoall]

to qingrun:
举个例子说明第一点：
错误的说法：系统通过odbc建立数据库连接，传送sql查询语句，从“图书”表查询......
正确的说法：系统按照查询条件搜索图书。

我所说的是对写用例阐述的主观要求，并不是提什么意见。呵呵
我很有兴趣拜读你的文章，可以寄给我分享吗？

[青润]

to wltsui:
界面设计人员不看rose模型的。也不需要他们能看懂rose模型。在我上面的描述中，也没有这样的说明呀？

[青润]

to yestoall：
我已经一段一段的贴在这里了，正在征询意见，很欢迎你的参加，但是，我不想公开的部分，目前还不便于公开。还望理解。

[yestoall]

to qingrun：
等着你一次性贴全的好消息。