18软工实践-第八次作业（课堂实战）-项目UML设计（团队）

目录

• 团队信息
• 分工选择
  • 课上分工
  • 课下分工
  • ToDolist
  • alpha版本要做的事情
  • 燃尽图
• UML
  • 用例图
  • 状态图
  • 活动图
  • 类图
  • 部署图
  • 实例图
  • 对象图
  • 时序图
  • 包图
  • 通信图
• 贡献分评定
  • 课上贡献分
  • 课下贡献分
• 工具选择
  • StarUML
  • Process on
• 使用工具感受
  • StarUML
  • ProcessOn
• PSP表格
• 换队感受

团队信息

队名 404 Note Found

队长：胡绪佩

临时队长：周政演

团队会议纪要链接

学号	姓名	博客链接
031602543	周政演	https://www.cnblogs.com/vancasola/p/9821102.html
031602510	葛家灿	https://www.cnblogs.com/dalegac/p/9823211.html
031602513	黄鸿杰	https://www.cnblogs.com/Jeho/p/9823214.html
031602627	刘恺琳	https://www.cnblogs.com/lkl-fzu/p/9821459.html
031602113	何宇恒	https://www.cnblogs.com/hyh1072797231/p/9822827.html
031602444	庄卉	https://www.cnblogs.com/ffxpy/p/9823213.html
031602525	刘一好	https://www.cnblogs.com/howtoloveyou/p/9823202.html
081600410	胡青元	https://www.cnblogs.com/waaaafool/p/9823203.html
031602114	胡绪佩	https://www.cnblogs.com/heihuifei/p/9823207.html
031602511	何家伟	https://www.cnblogs.com/Bylight/p/9823215.html
031602539	翟丹丹	http://www.cnblogs.com/breakbreak/p/9822763.html

分工选择

课上分工

课下分工

ToDolist

alpha版本要做的事情

迭代原则，由核心功能到辅助功能

燃尽图

UML

用例图

描述的部分：

• 描述了我们软件必须完成的任务，定义了必须完成的软件功能；
• 基本呈现用户与用例之间的具体关系；
• 基本表达系统的基本功能；
• 基本表达系统的具体行为。

面临的问题：

• 如何具体对用例进行分类，使得用例更加具体；
• 如何对用户与不同用例之间的关系详细分析。

解决的问题：

• 初步获取用户的需求；
• 指导测试；
• 在整个过程中对其他工作流起到指导作用。

状态图

【part1】
描述的部分：

• 描述了用户登录及未登录使用的状态。

面临的问题：

• 面临用户账号管理及云备份的问题。

解决的问题：

• 解决了用户使用云备份功能的问题。
• 解决了用户注册登录流程的问题。
• 解决了用户找回密码的问题。

附图：

【part2】
描述的部分：

• 描述了用户新建自定义备忘的状态。

面临的问题：

• 面临用户添加自定义备忘条目选填信息较多的问题。

解决的问题：

• 用户只需添加标题便可新建备忘，选填信息个性化添加。

附图：

【part3】
描述的部分：

• 描述了备忘信息的状态。

面临的问题：

• 备忘录的备忘录事项状态较多，如何分类、组织的的问题。

解决的问题：

• 用户可清晰了解备忘录事项的各种状态。

附图：

【part4】
描述的部分：

• 描述了所有备忘展示的状态。

面临的问题：

• 备忘信息分类方式不同及备忘信息展示形式比较多对于用户较复杂。

解决的问题：

• 方便用户切换查看备忘信息的分类方式，如按时间顺序与事务类型。
• 方便用户选择备忘信息展示的形式。

附图：

活动图

描述的部分

• 备忘录生成过程。
• 个性化壁纸设计。
• 用户自定义备忘录设置。

面临的问题

• 面临账户管理问题。
• 用户自定义设计问题。如何使用户获得喜爱的简洁实用的备忘录壁纸。

解决的问题

