diff --git a/docs/documentation/modelings/visualization/diagrams/uml/README.md b/docs/documentation/modelings/visualization/diagrams/uml/README.md index bf4cd983a03f5859564fb92214dbdcbb1fc31168..0c5858424108b977aacac6b401ab7293da4cd596 100644 --- a/docs/documentation/modelings/visualization/diagrams/uml/README.md +++ b/docs/documentation/modelings/visualization/diagrams/uml/README.md @@ -52,6 +52,19 @@ 3. `Interaction Overview Diagram` - Interactions：顺序图 + 活动图 4. `Timing Diagram` - Interactions：描述消息跨越不同对象或参与者的实际时间，而不仅仅只关心消息的相对顺序 +❗❗❗ + +`sequence diagram`和`communication diagram`是同构的 + +1. 联系： + 1. 两者都用于描述对象之间的交互，关注如何通过消息传递来协同完成某个功能 + 2. 理论上，任何一个顺序图都可以转换成等价的通信图，反之亦然 +2. 区别： + 1. 顺序图：强调时间顺序，纵向排列消息，展示消息的调用顺序 + 2. 通信图：强调对象之间的结构关系，用连接线表示对象间的关联，而消息则标注在这些连接线上 + +❗❗❗ + +## 1. Introduction -|关系|代码表现|实体|语义|备注| +### 1.1. What is Class Diagram + +`Class Diagram类图`用于描述系统的类、类之间的关系以及类的内部结构。类图主要用于建模系统的静态视图，即系统的结构，而不是用于建模系统的动态行为。 + +类图主要用于总体设计阶段，用于定义系统的整体架构和类的层次结构（即，描述类之间的关系）。 + +完整地建模类图是一个复杂的、庞大的工程，其工作量不亚于编写代码，并且跟综类图与代码的变更也是一项复杂的工程，代码才是软件的最终交付物，因此，并不是所有的类（及其属性、方法）都需要被完整建模。 + +实际应用中，仅绘制核心类及其相关的类、且不必细化所有属性和方法，例如，[Design Patterns: Elements of Reusable Object-Oriented Software](https://www.google.com/books/edition/_/tmNNfSkfTlcC?hl=en&sa=X&ved=2ahUKEwijxKOdoL2MAxUNK0QIHcepKIcQ7_IDegQIGhAC)是使用类图的经典书籍，类图中仅包含了核心类及其相关的类，但完整地阐述、表达了各个设计模式的实现方式。 + +![Design Patterns: Elements of Reusable Object-Oriented Software](./.assets/images/s1074361.jpg) + +## 2. How to Draw Class Diagram + +### 2.1. 类图元素的关系 + +|关系|代码表现（`Java`）|对应实体|语义|备注| |--|--|--|--|--| |`generalization泛化`|继承`extends`|`class - class`|`is-a`|---| |`realization实现`|实现`implements`|`class - interface`|`be-a`/`can-be-a`|---| |`composition组合`|成员变量|`variable - instance`|`owns-a`|删除整体后，个体没有存在的意义| |`aggregation聚合`|成员变量|`variable - instance`|`contains-a`|删除整体后，个体仍有存在的意义| |`association关联`|成员变量|`variable - instance`|`has-a`|平等关联| -|`dependency依赖`|形参或局部变量或静态方法调用|`variable - instance`|`use-a`|---| +|`dependency依赖`|形参或局部变量或静态方法调用|`variable - static`|`use-a`|---| -1. 各种关系的强弱顺序：$泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖$ +1. 各种关系的强弱顺序：**泛化 == 实现 > 组合 > 聚合 > 关联 > 依赖** 2. 组合、聚合、关联在语法上无法区分，需要在语义上区分（即，逻辑关系） -3. 关联也称为"强依赖"，依赖也称为"弱依赖" -4. 聚合是一个个有独立完整生命周期的个体，聚在一起 -5. 组合是一个个组成部分，组成一个有新的生命周期的整体 +3. 关联也称为`"strong dependency强依赖"`，依赖也称为`"weak dependency弱依赖"` +4. 聚合是多个部分聚合在一起，形成一个集合，部分 **有独立的生命周期**，部分的生命周期与整体的生命周期不同（部分对象可以脱离整体对象独立存在，整体对象销毁时，部分对象仍然可以存在） + - 例如，班级（Class） 和 学生（Student）：一个班级由多个学生组成，但学生可以转学到另一个班级或毕业后仍然存在 + - 例如，图书馆（Library） 和 书籍（Book）：图书馆中有很多书籍，但书籍本身可以存在于不同的图书馆或个人书架中，不依赖于某个特定的图书馆 + - 例如，公司（Company） 和 员工（Employee）：员工属于某个公司，但员工可以离职或换工作，不会因公司的消失而消失 +5. 组合是多个部分组合在一起，形成一个整体，部分 **无独立的生命周期**，部分的生命周期与整体的生命周期一致（部分部分不能脱离整体对象单独存在，整体对象销毁时，部分对象也会随之销毁） + - 例如，人（Person）和心脏（Heart）：心脏是人体的一部分，不能单独存在，一旦人死亡，心脏也会失去作用 + - 例如，房屋（House）和房间（Room）：房间属于房屋的一部分，不能独立于房屋存在。如果房屋被拆除，房间也不复存在 + - 例如，汽车（Car）和引擎（Engine）：引擎是汽车的重要组成部分，不能脱离汽车单独存在，汽车报废后，通常引擎也会随之报废（在特定的场景语义中，汽车和引擎表示为"聚合关系"，如，"汽车制造和供应链管理"） + +## 3. Examples ```plantuml @startuml -class A -class B -class C -class D -class E +class AClass +class BClass +Interface CInterface +class DClass +class EClass -A <|-- B: generalization -A .right.|> C: realization +AClass <|-- BClass: generalization +AClass .right.|> CInterface: realization -B -left-* D: composition -B -right-o E: aggregation -D -- F: association\n(bidirectional) -E --> G: association\n(unidirectional) -B ..> H: dependency +BClass -left-* DClass: composition +BClass -right-o EClass: aggregation +DClass -- FClass: association\n(bidirectional) +EClass --> GClass: association\n(unidirectional) +BClass ..> HClass: dependency @enduml ```