uml报告总结（精选9篇）

uml报告总结 第1篇

UML课程设计总结

这几周的课程设计，是对课本知识的总结和巩固，使我对UML的几种图有了更深刻的理解，明白了这些图分别表达的意思以及各图的优缺点，还有它们对于程序设计的作用。熟悉了VS中建模，熟悉了VS中控件的意义，对UML有了更深刻的了解。下面是我在每一个图的学习中的一些心得和体会

在项目设计阶段，我觉得顺序图，活动图，状态图比较重要。顺序图在这些图例里比较直观，用户能很快参与到讨论中，活动图和传统的流程图类似，也是一个补充。状态图在对关键对象是一定要做状态分析的，经常会在做分析的时候发现一些容易被忽视的问题。类图在设计阶段可以用。

深刻体会了UML在建模中关系和作用。UML可以为面向对象的开发系统进行说明，是的复杂的系统和功能，逻辑关系，类之间的关系可视化。用例图帮助我们从宏观上认识了学生选导师系统的软件结构。状态图，时序图，类图帮助我们从微观上认识了这个系统的结构和关系。

画用例图是我第一次使用VS建模，对VS中的一些工具还很生硬，仅仅知道跟着指导书来进行建模。但经过一定的练习，也有了一定的收获和体会，使我了解了用例图的组成，作用以及使用场合；掌握了用例之间的各种关系；知道了用例建模主要要了解各个图形所代表的意义，用例还可以进行下一集的描述，进行下一步的深化。

对于建模过程中遇到的问题通过上网查资料，问同学并和他们进行讨论，得到了比较满意的解决，避免了自己眼高手低，从实践中发现自己的不足，并及时改正。更让我明白，UML的知识是十分丰富的，我现在的认识还不够，我将会在以后的学习中，不断提高自己的UML知识，更好地让UML为将来的编程设计服务。

进一步加强和提高了文档的编写能力

增强了写作能力和团队精神

uml报告总结 第2篇

在我国十年前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”，表明这个对象在这时被销毁。

UML实验报告 第3篇

班级：

学号：

姓名：

实验一

业务建模

一、实验目的

二、实验内容

三、实验过程和结果分析

四、总结

UML实验报告四 第4篇

实验报告

实验四 交互图 专

业：

信息与计算科学

班

级：

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实验报告全 (500字) 第5篇

姓名：____钱秀梅_________ 学号：__ 10030117_____ 班级：_10计一_______ 指导教师：___殷凯__________ 计算机科学与技术系编写

系统分析与建模实验指导书 ―1― 计算机科学与技术系

目 录

实验0 熟悉软件开发环境? 实验1 用例图设计??? 实验2 类和对象图设计??? 实验3 交互图设计?? 实验4 状态图设计?? 实验5 活动图设计 实验6 包图设计?? 实验7 物理图设计? 附录 考核登记表??1 3 7 9 12 15 17 23实验0 熟悉软件开发环境

一、实验目的

学习使用ea开发环境创建模型的一般方法，理解ea界面布局和元素操作的一般技巧。

二、实验环境

软件平台：microsoft windows2000 /xp。软件工具：ea 7.5。

三、实验内容与要求

1． 学会启动和关闭ea 7.5开发环境。

2． 使用目标项目（project）的向导创建一个项目。3． 了解ea 7.5界面的六大组成部分（菜单menu、浏览器browser、文档窗口document window、图窗口diagram window、日值窗口log window和工具栏。

4． 在浏览器中实现如下操作：增加模型元素（包括角色、用例、类、组建、图等）；查看现有模型元素；查看现有模型元素之间的关系；移动模型元素；更名模型元素；访问元素的详细规范。

5． 分别在在图中增加删除图元素和在浏览器中增加删除图元素。

四、实验预习和准备

参考相关书籍，能够熟练地安装和使用ea 7.5软件建立模型。

五、实验过程与结果

读者

图0-1 用例图

图0-2 一个订单系统的包图

六、实验小结和体会

1、在创建用例图和包图过程中，使用目标项目（project）的向导创建一个项目，选择需要的模型，然后在所选的模型下面创建图。

2、通过创建用例图，知道了用例图的三个基本组成部分：系统、活动者、用例，用例图是从用户的角度而不是开发者的角度来描述对软件产品的需求，分析产品所需的功能和动态行为。用例是对一个活动者使用系统的一项功能时所进行的交互过程的一个文字描述系列。用例之间可以存在一定的联系，这些联系包括泛化联系、使用联系、包含联系、扩展联系等。

