Use Case实践的困惑与改进 笔记

Use Case实践的困惑与改进　－　2004中国软件技术大会笔记

本文是根据２００４年中国软件技术大会的视频所作的笔记，虽然已经两年了，但内容还是不错的，正好最近在用，就积累一下。我想这方面的东西时效性不会太强吧 :－）

一、Use Case 方法的简要回顾（由Ivar Jacobson发明，当时是用于一个大型的电信项目）

1.       本质

－基于建模系统的使用者、使用的场景以及场景中的步骤来获取和组织系统功能需求内容的方法。

        由外向内，从使用者的角度出发

－既是一种沟通的形式(过程)，也是一种信息的组织形式(结果)。

        逐渐细化的过程；用使用者、场景、场景中的步骤将部分需求作划分

2.       实践

－好方法，用不好

二、Use Case 方法的使用范围

1.       应用类型：

1.1   Use Case适用的应用类型（通常用于较大的业务应用）

―具有比较复杂的环境范围(比如使用者类型较多，或与其他系统有交互)

―系统与外围环境的交互以若干种典型的场景构成

1.2   Use Case不适合(无显著优势)的应用类型

―外部环境非常简单 (比如只有一个Actor)

―使用的典型场景不明确，存在大量可能的路径组合(比如IDE)

1.3   提示

－应用Use Case方法与应用面向对象方法并无必然关联。

2.       需求类型：捕获和描述(大部分)功能需求

1.1    非功能性需求

―主要针对质量指标，如可靠性、可用性、易用性、性能、可支持性……

1.2    功能需求

―不具有典型交互特征的功能性需求(比如软件界面的语言支持)

―具有典型交互特征的功能性需求(适合)

1.3    提示

―针对具有典型交互特征的功能性需求，在不同的概括层面，Use Case方法都能够有所帮助

         先搞清楚谁来用(火柴人)，再到涉及的场景、场景中的步骤

3.       使用时机：

Use Case方法不同层面的适用时机

－整体：理解整体的上下文环境

－局部：区分不同使用者要求（从整体到局部：哪些人用、应用场景）

－细节：描述操作具体内容

▲Use Case的目的不是要告诉客户要做哪些动作，而是通过系统能达到什么结果

▲通常都会做很多动作，而且有时动作还会改变

▲一般来讲如果一个系统有50～60个用例（Ivar Jacobson说的），那就是超大(或者超复杂)的系统了

▲组织形式上是要把问题变简单而不是变得更复杂

▲Use Case反映的是用户的体验，是要双方（客户和软件开发商）达成共识。当用户对软件的想法比较具体时可以描述的比较详细，但用户想法很笼统时就少写点，否则就是强加上去的了。

三、Use Case方法的应用技巧

（用例图的左用主要是时和客户交互时使用的过渡性东西，而用例则是自己用的；Use Case在后期最大的作用是告诉你变化是如何传递的，传递途径是什么；用例图中最有用的是连线，在用例中描述的其实是连线－用户的话或系统接口）

1.       整体

－从外向内的视角（就好比是黑盒的，不关心怎么实现）

2.       局部

－典型场景，反映使用者的价值（要让使用者看到他所能得到的东西）

3.       细节

－交互动作的完整性，渐进细化

4.       提示

在某个特定实际应用中，并不是所有的Use Case技术要点都有时机对应的内容。

四、Use Case方法的支撑环境

1.       需求管理工具

－解决条目化的问题，解决局部更新问题(Borland CaliberRM)

2.       UML建模工具

－与后续的分析和设计内容关联(Borland Together Designer)

3.       参考流程

－可操作的参考流程(《Use Case软件需求实践过程》)

 
相关信息：
　　 Ivar Jacobson博士，是许多技术“之父”，这包括组件及基于组件的软件架构，用例，现代业务工程，以及Rational统一过程。他还是统一建模语言 （UML）的三位创始之一。同时他也是关于这些方法和技术的五本畅销书籍的作者，以及两本关于UML的引领性书籍的合著者。Ivar博士是 JacobsonAB公司的创始人，在该公司他与其女儿、合作者Agneta Jacobson共同开发一套开创性的新产品，它将包括支持软件开发的智能代理。同时他还是Ivar Jacotson Consulting公司（IJC）的创始人，其目标是向全世界的开发团队推广优秀的软件开发实践。