软件开发学习笔记 <一> UML

UML

http://www.uml-diagrams.org

http://www.umlchina.com/index.htm

统一建模语言（UML）始于1997年的一个OMG（对象管理组织）标准，它是一种图形化、可视化的语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。

UML是一种建模语言，而不是一个开发过程。

UML统一了各种方法对不同类型的系统、不同开发阶段以及不同内部概念的不同观点，从而有效的消除了各种建模语言之间不必要的差异。它实际上是一种通用的建模语言。

UML的目标是以面向对象图的方式来描述任何类型的系统，具有很宽的应用领域。其中最常用的是建立软件系统的模型，但它同样可以用于描述非软件领域的系统，如机械系统、企业机构或业务过程，以及处理复杂数据的信息系统、具有实时要求的工业系统或工业过程等。总之，UML是一个通用的标准建模语言，可以对任何具有静态结构和动态行为的系统进行建模。

视图（View）

UML中的视图包括用例视图（Use Case View）、逻辑视图（Logical View）、实现视图（Implementation View）、进程视图（Process View）、部署视图（Deployment View），这5个视图被称作”4+1”视图。

每一个视图只关心系统的一个侧面，5个试图结合在一起才能反映系统的软件体系结构的全部内容。

4+1视图方法告诉我们【通过哪些视角、每个视角关注什么】，以此指导架构设计实践。

用例视图（Use-Case View）

从角色的视角来展示系统的功能。角色与系统进行交互，它可以是一个用户，也可以是另外一个系统。用例是对系统功能需求的概括描述，系统的使用被描述为用例视图中的多个用例。用例视图常常通过用例图进行描述，有时也需要活动图的辅助。用例视图在系统建模中处于中心地位，是其他视图的驱动因素。用例视图在系统需求分析时起着重要的作用，系统开发的最终目标就是要与用例视图中的描述相一致。

1.  问题系统是用例的集合，一般含有10~50个用例。

2.  需求 = 功能 + 质量 + 约束

用例是功能性需求实际上的标准，用例涉及、但不涵盖非功能性需求。

逻辑视图（Logical View）

用系统的静态结构和动态行为来展示系统内部的功能是如何实现的，其侧重点在于如何得到功能，这就要求逻辑视图能够剖析和展示系统的内部。系统的静态结构通过类图和对象图，而动态行为使用交互图和活动图进行描述。

逻辑视图指导逻辑架构设计，逻辑架构关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提供的“辅助功能模块”；它们可能是逻辑层、功能模块、类等。

实现视图（Implementation View）

展示代码的组织和执行，描述系统的主要功能模块和个模块之间的关系，主要被开发人员使用。

实现视图指导开发架构设计，开发架构关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。开发架构和逻辑架构之间可能存在一定的映射关系：比如逻辑架构中的逻辑层一般会映射到开发架构中的多个程序包；再比如开发架构中的源码文件可以包含逻辑架构中的一到多个类。

进程视图（Process View）

捕捉设计的并发和同步特征。展示与系统处理性能相关的主要元素，包括可伸缩性、吞吐量、基本时间性能。过程视图将系统划分为进程和处理器，通过这种方式来分析和设计系统如何有效利用资源、并行执行、处理来自外界的异步事件，除了要将系统划分为并发运行的线程以外，还要处理线程的通信和同步。进程视图包括动态图（状态机、交互图、活动图）和实现图（交互图和部署图）

进程视图指导运行架构设计，运行架构关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。运行架构和开发架构的关系：开发架构一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，运行架构比较关注的是这些运行时单元的交互问题。

部署视图（Deployment View）

利用节点来展示系统部署的物理架构。节点可以是电脑或者设备，将这些节点相互连接起来就可以分析和展示在物理架构中系统是如何部署的。

部署视图指导物理架构设计，物理架构关注“目标程序及其依赖的运行库和系统软件”最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理架构和运行架构的关系：运行架构特别关注目标程序的动态执行情况，而物理架构重视目标程序的静态位置问题；物理架构还要考虑软件系统和包括硬件在内的整个IT系统之间是如何相互影响的。

——————————————————

　　有了视图，我们可以每次把注意力集中在系统的一个方面，通过对多个视图的理解，我们在大脑中把不同方面的信息拼接起来，最终把握系统的全貌。

每个视图需要用一组图（diagram）来描述，图中包含的是代表系统模型元素的各种图形符号，不同的图体现出着系统的不同的方面。正如我们观察一个物体一样，从不同的角度看到的局部图像可能会出现重叠，不同的视图之间也可能出现重叠的状况，所以同一个图可以从属于不同的视图。

