Frank Buschmann

Applying Patterns
 

上一頁 下一頁


Architectural Vision(架構願景)

Context: 我們正在逐個成長流程的起點。

Problem:

我們要如何定義一個可以擷取系統的基本結構,及設計準則的架構大綱呢?有五個要點是需要考慮的:

 


 

Solution:

建立一個架構願景:一個基礎設計結構;可用來管控系統從規格定義到實作的過程。

要定義架構願景首先要先收集所有會影響系統基礎設計的構面。其中的一個構面是這個應用系統所須展現的系統屬性,例如它的分散性與互動性等。其它會影響軟體架構的因素,則是關於現有成品的使用及整合。例如,舊有的的程式碼以及已完成的元件等。舉例來說,系統可能必須嵌入 ,或存取依循某個特定元件模型的現有元件。

如果有許多這類的屬性及要素,則將他們依序放入一個序列當中;將最重要的特性,放在序列的前端,最不重要的特性,則放在序列的尾端。

接著選擇適當的架構樣式[BMRSS96]來處理這些特性與因素-藉由提供相對應的系統結構 ,以及隱含的設計準則。依據所要處理構面的重要性,以一次一個樣式的方式 ,來套用所選擇的樣式。如此,用以協助比較重要構面的實作設計結構及準則,就可以比那些處理比較不重要構面的設計結構及準則,更能控制與領導整個系統的架構。

對於那些沒有適合的架構樣式可以處理的構面,則使用傳統的設計方法來找出適合的結構。或使用其他可以引領建構此類結構之程序的樣式來處理,例如在 [Coad95] 中所提到的。

最終結果是,我們可以得到系統的基礎架構:包括它的次系統,它們的責任及合作關係;以及可以指引後續規格發展及細緻化的設計準則。

由於使用了樣式;這個架構定義了一個逐個成長程序的理想基礎。它是構建在可證明的設計概念之下。它在整體的結構上是穩固的;但仍可做系統的擴充及部分的修改。同時,這個設計也不是巨細靡遺的。我們只是著重在 ,將系統解構成次系統。我們所使用的樣式同時也協助了架構願景的溝通:要用哪一種結構、為什麼要用這麼樣的一個結構、它隱含的設計理念為何,以及該如何的構建它等。

 

Example:


假設我們要發展一個分散式及互動式的系統,有兩個架構樣式可以協助處理。Broker 樣式[BMRSS96] 可支援分散性,而 Model-View-Controller 樣式則支援人機互動。假設在這個例子裡,分散性是最重要的系統特性。所以我們要先使用 Broker 樣式。這樣的結構基本上會擁有客戶端與伺服端,以及一個處理跨越作業程序邊界(Process Boundaries)訊息的路由代理人。接著再把Model-View-Controller 樣式整合進這個結構裡,其中,每個伺服端分別代表了不同的 Model,而各個客戶端則是它的 View Controller 元件。

這兩個樣式同時定義了這個系統中,元件間基本的溝通及合作機制。Broker 樣式定義了客戶端該如何存取遠端的伺服端。Model-View-Controller 樣式則定義了使用端的介面元件 ,該如何與功能核心互動。

這兩個樣式也定義了此系統中,兩個一般性的設計準則:將系統的應用功能與通信功能分開,以及將系統的核心功能與使用者介面分開。


上一頁 下一頁