UML练习题

UML练习题（精选6篇）

UML练习题 篇1

2．UML的的客户需求分析、系统分析和系统设计阶段产生的模型，其描述图符（完全相同）。

3．类和对象都有属性，它们的差别是：类描述了属性的类型，而对象的属性必须有（具体值）。

4．UML系统分析阶段产生的包图描述了系统的（系统体系层次结构）。

1．在UML软件开发过程系统分析阶段产生的对象模型有三种模型。它们是：对象的静态 模型、对象的 动态模型和对象的 系统功能 模型。2．在UML的对象类图中，类之间的关系有 泛化、实现、聚集、依赖和关联 5种。

3．共享聚集的“部分”对象可以是任意“整体”对象的一部分，表示事物的整体/部分关系较弱的情况，“整体”端的重数应该是n。4．在UML软件开发过程的需求分析和系统分析阶段，建立对象类模型的步骤分为 寻找确定对象类、定义类的接口、定义类之间的关系、建立对象类图 和 建立系统包图。

5．组合聚集是指“整体”拥有它的“部分”，它具有强的物主身份，表示事物的整体/部分关系较强的情况。“部分”生存在“整体”中，不可分离，它们与“整体”一起存在或消亡。“整体”的重数必须是1。

1．封装是指把对象的（属性和操作）结合在一起，组成一个独立的对象。

2．封装是一种（信息隐蔽）技术，目的是使对象的生产者和使用者分离，使对象的定义和实现分开。

3．面向对象方法中的（继承）机制使子类可以自动地拥有（复制）父类全部属性和操作。

4．使得在多个类中能够定义同一个操作或属性名，并在每一个类中有不同的实现的一种方法是（接口）。

5．UML的软件以（类）为中心，以系统体系结构为主线，采用循环、迭代、渐增的方式进行开发。

6．UML的（静态）模型图由类图、对象图、包图、构件图和配置图组成。

7．UML的（动态）模型图由活动图、顺序图、状态图和合作图组成。

8．UML的最终产物就是最后提交的可执行的软件系统和（相应的软件文档资料）。

9．在UML的需求分析建模中，（用例）模型图必须与用户反复交流并加以确认。

1．软件开发模型有 瀑布模型、螺旋模型 和增量模型 等3种主要模型。2．UML分析和设计模型由三类模型图表示。三类模型图是：模型图和 3．UML开发过程是一种二维结构软件开发过程，软件项目开发过程流包括的核心工作内容是： 分析、设计、实现、测试 和 配置 4．UML视图和构建视图。

5．UML中有10种基本图可以完整地描述出所建造的系统，这10种图是 类图、用力 图、协作 图、顺序 图、状态 图、活动图、构件 图、部署 图、包 图和对象 图。

1．可行性研究分析包括经济可行性分析、技术可行性分析和（法律可行性分析。

2．UML的客户需求分析模型包括（用例）模型、类图、对象图和活动图组成。

3．UML客户需求分析使用的CRC卡上“责任”一栏的内容主要描述类的（属性）和操作。

4．UML客户需求分析产生的用例模型描述了系统的（功能要求）。

5．在UML的需求分析建模中，用例模型必须与（用户）反复交流并加以确认。

6．在UML的需求分析建模中，对用例模型中的用例进行细化说明应使用（活动图。7．活动图中分劈和同步接合图符是用来描述（多进程的并发处理行为。

1．软件项目的可行性研究分析中，技术可行性研究包括 经济、技术、法律 3部分组成。2．在UML软件开发过程的需求分析阶段，建立用例模型的步骤分为确定系统的边界和范围、确定系统的执行者和用例、对用例进行描述、定义用例之间的关系 和审核用例模型。

3．用例图中以实线方框表示系统的范围和边界，在系统边界内描述的是 用例，在边界外描述的是执行者。

4．用例模型中的执行者可以是 人 也可以是 外部系统。

UML实训总结 篇2

通过一个学期的Uml学习，我从书本上获取了基本的理论知识，而真正的学以致用，将书本理论知识运用到实际的过程，是这次UML实训的体现。

三个周的UML实训，主要是围绕着一个实训题目“基于UML系统需求分析与设计--合倍利业务流管理系统”进行的，以小组为单位进行文档的编写，其中还对各种流程图、类图、用例图等的绘制，整个过程设计了知识的方方面面。从中让我认识到UML的作用和运作模式以及方法，它是一种统一建模的标准语言，现在对于大多数软件开发来说，都使用Uml作为建模语言，形成了统一的标准。它是图形化的的语言，可以很直观的描述一个事物的状态、行为与特征，很好的说明与表达了“合贝利任务管理”这个系统。

