2013年UML

1. View are “slices” of architecture. Which view focus on structural issue?

选项：
A. Use-case
B. Process
C. Implementation
D. Logical

答案：D. Logical

解析：
• Use-case View (A): 关注系统的功能需求和用户交互，描述系统的行为而非结构。
• Process View (B): 关注系统的运行时行为，描述进程和线程的交互，侧重于动态行为。
• Implementation View (C): 关注系统的物理实现，例如文件、组件和模块的组织。
• Logical View (D): 关注系统的静态结构，描述类、接口和它们之间的关系，属于结构性问题。

2. Which of the following are not part of Extension Mechanisms of UML?

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

答案：C. Concurrent

解析：
• UML 扩展机制 (Extension Mechanisms):
• Tagged Value (A): 用于为模型元素添加额外的属性或元数据。
• Constraint (B): 用于为模型元素添加约束条件，定义规则或限制。
• Stereotype (D): 用于扩展 UML 的元模型，定义新的构造型（如 <<boundary>>、<<control>>）。
• Concurrent (C): 并发是一个概念，不是 UML 的扩展机制。

3. Which of the following is not part of a use-case realization?

选项：
A. Sequence diagrams
B. Use case
C. Communication
D. Class diagram

答案：C. Communication

4. A car has 4 wheels. What type of relationship is between the class car and the class wheel?

选项：
A. Association
B. Aggregation
C. Inheritance
D. Dependency

答案：B. Aggregation

解析：
• Association (A): 表示类之间的普通关系，例如“学生”和“课程”之间的关系。
• Aggregation (B): 表示“整体-部分”关系，且部分可以独立于整体存在。
• 在本题中，“车轮”可以独立于“汽车”存在，因此是聚合关系。
• Inheritance (C): 表示类之间的继承关系，例如“汽车”继承自“交通工具”。
• Dependency (D): 表示类之间的临时依赖关系，例如方法调用。

5. Scheduling project activities such as functional increment and test case development, which one of the following OOA/D artifacts is the most useful?

选项：
A. Use cases
B. Interaction diagrams
C. Activity diagrams
D. Class diagrams

答案：C. Activity diagrams

解析：
• Use cases (A): 描述系统的功能需求和用户交互，适合定义系统的功能范围，但不适合详细的活动调度。
• Interaction diagrams (B): 描述对象之间的交互，适合建模系统的动态行为，但不适合活动调度。
• Activity diagrams (C): 描述工作流或活动的流程，适合用于项目活动的调度和规划，例如功能增量和测试用例开发。
• Class diagrams (D): 描述系统的静态结构，适合建模类和它们之间的关系，但不适合活动调度。

以下是针对您提供的问题的详细解答和解析，帮助您更好地理解相关知识点。

6. In a well-designed layered architecture, which layers should know about which?

选项：
A. Model knows view and persistence, View knows Model and Persistence.
B. View knows Model, Model knows Persistence.
C. View knows Model, Persistence knows View and Model.
D. View knows Model, Model knows View and Persistence, Persistence knows Model.

答案：B. View knows Model, Model knows Persistence.

解析：
• 分层架构 (Layered Architecture):
• View (视图层): 负责用户界面和用户交互，依赖于 Model 层获取数据。
◦ View 知道 Model (View knows Model): 视图需要从模型中获取数据以显示给用户。
• Model (模型层): 负责业务逻辑和数据管理，可能依赖于 Persistence 层进行数据存储和检索。
◦ Model 知道 Persistence (Model knows Persistence): 模型需要与持久化层交互以存储或读取数据。
• Persistence (持久化层): 负责数据的存储和检索，通常对其他层不可见。
◦ Persistence 不应知道 View 或 Model (Persistence does not know View or Model): 持久化层是独立的，不应直接依赖其他层。

7. For showing how several objects collaborate in a single use case, which one of the following OOA/D artifacts is the most useful?

选项：
A. Sequence Diagrams
B. Activity Diagrams
C. State Diagram
D. Class Diagram

答案：A. Sequence Diagrams

解析：
• Sequence Diagrams (序列图):
• 描述对象之间的交互顺序，展示如何协作完成单个用例。
• 适合展示对象之间的消息传递和时间顺序。
• Activity Diagrams (活动图):
• 描述工作流或活动的流程，适合展示业务流程而非对象交互。
• State Diagram (状态图):
• 描述对象的状态变化，适合建模对象的状态转换，而非对象协作。
• Class Diagram (类图):
• 描述系统的静态结构，展示类及其关系，而非动态交互。

8. Which of the following is not one of the dimensions of software engineering according to UP recommendations?

选项：
A. Develop iteratively
B. Model the software visually
C. Control changes
D. Freeze requirements at the start of a project to provide stability

