一、UML是什么?
UML,全称为Unified Model Language,即统一建模语言。目的是直观地表示系统及其主要参与者、角色、动作、工件或类,以便更好地理解、维护或记录信息关于系统。它独立于任何具体的编程语言,旨在支持软件开发的全过程,包括需求分析、设计、实现和测试。
UML 是一种现代的软件建模和文档化方法。它是最流行的业务流程建模技术之一。它基于软件组件的图形表示。通过使用图形表示,我们能够更好地理解软件或业务流程中可能存在的缺陷或错误。
二、UML组成
2.1UML语言组成
- 基本图素:构成UML模型图的基本元素。例如类、对象、包、接口、组件等。
- 模型图:由UML基本图素按照UML建模规则构成。例如用例图、类图、对象图、…等。
- 建模规则:UML模型图必须按特定的规则有机地组合而成,从而构成一个有机的、完整的 UML模型图。
UML = UML成员 + UML建模规则
- UML建模规则:相当于建模语言的语法。
- UML成员(building blocks of the UML):它是UML的基本组成部分。
2.2UML成员
UML成员 = UML基本模型元素 + 关系 + 模型图
- UML 基本模型元素(things in UML)
- 关系(relationship)
- 模型图(diagram)
2.2.1UML基本模型元素
UML基本模型元素,类似于电子产品电原理图里的集成电路符号,是模型图上基本符号。
UML基本模型元素 = 结构模型元素 + 行为模型元素 + 分组元素 + 注解元素
基本模型元素可分为4类:
- 结构模型元素(structural things),是UML模型里的名词,是模型的静态组成部分,代理软件系统的概念或物理存。包括类、接口、协作、用例、活动、组件、节点。
- 行为模型元素(behavioral things),是UML模型的动态组成部分,它是模型的动词,代表软件系统在空间和时间上的行为。包括交互、状态两种。
- 分组模型元素(grouping things),是UML模型中组织的部分,可以把它看成盒子。只有一种分组方式:包。包是一种将有组织的元素分组的机制。
- 注解元素(annotational things),是UML模型的解释部分。
2.2.2关系
结构模型元素是UML模型的静态组成部分,静态组成部分不是孤立存在的,它们被组合在一起互相协作以完成某项任务。因此,结构模型元素之间存在着某种语义上的联系。在UML中,这种联系是关系(relationship),有以下4种关系:
-
关联(association)
-
依赖(dependency)
-
泛化/继承(generalization)
-
实现(realization)
- 聚合(Aggregation)
- 组合(Composition)
2.1.3模型图
UML基本模型元素及其关系必须通过某种载体表示,这种载体就是模型图(diagram)
在UML中,模型图是一组UML基本模型元素的图形表示,它通常由一组节点(UML基本模型元素), 及节点之间的连线(关系)组成。
软件系统体系结构的5个视图的内容就是用模型图来表达的。
一般地说,一个UML基本模型元素既可以出现在所有的模型图中,又可以出现在某些模型图中,甚至可以不在任何一个模型图上出现。
常用的UML模型图主要有:
- 用例图(use case diagram),展示系统的功能需求和用户与系统之间的交互。
- 交互图,交互图描述了系统中不同对象之间的交互,以及消息传递的顺序和方式。着重于显示对象之间的通信和协作,用于捕获系统中对象之间的动态交互。
- 活动图(activity diagram),描述系统中各个活动之间的流程和控制流。
- 序列图(sequence diagram),展示对象之间的消息交互顺序。
- 交互概览图(Interaction Overview Diagram),是一系列事件的模型,可用于将复杂的交互分解为更简单的事件。它是活动和序列图之间的交叉。
- 状态图(state diagram),表示系统中对象的状态及状态之间的转换。
- 通信图(Collaboration Diagram),描述对象之间的协作关系。
- 类图(class diagram),描述系统中的类、接口、关联、继承等。
- 对象图(object diagram),展示系统中具体对象的实例及其之间的关系。
- 组件图(component diagram),显示系统中的组件及其之间的依赖关系。
- 部署图(deployment diagram),描述系统的物理部署结构。
- 包图(package diagram),描述系统中的各个包(或命名空间)之间的关系和依赖。
三、软件体系结构分层
为了表达不同的软件开发相关人员在软件开发周期的不同时期关注软件产品的不同侧重面, 需要对模型进行分层。
UML根据软件产品的体系结构对软件进行分层。软件的体系结构分解为五个不同的侧面,称为4+1视图。每个视图分别关注软件开发的某一面,每一个视图由一种或多种模型图构成,而每个模型图又描述了构成相应视图的基本模型元素及它们之间的相互关系。这5种视图分别为:
- 用例视图(Use case view,Scenarios),场景视角;
- 逻辑(设计)视图(Logical view) , 逻辑视角;
- 进程(过程)视图(Process view) ,过程视角;
- 实现(开发)视图(Implementation view) ,开发视角;
- 部署(物理、配置)视图(Deployment view) ,物理视角;
3.1用例视图(Use case view)
主要从用户场景的角度来描述系统功能,由最终用户、分析人员、设计人员和测试人员看到的系统行为的用例图组成。最终用户,理解系统功能,确认是否符合自己的要求;分析人员,描述用户需求,与用户设计人员交流;测试人员,验证实现后的系统功能是否符合用户需求。
常用的模型图有:用例图、活动图、状态图、序列图、协作图。
3.2逻辑视图(Logical view)
主要从软件的角度描述系统要解决的问题以及解决方案,它是实现视图的基础。逻辑视图主要包括设计包、子系统、类和接口。
常用的模型图有类图、对象图、交互图、状态图、活动图。
3.3进程视图(Process view)
过程视图用来对系统的性能、可扩展展性、吞吐量、系统中对象间的同步与通信进行描述。它解决并发性、分布性、系统完整性、容错性的问题,以及逻辑视图的主要抽象如何与进程视图相配合在一起,即控制在哪个线程上实际执行对象的操作。进程视图主要包括系统并发和同步机制的线程和进程。
常用的模型图有:
3.4实现视图(Implementation view)
开发人员根据逻辑视图和进程视图来组织与管理软件模块,并实现系统。它通过系统输入输出关系的模型图和子系统图来描述。也要考虑软件的内部需求:开发的难易程度、重用的可能性,通用性,局限性等等。开发视图的风格通常是层次结构,层次越低,通用性越好。
常用的模型图有:部件图、状态图、活动图。
3.5部署视图(Deployment view)
部署视图用来描述软件产品在计算机硬件系统和网络上的安装、分发(delivery)、分布(distribution)。描述物理系统的拓扑结构、系统安装、通信等问题,考虑如何把软件映射到硬件上,同时也要考虑系统性能、规模、可靠性等。可以与进程视图一起映射。
常用的模型图有:交互图、状态图、活动图。