总之，在我看来，UML是一种定义良好、易于表达、功能强大且普遍适用建模语言。融入软件工程领域的心思想、新方法和新技术，作用域不限于支持面向对象的分析和设计，也不单纯是一种方法，仅仅是一组符号而已，它可以对任何具有静态机构和动态行为的系统进行建模，所以我很喜欢适用UML，在今后的学习中，我还会进一步对该模型的学习，因为它方便、简洁、干净、清爽，直观形象，把整个软件系统的开发流程都融入进去。

这次实训过程中，文档方面的编写，遇到了很多的问题，这些问题主要是对基础知识的理解和把握不够，不能融会贯通和学以致用，有时遇到困难的时候真的不知如何着手解决，但是，我始终相信的那句话“读万卷书，不如行万里路，行万里路不如名师指路”。所以，当遇到自己模糊和自己难以解决的问题时，向指导老师和懂的同学请教，帮助解决我遇到的问题，经过他们的讲解后，我下来自己在分析，在动手，从不理解到理解，从不会到会，从懂到懂，这是一个让我学习愉快的过程，在这个过程中，既可以丰富了自己的知识，还可以和老师和同学进行有效地方沟通。

在这次实训过程中，感触最深的也就是合作精神了。独木难成林，单枪匹马，那是最错误的思想和做法。这次我是深有感触了。对于一个系统的分析，到最终项目的完成，需要分析每个文档，然后在写出纸质的文档，而在每个文档中，内容比较多，分析也要求比较到位，所以单独凭借一个人去完成，似乎有点困难，于是我们小组，将每个文档进行分析，能独立成块就分配给每一个人，这样，每个人都有自己的任务，谁也不会闲着，既学到了知识，也充实了自己。另外一点，就是我深深体会到了积累知识的重要性。在实训当中我们遇到了不少难题，但是经过我们大家的讨论和老师细心的一一指导，问题得到了解决。两个月的实训结束了，收获颇丰，同时也更深刻的认识到要做一个合格的程序员并非我以前想像的那么容易，最重要的还是细致严谨。社会是不会要一个一无是处的人的，所以我们要更多更快地从一个学生向工作者转变，总的来说我对这次实习还是比较满意的，它使我学到了很多东西，为我以后的学习做了引导，点明了方向。

实训的日子即将结束，回想这一个过程，有过痛苦，有过烦恼，有过喜悦和有过成功。痛苦烦恼的是自己对所学书本知识掌握得不是很扎实，面对着从书本上学到的知识与实际联系不起来，总结起来就是自己的动手练习的时间太少。而喜悦的是，在做的过程中遇到了困难和问题，主动向老师和会的同学请教，然后再做，直至做正确做成功后的那种喜悦。

UML实验报告[推荐] 篇3

班 级：软件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心得体会 篇4

其实在上UML课之前，我以为UML跟C++和java一样是一门编程语言，直到经过老师的介绍，我才知道UML的全称是Unified Modeling  Language，他不同于C++,java这些编程语言，他是统一建模语言。UML是一种用于可视化描述系统，具有广泛用途的建模语言。作为一种标准化的图形语言，在软件工业中被用于软件系统部件的具体化，可视化，结构化描述以及撰写文档，同样在商业模型中也得到应用。

UML虽然不是一门程序设计语言，但他的重要性是不可忽视的。他的重要性主要体现在：使复杂的软件设计更为简单，也能够实现像OOP(面向对象编程)这一类被广泛应用的概念;用理解起来可能更容易的图来描述，避免了大量的文字;使表达和交流概念或系统结构变得更容易;在一张图中就能够描绘出整个系统;程序员实用类图来描述实际需求时，可让问题更加清晰明了，实现起来更容易。

很多人或许会说直接写代码要比画图分析什么的快多了，但我认为UML在分析和设计阶段十分重要。在学完职责分配原则和了解过一些设计模式过后，我更加坚定了我的想法。或许对于一个小项目来说，实现的方式有很多种，无论是哪一种，可能会有人觉得只要能够实现功能就是可用的，就是好的。但如果是一个比较庞大的项目呢?如果在具体写代码时某个类的职责过于庞杂，那么必定会给系统带来很大的压力。或者说每个类之间的关系特别复杂，那么当后续需要更改某个类的时候，必定会影响到其他的类，带来十分高昂的维护成本。而GRASP的九个原则：信息专家原则，创造者原则，低耦合原则，高内聚原则，控制器原则，多态原则，纯虚构，中介原则，受保护变量原则可以在一点程度上很有效地解决这些问题。

UML这门课程让我学会了话UML的五大类，共九种图:

用例图：从用户角度描述系统功能，并指出各功能的操作者。

