TRIZ技術(shù)系統(tǒng)演進(jìn)視角的計算機(jī)輔助創(chuàng)新軟件體系架構(gòu)

李牧南，熊俊霞，許 治，蘇錦鈿

0 引言

隨著各種新材料、新技術(shù)的發(fā)展，以及消費(fèi)需求的不斷多樣化和個性化，工業(yè)和服務(wù)業(yè)新產(chǎn)品的開發(fā)變得越來越復(fù)雜。同時，隨著市場競爭的加劇，新產(chǎn)品開發(fā)也面臨更高的技術(shù)和市場風(fēng)險。因此，作為新產(chǎn)品開發(fā)重要的支撐平臺——計算機(jī)輔助創(chuàng)新軟件（Computer Aided Innovation，CAI），就面臨著不斷更新和適應(yīng)新需求的挑戰(zhàn)。例如在當(dāng)前的工業(yè)設(shè)計中，模糊前端的設(shè)計思想需要集成更多不同領(lǐng)域的知識庫，有些制造性企業(yè)甚至提出能否在新產(chǎn)品設(shè)計階段就導(dǎo)入六西格瑪、精益制造等思想；此外，工業(yè)設(shè)計如何進(jìn)一步滿足新產(chǎn)品開發(fā)過程中的用戶需求建模、團(tuán)隊協(xié)同創(chuàng)新、知識管理與知識沉淀等，這些新增需求都給傳統(tǒng)的計算機(jī)輔助創(chuàng)新平臺（軟件）的體系架構(gòu)提出了更高的要求。傳統(tǒng)CAI軟件的體系架構(gòu)需要不斷進(jìn)化和變革，以構(gòu)建更加開放、柔性、可擴(kuò)展的CAI軟件。本文從發(fā)明問題解決理論（Theory of Invention Problem Solving，TRIZ）的技術(shù)系統(tǒng)進(jìn)化理論出發(fā)，從一個較新的視角探討了軟件系統(tǒng)架構(gòu)的技術(shù)演化路徑，并結(jié)合當(dāng)前國內(nèi)外主流的CAI軟件的體系架構(gòu)特點，提出了基于面向服務(wù)架構(gòu)（Service－Oriented Architecture，SOA）的新一代CAI軟件體系架構(gòu)設(shè)計的總體解決思路和設(shè)計框架。

軟件體系架構(gòu)的演化始終緊跟著計算機(jī)硬件、網(wǎng)絡(luò)技術(shù)、管理技術(shù)和軟件技術(shù)自身的發(fā)展。軟件開發(fā)依然是目前人類生產(chǎn)實踐中最復(fù)雜的團(tuán)隊協(xié)作活動之一。軟件工程作為一種復(fù)雜的系統(tǒng)工程，其目的就是為了降低軟件開發(fā)過程的風(fēng)險和成本，保證項目或者產(chǎn)品開發(fā)進(jìn)度和質(zhì)量。軟件體系架構(gòu)設(shè)計是整個軟件工程的核心環(huán)節(jié)。首先，軟件體系架構(gòu)設(shè)計包括對用戶或者產(chǎn)品設(shè)計需求進(jìn)行分析，構(gòu)建組織業(yè)務(wù)流程模型，以及對系統(tǒng)（產(chǎn)品）各模塊之間的交互任務(wù)和通信接口進(jìn)行準(zhǔn)確定義等重要內(nèi)容［1］；其次，體系架構(gòu)是后續(xù)的詳細(xì)設(shè)計，是代碼和測試的基準(zhǔn)性參考。根據(jù)國外軟件工程的應(yīng)用實例調(diào)查，需求工程和體系架構(gòu)設(shè)計的潛在缺陷在后續(xù)階段會逐漸放大，甚至導(dǎo)致軟件項目徹底失敗。舉一個極端例子，假設(shè)在設(shè)計階段沒有考慮到用戶的分布式需求，以及客戶端操作系統(tǒng)的差異，系統(tǒng)功能實現(xiàn)采取了傳統(tǒng)的客戶機(jī)／服務(wù)器（Client／Server，C／S）架構(gòu)，可能導(dǎo)致最終上線之后的軟件產(chǎn)品出現(xiàn)巨大的客戶端版本控制和協(xié)調(diào)問題，以及并發(fā)響應(yīng)所帶來的性能問題，此時整個系統(tǒng)可能面臨推倒重來的風(fēng)險。

1 軟件體系結(jié)構(gòu)的技術(shù)系統(tǒng)演化分析

在軟件工程的實施中，由于存在“缺陷放大”效應(yīng)，對軟件架構(gòu)設(shè)計的靈活性、動態(tài)性，甚至自適應(yīng)性都提出了較高的要求［2］。因此，軟件系統(tǒng)的設(shè)計需要采用符合技術(shù)系統(tǒng)進(jìn)化方向的設(shè)計理念和技術(shù)，延長軟件產(chǎn)品自身的發(fā)展期和成熟期，從而獲得更好的推廣和經(jīng)濟(jì)效益。

