自动订餐系统用例图.docx

上传人:b****5 文档编号:8008745 上传时间:2023-01-27 格式:DOCX 页数:16 大小:41.25KB
下载 相关 举报
自动订餐系统用例图.docx_第1页
第1页 / 共16页
自动订餐系统用例图.docx_第2页
第2页 / 共16页
自动订餐系统用例图.docx_第3页
第3页 / 共16页
自动订餐系统用例图.docx_第4页
第4页 / 共16页
自动订餐系统用例图.docx_第5页
第5页 / 共16页
点击查看更多>>
下载资源
资源描述

自动订餐系统用例图.docx

《自动订餐系统用例图.docx》由会员分享,可在线阅读,更多相关《自动订餐系统用例图.docx(16页珍藏版)》请在冰豆网上搜索。

自动订餐系统用例图.docx

自动订餐系统用例图

信息工程学院

《软件需求分析》实验报告

●实验编号:

3

●实验名称:

用户需求

●院系:

信息工程学院

●班级:

软件0902班

●班级人数:

39

●姓名:

黄彬吴坤王俊惠蓉亮

●学号:

0910024203

●任课教师:

陈娟

●实验地点:

软件实验室I

●实验日期:

2011年10月17日

计算机科学系上机实验报告

第一页

计算机科学系上机实验报告

第二页

一、实验目的

针对某小型软件产品(含小型网站)的开发,在业务需求文档(前景范围文档)的基础上,进一步收集、获取用户的业务知识(重点是人机交互、任务的输入、任务功能、输出信息及业务任务的结果等),建立起用例模型,描述:

1)用户业务任务的用例图(参见教材图8-1)

2)用户业务任务的用例列表(示例见附录表4-1)

3)若干个具体的用例。

即从用例出发推导部分功能需求和非功能需求,并明确说明。

异常处理单独描述。

(示例见附录表4-2)

4)用户完成业务任务中需遵循的业务规则(可选)

说明:

上述“若干个”具体的用例描述,指实验小组的每个成员至少从本组的软件(网站)的业务主干过程中选择一个用例进行规范描述。

二、实验环境

⑴计算机台数:

1台

⑵操作系统:

WindowsXP

三、实验内容

在学生自选的小型软件(或网站)的业务需求文档的基础上,实施以下实验内容:

1.深入获取业务知识,描绘用例图。

2.编写用例列表。

3.分工编写各自负责的用例描述。

4.学生自主讨论,教师指导、答疑。

信息工程学院上机实验报告

第二页

四、实验过程

表4-1用例列表(自动订餐系统)

主要参与者

用例

顾客

1.订餐

2.变更订单

3.取消订单

4.查看菜单

5.注册从工资中扣除餐费的付费方式

6.取消注册的从工资中扣除餐费的付费方式

7.订购标准餐

8.修改所订的标准餐

9推翻所订的标准餐

菜单经理

10.创建菜单

11.修改菜单

12.定义特色菜

自助食堂工作人员

13.准备餐

14.生成付费请求

15.请求送货

16.生成系统使用报告

送餐人员

17.送餐

18.记录送餐情况

19.打印送餐说明

任务分配表

成员

分配任务

黄彬

1~4,19,20

王俊

5~8,17,18

吴坤

7~11

惠蓉亮

11~16

表4-2用例描述(示例:

自动订餐系统的订餐用例)

用例ID号

UC-1

用例名称

订餐

创建者

黄彬

最后更新者

黄彬

创建日期

2011年10月17日

最后更新日期

2011年10月21日

参与者

顾客

描述

顾客从公司内联网或从家里访问“自助食堂订餐系统”,随意查看某一天的菜单,选择自己想要的食物,提交订单并要求在特定的时间窗口(15分钟)内送货到指定的地点

前置条件

1.顾客登录到“自助食堂订餐系统”

2.顾客注册的付费方式是从工资中扣除

后置条件

