2015UML
2015UML
以下是完整的题目、选项、答案和解释，包含中英文对照，确保清晰易懂：
1. View are “slices” of architecture. Which view focus on structural issue?
英文:
A. Use-case
B. Process
C. Implementation
D. Logical
中文:
视图是架构的“切片”。哪种视图关注结构性问题？
A. 用例视图
B. 过程视图
C. 实现视图
D. 逻辑视图
正确答案: D
解释 (Explanation):
• 逻辑视图 (Logical View):
• 聚焦于系统的结构化问题，如类（Class）、组件（Component）、接口（Interface）的设计。
• 例如：类图（Class Diagram）、包图（Package Diagram）。
• 其他视图对比:
• 用例视图 (Use-Case View): 关注功能需求（What the system does）。
• 过程视图 (Process View): 关注并发性和操作系统级细节（如线程、进程）。
• 实现视图 (Implementation View): 关注代码和部署细节（如编译器、运行时环境）。
2. Which of the following are not part of a use-case realization?
英文:
A. Tagged Value
B. Constraint
C. Concurrent
D. Stereotype
中文:
以下哪项不属于用例实现的一部分？
A. 标签值
B. 约束
C. 并发
D. 构造型
正确答案: C
解释 (Explanation):
• 用例实现 (Use-Case Realization):
• 包括用例（Use Case）、类图（Class Diagram）、序列图（Sequence Diagram）、通信图（Communication Diagram）等，用于描述系统如何实现用例的功能。
• 并发 (Concurrent):
• 属于活动图（Activity Diagram）或状态机图（State Machine Diagram）的范畴，用于描述并行流程或状态转换，而非用例实现的核心内容。
• 其他选项:
• 标签值 (Tagged Value): 是 UML 中的扩展机制，用于为模型元素添加额外信息。
• 约束 (Constraint): 是 UML 中的限制条件，用于描述模型元素的规则。
• 构造型 (Stereotype): 是 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
中文:
以下哪项不属于用例实现的一部分？
A. 序列图
B. 用例
C. 通信图
D. 类图
正确答案: D
解释 (Explanation):
• 类图 (Class Diagram):
• 属于系统的静态结构设计，用于描述类、属性、方法及其关系（如继承、聚合）。
• 用例实现 (Use-Case Realization): 更关注动态交互（如序列图、通信图），而非静态结构设计。
• 其他选项:
• 序列图 (Sequence Diagram): 和 通信图 (Communication Diagram) 是用例实现的核心工具，用于描述对象之间的动态交互。
• 用例 (Use Case): 是用例实现的基础，描述系统的功能需求。
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
中文:
汽车有 4 个轮子。类汽车和类轮子之间的关系类型是什么？
A. 关联
B. 聚合
C. 继承
D. 依赖
正确答案: B
解释 (Explanation):
• 聚合关系 (Aggregation):
• 轮子是汽车的组成部分，但轮子可以独立存在（例如作为零件库存）。
• 聚合关系用“空心菱形”表示，在类图中写作 Car has-a Wheel。
• 对比其他关系:
• 组合关系 (Composition): 轮子与汽车生命周期绑定（如焊接在车上），但题目未明确此条件。
• 关联关系 (Association): 通用术语，不强调“整体-部分”语义。
• 继承关系 (Inheritance): 表示“是一个”关系，不适用于此场景。
5. Scheduling project activities such as functional increment and test case development, which one of the following OOAD artifacts is the most useful?
英文:
A. Use cases
B. Interaction diagrams
C. Activity diagrams
D. Class diagrams
中文:
规划项目活动（如功能增量和测试用例开发）时，以下哪种面向对象分析设计（OOAD）工件最有用？
A. 用例
B. 交互图
C. 活动图
D. 类图
正确答案: B
解释 (Explanation):
• 交互图 (Interaction Diagrams):
• 包括序列图（Sequence Diagram）和协作图（Collaboration Diagram），用于描述对象之间的动态交互和消息传递。
• 适用场景:
◦ 规划功能模块的调用顺序（如 functional increment）。
◦ 分析测试用例的开发流程（如步骤间的依赖关系）。
• 其他选项:
• 活动图 (Activity Diagram): 适用于流程建模，但更关注步骤顺序而非对象交互。
• 用例图 (Use-Case Diagram): 描述功能需求，不涉及具体实现细节。
• 类图 (Class Diagram): 描述静态结构，不直接用于活动调度。
总结表格
| 问题编号 | 英文问题 | 中文问题 | 正确答案 | 关键概念 |
|---|---|---|---|---|
| 1 | Which view focus on structural issue? | 哪种视图关注结构性问题？ | D. Logical | 逻辑视图聚焦类、组件和接口设计。 |
| 2 | Which are not part of a use-case realization? | 哪些不属于用例实现？ | C. Concurrent | 并发属于活动图或状态机图的范畴。 |
| 3 | Which is not part of a use-case realization? | 哪些不属于用例实现？ | D. Class diagram | 类图属于静态结构设计，非用例实现的动态交互部分。 |
| 4 | Car与Wheel的关系类型？ | 汽车与轮子的关系类型是什么？ | B. Aggregation | 轮子是汽车的组成部分，但可独立存在（聚合关系）。 |
| 5 | Scheduling project activities的最佳OOAD工件？ | 规划项目活动的最佳OOAD工件是什么？ | B. Interaction diagrams | 交互图描述对象交互，适用于功能模块调用和测试用例开发。 |
复习建议
- 视图类型 (Views):
• 掌握逻辑视图（结构）、用例视图（功能）、过程视图（并发）、实现视图（代码）的核心区别。 - 用例实现 (Use-Case Realization):
• 区分用例图（需求分析）与序列图/通信图（设计实现）。 - 类关系 (Class Relationships):
• 聚合（弱生命周期依赖） vs 组合（强生命周期绑定）。 - 项目调度工具 (Project Scheduling):
• 交互图（动态交互）比活动图（流程步骤）更适合描述模块调用和测试流程。
以下是完整的题目、选项、答案和解释，包含中英文对照，确保清晰易懂：
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.
中文:
在一个设计良好的分层架构中，各层之间应该如何知道彼此？
A. 模型层知道视图层和持久层，视图层知道模型层和持久层。
B. 视图层知道模型层，模型层知道持久层。
C. 视图层知道模型层，持久层知道视图层和模型层。
D. 视图层知道模型层，模型层知道视图层和持久层，持久层知道模型层。
正确答案: D
解释 (Explanation):
• 分层架构的基本原则:
• 视图层 (View): 负责用户界面，仅与模型层交互以获取数据。
• 模型层 (Model): 负责业务逻辑，既需要与视图层交互以提供数据，也需要与持久层交互以存储和检索数据。
• 持久层 (Persistence): 负责数据存储，仅与模型层交互以保存或读取数据。
• 选项 D 的正确性:
• 视图层知道模型层（视图需要从模型获取数据）。
• 模型层知道视图层和持久层（模型需要与视图交互并提供数据，同时需要与持久层交互以存储数据）。
• 持久层知道模型层（持久层需要从模型获取数据以进行存储）。
7. For showing how several objects collaborate in a single use case, which one of the following OOAD artifact is the most useful?
英文:
A. Sequence Diagrams
B. Activities Diagrams
C. State Diagram
D. Class Diagram
中文:
为了展示单个用例中多个对象如何协作，以下哪种面向对象分析设计（OOAD）工件最有用？
A. 序列图
B. 活动图
C. 状态图
D. 类图
正确答案: A
解释 (Explanation):
• 序列图 (Sequence Diagram):
• 描述对象之间的动态交互，展示消息的顺序。
• 非常适合用于展示单个用例中多个对象的协作。
• 其他选项对比:
• 活动图 (Activity Diagram): 更适合描述流程或工作流，而非对象之间的交互。
• 状态图 (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
中文:
根据统一过程（UP）的建议，以下哪项不是软件工程的维度之一？
A. 迭代开发
B. 可视化建模
C. 控制变更
D. 在项目开始时冻结需求以提供稳定性
正确答案: D
解释 (Explanation):
• 统一过程（UP）的核心维度:
• 迭代开发 (Iterative Development): 通过多次迭代逐步完善系统。
• 可视化建模 (Visual Modeling): 使用 UML 等工具对系统进行建模。
• 控制变更 (Change Control): 管理需求、设计和实现中的变更。
• 选项 D 的错误性:
• UP 强调需求的动态管理，而不是在项目开始时冻结需求。
• 需求可能会随着项目的进展而变化，UP 提供了灵活的需求管理机制。
9. Which of the following is not one of the dimensions of software quality?
英文:
A. Supportability
B. Performance
C. Assessment
D. Usability
中文:
以下哪项不是软件质量的维度之一？
A. 可维护性
B. 性能
C. 评估
D. 易用性
正确答案: C
解释 (Explanation):
• 软件质量的常见维度:
• 支持性 (Supportability): 系统易于维护和扩展。
• 性能 (Performance): 系统的响应速度和资源利用率。
• 易用性 (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
中文:
以下哪个用例是有效的用例，因为它可以通过老板测试（Boss Test）、EBP 测试（Elementary Business Process Test）和规模测试（Size Test）？
A. 协商供应商合同
B. 处理退货
C. 登录
D. 游戏板上增加一块
正确答案: A
解释 (Explanation):
• 有效用例的标准:
• 老板测试 (Boss Test): 用例是否对业务目标有显著贡献？
• EBP 测试 (Elementary Business Process Test): 用例是否描述了一个完整的业务流程？
• 规模测试 (Size Test): 用例是否具有适当的规模（既不太大也不太小）？
• 选项 A 的正确性:
• “协商供应商合同”是一个完整的业务流程，对业务目标有显著贡献，并且规模适中。
• 其他选项的错误性:
• 登录 (Log In): 规模太小，不符合规模测试。
• 处理退货 (Handle Returns): 可能涉及多个子流程，规模过大。
• 游戏板上增加一块 (More Piece on Game Board): 不符合 EBP 测试，因为它不是一个完整的业务流程。
总结表格
| 问题编号 | 英文问题 | 中文问题 | 正确答案 | 关键概念 |
|---|---|---|---|---|
| 6 | In a well-designed layered architecture, which layers should know about which? | 在设计良好的分层架构中，各层之间应该如何知道彼此？ | D | 模型层是核心，视图层和持久层都依赖模型层，模型层也依赖持久层。 |
| 7 | For showing how several objects collaborate in a single use case, which one of the following OOAD artifact is the most useful? | 为了展示单个用例中多个对象如何协作，以下哪种面向对象分析设计（OOAD）工件最有用？ | A | 序列图用于描述对象之间的动态交互，适合展示用例中的协作。 |
| 8 | Which of the following is not one of the dimensions of software engineering according to UP recommendations? | 根据统一过程（UP）的建议，以下哪项不是软件工程的维度之一？ | D | UP 强调迭代开发、可视化建模和变更控制，而不是冻结需求。 |
| 9 | Which of the following is not one of the dimensions of software quality? | 以下哪项不是软件质量的维度之一？ | C | 软件质量维度包括可维护性、性能和易用性，但“评估”不是质量维度。 |
| 10 | Which of the following use case is a valid use case because it can pass the Boss Test, EBP Test and Size Test? | 以下哪个用例是有效的用例，因为它可以通过老板测试、EBP 测试和规模测试？ | A | “协商供应商合同”符合完整业务流程、业务目标显著贡献和适当规模的要求。 |
复习建议
- 分层架构 (Layered Architecture):
• 理解视图层、模型层和持久层的职责及其依赖关系。 - OOAD 工件 (OOAD Artifacts):
• 掌握序列图、活动图、状态图和类图的适用场景。 - 软件工程维度 (Software Engineering Dimensions):
• 熟悉 UP 的核心原则（迭代开发、可视化建模、变更控制）。 - 软件质量维度 (Software Quality Dimensions):
• 区分质量维度和质量评估过程。 - 用例设计 (Use-Case Design):
• 理解有效用例的标准（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. 一个对象可以同时处于多个状态
B. 状态机可以有多个终止状态
C. 一个状态可以记住上一个子状态
D. 转换可以有条件触发
正确答案: A
解释 (Explanation):
• A. 错误:
• 在传统的有限状态机（FSM）中，一个对象在同一时间只能处于一个状态。复合状态（Composite State）可以包含子状态，但整体上仍被视为一个状态。
• B. 正确:
• 状态机可以定义多个终止状态，表示不同的结束条件。
• C. 正确:
• 状态可以通过历史记录（History Pseudostate）记住上一个子状态。
• D. 正确:
• 转换可以基于条件触发（如事件发生且满足特定条件）。
12. Which model represents the following code generated by a Modeling tool?
英文:1
2
3
4Class Order {
private Customer recipient;
// ….
}
A. Design A
B. Design B
C. Design C
D. None of the above
中文:
以下建模工具生成的代码表示哪种模型？1
2
3
4类 Order {
私有 Customer recipient;
// ….
}
A. 设计 A
B. 设计 B
C. 设计 C
D. 以上都不是
正确答案: D
解释 (Explanation):
• 代码分析:
• Order 类包含一个私有属性 recipient，类型为 Customer，表示订单与客户之间的关系。
• 该代码仅描述了类的结构和属性，未明确体现设计模式或特定的设计视图（如类图、领域模型等）。
• 选项 D 的正确性:
• 由于代码未明确对应某种特定的设计模型（如 Design A、Design B 或 Design C），因此选择“以上都不是”。
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
中文:
在支付序列图中，CreditProcessor 类必须实现哪些方法？
A. 检查信用、生成确认码、显示确认
B. 检查信用、生成确认码
C. 检查信用、生成确认码、预订座位
D. 检查信用、预订座位、显示确认
正确答案: B
解释 (Explanation):
• CreditProcessor 类的职责:
• 根据支付序列图的逻辑，CreditProcessor 的主要职责是验证信用并生成确认码。
• 选项 B 的正确性:
• check Credit 和 generate Confirmation Code 是 CreditProcessor 的核心功能。
• 其他选项的错误性:
• A 和 D: display Confirmation 通常是视图层或用户界面的职责，不属于 CreditProcessor 的职责范围。
• C: Reserve seat 是预订系统的功能，与信用处理无关。
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
中文:
在进行领域分析时，类图应主要用来表示：
A. 对象之间发送的消息
B. 实现对象（如包装器和设备）
C. 业务对象和实现对象（如包装器和设备）
D. 业务对象
正确答案: D
解释 (Explanation):
• 领域分析的核心目标:
• 识别系统中的关键业务概念及其关系，而不是关注实现细节。
• 选项 D 的正确性:
• 类图在领域分析中应专注于业务对象（如订单、客户、产品等），而不是实现细节。
• 其他选项的错误性:
• A: 消息发送是序列图或通信图的职责，而非类图。
• B 和 C: 实现对象（如包装器、设备）属于设计阶段的内容，不应在领域分析的类图中体现。
15. The following are the requirements for a Report-generation module in an application:
英文:
1) When new data is generated, the user-interface should be refreshed automatically to reflect the largest values.
2) Multiple view types are possible.
Which of the following Model and View interactions BEST satisfies the above requirement?
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.
中文:
以下是应用程序中报告生成模块的需求：
1) 当新数据生成时，用户界面应自动刷新以反映最大值。
2) 可能存在多种视图类型。
哪种模型与视图的交互方式最能满足上述需求？
A. 在视图和模型之间建立订阅/通知机制，模型根据视图类型更新视图。
B. 在视图和模型层之间建立订阅/通知机制，使视图能够接收到变更通知。
C. 在模型中开发智能逻辑，根据视图类型决定刷新哪些视图。
D. 将视图和模型层合并为一个实体，使交互本地化且通知即时。
正确答案: A
解释 (Explanation):
• 需求分析:
• 需求 1 要求模型能够感知数据变化并通知视图刷新。
• 需求 2 要求支持多种视图类型，并根据视图类型动态更新内容。
• 选项 A 的正确性:
• 订阅/通知机制 (Subscribe/Notify Mechanism): 模型通过订阅/通知机制感知数据变化，并根据视图类型动态更新视图。
• 灵活性: 支持多种视图类型，并确保视图与模型的解耦。
• 其他选项的错误性:
• B: 仅实现了通知机制，但未明确如何根据视图类型更新视图。
• C: 将智能逻辑放在模型中违反了关注点分离原则，视图应负责决定如何显示数据。
• D: 合并视图和模型层会导致耦合性增加，违背了 MVC 或 MVVM 等设计模式的原则。
总结表格
| 问题编号 | 英文问题 | 中文问题 | 正确答案 | 关键概念 |
|---|---|---|---|---|
| 11 | Which of the following statement is false? | 以下哪项陈述是错误的？ | A | 一个对象在同一时间只能处于一个状态，复合状态是整体状态。 |
| 12 | Which model represents the following code? | 哪种模型表示以下代码？ | D | 代码仅描述类结构，未明确对应特定设计模型。 |
| 13 | What methods MUST be implemented by CreditProcessor? | CreditProcessor 类必须实现哪些方法？ |
B | CreditProcessor 的职责是验证信用并生成确认码，不涉及显示或预订功能。 |
| 14 | What should the class diagram represent in domain analysis? | 领域分析中类图应表示什么？ | D | 类图应专注于业务对象，而非实现细节或消息传递。 |
| 15 | Which Model-View interaction satisfies the requirements? | 哪种模型-视图交互满足需求？ | A | 订阅/通知机制结合视图类型动态更新视图，满足需求。 |
复习建议
- 状态机 (State Machine):
• 理解对象在同一时间只能处于一个状态，复合状态是整体状态。 - 领域分析 (Domain Analysis):
• 类图应专注于业务对象，而非实现细节或消息传递。 - 模型-视图交互 (Model-View Interaction):
• 掌握订阅/通知机制的设计原则，确保视图与模型的解耦。 - 职责分离 (Separation of Concerns):
• 模型负责业务逻辑，视图负责显示逻辑，避免将智能逻辑放在模型中。
以下是完整的题目、选项、答案和解释，包含中英文对照，确保清晰易懂：
1. Stereotypes can be applied to many UML elements such as class, package, and associations.
英文:
True (T)
中文:
构造型（Stereotypes）可以应用于许多 UML 元素，如类、包和关联。
正确答案: T
解释 (Explanation):
• 构造型 (Stereotypes):
• 是 UML 的扩展机制，用于为标准 UML 元素添加特定语义。
• 可以应用于类、包、关联、方法、属性等 UML 元素。
• 示例：<<interface>>、<<abstract>> 等。
2. Use cases are an object-oriented way to handle requirements. Therefore, they don’t fit very well into non-object-oriented projects.
英文:
False (F)
中文:
用例是一种面向对象的需求处理方式，因此它们不太适合非面向对象的项目。
正确答案: F
解释 (Explanation):
• 用例 (Use Cases):
• 是一种需求建模方法，用于描述系统的功能需求。
• 虽然用例起源于面向对象方法，但它们也可以用于非面向对象的项目（如过程式编程或函数式编程）。
• 用例的核心是描述“系统做什么”，与具体的编程范式无关。
3. A dependency between packages indicates that some element in the dependent package depends on some element(s) in the independent package.
英文:
True (T)
中文:
包之间的依赖关系表明依赖包中的某些元素依赖于独立包中的某些元素。
正确答案: T
解释 (Explanation):
• 包依赖 (Package Dependency):
• 表示一个包中的元素依赖于另一个包中的元素。
• 示例：Package A 中的类使用了 Package B 中的类，则 Package A 依赖于 Package B。
• UML 表示:
• 使用带箭头的虚线表示依赖关系，箭头指向独立包。
4. It is worthwhile to draw a state chart diagram for every class you create.
英文:
False (F)
中文:
为每个创建的类绘制状态图是值得的。
正确答案: F
解释 (Explanation):
• 状态图 (State Machine Diagram):
• 用于描述对象在其生命周期中的状态变化。
• 适用场景: 仅适用于具有复杂状态变化的类（如订单、工作流等）。
• 不适用场景: 对于没有复杂状态变化的类（如简单的 DTO 或工具类），绘制状态图是多余的。
5. Although the communication diagram has the same semantics with the sequence diagram, they have different representations.
英文:
True (T)
中文:
尽管通信图与序列图具有相同的语义，但它们的表示方式不同。
正确答案: T
解释 (Explanation):
• 通信图 (Communication Diagram):
• 强调对象之间的关系和消息传递，使用链接和消息编号表示交互顺序。
• 序列图 (Sequence 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.
英文:
True (T)
中文:
Protected Variation（GRASP 模式）的理念是设计对象和系统，使它们的不稳定性不会对其他元素产生不良影响。
正确答案: T
解释 (Explanation):
• Protected Variation (保护变化):
• 是 GRASP 模式中的一种设计原则，旨在通过封装可能变化的部分来减少对系统的影响。
• 目标: 使系统对变化的部分具有鲁棒性，避免变化扩散到其他部分。
• 实现方式: 使用接口、抽象类或包装器来隔离变化。
7. The inception phase in UP usually is more than a few weeks long for most projects.
英文:
False (F)
中文:
统一过程（UP）中的初始阶段通常对大多数项目来说持续数周以上。
正确答案: F
解释 (Explanation):
• 初始阶段 (Inception Phase):
• 是 UP 的第一个阶段，主要目标是定义项目的范围和可行性。
• 持续时间: 通常较短（几周），具体取决于项目的规模和复杂性。
• 目标: 确定“做正确的事”，而不是详细设计或实现。
8. The purpose of elaboration is to fully and carefully define models, which are translated into code during construction.
英文:
True (T)
中文:
细化阶段的目标是全面而仔细地定义模型，这些模型将在构造阶段转化为代码。
正确答案: T
解释 (Explanation):
• 细化阶段 (Elaboration Phase):
• 是 UP 的第二个阶段，主要目标是定义系统的架构和核心功能。
• 重点:
◦ 定义系统的主要结构和功能。
◦ 验证技术可行性。
◦ 创建初步的设计模型（如类图、序列图）。
• 输出: 这些模型将在构造阶段转化为代码。
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.
英文:
True (T)
中文:
系统序列图是一幅图，展示了一个用例的特定场景中外部参与者生成的事件、事件的顺序以及系统间的事件。
正确答案: T
解释 (Explanation):
• 系统序列图 (System Sequence Diagram):
• 描述系统与外部参与者之间的交互，展示消息的顺序。
• 主要元素:
◦ 参与者（Actor）。
◦ 系统（System）。
◦ 消息（Message）。
• 适用场景: 用于描述特定用例场景中的交互。
10. Strategy pattern allows one of a family of algorithms to be selected on-the-fly at runtime.
英文:
True (T)
中文:
策略模式允许在运行时动态选择一组算法中的一个。
正确答案: T
解释 (Explanation):
• 策略模式 (Strategy Pattern):
• 是 GoF 设计模式之一，定义了一系列算法，并将它们封装为独立的类，使它们可以互换。
• 特点:
◦ 在运行时动态选择算法。
◦ 避免使用条件语句（如 if-else 或 switch）来选择算法。
• 示例: 支付方式（信用卡、支付宝、微信支付）。
总结表格
| 问题编号 | 英文问题 | 中文问题 | 正确答案 | 关键概念 |
|---|---|---|---|---|
| 1 | Stereotypes can be applied to many UML elements such as class, package, and associations. | 构造型可以应用于许多 UML 元素，如类、包和关联。 | T | 构造型用于为 UML 元素添加特定语义，可应用于类、包、关联等。 |
| 2 | Use cases are an object-oriented way to handle requirements. Therefore, they don’t fit very well into non-object-oriented projects. | 用例是一种面向对象的需求处理方式，因此它们不太适合非面向对象的项目。 | F | 用例可以用于非面向对象项目，因为它们描述“系统做什么”，与编程范式无关。 |
| 3 | A dependency between packages indicates that some element in the dependent package depends on some element(s) in the independent package. | 包之间的依赖关系表明依赖包中的某些元素依赖于独立包中的某些元素。 | T | 包依赖表示一个包中的元素依赖于另一个包中的元素。 |
| 4 | It is worthwhile to draw a state chart diagram for every class you create. | 为每个创建的类绘制状态图是值得的。 | F | 状态图仅适用于具有复杂状态变化的类，简单类不需要绘制状态图。 |
| 5 | Although the communication diagram has the same semantics with the sequence diagram, they have different representations. | 尽管通信图与序列图具有相同的语义，但它们的表示方式不同。 | T | 通信图强调关系，序列图强调时间顺序，两者语义相同但表示方式不同。 |
| 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. | Protected Variation 的理念是设计对象和系统，使它们的不稳定性不会对其他元素产生不良影响。 | T | Protected Variation 是 GRASP 模式之一，用于封装可能变化的部分以减少对系统的影响。 |
| 7 | The inception phase in UP usually is more than a few weeks long for most projects. | 统一过程中的初始阶段通常对大多数项目来说持续数周以上。 | F | 初始阶段通常较短（几周），目标是定义项目范围和可行性。 |
| 8 | The purpose of elaboration is to fully and carefully define models, which are translated into code during construction. | 细化阶段的目标是全面而仔细地定义模型，这些模型将在构造阶段转化为代码。 | T | 细化阶段定义系统架构和核心功能，为构造阶段提供基础。 |
| 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 | 系统序列图描述系统与外部参与者的交互，展示消息的顺序。 |
| 10 | Strategy pattern allows one of a family of algorithms to be selected on-the-fly at runtime. | 策略模式允许在运行时动态选择一组算法中的一个。 | T | 策略模式封装算法，允许在运行时动态选择算法，避免条件语句。 |
复习建议
- 构造型 (Stereotypes):
• 理解构造型在 UML 中的作用及其适用范围。 - 用例 (Use Cases):
• 掌握用例的适用性，了解其在非面向对象项目中的应用。 - 包依赖 (Package Dependency):
• 理解包依赖的语义及其在系统设计中的意义。 - 状态图 (State Machine Diagram):
• 明确状态图的适用场景，避免过度建模。 - Protected Variation:
• 掌握 GRASP 模式中的 Protected Variation 原则及其实现方式。 - 细化阶段 (Elaboration Phase):
• 理解细化阶段的目标和输出，避免与初始阶段混淆。 - 系统序列图 (System Sequence Diagram):
• 掌握系统序列图的用途和表示方法。 - 策略模式 (Strategy Pattern):
• 理解策略模式的核心思想及其在运行时动态选择算法的应用。
以下是简答题的答案，包含中英文对照，确保清晰易懂：
1. What are the main phases of the Unified process? Explain them in a few words.
英文答案:
The Unified Process (UP) has four main phases:
Inception Phase:
• Focuses on defining the project scope, feasibility, and high-level requirements.
• Key deliverables: Use case model, initial risk assessment, and project plan.Elaboration Phase:
• Focuses on refining the architecture, identifying key use cases, and validating technical feasibility.
• Key deliverables: Software architecture document, detailed design of critical components.Construction Phase:
• Focuses on implementing and testing the system based on the refined design.
• Key deliverables: Executable software, complete design documentation.Transition Phase:
• Focuses on deploying the system, conducting user acceptance testing, and addressing feedback.
• Key deliverables: Deployed system, final documentation, and training materials.
中文答案:
统一过程（UP）有四个主要阶段：
初始阶段 (Inception Phase):
• 关注定义项目范围、可行性和高层次需求。
• 主要交付物：用例模型、初步风险评估和项目计划。细化阶段 (Elaboration Phase):
• 关注完善系统架构，识别关键用例，并验证技术可行性。
• 主要交付物：软件架构文档、关键组件的详细设计。构造阶段 (Construction Phase):
• 关注基于完善的设计实现和测试系统。
• 主要交付物：可执行软件、完整的设计文档。交付阶段 (Transition Phase):
• 关注部署系统、进行用户验收测试并处理反馈。
• 主要交付物：已部署的系统、最终文档和培训材料。
2. Explain briefly what is the Adapter design pattern. Example of its use.
英文答案:
The Adapter Design Pattern is a structural design pattern that allows incompatible interfaces to work together by converting the interface of a class into another interface that clients expect. It acts as a bridge between two incompatible interfaces.
• Purpose: To make two incompatible interfaces compatible without modifying their source code.
• Example Use Case:
• A third-party library provides a LegacyPrinter class with a method printText(String text).
• Your application expects a ModernPrinter interface with a method print(String document).
• An adapter class (LegacyPrinterAdapter) implements the ModernPrinter interface and internally uses the LegacyPrinter class to fulfill the request.
Code Example:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34// Target Interface
interface ModernPrinter {
void print(String document);
}
// Adaptee
class LegacyPrinter {
void printText(String text) {
System.out.println("Legacy Printer: " + text);
}
}
// Adapter
class LegacyPrinterAdapter implements ModernPrinter {
private LegacyPrinter legacyPrinter;
public LegacyPrinterAdapter(LegacyPrinter legacyPrinter) {
this.legacyPrinter = legacyPrinter;
}
public void print(String document) {
legacyPrinter.printText(document);
}
}
// Client Code
public class Main {
public static void main(String[] args) {
LegacyPrinter legacyPrinter = new LegacyPrinter();
ModernPrinter printer = new LegacyPrinterAdapter(legacyPrinter);
printer.print("Hello, World!");
}
}
中文答案:
适配器设计模式 (Adapter Design Pattern) 是一种结构型设计模式，通过将一个类的接口转换为另一个接口，使不兼容的接口能够协同工作。它充当两个不兼容接口之间的桥梁。
• 目的: 在不修改源代码的情况下，使两个不兼容的接口兼容。
• 示例用例:
• 某第三方库提供了一个 LegacyPrinter 类，其方法为 printText(String text)。
• 您的应用程序期望一个 ModernPrinter 接口，其方法为 print(String document)。
• 适配器类 (LegacyPrinterAdapter) 实现了 ModernPrinter 接口，并在内部使用 LegacyPrinter 类来完成请求。
代码示例:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34// 目标接口
interface ModernPrinter {
void print(String document);
}
// 被适配者
class LegacyPrinter {
void printText(String text) {
System.out.println("Legacy Printer: " + text);
}
}
// 适配器
class LegacyPrinterAdapter implements ModernPrinter {
private LegacyPrinter legacyPrinter;
public LegacyPrinterAdapter(LegacyPrinter legacyPrinter) {
this.legacyPrinter = legacyPrinter;
}
public void print(String document) {
legacyPrinter.printText(document);
}
}
// 客户端代码
public class Main {
public static void main(String[] args) {
LegacyPrinter legacyPrinter = new LegacyPrinter();
ModernPrinter printer = new LegacyPrinterAdapter(legacyPrinter);
printer.print("Hello, World!");
}
}
3. Please name and briefly describe the “4+1 view” of software architecture adopted in RUP.
英文答案:
The 4+1 View Model in RUP (Rational Unified Process) is a framework for describing software architecture from multiple perspectives. It includes:
Logical View:
• Focuses on the functional requirements of the system.
• Describes the design of classes, their relationships, and interactions.
• Key artifact: Class diagrams.Process View:
• Focuses on the runtime behavior of the system, including concurrency and synchronization.
• Describes how objects interact dynamically.
• Key artifact: Sequence diagrams, activity diagrams.Physical View (Deployment View):
• Focuses on the physical deployment of the system, including hardware and software components.
• Describes how the system is distributed across nodes.
• Key artifact: Deployment diagrams.Development View:
• Focuses on the organization of the software in the development environment.
• Describes the structure of modules, packages, and files.
• Key artifact: Component diagrams.Use Case View (Scenarios):
• Focuses on the functional scenarios and user interactions with the system.
• Provides a narrative description of how the system is used.
• Key artifact: Use case diagrams, sequence diagrams.
中文答案:
4+1 视图模型 (4+1 View Model) 是 RUP（Rational Unified Process）中用于从多个角度描述软件架构的框架。它包括以下视图：
逻辑视图 (Logical View):
• 关注系统的功能需求。
• 描述类的设计、类之间的关系及其交互。
• 主要工件：类图。过程视图 (Process View):
• 关注系统的运行时行为，包括并发性和同步性。
• 描述对象如何动态交互。
• 主要工件：序列图、活动图。物理视图（部署视图，Physical View/Deployment View):
• 关注系统的物理部署，包括硬件和软件组件。
• 描述系统如何在节点上分布。
• 主要工件：部署图。开发视图 (Development View):
• 关注软件开发环境中的软件组织。
• 描述模块、包和文件的结构。
• 主要工件：组件图。用例视图 (Use Case View):
• 关注功能场景和用户与系统的交互。
• 提供系统如何使用的叙述性描述。
• 主要工件：用例图、序列图。
总结
| 问题编号 | 英文问题 | 中文问题 | 关键概念 |
|---|---|---|---|
| 1 | What are the main phases of the Unified process? Explain them in a few words. | 统一过程的主要阶段是什么？简要解释。 | 初始、细化、构造、交付四个阶段，分别关注项目范围、架构设计、实现测试和部署。 |
| 2 | Explain briefly what is the Adapter design pattern. Example of its use. | 简要解释适配器设计模式，并举例说明其用途。 | 适配器模式用于使不兼容的接口兼容，示例：第三方库与应用程序接口的适配。 |
| 3 | Please name and briefly describe the “4+1 view” of software architecture. | 请命名并简要描述 RUP 中采用的“4+1 视图”模型。 | 逻辑视图、过程视图、物理视图、开发视图和用例视图，分别从不同角度描述软件架构。 |
复习建议
- 统一过程 (UP):
• 掌握四个主要阶段的重点和交付物，理解每个阶段的目标。 - 适配器模式 (Adapter Pattern):
• 理解适配器模式的核心思想，掌握其应用场景和实现方式。 - 4+1 视图模型:
• 理解每个视图的用途和主要工件，明确它们在软件架构描述中的作用。
问题 (Question)
英文:
Draw a class diagram for the following scenario. Be sure to include multiplicities on the ends of the connectors.
The following scenario is for a pet store. Each pet store has up to 20 furry (毛皮的) friends and 10 birds. Each pet has a vaccination (疫苗) history. Furry friends are either dogs or cats. Each furry friend has a microchip (微型芯片) implant for identification. Each microchip has a unique ID number.
中文:
为以下场景绘制类图。请务必在连接器的两端标注重数。
以下场景是一个宠物店。每个宠物店最多有 20 只毛皮宠物和 10 只鸟。每只宠物都有疫苗接种记录。毛皮宠物包括狗和猫。每只毛皮宠物都有一个用于识别的微型芯片植入物。每个微型芯片都有一个唯一的 ID 编号。
答案 (Answer)
类图描述 (Class Diagram Description)
类 (Classes):
•PetStore(宠物店)
•Pet(宠物)
•FurryFriend(毛皮宠物)
•Dog(狗)
•Cat(猫)
•Bird(鸟)
•VaccinationHistory(疫苗接种记录)
•Microchip(微型芯片)关系 (Relationships):
•PetStore包含最多 20 只FurryFriend和最多 10 只Bird。
•FurryFriend是Pet的子类，Dog和Cat是FurryFriend的子类。
• 每只Pet都有一个VaccinationHistory。
• 每只FurryFriend都有一个Microchip，并且Microchip有一个唯一的 ID。多重性 (Multiplicities):
•PetStore到Pet: 1 到 20 (最多 20 只毛皮宠物) 和 1 到 10 (最多 10 只鸟)。
•Pet到VaccinationHistory: 1 对 1 (每只宠物有一个疫苗接种记录)。
•FurryFriend到Microchip: 1 对 1 (每只毛皮宠物有一个微型芯片)。
类图 (Class Diagram)
1 | +-------------------+ +-------------------+ |
类图解释 (Explanation of the Class Diagram)
PetStore类:
• 表示宠物店。
• 包含两个集合：furryFriends（毛皮宠物，最多 20 只）和birds（鸟，最多 10 只）。
• 使用聚合关系（Aggregation）表示宠物店与宠物之间的关系，因为宠物可以独立于宠物店存在。Pet类:
• 表示宠物，是FurryFriend、Dog、Cat和Bird的基类。
• 每只宠物有一个VaccinationHistory对象，表示疫苗接种记录。FurryFriend类:
• 是Pet的子类，表示毛皮宠物。
• 每只毛皮宠物有一个Microchip对象，用于唯一标识。Dog和Cat类:
• 是FurryFriend的子类，分别表示狗和猫。Bird类:
• 是Pet的子类，表示鸟。VaccinationHistory类:
• 表示疫苗接种记录，包含宠物的疫苗接种信息。Microchip类:
• 表示微型芯片，包含一个唯一的 ID 编号。
总结 (Summary)
| 问题编号 | 英文问题 | 中文问题 | 答案 | 解释 (Explanation) |
|---|---|---|---|---|
| 1 | Draw a class diagram for the following scenario. Be sure to include multiplicities on the ends of the connectors. The following scenario is for a pet store. Each pet store has up to 20 furry friends and 10 birds. Each pet has a vaccination history. Furry friends are either dogs or cats. Each furry friend has a microchip implant for identification. Each microchip has a unique ID number. | 为以下场景绘制类图。请务必在连接器的两端标注重数。以下场景是一个宠物店。每个宠物店最多有 20 只毛皮宠物和 10 只鸟。每只宠物都有疫苗接种记录。毛皮宠物包括狗和猫。每只毛皮宠物都有一个用于识别的微型芯片植入物。每个微型芯片都有一个唯一的 ID 编号。 | 类图包含以下类：PetStore、Pet、FurryFriend、Dog、Cat、Bird、VaccinationHistory 和 Microchip。 |
PetStore 包含最多 20 只毛皮宠物和 10 只鸟，FurryFriend 是 Pet 的子类，Dog 和 Cat 是 FurryFriend 的子类。每只宠物有一个疫苗接种记录，每只毛皮宠物有一个微型芯片。 |
复习建议 (Review Suggestions)
聚合关系 (Aggregation):
• 理解聚合关系的含义，表示“整体-部分”关系，但部分可以独立存在。例如，宠物店和宠物之间的关系。继承关系 (Inheritance):
• 理解继承关系的含义，表示“是一个”关系。例如，Dog和Cat是FurryFriend的子类。多重性 (Multiplicities):
• 掌握如何在类图中表示多重性。例如，PetStore到Pet的关系是 1 到 20 和 1 到 10。类图设计:
• 确保类图清晰地表达了系统的结构和关系，避免过度复杂化。
问题描述 (Problem Description)
假设您需要使用面向对象分析和设计（OOA/D）技术开发一个销售点（POS）系统。POS 系统是一种用于记录销售、处理支付并通常用于零售店的计算机化应用程序。处理销售将是该系统必须执行的关键功能之一。
以下是处理销售的简化场景：
- 顾客带着要购买的物品到达零售店的收银台。
- 收银员使用 POS 系统的收银机记录每件购买的商品。
- 每件商品都有一份产品规格说明，属于产品目录。
- 系统显示累计金额和商品明细。
- 顾客输入支付信息，系统验证并记录支付信息。
- 系统更新库存（库存：库存中商品的数量）。
- 顾客从系统收到收据，然后带着商品离开。
- 销售记录被记录到账簿中，供经理在一段时间内查看。
请使用面向对象分析和设计的方法对系统的关键功能进行建模。
1. 绘制 UML 用例图 (Draw a UML Use Case Diagram)
英文问题 (English Question):
Draw a UML use case diagram for the system including their relationships.
中文问题 (Chinese Question):
为系统绘制 UML 用例图，并包括它们之间的关系。
答案 (Answer):
用例图描述 (Use Case Diagram Description):
• 参与者 (Actors):
• 顾客 (Customer): 带着商品到达收银台并接收收据。
• 收银员 (Cashier): 使用 POS 系统记录商品、处理支付并打印收据。
• 经理 (Manager): 查看账簿中的销售记录。
• 用例 (Use Cases):
• 记录商品 (Record Items): 收银员记录每件商品。
• 计算总金额 (Calculate Total): 系统计算累计金额。
• 处理支付 (Process Payment): 顾客输入支付信息，系统验证并记录支付。
• 更新库存 (Update Inventory): 系统更新库存数量。
• 打印收据 (Print Receipt): 系统为顾客打印收据。
• 记录销售 (Log Sale): 系统将销售记录到账簿中。
• 查看销售记录 (View Sales Records): 经理查看账簿中的销售记录。
用例图 (Use Case Diagram):
1 | +-------------------+ +-------------------+ |
解释 (Explanation):
• 顾客 (Customer):
• 与“记录商品”和“打印收据”用例相关联。
• 收银员 (Cashier):
• 负责“记录商品”、“计算总金额”、“处理支付”、“更新库存”、“打印收据”和“记录销售”。
• 经理 (Manager):
• 负责“查看销售记录”。
• 关系:
• Include (包含): “计算总金额”是“处理支付”的一部分。
• Extend (扩展): “打印收据”是“处理支付”的一部分。
2. 给出类图 (Give the Class Diagram)
英文问题 (English Question):
Give the class diagram with the analysis classes representing business entities involved in the system (names and brief descriptions only – no attributes or operations), along with their relationships and multiplicities.
中文问题 (Chinese Question):
给出类图，包含系统中涉及的业务实体分析类（仅提供名称和简要描述，不需要属性或操作），以及它们的关系和多重性。
答案 (Answer):
类图描述 (Class Diagram Description):
• 主要类 (Classes):
• Customer: 表示顾客。
• Cashier: 表示收银员。
• Manager: 表示经理。
• Product: 表示商品。
• ProductCatalog: 表示产品目录。
• Inventory: 表示库存。
• Sale: 表示销售记录。
• Receipt: 表示收据。
• Payment: 表示支付信息。
• 关系 (Relationships):
• Customer 与 Sale: 顾客参与销售。
• Cashier 与 Sale: 收银员处理销售。
• Manager 与 Sale: 经理查看销售记录。
• Product 与 ProductCatalog: 商品属于产品目录。
• Product 与 Inventory: 商品与库存相关联。
• Sale 与 Receipt: 销售记录生成收据。
• Sale 与 Payment: 销售记录关联支付信息。
类图 (Class Diagram):
1 | +-------------------+ +-------------------+ |
解释 (Explanation):
• Customer: 与 Sale 类关联，表示顾客参与销售。
• Cashier: 与 Sale 类关联，表示收银员处理销售。
• Manager: 与 Sale 类关联，表示经理查看销售记录。
• Product: 属于 ProductCatalog，并与 Inventory 关联。
• Sale: 是核心类，关联 Receipt、Payment、Product 和 Inventory。
3. 边界类、控制类和实体类 (Boundary Classes, Control Classes, and Entity Classes)
英文问题 (English Question):
Give the boundary classes, control classes, and entity classes involved in the system to bear responsibility of “process sale” in the case of J2EE (names and brief descriptions with UML class stereotypes only – no attributes or operations).
中文问题 (Chinese Question):
在 J2EE 框架下，给出负责“处理销售”的边界类、控制类和实体类（仅提供名称和简要描述，使用 UML 类构造型，不需要属性或操作）。
答案 (Answer):
| 类别 (Category) | 类名 (Class Name) | 描述 (Description) | UML 构造型 (UML Stereotype) |
|---|---|---|---|
| 边界类 (Boundary) | SaleUI |
用户界面，用于与收银员交互 | <<Boundary>> |
| 边界类 (Boundary) | ReceiptUI |
用户界面，用于打印收据 | <<Boundary>> |
| 控制类 (Control) | SaleController |
处理销售逻辑 | <<Control>> |
| 控制类 (Control) | PaymentController |
处理支付逻辑 | <<Control>> |
| 实体类 (Entity) | Customer |
表示顾客 | <<Entity>> |
| 实体类 (Entity) | Product |
表示商品 | <<Entity>> |
| 实体类 (Entity) | Sale |
表示销售记录 | <<Entity>> |
| 实体类 (Entity) | Payment |
表示支付信息 | <<Entity>> |
| 实体类 (Entity) | Receipt |
表示收据 | <<Entity>> |
解释 (Explanation):
• 边界类 (Boundary Classes):
• 负责与用户交互，提供用户界面。
• 控制类 (Control Classes):
• 负责处理业务逻辑，如销售和支付。
• 实体类 (Entity Classes):
• 表示系统中的核心业务实体，如顾客、商品、销售记录等。
4. 绘制序列图 (Draw a UML Sequence Diagram)
英文问题 (English Question):
Draw a UML sequence diagram to model the use case of “process sale” in the case of J2EE.
中文问题 (Chinese Question):
绘制 UML 序列图，建模 J2EE 框架下“处理销售”的用例。
答案 (Answer):
1 | Customer -> SaleUI: 输入商品信息 |
解释 (Explanation):
• 流程:
- 顾客输入商品信息，
SaleUI将信息传递给SaleController。 SaleController查询商品信息并更新销售记录和库存。- 顾客输入支付信息，
PaymentController验证支付并记录支付信息。 - 系统生成收据并打印给顾客。
- 销售记录被保存到账簿中。
总结 (Summary)
| 问题编号 | 英文问题 | 中文问题 | 答案 | 解释 (Explanation) |
|---|---|---|---|---|
| 1 | Draw a UML use case diagram for the system including their relationships. | 为系统绘制 UML 用例图，并包括它们之间的关系。 | 用例图包含顾客、收银员、经理及其相关用例（记录商品、处理支付等）。 | 用例图清晰地描述了系统的功能及其参与者之间的关系。 |
| 2 | Give the class diagram with analysis classes. | 给出类图，包含分析类及其关系。 | 类图包含顾客、商品、库存、销售记录等实体类及其关系。 | 类图展示了系统中核心业务实体的结构和关系。 |
| 3 | Give boundary, control, and entity classes in J2EE. | 给出 J2EE 框架下的边界类、控制类和实体类。 | 边界类负责用户交互，控制类处理业务逻辑，实体类表示业务数据。 | 明确了 J2EE 框架中类的职责分工。 |
| 4 | Draw a UML sequence diagram for the use case “process sale”. | 绘制“处理销售”用例的序列图。 | 序列图展示了顾客、收银员、系统之间的交互流程。 | 序列图清晰地描述了“处理销售”用例的执行流程。 |