3、通过创建包图，知道了包图由包和包之间的联系构成。包图的图形节点是包，节点之间用弧（依赖或泛化）连接。包图是和控制系统总体结构的重要建模工具。

实验一 用例图设计

一、实验目的

掌握在ea中用例图的基本用法和使用技巧。

二、实验环境

软件平台：microsoft windows2000 /xp。软件工具：ea7.5。

三、实验内容与要求

本实验给予某学校的网上选课系统的用例图的设计和实现。

需求描述如下：某学校的网上选课系统主要包括如下功能：管理员通过系统管理界面进入，建立本学期要开设的各种课程、讲课程信息保存在数据库中丙可以对课程进行改动和删除。学生通过客户机浏览器根据学号和密码进入选课界面，在这里学生可以进行三种操作：查询已选课程、选课以及付费。同样，通过业务层，这些操作结果存入数据库中。

分析：

本系统拟用三层模型实现：数据核心层、业务逻辑层和接入层。其中，数据核心层包括对于数据库的操作；业务逻辑层作为中间层对用户输入进行逻辑处理，再映射到相应的数据层操作；而接入层包括用户界面，包括系统登陆界面、管理界面、用户选择界面等。

本系统涉及的用户包括管理员和学生，他们是用例图中的活动者，他们的主要特征相似，都具有姓名和学号等信息，所以可以抽象处“基”活动者people,而管理员和学生从people统一派生。数据库管理系统是另外一个活动者。

系统事件：

添加课程事件：

（1）管理员选择进入管理界面，用例开始。

（2）系统提示输入管理员密码。

（3）管理员输入密码。

（4）系统验证密码。

（5）密码错误

(6)进入管理界面，系统显示目前所建立的全部课程信息。(7)管理员许恩泽添加课程。(8)系统提示输入新课程信息。(9)管理员输入信息。

(10)系统验证是否和已有课程冲突。(11)a2 有冲突。(12)用例结束。

其他事件： a1 密码错误

（1）系统提示再次输入。

（2）用户确认。

（3）三次错误，拒绝再次访问。

（4）否则进入添加课程事件第6步。a2 有冲突

（1）系统提示冲突，显示冲突课程信息。

（2）用户重新输入。

（3）继续验证直到无冲突。（4）进入添加课程事件第12步。

删除课程事件和修改课程事件与添加课程事件类似。请自行描述。选课事件：

（1）学生进入选课登陆界面，用例开始。（2）系统提示输入学号和密码。（3）学生输入学号和密码。

（4）系统验证。a1 验证失败（5）进入选课主界面。（6）学生点击选课。

（7）系统显示所有课程信息。（8）学生选择课程。

（9）系统验证课程是否可选。a2 不可选。（10）系统提示课程选择成功，提示学生交费。（11）用例结束。错误事件： a1: 验证失败。

（1）系统提示验证失败，提示重新输入。（2）三次失败，拒绝访问。

（3）成功，转选课事件第5步。a2: 课程不可选。

（1）系统提示课程不可选原因。（2）学生重新选课。（3）重新验证直到成功。（4）转选课事件第10步。

付费事件和查询事件不做描述。

根据以上分析，绘制系统所有用例图。

四、实验预习和准备

了解用例图描述系统基本方式。熟练掌握用例图绘制的基本方法，了解用例、活动者、角色等基本概念的表示。

五、实验过程与结果 数据库

六、实验小结和体会

1、用例图描述了一组用例、活动者及它们之间的关系，因此基本的用例图包括3个方面的内容：用例、活动者、用例之间的关系。

2、活动者是系统外部的一个实体（可以是任何的事物或人），它以某种方式参与了用例的执行过程。

3、用例除了与其活动者发生关联外，用例之间也存在着一定的联系。这些联系包括泛化联系、包含联系、扩展联系等。

4、在建立用例模型时，应该注意几个问题：（1）用例英简单明了，具有较强的可读性。

（2）应该用文本和其他uml图来描述用例是如何启动和停止的。（3）应该从活动者的角度并以主动语态编写用例。

（4）垂直地绘制继承和扩展联系，水平地绘制包含联系。（5）不要被《include》和《extend》所困扰。

