文章目录
1 统一建模语言
1.1 模型、建模与统一建模语言
模型是现实的简化，它提供了系统的蓝图。一个好的模型具有典型特征的元素并省略了与给定抽象级别无关的次要元素。其中：
1、结构性模型强调系统组织性。
2、行为性模型强调系统动态性。
建立模型(即建模)是为了更好地理解当前正在开发的系统：
1、模型帮助开发人员去构想一个系统的本来面目或客户想要的样子；
2、模型允许客户指定系统的结构或行为；
3、模型给开发人员一个模板，并指导其构建一个系统；
4、模型记录了开发人员所做的决定。
建立系统模型是因为有时候开发人员不能完全理解这样一个系统，即系统具有一定的复杂性。
UML，Unified Modeling Language，即统一建模语言。
UML是编写软件蓝图的标准语言，用来可视化、指定、构建和记录软件密集型系统的构件。需要注意的是：
1、UML不是一种可视化的程序设计语言，而是一种可视化的建模语言；
2、UML不是工具或知识库的规格说明，而是一种建模语言规格说明，并且UML也是一种表示的标准；
3、UML不是过程也不是方法，但允许任何一个过程和方法使用它。
UML可以描述软件开发所需的各种视图，包括：
1、概念视图：描述业务过程和系统功能；
2、具体视图：描述程序中的类、数据库模式、可重用的软件构件。
UML的4大特点：
1、可视化(visualizing)。UML提供一组具有明确语义的图形符号，可以建立清晰的模型，所有开发人员都可以无歧义地解释这个模型。UML代替了传统的“边想边写”的开发方式。
2、详细描述的(specifying)。意味着建立精确、无歧义的模型。UML为所有重要的分析、设计和实现决策提供了精确的、无歧义、完整的描述。
3、构造的(constructing)。UML不是一种可视化的编程语言，但它所描述的模型可以映射成不同的编程语言，如Java、C++等。其中：
(1)正向工程：从UML模型到编程语言的代码生成；
(2)逆向工程：从编程语言代码重新构造UML模型。
4、文档化(documenting)。UML可以建立系统体系结构及其详细文档，同时提供了描述需求和用于测试的语言，还可以对项目计划和发布管理的活动进行建模。
1.2 基本构造块
UML的基本构造块有三种：
1、事物(things)：是模型中的一类实体，是对模型中首要成分的抽象；
2、关系(relationships)：把事物结合在一起；
3、图(diagrams)：聚集了相关的事物，是事物的集合。
1.2.1 事物
有四种事物：结构事物、行为事物、分组事物、注释事物。其中：
1、结构事物。结构事物是UML中的名词，通常是模型的静态部分，一般描述的是概念元素或物理元素，包括类、接口、协作、用例、主动类、构件、制品、结点等，总称为类目(classifier)。其中：
(1)类。包括类名、属性、操作。如：
(2)接口。接口(interface)描述了一个类或构件的服务(操作)集，描述了一个元素的外部可见行为，定义了一组服务约定，而不是服务的实现，接口很少单独出现。符号表示的示例如下：
(3)协作。协作(collaboration)定义了一个交互，由一组共同工作以提供某种协作行为的角色和其它元素构成一个群体。协作行为大于所有元素的各自行为的总和。符号表示如下：
(4)用例。用例(use case)描述一组动作序列。系统执行这些动作将产生对特定的参与者有价值的、并且可以观察的结果。符号表示如下：
(5)主动类。主动类(active class)是特殊的类，该类的对象至少拥有一个进程或线程，能够启动控制活动，主动类的对象所表现的元素的行为与其他元素的行为并发。符号表示的示例如下：
(6)构件。构件(component)是系统设计的模块化部件，将实现隐藏在一组外部接口之后。在一个系统中，共享相同接口的构件可以相互替换，只要保持相同的逻辑行为即可，可以通过连接器组复合构件。符号表示如下：
(7)制品。制品(artifact)是系统中物理的而且可代替的部分，如源代码文件、可执行程序、脚本，通常代表对源码信息或运行时的物理信息进行打包。符号表示的示例如下：
(8)结点。结点(node)是指系统运行时存在的物理元素，表示一个计算机资源，该资源通常来说至少具备一些存储和运算功能。构件可驻留在一个结点内，也可以从一个结点迁移到另一个结点中去。符号表示的示例如下：
2、行为事物。行为事物是UML模型中的动态部分，是模型中的动词，代表了跨越时间和空间的行为。有3类主要的行为事物：交互、状态机、活动。其中：
(1)交互。交互(interaction)是一种行为，由特定语境中共同完成一定任务的一组对象或角色之间交换的消息组成，可表示一组对象的行为，也可表示单个操作的行为。符号表示的示例如下：
(2)状态机。状态机(state machine)是一种行为，描述了一个对象或一个交互在生命周期内响应事件所经历的状态序列以及对这些事件的响应。单个类或一组类之间的协作可以用一个状态机来描述。状态机涉及到一些其它元素，包括状态、迁移、事件和活动。符号表示的示例如下：
(3)活动。活动(activity)是一种描述计算过程执行的步骤序列，表示步骤之间的流程顺序，一个步骤称为一个动作，活动和状态在不同的语境中有所区别。符号表示的示例如下：
3、分组事物。包括各种包(package)，是对设计本身进行组织的通用机制。结构事物、行为事物甚至其它的分组事物都可以放进包内。与构件不同，构件是运行时存在，而包是概念上的，即在开发时存在。符号表示的示例如下：
4、注释事物。注释事物用来描述、说明和标注模型的任何元素，即注解(note)，是依附于一个元素或一组元素之上对其进行约束或解释的简单符号，应把注释表示成形式化或非形式化的文本。符号表示的示例如下：
1.2.2 关系
有四种关系，分别为依赖关系、关联关系、泛化关系、实现关系。其中：
1、依赖关系。依赖是两个模型元素间的语义关系，其中一个元素(独立元素)发生变化会影响另一个元素(依赖元素)的语义。符号表示如下：
2、关联关系。关联是类之间的结构关系，两个类之间存在某种语义关系。关联有重数、方向等的修饰。聚合和组合是特殊的关联。符号表示的示例如下：
3、泛化关系。泛化是一种表示特殊与一般的关系，特殊元素(子元素)基于一般元素(父元素)而建立，子元素拥有父元素的结构和行为。符号表示如下：
举个泛化的例子：
4、实现关系。实现是类目之间的语义关系，其中的一个类目指定了由另一个类目保证执行的合约。在以下2种情况下会有实现关系：
(1)接口和实现接口的类或构件之间；
(2)用例和实现用例的协作之间。
实现关系的符号表示如下：
1.2.3 图
图是一组元素的图形表示，大多数情况下把图画成顶点(代表事物)和弧(代表关系)的连通图。可以从不同的角度画图，以反映系统的不同侧面。理论上，图可以包含事物及其关系的任何组合，然而现实却并非如此。共有13种图：
将按照上图中的标号顺序对13种图进行简单的介绍(不会细讲)。
1.2.3.1 类图
类图展现了一组类、接口、协作及它们之间的关系，它是OO系统建模中最常见的图，类图给出了系统的静态设计视图，它包含主动类的类图，需要给出系统的静态进程视图。构件图是类图的变体。下面是一个示例：
1.2.3.2 对象图
对象图展现一组对象以及它们之间的关系，描述了在类图中所建立的事物的实例的静态快照。与类图一致，对象图会给出系统的静态设计视图或静态进程视图。对象图显示某时刻对象和对象之间的关系。一个对象图可看成一个类图的特殊用例，实例和类可在其中显示。对象图是类图的实例，几乎使用与类图完全相同的标识，不同点在于对象图显示类的多个对象实例，而不是实际的类。由于对象存在生命周期，因此对象图只能在系统某一时间段存在。对象图显示由对象构成的集合及其联系，代表了系统某时刻的状态，不能表示系统的演化过程。下面是一个示例：
关于对象图，有：
- 对象图可以捕获实例和连接；
- 在分析和设计阶段创建对象图；
- 对象图可以捕获交互的静态部分；
- 对象图说明了数据和对象的结构。
1.2.3.3 构件图
构件图描述了软件的各种构件和它们之间的依赖关系，通常包含3个元素：构件(component)、接口(interface)、依赖关系(dependency)。
构件图展现了一个封装好的类和它的接口、端口以及由内嵌的构件和连接构成的内部结构(可重用的构件及其接口)，用于表示系统的静态设计实现视图，尤其适用于由小的部件构建而成的大系统。下面是一个示例：
构件与类的比较：
- 相同点：两者都有名称；都可以实现一组接口；都可以参与依赖关系；都可以被嵌套；都可以有实例；都可以参与交互；
- 不同点：(1)类描述了软件设计的逻辑组织和意图；构件描述了软件设计的物理实现，即每个构件体现了系统设计中特定类的实现。(2)类可以有属性和操作；构件只有操作，且只有通过构件的接口才能使用操作。
在对软件系统建模的过程中，存在3种类型的构件：
- 配置构件(Deployment component)，如dll、exe、com等文件；
- 工作产品构件(work product component)，如源代码、数据文件等；
- 执行构件(execution component)，系统执行后得到的构件。
1.2.3.4 部署图
部署图展现了系统运行时的结点以及结点内部构件的配置，描述体系结构的静态部署视图。部署图显示了软件及硬件的配置。如下是房地产事务有关的软件及硬件构件的部署图：
1.2.3.5 复合结构图
复合结构图显示对象在聚合或组合中的相互关系，显示接口和协作的对象，常与部署图一起使用。
1.2.3.6 包图
包图描述了由模型本身分解而成的组织单元及它们的依赖关系，说明了相关联的类如何组合。包图是一种把建模元素组织成组的通用机制，通常将一些在语义上接近并倾向于一起变化的元素组织在一个包中，包与其内的元素具有组成关系，并且一个元素只能在一个包中。用于：
- 产生一个大模型元素集的概要视图；
- 组织一个大模型；
- 将相关的元素组织在一起。
下面是包图的一个示例：
1.2.3.7 用例图
用例图展现了一组用例、参与者及它们之间的关系，用例图给出的是系统的静态用例视图，对系统行为的组织和建模非常重要。下面是一个示例：
1.2.3.8 状态图
状态图展现了对象的动态视图，多用于建模接口、类或协作。对象拥有行为和状态，对象的状态是由对象当前的行动和条件决定的。状态图显示对象可能的状态以及由状态改变而导致的转移。下面是一个示例：
1.2.3.9 活动图
活动图将进程及其他计算结构展示为一步步的控制流和数据流，活动图专注于系统的动态视图，多用于建模系统功能，并强调对象间的控制流程。活动图集中在一个单独过程的动作流程，展现了活动之间的依赖关系。与状态图的区别在于，状态图把焦点集中在过程的对象身上。
1.2.3.10 顺序图
顺序图是强调消息的时间次序的交互图，将交互关系表示为一个二维图，其中：
- 纵轴是时间轴，时间沿竖线向下延伸。
- 横轴代表在协作中各独立对象的类元角色。类元角色用生命线表示，当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线。
- 消息使用从一个对象的生命线到另一个对象生命线的箭头来表示，箭头按时间顺序在图中从上到下排列。
下面是顺序图的一个示例：
1.2.3.11 通信图
通信图强调收发消息的对象或角色的结构组织，强调消息流经的数据结构，在某种情形下是对象之间发送的消息。下面是通信图的一个示例：
1.2.3.12 定时图
定时图展现了消息交换的实际时间，描述了消息跨越不同对象或角色的实际时间。下面是一个示例：
1.2.3.13 交互概览图
交互概览图是活动图和顺序图的混合物。
1.3 语义规则
UML描述了一个结构良好的模型应该如何组织在一起。UML的语法和语义规则用于：
1、命名：为事物、关系和图命名；
2、范围：使名字具有特定含义的语境；
3、可见性：这些名字如何让其他成分看见和使用；
4、完整性：事物如何正确、一致地相互联系；
5、执行：运行或模拟动态模型的含义是什么。
1.4 公共机制
UML中的公共机制使UML具备一定的风格且易于理解。包括以下4种机制：
1、详述。每一个UML图形的每个部分背后都有一个详述，它提供了对构造块的语言和语义的文字叙述，如类图提供了对该类所有的属性、操作和行为的全面描述。详述用来说明系统的细节，如用例和用例描述。
2、修饰。修饰有时可算作详述的一部分，是对UML中元素的进一步说明，目的是增加其可视化效果。
3、通用划分。常见的两种通用划分为：
- 类与对象的划分，如下面的左图：构件与构件实例、结点和结点实例。
- 接口与实现的分离，如下面的右图：用例与实现它们的协作。
4、扩展机制。有三种扩展机制：
- 衍型(Stereotype)，扩展了UML的词汇。
- 标记值(tagged value)，用于创建衍型的详述的新信息。
- 约束(constraint)，扩展了UML构造块的语义，可增加新的规则或修改现有的规则。
2 绘图原则
2.1 可读性准则
1、避免交叉线，将交叉表示为跃过或避开。如下：
2、避免使用对角线或曲线，使用大小格式统一的符号。如下：
3、布局对称。如下：
4、建议图表上有六个或更少的气泡。
5、图中应留有适当的空白，保证有足够的空间给线条添加标签。
6、绘图时应按从左往右，从上往下的顺序绘制。
7、避免过多的闭合线。
8、提供图例。如果不确定查看模型的所有用户是否都理解所使用的符号，请为其提供一个概述该符号的图例。一个好的图例表明了所使用的符号、符号的名称及其描述用法。
2.2 简单准则
1、内容精练，只展示所描述的关键特征。
2、优先选用通俗易懂的符号。
3、图的规模大小适中，有一个好的经验法则：7±2法则，即图表上的符号不应该超过9个。
4、图尽可能安排在一页。
5、内容第一，外观第二。
6、风格必须统一。
2.3 命名准则
1、沿用命名惯例。
2、使用通用的领域术语命名。
3、设计图中尽量利用将要使用的编程语言的命名惯例。
4、不同图中同一元素的命名应保持一致。
2.4 通用准则
1、适当使用问号？。如下：
2、巧用着色。一张图表中使用的颜色不应该超过六种，一般使用浅色，并且使用鲜艳的颜色时是为了强调某些事物。
3、慎重选择不同的字体。
2.5 几个示例
下面是示例1：
下面是示例2：
下面是示例3：
下面是示例4：
END
