CN107102948A - 一种基于uml的软件架构复杂性度量方法 - Google Patents

Abstract

本发明公开了一种基于UML的软件架构复杂性度量方法，包含UML数据采集模块、UML图元素分析模块、数据归一模块、架构元素分析模块、复杂性模型及算法模块、模型特征因子库；所述模型特征因子库与复杂性模型及算法模块连接，所述复杂性模型及算法模块与架构元素分析模块连接，所述架构元素分析模块与UML图元素分析模块连接，所述UML图元素分析模块与UML数据采集模块连接，所述UML数据采集模块、UML图元素分析模块、架构元素分析模块、复杂性模型及算法模块均与数据归一模块连接；本发明可以在软件过程的需求、分析、设计等多个阶段一致地使用，从良好设计的软件架构中计算得到，不仅可以反映过程的效果，还能表示过程产生的结果的质量。

Description

一种基于UML的软件架构复杂性度量方法

技术领域

本发明涉及的是一种基于UML的软件架构复杂性度量方法。

背景技术

软件度量是对软件开发过程的状态和产品的属性量化的表示，目的是要科学、定量地评估和预测软件开发活动及其产品的质量，也可以用来管理软件开发活动和过程。软件复杂性主要表现在设计结构的复杂性、程序的复杂性、功能的复杂性和数据的复杂性等。

软件架构是软件设计过程中的一个层次，这一层次超越计算过程中的算法设计和数据结构设计。软件架构问题包括总体组织和全局控制、通讯协议、同步、数据存取，给设计元素分配特定功能，设计元素的组织，规模和性能，在各设计方案间进行选择等。软件架构处理算法与数据结构之上关于整体系统结构设计和描述方面的一些问题，如全局组织和全局控制结构、关于通讯、同步与数据存取的协议，设计构件功能定义，物理分布与合成，设计方案的选择、评估与实现等。软件架构是一个抽象的系统规范，主要包括用其行为来描述的功能构件和构件之间的相互连接、接口和关系。软件架构是软件开发过程中的关键制品，体现了软件设计的早期决策，决定了软件的质量属性。因此，度量软件架构的复杂性就能度量整个软件的复杂性，指导软件的开发、评估和管理。

目前的软件度量方法在刻画软件架构的复杂性方面都具有一定的局限性。首先，虽然基于程序代码的度量可以得到准确的软件信息，但是，这类方法具有事后性，通常只能在实现了软件，存在程序代码时才能应用，无法在软件生命周期的早期进行，因而难以对软件的开发过程及其产品提供及时有效的指导。其次，由于对被测量实体缺乏严格的描述，其它的度量不能准确地获得软件的有关信息，度量也就缺乏应用价值，例如功能点方法可以在系统分析阶段使用，面向对象的复杂性和软件的耦合性等软件结构性度量也可以应用在软件设计阶段。如果系统或软件设计语言不具备严格的语法和语义，不能描述设计的详细特征，就难以得到准确一致和体现详细信息的软件设计度量。而且，如果软件的设计和程序实现缺乏一致的转换关系，就使得软件设计度量和程序度量的不一致，降低了软件设计度量的使用价值。

对UML的度量主要包括类、包、状态、关联、转移等UML基本建模元素的数量，以及类的继承深度等面向对象的度量。这些基本元素的数量及关系难以反映整个系统的特性，既没没有把UML的视可化特征对阅读和理解软件设计进行量化，也没有针对软件架构的特征。

发明内容

本发明的目的在于针对现有技术的缺陷和不足，提供了一种基于UML的软件架构复杂性度量方法。

为实现上述目的，本发明采用的技术方案是：一种基于UML的软件架构复杂性度量方法，包含UML数据采集模块、UML图元素分析模块、数据归一模块、架构元素分析模块、复杂性模型及算法模块、模型特征因子库；所述模型特征因子库与复杂性模型及算法模块连接，所述复杂性模型及算法模块与架构元素分析模块连接，所述架构元素分析模块与UML图元素分析模块连接，所述UML图元素分析模块与UML数据采集模块连接，所述UML数据采集模块、UML图元素分析模块、架构元素分析模块、复杂性模型及算法模块均与数据归一模块连接；

所述UML数据采集模块：负责从存储UML的文件中读取UML的信息，进行预处理：消除与软件设计、软件架构描述无关的数据；

所述UML图元素分析模块：识别出基本的UML元素，包括各种图元素、语义描述、属性、注释、语义约束等，分析出每个UML图元素(例如类、接口、角色、端口、继承关系、聚合关系)的形状、属性、位置坐标，计算出每个图元素的大小；

所述数据归一模块：主要有三个子模块：格式归一、图示归一、语义归一；采集的UML的图形设计，首先需要按照UML交换标准，把每个图形都转换成统一的XML格式，就是格式归一；其次，同一种UML图元素可能有大小(例如都是类，划出不同的大小)、形状(例如线条的粗细、长短)、显示颜色、是否重叠等的不同。

进一步，所述复杂性模型及算法，通过分析UML描述的软件的体系架构，综合考虑UML的图形显示、软件架构的组成及其结构，提出软件架构复杂度的计算公式SACplex，参数是有k层嵌套的UML图，不含嵌套元素的UML描述架构复杂度用BasiCplex表示——基本公式1，否则用递推公式2；

公式1表示一个基本的UML软件架构图的计算公式，COM表示一个UML图元素，用在UML图中的位置作为参数，ViSize()表示该经过归一化处理的图元素的视觉大小，sfactor()表示不同的UML图元素对应软件架构元素对架构影响的语义因子；公式2递归地定义一个UML描述的软件架构。

进一步，所述递推定义的公式(2)，用递归算法求解，算法如下：

(1)输入：含n个元素COM的UML图，嵌套层数≥1；

(2)输出：UML图的复杂数；

(3)SACplex＝BCplex＝0；

(4)如果UML图不含嵌套的元素，则对每个UML的图元素COM(i)

(5)SACplex+＝计算其语义因子sfactor/视图大小ViSize；//否则，k>1，递归计算SACplex；

(6)如果k>1则，对每个含嵌套的UML元素COM(i)

(7)SACplex+＝递归计算下一层(k-1)的SACplex×dfactor(k-1)；

(8)SACplex+＝BCplex；

(9)k＝k-1；

(10)返回(7)；

(11)输出SACplex。

本发明有益效果为：

1、本发明的UML软件架构复杂性度量可以在软件过程的需求、分析、设计等多个阶段一致地使用，从良好设计的软件架构中计算得到。

2、本发明的UML软件架构复杂性度量不仅可以反映过程的效果，还能表示过程产生的结果的质量。

3、本发明的UML软件架构复杂性度量不仅能被程序员使用，由于在设计期间就可以计算，架构复杂性度量也可以被软件测试人员、质量管理员、项目管理人员、客户在监控软件开发过程、评估设计质量、设计软件测试中使用。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明的结构框架图；

图2是本发明的一种实施流程图；

图3是本发明的算法UML_SAC运算时使用的关联表；

图4是本发明的UML元素架构元素语义因子表；

图5是本发明的架构元素嵌套层级因子表。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及具体实施方式，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施方式仅用以解释本发明，并不用于限定本发明。

参看图1至图5，本具体实施方式采用以下技术方案：实施本具体实施方式时，使用两张表，UML元素-架构元素语义因子和架构元素嵌套层级因子，实现模型特征因子库。

软件架构建模的核心元素是构件、连接件、端口和角色，每个架构元素都有不止一个UML图元素表示或建模。同样是描述每种架构元素的UML图元素，对于整个架构复杂度的影响不完全相同，比如，UML协作元素用以解释一组相互合作的实例如何实现联合任务或一组任务，可以在架构设计中描述一个模块或一个子系统。协作具有嵌套结构，语义要比类、构件等复杂。丰富的建模手段给架构设计者丰富的选择，同时也对架构的设计、分析和度量造成了不同的影响。UML元素-架构元素语义因子(简称语义因子)表示不同UML元素描述架构元素的复杂度影响系数，对应公式1中的sfactor()。UML元素对应的架构元素及其语义因子系数如图4所示，本具体实施方式建议的语义因子取值范围是1-1.50。

构件是计算机软件中的一个模块化的构造块，是系统中模块化的、可部署的和可替换的部件，该部件封装了实现并暴露一组接口。构件存在于软件架构中，在完成所建系统的需求和目标中起着重要作用。构件驻留于软件架构的内部，它们必须与其他的构件和存在于软件边界以外的实体(如其他系统、设备和人员)进行通信和合作。构件可以是被封装的类、接口服务、功能模块、数据集及其操作、软件框架、文档、组件、设计模式等。UML元素中常用来描述构件的有类、组件、协作等，每个UML元素描述架构元素时的影响度(语义因子)不同。

连接件是软件架构的一个组成部分，它通过对构件之间的交互规则的建模来实现构件之间的连接。连接可以是简单的指针、或者复杂到网络链接，还可以表示允许参数传递的多个实例之间的通信。连接器可以是包含构件的复合体，也可以是复杂度不同的动作，如复杂结构的活动边及其动作。角色和端口只能是简单成分、不能是复合体。

软件系统通常具有层次结构，相应的软件架构也就层次特征，比如用一个构件表示子系统，子系统本身又是一个连接在一起的构件，每个构件在子系统中具有不同的角色，通过不同的端口参与构件之间的交互。UML的图及其元素允许嵌套，比如用一个UML组件描述架构的构件时，组件可以是复杂的、包含UML类、组件、关联关系的图。架构元素嵌套层级因子(简称嵌套因子)表示不同UML元素嵌套的层级对架构的复杂度影响系数，对应公式2中的dfactor()。每种架构元素的不同嵌套层级对复杂度的影响不同，实施时建议子系统架构的层数原则上不超过7，否则系统架构就太复杂、需要重新设计。在架构元素中，只有构件和连接件允许嵌套，端口和角色不能嵌套。

图2示意了UML软件架构复杂性度量方法的一种实施流程，使用了三个数据文件：存储UML数据的UML模型文件(8)用本发明方法分析UML文件得到的处理后的UML图元素表(9)以及管理和操作UML元素-架构元素语义因子和架构元素嵌套层级因子的模型特征因子库(10)。

本具体实施方式中的UML数据可以有多种来源，可以从开源UML设计工具JUDE–community、ArgoUML、Visualparadigm–community或者UMLet存储的文件中(8)，读取UML数据(1)，进行基本的预处理：删除与UML图元素、语义描述的数据，分析出基本的UML数据。为了便于后期统一、简化处理，需要根据UML图数据交换标准XMI，对不同来源、不同格式的UML数据，统一到XML格式的数据归一化处理(2)。

然后，依据UML图元素的语法、语义及图符的定义，分析出UML图元素(3)，包括把识别的UML元素按照编号存入到UML图元素表(9)，填写UML元素类型和位置，计算出图形大小(即公式1中的ViSize)并记在表中(9)，按照元素种类记录每个元素在一层UML图中的唯一序号，如果该元素有嵌套，连接对应的嵌套子图、记下嵌套层级数等。由于不同UML工具、不同的架构设计者可能设计出不同方风格(图符选择)、样式(图形大小)、等UML图，要进行图示归一化处理(4)。

之后，依据模型特征库因子中的UML元素-架构元素对应表(10)，识别出用UML表示的架构成分：构件、连接件、角色和端口(5)。UML表示的软件架构的设计可能会详略不同，要依据架构成分类型把UML元素分门别类，进行语义归一化处理(6)，使得每个UML图元素的语义、可视化大小的取值范围都是[0..1]，。例如，UML图元素的动有调用行为动作、调用操作动作、发送信号动作、发送对象动作、创建对象动作、销毁对象动作、接受事件动作等，都可能是表示软件架构的连接，需要统一到架构的连接件，赋予相应的语义影响系数。