1.1 基于TRIZ技術(shù)系統(tǒng)進(jìn)化法則的軟件體系結(jié)構(gòu)進(jìn)化路徑分析

TRIZ之父阿奇舒勒通過對專利技術(shù)的分析發(fā)現(xiàn)，所有技術(shù)系統(tǒng)的進(jìn)化并非完全遵循隨機(jī)性原則，而是遵循一定的規(guī)律或法則，這就是TRIZ歸納和總結(jié)的技術(shù)系統(tǒng)8大進(jìn)化法則［3－4］。目前，TRIZ與軟件工程、管理理論與方法等領(lǐng)域的結(jié)合，也是比較熱點的研究［5－8］。結(jié)合基于 TRIZ的8大技術(shù)系統(tǒng)進(jìn)化法則，這里以其中3個原則為例，分析軟件體系架構(gòu)的技術(shù)演變軌跡。

1.1.1 理性度的趨近法則

TRIZ認(rèn)為“向最終理想化”方向進(jìn)化是所有技術(shù)系統(tǒng)始終遵循的法則。軟件體系架構(gòu)作為一個技術(shù)系統(tǒng)，從誕生到發(fā)展的過程，也可以認(rèn)為是完全按照該進(jìn)化原則進(jìn)行。一般來說，理想度的表示公式為［3－4］

對于軟件系統(tǒng)來說，以最低的成本和代價滿足用戶的需求和功能，減少系統(tǒng)的不穩(wěn)定性，增加系統(tǒng)的可擴(kuò)展性和可維護(hù)性，一直是軟件工程的目標(biāo)。軟件體系架構(gòu)從最初的胖客戶端到瘦客戶端，從面向?qū)ο蟮矫嫦蚪M件，從傳統(tǒng)的兩層（C／S）到三層體系（C／S／S），以及 N－tier的體系結(jié)構(gòu)的演變都是這種理想度法則進(jìn)化的結(jié)果。

軟件體系架構(gòu)作為軟件工程最大的復(fù)用構(gòu)件，其進(jìn)化的目標(biāo)就是提高軟件的復(fù)用水平、提高軟件整體的成產(chǎn)效率、降低成本，并提高系統(tǒng)整體的功能和性能水平。

1.1.2 增加系統(tǒng)動態(tài)性與可控制性法則

TRIZ關(guān)于增加系統(tǒng)動態(tài)性與可控制性的法則包括三個具體演化方向［3］：①增加系統(tǒng)柔性；②增加系統(tǒng)可移動性；③增加系統(tǒng)可控制性。軟件系統(tǒng)架構(gòu)從當(dāng)初的機(jī)器語言、匯編語言架構(gòu)，一直到今天的面向?qū)ο?、面向Agent、面向服務(wù)的體系架構(gòu)，可以清晰地看到向這三個方向的演化進(jìn)程。例如機(jī)器語言體系架構(gòu)—匯編語言體系架構(gòu)—結(jié)構(gòu)化編程體系架構(gòu)—面向?qū)ο篌w系架構(gòu)，就是不斷增加系統(tǒng)柔性和可控性的過程。“面向?qū)ο蟆嫦驑?gòu)件→面向A－gent”的路線顯然是體系架構(gòu)在向增加系統(tǒng)移動性方面的進(jìn)化努力。

1.1.3 增加集成度再進(jìn)行化簡法則

這條技術(shù)進(jìn)化原則認(rèn)為技術(shù)系統(tǒng)首先會趨于結(jié)構(gòu)復(fù)雜化，例如：通過增加系統(tǒng)構(gòu)件數(shù)量來提高系統(tǒng)的功能，然后再逐漸簡化系統(tǒng)。面向?qū)ο蟮能浖夹g(shù)出現(xiàn)的目的之一就是為了滿足功能需求不斷增長的需要。當(dāng)人們?nèi)粘５墓ぷ骱蜕钤絹碓揭蕾囓浖到y(tǒng)時，如銀行、電信、航空和政府等主要部門開始實施信息化時，傳統(tǒng)結(jié)構(gòu)化編程的模式無法滿足如此復(fù)雜的功能需求。面向?qū)ο蠹夹g(shù)的發(fā)展衍生了基于構(gòu)件的軟件體系架構(gòu)，可以將功能需求經(jīng)過分解后，以構(gòu)件（J2EE中的Java企業(yè)柄（Enterprise JavaBean，EJB）、COM＋、公共對象請求代理結(jié)構(gòu)（Common Object Request Broker Architecture，CORBA）等）的方式進(jìn)行集成和組合。盡管單純進(jìn)行業(yè)務(wù)功能封裝的方式滿足了復(fù)雜的功能性需求，但是也逐漸面臨著巨大的性能和維護(hù)風(fēng)險。軟件工程架構(gòu)師不得不將原來粒度較大的構(gòu)件重新進(jìn)行分解，并開始考慮利用客戶端的計算資源，這就是分布式軟件架構(gòu)思想的出發(fā)點之一，例如面對海量的互聯(lián)網(wǎng)下載任務(wù)事件，P2P技術(shù)就是通過簡化服務(wù)器端構(gòu)件的設(shè)計復(fù)雜性，充分利用客戶端的計算和網(wǎng)絡(luò)資源，從而提高整體的文件下載效率。體系架構(gòu)集成再簡化的路徑示意圖如圖1所示。

