段玉聰，高洪皓，唐朝勝，杜文才，萬世想，盧俊星

（1.海南大學(xué)信息科學(xué)技術(shù)學(xué)院，海南 ?？?70288；2.上海大學(xué)計算中心，上海200444）

1 引言

面向服務(wù)的計算模式能夠無縫地把各種商業(yè)應(yīng)用服務(wù)組合起來，以形成新的增值服務(wù)?；赪eb模式的應(yīng)用發(fā)展迅速，Web服務(wù)成為電子商務(wù)的有效解決方案。然而，隨著網(wǎng)絡(luò)形式趨于多樣化（Internet、3G、WSN 等），服務(wù)模式和類型不斷豐富，滿足相同需求的服務(wù)越來越多，使得在選擇服務(wù)時不僅要考慮功能性需求，還要考慮諸如服務(wù)響應(yīng)時間（Response Time）、費(fèi)用（Cost）、安全性（Safety）等非功能性需求?；ヂ?lián)網(wǎng)具有開放性、分布性、多變性和不確定性，如何在具有不同QoS 屬性值的服務(wù)組合中，給出一種有效的、動態(tài)的服務(wù)策略滿足用戶QoS 需求的服務(wù)，已成為限制Web服務(wù)發(fā)展的難題之一［1］。

1.1 軟件開發(fā)生命周期

從工程角度看，傳統(tǒng)軟件工程開發(fā)生命周期包括需求分析、系統(tǒng)設(shè)計、編碼、測試、交付和運(yùn)維等階段。從價值工程角度看，Boehm B W 等人［2］提出了軟件經(jīng)濟(jì)的概念，并論述了軟件開發(fā)過程應(yīng)當(dāng)是一個價值創(chuàng)造的過程。理想情況下在整個軟件開發(fā)階段，過程質(zhì)量必須服從于整體經(jīng)濟(jì)目標(biāo)［3］。軟件開發(fā)的最終目的是為用戶提供價值，并獲取自身經(jīng)濟(jì)利益。然而，由于缺乏有效的技術(shù)和商業(yè)一體化建?；蛘呒煞椒ê图夹g(shù)，當(dāng)前在一個軟件開發(fā)生命周期中，開發(fā)人員的技術(shù)決策目標(biāo)和項目最終是為用戶創(chuàng)造價值的目標(biāo)兩者之間存在著信息流通的間隙。這在用戶需求不斷變化的情形下更是一個挑戰(zhàn)。當(dāng)前實際中過程質(zhì)量和產(chǎn)品質(zhì)量仍欠缺相關(guān)性［4］，軟件經(jīng)濟(jì)學(xué)觀點［2］以價值為媒介為將二者互相關(guān)聯(lián)提供了質(zhì)量指標(biāo)。

1.2 傳統(tǒng)軟件工程與面向服務(wù)軟件工程開發(fā)對比

軟件經(jīng)濟(jì)概念的落實要求在軟件開發(fā)全過程可以無縫地實時進(jìn)行對于商業(yè)建模的技術(shù)實現(xiàn)狀況的價值層面的評價和度量，并根據(jù)評價和度量結(jié)果進(jìn)行實時反饋調(diào)整。這要求評價操作實施者即涉眾（Stakeholders）均能全程理解并參與軟件開發(fā)的全過程。然而，通常的軟件開發(fā)過程中，受利用相關(guān)者知識和經(jīng)驗的限制，開發(fā)者全程參與開發(fā)，用戶限于信息則只能參與需求分析和交付驗收兩個階段。同時，現(xiàn)實中用戶需求往往還具有多變性［5］，因此開發(fā)者的開發(fā)決策與用戶商業(yè)需求之間并不能保證在整個開發(fā)過程的每個階段都得以溝通，從而導(dǎo)致在開發(fā)過程中開發(fā)人員的開發(fā)決策和用戶商業(yè)需求的不匹配現(xiàn)象普遍存在。開發(fā)決策方只能單從技術(shù)層面控制項目的開發(fā)，而無法實時與用戶進(jìn)行信息溝通來反映客戶商業(yè)訴求方面的要求，因此無法在最終軟件產(chǎn)品上線之前的軟件開發(fā)過程中確保滿足用戶需求。這將導(dǎo)致在功能或性能實現(xiàn)方面，如用戶預(yù)期開發(fā)的網(wǎng)站背景能按照實際天氣智能更換，但先期開發(fā)過程完成后，核算出的成本超過了客戶在該部分的開銷和收益預(yù)期，這樣就只好與開發(fā)人員溝通后，出于成本原因最終放棄相應(yīng)需求。

