利用 RUP開發大規模系統

領測軟件測試網

利用 RUP開發大規模系統

（rational公司）

主題

• 歷史記錄
• 互連系統構成的系統
• 軟件開發生命周期
• 系統開發的工作流程和工件
• 互連系統構成的系統的開發
• 在互連系統構成的系統中的用例
• 在互連系統構成的系統中的設計模型
• 在互連系統構成的系統中的信息集
• 互連系統構成的系統之構架
• 系統之間的關系
• 應用范圍
• 總結
• 參考資料

歷史記錄

本文是根據發表在 ROAD 1995 年 5-6 月期的由 Ivar Jacobson、Karin Palmkvist 和 Susanne Dyrhage 合著的 "Systems of Interconnected Systems" 進行撰寫的。本文吸收了數個大規模系統開發項目的寶貴經驗，并有意將它們與 Rational Unified Process 版本 5.1 [2] 和統一建模語言結合起來 [3]。

互連系統構成的系統

開發大規模系統時，其復雜程度將大大增加。它不但要求您能夠理解一套更為復雜的工件，并且由于需要管理更多的一組資源，您為此還要負擔額外的開銷。本文描述了一個構架模式，它用于幫助管理新增的復雜性開銷。該構架模式在 [4] 的其他地方討論時被稱為互連系統構成的系統。

在構建諸如命令和控制系統等大型復雜系統或高度集成的 IT 解決方案時，這種構架模式是很有用的。這些類型的“超系統”在大多數情況下分成幾個不同的部分，每個部分作為單獨的系統獨立開發。超系統通過一組互連系統實現，而互連系統之間相互通信，履行超系統的職責。其中一個系統體現整體性能，我們稱之為上級系統。其余系統代表整體的一個部分，我們稱之為從屬系統。上級系統與實現它的從屬系統截然不同。不同類型系統之間的關系涇渭分明：從上級系統的角度來看，從屬系統是子系統，請參見圖 1。

 

圖 1. 上級系統的規約由一個互連系統構成的系統來實施，其中系統 A、B 和 C 分別是上級系統的子系統 a、b 和 c 的實施。

區分上級系統及其從屬系統有幾個好處：

• 從屬系統在生命周期內的所有活動中都可以單獨管理，其中包括銷售和交付。
• 通過把從屬系統插入到由互連系統構成的其它系統，就很容易使用從屬系統來實施其他上級系統
• 在開始構建系統的時候，并不總是知道它是不是一個由互連系統構成的系統。您可以從“簡單的”系統視圖開始，在生命周期的晚期再決定是否需要應用由互連系統構成的系統模式。
• 您不必開發新版本的上級系統，就可對從屬系統進行內部變更。只有在主要功能變更時才要求開發上級系統的新版本。

每個從屬系統都有一組相關的工件，工件之間有清晰的可追蹤性關系。從從屬系統的工件集到上級系統的相應工件集，它們之間也有可追蹤性。每個從屬系統可以作為獨立的開發項目進行管理，它們都有自己的生命周期階段：先啟階段、精化階段、構建階段、產品化階段。

如果正在構建的“超級系統”規模很大，可能需要進一步劃分從屬系統，從而將其作為一個由互連系統構成的系統。

軟件開發生命周期

在 Rational Unified Process，開發生命周期從兩個角度進行介紹和討論：管理角度和開發角度，請參見圖 2。

從管理角度來看，開發一個系統或者開發新一代的系統都要經歷四個生命周期階段。從開發角度看，您以迭代方式開發日臻完善的系統版本。迭代過程中執行的活動在 Rational Unified Process 分成一組核心工作流程。每個核心工作流程著重描述系統的某個方面，最終形成一個系統模型或文檔集。

圖 2. 迭代模型。

將其推廣到互連系統構成的系統，上級系統及其每一個從屬系統都要經歷自己的生命周期，并且它們經常被當作單獨的項目。

