機(jī)床設(shè)計(jì)行業(yè)自身的特點(diǎn)是：設(shè)計(jì)工作量大，生產(chǎn)技術(shù)準(zhǔn)備周期長(zhǎng)。這種特點(diǎn)在精密機(jī)床上表現(xiàn)得尤為明顯。由于每種機(jī)床的設(shè)計(jì)參數(shù)不同，結(jié)構(gòu)各異，產(chǎn)品設(shè)計(jì)工作的重復(fù)率低。

一般來(lái)說(shuō)，對(duì)應(yīng)于不同的機(jī)床產(chǎn)品，都要重復(fù)進(jìn)行設(shè)計(jì)、工藝、工裝、技術(shù)文件的準(zhǔn)備，設(shè)計(jì)任務(wù)量特別大，參與設(shè)計(jì)的部門(mén)多，時(shí)間跨度長(zhǎng)，設(shè)計(jì)過(guò)程復(fù)雜，產(chǎn)品數(shù)據(jù)和設(shè)計(jì)過(guò)程管理難度大。數(shù)控機(jī)床信息集成系統(tǒng)是一個(gè)面向多部門(mén)、多用戶(hù)的信息集成系統(tǒng)，系統(tǒng)的訪(fǎng)問(wèn)要求嚴(yán)格，既要求權(quán)限清晰分明，又要求防止權(quán)限的濫用，需要實(shí)現(xiàn)權(quán)限的最小化。傳統(tǒng)的訪(fǎng)問(wèn)控制，例如自主型訪(fǎng)問(wèn)控制（DAC），強(qiáng)制型訪(fǎng)問(wèn)控制（MAC）直接對(duì)用戶(hù)進(jìn)行權(quán)限的授予和取消。當(dāng)用戶(hù)數(shù)量龐大且關(guān)系復(fù)雜時(shí)，權(quán)限的管理就變得復(fù)雜而困難。一個(gè)新權(quán)限的加入或者修改都可能導(dǎo)致需對(duì)源代碼進(jìn)行的修改。信息集成系統(tǒng)一般由很多個(gè)子系統(tǒng)組成，子系統(tǒng)由很多模塊組成，模塊又由很多功能項(xiàng)組成。

本文提出 RBAC 技術(shù)在數(shù)控機(jī)床信息集成系統(tǒng)中的應(yīng)用，在信息集成系統(tǒng)中設(shè)計(jì)和實(shí)現(xiàn)基于角色的訪(fǎng)問(wèn)控制，有效的解決在機(jī)床設(shè)計(jì)過(guò)程中錯(cuò)綜復(fù)雜的訪(fǎng)問(wèn)權(quán)限控制問(wèn)題。

1. 系統(tǒng)方案模型

1.1 J2EE 架構(gòu)

采用 J2EE 企業(yè)平臺(tái)架構(gòu)構(gòu)建數(shù)控機(jī)床信息集成系統(tǒng)。J2EE架構(gòu)集成了先進(jìn)的軟件體系架構(gòu)思想，具有采用多層分布式應(yīng)用模型、基于組件并能重用組件、統(tǒng)一完全模型和靈活的事務(wù)處理控制等特點(diǎn)。本信息集成系統(tǒng)邏輯上分為四層：客戶(hù)層、應(yīng)用層、業(yè)務(wù)層和持久層，如圖 1 所示。

圖 1 信息集成系統(tǒng)邏輯結(jié)構(gòu)圖

a. 客戶(hù)層主要負(fù)責(zé)人機(jī)交互。可以使用戶(hù)通過(guò)Web 瀏覽器訪(fǎng)問(wèn)，也可以提供不同業(yè)務(wù)系統(tǒng)的API、Web Service 調(diào)用。

b. 應(yīng)用層封裝了用來(lái)提供通過(guò)Web 訪(fǎng)問(wèn)本系統(tǒng)的客戶(hù)端的表示層邏輯的服務(wù)。