静态图：包括类图和对象图。类图描述系统中类的静态结构，不仅定义系统中的类，表示类之间的联系，如关联、依赖、聚合等，也包括类的属性和操作，类图描述的是一种静态关系，在系统的整个生命周期都是有效的。对象图是类图的实例，几乎使用与类图完全相同的标识。一个对象图是类图的一个实例。由于对象存在生命周期，因此对象图只能在系统某一时间段存在。

行为图：描述系统的动态模型和组成对象间的交互关系，包括状态图和活动图。状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件，状态图是对类图的补充，活动图描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并进行活动。

交互图：描述对象间的交互关系，包括时序图和协作图。时序图显示对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时显示对象之间的交互;协作图描述对象间的协作关系，协作图跟时序图相似，显示对象间的动态合作关系。除显示信息交换外，协作图还显示对象以及它们之间的关系。如果强调时间和顺序，则使用时序图;如果强调上下级关系，则选择协作图。

实现图：包括组件图和部署图。组件图描述代码部件的物理结构及各部件之间的依赖关系，组件图有助于分析和理解部件之间的相互影响程度;部署图定义系统中软硬件的物理体系结构。

UML也同时让我自己去了解了统一过程，这部分老师并没有详细地讲，我自己查阅资料了解了一些。RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：初始阶段、细化阶段、构造阶段和交付阶段。每个阶段结束于一个主要的里程碑。每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。

UML实验指导书 篇5

前言

UML技术是一门实践性很强的课程，必须十分重视加强实验教学。UML技术实验课的目的是进一步巩固和加强理论知识，培养基本应用和建模工具操作技能，提高解决实际问题的能力。

为了达到上述目的，根据我系UML技术的教学大纲及实际情况编写了该实验指导书。全书共分7个实验，每个实验包括有：实验目的、实验器材、实验内容和步骤、实验报告要求

等项目。

１

UML实验指导书

目录

实验一 用例图...............................................................................................................................３ 实验二 交互图...............................................................................................................................４ 实验三 类图...................................................................................................................................５ 实验四 数据建模...........................................................................................................................６ 实验五 活动图...............................................................................................................................７ 实验六 状态图...............................................................................................................................８ 实验七 组件图和部署图...............................................................................................................９

２

UML实验指导书

实验一 用例图

一、实验目的

1． 熟悉用例图的基本功能和使用方法。2． 掌握如何使用建模工具绘制用例图方法。

二、实验器材

1.计算机一台；

2.Rational Rose 工具软件；

三、实验内容

根据以下需求设计一个图书馆管理系统的用例图。基本功能要求：

图书管理：新书登记，图书查询，图书注销； 借阅管理：借书，还书，查询今日到期读者；

读者管理：增加读者、删除读者、查询读者、读者类别管理（可以设置不同类的读者，并使不同类读者对应不同类的图书流通参数，如可借册数，可借天数，可续借次数，可续借天数等）；

报表管理：包括图书借阅统计报表，被注销图书统计报表等；报表可以有多种格式可供选择；可以把报表输出到文件中，可以预览报表、打印报表等。

系统管理：系统管理员使用，包括用户权限管理（增加用户，删除用户，密码修改等），数据管理（提供数据修改、备份、恢复等多种数据维护工具），系统运行日志，系统设置等功能。

四、实验步骤

详细分析系统需求，使用Rose工具完成系统用例图。（1）分析系统活动者（2）分析系统活动者的用例

（3）分析活动者之间、用例之间的关系（5）绘制用例图

五、实验报告要求

1． 整理实验结果。2． 小结实验心得体会。

３

UML实验指导书

实验二 交互图

一、实验目的

1．理解顺序图的基本概念； 2.理解协作图的基本概念；

3.掌握在Rational Rose中绘制交互图的操作方法。

二、实验器材

1.计算机一台；

2.Rational Rose 工具软件；

三、实验内容

根据图书馆管理系统的需求分析和用例图，完成系统的交互图，对用例进行动态建模。

四、实验步骤

1.分析：根据图书馆管理系统的需求分析和用例图，对系统中的用例进行动态建模。2.请根据教材中示例部分在Rational Rose中绘制上述的交互图。

五、实验报告要求

1． 整理实验结果。2． 小结实验心得体会。

４

UML实验指导书

实验三 类图

一、实验目的

1．理解类的基本概念；

2.掌握如何从需求分析中抽象出类的方法； 3.掌握在Rational Rose中绘制类的操作方法。

二、实验器材

1.计算机一台；

2.Rational Rose 工具软件；

三、实验内容

根据图书馆管理系统需求分析、用例图、交互图，对系统进行静态建模，寻找和发现类，分析类之间的关系。

四、实验步骤

1．打开前面初步构建的UML模型文件;2．打开Rose中的逻辑视图（Logical View），选择分析模型（analysis model）目录。并在其下创建一个子目录并命名为：“图书馆业务功能”。

