UML核心技术学习(二)

第一章       UML语言概述

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

l         视图用来表示被建模系统的各个方面（从不同的目的出发建立，为系统建立多个模型、这些模型都反映同一个系统，且具有一致性）；视图由多个图（diagrams）来构成，它不是一个图片（graph），而是在某一个抽象层上，对系统的抽象表示；如果要为系统建立一个完整的模型图，只需定义一定数量的视图，每个视图表示系统的一个特殊的方面就可以了，视图还把建模语言和系统开发时选择的方法或过程连接起来的

l         图由各种图片（graph）构成，用来描述一个视图的内容，UML定义了9种

l         模型元素代表面向对象中的类、对象、消息和关系等概念，是构成图的最基本的常用概念，一个模型元素可以用在多个不同的图中，无论怎样使用，它总是具有相同的含义和相同的符号表示

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

l         三种建模方式：静态、动态和功能性建模

2.1   视图

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

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

2.1.1   用例视图

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

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

       用例视图中可以包含若干个用例（use-case），用例用来表示系统能够提供的功能（系统用法），一个用例是系统用法（功能请求）的一个通用描述

       用例视图是其它视图的核心和基础

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

2.1.2   逻辑视图

       逻辑视图（Logical view）用来显示系统内部的功能是怎样设计的，它利用系统的静态结构和动态行为来刻画系统功能。静态结构描述类、对象和它们之间的关系等；动态行为主要描述对象之间的动态协作，当对象之间彼此发送消息给给定的函数时产生动态协作，一致性（persistence）和并发性（concurrency）等性质，以及接口和类的内部结构都要在逻辑视图中定义

       静态结构在类图和对象图中描述，动态建模用状态图、序列图、协作图和活动图

2.1.3   组件视图

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

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

2.1.4   并发视图

       并发视图（Concurrency view）用来显示系统的并发工作状况。并发视图将系统划分为进程和处理机方式，通过划分引入并发机制，利用并发高效地使用资源、并行执行和处理异常事件，并发视图还必须处理通信和这些线程之间的同步问题，它所描述的是系统中的非功能性质方面

       并发视图提供给系统开发者和集成者（integrator）使用，它由动态图（状态图、序列图、协作图、活动图）和执行图（组件图、展开图）构成

2.1.5   展开视图

       展开视图（Deployment view）用来显示系统的物理架构，即系统的物理展开。比如，计算机和设备以及它们之间的联接方式。其中计算机和设备称为结点（node）。它由展开图表示，展开视图还包括一个映射，该映射显示在物理架构中组件是怎样展开的，比如，在每台独立的计算机上，哪一个程序或对象在运行

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

2.2   图

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

2.2.1   用例图

       用例图（use-case diagram）用于显示若干角色（actor）以及这些角色与系统提供的用例之间的联接关系，用例是系统提供的功能（即系统的具体用法）的描述，用例图仅仅从角色（触发系统功能的用户或系统等）使用系统的角度描述系统中的信息，也就是站在系统外部察看系统功能，它并不描述系统内部对该功能的具体操作方式

2.2.2   类图

类图（class diagram）用来表示系统中的类和类之间的关系，它是对系统静态结构的描述，类用来表示系统中需要处理的事物，类与类之间有多种连接方式（关系），比如：关联（彼此间的连接）、依赖（一个类使用另一个类）、通用化（一个类是另一个类的特殊化）、打包（packed，多个类聚合成一个基本元素）。类和类之间的这些关系都体现在类图的内部结构之中，通过类的属性（attribute）和操作（operation）这些术语反映出来，在系统的生命周期中，类图所描述的静态结构在任何情况下都是有效的

2.2.3   对象图

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

       对象图没有类图重要，对象图通常用来示例一个复杂的类图，通过对象图反映真正的实例是什么，它们之间可能具有什么样的关系，帮助对类图的理解。对象图也可以用在协作图中作为其中的一个组成部分，用来反映一组对象之间的动态协作关系

2.2.4   状态图

       状态图（State diagram）是对类所描述的事物的补充说明，它显示了类的所有对象可能具有的状态，以及引起状态变化的事件。事件可以是给它发送消息的另一个对象或者某个任务执行完毕（比如，指定时间到）。状态的变化称作转移（transition），一个转移可以有一个与之相连的动作（action），这个动作指明了状态转移时应该做些什么

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

2.2.5   序列图

       序列图（Sequence diagram）用来反映若干个对象之间的动态协作关系，也就是随着时间的流逝，对象之间是如何交互的。主要反映对象之间已发送消息的先后次序，说明对象之间的交互过程，以及系统执行过程中，在某一具体位置将会有什么事件发生

       序列图由若干个对象组成，每个对象用一个垂直的虚线表示，每个对象的正下方有个矩形条，表示该对象随时间流逝的过程（从上至下），对象之间传递的消息用消息箭头表示

