设计及实作以元件为基础之网路教学系统

1、設計及實作以元件為基礎之網路教學系統蔡明宏 朱治平國立成功大學資訊工程系摘要 近年來,由於全球資訊網(World Wide Web, WWW)的興起,帶動電子商務的蓬勃發展。為求降低成本及增加軟體再利用率,軟體發展的趨勢逐漸走向以元件為基礎的建構方式,如此不僅為應用程式帶來維修時的彈性與便利,更可縮短開發的時間。 微軟(Microsoft)的DNA (Distributed interNet Application)是一個以元件為基礎且可在任何網路上交通之應用程式框架(Framework)。藉由其元件技術(DCOM/ActiveX),將主從式架構分為資料處理層、商業邏輯層與使用者介面展示層,使

2、得程式發展者可依此三層式架構分別地設計開發。但此架構仍屬於抽象層面的概念,缺少可讓程式師遵循的思考邏輯。因此本文以此一架構為目的,透過系統需求分析,提出推導出此三層元件的服務功能方法,並實際實作出一套以元件為基礎的網路教學系統。1.簡介 軟體的再利用(reuse)一直是軟體發展方法上的重要議題。早先的結構化系統發展方法是一種功能導向的設計方式,但依其方式卻很難從舊有的系統中粹取出可重複使用的程式單元。於是強調資料封裝與繼承的物件導向設計方法漸漸被採用,只是其中仍存在著許多待解決的問題,比方說,不同的程式語言本身有其獨特的設計方式(例如各種資料型態在記憶體中分配的大小與位置),使得依不同語言所實

3、作的程式單元彼此間無法溝通,而我們卻無法限制程式師都用同一種語言開發系統。再者,應用程式一但由編譯器產生之後,他日發現對其中的程式碼有更佳的演算法可改進其效能,或因應商業的需求需改變程式碼的計算邏輯,我們仍必須就整個應用程式重新撰寫編譯連結,此舉不僅浪費人力與時間,更難保程式的相容性。於是以介面(interface)為基礎的軟體元件設計方式解決了不同實作語言間的相容性問題,再配合各廠商為物件的生成、資源的分配管理、不同行程(process)間的資訊傳遞等提供了一種底層的服務機制,使得物件導向技術得以延伸,並趨向於提供比物件更完善的服務功能-元件。 目前市場上的元件介面規格主要有Microsof

4、t的ActiveX/DCOM (Distributed Component Object Model)、Sun Microsystems的Java-Beans,以及IBM及物件標準組織OMG (Object Management Group)所主導的CORBA(Common Object Request Broker Architecture)等系統,而軟體元件之發展技術主要著重在元件的開發、再用,以及組裝元件成為應用系統。因此如何利用元件技術去開發具延展性的系統是我們所關心的一項重要議題。本研究以微軟的元件介面規格,遵循其所提出的三層式DNA架構,探討如何去規劃設計出所須之服務元件,並以網路

5、教學系統作為案例,依所提出之方法步驟實際去開發實作,並探討以此三層式元件技術所開發出的系統與一般的應用程式有何不同之優缺點。2. 背景及相關研究DNA (Distributed interNet Applications)DNA是Microsoft發展的一組用來架構三層式(three-tier)應用系統的技術4,包含有IIS(Internet Information Server)、ASP(Active Server Pages)、MTS(Microsoft Transaction Server)、COM(Component Object Model)、ADO(ActiveX Data Obj

6、ects)等技術。在DNA架構下,ASP網頁構成網站的主要內容,資料物件(Data Object)是唯一能從永續儲存體(資料庫或檔案)讀取資料及將資料寫入的元件,其主要的目的是將存取過程細節封裝起來,包含與資料庫連線之驅動程式(如ODBC、JDBC),使得邏輯層物件(Business Object)可專注於商業邏輯的功能,而可不需注意資料真正的儲存方式細節。商業邏輯物件則封裝了應用程式的邏輯,控制執行順序。典型高階的邏輯層物件將從使用者處收集資訊與傳送資訊給使用者的情境(scenario)封裝起來。舉例而言,在一個借貸款的商務系統中,使用者經由使用者展示層所顯示的介面中填入顧客編號及所續借貸之

7、金額後,邏輯層物件及從資料物件擷取相關顧客資料,並由其所訂定的商務規則(Business rule)中(例如老顧客的利息較低),算出所應償還之本利和,並透過使用者展示層告知使用者。當商務規則有所變動時,我們只要將其邏輯層物件抽換掉,即可在最小的影響下更新此系統之功能服務,或者底層的資料庫系統(DBMS)有所變遷,只要保持其介面的一致性,將以不同的資料庫連線驅動程式資料物件取代即可。在展示層方面,ASP藉由HTML與CSS (Cascading Style Sheets)描述資料的展現及版面的設定,並以Script語言作資料傳送前的欄位檢查、處理不同事件與呼叫元件等6。而所呼叫的元件包含執行於用

