BUAA OO Unit4

最后一次博客啦！！！

本单元所实践的正向建模与开发

所谓正向，即从概念->实物，在本单元来说，就是先针对问题进行设计，画出类图、状态图与顺序图等UML图，再根据图来实现代码。可以说，图是我们思维的体现，有了图，再去实现代码就变得更加容易，也会让工作变得更加有序，不会出现直接写代码那种茫然无措的感觉。

在第十三次作业中只要求我们实现类图，我们需要根据题目要求考虑要实现哪些类，各个类之间有着怎样的关系，并将他们在类图中实现。一开始并不需要把所有方法与属性表明，因为有些可能会在代码实现中出现相应的方法属性要求，这种再加即可，我们只需要表明主要方法与属性。开始的时候，类图的更改是非常频繁的，就比如我这次的实现：一开始，我并没有一个好的思路，我尝试创建一个message类用来实现消息在各个地点的传递，借还处、预约处与书架都继承一个相同的父类。后来在这个架构上继续深入考虑方法实现的时候，我发现这样的设计要考虑很多东西，实现起来并不好，而且继承并没有起到很好的效果，几个地点的共性没有之前预想的大。因此我又重新考虑了新的实现。上述改动都在类图中发生，并没有出现之前在代码中实现那种大幅改动代码的情况，更加直观且减少了自己工作。

第十四次作业要求我们实现状态图，其实如果对第十三次作业有着充分理解之后，状态图中书本的移动逻辑并不是一个特别难的问题。不过，状态图的状态转移与guard的几个规定导致图画起来比较困难。我认为，这是自己的实现问题，可以为book类添加一个属性来表示其位置，并在book类中实现相应方法，这样应该能更容易画状态图。不过这周比较忙，就简单画了一下满足要求就交了。

第十五次作业要求我们画顺序图，来体现消息传递过程。同样，对作业充分理解后画起来并不难，就不多说了。

在经过了这三次作业之后，我对正向建模的过程有了更深刻的认识。整体来看，在我的实现过程中，类图是比较重要的，主要的方法与属性都在里边体现，类图明确后，整体代码实现就会变得简单。状态图侧重单一对象（类）的属性改变，可以用来明确重要的类的行为过程。顺序图体现类之间的交互，让我们明确通过哪些方法进行交互。有效利用UML图，真的可以为我们的编程提供很大的帮助。

本单元作业的架构设计

最终架构如上图。

第十三次作业要求我们模拟一个小型的图书管理系统，完成图书馆所支持的相关业务。图书馆要实现开闭馆行为，在开闭馆时处理请求。开闭馆时图书管理系统需要处理的请求包括：借书、还书、查询、预约和预约取书。首先MainClass主类用于接收请求，处理后交由library类处理，library将不同请求细化为不同对象的行为进行处理，并对它们进行同意管理。ApOffice、BdOffice与BookShelf为实现的第十三次作业中其他几个场所，Date类用来表示时间以及用于处理时间相关的判断，student表示借书的学生。这次作业中的book我并没有新建一个类，而是选择用librarybookId表示，这导致我需要在ApOffice中使用多个HashMap来处理相关信息，如借书人，书籍送来时间，书籍数量等。第十三次作业明确了整体架构后，后续两次作业改动较少，基本均采用这个架构。

第十四次作业在第十三次作业的基础上增加了图书借阅期限，增加了新地点：图书漂流角（漂流角中的书与书架中书有着不同的处理方式），增加新请求：续借。由于上次ApOffice中多个HashMap的复杂以及这次新增了续借与图书借阅期限，我选择新建一个Book类来表示图书，其中属性date在不同位置有着不同含义，比如在Student中存储时用来表示借出时间，而在ApOffice中表示送达时间。forWho用在ApOffice中表示书是为哪个人送达。同时，其他地方修改一下代码并增加相关方法以适应book类的重构与相应需求更改即可。

第十五次作业在上一次作业的基础上增加了用户信用分系统并对一些方法进行了限制。这次作业比上次作业的工作量还要少，最关键的就是在Student类中加一个credit属性，并添加相应方法，同时修改代码以满足本次作业的限制即可。

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

