著名的软件指标，LOC，CKMetrics,McCabe等已经被广泛用于缺陷定位，缺陷预测等。相对于日常生活中的度量标准，比如厘米，公里等，软件的度量指标仍然不能很好的满足软件可维护性度量的需要。
首先，软件度量指标不能有效的用于比较不同系统之间的可维护性。以厘米为参照，如果10岁的小明身高厘米，同龄的小红身高厘米，我们肯定小明比小红高。然而，以代码行数为例，如果A软件有k行代码，而B软件有k行代码，我们不能肯定A一定比B更容易维护。
第二，软件度量指标不能有效的用于架构腐化的检测。如果一个人的体重在两周之内浮动2磅左右是完全正常的；而体重突然增加或减少10磅，就值得引起注意了。使用软件的度量指标，人们往往不能确定度量值变化了多少才确切表明架构发生了质的变化。架构师通常无法根据这些指标判断软件的架构是否足够好，是否在逐渐恶化，程度如何。
由于现实生活中的指标可以形成各自的指标空间，支持有效的比较和监测，人们可以用大量的度量数据组成图表，以供参考。比如，参照所有10岁女孩的身高数据，如果小红的身高大约在第50个百分位，说明她的身高处于平均水平。
反观软件度量指标，由于不能很好的支持比较和监测，我们缺少一个架构可维护性健康图表，使得任何软件都可以以大量业界数据为参照，判断自己的可维护程度。
我们的研究以哈佛大学BaldwinClark的设计规则理论为基础[BC]。他们的理论从期权价值的角度量化分析了为何模块化给计算机工业带来了革命。根据他们的理论，规模小，且可以独立演进的模块(truemodule)具有最高的期权价值，因为这样的模块可以被更新，修改，甚至被替换成价值更高的模块。这些独立模块由设计规则(DesignRules)隔离开来，使得模块只依赖于设计规则，而不依赖于彼此。如果一个系统由大量这样的模块组成，那么整个系统的价值可以通过各个模块的价值提升得到快速提升。
设计规则和独立模块的概念也适用于软件架构。比如，几乎所有的设计模式都存在一个或一组设计规则，使得系统其他的部分可以被解耦成独立模块（详见论文）。为了可视化软件的模块化结构，我们用设计结构矩阵（DesignStructureMatrix(DSM)）来表达文件之间的依赖关系。我们以往的研究[ASE]提出了设计规则层级结构(DesignRuleHierarchy(DRH))聚类方法，可以自动在DSM中区别设计规则和独立模块。
根据设计规则层级结构，我们提出了一个新的软件可维护性度量指标：解耦度。这个指标根据设计规则理论的思想，首先度量DRH中每个模块的耦合度，大小，以及是否可以独立演进，然后度量一个系统中独立模块的比例。简而言之，解耦度测量一个软件的解耦程度如何，即系统中有多少小规模的独立模块。
以实际度量指标为参考，我们从以下三个方面对解耦度进行了验证：１)该指标是否可以用于比较不同的软件系统；2）该指标是否可以用于监测同一软件系统在演化过程中的架构变化；3）该指标是否能够反映软件的实际可维护性。
用解耦度比较不同的系统：
我们计算了１０８个开源软件，２１个工业软件的解耦度(见下图)。数据表明６０％的系统解耦度在４６％到７５％之间。
通过比较开源和工业软件，我们观察到，虽然开源软件的平均解耦度略高于工业软件，但解耦度最高的软件系统是工业软件。通过和该系统的开发团队进行交流，证实该系统架构稳定，没有突出的维护困难。
这些数据还表明，解耦度最低的软件系统是开源软件。我们分析了解耦度最低的三个开源软件。根据OpenHub的记录，这三个系统都只有三个贡献者，并且都不活跃。
解耦度已经被我们的一个工业界合作伙伴所采纳，用于度量公司内部开发的多个软件产品。其中一个软件系统的解耦度仅为29%。和其他个软件系统相比较，处于第十个百分位（见下图），表明该软件的可维护性比90%的软件系统差。通过和开发团队交流，我们证实了这个项目正经历严重的维护困难。
这些定性的分析给了我们信心：解耦度的确可以用来比较软件的可维护程度。
2.用解耦度监测架构演化。
这里我们从两个方面进行验证：(1)如果一个系统的架构没有大的变化，那么它的解耦度应保持稳定；(2)如果解耦度发生相当程度的变化，比如增大或减少１０％，那么该系统的架构一定发生了改变。
2.1稳定性验证
从这个系统中，我们选择了13个开源软件，3个工业软件，每个系统分析了4到13个没有架构变化的版本。我们之所以选择这些系统是因为我们以前的研究分析过它们，了解哪些版本没有经历重构，或我们的合作伙伴可以告诉我们哪些版本的架构是一致的。通过计算这些系统中多个版本的解耦度，我们发现版本之间解耦度变化很小，平均变异系数只有2%。这表明如果系统架构没有变化，即便不同版本之间文件个数差异很大，解耦度也不会有很大的变化。
2.2架构变化指征
为了验证当解耦度发生相当程度的改变（10%左右），系统的架构是否真的发生了质的变化，我们深入研究了一个工业界项目。这个项目演化了6年，一共29个版本，文件个数从个增长到个。
如上图所示，经过度量29个版本的解耦度，我们观察到了解耦度的四个转折点，即解耦度变化超过10%。通过和架构师深入交流，我们证实了这四个转折点如实的反映了架构的本质改变：
１.第一个转折点，从版本1到2,DL从45%增加到74%:开发团队证实，从版本0.10到1.01，该产品从一个设计原型，被重构成为商业产品。
２.第二个转折点，从版本7到8,DL从78%降低到68%: 在这段时间内，由于快速开发新特性的需要，架构债务不断积累，导致架构腐化。
３.第三个转折点，从版本18到19,DL从65%降低到48%：这个变化是出乎程序员意料之外的：由于感受到维护工作逐渐变得困难，在这里架构师引入了一个主要的设计模式。通过观察DSM，我们发现这个重构并不成功，模式实现的不完全正确，导致了大量的循环依赖。
４.第四个转折点，从版本28到29,DL从48%升高到62%: 由于程序员无法继续忍受架构的腐化，开发团队专门留出了一段时间清理架构债务，揭示了解耦度升高的原因。
通过这两方面的验证，我们认为通过解耦度的变化，可以有效的监测架构的演进和腐化。
3.与实际可维护性的关联度
由于解耦度完全是从静态结构的角度进行度量，那么它是否能够真正反映软件维护的难易程度呢？这里又存在一个问题:软件维护的难易程度如何体现呢？我们首先用一组从演化历史数据中提取的表征值(indicators)来反映维护的难易程度，然后计算它们和解耦度的关联度。
根据设计规则理论，如果一个系统易于维护，那么当程序员因添加新特性或修改缺陷而修改文件时，修改日志应体现出以下三个特点：
１.文件可以被独立的修改和提交。
２.不同的程序员修改的文件不同
３.程序员没有交流的需要
我们用COR,CFOR,PCO来量化这三个属性。通过计算解耦度和这三个属性的统计关系，可以证明解耦度和这三个属性强相关。也就是说，解耦度高的系统，文件的修改比较独立，不同的程序员修改的文件不同，表明程序员可以独立并行的进行开发和维护。
在这篇论文中，我们提出一个新的软件架构可维护性度量指标，解耦度。通过对这个指标进行全方位的验证，我们认为解耦度不同于以往任何其他的指标，可以用于1）不同软件系统之间可维护性的比较，2）同一系统的架构演化检测，以及3)较准确的反映系统维护的难易程度。该指标已经被我们的工业界合作伙伴所采纳。我们正在收集更多的数据，希望能够在不久的将来，发布一个“架构健康指标图表”，使得所有的软件系统都可以根据该图表判断自己的可维护程度。
本文的作者包括DrexelUniversity的博士研究生莫然，指导老师蔡元芳教授（DrexelUniversity）和RickKazman教授（UniversityofHawaiiSEI/CMU），以及博士研究生肖璐和凤琼（DrexelUniversity）。
[BC]C.Y.BaldwinandK.B.Clark.DesignRules,Vol.1:ThePowerofModularity.MITPress,
[ASE]S.Wong,Y.Cai,G.Valetto,G.Simeonov,andK.Sethi.Designrulehierarchiesandparallelisminsoftwaredevelopmenttasks.InProc.24thIEEE/ACMInternationalConferenceonAutomatedSoftwareEngineering,pages-,Nov..
治疗白癜风专科医院北京哪家医院白癜风较好