第一篇：UML实验报告四
XI`AN TECHNOLOGICAL UNIVERSITY
实验报告
实验四 交互图 专
业：
信息与计算科学
班
级：
121001
姓
名：
刘修花
学
号：
121001125
实验学时：
课时
指导教师：
时华
成绩：
2015
年 10 月 30 日
西安工业大学实验报告 专业 信息与计算科学 班级 121001 姓名 刘修花 学号 121001125 实验课程 UML 系统建模 指导教师 时华 实验日期 2015-10-30 同实验者
实验项目 交互图 实验设备及器材 电脑 一、实验目的练习使用 Rational Rose 绘制时序图、协作图等交互图。
二、实验原理
时序图用以显示对象之间的动态合作关系。它强调对象之间消息发送的顺序，同时也显示对象之间的交互过程。
协作图同序列图是等价的，但着重描述对象间的协作关系。
三、
实验步骤、数据记录及处理
时序图
单击菜单中的“Browse”子菜单的“Interaction Diagram”选项，屏幕中出现与创建用例图类似的界面。选择
在这个界面中选择创建顺序图（Sequence），进入如下图所示界面。
订餐者订餐
根据订餐者订餐的时序图可以创建如下协作图：
4.1.2 商家管理店铺
根据商家管理店铺的时序图可以创建如下协作图
4.1.3 店铺管理员管理店铺信息
根据店铺管理员管理店铺信息的时序图可以创建如下协作图：
4.1.4 店铺管理员建立客户评价档案
根据店铺管理员建立客户评价档案的时序图可以创建如下协作图：
4.1.5 店铺管理员建立商家监察档案
根据店铺管理员建立商家监察档案的时序图可以创建如下协作图：
4.1.6 订单管理员管理订单
根据订单管理员管理订单的时序图可以创建如下协作图：
4.1.7 系统管理员管理订餐者信息
根据系统管理员管理订餐者信息的时序图可以创建如下协作图：
4.1.8 系统管理员管理商家信息
根据系统管理员管理商家信息的时序图可以创建如下协作图：
4.1.9 系统管理员维护系统
根据系统管理员维护系统的时序图可以创建如下协作图：
第二篇：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 实 验 报 告
实验一
用例图
一、实验结果
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实验报告总结
实验一 熟悉Rational Rose及建立用例模型 实验
二、时序图和协作图建模
实习三 UML类图与包图建模（2学时）实验四 状态图和活动图建模 实验五
组件与部署图
实验一 熟悉Rational Rose及建立用例模型
（2学时）
一、实验名称：熟悉（2学时）
二、实验目的与要求：
了解和掌握Rose建模工具的使用 掌握怎样进行案例需求分析； 掌握UML用例图建模技术
三、实验内容：
1、熟悉rose上机环境及设置
2、根据以下谈话设计出用例图
Rational Rose及建立用例模型
四、实验步骤：
见实验说明书
实习二（2学时）
一、实验名称：
时序图和协作图建模（2学时）
二、实验目的与要求：
了解和掌握Rose或Visio建模工具的使用
掌握怎样进行系统分析，并进行UML静态建模分析； 掌握UML时序图和协作图建模技术
三、实验内容：
根据以下谈话设计出时序图和协作图建模。
四、实验步骤：
、UML类图与包图建模（2学时）
一、实验名称：UML类图与包图建模（2学时）
二、实验目的与要求：
了解和掌握Rose或Visio建模工具的使用
掌握怎样进行系统分析，并进行UML动态建模分析；
三、实验内容：
四、实验步骤：
实习四（2学时）
一、实验名称：
状态图和活动图建模（2学时）
二、实验目的与要求：
了解和掌握Rose或Visio建模工具的使用
掌握怎样进行系统分析，并进行UML动态建模分析； 掌握UML状态图和活动图建模技术
三、实验内容：
四、实验步骤：
实习五
组件与部署图与代码生成（2学时）
一、实验名称：
组件与部署图（2学时）
二、实验目的与要求：
三、实验内容：
四、实验步骤：
第五篇：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的建模的步骤和方法，了解用例图和类图等的画法，了解系统的分析和建模方法。增加动手和思维能力，使自己更加的了解软件系统前期开发的软件定义和分析方法。
点击咨询 