use case正解（答olive, knight, builder, 3nt和think关于use case的讨论).txt

一些关于UML的经典讨论

Use Case正解（答olive, knight, builder, 3nt和think关于Use Case的讨论)

大家好，下面是我的观点，望能抛砖引玉： 

1、好像不少人对Use Case存在误解，或者片面的认识。其实作为原爱立信公司的软件总设计师，Ivar Jacobson对软件界最重要的贡献之一就在Use Case上（另一个重大发明是被电信界广范采用的SDL），所以要真正理解Use Case，推荐大家有机会读一下Jacobson的经典名著“OOSE”(即Object-oriented Software Engineering - A Use Case Driven Approach)。
不能苟同olive的观点。
Use Case绝不是锦上添花的东西，一方面它可以促进与用户沟通，理解正确的需求，另一方面它可以划分系统与外部实体的界限，是系统设计的起点，而最终应该落实到类和实现代码上。
Use Case View与Logical View应该由明确的相关性。UML中从Use Case到类包的关联可以用依赖（或实现）关系描述，好像Rose 2000已经可以支持该功能了。
Actor不是指人，而是指代表某一种特定功能的角色，因此同一个人可能对应很多个Actor。Actor是虚拟的概念，甚至可以指像外部系统和设备。
理论上我们可以把一个软件系统的所有Use Case画出来，但实际运用时只需把重要的、交互过程复杂的那些画出来。
Use Case是对系统行为的动态描述，它是OO设计的起点，是类、对象、操作的来源，而通过逻辑视图的设计，我们可以获得软件的静态结构。
Use Case是Jacobson在设计世界上最大、最成功的OO产品——爱立信著名的AXE系列程控交换机过程中发明的，可见Use Case的重要性和实践意义。 

2、OOAD大部分情况下比结构化设计好。 

我认为结构化设计是过时的东西，它强调软件的结构按照功能来组织，一旦功能改变，软件的结构就会不稳定。
而OO设计把数据流和功能统一起来，因此我估计，IT行业绝大部分（70-80%）的软件设计（包括数据库设计）可以采用OO方法，目前国外流行的趋势也是这样，剩下的少部分有特定需求的可能还会用传统方法。
另外在电信界，用有限自动状态机的SDL方法仍占绝大数，但现在UML和SDL出现了融合的趋势，而Jacobson则是幕后戏剧性的重量级人物。 

3、Use Case是可以分解的
最近Jacobson出了一本新书: Software Reuse - Architecture, Process and Organization for Business Success. （世界图书出版公司影印版，88元）。很巧，去年底我在南京成贤街的小书店买到的，感觉如或至宝。该书通过一个网上银行的例子，对UML建模作了精辟的分析，大家可以从中了解到Use Case的正确用法。
书中在针对软件的分层结构，用了超系统和超用例（Superordinate Use Case）的概念。
分解一般在功能细化的时候进行，相当于子系统的功能分析。分解后当然还是Use Case图。
Use Case驱动很好理解，因为Use Case分析总是迭代递增开发过程中每次循环的起点。 

4、光有思想和方法论是不够的，最后还要落实到系统的实现上，即代码，这样才能前后贯通，从而对OOA、OOD、OOP方法有深刻的认识。这方面Rose的集成功能做的较为完善。 

5、Rose仅仅是UML设计的一种工具，事实上还有很多其他类似工具，包括嵌入式实时系统的UML设计。个人感觉Rose的可视化作的不错，使用较方便，就是耗内存，有点慢。据说国外有人用一个ROSE模型就有上千个类。大家可以参加Rational公司的Rose论坛，里面非常热闹，往往有问必答，包括FAQ和菜鸟级问题，最大的好处是可以了解世界先进水平的专业级用法。 

6、最后，我不是Rational公司的。 

#:--)


一些补充

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


Actor是指系统以外的，需要使用系统或与系统交互的东西。包括人，设备和
其它系统。
UseCase应该覆盖系统的所有功能性需求，即使是简单的UseCase，只要它确实
描述了这类需求，就应该在UseCase图上画出来，并用UseCase specification
加以详细描述。UseCase还是做开发计划，测试计划，设计测试用例的依据，
所以UseCase一定要识别得充分而完整。
UseCase与最后设计出来的类的关系是通过Use Case Realization来表现的。
一般不画它与类包的依赖关系，画出来一定很复杂，且意义不大。Use Case
Realization可以描述清楚类与类之间是如何协作来perform一个Use Case的。



USE CASE多少的问题?

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


好象在北航的那本书中提到了USE CASE多少的问题,有人用20-30个左右,有人用100多个,FRANCK的看法大概是100多个的那种.从需求定义,系统边界的角度,似乎应该是这样,那么为什么会有少定义USE CASE的情况呐? 

是否应该定义主要的,用户最关心的,对系统结构有重大影响的,而对于简单的如代码维护等就不必划USE CASE图了.
或者,都划,但简单不用Use Case Realization来详细描述.



Re: USE CASE多少的问题?

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

系统的规模不一样，Use Case的数目当然就不一样，怎么能硬性规定呢？
小的系统，可能7，8个就可以了，一个大系统，比如一个ERP系统，恐怕
100多个都不止吧？Use Case的数目还和Use Case的粒度有关。粒度大了
数目自然就少了。
我还是认为Use Case应该找全，简单的也要找出来。当然可以不用详细的
事件流来描述，只写出简单的步骤。Use Case Realization也应该做，
否则怎么保证类找得全呢？类的属性和方法都找全呢？


很好，但是...

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

回复给: Use Case正解（答olive, knight, builder, 3nt和think关于Use Case的讨论) posted by Dr.OO on July 17, 19100 at 14:44:13: 

www.umlchina.com中UML评论栏中有一篇转载的"use case miss the boat"中的观点怎么反驳呢？
当然我并不赞同olive的观点。

我记错了，应该是UML misses the boat

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