UML九种视图总结

第一篇：UML九种视图总结

1.UML关系

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

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

3、部署图实例：

第二篇：oracle视图总结

oracle视图总结(转)

视图简介: 视图是基于一个表或多个表或视图的逻辑表，本身不包含数据，通过它可以对表里面的数据进行查询和修改。视图基于的表称为基表。视图是存储在数据字典里的一条select语句。通过创建视图可以提取数据的逻辑上的集合或组合。

视图的优点：

1.对数据库的访问，因为视图可以有选择性的选取数据库里的一部分。2.用户通过简单的查询可以从复杂查询中得到结果。3.维护数据的独立性，试图可从多个表检索数据。4.对于相同的数据可产生不同的视图。

视图的分类：

视图分为简单视图和复杂视图。

两者区别如下：

1.简单视图只从单表里获取数据，复杂视图从多表获取数据； 2.简单视图不包含函数和数据组，复杂视图包含； 3.简单视图可以实现DML操作，复杂视图不可以。

视图的创建：

CREATE [OR REPLACE] [FORCE|NOFORCE] VIEW view_name [(alias[, alias]...)] AS subquery [WITH CHECK OPTION [CONSTRAINT constraint]] [WITH READ ONLY] 其中：

OR REPLACE：若所创建的试图已经存在，ORACLE自动重建该视图； FORCE：不管基表是否存在ORACLE都会自动创建该视图； NOFORCE：只有基表都存在ORACLE才会创建该视图： alias：为视图产生的列定义的别名；

subquery：一条完整的SELECT语句，可以在该语句中定义别名；

WITH CHECK OPTION ： 插入或修改的数据行必须满足视图定义的约束； WITH READ ONLY ： 该视图上不能进行任何DML操作。

例如： Sql代码

1.CREATE OR

REPLACE

VIEW dept_sum_vw

2.(name,minsal,maxsal,avgsal)

3.AS SELECT d.dname,min(e.sal),max(e.sal),avg(e.sal)

4.FROM

emp e,dept d

5.WHERE e.deptno=d.deptno

6.GROUP BY d.dname;

视图的定义原则：

1.视图的查询可以使用复杂的SELECT语法，包括连接/分组查询和子查询； 2.在没有WITH CHECK OPTION和 READ ONLY 的情况下，查询中不能使用 ORDER BY 子句；

3.如果没有为CHECK OPTION约束命名，系统会自动为之命名，形式为SYS_Cn;4.OR REPLACE选项可以不删除原视图便可更改其定义并重建，或重新授予对象权限。

查询视图：

视图创建成功后，可以从视图中检索数据，这点和从表中检索数据一样。示例：

SQL>SELECT * FROM dept_sum_vw；

修改视图：

通过OR REPLACE 重新创建同名视图即可。

删除视图：

DROP VIEW VIEW_NAME语句删除视图。删除视图的定义不影响基表中的数据。

只有视图所有者和具备DROP VIEW权限的用户可以删除视图。视图被删除后，基于被删除视图的其他视图或应用将无效。

查询视图定义：

SELECT view_name,text from user_views;其中text显示的内容为视图定义的SELECT语句，可通过DESC USER_VIEWS 得到相关信息。

视图上的DML 操作： DML操作应遵循的原则：

1.简单视图可以执行DML操作； 2.在视图包含GROUP 函数，GROUP BY子句，DISTINCT关键字时不能删除数据行； 3.在视图不出现下列情况时可通过视图修改基表数据或插入数据：

a.视图中包含GROUP 函数，GROUP BY子句，DISTINCT关键字； b.使用表达式定义的列； c.ROWNUM伪列。

d.基表中未在视图中选择的其他列定义为非空且无默认值。WITH CHECK OPTION 子句

通过视图执行的INSERTS和UPDATES操作不能创建该视图检索不到的数据行，因为它会对插入或修改的数据行执行完整性约束和数据有效性检查。（也就是说在执行INSERTS、UPDATES时，WHERE条件中除需要INSERT、UPDATE本身的限制条件之外，还需要加上视图创建时的WHERE条件。）