面向?qū)ο蠹夹g(shù)誕生以來，出現(xiàn)了以微軟和SUN公司為代表的兩種主流開發(fā)語言和工具提供商，也出現(xiàn)了微軟COM＋與SUN公司的EJB組件如何兼容和交互的問題。SOA的出現(xiàn)正是出于對這些異構(gòu)組件集成的需要，通過采取基于標(biāo)準(zhǔn)的 Web service封裝和簡單對象訪問協(xié)議（Simple Object Access Protocol，SOAP）實現(xiàn)異構(gòu)組件之間的訪問和交互。

1.2 基于技術(shù)系統(tǒng)進(jìn)化法則的軟件體系架構(gòu)進(jìn)化模式

從軟件體系架構(gòu)發(fā)展的歷史來看，至少可以找到TRIZ技術(shù)進(jìn)化規(guī)則中的3條來較好地描述軟件體系架構(gòu)進(jìn)化的趨勢。根據(jù)這3條進(jìn)化規(guī)則以及軟件體系架構(gòu)的演化歷史，軟件系統(tǒng)架構(gòu)技術(shù)的進(jìn)化模式如圖2所示。

從圖2可以看出，當(dāng)前軟件系統(tǒng)架構(gòu)技術(shù)進(jìn)化的路線與TRIZ技術(shù)系統(tǒng)演化的規(guī)則基本吻合，同時當(dāng)前主流的系統(tǒng)架構(gòu)是具有工業(yè)標(biāo)準(zhǔn)的SOA和相關(guān)技術(shù)［9－10］。隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展，以及現(xiàn)有信息系統(tǒng)之間通信的需求，具有支持標(biāo)準(zhǔn)化、跨平臺、異構(gòu)組件之間通信、松耦合和高復(fù)用等特點的SOA思想逐漸成為軟件體系架構(gòu)設(shè)計的主流思想之一。不可否認(rèn)，盡管與傳統(tǒng)的面向?qū)ο螅M件架構(gòu)相比，SOA出現(xiàn)的時間還不長，尚不能完全取代傳統(tǒng)的面向?qū)ο蟮捏w系架構(gòu)設(shè)計。對于基于SOA的應(yīng)用來說，盡管當(dāng)前還存在.Net和J2EE兩種主流應(yīng)用框架的異構(gòu)問題，但是面向服務(wù)的思想已經(jīng)逐漸得到了軟件工程領(lǐng)域的廣泛認(rèn)可。尤其是隨著云計算、物聯(lián)網(wǎng)、普適計算等多種跨平臺、計算終端異構(gòu)等應(yīng)用場景的出現(xiàn)，SOA架構(gòu)無疑具有更廣闊的應(yīng)用前景。例如：在一個典型物聯(lián)網(wǎng)應(yīng)用系統(tǒng)中，支持無線射頻識別（Radio Frequency Identification，RFID）讀寫的程序或者設(shè)備可能是基于傳統(tǒng)的C語言的應(yīng)用，企業(yè)的企業(yè)資源計劃（Enterprise Resource Planning，ERP）系統(tǒng)則采用J2EE架構(gòu)，而企業(yè)的郵件或者OA系統(tǒng)又是基于微軟的.Net技術(shù)架構(gòu)，此時如何實現(xiàn)不同信息系統(tǒng)之間的交互、整合和復(fù)用，SOA模型就是一個目前為止比較有效的解決方案。盡管SOA還存在服務(wù)模塊之間協(xié)同性差、缺乏主動任務(wù)發(fā)現(xiàn)機(jī)制和橫向關(guān)注點支撐等問題，但是依然代表目前軟件體系架構(gòu)發(fā)展的方向［9］。

本文對SOA的定位可能存在一定爭議，有學(xué)者或許會認(rèn)為面向Agent體系架構(gòu)（Agent－Oriented Architecture，AOA）應(yīng)該是更為先進(jìn)的體系架構(gòu)。實際上，AOA思想的出現(xiàn)比SOA思想早10年左右，但是長期以來缺乏工業(yè)化應(yīng)用和行業(yè)標(biāo)準(zhǔn)的支持，以及各種Agent平臺之間的融合問題，導(dǎo)致AOA難以真正走向行業(yè)和企業(yè)級應(yīng)用［11］。不可否認(rèn)，AOA在系統(tǒng)的適應(yīng)性、協(xié)作性、反應(yīng)式系統(tǒng)等領(lǐng)域優(yōu)于SOA的思想，但是SOA具有簡潔、直觀和容易實現(xiàn)的特征，因此當(dāng)前基于SOA的行業(yè)應(yīng)用比AOA廣泛得多［12］。

