專利名稱：：與對象建模形式體系兼容的數據處理方法
技術領域：
：本發明涉及一種提供新的Web(網絡)服務的方法，一種適合于實現該方法的計算機程序產品(特別是使用場合輔助程序(usecaseassistant))，以及一種通過該方法得到的計算機文件。
背景技術：
：在下文中，除非以其他方式指明，否則就按以下所指明的意思使用以下術語-“電子數據處理應用程序”適合于聯合運行的任意程序或任意一組程序，其目的是向其用戶呈遞服務。-“類”類的概念通常應用于建模形式體系和面向對象的編程語言并且特別是適合于在電子數據處理應用程序中共同工作的數據和處理的集合(分別是屬性和方法)。在面向對象的語言中，每種類型的對象由其類定義。一個類表示共享相同屬性、操作、方法、關系和語義的所有對象。-“行”向目標程序，例如向編譯器提供特定信息的符號語言的一個表達或一系列表達。-“容器”在面向對象的編程中，包括諸如目錄之類的其他對象并提供用于訪問該其內容的操作的對象。它還可以是包括其他組件的組件。-“源代碼”用編程語言或描述語言編寫的文本，該文本隨后被編譯為機器語言以便由硬件電子數據處理平臺執行或者由軟件環境或解譯硬件來解譯。-“代碼”該術語可互換地意指源代碼和編譯代碼。-“編譯”在由電子數據處理硬件平臺執行用編程語言表達的描述之前，將該描述轉換為該電子數據處理硬件平臺的本機語言的動作。-“聲明性的”未將數據與指明的或必需的使用該數據的順序相結合。如果指明了該順序，則這種表示就不再是聲明性的而是過程性的(procedural)。在語言可以具有聲明部分和過程部分的意義下，這兩個概念一般會重疊。-“DTD”文檔類型定義，指定文檔邏輯結構模型，用于固定(fix)構成文檔的單元以及連接這些單元的鏈接的性質。也可以使用術語“方案”。-“代碼生成”通過生成器對用于電子數據處理應用程序的源代碼的自動或半自動產生，從提供給生成器并控制生成處理的軟件應用程序的抽象描述中得到。在分析該描述之后，該處理構造期望的輸出代碼。該描述通常用比待產生的代碼中所用的語言更高級的語言表達。因此，通常選擇與自然人類語言盡可能接近的圖形形式或文本形式的語言。因此，可以在不需要獲知所生成的代碼中使用的編程語言的形式體系的情況下使用生成器。-“繼承”鏈接兩個類的關系，其中“基類”從“母類”繼承特性(屬性和方法)，使得基類能夠利用母類的定義來豐富其自身的定義，同時保持所有其原始的特征。繼承是豐富(將所繼承的類的特性添加到繼承類)而不是耗盡(并非母類的所有特性都可以被繼承)。-“HUTN”人類可用的文本的通知，意指用于利用設計為對用戶來說通用的、可自動化的且可理解的人類可讀句法(syntax)來創建并修改文本格式模型的OMG(對象管理組)標準。HUTN被認為比XMI“更簡單”且顯然更具有可讀性，原因是HUTN是面向“用戶”的，與諸如Java、C++之類的本領域中已知的語言類似。-“實例”一次出現、一個例子、一種類型或一個類的一個單獨成員。通常用同義詞“對象”和“實例”來指代類的成員。-“編程語言”用于描述將由計算機執行的動作的形式體系。在編譯或解譯之后，這些描述由計算機執行。使用一種或多種編程語言來描述電子數據處理應用程序。術語“語言”是指用于描述某些軟件或所有軟件以便直接地或間接地促成其實際構造的所有表示格式。-“元語言”一種語言，對于其主題采用另一種語言并使該另一種語言正式化。-“元建模”使用另一種建模語言(元語言)對一種建模語言的說明，元模型是表示語言句法的模型。術語“建模”是指語句、問題或系統的抽象表示，一方面為便于理解以及傳達該理解而執行，另一方面為解決該問題或者系統的具體實現而執行。-“模型驅動體系結構”(MDA)一組OMG規范，其涉及采用一系列模型的開發過程，該開發過程整合了項目的多個維度并從功能模型延伸到源代碼模型。這些模型基于UML標準。從一個模型到另一個模型的遞進(progress)包括對應用程序的說明的逐步豐富，以及使用由UML元模型認可的變換。-“面向對象的建模”一種特定類型的建模，其中建模單元是類、對象、屬性、方法、關聯(association)等，與“功能建模”相對，在功能建模中，建模單元是處理功能和數據流。也可參見“UML”。-“MOF”元對象工具，由OMG提出并被用于規定UML和其他建模語言的句法的元建模語言。-“OMG”對象管理組，一個組織，其目標包括定義標準以確保使用面向對象的語言編程的應用程序的相互兼容(參見http//www.omg.org)。-“對象”在建模或面向對象的編程中，包括一組數據(類的內在定義數據)和用于操縱這些數據的過程的類實例。-“面向對象”是指例如其組件部分是類或對象的模型、語言、應用程序或應用程序單元。例如，面向對象的語言是一種編程語言，其中基本組件是類，類的實例，即對象動態地位于使用類的電子數據處理程序中。-“封裝”首先是分組在一起以便再使用或改善模型的組織的一組建模單元(類或其他封裝)。一旦已經將模型以編程語言進行了編碼，則封裝就指定包含類或其他封裝的計算機的目錄(文件)。-“面向對象的編程”一種特定類型的編程，其使用面向對象的語言(例如Java、C++、C#或Eiffel)來操縱類和對象，與非面向對象的編程或“標準”編程相對，非面向對象的編程或“標準”編程只操縱簡單的數據結構和單獨的處理“功能”(例如使用C、COBOL、FORTRAN的編程)。-“Web服務”可在因特網上經由標準接口訪問的應用程序，該應用程序可以使用通信協議，例如基于XML，獨立于所使用的操作系統和編程語言動態地與其他應用程序進行交互。-“SGML”用于描述電子數據處理文檔的內容與其結構之間的關系的標準語言。-“定型”(Stereotype)一種類型的建模單元，其擴展了元模型的語義。定型必須基于存在于元模型中的某些類型或類。定型能夠擴展語義，而不是預先存在的類和類型的結構。UML中預先定義了一些定型，其他的可以由用戶定義。定型連同“標記值”(taggedvalue)和“注釋”一起構成用于擴展UML的三種機制之一。-“UML”統一建模語言，一種使用對象的建模表示法(而不是建模語言)，使得能夠在目標系統的開發期間確定和呈現目標系統的組件，以及在適當的時候生成系統文檔。UML當前是OMG標準。UML是通過JimRumbaugh、GradyBooch和IvarJacobson共同工作得到的，并且以各種方式演進。-“XMI”XML模型互換，用于規定元模型與“方案”之間的對應關系的規則。XMI是萬維網聯盟(W3C)的將模型領域與XML領域相聯系的OMG標準。XMI用于以XML文件的形式表示UML模型。-“XML”SGML的一種演進，其特別地使得HTML文檔的設計者能夠定義其自己的標志，目的是對數據結構進行個性化。對象建模是本領域中已知的并且包括獨立于任意編程語言、通過類和對象來創建真實世界的單元的表示。例如，確定對象的類，分離它們的內部數據和使用它們的功能。有不同的形式體系。UML是這些形式體系中的一個(并且實際上更像一類表示法)。UML表示法是在20世紀90年代成為OMG標準的。面向對象語言均構成實現類概念的特定方式。特別地，對象形式體系用于以“高級抽象”來定義問題，而不需要進入給定語言的細節。UML形式體系提供了一種用于以圖形形式容易地表示問題的工具，使得可以更容易訪問其解決方案中的各參與者。從這一方面講，希望盡可能嚴格地定義對象形式體系并且應當優選地對其進行唯一定義，以便使模糊度最小化。為解決給定問題，第一步通常是得到對象模型的抽象概念。然后，使用面向對象語言(諸如C#或Java)來實現該模型。本領域中還已知Web服務(WS)，其可以從任意因特網終端訪問，并且越來越多地用于生成簡單且可再使用的應用程序。從其復雜性的角度來說，可以將這些WS分為兩類基本WS和復合WS。基本WS提供與出現在數學庫中的服務相當的基本服務，并且包含低級的數據轉換，包括少量算法。例如，通常將轉換服務視為基本WS。另一方面，通過多個基本服務的協作，復合WS能夠提供高級服務并且具有多個訪問和數據轉換級別。復合服務有時稱為“配合服務”(或“交互處理”)，意指所需的所涉及基本服務的配合。預留服務和安全支付服務是配合復合WS的例子。盡管在諸如Apache/Axis或.NET平臺之類的本領域中已知的標準環境中可以相對容易地建立和部署基本服務，但有益的是具有能夠實現由對現有服務的配合集合得到的復合WS的產生和部署的適當的環境。然而，由于將繼承服務進行了集合和配合，繼承服務的交互，以及應當執行繼承服務的方式以達到其目標并在確保與終端服務的功能一致性的情況下提供該終端服務，這種環境會引發問題。從這一方面講，目前存在多種集合技術。盡管在業界仍然沒有關于公共語言的一致意見，但有兩種被認為是互補的語言-WSBPEL(Web服務業務流程執行語言)或BPEL，其描述了WS之間的交互，包括這些交互的應用程序邏輯和順序；以及-WS-CDL(Web服務編排描述語言)，其描述了在WS之間交換的消息，包括關于這些交換的順序和約束。然而，使用BPEL并不是描述應用程序邏輯的唯一方式，還可以使用Java或C#。因此，需要一種產生新的Web服務的方法，該方法確保服務的功能結合并且不會施加與最終的實現語言相聯系的約束。
發明內容為此，本發明提出一種產生新的Web服務的方法，包括步驟將文本描述分解為基于對象建模形式體系的新的Web服務的建模單元；根據建模單元創建內部對象模型；以及將內部對象模型的建模單元轉換為外部元模型的建模單元。本發明方法的優選實施例包括以下特征中的一個或多個特征-在分解步驟中，文本描述包括場景和/或使用場合；-分解步驟包括對數據的語法和/或語義的分析；-分解步驟還包括在使用場合中識別對新的Web服務的一般描述；以及可能將由該服務使用的現有Web服務；-分解步驟還包括從使用場合識別新服務中所涉及的參與者；以及從新的Web服務的一般描述中提取新服務的輸入-輸出；-分解步驟還包括重新組織場景的短語；-分解步驟還包括根據重新組織的場景短語來產生邏輯短語；-外部元模型是XMI模型，并且變換步驟是經由XMI生成器創建XMI模型的步驟；-該方法在創建XMI模型的步驟之后包括根據所創建的XMI模型創建UML模型的步驟；-該方法在轉換步驟期間或之后包括生成代碼的步驟；-創建內部對象模型的步驟包括穩定內部對象模型的數據結構的步驟，并且數據結構包括多個子句，將這些子句中的每個子句與形式體系的一個或多個建模單元相關聯，并且這些子句中的每個子句是完全聲明性的；-每個所述子句與一個單獨的建模單元有關；-每個所述子句包括與其所關聯的建模單元有關的代碼以及與該建模單元有關的特征；-一些所述子句包括與其所關聯的建模單元的容器有關的特征；-對象建模的形式體系是UML形式體系；-形式體系的建模單元中的一個建模單元是封裝、使用場合、類、屬性、關聯或繼承。本發明還涉及一種適合于實現本發明方法的計算機程序產品。本發明還涉及一種通過本發明方法得到的電子數據處理文件。通過閱讀以下對僅通過示例給出的本發明實施例的詳細描述并參考示例和附圖，本發明的其他特征和優點將變得明顯，其中圖1是本發明方法的一個實施例的特定步驟的示圖。具體實施例方式本發明提出了一種產生新的Web服務的方法，一種適合于實現該方法的計算機程序產品，以及一種通過該方法得到的電子數據處理文件。本發明的方法包括第一步驟，即將文本描述(通常是場景和使用場合)分解為對象建模形式體系的建模單元，該對象建模形式體系例如UML形式體系。場景和使用場合就現有服務的操作之間的交互而描述了未來的“交互處理”的詳細工作方式。使用場合類似于一般描述，而場景與對特定場合的詳細的、功能性的描述有關，這是本領域中已知的。如有必要，該方法可以使用多個場景文本。可以在該第一步驟期間或之前以半正式文本的形式表達場景和使用場合。該步驟優選地采用語法和/或語義分析。如有必要，則在該第一步驟期間，識別對新的Web服務以及可能將由該新服務使用的現有Web服務的生成描述。該方法還包括一個步驟，即從建模單元創建內部對象模型(MOI)。該MOI用于進行存儲(stacking)，并且優選地是屏蔽的，即對于用戶是透明的。之后是將內部對象模型的建模單元轉換為外部元模型的建模單元的步驟。例如，該操作可以伴隨產生采用任意對象語言(Java、C++、C#、Ada等)的代碼的步驟或創建XMI模型的步驟。采用MOI確保了未來服務即事務處理的功能一致性，并保證了從一個模型到另一模型的轉換運行良好。為此，服務構造機制優選地基于MDA方法。注意，所選的方法是不可知的(因為建模單元在對象意義上的使用)。此外，包含在數據中的描述(使用場合/場景)是功能性的。因此，該方法不會引起與最終的實現語言相聯系的任何約束。如果需要容易地既產生例如基于UML的對象模型又產生采用任意對象語言的源程序，則采用MOI也可證明是有利的。然后，MOI用作使用多種語言的對話者。從這一方面講，特別有利的是MOI基于特別適合于表示UML模型或特別適合于容易地生成源程序的特定數據結構。一旦產生，這些源程序就可以被部署。這樣就得到一種環境，在該環境中可以容易地部署最終復合的服務，以使得該服務對終端用戶可用。下文中將通過本說明書第一部分中的示例來對本發明方法的優選實施例進行說明。在本說明書的該第一部分中，重點在描述分解數據的步驟和創建MOI的步驟上。然后，在本說明書的第二部分中，更詳細地描述了特別有利于MOI的數據結構。該數據結構基于在下文中稱為“FIL”表示法(FIL意指“格式互換語言”或“格式內部建模語言”)的表示法。本說明書的第三部分針對源代碼的產生并針對服務的部署。I.借助于通過使用場合輔助程序而實現的本發明方法的示例進行描述接下來將聯系簡單的事務處理示例來描述上述一般概念。假定Web服務庫包括多個基本服務-消息傳輸服務，用于向給定接收方發送SMS消息、傳真或電子郵件；-目錄服務，即用于獲得特定于給定用戶的數據(例如其電子郵件地址或其聯系人列表)的一般服務；以及-用戶選項服務，其管理與每個用戶相關聯的選項。I.0對新服備的描述參考圖1，采用上述基本組件，現在假定需要建立新的服務，第一參與者(分析者)通過以下使用場合50不嚴密地描述到使用場合新服務的名稱是廣播消息。采用該新服務，用戶希望根據其消息傳送選項向多個接收者廣播消息。該新服務使用某些現有服務，但在這一級別上，我(分析者)忽略了這些現有服務的準確名稱……。場景(對新服務的描述)用戶給出他的名字，并且該新服務得到該用戶的相應的聯系人列表。然后，對于該列表上的每個聯系人，該新服務得到對應于該聯系人的消包傳送類型，并且根據該類型，該新服務向該聯系人發送SMS、傳真或電子郵件。適合于實現根據本發明的方法的使用場合輔助程序實現了將以上數據分解(100)為基于例如UML之類的對象建模形式體系的新的Web服務的建模單元。這種分解(100)優選地包括多個轉換，在下文中將對其進行描述。根據以上不太嚴密的描述，使用場合輔助程序執行一系列逐步的轉換，直至其得到(120、140)諸如XMI之類的外部元模型(70)的單元或對應于新服務的可編譯的、可執行的且準備好進行部署的源代碼(80)。I.1對應于新服務的文本到半正式模型的第一轉換可能將由輔助程序實現的第一轉換包括對文本的重新布置，以便賦予該文本可以由計算機“處理”的形式(在本領域中將其稱為“機器可用的”形式)。這種轉換可以包括兩個子步驟重組(refbrmulation)的第一子步驟以及在半正式模型中進行填充的第二子步驟。對文本進行重組的第一子步驟包括對文本的語法分析。這種分析由例如能夠實現短語重構的輔助程序的適當的語法分析模塊來實現。從這一方面講，注意到在本領域中已知有用于實現文本的語法分析的工具，例如Grammatica，其是用于采用法語或英語的文本的語法和拼寫檢查器。除建議之外，Grammatica還提供解釋。Grammatica分析單詞的功能(文本和語法聯系，同音字和同形異義字，同義字和在法語中的定義)。參見站點www.zdnet.fr。另一個示例是來自Lexiquest的工具，其執行文本分析和文本挖掘www.lexiquest.com。輔助程序的語法分析模塊通常能夠-清楚地分辨數據的“使用場合”部分與“場景”部分；-在“使用場合”部分中識別以下子部分○新服務的名稱；○對該新服務的一般描述；以及○對可能將用于設計該新服務的現有服務的識別；以及-在“場景”部分中○將文本分解為單獨的短語；○識別這些短語，以便為其賦予短語的第一編程指令輪。在上述操作之后，得到一個結果，例如使用場合新服務的名稱廣播消息。一般描述[采用該新服務，]用戶希望根據其消息選項向多個接收者廣播消息。所使用的現有服務新服務使用某些現有服務，但[在這一級別上，我(分析者)忽略了這些現有服務的準確名稱……。]＝在該步驟中，這些現有服務還是未知的。場景詳細描述-用戶給出他的名字；-該新服務得到該用戶的聯系人列表；-對于該列表上的每個聯系人о該新服務得到對應于該聯系人的消息類型；о根據該消息類型·該新服務發送SMS；或·該新服務發送傳真；或·該新服務向該聯系人發送電子郵件。第二子步驟必須有對文本中的有關信息的詳細提取，以便在半正式模型中進行填充，然后將該半正式模型用于生成屬于新服務的源代碼。采用適當的語法提取器，實現以下操作。-在“使用場合”部分中○識別新服務的名稱；○識別參與者初始參與者和最后的參與者(如果合適的話，則有多個)；○提取對該新服務的一般描述(如果可能的話)；*○提取通常以“用戶將……給服務”、“服務向用戶返回……”等表示的服務的主要輸入-輸出。-在“場景”部分中○根據單獨的短語，生成將要變為指令的“邏輯短語”，即獨立短語或短語的一部分；○識別必要的編程單元(例如“if...then...else”、“switch...case”、“foreach...”等)。將這些操作的結果存儲于半正式模型的相應字段中，例如，如下所示。用于消息業務處理的使用場合參與者參與者是用戶(消息廣播者)和接收者。使用場合影響參與者的使用場合用戶(消息廣播者)使用場合名稱廣播消息服務名稱消息業務處理描述用戶希望根據其消息選項向多個接收者廣播消息。輸入用戶將以下數據給服務-他的發送者名稱；-消息。輸出服務向用戶返回-無特定數據。異常現在沒有異常。所使用的現有服務新服務使用某些現有服務，但在該步驟中，這些現有服務還是未知的。場景用于新服務的場景廣播消息*該新服務根據該用戶的名字得到發送者的聯系人列表*對于該列表的每個聯系人*得到對應于該聯系人的消息類型*根據該消息類型*如果是SMS*向該聯系人發送SMS*如果是傳真*向該聯系人發送傳真*如果是電子郵件*向該聯系人發送電子郵件這種半正式描述特別地具有兩個優點用戶可以讀取該描述并且在該階段由計算機來處理該描述是實際可行的。在該階段可以添加三類單元以使得計算機能夠使用該描述-將使用的現有服務的名稱或標識符；-可能將由這些服務使用的方法的名稱或識別標志(對象意義上的)；-這些方法所使用的參數的名稱和類型。在該實施例和本例中，在下文中描述的第二轉換期間添加這些單元。然而，可以考慮多種實施例，其中可以默認地或直接由用戶本身指定這些單元(用戶本身直接指定這些單元的情形將構成非自動的操作模式)。I.2正式模型的確定第一轉換采用了語法分析。接下來將描述的內容更多地基于語義分析。為了能夠描述XMI類型的服務，在服務庫中使用例如本領域中已知的WSDL(關于該主題，參見www.w3.org并且特別是www.w3.org/TR/wsdl)描述了現有的(繼承)服務。基于給定Web服務的WSDL描述，使用場合輔助程序的專用模塊優選地執行以下操作-其查看場景的偽指令(即半正式指令)；-其從這些指令中提取“服務條件”，即關于必須適合于現有服務的服務的要求；-其將這些條件與服務方法的識別標志和參數(假定它們是用WSDL描述的)相比較；-如果在原始要求與屬于繼承Web服務的方法的識別標志之間找到令人滿意的匹配，則其用服務方法的“真實”識別標志來代替條件。如有必要，則該轉換模塊可以附加地完成該半正式模型的“所使用的現有服務”信息。使用場合……所使用的現有服務新服務使用以下現有服務*目錄服務；*消息傳送服務*用戶選項服務。場景用于新服務的場景廣播消息*利用參數“發送者名稱”，該新服務通過調用目錄服務的GetEmailAddress(得到電子郵件地址)操作來得到發送者的電子郵件地址。*利用參數“發送者名稱”，該新服務通過調用目錄服務的GetMyContactList(得到我的聯系人列表)操作來得到發送者的聯系人列表。*對于發送者的聯系人列表的每個單元，新服務工作如下*利用參數“聯系人名稱”，該新服務通過調用用戶選項服務的GetMessagePreference(得到消息選項)操作來得到消息類型，*根據該消息類型*如果是SMS*利用參數“聯系人移動電話號碼”和“消息”，調用消息服務的SendSMS(發送SMS)操作*如果是傳真*利用參數“聯系人傳真號碼”和“消息”，調用消息服務的SendFax(發送傳真)操作*如果是電子郵件*利用參數“聯系人電子郵件地址”和“消息”，調用消息服務的SendMail(發送郵件)操作注意，SendMail、SendSMS等操作是本發明意義上的建模單元。在這些新的附加之后，如有必要，輔助程序可以測試通過將由第二轉換模塊所選擇的識別標志和參數與繼承目錄服務的原始WSDL描述相比較而得到的描述的一致性。例如，使用輔助程序的特定命令來找到并存儲場景的原始文本所需的服務描述，以便之后將它們與由第一轉換的自動模塊所選擇的WSDL描述進行比較。在該一致性測試之后，開發者可以例如校正由輔助程序實現的選擇并替代性地施加他自己對服務的選擇。I.3場景的內部對象模型的產生由輔助程序所使用的根據本發明的方法包括中心步110，即從新的Web服務的建模單元創建內部對象模型60。例如，該步可以使用“內置文本到正式語言”的轉換模式以及“WSDL到正式語言”的轉換模式。因此，這些模式的規則將會把使用場合和場景的半正式文本以及繼承WSDL服務的描述轉換為正式的MOI。例如，MOI60可以采用在本說明書的第二部分中詳細說明的特定數據結構(FIL)。如上所述，MOI特別地用于容易地生成代碼，同時確保涉及不同的轉換時的功能一致性并從而保證最終服務的一致性。在“應用”“文本到MOI”轉換(即本實施例中的“文本到FIL”的轉換)之前，優選地將基本模式用于由操作于從第二轉換得到的場景文本上的關鍵字處理，以便將可以由用戶讀取的偽指令轉換為可由計算機執行的指令。為此，可以首先去掉諸如“該”、“服務”、“調用”、“操作”、“參數”等不重要的詞語。然后，關鍵字處理模式可以例如替換預定的關鍵字(諸如“得到”、“利用”、“從”、“的”等)并將每個偽指令重新組織為最終的編程指令形式。考慮例如來自上述場景中的以下短語利用參數“發送者名稱”，該新服務通過調用目錄服務的GetEmailAddress操作來得到發送者的電子郵件地址。該短語在“開發者”的領域中具有已知的匹配。例如-通過調用由開發者編寫的操作“B”來得到數據“A”A＝B()；-將服務“S”的操作“B”寫為S.B()。因此，在開發者的領域中，上述短語就轉換為sender_email_address＝DirectoryService.GetEmailAddress(sender_name)；在由關鍵字處理模塊執行的操作之后，得到ScenarioforthenewserviceBroadcastMessagesender_contact_list＝DirectoryService.GetMyContactList(sender_name)；foreachelementofsender_contact_listmessaging_type＝UserPreferenceService.GetMessagePreference(contact.name)；switch(messaging_type)caseSMSmessagingService.SendSMS(contact.Mobile_phone_number，message)；caseFaxMessagingService.SendFax(contact.Fax_number，message)；caseEmailMessagingService.SendMail(contact.Email_address，message)；現在仍然應用“文本到MOI”的轉換模式，其代表第三級轉換(實際上，在該級別上，更多的是一種翻譯)，以FIL格式產生使用場合和場景的完整半正式文本。以這種方式(提取)，得到*正式內部對象模型語言*對于新服務廣播消息*---------------------------*封裝聲明pMessagingBusinessProcesspMessagingServicepUserPreferenceServicepDirectoryService*類聲明cMessagingService，MessagingServicecDirectoryService，DirectoryService…*聯合聲明rMessagingBusinessProcess(1..1)uses(1..1)DirectoryService(...)rDirectoryService(1..1)uses(1..n)Contactlnfo*屬性聲明aNamestring，Contactlnfo(...)atheDirectoryServiceDirectoryService，MessagingBusinessProcessatype_of_messagingString，MessagingBusinessProcess*操作聲明oGetUserProfile(userNamestring)UserProfile；UserPreferenceServiceoGetMyContactList(usemamestring)ArrayOfContactlnfo，DirectoryService*操作聲明+操作詳細描述oBroadcastMessage(Stringsender_name，Stringmessage)；MessagingBusinessProcessdisplay_message(″TheuserwantstobroadcastamessagetoseveralReceivers″)sender_contact_list＝theDitectoryService.GetMyContactList(sender_name)for(i＜sender_contact_list.Length)type_of_messaging＝theUserPreferenceService.GetMessagePreference(sender_contact_list[i].Name)switch(type_of_messaging)caseSmstheMessagingService.SendSMS(sender_contact_list[i].Mobile.message)caseFaxtheMessagingService.SendFax(sender_contact_list[i].Fax.message)caseEmaldefaulttheMessagingService.SendMail(sender_contact_list[i].EMail，message)endswitchendfor*FIL結束以“*”開頭的行是注釋。關鍵字母后接區分新服務(在可應用時涉及現有服務(在本例中是“DirectoryService”))的建模單元的冒號“”(例如關系“MessagingBusinessProcess(1..)uses(1..1)DirectoryService”)。FIL表示法反映了新服務的內部模型，新服務的內部模型以正式的方式表達并存儲于例如使用場合輔助程序的專有數據庫中。本說明書的下一部分將對該表示法進行說明。II.基于FIL表示法的內部對象模型的數據結構II.0上下文、定義通過對FIL格式的數據結構的初步詳細描述，有必要指出，當前已標準化的UML表示法不具有用于表示對象模型的文本表示法。該標準中只提出了針對各種UML圖表(類、交互、狀態-轉換等的圖表)的圖形表示但在UML標準中沒有提出該圖形表示的對應文本。XMI并非旨在“可讀”，即對于人類用戶不是可理解的。此外，XMI不是自包含的(self-contained)。HUTN句法的設計目標是可被用戶理解。HUTN仍然是面向過程的語言，即行的順序對該語言的解譯來說是非常重要的。在這種背景下，特別希望具有一種數據結構，該數據結構能夠由計算機處理，能夠用于表示UML模型，并且能夠容易地生成采用任意對象語言的源程序。同樣希望該數據結構是簡單的且便于操縱，并且一旦具體實現，就可以被用戶理解。術語“數據結構”首先是指在使用數據的程序的內部表示中所用的該數據的實際結構。然而，術語“數據結構”同樣是指文件中所存在的信息的結構，正如在編輯或打印文件時所顯示的那樣。該文件可以是例如以其第一種意義來理解的上述“數據結構”的具體實現文件。II.1FIL數據結構的一般特征該數據結構是包括多個建模單元的對象建模形式體系的表示。表述“對象建模形式體系的表示”意指該數據結構可以特別地用于提供基于該形式體系的圖形表示。可以將該形式體系的圖形表示例如限制為UML表示法，在此情況下，建模單元是UML通常使用的單元，即封裝、類、屬性、操作、關聯、基數、繼承等。所提出的數據結構包括多個子句，例如邏輯子句，該邏輯子句可以由程序來穩定或使用。這些子句中的每個子句與形式體系的一個或多個建模單元相關聯，并且這些子句中的每個子句是完全聲明性的。該數據結構是簡單的。一旦將該數據結構具體實現在例如文件中，則每個子句就使用正式表示法變為該文件的一行。現在，假定每個子句是完全聲明性的，則這些子句的順序不會影響這些子句的解譯，并且因此文件的行的順序不會影響這些行的解譯。這簡化了用戶對文件的理解。每個子句優選地只對應于一個建模單元，這既簡化了對數據結構的算法處理又簡化了用戶對由該數據結構構造的文件的理解。此外，每個子句優選地是自包含的，以使得能夠對其進行解譯而不需要為該目的而訪問某個其他的子句。數據結構用高級的正式表示法來表示。這使得能夠使用簡單的且集成的數據處理方法。例如，用于轉寫(transcribe)并表示UML模型的方法，該UML模型通常是以與非正式文本相關聯的圖表和圖形方案的形式描述的并且該UML模型的結構未標準化。還通過適當的電子數據處理將該數據結構用于容易地產生基于UML的對象模型和采用任意對象語言(Java、C++、C#、Ada等)的源程序。稍后將在本說明書中對此進行詳細描述。因此，該數據結構有利地替代了當前提出的備選方案，該備選方案基于XMI/XML或基于HUTN，沒有提供同時是簡單、便捷且能夠容易地生成代碼的工具。為便于理解，下文將參考FIL數據結構的具體實現文件來描述FIL數據結構。然而，情況仍然是，該文件的行可以對應于能夠由電子數據處理程序解譯的邏輯子句。II.2FIL數據結構的正式特征該文件的每個FIL行優選地包括與其所關聯的建模單元有關的代碼，在適當的時候包括一個單獨的字符來規定所描述的單元的類型，例如，“a”表示屬性(attibute)，“c”表示類(class)，“h”表示繼承(heritage)，“r”表示“關系”(relationship)，等等。每行還包括主體，主體包括與該單元有關的特征。這就產生了適合于電子數據處理應用程序使用該行的結構。相應代碼的存在還便于用戶對該單元的識別。通過示例考慮以下短語“貓吃老鼠”。該短語在“貓”與“老鼠”之間建立了關系。可以使用FIL表示法將該關系編碼為以下行rcat(1..1)toeat(1..n)mice其中“r”規定所討論的建模單元是關系，并且(1..1)和(1..n)是指分別對應于(一只)貓和(一些)老鼠的基數。在下文中將對其他示例進行詳細描述。某些FIL行的主體優選地包括兩個部分，第一部分包括建模單元內在的特征(例如屬性的類型值)，以及第二部分包括與建模單元的容器有關的特征。這樣就將一個單元聲明為與其容器直接聯系。然而，該聲明主要與所述建模單元有關，并且容器可以是獨立聲明的對象。因此，相應的聲明(即子句的聲明或文件行的聲明)保持獨立。此后，這就得到使得應用程序能夠重構多個單元之間的層級的文件結構。在下文中所詳述的示例與特定的實施例有關，在該實施例中，出于可讀性的原因，按照類型以例如以下指明的順序將FIL行分類封裝、類、屬性、操作、關聯、繼承。這使得了解單元及其關系更加容易。然而，應當牢記，可以對這些行進行聲明并以任意順序將其存儲于存儲器中。在行的第一附加內容中，將規定這些單元的代碼縮減為一個單獨的小寫字母。如上例中所示，冒號“”緊接在后，其后又接著一個空格。此外，逗號(如果有的話)始終后接一個空格。可以應用其他句法規則，這一點在這些示例中將變得明顯。如果合適，則可以將數據結構產生和/或電子數據處理工具集成到輔助程序中，或至少輔助程序可以包括該工具的功能。該工具可以穩定數據結構，即，將相應的值指定給該數據。該工具還可以訪問該結構，即，能夠從該結構中提取值并且/或者能夠操縱該數據結構(替換其值)。特別地，該工具解譯文件的FIL行。如有必要，可以配備用于糾正或解譯句法錯誤和疏忽的例行程序。可以以任意順序將這些行存儲于存儲器中。II.3示例示例1將屬性聲明如下a屬性名稱，類名稱其中“屬性名稱”和“類名稱”邏輯地與屬性名稱和該屬性所屬的類的名稱相聯系，逗號用作分隔符。示例2a屬性名稱類型，類名稱在本例中，用屬性的類型來聲明屬性。優選地，在“類型”之前或之后沒有空格。標準類型是本領域中通常的類型，例如“String”(串)、“boolean”(布爾)、“int”或“integer”(整數)、“Date”(日期)。可以使用其他類型，包括表示法本身中描述的類的名稱。例如a屬性名稱類1，類2示例3a屬性＝值，類名稱在此，為屬性分配初始值。優選地，在等號之前或之后沒有空格。可以注意到，該工具可以有利地解譯不完整的句法(如同在上例中那樣，其中缺少了屬性類型)。例如，在考慮多種標準的情況下，可以將該工具設計為進行解譯并設計為自動地找到適當的類型。這些標準可以基于屬性名稱本身，例如，“編號(number)”、“數量”、“米”(meter)等，然后該工具默認地提出“整數”類型。這些標準還可以基于與屬性相關聯的值。例如，如果該值是“真”或“假”，則所提出的類型為“布爾”；如果該值是數字的，則根據該值是否在小數點后包含數字，所提出的類型為“整數”或“實數”；如果該值在雙引號之間(從而為“...”)，則所提出的類型為“串”(表示“字符串”)；等等。因此，在很多情況下，由于該工具能夠確定類型，因此指出類型可能是多余的。示例4a屬性類型＝值，類名稱在本例中，句法是完整的。示例5c類名稱[，封裝名稱]在此聲明了類，以及[，類所屬的封裝]。在此，方括號表示對封裝名稱的可選引用。例如，如果沒有提到封裝并且先前沒有遇到封裝，則可以系統地將類存儲于例如“p_system”封裝之類的給定封裝中，隨后將該給定封裝視為最高級別的封裝。該封裝可以例如默認地存在并且僅當類沒有目的封裝時才使用該封裝。如有必要，如果沒有指明封裝名稱，則可以使用電子數據處理工具將類存儲于在FIL文件中遇到的最后一個封裝“p”中。注意，在此包括順序的概念只是為了彌補用戶部分造成的句法錯誤。類似地，通過調整該工具可以省略利用“c”對類進行的明確聲明，從而基于屬性、操作、關聯和繼承而自動地識別和聲明類。然而，該工具對作為輸出而生成的FIL文件使用代碼“c”。另一方面，代碼“c”可以有利地明確用于利用定型(參見下文)來聲明類或強制地使類屬于一個封裝。示例6c<<定型>>類名稱[，封裝名稱]在此，利用定型和[，類所屬封裝]對類進行了聲明。如有必要，還可以將定型與封裝、屬性、操作和關聯相關聯。示例7h類名稱1“是一個”類名稱2在這個新的示例中，使用關鍵字聲明了繼承。對繼承進行聲明所必須的所用關鍵字是“是一個”。應當注意，代碼“h”可以省略。如果不存在代碼“h”，則該工具可以自動地添加該代碼，該工具將FIL行解譯為與繼承單元有關，原因是存在相應的關鍵字。因此，可以簡單地將該行輸入為以下示例中這樣“正方形是一個圖形單元”。示例8o操作名稱，類名稱在此聲明了操作。只需要一個逗號，后接一個空格。示例9p封裝名稱[，包圍封裝]在此聲明了封裝，該封裝屬于具有名稱“包圍封裝”的包圍封裝。對包圍封裝的指明是可選的。示例10r類名稱1(1...1)關聯名稱(1...n)類名稱2本例示出了規定基數的一種方式。使用了兩個數字，關聯的每一端具有一個數字并且在括號中。在適當時，指令以“(1”、“(0”、“(m”或“(n”開始并以“1)”或“n)”結束。之前或之后有空格。至于關聯或類的名稱，其可以是任意名稱，例如包括一個或多個字。同樣，在名稱之前和之后有空格。此外，如果關聯名稱是“由......構成”或“包含”，則可以在隨后使用的UML工具中自動地生成集合(aggregation)。此外，正如代碼“h”，代碼“r”不是必需的，該工具適合于這樣解譯關聯，即如果需要，則通過識別基數的編碼(codification)來解譯關聯。例如，可以將行“系統(1...1)由(1...n)子系統構成”直接解譯為描述關聯“由......構成”(集合)。示例11u使用場合名稱，封裝名稱對使用場合的聲明還可以用于聲明可能對應于一個或多個使用場合的系統的功能。考慮以下示例c貓，示例c老鼠，示例r貓(1...1)要吃(1...n)老鼠在UML表示法中，將以上子句表示如下。類“貓”和“老鼠”通常通過標簽來符號化。相應的基數可以在附近出現。上述關系(r貓(1...1)要吃(1...n)老鼠)通過聯系標簽的箭頭來符號化。II.4FIL格式數據結構的穩定(valorization)FIL表示法的簡單性使得能夠將數據結構(或文件)創建為在可應用時直接從對以自然語言編寫的文本的分析中反映該表示法。因此，所創建的結構可以用作例如創建UML對象或生成源程序的基礎。再次參考圖1，其中創建內部對象模型60的步驟110反映在對MOI的數據結構的穩定中。“穩定”意指對對應于數據的值進行存儲(例如在計算機的隨機存取存儲器中或在大容量存儲介質上)。因此，可以在計算機上處理數據結構60。特別地，可以將建模單元表示(即由計算機轉換)為數據結構60的相應子句。注意，可以考慮不同的算法變型。例如，如果建模單元是單獨的(在分解步驟100中)，則將該建模單元轉換為相應的子句(步驟110)。作為替代，在步驟100中對每個單元進行識別后，可以將這些單元轉換為子句。因此，分解步驟100和創建步驟110可以是至少部分伴隨的。III.轉換為外部元模型的建模單元(創建新模型或代碼生成)III.1創建新模型，例如XMI模型再次參考圖1，該方法可以在轉換步驟120、140期間或之后包括XMI生成器從與MOI60相關聯的數據結構創建XMI模型70的步驟120。XMI生成器可以根據與例如在下文中描述的碼生成器所采用的原理類似的原理來操作。在訪問數據結構的內容之后，該生成器將該結構存儲于其自身的內部存儲器中，并隨后根據其特有的轉換規則對其內容進行轉換，針對這些轉換規則有多個可以設置的參數，并且這些轉換規則依賴于將在兩個元模型之間建立的匹配例如，一方面是FIL數據結構本身(輸入結構)的元模型，以及另一方面是XMI、Java、C#或C++數據結構(期望的輸出結構)的元模型。因此，該生成工具僅應用于內部地存儲了將給定元模型的建模單元與另一元模型的建模單元相匹配的轉換規則的數據結構。從這一方面講，存在用于構造這種生成器的工具，諸如來自Sodifrance的Model-ln-Action(參見www.mia-softwore.com)利用UML描述兩個元模型，并且隨后以這種方式非常迅速地得到使用高級語言的轉換規則以及轉換器-語言生成器。在此，從先前穩定的數據結構60生成模型70。然后，可以在模型產生步驟130期間從XMI模型70產生圖形的UML模型75。從XMI模型產生圖形的UML模型本身在本領域中是已知的(例如，諸如來自Softeam的Objecteering或來自i-Logix的Rhapsody之類的工具可以用于這一點)。III.2代碼生成本發明的方法還可以包括步驟140，即在轉換步驟120、140期間或之后生成代碼80。以與上面參考XMI生成器所描述的方式類似的方式，在代碼生成步驟期間，例如存儲數據結構，并隨后根據轉換規則對其內容進行轉換，針對這些規則有多個可以設置的參數，并且這些轉換規則依賴于所需的兩個元模型之間的匹配。在該步驟結尾，生成Java類或C#類。這些類可以有利地在綜合服務開發環境(SDE)85中使用。服務開發環境是知道例如如何直接讀取Java或C#源類的對象應用程序開發環境。從這一方面講，步驟150是引入這些類80的簡單步驟，這些類80直接由環境85以目標格式正確地生成。應當注意，存在用于從“專有”內部模型生成代碼的現有技術工具(例如來自IBM的RationalRose，Objecteering，或Rhapsody)。所討論的內部對象模型通常是每個制造商特有的，這些內部對象模型不會被發布、不可修改并且不可輸出(exportable)。為實現代碼生成，現有的代碼生成器采用級別比將產生的代碼的級別更高的描述。該描述通常依賴于諸如UML之類的建模并用于以給定的編程語言生成其代碼。實際上，輔助程序使得開發者能夠選擇目標語言(例如C#或Java)。然后，輔助程序進行采用適當模式向目標語言的轉換。例如，Addison-Wesley專業出版社1995出版的ErichGamma、RichardHelm、RalphJohnson、JohnVlissides所著的“DesignPatterns”(設計模式)第一版中描述了對產生轉換模式來說有用的轉換原則。例如，在下文中給出由輔助程序從上述場景/使用場合生成的C#源代碼。 //———————————— //C#ClassNameMessagingBP // //CreationDate11-15-XXXX //GeneratedbyXXXXX //———————————— ＜％@WebServceLanguage＝″c#″ Class＝″PoweredBy.BusinessProcess.Messaging.MessagingBP″％＞ usingSystem； usingSystem.Web.Services； usingPoweredBy.WebServiceProxy；<!--SIPO<DPn="27">--><dpn="d27"/> namespacePoweredBy.BusinessProcess.Messaging { [WebService] publicclassMessagingBPSystem.Web.Services.WebService { //Attributes privateDirectoryServicetheDirectoryService； privateMessagingServicetheMessagingService； privateUserPreferenceServicetheUserPreferenceService； privateStringsender_email_address； privateContactlnfo[]sender_contact_list； privateStringcall_subject； privatemsgTypePrefmessaging_type； privateinti； //Constructor publicMessagingBP() { theDirectoryService＝newDirectoryService()； theMessagingService＝newMessagingService()； theUserPreferenceService＝newUserPreferenceSeivice()； } //Operations [WebMethod][SoapRpcMethod] publicvoidBraadcastMessage(Stringsender_name，Stringmessage) { sender_contact_list＝theDirectoryService.GetMyContactList(sender_name)； for(i＝0；i＜＝sender_contact_list.Length；i++) { messaging_type＝theUserPreferenceService.GetMessagePreference(sender_contact_list[i].Name)； switch(messaging_type){ casemsgTypePref.Sms{ theMessagingService.SendSMS(sender_confact_list[i].Mobile，message)；<!--SIPO<DPn="28">--><dpn="d28"/> break；} (...) }//endswitch }//endfor }//endofoperation }//endofclass }//endofnamespace—旦生成了例如“.asmx”文件形式的源代碼，就可以立即通過連接到輔助程序的測試環境來對其進行測試。III.2部署現在，開發工程師可以通過選擇所需的部署類型(例如MicrosoftIIS、Apache/Axis或BPEL)來部署最終的服務。然后，采用適當的模式，將新服務的最終源代碼移入適當的目錄中。然后，產生并部署相應的代理。然后就可以在因特網或內網上根據所選擇的部署特征獲得該新服務。因此，本發明用于將由用戶編寫的不嚴密的原始文本轉換為可編譯的、可執行的、可測試的且準備好部署的軟件。應當牢記采用本發明方法的輔助程序的全部方法，本發明的方法集合了多個有益的基本方法并改善了Web服務的產生。根據本發明，可以更快地、以更低的成本并且以更好的質量產生服務。特別地-根據“交互處理”方法，可以將新的Web服務視為對多個現有基本服務的配合集合；-根據多參與者方法，分析者、開發者等不同的參與者可以在不同的級別上使用該輔助程序；-根據多形式方法，輔助程序可以讀取、轉換和反轉半正式的或模糊的文本；-根據其不可知(agnostic)方法，獨立于最終的實現語言來表達目標事務處理的使用場合和場景；以及-根據“建模單元”和MDA方法，結合地且屏蔽地，構造了對用戶隱藏的一致的MOI，用戶只需要操縱高級描述。然而，本發明不限于上述實施例，并且本發明可將其自身推廣為多種其他變型，這些變型對本領域的技術人員來說是相當明顯的。權利要求1.一種產生新的Web服務的方法，包括步驟-將文本描述分解(100)為符合對象建模形式體系的所述新的Web服務的建模單元；-根據所述建模單元創建(110)內部對象模型(60)；以及-將所述內部對象模型(60)的建模單元轉換(120、140)為外部元模型的建模單元。2.根據權利要求1所述的方法，其中，在所述分解步驟(100)中，所述文本描述包括場景(50)和/或使用場合(50)。3.根據權利要求2所述的方法，其中所述分解步驟(100)包括對數據的語法和/或語義的分析。4.根據權利要求3所述的處理方法，其中所述分解步驟還包括在所述使用場合中識別-對所述新的Web服務的一般描述；以及-應該由該服務使用的現有Web服務。5.根據權利要求4所述的處理方法，其中所述分解步驟還包括-從所述使用場合識別所述新服務中所涉及的參與者；以及-從所述新的Web服務的所述一般描述提取所述新服務的輸入-輸出。6.根據權利要求4或5所述的處理方法，其中所述分解步驟還包括重新組織所述場景的短語。7.根據權利要求6所述的處理方法，其中所述分解步驟還包括根據重新組織的所述場景的短語來產生邏輯短語。8.根據權利要求1-7中的任一項所述的方法，其中所述外部元模型是XMI模型，并且所述轉換步驟(120、140)是經由XMI生成器創建所述XMI模型(70)的步驟(120)。9.根據權利要求8所述的方法，在創建所述XMI模型的所述步驟(120)之后包括-根據所創建的所述XMI模型(70)創建UML模型(75)的步驟(120)。10.根據權利要求1-9中任一項所述的方法，在所述轉換步驟(120、140)期間或之后包括-生成代碼(80)的步驟(140)。11.根據權利要求1-10中任一項所述的方法，其中創建所述內部對象模塊(60)的所述步驟(110)包括-穩定所述內部對象模塊(60)的數據結構(60)的步驟；并且其中-所述數據結構(60)包括多個子句；-將這些子句中的每個子句與所述形式體系的一個或多個建模單元相關聯；以及-這些子句中的每個子句全部是聲明性的。12.根據權利要求11所述的方法，其中每個所述子句與一個單獨的建模單元有關。13.根據權利要求12所述的方法，其中每個所述子句包括與其所關聯的所述建模單元有關的代碼以及與該建模單元有關的特征。14.根據權利要求11、12或13所述的方法，其中一些所述子句包括與其所關聯的所述建模單元的容器有關的特征。15.根據權利要求1-14中任一項所述的方法，其中所述對象建模的形式體系是UML形式體系。16.根據權利要求1-15中任一項所述的方法，其中所述形式體系的所述建模單元中的一個建模單元是-封裝；-使用場合；-類；-屬性；-關聯；或-繼承。17.一種計算機程序產品，其適合于實現根據權利要求1-16中任一項所述的方法。18.一種計算機文件，通過根據權利要求1-16中任一項所述的方法來得到所述計算機文件。全文摘要本發明涉及一種產生新的Web服務的方法，包括步驟將例如場景(50)和/或使用場合(50)之類的數據分解(100)為基于對象建模形式體系的新的Web服務的建模單元；根據該建模單元創建(110)內部對象模型(60)；以及將內部對象模型(60)的建模單元轉換(120、140)為外部元模型的建模單元。后一步驟可以伴隨生成代碼(80)的步驟(140)或者經由XMI生成器創建XMI模型(70)的步驟(120)。本發明還涉及一種適合于實現本發明方法的計算機程序產品，以及一種通過該方法得到的計算機文件。文檔編號H04L29/06GK1892593SQ20061009311公開日2007年1月10日申請日期2006年6月21日優先權日2005年6月21日發明者菲拉普·拉爾韋,帕特里克·方丹申請人:阿爾卡特公司