第一单元采用公众号上提供的递归下降法的思路，整体架构并不需要过多考虑，更多考虑的是内部方法的实现。这一单元主要学到的就是递归下降法的思路，以及将任务分解进行处理，即层次化处理的思想。同时，这一单元让我更深入理解了面向对象的含义，让我做到在处理问题时用面向对象的思想来思考。

第二单元在架构设计上我学到的主要是层次化设计。第二单元的作业课程组同样提供了架构参考，即生产者-消费者模式。但在这个模式下，如何进行进一步的架构设计，减少类之间的耦合程度并实现程序的层次性，是我们需要思考的。除了架构设计上的层次化，我还充分了解了有关多线程的知识，对于如何在线程并发下实现线程安全，有了自己的认识与理解。同时，从这一单元开始，我养成了先明确需求行为，再去实现代码的习惯，这样的习惯让我的编写代码的过程更加高效。

第三单元的整体架构课程组已经给好，我们只需要根据jml来编写相关代码，尤其关注实现时导致的时间复杂度的问题。这一单元最大的收获是充分理解了规格的实现及作用。同时，用课程组的架构，让我充分认识到了一个良好的架构为问题的考虑与实现提供多大帮补。

第四单元的整体架构在前边已经给出，这次的架构是完全由我们自主决定实现。也许是作业需求对应的架构比较简单，抑或是采用的类图方式进行正向建模有利于我们的架构设计，这次作业的架构实现比之前要快很多。这单元作业的最大收获就是采用UML图进行正向建模，这个不但在课程中很有用，而且是以后工作中经常使用的东西。

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

第一单元的数据生成比较简单，我和同学合作编写了一个数据生成器，可以自行构造数据。这时的我对于测试还没有形成好的思路，只是不断地跑评测机，得到错误数据并研究数据来发现错误。

第二单元涉及到多线程，数据就更难构造，基本所有的数据都来自于DPO评测机。构造数据的不全面也导致了我这次作业的强测出现错误。这单元作业让我认识到了构造全面，针对性强的数据的重要性。

第三单元我们需要在JML的基础上编写测试，测试程序写起来并不难。这单元的作业让我充分了解了各种测试，并且我利用junit简单实现了自动化测试。这次测试最主要的问题就是性能，我所实现的测试程序无法测试性能问题，自行构造数据也比较困难，导致测试不够充分出错。并且这单元bug让我充分明白了压力测试、边界测试与回归测试的重要性。

第四单元没有互测，而且需求比较简单，没有之前几个单元那种特别恶心的边界数据，所以实现起来bug就比较少，采用dpo就都能解决。每次实现一次新的作业我都会进行一下回归测试，这是我上一单元作业中学到的教训。

课程收获

首先，OO（更多的是OOpre）让我又学习了一门语言--Java，虽然现在并没有接触到Java更多高阶的东西，但我至少对这门语言有了一个基础的认识，为我以后进一步学习使用打下了坚实基础。

其次，OO让我真正理解了面向对象的思想，在之前，我都只会用C的面向过程的思维来考虑问题。现在，经过OO的学习，我可以用面向对象的思维来考虑问题并解决需求，为我解决编程问题提供一个更好的思路，一个更贴近生活的思路。

另外，OO增强了我阅读代码的能力，现在针对一个较大的需求的相关代码，我能够很好地去阅读相关代码并理解其意义，这是半年前的我所做不到的。

最后，OO不仅是面向对象，我认为更是软件工程先导。在OO里，我们学到了很多软件开发所必须的技能。比如面向需求的架构设计问题，层次化设计问题，如何处理类与类之间的耦合程度，编写测试的能力，阅读JML规格、画UML图等能力。这些能力是我们之后上软工所需要的，也是我们以后步入工作中，进行相关软件开发所必须的技能。OO让我们初步接触了软件开发的相关工作，我认为这是比只去学习面向对象思想重要的多的。

经过OO的磨练，我能真正感受到自己编程能力的成长，也能清楚看到自己看待问题的变化，我相信这些都以后将成为我珍贵的宝藏。感谢OO课程为我们提供如此出色的课程，希望OO课能越来越好。