3．用鼠标右击“图书馆业务功能”在弹出来的菜单中选择“New→Class diagram”项，创建类图。

4．双击新建的类图，并点右边控件集中选中的类并用鼠标在图中分别拖出上述类图。5．设定上述抽象出来各类的属性和操作。6．分析、设定以上各类之间的关系。

7．请根据教材中示例部分在Rational Rose中绘制类间的关系。

五、实验报告要求

1． 整理实验结果。2． 小结实验心得体会。

５

UML实验指导书

实验四 数据建模

一、实验目的

1．数据建模的基本概念

2．掌握在Rational Rose中进行数据建模。

二、实验器材

1.计算机一台；

2.Rational Rose 工具软件；

三、实验内容

根据图书馆管理系统需求分析、类图系统进行数据建模。

四、实验步骤

1.创建 Database，Database建模元素在component view中创建。2.创建 Schema，在logical view中创建schema，并选定目标数据库。

3.创建 Domain Package和Domain，在logical view中创建，先创建Domain Package，再创建Domain。

4.创建 Data Model Diagram，在schema下创建。5.创建 Table，在Data Model Diagram中建表。6.创建 Column，在表上建立列。

7.创建 Relationship，在表与表之间建立关系,，有两种关系，即non-identifying(非确定性)关系和 identifying(确定性)关系

8.Normalizing the Data Model，创建了数据模型后，还要将模型规范化，如转换为3NF。

9.Optimizing the Data Model，如创建索引，视图，存储过程，denormalization，使用domain等。

10.Implementing the Data Model，利用Rose产生DDL或直接在数据库中建立表。

五、实验报告要求

1． 整理实验结果。2． 小结实验心得体会。

６

UML实验指导书

实验五 活动图

一、实验目的

1． 熟悉活动图的基本功能和使用方法。2． 掌握如何使用建模工具绘制活动图方法。

二、实验器材

1.计算机一台；

2.Rational Rose 工具软件；

三、实验内容

根据图书馆管理需求分析、用例图、类图等，应针对每个用例进行业务分析，说明其具体的业务流程，完成系统活动图活动图。

四、实验步骤

以“删除读者信息”用例为例，说明绘制活动图的步骤。1．管理员在录入界面，输入待删除的读者名；

2．“业务逻辑”组件在数据库中，查找待删除的读者名；

3．如果不存在，则显示出错信息，返回步骤（1），如果存在则继续； 4．“业务逻辑”组件判断“待删除的读者”是否可以删除；

5．如果不可以，则显示出错信息，返回步骤（8），如果可以则继续； 6．在数据库中，删除相关信息； 7．显示删除成功信息； 8．结束。

五、实验报告要求

1． 整理实验结果。2． 小结实验心得体会。

７

UML实验指导书

实验六 状态图

一、实验目的

1．理解什么状态和状态图； 2.学会使用UML绘制状态图；

二、实验器材

1.计算机一台；

2.Rational Rose 工具软件；

三、实验内容

根据图书馆管理系统的需求分析、用例图和相应的活动图，从对象的动态行为的角度去描述系统的业务活动，完成系统的状态图。

四、实验步骤

1.业务分析：由前面章节对图书馆管理系统中的还书业务的描述和分析可知，还书业务的动态行为是由：空闲（idle）、图书查找（finding）、还书（reversion）、失败（Failure）、归还成功（Success）5种状态及激活相互转换的事件。

2.绘制状态图：请您根据分析运用UML绘制还书用例的状态图。

五、实验报告要求

1．整理实验结果。

2．小结实验心得体会。

８

UML实验指导书

实验七 组件图和部署图

一、实验目的

1.理解组件图的基本概念 2.理解组件图的应用：逻辑部署 3.理解部署图的基本概念 4.理解部署图的应用：物理部署 5.掌握组件图和部署图绘制的方法

二、实验器材

1.计算机一台；

2.Rational Rose 工具软件；

三、实验内容

1． 根据图书馆管理系统的分析和设计，已完成类图和交互图的分析与设计，完成系统的组件图和部署图。

四、实验步骤

1.绘制组件图 分析：

在图书馆管理系统中，通过分析可以发现类图中的类应分为4个部分：

1．用户接口模块（UI），主要负责系统和用户的交互，包括Frame类，Dialog类等。2．业务对象模块（BO），主要负责处理系统中的业务计算，如借书，还书等功能的具体操作。

3．数据存储模块（DB），主要负责处理对数据的存储。4．通用工具模块（UTIL），包括系统中通用函数。

通过一个主程序StartClass来启动。由于系统中的类较多，这里以业务对象模块（BO）为例来讲解如何创建组件图，BO模块中包括

Item类：书目类，表示一本实际存在的书籍或杂志

