UML实践报告校园二手交易系统Word文档下载推荐.docx
- 文档编号:16328316
- 上传时间:2022-11-22
- 格式:DOCX
- 页数:25
- 大小:196.06KB
UML实践报告校园二手交易系统Word文档下载推荐.docx
《UML实践报告校园二手交易系统Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《UML实践报告校园二手交易系统Word文档下载推荐.docx(25页珍藏版)》请在冰豆网上搜索。
李清伟
1.用户的注册与登录
2.浏览商品信息:
游客仅可查看商品图片和简介,注册用户才可查看详细信息
3.商品搜索
4.注册用户信息管理中心:
包括修改个人信息,发布或删除二手商品
5.留言系统:
用户留言后会消息推送给商品发布者
6.评价系统:
双方完成交易后要给评价
7.管理员功能:
管理用户信息,修改添加删除不符合规定的商品,管理留言等信息
8.投诉功能:
用户可以进行投诉或提交意见
9.公告信息:
最新商品推荐,活动分享
1.2系统非功能性需求
二手交易系统非功能性需求文档
1.简要说明
本文档列出二手交易系统的所有非功能性需求
2.可用性
(1)二手交易对于大学生来说非常重要,所以用户数量可以得到保障
(2)该系统具有友好的操作逻辑,帮助用户顺利使用该系统
(3)该系统采用C/S模式,对客户端的配置要求不高
3.可靠性
(1)严格按照合同法、专利法、知识产权保护法等对该系统进行开发。
不会触犯国家法律,和他人的利益,所以在法律上是可靠的
(2)由于是本地化的系统,安全隐患不会太大,用户都是本校师生,也仅对本校师生开放系统
4.性能
(1)要求服务器能同时承受10000人同时使用,系统的响应时间应该小于1秒
(2)系统要求能支持多种常见浏览器和移动操作平台
5.可支持性
无
6.设计约束
系统使用C#语言开发,数据库系统使用SQLServer数据库管理系统
7.帮助系统需求
要求系统提供在线帮助,常见问题说明,意见反馈和人工服务
8.购买构建需求
9.接口需求
此系统要求能和支付宝等第三方交易平台或银行系统进行连接
10.许可需求
11.其他需求
2.需求分析
2.1系统执行者
该系统提供给在校大学生使用,同时还需要管理员维护系统,所以执行者为用户和管理员
2.2系统用例
2.2.1用户操作
a)用户注册
b)用户登录
c)物品发布与修改
d)留言
e)浏览商品
f)加入购物车
g)提交订单
h)通过网银系统或线下交易付款
i)交易完成后的评价评分
2.2.2管理员操作
a)管理员登录
b)管理用户信息
c)管理用户留言和评论内容
d)管理订单
e)发布修改促销优惠
f)处理用户投诉和反馈信息
2.3用例与执行者之间的关系
3.需求描述
本系统目标是为了实现网站的二手商品的在线交易。
通过系统实现二手物品交易的多项功能,其中主要是管理员对商品的管理实现和用户的购物的实现:
前台:
用户在线浏览所有商品,按需求搜索相关商品,以及注册为会员后对商品选购的操作,购物结束后生成订单信息的功能,还可以发布修改个人二手商品。
后台:
管理员对用户注册信息进行管理,对用户购物订单的处理,以及管理员对网站新闻、公告的维护操作。
系统对从用户购物、生成订单,管理员从管理用户、管理网站、管理商品,处理订单等功能都一一实现。
建成一个功能齐全、合理、完善的二手物品交易网站。
3.1系统用例图
3.1.1用户系统用例图
3.1.2管理员系统用例图
3.1.3支付系统用例图
3.2用例描述
二手交易系统——用户系统用例
2013-6-5
本用例描述用户进入系统后的操作过程
2.事件流
(1)基本流
1.用户通过系统注册账号并且登录
2.用户通过个人中心页面发布商品或修改商品信息,查看评论和留言
3.通过首页检索选择要购买的商品
4.给卖家留言
5.加入购物车并提交订单
6.系统通过商品优惠数据计算优惠金额
7.用户选择支付方式
8.系统显示用户该次购买成功信息
9.用户确定交易完成后双方提交评价结束该次购买
(2)备选流
5.a如果顾客取消订单,系统给出提示并关闭订单结束
7.a用户选择在线支付却没有付款,系统给出提示并保留订单,等待用户支付
3.特殊需求
需要系统能和银行系统连接,获得用户付款信息
4.前置条件
用户必须成为系统注册用户才能登录才能执行上述操作
5.后置条件
6.扩展点
7.相关的数据
用户提交的订单、评价和留言信息
8.问题说明
二手交易系统——管理员系统用例
本用例描述管理员的操作流程
1.管理员登录后台管理系统
2.管理用户数据和留言
3.处理受争议订单
4.添加修改商品促销优惠信息
5.管理支付信息
6.完成管理退出系统
管理员在处理受争议订单时须和买卖双方进行商讨
管理员必须是系统注册管理员,登录后才能进行管理员操作
二手交易系统——支付系统用例
本用例描述用户支付的操作流程
1.用户选择商品提交订单
2.选择支付方式
3.进入网银系统进行支付
4.完成支付网银系统反馈支付信息
3.3概念层类图或对象图
4.需求评审
项目名称
校园二手交易系统
评审日期
2013-06-07
项目编号
001
评审方式
浏览文档
项目类型
合同项目:
自主项目:
1、特殊项目 2、一般项目 3、小型项目√
评审意见:
文字介绍清楚,图也清晰,通过
经办人:
李清伟 日期:
2013年6月7日
评审结论:
通过
评审负责人:
李清伟 日期:
批准意见:
批准人:
李清伟 日期:
三、概要设计
概要设计主要完成系统的功能设计和对外接口设计。
在功能设计中,最重要的是对每个功能的执行过程以及对象交互的分析。
1.系统顺序图
1.1顺序图
o用例的需求
用户购物流程以及管理员操作
o需求中涉及的对象
▪用户购物
▪用户
▪验证页面
▪商品详细页面
▪联系卖家
▪订单页面
▪支付页面
▪交易完成评论与评分
▪退出系统
▪管理员操作
▪管理员
▪商品管理
▪用户信息管理
▪订单信息管理
▪留言与评论管理
▪促销公告发布与修改
▪后台管理页面
o对象间的消息的传递
▪用户购物顺序
消息
发送对象
接收对象
输入登录信息
用户
验证页面
浏览商品
商品详情页面
购买商品
订单页面
询问
供货方
确定购买
确定付款
支付页面
交易成功
评论
交易不成功
退出
交易完成
▪管理员操作顺序
管理员
登陆成功
后台管理页面
验证操作
商品管理
用户管理
订单管理
评论管理
促销公告发布修改管理
o顺序图
▪用户购物顺序图
▪管理员操作顺序图
2.系统协作图
o协作图元素
o各元素间关系
元素间关系见下图
o实例层协作图
▪用户购物协作图
▪管理员操作协作图
3.系统状态图
3.1用户状态图
3.2管理员状态图
4.系统活动图
4.1用户活动图
4.2管理员活动图
5.说明层类图
6.概要设计评审
四、系统详细设计
1.实现层类图设计
2.包的设计
3.系统构件图设计
在分析阶段,构件图表达的UML是现实世界中的实体。
它是软件系统的一个物理单元,它驻留在计算机中而不是只存在系统分析员的脑海里。
构件之间存在的唯一关系是构件的依赖性。
构件依赖性指一个构件依赖于另一个构件。
构件依赖性画成构件之间的虚线箭头。
如下图箭头指的构件表示被依赖,也就是说Cart、Eshop、Checkout都依赖于ShoppingServlet。
下图描述的是在网上购物系统中几个构件之间的依赖关系。
4.详细设计评审
五、系统部署图
部署图描述系统硬件的物理结构以及在此结构上执行的软件。
部署图可以显示计算节点的拓扑结构和通信路径、结点上运行的软件组件、软件组件包含的逻辑单元等。
部属图常常用于帮助理解分布式系统。
在网上购物系统中,我们可以从网络上开始划分结构,该系统分为三层结构,分别针对数据库、服务器、和客户机。
下图显示了网上购物系统的主要部属。
六、教师评定
评语:
成绩:
教师签名:
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- UML 实践 报告 校园 二手交易 系统
![提示](https://static.bdocx.com/images/bang_tan.gif)