图（diagram）

（13种图）

静态视图

用例图

采用参与者和用例作为基本元素，以不同的视角展现系统的功能性需求。

业务用例视图

用业务主角和业务用例展现业务建模的结果。可能会有不同视角的版本。

      

（业务主角视角）                                                               （业务视角）

业务用例实现视图

展现业务用例有哪些实现途径。

概念用例视图

展现从业务用例中经过分析，分解出来的关键概念用例，并表示概念用例和业务用例之间的关系。这些关系一般有扩展、包含、精化。

系统用例视图

展现系统范围，将对业务用例进行分析得到的系统用例展现出来。一般系统用例视图以业务用例为单位来展现。表达了从系统需求到业务需求的映射，保证了过程的可追溯性。

系统用例实现视图

如果一个系统用例有多种实现方法，则应绘制实现视图。

类图

展现系统中类及其相互关系

概念层类图

着重对问题领域的概念化理解，类名通常是问题领域中实际事物的名称。对应业务建模阶段，用业务实体图表示。

（寄信）

说明层类图

对问题领域在接口层次抽象的描述，是现实世界与最终实现间的一座桥梁。对应概念模型阶段，用分析类和分析类型图表示。

实现层类图

明确采用的语言，设计模式，通信标准，遵循的规范等。直接映射可执行代码。可视为伪代码，甚至可以用工具直接生成可执行代码。

包图

一般用于展示高层次的观点。

　（领域包图）

（子系统包图）

（组织结构包图）

（层次包图）

对象图

组合结构图

（借书内部结构）

（ATM）

组件图

部署图

动态视图

动态视图无法独立存在，必须特指一个静态视图或UML元素，说明在规定的事物结构下它们的动态行为。

活动图

UML建模之活动图介绍（Activity Diagram）

关键元素：

起始点、结束点、活动（entry/do/event/exit四个特定事件）、分支、分叉、会合、基本流、支流、异常流、组合活动。

泳道：  由上述元素构建的活动图中描述了业务流程中活动的执行顺序，却没有描述出由谁来执行这些活动，即执行业务流程的职责被遗漏了。在面向过程的分析观点里，重要的是业务的执行过程，但在面向对象的分析观点中，业务的执行过程不是最重要的，对象职责才重要。因此在面向对象分析和设计中绘制活动图一定要添加泳道。

组合活动：

活动图主要目的是陈述活动与活动之间流程控制的转移。一般用于描述企业的本质性工作流程（Essential Workflow）。

活动是没有复用性的 为了能够清晰易懂地描述整个流程，为了避免一张图里包含太多信息，可以对其进行拆分。

活动图是描述用例场景最常用的图，因为它可以最方便地描述角色职责（每一个泳道对应一个角色）。

应用：

1. 业务场景建模：以业务主角（客户代表）为泳道，以从业务主角处获取的业务用例为活动来编排活动图。有助于发现及检查业务用例
2. 用例场景建模：以业务主角和业务工人为泳道，以工作单元作为活动来编排活动图以描述用例场景。有助于获取概念用例、角色、业务对象，建立领域模型。

领域模型：

对业务有着重要意义的业务对象。如果在同一个或多个用例场景的不同活动中某个名称重复出现，那么它很可能是一个关键的业务对象，这个业务对象在不同活动中的状态以及它与活动图中其他名词间的关系很可能就决定了业务的结构。绘制出这个结构就能获得领域模型。

活动图示例：

（对象交互泳道图）

（带角色职责的活动图）

状态图

UML建模之状态图（Statechart Diagram）

状态图显示一个状态机。用于对模型元素的动态行为进行建模，具体地说就是对系统行为中受事件驱动的方面进行建模。可以说明业务主角和业务实体可能的状态。状态图可以简化对类的设计的确认。

我们可以用状态机描述业务实体对象、分析类对象和设计类对象。通常只用于描述单个对象的行为，如果要描述对象间的交互，最好采用时序图或协作图。

关键元素：

初始状态（起始位置，不需要事件的触发）、状态（entry/do/event/exit四个特定事件）、复合状态、转移、事件、条件、最终状态。

（图书生命周期状态图）

活动图与状态图的比较

1. 活动和状态图标的版型很像，但还是不一样的

2. 活动图里一般有泳道

3. 活动图中活动间的 连线 表示流程控制权的转移，线上不会有文字；而状态图众状态间的 连线 表示引起状态改变的事件，每一条线上都有事件名称。

