从36题继续按顺序回答还没有被回答的问题

### 第36题
**评估下面的顺序图，找出问题，说明问题是什么，问题存在会导致什么后果，说明改进的目标（要求），然后解决，给出解决结果。**

#### 问题
1. **冗余调用**: `isAvailable` 方法被多次调用，增加了不必要的网络请求和数据库查询。
2. **缺少错误处理**: 如果 `isAvailable` 返回 `false`，没有明确的错误消息返回给客户端。
3. **重复代码**: `isAvailable` 和 `createLoanRecord` 方法在多个地方被调用，违反了 DRY（Don't Repeat Yourself）原则。

#### 后果
1. **性能问题**: 多次调用 `isAvailable` 会增加响应时间，影响用户体验。
2. **错误处理不足**: 缺乏明确的错误消息可能导致用户困惑。
3. **代码维护困难**: 重复代码增加了维护难度，容易引入 bug。

#### 改进目标
1. **减少冗余调用**: 只调用一次 `isAvailable` 方法。
2. **增强错误处理**: 提供明确的错误消息。
3. **避免重复代码**: 将重复的代码提取到单独的方法中。

#### 解决方案

| Patron | CheckoutController | DB | Document |
|--------|--------------------|----|----------|
|        |                    |    |          |
| msg:=checkOut(CallNo:string) |    |          |          |
|        | isAvailable(CallNo) |    |          |
|        |                     | a:=isAvailable(CallNo) |     |
|        |                     | <<call number>> |       |
|        |                     | ng             |       |
|        | a:=isAvailable()    |                |       |
|        | if(a == true)       |                |       |
|        | createLoanRecord(p:Patron, d:Document) |      |
|        | <<call number>>     |                |       |
|        | ng                  |                |       |
|        | setAvailable(callNo, false) |         |       |
|        | <<call number>>     |                |       |
|        | updateDocumentSetAvailable(false) |   |       |
|        | msg:=“Checkout successful.” |        |       |
|        | else                |                |       |
|        | msg:=“Document not available.” |      |       |
|        |                      |                |       |

### 第37题
**图1的顺序图描述的是用户登录的过程，图2给出了类LoginController的描述，（1）找出设计问题，说明问题是什么，（2）说明问题不解决会导致什么后果，（3）说明改进遵循的设计原则，（4）然后解决，给出解决结果。**

#### 问题
1. **单一职责原则（SRP）**: `LoginController` 类承担了过多的责任，包括获取用户信息、验证密码、显示错误消息等。
2. **高内聚低耦合**: `LoginController` 类与 `User` 和 `DBMgr` 类高度耦合，缺乏解耦机制。

#### 后果
1. **代码难维护**: 单一类承担过多职责，增加维护难度。
2. **扩展困难**: 高耦合使得未来的扩展和修改变得困难。
3. **测试困难**: 高耦合使得单元测试更加复杂。

#### 改进目标
1. **遵循单一职责原则**: 将 `LoginController` 的职责拆分到多个类中。
2. **降低耦合度**: 引入接口和依赖注入，降低类之间的耦合度。

#### 解决方案
1. **拆分类**:
- `UserService`: 负责用户信息的获取和验证。
- `MessageService`: 负责显示错误消息。

2. **引入接口**:
- `IUserService` 接口定义用户服务的方法。
- `IMessageService` 接口定义消息服务的方法。

3. **依赖注入**:
- 在 `LoginController` 中注入 `IUserService` 和 `IMessageService`。

public interface IUserService {
    String getPassword(String uid);
    boolean verifyPassword(String password, String storedPassword);
}

public interface IMessageService {
    void showMessage(String message);
}

public class UserService implements IUserService {
    private DBMgr db;

    public UserService(DBMgr db) {
        this.db = db;
    }

    @Override
    public String getPassword(String uid) {
        // 获取用户密码
        return db.getUserPassword(uid);
    }

    @Override
    public boolean verifyPassword(String password, String storedPassword) {
        // 验证密码
        return password.equals(storedPassword);
    }
}

public class MessageService implements IMessageService {
    @Override
    public void showMessage(String message) {
        System.out.println(message);
    }
}

