软件设计师 八:7.2 UML(3-5分)

UML:统一建模语言

统一建模语言是面向对象软件的标准化建模语言。由于其简单、统一,又能够表达软件设计中的动态静态信息,目前已成为可视化建模语言事实上的工业标准。

UML由3个要素构成:UML的基本构造块、支配这些构造块如何放置在一起的规则和运用与整个语言的一些公告机制(此次仅讨论基本构造块)

UML的词汇表包含3中构造块:事物、关系和图。

💡 事物是对模型中最具有代表性的成分的抽象;关系把事物结合在一起;图聚集了相关的事物

7.2.1 事物(题目较少)

UML中有4种事物:结构事物、行为事物、分组事物和注释事物

1. 结构事物

结构事物是UML模型种的名词。它们通常是模型的静态部分,描述概念或物理元素。

结构事物包括类(Class)、接口(Interface)、协作(Collaboration)、用例(Use Case)、主动类(Active Class)、构件(Component)、制品(Artifact)和结点(Node).
在这里插入图片描述

2. 行为事物

行为事物是UML模型的动态部分。它们是模型中的动词,描述了跨越时间和空间的行为。行为事物包括交互(Interaction)、状态机(State Machine)和活动(Activity)。
在这里插入图片描述

3. 分组事物

分组事物是UML模型的组织部分,是一些由模型分解成的“盒子”。在所有的分组事物中,最主要的分组事物是包。

包是把元素组织成组的机制,这种机制具有多种用途。

结构事物、行为事物甚至其他分组事物都可以放进包内。

包与构件(仅在运行时存在)不同,它纯粹是概念上的(即它仅在开发时存在)。
在这里插入图片描述

4. 注释事物

注释事物是UML模型的解释部分。这些注释事物用来描述说明标注模型的任何元素。

注解(Note)是一种主要的注释事物。注解是一个依附于一个元素或者一组元素之上,对它进行约束或解释的简单符号。
在这里插入图片描述

7.2.2 关系(题目不多不少)

UML中有4种关系:依赖、关联、泛化和实现(耦合度逐渐加强,其中泛化和实现的耦合度是一样的,都是最强)

【Web开发必备技能】UML类图、类与类之间的关系详解

1. 依赖

依赖是两个事物间语义关系,其中一个事物(独立事物)发送变化会影响另一个事物(依赖事物)的语义。

💡依赖关系是一种使用关系,它是对象之间耦合度最弱的一种关联方式,是临时性的关联。在代码中,某个类的方法通过局部变量、方法的参数或者对静态方法的调用来访问另一个类(被依赖类)中的某些方法来完成一些职责。

把一个依赖画成一条可能有方向的虚线

则A为依赖事物

B为独立事物
在这里插入图片描述

2. 关联 (关系里考的最多的)

关联是一种结构关系,它描述了一组链链是对象之间的连接

在关联上可以标注重复度(多重度)和角色

💡关联关系对象之间的一种引用关系(但是不存在一个类包含另外一个类的情况),用于表示一类对象与另一类对象之间的联系,如老师和学生、师傅和徒弟、丈夫和妻子、客户和订单等。
关联关系是类与类之间最常用的一种关系,分为:一般关系、聚合关系和组合关系。我们先介绍一般关系
关联可以是双向的,也可以是单向的。在UML类图中,双向的关联可以用带两个箭头或者没有箭头的实线来表示,单向的关联用带一个箭头的实线来表示箭头从使用类指向被关联的类。也可以在关联线的两端标注角色名,代表两种不同的角色。
在代码中通常将一个类的对象作为另一个类的成员变量来实现关联关系。

eg:1个雇主可以对应多个员工;多个员工可以对应0个或1个雇主
在这里插入图片描述

employer为雇主;employee为员工

0…1意思为0个至1个:[0,1]

0…意思为0个至多个:[0,]

左上角和右上角位多重度,左下角和右下角位一个角色(实例),线的上方正中间为一个关联名

则意思为:雇主与员工之间是1对n的关系,每个雇主可以有多个员工,每个员工只能属于一个雇主