4. 活动图的判断会为每一个支流的连线上附上条件，而状态图的判别条件附在事件的后面[中括号中]，表示的是事件发生的条件。

5. 状态图里没有“分支”、“分叉”、“会合”这种表流程控制的元素。

时序图

UML建模之时序图（Sequence Diagram）

时序图用于描述按时间顺序排列的对象之间的交互模式，它按照参与交互的对象所具有的“生命线”和它们相互发送的消息来显示这些对象。在时序图中包含对象和主角实例，以及说明它们如何交互的消息。

时序图对我们确定对象职责和接口有着显著的作用。

因为类有三个层次：概念层、说明层、实现层。分别对应三个建模阶段，相应的时序图也有3个层次。

业务模型时序图：采用业务实体来绘制，其目标是实现业务用例。一般是先通过活动图发现业务实体，然后再绘制业务实体时序图。

概念模型时序图：采用分析类来绘制，目标是实现业务用例。但因为分析类本身代表了系统原型，这个阶段的时序图已经带有了计算机理解。

设计模型时序图：使用设计类为对象绘制，目标是显示概念模型中的某个事件流，一般以一个完整交互为单位，消息细致到方法级别。一般用于描述典型的交互场景。

（网上购买商品业务模型时序图）

（购买商品概念模型时序图片断）

（登录和查询事件流设计模型时序图片断）

协作图

时序图强调消息事件的发生顺序，更方便于阐述事件流的过程，适于获得对调用过程的理解，而难以表达表达对象之间的关系。而协作图可以直观地展现对象间的关系，更适于获得对对象结构的理解。二者是可以互相转换的。

（网上购买商品业务模型协作图）

（购买商品概念模型协作图片断）

（登录和查询事件流设计模型协作图片断）

交互纵览图

时间图

（打电话的时序图，带时间约束）

（利用时间图描述时间约束）

核心元素

版型 stereotype

UML中几乎每一个元模型都有很多版型。例如：用例有 "业务用例"、"业务用例实现"、“用例”等版型，类有"接口"、"边界类","实体类"、“控制类”等版型。甚至“参与者本身”也是类的一个特殊版型。而参与者又有参与者和业务主角等版型。

模型元素

包

常见的版型：

组件

组件是系统中可更换的部件，表达软件的一组功能。它符合一套接口标准并实现一组接口。组件之间的关系只有一种：依赖关系。

而按SOA架构的标准，一个组件应当是一个独立的业务模块，有着完备的功能，可独立部署，可以看成是一个完备的服务。一个SOA服务和其他服务是没有依赖关系的，服务与服务之间仅保持松耦合的通信关系。系统功能由一个个的服务向外部暴露。这些服务是松耦合的，它们之间通过企业总线按照标准的通信协议来交互完成业务功能。

节点

节点是至少带有一个处理器、内存，可能还带有其他设备的处理元素。一个服务器、工作站、客户机都可称为节点。

节点是应用程序的部署单元。节点元素特别用于部署视图，描述应用程序在屋里结构上是如何部署到应用环境中的。是一种包括软、硬件在内的拓扑结构描述。

参与者（actor）

信息来源提供者，第一驱动者。

对比：涉众、业务主角、业务工人、用户、角色。

可能存在的关系：继承、代理、实现

1. 业务主角之所以加上业务二字，是因为业务主角确实有区别于系统参与者，后者参与构建系统用例图，也就是通常所说用例图。前者参与构建业务用例图。
2. 业务工人不是参与者，它是和业务主角对比理解的，业务主角位于系统边界之外，而业务工人在系统边界之内，相当系统中的一枚螺丝钉，参与需求的实现。
3. 他们都源于涉众（stakeholder）,涉众是与要建设的这个系统有利益关系的一切人和事。
4. 用户是系统的直接使用者，他是参与者的代表（参与者的某个实例或者代理）。
5. 角色是参与者的职责，是一个抽象概念，一个用户可以拥有多个角色，多个用户也可以拥有某些相同的角色。

用例（use case）

一个用例就是与参与者交互，并给参与者提供可观测的有意义的结果的一系列活动的集合。

用例是功能性需求，也是抽象的角度。必须有参与者（动作的发起人），必需有动作的受体，必须有对参与者来说有意义可观察的结果。

一个用例就是一个独立的分析单元、设计单元、开发单元、测试单元、部署单元。一旦决定了用例，软件开发工作的其他活动都以这个用例为基础，围绕着它进行。也就是用例驱动开发。

