202202 发际线跟我做队 实验七 团队作业4：团队项目需求建模与系统设计
一、实验目的与要求
| 项目 | |
|---|---|
| 课程班级博客链接 | https://edu.cnblogs.com/campus/xbsf/2019nwnucs |
| 本次作业要求链接 | https://edu.cnblogs.com/campus/xbsf/2019nwnucs/homework/12649 |
| 团队名称 | 发际线跟我作队 |
| 团队成员分工描述 | （1）毛玉贤：博客撰写、数据字典、软件系统状态图、软件总体结构设计、需求规格说明书、系统设计说明书 （2）蒋敏敏：ER图、数据库逻辑设计、需求规格说明书 （3）张颖：数据流图、WBS编制、系统设计说明书 |
| 团队的课程学习目标 | （1）编制团队项目需求规格说明书； （2）编制团队项目系统设计说明书，掌握软件系统总体设计过程、设计原理和启发式规则。 |
| 这个作业在哪些方面 助团队实现学习目标 |
（1）团队成员线上交流学习，使得我们对于讨论的问题可以清晰的抒发各自的观点； （2）成员彼此讲解自己对所学内容的理解，解答他人疑惑，提升了团队对基本概念的理解，加深印象； （3）团队一起学习用ProcessOn帮助我们更快的掌握软件的使用以及各种类型图形的绘制； |
| 团队博客链接 | 发际线跟我作队 |
| 团队项目Github仓库链接 | 传送门 |
二、实验环境要求
在线作图工具 ProcessOn：https://www.processon.com/
三、实验内容与步骤
1、 任务一：以团队协作学习方式掌握在线作图工具ProcessOn的软件操作方法。
1.1 ProcessOn软件介绍
| ProcessOn介绍 | |
|---|---|
| 什么是ProcessOn？ | （1）ProcessOn 是一个面向垂直专业领域的作图工具和社交网络，成立于2011年6月并于2012年启动； （2）支持绘制思维导图、流程图、UML、网络拓扑图、组织结构图、原型图、时间轴等等； （3）ProcessOn 将全球的专家顾问、咨询机构、BPM厂商、IT解决方案厂商和广泛的企业用户紧密地连接在一起，提供基于云服务的免费流程梳理、创作协作工具。用户可与同事和客户协同设计，实时创建和编辑文件，并可以实现更改的及时合并与同步。这意味着跨部门的流程梳理、优化和确认可以即刻完成； （4）专注于为作图人员提供价值，利用互联网和社交技术颠覆了人们梳理流程的方法习惯，继而使商业用户获得比传统模式更高的效率和回报，改善人们对流程图的创作过程； |
| 操作技巧 | （1）平均分布：在很多时候我们会使用一行（列）矩形，由于手动拖拽的随意性，导致这些元素的间距不尽相同，这时可以使用图形分布的功能，将这些元素调整为相等间距。操作时，选中对应的元素，然后选择屏幕顶部的工具栏中的“排列“，并选择“图形分布”->“垂直（水平）平均分布”； （2）元素对齐：在拖动一个元素的时候，会自动地出现一些对齐线，方便用户将元素对齐到特定的位置，一旦元素比较多，拖动的操作就有点杯水车薪，可以使用对齐的功能快速地进行元素对齐，将需要对齐元素选中，然后右键（或者点击屏幕顶部的工具栏中的“排列“），并选择“图形对齐”->“居中（左/右/顶端/垂直居中/底部）对齐”； （3）大小控制：有时，在一些框内会标注文字，由于文字长短不同，会出现框本身的宽度不一致，为了保持整齐，一般操作为手动逐个调整方框大小，或者选中之后统一调整高宽数值，也可以使用批量操作的方式，选中对应的元素，然后选择屏幕顶部的工具栏中的“排列“，并选择“匹配大小”->“宽度”； （4）Z轴排列：在多个元素进行组合的时候，通常会涉及到前后遮挡的问题，默认情况下，元素的z轴值是根据创建的先后顺序决定大小的，当想要调整时，可以使用“排列”->“置顶/置底/上移/下移”操作； （5）分组：操作简单，选中需要组合的元素，然后右键（或选择屏幕顶部的工具栏中的“排列”），并选择“组合”，即可完成； （6）框内文字对齐：在很多框图中，为了表示一个集合的概念，通常会在表示父元素的框内标注上集合的名字，一般情况下，父元素内的标注文字会使用“顶端对齐“的方式，操作时，先选中元素，然后打开屏幕上方工具栏中的“对齐“菜单，就可以选择相应的对齐方式； |
| 优点 | （1）它是一个在线的工具，有跨平台特性，屏蔽了因为不同操作系统带来的麻烦； （2）其有在线存储功能，避免忘记保存或突然断电来不及保存的悲剧发生； （3）操作简单，ProcessOn基本吸取了visio之类常用绘图软件的操作特点，故对于有绘图经验的用户，学习成本几乎为零； （4）不同图表的作者可以轻松地在平台分享各自作品，用户也可以方便地对公开的作品进行搜索，同时还支持多人协作功能，适合团队内部协同工作； |
| 缺点 | （1）该工具并非十全十美，产品还存在或大或小的不稳定因素，如丢失数据 （2）菜单功能卡住，图标相对比较少等； |
1.2 团队协作学习使用
2、 任务二：整理实验六的项目需求陈述资料，设计并绘制团队软件系统数据流图、编写数据字典、设计ER图、软件系统状态图，编制团队项目系统需求规格说明书，将该文档上传到团队项目Github仓库。
2.1 需求资料总结
-
资源管理模块
所开发的网站需要有丰富的资源供用户使用，包括系统提供的资源以及普通用户上传的资源，开源数据集等，资源管理模块实现了用户资源上传、资源分类（文档或文件夹）、资源删除、管理员的审核等功能，为用户上传下载资源，提供了便捷的途径。 -
论坛模块
一个好的知识学习网站，论坛功能是少不了的，论坛功能提供给用户随时随地发帖的机会，在学习过程中遇到不懂的问题，可以随心发帖，请教热心的技术伙伴，一起交流讨论问题，同时系统会为用户精准推送同一地区技术伙伴的帖子，以及笔记、文档等资源，这为用户提供了结交周边技术好友的机会。 -
笔记模块
用户在使用网站资源进行学习的同时，希望能随时在线记录所学知识，记录学习过程中的易混淆点、重点、难点，帮助学习，方便复习。笔记模块的编辑功能采用了用户比较喜欢的Markdown排版，编辑简单方便，同时用户可以查看下载其他用户公开发表的笔记，参考学习。 -
题库模块
背包知识社区系统，不仅要能进行知识资源的下载查看，还能进行相应模块的练习，巩固用户掌握的知识，用户能根据难度、题目类型搜索相应的编程练习题，还可以搜索具体的题目标题，来找相应的题目。 -
网站资源不收费，投放广告
经需求分析发现绝大部分用户不希望网站资源收费，故网站采用的收费方式为与其他公司进行合作，在界面中适当的投放一些广告，用户根据自身需求，点击广告查看。 -
网站界面
在实验六的需求分析中，根据问卷调查得到的结果，选择使用APP和网页来实现系统的占比大致相同，综合考虑团队选择使用网页版来设计实现。界面简洁，美观大方，操作简便，给用户提供了良好的用户交互式界面。
2.2 软件系统数据流图
- 简称DFD，它从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。
| 事项 | |
|---|---|
| 数据流 | （1）由一组固定成分的数据组成，表示数据的流向。注意，数据流图中描述的是数据流，而不是控制流； （2）除了流向数据存储或从数据存储流出的数据不必命名外，每个数据流必须要有一个合适的名字，以反映该数据流的含义； |
| 加工 | （1）加工描述了输入数据流到输出数据之间的变换，也就是输入数据流经过什么处理后变成了输出数据； （2）每个加工都有一个名字和编号。编号能反映该加工位于分层的数据流图的哪个层次和哪张图中，能够看出它是由哪个加工分解出来的子加工； |
| 数据存储 | （1）数据存储表示暂时存储的数据。每个数据存储都有一个名字； |
| 外部实体 | （1）外部实体是存在于软件系统之外的人员或组织，他指出数据所需要的发源地或系统所产生的数据的归属地； |
2.3 数据字典
- 数据字典是一种通用的程序设计方法。可以认为，不论什么程序，都是为了处理一定的主体，这里的主体可能是人员、商品（超子）、网页、接口、数据库表、甚至需求分析等等。当主体有很多的属性，每种属性有很多的取值，而且属性的数量和属性取值的数量是不断变化的，特别是当这些数量的变化很快时，就应该考虑引入数据字典的设计方法。
- 数据字典有两种：①把主体的属性代码化放入独立的表中，不是和主体放在一起，主体中只保留属性的代码。这里属性的数量是不变的，而属性取值的数量可以是变化的；②用一个表来放结构相同的所有属性信息，不同属性的不同取值统一编码，用“类型”来区别不同的属性，主体中保留属性代码的列表。这样主体所拥有的属性数量就是可变的了。
2.3.1 数据项
- 数据项是数据的最小组成单位，若干个数据项可以组成一个数据结构。数据字典通过对数据项和数据结构的定义来描述数据流、数据存储的逻辑内容。
| 字段名 | 说明 | 数据类型 |
|---|---|---|
| UserId | 用户编号 | varchar(30) |
| ResourceId | 资源编号 | varchar(30) |
| InvitationId | 帖子编号 | varchar(30) |
| NoteId | 笔记编号 | varchar(30) |
| QuestionId | 题目编号 | varchar(30) |
| EmailId | 邮件编号 | varchar(30) |
| AdministratorId | 工号 | varchar(30) |
| UserName | 姓名 | char(10) |
| AdministratorName | 姓名 | char(10) |
| SenderName | 发件人姓名 | char(10) |
| UserSex | 性别 | char(2) |
| AdministratorSex | 性别 | char(2) |
| PhoneNum | 手机号 | char(11) |
| AdministratorTel | 手机号 | char(11) |
| AdministratorPassword | 密码 | varchar(10) |
| UserPassword | 密码 | varchar(10) |
| UserIntroduce | 简介 | text |
| UserBirthday | 生日 | datetime |
| UserCity | 城市 | char(4) |
| UserSchool | 单位 | varchar(10) |
| UserEmail | 邮箱 | varchar(20) |
| ResourceSort | 资源类别 | char(10) |
| ResourceState | 审核状态 | char(4) |
| UploadTime | 上传时间 | datetime |
| InvitationPublishtime | 发表时间 | datetime |
| CreateTime | 创建时间 | datetime |
| NoteUpdataTime | 更新时间 | datetime |
| UpdataTime | 更新时间 | datetime |
| InvitationTitle | 标题 | char(20) |
| NoteTitle | 标题 | char(20) |
| CommentNum | 评论量 | int |
| LikeNum | 点赞量 | int |
| CollectNum | 收藏量 | int |
| QuestionName | 题目名称 | char(20) |
| PercentOfPass | 通过率 | char（4） |
| DegreeOfDifficulty | 难度 | char(10) |
| QuestionSort | 类型 | char(10) |
| ReceiveTime | 接收时间 | datetime |
| EmailName | 邮件标题 | char(20) |
| EmailState | 接收状态 | char(4) |
2.3.2 数据结构
- 根据课程题目的要求，经需求分析，需用到七个表，分别为注册用户表，资源上传表，帖子发布表，笔记记录表，练习题库表，邮件接收表，系统管理员表。详细属性及其主码如小表所示，其中加下划线的为该表的主码。
| 编号 | 数据结构名 | 属性 |
|---|---|---|
| 1 | 注册用户 | 用户编号、姓名、年龄、生日、城市、学校、手机号、邮箱、简介、密码 |
| 2 | 资源上传 | 用户编号、资源编号、资源类别、上传时间、更新时间、审核状态 |
| 3 | 帖子发布 | 帖子编号、标题、发表时间、发表用户、评论量、点赞量、收藏量 |
| 4 | 笔记记录 | 用户编号、笔记编号、标题、创建时间、更新时间 |
| 5 | 练习题库 | 题目编号、题目名称、通过率、难度、类型 |
| 6 | 邮箱 | 用户编号、邮件编号、发件人姓名、接收时间、邮件标题、接收状态 |
| 7 | 管理员 | 工号、姓名、性别、密码 |
- 下面是本系统所需要的的七个基本表。
| 字段名 | 说明 | 数据类型 | 约束 | 备注 |
|---|---|---|---|---|
| UserId | 用户编号 | varchar(30) | 主码 | 注册用户的编号 |
| UserName | 姓名 | char(10) | not null | 注册用户的姓名 |
| UserIntroduce | 简介 | text | not null | 注册用户的简单介绍 |
| PhoneNum | 手机号 | char(11) | not null | 注册的手机号码 |
| UserSex | 性别 | char(2) | not null，取“男”或“女” | 注册人性别 |
| UserBirthday | 生日 | datetime | not null | 注册人生日 |
| UserCity | 城市 | char(4) | not null | 注册人当前所在城市 |
| UserSchool | 单位 | varchar(10) | not null | 就读学校或者公司 |
| UserEmail | 邮箱 | varchar(20) | not null | 绑定的邮箱 |
| UserPassword | 密码 | varchar(10) | not null | 登录密码 |
| 字段名 | 说明 | 数据类型 | 约束 | 备注 |
|---|---|---|---|---|
| ResourceId | 资源编号 | varchar(30) | 主码 | 用户上传资源的独有编号 |
| UserId | 用户编号 | varchar(30) | not null，引用注册用户表的外码 | 注册用户的编号 |
| ResourceSort | 资源类别 | char(10) | not null | 用户上传的资源类型，文档或文件夹 |
| UploadTime | 上传时间 | datetime | not null | 资源上传的时间 |
| UpdataTime | 更新时间 | datetime | not null | 更新所上传资源的时间 |
| ResourceState | 审核状态 | char(4) | not null，取“通过”或“未过” | 管理员审核上传资源的状态 |
| 字段名 | 说明 | 数据类型 | 约束 | 备注 |
|---|---|---|---|---|
| InvitationId | 帖子编号 | varchar(30) | 主码 | 发布帖子的编号 |
| UserId | 用户编号 | varchar(30) | not null，引用注册用户表的外码 | 注册用户的编号 |
| InvitationTitle | 标题 | char(20) | not null | 发布帖子的标题 |
| InvitationPublishtime | 发表时间 | datetime | not null | 帖子发表的时间 |
| CommentNum | 评论量 | int | not null | 评论帖子的数量 |
| LikeNum | 点赞量 | int | not null | 点赞帖子的数量 |
| CollectNum | 收藏量 | int | not null | 收藏帖子的数量 |
| 字段名 | 说明 | 数据类型 | 约束 | 备注 |
|---|---|---|---|---|
| NoteId | 笔记编号 | varchar(30) | 主码 | 创建笔记的编号 |
| UserId | 用户编号 | varchar(30) | not null，引用注册用户表的外码 | 注册用户的编号 |
| NoteTitle | 标题 | char(20) | not null | 记录笔记的概要标题 |
| CreateTime | 创建时间 | datetime | not null | 笔记创建的时间 |
| NoteUpdataTime | 更新时间 | datetime | not null | 笔记再次编写更新的时间 |
| 字段名 | 说明 | 数据类型 | 约束 | 备注 |
|---|---|---|---|---|
| QuestionId | 题目编号 | varchar(30) | 主码 | 题库中题目的编号 |
| QuestionName | 题目名称 | char(20) | not null | 题目的标题、名称 |
| PercentOfPass | 通过率 | char（4） | not null | 答对这道题目的人占总答题人数的百分比 |
| DegreeOfDifficulty | 难度 | char(10) | not null | 这道题的难道，简单，普通，或困难 |
| QuestionSort | 类型 | char(10) | not null | 该题目相关的知识点类型，字符串、二叉树、数组、链表等等 |
| 字段名 | 说明 | 数据类型 | 约束 | 备注 |
|---|---|---|---|---|
| EmailId | 邮件编号 | varchar(30) | 主码 | 接收邮件的编号 |
| UserId | 用户编号 | varchar(30) | not null，引用注册用户表的外码 | 注册用户的编号 |
| SenderName | 发件人姓名 | char(10) | not null | 发件人的姓名 |
| ReceiveTime | 接收时间 | datetime | not null | 邮件接收的时间 |
| EmailName | 邮件标题 | char(20) | not null | 接收邮件的标题 |
| EmailState | 接收状态 | char(4) | not null ，取“已读”或“未读” | 邮件的接收状态，已读或未读 |
| 字段名 | 说明 | 数据类型 | 约束 | 备注 |
|---|---|---|---|---|
| AdministratorId | 工号 | varchar(30) | 主码 | 管理员的编号 |
| AdministratorName | 姓名 | char(10) | not null，引用注册用户表的外码 | 管理员的姓名 |
| AdministratorSex | 性别 | char(2) | not null，取“男”或“女” | 管理员的性别，男或女 |
| AdministratorTel | 手机号 | char(11) | not null | 管理员的注册电话 |
| AdministratorPassword | 密码 | varchar(10) | not null | 管理员的登录密码 |
2.3.3 数据流
- 根据用户需求分析，由用户，管理员，资源等基本表之间的关系，总结出本系统所需要的数据流。
| 编号 | 数据流名 | 输入 | 输出 |
|---|---|---|---|
| 1 | 用户注册信息 | 电话、密码 | 登录信息 |
| 2 | 用户登录信息 | 电话、密码 | 首页信息 |
| 3 | 资源上传信息 | 所要上传的资源 | 资源信息 |
| 4 | 检索信息 | 查询信息 | 相应帖子、文档信息 |
| 5 | 发帖信息 | 编辑帖子信息 | 帖子发布信息 |
| 6 | 笔记信息 | 笔记内容 | 保存笔记信息 |
| 7 | 习题信息 | 编辑代码 | 结果信息 |
| 8 | 个人信息 | 修改信息 | 修改后的个人信息，年龄、城市、性别等 |
| 9 | 管理信息 | 管理员电话、密码 | 通过用户上传资源、以及设置用户基本界面信息 |
2.4 ER图
- 也称为实体关系图，用于显示实体集之间的关系。它提供了一种表示实体类型、属性和连接的方法；用来描述现实世界的概念模型。ER模型是数据库的设计或蓝图，将来可以作为数据库来实现。
2.5 软件系统状态图
- 状态图：通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。状态图还指明了作为特定事件的结果系统将做哪些动作，因此状态图提供了行为建模机制。
| 事项 | |
|---|---|
| 状态 | （1）状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。系统对事件的响应，既可以是做一个或一系列动作，也可以是仅仅改变系统本身的状态，还可以是即改变状态又做动作； （2）在状态图中定义的状态主要有：初态（初始状态）、终态（最终状态）、中间状态。在一张状态图中只能有一个初态，而终态则可以有0至多个； |
| 事件 | （1）事件是在某个特定时刻发生的事情，它是对引起系统做动作或（和）从一个状态转换到另一个状态的外界事件的抽象； （2）事件是引起系统做动作或（和）转换状态的控制信息； |
| 符号 | （1）在状态图中，初态用实心圆表示，终态用一对同心圆表示（内圆为实心），中间状态用圆角矩形，可用两条横线划分为上中下3部分，上为状态名称，中位状态变量，下为活动表； （2）活动表三种基本事件：entry，exit，do； （3）两个状态间带箭头的连线称为状态转换，箭头指明转换方向； |
- 管理员状态图
-
普通用户状态图
-
总体状态
-
各个分支详细状态
-
资源管理
- 论坛
- 笔记
- 练习
- 消息通知
- 个人主页
2.6 系统需求规格说明书
2.7 文档上传至github团队仓库截图
3、 任务三：编制团队项目的WBS，估计各项任务所需时间。
3.1 编制软件系统WBS
3.2 各项任务所需时间
4、 任务四：按功能对团队软件项目进行模块划分、建立模块层次结构及调用关系、确定各模块间的接口等；进行软件系统数据库逻辑结构设计，包括数据特征的描述、确定数据的结构特性。撰写团队项目软件系统设计说明书，以回答：软件是如何实现用户需求的？
4.1 总体设计
- 系统处理流程图(更多细节见文档)
4.2 逻辑设计
4.2.1 ER图向关系模型转换
- 根据E-R图可以将系统中的概念模型转换为具体的表（即关系）结构，共分为7个关系，详细信息如下所示：
- 用户(用户编号、姓名、年龄、生日、城市、学校、手机号、邮箱、简介、密码)
- 资源(用户编号、资源编号、资源类别、上传时间、更新时间、审核状态)
- 管理员(工号、姓名、性别、密码)
- 笔记(用户编号、笔记编号、标题、更新时间，创建时间)
- 题库(题目编号、题目名称、通过率、难度、类型)
- 邮箱(用户编号、邮件编号、发件人姓名、接收时间、邮件标题、接收状态)
- 帖子(帖子编号、标题、发表时间、发表用户、评论量、点赞量、收藏量)
4.2.2 关系模式
4.3 软件系统设计说明书
4.4 文档上传至github团队仓库截图
5、 任务五：完成《实验七 团队作业4：团队项目需求建模与系统设计》团队博文作业
5.1 发布博客到班级作业
5.2 满足任务1-任务4要求上传到仓库的材料截图
5.3 记录完成《实验七 团队作业4：团队项目需求建模与系统设计》各项任务实际花费的时间和分工
| 任务 | 总计（min） | |
|---|---|---|
| 任务一 | （1）团队协作学习ProcessOn（30） | 30 |
| 任务二 | （1）整理实验六项目需求陈述资料（10）； （2）设计并绘制团队软件系统数据流图（35）； （3）编写数据字典（25）； （4）设计ER图（20）； （5）软件系统状态图（30）； （6）编制团队项目系统需求规格说明书（63）； |
183 |
| 任务三 | （1）编制团队项目的WBS，估计各项任务所需时间（45）； | 45 |
| 任务四 | （1）设计软件系统总体结构（65）； （2）设计软件系统数据库逻辑结构（45）； （3）撰写团队项目软件系统设计说明书（61）； |
171 |
| 任务五 | （1）完成博客（65） （2）记录时间（10） （3）感悟（5） |
78 |
5.4 从团队分工和协作学习角度，陈述团队实施项目需求分析建模、软件系统设计等学习活动的心得
| 姓名 | |
|---|---|
| 毛玉贤 | （1）团队分工：在上次实验六中，进行了项目需求调研活动，并根据调研结果进行了需求分析，已经获得了用户对于背包知识社区系统的功能需求，通过上次团队分工合作后，感觉我们的协作方式效率不是太高，所以在这次的实验中我们改进了协作方式，使得每位成员都能扬长避短，效率翻倍。在任务开始前，总览任务，分配各自最擅长的领域，组长总览全局，成员三人相互之间均有渗透，不断将各自任务改进优化； （2）学习角度：在不明白的问题上，我们团队会小组讨论，合力解决问题，这不仅使得每位成员的参与感增强，而且大家都在慢慢掌握这一知识点，提升了团队凝聚力，协作力；在此次实验中，无论是需求分析建模还是软件系统设计都是经过我们小组讨论后，在开始进行具体设计，在讨论的过程中，各自提出的疑问，有时也是其他人所不熟知的，通过这一过程，很好地帮助我们理解实验项目的各个要求； |
| 蒋敏敏 | （1）团队分工：我们小组有序的进行了需求分析建模，编写了需求规格说明书，如果有不懂得地方，每一位成员都会给出自己的意见，在分工上，我们小组感觉比较合理，所以完成的挺顺利的，需求分析是很重要的内容，所以我们在完成时也花费了大量的时间，团队协作让我们的效率大大提升，更加体会到分工与协作的重要性； （2）学习角度：在一开始，我们对于WBS完全没有想法，通过大家一起对相关资料的学习，每个人的看法以及小组之间的讨论，我们有了很大的进展，也顺利在后期完成了WBS的制作，很有成就感，软件的总体设计让我们对模块与模块之间有了划分，尤其是每个模块实现的功能； |
| 张颖 | （1）团队分工：只有在我们通过团队分工来思考到达一定的程度展开讨论，才有可能出现一点即通、恍然大悟、豁然开朗、原来是这样的效果；也只有在此时展开讨论，才有可能出现观点的碰撞，因此我们参与在协作学习之前，一定要做好团队分工，有独立学习思考的时机； （2）学习角度：通过小组讨论，互相启发，达到优势互补，解决我们个体无法解决的疑难的目的。我们在参与讨论，参与探究的过程中，必须要有自己的见解和前认知能力作为基础，而我们的独立思考是无法由别人或小组来替代的； |
