📝 期末模拟试卷：A/B 套试题与参考答案#

1. 用例图绘制（10分）#

• 评分标准：
  • 参与者与系统边界划分正确（2分）；
  • 主用例及子用例命名规范（2分）；
  • <<include>> 虚线箭头从主用例指向子用例（2分）；
  • <<extend>> 虚线箭头从扩展用例指向主用例，且标明扩展点（2分）；
  • 泛化（支付方式）使用实线空心三角指向父用例（2分）。

🎨 规范用例图示#

2. “提交下单”用例规约（10分）#

• 评分标准：

  • 基本要素完整（前置、后置条件等）（3分）；
  • 基本业务流程逻辑清晰、分步明确（4分）；
  • 扩展流程/异常流程处理描述正确（3分）。

• 标准答案：

  • 用例名称：提交下单
  • 主要参与者：学生（用户）
  • 前置条件：用户已成功登录系统，且购物车内已选择至少一件有效商品。
  • 主要流程（Basic Flow）：
    1. 用户在购物车界面点击“去结算”按钮。
    2. 系统读取用户信息，强制触发 [包含：身份与地址验证] 流程。
    3. 系统计算订单的总金额及运费，并在界面呈现应付总额。
    4. 用户确认配送信息及商品无误，点击“提交订单”按钮。
    5. 系统锁定库存，创建未支付订单。
    6. 系统若识别到用户勾选了“需要准时达配送险”，则同步触发 [包含：自动投保生成保单]。
    7. 系统返回订单提交成功响应，引导用户进入支付收银台。
  • 扩展流程（Alternative Flows）：
    • 4a. 积分抵扣（<<extend>>）：
      • 若用户账户内有积分且在确认订单前选择使用，系统调用积分计算服务，按规则抵扣部分金额，更新应付总额，随后继续执行步骤5。
    • 5a. 商品库存不足：
      • 系统检测到部分商品库存为0，则中断下单流程，提示用户“部分商品已被抢光”，解锁已锁定的其他商品。
  • 后置条件：订单在数据库中被创建，状态置为 CREATED（待支付），相应商品库存被锁定。

3. 系统顺序图（SSD）绘制（10分）#

• 评分标准：
  • 生命线仅包含外部 Actor 与 :System 两个黑盒（3分）；
  • 消息方向、名称及入参规范，使用同步实心三角箭头（4分）；
  • 返回消息使用虚线开放箭头（3分）。

🎨 规范系统顺序图示#

1. 原则与设计模式应用（10分）#

• 评分标准：

  • 准确说明单一职责原则（SRP）和依赖倒置原则（DIP）的定义（4分）；
  • 结合三层架构设计或策略模式，举例说明设计是如何遵循这两个原则的（6分）。

• 标准答案：

  • 单一职责原则（SRP）定义：一个类或模块，应该有且仅有一个引起它变化的原因。它要求一个类只专注于做好一类业务，不能承载过杂的职责。
  • 依赖倒置原则（DIP）定义：高层模块不应该依赖低层具体实现类，二者都应该依赖其抽象接口；抽象不应该依赖细节，细节应该依赖抽象。
  • 在设计中的体现：
    • 单一职责原则的遵循：在三层架构中，表示层的 OrderController 只负责参数校验和调用分发；业务层 OrderServiceImpl 只负责核心交易规则与事务，完全不编写具体的 SQL 数据存取语句，后者完全交由 OrderRepository。这样，当数据库存储方式发生改变（如从 MySQL 迁移到 MongoDB），只有持久层会发生变化，业务层和表示层完全不用修改，各个类引起变化的原因极其单一。
    • 依赖倒置原则的遵循：OrderController 并不直接声明依赖 OrderServiceImpl 具体实现类，而是依赖抽象的 OrderService 接口。具体实现类实现了该接口并被注入框架容器中。高层与低层之间完全通过抽象接口隔离开来，满足了 DIP 原则。

2. 核心建模原理辨析：后置条件契约（10分）#

• 评分标准：

  • 准确说出后置条件的定义与意义（4分）；
  • 说出为什么不能用“过程性动词”的原因（2分）；
  • 准确默写出后置条件“黄金三法则”的内容（4分）。

