【文章摘要】用例是统一建模语言（UML）的核心概念之一，一个用例就是用户为达到某种目的与系统之间进行的一次典型交互。

1.基本概念和方法

1.1用例图

用例是统一建模语言（UML）的核心概念之一，一个用例就是用户为达到某种目的与系统之间进行的一次典型交互。用例主要用于捕获系统功能性需求，它包括参与者（Actor）、用例（Use Case）、关联（Association）三个模型元素：

参与者是位于系统之外与系统发生交互的人或其他系统，在实际的用例模型中它往往模拟某个用户角色。

用例表示系统对外提供的服务或功能，它定义了系统是如何被参与者所使用的，每个用例都是对系统行为的动态描述。

关联表示了参与者与用例之间的对应关系，它描述了参与者如何使用系统提供的用例和用例间的依赖调用关系。在用例之间存在着依赖（Dependency）、包含（Include）、扩展（Extend）、泛化(Generalization)四种常用的关联关系。

用例捕获需求所搭建的模型称为用例模型，它由用例及用例规约两部分组成，其中用例规约是对用例附加的文本性注释。当一个用例在描述大粒度需求时，这种用例规约往往是必需的。图1-1中所示为用例图描述的电话呼叫系统，图中包括用户和运营商两个角色，设备接入、呼叫控制、计费三个用例，方框表示系统边界，箭头表示角色与用例间的调用关系。该图清晰明确地表达了电话呼叫系统的总体功能及模块划分，较好地表达了系统功能需求。

图 1 1用例图描述的电话呼叫系统

在搭建用例模型图时往往遵循如下步骤：首先确定参与者，考虑每个参与者期望系统提供的功能；然后对这些功能进行抽象，用领域术语进行描述，构建相应的用例；最后通过各种关联关系将参与者与用例连接起来，通过用例规约对用例进行细化描述。

由于用例建模是以用户为中心，屏蔽了系统内部细节，仅靠静态的用例规约文本不能体现系统内部模型间的动态交互，所以引入UML顺序图来解决这一问题。

1.2顺序图

UML顺序图展示了一种交互，由一组对象和它们之间的关系组成，着重体现对象间传递消息的时间顺序。

顺序图采用两个轴，水平轴表示参与交互的对象，垂直轴表示时间。顺序图中的对象用带有垂直虚线的矩形框表示，矩形框内标有类名、对象名或角色名。垂直虚线称为对象的生命线，代表在对象之间的交互作用中该对象的生命周期。对象间的通信消息通过对象生命线之间的箭头表示，箭头的形状表明了消息的类型是发送还是返回。消息按发生的时间顺序从上到下排列，每个消息旁边标有消息名，也可以加上参数。图1-2所示为上节中电话呼叫系统的顺序图描述，其中包括主叫、运营商、被叫三个对象，三者间共有六条消息交互，清晰地表达了电话呼叫系统的执行逻辑。

图 1 2顺序图描述的电话呼叫系统

由于电信业务采用“事件驱动、异步执行”机制，业务执行过程中有大量的消息交互，而以顺序图描述的电信业务恰能反映其动态交互特征，将顺序图描述的动态交互信息与用例规约描述的静态属性信息结合，即可完整得描述一个业务的综合特性。

2.领域需求建模分析

本节从通用的软件工程需求分析入手，借助需求工程理论获取通用需求，然后将此类通用需求转化为电信业务领域需求。

2.1软件工程通用需求建模分析

在软件开发需求分析阶段存在三个主要困难：首先是客户与开发人员交流困难，由于二者不同的知识背景及所处的行业，导致在描述系统需求时表达不一致甚至产生歧义；其次是需求信息描述不规范不一致，客户与开发人员都有各自的术语及表达习惯，同一种需求可能会产生若干种表达；最后是随着项目的深入，需求的变化在所难免，而这种变化往往不能及时反映到实际的开发中，导致需求与实现的脱节。

基于上述需求分析的诸多问题而产生了“需求工程”理论，其主要任务是：探索行之有效的需求获取方法；实现“用户主导、面向领域”的需求建模过程；形成促进协同工作和逐步优化的需求规格；构建真实可信的需求验证理论、方法和手段；为实现科学的需求管理奠定理论和方法基础。需求工程理论包括以下五个方面：

1、需求获取：通过与用户交流、对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求；

2、需求建模：为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义；

3、形成需求规格：生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约；

4、需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性；

5、需求管理：支持系统的需求演进，如需求变化和可跟踪性问题等。

需求分析作为软件开发的第一个也是最重要的步骤，它所描述的需求包括功能性需求（FR）及非功能性需求（NFR）两个方面。功能性需求旨在描述软件开发的目的，通常比较明确和具体，较容易通过用例的方式进行捕获和描述，它决定了软件成品的成败；而非功能性需求旨在描述软件成品的质量指标，通常比较抽象且主观成分较多，要准确直观地描述非功能性需求并非易事，通常都以自然语言形式进行描述，它从可用性、可维护性、健壮性、可移植性、安全性等方面影响着软件成品的生命周期。