2 當(dāng)前主流計算機(jī)輔助創(chuàng)新軟件的特點及其體系架構(gòu)分析

CAI技術(shù)是將TRIZ理論、現(xiàn)代工業(yè)設(shè)計、自然語言處理和計算機(jī)軟件技術(shù)融合的一種新技術(shù)，可以簡單表示為［5］

一般認(rèn)為影響創(chuàng)新的主要因素有［4］：①客觀規(guī)律發(fā)現(xiàn)的困難；②問題發(fā)現(xiàn)的困難；③設(shè)計者的個人偏見和思維定勢；④個人掌握的知識和能力的局限性。CAI的目標(biāo)就是幫助設(shè)計者克服思維定勢，從全新的觀念出發(fā)，朝著理想解的方向篩選出最佳方案，從而節(jié)省資源，高效完成設(shè)計任務(wù)，實現(xiàn)技術(shù)突破和創(chuàng)新，完成相關(guān)專利申報和知識管理工作。

CAI軟件的一個鮮明特點就是集成現(xiàn)有的創(chuàng)新理論和方法，其中最主要的創(chuàng)新理論就是TRIZ，具體的技術(shù)包括［5］：創(chuàng)新問題分析、定義和轉(zhuǎn)換技術(shù)、語義分析與類比技術(shù)、標(biāo)準(zhǔn)解到特定解法的二級類別技術(shù)、效應(yīng)知識庫技術(shù)、專利查詢與數(shù)據(jù)挖掘技術(shù)、方案評價技術(shù)等。IT信息化技術(shù)包括CAI軟件平臺軟件的設(shè)計與開發(fā)技術(shù)等。

當(dāng)前主流的CAI軟件都將TRIZ理論作為主要的創(chuàng)新理論，在軟件設(shè)計過程中實現(xiàn)發(fā)明問題分解、效應(yīng)分析、標(biāo)準(zhǔn)解類別、特定解類比、專利知識庫查詢等基本功能，從幾款主流CAI軟件的發(fā)展階段來看，基本上還是處于面向?qū)ο蠹夹g(shù)發(fā)展的中期技術(shù)水平。幾款主流的CAI軟件發(fā)展階段及特點對比如表1所示。

表1 部分主流CAI軟件一覽表

從表1可以看出，主流的CAI軟件產(chǎn)品由于歷史原因發(fā)展到今天主要采取面向?qū)ο蟮木幊趟枷?，體系架構(gòu)主要表現(xiàn)為兩層架構(gòu)（C／S，B／S）。盡管大部分CAI軟件提供的主要是單機(jī)版本工具，但實際上還都是“標(biāo)準(zhǔn)客戶端編程＋數(shù)據(jù)庫”的架構(gòu)，如果把數(shù)據(jù)庫獨(dú)立出來，如數(shù)據(jù)庫部署到SQL Server和Oracel等大型數(shù)據(jù)庫，則變成了典型的C（B）／S架構(gòu)。

3 基于SOA的CAI軟件體系架構(gòu)設(shè)計

SOA是面向?qū)ο蠹夹g(shù)在軟件體系架構(gòu)領(lǐng)域的一大發(fā)展。SOA的出現(xiàn)主要解決基于網(wǎng)絡(luò)／互聯(lián)網(wǎng)環(huán)境下，多個異構(gòu)系統(tǒng)之間的代碼復(fù)用和交互問題。面向?qū)ο蠹夹g(shù)的發(fā)展衍生了EJB和COM＋兩大基本構(gòu)件，而這兩種構(gòu)件由于開發(fā)環(huán)境和語言不通，很難實現(xiàn)功能繼承和代碼復(fù)用。如何實現(xiàn)這些異構(gòu)組件和功能模塊之間的復(fù)用和交互，最大程度地保護(hù)已有軟件資產(chǎn)的投資，需要采用一種更大粒度的功能組件和更加普適的通信協(xié)議，這就是SOA的基礎(chǔ)部件 Web service和SOAP。顯然，SOA架構(gòu)的出現(xiàn)最大程度地保護(hù)了原有系統(tǒng)的功能價值，實現(xiàn)了基于互聯(lián)網(wǎng)層自由訪問和信息共享。因為SOAP實際上是運(yùn)行在超文本傳輸協(xié)議（HyperText Transfer Protocol，HTTP）之上的應(yīng)用，可以規(guī)避大部分網(wǎng)絡(luò)安全策略和防火墻的攔截，同時具有較高的訪問安全性，所以得到了軟件工程界的重視。近年來，隨著云計算和物聯(lián)網(wǎng)應(yīng)用的興起，軟件支撐部分更加需要跨平臺的通信和協(xié)作，因此基于SOA的軟件系統(tǒng)設(shè)計思想在云計算中的地位和作用愈加凸顯和重要，但是兩者之間究竟是存在競爭還是逐步走向融合，目前還沒有最終的定論［13］。

