全面解析UML静态建模机制

本文和大家重点讨论一下UML静态建模机制 ，主要包括：用例图(Usecasediagram)、类图(Classdiagram)、对象图(Objectdiagram)、包(Package)、构件图(Componentdiagram)和配置图(Deploymentdiagram)。

UML静态建模机制

任何建模语言都以静态建模机制为基础,标准建模语言UML也不例外。

UML的静态建模机制包括：用例图(Usecasediagram)、类图(Classdiagram)、对象图(Objectdiagram)、包(Package)、构件图(Componentdiagram)和配置图(Deploymentdiagram)。

1.用例图

　　(1)用例模型(Usecasemodel)

用例模型描述的是外部执行者(Actor)所理解的系统功能。用例模型用于需求分析阶段,它的建立是系统开发者和用户反复讨论的结果,表明了开发者和用户对需求规格达成的共识。首先,它描述了待开发系统的功能需求;其次,它将系统看作黑盒,从外部执行者的角度来理解系统;第三,它驱动了需求分析之后各阶段的开发工作,不仅在开发过程中保证了系统所有功能的实现,而且被用于验证和检测所开发的系统,从而影响到开发工作的各个阶段和UML的各个模型。在UML中,一个用例模型由若干个用例图描述,用例图主要元素是用例和执行者。

(2)用例(usecase)

从本质上讲,一个用例是用户与计算机之间的一次典型交互作用。在UML静态建模中,用例被定义成系统执行的一系列动作,动作执行的结果能被指定执行者察觉到。在UML中,用例表示为一个椭圆。概括地说,用例有以下特点:

·用例捕获某些用户可见的需求,实现一个具体的用户目标。

·用例由执行者激活,并提供确切的值给执行者。

·用例可大可小,但它必须是对一个具体的用户目标实现的完整描述。

(3)执行者(Actor)

执行者是指用户在系统中所扮演的角色。其图形化的表示是一个小人。不带箭头的线段将执行者与用例连接到一起,表示两者之间交换信息,称之为通信联系。执行者触发用例,并与用例进行信息交换。单个执行者可与多个用例联系;反过来,一个用例可与多个执行者联系。对同一个用例而言,不同执行者有着不同的作用:他们可以从用例中取值,也可以参与到用例中。

需要注意的是执行者在用例图中是用类似人的图形来表示,尽管执行的,但执行者未必是人。例如,执行者也可以是一个外界系统,该外界系统可能需要从当前系统中获取信息,与当前系统有进行交互。

通过实践,我们发现执行者对提供用例是非常有用的。面对一个大系统,要列出用例清单常常是十分困难。这时可先列出执行者清单,再对每个执行者列出它的用例,问题就会变得容易很多。

(4)使用和扩展(UseandExtend)

UML静态建模中使用和扩展是两种不同形式的继承关系。

当一个用例与另一个用例相似,但所做的动作多一些,就可以用到扩展关系。

当有一大块相似的动作存在于几个用例,又不想重复描述该动作时,就可以用到使用关系。

(5)用例模型的获取

几乎在任何情况下都会使用用例。用例用来获取需求,规划和控制项目。UML静态建模中用例的获取是需求分析阶段的主要任务之一,

而且是首先要做的工作。大部分用例将在项目的需求分析阶段产生,并且随着工作的深入会发现更多的用例,这些都应及时增添到已有的用例集中。用例集中的每个用例都是一个潜在的需求。

a.获取执行者

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

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

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

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

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

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

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

　　b.获取用例

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

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

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

·必须提醒执行者的系统事件有哪些?

或者执行者必须提醒系统的事件有哪些?

怎样把这些事件表示成用例中的功能?

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

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

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

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

需要注意,最后两个问题并不是指没有执行者也可以有用例,只是获取用例时尚不知道执行者是什么。一个用例必须至少与一个执行者关联。还需要注意:不同的设计者对用例的利用程度也不同。

2.类图、对象图和包

　　(1)类图

UML静态建模中类图(ClassDiagram)描述类和类之间的静态关系。与数据模型不同,它不仅显示了信息的结构,同时还描述了系统的行为。类图是定义其它图的基础。在类图的基础上,状态图、合作图等进一步描述了系统其他方面的特性。

(2)类和对象

UML静态建模中对象(Object)与我们对客观世界的理解相关。我们通常用对象描述客观世界中某个具体的实体。所谓类(Class)是对一类具有相同特征的对象的描述。而对象是类的实例(Instance)。建立类模型时,我们应尽量与应用领域的概念保持一致,以使模型更符合客观事实,易修改、易理解和易交流。

类描述一类对象的属性(Attribute)和行为(Behavior)。在UML中,类的可视化表示为一个划分成三个格子的长方形(下面两个格子可省略)。

(3)关联关系

UML静态建模中关联(Association)表示两个类之间存在某种语义上的联系。例如,一个人为一家公司工作,一家公司有许多办公室。我们就认为人和公司、公司和办公室之间存在某种语义上的联系。在分析设计的类图模型中,则在对应人类和公司类、公司类和办公室类之间建立关联关系。

关联的方向

关联可以有方向,表示该关联单方向被使用。关联上加上箭头表示方向,在UML中称为导航(Navigability)。我们将只在一个方向上存在导航表示的关联,称作单向关联(Uni-directionalAssociation),在两个方向上都有导航表示的关联,称作双向关联(Bi-directionalAssociation)。

　　关联的命名

既然关联可以是双向的,最复杂的命名方法是每个方向上给出一个名字,这样的关联有两个名字,可以用小黑三角表示名字的方向