• 业务用例抛开系统，真实地反映参与者在现实世界的行为。准确而完备地描述客户的现存或预想业务。
• 用例（系统用例）描述的是系统要实现的那部分功能。它的粒度一般会更小。
• 概念用例用于精化业务用例，使系统用例的分析更容易些。
• 用例实现是用例的一个实例，如汇款是一个用例，则线下银行汇款和网上银行汇款就是两种用例实现。

业务实体

是类的一种版型，用于业务建模阶段绘制类图或建立领域模型。作为类的版型，具有对象的所有特征，包括属性和方法及对象的独立性。

业务实体至少被一个业务用例场景使用或创建，对业务用例场景没有贡献的事物是没必要建模的。

分析类

分析类用于概念建模或系统建模阶段

边界类 -> 操作界面或系统接口

　　控制类 -> 计算程序或控制程序，如工作流、算法体等

实体类 -> 数据库表、Xml文档或其他带持久化特征的类

类、对象

用于设计实现阶段，会涉及具体到程序语言。

类用带有类名、属性和操作的矩形框来表示。

对象是类的实例，其名字有下划线。

接口

接口描述了一个类或组(构)件的一个服务操作集，亦即定义了元素的外部可见行为。

接口定义的是一组操作的描述，而不是操作的实现。

在图形上，接口用一端带有小圆圈的直线来表示，它通常依附在实现接口的类或组(构)件之上。

注解、状态、活动

关系

关联关系

描述不同类的对象之间的一种静态的强关联关系。用一条直线表示（A、B互相知道对方的存在），有时会带箭头（A知道B,B不知道A），

关联除可以具有方向外，也可以带有多重性标注和角色名这类修饰符。

    

    

依赖关系

描述对象之间的依赖关系。依赖关系是一种临时的关系，通常在运行期产生。用带箭头的虚线表示

泛化（继承）关系

一条带空心箭头的直线，表类继承

实现关系

一条带空心箭头的虚线

实现是泛化关系和依赖关系的结合，通常在接口和实现它们的类或组(构)件之间用到这种关系。

用在用例模型中，表示基本用例的一种实现。

包含关系

一条带箭头的虚线 + 版型<<include>> ，用在概念用例模型中，表用例的分解、重用。

扩展关系

一条带箭头的虚线 + 版型<<extend>> ，用在概念用例模型中，表用例的功能扩展：某个支流，某个可选的系统功能。

包含(include)、扩展(extend)、泛化(Inheritance) 的区别

1. extend中的延伸用例表示的是某个支流，某个可选功能。用例的发生一般是有条件的。延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内容。
2. include中被包含的用例为参与者提供间接服务 ，而泛化和扩展提供直接的服务。因为包含的目的往往是为了分解、重用。
3. 对Inheritance而言，子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系。

精化关系

一条带箭头的虚线 + 版型<<refine>>，表一个基本用例可以分解成许多更小的精化用例。更细致地表示基本用例的核心业务。也可以用于模型之间或对象之间。

聚合关系

带空心菱形箭头的直线，聚合是一种特殊的关联，它描述了整体和部分之间的结构关系。指明一种类型的对象是另一种类型的对象的一部分。

组合关系

带实心菱形箭头的直线，一种强关联关系，它所描述的“部分”对象是依赖于“整体”对象的。组合是一种特殊的聚合关系，当整体不存在时，部分也随之消亡。

多重性关联

表示方式	多重性说明
1..1	表示另一个类的一个对象只与该类的一个对象有关系
0..*	表示另一个类的一个对象与该类的零个或多个对象有关系
1..*	表示另一个类的一个对象与该类的一个或多个对象有关系
0..1	表示另一个类的一个对象没有或只与该类的一个对象有关系
m..n	表示另一个类的一个对象与该类最少m，最多n个对象有关系 (m≤n)

类图中的关系示例

补充知识

UML的体系结构

UML的模型结构

根据UML语义，UML的模型结构可分为四个抽象层次；下一层是上一层的基础，上一层是下一层的实例。

元元模型示例

元元模型是组成UML的最基本事物，代表要定义的所有事物，如一些元类、元属性、元操作等概念。

元元模型示例是一个“元类”的元元模型描述，其中事物概念可代表任何定义的东西。

概念

元模型：

元模型是关于模型的模型。这是特定领域的模型，定义概念并提供用于创建该领域中的模型的构建元素。

MOF：

OMG提出的MOF（Meta Object Facility）是一个标准。为了描述某一特定的模型，需要描述组成该类模型的建模结构集，MOF能对建模结构进行描述。MOF的4层元建模架构提供一组建模元素以及使用这些元素的规则。

四层元模型：

