Java开发网 - [转帖]用例应该分多细 (from umlchina)

Java开发网

您没有登录

» Java开发网 » Design Pattern & UML

打印话题 寄给朋友 订阅主题

作者

[转帖]用例应该分多细 (from umlchina)

yj780210

发贴: 442
积分: 70

于 2003-01-15 09:12

作者内容
nextar 用例应该分多细？（我的一些个人看法，请指正）
--------------------------------------------------------------------------------
用例的划分粒度一直是大家所关注的一个话题，下面就我个人的经验提一些想法：

我一般会在两个层次上对用例进行划分：
一个层次是从驱动开发的角度：在这个层次描述的用例是比较粗的，一般是对应到一个完整的功能模块，通过实现这样一个用例所描述的功能来帮助最终用户完成一个完整的业务活动。

第二个层次是从详细说明需求的角度：在这个层次描述的用例比较细，一般是第一层用例的子用例（include），只是描述一个完整功能模块中的一项功能操作，当然它必须满足用例的定义。

通过这两个层次的用例的组合，一般的需求都可以比较清楚地描述了，用例粒度的问题也就不存在了，大家各取所需。
03/01/03 10:26 酷帖！臭帖！回复
酷帖评价：臭帖评价：
返回页首

SimonQiu 回复: 用例应该分多细？（我的一些个人看法，请指正）

--------------------------------------------------------------------------------
你提到了第二个层次的用例，我觉得不是很对。用例实际上是一个过程，他由若干事件组成，每个事件实际上就是系统需要完成的操作。如果按照你说的“只是描述一个完整功能模块中的一项功能操作”，那恐怕是太细了，想一想如果把所有的事件都作为一个用例来描述，那一个复杂的系统将会有多少个用例出现。所以我认为你说的第二层用例的概念不是很正确，其实可以对每个操作用一个契约说明或画一个活动图来描述就可以了。

至于用例的粒度，我觉得在刚刚开始一个系统分析的时候，应该画高层用例，或者说就是比较粗的用例，原因其实也很简单，因为你对这个新的系统还很不了解，所以你不可能一上来就能够画出很详细，很准确的用例图来。但随着每次迭代的过程，每个高层用例被一个一个的细化，这时可能一个高层用例又要分成几个小的用例来说明，直到最后，在真实用例中可能连用户界面都要进行说明的。

以上是我的个人看法，希望可以和大家一起交流讨论！
03/01/03 17:53 酷帖！臭帖！回复
酷帖评价：臭帖评价：
返回页首

nextar 我觉得用例多不是问题，但是用例如果没有组织好才是真正问题

--------------------------------------------------------------------------------
其实按照uml的定义“用例是由系统完成的一组动作的描述，它产生对特定参与者有价值的结果”，用户的一个简单的操作（不是系统内部的动作，这两者是有区别的）是可以作为一个用例的。
在我这种描述方式下，用例可能相对较多，但每个用例规约内容相对较少。
如果按照你这种方式，则用例相对较少，但每个用例规约则比较复杂。
这就可能要根据实际情况来取舍了。

我们在划分比较粗的用例的时候，划分标准是这个用例足以驱动一次迭代，在这个迭代完成之后，这个用例所描述的功能是否有效，有效的标准就是用户能完整地完成相关业务处理（就好像一个管理用户的用例，必须添加，删除，修改齐全），而不只是做其中部分事，与客户界定需求范围一般也是以这种用例为主。
03/01/03 19:09 酷帖！臭帖！回复
酷帖评价：臭帖评价：
返回页首

SimonQiu 回复: 我觉得用例多不是问题，但是用例如果没有组织好才是真正问题

--------------------------------------------------------------------------------
恩，我似乎能够明白你的意思，但如果你能举一个简单的例子来说明的话就更好了！！！

如果看你的下面这段说明：
“我们在划分比较粗的用例的时候，划分标准是这个用例足以驱动一次迭代，在这个迭代完成之后，这个用例所描述的功能是否有效，有效的标准就是用户能完整地完成相关业务处理（就好像一个管理用户的用例，必须添加，删除，修改齐全），而不只是做其中部分事，与客户界定需求范围一般也是以这种用例为主。 ”

我的理解是，你说的第一层用例是“用户管理用例”，而第二层用例是“新增用户”，“修改用户”，“删除用户”。不知是否理解的对。

如果是这样的话，那我们的思路是一样，只是在说法上有些出入。

对于用例驱动迭代的问题，我认为不一定一定要在一次迭代中全部完成用户管理用例的，这个要看迭代周期的长短，以及所开发模块的难易程度了，所以我认为迭代的标准应该以上面提到的新增用户，修改用户，删除用户为驱动，至少这样更合理一些。实际上上面提到的任何一个小的功能实现了，都可以认为是系统的一个演进的。
03/01/03 19:18 酷帖！臭帖！回复
酷帖评价：臭帖评价：
返回页首

