UML笔记02-UML概述

UML语言概述

  UML由视图（views）、图（Diagrams）、模型元素（Model elements）和通用机制（general mechanism）等几个部分构成。

视图用来表示被建模系统的各个方面（从不同的目的出发建立，为系统建立多个模型,这些模型都反映同一个系统，且具有一致性）。

  图由各种图片（graph）构成，用来描述一个视图的内容。

  模型元素代表面向对象中的类、对象、消息和关系等概念，是构成图的最基本的常用概念。

  通用机制用于表示其他信息，如注释、模型元素的语义等。另外，它还提供扩展机制，使UML语言能够适应一个特殊的方法（或过程）、或扩充至一个组织或用户。

 

视图

  描述一个系统设计到该系统的许多方面，比如：功能性方面（包括静态结构和动态交互）、非功能性方面（定时需求、可靠性、展开性等）和组织管理方面（工作组、映射代码模块等）。

  完整地描述系统，通常的做法是用一组视图反映系统的各个方面，每个视图代表完整系统描述中的一个抽象，显示这个系统中的一个特定方面。每个视图由一组图构成，图中包含了强调系统中某一个方面的信息。视图与视图之间有时会产生轻微的重叠，从而使得一个图实际上可能是多个视图的组成不封。如果用不同的视图观察系统，每次只集中地观察系统的一个方面。视图中的图应该简单，易于交流，且与其他的图（图用图形符号表示，图符号代表系统中的模型元素）和视图有关联关系。

用例视图

  用例视图（Use-case View）用于描述系统应该具有的功能集。它是从系统的外部用户角度出发，对系统的抽象表示。

用例视图所描述的系统功能依靠于外部用户或另一个系统触发激活，为用户或另一个系统提供服务实现用户或另一个系统与系统的交互。系统实现的最终目标是提供用力视图中描述的功能。

用例用来表示系统能共提供的功能（系统用法），一个用例是系统用法（功能请求）的一个通用描述。

用例视图是其他视图的基础。其他视图的构造和发展依赖于用例视图中所描述的内容。

用例视图还可以用于测试系统是否满足用户的需求和验证系统的有效性。

用例视图主要为用户、设计人员、开发人员和测试人员而设置。

逻辑视图

  逻辑视图（Logical View）用来显示系统内部的功能是怎么设计的，它利用系统的静态结构和动态行为来刻画系统功能。

  静态结构在类图和对象图中描述，主要描述类、对象和它们之间的关系。

  动态行为用状态图、序列图、协作图和活动图描述，主要描述对象之间的动态协作，当对象之间彼此发送消息给给定的函数时产生动态写作，一致性（persistence）和并发性（concurrency）等性质。

组件视图

  组件视图（Component View）用来显示代码的组织方式。它描述了实现模块（implementation module）和它们之间的依赖关系。

  组件视图由组件构成。组件式代码模块，不同类型的代码模块形成不用的组件，组件按照一定的结构和依赖关系呈现。

组件视图主要供开发者使用。

并发视图

  并发视图（Concurrency View）用来显示系统并发工作状况。并发视图将系统划分为进程和处理机方式，通过划分引入并发机制，利用并发高效率地使用资源、并行执行和处理异步事件。除了划分系统为并发执行的控制线程外，并发视图还必须处理通信和这些线程之间的同步问题。

  并发视图所描述的方面属于系统中的非功能性质方面，由动态图（状态图、序列图、协作图、活动图）和执行图（组件图、展开图）构成。

  并发视图供系统开发者和集成者使用。

展开视图

  展开视图（Deployment View）用来显示系统的物理架构，即系统的物理展开。

  展开视图提供给开发者、集成者和测试者。

 

图

  图（diagram）由图片（graph）组成，图片是模型元素的符号化。把这些符号有机地组织起来形成的图表示了系统的一个特殊部分或某个方面。

用例图

  用例图用于显示若干角色（actor）以及这些角色与系统提供用例之间的连接关系。

  用例图仅仅从角色（触发系统功能用户等）使用系统的角度描述系统信息，也就是站在系统外部看系统外部看系统功能，它并不描述系统内部对该功能的具体操作方式。

类图

  类图用来表示系统中的类和类与类之间的关系，它是对系统静态结构的描述。用来表示系统中需要处理的事物。

对象图

  对象图是类图的变体。两者之间差别在于对象图表示的是类图的对象实例，而不是真实的类。它是类图的一个范例（example），它即使具体地反映了系统执行到某处时，系统的工作状况。

  对象图没有类图重要，对象图通常用来示例一个复杂的类图，通过对象图反映真正的实例是什么，它们之间可能具有什么样的关系帮助理解类图。

状态图

  一般来说，状态图是对类图所描述事物的补充说明，它显示了类的所有对象可能具有的状态，以及引起状态变化的事件。

  并不是所有的类都有相应的状态图。状态图仅用于具有下列特点的类：具有若干个确定的状态，类的行为在这些状态下会受到影响且被不同的状态改变。

序列图

  序列图用来反映若干个对象之间的动态协作关系，也就是随时间的流逝，对象之间是如何交互。

  序列图主要反映对象之间已发送消息的先后次序，说明对象之间的交互过程，以及系统执行过程中，在某一具体位置将会有什么事情发生。

协作图

  协作图和序列图的作用一样，反映的也是动态协作。除了显示消息变化（称为交互）外，协作图还显示了对象和它们之间的关系（称为上下文有关）。

  如果需要强调时间和序列，最好选择序列图；如果需要上下文有关的，最好选择协作图。

活动图

  活动图反映一个连续的活动流，常用于描述某个操作执行时的活动状态。

  活动图由各种动作状态（action state）构成，每个动作状态包含可执行动作的规范说明。当某个动作执行完毕，该动作的状态就会随着改变。这样，动作状态的控制就从一个状态流向另一个与之相连的状态。

组件图

  组件图用来反映代码的物理结构

展开图

  展开图用来显示系统中软件和硬件的物理架构。

 

模型元素

   类、对象、状态、结点、包（package）和组件的符号图例：

  模型元素和与模型元素之间的联系也是模型元素，常见的有关联（association）、通用化（generalization）、依赖（dependency）、聚合（agregation）。

模型元素还包括消息、动作和版类（setreotype)。

 

通用机制

  UML利用通用机制为图附加一些信息，这些信息通常无法用基本的模型元素表示。

  常用的通用机制有修饰、笔记和规格说明。

修饰（adornment）

  在图的模型元素上添加修饰，为模型元素附加一定的语义。

如类用长方形表示，其名字用黑体字书写（如，计算机）。如果类的名字带有下划线，它则代表类的一个对象（如，某某的计算机）。

笔记（note）

  为了在模型中添加一些额外的模型元素无法表示的信息，UML提供了笔记。笔记可以房子任何图的任意位置，并且可以含有各种各样的信息。

  笔记可以包含版类（用于描述笔记的类型）。

规格说明（specification）

  模型元素含有一些性质，这些性质以数值方式体现。一个性质用一个名字和一个值表示，又称作加标签值（tagged value）。UML提供了许多预定义的性质，如：文档（document）、响应（responsibility）、持续性（persistence）和并发（concurrency）。

 

扩展机制

版类（stereotype）

  版类扩展机制是指在已有的模型元素基础上建立一种新的模型元素。版类与现有的元素相差不多，只不过比现有的元素多一些特别的语义。

  版类的表示方法是在元素名称旁边添加一个版类名字。版类也可以i用一个图形表示。

加标签值（tagged value）

约束（constrains）

  约束是对元素的限制。通过约束限制元素的用法或元素的语义。