一、简答题 (10分)

材料: 某企业进销存系统

1. 销售产品
销售员接到客户苏州美尚邻里超市购买 10 只乐扣乐扣拉杆箱的请求后，登录系统，点击菜单 [销售->销售->报价单]，点击新建，将客户设为“苏州美尚邻里超市”，在订单明细选项卡点击添加一个项目，产品设为“乐扣乐扣拉杆箱”，数量设为 10，此时会提示没足够的库存，这是因为仓库中并没有存货（如果产品的路线已勾选 Make To Order 的话，则没有此提示），关闭此提示，其余信息保留默认设置，然后点击保存。



将报价单发给客户(可通过系统发送，也可打印为 PDF 后另行通过邮件发送)，客户确认报价单后，点击确认订单，此时报价单转化成销售订单，系统会自动生成发货单，同时销售订单状态变为待开票。
点击查看发货单，可以看到发货单状态为“待出库方确认”，点击检查可用，发货单仍停留在此状态，表明库存不足。
点击生成发票，在弹出窗口选择“为整个销售订单开票”，然后点击创建和查看发票，此时生成内部发票，状态为“草稿”。生成的内部发票，会计人员可以通过菜单 [会计->客户->客户发票]来查询。
至此，销售前期工作完成，接下来需要采购产品入库再安排送货。

2. 采购补货
此处使用由系统生成询价单的方式，当然也可由采购人员手工创建询价单。
仓库经理在先前的步骤中已设置了产品的再订货规则，库管员登录系统，点击菜单 [仓库->计划->运行排程]，点击运行排程，系统会根据再订货规则和销售订单及库存情况自动生成采购询价单。
Tips: 在系统中设置好 MRP 计划的循环周期，系统会定期运行 MRP 生成采购询价单，我们这里采用手工运行排程的方式生成询价单。
采购人员登录系统，点击菜单 [采购->采购->询价单]，可看到已生成的采购询价单，点击打开，



供应商确认询价单信息后，采购人员点击确认订单，此时询价单转换成采购单，系统会自动生成入库单和内部发票，同时销售订单状态变为“采购单被确认”。
点击入库，可以看到入库单状态为“准备移动”。
点击收到的发票，可以看到发票的状态为“草稿”。生成的内部发票，会计人员可以通过菜单 [会计->供应商->供应商发票]来查询。
至此，采购前期工作完成，等待仓库收货。

3. 产品入库
乐扣乐扣日用品(苏州)有限公司将货物送到仓库后，仓管员登录系统，点击菜单 [仓库->操作->全部操作]，点击上图箭头所示的位置，接着打开入库单，



点击移动在弹出框中确认货物信息后，点击应用，此时入库完成，入库单状态变为“已移动”。入库单确认后，系统会自动生成会计分录，此时财务人员登录系统，点击菜单 [会计->会计分录->会计分录]，可看到已生成的会计分录。



点击过账，将会计凭证过账。

4. 付款处理
财务人员收到乐扣乐扣日用品(苏州)有限公司开具的实际发票后，需要与系统中之前生成的供应商发票草稿进行核对。点击菜单 [会计->供应商->供应商发票]，打开发票，点击记账，核准发票。
发票核准后，系统会自动生成会计分录，状态为“已记账”。



公司同意付款后，财务人员在供应商发票中点击付款，在弹出的支付窗口中选择实际的付款方式(现金或银行分录)，本案例选为“银行分录”，然后点击登记付款。



付款后，系统会自动生成会计分录，点击过账，将会计凭证过账。至此，供应商付款完毕，采购过程结束。

5. 产品出库
采购的拉杆箱入库后，仓管员点击出库单上的检查可用，因为已有充足的库存，此时出库单状态会变为“准备移动”。



准备好送货后，点击移动，在弹出框中确认信息后，点击应用，此时出库完成，出库单状态变为“已移动”。
出库单确认后，系统会自动生成会计分录，此时财务人员登录系统，点击菜单 [会计->会计分录->会计分录]，可看到已生成的会计分录，点击过账，将会计凭证过账。