5、总之，用例是以主要活动者的目标为中心的，其中每一条语句都应该描述其所想表达的子目标。实验二 类和对象图设计

一、实验目的

掌握ea中类图和对象图刻划系统的一般步骤和技巧，掌握类图和对象图中的各种基本概念的含义和表达方法。

二、实验环境

软件平台：microsoft windows2000 /xp。软件工具：ea7.5。

三、实验内容与要求

（1）根据实验一的问题描述，结合序列图中的描述，抽象出选课系统中的类（除

角色外），然后作出他们的类图。

（2）在选课系统中，涉及到的用户包括管理员和学生，其主要特征相似，所以可

以建立统一基类people，而管理员和学生则由people派生。创建它们三者之间的类图。

（3）假设在选课系统中设计了以下类：

（a）界面（b）控制对象（c）课程 设计了以下角色：（a）学生（b）管理员

（c）学生和管理员的父类people（d）数据库

这些类和角色之间的关系如下：

（a）角色学生和管理员从people派生

（b）学生、管理员在与系统交互时，都有一个界面与之对应。（c）一个界面可能和课程相关（0..n）

（d）控制对象负责课程的处理，处理结果在界面上显示。（e）控制对象完成对数据库的操作。（f）界面请求控制对象的服务。

根据以上描述，绘制类关系图。注意对象之间关联的类型。

四、验和准备

参照相关书籍和文档，理解类和对象图绘制的基本方法。注意派生类和关联类及关联类型的表达。

五、实验过程与结果

六、实验小结和体会

1、类在uml中用一个有三个分隔区的矩形来表示。顶端的分隔区为类的名称，中间的分隔区存放类的属性、属性的类型和值，第三个分隔区存放操作、操作的参数表和返回类型。

2、类中属性的可见性主要包括public(公共)、private(私用)和protected(保护)三种，它们分别用“+”、“—”和“#”来表示。

3、对象类图不仅定义系统中的类，表示类间的联系，如关联、依赖、聚合等；还包括类的内部结构，如类的属性和操作等。

4、在uml中对象类一般都不是孤立地在系统中存在的，它们之间往往存在着各种关联关系，如聚合和组合、泛化及依赖等。

5、建立对象类图做到以下几点：

（1）研究和分析问题域，确定系统的需求。

（2）发现、识别、确定系统中的类和对象，明确它们的含义和责任、确定属性和操作。（3）找出类之间存在的静态联系。

（4）对已经发现的类之间存在的联系进行调整和优化。（5）最后绘制对象类图。

实验三 交互图设计

一、实验目的

掌握交互图（序列图和协作图）绘制的基本方法和技巧，学会使用交互图描述用例实现的方法，掌握系统动态特性建模的技巧。

二、实验环境

软件平台：microsoft windows2000 /xp。软件工具：ea。

三、实验内容与要求

本实验以选择系统中的选课用例为例，来学习交互图的设计和实现。

为了时问题更简单一些，不考虑学生的登陆。假设学生已经成功登陆系统，选择的事件可以简化如下：

选课事件：

（1）入选课主界面。（2）生点击选课。

（3）系统显示所有课程信息。（4）学生选择课程。

（5）系统验证课程是否可选。a1 不可选。（6）系统提示课程选择成功，提示学生交费。（7）用例结束。错误事件： a1: 课程不可选。

（2）统提示课程不可选原因。（3）生重新选课。

（4）重新验证直到成功。（5）转选课事件第6步。

创建上述选课用例的交互图（序列图）。同时根据实验一的描述创建添加课程、修改课程和删除课程的序列图以及选择课程的协作图。

四、实验和准备

参照相关书籍和文档，熟悉交互图绘制和描述的方法。

五、实验过程与结果

5.执行选课

图3-2 选课系统的协作图

()

六、实验小结和体会

1、交互图描述了系统的交互，由对象、关联、消息等组成。交互图可分为序列图和协作图，都可以用于建立系统动态行为模型。

2、序列图由对象、生命线、消息组成，协作图由对象、关联、消息组成。

3、序列图和协作图用不同的方式表达了系统中对象的行为。序列图描述了消息的时间顺序，适合实时系统；协作图描述了对象间的联系，适合对象类的划分；但它们在语义上是等价的，可以彼此转换。

4、交互图中的交互描述系统的一个特定行为，类似于一个用例的说明。每个交互由一组对象之间的通信序列组成，参与交互的对象通过协作建立联系，共同刻画系统的某一个行为。

