需求建模方法在电信支撑系统研究中的应用探讨

2010-08-09朱明英王海霞张金娟

电信科学 2010年11期

关键词：用例面向对象对象

朱明英，邢豫，王海霞，张金娟

(中国电信股份有限公司广东研究院广州510630)

1 引言

1.1 需求定义

需求是支撑系统建设的起点。从广义的分析来看，需求来源于客户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。业界对“需求”的主流定义主要分两类。

（1）IEEE定义

IEEE的软件工程标准词汇表（1990年）中将需求定义为：

A.用户解决问题或达到目标所需的条件或能力（capability）；

B.系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力；

C.一种反映上面A或B所描述的条件或能力的文档说明。

IEEE公布的定义既体现了用户对需求的看法（系统的外部行为），又代表了开发人员的观点（一些深层的特性）。

（2）其他定义

著名软件工程专家Jones于1994年给出这样的定义：需求是“用户所需要的并能触发一个程序或系统开发工作的说明”。需求分析专家Alan Davis（1993年）对IEEE的需求概念进行了拓展：“需求是从系统外部能发现系统所具有的满足于用户的特点、功能及属性等”。这些定义强调的是产品是什么样的，而并非产品是怎样设计、构造的。Sommerville and Sawyer（1997年）认为：需求是对应该实现什么功能的说明。它描述了系统的行为、特征或属性，是在开发过程中对系统的约束。

综上所述，业界并没有一个清晰、毫无二义性的“需求”术语存在，真正的“需求”实际上在人们的脑海中。任何文档形式的需求（如需求规格说明）仅是一个模型，一种叙述，以确保所有项目风险承担者在描述需求的名词的理解上达成共识。

1.2 需求的重要性分析

在系统开发项目中，好的需求是至关重要的。Glass R提出：“项目需求无疑是在软件项目前期造成麻烦的一个最大原因。一个又一个的研究已经发现，当项目失败时，需求问题通常正是核心问题。”Standish集团公司的研究报告也称，项目失败的10个重要原因中有5个与需求相关，其权重占整个失败因素的51.7%。这5个需求原因主要有：不完整的需求、缺乏用户参与、不切实际的客户期望、需求变更频繁、提供了不必要的功能。因此，在软件开发过程中，必须及早、有效地发现和解决与需求相关的问题。

需求分析是制定需求的一种有效方法。需求分析实际上是业务分析，也就是选择一种业务导向的线索将零散的需求串起来，形成一个体系完整、内容清晰的框架，以指导后续的设计、开发工作。需求分析的任务是先分解，再提炼，在这个过程中消除矛盾。建模是需求分析的主要手段，通过简化、强调来帮助需求分析人员理清思路，达成共识。

2 主流需求建模方法分析

需求建模是需求分析中的重要工作。需求建模是根据待开发软件系统的需求，利用某种建模方法来建立该系统的逻辑模型，以帮助软件开发人员检测软件需求的一致性、完全性、二义性和错误等。

需求建模方法的要素有以下两方面。

（1）提供描述手段

需求建模方法应该规定描述模型的手段，包括要记录什么内容及用什么符号来表达。在目前的需求建模方法中，主要使用自然语言、图形符号和形式语言作为需求模型的描述手段。

（2）提供基本步骤

需求建模方法需要规定基本的实施步骤，确定每一步的目的，要产生什么样的结果，每步中要注意哪些概念以及完成该步工作需要掌握哪些必要的信息和哪些辅助性的工作等。

根据需求建模方法关注重点的差异，业界主要将需求建模方法分为两大类：面向过程的需求建模方法和面向对象的需求建模方法。

2.1 面向过程的需求建模方法

面向过程的需求建模通常是采用结构化的分析方法（SA）。SA方法是由美国Yourdon公司和密歇根大学在开发ISDOS工具系统时提出的，是20世纪70年代中期以来比较流行和普及的需求分析技术之一。SA方法主要用于数据处理，用于分析系统的功能，是一种直接根据数据流划分功能层次的分析方法。

SA方法描述手段由以下3部分组成。

·一套分层的数据流图，主要说明系统由哪些部分组成以及各部分之间的联系。

·一本词典，对数据流图中出现的每个元素提供详细的说明。

·其他补充材料：具体的补充和修改文档的说明。

为简单起见，将现实中已存在的人工系统称为当前系统，把待开发的软件系统称为目标系统。SA方法的分析步骤如下。

·理解和分析当前的现实环境，以获得当前系统的具体模型。具体模型必须忠实地反映当前系统的实际情况。

·建立当前系统的逻辑模型，从系统的具体模型中抽象出当前系统的逻辑模型，当前系统的逻辑模型应反映当前系统必须满足的性质，即当前系统“做什么”。此步的作用在于除去具体模型中非本质因素或一些具体因素。

·建立目标系统的逻辑模型。此步的主要工作是分析目标系统与当前系统在逻辑模型的差别，并建立目标系统的逻辑模型。