6. 收款处理
仓库人员送货后，财务人员点击菜单 [会计->客户->客户发票]，打开发票，点击记账，核准发票。发票核准后，系统会自动生成会计分录，状态为“已记账”。
财务人员收到客户货款后，在客户发票点击登记付款，选择实际的付款方式，然后点击登记付款，系统会自动生成会计分录，点击过账，将会计凭证过账。
至此，客户收款完毕，销售过程结束。

二、需求题 (10分)

• 【答案】 该功能涉及两个用例。
• 参与者:
1. 采购人员 (Purchaser)
2. 库管员 (Warehouse Keeper)
3. 仓库经理 (Warehouse Manager)
• 用例1：手工创建询价单
• 参与者: 采购人员
• 主要流程:
1. 采购人员登录系统。
2. 采购人员选择进入“创建询价单”功能。
3. 系统显示询价单创建界面。
4. 采购人员输入供应商、产品、补货数量等信息。
5. 采购人员保存询价单。
6. 系统创建并存储询价单。
• 用例2：自动生成采购询价单
• 参与者: 库管员, 仓库经理
• 前置条件: 仓库经理已设置好产品的再订货规则。
• 主要流程:
1. 库管员登录系统。
2. 库管员选择进入“运行排程”功能。
3. 库管员触发“运行排程”操作。
4. 系统获取当前的再订货规则、销售订单和库存情况。
5. 系统根据上述信息计算需要补货的产品和数量。
6. 系统自动为需要补货的产品生成采购询价单。

• 【答案】
• “在手工创建询价单时，当用户输入的补货数中含有非数字字符的时候，系统必须提示输入错误。” —— 这是 约束 (Constraint) 或 数据需求 (Data Requirement)。
• “用户输入的收入金额中不能含有非数字字符” —— 这是 数据需求 (Data Requirement)。

• 【解析】
• 第一个需求的分析: 这条需求可以从两个角度看。从数据需求角度，它定义了“补货数”这个数据项的格式规则（必须是数字）。从约束角度，它对系统的行为（如何处理非法输入）提出了一个强制性要求（“必须提示”），这是对系统实现方式的一种限制。在需求分类中，约束通常指实现上的限制，如必须使用特定技术、遵循特定标准等。此场景下，将其归类为数据需求或约束都是合理的，因为它同时描述了数据格式和系统的响应行为。
• 第二个需求的分析: 这是一条非常明确的数据需求。它没有描述系统的功能（“做什么”），也没有描述质量（“做得多好”），而是纯粹地定义了“收入金额”这个数据项的有效性规则或格式，即它的字符集只能是数字。

三、需求分析题 (10分)

1. 通过名词分析法确定概念类。重点分析以上功能相关的类。（包括人员、排程、规则、库存、单据等）（3 分）
• 【答案】 通过分析描述“仓库经理在先前的步骤中设置产品的再订货规则,库管员登录系统运行排程,系统会根据再订货规则(库存低于某个固定值订货)和销售订单及库存情况自动生成采购询价单”，可以识别出以下主要的概念类：
• 人员类: 仓库经理 (WarehouseManager), 库管员 (WarehouseKeeper)
• 规则/计划类: 再订货规则 (ReorderRule), 排程 (Scheduler)
• 库存/产品类: 库存 (Inventory), 产品 (Product)
• 单据类: 销售订单 (SalesOrder), 采购询价单 (PurchaseQuote)

四、体系结构设计题 (10分)

• 【答案】
该系统是一个典型的Web三层架构。物理包图如下所示：