3.1 基于SOA架構(gòu)的CAI軟件系統(tǒng)的特點分析

從用戶需求不斷發(fā)展變化的角度看，進(jìn)一步提升CAI軟件的開放性、柔性和可擴(kuò)展性，在CAI軟件的體系架構(gòu)設(shè)計中顯得極為重要?；赟OA的體系架構(gòu)最大程度地降低了傳統(tǒng)CAI軟件客戶端安裝和維護(hù)的成本，提高了用戶訪問的便捷性。在一個互聯(lián)網(wǎng)和移動通信技術(shù)高速發(fā)展的時代，對軟件和計算資源的訪問已經(jīng)從傳統(tǒng)的PC擴(kuò)展到手機(jī)、平板電腦等移動計算設(shè)備，而SOA的架構(gòu)保障了跨平臺和異構(gòu)網(wǎng)絡(luò)環(huán)境的高效訪問和數(shù)據(jù)交互。隨著系統(tǒng)功能的服務(wù)化和虛擬化，基于SOA的CAI軟件為更大范圍內(nèi)協(xié)同創(chuàng)新的計算輔助“云”的建設(shè)和資源整合提供了條件。與目前主流的傳統(tǒng)CAI軟件相比，基于SOA的CAI軟件的優(yōu)勢如表2所示。

表2 基于SOA的CAI軟件與傳統(tǒng)CAI軟件的對比分析

在工業(yè)產(chǎn)品的設(shè)計流程中，CAI軟件的主要目標(biāo)不僅是輔助用戶完成產(chǎn)品的創(chuàng)意和概念設(shè)計，還廣泛用于技術(shù)設(shè)計、參數(shù)設(shè)計、工藝設(shè)計中。因此，CAI軟件設(shè)計和開發(fā)是一個涉及認(rèn)知心理學(xué)、創(chuàng)新科學(xué)、軟件工程和人因工程等多個學(xué)科和知識領(lǐng)域的復(fù)雜系統(tǒng)工程［14］，同時在整個新產(chǎn)品設(shè)計流程中，CAI軟件又是一個幾乎貫穿整個新產(chǎn)品設(shè)計過程的輔助支撐平臺，如圖3所示。

從圖3可以看出，CAI軟件首先需要接收新產(chǎn)品的需求，由于需求的文字表述等問題，在錄入用戶產(chǎn)品需求描述內(nèi)容時，有必要考慮接口的規(guī)范和描述文檔內(nèi)容的規(guī)范問題。另外，因為很多產(chǎn)品需求分析可能來自其他軟件系統(tǒng)，所以在接收產(chǎn)品需求功能模塊時需要考慮靈活的接收、查詢和內(nèi)容校驗機(jī)制。其次，作為經(jīng)過CAI軟件過濾和篩選過的創(chuàng)意以及產(chǎn)品概念雛形可能有多個，而且一個產(chǎn)品創(chuàng)意可能僅為某種迭代設(shè)計的中間產(chǎn)物，因此CAI的輸出接口應(yīng)該是可以交互的，即當(dāng)前即使處于產(chǎn)品的詳細(xì)設(shè)計階段，依然可以回溯和查詢創(chuàng)意篩選的結(jié)果數(shù)據(jù)，反饋詳細(xì)設(shè)計可能存在的矛盾和問題。第三，在產(chǎn)品走向市場后，最終用戶可能會提出對原始概念和創(chuàng)意部分進(jìn)行修正和部分改動，因此如何考慮用戶意見的反饋也是未來CAI軟件需要考慮的問題。

SOA的軟件體系把系統(tǒng)主要的交互接口和業(yè)務(wù)邏輯功能封裝成統(tǒng)一的“服務(wù)”，而這種服務(wù)可以實現(xiàn)跨平臺的訪問和交互，系統(tǒng)內(nèi)部之間采取松耦合，有利于多個不同知識結(jié)構(gòu)和開發(fā)背景的人員協(xié)同開發(fā)。

3.2 CAI軟件發(fā)展和進(jìn)化趨勢分析

