作業: 說明執行時期架構
這項作業依據主動類別及其實例,以及這些類別和作業系統執行緒及處理程序的關係,來定義系統的處理架構。
目的
  • 分析並行需求,
  • 識別程序及其生命週期 
  • 識別跨程序通訊機制並配置跨程序協調資源 
  • 將模型元素分散到多個程序。
關係
角色主要: 其他的: 協助:
輸入強制: 選用: 外部:
輸出
主要說明

使用主動物件(亦即主動類別主動類別實例)來代表在系統中執行的並行執行緒:值得注意的是每個主動物件都會有其自己的控制緒,並且通常這是執行堆疊框的根。將主動物件對映到實際的作業系統執行序或程序,可能會因為回應需求而有不同,並且也會受環境定義切換的額外負荷考量的影響。例如,有一些主動物件可以和 一個簡單的排程器共用同一個作業系統執行緒,因此就會形成並行執行的外象。不過,如果有任何主動物件呈現封鎖行為時,例如執行同步輸入/輸出,則同群組中的其他主動物件就無法對在作業系統執行緒被封鎖時發生的事件做出回應。

另一個極端情況是給予每一個主動物件其自己的作業系統執行緒,如此就可以顯著提高回應,只要處理資源不會受到額外的環境定義切換的額外負荷嚴重影響即可。

在即時系統中, 工作成果:封裝體是建議使用的並行建模方式;和主動類別一樣,每個封裝體都擁有其自己的純理論控制緒,但是封裝體卻有額外的封裝和組合語意,可以使複雜的即時建模問題更容易追蹤。

這項作業依據主動類別及其實例,以及這些類別和作業系統執行緒及處理程序的關係,來定義系統的處理架構。對即時系統而言,處理架構也是依據封裝體和封裝體與作業系統程序及執行緒的關聯對映來定義。

在「詳述」階段的早期,此架構通常極為原始,但是到「詳述」階段的後期時,程序和執行緒應該已經完備定義。這項作業的結果會擷取在設計模型中 - 更精確地說,是在程序視圖中(請參閱概念:程序視圖)。

步驟
分析並行需求
目的  定義系統需要的平行執行範圍。此定義可以協助塑造架構。 

作業:識別設計元素期間,並行需求主要是由在所考量的問題領域中,自然發生的並行要求所驅動。 

它的結果是產生一組主動類別,代表系統中的邏輯控制緒。在即時系統中,這些主動類別是由  工作成果:封裝體代表。

在這個步驟中,我們要考慮其他並行需求來源 - 那些需求是由系統的非功能需求形成。

並行需求是由以下驅動:

  • 系統必須分散的程度。系統行為若必須分散到多個處理器或節點,就等於是需要多重程序架構。系統若使用某些「資料庫管理系統」或「交易管理程式」時,也必須考量那些主要子系統建立的程序。
  • 主要演算法的運算程度。為了提供良好的回應時間,可能必須將運算繁重的活動放置在其個別的程序或執行緒中,讓系統在進行運算期間,雖然資源減少了,但仍然可以回應使用者輸入。
  • 環境支援的平行執行程度。如果作業系統或環境不支援多個執行緒(輕型程序),就沒有必要考慮其對系統架構的影響。
  • 系統需要容錯機能。備份處理器需要備份程序,因而就導致需要將主要和備份程序維持同步。
  • 到達系統的事件型樣。在具有外部裝置或感應器的系統中,進入事件到達的型樣,可能會視不同的感應器而有不同。有些事件可能是定期性的(如在固定的間隔、加上或減去一點時間) 或非定期的(如具有不規則的間隔)。主動類別若代表會產生不同事件型樣的裝置時,通常會被指派不同的作業系統執行緒,並使用不同的排程演算法,來確保不會錯過事件或處理期限(如果這是系統的需求)。這項推論亦適用於在即時系統設計中使用的封裝體。

和許多架構問題一樣,這些需求之間有可能會互斥。但在一開始時,有互相衝突的需求存在並非不尋常。依重要性將需求區分等級,會有助於解決衝突。

識別程序和執行緒
目的  定義會存在系統內的程序與執行緒。 

最簡單的做法是將所有主動物件配置給同一個執行緒或程序,並使用簡單的主動物件排程器,因為這樣可以降低環境定義切換的額外負荷。不過,在某些情況下,可能需要將主動物件分散到一或多個執行緒或程序。大部分的即時系統都是屬於這種情況,因為即時系統會使用封裝體來代表 有時必須符合硬性排程需求的邏輯執行緒。

