趙 賽，韓 坤，張 廷

(安徽廣播電視大學 a.信息與建筑工程學院；b.信息技術(shù)與網(wǎng)絡管理中心， 合肥 230022)

一、引言

目前，信息化技術(shù)越來越多地應用于生活工作中，給人們帶來了極大的便利。在高校的日常工作中，員工請假、設備維修申請、財務報銷等工作，采用傳統(tǒng)的紙質(zhì)操作方式，對于申請者既耗時又費力，并且領(lǐng)導在外出時也無法及時執(zhí)行相關(guān)批閱審查[1]。顯然，傳統(tǒng)的工作方式已經(jīng)無法滿足管理需求。

作為智慧校園建設的一項指標，辦公業(yè)務的信息化建設已經(jīng)成為衡量高校信息化水平的重要標志[2]，辦公信息化取代傳統(tǒng)紙質(zhì)操作成為必然趨勢。雖然很多高校已經(jīng)具有了自動化辦公系統(tǒng)，但是這些系統(tǒng)對高校的具體業(yè)務針對性不強，并不能滿足高校具體業(yè)務的需求[3]。工作流技術(shù)實現(xiàn)了業(yè)務過程的自動化操作，適合于行政辦公、財務審批等日常事務處理[4]，已經(jīng)越來越多地運用于企事業(yè)單位管理中。業(yè)務流程模型注解BPMN(Business Process Modeling Notation)作為一種符號標注方法，能夠以圖形化方式幫助業(yè)務人員設計業(yè)務流過程[5]，已經(jīng)成為業(yè)務流程建模標準。本文采用支持BPMN 2.0規(guī)范的Flowable工作流引擎，結(jié)合高校中行政管理業(yè)務，設計并實現(xiàn)了一個高校辦公系統(tǒng)，使用表明能夠滿足高校個性化業(yè)務的需求，促進了業(yè)務流程各個環(huán)節(jié)的規(guī)范化和標準化，解決了用戶“多跑腿”問題，提高了工作效率。

二、系統(tǒng)功能需求分析

高校管理工作中，任務的辦理是根據(jù)單位組織邏輯結(jié)構(gòu)進行分工的。業(yè)務工作的執(zhí)行，需要職能部門人員在規(guī)定時間內(nèi)，按照要求處理所負責環(huán)節(jié)的工作，而工作任務需要在多個部門之間進行流轉(zhuǎn)。同時，任務邏輯是指一項工作的各個環(huán)節(jié)的處理過程，每個環(huán)節(jié)稱為一個任務，由組織邏輯中的人員進行辦理[6]?；谀掣咝５臉I(yè)務需求，系統(tǒng)功能模塊如圖1所示，分為組織結(jié)構(gòu)、日志模塊、流程管理。

圖1 功能模塊

(一)組織結(jié)構(gòu)

組織結(jié)構(gòu)是整個系統(tǒng)運行的基礎(chǔ)，是高校組織邏輯結(jié)構(gòu)以及組織之間關(guān)系的設計，保證了對系統(tǒng)用戶的認證，對資源的可定制化訪問。一般由超級管理員負責維護，設置用戶賬戶數(shù)據(jù)，并根據(jù)需求分配角色，而不同的角色關(guān)聯(lián)了不同的資源，實現(xiàn)對系統(tǒng)不同的操作權(quán)限，從而系統(tǒng)能夠穩(wěn)定地運行。組織結(jié)構(gòu)由用戶管理、角色管理、權(quán)限管理、字典管理四個子模塊構(gòu)成。

1.用戶管理

用戶管理是用于維護系統(tǒng)用戶數(shù)據(jù)的，實現(xiàn)對用戶賬號的分配，用戶信息的維護，只有分配了賬號的用戶才能訪問管理系統(tǒng)。在建立新用戶時，除了需要設置姓名、年齡、性別等基礎(chǔ)性數(shù)據(jù)外，還需要根據(jù)需求給用戶分配角色，并且同一個用戶可以擁有多個角色。

2.角色管理

角色是對一組資源的訪問權(quán)限的集合，對用戶設置相同的資源訪問權(quán)限時，可以設置同樣的角色，從而可以簡化授權(quán)管理。角色和組織結(jié)構(gòu)直接相關(guān)，一般相對固定，創(chuàng)建后不會因為用戶變化而變化。角色由管理員用戶根據(jù)業(yè)務崗位進行設計，并且可以把多個角色分配給同一個用戶。角色管理是對角色信息的維護，實現(xiàn)對角色的增刪改查操作。其中角色添加時進行資源訪問權(quán)限的設置，并且可以在角色編輯中進行更改。

3.權(quán)限管理