• 标准答案：

  • 后置条件的定义与意义：后置条件描述了当一个外部系统事件执行完毕后，系统状态所发生的基础性、持久化改变。它的意义在于不关注“系统如何实现这个功能”，而是提供了一个客观的、可验证的系统终态判定标准，是详细设计阶段类方法行为的重要设计契约。
  • 严禁使用过程性动词的原因：因为“更新”、“保存”或“处理”属于具体的程序执行过程（Process），而不是系统状态的结果（State）。操作契约必须独立于具体实现技术，只描述“发生了什么改变”，而非“怎么修改数据库”。
  • 后置条件“黄金三法则”：
    1. 对象被创建或销毁（如：创建了一个 Order 的实例 order）。
    2. 对象的属性值发生修改（如：order.status 被修改为 CREATED）。
    3. 对象之间的连接关系（关联）被创建或断开（如：order 与当前的 User 实例建立了关联）。

1. 三层架构设计类图绘制（10分）#

• 评分标准：
  • 三层分层结构清晰（表示层、业务层、数据访问层）（2分）；
  • 接口与实现类隔离，实现关系（Realization）箭头使用虚线加空心三角形（2分）；
  • 方法签名有明确的数据类型、返回类型与可见性标识（2分）；
  • 实体类（Entity）中包含主键 {PK} 和外键 {FK} 约束（2分）；
  • 依赖方向单向正确，无逆向交叉依赖（2分）。

🎨 规范设计类图示#

💡 绘图与考试规范提示（三层架构类图）：

• 主外键标注：由于 Mermaid 语法限制，属性列表中若带花括号 {PK}/{FK} 会引起崩溃，本图例使用黄色 note 框在 Order 类下方标注。
• 考试手绘要求：在期末闭卷考试手绘类图时，必须直接把 {PK} 和 {FK} 写在属性行后面，例如：- orderId : Long {PK}。

2. 策略模式设计类图绘制（10分）#

• 评分标准：
  • 正确抽象出 DiscountStrategy 策略接口（3分）；
  • 上下文类 DiscountContext 正确聚合/关联策略接口（3分）；
  • 具体策略实现类通过实现关系（虚线空心三角）指向策略接口（4分）。

🎨 策略模式类图示#

3. 支付订单处理逻辑活动图（10分）#

• 评分标准：
  • 正确使用空心菱形表达余额是否充足的条件分支（3分）；
  • 正确使用黑色粗同步条实现“分叉（Fork）”，产生并发流程（3分）；
  • 正确使用黑色粗同步条实现“汇合（Join）”，合并并发流程（3分）；
  • 起点、终点及终止符号正确规范（1分）。

🎨 支付活动图示#

💡 绘图与考试规范提示（活动图决策分支）：

• 判定问题标注：由于 Mermaid 无法在决策菱形（<<choice>>）中写字，我们将判定条件（“余额是否充足?”）写在了输入线上。
• 考试手绘要求：在期末闭卷考试手绘活动图时，必须将判定问题直接写在菱形框内部。

4. 订单状态机图（10分）#

• 评分标准：
  • 状态框使用圆角矩形，写有明确的大写状态名（2分）；
  • 状态转移路线正确，从创建到取消/完成闭环（4分）；
  • 状态迁移线上有明确的触发事件和保护条件（4分）。

🎨 状态机图示#

5. 系统包图设计（10分）#

• 评分标准：
  • 正确识别并绘制出表示层、业务层、数据层与实体模型包四者（3分）；
  • 依赖方向箭头（虚线箭头 ..>）正确，无循环依赖（3分）；
  • 准确阐述包级别如何应用依赖倒置原则（DIP），通过接口包切断业务层对具体持久层实现的物理依赖（4分）。

🎨 系统包图示#

💡 DIP在包级别的解耦应用说明#

