2004-2-3 21:36
大家好，下面是我的观点，望能抛砖引玉：
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 公司的。
#:--)
一些补充
发言人：Frank Gu
Actor 是指系统以外的，需要使用系统或与系统交互的东西。包括人，设备和其它系统。Use Case 应该覆
盖系统的所有功能性需求，即使是简单的Use Case，只要它确实描述了这类需求，就应该在Use Case 图
上画出来，并用Use Case Specification 加以详细描述。Use Case 还是做开发计划，测试计划，设计测
试用例的依据，所以Use Case 一定要识别得充分而完整。
Use Case 与最后设计出来的类的关系是通过Use Case Realization 来表现的。一般不画它与类包的依赖
关系，画出来一定很复杂，且意义不大。Use CaseRealization 可以描述清楚类与类之间是如何协作来
perform 一个Use Case 的。
USE CASE 多少的问题?
发言人semuw
好象在北航的那本书中提到了USE CASE 多少的问题,有人用20-30 个左右,有人用100 多个, Frank 的看法
大概是100 多个的那种.从需求定义,系统边界的角度,似乎应该是这样,那么为什么会有少定义USE CASE
的情况呐?
是否应该定义主要的,用户最关心的,对系统结构有重大影响的,而对于简单的如代码维护等就不必划USE
CASE 图了. 或者,都划,但简单不用Use Case Realization 来详细描述.
Re: USE CASE 多少的问题?
发言人Frank Gu
系统的规模不一样，Use Case 的数目当然就不一样，怎么能硬性规定呢？小的系统，可能7，8 个就可以
了，一个大系统，比如一个ERP 系统，恐怕100 多个都不止吧？Use Case 的数目还和Use Case 的粒度有
关。粒度大了
数目自然就少了。
我还是认为Use Case 应该找全，简单的也要找出来。当然可以不用详细的事件流来描述，只写出简单的
步骤。Use Case Realization 也应该做，否则怎么保证类找得全呢？类的属性和方法都找全呢？
我对Use Case 的理解。（也对下面关于Use Case 的讨论发表看法）
发言人Frank Gu
Use Case 的用途。
Use Case 分析是分析系统功能需求，确定系统边界的手段。Use Case Model 是系统需求分析阶段的成果
之一。Use Case View 是RUP 定义的系统架构4+1 五个视图的其中之一。Use Case 是系统分析和设计阶段
的输入之一，是分析和设计，制定开发计划、测试计划、设计测试用例的依据之一。Use Case 不仅仅用来
和用户交流，也是开发人员之间进行交流的重要手段。
Use Case 是非形式化的吗？
怎么样叫形式化，怎么样叫非形式化呢？Use Case 图中每个符号都有确定的含义，Use Case 图的绘制也
有明确的画法和规定。也许很多人对Use Case 的划分和Use Case Specification 的写法有不同的看法，
但至少在一个项目中应保持一致，而不能每个开发人员各写各的。这方面自由度是不应该很大的。这算形
式化还是非形式化呢？
Use Case View 和Logistic View 的关系。
Use Case View 的主要组成部分Use Case Model 是需求分析阶段的成果，分析和设计阶段的输入，Logistic
View 主要是在分析和设计阶段完成的。由此可见Use Case View 和Logistic View 的相关性非常强。Use Case
View 是Logistic View 的设计依据。
在Use Case 和分析与设计类之间的桥梁就是Use Case Realization. Use Case Realization 就是用互相
协作的对象类来描述一个特定的Use Case 在设计模型中是如何实现的。（A use-case realization
describes how a particular use case is realized within the design model, in terms of collaborating
objects。摘自Rational Unified Process）。
一个还是多个Actor?
Actor 是系统以外的与系统交互的人或物。就人这一方面来说，Actor 不是具体的某个用户，而是刻画了
一种角色。在现实世界中可能是某个岗位或职位，等等。这种划分是客观存在的。比如一个财务系统的用
户可能就有出纳，会计，财务主管等。他们会使用系统做不同的事，自然就会有不同的Use Case。所以不
分青红皂白，只用一个Actor 是不行的。如果Actor 与现实世界相符，那用户非但不会搞糊涂，反而会对
Use Case Diagram 理解得更清楚。
只要Word 就够了吗？
Use Case Diagram 不是可有可无的。在一定条件下，一幅图被长篇大论更能说明问题。Use Case Diagram
可以使我们对Actor 与Use Case 的关系，Use Case 之间的关系，系统的边界有一个总体的认识和把握。
Use Case Diagram 和Use Case Specification 缺一不可。就好象我们既要有Class Diagram 又要有Class
Specification 一样。而如果是开发一个大型项目，有上百，数百，甚至上千个Use Case 时，我们还需
要专门的需求管理工具，就更不是一个Word 就能胜任的了。
其实关于Use Case 如何划分，在www.umlchina.com 中有好几篇文章，都是写得很好的。在Rational
Unified Process 中也有具体的指导。
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 公司的。
#:--)
一些补充
发言人：Frank Gu
Actor 是指系统以外的，需要使用系统或与系统交互的东西。包括人，设备和其它系统。Use Case 应该覆
盖系统的所有功能性需求，即使是简单的Use Case，只要它确实描述了这类需求，就应该在Use Case 图
上画出来，并用Use Case Specification 加以详细描述。Use Case 还是做开发计划，测试计划，设计测
试用例的依据，所以Use Case 一定要识别得充分而完整。
Use Case 与最后设计出来的类的关系是通过Use Case Realization 来表现的。一般不画它与类包的依赖
关系，画出来一定很复杂，且意义不大。Use CaseRealization 可以描述清楚类与类之间是如何协作来
perform 一个Use Case 的。
USE CASE 多少的问题?
发言人semuw
好象在北航的那本书中提到了USE CASE 多少的问题,有人用20-30 个左右,有人用100 多个, Frank 的看法
大概是100 多个的那种.从需求定义,系统边界的角度,似乎应该是这样,那么为什么会有少定义USE CASE
的情况呐?
是否应该定义主要的,用户最关心的,对系统结构有重大影响的,而对于简单的如代码维护等就不必划USE
CASE 图了. 或者,都划,但简单不用Use Case Realization 来详细描述.
Re: USE CASE 多少的问题?
发言人Frank Gu
系统的规模不一样，Use Case 的数目当然就不一样，怎么能硬性规定呢？小的系统，可能7，8 个就可以
了，一个大系统，比如一个ERP 系统，恐怕100 多个都不止吧？Use Case 的数目还和Use Case 的粒度有
关。粒度大了
数目自然就少了。
我还是认为Use Case 应该找全，简单的也要找出来。当然可以不用详细的事件流来描述，只写出简单的
步骤。Use Case Realization 也应该做，否则怎么保证类找得全呢？类的属性和方法都找全呢？
我对Use Case 的理解。（也对下面关于Use Case 的讨论发表看法）
发言人Frank Gu
Use Case 的用途。
Use Case 分析是分析系统功能需求，确定系统边界的手段。Use Case Model 是系统需求分析阶段的成果
之一。Use Case View 是RUP 定义的系统架构4+1 五个视图的其中之一。Use Case 是系统分析和设计阶段
的输入之一，是分析和设计，制定开发计划、测试计划、设计测试用例的依据之一。Use Case 不仅仅用来
和用户交流，也是开发人员之间进行交流的重要手段。
Use Case 是非形式化的吗？
怎么样叫形式化，怎么样叫非形式化呢？Use Case 图中每个符号都有确定的含义，Use Case 图的绘制也
有明确的画法和规定。也许很多人对Use Case 的划分和Use Case Specification 的写法有不同的看法，
但至少在一个项目中应保持一致，而不能每个开发人员各写各的。这方面自由度是不应该很大的。这算形
式化还是非形式化呢？
Use Case View 和Logistic View 的关系。
Use Case View 的主要组成部分Use Case Model 是需求分析阶段的成果，分析和设计阶段的输入，Logistic
View 主要是在分析和设计阶段完成的。由此可见Use Case View 和Logistic View 的相关性非常强。Use Case
View 是Logistic View 的设计依据。
在Use Case 和分析与设计类之间的桥梁就是Use Case Realization. Use Case Realization 就是用互相
协作的对象类来描述一个特定的Use Case 在设计模型中是如何实现的。（A use-case realization
describes how a particular use case is realized within the design model, in terms of collaborating
objects。摘自Rational Unified Process）。
一个还是多个Actor?
Actor 是系统以外的与系统交互的人或物。就人这一方面来说，Actor 不是具体的某个用户，而是刻画了
一种角色。在现实世界中可能是某个岗位或职位，等等。这种划分是客观存在的。比如一个财务系统的用
户可能就有出纳，会计，财务主管等。他们会使用系统做不同的事，自然就会有不同的Use Case。所以不
分青红皂白，只用一个Actor 是不行的。如果Actor 与现实世界相符，那用户非但不会搞糊涂，反而会对
Use Case Diagram 理解得更清楚。
只要Word 就够了吗？
Use Case Diagram 不是可有可无的。在一定条件下，一幅图被长篇大论更能说明问题。Use Case Diagram
可以使我们对Actor 与Use Case 的关系，Use Case 之间的关系，系统的边界有一个总体的认识和把握。
Use Case Diagram 和Use Case Specification 缺一不可。就好象我们既要有Class Diagram 又要有Class
Specification 一样。而如果是开发一个大型项目，有上百，数百，甚至上千个Use Case 时，我们还需
要专门的需求管理工具，就更不是一个Word 就能胜任的了。
其实关于Use Case 如何划分，在www.umlchina.com 中有好几篇文章，都是写得很好的。在Rational
Unified Process 中也有具体的指导。