系統工程三明治——將需求、建模與設計相結合

近幾年，UML 在可視化軟件開發方面獲得了一定程度成功。隨著UML 2.0 的到來，對大型及復雜的系統與軟件進行建模已經變成現實。為了做到這一點，我們需要理解模型與其它系統工程領域，特別是需求管理的關系。

需求管理與系統模型的關系是什么呢？它們怎樣才能工作到一起？本文的目的就是從流程的角度來回答這些問題。

需求管理與系統建模

圖1 通過三明治的類比總結了需求管理與系統建模之間關系的關鍵概念。

在這個比喻中，需求管理是開發周期中的“面包和奶油”。三明治沒有面包會成為什么？但是，只有需求管理會有點干；通過系統模型的填充可以把面包連在一起，并使得整體變得更有意義。正是面包及填充物才構成了三明治。系統模型不是需求，許多工程師錯誤地認為系統模型自身就是對需求的詳細描述。事實上并非如此。即使UML模型已經詳細到能夠生成代碼，但是也有些系統方面——特別是非功能需求，如性能，安全等無法從系統模型中獲得。這些額外的需求也必須被跟蹤并需要有測試用例與之對應。這需要有需求管理活動對建模進行輔助。

僅使用模型作為合同的描述也是很困難的；在大多數情況下，客戶/供應商的合同依然需要使用文本文檔來表達。模型也許會在文檔中以圖形的形式出現， 但是僅有圖形對合同來說還是不夠，因此，需求與系統建模是相輔相成的。

層次控制復雜性

圖2 顯示了系統工程的一種典型的層次化方法。這種層次很重要，不僅作為對當今復雜系統的分解方法，也是因為工程流程幾乎總是涉及多個組織。不同的組織也許要執行不同的工程層次。

層次代表抽象的水平。這些抽象層次的一個重要特點是每層可以使用不同的語言，但是術語必須被映射到模型術語上。例如，問題領域的工程師可能很自然地談到涉眾而不是執行者、實體、類、關系、能力與用例。建模的障礙主要是必須學習一種新詞匯及由此帶來的困惑。

建模應該發生在所有層次，但是具有不同的抽象程度。這意味著同一實體可能在每個層次的模型中扮演不同的角色。圖3說明了下面的例子：例如，當對行李登記系統的涉眾層進行建模時， 叫做“飛機”的類也許會代表實際的物理實體。在系統層，“飛機”類也許代表系統的飛機的邏輯表示（如果你喜歡，可以叫做關于飛機的系統知識）并包含屬性細節。最后，在軟件設計層次，“飛機”類將代表飛機對象的軟件實現。

試圖在一個模型中管理不同層次的抽象會增加復雜性。因此不是力圖在一個UML模型中同時對同一個實體進行所有三種形式的表示，而是采用在每個層次建立分離的模型方法。上層模型的一些細節將被下層模型引用，但是，各種實體角色將隨著模型層次而逐步細化。跟蹤技術可以通過層次對模型之間進行映射。

系統的系統

了解被開發的系統，最重要的是了解其上下文內容。在開發前期使用的一種著名的建模方法就是繪出“上下文圖表”，來描繪系統與環境的外部關聯。

這種核心觀念來源于“系統的系統”思想，如圖4。對問題領域進行建模時，不僅對系統本身進行建模，而且要考慮封閉的系統。所創建的模型是域模型，它描述系統的外在部分及其接口。系統作為一個實體存在于域模型中，并可能參與到一些圖符中，但是，在這一層它是“黑盒”，是對系統本身進行建模的開始。

意識到一些設計發生在所有層次是很重要的。即使是在對問題進行建模時，部分模型將描述系統已存在的部分，部分描述將要實現的系統。新的封閉系統設計過程中這一點很明顯，此處的封閉系統指所要開發系統的外部支撐系統。

建模為設計提供依據

建模支持設計活動。它可以幫助工程師充分理解系統怎樣從一個特定層次的需求分解到下一個層次的需求。需求本身也是不斷細化的要求的一個縮影。建模也是創造性工作發生最多的地方，形成了包含模型圖符的設計文檔與文本解釋、依據及上下文內容。

圖5描述了模型可以用來從上一層需求推導出下一層需求的方式。左側的方框代表需求文檔，右側的代表設計文檔。雖然許多模型非常專業，但每個系統都有一些方面可以用UML 2.0這樣的方式來建立通用模型。大多數系統具有實體、事件、狀態、接口與執行者，它們以各種方式相互關聯，可以用不同的UML 圖符進行建模。

設計文檔也能夠表達模型中所沒有包含的與非功能分解相關的需求。通過這種方式，對于系統的特定層次來說，設計文檔就可以成為單一的參考點。

把設計從需求文檔（及其可跟蹤性的維護）中分離出來也使得重用設計與建立產品設計庫成為可能。

建模的例子

涉眾層（問題域）

這一層把初始需要的陳述作為輸入需求，并推導出涉眾需求。這一層根植于問題域。

這一層的建模重點是封閉系統，即“行李登記系統”所嵌入在的“行李處理系統”。一個關鍵的目標是為系統域建立詞匯表。這些詞匯隨圖形單元如類、執行者、用例與狀態的增加被收集在模型中。

