目的
|
定義設計師用來賦予物件對象生命所用的分析機制和服務。
|
在初始階段,主要重點是執行架構合成,但這項作業卻會排除這個步驟。
分析機制可以是由上而下(具有先前的經驗)或由下而上(一面做一面找)。在由上而下的模式中,經驗讓軟體架構師瞭解領域中存在的特定問題,並且需要特定的解決方案。在分析期間,會呈現作為機制的一般性架構問題範例包括:持續性、交易管理、錯誤管理、傳訊以及推論引擎。所有這些架構元素的共同特徵,是每個架構元素
都是系統的一個一般性的廣泛類別功能,並且每個架構元素都會提供功能
來和基本應用程式功能互動,或支援基本應用程式功能。分析機制支援系統的基本功能需求所需要的功能,不論系統部署的平台或實作的語言為何。分析機制也可以用多種不同的方式設計和實作;一般而言,每種分析機制都會有多個相對應的設計機制,並且每種分析機制也可能會有多種實作方式。
由下而上方法是實際產生分析機制,分析機制會建立成軟體架構師從多個問題的一組解決方案所衍生的共同主題中,所看到的分析機制,一開始時,這個機制可能還很模糊。這裡需要提供一種方式,讓不同頭緒中的各個元素能將時鐘同步化,並且需要一種共同的方式來分配資源。用來將分析語言簡化的分析機制,就是從這些型樣中洐生出來的。
指出分析機制表示您指出有共同的,但可能是隱含的次問題(系統的需求暗示這一點)存在,並且您加以命名。開始時,名稱可能是所有存在的問題,例如「軟體架構師認為系統需要一項持續性機制」。最後這個機制會透過合併類別群集實作(請參閱
[BOO98]),其中有些並不直接提供應用程式功能,只是單純做為支援用途。這些支援類別通常是位於分層式架構的中下層,因此可以對所有應用程式層的類別提供共同的支援服務。
如果指出的次問題相當普遍,或許已經有型樣存在,可以透過連結現有的類別,以及實作型樣所需的新機制,來建立機制。用這種方式產生的分析機制是抽象的分析機制,需要經過進一步的設計和實作來修飾。
如需詳細資訊,請參閱概念:分析機制。
|