转载:https://www.cnblogs.com/xinaixia/p/4424443.html
统一建模语言(Unified Modeling Language,UML)中各种视图并没有明显的概念区别。
在最上一层,视图被划分为三个视图域:结构,动态行为,模型管理。
结构主要描述了系统中的结构成员及其相互关系。结构元素包括类,用例,构件和节点。结构元素为研究系统的动态行为奠定了基础。结构视图包括静态视图,用例视图和实现视图。
动态行为描述了系统随时间变化的行为。行为用从静态视图中抽取出来的系统的瞬间值变化来描述。动态行为视图包括状态机视图,活动视图和交互视图。
模型管理说明了模型的分层组织结构。包是模型的基本组织单元。特殊的包还包括模型和子系统。模型管理视图跨越了其他视图并根据系统的开发和配置组织这些视图。
UML还有多种具有扩展能力的组件,这些扩展能力有限但很有用。这些组件包括约束,构造型和标记值,适用所有的视图元素。
UML的视图表,如下:
主要域 | 视图 | 图 | 主要概念 |
结构 | 静态视图 | 类图 | 类、关联、泛化、依赖关系、实现、接口 |
用例视图 | 用例图 | 用例、参与者、关联、扩展、包括、用例泛化 | |
实现视图 | 构件图 | 构件、接口、依赖关系、实现 | |
部署视图 | 部署图 | 节点、构件、依赖关系、位置 | |
动态 | 状态机视图 | 状态机图 | 状态、事件、转换、动作 |
活动视图 | 活动图 | 状态、活动、完成转换、分叉、结合 | |
交互图 | 顺序图 | 交互、对象、消息、激活 | |
协作图 | 协作、交互、协作角色、消息 | ||
模型管理 | 模型管理视图 | 类图 | 包、子系统、模型 |
可扩展性 | 所有 | 所有 | 约束、构造型、标记值 |
一、静态视图
它对应用领域中的概念和系统实现有关的内部概念建模。它因为不描述与时间有关的系统行为被称作静态视图。静态视图主要由类以及类之间的相互关系组成,这些关系包括:关联,泛化和各种依赖关系,如何使用和实现关系。类是应用领域或应用解决方案中概念的描述。类图是以类为中心组织的,类图中的其他元素或属于某个类或与类相关联。静态视图用类图来实现,正因为他以类为中心,所以称其为类图。下面是个类图的例子:
私下里觉得这张图很复杂,尤其是不知道这张图是用来干什么的时候!
二:用例视图
用例视图被称为参与者的外部用户所能观察到的系统功能模型图。用例是系统中的一个功能单元,可以描述为参与者与系统之间的一次交互。用例模型的用途是列出系统的用例和参与者,并显示了哪个参与者参与了哪个用例的执行。下面是个用例视图的例子:
个人观点,这个图很傻,不过还是很有意思的,最起码能够显示正常开发中各个参与者的活动情况。
三:交互视图
交互视图描述了执行系统功能的各个角色之间相互传递信息的顺序关系。交互视图显示跨越了多个对象的系统控制流程。交互视图可用两种视图来表示:顺序图和协作图,它们各有不同的侧重点。
1:顺序图
顺序图描述的是一个事务的流程,这个流程和面向过程编程中的顺序结构是一样的,从上到下。下面是一个图例:
这个图让我想起很久很久以前没有ajax时候的网络服务,就是一直用同步的方式操作,不堪回首!
2:协作图
协作图是对在一次交互中有意义的对象和对象间的链建模,对象和关系只有在交互的语境中才有意义。协作图用几何排列来表示交互作用中的各角色。附在类元角色上的箭头表示消息,消息的发生顺序用编号数字表示。下面是一个协作图图例:
这个图有个特点,与顺序图不一样,它展示了参数,方法名称,不是基于时间序列,是基于逻辑序列。
四:状态机视图
状态机视图是一个类对象可能经历的的所有历程的模型图。状态机由对象的各个状态和连接这些状态的转换组成。每个状态对一个对象在其生命周期中满足某种条件的一段时间段建模。当一个事件发生时触发状态的转换,从一个状态转化为另一个状态。下面是一个图例:
这个状态机我认为最好参考一下设计模式里面的状态模式,状态模式的实现就是这个状态图的代码描述。
五:活动视图
活动视图是状态机的一种变体,用来描述执行算法的工作流程中涉及到的活动。活动状态代表了一个活动:一个工作流执行步骤或一个操作的执行。活动图描述了一组顺序的或并发的活动。活动视图用活动来体现。下面是一个图例:
这个与状态机还是有很大的变化的,它是一个线性的执行步骤,状态机是一种环形触发的情况。状态机是每种情况很复杂,有一定触发状态存在于其中。活动图可能没有这些,但是符合现实的工作流程。
六:物理视图
物理视图对应自身的结构实现建模,图中的类将会映射称为物理结构中的节点。物理视图分为实现视图和部署视图。实现视图为系统中的构件建模,以及构件之间的依赖关系,通过对依赖关系修改评估对系统可能带来的影响。下面是一个实现视图的图例:
这个图很有意思吧,刚开始我还以为是电路板之类的图呢。接下来是一个部署图,仔细找找区别:
六:模型管理视图
它是对模型自身组织的建模。模型是从某一观点以一定精确度对系统所进行的完整性描述。下面是一个图例:
这样的系统图看着非常的不错,很容易理解和接受。
七:扩展组件
组件作为一种提供特定功能的模型存在,包含约束,构造型和标记值。约束是用某种形式化的语言或者自然语言表达的语义关系的文字说明。构造型是指建模者设计的新的模型元素,但是它要在已有的UML模型基础上。标记值是附加到任何模型元素上的命名的信息块。下面是例图:
八:各种视图之间的关系
九:个人学习经验分享
有些东西是很简单的,关键是没有了去学习的动力,没有了自己前进的方向。我一直觉得能够只需要背诵下来的东西是最简单,需要理解并推陈出新的是最难的。每一次推陈出新都是自己能力进步的体现,要不进步也太平凡了,不值得自己去欢呼雀跃了。学习,哪怕是仅仅只是源于对一句话的感悟,也是进步。
U在UML类图中,常见的有以下几种关系: 泛化(Generalization), 实现(Realization),关联(Association),聚合(Aggregation),组合(Composition),依赖(Dependency)
1. 泛化(Generalization)
【泛化关系】:是一种继承关系,表示一般与特殊的关系,它指定了子类如何特化父类的所有特征和行为。例如:老虎是动物的一种,即有老虎的特性也有动物的共性。
【箭头指向】:带三角箭头的实线,箭头指向父类
2. 实现(Realization)
【实现关系】:是一种类与接口的关系,表示类是接口所有特征和行为的实现.
【箭头指向】:带三角箭头的虚线,箭头指向接口
3. 关联(Association)
【关联关系】:是一种拥有的关系,它使一个类知道另一个类的属性和方法;如:老师与学生,丈夫与妻子关联可以是双向的,也可以是单向的。双向的关联可以有两个箭头或者没有箭头,单向的关联有一个箭头。
【代码体现】:成员变量
【箭头及指向】:带普通箭头的实心线,指向被拥有者
上图中,老师与学生是双向关联,老师有多名学生,学生也可能有多名老师。但学生与某课程间的关系为单向关联,一名学生可能要上多门课程,课程是个抽象的东西他不拥有学生。
下图为自身关联:
4. 聚合(Aggregation)
【聚合关系】:是整体与部分的关系,且部分可以离开整体而单独存在。如车和轮胎是整体和部分的关系,轮胎离开车仍然可以存在。
聚合关系是关联关系的一种,是强的关联关系;关联和聚合在语法上无法区分,必须考察具体的逻辑关系。
【代码体现】:成员变量
【箭头及指向】:带空心菱形的实心线,菱形指向整体
5. 组合(Composition)
【组合关系】:是整体与部分的关系,但部分不能离开整体而单独存在。如公司和部门是整体和部分的关系,没有公司就不存在部门。
组合关系是关联关系的一种,是比聚合关系还要强的关系,它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。
【代码体现】:成员变量
【箭头及指向】:带实心菱形的实线,菱形指向整体
6. 依赖(Dependency)
【依赖关系】:是一种使用的关系,即一个类的实现需要另一个类的协助,所以要尽量不使用双向的互相依赖.
【代码表现】:局部变量、方法的参数或者对静态方法的调用
【箭头及指向】:带箭头的虚线,指向被使用者
各种关系的强弱顺序:
泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖
下面这张UML图,比较形象地展示了各种类图关系: