太原理工大学系统分析实验报告文档格式.docx
《太原理工大学系统分析实验报告文档格式.docx》由会员分享，可在线阅读，更多相关《太原理工大学系统分析实验报告文档格式.docx（18页珍藏版）》请在冰豆网上搜索。
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）
Ｅ－１：
点击取消，则退出。
若有一项为空，返回评价页面。
[
12审核用户评价
》
该用例描述管理员根据发票号判断用户是否评论有效，然后再审核内容有无违禁内容，通过后发表。
管理员登录，用户评价
用用户评价修改餐厅信息
（
1确认系统中有无用户发送的发票号。
2审核评价有无违禁内容。
E-2
3审核通过，并发表在餐厅信息中。
—
若系统中没有用户输入的发票号，则提示“无此发票号”，并提示用户再次输入发票号。
Ｅ－２：
若有违禁内容，则提示“评价含有违禁内容”，并提示用户再次输入评价。
用例图
分析与讨论
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）：
收藏的餐厅（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（）
绘制类图
审核餐厅和审核评论是管理人员的两个子类，分别用来管理餐厅和用户评论。
用户可以产生评论和修改个人信息，评论要经过自查后送至审核评论进行审核。
餐厅可以访问和修改餐厅简介，餐厅简介的一个子类为餐厅信息，专门用来接收审核通过的言论，并显示出来。
餐厅，用户可互相查看信息，管理人员可查看两者的信息。
重要的行为：
①评论：
由用户产生，产生后进行自查，审查通过送至审核评论，不通过留在评论界面。
然后审核由小票号审查和言论审查，审核通过修改评论状态为通过，并修改餐厅信息，审查未通过修改评论状态为未通过。
最后将评论返回至用户，用户可查看自己评论的状态。
②修改餐厅信息和个人信息：
首先要审核ID是否一致，之后要求属于密码，密码正确进入修改界面。
`
包图
对于大型复杂系统，常需要把大量的模型元素用包组织起来，以方便处理。
对所选系统的类进行分组，以便更清晰地了解系统的结构。
分为用户、餐馆和管理人员三个包。
分析与讨论
1）建模类图的步骤、方法
1.确定类。
2.识别类的属性和操作。
3.识别类之间的关联。
4.定义类的结构和层次。
可用名字识别法识别类，以多角度确定类的属性，综合对象模型、动态模型和功能模型确定类的操作，之后，确定关联关系及多重性，利用继承组织类，考虑组合和聚集关系，最后考虑是否使用包图。
2）识别类有哪些方法，你是如何识别类的
行为分析、名词识别法、CRC分析法、根据边界类、控制类、实体类。
从系统简介中找出所有的名词，去掉重复的名词。
之后将可合并的类划归为一类，考虑其是否有必要另成一类。
审核划分好的每个类，思考后面的步骤，其适不适合划归为一类。
3）解释关联的多重性如何确定类的属性、操作、类之间的关联关系、组织类之间的继承
关联的多重性：
对于每个关联，从一端看本端的一个对象可能与另一端的几个对象进行联系，把结果标注到连线的另一端。
可以使用普通关联列表的方法帮助发现关联，也可通过添加关联角色和限定符以详细描述关联的性质。
通常可以在两个方向上识别继承：
自顶向下（从共性开始）或自底向上（从特殊的情形开始）。
建立动态模型
系统的动态行为模型由交互图（顺序图和协同图）、状态机图和活动图表达。
在系统的分析和设计中应当对主要的UseCase和对象类绘制这些图形，以便分析系统的行为，印证和修改系统的静态结构，满足用户的需求，达到系统的目标。
顺序图
主要描述了用户提交评论的过程。
用户通过页面发送评论，管理员审核后反馈给用户。
通信图
活动图
活动图的主要作用是表示系统的业务工作流和并发处理过程。
针对自选系统主要的业务工作流绘制活动图。
绘制活动图需要确定参与活动的对象、动作状态、动作流，以及对象流。
针对用户产生评论和管理员审核的过程描述。
状态图
状态机图表现一个对象（类）的生命史。
对于一些实现重要行为动作的对象应当绘制状态机图。
绘制状态机图需要确定一个对象的生命期可能出现的全部状态，哪些事件将引起状态的转移，将会发生哪些动作。
对象为评论。
分析与讨论
比较顺序图与通信图、活动图与状态图的应用
1、活动图与状态图
相同点：
①描述的图符基本一样。
②可以描述一个系统或对象在生存期间的状态和行为。
③可以描述一个系统或对象在多进程操作中的并发行为。
④可以用条件分支图符描述一个系统或对象的行为控制流。
不同点：
①触发一个系统或对象的状态（活动）发生的转移的机制不同。
②描述多个对象共同完成一个操作的机制不同。
2、顺序图与通信图
①同属于交互图，用于描述对象间的动态关系。
②在语义上等价，可互相转换。
①建模切入点不同，顺序图强调时间顺序，通信图强调参与交互的对
象的组织。
②建模元素各有特点，顺序图使用生命线和控制焦点，通信图描述路
径和链接。
③两者不能完全替代，顺序图描述对象间消息传递的时间顺序，用于
分析交互的顺序，是按时间顺序对控制流建模。
通信图描述对象间
的联系和传递的消息，用于描述一个操作的实现，是按对象组织关
系对控制流建模。
物理模型
建立构件图
系统实现的源代码、二进制码、执行码可以按照模块化的思想，用构件分别组织起来，明确系统各部分的功能职责和软件结构。
建立部署图
用户和餐馆登陆网页进行操作，管理员主要是登陆网页进行操作。
5.心得体会
虽然之前软工也制作过系统，但是是用结构化的方法制作的，我对于面向对象的方法还是不甚了解。
书上大部分也是文字说明，虽然给定了许多制作方法和优化方法，但是自己实际画起来也是困难重重，比如类的确定，类的关系确定等。
自己网上也查阅了不少，但是能参考的例子也比较少，不过自己动手动脑制作也算是对自己的锻炼，对面向对象有了更深的了解，对以后的编程有很大的帮助。
升级会员 