c. 業(yè)務(wù)層提供業(yè)務(wù)服務(wù)，包括業(yè)務(wù)數(shù)據(jù)和業(yè)務(wù)邏輯，集中了系統(tǒng)業(yè)務(wù)處理。主要的業(yè)務(wù)管理模塊包括項(xiàng)目管理、人員組織管理、設(shè)計(jì)信息管理和權(quán)限管理等幾個(gè)部分。

d. 資源層主要負(fù)責(zé)數(shù)據(jù)的存儲(chǔ)、組織和管理等。資源層提供了大型關(guān)系型數(shù)據(jù)庫(kù)（如Microsoft SQL Server）的訪(fǎng)問(wèn)。

1.2 RBAC 模型

RBAC[5]即角色訪(fǎng)問(wèn)控制(Role Based Access Control)是由美國(guó)Ravi Sandhu 提出的，它解決了具有大量用戶(hù)，數(shù)據(jù)客體和各種訪(fǎng)問(wèn)權(quán)限的系統(tǒng)中的授權(quán)管理問(wèn)題。其中主要涉及用戶(hù)，角色，訪(fǎng)問(wèn)權(quán)限，會(huì)話(huà)等概念。用戶(hù)，角色，訪(fǎng)問(wèn)權(quán)限三者之間是多對(duì)多的關(guān)系。角色和會(huì)話(huà)的設(shè)置帶來(lái)的好處是容易實(shí)施最小權(quán)限原則。在RBAC 模型中，將若干特定的用戶(hù)集合和某種授權(quán)連接在一起。這樣的授權(quán)管理與個(gè)體授權(quán)相比較，具有強(qiáng)大的可操作性和可管理性，因?yàn)榻巧淖儎?dòng)遠(yuǎn)遠(yuǎn)少于個(gè)體的變動(dòng)。通過(guò)引入RBAC 模型，系統(tǒng)的最終用戶(hù)并沒(méi)有與數(shù)據(jù)對(duì)象有直接的聯(lián)系，而是通過(guò)角色這個(gè)中間層來(lái)訪(fǎng)問(wèn)后臺(tái)數(shù)據(jù)信息。在應(yīng)用層次上角色的邏輯意義和劃分更為明顯和直接，因此RBAC 通常使用于應(yīng)用層的安全模型。

RBAC 區(qū)別于原有的角色/用戶(hù)，采用新型的角色/權(quán)限關(guān)系，具有以下兩個(gè)優(yōu)點(diǎn)：

1) 減小了授權(quán)管理的復(fù)雜性，降低管理開(kāi)銷(xiāo)。

2) 靈活地支持企業(yè)的安全策略，并對(duì)企業(yè)的變化有很大的伸縮性。

目的是為了隔離 User(即動(dòng)作主體，Subject)與Privilege(權(quán)限，表示對(duì)Resource 的一個(gè)操作，即Operation+Resource)。

Role 作為一個(gè)用戶(hù)(User)與權(quán)限(Privilege)的代理層，解耦了權(quán)限和用戶(hù)的關(guān)系，所有的授權(quán)應(yīng)該給予Role 而不是直接給User 或Group。Privilege 是權(quán)限顆粒，由Operation 和Resource 組成，表示對(duì)Resource 的一個(gè)Operation。Role-Privilege 是many-to-many 的關(guān)系，這就是權(quán)限的核心。

