uml简单复习

1. 定义

   • UML（Unified Modeling Language）即统一建模语言，是一种用于软件系统分析、设计和可视化建模的标准语言。它为软件开发过程中的不同阶段提供了一种通用的、直观的方式来描述软件系统的结构、行为、功能以及与用户和其他系统之间的交互等诸多方面。

2. UML的构成要素

   • 事物（Things）
     • 结构事物：是UML模型中的静态部分，用于描述概念或物理元素。例如类（Class），它是面向对象系统中最基本的结构事物，用于定义一组具有相同属性、操作和关系的对象。接口（Interface）也是一种结构事物，它定义了一组操作的规范，用于描述类或组件对外提供的服务。另外还有用例（Use Case），用于描述系统应该提供的功能，从用户的角度出发来定义系统的行为。
     • 行为事物：主要用于描述系统的动态行为。其中最常见的是交互（Interaction），包括顺序图（Sequence Diagram）中的消息传递、通信图（Communication Diagram）中的对象之间的交互等，它们展示了对象之间如何协作来完成某个功能。状态机（State Machine）也是行为事物的一种，用于描述对象在其生命周期内可能处于的状态以及状态之间的转换，例如一个订单对象可能有“已创建”“已支付”“已发货”“已完成”等状态，状态机可以清晰地展示这些状态之间是如何转换的。
     • 分组事物：主要用于对模型元素进行分组管理，包（Package）是最典型的分组事物。就像文件夹一样，包可以将相关的类、接口、用例等元素组织在一起，使模型结构更加清晰。例如，在一个大型的企业级软件系统中，可以将所有与用户管理相关的类和接口放在一个“用户管理包”中。
     • 注释事物：用于为模型中的其他元素提供解释说明。注释（Note）可以附加到任何UML元素上，通过简单的文本信息帮助开发人员、设计人员或者其他相关人员更好地理解模型元素的含义或意图。
   • 关系（Relationships）
     • 关联（Association）：用于描述类之间的结构关系，表示两个或多个类之间存在某种语义上的联系。例如，在一个“学生 - 课程”的关系中，学生类和课程类之间可能存在“选课”关联关系，这种关系可以通过关联线来表示，并且可以在关联线上标注角色名称（如学生在选课关系中的角色是“选课者”，课程的角色是“被选课程”）、多重性（如一个学生可以选多门课程，一门课程可以被多个学生选）等信息。
     • 依赖（Dependency）：体现了一种较弱的关系，表示一个元素（通常是类、用例等）在语义上依赖于另一个元素。例如，在一个简单的Java程序中，一个类可能依赖于另一个类提供的方法来完成自己的功能。在UML中，依赖关系用带箭头的虚线表示，箭头指向被依赖的元素。
     • 泛化（Generalization）：类似于面向对象编程中的继承关系，用于描述一般元素和特殊元素之间的关系。例如，“哺乳动物”是一个一般的类，“猫”和“狗”是特殊的类，它们是哺乳动物的子类，在UML中可以用泛化关系来表示这种继承层次结构，用带空心三角形箭头的实线表示，箭头指向父类。
     • 实现（Realization）：主要用于描述类和接口之间的关系，表示一个类实现了一个接口所定义的操作规范。在UML中，实现关系用带空心三角形箭头的虚线表示，箭头指向接口。
   • 图（Diagrams）
     • 用例图（Use Case Diagram）：从用户的角度出发，描述系统的功能需求。它展示了系统中的用例（功能）、参与者（用户或外部系统）以及它们之间的关系。例如，在一个图书馆管理系统的用例图中，可以有“借阅者”“图书管理员”等参与者，以及“借书”“还书”“查询图书”等用例，用例图能够清晰地展示系统的功能边界和用户与系统之间的交互场景。
     • 类图（Class Diagram）：是面向对象系统中最常用的图之一，用于描述系统中的类、类的属性、操作以及类之间的关系。通过类图可以直观地看到系统的静态结构，例如在一个电商系统的类图中，可以有“用户类”（包含用户名、密码等属性和注册、登录等操作）、“商品类”（包含商品名称、价格等属性和添加到购物车、修改价格等操作）以及它们之间的关联关系（如用户和商品之间通过购物车产生关联）。
     • 对象图（Object Diagram）：是类图的一个实例化版本，它展示了在某一时刻系统中对象的状态以及对象之间的关系。对象图可以帮助理解系统在运行时的具体情况，例如在某个订单处理场景下，对象图可以展示出一个具体的“用户对象”、“订单对象”和“商品对象”之间的关系，以及这些对象在当时的属性值（如订单对象的状态为“已支付”，商品对象的价格等）。
     • 顺序图（Sequence Diagram）：用于描述对象之间的交互顺序，按照时间顺序展示对象之间的消息传递过程。例如，在一个在线购物流程的顺序图中，可以展示用户发送“下单”消息给订单处理系统，订单处理系统再发送“查询库存”消息给库存管理系统，库存管理系统返回库存信息等一系列消息传递过程，从而清晰地呈现出系统中业务流程的动态执行过程。
     • 通信图（Communication Diagram）：也用于描述对象之间的交互，但更侧重于展示对象之间的链接以及在这些链接上传递的消息。它和顺序图在一定程度上可以相互转换，通信图能够更直观地看到对象之间的关联关系以及消息是如何在这些关联关系上传递的。
     • 状态图（State Diagram）：用于描述一个对象在其生命周期内可能经历的状态以及状态之间的转换条件。例如，对于一个电梯控制系统中的电梯对象，可以通过状态图来展示电梯的“空闲”“上升”“下降”等状态以及在什么条件下（如收到上升请求、到达目标楼层等）从一个状态转换到另一个状态。
     • 活动图（Activity Diagram）：主要用于描述业务流程或者系统操作流程中的活动以及活动之间的控制流。它类似于流程图，但更侧重于面向对象系统中的活动。例如，在一个软件项目的开发流程中，活动图可以展示“需求分析”“设计”“编码”“测试”等活动之间的顺序关系、分支条件（如测试不通过时的返工流程）和并行关系（如编码和测试部分环节可以同时进行）。