面向服務(wù)體系結(jié)構(gòu)是開發(fā)分布式應(yīng)用軟件的新型體系結(jié)構(gòu)，它將應(yīng)用程序的不同功能單元描述為服務(wù)，通過這些服務(wù)之間定義良好的接口（Interface）和契約（Contract）聯(lián)系起來［6，7］。服務(wù)所具有的接口是采用中立的方式進(jìn)行定義的，它應(yīng)該獨立于實現(xiàn)服務(wù)的硬件平臺、操作系統(tǒng)和編程語言，這使得構(gòu)建在各種這樣的系統(tǒng)中的服務(wù)可以以一種統(tǒng)一和通用的方式進(jìn)行交互，是一種可插拔模式的構(gòu)件集成形式。傳統(tǒng)軟件工程開發(fā)過程中的模型元素往往只承載了功能或者性能內(nèi)容，屬于技術(shù)層面。而Web服務(wù)系統(tǒng)中的服務(wù)作為基本建模和實現(xiàn)元素，與傳統(tǒng)軟件工程模型元素不同。它既是一種建模商業(yè)分析的商業(yè)建模元素，又是建模功能和性能的技術(shù)實現(xiàn)元素。相比于傳統(tǒng)開發(fā)的復(fù)雜流程開發(fā)，Web服務(wù)應(yīng)用程序的開發(fā)，模型元素基礎(chǔ)更好，流程更加簡易，極大降低開發(fā)者與用戶間的溝通障礙，縮短了開發(fā)時間。因此，Web服務(wù)組合具有更好的集成商業(yè)分析和技術(shù)建模的潛力，有助于推動在軟件開發(fā)過程中實現(xiàn)軟件經(jīng)濟(jì)的理念。

1.3 基于可變性的建模

模型驅(qū)動工程中的可變性建模（Variability Modeling）經(jīng)常被當(dāng)作管理和協(xié)調(diào)軟件開發(fā)的多種過程和關(guān)注的重要機(jī)制。在質(zhì)量驅(qū)動（Quality Driven）［8～11］或質(zhì)量意識（Quality Aware）［12］的設(shè)計開發(fā)領(lǐng)域，從面向單一軟件產(chǎn)品到面向軟件產(chǎn)品家族在過去的幾年里均取得了巨大發(fā)展。無論是軟件產(chǎn)品線SPL（Software Product Line）、特征建模（Feature Model）［13］，還是模型驅(qū)動架構(gòu)MDA（Model Driven Architecture）［12，14，15］，對 質(zhì) 量 的 控制核心之一就是可變性建模。針對Web 服務(wù)系統(tǒng)，已有很多可變性建模技術(shù)被提出，然而幾乎每個可變性建模解決方案都依賴于不同的技術(shù)背景，并使用自己特有的概念。本文考慮面向Web服務(wù)的軟件開發(fā)，基于軟件開發(fā)流程的質(zhì)量分析闡述如何將質(zhì)量因素運(yùn)用到設(shè)計決策過程中，提出了一種質(zhì)量驅(qū)動的軟件建模解決方案，即“問題－質(zhì)量－約束”方法PQC（Problem Quality Constraint）。該方法基于約束的建模解決方案，能夠滿足軟件開發(fā)中過程質(zhì)量和產(chǎn)品質(zhì)量的雙重要求，涵蓋涉眾的質(zhì)量評估（Assessment）、協(xié)議（Agreement）和在質(zhì)量生命周期中的經(jīng)濟(jì)價值。

基于此，本文提出了過設(shè)計（Over Design）與欠設(shè)計（Under Design）兩種偏離需求的服務(wù)設(shè)計，分別表示在服務(wù)組合過程中的過設(shè)計與欠設(shè)計行為，并構(gòu)建能夠約束服務(wù)組合的變化空間（Variability Space）實現(xiàn)控制服務(wù)質(zhì)量的目的。本文主要貢獻(xiàn)概括如下：

（1）介紹了以軟件經(jīng)濟(jì)為驅(qū)動，以綜合質(zhì)量為目標(biāo)，權(quán)衡過程質(zhì)量的質(zhì)量建模和質(zhì)量評估。

（2）針對Web服務(wù)應(yīng)用系統(tǒng)開發(fā)，從流程的過設(shè)計與欠設(shè)計角度進(jìn)行質(zhì)量設(shè)計分析。

本文內(nèi)容安排如下：本文第2節(jié)介紹基于電子商務(wù)的運(yùn)行實例；第3節(jié)介紹后文的概念和計算方法；第4 節(jié)引入解決框架“Problem－Quality－Constraint”；第5節(jié)通過實驗表明本文方法的有效性；最后討論相關(guān)工作與總結(jié)展望，并指出今后的研究方向。

2 運(yùn)行實例

運(yùn)行實例是一個跨國手機(jī)購買電子商務(wù)系統(tǒng)。圖1a展現(xiàn)的是其基于傳統(tǒng)軟件工程開發(fā)的一系列流程，該商務(wù)系統(tǒng)開發(fā)過程為傳統(tǒng)的瀑布模型，橫軸包括需求分析、系統(tǒng)設(shè)計、程序編碼、系統(tǒng)測試和系統(tǒng)部署五個基本階段。在這一系列流程中，存在大量的設(shè)計目標(biāo)（Target）?？v軸表示在不同開發(fā)階段中設(shè)計目標(biāo)的值。為了簡化分析，選取推薦服務(wù)（Recommendation）、響 應(yīng) 時 間（Response Time）、翻譯服務(wù)（Translation）作為典型設(shè)計目標(biāo)研究。每種服務(wù)的綜合價值（Value）的取值參考了我們在該系統(tǒng)建模的過程模型，數(shù)值為經(jīng)驗估計所得，僅為定性展示目的。其中，翻譯服務(wù)在系統(tǒng)部署階段假定為無，推薦服務(wù)在需求分析階段假定為無，響應(yīng)時間在各個階段均有出現(xiàn)。而圖1b則展現(xiàn)出面向服務(wù)的軟件工程開發(fā)流程，該體系為服務(wù)組合形式MASHUP構(gòu)造。很明顯，面向服務(wù)的軟件工程開發(fā)流程更加簡單，在服務(wù)組合階段，用戶根據(jù)服務(wù)合同進(jìn)行服務(wù)尋找與發(fā)現(xiàn)，匹配需要的服務(wù)價值，大大改善了傳統(tǒng)軟件工程中的開發(fā)決策與用戶需求之間的溝通問題。

