MyCollege.Net系統規劃與總體設計

2024-07-10 12:59:15

字體：大中小

來源：轉載

供稿：網友

目錄

一、前言…………………………………………………………………………………1

二、問題定義……………………………………………………………………………1

三、設計目標.…..………………………………………………………………………2

四、設計任務……………………………………………………………………………2

五、可行性可分析………………………………………………………………………3

六、總體設計……………………………………………………………………………5

七、mycollege.net中子系統的體系結構………………………………………………7

八、mycollege.net所倡導的應用系統開發流程………………………………………9

九、mycollege.net中的身份認證與權限控制策略……………………………………11

十、mycollege.net中公共數據資源數據訪問策略……………………………………11

十一、統一身份認證子系統中的關鍵技術……………………………………………12

十二、系統測試…………………………………………………………………………13

十三、小結…………………………………………………………………………………16

十四、參考文獻……………………………………………………………………………16

mycollege.net系統規劃與總體設計

王云

西南師范大學計算機與信息科學學院重慶 400715

摘要：mycollege.net系統采用基于xml的開放式結構，為mycollege.net內部其它應用系統的開發和應用提供了一種嶄新的思路。應用系統可以通過mycollege.net的核心子系統提供的統一身份認證服務和公共資源共享服務，提高各種數據資源在系統級的復用度，在簡化系統開發，增強系統功能、增強用戶登錄體驗等方面收到良好的效果。

abstract：the system named mycollege.net, which uses opened architecture based on xml, provides a fresh idea and method for its internal subsystems and other applications. the applications can make data more re-usable on system level and achieve better effect on simplifying system development, enhancing system functions and user logon experience through the universal identity authentication service and the common resource sharing service of mycollege.net core subsystems.

關鍵詞 webservice 統一身份認證子系統公共資源管理與共享子系統

一、前言

在mycollege.net系統的開發中，作為組長，我主要負責整個系統的規劃和總體設計，負責小組成員之間的協調并提供技術支持。針對問題定義提出了相應的解決方案，確定了mycollege.net的兩個核心子系統并劃定了各自的功能，并在技術上論證了開發該系統的可行性。為了降低其它小組成員開發各個子系統的難度，在總體設計中我定義了核心子系統開發所應采用的軟件體系結構，給核心子系統的體系機構提供了參考。最后，制定了mycollege.net下其它應用系統的開發流程、身份認證及數據訪問所應采用的策略。

二、問題定義

在高校不同的信息管理系統之間，比如圖書館管理系統和學籍管理系統中，都有對于系統用戶進行管理的功能，不同的用戶有不同的用戶名，密碼，權限等等。在傳統的開發方式下，不同的信息管理系統中都必須處理用戶身份認證和授權控制問題。但實際上它們的處理方式基本是一致的，由于這個功能不能在不同的系統之間復用，這就造成了系統的重復開發。另一方面，當一個特定的人同時充當多個不同信息管理系統中具有特定權限的用戶時，他需要重復的在各個系統中注冊，同時必須記住在不同系統下的用戶名和密碼等信息，這自然就帶來了眾所周知的人為安全問題：如果他采用同樣的用戶名和密碼，那么一旦不小心泄露出去后果將不堪設想；如果他采用完全不同的用戶名和密碼，那么他就需要記住這些不同的信息，這對用戶來說無疑是一個挑戰。因此，能否有一種方法，讓用戶注冊一次就可以在不同的系統中使用受限的服務，從而避免重復注冊呢？

圍繞著不同應用系統之間各種資源復用的主題，繼續深入下去后我們發現，上述的圖書管理系統和學籍管理系統都要使用全校學生的基本信息，實際上還有很多其他的信息管理系統在使用著這些基本信息。那么學生的基本信息是存放在一個單獨的數據庫服務器上呢還是單獨存放在獨立的服務器上呢？