• 提供用户行为分析功能，对用户娱乐，游戏方面进行时间监控。
• 提供智能分析功能，智能读取快递信息和订单信息，将有效信息转化成备忘录。
• 提供智能提醒功能，在备忘录自定义提醒时间之前进行短信提醒，并提供天气提醒附加功能。
• 提供壁纸生成功能，用户自定义壁纸样式，字体颜色及字号，完成个性化特色壁纸设计。

附图

类图

描述的部分：

• 描述了我们软件必须完成的类、接口以及它们之间的静态结构和关系；
• 类的部分：用户、备忘录、备忘录分类夹、桌面控件、锁屏壁纸、图片、音频、备忘详情、智能分析、快递信息、订单信息、天气信息；
• 关系部分：关联、聚合、泛化；

面临的问题：

• 绘制类图软件的选择和该软件在类图绘制上的使用方法；
• 类的定义（如属性和方法）和个数比较不明确；
• 各种类之间的关系比较模糊；

解决的问题：

• 1确定使用StarUML进行类图绘制并搜索相关博客教程学习使用StarUML绘制类图；
• 2 与其他负责后端任务的组员讨论交流沟通，确定主要的类的属性、方法和个数；
• 3与组内负责前端、原型设计和其他UML图绘制的组员反复沟通；

附图：

部署图

描述的部分：

• 描述服务器内部构建
• 描述软件物理构架示意图
• 描述软件与硬件组件之间的物理关系以及处理节点

面临的问题：

• 我们无法提供24小时开机的主机，只能进行租借与托管

解决的问题：

• 解决了开发者对于物理构架的宏观理解
• 提供了科学可实现的物理框架构建

附图：

实例图

描述的部分：

• 描述用户和软件之间、软件各个部分之间的联系
• 描述软件的逻辑结构
• 描述实体与其属性的联系，是用来描述现实世界的概念模型。

面临的问题：

• 1.具体实际功能要与后端商议，进行一定修改

解决的问题：

• 1.明确了各个部分的具体功能
• 2.具体解决了数据库的设计

附图：

对象图

描述的部分：

• 软件运行中的静态时刻，描述对象之间关联的实例；
• 描述某一个应用情景；

面临的问题：

• 具体的应用情景需求；
• 数据流图的设计；
• 抽象语义的可视化描述；

解决的问题：

• 可以直观表示出系统在某一个时刻（情景）一组类的实体之间的关系；
• 通过查看某个时刻不同类之间的关系，思考归纳数据流图；
• 对系统的设计视图建模时，可以使用一组类图完整地描述抽象的语义以及它们之间的关系；

附图：

时序图

云备份

描述的部分

• 这里描述了系统的云备份部分

面临的问题

• 要面临云搭建的，以及访问的问题

解决的问题

• 设计帮助后端成员理解这一过程

附图

登陆系统：

描述的部分

• 这里描述了用户登陆系统时遇到的情况

面临的问题

• 面临与数据库连接访问和与现有信息匹配的问题
  解决的问题
• 帮助编码人员分析登陆时遇到的情况

附图

备忘录管理：

描述的部分

• 这里描述了用户对备忘录进行操作时遇到的情况

面临的问题

• 面临对备忘录的内容进行增删改的问题

解决的问题

• 帮助编码人员分析录入备忘录时遇到的情况

附图

备忘录类别：

描述的部分

• 这里描述了用户对备忘录类别进行操作时遇到的情况

面临的问题

• 面临对备忘录的类别进行增删改的问题

解决的问题

• 帮助编码人员分析修改备忘录类别时遇到的情况

附图

壁纸系统：

描述的部分

• 这里描述了用户设定时遇到的情况

面临的问题

• 面临如何使用备忘录生成壁纸的问题

解决的问题

• 帮助编码人员分析如何生成壁纸的情况

附图

智能分析：

描述的部分

• 这里描述了备忘录软件进行智能分析时遇到的情况

