稱必須與 collaboration diagram 對應的 class 名稱一致；(2)跨階段 UML 圖形間的 追溯性所產生的關聯性，如 design class 與 analysis class 之間的關聯性，因此 USDP 流程中的 UML 圖形產物間一致性檢查的策略可制定如下： 查下個階段所產生的對應 collaboration diagram，及用 checklist 的方式，
讓使用者標註本階段產物與上個階段產物內元素的對應關係以達到產
物間追溯性的目的，如圖 4-1 所示。
圖 4-1 USDP 各階段主要產物之追溯關係
依據此策略，本系統所設計的功能機制可分為下列三類：
1. 流程進行輔助機制：在使用者進行設計而畫 UML 圖形時，適時提供已 有元素供使用者選用，以避免錯誤的發生，如提供使用者 responsibility 的清單，讓使用者從中挑選合適的 responsibility。
2. 同階段性 UML 圖形一致性檢查機制：當使用者完成某一個流程階段或 完成一個圖形繪製，系統自動檢查此流程產生的產物與其他已產生的產 物間是否有不一致的情形，例如使用者畫完一個 use case 中的
collaboration diagram 時，檢查該圖中的 class 是否在已有的 analysis class 清單中。
3. 階段產物的完整性檢查：當使用者完全完成 analysis 或 design 整個階段 時，系統所進行的整體檢查，確定使用者確實完成這個階段所必須產生 的產物，產物若不齊全就不允許使用者進入下一個流程，例如幫助使用 者在 analysis 階段完成時檢查是否每個 use case 裡的 scenario 都已經有 建立相對應的 collaboration diagram。
4.2 需求階段(Requirement Capturing)
Requirement capturing 階段是 USDP 軟體開發工作流程中的第一個階段，本 階段使用者必須以 use case diagram 來表示系統所定義的 use cases 與 actors，同 時註明各個 use case 的 specification。在 requirement capturing 階段系統提供了使
用者建立 use-case model，並依照上一章提到的標記方法標記各 scenario 裡的關 鍵名詞，這些關鍵名詞將輔助使用者進行 analysis 階段的流程。
Requirement capturing 階段的流程共分為五個項目，分別是 find actors and use cases、prioritize use cases、detail a use case、prototype user interface 與 structure the use-case model，各流程詳細的輔助功能茲列述如下：
1. Find actors and use cases
系統提供使用者藉由繪製 use case diagram 來表示其所定義的 actor 與 use cases，使用者在 use diagram 中加入並同時定義 use case 與 actor 的名稱，
以及 use case 與 actor 間的關係。繪製 use case diagram 的功能是由 ArgoUML 所提供。
2. Prioritize use cases
給予每個 use case 一個優先度欄位，使用者於本流程可設定各 use case 的優先度，系統會以優先度排序各個 use case，同時提醒使用者要在開發流 程的前期先進行具有高優先度 use case 的開發。
3. Detail a use case
本流程中使用者將註明各個 use case 的 specification，上一章已說明了 specification 裡的欄位，包含了 use case 的各種相關資訊如 use case name、
precondition、flow of event、postcondition 等，其中 flow of event 記載的是 use case 內各種可能發生的 scenario。本研究提出以表格的方式描述 use case 內的 scenario，故系統中將提供使用者 scenario 表格以書寫其中的動作，同 時提供使用者標記 scenario 裡的關鍵名詞。
4. Prototype User Interface
使用者於本流程中可為系統的介面建立雛型，因使用者介面並不會對下 一個階段的產物產生追溯性的影響，故本系統並沒有在這個流程中提供特別 的輔助功能。
5. Structure the use-case model
本流程中使用者必須為各個 use case 建立其間的關係，依據 UML 語言 的規範，use case 間具有 generalization、extend、與 include 三種關係，系統 提供使用者在 use case diagram 中以拖曳的方式建立 use case 間的關係。
4.3 分析階段(Analysis)
Analysis 階段有四個核心活動，分別是 architectural analysis、analyze a use case、analyze a class 與 analyze a package，各核心活動之輔助功能分述如下：
1. Architectural Analysis
U1.1 定義系統中的analysis package、service package，與建立analysis package間的依存關係U
系統在這個流程中提供使用者建立 packages 的工具，要求使用者為每 個 package 命名及建立 packages 間的 dependency 關係，若 package 間有巢狀 (nested)的關係，則要求使用者在 package 的性質內註明該 package 所屬的 parent package 及包含的 child package。
U1.2 定義obvious entity classU
使用者應定義對於該系統架構有重要影響的 entity class，系統會提供使 用者在 use case scenario 中標記的關鍵名詞及其出現次數，供使用者選擇產 生這類型的 entity class。
U1.3 定義Common special requirementU
使用者應定義一些共通的 special requirement，系統將會產生文字表格供 使用者填寫。
2. Analyze a Use Case
U2.1 定義analysis classesU
使用者定義一個 use case scenario 之 analysis class 的名稱時會參考此 use
candidate。系統將提供 scenario 上的關鍵名詞讓使用者選擇當作 entity class name，若該名詞已被定義為 entity class name，也將自動標明，當 scenario 內的名詞被用來當 entity class 名稱，將特別標記。
因為 boundary class 的名稱一般不會出現在 scenario 裡，因此無法提供 boundary class 名稱的協助，但能提供此 scenario 中共有幾次的 I/O 動作予使 用者參考。而 control class 是使用者依系統要執行的動作之複雜度而決定是 否由 control class 來負責，並由使用者依工作性質來命名，因此無法協助 control class 的命名。
U2.2 描述analysis object間的interactionU
使用者需建立 collaboration diagram 來描述該 scenario 內的 analysis class 如何互動。
系統將提供使用者已定義的 analysis class 供使用者選擇，scenario 敘述 句中名詞若為 analysis class 的名稱，將作標記以提醒使用者。當使用者加入 boundary class 時，將提供使用者在 scenario 上出現的 actor 名稱供使用者建 立 actor 與該 boundary class 之關係，並提供 I/O 相關的 scenario 敘述句供使 用者建立 link 及制定 boundary class 之 responsibility。
當使用者加入由 control class 或 boundary class 與 entity class 間的 link 時，系統將提供 scenario 有該 entity class 的敘述句供使用者建立 entity class 之 responsibility 之用。當 boundary class 或 control class 與另一 control class 間建立 link 時，則提供其他 scenario 中仍未被使用到的敘述句供使用者建立 該 control class 之 responsibility 之用。
當使用者繪製完一個 scenario 的 collaboration diagram 時，系統會提供 以下的檢查：
(1) 檢查 scenario 中是否有尚未被加入 collaboration diagram 內的 responsibility，若有則提醒使用者。
(2) 檢查 collaboration diagram 中 responsibility 的數量是否與 scenario
中列在 system column 內的 responsibility 數量相同，若不相同則代 表有尚未被加入圖形中的 responsibility，必須提醒使用者。
(3) 檢查 scenario 中是否有已定義的 analysis class 沒有出現在 collaboration diagram 中，若有則提醒使用者。
U2.3 Capturing special requirement
定義此 use case 的 nonfunctional requirement 供 design 或是 implement 階 段之用，系統將會產生文字表格來讓使用者填入這些資訊。
3. Analyze a Class
U3.1 定義analysis classes所負責的responsibilityU
列出該 analysis class 在上一階段各個 use-case realization 所代表的 collaboration diagram 中的 responsibilities 讓使用者檢閱。這部分是系統自動 完成的，直接對應到各個 scenario 的 collaboration diagram。
U3.2 定義analysis class的attributes
Scenario 中經過標示的名詞有些已經被指定為 entity class 的名稱，而剩 下未被指定的名詞將當作 analysis class 的 attribute 或是 attribute type，而 entity class 的 attribute 可從 comment 欄位中的關鍵名詞取得，這些資訊將自動產 生以供使用者選用。
U3.3 定義analysis class之間的associations與aggregationsU
將 collaboration diagram 中與該 analysis class 有 link 相連的 analysis class 列出供使用者參考建立 association 與 aggregation 之關係。
U3.4 定義analysis class之間的generalizationsU
系統將列出所有 analysis class 裡有相同的 attribute 或 responsibility 者給 使用者參考，供使用者建立 analysis class 間 generation 的關係。
U3.5 Capturing special requirement
implement 階段處理之用。系統將會產生文字表格來讓使用者填入這些資 訊。
4. Analyze a Package
此階段的工作是將所有已定義的 analysis class 分配到適當 package 中，
系統將會提供下列輔助：
(1) 列出所有的 analysis class 與該 analysis class 所參與的 collaboration diagram 及 scenario 名稱。
(2) 當 analysis class 被配置進某一 package 中時，系統提供與該 analysis class 有 link 的 analysis class 及出現的 collaboration diagram 名稱，
供使用者選擇分配 package 之參考，這些相互間有 link 的 analysis class 會有相當大的機會被分配到同一個 package。
(3) 當全部的 analysis class 都配置進 package 後，系統自動列出每個 package 間的 analysis class 跨 package 呼叫的次數，以提醒使用者 將次數高的 analysis class 重新分配所屬的 package。
在完成上述四個 analysis 階段的核心活動後，系統會進行整體檢查以保證能 無誤的進入下一個階段，本階段的整體一致性檢查包括：
(1) 系統若在各 use case scenario 中發現有未被使用到的關鍵名詞，則必須 告知使用者檢查是否有未定義的 attribute 或 attribute type。
(2) 系統若發現在 collaboration diagram 中有 link 相連的 analysis class 但相 互間卻沒有 relationships 的關係相連，則提醒使用者有未定義的關係。
(3) 系統會檢查是否每個在 collaboration diagram 中互相有溝通的 analysis class 其所屬的 package 之間是否也有關係存在。
4.4 設計階段(Design)
Design 階段的核心工作包括 architectural design、design a use case、design a class 與 design a subsystem，各核心工作之輔助功能分述如下：
1. Architectural Design
U1.1 定義系統的node與network
ArgoUML 已有提供使用者建立 deployment diagram 之功能，包括每個 node 的名稱以及 node 間的溝通方式(如 internet、intranet 等)。
U1.2 定義系統的subsystems以及interface並配置deployment diagram 系統將對每一個 analysis package 詢問使用者該 package 的執行將由哪些 node 來完成，每一個 node 傳遞需配置一個 subsystem。
此外使用者也將定義每一個將利用 middleware 與 system-software 的 subsystems，若有必要，將定義一(組)design class 或一 subsystem 當作呼叫的 介面，以保障應用系統的獨立性，而後定義各個 subsystem 之間的依存關係 (dependency)，系統將提供各 analysis package 間的關係給使用者參考，有關 係的 package 其所對應到的 subsystem 間也必須至少存在一組 dependency，
並提醒使用者要定義該 subsystem 的 interface。
U1.3 定義architecturally significant design classU
這個階段應定義對於系統架構有重要影響的 design class，系統會提供使 用者分析階段所定義之 architecturally significant analysis class 供使用者選 用。
U1.4 Identifying Generic Design Mechanism
此階段需靠使用者自行設計，系統不提供輔助的機制。
2. Design a Use Case
U2.1 參考analysis class定義參與use case的design classU
系統將列出該 scenario 已定義的 analysis class 當作建立 primary design
class，並要求使用者一一檢查 class 的性質，對於每一 entity class 則詢問是 否有必要建立其 container class，或其 attribute type 是否有必要建立 design class 以代表之，若有則建立相關的 design class，並定義其屬同一個 class group。
對於 middleware 或 system-software 的 subsystem，系統也一一詢問是否 要新增 design class 來當做呼叫介面，若必要則提供介面供其建立。
對於 boundary class 來說，boundary class 有三種產生輔助性 design class 的原因。系統會針對每個 boundary class 一一詢問使用者是否有必要分割
對於 boundary class 來說，boundary class 有三種產生輔助性 design class 的原因。系統會針對每個 boundary class 一一詢問使用者是否有必要分割