在前一種方式下，其它的系統要遠程連接到數據庫服務器上，學生基本信息數據庫的結構一旦確定就不能輕易改動，否則會牽一發而動全身，造成其它系統的不穩定。而且還存在一個跨平臺的問題，雖然不同的應用系統采用標準的sql語句與數據庫進行通信，但當信息管理系統運行在異構的網絡環境中或運行在不同的系統平臺上時，如何與數據庫服務器互連又是一個棘手的問題。

而后一種方式雖然數據庫獨立性比較強，但它又會帶來數據的重復存儲，數據不一致性增大，系統的重復開發等問題。

歸根揭底，所有的這些應用系統缺乏一種統一的規劃，軟件工程中的復用技術無法在系統級實現，系統之間公共數據資源不能被共享，通訊協作在系統級難以實現。因此我們的設計《基于xml的開放式集成系統（mycollege.net）設計與開發》試圖對此問題進行統一的規劃，在全局上給出一個盡量完善的解決方案。同時順應現代軟件網絡化的潮流，加強各種應用子系統之間通過網絡進行協同工作的能力。

三、設計目標

以一種靈活的方式集成高校內部已有的、現存的和未來的各種應用系統，對這些應用系統提供最基本的服務，最大限度的提高各個應用系統之間的資源共享程度，增強不同應用系統之間的協同工作能力，最終促進高校的網絡化管理。

四、設計任務

mycollege.net運行的支撐環境是統一身份認證子系統（uia）和公共資源管理與共享子系統（cresource）。這兩個核心子系統對mycollege.net中其它子系統的開發運行提供了支撐環境。需要說明的是應用系統和子系統在mycollege.net下是同一個概念，所有的應用系統一旦集成進來就成為mycollege.net下的子系統。

公共課成績管理子系統是為了便于公共計算機教育部對于公共課成績的管理及網上發布而開發的。這個子系統的開發完全是在我們的mycollege.net下進行的，遵循我們制定的mycollege.net下應用系統開發流程，使用了mycollege.net中的各種服務，包括統一的身份認證、集中的基于角色的授權控制以及對于公共數據資源的訪問。另一方面該系統的成功開發及與mycollege.net核心子系統的順利集成也將證明mycollege.net設計的先進性和可行性。

五、可行性分析

開發這樣一個復雜的系統，究竟在技術上能不能實現、能否產生預期的效果呢？通過上述設計任務的描述，我們知道該系統最核心的部分是uia和cresource，而最大的困難就是尋找一種靈活的、簡單的技術實現網絡環境下數據的傳輸和交換，這種技術必須是標準的、跨平臺的，網絡結構無關的。幸運的是在microsoft.net平臺上，有一種叫webservice的技術，這種技術完全可以滿足我們的要求。同時.net平臺還有很多其它的優點，現分述如下：

（一） microsoft.net特點

1、創建高度分布的應用程序

商務應用程序的趨勢一直是高度分布的模型。下一代的應用程序要將它們的元素分布在各個機構中。它與當今的主要模型形成了鮮明的對比——在當今的主流模型中，應用程序（除了基于瀏覽器的客戶程序）的所有元素都位于一個機構的內部。

2、簡化軟件開發

開發人員需要能夠將注意力集中在應用程序的業務邏輯處理部分，而不是為狀態管理、伸縮性等編寫邏輯代碼。在.net中，編寫internet應用程序不需要具備太多的internet專門的技術知識。

3、在web上的更好的用戶界面

用于internet的用戶界面開發也需要盡可能地類似于本地訪問。盡管使用本地wubdiws界面比瀏覽器更能提供優秀靈活的界面，但是這種界面需要專門的運行平臺（.net），實際應用中并不能保證每一臺客戶機都裝有.net。

4、簡化部署

dll hell的問題以及安裝基于窗體的應用程序需要的大量工作量，是當

前部署問題的兩個例子。.net的目標是使它的部署和在dos上一樣簡單——只需將編譯的模塊復制到系統上之后它即可。無需注冊，也沒有guid。

5、對各種語言的支持

所有支持.net的語言使用相同的數據類型和接口規范，這就能夠讓所有的.net語言透明地進行交互操作。一種語言能夠輕而易舉地調用另外一種語言，甚至能夠繼承另一語言編寫的類，并擴展它們，其它平臺都沒有這種級別的語言互操作性。

