【转】UML之类图和对象图
思路呈现
- 什么是类图？
- 描述类、接口、协作及他们之间的关系的图。显示系统中类的静态结构。
- 有什么作用？
- 描述软件系统的静态结构
- ①对系统的词汇建模
- ②对简单协作建模
- ③对逻辑数据库模式建模
- 什么是对象图？
- 是类图变化而来，与类图相似，显示一组对象和他们之间的关系（是类的多个对象实例而不是实际的类）
| 在类中包含三部分，分别是类名、类的属性和类的操作 | 对象包含两个部分：对象的名称和对象的属性 |
| 类的名称栏只包含类名 | 对象的名称栏包含“对象名：类名” |
| 类的属性栏定义了所有属性的特征 | 对象的属性栏定义了属性的当前值 |
| 类中列出了操作 | 对象图中不包含操作内容，因为对属于同一个类的对象，其操作是相同的 |
| 类中使用了关联连接，关联中使用名称、角色以及约束等特征定义 | 对象使用链进行连接，链中包含名称、角色 |
| 类代表的是对对象的分类所以必须说明可以参与关联的对象的数目 | 对象代表的是单独的实体，所有的链都是一对一的，因此不涉及到多重性。 |
- 类图（对系统的静态描述）：
对象图：对系统在某一时刻的展现
类的表示：
关于类和类图的一些总结分类：（个人感觉一幅图胜过千言万语，所以我很少用文字描述，基本上都整理成了思维导图的形式呈现出来，供大家参考！）
类在很多方面和组件相同：
（1）两者都有名称
（2）都可以实现一组接口
（3）都可以参与依赖关系
（4）都可以被嵌套
（5）都可以有实例
（6）都可以参与交互
但是也会有一些区别：
（1）类描述软件设计的逻辑组织和意图，组件描述软件设计的物理实现，每个组件体现了系统设计中特定类的实现
下面进行一些简单的说明：
①类图描述所有可能情况
②聚合：限制性没有组合强，聚合类似于书架与书的关系，不是有了书架才有的书，书的产生与书架没有关系
③组合：限制性强于聚合，类似于身体与肢体的关系，有了身体才会有肢体，没有身体，肢体是不会产生的（节点不能脱离列表的存在）
④能用关联不用依赖，能用组合、聚合不用普通关联，组合、依赖比普通关联描述的信息更加的严格，关联比依赖更加严格（严谨性、严格性：组合、聚合>关联>依赖）
⑤自身关联：一个对象可以与另一个同类的对象有链接，即类可以与自身有链接
⑥关联类：两个对象之间的链接本身可以拥有自己的属性和行为，如果把连接看做是一个类的实例，则该类称为关联类。（如图：L是A B的关联类）
单重继承：有且只有一个父类
多重继承：一个类有两个或两个以上的父类
实现关系：类元之间的语义关系，该关系中一个类元描述了另一个类元保证实施的契约
| 名称 | 描述关系性质（方向指示符用实心三角形箭头表示） |
| 角色 | 类处于关联某一端时，该类在关系中扮演特定角色（一个类对另一个类的职责） |
| 多重性 | 约束是UML三大扩展机制之一，多重性是一种约束（最广泛），用..表示 |
| 聚合 | 特殊型关联，表示整体与部分关系的关联（has a） |
| 组合 | 被称为“强聚合”，生命周期取决于聚合的生命周期 |
| 导航性 | 一个对象通过链（关联的实例）进行导航访问另一个对象（降低类间耦合度） |
| 0 | 恰好为“0” |
| 0..1 | 0或1 |
| 0..n | 0或更多 |
| 1 | 恰好为1 |
| 1..n | 1或更多 |
| n | n或更多 |
抽象类：（不能被实例化）
- 包图（将图形（系统）模块化）：
①将一个复杂的图模块化
②组织源代码
③两个包中任意两个类之间有依赖关系，则两个包之间有依赖关系
| 避免循环依赖 | |
| 以包为测试单位 | |
| 将概念和语义相近的元素包含在一个包中 | |
| 将包中的元素分为私有、公有（可以在包外访问）和受保护的 | |
| 构造型 | 用途 |
| 虚包（facade） | 描述一个只引用其他包内元素的包 |
| 框架（framework） | 描述一个主要由模式组成的包 |
| 桩（stub） | 描述一个座位另一个包的公共内容代理的包 |
| 子系统（subsystem） | 描述正在建模中的整个系统的独立部分的包 |
| 系统（system） | 描述正在建模中的整个系统的包 |
-
类与包的区别：
类：对问题领域或解决方案的事物的抽象，他必须有标识，有实例，类的实例（对象）是运行系统的组成元素。
包：把事物组织成一种模型的机制，他可以没有标识，因为在运行系统中不可见。 -
类图示例图：
-
对象图（一般用户）示例图：
-
对象图（操作员）示例图：
-
对象图（管理员）示例图：
转载：https://blog.csdn.net/tigaobansongjiahuan8/article/details/80256396。