答案：D. Freeze requirements at the start of a project to provide stability

解析：
• UP (Unified Process) 的软件工程维度：
• A. Develop iteratively (迭代开发): UP 强调迭代开发，逐步完善系统。
• B. Model the software visually (可视化建模): UP 使用 UML 等工具进行可视化建模。
• C. Control changes (控制变更): UP 提供变更管理机制，确保系统适应需求变化。
• D. Freeze requirements at the start of a project (在项目开始时冻结需求): UP 不支持冻结需求，而是强调需求的动态管理和适应性。

9. Which of the following is not one of the dimensions of software quality?

选项：
A. Supportability
B. Performance
C. Assessment
D. Usability

答案：C. Assessment

解析：
• 软件质量的维度 (Dimensions of Software Quality):
• A. Supportability (可支持性): 系统易于维护和支持的能力。
• B. Performance (性能): 系统的响应速度和资源利用率。
• D. Usability (可用性): 系统对用户的友好程度和使用便捷性。
• C. Assessment (评估): 不是软件质量的维度，而是对质量进行评估的过程。

10. Which of the following use case is a valid use case because it can pass the Boss Test, EBP Test, and Size Test?

选项：
A. Negotiate a Supplier Contract
B. Handle Returns
C. Log In
D. More Piece on Game Board

答案：B. Handle Returns

解析：
• Boss Test (老板测试):
• 用例是否对业务有价值？老板是否会关心？
• Handle Returns (处理退货): 对业务有直接价值，符合 Boss Test。
• EBP Test (Elementary Business Process Test,基本业务流程测试):
• 用例是否描述了一个完整的业务流程？
• Handle Returns: 描述了一个完整的退货流程，符合 EBP Test。
• Size Test (大小测试):
• 用例是否大小适中，既不太大也不太小？
• Handle Returns: 是一个适中的用例，符合 Size Test。

总结表格

题号	问题类型	问题内容	答案	解析
6	单选题	In a well-designed layered architecture, which layers should know about which?	B. View knows Model, Model knows Persistence.	分层架构中，视图层依赖模型层，模型层依赖持久化层，持久化层对其他层不可见。
7	单选题	For showing how several objects collaborate in a single use case, which one is the most useful?	A. Sequence Diagrams	序列图适合描述对象之间的交互顺序和时间关系。
8	单选题	Which of the following is not one of the dimensions of software engineering according to UP?	D. Freeze requirements at the start of a project	UP 不支持冻结需求，而是强调需求的动态管理和适应性。
9	单选题	Which of the following is not one of the dimensions of software quality?	C. Assessment	软件质量的维度包括可支持性、性能和可用性，评估不是质量维度。
10	单选题	Which of the following use case is valid based on Boss Test, EBP Test, and Size Test?	B. Handle Returns	处理退货是一个完整的业务流程，大小适中，对业务有价值，符合所有测试标准。

复习建议

分层架构 (Layered Architecture):
• 理解视图层、模型层和持久化层的职责及其依赖关系。
• 视图层依赖模型层，模型层依赖持久化层，持久化层对其他层不可见。
OOA/D 工件 (OOA/D Artifacts):
• 序列图 (Sequence Diagrams): 描述对象之间的交互顺序，适合展示单个用例的协作。
• 活动图 (Activity Diagrams): 描述业务流程或活动流程。
• 状态图 (State Diagram): 描述对象的状态变化。
• 类图 (Class Diagram): 描述系统的静态结构。
UP 的软件工程维度:
• 迭代开发、可视化建模和控制变更是 UP 的核心原则。
• UP 不支持冻结需求，而是强调需求的动态管理。
软件质量维度:
• 理解软件质量的关键维度，包括可支持性、性能、可用性等。
• 评估 (Assessment) 不是质量维度，而是对质量进行评估的过程。
用例设计:
• 确保用例符合 Boss Test（业务价值）、EBP Test（完整业务流程）和 Size Test（大小适中）。
• 选择适中的用例，避免过于复杂或过于简单。

以下是针对您提供的问题的详细解答和解析，帮助您更好地理解相关知识点。

11. Which of the following statement is false?

选项：
A. An Object can be in more than one state at a time
B. A state machine can have multiple termination states
C. A state can remember which sub state was the last state
D. A transition can fire conditionally

答案：A. An Object can be in more than one state at a time

解析：
• A. An Object can be in more than one state at a time (错误):
• 在传统的状态机中，一个对象在同一时间只能处于一个状态。
• 如果需要描述“同时处于多个状态”，可以使用 并发状态 (Concurrent Substates)，但这并不是传统状态机的默认行为。

