SoftEng 版 (精华区)

发信人: alai (alai), 信区: SoftEng
标  题: 标准建模语言UML的静态建模机制(二)
发信站: 紫 丁 香 (Sat Apr  8 03:45:30 2000), 转信

(4) 使用和扩展(Use and Extend)

    使用和扩展是两种不同形式的继承关系。当一个用例与另一个用例相似,但所做的动
作多一些,就可以用到扩展关系。如基本的用例是"进行交易"。交易中可能一切都进行得
很顺利,但也可能存在扰乱顺利进行交易的因素。其中之一便是超出某些边界值的情况。
例如,贸易组织会对某个特定客户规定最大贸易量,这时不能执行给定用例提供的常规动作
,而要做些改动。我们可在"进行交易"用例中做改动。但是,这将把该用例与一大堆特殊的
判断和逻辑混杂在一起,使正常的流程晦涩不堪。当有一大块相似的动作存在于几个用例,
又不想重复描述该动作时,就可以用到使用关系。例如,现实中风险分析和交易估价都需要
评价贸易,为此可单独定义一个用例,即"评价贸易",而"风险分析"和"交易估价"用例将使用
它。

    请注意扩展与使用之间的相似点和不同点。它们两个都意味着从几个用例中抽取那些
公共的行为并放入一个单独用例中,而这个用例被其他几个用例使用或扩展。但使用和扩展
的目的是不同的。

(5) 用例模型的获取
    几乎在任何情况下都会使用用例。用例用来获取需求,规划和控制项目。用例的获取是
需求分析阶段的主要任务之一,而且是首先要做的工作。大部分用例将在项目的需求分析阶
段产生,并且随着工作的深入会发现更多的用例,这些都应及时增添到已有的用例集中。用
例集中的每个用例都是一个潜在的需求。

a. 获取执行者

   获取用例首先要找出系统的执行者。可以通过用户回答一些问题的答案来识别执行者。
以下问题可供参考:
·谁使用系统的主要功能(主要使用者)。
·谁需要系统支持他们的日常工作。
·谁来维护、管理使系统正常工作(辅助使用者)。
·系统需要操纵哪些硬件。
·系统需要与哪些其它系统交互,包含其它计算机系统和其它应用程序。
·对系统产生的结果感兴趣的人或事物。

b. 获取用例
    一旦获取了执行者,就可以对每个执行者提出问题以获取用例。
以下问题可供参考:
·执行者要求系统提供哪些功能(执行者需要做什么)?
·执行者需要读、产生、删除、修改或存储的信息有哪些类型。
·必须提醒执行者的系统事件有哪些?或者执行者必须提醒系统的事件有哪些?
  怎样把这些事件表示成用例中的功能?
·为了完整地描述用例,还需要知道执行者的某些典型功能能否被系统自动实现?

还有一些不针对具体执行者问题(即针对整个系统的问题):
·系统需要何种输入输出?输入从何处来?输出到何处?
·当前运行系统(也许是一些手工操作而不是计算机系统)的主要问题?
 
    需要注意,最后两个问题并不是指没有执行者也可以有用例,只是获取用例时尚不知道
执行者是什么。一个用例必须至少与一个执行者关联。还需要注意:不同的设计者对用例的
利用程度也不同。例如,Ivar Jacobson说,对一个十人年的项目,他需要二十个用例。而在
一个相同规模的项目中,Martin Fowler则用了一百多个用例。我们认为:任何合适的用例都
可使用,确定用例的过程是对获取的用例进行提炼和归纳的过程,对一个十人年的项目来说
,二十个用例似乎太少,一百多个用例则嫌太多,需要保持二者间的相对均衡。(未完待续) 

 

--
※ 来源:．紫 丁 香 bbs.hit.edu.cn．[FROM: 202.118.224.232]