高等软工需求分析阶段总结

       如果选一句话来形容自己项目需求分析阶段的感受，我选“剪不断，理还乱”。

       前言

       我们小组选的项目是“轨道信号灯控制系统”，好像从选定题目以来，已经习惯了和同组的朋友们每周进行一次或两次针对需求分析的线下讨论，每次讨论时长至少要3~4个小时。我记得有一次周末是早上9点半开始讨论需求分析中涉及的一些模型，到下午接近两点才结束，结束的原因并不是得到了理想的结果，而是大家太饿了。项目的难度和复杂度是选择题目的时候没有想到的。最开始我们考虑，轨道信号灯的控制过程应该不是太难，只需要根据相邻的三个区间内列车的行驶信息更改信号灯显示状态，给出红灯、黄灯或绿灯的信号即可，而后列车驾驶员会根据信号灯的显示，做出停车、减速行驶或正常行驶的操作。后来发现，这种控制逻辑是没错的，但这不是需求分析，控制逻辑也不是系统。针对系统进行需求分析，我们除了需要考虑简单的控制逻辑外，还需要考虑系统涉及哪些硬件、软件，与外界存在哪些交互，存在哪些业务场景，以及如何进行安全性分析和故障的处理。这些问题是我们之前没有考虑的，也因此在需求分析阶段遇到不少问题。

     需求建模

      因为之前并没有了解过轨道信号灯的控制，所以在需求分析的最开始阶段，我们小组整体性的去了解了一下当前铁路轨道上信号灯以及列车的控制方案。通过网上搜集资料可以对系统的整体内容有一个初步了解，不过对于一些细节问题，例如车站正线与侧线的区分，侧线能否通车，信号灯的三显示与四显示优劣，是否有必要设置预告信号灯等问题，并没有找到较为详细的资料。俗话说专业的事情要找专业的人，我们小组刚好有位学长认识一位高铁驾驶员，我们小组通过打电话的方式同这位高铁驾驶员一起确认了系统控制的一些细节。在整体性的了解了轨道信号灯控制之后，我们正式的进行了系统需求的分析与建模。

       现在回想建模的过程，有点像文学家完成一篇诗歌的过程。总结起来，就是需要知识积累+不停的修改+灵感。首先来说知识积累，我们在建模的最开始对UML模型的了解是不够的。但是如果系统的对UML知识进行学习时间肯定是不允许的，所以我们只能用到哪种图，就去学习哪种图，参照网上的一些博客以及实例去完成我们系统所需的模型。再来说一下不停的修改。我感觉我们小组在需求答辩时展示的模型与初始版本相比，几乎每个地方都进行了修改，而且很多是“伤筋动骨”的改动。就比如以系统的整体架构为例，我们最开始是设计了两层的系统架构，各个区间的有自己的子控制系统，整个线路有一个总的控制系统。后面在小组讨论的过程中，考虑到总的控制系统要完成的功能其实和列控系统差不多，而我们可以将子系统的控制权直接交给列控系统，就没必要再增设总控制系统。所以我们又将系统的结构改为了一级的，只包含各区间的子控制系统，相邻区间控制系统可以通信，列控可以对区间控制系统进行宏观的调控。而在需求预答辩的过程中，根据老师的意见，列控是一个外部系统，我们不应该把太多的控制权交给列控。所以我们考虑将系统恢复到二级结构，但是在小组讨论的过程中考虑到如果一个总的控制系统控制太多子系统，会导致数据量和计算量偏大，所以我们又增设了站间控制系统，包含两个车站之间的所有区间。这样最终确定了系统的结构是轨道信号灯控制系统——站间信号灯控制系统——区间信号灯控制系统这样的三级结构。另外我们最开始在用例图中罗列了太多的功能模块，没有考虑到用例是否是Actor调用了的系统功能，或者是系统与Actor存在交互的功能模块，并且用例命名不够准确，后面也是几乎重新画了系统用例图。再如类图，最开始的类图中没有体现区间的概念，没有故障检测所需的传感器，系统的控制没形成闭环，后面我们也是对这些问题进行了修改。类图中有一个实体是信号灯，我们最开始没有将信号灯分为通过信号灯、入站信号灯和出站信号灯这些子类，后面再讨论时决定增加这三个子类，用于体现信号灯的不同类型。但是在需求答辩前，我们又考虑，这三种信号灯只是放置的位置不同，其属性和操作并没有区别，没必要以信号灯三个子类的形式展现出来。所以最后我们还是删除了这三个信号灯子类，而在信号灯这一实体中增加了位置属性，用于标识不同位置的信号灯。不停的修改的过程是比较磨人心态的，特别是“增加——删除——再增加——再删除”这样的过程，会让人感觉到自己是在做无用功。而且虽然是不停的再修改，我们仍无法得到一个每个人都认可的理想的模型。不过我觉得在这样不断修改的过程中，我们对系统的认知越来越清晰，而且虽然没得到最好的需求模型，但我们的模型在不断的变好。最后说一下灵感，我们小组在建模过程中遇到过很多的问题，很多时候问题的解决方案就是在大家讨论和交流过程中突然产生的。例如我们之前遇到一个问题，如何在类图中体现出“站间包含一个车站和多个区间”这一信息。我们讨论了很多方案，例如区间控制系统分为两类：行车区间控制系统和车站控制系统，但因为车站控制系统和行车区间控制系统在功能上并没有很大区别，将车站控制系统单独表示出来会使类图的看起来比较混乱。而如果不单独表示车站，又无法体现一个站间只包含一个车站这一信息。最后，我们是在小组讨论过程中突然想到，区间控制系统是一个类，而区间是另外一个类。区间控制系统类是指包含传感器、信号灯、故障处理单元、计算单元等软、硬件的一个系统，而区间类则是表示固定长度的某一段物理线路。在控制系统类中不好体现站间与车站和区间的对应关系，那我们可以在代表物理线路的类中去体现该对应关系。有时候，问题的解决真的就像文学的创作一样，需要一些灵感。

总结

      最后总结一下需求建模过程，虽然遇到的苦难很多，但是真正的学到了很多东西，很有收获。