UML建模培训教材格式

1、第二章统一建模语言简介1、UML和软件体系结构(1) UML是UML是用于描绘软件蓝图的标准语言。建模的原则：准确、分层、分治、标准统一律槿语宣 UML就是满足汶四个原则的建槿语。UML是用于描绘软件蓝图的标准语言。它可用于对软件密集型系统进行视化说明建造建档。UML是用于描绘软件蓝图的标准语言。UML是蓝图：支持视化：UML包括一组明确定义的标准图符描述软件产品生产活动中需要交流的各种内容。软件开发的所有相关人员，通过图符能了解和表达需要交流的内容。支持建模蓝图是模型的表达UML 是标准语言支持说明，建造和建档。生产软件产品，需要对此产品进行 说明说明需要标准化UML 是- 一种语言意味着

2、UML是以标准化的形式,表达这些说明的建模工 具。它以标准化的方式，完成对软件的市场需求的说明功能的说明运行原理的说明内部结构的说明对外接口的说明及其实现方式的说明，UML 是- -种语言意味着它是标准化的因此，用UML表达的软件模型，可以直接和某种设计语言建立映射关系，通过 UML 建模工具，可以 UML模型转换为对应的 程序设计语言源代码框架。UML就是通过此种方式，支持软件系统的建造的UML 是- -种语言意味着它是标准化的因此也能有效的支持软件生产的建档(documentation)UML有标准的描述手段(格式)来表达和组织这些内容UML支持软件制成品的建档，包括：开发活动中产牛的用于

3、控制、评Y则(measuring)、交流的各种中间产物，如：需求分析软件体系结构(architecture)结构设计行为设计源代码/项目计戈U /测试计戈U /传行版本e.g.:用例视图来描述需求分析用逻辑视图来描述结构设计，等等。作为描绘软件蓝图的语言UML定义了一系列的图符来描述软件密集型的系统这些图符有严格的语义和清晰的语法。这些图符及其背后的语义和语法，组成了一个标准，使得软件开发的所有相关人员都能用它来对软件系统的各个侧 面进行描述。(2)、UML根据软件体系结构对软件进行建模分层是软件建模的重要原则为了表达不同的软件开发相关人员在软件开发周期的不同时期看待软 件产品的不同侧重面，需

4、要对模型进行分层。UML 根据软件产品的 体系结构 (architecture) 对软件进行分层软件体系结构由一系列的决定组成.这些决定定义了如下内容:(1)、软件系统的组织；(2) 、构成软件系统的结构元素的结构及它们之间的接口：(3) 、结构元素的行为及元素之间的协同( collaboration );(4) 、结构元素的不断组合以构成日渐完备的子系统的过程：(5 )、指导软件建造过程的软件构筑风格(architectural style ):静态和动态元素之间的接口协同构成(composition )。软件体系结构不仅仅决定软件的结构和行为，而且还决定软件的用途功能性能应变性(resil

5、ience)可重用性经济和技术方面的限制和折衷以及美学考虑(aesthetic concern)。UML 将软件的体系结构分解为五个不同的侧面(右图)称为视图(view)。分别是：用例视图(Use caseview)设计视图(designview)井程莉I图 (process view)实壬见串见图(implementation view)分布见图(deployment view)设计*见图禾W井程串见图又可被统一称为谬.辑辛见图(logical view)。其中每个视图分别关注软件开发的某一侧面视图由一种或多种 模型图（diagram）构成。模型图描述了构成相应视图的基本模型元素（ elem

6、ent）及它们之间的相互关系。1、用 例视图 (use case view):用例视图用来支持软件系统的需求分析，它定义系统的边界，关注的是系统的外部功能的描述。它从系统的使用者的角度，描述系统的外部的动态行为静态的功能系统的动态功能由UML以下模型图描述：交互图(interaction diagram)状态图(state-chart diagram)活动图(activity diagram)2、逻辑视图 (Logical View )：逻辑视图定义系统的实现逻辑。描述为实现用例图描述的功能，在对软件系统进行设计时，所产生的设计概念，设计概念又称为软件系统的设计词汇(vocabulary)。逻

7、辑视图定义了设计词汇的逻辑结构存在于它们之间的语义联系。设计词汇包括系统的类协同接口及其关系对逻辑视图的描述在原则上与软件系统的实现平台无关。它相当于电子产品生产中的电原理图。逻辑视图包含的模型图有：类图 (class diagrams)对象图 (object diagrams)交互图 (interaction diagrams )状态图(state-chart diagrams)活动图 (state-chart diagrams)。3、实现视图(implementation view )当系统的逻辑结构在逻辑视图里被定义之后，需要定义逻辑结构的物理实现。这包括设计元素对应的源代码文件各物理文