四层元模型是OMG组织指定的UML的语言体系结构。这种体系结构是精确定义一个复杂模型语义的基础。除此之外，该体系结构具有，通过递归地将语义应用到不同层次上，完成语义结构的定义，为UML的元模型扩展提供体系结构基础，为UML元模型实现与其他的基于四层元模型体系结构的标准相结合提供体系结构基础。

每一层描述如下：

1．信息层（information layer）

　　信息是由我们希望描述的数据组成，这些数据通常是一些用户数据(user data)，主要职责是描述信息领域中的详细信息。

2．模型层（model layer）

　　模型层是由元数据组成，元数据是描述信息层的数据，元数据的集合被称作为模型。

　　模型层的主要职责是为描述信息层而定义的一种“抽象语言”(即没有具体语法或符号的语言)。信息层的数据，即用户数据，是模型层的一个实例。

3．元模型层（metamodel layer）

　　元模型层是由元一元数据组成，元一元数据定义了元数据的结构和语义，元一元数据的集合被称作为元模型。元模型层的主要职责是为了描述模型层而定义的一种“抽象语言”，是对模型层的进一步抽象。也就是说，模型层描述的内容通常要比元模型层描述的内容丰富、详细。一个模型是元模型的一个实例。数据词典中的元数据是对数据模型的描述。

4．元元模型层（meta-metamodel layer）

　　元元模型层是由元元数据的结构和语义的描述组成，这层的主要职责是为了描述元模型而定义的一种“抽象语言”。元元模型的定义要比元模型更加抽象、简洁。一个元元模型可以定义多个元模型，而每个元模型也可以与多个元元模型相关联。通常所说的相关联的元模型和元元模型共享同一个设计原理和构造，这也不是绝对的准则。每一层都需要维护自己设计的完整性。一个元模型是元元模型的一个实例。

UML建模规则

UML模型图按特定的规则有机地组成。

一个完备的UML模型图必须在语义上是一致的，并且和一切与它相关的模型和谐地组合在一起。

UML建模规则的内容

①名字：任何一个UML成员都必须包含一个名字。

②作用域：UML成员所定义的内容起作用的上下文环境。某个成员在每个实例中代表一个值，还是代表这个类元的所有实例的一个共享值，由上下文决定。

③可见性：UML成员能被其他成员引用的方式。

④完整性：UML成员间互相连接的合法性和一致性。

⑤运行属性：UML成员在运行时的特性。

UML建模的原则

在系统的开发过程中，模型可以：

①被省略：即模型本身是完备的，但在图上某些属性被隐藏起来，以简化表达；

②不完全：即在设计过程中某些元素可以暂时不存在；

③不一致：即在设计过程中暂时不保证设计的完整性。

UML公用机制

规约

在UML中，每个模型元素的图形表示法之后都存在一个规约(规范说明 )，它以文字的形式描述基本模型元素的语法和语义。

UML的图形表示法可视化地描述系统，而UML的规约则用来描述系统的细节。

Rup文档模版

修饰

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

1 . 在UML众多的修饰符中，注释是一种最重要的并且能单独存在的修饰符，它是附加在模型元素或元素集上用来表示约束或注解 信息的图形符号。

2.  类的图形符号

1. 用斜体类名表示它是抽象类。
2. 用+表示public，用-表示private,用#表示protected。
3. 上图的Member是内部类
4. 属性的表示方式 ： 可见性 名称:类型 [ = 缺省值 ]
5. 操作的表示方式： 可见性 名称(参数列表) [ : 返回类型]

通用划分

类/对象二分法

对象和类使用同样的图形符号。类用长方形表示，并用名字加以标识，当类的名字带有下划线时，则它代表该类的一个对象。

接口/实现二分法

接口定义一种协议，实现是此协议的实施。UML里这样的接口与实现的两分划分包括接口/类或组件、用例和协同，以及操作和方法。

扩展机制

⑴衍型(构造型)：对UML的词汇的扩展，用于创建与已有的模型元素相似且针对特定问题的新种类的模型元素。用书名号括起来的名字表示，其位置在其他元素之上。

⑵标记值：对UML元素的特性的扩展，用于在模型元素的规约中创建新的信息。用花括号括起来的字符串表示，其位置在其他元素之下。

⑶约束：对UML元素的语义的扩展，用于增加新规则或修改已有规则。用花括号括起来的字符串表示，且放在所关联的元素附近或通过依赖关系连接相应元素。

博文收集

UML实践详细经典教程----用例图、顺序图、状态图、类图、包图、协作图

UML序列图总结