6、平臺的可擴展性

.net完全基于對象的方法旨在通過繼承來擴展基本功能。該平臺的功能大致分為幾部分。允許各部分在需要時被替換為新版本。在將來，很可能將與外部世界連接的新方式添加到windows form, web form和web服務中。.net的體系結構使這一點變得十分切合實際。

7、未來的可移植性

.net盡量抽象掉底層平臺，將操作系統分離開來。程序員面臨的不是操作系統而是統一的.net平臺。.net的主要部件已經提交給標準化組織并打算將.net的核心在不同的操作系統上實現標準化。這樣最終的目標是一次編譯，可以將其移動到不同的操作系統中的另一個.net中，無需任何改動。

（二） webservice機制

在.net中，一個webservice就是一個可編程的單元，它可以提供一系列的服務，比如一些商務處理。而且通過使用互聯網的標準（比如xml和http），這個服務可以被很多不同的系統所利用。正是由于xml和其它互聯網標準，各種程序間的兼容問題才得以解決，webservice才成為現實。webservice利用四個模塊：directory，discovery，description及wire format來對所提供的服務進行描述并提供一個標準的數據傳送格式。directory提供了一個集中的位置供webservice的提供者發布他們所開發的webservice的相關信息。discovery用于幫助webservice客戶端了解到webservice的存在以及在哪里可以找到webservice的描述文檔。description定義了webservice的行為以及告訴webservice客戶端如何使用它。為了保證通用性，webservice使用開放的協議，這些協議幾乎可以被所有支持最常用的系統所使用，比如通常使用的http和soap（簡單對象訪問協議）協議。而soap是webservice的核心協議，它是一種基于xml的用于分散和分布環境下信息交換的輕型協議。

六、總體設計

基于xml的開放式集成系統（mycollege.net）提供了一個開放式的體系結構來集成校園內部已有的、現有的和未來的各種應用系統；以xml技術提供靈活的系統間數據交換格式，增強系統間的協同工作能力，降低各種應用系統的冗余開發，提高應用系統開發效率。系統的整體結構如下：

mycollege.net中有兩個核心的子系統：統一身份認證子系統（uia）和公共資源管理與共享子系統（cresource）。這兩個核心子系統對mycollege.net中其它應用系統的開發運行提供了支撐環境。

統一身份認證子系統提供了統一的應用系統身份認證及用戶身分認證服務、集中的基于角色的授權控制服務。統一身份認證子系統的單點登陸技術改善了用戶在不同應用系統中的登陸體驗。就如微軟的.net passport一樣，用戶只需登陸一次，在訪問其它的應用系統時便自動登陸無需輸入用戶名和密碼。任何一個在統一身份認證子系統中注冊的用戶在整個mycollege.net中都可以使用統一的身份標識來使用各種應用系統，在不同的應用系統之間切換時將進行自動登陸。應用系統對于用戶的授權訪問以及用戶對于個人隱私信息的發布在統一身份認證子系統中都有嚴格的授權控制。

公共資源管理與共享子系統提供了mycollege.net中各種應用系統最常使用的公共數據資源，并將這些數據資源通過webservice技術發布在網絡上，應用系統可以通過網絡受控的使用這些數據資源。不同的應用系統對于不同的資源類型及資源屬性有不同的讀寫訪問權限。這樣各應用系統的開發將有很強的靈活性，開發者可以針對該系統未來的運行環境（如網絡狀況等）制定出相應的數據訪問策略，在減少數據存儲的冗余性，增強數據更新的同步性，數據使用的跨平臺性等方面獲得最好的效果。

公共數據資源是這樣的數據資源：它是某一組應用系統所使用的數據資源的交集，如果cresource中不存在這個交集，則cresorce的管理員可以通過cresource中的管理功能創建這個資源并設置它的屬性。所有這些足以保證公共數據資源滿足絕大多數的應用系統需求，最大限度的提高公共數據資源的共享度。在我們的cresource中，它至少包含學校的系科專業設置信息及學生的基本信息，如學號、姓名、性別等信息。至于學生是否轉系、轉系的詳細信息則不應該保存在cresource中，因為它應該是由學籍管理系統所存儲和處理的。