8、件之间的关系存放路径，等等。实现视图就是定义这些内容的地方。它当于电子产品的印刷电路板的布线图。实现视图描述组成一个软件系统的各个物理部件，这些部件以各种方式组合起来，(如： 不同的源代码经过编译，构成一个可执行系统；或者不同的软件组件配置成为一个可执行系统；以及不同的网页文 件，以特定的目录结构，组成一个网站，等等)构成了一个可实际运行的系统。实现视图包含的模型图有：部件图(Component diagram)交互图(Interaction Diagram )状态图(state-chart diagram)活动图(activity diagram )。4、分布视图(Deployment Vi

9、ew )软件产品将运行在计算机硬件系统上如果软件产品是面向网络的应用系统，则有可能同时运行在多个计算机上。分布视图用来描述软件产品在计算机硬件系统和网络上的 安装分发(delivery)分布(distribution )在分布视图中，系统的静态特性用分布图(deployment diagram)描述，动态特性用交互图(interaction diagram )状态图(state-chart diagram)活动图(activity diagram )描述。2、UML概述从软件的体系结构出发，UML把软件模型分成了五个视图每个视图由不同的模型图构成。模型图实际上就是 UML的基本成员之一。作为U

10、ML的完整的概念模型，UML的构成为：UML = UML 成员 + UML 建模规则(roles of the UML)UML建模规则相当于建模语言的语法UML 成员(building blocks of the UML )它UML的基本组成部分它和UML建模规则一起组成了 UMLUML成员可进一步划分为UML 基本模型元素 (things in UML ) 关系 (relationship) 模型图(diagram )：UML成员=UML基本模型元素+关系+模型图UML基本模型元素：类似于电子产品电原理图里的集成电路符号，是模型图上包含的基本符号。基本模型元素可分为四类， 它们是：结构模型元

11、素 (structural things )行为模型元素 (behavioral things )分组模型元素 (grouping things )注解元素 (annotational things ):UML基本模型元素=结构模型元素+行为模型元素+成组元素+注解元素关系：基本模型元素之间的语义上的联系，在 UML里用关系来描 述。(1)、结构模型元素结构模型元素是UML模型里的名词(noun)是模型的静态组成部分代表软件系统的概念的，或物理的存在。例如：类(class)最常用的一个结构模型元素它代表一系列共享同样的属性(attributes)操作 (operation)关系、语义的对象(o

12、bject)。类的图形表示类在模型图（类图）上被通常用一个矩形为一个矩形其上包含类的名字属性操作（下图）Windoworiginsize open() close() display()图2.2类结构模型元素一共有七种，它们是：类接口( interface )协同用例(use case )主动类(active class )组件(component)节点(node)在这些结构元素中，最常用的包括：类、用例、接口、组件等(下图)I Shell.cpp1IISpellingCheck Pass Word用例接口组件图2.3 一些常用的结构模型元素行为模型元素(behavioral things )

13、UML模型的动态组成部分它是模型的动词，代表软件系统在空间和时间上的行为。行为模型元素包括两类：交互(interaction )状态机(state machine)行为模型元素=交互+状态机交互它是系统内一系列的对象之间互相交换消息的行为。消息代表软件系统内两个对象中一个对象向另一个对象发出的 执行某种操作的请求。交互描述了一系列的对象为完成某一项任务而联合采取的一系列的行动，其中包括这些行动在时间上的顺序，以及为执行这些动作序列，对象之间所发生的语义上的联系。所以，消息是描述交互的一个重要手段。消息的图形表示：在模型图上，消息被表示为一个箭头（下图）display消息状态机：状态机是描述一个

14、对象的动态特性的有效手段它描述的是对象在其生命周期内， 在响应外界的事件的过程中, 自身的状态的变化过程。Waiting状态状态机包括对象状态（上图2.5）事件由事件引起的状态之间的变迁以及变迁发生的同时对象所执行的动作(3)、成组模型元素分治的原则：在为复杂的软件系统建模的时候，将大的问题分解为多个子问题分 别描述和解决。UML提供了支持分治原则的语言成份，成组模型元素(grouping things)成组模型元素只有一类，即模型包(package)。模型包一个通用的手段用来组织多种语言成份，其中可包含：结构模型元素行为模型元素成组模型元素自身都可以置于模型包中。模型包是纯概念性的它只存在于

15、软件系统的开发阶段在UML模型图中，模型包被绘制 成文件夹的形状(下图)。模型包是UML的基本成组元素,它还有一些变体，如：框架(framework)函数在此返回一个标注的例子模型(model)一个模型包的例子子系统(subsystem)o(4)、注解元素注解大量存在于机械图和电子线路图中被用来标示产品的工艺要求，等等。在UML中，也存在着相似的语言成分，这就是：注解元素(annotation things)注解元素只有一种，即 标注(note)。标注用来描述施加于一个或多个模型元素的限制，或对模型元素的语义加以说明标注的图形表示：一个折了角的长方形(上图)在长方形中写标注的内容。标注的内容可

16、以是 形式的文本，或非形式的文本也可以是图形。(5)、关系结构模型元素是UML模型的静态组成部分静态组成部分不是孤立存在的它们被组合在一起互相协作以完成某项任务。 因此，结构模型元素之间存在着某种语义上的联系 在UML中，这种连系是关系 (relationship)UML中共有4种关系，它们是：依赖关系(dependency)关联关系(association)泛化关系(generalization)实现关系(realization)关联关系代表两个结构元素之间的某种语义上的连接它是所有的关系中语义最弱的一种。关联关系是双向的意味着被关联关系连接的两个模型元素的地位是相同的。如果两个结构模型元素

