專利名稱：利用uml時(shí)序圖開發(fā)的方法和活動圖生成工具的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信技術(shù)領(lǐng)域，尤其涉及一種利用UML時(shí)序圖開發(fā)的方法和活動圖生 成工具。
背景技術(shù)：
統(tǒng)一建模語言(UML，Unified Modeling Language)目前在軟件工程方面有所應(yīng) 用，它是一種進(jìn)行面向?qū)ο蟪绦蛟O(shè)計(jì)的工具，用來把現(xiàn)實(shí)中的問題抽象成面向?qū)ο蟮慕鉀Q 方案，以便進(jìn)一步的編碼。UML是由一堆圖組成的，包括用例圖、類圖、對象圖、狀態(tài)生成圖、活動圖、時(shí)序 圖、部署圖等等。這些圖存在的意義一方面是使軟件分析和設(shè)計(jì)人員對目標(biāo)問題有更深 刻的理解和認(rèn)識(在畫這些圖的過程中達(dá)到的)；另一方面，是要使工程所涉及的所有人員 都能參與到工程的設(shè)計(jì)中來，UML為非專業(yè)編程人士理解軟件的功能和構(gòu)造，提供了一種直 白、簡單、通俗的方法。但是發(fā)明人在發(fā)明的過程發(fā)現(xiàn)現(xiàn)有UML時(shí)序圖只能表示業(yè)務(wù)運(yùn)行的主干流程， 當(dāng)業(yè)務(wù)流程發(fā)生變化時(shí)，UML時(shí)序圖無法表達(dá)，如難于準(zhǔn)確表達(dá)條件分支和并行事件處理寸。

發(fā)明內(nèi)容
本發(fā)明的實(shí)施例提供了一種利用UML時(shí)序圖開發(fā)的方法和活動圖生成工具，以實(shí) 現(xiàn)在UML時(shí)序圖中能夠表達(dá)多種邏輯處理過程。一種利用統(tǒng)一建模語言UML時(shí)序圖開發(fā)的方法，包括獲取業(yè)務(wù)處理流程對應(yīng)的UML時(shí)序圖，所述UML時(shí)序圖中至少包括分支處理圖元、 并行處理圖元或內(nèi)部處理圖元中一項(xiàng)；將所述UML時(shí)序圖生成對應(yīng)的活動圖。一種活動圖生成工具，包括獲取單元，獲取業(yè)務(wù)處理流程對應(yīng)的UML時(shí)序圖，所述UML時(shí)序圖中包括表示分支 處理圖元、并行處理圖元、內(nèi)部處理圖元中至少一項(xiàng)；生成單元，將所述UML時(shí)序圖生成對應(yīng)的活動圖。由上述本發(fā)明的實(shí)施例提供的技術(shù)方案可以看出，本發(fā)明實(shí)施例通過在UML時(shí)序 圖中包括表示分支處理圖元、并行處理圖元、內(nèi)部處理圖元中的至少一項(xiàng)，并將所述時(shí)序圖 轉(zhuǎn)化為活動圖，從而可以實(shí)現(xiàn)根據(jù)各種業(yè)務(wù)流程的不同情況，執(zhí)行不同的處理邏輯。


