设计也可以按图索骥--设计建模总结与感悟

设计也可以按图索骥--设计建模总结与感悟设计建模博客

  高等软工课程渐渐进入尾声，在需求分析之后，就马不停蹄的对项目进行了设计建模工作的推进，此次设计建模的工作十分繁琐，且可以说耗费我们极大的精力去处理细节，但结果似乎还是有些欠缺。

设计建模进展

  想更好的完成设计建模，就需要了解设计建模的目标以及其开展流程。显然，最初我们并没有很好的认识到设计建模应该达到的效果，所以只是依葫芦画瓢的去画几张活动图与状态图，以及对我们的类进行OCL约束编辑，不能否认我们当时对这部分工作的付出，但现在想来，当时似乎做的无用功更为多一些。问题就在于，我们不清楚为什么要去画这些图，又是需要体现什么内容。幸好在前期汇报中，老师针对我们的工作给出了建议，他认为我们没有站在系统的角度去考虑问题，只是单纯的对单一场景给出设定，这使得我们的系统看起来有一种割裂感，无法很好体现与展示我们系统的完善性，令人怀疑系统设计是否可行。可以说，当时听到老师给的意见，就立刻意识到我们似乎走错了方向。于是，之后我们很快就开启了小组会议，讨论我们在设计建模阶段，需要干些什么，需要展示什么，我们开始主动去规划我们需要做的事情，而不是单纯完成老师给出的问题解决方案。
  现在看来，当时讨论结果算是比较合适的。我们当时得到的结论是首先设计建模阶段需要展现出我们系统的整体考虑，以及去验证我们系统能够正确的运行以及最重要的是安全的运行。基于这些考虑，我们的任务就比较清晰了。系统的整体架构这个问题，其实在之前已经提过一些，但并未真正的给出规范接口，模块化等，那么我们设计建模要做的就是将系统的三级架构，每级包含的模块以及需要实现功能给出更加完善以及规范的描述；之后是系统能正常运行，我们考虑两个方面的设计，第一个是分布式的架构如何统筹规划，协调处理好并发的事件，资源的合理分配以及事件比较合理的响应顺序等。这个解决方案，我们借鉴了操作系统的事务优先级排队处理，以及中断抢占的思想，并对我们系统中可能出现的事件根据紧急程度，规定了不同事件的优先级。第二点是，列车如何能够在我们系统中保持连续的正常行驶；这点我们利用了数学归纳法的思想，展示在起点站以及终点站两个特殊结点如何控制列车的行驶，然后在普通的区间中，列车如何不断的跨越区间，这三个联合起来，就能很好说明我们列车在整体系统的一个运行过程。最后一个问题，就是安全性的保障，关于这个我们讨论了很长时间，因为一方面是由于我们对专业领域知识的缺乏，另一个也是对于我们系统会发生哪些故障，如何解决没有一个明确的定义。多亏我的队友，提出了故障树的方法，我们才能系统的对故障类别进行划分，并且写出一个比较完善的故障等级表，针对不同的故障等级，我们决定是否去闭塞区间，亦或者仅仅只是记录下来，之后去响应等等。

设计建模存在的问题

  但是，我们还是忽略了一个很重要的问题，上述设计的实现是需要与之前的类图进行对照的。这个问题，直到设计建模答辩的时候，我们才意识到，我们的设计建模纵然细节很多，但其实与之前的联系似乎不大，并且忽略了最重要的一个点，就是设计的最终落地实现应该是类中的一个方法，如此才能说明我们的设计不是空中楼阁。这个问题，也正好解决了当时我们的疑惑，我们的需求分析对设计建模的影响似乎没有想象中的大。只有将需求分析与设计建模连贯起来，我们的设计才真的是一个完整的设计。完整的设计能够让代码工程师，通过类图以及各种参考直接看出代码的实现。我似乎有点理解当时学习软工时候，为啥老师说其实项目真正编写代码时间不多，大多时候是在开会，写文档了。当完整设计真的敲定后，那代码其实不过是按图索骥。第二个问题，是我们缺乏整体系统的故障分析的考量，我们需要设定两到三个故障场景，去分析我们的系统能否在当前设计中，迅速且正确的处理故障，保证列车的行驶。

总结与体会

  如果说初期的需求分析是打地基的过程，需求分析越详细越完整，之后才能起高楼而不会塌掉；那么，设计建模阶段就类似于建筑结构的图纸，规范的建筑图纸，不能有任何丝毫的偏差，才能保证最后按照图纸盖出可靠的建筑，如果但凡建筑图纸失之毫厘，那导致的将是真正的建筑谬以千里。设计建模阶段，无论如何规范细节都不过分，唯一的问题就是考虑的似乎还不够全面，不够精细。之后，起高楼就是按照图纸去码代码（搬砖人似乎很应景呵呵）。
  此次设计建模的成果值得肯定，但还需要进一步的完善，将实现真正的与类图联系起来。可以说，虽然我们这个项目不需要代码实现，但我觉得我们完整做下来，完成的工作量也接近75%，只是少了代码实现与代码测试的阶段。