OO 第四单元作业总结

丁梓星-20374272 学生 2023-06-20 19:48:08

正向建模

在设计领域中,正向设计是从概念、模型,产生实物的过程。与正向设计相反的是逆向设计,是先有实物,通过对实物的观察(扫描、获取三维坐标点)获取实物的模型,然后对模型进行再次创新。

软件工程中,正向建模是一种自顶而下的软件设计过程。从高层次的总体功能出发,对每个层次的功能进行分解和细化,逐步达到对底层细节的设计,以实现对整个系统的全面把握。

正向建模有清晰的层次结构和元素关系,可以考虑到系统中的各个角色和各种业务场景,可以达到更全面的系统分析和设计。

本单元围绕图书管理系统,模拟图书馆中包括借书、还书、书籍修复、书籍整理、校际借阅等多个复杂功能和场景。通过UML类图绘制,我先明确了各个情况下的书籍位置状态转移图,并依此完成了图书馆各个部门的功能设计。

完成 hw13 时绘制的状态转移图如下:

img

设计架构

对象类包括Book, Shelf, Student,以及几个图书管理部门。根据图书的状态转移需求设计架构结构。

hw13类图结构:

img

最后形成的 hw15 的类图结构:

img

随着设计需求的推进,三次作业迭代中修改的内容主要有:增加了继承结构;强化了分级代理的协作结构。

类的继承

hw13中各个图书管理员类的责任各异,实现中几乎没有共性的重复功能和结构,当时觉得没有构建父类的必要。

在 hw14 中,添加了多个学校的场景,因此所有的管理员可以共享学校信息自身所处的学校信息,简化设计。除此之外还有重复的校内和校外书本存储结构,及图书整理和图书运输的功能。因此添加了统一的父类 Librarian。

分级代理式为主,中心控制式为辅的结构的类协作模式

在多个学校图书馆的背景下,使用了一个图书馆系统 LibSystem 类,统一读取命令,分发到对应的图书馆执行;在 LibSystem 中进行时间管理,对各个图书馆的整理、校际运输操作进行统一调配。

各个部门之间的数据传递(图书运输等),通过各个类的关联关系完成,即一个类中可以包含另一个类的实例,调用其方法实现功能。比如整理书籍的功能,ArrangingLib中包含其他几个管理员类的实例,分别调用他们的 arrange() 方法后,将他们传回的图书整理上架。

因此,在完成一个功能时,往往需要形成 图书馆系统 -> 图书馆 -> 图书馆的某个部门 -> 图书馆的另一个部门 -> Student,Book 类 的消息传递(函数调用)链,整体呈现分级代理模式。

但在各个图书馆实现功能时,往往需要根据指令类型,调用各个部门的功能实现,存在一部分的中心控制式协作。

比如,预定购买图书的消息路径(UML顺序图)如下。

img

架构设计推进

面向需求和对象编程

第一单元的多项式合并架构设计时,我对对象的概念还不是很熟悉,在设计的时候关注的更多是如何以最简洁的结构实现最复杂的功能,关注的是代码底层的设计细节——数据的抽象和组织形式。

第二单元的电梯设计,在一个生活的具体场景中设计程序的运行,引导我们从设计需求和功能流程的角度设计,设计程序的结构。同时了解了并发场景的设计模式,在多 client 请求处理、工作流结构的基础上,在每次作业中逐步优化代码结构,以更合理的代码结构避免错误的发生。

第三单元强调规格的重要性,在标准化的规格编写中,了解到了在程序设计中需求的重要性,并深切体会到了需求和设计分离的思想。

至此,最后完成的第四单元作业就把面向对象的思想融会贯通起来,将文字表述的应用场景,先根据需求抽象成层次化的模型,组织各类的方法时更多处于贴合生活实际的考虑,以此预测系统未来的迭代方向。在完成整体架构设计,保证模型能够覆盖作业需求后,我再分离的思考各个函数功能的实现方式。第四单元作业完成的速度很快,hw13的结构也很好的继承至hw15,重构大大减少。

高内聚和低耦合

在4个单元的迭代中,我的类结构逐渐变得更加清晰,每个类的属性和方法复杂度也大大降低。

这也和整体的代码设计有关。在前几单元因为架构设计只得其形,在实现过程中更多的面向功能而不是面向对象,往往代码组织随意,功能实现复杂。

通过构架的优化设计,类的规模、代码方法的耦合度也降低了很多。

这是第一单元的代码度量平均值:

img


img

这是第四单元的代码度量平均值:

img

img

测试思维推进

第一单元的测试采用的是大部分手搓 + 借助大佬评测机。第一单元的设计场景下,如果程序基本能够正确运行,那么大部分出错场景都在极端数据上。列举想得到的极端情况,手动构造符合条件的数据,是我第一单元的主要测试方法。

第二单元和第三单元就越来越依靠与自动化工具,少数情况自己构造随机生成代码覆盖不到的极端情况测试功能。

其实后面几个单元都是在白嫖评测机,没能有太多对构造数据思考。这也是这门课我比较遗憾的点。

课程收获

现在回头再看第一第二单元的代码,其中可以优化的地方数不胜数。一开始代码结构的不完善,除了设计思想的不够成熟,也是因为对 Java 语言和并发控制的不熟悉。我觉得oo课一个很大问题就是先导知识的不完善,对 Java 的使用、语言特性等介绍太少。虽然上学期有开设先导课,但真的是很难抢。而且我觉得我和身边上过先导课的同学,在前两周的代码设计真的有很大的差距。希望先导课能够开放更多名额,或者课堂中多介绍一些代码工具的使用。

oo的理论课大多以介绍概念为主。虽然和作业都是围绕着同一主题展开,但是理论课有些太过抽象和晦涩,设计模型、设计理念的介绍有些简短或者没能结合实际理解。理论课和课后作业的差距很大,理论课只能提供一个方针指导,大部分的学习发生在完成作业和每两周一次的实验课中,而不在理论课上。

但这学期确实实打实的领略到了面向对象思维模式的内涵。几个单元从对象、类的层次设计,并发设计,规格设计,规格设计几个层次,从细节到整体,从局部到抽象,展示了代码设计的基本要点,并切实的影响到了我的设计思路。

这学期在数据构造上的造诣不深,一方面是因为精力有限,一方面也是工具的不熟悉和编程思想的不完善。编程能力和效率还有待提高。

...全文
193 回复 打赏 收藏 转发到动态 举报
写回复
用AI写文章
回复
切换为时间正序
请发表友善的回复…
发表回复

444

社区成员

发帖
与我相关
我的任务
社区描述
2023年北京航空航天大学《面向对象设计与构造》课程博客
java 高校 北京·海淀区
社区管理员
  • 被Taylor淹没的一条鱼
  • 0逝者如斯夫0
  • Mr.Lin30
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