例如：

CREATE OR REPLACE VIEW vw_emp20 AS SELECT * FROM emp WHERE deptno=20 WITH CHECK OPTION constraint vw_emp20_ck;视图 已建立。

查询结果：

SELECT empno,ename,job FROM vw_emp20;EMPNO

ENAME

JOB---------------------

--------------

-------------7369

SMITH

CLERK 7566

JONES

MANAGER 7902

FORD

ANALYST 修改：

UPDATE vw_emp20 SET

deptno=20 WHERE empno=7902;将产生错误：

UPDATE vw_emp20 * ERROR 位于第一行：

ORA-01402：视图WITH CHECK OPTION 违反WHERE 子句

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1，Oracle是可以通过视图来修改Base table的。所谓base table就是用来构建视图的表，也就是视图的数据来源表。但是这种修改是有条件的。比如： create view v_emp as select empno,ename,job,deptno from emp where deptno=10 with check option constraint emp_cnst;如果有这个限制，那么通过视图v_emp 插入数据的deptno字段的值必须是10，否则就会报“ORA-01402: 视图 WITH CHECK OPTIDN 违反 where 子句”的异常。

2，联结视图：

create view dept1_staff as select e.ename, e.empno, e.job, d.deptno, d.dname from emp e,dept d where e.deptno in(10,30)and e.deptno = d.deptno； 将两个表的数据联结起来，看起来应该是一个内联结（Inner joint）。

对于联结视图（Joint view）的修改规则稍显复杂，设计到所谓key_preserved table的概念。通过联结视图来修改基表，只有那些key_preserved 的表才能被修改。上述创建视图语句中emp和dept通过deptno进行联结构成视图时，emp就是key_preserved 表，而dept不是。为什么？因为在dept1_staff 中empno的值唯一的而deptno不是唯一的。所以emp是key_preserved 而dept不是。因此只能通过该视图来修改emp，而不能修改dept的数据。

3,Oracle视图非常强大的功能之一在于其可以创建一个带有错误的视图。比如说视图里的字段在基表里不存在，该视图仍然可以创建成功，但是非法的且无法执行。当基表里加入了该字段，或者说某个字段修改成视图里的该字段名称，那么视图马上就可以成为合法的。这个功能很有意思。例子：

创建基表： create table v_test(name varchar2(32),age number(12));创建带错误的视图：

create force view view_test as select name,age,address from v_test;（注意加上force选项）

由于address字段在v_test里不存在，所以会报warning: View created with compilation errors的警告，而且执行select * from view_test;时会报“ORA-04063: view “SCOTT.VIEW_TEST” 有错误”的异常。但是如果在v_test里加上address字段，那么视图就会合法。对基表进行修改：

alter table v_test add(address varchar2(128));

现在再执行select * from view_test；就会执行成功了。

from:http://www.blogjava.net/jinhualee/archive/2006/07/14/58115.html

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

其他问题总结：

1、视图上是否可以创建索引？

一般视图上不用建立索引，对视图的操作最终会转化为对表的操作。一个讨论：http://www.itpub.net/viewthread.php?tid=150019&extra=&page=1

第三篇：UML复习总结

1.UML(unified modeling language): 统一建模语言是创建描绘软件系统结构和设计蓝图的标准语言。它用于指定、构造、记录软件系统的工件并使之可视化。~ 的基本组成部分：包括 UML 的静态、动态、包和注释等部分。~ 的构建块包含基本的成分、关系和关系图。基本成分包括结构、行为、分组和注释成分。

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 构造块的属性

18静态建模：它表示软件系统的静态或结构成分。它包括类关系图和对象关系图。它有助于描绘系统成分之间的关联和依赖性。动态建模：它表示软件系统静态成分的行为过程。它包含交互、活动和状态关系图。它有助于表达系统在一段时间内的行为流程。

第四篇：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课程设计总结

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

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

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

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

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

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

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