基于面向服務(wù)的軟件工程開發(fā)流程（如圖1b所示），以響應(yīng)時間服務(wù)指標(biāo)為例，我們定義ID（Ideal Design）表示每種要素的理想設(shè)計值，ND（Negative Design）表示每種要素偏離ID的設(shè)計值。另外，我們定義基于ID的變化空間（Variability Space），上 界 是VUB（Variability Upper Boundary），下 界 是VLB（Variability Lower Boundary）。假定目標(biāo)要素響應(yīng)時間的價值如表1所示。

Table 1 Value of response time表1 響應(yīng)時間價值表

Figure 1 Comparison between traditional software engineering and service oriented software engineering development圖1 傳統(tǒng)軟件工程與面向服務(wù)軟件工程開發(fā)對比

我們基于對該電子商務(wù)系統(tǒng)的分析，經(jīng)驗方式定義實際軟件產(chǎn)品開發(fā)過程的質(zhì)量與理想情形的偏離程度為SPR－QU：

其中，Ci是目標(biāo)要素的實際價值；CID是目標(biāo)的理想價值；n是所有目標(biāo)的數(shù)量。

根據(jù)上述公式計算出的表1 的SPR－QU如表2所示。

Table 2 Subject properties SPR－QU表2 目標(biāo)屬性的SPR－QU

SPR－QU的數(shù)值大小反映出軟件產(chǎn)品實際設(shè)計與理想設(shè)計之間的偏離程度。值愈大表示整體的產(chǎn)品質(zhì)量越低，反之亦然。如表2所示，不良設(shè)計的SPR－QU值已嚴(yán)重偏離變化空間。因此，基于技術(shù)決策和價值創(chuàng)造，借助質(zhì)量指標(biāo)SPR－QU可設(shè)計出使過程與產(chǎn)品質(zhì)量最大化的解決方案。假定在需求分析階段中所有設(shè)計情形均較理想，后面的開發(fā)流程才會出現(xiàn)無法精確預(yù)知或控制的情形。如在系統(tǒng)設(shè)計階段，出現(xiàn)超出理想設(shè)計價值的情形；在編碼階段，出現(xiàn)無法滿足理想設(shè)計價值的情形，且此二者價值設(shè)計均在變化空間之外，屬嚴(yán)重偏離。此外，翻譯服務(wù)、推薦服務(wù)都有相似的偏離情形。考慮現(xiàn)實的軟件開發(fā)過程，對每個流程下的每種設(shè)計目標(biāo)均需考慮所有涉眾進(jìn)行優(yōu)化，才能得到最佳的產(chǎn)品質(zhì)量和經(jīng)濟(jì)效益。因此，必須將實際設(shè)計折線限制在變化空間內(nèi)，減小SPR－QU以使其接近理想設(shè)計線。

3 質(zhì)量指標(biāo)分析

3.1 欠設(shè)計與過設(shè)計

定義1 過設(shè)計OD（Over Design）指軟件在開發(fā)過程中，軟件中間成果或者最終成果超過了期待的理想情形。這里的理想情形的評價是基于軟件經(jīng)濟(jì)的策略做出的最優(yōu)評價。實際設(shè)計相對理想設(shè)計包含了不該在該模型中出現(xiàn)的設(shè)計內(nèi)容。過設(shè)計不僅會降低在隨后設(shè)計中的系統(tǒng)綜合質(zhì)量、運(yùn)行效果和商業(yè)目標(biāo)實現(xiàn)的機(jī)率，其多余部分或者過度約束的內(nèi)容也會增加項目相對理想設(shè)計的額外時間、變更成本和金錢成本。

令過設(shè)計的系統(tǒng)模型為OD，系統(tǒng)需求模型為RM，那么OD?RM，其中，RM≠?并且OD≠?。

定義2 欠設(shè)計UD（Under Design）指軟件在開發(fā)過程中，軟件中間成果或者最終成果少于期待的理想情形。從軟件經(jīng)濟(jì)的角度評價，欠設(shè)計的內(nèi)容對應(yīng)的價值在特定評價時刻少于理想設(shè)計。欠設(shè)計會使體系在功能上有欠缺或者在性能上無法滿足要求，最終影響實現(xiàn)商業(yè)目標(biāo)，或者其本身也會造成項目變更或者維護(hù)時相對理想設(shè)計的額外時間和金錢成本。在設(shè)計未完成的情形下判別欠設(shè)計可以參照中間結(jié)果的理想情形，有時也依賴被評估設(shè)計在被評估時刻與之關(guān)聯(lián)的其它設(shè)計部分的評估情況來判斷估計。