如果和主動物件共用同一個作業系統執行緒的其他主動物件對其他程序或執行緒進行同步呼叫,並且此呼叫封鎖住啟動物件的共用作業系統執行緒時,此狀況就會自動暫停位於啟動程序中的所有其他主動物件。現在情況並不一定要像這樣:對主動物件而言是同步的呼叫,對控制主動物件群組的簡單排程器而言,卻可能是以非同步式處理 - 因此排程器會暫停主動物件進行呼叫(等候其同步呼叫完成),然後再排定執行其他主動物件。 

當原始的「同步」作業完成時,就可以回復呼叫主動物件。不過,這種方式並不一定永遠可行,這是因為排程器可能無法設計為在進行封鎖之前,截取所有同步呼叫。請注意,在使用相同的作業系統程序或執行緒的主動物件之間起始的同步呼叫,為了通用起見,可以由排程器用這種方式處理 - 對於啟動主動物件而言,其效果等於程序呼叫。

因此我們可以將此歸納為主動物件應該依據它們是否需要和封鎖執行緒的同步呼叫作業平行執行,來加以分組程序和執行緒。亦即,主動物件應該和會使用同步呼叫來封鎖執行緒的 其他物件相同的程序和執行緒唯一狀況,是主動物件不需要和該物件同時執行,並且可以接受當其他物件被封鎖時,它自己被禁止執行。在回應極為重要的特別情況中,這種情況會導致需要針對每個主動物件使用個別的執行緒或程序。

在即時系統中,封裝體的訊息型介面代表對於跨封裝體的通訊而言,較簡單的做法是建立一個排程器,來確保即使封裝體在和其他封裝體進行同步通訊時,作業系統執行緒也絕不會被鎖定。不過,封裝體還是可以直接向作業系統發出要求,例如,針對同步計時等待,因而封鎖執行緒。因此,如果封裝體要共用相同執行緒 (並使用簡單的排程器來模擬平行作業)時,就需要針對封裝體啟動的低階服務建立一個使用慣例,來避免這種行為。

就一般的規則而言,在上述情況中,最好能使用輕型緒,而不要使用完整的程序,因為輕型緒的額外負荷較小。不過,您可能還是希望能利用到程序在一些特殊情況下的某些特殊特質的優點。由於執行緒會共用相同的位址空間,因此它們的潛在風險比程序高。如果有意外改寫的顧慮存在的話,則最好使用程序。此外,由於在大部分作業系統中,程序是代表獨立的回復單元,因此最好能依據物件是否需要分別回復,來配置主動物件給程序。亦即,需要作為同一單元回復的所有主動物件,可以包裝在同一個程序中。

針對系統需要的每個個別的控制流程,建立一個程序或執行緒(輕型程序)。在需要巢狀的控制流程(例如在程序中,在子作業層次需要獨立的控制流程)時,就應該使用執行緒。

例如,個別的控制緒可能需要執行下列動作:

  • 不同的軟體部分有不同的問題
  • 善用同一節點的多個 CPU 以及分散式系統中的多個節點好處
  • 當控制緒被暫停時,配置循環至其他活動以提高 CPU 使用率
  • 決定活動優先順序
  • 支援將負荷分攤到數個程序和處理器
  • 採用備份程序,達到更高層的系統可用性
  • 支援 DBMS、「交易管理程式」或其他主要子系統。

範例

在「自動提款機」中,必須處理的非同步事件是來自三個不同的來源:系統的使用者、ATM 裝置(例如,如果現金輸送匣卡住時)或是 ATM 網路 (例如來自網路的關閉指示)。為了處理這些非同步事件,我們可以如以下所示,使用 UML 內的主動類別,在 ATM 中定義三個不同的執行緒。

ATM 程序與執行緒圖例

ATM 中的程序與執行緒

識別程序生命週期
目的  指出何時建立及摧毀程序與執行緒。 

每一個程序或控制緒都必須建立及摧毀。在單一程序的架構中,程序是在啟動應用程式時建立,並在應用程式結束時摧毀程序。在多重程序的架構中,新的程序(或執行緒)通常是從在啟動應用程式時, 由作業系統建立的起始程序複製或衍生。這些程序也都必須明確地摧毀。

必須指定並記錄會導致建立和摧毀程序的序列事件,以及建立和刪除機制。

範例

在「自動提款機」中,會啟動一個主要程序,來負責協調整個系統的行為。這個主要程序會進而衍生一些臣屬的控制緒,來監視系統的各個部分:系統中的裝置,以及從客戶及 ATM 網路發出的事件。在 UML 中,可以使用主動類別 來顯示需要建立的這些程序和執行緒,並且可以用序列圖來顯示需要建立的這些主動類別的實例,如下所示:

建立系統啟動程序及執行緒圖例

系統起始設定期間建立程序及執行緒

指出跨程序通訊機制
目的  識別程序及執行緒用來進行通訊的方式。 

