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

时间:2024-01-17 21:03:50

对象图object diagram

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

组合结构的类图

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

一个时刻的对象图

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

包图package diagram

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

表示包的几种方式

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

包和依赖

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

  1. 包的分解。略。

实现包

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

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

何时使用包

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

部署图deployment diagrams

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

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

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

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

用例user case

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

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

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

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

用例的内容

下面是一个用例的例子。

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

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

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

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

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

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

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

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

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

用例图

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

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

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