您的位置：程序门 -> 软件工程/管理 -> 开发过程版



usecase分支流如何写比较好？


[收藏此页] [打印本页]选择字色：背景色：字体：[大][中][小]


usecase分支流如何写比较好？[已结贴,结贴人:asj]
发表于：2007-03-29 16:35:53 楼主
自以为对usecase有些了解了，实际写起来发现还是有疑惑。
开始比较容易，按照理解写出主序列，列出可能分支：
主序列
1，用户选择致电客户
2，系统显示客户电话号码，记录起始时间……
3，用户拨打电话，与客户交流
4，用户录入交流结果
5，系统记录，结束
分支
3a，电话空号

到与用户交流后，细化分支的时候，碰到问题了。要不要起一个分支事件流？如果不起，写出来是这样：

3a，电话空号。用户致电客户相关联系人来获得客户联系方式，如果还不
能联系上。联系这个客户的销售经理，由销售经理协助联系。

这样的优点是比较易懂，阅读时不干扰主流程。缺点是不够细化，可能遗漏，比如系统需要提供什么信息给用户，是否要记录过程。
如果写成分支流，可能是这样：
3a，电话空号
3a1，用户查看客户联系人信息
3a2，系统显示联系人电话
3a3，用户致电联系人，了解能够联系到客户的号码
3a4，用户录入与联系人沟通结果，客户新号码
3a5，系统记录沟通结果，更新客户号码。主流程继续
分支的分支
3a3a，联系人电话空号
3a3a1，用户查看客户销售经理信息
3a3a2，系统显示销售经理信息
3a3a3，用户联系销售经理，与客户获得联系
3a3a4，用户录入与销售经理联系情况
3a3a5，系统记录联系结果，主流程继续

这样是不是又太繁琐呢？其实在第二层分支后还有分支，也就是3a3a3a，销售经理仍然无法联系客户。这样一个两次判断的简单流程都写成这样，只怕最后用户完全看不下去了。
是否我犯了什么错误？分支流下面不能有分支么？

另外，主流程中的其他分支可能也会走相同的流程，如电话无人接听，连续5天更换不同时间都不能联系，后面流程就一样了。显然每个分支里面如果都这样写一遍更加冗长了。是不是该把这个分支流程作为一个用例分离出来呢？对于这个的疑惑是，如果它是一个usecase，它却永远都是从上面第一个usecase中才会被使用到，而且也只有这一个usecase使用。似乎并没有独立性。

另外，今天才发现csdn原来没有需求板块。
发表于：2007-03-29 17:17:301楼 得分:0
你去看看我那本书吧，书上对于用力的分支流/子流如何写，以及应该写多大，都给了一个我的经验方法。
书名：软件工程之全程建模实现
发表于：2007-03-29 17:21:522楼 得分:0
嘿嘿，谢谢青润老大
我现在在外地项目出差，买书不太方便，不知道有没有关于这个的节选让我先了解一下。
再顿首
发表于：2007-03-30 08:09:513楼 得分:100
我给你贴一点，但是更多的我也不好帖，怕出版社那边不满意，你可以找来看看，也不一定要买。
下面是书上关于用例阐述的前两个问题的解答：
1.5.8 常见的问题
下面描述的是在use   case阐述中经常出现的问题，也是笔者在工作中经常解释的问题。这里列在下面供大家参考：
问题一、use   case阐述到什么程度才是足够的，如何判定？
本书建议：
use   case阐述层次不要超过四层！
不要让use   case阐述超过四层，如果出现了，那么您需要考虑两个方面的问题，第一个问题：
① use   case的阐述是否过于冗长，语言是否精炼，描述是否准确；
如果您经过分析认为您的描述已经相当准确，没有冗余存在，那么您需要考虑的就是下面这个问题：
② 这个use   case是否需要拆分；
不超过四层也就是说，只能进行如下的描述：
主流子流分支流子分支流
如果发现在子分支流下还需要继续划分下级分支，那就一定是出现了上面两个原因中的一种。
声明：
这个说法目前只对mis系统有效，笔者目前还没有在其他的系统中进行过实践，所以这里不能对其他系统做任何结论。
问题二、use   case阐述的用词和语言怎样才合适？
use   case阐述的用词要准确，不能含糊其词，所有的词语都要精确，语言要精炼。图表1.27是某个use   case阐述中描述保存失败的语言：
1.2.2.1.1   保存失败
- 如果系统检测到必须填写的内容不完整，提示用户“数据录入不完整”   ，用户确认后，系统返回保存前的状态，用户重新输入正确的数据；
图表   1.27 一个实际use   case阐述的片段
这段描述就有一些问题，它没有明确的写明哪些内容是必填内容，因为这些应该是在需求调研过程中已经获取到的信息，如果没有获取到，在这里就应该找用户进行确认这些必要的信息。
另外，在进行use   case阐述的时候，不要这样写：提示用户“数据录入不完整”——因为这样的书写，会限制交互建模开发人员进行界面设计时的思路，应该写成：提示用户数据录入不完整。
按照惯例，被引号括起来的内容是属于固定不变的内容，而界面设计人员也许会认为：“您的数据信息录入不完整”，这样的描述会更贴切一些，而认为“数据录入不完整”过于生硬。当然，这里只是一个用词的问题。
对于上面的例子，本书建议的描述请参看图表1.28。
1.2.2.1.1   保存失败
- 如果系统检测到该页面上必须填写的内容填写不完整，应该提示用户数据录入不完整   ，用户认可后，系统返回保存前的状态，用户可以重新输入/修改数据；
必须填写的内容：包括名称、类别、项目编号和起始日期。
图表   1.28 建议对该片段修改后的描述
后面还应该注明类别有哪些，项目编号的格式和定义，起始日期的格式。因为这些可能属于在所有的use   case阐述中都需要引用的内容，所以，也可以将它们放入到词汇表中，对它们的解释进行统一管理。
对于类似“提示用户‘数据录入不完整'”这样的用语，应该在交互建模中进行实现，关于交互建模的内容，请参看第1章第6节的内容。
这里的例子因为是一个经常出错的例子，其流程过程非常简单，一句话即可明白该句所描述的流程顺序，因此可以看做是没有流程的，而采用这种方式进行描述。当遇到比较复杂的出错处理的例子时，在这里也要按照正常的结构（如同use   case主流那样的结构）进行描述。
注意：
这里有一个描述的度的问题，如果描述得不好，就会因写得过于详细，而影响到后面界面设计人员的思路，使他们的设计受限于您在use   case阐述中的描述而无法形成更有竞争力、更美观实用的界面形态，详情请查看第1章第7节的内容。而过于简单，就会出现如图表1.27中的现象使得需求无法得到更准确的描述，使得用户的一些关键性要求被忽略。
发表于：2007-03-30 08:57:254楼 得分:0
我个人习惯的格式是保证主流程的阅读顺畅，如果遇到异常流，就在主流程理写明如遇到xx情况，请转异常流1。

相关文章
其他资讯

快速检索
分类导航标签a

最新资讯
热门点击