1. 接口归宿包设计：业务接口 OrderService 放在 business 包中；而持久层接口 OrderRepository 应当定义在独立的 dataaccess 接口包（或直接在 business 包作为服务契约）。
2. 切断直接依赖：具体的持久层实现包（例如 dataaccess-impl，含有具体的 SQL 映射和 MyBatis/JPA 代码）反过来依赖 dataaccess 接口包。
3. 成果：在包的物理组织结构上，business 业务包只依赖 dataaccess 接口包，并不物理依赖具体的数据库持久化实现包。实现了高层不依赖低层具体实现的原则（DIP），方便了数据库技术在后续的任意无缝替换。

1. 用例图绘制（10分）#

• 评分标准：
  • 参与者与系统边界划分正确（2分）；
  • 主用例及子用例命名规范（2分）；
  • <<include>> 虚线箭头从主用例指向子用例（2分）；
  • <<extend>> 虚线箭头从扩展用例指向主用例，且标明扩展点与条件（4分）。

🎨 规范用例图示#

2. 对象序列图绘制（10分）#

• 评分标准：
  • 正确使用各层分析类对象作为生命线（2分）；
  • 正确绘制出 RentalServiceImpl 内部 alt（选择条件）判断框（3分）；
  • 正确展现 <<create>> 实例化 RentalRecord 实体（2分）；
  • 消息方向、名称、同步异步与返回符号完全正确（3分）。

🎨 规范设计级对象序列图示#

3. 系统操作契约分析（10分）#

• 评分标准：

  • 系统操作签名、交叉引用及前置条件书写正确（3分）；
  • 后置条件符合“过去时态”，且严禁出现过程性动词（3分）；
  • 后置条件完美对应“黄金三法则”，即实例创建、属性变更、关联建立（4分）。

• 标准答案：

  • 系统操作：confirmRental(userId: Long, bookId: Long, isInsured: Boolean)
  • 交叉引用：用例：租借图书
  • 前置条件：该读者（userId）处于登录状态，且其信用评分已通过系统初始校验，未处于黑名单中。
  • 后置条件（黄金三法则体现）：
    1. 一个 RentalRecord 的实例 record 被创建（法则一：实例创建）。
    2. record.rentalStatus 属性被修改为 RENTED，record.startTime 被修改为当前系统时间（法则二：属性修改）。
    3. record 与当前的 User 实例建立了关联；record 与对应的 Book 实例建立了关联（法则三：关联建立）。

1. 系统可行性分析的三大维度及核心问题（10分）#

• 评分标准：

  • 准确写出三大维度名称（3分）；
  • 详细阐述每个维度的核心评估重点（7分）。

• 标准答案：

  1. 技术可行性（Technical Feasibility）：
     • 核心关注点：评估“我们能建这个系统吗？”主要看开发团队对相关技术栈的掌握和熟悉程度、系统规模（是否过大、超出了团队的交付能力）、以及系统与组织现有软硬件基础设施的兼容性。
  2. 经济可行性（Economic Feasibility）：
     • 核心关注点：评估“我们应该建这个系统吗？”主要进行成本收益分析（有形与无形、一次性与续生成本收益），通过计算投资回报率（ROI）、平衡点、净现值（NPV）来论证该项目的财务合理性。
  3. 组织/操作可行性（Organizational/Operational Feasibility）：
     • 核心关注点：评估“如果建成了，系统会被接受和使用吗？”主要看系统是否匹配组织既有的工作流程和文化、高层管理和业务人员对系统变革的接受态度。评估是否有强力的“项目赞助人（Sponsor）”在组织层面为项目保驾护航。

2. IT 项目中的成本分类及实例说明（10分）#

• 评分标准：

  • 四个定义准确，表述专业规范（6分）；
  • 实例均属于合理的 IT/软件项目真实场景（4分）。

• 标准答案：

  1. 有形成本（Tangible Costs）：
     • 定义：能够容易且精确地用货币金额进行计量的系统开发或运行费用。
     • IT项目实例：向华为云采购弹性云服务器（ECS）的直接账单费用。
  2. 无形成本（Intangible Costs）：
     • 定义：对企业有负面影响，但在财务上极难用具体金钱金额进行直接、精确衡量的成本。
     • IT项目实例：由于系统切换，导致一线业务员不适应新系统操作而产生的抵触情绪与短期工作士气下滑。
  3. 一次性成本（One-time Costs）：
     • 定义：仅在系统建设初期、开发与部署阶段发生的一次性资金支出。
     • IT项目实例：委托外部软件公司进行系统定制开发所支付的合同款。
  4. 续生成本（Recurring Costs）：
     • 定义：系统上线投入运行后，在后续整个使用生命周期内，为了保障其日常正常运转而必须按周期持续支付的费用。
     • IT项目实例：每年支付给安全厂商的系统年度防火墙规则库升级与技术支持服务费。

