OO课程学期末总结
测试VS正确性论证
OCL vs JSF
对象约束语言(Object Constraint Language)， 简称OCL， 是一种指示用户建模系统中的限制方式。 他是UML可选的附加内容， 可以用来更好地定义对象的行为， 并为任何类元指定约束。
- 相似性：
- 形式化语言：基础都是集合论和谓词逻辑。是选择有歧义的但是多数人能看懂的自然语言，还是无歧义但少数人才能看懂的数学符号，OCL和JSF选择了“中庸之道”。（不过JSF的形式化没有OCL那么强）【PS:数学、逻辑和计算机科学中，形式语言(英语:Formal language)是用精确的数学或机器可处理的公式定义的语言】
- 声明式语言：就是描述了应该做出什么结果，而不是应该怎样做才能达到某个结果，给出了结果而非具体过程。
描述的约束相似：OCL可以描述4种约束：不变量、前置条件、后置条件、监护条件。JSF类似。
- 不同之处：
- 类型化语言：OCL中的每一个表达式都是具有类型的。这些类型包括：标准类型、UML图中的元素、上述元素的集合。
- 表达能力：OCL表达能力更强、也更严谨。
- OCL是和UML（统一建模语言）绑定的，JSF是直接面向代码。
第14次作业单电梯系统UML图
类图（greenuml自动生成）：
时序图（plantuml代码生成）：
状态图（不知为啥plantuml用不了，我就画图软件手画了，状态转移比较简单）：
【PS：这里的STILL是广义静止，包括 到达某请求目标楼层而导致的静止（可能马上又要移动），及，没有请求而导致的电梯空闲静止】
整理总结一个学期所学所练
关于四个单元模块
- 知识点循序渐进，从基础思想到设计原则，抽象层次越来越高，从代码完成到测试和验证，一步步完整实现工程开发。
- 老师并没有讲语法，毕竟大家都有其它语言的基础，因此语法方面全靠大家自学。
- OO开课前，由于我既没选大一下的java课，也没选暑期java先修课，心里有点虚，于是暑假用两周时间，看了中国大学MOOC浙大翁恺老师开设的：《面向对象程序设计——Java语言》，翁老师讲得真心好，特别是结合了实例，让我对面向对象的基本思想有了比较深入的了解，为本学期的OO课奠定了很好的基础，在这里种草一下。
梳理历次作业的收获和进步
阐述自己对工程化开发的理解
- 百度了下软件工程的开发过程：需求分析、设计（总体）、实现（细节）、测试、验收、维护。
- 工程化的一套流程，使得开发一个复杂易变的大工程这事儿 更加流程明确和高效，真是妙啊。
- 不过OO课只是给我们打开了软件工程的一扇小窗，让我们在一轮又一轮作业中强化体会前四个环节。特别是设计和实现分离，设计好了，实现也就是解决一些小细节而已，要是没设计好就急忙动手，那必然是内心空虚的蜗牛式前进。
- 顺带一提，每次作业都要静下心来认真分析指导书的需求，以后每次做一些很长很复杂的题、或者遇到复杂的实际情况时，就会告诉自己“指导书你都看过那么多了，还对付不了这个吗！”，以增加自己的耐心和自信心，这一点可以说是OO课给我的最大收获了【没事多逼逼自己，如果决定要翻过这面墙，就先把电脑丢过去】
对课程的期望或建议
- 一个不良现象：由于客服群分散为3、4个，因此可能会出现各客服群对同一问题的回答不统一的问题，进而出现 误导学生直至提交作业后在互测时才发现回答不统一，或，误导学生且在未提交作业前突然发现口径不一然后天降需求。这不是学生或助教的错，而是这个问答机制不大完善。用客服助教来模拟用户，结果却发现用户使用了分身术提出不同的需求，这显然不是课程组希望看到的。
- 针对上述不良现象的几个可能的解决方法：
客服群之外再建一个群 专门发通知 不允许发问，但是这就需要每个小客服群在回答每个问题之后就发通知，助教除了要回答问题，还要把问题描述清楚（当然截图也海星）之后发通知，还要注意有没有其他助教已经发过这个问题的通知。助教比较累。
建一个大群，舍弃小群，不允许水群比如发表情包和其它与OO无关的东西。要求提问和解答的内容都尽量控制在一段话内，不要分开发多条消息，想清楚了理好逻辑了再问/再答，每个时间段固定由某位助教回答，重复提问者给予黄牌警告（大家共同监控）。这样能减少水群信息，方便你我他。不过对于提问者和问答者的要求较高，大家不一定能做到，不易实施。
大就大到极端，舍弃群聊，只保留讨论区，这样会减少很多提问的次数，因为大家似乎不大愿意在讨论区发问，进而，按照大家“不提问就不会改需求”的逻辑，改需求这事儿就会变少，顺便要求ddl前一天不允许提问好了，以免天降需求呵呵。
小就小到极端，分成7、8个小群（绝对不能按小班分），保证群内人员互测。对于关键问题的回答，由助教保证与其它助教的回答统一，不关键问题的回答，助教自由发挥，互测时以助教回答为准，该助教负责这个小群内的同学的仲裁工作。但是，或许容易发生私下交易，而且如果指导书的部分需求很不明确时，同学们会大量发问，而且和其它群的同学的问题相似，助教工作较多。
【哇，设计好一门课真是不容易】
- 然后就是互测的问题了，建议在互测仲裁中加入扣分机制。即，仲裁结果分为：
确有其事，报告bug/imcomplete成功，测试者得到测试的加分。
- 双方观点都挺有道理，报告bug/imcomplete成功/失败/和棋。
- 测试者恶意测试，报告bug/imcomplete失败，测试者扣分。
- 最后，希望这门课能越办越好，达到课程组真正的教学目标，同时也得到学生们的认可：
——“这门课虽然虐人，但是学到了好多好东西，被虐得挺值的嘿嘿嘿”。