UML語言與軟體架構設計（持續更新中）
1.前言
本文是以《軟體架構設計》和《大象Think in UML》兩本書的內容為基礎進行講述，以個人的理解做了提煉和總結，旨在能夠通過本文對UML語言以及其在系統設計中的應用有一個概括性的瞭解。
2.《軟體架構設計》
圖 架構設計過程的節奏
圖 架構設計的6個步驟
需求分析
確定關鍵需求
概念架構設計
2.1需求分析
願景分析：願景=業務目標+範圍+Feature+上下文圖。
需求分析
用例圖
用例簡述（使用者故事）
用例規約
用例實現（魯棒圖）
2.2.領域建模
領域模型：類圖、狀態圖
領域模型在軟體開發中的作用
2.3.確定關鍵需求
關鍵質量
關鍵功能：核心功能、必做功能、高風險功能、獨特功能。
2.4.概念架構設計
關鍵需求進、概念架構出。
左手功能：魯棒圖。
右手質量：目標-場景-決策表。
要領1：功能需求與質量需求並重。
要領2：1個決定、4個選擇。
2.5.細化架構設計
5個檢視、15個任務
邏輯架構=模組劃分+介面定義+領域建模。
開發架構=技術選型+檔案劃分+編譯關係。
物理架構=硬體分佈+軟體部署+方案優化。
執行架構=技術選型+控制流劃分+同步關係。
資料架構=技術選型+儲存格式+資料分佈。
3.《大象Think in UML》
3.1概念
UML（Unified Modeling Language）統一建模語言
RUP（Rational Unified Process）統一過程
3.2UML核心元素
版型：是對一個UML元素基礎定義的擴充套件，UML幾乎每一個元素都有很多版型，例如：用例有業務用例、業務用例實現、系統用例等版型；類有介面、邊界類、實體類、控制類等。在建模的不同階段，問了區分檢視之間的不同點，會採用不同的圖示來表示。
參與者：參與者是在建模過程中處於核心地位的。
參與者位於邊界之外。
參與者可以非人。
業務主角和業務工人的區別。
參與者與涉眾的關係
參與者與使用者的關係
參與者與角色的關係
用例：用例是一種把現實世界捕獲下來的方法，用例定義了一組用例例項，其中每一個例項都是系統所執行的一系列操作，這些操作生成特定主角可以觀測的值。
用例是相對獨立的。
用例執行結果對參與者來說是可以觀測和有意義的。
這件事必須由一個參與者發起，不存在沒有參與者的用例，用例不應該自動啟動，也不應該主動啟動另一個用例。
用例必須是以動賓短語形式出現的。
業務用例、業務用例實現、概念用例、系統用例、用例實現
邊界：
邊界決定視界
邊界決定抽象層次
業務實體：業務實體是一種版型，在業務建模階段建立領域模型。
包：
領域包、子系統、組織結構、層
分析類：分析類用於獲取系統中主要的“職責簇”。它們代表系統的原型類，是系統必須處理的主要抽象概念的第一個關口。
分析類代表系統的主要“職責簇”，意味著分析類是從功能性需求向計算機實現轉換的第一個關口。
分析類可以產生系統的設計類和子系統，意味著計算機實現是可以通過某種途徑產生出來的。
邊界類
控制類
類：屬性、方法、可見性
關係：關係是重要的語義，它抽象出物件之間的聯絡，讓物件構成某個特定的結構。
關聯 
它描述不同類的物件之間的結構關係，它在一段時間內將多個類的例項連線在一起。A物件知道B物件的存在。
依賴 
它表示一個物件的修改會導致另一個物件的修改的關係。A物件儲存了B物件的ID，如果A沒有使用B，則是關聯關係，如果A使用了B物件，則是依賴關係。
擴充套件
它特別用於用例模型中說明向基本用例中的某個擴充套件點插入擴充套件用例。一般來說，擴充套件用例是帶有抽象性質的，它表示用例場景中的某一個支流，由特定的擴充套件點觸發而被啟動。用例是可選的。
包含它特別用於用例模型，說明在執行基本用例的例項的用例例項過程中插入行為端。用例是必須的而不是可選的。
實現
A實現B，在用例模型中連線用例與用例實現，說明基本用例的一種實現方式。
精化
A精化了B，一個基本用例可以分解出許多更小的關鍵精化用例，這些精化用例更細緻地展示了基本用例的核心業務。
泛化
A繼承自B，說明兩個物件之間的繼承關係。
聚合
聚合關係用於類圖，特別用於表示實體物件之間的關係，表達整體由部分構成的語義。與組合不同的是，聚合不是強依賴的，即使整體不存在了，部分仍然存在。
組合
組合關係用於類圖，特別用於表示實體物件關係，表達整體擁有部分的含義，組合關係是一種強依賴的特殊聚合關係，如果整體不存在了，則部分也消亡了。
元件
3.3UML核心檢視
3.3.1靜態圖
3.3.1.1用例圖
用例圖採用參與者和用例作為基本元素，以不同的視角展現系統的功能性需求。用例檢視是瞭解檢視的第一個關口，人們通過用例檢視得知一個系統將會做什麼。對客戶來說，用例檢視是客戶業務領域的邏輯化表達，對建設單位來說，用例檢視是系統藍圖的開發依據。
1. 業務用例檢視：業務用例檢視使用業務主角和業務用例展現業務建模的結果。大多數情況下，業務用例檢視要從業務主角和業務模組兩個視角進行展示。
2. 業務用例實現檢視：業務用例實現檢視展現業務用例有哪些實現途徑。業務用例是業務需求，而業務用例實現則是業務的實現途徑，從軟體工程的角度說，這個檢視展示了需求的可追溯的特點。
3. 概念用例檢視：用於展示業務用例中分析出來的關鍵概念用例，並表示概念用例和業務用例之間的關係，一般來說這些關係有擴充套件、包含、精化。對於概念用例來說，一般以業務用例為單元來展現的，即將試圖名稱命名為業務用例名稱，如果某幾個業務用例關係緊密也可以放在一個視圖裡展示。概念用例不是必須的，如果業務用例關係複雜，繪製概念用例有助於細化和更準確地理解業務用例。
3. 系統用例檢視：系統用例檢視展現系統範圍，將對業務用例分析以後得到的系統用例展現出來。系統用例就是系統給的開發範圍。
4. 系統用例實現檢視：如果一個系統用例有多種實現方式，也應當為期繪製實現檢視。雖然繁瑣，還是建議為即使只有一種實現方式的系統用例也繪製實現檢視。
3.3.1.2 類圖
類圖用於展示類及其相互之間的關係。
UML解決面向物件困難的方法源於面向物件的方法中對類理解的三個層次觀點,這三個層次是概念層、說明層和實現層。類圖建模是先建概念層而說明層，再建實現層的過程。
- 概念層類圖：這個層次的類描述的是現實世界中問題領域的概念理解，類圖中表達的類與現實世界的問題領域存在著明顯的對應關係，類之間的關係也與問題領域中實際事物的關係有著明顯的對應關係。概念層中的類和類之間的關係與最終的實現類並不一定有直接和明顯的對應關係。類圖著重對問題領域的概念理解，而不是實現，因此類名稱通常問題領域的實際事物的名稱。
- 說明層類圖：這個層次的類圖考察類的介面而不是實現，類圖中表達的類和類關係應當時對問題領域在介面層次抽象的描述。說明層檢視是搭建在現實世界和最終實現之間的一座橋樑。在這個階段，類通常都很粗略。
- 實現層類圖：類是實現程式碼的描述，類圖中的類直接對映到可執行的程式碼。實現層類圖位於設計階段。在這個階段，類圖可以視為虛擬碼。
3.3.1.3 包圖
包圖一般用來展示高層次的觀點。包具有多種版型，通過包這個容器從大到小、從粗到細地建立關係是一種很好的辦法。
3.3.2 動態圖
動態檢視不能獨立存在，它必須特指一個靜態檢視或UML元素。
3.3.2.1 活動圖
活動圖描述了為了完成某一目標需要做的活動以及這些活動的執行順序。UML中有兩個層面的活動圖，一種用於描述用例場景，另一種用於描述物件互動。
在面向物件的眼中是沒有業務流程這種東西的，所謂流程只不過是在某個外部力量推動下物件之間相互交流的一個過程，它只是瞬時的。
活動圖在描述用例場景時仍然是十分有效的工具，關鍵還是建模者自己要避免被過程化的觀點所困擾，而不必忌諱使用活動圖。
- 用例活動圖：用例表達了參與者的一個目標，用例場景則描述瞭如何達到這個目標。活動圖用來描述用例場景，也就是通常所說的業務流程。業務流程一般包括一個基本業務流程和一個或多個備選業務流程，而業務流程則通過多個活動按照一定的條件和執行順序來推進，活動圖可以是手動執行的，也可以是自動執行的任務，每個活動完成一個工作單元。活動圖有幾個關鍵元素：起始點、活動、判斷、同步、結束點、基本流、支流、異常流、組合活動。
- 物件活動圖：物件活動圖用於展示物件的活動。
- 泳道：泳道技術的引入解決了活動圖不能描述物件職責的遺憾，一個物件只能在一個業務流程中擔任一個（或一類）職責，泳道代表了一個特定的類、人、部門、層次等物件職責區。
- 業務場景建模：以業務主角（客戶代表）為泳道，以從業務主角處獲取的業務用例作為活動來編排活動圖，這種活動圖對我們獲取正確的業務用例和檢查已經獲得的業務用例有著很好的幫助。它能夠：幫助發現業務用例、幫助檢查業務用例粒度、幫助檢查業務主角、幫助檢查業務用例。
- 用例場景建模：在獲取了業務用例之後，我們的到了參與者和業務目標，我們通過用例場景來說明如何達到業務目標。我們以業務主角和業務工人為泳道，以工作單元作為活動來編排活動圖來描述用例場景。這種檢視對我們獲取概念用例、角色和業務物件（業務實體）有著很好的幫助。它能夠：幫助發現概念用例、幫助發現角色、幫助發現業務實體、幫助建立領域模型。
狀態圖
狀態圖顯示一個狀態機，狀態機用於對模型元素的動態行為進行建模，更具體地說就是對系統行為中受時間驅動的方面進行建模。通常使用狀態圖來說明業務角色或業務實體可能的狀態—導致狀態轉換的事件和狀態轉換引起的操作。狀態圖中的關鍵元素包括：初始狀態、狀態、複合狀態、轉移、事件、條件、最終狀態。
- 時序圖
用於描述按時間順序排列的物件之間的互動模式，時序圖在概念層、說明層、實現層的檢視分別是：業務模型時序圖、概念模型時序圖、設計模型時序圖。
- 業務模型時序圖：業務模型時序圖用於為領域模型中的業務實體互動建模，其目標是實現業務用例。在時序圖中常用的UML元素有：物件、生命週期線、訊息、會話、銷燬。繪製業務模型時序圖時要注意：第一，時序圖以達成業務目標為準則；第二，這個階段處於業務階段，使用的描述語言應當採用業務術語；第三，時序圖表達的內容會對將來的分析設計帶來幫助，但是對於編碼實現來講由於太粗略而不能夠作為依據。
- 概念模型時序圖：概念階段的時序圖採用分析類來繪製，目標同樣是實現業務用例。但是，由於分析類本身代表系統原型，所以這個階段的時序圖已經帶有計算機理解。
- 設計模型時序圖：設計模型時序圖採用設計類來繪製，目標是實現概念模型中的某個事件流，一般以一個完整互動為單位訊息細緻到方法級別。建議在設計模型階段，只需要用框架中的關鍵類描述典型的互動場景即可，不需要為每一個互動都繪製時序圖。
3.3.2.4 協作圖
協作圖描述了物件之間的一種互動模式，它通過物件之間的連線和它們相互發送的訊息來顯示參與互動的物件。協作圖中可以有物件和主角例項，以及描述它們之間關係和互動的連線和訊息。可以為用例事件流中的每一個變化繪製一個協作圖。
協作圖用於顯示物件之間如何進行互動以執行特定用例或用例中特定部分的行為，協作圖的建模結果用於獲取物件的職責與介面。協作圖因為展示了物件之間的關係，使得它更適合獲取對物件結構的理解，而時序圖則更適合於獲得對於呼叫過程的理解。
針對概念層、說明層、設計層分別對業務實體物件、分析類物件和設計類物件繪製協作圖，分別得到業務模型協作圖、概念模型協作圖和設計模型協作圖。
- 業務模型協作圖：採用業務實體來繪製，目標是實現用例場景。
- 概念模型協作圖：採用分析類進行繪製，目標是實現業務用例。
- 設計模型協作圖：採用設計類進行繪製，目標是實現概念模型中的某個事件流。
3.4 UML核心模型
3.4.1 用例模型
用例模型是系統既定功能或系統環境的模型，它可以作為客戶和開發人員之間的契約。用例是貫穿整個系統開發的一條主線。用例模型即為需求工作流程的結果，可當作分析設計工作流程以及測試工作流程的輸入使用。
統一過程是一種演進式的軟體過程，在整個產品生命週期之內充滿了許多小規模的迭代，而每個迭代的開始幾乎都是從識別用例開始，從用例被實現而結束。
用例模型有業務用例模型、概念用例模型和系統用例模型。
業務用例模型用於識別和規定業務需求，概念模型用來分析和確定業務需求，而系統用例模型用來規定系統開發需求。這三者之間是一種精化的關係。
3.4.1.1 業務用例模型
業務用例模型位於統一過程的先啟階段，在業務建模核心工作流中完成。業務模型目的是為現存的或客戶預想中的真實業務建立模型，是我們為了理解客戶的業務，並與客戶達成業務理解上的共識而建立的模型，它不需要考慮計算機環境。
- 業務模型的主要內容包括：
- 業務用例檢視：業務用例檢視包括業務主角和業務用例，它是業務的高層和概要檢視，並作為其他建模要素的組織存在。
- 業務用例場景
- 業務用例規約
- 業務規則
- 業務物件模型
- 業務用例實現檢視
- 業務用例實現場景
- 包圖
3.4.1.2 概念用例模型
概念用例模型位於先啟階段，有時在精化階段進行，是業務用例建模的一個子集。業務用例是粗略的，我們需要一種方法來分解那些較大的業務用例，從中找到關鍵和核心的工作單元，針對這些工作單元建立模型來簡化業務。
- 概念用例模型的主要內容：
- 概念用例檢視
- 概念用例分析
- 分析類檢視
- 分析場景
3.4.1.2 系統用例模型
系統用例模型位於統一過程的先啟階段的末期以及精化階段的早期。
- 業務用例模型的主要內容：
- 業務用例
- 概念檢視
- 用例檢視
- 用例規約
- 補充規約
- 業務規則
- 用例實現
- 用例場景
- 分析物件
3.4.2 領域模型
領域模型是採用業務物件建立起來的一種模型，我們把領域模型當中使用到的業務物件成為領域類，一般來說，領域類有三種形式：
業務物件實體，表示業務中使用到或產生的東西，如訂單、賬號、合同等。
系統需要處理的現實世界的物件和概念，如商品、買家、買家。
將要發生和已經發生的事件，如購買、撤單、付費等。
領域模型建立的目的是檢視挖掘這一系列物件之間互動關係的本質。領域模型的研究高於特定業務場景的一般規律。可以說，領域模型是從所有業務場景物件互動模型當中抽象出來的更高級別的業務物件模型；它表示了業務物件結構和互動的一般規律，揭示了業務執行的本質和核心。要求建模者有深厚的行業知識背景，或者具備高度的抽象能力，並且遍歷了絕大部分的業務用例場景。
領域模型可以幫助我們理解問題領域的關鍵概念和關鍵物件，幫助我們理解這些物件如何工作，以及如何解決問題。
- 領域模型的主要內容：
3.4.3 分析模型
分析類用於獲取系統中的主要“職責簇”。它們代表系統的原型類，是系統必須處理的主要抽象概念的第一個關口。分析模型使用分析類來建立系統原型，獲得系統實現需求的第一手方案。
3.4.4 軟體架構和框架
- 軟體架構：架構需要描述兩個方面，這兩個方面分別針對業務領域的理解和系統領域的理解，我們稱之為業務架構和系統架構，這兩者是需要和諧統一的。
- 業務架構：業務架構在先啟階段建立，在精化階段得以改進。
- 軟體架構：軟體架構需要在業務架構的基礎上引入計算機環境，計算機環境包括硬體環境和軟體環境。
- 架構描述：架構描述通過架構文件記錄，至少需要描述以下方面：業務架構概述、組織結構、業務模組、業務物件模型、典型用例場景、軟體架構概要、計算環境、軟體層次、實現架構、協議和介面、軟體框架、典型用例場景的架構實現、非功能性需求。
- 軟體框架：軟體框架是針對一個普遍問題的最佳實踐或解決方案，它通常是一個半成品，提供基本類庫、程式設計模型和程式設計規範，甚至包括IDE工具。
3.4.5 設計模型
設計模型是一個描述用例實現的物件模型，它可作為對實施模型及其原始碼的抽象。設計模型用作實施和測試活動的基本輸入。
從分析模型對映到設計模型：分析類代表設計元素的例項所承擔的角色；這些角色可以由一個或多個設計模型元素來實現。此外，單個設計元素可以實現多個角色。
一個分析類可以成為設計模型中的單個類。
一個分析類可以成為設計模型中的某各類的一部分。
一個分析類可以成為設計模型中的一個聚合關係類。
一個分析類可以成為設計模型中從同一個類繼承而來的一組類。
一個分析類可以成為設計模型中一組功能相關的類。
一個分析類可以成為設計模型中一個包。
一個分析類可以成為設計模型中一項關係。
分析類之間的一項關係可以成為設計模型中的一個類。
分析類主要處理功能性需求以及來自“問題”領域的模型物件；設計類則處理非功能性需求以及來自“解決方案”領域的模型物件。
分析類可用來代表“我們希望系統支援的物件”，而不用決定用硬體支援分析類的多大部分，用軟體支援分析類的多大部分。
3.4.6元件模型
元件總是用來容納分析類和設計類的，從這個角度說，元件可以理解為一種特殊的包，只不過普通的包起到組織和容納的作用，而元件的組織行為卻有著特別的目標：這些分析類或設計類被組織起來完成一組特定的功能。
元件的四個特性：完備性、獨立性、邏輯性和透明性。如何組織程式碼來保證這些特性呢？答案是架構。元件總是與架構密不可分的，如果沒有架構就談不上元件。生產元件的目的是為了像積木一樣構建一個應用系統，為了能夠搭建它們並且保證它們的互動，元件必須符合某個架構的規範要求。
定義元件是為了這樣的一些目的：
- 這些元件將成為可複用的單位。
- 每個元件都有一組特定的功能。
- 這些元件將成為可獨立部署的單位。
- 這些元件將遵循架構規範。
何時使用元件：
應當根據實際情況決定是否需要元件，以下場合可以選擇不使用元件，其他情況需要建立：
- 如果你所實施的專案不是一個分散式的系統，通常沒有必要為元件建模。
- 如果你所實施的專案不需要想第三方提供支援服務，通常不需要元件建模。
- 如果你所實施的專案中沒有將某部分業務功能單獨抽取出來形成一個可複用的單元，在許多系統或子系統中使用的要求，通常不需要元件建模。
- 如果你所實施的專案沒有與客戶其他現存的系統或第三方系統整合的要求，通常沒有必要為元件建模。
- 如果系統沒有采用架構開發，通常不需要元件建模。
廣義的元件的用法：
- 描述應用系統中各個邏輯模組之間的關係，此時含義是模組。
- 描述應用系統中各個子系統之間的關係，此時的含義是子系統。
- 描述應用系統中各個可執行部分之間的關係，此時的含義是可執行程式。
- 描述應用系統中各個程式包之間的關係，此時的含義是包。
3.4.7實施模型
實施模型由配置節點和元件組成。其中配置節點使用節點元素繪製，它用來描述系統硬體的物理拓撲結構；元件使用元件元素繪製，它用來表示在配置圖中描述的結構上執行的軟體。
何時使用實施模型：
- 分散式系統，為了描述各種資源在不同節點上的分佈情況。
- 系統需要與來自多方的程式、模組等互動，為了描述這些程式的分佈情況。
- 系統具有多個硬體，為了描述可執行程式在不同硬體裝置上的分佈情況。
3.5統一過程核心工作流程
軟體過程明確了軟體的生命週期，明確了軟體生命週期過程中的成果物和可交付物，同時也就明確了需要什麼樣的模型。
3.5.1業務建模工作
業務建模位於統一過程的先啟階段，它主要使用到的模型包括業務用例模型、概念用例模型和領域模型。
業務建模的工作流程如下：
業務建模的活動集如下：
業務建模的工件集如下：
| 角色 |
活動集 |
工件集 |
| 業務流程分析員 |
評估目標組織 設定和調整目標 獲取常用業務詞彙 查詢業務主角和用例 制定業務規則 定義業務架構 |
業務詞彙表 業務規則 目標組織評估 業務前景 業務用例模型 業務物件模型 業務架構文件 補充業務用例規約 |
| 業務設計員 |
詳細說明業務用例 詳細說明業務角色 查詢業務角色和實體 詳細說明業務實體 定義自動化需求 |
業務用例 組織單元 參與者 業務實體 業務用例實現 業務角色 |
| 業務模型複審員 |
複審業務用例模型 複審業務物件模型 |
|
業務建模的目標：
瞭解目標組織的結構和機制。
瞭解目標組織中當前存在的問題並確定改進的可能性。
確保客戶、終端使用者和開發人員就目標組織達成共識。
匯出支援目標組織所需的系統需求。
業務建模的作用在於：
業務模型是需求工作流程的一種重要的輸入，用來了解對系統的需求。
業務實體是分析設計工作流程的一種輸入，用來確定設計模型中的實體類。
3.5.2系統建模工作
工作流程：
系統建模工作主要位於先啟階段和精化階段，先啟階段側重於“分析問題”和“理解涉眾需要”，而精化階段則側重於“定義系統”和“改進系統定義”。“管理系統規模”和“管理需求變更”的活動貫穿專案始終。
系統建模的首要問題是要了解我們利用該系統檢視解決的問題的定義和範圍。
活動集和工件集
| 角色 |
活動集 |
工件集 |
| 系統分析員 |
制定需求管理計劃 確定前景 獲取涉眾請求 獲取常用詞彙 查詢主角和用例 管理依賴關係 建立用例模型 |
需求管理計劃 前景 涉眾請求 詞彙表 補充規約 需求屬性 用例規約 |
| 架構設計員 |
確定用例的優先順序 |
|
| 用例闡述者 |
詳細說明用例 詳細說明軟體需求 |
用例 用例包 軟體需求規約 |
| 使用者介面設計員 |
使用者介面建模 設計使用者介面原型 |
主角（人員） 邊界類 使用者介面原型 用例示意板 |
| 需求複審員 |
複審需求 |
|
系統建模的目標
與客戶和其他涉眾在系統的工作內容方面達成一致並儲存。
是系統開發人員能夠更清楚地瞭解系統需求。
定義系統邊界（限定）。
為計劃迭代的技術內容提供基礎。
定義系統的使用者介面，重點是使用者的需要和目標。
系統建模工作流程與其他工作流程的關係為：
業務建模工作流程為系統建模工作流程提供了業務規則、業務用例模型和業務物件模型，包括領域模型和系統的組織環境。
分析設計工作流程從系統建模工作流程中獲取主要輸入。在分析設計中可以發現用例模型的缺陷；隨後將生成變更請求，並應用到用例模型中。
測試工作流程對系統建模工作流程確定的系統進行測試，以便驗證程式碼是否與用例模型一致。
3.5.3分析設計工作
分析設計建模即我們所熟知的概要設計和詳細設計過程。它主要使用分析模型和設計模型來完成分析設計過程。它主要在精化階段實施。
工作流程
定義備選架構
改進被選架構
分析行為
設計非實時元件
設計實施元件
分析設計活動集
分析設計工件集
分析設計的目標:
- 將需求裝換為未來的設計。
- 逐步開發健壯的系統構架。
- 使設計適合於實施環境。
分析設計與其他工作流程的關係為：
- 業務建模工作流程為系統提供組織環境。
- 需求工作流程為分析設計提供輸入。
- 測試工作流程測試在分析設計過程中所設計的系統。
推薦的分析設計工作流程：
分析過程概要
設計過程概要
3.5.4實施建模工作
工作流程
活動集
工件集
推薦的實施建模工作流程
3.5實踐
準備工作
瞭解問題領域
涉眾分析
規劃業務範圍
客戶訪談
獲取需求
定義邊界
發現主角
發現業務用例：用例圖
業務建模：活動圖（泳道）、時序圖、協作圖、用例規約、業務物件模型、業務用例實現檢視、業務用例實現場景、包圖
領域建模：分析類圖、時序圖、協作圖
提煉業務規則：全域性規劃、互動規則、內稟規則
獲取非功能性需求
主要成果物
需求分析
關鍵概念分析：概念用例、概念模型
業務架構
系統原型
系統分析
系統用例
分析業務規則：全域性規則、互動規則、內稟規則
用例實現：系統用例、系統用例實現、系統用例實現場景。
軟體架構和框架
分析模型：分析類、時序圖
元件模型
部署模型
系統設計
設計模型：設計類、設計模型、設計類實現（時序圖）
介面設計
包設計