圖3. 每個系統，包括上級系統和從屬系統，都要經歷自己的生命周期。

當然，生命周期確實存在依賴關系。如何正確管理依賴關系是開發由互連系統構成的系統所面臨的難題之一。依賴關系有以下類型：

• 生命周期與時間相關。上級系統的生命周期首先開始。一旦上級系統經歷過至少一次迭代而且從屬系統的接口相對穩定，從屬系統的生命周期即可開始。實際上，在上級系統至少經歷一次迭代之前，您甚至可能不知道哪一個是從屬系統。
• 從屬系統的接口一旦穩定，上級系統的生命周期即可進入維護階段。這意味著不進行主動開發，除非出現問題才要求修改從屬系統的接口。
• 從屬系統的接口由開發上級系統的人掌握。有關接口的更多信息，請參見 [3] 和 [5]。
• 實現從屬系統接口的類由開發從屬系統的人所有。

系統開發的工作流程和工件

有一個自然前提，即上級系統和從屬系統可以使用相同的工件集和通過相同的工作流程來進行開發，這在開發非合成系統時尤為典型。在我們繼續說明如何執行這一前提前，需要先引入工件和工作流程。在 Rational Unified Process 中，我們引入了五個核心工作流程，請參見圖 4。它們分別是：

• 業務工程 - 目的是評估即將使用該系統的組織，更好地理解通過系統解決的需求和問題。最終結果是得到一個用例模型和業務對象模型。該工作流程是可選的。如果即將部署系統的組織結構過于簡單，則工作流程可能不會增值。
• 需求 - 目的在于獲取和評估需求，重點放在可用性。其結果是生成一個用例模型，其中主角代表與系統通信的外部單元，用例代表事務序列，為主角提供可測量的結果值。
• 分析設計 - 目的在于調查預期實施環境及其對系統構建的影響。其結果是生成一個對象模型（設計模型），包括用例實現。這些用例實現說明了對象如何進行通信以執行用例流。該工作流程可能包括類和子系統的接口定義，指定它們在所提供的操作上的責任。這個對象模型還在實施語言、分布等方面進行改造，使之適應實施環境。將分析結果作為一個單獨的模型考慮有時很有用，這時該模型稱為分析模型。

圖 4. 每個核心工作流程都與一個特定的模型集相關聯。

• 實施 - 目的是在規定的實施環境內實施系統。其結果是生成源代碼、可執行代碼和文件。
• 測試 - 目的在于保證系統與預期系統相吻合，并且在實施中沒有出現錯誤。它生成一個合格的、準備交付的系統。

互連系統構成的系統的開發

• 分解標準
• 組織
• 上級系統的生命周期
• 從屬系統的生命周期

我們必須完成的工作是確定如何能夠將一個系統的職責分布在幾個系統之間，每一個系統負責一個明確定義的責任子集。這就是說，主要目標是定義這些從屬系統間的接口。實現上述主要目標之后，其余工作就可以根據“分而治之”的原則，由每個從屬系統獨立完成。因此，除了在實施以后對系統進行測試之外，這就是我們要為系統做的全部工作。

分解標準

那么如何決定是否將系統分解為由互連系統構成的系統？下面是應值得注意的兩個特征：

• 如果系統具有相當的規模和復雜性，則可以把問題分成許多小問題，這樣更容易理解。

• 是否正在處理物理上獨立的系統？在處理遺留系統或者遺留舊構架時常常會遇到這種情況。
• 分解有助于定義系統各部分之間的自然接口和窄接口。
• 您可以決定使用一些重要的 COTS（市售）產品來實施系統的一個部分。分解將有助于明確您打算如何使用 COTS 產品。

• 分區可以最大限度地發揮分布式開發組織的潛力，并且清楚劃分在地理上分散的幾個團隊之間的工作。

要考慮以下風險包括：

• 過度分割會導致只見樹木不見森林的問題。
• 使用物理上分離的系統或者物理上分離的團隊，有扼殺任何形式的復用的危險，最后得到的是一個僵化的系統。