public class LoginController {
    private IUserService userService;
    private IMessageService messageService;

    public LoginController(IUserService userService, IMessageService messageService) {
        this.userService = userService;
        this.messageService = messageService;
    }

    public void login(String uid, String password) {
        String storedPassword = userService.getPassword(uid);
        if (userService.verifyPassword(password, storedPassword)) {
            messageService.showMessage("Login successful.");
        } else {
            messageService.showMessage("Invalid credentials.");
        }
    }
}

### 第38题
**下面给出一段材料，该段材料陈述了软件内部各个软件对象是如何协调来进行用户请求事件的处理的，请同学们据此生成通信图。之后，（1）思考应用GRASP的过程；（2）请自行总结“生成通信图的方法”。**

#### 材料
假设有一个简单的电子商务系统，用户发起购买请求后，系统需要检查库存、创建订单、扣减库存、发送邮件通知用户。

#### 通信图

| User | PurchaseController | InventoryService | OrderService | EmailService |
|------|---------------------|------------------|--------------|--------------|
|      | handlePurchase()    |                  |              |              |
|      | checkInventory()    | checkInventory() |              |              |
|      |                     | return inventory |              |              |
|      | createOrder()       |                  | createOrder() |              |
|      |                     |                  | return order  |              |
|      | deductInventory()   | deductInventory()|              |              |
|      |                     | return success   |              |              |
|      | sendEmail()         |                  |              | sendEmail()  |
|      |                     |                  |              | return success|

#### GRASP过程
1. **信息专家**: `InventoryService` 是库存信息的专家，负责检查库存。
2. **控制器**: `PurchaseController` 控制整个购买流程。
3. **创建者**: `OrderService` 创建订单。
4. **低耦合**: 各服务之间通过接口通信，降低耦合度。
5. **高内聚**: 每个服务负责自己的一部分功能，提高内聚度。

#### 生成通信图的方法
1. **确定参与对象**: 根据需求确定参与处理用户请求的各个对象。
2. **确定消息传递**: 分析对象之间的消息传递顺序和内容。
3. **绘制通信图**: 使用 UML 通信图的格式绘制对象及其之间的消息传递。
4. **优化图**: 确保图的清晰性和准确性，去除冗余信息。

### 第39题
**下面给出一段材料，请同学们为其生成类图。之后，请自行总结“生成类图的方法”。**

#### 材料
描述租车业务的类图。车辆可以从一个地点借出并在同一地点归还，也可以在不同地点归还，但需额外收费。目前公司仅关心乘客车，未来可能扩展到其他类型的车辆。公司有多款车型，每款车型有多个型号，型号分为不同的价格等级。客户可以选择车型和型号，如果选中的车不可用，系统应提示客户选择其他车型或推荐相似的车型。公司提供多种租赁计划，如每日无限里程计划和周末省钱计划。客户可以通过电话或亲自预订，无需押金。预订超过一定时间未签约将作废。客户可以一次性支付账单，也可以由公司支付。账单可以通过信用卡支付，支付信息通过信用卡处理公司处理。车辆需要频繁的预防性维护，任何损坏必须尽快修理。公司需要记录车辆的购买、维修、保养和报废信息，用于商业和税务目的。

#### 类图

+-----------------+
|  RentalCompany  |
+-----------------+
| +rentCar()      |
| +returnCar()    |
| +suggestModels()|
+-----------------+

+-----------------+
|    Customer     |
+---+

+-----------------+
|     Invoice     |
+-----------------+
| +openInvoice()  |
| +closeInvoice() |
+-----------------+

+-----------------+
|    CarModel     |
+-----------------+
| +getName()      |
| +getPriceClass()|
+-----------------+

+-----------------+
|  PriceClass     |
+-----------------+
| +getPrice()     |
+-----------------+

+-----------------+
|    RentalPlan   |
+-----------------+
| +getPlanName()  |
| +getDetails()   |
+--+
|     Car         |
+-----------------+
| +getModel()     |
| +getAvailability|
| +rent()         |
| +return()       |
| +maintain()     |
| +repair()       |
+---+
| CreditCardProcessor|
+-----------------+
| +processPayment()|
+-----------------+

