2017UML考点整理

2017年UML考点整理

一、选择题 (Multiple Choice Questions)

1. Which of the following are not part of a use-case realization?

选项：
A. Tagged Value
B. Constraint
C. Concurrent
D. Stereotype

答案：C. Concurrent

解析：
• 用例实现 (Use-Case Realization) 是描述某个用例在设计模型中如何基于协作对象实现的。
• 选项分析：
• A. Tagged Value（标记值）： 是 UML 中用于扩展模型元素的属性，可能出现在用例实现中。
• B. Constraint（约束）： 是对模型元素的限制条件，通常用于描述用例实现中的规则或限制。
• C. Concurrent（并发）： 并发是一个概念，不是用例实现的组成部分。
• D. Stereotype（构造型）： 是 UML 中用于扩展元模型的机制，可能出现在用例实现中。

2. Which of the following is not part of a use-case relazation?

注意：题目中 “relazation” 应为 “realization”。
选项：
A. Sequence diagrams
B. Use case
C. Communication
D. Class diagram

答案：B. Use case

解析：
• 用例实现 (Use-Case Realization) 描述了用例在设计模型中的实现方式，通常包括协作对象、交互图和类图等。
• 选项分析：
• A. Sequence diagrams（序列图）： 是用例实现的一部分，用于描述对象之间的交互顺序。
• B. Use case（用例）： 用例本身是需求模型的一部分，而不是用例实现的组成部分。
• C. Communication（通信图）： 是用例实现的一部分，用于描述对象之间的关系和交互。
• D. Class diagram（类图）： 是用例实现的一部分，用于描述系统中类的结构和关系。

以下是针对您提供的知识点的详细解答和总结，包含中英文对照，帮助您更好地理解和复习。

6. Controller (控制器)

英文描述：

The Controller is the first object above the UI layer. It is responsible for receiving and processing system operation information.
• For all system events in the same use-case scenario, the same controller class is used.
• The controller should delegate tasks to other objects. It only coordinates or controls these activities and does not perform substantial work itself.
• When assigning responsibilities to a facade controller leads to a design with low cohesion or high coupling (e.g., when the facade controller becomes “bloated” due to excessive responsibilities), a use-case controller should be considered.
• The GRASP Controller is part of the domain layer and controls or coordinates the processing of work requests.

Advantages of Controller:

• Increases the potential for reusability and interface plug-and-play.
• Provides opportunities to infer the state of use cases.

中文描述：

控制器 (Controller) 是用户界面层之上的第一个对象，负责接收和处理系统操作信息。
• 对于同一用例场景中的所有系统事件，使用相同的控制器类。
• 控制器应将任务委派给其他对象，仅协调或控制这些活动，而不直接完成大量工作。
• 当将职责分配给外观控制器（Facade Controller）导致低内聚或高耦合的设计时（例如，外观控制器的职责过多而变得“臃肿”），通常需要考虑使用用例控制器。
• GRASP 控制器 是领域层的一部分，用于控制或协调工作请求的处理。

控制器的优点：
• 增加了可复用性和接口可插拔的潜力。
• 提供了推测用例状态的机会。

7. Activity Diagram and Interaction Diagram (活动图和交互图)

英文描述：

• Activity Diagram:
• Represents the flow of activities or processes in a system.
• Shows the sequence of actions, decisions, and outcomes in a use case or workflow.
• Useful for modeling business processes or algorithmic flows.

• Interaction Diagram:
• Includes Sequence Diagrams and Communication Diagrams.
• Describes how objects interact to perform a specific task or use case.
• Focuses on the sequence of messages exchanged between objects.

中文描述：

• 活动图 (Activity Diagram):
• 表示系统中活动或流程的流动。
• 显示用例或工作流中的动作顺序、决策点和结果。
• 适用于建模业务流程或算法流程。

• 交互图 (Interaction Diagram):
• 包括 序列图 (Sequence Diagram) 和 通信图 (Communication Diagram)。
• 描述对象如何交互以执行特定任务或用例。
• 重点关注对象之间消息交换的顺序。

