OO第四单元博客总结

[苏弘康-21371420]

OO第四单元博客总结

本单元正向建模与开发

正向建模是指先进行从无到有的建模，有一个具体的框架之后再进行开发活动。在本单元来说，就是先对UML图进行建模，不管是类图、状态图、还是顺序图，先建立起一个整体的架构，让自己对任务需求有具体的、实现上的认识。在完成建模之后，可以在一个更宏观的视角上进行程序开发，同时，也可以大大减少重构的次数，节省开发时间。
从本单元作业的角度来说，类图、状态图和顺序图分别是UML图建模下的三个不同视角的建模图。也正因如此，它们的重要性是等同的。

类图

类图描述的是程序中所建的各个类的属性，方法，以及它们之间的关系。是从面向对象的角度对代码层面的建模逻辑的静态描述。总的来说，类图涵盖了所有代码的抽象集合的表示，但只是静态的描述，无法表示程序的运行过程，也无法很好的描述多线程程序。

状态图

状态图描述的是一个特定的对象的一系列状态转移的过程。状态图是对程序执行过程中某对象状态变化的描述，可以很好地展示程序的运行过程，但无法表示多线程，而是一个具象的过程描述。

顺序图

顺序图描述的是各个线程之间的，也可以不是多个线程而是多个对象之间的，互相交互的一个顺序的过程。每个线程都有其生命线，而在生命线的过程中，它们会与其他线程之间进行消息的传递。类似于操作系统课程中的进程间通信过程。只不过这个是更为抽象的概念，不局限于进程，也不局限于通信。状态图可以很好地描述多线程程序的运行过程。

可以看到，UML的类图、状态图、顺序图三者之间是互补的关系，各自都要满足彼此之间的约束。在开发之前进行正向建模，事实上，对开发的进行是由很大帮助的。就相当于在开发时顺着既定的框架走，可以大大减少开发的难度，提高开发效率，同时保证程序的可靠性。

本单元作业的架构设计及代码设计和UML模型设计之间的追踪关系

架构设计

本单元中，需要对图书馆的借书系统进行建模。图书馆里有一个自动机器，借还管理员，预订管理员，以及整理管理员。其中自动机器负责查询，自动机器和借还管理员负责借还书，预订管理员负责预订，整理管理员负责整理。在我的架构中，这些都是要单独建类的，除此之外，书本和学生我也是单独建类的。然后对这些管理员具体功能的调用，我是在main函数里实现的，就相当与将main函数看成整个图书管理系统，这是我第一次作业的架构。
第二次作业中，需要对图书管理系统加入跨校借阅和购买书籍的功能，还加入了图书管理处这个管理员，负责进行校际借阅的相关流程。因此，在第二次作业中，我开了一个School类，用来表示每个学校单独的图书管理系统。同时，每个学校都拥有各自的管理员，学生，以及书籍。而main函数则代表管理所有学校的最大的图书管理系统。
第三次作业中，在设计层面只增加了一个逾期罚款功能，很快就能解决。

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

第一次作业要求画类图。在代码设计上，需要与UML的类图之间一一对应。具体来说，需要保证每个类，类中的属性，类中的方法，方法的参数，都与UML类图完全一致。
第二次作业中，需要在类图的基础上，画状态图，表示一本图书在借阅归还的一系列过程中，书本的状态变化和转移过程。状态图和代码设计的追踪关系要求对每个状态转移都要有对应的设计性输出，同时，每次状态转移必须对应某一个方法。
第三次作业中，需要在类图和状态图的基础上，再进一步画顺序图。以表示各个类之间的消息传递的过程。同样，规定的每一次消息传递都要有对应的方法和设计性输出。

三次作业总的UML图如下:

类图:

状态图:

顺序图:

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

在四个单元中，我的架构设计思维整体来说，是从面向过程到面向对象逐步转变的。在第一单元，我的思维整体还是面向过程的，这不光是指我写了两百多行的展开函数，最后压行压成了几个四不像的函数;同时也指我没有对各个因子(表达式因子、函数因子、变量因子、常量因子等)进行属性和方法层面上的抽象。这些问题直接导致了我的代码写的非常冗长，而且有很多的分支判断，大大增加代码出现bug的概率。
第二单元是多线程调度，在这一单元中，我吸取教训，在第一次作业的开始就作好规划，尽可能地用更多的类、更多的方法去对业务需求进行抽象，而不是把它们全挤在一个类或者一个方法中。这让我接下来的迭代和代码测试都相对第一单元轻松了一些，也没那么容易出现bug。
第三单元是JML规格设计。这单元主要是根据既定的JML规格进行代码编写，与架构设计的关系较小。
第四单元也就是这一单元，主要是考验UML图和代码设计相吻合。同时也需要较好的架构设计。在架构设计上，根据需求进行架构的设计就可以了。

四个单元中测试思维的演进

在数据构造的方面，由于我一直用的是别人的评测机，很难说对数据如何构造能更好地测出bug这一层面上有什么进步。但是，在已经知道有bug的情况下，在测试数据已经证明程序出错的情况下，如何更快地定位到bug出现的位置并加以改正，在这方面我还是有演进的。
具体来说，从第一单元我找一个bug要在每一个分支上加上断点，到第二单元我要在可能出错的地方进行打点输出。再到第三第四单元我只需要对特定的方法中的关键几步加上断点，且面对测试数据我能很快地知道是哪一个方法出现了错误。这样的进步固然是在代码测试的过程中找bug经验的积累，同样也是对架构设计的更为清晰，对代码运行逻辑有整体观念的体现。

总结自己的课程收获

面向对象程序设计这门课，作为一门三学分的课程，虽然没有理论考试，但它的任务量以及工作量，都是我所经历的课程里，算是最重的一批了，比起CO、OS也是不遑多让。在这门课的学习过程中，我体会到了面向对象程序设计的具体逻辑，更重要的是，我对未来职场上很可能遇到的巨额工作量以及客户(甲方)的奇葩需求都有了较为深刻清晰的认识与体验。
总的来说，OO这门课很累，但收获也是十足的。对代码能力，面向对象思维，以及测试思维、抗压能力，都有十分充分的锻炼，是非常充实的一门课程。