基于业务建模的软件产品系统分析过程与特点分析

开篇：润墨网以专业的文秘视角，为您筛选了一篇基于业务建模的软件产品系统分析过程与特点分析范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

摘 要：系统分析的方法多种多样，本文介绍了一种产品系统分析过程，这个过程使用了实体与行为分离的业务建模的思想来完成系统的分析，在文章中仔细分析了每个步骤怎么样做，输出入什么样的内容，得到什么样的输出，经过这样的分析过程后，使系统最核心的业务被固化下来，达到平台无关、具备更强的扩展性，每个领域内部关系及外部关系、系统中的每一个元素都得到集中的管理，对系统的理解不易产生歧义。本文所研究的系统分析过程具有很强的操作性，具备较高推广价值。

关键词：业务建模；领域模型；系统分析过程；UML模型

中图分类号：TP31 文献标识码：A

1引言

软件系统分析是一个产品实现的开端，也是产品实现最重要的关键点，其主要任务是将所有的需求文档汇总到一起， 从业务全过程的角度，对组织内部整体管理状况和信息处理过程进行分析。

本文完整的描述基于业务建模的系统分析过程，并分析其在可操作性、扩展性、稳定性、系统性等方面的特点。在本文的最后对其使用的效果进行描述。

2 相关定义

业务建模：以软件模型方式描述业务所涉及的对象和要素、以及它们的属性、行为和彼此关系，业务建模强调以体系的方式来理解、设计和构架软件系统。

业务用例模型：描述一个业务的流程以及它们与外部各方之间的交互。

业务实体：在业务用例中所使用与处理的任何事物。

业务行为：对业务实体所进行的操作的抽象。

实体状态：业务实体在系统各用例中属性的值。

领域模型：描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。本文中的领域模型将对象模型分成实体与行为两部分来进行描述。

UML模型：用UML（The OMG's Unified Modeling LanguageTM （UMLR ）描述系统的模型。本文的业务建模采用UML 1.4的标准对业务用例（用例图），领域模型（类图），业务流程（状态图）进行描述。

3 概述

当前常用的系统分析方法有：面向过程的方法（主要从系统如何将输入转换为输出的角度来分析系统）、面向数据的方法（强调用数据结构表示系统状态）、面向控制的方法（强调同步、死锁、排斥、并发及过程的激活和去活）、面向对象的方法（基于系统的对象类及类之间的交互来进行分析），这些分析方法各有特色，在特定的场景下，能表现出各自的优势。但对于产品的研发，它的不足就暴露了出来，面向过程的方法，往往只见树木不见森林在需求的相关性、扩展性的表现不足，面向数据的方法忽略了业务过程，面向控制的方法对控制对象的描述不够详细，面向对象的方法同样的需求不同的分析过程对分析结果差异大，分析质量得不到保证。

对于模块多、业务过程复杂的产品系统分析我们需要一个可规范化、考虑全面、相对稳定性，阶段独立的分析方法。

基于业务建模的系统分析方法，是以面向对象的分析方法为指导思想，并规范化过程及输入输出、以UML图为表现形式建立业务模型，逐步全面的完成系统分析。

其分析过程如图1

4系统分析过程

4.1 输入文档

对业务需求文档的规范性要求，是一个很好的开始。按照分析设计人员的要求，结合对市场的分析，需求人员给出了功能规划及业务需求。

1产品功能规划及主体功能及优先级列表

经过对市场的分析及竞争产品的分析，初步做出了产品功能的规划，并给出来产品主要的模块及模块间的关系。

2系统主要业务需求及初步界面

业务需求文档一定要体现以下几方面的内容：

业务模块中英文、功能名称中英文、优先级、编号、业务描述、参与角色中英文、前置条件、基本事件流（区分用户及系统）、异常事件流、业务规则、后置需求、特殊需求、扩展点、补充说明（对操作对象的属性、规则说明）等信息。

3非功能需求描述

本文着重进行业务建模，对非功能需求只做为辅助验证，本处不进行描述。

4.2 模块级需求分析

1 找名词，抽象业务实体

