UML总复习（一）——最细复习教程

UML总复习（一）知识点篇

UML总复习（二）.

前言

这是本博主的第一篇文章，写这篇文章的原因是致我刚刚裸考结束的考试；写这篇文章的目的有二：
其一：为了大家考试前的复习
其二：我要是没过，我自己留着复习！！！

---

提示：以下是本篇文章正文内容，下面案例可供参考

---

一、UML概述

概论

软件开发分为五个阶段（生命周期）：
需求分析、系统分析与设计、系统实现、测试、维护
（编程仍然是重要的，但是更具有决定意义的是系统建模。只有在分析和设计阶段建立了良好的系统模型，才有可能保证工程的正确实施。）
建模：从本质上讲是标准而规范的设计描述手段

信息系统建模的原则：准确、分层、分治、标准
斜体部分了解一下：
准确的原则：模型必须准确地反映软件系统的真实情况。
分层的原则：在建模的过程中，必须有不同的模型，以不同的抽象程度，反映系统的不同侧面。
分治的原则：不可能单独用一个模型来反映整个系统的任何侧面。
标准的原则：模型必须在某种程度上是通用的。

面向对象技术的优点：▶稳定：较小的需求变化不会导致系统结构大的改变
▶易于理解：面向对象的模型更加贴切地反映了现实世界，尤其对于使用者
▶具有更高的可靠性和灵活性
▶面向对象的方法有助于开发大型软件系统

类是一组具有相同属性和方法的对象的集合
类是静态的：类的存在、语义和关系在程序执行前就已经定义好了。
对象是动态的;：对象在程序执行时可以被创建和删除。

多态性：同一操作作用于不同的对象，可以有不同的解释，产生不同的执行结果
多态性的实现方式：
▶通过接口实现多态性
▶通过继承实现多态性
▶通过抽象类实现的多态性

UML概述

UML的主要特点：
统一标准：已成为面向对象的标准化的统一的建模语言。
面向对象
可视化、表示能力强大
独立于过程
概念明确，建模表示法简洁，图形结构清晰，容易掌握使用。

UML的构成：视图、图、模型元素、通用机制
下图做个了解：

用例视图：
用途：描述系统应该具备的功能，即被称为参与者的外部用户所能观察到的功能。
用例视图是几个视图的核心，它的内容直接驱动其他视图的开发。
UML中的关系 ：

UML经历系统的开发各阶段：
分析阶段、设计阶段、实现阶段、测试阶段

UML(统一建模语言)是为软件系统的制品进行：
▶描述（specifying）
▶可视化（visualizing）
▶构造（constructing）
▶文档化（documenting）的一种语言。
UML的视图：用例视图、设计视图、进程视图、实现视图、分布视图
UML = UML成员 + UML建模规则
UML成员 = UML 基本模型元素+ 关系+ 模型图
UML基本模型元素 = 结构模型元素+行为模型元素+成组元素+注解元素

二、UML用例图

需求分析的任务是确定所开发的软件的功能、性能、数据等各个方面的要求
需求就是系统（项目）必须提供的能力和必须遵从的条件。

需求分类：
◢功能性：有具体的完成内容的需求。
客户登录、邮箱网站的收发收发邮件、论坛网站的发帖留言等。
用户能够搜索所有的数据集合
每一个订单需要分配一个唯一标识符，用户可以永久保存起来
◢非功能性：软件产品为满足用户业务需求而必须具有且除功能需求以外的特性包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。
性能要求：要求系统能满足100个人同时使用，页面反应时间不能超过6秒；

进入正题啦：
首先我们先看看用例图长什么样子（基本就是下面的模样了）：

用例图是干什么的呢？
前面我们总结到它是用来描述系统应该具备的功能滴
既然是图了，它显示的内容是：
·相关的用户
·用户希望系统提供什么服务
·用户需要为系统提供的服务
它经常用来描述系统以及子系统。

---

那么这个图该怎么入手呢？
首先需要知道画这类图用到的一些元素：
用例图包含6个元素：
☬参与者
☬用例
☬关联关系
☬包含关系
☬扩展关系
☬泛化关系
接下来我们挨个进行介绍：
☬参与者：
首先它是长下面这个样子的：

