活動圖
在 UML 中, 活動圖本質上就是流程圖. 它用於描述系統的活動, 判定點和分支等.
活動圖中的基本概念
（一）動作狀態: 原子的, 不可中斷的動作, 並在此動作完成之後向另一個動作轉變. 在 UML 中動作狀態用圓角矩形。
（二）分支與合併: 分支在軟件系統中很常見. 一般用於表示對象類所具有的條件行爲. 用一個布爾型表達式的真假來判定動作的流向. 條件行爲用分支和合並表達.在活動圖中, 分支用空心小菱形 表示. 分支包括一個入轉換和兩個帶條件的出轉換, 出轉換的條件應該是互斥的, 須保證只有一條出轉換能夠被觸發. 合併包含兩個帶條件的入轉換和一個出轉換。
（三）分叉與匯合: 分叉用來描述併發線程, 每個分叉可以有一個輸入轉換和兩個或多個輸出轉換. 每個轉換都可以是獨立的控制流. 匯合代表兩個或多個併發控制流同步發生, 當所有的控制流都達到匯合點後, 控制才能繼續往下進行. 每個匯合可以有兩個或多個輸入轉換和一個輸出轉換. 在 UML 中分叉和匯合用一條粗直線 表示
（四）泳道: 泳道將活動圖中的活動劃分爲若干組, 並將每一組指定給負責這組活動的業務組織. 泳道區分負責活動的對象, 明確地表示哪些活動是由哪些對象進行的. 每個活動指定明確地屬於一個泳道. 在活動圖中, 泳道用垂直實線繪出, 垂直線分隔的區域即爲泳道。
（一）
時序圖
時序圖用於描述對象之間的傳遞消息的時間順序, 即用例中的行爲順序.
當執行一個用例時, 時序圖中的每條消息對應了一個類操作或者引起轉換的觸發事件.
在 UML 中, 時序圖表示爲一個二維的關係圖, 其中, 縱軸是時間軸, 時間延豎線向下延伸. 橫軸代表在協作中各個獨立的對象. 當對象存在時, 生命線用一條虛線表示, 消息用從一個對象的生命線到另一個對象的生命線的箭頭表示. 箭頭以時間的順序在圖中上下排列.
時序圖中的基本概念
（一）對象: 時序圖中對象使用矩形表示, 並且對象名稱下有下劃線. 將對象置於時序圖的頂部說明在交互開始時對象就已經存在了. 如果對象的位置不在頂部, 表示對象是在交互的過程中被創建的.
（二）生命線: 生命線是一條垂直的虛線. 表示時序圖中的對象在一段生命週期內存在. 每個對象底部中心的位置都帶有生命線.
（三）消息: 兩個對象之間的單路通信. 從發送方指向接收方. 在時序圖中很少使用返回消息.
（四）激活: 時序圖可以描述對象的激活和鈍化. 激活表示該對象被佔用以完成某個任務. 鈍化指對象處於空閒狀態, 等待消息. 在 UML 中, 對象激活時將對象的生命線拓寬爲矩形來表示的. 矩形稱爲計劃條或控制期. 對象就是在激活條的頂部被激活的. 對象在完成自己的工作後被鈍化.
（五）對象的創建和銷燬: 在時序圖中, 對象的默認位置是在圖的頂部. 這說明對象在交互開始之前就已經存在了. 如果對象是在交互過程中創建的, 那麼就應該將對象放到中間部分. 如果要撤銷一個對象, 在其生命線終止點處放置 “ X” 符號.
協作圖
（一）協作圖(也叫合作圖)是一種交互圖.
（二）時序圖主要側重於對象間消息傳遞在時間上的先後關係, 而協作圖表達對象間的交互過程及對象間的關聯關係。
狀態圖
（二）狀態圖: 通過建立對象的生存週期模型來描述對象隨時間變化的動態行爲.
（三）狀態: 用圓角矩形表示. 狀態名稱表示狀態的名字, 通常用字符串表示. 一個狀態的名稱在狀態圖所在的上下文中應該是唯一的.
（四）轉換: 用帶箭頭的直線表示. 一端連着源狀態, 一端連着目標狀態.
（五）初始狀態: 每個狀態圖都有一個初始狀態. 此狀態代表狀態圖的起始位置. 初始狀態只能作爲轉換的源, 不能作爲轉換的目標, 並且在狀態圖中只能有一個. 初始狀態用一個實心圓表示.
終止狀態: 模型元素的最後狀態, 是一個狀態圖的終止點. 終止狀態在一個狀態圖中可以有多個.
對象圖簡介
對象圖是類圖的一個實例, 用於顯示系統執行時的一個可能的快照. 即在某一個時間上系統可能出現的樣子. 對象圖用帶下劃線的對象名稱來表示對象.
包圖簡介
（一）包圖: 由包和包之間的關係組成. 包的圖標就如同一個帶標籤的文件夾.
（二）包提供了一種用於組織各種元素的分組機制. 在 UML 中, 包用來對元素進行分組, 併爲這些元素提供命名空間. 包所擁有的或者引用的所有元素稱爲包的內容, 包沒有實例.
組件圖簡介
（一）組件圖用來建立系統中各組件之間的關係, 各組件通過功能組織在一起.
（二）Javabean, ejb, jsp 都是組件。在UML中，組件使用在左側有兩個小矩形的大矩形來表示。
（三）組件圖可以用來設計系統的整體構架。
部署圖簡介
（一）部署圖用來幫助開發者瞭解軟件中的各個組件駐留在什麼硬件位置, 以及這些硬件之間的交互關係。
（二）節點: 用來表示一種硬件, 可以是打印機, 計算機等.節點的標記符號是一個三維框，在框的左上方包含了節點的名稱。
（三）通信關聯: 節點通過通信關聯建立彼此的關係，採用從節點到節點繪製實線來表示關聯。
軟件的生命週期概述
（一）軟件生命週期: 軟件的產生直到報廢的生命週期
（二）軟件生命週期內有問題定義, 可行性分析, 總體描述, 系統設計,編碼, 調試和測試, 驗收與運行, 維護升級到廢棄等階段
（三）隨着新的面向對象的設計方法和技術的成熟, 軟件生命週期設計方法的指導意義正在逐步減少.
軟件的生命週期分解
軟件工程可以分爲三個大的階段:需求; 設計; 測試與維護
1. 需求:
問題的定義
可行性分析
需求分析
2. 設計:
概要設計
詳細設計
編碼與單元測試 (集成測試)
3. 測試與維護
綜合測試
維護
軟件的生命週期詳解
1、問題的定義及規劃(和軟件開發計劃): 此階段是軟件開發方與需求方共同討
論，主要確定軟件的開發目標及其可行性。
2、需求分析(需求分析說明書和初步的用戶手冊): 在確定軟件開發可行的情況下，對軟件需要
實現的各個功能進行詳細分析。需求分析階段是一個很重要的階段，這一階段做得好，將爲
整個軟件開發項目的成功打下良好的基礎。
3、軟件設計(概要設計、詳細設計): 此階段主要根據需求分析的結果，對整個軟件系統進行設
計，如系統框架設計，數據庫設計等等。軟件設計一般分爲總體設計和詳細設計。
4、程序編碼(提交源程序及清單): 此階段是將軟件設計的結果轉換成計算機可運行的程序代碼。
在程序編碼中必須要制定統一，符合標準的編寫規範。以保證程序的可讀性，易維護性，提
高程序的運行效率。
5、軟件測試(提交軟件維護測試報告): 在軟件設計完成後要經過嚴密的測試，以發現軟件在整
個設計過程中存在的問題並加以糾正。整個測試過程分單元測試（白盒）、集成測試（黑
盒，功能測試、強度性能測試）以及系統測試三個階段進行。測試的方法主要有白盒測試和
黑盒測試兩種。在的隨意性。測試過程中需要建立詳細的測試計劃並嚴格按照測試計劃進行測試，以減
少測試
6、運行維護（提交軟件維護報告): 軟件維護是軟件生命週期中持續時間最長的階段。在軟件
開發完成並投入使後，由於多方面的原因，軟件不能繼續適應用戶的要求。要延續軟件的使
用壽命，就必須對軟件進行維護。軟件的維護包括糾錯性維護和改進性維護兩個方面。
軟件的生命週期 ---- 瀑布模型
瀑布模型是傳統的軟件生存週期模式
軟件的生命週期 ---- RUP
統一軟件開發過程(Rational Unified Process,RUP): 一個通用的軟件流程框架, 以架構爲中心, 用例驅動的迭代化開發流程. RUP 是從幾千個軟件項目的實踐經驗中總結出來的, 對於實際的項目具有很強的指導意義.
RUP 用二維座標來描述. 橫軸通過時間來組織, 是過程展開的生命週期特徵, 體現開發過程的動態結構; 縱軸以內容來組織, 體現開發過程的靜態結構.
RUP 中軟件生命週期的四個階段
初始階段: “獲得項目的基礎”. 該階段的主要人員是項目經理和系統設計師. 所要完成的主要任務包括對系統的可行性分析; 創建基本的需求; 識別系統的關鍵任務.
細化: 主要目標是創建可執行構件基線; 精化風險評估; 捕捉大部分的系統功能需求用例; 爲構造階段創建詳細需求. 該階段並不是要創建可執行的系統, 而是展現用戶所期望的需求.
構建: 完成所有的需求, 分析和設計. 該階段的製品將演化成最終系統
交付: 將完整的系統部署到用戶所處的環境中.
RUP 中的核心工作流
RUP中有9個核心工作流. 分爲6個核心過程工作流(Core Process Workflows) 和 3個核心支持工作流 (Core Supporting Workflows). 儘管6個核心過程工作流類似於傳統瀑布模型中的幾個階段, 但迭代過程中的階段是完全不同的, 這些工作流在整個生命週期中一次又一次被訪問. 9個核心工作流在項目中輪流被使用, 在每一次迭代中以不同的重點和強度重複.
（一）RUP 中的核心工作流(1)
商業建模: 理解目標客戶的商業結構及商業運作. 爲目標系統描述一個構想.
需求分析:描述系統應該做什麼, 並使開發人員和用戶就這一描述達成共識.
分析和設計
實現
測試
部署
（二）RUP 中的核心工作流(2)
配置和變更管理: 對重複工作, 無效的改變進行控制和監視, 以避免由此產生的混亂.跟蹤軟件創建過程中的版本.
項目管理: 平衡各種可能產生衝突, 管理風險, 克服各種約束併成功交付使用戶滿意的產品
環境: 軟件開發環境.
