设计也可以按图索骥

设计也可以按图索骥

设计建模

我们组的题目是信号灯控制系统。按设计建模阶段完成的工作来讲，我们做了许多事情，完成了OCL约束的设置，细化了类图，对故障进行了详细的分析，并给了相应的措施等等。但是好像并没有理解设计建模到底要干什么。我们小组也经常讨论，频率不算低，大约一周两三次的样子，但讨论的方式大抵是针对问题，解决问题的方式来完成的，也并不涉及我们在设计建模建模阶段到底应该完成什么内容，达到什么目的的讨论，只是在尝试完善我们的系统，使它看起来更加合理。在设计建模正式答辩之前的答辩，老师给我们提出了不少的建议，指出许多问题，告诉我们应该从系统整体去考虑，而不是着眼于底层级的系统应该有哪些方法，有哪些属性这样细节的事情。根据这样保姆般的建议，我们才去详细设计了我们系统处理事件的逻辑，优先级，针对性的处理可能遇到的故障。这之后我们的小组讨论根据老师的建议主动分析了一下，并顺着这种分布式系统，从系统整体的级别去考虑问题的思路讨论了一下我们应该如何完善我们的项目，使得我们的项目尽可能成为一个能够真正使用的信号的系统。在听了老师的建议之后，回过头来想设计建模到底应该干什么。（其实是在看了老师上次给我博客的留言，大意是对于故障，需求分析时应该做到对故障的识别，而设计建模的时候就应该针对各种故障提出有针对性的解决方案。）我的理解就是应该针对需求分析中分析的核心业务，安全性需求，进行合理的详尽的设计，使得系统至少能够达到看起来是个可靠能正确运行的系统的标准。对于这个设计，虽然我还说不清楚到底应该怎样设计，怎么才可以按图索骥的设计，但是我感觉这个合理详尽的设计，需要对系统的核心业务，最重要的问题有仔细的考虑，做出有针对性的解决办法，这个别出心裁的解决办法，应该就算是设计了吧。

关于小组讨论

我们组是经常讨论的，通常我们会在星期六的早上，星期一的早上和星期三的下午进行面对面的讨论，大概率是在天行咖啡馆或者是共享空间中进行，偶尔会在新主楼的二楼。我很喜欢这种讨论的氛围，我是个喜欢抬杠的人，倒也不是故意抬杠，只是习惯了抬杠。我觉得抬杠讨论能够更加有效的解决问题。有时候我们只是想到一个点子，说了出来，抬杠能够让你更加仔细的去思考，完善这个点子。就比如我们讨论事件优先级的时候，其实有不小的分歧，小组中的李同学提出或许排队按照优先级排队，但是抢占的时候，优先级达到一定等级之后就不应该再被抢占。我们显然分成了两派，一派觉得这个点子有些许的道理，却又解释不出来。另一派则觉得，高优先级的不能抢占低优先级的，那他们其实就应该是同一个优先级。我们讨论这个问题，找出一个合理的解释，在优先级达到一定程度之后，大部分事件处理的时间都不算长，不抢占可能会让效率更高。因为抢占时需要保存现存，最后恢复中断之类的事情，这些时间林林总总的加起来或许都够完成这件事情了。所以在我们最后的设计当中，采用了排队优先级和抢占优先级分开的机制。在这种大家都比较有意见（思考）的问题上，我们似乎都完成的不错。集思广益，三个臭皮匠顶一个诸葛亮这些话终归还是有一点道理的。

总结

在设计建模的过程中，我们花费了相当多的精力，但是没有取得设计的精髓，在老师第一次仔细点评过后我们的设计才走上正轨。我们的设计中最具特色的，最重要的应该是我们设计的针对故障的处理，包括设置故障的优先级，故障的分级处理，处理不同故障的流程等，做到了每种故障既有独特的处理细节，又有同一级故障的处理共性（启用冗余设备，记录故障等）。然后还有一些其他的设计，包括系统的整体架构，不同层级控制系统之间的交互，系统处理并发事件的机制等等。在上次设计答辩之后，我们仍有不少可以完善的地方，如将所有的设计落实到类图中体现，希望能做到“编程人员按照我们的类图完成，就可以直接实现一个可用的系统”这样的程度；在展示方面仍然缺少各级系统，设备一起配合的示意图或者交互图。