本科实验报告课程名称：系统分析与设计实验项目：《系统分析与设计》实验实验地点：行逸楼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用例名称：添加或删除每日推荐美食执行者：管理人员目的：从评价为五星和四星的餐厅中挑选出一个，推荐其特殊菜。

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-15)点击确定，系统显示提示评价已经被提交。

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-23审核通过，并发表在餐厅信息中。

12.6.2 扩展事件流（AlternativeFlows）Ｅ－１：若系统中没有用户输入的发票号，则提示“无此发票号”，并提示用户再次输入发票号。

Ｅ－２：若有违禁内容，则提示“评价含有违禁内容”，并提示用户再次输入评价。

4.1.3 用例图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()餐厅•属性编号(ID)：文本(String)密码(Password)：数值（double）•操作注册Register()登陆Rlogin()发送发票Sent()查询餐厅信息Qr()查询用户信息Qu()餐厅信息•属性用户名（ID）：文本(String)用户评价(User comment)：文本(String)综合星级(Tstar)：数值（double）评价人数(Count)：数值（double）•操作计算星级Cstar()接收并增添评论Radd()餐厅简介•属性地址(address):文本(String)特色菜系(Special)：文本(String)招牌菜(SS)：文本(String)今日特价(Promotion)：文本(String)•操作提交修改申请Apply()修改简介Ci()管理人员•属性编号(ID)：文本(String)密码(Password)：数值（double）•操作登陆Mlogin()查询餐厅信息Qr()查询用户信息Qu()推送每日推荐美食Pf()给用户评星Cus()4.2.3绘制类图审核餐厅和审核评论是管理人员的两个子类，分别用来管理餐厅和用户评论。

用户可以产生评论和修改个人信息，评论要经过自查后送至审核评论进行审核。

餐厅可以访问和修改餐厅简介，餐厅简介的一个子类为餐厅信息，专门用来接收审核通过的言论，并显示出来。

餐厅，用户可互相查看信息，管理人员可查看两者的信息。

重要的行为：①评论：由用户产生，产生后进行自查，审查通过送至审核评论，不通过留在评论界面。

然后审核由小票号审查和言论审查，审核通过修改评论状态为通过，并修改餐厅信息，审查未通过修改评论状态为未通过。

最后将评论返回至用户，用户可查看自己评论的状态。

②修改餐厅信息和个人信息：首先要审核ID是否一致，之后要求属于密码，密码正确进入修改界面。

4.2.4包图对于大型复杂系统，常需要把大量的模型元素用包组织起来，以方便处理。

对所选系统的类进行分组，以便更清晰地了解系统的结构。

分为用户、餐馆和管理人员三个包。

4.2.5分析与讨论1）建模类图的步骤、方法？步骤：1.确定类。

2.识别类的属性和操作。

3.识别类之间的关联。

4.定义类的结构和层次。

方法：可用名字识别法识别类，以多角度确定类的属性，综合对象模型、动态模型和功能模型确定类的操作，之后，确定关联关系及多重性，利用继承组织类，考虑组合和聚集关系，最后考虑是否使用包图。

2）识别类有哪些方法，你是如何识别类的？行为分析、名词识别法、CRC分析法、根据边界类、控制类、实体类。

从系统简介中找出所有的名词，去掉重复的名词。

之后将可合并的类划归为一类，考虑其是否有必要另成一类。

审核划分好的每个类，思考后面的步骤，其适不适合划归为一类。

3）解释关联的多重性？如何确定类的属性、操作、类之间的关联关系、组织类之间的继承？关联的多重性：对于每个关联，从一端看本端的一个对象可能与另一端的几个对象进行联系，把结果标注到连线的另一端。

可以使用普通关联列表的方法帮助发现关联，也可通过添加关联角色和限定符以详细描述关联的性质。

通常可以在两个方向上识别继承：自顶向下（从共性开始）或自底向上（从特殊的情形开始）。

4.3 建立动态模型系统的动态行为模型由交互图（顺序图和协同图）、状态机图和活动图表达。

在系统的分析和设计中应当对主要的Use Case和对象类绘制这些图形，以便分析系统的行为，印证和修改系统的静态结构，满足用户的需求，达到系统的目标。

4.3.1顺序图主要描述了用户提交评论的过程。

用户通过页面发送评论，管理员审核后反馈给用户。

4.3.2 通信图4.3.3活动图活动图的主要作用是表示系统的业务工作流和并发处理过程。