Loan类：借书业务类，将借阅者和图书馆关联起来，一个Loan对象表示借出的一本书 BorrowerInfomation类：借阅者信息类，表示一个借阅者。

Title类：表示一种书或一种杂志。如《C++编程思想》就是一种书，用1个title表示，如果有2本这样的书，则需要用2个Item表示。

Reservation类：预定信息类，表示一个预定信息。

Item类和Loan类之间互相依赖，Loan类和BorrowerInfomation类之间互相依赖，９

UML实验指导书

BorrowerInfomation类和Reservation类之间互相依赖，Reservation类和Title之间互相依赖，Title和Item类之间互相依赖。绘图步骤：

（1）在组件视图中双击Main图，出现图7.1，为编辑组件图做好准备，这时绘图工具栏中的图标如图中椭圆所示，其中具体含义可参看本节“补充图标”一段的介绍。

图7.1（2）在组件视图中，从工具栏中选择MainProgram图标，在右边的绘图区中添加一个新组件，并取名StartClass.java表明新增一个主程序。

图7.2（3）选择新创建的组件，点击鼠标右键，在弹出的菜单中选择“Open Sepcification”,弹出图7.3对话框。

１０

UML实验指导书

（4）在对话框中，可以修改组件的名称，设置组件的类型，指定实现的语言。这里新组件的名称定为“StartClass.java”，组件构型为Main Program（Rose中提供了多种构型，大部分在补充图标一段中均有简单的介绍），实现语言为JAVA（Rose中默认的是分析语言Analysis），修改结果如图7.4所示。

图7.3

图7.4（5）组件图描述的是系统的实现视图，因此要指定实现组件功能的文件。点击File

１１

UML实验指导书

选项卡，在列表框中点击鼠标右键，在弹出的菜单中选择“Insert File”，弹出文件对话框。在对话框中，键入StartClass.java，点击“打开”按键，这时对话框如图7.5所示。

图7.5（6）双击StartClass.java，弹出是否创建对话框，询问是否创建文件，选择“YES”,弹出记事本，这时可输入相应的源程序（注意：如果这里选择的文件已经存在，则不会弹出创建文件对话框，而是直接显示相应文件内容）。

（7）创建相应的包。选择包图标，在右图中创建。这里同样需要对每个组件打开“Open Specification”对话框，设置具体的属性，对“包”组件来说需要在Files选项卡中指明与其对应的目录。创建完毕的组件图如图7.6所示。

图7.6（8）选择业务对象包（BO），双击，打开业务对象包的详细组件图，这里根据分析的结

１２

UML实验指导书

果分别创建Title.java,Item.java，Loan.java，BorrowerInfomation.java，Reservation.java组件，并设置好每个组件的构型和对应的文件。创建好的BO包组件图如图7.7。

图7.7（9）创建依赖关系。在本节“关系”一段中，已经描述过依赖关系使用虚线表示，因此根据分析中的结果，在图中将相互依赖的组件连接即可。完成后的组件图如图7.8。

图7.8 2.绘制部署图 分析：

HNS的图书管理系统目前开发的是一个单机版系统，其中所有的运算均在一台机器上完

１３

UML实验指导书

成，但是由于打印报表的需要，系统还应配备一台打印机。因此得出系统中存在2个节点：

① 一台主机，其类型是Processor。② 一台打印机，其类型是Device。绘图步骤：

（1）浏览窗口中选择“Deployment View”,弹出如图7.9所示窗口：

图7.9（2）在图中添加分别添加一个Processer和Device，并分别命名为“computer with java support”和“Printer”，添加完毕后，其结果如图7.10所示：

１４

UML实验指导书

图7.10（3）为节点添加连接关系。全图如图7.11。

图7.11

五、实验报告要求

1． 整理实验结果。2． 小结实验心得体会。

UML九种视图总结 篇6

UML类图中的关系分为四种：泛化关系、依赖关系、关联关系、实现关系；关联关系又可以细化为聚合和组合。

1.1 泛化（Generalization)泛化是父类和子类之间的关系，子类继承父类的所有结构和行为。在子类中可以增加新的结构和行为，也可以覆写父类的行为。

1.2.依赖（Dependencies）

依赖关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的事物，反之不成立。在你想显示一个事物使用另一个事物时使用，两个元素之间的一种关系，其中一个元素（服务者）的变化将影响另一个元素（客户），或向它（客户）提供所需信息。它是一种组成不同模型关系的简便方法。依赖表示两个或多个模型元素之间语义上的关系。它只将模型元素本身连接起来而不需要用一组实例来表达它的意思。它表示了这样一种情形，提供者的某些变化会要求或指示依赖关系中客户的变化。