公共課成績管理子系統將作為一個相對獨立的系統單獨開發，在開發完成后將與mycollege.net集成起來。

各個子系統之間的集成是采用webservice技術，由于各個子系統在公布其自身的web服務的同時也要請求其它子系統提供的web服務，因此所有的子系統便通過webservice之間的調用松散地耦合在一起。

下面通過圖示說明一下公共課成績管理子系統在mycollege.net下的工作過程：

假如用戶要使用course2，他在請求登陸時通過uia中統一的“登陸”按鈕被course2重定向到uia的統一登陸界面，用戶輸入他的用戶名和密碼，uia通過身份驗證后將驗證信息和用戶在course2下所具有的權限（角色）返回給course2，這樣course2便借助于uia完成了對用戶的身份驗證和權限分配。在用戶使用course2的過程中，可能要訪問某個學生的基本信息，course2首先在本地數據庫中查詢數據，如果該數據不存在便調用cresource中的webservice接口獲取數據，并進行處理。最后當用戶準備離開course2時，他通過uia中統一的“安全退出”按鈕退出登陸。或者通過單點登陸技術自動登陸到其它的應用系統。如果用戶之前沒有統一的身份標示或不具備使用course2的權限，那么他可以先到uia上申請一個統一的身份，并申請在course2中的權限。如果course2的管理員同意你的申請并啟用了你的角色，那么你就可以使用你的用戶名和密碼使用course2。

七、 mycollege.net 中子系統的體系結構

在一個大型的應用系統中，簡單的表示層、邏輯層、數據訪問層并不能滿足要求。mycollege.net結合了.net平臺的特點對簡單的三層結構做了擴充，使之能夠滿足網絡環境下絕大多數應用系統的需要，對mycollege.net下的各個子系統及應用系統的開發起到指導性的作用。擴充的體系結構圖如下所示：

表示層有windows form和web form兩種形式，對應于c/s結構和b/s結構。通過webservice技術兩種結構可以共存，且c/s結構在.net平臺上的開發非常簡單，幾乎不用考慮高深的網絡編程。

邏輯層被細化為商務外觀層（businessfacade）和商務邏輯層（businessrules）。前者主要是封裝應用系統中分散的商務邏輯，給表示層提供一個簡潔的無狀態的調用界面。它實際上是對系統需求在函數接口層的精確描述，即該層類中的函數完全表達了系統需求中涉及的功能。這樣，一旦該層設計完成，表示層的開發者就可以利用該層進行獨立的界面開發。businessrules層主要是表達商務規則。例如對于uia中對于用戶email地址的驗證，簡單的驗證條件是email地址中必須包含@符號，而復雜的驗證方法將會通過某種網絡服務查看該地址是否存在并有效。對于email的驗證就是一條商務規則，就應該在businessrules層中處理。

webservice層是這種體系結構中新出現的層，它其實相當于網絡版的businessfacade層，系統中的某些功能可能需要公開并通過internet發布，并允許用戶針對這些功能定制不同的用戶界面（如c/s和b/s）。

數據訪問層（dataaccess）負責數據庫的處理，它僅僅對數據庫中的數據進行添加刪除修改，并不考慮這些操作是否滿足商務規則，因此重要的操作必須先通過businessrules層的審查才可以被調用。dataaccess層一般是直接建立在.net平臺上的ado.net層之上，可以對數據庫進行靈活的操作，但是為了簡化系統的開發，微軟提供了一套工具microsoft data application block(簡稱dab)，用于簡化ado.net的使用。我們的dataaccess層可以直接建立在dab層上，在大多數情況下能夠滿足要求。當然，你也可以兩種方式混合使用。