17、之间存在着关联关系，则它们之间可以互相访问。关联关系可以描述数据库记录之间的对应关系（下图）描述结构模型元素之间的部分和整体关系。结构模型元素之间的部分和整体关系是关联关系的一种, 又被称为聚合关系。*0.1+employer+employee关联关系依赖关系它代表一个结构模型元素的语义依赖于另一个结构模型元素的语 义。当被依赖的结构模型元素的语义部分地发生变化时，依赖元素的语义也会发生变化。可以用依赖关系描述的情形包括类之间的函数调用和变量引用图形表示（下图）虚线箭头依赖关系另外两类关系是泛化关系(图(a)描述基类和导出类之间的继承关系 实现关系(图(b)类之间的接口定义和实现的关系。>

18、;(a) 泛化关系>(b) 实现关系泛化关系和实现关系（6）、模型图UML是图示化的建模语言UML基本模型元素及其关系必须通过某种载体表示这种载体就是模型图（diagram）在UML中，模型图是一组 UML基本模型元素的图形表示 它通常由一组节点（UML基本模型元素），及节点之间的连线（关系）组成软件系统体系结构的 5个视图的内容，就是用模型图视化的一般地说，一个 UML基本模型元素既可以出现在所有的模型图中又可以出现在某些模型图中甚至可以不在任何一个模型图上出现但是，对不同的视图，其中的模型图通常只包含特定的UML基本模型元素及其关系的组合。由此便产生了 9种UML模型图。它们是：类图

19、 对象图 用例图 序列图 协同图状态图 活动图 组件 分布图类图包含类接口协同及其关系它用来描述逻辑视图的静态属性对象图包含对象及其关系它用来表示类图的类的对象在系统运行过程中某一时刻的状态对象也是软件系统的逻辑视图的一个组成部分组件图描述系统的物理实现包括构成软件系统的各部件（运行文件）的组织和关系，类图里的类在实现时最终会映射到组件图的某个组件一个组件可以实现多个类组件图是软件系统实现视图的组成部分 分布图描述系统的组件在运行时在运行节点上的分布一个节点可包含一个或多个组件分布图是软件系统分布视图的组成部分上述四种模型图主要用来描述软件系统的静态结构。描述软件系统的动态特性的，使用用例图序

20、列图协同图状态图活动图用例图描述系统的边界，和其上的动态行为图中包括：用例（use case系统作用者（actor）及其之间的（关联）关系用例图是用例视图的重要组成部分。序列图和协同图用来描述一组对象之间的动态交互。以用来描述系统的动态特性外部的动态特性内部的动态特性序列图和协同图包含对象消息序列图和协同图是用例视图和逻辑视图的重要组成部分序列图和协同图是交互图的两种不同的表现形式状态图和活动图用于描述对象的动态特性状态图强调对象对外部事件的响应及相应的状态变迁活动图描述对象之间控制流的转换和同步机制。(8)、UML建模规则UML的模型图不是 UML语言成份(UML成员)的简单堆砌 它必须按特

21、定的规则有机地组合而成从而构成一个 完备的UML模型图完备的 UML模型图(well-formed UML diagram )必须在语义上是一致的并且和一切和它相关的模型和谐地组合在一起。UML建模规则包括：名字：任何一个UML成员都必须包含一个名字作用域：UML成员所定义的内容起作用的上下文环境可见性：UML成员能被其它成员引用的方式完整性：UML成员之间互相联接的合法性和一致性。运行属性(execution):UML成员在运行时的特性。完备的UML模型必须对以上的内容给出完整的解释 当用于软件系统的建造时，UML模型是必须是完备的 但是当模型在不同的视图中出现时出于不同的交流侧重点其表达可

22、以是不完备的建模的原则在系统的开发过程中，模型可以：被省略即模型本身是完备的，但在图上某些属性被隐藏起来，以 减化表达。不完全在设计过程中某些元素可以暂时不存在。不一致在设计过程中暂不保证设计的完整性目的：鼓励开发者在设计模型时把注意力放在某一特定时期内对分析设计活动最重要的问题上，而暂不 迷恋于细节的完美，使模型逐步趋向完备。(9)、UML共用机制在模型图上对 UML成员进行描绘时，存在着共同的描绘方式，它们称为:UML共用机制 (UML common mechanism )使用这些共用机制，使得建模的过程易于掌握模型易于被理解共用机制可被分解为四个方面的内容：规格说明修饰公共划分扩充机制规格说明(specification )UML规则的省略性原则模型图省略某些对突出重点不重要的内容软件模型必须是完备的以便于软件系统的建造意味着此模型必须具备足够的详细信息以供软件建造之用。这些构成一个完备模 型的详细信 息就是 模型的规格说明 (specification )。所有UML模型元素都包含 规格说明在模型图上被省略的内容并不代表它也不存在于模型之中，模型的完整的或完备的信息是被保存在模型的规格说明中的， 而通常一个完备的模型全部内容是通过多个模型图表达出来 的。修饰UML模型图中的图符通常都有一个