太原理工大学系统分析实验报告.docx
《太原理工大学系统分析实验报告.docx》由会员分享，可在线阅读，更多相关《太原理工大学系统分析实验报告.docx（18页珍藏版）》请在冰豆网上搜索。
太原理工大学系统分析实验报告
本科实验报告
课程名称：
系统分析与设计
实验项目：
《系统分析与设计》实验
实验地点：
行逸楼B114
专业班级：
软件学号：
学生姓名：
指导教师：
孟东霞
2015年11月4日
一、实验目的
通过《系统分析与设计》实验，使学生在实际的案例中完成系统分析与系统设计中的主要步骤，并熟悉信息系统开发的有关应用软件，加深对信息系统分析与设计课程基础理论、基本知识的理解，提高分析和解决实际问题的能力，使学生在实践中熟悉信息系统分析与设计的规，为后继的学习打下良好的基础。
二、实验要求
学生以个人为单位完成，自选题目，班题目不重复，使用UML进行系统分析与设计，并完成实验报告。
实验报告以纸质版（A4）在课程结束后二上提交（12）。
三、实验主要设备：
台式或笔记本计算机
四、实验容
1选题及项目背景
美食评价系统
背景：
互联网时代下网络评论越来越随意，希望可以规化的进行。
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）
Ｅ－１：
点击取消，则退出。
若有一项为空，返回评价页面。
12.1
用例ID号及用例名
12审核用户评价
12.2
用例概述
该用例描述管理员根据发票号判断用户是否评论有效，然后再审核容有无违禁容，通过后发表。
12.3
参与者：
管理员
12.4
前置条件（Pre-Conditions）
管理员登录，用户评价
12.5
后置条件（Post-Conditions）
用用户评价修改餐厅信息
12.6
事件流
12.6.1
基本事件流
（BasicFlow）
1确认系统中有无用户发送的发票号。
E-1
2审核评价有无违禁容。
E-2
3审核通过，并发表在餐厅信息中。
12.6.2
扩展事件流（AlternativeFlows）
Ｅ－１：
若系统中没有用户输入的发票号，则提示“无此发票号”，并提示用户再次输入发票号。
Ｅ－２：
若有违禁容，则提示“评价含有违禁容”，并提示用户再次输入评价。
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）：
文本（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（）
发送评论Sentcomment（）
审核餐厅
•属性
•操作
审核注册信息CheckIn（）
审核餐厅简介CheckId（）
餐厅
•属性
编号（ID）：
文本（String）
密码（Password）：
数值（double）
•操作
注册Register（）
登陆Rlogin（）
发送发票Sent（）
查询餐厅信息Qr（）
查询用户信息Qu（）
餐厅信息
•属性
用户名（ID）：
文本（String）
用户评价（Usercomment）：
文本（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建立动态模型
系统的动态行为模型由交互图（顺序图和协同图）、状态机图和活动图表达。
在系统的分析和设计中应当对主要的UseCase和对象类绘制这些图形，以便分析系统的行为，印证和修改系统的静态结构，满足用户的需求，达到系统的目标。
4.3.1顺序图
主要描述了用户提交评论的过程。
用户通过页面发送评论，管理员审核后反馈给用户。
4.3.2通信图
4.3.3活动图
活动图的主要作用是表示系统的业务工作流和并发处理过程。
针对自选系统主要的业务工作流绘制活动图。
绘制活动图需要确定参与活动的对象、动作状态、动作流，以及对象流。
针对用户产生评论和管理员审核的过程描述。
4.3.4状态图
状态机图表现一个对象（类）的生命史。
对于一些实现重要行为动作的对象应当绘制状态机图。
绘制状态机图需要确定一个对象的生命期可能出现的全部状态，哪些事件将引起状态的转移，将会发生哪些动作。
对象为评论。
4.3.5分析与讨论
比较顺序图与通信图、活动图与状态图的应用
1、活动图与状态图
相同点：
①描述的图符基本一样。
②可以描述一个系统或对象在生存期间的状态和行为。
③可以描述一个系统或对象在多进程操作中的并发行为。
④可以用条件分支图符描述一个系统或对象的行为控制流。
不同点：
①触发一个系统或对象的状态（活动）发生的转移的机制不同。
②描述多个对象共同完成一个操作的机制不同。
2、顺序图与通信图
相同点：
①同属于交互图，用于描述对象间的动态关系。
②在语义上等价，可互相转换。
不同点：
①建模切入点不同，顺序图强调时间顺序，通信图强调参与交互的对
象的组织。
②建模元素各有特点，顺序图使用生命线和控制焦点，通信图描述路
径和。
③两者不能完全替代，顺序图描述对象间消息传递的时间顺序，用于
分析交互的顺序，是按时间顺序对控制流建模。
通信图描述对象间
的联系和传递的消息，用于描述一个操作的实现，是按对象组织关
系对控制流建模。
4.4物理模型
4.4.1建立构件图
系统实现的源代码、二进制码、执行码可以按照模块化的思想，用构件分别组织起来，明确系统各部分的功能职责和软件结构。
4.4.2建立部署图
用户和餐馆登陆网页进行操作，管理员主要是登陆网页进行操作。
5.心得体会
虽然之前软工也制作过系统，但是是用结构化的法制作的，我对于面向对象的法还是不甚了解。
书上大部分也是文字说明，虽然给定了多制作法和优化法，但是自己实际画起来也是困难重重，比如类的确定，类的关系确定等。
自己网上也查阅了不少，但是能参考的例子也比较少，不过自己动手动脑制作也算是对自己的锻炼，对面向对象有了更深的了解，对以后的编程有很大的帮助。
升级会员 