设计也可以按图索骥

引言

我们小组的题目是社区疫情防控追踪系统，经过前面的领域分析和需求分析我们小组对整个的一些系统都进行了详细的讨论。但还是存在一些问题。本文旨在对设计阶段的工作进行总结，并对出现的问题进行分析，以求进步。

 

设计建模

设计建模的意义就在于回答这个软件是怎么做的。正如这次作业的标题所述——设计也可以按图索骥。设计，就是要让任何一个不熟悉相关领域的开发者都可以根据设计建模的文档开发出符合要求的系统或软件。这也是我们进行设计建模的目标。

这次的小组作业中，我主要负责的是OCL约束部分的撰写。这是之前我没有接触过的，OCL对象约束语言，它可以表达UML类图中值的约束，还能够用来对UML图中的任何元素写表达式，也可以指出系统中的一个值或者对象。是一门值得仔细研究的语言。通过这次小组任务，又收获了新知识~

 

在上周的答辩中，老师指出的一个问题是当我们接收到信息健康码变化的时候系统如何决策？我们如何根据这些变化来进行疫情的一个防控。也就是变化规则的一些细则这些，在我们的展示中没有体现出来。目前我们所实现的系统更像是一个单纯的疫情填报系统，防和控体现得没有那么明显。这个问题，我们也会进行小组讨论，争取在最终的验收中，展现出令人满意的成果。

同时，还指出我们设计的一些东西，在设计建模的产出中看不出来。这确实是一个很严肃的问题，因为作为软件开发人员之一（总共两人，分别负责前端后端），我们是参照需求文档+设计文档开发的，在开发中一些模糊性的细节上，可能会结合两个文档，再靠自己发挥一部分…然后展示时所讲述的又是参照的我们实际实现的设计来谈的，所以就出现了口中的设计与文档中的设计不符的问题。这是不太规范的一件事，违背了按图索骥的原则。后续我们会对设计文档进行完善，尽可能的完善文档，消除个人发挥，将所有的设计与实现一一对应。

在接口设计这部分，我认为我们的文档还有很大的欠缺之处。作为前端开发人员，真正写前端的时间不到20%，剩下的时间都用在了和后端的队友沟(zhe)通(sha)交(wan)流(yi)（抓狂.jpg）…这种问题的出现就在于接口文档的匮乏，不是“按图索骥”了，而是“盲人摸象”。这是我对文档的重要性理解最深的一次…

 

结语

软件工程中的设计，是一个按图索骥的过程。与工程中的具体实现无关，而是完成从模型层面的设计。软件工程作为一门经验性的学科，前人留传下来的经验是有意义的，一份完善的设计文档，可以极大的降低实现过程中可能出现的问题，提高工作效率。至于对不同的工程需求，模型如何设计能达到效果最优，还有很长的探索之路值得我们去走。