跨程序通訊 (IPC) 機制可讓在不同的程序中執行的物件之間,互相傳送訊息。

常見的跨程序通訊機制包括:

  • 共用記憶體,使用/不使用號誌來確保同步化。
  • 會合,特別是由諸如 Ada 類的語言直接支援時
  • 號誌,用來封鎖同時存取共用的資源
  • 訊息傳遞,包括點對點及一對多點
  • 信箱
  • RPC - 遠端程序呼叫
  • 事件播送 - 使用「軟體匯流排」(訊息匯流排架構)

選擇使用的 IPC 機制會變更系統的建模方式;例如,在「訊息匯流排架構」中,物件之間不需要具有明確的關聯,就可以互相傳送訊息。

配置跨程序協調資源
目的 配置稀有資源
預測及管理可能的效能瓶頸 

跨程序通訊機制通常很稀有。號誌、共用記憶體以及郵箱通常會固定其大小或數目,並且要提高時,工程耗大。RPC、訊息及事件播送會耗用大量的可貴網路頻寬。當系統超出資源臨界值時,通常會發生非線性的效能降級:當稀有的資源用盡時,對該資源的後續要求將會產生令人不悅的結果。

如果沒有稀有資源可用,則可以考慮數種策略:

  • 藉由減少程序數目,來減少對稀有資源的需求
  • 改變稀有資源的用法(針對一或多個程序,選擇在 IPC 機制中使用不同的、較充足的資源)
  • 增加稀有資源的數量(例如增加號誌數目)。這種做法只需要做極少的變更,但是通常會有負面影響或固定的限制存在。
  • 共用稀有資源(例如只在必要時,才配置資源,並在不需要時,將其釋放出)。這種做法很耗費成本,並且可能只能預測資源危機而已。

不論採用哪一種策略,當系統部署之後,系統都應該溫和式地降級(而不是突然當機),並且應該向系統管理員提供適宜的回饋,以便能現場解決問題(如果可能的話)。

如果系統需要對執行環境做特殊的配置,以便提高重要資源的可用性(通常是由重新配置作業系統核心方式來控制)時,必須由系統安裝程式自動執行此動作,或指示系統管理員執行此動作,系統才會開始運作。例如,系統可能需要重新開機,變更才會生效。

將程序對映至實作環境
目的  將「控制流程」對映至實作環境支援的概念。 

概念性的程序必須對映到作業環境中的特定建構。在許多環境中,都會有多種程序類型可以選擇,通常至少都會有程序和執行緒。選擇是根據耦合性程度(程序是獨立式的,而執行緒則是在內含程序的環境定義中執行) 以及系統的效能需求(執行緒之間的跨程序通訊通常要比程序之間的跨程序通訊快且有效率)而定。

在許多系統中,可能會限定每個程序的執行緒或每個節點的程序數目上限。這些限制可能並不是絕對的,但可能是對稀有資源的可用性所施行的實用限制。已經在目標節點上執行的執行緒和程序,需要和程序架構中提議的執行緒和程序一起考量。完成對映後,需要考量先前步驟配置跨程序協調資源的結果,以確保不會造成新的效能問題。

將設計元素對映至控制緒
目的  決定要在其中執行的控制緒類別及子系統。 

給定類別或子系統的實例必須至少在一個為類別或子系統提供執行環境的控制緒中執行;它們實際上也可能會在數個不同的程序中執行。

使用兩個不同的同步策略時,我們就可以判定「正確」的平行作業數目,並定義一組「正確」的程序:

由內向外

  1. 從「設計模型」開始,將類別和子系統組合在一組合作元素中,這些元素會 (a) 緊密地互相合作,並且 (b) 需要在相同的控制緒中執行。在將元素分割到不同的控制緒時,請考量在訊息序列中間引進跨程序通訊時,所會造成的影響。
  2. 另一方面,將完全不會互動的不同類別和子系統,放置在不同的控制緒中。
  3. 這項叢集作業要持續進行到將程序數目縮減到小於仍然可以分散及使用實體資源。

由外而內

  1. 指出系統必須回應的外部刺激。定義個別的控制緒來處理每一個刺激物,並用個別的伺服器控制緒來提供每一項服務。
  2. 考慮使用資料完整性以及序列化限制,將這組起始控制緒的數目減少到執行環境可以支援的數目。

這並不是一項線性的決定性程序,來決定最理想的程序視野;這個程序需要反覆多次,才能達到可接受的程度。

範例

下圖顯示 ATM 中的類別如何分散到系統中的各個程序和執行緒。

ATM 類別分散到程序和執行緒圖例

將類別對映至 ATM 的程序



內容
多次出現的項目
事件驅動
持續進行中
選用
規劃
可重複的
詳細資訊