BUAA-OO-Unit4总结

前言

第四单元旨在通过模拟一个小型图书馆管理系统，掌握使用StarUML工具绘制UML类图、状态图和顺序图的方法，体会代码设计和UML模型设计之间的正向建模与开发。同时进一步应用面向对象的构造设计方法，综合前三个单元的内容，对整个课程进行总结。

正向建模与开发

正向建模是一种用于描述和分析系统或过程的建模方法。它基于系统的目标和行为，以及各个组成部分之间的相互作用关系，从而生成系统的模型。在正向建模中，建模过程从系统的高层目标出发，逐步细化到具体的组成部分和其行为。这种方法着重于描述系统的结构和功能，以及各个组件之间的交互关系。可见正向建模不止用于软件设计，还是系统工程方法学中的重点研究对象。

具体到本单元所实践的正向建模，聚焦于通过绘制UML类图、状态图和顺序图的设计分析来指导编程实现。类图明确了每个类的属性（包括它的类型）、类的方法（包括它的参数），指导开发过程中的类的各项声明，如图书馆、书、用户等实体及其关系。状态图明确了关键对象的状态变化，指导类中方法的具体实现，如图书所处位置以及转移的方向和条件。顺序图明确了类和对象之间的交互关系，指导类中方法的具体实现，如图书馆如何响应用户请求。

就个人体会，正向建模提示在面对一个相对庞大的工程项目时，绝对不能着急编码，而应该先做全面系统的分析，整体把握系统结构后，再开始尝试代码实现。同时也应该意识到，需要避免走向另一个极端，架构设计时不可能面面俱到，现实工程中有千千万个细节，这些是不可能在架构设计之初就全部考虑到的。因此正确且有效的做法是架构设计与代码实现互相融合、共同迭代，进而找到一定限制条件下的最优解。

架构设计

UML类图

图书状态转移图

从类图中可以看出，本单元的图书管理系统将Library类作为核心管理类，图书馆的各部门（书架、借还处、预约处、漂流角）以及用户都作为它的属性，在Library类中实现了处理请求，图书调度等的具体逻辑。由于各部门和用户的共同核心特征是持有图书并执行与图书相关的操作，因此增加Books辅助类管理图书的数据结构，而使其他类拥有该类的对象。

该模型的优点是Library类具有的绝对核心地位，面对新增请求，只需在其中添加相应处理逻辑，而不用重新调整代码架构，因此具有良好的可扩展性。在hw14中新增图书漂流要求，只需增加漂流角类BookDriftCorner并将其与Library关联即可。缺点也很明显，所有处理逻辑集中在一个类中实现，导致Library类过于巨大，或许可以尝试将每个处理需求的逻辑单独成为一个类，Library类只需管理这些方法类而无需实现。

从状态图中可以看出，图书这一核心数据结构的状态与图书馆的各部门和用户紧密相关，而在状态图中未出现Library这一状态，这也是符合逻辑的。通过状态图的示意，直观展现了Library类中各个方法对应的图书的状态转移。因此便可窥得状态图的强大能力。

追踪关系

代码和UML模型到底是谁追踪谁，是先设计一个完美的模型架构再实现编码，还是先写代码再补充UML模型，或者达到两者间的平衡。代码和模型本不存在严格意义下的追踪关系，即使没有模型也可以编写出实现功能的代码，同样没有代码也可以设计出好的模型，重要的是在工程实践中怎样综合运用两者达到最高效率。事实上，多数人在编写代码前绘制的图并非标准的UML图，更多的只是纸上粗糙的思维导图，然而这正是一种正向建模，设想如果一开始就在StarUML上画图，便不利于思维的流畅连续。使用UML进行设计时，可先做好相应设计，绘制UML类图后再实现具体代码；当然也可在代码变化后再回头更新UML图。

架构设计思维

