課業子系統需求分析

圖 2.12、課業子系統需求 2.2.7 課程資料子系統需求分析

圖 2.13、課程資料子系統需求

2.2.8 學生資料子系統需求分析

圖 2.14、學生資料子系統需求 2.2.9 學校行事曆子系統需求分析

2.2.10 記事本子系統需求分析

圖 2.16、記事本子系統需求 2.2.11 教師子系統需求分析

圖 2.17、教師子系統需求

2.2.12 登入子系統需求分析

圖 2.18、登入子系統需求

第三章 系統分析與設計

1. 瀑布模式(waterfall model)

瀑布模式開發是一種有系統、符合邏輯的方法。它依軟

瀑布模式一班適用於低風險、需求變動小又可以清楚表

2. 原型模式(prototyping model)

通常，客戶只會定義出一些系統要達成的目標，而不會

改與擴充原型。原型不斷的調整，直到系統符合雙方約定

(3) 由剩下之相關風險決定下一步驟 Client-Server 架構，透過網際網路，不限制任何作業系統平台，

客戶只要使用符合標準瀏覽器便能操作系統，無須下載安裝任何 客戶程式。就算是更新系統，亦只要更新 Web Server 這端即可，

客戶無須作何更新動作，便能享受新的服務。

現行的 Web 應用程式開法技術，最主要的有 ASP、JSP、PHP 以 及 ASP.NET。

(1) ASP，全名為 Active Server Pages，是 Microsoft 公司 所開發出來的 Server 端網頁技術，採用腳本語言 VBScript 和

(2) JSP，Java Server Page，是 Sun 公司推出的新一代網站 開發語言，使 Java 在網頁方面的應用，除了可使用 Java Applet 之外的另一個新技術。JSP 可以在 Serverlet 和 JavaBean 的支援 下，完成功能強大的 Web 應用程式。

(4) ASP.NET，是 Microsoft 公司推出的新一代的網頁應用技 術。屬於 Microsoft 公司.NET 願景之一的重要技術。利用強大 的.NET Framework 平台和 Web Services 建構出網際網路的分散式 架構，並且可使用符合.NET 規範的任何程式語言，如 Basic、C＋

＋、Cobol、Jscript 等作為開發的語言。

就上述的四種 Web 應用程式技術，我們分別以我們的線上學生 系統所要求的速度、元件化、行動通訊這三個目的來對其作討論 及選擇。

(1) 快速：

由於我們要改善原有的課程查詢系統速度上的缺點，我以

執行速度是我們的第一考量。就架構而言，ASP 和 PHP 是利用 Script 語言作為開發語言，因為直譯式程式執行的先天限 制，所以在速度上無法跟經過編譯的 JSP 和 ASP.NET 相比，所

以這方面而言，ASP.NET 略勝一籌，她特別為行動通訊裝 置設計 Mobile ASP.NET，將網頁標籤包裝成一個個元件，依 照前端瀏覽器的不同，自動判斷產生合乎其特性的標籤。例如

另外，選擇使用 ASP.NET 還有以下幾個優點：

(1) 功能完善的核心：

.NET Framework 提供了完整的物件導向核心，可使用數種程 式語言開發應用程式，並且有功能強大的執行環境，提供了跨 語言的執行平台、自動資源回收和型別安全檢查等功能。

(2) 良好的開發框架：

ASP.NET 的 Web Form 設計，透過事件驅動和資料繫結，讓開 發 Web 應用程式的方式和一般開發普通的 Windows 應用程式的 方式一致，使得開發更易上手。並且透過 Code-Behind 的方 式，讓 HTML 標籤與程式碼可以完全地分開撰寫，免除了二種 程式混在一起分不清楚的惡夢。

(3) 擁有良好的整合式開發環境：

Visual Studio.net 為微軟新衣戴用來開發.NET 平台上程式的 開發工具。自動化和視覺化的設計工具，使得程式設計師能專

1..NET 架構對於 SQL Sever 2000 整合良好，並且有最佳

SQL SEVER 2000 及採用的塑模技術－Design Patterns

(1) UML(Unified Modeling Language)

UML 是一種視覺化語言，用來為系統建立模型。他並非是一

UML 中定義了九種的圖形，分別在系統開發時不同的時期描述 系統，好讓我們根據不同的角度來看待系統。這九種圖形分別 為：

a. 類別圖(Class diagram) b. 物件圖(Object diagram)

c. 使用案例圖(Use case diagram) d. 順序圖(Sequence diagram)

e. 合作圖(Collaboration diagram) f. 狀態圖(Statechart diagram) g. 活動圖(Activity diagram) h. 元件圖(Component diagram) i. 部署圖(Depolyment diagram)

以下我們分別簡介類別圖、順序圖和活動圖這三種在我們的

別(class)、類別的內部結構和操作，以及類別和類別之間的靜 態關係的圖形。其中類別是用來定義物件的詳盡描述，包含了 欄位(field)、方法(method)等。

UML 表示抽象類別(abstract class)和具像類別的圖形。類 別是以長方形方塊來表示，其中類別的名子位於方塊上方，中

生命線，垂直長方形代表物件取得控制權，正在處理外界送來

是在說明活動的控制流程，利用活動圖，更可明白表示出系統 中的活動順利以及工作流程。

(2) Design patterns

在 UML 中，只定義了如何用圖形表達物件導向設計。相反的 patterns 看的是結果－已經設計好的模型範例。

Patterns 是描述作事情的共通方法。對於某些類型的問題，

