272
社区成员




正向建模与开发是指在代码开发过程中,先通过需求说明,通过抽象分析构建系统模型,并指导后续的设计、开发和测试。
在本单元作业的开发过程中,我使用基于实践的正向建模方式,也就是说,先画出一个并不标准的类图,只标注出主要的类和重要的方法,然后根据类图编写代码,最后根据代码修改类图
在使用正向建模的过程中,我感觉到正向建模不是“从模型到代码”,而是模型和代码的互动,初期建模为开发提供方向,而在实际开发中,代码的演变又反过来促进了模型的完善,经过不断的迭代,才能开发出优秀的代码。
第一次作业中,我为图书的每一个状态定义了一个类,并增加了User类,Book类,Library类,Move类,其中的Move类用来存储一本图书的一条移动信息
类图如下
在第二次作业中,我发现我的Move类和官方包的功能是重复的,但是这个类也可以实现功能,于是我没有删改Move类
在本单元的作业中,我增加了ReadRoom类用来实现阅读和归还功能。对于热门书籍,我认为Book的state属性为HOT_BOOKSHELF就足以说明书籍是热门书籍了,我只需要修改Book类的状态迁移相关的代码,而不需要新增一个HotShelf类
第二单元的类图如下
在第三次作业中,这次作业没有增加新的类,由于需要在用户预约后不取和阅读之后不还时扣除信用分,我选择将存储所有用户的ArrayList<User>作为Library、AppOffice的共享变量,实际上增加了系统的耦合度,这说明我的模型构建方面的问题,如果在设计的时候增加一个Users类管理所有的User会好很多
最终的代码设计和UML模型之间的所有的类和大部分的方法都是对应的,这也说明了UML模型设计的重要性
在本单元中,我主要通过大语言模型辅助提取项目需求以及根据描述生成代码。以下是我在使用过程中的一些体会和反思。
首先,大模型在提取项目需求方面确实提高了效率,能够快速整理出大部分核心功能,但在处理细节时容易出现遗漏。例如,在第三次作业中,我让模型生成图书馆管理系统的主要需求时,它忽略了“图书馆并不是每天开放”这一关键细节。这提醒我,大模型的输出仍需人工仔细审查,不能完全依赖。
在类图生成方面,直接让模型创建完整类图时,其结果往往忽视了代码的耦合性和可扩展性,设计也不够合理。如果我先给出应该包含的类,再让模型补充属性和方法,效果会好很多。同时,我发现不宜直接要求模型修改整个类图——它在修改时经常会做出我未要求的删减或重命名操作,例如擅自修改类名。因此,我认为较为理想的做法是由我主动设计类的结构,并借助模型进行逐步完善和讨论。
大模型在判断代码的耦合程度和复杂度方面表现较好,能指出一些我未曾注意的设计问题。通过这种方式,我可以更有针对性地调整建模方案,提高模型质量。
在第一单元的架构设计中,我存在的问题是类的划分太多了,我在表达式解析和生成结果的过程中分别构造了两棵树,第三次作业的代码中存在21个java类,整体看下来有点臃肿,为了避免出现ctle我删除了对于结果表达式进行化简的大部分代码。也降低了我的性能分
在第二单元的架构设计,我的架构设计在职能划分上出现了严重的问题,我的策略是电梯之间自由竞争乘客,以多捎带乘客为主要目的,电梯会在力所能及的范围内拉取离本电梯最近的有人的楼层中移动方向相同的所有乘客。在第六次作业中,电梯的运动逻辑写在电梯类里面,判断逻辑过于复杂,导致debug比较困难。在第七次作业中,我选择将控制电梯运行的逻辑分离出来,但是我选择将电梯的运动分离出来一个类(运动/开门/上下人/关门/调度/改造),类的关系过于复杂。
第三单元的主要类都由JML规定好了,我只是增加了一些辅助计算的类,并不怎么改动代码的架构
第四单元中,我吸取了前几个单元的架构设计的教训,我的架构设计总体上没什么大的问题,职能划分比较合理。
在四个单元的学习过程中,我广泛使用了大语言模型辅助测试。以下是我在各单元进行测试的具体经验。
第一单元我使用大模型生成评测机,主要包括测试用例的生成、对拍两部分,除了使用大模型的对拍程序,我也和其他同学对拍,实现了比较良好的debug效果
第二单元的程序功能比较复杂,不像第一单元可以直接使用sympy库比较两个表达式是否相等,第二单元的程序是多线程的,很难直接判断输出结果是否正确,这一单元我的测试方式是:手动构造测试用例、把输出结果和输出限制丢给ai,秦穆公ai判断输出是否存在问题
第三单元由于直接给定了JML约束,可以直接使用ai生成正确代码,这一单元我的测试方法有:1.直接使用ai生成测试用例。2.将所有id限定在-10到10的范围内,随机选择指令,生成高强度测试用例,与正确代码对拍。3.生成随机指令,覆盖每一个分支,但是仅限第10次作业。
第四单元的重点更多集中在类图建模与功能设计上,我主要使用ai生成的测试用例和自己构造的测试用例
在测试过程中我意识到:测试的核心不仅仅是发现错误,更在于通过测试用例精准定位出错的代码行或模块。在这方面,良好的程序架构设计能够显著提升调试效率。而大模型在测试生成和结果分析方面虽不能完全替代人工判断,但作为一种辅助工具,能够在构造复杂用例和分析边界情况时提供很大帮助。
通过本课程的学习,我了解到了Java语言的基本语法和特性,学会使用一些库,此外我也学会使用“面向对象”的方式去思考和解决问题
课程通过多个单元式项目逐步展开,从基础的语法练习,到多线程、JML 规范,再到 UML 类图建模 ,每一个单元都环环相扣,训练了我在需求分析、代码实现、测试调试以及结构优化方面的综合能力。
此外,我还学会到一些优秀的设计思想,比如使用递归下降分解问题、多线程模拟实际问题、使用李氏替换原则判断接口设计的合理性、建模思想等
在实践中,我尤其体会到良好的架构的重要性。合理划分类职责、控制耦合性、使用继承和多态实现扩展性,都可以极大地增加项目的可扩展性和可维护性。
另外,我尝试在多个单元中使用大语言模型辅助建模、调试和测试,这种辅助方式虽然并不完美,但在需求整理、类图构思和测试用例生成方面提供了不少启发,也让我意识到人机协同在软件工程中的潜力与边界。