專利名稱：一種信息系統(tǒng)的構(gòu)建平臺系統(tǒng)及其方法
技術(shù)領(lǐng)域：
本發(fā)明涉及使用計算機(jī)進(jìn)行業(yè)務(wù)管理的系統(tǒng)和方法，尤其涉及一種構(gòu)建計算 機(jī)管理信息系統(tǒng)(數(shù)字神經(jīng)系統(tǒng))的軟件平臺系統(tǒng)及其實現(xiàn)方法。
背景技術(shù)：
進(jìn)入21世紀(jì)的企業(yè)，處于快速變化的環(huán)境中，信息系統(tǒng)必須提供必要的技術(shù)
來滿足企業(yè)發(fā)展、法規(guī)遵從等要求，并提供更廣泛的服務(wù)。但是，在當(dāng)前的軟件架
構(gòu)下，IT團(tuán)隊始終處于被動狀態(tài)，面臨的挑戰(zhàn)日益嚴(yán)峻，在滿足不斷變化的業(yè)務(wù) 需求與不能實現(xiàn)隨需應(yīng)變的信息系統(tǒng)之間，存在著越來越大的差距。
企業(yè)IT系統(tǒng)當(dāng)前面臨的問題是，沒有針對它的一套架構(gòu)方法，產(chǎn)品孤島之間 的數(shù)據(jù)使用不一致，無法實現(xiàn)客戶的單一視圖。渠道集成或"客戶接觸點"集成可 能引起包括高度的復(fù)雜性、高昂的成本，缺乏足夠的靈活性及可擴(kuò)展性等諸多問題。
目前的信息系統(tǒng)如圖l所示，這種信息系統(tǒng)的架構(gòu)具有以下的特點(l)各
個應(yīng)用單獨(dú)開發(fā)，各自為政，其數(shù)據(jù)庫也單獨(dú)設(shè)計，形成一個個信息孤島。(2)
開發(fā)各個應(yīng)用所采用的理念、方法、技術(shù)不一樣，沒有考慮應(yīng)用間流程的集成和交
互，沒有統(tǒng)一的接口。 (3)每個應(yīng)用都有自己的用戶管理和安全控制機(jī)制，沒有 統(tǒng)一的門戶。(4)缺少全面的管理控制功能。(5)應(yīng)用的業(yè)務(wù)流程大都是硬編 碼程序，應(yīng)變能力差。
基于上述架構(gòu)的信息系統(tǒng)，必然存在以下的缺陷(1)每個應(yīng)用各自為政， 形成一個個信息孤島，應(yīng)用和業(yè)務(wù)流程的無縫集成很難實現(xiàn)。(2)系統(tǒng)結(jié)構(gòu)和功
能僵化，應(yīng)變能力差，無法快速應(yīng)對變化，需要不斷投入人力物力進(jìn)行系統(tǒng)改造和
升級，甚至推倒重來。(3)缺少幫助業(yè)務(wù)人員進(jìn)行業(yè)務(wù)創(chuàng)新和管理創(chuàng)新的技術(shù)手 段。(4)缺乏統(tǒng)一的系統(tǒng)門戶，業(yè)務(wù)人員疲于應(yīng)付，工作效率低下。(5)隨著應(yīng) 用的增多，管理的復(fù)雜度增加，管理和安全存在失控的危險。
鑒于目前的IT架構(gòu)存在的問題，后來提出了面向服務(wù)的架構(gòu)(Service-Oriented Architecture, SOA) 。 SOA是基于標(biāo)準(zhǔn)的、松散耦合的面向 服務(wù)的架構(gòu)?；赪eb服務(wù)的SOA架構(gòu)與過去不同的特點就在于它們是基于標(biāo)準(zhǔn)以 及松散耦合的。廣泛接受的標(biāo)準(zhǔn)(如XML和SOAP)提供了在各不同廠商解決方案 之間的交互性。而松散耦合將分布計算中的參與者隔離開來，交互兩邊某一方的改 動并不會影響到另一方。這兩者的結(jié)合意味著公司可以實現(xiàn)某些Web services而 不用對使用這些Web services的客戶端的知識有任何了解。但是目前的實現(xiàn)方法 是在現(xiàn)有的各個應(yīng)用各自為政的IT架構(gòu)的基礎(chǔ)上，添加SOA的組件，以期取得良 好的效果。
在滿足用戶的業(yè)務(wù)需求方面，工作流管理系統(tǒng)不必事先之道問題域的相關(guān)信 息，而是將業(yè)務(wù)流程描述作為輸入并管理流程實例的執(zhí)行。目前的業(yè)務(wù)流程建模技 術(shù)存在以下的不足(1)對業(yè)務(wù)流程中活動之間的關(guān)系的分析不全面，基本劃分 成串行關(guān)系和并行關(guān)系二類(分支、循環(huán)、子流程等關(guān)系本質(zhì)上都可歸于這二類)， 導(dǎo)致無法對復(fù)雜的業(yè)務(wù)和管理活動建模。(2)建模元素的設(shè)置不合理，建模元素 過多，用戶不易理解。例如，將事件與活動分開，而活動中卻也可以包含事件。將 活動之間的某些關(guān)系或路徑用專門的元素來表示(如branch, Fork、 Join、 Merge 等元素)，而它們中的大多數(shù)本來是可以直接用活動之間的連接線來直觀表示的。 (3)以流程(Process)為管理單位，管理粒度太大，無法實現(xiàn)層次化精細(xì)化的管 理，也無法實現(xiàn)自動流程與人工流程的完美結(jié)合。(4)無法表達(dá)復(fù)雜的業(yè)務(wù)流程， 建立的流程模型一般不能直接運(yùn)行， 一部分需要靠編程實現(xiàn)。(5)現(xiàn)在的業(yè)務(wù)建 模還離不開技術(shù)，不懂軟件技術(shù)的一般用戶無法定義，因此項目的實施離不開技術(shù) 人員。(6)業(yè)務(wù)流程實現(xiàn)時所作的變動使之無法與定義的業(yè)務(wù)流程模型保持同步。 由于以上的缺陷，導(dǎo)致目前的工作流管理系統(tǒng)還存在許多的不足，無法取代現(xiàn)有的 應(yīng)用系統(tǒng)，只能作為現(xiàn)有應(yīng)用系統(tǒng)的補(bǔ)充。