3. UML的应用场景

   • 软件系统开发的不同阶段
     • 需求分析阶段：可以使用用例图来收集和整理用户需求，明确系统的功能边界。通过和用户沟通，确定系统中有哪些参与者以及他们需要系统提供哪些功能，用例图能够将这些需求以一种直观的方式呈现出来，方便用户和开发人员共同确认。
     • 系统设计阶段：类图和对象图用于设计系统的静态结构，确定系统中的类、它们的属性和操作以及类之间的关系。顺序图、通信图和活动图可以用于设计系统的动态行为，例如设计系统中的业务流程如何通过对象之间的交互来实现，不同活动之间的控制流等。状态图可以用于设计具有复杂状态变化的对象的行为模式。
     • 实现阶段：开发人员可以根据UML模型（特别是类图和顺序图等）作为编程的参考蓝图，将UML模型转换为具体的代码。并且在代码开发过程中，如果需要对系统进行修改或扩展，也可以通过更新UML模型来更好地理解系统的整体结构和行为，从而更合理地进行代码调整。
     • 测试阶段：UML模型可以帮助测试人员更好地理解系统的功能和行为，从而设计出更有效的测试用例。例如，根据用例图来测试系统是否满足用户的功能需求，根据状态图来测试对象的状态转换是否正确等。
   • 团队协作和文档编制
     • 在软件开发团队中，UML是一种通用的语言。不同的角色（如系统分析师、设计师、开发人员、测试人员等）可以通过UML模型进行有效的沟通。例如，系统分析师可以将需求分析阶段得到的用例图和业务流程相关的活动图交给开发团队和测试团队，开发团队可以根据这些图来设计和实现系统，测试团队可以根据这些图来制定测试计划和测试用例。同时，UML模型也可以作为项目文档的一部分，用于记录系统的结构和行为，方便后续的维护和升级。

4. 概念

   • 定义：UML类图（Class Diagram）是一种用于描述软件系统中类（Class）、接口（Interface）以及它们之间关系的静态结构视图。它以图形化的方式展示了系统的静态架构，是面向对象分析与设计（OOAD）中最核心的建模工具之一。
   • 基本元素
     • 类：类是类图的核心元素，在类图中用矩形表示。一个类包含三个部分（可根据需要显示其中部分内容），最上面是类名，中间是类的属性（Attributes），下面是类的操作（Operations）。例如，一个简单的“学生”类可以表示为：

|学生|
| - 学号: int|
| - 姓名: String|
| + 学习(): void|
| + 参加考试(): void|

其中，“-”表示私有属性或操作，“+”表示公有属性或操作。学号和姓名是学生类的属性，学习和参加考试是学生类的操作。
- 接口：接口在类图中也用矩形表示，但与类不同的是，接口通常只有名称和操作，没有属性。接口的操作默认是公有的，并且接口中的操作没有方法体，它定义了一组规范，实现该接口的类必须实现这些操作。例如：

|<<接口>> 可打印|
| + 打印(): void|

这里定义了一个名为“可打印”的接口，其中包含一个打印操作，任何实现这个接口的类都需要实现打印操作。