令欠設(shè)計的系統(tǒng)模型為UD，系統(tǒng)需求模型為RM，那么UD?RM，其中，RM≠?并且UD≠?。理想設(shè)計ID（Ideal Design）與實際設(shè)計AD（Actual Design）之間的設(shè)計偏差（△D）可數(shù)值化為：

ΔD＝ID－AD

其中：

（1）若△D＞0，那么AD＜ID，實際設(shè)計不能滿足理想設(shè)計需要，出現(xiàn)了欠設(shè)計；

（2）若△D＜0，那么AD＞ID，實際設(shè)計超出了理想設(shè)計需要，出現(xiàn)了過設(shè)計。

將減少△D的問題表示為△PD，那么應(yīng)當(dāng)是系統(tǒng)中過設(shè)計與欠設(shè)計的作用之和，即：

ΔPD＝ΔPOD∪ΔPUD

其中，△PUD表示UD空間，△POD表示OD空間。

UD/OD 都是偏離理想設(shè)計的設(shè)計形式［12，16］。在軟件產(chǎn)品線中，對眾多的模型決策中設(shè)置優(yōu)先權(quán)并不容易。使用基于約束的方法［17］有益于解決此問題，同時避免欠設(shè)計和過設(shè)計。圖2的UML 圖展示了以約束（Constraint）形式平衡欠設(shè)計和過設(shè)計的一種解決策略，UD 和OD 承載了兼顧各種涉眾理解基礎(chǔ)的設(shè)計偏差評估指標(biāo)（Design Evaluation）的意義。為簡化分析我們暫時忽略了對功能的考察，著重于在完成軟件經(jīng)濟(jì)商業(yè)目標(biāo)（Business Goal）下，使用約束通過對設(shè)計過程整體的質(zhì)量（Process Quality）以及各個階段的質(zhì)量（Stage Quality）指標(biāo)的控制，來實現(xiàn)各類涉眾對減少設(shè)計偏差的需求。這些需求包括長期需求和當(dāng)前需求的范圍（Scope）形式和精確（Precise）形式。范圍形式表達(dá)的設(shè)計需求一般為當(dāng)前設(shè)計階段不宜細(xì)化的內(nèi)容。例如，確立對象屬性或方法在類繼承體系中的位置不應(yīng)當(dāng)在對其重用范圍確立之前確認(rèn)，可臨時以范圍形式表達(dá)。

Figure 2 Constraint based design圖2 基于約束的設(shè)計

3.2 質(zhì)量生命周期

在本文中，所有的質(zhì)量屬性都被假定是正交的，即它們之間不會相互影響。如表3 所列的性質(zhì)，彼此不相互影響。令Pro為質(zhì)量屬性集合，那么?x∈Pro，?y∈Pro↓｛x｝·x∩y＝?。

軟件質(zhì)量可以在功能性、質(zhì)量屬性和資源規(guī)范上定義。后面兩種定義與系統(tǒng)的非功能性需求有關(guān)。質(zhì)量評估可以通過以下幾種階段組成的軟件生命周期完成：設(shè)計階段、執(zhí)行階段、維護(hù)階段和效益評估階段。在所有涉眾的一系列調(diào)節(jié)之后將達(dá)到一致協(xié)定。表3 展示了質(zhì)量屬性QP（Quality Property）和相關(guān)聯(lián)的評估標(biāo)準(zhǔn)CR（CRiteria）。

Table 3 Evaluation items of software quality表3 軟件質(zhì)量評估條目

3.3 質(zhì)量經(jīng)濟(jì)

質(zhì)量經(jīng)濟(jì)是一種衡量消費(fèi)者為達(dá)到其理想產(chǎn)品質(zhì)量而愿意花費(fèi)的價值。在相同的質(zhì)量標(biāo)準(zhǔn)下，資源花費(fèi)得越少，則質(zhì)量經(jīng)濟(jì)越好?；趦r值分析的角度，SPR－QU越低，那么產(chǎn)品價值越高，質(zhì)量經(jīng)濟(jì)越好。而通過下面兩個階段的優(yōu)化設(shè)計便可得到最佳的產(chǎn)品質(zhì)量。

（1）設(shè)計時（Design Time）服務(wù)利益權(quán)衡。

在這個質(zhì)量協(xié)商的利益權(quán)衡點，所有利益相關(guān)者必須在質(zhì)量經(jīng)濟(jì)上達(dá)成一致，使其滿意度達(dá)到最大化［18］。因此，第i個質(zhì)量屬性的利益相關(guān)點可以表示為：

其中，Vi表示第i個質(zhì)量屬性量化價值；Wij表示在特定質(zhì)量屬性下的第j個涉眾權(quán)重。

通過對系統(tǒng)設(shè)計和執(zhí)行過程的動態(tài)調(diào)整，AG（Vi）｜STG將可以取到最大值。這種動態(tài)調(diào)整被稱為CG－STG，其可變域稱為CPCG－STG。

以第2節(jié)的運(yùn)行實例為例，可以計算出考慮所有涉眾的最優(yōu)質(zhì)量值。對于每個質(zhì)量目標(biāo)，有若干的設(shè)計值可以選擇。這里以需求分析階段下的翻譯服務(wù)為例，假設(shè)其有1美元、2美元和3美元共三個可選價值（Vi）。由于對于每種設(shè)計值都有不同的權(quán)重，選取三個涉眾，亦得到矩陣Wij。

