專利名稱：：一種基于中間件的組件系統(tǒng)性能預測方法和系統(tǒng)的制作方法
技術領域：
：本發(fā)明屬于計算機網(wǎng)絡和數(shù)據(jù)通信
技術領域：
，具體涉及一種基于中間件的組件系統(tǒng)性能預測方法，以模型轉(zhuǎn)換分析為基礎，通過嵌套分析的方法構(gòu)建中間件完整性能模型，并最終生成預測結(jié)果。
背景技術：
：中間件是位于平臺(硬件和操作系統(tǒng))和應用之間的通用服務，這些服務具有標準的程序接口和協(xié)議。分布式應用軟件借助它在不同的技術之間共享資源，用于解決網(wǎng)絡分布異構(gòu)問題，幫助用戶靈活、高效地開發(fā)和集成復雜的應用軟件。己有大量中間件技術標準及其產(chǎn)品在業(yè)界得到廣泛應用，比如CORBA、EJB等。中間件技術為設計人員提供了一個統(tǒng)一的、高效的、簡化的設計平臺，為符合其標準的組件提供了位置透明性、語言獨立性和事件驅(qū)動等特性，使應用程序在設計開發(fā)時無需考慮通信協(xié)作的實現(xiàn)細節(jié)。但與此同時，中間件技術也為組件性能帶來影響，而性能又是一個軟件系統(tǒng)關鍵的質(zhì)量屬性，是用戶滿意度的重要衡量指標，也是設計人員不可忽視的重要因素。為解決這個問題，一個可行的方案是在系統(tǒng)設計初期預測系統(tǒng)性能。在系統(tǒng)尚未實現(xiàn)之前預見出設計中存在的性能缺陷，輔助設計人員盡早修改設計，從而減少后期修復所需要的大量人力和物力的投入，縮短系統(tǒng)性能調(diào)優(yōu)周期。然而，在預測中間件系統(tǒng)性能的時候，問題又變得異常復雜。系統(tǒng)性能不再是用戶程序所能控制的代碼邏輯，而是包括支持組件運行的中間件和第三方組件實現(xiàn)邏輯在內(nèi)的復雜體系。這些影響因素可分為中間件自身的性能影響因素，中間件為組件自動加載的橫切關注點執(zhí)行邏輯的影響因素和由組件調(diào)用的其它服務或組件的影響因素等。對普通設計人員來說這些是透明的，他們并不關心底層中間件的具體實現(xiàn)。已有一些研究針對如何構(gòu)建軟件自身的性能模型展開，另一些研究則進一步考慮到中間件性能影響因素，但是它們均未全面系統(tǒng)的為應用設計人員提供一種快捷高效的針對中間件系統(tǒng)的建模與分析方法。Woodside提出了一種用于分析軟件性能的數(shù)學模型(M.Woodside，"TheStochasticRendezvousNetworkModelforPerformanceofSynchronousClient-ServerLikeDistributedSoftware",IEEETransactionsonComputers,Vol.44,No.1，January1995，pp.20-34)，并進一步將其演化為分層排隊網(wǎng)模型(LayeredQueuingNetwork),之后又改進了他所提出的將軟件體系結(jié)構(gòu)轉(zhuǎn)換為此數(shù)學模型的方法(M.Woodside,"FromAnnotatedSoftwaeDesigns(UMLSPT/MARTE)toModelFormalisms",LNCS4486，2007,p.429-467)。但上述方面并不適用于中間件系統(tǒng)。針對中間件影響，他提出了一種基于此數(shù)學模型設計的模版驅(qū)動的EJB組件性能予頁領!l方、法(J.Xu，M.Woodside,"Template-DrivenPerformanceModelingofEnterpriseJavaBeans",Proc.WorkshoponMiddlewareforWebServices，2005.pp.57-64.)，該方法最大的局限在與應用設計人員并不了解此數(shù)學模型，不便于根據(jù)需求調(diào)整或設計子模塊的性能影響因素。同時，他又指出了研究一種自動分析設計人所不涉及部分性能影響因素的重要性(M.Woodside,"TheFutureofSoftwarePerformanceEngineering",IEEEFutureofSoftwareEngineering,2007,pp.171-187)。Shen提出了一種面向方面的性能建模方法(H.Shen，"PerformanceAnalysisofUMLModelsusingAspectOrientedModelingTechniques",LNCS3713,2005,PR156-170)，分析由面向方面技術構(gòu)建的系統(tǒng)性能。但該方法只適用于通用軟件的問題，而并未將中間件因素考慮在內(nèi)。Verdickt提出了一種為UML軟件模型自動引入中間件性能屬性的方法(T.Verdickt,"AutomaticInclusionofMiddlewarePerformanceAttributesintoArchitecturalUMLSoftwareModels",IEEETransactionsonSoftwareEngineering,Vol.31，No.8,August,2005,pp.695-711)。該方法，以模型驅(qū)動(J.MillerandJ.Mukerji,"MDAGuide,Version1.0.1,"June2003.)為基礎，允許設計人員以聲明式的方法將中間件影響因素和組合其它組件帶來的影響因素考慮進來，但并未分析中間件自動加入組件的橫切關注點執(zhí)行邏輯，同時這種其聲明的影響因素粒度較大，并不能精確的刻畫影響因素。
發(fā)明內(nèi)容針對上述問題，本發(fā)明依據(jù)中間件平臺所具有的特性，設計出一種基于中間件的組件系統(tǒng)性能預測方法，將中間件性能影響因素和程序自身性能影響因素有機的組合起來。本發(fā)明吸取了幾種已有的建模和預測方法的思想，并做出相應改進，精簡冗余操作，使其更加適應中間件環(huán)境，為應用設計人員提供一種簡捷高效的性能預測方法。為了抽象出中間件性能影響因素，本發(fā)明提出了一種可嵌套模型。該套模型源于組件間的嵌套調(diào)用關系，而這種關系允許組件間無限次嵌套調(diào)用。以這種調(diào)用關系為基礎，可嵌套模型定義為可被其它組件調(diào)用或調(diào)用其它組件的獨立單元，描述了這部分操作的詳細性能影響因素。性能分析也依據(jù)此嵌套關系設計，采用嵌套分析方法加載性能影響因素。原始輸入模型將逐步被含有詳細性能影響因素的可嵌套模型所攔截或替換，進而構(gòu)造成一個完整的具有各種性能影響因素的性能模型。另外，為了減輕設計人員的負擔，本發(fā)明所設計的預測過程并不需要額外的性能建模工作，而是蘊含在系統(tǒng)建模過程中，利用建模的產(chǎn)出作為預測的輸入。系統(tǒng)設計人員只需提供符合UML2.0規(guī)范的軟件體系結(jié)構(gòu)模型和相關聲明信息，本發(fā)明將會自動查找、組織和分析各種影響因素信息，并最終生成性能預測結(jié)果。結(jié)果包括系統(tǒng)吞吐率、響應時間和資源利用率等性能相關數(shù)據(jù)。本發(fā)明預測分析中間件性能的步驟如下1)載入軟件體系結(jié)構(gòu)原始模型，確定中間件平臺，所述軟件體系結(jié)構(gòu)原始模型包括應用聲明文件、部署圖、協(xié)作圖和活動2)分割器分析原始模型，選取入度為O的節(jié)點作為當前待分析組件；3)橫切點分析器分析當前待分析組件是否存在未編織的橫切關注點，若存在，編織橫切關注點模板，并將原始模型轉(zhuǎn)換為性能模型；4)性能模板加載器分析當前待分析組件是否受中間件平臺的影響，若是，加載中間件性能模板；5)調(diào)度器分析當前節(jié)點所引用的其它組件是否存在未處理的，若存在轉(zhuǎn)入步驟6);否則判斷當前節(jié)點是否存在父節(jié)點，若有父節(jié)點作為當前待分析節(jié)點重復步驟5)，否則轉(zhuǎn)入步驟7);6)第三方組件引入器分析當前待分析組件是否為第三方組件，若是，則引入第三方組件模板，并調(diào)用分割器更新當前分析節(jié)點；否則直接更新當前分析節(jié)點，并返回步驟3);7)確定測試硬件環(huán)境，載入相關資源消耗數(shù)據(jù)，計算分析組件完整性能結(jié)果；上述軟件體系結(jié)構(gòu)原始模型包括(1)UML部署圖，描述組件的物理部署狀態(tài)，以及它們之間的聯(lián)系方式。(2)UML協(xié)作圖，描述不同組件間交互的請求模式。(3)UML活動圖，描述組件使用場景，并用SPT標注必須的性能影響因素。本發(fā)明定義的可嵌套模型包括-(1)通用方面模型，描述了橫切關注點性能影響因素細節(jié)；(2)中間件性能模型，描述了中間件自身性能影響因素細節(jié)；(3)第三方組件模型庫，描述了第三方組件性能影響因素細節(jié)；上述預測方法使用了一個存儲和査找可嵌套模型和系統(tǒng)資源消耗的數(shù)據(jù)庫，包括(1)通用方面模型庫，存放通用方面模型；(2)中間件性能模型庫，存放中間件性能模型；(3)第三方組件模型庫，存放第三方組件模型；(4)平臺相關資源庫，存放平臺相關系統(tǒng)資源消耗數(shù)據(jù)；上述預測方法中步驟2、4、5是本發(fā)明的核心步驟，主要解決如下兩方面問題(1)模型樣式。設計恰當?shù)哪Ｐ徒Y(jié)構(gòu)和建模方法，使其既能刻畫某類性能影響因素的細節(jié)，又便于設計人員理解和操作。本發(fā)明分別使用了通用方面模型、中間件性能模型和第三方組件模型。(2)模型編排。編排的目的是將可嵌套模型組合到原始模型中，這里的原始模型指軟件設計人員所提供的軟件模型，構(gòu)成一個完整的性能模型，從而將一個用戶輸入的原始模型轉(zhuǎn)化為包含豐富信息的完整性能模型。分別采用了面向方面的編織技術，性能模型加載技術和第三方組件替換技術。上述性能預測方法中在步驟4)中判斷是否存在未引入的第三方組件是一個遞歸嵌套的過程，對每一個子服務或組件都會重復調(diào)用步驟2-4的步驟，直到當前分析的服務或組件不再調(diào)用其它服務或組件為止。本發(fā)明提出了一種基于可嵌套模型的中間件性能預測方法，其優(yōu)點如下1.支持多中間件類型、多中間件實現(xiàn)產(chǎn)品和多運行平臺；2.將系統(tǒng)建模與性能預測過程統(tǒng)一，無須設計人員花費額外精力進行性能建模；3.統(tǒng)一考慮了中間件平臺、橫切關注點以及引用組件的性能影響因素。4.各性能影響因素均以可嵌套模型形式存放，可在不同應用間復用；5.預測結(jié)果可以輔助設計人員盡早發(fā)現(xiàn)設計缺陷，幫助他們篩選備選方案。圖1為本發(fā)明性能預測的處理流程圖。圖2為本發(fā)明總體結(jié)構(gòu)圖。圖3為本發(fā)明性能影響因素庫的總體結(jié)構(gòu)。圖4為模型轉(zhuǎn)換算法的調(diào)度流程圖。圖5為通用方面模型編織示意圖。圖6為中間件性能模型加載示意圖。圖7為第三方組件模型引入示意圖。具體實施例方式本節(jié)將介紹使用本發(fā)明預測中間件性能的具體實施方式。本發(fā)明以軟件體系結(jié)構(gòu)為基礎，使用模型驅(qū)動逐步求精的方法引入各種性能影響因素，并最終生成性能預測數(shù)據(jù)。軟件體系結(jié)構(gòu)采用UML模型描述，僅包含了設計人員所關注的系統(tǒng)基本結(jié)構(gòu)及其調(diào)用關系，詳細性能影響因素將在嵌套分析過程中逐步給出。預測過程涉及的關鍵技術包括面向方面的橫切關注點性能影響因素分析技術，基于性能模型的中間件性能影響因素分析技術和申明式第三方組件引入技術。這些技術稍后將逐一介紹。預測流程從軟件體系結(jié)構(gòu)的起始節(jié)點開始。首先分析中間件平臺自動加載到組件的橫切關注點(可配置服務，如事務、安全和監(jiān)控等)的性能影響因素，并將其轉(zhuǎn)換為性能模型。接著分析中間件平臺自身給組件帶來的額外性能開銷(如通信、數(shù)據(jù)轉(zhuǎn)換和資源競爭等)。之后判斷當前組件是否引用了其它服務或組件，如果有則判斷該節(jié)點是否為第三方組件，若是則引入第三方組件模板。然后根據(jù)調(diào)用關系更新當前帶分析節(jié)點，并對當前節(jié)點繼續(xù)嵌套分析，直到所有引用服務和組件分析結(jié)束。此時，整個嵌套調(diào)用關系中的組件、服務、橫切關注點和中間件自身性能因素均包含在生成的完整性能模型當中。通過模型實例化與運行硬件環(huán)境相關的資源消耗參數(shù)，即可得到一個可計算的分層排隊網(wǎng)模型。最后，使用分層排隊網(wǎng)求解工具便可求解出最終性能預測的結(jié)果，包括系統(tǒng)吞吐率、響應時間、處理器利用率等數(shù)據(jù)。整個流程如圖l所示。為實現(xiàn)以上流程，本發(fā)明采用了如圖2所示的總體結(jié)構(gòu)。主要模塊有UML模型載入模塊、中間件性能影響因素庫模塊、性能分析與編排模塊和分析計算模塊四個部分。其中，性能分析與編排模塊是整個算法的核心，負責分析組裝各種性能影響因素。一、UML模型載入模塊UML模型載入模塊的主要任務是讀取設計人員提供的UML模型和相關聲明信息?？紤]到不同UML工具所產(chǎn)生的UML模型存在的差異性，該模塊由多個不同的載入器組成，每個載入器負責讀取某種特定工具生成的UML圖。這些載入器必須實現(xiàn)了同一個載入器接口，并返回具有相周結(jié)構(gòu)的數(shù)據(jù)結(jié)構(gòu)。該數(shù)據(jù)結(jié)構(gòu)與UML模型一一對應，包含了UML模型最基本信息(如節(jié)點類型、節(jié)點名稱、標注信息和關聯(lián)關系等)，而不包含特定的與工具相關的細節(jié)。整個讀取過程可以看作是一個文件讀取和數(shù)據(jù)映射過程，除了需要過濾與工具相關的無用數(shù)據(jù)外，基本不需要作復雜轉(zhuǎn)化工作。該模塊所需讀取的數(shù)據(jù)包括應用聲明文件、UML部署圖、UML協(xié)作圖和UML活動圖等，在預測前由系統(tǒng)設計人員給出。應用聲明文件用于說明預測過程中需要的信息，使用XML格式文件定義，包括組件的類型、運行平臺、橫切關注點和引用其它服務與組件等信息。如下聲明文件片斷描述了用于闡述本發(fā)明的實施例所聲明的信息。該實施例是一個運行在JBOSS應用服務器上的有狀態(tài)會話Bean組件，配置了橫切關注點，引用了第三方組件，并運行在指定的運行平臺上。<table>tableseeoriginaldocumentpage9</column></row><table>除申明文件外，剩下的三項輸入數(shù)據(jù)——部署圖、協(xié)作圖和活動圖，組合在一起描述了本發(fā)明所需的軟件體系結(jié)構(gòu)，而系統(tǒng)資源消耗數(shù)據(jù)則由符合SPT規(guī)范(UMLProfileforSchedulability,PerformanceandTime)的標注信息給出。部署圖描述了運行軟件系統(tǒng)的物理硬件，以及如何將軟件部署到硬件上。部署圖通常包含節(jié)點以及節(jié)點之間的關系。節(jié)點是定義運行時的物理對象的類，它一般用于對執(zhí)行處理或計算機的資源建模。給定一個部署圖也就確定了組件的基本屬性和物理部署結(jié)構(gòu)，包括組件的類型以及組件與硬件的物理部署狀態(tài)和連接方式等。協(xié)作圖是一種類圖，它包含類元角色和關聯(lián)角色，而不僅僅是類元和關聯(lián)。類元角色和關聯(lián)角色描述了對象的配置和當一個協(xié)作的實例執(zhí)行時可能出現(xiàn)的連接。關聯(lián)角色也可以被各種不同的臨時連接所擔當。為了提供組件間交互或通信模式，圖中進一步給出了組件間通過何種方式交互，比如說"客戶機/服務器"風格的同步方式或消息通信的異步方式等。標準的UML規(guī)范尚不支持這種交互方式的定義，但可采用其擴展機制或注釋解決這個問題?；顒訄D是一種特殊形式的狀態(tài)機，用于對計算流程和工作流程建模?；顒訄D中的狀態(tài)表示計算過程中所處的各種狀態(tài)，而不是普通對象的狀態(tài)?；顒訄D具體給出了組件內(nèi)部執(zhí)行的過程，以及和其它組件間協(xié)作的形式。圖中代表請求和響應事件的邊要和協(xié)作圖中定義的交互模式保持一致。比如有A和B兩個組件，采用"客戶機/服務器"方式交互，如果A有一個請求B的事件，那么B則需有返回A的事件。通過組合這三種UML模型，可獲得組件的內(nèi)部行為、外部行為以及硬件環(huán)境。SPT則給出了各個活動所需要的系統(tǒng)資源，比如處理器運算消耗時間等。不同的UML圖之間的元素通過命名關聯(lián)。同一個組件在不同的圖中須具有相同的名稱，在部署圖里表示了一個組件實例，在協(xié)作圖里表示為一個分類器，而在活動圖里表示為一個泳道。本實施例所釆用的原始模型包括三個組件和兩臺主機，組件分別是Client、Facade和Service;主機為ClientPC禾BServerStation。由部署圖可以確定Client組件部署在ClientPC主機上，而Facade組件和Service組件則部署在ServerStation主機上。ClientPC主機和ServerStation主機通過網(wǎng)絡連接。由協(xié)作圖可以確定Client組件和Facade組件，以及Facade組件和Service組件均是通過"客戶機/服務器"風格的同步方式交互。由活動圖可以確定Client組件是一個客戶組件，作為整個活動圖的起始節(jié)點。它向Facade組件發(fā)出請求。Facade組件在接受到Client組件請求之前一直等待執(zhí)行時機，在接受到Client請求后會執(zhí)行準備操作(prepare)，然后請求Service組件的業(yè)務方法(doBusiness)，并等待結(jié)果。直到在接受到Service組件的返回結(jié)果，執(zhí)行處理操作(process),最后返回結(jié)果給Client組件，自身再次進入等待狀態(tài)。為了使模型可適應多種硬件環(huán)境，資源消耗需求采用參數(shù)化的形式給出(首字母以"$"標示)，實際值可在計算最終性能模型時賦值?？紤]到用戶組件實現(xiàn)可以非常簡單，只是組合使用了其它系統(tǒng)服務或第三方組件，其自身并不消耗系統(tǒng)資源。因此，這種情況下設計人員此處可以不指定性能標注信息(SPT)。總的來說UML模型載入模塊可看作一個輸入模塊，負責讀取不同來源的輸入信息，并將這些信息統(tǒng)一轉(zhuǎn)化為后續(xù)模塊可操作的形式。二、中間件性能影響因素庫模塊中間件性能影響因素庫模塊用于存放了性能分析過程中需要的模型信息和運行平臺信息，主要由一系列的通用方面模型庫、中間件性能模型庫、第三方組件模型庫和平臺相關資源庫組成。中間件性能影響因素庫的總體結(jié)構(gòu)如圖3所示。因為不同類型的中間件平臺之間，甚至是不同廠商實現(xiàn)的中間件產(chǎn)品之間均存在差異。所以，本發(fā)明采用樹形結(jié)構(gòu)組織整個庫結(jié)構(gòu)，應對這種差異性。頂層根節(jié)點代表整個庫，其下按中間件種類分為中間件庫，中間件庫又進一步按照不同的實現(xiàn)產(chǎn)品和版本分為與特定運行平臺對應的產(chǎn)品庫。與產(chǎn)品庫位同級的有一個共享庫，它存放了可在不同中間件產(chǎn)品間共享的資源。產(chǎn)品庫和共享庫具有相同的庫結(jié)構(gòu)，即均包括四個子庫通用方面模型庫、中間件性能模型庫、第三方組件模型庫和平臺相關資源庫。通用方面模型庫存放了分析橫切關注點所需的UML方面模型信息；中間件性能模型庫存放了中間件性能影響因素的性能模型信息和系統(tǒng)資源消耗數(shù)據(jù)；第三方組件模型庫存放了被引用的第三方組件的模型信息和相關聲明信息。所謂第三方組件，可以是中間件提供的服務，也可以是其它可用組件。其聲明信息的內(nèi)容和應用聲明信息內(nèi)容一致，用于說明第三方組件的類型等屬性。而所謂平臺相關資源庫是一個存放組件活動對系統(tǒng)資源消耗的數(shù)據(jù)庫，比方說處理器執(zhí)行時間和線程池大小等。庫中的模型以命名方式加以區(qū)別，同一個子庫中的模型不允許同名，但不同子庫之間的模型允許同名。因為，對于同一個服務或者組件，在不同的中間件產(chǎn)品上可以有不同的具體實現(xiàn)。査找資源時從起始節(jié)點出發(fā)，首先搜索相應的中間件平臺的子節(jié)點，接著選擇對應的中間件產(chǎn)品，之后會在該產(chǎn)品的子庫中搜索所需的信息，最后如果未查找到數(shù)據(jù)則轉(zhuǎn)到公用庫査找。因此，公用庫中的數(shù)據(jù)可以被具體中間件產(chǎn)品所提供的數(shù)據(jù)所覆蓋。本發(fā)明存儲在中間件性能影響因素庫中的可嵌套模型，分別是通用方面模型、中間件性能模型和第三方組件模型。本發(fā)明的這些模型刻畫了設計人員在描述系統(tǒng)體系結(jié)構(gòu)時不曾考慮的，由中間件引起的，對系統(tǒng)產(chǎn)生顯著性能影響的底層實現(xiàn)細節(jié)。與其它普通符合規(guī)范的圖相比，本發(fā)明的這些模型必須指定輸入與輸出接口和必要的參數(shù)化數(shù)據(jù)，以便性能分析過程中將模型實例化并關聯(lián)到設計人員提供的原始模型中。本實施例中，模型中各個活動對資源的消耗以參數(shù)形式給出(首字母用"$"標示)，實際值則根據(jù)硬件平臺的不同存放在平臺相關資源庫中。1.通用方面模型也是一個UML模型，刻畫了橫切關注點的性能影響因素，由部署圖、協(xié)作圖和活動圖組成。本實施例中，與上下文相關的組件名和活動名采用了參數(shù)化的方式(首字母用"l"標示)預留，實際值將在方面模型編織到原始模型時指定。通用方面模型中活動圖有一條輸入邊和一條輸出邊，它們的一端不與任何活動節(jié)點相連，在編織時才會與具體節(jié)點關聯(lián)，分別代表著輸入和輸出接口。另外，它還具有一個連接點，由一個參數(shù)化的活動定義。所謂連接點就是橫切關注點將要攔截的目標組件，默認情況下可以不給出部署圖或協(xié)作圖定義。本實施例采用的通用方面模型只包含一個活動圖，由IGenericAspect和|Target兩個組件組成。IGenericAspect組件是一個代表橫切關注點的方面，擁有一條輸入邊和一條輸出邊，分別對應著接受請求和返回結(jié)果事件。輸入邊的起點尚未與任何活動關聯(lián)，終點則是該組件自身的一個活動，在完成所需操作之后將會請求ITarget組件的IJoinPoint活動。|JoinPoint活動是一個連接點，但此時并不代表具體的操作邏輯，而是一個占位空間。當IJoinPoint活動所需操作完成之后，將返回IGenericAspect組件。此時IGenericAspect組件根據(jù)返回執(zhí)行處理，之后會調(diào)用輸出邊所對應的事件，將請求返回給該方面的調(diào)用者。輸出邊的終點此時也尚未與具體的活動關聯(lián)，起點則關聯(lián)在上述活動上。2.中間件性能模型是一個分層排隊網(wǎng)模型，刻畫了中間件自身性能影響因素和系統(tǒng)資源消耗數(shù)據(jù)。如圖6所示，模型中的小圓圈代表接口，在組合過程中這些接口將于實際任務的請求關聯(lián)。各任務對處理器資源的消耗以首字母為"$"的參數(shù)表示。這樣，同一個模板便可以適用于不同的運行平臺。原始模型在與方面模型進行編織后，將被轉(zhuǎn)化為分層排隊網(wǎng)模型，并與此性能模型組合構(gòu)成該組件完整的性能模型。本實施例采用的中間件性能模型由一個接口、四個任務(Task)和一個方面子模型(AspectSubmodel)組成。接口是中間件性能模型請求的入口，由外部任務調(diào)用。這四個任務分別是Container、ContServ、BeanthreadPool和CallBack任務。Container任務具有無限實例個數(shù)，表示該對象可以在不同請求間并發(fā)執(zhí)行，不會受到同步操作的影響。ContServ任務只有一個實例，是關鍵區(qū)域競爭的抽象，模擬同步處理操作。BeanthreadPool模擬了實例池的大小，由參數(shù)SM控制池的規(guī)模。Bean實例的掛起與激活操作則由CallBack任務進行模擬，參數(shù)Sp一s用于申明掛起與激活的概率。當接口被觸發(fā)后，首先會調(diào)用Container的invokeMethod入口(Entry)，該入口又會調(diào)用Beanthreadpool的getThread入口。getThread入口會調(diào)用方面子模型的接口和ContServ任務的prepareBean入口。prepareBean入口又會以Sp一s的概率調(diào)用CallBack的passive/activate入口。方面子模型是為UML方面模型預留的占位空間，此處僅保留了一個接口的位置，實際模型是組件及其橫切關注點轉(zhuǎn)化而來的性能模型。3.第三方組件模型也是一個UML模型，刻畫了被組件引用的第三方組件所帶來的性能影響因素，由部署圖、協(xié)作圖和活動圖組成。與方面模型類似，活動圖定義了輸入和輸出接口，但沒有連接點的定義。因為第三方組件只需描述出調(diào)用者與被調(diào)者之間的嵌套調(diào)用關系，而不必刻畫橫切關注點這類插入到調(diào)用者與被調(diào)者之間的因素。默認情況下也不需要給出部署圖和協(xié)作圖的定義。在本發(fā)明中第三方組件被看作是具有獨立的第三方組件模型的組件，聲明信息中定義了原始模型中的使用到的第三方組件。若聲明文件中指定了原始某行中某組件對應于某個特定的第三方組件模型，則該組件在分析時便作為第三方組件看待。本實例采用的第三方組件模型由兩個組件組成Service和DataAccess組件。Service組件與原始模型中的Service組件對應，所不同的是在原始模型中Service組件只是一個抽象的描述，僅有doBusiness活動，而此處的Service組件則詳細刻畫了該組件的完整執(zhí)行過程。與通用方面模型類似，該模型也具有一條輸入邊和一條輸出邊。輸入邊的終點關聯(lián)著一個準備操作，執(zhí)行完該操作后，將調(diào)用DataAccess組件的讀取數(shù)據(jù)庫數(shù)據(jù)活動。待讀取操作完成將會返回到Service組件，并根據(jù)讀取結(jié)果繼續(xù)處理，處理結(jié)束將會調(diào)用DataAccess組件的保存活動進行保存。保存完畢會再次返回Service組件，此時該組件將出發(fā)輸出邊，將請求返回給調(diào)用者?？偟膩碚f，中間件性能影響因素庫主要用于存儲各種可嵌套模型和系統(tǒng)資源消耗數(shù)據(jù)?？梢钥醋黝A測算法的數(shù)據(jù)輔助模塊，存儲了不同類型中間件產(chǎn)品的性能影響因素。三、整個算法的核心模塊——'性能分析與編排模塊性能分析與編排模塊負責編排各個不同性能影響因素，構(gòu)造一個完整的，包含中間件自身、橫切關注點以及引用服務和組件的性能模型。由嵌套調(diào)度器、分割器、轉(zhuǎn)換器、橫切點分析器、性能模型加載器和第三方組件引入器組成。1.嵌套調(diào)度器負責管理嵌套關系，關聯(lián)其它模塊，承擔著協(xié)調(diào)者的角色。主要的功能是控制圖1所示的算法流程，保證分析過程的正確性。另外它還負責保存轉(zhuǎn)換過程中所需的上下文數(shù)據(jù)，包括原始性能模型、當前節(jié)點相關的數(shù)據(jù)、已轉(zhuǎn)化出的性能模型等。2.分割器用于分割組件間的原始關聯(lián)關系，以便逐個對組件加入必要的性能影響因素。它從入度為0的節(jié)點開始，逐步遍歷整個活動圖，保證任何情況下只有入度為0的節(jié)點才被訪問。因此我們使用拓撲排序的方法分割組件。對一個有向無環(huán)圖G進行拓撲排序，將G中所有頂點排成一個線性序列，使得圖中任意一對頂點u和v，若<11，v>GE(G)，則u在線性序列中出現(xiàn)在v之前。通常，這樣的線性序列稱為滿足拓撲次序的序列，簡稱拓撲序列。使用拓撲排序算法進行分割實質(zhì)上是一個循環(huán)訪問圖中節(jié)點的過程，每次取出一個入度為0的節(jié)點作為當前節(jié)點，刪除與其它節(jié)點的關聯(lián)邊，并將關聯(lián)節(jié)點的入度減l。當前節(jié)點既是當前被訪問節(jié)點，繼續(xù)分割時如果圖中仍有節(jié)點未取出則重復上述過程，否則算法結(jié)束。3.轉(zhuǎn)換器負責將UML模型轉(zhuǎn)化為分層排隊網(wǎng)的數(shù)學模型，本發(fā)明采用了一種基于中間模型的轉(zhuǎn)換算法(GordonP.Gu,"FromUMLtoLQNbyXMLalgebra-basedmodeltransformations",WOSP'05,July12-14,2005,P99-110)。它的作用是將三種UML圖表示的軟件體系結(jié)構(gòu)原始模型轉(zhuǎn)化為用數(shù)學模型表示的性能模型，便于與中間件性能模型組合并計算出最后的預測結(jié)果。轉(zhuǎn)換過程以中間模型為基礎，UML模型首先將被轉(zhuǎn)化為中間模型，然后再由中間模型轉(zhuǎn)化為數(shù)學模型。本發(fā)明采用的轉(zhuǎn)換算法需要在調(diào)度策略上做一定的改進，原有的轉(zhuǎn)換算法是針對一個固定的UML模型轉(zhuǎn)化為與之對應的性能模型，而本發(fā)明需要逐一轉(zhuǎn)換出當前分析組件的性能模型，并且UML模型會在分析過程中不斷被更新。所以當有更新發(fā)生時，需要重新轉(zhuǎn)換模型，并遍歷該模型選選取出新增的任務(task)包括調(diào)用它的請求(call)加入己轉(zhuǎn)化性能模型。己轉(zhuǎn)化性能模型存放在嵌套調(diào)度器中，后續(xù)操作均針對次已轉(zhuǎn)化性能模型。因為當前節(jié)點己經(jīng)穩(wěn)定，不會再有變化，所以轉(zhuǎn)化的出的結(jié)果也將穩(wěn)定，從起始任務到當前任務之間結(jié)構(gòu)便可以確定。轉(zhuǎn)換的流程圖如圖4所示，轉(zhuǎn)換算法仍采用原有方法。橫切關注點編織和第三方組件加載過程中均會使用到參數(shù)綁定技術，參數(shù)綁定的目的是將應用無關的模型轉(zhuǎn)化為與特定應用上下文相關的模型，以便將其可以與目標組件編織在一起。綁定規(guī)則可以描述為如下形式的值對"(參數(shù)化元素名，實際元素集)"。實際元素集可以是一個單一的元素名也可以是一個有"->"符號連接的元素集。如A->B，A是該集合的起始活動，B是該集合最后執(zhí)行的活動，它們之間可以存在諸多復雜活動。被一個方面所攔截的活動可能比較復雜，不是一個簡單的單一活動，該集合所定義的元素集合需要涵蓋被攔截請求的所有活動。本實施例采用如下綁定規(guī)則。<table>tableseeoriginaldocumentpage15</column></row><table>通過使用上述綁定規(guī)則，通用方面模型中各個參數(shù)的在實際應用中的值將被指定。在本實施例里，綁定前方面模板并不知道它所攔截哪個目標組件，但在綁定后AspectModel組件將攔截Facade組件pr印are到process之間的操作。4.性能分析與編排模塊的三個關鍵子模塊，分別為橫切點分析器、性能模型加載器和第三方組件引入器。它們各自負責分析不同方面對系統(tǒng)性能影響，并將這些影響因素通過不同的形式組合到原始模型中。(a)橫切點分析器負責分析由中間件動態(tài)加載的橫切關注點所引起的性能影響因素，用到面向方面的橫切關注點性能影響因素分析技術。該模塊以面向方面的建模技術為基礎，采用模型編織技術算法，將對應的方面模型織入到不同的應用中。本發(fā)明對常規(guī)編織和建模方法做出相應簡化，只需考慮調(diào)用鏈的編織，而不需考慮組件的靜態(tài)結(jié)構(gòu)等情況，所需支持的連接點也只有方法調(diào)用一種。編織是將不同的方面模型織入原始模型，從而引入橫切關注點的性能影響因素。編織需要對三種不同類型的UML模型分別進行，而所需要的模型信息則從UML方面模型庫中査詢獲得。對于部署圖和協(xié)作圖的編織過程相對簡單，在實行參數(shù)綁定后，只需要在原始模型添加方面模型新增的組件。這些新增組件將被部署到指定的主機，同時建立與其它組件協(xié)作的方式。值得注意的是部署圖和協(xié)作圖中只描述了新增組件，并沒有描述調(diào)用者和橫切關注點之間的關系，而是沿用原始輸入模型中的描述。默認情況下新增的組件將與目標組件分配到同一臺主機，并采用"客戶機/服務器"請求模式與目標組件協(xié)作。經(jīng)過編織，部署圖中具有了四個組件，分別是Client、GenericAspect、Facade和Service組件。除了Client組件部署在ClientPC主機上之外，其它組件均部署在ServerStation上。協(xié)作圖此時也有四個組件，它們的協(xié)作關系是，Client到GenericAspect,GenericAspect到Facade,Facade到Service均通過"客戶機/服務器"交互?；顒訄D編織需要將方面模型插入到原始模型指定的位置，并重新建立調(diào)用關系。整個過程由參數(shù)綁定和模型關聯(lián)組成，參數(shù)綁定過程如前所述，此處模型關聯(lián)的步驟如下-第一步確定連接點。連接點位置由綁定規(guī)則給出，本實施例中連接點定義為Facade組件從prepare到process之間的活動。第二步確定連接點的輸入與輸出邊。輸入邊和輸出邊給出了其它組件對目標組件嵌套調(diào)用的范圍，連接點必須全部位于這一組邊所構(gòu)成的區(qū)域之內(nèi)。第三步重新關聯(lián)輸入邊與輸出邊。由于橫切關注點先于目標組件之前被調(diào)用，所以原始模型中其它組件對目標組件的請求將會被橫切關注點攔截。關聯(lián)首先需要斷開原有請求和響應事件的對應邊，記錄下與這兩條邊關聯(lián)的節(jié)點的四個位置。然后，將通用方面模板中的輸入輸出邊未與節(jié)點關聯(lián)的兩個端點關聯(lián)到請求組件對應的兩個位置，再將請求連接點的兩條邊與連接點關聯(lián)的兩個位置關聯(lián)到目標組件的對應位置。圖5給出了一個編織后的示意圖，圖中的小圓點代表重新關聯(lián)的四個位置。編織前，請求組件的請求活動直接調(diào)用目標組件的接受活動，而返回活動也是直接返回給響應活動。在編織后，通用方面模型被織入，原有的請求響應邊斷開，通用方面模型則關聯(lián)在請求組件和目標組件之間。關聯(lián)過程只與邊與活動的連接位置相關，而與活動無關，也就是說目標組件的接受活動和返回活動可以是一個活動，也可以是更加復雜的結(jié)構(gòu)。對于本實施例，當分析到Facade組件時，發(fā)現(xiàn)聲明文件中定義了該組件的橫切關注點信息，于是通過對中間件性能影響因素庫的查找，找到了如前所述的方面模型。再對方面模型實施綁定規(guī)則和模型綁定操作，即可得到一個織入橫切關注點信息的軟件模型。如果存在多個橫切關注點，織入過程會一直循環(huán)下去，直到所有橫切關注點均織入到原始模型中。之后，嵌套調(diào)度器將調(diào)度轉(zhuǎn)換器將包括所有橫切關注點和目標組件構(gòu)成的整體轉(zhuǎn)化為性能模型，再交由給性能模型加載器繼續(xù)處理。此時，中從初始任務到當前任務的性能模型已經(jīng)轉(zhuǎn)化成功，保存在嵌套調(diào)度器中，其中目標組件和它所擁有的橫切關注點作為一個方面子模型看待。經(jīng)過編織，本實施例的原始模型中由Client到Facade的請求則改由GenericAspect方面中轉(zhuǎn)。原來Client到Facade的請求邊則和GenericAspect的輸入邊結(jié)合，而由Facade返回Client的返回邊則與GenericAspect的輸出邊結(jié)合。通用方面模型中的連接點則替換為Facade組件在接受Client組件調(diào)用后執(zhí)行的操作。織入橫切關注點的過程可以看為橫切關注點在原先的請求關系之上，添加了一些額外的操作，使請求并不直接到達目標組件，而是通過橫切關注點中轉(zhuǎn)。(b)性能模型加載器用于分析中間件自身對組件性能的影響，用到基于性能模型的中間件性能影響因素分析技術。一個請求在到達組件服務器后，服務器會做出一系列繁瑣而重復的處理，直到完成所有操作，才會將請求轉(zhuǎn)發(fā)到相應的組件。這一系列的操作會為組件帶來明顯的性能影響，同時又考慮到系統(tǒng)設計人員不會關注于這些影響因素的細節(jié)，所以我們采用分層排隊網(wǎng)模型的性能模型進行中間件自身影響因素的建模。加載中間件性能模型的步驟如下-第一步分析組件類型。根據(jù)運行環(huán)境以及組件類型從中間件性能模型庫中査找相應的中間件性能模型。第二步組合由UML模型轉(zhuǎn)換而來的方面子模型和中間件性能模型。中間件性能模型預留了組件性能模型的空間，方面子模型則是當前組件和其橫切關注點的集合。斷開性能子模型中原有關聯(lián)方面子模型占位空間的請求，關聯(lián)到轉(zhuǎn)化后的實際方面子模型。第三步重新建立調(diào)用者與該組件間的聯(lián)系。斷開原有請求方面子模型調(diào)用的請求，關聯(lián)到組合后的性能模板接口上。圖6給出了一個加載示后的示意圖，圖中的小圓點代表重新關聯(lián)的兩個位置。加載前請求者任務(task)將會直接請求方面子模型。加載后包含了中間件性能模型則，請求經(jīng)過中間件任務后才會到達方面子模型。此示意圖里中間件只包含了一個任務，方面子模型也包含了一個橫切關注點，實際情況將比這復雜。在我們的實施例中Facade組件是一個有狀態(tài)會話Bean組件，中間件加載模塊會使用如前所述的中間件性能模型加載中間件性能影響因素。該模型包含了中間件處理有狀態(tài)會話Bean組件的關鍵操作，并為目標組件預留了一個方面子模型。加載后Client組件的請求首先經(jīng)過該模型描述的一系列操作，如線程池，共享區(qū)域等。然后才由中間件轉(zhuǎn)發(fā)到方面子模型，經(jīng)過GenericAspect橫切關注點后才最終到達Facade組件。(c)第三方組件引入器負責分析當前組件使用其它組件的情況，并在該組件分析結(jié)束之后，引入被該組件引用的其它組件。通過與嵌套調(diào)度模塊的交互，對服務和組件的分析便會一直遞歸嵌套下去，直到組件不再引用其它組件為止。該模塊用到了申明式第三方組件引入技術。被調(diào)用的組件可以是設計人員自己提供的，也可以是由服務器提供的第三方組件。對于設計人員自己設計的組件，所有必要的信息都可以直接獲取，直接進行嵌套分析，不需要額外的引入操作細化實現(xiàn)細節(jié)；而對于應用的其它服務則需要額外的信息輔助分析，這些信息存放在第三方組件模型庫中。第三方組件引入過程分為兩大步驟一是確定組件引用方式，査找相應第三方組件模型；二是替換原始模型中被引用組件。確定組件引用方式需要結(jié)合聲明信息確定是否對中間件性能影響因素庫進行查找。首先要確定第三方組件的調(diào)用關系，可從UML圖中獲??；接著在聲明信息中査找第三方組件信息，如果發(fā)現(xiàn)有調(diào)用發(fā)生且調(diào)用的是第三方組件，則從庫中查找相應的第三方組件模型，否則該組件為用戶自定義組件，不需要對其進行替換操作。此處替換操作目的是用第三方組件模型替換原始模型中對該組件的調(diào)用，使原始模型中抽象調(diào)用關系替換為擁有詳細性能影響因素的第三方模型，從而構(gòu)造出完整的調(diào)用圖，并引入相關影響因素。對于部署圖和協(xié)作圖的替換方法與編織過程類似，這里不再贅述。本實施例中，處理完部署圖和協(xié)作圖后，原先部署圖和協(xié)作圖中的組件會增加到五個，兩幅圖中均增加了一個DataAccess組件，該組件部署在ServerStation主機上，與Server組件采用"客戶機/服務器"方式交互。對于紹活動圖的替換有如下的步驟第一步確定替換位置。被替換的節(jié)點在原始模型中僅是一個活動，抽象描述該調(diào)用過程，第三方組件模型將被替換到此處。第二步斷開原有關聯(lián)。斷開原始模型中調(diào)用與被調(diào)用組件間的關聯(lián)關系，即斷開原有輸入邊和輸出邊關聯(lián)的活動。第三步關聯(lián)第三方組件。將第三方組件的輸入與輸出邊對應的活動關聯(lián)到原始模中，建立起新的調(diào)用關系。圖7給出了一個引入第三方組件后的示意圖，圖中的小圓點代表重新關聯(lián)的兩個位置；引入前目標組件只有一個活動，引入后目標組件的執(zhí)行細節(jié)則描述出來。目標組件的執(zhí)行過程定義在第三方組件模型當中，它可以調(diào)用其它一些原始模型中并未出現(xiàn)的組件。此時引入的第三方組件將作為新的當前分析節(jié)點，被該組件調(diào)用的其它組件則作為第三方組件處理。對于本實施例替換過程如下在分析完Facade組件時，引入模塊開始分析被其調(diào)用的其它組件，由于此時會發(fā)現(xiàn)原始模型中的Service組件是一個第三方組件，所以需要接著査找該組件模型，將其替換到原始模型中，并重新建立調(diào)用關系。此時，一個完整的調(diào)用關系圖就已構(gòu)造出來。默認情況下第三方組件將被部署到與調(diào)用者相同的主機上，采用"客戶機/服務器"的方式協(xié)作。嵌套分析器則調(diào)度分析嵌套順序，對引入的第三方組件進行嵌套分析。替換之后原始模型中Facade組件對Service組件的調(diào)用則從一個簡單的活動，轉(zhuǎn)換為由具有詳細調(diào)用細節(jié)的活動組合。原始模型的doBiisiness活動替換為第三方組件模型中定義的調(diào)用過程，并且引入了原始模型中不存在的DataAccess組件。此時，第三方組件的輸入輸出邊與原始模型中對doBusiness活動的請求和響應邊對應。經(jīng)過如上所述步驟，分析結(jié)束時，一個完整的性能就已構(gòu)造完畢。對于本實施例，完整性能模型包含了從請求最初發(fā)起到最終結(jié)束的所有執(zhí)行細節(jié)。在此模型中，客戶端Client組件對服務器端Facade組件的請求首先需要經(jīng)過中間件的相關處理，然后轉(zhuǎn)發(fā)到相應的橫切關注點，最后才會被轉(zhuǎn)發(fā)到目標組件。該組件繼而又調(diào)用了Service組件和DataAccess組件。在本實施例中Service組件和DataAccess組件均為簡單組件，因而不像Facade組件加入了其它性能影響因素?？偟膩碚f，性能分析與編排模塊可看作性能影響因素的加載模塊，其各個子模塊在嵌套調(diào)度器的控制下，有序的對原始模型進行橫切關注點分析，中間件影響因素分析和第三方組件分析，并最終生成一個完整的包含各種性能影響因素的性能模型。四、分析計算模塊分析計算模塊主要負責求解轉(zhuǎn)化得來的完整性能模型，并得出最終需要的性能預測數(shù)據(jù)。該模塊主要由系統(tǒng)資源消耗加載器和模型分析計算器組成。1.資源消耗加載器負責根據(jù)不同的運行平臺加載相應的系統(tǒng)資源消耗數(shù)據(jù)，這里主要考慮的是處理器運算時間、共享資源個數(shù)(比如說線程池大小和調(diào)度策略)等。考慮到目標系統(tǒng)可能運行在不同的硬件環(huán)境，庫中存放了多種典型硬件環(huán)境下測試出的資源消耗量。模型中對資源的需求均以參數(shù)的形式給出，實際求解前先由設計人員選擇運行平臺，再由該加載器從平臺相關資源庫中查詢數(shù)據(jù)賦予實際值。實際預測的參數(shù)信息一部分從用戶的聲明文件中獲取，比如服務器線程池的配置等；一部分從平臺相關資源庫中讀取，比如某組件的處理器消耗時間。參數(shù)以"鍵/值"對的形式存放，模型中以首字母"$"作為標示。以下給出一段參數(shù)值片斷。$s—checkAccess=1.325ms;$s—getThread=0.0135ms;$s_prepareBean=0.472ms;$s—callback=0.513;2.模型分析計算器是一個求解分層排隊網(wǎng)工具的計算工具，可以通過分析工具LQNS和模擬工具LQNSim進行求解(M.WoodsideandG.Franks,"TutorialIntroductiontoLayeredModelingofSoftwarePerfromance",http:〃www.sce.carieton.ca/rads/lqns/lqn-documentation)。該工具的輸入是一個符合分層排隊網(wǎng)模型的性能模型，輸出則是性能預測的結(jié)果。結(jié)果包含了系統(tǒng)總的響應時間、吞吐率、處理器利用率和單個組件的使用率、總執(zhí)行時間等數(shù)據(jù)。本實施例所收集的測試結(jié)果片斷如下#$N，$T，$R，$UServerPC,$AM20.2969456.735260.75038970.15775940.33855711.81480.855545620.17986760.36088516.62580.911969530.19172980.37413821.38250.945459730.19877100.38253926.14110.966689530.203234120,38104231.49260.962906960.202438140.38034136.80910.96113560.202066160.37894542.22250.957607020.201324180.37741247,69320.953734420.20051200.37594453.19940.950024740.19973以上結(jié)果表示本實施例收集的數(shù)據(jù)，自左向右依次分別為并發(fā)用戶數(shù)、系統(tǒng)吞吐率(c/ms)、響應時間(ms)、服務器處理器利用率(％)和橫切關注點占用處理器的利用率(％)。可收集的數(shù)據(jù)不限于以上幾種，求解工具允許用戶自行定義。依據(jù)這些數(shù)據(jù)，設計人員可以清晰地了解不同負載下系統(tǒng)的性能狀況，再參照最終系統(tǒng)的需求說明，便可判斷當前設計是否滿足需求。特別是在有若千備選方案的情況下，通過比較預測結(jié)果，可以從中選擇相對最優(yōu)的方案。總的來說，分析計算模塊可以看作一個計算輸出模塊。通過加載硬件相關的資源消耗需求數(shù)據(jù)并調(diào)用相關求解器求解，即可得出最終性能預測結(jié)果。以上是完成本發(fā)明組件系統(tǒng)性能預測方法的四個主體模塊，它們分工合作，有機的貫穿了預測的整個過程。各種相對固定，具有穩(wěn)定結(jié)構(gòu)的性能影響因素以可嵌套模型的形式獨立存儲在中間件性能影響因素庫中。以這些模型為基礎，一個抽象的不包含任何中間件平臺信息的軟件系統(tǒng)體系結(jié)構(gòu)，便轉(zhuǎn)化為包含詳細性能影響因素的完整性能模型。結(jié)合已有的數(shù)學工具，即可求解出性能預測結(jié)果?？偠灾?，本發(fā)明以簡化預測過程為目標，以可嵌套模型為核心，以模型驅(qū)動為指導，以模型轉(zhuǎn)換為具體實施策略，逐步將各種性能影響因素編排到原始輸入模型，并最終計算出預測結(jié)果，輔助設計人員盡早發(fā)現(xiàn)設計缺陷，篩選備選方案，降低性能調(diào)優(yōu)代價，縮短系統(tǒng)調(diào)優(yōu)周期。權利要求1.一種基于中間件的組件系統(tǒng)性能預測方法，其步驟包括1)載入軟件體系結(jié)構(gòu)原始模型，確定中間件平臺，所述軟件體系結(jié)構(gòu)原始模型包括應用聲明文件、部署圖、協(xié)作圖和活動圖；2)分割器分析所述原始模型，選取入度為0的節(jié)點作為當前待分析組件；3)橫切點分析器分析當前待分析組件是否存在未編織的橫切關注點，若存在，編織橫切關注點模板，并將原始模型轉(zhuǎn)換為性能模型；4)性能模板加載器分析當前待分析組件是否受中間件平臺的影響，若是，加載中間件性能模板；5)調(diào)度器分析當前節(jié)點所引用的其它組件是否存在未處理的，若存在轉(zhuǎn)入步驟6)；否則判斷當前節(jié)點是否存在父節(jié)點，若有父節(jié)點作為當前待分析節(jié)點重復步驟5)；6)第三方組件引入器分析當前待分析組件是否為第三方組件，若是，則引入第三方組件模板，并調(diào)用分割器更新當前分析節(jié)點；否則直接更新當前分析節(jié)點，并返回步驟3)。2.如權利要求l所述的一種方法，其特征在于步驟6)后增加如下操作確定測試硬件環(huán)境、載入資源消耗消耗數(shù)據(jù)，使用分層排隊網(wǎng)求解工具計算組件系統(tǒng)性能。3.如權利要求1所述的一種方法，其特征在于步驟3)中編織橫切關注點模板的方法如下1)設定綁定規(guī)則將應用無關的模型轉(zhuǎn)化為與特定應用上下文相關的模型；2)由綁定規(guī)則獲得確定連接點位置、連接點的輸入與輸出邊；斷開原有請求和響應事件的對應邊，記錄與這兩條邊關聯(lián)的四個節(jié)點位置，將通用方面模板中的輸入輸出邊未與節(jié)點關聯(lián)的兩個端點關聯(lián)到請求組件對應的兩個位置，并將請求連接點的兩條邊與連接點關聯(lián)的兩個位置關聯(lián)到目標組件的對應位置。4.如權利要求1所述的一種方法，其特征在于步驟3)中將原始模型轉(zhuǎn)換為性能模型基于中間模型的轉(zhuǎn)換算法。5.如權利要求1所述的一種方法，其特征在于步驟4)中加載中間件性能模塊的方法如下1)根據(jù)運行環(huán)境以及組件類型在中間件性能模型庫中査找中間件性能模型；2)斷開性能子模型中原有關聯(lián)方面子模型占位空間的請求，關聯(lián)到轉(zhuǎn)化后的實際方面子模型；3)斷開原有請求方面子模型調(diào)用的請求，關聯(lián)到組合后的性能模板接口上，重新建立調(diào)用者與該組件間的聯(lián)系。6.如權利要求1所述的一種方法，其特征在于步驟6)中引入第三方組件的方法如下1)利用UML圖確定第三方組件的調(diào)用關系，在聲明信息中找出發(fā)生調(diào)用的第三方組件信息，并從中間件性能影響因素庫中査找對應的第三方組件模型；2)替換原始模型中被引用組件。7.如權利要求6所述的一種方法，其特征在于所述替換的步驟如下確定替換位置；斷開原始模型中調(diào)用與被調(diào)用組件間的關聯(lián)關系；將第三方組件的輸入與輸出邊對應的活動關聯(lián)到原始模中，建立起新的調(diào)用關系。8.—種基于中間件的組件系統(tǒng)性能預測系統(tǒng)，其特征在于，所述系統(tǒng)包括UML模型載入模塊、中間件性能影響因素庫?？旒靶阅芊治雠c編排模塊；所述UML模型載入模塊用于將設計人員提供的UML模型和相關聲明信息，載入原始模型，確定中間件平臺；所述中間件性能影響因素庫模塊包括用于存放分析橫切關注點所需的UML方面模型信息的通用方面模型、用于存放中間件性能影響因素的性能模型信息的中間件性能模型，及用于存放被引用的第三方組件的模型信息和相關聲明信息的第三方組件模型庫；所述性能分析與編排模塊包括分割器、橫切點分析器、性能模板加載器、第三方組件引入器及轉(zhuǎn)換器；所述分割器用于分析原始模型，選取當前待分析組件；所述橫切關注點分析器用于分析由中間件動態(tài)加載的橫切關注點所引起的性能影響因素；所述性能模板加載器用于分析中間件對組件性能的影響；所述第三方組件引入器用于分析性能模型是否存在未引入的第三方組件，并引入被當前調(diào)用的第三方組件模型；所述轉(zhuǎn)換器用于將原始模型轉(zhuǎn)換為性能模型。9.如權利要求1所述的一種系統(tǒng)，其特征在于所述系統(tǒng)還包括系統(tǒng)資源消耗加載器和模型分析計算器，所述系統(tǒng)資源消耗加載器用于根據(jù)不同的運行平臺加載相應的系統(tǒng)資源消耗數(shù)據(jù)；所述模型分析計算器通過求解分層排隊網(wǎng)工具分析計算上述系統(tǒng)資源消耗數(shù)據(jù)，獲得性能預測的數(shù)據(jù)。全文摘要本發(fā)明屬于計算機網(wǎng)絡和數(shù)據(jù)通信
技術領域：
，具體涉及一種基于可嵌套模型的中間件性能預測方法，以模型轉(zhuǎn)換分析為基礎，通過嵌套分析的方法構(gòu)建中間件完整性能模型，并最終生成預測結(jié)果。本發(fā)明通過采用性能分析與編排模塊及中間件性能影響因素庫，將原始模型將被轉(zhuǎn)化為分層排隊網(wǎng)模型，并構(gòu)成該組件完整的性能模型，通過分析工具LQNS和模擬工具LQNSim進行求解，獲得基于中間件的組件系統(tǒng)性能預測的數(shù)據(jù)。本發(fā)明支持多中間件類型、多中間件實現(xiàn)產(chǎn)品和多運行平臺，將系統(tǒng)建模與性能預測過程統(tǒng)一，無須設計人員花費額外精力進行性能建模。文檔編號G06F9/44GK101373432SQ20081022304公開日2009年2月25日申請日期2008年9月26日優(yōu)先權日2008年9月26日發(fā)明者波張,張文博,峻魏,濤黃,翔黃申請人:中國科學院軟件研究所