8. Three-Tier Architecture (三层架构)

英文描述：

The three-tier architecture typically includes the following layers:

User Interface Layer (Presentation Layer):
• Responsible for user interaction and displaying information.
• Examples: Web pages, mobile app interfaces.
Application Logic Layer (Business Logic Layer):
• Contains the core business logic and workflows of the system.
• Examples: Order processing, payment handling.
Data Service Layer (Infrastructure Layer):
• Provides data storage, retrieval, and communication with external systems.
• Examples: Databases, APIs, network services.

Layer Characteristics:

• Higher layers can call services of lower layers.
• In a strict layered architecture (e.g., network protocol stack), a layer can only call services of its directly adjacent lower layer.
• In a relaxed layered architecture (e.g., information systems), a higher layer can call services of any lower layer.

中文描述：

三层架构通常包括以下层次：

用户界面层 (Presentation Layer):
• 负责用户交互和信息显示。
• 示例：网页、移动应用界面。
应用逻辑层 (Application Logic Layer):
• 包含系统的核心业务逻辑和工作流。
• 示例：订单处理、支付处理。
数据服务层 (Infrastructure Layer):
• 提供数据存储、检索以及与外部系统的通信。
• 示例：数据库、API、网络服务。

层次特性 (Layer Characteristics):

• 较高层可以调用较低层的服务。
• 在严格的分层架构中（如网络协议栈），层只能调用与其直接相邻的较低层的服务。
• 在宽松的分层架构中（如信息系统），较高层可以调用其下任意层的服务。

10. Credit Card Service (信用卡服务)

英文描述：

The Credit Card Service is a use case or service that handles credit card-related operations, such as payment processing, validation, and transaction logging.

When to Use:

• Redundancy: If the same credit card operations are used in multiple use cases, a separate credit card service can reduce redundancy through inclusion relationships.
• Complexity: If the credit card operations are complex and lengthy, breaking them into smaller units (e.g., validation, payment processing) improves understandability.

中文描述：

信用卡服务 (Credit Card Service) 是一个用例或服务，用于处理与信用卡相关的操作，例如支付处理、验证和交易日志记录。

使用场景：

• 冗余 (Redundancy): 如果多个用例中重复使用相同的信用卡操作，可以通过包含关系将信用卡服务分离出来以减少冗余。
• 复杂性 (Complexity): 如果信用卡操作非常复杂且冗长，可以将其分解为更小的单元（如验证、支付处理），以提高可理解性。

13. System Architecture Diagram → Package Diagram (系统架构图 → 包图)

英文描述：

A Package Diagram in UML represents the organization of system components into packages and their dependencies.

Key Features:

• Packages: Logical groupings of related components, such as classes, interfaces, or use cases.
• Dependencies: Represented by dashed arrows pointing from the dependent package to the package it depends on.
• Coupling: The dependency lines indicate the level of coupling between packages in the system.

Purpose:

• To visualize the high-level structure of the system.
• To identify dependencies and potential areas for modularization or refactoring.

中文描述：

包图 (Package Diagram) 是 UML 中用于表示系统组件如何组织成包及其依赖关系的图。

关键特性 (Key Features):

• 包 (Packages): 相关组件的逻辑分组，例如类、接口或用例。
• 依赖关系 (Dependencies): 由虚线箭头表示，从依赖的包指向被依赖的包。
• 耦合 (Coupling): 依赖线表示系统中包之间的耦合程度。

目的 (Purpose):

• 可视化系统的高层结构。
• 识别依赖关系以及模块化或重构的潜在区域。

总结表格

编号	知识点	英文描述	中文描述
6	Controller	The Controller is the first object above the UI layer, responsible for receiving and processing system operations.	控制器是用户界面层之上的第一个对象，负责接收和处理系统操作信息。
7	Activity Diagram	Represents the flow of activities or processes in a system.	活动图表示系统中活动或流程的流动。
	Interaction Diagram	Describes how objects interact to perform a specific task or use case.	交互图描述对象如何交互以执行特定任务或用例。