面向对象是一种思维方法。对象是一组具体的个体，各自维护自己的状态，同一个类所实例化对象，状态管理能力相同，但却是不同个体。所谓“面向”，即把对象（类）作为单位来规划程序的结构和行为。此课程聚焦面向对象设计思想，包括层次化、线程安全、规格化和模型化的设计方法，强调架构设计和模型构造能力，结合Java语言的特性，实现具体代码。

第一单元聚焦层次化设计，解决三个基本问题：如何管理对象、如何建立对象之间的层次关系、如何利用层次关系。几乎大部分设计模式都会使用继承和接口来建立层次，第一单元的表达式解析也不例外。同时强调程序的鲁棒性设计，逐步建立程序的鲁棒性概念，具体包括输入数据、数据管理和计算等的鲁棒性。

第二单元聚焦线程安全设计，同时继续使用层次化设计。通俗来说，线程安全就是“线程**，你不用担心什么，只管做你的事情，保证不给你添乱”。有并发的地方，就需要多线程的存在，就需要考虑线程安全。当关注数据抽象和行为抽象时，继承、接口和多态就形成了面向数据和行为抽象的层次设计结构。当关注并发行为的安全和效率时，线程、共享和交互就形成了面向并发和协同抽象的层次设计结构。保持架构的扩展能力是不变的追求，因此依然要强调层次化设计。

第三单元聚焦规格化设计。类是一个编程单位，类规格定义了开发人员与用户的契约。规格化设计，或者契约式设计，是一种基于信任机制和权力义务权衡机制的设计方法，JML正源于契约式设计的需要而产生。可以说基于JML的规格模式，写出严谨的JML描述比将其转换为Java代码更加困难，但同时需要知道绝对不能对照规格机械地实现代码，因为规格并不会限制模块内部细节设计。

第四单元聚焦模型化设计。前三个单元的层次化设计、线程安全设计和规格化设计都指向了模型化设计，什么是模型，模型是对用来描述一个目标对象的元素及其关系、约束的统称。而基于模型化的设计使用系统化的模型语言来表达设计结果，进而开展设计思考。其中UML以其语法明确、语义清晰以及可视化的特点成为建模语言的集大成者。UML的类图、状态图和顺序图作为表达设计的工具，能帮助人们更好传递思想。

测试思维

测试就像是面镜子，具体的：测试是反射镜，测试别人发现自己的问题；测试是放大镜，通过测试放大程序中的局部问题，直至架构问题；测试是望远镜，结合需求迭代预测可能得脆弱点，提前进行重构或固化。从中测、强测、互测，到各个单元中的输入结构导向、程序架构导向、线程并发导向、交互场景导向、单一契约导向、层次契约导向、模型结构导向、模型语义导向的测试，OO中的测试形式多样，着重点也各不相同。而在之前，我简单以为测试就是提交评测机，然而事实却并非如此。在第一单元就提出了黑盒分析、白盒分析的概念，第三单元引入JML后，测试变得更加严谨。同时测试也需要保证几个基本原则：独立视角，不能把自己限定为设计和开发人员，怎么用就怎么测；尽早介入，在需求确定时就开始测试；可靠追溯，一旦测试发现错误，需要追溯相应的代码和数据；确保复现；有序开展，测试输入的复杂度和规模由小到大。当然，基于测试验证代码正确性，由于无法穷举所有可能，所以测不全是必然的。

在我的作业中采用以下测试流程：首先使用简单数据测试程序基本功能，之后逐步上调数据规模，并考虑边界情况，使用极端数据考虑程序的性能问题。最后提交评测机测试。

课程收获

整个课程中，有如下收获：

1. 逐渐开始从C语言面向过程式的程序设计转变为面向对象的程序设计，体会面向对象的编程思想。
2. 了解并熟悉Java语言，掌握其语法和编程特性。
3. 建立系统观和工程意识，通过每个单元三次作业迭代式的开发，逐步从编写一个小型算法过渡到大型软件工程。

此课程展现的只是冰山一角，而面向对象是蔚蓝大海。