实验四 状态图设计

一、实验目的

掌握状态图绘制的基本方法，理解状态图中各个要素的含义及表达。

二、实验环境

软件平台：microsoft windows2000 /xp。软件工具：ea。

三、实验内容与要求

（1）考察课程类（对象）的状态变化过程。课程对象被创建，添加到数据库中。

管理员可以删除、修改课程信息，在某个学期，开设改课程，如果选修人数超过制定人数，就不再允许学生选这门课。学期结束，学期结束，课程的状态终止。

根据以上描述，绘制课程对象的状态图。

（2）电梯运动是日常生活中常见的现象，请根据电梯的运动状态绘制电梯对象的状态图。

四、实验和准备

参照相关书籍和文档，熟悉绘制状态图的基本方法。

五、实验过程与结果

六、实验小结和体会

1、一个状态图描述了一个状态机，用状态图说明系统的动态视图。它对于接口、类或协作的行为建模尤为重要，可用它描述用例实例生命周期。

2、状态图显示一个对象从生成到删除的生命周期。

3、在uml中，状态图通常由状态和迁移组成，除此之外，还可以包括像判定和同步这样的用于表示控制流向的图形元素。

实验五 活动图设计

一、实验目的

掌握使用活动图描述各种复杂事件的逻辑。

二、实验环境

软件平台：microsoft windows2000 /xp。软件工具：ea。

三、实验内容与要求

在用例图中，我们对添加课程的用例事件做了详细分析（见实验二）。由于管理员密码验证过程可以抽取出来，作为通用的流程，所以这里对添加课程事件稍作修改，将管理员输入课程信息作为起始的活动，内容如下：

（1）管理员输入信息。

（2）系统验证是否和已有课程冲突。a2 有冲突（3）系统添加新课程，提示课程添加成功。（4）系统重新进入管理主界面，显示所有课程。（5）用例结束。根据以上分析，创建添加课程完整的活动图。绘制活动图时注意各元素的表示方式。

四、实验预习和准备

了解活动图描述工作流的基本方式，包括动作、状态、序列以及泳道。熟练掌握活动图绘制的基本方法。

五、实验过程与结果

六、实验小结和体会

1、活动图通常由动作状态和活动状态、动作流、泳道、对象流组成。另外，初始状态、终止状态、判定（分支）、分岔、接合等也是常见的图形元素和符号。

2、活动图是一种特殊的形式的状态机，其中大多数状态都是活动，并且大多数迁移都是由源活动中的动作执行完毕时隐式触发的。活动图主要用于工作流建模和算法流程建模。

3、在活动图中可以在一个活动上标出对象名，或者用泳道划分对象的责任，或者通过对象流表示，但是这些动作与对象的关系的表达都不如在交互图中表现得直接和清晰，因此，活动图最好和其他的行为建模工具一起使用。

实验六 包图设计

一、实验目的

掌握包图（组件图）设计的基本要点，学习绘制包图的技巧。

二、实验环境

软件平台：microsoft windows2000 /xp。软件工具：ea。

三、实验内容与要求

绘制选课系统的包图（组建图）。

四、实验预习和准备

查看相关资料，了解包图的组成部分及创建的基本方法。

五、实验过程与结果

六、实验小结和体会

1、包图由包和包之间的联系构成。包图的图形节点是包，节点之间用弧（依赖或泛化）连接。包图是维护和控制系统总体结构的重要建模工具。

2、在绘制包时，应注意：

（1）一般情况下应使用简单包的图标形式。

（2）当揭示一个包的内容时，仅仅显示出对于理解包在上下文中的意思来说有必要的那些元素。

(3)特别是，如果包用于系统配置管理方面的建模时，则应该显示与版本有关的标签值。

实验七 物理图设计

一、实验目的

了解物理图的组成，并绘制物理图。

二、实验环境

三、实验内容与要求

绘制选课系统的物理图。

四、实验预习和准备

阅读教材和有关资料，了解物理图方面的基本知识。

五、实验过程与结果

UML复习总结 第6篇