根據(jù)上述關(guān)于軟件體系架構(gòu)技術(shù)路線圖和基于TRIZ的技術(shù)進(jìn)化規(guī)則的分析，可以發(fā)現(xiàn)SOA的軟件體系架構(gòu)符合當(dāng)前軟件技術(shù)發(fā)展和進(jìn)化的方向?；赟OA的體系架構(gòu)可以滿足功能即服務(wù)的需求，又是與其他創(chuàng)新設(shè)計理念融合、交互的重要基礎(chǔ)。近年來，有學(xué)者提出了TRIZ與質(zhì)量功能配置（Quality Function Deployment，QFD）、綜合集成、公理化設(shè)計等理論的融合，以及CAI、產(chǎn)品生命周期管 理 （Product Lifecycle Management，PLM）和CAx等系統(tǒng)相互整合的概念，這些都對現(xiàn)有CAI軟件的開放性和模塊的松耦合性提出了更高的要求［15］。在現(xiàn)有面向?qū)ο缶幊炭蚣芟?，基于SOA的架構(gòu)可以最大程度地保護(hù)已有代碼和功能模塊，并實現(xiàn)對既有代碼的復(fù)用。同時，在當(dāng)前的互聯(lián)網(wǎng)背景下，如何運(yùn)用最新的互聯(lián)網(wǎng)理論和技術(shù)實現(xiàn)更廣泛的協(xié)同創(chuàng)新支撐，也是下一代CAI軟件系統(tǒng)需要關(guān)注的熱點之一［16］。

3.3 基于SOA的CAI軟件體系結(jié)構(gòu)設(shè)計框架

基于SOA的軟件系統(tǒng)通過功能分解后再封裝，有利于降低開發(fā)難度和提高效率，同時所有功能模塊的標(biāo)準(zhǔn)化封裝、松耦合性結(jié)構(gòu)也降低了后續(xù)的維護(hù)難度，還可以最大程度地復(fù)用現(xiàn)有的代碼和模塊。這里提供一個基于TRIZ理論的CAI軟件的架構(gòu)設(shè)計框架?；竟δ苄枨髤⒖贾髁鬈浖延械哪K。一般基于SOA架構(gòu)的簡單形式化表示可以參考式（3），簡單的結(jié)構(gòu)示意圖可以參考圖4。

3.3.1 SOA體系的基本技術(shù)和協(xié)議

面向服務(wù)的體系架構(gòu)模型所涉及的基本技術(shù)和協(xié)議主要有以下三個方面的內(nèi)容：

（1）Web服務(wù)描述語言（Web Services Description Language，WSDL） 用來描述 Web服務(wù)和說明如何與 Web服務(wù)通信的可擴(kuò)展標(biāo)記語言（eX－tended Markup Language，XML），為用戶提供詳細(xì)的接口說明書。

（2）簡單對象訪問協(xié)議 SOAP是一種輕量的、簡單的、基于XML的協(xié)議，它被設(shè)計成在 Web上交換結(jié)構(gòu)化和固化的信息。SOAP最大的優(yōu)勢在于可以和現(xiàn)存的許多因特網(wǎng)協(xié)議和格式結(jié)合使用，包括 HTTP、簡單郵件傳輸協(xié)議（Simple Mail Transfer Protocol，SMTP）等。SOAP還支持從消息系統(tǒng)到遠(yuǎn)程過程調(diào)用（Remote Process Call，RPC）等大量的應(yīng)用程序。

（3）統(tǒng)一描述、發(fā)現(xiàn)和集成協(xié)議（Universal Description，Discovery and Integration，UDDI）UDDI其實是一種目錄服務(wù)，企業(yè)可以使用它對Web services進(jìn)行注冊和搜索。程序開發(fā)人員通過UDDI機(jī)制查找分布在互聯(lián)網(wǎng)上的 Web service，在獲取其WSDL文件后，就可以在自己的程序中以SOAP調(diào)用的格式請求相應(yīng)的服務(wù)。

3.3.2 SOA架構(gòu)設(shè)計約束

（1）Service Provider設(shè)計約束

Service Provider設(shè)計其實就是傳統(tǒng)的面向?qū)ο髽?gòu)件（組件）設(shè)計的升級，但是服務(wù)粒度的設(shè)計依賴外部調(diào)用約束（Invoke）和內(nèi)部交互約束兩個方面的約束。

（2）Service Invoker設(shè)計約束

服務(wù)調(diào)用或者消費(fèi)設(shè)計需要考慮服務(wù)發(fā)現(xiàn)的效率，以及參數(shù)的可讀性、響應(yīng)的效率和安全性問題。

（3）Service Registry設(shè)計約束

一般服務(wù)發(fā)布和注冊需要考慮在UDDI中心披露更多實質(zhì)性的功能描述和說明，使其他開發(fā)者或者服務(wù)消費(fèi)者能夠快速瀏覽和引用，即獲取的 WSDL文件能夠快速地被集成到使用者的模塊中。

3.3.3 基于SOA的CAI軟件設(shè)計框架

