目录
类图
类图是软件设计中使用最广泛的 UML 图形之一，用来描述 类的特性以及类之间的静态关系 。在一个类图中，每个类都由三个部分组成：类名、属性列表 和 方法列表。
- 关联（Association）：表示一个类对象与另一个类对象之间的关系，比如订单与客户之间的关系。
- 依赖（Dependency）：表示一个类对另一个类的使用或调用，比如客户下订单时需要使用订单类。
- 组合（Composition）：表示一种包含关系，表示一个类对象包含另一个类对象，比如一个订单包含多个商品。
- 聚合（Aggregation）：也表示一种包含关系，但是聚合关系中包含的类对象可以被多个类共享，比如一个学校包含多个班级。
- 继承（Inheritance）：表示一个类继承自另一个类，可以从父类中继承属性和方法，并且可以添加新的属性和方法。
- 泛化（Generalization）：与继承关系相似，但泛化关系可以用来表示更抽象的关系，比如多个类都实现了一个接口。
序列图
序列图用于描述参与者之间的动态调用关系。每个参与者都有一条垂直向下的生命线，该生命线用虚线表示。参与者之间的消息按照从上到下的顺序表示它们的调用顺序关系，这就是序列图这个词的来源。每个生命线都有一个激活条，它是图中的细长矩形条，只有在参与者活动时才是激活的。
组件图
组件是比类更大粒度的设计元素，通常一个组件中包含多个类。组件图有时与包图的用途相似，通常用于描述物理组件，如JAR、DLL等。在实践中，我们更多地使用组件图进行模块设计。
组件图描述组件之间的静态关系，主要是依赖关系。如果想要描述组件之间的动态调用关系，可以使用组件序列图，以组件作为参与者，描述组件之间的消息调用关系。
由于组件的粒度较大，通常用于描述和设计软件的模块及其之间的关系。因此，在设计的早期阶段就需要画出组件图，一般用于架构设计阶段。
部署图
部署图描述的是软件系统最终的物理部署情况，包括需要部署的服务器数量、关键组件的部署位置等。它是软件系统最终呈现的物理蓝图，能够让客户、老板和工程师清晰地了解系统的最终运行状态，以及与现有系统和第三方服务器的关系。通过部署图，可以预估服务器和第三方软件的采购成本。
因此，部署图是整个软件设计模型中相当宏观的一种图，需要在设计早期就绘制。各方可以根据部署图讨论是否认可该方案，只有对部署图达成共识，才能继续后面的细节设计。部署图主要用于架构设计阶段，并且与组件图要彼此呼应。
用例图
用例图分为业务用例和系统用例，业务用例图主要体现在 业务分析阶段， 描述一个承建系统的组织对外提供的能力，系统用例体现在需求分析阶段描述系统对外提供的能力。
这张图中，左边是业务用例图，右边是系统用例图 。虽然它们的画法相似，但它们本质上有很大的区别，具体可以查看我之前写的这篇文章。
图中的人形元素称为角色，角色可以是人也可以是其他系统。由于系统的功能可能很复杂，用例图可能仅包含其中的一小部分功能，这些功能被画在一个矩形框内，这个矩形框是用例边界。矩形框里面的椭圆表示单个功能，它们可以相互依赖或需要扩展。因为用例图中的功能描述相对简单，所以通常需要配以文字说明以形成需求文档。
状态图
状态图用来展现单个对象生命周期中的状态变迁。
在业务系统中，许多重要的领域对象都有相当复杂的状态变化，比如订单，它们可以有待付款、待审核、待发货、待收货、交易关闭和交易完成等各种状态。
这些状态变化可以在用例图中用文本形式描述，并随着各个用户的不同操作而改变。但是，使用这种方法描述状态时，状态会分散到不同的地方，这样可能会导致开发错误以及产品经理在设计时的困惑。
采用UML状态图可以有效地解决这些问题，因为它可以在一张图表中展示对象的整个生命周期以及各个状态和变迁之间的关系。比如下面的图表展示了一个订单从创建到交易完成的状态变化。
状态图要在需求分析阶段画，描述状态变迁的逻辑关系，在详细设计阶段也要画，这个时候，状态要用枚举值表示，以指导具体的开发。
活动图
活动图常用于描述系统或业务流程中的动态行为。它可以清晰地展现从一个活动到另一个活动的控制流，描绘出系统或业务流程的逻辑和流程，让开发人员更好地了解整个系统的运作方式。
在活动图中，实心圆表示流程的开始，空心圆表示流程的结束，圆角矩形表示活动，菱形表示分支判断。这些符号的使用能够使活动图更加规范化和可读性，有助于提高系统开发的效率和质量。
此外，活动图引入了一个重要的概念——泳道。活动图可以根据活动的范围，将活动根据领域、系统和角色等划分到不同的泳道中，使流程边界更加清晰。
流程图也比较有普适性，可以在需求分析阶段描述业务流程，也可以在架构设计阶段描述子系统和组件的交互，还可以在详细设计阶段描述一个类方法内部的计算流程。