设计也可以按图索骥

引言

　　本人所在的小组题目是“社区疫情防控追踪系统”，本文是对设计阶段工作的总结。在本阶段，我们完成了详细设计文档的撰写，并进行了答辩。本人承担了部分用例的具体叙述工作，制作了答辩ppt并代表小组进行了汇报。本文旨在对本阶段的工作进行总结。 

工作总结

　　按时间顺序，我们的工作包括以下几点：

　　阅读学习往年学长组的详细设计文档，构思文档的大体结构，将详细设计文档划分为系统概述、系统架构、系统组件、系统实体、系统类、详细用例描述、OCL约束、开发计划。具体内容如下：

（1）       系统概述：同需求文档类似，需对之前老师提出的问题进行修改完善。

（2）       系统架构：包括系统架构图，从简端、后端、底层存储的角度描述系统。

（3）       系统组件：包括系统组件图，从组件的逻辑关系描述系统。

（4）       系统实体：包括E-R图，从数据库的角度描述系统的实体及属性。

（5）       详细用例描述：对于每个用例，包括设计类图和顺序图，与需求文档不同，需具体到工程实现的逻辑与方法。

（6）       OCL约束：对象约束语言作为图形符号的补充，说明建模元素的有关细节。

（7）       开发设计计划：说明从项目设计到最终实现的时间内容安排。

　　针对需求答辩阶段老师提出的问题，对项目需求进行修改。需求答辩老师提出的问题主要有以下几点：

（1）       防控粒度过大的问题：之前系统防控级别以社区为单位，但一个社区有多栋居民楼，若某个楼的居民确诊，该楼栋居民的管控措施应与其它楼栋有所区别。针对此问题，我们对防控粒度进行修改，细化到楼，居民出入楼栋时需进行打卡。

（2）       防控信息流不明确的问题：之前系统设有“每日信息填报”、“其它社区或政府信息导入”的功能。但是对于本社会异常情况出现时，如何进行应急处理，将消息传播到其它社区，以及如何迅速控制异常人员，系统没有进行明确。针对此问题，我们增加了第三方系统的假设，每日各社区系统会定时将数据传送给第三方中间系统，中间系统进行解析，将消息实时分发给其它社会系统。通过这样的模式解决了消息流传递的问题。

（3）       防控逻辑过于简单的问题：之前疫情防控工作是以社区为单位的，即确诊患者不会对没有进入过的社区、居民产生实质性影响。本阶段我们通过增加“相邻社区”、“同一个人进入多个社区”的概念，实现了对与确诊患者接触概率较大的潜在接触者的管控逻辑。

　　同步进行文档撰写和前后端开发。本阶段本人没有参与开发，进行了注册、每日健康打卡、接受第三方消息、用户进出社区填报用例的文档撰写工作，包括对应的类图和顺序图。

　　制作答辩ppt准备答辩。本阶段本人承担了相应的工作，主要对其它成员的成果进行了学习与提炼，以加深对项目整体的理解。

老师提出的问题

　　答辩时，老师提出我们的防控逻辑仍然过于简单，虽然相对需求阶段防控逻辑已经有所细化，但是目前若一个小区出现确诊病例，我们只是笼统地按照“有过同楼栋打卡记录的居民”、“同一小区未有过同楼栋打卡记录的居民”、“相邻小区的其它居民”的层次进行相应的管控。没有考虑到“与确诊患者虽然有过同一楼栋打卡记录，但是出入楼栋时间没有重叠段”、“与确诊患者不是相邻社区，但可能由于交通工作的原因，轨迹有重叠”的情况。在下一阶段，我们将针对这个问题对防控规则进行进一步的细化完善。

心得与感悟

　　本次设计阶段由于本人承担了汇报工作，因此对整个系统有了更加深入的理解，从设计到实现，从逻辑到架构，学习到的东西是十分宝贵的。通过学习实现同学Springboot代码，对MVC架构有了新的认识。在撰写文档阶段，学习了设计类图和顺序图如何进行绘制，对于复杂的逻辑函数，重点在图上应该突出什么。通过和老师的汇报，锻炼了语言表述能力。最后，感谢聆听我们答辩的各位老师、团队组长、团队的其它同学这段时间辛苦的付出。