大多数情况下就是系统的面向人员（没错，就是人），是谁会使用该系统，谁的操作会影响/控制该系统，可以是服务对象，可以是操作对象。
但是如果参与者只是由人组成的话就太单纯了，它还可以表示与所建造的系统交互的其他系统或者一些可以运行的进程。

☬用例：
长相如下图所示：

用例是对一个活动者使用系统的一项功能时所进行的交互过程的一个文字描述序列。（说白了就是一项功能啦，但是这个功能的粒度可不能太大。） 使用use case可以用来划分系统与外部实体的界限，是OO系统设计的起点，是类、对象、操作的来源。Use Case分析是一种功能分解的技术

用例的描述（划重点）：
用例图自然关键元素就是用例，这里不仅在图形上有所体现，在必要时，对用例进行描述是必不可少的。
用例的描述是独立于实现方法的，描述系统“做什么”，而不是“怎么做”。
主要组成部分：
▶简要说明
▶前提条件
▶后置条件
▶事件流程（主事件流、其他事件流、错误流）
（这里就直接放在下面了）

简单分析一下：
①用例名称：对应图中用例的名字（就是圈圈里的内容）
②参与者：对应用例图中的参与对象
③假设：一般是完成了某项功能用例为标准（个人认为这个点可有可无）
①~③就是对应的“简要说明”部分
④前置条件：列出用例执行之前必须满足的条件
⑤后置条件：用例执行完毕后必须满足的条件，就是执行完该活动系统需要做的其他事情。
⑥主事件流：从用户角度描述执行用例的具体步骤，对于与系统交互的部分，一般是用户执行一次，系统反馈一次交替进行。比如下图：

⑦备选事件流：一般是系统遇到非正常情况下的一些异常处理，非理想操作的应对方式
⑥~⑦对应“事件流程”部分
//在写描述的时候需要注意一下：
·内容是可见的，不涉及细节实现
·语句是主动的（比如：会员提交用户名√ 系统获取用户名×）
·每一句都要朝目标迈进
（比如：用户登录系统 √
用户输入帐户->用户输入密码->用户登录 ×
一气呵成即可 ）
·不要涉及界面信息（这点上面的例子就不是很好，像点击XX按钮这样的内容就省省吧，直接点命点击完之后的目的就行了）

☬关联关系
表示参与者用例之间进行通信（就是下图的关系没错了）
就是参与者执行一些用例的直接关系 简单粗暴
而且避免用例图出错，即使全部画成参与者与用例的关联关系也无伤大雅，虽然很简单，但是它不错

☬泛化关系
该种关系用于用例与用例之间，和面向对象的类的泛化（继承）关系相似
如下图所示：

☬包含关系
一个用例可以简单地包含其他用例具有的行为，并把它所包含的行为作为自身行为的一部分，这称作用例间的包含关系

包含用例（客户用例）执行，则被包含用例（提供者用例）必须执行
如果两个以上的用例有大量一致的功能，则可以将这个功能分解到另一个用例中，其他用例可以和这个用例建立包含关系

如上图三个用例间的关系，查阅两种报表的共同功能是预览报表

☬扩展关系
基础用例提供扩展点以添加新的行为

▶基础用例没有扩展用例也是完整的用例
▶基础用例被执行时，一般不会涉及扩展用例，只有特定的条件发生，扩展用例才可能被执行，这是与包含关系的差别

//到这里用例图的基本内容就总结完了，还需要参考一些实例来从上层视角明白用例图的内容，这里就不再举例了，可以参考各个论坛的内容，或者书上的内容（虽然书上的内容也未必是对的，但是可以帮助理解）
补充（概念）：
·用例图是表达用例和活动者及其之间关系的载体
·用例图和用例关系在编写用例工作中是次要的。用例是文本文档。编写用例意味着编写文本。文字描写才是重点。

用例图汇总：

三、UML顺序图

之前我们总结过：
建模：从本质上讲是标准而规范的设计描述手段

静态和动态建模
静态模型：包，类，属性和方法特征标记的定义，例如类图，包图，部署图
动态模型：设计逻辑，代码行为或方法体

---