根据这个定义，关联和泛化都是依赖关系，但是它们有更特别的语义，故它们有自己的名字和详细的语义。我们通常用依赖这个词来指其他的关系。依赖用一个从客户指向提供者的虚箭头表示，用一个构造型的关键字来区分它的种类，通常情况下，依赖关系体现在某个类的方法使用另一个类作为参数。

1.3.关联（Association）

关联是一种结构化的关系，指一种对象和另一种对象有联系。给定有关联的两个类，可以从一个类的对象得到另一个类的对象。

类与类之间由弱到强关系是: 没关系 > 依赖 > 关联 > 聚合 > 组合。

类和类之间八竿子打不着那就是没关系，这个没啥歧义。依赖(dependency)

可以简单的理解，就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、、临时性的、非常弱的，但是B类的变化会影响到A；比如某人要过河，需要借用一条船，此时人与船之间的关系就是依赖；表现在代码层面，为类B作为参数被类A在某个method方法中使用。用带虚线的箭头。

关联(association)

他体现的是两个类、或者类与接口之间语义级别的一种强依赖关系，比如我和我的朋友；这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的，一般是长期性的，而且双方的关系一般是平等的、关联可以是单向、双向的；表现在代码层面，为被关联类B以类属性的形式出现在关联类A中，也可能是关联类A引用了一个类型为被关联类B的全局变量；

依赖和关联区别：我用锤子修了一下桌子，我和锤子之间就是一种依赖，我和我的同事就是一种关联。依赖是一种弱关联，只要一个类 用到另一个类，但是和另一个类的关系不是太明显的时候（可以说是“uses”了那个类），就可以把这种关系看成是依赖，依赖也可说是一种偶然的关系，而不是必然的关系。关联是类之间的一种关系，例如老师教学生，老公和老婆这种关系是非常明显的。依赖是比较陌生，关联是我们已经认识熟悉了。

1.3.1 聚合（Aggregation）

聚合是一种特殊的关联。它描述了“has a”关系，表示整体对象拥有部分对象。

关联关系和聚合关系来语法上是没办法区分的，从语义 上才能更好的区分两者的区别。聚合是较强的关联关系，强调的是整体与部分 之间的关系。

与关联关系一样，聚合关系也是通过类的成员变量 来实现的。

1.3.2 组合（Composition）

组合是聚合的一种形式，它具有更强的拥有关系，强调整体与部分的生命周期 是一致的。整体负责部分的生命周期的管理。如果整体被销毁，部分也必须跟着一起被销毁，如果所有者被复制，部分也必须一起被复制。

与关联关系一样，组合关系也是通过类的成员变量 来实现的。

1.4.实现（Realization）

实现关系指定两个实体之间的一个合约。换言之，一个实体定义一个 合约，而另一个实体保证履行该 合约。

1.5 扩展关系(extends)1.6 包含(include)

1.7 精化关系（refine）UML视图

说明：

构件事物是名词，是模型的静态部分。行为事物是动态部分，表示行为。分组事物是组织部分。注释事物是解释部分。

依赖：一个事物变化会引起另一个事物变化。聚集：特殊的关联，描述整体与部分的组合关系。

泛化：是一种特殊与一般的关系，如子元素（特殊）与父元素（一般），箭头指向父元素。实现：类元之间的关系，其中一个类元指定了由另一个类元保证执行的契约。一般用在接口和实现他们的类之间或用例和实现它们的协作之间。

2.1 类图

用于展现系统中的类以及其之间的关系

对象图：显示了单独的对象及其关系。对象图有助于记录测试用例以及讨论用例。

•静态图：包括类图和对象图。

类图描述系统中类的静态结构，不仅定义系统中的类，表示类之间的联系，如关联、依赖、聚合等，也包括类的属性和操作，类图描述的是一种静态关系，在系统的整个生命周期都是有效的。

对象图是类图的实例，几乎使用与类图完全相同的标识。一个对象图是类图的一个实例。由 于对象存在生命周期，因此对象图只能在系统某一时间段存在。2.1.1 包

包可直接理解为命名空间，文件夹，是用来组织图形的封装，包图可以用来表述功能组命名空间的组织层次。

•在面向对象软件开发的视角中，类显然是构建整个系统的基本构造块。但是对于庞大的应用系统而言，其包含的类将是成百上千，再加上其间“阡陌交纵”的关联关系、多重性等，必然是大大超出了人们可以处理的复杂度。这也就是引入了“包”这种分组事物构造块。•包的作用是：

1）对语义上相关的元素进行分组； 2）定义模型中的“语义边界”； 3）提供配置管理单元；

4）在设计时，提供并行工作的单元；

5）提供封装的命名空间，其中所有名称必须惟一

上图解释