将前面一节提供的一个用例的业务需求文档进行梳理，将实体从业务需求文档中找出来，一边找一边填写表一，直至写完所有的名词，并做初步判断是否由本模块处理，如下表一是在用户管理的用户新增用例中名词分析得到用户实体。

2 找动词，分析业务行为

将前面一节提供的一个用例的业务需求文档与初步分析出来的实体共同梳理，将实体被如何操作（行为）从业务需求文档中找出来，一边找一边填写表二，直至写完所有的名词及该名词被怎么样操作（行为），如下表，将与实体有关的动词进行分析，抽象为业务行为

3 完善模块业务用例并进行合并

这一步骤的核心内容是依托实体分析表及实体行为分析表，用UML的类图完成模块内实体间及实体自身的关系，以实体为核心完成对实体操作的方法类，原则上一个实体对应一个实体行为类。

模块分析人员将所负责的模块经过分析，补充完整用例，并把业务实体在整个模块中的属性变化用业务流程图描绘出来。将业务实体、业务行为进行合并，生成本模块的需求分析词汇表（用例词汇表、实体词汇表）、业务用例模型、业务流程图。

在对模块的分析过程中，会发现一些需求未明确或没有考虑到的用例，在合并的时候将他们补充完整，并把各分散的用例集中起来。

实体间的关系及实体能提供的操作共同形成一个完整的领域模型。

对模块分析汇总还需要将实体的属性在模块中变化的过程用状态图表现出来，以分析实体的数据流向。

4 模块需求分析评审

通过以界面为主线，业务实体与行为的结合，一方面验证业务用例的是否都得到实现，另一方面核对与其他模块的实体、行为是否完整。

4.3 对业务需求的总体分析

1 汇总各模块的实体、行为更新业务实体模型及实体状态图。

系统中的实体往往会在多个模型中作，通过汇总，补充了实体的行为、完善领域模型，实体在系统中各属性状态也被完整的用状态图表现出来。

2汇总业务用例重新划分模块边界及模块间的关系

通过对用例模型的汇总划分出系统的一级子系统（领域），明确各子系统的调用关系，将它们完整的用UML的包图表现出来。领域的划分原则是划出来的领域可以独立完成业务，与其他领域的交互以接口服务调用的方式进行。如图二为组织管理实体模型。

3 汇总生成词汇表

把分析过程中实体、行为进行汇总，明确各词汇所表示的意思，并给出相应的中英文描述。

4领域间接口的设计

结合汇合后的领域模型，利用用例分析时产生的跨领域实体访问，抽象出领域间的访问接口（行为名称、所需参数、返回值）用UML的类图表现出来。

4.4 主要输出文档

经过对单个用例的分析，对模块需求的分析，对系统汇总后的需求分析，我们抽象出系统级子系统，并对子系统进行抽象实现了业务实体的模型化，结合实体的行为，完成了领域模型的构建。

需求分析的输出成果是以对以下文档评审通过为结束标志。

①领域词汇表（实体词汇表、行为词汇表）

②业务用例模型（用UML用例图表示）、业务实体流程图（用UML状态图表示）

③领域模型（用UML类图表示）

④领域间接口（用UML类图表示）

5特点分析

5.1可操作性

对于复杂的产品系统分析往往不是由一两个人完成的，每个人的分析方式不同必然会造成系统分析质量的不稳定，基于业务建模的软件产品系统分析过程，从最初的类分析用最简单的表格方式做为输出，在分析的过程中，采用最基础的名词、动词的分析方式，大大减少了因为人员的水平参差不平，人员心情起伏等人为因素带来的偏差。对每一个所负责的任务清晰定义，以明确的文档为输入，以评审通过为边界，使系统分析结果有负责人，可追溯来源。

可见从操作人员过程规范方面，从管理人员对质量的管理方面，基于业务建模的软件产品系统分析过程都具备较强的操作性。

5.2稳定性及可扩展性

稳定性与扩展性好象是鱼与熊掌很难得以兼顾，但基于业务建模的软件产品系统分析过程并将这两者统一起来。

