基于React的MERN技术栈即时通讯软件设计-需求分析与软件架构

AMOYHANS 2021-12-26 13:38:53

一、项目概述
传统前端技术不适应大规模应用，当系统中有很多模型和相应的视图时，其复杂度就会迅速扩大，非常难以理解和调试，特别是模型和视图可能存在双向数据流动。由此催生React、Vue等使用虚拟DOM技术、提倡组件化的框架。
相较于国内流行的Vue，国外使用更频繁的react具有更适用于大型应用、与其他框架、库兼容性更好、使用了Javascript的扩展语法-JSX、更灵活等特点。
我们在react的基础上，开发一个即时通讯软件，熟悉从前端架构设计，到前后端分离、页面模块化，到应用打包部署的开发流程，学习并掌握react和数据库持久化等技术。在开发过程中探索react高阶组件的使用、深入理解函数式编程的思想。

二、技术选型
    与React相关的技术栈很多，综合分析，我们选择了应用比较广泛且相对成熟的MERN stack的全栈开发方式。
   M代表Mongodb:
   目前普遍认为JSON格式是理解和存储数据最自然的方式，JSON格式比传统的关系数据模型有更强大的数据表达能力。MongoDB是一个通用的、基于文档的、分布式的数据库，为云计算时代的现代应用程序开发者而生。MongoDB是一种文档数据库，也就是说MongoDB用类似JSON格式的文档来存储数据。我们将使用Mongodb实现数据的持久化。
   E代表Express:
   Express 是一个保持最小规模的灵活的 Node.js Web 应用程序开发框架，为 Web 和移动应用程序提供一组强大的功能。使用所选择的各种 HTTP 实用工具和中间件，配合Node.js可以快速方便地创建强大的 API。
   R代表React:
   当前最流行的声明式的组件化的前端开发框架，将用于构建我们的前端页面
   N代表Node.js：
   Node作为一个新兴的前端框架，后台语言,采用一系列“非阻塞”库来支持事件循环的方式。本质上就是为文件系统、数据库之类的资源提供接口,将用于构建我们的后端API和数据库的访问。
   其他：Socket.io库。Socket.IO 实现了实时双向的基于事件的通讯机制。旨在让各种浏览器与移动设备上实现实时app功能，模糊化各种传输机制。Socket.IO 具有跨平台，多种连接方式自动切换的特性，做即时通讯方面的开发很方便，而且能和expressjs提供的传统请求方式很好的结合。

三、需求分析

1.模块化分析

React的显著特点之一就是组件化编程，因此我们先从组件化的思维入手，将问题分解成模块。

我们主要将从三个模块入手，分别是：

个人模块负责与每个用户个人有关的操作。社交模块着重在朋友圈社交相关的内容，会话模块主要管理与聊天相关的操作。

其中，个人模块的细分功能如下：

社交模块：

会话模块：

2.用例分析

原型化方法（Prototyping）和建模的方法（Modeling）是整理需求的两类基本方法。

建模的方法可以快速给出有关事件发生顺序或活动同步约束的问题，能够在逻辑上形成模型来整顿繁杂的需求细节。我们接下来以用例建模、业务领域建模和业务数据建模来具体了解对需求进行建模的方法。

首先我们可以从上面的模块中体现的业务过程提取出抽象用例。

基本的抽象用例：

对于个人来说，主要有

1.编辑个人资料

2.发起单人/多人会话

3.好友管理

4.查看朋友圈

5.编辑朋友圈帖子

6.管理动态

根据对即时通讯系统的过程进行抽象，我们可以得到大致的如下的用例图：

扩展用例：

进一步对上面的模块进行扩展，我们可以得到几个主要的扩展用例（高层用例也包含在其中）：

资料管理扩展用例：

用户端	服务端
1.TUCBW 用户请求登入个人资料页面	2.系统回送资料页的相关信息
3.用户修改个人资料	4.系统检查资料格式并回送结果
5.TUCEW 用户保存并退出

单人聊天扩展用例：

用户端	服务端
1.TUCBW 用户发起对某个好友的聊天请求	2.系统检查好友相关信息，回送聊天室基本信息
3.用户查看聊天记录	4.系统回送聊天记录
5.用户键入新的消息	6.系统保存新消息并发送给对等方
6.TUCEW 用户退出聊天

多人聊天扩展用例：

用户端	服务端
1.TUCBW 用户发起加入群聊	2.系统检查群聊相关信息，回送聊天室基本信息
3.用户查看群成员，群主页	4.系统回送群的详细信息
5.用户查看群聊记录	6.系统回送群聊记录
6.TUCEW 用户退出聊天室

帖子管理扩展用例：

用户端	服务端
1.TUCBW 用户编辑帖子内容后请求推送至朋友圈	2.系统将帖子内容保存至服务器
3.TUCEW 用户收到“发送成功”消息

好友管理扩展用例：

用户端	服务端
1.TUCBW 用户请求查看好友信息	2.系统回送好友信息
3.用户选择添加好友(或加黑名单）	4.系统建立二者的好友（或黑名单）关系
5.TUCEW 用户收到“添加（黑名单）成功”消息

朋友圈管理扩展用例：

用户端	服务端
1.TUCBW 用户请求查看朋友圈	2.系统回送朋友圈最新动态
3.用户查看朋友圈并执行操作（点赞/评论）	4.系统保存用户的操作
5.TUCEW 用户退出

根据组件化的功能细分，我们可以进一步按模块组织分析用例：
个人模块：

社交模块：

会话模块：

最后，我们可以得到基于用例的业务领域模型：

我们主要需要管理用户User与群组Group的之间的Join关系，以及发送的消息格式如Post与User之间的对应关系，Group与Message之间的对应关系。还有对整个用户表和群组表的管理：

业务数据建模：

对业务数据的建模基本如上面的UML类图所示，下面主要说明一下User和Group的组成：
User:

属性	类型	注释
userId	Long	用户ID
userName	String	用户名
desc	String	描述
pswd	String	密码
isOnline	Bool	是否在线

Group:

属性	类型	注释
groupId	Long	群组ID
groupName	String	群名
allUsers	User[]	用户数组
groupDesc	String	群描述
msgRecord	Message[]	消息记录

在数据库的设计上，由于牵涉的数据量不是很大，所以我们不会用到一对非常多的模型，会用到一对很少和一对多的模型，并且由于读的频率会更高，会涉及到反范式化的设计。

四、设计模式与软件架构

1.设计模式

对于消息的组织我们可以采用命令模式

命令（Command）模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。这样两者之间通过命令对象进行沟通，这样方便将命令对象进行储存、传递、调用、增加与管理。

如第三部分中设计的那样，我们将message单独抽象为了一个类，对应的数据和操作组成如下：

属性/操作	类型	注释
msgTime	Long	消息时间
msgSender	User	消息发送者
msgReciver	User	消息接受者
msgContent	String	消息内容
getSender()	User	获取发送者信息
getReciver()	User	获取接收者信息
getContent()	String	获取消息内容