OO U4 总结报告

张栗瑞-22373425 学生 2024-06-17 19:23:59

OO U4 总结

一、正向建模与开发

我认为，程序实现是对系统架构设计的具体验证和实现。通过实际的编码和开发，我们将抽象的设计转化为具体的功能。这不仅仅是将设计付诸实践，更是对设计的有效性进行检验的过程。

验证架构设计的性能和可维护性：在实现阶段，我们可以验证架构设计是否能够满足实际运行的需求。这包括系统的性能指标和可维护性要求，通过实际运行的数据和表现，我们能够及时发现和解决潜在的问题。
及时调整设计：如果在实现过程中发现技术选型或性能方面的问题，我们可以及早调整设计，使得架构更加高效和可靠。这个过程确保我们的系统设计是切实可行的，并且能够应对实际的使用场景。

反过来看，系统架构设计为程序实现提供了明确的蓝图和规范。架构设计指引着开发人员按图索骥地进行编码工作，为整个开发过程奠定了坚实的基础。

统一的标准和规范：设计中定义的模块划分、接口规范和整体结构，为开发团队提供了统一的标准和规范。这不仅提高了代码的一致性和质量，还使得不同开发人员之间的协作变得更加顺畅。
系统的可维护性和扩展性：良好的架构设计考虑了系统的可维护性和扩展性，使得未来的功能扩展和维护更加方便，不会影响到系统的稳定性。一个经过深思熟虑的架构设计能够大大降低未来系统维护和扩展的成本。

系统架构设计与程序实现是相辅相成的。系统架构设计为程序实现提供了蓝图和指导，而程序实现则是对系统架构设计的具体验证和实施。两者相互依赖，共同富裕，最终实现一个高效、可靠和可维护的系统。

二、作业的架构设计

本单元的作业是设计并实现一个图书馆管理系统，系统的核心功能包括借书、还书、预约、取书、续借和图书漂流等，主要由以下几个核心模块组成：

MainClass: 系统的入口。
Librarian: 图书管理员类，作为系统的核心控制器，负责处理各类指令（如开馆、闭馆、借书、还书等），并协调其他组件的工作。
Book: 图书类，表示图书馆中的每一本书，包含图书的基本信息（如书号、位置、归还期限等）以及各种操作方法（如借阅、归还等）。
CreditTable: 用户信用积分表，记录并管理用户的信用积分，处理积分的增减和查询。
Fetcher: 图书调度类，负责图书在不同位置间的移动，并记录移动信息。
OrderTable: 预约管理表，记录并管理用户的预约请求。
Panel: 图书面板类，负责存储和管理所有图书的信息，提供各种查询和操作接口。
Place: 枚举类，定义图书在馆内的不同位置（如书架、预约处、借还处等）。

三、代码设计与UML模型设计的追踪关系

在类与对象的映射方面，UML类图中定义的各个类和对象在最终的代码实现中都有对应的实现，并且保持了UML类图中的关系和交互。例如，Librarian类在代码中对应的实现负责协调和处理图书馆的各种操作，Book类表示图书馆中的每一本书，CreditTable类管理用户的信用积分，Fetcher类负责图书的调度，OrderTable类管理预约请求，Panel类则负责所有图书的信息管理，而Place枚举类定义了图书在馆内的不同位置。

其次，在方法与操作的映射方面，UML序列图中描述的各个方法和操作在代码中也都有对应的实现。借书流程、还书流程、预约流程和查询流程等操作在代码中通过Librarian类中的对应方法得到了实现。具体来说，借书流程的borrowed方法、还书流程的returned方法、预约流程的ordered方法和查询流程的queried方法在代码中都按序列图中的描述实现了相应的功能，并且保持了调用顺序和逻辑。

在设计优化与调整方面，为了提高代码的效率和可维护性，我在实现过程中对一些细节进行了调整和优化。例如，对fetch方法的参数和返回值进行了调整，以提高代码的效率和可读性；增加了异常处理机制，保证输入数据的正确性；通过代码重构和优化（尤其是Librarian部分），提高了系统的性能和可维护性。这些调整和优化都是在保证总体架构和功能的前提下进行的，并没有影响整体设计的实现。

四、四个单元中架构设计思维的演进

U1 软件架构设计与优化实践

在U1单元，我深入学习了如何通过“展开、标准化、合并、简化”四步法来优化表达式处理程序的架构。在设计初期我采用实验代码提供的架构，这虽然快速简便，但过度固定的模板限制了后续的扩展性，这促使我思考如何在设计中更好地遵循面向对象的原则，如“高内聚低耦合”。通过引入递归下降思想处理表达式展开，以及利用一些HashSet间的优化合并策略，我优化了程序的性能。然而，我也遇到了如处理exp((-x))简化问题的挑战，暴露了架构的局限性，提示我在设计时需要考虑更多边界情况。此外，未能充分运用面向对象设计原则导致的调试难题，让我深刻体会到良好架构设计的重要性。

