目录
一、背景介绍
如今随着互联网的迅速发展，各种“互联网+”产业不断出现在市场中。对于想要购买东西的人来说，挨家挨户的去货比三家不仅浪费力气而且浪费时间最后可能还无法购买到自己需要的物品，因此“互联网+”购物的模式也就应运而生。
以上也就是我们俗称的电商，本项目即对电商基础电子商务购物管理系统的概述。
二、需求
2.1功能需求
2.1.1交易管理[网上下单]（消费者）
· 登录：对消费者输入的账号和密码进行验证。
· 注册：要求提供部分资料，包括姓名，性别，电话等。
· 个人信息修改：登录后可以对昵称等身份信息和密码进行修改。
· 商品的浏览：可以对商品进行浏览（无需注册登录）。
· 商品购买：选择所需商品；填写收件人信息，包括收件人姓名，收件人电话，收件地 址；确认订单（向系统提交订单）；货到后确认收货。
2.1.2商品管理（商家）
· 登录：对商家输入的账号和密码进行验证。
· 注册：要求商家提供部分资料，包括姓名，性别，电话等。
· 个人信息修改：登录后商家可以对个人信息包括密码进行修改。
· 商品管理：商家对相关商品的上架，下架或是对商品信息（名称，类型，库存...）
的修改。
2.1.3用户管理（管理员）
· 管理员登录（管理员不能注册，但可以修改密码）
· 用户信息管理：当用户存在违规操作时对用户账号进行封号处理，用户信息的修改等。
【使用者特点概述：】
～用 户：年龄段跨度较大，需要考虑到部分用户无法进行难度较高或者不易理解的交互行为，需 要界面的简单化和整洁化（考虑到用户体验），并且需要提供操作指南，帮助用户快速上 手本系统。
～管理员：无需考虑使用问题，尽量注意功能的方便操作即可。
图2.1 系统功能图
2.2非功能需求
表2.2 非功能性需求优先级
| 序号 |
用例/质量需求项名称 |
优先级 |
说明 |
| 1 |
登录 |
高 |
必须完整实现 |
| 2 |
注册 |
高 |
必须完整实现 |
| 3 |
个人信息修改 |
中 |
尽量实现 |
| 4 |
商品浏览 |
中 |
尽量实现 |
| 5 |
商品购买 |
高 |
必须完整实现 |
| 6 |
商品管理 |
高 |
必须完整实现 |
| 7 |
用户信息管理 |
高 |
必须完整实现 |
| 8 |
性能：Req-Performance-001~002 |
高 |
对产品的接受度影响很大 |
| 9 |
可靠性：Req-Peliability-001~003 |
高 |
同上 |
| 10 |
易用性：Req-EasyUse-001~002 |
中 |
对产品的接受度有一定影响 |
| 11 |
安全性：Req-Authentication-001 |
高 |
对产品的接受度影响较大 |
| 12 |
安全性：Req-Authorization-001 Req-Audit-001 |
中 |
对产品接受度有一定影响 |
| 13 |
兼容性：Req-Compatibility-001 |
低 |
可以不实现，但实现可提高接受度 |
| 14 |
兼容性：Req-Compatibility-002 |
中 |
对产品接受度有一定影响 |
| 15 |
本地化与国际化：Req-Intl-001 |
低 |
可以不实现，但实现可提高接受度 |
三、可行性分析
3.1运行可行性
· 信息：输出方面不缺少相关信息（无论是必要信息还是有关信息），不存在信息超载的情况，可以确保商品信息的正确和时效性（及时更新信息）。能够及时的收集有用的信息，这方面也确保了上一条的实现。确保能够有效且高效的存储使用数据。
· 经济：经费来源已经明确，仍然拥有待开发的市场份额，能保证订单的实现。
· 效率：任务所需工作量即人力物力均在可控范围内，不存在大量的冗余或是不足。
· 服务：能够基本保证系统的正常运行，各个功能的正常使用，系多次实验保证统的反应结果可靠且一致。系统操作简单，易上手，适合普遍用户使用。能够保证系统对变化的及时反应，以及对新状况的快速应对。
3.2文化可行性
开发团队及均支持系统的研发。管理人员可能介意无法注册新的管理员，可以后期修改添加注册功能，如果有需要的话（原则上管理员1～2个足够，有需求的化可以再添加）。本系统较为稳定，基本不存在太大变化，大大降低了使用者的难度和学习上手难度。
3.3技术可行性
本系统研发使用的技术均为已有的成熟技术或框架，不存在实际与否的疑问。团队中的技术人员均已熟练掌握相关技术。暂时不需要技术专家，开发时间充足，暂时无需担心进度问题。
3.4进度可行性
项目的研发时间充裕，期限合理，不存在项目过大但时限紧张导致项目进度紧张乃至项目完成度低的情况。存在两个项目期限，即期望期限和最后期限。按照期望期限规划任务进度，也为任务进行可能遇到的各种问题预留解决时间（即期望期限到最后期限之间的时间）。
3.5经济可行性（这部分不太懂，仅供参考）
表3.5.1 电商购买管理系统方案的成本分析
| 序号 |
项目 |
详情 |
费用 |
总成本 |
| 1 |
人员 |
前端程序员*1 |
150h*42¥ |
6,300¥ |
| 2 |
后端程序员*1 |
200h*50¥ |
10,000¥ |
|
| 3 |
系统架构师（兼分析员）*1 |
400h*55¥ |
22,000¥ |
|
| 4 |
软硬件 |
开发服务器 |
/ |
20,000¥ |
| 5 |
开发软件 |
/ |
12,000¥ |
|
| 6 |
其他 |
办公用品，电费等... |
/ |
15,000¥ |
表3.5.2 电商购买管理系统方案的净现值分析
| 现金流分配 |
第0年 |
第1年 |
第2年 |
第3年 |
第4年 |
第5年 |
||||
| 开发成本 |
¥85,300 |
/ |
/ |
/ |
/ |
/ |
||||
| 维护成本 |
/ |
¥5,000 |
¥7,500 |
¥9,200 |
¥10,000 |
¥12,000 |
||||
| 12%的贴现率 |
1.000 |
0.897 |
0.795 |
0.715 |
0.653 |
0.567 |
||||
| 保留价值 |
¥85,300 |
¥4,485 |
¥5,962.5 |
¥6,578 |
¥6,530 |
¥6,804 |
||||
| 总成本 |
¥115,659.5 |
|||||||||
| 收益 |
¥0 |
¥35,000 |
¥47,000 |
¥58,000 |
¥68,500 |
¥69,000 |
||||
| 总收益 |
¥277,500 |
|||||||||
| 净收益 |
¥161,840.5 |
|||||||||
四、系统分析
4.1用例分析
图4.1.1 电商购物管理系统用例图
用例名称： 商品的购买
业务目标： 用户选择心怡的商品并对已经确认好或者放入购物车的商品进行购买。
执行者： 消费者
触发条件：点击购买等相关按钮
前置条件：消费者身份验证通过
基本动作序列：1.用户身份验证
2.购买商品
2.1用户选择指定商品
2.2点击购买按钮
2.3填写收件人信息
2.4进行付款
3.界面显示购买成功
图4.1.2 商品购买的活动图
4.2数据模型（ERD）
图4.2.1 数据模型图
4.3过程模型图（DFD）
图4.3.1 上下文数据模型图
图4.3.2 功能分解图
图4.3.3 购物订单响应事件图
图4.3.4 购物基本图
4.4分析时的类模型
图4.4 分析类图
五、系统设计
5.1体系结构设计
图5.1.1 部署图
5.2一个设计用例的详细说明
| 用例名称 |
商品的购买 |
用例类型： 系统设计 R️ |
| 优先权 |
高 |
|
| 主要业务参与者 |
消费者 |
|
| 主要系统参与者 |
消费者 |
|
| 其他参与者 |
商家 |
|
| 描述 |
本用例描述本系统的使用者之一消费者通过商品的购物操作或者购物车中多项勾选来下单购买所选中的商品。消费者可以直接在浏览商品的时候点击相应所需商品的购买键进行购买（前提是在登录状态，如果浏览商品为游客状态，购买时会提示用户登录），然后填入收件人手机号地址确认订单，付费后提交订单。 |
|
| 前提条件 |
消费者需要处于已登录状态。 |
|
| 触发器 |
消费者点击购买按钮时，用例被触发 |
|
| 典型事件过程 |
参与者动作 |
系统相应 |
| 第1步：消费者选择需要的商品。 第3步：消费者点击样品展示图查看全屏图片，确认细节后再次点击返回详情界面，通过样式栏选择对应商品及商品个数，可以使用“立即购买①”按钮或者“加入购物车②”按钮。 第5步：①消费者确认订单内容（包括收件人信息，商品信息等），确认无误后点击付款按钮。 ②消费者通过购物车logo切换到购物车可以查看购物车内商品简介及数量。点击管理按钮勾选商品后可以使用“移除”，“购买”按钮。 第9步：消费者点击确认付款完成操作。 |
第2步：系统相应，显示商品详情界面（包括商品的名称，样品展示，评价，样式，价格，相关操作等） 第4步：根据操作为展示全屏清晰商品图和退出全屏。①当消费者选定某个商品和数量后，展示订单确认界面，要求消费者填写收件人姓名，电话，收件地址等。②当消费者选定某个商品和数量后，将该商品及其对应的数量添加到购物车的列表中（在购物车界面可以查看）。 第6步：①系统响应消费者动作，显示付款界面，消费者可以选择付款方式以及查看付款总金额。将 ②显示购物车界面，根据消费者操作移除被勾选商品或者切换到6①步。 第7步：系统记录订单信息。（为后面的退单和订单查询功能提供数据。） 第8步：显示订单明细和订单状态（已结算/待结算） 第10步：系统将订单传递到商家界面。 |
|
| 结论 |
当消费者看到下单成功字样，该用例结束。 |
|
| 后续条件 |
订单提交到商家方，并且留下记录（由于库存不足无法购买，此处不需要考虑库存问题）。商家根据订单信息发货给消费者。 |
|
| 业务规则 |
·消费者需要在规定时间内付款完成订单提交，否则订单将会提交失败。 ·商家需要在规定时间内发货，当消费者确认收货后，才算完成订单钱货两清。 |
|
| 实现约束和说明 |
·用例需24h对用户开放 ·频率：考虑到后期的推广，至少需要满足100个并发用户 |
|
| 假设 |
·消费者可以随时取消订单 ·记录每一笔消费订单保证有迹可循 |
|
| 开放问题 |
无 |
|
5.3设计类模型
5.3.1 消费者购买商品设计类
5.3.2 商家处理订单设计类
5.3.3 管理员管理用户设计类
5.4系统的应用架构
5.4.1 系统的应用架构图
5.5数据库模型图
5.5.1 部分数据库模型图
5.6设计阶段的类交互图
5.6.1 消费者购买商品设计阶段时序图
5.6.2商品类的状态图
六、参考文献
[1]Jeffrey L. Whitten Lonnie D.Bentley. Systems Analysis and Design Methods Seventh Edition[M]系统分析与设计方法