billiondelly 你这样做陷入了功能分解的误区了，是不符合用例的出发点的，用例是用来捕获系统需求的，是用户的角度来看的，高焕堂先生甚至认为用例不是OOA的部分，更遑论你这样为了设计的目的分解成模块了

--------------------------------------------------------------------------------

03/01/03 20:33 酷帖！臭帖！回复
酷帖评价：臭帖评价：
返回页首

babituo 业务用例"见好就收",系统用例"打破沙锅问到底"

--------------------------------------------------------------------------------
所谓"见好就收"我已经讲过,查我以前的帖子就知道.
所谓"打破沙锅问到底",就是做到越细越好.
好多人看到越细越好一定会表示反对,许多大师不是一再强调过多的用例是一种错误吗?
请别忙,我所说的越细越好是有条件的.
系统用例讲究的是系统用户和系统发生交互的界面(请注意,不是图形用户界面).而是用户有可能和系统发生交互操作的逻辑层面.我们讨论系统用例,一定不能跨越这个层面,深入到系统内部的处理过程.这是一条最基本的原则.
遵守了这条原则,我们就可以来设想:假设系统完成后,已经交付给用户手中,那么,此时用户对系统所能进行的每一个细小的操作,是不是一定已经在程序代码中实现了呢?当然是的,否则,用户用什么?那么,我们的程序员是怎么开发出来这些每一个细小的操作界面的呢?如果当初的系统用例模型没有把每一个细小的,用户进行的交互界面说清楚,我们的设计员和程序员不就只能凭空添加这些交互特性了吗?或者,在设计实现中,不就得被迫产生需求变更吗?
我曾经用"找门"来比喻查找用例,就是说,您把系统当作一个大厦或一群大厦,用户是将来出入大厦的人,用例就是从进入大厦到达到大厦的每一个房间的一道道门,如果你进入一道房间,房间中已经不在有门通向更深的房间,只看到抽屉门,柜子门,你不可能再走进这些门去探究,也探究不到什么东西了,抽屉和柜子里的操作已经不再神秘,你很清楚每个抽屉和柜子是做什么用的,你才不用把这些抽屉门和柜子门建为用例,这就到底了.
也许有朋友会说,别吹了,可能吗?一开始用例模型有可能做到那么细吗?
当然不可能,一座大厦的所有的门一开始你也不是一下就能找到,找到了一时半会您也不一定进得去,非要愚公移山的啃硬骨头,碰钉子吗?当然不要那么傻,你已经尽力了,而且你已经对需求变更的风险源有所掌握,尽可策马前行了.
所以系统用例做多细才好,更多时候取决于你能做多细。一些做测试的人说：从来就没有出现过甚至听说过测试过度导致项目失败的，我也说：似乎我也没有听说过因为对用户行为分析过度导致项目失败的事例，反倒是大量项目失败的原因是因为对用户行为分析过粗。
有的朋友还说：用例太多了不好组织，给人信息太多，容易陷入迷途。这已经不是用例粒度的问题了，而是用例组织的问题了。

03/01/04 16:59 酷帖！臭帖！回复
酷帖评价：臭帖评价：
返回页首

laoyuan 回复: 我觉得用例多不是问题，但是用例如果没有组织好才是真正问题

--------------------------------------------------------------------------------
我完全同意上面二位说的，用例的粒度我觉得只有这样算来才有一定的可操作性，并且概念也清晰，还有对于一些大的、独立的功能模块我倒倾向于用包来定义，比如我把“用户管理”定义为“用户管理子系统”的子系统包，里面再进一步设置粗细不同的若干用例。但是我有一点不太同意SimonQiu说的详细的甚至要对用户界面来进行说明，我觉得这大可不必，除非这个界面是有非常特殊的要求需要在需求中明确的，否则我觉得是没有必要的！
不知各位以为如何？
03/01/04 17:38 酷帖！臭帖！回复
酷帖评价：臭帖评价：
返回页首

wu_hao FYI: Managing Use-Case Details（及译文）节选

--------------------------------------------------------------------------------
下文选自PMT合作翻译作品（http://www.pmtsolution.net）
译文尚未全文发布，敬请等候。

Managing Use-Case Details
应对用例细节

Kurt Bittner 原作
何伟译

Details, details! System designers seem to have a general fear of details when writing use cases, perhaps driven by the worry that clarity, the hallmark of a good use case, will be lost in a blizzard of details if they are not careful. Although this fear has some foundation in reality, unfortunately the typical response -- to omit all details from the use-case description -- results in use cases that lack specificity and real value.