組織

要降低上述風險，關鍵是要委派一組人監督整個開發工作。這個小組通常稱作構架設計師團隊，他們應該重點關注以下問題：

• 定義一個整體構架，并且從屬系統遵守該構架。
• 適當關注從屬系統之間的復用和經驗共享。
• 對生產什么工件、從屬系統工件與上級系統工件之間有什么關系有清晰的理解。
• 定義一個有效的變更管理策略，并得到所有團隊的遵守。

構架設計師團隊可以（但不總是）控制上級系統的開發。有關組織方面的更充分討論，請參見 [6]。

上級系統的生命周期

首先，可以選擇執行業務工程，以便更好地理解系統的環境。在以下情況中，它可以創造價值：

• 開發人員需要更好地理解組織，
• 組織本身的業務運作方式存在不同類型，術語和流程需要統一，或者
• 軟件工程與業務重建工程一同完成。

另請參見 [6]。

該工作將產生一個業務用例模型和一個業務對象模型。另一種方法是，選擇執行有限的業務工程，只關注業務領域的關鍵概念，并在業務模型對象中將其記錄下來。這種方法通常稱為領域建模。

一旦對業務模型集采取了措施，您需要開始獲取整個系統的需求。我們對由互連系統構成的系統的需求建模要求與其他系統一樣。用例模型是一種非常自然的表示結果的方法，請參見 [7]�？紤]該上級用例模型最直截了當的方式就是假定它完全獲取了系統的行為需求。然而情況可能很少如此。既然我們需要用其他系統來實施該系統，整體系統很可能相當復雜。因此，在這個級別上鉆牛角尖就不是一個好主意。因而，上級用例模型通常給出一個完整但經過簡化的系統功能需求圖。在該級別上沒必要過于詳細，因為詳細建模將在每個從屬系統中進行。而且，許多需求在分成幾個子系統的上級用例中并不一定看得見，這也是事實。此類需求可以說是子系統的“局部”需求。

分析設計的目的是為了獲得一個強壯的系統構架，當然這對由互連系統構成的系統是極其重要的。上級系統的開發人員必須獲得一個強壯的從屬系統結構，但他們根本不必為內部結構勞心費力。因此我們將使用子系統的概念對系統劃分進行建模，將系統分成許多更小的部分。為了得到正確的子系統集，并得到如何在這些子系統之間分配上級系統的職責的初步構思，我們開發了一個分析模型。在執行高級用例時，分析類應該表現系統內的事務所承擔的角色。因此，分析模型與高級用例模型類似，給出了完整對象結構的一個簡化視圖。

將功能相關的分析類進行組合，分到不同的子系統中。因而，我們得到的子系統結構從它僅僅基于功能標準的意義上看是理想的，例如，我們并未考慮任何需求分布。遺留系統的存在通常是一個影響巨大的因素。遺留系統可能執行一些或者許多在分析模型中定義的職責。這些系統的存在還可能引起對分析中發現的職責再進行劃分，以便能最大限度地復用現有的能力。

設計結果可能是一個子系統結構，它與分析過程中基于功能標準所定義的結構差別很大。因此我們最后得到了一個設計子系統結構，每一個子系統將通過一個從屬系統進行實施（請參見圖 5）。為了能夠繼續每個此類系統各自的開發工作，我們為每個子系統定義了接口。實際上，定義接口是在上級系統級別執行的最重要活動，因為接口提供了開發從屬系統的規則。不需要定義設計類，唯一要做的事情就是定義設計子系統的接口。

實施無需作為上級系統生命周期的部分來進行，而只執行一些原型設計工作，研究系統特定方面的技術。

最后的工作流程是測試，這里指的是組裝不同從屬系統時的集成測試，并還測試每個上級用例是否根據其規約通過互連系統協作獲得執行。