往往會被設計成相同的架構，而這些架構或是設計，已被證明 是有效且能重複使用解決問題的，這些設計便被蒐集起來並且 給他一個名子。這種有名子且能重複套用的設計，便稱之為 patterns。每一個 Patterns 都是錢人經驗累積的精華，它描述 了一個重複發生在我們環境中發生的問題，也描述了問題的核 心解法。它提供了設計者一個共通的名子，以幫助團隊溝通，

也提供了如何將問題的解決成為一個高凝聚力、低耦合力的設 計。Design patterns 給予我們專注在問題本身，以及設計物 件導向時更高的觀點，讓我們不會過早被太仔細的細節所牽絆 住。利用 design patterns 設計系統可將複雜的系統便成單純 的解決一個一個的問題，並且擁有高度彈性的架構。要創造良 好的物件導向設計，有幾個策略可使用，如：

z 對介面設計

z 使用組合，勝過繼承 z 找出變化，並將它封裝

這便是 design patterns 的精神。以下舉例簡介何為 Singleton patterns：

有時候我們必須卻表某些類別只能有一個物件實體，譬如 第二個實體出來。這就是 singleton patterns。

Singleton patterns 藉由一個特殊的方法，當它被呼叫時，

它會檢查是否已有實體。如果有，則傳新物件的參考。並且，

為了確保別人無法擅自生成實體，將此列別的建構式定義為 protected 或是 private。

以 C＃為例，實際的 Singleton 類別會宣告成類似以下的程 式碼：

{ public：

和資料繫結的開發方式，使得讓前端的 UI 介面和後端的程式碼可清楚 的分開撰寫，即是 Design Patterns 中的 Mediator 模式和 Observer 模 式的混合運用。ASP.NET 又透過 Code-Behind 的技術，將程式碼和展示 用的 HTML 標籤分開在不同的檔案，使程式更可讀性，其中 HTML 標籤 Server 2000，故在移植到新學校時會採用的資料庫系統的不同 而變更相對應的程式碼。

首先我們先考慮使用者的問題，因使用者的不同，所需對應的邏輯 層便不同，例如以教師帳號登錄的使用者，其首頁便不應該出現作業 繳交通知的功能，故系統應能依使用者的類別不同，顯示出符合其身

第一種做法是更改顯示層，顯示為不同的使用者建立相對應頁面再

為 HTML 標籤，(即*.aspx 檔)，而 System.Web.UI.Page 退化成了 MVC 設計中的 Controller，只負責對使用者介面的輸入作出相對應的處理 和將結果對應於 View。其餘的部分則為 Model，負責應用軟體物件。

我們訂定出了 Page 的責任，接下便可繼續思考 Model 中的系統的架構 設計。

抽象類別 Group 定義出在此系統中所需那些運算，再分別依學生或 老師的不同分別實現其實際的動作。Config 類別用來存取 Config.xml 檔，此檔案紀錄著系統管理這所作的設定。

此設計的好處在於讓 Controller 可以對所有的使用者皆一視同 仁，作出相同的動作。而使用者之間的所需差別，則由使用者所屬的

群組自行負責，日後若要新增新種類的使用者，只需增加相對應的群 組作出其所需的邏輯即可。

但目前的設計卻會使得資料庫與系統過分耦合，一但資料庫系統更 換，便得重新編寫 Student 和 Teacher 中對資料庫動作的所有程式碼。

另外在.NET Framework 中，對資料庫的操作模型為 ADO.NET。它提 供了 Data Provider 物件用來連接資料庫，執行資料操作指令、取回 查詢資料等功能。但對於所連接的資料庫不同，其所對應的 Data Provider 物件也不同。若連接的對象為 SQL Server，便應使用 SQL Server.NET Data Provider，若連接 Oracle 資料庫便應使用.NET Data Provider，若連結 Oracle 資料庫，便應使用.NET Data Provider for Oracle。也因此，對於使用的資料庫的不同，便要重新編寫所有有關

Select、Insert、Delect 和 Update 四個動作，以及使用 Bridge 模式

如此，一但要新增連接到埠同的資料庫，便只需使用 Adapter 模 式，將其所對應的 Data Provider 轉換成符合 ConnectDB 的介面即可。

但是在 Group 中仍然需要指名所需的 ConnectDB 子類別為何，並無 法在程式執行時動態的去挑選要聯結的資料庫引擎，，我們希望系統 能和使套裝軟體一般的方便可依系統管理者的設定，自動創造合適的 ConnectDB 子類別，如此在移植時便能作到最小的改變。所以加上了退 化的 Abstract Factory 模式，讓系統自行判斷，動態生成合適的 ConnectDB 子類別。

CreatConnectDB 會依 Config.xml 的內容，選擇要生成何種的 ConectDB 子類別。

接下來，我們在繼續考慮關於課程資料庫的變化。為了操作的方便 性和一至性，我們亦利用 Adapter 模式將對課程資料庫的操作包裝成 ConnectDB 的介面。

考慮課程資料庫的變動，和課務資訊系統資料庫一樣，隨著學校的 不同，課程資料庫可能為不同種類的資料庫系統，而且絕大多數的 Table 定義都可能不同，Table 名稱不同，欄位名稱不同，Table 之間 的關係也不同，甚至可能分散到好幾個資料庫裡。所以想要轉移系統 至其他學校，修改程式碼是無可避免的。

我們必須思考一種好的做法使修改的程式碼維持最小，讓系統的主

要邏輯不受到資料庫變更的影響。是故，利用資料庫中 VIEW 的觀念並 Config.xml 的虛擬路徑轉為實體檔案路徑以供後續動作使用。但在 ASP.NET 中，提供此轉換功能的物件址能由 ASP.NET 應用程式實體化，

所以 Config 勢必得提供一方法，接受此一物件，才能在內部進行路徑

所以 Config 勢必得提供一方法，接受此一物件，才能在內部進行路徑