软件工程项目这周要交一个设计文档，其中涉及UML图的画法，根据上课给的ppt做一个记录。
有关于UML的介绍在这里不再赘述，直接开整！
UML的基本模型
当然必要的介绍必不可少，这里先介绍UML的基本模型，之后的介绍将按照下图的顺序进行。
之后简单介绍一下面向对象的程序设计原则。这部分是我对之前知识的一个复习，想看UML的朋友可以直接跳到下一章。
对象
对象的概述
对象是包含现实世界物体特征的抽象实体，它不仅表示具体的事物，还可以表示具体的规则或者事件。举个例子，公费医疗报销系统中的报销用户就是一个对象。
对象具有状态，也就是对象还拥有属性。举例来说，报销用户有姓名、年龄、单位等等状态。
对象中还包括操作，我们称之为方法，操作用来改变对象的状态。举例来说，报销用户中的操作可能是对自己个人信息的修改。
对象的分类
对象大体可以分为5类：分别是物理对象，角色，事件，交互和规格说明。
-
物理对象
多表示现实生活中最容易被抽象的对象，比如报销系统中的某个单位的学生或者老师就是物理对象； -
角色
举例来说，报销系统中，某个单位的学生老师的角色都是报销用户。 -
事件
这里的理解不太确定，个人理解是事件对象的作用是对出现的事件相关的状态进行存储，以便后续操作中读取。 -
交互
交互表示两个对象之间的关系。它的实际应用是在实体之间是多对多的关系时，使用交互对象可以简化为两个一对多的关系。个人理解，交互关系在Java中表现为interface，它可以防止在不同的类中多次实现相似的方法。 -
规格说明
表明组合某些实体时的要求，可以理解为config项。
封装，继承与多态
我们在面向对象中广泛提到的类，其实可以理解为人为定义的、使计算机构造对象的规则。这里介绍的封装，继承与多态是比较笼统的，之后会专门写一篇随笔介绍（咕咕咕？）
封装
使用抽象数据类型将数据和基于数据的操作封装在一起。借用一个上课的例子，对于一个智能手机，大多数用户只需要学习如何使用手机即可，不需要学习如何维修手机，所以有关手机维修的属性和操作就不必对用户公开。
Java提供了四种控制修饰符控制方法和属性访问的权限：
-
public：对外公开
-
protected：对子类课同一个包中的类公开
-
private：只有类本身可以访问，不公开
-
没有修饰符号：向同一个包的类公开
理论上一个优秀的面向对象设计，类属性应均为private
继承
最主要的是解决代码复用问题，当多种对象有相似的属性和方法时，要从这些类中尽可能的抽象出父类，父类中定义这些相同的属性和方法，子类只需要定义自己独有的属性和方法即可。Java中使用extends语句实现继承。
多态
多态的知识在这里不进行介绍，详见另一个随笔（咕咕咕？）
UML的事物
事物是模型中最具代表性的部分的抽象。
结构事物
结构事物是UML模型的静态部分，包括类，主动类，接口，对象，用例，参与者，协作，构件，节点等等。
- 类：下图表示了一个类。
-
主动类（活动类）：实例应为一个或多个进程或线程，可以和其他类元素的行为并发工作。
-
接口：描述了类或组件对外的，可见的操作，是一组操作的描述，而不是具体实现。
-
对象：类的实例，其名字应加上下划线，对象的属性需要明确给出。
-
用例：描述一组动作序列，表示系统想要实现的行为。
-
参与者：也叫角色，表示与系统有信息交互的部分，可以是人，软件，硬件等等。
-
协作：描述一组角色实体和其他实体如何通过协同工作完成一个功能或行为。
-
构件（组件）：描述一些逻辑元素的物理包。
-
节点：代表一种可计算的资源，通常具有记忆能力和处理能力。
行为事物
行为事物是UML模型的动态部分，包括交互和状态机两部分。
-
交互：交互由在特定的上下文环境中完成一定任务的一组对象之间传递的消息组成。
-
状态机：描述一个交互或者一个对象在生存周期内响应事件所经历的状态序列以及记录他们对事件的响应。说人话就是描述一组类之间的协作行为。
分组事物
分组事物是包，包把模型元素组织成组。
注释事物
解释UML模型的任何UML元素
UML的关系
总的关系表示如图所示。接下来依次介绍：
泛化关系
泛化是一般类和特殊类之间的继承关系。注意，泛化所针对的是类并不是类的实例。进一步的，泛化可进一步划分为普通泛化和受限泛化。
一个小技巧，泛化关系可以表示为is-a，即SUV is a car，那么car就是SUV的一个泛化。
-
普通泛化：允许单继承和多重继承。
-
受限泛化：一般存在四种约束，交叉（overlapping）、不相交（disjoint）、完全（complete）和不完全（imcomplete）。
实现关系
implement是泛化关系与依赖关系的结合，强调继承一个抽象类（abstract或者interface），而泛化关系继承一个具体类。
关联关系
描述了两个或者多个类的治理之间的连接关系。可以分为普通关联，限定关联，关联类，聚合以及导航。
-
普通关联：
是最常见的关联关系。又可以分为二元关联和多元关联。二元关联的多重性描述了一个关联两端的类实例个数的对应关系。关联端点出还可以附加角色名，同时也允许类自身关联。多元关联指三个或者三个以上的类之间的关联。
-
限定关联：
限定关联通常用在一对多或者多对多的关联关系中，可以把多重性从一对多变成一对一，或把多对多简化为多对一。具体实现方式就是把限定词放在关联关系末端。 -
关联类：
需要对关联关系进行详细的定义，这时使用关联类。 -
聚合：
聚合是一种特殊的关联，描述了整体与部分之间的关系。大体可以分为共享聚合以及复合聚合。共享聚合：部分实例可以同时参与多个整体实例的构成。举例来说，一个演员可以同时在多个剧组中。演员和剧组构成共享聚合。
复合聚合：部分实例完全依赖于整体实例，即部分实例与整体实力共存。举例来说，一个窗体中的按钮与窗体的关系就是复合聚合。
-
导航：
导航是关联关系的一种特性，通过关联的一个端点上加箭头表示导航方向。通俗理解就是可以由一个类的对象得到另一个类的全部对象。
依赖关系
描述两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。通俗地讲，一个类的实现需要另一个类的协助，举例来说，现代人这个类依赖计算机这个类。
UML图
啊累死了。。。虽然说不讲理论，还是扯了这么多QAQ。现在正式开始！下图清晰的展示了UML图之间的关系。
用例图
最基本，最好画的图！描述了执行者所理解的系统功能。多用于需求分析阶段。在UML中，一个用例模型由若干个用例图来描述，用例图的主要元素是用例和执行者。
用例图是包括执行者、由系统边界（一个矩形）封闭的一组用例，执行者和用例之间的关联、用例间关系以及执行者的泛化的图。
用例（use case）是对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。
用例之间可以有泛化、扩展、使用（包含）三种关系。
泛化关系可以理解为OO中的继承，某些子用例与父用例大体上相似，只有一些地方有差异。
扩展关系其实是细化功能的一个表现，这里还是举个例子，比如系统支持用户导出或者打印查询到的记录，这里不管是导出还是打印，其查询操作都是一样的，因此这两个用例就可以作为查询这个用例的扩展用例。
包含关系是为了防止系统功能的过细设计。举例来说，比如我们要维护一个数据库，我们可以设计增删查改四个用例，但是在一个大系统中这样用例划分太细了，所以可以把维护数据库作为一个用例，而增删查改作为其中包含的四个用例。
其实我们可以看到，这三种关系之间的界定不是很清楚，有人从用例关系优化侧重点这个角度进行了区分：
-
泛化侧重子用例之间的互斥
-
包含侧重表示被包含用例对Actor提供服务的间接性
-
扩展侧重表示扩展用例的触发不确定性（个人理解扩展关系不会影响系统的正常工作，属于锦上添花的用例）
在拿到两个用例时，用这三个问题去判断即可。下面是根据本次软工项目画的UML用例图。
类图
类图描述类和类与类之间的静态关系，它是从静态角度表示系统的，因此类图属于一种静态模型。类图是构建其他图的基础，没有类图就没有状态图、协作图等其他图，也就无法表示系统其他方面的特性。
在类的建模中可以使用关联、聚合和泛化（继承）关系。
顺序图
顺序图描述对象之间的动态交互关系，着重表现对象间消息传递的时间顺序。
状态图
状态图描述一个特定对象的所有可能的状态以及引起状态转换的事件。大多数面向对象技术都用状态图表示单个对象在其生命期中的行为。一个状态图包括一系列状态、事件以及状态之间的转移。
构件图&部署图
啊真的是被这个东西搞蒙了。。。我现在都不知道自己在画啥了QAQ。
总结
理论果然还是看不懂，还是得上手实操才有效。。。文中的UML图难免出错，还请不吝赐教！
啊是真的难受，明天又要早起。。。