BUAA-OO-2024-第四单元总结&&课程总结

孙锐毅-22373500 学生 2024-06-11 22:17:16

OO第四单元总结
正向建模与开发
用UML帮助Java程序的实现
利用UML进行建模设计的意义
第四单元作业
UML图
类图
状态图（Book）
顺序图（OrderBook）
架构设计
13次作业
14次作业
15次作业
最终的代码设计和UML模型设计之间的追踪关系
总结自己在四个单元中架构设计思维的演进
第一单元
第二单元
第三单元
第四单元
总结自己在四个单元中测试思维的演进
总结自己的课程收获

OO第四单元总结

正向建模与开发

用UML帮助Java程序的实现

利用 UML 图形建模来全面设计和实现 Java 应用程序，我们可以逐步进行以下流程来设计和实现：

识别和梳理数据抽象，建立关系，形成初步的类图：
- 分析系统需求，识别出主要的实体和数据对象。
- 将这些实体和数据对象抽象成类，并建立它们之间的关系，包括关联、聚合、继承等。
- 这个阶段形成的初步类图可以作为后续设计的基础。
识别和梳理流程场景，建立顺序图，完善类的职责和关联关系：
- 分析系统的业务流程场景，识别出各种交互和消息传递的过程。
- 基于这些场景，绘制顺序图来描述对象之间的交互过程，并完善类的职责和关联关系。
- 顺序图可以帮助理解系统的动态行为，从而完善和调整类的设计。
识别和梳理关键类的状态和迁移，建立状态图，完善类的数据和行为：
- 分析系统中涉及状态变化的关键类，识别出它们的状态和状态之间的转换条件。
- 基于这些状态和转换条件，绘制状态图来描述对象的状态变化过程，并完善类的数据和行为。
- 状态图可以帮助理解对象的状态行为，从而优化和完善类的设计。
基于三种图来动态“执行”系统业务场景，发现不一致问题：
- 将用例图、顺序图和状态图结合起来，动态模拟系统的业务场景执行过程。
- 在模拟执行过程中，观察系统的行为是否符合预期，发现可能存在的不一致问题。
- 通过动态执行业务场景，可以及时发现并解决设计和实现过程中的问题。
基于三种图来构造测试用例：
- 根据用例图、顺序图和状态图，构造系统的各种测试用例，覆盖不同的功能和场景。
- 测试用例可以基于各种图形模型的路径、分支和状态变化来设计，确保对系统的各个方面进行充分的测试。
基于三种图来实现程序和开展测试：
- 根据前面的设计和测试用例，开始编写 Java 程序的源代码。
- 在编写代码的过程中，根据类图、顺序图和状态图的设计，实现系统的各项功能和特性。
- 在实现完成后，进行测试，并根据测试结果来修改和优化程序，确保系统的正确性和稳定性。

通过以上步骤，可以利用 UML 图形建模来全面设计和实现 Java 应用程序，并在开发过程中充分考虑系统的功能、动态行为和状态变化，从而提高系统的质量和可靠性。

利用UML进行建模设计的意义

抽象和模型化: UML提供了一套丰富的建模元素和符号，可以用来抽象和模型化现实世界中复杂的系统和问题。通过UML，可以将系统分解为不同的组件和模块，并定义它们之间的关系和行为，从而更容易理解和管理系统的复杂性。
沟通和交流: UML提供了一种统一的、标准化的建模语言，可以帮助团队成员之间进行有效的沟通和交流。通过使用UML图表，可以清晰地展示系统的结构、行为和交互，从而促进团队成员之间的理解和协作。
分析和设计: 利用UML进行建模设计可以帮助工程师更好地分析和设计系统。通过绘制类图、时序图、活动图等UML图表，可以发现系统中的潜在问题和瓶颈，从而指导系统的设计和优化。
可利用自动化工具测验: UML是一种标准化的建模语言，支持许多自动化工具和软件，如UML建模工具、代码生成工具等。利用这些工具，可以自动生成代码、执行模型验证和仿真等操作，提高开发效率和质量

第四单元作业

UML图

类图

状态图（Book）

顺序图（OrderBook）

架构设计

13次作业

最初根据作业要求有了第一版的设计构想

之后的设计也大致围绕着这个展开，并在此基础上有一定的修改

14次作业

这次作业主要新增了一个图书漂流角，相应的增加了图书捐赠，转正，非正式图书等操作。另外的一个内容有关书籍借阅期限，需要在归还时判断是否逾期，且要支持续借操作。

在架构上的变化最大的就是加入了drift，即图书漂流角类。其与Bookshelf类较为相似。

同时书籍的属性有了更多的变化，对于正式图书与非正式图书在预约，借阅等操作时需要不同的处理。

需要注意的是这次作业对整理有了一定的要求，在开馆对应的整理后，借还处不应该有书，预约处不应该有逾期的书。最开始忽略了这个条件导致了一些错误。