最后一個層是model層。在設計了如此復雜的系統結構后，我們不得不考慮一個問題：各層之間的數據如何進行傳遞。如何將從數據庫中提取出來的dataset傳遞給businessfacade層或businessrules層？由于各層設計時所使用的數據格式可能不同，在傳遞過程中如何進行格式轉換？model層的出現正是解決這一問題，它定義了各個層之間傳遞的數據實體的數據結構，在ado.net中它可以完全由dataset代替，也可以使用自定義的類來實現，兩種方式各有各的優缺點。

在n層結構中，層間的調用關系必須遵循一定的原則，這樣才能體現出分層結構的優點。一般來說，各層只能被它的上層調用，不能被同一層或下層調用。businessfacade層中涉及到商務規則的函數應先調用businessrules層的函數，由businessrules層完成商務規則的實施并調用dataaccess層執行具體的數據庫操作；不涉及商務規則的函數可以直接通過dataaccess層來完成。webservice層與businessfacade層幾乎一樣，不同的是它可以調用businessfacade中的函數（相當于同一層的調用）。dataaccess層作為最低層可以被其上的任意一層調用。而model層由于作為各層之間數據交換的媒介，能夠被dataaccess及其上的任意層次調用。

關于各層之間狀態的處理，這里有一個說明。狀態是對象在指定時間內保持存在并可用，以提供對屬性訪問和事件激發的訪問支持。例如在dataaccess層可以打開數據庫連接并一直保持連接狀態，這樣在每次訪問數據的時候就可以在上次結束的地方開始，而不用重新打開數據連接和查找。在有狀態的系統中雖然可以更靈活的訪問數據，但系統的開銷可能會非常大。比如在數據庫連接中，如果連接的用戶從10個猛增至1000個，那么數據庫就需要維持1000個打開的連接，這對系統資源的浪費是很大的。無狀態對象的頻繁創建雖然耗費時間，但它提供了極強的可伸縮性，當用戶增加時，每個用戶的請求處理完后就立刻銷毀相應的對象，釋放系統資源，系統的負擔增加只是在對象的創建時間上有所延遲，但這可以通過對象池的緩存功能來解決。我們在層間傳遞的數據對象（model層對象）很明顯就是一個無狀態的對象，它只負責傳遞數據實體，并沒有保存任何狀態。因此，如果你愿意使用無狀態的結構，那最好不要在層間調用時為節省對象的創建時間而緩存對象。

上述結構具有很強的靈活性，在mycollege.net下，各個子系統的開發可以參考上述的體系結構，并進行適當的裁剪。例如在公共資源管理與共享子系統中，由于子系統相當于一個網絡版的dataaccess層，其并不涉及復雜的商務邏輯，因此就可以將businessrules層去掉，將簡單的邏輯加入到businessfacade層中。

八、 mycollege.net所倡導的應用系統開發流程

(一) 將應用系統注冊成為mycollege.net的成員站點（membersite）

應用系統開發者首先向uia提出申請，要求成為uia的成員站點，同時提供其應用系統所需要的用戶角色（相當于設置其用戶的權限級別，如管理員、游客等）等信息。如果開發者的申請被uia的管理員所批準，那么他將得到一個usid，這個usid將成為此應用系統在mycollege.net中的唯一身份標示。

(二) 開發你的應用系統

此時你的應用系統已經有資格使用mycollege.net內部的核心服務了。首先是使用uia提供的身份認證、基于角色的授權控制及單點登陸等服務。但是這并不意味著應用系統必須使用這些服務，它可以有選擇的使用其中的某些服務。舉例來說，如果應用系統對于權限的控制不是很嚴格，只要是mycollege.net中的用戶都可以使用此系統，那么它就可以不使用權限控制服務而僅僅使用身份認證服務。但是，mycollege.net將強烈建議開發者使用統一身份認證子系統中的全部功能，因為這樣做不僅能夠大大提高應用系統的開發效率，同時也給應用系統的使用者帶來諸如單用戶名、單密碼及單點登陸等使用上的方便。