依據(jù)實際情形，這里的每種權(quán)重（行向量）不滿足和為1，例如，對于3美元的質(zhì)量屬性所有涉眾都可以拒絕。經(jīng)過簡單的計算，得到對于每個質(zhì)量屬性的綜合后的價值：

因此，最優(yōu)值是2.7，對應(yīng)著2美元是在翻譯服務(wù)上的最優(yōu)價值。此時在需求分析階段得到了翻譯服務(wù)的最大價值，并且考慮到所有涉眾。

（2）運(yùn)行時（Runtime）服務(wù)利益權(quán)衡。

與獨立階段的利益權(quán)衡類似，動態(tài)階段的利益權(quán)衡也是建立在所有利益相關(guān)者的價值最大化基礎(chǔ)之上的。不同的是，在動態(tài)階段中的權(quán)重是實時變化的，因此，動態(tài)利益權(quán)衡可以表示為：

其中，Vi是第i個質(zhì)量屬性價值；j∈N 是第j個利益相關(guān)者（涉眾）；k∈N是第k個階段；Wij是第j個利益相關(guān)者的權(quán)重；fk（）是第k個狀態(tài)中第j個利益相關(guān)者的權(quán)重。

為了得到最佳的AG（Vi）｜QL，需要對設(shè)計要素的利用率、關(guān)聯(lián)階段的進(jìn)程進(jìn)行干預(yù)優(yōu)化。這種優(yōu)化標(biāo)記為CG－QL。這種變化的可變域標(biāo)記為CPCG－QL。這里的分析與靜態(tài)分析相似，由于篇幅所限，不再詳述。

4 問題－質(zhì)量－約束（PQC）

為了減少過設(shè)計和欠設(shè)計對系統(tǒng)設(shè)計產(chǎn)生的影響，通過“問題－質(zhì)量－約束”PQC（Problem－Quality－Constraint）來解決軟件項目生命周期中的質(zhì)量保證問題。

4.1 問題建模

問題建模具體由功能建模和過程建模來實現(xiàn)，主要分為抽象層次上的功能建模和過程建模兩個方面。

（1）抽象層次上的功能建模。

合理的系統(tǒng)架構(gòu)能縮短項目安排和預(yù)期系統(tǒng)實現(xiàn)上的差距［19，20］。在理想模型設(shè)計層次上建立相應(yīng)參考模型。此參考模型考慮到軟件項目系統(tǒng)架構(gòu)中的過設(shè)計和欠設(shè)計，并希望通過減少這兩種情形來提高軟件質(zhì)量的滿意度。

（2）過程建模。

過程建模是根據(jù)軟件產(chǎn)品實際開發(fā)的流程來建立尋找最優(yōu)價值的建模。這種建模具有動態(tài)和實時的特點。

4.2 改進(jìn)的質(zhì)量建模

對于一些有非功能性需求的利益相關(guān)者而言，在系統(tǒng)設(shè)計時有必要控制預(yù)定的變化空間［10］，代表某種質(zhì)量要求，用NFRV表示。除明確描述NFRV設(shè)計外，最重要的目標(biāo)是壓縮質(zhì)量生命周期的變化空間，減少過設(shè)計和欠設(shè)計的空間。因此，在開發(fā)過程中，有必要從所有涉眾的角度來確定一個質(zhì)量要求，用NFRP表示。文獻(xiàn)［21］中描述的質(zhì)量模型（QMS）由NFRp并NFRV，并作為先決條件滿足系統(tǒng)實現(xiàn)，公式定義為：

QMS＝NFRV∪NFRP

在模型中，需最大限度考慮所有已知信息，其中超出合適設(shè)計上邊界將變成過設(shè)計。如運(yùn)行實例中系統(tǒng)設(shè)計階段的翻譯服務(wù)價值，在嚴(yán)重偏離設(shè)計情形下已經(jīng)超出變化空間上限，出現(xiàn)過設(shè)計。在模型中，需最小限度考慮所有未知信息，其中超出合適設(shè)計下邊界將變成欠設(shè)計。如運(yùn)行實例中編碼階段的翻譯服務(wù)價值，在嚴(yán)重偏離設(shè)計情形下已經(jīng)超出變化空間下限，出現(xiàn)欠設(shè)計。因此，在實際的軟件產(chǎn)品線中，基于系統(tǒng)價值或質(zhì)量控制即是在實際設(shè)計流程中通過將設(shè)計值限制在變化空間內(nèi)來減少欠設(shè)計和過設(shè)計的因素，使系統(tǒng)綜合價值最大化。

5 案例研究

在本節(jié)中，將對第2節(jié)的運(yùn)行實例進(jìn)行功能拓展，運(yùn)用基于過設(shè)計和欠設(shè)計的服務(wù)質(zhì)量控制理論，對比Web服務(wù)在電子商務(wù)中的設(shè)計情形，驗證避免過設(shè)計與欠設(shè)計的必要性。

5.1 電子商務(wù)特征模型

圖3有兩種服務(wù)結(jié)構(gòu)類型：靜態(tài)類型和動態(tài)類型。靜態(tài)類型描述了一個工作流模型的服務(wù)組合設(shè)計；而動態(tài)類型描述了一個基于SLA 協(xié)議的服務(wù)編舞組合設(shè)計，其服務(wù)構(gòu)件成員動態(tài)組合。假定設(shè)計A是一個理想設(shè)計，設(shè)計B是一個實際設(shè)計。