2.1 聚集(聚合,组合)一个类包含另外一个类

是一种特殊类型的关联,它描述了整体和部分间的结构关系。

  1. 聚合

    部分和整体的声生命周期不一致,整体消失了,部分仍然存在,部分可以脱离整体存在。

💡 eg:公司倒闭了,但是公司的人依旧是会存在的,只是不再是这家公司的职员而已(总不能公司倒闭了,人就都杀了吧!!!)
即将多个人(或其他东西)组合在一起称为一个群体(名)。群体(名)可以消失(解散),但是单个人(或其他东西)依旧存在

在这里插入图片描述
在这里插入图片描述

  1. 组合

    部分和整体的生命周期一致,整体消失了,部分也会随即消失,部分不可以脱离整体存在

💡 eg:人去世后,人的各个细胞也就无法继续运行了,也一起死亡了    

在这里插入图片描述
在这里插入图片描述

3. 泛化

泛化是一种特殊/一般关系,特殊元素(子元素)的对象可替代一般元素(父元素)的对象。用这种方法,子元素共享了父元素的结构和行为。

在图形上,把泛化关系画成一条带有空心箭头的实线,它指向父元素

💡 父类泛化子类;子类继承父类

在这里插入图片描述在这里插入图片描述

4. 实现

实现是类元之间的语义关系,其中一个类元指定了由另一个类元保证指向的契约。在两种情况下会使用实现关系

  • 一种是在接口和实现它们的类或构建之间
  • 另一种是在用例和实现它们的协作之间

在图形上,把一个实现关系画成一条带有空心箭头的虚线。
在这里插入图片描述

补充(关联类)

前提条件:两个类必须是多对多的关系,才会产生关联类
在这里插入图片描述

关系总结

在这里插入图片描述
在这里插入图片描述

7.2.3 UML中的图(题目较多)

图是一组元素的图形表示,大多数情况下把图画成顶点(代表事物)和弧(代表关系)的连通图。为了对系统进行可视化,可以从不同的角度画图,这样图是对系统的投影

UML 2.0提高了13种图,分别是类图、对象图、用例图、序列图、通信图、状态图、活动图、构件图、组合结构图部署图包图、交互概览图和计时图序列图、通信图、交互概览图和计时图均被称为交互图

1. 类图(静态)

主要支持系统的功能需求

类图展现了一组对象、接口、协作和它们之间的关系。在面向对象系统的建模中所建立的最常见的图就是类图。类图给出系统的静态设计视图包含主动类的类图给出了系统的静态进程视图。

