太原理工大学系统分析实验报告.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系统分析与设计
需求分析
识别参与者
]
用户,餐厅,管理人员
对需求进行捕获与描述
1用例名称:
注册个人用户执行者:
用户
目的:
完成一次注册个人用户的完整过程。
2用例名称:
用户登录执行者:
用户
'
目的:
完成一次用户登陆的过程。
4用例名称:
填写与修改个人信息执行者:
用户
目的:
填写和修改用户的个人信息,可由别人查阅。
5用例名称:
收藏餐厅执行者:
用户
目的:
用户可以根据自己的喜好收藏餐厅。
6用例名称:
查询餐厅信息或个人信息执行者:
用户、餐厅
目的:
用户和餐厅可根据需求喜好查询餐厅信息或个人信息。
7用例名称:
注册餐厅执行者:
餐厅
目的:
完成一次注册餐厅信息的过程。
8用例名称:
修改餐厅介绍执行者:
餐厅
)
目的:
根据餐厅需求,经过管理人员审核后修改餐厅介绍。
9用例名称:
发送当日发票执行者:
餐厅
目的:
每日结束营业后,将给出的当日的发票号发送至管理人员。
10用例名称:
审核餐厅执行者:
管理人员
目的:
餐厅注册信息,修改信息,管理人员都要进行审核。
>
11用例名称:
增删餐厅执行者:
管理人员
目的:
根据实际情况和个人要求,对餐厅信息进行管理。
13用例名称:
给用户评星执行者:
管理人员
目的:
根据用户的评价次数,予以用户星级。
14用例名称:
修改餐厅信息执行者:
管理员
|
目的:
根据用户对餐厅进行评价和评星,来修改餐厅信息。
15用例名称:
添加或删除每日推荐美食执行者:
管理人员
目的:
从评价为五星和四星的餐厅中挑选出一个,推荐其特殊菜。
]
用例ID号及用例名
3评价餐厅
用例概述
^
该用例描述用户根据从餐厅得到的小票号,来对餐厅进行评星和评价。
参与者:
用户
,
前置条件(Pre-Conditions)
会员登录
后置条件(Post-Conditions)
将用户的评价和提供的小票号提交至管理人员。
.
事件流
基本事件流
【
(BasicFlow)
1)用户输入小票号。
2)用户给出评星。
3)用户输入评价。
4)用户确认评星和评价。
E-1
5)!
6)点击确定,系统显示提示评价已经被提交。
扩展事件流(AlternativeFlows)
E-1:
点击取消,则退出。
若有一项为空,返回评价页面。
[
用例ID号及用例名
12审核用户评价
》
用例概述
该用例描述管理员根据发票号判断用户是否评论有效,然后再审核内容有无违禁内容,通过后发表。
参与者:
管理员
:
前置条件(Pre-Conditions)
管理员登录,用户评价
后置条件(Post-Conditions)
|
用用户评价修改餐厅信息
事件流
(
基本事件流
(BasicFlow)
1确认系统中有无用户发送的发票号。
E-1
2审核评价有无违禁内容。
E-2
3审核通过,并发表在餐厅信息中。
—
扩展事件流(AlternativeFlows)
E-1:
若系统中没有用户输入的发票号,则提示“无此发票号”,并提示用户再次输入发票号。
E-2:
若有违禁内容,则提示“评价含有违禁内容”,并提示用户再次输入评价。
,
用例图
分析与讨论
1)建模用例图的步骤、方法
步骤:
$
1.定义系统边界和范围。
2.识别系统参与者。
3.发现用例。
4.描述用例及确定用例关系。
5.建立用例图。
,
6.定义用例图的层次结构。
方法:
创建一个用例名时,要尽量使用主语动态动词和可以描述系统上执行的功能的名词,从整体考虑,用例图要获取和分析用户需求。
2)如何识别系统的参与者应该如何划分用例,应注意哪些问题
参与者是与系统交互的实体,包括需要和系统交换信息的一切实体。
参与者不是系统的一部分,他们处于系统的外部。
参与者是一组角色。
¥
根据每个用例都有其对应的参与者来划分用例,注意用例可大可小,但对应一个具体的用户目标
3)心得
设计用例图时要全面考虑到需求,将参与者划分出来,并且每个参与者都有对应的用例,最后才能更好地理解需求。
建立对象模型
候选类的数据字典
:
类名
中文
定义
User
—
用户
可以在系统上注册信息,填写和修改个人信息,查阅他人信息、餐厅信息,收藏喜欢的餐厅。
Comment
评论
用户向餐厅提交的评价,要由管理人员审核。
]
PersonIn
个人信息
包括用户的爱好,收藏的餐厅,性别,评论次数,星级。
RestaurantIn
餐厅信息
主要用来展示审核通过的用户评论。
RestaurantId
餐厅介绍
展示餐厅的特色。
Restaurant
、
餐厅
可以在系统上注册信息,填写和修改餐厅信息,查阅别的餐厅信息、个人信息。
Manager
管理人员
审核餐厅和评论。
^
ModerateCo
审核评论
审核小票号是否存在,言论是否违禁,有问题则改变状态为未通过退回,没问题则改变状态为通过,添加到餐厅信息中。
定义类
【
用户
•属性
用户名(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()
绘制类图
…
审核餐厅和审核评论是管理人员的两个子类,分别用来管理餐厅和用户评论。
用户可以产生评论和修改个人信息,评论要经过自查后送至审核评论进行审核。
餐厅可以访问和修改餐厅简介,餐厅简介的一个子类为餐厅信息,专门用来接收审核通过的言论,并显示出来。
(
餐厅,用户可互相查看信息,管理人员可查看两者的信息。
重要的行为:
①评论:
由用户产生,产生后进行自查,审查通过送至审核评论,不通过留在评论界面。
然后审核由小票号审查和言论审查,审核通过修改评论状态为通过,并修改餐厅信息,审查未通过修改评论状态为未通过。
最后将评论返回至用户,用户可查看自己评论的状态。
②修改餐厅信息和个人信息:
首先要审核ID是否一致,之后要求属于密码,密码正确进入修改界面。
`
包图
,
对于大型复杂系统,常需要把大量的模型元素用包组织起来,以方便处理。
对所选系统的类进行分组,以便更清晰地了解系统的结构。
分为用户、餐馆和管理人员三个包。
分析与讨论
1)建模类图的步骤、方法
>
步骤:
1.确定类。
2.识别类的属性和操作。
3.识别类之间的关联。
4.定义类的结构和层次。
方法:
可用名字识别法识别类,以多角度确定类的属性,综合对象模型、动态模型和功能模型确定类的操作,之后,确定关联关系及多重性,利用继承组织类,考虑组合和聚集关系,最后考虑是否使用包图。
…
2)识别类有哪些方法,你是如何识别类的
行为分析、名词识别法、CRC分析法、根据边界类、控制类、实体类。
从系统简介中找出所有的名词,去掉重复的名词。
之后将可合并的类划归为一类,考虑其是否有必要另成一类。
审核划分好的每个类,思考后面的步骤,其适不适合划归为一类。
3)解释关联的多重性如何确定类的属性、操作、类之间的关联关系、组织类之间的继承
关联的多重性:
对于每个关联,从一端看本端的一个对象可能与另一端的几个对象进行联系,把结果标注到连线的另一端。
可以使用普通关联列表的方法帮助发现关联,也可通过添加关联角色和限定符以详细描述关联的性质。
通常可以在两个方向上识别继承:
自顶向下(从共性开始)或自底向上(从特殊的情形开始)。
建立动态模型
系统的动态行为模型由交互图(顺序图和协同图)、状态机图和活动图表达。
在系统的分析和设计中应当对主要的UseCase和对象类绘制这些图形,以便分析系统的行为,印证和修改系统的静态结构,满足用户的需求,达到系统的目标。
顺序图
主要描述了用户提交评论的过程。
用户通过页面发送评论,管理员审核后反馈给用户。
通信图
活动图
活动图的主要作用是表示系统的业务工作流和并发处理过程。
针对自选系统主要的业务工作流绘制活动图。
绘制活动图需要确定参与活动的对象、动作状态、动作流,以及对象流。
针对用户产生评论和管理员审核的过程描述。
状态图
状态机图表现一个对象(类)的生命史。
对于一些实现重要行为动作的对象应当绘制状态机图。
绘制状态机图需要确定一个对象的生命期可能出现的全部状态,哪些事件将引起状态的转移,将会发生哪些动作。
对象为评论。
分析与讨论
比较顺序图与通信图、活动图与状态图的应用
1、活动图与状态图
相同点:
①描述的图符基本一样。
②可以描述一个系统或对象在生存期间的状态和行为。
③可以描述一个系统或对象在多进程操作中的并发行为。
④可以用条件分支图符描述一个系统或对象的行为控制流。
不同点:
①触发一个系统或对象的状态(活动)发生的转移的机制不同。
②描述多个对象共同完成一个操作的机制不同。
2、顺序图与通信图
相同点:
①同属于交互图,用于描述对象间的动态关系。
②在语义上等价,可互相转换。
不同点:
①建模切入点不同,顺序图强调时间顺序,通信图强调参与交互的对
象的组织。
②建模元素各有特点,顺序图使用生命线和控制焦点,通信图描述路
径和链接。
③两者不能完全替代,顺序图描述对象间消息传递的时间顺序,用于
分析交互的顺序,是按时间顺序对控制流建模。
通信图描述对象间
的联系和传递的消息,用于描述一个操作的实现,是按对象组织关
系对控制流建模。
物理模型
建立构件图
系统实现的源代码、二进制码、执行码可以按照模块化的思想,用构件分别组织起来,明确系统各部分的功能职责和软件结构。
建立部署图
用户和餐馆登陆网页进行操作,管理员主要是登陆网页进行操作。
5.心得体会
虽然之前软工也制作过系统,但是是用结构化的方法制作的,我对于面向对象的方法还是不甚了解。
书上大部分也是文字说明,虽然给定了许多制作方法和优化方法,但是自己实际画起来也是困难重重,比如类的确定,类的关系确定等。
自己网上也查阅了不少,但是能参考的例子也比较少,不过自己动手动脑制作也算是对自己的锻炼,对面向对象有了更深的了解,对以后的编程有很大的帮助。