UML精粹4 - 对象图，包图，部署图，用例

对象图object diagram

对象图是某个时间点上的对象在系统中的快照，也经常被称为实例图。一般在展示组合对象结构时比较有用。例如

组合结构的类图

一个时刻的对象图

包图package diagram

包是一种分组构造，它允许你选择UML里的任何构造，把它的元素组织在一起，成为更高级别的单元。包最常见的用法是组织“类”，但也可以用来组织其它元素。如何选择哪些类放在哪个包里？两个有用的原则是：共同封闭原则和共同复用原则。

表示包的几种方式

包和依赖

包的分解。略。

实现包

一个包定义了被其它包实现的接口。

何时使用包

包图对大规模系统及其有用。通过包图可以获得系统主要元素之间的关系，这些图形和常见的编程结构对应的很好。包图代表编译时的分组机制，要展示对象运行时如何组合，应使用组合结构图。

部署图deployment diagrams

部署图展示系统的物理布局，揭示哪个软件运行在哪个硬件上。下面是一个部署图的例子。

节点node是上面能驻留一些软件的环境。设备device是硬件。执行环境（execution environment）是软件，它本身作为软件或包含其他软件，比如操作系统或容器进程。节点包含工件artifact，工件是软件的物理显现，通常是文件。使用标记值（tagged value）在图上展示一些感兴趣的信息。

通常会有多个物理节点执行同一个逻辑任务，可以使用多个节点框，也可以使用标记值数值展示。如图中使用“number deployed = 3”表示部署了3台Web服务器。

用例user case

经常使用用例来捕获需求。场景scenario是描述用户和系统之间交互的步骤序列。比如，我们有一个基于web的在线商店，可以有一个这样的“购买产品”场景：

顾客浏览目录并添加想要的条目到购物车。当顾客想要付款时，顾客提供配送和付款信息并确认购买。系统检查付款信息（如果使用信用卡支付需要确认授权，在线支付是否成功），随后发送购买确认信息。

这个场景描述了一件可能发生的事情。然而，支付可能失败，这是另一个场景；注册用户可能已经设置了默认配送和付款信息，这是第三个场景。这些场景不同，但又相似。它们都围绕着一个共同的目标：购买产品。用例是通过共同用户目标绑在一起的场景集合。

在用例中，用户叫做执行者actor。执行者可以是人，也可以是另一个系统。用角色role来称呼用户其实更贴切。

用例的内容

下面是一个用例的例子。

一开始，挑选一个场景作为主成功场景（main success scenario），再书写其它场景作为扩展（extension），描述主场景上的变化。

每个用例有一个主执行者，它调用系统来交付一个服务。主执行者是带有目标的，用例会尝试满足它的目标。主执行者通常是用例的引发者，用例中和系统通信的其它执行者称为辅助执行者。

用例的每一步力求简洁，清晰展示谁执行该步骤。步骤应该展现执行者的意图，而不是如何做的细节。

用例中的扩展命名了一个条件，这个条件导致了和主成功场景MSS不同的交互，并陈述了差异是什么。扩展使用多级目录格式编号，例如3a是对MSS第3步的扩展。

用例中的复杂步骤或者重复出现的步骤可以变成一个用例，第一个用例可以包含include第二个用例。

在用例中可以添加一些其他的共同信息。

前置条件pre-condition，描述在系统开始之前，系统应该确保为真的东西。
保证guarantee，描述用例结束时系统会确保的东西。
触发器trigger，触发用例开始的事件。

要努力保持用例的简短和易读。高风险、重要的场景保留足够的细节，其它的场景不用写下所有细节，可以通过口头沟通来弥补。

用例图

将精力集中在用例的文本内容，将用例图作为用例集的图形目录。

用例的级别。一般将用例分为系统用例和业务用例。系统用例是和软件的交互，业务用例是讨论业务如何响应顾客或事件。Cockburn在《编写有效用例》中将用例分为sea-level，fish-level和kite-level。
用例和特性（或故事）。许多方法使用系统特性（极限编程把它们叫做用户故事）来帮助描述需求。特性和用例是什么关系呢？特性是系统提供的功能，可以是一个用例，用例中的场景，用例中的步骤或者一些行为变体。通常我们先开发用例，然后得到特性列表。通常，特性比用例有更细的粒度。
何时使用用例。用例是帮助理解系统功能需求的有价值的工具。在项目早期，应该粗略地描述每个用例，然后在开发该用例之前再去做更详细的版本。
更多资料。Cockburn的《编写有效用例》