•首先根据《use》关系，可以发现Client包使用Server包，Server包使用System.Data.SqlClient包，结合其元素，不难得知Client负责Order（订单）的输入，并通过Server来管理用户的登录（LoggingService）和数据库存储（DataBase），而Server包还将通过.NET的SQL Server访问工具包来实现与数据库的实际交互。•接着再看两个《import》，从包的命名和其所属的元素不难发现Rule负责处理一些规则，并引用一个具体的窗体（Window），而Client包则通过引用Rule来实现整个窗体和表单的显示、输入等。并且还将暂存Order（订单）信息。•最后来看包的泛化关系，GUI有两个具体实现，一个是针对C/S的WindowsGUI，一个是实现B/S的WebGUI。依赖关系

•《use》使用关系：是一种默认的依赖关系，说明客户包（发出者）中的元素以某种方式使用提供者包（箭头指向的包）的公共元素，也就是说客户包依赖于提供者包

•《import》引用关系：最普遍的包依赖类型，说明提供者包(箭头指向的包)的命名空间（包本身代表命名空间）将被添加到客户包（发出者）的命名空间中，客户包中的元素也能够访问提供者包的所有公共元素

•《access》访问关系：只想使用提供者包中的元素，而不想将其命名空间合并则应使用该关系

•《trace》追溯关系：想表示一个包到另一个包的历史发展，则需要使用《trace》关系来表示

例子描述

•分析系统工作流程：

1）通过Internet连接到股票信息服务器，获取实时的股票信息，并存入数据库中。2）根据用户的输入和选择，从数据库中获取相应的信息，展现在屏幕中。3）在数据的展现过程中，将需要绘制大量的图表 •根据功能模块组织包：

包之间的依赖关系

2.2 状态图

展示了一个状态机，由状态、转换、事件和活动组成。强调事件行为的顺序。如下图(摘自网络)：

2.2.1 事件

事件是指某个时刻发生的事情。

信号是指从一个对象到另一个对象的明确的单向信号流动。

信号事件：是指发送或者接受信号的事件。

区别：信号是对象间的消息，而信号事件是指某个时刻发生的事情。

变更事件：是指满足布尔表达式而引起的事件。

时间事件：是指在绝对时间上或者在某个时间间隔内发生的事情而引起的事件。

2.2.2 状态

是对象取值和链接的抽象。根据对象的总体行为，将取值和链接的集合组成一个状态。

事件表示时间点，状态表示时间段。

2.2.3 迁移

是指从一种状态到另一种状态的瞬时变化。

2.2.4 电话状态图

2.2.5 活动 2.2.6 增加了活动的电话状态图 2.2.7 嵌套状态图

嵌套状态

2.3 用例图

描述一组用例、参与者以及它们之间的关系，其展示的是该系统在它 的外面环境中所提供的外部可见服务

2.3.1 用例中的包含

包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的 关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。2.3.2 扩展

将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。

2.3.3 泛化

泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。2.3.4 实例

2.4 交互图

场景是指系统在某个特定的执行期内发生的一系列事件。

包括序列图（顺序图）和协作图，两者对应，顺序图是强调消息时间顺序，有对象生命线和控制焦点。

协作图是强调接收和发送消息的对象的结构组织，有路径和顺序号

交互图强调的是对象到对象的控制流，而活动图则强调的是从活动到活动的控制流

•活动图是一种表述过程基理、业务过程以及工作流的技术。它可以用来对业务过程、工作流建模，也可以对用例实现甚至是程序实现来建模

2.4.1 顺序图

显示了交互的参与者以及参与者之间的消息顺序。也显示了系统为了执行全部或部分用例而与参与者的交互。

2.4.2 活动图

显示了组成复杂过程的步骤序列。

活动图的主要元素

•初始节点和活动终点：用一个实心圆表示初始节点，用一个圆圈内加一个实心圆来表示活动终点

•活动节点：是活动图中最主要的元素之一，它用来表示一个活动

•转换：当一个活动结束时，控制流就会马上传递给下一个活动节点，在活动图中称之为“转换”，用一条带箭头的直线来表示 活动图的主要元素

•分支与监护条件：分支是用菱形表示的，它有一个进入转换（箭头从外指向分支符号），一个或多个离开转换（箭头从分支符号指向外）。而每个离开转换上都会有一个监护条件，用来表示满足什么条件的时候执行该转换。

•分岔与汇合：

修改后的简单活动图

带泳道的活动图

带对象流的活动图 复杂活动图 •辅助活动图：

•汇合描述：当汇合的所有入流均到点汇合点时，就将执行汇合点指向的活动节点。但是有些时候，你希望对其做一些约束，这时就可以借助汇合描述来完成。汇合描述实际上是一个约束，其格式就是“{约束条件}”。•发送信号与接收信号：

•如何绘制活动图 绘制活动图