• B. A state machine can have multiple termination states (正确):
• 状态机可以有多个终止状态，表示不同的结束条件。

• C. A state can remember which sub state was the last state (正确):
• 状态可以通过 历史状态 (History State) 记录最后一个子状态，以便在返回时恢复。

• D. A transition can fire conditionally (正确):
• 转换可以基于条件触发，例如满足某些约束或事件时触发。

12. Which model represents the following code generated by a Modeling tool?

代码：

Class Order {
  private Customer recipient;
  // ….
}

选项：
A. Design A
B. Design B
C. Design C
D. None of the above

答案：D. None of the above

解析：
• 题目中没有提供 Design A、Design B、Design C 的具体描述，因此无法判断哪个模型与代码匹配。
• 代码展示了一个类 Order 和其私有属性 recipient，属于 类图 (Class Diagram) 的范畴。
• 如果选项中没有明确的类图描述，则正确答案应为 D. None of the above。

13. What methods MUST be implemented by the CreditProcessor class in the payment Sequence diagram?

选项：
A. check Credit, generate Confirmation Code, display Confirmation
B. check Credit, generate Confirmation Code
C. check Credit, generate Confirmation Code, Reserve seat
D. check Credit, Reserve seat, display Confirmation

答案：B. check Credit, generate Confirmation Code

解析：
• CreditProcessor 类的职责：
• 在支付序列图中，CreditProcessor 的主要职责是验证信用和处理与信用相关的逻辑。
• check Credit (验证信用): 是 CreditProcessor 的核心功能。
• generate Confirmation Code (生成确认码): 是支付完成后需要生成的操作，通常由 CreditProcessor 或相关类完成。
• Reserve seat (预订座位): 和 display Confirmation (显示确认信息): 不属于 CreditProcessor 的职责，可能由其他类（如 SeatManager 或 UserInterface）处理。

14. When doing domain analysis, the class diagram should be drawn PRIMARILY to represent:

选项：
A. messages sent between objects
B. implementation objects such as wrappers and devices
C. business objects and implementation objects such as wrappers and devices
D. business objects

答案：D. business objects

解析：
• 领域分析 (Domain Analysis):
• 领域分析的目标是识别和建模业务领域的核心概念和对象。
• 类图应主要表示 业务对象 (Business Objects)，而不是实现细节。
• 选项分析：
• A. messages sent between objects (对象之间的消息): 这是交互图（如序列图）的内容，而不是类图的重点。
• B. implementation objects such as wrappers and devices (实现对象): 实现细节不属于领域分析的范畴。
• C. business objects and implementation objects (业务对象和实现对象): 领域分析应专注于业务对象，而非实现对象。
• D. business objects (业务对象): 正确，领域分析的核心是建模业务领域的核心对象。

15. The following are the requirements for a Report-generation module in an application:

需求：

当新数据生成时，用户界面应自动刷新以反映最大值。
支持多种视图类型。

选项：
A. Establish subscribe/notify mechanism between the view and model, with the model updating the view based upon the view type.
B. Establish subscribe/notify mechanism between the view and model layers so that the views get notified of the change.
C. Develop intelligence within the model so that it decides which views are to be refreshed based on the view type.
D. Combine the view and model layers into a single entity so that the interactions are localized and notifications are instantaneous.

答案：B. Establish subscribe/notify mechanism between the view and model layers so that the views get notified of the change.

解析：
• 需求分析：
• 需求 1 要求实现 观察者模式 (Observer Pattern)，当数据变化时通知视图自动刷新。
• 需求 2 要求支持多种视图类型，视图应独立于模型。

• 选项分析：
• A. Establish subscribe/notify mechanism with the model updating the view based upon the view type (模型根据视图类型更新视图):
◦ 模型不应直接决定如何更新视图，这违反了 关注点分离 (Separation of Concerns) 原则。
• B. Establish subscribe/notify mechanism (建立订阅/通知机制):
◦ 正确，模型通过观察者模式通知视图数据变化，视图根据需要刷新。
• C. Develop intelligence within the model (在模型中开发智能逻辑):
◦ 模型不应包含视图相关的逻辑，这会导致耦合度增加。
• D. Combine the view and model layers (合并视图和模型层):
◦ 违反了 MVC 或分层架构 的原则，视图和模型应分离。

总结表格