面临的问题

• 面临如何对用户行为进行分析和根据短信进行识别的问题

解决的问题

• 帮助编码人员分析进行智能分析时遇到的情况

附图

包图

描述的部分：

• 基本表达系统的基本功能
• 描述了软件大致需要实现的功能

面临的问题：

• 如何对于相关的类进行整合使之成为更加简练的包
• 对于相关包之间的关系如何显示比较好

解决的问题：

• 大致了解整个软件的使用过程
• 对于繁杂的类实现相当于文件夹的功能，看起来更加简洁
• 实现了uml的附加功能之一

附图

通信图

【part1】
描述的部分

• 描述的是用户登陆注册流程。

面临的问题

• 面临用户账号管理以及云备份的问题。

解决的问题

• 解决用户注册登录的问题
• 解决了用户使用云备份的问题
• 解决用户找回密码的问题。

附图

【part2】

描述的部分

• 描述的备忘录的生成以及删除的问题。

面临的问题

• 面临备忘录自动生成和用户自行创建的问题。

解决的问题

• 解决用户自动撰写备忘录的问题，解决根据手机短信生成备忘录提醒的问题，解决备忘录云备份的问题。

附图

【part3】

描述的部分

• 这里是根据用户手机上其他APP的使用频率自动生成分析图表的部分

面临的问题

• 应用使用频率的获取问题
• 生成分析图表的问题
• 生成消息提醒的问题。

解决的问题

• 自动获取应用使用频率
• 自动生成分析图表
• 自动发送消息提醒。

附图

贡献分评定

分工参考：

团队内部一致交流后，大致分为以下三个模块：任务工作量、任务完成效率、反馈度。贡献分评定不应当仅仅局限于工作量，而应该综合考虑所有对团队发展的因素。具体理由分析：

• 任务工作量：如构建之法中所说，在软件行业中，如何衡量工作量这本身就是一个大问题。但是工作量却并不能因为其难以衡量便不予以考虑，我们会采取团队重复讨论投票形式比较精确、公平的决定工作量占比。比如：在还未开始时进行投票哪个模块的难度最大，工作量最多，这样不够全局自然也会存在偏差，因此我们还会在实现过程中中途继续进行讨论对初始工作量、难度的投票结果进行一定程度的更改使之更为精确。尽量避免出现：“明明有效的只有十行代码，却因为其中加了许多的冗余代码甚至是空行使其代码量看上去较多”这类误判情况。因此我们相信在我们团队中评定出的较为合理的工作量作为贡献分占比的重要参考数据可以使团队更良好的发展，相互良性竞争。

• 任务完成效率：团队并非一个人，而是许多个成员之间的整体，多个模块功能组成的集合，相互之间的影响是很大的，产品的进度很可能会受其中某一个模块而停滞不前。比如产品发布时出现前后端有一个模块还有一半未完成的现象那对整个项目的影响也非常大。因此任务完成效率也是一个重要衡量贡献分占比的数据。

• 反馈度：团队想要良好的发展，就应当每一个成员都尽量保持较高的热情和动力，这样团队才会持久的具有活力和潜力。因此将反馈作为一项重要参考数据决定贡献分，防止出现因为个别成员懈怠导致整个团队缺乏活力，项目完成自然也受到影响。

考虑到本次工作的临时性，既要考虑到贡献分评定的公平性，又要考虑要计算的快速性，故采用以下方式

• 临时贡献分评定 ：个人任务量 45%+完成度45%+反馈情况10%
• 要求：组里总共11个人，分数加起来为100分
• 每个人结束前，对临时队内的每个人进行评定，汇总给PM，PM对每个人的给分进行平均，得出最后贡献分

课上贡献分

课下贡献分

工具选择

根据助教学姐推荐，以及转进同学的使用习惯，本次作业共使用了两种工具：StarUML，ProcessOn。

StarUML

