一款聚会协同决策软件系统的设计
2019-04-26何胜辉
文/何胜辉
近年来,笔者在参与一些稍具规模的群体性活动(如大学同学毕业十周年聚会、单位组织的登山、羽毛球比赛等)时,经常发生因相关信息不完全且组织者和参与者无法进行有效沟通而最终导致原本可以顺利进行且让各方面都满意的聚会活动变得要么办的不尽如人意,要么流产的情况,令人深以为憾。有感于此,经过反复思考,设计出一个供聚会时使用的活动信息发布共享、组织者和参与者相互沟通并协同决策的系统,以期为人们组织活动提供便利。
1 系统总体需求
设计一个聚会协同决策系统,该系统的每个用户都可发起活动和设定活动各项信息,系统需为其他用户提供参与活动的入口。在一个活动里,每个参与者的选择情况都应实时显示给活动内其他用户,每个参与者在发起人限定的时间范围内都可对原先的选择进行调整,调整结果也要实时显示给其他会话内用户。发起人可根据情况需要在一定时限内随时对自己之前设定的活动信息进行调整,发起人可对该活动参与者做出选择的时间予以限制并随时调整该限制,发起人可以对该活动的参与者进行各种管理;系统为所有用户提供发送消息相互沟通的功能;系统设置评价机制,为用户提供通过具体的活动进行相互评价的功能;系统还应考虑一定的隐私保护。
2 功能结构设计
2.1 发起活动
图2
用于创建一个活动。需要设定活动标题、活动详情、活动图片(上传活动参考图片,非必填,为保证上传和显示效果,需对图片大小长宽进行控制)、报名截止时间、决策截止时间(报名截至时间要晚于当前时间,决策截止时间要晚于报名截止时间)、是否公开(选择公开或者匿名,决定活动是否在活动列表显示)、人数限定、活动起始时间(活动起始时间要迟于决策截止时间)、活动类型(分为“选项”、“方案”两种)等信息。
如选择活动类型为“选项”,则需进一步添加若干条选项的标题、选项内容(一般为多条)、是否单选(若是为单选,否则为多选)等信息。
表1
如选择活动类型为“方案”,则需进一步添加若干条方案的标题、详情、开始时间、结束时间、活动地点、是否单选(若是为单选,否则为多选)等相关信息。
“选项”和“方案”的区别在于“选项”可以相对自由的组合各种条件供用户选择,而“方案”格式相对规范,但也基本包含了要发起一个活动需要让潜在的参与者所了解的各种信息。
2.2 活动列表
对系统内各位用户发起生成的活动进行列表展示,针对不同活动的活动状态,展示方式也会有所区别:还没有开始的活动高亮显示、已经过期的活动就暗灰色。另外,活动列表还需要提供筛查、排序功能,可以方便用户通过活动主题、参与人等关键字进行活动查询,以是否过期等状态信息进行筛选,或根据发起时间、报名截止时间等条件进行排序。
2.3 活动管理
2.3.1 我发起的
作为一个活动的发起人拥有对该活动的全部管理权限,可以取消、决策该活动,修改、删除该活动全部信息,对参与该活动的成员进行管理(踢人、设置或取消该活动管理者)和发送系统内消息。
2.3.2 我管理的
一个活动的参与者在被该活动发起人授予该活动管理者权限后,就具备了决策该活动,修改该活动全部信息,对参与该活动的成员进行管理(踢人)和发送系统内消息的权力,但他不能取消该活动,也不能踢该活动的发起人和其他该活动的管理者或取消该活动的管理者。
2.3.3 我参与的
作为一个活动的参与者,可以参与选择各“选项”和“方案”,供活动组织者决策。还可以接受各种消息,并给其他该活动参与者发系统内消息。
2.4 评价管理
评价是针对具体活动的,且是双向的。因为每个用户即可能是一个活动的发起人也可能是一个活动的参与者,当他是一个活动的参与者时,他就给发起他参与的活动的用户评价;反之,如果她发起了一个活动,那他就接受其他参与了他发起的活动的参与者对他的评价。
评价从两个维度出发,一是人品,另一个是能力。一个用户发起一个活动后,其他参与者对他进行评价,既要看他是否组织好了这个活动(能力)也要考量他是否认认真真的用心在办这个活动(人品)。如图2所示。
图3
图4
2.5 消息中心
消息中心分为“我发出的”和“我收到的”,其中“我收到的”包括来自系统(活动临近报名截止时间或决策截止时间的提醒、踢人提醒、活动内容修改提醒等)和来自他人,消息要能够关联到具体的活动(每个用户都是在进入一个活动后才能够有对该活动的其他参与者发消息的接口)。一条消息包括题目、内容 、发送时间和所属活动等相关信息。如图2所示。
2.6 系统结构流程图
如图3所示。
3 数据结构设计
3.1 E-R图
如图4所示。
3.2 数据字典
如表1所示。
4 小结
一个软件是否有价值,必须要投入实用并接受用户的检验。目前该软件已经完成了系统设计工作,并在圈子内的朋友们共同努力下开发出了基于微信公众号技术的测试版本。在内部测试过程中,发现了不少问题,还需要进一步的改进和优化。笔者力争早日完善该系统,使其尽快正式上线,为大家提供服务。