首先用類圖建立封閉的系統，其中的行李登記系統以類的形式也存在于系統中。這一系統如圖6所示。行李登記系統與其它類之間的關系是用來定義系統的周圍環境的。

這一階段，模型另一部分是用例圖。一個用于封閉的行李處理系統（圖7）， 另一個用于行李登記系統（圖8）。

圖7采用“系統的系統”視圖，在其它交互系統的背景下描述行李登記系統。

第二個圖的目的如下:

• 幫助定義系統邊界，用矩形標示，用UML 的術語來說叫做“主題”，是行李登記系統類的一個實例。
• 把涉眾與外部系統表示為執行者。它們在系統邊界的外部。
• 把用例的名稱作為涉眾的最高目標。注意在用例之間的“包含”關系，這允許根據能力對系統進行分解。

圖9顯示了這一階段的另一種圖，一種構架圖。在這里封閉系統被它的內部部件所描述，其中之一是行李登記系統。也顯示了與周圍部件的接口。

注意在這一層中我們只允許在頂層用例中描述行李登記系統的細節。在其它圖中，行李登記系統作為“黑箱”存在，并對其外部關系進行建模。

從這一層的模型中，可以推導出下列的需求管理工件：

• 從模型中發現基于領域的術語詞匯表；
  例如，每個類、執行者與用例形成詞匯條目，同時也提供相關的文本解釋。
• 基于模型中執行者的，行李登記系統的涉眾列表。
• 基于類的關聯與部件接口的外部接口與外部系統的記錄。
• 行李登記系統場景列表。
• 基于如主要用例圖中使用“包含”關系的來形成層次結構，也可以用于涉眾需求文檔的層次結構
• 對于每個用例，涉眾所要求的關鍵能力。
• 涉眾提出的關鍵約束能力列表。這可以從評審每個圖并詢問用于提取約束問題，如“多快？”，“使用頻率？”等獲得。約束有時可以在適當用例的注釋中表示。例如，在行李登記系統中，或許有個用例叫做“秤量行李”，在注釋中說明“兩分鐘內被放在傳送帶上”。

能力需求很可能會被工程師重新用文本方式表達，利用術語表中的詞匯畫圖。能力經常被具有數量的質量需求詳細描述，如性能，它們沒有被模型所表達。除此之外，在模型中沒有表達的分離的約束必須用文本捕獲。

系統開發層

這一層把涉眾需求作為輸入需求，并推導出系統需求。這一層從抽象的角度看根植于解決方案域。

在抽象解決方案層，我們開始考慮功能與行為而不是能力。問題層模型現在被細化來顯示用于提供能力的功能步驟。前面的類圖用屬性來細化，如圖10。

系統行為通過順序圖與狀態圖結合描述。圖11 顯示了一個順序圖的例子。

一個構架圖也可以被用于把行李登記系統首先分解成子系統與部件。如圖12 所示的例子。外部的矩形框現在是行李登記系統，而在圖9中是以內部框的形式出現的。這里形式化建模的一個最大的好處就可以顯示出來了，被分解的層次接口的一致性可以被工具自動檢查。

系統建模最后，可以推出下面三條：

• 系統需求與每個被識別的系統功能相關。
• 一個頂層的構架顯示子系統與內部接口。
• 一組子系統需要被開發。

對于每個被識別的子系統現在產生了一個新的需求層。

子系統開發層

這些層以系統需求作為輸入需求，完成頂層構架并推導子系統需求。這些層的特性與系統開發層很相似，只是現在的重點是一個單一的子系統。在系統層的建模與設計依據的重點是決定哪些系統需求要流向這個子系統。

系統模型與需求管理的集成原理現在已經被建立起來了，因此我們不必在像先前那樣詳細地定義下層的細節。

部件開發層

在系統分解的某一水平，子系統成為部件，它們中的一些已經是存在的，其它的一些需要被開發；一些是軟件，其它的是硬件。對于軟件來說，UML 模型可以處理部件層直到詳細設計與代碼生成， 并且在這一階段，可以完全轉換到UML 開發工具中來完成整個開發周期。

結論

通過將需求管理與系統建模相結合，我們獲得了一種更加準確、易懂的描述復雜問題和解決方案的方法。

系統建模給需求工程帶來的好處：

• 系統模型為在需求層之間的設計流程中加入了形式化內容。
• 系統模型支持需求以文本方式表述所用詞匯的一致性。（事實上，可以有工具直接從模型字典中提取術語詞匯表）
• 來源于系統模型的設計依據成為需求層之間跟蹤性的依據。
• 系統模型的結構可以為需求文檔提供結構。（通?？梢岳霉ぞ邚哪Ｐ椭薪⑿枨笪募拇缶V。）
• 系統模型可以被嵌入到系統設計文檔中。這些可以為系統模型提供文本的上下文關系，為設計選擇、圖形解釋等提供依據。
• 影響分析可從需求直接過渡到模型。
• 模型所不能捕獲的非功能與性能需求可以作為文本陳述來管理。

原文轉自：http://www.anti-gravitydesign.com