軟件體系架構(gòu)設(shè)計包括哪幾個部分，目前還沒有統(tǒng)一的定義。例如：CMM（capability maturity model for software）規(guī)范體系認(rèn)為體系架構(gòu)設(shè)計是概要設(shè)計（High level）的一部分，而又有學(xué)者和機(jī)構(gòu)認(rèn)為體系架構(gòu)設(shè)計應(yīng)該在概要設(shè)計之前，是軟件工程中一個獨(dú)立的階段，架構(gòu)設(shè)計是概要設(shè)計的基礎(chǔ)，是對用戶需求進(jìn)行建模分析和對系統(tǒng)總體結(jié)構(gòu)進(jìn)行規(guī)劃的重要階段。體系架構(gòu)設(shè)計的輸出應(yīng)當(dāng)包括系統(tǒng)的需求模型、系統(tǒng)邏輯結(jié)構(gòu)、子系統(tǒng)或模塊構(gòu)成、模塊之間通信協(xié)議或機(jī)制、用戶與系統(tǒng)界面原型、業(yè)務(wù)流程建模與校驗、系統(tǒng)測試流程與用例、數(shù)據(jù)與代碼規(guī)范、開發(fā)工具與語言、硬件與網(wǎng)絡(luò)資源要求與說明和風(fēng)險控制策略。限于篇幅，本文只給出CAI軟件的需求描述、系統(tǒng)邏輯結(jié)構(gòu)設(shè)計、主要的業(yè)務(wù)流程設(shè)計、Use－case設(shè)計和一個功能服務(wù)模塊的對象化設(shè)計。

（1）功能需求分析 根據(jù)當(dāng)前主流CAI軟件的功能框架，以及TRIZ解決發(fā)明問題的流程和思路，CAI軟件系統(tǒng)的需求經(jīng)過分析和整理后，主要有如下幾個需求點：

1）發(fā)明創(chuàng)新問題的接收、轉(zhuǎn)化、定義、分解。

2）資源約束矛盾和沖突的分析和技術(shù)進(jìn)化分析。

3）物－場分析與標(biāo)準(zhǔn)解映射，一級類比。

4）標(biāo)準(zhǔn)解到基于領(lǐng)域知識的特定解。

5）效應(yīng)知識庫。

6）創(chuàng)新案例知識庫。

7）專利檢索與挖掘。

8）創(chuàng)新案例庫。

9）解決方法和路徑評價。

10）效果反饋。

（2）系統(tǒng)邏輯結(jié)構(gòu)設(shè)計 采用基于SOA的軟件系統(tǒng)，一般可以采取top－down的設(shè)計方式?；趖op—down設(shè)計方式的CAI軟件系統(tǒng)的邏輯架構(gòu)示意圖如圖5所示。

（3）部分主要Use－case設(shè)計 系統(tǒng)部分的Usecase設(shè)計圖如6所示。

（4）主要業(yè)務(wù)流程設(shè)計 主要的業(yè)務(wù)流程參考TRIZ理論關(guān)于創(chuàng)新和發(fā)明問題的解決流程進(jìn)行設(shè)計，具體設(shè)計如圖7所示。

（5）對象與組件層設(shè)計實例分析 對象與組件層設(shè)計部分已經(jīng)覆蓋了詳細(xì)的設(shè)計部分，這里給出專利查詢服務(wù)功能的組件設(shè)計簡化示意圖，如圖8所示。

基于圖8的組件層設(shè)計之后，Web service封裝后的WSDL和服務(wù)瀏覽窗口如圖9所示。

4 結(jié)束語

CAI軟件系統(tǒng)作為當(dāng)前TRIZ應(yīng)用和推廣的重要輔助工具和平臺，國內(nèi)外都比較缺乏針對其軟件體系架構(gòu)、軟件開發(fā)技術(shù)演化路徑和方向的研究。一方面，由于當(dāng)前國內(nèi)外主流CAI軟件供應(yīng)商的商業(yè)秘密保護(hù)策略；另一方面，國內(nèi)外研究CAI軟件的機(jī)構(gòu)大多數(shù)以TRIZ咨詢公司，或者TRIZ與創(chuàng)新理論研究機(jī)構(gòu)為主，缺乏對軟件系統(tǒng)架構(gòu)、軟件技術(shù)演化等領(lǐng)域的關(guān)注和研究的專業(yè)激勵。本文是廣東省創(chuàng)新方法與決策管理系統(tǒng)重點實驗室的一個前期科研成果，是建立在對當(dāng)前國內(nèi)外主流CAI軟件充分調(diào)研基礎(chǔ)上的概覽性成果。

本文的主要創(chuàng)新有兩點：①從TRIZ技術(shù)系統(tǒng)演進(jìn)的視角分析了當(dāng)前主流CAI軟件體系架構(gòu)發(fā)展的現(xiàn)狀，并根據(jù)軟件體系架構(gòu)技術(shù)發(fā)展的技術(shù)系統(tǒng)演化規(guī)則，提出了基于SOA的新一代CAI軟件系統(tǒng)設(shè)計思想；②從軟件工程架構(gòu)設(shè)計的角度，綜合當(dāng)前國內(nèi)外的主流CAI軟件產(chǎn)品功能模塊，給出了一個具有一定參考價值和工程實踐意義、基于SOA架構(gòu)的下一代CAI軟件設(shè)計框架。