15次作业

这次作业增添的内容也并不多，主要是引入了信用分机制。

因此用户会新增信用分属性。并且为了满足加减信用分的操作，捐献书籍需要知道对应的捐献者。最困扰我的其实是关于涉及多个信用分同时加减的操作时的先后顺序。好在经过讨论区与指定书的阅读搞清楚了相关顺序。

本单元三次作业都没有出现bug，也算是完美收官（前面几个单元有点菜了 (ಥ_ಥ))

最终的代码设计和UML模型设计之间的追踪关系

这种追踪关系在我看来主要应该是指UML模型中的各种元素（如类、对象、关系、行为等）与代码中的相应构造之间存在着映射关系。例如，UML类可以直接映射到代码中的类，类之间的关联关系可以映射到代码中的成员变量或方法调用关系等。这样能够保证UML模型设计和代码设计的一致性，使得通过UML模型所描述的系统结构、行为和交互能够在代码实现中找到对应的体现。

最后回顾一下我最终的代码设计和UML模型设计，两者之间的追踪关系还算结合的不错，但还是存在着一些没有考虑到的地方。

在UML模型的设计中，主要的类和类主要的属性与方法我都有考虑到，并且在代码中都有相应的实现。但是有一些细节的方法实现在一开始我是没有考虑到的，是在代码编写的过程中发现可以做出简化或者必要的方法。这也说明了UML模型设计并不是从一开始就能够设计得十全十美，也会有考虑不周到的地方，在代码实际开发过程中也可以做出修改。

UML模型设计是代码设计的前置工作，它为代码设计提供了指导和依据。但是在软件开发过程中，需求和设计可能会发生变化，导致UML模型和代码设计需要进行相应的调整。因此，需要确保UML模型和代码之间的变更是同步的，对代码的修改也应该能够更新到UML模型中。

建立代码设计和UML模型设计之间的追踪关系也有着重要作用：

保持一致性和同步性: 通过建立追踪关系，可以确保UML模型和代码设计之间的一致性和同步性。这意味着通过UML模型描述的系统结构、行为和交互应该与实际代码设计保持一致，从而避免因为模型与代码不一致而导致的设计错误和实现偏差。
指导开发过程: UML模型可以作为代码设计的指导，通过建立追踪关系，开发人员可以直接从UML模型中获取设计信息，从而更加清晰地了解系统的设计思路和架构。这有助于开发人员更快地理解需求、设计代码，并减少开发过程中的误解和偏差。
变更管理: 当需求或设计发生变化时，建立了追踪关系的UML模型和代码设计可以更容易地进行变更管理。通过追踪关系，可以追踪到模型和代码之间的对应关系，从而及时地更新代码设计，保持系统的一致性和可维护性。
辅助维护和升级: 建立了追踪关系的UML模型和代码设计可以作为系统维护和升级的重要参考。当需要修改或扩展系统功能时，开发人员可以通过分析UML模型和代码设计之间的关系，更加清晰地了解系统的结构和行为，从而更有效地进行系统的维护和升级。

总结自己在四个单元中架构设计思维的演进

在这一个学期OO课程的学习中，架构设计思维确实经历了不少演进(*/ω＼*)

第一单元

第一个单元是训练目标是层次化设计。（在之后的单元中也都有用到）

既然要有层次，必然涉及多对象，层次化设计在我看来其实是一种对对象的管理方式。在第一单元的学习中，我加深了类的层次化设计的理解，针对目标应用情景我们应该如何建类，这些类之间有什么关系，这些类分别要负责什么工作，等等，这都是我们需要考虑的内容。

在层次化设计中十分重要的一环就是抽象层次设计，对于一个应用场景，其层次可能并不是十分清晰明了，需要我们去分析各个对象，提取共性，完成分层。抽象层次设计考验了我们对继承和接口的理解与运用，其对我们的设计与架构有着重要作用：

简化复杂性: 抽象层次可以将系统分解为多个层次或级别，每个级别都具有不同的抽象程度和关注点。这种分解可以帮助降低系统的复杂性，使得开发人员能够更容易地理解和处理系统的各个部分。
提高可维护性: 通过建立抽象层次，可以将系统分解为更小、更独立的模块或组件。这样的分解有助于提高系统的可维护性，因为开发人员可以更容易地理解和修改单个模块，而不会影响到整个系统。
促进模块化: 抽象层次可以帮助将系统划分为模块或组件，每个模块都具有清晰的责任和接口。这种模块化的设计有助于提高系统的灵活性和可重用性，因为模块可以被独立地开发、测试和部署。
提高扩展性: 通过建立抽象层次，可以将系统的核心功能和实现细节分离开来。这样的设计有助于提高系统的扩展性，因为新功能可以被添加到系统中而不会影响到现有的功能和结构。

