信管院软件工程习题课.docx
- 文档编号:4316040
- 上传时间:2023-05-07
- 格式:DOCX
- 页数:16
- 大小:106.48KB
信管院软件工程习题课.docx
《信管院软件工程习题课.docx》由会员分享,可在线阅读,更多相关《信管院软件工程习题课.docx(16页珍藏版)》请在冰点文库上搜索。
信管院软件工程习题课
1.工资管理系统说明:
(1)财务部根据员工工资信息系统内部规则结算和发放员工工资。
(2)管理员根据员工工资信息系统的相关规则修改员工个人信息和修改员工工资信息。
(3)管理层对由员工工资信息系统得出的工资统计进行审核。
(3)员工进行工资查询和领取工资。
用例说明
财务部门:
系统的主要使用者,完成工资核算、工资发放。
管理层:
工资审核。
管理员:
负责修改员工个人信息和修改员工工资信息,对员工工资信息系统进行维护。
员工:
使用员工工资信息系统进行查阅工资信息,然后领取工资。
2.员工工资管理系统的静态系统:
用例图
2.飞机订票系统动态模型:
活动图
3.网上订票系统的需求建模
1)问题陈述
网上订票系统主要为订票客户和售票管理员服务的。
普通订票客户在使用本订票系统的功能之前,必须先注册账号。
在注册页面中填写实名信息,如账号、密码、个人姓名、省份证号等等。
在提交完表单和注册信息之后,系统将保存信息并且审核信息的真实性,审核通过注册成功。
如果客户已经在系统中注册过后,可以输入账号和密码进入系统,选择相应的订票服务,否则只能浏览普通的页面。
进入系统之后,客户可以开始选择自己所要的服务,比如购票、查询余票、退票、改签、票价查询等!
客户确定自己的订票信息后,客户填写包括订票人姓名,身份证号等等,检查车次、时间之后,确认无误,提交订单,系统将自动将信息发送到银联系统,执行扣款,银联系统将操作成功与否的信息返回到系统。
操作成功之后,购票成功。
售票管理员在进入系统之前,要输入口令,输入无误之后方可进入。
进入系统之后,可以设置操作权限,可以时间增加和删除票务信息,处理客户提出的相关的服务请求,但是管理员无权限修改客户的信息。
系统提供的票务服务信息丰富,客户可以先查询,后订购,可以一次性购买多张。
2)用例模型
1.用例图
由该用例图可知,该用例图包括8个用例,3个参与者。
分别是:
用例有:
注册、登陆、订票、查询、退票、改签、票务信息、订单信息。
参与者:
订票客户、售票管理员、银联系统
2.用例规约
1.注册
1.1简要说明
本用例用来向用户提供注册功能,每位客户必须注册之后才可以进行订票、退票等改签等服务请求。
注册信息必须包括本系统的账号、密码、身份证号码、电子邮箱、联系地址、联系电话等信息。
进过系统审核过后,注册完成。
注册完成后,系统将会自动保存这些信息,方便用户登录的时候进行验证。
1.2事件流
1.2.1基本流
当用户开始注册时,开始执行以下基本流:
●系统要求用户填写实名制个人信息,包括个人的本系统的账号、密码、身份证号码、电子邮箱、联系地址、联系电话等信息。
●用户开始填写注册信息。
●系统验证审核用户的注册信息格式和内容,将审核的结果发至电子邮箱。
●保存注册信息。
1.2.2备选流
1.2.2.1用户信息验证错误
如果系统检测到用户的信息格式或者内容有错,会给与错误提示,并且清空填写错误的文本框,要求用户重新插入。
1.2.2.2用户注册信息审核失败
如果用户的信息和公安系统的实名制的信息不相匹配,会发邮件至邮箱,提示审核失败,该未审核通过的信息将不被保存,必须重新注册。
1.2.2.3用户注册信息保存失败
如果系统发现数据库中已经保存了同样账号的实名制用户记录,将会发送邮件至电子邮箱,是页面跳回注册的页面,要求重新注册。
1.3特殊要求
无。
1.4前置条件
用户必须首先登陆网上订票的的首页才可以点击注册。
1.5后置条件
如果该用例成功,则系统数据库将会增加一条该用户的信息记录,否则,系统将保持原样。
1.6拓展点
无。
2.登陆
2.1简要说明
本用例用来向用户提供登陆功能,每位客户必须注册之后才可以登陆该订票系统。
注册成功后,登陆是填入系统账号、密码以及输入验证码之后,系统将验证填入的信息,输入正确方可进入订票系统。
2.2事件流
2.2.1基本流
当用户开始登陆时,开始执行以下基本流:
●系统要求用户填写系统账号、密码和验证码。
●用户开始登陆信息。
●系统验证审核用户的登陆信息格式和内容,输入正确则跳转到系统页面。
2.2.2备选流
2.2.2.1用户信息登陆错误
如果系统检测到用户的信息格式或者内容有错,会给与错误提示,并且清空填写错误的文本框,要求用户重新插入。
2.3特殊要求
无。
2.4前置条件
用户必须首先成功注册之后,进入本系统的首页点击输入再登陆。
2.5后置条件
如果该用例成功,页面将转入系统页面,方可进行相应的服务请求。
2.6拓展点
无。
3.订票
3.1简要说明
本用例用来向用户提供订票功能,每位客户必须登陆之后才可以进行订票请求。
订票必须输入订票人的身份证号好姓名,系统验证之后,系统将返回相应的票务信息。
3.2事件流
3.2.1基本流
当用户开始订票时,开始执行以下基本流:
●顾客请求订票,系统显示相应的票务信息。
●顾客选择所需要订购的票,式和内容,一旦确定对票务信息的操作,则转向以下子流程:
若选择了订票,则系统要求输入订票人姓名和身份证号,则进入“生成订单“子流程开始执行。
如果从票务信息里没有想要的票,则退出到系统页面。
3.2.1.1生成订单
若顾客想要生成订单,则系统修改相应的票务信息,系统数据库增加一条订单信息,进入银联系统进行支付。
3.2.2备选流
3.2.2.1用户信息订票失败
如果系统检测到用户提交的订单信息不全,会给与错误提示,并清空填写错误的文本框,要求用户重新输入订单信息。
3.2.2.2用户取消订单
如果用户取消订单,系统更新票务信息,将用户在数据库中的订单信息删除,页面重新跳回系统页面。
3.3特殊要求
无。
3.4前置条件
用户必须首先登陆网上订票的的首页才可以点击订票,订票也必须输入实名信息。
3.5后置条件
如果该用例成功,则系统数据库将会增加一条该用户的订单信息记录,系统要求用户进入银联系统支付票款,否则,系统将保持原样。
3.6拓展点
无。
4.查询
4.1简要说明
本用例用来向用户提供查询功能,每位客户必须登陆之后才可以进行查询请求。
用户必须有过订票,才可以选择查询订单信息,若是没有点单信息,也可以查询余票、票价等。
4.2事件流
4.2.1基本流
当用户开始查询时,开始执行以下基本流:
●顾客请求查询,系统根据查询请求显示相应的票务信息。
若顾客查询订单信息,系统则从系统数据库调出相应的订单信息。
多顾客查询余票或者票价信息,则信息显示相应的票务信息。
4.2.2备选流
4.2.2.1用户查询失败
如果系统检测到用户提交的查询信息不全,会给与错误提示,并清空填写错误的文本框,要求用户重新输入查询信息,待用户输入正确的查询信息,再显示相应的查询结果。
4.3特殊要求
无。
4.4前置条件
用户必须首先登陆网上订票的的首页才可以点击订票,订票也必须输入实名信息。
4.5后置条件
无。
4.6拓展点
无。
5.退票
5.1简要说明
本用例用来向用户提供退票功能,每位客户必须订票之后才可以进行退票请求。
退票必须查询到自己的订单信息,确定退票之后,系统数据库将删除相应的订单信息记录,银联系统将会退换票款至用户的账户。
5.2事件流
5.2.1基本流
当用户开始订票时,开始执行以下基本流:
●顾客请求退票,系统显示相应的订单信息。
●顾客确定退票,系统删除相应的订单信息记录。
●银联系统将会退换票款至用户的账户。
5.2.2备选流
5.2.2.1用户退票失败
如果系统繁忙,或者用户太多,导致退票失败,会将失败信息返回给用户,系统重新跳回到退票页面。
5.2.2.2用户取消退票
如果用户取消订单,系统更新票务信息,将用户在数据库中的删除的订单信息重新添加,将结果返回给用户,页面重新跳回系统页面。
5.3特殊要求
无。
5.4前置条件
用户必须首先有过订票记录才能点击退票,退票也必须在票还没有取之前。
5.5后置条件
如果该用例成功,则系统数据库将会删除一条该用户的订单信息记录,系统进入银联系统返还票款,否则,系统将保持原样。
5.6拓展点
无。
6.改签
改签几乎是退票和订票的结合,同理。
7.票务信息
7.1简要说明
本用例用来向用户提供票务信息,每为用户在进行查询或者订票、退票、改签时,系统都根据用户的请求返回给用户的票务结果。
7.2事件流
7.2.1基本流
当用户使用票务信息时,开始执行以下基本流:
如果用户在查询和订票时,系统要求用户输入关键字,根据用户输入的内容返回给用户相应的票务信息。
如果用户是在退票或者改签时,系统要求用户输入订单号,再返回给用户相应的订单信息。
7.2.2备选流
7.2.2.1票务信息显示错误
如果系统检测到用户输入的关键字或者订单号有误,会给与错误提示,并且清空填写错误的文本框,要求用户重新输入。
7.2.2.2用户注册信息显示失败
如果用户所想要查询的票务信息不存在,系统将显示错误信息,并且清空填写错误的文本框,要求用户重新输入
7.3特殊要求
无。
7.4前置条件
用户必须首先登陆网上订票的的首页才可以查询票务信息。
7.5后置条件
无。
7.6拓展点
无。
8.订单信息
8.1简要说明
本用例用来向用户返回订单结果,用户在订票或退票、改签之后都会将操作的结果作为订单信息返回给用户。
8.2事件流
8.2.1基本流
当用户想要使用订单信息时,开始执行以下基本流:
●用户向系统请求的订票、退票或改签结束后,系统会自动更新票务信息。
●系统将用户的请求完成后的结果返回个用户,否则停在该页面。
8.2.2备选流
8.2.2.1用户获取订票信息失败
如果系统还未完成用户提供的请求,或者订票是还没有取银联系统付清账款,系统将会停在该页面等待,过了规定时间后,将会把失败信息返回给用户。
8.3特殊要求
无。
8.4前置条件
用户必须首先登陆网上订票系统,请求订票或退票或改签,在请求执行完之后,才会获取到订票信息。
8.5后置条件
如果该用例成功,则系统数据库将会增加或删除或修改一条该用户的订单信息记录。
8.6拓展点
无。
3)补充规约
1.目的
本补充规约列出了网上订票系统的非功能性需求和部分全局性
需求。
它和用例模型一起,组成了完整的系统需求规格说明书。
2.范围
本说明书除了定义在许多用例中有的共有的功能性需求以外,还定义了系统的非功能性需求,如可靠性、可用性、系统性能和可支持性等。
3.参考
无。
4.功能性
4.1满足多个用户的并发执行。
4.2当用户执行网上订票系统的功能时,系统将自动查询票务信息,若无票或者无坐票,都将提醒用户。
4.3系统能够提供管理票务系统和审核用户注册信息的功能,管理员审核通过注册才成功,管理员通过用户的注册信息,将用户的订单消息发送至用户邮箱。
5.可用性
用户界面视窗与Windows系统兼容,也和智能手机操作系统兼容。
6.可靠性
保证系统完成后24小时都可以用,平均无故障时间应超过300小时。
7.性能
7.1该系统应能支持多达50000名用户在任何特定时间使用中央数据库,并支持多达5000名用户在任何时间访问本地服务器。
7.2系统要求对数据库的访问,读取以及存取速度要快,特别是对票务信息的访问的反应时间要在10秒以内。
7.3系统要求在确认订票后,45分钟内通过银联系统将票款支付到账,订票才算成功,否则订票失败。
7.4如果使用该系统的用户过多,采取先来先排队的方法,顺序订票。
8.可支持性
无。
9.安全性
系统要求有非常高的安全性,由于订票时,用户的账号密码将在网上传递,所以必须提供额外的安全措施。
10.设计约束
无。
4)术语表
1.简介
本文档用来对一些术语来进行定义,同时也对用例说明或者其他文档中读者不太熟悉的术语进行解释性的描述。
一般地说,它可用作一种信息数据字典,使得用例规约和其他文档显得简洁易懂。
2.名词定义
这份术语表包含了网上订票系统的重要概念。
2.1顾客:
指每个使用该系统进行订票的人。
2.2售票管理员:
负责审核用户注册信息以及更新修改票务信息的人。
2.3银联系统:
验证用户及信用卡信息并执行扣款或者退款操作。
2.4票:
本系统出售的票。
2.5注册信息:
用户注册时填写的账号、秘码以及个人信息,如姓名、身份证号、联系方式、电子邮件等。
2.6票务信息:
用户需要的车次、余票、价格等信息。
2.7订单信息:
用户订购的票,包括订票人姓名、身份证号、车次、座位、价格、数量等信息。
2.8用户账号:
用户使用本系统之前必须要先注册,用户账号标识特定的用户,作为进入本系统的凭证,只有注册过的用户才可以进入系统页面,才可以请求订票业务。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 信管院 软件工程 习题
![提示](https://static.bingdoc.com/images/bang_tan.gif)