圖 5. 上級系統通過一個模型集來描述，其中高級設計模型定義的子系統將通過從屬系統實施。從屬系統的接口歸上級系統所有。

為說明如何使用上級系統，下面給出了幾個迭代計劃樣本；一個是上級系統生命周期先啟階段的迭代計劃，另一個是精化階段的迭代計劃。我們使用活動圖來描述迭代計劃。這些圖中的動作狀態對應 Rational Unified Process 定義的工作流程明細。

圖 6. 描述上級系統先啟階段迭代計劃示例的一個活動圖。

圖7. 描述上級系統精化階段迭代計劃的一個活動圖。由于您為了研究系統的有關技術方面執行了有限的原型實施，這里出現了動作狀態“實施類”。

從屬系統的生命周期

每個從屬系統按正常方式進行開發，把其作為主角與其他系統通信的黑箱來考慮。如前所述，您可以為每個子系統執行正常的活動集并開發通常使用的模型集。如果上級級別的模型在所有明細中都有定義，那么在不同級別的模型之間都能得到完整遞歸，但如前所述，實際上情況很少是這樣的。

對從屬系統，您需要執行需求工作流程。上級系統的接口和用例將成為你理解從屬系統邊界及其主角的主要輸入。

在執行從屬系統的分析設計時，上級系統定義的接口與高級用例一起將成為“邊界條件”。

圖 8. 從屬系統由它們各自的模型集來描述。

為說明如何使用從屬系統，下面給出了兩個從屬系統生命周期的迭代計劃示例。

圖 9. 從屬系統先啟階段迭代計劃示例。這是一個不完整的迭代，因為不產生任何可執行代碼。

圖 10. 從屬系統精化階段迭代計劃示例。精化階段的重點在于完成構架和已改進系統的定義上。

在互連系統構成的系統中的用例

您應該為每個系統，包括上級系統和從屬系統，在互連系統構成的系統中建立一個用例模型。它們按以下方式相關（另請參見圖 11）：

• 上級系統的高級用例分解到子系統上（不一定，但通常是）。每個“分塊”將成為從屬系統模型中的一個用例，請參見圖 11。
• 從一個從屬系統的角度來看，其他從屬系統是它用例模型的主角，請參見圖 12。

圖 11. 上級系統的高級用例與從屬系統的詳細用例之間的關系。

圖 12. 在從屬系統 X2 的用例模型中，從屬系統 X1 和 X3 都被視作主角。

關于描述上級系統的用例有一些特殊注意事項。由于從某種意義上說，您將重新描述每一個從屬系統的所有需求，因此深究這些用例毫無意義。在正常情況下，只要寫下高級用例事件流的分步大綱就足夠了，不必展開詳述。

在該用例模型中，不應使用任何用例關系（泛化關系、擴展關系、包含關系）。一般情況下，它不創造價值，原因如下：

• 您不會詳細描述高級用例，因此不必擔心有關文字出現在幾個地方。
• 無論如何，當您將高級用例分解到“從屬系統”上時，都需要建立信息結構。將它與其他構造機制混合會產生疑惑。

但有一個重要例外，即如果您打算尋找由互連系統構成的系統中的可復用構件。建立上級用例模型以便查找一般用例模型，這是一種尋找可復用構件的好方法。有關該主題的詳細信息，請參見 [6]。

在互連系統構成的系統中的設計模型

由互連系統構成的系統中的每個系統，包括上級系統和從屬系統，都應該有自己的設計模型。設計模型按以下方式相關：

• 上級系統設計模型中的子系統定義了從屬系統的邊界。
• 為上級系統子系統定義的操作是定義從屬系統接口的輸入。

對上級系統設計模型的描述不如描述從屬設計模型詳細。描述對象包括：

• 子系統，簡要說明。
• 用例實現，利用子系統協作方式描述。記錄這些高級用例實現的一般方法是繪制序列圖。通過繪制這些圖形，您可以定義在從屬系統上的高級用例的“分塊”，請參見圖 13。
• 子系統的操作。
• 子系統的接口定義。

