大题

UML建模

UML（Unified Modeling Language，统一建模语言）是一种用于描述、可视化、构建和文档化软件系统 artifacts 的标准化建模语言。它提供了一套丰富的图形符号，帮助开发团队更好地理解、设计和沟通软件系统。

软件的本质

软件=对象➕通信机制

软件系统的核心由两部分组成：

• 对象：系统中的基本构建块，包含数据和行为
• 通信机制：对象之间交互和协作的方式

软件的本质

UML通过不同类型的图表来描述这两个核心要素，帮助我们全面理解和设计软件系统。

重点

UML 1.x 与 UML 2.x 的 UML 图

UML 1.x 包含的图

UML 1.x 版本中包含 9 种图，分别是：

• 用例图（Use Case Diagram）：描述系统功能和参与者之间的关系
• 类图（Class Diagram）：描述类及其相互关系
• 对象图（Object Diagram）：类图在某一时刻的实例
• 状态图（State Diagram / Statechart Diagram）：描述对象的状态及状态变化
• 活动图（Activity Diagram）：描述业务流程或控制流程
• 顺序图（Sequence Diagram）：描述对象之间消息交互的时间顺序
• 协作图（Collaboration Diagram）：描述对象之间的协作关系
• 组件图（Component Diagram）：描述系统的物理组件及其依赖关系
• 部署图（Deployment Diagram）：描述系统的物理部署结构

注：包图在 UML 1.x 中已被支持，但通常不单独计入核心 9 种图中。

UML 2.x 新增和修改的图

UML 2.x 在 UML 1.x 的基础上进行了扩展和调整，总共定义了 13 种图，并对部分图形进行了细化和改名。

1. 新增图形（3 种）

   • 交互概览图（Interaction Overview Diagram）：以活动图的形式组织多个交互
   • 计时图（Timing Diagram）：描述对象状态或值随时间变化的情况
   • 组合结构图（Composite Structure Diagram）：描述类或组件的内部结构

2. 图形改名

   • 协作图（Collaboration Diagram） → 通信图（Communication Diagram）
   • 状态图（State Diagram） → 状态机图（State Machine Diagram）

3. 其他调整

   • 将顺序图、通信图、交互概览图和计时图统一归类为 交互图（Interaction Diagrams）
   • 明确引入并强化 包图（Package Diagram），用于描述模型的组织结构

静态结构图（Structure Diagrams）

• 类图
• 对象图
• 组件图
• 部署图
• 包图
• 组合结构图

动态行为图（Behavior Diagrams）

• 用例图
• 活动图
• 状态机图
• 交互图：
  • 顺序图
  • 通信图
  • 交互概览图
  • 计时图

用例图之间的关系

用例图中的关系主要包括以下四种：

1. 包含关系（Include）

• 定义：一个用例包含另一个用例的功能，被包含的用例是主用例的必要组成部分
• 表示方法：带箭头的虚线，箭头指向被包含用例，虚线标注 <<include>>
  

2. 扩展关系（Extend）

• 定义：一个用例扩展另一个用例的功能，扩展用例是主用例的可选部分，基于特定条件触发
• 表示方法：带箭头的虚线，箭头指向主用例，虚线标注 <<extend>>
  

3. 泛化关系（Generalization）

• 定义：一个用例是另一个用例的特殊化，子用例继承父用例的所有特性并可以添加自己的特性
• 表示方法：带空心三角形的实线，三角形指向父用例

4. 关联关系（Association）

• 定义：表示用例与参与者之间的交互关系
• 表示方法：实线连接参与者和用例
  

用例描述

类图之间的关系

类图中的关系主要包括以下六种：

1. 关联关系（Association）

• 定义：表示两个类之间存在某种静态联系，是最基本的关系类型
• 表示方法：实线连接两个类（带箭头表导航性）
  

2. 依赖关系（Dependency）

• 定义：一个类的变化会影响另一个类，依赖是一种弱关联
• 表示方法：带箭头的虚线，箭头指向被依赖的类
  

3. 泛化关系（Generalization）

• 定义：表示类之间的继承关系，子类继承父类的所有特性
• 表示方法：带空心三角形的实线，三角形指向父类
  

4. 实现关系（Realization）

• 定义：表示类实现了接口的所有方法
• 表示方法：带空心三角形的虚线，三角形指向接口
  

5. 聚合关系（Aggregation）

• 定义：表示整体与部分的关系，部分可以独立于整体存在
• 表示方法：带空心菱形的实线，菱形指向整体
  

6. 组合关系（Composition）

• 定义：表示整体与部分的关系，部分不能独立于整体存在
• 表示方法：带实心菱形的实线，菱形指向整体
  

简答题

