面向对象(OO)
-
对象
-
类
-
抽象
-
封装
-
泛化
-
多态
初识UML
UML构造块(Building Block)
事物(Things)
-
结构事物
类、接口、用例、协作、组件、节点
-
行为事物
交互、状态机、活动
-
分组事物
包
-
注释事物
注解
关系(Relationships)
-
关联(association)
-
依赖(dependency)
-
泛化(generalization)
-
实现(realization)
图(Diagrams)
-
结构图 + 行为图
UML规则
-
Names
-
Scope
-
Visibility
-
Integrity
-
Execution
UML通用机制(Common Mechanisms)
规格说明(specifications)
修饰(adornments)
通用划分(common divisions)
-
类型-实例
典型例子:类和对象
-
接口-实现
拓展机制(extensibility mechanisms)
-
构造型(stereotype)
将已有的元素模型进行修改或精化,创造出一种新的模型元素
-
标记值(tagged value)
标记值是关于模型元素本身的一个属性的定义,即一个元属性的定义
-
约束(constraint)
约束是使用某种文本语言中的陈述句表达的语义条件或者限制
4 + 1 架构
"4"
-
逻辑视图(logic view)
反映系统内部如何组织和协作来实现功能的
-
开发视图(development view)
描述软件各个模块的组织方式
-
进程视图(process view)
描述系统的运行特征,例如进程,线程,同步,并发
-
物理视图(physical view)
描述硬件配置,例如系统的安装,配置,通信
"1"
-
场景视图(scenarios)
从项目需求入手,将四个视图结合为一个整体。可以描述一个特定视图内的构件关系,也可以描述不同视图间的构件关系
UML 4 + 1 View
"4"
-
逻辑视图(logical view)
-
实现视图(implementation view)
-
进程视图(process view)
-
部署视图(deployment view)
"1"
-
用例视图(usecase view)
正向工程
模型 \rightarrow 代码
逆向工程
代码 \rightarrow 模型
UP
阶段(Phases)
-
起始阶段(Inception phase)
-
细化阶段(Elaboration phase)
-
构建阶段(construction phase)
-
转化阶段(transition phase)
特征(Characteristics)
-
用例驱动(Usecase driven)
-
体系结构为中心(Architecture centric)
-
迭代增量(Iterative and incremental)
用例图(Use Case Diagram)
简介
-
用例图是什么?
用例图是表示一个系统中用例与参与者之间关系的图
-
用例图中的主要元素。
包括参与者、用例以及元素之间的关系。此外还可以包括注释和约束
组成元素
-
参与者(actor)
参与者是与系统主体交互的外部实体的类元
参与者位于系统边界之外,不是系统的一部分
参与者是从现实世界中抽象出来的一种形式,但不一定确切的对应现实中的某个特定对象
-
用例(use case)
用例是参与者在系统中做某件事从开始到结束的一系列活动的集合
-
用例是动宾短语
-
用例由启动者启动,不存在没有参与者的用例
-
用例的粒度:没有明确界限,根据应用场景判断
-
常见关系
-
参与者间的泛化关系
系统中的几个参与者既扮演自身的角色,同时也有更一般化的角色。这时可以建立泛化关系进行描述
-
参与者与用例的关联关系
关联关系用实线箭头表示。
若箭头指向用例,表明参与者发起用例,即用例的主参与者;
若没有箭头或者箭头指向参与者,表示用例与外部服务参与者或外部接受参与者之间有交互,即用例的次参与者
-
用例间的泛化关系
将特化的用例与一般化的用例联系起来
-
用例间的依赖关系
-
包含 <<include>>
基用例执行时,包含用例也会执行。例如执行登录操作,一定要核实账号密码是否匹配
-
扩展 <<extend>>
基用例执行时,拓展用例可能会执行。例如执行登录操作,有可能返回登录失败的信息
-
前置条件与后置条件
-
前置条件
用例执行前系统和参与者应处于的状态
-
后置条件
用例执行完毕后系统处于的状态
事件流
类图(Class Diagram)
组成元素
类(class)
-
类名
简单名(simple name):Person
路径名(path name):java::awt::Rectangle
命名采用 UpperCamelCase 格式
-
属性
命名采用lowerCamelCase 格式
语法格式:
-
类型
属性的数据类型
例如:length: double
-
多重性
表示为一个包含于方括号中的数字表达式,相当于编程语言中数组的概念,若多重性为1,则可以省略
例如:nums: int [10]
-
初始值
创建对象时属性的默认值
例如:nums: int = 3
-
特性
对属性性质的约束,UML定义了三种特性
可变(changeable):属性可以随便修改,没有约束
只增(addOnly):属性修改时可以增加附加值,但不允许对值进行消除或进行减的改变
冻结(frozen):在初始化对象后,就不允许改变属性值
例如:PI: double = 3.1415926{frozen}
-
-
操作
接口(interface)
-
特性
-
接口不包含任何属性,不包含任何实现操作的方法,只包含一些操作
-
接口可以有泛化,但是没有直接实例
-
-
表示方法
-
带名称的小圆圈
-
带有<<interface>>构造型的类
-
类图关系
-
关联关系(Association)
-
关联名称
-
角色
角色名放在靠近关联端的部分,表示该关联端连接的类在这一关联关系中担任的角色,可以用+、-、#修饰
-
多重性
放在靠近关联端的部分,表示在关联关系中源端的一个对象可以与目标类的多少个对象之间有关联
-
导航性
-
限定符
-
关联的约束
-
-
泛化关系(Generalization)
描述了一种 "is-a-kind-of" (是……的一种)关系,类比继承关系
表示方法:一个由子类指向父类的空心三角形箭头
-
依赖关系(Dependency)
表示两个元素之间语义上的连接关系
对于两个元素 X(提供者) 和 Y(客户) ,如果元素 X 的变化会引起另一个元素 Y 的变化,则称元素 Y 依赖于 X。
表示方法:一个指向提供者的虚线箭头
-
实现关系(Realization)
表示方法:
-
一条指向提供规格说明的元素的虚线三角形箭头(接口用带有<<interface>>构造型的类表示)
-
一条简单的实线(接口用小圆圈表示)
-
-
聚合关系(Aggregation)
has a
一个描述整体的对象由一些描述部分的对象组成
聚合关系中,“部分”可以独立于“整体存在”
例如:教室类和课桌类之间构成聚合关系,即教室中有许多课桌,当教室对象不存在时,课桌同样可以用作其他用途,二者是独立存在的
-
组合关系(Composition)
contains a
组合关系中的部分完全依赖于整体,体现在两个方面:
-
部分对象在某一特定时刻只能属于一个组合(整体)对象
-
组合对象和部分对象具有重合的生命周期,组合对象销毁时,所有从属部分必须同时销毁
-
类的高级概念
-
抽象类(abstract class)
当某些类有一些共同的方法或属性时,可以定义一个抽象类来抽取这些特征;将包含这些共性方法和属性的具体类作为该抽象类的继承。
抽象类没有直接的实例。
-
模板类(template class)
-
关联类(association class)
-
分析类
-
边界类(boundary class)
用于对系统外部环境与其内部运作之间的交互进行建模的类
-
控制类(control class)
用于对一个或多个用例所特有的控制行为进行建模的类
-
实体类(entity class)
用于对必须存储的信息和相关行为进行建模的类
-
面向对象的设计原则
-
开闭原则(Open Closed Principle,OCP)
“开”:对扩展开放,即允许对系统的功能进行拓展
“闭”:对原有内容的修改是封闭的,即不应该修改原有的内容
为了遵循开闭原则,再类图设计时应该尽可能地使用接口或泛化进行封装,并通过使用多模态机制进行调用。
-
里氏替换原则(Liskov Substitution Principle,LSP)
核心内容:
-
子类对于父类应该是完全可替换的
-
-
依赖倒置原则(Dependency Inversion Principle,DIP)
核心内容:
-
高层次模块不应该依赖于低层次的模块,二者都应该依赖于抽象
-
抽象不应该依赖于具体,具体应该依赖于抽象
具体实现:
-
在高层次模块与低层次模块之间引入一个抽象层
-
新的抽象层不应该根据低层次创建,而是低层次模块要根据抽象层而创建
类结构组织方式:
高层次类 \rightarrow 抽象层 \rightarrow 低层次类
-
-
接口分离原则(Interface Segregation Principle,ISP)
核心内容:系统中任何客户类都不应该依赖于它们不使用的接口
具体实现:
-
当系统中需要接入许多个子模块时,相比于只使用一个接口,将其分成许多规模更小的接口是一种更好的选择,其中每一个接口服务于一个子模块
原则优点:
-
降低了系统的耦合度,从而使系统更容易重构、改变并重新部署
-
活动图(Activity Diagram)
简介
-
活动图是什么?
活动图的作用是描述一系列具体动态过程的执行逻辑,展现活动和活动之间转移的控制流
-
活动图的主要元素
包括动作、活动、动作流、分支与合并、分叉与汇合、泳道和对象流
组成元素
-
动作和活动节点(activity node)
动作表示一个原子操作,操作可以是任何合法的行为
活动节点是一系列动作,用于实现动作序列的简化和动作图的嵌套
-
开始和终止(initial node and final node)
活动图中必须有且仅有一个开始标记,一般至少有一个终止标记
-
控制流(control flows)
用于标示控制路径的一种符号,将执行主体从当前已完毕的节点转移到过程的下一个动作或动作节点
-
判断节点(decision node and guard expression)
用于逻辑判断并创造分支
-
合并节点(merge)
将多个控制流进行合并,并统一导出到同一个离开控制流
-
泳道(swimlane)
将活动中的具体活动按照负责进行该活动的对象进行分区,一条泳道中的所有活动由同一个对象来执行
-
分叉节点与结合节点(fork node and join node)
分叉节点:从线性流程进入并发过程的过渡节点
结合节点:仅仅表示形式上的收束。先到达结合节点的控制流都必须等待,直到所有的流全部到达这个结合节点后才继续进行
-
对象流(object flow)
对象流是一种连接两个节点的活动边,这两个节点通常是一个可执行节点和一个对象节点
-
扩展区域(expansion region)
同一个操作通常要在一组元素上进行
高级概念
-
子活动(sub-activity)
活动中可以嵌套活动
-
信号(signal)
信号表示在活动图中的两个活动或动作之间进行通信或触发的事件。它用于描述活动之间的异步通信,通常在一个活动发出信号,而另一个活动或对象捕获并响应该信号。信号可以在活动图的顺序流中传递,引发状态转换或触发操作的执行。
-
引脚(pin)
引脚用于表示输入或输出参数、变量或数据流。它们通常与活动图中的动作或控制流节点相关联。引脚有输入引脚和输出引脚两种类型。输入引脚表示数据的输入,输出引脚表示数据的输出。引脚有助于定义活动图中的数据流,并显示在不同节点之间传递的信息。
包图(Package Diagram)
简介
-
包图是什么?
包图是用来描述模型中的包和所包含元素的组织方式的图
-
包图的主要元素
包以及包的依赖关系
组成元素
-
包名
包有简单名和路径名两种命名方法
例如,简单名:operation;路径名:com::system::GUI
-
包中的元素
包中可以容纳各种高级的模型元素,如类和类的关系、状态机、用例图、交互等,甚至是一个完整的UML图;
而低层次的元素如属性、行为、状态和消息等,则不能直接体现在包中,而应该体现在其所属的模型元素中。
包中可以含有包(包的嵌套),包的嵌套可以清晰地表现系统模型元素的关系以及包的整体架构
相关概念
-
包元素的可见性
含义:包外元素对包内元素的访问权限
包内元素可能被其他包的元素使用,这种使用被称作引入(import)
包使用元素的可见性来控制包外元素对包内元素的访问权限,包括公有(public)、保护(protecte)和私有(private)三种。
如果某元素对于一个包是可见的,则它对于嵌套在这个包中的任何包都是可见的,即一个包可以看到其容器包可见的元素
-
包的构造型
可以通过构造型来描述包的种类。UML一共定义了五种可应用在包上的标准构造型
-
<<system>>
-
<<subsystem>>
-
<<facade>>
-
<<stub>>
-
<<framework>>
-
包的依赖关系
包的依赖关系可以通过添加构造型来使其语义更加明确,最常见的包依赖关系的构造型就是引入,表示为<<import>>
<<import>>
关系的箭头通常指向被导入的包,表示导入了该包的内容。
对象图(Object Diagram)
-
对象
对象名三种表示方法
stu: Student
: Student
stu
-
链
关联关系的实例
不能显示多重性,因为实例之间没有多重性
状态机图(State Machine Diagram)
-
Describe the lifetime of a single object
State
name + entry/exit effects + internal transition + substates + deferred event
Transition
source state + target state + event trigger + guard condition + effect
external transition + internal transition + local transition
History State
shallow state + deep state
Composite State
concurrent (orthogonal) substates + sequential (nonorthogonal) substates
Initial Node
Final Node
顺序图(Sequence Diagram)
-
简介
-
顺序图是什么?
按时间顺序显示对象交互的图
-
顺序图的主要元素
对象、生命线、激活、消息
-
组成元素
-
对象和生命线(object and lifeline)
-
激活(activation)
-
消息(message)
-
结构化控制
-
可选片段:opt
-
条件片段:alt
-
并行片段:par
-
循环片段:loop
-
交互片段:ref
opt, alt, and loop have guard condition.
通信图(Communication Diagram)
emphasizes the structural organization of the objects that send and receive messages
Object + Link + Message
时间图(Timing Diagram)
时间图相对顺序图的优点
时间图显示地展现了生命线上的状态变化和标度时间,可以应用到实时控制等系统中
linear time axis
线性时间轴,可以表示对象之间确切的交互时间
交互概览图(Interaction Overview Diagram)
组件图(Component Diagram)
component + interface + port
-
组件(component)
组件是一个封装完好的物理实现单元,它对接口的实现过程与外部元素独立
组件具有可替换性,相同接口但不同实现的组件一般来说是可以互相替换的
组件与类二者的区别:
类是逻辑抽象,不能单独存在于计算机中
组件是物理抽象,可以独立存在并部署在计算机上
-
接口(interface)
提供接口(provide interface) + 需求接口(required interface)
表示方法:球窝表示法
-
端口(port)
端口是一个被封装的组件的对外窗口
端口提供的封装性和独立性在更大程度上保证了组件的封装性和可替换性
Component diagrams address the static implementation view of a system.
Component diagram has a higher level of abstraction than a Class Diagram.
A component is shown as a rectangle with a small two-pronged icon in its upper right corner.
部署图(Deployment Diagram)
-
节点(node)
节点是运行时的物理对象,代表一个计算资源
节点可以根据其不同种类标记为不同的构造型,常见的两种构造型分别是设备(device)和执行环境(execution environment)
-
连接(connection)
节点之间使用关联关系表示节点之间的通信路径,可以使用不同的构造型来区分不同类型的通信路径或通信的实现方式
例如:<<HTTP>>、<<TCP/IP>>
visualize the static aspect of physical nodes and their relationships and to specify their details for construction