BUAA - OO - 第四单元作业与学期总结

BUAA - OO - 第四单元作业与学期总结

1. 第四单元

  • 搭建 UML 解析器，使其支持对 UML 类图、状态图和顺序图的分析
    • 可以通过输入相应的指令来进行相关查询
    • 并能根据 UML 规则进行一定的规范性验证。
  • 重点在于理解架构的层次，其次才是厘清查询与验证的要求

1.1 架构设计

0. MyImplementation

  • 由于每个类至多500行，因此把所有方法的实现都塞到MyImplementation中是不够优雅且破坏风格的，因此我们让MyImplementation变成一个分流存储所有必要元素的实质性接口，而在其构建的类图、顺序图和状态图中执行相关的查询指令与规范性验证。
tophierarchy

1. classmap

  • 为了在classmap中实现8个查询指令和规范性验证001-005，我们建立如下架构
classmap
  • MyParameter：将Parameter封装为按(direction, type)排序的类型
  • MyOperations：存储每个operation含有的MyParameter
  • MyInterfaces
    • 存储每个interface含有的attributes和MyOperations
    • 存储每个interface的父interfaces
  • MyClasses：
    • 存储每个class含有的attributes和MyOperations
    • 存储每个class的父class
    • 存储每个class实现的interfaces
    • 存储每个class关联的associates

2. sequencemap

  • 为了在sequencemap中实现3个查询指令和规范性验证006、007，我们建立如下架构
sequencemap
  • MyCollaborations：存储每个collaboration含有的attributes和MyInteractions
  • MyInteractions
    • 存储每个collaboration含有的endPoints和MyLifelines
    • 存储每个collaboration收到的message
  • MyLifelines
    • 存储每个lifeline，endPoint与他们的关联
    • 分类存储每个lifeline收到的message

3. statemap

  • 为了在statemap中实现3个查询指令和规范性验证008、009，我们建立如下架构
statemap
  • MyStateMachines：存储每个MyStateMachine和他们的region
  • MyStateMachine：存储stateMachine的region和states
  • MyTransition：存储transition的event和opaquebehavior
  • MyStates：存储stateMachine的pseudostates，states，finalStates与他们的MyTransitions
  • StateGraph：stateMachine建图

1.2 算法与性能

  • 图论算法都用dfs解决也基本不会超时，所以就不管算法了（
  • 对所有重要元素都建了id -> element的HashMap，因此查询变得足够方便

2. 架构设计思维与OO方法理解

  • 第一单元：
    • 最开始虽然对OO没有概念，但还是具有输入格式化-表达式化简-输出格式化的顶层架构
    • 此时的写法虽然可行，但过于依赖正则表达式和字符串替换，因此可读性、稳定性、可扩展性都很差
    • 在训练和实验后，开始采用递归下降法作为表达式处理的核心，并建立了表达式因子的递归架构
    • 此时类的封装与可见性使我对OO在层次化设计上的优势有了理解，对于开闭原则和功能解耦也有了基本的实践
  • 第二单元：
    • 对线程的阻塞唤醒调度和信号量的应用十分重要，虽然我在OS学完这一部分之后才真正理解（
    • 线程交互成为了架构设计的核心问题，此时架构设计基本就是围绕几个核心线程进行需求扩展
    • 架构迭代的效果直接在几次作业的推进中得以体现，但同时坏架构导致的重构也更加明显
    • 设计模式在OO中的重要作用得以体现，不管是生产者-消费者模式、观察者模式这样确定设计基调的模式，还是单例模式、工厂模式这样优化设计过程的模式都是OO中重要的模式
  • 第三单元：
    • 根据JML契约的设置，对于契约设计和异常设计（抛出条件与计数）在架构设计中地位的有了进一步认识
    • 一定不能背离契约设计要求的写法进行完成
    • 鉴于效率的要求，可对算法的设计有所变通
    • 随时复习图论和算法，尽管java有一大堆库，但是算法的技能是不能替代的
  • 第四单元：
    • 基于UML类图、顺序图和状态图的架构，对于类的封装，类之间的信息交互与大规模复杂架构设计有了进一步认识
    • 一定要先做好架构设计并进行尝试，拒绝冲动作业与空想式设计
    • 要敢于进行完备与复杂的架构设计和编写，要敢于重构而非在不完备架构中钻空子
    • 要在贯彻开闭原则的条件下对类和接口进行功能解耦，这样的拆分有利于内容修改与功能扩展

3. 测试与实践

  • 第一单元：
    • 手动测试：针对基本情况进行等价类测试，并定位特殊的输入输出情况进行专门测试
    • 自动测试：按照一定逻辑大量构造随机表达式，以此分类覆盖全部基本情况，与同学对拍
  • 第二单元：
    • 手动测试：利用评测机数据进行修改、构造极端数据，进行线程安全测试与效率测试
    • 自动测试：按照一定逻辑大量构造随机请求序列，以此分类覆盖主要基本情况并排查线程安全问题，与同学对拍
  • 第三单元：
    • 手动测试：精读契约要求，分类定位特殊问题，构造合理指令序列进行测试，可利用JUnit
    • 自动测试：按照一定逻辑大量构造随机指令序列，以此分类覆盖全部基本情况，并与同学对拍
  • 第四单元：
    • 手动测试：理解架构要求，分类定位特殊问题，构造合理图表结构与指令序列进行测试
    • 自动测试：制造数据难度较大且意义有限，故主要手动测试

4. 学习收获

  • 初步理解了面向对象的原则、架构设计思维和设计模式
  • 初步接触了多线程编程
  • 进一步提升了代码编写能力：算法、风格等等
  • 进一步进行了迭代性的、有一定规模的工程设计训练
  • 进一步提升了代码静态分析和测试的能力
  • 进一步提升了与他人合作开发的能力
  • 进一步提升了资料查找能力
  • 心态发生了一些变化

5. 改进建议

5.1 课程进度

  • 前两单元的内容来不及自学，尤其是第二单元，希望能增加预习内容的介绍，并要求假期强制预习
  • JML和UML单元的难度偏低，且有助于理解架构与能力过渡，希望将他们压缩并前置
  • 多线程单元在理解和操作上的困难远超其他单元，且与OS核心实验部分撞车，希望将其后置

5.2 课程内容

  • 可在训练和实验中增加一些模板性内容
  • 可在讨论区增加对于困难作业部分的提示
  • 可在研讨课中增加与困难作业直接相关的引导性话题
  • 可在教学课中增加OO思维和java语言本身相关的内容，如设计模式等等

5.3 课程评价

  • 希望能有一些得知成绩算法的途径
  • 希望能有一些补救成绩的途径（OS都有实验强测了）
posted @ 2022-06-29 01:14  Ph_D  阅读(36)  评论(2)  编辑  收藏  举报