mycollege.net的核心服務還包括公共資源管理與共享服務。mycollege.net中的公共資源管理與共享子系統管理著大量的數據，且這些數據對于大部分校園信息管理系統都是公共的、必不可少的，例如學生的學號、姓名、系科等基本信息；教師的教工號，學校的系科專業信息等等。這些公共數據資源對于很多校園應用系統的開發都是必需的數據。任何一個加入mycollege.net中的應用系統都可以在得到公共資源管理與共享子系統的授權后受控的使用特定的數據。mycollege.net所使用的webservice技術將保證在不同的網絡結構和系統平臺上開發者都可以輕松的使用這些數據服務。

現在我們知道在mycollege.net中存在兩個核心子系統以及大批的應用系統，實際上除了兩個核心子系統提供服務外，其它的應用系統也可能向外部提供web服務。我們的圖書館管理系統可以提供這樣一個服務：根據學生的學號查詢學生的借閱情況。這樣新加入的應用系統還可以使用mycollege.net中已有的應用系統所提供的web服務。

(三) 安裝部署你的應用系統

在mycollege.net中，應用系統不再是一個孤立的單機系統，它是一個網絡化的軟件系統，通過網絡使用mycollege.net中核心服務和其它應用系統公開的web服務（相當于web服務的消費者），同時發布自己的web服務（相當于web服務的生產者）。它們組成了一個復雜的網狀結構并且相互協同工作。由于系統的網絡化與系統間的網狀化，其安裝部署將與傳統的桌面系統有所不同，必須采取特殊措施，以簡化系統的安裝部署。在mycollege.net中，對于應用系統的安裝部署由下列建議：

盡量使應用系統安裝在服務器端，做到客戶端的0安裝，對于b/s結構這是很簡單的。對于c/s結構，由于其采用的是windows界面，要求必須運行在本地客戶機上，但這并不意味著客戶端系統必須安裝在客戶機上。在.net中可以利用遠程窗體將客戶端系統安裝在服務器上，然后做一個頁面提供一個超鏈接。客戶機運行系統時將其下載到本地緩存運行。這樣就避免了客戶端的安裝部署，從而避免了軟件升級時帶來的大量客戶端版本更新問題。版本更新時只需重新部署到服務器上即可，.net中的增量下載技術將保證客戶機上運行的始終是應用系統的最新版本。

(四) 應用系統的運行環境

由于應用系統是mycollege.net的一個組成部分，它的正常運行離不開核心子系統和其它應用系統的支撐，因此應用系統的正常運行必須由可靠的網絡連接來保證。對于某些純粹的數據獲取系統來說，開發者可以采用特殊的技術（如將數據緩存在本系統中）來降低應用系統對于網絡的依賴性。

九、 mycollege.net中的身份認證與權限控制策略

mycollege.net下面的uia子系統中的身分認證與權限控制使用起來是非常方便和靈活的，應用系統可以根據自己對安全性的要求有選擇的使用其中的服務。

純粹的身份認證策略：有些應用系統對于安全性的要求并不是很高，比如學生成績查詢系統，只要是mycollege.net下的具有統一身份的用戶都可以使用，對用戶沒有嚴格的授權控制。在這種情況下，使用uia中的身份認證服務是非常方便的，應用系統開發者只需在uia中申請注冊并獲取自己的usid后就可以調用uia中的身份認證服務。

身分認證與授權控制的綜合使用策略：對于安全性要求比較高的應用系統，除了使用uia的身份認證服務外，使用uia的授權控制服務是非常必要的。uia中的授權控制是集中的基于角色的授權控制。應用系統開發者在申請獲取usid的同時，向uia提供自己所開發的應用系統中所要設置的用戶角色。例如一個典型的應用系統所包含的角色有管理員和一般用戶。在uia中的注冊工作完成后，開發者就可以使用其中的身份認證與權限控制服務。

十、 mycollege.net中公共數據資源訪問策略

mycllege.net下的公共數據資源獲取有三種不同的策略：同步訪問策略、緩存策略及異步訪問策略，三種不同的策略各有個的優缺點及應用場合。