U2 多线程调度与电梯系统优化

在多线程编程的探索中，我从简单的synchronized同步块开始，逐渐过渡到复杂场景下的读写锁应用。尤其是在电梯调度系统的设计中，我构建了一个三层级的线程管理体系，但很快意识到这种架构的局限性，尤其是集中式控制的低效和僵硬。通过重构，我将“调度策略”和“运行策略”分离，引入Dispatcher和Controller类，以及Observer模式，显著提高了系统的灵活性和可维护性。这一过程教会我如何根据具体应用场景调整架构，以及如何通过合理拆分职责来提升系统的可扩展性。在处理多线程bug时，我学会了利用画图分析、日志记录等多种策略，这些经历让我对多线程编程的挑战有了更深刻的认识。

U3 JML规范与测试

U3单元通过JML（Java建模语言）的实践，我深入理解了规格与实现分离的重要性，以及不同测试方法的精髓。从黑箱测试、白箱测试到单元测试、集成测试，我学会了如何根据不同测试目的选择合适的测试策略。通过构建和维护图模型，我体会到了数据构造策略对测试效果的影响，以及自动化测试的重要性。这一系列实践增强了我的测试设计能力，促使我思考如何更好地平衡规格定义与算法优化之间的关系，以及如何在保证软件质量的同时，提高开发效率。

U4 建模与开发

在U4单元，我深刻体会到程序实现不仅是对系统架构设计（UML）的具体验证和实施，更是对设计有效性的重要检验。通过实际的编码和开发，我们将抽象的设计转化为具体的功能。这不仅是将设计付诸实践，更是对设计的性能和可维护性进行全面检验的过程。良好的架构设计考虑了系统的可维护性和扩展性，使得未来的功能扩展和维护更加方便，不会影响到系统的稳定性。一个经过深思熟虑的架构设计能够大大降低未来系统维护和扩展的成本。

五、四个单元的测试思维的演进

在整个学习过程中，我的测试思维经历了从简单到复杂、从表面到深层的逐步演进。

最初的测试阶段，我依赖于直接的功能测试，往往是在完成代码编写后，通过手工输入各种数据来验证程序的正确性。在U1单元中，这种方法让我快速验证了表达式处理程序的基本功能。然而，随着系统复杂度的增加，我发现这种简单的测试方法无法有效捕捉程序中的潜在问题。特别是在处理复杂表达式展开和简化时，手工测试变得异常繁琐且容易出错。这促使我开始思考如何通过更系统化的测试方法来提升测试效率和覆盖率。

在U2单元中，面对多线程编程的挑战，我的测试思维开始向并发场景扩展。多线程环境下的程序容易出现诸如死锁、竞态条件等问题，这些问题在简单的功能测试中往往难以复现。为了更好地测试电梯调度系统的稳定性和性能，我引入了日志记录和并发测试工具。这些工具帮助我捕捉到程序在高并发下的异常行为，通过分析日志，我能够更好地理解程序运行时的线程交互情况，并在设计上做出相应优化。这一过程让我认识到，在复杂系统中，测试不仅是验证功能正确性，更是发现和解决系统潜在问题的关键手段。

随着对测试方法的进一步探索，在U3单元中，我接触到了JML（Java建模语言），并通过它实践了规格与实现分离的测试方法。JML让我能够在代码中直接定义和验证软件规范，通过形式化的规格定义和自动化测试工具，我可以更精确地捕捉程序行为是否符合预期。我开始构建和维护复杂的测试模型，模拟各种极端和边界情况，确保程序在各种情况下都能稳定运行。这一阶段的学习让我深刻体会到，良好的测试不仅是代码正确性的保证，更是对系统设计和实现的全面验证。

在U4单元，我的测试思维进一步向全生命周期质量保证演进。我深刻体会到，程序实现不仅是对系统架构设计的具体验证，更是对设计有效性的重要检验。通过实际的编码和开发，我们将抽象的设计转化为具体的功能，而良好的架构设计需要通过系统性的测试来验证其可维护性和扩展性。在这个阶段，我开始将测试视为开发过程中不可或缺的一部分，从设计之初就考虑测试的可行性和覆盖率。通过自动化测试框架，我构建了一整套完整的测试体系，确保每个模块在独立和集成环境下都能稳定运行。

回顾整个学习过程，我的测试思维经历了从简单功能验证到复杂系统性验证的逐步演进。这也正是面向对象独有的优势