首先明确一下交互图的概念：
交互图：是一种详细表示对象之间以及对象与系统外部的参与者之间动态联系的图形文档。交互图有两种形式，即顺序图和协作图。
交互图是用来描述对象之间的动态协作关系以及协作过程中的行为次序，它常常用来描述一个用例的行为，显示该用例中所涉及的对象和这些对象之间的消息传递情况。
一般一个用例需要一个或多个顺序图或协作图
顺序图和协作图从不同的角度表达了系统中的交互和系统的行为，它们之间可以相互转化。
顺序图着重描述对象按照时间顺序的消息交换
协作图着重描述系统成分如何协同工作

---

进入正题：
先看看顺序图长什么样子：

首先明确一点：在大多数情况下顺序图是对一个用例的描述，前面在用例图中介绍过用例了，其实可以理解为一个业务，而顺序图就是描述了这个业务在执行过程中用到了哪些对象，它们之间是怎样的关系，怎样的调用关系。感受一下，这是一个动态的过程。
顺序图是一个二维图形：
在顺序图中：
水平方向为对象维沿水平方向排列参与交互的对象
竖向方向为时间维沿垂直向下方向按时间递增顺序列出各对象所发出和接收的消息
水平轴上的对象间的相互顺序并不重要。
顺序图不表示对象间的关联关系。

---

顺序图的组成：
☫对象
☫生命线
☫消息
☫激活
☫对象
对象的存在形式：

☫生命线
生命线（是一条时间线）是一条垂直的虚线，表示顺序图中的对象在一段时间内的存在。每个对象的底部中心的位置都带有生命线
生命线表示对象存在的时间，在顺序图中生命线表示为从对象图标向下延伸的一条虚线

☫消息
消息定义的是对象之间某种形式的通信，它可以激发某个操作、唤起信号或导致目标对象的创建或撤销。
消息可以用于在对象间传递参数。
消息可以是信号，也可以是调用。

标准的消息：▶调用消息
▶异步消息
▶返回消息
▶自调用
▶调用消息
调用消息的发送者把控制传递给消息的接收者，然后停止活动，等待消息接收者放弃或返回控制

调用消息的接收者必须是一个被动对象
一般调用消息必有一个配对的返回消息

▶异步消息
异步消息的发送者通过消息把信号传递给消息的接收者，然后继续自己的活动，不等待接收者返回消息或控制，常用于并发。

▶返回消息

表示消息的返回，一般与调用消息成对出现
▶自调用
就是对象自己调用自己方法

上面这四种消息很标准但是不全面，下面总结一些实在常用的，简单的消息类型：
个人认为目前最常用的就是上面的这四种，而且道理用起来很简单：

简单消息：可以说是消息，其实也是操作，很多时候在进行业务(用例)的时候我们并不需要调用什么方法，只是简单的传递数据而已，那么就用简单消息即可。
如图所示，参与者与参与者之间肯定不存在调用关系，参与者与类对象之间也许只是传递一个物品的信息。（注意参与者是一个对象来存在的）

调用消息：这个蛮重要的，是顺序图中常用的消息类型，一般是对象之间的调用，比如下面这个图，3和5都是调用关系，在写顺序图的时候我们要实时与代码结合，要清楚代码的运行方式和顺序，在什么时候，什么对象，调用什么方法，注意调用消息上面标注的是方法，是调用下一个对象的什么方法的消息内容，比如其中findBook是BookDao类对象的方法，update()是DBUpdate的方法

异步消息和返回消息：
需要注意的是返回消息和调用一般成对出现，调用消息的主动对象需要等待接收者的反馈，也就是返回消息才能继续进行。
这个就不多介绍了和之前说的内容一样

☫激活

激活表示该对象被占用以完成某个任务，去激活指的则是对象处于空闲状态、在等待消息
在UML中，为了表示对象是激活的，可以将该对象的生命线拓宽成为矩形。其中的矩形称为激活条或控制焦点，对象就是在激活条的顶部被激活的，对象在完成自己的工作后被去激活。
简单来说就是对象在这次业务中的活动表现，一般在调用消息的指向对象生命线中会出现激活条，毕竟要调用该对象的某个方法，但是某个激活条有多长就是代表对象的活动时间长短（没有激活条时期的对象就是在打酱油）。
//到此顺序图的基础内容介绍的差不多了，但是如何使用还是需要看一些例子
♦补充（小知识点）：
1.sequence图和collaboration图描述的是对象之间的消息发送关系，而不是类之间的关系
2.将对象置于顺序图的顶部意味着在交互开始的时候对象就已经存在了，如果对象的位置不在顶部，那么表示对象是在交互的过程中被创建的。
3.顺序图横轴表示对象，纵轴表示时间。（划重点！划重点！划重点！）
4.对象的存在分为三种类型：
5.应该先有需求阶段的顺序图，后有类图

