「BUAA OO」Unit-4 UML

UML - Unified Modeling Language

一、第四单元正向建模与开发

在第四单元中的，课程组让我们体验了一下正向UML建模 + 基于UML进行再开发的项目开发流程。

第四单元的正向建模开发大概包括四步：

1. 根据用户需求设计UML图，确定类、接口及其关系，确定方法和属性，完善UML类图
2. 基于UML类图，也就是原先最初的设计进行代码编写。
3. 根据实际编写的代码，逆向修改UML图，进行UML图的再设计
4. 根据UML图的修改，对代码进行再编写。

当然其中的第三步和第四步会不断重复循环，直到项目编写成了开发者想看到的样子。

在第四单元中，个人认为正向建模开发最大的好处就是能对项目整体有一个把握。不论是对数据结构的把握（属性、数据结构、继承），还是对象行为上的设计（方法、抽象、实现），设计者都能够在开发先前对整个项目有一个十分全面的把握，从而避免了在开发流程中不断进行小迭代、小重构的可能。

正向建模开发的缺点

但是一码归一码。在第四单元中，经过了第十三次作业的正向建模开发后，个人认为正向建模开发同时也存在不少问题：

1. 首先，正向建模开发需要开发者对用户需求有相当全面的把握和理解，而这种理解需要时间思考。
2. 其次，正向建模开发可能会让开发者不断在UML设计和代码编写中反复横跳。

这两点在某种程度上时相互制约的。如果开发者未能做到第一点，也就是未能从整体上把握住项目的整体设计，那么在之后的项目开发中很有可能不断“重写代码 + 重写UML”。而如果开发者想避免第二个缺点带来的苦痛，就需要花时间不断完善自己的设计，等到设计好了再进行代码编写。

从项目设计的角度而言，正向开发毫无疑问是是一种很强的开发流程。就第四单元来说，正向建模开发似乎显得不必要。但是从课程和学生的角度来说，正向建模开发十分有必要开展并体验一番。

二、第四单元架构设计

总体来说，第四单元的三次作业中，除了第十三次作业略微使用了正向建模开发，此外均是抛开UML图进行设计

三次作业中，整体架构设计的演进如下：

第十三次作业

• 加入了图书馆类，用于表示图书馆的整体运行情况。其中的run()方法能够让一个图书馆对象运行起来。
• 加入了书架、周转台、预约处、学生四个类，表示图书的所在位置
• 加入了书本类，用于表示大量书籍，同时也是不同部门间传递书籍的最基本的单位。

第十三次作业的整体设计比较简单，类与类之间的关系如下图所示。

↑ 第十三次作业

第十四次作业

• 加入了BookOwner类来统一管理拥有书籍的类，包括书架、图书角、周转台、书架和学生。这大量简化了周转台和书架的代码量。
• 加入了ReservationInfo 和 ReservationInfos 预约信息类来表示预约信息，也正因如此预约台没有继承BookOwner，而是由ReservationInfos组合成。

↑ 第十四次作业

第十五次作业

• 没有引入任何新类，只是在原有的基础上进行动刀。类间关系没有任何改变。
• 将BookOwner弱化成了抽象类，因为它没有实例化的机会。

↑ 第十五次作业

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

UML模型设计主要分为三个部分：类图、状态图和时序图

在类图上，由于代码与UML的一致性难以维持（打字错误），于是用JavaParser写了一个简单的类图生成器，用于生成UML类图中各个类的属性和方法定义，再手动修正类与类之间的关系。效果不错。

（UML生成的源码在Github 上，个人感觉实际应用不大，主要是为了应对Unit4的UML评测）

状态图用于维护图书的状态。具体来说，就是图书在不同图书持有者之间的流动。通过编写@Trigger，可以确定状态图中一次状态的转化的初态末态和Trigger，也就是方法名称。因此也可以写一个简单UML状态图生成器，再手搓Guard字段。在第十五次作业中，UML状态如下图所示。

可以看到，基本包括了应该有的状态。

顺序图的一致性就很糟糕了。可能也是到最后一次作业了，比较懈怠，并没有保持好代码与顺序图的一致性。另一方面，由于顺序图的绘制过于麻烦，第十五次作业中并没有画好顺序图，在此不做展示。

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

个人认为演进过程不是很好描述，毕竟在设计思维在不断变化，而我也没有记录下过膝的设计思维是如何的，所以也只能谈一谈现在的设计思维了。

总的来说，设计思维和吴老师在课上讲的内容逐渐吻合，最大的特征在于项目的层次化设计愈发明显。

首先，在拿到任务需求之后，我会合理分析各个类的设计和定义，构建层次化的项目结构。同时，在必要时可以抽象出控制类用来专门管理不同类和对象之间的关系。

其次，在先导课中没有得到充分锻炼的实现和继承，经过了四次作业的洗礼之后也能够摸到点皮毛了。基本上，在迭代开发的过程中，遇到了高度相似的数据结构或者行为，就会有意识地抽象出父类或者接口，进而简化代码开发。

此外，在第一次和第二次作业中，我可能还会出现五六十行的方法。在第四次作业的开发过程中，我慢慢地能够找到要在什么层次完成什么工作。

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

debug的最好方式就是不写bug。

在四次作业中，我进行的测试可谓是少之又少。而在这少之又少的测试中，做的最多的毫无疑问就是功能性黑盒测试。

在Pre中吴老师交了我们如何进行单元测试。但是经过了JML之后，我发现契约式设计比单元测试更为有用。倒不是说真的要用JML，而是定好了一个方法需要满足的前置条件和后置条件之后，但凡是稍微简单一点的方法就很难写错，进而避免了一个方法究竟要在那个层次完成何种功能，前置条件的判断究竟要放在方法体内还是调用者那块儿的苦恼。我并没有在设计中使用适当的 annotation 标明契约，而是用注释的方式清晰地表述了出来。

六、课程收获

真心感谢OO，是一门能够学到本事的课。或许在未来里我们不会用到java语言，但是其中包含的面向对象设计思想真能让码农一辈子获益。

要说课程收获的话，最大的收获就是层次化设计上的收获。这在前文（第四部分）已经叙述过。也希望之后的面向对象思想也能够刻印在我的脑子中。

此外，OO课程对代码能力的提升也是巨大的。IDEA + Vim插件让代码速度快到飞起。熟练的Java语言编写使得个人能从OO作业中获得强烈快感。

如果一切幸运的话，希望明年也能与OO再见！