以下是本文大纲。

二、从一个示例开始

先举个现实天下的例子。
我们上大学的时候,作为学生,每人都有一张学生证,会归属到一个班级,上学时可能会用到自行车。
很多同学还会考驾照,挑放假韶光练车,车可能是轿车也可能是皮卡。

uml画jspUML 入门  类图  时序图 万字多图异常干燥 Java

如果想通过在线的办法记录以上的信息和行为,在软件天下中如何表达呢?

相信很多朋友的操作是,找到这段话里的主语和宾语,也就找到了这个例子中涉及的角色,然后通过动词来判断各个角色之间的关系和能力,末了用代码的办法来表达,产出可实行的程序。

像下图这样,识别出关键的实体和它们之间的关系。

用软件工程的办法,办理现实中的问题,是信息时期最明显的特点,这让我们的生活和事情变得更加便利。

但现实天下错综繁芜,灵巧多变,每个人的理解可能会有不同,从现实天下到软件天下的映射,就变得困难重重,一团乱麻。

如何让现实天下到软件天下映射变的大略随意马虎,这便是 UML 要办理的问题。

三、什么是 UML?

UML 全称是 Unified Modeling Language(统一建模措辞),它以图形的办法来描述软件的观点。

3.1 为什么称为措辞

先说措辞,为什么称为措辞?

名称的落脚点是措辞。
既然是措辞,那么它就会具备措辞的特性,比如构造上它由词汇和语法构成,功能上它能办理沟通问题。

你熟知的措辞里比较多的该当是汉语和英语,如果从事软件行业,C 措辞和 Java 措辞你该当也不会陌生。
英语和 Java 措辞明显都是措辞,却常常不被放在一起谈论,为什么?由于它们是不同维度的措辞。
英语是办理现实天下中人与人之间沟通问题的人类措辞,Java 是办理软件天下中程序员与打算机之间沟通问题的打算机措辞。

人类措辞实质上是事实和不雅观点的表达,打算机措辞实质上是0 和 1 的表达。
前者的表达形式是难以确定的,而且可能会产生歧义,以是才会有「被误解是表达者的宿命」这样的不雅观点, 但后者便是确定性无歧义的 0 1 表达。

这么看来,UML 的目标是通过一定构造的表达,来办理现实天下到软件天下的沟通问题。

3.2 什么是建模

再说建模,模是什么,须要怎么建?

建模大略讲,是指通过抽象的办法办理某个领域的问题。
各个抽象角度共同组成了一个问题领域。

对付传统模型而言,建造它是为了证明这个问题领域下某件事物能否事情。
当然它有条件,即建造模型的本钱远远低于建造实物的本钱。
比如造飞机或造高楼。

对付软件模型而言,建造它是为了与他人沟通,也为了保存这个问题领域下软件设计的终极成果。
当然它也有条件,便是模型比代码更解释问题。

比如购物这个问题,甲可以在淘宝上买衣服,乙可以在亚马逊上买书,丙可以在京东上买手机。

谁买东西?是甲、乙和丙,他们都能抽象成人。

买什么东西?有衣服、书和手机,它们都能抽象成货。

在哪里买?在淘宝,亚马逊和京东,它们都能抽象成场。

整体抽象一下便是人到场里买货。
以是购物这个场景所抽象出来的人货场,就用来办理零售领域的问题。
当然还可能会有些规则,比如成为注册会员才能发生交易。

我们会创造,一个特定的事宜(比如购物)里,会有特定的人的行为(比如甲乙丙要上电商网站),会有特定的物(比如货),有特定的规则(比如注册会员),共同完成购物这件事。

特定的事 = 特定的人的行为 + 特定的物 + 特定的规则

在人货场这个抽象角度里,就会涉及到很多特定的事,包括会员注册,会员下单,会员支付,商家发货,快递公司邮寄等等。

模大略讲,便是人、事、物和规则。

人是统统的中央,人要干事,干事就会利用一些物并产生另一些物,同时干事须要遵照一定的规则。

人驱动系统,事表示过程,物记录结果,规则是掌握。

建立模型的关键便是弄明白有什么人,什么人做什么事,什么事产生什么物,中间有什么规则,再把人、事、物之间的关系定义出来,一个模型也就基本成型了。

3.3 统一的意义在哪