圖 13. 實現上級用例 A 的序列圖。

 

在互連系統構成的系統中的信息集

大多數組織在理解如何管理工件以及如何正確理解它們的依賴關系等方面都投入大量精力。我們在上一節特別討論了上級用例模型和設計模型與從屬用例模型和設計模型之間的依賴關系。另外還要考慮一些一般性的依賴關系問題。

系統經過生命周期的某個關口后，將產生可組織成信息集 [8] 的工件，請參見圖 14。這些信息集按“共同”演進的工件進行組織。

• 根據正在構建的應用程序類型，可以定制每個集合的確切內容，但集合保持不變。
• 您需要理解集合之間的依賴關系，這樣才能有效地維護工件之間的可追蹤性。

圖 14. 系統的生命周期將產生信息集。

在互連系統構成的系統中，上級系統和每個從屬系統將產生各自的信息集，請參見圖 15。

• 從屬信息集對相應的上級信息集有依賴關系。
• 由于應用程序類型不同，上級系統之間的相應信息集的內容類型也可能不同。
• 相關的從屬信息集應該是獨立的，只是它們服從于上級系統定義的相同子系統接口。

在維護上級系統與從屬系統工件之間可追蹤性上投入的精力應該盡量要少。應確定維護系統內的可追蹤性的優先順序。

圖 15. 在互連系統構成的系統中的每個系統將生成自己的信息集。

互連系統構成的系統之構架

由互連系統構成的系統中的每個系統，包括上級系統和從屬系統，都應該定義自己的構架。

對于上級系統，構架文檔應包括以下方面：

• 上級系統的關鍵用例或場景。
• 對互連系統構成的系統的分層。
• 如何處理從屬系統之間的復用以及復用內容。
• 所有從屬系統都能使用的通用關鍵機制及其實施。例如，所有從屬系統都應該使用通用的通信、錯誤報告、容錯管理機制，否則上級系統不會表現為同類系統。

對于從屬系統，構架文檔應該澄清以下問題：

• 從屬系統在互連系統構成的系統內的角色。
• 從屬系統的關鍵用例或場景。
• 從屬系統如何使用為由互連系統構成的系統定義的分層結構。換句話說，就是定義從屬系統如何履行在互連系統構成的系統的分層結構中為它定義的職責。
• 使用哪些通用的關鍵機制、如何使用用以及添加哪些應用程序專用的關鍵機制。
• 如何復用。確切地說，哪些子系統是兩個或多個從屬系統公有的，需要建立哪些機制來允許從屬系統進行通信。

系統之間的關系

您已經看到，常用的系統開發活動也可應用于通過互連系統構成的系統實施的系統。這是非常有利的，因為它意味著你不必用一種與其他系統大相徑庭的方式處理此類系統。您還可以很好地將上級系統與其以其他從屬系統形式進行的實施分離。在互連系統構成的系統中的每個系統都有自己的生命周期。既然每個系統可能有不同的特點，您可以使用不同的開發流程來生成系統。依據 Rational Unified Process [2]，每個系統將有一個不同的開發案例。

最后注意在互連系統構成的系統中所涉及系統之間的獨立性：

首先，查看一下從屬系統。在上級系統的設計模型中，每個從屬系統實施一個子系統。子系統依賴于彼此的接口，但相互之間不直接依賴，請參見圖 12。因此，可以用新版本替換其中的一個子系統，只要新的子系統使用同樣的接口，就不會影響其他子系統。您將在從屬系統之間得到完全相同的關系。每個從屬系統都將其周圍環境看作一個接口集。這意味著您可以更換系統，只要新系統對其他系統扮演的角色相同就可以，例如新系統可以用相同的接口集來表示。系統相互引用各自的接口，這是由上級模型中子系統和接口之間的對應關系指定的。