在以往常見(jiàn)的模型中，對(duì)不同數(shù)據(jù)訪(fǎng)問(wèn)權(quán)限的控制主要通過(guò)不同用戶(hù)進(jìn)入不同的系統(tǒng)界面來(lái)實(shí)現(xiàn)，這樣做的缺點(diǎn)是用戶(hù)的角色不能設(shè)置太多，角色越多，所需要編寫(xiě)的系統(tǒng)界面就越多，這對(duì)于數(shù)控機(jī)床的實(shí)際的設(shè)計(jì)過(guò)程來(lái)說(shuō)，會(huì)大大加重編程的難度并降低信息集成系統(tǒng)完全實(shí)現(xiàn)的可能性。為應(yīng)對(duì)盡可能多的角色要求，本文提出一種通過(guò)分析各種角色的權(quán)限，來(lái)規(guī)定不同的角色的權(quán)限的方法來(lái)控制各個(gè)用戶(hù)的權(quán)限。基于角色的訪(fǎng)問(wèn)控制示意圖如圖2所示。

圖2 基于角色的訪(fǎng)問(wèn)控制示意圖

基于角色的訪(fǎng)問(wèn)控制機(jī)制不同于以往的單層用戶(hù)權(quán)限控制，其在傳統(tǒng)的用戶(hù)權(quán)限控制中加入一層角色層，帶來(lái)以下優(yōu)點(diǎn)：

1). 權(quán)限設(shè)置更加靈活多樣

通過(guò)基于角色的訪(fǎng)問(wèn)控制分離了用戶(hù)層和權(quán)限層，使得不必規(guī)定某個(gè)特定用戶(hù)所具有的權(quán)限，而只需把權(quán)限分成若干集合，這樣的集合就是角色。

2). 編程實(shí)現(xiàn)更加方便

傳統(tǒng)的用戶(hù)權(quán)限機(jī)制通過(guò)給不同用戶(hù)設(shè)置界面入口來(lái)實(shí)現(xiàn)賦予不同用戶(hù)的不同權(quán)限，這樣，每添加一個(gè)用戶(hù)，就需要改變整個(gè)系統(tǒng)的框架。而在用戶(hù)層和權(quán)限層中加入角色層，可以使添加用戶(hù)變得簡(jiǎn)潔，并且通過(guò)修改角色層來(lái)實(shí)現(xiàn)權(quán)限的賦予，會(huì)使編程變得簡(jiǎn)單。

2 用戶(hù)需求的分析

在信息集成系統(tǒng)中，所涉及的用戶(hù)有很多種，從以下的分析就可以看出信息集成系統(tǒng)的權(quán)限控制的復(fù)雜性。在實(shí)際情況中，遠(yuǎn)不止下面所列的三種用戶(hù)，這三種用戶(hù)是最為常見(jiàn)的用戶(hù)，對(duì)于數(shù)控機(jī)床的開(kāi)發(fā)來(lái)說(shuō)，還會(huì)有電氣控制部分的設(shè)計(jì)人員，加工程序的設(shè)計(jì)人員等。

1). CAD 用戶(hù)的需求分析

本信息集成系統(tǒng)的一個(gè)重要功能之一是數(shù)控機(jī)床床身的可視化設(shè)計(jì)。可視化設(shè)計(jì)的一般過(guò)程是指定的設(shè)計(jì)者根據(jù)自己的任務(wù)調(diào)出要修改的基本機(jī)床零件的三維模型據(jù)，發(fā)現(xiàn)與目標(biāo)模型的差別，并修改基本構(gòu)件以形成新設(shè)計(jì)零件。設(shè)計(jì)過(guò)程中要隨時(shí)與其它環(huán)節(jié)聯(lián)絡(luò)，并檢查與不打算修改的構(gòu)件或總成的干涉與協(xié)調(diào)。CAD 軟件是商業(yè)化三維軟件，如Pro/E 等。在調(diào)出具體的CAD 三維數(shù)據(jù)模型前，設(shè)計(jì)者可能需要對(duì)該件進(jìn)行瀏覽，因此將車(chē)身零部件的VRML 模型存入數(shù)據(jù)庫(kù)。為了和其它不使用Pro/E 的人員進(jìn)行模型數(shù)據(jù)庫(kù)交流，還可以生成并保存STEP 文件；當(dāng)然，為了能方便地找到這些數(shù)據(jù)，數(shù)據(jù)庫(kù)內(nèi)還必須保存參照機(jī)床零部件的件號(hào)、件名等信息，另外，諸如零部件的二維圖圖紙?zhí)枴姹咎?hào)、日期等也是不可或缺的信息。對(duì)干數(shù)控機(jī)床，還應(yīng)有該產(chǎn)品的一些說(shuō)明文件。最后，為了使設(shè)計(jì)者在早期對(duì)所設(shè)計(jì)的構(gòu)件的動(dòng)態(tài)特征有所把握，CAD 工作人員應(yīng)能從數(shù)據(jù)庫(kù)獲取CAE 人員對(duì)參考機(jī)床構(gòu)件及設(shè)計(jì)模型動(dòng)態(tài)分析后的信息，因此存有CAE 分析結(jié)果圖和分析結(jié)果描述文件。歸納CAD 人員的需求清單如下：