统一的普遍意义是形成标准。
所谓标准,便是所有人都明白的表述,所有人都屈服的格式。
标准可以让信息在人群中无障碍地流利,纵然这些信息来自不同地域、不同文化、不同社会或不同组织。

比如美元作为国际统一利用的货币方便了环球的经济贸易,我们国家遍及普通话方便了不同地区的互换沟通。

在软件天下,任何一种组件化开拓模式背后都有一个标准在规范和辅导,比如 Java 的 JSR 标准。
有了标准,编程就随意马虎组件化,协作效率也会提升很多。
对 UML 来说,这便是统一的意义。

四、为什么须要 UML

一个软件项目要经历业务调研、立项、需求采集、架构设计、编码开拓和测试验证等多个环节。

每个环节可能角色并不相同,同样的文档同样的话语越向后通报就越随意马虎失落真。
因此就随意马虎涌现终极交付的产品不是客户真正想要的这种情形。

如何避免角色间信息通报的失落真,担保信息能被准确的传达和准确的理解?一种好的办法便是大家利用标准化的措辞。

统一建模措辞(UML)就试图用标准化的措辞来覆盖全体软件过程,让不同团队不同角色可以用相同的措辞顺畅的沟通。

在信息传播方面,图形相对付笔墨,人脑的接管能力显然更强。
因此,UML 采取了「可视化」的图形办法来定义措辞。

五、UML 的适用场景

UML 既可以描述某个问题领域,也可以表达构思中的软件设计,还可以描述已经完成的软件实现。

它适用于面向工具剖析设计的全体过程。
这个过程可以分为三个阶段,如下图。

第一个阶段是通过建模将现实天下转为业务模型。
业务模型真实映射了参与者(业务活动的驱动者)在现实天下的行为。

从图里可以看到,现实天下映射到业务模型后,是利用 参与者 和 用例 这两个 UML 的核心元素表达的。
参与者作为一个特定事宜的驱动者,用例则描述了这个驱动者的业务目标。
文章后边也会提到这两个元素。

第二个阶段是对业务模型观点化,建立适宜打算机理解和实现的模型,也便是观点模型,或者叫剖析模型。
剖析模型向上映射了原始需求,向下为打算机实现规定了一种高层次的抽象,是一种过渡模型。

现实天下千差万别的业务,都用 边界、掌握和实体这几个核心元向来描述,同时也引入了 包、组件 这些与现实天下绝不相关的观点做包装。

第三个阶段是对观点模型实例化,得到相对详细的设计模型。

在设计模型中,观点模型中的边界类可以被转化为操作界面或者系统接口;掌握类可以被转化为打算程序或掌握程序,例如事情流、算法体等;实体类可以转化为数据库表、XML 文档或者其他带有持久化特色的类。

同样的观点模型会由于选择不同而得到不同的设计模型。
比如技能选型上利用不同的编程措辞,不同的中间件就会得到不同的设计。

为什么须要这一道转换呢?

由于“边界”、“掌握”、“实体”这些工具化的观点,虽然是打算机可以理解的,但它并不是真正的工具实例,也便是说它们并不是可实行代码,观点模型只是纸上谈兵。
真正的工具天下行为是由 Java 类、C++ 类、JSP 等这些可实行代码构成的。

换句话说,设计模型是观点模型在特定环境和条件下的实例化,实例化后的工具行为实行了观点模型描述的那些信息。

以下是面向工具剖析设计的完全过程,它表达了现实天下是怎么通过 UML 映射到工具天下的。

六、UML 的组成构造

前面花了比较大的篇幅剖析了 UML 的定位和适用场景,目的是帮助读者建立对 UML 整体系统性的认知,而不是过早的陷入 UML 的利用细节里。
我们要运用一项技能或工具,不能纯挚的由于它的酷炫或者说业界都在用以是我们要用,而该当结合自己的利用场景以及技能或工具的特点,来确认这项技能或工具究竟是不是我们须要的。

在读者理解 UML 在面向工具剖析设计领域精良的特性之后,我们再来看看 UML 的一些细节。

凡是措辞,都会存在基本词汇和语法。

那么对应到 UML 里,基本词汇便是核心元素,语法便是核心视图。

UML 的组成构造如下图:

6.1 核心元素

我们先先容核心元素,下图是大纲。

6.1.1 版型