类图中通常包括下述内容:

  • 接口(少见
  • 协作(少见
  • 依赖、泛化和关联关系
    在这里插入图片描述
    在这里插入图片描述

2. 对象图(静态)

主要支持系统的功能需求

对象图展现了某一时刻一组对象以及它们之间的关系,描述了在类图中所建立的事物的实例的静态写照。对象图一般包括对象和链。
在这里插入图片描述
在这里插入图片描述

和类图一样,对象图给出系统的静态设计视图或静态进程视图,但它们是从真实的或原型实例的角度建立的。

在对系统的静态设计视图或静态进程视图建模时,主要使用对象图对对象结构进行建模。
在这里插入图片描述

3.用例图(静态)(上午题少,下午题常客)

用例图展现了一组用例、参与者(Actor)以及它们之间的关系。用例图通常包括以下内容

  • 用例:椭圆形
    • 用例是从用户角度描述系统的行为,它将系统的一个功能描述成一系列的事件,这些事件最终对操作者产生有价值的观测结果。用例是一个类,它代表一类功能而不是使用该功能的某一具体实例。
  • 参与者:小人
    • 参与者是与系统交互的外部实体,可能是使用者,也可能是与系统交互的外部系统。基础设备等。
  • 用例之间的扩展关系(<<extend>>)和包含关系(<<include>>),参与者和用例之间的关联关系(———),用例与用例以及参与者与参与者之间的泛化关系。
    在这里插入图片描述
    在这里插入图片描述

3.1 包含关系(<>)

用例与用例之间的关系———>一个用例包含另一个用例(用例即行为/方法
必须先执行被包含用例,再执行基本用例(?)
在这里插入图片描述
在这里插入图片描述

3.2 扩展关系(<<extend>>

用例与用例之间的关系———>一个用例执行的时候,可能会发送一些特殊的情况或可选的情况,这种情况就是这个用例的扩展用例。
在这里插入图片描述
在这里插入图片描述

3.3 泛化关系

参与者与参与者之间的关系和用例与用例之间的关系
在这里插入图片描述

4. 交互图(动态)

交互图用于对系统的动态方面进行建模。一张交互图表现的是一个交互,由一组对象和它们之间的关系组成,包含它们之间可能传递的信息。

交互图表现为序列图通信图、交互概览图和计时图,每种针对不同的目的,能适用于不同的情况。

序列图是强调消息时间顺序的交互图;

通信图是强调接收和发送消息的对象的结构组织的交互图;

交互概览图强调控制流的交互图
在这里插入图片描述

交互图一般包含对象、链和消息。

序列图和通信图是同构的,它们之间可以相互转换

4.1 序列图(顺序图)

序列图是场景的图形化表示,描述了以时间顺序组织的对象之间的交互活动。

如图,形成序列图时,首先把参加交互的对象放在图的上方,沿水平方向排列。通常把发起交互的对象放在左边,下级对象依次放在右边。然后,把这些对象发送和接收的消息沿垂直方向按时间顺序从上到下放置。这样,就提供了控制流随时间推移的清晰的可视化轨迹

  • 同步消息:需要等接收方返回消息后才可进行下一步
  • 异步消息:不需要等接收方返回消息
    在这里插入图片描述

序列图有两个不同于通信图的特征

  1. 序列图有对象生命线

    对象生命线是一条垂直的虚线,表示一个对象在一段时间内存在。

    在交互图中出现的大多数对象存在于整个交互过程中,所以这些对象全都排列在图的顶部,其生命线从图的顶部画到图的底部。但对象也可以在交互过程中创建,它们的生命线从接收到构造型为create的消息时开始。对象也可以在交互过程中撤销,它们的生命线在接收到构造型为destroy的消息时结束(并且给出一个大X的标记表明生命的结束)

  2. 序列图有控制焦点

    控制焦点是一个瘦高的矩形,表示一个对象执行一个动作所经历的时间段,既可以是直接执行,也可以是通过下级过程执行。矩形的顶部表示动作的开始,底部表示动作的结束(可以由一个返回消息来标记)

  • 序列图举例
    在这里插入图片描述
    在这里插入图片描述

4.2 通信图(协作图)

通信图描述了对象之间的消息流及其顺序。

通信图强调收发消息的对象的结构组织。通信图强调参加交互的对象的组织。产生一张通信图,如图。

首先要将参加交互的对象作为图的顶点,然后把连接这些对象的链表示为图的弧,最后用对象发送和接收的消息来修饰这些链。这就提供了在协作对象的结构组织的语境中观察控制流的一个清晰的可视化轨迹。
在这里插入图片描述
通信图有两个不同于序列图的特性

  • 通信图有路径
  • 通信图有顺序号
    在这里插入图片描述
  • 通信图举例
    在这里插入图片描述

5. 状态图(动态)(21上,下都考了)

状态图展现了一个状态机,它由状态、转换、事件和活动组成。状态图关注系统的动态视图,对于接口、类和协作的行为建模尤为重要,强调对象行为的事件顺序。

状态图通常包括简单状态和组合状态、转换(事件和动作)

5.1 状态和活动

状态时任何可以被观察到的系统行为模式,一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。系统对事件的响应,就可以做为一个(或一系列)动作,也可以仅仅改变系统本身的状态,还可以是既改变状态,又做动作。

在状态转换图中定义的状态主要有:

  • 初态:即初始状态
    • 初态用一个黑圆点表示:●
  • 中间状态
  • 终态:即最终状态
    • 终态用黑圆点外加一个圆表示

💡 状态图中的状态用一个圆角四边形表示(可以用两条水平横线把它分成上、中、下3个部分)
上面部分——为状态名称(必须有)
中间部分——为状态变量的名称和值(可以有也可以无)
下面部分——是活动表(可以有也可以无)(活动表是若干动作组成的)
状态之间的状态转换,用一条带箭头的线表示。带箭头的线上的事件发生时,状态转换开始(有时也称为转换“点火”或转换被“触发”)。一张状态图中只能有一个初态,而终态可以没有,也可以有多个。

在这里插入图片描述

状态中的活动表的语法格式如下

事件名(参数表) / 动作表达式 事件名(参数表)/动作表达式 事件名(参数表)/动作表达式

  • “事件名”可以是任何事件的名称。在活动表中经常使用下述3种标准事件:entry、exit和do.
    • entry事件指定进入该状态的动作
    • exit事件指定退出该状态的动作
    • do事件指定在该状态下的动作。
  • 需要时可以为事件指定参数表
  • 活动表种的动作表达式描述应做的具体动作
    在这里插入图片描述
    在这里插入图片描述

5.2 事件和转换

事件是在某个特定时刻发生的事情,它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。例如,观众使用电视遥控器,用户移动鼠标,单击鼠标等事件。简而言之,事件就是引起系统做动作或(和)转换状态的控制信息。

状态变迁通常是由事件触发的,在这种情况下,应在表示状态转换的箭头线上标出触发转换的事件表达式。

如果在箭头线上未标明事件,则表示在源状态的内部活动执行完之后自动触发转换。

转换(迁移)应该包含两个状态(源状态和目标状态)否则为不合法的。还可能包括事件,监护条件,动作

活动(动作)可以在状态内执行,也可以在状态转换(迁移)时执行

事件表达式的语法如下:

事件说明 [ 守卫条件 ] / 动作表达式 事件说明[守卫条件]/动作表达式 事件说明[守卫条件]/动作表达式

其中,事件说明的语法为:事件名(参数表)

守卫(监护)条件是一个布尔表达式。如果同时使用事件说明和监护条件,则当且仅当事件发生且布尔表达式为真时,状态转换才发生(即可以先判断监护条件,监护条件为真,在执行事件)。如果只有监护条件没有事件说明,则只要监护条件为真,状态转换就发生。
在这里插入图片描述
动作表达式是一个过程表达式,当状态转换开始时执行该表达式。
在这里插入图片描述

5.3 总结

状态图通常包括简单状态和组合状态、转换(事件和动作)
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
并发状态
在这里插入图片描述
在这里插入图片描述

6. 活动图(动态)

活动图是一种特殊的状态图,它展现了在系统内从一个活动到另一个活动的流程。

活动图专注于系统的动态视图,它对于系统的功能建模特别重要,并强调对象间的控制流程

活动图可以表示分支、合并、分岔和汇合

  • 对工作流建模
  • 对操作建模
    在这里插入图片描述

7. 构件图(组件图)(静态)

构件图展现了一组构件(组件)之间的组织和依赖。构件图专注于系统的静态实现视图。它与类图相关,通常把构件映射为一个或多个类、接口或协作。

UML图详解(五)组件图_架构师成长营的博客-CSDN博客_供接口和需接口

供接口( ◯ \bigcirc )需要需接口( ⊂ \sub )实现
在这里插入图片描述

8. 部署图(静态)(上午题考的少,下午题不考)

部署图是用来对面向对象系统的物理方法建模的方法,展现了运行时处理结点以及其中构件(制品)的配置。部署图对系统的静态部署视图进行建模,它与构件图相关。通常,一个结点是一个在运行时存在并代表一项计算资源的物理元素,至少拥有一些内容,常常具有处理能力,包括一个或多个构件,其依赖关系类似于包图。其中,<<artifact>>表示制品

  • 部署图展现了系统的软件和硬件之间的关系
  • 在实施阶段(即实施工程)阶段使用

7.2.4 UML图总结

在这里插入图片描述

  • 3
    点赞
  • 24
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值