细节，细节！系统设计员在编写用例的时候，好像普遍都会有一种害怕细节的心理，这多半是由于担心引起的。清晰无误是用例的首要要求，而如果不仔细的话，用例的清晰无误将会在诸多的细节中荡然无存。这种担心当然是有一定的现实原因的，但不幸的是，它带来的典型反应是——忽略所有用例描述中的细节——从而导致用例缺乏针对性和实用价值。

As the old saying goes, "The devil is in the details," meaning that most of the real problems become apparent only when you get down to specifics. If we are to write effective use cases, then we must present details. So how can we overcome our fears about them?

有一句古老的谚语，“细节是罪魁祸首”，意思是说，绝大多数的真正问题都是在你开始认真考虑事物的特性以后出现的。但是，当我们想要编写有效的用例时，我们又必须表述细节。那么，我们该如何克服害怕细节的心理呢？

The best strategy is to plunge ahead. All the details will be needed at some point, and you can move them to other artifacts later on. As Franklin Roosevelt said, "We have nothing to fear but fear itself." Sometimes fear of detail is just procrastination in disguise: We worry about documenting a behavior with too much detail before we even start writing anything and then find ourselves unable to get started. Instead, try to put aside your fears and dig into the specifics of the required behavior to describe exactly what the system will do. If you do not provide enough detail, then there is a real possibility of failure: The development team will have to re-discover the requirements even after they read your use-case description. You will have wasted everyone's time, including your own.

你能采取的最好策略就是“一头扎入细节”。所有的细节总在某个时候会被需要，而你也总能拖延到后续的工作中去。正如富兰克林·罗斯福所说：“我们没有什么好害怕的，除了害怕本身。” 有些时候，害怕细节只是为了掩饰拖延时间：甚至在我们开始编写任何东西之前，我们已经在担心怎样才能把有这么多细节的系统行为文档化，然后发现自己根本无从开始。相反的，试着撇开这些担心，并深入到那些所需的系统行为的细节中，从而可以确切的描述系统功能。如果你不能提供足够的细节，那反而真有失败的可能：开发组即使阅读了你的用例描述，还是不得不重新探明需求。这样会浪费每个人的时间，包括你自己的。

This article discusses use-case flow description and presents several strategies for managing details in these descriptions, including using glossaries and domain models, plus representing complex business rules and other special requirements. En route, a number of examples are used to illustrate various aspects of the problem. So without further introduction, let's get started.

本文主要讨论用例流程的描述，并为处理这些描述的细节提供几种好的策略，包括使用术语表和领域模型，外加复杂业务规范的描述和其他特殊需求。本文将会用一些例子来说明问题的各个方面。好，不多介绍了，让我们开始。

03/01/04 18:06 酷帖！臭帖！回复
酷帖评价：臭帖评价：
返回页首

SimonQiu 回复: 我觉得用例多不是问题，但是用例如果没有组织好才是真正问题

--------------------------------------------------------------------------------
恩，赞同你用包来表示一个大的功能模块的做法，我在实际工作中，也是采用的这种方式。

但对你提出的关于是否画界面的不同意见，我还想再说两句：我说绘制用户界面应该说不是在前期的系统概要分析阶段进行的工作，而是再某个迭代过程中可能需要完成的工作，因为一个拥有可视化界面的软件，我想应该在该模块正式开发前，做出一个原型，以便于获得用户的确认，否则我们可能会出现在开发完成后出现返工的现象，当然界面的变动一般情况下不会对我们的项目造成什么阻碍，但界面引起我程序大的改变的先例应该也不是没有的。所以我觉得如果我们开发具有可视化界面的应用时，必要时还是应该绘制出相应的界面，如此，能够更好的保证我们系统的实现。
03/01/04 18:45 酷帖！臭帖！回复
酷帖评价：臭帖评价：
返回页首

nextar 我曾经得到一个建议：用用例来描述面向用户的功能性的需求。

--------------------------------------------------------------------------------
因此在大部分的情况下，我都是根据用户所看到的功能来划分用例。对于那些用户/外部接口很少的系统，是没什么必要通过用例来描述系统需求的（完整地说明在《软件需求管理-统一方法》p154）。
对于用例是否ooa的部分，现在应该已经有了基本统一的认识，这里就不多说了。
03/01/06 10:55 酷帖！臭帖！回复
酷帖评价：臭帖评价：
返回页首

nextar 回复: 我觉得用例多不是问题，但是用例如果没有组织好才是真正问题