版型:也称「类型」或「布局型」。
是对 UML 元素根本定义的扩展,在元素根本定义的根本上授予特殊的含义,使得这个元素适用于特定的场合。

比如,我们前边提到的「边界类」、「实体类」、「掌握类」都是类的版型。

6.1.2 参与者

参与者定位:事宜的第一驱动者,也是系统的做事方。
比如你在电商网站购物,你便是参与者。

6.1.3 用例

用例定位:系统实行的一系列操作,并天生参与者可以不雅观察的值。
比如你在电商网站交易,会天生在线订单,用户下单便是一个用例。

用例版型:

业务用例:用于需求阶段业务领域建模。
与打算机系统建模无关,比如下单可以不依赖在线做事,而只是线下签署协议。
业务建模的目标是让需求职员和客户能够达成共识。
业务用例实现:业务用例的一种实现办法,一个业务用例可以有多种实现办法。
比如下单后的支付,可以用现金,也可以银行卡转账,还可以第三方支付。

观点用例:用于获取业务模型中的关键观点,剖析出核心业务构造。
业务架构便是观点建模阶段产生,同时为系统建模阶段供应主要辅导。
比如用户下单这个用例,可以从实现过程中得到一些核心业务,并把它们展现出来。

系统用例:用于定义系统范围、获取功能性需求。
也便是我们常挂在嘴边的用例。
像业务用例中提到的线下签约的办法,就不会纳入到系统用例中,但如果是电子签约的话,就可以成为系统用例了。
系统用例实现:系统用例的一种实现办法,一个别系用例可以有多种实现办法。
比如下单后的支付,可以接入微信支付接口,也可以接入支付宝支付接口。

你会创造,同是用例的版型,业务用例与系统用例的差异就在于业务用例是客户业务视角,系统用例是系统视角。

6.1.4 边界

边界定位:用于业务建模和系统建模阶段的剖析,担保剖析粒度在一定的范围内,不会扩散。

比如一个电商网站按领域职责作为边界,会有店铺域、商品域、会员域、交易域、支付域和营销域等。
各域只卖力域内的事情,就能够减少混乱紧耦合的局势。

一个好的剖析和设计如同一筐带壳的鸡蛋,清清爽爽;一个差的设计如同一堆打碎了壳的鸡蛋,粘粘糊糊。
壳,是好坏的关键。

6.1.5 业务实体

业务实体定位:它代表参与者实行业务用例时所处理或利用的事物,特殊用于在业务建模阶段建立领域模型。
业务实体是类(class)的一种版型。

业务实体的构造:包含属性和方法。
属性用来保存业务实体特色,方法用来访问业务实体。
比如一台电视,把它算作一个业务实体的话,它的属性有运行状态和音量,它的方法便是遥控器,我们可以开、关、调声音,但是我们不可以试图让它飞起来——由于它没有这样的方法。

6.1.6 包

包定位:容纳并为其他 UML 元素分类。
比如 Java 后端常常会供应 jar 包给接入方利用。

6.1.7 剖析类

剖析类定位:用于代表系统中紧张的职责簇,由此产生系统的设计类和子系统。

边界类:用于对系统外部环境和内部运作之间的交互进行建模。
比如现实天下的窗户,打算机天下的网页。
掌握类:用于对用例特有的掌握行为进行建模。
比如显示逻辑和业务逻辑通过掌握层分离的 MVC 架构。
实体类:用于对须要存储的信息和干系行为进行建模。
源于业务模型中的业务实体。

剖析类的抽象层次较高,比设计和实现要稳定很多,因此方便掩护,也更随意马虎得到一个稳定架构来辅导全体软件的开拓。

6.1.8 设计类

设计类定位:是系统履行中一个或多个工具的抽象,由此映射到实当代码,依赖于履行措辞。

设计类构造:

类型:对工具某一方面特色的归纳和抽象。
映射到编码中的 class。
属性:工具特色。
映射到编码中的 field。
方法:访问工具属性的唯一路子。
映射到编码中的 method。
6.1.9 关系

关系定位:抽象出工具之间的联系,让工具构成某个特定的构造。

关系分为以下几种:

关联(association)关系:是一种拥有的关系,即一个类知道另一个类的属性和方法;比如老师与学生可以是双向的,也可以是单向的。
双向的关联可以有两个箭头或者没有箭头,单向的关联有一个箭头。
箭头和连线:带普通箭头的实心线,指向被拥有者。
适用场景:类图。
依赖(dependency)关系:是一种利用的关系,即一个类的实现须要另一个类的帮忙,是一种弱关系,随运行场景变革。
比如削苹果时,人依赖于刀,分开了这个场景,依赖关系就不存在了。
箭头和连线:带箭头的虚线,指向被利用者。
适用场景:类图。
泛化(generalization)关系:是一种继续的关系,比如猫是动物的一种。
箭头和连线:带三角的实线,箭头指向父类。
适用场景:类图。
实现(realization)关系:是一种实现的关系,比如用例和用例实现的关系,接口与实现类的关系。
箭头和连线:带三角的虚线,箭头指向用例实现或接口类。
适用场景:用例图,类图。
聚合(aggregation)关系:是整体与部分的关系,且部分可以离开整体而单独存在。
生命周期各自独立。
如车和轮胎是聚合关系,轮胎离开车仍旧可以存在。
箭头和连线:带空心菱形的实线,菱形指向整体。
适用场景:类图。
组合(composition)关系:是整体与部分的关系,但部分不能离开整体而单独存在。
同生同灭。
如公司和部门是组合关系,没有公司就不存在部门。
箭头和连线:带实心(玄色实心:要去世一起去世,良心是黑的)菱形的实线,菱形指向整体。
适用场景:类图。

关联关系和依赖关系的差异:

关联关系是静态天然的联系,依赖关系是动态临时的联系。

此外还有只用于用例中的关系:

扩展(extends)关系:用于在用例模型中解释向基本用例中的某个扩展点插入扩展用例。
箭头和连线:带箭头的虚线加版型<<extends>>。
特点:用例可选。
包含(include)关系:用于在用例模型中解释在实行基本用例的用例实例过程中插入的行为段。
箭头和连线:带箭头的虚线加版型<<include>>。
特点:用例必需。
6.1.10 组件

组件定位:实现特定功能的逻辑代码模块。
比如分布式运用架构下,将业务目标拆成多个功能,每个功能作为组件独立支配。
这样这些组件也能被其他场景复用。

6.1.11 节点

节点定位:表示运用程序的支配单元。
比如分布式运用的环境中,做事器或设备会有很多,就须要通过节点来表示物理支配的情形。

6.2 核心视图

前面我们先容了 UML 的核心元素,这些元素分别运用于面对工具剖析设计的各个阶段,正是它们之间的相互组合,才形成了 UML 里的各种视图,终极辅导软件设计。

接下来讲讲核心视图里的构造视图和行为视图,下图是大纲。

6.2.1 构造视图

构造视图也称为静态视图。
静态视图便是表达静态事物的。
它只描述事物的静态构造,而不描述其动态行为。
这里简要先容的静态视图包括用例图,工具图,类图,组件图,包图和支配图。

6.2.1.1 用例图

用例图包含参与者、用例和关系这三种核心元素,不同的视角可以得到不同的用例视图,它展现了系统的功能性需求。

所谓不同的视角,可以对应面向工具剖析设计的三阶段。

建立业务模型阶段,产出业务用例视图。
建立观点模型阶段,产出观点用例视图。
建立设计模型阶段,产出系统用例视图。

就借阅图书的用例而言,业务用例视图如下,它是完备从业务角度出发,和打算机系统无关。

而我们在业务用例剖析的过程中,可以分解出一些关键的观点用例,并建立它们之间的关系,如下图(bu 表示业务用例,cu 表示观点用例)。

我们对业务用例进行剖析往后,就可以绘制系统用例视图。
但不是所有的业务用例都有系统用例对应,比如检讨借阅证可能是手工事情,就不须要纳入系统培植范围。

下图是借阅图书的系统用例视图。

6.2.1.2 类图

类图用于展示系统中的类及其相互之间的关系。

类图建模常用的办法是从观点层,到解释层,末了到实现层这么一个抽象层次逐步降落和细化的过程。

观点层类图位于业务建模阶段,这个阶段采取业务实体这个核心元向来表示。

下图是网上购物的业务实体图。

网上购物紧张由商品、订单、支付账户这几个关键类构成,这几个类的交互能够完成网上购物这个业务目标。

解释层类图位于观点建模阶段,这个阶段采取剖析类这个核心元向来表示。