#### 生成类图的方法
1. **确定类**: 根据需求确定系统中的主要类。
2. **确定属性和方法**: 为每个类添加必要的属性和方法。
3. **确定关系**: 确定类之间的关系，如关联、聚合、组合、继承等。
4. **绘制类图**: 使用 UML 类图的格式绘制类及其之间的关系。
5. **优化图**: 确保图的清晰性和准确性，去除冗余信息。

### 第40题
**下面给出一段材料（顺序图），请同学们为其生成类图，映射代码。之后，（1）请自行总结“从顺序图交互图中获取类的方法”；（2）并总结代码映射的方法。**

#### 顺序图

| User | LoginController | UserService | DBManager | MessageService |
|------|-----------------|-------------|-----------|---------------|
|      | login()         |             |           |               |
|      | getUserInfo()   | getUserInfo()|           |               |
|      |                 |             | queryDB() |               |
|      |                 |             | return user|              |
|      |                 | return user |           |               |
|      | verifyPassword()|             |           |               |
|      |                 | verifyPassword()|         |               |
|      |                 | return result |          |               |
|      |                 |              |           | showMessage() |
|      |                 |              |           | return success|

#### 类图

+--+
| +login()        |
| +getUserInfo()  |
| +verifyPassword()|
+-----------------+

+-----------------+
|     UserService |
+--+

+-----------------+
|    DBManager    |
+-----------------+
| +queryDB()      |
+-----------------+

+-----------------+
| MessageService  |
+---+

#### 从顺序图交互图中获取类的方法
1. **识别参与者**: 确定顺序图中的所有参与者。
2. **确定消息**: 分析参与者之间的消息传递。
3. **确定类**: 根据消息传递确定类及其方法。
4. **确定关系**: 确定类之间的关系，如关联、聚合、组合等。
5. **绘制类图**: 使用 UML 类图的格式绘制类及其之间的关系。

#### 代码映射的方法
1. **定义类**: 根据类图定义类。
2. **实现方法**: 根据类图中的方法定义实现相应的代码。
3. **处理关系**: 根据类之间的关系处理依赖、关联等。
4. **测试**: 对生成的代码进行单元测试，确保功能正确。

### 第41题
**下面给出一段材料（通信图），请同学们为其生成类图，映射代码。之后，（1）请自行总结“从通信图等交互图中获取类的方法”；（2）并总结代码映射的方法。**

#### 通信图

| User | PurchaseController | InventoryService | OrderService | EmailService |
|--|--------------|
|      | handlePurchase()    |                  |              |              |
|      | checkInventory()    | checkInventory() |              |              |
|      |                     | return inventory |              |              |
|      | createOrder()       |                  | createOrder() |              |
|      |                     |                  | return order  |              |
|      | deductInventory()   | deductInventory()|              |              |
|      |                     | return success   |              |              |
|      | sendEmail()         |                  |              | sendEmail()  |
|      |                     |                  |              | return success|

#### 类图

+--+
|  PurchaseController|
+-----------------+
| +handlePurchase()|
| +checkInventory()|
| +createOrder()   |
| +deductInventory()|
| +sendEmail()     |
+-----------------+

+-----------------+
|  InventoryService|
+-----------------+
| +checkInventory()|
| +deductInventory()|
+-----------------+

+-----------------+
|    OrderService |
+---+
| +sendEmail()    |
+-----------------+

#### 从通信图等交互图中获取类的方法
1. **识别参与者**: 确定通信图中的所有参与者。
2. **确定消息**: 分析参与者之间的消息传递。
3. **确定类**: 根据消息传递确定类及其方法。
4. **确定关系**: 确定类之间的关系，如关联、聚合、组合等。
5. **绘制类图**: 使用 UML 类图的格式绘制类及其之间的关系。

#### 代码映射的方法
1. **定义类**: 根据类图定义类。
2. **实现方法**: 根据类图中的方法定义实现相应的代码。
3. **处理关系**: 根据类之间的关系处理依赖、关联等。
4. **测试**: 对生成的代码进行单元测试，确保功能正确。

