太原理工大学系统分析报告实验报告材料_第1页
太原理工大学系统分析报告实验报告材料_第2页
太原理工大学系统分析报告实验报告材料_第3页
太原理工大学系统分析报告实验报告材料_第4页
太原理工大学系统分析报告实验报告材料_第5页
已阅读5页,还剩9页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

标准本科实验报告课程名称: 系统分析与设计实验项目: 《系统分析与设计》实验实验地点: 行逸楼B114专业班级:软件 学号:学生姓名:指导教师: 孟东霞2015年11月4日文案标准一、实验目的通过《系统分析与设计》实验,使学生在实际的案例中完成系统分析与系统设计中的主要步骤,并熟悉信息系统开发的有关应用软件,加深对信息系统分析与设计课程基础理论、基本知识的理解,提高分析和解决实际问题的能力,使学生在实践中熟悉信息系统分析与设计的规范,为后继的学习打下良好的基础。二、实验要求学生以个人为单位完成,自选题目,班内题目不重复,使用UML进行系统分析与设计,并完成实验报告。实验报告以纸质版(A4)在课程结束后二周上内提交(12周)。三、实验主要设备:台式或笔记本计算机四、实验内容选题及项目背景美食评价系统背景:互联网时代下网络评论越来越随意,希望可以规范化的进行。定义美食评价系统为用户提供美食指导和参考。任何人都可注册为会员,个人资料包括姓名,性别,收藏的餐厅以及口味爱好。会员可以收藏餐馆,浏览餐馆信息以及其他会员的评价。餐厅必须向管理人员提出注册并审核通过后才能显示。管理人员需到工商局和餐厅具体审查后才能通过。会员可以提供来自餐馆提供的小票在次日来对用餐进行评价,一张小票仅可提供一次评价。餐馆则提供当日用餐小票记录给管理人员,用以核对用户提供的小票是否正确,然后系统则会审核评价有无不良信息,审核通过发布在餐厅信息上,并根据会员评价次数对给会员评星(1-5)。个人信息和餐馆信息可被所有人访问,管理员信息只能管理员访问。参考资料1.GB8567-88 《计算机软件产品文件编制规范》2.GB/T11457-1995 《软件工程术语》3.GB1526—89信息处理--数据流程图、程序流程图、系统流程图、程序网络图和系统资源图的文件编制符号及约定4.GB8566-88 《软件开发规范》文案标准系统分析与设计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基本事件流1)用户输入小票号。(BasicFlow)2)用户给出评星。3)用户输入评价。4)用户确认评星和评价。E-15)点击确定,系统显示提示评价已经被提交。3.6.2扩展事件流(AlternativeFlows)E-1:点击取消,则退出。若有一项为空,返回评价页面。12.1 用例ID号及用例名12.2 用例概述12.3参与者:12.4前置条件(Pre-Conditions)12.5后置条件(Post-Conditions)12.6事件流12.6.1基本事件流(BasicFlow) 扩展事件流(AlternativeFlows)

审核用户评价该用例描述管理员根据发票号判断用户是否评论有效,然后再审核内容有无违禁内容,通过后发表。管理员管理员登录,用户评价用用户评价修改餐厅信息1确认系统中有无用户发送的发票号。E-12审核评价有无违禁内容。E-2审核通过,并发表在餐厅信息中。E-1:若系统中没有用户输入的发票号,则提示“无此发票号”,并提示用户再次输入发票号。E-2:若有违禁内容,则提示“评价含有违禁内容”,并提示用户再次输入评价。 用例图文案标准 分析与讨论建模用例图的步骤、方法?步骤:定义系统边界和范围。识别系统参与者。发现用例。描述用例及确定用例关系。建立用例图。定义用例图的层次结构。方法:创建一个用例名时,要尽量使用主语动态动词和可以描述系统上执行的功能的名词,从整体考虑,用例图要获取和分析用户需求。如何识别系统的参与者?应该如何划分用例,应注意哪些问题?参与者是与系统交互的实体,包括需要和系统交换信息的一切实体。参与者不是系统的一部分,他们处于系统的外部。参与者是一组角色。根据每个用例都有其对应的参与者来划分用例,注意用例可大可小,但对应一个具体的用户目标心得设计用例图时要全面考虑到需求,将参与者划分出来,并且每个参与者都有对应的用例,最后才能更好地理解需求。4.2 建立对象模型 候选类的数据字典类名 中文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)建模类图的步骤、方法?步骤:确定类。2.识别类的属性和操作。识别类之间的关联。4.定义类的结构和层次。方法:可用名字识别法识别类,以多角度确定类的属性,综合对象模型、动态模型和功能模型确定类的操作,之后,确定关联关系及多重性,利用继承组织类,考虑组合和聚集关系,最后考虑是否使用包图。)识别类有哪些方法,你是如何识别类的?行为分析、名词识别法、CRC分析法、根据边界类、控制类、实体类。从系统简介中找出所有的名词,去掉重复的名词。之后将可合并的类划归为一类,考虑其是否有必要另成一类。审核划分好的每个类,思考后面的步骤,其适不适合划归为一类。)解释关联的多重性?如何确定类的属性、操作、类之间的关联关系、组织类之间的继承?关联的多重性:对于每个关联,从一端看本端的一个对象可能与另一端的几文案标准个对象进行联系,把结果标注到连线的另一端。可以使用普通关联列表的方法帮助发现关联,也可通过添加关联角色和限定符以详细描述关联的性质。通常可以在两个方向上识别继承:自顶向下(从共性开始)或自底向上(从特殊的情形开始)。4.3 建立动态模型系统的动态行为模型由交互图(顺序图和协同图)、状态机图和活动图表达。在系统的分析和设计中应当对主要的UseCase和对象类绘制这些图形,以便分析系统的行为,印证和修改系统的静态结构,满足用户的需求,达到系统的目标。 顺序图主要描述了用户提交评论的过程。用户通过页面发送评论,管理员审核后反馈给用户。文案标准 通信图活动图活动图的主要作用是表示系统的业务工作流和并发处理过程。针对自选系统主要的业务工作流绘制活动图。绘制活动图需要确定参与活动的对象、动作状态、动作流,以及对象流。针对用户产生评论和管理员审核的过程描述。文案标准状态图状态机图表现一个对象(类)的生命史。对于一些实现重要行为动作的对象应当绘制状态机图。绘制状态机图需要确定一个对象的生命期可能出现的全部状态,哪些事件将引起状态的转移,将会发生哪些动作。对象为评论。 分析与讨论比较顺序图与通信图、 活动图与状态图的应用一、活动图与状态图相同点:①描述的图符基本一样。②可以描述一个系统或对象在生存期间的状态和行为。③可以描述一个系统或对象在多进程操作中的并发行为。④可以用条件分支图符描述一个系统或对象的行为控制流。不同点:①触发一个系统或对象的状态(活动)发生的转移的机制不同。②描述多个对象共同完成一个操作的机制不同。二、顺序图与通信图相同点:①同属于交互图,用于描述对象间的动态关系。②在语义上等价,可互相转换。不同点:①建模切入点不同,顺序图强调时间顺序,通信图强调参与交互的对象的组织。②建模元素各有特点,顺序图使用生命线和控制焦点, 通信图描述路径和链接。③两者不能完全替代,顺序图描述对象间消息传递的时间顺序,用于分析交互的顺序,是按时间顺序对控制流建模。通信图描述对象间的联系和传递的消息,用于描述一个操作的实现,是按对象组织关系对控制流建模。文案标准4.4物理模

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论