题号	问题类型	问题内容	答案	解析
11	单选题	Which statement about state machines is false?	A. An Object can be in more than one state at a time	传统状态机中，对象在同一时间只能处于一个状态。并发状态是例外情况。
12	单选题	Which model represents the given code?	D. None of the above	题目未提供具体设计描述，无法匹配代码。类图是建模业务对象的工具。
13	单选题	What methods must CreditProcessor implement in a payment sequence diagram?	B. check Credit, generate Confirmation Code	CreditProcessor 的职责是验证信用和生成确认码，其他操作应由其他类处理。
14	单选题	What should a domain analysis class diagram primarily represent?	D. business objects	领域分析的核心是建模业务对象，而非实现细节或对象间的消息传递。
15	单选题	Which design satisfies report-generation module requirements?	B. Establish subscribe/notify mechanism	观察者模式是满足需求 1 和 2 的最佳设计，模型通过通知机制与视图解耦。

复习建议

状态机 (State Machine):
• 理解状态机的基本概念，包括状态、转换和终止状态。
• 注意传统状态机中对象在同一时间只能处于一个状态，并发状态是例外情况。
类图 (Class Diagram):
• 类图用于建模业务对象及其关系，而非实现细节。
• 领域分析的核心是识别业务对象及其关系。
观察者模式 (Observer Pattern):
• 用于实现模型和视图之间的解耦。
• 当数据变化时，模型通过通知机制自动更新视图。
职责分配 (Responsibility Assignment):
• 确保类的职责单一，避免将视图逻辑放入模型中。
• 使用设计模式（如观察者模式）分离关注点。
需求分析 (Requirement Analysis):
• 理解需求并选择合适的设计模式。
• 在报告生成模块中，观察者模式是满足自动刷新和多视图需求的最佳选择。

以下是针对您提供的判断题的详细解答和解析，帮助您更好地理解相关知识点。

1. Stereotypes can be applied to many UML elements such as class, package, and associations.

答案：T (True)

解析：
• Stereotypes (构造型):
• 是 UML 的一种扩展机制，用于为现有的元模型元素添加特定的语义。
• 可以应用于多种 UML 元素，例如类 (class)、包 (package)、关联 (association) 等。
• 示例：<<boundary>>、<<control>>、<<entity>> 是常见的构造型。

2. Use cases are an object-oriented way to handle requirements. Therefore, they don’t fit very well into non-object-oriented projects.

答案：F (False)

解析：
• 用例 (Use Cases):
• 是一种需求建模方法，用于描述系统的功能需求和用户交互。
• 虽然用例最初是为面向对象的设计而提出的，但它们并不局限于面向对象项目。
• 用例同样适用于非面向对象的项目，例如过程式编程或函数式编程项目。

3. A dependency between packages indicates that some element in the dependent package depends on some element(s) in the independent package.

答案：T (True)

解析：
• 包依赖 (Package Dependency):
• 表示一个包（依赖包）中的某些元素依赖于另一个包（独立包）中的元素。
• 依赖关系通常是单向的，表示设计上的耦合。
• 示例：如果 Package A 中的类使用了 Package B 中的类，则 Package A 依赖于 Package B。

4. It is worthwhile to draw a state chart diagram for every class you create.

答案：F (False)

解析：
• 状态图 (State Chart Diagram):
• 用于描述对象的状态变化及其触发条件。
• 并不是每个类都需要状态图，只有那些具有明确状态变化的类才需要。
• 过度绘制状态图会增加复杂性，降低模型的可读性。

5. Although the communication diagram has the same semantics with the sequence diagram, they have different representations.

答案：T (True)

解析：
• 通信图 (Communication Diagram) 和序列图 (Sequence Diagram):
• 两者都用于描述对象之间的交互，语义上是等价的。
• 区别：
◦ 序列图 (Sequence Diagram): 强调消息的时间顺序。
◦ 通信图 (Communication Diagram): 强调对象之间的关系和消息的传递路径。

6. The idea of Protected Variation-GRASP pattern is to design objects and systems so that instability in them does not have undesirable effects on other elements.

答案：T (True)

解析：
• Protected Variation (保护变化) - GRASP 模式：
• 目标是通过识别系统中的变化点，并将其封装在独立的模块中，从而减少变化对其他部分的影响。
• 通过使用接口、抽象类或其他设计模式（如依赖倒置原则），实现对变化的隔离。

7. The inception phase in UP usually is more than a few weeks long for most projects.

答案：F (False)

解析：
• UP (Unified Process) 的初始阶段 (Inception Phase):
• 初始阶段的目标是定义项目的高层次目标、范围和可行性。
• 通常是一个短期的阶段，持续几周而不是几个月。
• 过长的初始阶段可能会导致项目启动延迟。

8. The purpose of elaboration is to fully and carefully define models, which are translated into code during construction.

答案：F (False)

解析：
• 精化阶段 (Elaboration Phase):
• 目标是细化系统的架构和关键需求，验证项目的可行性。
• 并不是完全定义所有模型，而是重点关注架构和关键设计决策。
• 代码的实现主要发生在 构造阶段 (Construction Phase)。

