2010UML
2010UML
问题1
题目：在用例的背景下，UML中哪种图可以用于描述系统操作员识别和处理的外部系统事件？
选项：
A. 状态图（Statechart Diagram）
B. 活动图（Activity Diagram）
C. 顺序图（Sequence Diagram）
D. 协作图（Collaboration Diagram）
在UML中，状态图（Statechart Diagram） 被选为正确答案的原因如下：
- 核心用途
状态图专门用于描述对象或系统在其生命周期中状态的变化，以及触发这些变化的外部事件。它强调系统如何根据当前状态对事件作出响应，并转换到新的状态。 - 与题干的匹配
题目要求描述“外部系统事件”（如操作员触发的动作）及其在用例中的处理。状态图能清晰展示：- 系统可能处于的状态（如“待机”、“运行中”、“错误”）。
- 由操作员触发的事件（如“启动系统”、“终止操作”）如何驱动状态转换。
- 状态相关的行为（如进入/退出状态时的操作）。
- 与其他选项的对比
- 活动图（B）：关注流程步骤和操作顺序，而非状态变化。适合描述用例的工作流程，但无法直接映射事件与状态的关系。
- 序列图（C）：展示对象间按时间顺序的消息交互，强调动态协作，而非系统内部状态逻辑。
- 协作图（D）（现称通信图）：与序列图类似，但侧重对象间结构关系，同样不直接表达状态机逻辑。
- 实际场景示例
例如，在“用户登录”用例中，系统可能处于“未认证”、“验证中”、“已认证”等状态。操作员（用户）触发“输入密码”、“提交”等事件，状态图可直观显示这些事件如何导致状态转换（如从“未认证”到“验证中”），以及验证失败时如何回到“未认证”状态。
结论：状态图（A）因其对状态转换和事件驱动的建模能力，成为描述外部事件在用例中处理的最佳选择。
中文解释：
• 状态图主要用于描述对象的状态变化，不适合描述外部事件的处理。
• 活动图强调工作流程和决策点，而不是外部事件的交互。
• 顺序图适合描述系统操作员如何识别和处理外部系统事件，因为它强调时间顺序上的消息传递。
• 协作图侧重于对象之间的关系，而不是时间顺序。
问题2
题目：我们为什么要建模？
选项：
A. 帮助可视化系统。
B. 给我们提供一个构建系统的模板。
C. 记录我们的决策。
D. 以上所有。
答案：D
解释：
• 帮助可视化系统：建模可以帮助我们直观地理解系统的结构和行为。
• 提供构建系统的模板：模型可以作为构建系统的蓝图或模板。
• 记录我们的决策：模型记录了设计过程中的决策，便于后续维护和理解。
中文解释：
• 建模可以帮助我们可视化系统，直观地理解其结构和行为。
• 模型可以作为构建系统的模板，指导系统的实现。
• 模型记录了设计过程中的决策，便于后续的维护和理解。
问题3
题目：以下哪个短语最能代表组合关系？
选项：
A. 是……的一部分。
B. 是……的一种。
C. 是唯一的……部分。
D. 是……的继承。
答案：A
解释：
• 组合关系：表示整体与部分的关系，部分不能独立于整体存在。选项A“是……的一部分”最能代表这种关系。
• 选项B“是……的一种”表示的是泛化关系（继承）。
• 选项C“是唯一的……部分”并不是标准的UML术语。
• 选项D“是……的继承”表示的是继承关系。
中文解释：
• 组合关系表示整体与部分的关系，部分不能独立于整体存在，选项A“是……的一部分”最能代表这种关系。
• 选项B“是……的一种”表示的是泛化关系（继承）。
• 选项C“是唯一的……部分”不是标准的UML术语。
• 选项D“是……的继承”表示的是继承关系。
问题4
题目：在设计可重用性时，以下哪项是好的实践？
选项：
A. 定义一个持久化框架，为持久化对象提供服务。
B. 使用设计模式，其中包含完整的解决方案。
C. 使用控制器对象来控制流程。
D. 为类分配职责，使它们之间的耦合度保持高。
E. A和B
F. A、B和C
G. A、B、C和D
答案：F
解释：
• A：定义持久化框架可以提高代码的重用性和一致性。
• B：使用设计模式可以提供经过验证的解决方案，提高代码的可重用性。
• C：控制器对象可以帮助管理流程，提高代码的模块化和可重用性。
• D：高耦合度会降低代码的可重用性，因此不推荐。
中文解释：
• 定义持久化框架可以提高代码的重用性和一致性。
• 使用设计模式可以提供经过验证的解决方案，提高代码的可重用性。
• 控制器对象可以帮助管理流程，提高代码的模块化和可重用性。
• 高耦合度会降低代码的可重用性，因此不推荐。
问题5
题目：以下哪项陈述是不正确的？
选项：
A. 子系统是一个具有单独规范和实现部分的包。
B. 子系统是一个具有行为和接口的离散实体。
C. 子系统可以通过构造型<
D. 子系统是一个仅具有规范部分的包。
答案：D
解释：
• A：子系统通常是一个包，包含规范和实现部分。
• B：子系统是一个独立的实体，具有行为和接口。
• C：子系统可以通过构造型<
• D：子系统不仅包含规范部分，还包含实现部分，因此这个陈述是不正确的。
中文解释：
• 子系统通常是一个包，包含规范和实现部分，因此选项A是正确的。
• 子系统是一个独立的实体，具有行为和接口，因此选项B是正确的。
• 子系统可以通过构造型<
• 子系统不仅包含规范部分，还包含实现部分，因此选项D是不正确的。
以下是问题的中文答案和解释：
问题 6：
在面向对象系统中，以下哪种分配职责的方式是 不 可取的？
A. 相对均匀地分配到各个类中
B. 集中在少数控制类中
C. 根据交互图中的消息传递分配
D. 根据用例图分配
E. A 和 B
F. B, C 和 D
答案： A
解释：
既不能均匀分配，也不能够集中在少数类上，世界上并没有所谓一劳永逸的法子，随机应变而已。
问题 7：
为了展示多个对象在单个用例中的协作，以下哪种面向对象分析与设计（OOAD）工件最有用？
A. 交互图
B. 活动图
C. 状态图
D. 类图
答案： A
解释：
交互图（如序列图或通信图）专门用于展示多个对象在单个用例中的协作，通过描述对象之间传递的消息来体现协作关系。活动图关注工作流和过程逻辑，状态图关注单个对象的状态变化，类图关注静态结构。因此，最有用的是 A。
问题 9：
关于部署图，以下哪项是正确的？
A. 由于消息总是会得到某种响应，部署组件之间的依赖关系是双向的。
B. 部署组件之间的依赖关系往往与包依赖关系相同。
C. 部署图不用于显示代码的物理模块。
D. 部署图不显示系统在计算机上的物理分布。
答案： C
解释：
部署图用于展示软件组件（如可执行文件、库）在硬件节点（如服务器、设备）上的物理部署。它不用于显示代码的物理模块（选项 C 正确）。
• 选项 A 错误，因为部署图中的依赖关系不一定是双向的。
• 选项 B 错误，因为部署依赖关系是关于硬件和软件部署的，而不是包依赖关系。
• 选项 D 错误，因为部署图确实显示系统在计算机上的物理分布。
因此，正确答案是 C。
部署图所现实的是软件组件在硬件节点上的物理部署，和代码是没有多大关系的。
问题 10：
在使用 OOAD 工件组织和分配项目团队职责时，最佳做法是：
A. 将用例均匀分配给团队成员，并让他们尽可能独立工作，以最小化代码依赖。
B. 指定一个团队负责实现与“通用代码路径”相关的交互图，另一个团队负责实现与“代码路径变体”（例如条件或错误路径）相关的交互图。
C. 根据软件架构的层次划分团队，并让他们尽可能独立工作，以最小化层次之间的依赖。
D. 根据包图依赖关系划分团队，并利用用例为团队成员安排工作。
答案： C
解释：
最佳做法是根据软件架构的层次（如表示层、业务逻辑层、数据访问层）划分团队，并让他们尽可能独立工作，以最小化层次之间的依赖（选项 C）。这符合关注点分离原则，并确保模块化。
• 选项 A 效果较差，因为用例可能存在重叠，导致依赖关系。
• 选项 B 效率较低，因为它根据代码路径而不是架构层次划分团队。
• 选项 D 不太实用，因为包依赖关系并不总是与团队职责一致。
因此，正确答案是 C。
按层次进行分配是最好事情。
问题 11：
为了最有效地管理大型项目中不同包的团队，以下哪项应为真？
A. 一位技术负责人应控制项目细节，并将决策传达给不同团队。
B. 团队负责人应关注使用的数据库类型（如 DB2 UDB、Oracle、Sybase 或 Instant DB）。
C. 团队负责人应关注其包的内部设计质量，并指导团队成员。
D. 团队之间的沟通应尽量减少，以减少他们在独立处理包的用例时的开销负担。
答案： C
解释：
最有效的管理方式是让团队负责人关注其包的内部设计质量，并指导团队成员（选项 C）。这有助于确保每个包的设计和实现质量，同时促进团队成员的成长。
• 选项 A 错误，因为集中控制会降低团队的自主性和效率。
• 选项 B 错误，因为数据库类型的选择通常是架构师或技术负责人的职责，而不是团队负责人的主要关注点。
• 选项 D 错误，因为减少沟通可能导致团队之间的不一致和依赖问题。
因此，正确答案是 C。
问题 12：
用例 不能 用于：
A. 建模非行为方面，如数据需求、性能和安全性。
B. 捕获系统的行为方面。
C. 捕获系统的功能方面。
D. 在高层捕获业务流程。
答案： A
解释：
用例主要用于捕获系统的功能和行为方面（选项 B 和 C），以及在高层描述业务流程（选项 D）。然而，它不适合建模非行为方面，如数据需求、性能和安全性（选项 A）。这些方面通常通过其他工件（如数据模型、性能模型或安全模型）来描述。因此，正确答案是 A。
问题 13：
以下 Java 代码描述的两个类之间的关联是什么类型？1
2
3
4
5
6
7
8public class A {
private ArrayList<B> _Bs = new ArrayList<>();
public A(B b) {
this._Bs.add(b);
}
}
public class B {
}
A. 继承
B. 依赖
C. 组合
D. 聚合
B.依赖
问题 14：
参考下图，以下哪项是正确的？
A. 类“Teacher”是类“Professor”和类“Lecturer”的父类。
B. “Professor”的实例必须实现“Teacher”的所有行为。
C. 系统中存在“Teacher”的实例。
D. “Professor”是一种“Teacher”，“Lecturer”也是一种“Teacher”。
答案： B
可以注意到只是接口！
问题 15：
在需求工程过程中，软件工程师和系统用户应共同定义：
A. 用户使用系统的可见上下文
B. 关键软件属性
C. 系统的输入和输出
D. A 和 B
E. A、B 和 C
答案： A 。
问题 1：
请描述软件开发中的风险以及避免这些风险的方法（8 分）。
(1) 风险类型：
• 技术/架构风险
未经验证的技术、不确定的范围
• 资源风险
人员、技能、资金
• 业务风险
竞争、投资回报率（ROI）、供应商接口
• 进度风险
项目依赖、时间限制（一天只有 24 小时）
(2) 避免风险的方法：
• 迭代开发
• 管理需求
• 使用组件架构
• 可视化建模（UML）
• 持续验证质量
• 管理变更
Answer and Explanation (答案与解释)：
(1) Risk Types (风险类型):
Technical/Architectural Risks (技术/架构风险):
• Unproven Technology (未经验证的技术): 使用未经测试或未经验证的技术可能导致项目失败或性能问题。
• Uncertain Scope (不确定的范围): 需求不明确或频繁变更可能导致项目失控。Resource Risks (资源风险):
• People (人员): 缺乏有经验的开发人员或团队协作不佳会影响项目进度。
• Skills (技能): 团队缺乏必要的技术技能可能导致技术债务或质量问题。
• Funding (资金): 资金不足可能导致项目中断或资源短缺。Business Risks (业务风险):
• Competition (竞争): 市场竞争可能导致项目优先级变化或需求调整。
• ROI (投资回报率): 项目可能无法实现预期的投资回报。
• Supplier Interfaces (供应商接口): 依赖第三方供应商可能导致延迟或兼容性问题。Schedule Risks (进度风险):
• Project Dependencies (项目依赖): 依赖其他项目或团队可能导致进度延误。
• Time Constraints (时间限制): 时间不足可能导致开发质量下降或功能缺失。
(2) Approaches to Avoiding Risks (避免风险的方法):
Develop Iteratively (迭代开发):
• 通过迭代开发，逐步交付功能，减少范围不确定性和技术风险。
• Example: 使用敏捷开发方法（如 Scrum）分阶段交付功能。Manage Requirements (管理需求):
• 明确需求并通过需求管理工具（如 JIRA）跟踪变更，减少需求不确定性。
• Example: 定期与客户沟通，确保需求一致。Use Component Architectures (使用组件架构):
• 采用模块化设计，降低技术复杂性和维护成本。
• Example: 使用微服务架构将系统分解为独立组件。Model Visually (UML) (可视化建模):
• 使用 UML 图（如用例图、类图、序列图）清晰描述系统设计和行为，减少设计风险。
• Example: 在需求分析阶段使用用例图明确系统功能。Continuously Verify Quality (持续验证质量):
• 通过自动化测试和代码审查确保代码质量，减少缺陷风险。
• Example: 使用 CI/CD 工具（如 Jenkins）自动运行测试。Manage Change (管理变更):
• 通过变更控制流程管理需求变更，减少范围蔓延风险。
• Example: 使用变更请求表（Change Request Form）记录和评估变更影响。
总结：
软件开发中的风险包括技术、资源、业务和进度风险。通过迭代开发、需求管理、组件架构、可视化建模、持续验证质量和变更管理等方法，可以有效降低这些风险，确保项目成功。
问题 2：
请概述 RUP（Rational Unified Process）的阶段和工作流（5 分）。
4 个阶段和 9 个工作流。
Answer and Explanation (答案与解释)：
RUP 概述：
RUP（Rational Unified Process）是一种迭代式软件开发过程框架，强调风险管理和持续改进。它将开发过程分为4 个阶段和9 个工作流。
1. 4 个阶段 (4 Phases):
初始阶段 (Inception):
• 目标: 确定项目范围、主要需求和可行性。
• 关键活动: 创建项目愿景、识别主要风险、制定初步计划。
• 交付物: 项目愿景文档、初始需求文档、风险评估报告。细化阶段 (Elaboration):
• 目标: 定义系统架构、细化需求、降低主要风险。
• 关键活动: 设计系统架构、编写用例、制定详细计划。
• 交付物: 系统架构文档、用例模型、详细项目计划。构建阶段 (Construction):
• 目标: 开发系统的可运行版本。
• 关键活动: 编码、单元测试、集成测试。
• 交付物: 可运行的系统版本、测试报告。交付阶段 (Transition):
• 目标: 将系统交付给用户并确保其正常运行。
• 关键活动: 用户培训、系统部署、问题修复。
• 交付物: 最终系统版本、用户手册、支持文档。
2. 9 个工作流 (9 Workflows):
业务建模 (Business Modeling):
• 理解业务需求并将其转化为系统需求。需求 (Requirements):
• 捕获、分析和记录系统需求。分析与设计 (Analysis & Design):
• 将需求转化为系统设计和架构。实现 (Implementation):
• 编写代码并构建系统。测试 (Test):
• 验证系统是否满足需求。部署 (Deployment):
• 将系统交付给用户并确保其正常运行。配置与变更管理 (Configuration & Change Management):
• 管理系统的配置和变更。项目管理 (Project Management):
• 规划、监控和控制项目进度。环境 (Environment):
• 提供支持开发过程的工具和基础设施。
总结：
RUP 的 4 个阶段（初始、细化、构建、交付）和 9 个工作流（业务建模、需求、分析与设计、实现、测试、部署、配置与变更管理、项目管理、环境）共同构成了一个迭代式、风险驱动的软件开发过程框架。每个阶段和工作流都有明确的目标和交付物，确保项目按计划推进并满足用户需求。
问题 3：
请列出并简要描述 RUP 中采用的“4+1 视图”软件架构（5 分）。
用例视图 + 逻辑视图 + 实现视图 + 过程视图 + 部署视图。
Answer and Explanation (答案与解释)：
“4+1 视图”概述：
“4+1 视图”是软件架构的一种描述方法，通过多个视角全面描述系统的架构。它包括以下 5 个视图：
1. 用例视图 (Use-case View):
• 描述: 从用户角度描述系统的功能需求和行为。
• 作用: 帮助开发团队理解系统的核心功能和用户交互。
• 工具: 用例图（Use-case Diagram）。
• 示例: 在电商系统中，用例视图可能包括“用户下单”、“支付处理”等用例。
2. 逻辑视图 (Logical View):
• 描述: 描述系统的静态结构，包括类、对象、接口及其关系。
• 作用: 帮助开发团队理解系统的设计逻辑和组件之间的关系。
• 工具: 类图（Class Diagram）、对象图（Object Diagram）。
• 示例: 在电商系统中，逻辑视图可能包括“用户类”、“订单类”及其关系。
3. 实现视图 (Implementation View):
• 描述: 描述系统的物理实现，包括代码模块、库和组件。
• 作用: 帮助开发团队管理代码的组织和构建过程。
• 工具: 组件图（Component Diagram）。
• 示例: 在电商系统中，实现视图可能包括“用户管理模块”、“订单处理模块”等。
4. 过程视图 (Process View):
• 描述: 描述系统的运行时行为，包括进程、线程及其交互。
• 作用: 帮助开发团队理解系统的并发性和性能特征。
• 工具: 活动图（Activity Diagram）、序列图（Sequence Diagram）。
• 示例: 在电商系统中，过程视图可能包括“订单处理流程”、“支付流程”等。
5. 部署视图 (Deployment View):
• 描述: 描述系统的物理部署，包括硬件节点、网络配置和软件分布。
• 作用: 帮助开发团队理解系统在硬件环境中的部署方式。
• 工具: 部署图（Deployment Diagram）。
• 示例: 在电商系统中，部署视图可能包括“Web 服务器”、“数据库服务器”及其连接方式。
总结：
“4+1 视图”通过用例视图（功能需求）、逻辑视图（静态结构）、实现视图（代码实现）、过程视图（运行时行为）和部署视图（物理部署）全面描述软件架构。每个视图从不同角度关注系统的不同方面，帮助开发团队更清晰地理解和设计系统。
问题 4：
请描述 OOA/D（面向对象分析与设计）中的用例分析步骤（7 分）。
答案：
• 补充用例描述
• 对于每个用例实现：
▪ 从用例行为中寻找类
▪ 将用例行为分配到类中
• 对于每个分析类：
▪ 描述职责
▪ 描述属性和关联
▪ 限定分析机制
• 统一分析类
• 检查点
Answer and Explanation (答案与解释)：
OOA/D 中的用例分析步骤：
补充用例描述 (Supplement the Use Case Description):
• 描述: 完善用例的详细描述，包括前置条件、后置条件和主要流程。
• 作用: 确保用例描述完整、清晰，为后续分析提供基础。
• 示例: 在“用户登录”用例中，补充“用户输入用户名和密码”、“系统验证用户信息”等步骤。对于每个用例实现 (For each Use Case Realization):
• 从用例行为中寻找类 (Find Classes from Use Case Behavior):
◦ 描述: 分析用例行为，识别参与该行为的类。
◦ 作用: 确定系统中需要哪些类来实现用例功能。
◦ 示例: 在“用户登录”用例中，识别“用户类”、“认证类”等。
• 将用例行为分配到类中 (Distribute Use Case Behavior to Classes):
◦ 描述: 将用例中的行为分配给相应的类，明确每个类的职责。
◦ 作用: 确保每个类有明确的职责，避免职责重叠。
◦ 示例: 将“验证用户信息”行为分配给“认证类”。对于每个分析类 (For each resulting analysis class):
• 描述职责 (Describe Responsibilities):
◦ 描述: 明确每个类的职责和行为。
◦ 作用: 确保类设计符合单一职责原则。
◦ 示例: “认证类”的职责是“验证用户信息”。
• 描述属性和关联 (Describe Attributes and Associations):
◦ 描述: 定义类的属性及其与其他类的关系。
◦ 作用: 明确类的内部结构和外部关系。
◦ 示例: “用户类”的属性包括“用户名”、“密码”，与“认证类”有关联。
• 限定分析机制 (Qualify Analysis Mechanisms):
◦ 描述: 确定类实现所需的技术或机制（如数据库访问、网络通信）。
◦ 作用: 确保类设计考虑技术实现细节。
◦ 示例: “认证类”需要使用“数据库访问机制”验证用户信息。统一分析类 (Unify Analysis Classes):
• 描述: 整合不同用例中识别出的类，消除重复或冗余。
• 作用: 确保类设计一致且高效。
• 示例: 将“用户管理”和“用户登录”用例中的“用户类”统一为一个类。检查点 (Checkpoints):
• 描述: 验证用例分析的正确性和完整性。
• 作用: 确保分析结果符合需求和设计目标。
• 示例: 检查“用户登录”用例是否覆盖所有场景，类职责是否明确。
设计的补充步骤：
描述设计对象之间的交互 (Describe interaction between design objects):
• 描述: 使用序列图或协作图描述对象之间的交互。
• 作用: 明确对象在运行时如何协作完成任务。使用子系统简化序列图 (Simplify sequence diagrams using subsystems):
• 描述: 将复杂交互分解为子系统，简化序列图。
• 作用: 提高设计文档的可读性和可维护性。描述持久化相关行为 (Describe persistence related behavior):
• 描述: 定义对象如何与数据库或其他持久化机制交互。
• 作用: 确保系统能够持久化数据。细化事件流描述 (Refine the flow of events description):
• 描述: 完善用例事件流的详细描述。
• 作用: 确保设计文档与需求一致。统一类和子系统 (Unify classes and subsystems):
• 描述: 整合设计中的类和子系统，消除冗余。
• 作用: 确保设计结构清晰且高效。
总结：
OOA/D 中的用例分析步骤包括补充用例描述、寻找类并分配行为、描述类的职责、属性和关联、统一分析类和检查点。通过这些步骤，可以确保用例分析全面、清晰，并为后续设计提供坚实基础。设计阶段进一步细化对象交互、持久化行为和事件流描述，确保系统设计符合需求且易于实现。
判断改错题：
问题：
假设软件公司的员工可以按角色分类，如程序员（Coder）、项目经理（Project Manager）和软件工程师（Software Engineer）。下图所示的 UML 图被建议为满足公司员工角色变化的解决方案。请判断该解决方案是否正确，并解释你的判断依据。如果错误，请给出修改后的图（5 分）。
答案与解释：
1. 判断：
该解决方案不完全正确。虽然 UML 图正确地展示了继承关系，但设计存在以下问题：
• 角色分类不合理:
• “Coder”和“Software Engineer”在现实中通常是同一角色的不同表述，而不是独立的角色。将它们作为独立的子类会导致冗余。
• “Project Manager”是管理角色，而“Coder”和“Software Engineer”是技术角色，将它们放在同一继承层次中可能不符合实际业务需求。
• 缺乏灵活性:
• 如果员工角色需要动态变化（例如，从“Coder”晋升为“Project Manager”），这种继承关系无法支持角色的动态调整。
2. 解释：
• 继承关系的局限性:
继承关系适用于“is-a”关系，但员工角色的变化更符合“has-a”关系（即员工“具有”某种角色）。因此，使用继承关系会导致设计僵化。
• 更好的设计方式:
使用组合关系（Composition）或策略模式（Strategy Pattern）可以更灵活地支持员工角色的动态变化。
3. 修改建议：
修改后的 UML 图如下：
- 父类: “CompanyEmployee”
- 角色类: “Role”（抽象类）
• 子类：“Coder”、“Project Manager”、“Software Engineer” - 组合关系: “CompanyEmployee”包含一个“Role”对象，表示员工“具有”某种角色。
修改后的 UML 图描述:1
2
3
4
5
6
7
8
9
10
11
12+-------------------+ +-------------------+
| CompanyEmployee | | Role |
|-------------------| |-------------------|
| - role: Role |<>------| |
+-------------------+ +-------------------+
^
|
+----------------+----------------+
| | |
+-------+-------+ +-----+-------+ +---+-----------+
| Coder | | ProjectManager| | SoftwareEngineer|
+--------------+ +---------------+ +-----------------+
总结：
原解决方案的 UML 图虽然正确地展示了继承关系，但设计不够灵活，无法满足员工角色动态变化的需求。通过组合关系和角色抽象类的设计，可以更灵活地支持员工角色的动态调整。因此，修改后的设计更符合实际业务需求。
建模分析题：
问题：
假设您被要求使用面向对象分析与设计（OOA/D）技术开发一个销售点（POS）系统。POS 系统是一种用于记录销售和处理付款的计算机化应用程序，通常用于零售商店。处理销售是系统必须执行的关键功能之一。请通过面向对象分析与设计的方法对该关键功能进行建模。
假设处理的简化场景如下：顾客带着要购买的商品到达零售店的收银台。收银员使用 POS 系统的收银机记录每件购买的商品。每件商品由一个产品规格描述，属于产品目录。系统显示运行总计和商品明细。顾客输入付款信息，系统验证并记录。系统更新库存（库存：商品的库存数量）。顾客从系统收到收据，然后带着商品离开，销售记录在分类账上，经理可以在一段时间内检查信息。
- 绘制系统的 UML 用例图，包括用例之间的关系（5 分）。
- 给出表示系统中涉及的业务实体的分析类的类图（仅名称和简要描述，无属性或操作），以及它们之间的关系和多重性（10 分）。
- 给出在 J2EE 中处理销售用例涉及的边界类、控制类和实体类（仅名称和简要描述，带有 UML 类构造型，无属性或操作）（5 分）。
- 绘制 J2EE 中处理销售用例的 UML 序列图（10 分）。
答案与解释：
1. UML 用例图：
用例图描述：
• 参与者: 顾客、收银员、经理。
• 用例:
• 记录商品（Record Items）
• 计算总计（Calculate Total）
• 处理付款（Process Payment）
• 更新库存（Update Inventory）
• 打印收据（Print Receipt）
• 记录销售（Log Sale）
• 关系:
• 包含关系（Include）：记录商品 → 计算总计。
• 扩展关系（Extend）：处理付款 → 更新库存。
用例图：1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23+-------------------+ +-------------------+
| 顾客 | | 收银员 |
+-------------------+ +-------------------+
| |
| |
+-------------------+ +-------------------+
| 记录商品 |<-------| 计算总计 |
+-------------------+ +-------------------+
| |
| |
+-------------------+ +-------------------+
| 处理付款 |<-------| 更新库存 |
+-------------------+ +-------------------+
| |
| |
+-------------------+ +-------------------+
| 打印收据 | | 记录销售 |
+-------------------+ +-------------------+
| |
| |
+-------------------+ +-------------------+
| 经理 | | |
+-------------------+ +-------------------+
2. 类图（分析类）：
类图描述：
• 类:
• Customer（顾客）: 购买商品的顾客。
• Cashier（收银员）: 操作 POS 系统的收银员。
• Product（商品）: 购买的商品。
• ProductSpecification（产品规格）: 商品的描述信息。
• ProductCatalog（产品目录）: 商品目录。
• Sale（销售）: 一次销售记录。
• Payment（付款）: 付款信息。
• Inventory（库存）: 商品库存。
• Ledger（分类账）: 销售记录的分类账。
• 关系:
• 顾客与销售：1 对多。
• 收银员与销售：1 对多。
• 销售与商品：1 对多。
• 商品与产品规格：1 对 1。
• 产品规格与产品目录：多对 1。
• 销售与付款：1 对 1。
• 销售与库存：1 对多。
• 销售与分类账：1 对 1。
类图：1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23+-------------------+ +-------------------+
| Customer | | Cashier |
+-------------------+ +-------------------+
| |
| |
+-------------------+ +-------------------+
| Sale |<-------| Payment |
+-------------------+ +-------------------+
| |
| |
+-------------------+ +-------------------+
| Product | | ProductSpecification|
+-------------------+ +-------------------+
| |
| |
+-------------------+ +-------------------+
| ProductCatalog | | Inventory |
+-------------------+ +-------------------+
| |
| |
+-------------------+ +-------------------+
| Ledger | | |
+-------------------+ +-------------------+
3. 边界类、控制类、实体类（J2EE）：
类描述：
• 边界类:
• POSUI: POS 系统的用户界面。
• 控制类:
• SaleController: 处理销售流程的控制类。
• 实体类:
• Sale: 销售记录。
• Product: 商品。
• Payment: 付款信息。
• Inventory: 库存。
类图：1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16+-------------------+ +-------------------+
| <<Boundary>> | | <<Control>> |
| POSUI | | SaleController |
+-------------------+ +-------------------+
| |
| |
+-------------------+ +-------------------+
| <<Entity>> | | <<Entity>> |
| Sale | | Product |
+-------------------+ +-------------------+
| |
| |
+-------------------+ +-------------------+
| <<Entity>> | | <<Entity>> |
| Payment | | Inventory |
+-------------------+ +-------------------+
4. 序列图（J2EE）：
序列图描述：
- 顾客将商品交给收银员。
- 收银员通过 POSUI 输入商品信息。
- POSUI 调用 SaleController 处理销售。
- SaleController 创建 Sale 对象并记录商品。
- SaleController 调用 Payment 处理付款。
- SaleController 调用 Inventory 更新库存。
- SaleController 返回收据信息给 POSUI。
- POSUI 打印收据。
序列图：1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23+-------------------+ +-------------------+ +-------------------+
| Customer | | Cashier | | POSUI |
+-------------------+ +-------------------+ +-------------------+
| | |
| 1: 提交商品 | |
|------------------------>| |
| | 2: 输入商品信息 |
| |------------------------>|
| | | 3: 处理销售 |
| | |------------------>|
| | | 4: 记录商品 |
| | |------------------>|
| | | 5: 处理付款 |
| | |------------------>|
| | | 6: 更新库存 |
| | |------------------>|
| | | 7: 返回收据 |
| | |<------------------|
| | 8: 打印收据 |
| |<------------------------|
| 9: 收到收据 | |
|<------------------------| |
+-------------------+ +-------------------+ +-------------------+
总结：
通过 UML 用例图、类图、边界类/控制类/实体类以及序列图，可以全面建模 POS 系统的处理销售功能。这些图清晰地描述了系统的功能、业务实体、职责分配和交互流程，为系统开发提供了坚实的基础。
问题与答案：
1. A 是一个（n）
答案： actor（参与者）
解释：
在序列图中，参与者（Actor） 是系统外部的实体，通常是用户或其他系统。A 是序列图的发起者，因此它代表参与者。
2. B 是一个（n）
答案： boundary class object（边界类对象）
解释：
边界类（Boundary Class） 用于表示系统与外部实体（如用户或其他系统）之间的交互。B 接收来自参与者 A 的消息，并将其传递给内部对象，因此 B 是边界类对象。
3. 1.1.3 是一个（n）
答案： 发给“自身”的本地调用消息（local invocation message）
解释：
在序列图中，本地调用消息（Local Invocation Message） 是对象向自身发送的消息。1.1.3 是对象 C 向自身发送的消息，因此它是本地调用消息。
4. 1.1 是一个（n）
答案： create object message（创建对象消息）
解释：
创建对象消息（Create Object Message） 用于在序列图中创建新对象。1.1 是创建对象 C 的消息，因此它是创建对象消息。
5. 框下方的虚线称为
答案： lifeline（生命周期线）
解释：
在序列图中，生命周期线（Lifeline） 用虚线表示，表示对象在序列图中的存在时间。
6. 框下方的矩形称为
答案： 控制焦点（执行规格条）
解释：
在序列图中，控制焦点（Execution Specification） 用矩形表示，表示对象正在执行某个操作或方法。
7. 如果这个系统代表网站的一部分，B 最可能代表什么？
答案： 界面类（interface class）
解释：
在网站系统中，边界类（Boundary Class） 通常代表用户界面（UI），用于处理用户输入和显示输出。因此，B 最可能代表界面类。
8. 为什么 C 低于 A、B、D？
答案： 调用操作符 new 并调用其构造器
解释：
C 是通过调用 new 操作符和构造器创建的对象，因此在序列图中它的生命周期线开始于 A、B、D 之后，位置较低。
9. 为什么 A 到 G 有下划线？
答案： 区分对象名和类名
解释：
在 UML 中，对象名的表示方式通常是“对象名:类名”。如果只显示对象名，则用下划线表示，以区分对象名和类名。
10. 根据图，以下哪一个是无效的消息序列？
答案： B. 1, 1.1, 1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.1.4.1, 1.1.5, 1.1.5.1
解释：
根据图中的条件判断，当 cond == true 时，消息序列应为 1, 1.1, 1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.1.4.1；当 cond == false 时，消息序列应为 1, 1.1, 1.1.1, 1.1.2, 1.1.3, 1.1.5, 1.1.5.1。选项 B 同时包含 1.1.4 和 1.1.5，这是无效的，因为条件判断只能选择其中一个分支。
总结：
以上问题和答案基于序列图的基本概念和 UML 规范，帮助理解对象之间的交互关系、消息类型以及序列图的绘制规则。
