软件系统设计方案--二手交易论坛微信小程序
0.项目概述
本篇博客将针对工程实践项目--校园二手交易论坛微信小程序开发进行软件系统设计分析，从设计模式，软件架构，各类视图，以及数据库设计，软件开发目录的角度进行分析。
此次项目是基于微信小程序的校园二手交易论坛项目，用于校园范围内的二手商品交易和论坛交流，主要功能包括：商品交易，商品交易，论坛发布等功能。
1.设计方案
1.1设计模式
设计模式的本质是面向对象设计原则的实际运用总结出的经验模型。对类的封装性、继承性和多态性以及类的关联关系和组合关系的充分理解的基础上才能准确理解设计模式。
根据模式是主要用于类上还是主要用于对象上来划分的话，可分为类模式和对象模式两种类型的设计模式；
根据设计模式可以完成的任务类型来划分的话，可以分为创建型模式、结构型模式和行为型模式 3 种类型的设计模式；
常见的设计模式有：单例（Singleton）模式，原型（Prototype）模式，建造者（Builder）模式，代理（Proxy）模式，适配器（Adapter）模式，装饰（Decorator）模式，外观（Facade）模式，享元（Flyweight）模式，策略（Strategy）模式，命令（Command）模式。
1.2系统架构
常见的软件架构有：三层架构，MVC架构，MVVM架构等等，我们组的项目决定模型／视图／控制器模式，也即MVC架构（Model-view-controller pattern），这也是在web开发中常用的架构。
MVC即为Model-View-Controller（模型-视图-控制器），MVC是一种设计模式，以MVC设计模式为主体结构实现的基础代码框架一般称为MVC框架，如果MVC设计模式决定了整个软件的架构，不管是直接实现了MVC模式还是以某一种MVC框架为基础，只要软件的整体结构主要表现为MVC模式，我们就称为该软件的架构为MVC架构。
MVC中M、V和C所代表的含义如下：
Model（模型）：代表一个存取数据的对象及其数据模型，也即负责存储系统的中心数据，对于此项目，假如用户需要发布一件新的二手交易商品，Model层负责将这一信息写入到我们的数据库中，而这一过程对其他层来说是透明的；
View（视图）：代表模型包含的数据的表达方式，一般表达为可视化的界面接口，对于此项目而言，由于项目是对微信小程序进行开发，可以概括为wxml界面，也即通过前端呈现给用户的信息，通常可以定义为多个视图；
Controller（控制器）：也即处理用户输入的信息。负责从视图读取数据，控制用户输入，并向模型发送数据，是应用程序中处理用户交互的部分。负责管理与用户交互交互控制。视图和控制器共同构成了用户接口。
整个项目的开发采用WEB开发中十非常重要的SSM框架，也即Spring+SpringMVC+mybatis,尽管目前使用spingboot框架更加轻量级，开发效率更高，但本着学习的目的我们还是决定使用SSM框架进行开发和学习，为之后的学习打下基础。
2.接口API
2.1获取商品列表
下图为后端发给前端的商品列表json数据格式类型：
前端通过接口读取并处理后端发送的数据：
2.2获取论坛列表
下图为后端发给前端的论坛列表json数据格式类型：
前端通过接口读取后并处理后端发送的数据：
3.项目视图
3.1分解视图
分解是构建软件架构模型的关键步骤，分解视图也是描述软件架构模型的关键视图，一般分解视图呈现为较为明晰的分解结构（breakdown structure）特点。分解视图用软件模块勾划出系统结构，往往会通过不同抽象层级的软件模块形成层次化的结构。由于前述分解方法中已经明确呈现出了分解视图的特征，我们这里简要了解一下分解视图中常见的软件模块术语。
3.2依赖视图
依赖视图展现了软件模块之间的依赖关系。比如一个软件模块A调用了另一个软件模块B，那么我们说软件模块A直接依赖软件模块B。如果一个软件模块依赖另一个软件模块产生的数据，那么这两个软件模块也具有一定的依赖关系。
3.3泛化视图
泛化视图展现了软件模块之间的一般化或具体化的关系，典型的例子就是面向对象分析和设计方法中类之间的继承关系。值得注意的是，采用对象组合替代继承关系，并不会改变类之间的泛化特征。因此泛化是指软件模块之间的一般化或具体化的关系，不能局限于继承概念的应用。
3.4执行视图
执行视图展示了系统运行时的时序结构特点，比如流程图、时序图等。执行视图中的每一个执行实体，一般称为组件（Component），都是不同于其他组件的执行实体。如果有相同或相似的执行实体那么就把它们合并成一个。
执行实体可以最终分解到软件的基本元素和软件的基本结构，因而与软件代码具有比较直接的映射关系。在设计与实现过程中，我们一般将执行视图转换为伪代码之后，再进一步转换为实现代码。
3.5部署视图
部署视图是将执行实体和计算机资源建立映射关系。这里的执行实体的粒度要与所部署的计算机资源相匹配，比如以进程作为执行实体那么对应的计算机资源就是主机，这时应该描述进程对应主机所组成的网络拓扑结构，这样可以清晰地呈现进程间的网络通信和部署环境的网络结构特点。当然也可以用细粒度的执行实体对应处理器、存储器等。
由于我们的项目现阶段还未考虑高并发分布式等需求，因此现阶段只采用最基础的将项目部署在服务器上：
3.6工作分配视图
工作分配视图将系统分解成可独立完成的工作任务，以便分配给各项目团队和成员。工作分配视图有利于跟踪不同项目团队和成员的工作任务的进度，也有利于在个项目团队和成员之间合理地分配和调整项目资源，甚至在项目计划阶段工作分配视图对于进度规划、项目评估和经费预算都能起到有益的作用。
4.数据库设计
用户表：
| 字段名 | 类型 | 注释 |
|---|---|---|
| id | int | 用户id |
| name | string | 用户昵称 |
| phone_number | string | 用户手机号 |
| email_address | string | 邮箱地址 |
| wx_id | string | 用户微信账号 |
| student_number | string | 用户学号 |
| school_name | string | 学校名称 |
| 管理员表： | ||
| 字段名 | 类型 | 注释 |
| ---- | ---- | ---- |
| id | int | 管理员id |
| name | string | 管理员昵称 |
| phone_number | string | 管理员手机号 |
| email_address | string | 邮箱地址 |
| wx_id | string | 管理员微信账号 |
| student_number | string | 用户学号 |
| 商品表： | ||
| 字段名 | 类型 | 注释 |
| ---- | ---- | ---- |
| goods_id | int | 商品id |
| user_id | int | 发布商品的用户id |
| name | string | 商品名称 |
| price | int | 商品价格 |
| image | string | 商品图片地址 |
| publish_time | string | 发布时间 |
| type | string | 商品类型 |
| information | string | 商品信息描述 |
| reply_number | int | 评论数量 |
| 论坛表： | ||
| 字段名 | 类型 | 注释 |
| ---- | ---- | ---- |
| post_id | int | 论坛id |
| user_id | int | 发布论坛的用户id |
| name | string | 论坛名称 |
| image | string | 论坛图片地址 |
| publish_time | string | 发布时间 |
| type | string | 论坛类型 |
| information | string | 论坛内容 |
| reply_number | int | 评论数量 |
| 回复表： | ||
| 字段名 | 类型 | 注释 |
| ---- | ---- | ---- |
| reply_id | int | 回复id |
| item_id | int | 所属商品或论坛的id |
| user_id | int | 发表评论用户的id |
| publish_time | string | 评论时间 |
| information | string | 评论内容 |
5.项目实现视图
实现视图是描述软件架构与源文件之间的映射关系。比如软件架构的静态结构以包图或设计类图的方式来描述，但是这些包和类都是在哪些目录的哪些源文件中具体实现的呢？一般我们通过目录和源文件的命名来对应软件架构中的包、类等静态结构单元，这样典型的实现视图就可以由软件项目的源文件目录树来呈现。
前端的项目目录如图所示：
由于该项目目前设计主要内容为前端，后端框架目前正在学习中，不能给出详细的目录结构，总体的SSM框架目录结构如图所示：
6.软件系统运行环境和技术选型
该项目前端开发使用Visual Studio进行编码，并用小程序官方开发软件进行测试，使用微信小程序的原生框架进行开发，后端使用IDEA进行编码，采用SSM框架（即spring+springMVC+mybatis），数据库初步考虑使用mysql，后期将项目部署在linux环境下，并上传至微信小程序官方进行审核，审核通过后用户可以在微信中搜索小程序进行使用。
7.概念原型和核心工作机制
概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论,而概念原型是一种虚拟的、理想化的软件产品形式。
如下是概念原型的具体定义：
概念原型=用例+数据模型。
因此也可以总结出该项目的核心工作机制为：
项目参与者主要分为普通用户和管理员，普通用户首先进行注册，在管理员审核通过之后可以顺利进行登录，可以从商品页面浏览商品，根据分类选择自己感兴趣的商品，并在感兴趣的商品下评论；也可以在论坛页面浏览论坛并发表评论；同时用户也可以发布自己的帖子和商品，在管理员审核通过之后成功发布。管理员由可以做到和普通用户同样的事情，除此之外，管理员可以审核进行注册的普通用户，通过验证其学校和学号等信息使普通用户使用小程序，并在用户发布其商品或者帖子后进行审核，审核通过之后，该商品或帖子可以在商品页面和论坛页面公开显示
8总结
经过这两次作业博客的撰写，我对本次工程实践的理解也更加深刻了，本次博客通过软件系统设计方案的分析，绘制各类视图，也帮助我梳理了项目的逻辑思路，接下来工程实践的内容正是后端代码的书写，逻辑理清之后，相信项目的开发也会更加，同时在编码的过程中二次理解项目和软件工程的思想。博客中的不足之处，希望老师和同学们批评指正。