8	Three-Tier Architecture	Includes User Interface, Application Logic, and Data Service layers.	三层架构包括用户界面层、应用逻辑层和数据服务层。
10	Credit Card Service	A use case or service for handling credit card-related operations.	信用卡服务是一个用例或服务，用于处理与信用卡相关的操作。
13	Package Diagram	Represents the organization of system components into packages and their dependencies.	包图表示系统组件如何组织成包及其依赖关系。

复习建议

控制器 (Controller):
• 理解控制器的职责是接收和处理系统操作信息，并将任务委派给其他对象。
• 掌握 GRASP 控制器的概念及其在领域层中的作用。
活动图与交互图:
• 活动图用于描述流程或活动的流动，交互图用于描述对象之间的交互。
• 区分序列图和通信图的用途：序列图强调时间顺序，通信图强调对象之间的关系。
三层架构:
• 理解用户界面层、应用逻辑层和数据服务层的职责。
• 掌握分层架构的调用规则：严格分层架构中，层只能调用相邻下层的服务；宽松分层架构中，层可以调用任意下层的服务。
信用卡服务:
• 理解信用卡服务的用途及其在高内聚、低耦合设计中的作用。
• 掌握用例的冗余和复杂性分解方法。
包图:
• 理解包图的用途是描述系统组件的高层结构和依赖关系。
• 掌握依赖线的含义及其在系统设计中的作用。

以下是针对 分析建模题 和 综合设计题 的详细解答，包含类图设计、用例图、活动图、时序图和状态机图的描述，帮助您完成题目要求。

一、分析建模题

题目要求：

基于 Payment 和 Sale 的关系，画一个具体应用的类图。
使用 GRASP 模式中的高内聚和低耦合原则进行分析和设计。
降低耦合程度，确保类的职责清晰，符合高内聚低耦合的设计目标。

设计思路：

1. GRASP 模式分析：

• 高内聚 (High Cohesion):
• 每个类应该专注于完成单一的职责。
• 例如，Sale 类负责处理销售相关的逻辑，Payment 类负责处理支付相关的逻辑。

• 低耦合 (Low Coupling):
• 类之间的依赖关系应尽量减少，避免一个类直接依赖另一个类的内部实现。
• 例如，Register 不需要直接依赖 Payment，而是通过 Sale 间接与 Payment 交互。

2. 类图设计：

• 类及其职责：
• Register (收银机):
◦ 负责记录销售信息，但不直接创建 Payment 实例。
◦ 通过 Sale 类间接处理支付。
• Sale (销售):
◦ 负责管理销售过程，包括商品、数量、总价等。
◦ 创建 Payment 实例并调用支付逻辑。
• Payment (支付):
◦ 负责处理支付相关的逻辑，例如支付方式、金额验证等。
• Item (商品):
◦ 表示销售中的商品，包含商品的名称、价格等信息。

• 类之间的关系：
• Register 和 Sale 是聚合关系，Register 包含 Sale。
• Sale 和 Payment 是依赖关系，Sale 创建并调用 Payment。
• Sale 和 Item 是聚合关系，Sale 包含多个 Item。

类图描述：

+-------------------+       +-------------------+       +-------------------+
|      Register     |       |       Sale        |       |     Payment       |
+-------------------+       +-------------------+       +-------------------+
|                   |<>-----|                   |<>-----|                   |
| - sales: Sale[]   |       | - items: Item[]   |       | - amount: double  |
|                   |       | - total: double   |       | - method: String  |
+-------------------+       +-------------------+       +-------------------+
| + createSale()    |       | + calculateTotal()|       | + processPayment()|
| + recordSale()    |       | + addItems(Item)  |       +-------------------+
+-------------------+       +-------------------+

类图说明：

Register (收银机):
• 包含多个 Sale 实例，负责记录销售信息。
• 不直接依赖 Payment，通过 Sale 间接处理支付。
Sale (销售):
• 包含多个 Item 实例，负责管理销售过程。
• 创建 Payment 实例并调用支付逻辑。
Payment (支付):
• 负责处理支付相关的逻辑，例如支付方式和金额验证。
Item (商品):
• 表示销售中的商品，包含商品的名称、价格等信息。

