UML
类图
类图的定义：是显示一组类、接口、协作以及它们之间关系的图。
类图主要包含7种元素：、类、接口、协作、依赖关系、泛化关系、实现关系、关联关系。
类图：包、子系统，用来把模型元素聚集成更大的组块。
类图：约束、注解
类
1.类是一组拥有相同的属性、操作、方法、关系和行为的对象地描述符。
2.类定义了一组有着状态与行为的对象。类的状态由属性和关联来描述，个体行为由操作来描述，对象的生命周期则由附加给类的状态机来描述。
3.在UML中，类表达成一个有三个分隔区的矩形。其中顶端显示类名，中间显示类的属性，尾端显示类的操作。
类——属性
可见性：描述了该属性在那些范围内可以被使用。
可见性 | 英文限定符 | UML标准图示 | Rose图示 | 说明 |
公有 | public | + | 其他类可以访问 | |
私有 | private | - | 只对本类可见，不能被其他类访问 | |
保护 | protected | # | 对本类及其派生类可见 |
类型：属性的数据类型，可以系统固有，也可以用户自定义。属性的类型决定了该属性的所有可能取值的集合。
类——操作
可见性：同样描述该操作在那些范围内可以使用，与属性的可见性相同。
参数列表：是一些按照顺序排列的属性定义了操作的输入。例如：oper(out arg1:int, arg2:double=3.2)
返回类型即回送调用对象消息的类型。void关键字表示无返回值。
特性是对操作性质的约束说明。
类——职责
职责是类的契约或责任。当创建一个类时，就声明了这个类的所有对象具有相同种类的状态和相同种类的行为。在较高的抽象层次上，这些相应的属性和操作正式要完成类的职责的特征。
类的职责是自由形式的文本，在非正式的类图中，可以将职责列在类图操作下的另一分割栏中。
接口
1.接口是一个被命名的操作集合，用于描述类或组件的一个服务。
2.接口不包含属性与方法实现，但可以有一些操作。接口的所有内容都是公有的。
3.接口代表了一份契约，实现该接口的类元必须履行它。
4.在UML中，接口由一个带名称的小圆圈表示；也可以表示为带有<<interface>>构造型的类
类图中的关系
UML中最常用的四种关系，即关联关系、泛化关系、依赖关系和实现关系。
类图中的关系——关联关系
1）关联的实例被称为链，每个链由一组有序或无序的对象组成。
2）关联关系靠近被关联元素的部分称为关联端，关联的大部分描述都包含在一组关联端的列表里，每个端用来描述关联中类的对象的参与
3）二元关联、自关联、N元关联。
注意要点
关联名称：放在关联路径的旁边，但远离关联端。
角色：放在靠近关联端的部分，表示该关联端连接的类在这一关联关系中担任的角色。角色名上也可使用可见性修饰符号。
多重性：放在靠近关联端的部分，表示在关联关系中源端的一个对象可以与目标类的多少个对象之间有关联。
导航性：一个布尔值，用来说明运行时刻是否可能穿越一个关联。
限定符：是二元关联上的属性组成的列表的插槽，其中的属性值用来从整个对象集合里选择一个唯一的关联对象或者关联对象的集合。
约束：关联间的约束关系。
[现实例子]
比如客户和订单，每个订单对应特定的客户，每个客户对应一些特定的订单；再例如公司和员工，每个公司对应一些特定的员工，每个员工对应一特定的公司。
派生关联：属于一种派生元素。它不增加语义信息，只是一种可以由两个或两个以上的基础关联推算出来的虚拟关联。
两种特殊的关联关系：聚合关系与组合关系
1.聚合关系：描述“整体-部分”的关联关系
聚合关系没有改变整体与部分之间整个关联的导航含义，也与整体和部分的生命周期无关。
2.组合关系：描述“整体-部分”的关联关系
组合关系中的部分要完全依赖于整体。
关联与聚合的区别
(1)关联关系所涉及的两个对象是处在同一个层次上的。比如人和自行车就是一种关联关系，而不是聚合关系，因为人不是由自行车组成的。
聚合关系涉及的两个对象处于不平等的层次上，一个代表整体，一个代表部分。比如:电脑和它的显示器、键盘、主板以及内存就是聚集关系，因为主板是电脑的组成部分。
(2)对于具有聚集关系（尤其是强聚集关系）的两个对象，整体对象会制约它的组成对象的生命周期。部分类的对象不能单独存在，它的生命周期依赖于整体类的对象的生命周期，当整体消失，部分也就随之消失。比如张三的电脑被偷了，那么电脑的所有组件也不存在了，除非张三事先把一些电脑的组件（比如硬盘和内存）拆了下来。
聚合与组合的区别
聚合关系：涉及的两个对象处于不平等的层次上，一个代表整体，一个代表部分。比如:电脑和它的显示器、键盘、主板以及内存就是聚集关系，因为主板是电脑的组成部分。
组合关系：代表整体的对象负责代表部分对象的生命周期。公司不存在，部门也没有意义了。再例如：人和五脏六腑、四肢的关系。
类图中的关系——泛化关系
泛化关系定义为一个较普通的元素与一个较特殊的元素之间的类元关系。其中描述一般的元素称为父，描述特殊的元素称为子。（子类是父类的继承，则父类就是子类的泛化。）
通过泛化对应的继承机制使子类共享父类的属性和操作，小了模型的规模，同时也防止了模型的更新所导致的定义不一致的意外。
泛化关系的特征：
传递性：一个类子类的子类同样继承了这个类的特性。在父方向上经过了一个或几个泛化的元素被称为祖先，在子方向上则被称为后代。
反对称性：泛化关系不能成环，即一个类不可能是自己的祖先和自己的后代。
泛化关系的两种情况
单继承：每个类之多能拥有一个父类。
编程语言：C#、Java等
多重继承：子类可以有多个父类并继承了所有父类的结构、行为和约束。
编程语言：C++等
类图中的关系——依赖关系
依赖关系表示的是两个元素之间语义上的连接关系。对于两个元素X和Y，如果元素X的变化会引起对另一个元素Y的变化，则称元素Y依赖于X。其中，X被称为提供者，Y被称为客户。
[现实例子]比如说你要去拧螺丝，你是不是要借助(也就是依赖)螺丝刀(Screwdriver)来帮助你完成拧螺丝(screw)的工作。
对于类图而言，主要有以下需要使用依赖的情况：
1）客户类向提供者类发送消息。
2）提供者类是客户类的属性类型。
3）提供者类是客户类操作的参数类型。
类图中的关系——实现关系
实现关系用来表示规格说明与实现之间的关系。在类图中，实现关系主要用于接口与实现该接口的类之间。
一个类可以实现多个接口，一个接口也可以被多个类实现。
实现关系的两种表示法：
a.当接口元素以带构造型的类的方式表示时，用虚线三角形箭头表示。
b.当接口元素以小圆圈方式表示时，用实线表示。
综合例子：
补充
涉及类的其他概念——抽象类
抽象类即不可实例化的类，也就是说，抽象类没有直接的实例。
在UML中，抽象类通过对类名添加斜体修饰来表示。
涉及类的其他概念——模板类
模板又称为参数化元素是对一类带有一个或者多个未绑定的形式参数的元素的描述。模板应用在类上时称为模板类。
对应概念：C++中的模板与Java中的泛型
模板类可以根据参数来定义类，而不用说明属性和操作参数及返回值的具体类型，使用时通过实际值代替参数即可创建新的类，这样就可以避免建立大量功能相似的类。
涉及类的其他概念——关联类
具有类的特性的关联关系，称为关联类。关联类具有关联和类二者的特性，它既可以关联类元素，也可以拥有属性和操作。
关联类在UML中被表示为一个类符号，并通过一条虚线连接到关联路径。
涉及类的其他概念——分析类
分析类是一个主要用于开发过程中的概念，用来获取系统中主要的“职责簇”，代表系统的原型类，是带有某些构造型的类元素。
边界类：用于对系统外部环境与其内部运作之间的交互进行建模的类。
控制类：对一个或多个用例所特有的控制行为进行建模的类。
实体类：用于对必须存储的信息和相关行为建模的类。
类图的建模技术
对逻辑数据库模式建模
识别模型中那些状态必须超过应用程序生存时间的类作为需要作为永久数据存储的类。
创建一个包含这些类的类图。可以自己定义相关的构造型和标记值组合。
对类的结构细节进行细化。包括属性的细节、类之间的关联及其多重性。
注意那些增加数据库设计复杂化的公共模式并尽量简化，如循环关联、一对一的关联和N元关联等。
考虑类的行为。这些行为主要包括对数据存取和数据完整性约束重要的操作。一般情况下，这些业务规则应该被封装在这些永久类的上一层中。
如何阅读类图？
阅读顺序应遵循的原则：
1）先看清有哪些类；
2）然后看看类之间存在的关系；
3）结合多重性来理解类图的结构特点以及各个属性和方法的含义
案例：
1.确定类:Customer、Consignee、Order、OrderItem、DeliverOrder、Peddlery、Product。
2.读出关系：从图中关系最复杂（也就是线最密集）的类开始阅读，本图中最复杂的就是Order类。
1）OrderItem和Order之间是组合关系，根据箭头的方向可知Order包含了OrderItem。
2）Order类和Customer、Consignee、DeliverOrder是关联关系。也就是说，一个订单和客户、收货人、送货单是相关的。
3.多重性来理解类图的结构特点
4．理解方法与图
如何建立类图？
1、建立类图的步骤
1）分析问题域，确定需求；
2）寻找类，确定类的含义和职责；
3）定义类的属性和操作；
4）确定类之间的关系；
5）精化类和类间的关系；
6）绘制类图。
2、寻找类的方法
使用名词/动词寻找类：
1）收集相关信息
a.补充的需求规格说明
b.用例
c.项目说明文档
d.其他文档
2）分析信息
名词、名词短语 类或属性
动词、动词短语 操作
3、寻找类的方法
使用CRC分析法寻找类：
C-class（类）
R-responsibility（职责）
C-collaboration（协作）
CRC分析法是根据类所要扮演的职责来确定类。
a.脑力风暴收集信息。
b.关键业务用类表示，其它卡片作为属性。
案例：
需求描述如下：
李小平是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计。
发现类：
筛选备选类
“李小平”、“人”、“家里”很明显是系统外的概念，无须对其建模；
而“个人图书管理系统”、“系统”指的就是将要开发的系统，即系统本身，也无须对其进行建模；
很明显“书籍”是一个很重要的类，而“书名”、“作者”、“类别”、“出版社”、“书号”则都是用来描述书籍的基本信息的，因此应该作为“书籍”类的属性处理，而“规则”是指书号的生成规则，而书号则是书籍的一个属性，因此“规则”可以作为编写“书籍”类构造函数的指南。
“基本信息”则是书名、作者、类别等描述书籍的基本信息统称，“关键字”则是代表其中之一，因此无需对其建模；
功能”、“新书籍”、“信息”、“记录”都是在描述需求时使用到的一些相关词语，并不是问题域的本质，因此先可以将其淘汰掉；
筛选修选类
“计算机类”、“非计算机类”是该系统中图书的两大分类，因此应该对其建模，并改名为“计算机类书籍”和“非计算机类书籍”，以减少歧义；
“外借情况”则是用来表示一次借阅行为，应该成为一个候选类，多个外借情况将组成“外借情况列表”，而外借情况中一个很重要的角色是“朋友”—借阅主体。虽然到本系统中并不需要建立“朋友”的资料库，但考虑到可能会需要列出某个朋友的借阅情况，因此还是将其列为候选类。为了能够更好地表述，将“外借情况”改名为“借阅记录”，而将“外借情况列表”改名为“借阅记录列表”；
“购买金额”、“册数”都是统计的结果，都是一个数字，因此不用将其建模，而“特定时限”则是统计的范围，也无需将其建模；不过从这里的分析中，我们可以发现，在该需求描述中隐藏着一个关键类—书籍列表，也就是执行统计的主体。
得到候选类
书籍 计算机类书籍 非计算机类书籍
借阅记录 借阅记录列表 书籍列表
分析与建模
扫描二维码推送至手机访问
