專利名稱：產(chǎn)生和管理商業(yè)過程集成解決方案的系統(tǒng)和方法
技術(shù)領(lǐng)域：
本發(fā)明涉及商業(yè)系統(tǒng)和基礎結(jié)構(gòu)，更具體地說，涉及產(chǎn)生和管理商業(yè)過程集成解決方案的系統(tǒng)和方法。
背景技術(shù)：
從根據(jù)用戶知識和現(xiàn)有文獻的商業(yè)過程著手，產(chǎn)生操作和管理該商業(yè)過程的優(yōu)化IT解決方案目前是一項成本高、費時的任務。目前，商業(yè)過程建模的實用性有限，即主要在包括徒手繪制的圖表的文檔中說明商業(yè)過程建模，缺少正規(guī)的語義學。結(jié)果從而包含只能在代碼級共享的非結(jié)構(gòu)化解決方案知識。此外，完成的解決方案不易于或者不能自動與初始的過程模型一致，商業(yè)過程性能難以測量，并且難以用于重建商業(yè)過程。
目前已知的關(guān)于該問題的解決方案的成本效率不高，時間效率也不高，此外，并不覆蓋整個端對端商業(yè)過程。例如，Holosofx是一種產(chǎn)生商業(yè)過程模型和工作流的流行工具，但是不能用于產(chǎn)生其它必需的組件，例如應用適配器或商業(yè)對象。Crossworlds InterChangeServer是一種實現(xiàn)商業(yè)對象和商業(yè)邏輯操作的工具，但是不進行商業(yè)過程建?；蚬ぷ髁鳟a(chǎn)生和處理。
從而，非常需要為商業(yè)過程集成和管理解決方案提供一種系統(tǒng)和方法。
此外，非常需要提供一種商業(yè)級建模語言，所述語言正規(guī)地從各個方面，包括作為信息技術(shù)(IT)執(zhí)行模型的實現(xiàn)基礎的策略操作和執(zhí)行觀點，描述功能商業(yè)模型，并便于與商業(yè)過程開發(fā)生存期內(nèi)改變商業(yè)目的和目標相應的商業(yè)過程重建。

發(fā)明內(nèi)容
本發(fā)明的目的是提供一種節(jié)省成本并且節(jié)省時間的解決方案，所述解決方案提供商業(yè)過程集成和管理解決方案，尤其是可產(chǎn)生商業(yè)過程的IT解決方案的新過程。
根據(jù)本發(fā)明的優(yōu)選實施例，提供一種產(chǎn)生商業(yè)集成和管理解決方案的完整系統(tǒng)和方法。本發(fā)明的創(chuàng)新點在于建模的商業(yè)活動和解決方案產(chǎn)生過程中每個步驟的輸出的正規(guī)定義。在每個步驟中，根據(jù)明確的模式和規(guī)范，產(chǎn)生一個或多個文檔或其它工件。用軟件實現(xiàn)的算法使關(guān)鍵步驟自動化，或者通過用圖形用戶界面利用工具，幫助關(guān)鍵步驟。模式和規(guī)范使工作產(chǎn)物有效，確保與其它組件和整個模型的兼容性。另一關(guān)鍵要素是在極早階段中引入關(guān)鍵性能指標，接下來實現(xiàn)軟件探測器，以便收集商業(yè)過程性能數(shù)據(jù)。一旦部署該解決方案，則向商業(yè)分析員報告這些數(shù)據(jù)，以便調(diào)整性能和重構(gòu)商業(yè)過程。
在這些目的的實現(xiàn)中，向商業(yè)過程解決方案的整個生命周期提供全面的方法和工具集，包括1)策略層的商業(yè)策略建模；2)操作層的商業(yè)過程建模，在操作模型中，用承諾和關(guān)鍵性能指標定義商業(yè)過程度量結(jié)果；3)過程模型到信息技術(shù)(IT)解決方案的轉(zhuǎn)換，IT解決方法由預定類型的解決方案工件組成，包括商業(yè)對象，自適應商業(yè)對象，宏流，微流，EAI適配器，B2B連接器，用戶互作用屏幕流；4)模型的模擬，以便進行靜態(tài)和動態(tài)分析；5)關(guān)鍵性能指標到IT解決方案中IT探測器的映射；6)在一組集成的圖形工具中定義IT解決方案工件的細節(jié)；7)把解決方案工件綁定和部署到特定運行時平臺；8)監(jiān)視并報告由來自探測器的事件數(shù)據(jù)服務的關(guān)鍵性能指標測量的商業(yè)過程性能；和9)代理的可選調(diào)用，以便推薦和/或?qū)崿F(xiàn)對商業(yè)過程的提高其性能的改變。


