第八次作业（课堂实战）- 项目UML设计

本次作业博客

团队信息

• 队名：起床一起肝活队
• 原组长：
  白晨曦(101)
  • 原组员：
    李麒 (123)
    陈德斌(104)
    何裕捷(214)
    黄培鑫(217)
    王焕仁(233)
    林志华(128)
    乐忠豪(121)
    蔡子阳(102)
• 临时组长：
  何裕捷（214）
  • 组员：
    李麒(123)
    陈德斌(104)
    黄培鑫(217)
    王焕仁(233)
    高裕翔(212)
    胡青元(081600410)
    蔡子阳(102)

---

alpha版本

模块序号	模块名	模块具体内容
1	登陆注册模块	用户的登陆与注册
2	个人信息模块	用户的个人信息
3	累计反馈模块	用户世界树的更新成长以及实时天气温度等信息
4	计划模块	以日历形式显示用户制定的计划，分个人和团队
5	闹钟模块	设置关联闹钟，优先级以及提醒方式

成员分工明细以及TODO-list

负责人	分工明细	TODO-list
白晨曦	1.规划项目进程；2.组织会议、分配任务；3.负责UI设计；4.参与文档拟写	完成各个界面的UI设计稿
陈德斌	辅助项目原型的逻辑功能设计	协同同何裕捷完成项目原型逻辑功能设计
林志华	1.负责前端的开发；2.辅助pm进行项目规划	个人信息模块前端开发
何裕捷	负责项目原型的逻辑功能设计	完成项目原型逻辑功能设计
黄培鑫	负责前端的设计、开发	完成登陆注册模块前端开发
蔡子阳	负责网络接口	完成网络接口的设计与开发
李麒	1.负责后台的设计、搭建；2.主要功能程序编写	完成后台构建以及累计反馈模块的实现
乐忠豪	1.辅助后台的设计、搭建；2.搭建数据库	闹钟模块的实现，搭建数据库
王焕仁	1.辅助后台的设计、搭建；2.辅助主要功能编写	计划模块的实现

燃尽图

---

UML

用例图

描述的部分：

• 这里是用户个人管理系统的用例图

面临的问题：

• 面临用户登录注册和个人信息处理等基本问题

解决的问题：

• 尽可能符合用户的使用习惯，使用户用起来方便

附图：

描述的部分：

• 这里是用户团队管理部分的用例图

面临的问题：

• 这部分面临用户管理团队的问题，包括创建团队，解散团队，加入团队，退出团队，添加成员，踢出成员

解决的问题：

• 罗列了团队管理的基本逻辑，让用户更方便地管理自己的团队

附图：

描述的部分：

• 这里是用户计划管理部分的用例图

面临的问题：

• 这部分面临用户管理计划的问题，包括删除计划，添加计划和查看计划

解决的问题：

• 罗列了计划管理的基本逻辑，让用户更方便地管理自己的计划

附图：

描述的部分：

• 这里是用户闹钟管理部分的用例图

面临的问题：

• 这部分面临用户管理闹钟的问题，包括删除闹钟，添加闹钟和查看闹钟

解决的问题：

• 罗列了闹钟管理的基本逻辑，让用户更方便地管理自己的闹钟

附图：

描述的部分：

• 这里是用户成长反馈部分的用例图

面临的问题：

• 这部分面临用户成长反馈的问题

解决的问题：

• 罗列了成长反馈的基本逻辑

附图：

类图

描述的部分：

• 用户与闹钟，团队，计划，累计反馈的关系

面临的问题：

• 各种类的关系复杂

解决的问题：

• 明确了各类的关系

附图：

活动图

描述的部分：

• 1 用户的团队管理部分。
• 2 用户闹钟制定的部分。
• 3 用户计划制定的部分。

面临的问题：

• 1 对软件不熟悉，进度缓慢，效率低。
• 2 缺少交流，没有统一好整个流程的实现。

解决的问题：

• 1 对要开发软件的整体结构更加了解。
• 2 更加清晰用户使用软件的整个流程

附图：

状态图

描述的部分：

• 用户的注册登录部分。

面临的问题：

• 账户的管理问题。

解决的问题：

• 解决用户的注册登录问题。

附图：
]
描述的部分：

• 关联计划部分。

面临的问题：

• 关联计划有什么作用。

解决的问题：

• 用户可以创建计划、查看计划、修改计划。

附图：

描述的部分：

