OO课程学期末总结

Posted jeffan

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了OO课程学期末总结相关的知识,希望对你有一定的参考价值。

 OO课程学期末总结

测试VS正确性论证

技术分享图片

OCL vs JSF

对象约束语言(Object Constraint Language), 简称OCL, 是一种指示用户建模系统中的限制方式。 他是UML可选的附加内容, 可以用来更好地定义对象的行为, 并为任何类元指定约束。

  • 相似性:
  1. 形式化语言:基础都是集合论和谓词逻辑。是选择有歧义的但是多数人能看懂的自然语言,还是无歧义但少数人才能看懂的数学符号,OCL和JSF选择了“中庸之道”。(不过JSF的形式化没有OCL那么强)【PS:数学、逻辑和计算机科学中,形式语言(英语:Formal language)是用精确的数学或机器可处理的公式定义的语言】
  2. 声明式语言:就是描述了应该做出什么结果,而不是应该怎样做才能达到某个结果,给出了结果而非具体过程。
  3. 描述的约束相似:OCL可以描述4种约束:不变量、前置条件、后置条件、监护条件。JSF类似。

  • 不同之处:
  1. 类型化语言:OCL中的每一个表达式都是具有类型的。这些类型包括:标准类型、UML图中的元素、上述元素的集合。
  2. 表达能力:OCL表达能力更强、也更严谨。
  3. OCL是和UML(统一建模语言)绑定的,JSF是直接面向代码。

第14次作业单电梯系统UML图

类图(greenuml自动生成):

技术分享图片

时序图(plantuml代码生成):

技术分享图片

状态图(不知为啥plantuml用不了,我就画图软件手画了,状态转移比较简单):

技术分享图片

【PS:这里的STILL是广义静止,包括 到达某请求目标楼层而导致的静止(可能马上又要移动),及,没有请求而导致的电梯空闲静止】

整理总结一个学期所学所练

关于四个单元模块

技术分享图片

  • 知识点循序渐进,从基础思想到设计原则,抽象层次越来越高,从代码完成到测试和验证,一步步完整实现工程开发。
  • 老师并没有讲语法,毕竟大家都有其它语言的基础,因此语法方面全靠大家自学。
  • OO开课前,由于我既没选大一下的java课,也没选暑期java先修课,心里有点虚,于是暑假用两周时间,看了中国大学MOOC浙大翁恺老师开设的:《面向对象程序设计——Java语言》,翁老师讲得真心好,特别是结合了实例,让我对面向对象的基本思想有了比较深入的了解,为本学期的OO课奠定了很好的基础,在这里种草一下。

梳理历次作业的收获和进步

技术分享图片

阐述自己对工程化开发的理解

  • 百度了下软件工程的开发过程:需求分析、设计(总体)、实现(细节)、测试、验收、维护。
  • 工程化的一套流程,使得开发一个复杂易变的大工程这事儿 更加流程明确和高效,真是妙啊。
  • 不过OO课只是给我们打开了软件工程的一扇小窗,让我们在一轮又一轮作业中强化体会前四个环节。特别是设计和实现分离,设计好了,实现也就是解决一些小细节而已,要是没设计好就急忙动手,那必然是内心空虚的蜗牛式前进。
  • 顺带一提,每次作业都要静下心来认真分析指导书的需求,以后每次做一些很长很复杂的题、或者遇到复杂的实际情况时,就会告诉自己“指导书你都看过那么多了,还对付不了这个吗!”,以增加自己的耐心和自信心,这一点可以说是OO课给我的最大收获了【没事多逼逼自己,如果决定要翻过这面墙,就先把电脑丢过去】

对课程的期望或建议

  • 一个不良现象:由于客服群分散为3、4个,因此可能会出现各客服群对同一问题的回答不统一的问题,进而出现 误导学生直至提交作业后在互测时才发现回答不统一,或,误导学生且在未提交作业前突然发现口径不一然后天降需求。这不是学生或助教的错,而是这个问答机制不大完善。用客服助教来模拟用户,结果却发现用户使用了分身术提出不同的需求,这显然不是课程组希望看到的。
  • 针对上述不良现象的几个可能的解决方法:
  1. 客服群之外再建一个群 专门发通知 不允许发问,但是这就需要每个小客服群在回答每个问题之后就发通知,助教除了要回答问题,还要把问题描述清楚(当然截图也海星)之后发通知,还要注意有没有其他助教已经发过这个问题的通知。助教比较累。

  2. 建一个大群,舍弃小群,不允许水群比如发表情包和其它与OO无关的东西。要求提问和解答的内容都尽量控制在一段话内,不要分开发多条消息,想清楚了理好逻辑了再问/再答,每个时间段固定由某位助教回答,重复提问者给予黄牌警告(大家共同监控)。这样能减少水群信息,方便你我他。不过对于提问者和问答者的要求较高,大家不一定能做到,不易实施。

  3. 大就大到极端,舍弃群聊,只保留讨论区,这样会减少很多提问的次数,因为大家似乎不大愿意在讨论区发问,进而,按照大家“不提问就不会改需求”的逻辑,改需求这事儿就会变少,顺便要求ddl前一天不允许提问好了,以免天降需求呵呵。

  4. 小就小到极端,分成7、8个小群(绝对不能按小班分),保证群内人员互测。对于关键问题的回答,由助教保证与其它助教的回答统一,不关键问题的回答,助教自由发挥,互测时以助教回答为准,该助教负责这个小群内的同学的仲裁工作。但是,或许容易发生私下交易,而且如果指导书的部分需求很不明确时,同学们会大量发问,而且和其它群的同学的问题相似,助教工作较多。

【哇,设计好一门课真是不容易】

  • 然后就是互测的问题了,建议在互测仲裁中加入扣分机制。即,仲裁结果分为:
  1. 确有其事,报告bug/imcomplete成功,测试者得到测试的加分。

  2. 双方观点都挺有道理,报告bug/imcomplete成功/失败/和棋。
  3. 测试者恶意测试,报告bug/imcomplete失败,测试者扣分。
  • 最后,希望这门课能越办越好,达到课程组真正的教学目标,同时也得到学生们的认可:

  ——“这门课虽然虐人,但是学到了好多好东西,被虐得挺值的嘿嘿嘿”。

以上是关于OO课程学期末总结的主要内容,如果未能解决你的问题,请参考以下文章

OO课程学期总结

OO期末总结

教学法学期末考试MOOC01

教育法学期末考试02MOOC

OO助教工作总结(退休撒花

期末课程总结与个人总结