Translated from Author: Randy Miller
面向对象问题解决的核心是构建模型。该模型从其通常复杂的现实世界中抽象出基本问题的基本细节。一些建模工具被包装在UML标题下，它代表了统一建模语言。本课程的目的是介绍UML的重要亮点。
UML的核心是它的九种建模图，我们在这里描述。
- 用例图 點擊Open Diagram打開並編輯。
- 类图 點擊Open Diagram打開並編輯。
- 序列图 點擊Open Diagram打開並編輯。
- 状态图 點擊Open Diagram打開並編輯。
- 活动图 點擊Open Diagram打開並編輯。
- 组件图 點擊Open Diagram打開並編輯。
- 部署图 點擊Open Diagram打開並編輯。
- 包圖 點擊Open Diagram打開並編輯。
本课程的某些部分包含指向更详细信息的页面的链接。每个部分都有简短的问题。使用它们来测试您对章节主题的理解。
为什么UML很重要？
我们从建筑业的角度来看这个问题。建筑师设计建筑物。建筑商使用这些设计来创建建筑物。建筑越复杂，建筑师和建筑师之间的沟通就越重要。蓝图是建筑师和建筑商必须学习的标准图形语言，作为其交易的一部分。
编写软件与构建建筑无异。底层系统越复杂，参与创建和部署软件的每个人之间的沟通就越重要。在过去的十年中，UML已经成为分析师，设计师和程序员的软件蓝图语言。它现在是软件交易的一部分。UML为业务分析师，设计师和程序员提供了一个共同的词汇来讨论软件设计。
UML适用于面向对象的问题求解。任何对学习UML感兴趣的人都必须熟悉面向对象问题解决的基本原则 - 这一切都始于建模。甲模型是根本问题的抽象。该领域是问题出现的现实世界。
模型由通过发送其他消息进行交互的对象组成。把一个物体想象成“活着”。对象拥有他们知道的东西（属性）和他们可以做的事情（行为或操作）。对象属性的值决定了它的状态。
类是对象的“蓝图”。一个类将属性（数据）和行为（方法或函数）封装到一个不同的实体中。对象是类的实例。
用例图描述了系统从外部观察者的角度所做的工作。重点是什么样的系统呢，而不是如何。
用例图与场景密切相关。一个场景是某人与系统进行交互时发生的情况的一个例子。这是一个医疗诊所的场景。
“病人打电话给诊所预约每年检查一次，接待员找到预约簿中最近的空白时间段，并安排该时间段的预约。”
一个 用例是单个任务或目标的情景摘要。一个演员是谁或什么启动了该任务中涉及的事件。演员只是人或物体扮演的角色。下图是医疗诊所的预约用例。演员是病人。参与者和用例之间的联系是通信联系（简称通信 ）。
演员是坚持数字。用例是椭圆。通信是将行动者与用例联系起来的线路。
用例图是演员，用例及其通信的集合。我们把Make Appointment作为一个包含四个角色和四个用例的图表的一部分。注意一个用例可以有多个参与者。
用例图有三个方面的帮助。
- 确定功能（要求）。随着系统的分析和设计的形成，新的使用案例往往会产生新的需求。
- 与客户沟通。它们的符号简洁性使用例图成为开发人员与客户沟通的好方法。
- 生成测试用例。用例情景的集合可能会为这些情景提供一套测试用例。
类图通过显示它的类和它们之间的关系来概述系统。类图是静态的 - 它们显示交互的内容，但不显示交互时会发生什么。
下面的类图模拟了零售目录中的客户订单。中央阶层是秩序。与之相关的是进行购买和付款的 客户。一个 付款是三种：现金，检查，或 信用。该订单包含OrderDetails（订单项），每个订单项都有相关的项目。
UML类符号是一个矩形，分为三个部分：类名称，属性和操作。抽象类的名称（如 付款）以斜体表示。类之间的关系是连接链接。
我们的类图有三种关系。
- 关联 - 这两个类的实例之间的关系。如果一个类的实例必须知道另一个类的实例以执行其工作，那么两个类之间就存在关联。在图中，关联是连接两个类的链接。
- 聚合 - 一个类属于一个集合的关联。聚合具有指向包含整体的部分的菱形末端。在我们的图中， Order 具有 OrderDetails的集合。
- 泛化 - 指示一个类的继承链接是另一个类的超类。泛化有一个指向超类的三角形。支付是现金，支票和信用的超类。
一个协会有两个目的。结束可能有一个角色名称来澄清协会的性质。例如， OrderDetail是每个订单的订单项。
一个 关联上的可导航箭头显示可以遍历或查询关联的方向。一个的OrderDetail可以查询有关其 项目周围，而不是其他方式。箭头还可以让你知道谁拥有该协会的实施; 在这种情况下， OrderDetail有一个 Item。没有导航箭头的协会是双向的。
该 关联结束的多重性是与另一端的单个实例关联的类的可能实例的数量。多重性是单个数字或数字范围。在我们的示例中，每个 订单只能有一个客户，但客户可以有任意数量的 订单。
该表给出了最常见的多重性。
| 多重 | 含义 |
|---|---|
| 0..1 | 零个或一个实例。符号n。。m 表示n到m个实例。 |
| 0 .. * 或 * | 对实例数量没有限制（包括无）。 |
| 1 | 恰好一个例子 |
| 1 .. * | 至少有一个例子 |
每个类图都有类，关联和多重性。导航和角色是放置在图表中的可选项目，以提供清晰度。
为了简化复杂的类图，可以将类组合到 包。一个包是逻辑上相关的UML元素的集合。下面的图是一个业务模型，其中类被分组到包中。
包在顶部显示为带小标签的矩形。包名称位于选项卡上或矩形内。虚线箭头是依赖关系。如果另一个包的变化可能会导致第一个变化，那么一个包依赖于另一个包。
对象图显示实例而不是类。它们对于解释具有复杂关系的小碎片很有用，特别是递归关系。
这个小类图表明大学部门可以包含很多其他部门。
下面的对象图通过一个具体的例子来实例化类图。
对象图中的每个矩形都对应一个实例。实例名称在UML图中用下划线表示。只要图表的意义仍然清晰，类或实例名称可以从对象图中省略。
类和对象图是静态模型视图。 交互图是动态的。他们描述对象如何协作。
一个 顺序图是一个交互图，详细说明如何执行操作 - 发送什么消息以及何时发送。时序图按照时间组织。随着你走下页面，时间会进展。根据参与消息序列的时间从左到右列出操作涉及的对象。
以下是进行酒店预订的顺序图。启动消息序列的对象是预约窗口。
的预约窗口发送makeReservation（）消息到HotelChain。所述HotelChain然后发送makeReservation（）消息到饭店。如果 酒店有空房间，则预订和 确认。
每条垂直虚线是a 生命线，代表一个物体存在的时间。每个箭头都是一个消息调用。箭头从发件人到顶部在接收器的生命线上的消息的激活条。激活条表示消息执行的持续时间。
在我们的图中，酒店发布了一个自我呼叫以确定房间是否可用。如果是这样，那么酒店创建一个预订和一个 确认。自助电话上的星号表示迭代（以确保在酒店住宿的每一天都有空余房间）。方括号中的表达式[]是一个条件。
该图有一个澄清 请注意，这是狗耳长方形内的文字。Notes可以放入任何类型的UML图中。
协作图也是交互图。它们传递与序列图相同的信息，但它们专注于对象角色而不是消息发送的时间。在序列图中，对象角色是顶点，消息是连接链接。
对象角色矩形标有类名或对象名（或两者）。类名前面是冒号（：）。
协作图中的每条消息都有一个 序列号。顶级消息编号为1.同一级别的消息（在同一个呼叫期间发送）具有相同的小数前缀，但后缀为1，2等。
对象具有行为和状态。对象的状态取决于其当前的活动或条件。一个状态图显示了对象的可能状态以及导致状态改变的转换。
我们的示例图模拟了在线银行系统的登录部分。登录包括输入有效的社会安全号码和个人身份证号码，然后提交信息进行验证。
登录可以分解为四个不重叠的状态：获取SSN，获取PIN，验证和拒绝。来自每个国家的都是一套完整的转换决定后续状态。
国家是圆角矩形。转变是从一个国家到另一个国家的箭头。触发转换的事件或条件被写在箭头旁边。我们的图有两个自我转换，一个是获取SSN ，另一个是获取PIN。
初始状态（黑色圆圈）是开始动作的虚拟人。最终状态也是终止操作的虚拟状态。
由于事件或条件而发生的动作以表单/动作表示。处于 验证状态时，对象不会等待外部事件触发转换。相反，它执行一项活动。该活动的结果决定了其后续状态。
一个 活动图本质上是一个花哨的流程图。活动图和状态图是相关的。虽然状态图将注意力集中在正在经历过程的对象上（或作为对象的过程），但活动图侧重于单个过程中涉及的活动流。活动图表显示这些活动如何相互依赖。
对于我们的例子，我们使用了以下过程。
“通过ATM从银行账户中提取资金。”
这三项涉及的活动类别（人员等）是 客户，ATM和银行。该过程从顶部的黑色起始圆开始，并在底部的同心白色/黑色停止圆结束。这些活动是圆角矩形。
活动图可以分为对象 确定哪个对象负责哪个活动的泳道。单一 每个活动都会进行转换，并将其连接到下一个活动。
转变可能 分支成两个或多个互斥的转变。Guard表达式 （ []内部）标记分支出来的转换。一个分支及其后续合并标记分支的末端作为空心钻石出现在图表中。
转变可能 叉成两个或更多个平行的活动。叉和随后从叉中出来的螺纹的连接在图中显示为实心条。
一个组件是一个代码模块。组件图是类图的物理类比。部署图显示了软件和硬件的物理配置。
以下部署图显示了涉及房地产交易的软件和硬件组件之间的关系。
物理硬件由节点组成。每个组件都属于一个节点。组件在左上角显示为带有两个选项卡的矩形。