下图展示了网上购物的解释层类图,这个类图表达了从打算机的视角来说,网上购物这个业务目标是由哪些类来完成的,这些类的接口担保了这个业务目标的达成。

实现层类图位于设计建模阶段,这个阶段采取设计类这个核心元向来表示。

到了这一层,类图可视作伪代码,因此,在这个层次上,类必须明确采取哪种实现措辞、什么设计模式、什么通信标准、遵照什么规范等。

下图展示了查询商品功能的类图。
可以看到,到了实现层类图,类描述和类关系已经是伪代码级别了。

由此可见,在软件生命周期的不同阶段,类图也有三种不同的表达,他们分别是观点层类图,解释层类图和实现层类图。

很多朋友在建模的时候只会用到实现层类图,并非他们对问题领域足够理解,而是不清楚类图也分了这么三层。

6.2.1.3 工具图

工具图是类图的实例,标识和类图基本相同。
由于工具存在生命周期,工具图只能在系统某一韶光段存在,因此工具图可以被想象成正在运行的系统在某一时候的快照。

比如一个正在运行的列车,如果用工具图来描述,某个韶光点你会创造以下静态图片:

当前的运行状态(运行中或停车中)当前的搭客数量。
(如果捕捉在不同的韶光,该值会变革)

6.2.1.4 包图

在实际的项目中,建模过程得到的元素可能是非常多的,如果将这些元素的关系都绘制出来,看上去就会特殊乱,特殊繁芜,也难以识别。

那为了更好的理解和管理这些建模元素,我们就须要有规律的对元素进行组织。
包图就起到了这么一个浸染,通过包这个容器,可以从大到小、从粗到细地将建模元素组织起来,便于我们的剖析,互换和细化。

下图是网上购物的领域包图,它表达了关键业务领域及其依赖关系。

下图展示了查询商品功能的类层次,它表达了实现类位于哪个层次的软件架构的不雅观点。

6.2.1.5 组件图

当有些包能够被多个场景重复利用,那这个包就可以认为有着特定的功能,能够完成特定的目标。

这种情形下,包就可以定义为组件,组件是一种分外的包,既起到了普通包组织和容纳的浸染,又能完成特定的功能。

比如模块(登录模块),类库(Java Guava 包)。

下图可以表达组件实现的过程,通过第三方软件或者面向工具剖析设计过程中产生的各种包,可以定义组件。

组件可以按功能分为以下几类:模块、子系统、库、可实行文件和程序包等等。

6.2.1.6 支配图

支配图描述了物理上系统运行时的构造,包括系统中硬件的分布以及软件支配到硬件上的详细办法。

支配图用于设计建模阶段,采取节点和关系两种核心元向来绘制。
常用于分布式运用环境和多设备运用环境。

上图是一个大略的支配图,表达了客户端比如浏览器这个节点,会要求到 Web 做事器节点,末了通过数据库做事器节点返回数据。
如果涉及分布式环境,就要考虑多个 Web Server,多个 Database Server,乃至考虑多机房,异地等物理层面的支配办法。

6.2.2 行为视图

构造视图先容完,我们讲讲行为视图。

行为视图也称为动态视图。
动态视图便是描述事物动态行为的。
动态视图不能独立存在,它必须基于一个静态视图或者 UML 元素,解释在静态视图规定的事物构造下它们的动态行为。

这里简要先容的动态视图包括状态图、活动图、时序图和协作图。

6.2.2.1 状态图

状态图也称状态机,它描述了一个工具的生命周期,你可以把它理解成一台运行中的机器,这台机器卖力这个工具在固定几个状态间的流转。

这个工具可以是业务实体工具,也可以是剖析类工具,还可以是设计类工具。
也便是说,在面向工具剖析设计的三个阶段(业务建模,观点建模,设计建模),都可以用状态图来表达。

下图是一个产品的生命周期状态图。
绿色部分是状态图干系的元素,赤色部分是元素的阐明。

从图中,我们可以看到,状态图有以下关键元素:

初始状态:它是状态机的起始位置,不须要事宜的触发。
用实心圆圈表示。
状态:状态是工具实行某项活动或者等待某个事宜时的条件。
比如要想实行产品入库动作,产品得是未入库的状态,如果想发卖某个产品,产品得是入库的状态。
转移:转移是两个状态之间的关系,它表示当发生指定事宜并且知足指定条件时,第一个状态中的工具将实行某些操作并进入第二个状态。
比如产品入库这个动作,就将产品的状态从未入库转移到了已入库。
事宜:事宜是一个特定的动作或行为,有时候也包括系统时钟之类的定时器。
如果条件知足,事宜的发生将触发一个转移。
比如产品发卖这个动作,出发产品从已入库状态转移至已发卖状态。
条件:条件是一个布尔表达式,当事宜发生时将检讨这个表达式的值。
条件求值结果可能决定转移的分支,或者谢绝转移。
条件有可能引用当前状态。
比如产品合不合格这个布尔判断,决定了产品是可被发卖,还是不可被发卖。
终极状态:终极状态表示状态机实行结束,或者工具生命周期结束。
用带环的实心圆圈表示。
6.2.2.2 活动图

活动图描述了为了完成某一个目标须要做的活动以及这些活动的实行顺序。

UML 中有两个层面的活动图,一种是用例活动图,它用于描述用例场景,常用于业务建模阶段,另一种是工具活动图,用于描述工具交互,常用于设计建模阶段。

下图是一个登机手续办理的用例活动图。
绿色部分是活动图干系的元素,赤色部分是元素的阐明。

从图中,我们可以看到,活动图有以下几个关键元素:

起始点:起始点标记业务流程的开始。
一个活动图仅有一个。
用实心圆圈表示。
活动:活动是业务流程中的一个实行单元。
比如办理登机手续须要出示机票和身份证这样的动作。
判断:判断根据某个条件进行决策,实行不同的流程分支。
比如身份核对决定了你能否连续办理登机手续。
基本流:基本流表示最紧张、最频繁利用的、默认的业务流程分支。
比如身份核对的正常分支。
支流:支流是进行判断后走进的业务流程分支。
比如图中无行李分支。
非常流:非常流表示非正常的、不是业务目标期待的、容错性的、处理意外情形的业务流程分支。
比如身份证核对缺点。
同步:同步分为同步起始和同步汇合。
同步起始表示从它开始多个支流并行实行。
比如托运行李的处理和登机牌的打印操作,可以并行。
同步汇合表示多个支流同时到达后再实行后续活动。
结束点:结束点表示业务流程的终止。
一个或多个。

用例活动图常常是从业务的角度上,剖析要完成某个目标,要实行哪些活动。
如果在系统设计的角度上,要表达完成目标须要的活动,就须要用到工具活动图。

比如根据查询商品的工具交互过程,就能绘制出以下的工具活动图。

虽然 UML 许可用活动图绘制工具交互,但实际事情中,我从来没用过。
由于 UML 有其他更好的工具来绘制工具交互图,比如接下来要讲的时序图。

6.2.2.3 时序图

时序图用于描述按韶光顺序排列的工具之间的交互模式。

前面类图那一节有提过类有三个层次的不雅观点:观点层、解释层和实现层,分别对应于面向工具剖析设计的业务建模阶段、观点建模阶段和设计建模阶段,相应的,也可以在这三个层次上分别对业务实体工具、剖析类工具和设计类工具绘制业务模型时序图、观点模型时序图和设计模型时序图。

接下来先容三种时序图。

业务模型时序图用于为领域模型中的业务实体交互建模,目标是实现业务用例。

上一节提到的活动图,可以帮助我们创造业务实体,活动图也可以很轻易的转换成时序图,下图是网上购买商品的业务模型时序图。

时序图中会涉及一些 UML 元素,这里列举常用的几个:

工具:表示参与交互的工具。
每个工具都有一条生命周期线,工具被激活时,生命周期线上会涌现一个长条(会话),表示工具的存在。
生命周期线:表示工具的存在。
当工具被激活时,生命周期线上涌现会话,表示工具参与了这个会话。
:表示工具间交互所发生的动作。
由一个工具的生命周期线指向另一个工具的生命周期线。
常见的类型有以下几种:大略:向右的实线箭头,这种最为常用。
返回:源的返回体,并非新。
用向左的单向虚线箭头表示。
一样平常不须要为每个源都绘制返回,一方面源默认情形下都有返回,另一方面过多的返回会让图变得更繁芜。
同步:表示发出的工具将停滞所有后续动作,一贯等到吸收方相应。
用向右带×的单向实线箭头表示。
同步将壅塞源所有行为。
常日程序之间的方法调用都是同步。
异步:表示源发出后不等待相应,而可以连续实行其他操作。
用向右的单向上箭头表示。
异步一样平常须要中间件的支持,如 MQ 等。
会话:表示一次交互,在会话过程中所有工具共享一个高下文环境。
例如操作高下文。
销毁:表示生命周期的终止。
绘制在生命周期线的末端,一样平常没有必要强调。