9. A system sequence diagram is a picture that shows, for one particular scenario of a use case, the events that external actors generate, their order, and inter-system events.

答案：T (True)

解析：
• 系统序列图 (System Sequence Diagram):
• 描述在用例的某个特定场景中，外部参与者生成的事件及其顺序。
• 还可以包括系统之间的交互事件。
• 用于展示系统的整体行为和外部交互。

10. Strategy pattern allows one of a family of algorithms to be selected on-the-fly at runtime.

答案：T (True)

解析：
• 策略模式 (Strategy Pattern):
• 是一种行为型设计模式，用于定义一系列算法，并将它们封装在独立的类中。
• 允许在运行时动态选择和切换算法，而不需要修改客户端代码。
• 示例：支付策略（信用卡支付、支付宝支付、微信支付）可以根据需要动态切换。

总结表格

题号	问题类型	问题内容	答案	解析
1	判断题	Can stereotypes be applied to many UML elements such as class, package, and associations?	T (True)	构造型可以应用于类、包、关联等多种 UML 元素。
2	判断题	Are use cases an object-oriented way to handle requirements that don’t fit into non-object-oriented projects?	F (False)	用例不仅适用于面向对象项目，也可以用于非面向对象项目。
3	判断题	Does a dependency between packages indicate that some element in the dependent package depends on the independent package?	T (True)	包依赖表示依赖包中的元素依赖于独立包中的元素。
4	判断题	Is it worthwhile to draw a state chart diagram for every class?	F (False)	只有具有状态变化的类才需要状态图，不需要为每个类都绘制状态图。
5	判断题	Do communication diagrams and sequence diagrams have the same semantics but different representations?	T (True)	通信图和序列图语义等价，但通信图强调对象关系，序列图强调时间顺序。
6	判断题	Does the Protected Variation-GRASP pattern aim to isolate instability in objects and systems?	T (True)	保护变化模式通过封装变化点来减少变化对其他部分的影响。
7	判断题	Is the inception phase in UP usually more than a few weeks long for most projects?	F (False)	初始阶段通常是短期的，持续几周而不是几个月。
8	判断题	Is the purpose of elaboration to fully define models for implementation during construction?	F (False)	精化阶段的目标是细化架构和关键需求，而不是完全定义所有模型。
9	判断题	Does a system sequence diagram show events generated by external actors and their order?	T (True)	系统序列图展示用例场景中外部参与者生成的事件及其顺序。
10	判断题	Does the Strategy pattern allow algorithms to be selected at runtime?	T (True)	策略模式允许在运行时动态选择和切换算法。

复习建议

构造型 (Stereotypes):
• 构造型是 UML 的扩展机制，可以应用于类、包、关联等多种元素。
• 常见的构造型包括 <<boundary>>、<<control>> 和 <<entity>>。
用例 (Use Cases):
• 用例是一种需求建模方法，适用于面向对象和非面向对象项目。
• 用例描述了系统的功能需求和用户交互。
包依赖 (Package Dependency):
• 包依赖表示一个包中的元素依赖于另一个包中的元素。
• 依赖关系通常是单向的，表示设计上的耦合。
状态图 (State Chart Diagram):
• 状态图用于描述对象的状态变化及其触发条件。
• 并不是每个类都需要状态图，只有具有状态变化的类才需要。
通信图与序列图 (Communication Diagram vs. Sequence Diagram):
• 两者语义等价，但通信图强调对象关系，序列图强调时间顺序。
保护变化模式 (Protected Variation - GRASP):
• 通过封装变化点来减少变化对其他部分的影响。
• 使用接口、抽象类或其他设计模式实现隔离。
初始阶段 (Inception Phase):
• 初始阶段是项目的短期阶段，目标是定义高层次目标、范围和可行性。
• 通常持续几周而不是几个月。
精化阶段 (Elaboration Phase):
• 精化阶段的目标是细化架构和关键需求，而不是完全定义所有模型。
• 代码实现主要发生在构造阶段。
系统序列图 (System Sequence Diagram):
• 系统序列图展示用例场景中外部参与者生成的事件及其顺序。
• 用于描述系统的整体行为和外部交互。
策略模式 (Strategy Pattern):
◦ 策略模式允许在运行时动态选择和切换算法。
◦ 常见应用场景包括支付策略、排序算法等。

通过针对性练习这些问题，可以快速巩固 UML 和设计模式的核心概念！

以下是针对您提供的简答题的详细解答，答案以中文形式呈现，帮助您更好地理解和复习。

二、简答题

1. What are the main phases of the Unified Process? Explain them in a few words.

答案：
统一过程（Unified Process, UP）主要包括以下四个阶段：