（1）靜態(tài)類型。如圖3中左邊所示，所有的服務(wù)都被定義為靜態(tài)的。在設(shè)計A中的推薦汽車服務(wù)（Car）在設(shè)計B中被設(shè)計成了音樂服務(wù)（Music），在設(shè)計A中的住宿代理服務(wù)（Accommodation Agent）在設(shè)計B中被取消，在設(shè)計A中的并行（And）關(guān)系在設(shè)計B中被設(shè)計成了多選一（Or）關(guān)系。顯然這個設(shè)計是一個欠設(shè)計。

（2）動態(tài)類型。動態(tài)結(jié)構(gòu)是新的概念，它通過創(chuàng)建一個連續(xù)的服務(wù)流，形成一個特定的動態(tài)服務(wù)。圖3中右邊的投票器系統(tǒng)就是動態(tài)類型。例如，在設(shè)計B中的投票器（Responder Auction）相對設(shè)計A多了一個，并且投票器的多選一被設(shè)計成了并行結(jié)構(gòu)。顯然這個設(shè)計是一個過設(shè)計。在電子商務(wù)系統(tǒng)中，價值（Value）和價值增益（Value Added）的總和分別由系統(tǒng)中所有服務(wù)組件價值和價值增益的和組成。

上述分析是針對單獨的服務(wù)質(zhì)量進(jìn)行的精確設(shè)計。在實際的軟件項目中，總是希望可以更精確地控制軟件生產(chǎn)的過程。然而，在很多情況下是不實際甚至是不可行的。解決方案就是動態(tài)設(shè)計。有必要把足夠大的變化空間留給“未知”的設(shè)計因素，從而避免陷入嚴(yán)重的欠設(shè)計和過設(shè)計情形。因此，尋求一個精確設(shè)計的代價是昂貴的。例如，在設(shè)計B中有比設(shè)計A更多的服務(wù)組合，設(shè)計B可選擇性強(qiáng)，設(shè)計價值也更高，但此時卻不是最佳的服務(wù)設(shè)計，這里出現(xiàn)了過設(shè)計。由圖3可知，每個服務(wù)組件對應(yīng)特定的價值。例如，推薦服務(wù)（Recommendation）、購買記錄服務(wù)（Purchase Record）和私人信息（Privacy Information）服務(wù)雖然不在一級，但都屬于系統(tǒng)服務(wù)，故計算時需要全局考慮。每個圖例產(chǎn)生若干種不同服務(wù)組合。

Figure 3 Comparison between design Aand design B圖3 設(shè)計A 與設(shè)計B 的對比

5.2 服務(wù)組合統(tǒng)計分析

為闡述理想設(shè)計與包含過設(shè)計和欠設(shè)計的實際設(shè)計之間的差異，建立了一個計算所有服務(wù)組件價值總和的實驗?zāi)Ｐ?。使用兩種質(zhì)量權(quán)衡指標(biāo)：價值與附加值。價值是指設(shè)計時綜合考慮技術(shù)決策、用戶需求和所有涉眾的最優(yōu)值。附加值是指特定服務(wù)設(shè)計帶來的收益。顯然服務(wù)價值越高，其附加值越高。如表4所示，依據(jù)經(jīng)驗假設(shè)出服務(wù)組件的價值和附加值。選取了部分服務(wù)用于過設(shè)計和欠設(shè)計計算過程中的利益權(quán)衡。如表5 所示，其中WE表示天氣服務(wù)，PA 表示支付驗證服務(wù)，SA 表示安全服務(wù)，SE－BA 表示服務(wù)帶寬服務(wù)，IN 表示接口服務(wù)。表5各列分別描述需求、設(shè)計、編碼、測試以及部署，數(shù)值分別代表所需要花費(fèi)的成本百分比。

Table 4 Values and values added of service components表4 服務(wù)組件的價值與附加值

Table 5 Cost vs service in percentage表5 服務(wù)與成本百分比

令五個服務(wù)依次得到不同的權(quán)重，進(jìn)行利益權(quán)衡，計算矩陣如下：

我們計算綜合后的質(zhì)量屬性的價值如下所示：

從結(jié)果上看，對于場景1，SA 服務(wù)最優(yōu)；對于場景2，PA 服務(wù)最優(yōu)；對于場景3，IN 服務(wù)最優(yōu)；對于場景4，SE－BA 服務(wù)最優(yōu)；對于場景5，WE 服務(wù)最優(yōu)。這些服務(wù)在各自實現(xiàn)過程中，需要重點關(guān)注。

6 相關(guān)工作