8、戶端的ActiveX Control元件和執行於Server端的ASP內建元件及使用者自行開發的元件,其整個運作機制如圖一所示。3.設計方法 由於資料物件是扮演邏輯層物件和資料的中介角色,因此我們設計此類別時必須考慮系統有哪些資料？邏輯層物件會需要用到何種服務？為了使資料物件能夠滿足邏輯層物件的需求,在設計資料物件的介面時應考慮到要提供何種服務給邏輯層物件,因此我們整個設計思考流程應從系統的需求分析,來考慮商業邏輯層物件會提供哪些功能來處理可能的需求,而處理過程中會用到哪些資料物件的存取方法。資料物件應依此來思考應提供何種介面以供使用。 <圖一> DNA框架元件軟體之運作機制 一種

9、方法是以屬性為基礎的有狀態(stateful)資料物件解決方式。也就是以資料物件中的屬性對應到永續資料,然後提供方法(method)來存取物件中的屬性。但是此種作法的資源管理過於複雜(比如說保留資料庫連線與鎖定(Lock)的時間分配問題),且負載(Overhead)過重。由於資料物件不屬於特定的使用者(client),所以我們將採用無狀態(stateless)資料物件的方式,讓資料物件所提供的服務與資料物件狀態無關,而只是單純地透過物件將所有的資料經由方法呼叫(Method call)傳回商業邏輯層,也就是說所有特定功能所需的資料都必須由商業邏輯層傳遞到資料物件,而這個行為所產生的所有資料都將

10、被傳回到使用者端。一旦方法呼叫完成,資料便不需存在,所以其佔用server的資源較少,也大大簡化了其中的複雜度。 由於資料的存取不外乎包含新增(Add)、修改(Update)、刪除(Delete)、查詢(Query),因此我們為每個資料表定義一個新增(Add)方法,再由商業邏輯層的需求及資料表的欄位名稱(Field name),找尋可能會作為將來邏輯層物件刪除的鍵(key)欄位,以及可能修改與查詢的欄位名稱集合來設計N個刪除與修改方法。在此同時我們有可能會發現之前所設計的永續資料模型(檔案系統或資料庫系統)會有所遺漏或不足,這時再修正我們的永續資料模型。 至於要如何找出商業邏輯物件及其所提供之

11、服務方式(function)呢？我們可以從使用案例(Use Case)的情境(scenario)分析中識別出商業邏輯物件所應提供之服務功能並依據下列幾項考量來設計邏輯層物件:· 如何使設計的方法(Method)能發揮個別的功能,並能組合成較高階的操作。· 可以直接讓展示層使用,並能滿足商業需求。· 因為將展示層跟邏輯層不一定在同一台機器,因此應儘量降低彼此間資料傳遞的負荷,這可從參數的傳遞及資料型態來考量。· 邏輯物件執行的成功或失敗應和客戶端的成功或失敗分開來,所以邏輯物件應有良好的錯誤處理機制,並能回報給客戶端程式知道。· 將相似的需求分組

12、成介面,如果有安全性的考量再分別分開。 原則上我們以每個使用案例為類別分割單位,理由是同一使用案例的功能需求叫相關,遇到有安全性考量的方法(method)再另外分出來。整個系統設計步驟如下1. 藉由需求分析,導出使用案例。2. 從使用案例情境(scenario)描述中找出實體(entity),而實體可以是一個實際存在的物件,如特定的人、車、房子或職員,也可以只是概念上存在的物件,如工作、討論區、或課表。並從實體中找出描述它的屬性。比如說課表這個實體而言,我們可以找出課程的編號、課程名稱、授課老師、開課系所等屬性,然後再判斷該資料庫或是目錄檔案結構儲存。拿學生作業這個實體來說,可以找出作業名稱、

13、作業繳交者、該作業是屬於哪個課程等屬性,而我們可以用檔案目錄的結構來分類儲存。而適合儲存於資料庫的實體屬性,我們可就每個實體建立資料庫表格儲存該屬性,然後再就所有資料庫表格作正規化(Normalization)。3. 從經過正規化的資料庫表格欄位名稱中,思考資料物件(Data Object)應該提供何種服務功能。本研究採取以一個資料庫表格對應到一個資料庫物件的方式,從新增、查詢、刪除、修改等四個方向思考邏輯層元件(Business object)可能會需要用到的服務。資料物件的設計需考慮一般化的功能,不應只考慮到特定專案需求,以期能設計出可供將來其他應用程式重複使用的服務元件。4. 設計邏輯層

14、物件應從使用案例情境描述中,模擬客戶端程式會需要用到哪些計算邏輯。本研究採取依每個使用案例對應到一個邏輯層物件,不過這得依實際情況看需不需要對應到多個物件,考量的重點在於若將一個使用案例對應到單一邏輯層物件會不會影響到此物件的可再利用(Reuse)性。5. 決定好資料物件及邏輯層物件後,標示出需要加入交易(Transaction)之物件.6. 將物件封裝成元件。若某個物件需由另一個物件來生成(instantiate),則考慮將其一起封裝成單一元件中。7. 設計套件(Package)。考慮要將哪些元件封裝在一起,一般而言,除了安全性的考量外,我們可把整個元件封裝成單一套件,或者依存取元件的目的封