1.订单在“自助食堂订餐系统”中的存储状态是“已接受”

2.根据这一订单的食物条目来更新食物存货

3.根据这一次的送货请求,对请求的时间窗口更新剩余的送货能力

主干过程

1.0订一份餐

1.顾客要求查看某一天的菜单

2.系统显示有效食物菜单和当日特色菜

3.顾客从菜单中选择一种或多种食物

4.顾客表明订餐完成

5.系统显示所订菜单条目、单价和总价格,包括应交纳的税和送货费用

6.顾客确认订餐订单或请求修改订餐订单(回到第3步)

7.系统显示那一天中有效的送餐时间

8.顾客选择送餐时间和指定送餐地点

9.顾客指定付费方式

10.系统确认接收订单

11.系统向顾客发送电子邮件,确认订单细节、价格和送餐说明

12.系统将订单存储在数据库中,并发送电子邮件通知自助食堂工作人员,将食物信息发送给自助食堂库存系统,并更新有效的送餐时间

分支过程

1.1订多份餐(第4步之后分支出来)

1.顾客要求预订另一份餐

2.返回到第2步

1.2同样的餐订多份(第3步之后分支出来)

1.顾客请求预订指定数量的同样食物的多份餐

2.返回到第4步

1.3订当日特色菜(第2步之后分支出来)

1.顾客从菜单中订当日特色菜

2.返回到第5步

异常

1.0.E.1订单截止时间在当前时间之前(第1步)

1.系统通知顾客今天订餐已太晚了

2a.顾客取消订单

2b.系统终止用例

3a.顾客请求选择另一个日期

3b.系统重新启动用例

1.0.E.2没有有效的送餐时间(第1步)

1.系统通知顾客送餐日已没有有效的送餐时间

2a.顾客取消订单

2b.系统终止用例

3.顾客请求在自助食堂选择订单(跳过第7步和第8步)

1.0.E.3不能完成指定数量的同样食物的多份餐(第1步)

1.系统通知顾客它所能提供的同样食物曲多份餐的最大数量

2顾客变更所订的同样食物的份数,或者取消订单

包含

优先级

使用频率

大约400名用户,平均每天使用一次

业务规则

BR-1,BR-2,BR-3,BR-4,BR-8,BR-11,BR-12,BR-33

特别需求

1.顾客在确认订单之前的任何时间都可以取消订单

2.顾客能查看自己前6个月的全部订餐,并可以重复其中的任一次订餐作为新的订餐,只要所有食物在请求送餐日的菜单中都有效。

(优先级为中)

假设

1.假设30%的顾客会订当日特色菜(来源:

根据前6个月的自助食堂数据所得)

注意和问题

1.如果客户在今天的截止时间之前使用系统,那么默认的日期是当前日期。

否则,默认日期是自助食堂的下一个营业日

2.如果顾客不要求送餐,那么“请求注册付费方式是从工资中扣除”这一前置条件就不适用

3.这一用例的峰值使用负载是当地时间早晨8点到10点

信息工程学院上机实验报告

第三页

用例ID号

UC5~8

用例名称

学生信息的录入和修改

创建者

王俊

最后更新者

王俊

创建日期

2011年10月17日

最后更新日期

2011年10月21日

参与者

学生信息录入员

描述

学生信息录入员将学员的基本信息写入到自考系统的学员信息表中;当学员选完课后,将学员的选课信息录入到学员_选课表;考完试后,将学员的成绩录入学员_成绩表;学生信息录入员也有修改上述表中的信息。

前置条件

1学生已经提交了自己的基本信息

2.学生已经选择了自己的课程

3.学员已经参加了所选课程的考试

后置条件

1.学生提交基本信息的页面显示“受理成功”

2.学员可以登录自考系统查看自己的学员信息

3.学员可以查看自己的选课情况以及成绩

主干过程

1.0学生信息的录入

1.学生使用自己的账号登陆自考系统填写自己的基本信息