件號(hào)、件名、版本、CAD 模型數(shù)據(jù)、VRML 模型數(shù)據(jù)、STEP 文件、日期等。

2). CAE 用戶(hù)的需求分析

CAE 分析人員在接受到一個(gè)新的CAD 模型STEP 文件時(shí)，他需要能立即從數(shù)據(jù)庫(kù)里查找到該部件在參考機(jī)床上的典型載荷，他可能還需要知道在該部件中哪個(gè)或哪些零件比較關(guān)鍵，從而應(yīng)該對(duì)其進(jìn)行重點(diǎn)研究并通知CAD 設(shè)計(jì)人員。在對(duì)新的模型進(jìn)行了分析計(jì)算后，他需要調(diào)出參照機(jī)床中對(duì)應(yīng)模型的分析結(jié)果來(lái)進(jìn)行比較判斷。分析結(jié)果包括該模型的靜態(tài)分析以及各階模態(tài)分析。歸納CAE 用戶(hù)的需求清單如下：

件號(hào)、件名、版本、CAE 模型、典型載荷圖、靜態(tài)結(jié)果、模態(tài)分析結(jié)果、結(jié)果說(shuō)明等。

3). 管理人員的需求分析

在企業(yè)內(nèi)部，管理人員因部門(mén)不同，項(xiàng)目不同，他們的需求也是各式各樣。在本系統(tǒng)中，以企業(yè)設(shè)計(jì)部門(mén)級(jí)的信息管理定位，故取項(xiàng)目信息管理來(lái)統(tǒng)一綜合處理有關(guān)信息，因?yàn)槿魏我患O(shè)計(jì)活動(dòng)都可以定義為一個(gè)項(xiàng)目，也必定屬于某個(gè)項(xiàng)目，項(xiàng)目間的時(shí)序、隸屬和成果的給出和轉(zhuǎn)移就是設(shè)計(jì)活動(dòng)的表現(xiàn)形式，其中的信息就是設(shè)計(jì)活動(dòng)的動(dòng)態(tài)信息。比如，有關(guān)人事信息的需求簡(jiǎn)單概括為：管理人員可以知道某部件是由哪些人，在什么時(shí)間設(shè)計(jì)的，以及這些人員的相關(guān)信息。管理人員需求說(shuō)明清單如下：

件號(hào)、件名、設(shè)計(jì)人工號(hào)、設(shè)計(jì)人姓名、設(shè)計(jì)人所屬角色、設(shè)計(jì)人所屬部門(mén)、設(shè)計(jì)人職務(wù)、電話(huà)號(hào)碼、E-mail 地址等。

3 權(quán)限管理數(shù)據(jù)庫(kù)設(shè)計(jì)

根據(jù)RBAC 模型的權(quán)限設(shè)計(jì)思想，建立權(quán)限管理系統(tǒng)的核心對(duì)象模型。如圖3 所示。

圖3 基于角色的數(shù)據(jù)庫(kù)結(jié)構(gòu)