--------------------------------------------------------------------------------
没错，我们的理解基本一致，例子嘛...我实在比较懒，呵呵，以后改进。
不过在进行每一次迭代（可以认为是一个子项目）之后，我觉得应该提交给用户在某个功能模块的完整有效的功能，而不是一个半成品，这样才有可能对此次迭代的成果进行评估。
03/01/06 11:35 酷帖！臭帖！回复
酷帖评价：臭帖评价：
返回页首

bbsjcn 回复: 我觉得用例多不是问题，但是用例如果没有组织好才是真正问题

--------------------------------------------------------------------------------
看了几位的讨论，感觉获益颇多，确实，我们需要一个可操作性的东西来指导我们将理论知识转化为自己的经验，尤其是SmionQiu老弟的做法，我比较赞同，有时候，图形界面更能说明问题，它能避免我们走太多的弯路，只是说到用例的多少问题，我觉得对于一个应用系统来说，当然理想的情况是最终的用例集能够尽可能的细一些，因为用例越细，就说明你在分析和设计阶段做的工作越到位，对应用系统的需求理解的也越清楚，不过用例划分的越细，如果没有好的用例管理办法和操作习惯，我们分析和设计人员最终驾御这套用例的难度也许会越来越大，因为最后你也许发现它是一团乱麻，不知道你们是否有好的管理用例的方法和习惯，不妨说出来让大家也分享一下，希望以后能多看到这样一些有价值的帖子。
03/01/06 11:37 酷帖！臭帖！回复
酷帖评价：臭帖评价：
返回页首

billiondelly 描述功能不等于功能分解，<RUP>中明确提到了要“避免功能分解”，（我拷在这里了），另外，你说用例是不是OOA有统一定论，那么请“不厌其烦”地告诉我们这些新手定论是什么，并为什么，谢谢

--------------------------------------------------------------------------------

03/01/06 14:10 酷帖！臭帖！回复
酷帖评价：臭帖评价：
返回页首

billiondelly 前面忘拷了，这里补上RUP中的段落

--------------------------------------------------------------------------------
避免功能分解
用例模型退化导致系统功能分解的情况并不罕见。为避免发生这种情况，必须注意以下故障现象：

“小”用例，即对事件流的说明只有一个或少数几个句子。
“许多”用例，即用例的数量有好几百，而不是好几十。
用例名的构造类似于“根据这一特定数据执行本操作”或“利用这一数据执行本功能”等。例如，“在 ATM 机上输入个人识别号”不应建模为 ATM 机的一个单独用例，原因是没有人会使用系统仅执行这一操作。用例是一个完整事件流，它可以产生对主角有价值的东西。
为避免功能分解，您需要确保该用例模型有助于回答诸如以下的问题：

系统的环境是什么？
为什么要建立系统？
用户在使用系统时希望获得什么？
系统将给用户创造什么价值？
03/01/06 14:13 酷帖！臭帖！回复
酷帖评价：臭帖评价：
返回页首

nextar 如果是避免这种功能分解，那是必然的。

--------------------------------------------------------------------------------
就你举的这个例子而言，“在 ATM 机上输入个人识别号”是一个活动，它有特定参与者，但没有可见的有价值的结果，根据用例的定义我们不可能把它划分为一个用例。我们现在讨论的是在对用例定义理解正确的基础上对用例的划分。

关于那个用例不是oo的问题，我就我个人的理解作简单说明：首先，用例是用来帮我们捕获/描述需求用的，而oo实际上是分析/设计/实现范畴的内容，这两者之间本没有必然联系；之所以会认为用例属于oo的范畴，其实在于早期的一些误导，人们提到oo就提到uml,提到uml就提到用例，仿佛oo和用例之间存在必然联系，其实不然，用用例描述的需求一样可以通过非oo的方法来实现；现在会有一些建议把用例和oo的方法结合起来使用，更多的是出于便利的考虑，而不是必需的。
不知上述说明是否足够。
03/01/06 14:47 酷帖！臭帖！回复
酷帖评价：臭帖评价：
返回页首

SimonQiu 回复: 业务用例"见好就收",系统用例"打破沙锅问到底"

--------------------------------------------------------------------------------
同意！！！

记得一篇《建模鸡汤》的文章中提到这么一句话：

“分析是一门科学，而设计是一门艺术”

想必大家都能理解，他说的意思就是说在作需求分析的时候应该一丝不苟，认认真真的进行，并要尽可能的保证阶段性的准确性，否则会给系统带来比编码更严重的BUG！！！！
03/01/08 15:08 酷帖！臭帖！回复
酷帖评价：臭帖评价：
返回页首

话题树型展开

人气	标题	作者	字数	发贴时间
4149	[转帖]用例应该分多细 (from umlchina)	yj780210	10251	2003-01-15 09:12

已读帖子

新的帖子

被删除的帖子