设计优点：

高内聚：
• 每个类的职责单一，Register 只负责记录销售，Sale 负责管理销售过程，Payment 负责支付逻辑。
低耦合：
• Register 不直接依赖 Payment，而是通过 Sale 间接与 Payment 交互，降低了耦合度。
可扩展性：
• 如果需要添加新的支付方式，只需修改 Payment 类，而不需要修改 Register 或 Sale。

二、综合设计题

题目要求：

从以下三种系统中选择一个，完成以下设计任务：

用例图 (Use-Case Diagram)
活动图 (Activity Diagram)
时序图 (Sequence Diagram)
状态机图 (State Machine Diagram)

选择系统：在线租车系统

1. 用例图 (Use-Case Diagram)

描述：

在线租车系统的核心功能包括：
• 用户可以预订车辆。
• 用户可以归还车辆。
• 系统会根据租用时间计算费用。

用例图：

+-------------------+       +-------------------+
|                   |       |                   |
|   Customer        |       |   Admin           |
|                   |       |                   |
+-------------------+       +-------------------+
          |                           |
          |                           |
          v                           v
+-------------------+       +-------------------+
|                   |       |                   |
| - Book a car      |       | - Manage cars     |
| - Return a car    |       | - View reports    |
| - View rental fee |       |                   |
+-------------------+       +-------------------+

说明：

• Customer (顾客):
• 预订车辆 (Book a car)。
• 归还车辆 (Return a car)。
• 查看租赁费用 (View rental fee)。

• Admin (管理员):
• 管理车辆 (Manage cars)。
• 查看报告 (View reports)。

2. 活动图 (Activity Diagram)

描述：

以“预订车辆”为例，描述活动流程：

用户选择车辆。
系统检查车辆可用性。
用户确认预订。
系统生成预订记录。

活动图：

1
2
3

[Start] --> [Select Car] --> [Check Availability] --(Yes)--> [Confirm Booking]
                                          --(No)--> [Show Unavailable Message]
[Confirm Booking] --> [Generate Booking Record] --> [End]

3. 时序图 (Sequence Diagram)

描述：

以“归还车辆”为例，描述对象之间的交互：

用户归还车辆。
系统记录归还信息。
系统计算租赁费用。
系统更新用户账户。

时序图：

Customer -> ReturnCarSystem: Return Car
ReturnCarSystem -> CarDatabase: Update Car Status
ReturnCarSystem -> RentalFeeCalculator: Calculate Fee
RentalFeeCalculator -> UserAccount: Update Account

4. 状态机图 (State Machine Diagram)

描述：

以“车辆状态”为例，描述车辆的状态变化：
• Available (可用): 车辆可被预订。
• Rented (已租用): 车辆已被预订。
• Returned (已归还): 车辆被归还，等待费用结算。
• Under Maintenance (维修中): 车辆不可用。

状态机图：

[Available] --> [Rented]: Book Car
[Rented] --> [Returned]: Return Car
[Returned] --> [Available]: Fee Paid
[Available] --> [Under Maintenance]: Schedule Maintenance
[Under Maintenance] --> [Available]: Maintenance Complete

总结表格

任务	描述	图示说明
用例图	描述在线租车系统的核心功能，包括顾客和管理员的功能。	顾客可以预订、归还车辆，查看费用；管理员可以管理车辆和查看报告。
活动图	描述“预订车辆”的活动流程，包括选择车辆、检查可用性、确认预订和生成记录。	使用决策节点表示车辆是否可用，分支处理不同的流程。
时序图	描述“归还车辆”的对象交互，包括系统记录归还信息、计算费用和更新用户账户。	展示顾客、归还系统、车辆数据库、费用计算器和用户账户之间的交互顺序。
状态机图	描述车辆的状态变化，包括可用、已租用、已归还和维修中。	使用状态节点和转换箭头表示车辆的状态变化及其触发条件。