• 关系：类图中的类和接口之间存在多种关系，这些关系是类图的重要组成部分。
  • 关联（Association）：表示类与类之间的结构关系，它描述了两个或多个类之间存在语义上的连接。例如，“教师”类和“课程”类之间可能存在“教授”关联关系，在类图中用一条直线连接两个类来表示关联关系，并且可以在直线两端标注角色名称和多重性。多重性表示一个类的对象可以与另一个类的多少个对象相关联，例如“一个教师可以教授多门课程，一门课程可以由多个教师教授”可以表示为在“教师”端标注“1..”，在“课程”端标注“0..”。
  • 聚合（Aggregation）：是一种特殊的关联关系，它表示整体与部分的关系，部分可以脱离整体而存在。在类图中用空心菱形加直线来表示，菱形端指向整体。例如，“汽车”和“轮胎”之间是聚合关系，一辆汽车由多个轮胎组成，但轮胎可以独立于汽车存在。
  • 组合（Composition）：也是整体与部分的关系，但部分不能脱离整体而存在，整体和部分具有相同的生命周期。在类图中用实心菱形加直线来表示，菱形端指向整体。例如，“订单”和“订单项”之间是组合关系，一个订单由多个订单项组成，当订单不存在时，订单项也不存在。
  • 依赖（Dependency）：体现了一种较弱的关系，表示一个类在语义上依赖于另一个类。在类图中用带箭头的虚线表示，箭头指向被依赖的类。例如，“学生”类可能依赖于“课程安排”类来获取课程信息，这种依赖关系可能是因为学生类中的某个操作需要调用课程安排类的方法来完成。
  • 泛化（Generalization）：类似于面向对象编程中的继承关系，用于描述一般类与特殊类之间的关系。在类图中用带空心三角形箭头的实线表示，箭头指向父类。例如，“哺乳动物”类是“猫”类和“狗”类的父类，“猫”和“狗”类继承了哺乳动物类的某些属性和操作。
  • 实现（Realization）：用于描述类与接口之间的关系，表示一个类实现了一个接口所定义的操作规范。在类图中用带空心三角形箭头的虚线表示，箭头指向接口。例如，“打印机类”实现了“可打印”接口，就需要实现接口中的“打印”操作。

2. 作用
   • 系统架构设计
     • 构建静态模型：类图能够帮助软件架构师和设计师构建软件系统的整体静态架构。通过定义系统中的各类和接口，以及它们之间的关系，为系统的设计提供了一个高层次的蓝图。例如，在设计一个企业资源规划（ERP）系统时，使用类图可以确定系统中有哪些核心业务类（如客户类、订单类、库存类等），这些类之间是如何关联的（如客户与订单之间是一对多的关联关系），以及它们需要实现哪些接口（如订单类可能需要实现可跟踪接口，用于跟踪订单状态），从而为系统的详细设计和实现奠定基础。
     • 划分模块和层次：有助于划分系统的模块和层次结构。可以根据类之间的聚合、组合等关系，将相关的类组合成模块，明确模块之间的接口和依赖关系。例如，在一个多层架构的软件系统中，通过类图可以将数据访问层的类（如数据库连接类、数据实体类等）与业务逻辑层的类（如业务处理类、业务规则类等）区分开来，并且清晰地展示它们之间的交互关系（如业务逻辑层的类依赖于数据访问层的类来获取和存储数据），从而实现系统的分层架构设计。
   • 代码实现指导
     • 作为编程参考：对于开发人员来说，类图是将设计转换为代码的重要参考工具。类图中的类可以直接对应到编程语言中的类定义，属性对应类的成员变量，操作对应类的成员方法。例如，在Java开发中，根据类图中的“学生”类的定义，可以很容易地写出如下代码：

public class Student {
    private int studentId;
    private String name;
    public void study() {
        // 学习方法的实现
    }
    public void takeExam() {
        // 参加考试方法的实现
    }
}

 - **促进代码一致性和规范性**：类图规定了类之间的关系和接口规范，这有助于开发团队在代码实现过程中保持一致性和规范性。例如，如果类图中定义了某个类实现了一个接口，开发人员在编写代码时就必须按照接口的规范来实现相应的方法，避免了代码实现的随意性，提高了代码的质量和可维护性。

• 团队沟通协作
  • 统一理解系统结构：在软件开发团队中，类图是一种通用的沟通工具。不同的团队成员（如系统分析师、设计师、开发人员、测试人员等）可以通过类图对系统的静态结构达成统一的理解。例如，系统分析师可以将类图作为需求文档的一部分，向开发团队和测试团队解释系统的设计架构和功能模块划分；开发人员可以通过类图了解自己负责的模块与其他模块之间的关系，从而更好地进行代码开发和集成；测试人员可以根据类图设计针对类之间交互和接口的测试用例。
  • 支持模型驱动开发（MDD）：在模型驱动开发方法中，类图作为核心模型之一，能够驱动整个软件开发过程。开发团队可以先构建类图等UML模型，然后通过工具将这些模型自动转换为部分代码框架，开发人员再在这个基础上进行具体的代码实现和完善，这种方式提高了软件开发的效率和质量，而类图在其中起到了关键的基础作用。
• 系统维护和演进
  • 理解系统现状：当软件系统需要维护或升级时，类图可以帮助维护人员快速理解系统的现有结构。通过查看类图，维护人员可以了解系统中有哪些类、它们的功能以及相互之间的关系，从而更容易定位问题和进行修改。例如，如果系统出现了数据库访问异常，维护人员可以通过查看类图中数据访问层和其他业务层类之间的关系，确定可能出现问题的类和方法。
  • 规划系统扩展和重构：类图也为系统的扩展和重构提供了依据。在对系统进行功能扩展时，例如添加新的业务模块或功能，开发人员可以根据类图来确定新功能与现有系统的集成点和可能需要修改的类。在进行系统重构时，类图可以帮助评估重构方案对系统整体结构的影响，例如在将一个复杂的类拆分为多个类或者调整类之间的关系时，通过更新类图可以直观地看到这些变化对系统架构的影响，从而更好地进行重构决策。