• 【解析】
• 客户端: 用户的浏览器，只负责展示（HTML/CSS）和一些前端交互逻辑（JS）。
• 服务器端: 这是核心。
• 表示层 (Controller): 接收来自浏览器的HTTP请求，解析参数，调用下层业务逻辑，最后将结果封装成HTTP响应（如JSON）返回给浏览器。它像一个“交通警察”。
• 业务逻辑层 (Service): 实现所有复杂的业务规则。例如，“自动生成采购询价单”这个核心逻辑就在这一层完成。它不关心数据从哪来，也不关心结果给谁看。
• 数据访问层 (DAO/Repository): 专门负责与数据库打交道，提供增删改查（CRUD）的原子操作。它将业务层与具体的数据库技术解耦。
• 数据层: 物理存储数据的数据库。

1. 请设计采购补货模块中自动生成采购询价单功能中库管员运行排程这个用例对应的展示层和逻辑层交互的接口，以及其涉及的逻辑层与数据层交互的接口（写出接口声明的代码，不用实现）。每个接口都要写出其所属的包名。请考虑接口在包中的分布。（6 分）
• 【答案】
假设使用Java和Spring框架。

五、详细设计题 (10分)

• 供应商交货期 3 天以内，备货量 7 天销量；

• 供应商交货期 7 天以内，备货 15 天销量；

• 供应商交货期 10 天以内，备货 20 天销量；

• 供应商交货期 15 天以内，备货 30 天销量；

• 供应商交货期 20 天以上，备货 40 天销量

• 【答案】
• 变更类型: 这是数据或配置级别的变更。业务规则的“结构”没有变，只是规则中的“参数”（如天数、销量）发生了变化。
• 应对方法:
1. 避免硬编码 (Hardcoding): 不应将这些数值（3, 7, 15, 20 等）直接写在代码里。
2. 外部化配置: 应该将这些规则参数存储在外部，例如数据库表或配置文件（如.properties, .yml, .xml）中。
3. 设计: 创建一个ReorderRule表，字段包括minDeliveryDays, maxDeliveryDays, stockupDays。程序在运行时从该表中读取规则，而不是在代码中使用if-else判断。这样，当规则变更时，只需修改数据库或配置文件中的数据，无需修改和重新部署代码。

1. 除此之外，库存订货规则还可能添加订货规则，考虑近期活动的需求，包含新的计算方式：备货量＝活动备货量 × 活动规模基数+基础备货量
那么，在逻辑层应该如何去实现可以更好地应对这种变更。画出具体的类图（包括属性和方法的定义）（4 分）
• 【答案】
• 应对方法: 这种新增“计算方式”的变更是逻辑级别的变更。最好的应对方法是使用策略模式 (Strategy Pattern)。将不同的备货量计算算法封装成独立的策略类，使得它们可以相互替换。
• 类图 (Mermaid语法):
• 解析:
• IStockupStrategy: 这是一个策略接口，定义了一个统一的计算方法calculate()。
• StandardStockupStrategy: 实现了标准订货规则的计算逻辑。
• ActivityStockupStrategy: 实现了新的活动订货规则的计算逻辑。
• Scheduler (或某个上下文类): 持有一个IStockupStrategy的引用。在运行时，可以根据需要（例如，判断当前是否有活动）动态地给它设置具体的策略对象（StandardStockupStrategy或ActivityStockupStrategy），然后调用calculate()方法即可，无需改变Scheduler自身代码。

2. 画出考虑活动的计算备货量的对象（订货、规则、活动、销量、订货单）之间协作的顺序图。（3 分）
• 【答案】

六、详细设计题 (10分)

• 【答案】
• 耦合类型: 标记耦合 (Stamp Coupling) 或 数据耦合 (Data Coupling)。validate_request方法将整个input_form对象i传递给了valid_month（虽然代码中没显示传递，但valid_month的参数是date d，可以推断validate_request内部会调用valid_month(i.date))。如果传递的是整个i，就是标记耦合；如果只传递i.date，就是数据耦合，这是比较好的一种。但根本问题在于内聚性低，验证逻辑分散。
• 如何修改: 应该提高内聚性，让数据和操作该数据的行为放在一起，即面向对象封装。
1. 将验证逻辑移到数据所属的类中。
2. 创建一个Date类，并让它自己负责验证自己的有效性。
• 修改后代码示例:

• 【答案】
• 耦合类型: 控制耦合 (Control Coupling)。调用方validate_request通过传递一个type参数（STRING或DATE）来控制被调用方valid内部执行哪一个逻辑分支（switch…case）。这意味着调用方必须了解被调用方的内部实现细节。
• 如何修改: 消除switch…case和类型标记，使用多态来代替。
1. 为不同的验证逻辑创建不同的函数或类。
2. 利用函数重载或多态，让系统在编译时或运行时自动选择正确的验证方法。
• 修改后代码示例 (使用函数重载):

七、设计模式题 (10分)

• 【答案】
• 使用的设计模式: 抽象工厂模式 (Abstract Factory Pattern) 或 工厂方法模式 (Factory Method Pattern)。抽象工厂模式更适合此场景，因为通常一个应用会涉及多个DAO对象（如UserDAO, ProductDAO等），抽象工厂可以创建一系列相关的DAO对象。
• 使用到的设计原则:
1. 依赖倒置原则 (Dependency Inversion Principle): 业务逻辑层不依赖于具体的DAO实现（如MySqlUserDAO），而是依赖于DAO接口（如IUserDAO）。高层模块不应依赖于低层模块，二者都应依赖于抽象。
2. 开闭原则 (Open/Closed Principle): 当需要支持一个新的数据库（如从MySQL切换到SQLServer，或新增Oracle支持）时，我们只需要创建新的具体DAO实现类和新的具体DAO工厂类，而不需要修改业务逻辑层的代码。系统对扩展开放，对修改关闭。
• DAO的概念类图 (基于抽象工厂模式):
 

八、构造题 (10分)

• 供应商交货期 3 天以内，备货量 7 天销量；

• 供应商交货期 7 天以内，备货 15 天销量；

• 供应商交货期 10 天以内，备货 20 天销量；

• 供应商交货期 15 天以内，备货 30 天销量；

• 供应商交货期 20 天以上，备货 40 天销量

• 【答案】
• 代码存在的问题:
1. 命名极差 (Poor Naming): 变量名aa和bb完全没有业务含义，使代码难以理解。aa应为deliveryDays（交货期天数），bb应为stockupDays（备货天数）。
2. 使用魔术数字 (Magic Numbers): 代码中充满了3, 7, 15, 20, 30, 40等数字，这些数字的业务含义不明确，修改困难且容易出错。应定义为有意义的常量。
3. 逻辑不清晰且存在缺陷 (Flawed Logic):
• 使用了一系列独立的if语句，而不是互斥的if-else if-else结构。这导致了不必要的重复判断，效率低下。
• 逻辑漏洞: 条件if(aa < 15 && aa >= 10)和if(aa >= 20)之间缺少了对aa在[15, 20)区间内的处理。如果输入15或18，函数将返回初始值0，这是一个Bug。
• 边界条件不一致: 第一个条件是< 3，第二个是< 7 && >= 3。这种混合了<和>=的写法容易出错且难以阅读。
4. 可维护性差 (Poor Maintainability): 如果需要增加或修改一条规则，直接修改这个复杂的if链条很容易引入新的错误。
• 正确、易读、可靠的代码实现:

九、人机交互题 (10分)