第二单元

第二个单元的训练目标是线程安全设计（也是令我有些痛苦的单元 o(TωT)o ）

线程安全是一个重要的对象特性，对象共享是产生线程安全问题的根本原因。

在考虑线程安全设计时，主要关注几个问题：

对象
- 使用不可变对象
  
  使用final来强制限制对属性成员的修改
  
  要小心对可变对象的引用
- 使用可变对象
  
  操作的原子性
  
  共享对象要始终处于严密控制之下
  
  避免不受控的对象发布
  
  设置范围适当的临界区
  
  使用合适的监控器monitor
临界区
- 临界区和监控器的匹配
  经验原则：临界区中代码围绕监控器对象开展工作
  如果临界区代码不访问监控器（而访问其他共享对象），则无法获得安全保护的效果
- 临界区最小化
  
  如果一个临界区中某行代码不访问monitor，应把相应的代码移出临界区
  如果临界区中某行代码仅访问monitor中的不可变数据，应把相应的代码移出临界区

确保线程安全的设计，归结起来，三个关键要素

控制对象发布和共享

复杂的对象引用和共享是导致程序死锁或数据竞争的主要原因
共享对象设计为线程安全类

访问共享对象的类无需额外采取同步控制措施

同步控制范围不宜过大，性能与安全的平衡

读写锁一般可以获得更好的性能
保持简洁的线程类

run方法只负责顶层的控制逻辑

不去管理具体业务数据

不要让一个线程对象去访问另一个线程对象

第三单元

第三单元聚焦于规格化设计

规格化设计是一种致力于保证程序正确性的方法，其正确性的含义是——在规定的输入范畴内给出满足规定要求的输出，即“你”如果能够保证前置条件成立，“我”就能保证后置条件成立。

主要从两方面来看，一个是类规格，一个是方法规格。

类规格定义了与用户的契约，包含数据规格（类所管理的数据内容，及其有效性条件(invariant, constraint)）和方法规格（类所提供的操作，权利+义务+注意事项）。类规格定义了开发人员必须实现的规约——实现数据内容并确保始终有效，任意一个方法的实现都不能破坏对象的有效性，任意一个方法的实现都要满足方法本身定义的规约。
方法规格是一个方法与其用户交互的契约（契约：权利+义务+注意事项）
- 义务：用户要保证提供有效的输入以及有效的对象状态
  
  权利：用户能够获得满足确定条件的输出结果
  
  注意事项：方法执行过程中可能会修改用户对象的状态
方法规格是一个方法对实现者做出的规约要求（规约：前置条件+后置条件+副作用）
- 前置条件：实现者可依赖的初始条件
  
  后置条件：实现者如何提供满足要求的结果
  
  副作用：不去做多余的事情

第四单元

第四单元也正如前几部分所体现的一样，讲求的是模型化设计。

模型化设计，顾名思义，使用系统化的模型语言来表示设计结果，进而开展设计思考。其最需要，也是最考验的能力就是抽象能力。抽象是建模中的最重要方法，重点在于要忽略细节，抓住本质。

重点内容在前面第四单元的总结中也都有所谈到，就不再赘述了。

总体来看，四个单元，每个单元侧重训练的设计思维都有所不同，但都是面向对象中在设计层次重要的一环。在一次次单元训练中，我的设计思维也逐渐变得更加完善，能够更全面综合的来思考问题了。

总结自己在四个单元中测试思维的演进

每个单元的测试都给我带来了一些新的思考

第一单元我测试主要是靠手搓样例。关注的点主要是一些特殊点测试和边界测试。

第二单元依靠了一下佬的评测机，所关注的测试策略加入了高并发测试

第三单元由于有Junit测试的要求，就顺便自己手搭了一个简陋的评测机进行测试。这一单元加深了对黑箱和白箱测试的理解

第四单元在测试策略上没有什么大的变化，但是接触到了一种新的测试方式，交互性测试，根据程序上一步做出的输出来决定下一步的测试输入。

其实总体来说，每个单元的测试都有些相同的地方，前面所列出的只是在每个单元中重点关注的方法，但是通过这一学期课程的学习，在测试上面也是有了更多的心得与思考吧。

总结自己的课程收获

::.--.-.::
:( (    ):::::   
(_,  \ ) ,_)::         |
:::-'--`--:::::::: ~~|     ,       \ _ /
::::::::::::::::::: ,|`-._/|   -==  (_)  ==-
::::::::^^::::::::.' |   /||\      /   \
::::::^^::::::::.'   | ./ ||`\       |
:::::::::::::::/ `-. |/._ ||  \
::::::::::::::|      ||   ||   \
 ~~=~_~^~ =~ \~~~~~~~'~~~~'~~~~/~~`` ~=~^~
~^^~~-=~^~ ^ `--------------'~^~=~^~_~^=~^~