權(quán)限是對不同角色的用戶在訪問系統(tǒng)資源時所具有的不同安全策略，用戶只能訪問權(quán)限規(guī)則授予的資源。權(quán)限管理包括了對訪問用戶進行賬戶信息的身份認證以及分配指定資源給不同用戶不同的訪問權(quán)限，用戶操作系統(tǒng)資源時，需要通過系統(tǒng)的身份認證，并且具有操作該資源的權(quán)限時才可以對其進行操作。身份認證是對訪問系統(tǒng)的用戶進行驗證，只允許驗證通過的用戶進入，避免非法用戶的訪問。資源授權(quán)是指把系統(tǒng)中的各個功能看作資源，必須授權(quán)才能實現(xiàn)資源的查看或操作，用于控制不同身份的用戶訪問不同的資源。

4.字典管理

字典代表業(yè)務系統(tǒng)不變的基礎(chǔ)數(shù)據(jù)，是業(yè)務系統(tǒng)中使用比較頻繁的管理對象和數(shù)據(jù)指標，便于用戶查詢使用。通過對這些字典的維護管理，可以提高數(shù)據(jù)的重復利用率，提高用戶的個性化需求。

(二)日志模塊

日志模塊是對系統(tǒng)啟動和運行狀態(tài)以及用戶訪問系統(tǒng)時操作記錄的管理，用于系統(tǒng)的安全管理以及追蹤問題原因。包括操作日志和系統(tǒng)日志，其中操作日志用于記錄用戶的日常訪問操作，便于系統(tǒng)管理員查看用戶行為事件；系統(tǒng)日志用于保存系統(tǒng)運行中產(chǎn)生的事件以及發(fā)生錯誤時的異常事件，便于系統(tǒng)開發(fā)人員進行故障追蹤和修復。

(三)流程管理

流程管理模塊主要包括高校工作常用的工作流模型，具體有請假申請、財務報銷審批、工作的請示、校內(nèi)設施維修申請等。在使用時，流程發(fā)起者可以根據(jù)需求，選擇工作流模型，填寫業(yè)務表單，提交后發(fā)起流程，流程在后臺會自動流轉(zhuǎn)到下一個業(yè)務審批者進行辦理，最后一個審批人辦理結(jié)束，此次流程結(jié)束，或者在任意環(huán)節(jié)被駁回給流程發(fā)起者，由其決定重新申請或者終止流程。用戶可以根據(jù)需求，動態(tài)指定任務的辦理者，并且可以查看已經(jīng)完成的任務、發(fā)起過的流程、待完成的任務，監(jiān)控參與承辦的流程各個環(huán)節(jié)的執(zhí)行情況。

三、系統(tǒng)的總體設計

本文采用B/S結(jié)構(gòu)實現(xiàn)，用戶不用安裝專用的客戶端，使用瀏覽器就可以訪問，并且不會隨著系統(tǒng)的升級而影響系統(tǒng)的訪問，方便用戶異地辦公使用。系統(tǒng)架構(gòu)如圖2所示，采用目前比較常用的Spring Boot并結(jié)合MyBatis數(shù)據(jù)持久層框架進行設計，數(shù)據(jù)庫使用MySQL關(guān)系型數(shù)據(jù)庫。前端渲染使用了Thymeleaf模板引擎，其具有HTML的特點，可以很方便地看到實現(xiàn)效果。業(yè)務控制層使用了Controller-Service-Dao的組織方式，實現(xiàn)控制邏輯、業(yè)務操作、數(shù)據(jù)訪問的模塊化，增加代碼重用性。

圖2 系統(tǒng)架構(gòu)

四、系統(tǒng)的實現(xiàn)

(一)基礎(chǔ)模塊的實現(xiàn)

為了更好地控制不同的人員在系統(tǒng)中擁有不同的資源操作權(quán)限，系統(tǒng)中集成了Shiro框架，并采用了基于資源的權(quán)限控制RBAC(Resource-Based Access Control)策略。Shiro是一個使用Java開發(fā)的，易于使用且比較流行的安全框架，用于執(zhí)行用戶認證、授權(quán)訪問資源、管理連接會話等功能。系統(tǒng)中把可以操作的事物稱為資源，只有被授予了對應權(quán)限的用戶，才能操作對應的資源。權(quán)限模型可以通過圖3表示，角色是權(quán)限的集合，而同一個權(quán)限可以屬于不同的角色，用戶可以具有多個角色，而同一個角色也可能包含不同的用戶，所以用戶和角色、角色和權(quán)限資源之間都是m：n的對應關(guān)系，因此增加用戶角色表和角色權(quán)限表來把三者進行連接起來，設計成1：n關(guān)系以滿足數(shù)據(jù)庫設計原理。

圖3 權(quán)限管理模型

系統(tǒng)中的資源按照訪問方式分為匿名資源和授權(quán)資源，匿名資源是指無須系統(tǒng)中注冊就可以訪問的資源，授權(quán)資源是指需要認證的資源，必須是合法用戶且擁有訪問權(quán)限才可以訪問的資源。在訪問系統(tǒng)資源時，對于授權(quán)資源，Shiro會要求用戶進行認證，認證成功后，則會判斷訪問的url是否授權(quán)給此用戶，如果未授權(quán)，則提示無操作權(quán)限，否則可以直接訪問。并且，Shiro也可以配置匿名訪問的資源，任何用戶都可以訪問這些資源，如圖4所示。通過對資源認證授權(quán)的方式，來保證資源的操作安全。