四、UML领域模型和类图

领域模型和类图
建模流程：

---

领域模型
领域模型是对领域内概念类或现实世界中对象的可视化表示，也称为概念模型。是更为完整的业务模型的一个特例。从UML的表示法角度，领域模型被描述为一组没有定义操作的类图（概念类、关联、属性）。领域模型中的领域类通常只有属性，没有或很少的操作。
领域模型是对真实世界中概念类的表示，而不是软件对象的表示。（划重点！）
为模型建立适当的属性与关联。领域模型表现的是概念类之间的数量关系，对于数量关系的理解可以理解为与ER图中相似。
先上个领域模型图找找感觉：

领域模型中核心部分自然就是概念类的确定，因为领域模型属于分析阶段的产物，还没有进一步的实现，所以很多内容都属于猜想阶段，但是如何尽可能准确地找到系统需要的类，进而找到概念类呢，有以下几个标准：业务对象、真实世界中的对象、事件。
在找到概念类之后，需要确定的剩余内容就是关联关系了，领域模型说起来就是两步走：找到概念类+建立关联（多是数量关联）
最简单的例子：

当然关联是可以有方向的：关联可以是单向的，也可以是双向的

基本常用的关系上面两种够用了，但是数量关系是根据需求定义的：
定义了类A有多少实例可以和类B的多少实例关联（指标是在特定的时刻（而不是在某个时间跨度内）有效关联的实例数量）

♦补充：
1.概念类的属性的确定根据需求，还是那句话，从代码角度思考一下，当然属性可以配置一定的类型。
2.确定概念类比找到关联更重要
3.领域模型构建时，主要的时间要花在确定概念类上，而不是找关联上
4.关注那些需要保持一段时间的关联
5.发现概念类比发现关联更重要
6.太多的关联将会使领域模型变得混乱，而找出这些关联需要消耗太多时间，效益却不大
7.避免显示冗余的或者可派生的关联

类图

显示系统中各个类的静态结构，一个类图说实话不可能包含一个系统的所有类，但是可以包含核心类，类图和领域模型差别很大，首先领域模型表现的是概念类的数量关系，然而类图表现的是类的依赖等关系，而且在名称和属性的基础上，类图需要有方法。
类图属于静态建模，类图描述类和类之间的静态关系。与数据模型不同，它不仅显示了信息的结构，同时还描述了系统的行为。
类图中可以包含接口，包，关系等建模元素，也可以包含对象，链等实例。
类图的组成元素虽然直观上来看还是类，但是关系复杂，所以类图的组成元素就相对较多：
▶类
▶接口
▶依赖关系
▶泛化关系
▶关联关系
▶实现关系

//接下来逐个总结：
▶类
这个概念不用多介绍了，面向对象的核心内容，不知道类的话，就可以洗洗睡了~

在类图中的存在形式是：名称部分、属性部分和操作部分（核心就是这三点）
名称部分：一定要是名词
属性：描述类特有的一些性质（可以有，当然也可以没有）
属性的组成：可见性：公有“＋”、私有“－”、受保护“＃”
属性名
类型：整型、布尔型…
初始值
属性字符串:指定关于属性的其他信息
操作：对类的对象所能做的事务的抽象，返回类型、名称和参数一起被称为操作签名。
操作的组成：可见性：公有“＋”、私有“－”、受保护“＃”、包内公有“～”
操作名：用来描述所属类的行为的动词或动词短语
参数表：就是传入参数，是可选的， 定义方式：“名称：类型”
返回类型：可选的
属性字符串：在操作的定义中加入一些除了预定义元素之外的信息。
小知识点：类的操作最终目的可以分为两类：一类是操作的结果引起了对象状态的改变，状态的改变也包括相应的动态行为的发生。另一类是为服务的请求者提供返回值。
职责&&约束&&注释
职责：类或其他元素的契约或义务
约束：指定了类所要满足的一个或多个规则
注释：注释可以包含图形也可以包含文本

  职责                约束                      注释