2.2电信业务领域需求建模分析

电信领域的非功能性需求用于描述电信业务对通话质量、带宽、实时性等QoS的需求，功能性需求则包括了电信业务管理功能、底层网络能力、业务执行环境的需求等。以上述分析得到的通用需求为基础，针对电信业务自身特点，电信业务领域需求建模步骤如下：

1、需求获取：业务设计人员与业务用户进行充分交流，全面、精确地获取用户需求，双方形成明确、一致的业务概念；

2、需求建模：

（1）、为第1步中获取的用户需求构建用例项，并将这部分用例归入“用户需求”类中，对于描述不精确的用例项以文字形式进一步描述；

（2）、业务开发人员获取上述“用户需求”类中的用例，针对每个用户需求用例开发相应的“业务提供商”用例来满足其需求，并将其归入“业务提供商需求”类中；

（3）、业务运行部署人员获取“业务提供商需求”类中的用例，针对每项功能开发相应的底层支撑功能用例以完成业务功能，相应的用例归入“网络运营商需求”类中。

3、形式化需求描述：严格按照UML用例图的标准搭建业务的功能视图，并配以相应的文字描述；复杂用例通过子用例图的形式进一步描述；业务整体的运行逻辑通过顺序图进行描述。由于采用了UML这一业界统一的建模标准，使得建模结果不会产生二义性，且重用性较好；

4、需求验证：将文本形式的需求分析规约（初期的需求分析文档细化后得到）、需求建模阶段得到的用例图和顺序图分别提供给用户、业务设计人员、业务开发人员、业务运行部署人员，形成一致意见后得到最终的需求分析可执行文档，该文档可作为后期设计开发的依据；

5、需求管理：开发团队时刻关注用户的需求是否改变，一旦有需求变更则需要循环执行上述步骤，以确定开发出的产品精确无误得交付给用户。

由于电信业务对非功能性需求的侧重不同，本文所考虑的非功能性需求如下：

1、稳定性：由于电信业务一旦部署往往需要运行较长时间，对业务的稳定性要求较高；

2、容错性：一旦发生不可预知的错误，如访问量激增、物理设备错误等，应该有容错机制支撑业务继续运行；

3、扩展性：由于电信业务更新换代较快，要求业务较容易在原有服务器上扩展总署；

4、时延：随着用户对业务体验要求的提高，带宽成为衡量业务指标的一个重要因素。

由于本文采用UML用例建模这一业界建模标准，可以有效获取并形式化描述需求，同时模块化描述的需求在验证及管理阶段也较易沟通理解及改动，提高了需求分析的效率。

基于上述讨论，我们得到了软件工程领域的通用需求（功能性及非功能性需求），下面我们将关心如何将通用需求映射为领域需求。

3.领域需求建模设计与实现

在MDA建模思想的指引下，软件开发人员创建了各自的建模语言及工具用于支持不同领域的系统建模，不同领域的建模语言由于各自差异而导致交互及移植困难，从而迫切需要一种针对建模语言和工具的规范，这就是OMG于1997年通过的元对象设施，即MOF标准（Meta Object Facility）。MOF是一个庞大的规范，其核心是提供一个开放的建模框架，可以通过继承、组合和实例化机制实现组件的扩展，从而定义功能更加强大的模型。MOF基于传统的经典四层元数据模型框架将模型的抽象过程分为以下四个层次：

图 3 1 MOF四层元数据架构

本文所讨论的电信业务领域需求建模就是在遵循MOF规范的基础上完成的，首先对通用电信业务能力进行抽取、归类，得到通用的电信业务能力集（M3层），然后将该能力集抽象为概念元模型（M2层），最后在Borland Together 2006环境下设计生成UML Profile用例元模型（M1层）。

3.1电信业务能力分析

现有第三代移动通信（3G）除了提供传统的语音会话业务外，还提供丰富多彩的多媒体业务、数据通信类业务，参照3GPP和ETSI的业务能力分类，从下层的接口技术中抽象出支持各种业务的能力集，包括呼叫类、消息类、位置服务类、用户交互类、会话控制类等，以及相应的一些通用服务类,如图3-2所示。

图 3 2电信业务能力集

呼叫类的业务特征不仅包括双方呼叫，也包括多方呼叫和多媒体呼叫；消息类包括短消息、多媒体消息和及时消息；位置服务提供立即定位服务、紧急定位服务以及根据时间或地点的触发定位服务；用户交互类用于获取用户输入、对用户放音、监控用户状态等；会话控制类用于建立及解除会话逻辑、控制业务逻辑跳转、监控业务状态等；通用服务类是各个业务都可以使用的一些逻辑功能如数据库操作、逻辑处理、计费、鉴权认证等。

3.2概念元模型设计

软件系统建模是一种概念性的建模方法，首先对现实世界中事物进行抽象，得到待建系统功能及架构的感性认识（M3层），这些感性认识往往不成体系且缺乏形式化描述；将这些感性认识进一步进行归纳汇总，并加以形式化描述，即形成概念模型（M2层）。概念模型是领域模型的总体视图，可以通过UML类图或结构图进行表示。