• 【答案】 结合页面（图2.2 采购询价单 PO00001），可以从以下人机交互原则进行点评：
1. 状态可见性原则 (Visibility of system status):
• 体现: 页面顶部明确显示了当前单据的类型和编号“询价单 PO00001”，让用户清楚地知道自己正在操作哪个对象。标签页“退换货申请”用红色高亮，清晰地标示出用户当前所在的视图位置。主操作按钮“确认订单”是蓝色的，暗示这是当前流程的关键下一步操作。这些都为用户提供了清晰的状态反馈。
• 点评: 该页面在状态可见性方面做得较好，用户可以快速了解当前上下文和可执行的关键操作。
1. 一致性与标准原则 (Consistency and standards):
• 体现: 整个页面的布局（顶部标题、中部表单、下部表格）符合企业级管理软件（ERP/CRM）的常见设计范式。用户可以利用从其他类似系统获得的经验来快速上手。按钮、标签页等控件的风格基本保持了一致。
• 点评: 遵循了平台和行业标准，降低了用户的学习成本。但部分按钮（如“确认订单”和“打印”）的视觉风格略有差异，可以在细节上追求更高的一致性。
2. 为专家用户提供快捷方式 (Flexibility and efficiency of use):
• 体现: 页面顶部提供了一系列按钮，如“确认订单”、“打印”、“发送邮件”等，这些都是针对此单据的常用操作。用户无需通过多级菜单即可一键执行，提高了操作效率。
• 点评: 为高频操作提供了直接入口，方便了熟练用户的快速使用。
3. 识别而非回忆原则 (Recognition rather than recall):
• 体现: 页面将供应商、订单日期、关联单据等所有相关信息都直接展示出来，用户无需去记忆或查找这些信息。在表格中，产品、说明、数量、单价等信息也都一目了然。
• 点评: 将需要的信息都呈现在界面上，减轻了用户的记忆负担，符合“识别而非回忆”的原则，让用户可以专注于当前的任务。

十、测试题 (10分)

• 供应商交货期 3 天以内，备货 7 天销量；

• 供应商交货期 7 天以内，备货 15 天销量；

• 供应商交货期 10 天以内，备货 20 天销量；

• 供应商交货期 15 天以内，备货 30 天销量；

• 供应商交货期 20 天以上，备货 40 天销量。

• 【答案】 背景分析: 边界值分析法是黑盒测试的一种，旨在测试输入域的边界。测试用例应覆盖“正好在边界上”（On Point）、“在边界内侧”（In Point）和“在边界外侧”（Off Point）的值。首先，我们需要澄清规则的边界。“3天以内”通常理解为<= 3，“7天以内”为<= 7。规则之间是互斥的，因此可以整理为：
• d <= 3
• 3 < d <= 7
• 7 < d <= 10
• 10 < d <= 15
• d >= 20 (题目写”20天以上”，这里理解为>= 20更合理。需要注意15 < d < 20这个区间规则是缺失的，这是一个需求缺陷，测试时需要特别指出)。
测试用例设计 (基于边界值法):

测试用例ID	输入：交货期天数 (d)	边界描述	预期输出：备货天数	备注
TC-BVA-01	0	无效等价类下边界	0 或 错误提示	测试负数/零值
TC-BVA-02	1	规则1有效等价类	7	在边界内
TC-BVA-03	3	规则1上边界/规则2下边界	7	On Point
TC-BVA-04	4	规则2下边界+1	15	Off Point (for rule 1), In Point (for rule 2)
TC-BVA-05	6	规则2有效等价类	15	在边界内
TC-BVA-06	7	规则2上边界/规则3下边界	15	On Point
TC-BVA-07	8	规则3下边界+1	20	Off Point (for rule 2), In Point (for rule 3)
TC-BVA-08	10	规则3上边界/规则4下边界	20	On Point
TC-BVA-09	11	规则4下边界+1	30	Off Point (for rule 3), In Point (for rule 4)
TC-BVA-10	15	规则4上边界	30	On Point
TC-BVA-11	16	规则4上边界+1	未定义	需求缺陷，测试其行为
TC-BVA-12	19	规则5下边界-1	未定义	需求缺陷，测试其行为
TC-BVA-13	20	规则5下边界	40	On Point
TC-BVA-14	21	规则5有效等价类	40	在边界内
TC-BVA-15	100	有效等价类（大数值）	40	ㅤ