### 第42题
**CRC建模 下面给出一段材料，请同学们为其建立CRC模型。之后，请自行总结“建立CRC模型的方法”。**

#### 材料
描述租车业务的类图。车辆可以从一个地点借出并在同一地点归还，也可以在不同地点归还，但需额外收费。目前公司仅关心乘客车，未来可能扩展到其他类型的车辆。公司有多款车型，每款车型有多个型号，型号分为不同的价格等级。客户可以选择车型和型号，如果选中的车不可用，系统应提示客户选择其他车型或推荐相似的车型。公司提供多种租赁计划，如每日无限里程计划和周末省钱计划。客户可以通过电话或亲自预订，无需押金。预订超过一定时间未签约将作废。客户可以一次性支付账单，也可以由公司支付。账单可以通过信用卡支付，支付信息通过信用卡处理公司处理。车辆需要频繁的预防性维护，任何损坏必须尽快修理。公司需要记录车辆的购买、维修、保养和报废信息，用于商业和税务目的。

#### CRC模型
| 类名 | 责任 | 合作者 |
|------|------|-------|
| RentalCompany | 管理车辆租借和归还，建议替代车型 | Car, CarModel, Customer, Reservation |
| Customer | 预订车辆，支付账单 | RentalCompany, Invoice |
| Invoice | 打开和关闭账单 | Customer, PaymentProcessor |
| CarModel | 提供车型名称和价格等级 | Car, PriceClass |
| PriceClass | 提供价格信息 | CarModel |
| RentalPlan | 提供租赁计划名称和详情 | Car, Reservation |
| Car | 提供车型信息，检查可用性，出租和归还 | RentalCompany, MaintenanceLog, RepairLog |
| CreditCardProcessor | 处理信用卡支付 | Invoice |

#### 建立CRC模型的方法
1. **识别类**: 根据需求确定系统中的主要类。
2. **确定责任**: 为每个类确定其主要责任。
3. **确定合作者**: 确定每个类与其合作者的关系。
4. **填写卡片**: 使用 CRC 卡片格式填写类名、责任和合作者。
5. **优化模型**: 确保模型的清晰性和准确性，去除冗余信息。

### 第43题
**熟悉需求模型的各个元素，以及需求模型向设计模型的转换关系。思考从行为和结构两个方面思考做真正开发这件事情。**

#### 需求模型的元素
1. **用例图**: 描述系统与外部参与者之间的交互。
2. **用例规约**: 详细描述用例的场景和步骤。
3. **活动图**: 描述用例中的活动流程。
4. **状态图**: 描述对象在不同状态下的行为。
5. **序列图**: 描述对象之间的消息传递顺序。
6. **通信图**: 描述对象之间的交互关系。
7. **类图**: 描述系统的静态结构。
8. **数据字典**: 描述系统中的数据元素。

#### 需求模型向设计模型的转换关系
1. **用例图 → 类图**: 从用例图中提取主要的类和对象。
2. **用例规约 → 序列图**: 从用例规约中提取消息传递顺序，生成序列图。
3. **活动图 → 流程图**: 从活动图中提取流程，生成流程图。
4. **状态图 → 状态机**: 从状态图中提取状态和转换，生成状态机。
5. **类图 → 数据模型**: 从类图中提取数据模型，生成数据库表结构。

#### 从行为和结构两个方面思考开发
1. **行为方面**:
- **用例驱动**: 从用例出发，确保系统功能的完备性和正确性。
- **活动图和状态图**: 描述系统的行为和状态，确保系统的动态行为符合预期。
- **序列图和通信图**: 描述对象之间的消息传递，确保系统的交互逻辑正确。

2. **结构方面**:
- **类图**: 描述系统的静态结构，确保系统的结构合理和可维护。
- **数据模型**: 描述系统的数据结构，确保数据的完整性和一致性。
- **模块化设计**: 将系统分解为模块，确保每个模块的功能独立和高内聚。

### 第44题
**学习如何建模E-R图（E-R图是类图的超集）**

#### E-R图的基本元素
1. **实体**: 代表系统中的对象，用矩形表示。