發(fā)明內(nèi)容
本發(fā)明的目的在于解決上述問題，提供了一種信息系統(tǒng)的構(gòu)建平臺系統(tǒng)，能 更好的滿足企業(yè)信息系統(tǒng)建設(shè)的需求，更能適應(yīng)未來的變化，成為隨需應(yīng)變的信息 系統(tǒng)。
本發(fā)明的另一目的在于提供了一種通過上述的構(gòu)建平臺系統(tǒng)進(jìn)行業(yè)務(wù)處理的方法。這種以業(yè)務(wù)(任務(wù))為中心的模式可以大大簡化甚至取消傳統(tǒng)的固定的組織
結(jié)構(gòu)，形成靈活的、以任務(wù)為中心的組織結(jié)構(gòu)，有助于改善現(xiàn)有組織結(jié)構(gòu)總是跟不
上實際需要的情形，使組織反應(yīng)迅速，增強(qiáng)組織的應(yīng)變能力。
本發(fā)明的技術(shù)方案為本發(fā)明揭示了一種信息系統(tǒng)的構(gòu)建平臺系統(tǒng)，包括 用戶接口層模塊，提供用戶登錄系統(tǒng)的入口，包含用于支持客戶端設(shè)備的用
戶接口適配器；
數(shù)據(jù)服務(wù)層模塊，以WEB服務(wù)的形式提供對數(shù)據(jù)庫的訪問，通過集中統(tǒng)一地 管理所有數(shù)據(jù)來消除信息孤島；
業(yè)務(wù)流程層模塊，面向數(shù)據(jù)服務(wù)層的WEB服務(wù)，通過以業(yè)務(wù)為組成單元的建 模方式定義和實現(xiàn)業(yè)務(wù)流程，通過與自己分離解耦的數(shù)據(jù)服務(wù)層訪問數(shù)據(jù)庫。
上述的信息系統(tǒng)的構(gòu)建平臺系統(tǒng)，其中，該用戶接口層模塊包括一顯示代碼 配置單元，接收用戶設(shè)定的配置參數(shù)自動生成顯示代碼。
本發(fā)明還揭示了一種通過上述的信息系統(tǒng)的構(gòu)建平臺系統(tǒng)進(jìn)行業(yè)務(wù)處理的方 法，包括
(1) 建立業(yè)務(wù)數(shù)據(jù)庫和數(shù)據(jù)訪問服務(wù)層；
(2) 接收用戶管理信息的定義并保存在平臺系統(tǒng)的數(shù)據(jù)庫中，并為角色分配
權(quán)限；
(3) 接收對訪問業(yè)務(wù)數(shù)據(jù)庫的WEB服務(wù)的定義并保存在平臺系統(tǒng)的數(shù)據(jù)庫
中；
(4) 接收任務(wù)定義并保存在平臺系統(tǒng)的數(shù)據(jù)庫中，定義的任務(wù)是一個自包含 的對象，任務(wù)既包含業(yè)務(wù)流程同時又是業(yè)務(wù)流程的組成單元，任務(wù)是可重用的業(yè)務(wù) 建模單元也是可單獨(dú)執(zhí)行和單獨(dú)管理的業(yè)務(wù)單元，而且任務(wù)包括任務(wù)屬性、任務(wù)的 輸入信息和正文信息、任務(wù)的分解結(jié)構(gòu)、任務(wù)調(diào)用的WEB服務(wù)、任務(wù)發(fā)送的郵件 要素；
(5) 在接收到任務(wù)產(chǎn)生請求后，根據(jù)定義的任務(wù)屬性產(chǎn)生任務(wù)實例，并從有 權(quán)執(zhí)行本任務(wù)的用戶列表中選擇任務(wù)的接收者，產(chǎn)生任務(wù)后同時修改任務(wù)實例的任 務(wù)關(guān)系。
上述的通過信息系統(tǒng)的構(gòu)建平臺系統(tǒng)進(jìn)行業(yè)務(wù)處理的方法，其特征在于，步 驟(4)進(jìn)一步包括(4.1) 定義任務(wù)輸入信息和任務(wù)正文信息以及兩者之間的信息映射；
(4.2) 指定任務(wù)調(diào)用的WEB服務(wù)；
(4.3) 定義任務(wù)關(guān)系，任務(wù)關(guān)系即業(yè)務(wù)流程，任務(wù)之間的關(guān)系包括父子關(guān)系、 前后關(guān)系、并列關(guān)系三種；
(4.4) 定義任務(wù)接口，任務(wù)接口分為用于接收產(chǎn)生任務(wù)實例的指令的輸入接 口和用于發(fā)送產(chǎn)生任務(wù)實例的指令的輸出接口；
(4.5) 定義任務(wù)關(guān)系建模的元模型；
(4.6) 指定任務(wù)關(guān)系中任務(wù)節(jié)點的類型，任務(wù)節(jié)點的類型分為正常型、永久 型、多實例型、重復(fù)型和臨時型；
(4.7) 指定任務(wù)間的信息映射，為每對有產(chǎn)生關(guān)系的任務(wù)間指定信息映射關(guān)
系；
上述的通過信息系統(tǒng)的構(gòu)建平臺系統(tǒng)進(jìn)行業(yè)務(wù)處理的方法，其特征在于，步 驟(4.1)的任務(wù)輸入信息和任務(wù)正文信息用XML信息結(jié)構(gòu)表示，兩者之間的信息 映射用XML格式來保存。
上述的通過信息系統(tǒng)的構(gòu)建平臺系統(tǒng)進(jìn)行業(yè)務(wù)處理的方法，其特征在于，步 驟(4.2)還包括分別指定任務(wù)正文信息與WEB服務(wù)的輸入?yún)?shù)和輸出參數(shù)之間的 信息映射。
上述的通過信息系統(tǒng)的構(gòu)建平臺系統(tǒng)進(jìn)行業(yè)務(wù)處理的方法，其特征在于，步 驟(4.7)中指定的信息映射關(guān)系通過圖形界面實現(xiàn)。
上述的通過信息系統(tǒng)的構(gòu)建平臺系統(tǒng)進(jìn)行業(yè)務(wù)處理的方法，其特征在于，步 驟(2)和步驟(3)之間還包括
接收元素類型的定義，并將其保存在平臺系統(tǒng)的數(shù)據(jù)庫中，其中元素用于組 成任務(wù)的正文信息結(jié)構(gòu)。
上述的通過信息系統(tǒng)的構(gòu)建平臺系統(tǒng)進(jìn)行業(yè)務(wù)處理的方法，其特征在于，步 驟(5)之后還包括
(6) 根據(jù)任務(wù)定義的任務(wù)正文信息架構(gòu)、任務(wù)正文信息和顯示格式來顯示任 務(wù)的信息；
(7) 接收用戶對任務(wù)的操作，調(diào)用該操作對應(yīng)的WEB服務(wù)以訪問業(yè)務(wù)數(shù)據(jù) 庫，這些操作包括退回、委托、開始、執(zhí)行、結(jié)束、追回。上述的通過信息系統(tǒng)的構(gòu)建平臺系統(tǒng)進(jìn)行業(yè)務(wù)處理的方法，其特征在于，步 驟(7)之后還包括
(8)接收用戶對任務(wù)的管理，包括顯示任務(wù)、取消任務(wù)、修改任務(wù)實例關(guān)系、 指定共享用戶和角色、改變?nèi)蝿?wù)的用戶。
本發(fā)明對比現(xiàn)有技術(shù)有如下的有益效果本發(fā)明通過完全基于S0A的三層體 系結(jié)構(gòu)用戶接口層模塊、數(shù)據(jù)服務(wù)層模塊以及業(yè)務(wù)流程層模塊，數(shù)據(jù)集中統(tǒng)一管 理，消除了信息孤島。而且數(shù)據(jù)服務(wù)層模塊和業(yè)務(wù)流程層模塊完全分離并解耦，增
加了系統(tǒng)的適應(yīng)性和靈活性。本發(fā)明還基于XML和WEB服務(wù)技術(shù)，通過WEB服務(wù)訪 問應(yīng)用數(shù)據(jù)庫。本發(fā)明的系統(tǒng)以任務(wù)為組成單元，每一級任務(wù)都有一定的自主性， 使得信息系統(tǒng)的建設(shè)擺脫了對技術(shù)人員的依賴，信息系統(tǒng)的建設(shè)完全由用戶主導(dǎo)， 可實現(xiàn)用戶想要的任何業(yè)務(wù)流程。所有員工共同參與，而且大大簡化了IT基礎(chǔ)架 構(gòu)，使得使用和維護(hù)簡單， 一般業(yè)務(wù)人員就能勝任大部分工作。