15、裝成多個套件,並設定存取此套件的權限。8. 在展示層方面,本研究採ASP(ActiveX Server page)作為客戶端資料展示及元件呼叫程式。9. 設計的過程是反覆漸進(iterative and incremental),不斷修改,直至完善。4.網路教學系統實作案例系統規格 網路教學系統是提供給教師及修課學生教學輔助使用的。學生用自己的學號(教師用教師代碼)及密碼登入系統確認身份後,系統應可列出所有可供註冊的課程。學生應先從該課程的授課老師處取得該課程的註冊密碼方得以完成線上註冊。 一旦完成課程註冊,下次以學號及密碼重新登入後,系統應可列出該學生所有已註冊過的課程供該學生作課程的登入。

16、登入某課程成後,系統應列出所有的功能選項。 因此當教師欲新增、刪除課程時應把課程名稱、教師代碼及課程註冊密碼告知管理者,由系統管理者負責新增、刪除教師的課程。 教師用教師代碼及密碼登入後,系統應可列出該教師所開的所有課程供老師作維修課程登入。老師登入某課程後,能夠在此系統內作課程的管理。 此系統應具備下列幾種功能:1. 公佈欄:藉由公佈欄,教師可對全班同學宣告事項並可作為該課程之備忘錄。2. 討論區討論區可供大家公開即時匿名的討論問題,教師擁有刪除權。3. 個人信箱可寄信給班上任一位成員,並可在任一課程的信箱中收到所有課程的信件。收到信件後,系統會自動回覆給寄信者,讓寄信者知道對方已看過信。4

17、. 作業處理: 教師在填寫作業名稱後,學生即可針對該作業上傳檔案,並可刪除上傳後的檔案。教師則可檢視每位學生的作業。5. 成績處理教師只要填寫該成績的名稱,即可於線上輸入班級及成績,系統應自動做好統計的工作。學生則可查閱自己的成績及班上成績分佈。6. 教學課程教師可上傳教學文件或補充資料供班上同學課外閱讀。7. 人員管理教師可以控制課程註冊的開放與否,並可刪除非本課程的學生。 系統設計1.從需求分析導出使用案例,圖二是導出之本系統之使用案例圖2-3. 從使用案例情境描述(略)中找出實體及其屬性, 本系統實體包含有: 個人資料、密碼、課表、班級、公佈欄、學生成績、學生作業、討論區,並從各實體屬性

18、導出對應資料庫表格,或目錄及檔案結構,及其對應之資料物件,圖三是本系統之資料庫表格(永續資料模型)及其對應之資料物件及功能描述. 圖四為儲存學生作業之目錄及檔案結構.4. 設計邏輯層物件,圖五為商業邏輯物件(圖中)及其所呼叫到之資料物件(圖左)之設計.5. 標示出需要加入交易(Transaction)之物件,如圖六.6. 將物件封裝成元件7. 設計套件(Package), 本系統僅將db_Course與bus_Course放在一起成一個套件, 其他元件放在一起成另一個套件.8. 在展示層方面,用Frame將功能性選項區隔出,並以ASP的Server端script語法作呼叫邏輯層元件,以便將結果

19、用HTML與CSS展示。系統實作及成果展示 請參考9 <圖二> 網路教學系統之使用案例圖<圖三>網路教學系統之永續資料模型(資料庫表格)及其對應之資料物件之設計及方法描述 <圖四> 儲存學生作業目錄檔案結構 <圖五> 商業邏輯物件之設計 <圖六> 需要加入交易之物件5.討論與結論 本文描述採用三層式主從架構來分析、設計及實作元件為基礎的教學輔助系統。一般網路教學系統是把資料庫驅動程式設定、商業邏輯運作及使用者介面程式寫在單一ASP檔案的系統。與其比較,我們覺得以元件為基礎所設計的系統雖然可在不更改使用者端程式情況下藉由更新邏輯層物件來

20、達到程式的更新,但許多情況下我們較常改變的反而是使用者端的使用者介面程式,使得還沒享受元件更新的好處卻花許多時間在元件的設計、實作、測試、註冊與除錯。 有些系統是將部分使用者介面程式一起封裝成元件的形式,只要呼叫該元件,不用再另外寫介面程式。這樣一方面可保護原始程式碼,一方面該功能有個完整性與獨立性,但卻也抹煞了N層式架構所帶來的好處,並且缺乏彈性。 另外可能在設計上如缺乏經驗,常常會在實作階段才發現之前所設計的模型有所遺落,使得必須再回頭更改之前已寫好的元件,甚至在寫使用者端程式時才會發現我們的元件缺少哪些能力,這有待經驗的累積以縮短開發時間。 但以元件為基礎之系統的使用者端程式的確比較好維護,並且由元件去負責處理交易與資源共享更可讓使用者端程式簡潔不少,且不用顧慮不小心會更改到程式邏輯部分。當下次欲開發此類似系統時,即可快速將可重複元件抽離出來,增加系統開發的速度。6.參考文獻:1Dale Rogerson,“Inside COM”, Mircosoft Press, 1997.2 David Chappell, ”Understanding Act