澳门人·巴黎(中国)官网欢迎您

一、前言谈到面向工具技术的分析和设计，自然就离不开 UML。对于 UML 这个观点，许多法式员朋侪耳熟能详，也有在用，但在事情中，一些朋侪其实并不擅长使用 UML 甚至对 UML 这个工具模棱两可，也包罗我自己。因此我希望可以联合自己的履历和实践，写一篇 UML 的入门文章，资助做面向工具的法式员朋侪能更好的使用它，从而顺利完成自己的编程设计事情。以下是本文纲领。

二、从一个示例开始先举个现实世界的例子。我们上大学的时候，作为学生，每人都有一张学生证，会归属到一个班级，上学时可能会用到自行车。许多同学还会考驾照，挑放假时间练车，车可能是轿车也可能是皮卡。

如果想通过在线的方式记载以上的信息和行为，在软件世界中如何表达呢？相信许多朋侪的操作是，找到这段话里的主语和宾语，也就找到了这个例子中涉及的角色，然后通过动词来判断各个角色之间的关系和能力，最后用代码的方式来表达，产出可执行的法式。像下图这样，识别出关键的实体和它们之间的关系。用软件工程的方式，解决现实中的问题，是信息时代最显着的特点，这让我们的生活和事情变得越发便利。但现实世界错综庞大，灵活多变，每小我私家的明白可能会有差别，从现实世界到软件世界的映射，就变得难题重重，一团乱麻。

如何让现实世界到软件世界映射变的简朴容易，这就是 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 的组成结构，从元素和视图的角度出发，解说了绘制图形的方法和相关观点。文中也给出了许多我亲手绘制的样例视图，如有错误之处，还望读者指摘。纸上得来终觉浅，绝知此事要躬行。

知道和做到总有一段距离，重在实践。希望这篇文章对从事面向工具编程的读者朋侪能够有所启发，接待和我一起交流，也接待转发给有需要的朋侪。

（完）。

本文来源：巴黎澳门人娱乐网站-www.ausunland-group.com