为了确保电信业务需求建模信息的完备性和准确性，本文采用分层次、多视点的需求捕获方法。电信业务包括业务用户（Service User）、业务提供商（Service Provider）、网络运营商（Network Operator）三个参与者：

图 3 3视点分离的需求捕获方法

1、业务用户主要关注业务所提供的功能（或服务），业务的使用方式，业务的接入方式、业务的计费模式，终端的能力要求等，用户并不关心业务是如何实现的；

2、网络运营商主要负责业务的生命周期管理，业务的部署对下层网络（如接入网、核心网、业务网）的要求，计费策略，与SP的分成结算模式，业务的目标用户群，业务数据和用户数据的维护管理，业务的接入控制和授权、业务的订阅等；

3、对于业务提供商而言，则更关注该业务的技术实现细节，与运营商的网络通信接口（包括应用接口、网管接口）、业务的管理方式（包括计费、结算、业务的接入、服务等级协定等），以及与其他内容提供商和服务提供商的商务模式（Business Pattern），该业务的部署环境（包括软硬件），业务所属的类型和具有的业务特征、业务流程等。

从三个业务角色的视点出发分别对业务能力进行分类，设计得到的电信业务需求概念元模型类图如下：

图 3 4通用能力类概念元模型设计

图 3 5网络支撑能力类概念元模型设计

图 3 6业务能力类概念元模型设计

概念元模型设计完毕，接下来将概念元模型（M2层）转换为可用的UML用例模型（M1层）。

3.3UML Profile用例元模型实现

从概念模型（M2层）到UML Profile模型（M1层）就是把半形式化描述的领域视图转换为建模工具中形式化描述的UML视图，是电信业务需求建模的最基本要求，所生成的UML Profile元模型信息的完备性、准确性直接关系到需求建模结果的优劣。

本文以Borland Together 2006为建模环境，采用扩展UML用例元模型的方式，以4.2节所设计的通用能力类概念元模型为例扩展用例Profile如下：

图 3 7通用能力用例扩展

非功能性需求的用例扩展与功能性需求的扩展方法类似，各个功能性需求模型的性能指标将通过这些非功能性需求模型来指示，具体反映为用例图中用例规约的文字描述。

4.需求建模实例及验证

本部分以“基于位置的短信发起的三方呼叫业务”为例，利用上述建立的元模型集合，搭建该业务的需求模型。

4.1用例描述的业务需求模型

“基于位置的短信发起的三方呼叫业务”由主叫（333444）向SP提供的服务接入码（888）发送短消息而触发，消息内容包括用户名、密码、被叫（333555）；然后以第三方（虚拟网络端）呼叫主叫，待主叫接听后对其放提示音“是否收听广告”，得到主叫的肯定后按照主叫所在的地理位置播放广告商提供的广告；待主叫广告接听完毕后，再接通被叫，实现二者通话，并对主叫实行费率优惠。该业务由于既实现了业务运营商的广告收益，又实现了广告商的低费率宣传，用户也得到了合理的优惠，所以具有广阔的应用前景。

按照上文描述的业务场景，利用上述搭建的UML Profile用例元模型，搭建业务需求模型如下：

图 4 1用例描述的需求模型

上图以视点分离的原则，分别为三个业务角色搭建需求用例，明确清晰地描述了该业务的功能需求。然而由于用例图“以用户为中心，完全屏蔽内部细节”的特点，导致业务逻辑表达不清晰，需要进一步用顺序图进行动态描述。

4.2顺序图描述的业务逻辑

顺序图可以很好地描述不同对象间消息的动态交互，以4.1节用例图描述的业务为例，其顺序图描述的业务逻辑如下：

图 4 2顺序图描述的业务逻辑

顺序图描述的业务逻辑很好地弥补了用例需求视图“细节缺失”的弱点，所表达业务逻辑也清晰完整，全面描述了业务执行中各对象的动态交互消息。

4.3需求建模验证

从本节中示例业务的需求建模结果可以看出，本建模方式描述的电信业务领域需求具有以下优点：

1、由于采用了UML用例图和顺序图这一业界统一的标准，不同领域开发人员可以“无歧义”地交流；

2、图形描述的需求较之文本更加清晰简洁，需求变动时可以通过修改元模型进行统一更新；

3、按照电信业务的特点抽取并建立的需求模型，更加符合电信业务自身特点，描述电信业务需求更加精确。

5.总结

由于目前MDA方式开发电信业务中缺乏对CIM层的需求建模，本文在需求工程理论的基础上以用例图的方式进行需求捕获，并对业务功能进行高层次的抽象描述；为了解决抽象粒度过大及用例图在描述业务逻辑方面的缺陷，又引入了顺序图对业务逻辑进行描述，从而本建模方法既可以获取静态功能需求也可以描述业务执行中各功能实体的动态交互，关注业务整体需求的同时也考虑了细节描述。由于UML不是形式化的建模语言,缺乏精确的语义描述，所以今后需要引入对象约束语言（OCL Object Constraint Language）对模型间的对应关系、静态属性、动态行为等进行约束。