• 用户关联闹钟管理的部分。

面临的问题：

• 关联闹钟的管理问题。

解决的问题：

• 用户可以对关联闹钟创建、删除、修改。

附图：

描述的部分：

• 关联闹钟的叫醒部分。

面临的问题：

• 关联闹钟如何叫醒用户。

解决的问题：

• 用户通过完成任务、成员一键呼叫来起床，用户起床后或无法被联系才解除闹钟。

附图：

描述的部分：

• 累积反馈部分。

面临的问题：

• 累积反馈的过程如何。

解决的问题：

• 完成任务后成果增加，超过时间未完成任务则成果减少，可以查看自己的成果。

附图：

实体关系图

描述的部分：
这里是软件所拥有的实体以及它们之间的关系

面临的问题：
如何清晰地展示我们软件的一个实体属性以及之间的关系。

解决的问题：
能让用户和程序员更清晰地了解到软件的构成。

附图：

---

构件图

描述的部分：

• 1 用户界面
• 2 计划管理
• 3 成长反馈
• 4 团队关联

面临的问题：
如何描述接口和系统功能

解决的问题：
在有交互的界面标注接口，系统功能分为直接调度和程序调用

附图：

对象图

描述的部分：

• 描述对象与类之间的关系

面临的问题：

• 对软件不熟悉以及需要等待类图

解决的问题：

• 明确了对象与类的关系

附图：

序列图

描述的部分：

• 1 总体而言，是对象之间的沟通方法，描述运行时的交互关系。
• 2 流程而言，创建一个群组，并进行发布（关联闹钟|关联计划）的过程。
• 3 具体而言，是在一次正常工作情况中，进行的用户，系统，数据库之间的数据交路的过程与方法。

面临的问题：

• 1 如何建立正确的模块调用关系。
• 2 如何处理好大量用户情况下的调用。

解决的问题：

• 1 让模块调用顺序化，具体化。
• 2 让系统能成功调用模块和功能。

附图：

部署图

描述的部分：

• 描述用户，客户端，数据库的关系

面临的问题：

• 系统如何部署

解决的问题：

• 更好的体现了各个硬件的宏观关系

附图：

---

工具选择

• 工具：StarUML
• 评价：
  1.优点：针对性强，容易上手，使用便利，转出方便。
  2.缺点：相比其他在线工具需下载安装才能使用，功能的友好度方面缺少团队协作功能和自动保存功能。

---

PSP表格

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	180	190
· Estimate	· 估计这个任务需要多少时间	5	5
Development	开发	90	120
· Analysis	· 需求分析 (包括学习新技术)	60	60
· Design Spec	· 生成设计文档	30	60
· Design Review	· 设计复审 (和同事审核设计文档)	0	0
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	0	0
· Design	· 具体设计	0	0
· Coding	· 具体编码	0	0
· Code Review	· 代码复审	0	0
· Test	· 测试（自我测试，修改代码，提交修改）	0	0
Reporting	报告	80	80
· Test Report	· 测试报告	0	0
· Size Measurement	· 计算工作量	20	20
· Postmortem & Process Improvement Plan	· 事后总结, 并提出过程改进计划	60	60
合计		350	390

---

个人贡献

• 课上贡献分评估

短学号	姓名	此次作业任务	贡献分配	备注
214	何裕捷	用例图	13.5%	临时队长
123	李麒	对象图；写博客	13%
104	陈德斌	实体关系图	12.5%
217	黄培鑫	状态图	12.5%
233	王焕仁	活动图	12%
212	高裕翔	构件图	11%
081600410	胡青元	顺序图	12.5 %
102	蔡子阳	类图；部署图	13%

• 课后贡献分评估

短学号	姓名	此次作业任务	贡献分配	备注
101	白晨曦	组织	5%	原组长
214	何裕捷	用例图	15%	临时队长
123	李麒	对象图；写博客	16%
104	陈德斌	实体关系图	13%
217	黄培鑫	状态图	13%
233	王焕仁	活动图	12%
102	蔡子阳	类图；部署图；alpha版本分工；燃尽图	22%
128	林志华	完善构图	2 %
121	乐忠豪	完善构图	2%

---

换队环节感受

感觉大家适应性都很强，都能迅速定位好自己。临时队长也能很好的承担起队长的责任，新队友能够迅速了解我们团队项目并进行图的制作以及辅助其他队友。新团队氛围很好，大家积极性都很高，斗志昂扬。