第一篇：UML实验报告
一：需求分析
在我国十年前ATM（自动取款机）还是一个很新鲜的事物，现在在城市的大街小巷随处可见。我们在日常生活中也经常和ATM打交道。本章我们将以简化的ATM系统为例将前面几章中学到的用例图、类图、顺序图、状态图、活动图及协作图知识运用到此例中。二：银行ATM机系统UML建模设计 1.用例图
参与者“银行储户”和ATM机。简化后的ATM机仅有取款、存款及其余功能。其余功能不做详细说明。
银行储户在ATM机上完成取款、存款及其他业务。2.类图
整个银行系统包括了帐户库、银行储户库及ATM系统。
许多单个的帐户组成了帐户库。帐户具有帐户类型、帐户号、余额三个属性，均为private，其类型分别为char，int，double。六个操作分别为setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance为protected其余均为public。
setType设置帐户类型，返回类型为void，参数类型为char，输入帐户类型。getType获取帐户类型，返回类型为char，无参数。
setAccountNumbe设置帐户号，返回类型为void，参数类型为int，输入帐户号。getAccountNumbe获取帐户号，返回类型为int，无参数。
caculateBalance计算余额，返回类型为void，参数为double，第一个参数为输入存取款数额，第二个参数为存款余额，既为输入也为输出。getBalance获取帐户余额，返回类型为double，无参数。
许多银行储户组成了储户库。ATM系统包含了许多ATM机。银行储户及ATM机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。更多的属性及操作都可以一一加上，使这个类图更详细更完整，从而使参与项目的每个成员都能无歧义的明了整个设计的类的结构。同样对于一个真正的银行系统，这个类图过于简单。比如帐户类型我们可以先定义一个abstract class，它包含一个帐户最基本的属性及操作。而有些操作先定义为abstract，如余额的计算。然后再继承这个abstract class，我们可以有saving account 和checking account等等。不同的帐户有不同的余额计算方法，我们可以加上具体的算法。对于不同的帐户可能还有一些它特有的操作，我们也可以加上，比如saving account在存款达到多少时可以享受机票打折的优惠。通过类图不仅可以使设计者明确的表达自己的设计意图，也能帮组自己整理思路，充实及优化自己的设计。
3.顺序图
描述顾客在ATM机上取款时信息的流动情况。以时间为顺序。因为是示例图，所以整个过程是没有出现任何故障时的流程，并且只画到了取款结束。通过这个图，我们可以看出消息是如何在系统中不同对象之间进行交互。
通过流程图我们可以很清楚地看到系统是如何工作的，系统各部分之间的信息及控制是如何发送的，整个流程是否合理。流程图对我们的设计起到了很好的帮助作用。注意在本图没有一个生命线终端有一个“X”，这是因为这个流程中还未遇到有对象生命结束。当有对象生命结束时需在对应的生命线终端画“X”，表明这个对象在这时被销毁。
首先银行储户将ATM卡插入读卡机，读卡机将信息传给客户管理，客户管理提出查询密码，显示部分将输入密码请求显示出来….银行储户读卡机显示输入设备客户管理点钞机事务管理1: 插入ATM卡2: 接受ATM卡3: 查询密码4: 显示输入密码请求5: 输入密码6: 密码传递7: 请求确认密码的合法性8: 确认密码的合法性9: 询问服务类别10: 显示输入服务类别请求11: 输入取款请求12: 取消请求13: 询问取款数额14: 显示输入数额请求15: 输入取款数额16: 传递取款数额17: 询问取款数额确认18: 显示确认数额请求19: 输入确认20: 传递确认信息21: 数额合法性确认请求22: 确认数额的合法性23: 计算储户余额24: 出钞请求25: 出钞26: 取钞27: 传递余额并询问是否需要其它服务28: 显示储户余额并显示其它服务
第二篇：UML实验报告[推荐]
UML实验报告
班 级：软件0841
姓 名：张文成 学 号：081842173
实验内容：
用例建模、分析建模、设计建模（1）、设计建模（2）
实验一：用例建模
[实验目的] 〃掌握客户需求分析的方法和步骤
〃了解以用例驱动的软件开发方法 〃识别并编写用例
〃掌握用Rose 进行用例建模的具体方法和步骤
[实验内容] 要求学生根据周围的实际情况，自选一个小型应用项目，分析业务需求，识别并编写用例、绘制用例图以理解系统需求。亦可采用教师指定的“企业综合信息管理系统”中的“进销存管理子系统”
[实验原理和步骤] 建模原理：
(1)需求获取。以任务和客户为中心，通过会议、面谈等手段对客户需求进行调研，获得系统目标、范围和功能要求的初步说明。(2)用例分析。确定用例，同时采用分层思想，对用例的层次级别进行划分（高层用例、子系统级、用户目标级）
（3）用例描述。分层绘制用例图，撰写用例的文字描述（采用单栏格式）。
步骤：
（1）需求获取。自选题目，与相关客户、领域专家等反复商讨，获得系统目标、范围和功能要求的初步说明。（也可采用教师指定的题目：“企业综合信息管理系统”中的“进销存管理子系统”，但要仔细研读“企业现状”、“系统目标、范围和功能要求”等文字说明）。（2）用例分析。确定系统范围和边界、确定参与者、确定用例。（3）用例描述。分层绘制用例图、描述用例。
画图原理：
采用Rose 软件进行用例建模必须建立在完好的系统用例分析基础之上．只有做好系统用例分析，系统用例建模才能这到预期的效果。步骤：
（1）分层绘制用例图，每层采用“包”进行管理。
（2）以“企业综合信息管理系统”-> “进销存管理”子系统-> “销售管理”-> “合同管理”->“收款单处理”为主线，完成附录2 中的操作过程（亦可选择“企业综合信息管理系统”-> “进销存管理”子系统-> “库存管理”-> “原材料出库”->“领料单处理”主线）
[ 实验结果]
实验2 分析建模
[ 实验目的](1)理解面向对象系统分析和对象类建模(概念建模)的概念(2)了解和掌握面向对象系统分析的方法和步骤(3)了解和掌握寻找待开发系统中类(概念)的方法和技巧(4)掌握使用ROSE 绘制概念模型的方法
[ 实验内容] 在用例分析的基础上，选择第一个迭代周期打算开发的用例，建立相关的概念模型。
[ 实验原理和步骤] 建模原理：
(1)使用概念目录列表（见下图）和非正式分析法（识别出问题域的文本描述中的名词短语，然后将其作为概念或属性的候选对象。）相结合的方法识别概念。因此，待开发用例的文字描述中，名词可能成为概念或属性的候选对象；表示行为的动词词组有可能成为事务型或过程型对象；形容词词组有可能对应抽象的名词型概念。
采用的技术基本上就是：ER 图+纯行为+OO 的聚合、泛化。（2）最终关联的数量介于“需要知道”型关联与【“需要知道”型关联+“需要理解”型（从通用关联列表中派生出 的，见下图）】之间。
步骤：
（1）识别关键用例作为第一个迭代周期的开发目标（一般是在用例图中被依赖得比较多的用例）。可以选“企业综合信息管理系统”-> “进销存管理”子系统-> “库存管理”-> “原材料出库”->“领料单处理”主线中的“领料单处理”用例；也可以选“企业综合信息管理系统”-> “进销存管理”子系统-> “销售管理”-> “合同管理”->“收款单处理”主线中的“增加销售合同”或“收款单处理”用例。（其实，选“库存管理”主线更合适；当然，如果要实现产销一体化，以销售订单指导生产和采购，并实现零库存目标，那么一切工作就以销售管理为中心。即便如此，首选“增加合同”用例也更为合适。）
（2）识别概念和重要属性。
（3）建立概念间的关联。
画图原理：
（1）可以采用“逻辑视图”下的类图描述概念模型，只不过每个类中只有类名和属性，没有方法。在概念建模 阶段也没有必要确定属性的类型和访问属性。
（2）概念间的关联可以采用一般关联（无方向实线），当然，对于聚合和泛化，应采用相应的连线（组合：实心菱形+实线；聚合：空心菱形+实线；泛化：空三角形+实线）
步骤：
（0）前提条件：第一个迭代周期可以选“企业综合信息管理系统”
-> “进销存管理”子系统-> “库存管理”->“原材料出库”->“领料单处理”主线中的“领料单处理”用例；也可以选“企业综合信息管理系统”->“进销存管理”子系统-> “销售管理”-> “合同管理”->“收款单处理”主线中的“增加销售合同”或“收款单处理”用例。做好与此用例相关的概念模型
（1）建立相关的概念模型的基础上，在“逻辑视图”下的类图中描述概念模型，可以直接在类图main 中绘制，也可采用类似用例图中用过的分包机制
(2）绘制概念和重要属性。（3）绘制概念间的关联。
[ 实验结果]
[ 实验总结] ① 对重点实验结果进行分析；
② 实验中的问题和提高：对自己的分析或设计进行评价，指出合理和不足之处，提出改进的方案。
③ 收获与体会：筛选概念的要点；区分概念与属性的要点；关联取舍的要点；画图时如何防止关联重名。
实验3 设计建模（1）
[ 实验日期]2011年5月20日 [ 实验目的](1)理解顺序图的基本概念
（2）了解和掌握软件工程中用例逻辑时序的分析方法（3）掌握使用ROSE 创建顺序图的方法
[ 实验内容] 在用例模型和概念模型的基础上，对首选的用例进行事件分解，识别出系统事件（系统操作），（并写出契约的后置条件）；为每个系统事件画顺序图，为对象分配职责。
[ 实验原理和步骤] 原理：
(1)在系统顺序图中，所有的系统都被当成黑盒子看待，顺序图的重点是参与者发起的跨越系统边界的事件。
(2)系统事件是由某参与者发起的指向系统的输入事件。一个事件的发生能够触发一个响应操作的执行。
(3)请仔细研究下图,考察它是如何从左边的“购买商品”用例的文字描述中分解出3 个系统事件的。
（4）参照用例模型和概念模型，为每个系统操作估计后置条件。（实例创建、形成关联、属性修改）（5）按照设计模式为对象分配职责。
步骤：
（1）分析首选用例的文字描述，按事件进行分解，识别出系统事件。（下面以“企业综合信息管理系统”-> “进销存管理”子系统-> “销售管理”-> “合同管理”->“收款单处理”主线中的“收款单处理”用例为例）。
我们暂不考虑批处理。第一个核对，因为要将“货款金额填写到合同中”。后置条件显然有“销售合同”的属性修改。此合同显然已经存在，不需要创建，但需要根据合同编号find，然后形成关联。第二个核对需要根据合同明细到仓库的“存货明细”（概念模型中还没有）中去查。此核对发生前虽然敲了一下键盘，但随后并没有新的消息穿越系统边界，因此这仍然是同一个系统事件。先考虑成功场景，应该向库存系统发提货单（概念模型中还没有）就结束了。后续的削减库存（核销）、预警显然不是销售管理员的职权，并且真正的核销必须由仓库的发货人执行，才能保证货帐一致。并且“生产厂家”与“邮购公司”的运作方式不同，后者是自己的员工取货并邮寄，而前者还有可能是来人来车取货，这时仓库收到取货单后并不能立即自动处理（开发货单），必须等取货人到达才能处理。
根据题意，本项目应该是“生产厂家”模式。这又存在一个问题，如
果在开出提货单后不修改库存，可能影响并发用户和后续付款单的处理。所以有必要设计一个“临时存货明细”（概念模型中还没有）（不是真实的“存货明细”）供修改，何时按存货明细”进行刷新应该是库存管理系统的事（比如每天夜里刷新，但因为雨雪天气，取货 人迟迟不提货，是提货单作废（相当于退回销售系统，付款单变为未处理）还是就强行刷新（此时有冲突危险）？）失败场景。向“生产调度部门”发送“产品生产申请单”。如果是专门为此单进行生产，那么还应该有库存系统发来的“产品入库通知处理”用例来调用本用例进行发货。本题显然一概根据付款单运作，因此如果失败，就不处 理付款单，但按日期把它排在待处理付款单的前面。从前面的分析来看，就一个系统事件，我们就命名为“付款单处理(pb:付款单)”（2）为每个系统事件估计后置条件。(以上已做了部分分析)（3）按设计模式进行设计。
首先考虑控制者,领域控制者选参与者角色，即“销售人员”。为了避免使用FORM,窗口等表示层对象,我们人造一 个类”应用协调者”向控制者发送消息。
[ 实验结果]
① 对重点实验结果进行分析；
② 实验中的问题和提高：对自己的分析或设计进行评价，指出合理和不足之处，提出改进的方案。
③ 收获与体会：事件分解的要点；控制者选择的要点；绘制顺序图的要点。
[ 实验总结] ① 对重点实验结果进行分析；
② 实验中的问题和提高：对自己的分析或设计进行评价，指出合理和不足之处，提出改进的方案。
③ 收获与体会：事件分解的要点；控制者选择的要点；绘制顺序图的要点。
实验4 设计建模（2）
[ 实验日期] 2011年5月27日 [ 实验目的](1)理解面向对象类之间关联关系的概念(2)了解和掌握分析类之间的关联关系的方法
(3)了解和掌握待开发系统中类之间关联关系的分析方法(4)完善设计类图，掌握使用ROSE 对关联进行建模的过程
[ 实验内容] 根据设计建模（1）中的交互分析，进一步设计关联和对象可见性（补
上遗漏的关联）,完善设计类图。
[ 实验原理和步骤] 建模原理：
（1）关联关系描绘了给定类的对象个体之间的语义连接，是类与类之间的连接。关联可以分为一般关联、聚合关 联、组合关联和依赖关联等。
（2）一般关联包括一对类的二元关联及多个类之间的多元关联。
（3）聚合(Aggregation)表示整体和部分之间较强的关联关系，聚合关系的多重性大于1，则称为共享聚合。
（4）组合(Composition)关系表示整体和部分之间有比聚合关系更强的关系，它们之间是一对一的关系，即同生死共存亡，组合关系不能共享。
（5）依赖关系是一种使用关系，表现为一个对象仅仅调用了另一个对象的服务。可以使用下列的指导方针列出暂时性的关系：
(1)存在两个或两个以上的类相互之间就可能有关联。(2)类的操怍(成员函数)的参数列表里出现其他类的对象。(3)一个类包含另一个类的对象(对象成员)。(4)根据一般常识可能会出现的关联。步骤：
（1）分析已建立的设计类图和交互图，进一步设计关联和
对象可见性（补上遗漏的关联）。（下面以“企业综合 信息管理系统”-> “进销存管理”子系统-> “销售管理”-> “合同管理”->“收款单处理”主线中 的“收款单处理”用例为例）。
在销售管理子系统中，定义的各个类之间一般都有关系发生。销售人员和客户(大客户)共同签署销售合同，销售合同中涉及到多种可以销售的产品，合同经公司经理审查并签字后该合同才能生效，付款单需要客户付款，销售人员签发催款单向客户催缴欠款，销售人员制定销售计划，销售人员要检查督促执行期合同按合同执行、履 约，履约后的合同转到履约合同数据库存档备查等等。例如：
（a）销售人员与客户：一般关联，多对多
（b）销售合同与合同明细，销售计划与计划明细：组合。（c）付款单与客户：依赖关系。《如果付款单类中有“统计付款金额(客户类客户对象)”操作的话，付款 单类就依赖客户类》（2）完善设计类图 画图原理：
（1）关联关系描绘了给定类的对象个体之间的语义连接，是类与类之间的连接。关联可以分为一般关联、聚合关 联、组合关联和依赖关联等。
（2）一般关联包括一对类的二元关联及多个类之间的多元关联。
（3）聚合(Aggregation)表示整体和部分之间较强的关联关系，聚合关系的多重性大于1，则称为共享聚合。
（4）组合(Composition)关系表示整体和部分之间有比聚合关系更强的关系，它们之间是一对一的关系，即同生死共存亡，组合关系不能共享。
（5）依赖关系是一种使用关系，表现为一个对象仅仅调用了另一个对象的服务。步骤：
（1）在关联和对象可见性分析的基础上，补充一般关联、组合，泛化、依赖
（a）一般关联关系要注意关联的命名以及哪个是role A 哪个是role B。
(b)一般关联选中role B detail 中的aggregate，就变成聚合；再选中by value 就变成组合。(c)依赖画虚线箭头。（2）完善设计类图
[实验结果] ① 对重点实验结果进行分析；
② 实验中的问题和提高：对自己的分析或设计进行评价，指出合理和不足之处，提出改进的方案。
③ 收获与体会：分析依赖关系的要点，绘制关联的要点。通过实验了解UML的建模的步骤和方法，了解用例图和类图等的画法，了解系统的分析和建模方法。增加动手和思维能力，使自己更加的了解软件系统前期开发的软件定义和分析方法。
第三篇：UML实验报告
计 《面向对象分析与设计 U ＭL 》 实验报告 学 学
号:180 １0 ８２１３ 姓 姓
名: 庞志伟 班 班
级:08 级软件 2 班
指导老师:姚 姚 宇峰 峰 实验及作业一 一、实验目得
了解软件工程等基础知识,为后续得统一建模语言 UＭL 知识得学习做好准备工作。
二、实验设备与环境
装有Ｖisiｏ、RatｈionalRoｓｅ得计算机。
三、实验内容 １、复习阐述“软件工程开发模型”得相关概念,并分析各种模型得优缺点,写成实验报告。
２、熟悉ＵMＬ软件设计工具 Vｉsio、Ratioｎal Rose 得安装及环境
四、实验过程及结果 1、软件工程开发模型有(1)瀑布模型,(2)原型模型,(3)螺旋模型,(4)喷泉模型(１)瀑布模型 将功能得实现与设计分开,便于分工协作,即采用结构化得分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试与运行维护等六个基本活动,并且规定了它们自上而下、相互衔接得固定次序,如同瀑布流水,逐级下落。
优点: 1)为项目提供了按阶段划分得检
瀑布模型查点。
2)当前一阶段完成后,您只需要去关注后续阶段。
3)可在迭代模型中应用瀑布模型。
缺点: １)在项目各个阶段之间极少有反馈。
2)只有在项目生命周期得后期才能瞧到结果。
３)通过过多得强制完成日期与里程碑来跟踪各个项目阶段。
(2)原型模型 原型模型又称快速原型,它就是增量模型得另一种形式;它就是在开发真实系统之前,构造一
个原型,在该原型得基础上,逐渐完成整个系统得开发工作、快速原型模型得第一步就是建造一个快速原型,实现客户或未来得用户与系统得交互,用户或客户对原型进行评价,进一步细化待开发软件得需求。通过逐步调整原型使其满足客户得要求,开发人员可以确定客户得真正需求就是什么;第二步则在第一步得基础上开发客户满意得软件产品。
优点:克服瀑布模型得缺点,减少由于软件需求不明确带来得开发风险。
缺点:所选用得开发技术与工具不一定符合主流得发展;快速建立起来得系统结构加上连续得修改可能会导致产品质量低下。
(３)螺旋模型 螺旋模型采用一种周期性得方法来进行系统开发。这会导致开发出众多得中间版本。使用它,项目经理在早期就能够为客户实证某些概念。该模型就是快速原型法,以进化得开发方式为中心,在每个项目阶段使用瀑布模型法、这种模型得每一个周期都包括需求定义、风险分析、工程实现与评审 4 个阶段,由这４个阶段进行迭代、软件开发过程每迭代一次,软件开发又前进一个层次。螺旋模型基本做法就是在“瀑布模型”得每一个开发阶段前引入一个非常严格得风险识别、风险分析与风险控制,它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险,直到所有得主要风险因素都被确定。
优点: １)设计上得灵活性,可以在项目得各个阶段进行变更。
2)以小得分段来构建大型系统,使成本计算变得简单容易。
3)客户始终参与每个阶段得开发,保证了项目不偏离正确方向以及项目得可控性。
4)随着项目推进,客户始终掌握项目得最新信息 , 从而她或她能够与管理层有效地交互。
5)客户认可这种公司内部得开发方式带来得良好得沟通与高质量得产品。
缺点: 很难让用户确信这种演化方法得结果就是可以控制得。建设周期长,而软件技术发展比较快,所以经常出现软件开发完毕后,与当前得技术水平有了较大得差距,无法满足当前用户需求。
(4)喷泉模型 喷泉模型就是一种以用户需求为动力,以对象为驱动得模型,主要用于采用对象技术得软件开发项目。该模型认为软件开发过程自下而上周期得各阶段就是相互迭代与无间隙得特性。软件得某个部分常常被重复工作多次,相关对象在每次迭代中随之加入渐进得软件成分。无间隙指在各项活动之间无明显边界,如分析与设计活动之间没有明显得界限,由于对象概念得引入,表达分析、设计、实现等活动只用对象类与关系,从而可以较为容易地实现活动得迭代与无间隙,使其开发自然地包括复用。
优点: 喷泉模型不像瀑布模型那样,需要分析活动结束后才开始设计活动,设计活动结束后才开始编码活动。该模型得各个阶段没有明显得界限,开发人员可以同步进行开发。其优点就是可以提高软件项目开发效率,节省开发时间,适应于面向对象得软件开发过程。
缺点: 由于喷泉模型在各个开发阶段就是重叠得,因此在开发过程中需要大量得开发人员,因此不利于项目得管理、此外这种模型要求严格管理文档,使得审核得难度加大,尤其就是面对可能随时加入各种信息、需求与资料得情况。
五、实验小结: 通过本次实验让我了解了软件工程开发得 4 中主要模型与这些模型得优缺点、初次安装并使用 UML 软件设计工具 Visio 与Ｒatioｎaｌ Rose 使我初步认识了软件开发中 UML 得设计、实验及作业二 一、实验目得
1、了解面向对象得基本概念 2、熟悉面向对象得分析、设计过程 3、了解基于 UML 得面向对象分析设计过程
二、实验设备与环境
装有 Visio、ＲａthｉｏnaｌRose 得计算机。
三、实验内容 1、熟悉 Raｔｉonal Rosｅ得使用。
２、熟悉利用统一建模语言进行分析、设计软件得过程,完成作业:论述面向对象(OO)方法得特点、优势以及存在得问题。
四、实验过程及结果 面向对象方法(Oｂject—Oriented Ｍethod)就是一种把面向对象得思想应用于软件开发过程中,指导开发活动得系统方法,简称 OO(Objｅcｔ－Ｏｒｉenｔed)方法,就是建立在“对象“概念基础上得方法学。对象就是由数据与容许得操作组成得封装体,与客观实体有直接对应关系,一个对象类定义了具有相似性质得一组对象、而每继承性就是对具有层次关系得类得属性与操作进行共享得一种方式。所谓面向对象就就是基于对象概念,以对象为中心,以类与继承为构造机制,来认识、理解、刻画客观世界与设计、构建相应得软件系统、主要特征:封装性,多态性 优势:(１)强调从现实世界中客观存在得事物(对象)出发来认识问题域与构造系统,这就使系统开发者大大减少了对问题域得理解难度,从而使系统能更准确地反映问题域。
(2)运用人类日常得思维方法与原则(体现于 OO 方法得抽象、分类、继承、封装、消息通讯等基本原则)进行系统开发,有益于发挥人类得思维能力,并有效地控制了系 统复杂性。
(3)对象得概念贯穿于开发过程得终,使各个开发阶段得系统成分具良好得对应,从而显著地提高了系统得开发效率与质量,并大大降低系统维护得难度。
(４)对象概念得一致性,使参与系统开发得各类人员在开发得各所段具有共同语言,有效地改善了人员之间得 交流与协作、(5)对象得相对稳定性与对易变因素隔离,增强了系统得应变能力。
(6)对象类之间得继承关系与对象得相对独立性,对软件复用提供了强有力得支持。
存在得问题:(1)软件重用性差
(2)软件可维护性差
(3)开发出得软件不能满足用户需要 五、实验小结: 通过本次实验了解 Raｔional Ｒose 得使用。学习利用统一建模语言进行分析、设计软件得过程,通过上网查询,了解有关面向对象(OO)方法得特点、优势以及存在得问题。
实验及作业三
三、实验目得
1、讲解用例、参与者、ＵＭＬ语境建模技术与ＵＭＬ需求建模技术。
2、通过实例使学生有一个初步认识,为后面得学习打下坚实得基础。
四、实验设备与环境
装有 Visｉｏ、RationａlRosｅ得计算机。
四、实验内容 1、掌握“参与者”、“用例”、“各种关系”在Ｖisio 或 Raｔｉonal Rosｅ中得设计方法。体会用例图得设计方法。
2、以图书馆管理系统为例,完成其用例图得设计。并书写实验报告、四、实验过程及结果 图书管理系统中得参与者有读者、图书管理员与系统管理员、读者能够进行查询,借书(有扩展关系预定与续借),还书,罚款(有扩展关系超期罚款与损坏罚款),登陆;图书管理员能够进行登陆,处理借书,处理还书(有扩展关系收罚金),解除预定;读者订书借书还书删除预订信息图书管理员<
图书维护读者信息维护新增图书删除图书系统维护系统管理员 五、实验小结: 通过本次实验第一次使用ＲOＳE 画用例图使我初步了解了什么就是用例图,如何进行画用例图。通过画图书管理系统得用例图后,使我能够正确使用ＲOSE 软件画用例图、实验及作业四 一、实验目得
讲解静态视图中得类图、对象图等建模知识,并通过图书馆管理系统得静态视图进行实例讲解,为学生以后得学习打下坚实得基础。
二、实验设备与环境
装有Ｖiｓio、ＲationalRose 得计算机。
三、实验内容 实现并改进图书馆管理系统中得类图。
四、实验过程及结果 根据实验三得用例图画出如下得类图、1、读者,图书管理员,与系统管理员都就是用户,就是用户类得泛化;2、登录与用户就是依赖关系,登录需要取决于用户类里得用户名与密码。
五、实验小结:
通过本次实验就是我初步了解了如何将用例图转换成相应得类图。在画类图就是需要弄清楚类与类之间得各种关系,只有弄清楚类之间得关系后才能画好类图。
《面向对象分析与设计(UML)》实验五 一、实验目得
了解动态视图中得状态图得设计、建模,包括:状态机、状态、转移等概念。
二、实验设备与环境
装有 Vｉsio、RａtionaｌRose 得计算机、三、实验内容 实现并改进图书馆管理系统中得状态图、四、实验过程及结果
新书可借书删除已预定 已借书借书 预定借书还书取消预定
新用户 账户可借书可借书不可借书还书达借书上限删除用户户欠款还款借书超期或者损坏 五、实验小结:
通过本次实验得练习,让我初步了解并使用 Rｏsｅ画图书管理系统得状态图。在画图中通过分析画出图书管理系统得每个状态过程。
《面向对象分析与设计(UML)》实验六 一、实验目得
了解活动图得设计方法及建模技术。重点介绍了活动图得构成要素、判定、对象流、泳道等概念,以及活动图与状态图得关系、活动图与流程图得区别。
二、实验设备与环境
装有 Viｓio、ＲａtionaｌRｏse 得计算机。
三、实验内容 实现并改进图书馆管理系统中得活动图。
四、实验过程及结果
登录更新用户信息更新新图书信息 五、实验小结:
通过本实验得练习就是我初步了解了如何画活动图、《面向对象分析与设计(ＵML)》实验七 一、实验目得
了解动态视图中得时序图、协作图得设计、建模。
二、实验设备与环境
装有 Visio、RatiｏｎａlRose 得计算机。
三、实验内容 实现并改进图书馆管理系统得时序图,并在此基础上做出相应得协作图。
四、实验过程及结果 图书管理系统时序图: 1、借阅者预定图书
2、系统管理员添加新图书
３、系统管理员删除旧图书 借阅者 图书系统 图书名 预定记录登陆查找返回查找...预定图书生成预定记录系统管理员 图书系统 图书名 图书条目添加...查找返回创建新...4、图书管理员处理还书 系统管理员 图书系统 图书名 图书条录删除图书...查找返回删除图书...删除...图书管理员 还书 图书名 借阅者 借书记录 图书条目扫描...查找图书条目更新图书...删除借阅...更新借阅者可借图...查找
5、图书管理员处理借书 协作图如下: １、借阅者借书 2、图书管理员处理还书 ３、图书管理员处理借书 ４、系统管理员新增图书 图书管理员 借书 图书名 借阅者 借书记录 图书条目查找图...查找查找图书...查找...验证借阅者...查找创建借阅...借阅者 图书系统图书名图书目录借书记录1: 验证借阅者ID2: 预定图书4: 预定3: 查找图书名5: 创建借书记录图书管理员图书系统借书记录图书名 图书目录1: 查找借阅者ID2: 还书4: 还书 5: 更新记录3: 更新目录图书管理员图书系统借书记录图书目录图书名预定记录4: 验证是否达借书数量上限1: 验证借阅者ID5: 借书2: 查找是否有预定记录3: 更新借书记录6: 更新记录
5、系统管理员删除旧图
五、实验小结
通过这 8个课时得课程学习,使我初步了解什么就是时序图与协作图,如何使用Ｒose 画时序图与协作图。时序图就是消息时间顺序得交互图,描述了对象之间消息传递得时间顺序,在实验课上通过分析与画出了图书管理系统得时序图。而协作图描述得就是与对象结构相关得信息,表示一个类操作得实现。通过时序图可以清楚得了解到图书管理系统所有对象之间消息传递得时间顺序,通过协作图又能够清楚得瞧到各个对象之间得结构关系。
Ｒ ＲOSE 双向工程实验八 五、实验目得
1、了解 UML 模型与代码得对应关系。
２、了解 ROSE 得双向工程、六、实验设备与环境
装有Ｖｉsiｏ、RatｉonaｌRosｅ得计算机。
六、实验内容 1、掌握正向工程在 Visio 或Ｒationaｌ Ｒose 中得实现、体会类图中类关系在源代码中得体现。
(１)简单类、在类中添加属性与方法、类可见性设置。
(2)类图中得关系:泛化关系、关联关系(包括一对一关联、一对多关联、多对多关联、聚合关系、组合关系)、依赖关系、实现关系、系统管理员图书系统图书名图书目录1: 添加新书 2: 查找3: 更新目录系统管理员图书系统图书名 图书目录删除图书1: 2: 查找3: 更新
请依次将上述实验内容得ＵML 图与生成得代码附在实验过程及结果中,并说明UMＬ中得模型在源代码中就是否体现、２、掌握逆向工程在 Visio 或 Ratioｎａl Rｏse 中得实现。体会 Rａtional Ｒoｓe 在阅读代码中得好处。
六、实验过程及结果 1.1 在 Rｏse 得 LｏgicａlＶiew 下新建简单类Ｐｅopｌe 如下:
通过使用 UＭＬ中得正向工程得到代码如下:
1。２类图中得关系 Ａ:泛化关系
生成代码如下:
B:关联关系
(1)一对一:
生成代码如下:
(2)一对多
生成代码如下:
(３)多对多
ﻩ生成代码如下:
(4)聚合关系
生成代码如下:
C:依赖关系:
生成代码如下:
D:实现关系:
生成代码如下:
七、实验小结: 通过本次课程得学习与实验得联系就是我初步了解到如何使用Rose 进行ＵML 得正向工程与逆向工程,通过正向工程可以将类图转化成代码,通过逆向工程可以将代码转换正相应得类。
组件图与配置图设计 实验九 九 一、实验目得
1、了解组件图得概念及应用。
２、了解配置图得概念及应用。
二、实验设备与环境
装有 Visio、Rａtiｏnal Ｒｏse 得计算机。
三、实验内容 1、实现并完善图书管理系统中得组件图、配置图、四、实验过程及结果 1、组件图: 通过对系统中得组件与组件得接口进行建模得到如下图书馆管理系统组件图:
2、部署图: 通过对系统中得节点进行建模得到如下图书管理系统得部署图:
五、实 验小结: 通过这次课时得学习,使我初步了解 了什么就是组件图与部署图。组件图描述 了软件得各种组件与它们之间得依赖关系。而部署图即配置图,配置图描述了运行 软件得系统中硬件与软件得物理结构、通 过实验得练习,我完成得图书管理系统得 组件图与部署图。
图书管理系统图书条目图书借书记录预定记录读者信息数据库服务器借书机图书管理员系统管理员
第四篇：UML实验报告
UML 实 验 报 告
实验一
用例图
一、实验结果
1、整理实验结果
2、小结实验心得体会
用例模型用于需求分析阶段，它描述了待开发系统的功能需求，并驱动了需求分析之后各阶段的开发工作。用例图是UML中用来对系统的动态方面进行建模的7种图之一。用例图描述了用例、参与者以及它们之间的关系。用例图从用户角度描述系统功能，并指出各功能的操作者。
通过本次实验，我熟悉 Rational Rose 建模环境，更加清楚的了解了用例图的语义和功能，如何清晰明了的识别参与者、用例，学会了如何使用事件流描述用例。同时掌握了用例间的类属关系、Include关系和Extend关系的语义、功能和应用。最后通过本次实验学习了如何使用用例图为系统的上下文以及系统的需求建模。
二、思考题
1、如果要删除参与者、用例，请问是在导航窗口删除，还是在绘图窗口删除？
答：都可以删除，但在绘图窗口中有两种删除方式：一种是只删除参与者、用例，而不改变其在导航窗口中的存在，另一种是从建模中完全删除。
2、如果要删除参与者和用例的联系，用例和用例的联系，请问是在绘图中删除，还是在参与者或用例的设置对话框中删除？ 答：都可以删除。
实验二
类对象模型的建立
一、实验结果 1．整理实验结果。
2．小结实验心得体会。
类图是面向对象系统建模最常用的图，描述了类图、接口集、协作以及它们之间的关系。类图描述了系统的静态设计视，该视主要体现系统的功能需求，即系统应该提供给用户的服务。
通过本次实验，加深了我对类图语义的理解和功能的应用，掌握了类之间的联系，关联、依赖、聚合等，同时基本掌握了在 Rational Rose中绘制类的关联、依赖、泛化关系。
二、思考题
选中一个模型对象，点击鼠标右键，比较快捷菜单项“Edit——Delete”与“Edit——Delete from Model”，它们二者之间区别在哪里？
答：“Edit——Delete”只删除绘图窗口中的图形，而不改变其在导航窗口中的存在；“Edit——Delete from Model” 是从建模中完全删除。
实验三
顺序图、协作图
一、实验结果 1.整理实验结果。
2.小结实验心得体会
顺序图描述了对象之间的动态合作关系，它强调对象之间消息发送的时间顺序，同时显示对象之间的交互。协作图与顺序图是同构的，Rose 可自动转换。顺序图是强调消息的交互作用图，协作图描述了对象间的关系，是强调发送和接收消息的对象的组织结构的交互作用图。
通过本次实验，掌握了对图书管理功能中的借书用例、还书用例进行动态建模。实验过程中由于对Rational Rose工具软件的不熟识，导致出现了不该出现的错误。在设计阶段，顺序图中需要引入边界类和控制类，在识别对象职责的基础上，需要将消息转换为类的方法，为方法定义参数、返回值类型，便于计算机的实现。其中，为方法定义参数、返回值类型的时候，还是不能够快速准确的作出判断。
实验四
活动图
一、实验结果 1．整理实验结果。
2．小结实验心得体会
在UML中，活动图是为系统的动态方面建模的7个图之一。活动图主要是一个流图，它描述了从活动到活动的控制流，它还可以用来描述对象在控制流的不同点从一个状态转移到另一个状态时的对象流。
通过本次实验，我对活动图的语义和功能有了更深层次的理解和应用，并对活动图的组成部分，包括动作状态、活动状态、分支、分叉和泳道、对象流，逐一进行了学习。同时基本掌握了用活动图来描述系统中“借出图书”用例的业务过程。实验过后本应该有完整的截图，由于自己的粗心马虎，造成截图的不完整性。
实验五
状态图
一、实验结果 1．整理实验结果。
2.小结实验心得体会。
状态图描述了一个特定对象的所有可能状态，以及引起状态跃迁的事件。状态图用来模拟系统的动态方面，这些动态方面指系统对象按事件发生顺序排序的行为。状态图可以用来描述整个系统、子系统或类的动态方面，还可以用来描述用力的一个脚本。
通过本次实验，我熟悉了状态图的基本功能和使用方法。掌握了如何使用建模工具绘制状态图方法。同时完成了图书管理业务中，资源项“ResourceItem”的状态图。
实验六
组件图和部署图
一、实验结果 1．整理实验结果。
2．小结实验心得体会。
组件图和部署图是用来为面向对象系统的物理实现建模的两种图。组件图描述了组件、组件间的关系，表示了组件之间的组织和依赖关系，它用来为系统的静态实现视建模。部署图描述了节点和运行其上的组件的配置，它用来模拟系统的静态部署视。
通过本次实验，我理解了组件图的基本概念及组件图的应用：逻辑部署。理解了部署图的基本概念。及部署图的应用：物理部署。掌握了组件图和部署图绘制的方法。完成了系统的组件图和系统的部署图。
二、思考题
1.为什么要求相对应的类名、组件名和实现组件的文件名相同？
答：相应的名字中能够找到相应的类的信息。如果组件名、类名和 Java 文件名不相同，会出现实体类的语法错误。
实验七
正向工程
一、实验报告要求 1．整理实验结果。
2．小结实验心得体会。
正向工程是对一个系统物理结构实现的高层抽象性、逻辑性及独立性设计的传统处理过程。通过本次试验，学会了利用 Rose 工具生成代码框架及生成数据库脚本，同时在实现过程中使用转换后的代码和数据库脚本。了解了Java 编程综合练习。
二、思考题
1．在本案例中，并未对实体类 ResourceTitle 设置主键，系统在生成数据库脚本时是如何处理的？
答：（1）设置类的持久化特性和主键：在导航窗口右击类，如“Loan”，选择快捷菜单“Open Standard Specification”菜单项，打开类设置对话框。选中“Detail”选项卡中的“Persistent”特性。点击 OK按钮，关闭设置对话框。然后，在导航窗口中展开类的属性，鼠标右击类的某个属性，如类“Loan”的属性“LoanID”，选中快捷菜单中的“Data Modeler”的“Part of Object Identity”属性，这样，在生成数据模型时，该属性就成为表 Loan 的主键。（2）创建数据库组件。（3）在导航窗口中选择所生成的数据库模式 S_0，单击鼠标右键，选择快捷菜单项“Data Modeler——Forward Engineer”，出现生成数据库脚本的导航界面，鼠标单击“Next”按钮，在导航界面输入脚本文件的保存路径，注意 SQL Server2000 的脚本文件扩展名用.sql。单击“Next”直至完成脚本文件的生成。
2.本案例中，ResourceTitle 与BookTitle、DiscTitle的继承关系，SQL Server 2000 关系型数据库的转换合理吗？如不合理，请问该如何修改？ 答：不合理。
第五篇：UML实验报告
《OO & UML》实验报告
班级：
学号：
姓名：
实验一
业务建模
一、实验目的
二、实验内容
三、实验过程和结果分析
四、总结
1． 实验内容总结 2． 心得体会
点击咨询 