結(jié)合附圖，根據(jù)下面的詳細說明，對本領(lǐng)域的技術(shù)人員來說，本發(fā)明的目的、特征和優(yōu)點將變得顯而易見，其中圖1是圖解說明根據(jù)本發(fā)明的產(chǎn)生自適應商業(yè)解決方案的模型驅(qū)動方法的一般方框圖；圖2圖解說明了根據(jù)本發(fā)明的端對端商業(yè)過程建模系統(tǒng)和組件100；圖3圖解說明了根據(jù)本發(fā)明的商業(yè)解決方案產(chǎn)生生命周期；圖4圖解說明了表現(xiàn)商業(yè)運作觀點的商業(yè)運作規(guī)范(BopS)模型。
具體實施例方式
本發(fā)明定義一種過程，借助該過程，能夠產(chǎn)生商業(yè)過程的IT解決方案。在每個步驟中，產(chǎn)生可供未來步驟之用的，或者在以后在其它解決方案的產(chǎn)生過程中，重復使用的一組具體的工件。
圖1描述了產(chǎn)生自適應商業(yè)解決方案的模型驅(qū)動方法10。在該方法中，捕捉商業(yè)語義，隨后直接實現(xiàn)改變商業(yè)的IT變化。該方法包括(1)為每個主要的用戶角色和用途，在恰當?shù)某橄髮咏⑸虡I(yè)的模型的步驟，和(2)相對于彼此以及相對于IT基礎結(jié)構(gòu)，映射、變換和連接這些模型，從而操縱模型對應于操縱實現(xiàn)代碼。操縱模型而非操縱代碼的優(yōu)點在于一般來說，和代碼相比，模型更易于理解和操縱。例如，如同面向?qū)ο蟮腏ava開發(fā)人員不希望操縱匯編代碼那樣，需要修改商業(yè)操作的商業(yè)用戶-不論是經(jīng)營范圍(a line of business)管理員，商業(yè)分析員或商業(yè)過程設計專家-并不希望操縱Java代碼或者甚至BPEL(商業(yè)過程執(zhí)行語言)腳本來理解當前的過程或者改變當前的過程。相反，經(jīng)營范圍管理員希望操縱形象的商業(yè)操作模型，形象的商業(yè)操作模型是關(guān)于該用戶和用途的商業(yè)語義的恰當抽象層。
如圖1中所示，方法10包括使模型變成可執(zhí)行的代碼的步驟。用于三種主要用戶角色和組織用途的三級模型包括1)例如以記分卡(目的的量化)和目標(可度量的目標)的形式定義商業(yè)目的和目標的策略模型12。由執(zhí)行者21，或者類似的商業(yè)專業(yè)人員進行這種策略建模；2)操作模型14以商業(yè)過程、承諾和映射到記分卡以便與它們的關(guān)鍵目標比較的KPI(關(guān)鍵字性能指標)量度(metrics)定義商業(yè)做什么。這種操作建模由經(jīng)營范圍(Line-of-Business)(LOB)管理員(manager)31、商業(yè)分析員或類似的商業(yè)級用戶進行。在策略模型的產(chǎn)生中，提供數(shù)據(jù)鏈接結(jié)構(gòu)，以便借助操作模型映射策略模型。最好，操作模型14被半自動變換成3)以獨立于平臺的方式，用具體的應用、數(shù)據(jù)源、人員和合作者定義如何執(zhí)行商業(yè)操作的執(zhí)行模型16。這種執(zhí)行建模由例如IT設計師或類似的IT專業(yè)人員進行。在策略模型的產(chǎn)生中，提供軟件數(shù)據(jù)結(jié)構(gòu)，以便把操作模型變換成執(zhí)行模型。最后，需要進行一些開發(fā)，以便連接獨立于平臺的執(zhí)行工件(artifact)和諸如WAS J2EE或MS.NET平臺之類具體的平臺實現(xiàn)模型18，并通過利用Web服務實現(xiàn)專用API。這種實現(xiàn)建模由例如IT開發(fā)人員51、或者類似的IT專業(yè)人同進行。
在這些映射、變換和連接就位的情況下，原始事件，交易23以及環(huán)境數(shù)據(jù)可被捕捉并集合到商業(yè)量度中，例如投資收益率(ROI)或每股收益(EPS)，以便與商業(yè)活動監(jiān)視(BAM)控制板(dashboard)中的商業(yè)承諾和目標比較。通過多個反饋循環(huán)25a-25c，連續(xù)優(yōu)化/檢測和響應(CO/SaR)技術(shù)隨后可提供管理操作例外的決策支持，并提前建議改變商業(yè)過程，以便最佳地實現(xiàn)商業(yè)目標。最后，主要通過操縱模型而不是代碼-和傳統(tǒng)的商業(yè)變換事務相比，需要少得多的時間和成本，現(xiàn)在能夠直接把商業(yè)方向方面的變化從策略模型向下傳送到IT基礎結(jié)構(gòu)。這允許和修改模型一樣快速和容易地修改商業(yè)過程。
圖2圖解說明了端對端商業(yè)過程建模系統(tǒng)100和各個組件。在優(yōu)選實施例中，ABS原理的第一步驟103是用外部定義的商業(yè)內(nèi)容，填充商業(yè)級建模(BLM)庫，例如存儲器裝置或數(shù)據(jù)庫110。上述商業(yè)專業(yè)人員，例如執(zhí)行者可實現(xiàn)收集或產(chǎn)生保存在庫110中的外部定義的商業(yè)內(nèi)容的商業(yè)策略造模工具或任意類似方法。該內(nèi)容包括(但不限于)現(xiàn)有的或者需要通過會見商業(yè)過程中涉及的人員而產(chǎn)生的商業(yè)過程的文獻。接下來在步驟106涉及利用商業(yè)分析員(例如商業(yè)操作管理員)產(chǎn)生商業(yè)操作的形式模型，例如通過利用稱為Business ViewEditor(BE)的工具。BE是允許商業(yè)用戶或分析員以圖表200的形式，產(chǎn)生商業(yè)過程的模型的圖形工具，圖表200的每個組件和連接都具有明確的含義。該商業(yè)過程的圖形表示200在符合某一模式(schema)，例如XML模式的文檔中，具有對應的文本表示。如同這里更詳細說明的那樣，這種模式提供包括建模過程任務、商業(yè)工件流和工件庫(repository)的商業(yè)操作的子模型的形式過程。商業(yè)過程模型200可保存在相同的商業(yè)級模型(BLM)庫110中，以便稍后取出、重復使用、定制或修改，或者保存在另一類似的庫中(未示出)。如同這里更詳細說明的那樣，用規(guī)定商業(yè)的操作觀點的稱為BOpS(商業(yè)操作規(guī)范)的形式語言描述商業(yè)過程模型。實現(xiàn)稱為TransformationWizard 150(變換向?qū)?的工具的另一步驟108被用于把BLM 200變換成IT級模型(ILM)250。在作為參考包含于此的同時待審的美國專利申請No.＿＿(美國律師編號YOR920030143US1(16596))中更詳細地說明了這種變換過程。
更具體地說，Transformation Wizard 150可自動把商業(yè)級模型變換成IT級模型(ILM)250。Transformation Wizard可由使用不同的方法產(chǎn)生解決方案的IT體系結(jié)構(gòu)的一種或多種備選算法自動操作。算法識別將在ILM 250中使用的必需組件，包括(但不限于)諸如商業(yè)對象201、自適應實體(自適應商業(yè)對象)202、屏幕流203、宏流(macroflow)和工作流(workflow)204，微流(可自動執(zhí)行的任務)205，和應用(application)或企業(yè)對企業(yè)適配器206之類組件。自適應實體是關(guān)于商業(yè)對象可具有的各種狀態(tài)和商業(yè)對象能夠經(jīng)歷的轉(zhuǎn)變的規(guī)定。工作流是一系列的活動，其中的一些活動涉及人類交互作用。應用適配器是允許獨立的應用和商業(yè)過程集成的軟件。企業(yè)對企業(yè)適配器是使外部商業(yè)合作人能夠與商業(yè)過程結(jié)合的軟件。
步驟115由IT開發(fā)人員51進行，IT開發(fā)人員51實現(xiàn)運行時(runtime)開發(fā)工具185，例如IT級Editor或“Binding Wizard”工具(未示出)，可用于查看或修改這一級的工件。一般來說，采用一個或多個IT級Artifact Editor(工件編輯器)來進一步指定每個組件的細節(jié)。這是必要的，因為對于商業(yè)級模型來說，包含足以充分定義IT級的所有組件的足夠細節(jié)不現(xiàn)實。分別取回(如果先前已經(jīng)產(chǎn)生)或產(chǎn)生用于現(xiàn)有應用和商業(yè)合作人的適配器。從資產(chǎn)庫400取回這些適配器，和ILM中的工件一起被“Binding Wizard(綁定向?qū)?”工具用于產(chǎn)生組件之間的綁定，隨后把這些綁定保存在資產(chǎn)庫400中。具體地說，Binding Wizard使用定義的適配器和ILM庫中的命令產(chǎn)生具體的綁定。
另一種運行時開發(fā)工具是產(chǎn)生可部署的解決方案，例如文件，并把它們部署在本地或遠程機器上的Package Generator(包產(chǎn)生器)。即，根據(jù)選擇的軟件和硬件平臺和技術(shù)，產(chǎn)生平臺專用組件，整個解決方案被打包并保存在運行時工件庫500中。該包隨后隨時可以測試和部署在客戶的環(huán)境中。
圖3描述了在開發(fā)生命周期275中，是如何產(chǎn)生和管理商業(yè)解決方案的。如圖所示，查找預期解決方案的商業(yè)目標包括如同這里更詳細說明的那樣，利用諸如BOpS之類商業(yè)過程建模語言，形式表現(xiàn)商業(yè)操作模型280；對諸如模擬引擎283之類的相關(guān)“運行時”平臺進行靜態(tài)和動態(tài)分析282的分級結(jié)構(gòu)。如同這里說明的那樣，建立預期的解決方案需要開發(fā)體系結(jié)構(gòu)模型285，開發(fā)IT工件287，隨后產(chǎn)生集成中件(WBI)289。由此，通過執(zhí)行產(chǎn)生商業(yè)觀察模型290，定制商業(yè)活動監(jiān)視器292，和實現(xiàn)查看模型的探測器(供給模型)和控制板295的步驟，觀察和監(jiān)視商業(yè)過程。觀察和監(jiān)視數(shù)據(jù)被反饋(297)給第一層次，以便進一步改進和找到最佳解決方案。
如上所述，根據(jù)商業(yè)操作規(guī)范(BOpS)描述商業(yè)過程模型，BOpS是一種商業(yè)級建模語言。商業(yè)級模型提供商業(yè)操作的形式表現(xiàn)，反映過程和商業(yè)政策，客戶要求，限制因素和解決方案環(huán)境。商業(yè)分析員和經(jīng)營范圍用戶將定義這種模型。
可獨立于任意IT實現(xiàn)，單獨把商業(yè)級模型用于成本分析，過程模擬，資源分配或優(yōu)化研究。BOpS模型的一個預期用途是用作這類獨立應用的基礎。另外，BOpS模型預定被用作IT實現(xiàn)的起點和頂極“托架(bracket)”作為起點，因為將提供幫助把模型改進到可執(zhí)行的解決方案層次的輔助工具和過程；作為頂級“托架”，因為BOpS模型將保持與部署的解決方案互鎖，并用作商業(yè)活動監(jiān)視，基于實時數(shù)據(jù)的過程分析和過程重構(gòu)的基礎。
BOpS模型的其它擴展可覆蓋資源分配和部署，記帳和收費，資產(chǎn)管理，安全性，目錄和組織結(jié)構(gòu)，企業(yè)信息模型，內(nèi)部和外部聯(lián)系渠道等的企業(yè)模型。預期BOpS模型用作建立企業(yè)的模型的幾乎各個方面的公共核心和起點。
BOpS模型是企業(yè)所有者的觀點的形式表現(xiàn)。第二種定位BOpS的方式和解決方案開發(fā)生命周期相關(guān)它是解決方案的第一形式表現(xiàn)，在初始機會評估和要求收集，策略公式化之后，并在任意IT體系結(jié)構(gòu)確定之前。
另一種定位BOpS的方式和對解決方案建模的粒性(granularity)相關(guān)這是商業(yè)級用戶認識到的最細致的表現(xiàn)。從商業(yè)用戶的觀點來看，BOpS任務，資源和工件是“原子的”(一個人可把發(fā)票撕成碎片，或者折卸計算機，但是結(jié)果不再被看作“商業(yè)文檔”或“系統(tǒng)資源”)。
商業(yè)系統(tǒng)的觀點有三種。表現(xiàn)商業(yè)是什么的操作觀點，描述商業(yè)為何如此的策略觀點，和描述商業(yè)如何如此的執(zhí)行觀點。商業(yè)過程建模的多數(shù)工作集中于執(zhí)行層。基于表示商業(yè)的操作觀點的最佳方式是集中于商業(yè)處理的工件和影響這些工件的生命周期的商業(yè)要素的思想，建立BOpS。這些商業(yè)要素分成三類代表在這些工件的環(huán)境中實現(xiàn)的不可還原的商業(yè)功能的商業(yè)任務，用作這些工件的存儲器的工件庫，和定義關(guān)于商業(yè)要素的聚合的布局的商業(yè)過程。BOpS描述的商業(yè)模型還被分解成三個子模型。信息模型捕捉商業(yè)工件和商業(yè)事件。功能模型捕捉商業(yè)過程，商業(yè)任務和工件庫。資源模型捕捉角色和資源組。
很自然地發(fā)現(xiàn)對商業(yè)操作建模涉及對語句的三種基本組成主語(行動者)，動詞(動作)和賓語(工件)建模。從而，如圖4中所示，BOpS模型300具有三個部分資源模型(描述行動者)302；功能模型(描述動作)304；和信息模型(描述工件)306。資源模型302描述行動者和他們的能力。資源308(可以是人力資源，自動化資源，或外部資源)有資格充任角色，角色被定義為完成任務的能力的聚合。角色309可被“劃分范圍(scoped)”，這種情況下，這些能力具有任務實例(或工件)相關(guān)性。注意資源可被組織(商業(yè)單位，部門，合作人)所有。功能模型304以商業(yè)過程，商業(yè)任務和用作企業(yè)處理的工件的存儲器的工件庫的形式，描述動作。這里同樣確定模型的一致性哪些任務利用何種資源處理哪些工件，任務如何通過工件的交換，被互連(排序)。最后，信息模型306描述商業(yè)任務互換的工件(“文檔”，“工作產(chǎn)品”)312和商業(yè)事件(“消息”、“信號”)。另外，它表征任務環(huán)境和商業(yè)謂詞(predicate)，任務環(huán)境保持任務需要的臨時信息，商業(yè)謂詞模擬關(guān)于所有信息模型組成的約束，以及所有信息模型組成之間的關(guān)系。
如圖4中所示，圖中圖解說明了和BOpS一起工作的兩個互補模型的應用。商業(yè)過程承諾(commitment)語言(BPCL)316用于指定商業(yè)操作的關(guān)鍵性能指標(KPI)318。包括模式322的模擬模型320規(guī)定商業(yè)操作的模擬參數(shù)。
現(xiàn)在借助這里更詳細說明的每個語言結(jié)構(gòu)的細節(jié)，概略說明BOpS的語法。在最高層，BOpS使用商業(yè)模型結(jié)構(gòu)定義商業(yè)的操作觀點。商業(yè)模型中包括的是信息模型、功能模型和資源模型。下面本說明書使用非正式的語法描述XML片斷的XML文法語法表現(xiàn)成XML實例，但是數(shù)值指示數(shù)據(jù)類型而不是數(shù)值；粗體文法前面一直沒有介紹，在例子中也不特別關(guān)心粗體文法；<--description-->是來自一些“other”名稱空間的元素的占位符(類似于XSD中的##other)；如下把字符附到元素、屬性和<！--description-->上“？”(0或1)，“*”(0或更大)，“+”(1或更大)。字符“[”和“]”用于表示包含的項可相對于“？”、“*”或“+”字符看作一組；被“|”隔開和被“(”和“)”聚合在一起的元素和屬性意味著語義替換物；XML名稱空間前綴(下面定義)被用于指示正被定義的元素的名稱空間；始于＜？xml的例子包含和本說明書相符的足夠信息；其它例子是片斷，并且為了相符，需要指定額外的信息；以文法的正規(guī)定義的形式提供XSD模式。下面借助如上所述的語言的基本結(jié)構(gòu)，說明基礎商業(yè)模型的語法結(jié)構(gòu)<businessModel name＝”string”targetNamespace＝”anyURI”？expressionLanguage＝”anyURI”？xmlns＝”http://www.ibm.com/2002/07/business-process/bops/”>
<informationModel>
informationmodel</informationModel>
<functionalModel>
<businessProcess name＝”ncname”abstract＝”true|false”？extemal＝”true|false”？automatic＝”true|false”？transactional＝”true|false”？compensation＝”true|false”？>+businesselement(businessProcess，businessTask，artifactRepository)*</businessProcess>
<businessTask name＝”ncname”automatic＝”true|false”？transactional＝”true|false”？compensation＝”true|false”？>*businesselement(businessTask)</businessTask>
<artifactRepository name＝”ncname”>*businesselement(aritifactRepository)</artifactRepository>
</functionalModel>
<resourceModel targetNamespace＝”any URI”>？<roles>？<role name＝”string”>+<scopes？<scope name＝”string”？value＝”string”>+</scopes>
</role>
</roles>
<resources>
resourceGroup</resources>
</resourceModel>
<constraints/>？tConsttaints？</constraints>
</bops>
根據(jù)所示的基本結(jié)構(gòu)，頂級屬性如下所示其屬性定義模型的名稱的“name”；其屬性定義文檔的目標名稱空間的“targetNamespace”；其屬性規(guī)定過程中使用的表達語言的“expressionLanguage”。該屬性的當前默認是由在http://www.w3.org/TR/1999/REC-xpath-19991116的XPath 1.0規(guī)范的URI表示的XPath 1.0；“informationModel”描述上面提及的和商業(yè)的操作觀點有關(guān)的工件和商業(yè)事件；“functionalModel”描述上面提及的過程、任務、工件庫及他們的利用端口和鏈接的互連；“resouce Model”描述和商業(yè)操作相關(guān)的上述組織角色和資源組；“constraints”描述確保BOpS商業(yè)模型的語義正確性的約束條件。
功能模型如上所述，標記“businesselement”可以是下述任意之一businessProcess；businessTask；和artifactRepository。<businessProcess>結(jié)構(gòu)描述具有如下基本語言結(jié)構(gòu)的商業(yè)過程<businessProcess name＝”ncname”abstract＝”true|false”？external＝”true|false”？automatic＝”true|false”？transactional＝”true|false”？compensation＝”true|false”？>
ports？<links>？<link fromport＝”ncname”toport＝”ncname”/>*</links>
businesselement(businessProcess，businessTask，artifactRepository)*roles？</businessProcess>
<businessTask>結(jié)構(gòu)描述如下所述的商業(yè)任務<businessTask name＝”ncname”automatic＝”true|false”？transactional＝”true|false”？compensation＝”true|false”？>
ports？<taskContext>？<contextVariable name＝”ncname”type＝”qname”？value＝”string”？>*<predicate name＝”ncname”expression＝”string”/>？</contextVariable>
</taskContext>
roles？<trigger timer＝”true|false”？self＝”true|false”？>？<port id＝”ncname”/>*</trigger>
</busincssTask>
<artifactRepository>結(jié)構(gòu)描述如下所述的工件<artifactRepository name＝”ncname”label＝”string”？>
ports？</artifactRepository>
如下描述上面涉及的標記“ports”<ports>
<port name＝”string”direction＝”in|out|in-out|out-in”predicate＝”string”？identityPassed＝”true|false”？proxyOf＝”ncname”？>*choice<businessArtifactType name＝”ncname”/>
<businessEventType name＝”ncname”/>
choice<predicate name＝”ncname”expression＝”string”/>？</port>
</ports>
信息模型如下描述上面涉及的標記“informationmodel”<businessArtifactType name＝”ncname”type＝”qname”？/>*<businessEventType name＝”ncname”type＝”qname”？/>*<predicate name＝”ncname”expression＝”string”/>*資源模型如下描述上面涉及的標記“roles”<roles>
<role roleref＝”qname”？>*<brmrole>？...
<brmrole>
</role>
</roles>
如下描述上面涉及的標記“resourceGroup”<resource name＝”string”aggregationType＝”bag|sequence|alternative？”>*tAtomicResourceresourceGroup</resource>
<humanResource name＝”string”aggregationType＝”bag|sequence|alternative？”>*tAtomicResource<humanResource name＝”string”aggregation Type＝”bag|sequence|alternative？”/>*</humanResource>
<systemResource name＝”string”aggregationType＝”bag|sequence|alternative？”>*tAtomicResource<systemResource name＝”string”aggregationType＝”bag|sequence|alternative？”/>*</systemResource>
<externalResource name＝”string”aggregationType＝”bag|sequence|alternative？”>*tAtomicResource<externalResource name＝”string”aggregationType＝”bag|sequence|alternative？”/>*</externalResource>
如下描述上面涉及的標記“tAtomicResource”<attributes>？<attribute name＝”string”value＝”string”？>+<description/>*</attribute>
</attributes>
<roles>
<role name＝”string”>+<scope name＝”string”？value＝”string”>*</role>
</roles>
約束利用Boolean Xpath描述約束條件，并且對于語義要正確的模型來說，約束條件必須被評價為真。如下描述上面涉及的標記“tConstraints”<constraints>？<constraint name＝”ncname”expression＝”string”>*<description/>？</constraint>
</constraints>
BOpS商業(yè)模型捕捉商業(yè)操作的關(guān)鍵工件的生命周期和影響生命周期的商業(yè)事件。利用商業(yè)謂詞捕捉操作層的商業(yè)邏輯。商業(yè)工件、商業(yè)事件和商業(yè)謂詞是BOpS信息模型的基礎。
<xscomplexType name＝″tArtifact″>
<xsattribute name＝″name″type＝″xsNCName″use＝″required″/>
<xsattribute name＝″type″type＝″xsQName″use＝″required″/>
</xscomplexType>
BOpS商業(yè)模型捕捉商業(yè)操作的關(guān)鍵工件的生命周期和影響生命周期的商業(yè)事件。利用商業(yè)謂詞捕捉操作層的商業(yè)邏輯。商業(yè)工件、商業(yè)事件和商業(yè)謂詞是BOpS信息模型的基礎。
商業(yè)工件還提供了使用BOpS定義本例商業(yè)的操作觀點和描述商業(yè)的核心結(jié)構(gòu)。就旅行社的例子來說，旅行預定過程對客戶的計劃旅程，識別所需的一段飛行航程和賓館預定。它隨后產(chǎn)生負責預定航班和賓館的子過程。如果所有預約在預定時限內(nèi)被確認，則打印旅行計劃并將其發(fā)給客戶。
如上所述，BOpS通過商業(yè)要素，以工件類型的流的形式捕捉商業(yè)工件的生命周期。工件類型的基數(shù)屬性表示關(guān)于某一工件類型的實例的任何限制。工件類型還識別該工件類型的信息變量。工件或者由商業(yè)任務處理，或者駐留于工件庫中。工件具有下述屬性namencname-規(guī)定工件的名稱；和typeqname-規(guī)定工件的類型。它是一個限定(qualified)名稱，從而它可在另一名稱空間中。工件由其類型屬性描述，其類型屬性是一個限定名稱(參考名稱空間)。例證的工件的語法結(jié)構(gòu)如下<xscomplexTypename＝″tArtifact″>
<xsattribute name＝″name″type＝″xsNCName″use＝″required″/>
<xsattribute name＝″type″type＝″xsQName″use＝″required″/>
</xscomplexType>
商業(yè)事件商業(yè)事件(例如來自客戶的傳真或電話)可傳送工件參考或工件內(nèi)容的副本。從而，商業(yè)事件具有下述屬性name，例如指定工件的名稱的“ncname”；和type，例如指定工件的類型的“qname”。它是一個限定名稱，從而它可在另一名稱空間中。商業(yè)事件由其類型屬性描述，其類型屬性是一個限定名稱(參考名稱空間)。商業(yè)事件的語法結(jié)構(gòu)如下<xscomplexType name＝″tBusinessEvent″>
<xscomplexContent>
<xsextension base＝″tArtifact″/>
</xscomplexContent>
</xscomplexType>
商業(yè)謂詞商業(yè)謂詞是用模型中的信息變量和/或工件屬性來表示的條件邏輯的表達式。商業(yè)謂詞可用在BOpS模型中的下述部分中Port-作為其賦值(evaluation)確定工件是否通過該端口的布爾表達式；ContextVarable-作為其賦值設置變量的數(shù)值的正則表達式；和Constraint(s)-作為其賦值驗證模型的布爾表達式。利用XPath表述謂詞。它具有下述屬性namencname-謂詞的獨特名稱；和expressionstring用工件、商業(yè)事件或環(huán)境變量表示的XPath表達式。謂詞的語法結(jié)構(gòu)如下<xscomplexType name＝″tPredicate″>
<xsattribute name＝″name″type＝″xsNCName″ use＝″required″/>
<xsattribute name＝″expression″type＝″xsstring″use＝″required″/>
</xscompplexType>
如上所述，商業(yè)功能模型包括商業(yè)要素及他們的連接。商業(yè)要素是功能模型中的一般結(jié)構(gòu)，即，它被表示為商業(yè)過程，商業(yè)任務或者表示為工件庫。根據(jù)商業(yè)工件(例如購買定單，客戶記錄，合同，發(fā)票)的核心概念，建立商業(yè)功能模型。注意利用信息模型的結(jié)構(gòu)描述商業(yè)工件和商業(yè)事件的結(jié)構(gòu)，而用操作模型描述他們的生命周期；商業(yè)事件(例如計時器信號，警報，通知)在商業(yè)任務之間被交換。商業(yè)任務具有工件和事件進出的端口。端口通過鏈接被連接。此外，模型表征當任務中未處理工件時，商業(yè)工件留駐于其中的工件庫，和把任務、工件以及潛在嵌套的過程聚合成更大的操作單元的商業(yè)過程。注意商業(yè)功能模型和現(xiàn)有的多個“流模型”之間的根本區(qū)別在于在BOpS中，不存在任何流。只存在由到達的工件或事件產(chǎn)生的任務，進行某些工作，最后發(fā)送事件和工件，發(fā)送的事件和工件又會產(chǎn)生其它任務。這產(chǎn)生通過工件和事件的交換而連接的“互作用任務網(wǎng)”?？勺裱囟üぜ穆窂剑⒍x所遭遇的任務的順序為“過程”或“流”。但是，借助這種方法，可按照多個方式把特定BOpS模型分解成多個流，對于處理多個工件的任務來說，甚至不清楚他們屬于哪個流或過程。雖然BOpS中的“商業(yè)過程”結(jié)構(gòu)可用，但是這實際上應被看作“復合任務”，因為從外部來看，它看起來并且表現(xiàn)得完全像一項任務，具有發(fā)送或接收工件和事件的端口。唯一的區(qū)別在于對于過程來說，他們的內(nèi)部操作結(jié)構(gòu)在BOpS內(nèi)被進一步分解，而基本任務則不是這樣的。在資源模型中定義角色，并從商業(yè)模型查閱角色。角色識別誰能實現(xiàn)商業(yè)功能。
商業(yè)要素商業(yè)要素是抽象的結(jié)構(gòu)體。商業(yè)過程、商業(yè)任務和工件庫都擴展商業(yè)要素。商業(yè)要素的語法結(jié)構(gòu)如下<xscomplexType name＝″tBusinessElement″>
<xscomplexContent>
<xsextension base＝″bopstExtensibleElements″>
<xssequence>
<xselement name＝″ports″type＝″bopstPorts″minOccurs＝″0″/>
<xselement name＝″description″type＝″xsstring″minOccurs＝″0″/>
</xssequencc>
<xsattributc name＝″name″type＝″xsNCName″usc＝″required″/>
</xsextension>
</xscomplexContent>
</xscomplexType>
端口定義商業(yè)要素的接口。端口具有下述屬性namencname-端口的名稱；方向(入|出|入-出|出-入)-端口中信息流的方向。具體地說，“入”表示在該端口接收商業(yè)工件或商業(yè)事件。如果端口被定義成觸發(fā)端口，它將觸發(fā)(參見任務觸發(fā)器)任務的開始。它必須通過鏈接連接到對應的“出”端口；“出”表示通過該端口發(fā)送商業(yè)工件或商業(yè)事件。輸出端口不能被指定成任務的觸發(fā)器(參見任務觸發(fā)器)。它必須通過鏈接，連接到對應的“入”端口?！叭?出”表示接收對商業(yè)工件的請求，并回送相應的響應。入-出端口不能被指定為任務的觸發(fā)器(參見任務觸發(fā)器)。這些端口對所有商業(yè)要素都有效，并且通常在工件庫內(nèi)規(guī)定。它必須通過鏈接，連接到對應的“出-入”端口；“出-入”表示發(fā)送關(guān)于商業(yè)工件的請求，并接收對應的響應。如果該端口被定義成觸發(fā)端口，則它將觸發(fā)(參見任務觸發(fā)器)任務的開始。這里任務是根據(jù)預定的條件，監(jiān)聽/輪詢某一或某些工件。這些端口對任務和進程有效(對工件庫無效)。它必須通過鏈接，連接到對應的“入-出”端口。
predicatestring-其賦值確定端口是否有效的布爾XPath表達式。信息只能流經(jīng)有效端口；identifyPassed是表示工件的身份是否作為信息流的一部分被傳遞的布爾(真|假)值。在任意情況下，只有一個商業(yè)要素能夠持有某一工件的身份。商業(yè)要素通過其“identifyPassed”屬性被設置為“真”的“出”或“入-出”端口釋放工件身份。商業(yè)要素通過其“identifyPassed”屬性被設置為“真”的“入”或“出-入”端口接收工件身份。默認值被設置成真；proxyOfncname指示對物理端口的參考。該屬性表示該端口是一個代理端口，實際上指的是另一端口。它只適用于非抽象過程(它們必須具有涉及屬于其子過程、任務和庫的端口的端口)。
端口的語法結(jié)構(gòu)如下<xscomplexType name＝″tPorts″>
<xssequence maxOccurs＝″unbounded″>
<xselcment name＝″port″type＝″bopstPort″/>
</xssequence>
</xscomplexType>
<xscomplexType name＝″tPort″>
<xssequence>
<xschoice>
<xselement name＝″businessEventType″type＝″bopstBusinessEventRef″/>
<xselement name＝″businessArtifactType″type＝″bopstBusincssArtifactRef″/>
</xschoice>
<xselement name＝″predicate″type＝″bopstPredicate″minOccurs＝″0″/>
</xssequence>
<xsattribute name＝″name″type＝″xsNCName″use＝″required″/>
<xsattribute name＝″direction″type＝″tPortDrection″use＝″required″/>
<xsattribute name＝″predicate″type＝″xsNCName″use＝″optional″/>
<xsattribute name＝″identityPassed″type＝″xsboolean″use＝″optional″default＝″true″/>
<xsattribute name＝″proxyOf″type＝″xsNCName″use＝″optional″/>
</xscomplexType>
<xssimpleType name＝″tPortDirection″>
<xsrestriction base＝″xsstring″>
<xsenumeration value＝″in″/>
<xsenumeration value＝″out″/>
<xsenumeration value＝″in-out″/>
<xsenumeration value＝″out-in″/>
</xsrestriction>
</xssimpleType>
商業(yè)過程是商業(yè)要素，即商業(yè)任務、工件庫和支持分層結(jié)構(gòu)的其它商業(yè)過程的集合。商業(yè)過程具有下述屬性-namencname-規(guī)定商業(yè)過程的名稱abstract布爾值(真|假)-其抽象屬性被設置成“真”的過程不被分層分解成更多的任務和工件庫，而被看作不透明要素。它只包含定義其接口的端口和指示誰能實現(xiàn)其功能的角色。如果未規(guī)定抽象屬性，則該值被默認為“假”。
external布爾值(真|假)-外部屬性被設置成“真”的商業(yè)過程表示它在BOpS正在建模的商業(yè)的企業(yè)范圍之外。當前版本的BOpS模仿企業(yè)的操作和在這些操作環(huán)境中，該企業(yè)與其合作人的交互作用。如果未規(guī)定外部屬性，則認為外部屬性為“假”。除非另作規(guī)定，否則外部過程必定是抽象的(例如，制造商不會定義其供應商的商業(yè)過程)。
automatic布爾值(真|假)-自動屬性被設置成“假”的商業(yè)過程表示該商業(yè)過程需要人的干預才能完成。該過程內(nèi)的所有任務繼承自動屬性，并且如果需要，可超越該屬性。如果未規(guī)定自動屬性，則認為自動屬性為“真”。
transactional布爾值(真|假)-事務屬性被設置成“真”的商業(yè)過程表示整個過程被看作長運行事務，即，如果在過程的執(zhí)行中產(chǎn)生異常，那么整個商業(yè)過程狀態(tài)應被重置為開始執(zhí)行商業(yè)過程之前的狀態(tài)。如果未規(guī)定事務屬性，則認為事務屬性為“假”。所有任務繼承其父過程的事務屬性。
compensation布爾值(真|假)-補償屬性被設置成“真”的商業(yè)過程表示在它需要被“退回重來”(rolled back)的情況下，它支持補償。如果未規(guī)定補償屬性，則認為補償屬性為“假”。所有任務繼承其父過程的補償屬性。
商業(yè)模型必定包含至少一個商業(yè)過程。商業(yè)過程由商業(yè)要素(過程、任務、工件庫)，端口，鏈接和角色組成。端口規(guī)定商業(yè)過程的接口。角色規(guī)定誰有權(quán)執(zhí)行商業(yè)過程代表的商業(yè)功能。鏈接連接包含在商業(yè)過程中的商業(yè)要素的端口，規(guī)定工件通過商業(yè)要素的流。鏈接具有下述屬性fromportncname-對端口id的引用。端口的方向必須是“出”或“出-入”。
toportncname-對端口id的引用。端口的方向必須是“入”或“入-出”。
鏈接的語法結(jié)構(gòu)是<xscomplexType name＝″tLinks″>
<xssequence>
<xselement name＝″link″type＝″bopstLink″maxOccurs＝″unbounded″/>
</xssequence>
</xscomplexType>
<xscomplexType name＝″tLink″>
<xsattribute name＝″fromport″type＝″xsNCName″use＝″required″/>
<xsattribute name＝″toport″type＝″xsNCName″use＝″required″/>
</xscomplexType>
商業(yè)過程的語法結(jié)構(gòu)是<xscomplexType name＝″tProcess″>
<xscomplexContent>
<xsextension base＝″bopstBusinessElement″>
<xssequence>
<xselement name＝″links″type＝″bopstLinks″minOccurs＝″0″/>
<xselement name＝″businessProcess″type＝″bopstProcess″minOccurs＝″0″maxOccurs＝″unbounded″/>
<xselement name＝″businessTask″type＝″bopstTask″minOccurs＝″0″maxOccurs＝″unbounded″/>
<xselement name＝″artifactRepository″type＝″bopstArtifactRepository″minOccurs＝″0″maxOccurs＝″unbounded″/>
<xselement name＝″roles″type＝″bopstRoles″minOccurs＝″0″/>
</xssequence>
<xsattribute name＝″abstract″type＝″xsboolea″use＝″optional″default＝″false″/>
<xsattribute name＝″external″type＝″xsboolean″use＝″optional″default＝″false″/>
<xsattribute name＝″automatic″type＝″xsboolean″use＝″optional″default＝″true″/>
<xsattribute name＝″transactional″type＝″xsboolean″use＝″optional″default＝″false″/>
<xsattribute name＝″compensation″type＝″xsboolean″use＝″optional″default＝″false″/>
</xsextension>
</xscomplexContent>
</xscomplexType>
商業(yè)任務商業(yè)任務是商業(yè)模型中不可還原的功能商業(yè)要素。商業(yè)任務作用于工件。任務具有下述屬性namencname-規(guī)定商業(yè)任務的名稱automatic布爾值(真|假)-自動屬性被設置成“假”的商業(yè)任務表示該商業(yè)任務需要人的干預才能完成。所有任務繼承其父過程的自動屬性，并且如果需要，可超越該屬性。如果未規(guī)定自動屬性，則認為自動屬性為“真”。
transactional布爾值(真|假)-事務屬性被設置成“真”的商業(yè)任務表示該任務是transactional，即，如果在任務的處理中產(chǎn)生異常，那么整個任務應退回重來。如果未規(guī)定事務屬性，則認為事務屬性為“假”。所有任務繼承其父過程的事務屬性。
compensation布爾值(真|假)-補償屬性被設置成“真”的商業(yè)任務表示在發(fā)生異常的情況下，它支持補償。如果未規(guī)定補償屬性，則認為補償屬性為“假”。所有任務繼承其父過程的補償屬性。
商業(yè)任務由端口、任務環(huán)境(task context)、角色和觸發(fā)器組成。商業(yè)任務應具有至少一個端口，而任務環(huán)境、角色和觸發(fā)器是可選的。角色被用于識別誰有權(quán)執(zhí)行該商業(yè)任務。
商業(yè)任務的語法結(jié)構(gòu)是<xscomplexType name＝″tTask″>
<xscomplexContent>
<xsextension base＝″bopstBusinessElement″>
<xssequence>
<xselement name＝″taskContext″type＝″bopstTaskContext″minOccurs＝″0″/>
<xselement name＝″roles″type＝″bopstRoles″minOccurs＝″0″/>
<xselement name＝″trigger″type＝″bopstTrigger″minOccurs＝″0″/>
</xssequence>
<xsattribute name＝″automatic″type＝″xsboolean″use＝″optional″default＝″true″/>
<xsattribute name＝″transactional″type＝″xsboolean″use＝″optional″default＝″true″/>
<xsattribute name＝″compensation″type＝″xsboolean″use＝″optional″default＝″false″/>
</xsextension>
</xscomplexContent>
</xscomplcxType>
任務環(huán)境(context)對于一項任務，可定義一個或多個“contextVariables”。任務環(huán)境定義任務專用信息。這種信息的可能用途是定義可在端口中的布爾表達式(表示成謂詞)內(nèi)使用的變量，其賦值確定某一端口是否有效。
把數(shù)值分配給范圍變量。任務的資源分配取決于范圍變量的正確分配。
任務環(huán)境的語法結(jié)構(gòu)是<xscomplexType name＝″tTaskContext″>
<xssequence>
<xselement name＝″contextVariable″type＝″bopstContextVariableAttribute″maxOccurs＝″unbounded″/>
</xssequence>
</xscomplexType>
<xscomplexType name＝″tContextVariableAttribute″>
<xscomplexContent>
<xsextension base＝″bopstAttribute″>
<xssequence>
<xselement name＝″predicate″type＝″bopstPredicate″minOccurs＝″0″/>
</xssequence>
</xsextension>
</xscomplexContent>
</xscomplexType>
觸發(fā)器任務是當被觸發(fā)時，開始處理，并在某一合理時間之后保證停止的功能單元。根據(jù)下述情況觸發(fā)任務當通過“入”端口輸入工件時；當庫中存在工件時(這種情況下，回收機構(gòu)通過“出-入”端口觸發(fā)任務)；由計時器觸發(fā)；或者由它本身觸發(fā)。
觸發(fā)器的語法結(jié)構(gòu)是<xscomplexType name＝″tTrigger″>
<xssequence>
<xselement name＝″port″minOccurs＝″0″maxOccurs＝″unbounded″>
<xscomplexType>
<xsattribute name＝″name″type＝″xsNCName″use＝″required″/>
</xscomplexType>
</xselement>
</xssequence>
<xsattribute name＝″timer″type＝″xsboolean″use＝″optional″default＝″false″/>
<xsattribute name＝″self″type＝″xsboolean″use＝″optional″default＝″false″/>
</xscomplexType>
商業(yè)工件庫工件庫是商業(yè)工件的集結(jié)區(qū)。工件庫的一個實例只能持有特定的一種工件。工件庫被用于模仿與商業(yè)模型中的定購約束條件的時間相關(guān)性。工件庫具有下述屬性name-ncname-規(guī)定工件庫的名稱。端口定義工件庫的接口。由于工件庫只能持有一種工件，因此具有端口必須引用相同的工件類型。有效的端口方向是“入”、“出”和“入-出”。
工件庫的語法結(jié)構(gòu)是<xscomplexType name＝″tArtifactRepository″>
<xscomplexContcnt>
<xsextension base＝″bopstBusinessElement″/>
</xscomplexContent>
</xscomplexType>
資源模型資源模型描述執(zhí)行商業(yè)任務的行動者，以及他們的能力。執(zhí)行商業(yè)任務的一組能力定義一個角色。行動者被模擬成資源，資源有資格充任角色，如果他們能夠執(zhí)行對應的任務。如果資源可用，并且不受范圍條件限制(參見下面)，則他們可被分配給供執(zhí)行的這些任務。注意在模型的這一層次，沒有區(qū)分“執(zhí)行(performing)”和“幫助(assisting)”資源。這兩者之間的界限模糊不清，通常參與任務實現(xiàn)的資源將被占用，消耗，或者被收費，而和他們是“執(zhí)行”資源還是“幫助”資源無關(guān)。即使資源能夠執(zhí)行某一商業(yè)功能(即它有資格充任對應角色)，也存在關(guān)于其執(zhí)行某一任務的能力的限制，取決于任務實例。例如，公司中的幾個人可能是購買定單的“批準者”，但是根據(jù)定購產(chǎn)品的類型和價格，不是每個人都有資格批準每份定單。引入范圍的概念，來模擬資源能力的這種取決于實例的限制性。
資源資源可以是人力資源或自動化資源(機器或系統(tǒng)資源)。另外，外部資源類型可被引入超出過程所有者控制之外，過程所有者未知或者與過程所有者不相關(guān)的模型資源(不透明資源)中。雖然三種資源(人力、系統(tǒng)、外部)在模型的這一層次看起來相同，但是在擴展和改進中，例如對于過程模擬或IT實現(xiàn)來說，差異變得明顯。例如，人力資源最終可映射成公司名錄簿中的條目。系統(tǒng)資源將由應用、機器或自動化工具實現(xiàn)，并且需要連接器或適配器，以便參與自動化過程執(zhí)行。在通過量模擬(資源的數(shù)量和可用性未知，或者無限)，成本計算(由第三方招致的他們的成本)和IT實現(xiàn)(他們的交互作用需要B2B網(wǎng)關(guān))方面，外部資源不同于其它兩類資源。
資源用成本和可用性表征，應被看作具有區(qū)別身份(例如會計Bill Smith，SAP System 4224，航線預定服務www.flyright.com)的“確實”過程行動者。資源不會與角色混淆，角色只指示能力(例如，制造專家，旅行代理，導購(lead buyer)，開支帳批準者)。同一角色可由具有不同成本特性的資源扮演例如，根據(jù)誰批準開支帳，執(zhí)行該任務，每小時的成本會顯著變化。如同下面更詳細說明的那樣。
作為一個示例，人力資源可以是會計部門的某一雇員，或者一組四個IT專家。系統(tǒng)資源的一個例子是SAP R/3系統(tǒng)。外部資源的一個例子是航線預定服務。
<？xml version＝″1.0″encoding＝″UTF-8″？>
<resourceModel>
<resources>
<humanResource name＝″Accounting Clek 01″/>
<humanResource name＝″Accounting Clerk 02″/>
<systemResource name＝″SAP System 4224-A″/>
<extemalResource name＝″www.flyright.com″/>
</resources>
</resourceModel>
資源可被聚合。人力資源、系統(tǒng)資源或外部資源的聚合定義同一類型的一種新(復合)資源。類型不同的資源的聚合產(chǎn)生一種類型不明(un-typed)的資源。組合類型不明的資源和任意資源將再次產(chǎn)生一種類型不明的資源。例如，人力資源的聚合可被看作“團隊”或“工作組”。當經(jīng)常組合使用人力資源和系統(tǒng)資源時，定義系統(tǒng)資源的聚合，以及人力資源和系統(tǒng)資源的混合體(mixed bag)是有益的。例如，記帳過程需要由會計部門的成員和公司結(jié)算系統(tǒng)組成的資源；營救行動需要直升機、飛行員和醫(yī)師。
此外，資源聚合可被嵌套，允許三種基本聚合類型袋子(bag)(無序集合)；序列(有序集合)；和選擇權(quán)(替換物)。如果沒有指定聚合類型，則默認為袋子。當分配復合資源時，袋子的分配將把它包含的所有資源連接到該任務。選擇權(quán)的分配指示將分配該集合中的資源之一；其選擇受可用性、范圍或其它運行時約束條件，但是在資源模型中沒有指示挑選某一特定資源的順序或偏愛。分配序列的語義學和分配選擇權(quán)(將挑選一個資源)的語義學類似，但是，序列預先定義產(chǎn)生該選擇中的某一偏愛或優(yōu)先權(quán)。資源袋的一個例子是工作組；序列的一個例子是依據(jù)成本或速度排序的貨運服務清單；選擇權(quán)的一個例子是公司的一組司機。
<resourceModel>
<resources>
<humanResource name＝″The Hauling Squad″aggregationType＝″bag″>
<！--sameas previous example，but aggregation type made explicit-->
<humanResource name″Al″/>
<humanResource name＝″Bob″/>
<humanResource name＝″Chuck″/>
<humanResource name＝″Dan″/>
</humanResource>
<resource name＝″Shipping Service″aggregationType＝″sequence″>
<resource name＝″The Overnight Express″/>
<resource name＝″The Courier Service″/>
<resource name＝″The Postal Service″/>
</resource>
<humanResource name＝″Limousine Driver″aggregationType＝″choice″>
<humanResource name＝″A.Abrams″/>
<humanResource name＝″B.Baker″/>
<humanResource name＝″C.Chung″/>
</humanResource>
</resources>
</resourceModel>
最后，資源可被組織所有，組織可以是內(nèi)部組織(例如部，部門)或者是企業(yè)外部的組織(例如企業(yè)合作人，外部服務提供者)。但是，模擬這些組織，他們的分層結(jié)構(gòu)，以及他們的資源所有權(quán)在核心模型的范圍之外?？稍诶缬糜谶^程模擬的模型擴展中增加這樣的能力。
角色通過向資源分配角色，描述資源的功能能力，角色被定義成執(zhí)行商業(yè)任務的能力的聚合。在商業(yè)過程的IT實現(xiàn)中，角色被頻繁用于表示執(zhí)行商業(yè)功能的授權(quán)或許可。在基于BOpS的企業(yè)安全模型中，可按照這種方式延伸這里提出的角色概念。對資源的角色的分配可被劃分范圍(scoped)，這種情況下，資源的扮演角色的能力未關(guān)于所有任務實例得到普遍準許，相反取決于手邊的任務。例如，汽車制造商定義采購代理商的公司導購。導購的工作是確保生產(chǎn)資料的購買合同符合公司的采購策略。在公司采購過程中，該角色會聚合“批準空白定單”，“改變供應商評級”和“設置供應商份額限制”的能力。但是，具有導購角色的雇員實際是否執(zhí)行這些任務取決于購買的材料的類型(其所謂的日用品類型)以及供應商的地理位置。從而，依據(jù)供應商位置和日用品類型，劃分導購角色的范圍。這種劃分范圍的導購角色的例子是“從美國供應商購買的輪胎的導購”，“從德國供應商購買的任意類別的材料的導購”或者“減震器的全球?qū)з彙薄?br> <resourceModel>
<！--Declaring the lead buyer role-->
<roles>
<role name＝″lead buyer″/>
</roles>
<！--Dcclaring a Lead Buyer，and down-scoping her lead buyer role-->
<resurces>
<resource name＝″Patricia Goldman″>
<roles>
<role name＝″lead buyer″>
<scope name＝″commodity type″value＝″tires″/>
<scope name＝″supplier location″value＝″United States″/>
</role>
</roles>
</resource>
</resources>
</resourceModel>
在BOpS中，范圍被模擬成分配給資源的角色的名值對。他們下劃分(“down-scope”)資源的角色。范圍名稱定義范圍的領(lǐng)域(例子是日用品類型，供應商位置，銷售區(qū)域，客戶狀態(tài))，范圍值定義該領(lǐng)域內(nèi)，范圍的限制(例如，日用品類型＝64，供應商位置＝德國，銷售區(qū)域＝EMEA，客戶狀態(tài)＝高級，...)。下劃分分配給資源的角色-稱為資源限定-隱含要求關(guān)于要求這種范圍受限角色的每項任務定義“劃分(scoping)算法”它必須把任務的每個實例映射到關(guān)于它所需角色定義的不同范圍領(lǐng)域中。
在上面的例子中，汽車制造商的采購過程包括將由導購執(zhí)行的合同批準任務。該任務具有相關(guān)的劃分算法，該算法確定每個合同的適用的日用品類型和供應商位置。這將涉及分析合同，并查尋定購的生產(chǎn)資料的每個冊列項目的日用品類型。它還涉及在供應商數(shù)據(jù)庫中查尋供應商的地理位置。
如果從相同領(lǐng)域分配數(shù)個范圍，則作為結(jié)果的范圍是他們的聯(lián)合。在依據(jù)領(lǐng)域形成范圍的聯(lián)合之后，總的范圍被定義成跨越領(lǐng)域的笛卡爾產(chǎn)物。從而，例如，其范圍被定義成(銷售區(qū)域＝德國，銷售區(qū)域＝奧地利，銷售區(qū)域＝瑞士)的銷售代理負責這三個講德語的國家(三個范圍的聯(lián)合)。其范圍被定義成(日用品類型＝燈泡，日用品類型＝刮片，供應商位置＝德克薩斯州，供應商位置＝亞利桑那州，供應商位置＝新墨西哥州)的導購負責從位于這三個州的供應商購買燈泡和刮片(聯(lián)合的笛卡爾產(chǎn)物)。
<resoureeModel>
<roles>
<role name＝″sales agent″/>
<role name＝″lead buyer″/>
</roles>
<resources>
<resource name＝″Sales Agent Germany and Alpine Countries″>
<roles>
<role name＝″sales agent″>
<scope name＝″sales region″value＝″Germany″>
<scope name＝″sales region″value＝″Austria″/>
<scope name＝″sales region″vulue＝″Switzerland″/>
</role>
</roles>
</resource>
<resource name＝″Lead Buyer 007″>
<roles>
<role name＝″lead buyer″>
<scope name＝″commodity type″value＝″light bulbs″/>
<scope name＝″commodity type″ value＝″wiper blades″/>
<scope name＝″supplier location″value＝″Texas″/>
<scope name＝″supplier location″value＝″Arizona″/>
<scope name＝″supplier location″value＝″New Mcxico″/>
</role>
</roles>
</resource>
</resources>
</resourceModel>
國家的各州)，公司單位(公司組內(nèi)各個部門內(nèi)的各部)，或者產(chǎn)品的類別。把范圍定義成這種結(jié)構(gòu)中的一個節(jié)點等同于將其定義成一組全部從屬葉子。從而，例如電子設備制造商定義銷售主管角色，從而銷售主管負責某一地理區(qū)域。分層構(gòu)成公司的銷售區(qū)域，地理區(qū)域(北美，拉美，EMEA，亞太)位于頂層，單個國家位于下一層，國家內(nèi)的州或省位于最下層。
為了用文件證明范圍領(lǐng)域的分層結(jié)構(gòu)，或者為了列舉所有可能的范圍值，可把一組許可的范圍值宣稱為角色定義的一部分。如果存在這樣的“范圍”聲明，則資源資格的范圍限制必定是這樣聲明的范圍的子集。例如，航空公司定義客戶服務代表角色，其范圍由客戶狀態(tài)限定?？蛻舴沾淼慕巧x列舉銀、金和白金作為客戶狀態(tài)的三種可能范圍值。從而，宣稱客戶狀態(tài)＝None或客戶狀態(tài)＝All的客戶服務代表會是一個錯誤。如果在客戶服務代表角色下沒有宣稱任何范圍值，則關(guān)于客戶狀態(tài)的任何值應是許可的。在下面的XML例子中還表示了上面介紹的，依據(jù)地理區(qū)域劃分范圍的銷售主管角色。角色宣稱包括公司的銷售區(qū)域的分層結(jié)構(gòu)。
約束模型約束模型描述對于語義上有效的BOpS模型，必須被滿足的約束條件。它反映模型的操作語義學。約束有兩種類型1)元數(shù)據(jù)約束，它是需要高于模式約束條件規(guī)定的語義約束條件。這些是模式層約束條件(但是不能由模式指定)，通常與所有實例文檔有關(guān)；2)模型約束，它是實例文檔特有的語義約束條件。這些約束條件反映需要被評估，以便使模型有效的商業(yè)規(guī)則/邏輯。
雖然關(guān)于本發(fā)明的例證實施例，具體表示和說明了本發(fā)明，不過對本領(lǐng)域的技術(shù)人員來說，在不脫離本發(fā)明的精神和范圍的情況下，可做出形式和細節(jié)方面的前述及其它變化，本發(fā)明的精神和范圍只由附加的權(quán)利要求限定。
權(quán)利要求
1.一種產(chǎn)生并管理商業(yè)過程集成解決方案的系統(tǒng)，包括根據(jù)實體的定義的商業(yè)目的和目標，對商業(yè)策略建模的裝置，所述商業(yè)策略包括代表商業(yè)度量和主動性的要素；用包括過程任務、工件流和工件庫的商業(yè)過程要素，對所述實體的商業(yè)操作建模的裝置，所述商業(yè)過程要素包含關(guān)鍵性能指標；和用操作模型的工件和過程要素映射策略模型的要素的數(shù)據(jù)結(jié)構(gòu)裝置，測量商業(yè)性能并比較性能和所述關(guān)鍵性能指標的裝置，其中由于過程度量和比較的結(jié)果，在解決方案開發(fā)周期內(nèi)，可持續(xù)改進所述商業(yè)策略和操作模型過程要素。
2.按照權(quán)利要求1所述的系統(tǒng)，還包括把操作模型要素轉(zhuǎn)換成獨立于平臺的信息技術(shù)(IT)可執(zhí)行解決方案模型的裝置，所述可執(zhí)行的解決方案模型包括商業(yè)解決方案工件。
3.按照權(quán)利要求2所述的系統(tǒng)，其中解決方案工件包括代表商業(yè)文檔或材料、合同或工作產(chǎn)物的商業(yè)對象。
4.按照權(quán)利要求2所述的系統(tǒng)，其中解決方案工件包括捕捉和狀態(tài)相關(guān)的行為的自適應商業(yè)對象。
5.按照權(quán)利要求2所述的系統(tǒng)，其中解決方案工件包括代表可中斷的過程流的宏流，和代表不可中斷的過程流的微流。
6.按照權(quán)利要求2所述的系統(tǒng)，其中解決方案工件包括轉(zhuǎn)換數(shù)據(jù)，并與應用軟件接口的應用適配器。
7.按照權(quán)利要求2所述的系統(tǒng)，其中解決方案工件包括轉(zhuǎn)換數(shù)據(jù)，并與外部商業(yè)系統(tǒng)接口的企業(yè)-企業(yè)連接器。
8.按照權(quán)利要求2所述的系統(tǒng)，其中解決方案工件包括使用戶能夠與解決方案相互作用的入口工件。
9.按照權(quán)利要求2所述的系統(tǒng)，還包括按照使所述解決方案工件可綁定或部署到一個或多個具體的運行時平臺的方式，定義一個或多個所述IT解決方案工件的細節(jié)的裝置。
10.按照權(quán)利要求2所述的系統(tǒng)，其中所述變換裝置把所述關(guān)鍵性能指標變換成IT可執(zhí)行解決方案模型中的IT探測器，所述探測器實時監(jiān)視和報告由在操作模型中定義的所述關(guān)鍵性能指標測量的商業(yè)過程性能。
11.按照權(quán)利要求1所述的系統(tǒng)，還包括推薦或?qū)崿F(xiàn)對商業(yè)過程的改變，以便在所述商業(yè)測量裝置看來改進其性能的裝置。
12.按照權(quán)利要求1所述的系統(tǒng)，其中所述測量和比較商業(yè)性能的裝置包括至少在策略、操作、執(zhí)行和實現(xiàn)模型之一中實現(xiàn)模擬模型的模擬裝置。
13.按照權(quán)利要求1所述的系統(tǒng)，其中對所述實體的商業(yè)操作建模的所述裝置包括實現(xiàn)正規(guī)表現(xiàn)所述商業(yè)操作的商業(yè)級建模語言。
14.按照權(quán)利要求1所述的系統(tǒng)，其中正規(guī)表現(xiàn)所述商業(yè)操作的所述商業(yè)級建模語言按照某一模式對商業(yè)操作建模。
15.按照權(quán)利要求14所述的系統(tǒng)，其中所述模式代表包括與所述商業(yè)實體的操作觀點有關(guān)的工件和商業(yè)事件的信息模型。
16.按照權(quán)利要求1所述的系統(tǒng)，其中所述模式表示包括過程、任務、工件庫和他們的互連的商業(yè)功能。
17.按照權(quán)利要求1所述的系統(tǒng)，其中所述模式表示包括角色和資源組的資源。
18.一種產(chǎn)生和管理商業(yè)過程集成解決方案的方法，包括a)根據(jù)實體的定義的商業(yè)目的和目標，對商業(yè)策略建模，所述商業(yè)策略包括表現(xiàn)商業(yè)度量和主動性的要素；b)用包括過程任務、工件流和工件庫的商業(yè)過程要素，和包括合并關(guān)鍵性能指標的商業(yè)承諾要素，對所述實體的商業(yè)操作建模；c)用操作模型的工件和過程要素映射策略模型的要素；和d)測量商業(yè)性能并比較性能度量和所述關(guān)鍵性能指標，其中由于過程度量和比較的結(jié)果，在解決方案開發(fā)周期內(nèi)，可持續(xù)改進所述商業(yè)策略和操作模型過程要素。
19.按照權(quán)利要求18所述的方法，還包括把操作模型要素轉(zhuǎn)換成獨立于平臺的信息技術(shù)(IT)解決方案模型的步驟，所述解決方案模型包括商業(yè)解決方案工件。
20.按照權(quán)利要求19所述的方法，其中解決方案工件包括從下述組中選出的一個或多個商業(yè)對象、自適應商業(yè)對象、宏流、微流、應用適配器、企業(yè)-企業(yè)連接器和入口工件。
21.按照權(quán)利要求19所述的方法，還包括定義一個或多個所述IT解決方案工件的細節(jié)，把所述解決方案工件綁定或部署到一個或多個具體的運行時平臺的步驟。
22.按照權(quán)利要求21所述的方法，還包括下述步驟把所述關(guān)鍵性能指標變換成IT可執(zhí)行解決方案模型中的IT探測器，所述探測器能夠?qū)崿F(xiàn)由定義的所述關(guān)鍵性能指標測量的商業(yè)過程性能的實時監(jiān)視和報告。
23.按照權(quán)利要求22所述的方法，還包括推薦或?qū)崿F(xiàn)對商業(yè)過程的改變，以便從所述監(jiān)視看來改進其性能的步驟。
24.按照權(quán)利要求19所述的方法，還包括實現(xiàn)正規(guī)表現(xiàn)所述商業(yè)操作的商業(yè)級建模語言，所述商業(yè)操作的所述表現(xiàn)根據(jù)某一模式對商業(yè)操作建模。
25.一種包含多個指令的計算機存儲設備，所述多個指令實現(xiàn)產(chǎn)生并管理商業(yè)過程集成解決方案的方法，所述方法包括下述步驟a)根據(jù)實體的定義的商業(yè)目的和目標，對商業(yè)策略建模，所述商業(yè)策略包括表現(xiàn)商業(yè)度量和主動性的要素；b)用包括過程任務、工件流和工件庫的商業(yè)過程要素，和包括合并關(guān)鍵性能指標的商業(yè)承諾要素，對所述實體的商業(yè)操作建模；c)用操作模型的工件和過程要素映射策略模型的要素；和d)測量商業(yè)性能并比較性能度量和所述關(guān)鍵性能指標，其中由于過程度量和比較的結(jié)果，在解決方案開發(fā)周期內(nèi)，可持續(xù)改進所述商業(yè)策略和操作模型過程要素。
全文摘要
產(chǎn)生并管理商業(yè)過程集成解決方案的系統(tǒng)和方法包括根據(jù)實體的定義的商業(yè)目的和目標，對商業(yè)策略建模，所述商業(yè)策略包括表現(xiàn)商業(yè)度量和主動性的要素；用包括過程任務、工件流和工件庫的商業(yè)過程要素，和包括合并關(guān)鍵性能指標的商業(yè)承諾要素，對所述實體的商業(yè)操作建模；用操作模型的工件和過程要素映射策略模型的要素；測量商業(yè)性能并比較性能度量和所述關(guān)鍵性能指標。由于過程度量和比較的結(jié)果，在解決方案開發(fā)周期內(nèi)，可持續(xù)改進所述商業(yè)策略和操作模型過程要素。還實現(xiàn)一種商業(yè)級建模語言，以便正規(guī)表示商業(yè)操作。
文檔編號G06Q10/00GK1629869SQ20041008611
公開日2005年6月22日 申請日期2004年10月19日 優(yōu)先權(quán)日2003年10月24日
發(fā)明者庫瑪·巴斯卡拉恩, 斯蒂芬·J·巴克里, 內(nèi)森·S·卡斯維爾, 張鴻洋, 卓阿奇姆·H·弗蘭克, 萊納·F·豪瑟, 黃瑩, 舒伯爾·卡珀, 佳納·克勒, 桑索施·庫瑪拉恩, 布拉博·南迪, 艾尼爾·尼加姆, 田忠, 王健, 弗雷德里克·Y·吳, 朱俊 申請人:國際商業(yè)機器公司