初始阶段 (Inception):
• 目标： 定义项目的高层次目标、范围和可行性。
• 关键活动： 业务案例开发、粗略估算、需求识别。
• 成果： 对项目的高层次构想和范围有一个大致的理解。
细化阶段 (Elaboration):
• 目标： 精化项目架构，解决高风险问题，并定义大部分需求和范围。
• 关键活动： 核心架构的迭代实现、关键用例的验证、更实际的估算。
• 成果： 稳定的架构和明确的项目计划。
构造阶段 (Construction):
• 目标： 实现剩余的低风险和简单元素，并为部署做准备。
• 关键活动： 剩余功能的迭代开发、系统集成和测试。
• 成果： 一个功能完整且可部署的系统。
移交阶段 (Transition):
• 目标： 将系统部署到最终用户并进行验证。
• 关键活动： Beta 测试、用户培训、系统部署和最终调整。
• 成果： 系统正式投入使用。

2. Explain briefly what the Adapter design pattern is. Provide an example of its use.

答案：
• 定义：
• 适配器模式 (Adapter Design Pattern) 是一种结构型设计模式，用于解决不兼容接口的问题。
• 它通过一个适配器对象，将一个类的接口转换为客户端期望的另一种接口，从而使原本因接口不兼容而无法协作的类能够一起工作。

• 目的：
• 解决接口不兼容问题。
• 为具有不同接口的类似构建提供统一的接口。

• 示例：
• 场景： 假设有一个 LegacyPrinter 类，它使用 printText(String text) 方法打印文本，但你的应用程序需要一个 print(Document document) 方法，该方法定义在 ModernPrinter 接口中。
• 解决方案： 创建一个适配器类 PrinterAdapter，它实现 ModernPrinter 接口，并在内部使用 LegacyPrinter 类来完成实际的打印任务。

代码示例：

// 目标接口（客户端期望的接口）
interface ModernPrinter {
    void print(Document document);
}

// 遗留类（不兼容的接口）
class LegacyPrinter {
    void printText(String text) {
        System.out.println("Printing: " + text);
    }
}

// 适配器类
class PrinterAdapter implements ModernPrinter {
    private LegacyPrinter legacyPrinter;

    public PrinterAdapter(LegacyPrinter legacyPrinter) {
        this.legacyPrinter = legacyPrinter;
    }

    @Override
    public void print(Document document) {
        String text = document.getText(); // 将 Document 转换为文本
        legacyPrinter.printText(text);    // 使用 LegacyPrinter 打印
    }
}

// 客户端代码
public class Client {
    public static void main(String[] args) {
        LegacyPrinter legacyPrinter = new LegacyPrinter();
        ModernPrinter printer = new PrinterAdapter(legacyPrinter);

        Document document = new Document("Hello, World!");
        printer.print(document); // 无缝工作！
    }
}

• 实际应用场景：
• 适配器模式常用于集成第三方库或遗留系统到现代应用程序中。

3. Please name and briefly describe the “4+1 view” of software architecture adopted in RUP.

答案：
RUP（Rational Unified Process）采用的“4+1视图模型”是一种从多个角度描述软件架构的框架，包括以下五种视图：

逻辑视图 (Logical View):
• 目标： 关注系统的功能设计和如何满足用户需求。
• 利益相关者： 分析人员、设计人员。
• 描述： 描述系统的结构，包括类、接口及其关系。
实现视图 (Implementation View):
• 目标： 关注系统的物理实现，包括源代码组织和构建过程。
• 利益相关者： 程序员。
• 描述： 描述系统的模块、组件及其关系，以及源代码的组织方式。
进程视图 (Process View):
• 目标： 关注系统的运行时行为，包括进程、线程及其交互。
• 利益相关者： 系统迭代器（负责系统级设计和迭代计划）。
• 描述： 描述系统的并发性、同步性以及进程间的交互。
部署视图 (Deployment View):
• 目标： 关注系统的物理部署，包括硬件、软件和网络配置。
• 利益相关者： 系统工程师。
• 描述： 描述系统如何在硬件和软件环境中部署。
用例视图 (Use Case View):
• 目标： 关注系统的功能需求和用户交互。
• 利益相关者： 终端用户。
• 描述： 描述系统的用例、用户交互和高层需求。

补充说明

1. Unified Process (UP) 的主要阶段：

• 初始阶段 (Inception):
• 目标是定义项目的高层次目标、范围和可行性。
• 关键活动包括业务案例开发、粗略估算和需求识别。

• 细化阶段 (Elaboration):
• 目标是精化项目架构，解决高风险问题，并定义大部分需求和范围。
• 关键活动包括核心架构的迭代实现和需求验证。