圖1是傳統(tǒng)的信息系統(tǒng)的架構(gòu)示意圖。
圖2是本發(fā)明的信息系統(tǒng)的構(gòu)建平臺系統(tǒng)的較佳實施例的架構(gòu)示意圖。 圖3是本發(fā)明的通過上述的信息系統(tǒng)的構(gòu)建平臺系統(tǒng)進(jìn)行業(yè)務(wù)處理的方法的 較佳實施例的流程示意圖。
圖4是圖3實施例中定義任務(wù)步驟的子流程圖。
圖5是本發(fā)明的一個示例BUG管理系統(tǒng)的BUG狀態(tài)變化圖。
圖6是BUG管理系統(tǒng)的BUG業(yè)務(wù)流程圖。
圖7是BUG管理系統(tǒng)的編程管理業(yè)務(wù)流程圖。
圖8是BUG管理系統(tǒng)的開發(fā)管理業(yè)務(wù)流程圖。
圖9是業(yè)務(wù)建模的圖形元素的示意圖。
具體實施例方式
下面結(jié)合附圖和實施例對本發(fā)明作進(jìn)一步的描述。
本發(fā)明的信息系統(tǒng)的構(gòu)建平臺系統(tǒng)是一種基于S0A架構(gòu)的以業(yè)務(wù)為中心的企 業(yè)信息系統(tǒng)平臺，集業(yè)務(wù)、管理、交流和協(xié)作為一體。這種構(gòu)建平臺系統(tǒng)能實現(xiàn)各種業(yè)務(wù)流程，集成所有的應(yīng)用和服務(wù)，讓所有人協(xié)同工作，并能適應(yīng)環(huán)境的不斷變 化。因此，這種構(gòu)建平臺系統(tǒng)是一個以人為本的數(shù)字神經(jīng)系統(tǒng)平臺，組織中的任何 人，只要進(jìn)入這個系統(tǒng)，就能參與任何項目，獲取任何信息，完成任何業(yè)務(wù)。 信息系統(tǒng)的構(gòu)建平臺系統(tǒng)的實施例
圖2示出了本發(fā)明的構(gòu)建平臺系統(tǒng)的一個實施例的架構(gòu)。請參見圖2，本實施 例的構(gòu)建平臺系統(tǒng)分為三大層用戶接口 (UI)層模塊IO、業(yè)務(wù)流程層模塊12和 數(shù)據(jù)服務(wù)層模塊14。對于用戶接口層模塊10來說，提供用戶登錄整個系統(tǒng)的入口， 包含支持各種UI設(shè)備的適配器(Adaptor)，可支持WEB瀏覽器、移動終端等各種 客戶端設(shè)備。較佳的，用戶接口層模塊10還包括顯示代碼配置單元100，接收用 戶設(shè)定的配置參數(shù)自動生成顯示代碼，消除了開發(fā)顯示程序的需要。對于數(shù)據(jù)服務(wù) 層模塊12，與業(yè)務(wù)流程層模塊12徹底分離，以WEB服務(wù)的形式提供對數(shù)據(jù)庫16 的訪問，通過集中地統(tǒng)一地管理所有數(shù)據(jù)來消除信息孤島。對于業(yè)務(wù)流程層模塊 12，通過以業(yè)務(wù)為組成單元的建模方式來定義和實現(xiàn)業(yè)務(wù)流程，通過數(shù)據(jù)服務(wù)層模 塊14來訪問數(shù)據(jù)庫16。以上的用戶接口層模塊10、業(yè)務(wù)流程層模塊12和數(shù)據(jù)服 務(wù)層模塊14相互獨(dú)立，各層模塊的變化不會影響要其他的層次，這使得各層模塊 可以單獨(dú)改變。由于業(yè)務(wù)流程層模塊14完全是面向數(shù)據(jù)服務(wù)層模塊14的WEB服務(wù) 的，因此對整個構(gòu)建平臺系統(tǒng)而言，是真正面向SOA架構(gòu)的系統(tǒng)。
數(shù)據(jù)服務(wù)層模塊14不用考慮業(yè)務(wù)流程的實現(xiàn)，從全局著手，按企業(yè)業(yè)務(wù)數(shù)據(jù) 需求和數(shù)據(jù)本身應(yīng)有的結(jié)構(gòu)和關(guān)系來設(shè)計，對數(shù)據(jù)的訪問以WEB服務(wù)的方式提供， 同時保證數(shù)據(jù)的完整性和一致性。這提供了以下的優(yōu)點由于不用考慮業(yè)務(wù)流程的 實現(xiàn)，因此開發(fā)變得更為容易和穩(wěn)定；由于與業(yè)務(wù)流程分離，因此不會受到對方變 化的影響；由于數(shù)據(jù)服務(wù)層模塊14可以供業(yè)務(wù)流程層模塊12中的任何業(yè)務(wù)流程訪 問，輕易實現(xiàn)數(shù)據(jù)的共享和集中統(tǒng)一管理。
業(yè)務(wù)流程層模塊12定義和實現(xiàn)各種業(yè)務(wù)流程，以及各種業(yè)務(wù)之間或者跨系統(tǒng) 業(yè)務(wù)之間的集成。負(fù)責(zé)整個構(gòu)建系統(tǒng)的管理、控制、交流和協(xié)作。在業(yè)務(wù)流程層模 塊12還植入了安全機(jī)制，任何人只能訪問已授權(quán)的業(yè)務(wù)和數(shù)據(jù)。
對于本發(fā)明實施例的構(gòu)建平臺系統(tǒng)來說，類似于一個地球架構(gòu)。數(shù)據(jù)庫類似 于地球的地核，保存數(shù)據(jù)。數(shù)據(jù)服務(wù)層模塊14類似于地幔，充當(dāng)對數(shù)據(jù)庫訪問的 門戶，而且將數(shù)據(jù)庫和業(yè)務(wù)流程層模塊12隔離解耦。業(yè)務(wù)流程層模塊12類似于地幔之上的生物圈，各種業(yè)務(wù)相當(dāng)于生物圈內(nèi)的各種生物群落。用戶接口層模塊io
相當(dāng)于用戶登錄系統(tǒng)的一個端口。
通過信息系統(tǒng)的構(gòu)建平臺系統(tǒng)進(jìn)行業(yè)務(wù)處理的方法的實施例
圖3示出了本發(fā)明的通過上述的信息系統(tǒng)的構(gòu)建平臺系統(tǒng)進(jìn)行業(yè)務(wù)處理的方 法的較佳實施例的流程。
第一步是建立業(yè)務(wù)數(shù)據(jù)庫和訪問該業(yè)務(wù)數(shù)據(jù)庫的數(shù)據(jù)訪問服務(wù)層(DAS)，這 一步是在系統(tǒng)之外實現(xiàn)的。
第二步是接收用戶管理信息的定義并保存在構(gòu)建平臺系統(tǒng)的數(shù)據(jù)庫中，同時 為角色分配權(quán)限(對應(yīng)圖3的步驟①)。這一步可由構(gòu)建平臺系統(tǒng)中的用戶管理子 模塊來實現(xiàn)，具體包括定義組織結(jié)構(gòu)，包括公司、機(jī)構(gòu)和部門；定義角色及其對 任務(wù)的執(zhí)行權(quán)限；定義用戶信息以及為用戶分配角色。而定義好的這些組織結(jié)構(gòu)、 角色以及用戶信息都保存在數(shù)據(jù)庫中。 一般而言，為角色分配的權(quán)限包括任務(wù)的使 用權(quán)限、任務(wù)的執(zhí)行權(quán)限以及任務(wù)的產(chǎn)生權(quán)限，使用權(quán)限是指用戶能否在任務(wù)種類 列表中看到任務(wù)并在定義任務(wù)時使用它，執(zhí)行權(quán)限是指能否接收和執(zhí)行該任務(wù)種 類，產(chǎn)生權(quán)限是指能否直接產(chǎn)生該任務(wù)的實例。
第三步是接收元素類型的定義并將其保存在構(gòu)建平臺系統(tǒng)的數(shù)據(jù)庫中，元素 用于組成任務(wù)的正文信息結(jié)構(gòu)(對應(yīng)圖3的步驟②)。這一步可由構(gòu)建平臺系統(tǒng)中 的元素定義子模塊來實現(xiàn)，在該構(gòu)建平臺系統(tǒng)中，每個任務(wù)都有它的信息結(jié)構(gòu) (Schema)，而信息結(jié)構(gòu)是由不同類型的元素組成的。因此在定義任務(wù)之前需要先 定義任務(wù)要用到的元素類型，特別是一些任務(wù)要用到的復(fù)雜元素類型。值得注意的 是，這一步驟并不是必須的，在定義任務(wù)信息結(jié)構(gòu)的后續(xù)步驟中也可以直接定義元 素類型，但是只有在本步驟中定義的元素類型才是可以被所有的任務(wù)共享的。定義 好的元素類型用XML Schema格式保存在數(shù)據(jù)庫中。
第四步是接收訪問業(yè)務(wù)數(shù)據(jù)庫的WEB服務(wù)的定義并保存在構(gòu)建平臺系統(tǒng)的數(shù) 據(jù)庫中(對應(yīng)圖3的步驟③)。這一步可由構(gòu)建平臺系統(tǒng)的WEB服務(wù)定義子模塊來 實現(xiàn)。WEB服務(wù)指的是訪問業(yè)務(wù)數(shù)據(jù)庫的服務(wù)，位于數(shù)據(jù)訪問服務(wù)層(DAS)。在 本發(fā)明的構(gòu)建平臺系統(tǒng)中，任務(wù)可能要引用或調(diào)用各種WEB服務(wù)，在定義任務(wù)之前， 先要對這些WEB服務(wù)進(jìn)行定義。這里所謂的定義，就是將網(wǎng)絡(luò)上已經(jīng)存在的WEB服務(wù)登記到構(gòu)建平臺系統(tǒng)中，以供定義任務(wù)時使用。對于非査詢的WEB服務(wù)，應(yīng)該 定義WEB服務(wù)的調(diào)用成功返回碼，以判斷調(diào)用WEB服務(wù)是否成功。通常在定義一個 WEB服務(wù)時會將WEB服務(wù)的所有方法都導(dǎo)入。定義好的WEB服務(wù)也用XML Schema 格式保存在數(shù)據(jù)庫中。
第五步是接收任務(wù)的定義并保存在構(gòu)建平臺系統(tǒng)的數(shù)據(jù)庫中(對應(yīng)圖3的步 驟 )。這一步可由構(gòu)建平臺系統(tǒng)的任務(wù)定義子模塊來實現(xiàn)。
對于業(yè)務(wù)流程的建模方式，本發(fā)明通過以下兩個方面來實現(xiàn)。首先是完全面 向業(yè)務(wù)的建模，構(gòu)建平臺系統(tǒng)將所有的業(yè)務(wù)活動包裝成任務(wù)，因此面向業(yè)務(wù)建模就 是面向任務(wù)建模。這里的任務(wù)是一個自包含的對象，既包含業(yè)務(wù)流程，同時又是業(yè) 務(wù)流程的組成單元。任務(wù)既是可重用的業(yè)務(wù)建模單元，也是可單獨(dú)執(zhí)行和可單獨(dú)管 理的業(yè)務(wù)單元。面向任務(wù)建模的好處有(1)由于任務(wù)封裝了活動的所有細(xì)節(jié)， 大大簡化了業(yè)務(wù)建模的復(fù)雜度；(2)任務(wù)可直接反映和表達(dá)業(yè)務(wù)需求， 一般用戶 都可以理解和操作，不需要技術(shù)人員的參與，這就消除了業(yè)務(wù)需求與軟件實現(xiàn)之間 的鴻溝，能更快更好地滿足用戶的需求；(3)可重用性強(qiáng)，定義好的任務(wù)可以很 容易地放到別的任務(wù)中，就象搭積木一樣；(4)任務(wù)比目前業(yè)界流行的"基于構(gòu) 件開發(fā)"中的構(gòu)件更"軟"和更"輕"，構(gòu)件是物理上存在的程序代碼，需要軟件 開發(fā)人員編程實現(xiàn)，而任務(wù)是用戶就可以定義的對象，因此更容易改變，改變花費(fèi) 的代價更小，更能適應(yīng)業(yè)務(wù)的變化；(5)由于任務(wù)包含了 WEB服務(wù)，用戶可以透 明地訪問網(wǎng)絡(luò)上的WEB服務(wù)，不管它們位于何處，任務(wù)將網(wǎng)絡(luò)上的資源無縫地集成 起來了； (6)由于各種業(yè)務(wù)都是基于相同的單元(任務(wù))構(gòu)建并在同一種平臺上 運(yùn)行，它們之間的"集成"將不會有任何障礙，業(yè)務(wù)流程的集成問題將成為歷史； (7)由于任務(wù)定義后可直接運(yùn)行，因此用戶可隨時改變他們的業(yè)務(wù)流程，系統(tǒng)的 建設(shè)完全由用戶主導(dǎo)。
雖然傳統(tǒng)的業(yè)務(wù)建模方法中也有"任務(wù)"的概念，但是它們的"任務(wù)"與本 發(fā)明的"任務(wù)"有著以下本質(zhì)的區(qū)別(1)傳統(tǒng)的"任務(wù)"與"流程"是不同的 對象，"任務(wù)"是不可再分的原子活動，"任務(wù)"是屬于"流程"或"子流程"的。 而在本發(fā)明的構(gòu)建平臺系統(tǒng)中， 一切活動皆是任務(wù)，"流程"也是任務(wù)，所以，任 何任務(wù)都可屬于任務(wù)，也可包含其它的任務(wù)。構(gòu)建平臺系統(tǒng)中沒有"流程"和"子 流程"對象。(2)傳統(tǒng)的"任務(wù)"與"事件"是分開的，而在構(gòu)建平臺系統(tǒng)中，事件是屬于任務(wù)的，任務(wù)之外并沒有單獨(dú)的事件。(3)傳統(tǒng)的"任務(wù)"簡單，只 是流程圖中的一個節(jié)點，不是可重用的業(yè)務(wù)建模單元。(4)傳統(tǒng)的"任務(wù)"不是 可單獨(dú)管理的業(yè)務(wù)單元，是以"流程"為單位進(jìn)行管理的。(5)傳統(tǒng)的"任務(wù)" 一般不能直接運(yùn)行， 一般需要開發(fā)相對應(yīng)的構(gòu)件或控件才能運(yùn)行。
其次本發(fā)明的業(yè)務(wù)建模是通過模擬生物體細(xì)胞來設(shè)計任務(wù)的。本發(fā)明的構(gòu)建 平臺系統(tǒng)中的任務(wù)包括任務(wù)屬性(如執(zhí)行模式、度量等)、任務(wù)的輸入信息和正文 信息(可包含WEB服務(wù)引用)、任務(wù)的分解結(jié)構(gòu)(任務(wù)關(guān)系)、任務(wù)調(diào)用的WEB 服務(wù)以及任務(wù)發(fā)送的郵件等要素。與生物體細(xì)胞相似，任務(wù)帶有一定的信息，且都 可以分解/分裂為更小的單元或組成更大的單元，而且都可以與其他單元形成一定 的關(guān)系。在構(gòu)建平臺系統(tǒng)中，每個用戶都可以產(chǎn)生任務(wù)。每個任務(wù)可以分解為更小 的任務(wù)，同時又可以是更大的任務(wù)的組成部分，任務(wù)之間有一定的關(guān)系。使用這種 方式能夠構(gòu)建非常復(fù)雜的信息系統(tǒng)，并能高效利用資源、對內(nèi)部和外部的擾動保持 高度的彈性、適應(yīng)所處環(huán)境的變化。而且在這個系統(tǒng)中，每一個組成部分都有一定 程度的自主性，都能夠在沒有上一層組織的協(xié)助下，在其所處的特定層次上掌握環(huán) 境和處理問題。同時也能接受來自上層整體的指導(dǎo)，在某種意義上受上層整體的控 制。自主性保證了部分(小的整體)是穩(wěn)定的，能夠在干擾下生存，而對上層整體 的戚從又確保了更大的整體的有效運(yùn)轉(zhuǎn)。
定義任務(wù)的步驟還可以進(jìn)一步細(xì)分為如圖4所平的子流程。下面結(jié)合圖4對 該步驟進(jìn)行進(jìn)一步的描述。
步驟S50:定義任務(wù)輸入信息和任務(wù)正文信息以及兩者之間的信息映射。一般產(chǎn)生一個任務(wù)時需要輸入一些信息，以讓任務(wù)接收者明白做什么，這稱 為任務(wù)的輸入信息，任務(wù)輸入信息的結(jié)構(gòu)用XML Schema表示。產(chǎn)生任務(wù)時，任務(wù)
輸入信息一般由產(chǎn)生的任務(wù)通過任務(wù)間信息映射輸入，直接產(chǎn)生任務(wù)時則由手工輸 入。
任務(wù)的正文信息即任務(wù)的內(nèi)容，是顯示任務(wù)時看到的信息。任務(wù)正文信息可 能包括任務(wù)產(chǎn)生者輸入的一些信息和任務(wù)接收者輸入的信息。任務(wù)的正文信息中可 包含對WEB服務(wù)的引用。可以對任務(wù)正文信息中的元素定義附加屬性，也稱為用戶 接口屬性，主要用來控制元素的顯示和輸入。任務(wù)正文信息的結(jié)構(gòu)用XML Schema 來表示。任務(wù)輸入信息與任務(wù)正文信息之間的信息映射用XML格式保存，在產(chǎn)生任務(wù) 時構(gòu)建平臺系統(tǒng)自動將輸入信息的值轉(zhuǎn)換到正文信息中。 步驟S5h指定任務(wù)調(diào)用的WEB服務(wù)。
任務(wù)是通過調(diào)用WEB服務(wù)訪問業(yè)務(wù)數(shù)據(jù)庫的。如果執(zhí)行任務(wù)時需要訪問業(yè)務(wù) 數(shù)據(jù)庫，則應(yīng)該指定任務(wù)調(diào)用的WEB服務(wù)。為了實現(xiàn)任務(wù)與WEB服務(wù)之間信息的傳 遞，還要分別指定任務(wù)正文信息與WEB服務(wù)的輸入?yún)?shù)與輸出參數(shù)之間的信息映 射。
步驟S52:定義任務(wù)關(guān)系。
任務(wù)關(guān)系就是業(yè)務(wù)流程，定義任務(wù)關(guān)系實質(zhì)上就是定義業(yè)務(wù)流程。任務(wù)關(guān)系 是指任務(wù)的分解關(guān)系，是屬于任務(wù)的，因此任務(wù)關(guān)系的定義是任務(wù)定義的組成部分。
任務(wù)關(guān)系分為三種父子關(guān)系、前后關(guān)系和并列關(guān)系。其中父子關(guān)系是整體 與部分的關(guān)系，屬于不同的任務(wù)層次。 一個任務(wù)只能有一個父任務(wù)，但一個任務(wù)可 以有多個子任務(wù)。父任務(wù)必須先于子任務(wù)產(chǎn)生，子任務(wù)必須先于父任務(wù)結(jié)束。從本 質(zhì)上說父子關(guān)系體現(xiàn)了活動的目的性。當(dāng)兩個或多個任務(wù)之間的執(zhí)行有先后順序時 就屬于前后關(guān)系。前任務(wù)和后任務(wù)屬于相同的任務(wù)層次， 一個任務(wù)可以有多個前任 務(wù)，也可以有多個后任務(wù)。前任務(wù)必須先于后任務(wù)產(chǎn)生和結(jié)束。從本質(zhì)上看，前后 關(guān)系反映了活動的時間性。屬于并列關(guān)系的任務(wù)之間沒有執(zhí)行的先后順序，也即互 不影響。從本質(zhì)上看前后關(guān)系反映了活動的時間性。從本質(zhì)上看并列關(guān)系反映了 活動的空間性
任務(wù)關(guān)系必須滿足一定的要求(1)任務(wù)只能由它的父任務(wù)或前任務(wù)產(chǎn)生， 或者直接由任務(wù)定義產(chǎn)生一個項目，或由輸入接口產(chǎn)生。(2)先有父任務(wù)，后有 子任務(wù)；先有前任務(wù)，后有后任務(wù)。(3)父任務(wù)天然有產(chǎn)生子任務(wù)的權(quán)利，但如 果一個任務(wù)已經(jīng)定義為由前任務(wù)產(chǎn)生，則它不應(yīng)該由父任務(wù)產(chǎn)生。如果一個任務(wù)沒 有定義為前任務(wù)產(chǎn)生，則前任務(wù)不能產(chǎn)生它，它只能由父任務(wù)產(chǎn)生。
通過上述三種任務(wù)關(guān)系的排列組合，可以形成各種各樣的任務(wù)關(guān)系，以表示 各種各樣的業(yè)務(wù)流程。
步驟S53:定義任務(wù)接口。
任務(wù)接口用來實現(xiàn)不同流程/系統(tǒng)之間的集成。任務(wù)接口分為輸入接口和輸出 接口，其中輸入接口用于接收產(chǎn)生任務(wù)實例的指令，輸出接口用于發(fā)送產(chǎn)生任務(wù)實例的指令。任務(wù)接口不能單獨(dú)存在，必須依賴于任務(wù)存在。任務(wù)接口的另一作用是 突破了任務(wù)之間嚴(yán)格的層次關(guān)系和前后關(guān)系，作為對它們的有力補(bǔ)充，相當(dāng)于在任 務(wù)之間引入了非線性關(guān)系。
任務(wù)接口功能也是用Web服務(wù)實現(xiàn)的。 步驟S54:定義任務(wù)關(guān)系建模的元模型。
如圖9所示，業(yè)務(wù)建模的圖形元素包括 一般任務(wù)900;決策任務(wù)901;表示
匯總與任務(wù)902，所有前任務(wù)都結(jié)束才產(chǎn)生和執(zhí)行；表示匯總或任務(wù)903，任一個 前任務(wù)結(jié)束就產(chǎn)生和執(zhí)行；表示任務(wù)接口 904，通常有輸入接口和輸出接口這兩種 任務(wù)接口；表示任務(wù)之間的連線905;表示任務(wù)之間的連接和手工產(chǎn)生關(guān)系906， 箭頭由任務(wù)指向被產(chǎn)生的任務(wù)；表示任務(wù)之間的連接和自動產(chǎn)生關(guān)系907，箭頭由 任務(wù)指向被產(chǎn)生的任務(wù)；表示顯示任務(wù)時，可以手工跳轉(zhuǎn)到(顯示)另一任務(wù)908; 表示任務(wù)執(zhí)行完成后，自動跳轉(zhuǎn)到(顯示) 一個任務(wù)909;父子關(guān)系910，由父任 務(wù)的上邊或下邊引出，連接到子任務(wù)的左邊；前后關(guān)系911，由前任務(wù)的右邊引出， 連接到后任務(wù)的左邊；并列關(guān)系912，兩個以上任務(wù)的左邊互相連接在一起。 步驟S55:指定任務(wù)關(guān)系中任務(wù)節(jié)點的類型。
一個任務(wù)節(jié)點的生命周期分為五種類型正常型，指正常產(chǎn)生和結(jié)束的任務(wù)， 這是默認(rèn)的類型；永久型，指產(chǎn)生一次，長期存在，且不能結(jié)束的任務(wù)；多實例型， 指可以產(chǎn)生多個實例，且都保存的任務(wù)；重復(fù)型，指產(chǎn)生一次，可以重復(fù)執(zhí)行，但 不結(jié)束的任務(wù)；臨時型，指正常產(chǎn)生和結(jié)束，但不需要保存，也不會修改任務(wù)關(guān)系 的任務(wù)。
步驟S56:指定任務(wù)間的信息映射，為每對有產(chǎn)生關(guān)系的任務(wù)間指定信息映射 關(guān)系。
在任務(wù)關(guān)系中，如果一個任務(wù)產(chǎn)生另一個任務(wù)，就需要指定產(chǎn)生任務(wù)的正文 信息與被產(chǎn)生任務(wù)的輸入?yún)?shù)之間的映射關(guān)系。如果該任務(wù)由父任務(wù)產(chǎn)生，則應(yīng)指 定父任務(wù)與它的信息結(jié)構(gòu)間的映射關(guān)系；如果該任務(wù)由前任務(wù)產(chǎn)生，則應(yīng)指定前任 務(wù)與它的信息結(jié)構(gòu)間的映射關(guān)系。任務(wù)關(guān)系的定義可以通過上述的圖形界面來實 現(xiàn)，定義好的任務(wù)關(guān)系保存在構(gòu)建平臺系統(tǒng)的數(shù)據(jù)庫中，定義后的任務(wù)稱為任務(wù)種 類。
第六步是在接收到任務(wù)產(chǎn)生請求后，根據(jù)定義的任務(wù)屬性產(chǎn)生任務(wù)實例，并從有權(quán)執(zhí)行本任務(wù)的用戶列表中選擇任務(wù)的接收者，產(chǎn)生任務(wù)后同時修改任務(wù)實例
的任務(wù)關(guān)系(對應(yīng)圖3的步驟⑤)。
第七步是根據(jù)任務(wù)定義的任務(wù)正文信息架構(gòu)(XML Schema)、任務(wù)正文信息 (XML)和顯示格式來顯示任務(wù)的信息(對應(yīng)圖3的步驟⑥)。
第八步是接收用戶對任務(wù)的操作，這些操作包括退回、委托、開始、執(zhí)行、 結(jié)束、追回等。當(dāng)處理或執(zhí)行一個任務(wù)時，如果為該操作定義了WEB服務(wù)，則會調(diào) 用相應(yīng)的WEB服務(wù)(對應(yīng)圖3的步驟⑦)以訪問業(yè)務(wù)數(shù)據(jù)庫。
第九步是接收用戶對任務(wù)的管理(對應(yīng)圖3的步驟⑧)，包括顯示任務(wù)、取 消任務(wù)、修改任務(wù)實例關(guān)系、指定共享用戶和角色、改變?nèi)蝿?wù)的用戶。構(gòu)建平臺系 統(tǒng)中的管理是基于任務(wù)及其相互關(guān)系來實現(xiàn)的，只要授予了權(quán)限，通過一個任務(wù)就 可以進(jìn)入到相關(guān)的任務(wù)。
構(gòu)建平臺系統(tǒng)的這種以任務(wù)(業(yè)務(wù))為中心的管理模式，通過定義業(yè)務(wù)流程 (任務(wù)關(guān)系)，各種相關(guān)聯(lián)的任務(wù)已經(jīng)按業(yè)務(wù)的內(nèi)在邏輯聯(lián)系在了一起，任務(wù)之間 的協(xié)作輕而易舉，每個用戶只要執(zhí)行自己的任務(wù)，就可以與他人進(jìn)行緊密的協(xié)作。 此外在用戶之間還可以進(jìn)行通信交流。
BUG管理系統(tǒng)的示例
圖5示出了本發(fā)明的一個應(yīng)用示例一軟件開發(fā)項目中的BUG管理系統(tǒng)。軟件 開發(fā)中BUG管理因涉及到測試人員、開發(fā)人員和項目經(jīng)理等多個角色，是一項比較 繁重的工作。BUG從提交到關(guān)閉，有一個完整的生命周期，如果管理得不好，就會 影響項目的進(jìn)度及軟件的質(zhì)量。傳統(tǒng)的BUG管理軟件雖然對BUG本身進(jìn)行了較好的 管理，但不能讓BUG與測試人員和開發(fā)人員的工作進(jìn)行無縫的集成。建立在本發(fā)明 的構(gòu)建平臺系統(tǒng)上的BUG管理系統(tǒng)很好地解決了這個問題。
首先，分析BUG管理的業(yè)務(wù)流程。BUG可以分為六個狀態(tài)N表示新發(fā)現(xiàn)，A 表示已指派，F(xiàn)表示己解決，H表示暫不修改，C表示已關(guān)閉，X表示已刪除。BUG 狀態(tài)的變化路徑如圖5所示。
然后，設(shè)計和建立BUG管理數(shù)據(jù)庫，開發(fā)訪問BUG管理數(shù)據(jù)庫的WEB服務(wù)。 比如提交一個BUG服務(wù)、査詢BUG服務(wù)、修改BUG的狀態(tài)服務(wù)等。
再定義BUG管理項目的業(yè)務(wù)流程(業(yè)務(wù)關(guān)系)，如圖6所示。其中"BUG管理"是正常型項目。"提交BUG"是永久型任務(wù)，包含WEB服務(wù)引用。"BUG査詢&選擇" 是重復(fù)型任務(wù)，包含WEB服務(wù)引用。"判斷BUG狀態(tài)"是決策型任務(wù)。"顯示新 BUG"、"顯示已分配BUG"、"顯示己解決BUG"、"顯示已關(guān)閉BUG"、"顯示 已掛起B(yǎng)UG"、"顯示已刪除BUG"都是臨時型任務(wù)，包含WEB服務(wù)引用。"掛起 BUG"等也是臨時型任務(wù)，包含WEB服務(wù)調(diào)用。"分配BUG"通過任務(wù)輸出接口為 編程管理項目中的開發(fā)人員產(chǎn)生修正BUG的任務(wù)，包含WEB服務(wù)調(diào)用。"BUG檢查" 是多實例型任務(wù)，接收編程管理系統(tǒng)發(fā)送過來的檢查BUG任務(wù)，讓測試人員檢査 BUG是否真的被修正，如果檢査合格測試人員就關(guān)閉該BUG，否則就重新提交該BUG， 包含WEB服務(wù)調(diào)用。
編程管理項目的業(yè)務(wù)流程如圖7所示，其中"修正BUG任務(wù)"是多實例型任 務(wù)，接收BUG管理系統(tǒng)發(fā)送過來的修正BUG任務(wù)，讓開發(fā)人員修正BUG。當(dāng)修正完 BUG后，開發(fā)人員就結(jié)束該任務(wù)，同時通過輸出接口給BUG管理系統(tǒng)發(fā)送一個檢査 BUG的任務(wù)，供測試人員使用。
如前所述，整個業(yè)務(wù)流程的邏輯完全搭建起來，無需任何的硬編碼，并且隨 時可以調(diào)整。通過建立在構(gòu)建平臺系統(tǒng)之上的BUG管理項目和編程管理項目，BUG 的生命周期就被很好地管理起來，同時與測試人員、開發(fā)人員和項目經(jīng)理等人的工 作實現(xiàn)了無縫結(jié)合，極大提高了開發(fā)項目的工作效率。
此外，BUG管理和編程管理又可以組合成更上一級的項目一開發(fā)管理項目，開 發(fā)管理項目業(yè)務(wù)流程如圖8所示。依次類推，開發(fā)管理項目又可以和別的項目(比 如銷售管理項目)組成更上一級的項目(公司管理項目)，直至整個公司的管理都 包括進(jìn)來，形成企業(yè)的數(shù)字神經(jīng)系統(tǒng)。
上述實施例是提供給本領(lǐng)域普通技術(shù)人員來實現(xiàn)或使用本發(fā)明的，本領(lǐng)域普 通技術(shù)人員可在不脫離本發(fā)明的發(fā)明思想的情況下，對上述實施例做出種種修改或 變化，因而本發(fā)明的保護(hù)范圍并不被上述實施例所限，而應(yīng)該是符合權(quán)利要求書提 到的創(chuàng)新性特征的最大范圍。
權(quán)利要求
1、一種信息系統(tǒng)的構(gòu)建平臺系統(tǒng)，包括用戶接口層模塊，提供用戶登錄系統(tǒng)的入口，包含用于支持客戶端設(shè)備的用戶接口適配器；數(shù)據(jù)服務(wù)層模塊，以WEB服務(wù)的形式提供對數(shù)據(jù)庫的訪問，通過集中統(tǒng)一地管理所有數(shù)據(jù)來消除信息孤島；業(yè)務(wù)流程層模塊，面向數(shù)據(jù)服務(wù)層的WEB服務(wù)，通過以業(yè)務(wù)為組成單元的建模方式定義和實現(xiàn)業(yè)務(wù)流程，通過與自己分離解耦的數(shù)據(jù)服務(wù)層訪問數(shù)據(jù)庫。
2、 根據(jù)權(quán)利要求1所述的信息系統(tǒng)的構(gòu)建平臺系統(tǒng)，其特征在于，該用戶接 口層模塊包括一顯示代碼配置單元，接收用戶設(shè)定的配置參數(shù)自動生成顯示代碼。
3、 通過如權(quán)利要求1或2所述的信息系統(tǒng)的構(gòu)建平臺系統(tǒng)進(jìn)行業(yè)務(wù)處理的方 法，包括(1) 建立業(yè)務(wù)數(shù)據(jù)庫和數(shù)據(jù)訪問服務(wù)層；(2) 接收用戶管理信息的定義并保存在平臺系統(tǒng)的數(shù)據(jù)庫中，并為角色分配權(quán)限；(3) 接收對訪問業(yè)務(wù)數(shù)據(jù)庫的WEB服務(wù)的定義并保存在平臺系統(tǒng)的數(shù)據(jù)庫中；(4) 接收任務(wù)定義并保存在平臺系統(tǒng)的數(shù)據(jù)庫中，定義的任務(wù)是一個自包含 的對象，任務(wù)既包含業(yè)務(wù)流程同時又是業(yè)務(wù)流程的組成單元，任務(wù)是可重用的業(yè)務(wù) 建模單元也是可單獨(dú)執(zhí)行和單獨(dú)管理的業(yè)務(wù)單元，而且任務(wù)包括任務(wù)屬性、任務(wù)的輸入信息和正文信息、任務(wù)的分解結(jié)構(gòu)、任務(wù)調(diào)用的WEB服務(wù)、任務(wù)發(fā)送的郵件 要素；(5) 在接收到任務(wù)產(chǎn)生請求后，根據(jù)定義的任務(wù)屬性產(chǎn)生任務(wù)實例，并從有 權(quán)執(zhí)行本任務(wù)的用戶列表中選擇任務(wù)的接收者，產(chǎn)生任務(wù)后同時修改任務(wù)實例的任 務(wù)關(guān)系。
4、 根據(jù)權(quán)利要求3所述的通過信息系統(tǒng)的構(gòu)建平臺系統(tǒng)進(jìn)行業(yè)務(wù)處理的方 法，其特征在于，步驟(4)進(jìn)一步包括(4.1) 定義任務(wù)輸入信息和任務(wù)正文信息以及兩者之間的信息映射；(4.2) 指定任務(wù)調(diào)用的WEB服務(wù)；(4.3) 定義任務(wù)關(guān)系，任務(wù)關(guān)系即業(yè)務(wù)流程，任務(wù)之間的關(guān)系包括父子關(guān)系、 前后關(guān)系、并列關(guān)系三種；(4.4) 定義任務(wù)接口，任務(wù)接口分為用于接收產(chǎn)生任務(wù)實例的指令的輸入接 口和用于發(fā)送產(chǎn)生任務(wù)實例的指令的輸出接口；(4.5) 定義任務(wù)關(guān)系建模的元模型；(4.6) 指定任務(wù)關(guān)系中任務(wù)節(jié)點的類型，任務(wù)節(jié)點的類型分為正常型、永久 型、多實例型、重復(fù)型和臨時型；(4.7) 指定任務(wù)間的信息映射，為每對有產(chǎn)生關(guān)系的任務(wù)間指定信息映射關(guān)系。
5、 根據(jù)權(quán)利要求4所述的通過信息系統(tǒng)的構(gòu)建平臺系統(tǒng)進(jìn)行業(yè)務(wù)處理的方 法，其特征在于，步驟(4.1)的任務(wù)輸入信息和任務(wù)正文信息用XML信息結(jié)構(gòu)表 示，兩者之間的信息映射用XML格式來保存。
6、 根據(jù)權(quán)利要求5所述的通過信息系統(tǒng)的構(gòu)建平臺系統(tǒng)進(jìn)行業(yè)務(wù)處理的方 法，其特征在于，步驟(4.2)還包括分別指定任務(wù)正文信息與WEB服務(wù)的輸入?yún)?數(shù)和輸出參數(shù)之間的信息映射。
7、 根據(jù)權(quán)利要求6所述的通過信息系統(tǒng)的構(gòu)建平臺系統(tǒng)進(jìn)行業(yè)務(wù)處理的方 法，其特征在于，步驟(4.7)中指定的信息映射關(guān)系通過圖形界面實現(xiàn)。
8、 根據(jù)權(quán)利要求3所述的通過信息系統(tǒng)的構(gòu)建平臺系統(tǒng)進(jìn)行業(yè)務(wù)處理的方 法，其特征在亍，步驟(2)和步驟(3)之間還包括接收元素類型的定義，并將其保存在平臺系統(tǒng)的數(shù)據(jù)庫中，其中元素用于組 成任務(wù)的正文信息結(jié)構(gòu)。
9、 根據(jù)權(quán)利要求3所述的通過信息系統(tǒng)的構(gòu)建平臺系統(tǒng)進(jìn)行業(yè)務(wù)處理的方 法，其特征在于，步驟(5)之后還包括(6) 根據(jù)任務(wù)定義的任務(wù)正文信息架構(gòu)、任務(wù)正文信息和顯示格式來顯示任 務(wù)的信息；(7) 接收用戶對任務(wù)的操作，調(diào)用該操作對應(yīng)的WEB服務(wù)以訪問業(yè)務(wù)數(shù)據(jù) 庫，這些操作包括退回、委托、開始、執(zhí)行、結(jié)束、追回。
10、 根據(jù)權(quán)利要求9所述的通過信息系統(tǒng)的構(gòu)建平臺系統(tǒng)進(jìn)行業(yè)務(wù)處理的方 法，其特征在于，步驟(7)之后還包括(8) 接收用戶對任務(wù)的管理，包括顯示任務(wù)、取消任務(wù)、修改任務(wù)實例關(guān)系、 指定共享用戶和角色、改變?nèi)蝿?wù)的用戶。
全文摘要
本發(fā)明公開了一種信息系統(tǒng)的構(gòu)建平臺系統(tǒng)，能更好的滿足企業(yè)信息系統(tǒng)建設(shè)的需求，更能適應(yīng)未來的變化，成為隨需應(yīng)變的信息系統(tǒng)。其技術(shù)方案為系統(tǒng)包括用戶接口層模塊，提供用戶登錄系統(tǒng)的入口，包含用于支持客戶端設(shè)備的用戶接口適配器；數(shù)據(jù)服務(wù)層模塊，以WEB服務(wù)的形式提供對數(shù)據(jù)庫的訪問，通過集中統(tǒng)一地管理所有數(shù)據(jù)來消除信息孤島；業(yè)務(wù)流程層模塊，面向數(shù)據(jù)服務(wù)層的WEB服務(wù)，通過以業(yè)務(wù)為組成單元的建模方式定義和實現(xiàn)業(yè)務(wù)流程，通過與自己分離解耦的數(shù)據(jù)服務(wù)層訪問數(shù)據(jù)庫。本發(fā)明應(yīng)用于信息系統(tǒng)領(lǐng)域。
文檔編號H04L12/54GK101414945SQ20081020118
公開日2009年4月22日 申請日期2008年10月15日 優(yōu)先權(quán)日2008年10月15日
發(fā)明者熊軍民 申請人:上海道侖軟件有限公司