圖4 資源訪問驗證流程

(二)工作流的實現(xiàn)——以請假申請為例

BPMN作為一種流程標記符號規(guī)范，已經(jīng)在業(yè)務流程設計和實現(xiàn)中被廣泛使用。在其2.0版本中，引入了流程元模型和執(zhí)行語義，業(yè)務發(fā)生過程使用標準圖元描述，保證了使用不同的引擎執(zhí)行相同的流程時都會得到相同的結(jié)果[7]。BPMN常用的圖形元素有事件、活動、網(wǎng)關(guān)以及順序流[8]，其對應的符號如表1所示。

表1 BPMN常用符號

Flowable工作流引擎能夠解析bpmn或者bpmn20.xml為后綴名的BPMN文件，以任務驅(qū)動的方式按照流程定義的規(guī)定執(zhí)行，在業(yè)務流工作中，任務會自動推送到承辦人的待辦任務中，無須主動獲取。根據(jù)某高校的請假申請的業(yè)務流程，設計了如圖5所示的BPMN工作流程，具體執(zhí)行過程如下：

圖5 請假申請流程

1)請假申請者發(fā)起流程，在彈出的請假表單中填寫具體信息，包括了請假起止日期、請假類型、說明信息以及有關(guān)證明材料。提交表單后，流程正式啟動。后臺根據(jù)分析判斷自動決定下一步的流轉(zhuǎn)路徑。

2)輔導員登錄系統(tǒng)，在待辦任務列表中會看到申請請求，決定是否批準申請，并填寫批準意見。如果不同意，可以點擊駁回按鈕，流程會回退給流程發(fā)起者。

3)后臺會根據(jù)請假天數(shù)，通過排他網(wǎng)關(guān)決定流轉(zhuǎn)的下一個節(jié)點。請假天數(shù)不超過3天，則可以直接經(jīng)過學院教務科審核備案，如果同意申請，則流程結(jié)束。如果駁回申請，則流程會回退給流程發(fā)起者。請假天數(shù)大于3天，并且不超過30天的情況下，必須先經(jīng)過學院分管領(lǐng)導審核同意后，才能經(jīng)過學院教務科審核備案，全部同意申請后流程結(jié)束。如果學院分管領(lǐng)導不同意，則填寫拒絕原因，流程回退給發(fā)起者。請假天數(shù)大于30天，則學院教務科審核同意后，需要學校教務處審核備案，如果同意申請，則請假流程結(jié)束，否則，流程回退給流程發(fā)起者。

4)如果流程退回給流程發(fā)起者，則發(fā)起者根據(jù)駁回原因，選擇補充請假說明信息或者材料，繼續(xù)再次申請，或者直接終止流程，請假流程也同樣結(jié)束。

(三)流程運行

流程定義設計好后，使用Flowable引擎的RepositoryService服務提供的接口部署到系統(tǒng)中，然后通過RuntimeService服務可以啟動執(zhí)行流程。用戶登錄系統(tǒng)，通過對應的業(yè)務申請按鈕填寫業(yè)務表單，提交表單就可以啟動對應業(yè)務流程。在各個承辦者辦理任務時，都可以看到前面各個環(huán)節(jié)執(zhí)行者的審批意見，并且可以實時跟蹤查看流程執(zhí)行的全過程。當學院教務科工作人員登錄系統(tǒng)后，在自己的待辦任務中，可以看到需要辦理的所有工作任務，如圖6所示。

圖6 任務管理

點擊辦理后，可以查看到詳細的請假申請信息，填寫審批意見，執(zhí)行同意或駁回操作，如圖7所示。

圖7 申請辦理

五、結(jié)語

目前，工作流技術(shù)已經(jīng)廣泛應用于各種系統(tǒng)中，用來處理行政辦公等日常事務。BPMN 2.0作為一種符號標記的流程規(guī)范，以其簡單、易用、形象化的符號被廣泛使用。Flowable是基于BPMN2.0的流程引擎，解決了傳統(tǒng)方式中難以處理的流程邏輯問題，能夠很靈活的處理流程的變化。對BPMN2.0常用元素進行了介紹，并以某高校的請假流程為例，介紹了流程定義的設計?；赟pring Boot框架，集成了前端Thymeleaf頁面模板、安全認證Shiro模塊、數(shù)據(jù)庫持久層Mybatis插件，并采用Flowable工作流引擎設計并實現(xiàn)了高校辦公系統(tǒng)，用于實現(xiàn)高校辦公中工作流業(yè)務的自動化，讓工作人員從繁雜的事務性工作中解放出來，提高了工作效率。