• 构造阶段 (Construction):
• 目标是实现剩余的低风险和简单元素，并为部署做准备。
• 关键活动包括功能开发、集成和测试。

• 移交阶段 (Transition):
• 目标是将系统部署到最终用户并进行验证。
• 关键活动包括 Beta 测试、用户培训和最终调整。

2. Adapter Design Pattern 的应用场景：

• 接口不兼容问题：
• 当两个系统或类的接口不兼容时，适配器模式可以通过包装或转换接口来解决。
• 第三方库集成：
• 在集成第三方库时，适配器模式可以将第三方库的接口转换为系统所需的接口。
• 遗留系统迁移：
• 在迁移遗留系统时，适配器模式可以帮助新系统与遗留系统协同工作。

3. 4+1 视图模型的作用：

• 多视角描述系统：
• 通过逻辑视图、实现视图、进程视图、部署视图和用例视图，从不同角度描述系统的架构和行为。
• 支持团队协作：
• 不同视图满足不同利益相关者的需求，例如分析师、设计师、程序员和系统工程师。
• 提高系统可理解性：
• 通过多视图描述，帮助团队成员更好地理解系统的复杂性。

总结表格

题号	问题类型	问题内容	答案要点
1	简答题	What are the main phases of the Unified Process? Explain them in a few words.	Inception: 定义目标、范围和可行性。 Elaboration: 精化架构，解决风险。 Construction: 实现剩余元素。 Transition: 部署和测试。
2	简答题	Explain briefly what the Adapter design pattern is. Provide an example of its use.	定义: 解决接口不兼容问题。目的: 提供统一接口。示例: `LegacyPrinter` 通过适配器适配到 `ModernPrinter`。
3	简答题	Name and briefly describe the “4+1 view” of software architecture in RUP.	逻辑视图: 关注功能设计。实现视图: 关注代码结构。进程视图: 关注运行时行为。部署视图: 关注物理部署。用例视图: 关注用户交互。

复习建议

Unified Process (UP):
• 理解 UP 的四个主要阶段（Inception、Elaboration、Construction、Transition）及其目标。
• 每个阶段的关键活动和交付物需要清晰掌握。
Adapter Design Pattern:
• 理解适配器模式的作用是解决接口不兼容问题。
• 掌握适配器模式的实现方式及其在实际开发中的应用场景。
4+1 View Model:
• 理解五种视图的作用及其对应的利益相关者。
• 逻辑视图、实现视图、进程视图、部署视图和用例视图分别从不同角度描述系统。

通过针对性练习这些问题，可以快速巩固软件工程和设计模式的核心概念！

以下是针对您提供的两个建模问题的详细解答，包括类图和顺序图的绘制说明。

一、简单建模

1. Draw class diagram for the following scenario.

场景描述：

• 每个宠物店最多有 20 只毛皮类宠物（furry friends）和 10 只鸟类宠物。
• 每只宠物都有疫苗接种记录（vaccination history）。
• 毛皮类宠物分为狗（Dog）和猫（Cat）。
• 每只毛皮类宠物都有一个微型芯片（microchip）用于识别。
• 每个微型芯片有一个唯一的 ID 号。

类图设计：

以下是类图的文字描述，您可以根据描述绘制图形。

类及其属性：

PetStore (宠物店):
• furryFriends: List<FurryFriend> (0..20)
• birds: List<Bird> (0..10)
Pet (宠物): （抽象类）
• vaccinationHistory: List<VaccinationRecord>
FurryFriend (毛皮类宠物): （继承自 Pet）
• microchip: Microchip
Dog (狗): （继承自 FurryFriend）
Cat (猫): （继承自 FurryFriend）
Bird (鸟类宠物): （继承自 Pet）
Microchip (微型芯片):
• id: String （唯一标识）
VaccinationRecord (疫苗接种记录):
• date: Date
• vaccineType: String

类图关系：

PetStore 包含多个 FurryFriend 和 Bird，表示聚合关系。
• PetStore 与 FurryFriend 是聚合关系，PetStore 包含最多 20 只 FurryFriend。
• PetStore 与 Bird 是聚合关系，PetStore 包含最多 10 只 Bird。
FurryFriend 继承自 Pet，表示继承关系。
Dog 和 Cat 继承自 FurryFriend，表示继承关系。
FurryFriend 拥有一个 Microchip，表示组合关系（Microchip 的生命周期依赖于 FurryFriend）。
Pet 拥有一个 VaccinationHistory，表示组合关系。

类图示例（文字描述）：

+-------------------+
|    PetStore       |
+-------------------+
| - furryFriends: List<FurryFriend> (0..20) |
| - birds: List<Bird> (0..10)               |
+-------------------+
         |                   |
         |                   |
         |                   |
