UML绘图

1.UML概述

UML（统一建模语言）并不是一种科学上严谨的方法工具，但是被广泛的使用。说它不严谨主要是因为，UML是用自身定义自身，就是说一个定义不是由别的定义来定义，而是由自身来定义，这就很奇怪。所以，数学家可能比较不理解UML这个东西，因为它是用自身定义自身。

UML是一种广泛使用的建模语言，它在过去的几十年中经历了多次版本更新和修订。虽然UML最初的版本包含了一组基本的建模元素，但随着时间的推移，新的元素和概念被不断引入，以满足不断发展的软件建模需求。

然而，自从UML 2.0版本发布以来，UML的元素并没有持续增加。UML 2.0定义了一组完整的建模元素，包括类、接口、用例、活动、状态机、序列、协作等，这些元素已经能够涵盖大多数软件建模的需求。之后，UML 2.1、2.2、2.3等版本的更新主要是在细节和规范方面进行了一些修订和改进，但并没有引入大量新的元素。

虽然UML的元素没有持续增加，但由于软件开发的不断发展和变化，UML的应用也在不断变化和演进。例如，现代的软件开发倾向于更加注重领域驱动设计和面向服务的架构，这些新的概念和方法也会在UML的应用中得到体现。因此，UML的应用和实践仍在不断发展和演进。

UML中的元素主要包括：事物，关系，图。顾名思义，关系就是事物之间的关系，事物和其关系构成图。根据下图可知，事物有很多分类，关系也有分类，图也有分类。

2.用例模型

用例模型是帮助我们捕获用户需求的的工具。用例模型由参与者、用例组成。

2.1 参与者（Actor）

Actor是属于我们要开发的系统（以下简称系统）的外面，Actor并不属于系统，但是又要和系统发生交互 。比如Actor可以给系统提供一些数据，或者希望系统给它提供服务。分类用例模型中有哪些参与者就可以确定系统需要哪些功能。也是需求分析的一部分。

Actor可以是人，物，其它的子系统。Actor在UML元素中用上图表示。 比如说，我们要开发的系统是教务系统，教务系统中有人，学生，老师等参与者。但是教务系统又要和学校的其它系统有交互，比如说学校的财务系统、人事系统等。这里的财务系统和人事系统也是参与者，属于其它子系统。

那么在系统的需求分析阶段如何寻找系统的参与者呢？

主要考虑以下几个问题：

1、谁使用系统?
2、谁安装、维护系统？
3、谁启动、关闭系统？
4、谁给系统提供信息、从系统中获取信息？
5、我们要开发的系统与哪些其它子系统有关联？
6、在系统交互中，谁扮演什么角色？
7、内/外部定时器

如果高明白了以上几个问题，系统的Actor就可以确定了。

2.2 用例

上面分析了系统的参与者（actor），每个参与者都会有1个或者多个需求。不同的参与者可能会有相同的需求。把这些需求分门别类，形成一个个的用例，每个用例是处理一种需求的操作组合。

因此，用例就是：系统为响应参与者引发的一个事件而执行的一系列的处理/动作，而这些处理应该为参与者产生一种有价值的结果。这些处理/动作应该还能够处理一些Exception。

2.3 参与者和用例之间的关系

2.4 如何寻找用例？

1、参与者希望系统提供什么样的功能？
2、系统是否存储和检索信息？
3、当系统改变状态时，是否通知参与者？
4、是否存在影响系统的外部时间？是哪个参与者通知系统这些外部事件？
5、哪个参与者触发了活动？

如果搞明白上面的问题，就可以直到用例是什么了。

2.5 用例模型中的关系

用例模型中的参与者和用例都是UML中的建模元素，那么是建模元素就会有关系。关系主要有以下三种，即：用例和用例之间的关系、用例和参与者之间的关系、参与者和参与者之间的关系。

2.5.1 用例和用例之间的关系

1、泛化关系（继承关系）
这一点类似于OOP中的继承。只是叫法不一样。如下图所示。

2、包含关系（include）
包含关系是，一个用例A必须包含另外一个用例B才能正常工作。否则A无法工作。比如在写C++代码的时候，有一个 main.cpp 文件（设为用例A，用来打印参与者给出的字符串），该文件必须包含另外一个用例B（iostream）才能完成打印功能。

3、拓展关系（extend）
拓展关系是一个用例在执行的过程中，可能会用到另外一个用例。

以上三种关系由下图展示。

2.5.1 用例和参与者之间的关系

关联关系：用实线表示

2.5.1 参与者和参与者之间的关系

泛化关系：实线+空心箭头