• 制作工具：staruml2.8
• 选择理由：staruml功能完整、易上手；
• 本小组组内试用过ProcessOn和visio，前者缺少部分构图件，后者使用感觉一般。

Process on

• 制作工具 Process on
• 选择理由：
  • 支持流程图、思维导图、原型图、UML、网络拓扑图等；
  • 支持图形界面操作，容易上手，方便实用；
  • 随时将作品分享给队友，达成团队之间的共享，能够更好的协同合作，互相促进；资源丰富，图库资源强大；

使用工具感受

本次作业共使用了两种工具：StarUML，ProcessOn

StarUML

• 在绘制类图上的功能很强大，提供的功能很多也很丰富。虽然下载的StarUML需要使用VPN下载和手动破解并且为全英文版，但是类图的绘制操作并不会复杂，反而很容易。此外，相关的几个英文单词也是比较常用的，所以需要查询的英文单词部分不会很多，这部分不会耗费很多时间。而且，你的类图绘制可以自定义字体格式、大小、填充颜色、属性类型、方法参数和返回值等部分。还有一点，这个软件具有代码逆向工程功能，可以以多种形式导出内容，可以生成Java stub代码、添加实现代码。与Visio相比，StarUML功能比较强大；与Rose相比，StarUML比较轻巧灵活。

• 工具十分的方便可靠，而且还有大量的模板供我们参考。但是面对没有汉化，的确是硬伤，我一开始是抗拒的，因为我“嘤”文不行，所以非常的难受。不过工具设计的十分人性化，及时没有汉化，也可以凭借图标，完成对图的制作。

• 一开始，在真正使用之前，我是抗拒的，没有汉化版，从0开始学一个看起来不是必须的软件，看起来很蠢，但是实际使用起来，“真香!”.starUML这款软件十分具体地分了不同图的模型，每个模型对应详细地工具，使得用起来得心应手！而且，对于对应的UML图，它会自动检测（编译），帮用户发现画错的地方。最关键的是，可以生成java、c++等语言的具体的代码！让用户更直观地了解UML！

ProcessOn

• 是一个功能非常强大的在线画图工具，支持流程图，UML图，UI原型图和思维导图等等，满足用户的绝大部分工作和开发需求。轻便和支持制图的种类多是它最大的优点，同时支持协作功能。不过类比于专业开发的软件如 starUML 不能做到由制图到代码的转换，不能减轻用户负担。

PSP表格

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

换队感受

• 作为一个刚刚跳槽到该队的成员，我觉得自己相当于就是新队友。所以先谈谈来到一个新队的感受吧。在什么都不熟悉的情况下，加入一个已经组了几周的队伍真的好尴尬，队友和项目都非常不熟悉。所幸在来的短短一周内开了两次会，做了原型（一种非常直观的了解方式），新队友们都很热情友好，因此在短短时间内对项目有了较为详细的认识。
• 首先来说下我转队后的团队氛围，我真的觉得很棒，没有不适应，大家都很活跃并且能提出自己的意见，执行力也很好，说迅速融入好像有点奇怪，但是事情就是这样。团队氛围跟转队前的队伍比起来活跃很多。
• pm绪佩，在被他领导的这一周里，我真的对他的领导力以及执行力等相当服气，团队的氛围他功不可没，给他点赞。缺点就是过于大公无私（逃
• 关于uml设计的换人环节，估计是想模拟一下换队，然而在这周我已经体验过了(´-ι_-｀)。临时pm政演很好，善于听取别人建议，执行力也不错，团队uml设计的过程比较都顺利。给他一点点小建议就是希望他能更强硬一点。
• 被换来的新队友因为大多认识，甚至之前因为其他事合作过，也都配合得挺好。
• 新团队氛围对我来说没差，毕竟一直是新团队，就是我周围坐了两个不大了解项目的新队员，对项目比较不熟悉，花了一些时间在项目的讨论上。
• 最后想说，路是自己选的，选了就努力走下去吧。