UML网上购物系统建模.docx
《UML网上购物系统建模.docx》由会员分享，可在线阅读，更多相关《UML网上购物系统建模.docx（28页珍藏版）》请在冰点文库上搜索。
UML网上购物系统建模
网上购物系统
小组成员介绍：
组员：
楚家明学号：
20207790207
组员：
苗高升学号：
20207790233
系统目录：
一、用例分析
二、系统要紧用例图
三、要紧用例规约
四、系统类图
五、系统序列图
六、系统协作图
七、系统活动图
八、系统状态图
九、系统构件图
十、系统部署图
十一、总结
一、用例分析：
本系统有6个用户：
一般用户，会员，治理员，在线效劳员，财务人员，仓库人员
一般用户：
一般用户登岸本系统后能够注册成为会员，查看商城中的商品信息，有疑问的时候能够在线求助，而且能够查看会员给商家的留言！
会员：
会员具有相关于一般用户较多的功能：
能够再商城中购买商品，其中购买商品时需填写定单，提交定单，选择付款的方式（信誉卡，现金，支票，借记卡等）。
能够治理自己的购物车，包括查看、增加、删除购物车中的商品。
能够治理自己的信息，包括查看，修改，添加，删除，并支持修改密码，找回密码，重置密码。
治理员：
治理员要紧负责对系统信息的保护和治理，包括复查商品信息是不是正确，治理会员，能够查看所有会员的大体信息或删除会员，查看交易过的定单，治理留言，能够恢复留言。
在线效劳人员：
要紧负责和系统客户的交流，更好的为客户效劳。
财务人员：
财务人员能够处置会员提交的定单，假设未发货，那么依照用户所提交的定单打出相应的发票。
还能够查看商品的价钱信息，能够依照市场需求对商品的价钱进行改动。
仓库人员：
仓库人员依照定单发货并更改定单的状态，并负责查看并随时更新商品的库存信息。
二、系统主用例图：
三、要紧用例规约：
一般与用户注册：
主要参与者
普通用户
用例说明
完成普通用户向会员的转变，使顾客拥有更多的权限更完善的服务
前置条件
系统正常运行
主成功场景
1、客户打开系统进入购物页面，点击注册按钮
2、用户进入顾客注册页面
3、顾客填写注册信息、点击提交
4、系统管理员验证顾客的所有注册信息是合法
5、系统返回用户注册成功信息
扩展流
1、顾客填写信息不合法，提交失败
2、系统返回失败原因
后置条件
系统的数据可中增加一条顾客的信息
角色登录：
主要参与者
会员，管理员，在线服务员，财务人员，仓库人员
用例说明
使角色登陆系统，获得相应权限，从而管理或使用系统
前置条件
系统正常运行
主成功场景
1、角色打开系统，进入登陆页面
2、选择与自己相对应的角色
3、输入用户名称和密码以及验证码，点击登录
4、检测用户登录信息
5、系统提示登陆成功
扩展刘
1、角色多填写的登录信息不正确
2、系统返回登录失败的原因，并提示角色是否继续登录
后置条件
系统根据不同的用户角色跳转到与其相对应的页面
查找商品信息：
主要参与者
普通用户，会员，管理员，在线服务员，财务人员，仓库人员
用例说明
为系统用户提供便利的服务
前置条件
系统正常运行
主成功场景
1、用户（此为系统用户的简称）打开系统，进入查询页面（此页面不是只有查询工能，查询功能是嵌套在系统页面中的，例如商品浏览页面）
2、选择所查找商品的类型（可不选，不过相对来说查找速度会慢一些），可选择性的输入商品的商品号或者商品名称，也可同时输入
扩展流
1、未查找到指定商品信息
2、返回查找失败信息、提示是否继续查找
后置条件
系统显示所查找的商品信息（可能是多条）
在线求助：
主要参与者
普通用户、会员
用例说明
系统为商家提供更好的交流环境
前置条件
系统正常运行
主成功场景
1、客户对商品信息或其他有疑问
2、点击在线求助
扩展流
在线服务员繁忙，系统提示稍后再试
后置条件
系统弹出对话框，互动完毕后对话框关闭
在线交易：
主要参与者
会员
用例说明
此为系统的主要功能，复员可以通过系统购买自己想要的商品
前置条件
系统正常运行，会员已成功登陆
主成功场景
1、会员选择自己满意的商品，加入购物车，确定购买后，点击购买
2、系统跳入订单填写页面，会员填写自己的基本信息确定价格后点击提交订单
3、系统跳转到支付方式页面，选择支付方式
4、确认支付后填写验证信息
5、系统检验验证信息
6、交易完成
扩展流
交易失败，系统返回时报信息
后置条件
系统数据库中增加一条订单信息
治理个人大体信息：
主要参与者
会员，在线服务员，仓库管理人员，财务人员
用例说明
系统的不服用户可以对自己的信息进行查看、添加、修改、删除、操作
前置条件
系统正常运行，已登录
主成功场景
1、用户（此为用例参与者）点击个人信息管理
2、系统跳转到用户基本信息页面，此时信息为只读状态，显示用户的基本信息
3、用户想要修改信息时，点击修改
4、系统跳转到修改信息页面，此时信息为可写状态
5、用户按照自己的情况修改信息
6、确认完成后点击提交
7、系统提示修改信息成功并显示修改后的信息
扩展流
1、修改信息失败
2、系统提示提交失败信息，并跳转到信息只读状态
后置条件
系统数据库中关于用户的信息有更新
修改密码：
主要参与者
会员，在线服务员，仓库管理人员，财务人员
用例说明
假如用户（此指本用例的住参与者）感觉自己的账户有安全威胁，可通过修改密码的方式来保证自己账户的安全
前置条件
系统正常运行，已登录
主成功场景
1、用户点击“修改密码”
2、系统跳转到修改密码的页面
3、用户需填写原密码，新密码和验证信息
4、填写完成后提交信息
5、系统检测密码，验证信息
6、密码修改成功
扩展流
1、修改密码失败
2、系统返回错误信息
后置条件
系统数据库中响应用户的密码有更新
密码找回：
主要参与者
会员，在线服务员，仓库管理人员，财务人员
用例说明
假如用户（此指本用例的住参与者）因为某种原因将自己的密码忘记了，可通过本用例进行密码找回
前置条件
系统正常运行
主成功场景
1、用户打开系统
2、进入登陆页面、点击“找回密码”
3、系统跳转到找回密码的页面
4、用户根据要求填写验证信息
5、提交验证信息
6、系统检测验证信息
7、验证通过
8、指定时间段内将密码发送至绑定邮箱内
扩展流
1、找回密码失败
2、系统将失败信息发送到绑定邮箱中，询问是否重置密码
密码重置：
主要参与者
会员，在线服务员，仓库管理人员，财务人员
用例说明
假如用户（此指本用例的住参与者）因为某种原因无法最缺想起自己的验证信息，可通过本用例向系统管理员提出重置密码的申请
前置条件
系统正常运行
主成功场景
1、用户打开系统
2、进入登陆页面，点击“密码重置”
3、系统跳转至重置密码的界面
4、用户根据要求填写其他的验证信息，当然这种信息会更详细
5、用户提交验证信息
6、系统验证信息
7、验证通过
8、系统在指定时间段发送邮件至用户绑定邮箱，需用户登陆绑定邮箱后手动激活重置
9、系统提示充值成功，并立即将随机生成的重置密码发送给用户并将重置密码所需的验证信息初始化，并提醒用户立即修改密码，用户在次重置密码时需设置验证信息
扩展流
1、重置密码失败
2、系统发送失败信息至用户绑定信息，并询问用户是否继续申请
后置条件
系统数据库重置相应用户的密码和验证信息
治理购物车：
主要参与者
会员
用例说明
会员可以管理自己的购物车，按照自己的需求更改，增加或者删除购物车中的商品
前置条件
系统正常运行，会员登录
主成功场景
1、会员点击购物车
2、系统跳转至购物车页面
3、用户根据自己的情况对购物车进行添加，修改，查看，删除商品操作
4、4、若改动购物车中的信息则操作完成后显示操作成功
扩展流
1、修改购物车商品信息失败
2、系统显示错误信息
后置条件
系统数据库中与客户关联的购物车信息做出相应的变动
会员治理定单：
主要参与者
会员
用例说明
在本用例中，会员可以查看或查找自己所有订单的信息，以及修改订单的状态（是否到货），当然订单的其他信息会员是无权修改的
前置条件
系统正常运行、会员已登录
主成功场景
1、会员点击“我的订单”
2、系统跳转到该用户的订单页面
3、用户可以查看，修改自己的订单，如果订单过多，可查找，其中修改是指只能修改订单的状态，也就是是否到货
4、若修改信息则需要填写验证信息
5、提交修改信息
6、系统检验验证信息
7、提示修改成功
后置条件
系统数据库中与会员相关联的订单信息做出相应的更新
查找定单：
主要参与者
会员，财务人员，管理员、仓库人员
用例说明
但订单过多的是否可以通过此用例快速的找到需要的订单
前置条件
系统正常运行，用户（此为此用例的主要参与者）已登录
主成功场景
1、进入显示订单页面
2、点击“查找”
3、输入订单信息，如：
订单号，订单状态
4、查找成功
5、系统将符合订单显示在页面上
扩展流
1、查找失败
2、系统显示查找失败信息
后置条件
系统显示符合的订单
会员留言：
主参与者
会员
用例说明
当客户对商家存在意见或建议时，可通过此方式提出，且此留言其他用户也可以看到，能让其他用户更好地了解商家
前置条件
系统正常运行，会员已登录
主成功场景
1、会员点击“留言”
2、系统跳转到留言界面
3、会员填写留言
4、会员提交留言
5、系统提示留言成功
扩展流
1、留言失败
2、系统返回留言失败信息（包含非法信息）
后置条件
系统数据库中的留言表内增加一条记录
开发票：
主要参与者
财务人员，管理员，仓库
用例说明
财务人员根据用户提交的订单制作电子版发票并将其打印，然后将电子版发票纸质发票分别提交给仓库和管理员审核通过后的发票将同商品一起发给会员
前置条件
系统正常运行，财务人员已登录
主成功场景
1、财务人员查看订单状态
2、若订单状态为已付款，点击生成发票
3、系统成功生成发票
4、点击审核
5、审核通过
6、点击打印发票
7、打印发票成功
8、订单状态改变为已生成发票状态
扩展流
1、生成发票失败，系统返回失败信息
2、审核失败，系统返回失败信息
3、打印失败，系统返回失败信息
后置条件
系统数据库中订单状态发生改变
仓库人员治理定单
主要参与者
仓库人员
用例说明
仓库人员可以通过此用例查看和更改订单的状态
前置条件
系统正常运行，仓库人员登录
主成功场景
1、仓库人员点击查看订单
2、系统显示财务人员提交过来的订单
3、仓库人员查看订单的审核情况
4、订单通过了财务和管理员的审核
5、仓库人员审核订单
6、审核通过
7、仓库人员根据发票和订单发货
8、仓库人员更改订单状态为已发货
扩展流
审核失败，系统返回错误信息
后置条件
系统数据库中订单状态有更新
保护商品信息：
主参与者
管理员，财务人员，仓库人员
用例说明
用户（此指本用例的主要参与者）可以通过本用例更新商品的信息
前置条件
系统正常运行，用户已登录
主成功场景
1、用户点击查看商品信息
2、系统跳转到商品信息界面
3、用户可以再此页面点击“更新”“下架”“上架”
4、系统跳转到相应的页面
5、操作完成后用户点击提交
6、系统提示操作成功
扩展流
1、操作失败
2、系统返回失败信息
后置条件
系统数据库中有更新
四、系统类图：
五、系统序列图：
查看购物车：
查找商品：
修改个人信息：
在线交易：
重置密码：
注册成功：
注册失败一：
注册失败二：
六、系统协作图：
查看购物车：
查找商品：
修改个人信息：
在线交易：
重置密码：
注册成功：
注册失败一：
注册失败二：
七、系统活动图:
查看购物车：
查找商品：
修改个人信息：
在线交易：
注册：
八、系统状态图：
定单：
发票：
会员：
九、系统构件图：
十、系统部署图：
十一、总结
通过这次实验我仍是感觉对自己以后从事编程行业工作的时候，这门课仍是相当的比较有效的，有助于软件的开发，整体结构比较清楚，逻辑结构比较明朗，通过这次设计自己对ＵＭＬ面向对象建模的流程有了必然的了解。
作为一门面向对象软件设计语言它完全表现了面向对象技术的所有优势，同时还有诸如唯一性、持续性、可保护性等优势。
尽管通过这次实验自己并无完全部会到这些优势，可是通过这次设计仍是大大提高了自己设计水平，分析问题能力。
问题只要分析的透彻，解决问题的思路便会很清楚。
这次实验设计让我收成很多，我也相信能够为自己以后的学习和工作提供宝贵的体会。
自己在以后的培训学习进程中也会不断学习相关的知识加深对ＵＭＬ建模和分析的熟悉，学习好UML来指导自己更好的从事自己的编程开发，使自己在以后的学习工作中加倍自信。
升级会员 