12.3 设 计 阶 段
该阶段的报告主要为软件架构设计、软件设计模型。
12.3.1 软件架构设计
12．3．1．1 引言
1）编写目的
本软件架构文档的编写目的是对二手商品交易平台软件的系统结构进行描述和定义，在之前的需求规约、系统分析的基础上，利用各种模型，详细展示系统的结构，为后续的软件实现工作奠定基础。文档将定义系统架构的设计目标，描述系统的结构、子系统定义、软硬件部署、数据管理、软件控制、边界条件等内容。本文档用于开发团队明确系统的架构和设计，并以之为依据进行开发工作。
2）适用范围
本文档适用于的软件：校园二手商品交易平台。
与该软件相关的特性、子系统、模型等均符合本文档中的内容。
3）定义
本文档中涉及的术语定义在项目词汇表（词汇表．docx）中给出。
4）参考资料
《面向对象软件工程——使用UML、模式与Java》（第3版），清华大学出版社，2011。
5）概述
本文档包括引言、目前系统架构、系统架构设计目标、建议的软件系统架构四部分。目前系统部分对当前线下二手交易市场进行分析并指出其不足。系统架构设计目标部分结合软件需求，列举出系统设计的目标。建议的软件系统架构给出系统的架构和子系统的分解，并以文字表述和模型图相结合的方式展示系统的对象设计、软硬件部署、数据管理、软件控制、边界条件等设计。本文件的各部分内容联系紧密，互为补充和对照，共同呈现本系统的软件架构。
12．3．1．2 目前软件系统体系架构
目前存在的系统是一个线下的原始人工系统，即由商贩或者店家通过较低的价格收购旧书或者生活用品，自行整理分类后运至学校门口进行小范围短时间销售的这一流程所构成的系统。
新的系统是手机端的App，快捷简便且便于用户上手。
12．3．1．3 软件系统架构设计目标
系统架构的设计目标如下：
（1）高可用性：本软件作为一个交易平台，如果在交易发生时发生系统不可用的情形，将会带来不可知的后果。因此系统需要保证较高的可用性。
（2）安全性：本系统注册为实名制，数据库内保留有比较重要的个人信息，因此必须保证系统的安全性。
（3）高性能：本系统运行过程中实时响应，并且具有较大的流量，因此要求有较高的性能。
（4）可扩展性：本系统在初期规模较小时，不需要较为高规格的硬件。但应当考虑到在用户数量增加后对系统的扩展。
12．3．1．4 建议的软件系统架构
12．3．1．4．1 概述
本系统的架构及采用架构模式：
1）客户／服务器模式（client／server）
本系统分为前台客户端和后台服务器。前台为用户手机上的App，后台是实现系统功能的服务器。
选择客户／服务器模式的原因是这种模式比较成熟，且客户、服务器分离符合App开发的环境，并且也方便数据的集中管理。
2）三层体系结构（3-layered architecture）
本系统用三个层次来组织子系统：第一层为用户界面层，提供与用户交互的接口，即App的UI。第二层为应用逻辑层。这一层主要负责控制并实现系统功能，包含User Management、Item Management、Order Management和Dialog Management四个子系统，分别负责用户信息、商品、订单和对话的控制。第三层为存储层。主要负责系统数据的存储、检索和查询。
三层体系结构比较成熟，将接口和应用逻辑分开，耦合度低，灵活性和扩展性强，方便开发过程的分工。因此本软件采用这个结构。
3）模型视图控制器模式（model，view and controller，MVC）
MVC模式适用于交互系统。在上述的三层体系结构中已经将系统分为视图（第一层）、控制器（第二层）和模型（第三层）三部分。
本系统为独立开发，在支持双方交互通信功能的实现上，将使用第三方的类库。
本系统包含以下子系统：
（1）UI：负责用户界面部分。
（2）User Management：负责用户信息的管理，控制登录、注册、个人资料修改等功能。
（3）Item Management：负责商品的管理，控制商品发布、修改、检索、分类、查看等功能。
（4）Purchase Management：负责订单的管理，控制订单的生成、确认和完成等功能。
（5）Dialog Management：负责对话和消息管理。控制用户之间的联系、系统消息的发送、公告的管理等功能。
（6）Common Service：负责客户机与服务器通信以及数据存取功能。
12．3．1．4．2 用例视图
插入软件需求规约文档中的图12-7。此处为节省篇幅略去。在实际的文档中，为了文档的完整性、自包含性，将把图12-7复制在此处。
12．3．1．4．3 系统逻辑视图
1）系统架构
本系统采用了三层体系结构和客户机／服务器模式。最顶层是UI层，是用户直接交互的客户机部分。中间层是应用逻辑层，包含实现系统功能的各子系统。第三层为公共服务层，实现对数据的存储和管理、移动端与服务器的通信功能。
此处插入软件设计模型文档中的图12-60。此处为节省篇幅略去。在实际的文档中，为了文档的完整性、自包含性，应把图12-60复制在此处。
2）子系统
（1）UI子系统。
功能：负责与用户的交互。
服务：UI层主要提供各种输入框、按钮、文本框等进行信息的显示和与用户的交互的功能。
类图：此处插入软件设计模型文档中的图12-61。
组件图：此处插入软件设计模型文档中的图12-89。
（2）User Management子系统。
功能：负责用户信息的管理，控制登录、注册、个人资料修改等。
服务：
public void register（）
public int submit User Info（String user Name，String password，String mail，String phone Number，String password Confirmation）
public int login（Stringuser Name，String password）
public void show Personal Info（）
public int update Personal Info（String user Name，String password，String mail，String phone Number，String password Confirmation）
类图：此处插入软件设计模型文档中的图12-62。
组件图：此处插入软件设计模型文档中的图12-90。
（3）Item Management子系统。
功能：负责商品的管理，控制商品发布、修改、检索、分类、查看等功能。
服务：
public Stringget Item Types（）
public String get Itemsby Type（String type Name）
public Boolean publish Item（String item Name，String description，String price，String item Type，Image image）
public void publish Item Process（）
public void get My Published Info（int user ID）
public Item get Published Item Info（int item ID）
public Boolean withdraw Item（int item ID）
public Item［］get My Favored Info（int user ID）
public Item get Favored Item Info（int item ID）
public Item get Item Info（int item ID）
public Boolean cancel Favor（int user ID，int item ID）
public Item［］search Items（String keywords）
public Item request Item Details（int item ID）
public Boolean favor Item（int user ID，int item ID）
类图：此处插入软件设计模型文档中的图12-63。
组件图：此处插入软件设计模型文档中的图12-91。
（4）Purchase Management子系统。
功能：负责订单的管理，控制订单的生成、确认和完成等功能。
服务：
public void purchase Item（）
public Boolean submit Order（int user ID，int item ID，Date deal Time，String deal Place， String phone Number）
public int submit Order（）
public Boolean confirm Order（int order ID）
public String get Order Status（int order ID）
public Boolean close Deal（int order ID）
public Boolean confirm Closure（int order ID）
public Boolean cancel Order（int user ID，int order ID）
public Boolean confirm Order Cancel（int order ID，int user ID）
public Order［］get My Order Info（int user ID）
public Boolean select Order（int order ID）
public Order get Order Info（int order ID）
类图：此处插入软件设计模型文档中的图12-64。
组件图：此处插入软件设计模型文档中的图12-92。
（5）Dialog Management子系统。
功能：负责对话和消息管理。控制用户之间的联系、系统消息的发送、公告的管理等功能。
服务：
public Dialog［］get My Dialogs（int user ID）
public Dialog chose Dialog（int dialog ID）
public Dialog get Dialog Info（int dialog ID）
public Boolean start Communication（int caller ID，int callee ID）
public Boolean communication Request（int caller ID）
public Boolean send Message（int send ID，int receiver ID，String content）
public Boolean show Message（int sender ID，int receiver ID，String contents）
类图：此处插入软件设计模型文档中的图12-65。
组件图：此处插入软件设计模型文档中的图12-93。
（6）Common Service子系统。
功能：提供数据存取管理、客户端与服务器通信功能。
服务：
public String request（String request String，String url）
public Boolean start Communication（int caller ID，int callee ID）
public Boolean send Message（int sender ID，int receiver ID，String contents）
类图：此处插入软件设计模型文档中的图12-66。
组件图：此处插入软件设计模型文档中的图12-94。
3）用例实现
本系统中的核心用例为Purchase Item。
此处插入软件设计模型文档中的图12-80。
4）子系统协作
核心用例Purchase Item的子系统协作图如图12-54所示。
图12-54 Purchase Item子系统协作图
12．3．1．4．4 系统运行视图
1）客户端进程视图
在Client端，为了保证用户体验，UI线程只负责边界对象与用户的交互。同时对每一个控制器单独启动一个线程。同时对于通信模块，也启动一个线程。这样的设计能够保证前台、功能实现、通信不会阻塞应用的运行。
此处插入软件设计模型文档中的图12-95。
2）服务端进程视图
服务端进程设计中，对于通信部分，将依据请求的并发性，进行多线程的管理，以响应每个客户的请求。同时，各个控制对象也有自己单独的线程。对于持久服务，我们也将采用多线程机制保证其响应性。
此处插入软件设计模型文档中的图12-96。
12．3．1．4．5 系统实现视图
1）系统开发环境
开发环境：Eclipse。
Android Studio2．0。
开发语言：Java。
2）系统开发模型
本系统中按照组件图进行了相应的软件文件定义，因此，系统开发模型与12．3．1．4．3节中的组件图一致。
12．3．1．4．6 系统物理视图
此处插入软件设计模型文档中的图12-97。
硬件配置要求：
（1）User machine：一台配有1GHz双核处理器及1GB内存（或以上）的手机。为保证较为良好的用户体验，此为流畅运行大多数安卓应用程序的最低配置。
（2）Application Server：两台（或更多）具有双核心corei系列处理器，配以4GB（或以上）内存、100GB（或以上）存储空间的服务器。为保证系统高负荷时正常运作，management与database分别运行在不同的服务器上，因此需要至少两台服务器。初期在用户数量不太多的情况下，服务器配置不需要过高，一般计算机性能即可满足。
（3）网络：30Mbps的互联网络。由于控制存储分开，需要在服务器之间进行大量的数据交换，因此需要较大的带宽。
12．3．1．4．7 边界条件设计
通过定义启动、关闭用例来考虑边界条件。
1）启动服务器Start Server（见图12-55）
（1）用户在服务器上点击应用程序图标。
图12-55 启动服务器用例实现
（2）启动Server Com对象。
（3）启动持久服务Persistent Service对象。
（4）依次启动Server Purchase Control、Server Item Control、Server User Control、Server Dialog Control对象，同时把Server Com对象、Persistent Service对象的引用传给这些对象。
（5）启动Rong Cloud SDK。
2）关闭服务器Stop Server（见图12-56）
（1）用户点击应用的关闭按钮。
（2）系统删除Rong Cloud SDK、Server Dialog Control、Server User Control、Server Item Control、Server Purchase Control对象。
（3）系统断开与数据库连接，删除Persistent Service对象。
图12-56 关闭服务器用例实现
（4）系统删除Server Com对象。
3）启动App用例（见图12-57）
（1）用户点击App图标。
（2）系统启动Main Page对象。
（3）Main Page对象启动Http Util对象。
（4）Main Page对象启动Rong Cloud SDK。
（5）Main Page对象启动Dialog Adapter、Purchase Adapter、Item Adapter、User Adapter，并把Http Util对象传给它们。
（6）Main Page对象启动Client Dialog Control、Client Item Control、Client User Info Control、Client Purchase Control对象，并分别把 Dialog Adapter、Item Adapter、User Adapter、Purchase Adapter对象的引用传给它们，同时把Rong Cloud SDK对象引用传给Client Dialog Control。
（7）Main Page对象启动Login Page对象，同时把Client User Info Control传给Login Page。
4）关闭App（见图12-58）
（1）通过手机关闭App。
（2）依次关闭各个Client Control对象。
（3）依次关闭各个Adapter对象。
（4）关闭Rong Cloud SDK对象、Http Util对象。
（5）关闭Main Page对象。
5）异常情况
（1）系统在出现异常情况下，重启App或者Server即可以。
（2）数据库本身靠事务特性维持其正确性。
12．3．1．4．8 数据管理设计
由于本系统带有大量的用户、订单以及商品信息，基于文件的系统无法适应，因此，我们选择使用关系数据库存储信息。
1）用户信息表User Info（见表12-11）
表12-11 用户信息表User Info
2）物品信息表User Info（见表12-12）
表12-12 物品信息表User Info
3）订单信息表Order（见表12-13）
表12-13 订单信息表Order
4）物品类别表Item Type（见表12-14）
表12-14 物品类别表Item Type
5）收藏物品列表Favored List（见表12-15）
表12-15 收藏物品列表Favored List
6）对话信息表（见表12-16）
表12-16 对话信息表
7）对话内容表（见表12-17）
表12-17 对话内容表
实体类设计类图如图12-59所示。
图12-59 实体类设计类图
12．3．1．4．9 其他设计
（1）访问控制和安全设计（见表12-18）。登录用户在使用他们的权限之前需要先提供用户名和登录密码，经检查是匹配的才通过认证。
表12-18 访问控制和安全设计
（2）可靠性设计。为了提高系统的可靠性，我们考虑采取冗余与备份的方案。设置备用服务器，在主服务器发生故障时将系统运行切换至备用服务器上；数据库冗余并备份，防止数据的丢失与意外更改。
12.3.2 软件设计模型
12．3．2．1 引言
1）编写目的
本软件设计模型文档的编写目的是将二手商品交易平台软件的各种设计模型进行绘制和整理，在之前的需求规约、系统分析的基础上，详细展示系统的结构，为后续的软件实现工作奠定基础。文档将围绕系统用UML语言，构造逻辑视图、实现视图、进程视图、部署视图等。本文档用于开发团队明确系统的设计模型，并以之为依据进行开发工作。
2）适用范围
本文档适用的软件：校园二手商品交易平台。
与该软件相关的特性、子系统、模型等均符合本文档中的内容。
3）定义
本文件中涉及的术语定义在项目词汇表（词汇表．docx）中给出。
4）参考资料
《面向对象软件工程——使用UML、模式与Java》（第3版），清华大学出版社，2011。
5）概述
本文档包括用例视图、逻辑视图、实现视图、进程视图和部署视图5个部分的模型。用例视图展现系统包含的用例。逻辑视图主要包括系统架构图、设计类图和用例的实现。实现视图针对每个子系统构建组件图。进程视图用类图和组件图表示系统的进程和线程。部署视图展现系统的软硬件部署。本文件的各部分内容联系紧密，互为补充和对照，共同呈现本软件的设计模型。
12．3．2．2 用例视图
插入软件需求规约文档中的图12-7。此处为节省篇幅略去。在实际的文档中，为了文档的完整性、自包含性，将把图12-7复制在此处。
12．3．2．3 逻辑视图
1）系统结构
系统架构包图如图12-60所示。整个系统分为6个子系统，分别是用户接口子系统、用户管理子系统、物品管理子系统、购买管理子系统、通信交流子系统以及公共服务子系统。
图12-60 系统架构图
每个子系统的包图如下：
（1）用户接口包的类图（见图12-61）。
图12-61 用户接口包类图
（2）用户管理包的类图（见图12-62）。
图12-62 用户管理包类图
（3）物品管理包的类图（见图12-63）。
图12-63 物品管理包类图
（4）购买管理包的类图（见图12-64）。
图12-64 购买管理包类图
（5）通信交流包的类图（见图12-65）。
图12-65 通信交流包类图
（6）公共服务包的类图（见图12-66）。
图12-66 公共服务包类图
3）设计类图
由于类比较多，因此按照包列出其对应的类图。
（1）用户接口子系统（见图12-83）。
图12-83 用户接口子系统设计类图
（2）用户管理子系统（见图12-84）。
图12-84 用户管理子系统设计类图
（3）物品管理子系统（见图12-85）。
图12-85 物品管理子系统设计类图
（4）购买管理子系统（见图12-86）。
图12-86 购买管理子系统设计类图
（5）通信交流子系统（见图12-87）。
图12-87 通信交流子系统设计类图
（6）公共服务子系统（见图12-88）。
图12-88 公共服务子系统设计类图
4）其他图
插入软件需求规约文档中的图12-42和图12-43。此处为节省篇幅略去。在实际的文档中，为了文档的完整性、自包含性，需要将把图12-42和图12-43复制在此处。
12．3．2．4 实现视图
1）开发模型构成
（1）用户接口子系统（见图12-89）。
图12-89 用户接口子系统开发模型
（2）用户管理子系统（见图12-90）。
图12-90 用户管理子系统开发模型
（3）物品管理子系统（见图12-91）。
图12-91 物品管理子系统开发模型
（4）购买管理子系统（见图12-92）。
图12-92 购买管理子系统开发模型
（5）通信交流子系统（见图12-93）。
图12-93 通信交流子系统开发模型
（6）公共服务子系统（见图12-94）。
图12-94 公共服务子系统开发模型
2）编译后系统
本系统中每一个j．ava文件将编译生成对应的．class文件。因此，编译后组件图与开发视图一致，因而图12-89到图12-94略去。在实际开发中，经常多个文件编译后生成一个文件，需要针对编译后生成的组件重新画组件图。
12．3．2．5 进程视图
1）客户端进程视图（见图12-95）
在Client端，为了保证用户体验，UI线程只负责边界对象与用户的交互。同时对每一个控制器单独启动一个线程。同时对于通信模块，也启动一个线程。这样的设计能够保证前台、功能实现、通信不会阻塞应用的运行。
图12-95 客户端进程视图
2）服务端进程视图（见图12-96）
图12-96 服务端进程视图
服务端进程设计中，对于通信部分，将依据请求的并发性，进行多线程的管理，以响应每个客户的请求。同时，各个控制对象也有自己单独的线程。对于持久服务，我们也将采用多线程机制保证其响应性。
12．3．2．6 部署视图
本系统是一个移动应用系统。因此客户端是手机上运行的App，后台提供服务器，同时通过数据库服务器进行数据存取（见图12-97）。
图12-97 部署视图
