一. 工程实践项目分析

在使用用例以及用例建模的方法之前，我简要介绍一下我的工程实践项目：

首先，我所选的是一个企业项目，题目为“物联网组网智能分析引擎”；

其次，项目描述为：通过爬取现有物联网设备组网的数据或采用现场调研的方式，运用数据挖掘方法对这些数据进行分析，为开发新型物联网设备提供参考与依据。数据分析结果可以包括成本、典型组网方式、开发周期、测试标准、交付周期、功能。

所以，能够提取出其中的关键词为：物联网；数据挖掘及可视化；Web 编程等。

下面的内容主要分为两个部分，一是叙述用例一些基本知识，二是针对于我的工程实践项目，展示用例的分析以及建模的过程。

二. 用例建模的作用与步骤

2.1 什么是用例方法？优势何在？

首先来看一下传统的需求表述方式——"软件需求规约"(Software Requirement Specification)。

传统的软件需求规约基本上采用的是功能分解的方式来描述系统功能，在这种表述方式中，系统功能被分解到各个系统功能模块中，我们通过描述细分的系统模块的功能来达到描述整个系统功能的目的。

采用这种方法来描述系统需求，非常容易混淆需求和设计的界限，这样的表述实际上已经包含了部分的设计在内。由此常常导致这样的迷惑：系统需求应该详细到何种程度？一个极端就是需求可以详细到概要设计，因为这样的需求表述既包含了外部需求也包含了内部设计。在有些公司的开发流程中，这种需求被称为"内部需求"，而对应于用户的原始要求则被称之为"外部需求"。

功能分解方法的另一个缺点是这种方法分割了各项系统功能的应用环境，从各项功能项入手，你很难了解到这些功能项是如何相互关联来实现一个完成的系统服务的。

可以发现，按照传统的需求表述方法来进行编码，最终的成品往往与用户的期望有很大偏差。

有没有一种方法，是以用户的视角来进行系统分析，又能够极大程度提升系统成品与用户需求契合度呢？

有，这就是用例分析的方法：

用例方法完全是站在用户的角度上（从系统的外部）来描述系统的功能的。在用例方法中，我们把被定义系统看作是一个黑箱，我们并不关心系统内部是如何完成它所提供的功能的。用例方法首先描述了被定义系统有哪些外部使用者（抽象成为Actor），这些使用者与被定义系统发生交互；针对每一参与者，用例方法又描述了系统为这些参与者提供了什么样的服务（抽象成为Use Case），或者说系统是如何被这些参与者使用的。所以从用例图中，我们可以得到对于被定义系统的一个总体印象。

与传统的功能分解方式相比，用例方法完全是从外部来定义系统的功能，它把需求与设计完全分离开来。在面向对象的分析设计方法中，用例模型主要用于表述系统的功能性需求，系统的设计主要由对象模型来记录表述。另外，用例定义了系统功能的使用环境与上下文，每一个用例描述的是一个完整的系统服务。用例方法比传统的SRS更易于被用户所理解，它可以作为开发人员和用户之间针对系统需求进行沟通的一个有效手段。

那么，明确了用例方法的好处，该如何建立一个可靠的用例模型呢？

2.2 建立用户模型

使用用例的方法来描述系统的功能需求的过程就是用例建模，用例模型主要包括以下两部分内容：

一、用例图(Use Case Diagram)

　　确定系统中所包含的参与者、用例和两者之间的对应关系，用例图描述的是关于系统功能的一个概述。

二、用例规约(Use Case Specification)

　　针对每一个用例都应该有一个用例规约文档与之相对应，该文档描述用例的细节内容。

在用例建模的过程中，具体的步聚是：先找出参与者，再根据参与者确定每个参与者相关的用例，最后再细化每一个用例的用例规约。

2.2.1 寻找参与者

所谓的参与者是指所有存在于系统外部并与系统进行交互的人或其他系统。通俗地讲，参与者就是我们所要定义系统的使用者。寻找参与者可以从以下问题入手：

系统开发完成之后，有哪些人会使用这个系统？
系统需要从哪些人或其他系统中获得数据？
系统会为哪些人或其他系统提供数据？
系统会与哪些其他系统相关联？
系统是由谁来维护和管理的？

这些问题有助于我们抽象出系统的参与者。

而对于本项目而言，回答这些问题也能够帮助我更快更好地找到系统的参与者：

普通用户使用系统所提供的功能与服务；

管理员用户使用后台系统进行系统信息的更新和维护。

2.2.2 确定用例

找到参与者之后，我们就可以根据参与者来确定系统的用例，主要是看各参与者需要系统提供什么样的服务，或者说参与者是如何使用系统的。寻找用例可以从以下问题入手（针对每一个参与者）：

参与者为什么要使用该系统？
参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话，参与者又是如何来完成这些操作的？
参与者是否会将外部的某些事件通知给该系统？
系统是否会将内部的某些事件通知该参与者？

在用例的抽取过程中，必须注意：用例必须是由某一个主角触发而产生的活动，即每个用例至少应该涉及一个主角。如果存在与主角不进行交互的用例，就可以考虑将其并入其他用例；或者是检查该用例相对应的参与者是否被遗漏，如果是，则补上该参与者。反之，每个参与者也必须至少涉及到一个用例，如果发现有不与任何用例相关联的参与者存在，就应该考虑该参与者是如何与系统发生对话的，或者由参与者确定一个新的用例，或者该参与者是一个多余的模型元素，应该将其删除。

可视化建模的主要目的之一就是要增强团队的沟通，用例模型必须是易于理解的。用例建模往往是一个团队开发的过程，系统分析员在建模过程中必须注意参与者和用例的名称应该符合一定的命名约定，这样整个用例模型才能够符合一定的风格。如参与者的名称一般都是名词，用例名称一般都是动宾词组等。

对于同一个系统，不同的人对于参与者和用例都可能有不同的抽象结果，因而得到不同的用例模型。我们需要在多个用例模型方案中选择一种"最佳"（或"较佳"）的结果，一个好的用例模型应该能够容易被不同的涉众所理解，并且不同的涉众对于同一用例模型的理解应该是一致的。

2.2.3 描述用例规约

应该避免这样一种误解――认为由参与者和用例构成的用例图就是用例模型，用例图只是在总体上大致描述了系统所能提供的各种服务，让我们对于系统的功能有一个总体的认识。除此之外，我们还需要描述每一个有例的详细信息，这些信息包含在用例规约中，用例模型是由用例图和每一个用例的详细描述――用例规约所组成的。RUP中提供了用例规约的模板，每一个用例的用例规约都应该包含以下内容：

简要说明 (Brief Description)
简要介绍该用例的作用和目的。
事件流 (Flow of Event)
包括基本流和备选流，事件流应该表示出所有的场景。
用例场景 (Use-Case Scenario)
包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的。
特殊需求 (Special Requirement)
描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）。
前置条件 (Pre-Condition)
执行用例之前系统必须所处的状态。
后置条件 (Post-Condition)
用例执行完毕后系统可能处于的一组状态。

用例规约基本上是用文本方式来表述的，为了更加清晰地描述事件流，也可以选择使用状态图、活动图或序列图来辅助说明。只要有助于表达的简洁明了，就可以在用例中任意粘贴用户界面和流程的图形化显示方式，或是其他图形。如活动图有助于描述复杂的决策流程，状态转移图有助于描述与状态相关的系统行为，序列图适合于描述基于时间顺序的消息传递。