作業: 定義系統環境
這項作業定義如何建立系統環境圖,顯示系統和參與者之間的最上層合作情形。
規範: 分析 設計
目的
  • 根據「使用案例模型」,建立最上層合作關係來顯示系統(塑造為最上層子系統)、介面及與參與者的關係,包括在參與者和系統之間流動的外部 I/O 實體。
關係
步驟
簡介

儘管「使用案例模型」顯示系統的行為觀點,但在這項作業中,您會在環境中建立系統的邏輯模型,利用工作成果:使用案例模型工作成果:增補規格環境圖中描繪:

  • 由系統實現的介面(依據系統提供的操作和支援的相關通訊協定、 系統實現的狀態變數儲存器,以及以技術效能測量來表示的屬性)。
  • 在系統和參與者之間流動的 I/O 實體
  • 系統正確運作所需的介面(由與系統互動的參與者實現)。 如果參與者代表系統必須溝通的一個現有的系統,則這些必要的介面通常只是反映這個另外的系統所強加的限制。

環境圖顯示系統和參與者之間的最上層合作情形。結構上類似系統的「使用案例模型」。此合作情形是在「分析模型」中建立。

I/O 實體(以塑造為 "I/O" 模板類別來表示,有屬性,沒有操作)描述流進或流出系統的事物, 在一般的系統案例中,可能包括資料、質量、能源或實體組件。 I/O 實體會與參與者-系統配對建立關聯(在建模期間),表示這些特定的 I/O 實體在參與者和系統之間流動。 也可以選擇在圖型上顯示,與參與者建立關聯,在關聯上以 "send" 或 "receive" 模板來表示流動方向,指出相對於參與者的方向。

「系統操作」是指可向物件要求來影響行為的服務。 操作會指定名稱、類型、參數及限制來呼叫相關的行為。「操作」依據介面及目前考量的(子)系統的主要責任來分組。 系統操作呼叫代表與系統之間較細微的互動,比使用案例實例的互動更細微,使用案例實例由操作呼叫和回應所組成。

狀態變數和儲存器是在系統實現的介面上所定義的屬性。這些都很抽象,必須由系統維護對應於屬性類型和多重性的資訊,也要允許儲存、擷取及修改這項資訊。 系統中不一定會有屬性直接對應於介面上定義的屬性。 變數和儲存器沒有明顯的差別,只是反映屬性如何控制系統的(抽象)狀態機的操作。 「狀態」會保留一段時間,不同於某個時刻發生的事件(例如信號到達)。 這裡提到的狀態機是指有限狀態機,通常由非常少的變數來決定「狀態」的描述; 例如,現行狀態可能由列舉類型的單一屬性的值來指定。 然而,系統對於事件的反應不一定只依賴事件的本質(和傳送的資訊.,例如,在操作變數中)和現行狀態,也取決於其他屬性的值(可能很多)。

「技術效能測量 (TPM)」是從「增補規格」或「使用案例模型」中挑出的關鍵技術屬性,視為重要的系統效能指標, 如果無法達到,系統開發將會冒險在成本超支、進度落後或效能受限的情況下進行。 整個專案生命週期會追蹤這些屬性出現的新值。 例如,系統交貨重量可能必須低於一定的限制,且在設計和建構期間必須追蹤是否達到這個目標。 系統交貨時的重量很顯然是系統實例的一個屬性(在許多方面可以看出), 不一定和開發期間的目標重量相同(為了讓系統進入運作軌道,您可能希望重量輕一些)。 UML 標示值可以註明 TPM 屬性來表示效能屬性,例如:

"TPM" weight {maximum_weight = 1000kg}

「技術效能測量」也適用於其他非結構化特性,例如操作回應時間。 標示值可用在系統操作上或系統本身來記錄這些特性。

建立初步環境圖

下列步驟顯示系統在環境中逐步形成的詳細程度。以保全系統為例,此系統可以保護財產免於遭受非法入侵,除了發出警報,也能夠向某些應變服務回報入侵事件。 

隨著您在「使用案例模型」中不斷發展和加入更多細節(尋找參與者;如果已執行「商業模型」,且已找出參與者甚至是操作,則詳述互動情形), 您可以建立初步的合作關係,並以「環境圖」來闡述這項觀點。 「環境圖」可以如下圖所示建立,一開始先不加入系統介面。 系統描繪成最上層子系統(以 "system" 為模板),最後會實現多個介面。 也顯示參與者和關聯,一開始也同樣不加入細節。

環境圖(初步)

環境圖(初步)

修正關聯和介面

接下來,您要修正參與者和系統之間的關聯,以及系統介面。您可以開始推論作業:尋找參與者和使用案例中出現的系統操作和系統屬性(後來:作業:詳述使用案例)。 請注意,系統現在以介面呈現在參與者面前。 喜歡的話可以顯示這個觀點的實現(在圖型中以虛線強調),但省略也不會失去太多資訊。

在此階段,只是根據領域知識及先前在企業層次上實現使用案例時已完成的任何工作,暫時地指出 I/O 實體。 請注意,不一定要在圖型上顯示 I/O 實體,但這樣有助於推論參與者和系統的互動。

因此,您可以開始描繪參與者和系統之間的連線特性(例如,記錄必要的通訊協定),並記錄兩者之間流動的實體。

環境圖(預備)

環境圖(預備)

詳述系統操作及其他系統特性

在此步驟,您要開始建構使用案例情境(使用案例的實例),從這些情境中描述系統操作(提供的和必要的)。 情境可以用互動圖或活動圖來表示。 使用案例中的每一個黑箱步驟代表與系統之間的細部互動,且對映到操作呼叫(但不一定是唯一的操作;其他黑箱步驟可能使用相同的操作)。 除了在「環境圖」(和後來的「分析模型」)中定義系統操作,為了追蹤,呼叫的操作上也要註明使用案例。 操作也繼承任何已分配給黑箱步驟的效能需求或其他非功能面需求。 在檢查情境中執行的每一個黑箱步驟時,您會發現名稱的用法可能暗示狀態變數和儲存器,在執行使用案例情境時必須由系統維護。 您也可以修正必要的 I/O 實體,並與操作呼叫建立關聯性,以形成在參與者和系統之間傳送的信號。 

將系統介面切割為更特殊的介面可能有助於理解;的確,「增補規格」中可能有此介面需求。 下圖顯示每一個參與者類型的系統介面進化到「提供的系統介面」的情形,但這並非固定的慣例。 多個參與者可能共用一個介面,一個參與者也可能有多個介面。

此分析也可能指出系統所需的介面,亦即,參與者必須支援的介面(處理來自系統的訊息)。 這些都可以用一種對稱的方式加入圖型中(例如,請參閱下圖中由「緊急服務」參與者實現的 IE-services/ESS「必要的系統介面」)。 同樣地,一個參與者可能支援(實現)多個介面(圖型中未顯示)。

如圖所示,操作、儲存器等必須新增至詳細格式的介面(在屬性和操作隔間中)。 圖型只局部詳述(重要的部分)。未詳述實體環境介面、參與者等。 同樣地,省略提供的系統介面的實現也不會失去太多資訊。

環境圖(最終)

環境圖(最終)。

在「環境圖」中捕捉的這個最上層合作關係可以精確指定介面、連線、流入和流出系統的事物,以及相關的效能特性, 可以在系統環境下的其他元素以外,以稍微獨立的方式進行系統開發。