这一点类似于用例和用例之间的关系，如上图所示。

2.6 对用例的描述

用例描述是针对每一个用例的。用例描述有其相应的规范。常用规范如下表所示，当然了，不一定非要是下面的写法，也可以是别的写法。

条目	条目描述
总结	描述用例的角色、所要达到的目的、对用例总结
参与者列表	列出使用该用例的所有参与者
前置条件	激活该用例的前置条件
描述	描述用例尽可能多的所有细节
后置条件	当用例执行完毕后，即参与者与用例断开后，用例需要做一些完善工作，有查缺补漏的作用
异常处理	异常处理，类似于各种编程语言中的exception，比如C++中的try语句等

2.6 用例模型总结

通过以上叙述，可以知道，关于用例模型的知识点主要包括以下几个内容：

1、系统边界
2、参与者
3、用例
4、用例图
5、用例描述

3 活动图

用例模型和活动图是相互补充的。

3.1 活动图的基本建模元素

1、活动图的开始、结束、对象

其中的对象是活动图过程中，产生的具体的东西，就像像OOP中的对象一样，是个具体的实体。

2、活动节点和分支

每个活动节点最终又可以被分为不可再分的原子动作（Action).

分支，有一个输入流，有多个离去流，每个离去流都要有条件。

3、分叉、汇合、泳道

规则是，活动部分是不能跨泳道的，从常识来讲，一个活动不能同时被两个泳道来做，如果要两个泳道来做，那就不是一个活动了，应该是两个活动。

分叉是一个动作执行完毕后，可以分成两个动作同时进行，类似于并行操作。

汇合是，两个动作必须都做完，汇合到一点后，才能继续往下执行，这个类似于进程同步。

3.2 活动图总结

1、描述一项任务执行过程中所完成的工作（动作）
2、描述对象的内部工作
3、显示如何执行一组相关的动作，以及这些动作如何影响它们周围的对象
4、显示用例的实例如何执行动作以及如何改变对象的状态
5、说明一次业务流程中的人（参与者）和对象是如何工作的

活动图与用例模型互为补充，主要用于需求分析阶段

活动图中的基本要素包括：活动（动作）、转移、分支、分叉和汇合、泳道、对象流等。

4 类图（静态）

用例图和活动图是软件分析阶段要做的事情，是帮助我们捕获需求的。需求知道了之后，怎么做呢？那就是用类进行设计了。

4.1 类之间的关系

1、依赖关系
2、关联关系
3、继承\泛化关系
4、实现关系

5、对以上四种关系的修饰
1）名称及方向

2）角色

3）可见性

其中的加号（+）是一种可见性修饰符，即——public。
4）多重性

5）聚合\组合
组合和聚合的区别就是，组合说是，当整体不消失/死亡/不在的时候，部分也将不复存在，聚合是，当整体消失/死亡/不在的时候，部分可以存在，也可以不存在。

6）关联类

4.2 类图总结

类是一种抽象，是对用例和活动图的实现。

5 顺序图（动态，交互图的一种）

用例图、活动图给出了需求分析，类图给出了静态的解决方案。那么解决方案是否可行呢，我们又不可能区写代码去验证，那么就需要顺序图来解决。

5.1 消息

5.1.1 同步消息

同步消息是指，一个对象在执行的过程中，需要另外一个对象来来执行一个方方法，并等待它返回一个结果后，才能继续执行。在等待的结果返回前，主进程处于阻塞状态。

5.1.2 异步消息

和同步消息不同的是，异步消息不会阻塞主进程，还有就是会有一个消息队列。

5.2 交互图

5.3 操作

5.4 代码和顺序图的映射

5.5 顺序图总结

顺序图可以动态验证类模型的可行性。

顺序验证的某一个功能，属于某个用例描述的功能中的一部分，又被成为用例实现。

顺序图从上到下，反应了各对象相互协作的时间顺序。

6 通信图（交互图的一种）

交互图有两种，一种是顺序图，一种就是通信图。

通信图和顺序图在某些情况下可以相互转化。

7 状态图（状态机）

在考虑某个实体（这里的实体不同于类实例化出来的实体）的状态的时候，单个实体是多大粒度的实体？比如，一辆汽车，它作为一个单个实体，它的状态有行驶状态，停止状态，缺油状态，故障状态等等。但是，组成汽车又有很多的零部件，这些零部件也有自己的状态。比如，进入汽车后，可以把发动机作为一个整体，把电路系统作为一个整体，把油箱作为一个整体等等。

以上所有内容有待继续完善！！！！！！！！