1. 三层架构设计类图绘制（10分）#

• 评分标准：
  • 经典三层分层清晰且依赖方向单向正确（3分）；
  • 接口与实现类隔离，实现关系（Realization）箭头使用虚线加空心三角形（3分）；
  • 主外键 {PK}/{FK} 标注完整规范（4分）。

🎨 规范设计类图示#

💡 绘图与考试规范提示（三层架构类图）：

• 主外键标注：由于 Mermaid 语法限制，属性列表中若带花括号 {PK}/{FK} 会引起崩溃，本图例使用黄色 note 框在 RentalRecord 类下方标注。
• 考试手绘要求：在期末闭卷考试手绘类图时，必须直接把 {PK} 和 {FK} 写在属性行后面，例如：- recordId : Long {PK}。

2. 新图书入库活动图（10分）#

• 评分标准：
  • 正确表达书籍格式的多分支判定（3分）；
  • 并行同步条分叉与汇合（Fork / Join）绘制及对应控制流正确（4分）；
  • 起点、终点等流程节点符号标准（3分）。

🎨 图书入库活动图示#

💡 绘图与考试规范提示（活动图决策分支）：

• 判定问题标注：由于 Mermaid 无法在决策菱形（<<choice>>）中写字，我们将判定条件（“书籍格式为何?”）写在了输入线上。
• 考试手绘要求：在期末闭卷考试手绘活动图时，必须将判定问题直接写在菱形框内部。

3. 租借记录状态机图（10分）#

• 评分标准：
  • 状态框使用圆角矩形，写有明确的大写状态名（2分）；
  • 正确展现逾期过渡及各种完结态的流向（4分）；
  • 迁移线上的事件及保护条件标注清晰（4分）。

🎨 租借记录状态机图示#

4. 以 GRASP 原则进行职责分配推理（10分）#

• 标准答案：
  1. 根据 GRASP 信息专家模式（Information Expert），职责应分配给拥有执行该职责所需全部信息的类。
  2. 计算租金的核心基础数据存放在 RentalRecord（记录了实际借阅时长、是否受损等），而图书每日的基础租金单价存放在 BookSpecification 中，逾期计算罚款的倍率和天数规则存放在 FinePolicy 中。
  3. 为了计算最终租金与罚款，RentalRecord 必须要关联 BookSpecification 以获取基础价格，并关联 FinePolicy 以判断是否逾期并计算罚款。由于 RentalRecord 完整持有了计算租借时间差的全部业务数据，且它组合/连接了另外两个专家类。
  4. 结论：计算“最终租金与罚款”的核心方法 calculateTotalFee() 应分配给 RentalRecord 类。

5. 逻辑数据库模型设计（10分）#

• 评分标准：

  • 正确识别多对多关系无法在物理表直接存储，必须拆分为两个一对多，引入中间关联表（4分）；
  • 主表与中间关联表字段设计合理（3分）；
  • 精确标出主键（PK）与外键（FK）（3分）。

• 逻辑表结构设计：

1. 用户表 (sys_user)：
   • user_id (BIGINT) —— PK
   • username (VARCHAR)
   • credit_score (INT)
2. 图书表 (lib_book)：
   • book_id (BIGINT) —— PK
   • isbn (VARCHAR)
   • title (VARCHAR)
   • status (VARCHAR)
3. 图书租借关联记录表 (lib_rental_record) —— 中间关联表：
   • record_id (BIGINT) —— PK
   • user_id (BIGINT) —— FK (关联 sys_user.user_id)
   • book_id (BIGINT) —— FK (关联 lib_book.book_id)
   • start_time (TIMESTAMP)
   • end_time (TIMESTAMP)
   • rental_status (VARCHAR)