作業: 指出設計機制
這項作業說明如何將分析機制修正成設計機制。
規範: 分析 設計
目的
  • 根據實作環境的強制限制,將分析機制修正成設計機制。
關係
步驟
分類分析機制的用戶端

分析機制在概念上提供分析類別所用的各組服務。對於您最終仍必須考量,但超出分析工作範圍的非常複雜的行為,它們提供了簡便的表達方式。它們的主要目的是讓我們不必考量服務提供者本身的細節,就能夠擷取關於這些尚未設計之系統服務的需求。

現在,我們必須開始修正所收集的分析機制資訊。以下是這項作業的步驟:

識別每個分析機制的用戶端。 請掃描給定分析機制的所有用戶端,查看它們所需要的這個機制的特性。例如,許多分析類別可能會用到持續性機制,但它們在這方面的需求可能非常不同:有一千個持續性實例的類別,它的持續性需求與有四百萬個持續性實例的類別非常不同。同樣地,實例必須以亞毫秒來回應實例資料之類別所需要的持續性方法,不同於只利用特定查詢和批次報告應用程式來存取實例資料的類別。

識別每個分析機制的特性設定檔。特性設定檔的差別有可能非常大,會提供不同程度的效能、覆蓋區、安全和經濟成本等。每個分析機制都各不相同,它們會分別適用不同的特性。許多機制都需要透過預期的位元組數目來預估要管理的實例數量及它們的預期大小。在任何系統中移動大量資料,都會產生必須處理的驚人效能問題。

依照用戶端使用特性設定檔的方式來分組用戶端。 請從似乎共同需要含類似特性設定檔的分析機制之用戶端群組中,根據每項這類需求來識別出設計機制。這些分組提供了設計機制的開端。「跨程序通訊」這個分析機制範例便可能對映到 "Object Request Broker" 設計機制。不同的特性設定檔會產生從相同分析機制合併而來的不同設計機制。分析中的簡單持續性機制會帶來設計中的許多持續性機制:記憶體內的持續性、以檔案為基礎、以資料庫為基礎、分散式,等等。設計機制是以不同的特性設定檔為基礎的分析機制修正。

庫存實作機制

請繼續由下而上作業,建立您能夠處理的實作機制(請參閱 概念:設計和實作機制)庫存:

  • 中介軟體產品或元件架構所提供的機制。
  • 作業系統所提供的機制。
  • 元件所提供的機制。
  • 類別庫所提供的機制。
  • 舊版程式碼(另請參閱作業:納入現有的設計元素
  • 特殊用途的套件:GUI 建置器、地理資訊系統、DBMS 等。

請判斷哪裡可以使用現有的實作機制,哪裡必須建置新的實作機制。

將設計機制對映至實作機制

設計機制提供實作機制的抽象化,它在分析機制和實作機制之間架起橋樑。在設計期間使用抽象的架構機制,可讓我們考慮如何去提供架構機制,且眼前的問題不會被特定機制的細節遮蔽。另外,它也可讓我們用特定實作機制來替代另一個機制,而不會對設計造成負面影響。

判斷特性的範圍。 請採用針對設計機制而識別的特性來判斷候選實作機制所能使用的合理、經濟或可行的值範圍。

考慮購買的元件之收購成本。 請針對候選實作機制,在純粹技術準則之外,考量收購或版權的成本、產品成熟度、與供應商的關係、支援等等。

搜尋正確的元件或建置元件。 您通常會發現,有些設計機制並沒有明顯適用的實作機制;這會觸發搜尋正確產品或識別獨立開發的需求。另外,您也可能發現有些實作機制根本用不到。

實作機制的選擇基礎並不只是非常符合技術特性,同時也在於非技術的特性,例如成本。有些選擇是臨時的;它們幾乎都會有風險:效能、強韌度和延展性幾乎是永遠存在的問題,必須透過評估、探索性原型或併入架構原型來進行驗證。

產生架構機制的文件

在這項作業中,軟體架構師的角色是建置或整合這些機制以及確認它們會執行工作,以進行這些機制的決策和驗證,之後,再將它們一致地強加在系統設計的其餘部分。軟體架構師角色會協同流程工程師角色來產生這些機制及它們在專案特定設計準則中之使用細節的文件。請參閱作業:準備專案特定準則。從分析機制到設計機制到實作機制的關係(或對映)及這些選擇之基本理由的說明文件,都應該在軟體架構文件中。機制本身是設計模型元素(如設計套件、設計類別和設計子系統),在工作成果:設計模型中,元素各自的設計作業會有元素的詳細說明。



詳細資訊