2.学生对已应提交的信息进行最后提交确认,提交页面出现等待受理

3.信息录入员使用自己的账号登陆页面,将已提交的学员信息进行检查

4.对不符合提交的学员信息驳回,并要求其修改不符合条件的信息

5.对符合条件的学员信息,进行记录,并录入学员信息表

6.在学生提交页面显示“受理成功”

1.1学生信息的修改

1.学生某些信息发生改变,需要对要修改的信息进行提交

2.学生提出申请并提交需要改变的信息

3.录入员对学员提出的申请进行核实,如果该学员信息存在,就对该学员信息进行修改

4.学生申请页面显示“已经成功受理”

1.2学生选课信息的录入

1.学生使用自己的账号登陆自考系统进行网上选课

2.当选课信息提交后,学员就可查询自己已选课程

3.录入员将选课信息录入到学员_选课表

1.3学员选课信息的修改

1.学员在选课时间内,想对已选课程进行修改,可以提交申请

2.申请通过,就可以重新选择课程进行提交

3.录入员将学员_选课表的信息进行修改

4.在学员的申请页面显示“修改成功”

1.4学员成绩的录入和修改

学员成绩的录入和修改可以参照1.2学生信息的录入和1.3学院信息的修改

异常

.E1.用户填写的信息不符合要求填写格式

1.系统通知学生应该填写的格式

2.学员取消信息填写

3.信息提交不成功

E2.提交时间很长,但无人受理

1.学员可以打电话询问是否提交成功或未受理原因。

2.可以取消以前提交,重新进行提交

3.顾客请求在自助堂选择订单

E3录入信息与学员提交信息不符

1.可以通过打电话或留言方式通知录入人员修改信息。

2.可以通过申请提交正确信息

包含

优先级

使用频率

大约500名用户,平均每天使用一次

业务规则

特别需求

1.学员可以随时提出修改申请

2.录入员应该每天进入系统查看是否有信息需要录入。

假设

每天都有新增学员要求信息录入

注意和问题

1.如果学员毕业或途中退学要注销该学生的所有信息。

2.如果长时间申请得不到受理,可以取消当前申请,重新提出申请

3.这一用例的峰值会出现在是选课期间

用例ID号

UC-9-16

用例名称

学生信息查询

创建者

吴坤

最后更新者

吴坤

创建日期

2002年10月17日

最后更新日期

2002年10月21日

参与者

学员

描述

学生从互联网登录“自考学籍管理系统”,选择学生信息查询,可以进行学员基本信息查询、选课记录查询,成绩记录查询,缴费记录查询、考勤记录查询、学员论文开写提示信息查询、学员毕业提示信息查询、课程通过率查询。

前置条件

1.学员登录到“自考学籍管理系统”

2.学员查询自己的各类信息需要个人登录密码才能查询

后置条件

1.学员在“自考学籍管理系统”中的存储状态是“已注册”

2学员所要查询的信息已录入

主干过程

1.0学员需要进行信息查询

1.学员登录“自考学籍管理系统”

2.系统要求学员输入用户名和密码

3.学员成功登录到“自考学籍管理系统”

4.系统显示所有可以查询的项目

5.学员选择需要查询的项目

6.系统显示查询的信息

7.学员查询完毕返回查询列表(回到第五步)

8.查询完毕

9.系统记录最后一次查询时间和查询项目

10.系统自动备份系统数据

常用查询项目库存系统,方便学员日后再次快捷查询

异常

1.0.E.1学员输入的用户名不存在或者密码错误(第2步)

1.系统通知学员用户名不存在

2a.学员记错密码

2b.系统终止用例

3a.学员输入新的用户名和密码

3b.系统重新启动用例

1.0.E.2学员需要查询的信息系统洗洗录入员尚未录入(第4步)

1.系统通知学员最新的信息尚未更新,可以继续查询以前的信息