·进一步完善目标系统的逻辑模型，包括对尚未说明的处理细节的完善，如：出错处理、系统的启动和结束方式；某些需要的输入输出格式或用户界面的说明；增加性能需求和其他的一些约束限制等。

2.2 面向对象需求建模方法

面向对象需求建模方法是面向对象的开发方法在需求建模过程中的一种应用，它属于软件工程的范畴。面向对象的需求建模方法主要有：OMT方法、Booch方法、OOSE方法、UM（unified method）方法等。

面向对象的需求建模方法主要使用一些描述模型的图形工具来进行建模。在市场上已有一些公司，如Rationa1、Cayenne、Platinum等开始提供商品化的建模工具，即通常所谓的Case工具，使得建模过程实现了一定的自动化和标准化，并逐步走向实用。

面向对象需求建模方法的建模步骤如下介绍。

（1）建立对象模型

建立对象模型是在分析获得的所有需求信息的基础上，首先确定对象和类以及它们之间的静态关联。然后给类和关联增添属性，并利用类和对象的继承关系等，对初步建立的对象模型进行修改和完善。建立对象模型主要包括分析需求信息、确定类与对象、确定实体间静态关系、划分主题、确定属性、简化对象模型等6个环节。对象模型的建立过程是一个反复修改、逐渐完善的过程。在建立起对象模型后，有必要对该模型进行修改，以使对象模型更加简单和清晰。

（2）构建动态模型

动态模型用于表达类或对象间所发生的动态时序关系。构建动态模型主要包括编写场景、设计用户界面、建立序列图、构建动态模型等4个环节。

（3）构建功能模型

功能模型主要表达系统内部数据流的传递和处理的过程。

（4）定义类和对象中的操作

确定类和对象中的操作主要取决于该类和对象在问题中的实际作用。

2.3 需求建模方法分析

从关注重点和建模要点两方面进行分析，面向过程的需求建模方法和面向对象的需求建模方法的差异见表1。

3 需求建模的应用探讨

根据上面对需求建模方法的分析，在实际工作中，需要选取适当的需求建模方法，按需要的样式对系统进行可视化，给出一个指导系统构造的模板以及将建模的内容进行文档化。

在需求建模的实际应用中，提取了关键的几个建模环节进行分析。这些环节主要有以下两个。

·业务建模:业务主题域分析、上下文关系分析、业

务流程建模等。

·系统建模：系统用例建模、界面建模等。

下面对需求建模的几个关键点进行举例说明。

3.1 业务建模

业务建模的第一步是对目标系统的主题域进行分析。TMF(电信管理论坛)所提出的eTOM（扩展的电信运营模型）中，对主题域进行了划分，如图1所示。

表1 两种需求建模方法的比较

根据中国电信提出的CTG-MBOSS体系，其功能和系统架构由管理支撑系统（MSS）、业务支撑系统（BSS）、运营支撑系统（OSS）和企业数据模型（EDA）等部分构成。其中,业务支撑系统主要包含CRM和计费两大核心主题功能域。在中国电信的CTG-MBOSS规范中明确了CRM系统在eTOM中的定位，即CRM系统包含eTOM模型中的下列模块；

·客户关系管理中的运营支持与就绪、服务开通与服务保障和部分的服务计费功能(收费前端)；

·供应商/合作伙伴关系管理中的运营支持与就绪、服务开通和服务保障部分；

·营销与提供管理中产品生命周期管理部分。

确定了CRM主题域之后，就可以确定CRM系统的上下文关系，划分出CRM系统与其他系统的功能边界，确定CRM系统和其他系统的交互关系，进而设计CRM系统和其他系统之间的接口方案。

对关键业务进行业务流程建模，是业务建模的重要环节之一。下面以固定电话类产品的新装业务为例，采用UML序列图建模工具，建立固定电话新装业务的流程，如图2所示。

3.2 系统建模

系统建模主要包括界面建模和系统用例建模。界面建模主要是对信息在界面表达方式以及系统与用户交互方式的建模。界面建模对于用户及开发团队来讲更直观、更容易理解。业界有很多专用工具可以用来进行界面建模，如Balsamiq mockups、Pencil project、Axure RP pro、DENIM等。

系统用例建模主要包括系统用例以及用例描述。系统用例建模是根据业务用例建模结果，分离出与系统相关的业务角色，即系统角色。对系统角色与其所使用的功能进行关联，就可以得出系统用例模型。在用例模型的基础上，对每个系统用例进行详细的用例描述。下面针对固定电话新装业务流程，完成系统用例建模，用例描述见表2。

4 结束语

本文通过对业界两种主流需求建模方法的分析，根据电信支撑系统的特点，提取了适合于在电信支撑系统中进行需求建模的关键要素，并给出了在电信支撑系统中进行需求建模的具体步骤，并列举了实际需求分析工作中的应用范例。通过需求建模方法在支撑系统需求分析中的广泛应用，提升了支撑系统的需求分析水平，为系统的快速开发提供了指导意义。