R
rester
Unregistered / Unconfirmed
GUEST, unregistred user!
二、标准建模语言UML的静态建模机制
任何建模语言都以静态建模机制为基础,标准建模语言UML也不例外。UML的静态建模机制包括用例图
(Use case diagram)、类图(Class diagram)、对象图(Object diagram )、包(Package)、构件图(Component diagram)
和配置图(Deployment diagram)。
1. 用例图
(1) 用例模型(Use case model)
长期以来,在面向对象开发和传统的软件开发中,人们根据典型的使用情景来了解需求。但是,这些使用情景
是非正式的,虽然经常使用,却难以建立正式文挡。用例模型由Ivar Jacobson在开发AXE系统中首先使用,并
加入由他所倡导的OOSE和Objectory方法中。用例方法引起了面向对象领域的极大关注。自1994年Ivar Jacobson
的著作出版后,面向对象领域已广泛接纳了用例这一概念,并认为它是第二代面向对象技术的标志。
用例模型描述的是外部执行者(Actor)所理解的系统功能。用例模型用于需求分析阶段,它的建立是系统开发
者和用户反复讨论的结果,表明了开发者和用户对需求规格达成的共识。首先,它描述了待开发系统的功能需
求;其次,它将系统看作黑盒,从外部执行者的角度来理解系统;第三,它驱动了需求分析之后各阶段的开发工作,
不仅在开发过程中保证了系统所有功能的实现,而且被用于验证和检测所开发的系统,从而影响到开发工作的各
个阶段和 UML 的各个模型。在UML中,一个用例模型由若干个用例图描述,用例图主要元素是用例和执行者。
(2) 用例(use case)
从本质上讲,一个用例是用户与计算机之间的一次典型交互作用。以字处理软件为例,"将某些正文置为黑体"和"
创建一个索引"便是两个典型的用例。在UML中,用例被定义成系统执行的一系列动作,动作执行的结果能被指定执
行者察觉到。
在UML中,用例表示为一个椭圆。用例有以下特点:
·用例捕获某些用户可见的需求,实现一个具体的用户目标。
·用例由执行者激活,并提供确切的值给执行者。
·用例可大可小,但它必须是对一个具体的用户目标实现的完整描述。
(3) 执行者(Actor)
执行者是指用户在系统中所扮演的角色。其图形化的表示是一个小人。在处理执行者时,应考虑其
作用,而不是人或工作名称,这一点是很重要的。
不带箭头的线段将执行者与用例连接到一起,表示两者之间交换信息,称之为通信联系。执行者触发用例,
并与用例进行信息交换。单个执行者可与多个用例联系;反过来,一个用例可与多个执行者联系。对同一个
用例而言,不同执行者有着不同的作用:他们可以从用例中取值,也可以参与到用例中。
需要注意的是执行者在用例图中是用类似人的图形来表示,尽管执行的,但执行者未必是人。例如,执行者也可
以是一个外界系统,该外界系统可能需要从当前系统中获取信息,与当前系统有进行交互。
通过实践,我们发现执行者对提供用例是非常有用的。面对一个大系统,要列出用例清单常常是十分困难。
这时可先列出执行者清单,再对每个执行者列出它的用例,问题就会变得容易很多。
(4) 使用和扩展(Use and Extend)
使用和扩展是两种不同形式的继承关系。当一个用例与另一个用例相似,但所做的动作多一些,就可以用到扩展关系。
(5) 用例模型的获取
几乎在任何情况下都会使用用例。用例用来获取需求,规划和控制项目。用例的获取是需求分析阶段的
主要任务之一,而且是首先要做的工作。大部分用例将在项目的需求分析阶段产生,并且随着工作的深入
会发现更多的用例,这些都应及时增添到已有的用例集中。用例集中的每个用例都是一个潜在的需求。
a. 获取执行者
获取用例首先要找出系统的执行者。可以通过用户回答一些问题的答案来识别执行者。以下问题可供参考:
·谁使用系统的主要功能(主要使用者)。
·谁需要系统支持他们的日常工作。
·谁来维护、管理使系统正常工作(辅助使用者)。
·系统需要操纵哪些硬件。
·系统需要与哪些其它系统交互,包含其它计算机系统和其它应用程序。
·对系统产生的结果感兴趣的人或事物。
b. 获取用例
一旦获取了执行者,就可以对每个执行者提出问题以获取用例。
以下问题可供参考:
·执行者要求系统提供哪些功能(执行者需要做什么)?
·执行者需要读、产生、删除、修改或存储的信息有哪些类型。
·必须提醒执行者的系统事件有哪些?或者执行者必须提醒系统的事件有哪些?怎样把这些事件表示成用例中的功能?
·为了完整地描述用例,还需要知道执行者的某些典型功能能否被系统自动实现?
还有一些不针对具体执行者问题(即针对整个系统的问题):
·系统需要何种输入输出?输入从何处来?输出到何处?
·当前运行系统(也许是一些手工操作而不是计算机系统)的主要问题?
需要注意,最后两个问题并不是指没有执行者也可以有用例,只是获取用例时尚不知道执行者是什么。
一个用例必须至少与一个执行者关联。还需要注意:不同的设计者对用例的利用程度也不同。例如,
Ivar Jacobson说,对一个十人年的项目,他需要二十个用例。而在一个相同规模的项目中,Martin Fowler
则用了一百多个用例。我们认为:任何合适的用例都可使用,确定用例的过程是对获取的用例进行
提炼和归纳的过程,对一个十人年的项目来说,二十个用例似乎太少,一百多个用例则嫌太多,需要
保持二者间的相对均衡。
