儘管「使用案例模型」顯示系統的行為觀點,但在這項作業中,您會在環境中建立系統的邏輯模型,利用工作成果:使用案例模型和工作成果:增補規格在環境圖中描繪:
-
由系統實現的介面(依據系統提供的操作和支援的相關通訊協定、 系統實現的狀態變數和儲存器,以及以技術效能測量來表示的屬性)。
-
在系統和參與者之間流動的 I/O 實體。
-
系統正確運作所需的介面(由與系統互動的參與者實現)。 如果參與者代表系統必須溝通的一個現有的系統,則這些必要的介面通常只是反映這個另外的系統所強加的限制。
環境圖顯示系統和參與者之間的最上層合作情形。結構上類似系統的「使用案例模型」。此合作情形是在「分析模型」中建立。
I/O 實體(以塑造為 "I/O" 模板類別來表示,有屬性,沒有操作)描述流進或流出系統的事物, 在一般的系統案例中,可能包括資料、質量、能源或實體組件。 I/O 實體會與參與者-系統配對建立關聯(在建模期間),表示這些特定的 I/O
實體在參與者和系統之間流動。 也可以選擇在圖型上顯示,與參與者建立關聯,在關聯上以 "send" 或 "receive" 模板來表示流動方向,指出相對於參與者的方向。
「系統操作」是指可向物件要求來影響行為的服務。 操作會指定名稱、類型、參數及限制來呼叫相關的行為。「操作」依據介面及目前考量的(子)系統的主要責任來分組。
系統操作呼叫代表與系統之間較細微的互動,比使用案例實例的互動更細微,使用案例實例由操作呼叫和回應所組成。
狀態變數和儲存器是在系統實現的介面上所定義的屬性。這些都很抽象,必須由系統維護對應於屬性類型和多重性的資訊,也要允許儲存、擷取及修改這項資訊。 系統中不一定會有屬性直接對應於介面上定義的屬性。
變數和儲存器沒有明顯的差別,只是反映屬性如何控制系統的(抽象)狀態機的操作。 「狀態」會保留一段時間,不同於某個時刻發生的事件(例如信號到達)。 這裡提到的狀態機是指有限狀態機,通常由非常少的變數來決定「狀態」的描述;
例如,現行狀態可能由列舉類型的單一屬性的值來指定。 然而,系統對於事件的反應不一定只依賴事件的本質(和傳送的資訊.,例如,在操作變數中)和現行狀態,也取決於其他屬性的值(可能很多)。
「技術效能測量 (TPM)」是從「增補規格」或「使用案例模型」中挑出的關鍵技術屬性,視為重要的系統效能指標, 如果無法達到,系統開發將會冒險在成本超支、進度落後或效能受限的情況下進行。 整個專案生命週期會追蹤這些屬性出現的新值。
例如,系統交貨重量可能必須低於一定的限制,且在設計和建構期間必須追蹤是否達到這個目標。 系統交貨時的重量很顯然是系統實例的一個屬性(在許多方面可以看出), 不一定和開發期間的目標重量相同(為了讓系統進入運作軌道,您可能希望重量輕一些)。
UML 標示值可以註明 TPM 屬性來表示效能屬性,例如:
"TPM" weight {maximum_weight = 1000kg}
「技術效能測量」也適用於其他非結構化特性,例如操作回應時間。 標示值可用在系統操作上或系統本身來記錄這些特性。
|