use case 图是否可以分层次画.txt

一些关于UML的经典讨论

demogorgon   use case 图是否可以分层次画？
　
http://www.umlchina.com/best/g34/u1151169.htm
--------------------------------------------------------------------------------
 
比如有一个use case图包含了“信用管理”这样一个用例，可是“信用管理”有 
可能有很多内容，如果把所有的用例都分解很细可能会使图太复杂，难以理解。 
那么有没有可能分层次画出？ 画用例图时有需要注意说不能画成功能分解，那么应该怎么样做才是比较正确的？
 
 03/09/27 13:50 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 wyhacker  回复: use case 图是否可以分层次画？
　
--------------------------------------------------------------------------------
 
　　Use Case 是过程抽象，不是概念抽象。是把过程相似的活动组织在一起，而不是把与某一类事物相关的业务放到一起。 
　　Use Case 有层次，如Business Use Case、System Use Case。但是这种层次与数据流程图中的层次决不一样。比如说，统一过程中，一个好的System Use Case在开发过程中将一直保持稳定，从而驱动系统开发向推进。如果说，你的Use Case过于复杂，那不是对Use Case理解有误，就是Use Case粒度没有选好。
 
 03/09/27 14:33 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 mengyuetao  不如把它分为不同的用例文件！
　
--------------------------------------------------------------------------------
 
 03/09/27 14:53 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 chenhuijun   回复: use case 图是否可以分层次画？
　
--------------------------------------------------------------------------------
 
我也有同样的困惑，看过一些资料，都说明了一个意思：用例是表达一个有意义的用户业务过程。但是，这些有意义的业务过程是由一些具体的步骤组成，也就是很多人经常认为的“子用例”。这些具体的步骤可以作为用例场景中的具体路径进行描述。这也就说明单凭用例图是不能清楚地描述真正的用例的，还要借助于详细的文档。有的人说常用的操作CRUD是不能作为用例存在的，因为他没有真正的意义，我也同意。不过今天我看了RoseTutorial中的例子，为什么在它的用力图中所谓的“Create New Order”“Edit Order”等等可以作为用例呢？请高手指点。是不是只要将业务描述清楚就可以了，不必拘泥于所谓的规则，是吧？
 
 03/09/27 15:57 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 wyhacker  回复: use case 图是否可以分层次画？
　
--------------------------------------------------------------------------------
 
　　不管什么时候，用例的粒度可能都是一个困扰人的问题。我个人认为用例的粒度分为两个维度。一是横向，一是纵向。横向就是过程的抽象程度。纵向就是过程的总体长度。 
　　用例常常是几个相似过程的抽象，换句话说用例描述的可能是几个业务过程，而不一定就是一个业务过程，但前题是他们相似、相关。至于以“Create New Order”、“Edit Order”作为用例，我认为是很正常的。对于“Edit Order”用例，很可能包括修改、查看、添加项（Item）、删除项等相实际过程。画出他们的活动图，看一下，他们的过程应该是很相似的。 
　　另一方面，在纵向维度上，其大小应该以易于应用为原则。毕竟，用例是用来驱动整个开发的。如果在用例中，用户与系统的交互序列很长，那么，将来你在需求时做活动图，分析和设计时做顺序图，打印文档时，可能就需要特别的打印机或打印纸了。当然不仅于此，它还会为你的后续活动带来很多麻烦，原因很简单，就是因为他太复杂，超出我们的管理能力。不过用例太小也不行。若用例太小，维护用例之间的关系就要花很多精力。总之纵向维度上，用例的大小是在用例本身的复杂性和用例之间的复杂性上的一种选择。
 
 03/09/28 10:22 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 jmisp19  回复: use case 图是否可以分层次画？
　
--------------------------------------------------------------------------------
 
这个问题很好，用例图是可以分层，而且必须是分层的。 
一个简单证明： 
用例图是用来交互的，对于架构工程师和程序员应该有不同层次的图，对吧？ 

以前我也很困惑，后来联系RUP才最终想明白，层次的完美的体现了面向对象的思想。有一本《面向对象的软件工程》现在好像只有影印本，建议兄台一读。
 
 03/10/02 14:13 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 sealw  可以分层的，但分解出“信用管理”似乎有些不妥
　
--------------------------------------------------------------------------------
 
一般来说，分成业务级用例，系统级用例和实现级用例。 

业务级用例针对的一般是客户实现的价值。比如说“贷款”，其中一个步骤是“检查客户信用额度”。对客户来说，可能的结果就是贷款成功或失败。这个级别的用例实际上可能涉及组织内多部门和员工的工作才能完成。 

系统级用例针对的是系统的最终用户，即操作系统的人。 

实现级用例是不同系统级用例共同的一些功能。 

所以独立出“信用管理”并不适合放在以上的三个层次。如果放在最上一层，它不为客户提供明确的价值。虽说客户也很关心自己信用额度，但客户不是“信用管理”的Actor。如果放在第二层，它又没有明确的最终用户作为Actor，信用的管理是通过多次贷款还款以及其它信息来实现的吧。也不适合放在第三层。 

独立出“信用管理”似乎是系统功能分解的做法。银行系统包括信用管理子系统。我个人认为，这种思考方式与用例的方式是相违的。 

建议您阅读《有效用例模式》一书。