第3章-用例和用例图.docVIP

第3章用例和用例图

3.1用例

用例〔usecase〕这个概念是IvarJacobson于20世纪60～70年代在爱立信公司开发AKE、AXE系列系统时创造的，并在其博士论文“Conceptsformodelinglargerealtimesystems”〔1985年〕和1992年出版的论著“Object-orientedsoftwareengineering：ausecasedrivenapproach”中做了详细论述。

【定义1】用例是对一个活动者〔actor〕使用系统的一项功能时所进行的交互过程的一个文字描述序列。

【定义2】用例是系统、子系统或类和外部的参与者〔actor〕交互的动作序列的说明，包括可选的动作序列和会出现异常的动作序列。

在UML中，用例是用一个椭圆表示，用例名往往用动宾结构或主谓结构命名〔如果是英文命名，那么往往是动宾结构〕。图3.1表示的是用例的例子。

【例3.1】在字处理程序中，“置正文为黑体”是一个用例，“创立索引”也是一个用例。从这个例子中可以看到，用例的粒度可大可小，用的用例可能很简单，如“置正文为黑体”这个用例就比拟简单，很快就可以实现，但“创立索引”这个用例就比拟复杂，实现起来可能要花很长的时间。

【例3.2】在一个银行业务系统中，可能会有以下一些用例：

·浏览账户余额

·列出交易内容

·划拨资金

·支付账款

·登录

·退出系统

·编辑配置文件

·买进证券

·卖出证券

根据上面的例子，可以发现采用用例进行需求分析时的一些特点：

1．用例从使用系统的角度描述系统中的信息，即站在系统外部观察系统功能，而不考虑系统内部对该功能的具体实现方式。

2．用例描述了用户提出的一些可见需求，对应一个具体的用户目标。使用用例可以促进与用户沟通，理解正确的需求，同时也可以用来划分系统与外部实体的界限，是OO系统设计的起点，是类、对象和操作的来源。

3．用例是对系统行为的动态描述，属于UML的动态建模局部。UML中的建模机制包括静态建模和动态建模两局部，其中静态建模机制包括：类图、对象图、构件图和部署图；动态建模机制包括：用例图、顺序图、协作图、状态图和活动图。需要说明的是，有些书中把用例图归类到静态建模，但根据Booch在[BRJ99，p233]中的说明，用例图属于动态建模局部。

理论上可以把一个软件系统的所有用例都画出来，但实际开发过程中，进行用例分析时只需把那些重要的、交互过程复杂的用例找出来。

不要试图把所有的需求都以用例的方式表示出来，这也是UML初学者易犯的一个错误。初学者对UML的一个普遍误解就是，认为用例可以表示所有的系统需求，因此千方百计地要用UML中的符号来表示那些事实上很难用用例表示的需求。需求有两种根本形式：功能性需求和非功能性需求。那些用UML难以表示的需求很多是非功能性的需求，例如，开发工程中所涉及的术语表〔glossory〕就很难用UML表示。对于这些需求往往是采用附加补充文档的形式来描述。

用例并不是系统的全部需求，用例描述的只是功能性方面的需求。在编写一个系统的需求说明时，应该根据特定的需求大纲来写，很多开发组织或个人提供了需求大纲供参考。例如A.Cockburn给出的需求大纲把需求分为6大局部[Coc00，p13]。

·系统的目的和范围

·系统中的术语表

·用例

·系统采用的技术

·开发过程中的参加人员、业务规那么、系统运行所依赖的条件、平安要去、文档要求等各种其它需求

·法律、政治、组织机构等方面的问题

从上面的需求大纲可以看到，用例只是所有需求中的一局部内容。

用例这种技术很容易使用，但也很容易误用。正确使用用例分析来做好领域建模〔domainmodeling〕，以确保定义正确的需求〔rightrequirements〕，然后开发出正确的系统〔rightsystem〕，是保证OO软件开发成功的根底。对于初学者来说，掌握用例的概念并不难，但要在具体的工程中灵活地使用用例来捕获用户的需求，并不是一件容易的事情，往往需要用户的经验、沟通能力、丰富的领域知识等。

本质上，用例分析是一种功能分解〔functionaldecomposition〕的技术，并未使用到面向对象思想。因而有人认为用例分析只是面向对象分析与设计〔Object-OrientedAnalysis/Object-OrientedDesign，OOA/OOD〕的先导性工作，并非OOA/OOD过程的一局部，但也有人视其为OOA/OOD的一环。不管怎样，用例是UML的一局部，确定一个系统的用例是开发OO系统的第一步，用例分析这步做得好，接着的交互图分析、类图分析等才有可能做得好，整个系统的开发才能顺利进行。

用例是与实现无关〔implementationindependent