UML之交互图中是谁在交互？为什么交互？如何交互？

1. 谁在交互？

• 对象：交互的主体是类的实例

2. 为什么交互？

• 实现功能：完成系统用例和业务逻辑
• 信息传递：对象间需要数据交换

3. 如何交互？

• 消息传递：通过同步、异步、返回消息
• 时间顺序：按生命线从上到下排列

在下图1中最上面的对象的名称是什么？该图表示的意思是什么？请绘制出与其相应的类图。

图1

最上面对象的名称和表示的是：

• 对象名：China
• 表示：表示福建，四川等省份聚合成中国

相应的类图

补充下图的系统核心类图

分析系统需求，确定核心类包括：用户、租户、房东、办公空间、预订记录、租赁合同、支付记录、评价等，绘制出的类图如图2所示，请将识别出的系统核心类填写到图中对应的（1）~（6）号所对应的位置（每个空格1分，共6分）：

(1) 用户
(2) 房东
(3) 租户
(4) 预订记录
(5) 评价
(6) 支付记录

（下方对应类图：包含标注(1)-(6)的矩形框，以及“办公空间”“租赁合同”等类，带“+1”“+n”的关联关系）

类图

解析

• (1) 用户是父类，因为(2)和(3)继承自(1)
• (2) 房东，因为房东拥有办公空间
• (3) 租户，因为租户预订办公空间并发布评价
• (4) 预订记录，因为租户生成预订记录，预订记录关联到办公空间
• (5) 评价，因为租户发布评价
• (6) 支付记录，因为租赁合同关联到支付记录

改错题

用例图

请分析以下用例图，请指出5处错误，并绘制正确的用例图

1. 错误点：登录和找回密码的关系错误（原使用<<include>>，应使用<<extend>>）

• 原因：找回密码不是登录的必要步骤，而是可选功能

2. 错误点：借书和查找书籍的关系错误（原使用<<extend>>，应使用<<include>>）

• 原因：借书前必须先查找书籍，查找书籍是借书的必要步骤

3. 错误点：还书和查找书籍的关系错误（原使用<<extend>>，应使用<<include>>）

• 原因：还书前必须先查找书籍，查找书籍是还书的必要步骤

4. 错误点：还书和缴纳罚款的关系错误（原使用<<include>>，应使用<<extend>>）

• 原因：缴纳罚款不是还书的必要步骤，只有超期时才需要缴纳罚款

5. 错误点：参与者与“查找书籍”缺少直接关联

• 原因：查找书籍是图书管理员可以直接执行的用例

完整正确的图书管理系统用例图

类图

分析以下类图，指出5处错误，并绘制正确的类图

1766484818283

1. 错误点：企业与制衣厂之间错误使用了继承关系且方向错误

• 错误表现：原类图中企业通过继承箭头（空心三角）指向制衣厂，实际表示企业是制衣厂的子类，但这与业务逻辑不符
• 错误原因：继承关系表示"is-a"（是一个）关系，箭头应从子类指向父类；而制衣厂不是企业的一种，而是企业包含的一个组织，应使用表示"has-a"（有一个）关系的关联或聚合
• 正确设计：企业和制衣厂之间应使用聚合关系，企业作为整体，制衣厂作为其组成部分

2. 错误点：制衣厂与设计部之间错误使用了组合关系

• 错误表现：原类图中制衣厂通过实心菱形指向设计部，表示组合关系
• 错误原因：组合关系表示整体与部分的强依赖，部分（设计部）不能独立于整体（制衣厂）存在，但实际上设计部可以独立存在
• 正确设计：应使用表示松散依赖的聚合关系，空心菱形指向整体

3. 错误点：工人与生产部门的聚合关系方向错误

• 错误表现：原类图中工人通过空心菱形指向生产部门，表明工人拥有生产部门
• 错误原因：聚合关系中菱形应指向整体，实际是生产部门拥有工人，而不是工人拥有生产部门
• 正确设计：菱形应指向生产部门，表明生产部门是整体，工人是其组成部分

4. 错误点：制衣厂与生产部门的组合关系方向错误

• 错误表现：原类图中组合关系的黑菱形放在了"生产部门"一侧，实际表示生产部门拥有制衣厂，但这与业务逻辑完全相反
• 错误原因：组合关系中，黑菱形必须放在"整体（拥有者）"一端；按照业务逻辑，应该是制衣厂拥有生产部门，而不是生产部门拥有制衣厂
• 正确设计：黑菱形应放在制衣厂一侧，表示制衣厂是整体，生产部门是其组成部分

5. 错误点：制衣厂实现接口的箭头方向错误

