平臺無關服務建模技術的製作方法

2023-06-07 14:00:36 2

專利名稱：：平臺無關服務建模技術的製作方法
技術領域：
：本發明大體涉及產生平臺無關服務模型的領域。更具體地，本發明涉及形成平臺特定物理工件(artifact)的基礎的平臺無關服務模型的產生。
背景技術：
：軟體幵發通常以創建邏輯模型而開始，該邏輯模型反映了待開發軟體的特定流程的功能性要求。在這種模型驅動方法中，必須把邏輯模型轉換為額外地滿足非功能性要求的物理表示或工件(例如代碼表示)。非功能性要求中存在特定軟體和硬體平臺的技術性約束，包括必須加以考慮的程式語言。為了產生物理代碼，必須向邏輯模型應用規則和樣式集。例如在某些情況下，軟體架構定義了不同種類的類(class)。第一種類的類可以表示持久性實體，而第二種類的類表示流程(process)或流程步驟。邏輯模型的特定元素是實體，而流程當然是一個功能性問題。然而，將邏輯實體最終轉換為相應的物理表示的方式通常對於所有邏輯實體是相同的，並且對於邏輯流程的轉換也是相同的。為了幫助軟體開發者並使軟體開發流程中儘可能多的步驟自動化，已經引入生成軟體開發方法。生成軟體開發利用如下事實從邏輯模型到物理工件的步驟可以被看作向邏輯模型的各種元素應用轉換規則集。所以基本上，需要定義各個轉換，指定何時應用，並為邏輯模型標註一些控制信息，該控制信息控制自動化的轉換流程。典型地，通過模板來定義轉換。對於需要產生的每一種不同的物理工件，必須提供單獨的模板或模板集。該模板包括規定了怎樣把邏輯模型的各個元素轉換為其物理對應物的轉換邏輯。該邏輯模型又包括規定將哪個模板用於特定類型的模型元素的標註。在傳統的UML(統一建模語言)的場景下，該標註例如由構造型(stereotype)或標記值所組成。由於模型中沒有定義每個細節，所以可通過在所產生的物理結構中進行編程而定義特定的程序方面。因此，模型可以包括受保護區，在受保護區中，開發者可以直接寫入受保護而免於進行轉換的程序代碼。受保護區確保手動輸入的代碼在模型中可經受變化。所以，即使模型(例如迭代地)發生變化，受保護區中的代碼仍保留在相同的邏輯位置中。當今，試圖把模型驅動開發(MDD)的概念應用於作為所謂的面向服務架構(S0A)的基礎的服務範例。SOA旨在通過各個服務而提供複雜軟體組件的功能。在SOA的上下文中，可以使用和重新使用各個服務，而不是把相應的程序代碼或更常見的物理工件進行複製。這是可能的，因為服務是從特殊的平臺特定實現中抽取出的。在傳統的S0A中，各個服務僅被當作具有與其他服務的接口的"黑箱"。換句話說，該服務的內部結構對於SOA的實現並不扮演主要角色。然而，當把MDD的原理應用於各個服務的建模時，服務模型的內部結構當然是重要的方面。因此，本發明的目的大體上涉及一種MDD與SOA的有效組合。具體地，需要一種針對生成軟體開發的有效率的服務建模技術。
發明內容根據第一方面，提供了一種模板驅動系統，用於根據平臺無關服務模型而產生平臺特定工件，例如程序代碼。所述系統包括模板存儲器，具有平臺特定模板，每一個模板包括平臺特定模型轉換信息；倉庫，具有多個至少本質上為平臺無關的服務模型元素，以及根據所述模型元素而建模的一個或更多個服務模型；以及生成器，適於通過把所述模板中包括的轉換信息應用於所述服務模型而生成平臺特定工件。儘管服務模型和構成服務模型的模型元素可能在最大程度上是平臺無關的，然而在一個變體中，模型元素可能與少量平臺特定信息相關聯。對於例如與屬性相對應的模型元素，該平臺特定信息可以包括與屬性有關的格式信息。服務模型元素中至少一些可以由兩個或更多個服務模型共享。這種針對多個服務模型而重新使用先前定義的模型元素減少了冗餘的建模工作量。此外，有利於進行改變管理，因為各個模型元素的改變將自動反映在包括該模型元素的每一個服務模型中。所述系統還包括服務模型創建器，用於創建至少一個服務模型元素並根據所述服務模型元素而創建平臺無關服務模型。所述服務模型創建器的輸出優選地存儲在所述倉庫中。在一個變體中，所述倉庫中包括的服務模型元素具有分層結構。該分層結構便於創建服務模型，且額外地有助於對倉庫的內部設計進行結構化。所述倉庫可以被配置為資料庫(例如關係資料庫)。基於具有分層結構的模型元素，根據較高層級的一個或更多個第一模型元素以及較低層級的一個或更多個第二模型元素，來建模每一個服務。在服務模型中，每一個第一模型元素可與一個或更多個第二模型元素相關聯。在這種情況下，所述一個或更多個第二模型元素優選地構成了第一模型元素的屬性。第一模型元素可以定義一個或更多個服務輸入參數以及一個或更多個服務輸出參數中至少一項。另一方面，第二模型元素可以構成服務輸入參數樹(tree)和服務輸出參數樹中至少一項中的葉(leaf)欄位。在其他變體中，所述倉庫中的服務模型與映射相關聯。所述映射可以出現在兩個或更多個模型元素之間，或出現在模型元素和資料庫表之間。所述映射可以定義屬於相同層級的模型元素之間的轉移操作。在一種實現中，所述映射定義了一個或更多個服務輸入參數與一個或更多個服務輸出參數之間的轉移操作。所述輸入參數和輸出參數可以屬於同一個服務，或可選地，屬於不同的服務。對於服務建模，預定義的服務類型和服務公幵度(publicity)是可選擇的。服務模型創建器則可以允許選擇服務類型和服務公幵度中的至少一項。優選地，所述服務類型包括以下一種或多種流程服務、實體服務、呈現服務、技術服務、批作業和査看。在這種情景下，所述模板存儲器可包括針對每一個服務類型的至少一個專用模板。因此，所述服務類型可以被解釋為轉換控制參數。另外，可定義特定種類的第一模型元素，並可通過服務模型創建器選擇用於服務建模。所述種類的第一模型元素可以在生成物理工件時構成轉換控制參數。所產生的工件可包括以下中的至少一項Java代碼、Cobol代碼、HTML代碼和XML代碼。可存在定義了特定服務模型的物理實現的多種預定義平臺類型。優選地，所述生成器允許選擇平臺類型。對於每一種平臺類型，所述模板存儲器可以包括至少一個專用模板。此外，所述模板存儲器可以包括針對服務類型和平臺類型的各種組合的至少一個專用模板。根據本發明的其他方面，提供了一種倉庫資料庫。所述倉庫資料庫包括至少本質上為平臺無關的模型元素以及根據所述模型元素而建模的服務模型，所述服務模型形成了用於在平臺特定模板的控制下生成平臺特定工件的基礎，每一個模板包括平臺特定模型轉換信息。根據本發明的其他方面，提供了一種方法，用於根據平臺無關服務模型而產生平臺特定工件，例如程序代碼。所述方法包括以下步驟提供平臺特定模板，每一個模板包括平臺特定模型轉換信息；提供多個至少本質上為平臺無關的服務模型元素，以及根據所述模型元素而建模的一個或更多個服務模型；以及通過把所述模板中包括的轉換信息應用於所述服務模型而生成平臺特定工件。本發明能夠以硬體、軟體或組合的硬體/軟體方法來實踐。對於軟體方面，提供了一種電腦程式產品。所述電腦程式產品包括程序代碼部分，當所述電腦程式產品運行在一個或更多個計算設備上時，所述程序代碼部分用於執行本發明的步驟。所述電腦程式產品可以存儲在計算機可讀記錄介質上。下文參考附圖中所示的典型實施例來描述本發明，其中圖l是示出本發明的第一設備實施例的示意性框圖圖2是示出本發明的第一方法實施例的流程圖；圖3是示出本發明的第二設備實施例的示意性框圖；圖4是示出第二實施例的主要功能的示意圖；圖5是示出實施例的上下文以及兩個不同的服務建模方法中所使用的迭代開發流程的示意圖；圖6是示出實施例中所使用的邏輯數據模型的主要實體的示意圖；圖7至9是示出圖6中的邏輯數據模型的各個部分的示意圖；圖10是示出與兩個基礎建模方法有關的決策過程的流程圖；圖ll是示出用於產生服務模型的第二方法實施例的基本步驟的流程圖；圖lla是示出這裡所用的各種服務的定義的概圖；以及圖12至74示出了用於第二方法實施例中的各種用戶界面。具體實施方式在下文描述中，為了說明而非限制，提出了特定細節，例如步驟的特定次序、用戶界面以及設備配置，以提供對本發明的完整理解。對於本領域的技術人員明顯的是，本發明可以以不同於這些特定細節的其他實施例來實踐。此外，本領域的技術人員可以理解，下文描述的功能可以使用與編程的微處理器或通用計算機一同工作的軟體來實現。還可以理解的是，雖然本發明主要以方法和設備的形式來描述，然而本發明還可以在電腦程式產品或如下系統中體現該系統包括計算機處理器和耦合至該處理器的存儲器，其中，該存儲器被編碼有可以執行這裡公幵的功能的一個或更多個程序。圖l示出了用於根據平臺無關服務模型而產生平臺特定工件的模板驅動系統100的實施例。系統100包括三個主要組件，模板存儲器102、倉庫資料庫104和平臺特定工件生成器106。在模板存儲器102中存儲有平臺特定模板。每一個模板包括平臺特定轉換信息。倉庫資料庫104包括多個至少本質上為平臺無關的服務模型元素以及根據該模型元素而建模的一個或更多個服務模型。優選地，倉庫資料庫中所包括的模型元素由若干服務模型共享。這減小了必須存儲的模型元素的總數目。生成器106產生平臺特定工件。對此，將模板存儲器102中所包括的一個或更多個平臺特定模板應用於倉庫資料庫104中存儲的平臺無關服務模型。圖2是示出用於根據平臺無關服務模型而產生平臺特定工件的方法實施例的流程圖200。該方法可以由圖1所示的系統100或任意其他設備來執行。該方法在步驟202處開始，提供平臺特定模板。每一個模板包括把特定服務模型轉換為特定工件所需的平臺特定轉換信息。在步驟204，提供多個至少本質上為平臺無關的服務模型元素。另外，提供根據該模型元素而建模的一個或更多個服務模型。在步驟206，產生平臺特定工件。為了產生工件，把一個或更多個平臺特定模板應用於特定的平臺無關服務模型。圖3示出了用於根據平臺無關服務模型來產生工件的另一個系統300。該系統300包括針對服務模型(以及服務模型元素)的倉庫資料庫302，以及用於針對倉庫資料庫302中存儲的服務模型而產生工件308的模板驅動生成器304。服務模型至工件的轉換由模板文件306來控制。在本實施例中，針對每一個單獨的平臺，提供一個或更多個模板文件306的特定集合。如果需要，在把所產生的工件存儲到軟體組件管理倉庫310中之前，可以手動地完成所產生的工件(例如在所謂的受保護區中)。圖4示意性地示出了在上文所述系統100和300中實現從平臺無關模型至平臺特定工件的方式從平臺無關組件模型開始，首先產生平臺無關服務模型。然後把該平臺無關服務模型轉換為平臺特定工件，例如可執行的呈現或應用(業務)服務。圖5的左側示出了從服務模型開始的服務迭代產生。右側示出了用於產生物理工件的兩個基本方法，即自頂向下方法和自底向上方法。稍後參考圖12至74的用戶界面來詳細描述這些方法。圖6中示出了本實施例中所使用的邏輯數據模型的主要元素。邏輯數據模型提供了倉庫資料庫302的物理資料庫設計的基礎。其與實施方式無關，因而使資料庫規範和資料庫實現之間存在明顯的區別。其物理模型更為複雜，而且包含更多的元素，這些元素與存儲關於每一個主要元素的所有細節信息有關。然而，圖6所示的邏輯數據模型是整個倉庫資料庫的關鍵。一種服務是根據兩個基本的分層結構的模型元素而建模的，這兩個模型元素即複合類型模型元素(簡稱為"複合類型")以及數據項模型元素(或簡稱為"數據項")，複合類型模型元素再次包括複合類型的模型元素。這些模型元素在圖7中示出。服務與這兩個模型元素類別之間的關係通過圖8中所示的欄位元素來表示。該欄位元素是單獨數據項的實例，並管理複合類型內的數據項的關係和使用。各個服務之間的關係通過圖9中所示的映射元素而表示。在下文中，參考圖10至74來討論用於產生針對特定軟體組件的服務模型的工具。如圖10所示，以及在圖5的上下文中所提到的，該工具允許兩種服務建模方式。圖10左側所示的自頂向下實現用於不存在可重新使用的特有工件的情況下("綠欄位建模")。圖10右側所示的自底向上實現具有一些先決條件，一些物理實現(例如資料庫表描述、原始碼、...)將重新用於服務設計("基於物理工件的建模")。每一種情況下的元模型(metamodel)相同。首先，參考下表所列和圖ll所示的步驟來描述自頂向下的實現-tableseeoriginaldocumentpage11tableseeoriginaldocumentpage12例如，要為其創建服務模型的服務可以是資料庫中顧客地址的變化(mutation),或搜索滿足特定標準的資料庫中的顧客。在開始服務建模前，軟體開發者必須考慮待建模的服務的接口，即輸入和輸出參數，並考慮怎樣把輸入參數傳遞("映射")給輸出參數。現在參考圖ll中的步驟l，針對特定軟體組件(可能包括其他服務)的新服務模型的啟動從顯示圖12所示的圖形用戶界面開始。圖12中的用戶界面要求輸入下表中所示的服務參數-tableseeoriginaldocumentpage12tableseeoriginaldocumentpage13該工具支持不同的服務類型和不同的公開度類別。圖Ua以分層的方式示意性地示出了可以選擇的各種服務類型中的一些。呈現服務位於上層。這個服務類型主要提供在向用戶請求信息和/或向用戶顯示信息的上下文中的可視功能。在低層，提供了資料庫服務。中層提供了既不是呈現服務又不是資料庫服務的一般應用服務(這裡有時被稱作業務服務)。存在兩種類型的應用服務流程服務和實體服務。實體服務通常進行資料庫訪問(例如使用相應的資料庫服務從資料庫讀數據或向資料庫寫數據)。另一方面，流程服務不進行(直接的)資料庫訪問。其執行一個或更多個專用的處理操作，並包括該任務所需的應用邏輯。通過圖12的用戶界面來選擇特定的服務類型將會對稍後在把相應的服務模型轉換為特定工件時所使用的模板(或模板集)產生影響。換句話說，將會有一個或更多個針對呈現服務的專用模板(例如指定所產生的圖形用戶界面的可視外觀)、一個或更多個針對實體服務的專用模板(例如指定資料庫接口)等。上表中的每一個公開度類別指示服務模型(或其元素)重新使用分層軟體環境的可能性，從較低層到較高層來說，該環境包括"軟體組件"、"業務域"和"業務系統"。軟體組件自身還以如下方式分類:每一個單獨的軟體組件類別與特定的服務類型子集(以及可選地，公開度類別)相關聯。原理上，服務總是屬於特定的軟體組件，這意味著通過相關的軟體組件來執行服務管理。每一個軟體組件都具有所有者，同時該所有者是分配給該軟體組件的所有服務的所有者。如上所述，存在不同類別的軟體組件(例如後端的應用組件、前端的呈現組件以及針對技術目的的技術組件)。因此，呈現服務可以僅存在於呈現組件內，應用服務可以僅存在於應用組件內，等等。一般說來，特定軟體組件的類型控制可能與之相關聯的服務類型。例如，呈現服務可能不會存在於應用組件內。另一方面，呈現服務總是請求至少一個應用服務執行後端中的操作(例如後端處理操作或資料庫操作)。其原因是，呈現服務不被允許訪問資料庫或包括後端處理邏輯。這些任務總是由應用/業務服務來執行。現在回到圖12，點擊"Next"按鈕將導致圖13的用戶界面。使用這個用戶界面，可以選擇輸入的類型(這裡僅有選項"New,e卿tyinterface"可用)。通過點擊"Finish",該工具創建具有先前用戶界面中設置的版本(如果沒有改變，則是"1.0.0")的新服務。為了改變服務參數或向服務添加屬性，需要在服務編輯器模塊(未示出)中重新打幵該服務。圖14示出了允許對新產生的服務的"basicdata"進行編輯的相應的用戶界面。可以通過圖14中所示用戶界面左下角的標籤"Attributes"來定義與實現(iraplementation)有關的屬性。圖15中示出了"Attributes"用戶界面。應當注意的是，儘管服務建模在很大程度上是與實現無關的，然而在對服務進行建模時指定少量的與實現有關的信息是有利的。一旦已經定義了新服務的基本數據和屬性，該建模繼續進行，把一個或更多個"複合類型"的模型元素與待建模的服務進行關聯。已參考圖7做出說明，在本實施例的服務模型中，每一個服務必須包括一個或更多個複合類型，而且每一個複合類型可能又包括一個或更多個其他的複合類型。在詳細討論向服務分配複合類型的模型元素之前，首先討論與複合類型有關的典型服務建模規則。在本實施例中，定義了三種不同的這種元素即序列型(圖16)、列表型(圖17)和選擇型(圖1S)。每一特定種類的複合類型與產生工件時特定的轉換操作相關聯。因此，與服務類型相似，模型創建期間所指定的複合類型的種類用作後續轉換過程的控制參數。為了更好的理解，在具有地址數據欄位的典型上下文中解釋不同的種類。圖16示出了序列類的複合類型"Adresse"。這種複合類型包括各個欄位的序列(見圖8)，這裡標為"Address-Element—1"至"Address—Element—4"，如下表所示tableseeoriginaldocumentpage15當碼生成器把圖16中的複合類型"Adresse"轉換為典型文檔類型描述(DTD)碼時，將產生如下輸出(工件部分)〈!ELEMENTAddress—Element—4(#PCDATA)>當把圖16中的複合類型"Adresse"轉換為典型C0B0L習字本(copybook)碼時，將產生如下輸出(工件部分)05:BLW:-ADRESSE.10:BLW:-ADR匿ZEILE-110:BLW:-ADR-ZEILE-210:BLW:-ADR-ZEILE-310:BLW:-ADR-ZEILE-4PICX(35).PICX(35).PICX(35).PICX(35).圖17示出了列表型的複合類型"Address—Output"。這種複合類型包括一個或更多個序列型的複合類型(包括上述複合類型"Address"),並還包括下表所示的各個欄位(包括列表長度參數)名稱類型Address—Output複合類型/序列Address一ListJLength欄位/數字Address_List複合類型/序列Address複合類型/序列Address—Element—1欄位.Address—Element—2欄位Address一Element—3欄位Address—Element—4欄位當把圖17中的複合類型"Address—Output"轉換為典型文檔類型描述(DTD)碼時，將產生如下輸出(工件部分)〈!ELEMENTOutput(Address—Output)>〈！ELEMENTAddress—Output(AddressJ_ist_Length,Address_List)>〈!ELEMENTAddress—ElementJ(#PCDATA)>當把圖17中的複合類型"AddressJ)utput"轉換為典型C0B0L習字本碼時，將產生如下輸出(工件部分)05:BLW:-ADDRESS-OUTPUT.IO:BLW:-ADDRESS'UST丄ENGTHPIC9(6).iO:BLW:-ADD鄉S-LIST.OCCURS1TO卿TIMESDEP,INGON:隨:-ADDRESS-LIST-LENGTH.20:BLW:-ADR-ZEILE-1PICX(35).20:BLW:-ADR-ZEILE-2PICX(35).20:BLW:-ADR-ZEILE-3PICX(35).20:BLW:-ADR-ZEILE隱4PICX(35).圖18示出了選擇型的複合類型"Choice這種複合類型典型地包括兩種或更多種序列型(包括上述複合類型"Address"),如下表所示tableseeoriginaldocumentpage17tableseeoriginaldocumentpage18當把圖18中的複合類型"Choice"轉換為典型DTD碼時，將產生如下輸出(工件部分)〈!ELEMENTOutput(Choice)>當把圖18中的複合類型"Choice"轉換為典型COBOL習字本碼時,將產生如下輸出(工件部分)05:BLW:國C眼CE.IO:BLW:陽ADRESSEPRIVAT.15:BLW:-ADDRESS-ELEMENT-1PICX(35).15:BLW:-ADDRESS-ELEMENT-2PICX(35).15;BLW:-ADDRESS-ELEMENT-3PICX(35).15:BLW:-ADDRESS-ELEMENT-4PICX(35),IO:BLW:-ADRESSEGESCHAEFT.15:8LW:-ADDRESS-ELEMENT-1PICX(35).15:BLW:-ADDRESS-ELEMENT-2PICX(3S).15:BLW:-ADDRESS-ELEMENT-3PICX(35).15:隨:-ADDRESS-ELE,T-4PICX(35).在一些情況下，服務模型可以重新使用現有的複合類型，在其他情況下，必須創建新的複合類型。對於重新使用，可以從倉庫資料庫中包括的先前定義的複合類型中簡單地選擇所需的複合類型。可通過不兼容的公開度而防止重新使用先前定義的複合類型。現在，在圖19至27所示的用戶界面的上下文中討論新的複合類型的創建。新的複合類型的創建(圖11中的步驟2)從圖19的用戶界面幵始。這個用戶界面請求用戶指定新的待創建複合類型的名稱，以及該複合類型所要分配給的軟體組件。一旦己經輸入相應的數據，則可通過點擊"0K"按鈕來進行保存。在下一步驟，可通過圖20中所示的用戶界面來編輯新創建的複合類型。該用戶界面允許對複合類型的種類進行選擇(即上述的序列、列表或選擇型)。另外，圖20中的用戶界面基本上允許通過圖21所示的菜單來創建輸入或輸出欄位。這裡，"sibling"創建會創建出相同級別的元素，"child"創建會創建出子輩元素。基於數據項類型的葉屬性可以不包括任何子輩元素。當選擇"CreateChild"或"CreateSibling"時，提供了5個選項(在圖21所示的頂部上，選項"CreateSibling"被禁用)。這在下表中示出tableseeoriginaldocumentpage19tableseeoriginaldocumentpage20在圖21的用戶界面中，如果選擇選項"ExistingDataItem"，則顯示圖22的用戶界面。圖22的用戶界面構成了數據項選擇對話框，其允許重新使用倉庫資料庫中所包括的己有數據項。所有當前加載的數據項顯示在圖21中的用戶界面的下部。如果沒有顯示所需的數據項，則可以基於圖22的用戶界面的上部中指定的搜索標準而啟動對該數據項的搜索。一旦選擇將以新創建的複合類型而插入的數據項並點擊按鈕"0K",則創建基於所選數據項的複合類型的新欄位。在這個上下文中，將會顯示圖23中的用戶界面，並且能夠輸入該欄位的適當名稱。在圖21的用戶界面中，如果選擇選項"ExistingComplexType",則顯示圖24的用戶界面。圖24的用戶界面構成了複合類型選擇對話框。所有當前加載的複合類型顯示在圖24的用戶界面下部的結果列表中。如果所需的複合類型仍沒有顯示，則可以基於圖24的用戶界面的底部中指定的搜索標準而啟動搜索。一旦選擇將以新創建的複合類型而插入的數據項並點擊按鈕"OK"，則創建基於所選複合類型的新欄位，如圖25中所示。在圖21的用戶界面中，如果選擇選項"NewSequenceComplexType",則顯示圖26的用戶界面以創建新的複合類型。在圖26的用戶界面中，新的複合類型可以被賦予有特點的名稱，且參數"Kind"被預置為"Sequence"(見圖27)。以類似的方式，如果用戶在圖21的用戶界面中選擇選項"NewChoiceComplexType",則參數"Kind"將被預置為"Choice"。本實施例的建模工具不僅允許創建新的複合類型，而且還允許創建新的數據項(也會存儲在倉庫資料庫中)。在建模工具中，數據項主要用於定義服務參數。服務的輸入或輸出樹中每一個葉均基於數據項。通常，應當儘可能地重新使用現有數據項(如同參考圖21至23所述)。然而，仍可能存在這樣的情況，即不可避免地要創建新的數據項。新的數據項總是特定數據項，這意味著其在特定域中被創建，但是對於其在其他域中的意義和使用，其可以變為核心數據項。核心數據項表示公司的主要數據字典。圖28示出了允許為新的將要創建的數據項定義數據項屬性的用戶界面。該屬性包括name、description、length、category、parent禾口softwarecomponent。在本實施例中，數據項必須總是屬於特定的軟體組件。初始屬性在下表中詳細示出Name數據項的名稱。該名稱應當符合數據項的預定命名規則Description新數據項的描述Software允許選擇具有新數據項的軟Component件組件Category針對新數據項給出的選擇是-核心數據項-特定數據項-技術數據項ParentDataItem:除了基本數據項，所有數據項都從父數據項導出ParentLength表示父數據項的長度Length數據項的長度。該長度必須不為空。其必須小於或等於父長度。其必須不為零。一旦已經指定新數據項的參數，則可以點擊圖28中用戶界面的"OK"按鈕以創建該數據項。該數據項可以在之後通過圖29所示的數據項屬性用戶界面進行編輯。該用戶界面具有5個標籤，即"Basic"、"Physical","Business"、"GUI"和"Lifecycle"，分別如圖29、30、31、32和33所示。圖29所示的"Basic"屬性包括如下tableseeoriginaldocumentpage22圖30所示的"Physical"屬性允許關於新創建的數據項在模型級別上指定一些與實現有關的信息。可以指定的物理屬性包括如下；tableseeoriginaldocumentpage22分別設置物理屬性Implementation所選環境(上下文)中數據項的物理名稱DefaultImpi.Type所選環境(上下文)中可用數據類型的選擇ResultingType預設類型的結果以及與上下文無關的DI定義的長度。這個類型在產生特定上下文的工件期間使用圖31所示的"Business"(或應用)屬性包括如下BusinessRule定義數據項的有效值、基礎標準或內部結構的一個或更多個規則；包括數據項的語法和語義驗證Ext.BackusNaurForm根據IS0-EBNF(生產規則)的數據項內部結構的正式定義ObjectConstraintLangusge約束的正式描述，基於根據OCL的說明性語義InformationObject數據項所屬於的來自應用架構的信息對象SensitiveData定義是否對數值進行測試數據匿名圖32所示的"GUI"屬性用於控制各個用戶界面中數據項的呈現注意，數據項總是以相同的方式並以相同的標記示出給用戶。"GUI"屬性包括如下tableseeoriginaldocumentpage23tableseeoriginaldocumentpage24圖33所示的"Lifecycle"屬性反映出特定數據項("DI")的當前狀態。這些屬性主要用於數據項回顧。多數設置僅能夠由具有相應授權的用戶("DataManager")來設置和改變。"Ufecycle"屬性包括如下tableseeoriginaldocumentpage24服務的輸入和輸出參數組成了樹結構(其形式為"複合類型")0它們以類似於文件系統中的文件夾結構的方式而顯示在建模工具中。即，複合類型與文件夾相對應，而欄位(或屬性)與文件相對應。必須將每個欄位分配給數據項。建模工具允許通過樹編輯器(圖ll中的步驟2a)或備選地通過圖形編輯器(圖ll中的步驟2b)來規定輸入和輸出參數(即創建屬性)。在下文中，參考圖34至36所示的用戶界面來首先討論樹編輯器。打開服務並連續選擇"Interface"(見圖14)和"Tree"標籤將會打開圖34所示的針對輸入和輸出參數的編輯器。上部中的下拉菜單允許在"I叩ut"和"Output"之間進行切換。左側框架中示出了輸入或輸出複合類型各自的結構。在右側框架中，可以描述所選欄位的屬性。對左側框架中所示的複合類型中的元素進行右擊，創建新的輸入或輸出欄位(圖35)。當選擇"CreateChild"或"CreateSibling"時(還參見圖21和相應描述)，提供了若干可能Field-ExistingDataItem插入基於現有數據項的屬性Field-ExistingComplexType插入基於現有複合類型的結構Field—NewSequenceComplexType插入新的複合類型，其子輩形成序列Field-NewChoiceComplexType插入新的複合類型。在複合類型的具體實例中，僅存在一個子輩插入兄弟(sibling)將創建相同級別的元素；插入子輩(child)將創建元素的子輩。當然，基於數據項類型的葉屬性可以不包括任何子輩。應當注意的是，編輯器中不能創建新數據項。新數據項僅能夠在數據項資源管理器(explorer)中創建，如上文在圖28至33的上下文中所述。此外，不能夠在服務或複合類型編輯器中直接改變數據項的屬性。圖36的用戶界面示出了具有"choice"複合類型的元素的"I叩ut"複合類型的示例，如數編輯器所顯示。打開服務並連續選擇"Interface"(見圖14)和"Graphical"標籤將會打開圖37所示的針對輸入和輸出參數的圖形編輯器。在圖37的圖形編輯器中，以其各自的分層結構並行地示出輸入和輸出參數。不同種類的複合類型可以用不同的顏色以圖形的方式來表示。圖37左側的工具箱允許以如下選項來改變接口tableseeoriginaldocumentpage26如上所述，複合類型可以用作服務的輸入和輸出參數(或參數集)。現在，映射(圖11中的步驟3)定義了怎樣把複合類型轉為另一個複合類型並主要用於把特定服務的輸入參數映射為其輸出參數，如圖38中所示的兩個示範性複合類型。把服務的輸入複合類型映射至輸出複合類型意味著指定了服務的"算法"。其還意味著可以根據輸入直接計算輸出，而不需調用另一個服務。映射還用於把特定服務的輸入參數映射至資料庫表，或把第一服務的輸出參數映射至第二服務的輸入參數。在建模工具中，映射在服務編輯器的"Mappings"頁上定義。為了由後續的工件生成器進行正確處理，映射必須遵循特定命名慣例，這取決於映射類型。開發者可以為每一個映射定義名稱。這些名稱不存在技術限制，但應避免特殊符號，因為該名稱還將被用作所產生的代碼中的名稱。如果在特定實體服務中存在多於一個的映射，則相同的名稱應當用於所有映射。在流程服務中，相同的名稱應當用於兩個子步驟映射。為了創建新的映射，必須點擊服務編輯器的"Mappings"頁(見圖39)中的"Add"按鈕。可通過圖14所示的用戶界面的"Mappings"標籤來到達"Mappings"頁。響應"Add"按鈕的激活，可通過圖40所示的窗口來選擇映射類型，從而定義映射的主要屬性。映射種類對服務代碼框架的產生具有影響(如果需要，可以手動地完成"construct")。這不會影響服務編輯器的功能(例如映射來源、映射目標、映射操作)。在本實施例中，存在6種映射I叩ut、Output、Restriction、SubstepInput(Invoke或Call)、SubstepOutput禾口InternalMapping。這些映射種類的屬性在下表中概括Input使用服務輸入或子集而沒有任何限制Output沒有限制地把複合類型映射至服務輸出Restriction對兩個複合類型的映射設置約束；在SQL中，這與WHERE子句相對應Subst印-I叩ut麗OKE當調用服務以提供這個服務調用的輸入參數時，必須使用Substep-I叩ut—CALL當調用服務以提供這個服務調用的輸入參數時，可以使用(在z/0S中，僅用於相同的業務系統或共享服務)Substep-Output必須使用以獲取服務調用的輸出參數Internal-Mapping內部處理的助手映射(Helpermapping)如上所述，映射還可以用作兩個單獨服務之間轉移數據的工具。圖41示出了典型的場景。該示例示出了如何在服務"GetSingleKu油一VI—0"(B)內調用服務"GetltemList—VI—0"(A)。第一映射用於調用服務"B"，第二映射用於把服務"B"的結果返回服務"A"。圖42中示出了相應的用戶界面。苜先，把服務"A"的輸入複合類型映射到服務"B"的輸入複合類型，以便向服務"B"提供所需信息。接下來，把服務"B"的輸出複合類型映射到服務"A"的輸出複合類型。這意味著把參數從被調用的服務"B"轉移到"A"的輸出參數(參見圖43)。映射來源(source)和映射目標(target)可以手動地選擇，也可以通過圖39、42和43所示的用戶界面的"UseService"按鈕來選擇。然後，出現搜索對話框，其允許作為子步驟而選擇服務。在該選擇得以確認後，提供映射來源和映射目標，如圖44的用戶界面所示。該用戶界面提供了如下選項tableseeoriginaldocumentpage28除了定義映射來源和映射目標外，還必須定義映射操作。映射操作定義了怎樣把單獨的輸入欄位轉移至輸出欄位。圖45示出了在其中示出複製操作的用戶界面。該操作例如可用於通過一個或更多個實體服務和/或流程服務，在資料庫和呈現服務之間轉移數據。在圖45的用戶界面中，通過點擊映射來源部分中的一個欄位、映射目標部分中的一個欄位，並通過激活"Add"按鈕而向服務添加映射。如果需要，也可以定義更為複雜的操作。該建模工具額外還允許針對待建模的服務的錯誤消息管理。現在，參考圖46至52中的用戶界面來詳細描述錯誤消息管理(圖ll中的步驟4)。在圖14所示的服務編輯器起始頁中，可通過"ErrorMessages"標籤到達相應的"ErrorMessages"頁(圖46中所示)。已針對特定服務而定義的錯誤消息自動顯示在表"Associatedusererrormessages"中。圖46的用戶界面示出了在任何消息與典型(業務)服務"oWres^/;^Z77a《eZht相關聯之前的頁。與業務服務相關聯的消息有兩種5W6co/^o加/71-^eci/7c消息和Common消息。Subcomponent-specific消息可通過點擊按鈕"GAC消息..."而與服務相關聯，其中〈GAC〉是定義了服務的軟體子組件ID。同樣，Common消息可通過點擊按鈕"Commonmessages..."而與服務相關聯。點擊這兩個按鈕中任一個都會導致圖47所示的對話框用戶界面。對話框用戶界面左手側的表示出了與子組件相關聯的所有可能的消息(或在"Commonmessages"場景中為Common消息)。選擇表中的行會在該對話框的右手側上顯示消息概要。用戶界面可能不顯示消息，而是顯示空表，其指示沒有針對該子組件定義錯誤消息。當打開對話框時，檢査與服務相關聯的消息。為了指明消息應當與服務相關聯，必須對消息的複選框(checkbox)做出標記。為了指明消息應當不與服務相關聯，必須清除消息的複選框。最後，為了做出關聯，必須點擊"Associatemessages"按鈕。圖48示出了添加Subcomponent-specifie消息和Common消息後的原始編輯器屏幕。圖48所示的用戶界面提供以指示"MessageSeverity"。對於每一個消息，可以選擇如下選項之一"Warning","Exc印tion，，或"Severe，'。如上面在映射的上下文中所述，服務可以調用附加服務。這些調用在服務編輯器的"Ma卯ings"標籤中定義。在創建服務映射後，可以重新打開待調用的服務。在標籤"Mapping"中，列出了被調用的服務的所有錯誤消息。建模工具提供了把這些"子輩"錯誤消息映射為屬於作業中的服務的任何現有錯誤消息的可能，如圖49所示。在這個上下文中，首先可以選擇一個或更多個子輩消息，然後選擇選項"Mapto..."，並從列表中選出一個錯誤消息，如圖50中所示。子輩消息將被映射到所選消息。在這個動作之後，相應的信息將會顯示在列"Mappedto"中，如圖51所示。在標籤"ErrorMessages"上，對子輩消息進行映射的所有消息被標有選中標記(見圖52〉。另外，提供了一種用於消除映射的機制。最為示例，當產生Cobol服務代碼時，對於每一個錯誤消息，可以把如下注釋寫入來源-*:相應的輸出代碼看起來如下formulaseeoriginaldocumentpage30一旦為特定服務指定了錯誤消息，則完成從頂向下建模，而且該服務模型可以轉移到用於產生所需工件的生成器。作為上文討論的從頂向下建模方法的替代，可以使用從底向上建模(見圖5和10)。這種建模類型使用先前定義的一些工件，以確保倉庫元信息的自動填寫(fill-out)。該自動流程被稱作嚮導。針對本實施例的建模工具定義了如下嚮導。嚮導名稱描述創建呈現服務從業務組件開始創建呈現服務創建實體服務導入資料庫表並創建實體服務創建基於DTD的服務導入DTD創建基於習字本的服務導入Cobol習字本現在從使用應用組件創建呈現服務開始，分別描述上表中所示的4個嚮導中每一個的操作。為了根據後端應用(業務應用或技術應用)而創建呈現服務，首先必須創建呈現組件。建模工具可以從現有應用服務中創建呈現服務(例如WPS)。在這個上下文中，首先必須選擇應用服務。一旦已經選擇應用服務，必須選擇容器，即針對呈現服務的軟體子組件。圖53的用戶界面示出了建模工具關於此而提供的搜索功能。由於這裡僅允許業務應用和技術應用，所以這些種類的軟體組件自動地進行設置。圖53的用戶界面允許搜索期望的軟體組件。通過點擊'0K'，可以選擇軟體組件，並將其分配作為呈現服務的容器。接下來，需要通過圖54的用戶界面選擇呈現服務類型。預設的呈現服務類型是"Simple"。可以額外輸入呈現服務的版本。在"Simple(Get，OpenorDelete)"呈現服務("simple",例如關於相應的資料庫操作)的情況下，將顯示圖55所示的確認對話框用戶界面。在更為複雜的呈現服務(例如"Modify"呈現服務)的情況下，將需要啟動額外的步驟，這裡不做詳細討論。點擊"Finish"按鈕開始創建所請求的呈現服務。由此，針對建模工具的倉庫資料庫中的呈現服務而創建元素(對象)，而且呈現服務出現在軟體組件資源管理器中的所選應用和軟體子組件之下，如圖56中所示。在圖56中，數字(1)表示遵循簡單呈現服務指令而創建的呈現服務，而(2)表示遵循"modify"呈現服務指令而創建的呈現服務。如上所述，對於從底至下建模，定義了其他嚮導以導入資料庫表並創建實體服務。例如，基於DB2表定義，可以產生所謂的DCLGEN文件，其包含表的描述以及至Cobol習字本的映射。這個文件可以用於導入建模工具中的表定義。DB2表在建模工具中表示為複合類型。從DCLGEN文件中創建該複合類型開始於圖57所示的表選擇對話框。DCLGen文件的目錄應當已經包含正確的路徑，例如輸入DCLGEN文件名樣式(pattern)將會刷新可用表的列表。選擇一個或更多個表並點擊"Import"按鈕將開始創建針對每一個DCLGEN文件的新的複合類型。在下一步中，可以選擇一個或更多個已創建的複合類型，從而創建實體服務(見圖lla)。可通過圖58所示的用戶界面來定義針對所選複合類型的實體服務。存在如下選項-實體服務類型(Read、Search等)實體服務的類型-讀("Get")對象*搜索("GetList")對象插入("Open")新對象更新("Modify"現有對象)刪除("Close")現有對象ServiceName實體服務的邏輯名稱ServiceVersion服務版本ModuleName可選的模塊名稱ItemName僅當選擇"Search"作為服務類型時才可用。定義了用於結果列表的名稱。例如，Item-"Partner"導致圖59所示的服務結果列表的複合類型FieldsforWhere-Clause所產生的實體服務的輸入複合類型。圖60示出了該示例的配置。FieldsinOutput所產生的實體服務的輸出複合類型。圖61示出了該示例的配置。在提供必需的數據後，軟體組件釋放，並通過圖62所示的用戶界面來選擇其中將要創建實體服務的子組件。可通過使用"Search"按鈕來打開該釋放(如果其沒有被打開)。點擊"Create"將會在所選的軟體子組件中創建實體服務，如圖63所示。如果新創建的實體服務已打開且顯示"M鄰ping"頁，則定義兩個映射，如圖64和65所示。在下文中，將參考現有DTD的導入而說明自底向下建模的另一個示例。為創建新的流程服務，首先必須在建模工具的軟體組件資源管理器中打開軟體組件釋放。然後，選擇應提供待創建服務的軟體子組件(服務提供者)。圖66所示的用戶界面允許選擇包含現有DTD的一個或更多個輸入文件。在已經執行選擇後，點擊"Next"按鈕將啟動解析或所選DTD。然後，通過圖67所示的用戶界面來顯示將被創建的複合類型。導入機制對所有等同的複合類型進行融合(me:rge)。點擊"Finish"按鈕啟動該導入流程。在完成導入後，服務在軟體組件資源管理器中顯示，如圖68所示。現在，參考現有習字本文件的導入來說明自底向下建模的其他示例。為創建新的流程服務，必須在軟體組件資源管理器中打開軟體組件釋放。然後，需要選擇應提供待創建服務的軟體子組件(服務提供者)。可通過圖69所示的用戶界面來執行Cobol習字本文件的導入。這個用戶界面提供了如下選項。tableseeoriginaldocumentpage33ServicePublicity服務的公開度InputCopyBook針對輸入的習字本結構；見下OutputCopyBook針對輸出的習字本結構IndicatorFlags忽視所選習字本中找到的指示符標誌對於輸入和輸出習字本文件，必須通過圖70的用戶界面來選擇文件(擴展名為".cpy"或".cob")。在設置所有欄位後，"ImportDefinition"看起來可能如圖71所示。利用"OK"關閉這個對話框，這個特定導入將顯示為習字本導入對話框中的一行(見圖72)。如圖73所示，接下來的任務是向習字本中每個欄位分配數據項(預設地，所有數據項被分配給"GenericDataItem"、如果將把一個或更多個欄位分配給現有數據項，則可以通過"Linkselecteditem(s)toexistingDataItems..."按鈕啟動相應的步驟，這會引出數據項選擇對話框。如果針對一個或更多個欄位創建新的數據項，這可以通過圖73的用戶界面的相應按鈕而開始。在完成這些分配後，點擊"Finish"完成操作，而且還完成了服務模型的自底向上的產生。不考慮其創建(自頂向下或自底向上)，服務模型及其單獨的模型參數將至少暫時存儲在圖3中所示系統的倉庫資料庫302中。如果需要特定的工件，則生成器304可以在任意時刻從倉庫資料庫302中獲取服務模型。然後，生成器選擇與基礎服務類型和所請求的工件類型(例如Java代碼)相關聯的一個或更多個模板文件306，並在所選模板文件306的控制下將服務模型轉換為工件。因此，同一個模型可以形成產生不同類型工件的基礎，包括代碼、測試案例、以及例如服務的物理描述的規範。對於這些類型的工件中的每一種，提供了一個或更多個專用的模板文件306。在一些情況下，所產生的工件可以是構造(construct)(框架)，其通過在該構造的受保護區中輸入代碼(例如特定的應用邏輯)而手動地完成。該建模方法所具有的優點是，該服務模型與應用邏輯無關,這極大地便利了服務模型及其模型元素的重新使用。此外，應用邏輯的修改不需要改變基礎服務模型。從上文中明顯看出，中央倉庫資料庫的提供允許有指導地並高度結構化地創建服務模型。可確保的是，先前定義的模型元素，例如複合類型和數據項，可以在軟體開發者和軟體開發項目之間共享。這種共享增加了可用模型元素的重新使用，因而減小了建模過程的冗餘。應當注意的是，在較大的軟體開發環境中，中央倉庫資料庫可能包括多於5000個服務，多於25000個複合類型，以及多於5000個數據項。從這些數字中可以看出中央倉庫的優點。在倉庫中對服務模型和模型元素進行管理比管理相應的物理工件要容易得多(而且消耗更少的資源)。為此，倉庫中每一個元素(服務、複合類型、數據項)可以和唯一的標識符相關聯。該標識符便於改變管理，並允許(自動)改變修改。每一個倉庫元素可以額外地和(重新使用)使用指示符相關聯。這個指示符可以用於倉庫管理，例如對於在特定時段內沒有使用的元素進行刪除和/或歸檔。此外，可以定義授權簡檔，其指示單獨的軟體開發者的(重新使用)使用權。這裡描述的再生軟體開發方法利用高度結構化的倉庫資料庫以助於創建服務模型，其表示用於實現SOA的有利的模型驅動方法，即通過單獨的可執行服務、而不是通過例如面向對象(00)的方法中的對象來進行通信的體系結構。本領域的技術人員可以理解，上述方法和設備可以以各種方式進行調整或擴展。雖然上文描述參考了優選實施例，然而本發明的範圍僅由所附權利要求以及這裡引述的要素來限定。權利要求1.一種模板驅動系統(100)，用於根據平臺無關服務模型而產生平臺特定工件，例如程序代碼，所述系統包括-模板存儲器(102)，具有平臺特定模板，每一個模板包括平臺特定模型轉換信息；-倉庫(104)，具有i.多個至少本質上為平臺無關的服務模型元素，以及ii.根據所述模型元素而建模的一個或更多個服務模型；以及-生成器(106)，適於通過把所述模板中包括的轉換信息應用於所述服務模型而生成平臺特定工件。2.根據權利要求1所述的系統，其中，所述服務模型元素中至少一些由兩個或更多個服務模型共3.根據權利要求1或2所述的系統，還包括服務模型創建器，用於根據所述服務模型元素而創建服務模型元素和平臺無關服務模型中的至少一項。4.根據權利要求1至3中任意一項所述的系統，其中，所述倉庫中包括的服務模型元素具有分層結構。5.根據權利要求4所述的系統，其中，根據較高層級的一個或更多個第一模型元素以及較低層級的一個或更多個第二模型元素，建模每一個服務。6.根據權利要求5所述的系統，其中，在所述服務模型中，每一個第一模型元素與一個或更多個第二模型元素相關聯，所述一個或更多個第二模型元素構成了第一模型元素的屬性。7.根據權利要求5或6所述的系統，其中，第一模型元素定義了一個或更多個服務輸入參數以及一個或更多個服務輸出參數中的至少一項。8.根據權利要求5至7中任意一項所述的系統，其中，第二模型元素構成服務輸入參數樹和服務輸出參數樹中的至少一項中的葉欄位。9.根據權利要求1至8中任意一項所述的系統，其中，所述倉庫中的服務模型與兩個或更多個模型元素之間或模型元素與資料庫表之間的映射相關聯。10.根據權利要求9所述的系統，其中，所述映射定義了屬於相同層級的模型元素之間的轉移操作。11.根據權利要求9或10所述的系統，其中，所述映射定義了一個或更多個服務輸入參數與一個或更多個服務輸出參數之間的轉移操作。12.根據權利要求ll所述的系統，其中，輸入參數和輸出參數屬於不同的服務。13.根據權利要求1至12中任意一項所述的系統，其中，預定義的服務類型可被選擇用於服務建模。14.根據權利要求13所述的系統，其中，所述服務類型包括以下一種或多種流程服務、實體服務、呈現服務、技術服務、批作業和査看。15.根據權利要求13或14所述的系統，其中，所述模板存儲器包括針對每一個服務類型的至少一個專用模板。16.根據權利要求1至15中任意一項所述的系統，其中，存在多個預定義的平臺類型。17.根據權利要求16所述的系統，其中，所述模板存儲器包括針對每一個平臺類型的至少一個專用模板。18.根據權利要求16所述的系統，其中，所述模板存儲器包括針對服務類型和平臺類型的各種組合的至少一個專用模板。19.根據權利要求3至18中任意一項所述的系統，其中，所述模板創建器允許選擇服務類型和服務公開度中的至少一項。20.根據權利要求1至19中任意一項所述的系統，其中，所述生成器允許選擇平臺類型。21.根據權利要求5至20中任意一項所述的系統，其中，定義特定種類的第一模型元素，並可通過用於服務建模的服務模型創建器來選擇。22.根據權利要求1至21中任意一項所述的系統，其中，所產生的工件包括以下至少一項Java代碼、Cobol代碼、H頂L代碼和XML代碼。23.—種倉庫資料庫(302)，包括至少本質上為平臺無關的模型元素以及根據所述模型元素而建模的服務模型，所述服務模型形成了用於在平臺特定模板的控制下生成平臺特定工件的基礎，每一個模板包括平臺特定模型轉換信息。24.—種方法，用於根據平臺無關服務模型而產生平臺特定工件，例如程序代碼，所述方法包括-提供平臺特定模板，每一個模板包括平臺特定模型轉換信息；-提供i.多個至少本質上為平臺無關的服務模型元素，以及ii.根據所述模型元素而建模的一個或更多個服務模型；以及-通過把所述模板中包括的轉換信息應用於所述服務模型而生成平臺特定工件。25.—種包括程序代碼部分的電腦程式產品，當所述電腦程式產品在一個或更多個計算設備上運行時，所述程序代碼部分用於執行權利要求24所述的步驟。26.根據權利要求25所述的電腦程式產品，其存儲在計算機可讀記錄介質上。全文摘要描述了一種模板驅動系統，用於根據平臺無關服務模型而產生平臺特定工件，例如程序代碼。所述系統包括模板存儲器(102)，具有平臺特定模板，每一個模板包括平臺特定模型轉換信息；倉庫(104)，具有多個至少本質上為平臺無關的服務模型元素，以及根據所述模型元素而建模的一個或更多個服務模型；以及生成器(106)，適於通過把所述模板中包括的轉換信息應用於所述服務模型而生成平臺特定工件。文檔編號G06F9/44GK101164044SQ200680013571公開日2008年4月16日申請日期2006年4月21日優先權日2005年4月22日發明者漢斯貝亞特·洛卡,阿涅洛·博韋申請人:瑞士銀行股份有限公司