2.RUP(rational unified process): 统一开发过程是一种过程框架，有助于使用创建和部署用UML设计的软件。~生命周期分为四个阶段：起始阶段、细化阶段、构造阶段、转换 3.软件开发生命周期(SDLC)是一个规范的、系统的软件开发方法。可分为六个阶段：可行性分析、需求分析和规范说明、设计、编码、测试、维护。软件的开发方法：瀑布方法、原型方法、螺旋方法、双赢螺旋方法、增量方法。在设计阶段，有两种~：①面向功能方法以模块为中心，注重软件的功能。②面向对象（OO）方法支持重用、数据封装、以及继承、抽象和多态性等概念。

4.面向对象分析和设计（OOAD）是指根据对象、类、封装、继承、多态、抽象和动态邦定来分析需求以及设计软件系统。

5.软件系统的各个视图：①用例视图：表示系统为客户提供的功能②设计~：侧重于系统的静态和动态表示③实施~：表示软件系统中组成系统所需的各个文件和组件④部署~：表示将执行软件系统和硬件的组合关系。

6.四种建模技术：①需求建模：包括使用用例关系图描述需求。②静态~：包括使用类、对象和复合结构关系图来描述软件系统的静态成分③动态~：包括使用以下关系图来描述动态成分的行为：活动关系图、状态机关系图、通信关系图、序列关系图、交互概览图、时序关系图④架构~： 描述软件系统的内部结构如何构成：包关系图、主件关系图、部署关系图 7.需求管理是一种持续的系统化方法。~的四个阶段： 需求收集、~分析与协商、~规格化、~验证。需求分析指将需求分类和组织为功能性需求和非功能性需求的过程。功能需求指软件系统需要实现的功能和特性。非功能性需求指软件系统需要达到的性能指标。需求验证是在指定需求规范化后对需求进行验证的活动。需求验证包括：①确定所有的模糊需求②确定每条需求的来源③说明需求数量④确定需求之间的依赖关系⑤验证需求是否简明、可测试并且可跟踪⑥验证需求与软件系统中的约束是否有冲突

8.软件需求规格化（SRS）是详细分析任务后产生的文档。~必须提供信息：软件系统定义、SRS文档的用途、软件系统的范围、功能性需求、非功能性需求、目标软件系统的运行条件 9.角色有关的关系：泛化~： 存在于有类似的行为和特性的角色之间继承关系。关联~： 显示用例与角色之间通信关系。

10.用例关系图：①显示目标软件系统的用例和角色之间的交互关系②显示用例之间或角色之间的关系（如关联和泛化等）。用例可以（文本方式，事件流方式）描述外部角色与软件系统之间的交互过程。用例之间的关系：①扩展：指通过获取其它用例的某些功能来建立当前用例的方式扩展关系的箭头方向指向要被扩展的用例②包含：指一个用例的功能包含在另一个用例的功能中。包含关系里箭头指向被包含在另一个用例中的用例。11.类关系图表示类、接口、以及它们之间的关系。对象关系图表示类的特定实例的属性值以及对象之间的关系。类的属性和操作的可见性是：+ :表示属性或操作对于其它类可见。-：表示属性或操作对其它类不可见。#：表示基类的属性或操作仅对它的派生类可见。~:表示属性或操作只对同一个包里的类是可见的。类和对象之间的关系：①关联：表示两个类的对象之间一般上的逻辑意义上的联系。②聚合：表示两个类之间的整体与局部的关系③组合：表示两个类之间的整体与局部的关系④依赖性：表示两个类的对象之间一般上的动态功能上的联系⑤泛化：表示父类与子类之间派生关系⑥实现：表示类关系图里两个元素之间的语义关系，其中一个元素定义一个协议，另一个元素实现这个协议。12．抽象类是没有任何直接实例的类，继承于抽象类的类可以有直接实例，用于定义一组子类的公共特征和公共行为。接口是一组用于表示由类或组件提供的服务的操作集合，只能提供公共方法的声明，而不能提供这些公共方法的实现，不可以创建接口的对象。两者的相同处：①抽象类和接口都提供方法的规范，但是都不允许您直接创建实例。②抽象类和接口中指定的方法实现都在派生类中提供。不同处：①接口使您能实现多继承，因为一个类可以实现多个接口。但是，抽象类不支持多继承。一个类无法继承多个抽象类②抽象类包含的属性和方法可以是公共的、私有的或受保护的。接口只包含方法③抽象类可提供一部分方法的定义但接口不提供任何定义④抽象类在同一个包内使用，而接口可以跨多个包里实现。接口继承与抽象类继承的区别：①接口继承可多继承，而抽象类继承不行②接口继承中全是抽象方法，不提供定义，而抽象类继承中可有方法定义。