限于篇幅和筆者的研究水平，這里給出的設(shè)計框架還需要進(jìn)一步細(xì)化，真正落實到具體的CAI軟件系統(tǒng)中，這也正是下一步研究的重點內(nèi)容之一。

［1］ TAYLOR 段 ，MEDVIDOVIC N，DASHOFY E.Software architecture：foundations，theory，and practice［M］.Hoboken，N.J.，USA：Wiley Publisher，2009.

［2］ QIN Zheng，XING Jiankuan，DONG Jinchun，et al.Software architecture［M］.2nd ed.Beijing：Tsinghua University Press，2008（in Chinese）.［覃 征，邢劍寬，董金春，等.軟件體系結(jié)構(gòu)［M］.2版.北京：清華大學(xué)出版社，2008.］

［3］ TAN Runhua.Theory of inventive problem solving［M］.Beijing：Science Press，2004（in Chinese）.［檀潤華.發(fā)明問題解決理論［M］.北京：科學(xué)出版社，2004.］

［4］ FEY V，RIVIN E.Innovation on demand［M］.Cambridge，UK：Cambridge University Press，2005.

［5］ MA Jianhong，LI Juan，TAN Runhua.Development of a computer aided inventive problem solving system—Invention Tool 2.0［J］.Journal of Hebei University of Technology，2004，33（4）：1－6（in Chinese）.［馬建紅，李 娟，檀潤華.計算機(jī)輔助創(chuàng)新設(shè)計系統(tǒng)——Invention Tool 2.0開發(fā)［J］.河北工業(yè)大學(xué)學(xué)報，2004，33（4）：1－6.］

［6］ DELOACH 段 ，PADGHAM L，PERINI A，et al.Using three AOSE toolkits to develop a sample design［J］.International Journal of Agent－Oriented Software Engineering，2009，3（4）：416－476.

［7］ BONNEMA 段 .TRIZ for systems architecting ［C］／／Proceedings of the ETRIA World TRIZ Future Conference.Amsterdam，the Netherlands：Elsevier，9：702－707.

［8］ WANG Suhua，DURGESH S，CHEN Dengjie.Software development and quality problems and solutions by TRIZ ［J］.Procedia Computer Science，2011，5：730－735.

［9］ LING Xiaodong.A review of SOA ［J］.Computer Applications and Software，2007，24（10）：122－125（in Chinese）.［凌曉東.SOA綜述［J］.計算機(jī)應(yīng)用與軟件，2007，24（10）：122－125.］

［10］ LIU Min，YAN Junwei.Study on SOA based grid manufacturing and its architecture［J］.Journal of Tongji University：Natural Science，2007，35（2）：239－243（in Chinese）.［劉敏，嚴(yán)雋薇.基于SOA的網(wǎng)格化制造模式及體系結(jié)構(gòu)［J］.同濟(jì)大學(xué)學(xué)報：自然科學(xué)版，2007，35（2）：239－243.］

［11］ MAO Xinjun.State－of－the－art，challenges and prospects of Agent oriented software engineering［J］.Computer Science，2011，38（1）：1－6（in Chinese）.［毛新軍.面向Agent軟件工程：現(xiàn)狀、挑戰(zhàn)與展望［J］.計算機(jī)科學(xué)，2011，38（1）：1－6.］

［12］ CABRI G，LEONARDI L，PUVIANI M，et al.Comparing service－oriented computing and Agent－oriented programming towards integration ［J］.Web Intelligence and Agent Systems，211，9（2）：135－146.

［13］ ZHU Zhiliang，YUAN Haitao，SONG Jie，et al.SOA and clouding computing：competition or integration［J］.Computer Science，2011，38（12）：6－11（in Chinese）.［朱志良，苑海濤，宋 杰，等.SOA與云計算：競爭還是融合［J］.計算機(jī)科學(xué)，2011，38（12）：6－11.］

［14］ LIU Xiaoying，LI Yan，PAN Peiyuan，et al.Research on computer－aided creative design platform based on creativity model［J］.Expert Systems with Applications，2011，38（8）：9973－9990.

［15］ LEON N.The future of computer－aided innovation［J］.Computers in Industry，2009，60（5）：539－550.

［16］ HUSIG S，KOHN S.“Open CAI 2.0”— Computer Aided Innovation in the era of open innovation and Web 2.0［J］.Computers in Industry，2011，62（4）：407－413.

［17］ KLUENDER D.TRIZ for software architecture［J］.Procedia Engineering，2011，9：708－713.