UML 簡介

系統開發生命週期

• 計畫
• 分析
• 設計
• 實作
• 測試

系統開發方法論

結構化的方法論

結構化方法指的是，在執行過程中，是以資料(data)或者處理(process)為中心。 也就是將焦點放在如何將一個大問題分解成較小的範圍來處理； 如果在執行時，該範圍的邏輯還是過於複雜，就將其再拆解成更小的範圍來處理。 同樣的，面對資料方面，也是採用相同的態度去處理。

結構化的方法論可以歸納出以下幾種開發方式：

瀑布式 (waterfall methodology)

雛型式 (prototype methodology)

螺旋式 (spiral methodology)

物件導向的方法論

物件導向方法論強調的是：

• 物件和物件之間的靜態關係。
• 物件與物件是如何互動的動態關係。
• 利用物件將資料和處理封裝起來。

所以，物件導向方法論在分析、設計、實作各個階段，都是以物件當做主要思維方向。 由於物件導向方法論剛開始被大量採用時，不同的開發人員會使用各自的表示法或符號來產出文件，這些文件沒有統一的標準，以致於不同的團隊在溝通上常常造成困難。

為了讓開發過程中，所有的開發人員可以有一個統一的標準，1944-1995 年間，IBM Rational 開發團隊就請來了 Grady Booch, Jim Rumbaugh, Ivar Jacobson 三位物件導向方法論的大師， 共同發展出一套以物件導向為主的統一塑模語言（Unified Modeling Language, UML）。 透過 UML主 這個語言工具，讓所有進行系統分析設計的工程師，可以有一個共同的圖形化語言，來描述他們所想要建立的系統。

後來這三位大師也將研究重點轉向系統的開發流程，並於 1998 年提出一套物件導向系統關發的方法論，讓整個開發過程也有一套標準，而這樣子的一個軟體開發流程就稱為「 Rational 統一流程（RUP）」（Rational Unified Process）。

RUP 簡介

RUP（Rational Unified Process）本身是一種軟體工程流程（Software Engineering Process）。 它提供研發單位一個嚴謹的方法，分配軟體開發工作和責任；目的是確保在可預期的時程和預算內，開發出符合使用者需求的高品質軟體。

這套軟體開發流程包含三大特點、四個階段和九個核心流程。

RUP的三大特點

使用案例驅動（Use-Case Driven）

「使用案例」是以一種使用者角度來描述問題的圖形，可以用來捕捉客戶真的的需求所在。 RUP 透過「使用案例」來做為系統關發的初始，目的就是希望能夠以使用者的角度來透視客戶的需求，避免系統開發完成後，才發覺到功能無法滿足需求。

以架構為中心（Architecture Centric）

每一個系統都會有一個架構，但是這個架構是否完整，不是單單用幾張圖表就可以描述清楚。 RUP 採用所謂的「4+1觀點」，透過不同的觀點來看一個系統，每個觀點都有它特定想表達的項目，用以描繪出整個系統的所有需求。

所謂 4+1 觀點，指的是：

• 使用案例觀點（Use Case View）：
  使用案例觀點是橫跨四個觀點之上的重要觀點， 之所以稱為 4+1 觀點 ，而不是 5 個觀點，就說明了 UML 軟體架構中的所有設計，都是以使用者觀點的角度出發。 在使用者案例觀點中，我們會透過 Use-Case Diagram 了解使用者的需求，進而幫助開發人員界定系統需求的範圍。
• 邏輯觀點（Logical View）：
  此觀點旨在根據使用者需求，訂出系統初步的功能結構。 這個觀點常會使用 Class DIagram 來表示物件類別間的靜態關係（關聯性），以及 Sequence Diagram 或 Collaboration Diagram 來表示物件類別間的動態關係（互動性）。
• 實作觀點（Implementation View）：
  以模組或元件來顯示邏輯觀點中物件是在哪一個模組或元件中實作。 這個觀點常會使用 Component Diagram 來描述物件之間的依附關係。
