【正文】 型），用戶全名（字符型） 用戶 用戶組映射表：組名（字符型， PK），用戶名（字符型， PK） 用戶組表：組名（字符型， PK），描述（字符型） 角色 用戶組映射表：角色名（字符型， PK），用戶組名（字符型， PK） 角色表：角色名（字符型， PK），描述（字符型） 角色 用戶映射表：角色名（字符型， PK），用戶名（字符型， PK） 用戶組（ Group）信息管理維護(hù) 10 “用戶組列表”界面長(zhǎng)相與“用戶列表”大致相同，但是在“刪除”的處理策略上是這樣的：只有空的用戶組（即沒(méi)有關(guān)聯(lián)到任何用戶）才能夠刪除，否則不予執(zhí)行刪除動(dòng)作并且給用戶以友好的警示信息。 點(diǎn)擊用戶組名超鏈接和“新建”按鈕會(huì)分別轉(zhuǎn)至編輯和新建界面，這兩個(gè)畫面長(zhǎng)相很類似，“編輯用戶組”界面大致如下： 角色（ Role）信息管理維護(hù) “角色列表”界面長(zhǎng)相與“用戶列表”大致相同，但是在“刪除”的處理策略上是這樣的：只有滿足以下條件才能刪除角色， 1）沒(méi)有與任何用戶組關(guān)聯(lián)； 2）沒(méi)有與任何用戶關(guān)聯(lián)； 3）沒(méi)有與任何授權(quán)操作關(guān)聯(lián)。除此以外不予執(zhí)行刪除動(dòng)作并且給用戶以友好的警示信息。 點(diǎn)擊“角色列表”界面的“新建”按鈕會(huì)轉(zhuǎn)至“新建”界面，大致長(zhǎng)相如下： 11 說(shuō)明： 從現(xiàn)實(shí)情況總結(jié)來(lái)看，系統(tǒng)管理員授權(quán)管理的開(kāi)銷有時(shí)還是蠻大的，很多情況下從相近的已經(jīng)授權(quán)的角色復(fù)制權(quán)限然后改一改要比全新從頭授權(quán)要輕松得多。所以，本框架加入“從已有角色復(fù)制權(quán)限”這一功能純粹 是為了便于系統(tǒng)管理員工作。用戶填寫完畢點(diǎn)擊“ Save”，處理完畢后即會(huì)轉(zhuǎn)向角色列表界面。 點(diǎn)擊“角色列表”界面的角色名超鏈接會(huì)轉(zhuǎn)至“編輯”界面，這與“新建”畫面長(zhǎng)相很類似，“編輯角色”界面大致如下： 說(shuō)明： 點(diǎn)擊“授權(quán) ...”時(shí)會(huì)出現(xiàn)角色授權(quán)界面，其長(zhǎng)相大致如下： “增加”的界面大致如下： 12 暫缺 需要關(guān)注一點(diǎn)：系統(tǒng)管理員在對(duì)角色進(jìn)行權(quán)限許可授予時(shí)，往往是工作量巨大而且特別乏味。所以一定要注意盡量降低管理員管理開(kāi)銷。 關(guān)于這一點(diǎn)，請(qǐng)看一個(gè)典型的場(chǎng)景：某個(gè)系統(tǒng)中有一些公共的菜單需要開(kāi)放給系統(tǒng)的每一個(gè)用戶，譬如：“修改密碼”、“關(guān)于 ...”、“系統(tǒng)幫助”等等（朋友，數(shù)一下吧，是不是幾乎每個(gè)系統(tǒng)都有這種類似的情況？），對(duì)系統(tǒng)管理員來(lái)說(shuō)，這無(wú)疑是一種揮之不去的負(fù)擔(dān)，他 /她必須為每個(gè)用戶都指定一遍這些公用菜單的訪問(wèn)權(quán)限 ... 這顯然不是我們希望看到的情景，我們必須為系統(tǒng)管理員減負(fù)！解決方法是單獨(dú)設(shè)置一個(gè)不受訪問(wèn)權(quán)限控制的“非受控資源 /公共菜單按鈕”登記區(qū)，凡在此登記的菜單按鈕都權(quán)限框架都認(rèn)為其可為所有用戶訪問(wèn)。 “編輯”的界面大致 如下： 暫缺 變更密碼功能 這個(gè)功能是提供給 Login 到 WebApp 系統(tǒng)中的每個(gè)用戶（包括系統(tǒng)管理員和普通用戶）的，該資源應(yīng)屬于不受控資源，不在權(quán)限管理的授權(quán)范圍，人人可訪問(wèn)。權(quán)限框架在提供這個(gè)功能的同時(shí)亦應(yīng)有機(jī)制保證這一點(diǎn)。進(jìn)一步說(shuō)，系統(tǒng)投入運(yùn)行后，新增加一個(gè)角色 /用戶，即便在沒(méi)有接受系統(tǒng)管理員任何授權(quán)時(shí)缺省都是可訪問(wèn)這個(gè)功能的。 WebApp 開(kāi)發(fā)者亦需要明白這個(gè)道理并適當(dāng)安排菜單入口（可能的菜單項(xiàng)名字是“變更密碼”）。 這個(gè)功能的頁(yè)面長(zhǎng)相大致如下： 8 登錄（ Login）認(rèn)證功能 13 原則：可插入（ pluggable）性，低侵入性。 設(shè)想一個(gè)場(chǎng)景：一個(gè) WebApp 系統(tǒng)從初期的 Demo 原形（ prototype）逐步演化而來(lái)，到最后，功能基本完備了，是要考慮用戶登錄認(rèn)證這一塊功能的時(shí)候了。這時(shí)引入本權(quán)限框架，開(kāi)發(fā)人員不需要改動(dòng) WebApp 任何既有代碼，甚至于可以完全不曉得此登錄認(rèn)證功能的存在，即可享用框架帶來(lái)的登錄認(rèn)證功能，完全是一種通過(guò) runtime 配置即可插入使用的機(jī)制。這就是我們想要提供的登錄認(rèn)證功能。 [技術(shù)實(shí)現(xiàn)相關(guān)： ] 或許會(huì)考慮使用 Servlet specification 的 Filter機(jī)制來(lái)實(shí)現(xiàn)。這種情況， WebApp 開(kāi)發(fā)人員只需把框架提供的攔截器通過(guò) WebApp部署描述文件配置好即可，它會(huì)攔截所有的 HttpRequest，若該用戶已經(jīng)是合法登錄用戶則放行，否則轉(zhuǎn)向 Login 頁(yè)面。為了方便上層 WebApp，該頁(yè)面由權(quán)限框架提供缺省實(shí)現(xiàn)，無(wú)需 WebApp編碼實(shí)現(xiàn)。如果要求與相應(yīng) WebApp 的顯示風(fēng)格匹配，只要替換 CSS 文件即可。若 CSS還無(wú)法滿足要求，則可直接替換掉該頁(yè)面文件，但這時(shí)有一點(diǎn)要求：用戶名域、密碼域的元素名稱以及 Form的 Method、Action 取值都必須與原文件相同。 Login 頁(yè)面的 Form 的 action 指向的 target必須是權(quán)限框架提供，因?yàn)檫@涉及到認(rèn)證的動(dòng)作以及下一步的對(duì)所請(qǐng)求資源的授權(quán)驗(yàn)證。 再設(shè)想一個(gè)場(chǎng)景： WebApp 系 統(tǒng)已經(jīng)投入使用，有一個(gè)用戶的職責(zé)就是每天察看某一張報(bào)表的數(shù)據(jù)?？墒且吹竭@張報(bào)表他必須：每次登錄然后等待出現(xiàn)系統(tǒng)主界面，然后層層深入到第三層菜 單，點(diǎn)擊其中的一個(gè)菜單項(xiàng)，出現(xiàn)相應(yīng)的畫面，在此畫面上點(diǎn)擊某個(gè)超級(jí)鏈接，才能看到這張報(bào)表。很繁瑣！但這個(gè)用戶是個(gè)聰明人，他把這個(gè)超級(jí)鏈接放到瀏覽器 的“我的最愛(ài)”或者“收藏夾”中，期望每次點(diǎn)擊此鏈接，系統(tǒng)登錄后便直接轉(zhuǎn)到這個(gè)請(qǐng)求的鏈接，他就可以看到報(bào)表了（我僅僅是看指定的報(bào)表而已，為什么需要 每次看到主界面和討厭的三層菜單？）。 上段描述的場(chǎng)景很典型，也合情合理。但并不是所有的應(yīng)用都有這種情況，有的系統(tǒng)就要求不管你請(qǐng)求的是什么資源，每次都必須把你帶到主界面。 那么權(quán)限框架如何處理這兩種不同的情況？支持其中的哪一種？解答是：兩種都支持，做成靈活的配置項(xiàng)，根據(jù)具體 WebApp 項(xiàng)目要求，通過(guò) runtime 配置即可。 [WebApp 開(kāi)發(fā)人員相關(guān)： ] 關(guān)于用戶名 /密碼等信息的存儲(chǔ)約定，請(qǐng)參見(jiàn)“ 數(shù)據(jù)庫(kù)表協(xié)議 ”。 9 訪問(wèn)控制（ Access control）功能 此部分功能的用戶是 WebApp 開(kāi)發(fā)人員。 14 正如權(quán)限模型一節(jié)所說(shuō)，解決復(fù)雜的權(quán)限管理問(wèn)題的過(guò)程可以抽象概括為：判斷【 Who是否可以對(duì) What 進(jìn)行 How 的訪問(wèn)操作（ Operator）】這個(gè)邏輯表達(dá)式的值是否為 True 的求解過(guò)程。當(dāng)然，判定當(dāng)前登錄用戶是誰(shuí)（那個(gè)用戶，什么角色等），那是權(quán)限框架的事情，所以 WebApp開(kāi)發(fā)人員在程序中只需向權(quán)限框架提問(wèn)：“可以對(duì) What 進(jìn)行 How的訪問(wèn)操作嗎？”。這就夠了，這就是權(quán)限框架要提供給上層 WebApp 的 API。 大家要知道，一個(gè)系統(tǒng)在設(shè)計(jì)階段便需劃分：整個(gè)系統(tǒng)應(yīng)該有多少子系統(tǒng)、多少子模塊、多少菜單、多少頁(yè)面按 鈕，其中有哪些應(yīng)該是受控資源，它的訪問(wèn)權(quán)限是怎樣的。這是權(quán)限定義，完成的是 Privilege（ How）與 Resource（ What）的聲明。直到系統(tǒng)管理員進(jìn)行了權(quán)限分配時(shí)，權(quán)限才真正與資源實(shí)例聯(lián)系到了一起，注冊(cè)于某個(gè)地方（也許是數(shù)據(jù)庫(kù)，也許是文件）。程序執(zhí)行到向權(quán)限框架提問(wèn)：“可以對(duì) What 進(jìn)行 How的訪問(wèn)操作嗎？”時(shí)，框架會(huì)到權(quán)限注冊(cè)處去匹配尋找，便可以做出該用戶是否有權(quán)訪問(wèn)該資源的判定。 基本上，訪問(wèn)控制可以有兩個(gè)控制級(jí)別： ? 粗粒度：表示類別（ Type）級(jí)，即僅考慮對(duì)象的類別 (the type of object)，不考慮對(duì)象的某個(gè)特定實(shí)例。比如，查詢 /報(bào)表管理中，創(chuàng)建、刪除，對(duì)所有的用戶都一視同仁，并不區(qū)分操作的具體對(duì)象實(shí)例。 ? 細(xì)粒度：表示實(shí)例（ Instance）級(jí)，即需要考慮具體對(duì)象的實(shí)例 (the instance of object)，當(dāng)然，細(xì)粒度是在考慮粗粒度的對(duì)象類別之后才再考慮特定實(shí)例。比如，查詢 /報(bào)表管理中，刪除某報(bào)表，需要區(qū)分該報(bào)表實(shí)例是否為當(dāng)前用戶所創(chuàng)建。 下面分別從這兩個(gè)方面介紹本框架的支持情況： 系統(tǒng)功能項(xiàng)權(quán)限控制（粗粒度權(quán)限控制 ） 這種控制是系統(tǒng)最常見(jiàn)的需求，不同用戶對(duì)系統(tǒng)功能項(xiàng)有不同的限制，通常表現(xiàn)為某些系統(tǒng)菜單、頁(yè)面按鈕的不可見(jiàn)或灰掉。在這一控制層面，權(quán)限框架提供直接完全支持。 [WebApp 開(kāi)發(fā)人員相關(guān)： ] 必須預(yù)先對(duì)全系統(tǒng)的受控以及非受控的功能項(xiàng)（菜單、按鈕）作一個(gè)全局規(guī)劃，保證每一個(gè)功能項(xiàng)分配有一個(gè)全局唯一的標(biāo)識(shí)號(hào)，并向權(quán)限框架注冊(cè)。然后只要在需要決定是否顯示某個(gè)菜單、按鈕之前，調(diào)用權(quán)限框架 API向權(quán)限框架提類似問(wèn)題：“可以對(duì) new MenuPermession(“”) 進(jìn)行訪問(wèn)操作嗎？”即可，根據(jù)結(jié)果的 Ture/False決定是否顯示這個(gè)菜單、按鈕。 防止直接 URL 侵入 15 因?yàn)槭?Web 應(yīng)用程序的緣故，瀏覽器不受 WebApp或權(quán)限框架控制，所以單純采用上一節(jié)的介紹的方法會(huì)導(dǎo)致安全隱患。 請(qǐng)看一個(gè)場(chǎng)景：因?yàn)闄?quán)限不允許，用戶張三的菜單“報(bào)表”被封掉了，在系統(tǒng)給他展現(xiàn)出來(lái)的界面中根本看不到這個(gè)菜單，于是他根本無(wú)法訪問(wèn)“報(bào)表”，OK，權(quán)限系統(tǒng)贏了！可是，有一天張三上廁所的時(shí)候無(wú)意中看到李四在使用“報(bào)表”菜單，這小子打了鬼主意，乘李四離開(kāi)座位的時(shí)候偷偷到他機(jī)器上，點(diǎn)擊該菜單并記下其 URL，然后回到自己機(jī) 器前，在瀏覽器的地址欄敲入這個(gè) URL，哇，“報(bào)表”界面出現(xiàn)了！瞧，這一下，權(quán)限系統(tǒng)輸了，輸?shù)煤軕K！ 所以，可以看到，這種“直接 URL 侵入”的問(wèn)題是非常危險(xiǎn)的，特別是在 Web應(yīng)用中你根本無(wú)法阻止用戶在地址欄輸入任何東西。 權(quán)限框架必須負(fù)責(zé)解決這個(gè)問(wèn)題，這也是他的職責(zé)所在！怎么解決？哦，有一種簡(jiǎn)單的解決方法如下： [WebApp 開(kāi)發(fā)人員相關(guān)： ] 除了保證每一個(gè)功能項(xiàng)（菜單、按鈕）分配有一個(gè)全局唯一的標(biāo)識(shí)號(hào)外，每一個(gè)功能項(xiàng)還必須分配有一個(gè)全局唯一的 HttpRequest URL 并向權(quán)限框架注冊(cè)。這樣的話，被限制 訪問(wèn)的功能項(xiàng)，首先不會(huì)顯示出來(lái)，其次就算用戶在地址欄直接輸入 URL，也會(huì)被權(quán)限框架的攔截器攔截然后判定為非法，然后阻攔掉。于是系統(tǒng)就是安全的了！ 業(yè)務(wù)面上的定制權(quán)限控制（細(xì)粒度權(quán)限控制） 系統(tǒng)功能項(xiàng)權(quán)限控制可以解決菜單按鈕是否可見(jiàn)的問(wèn)題，譬如：所有 RD 研發(fā)員角色都可以看見(jiàn)報(bào)表列表界面的“刪除”按鈕、可以執(zhí)行這個(gè)動(dòng)作，而其他角色則不可以。這種方法確實(shí)可以解決類別（ Type）級(jí)的粗粒度權(quán)限控制問(wèn)題。 但是它解決不了這樣的實(shí)例（ Instance）級(jí)的細(xì)粒度業(yè)務(wù)規(guī)則級(jí)別的問(wèn)題，譬如：雖然所有 RD 研發(fā)員角色都可以看見(jiàn)報(bào)表列表界面的“刪除”按鈕、可以執(zhí)行這個(gè)動(dòng)作，但是只有選中的該報(bào)表是當(dāng)前用戶所創(chuàng)建才可以真正允許刪除。 正如前文“范圍界定”一節(jié)所說(shuō)，對(duì)于類似于這種，各種各樣業(yè)務(wù)層面上的權(quán)限管理要求，由于權(quán)限框架無(wú)法預(yù)知也不能做任何假定，所以這也是框架實(shí)現(xiàn)難點(diǎn)所在。本框架的解決方案是以 API 的形式提供擴(kuò)展點(diǎn)， Web 應(yīng)用開(kāi)發(fā)者在擴(kuò)展點(diǎn)上插入滿足自己業(yè)務(wù)規(guī)則要求的權(quán)限許可模塊即可。由于外部擴(kuò)展也是建立在權(quán)限框架的游戲規(guī)則上的，所以就保證了整個(gè) Web 應(yīng)用的權(quán)限管理都是在協(xié)調(diào)一致的機(jī)制下進(jìn)行。 14 大學(xué)本科生畢業(yè)設(shè)計(jì) （論文） 撰寫規(guī)范 本科生畢業(yè)設(shè)計(jì)（論文）是學(xué)生在畢業(yè)前提交的一份具有一定研究?jī)r(jià)值和實(shí)用價(jià)值的學(xué)術(shù)資料。它既是本科學(xué)生開(kāi)始從事工程設(shè)計(jì)、科學(xué)實(shí)驗(yàn)和科學(xué)研究的初步嘗試，也是學(xué)生在教師的指導(dǎo)下，對(duì)所進(jìn)行研究的適當(dāng)表述，還是學(xué)生畢業(yè)及學(xué)位資格認(rèn)定的重要依據(jù)。畢業(yè)論文撰寫是本科生培養(yǎng)過(guò)程中的基本訓(xùn)練環(huán)節(jié)之一，應(yīng)符合國(guó)家及各專業(yè)部門制定的有關(guān)標(biāo)準(zhǔn)，符合漢語(yǔ)語(yǔ)法規(guī)范。指導(dǎo)教師應(yīng)加強(qiáng)指導(dǎo)，嚴(yán)格把關(guān)。 論文結(jié)構(gòu)及要求 論文包括題目、中文摘要、外文摘要、目錄、正文、參考文獻(xiàn)、致謝和附錄等幾部分。 題目 論文題目應(yīng)恰當(dāng)、準(zhǔn)確地反映論文的主要研究?jī)?nèi)容。不應(yīng)超過(guò) 25 字，原則上不得使用標(biāo)點(diǎn)符號(hào)，不設(shè)副標(biāo)題。 摘要與關(guān)鍵詞 摘要 本科生畢業(yè)設(shè)計(jì)（論文）的摘要均要求用中、英兩種文字給出，中文在前。 摘要應(yīng)扼要敘述論文的研究目的、研究方法、研究?jī)?nèi)容和主要結(jié)果或結(jié)論，文字要精煉，具有一定的獨(dú)立性和完整性，摘要一般應(yīng)在 300 字左右。摘要中不宜使用公式、圖表，不標(biāo)注引用文獻(xiàn)編號(hào)，避免將摘要寫成目錄式的內(nèi)容介紹。 關(guān)鍵詞 關(guān)鍵詞是供檢索用的主題詞條，應(yīng)采用能覆蓋論文主要內(nèi)容的通用技術(shù)詞條（參照相應(yīng)的技術(shù)術(shù)語(yǔ)標(biāo)準(zhǔn)），一般列 3～ 5 個(gè)，按詞條的外延層次從大到小排列，應(yīng)在摘要中出現(xiàn)。 目錄 目錄應(yīng)獨(dú)立成頁(yè)，包括論文中全部章、節(jié)的標(biāo)題及頁(yè)碼。 15 論文正文 論文正文包括緒論、論文主體 及結(jié)論等部分。 緒論 緒論一般作為論文的首篇。緒論應(yīng)說(shuō)明選題的背景、目的和意義，國(guó)內(nèi)外文獻(xiàn)綜述以及論文所要研究的主要內(nèi)容。 文管類論文的緒論是畢業(yè)論文的開(kāi)頭部分，一般包括說(shuō)明論文寫作的目的與意義，對(duì)所研究問(wèn)題的認(rèn)識(shí)以及提出問(wèn)題。緒論只是文章的開(kāi)頭，不必寫章號(hào)。 畢業(yè)設(shè)計(jì)（論文）緒論部分字?jǐn)?shù)不多于全部論文字?jǐn)?shù)的 1/4。 論文主體 論文主體是論文的主要部分，要求結(jié)構(gòu)合理，層次清楚，重點(diǎn)突出，文字簡(jiǎn)練、通順。論文主體的內(nèi)容要求參照《大學(xué)本科生畢業(yè)設(shè)計(jì)（論文）的規(guī)定》第五章。 論文主體各章后應(yīng)有一節(jié)“本章小結(jié)”。 結(jié)論