太原理工大学系统分析实验报告.doc

精品文档本科实验报告课程名称： 系统分析与设计 实验项目： 系统分析与设计实验 实验地点： 行逸楼B114 专业班级：软件 学号： 学生姓名： 指导教师： 孟东霞 2015年 11月4日一、实验目的 通过系统分析与设计实验，使学生在实际的案例中完成系统分析与系统设计中的主要步骤，并熟悉信息系统开发的有关应用软件，加深对信息系统分析与设计课程基础理论、基本知识的理解，提高分析和解决实际问题的能力，使学生在实践中熟悉信息系统分析与设计的规范，为后继的学习打下良好的基础。二、实验要求学生以个人为单位完成，自选题目，班内题目不重复，使用UML进行系统分析与设计，并完成实验报告。实验报告以纸质版（A4)在课程结束后二周上内提交（12周）。三、实验主要设备：台式或笔记本计算机四、实验内容1 选题及项目背景 美食评价系统 背景：互联网时代下网络评论越来越随意，希望可以规范化的进行。2 定义美食评价系统为用户提供美食指导和参考。任何人都可注册为会员，个人资料包括姓名，性别，收藏的餐厅以及口味爱好。会员可以收藏餐馆，浏览餐馆信息以及其他会员的评价。餐厅必须向管理人员提出注册并审核通过后才能显示。管理人员需到工商局和餐厅具体审查后才能通过。会员可以提供来自餐馆提供的小票在次日来对用餐进行评价，一张小票仅可提供一次评价。餐馆则提供当日用餐小票记录给管理人员，用以核对用户提供的小票是否正确，然后系统则会审核评价有无不良信息，审核通过发布在餐厅信息上，并根据会员评价次数对给会员评星（1-5）。个人信息和餐馆信息可被所有人访问，管理员信息只能管理员访问。3 参考资料 1GB8567-88 计算机软件产品文件编制规范2GB/T11457-1995 软件工程术语3GB 152689 信息处理-数据流程图、程序流程图、系统流程图、程序网络图和系统资源图的文件编制符号及约定 4GB8566-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-12审核评价有无违禁内容。E-23审核通过，并发表在餐厅信息中。12.6.2扩展事件流（Alternative Flows）：若系统中没有用户输入的发票号，则提示“无此发票号”，并提示用户再次输入发票号。：若有违禁内容，则提示“评价含有违禁内容”，并提示用户再次输入评价。4.1.3 用例图 4.1.4 分析与讨论1) 建模用例图的步骤、方法？ 步骤： 1.定义系统边界和范围。 2.识别系统参与者。 3.发现用例。 4.描述用例及确定用例关系。 5.建立用例图。 6.定义用例图的层次结构。 方法：创建一个用例名时，要尽量使用主语动态动词和可以描述系统上执行的功能的名词，从整体考虑，用例图要获取和分析用户需求。2) 如何识别系统的参与者？应该如何划分用例，应注意哪些问题？参与者是与系统交互的实体，包括需要和系统交换信息的一切实体。参与者不是系统的一部分，他们处于系统的外部。参与者是一组角色。根据每个用例都有其对应的参与者来划分用例，注意用例可大可小，但对应一个具体的用户目标3) 心得 设计用例图时要全面考虑到需求，将参与者划分出来，并且每个参与者都有对应的用例，最后才能更好地理解需求。4.2 建立对象模型 4.2.1 候选类的数据字典类名中文定义User用户可以在系统上注册信息，填写和修改个人信息，查阅他人信息、餐厅信息，收藏喜欢的餐厅。Comment评论用户向餐厅提交的评价，要由管理人员审核。Person In个人信息包括用户的爱好，收藏的餐厅，性别，评论次数，星级。Restaurant In餐厅信息主要用来展示审核通过的用户评论。Restaurant Id餐厅介绍展示餐厅的特色。Restaurant餐厅可以在系统上注册信息，填写和修改餐厅信息，查阅别的餐厅信息、个人信息。Manager管理人员审核餐厅和评论。Moderate Co审核评论审核小票号是否存在，言论是否违禁，有问题则改变状态为未通过退回，没问题则改变状态为通过，添加到餐厅信息中。 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活动图活动图的主要作用是表示系统的业务工作流和并发处理过程。针对自选系统主要的业务工作流绘制活动图。绘制活动图需要确定参与活动的对象、动作状态、动作流，以及对象流。针对用户产生评论和管理员审核的过程描述。 4.3.4状态图 状态机图表现一个对象（类）的生命史。对于一些实现重要行为动作的对象应当绘制状态机图。绘制状态机图需要确定一个对象的生命期可能出现的全部状态，哪些事件将引起状态的转移，将会发生哪些动作。对象为评论。 4.3.5 分析与讨论 比较顺序图与通信图、 活动图与状态图的应用1、 活动图与状态图 相同点：描述的图符基本一样。 可以描述一个系统或对象在生存期间的状态和行为。 可以描述一个系统或对象在多进程操作中的并发行为。 可以用条件分支图符描述一个系统或对象的行为控制流。 不同点：触发一个系统或对象的状态（活动）发生的转移的机制不同。 描述多个对象共同完成一个操作的机制不同。2、 顺序图与通信图 相同点：同属于交互图，用于描述对象间的动态关系。 在语义上等价，可互相转换。 不同点：建模切入点不同，顺序图强调时间顺序，通信图强调参与交互的对 象的组织。 建模元素各有特点，顺序图使用生命线和控制焦点，通信图描述路 径和链接。 两者不能完全替代，顺序图描述对象间消息传递的时间顺序，用于 分析交互的顺序，是按时间顺序对控制流建模。通信图描述对象间 的联系和传递的消息，用于描述一个操作的实现，是按对象组织关 系对控制流建模。4.4物理模型4.4.1 建立构件图系统实现的源代码、二进制码、执行码可以按照模块化的思想，用构件分别组织起来，明确系统各部分的功能职