分析機制在概念上提供分析類別所用的各組服務。對於您最終仍必須考量,但超出分析工作範圍的非常複雜的行為,它們提供了簡便的表達方式。它們的主要目的是讓我們不必考量服務提供者本身的細節,就能夠擷取關於這些尚未設計之系統服務的需求。
現在,我們必須開始修正所收集的分析機制資訊。以下是這項作業的步驟:
識別每個分析機制的用戶端。 請掃描給定分析機制的所有用戶端,查看它們所需要的這個機制的特性。例如,許多分析類別可能會用到持續性機制,但它們在這方面的需求可能非常不同:有一千個持續性實例的類別,它的持續性需求與有四百萬個持續性實例的類別非常不同。同樣地,實例必須以亞毫秒來回應實例資料之類別所需要的持續性方法,不同於只利用特定查詢和批次報告應用程式來存取實例資料的類別。
識別每個分析機制的特性設定檔。
各特性設定檔的差別有可能非常大,會提供不同程度的效能、覆蓋區、安全和經濟成本等。每個分析機制都各不相同,它們會分別適用不同的特性。許多機制都需要透過預期的位元組數目來預估要管理的實例數量及它們的預期大小。在任何系統中移動大量資料,都會產生必須處理的驚人效能問題。
依照用戶端使用特性設定檔的方式來分組用戶端。 請從似乎共同需要含類似特性設定檔的分析機制之用戶端群組中,根據每項這類需求來識別出設計機制。這些分組提供了設計機制的開端。「跨程序通訊」這個分析機制範例便可能對映到
"Object Request Broker"
設計機制。不同的特性設定檔會產生從相同分析機制合併而來的不同設計機制。分析中的簡單持續性機制會帶來設計中的許多持續性機制:記憶體內的持續性、以檔案為基礎、以資料庫為基礎、分散式,等等。設計機制是以不同的特性設定檔為基礎的分析機制修正。
|