同步訪問策略：應用系統自身并沒有設置專門的數據庫或文件來保存所需的公共數據資源，每當應用系統需要使用公共數據資源時，就通過網絡調用cresource子系統中的webservice獲取數據，而cresource中保存的是mycllege.net體系下的最新數據。因此該策略能夠保證應用系統同步獲取到最新的數據，使得不同應用系統中的數據達到高度的一致性。這種數據訪問的方式的缺點是對網絡的性能和可靠性要求比較高，應用系統中對于cresource中webservice的頻繁調用會加重cresource服務器的負擔。

緩存策略：在該策略中，應用系統需要設置本地數據庫來緩存所需的公共數據資源。應用系統在訪問所需的公共數據資源時先試圖從本地數據庫中檢索數據，如果命中本地數據庫那么就直接調出來使用。如果本地數據庫中沒有緩存所需的數據，如果沒有命中本地數據庫，那再通過webservice獲取最新的數據，同時采取一定的緩存策略將獲取到的數據緩存到本地數據庫中，以支持后面對于該數據的高速訪問。這與計算機系統中的虛擬存儲器的工作原理有點類似。這種數據訪問策略克服了同步策略中對網絡高性能高可靠性的苛刻要求，因為大量的公共數據資源被緩存在本地數據庫中。但是，它引入了一個問題，如果數據在訪問的過程中被修改了，該怎么辦？與虛擬存儲器類似，采用何種寫回策略將修改的數據寫回到cresource是一個值得應用系統開發者思考的問題。

異步訪問策略：該策略同緩存策略類似，同樣要在應用系統中設置本地數據庫。但是在數據訪問地過程中并沒有緩存策略中的那么復雜，應用系統僅僅是定期或不定期的訪問cresource子系統，獲取最新的公共數據資源，然后更新本地數據庫，同時將在本地更新后的數據寫回到cresource中。雖然數據更新不能同步，但對周期性更新的公共數據資源比較適用。

應用系統開發者在具體使用時應考慮系統運行所處的網絡環境和自身硬件設施的配置，根據這些條件制定出最合適的公共數據資源訪問策略。

十一、統一身份認證子系統中的關鍵技術

mycollege.net中最關鍵的技術是uia中的身份認證與權限控制。在asp.net中通過相應的函數對頁面實現身份認證是非常簡單的，但是這個簡單的函數并沒有提供在頁面中附加用戶角色的功能。因此我們必須利用asp.net中身份認證的底層函數來實現附加用戶角色的功能。下面是部分重要地代碼：

login.ascx控件中附加用戶角色的代碼：

private void button1_click(object sender, system.eventargs e)

{

//對參數進行規范化處理，去掉多余的空格

string nickname=textbox1.text.trim();

string password=textbox2.text.trim();

//調用uia的webservice來完成用戶身份驗證

if(new businessfacade.usersystem().checkuser(nickname,password))

{

//將登錄用戶的信息加入到session中

model.userdata user=null;

user=new businessfacade.usersystem().getuser(nickname);

this.session["user"]=user;

//創建身份驗證票

formsauthenticationticket ticket = new formsauthenticationticket (1,nickname,datetime.now, datetime.now.addminutes(30), false,"","/") ;

string hashticket = formsauthentication.encrypt (ticket);

httpcookie usercookie = new httpcookie(formsauthentication.formscookiename, hashticket);

//添加到cookies中

response.cookies.add(usercookie);

//跳轉到適當的頁面

if(this.session["returnurl"]!=null)

response.redirect (this.session["returnurl"].tostring(),true);

else response.redirect ("default.aspx",true);

}

}

global.asax中恢復用戶名和角色的關鍵代碼：

protected void application_authenticaterequest(object sender, eventargs e)

{

httpapplication app = (httpapplication) sender;

httpcontext ctx = app.context ; //獲取本次http請求相關的httpcontext對象

if (ctx.request.isauthenticated == true) //驗證過的用戶才進行role的處理

{

formsidentity id = (formsidentity)ctx.user.identity ;

formsauthenticationticket ticket = id.ticket ; //取得身份驗證票

string[] roles = ticket.userdata.split (',') ; //將身份驗證票中的role數據轉成字符串數組

ctx.user = new genericprincipal (id, roles) ; //將原有的identity加上角色信息新建一個genericprincipal表示當前用戶,這樣當前用戶就擁有了role信息

}

}