Dao T M 等人［22］嘗試了定義一個問題解決框架來控制軟件設(shè)計中的非功能性需求指標(biāo)。Alebrahim A 和Heisel M［23］提出了一個UML原型來構(gòu)建問題描述質(zhì)量模型?，F(xiàn)有大多數(shù)方法基于對質(zhì)量的過后分析，而指導(dǎo)系統(tǒng)開發(fā)過程中則需要預(yù)先分析或者實時解決方案。本文提供一個系統(tǒng)性指導(dǎo)設(shè)計，并闡述基于約束驅(qū)動的設(shè)計方法。Eiffel M B［24］表述了一種基于軟件規(guī)約的約束實現(xiàn)方案。Boogie［25］給出限定預(yù)條件和傳輸條件（Pre－＆Post－Conditions）來控制程序流中的非確定性因素。但是，兩者都限于開發(fā)流程的編碼階段，無法用于整個軟件開發(fā)流程。Czarnecki K 等人［26］證實了功能模型映射與決策模型間存在缺口，他們歸結(jié)缺口存在的部分原因是在綁定策略的執(zhí)行和質(zhì)量屬性實現(xiàn)之間缺少明確認(rèn)知和關(guān)聯(lián)。本文引入過設(shè)計與欠設(shè)計的概念來彌合此缺口。Demuth A 等人［16］提出了基于約束的方法來挑選設(shè)計方案。而本文的方法是利用基于約束的模型從協(xié)助設(shè)計過渡到驅(qū)動整個設(shè)計流程。由于PQC與模型質(zhì)量的變化密切相關(guān)，因此，它能夠補(bǔ)充實現(xiàn)更高層次的決定［22，23］。PQC也將適用于系統(tǒng)設(shè)計的新趨勢，如MASHUP［11］的系統(tǒng)是建立在以下三者之上：具有獨立功能的服務(wù)、記錄在相應(yīng)電子合同中的QoS 和體現(xiàn)商業(yè)價值最大化的服務(wù)代理模式（SVB）［10］。

7 結(jié)束語

軟件開發(fā)過程的工程性目標(biāo)是生產(chǎn)出優(yōu)異的軟件產(chǎn)品。一個軟件產(chǎn)品的評價既要從技術(shù)角度評價軟件功能和性能，從軟件經(jīng)濟(jì)的角度考慮，評價所依據(jù)的更本質(zhì)的是軟件系統(tǒng)對項目實施各涉眾的價值增益衡量。軟件經(jīng)濟(jì)的價值衡量涵蓋了包括設(shè)計時和運(yùn)行時的整個軟件生命期的各個階段。為了實現(xiàn)對每個階段從商業(yè)分析到技術(shù)實現(xiàn)的關(guān)聯(lián)評價，理論上要求對相關(guān)涉眾的跨越商業(yè)分析和技術(shù)實現(xiàn)的評價支持。這種評價應(yīng)當(dāng)是建立在相關(guān)涉眾對相關(guān)開發(fā)階段的理解和信息流通的基礎(chǔ)上的。然而，當(dāng)前實現(xiàn)對在整個軟件生命期中溝通跨越商業(yè)分析和技術(shù)實現(xiàn)這兩個層面的涉眾的共同理解和交流這一需求的支持尚不足夠。對比傳統(tǒng)軟件工程開發(fā)過程和Web服務(wù)系統(tǒng)開發(fā)過程，我們認(rèn)識到Web 服務(wù)本身有別于傳統(tǒng)軟件系統(tǒng)，它既是一種商業(yè)建模元素又是技術(shù)實現(xiàn)元素，從而Web服務(wù)組合潛在地可以更有效地集成商業(yè)分析和技術(shù)建模來實現(xiàn)軟件經(jīng)濟(jì)的策略。針對銜接商業(yè)分析和技術(shù)建模，我們認(rèn)為在概念層次應(yīng)該提供有效的橋接商業(yè)領(lǐng)域的價值分析和技術(shù)領(lǐng)域的QoS指標(biāo)的中間概念，來支持相關(guān)涉眾的跨域信息交流和溝通。具體地，我們在模型驅(qū)動軟件開發(fā)的背景下依據(jù)經(jīng)驗提出以約束為主要設(shè)計形式的解決方案，稱為約束驅(qū)動設(shè)計，并選擇了過設(shè)計和欠設(shè)計作為中間概念輔助實現(xiàn)價值驅(qū)動（Value Driven）的開發(fā)過程。我們討論了相關(guān)概念的內(nèi)涵并基于其構(gòu)造了相關(guān)的方法框架來基于約束［27，28］填補(bǔ)整個軟件生命周期中預(yù)期設(shè)計與最終設(shè)計之間的設(shè)計缺口，幫助實現(xiàn)整個業(yè)務(wù)細(xì)化和設(shè)計模型演化兩個過程的集成。該方案從保證過程質(zhì)量的角度管理抽象的設(shè)計決策變化空間。此外，此方案亦可用于在一個動態(tài)的過程上減輕質(zhì)量損失，有利于對OD 或UD 的影響做出選擇。

未來我們計劃圍繞軟件經(jīng)濟(jì)和可變性技術(shù)，將本方法運(yùn)用到實際系統(tǒng)的需求設(shè)計、功能組合、運(yùn)行維護(hù)和質(zhì)量評估中，并集成功能性需求和非功能性需求。我們還將進(jìn)一步研究欠設(shè)計和過設(shè)計服務(wù)系統(tǒng)到目標(biāo)系統(tǒng)的自動化轉(zhuǎn)換方案。

［1］ Wang Shang－guang，Sun Qi－bo，Yang Fang－chun.Web service dynamic selection by the decomposition of global QoS constraints［J］.Journal of Software，2011，22（7）：1426－1439.（in Chinese）

