计算机系面向对象网上订餐系统.docx
《计算机系面向对象网上订餐系统.docx》由会员分享，可在线阅读，更多相关《计算机系面向对象网上订餐系统.docx（34页珍藏版）》请在冰豆网上搜索。
计算机系面向对象网上订餐系统
面向对象分析与设计
实习报告
系统名称：
快乐网上订餐系统
指导教师：
yyy
小组成员：
hj、may、ygr
学号：
c、b、a
提交日期：
2013/11/21
目录
1系统概述（组内共享）1
1.1系统简介1
1.2小组成员及分工1
2需求获取实习（组内共享）2
2.1功能性需求2
2.2非功能性需求2
3用例建模实习3
3.1识别参与者（组内共享）3
3.2识别用例（组内共享）3
3.3绘制用例图（组内共享）3
3.4编写用例归约3
3.5术语表..................................................................................................................................4
4精化用例模型实习5
4.1精化用例模型5
4.2编写或修改用例归约（个人独立完成）5
5寻找分析类实习（组内共享）6
5.1CRC头脑风暴6
5.2Noun/Verb分析6
5.3绘制初步的分析类图6
6识别关系实习（组内共享）7
6.1识别关联7
6.2识别其它关系7
6.3更新分析类图7
7用例实现（分析）实习8
7.1确定和整合分析类（个人独立完成）8
7.2创建交互图（个人独立完成）8
7.3分包组织建模元素（组内共享）8
8设计模型实习（组内共享）10
8.1划分子系统和层10
8.2创建设计类图10
8.3精化顺序图10
9总结与建议11
9.1总结（组内共享）11
9.2建议（个人独立完成）11
1系统概述（组内共享）
1.1系统简介
本系统主要是实现网上浏览菜单、订餐、产生订单等功能的系统。
需要实现菜品信息的动态提示、购物车管理、客户信息注册、登录管理、订单处理、信息反馈等模块。
需要完成的主要任务如下：
当顾客进入网上订餐时，应该在主页面中分类显示最新的菜品信息，以供顾客选择所需菜品，同时提供按菜品名称，快速查询所需菜品信息的功能。
当顾客选择预定某个菜品时，应该能够将对应菜品信息，如：
价格、数量记录到对应的购物车中，此时顾客可以选择选择其他菜品或是查看自己的购物车，最后，在购物车中填写相应的送餐信息，提交订餐订单后，自动清除以生成订单的购物车中的信息。
餐厅服务人员根据订单信息，查看详细订单明细并根据实际情况处理订餐。
总而言之，我们要实现的快乐订餐是一种方便快捷的在线订餐平台，真正地让用户订餐省时、省力、省心。
1.2小组成员及分工
学号
姓名
主要工作分工
c
hj
部署分工，上机绘图。
b
may
上机绘图
a
ygr
归总和完善文档描述
2需求获取实习（组内共享）
2.1.1顾客界面（Customer）包括用户登录（LogOn）、注册（Register）功能修改账户信息（Update）。
2.1.2定位界面（Location）User,Customer能在页面上按拼音查找（PinYin），按区域查找（Area）,热门城市（PopularCity）进行定位自己地理位置。
2.1.3餐馆界面（Restaurant）显示所有商家（Salesagent），最火餐厅（HotR），最近餐馆（ClosetR），综合排名餐馆（R-rank）
2.1.4菜单界面（Menu）显示所有的菜（Dishes）及它们的分类（Category），分类包括中餐类（ChineseFood）,西餐类（WesternFood）,东南亚菜（South-EastFood）,热菜类（HotDishes）,凉菜类（ColdDishes）,主食类（Staple）,酒水类（Drinks）,汤类（Soups）等,每个类别都包含相应的菜，如中餐类：
川菜（Sichuandish），粤菜（Cantonesedish），鲁菜（Shangdongdish）等;西餐类：
意大利餐（Italian），法餐（French），西班牙餐（Spain）等。
2.1.5购物篮界面（Basket）显示顾客所点的餐的信息列表，如菜名，价格、数量以及优惠券信息等。
2.1.6结算订单界面（Checkout）显示最终订单并请求确认。
订单包括下单时间以及顾客姓名、电话、地址以及支付方式（菜到付款，网上支付：
网银，信用卡，支付宝等）等信息。
2.2功能性需求
按照下面的表格填写系统的功能性需求。
编号
描述
分类
优先级
R1
快乐订餐系统可显示所有菜品列表
Dishes
MustHave
R2
快乐订餐系统应能根据菜品列表显示菜的分类
Dishes
MustHave
R3
快乐订餐系统应能显示选定产品的详细信息，包括名称、图片以及相应的描述信息
Dishes
MustHave
R4
快乐订餐系统应能支持所有主流的信用卡
Payment
MustHave
R5
快乐订餐系统应能通过信用卡处理公司验证支付
Payment
MustHave
R6
快乐订餐系统应能自动计算订单的配送费用
Payment
ShouldHave
R8
快乐订餐系统应允许顾客向购物篮中添加产品
UI
MustHave
R9
快乐订餐系统应允许顾客从购物篮中移除产品
UI
MustHave
R10
快乐订餐系统应允许顾客结算并支付购买产品
UI
MustHave
R11
快乐订餐系统用户界面应支持插入广告
UI
WantToHave
R12
快乐订餐系统应在顾客支付的时候生成订单
Orders
MustHave
R13
快乐订餐系统应在订单支付完成后通知配送部分
Orders
ShouldHave
R14
快乐订餐系统应在支付和订单被确认后，向顾客发送当前订单的拷贝
Orders
MustHave
R15
快乐订餐系统应允许顾客查看历史订单信息
Orders
ShouldHave
R16
快乐订餐系统应允许顾客在订单配送前取消订单
Orders
MustHave
R17
快乐订餐系统在订单取消时应通知配送部分
Orders
MustHave
R19
快乐订餐系统应允许配送部分查看所有订单
Orders
MustHave
R20
快乐订餐系统应允许顾客通过网站注册账号
Register
MustHave
R21
快乐订餐系统应支持顾客Email地址作为登录用户名
LogOn
MustHave
R22
快乐订餐系统应要求顾客为注册账号设置密码
Register
MustHave
R23
快乐订餐系统应保存注册顾客的基本信息，包括姓名、住址、Email地址、电话号码、传真号码、信用卡信息
Register
MustHave
R24
快乐订餐系统应允许顾客查看及修改顾客信息
LogOn
MustHave
2.3非功能性需求列表
ID
Details
Type
Priority
R25
快乐订餐系统应保存事务过程中不可否认的凭证
Security
MustHave
R26
快乐订餐系统应能支持每日100000个事务
Capacity
ShouldHave
R27
快乐订餐系统应能支持峰值时每秒10个事务
Capacity
ShouldHave
R28
快乐订餐系统应能支持10000个并发连接
Capacity
MustHave
R29
快乐订餐系统应每日24小时，每年360日可用
Availability
MustHave
R30
快乐订餐系统应保存所有销售事务数据
Availability
MustHave
R31
95%情况下，快乐订餐系统应能接收支付并在5秒内生成订单（考虑到网络及信用卡公司授权验证的延时，该性能不能在所有情况下确保实现）
Performance
ShouldHave
R32
顾客登录快乐订餐系统的延时不应超过5秒
Performance
ShouldHave
R33
快乐订餐系统使用浏览器作为用户界面
ComplianceToStandards
MustHave
R34
快乐订餐系统应支持IE8及以上、FireFox3及以上版本浏览器
ComplianceToStandards
MustHave
R35
快乐订餐系统兼容IE、FireFox老版本或其它浏览器，无法兼容时友好提示
ComplianceToStandards
MustHave
R36
快乐订餐系统使用标准Java语言实现，能够在Linux和Windows系统上运行
ComplianceToStandards
ShouldHave
R38
快乐订餐系统应认证非顾客的系统用户
Security
MustHave
R39
快乐订餐系统应使用加密通信手段
Security
MustHave
Priority：
M（MustHave）、S（ShouldHave）、C（CouldHave）、W（WanttoHave）
3用例建模实习
3.1识别参与者（组内共享）
按照下面的表格填写系统的参与者。
参与者名称
简要描述
Customer
在快乐订餐系统上订餐的顾客
User
在快乐订餐系统上浏览的用户
Administrator
管理顾客信息的人
Servicer
负责售前售后服务的人
salesAgent
参与网上订餐的商家
3.2识别用例（组内共享）
用例名称
简要描述
Cmanege
Orders
Customer可以创建，查看，修改和删除订单。
ManageCustomer
Administrator可以查看，添加、删除和修改Customer信息。
ManageUser
Administrator管理User登陆权限及信息
LogOn
CustomerUserSalesAgentServicerAdministrator通过信息认证可以登录系统。
Register
CustomerSalesAgent可以输入个人信息注册系统账号。
CmanageInformation
Customer可以查看，修改个人账户信息。
ViewDishes
CustomerUser可以浏览各种菜品，以及查看各种类菜品信息。
FindDishes
CustomerUser可以通过菜名等条件查找具体菜种。
Location
CustomerUser通过选择城市定位，定位具体区域
SalesAgentmanagemenus
SalesAgent可以查看，添加、删除菜品，修改菜品图片，价格，菜品介绍等信息。
Consult
Servicer可以为Customer提供订餐前菜品信息的查询，以及订餐后的配送等信息查询。
Feedback
Customer可以通过Servicer对菜品，订餐服务等进行打分,并且可以进行投诉。
CustomermanageB
Customer向购物篮中添加，删除，修改Dishes信息
3.3绘制用例图（组内共享）
3.4编写用例归约
3.4.1小组成员及分工
学号
姓名
完成的用例
1004111205
hj
ID:
4,5
b
may
ID：
6,7
a
ygr
ID：
1,2,3
3.4.2用例归约（个人独立完成）
3.4.2.1用例1用例归约
1.CmanageOrders用例
UseCase：
CmanageOrders
UseCaseID：
1
Description:
Customer可以创建，查看，修改和删除订单。
PrimaryActors:
Customer
SecondaryActors：
None
Preconditions：
用户进入个人信息界面
FlowofEvents：
1.进入修改界面
2.输入需要修改的内容
3.输入完毕后点击保存
4.用户提示订单信息修改成功
5.退出订单界面返回主界面
AlternativeFlows:
None
Postconditions:
修改成功
2.CustomerLogin用例
UseCase：
CustomerLogin
UseCaseID：
2
Description:
Customer通过信息认证可以登录系统。
PrimaryActors:
Customer
SecondaryActors：
None
Precondition:
用户登录成功，进入系统界面
FlowofEvents：
用户启动系统
系统显示登录信息填写界面
用户填写用户名
用户填写密码
用户提出登录请求
系统检测信息的充分性
系统核对用户身份的合法性
用户登录成功，进入系统界面
AlternativeFlows:
None
Postconditions:
登录成功
3.CustomerRegister用例
UseCase：
CustomerRegister
UseCaseID：
3
Description:
Customer可以在顾客界面输入个人信息注册系统账号。
PrimaryActors:
Customer
SecondaryActors：
None
Preconditions：
用户未登录且无系统账号。
FlowofEvents：
1用户启动系统
2.系统显示注册信息填写界面
3.用户填写用户名
4.系统检测用户输入的用户名是否已被使用。
5.用户填写密码
6.系统检测用户输入的密码和确认输入的密码是否相同。
7.用户填写邮箱
8.系统检测用户输入的邮箱是否已经被使用
9.用户提出注册请求
10.系统提示注册成功
10.系统向用户填写的邮箱地址发送认证邮件。
11．用户进入邮箱后确认注册，并认证成功。
AlternativeFlows:
None
Postconditions:
注册成功
3.5术语表
Dishes
所有菜品
payment
支付
UI
用户界面
Location
定位界面
CmanageInformation
顾客管理信息
V-Drink
浏览菜品
V-Food
浏览饮料酒水
ManageB
管理购物篮
AddDishesToB
向购物篮添加菜品
CupdateInfo
顾客更新信息
Consult
查询
OrdingDishes
生成订餐菜单
4精化用例模型实习
4.1精化用例模型
4.1.1精化后的用例图（组内共享）
4.1.2参与者和用例描述（组内共享）
参与者名称
简要描述
Customer
在IBDS系统上订餐的人
User
使用系统但不是管理的人
（普通浏览者，系统用户）
Administrator
管理系统信息的人
CustomerServicer
负责售前售后服务的人
SalesAgent
网上订餐的合作商家
PaymentCompany
完成网上支付事务的外部公司
用例名称
简要描述
CustomerLogOn
Customer在进行订餐，管理账户信息之前通过信息认证登陆系统
CustomerRegister
Customer创建新的账号，设置账号信息（姓名，地址，登录名，密码等）
CmanageInformation
Customer更新，查看个人信息账户。
该用例之后包含CUpadateInfo，CViewInfo用列。
CUpadateInfo
Customer更新个人信息，姓名地址，密码等。
但是不可以修改登录名。
CViewInfo
Customer通过登陆个人账户查看个人账户信息。
OrdingDishes
Customer生成订餐订单，可以进行修改，查看等操作。
BrowseBasket
Customer可以查看购物篮中的信息，顾客添加菜种或执行查看购物篮功能后，将显示当先购物篮的菜种，价格等信息
ManageB
Customer可以通过购物篮修改菜种数量或移除菜种，当前用例扩展自BrowseBasket，
AddDishesToB
Customer可以向购物篮中添加菜种，添加菜种后将包含BrowseBasket用例。
ViewDishes
CustomerUser可以浏览各种菜品，以及查看各种类菜品，所属商家，价格等信息。
V-Food
ViewDishes的特殊化用例,可以浏览各种菜品。
V-Drinks
ViewDishes的特殊化用例：
可以浏览各种饮料酒水。
FindDishes
CustomerUser可以基于菜名等设定条件查找一个或多个具体菜种，该用例执行后包含ViewDishes用例。
F-Food
FindDishes的特殊化用例,可以基于条件查看各种菜品。
F-Drinks
ViewDishes的特殊化用例：
可以查看各种饮料酒水。
Location
CustomerUser通过拼音，区域等条件选择城市定位，定位具体区域
SalesRegister
SalesAgent可以通过与订餐系统网站合作，注册创建商家账号。
SalesAgentmanagemenus
SalesAgent可以查看，添加、删除菜品，修改菜品图片，价格，菜品介绍等信息。
CheckOut
Customer执行结算功能，顾客为订餐订单付费。
当前用例扩展自OrdingDishes用例，并包含AceepPaymentCard用例。
AceepPaymentCard
Customer可以通过第三方公司的支持通过信用卡或网上进行支付。
Consult
Servicer可以为Customer提供订餐前菜品信息的查询，以及订餐后的配送等信息查询。
Feedback
Customer可以通过Servicer对菜品，订餐服务等进行打分,并且可以进行投诉。
该用例扩展自Consult用例。
ManageCustomer
Administrator管理顾客信息账户，进行权限管理等操作。
ManageUser
Administrator对普通浏览用户进行权限制，也可保存浏览信息等。
LogOnUser
SalesAgent,Administrator,在执行后台系统操作之前必须通过信息认证登录系统。
4.1.3编写或修改用例归约（个人独立完成）
4.1.3用例1的用例归约
UseCase：
CmanageOrders
UseCaseID：
1
Description:
Customer可以修改订单。
PrimaryActors:
Customer
SecondaryActors：
None
Preconditions：
用户进入个人信息界面
FlowofEvents：
1.用户进入订单界面。
2.选择修改订单信息
3.进入修改界面
4.输入需要修改的内容
5.输入完毕后点击保存
6.系统提示是否确认保存
7.点击保存
8.用户提示订单信息修改成功
9.退出订单界面返回主界面
AlternativeFlows:
None
Postconditions:
修改成功
UseCase：
CustomerLogin
UseCaseID：
2
Description:
Customer通过信息认证可以登录系统。
PrimaryActors:
Customer
SecondaryActors：
None
Precondition:
用户登录成功，进入系统界面
FlowofEvents：
1.用户启动系统
2.系统显示登录信息填写界面
3.用户填写用户名
4.用户填写密码
5.用户提出登录请求
6.系统检测信息的充分性
If登录信息不充分
6.1系统提示用户登录信息不充分并返回登陆界面
If登录信息充分
6.2系统检测用户信息充分
7.系统核对用户身份的合法性
If用户身份不合法
7.1系统提示用户登录信息不合法并返回登录界面
If用户身份合法
7.2系统核对用户身份合法
8.用户登录成功，进入系统界面
AlternativeFlows:
None
Postconditions:
登录成功
UseCase：
CustomerRegister
UseCaseID：
3
Description:
Customer可以在顾客界面输入个人信息注册系统账号。
PrimaryActors:
Customer
SecondaryActors：
None
Preconditions：
用户未登录且无系统账号。
FlowofEvents：
1用户启动系统
2.系统显示注册信息填写界面
3.用户填写用户名
4.系统检测用户输入的用户名是否已被使用。
If用户名未被使用。
4.1用户可使用此用户名注册账号。
If用户名已被使用。
4.2用户需更换其他用户名并重新检测。
5.用户填写密码
6.系统检测用户输入的密码和确认输入的密码是否相同。
If两次输入的密码相同。
6.1用户可继续填写其他注册信息。
If两次输入的密码不同。
6.2用户需修改密码并再次确认两次输入的密码是否相同。
7.用户填写邮箱
8.系统检测用户输入的邮箱是否已经被使用
If邮箱未被使用
8.1用户可以继续注册
If邮箱已被使用
8.2用户需要重新填写新的邮箱地址
9.用户提出注册请求
10.系统提示注册成功
10.系统向用户填写的邮箱地址发送认证邮件。
11．用户进入邮箱后确认注册，并认证成功。
AlternativeFlows:
None
Postconditions:
注册成功
5寻找分析类实习（组内共享）
5.1CRC头脑风暴
Customer职责：
维护关于顾客的详细信息，如名字、电话、住址等。
Menu职责：
展示菜品列表，分类展示菜品。
Dishes职责：
向用户展示菜品的基本信息，包括菜名、菜品描述、价格、
提供菜品的餐馆。
SalesAgent职责：
提供销售商的名字与基本信息。
System职责：
为已登录用户提供系统主界面，可进行菜品、餐馆浏览、订餐等。
Ordering职责:
维护用户可能购买的菜品的信息，允许用户添加和取消订单
Basket职责：
显示用户选择的菜品，数量，价格。
5.2Noun/Verb分析
根据Noun/Verb法，寻找候选类，填写下表。
候选类
菜品分类、菜品、目录、结算（checkout）、信用卡信息、信用卡处理公司、顾客、配送、表单、菜品描述、菜品列表、订单、菜品信息、查询条件、购物篮、订单概要信息、系统、用户（User）、用户名
候选属性
地址、分类、Email地址、标签、姓名、电话号码、图片、价格、配送地址、密码
候选操作
接受（订单）、添加到购物车
升级会员 