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

（1.海南大學信息科學技術學院，海南 海口570288；2.上海大學計算中心，上海200444）

1 引言

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

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

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

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

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

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

1.3 基于可變性的建模

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

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

（1）介紹了以軟件經濟為驅動，以綜合質量為目標，權衡過程質量的質量建模和質量評估。

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

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

2 運行實例

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

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

Table 1 Value of response time表1 響應時間價值表

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

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

其中，Ci是目標要素的實際價值；CID是目標的理想價值；n是所有目標的數量。

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

Table 2 Subject properties SPR－QU表2 目標屬性的SPR－QU

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

3 質量指標分析

3.1 欠設計與過設計

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

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

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

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

ΔD＝ID－AD

其中：

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

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

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

ΔPD＝ΔPOD∪ΔPUD

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

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

Figure 2 Constraint based design圖2 基于約束的設計

3.2 質量生命周期

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

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

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

3.3 質量經濟

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

（1）設計時（Design Time）服務利益權衡。

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

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

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

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

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

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

（2）運行時（Runtime）服務利益權衡。

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

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

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

4 問題－質量－約束（PQC）

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

4.1 問題建模

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

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

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

（2）過程建模。

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

4.2 改進的質量建模

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

QMS＝NFRV∪NFRP

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

5 案例研究

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

5.1 電子商務特征模型

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

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

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

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

Figure 3 Comparison between design Aand design B圖3 設計A 與設計B 的對比

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

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

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

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

令五個服務依次得到不同的權重，進行利益權衡，計算矩陣如下：

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

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

6 相關工作

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

7 結束語

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

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

［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.

附中文參考文獻：

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

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