全面解析UML静态建模机制

开发 架构
UML静态建模你是否熟悉,本文就向大家介绍一下它的概念,任何建模语言都以静态建模机制为基础,标准建模语言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.获取用例

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

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

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

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

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

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

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

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

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

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

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

  2.类图、对象图和包

  (1)类图

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

  (2)类和对象

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

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

  (3)关联关系

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

  关联的方向

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

  关联的命名

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

  聚集(Aggregation)是一种特殊形式的关联。UML静态建模中聚集表示类之间的关系是整体与部分的关系。一辆轿车包含四个车轮、一个方向盘、一个发动机和一个底盘,这是聚集的一个例子。在需求分析中,"包含"、"组成"、"分为……部分"等经常设计成聚集关系。聚集可以进一步划分成共享聚集(SharedAggregation)和组成。例如,课题组包含许多成员,但是每个成员又可以是另一个课题组的成员,即部分可以参加多个整体,我们称之为共享聚集。

  另一种情况是整体拥有各部分,部分与整体共存,如整体不存在了,部分也会随之消失,这称为组成(Composition)。例如,我们打开一个视窗口,它就由标题、外框和显示区所组成。一旦消亡则各部分同时消失。在UML中,聚集表示为空心菱形,组成表示为实心菱形。

【编辑推荐】

  1. UML轻松入门--UML静态建模:用例
  2. 使用彩色UML建模 彰显颜色的魅力
  3. 畅谈UML静态建模机制
  4. UML静态建模:类和对象
  5. UML建模中绘制UML用例图行之有效的办法
责任编辑:佚名 来源: csdn.net
相关推荐

2010-07-08 14:13:58

UML静态建模

2010-06-17 10:05:35

UML动态建模

2010-06-30 10:30:29

UML动态建模

2010-07-09 13:16:46

UML动态建模机制

2010-07-07 09:34:06

UML用户指南

2010-06-30 13:53:28

UML建模过程

2010-07-07 10:35:40

UML软件建模

2010-06-30 15:26:33

UML静态建模

2010-06-17 10:38:08

UML动态建模机制

2010-07-12 15:25:05

UML建模工具

2010-06-09 13:06:22

UML业务建模实例

2010-06-30 15:40:08

2010-07-12 14:47:53

UML建模

2010-06-30 14:46:49

UML类图

2010-06-18 18:42:43

UML建模语言

2010-07-09 15:19:58

UML类图建模

2010-06-18 16:35:32

UML建模

2010-06-28 09:44:48

UML建模工具Rose

2010-06-28 18:52:49

UML关系符号

2010-06-30 16:06:28

UML建模优点
点赞
收藏

51CTO技术栈公众号