太原理工大学系统分析实验报告Word文件下载.docx
《太原理工大学系统分析实验报告Word文件下载.docx》由会员分享,可在线阅读,更多相关《太原理工大学系统分析实验报告Word文件下载.docx(16页珍藏版)》请在冰豆网上搜索。
美食评价系统
背景:
互联网时代下网络评论越来越随意,希望可以规化的进行。
2定义
美食评价系统为用户提供美食指导和参考。
任人都可注册为会员,个人资料包括姓名,性别,收藏的餐厅以及口味爱好。
会员可以收藏餐馆,浏览餐馆信息以及其他会员的评价。
餐厅必须向管理人员提出注册并审核通过后才能显示。
管理人员需到工商局和餐厅具体审查后才能通过。
会员可以提供来自餐馆提供的小票在次日来对用餐进行评价,一小票仅可提供一次评价。
餐馆则提供当日用餐小票记录给管理人员,用以核对用户提供的小票是否正确,然后系统则会审核评价有无不良信息,审核通过发布在餐厅信息上,并根据会员评价次数对给会员评星(1-5)。
个人信息和餐馆信息可被所有人访问,管理员信息只能管理员访问。
3参考资料
1.GB8567-88《计算机软件产品文件编制规》
2.GB/T11457-1995《软件工程术语》
3.GB1526—89信息处理--数据流程图、程序流程图、系统流程图、程序网络图和系统资源图的文件编制符号及约定
4.GB8566-88《软件开发规》
4系统分析与设计
4.1需求分析
4.1.1识别参与者
用户,餐厅,管理人员
4.1.2对需求进行捕获与描述
1用例名称:
注册个人用户执行者:
用户
目的:
完成一次注册个人用户的完整过程。
2用例名称:
用户登录执行者:
完成一次用户登陆的过程。
4用例名称:
填写与修改个人信息执行者:
填写和修改用户的个人信息,可由别人查阅。
5用例名称:
收藏餐厅执行者:
用户可以根据自己的喜好收藏餐厅。
6用例名称:
查询餐厅信息或个人信息执行者:
用户、餐厅
用户和餐厅可根据需求喜好查询餐厅信息或个人信息。
7用例名称:
注册餐厅执行者:
餐厅
完成一次注册餐厅信息的过程。
8用例名称:
修改餐厅介绍执行者:
根据餐厅需求,经过管理人员审核后修改餐厅介绍。
9用例名称:
发送当日发票执行者:
每日结束营业后,将给出的当日的发票号发送至管理人员。
10用例名称:
审核餐厅执行者:
管理人员
餐厅注册信息,修改信息,管理人员都要进行审核。
11用例名称:
增删餐厅执行者:
根据实际情况和个人要求,对餐厅信息进行管理。
13用例名称:
给用户评星执行者:
根据用户的评价次数,予以用户星级。
14用例名称:
修改餐厅信息执行者:
管理员
根据用户对餐厅进行评价和评星,来修改餐厅信息。
15用例名称:
添加或删除每日推荐美食执行者:
从评价为五星和四星的餐厅中挑选出一个,推荐其特殊菜。
3.1
用例ID号及用例名
3评价餐厅
3.2
用例概述
该用例描述用户根据从餐厅得到的小票号,来对餐厅进行评星和评价。
3.3
参与者:
3.4
前置条件(Pre-Conditions)
会员登录
3.5
后置条件(Post-Conditions)
将用户的评价和提供的小票号提交至管理人员。
3.6
事件流
3.6.1
基本事件流
(BasicFlow)
1)用户输入小票号。
2)用户给出评星。
3)用户输入评价。
4)用户确认评星和评价。
E-1
5)点击确定,系统显示提示评价已经被提交。
3.6.2
扩展事件流(AlternativeFlows)
E-1:
点击取消,则退出。
若有一项为空,返回评价页面。
12.1
12审核用户评价
12.2
该用例描述管理员根据发票号判断用户是否评论有效,然后再审核容有无违禁容,通过后发表。
12.3
12.4
管理员登录,用户评价
12.5
用用户评价修改餐厅信息
12.6
12.6.1
1确认系统中有无用户发送的发票号。
2审核评价有无违禁容。
E-2
3审核通过,并发表在餐厅信息中。
12.6.2
若系统中没有用户输入的发票号,则提示“无此发票号”,并提示用户再次输入发票号。
E-2:
若有违禁容,则提示“评价含有违禁容”,并提示用户再次输入评价。
4.1.3用例图
4.1.4分析与讨论
1)建模用例图的步骤、法?
步骤:
1.定义系统边界和围。
2.识别系统参与者。
3.发现用例。
4.描述用例及确定用例关系。
5.建立用例图。
6.定义用例图的层次结构。
法:
创建一个用例名时,要尽量使用主语动态动词和可以描述系统上执行的功能的名词,从整体考虑,用例图要获取和分析用户需求。
2)如识别系统的参与者?
应该如划分用例,应注意哪些问题?
参与者是与系统交互的实体,包括需要和系统交换信息的一切实体。
参与者不是系统的一部分,他们处于系统的外部。
参与者是一组角色。
根据每个用例都有其对应的参与者来划分用例,注意用例可大可小,但对应一个具体的用户目标
3)心得
设计用例图时要全面考虑到需求,将参与者划分出来,并且每个参与者都有对应的用例,最后才能更好地理解需求。
4.2建立对象模型
4.2.1候选类的数据字典
类名
中文
定义
User
可以在系统上注册信息,填写和修改个人信息,查阅他人信息、餐厅信息,收藏喜欢的餐厅。
Comment
评论
用户向餐厅提交的评价,要由管理人员审核。
PersonIn
个人信息
包括用户的爱好,收藏的餐厅,性别,评论次数,星级。
RestaurantIn
餐厅信息
主要用来展示审核通过的用户评论。
RestaurantId
餐厅介绍
展示餐厅的特色。
Restaurant
可以在系统上注册信息,填写和修改餐厅信息,查阅别的餐厅信息、个人信息。
Manager
审核餐厅和评论。
ModerateCo
审核评论
审核小票号是否存在,言论是否违禁,有问题则改变状态为未通过退回,没问题则改变状态为通过,添加到餐厅信息中。
4.2.2定义类
•属性
用户名(ID):
文本(String)
密码(Password):
数值(double)
•操作
登陆Ulogin()
修改密码Cpassword()
查询餐厅信息Qr()
查询用户信息Qu()
查询用户自己的评论Qc()
•属性
用户名(ID):
收藏的餐厅(Rest):
个人喜好(Like):
文本(String)
性别(Sex):
评论次数(Cc):
星级(Us):
•操作
修改Change()
收藏Collect()
评价(Comments):
星级(Star):
状态(State):
评论人(Men):
自查Selfcheck()
提醒用户评论状态Alarm()
修改评论状态Change_state()
发送评论Sentcomment()
审核餐厅
审核注册信息CheckIn()
审核餐厅简介CheckId()
编号(ID):
密码(Password):
注册Register()
登陆Rlogin()
发送发票Sent()
用户评价(Usercomment):
综合星级(Tstar):
评价人数(Count):
计算星级Cstar()
接收并增添评论Radd()
餐厅简介
地址(address):
特色菜系(Special):
招牌菜(SS):
今日特价(Promotion):
提交修改申请Apply()
修改简介Ci()
登陆Mlogin()
推送每日推荐美食Pf()
给用户评星Cus()
4.2.3绘制类图
审核餐厅和审核评论是管理人员的两个子类,分别用来管理餐厅和用户评论。
用户可以产生评论和修改个人信息,评论要经过自查后送至审核评论进行审核。
餐厅可以访问和修改餐厅简介,餐厅简介的一个子类为餐厅信息,专门用来接收审核通过的言论,并显示出来。
餐厅,用户可互相查看信息,管理人员可查看两者的信息。
重要的行为:
①评论:
由用户产生,产生后进行自查,审查通过送至审核评论,不通过留在评论界面。
然后审核由小票号审查和言论审查,审核通过修改评论状态为通过,并修改餐厅信息,审查未通过修改评论状态为未通过。
最后将评论返回至用户,用户可查看自己评论的状态。
②修改餐厅信息和个人信息:
首先要审核ID是否一致,之后要求属于密码,密码正确进入修改界面。
4.2.4包图
对于大型复杂系统,常需要把大量的模型元素用包组织起来,以便处理。
对所选系统的类进行分组,以便更清晰地了解系统的结构。
分为用户、餐馆和管理人员三个包。
4.2.5分析与讨论
1)建模类图的步骤、法?
1.确定类。
2.识别类的属性和操作。
3.识别类之间的关联。
4.定义类的结构和层次。
可用名字识别法识别类,以多角度确定类的属性,综合对象模型、动态模型和功能模型确定类的操作,之后,确定关联关系及多重性,利用继承组织类,考虑组合和聚集关系,最后考虑是否使用包图。
2)识别类有哪些法,你是如识别类的?
行为分析、名词识别法、CRC分析法、根据边界类、控制类、实体类。
从系统简介中找出所有的名词,去掉重复的名词。
之后将可合并的类划归为一类,考虑其是否有必要另成一类。
审