為了更清楚地說明本發(fā)明實(shí)施例的技術(shù)方案，下面將對實(shí)施例描述中所需要使用 的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實(shí)施例，對于本 領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動性的前提下，還可以根據(jù)這些附圖獲得其他的附圖。
圖1為本發(fā)明實(shí)施 歹一提供的--種利用UML時(shí)序圖開發(fā)的方法流程圖2為本發(fā)明實(shí)施 歹二提供的--種帶有分支處理邏輯的UML時(shí)序圖3為本發(fā)明實(shí)施 歹二提供的--種將圖2所示的UML時(shí)序圖中生成的活動圖
圖4為本發(fā)明實(shí)施 歹三提供的--種帶有并行處理邏輯的UML時(shí)序圖5為本發(fā)明實(shí)施 歹三提供的--種將圖4所示的UML時(shí)序圖生成的活動圖6為本發(fā)明實(shí)施 歹四提供的--種帶有內(nèi)部處理邏輯的UML時(shí)序圖7為本發(fā)明實(shí)施 歹四提供的--種將圖6所示的UML時(shí)序圖生成的活動圖8為本發(fā)明實(shí)施 歹五提供的--種帶有嵌套的UML時(shí)序圖9為本發(fā)明實(shí)施 歹提供的一種活動圖生成工具的結(jié)構(gòu)示意圖10為本發(fā)明實(shí)施例提供的另一種活動圖生成工具的結(jié)構(gòu)示意圖。
具體實(shí)施例方式為便于對本發(fā)明實(shí)施例的理解，下面將結(jié)合附圖以幾個(gè)具體實(shí)施例為例做進(jìn)一步 的解釋說明，且各個(gè)實(shí)施例并不構(gòu)成對本發(fā)明實(shí)施例的限定。實(shí)施例一該實(shí)施例提供的一種利用UML時(shí)序圖開發(fā)的方法，如圖1所示，包括如下處理步 驟步驟11、獲取業(yè)務(wù)處理流程對應(yīng)的UML時(shí)序圖，所述UML時(shí)序圖中至少包括分支處 理圖元、并行處理圖元或內(nèi)部處理圖元中一項(xiàng)；步驟12、將所述UML時(shí)序圖生成對應(yīng)的活動圖。由上述本發(fā)明的實(shí)施例提供的技術(shù)方案可以看出，本發(fā)明實(shí)施例通過在UML時(shí)序 圖中包括表示分支處理圖元、并行處理圖元、內(nèi)部處理圖元中的至少一項(xiàng)，并將所述時(shí)序圖 轉(zhuǎn)化為活動圖，從而可以實(shí)現(xiàn)根據(jù)各種業(yè)務(wù)流程的不同情況，執(zhí)行不同的處理邏輯。分支處理圖元、并行處理圖元或內(nèi)部處理的具體生成過程下面將詳細(xì)介紹。實(shí)施例二該實(shí)施例中存在帶有分支處理邏輯的業(yè)務(wù)處理流程，在利用UML時(shí)序圖表示帶有 分支處理邏輯的業(yè)務(wù)處理流程時(shí)，需要在UML時(shí)序圖中設(shè)置多個(gè)分支圖元，分別表示多個(gè) 不同分支的處理邏輯，如Flowl和Flow2，其中，分支圖元Flowl對應(yīng)第一個(gè)分支處理邏輯， 分支圖元Flow2對應(yīng)第二個(gè)分支處理邏輯。因此當(dāng)選中Flowl或Flow2時(shí)，就展示出相應(yīng) 的分支處理邏輯的具體處理步驟。需要說明的是該分支圖元的表示方法，比如圖2中， 用兩個(gè)并列的小方塊圖標(biāo)來表示3個(gè)并列的分支，當(dāng)然，也可以設(shè)置其它的形狀，比如是設(shè) 置圓形來表示分支圖元，還可以設(shè)置不同的顏色，比如，紅色圖形就表示分支圖元，本發(fā)明 的實(shí)施例并不限制分支圖元的表示方式，只要能夠唯一區(qū)分出一個(gè)圖元為分支圖元就可以 了。下面結(jié)合一個(gè)具體的實(shí)施例來說明帶有分支圖元的UML時(shí)序圖的工作原理，該業(yè) 務(wù)處理流程的UML時(shí)序圖如圖2所示。核心網(wǎng)MSC觸發(fā)一個(gè)呼叫業(yè)務(wù)，MSC根據(jù)該呼叫業(yè)務(wù)的主被叫用戶的用戶簽約信 息，發(fā)送攜帶上述呼叫業(yè)務(wù)的參數(shù)信息的IDP (A，b)消息給krviceBroker。
Service Broker接收到上述IDP(A，b)消息后，獲取其中攜帶的上述呼叫業(yè)務(wù)的 參數(shù)信息，根據(jù)該參數(shù)信息中的業(yè)務(wù)標(biāo)識信息，該業(yè)務(wù)標(biāo)識信息有三類，不同的業(yè)務(wù)標(biāo)識信 息，后續(xù)的流程是不同的，即這里存在一個(gè)分支處理的流程，因此在UML時(shí)序圖預(yù)先設(shè)置 時(shí)，需要設(shè)置分支圖元來表示這個(gè)邏輯，如附圖2所述，分支圖元為圖元Flowl、圖元Flow2 和圖元Flow3。根據(jù)該參數(shù)信息中的業(yè)務(wù)標(biāo)識信息，Service Broker確定是執(zhí)行分支圖元Flowl 或分支圖元Flow2對應(yīng)的處理邏輯。比如，根據(jù)參數(shù)信息中的業(yè)務(wù)標(biāo)識信息確定是執(zhí)行分 支圖元Flowl的處理邏輯時(shí)，便選中分支圖元Flowl (附圖2中的步驟2為Flowl對應(yīng)的分 支)，獲取這個(gè)處理邏輯的具體處理步驟，并執(zhí)行該具體處理步驟。上述分支圖元Flowl的處理的步驟可以包括Service Broker將上述IDP (A，b) 消息發(fā)送給VPN系統(tǒng)。圖2中只是顯示分支圖元Flowl所對應(yīng)的流程，而由于頁面顯示的限制，分支圖元 Flow2具體對應(yīng)的分支流程在圖2中并沒有顯示出來，在實(shí)際應(yīng)用中，根據(jù)上述的該參數(shù)信 息中的業(yè)務(wù)標(biāo)識信息，Service Broker確定是執(zhí)行分支圖元Flow2，這時(shí)只要選擇分支圖元 Flow2就可以，圖2將顯示Flow2流程對應(yīng)的流程，如Service Broker將上述IDP (A，b)消 息發(fā)送給PPS。如果義！^丨⑶Broker根據(jù)上述的該參數(shù)信息中的業(yè)務(wù)標(biāo)識信息，確定是執(zhí) 行分支圖元Flow3，則相應(yīng)選擇分支圖元Flow3 (假設(shè)該流程為krvice Broker內(nèi)部處理的 流程)，并執(zhí)行該Flow3對應(yīng)的流程。進(jìn)一步地，在實(shí)際的應(yīng)用中，可能存在多個(gè)分支處理時(shí)，此時(shí)就對應(yīng)的增加多種分 支圖元，每一種分支圖元代表一種具體的處理流程。本發(fā)明實(shí)施例可以利用利用配置的各種活動元，將上述圖2所示的時(shí)序圖中 的生成為活動圖，在將時(shí)序圖生成為活動圖的過程中，是以一個(gè)網(wǎng)元的角度來生成的，例 如圖3是從krvice Broker的角度將圖2的時(shí)序圖生成為活動圖的，下面介紹該生成的 過程。 Service Broker接收一個(gè)IDP消息，并存儲該IDP消息，進(jìn)行邏輯判斷，選擇該IDP 消息對應(yīng)的處理分支，Service Broker接收IDP消息，活動圖就生成為Wait (等待處理)圖元和 MveMessage (存儲)圖元，這和現(xiàn)有的技術(shù)相同，這里就不在贅述了。活動圖的圖元可以直接轉(zhuǎn)換成相應(yīng)的程序代碼，該過程和現(xiàn)有的技術(shù)相同，這里 就不在贅述了。當(dāng)krvice Broker分析IDP消息時(shí)，根據(jù)IDP消息中包含的不同的參數(shù)信息，有 三種不同的處理流程，也就是說存在分支處理邏輯，這時(shí)時(shí)序圖分支圖元轉(zhuǎn)換成活動圖的 分支處理SwitchO圖元，活動圖的分支處理SwitchO圖元包含了 4個(gè)分支，分別是分支1，生 成Service Broker向VPN發(fā)送IDP消息的代碼；分支2，生成Service Broker向PPS發(fā)送 IDP消息的代碼；分支3，生成krvice Broker將IDP消息進(jìn)行內(nèi)部處理的代碼，分支4，生 成默認(rèn)default分支代碼，直接執(zhí)行到失敗處理出口。實(shí)施例三該實(shí)施例的處理過程中，某個(gè)網(wǎng)元需要同一時(shí)間內(nèi)處理多個(gè)事件，也就是說，在處 理過程中，存在一個(gè)并行處理邏輯，因此在UML時(shí)序圖表示該流程時(shí)，需要設(shè)定一個(gè)并行處理圖元，例如如圖4所示，該并行處理圖元可以用一個(gè)黑色豎型小方塊來表示，該并行處 理圖元在接收到步驟4中的VPN返回的CON消息和步驟5中的PPS返回的RRBE消息后才生 效，即krvice Broker同時(shí)處理上述CON消息和RRBE消息。如果只接收到上述CON消息 和RRBE消息中的一個(gè)，則上述并行處理圖元不生效，即krvice Broker并不處理上述CON 消息或RRBE消息，整個(gè)呼叫業(yè)務(wù)的處理流程失敗。需要說明的是該并行處理圖元的表示 方法，可以為附圖4中的黑色豎型小方塊，當(dāng)然，也可以設(shè)置其它的形狀，比如是設(shè)置圓形 來表示并行處理圖元，還可以設(shè)置不同的顏色，比如，紅色圖形就表示并行處理圖元，本發(fā) 明的實(shí)施例并不限制并行處理圖元的表示方式，只要能夠唯一區(qū)分出一個(gè)圖元為并行處理 圖元就可以了。上述業(yè)務(wù)處理流程的具體處理過程如下核心網(wǎng)MSC觸發(fā)上述呼叫業(yè)務(wù)，MSC根據(jù)上述呼叫業(yè)務(wù)的主被叫用戶的用戶簽約 信息，發(fā)送攜帶上述呼叫業(yè)務(wù)的參數(shù)信息的IDP (A，b)消息給krviceBroker。Service Broker接收到上述IDP(A，b)消息后，獲取其中攜帶的上述呼叫業(yè)務(wù)的 參數(shù)信息，根據(jù)該參數(shù)信息中的業(yè)務(wù)標(biāo)識信息，獲取保存的上述呼叫業(yè)務(wù)的業(yè)務(wù)處理流程 對應(yīng)的時(shí)序圖，并執(zhí)行該業(yè)務(wù)處理流程。Service Broker 將 IDP (A, b)消息發(fā)送給 VPN 和 PPS。VPN 接收到上述 IDP (A, b) 消息后，觸發(fā)VPN業(yè)務(wù)，由VPN業(yè)務(wù)把短號b轉(zhuǎn)換成長號B。VPN向krvice Broker發(fā)送 C0N(A,B)消息。PPS接收到上述IDP (A，b)消息后，觸發(fā)PPS業(yè)務(wù)，PPS向krvice Broker 發(fā)送RRBE消息。Service Broker在接收到上述VPN返回的CON消息和PPS返回的RRBE消息后，上 述時(shí)序圖中的并行處理圖元生效，Service Broker同時(shí)處理上述CON消息和RRBE消息，并 繼續(xù)執(zhí)行后續(xù)的處理步驟。本發(fā)明實(shí)施例可以利用利用配置的各種活動元，將上述圖4所示的時(shí)序圖中 的生成為活動圖，在將時(shí)序圖生成為活動圖的過程中，是以一個(gè)網(wǎng)元的角度來生成的，例 如圖5從krvice Broker的角度將圖4的時(shí)序圖生成為活動圖的，下面只介紹圖4中的 第4步和第5步生成活動圖的過程。活動圖生成工具根據(jù)時(shí)序圖中的存在并行處理圖元，則將該時(shí)序圖的并行處理圖 元生成為對應(yīng)的活動圖的并行處理圖，如附圖5所示?；顒訄D生成工具將時(shí)序圖的并行處理圖元生成包括Wait(等待處理)圖元、 MveMessage (存儲)圖元和EventFinish(并行判斷)圖元的并行處理的活動圖。其中， Wait (等待處理)圖元，用于在預(yù)定的業(yè)務(wù)邏輯的執(zhí)行周期結(jié)束(TimeOut)后，連接執(zhí)行失 敗出口，在所述執(zhí)行周期結(jié)束前，處理VPN上報(bào)的CON事件和PPS上報(bào)的RRBE事件，分別將 CON事件和RRBE事件的處理信息發(fā)送給^iveMessage圖元。SaveMessage圖元，用于保存 上述CON事件和RRBE事件的處理信息，連接執(zhí)行成功出口。EventFinish (并行判斷)圖 元，用于判斷上述CON事件和RRBE事件是否都執(zhí)行完成，如果是，連接執(zhí)行成功出口 ；否則， 連接上述等待處理圖元，繼續(xù)等待VPN上報(bào)的CON事件或PPS上報(bào)的RRBE事件。由于存在 并行處理過程，因此在該活動圖中存在了一個(gè)循環(huán)的并行判斷的過程，這就保證了并行的 每一個(gè)事件處理處理結(jié)束之后，才結(jié)束該循環(huán)等待過程。實(shí)施例四
該實(shí)施例的處理過程中，某個(gè)網(wǎng)元在某個(gè)步驟中，需要進(jìn)行內(nèi)部處理，也就是說， 在處理過程中，存在一個(gè)內(nèi)部處理邏輯，因此在UML時(shí)序圖表示該流程時(shí)，需要設(shè)定一個(gè)內(nèi) 部處理圖元，例如如圖6所示，該內(nèi)部處理圖元可以用循環(huán)箭頭來表示，雙擊內(nèi)部處理圖 元，可以打開一個(gè)編輯器，可以在編輯器中編輯一個(gè)完整的子活動圖。例如上述業(yè)務(wù)處理流程的具體處理過程如下核心網(wǎng)MSC觸發(fā)上述呼叫業(yè)務(wù)，MSC根據(jù)上述呼叫業(yè)務(wù)的主被叫用戶的用戶簽約 信息，發(fā)送攜帶上述呼叫業(yè)務(wù)的參數(shù)信息的IDP (A，b)消息給krviceBroker。Service Broker接收到上述IDP(A，b)消息后，獲取其中攜帶的上述呼叫業(yè)務(wù)的 參數(shù)信息，根據(jù)該參數(shù)信息中的業(yè)務(wù)標(biāo)識信息，獲取保存的上述呼叫業(yè)務(wù)的業(yè)務(wù)處理流程 對應(yīng)的時(shí)序圖，并執(zhí)行該業(yè)務(wù)處理流程。Service Broker發(fā)送IDP (A, b)消息發(fā)送給VPN。VPN接收到上述IDP (A，b)消息 后，觸發(fā)VPN業(yè)務(wù)，由VPN業(yè)務(wù)把短號b生成成長號B。VPN向ServiceBroker發(fā)送CON(A， B)消息。Service Broker接收到上述CON(A，B)消息后，上述內(nèi)部處理圖元生效，Service Broker執(zhí)行上述內(nèi)部處理邏輯，將上述IDP (A，b)消息中的長號B換成長號C。然后，Service Broker向PPS發(fā)送DP (A，C)消息，并繼續(xù)執(zhí)行后續(xù)的處理步驟。本發(fā)明實(shí)施例可以利用配置的各種活動元，將上述圖6所示的時(shí)序圖中的 內(nèi)部處理圖元轉(zhuǎn)化為圖7所示的內(nèi)部處理活動元，這里只介紹圖6中第4步Service Broker將上述IDP(A，b)消息中的長號B換成長號C的內(nèi)部處理過程生成對應(yīng)活動圖的過程。活動圖生成工具根據(jù)時(shí)序圖中的存在內(nèi)部處理圖元，則將該時(shí)序圖的內(nèi)部處理圖 元生成為對應(yīng)的活動圖的內(nèi)部處理圖，如圖7所示?；顒訄D生成工具將時(shí)序圖的內(nèi)部處理圖元生成包括多個(gè)Logic(內(nèi)部處理邏輯) 圖元和cond(條件判斷)圖元的活動圖，其中，生成的活動圖的Logic(內(nèi)部處理邏輯)圖元 個(gè)數(shù)與時(shí)序圖的內(nèi)部處理圖元的處理邏輯個(gè)數(shù)相同。例如附圖 中包含了 2個(gè)Logic (內(nèi) 部處理邏輯)圖元，分別為查詢長號B對應(yīng)的長號C的內(nèi)部處理過程，和將長號B改為長號 C的內(nèi)部處理過程。實(shí)施例五上述各種處理邏輯關(guān)系還可以進(jìn)行嵌套使用，例如該實(shí)施例中ServiceBroker 存在了分支處理和嵌套的子分支處理的業(yè)務(wù)流程，如圖8所示，分支處理圖元Flowl和 Flow2表示兩個(gè)不同的分支處理的過程，其中Flowl分支處理邏輯還存在一個(gè)異常處理邏輯。核心網(wǎng)MSC觸發(fā)一個(gè)呼叫業(yè)務(wù)，MSC根據(jù)該呼叫業(yè)務(wù)的主被叫用戶的用戶簽約信 息，發(fā)送攜帶呼叫業(yè)務(wù)的參數(shù)信息的IDP消息給krvice Broker, Service Broker獲取其 中攜帶的呼叫業(yè)務(wù)的參數(shù)信息，根據(jù)該參數(shù)信息中的業(yè)務(wù)標(biāo)識信息，執(zhí)行Flowl的流程，即 圖8所展示的內(nèi)容(圖8并沒有顯示Flow2的分支流程)；Service Broker將IDP消息發(fā) 送給VPN，VPN處理成功的情況下，向krvice Broker發(fā)送CON消息，如果處理失敗或者異 常的情況下，向義！^丨⑶Broker發(fā)送RC消息，(需要說明的是這里并不是并行處理過程，而 是一個(gè)可選選擇的過程)。由于krvice Broker可能接收不同類型的消息，因此在Flowl的分支處理圖元中存在了 1個(gè)嵌套的子分支處理圖元，即存在分支處理圖元normal和分支 處理圖元abnormal，如果krvice Broker接收的是CON消息，則執(zhí)行normal分支處理邏 輯，如果krvice Broker接收的是RC消息，則執(zhí)行abnormal分支處理邏輯，其中，圖8所 展示的內(nèi)容為normal分支處理邏輯，abnormal分支處理邏輯在圖8中并沒有顯示。由于krvice Broker從VPN接收到的是CON消息，因此執(zhí)行normal的分支處理 過程，即，Service Broker向PPS發(fā)送IDP消息，并且接收了 PPS返回的RRBE消息后，還向 MSC發(fā)送RRBE和CON消息。本發(fā)明實(shí)施例還提供了一種活動圖生成工具，其具體實(shí)現(xiàn)結(jié)構(gòu)如圖9所示，包括獲取單元91，獲取業(yè)務(wù)處理流程對應(yīng)的UML時(shí)序圖，所述UML時(shí)序圖中包括分支處 理圖元、并行處理圖元、內(nèi)部處理圖元中至少一項(xiàng)；生成單元92，將所述UML時(shí)序圖生成對應(yīng)的活動圖。進(jìn)一步地如圖10所示，生成單元92具體包括了分支生成子單元921，并行生成 子單元922和內(nèi)部生成子單元923，其中分支生成子單元921，用于將所述UML時(shí)序圖的分支處理圖元轉(zhuǎn)換成活動圖的分 支處理SwitchO圖元，其中所述活動圖的分支處理SwitchO圖元包含的分支處理個(gè)數(shù)與UML 時(shí)序圖的分支處理圖元的分支個(gè)數(shù)相同；并行生成子單元922，用于將所述UML時(shí)序圖的并行處理圖元轉(zhuǎn)換成活動圖的等 待處理圖元、存儲圖元以及并行判斷圖元；內(nèi)部生成子單元923，用于將所述UML時(shí)序圖的內(nèi)部處理圖元轉(zhuǎn)換成活動圖的1個(gè) 或1個(gè)以上的內(nèi)部處理邏輯圖元和條件判斷圖元。本領(lǐng)域普通技術(shù)人員可以理解實(shí)現(xiàn)上述實(shí)施例方法中的全部或部分流程，是可以 通過計(jì)算機(jī)程序來指令相關(guān)的硬件來完成，所述的程序可存儲于一計(jì)算機(jī)可讀取存儲介質(zhì) 中，該程序在執(zhí)行時(shí)，可包括如上述各方法的實(shí)施例的流程。其中，所述的存儲介質(zhì)可為磁 碟、光盤、只讀存儲記憶體(Read-Only Memory, ROM)或隨機(jī)存儲記憶體(Random Access Memory, RAM)等。由上述本發(fā)明的實(shí)施例提供的技術(shù)方案可以看出，本發(fā)明實(shí)施例通過在UML時(shí)序 圖中包括表示分支處理圖元、并行處理圖元、內(nèi)部處理圖元中的至少一項(xiàng)，并將所述時(shí)序圖 轉(zhuǎn)化為活動圖，從而可以實(shí)現(xiàn)根據(jù)各種業(yè)務(wù)流程的不同情況，執(zhí)行不同的處理邏輯。本發(fā)明實(shí)施例解決了時(shí)序圖語義不嚴(yán)謹(jǐn)，不能用于準(zhǔn)確表達(dá)業(yè)務(wù)邏輯的執(zhí)行過程 的問題。將本發(fā)明實(shí)施例中的時(shí)序圖和活動圖用于業(yè)務(wù)的開發(fā)，可以使得業(yè)務(wù)邏輯清晰明 了，提高了業(yè)務(wù)開發(fā)效率，同時(shí)降低了維護(hù)難度。以上所述，僅為本發(fā)明較佳的具體實(shí)施方式
，但本發(fā)明的保護(hù)范圍并不局限于此， 任何熟悉本技術(shù)領(lǐng)域的技術(shù)人員在本發(fā)明揭露的技術(shù)范圍內(nèi)，可輕易想到的變化或替換， 都應(yīng)涵蓋在本發(fā)明的保護(hù)范圍之內(nèi)。因此，本發(fā)明的保護(hù)范圍應(yīng)該以權(quán)利要求的保護(hù)范圍 為準(zhǔn)。
權(quán)利要求
1.一種利用統(tǒng)一建模語言UML時(shí)序圖開發(fā)的方法，其特征在于，包括獲取業(yè)務(wù)處理流程對應(yīng)的UML時(shí)序圖，所述UML時(shí)序圖中至少包括分支處理圖元、并行 處理圖元或內(nèi)部處理圖元中一項(xiàng)；將所述UML時(shí)序圖生成對應(yīng)的活動圖。
2.根據(jù)權(quán)利要求1所述方法，其特征在于，所述UML時(shí)序圖為分支處理圖元時(shí)，所述分 支處理圖元表示了1個(gè)以上的不同分支處理邏輯；所述將所述UML時(shí)序圖生成對應(yīng)的活動圖，具體為將所述UML時(shí)序圖的分支處理圖元轉(zhuǎn)換成活動圖的分支處理SwitchO圖元，其中所述 活動圖的分支處理SwitchO圖元包含的分支處理個(gè)數(shù)與UML時(shí)序圖的分支處理圖元的分支 個(gè)數(shù)相同。
3.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述UML時(shí)序圖為并行處理圖元時(shí)，所述 并行處理圖元表示了并行處理邏輯；所述將所述UML時(shí)序圖生成對應(yīng)的活動圖，具體為將所述UML時(shí)序圖的并行處理圖元 轉(zhuǎn)換成活動圖的等待處理圖元、存儲圖元以及并行判斷圖元。
4.根據(jù)權(quán)利要求3所述的方法，其特征在于，還包括根據(jù)所述等待處理圖元和存儲圖 元接收的信息，所述并行判斷圖元確定并行處理成功后，結(jié)束并行處理流程。
5.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述UML時(shí)序圖為內(nèi)部處理圖元時(shí)，所述 內(nèi)部處理圖元表示了內(nèi)部處理邏輯；所述將所述UML時(shí)序圖生成對應(yīng)的活動圖，具體為將所述UML時(shí)序圖的內(nèi)部處理圖元 轉(zhuǎn)換成活動圖的1個(gè)或1個(gè)以上的內(nèi)部處理邏輯圖元和條件判斷圖元。
6.根據(jù)權(quán)利要求5所述的方法，其特征在于，還包括根據(jù)所述1個(gè)或1個(gè)以上的內(nèi)部 處理邏輯圖元接收的信息，所述條件判斷圖元確定內(nèi)部處理成功后，結(jié)束并行處理流程。
7.根據(jù)權(quán)利要求1所述的方法，其特征在于，還包括所述UML時(shí)序圖中各個(gè)處理圖元 之間相互嵌套使用。
8.根據(jù)權(quán)利要求1所述的方法，其特征在于，還包括根據(jù)業(yè)務(wù)處理邏輯，在UML時(shí)序 圖中預(yù)先設(shè)置所述包括分支處理圖元、并行處理圖元、內(nèi)部處理圖元中至少一項(xiàng)。
9.一種活動圖生成工具，其特征在于，包括獲取單元，獲取業(yè)務(wù)處理流程對應(yīng)的UML時(shí)序圖，所述UML時(shí)序圖中包括分支處理圖 元、并行處理圖元、內(nèi)部處理圖元中至少一項(xiàng)；生成單元，將所述UML時(shí)序圖生成對應(yīng)的活動圖。
10.根據(jù)權(quán)利要求9所述的活動圖生成工具，其特征在于，所述生成單元包括分支生成 子單元，并行生成子單元和內(nèi)部生成子單元，其中分支生成子單元，用于將所述UML時(shí)序圖的分支處理圖元轉(zhuǎn)換成活動圖的分支處理 SwitchO圖元，其中所述活動圖的分支處理SwitchO圖元包含的分支處理個(gè)數(shù)與UML時(shí)序圖 的分支處理圖元的分支個(gè)數(shù)相同；并行生成子單元，用于將所述UML時(shí)序圖的并行處理圖元轉(zhuǎn)換成活動圖的等待處理圖 元、存儲圖元以及并行判斷圖元；內(nèi)部生成子單元，用于將所述UML時(shí)序圖的內(nèi)部處理圖元轉(zhuǎn)換成活動圖的1個(gè)或1個(gè) 以上的內(nèi)部處理邏輯圖元和條件判斷圖元。
全文摘要
本發(fā)明提供了利用統(tǒng)一建模語言UML時(shí)序圖開發(fā)的方法和活動圖生成工具。該方法主要包括獲取業(yè)務(wù)處理流程對應(yīng)的UML時(shí)序圖，所述UML時(shí)序圖中至少包括分支處理圖元、并行處理圖元或內(nèi)部處理圖元中一項(xiàng)；將所述UML時(shí)序圖生成對應(yīng)的活動圖。利用本發(fā)明，可以實(shí)現(xiàn)根據(jù)各種業(yè)務(wù)的不同情況，執(zhí)行不同的處理邏輯。
文檔編號G06F9/44GK102141911SQ201010198178
公開日2011年8月3日 申請日期2010年6月3日 優(yōu)先權(quán)日2010年6月3日
發(fā)明者何沁, 龐啟勇 申請人:華為技術(shù)有限公司