［2］ Boehm B W，Sullivan K J.Software economics：A roadmap［C］∥Proc of the Future of Software Engineering，2000：319－343.

［3］ Pautasso C，Alonso G.Flexible binding for reusable composition of web services［C］∥Proc of the 4th International Conference on Software Composition，2005：151－166.

［4］ Yue Kun，Wang Xiao－ling，Zhou Ao－ying.Underlying techniques for web services：A survey［J］.Journal of Software，2004，15（3）：4－28.（in Chinese）

［5］ Garlan D.Software architecture：A raodmap［C］∥Proc of the Fureture of Software Engineering，2000：91－101.

［6］ Gamma E，Helm R，Johnson R E，et al.Design patterns：Abstraction and reuse of object－oriented design［C］∥Proc of the 7th European Conference on Object－Oriented Programming，1993：406－431.

［7］ Ogrinz M.Mashup patterns：Designs and examples for the modern enterprise［M］.1st ed.Boston：Addison－Wesley Professional，2009.

［8］ Duan Y.A survey on service contract［C］∥Proc of the 13th ACIS International Conference on Software Engineering，Artificial Intelligence， Networking and Parallel/Distributed Computing，2012：805－810.

［9］ Kattepur A，Benveniste A，Jard C.Negotiation strategies for probabilistic contracts in web services orchestrations［C］∥Proc of ICWS，2012：106－113.

［10］ Duan Y，Kattepur A，Zhou H，et al.Service value broker patterns：An empirical collection［C］∥Proc of SNPD，2013：675－682.

［11］ Al－Naeem T，Gorton I，Babar M，et al.A quality－driven systematic approach for architecting distributed software applications［C］∥Proc of ICSE，2005：244－253.

［12］ Drago M L，Ghezzi C，Mirandola R.A quality driven extension to the QVT－relations transformation language［J］.Computer Science－Research and Development，2011（11），DOI 10.1007/s00450－011－0202－0.

［13］ Lee K，Kang K C，Lee J.Concepts and guidelines of feature modeling for product line software engineering［M］∥Software Reuse：Methods，Techniques，and Tools，Berlin：Springer，2002：62－77.

［14］ Duan Y，Lee R.Knowledge management for model driven data cleaning of very large database［M］∥Software Engineering，Artifical Intelligence，Networking and Parallel/Distributed Computing，Berlin：Springer－Verlag，2013：143－158.

［15］ Duan Y，Kattepury A，Getahun F，et al.Releasing the power of varibility：Towards constraint driven quality assurance［C］∥Proc of IEEE AAI/ESKM，2013：15－20.

［16］ Schobbens P Y，Heymans P，Trigaux J C.Feature diagrams：A survey and a formal semantics［C］∥Proc of the 14th IEEE International Conference on Requirements Engineering，2006：136－145.

［17］ Demuth A，Lopez－h(huán)errejon R E，Egyed A.Constraint－driven modeling through transformation［C］∥Proc of ICMT’12，2012：248－263.

［18］ Feldstein M.Domestic saving and international capital movements in the long run and the short run［J］.European Economic Review，1983，21（1－2）：129－151.

［19］ Nassaj A，Lienig J.A new methodology for constraint－driven layout design of analog circuits［C］∥Proc of ICECS，2009：996－999.

［20］ Group O M.Formal/2011－08－05，OMG unified modelling language（OMG UML），Infrastructure［S］.OMG，2011.

［21］ Chung L，do Prado Leite C S.On non－functional requirements in software engineering［M］∥Conceptual Modeling：Foundations and Applications，Berlin：Springer，2009：363－379.

［22］ Dao T M，Lee H，Kang K C.Problem frames－based approach to achieving quality attributes in software product line engineering［C］∥Proc of the 15th International Conference on Software Product Line，2011：175－180.

［23］ Alebrahim A，Heisel M.Supporting quality－driven design decisions by modeling variability［C］∥Proc of the 8th International ACM SIGSOFT Conference on Quality of Software Architectures，2012：43－48.

［24］ Meyer B.Eiffel：A language and environment for software engineering［J］.The Journal of Systems and Software，1988，8（3）：199－246.

［25］ Barnett M，Chang B E，Deline R，et al.Boogie：A modular reusable verifier for object－oriented programs［C］∥Proc of FMCO’05，2006：364－387.

［26］ Czarnecki K，Grünbacher P，Rabiser R，et al.Cool features and tough Decisions？：A comparison of variability modeling approaches［C］∥Proc of the 6th International Workshop on Variability Modeling of Software－Intensive Systems，2012：173－182.

［27］ Egyed A，Wile D S.Support for managing design－time decisions［J］.IEEE Transactions on Software Engineering，2006，32（5）：299－314.

［28］ Lano K.Constraint－driven development［J］.Journal of Information and Software Technology，2008，50（5）：406－423.

附中文參考文獻(xiàn)：

［1］ 王尚廣，孫其博，楊放春.基于全局QoS約束分解的Web服務(wù)動態(tài)選擇［J］.軟件學(xué)報，2011，22（7）：1426－1439.

［4］ 岳昆，王曉玲，周傲英.Web服務(wù)核心支撐技術(shù)：研究綜述［J］.軟件學(xué)報，2004，15（3）：4－28.