太原理工大学系统分析报告实验报告材料
本科实验报告
课程名称：系统分析与设计
实验项目：《系统分析与设计》实验
实验地点：行逸楼B114
专业班级：软件学号：
学生：
指导教师：孟东霞
2015年11月4日
一、实验目的
通过《系统分析与设计》实验，使学生在实际的案例中完成系统分析与系统设计中的主要步骤，并熟悉信息系统开发的有关应用软件，加深对信息系统分析与设计课程基础理论、基本知识的理解，提高分析和解决实际问题的能力，使学生在实践中熟悉信息系统分析与设计的规，为后继的学习打下良好的基础。
二、实验要求
学生以个人为单位完成，自选题目，班题目不重复，使用UML进行系统分析与设计，并完成实验报告。实验报告以纸质版（A4)在课程结束后二周上提交（12周）。
三、实验主要设备：台式或笔记本计算机
四、实验容
1 选题及项目背景
美食评价系统
背景：互联网时代下网络评论越来越随意，希望可以规化的进行。
2 定义
美食评价系统为用户提供美食指导和参考。任何人都可注册为会员，个人资料包括，性别，收藏的餐厅以及口味爱好。会员可以收藏餐馆，浏览餐馆信息以及其他会员的评价。餐厅必须向管理人员提出注册并审核通过后才能显示。管理人员需到工商局和餐厅具体审查后才能通过。会员可以提供来自餐馆提供的小票在次日来对用餐进行评价，一小票仅可提供一次评价。餐馆则提供当日用餐小票记录给管理人员，用以核对用户提供的小票是否正确，然后系统则会审核评价有无不良信息，审核通过发布在餐厅信息上，并根据会员评价次数对给会员评星（1-5）。个人信息和餐馆信息可被所有人访问，管理员信息只能管理员访问。
3 参考资料
1．GB8567-88 《计算机软件产品文件编制规》
2．GB/T11457-1995 《软件工程术语》
3．GB 1526—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用例名称：添加或删除每日推荐美食执行者：管理人员目的：从评价为五星和四星的餐厅中挑选出一个，推荐其特殊菜。
4.1.3 用例图
3.1
用例ID 号及用例名 3 评价餐厅 3.2
用例概述 该用例描述用户根据从餐厅得到的小票号，来对餐厅进行评星和评价。 3.3
参与者： 用户 3.4
前置条件（Pre-Conditions ） 会员登录 3.5
后置条件（Post-Conditions ） 将用户的评价和提供的小票号提交至管理人员。 3.6
事件流 3.6.1 基本事件流
（Basic Flow ） 1) 用户输入小票号。 2)
用户给出评星。 3)
用户输入评价。 4)
用户确认评星和评价。E-1 5) 点击确定，系统显示提示评价已经被提交。
3.6.2 扩展事件流（Alternative Flows ） Ｅ－１：点击取消，则退出。若有一项为空，返回评价页面。
12.1
用例ID 号及用例名 12 审核用户评价 12.2
用例概述 该用例描述管理员根据发票号判断用户是否评论有效，然后再审核容有无违禁容，通过后发表。 12.3
参与者： 管理员 12.4
前置条件（Pre-Conditions ） 管理员登录，用户评价 12.5
后置条件（Post-Conditions ） 用用户评价修改餐厅信息
12.6
事件流 12.6.1 基本事件流
（Basic Flow ） 1确认系统中有无用户发送的发票号。E-1 2审核评价有无违禁容。E-2
3审核通过，并发表在餐厅信息中。
12.6.2 扩展事件流（Alternative Flows ） Ｅ－１：若系统中没有用户输入的发票号，则提示“无此发票号”，
并提示用户再次输入发票号。
Ｅ－２：若有违禁容，则提示“评价含有违禁容”，并提示用户再
次输入评价。
4.1.4 分析与讨论
1)建模用例图的步骤、方法？
步骤：
1.定义系统边界和围。
2.识别系统参与者。
3.发现用例。
4.描述用例及确定用例关系。
5.建立用例图。
6.定义用例图的层次结构。
方法：创建一个用例名时，要尽量使用主语动态动词和可以描述系统上执行的功能的名词，从整体考虑，用例图要获取和分析用户需求。
2)如何识别系统的参与者？应该如何划分用例，应注意哪些问题？
参与者是与系统交互的实体，包括需要和系统交换信息的一切实体。参与者不是系统的一部分，他们处于系统的外部。参与者是一组角色。
根据每个用例都有其对应的参与者来划分用例，注意用例可大可小，但对应一个具体的用户目标
3)心得
设计用例图时要全面考虑到需求，将参与者划分出来，并且每个参与者都有对应的用例，最后才能更好地理解需求。
4.2 建立对象模型
4.2.1 候选类的数据字典
4.2.2定义类
用户
?属性
用户名（ID）：文本(String)
密码（Password）：数值（double）
?操作
登陆Ulogin()
修改密码Cpassword()
查询餐厅信息Qr()
查询用户信息Qu()
查询用户自己的评论Qc()
个人信息
?属性
用户名（ID）：文本(String)
收藏的餐厅(Rest)：文本(String)
个人喜好(Like)：文本(String)
性别(Sex)：文本(String)
评论次数(Cc):数值（double）
星级（Us）:数值（double）
?操作
修改Change()
收藏Collect()
评论
?属性
评价(Comments)：文本(String)
星级(Star)：数值（double）
状态(State)：文本(String)
评论人(Men):文本(String)
?操作
自查Selfcheck()
提醒用户评论状态Alarm()
审核评论
?属性
?操作
修改评论状态Change_state()
发送评论Sent comment()
审核餐厅
?属性
?操作
审核注册信息Check In()
审核餐厅简介Check Id()
餐厅