對(duì)象模型中包含的基本元素主要有：用戶(hù)、用戶(hù)組、角色、角色權(quán)限、數(shù)據(jù)對(duì)象、資源對(duì)象、功能和操作。主要的關(guān)系有：分配角色權(quán)限、分配用戶(hù)角色。在基于角色的數(shù)據(jù)庫(kù)結(jié)構(gòu)中：

1) 用戶(hù)：是權(quán)限的擁有者或主體。用戶(hù)和權(quán)限實(shí)現(xiàn)分離，通過(guò)授權(quán)管理進(jìn)行綁定。

2) 用戶(hù)組：一組用戶(hù)的集合，具有相同的權(quán)限分配。

3) 角色：權(quán)限分配的單位與載體。角色通過(guò)繼承關(guān)系支持分級(jí)的權(quán)限實(shí)現(xiàn)。

4) 操作：完成資源的類(lèi)別和訪(fǎng)問(wèn)策略之間的綁定。

5) 權(quán)限：對(duì)受保護(hù)的資源操作的訪(fǎng)問(wèn)許可，是綁定在特定的資源實(shí)例上的。對(duì)應(yīng)地，訪(fǎng)問(wèn)

策略和資源類(lèi)別相關(guān)，不同的資源類(lèi)別可能采用不同的訪(fǎng)問(wèn)模式。例如，頁(yè)面具有能打開(kāi)、不能打開(kāi)的訪(fǎng)問(wèn)模式，菜單具有顯示、不顯示的訪(fǎng)問(wèn)模式，文本編輯框具有可編輯、不可編輯的訪(fǎng)問(wèn)模式。同一資源的訪(fǎng)問(wèn)策略可能存在排斥和包含關(guān)系。例如，某個(gè)數(shù)據(jù)的可修改訪(fǎng)問(wèn)模式就包含了可查詢(xún)?cè)L問(wèn)模式。

4 方案的具體實(shí)現(xiàn)

用戶(hù)的登錄之后，查找該用戶(hù)在數(shù)據(jù)庫(kù)中所對(duì)應(yīng)的權(quán)限并在同一界面中顯示不同的菜單模塊，繼而控制該用戶(hù)可以操作的功能模塊。在建立角色過(guò)程中，角色權(quán)限（role_privilege）可通過(guò)若干個(gè)func_id 累加而成；在程序運(yùn)行中解析角色權(quán)限是個(gè)相反的過(guò)程，要將role_privilege 與func_id 聯(lián)系，來(lái)將role_privilege 分解為權(quán)限，以圖2 為例，角色權(quán)限為1 表示角色具有功能1 到功能4 的所有權(quán)限，而角色權(quán)限為2 表示角色同時(shí)具有角色權(quán)限1 所具有的權(quán)限并具有功能5 和功能6的權(quán)限。

我們可以把以上權(quán)限關(guān)系表示成 Role 2＞Role 1，從某種意義上來(lái)說(shuō)，Role 2 是Role 1的繼承，這意味著Role 2 具有Role 1 所有的功能，所有的較高層次的角色繼承了較低層次的角色的功能。這種繼承我們可以理解為一個(gè)用戶(hù)的所具有的功能多于另一個(gè)用戶(hù)，可以表示成Role 1＞Role 2＜＝＞Role 1.Function＞Role 2.Function。

5 結(jié)語(yǔ)

本文論述了一種基于RBAC 模型的數(shù)控機(jī)床信息集成系統(tǒng)的實(shí)現(xiàn)技術(shù)方案。該權(quán)限管理模型已成功應(yīng)用于系統(tǒng)的設(shè)計(jì)和開(kāi)發(fā)。實(shí)踐表明，采用基于RBAC 模型的權(quán)限具有以下優(yōu)勢(shì)：權(quán)限分配直觀、容易理解，便于使用；擴(kuò)展性好，支持權(quán)限多變的需求；分級(jí)權(quán)限適合分層的組織結(jié)構(gòu)形式；重用性強(qiáng)。