最后，按照计算UML软件架构复杂度的算法UML_SAC，计算出软件架构复杂度SACplex(7)，其中要使用模型因子库(10)和UML图形元素表(9)：对每一个UML元素，检索UML图元素表(9)得到其标识符(7a)，在表中得到可视化大小(7b)；通过UML图元素标识符在语义因子表中查询(7c)得到语义系数(7e)；如果该UML图元素的嵌套层级数大于1，则要在层级因子表中查找(7d)对应的层级因子数(7f)，最终送到算法UML_SAC按照公式(1)和公式(2)进行计算。必要时还要按照“先进后出”的栈式数据结构的方式，由最底层向最外层、逐层计算，最终计算出软件架构复杂度SACplex的值。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

Claims (3)

1.一种基于UML的软件架构复杂性度量方法，其特征在于：包含UML数据采集模块、UML图元素分析模块、数据归一模块、架构元素分析模块、复杂性模型及算法模块、模型特征因子库；所述模型特征因子库与复杂性模型及算法模块连接，所述复杂性模型及算法模块与架构元素分析模块连接，所述架构元素分析模块与UML图元素分析模块连接，所述UML图元素分析模块与UML数据采集模块连接，所述UML数据采集模块、UML图元素分析模块、架构元素分析模块、复杂性模型及算法模块均与数据归一模块连接；

所述UML数据采集模块：负责从存储UML的文件中读取UML的信息，进行预处理：消除与软件设计、软件架构描述无关的数据；

所述UML图元素分析模块：识别出基本的UML元素，包括各种图元素、语义描述、属性、注释、语义约束等，分析出每个UML图元素(例如类、接口、角色、端口、继承关系、聚合关系)的形状、属性、位置坐标，计算出每个图元素的大小；

所述数据归一模块：主要有三个子模块：格式归一、图示归一、语义归一；采集的UML的图形设计，首先需要按照UML交换标准，把每个图形都转换成统一的XML格式，就是格式归一；其次，同一种UML图元素可能有大小(例如都是类，划出不同的大小)、形状(例如线条的粗细、长短)、显示颜色、是否重叠等的不同。

2.根据权利要求1所述的一种基于UML的软件架构复杂性度量方法，其特征在于：所述复杂性模型及算法，通过分析UML描述的软件的体系架构，综合考虑UML的图形显示、软件架构的组成及其结构，提出软件架构复杂度的计算公式SACplex，参数是有k层嵌套的UML图，不含嵌套元素的UML描述架构复杂度用BasiCplex表示——基本公式1，否则用递推公式2；

公式1表示一个基本的UML软件架构图的计算公式，COM表示一个UML图元素，用在UML图中的位置作为参数，ViSize()表示该经过归一化处理的图元素的视觉大小，sfactor()表示不同的UML图元素对应软件架构元素对架构影响的语义因子；公式2递归地定义一个UML描述的软件架构。

3.根据权利要求2所述的一种基于UML的软件架构复杂性度量方法，其特征在于：所述递推定义的公式(2)，用递归算法求解，算法如下：

(1)输入：含n个元素COM的UML图，嵌套层数≥1；

(2)输出：UML图的复杂数；

(3)SACplex＝BCplex＝0；

(4)如果UML图不含嵌套的元素，则对每个UML的图元素COM(i)

(5)SACplex+＝计算其语义因子sfactor/视图大小ViSize；

//否则，k>1，递归计算SACplex；

(6)如果k>1则，对每个含嵌套的UML元素COM(i)；

(7)SACplex+＝递归计算下一层(k-1)的SACplex×dfactor(k-1)；

(8)SACplex+＝BCplex；

(9)k＝k-1；

(10)返回(7)；

(11)输出SACplex。