• 處理流程觀點（Process View）：
  此觀點主要從系統整合的角度看系統的效能、與容錯能力應該怎樣規劃。 特別在分散式架構系統中，工作流程間的溝通或訊息的交換都非常複雜，這時候工作流程觀點的說明就變得更加的重要。 這個觀點常會使用 Activity Diagram 來描述流程間互動的關係。
• 部署觀點（Deployment View）：
  此觀點強調實際系統的分布、交付及安裝部分。 這個觀點常會使用 Component Diagram 與 Deployment Diagram 來表示工作元或執行緒對應主機與裝置的實際情形。

表：UML圖形的使用時機

	靜態模型	動態模型
使用案例觀點	使用案例圖	互動圖、狀態圖、活動圖
邏輯觀點	類別圖、物件圖	互動圖、狀態圖、活動圖
處理流程觀點	類別圖、物件圖	互動圖、狀態圖、活動圖
實作觀點	元件圖	互動圖、狀態圖、活動圖
部署觀點	部署圖	互動圖、狀態圖、活動圖

反覆漸進式開發（Develop Iteratively）

不管系統的大小如何，要一次就將整個系統的模型完整定義出來是非常不容易的。 RUP將整個開發過程分成多個處理流程（workflow），每個流程都必須經過多個階段（phase），每個階段都可以透過雛型來檢驗結果，同時每個階段的結果也將做為下個階段的輸入。

簡單講就是將專案分成多個週期，循序反覆的進行著RUP的四個階段以及九個處理流程。 隨著時間的遞增，每一個階段所著重的處理流程比重也會不同。 例如，在計畫[初始階段]，需求分析的份量會比實作來的多；而在[建構階段]，實作將變成整個計畫的核心工作。

RUP的四個階段

起始階段（Inception phase）

進行可行性研究，定義出專案大小及涵蓋範圍，評估專案所需的能力、時程與經費， 以及資訊系統預期達到之效益、了解商業模型及需求。

詳述階段（Elaboration phase）

擬定專案計畫、系統架構、進行系統分析與設計。

建構階段（Construction phase）

建構產品並進行單元測試、整合測試。

移轉階段（ Transition phase）

將產品分批交付給客戶進行驗收測試，並進行使用者訓練。

RUP的九個核心流程

企業塑模（Business Modeling）

需求（Requirements）

分析與設計（Analysis & Design）

實作（Implementation）

測試（Test）

部署（Deployment)

成功將產品釋出給使用者。

配置和變更管理（Configuration & Change Management）

有關產品系統化之配置管理；文件及模型必須有版本控制等。

專案管理（Project Management）

規劃專案時程。

環境（Environment）

提供系統開發之環境及工具以支援開發團隊。

UML 簡介

統一模型語言（Unified Modeling Language, UML）是一種視覺化的模型工具，它使用圖形化標記（Notations）來描述問題，讓團隊中的人員可以更加容易的了解需求。 這個工具可以讓專案經理將客戶需求轉成易於瞭解的使用案例， 協助系統分析師依需求建立系統所需要的活動， 而且對開發人員而言，透過 UML 一致化的溝通方式，可以將抽象的系統變的較為具體，讓程式的實作與管理變的較為容易。

例如，下面這個案例圖，簡單且明確的描述出一個線上訂購系統，該系統允許讀者進行線上訂購書籍的操作，另外允許店家將書籍資料上架到線上訂書系統。

你也可以使用活動圖，來進一步描述讀者訂購書籍的步驟。

UML定義了九種模型圖：

1. 案例圖（Use Case Diagram）
2. 活動圖（Activity Diagram）
3. 循序圖（Sequence Diagram）
4. 合作圖（Collaboration Diagram）
5. 狀態圖（State Machine Diagram）
6. 類別圖（Class Diagram）
7. 物件圖（Object Diagram）
8. 元件圖（Component Diagram）
9. 部署圖（Deployment Diagram）

一般來說，在進行需求訪談與分析之後，會先使用「使用案例圖」定義出系統所需要的功能，以及實作的範圍。 接下來，針對各個功能，使用「活動圖」與「順序圖」來描述該功能的執行流程。 有了明確的系統流程，再使用「元件圖」勾勒出較高階的系統架構， 最後才使用「類別圖」定義系統必須要實作出來的類別。