13.交互关系图：描述软件系统的成分如何彼此交互以实现系统用例的功能。~有两个部分：①协作者：描述交互关系图中参与交换的系统静态部分②交互：描述交互关系图中静态部分是怎样参与动态协作的。常用的交互关系图有：①序列关系图：以一组按时间顺序排序的消息的形式表示对象之间的交互②通信关系图：以消息的形式表示对象间的交互

14.包关系图用于描述软件系统的各个包以及包之间的关系。使用包来建模软件系统成分的好处有：①以可视化的方式显示功能组以及它们之间的关系②使得大型软件系统易于管理。用例分包规则：①以可视化的方式显示功能组以及它们之间的关系② 使得大型软件系统易于管理。类分包~：①具有相同继承层次结构的类分组在一个包里②具有复合关系的类分组在一个包里③将相互协作、彼此交互的类分组在一个包里。

15.组件:实现一组规定接口功能的可执行部件。组件实现了一组接口。组件类型：①部署组件：描述可执行系统最终可部署部件②工作产品~：描述工程软件有哪些文件组成③执行~：描述可执行软件有哪些可执行部件组成

16.框架和模式是使软件构件可重用的标准。框架：特定领域中类似应用程序的通用功能的模板，增加可重用性和减少应用程序开发时间。其特性：①类或组件的集合，具有执行一些特定或通用的功能②包含一些预定义规范的抽象和具体类接口③可以可通过子类化来扩展和实现这些抽象类和接口④定义一些抽象方法，这些方法接收系统中预定义的消息。模式：

新建的系统能满足可重用的要求，有助于软件组件之间更好的通信。~类型：通用职责分配软件模式（GRASP）、四人组模式(GoF)单例模式：允许创建它自身的唯一一个实例的类。对于有些类只应许创建一个实例对象。用静态数据成员来定义单件模式，以跟踪所创建对象的生命期。设计模式好处：①可让你创建能满足新需求的可重用的解决方案而无需修改现有系统。②有助于软件组件之间更好的通信。③有助于设计的重用、提供最有效的问题解决方案、给类分配职责。

17.实施质量流程的目的是为了在软件开发过程中检查所开发的软件模型和产品的质量。质量流程包括：①用于开发软件系统的软件开发过程的质量②软件开发过程中使用的软件模型的质量③软件开发过程结束时获得的软件产品的质量④质量流程自身的质量。生产质量过硬的产品时需要考虑的维度是：①技术：描述软件开发过程所需的工具以及生成的输出② 方法：描述软件开发过程期间需要执行以生成输出的操作顺序③社会学：描述软件开发过程所需的人力资源、环境条件和技能。质量保证技术检查：语法：确保软件模型使用正确的语法。语义：确保软件模型表达出目标意图并确保软件模型的表示在项目中一致。美观：确保软件模型对称并且完整。UML提供的三种扩展元素为：构造型：扩展 UML 词汇表约束：扩展 UML 构造块的语义关系。标记值：扩展 UML 构造块的属性

UML实训总结 第7篇

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

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

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

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

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

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

UML考试复习总结 第8篇

1)分解，对复杂问题进行分解，然后分别解决各个子问题。

2)抽象，指抽取系统中的基本特性而忽略非基本的特性，以便更充分地注意与当前目标有关的方面。

3)模块化，指解决一个复杂问题时自顶向下逐层把系统划分成若干模块的过程，并遵循高内聚低耦合的原则。

4)信息隐藏，即封装，指把模块内的实现细节与外界隔离，用户只需知道模块的功能，而不需了解模块的内部细节。3，视图

1)用例视图。

作用：描述系统的功能需求，找出用例和执行者；描述使用的图：用例图和活动图。2)逻辑视图。

作用：描述如何实现系统内部的功能 ；

描述使用的图：类图和对象图、状态图、顺序图、合作图和活动图。3)构件视图。

作用：描述系统代码构件组织和实现模块，及它们之间的依赖关系 ； 描述使用的图：构件图。4)进程视图。

作用：描述系统的并发性，并处理这些线程间的通信和同步 ；

描述使用的图：状态图、顺序图、合作图、活动图、构件图和配置图。5)配置视图。

