高软课程总结

高软课程总结

回顾

这个课程总结是需要回顾这门课的第一次博客作业对这门课的期望。我当初写第一篇的时候，我是“被迫”选的这课，对课程的期望也只是能不愧对我选课时的几十权重，能学到有用的知识，上完整个课程来看，显然是值回权重的。一学期的软工课程上完，首先是学到了很多软件工程方面的基础知识，我本科是没有上过软件工程的，所以对软件工程相关的知识并不太了解。这学期通过实际完成轨道信号灯系统的设计，我们实际画了相当多的图，UML类图，时序图，状态图，活动图等等。并且通过完成这个项目的设计，我也完整的经历了一遍一个项目是如何从开始到设计完成的流程。这更像是一套思考项目的通用流程，先对问题进行了解，然后基于对问题的了解分析有些什么需求，最后再进行设计来满足这些需求。

除了知识

除了学到这些软件工程的知识，我觉得我还收获了很多。首先是老师对核心价值，核心业务的强调。老师在课上提过相当相当多次要关注核心价值，核心业务。一个项目当然应该有他自己的核心业务，对我们的项目来说是对列车安全的调度，保证列车行驶的安全性，我们一开始并没有这种核心业务的概念，导致我们花了不少时间在一些可能不是那么重要的细枝末节上的设计。关注项目的核心业务，这应该是我在这课上学到的一点意识。另外一点，也是老师提过的，大意是UML类图，这些软件工程的图，都只不过是用来表达设计的工具，重要的是设计，而不是用来表达设计的工具。这也是很重要的一点，我们组一开始确实陷入了一些‘歪门邪道’，感觉有些过于关注图怎么画，而不是关注我们是怎么设计的。在理解了这一点之后，我们组的设计才变得好了一些，不在拘泥于图的细节，而专注于怎样才能更好的表达我们所想的设计，所以才有了后来的用优先级的表格来表达对故障处理，时间调度的设计，用架构图来展示我们整个的系统结构。还有一点是，从整个系统的层面去考虑设计，这是在我们某次报告的时候，老师提出来的问题。我们的设计一开始着眼于最低一级的系统基本功能的设计，而忽略了我们的整体系统的特性，我们的系统整体来看是一个三级分布式的结构，最低一级的系统完成信号的计算，因此整体系统需要处理相当多的事务，会有事务调度，事务处理顺序的问题，同时每一级系统之间的交互，配合也是需要考虑的。

关于项目 

我们的项目是轨道信号灯系统，大致的功能是通过对信号灯显示信号的控制，来对列车的行驶进行控制，确保列车的安全行驶。我们组最终设计完成的项目，我觉得亮点有几处：故障分析和处理；事件调度；列车连续性。故障处理这一部分，是我们项目的核心业务，确保列车能够安全行驶，正常情况的调度相对容易，只要获得相邻区间的信息就可以完成控制，而对故障的识别，对各种故障的处理才是真正困难的地方。我们组采用故障树的方法对各种可能的故障进行识别，并且对他们有区分性的设置处理办法（对故障设置优先级）。我们对一些重要的设备设置冗余来处理大多数的故障，在必要时进行紧急关闭区间是我们对较为危险的故障的处理。我们还考虑了站间调度维修资源的处理模式，设置了动态故障优先级，以此来调度资源处理更为紧急且必要的故障。在事件调度这里，我们对每一级系统可能遇到的事件进行了分优先级的处理，然后根据这些事务的特点，我们设置了半抢占式的优先级，高优先级的事务在排队时一定在优先级较低的事务之前，而在处理机的分配这里，我们设置了在事务达到一定优先级之后，更高优先级的事务也不能够抢占的机制，这样确保了一些比较重要的事情也能够及时得到处理。列车连续性是指列车在行驶过程中应该能够一直在系统中有所表达，跟踪，从一个区间到下一个区间，一个站间到下一个站间，列车的信息是能够时刻获取，时刻跟踪的。为了这样的目的，我们设置了列车在一条轨道上行驶时，为了确保列车连续性我们系统需要完成的工作。

关于团队

我们团队真的很不错，大家对于线下讨论都很积极，我觉得这是我们组完成的不错的重要原因之一。尽管大家选的课都不一样，有各种各样的事情，但大家也都尽量调整时间，凑出能够一起线下讨论的时间，线下讨论还是挺必要的，我们许多的想法都是在线下讨论的时候提出的，实时面对面的交流效率很高（尽管我老抬杠）。我们的分工合作在一次次的讨论中越发熟练，我的一个体会是让专业的人干专业的事，是提高团队效率的一种方式。我们组的故障分析，总体上的设计是我们一起讨论时确定的，但更多的细节，都是我们的一个组员持续跟进的，很长一段时间他就专注于我们的故障分析，遇到了问题就在小组讨论的时候提出来，大家一起讨论，这样的合作方式我觉得是比较高效的。

另外，不谈其他的，我觉得能认识小组中的各位同学并成为朋友，是我本次课程很大的一个收获，他们真的都是人才，说话又好听，我真的超喜欢在这个组里。最后，祝老师同学们，新年快乐，假期愉快！！