业务模型时序图是业务建模阶段的产物,它展现了业务的实际需求,因此利用的描述措辞应该采取业务术语。

进入观点建模阶段,可以采取剖析类绘制观点模型时序图。
和业务模型时序图比较,同样是展现业务需求,不同点在于剖析类代表了系统原型,以是这个阶段的时序图已经带有了打算机层面的理解。

因此,观点模型时序图既保留了实际业务需求,又得到了打算机实现的基本理念。
如下图所示。

可以看到,在观点模型时序图里,相对付业务模型时序图,我们的表达增加了安全认证和商品目录。
这是由于我们实际在做登录这个功能时,我们的软件系统须要关心身份核验。
我们在获取商品时,为了避免凌乱须要对其进行分类。

其余,我们的业务实体转为剖析类进行表达,网站作为边界类,用于隔离用户操作和系统行为。
安全认证作为掌握类,用于决定是否能成功登录网站。
商品目录和商品作为实体类,用于表达用户实际想看到或者操作的实体信息。

剖析类展示出来的已经是系统实现的原型,进入设计建模阶段,我们做的事情便是要选择得当的实现办法来实现这个原型。

设计建模阶段,我们采取设计模型时序图来实现观点模型中的交互。

设计模型时序图利用设计类作为工具绘制,也是我们日常开拓设计中最为常用的动态视图。
以下是商品查询的设计模型时序图。

可以看到,在设计模型时序图里,会细致到方法级别。
由于在这个阶段,干系的技能选型,比如编程措辞,交互协议,中间件等已经比较明确了。

时序图除了在建模的三个阶段利用外,当你须要表达工具的交互,或者想剖析工具的职责和接口时,都可以利用时序图。

6.2.2.4 协作图

协作图和时序图一样,也是描述工具之间的交互模式,不同的是,时序图在意的是工具交互的实行顺序,而协作图在意的是工具间的构造关系。

因此,时序图适用于得到对调用过程的理解,而协作图适用于得到对工具构造的理解。

协作图可以和时序图相互转换,对合时序图的三种表达办法,协作图也分为业务模型协作图,观点模型协作图和设计模型时序图。
本文只先容业务模型协作图,其余两种协作图可以由相应的时序图推导,这里就不赘述了。

业务模型协作图同样采取业务实体来绘制,目标也是实现用例场景。
下图是网上购买商品的业务模型协作图。

可以看到,协作图和时序图比较,工具间的构造一览无余,很随意马虎知道哪些会影响哪些工具或者哪些工具须要供应哪些接口。
但在实行顺序的表达上就很弱,必须依赖文本里的数字。

以下是协作图常用的 UML 元素:

工具:表示参与协作的工具。
工具关联:用于连接两个工具,表示二者的关联。
这种关联是临时的,只在本次交互中有效。
:和时序图中的定义同等。
序号:表明通报的先后顺序。
6.2.3 小结

本节先容了 UML 的核心视图,我们再看下核心视图的大纲。

核心视图分静态视图和动态视图。
静态视图表达事物的构造性不雅观点,动态视图表达事物的行为性不雅观点。

一个好的建模,构造性和行为性都不可或缺,既要解释该事物长什么样子,又要解释该事物该当怎么用。

七、总结

本文从一个示例开始,引入了 UML 的观点,先容了什么是 UML,为什么要用 UML以及什么时候用 UML。
我们理解一个事物,知其然也要知其以是然。

然后先容了 UML 的组成构造,从元素和视图的角度出发,讲解了绘制图形的方法和干系观点。
文中也给出了很多我亲手绘制的样例视图,如有缺点之处,还望读者指摘。

纸上得来终觉浅,绝知此事要躬行。
知道和做到总有一段间隔,重在实践。

希望这篇文章对从事面向工具编程的读者朋友能够有所启示,欢迎和我一起互换,也欢迎转发给有须要的朋友。

(完)