---

▶接口
什么是接口也不在解释了，直接上图：

接口类：

类之间的关系
消息的传递大多数情况下是以函数调用的形式实现的，有时也会通过直接访问目标对象的成员变量的形式实现。
▶依赖关系
如果两个类的对象之间存在着下面的情形，且两个类之间不存在结构方面的联系（例如：供应类以成员变量的形式作为客户类的一部分），就可以建模成为具有依赖关系，这些情形是：
♦客户类访问定义在供应类内部的值(常量或变量)
♦客户类的操作启动了定义在供应类内的操作
♦客户类的返回类或参数是供应类的实例
顺序图中的两个对象，如果存在着消息的发送，且它们之间又没有结构方面的连接，就可以在类图上用依赖关系对它们建模

简单来说（不是很精确）：如何确认依赖关系？
类A与类B，其中类A对于B对象的使用出现在方法体内，方法参数或者返回值的时候，类A依赖于类B。

▶泛化关系
泛化关系表示的两个类之间，简单来说就是继承关系（应该这一句话就可以解决对泛化基本理解的问题了）

泛化主要用途：多态、继承

▶关联关系
依赖关系和泛化关系反映的是类之间在动态行为方面的联系
在软件系统中还存在着大量的结构方面的联系
关联是模型元素间的一种语义联系，它是对具有共同的结构特性、行为特性、关系和语义的链接的描述。
上面所说的关联关系覆盖面积比较大，但是在考试中不会这么反应，简单来说：类A与类B，其中类A对于B对象的使用出现在属性的时候，类A关联于类B。
关联关系在实现为程序设计语言源代码时，会有对应的映射
通常，当把两个有关联关系的类映射为特定的程序设计语言代码时，每一个类都会被定义为可以引用对方的类的对象的成员变量
这个成员变量视对关联关系的修饰的不同，可能会采取不同的形式，如：
它可以指向对方的类的指针
也可能是对方类的对象
一个关联至少有两个关联端，每个关联端连接到一个类
关联可以有方向，关联可以是单向关联或双向关联


关联关系：
♦名称
♦角色
♦多重性
♦聚合关系
♦组合关系
♦导航性
♦名称
关联的名字通常是动词或动词短语，来描述关联的作用

当然描述关联之间的关系不止用名称，还可以使用关联类来表示关系：

♦角色
关联两端的类可以某种角色参与关联。

♦多重性
角色还具有多重性，表示可以有多少个对象参与该关联

---

♦聚合关系
表示整体与部分关系的关联，描述了“has a”的关系。

---

♦组合关系
聚合关系中的一种特殊情况，是更强形式的聚合，又称强聚合。
组合关系中的整体与部分具有同样的生存期（也就是同生共死）

♦导航性（略）

---

UML中有三种主要的类版型：Boundary，Entity，Control。
边界类(Boundary class)位于系统与外界的交界处，包括所有窗体(form)、报表(report)、与外部设备的接口(interface)，以及与其它系统的接口等。
UML中边界类的表示：

每个actor/use case交互至少要有一个边界类。但并非每个actor/use case对要生成唯一边界类

实体类(Entity class)保存要放进持久存储体的信息。
UML中实体类的表示：

控制类(Control class)是负责其它类工作的类。
UML中控制类的表示：

补充：
1.类不是孤立存在的，它的对象将参与一个或多个交互
2.类的语义是对此对象代表的事物的性质的描绘，通过对事物性质的描绘，可以记录对象在交互过程中状态的变换，并可进一步决定对象在此状态下的行为
3.抽象类是不能直接产生实例的类。
4.UML中把类名写成斜体字来表示抽象类。
5.抽象类与接口不同：抽象类可以含有属性，接口不含有属性
类图的抽象层次：类图可分为三个层次，即概念层，说明层和实现层（了解一下）

概念层：类图描述应用领域中的概念
说明层：类图描述软件的接口部分，而不是软件的实现部分
实现层：类图才真正考虑类的实现问题，揭示实现细节