对于产品需要业务稳定而对产品所支持的项目又希望能提供更多的定制，于是稳定及扩展两者剪不断理还乱，基于实体与行为分离的业务模型的建立让核心的业务得到了稳定，而扩展的功能在需求分析的时候就与核心用松耦合的方式独立出行为与属性，兼顾了项目又保障了产品，时机成熟项目的内容可以纳入到产品中来，这样项目与产品进入了良性的循环。

5.3系统全面的分析

系统的分析是一种根据客观事物所具有的系统特征，从事物的整体出发，着眼于整体与部分，整体与结构及层次，结构与功能、系统与环境等的相互联系和相互作用，求得优化的整体目标的现代科学方法。

基于业务建模的软件产品系统分析过程从进入分析过程开始就是从整体规划到单个用例，从单个用例分析到整个系统分析汇总，无论是实体还是行为还是实体的变化都是着眼于整个系统，整个领域，在输出的文档中，可以看到基于业务建模的软件产品系统分析过程统一的对待系统的词汇表、领域的接口等内容，这些都是常用的系统分析方法容易忽略的地方。

5.4阶段独立的分析方法

其独立性表现在两个地方：

1.充分利用UML带来的独立性优势：

（1）可视化，表示能力强。通过UML的模型图能清晰地表示系统的逻辑模型和实现模型。可用于各种复杂系统的建模。

（2）独立于过程。UML是系统建模语言，独立于开发过程。

（3）独立于程序设计。用UML建立的软件系统模型可以用Java、VC++、SmalltaIk等任何一种面向对象的程序设计来实现。

2.独立于其他阶段

基于业务建模的软件产品系统分析过程是一个建模的过程，与之前的需求分析、之后的系统设计有着明确的界线，系统分析评审完成后，系统分析的成果就可作为系统设计的输入进入下一阶段，如果需要系统分析修改的时候就要遵循系统分析变更流程，重新经过系统分析的过程；系统分析结果是与系统设计、系统开发等过程无关的内容，以就意味着系统分析的结果不会因后面的软件过程使用何种方式而改变系统分析的结果。

6使用效果

在一个研发周期10个月总工作量120个人月的基于信息资源管理的内容管理产品当中使用了基于业务建模的软件产品系统分析过程，投入到系统分析时间为3个月24个人月工作量。产品从2009年投入使用以来，在系统分析方面成效是非常显著的，主要表现在下面几点：

1 独立的特性

系统分析完成后，系统的功能模块有的是使用java语言进行c/s模式的实现，有的是采用java与HTML一起的B＼S模式的实现，有的采用C语言来实现但这些都没有引起系统分析结果的修改。

2 适应变化能力强

产品开始用来做项目后，无论是实体的属性有增加的，有减少的，对其的操作有意义发生变化的，有增加减少的，在实体与行为分离的大框架下，这些变化不仅没有让产品变得不稳定，反而逐步完善了产品的领域模型让产品的系统分析成果能够支撑更多的项目。

3 UML模型表现力强

UML图形结构清晰，建模简洁明了，容易掌握理解。使用UML进行系统分析加速开发进程，提高代码质量。用UML来描述业务过程方便清晰，在业务传承、交接的时候表现出其优越的特性，不用跑系统跟代码就能完成对系统逻辑的理解。

4 系统元素得到了统一

从系统分析时就开始将系统词汇、实体、行为进行统一管理，对后期专有名词语意的理解、数据库逻辑模型的生成、国际化的处理、接口查找复用等都显得方便、可控。

结语

经过以上对基于业务建模的软件产品系统分析过程的分析，我们可以看到基于业务建模的软件产品系统分析过程其突出的可操作性、独立性、全面性、稳定性非常适合于阶段明确软件产品研发过程，随着该方法的推广，产品的核心业务得到不断完善与传承，产品的优势将会越来越得到发挥。

参考文献

[1]来自， 2009-07-23：业务用例模型.

[2] 来自IBM网站，Nandi等，2010-04：Introducing Business Entities and the Business Entity Definition Language （BEDL） - A first class representation of data for BPM applications.

[3] 来自网站，Introduction to OMG's Unified Modeling LanguageTM （UMLR ）.

[4] 张龙详，UML与系统分新设计[M]，人民邮电出版社，2001，p2-10.