+-------------------+   +-------------------+
|    Pet (abstract) |   |      Bird         |
+-------------------+   +-------------------+
| - vaccinationHistory: List<VaccinationRecord> |
+-------------------+   +-------------------+
         ^
         |
         | (Inheritance)
+-------------------+       +-------------------+
|   FurryFriend     |       |      Dog          |
+-------------------+       +-------------------+
| - microchip: Microchip                     |
+-------------------+       +-------------------+
         ^                                ^
         |                                |
         | (Inheritance)                  | (Inheritance)
+-------------------+       +-------------------+
|      Cat          |       |   Microchip       |
+-------------------+       +-------------------+
                              |
                              | (Composition)
                              v
                      +-------------------+
                      | VaccinationRecord |
                      +-------------------+
                      | - date: Date      |
                      | - vaccineType: String |
                      +-------------------+

类图说明：

PetStore 是主类，包含多个 FurryFriend 和 Bird。
Pet 是抽象类，定义了所有宠物的共同属性（如疫苗接种记录）。
FurryFriend 是 Pet 的子类，包含一个 Microchip。
Dog 和 Cat 是 FurryFriend 的具体实现。
Microchip 是 FurryFriend 的组成部分，表示唯一标识。
VaccinationRecord 是 Pet 的组成部分，记录疫苗接种信息。

2. 画顺序图相关的题目

题目示例：

设计一个顺序图，描述以下场景：
• 用户在宠物店系统中为宠物预约疫苗接种。
• 系统验证宠物的疫苗接种历史。
• 如果宠物需要接种疫苗，系统生成一个新的疫苗接种记录并更新宠物的疫苗接种历史。

顺序图设计：

以下是顺序图的文字描述，您可以根据描述绘制图形。

参与者：

User (用户): 发起点预约请求。
PetStoreSystem (宠物店系统): 处理用户的请求。
Pet (宠物): 被预约接种疫苗的宠物。
VaccinationService (疫苗接种服务): 负责验证疫苗接种历史并生成新的接种记录。

顺序图步骤：

用户向宠物店系统发送预约疫苗接种的请求。
宠物店系统调用 Pet 对象，获取宠物的疫苗接种历史。
宠物店系统调用 VaccinationService，验证宠物是否需要接种疫苗。
如果宠物需要接种疫苗：
• VaccinationService 生成一个新的疫苗接种记录。
• 更新宠物的疫苗接种历史。
宠物店系统向用户返回操作结果。

顺序图示例（文字描述）：

User -> PetStoreSystem: 请求预约疫苗接种
PetStoreSystem -> Pet: 获取疫苗接种历史
Pet -> PetStoreSystem: 返回疫苗接种历史
PetStoreSystem -> VaccinationService: 验证是否需要接种疫苗
VaccinationService -> PetStoreSystem: 需要接种疫苗
PetStoreSystem -> VaccinationService: 生成新的疫苗接种记录
VaccinationService -> Pet: 更新疫苗接种历史
Pet -> PetStoreSystem: 返回更新后的疫苗接种历史
PetStoreSystem -> User: 返回操作成功

顺序图说明：

用户发起请求：
• 用户通过宠物店系统发起预约疫苗接种的请求。
获取疫苗接种历史：
• 宠物店系统调用 Pet 对象，获取宠物的疫苗接种历史。
验证接种需求：
• 宠物店系统调用 VaccinationService，验证宠物是否需要接种疫苗。
生成接种记录：
• 如果宠物需要接种疫苗，VaccinationService 生成新的接种记录并更新宠物的疫苗接种历史。
返回结果：
• 宠物店系统向用户返回操作结果。

补充说明

类图 (Class Diagram):

• 类图用于描述系统的静态结构，包括类、属性、方法及其关系。
• 在宠物店场景中，类图展示了宠物店、宠物、微型芯片、疫苗接种记录等对象之间的关系。

顺序图 (Sequence Diagram):

• 顺序图用于描述对象的动态交互，展示对象之间的消息传递顺序。
• 在疫苗接种场景中，顺序图展示了用户、宠物店系统、宠物和疫苗接种服务之间的交互过程。

总结表格

题目	问题类型	问题内容	答案要点
1	建模题	Draw class diagram for the pet store scenario.	类图包括：PetStore、Pet、FurryFriend、Dog、Cat、Bird、Microchip、VaccinationRecord。关系：继承、聚合、组合。
2	建模题	Draw a sequence diagram for vaccine appointment scenario.	顺序图包括：User、PetStoreSystem、Pet、VaccinationService。交互：请求预约、验证接种历史、生成接种记录。