作用：描述系统的物理设备配置，如计算机、硬件设备以及它们相互间的连接 ； 描述使用的图：配置图。4，基本概念

1)用例是对一个活动者(actor)使用系统的一项功能时所进行的交互过程的一个文字描述序列，是系统、子系统或类和外部的参与者(actor)交互的动作序列的说明，包括可选的动作序列和会出现异常的动作序列。

2)参与者(actor)是指系统以外的、需要使用系统或系统交互的东西，包括人、设备、外部系统等。

3)用例图（use case diagram）以图解的形式概括了系统中的不同参与者和用例，并显示了哪些参与者能够参与哪些用例。

4)类图(Class diagram)是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。5)类间关系

(1)关联(association)是模型元素间的一种语义联系，它是对具有共同的结构特性、行为特性、关系和语义的链(link)的描述。一个关联可以有两个或多个关联端(association end)，每个关联端连接到一个类。

(2)聚集和组合：聚集是一种特殊形式的关联。聚集表示类之间整体与部分的关系。聚集关系的实力是传递的，反对称的。组合表示的也是类之间的整体与部分之间的关系，但组合关系中的整体与部分具有同样的生存周期。

(3)泛化关系：泛化定义了一般元素和特殊元素之间的分类关系，类和类之间的泛化关系就是类与类之间的继承关系。

(4)依赖关系：假设有两个元素X和Y，如果修改了X元素的定义可能会导致两一个元素Y的定义的修改，则称元素Y依赖于元素X。6)接口类：只有方法没有属性，且所有方法只有声明没有实现的类。7)边界类控制类和实体类的画法

8)对象图表示一组对象及他们之间的联系。对象图是系统的详细状态在某一时刻的快照，常用于表示复杂的类图的一个实例。9)包就像一个“容器”，可用于组织模型中的相关元素。

10)包之间可以存在依赖关系，但这种依赖关系没有传递性。11)对包的命名有两种方式，即简单包名和路径包名。

12)构件是系统中遵从一组接口且提供其实现的物理的、可替换的部分。

13)构件图则显示一组构件以及它们之间的相互关系，包括编译、链接或执行时构件之间的依赖关系。

14)部署图也成为配置图、实施图，可以用来显示系统中计算节点的拓扑结构和通信路径与节点上运行的软构件等。15)交互图，是用来描述对象之间以及对象与参与者之间协作关系以及动态协作关系以及协作过程中行为次序的图形文档。

16)交互图包括顺序图和协作图两种形式。顺序图着重描述对象按时间顺序的消息交换，协作图着重描述系统成分如何协同工作。

17)顺序图也称时序图，是显示对象之间交互的图，这些对象是按时间顺序排列的。顺序图是二维模型，在顺序图中水平方向为对象维，沿水平方向排列的是参与交互的对象；顺序图中垂直方向为时间维，沿垂直向下方向按时间递增顺序列出各对象所发出和接受的消息。18)顺序图中的消息

(1)调用消息：调用消息的发送者把控制传递给消息的接收者，然后停止活动，等待消息接收者放弃或返回控制。

(2)异步消息：异步消息的发送者通过消息把信号传递该消息的接收者，然后继续自己的活动，不等待接收者返回消息或控制。

(3)返回消息：返回消息表示从过程调用返回。

(4)阻止消息和超时消息：阻止消息是指消息发送者发出消息给接收者，如果接收者无法立即接收消息，则发送者放弃这个消息。超时消息是指消息发送者发出消息给接收者并按指定时间等待。如果接收者无法在指定时间内接收消息，则发送者放弃这个消息。19)协作图是用于描述系统的行为是如何由系统的成分协作实现的图，协作图中包括的建模元素有对象、消息、链等。

20)状态图(statechart diagram)主要用于描述一个对象在其生存期间的动态行为，表现一个对象所经历的状态序列，引起状态转移的事件(event)，以及因状态转移而伴随的动作(action)。21)活动(activity)表示的是某流程中任务的执行，它可以表示算法过程中语句的执行。22)状态图可以表现一个对象在生存期的行为、所经历的状态序列、引起状态转移的事件以及因状态转移引起的动作。活动图用来表示完成一个操作所需要的活动，或者是一个用例实例的活动。实际也是一种流程图，描述活动的序列，即系统由一个活动到另一个活动的控制流。

UML九种视图总结 第9篇

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、部署模型的目的：

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