軟體的架構設計

大型系統通常會被分解成數個子系統，而辨識這些子系統的初始設計 程序以及建立子系統之間控制與通訊的骨架則稱為架構設計（architectural design）。軟體架構設計的重點是為系統建立一個基本的結構化骨架，以用 來辨識子系統控制與溝通的框架（Sommerville, 2006）。Bass(2003)曾經提 出明確的設計與紀錄一個軟體架構會得到以下三個好處：

1. 與利害關係人進行溝通：架構等於是系統比較高階的表示方法，

所以可以當成各不同領域的利害關係人討論時的聚焦所在。

2. 系統分析：在系統開發初期階段時，明確的建立系統架構，分析 此系統架構是否符合系統重要的需求。系統重要的需求包括執行 效能、系統可靠性及系統可維護性等。

3. 大規模再利用：系統架構是對系統的組織方式和系統間元件的互 動做一個簡單且容易管理的描述。如此一來，當這個系統需要轉 移至其他相同架構的系統時，可以重複的利用。

在本節中，將會分成三個小節來探討三種架構設計的模型：倉庫模型

（repository model）、主從式模型（server-client model）和抽象機器模型

（abstract machine model）。

2.3.1 倉庫模型

組成一個系統的子系統之間一定要交換資訊才能有效的一起運作，交 換資訊有兩個基本方法：

1. 將共用的資料保存在一個集中的資料庫，讓所有子系統都可以存 取資料。以共用資料庫為基礎的軟體架構模型則稱為「倉庫模型」。 2. 每一個子系統都有各自的資料庫保存資料，需要交換資料的時候

則透過子系統之間的訊息傳遞。

大 多 數 使 用 大 量 資 料 的 系 統 都 會 使 用 倉 庫 模 型 作 為 軟 體 的 架 構

（Pfleeger, 2001），因為這個模型適合於資料由某一個子系統產生之後存回

2.3.2 主從式模型

主從式架構模型式一種分散式的系統模型（Pressman, 2001）。這個模 型的主要組成元件有：

1. 提供服務給其他子系統的一些獨立伺服器。例如提供列印服務的 列印伺服器和提供檔案管理的檔案伺服器等。

2. 向伺服次要求提供服務的客戶端。這些客戶端通常是子系統，同 一個客戶端程式可能在同一個時間有多個實例同時執行。

3. 可讓客戶端存取這些服務的網路。這個元件不是絕對需要，因為 客戶端和伺服器可以放在同一部機器上執行，因此客戶端不需透 過網路存取伺服器的資料。

在這個模型架構下，客戶端要知道可用的伺服器名稱以及伺服器所能 提供的服務；伺服器則不需要知道客戶端的名稱及數量。主從式方法也可 以用來實做一個以倉庫模型為架構的系統，只要將資料庫以一個系統伺服 器來提供即可，而存取資料庫的子系統就是客戶端。圖12是一個主從式架 構為基礎所建構的系統範例，它是一個能夠提供影片和圖片資料庫的多使 用者超文件系統。系統中有一些負責管理不同媒體類型的伺服器，另外有 伺服器是提供超文件資訊系統的連結，以方便客戶端查詢目錄。客戶端程 式則只是為了這些服提供一個整合的使用者介面。

主 從 式 模 型 最 大 的 好 處 就 是 它 是 屬 於 分 散 式 架 構 （Christensen, 2002），這種以網路連結的系統可以有效的利用許多分散的處理器來執 行，而且假如要加入一個新的伺服器或是與系統的其他部份整合都非常容 易，若要升級伺服器，也不會影響到系統其他的部份。

網際網路

抽象機器模型亦稱作為分層式模型（Sommerville, 2006），它可以用來 建立子系統間的介面，並且將一個系統分解成許多分層，讓每一層都提供

版本管理 物件管理 資料庫系統

作業系統

圖13 版本管理系統的抽象機器模型（Sommerville, 2006）

2.3.4 小結

不同的軟體工程師會採用不同的架構設計，這些設計會根據軟體工程 師對應用程式的瞭解和熟悉程度而有所不同。然而，大部分的大型系統架 構並不只符合單一模型，系統中不同部份的地方可能會使用不同的架構模 型來設計。因此有些系統的架構可能是一個合成架構，它是由各種不同的 架構組合而成。軟體工程師必須找出最適合的模型，然後依照問題的需求 加以修改。

在 2.3.3 節中，共提到三種軟體架構設計的方式。抽象機器模型雖然 可以有效的保護系統，使其不易受到不明使用者的破壞，但由於其建構系 統的方式困難且費時，較不適用於本研究所要發展的軟體；而倉庫模型雖 然管理容易，但其執行效能不佳，且若要改變其架構，必須花費具大成本。

相較於上述兩種架構設計，主從式模型克服了倉庫模型的缺點及保留其優 點，在軟體架構設計上容易執行；且目前許多大型的線上遊戲皆是採用這 種架構（曾華堃，2005）。因此本研究決定採用主從式模型作為架構遊戲 的方式。