• 错误表现：原类图中接口"生产校服"通过虚线空心三角指向制衣厂
• 错误原因：实现关系中，箭头应从类指向接口，表示类实现了接口
• 正确设计：应使用虚线空心三角，箭头从制衣厂指向接口"生产校服"

6. 错误点：生产部门与原材料之间错误使用了依赖关系

• 错误表现：原类图中生产部门通过虚线箭头指向原材料，表示依赖关系
• 错误原因：依赖关系表示"临时使用"，而原材料是生产部门长期使用的对象，应使用表示"长期关联"的关联关系
• 正确设计：应使用实线表示关联关系，表明生产部门与原材料之间存在长期的业务关系

正确的制衣厂类图

找出并说明下面类图1中的错误。

类图1

1. 错误点：“计算机”与“维护人员”之间错误使用了聚合关系

• 错误表现：
  原类图中“计算机”通过空心菱形指向“维护人员”，表示维护人员是计算机的一部分。

• 错误原因：
  聚合（has-a）表示整体与部分关系，而维护人员是使用或维护计算机的人，并不是计算机的组成部分。
  把“人”作为“物”的组成在语义上是错误的。

• 正确设计：
  “维护人员”与“计算机”之间应为关联关系，表示维护或管理行为。

2. 错误点：“用户”与“计算机”之间关系方向与类型不合理

• 错误表现：
  原图中“用户”与“计算机”之间使用了带方向的依赖/关联关系，且方向从计算机指向用户。

• 错误原因：
  在业务语义中，是用户使用计算机，而不是计算机依赖用户；方向表达与实际含义相反。

• 正确设计：
  应使用单向或双向关联，方向从“用户”指向“计算机”，或直接使用无方向关联。

3. 错误点：“用户”和“维护人员”未正确体现其继承自“人”

• 错误表现：
  原类图中“人”与“用户”“维护人员”之间的继承关系混乱或不规范，继承方向不清晰。

• 错误原因：
  继承（is-a）关系要求：

  • 子类指向父类
  • 用户、维护人员本质上都是“人”

• 正确设计：
  “用户”和“维护人员”都应继承自“人”，箭头从子类指向父类。

4. 错误点：“计算机”与其硬件部件关系使用不当（聚合 vs 组合）

• 错误表现：
  原类图中“计算机”与“主机、显示器、键盘、鼠标”使用的是聚合关系（空心菱形）。

• 错误原因：
  这些部件在该模型中是计算机的组成部分，生命周期通常依附于计算机，语义上更符合组合关系。

• 正确设计：
  “计算机”应通过 组合关系（实心菱形） 包含这些硬件部件。

设计题

某高校计划开发校园外卖订餐系统，支持学生下单、商家接单、配送员配送、管理员管理等功能。需求如下：

1. 管理员可以录入商家信息（商家名称、地址、营业时间、配送范围），审核商家提交的菜品信息（如价格、库存），导出订单统计表（如热门菜品、商家销售额）。
2. 商家可以提交菜品信息（需关联商家ID），查看订单列表（待接单/已接单/已完成），更新菜品库存。
3. 学生可以浏览菜品并下单（需选择配送地址、支付方式），查看订单状态（待接单/配送中/已完成），取消订单（仅限商家未接单时）。
4. 配送员可以查看待配送订单（需关联配送地址），更新订单状态为“已完成”。

采用面向对象方法开发系统：

【问题1】识别参与者、用例及关系，建模用例图。（8分）
参与者识别

1. 管理员
2. 商家
3. 学生
4. 配送员

用例识别

1. 管理员用例：录入商家信息、审核菜品信息、导出订单统计表
2. 商家用例：提交菜品信息、查看订单列表、更新菜品库存
3. 学生用例：浏览菜品、下单、查看订单状态、取消订单
4. 配送员用例：查看待配送订单、更新订单状态

关系识别

• 关联关系：参与者与用例之间的交互
• 扩展关系：取消订单是下单的扩展（仅在商家未接单时可触发）

用例图

【问题2】识别类，分析关系，建模类图。（7分）

类识别

1. 管理员：管理员ID、用户名、密码
2. 商家：商家ID、商家名称、地址、营业时间、配送范围
3. 菜品：菜品ID、菜品名称、价格、库存、商家ID
4. 学生：学生ID、姓名、手机号、配送地址
5. 订单：订单ID、订单日期、订单状态、学生ID、配送地址、支付方式
6. 订单明细：明细ID、订单ID、菜品ID、数量、单价
7. 配送员：配送员ID、姓名、手机号

关系识别

• 关联关系：商家与菜品（1对多）、学生与订单（1对多）、订单与配送员（1对多）、订单明细与菜品（1对1）
• 组合关系：订单包含订单明细（订单明细依赖订单存在，订单删除则明细删除）

类图