在從屬系統的用例模型中，與之交互的其他從屬系統的接口表示為主角�？梢哉f，從屬系統把另一個系統的接口看作是由相關主角提供的，因此永遠不必直接引用其他系統，請參見圖 16。注意在圖 12 中，有幾處地方出現了接口 B，說明接口 B 是上級系統中的子系統和相應從屬系統實際引用的同一個接口。

圖 16. 上級系統的子系統僅僅通過接口相互依賴。因此實施從屬系統就得到了同樣的獨立性。在上級系統的模型中，子系統 B 提供與其他子系統連接的接口 B。因而，相應的從屬系統 B 也需向其他從屬系統提供相同的接口 B。

那上級系統情形又如何呢？它與從屬系統有什么關系？從以下方面講，它獨立于其實施系統：每個這類的系統僅僅是上級系統模型中所指定內容的一個實施，并不屬于上級規約的一部分。出于實際原因，為了追蹤需求，您需要定義不同級別上系統之間的可追蹤性鏈接，而最“簡潔”的方法就是只在接口之間定義此類鏈接，請參見圖 11。事實上，甚至可以說從屬系統只不過是提供了上級模型中所定義接口的實施。

但是，這僅僅對簡單系統成立。接口除了說明在一個特定交互點所發生的事情之外，并未指定任何東西。一個從屬系統可能有 100 個接口，每個接口有 10 個操作。在接口說明中，把某個接口的輸入與另一個接口的一個或多個輸出相關聯是不切實際的。這就是為什么需要用例來解釋從屬系統的語義的原因。

可以得出結論，當一個系統由互連系統構成的系統實施時，所涉及的每一個系統都獨立于其他系統，但它們嚴重依賴彼此的接口。這就為您提供了一個很好的從屬系統并行開發平臺。

應用范圍

互連系統構成的系統的構架和建模技術可以用于多種系統，如：

• 分布式系統
• 很大或者很復雜的系統
• 綜合幾個業務領域的系統
• 復用其他系統的系統
• 系統的分布式開發

情況也可以反過來：從一組現有的系統，通過組裝系統來定義由互連系統構成的系統。實際上，在某些情況下，大型系統在演進的早期階段就是以這種方式發展的。你意識到你有幾個可以互連的系統，那么讓系統互連可以創建一個“大型”系統，它比兩個獨立的系統能創造更多價值。

事實上，如果一個系統的不同部分本身可以看作系統，建議把它定義為由互連系統構成的系統。即使現在它還是單個的系統，由于分布式開發、復用或者客戶只需購買它的幾個部分等原因，以后也會證明把系統分割成幾個獨立的產品是有必要的，這里僅僅舉幾個示例。

作為結束，我們來認真分析兩個可以使用由互連系統構成的系統構架的案例。在每一個示例中，我們將說明討論中的系統既要作為單個的系統考慮，又要作為分離系統的集合考慮，以此說明它應該作為通過由互連系統構成的系統實施的上級系統來對待。

大規模系統

電話網絡可能是世界上最大的由互連系統構成的系統。這是一個很好的示例，在電話網絡中需要管理兩個以上系統級別的復雜性。它還作為這類案例的示例：頂層上級系統由一個標準化實體掌握，不同的競爭公司開發一個或幾個必須符合該標準的從屬系統。這里，我們將討論移動電話網絡 GSM （全球移動電話系統），說明將大規模系統作為互連系統構成的系統來實施的優勢。

大規模系統的功能通常包含幾個業務領域。例如，GSM 標準包括了從呼叫用戶到被呼叫用戶的整個系統。換句話說，它既包括移動電話的行為，也包括網絡節點的行為。由于系統的不同部分是單獨購買的產品本身，甚至是由不同客戶購買的，因而它們本身可當作系統。例如，開發完整 GSM 系統的公司向用戶銷售移動電話，向話務員銷售網絡節點。這是把 GSM 系統的不同部分當作不同從屬系統的一個原因。另一個原因是，把 GSM 這樣大型復雜的系統作為單個系統進行開發的時間太長；不同的部分必須由幾個開發團隊并行開發。