2a.学员返回查询其他信息

2b.系统终止用例

3.学员自己终止用例退出系统(跳过第7步)

包含

优先级

使用频率

大约500名用户,平均每天使用一次

业务规则

BR-1,BR-2,BR-3,BR-4,BR-8,BR-11,BR-12,BR-33

特别需求

1.学员在任意时间都可以登录“自考学籍管理系统”进行信息查询

2.学员可以查询与自己相关的所有的信息,如果某些查询项目信息尚未更新,可以继续查询以前录入的信息。

(优先级为中)

3.当学员输入密码错误,忘记密码时,系统可以帮助用户找回密码

假设

1.假设30%的学员查询最新的信息

注意和问题

1.学员在每天任何时候都可以登录系统查询

2.同一时间登录学员过多时,可能导致系统反应速度缓慢

用例ID号

UC-9-16

用例名称

学生信息查询

创建者

惠蓉亮

最后更新者

惠蓉亮

创建日期

2011年10月17日

最后更新日期

2011年10月21日

参与者

学员

描述

学生从互联网登录“自考学籍管理系统”,选择学生信息查询,可以进行学员基本信息查询、选课记录查询,成绩记录查询,缴费记录查询、考勤记录查询、学员论文开写提示信息查询、学员毕业提示信息查询、课程通过率查询。

前置条件

1.学员登录到“自考学籍管理系统”

2.学员查询自己的各类信息需要个人登录密码才能查询

后置条件

1.学员在“自考学籍管理系统”中的存储状态是“已注册”

2学员所要查询的信息已录入

主干过程

1.0学员需要进行信息查询

1.学员登录“自考学籍管理系统”

2.系统要求学员输入用户名和密码

3.学员成功登录到“自考学籍管理系统”

4.系统显示所有可以查询的项目

5.学员选择需要查询的项目

6.系统显示查询的信息

7.学员查询完毕返回查询列表(回到第五步)

8.查询完毕

9.系统记录最后一次查询时间和查询项目

10.系统自动备份系统数据

常用查询项目库存系统,方便学员日后再次快捷查询

异常

1.0.E.1学员输入的用户名不存在或者密码错误(第2步)

1.系统通知学员用户名不存在

2a.学员记错密码

2b.系统终止用例

3a.学员输入新的用户名和密码

3b.系统重新启动用例

1.0.E.2学员需要查询的信息系统洗洗录入员尚未录入(第4步)

1.系统通知学员最新的信息尚未更新,可以继续查询以前的信息

2a.学员返回查询其他信息

2b.系统终止用例

3.学员自己终止用例退出系统(跳过第7步)

包含

优先级

使用频率

大约500名用户,平均每天使用一次

业务规则

BR-1,BR-2,BR-3,BR-4,BR-8,BR-11,BR-12,BR-33

特别需求

1.学员在任意时间都可以登录“自考学籍管理系统”进行信息查询

2.学员可以查询与自己相关的所有的信息,如果某些查询项目信息尚未更新,可以继续查询以前录入的信息。

(优先级为中)

3.当学员输入密码错误,忘记密码时,系统可以帮助用户找回密码

假设

1.假设30%的学员查询最新的信息

注意和问题

1.学员在每天任何时候都可以登录系统查询

2.同一时间登录学员过多时,可能导致系统反应速度缓慢

五、实验结果分析

1.总结用例法分析用户需求的过程和步骤。

2.针对实验数据检查与分析结果,总结自己的问题与收获。

用例建模技术,用于描述系统的功能需求。

在宏观上给出模型的总体轮廓。

通过对典型用例的分析,使开发者能够有效地了解用户的需求。

用例模型由若干个用例图构成,用例图中主要描述执行者和用例之间的关系。

在UML中,构成用例图的主要元素是用例和执行者及其它们之间的联系。

六、评语(得分)

信息工程学院上机实验报告

第五页

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 医药卫生 > 基础医学

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1