2.2.6   协作图

       协作图（Collaboration diagram）和序列图一样，反映的也是动态协作，除了显示消息变化（称为交互）外，协作图还显示了对象和它们之间的关系（称为上下文有关），如果需要强调时间和序列，使用序列图；如果需要强调上下文相关，使用协作图

2.2.7   活动图

       活动图（activity diagram）反映一个连续的活动流，相对于描述活动流（比如，用例或交互）来说，活动图更常用于描述某个操作执行时的活动状况

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

      

2.2.8   组件图

       组件图（Component diagram）用来反映代码的物理结构

       代码的物理结构用代码组件表示，组件可以是源代码、二进制文件或可执行文件组件

       组件包含了逻辑类或逻辑类的实现信息，因此逻辑视图与组件视图之间存在着映射关系，组件之间也存在依赖关系，利用这种关系可以分析出一个组件的变化会给其他组件带来怎样的影响

       组件可以与公开的任何接口一起显示，也可以把它们组合起来形成一个包（package），在组件图中显示这种组合包。

2.2.9   展开图

       展开图（deployment diagram）用来显示系统中软件和硬件的物理架构，可以清晰地看到计算机和设备（用结点node表示）之间的关系

2.3   模型元素

       可以在图中使用的概念统称为模型元素。模型元素用语义、元素的正式定义或确定的语句所代表的准确含义来定义

       模型元素在图中用其相应得视图元素（符号）表示。

       模型元素与模型元素之间的连接关系也是模型元素，常见的关系有关联（association）、通用化（generalization）、依赖（dependency）和聚合（aggregation），其中聚合是关联的一种特殊形式

       除了上述的模型元素外，模型元素还包括消息、动作和版类（stereotype）。

2.4   通用机制

       UML语言利用通用机制为图附加一些信息，这些信息通常无法用基本的模型元素表示，常用的通用机制有修饰（adornment）、笔记（note）和规格说明（specification）

2.4.1   修饰

       在图的模型元素上添加修饰为模型元素附加一定的语义。类用的是黑体书写的，如计算机，若类的名字带有下划线，则代表该类的一个对象，如丁一的计算机

 

 

（这是类） （这是实例，加了下划线）

2.4.2   笔记

       无论建模语言怎样扩展，它不可能应用于描述任何事物，为了在模型中添加一些额外的模型元素无法表示的信息，UML语言提供了笔记能力。笔记可以放在任何图的任何位置

用虚线连接起来，可以包含各式各样的信息

2.4.3   规格说明

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

2.5   扩展机制

       三种扩展机制：版类（stereotype）、加标签值（tagged value）、约束（constrains）

2.5.1   版类

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

       版类的表示方法是在元素名称旁边添加一格版类的名字，版类的名字用字符串（用双尖角括号括起来），三种版类的图示方法：

2.5.2   加标签值

       性质用名字和值一对信息表示，性质也成为加标签值，任何一种类型的信息都可以定义为元素的性质

2.5.3   约束

       约束是对元素的限制。通过约束限定元素的用法或元素的语义，如图，表示年龄大于60岁的人是老年人

2.6   用UML建模

       用UML语言建造系统模型的时候，并不是只建一个模型。在系统开发的每个阶段都要建造不同的模型，建造的模型目的也不同。需求分析阶段建造的模型用来捕获系统的需求、描绘与真实世界相应的基本类和协作关系；设计阶段的模型是分析模型的扩充，为实现阶段作指导性的、技术上的解决方案；实现阶段的模型是真正的源代码（source code），编译后的源代码就成了程序；最后是展开模型，它在物理构架上解释系统是如何展开的

       在各个阶段建造的模型都应该独立保存，以便返回改错。建模语言只能用于建造模型，不能用于保证系统的质量

       若使用了UML语言建模，建模工作一定要依照某个方法或过程进行，建模的过程一般被分为：需求分析阶段、设计阶段、实现阶段和展开阶段

   讨论->假说->case工具描述->前期模型（反复加细，细化解决问题的方案和文档）->集成（integration）模型->验证（verification）模型

 

 

 

 

       集成就是把同一系统中的各种图或模型结合起来，通过验证工作保证图与图之间数据的一致性，通过验证工作，保证模型能够正确地解决问题

       最后，在实际解决问题的时候，模型被实现为各种原型（prototype），生成原型时，要对生成的原型进行评价，以便发现可能潜在的错误、遗漏的功能和开发代价过高等不足之处。注意，把图原型化的工作，一定要在把多个图结合成原型结构之后，原型只是一个很粗浅的东西，构建原型只是为了对其进行评价，发现其中的不足

2.7   工具的支持

       一个现代的case工具（建模工具）应提供如下功能：

l         画图（draw diagrams）

l         积累（repository）：一个图中类名改变，及时映射到各使用的地方

l         导航（navigation）：方便从一个图到另一个图切换

l         多用户支持

l         产生代码（generate code）

l         逆转（reverse）：可以通过编写代码来建模

l         集成（integrate）

l         覆盖模型的所有抽象层

l         模型互换