另一方面，由于GSM 標準包括整個系統，因此有理由將系統作為一個整體即上級系統來考慮。這有助于開發人員理解問題領域，以及不同部分是怎樣彼此相關的。

分布式系統

在分布在幾個計算機系統的系統中，使用由互連系統構成的系統構架是非常合適的。顧名思義，分布式系統至少由兩個部分組成。由于分布式系統中必須有明確定義的接口，因此這些系統也非常適合進行分布式開發，也就是說，幾個獨立的開發團隊并行開發。分布式系統的從屬系統本身甚至可以當作產品來銷售。因而，將分布式系統視為獨立系統的集合是很自然的。

分布式系統的需求通常包括整個系統的功能，有時不預先定義不同部分之間的接口。而且，如果對開發者而言問題領域是陌生的，他們首先需要考慮整個系統的功能，而不管它將如何分布。這是把它當作單個系統看待的兩個重要原因。

遺留系統的復用

大型系統常常復用遺留系統。遺留系統可作為從屬系統來描述。為了理解遺留系統如何在上級系統的大環境中工作，需要為它“重建”一個用例模型，有時還有一個分析模型。這些重建的模型不必完整，但至少要包含對互連系統構成的系統的其余部分有直接影響的遺留功能，否則需要進行修改。

使用預制包

系統可以集成和定制兩個或多個預制包。企業資源規劃 (ERP) 系統就是一個典型示例。許多 ERP 系統是 MRP（材料資源規劃）、庫存管理、供應鏈管理等從屬系統的組合。其他領域也有類似組合，如人力資源和工資單應用等。它們就像預制系統一樣，為了得到一個完整的系統，必須令其專用化并與其他標準包互連。為理解包集合的作用，我們需要上級系統。這是在金融界許多客戶所面臨的情況。

總結

本文提出了一種由互連系統構成的系統構架模式。這個構架模式不但允許在一個模型內遞歸，它還把每個子系統本身作為一個系統考慮，并允許在每個系統所有的工件集之間遞歸。引入的構架用于那些由幾個相互通信的系統實施的系統。所涉及的每個系統用它自己的模型集描述，與其他系統的模型分開。

采用這種技術的優勢是顯而易見的：可以處理相當復雜的問題，并使用“分而治之”的原則來理解它們。然而，缺點就是您的開銷增大，進度無法同步。我們還考察了幾個示例，在這些示例中，組織發現上級系統很難使用迭代式生命周期，從而承擔風險被推到上級系統生命周期末尾的危險。您還要注意執行合理而有效的復用策略，以避免開發出一個“僵化”的系統集。

本文給出的示例說明了由互連系統構成的系統建模構架可用于許多應用領域。實際上，只要系統的不同部分本身可看作系統，就可以使用本文提出的構架。

參考資料

[1] - Jacobson, I.; Palmkvist, K.; and Dyrhage, S., Systems of Interconnected Systems, ROAD, 2(1), 1995.

[2] - Rational Unified Process 版本 5.1.

[3] - Rumbaugh, J.; Booch, G.; Jacobson,I., UML Reference Manual, Addison Wesley Longman, 1999.

[4] - Herbert A. Simon, The Sciences of the Artificial, MIT Press,1981.

[5] - Jacobson, I.; Bylund, S.; Jonsson, P., Using Contracts and Use Cases to Build Plugable Architectures, Journal of Object-Oriented Programming, May/June, 1995.

[6] - Jacobson, J.; Griss, M.; Jonsson, P., Software Reuse - Architecture, Process and Organization for Business Success, Addison Wesley Longman, 1997.

[7] - Jacobson, I., Use Cases in Large-Scale Systems, ROAD, 1(6), 1995.

文章來源于領測軟件測試網 http://www.kjueaiud.com/