•“活动图” 比较直观易懂；与传统的流程图十分的相近，只要能够读懂活动图，就不难画出活动图

•绘制时首先决定是否采用泳道：主要根据活动图中是否要体现出活动的不同实施者 •然后尽量使用分支、分岔和汇合等基本的建模元素来描述活动控制流程

•如果需要，加入对象流以及对象的状态变化，利用一些高级的建模元素（如辅助活动图、汇合描述、发送信号与接收信号、引脚、扩展区）来表示更多的信息

•活动图的建模关键是表示出控制流，其它的建模元素都是围绕这一宗旨所进行的补充 工作流程，控制流程，业务流程中使用。

• •活动图应用说明

活动图应用说明

•对工作流建模：用于业务建模的时候，每一条泳道表示一个职责单位，该图能够有效地体现出所有职责单位之间的工作职责，业务范围及之间的交互关系、信息流程 建模时应遵循以下策略： •为工作流建立一个焦点，除非你所涉及的系统很小，否则不可能在一张图中显示出系统中所有的控制流

•选择对全部工作流中的一部分有高层职责的业务对象，并为每个重要的业务对象创建一条泳道

•识别工作流初始节点的前置条件和活动终点的后置条件，这可有效地实现对工作流的边界进行建模。

•从该工作流的初始节点开始，说明随时间发生的动作和活动，并在活动图中把它们表示成活动节点

•将复杂的活动或多次出现的活动集合归到一个活动节点，并通过辅助活动图或子活动图来表示它们

•找出连接这些活动节点的转换，首先从工作流的顺序开始，然后考虑分支，接着再考虑分岔和汇合

•如果工作流中涉及重要的对象，则也可以将它们加入到活动图中 •若工作流中有多次启用的，则可采用展开区表示

•对操作建模：每一个对象占据一个泳道，而活动则是该对象的成员方法 •建模时应遵循以下策略：

--收集操作所涉及的抽象概念，包括操作的参数、返回类型、所属类的属性以及某些邻近的类

--识别该操作的初始节点的前置条件和活动终点的后置条件。也要识别在操作执行过程中必须保持的信息

--从该操作的初始节点开始，说明随着时间发生的活动，并在活动图中将它们表示为活动节点

--如果需要，使用分支来说明条件语句及循环语句

--仅当这个操作属于一个主动类时，才在必要时用分岔和汇合来说明并行的控制流程 构件图

2.5 构件图

类是最基础的“模块化”元素，它封装了属性和成员的方法，就像是物理世界中的“分子”。但是，对于复杂的软件系统而言，往往拥有成百上千的各种类。因此，类的粒度太小了，引入更粗的粒度的概念—“构件”

构件是系统中可替换的物理部分，它包装了实现而且遵从并提供一组接口的实现。通俗的说，构件是系统设计的一个模块化元素，它隐藏了内部的实现，对外提供一组外部接口。在系统中，满足相同接口的组件可以自由地替换。

1、构件的表示方法

和类的名称相近，构件的名称也是一个正文字符串，它可以是简单名，也可以是带路径的全名。

2、构件图实例：

2.6 部署图

1、部署图描述了一个系统运行时的硬件节点，在这些节点上运行的软件构件将在何处物理运行以及它们将如何彼此通信的静态视图。

部署图包括两种基本模型元素：节点和节点间的连接。每个模型中，仅包含一个部署图。节点包括两种类型：处理器和设备。

处理器指本身具有计算能力且能执行各各软件的节点，如服务器。

处理器具有处理能力，所以在描述处理器方面应当包含了处理器的调度和进程。

调度指在处理器处理其进程中为实现一定的目的而对共同使用的资源进行时间分配。调度方式包含：抢占，无优先级，循环，算法控制，手动执行。进程表示一个单独的控制纯种，是系统中一个重量级的并发和执行单元。

设备指本身不具备处理能力的节点，如打印机。

连接用来表示两个节点之间的硬件连接。节点之间的连接可以通过光缆直接进行，或通过卫星等方式非直接连接，通常连接都是双向的。连接用实线表示，实线上可加连接名和构造型。

系统开发人员和部署人员可以利用部署图去了解系统的物理运行情况。如果，开发的软件系统只需在一台计算机上运行，且使用的标准设备，则不需要为它画出系统部署图。部署图只需要给那些复杂的物理运行情况进行建模。

部署图显示了系统的硬件，安装在硬件上的软件，用于连接硬件的各种协议和中间件等。

2、部署模型的目的：

描述一个具体应用的主要部署结构，通过对各种硬件，在硬件中的软件以及各种连接协议的显示，可以很好的描述系统是如何部署的；平衡系统运行时的计算资源分布；可以通过连接描述组织的硬件网络结构或者是嵌入式系统等具有多种硬件和软件相关的系统运行模型。