标准建模语言UML及其支持环境(二)

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

　　(5) 用例模型的获取

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

　　a. 获取执行者

　　获取用例首先要找出系统的执行者。可以通过用户回答一些问题的答案来识别执行者。以下问题可供参考:

　　·谁使用系统的主要功能(主要使用者)。

　　·谁需要系统支持他们的日常工作。

　　·谁来维护、管理使系统正常工作(辅助使用者)。

　　·系统需要操纵哪些硬件。

　　·系统需要与哪些其它系统交互,包含其它计算机系统和其它应用程序。

　　·对系统产生的结果感兴趣的人或事物。

　　b. 获取用例

　　一旦获取了执行者,就可以对每个执行者提出问题以获取用例。

　　以下问题可供参考:

　　·执行者要求系统提供哪些功能(执行者需要做什么)?

　　·执行者需要读、产生、删除、修改或存储的信息有哪些类型。

　　·必须提醒执行者的系统事件有哪些?或者执行者必须提醒系统的事件有哪些?怎样把这些事件表示成用例中的功能?

　　

　　·为了完整地描述用例,还需要知道执行者的某些典型功能能否被系统自动实现?

　　还有一些不针对具体执行者问题(即针对整个系统的问题):

　　·系统需要何种输入输出?输入从何处来?输出到何处?

　　·当前运行系统(也许是一些手工操作而不是计算机系统)的主要问题?

　　需要注意,最后两个问题并不是指没有执行者也可以有用例,只是获取用例时尚不知道执行者是什么。一个用例必须至少与一个执行者关联。还需要注意:不同的设计者对用例的利用程度也不同。例如,Ivar Jacobson说,对一个十人年的项目,他需要二十个用例。而在一个相同规模的项目中,Martin Fowler则用了一百多个用例。我们认为:任何合适的用例都可使用,确定用例的过程是对获取的用例进行提炼和归纳的过程,对一个十人年的项目来说,二十个用例似乎太少,一百多个用例则嫌太多,需要保持二者间的相对均衡。(未完待续)

 如果您对本文有任何疑问或者建议，请到讨论区发表您的意见: >> 论坛入口 <<

上一页 1 2下一页

上一篇：标准建模语言UML及其支持环境(一)   下一篇：标准建模语言UML及其支持环境(三)

【文章评论】 【收藏本文】 【推荐好友】 【打印本文】 【我要投稿】 【论坛讨论】