十二、系統測試

(一) 子系統獨立測試

mycollege.net系統由兩個核心的子系統和一個應用子系統組成，在開發過程中三個子系統幾乎是同步進行的，因此在子系統開發的中后期就有必要進行獨立的測試。由于兩個核心子系統相當大一部分功能是通過webservice技術發布的，如果要通過界面進行完整的白盒測試，必須編寫相應的客戶端測試程序，這顯然會增加程序的開發量。而采用webservice自動生成的調試界面又有很大的局限性，因此在子系統獨立測試中我們主要采用了黑盒測試技術對代碼進行審查。

(二) 綜合測試

mycollege.net是一個集成的系統，子系統的單獨測試成功并不能保證整個系統的協調工作，因此對其進行綜合的集成測試以確保整個系統能夠正常工作是非常重要的。在測試的過程中因為已經有子系統集成進來，因此采用的是白盒測試技術。對于兩個核心子系統的集成測試步驟如下：

1．對cresource的集成測試。我們開發的一個學生信息處理實用工具sget是完全建立在cresource所提供的服務上的。sget的主要提供在網上查詢學生基本信息的功能，通過輸入學號或姓名等關鍵字從cresource中調出相應的數據，sget的成功運行只能說明對cresource的初步集成成功，因為sget只用到了其中的查詢功能。對于cresource的更進一步的測試還有待進行。下面是sget測試中的一個界面。

2．于uia和cresource更進一步的綜合測試由公共課成績管理子系統course2和學生信息處理實用工具sinput來完成，因為這兩個子系統都使用mycollege.net中核心子系統的服務。綜合測試中這兩個子系統同時進行，因為要測試uia中具有統一身份的用戶在兩個不同的成員站點間相互切換的功能，因此該部分測試的重點是設計完整的用戶名測試用例。由于版面原因，下面只列出了部分測試用例：

在測試過程中對于上述測試用例，我們進行了密碼修改和角色的申請等修改操作后，course2和sinput中所有的結果都是在預料之中，這就充分說明了我們整個系統確實能夠協調的工作。下面是uiasdk中windows form形式的統一登錄窗體在不同的用例下所顯示的登錄失敗信息：

十三、小結

在兩個多月的時間中，我帶領我們小組圓滿的完成了畢業設計的任務。作為整個小組的組長，我有更多的機會參與到畢業設計的各個過程中，對于軟件開發過程中的各項活動有了充分的了解。畢業設計不僅是一項技術性的工作更是一項工程性的工作，它需要的不僅僅是我們對技術的掌握，更需要工程化的管理方法、開發方法及小組內各成員之間的相互協作。在開發的過程中，我們的小組成員表現出了高度的協同工作能力，為以后從事軟件開發工作奠定了良好的基礎。由于時間關系，有部分實現未達到當初的設計目標，在該項目下一步的開發中應重點解決單點登錄的難題。最后，本次畢業設計能夠順利完成離不開我們指導老師鄒顯春老師的指導和幫助，盧心紅老師、陳武老師、聞曉老師、李運剛老師在此過程中也給予了極大的幫助，對他們的幫助表示衷心的感謝。還有小組所有成員對我的大力支持，在此對他們表示衷心的感謝！

十四、參考文獻

[1] 邵維忠、楊芙清.面向對象的系統設計.清華大學出版社.

[2] 方貴賓等.uml和統一過程.機械工業出版社.

[3] 覃征.軟件體系結構.西安交通大學出版社.

[4] 吳煒煜.面向對象分析設計與編程.清華大學出版社.

[5] 魏胤紅譯.asp.net分布式數據應用程序高級編程.清華大學出版社.

[6] 張加榮譯.vb.net高級編程.清華大學出版社.

上一篇：學習筆記《.NET框架程序設計（修訂版）》－－第三章共享程序集（3）

下一篇：學習筆記《.NET框架程序設計（修訂版）》－－第三章共享程序集（2）