中 華 大 學 碩 士 論 文
題目：物件導向設計之版本變更差異分析研究
A Study on Version Difference Analysis for Object-Oriented System Design
系 所 別：資訊工程學系碩士班 學號姓名： 8802506 林雅鈞 指導教授： 王 素 華 博 士
中華民國 九十 年 七 月
摘要
軟體組態管理對於專案的成功與否，扮演著舉足輕重的角色。現 有的軟體組態管理工具中，提供的功能如：檔案比對、報告、檔案合 併、衝突分析以及分散式、跨區域性的平行發展模式… 等，多數是使 用於軟體生命週期中的程式開發階段。開發人員利用軟體組態管理工 具所提供的版本控制功能，對於稽核追蹤所撰寫的程式，都能清楚的 了解其各版本間程式碼變更的差異情形，但應用於其他原始碼的控制 上，如利用 Rational Rose 所繪製的物件導向流程圖，則是將流程圖以 轉換成編碼的方式儲存記錄，若僅僅也只是比較其中版本內容的差 異，就無法進一步為設計師與專案經理提供更有意義的資訊。
物件導向技術近年來被廣泛的應用於軟體開發過程，然而在設計 發展的過程中，卻無法有效的控管開發過程中檔案的變更情形。本研 究的主要範圍是應用於軟體發展生命週期中的系統分析設計階段，利 用物件導向系統分析及設計的技術與統一模式語言，整合現有的軟體 組態管理工具─Microsoft Visual SourceSafe 與現有的理論，實作 一個應用於系統分析設計階段的版本變更差異分析系統。
在本系統中，將經由比對、轉換差異報告為我們所定義的轉換規 則，並對於所繪製的流程圖，進行設計檔案的版本變更差異分析，以 提供給系統設計師與專案經理更進一步的資訊。最後利用一個現有專 案，將分析設計階段所繪製的設計檔案版本應用於系統上，並將實際 的結果加以介紹。
關鍵字：軟體組態管理 (Software Configuration Management, SCM)、
統一模式語言 (Unified Modeling Language, UML)、版本控 制 (Version Control)
Abstract
Software configuration management (SCM) is the key to the success of software development. Current SCM tools provide functions such as comparing files, preparing difference reports, combining file, analyzing conflict, and supporting development models. Must of the tools are applied to the programming phase of the software development life cycle.
For version control, these tools only provide difference reports among different versions of files. No further analyses of the reports are provided to the designers and project leaders.
Object-oriented technology has been widely applied in software development recently years. However, the versions of designs usually cannot be effectively managed during the process. This research focuses on the effective difference analysis of design version during the design phase of software development. A framework for providing design version information is proposed. By integrating the object-oriented design tool, UML, and the SCM tool, Microsoft Visual SourceSafe, we also implemented a system named Version Change Difference Analysis System.
The system performs analysis of different versions of design flowcharts, and then provides useful information to the designers and the project leaders. A real project will be used to test the system. The results will also be evaluated.
目 錄
第一章 緒論… … … ...1
1.1 研究動機… … … ..… … … .… … … 1
1.2 研究目的… … … ..… … … .… … … 2
1.3 研究範圍… … … ..… … … .… … … 3
1.4 論文架構… … … ..… … … .… … … 4
第二章 文獻探討 … … … ...5
2.1 組態管理… … … ..… … … .… … … 5
2.2 軟體組態管理… … … ..… … … .… 6
2.3 軟體組態管理模型… … … ..… … … .7
2.4 軟體組態管理工具… … … ...… … … ..… … … 12
第三章 版本變更差異分析系統架構… … … .16
3.1 變更差異分析功能… … … .… … … .16
3.1.1 物件導向設計與 UML… … … ..… … … .… … 17
3.1.2 相關發展工具… … … ..… … … ..… … … 18
3.2 系統架構… … … ..… … … ....… … … … 23
3.2.1 模式符號產生器 (Model Notation Generator) … … … 26
3.2.2 軟體組態差異分析器架構… … … ..… … … ..… … 28
3.2.2.1 符號轉換規則 (Notation Transformation Rules) … … .30
3.2.2.2 差異分析引擎 (Difference Analyzer Engine) … … … ..30
3.2.2.3 差異分析介面 (Difference Analyzer Interface) … … ...35
3.2.3 Visual SourceSafe 使用模式… … ..… … ..… … … 35
第四章 系統實作與介紹 … ..… … … ..… … … .… … 37
4.1 開發環境… ..… … … ..… … … ..37
4.2 系統功能架構… ..… … … ..… … … ..38
4.3 詳細系統說明… ..… … … ..… … … ..39
第五章 實例說明 … ..… … … ..… … … .… … 44
5.1 專案版本管理… ..… … … ..… … … ..44
5.2 物件導向系統分析設計過程… ..… … … ..… … … ..45
5.3 前後版本差異分析實例… ..… … … ..… … … ..… … … 46
5.4 專案整合分析實例… ..… … … ..… … … ..53
第六章 結論… ..… … … ..… … … .… … … … 57
6.1 系統特色… ..… … … ..… … … ..57
6.2 未來研究方向… ..… … … ..… … … ..… … 58
6.3 結論… ..… … … ..… … … ..59
參考文獻 … ..… … … ..… … … ...60
圖目錄
圖 2-1 Checkout/Checkin 模型… … … 8
圖 2-2 Composition 模型… … … .… … … 9
圖 2-3 Long Transaction模型… .… … … ...10
圖 2-4 Change Set 模型… … … .10
圖 3-1 Visual SourceSafe 提供版本差異報告… … … ..19
圖 3-2 類別圖… … … 21
圖 3-3 使用案例圖… … … 21
圖 3-4 循序圖… … … 22
圖 3-5 版本變更差異分析系統整合架構圖… … … 24
圖 3-6 系統執行流程圖… … … 25
圖 3-7 軟體組態差異分析器架構圖… … … 29
圖 3-8 版本差異分析報告產生流程圖… … … 33
圖 3-9 專案整合報告產生流程圖… … … 34
圖 3-10 Visual SourceSafe 使用流程圖… … … 36
圖 4-1 系統功能架構… … … 38
圖 4-2 系統起始登入畫面… … … 39
圖 4-3 系統【個別版本管理】畫面… … … 40
圖 4-4 非檔案設計者錯誤畫面 … … … ...41
圖 4-5 系統【專案整合分析】區畫面… … … 42
圖 5-1 Visual SourceSafe 的使用… … … .… … … 44
圖 5-2 Rational Rose 的使用… … … 45
圖 5-3 類別圖修改後… … … 46
圖 5-4 Visual SourceSafe 所提供之版本差異報告… … … .47
圖 5-5 類別圖版本差異分析報告… … … 48
圖 5-6 使用案例圖修改前… … … 49
圖 5-7 使用案例圖修改後… … … 49
圖 5-8 使用案例圖版本差異分析報告… … … 50
圖 5-9 循序圖修改前… … … 51
圖 5-10 循序圖修改後… … … ..51
圖 5-11 循序圖版本差異分析報告 … … … 52
圖 5-12 專案架構圖… … … ..53
圖 5-13 整合類別圖畫面… … … ..54
圖 5-14 整合使用案例圖畫面… … … ..55
圖 5-15 整合循序圖畫面… … … ..… … … 56
表目錄
表 2-1 軟體組態管理工具的比較… … … 14 表 3-1 UML 符號項目… … … 27
第一章 緒論
多數軟體發展的生命週期中，隨著軟體元件的發展，除了必須要 處理單一元件不斷成長的版本數目之外，還可能要利用不同的元件，
以不同的方式再建造為完整的系統，這樣的一個任務不但繁複而且瑣 碎，亦需要依賴大量的人工管理作業以保持其正確性，因此組態管理 (Configuration Management) 與版本控制 (Version Control) 在軟體發 展中扮演著既特殊且重要的角色[Ambr90]。
1.1 研究動機
組態管理原先是運用於管理硬體的技術上，以 組織和控制系統的 發展。而軟體組態管理 (Software Configuration Management, SCM) 出現於組態管理之後，關心於平行發展環境下一個系統的組態識別、
組織、控制和變更，對於專案的成功與否，扮演著舉足輕重的角色。
平行發展在今日軟體發展中是一項實際的需要，許多現有的軟體 組態管理工具都提供了分散式的平行發展模式，以控制開發團隊中多 位開發者之間的工作與交互影響，讓多位開發者能同時有效的設計、
撰寫程式、測試以及改進軟體程式碼功能。但由於軟體在發展上有容 易改變、容易複製並且複雜… 等等的特性，因此當組態管理實際應用 於軟體發展上也有著相當的困難。
許多軟體組態管理工具在版本控制的功能上，都僅僅只是比較某 檔案中前後版本的內容，提供給使用者兩版本間比對程式碼差異的報 告，並沒有對其中的程式碼差異做深入的分析。本論文將針對此問題 提出一套系統，期望為系統設計師在進行檔案設計與版本控制的過程 中，提供更為有意義的訊息。
1.2 研究目的
現有的軟體組態管理工具，提供的功能如：檔案比對、報告、檔 案合併、衝突分析以及分散式、跨區域性的平行發展模式… 等。以往 大部分軟體組態管理工具多使用於軟體生命週期中的程式開發階 段，開發人員利用軟體組態管理工具所提供的功能，對於稽核追蹤自 己所撰寫的程式，都能清楚的了解其各版本間程式碼變更的差異情 形。但應用於軟體發展的其他生命週期，如：系統分析設計階段，面 對必須處理的是所繪製的流程圖設計檔案時，則無法進一步為設計師 提供有效的資訊。
隨著現有軟體的輔助，系統分析設計過程利用 Rational Rose 所繪 製的物件導向流程圖，是將流程圖以轉換成編碼的方式儲存記錄，對 於像這樣產生的設計檔案，配合使用軟體組態管理的工具，雖然可以 方便系統設計師進行版本控制，但是在進行版本控管上，卻也只見其 提供一大串連續編碼的差異報告。若僅僅只靠提供比對編碼變更差異
的這樣一份報告，對於系統設計師來說並不能為其帶來任何較有意義 的訊息，也無法更進一步的為專案經理提供整合性的資訊。
本研究的主要目的在於整合使用現有的軟體組態管理工具，應用 於並非由開發人員所撰寫，而是經由相關工具所自動產生編碼的設計 檔案控管。因此，除了將著重於軟體發展過程中的系統分析設計階 段，透過現有的一套軟體組態管理工具的使用，對於 Rational Rose 所繪製的流程圖進行版本的控管，並延續發展一個變更差異的整合分 析系統，期望為專案經理及系統設計師提供更具有意義的分析報告。
1.3 研究範圍
本研究的主要範圍是應用於軟體發展生命週期中的系統分析設 計階段，利用物件導向系統分析及設計的技術與統一模式語言 (Unified Modeling Language, UML)，繪製軟體專案發展過程中所分 析設計的流程圖，並運用現有的軟體組態管理工具─Microsoft Visual SourceSafe 進行流程圖設計檔案的版本控管。另外，對於物件導向分 析設計的流程圖，本研究主要選擇其中三種最為常用的流程圖以做為 版本變更的分析管理，包括：使用案例圖 (Use Case Diagram)、類別 圖 (Class Diagram)、和循序圖 (Sequence Diagram)。在未來發展中，
若有收集更多的模式符號，也可對於其他類型的流程圖進行相同的版
1.4 論文架構
本論文除了第一章緒論外，在第二章中將針對於軟體組態管理在 文獻上的基礎理論與模型做整理及介紹，並且進一步的比較現有的軟 體組態管理工具。
第三章中將應用文獻理論、模型與相關工具的研究，提出一個應 用於系統分析設計階段的版本變更差異分析系統架構，並針對其中的 元件逐一做說明。
第四章則根據本研究所提出的系統架構為基礎，實作一個版本變 更差異分析系統，再分別對於系統的開發環境、系統功能架構、以及 系統內容做詳細的說明。
在第五章中我們將利用一個現有的專案，並將分析設計階段所繪 製的設計檔案版本應用於本系統上，最後將實際的結果加以介紹。
第六章則說明系統開發的特色，並對於後續的研究提出未來方向 與結論。
第二章 文獻探討
軟體組態管理是一個控制發展複雜軟體系統的學科，在整個軟體 發展生命週期中扮演著極為重要的角色。軟體組態管理除了必須管理 在專案生命週期中有所變更的元件外，也必須要同時符合設計師與管 理者的需要。本章將大略介紹 (軟體) 組態管理、組態管理模型，並 且概括論述現有軟體組態管理的工具。
2.1 組態管理
通常在發展一個龐大與複雜的系統時，需要一再的說明，這是因 為系統本身元件版本數目不斷的成長之外，並且可能需要用少數不同 的方法設計系統。因此支援系統組態管理工具的兩個主要目標是：節 省花費在說明系統的時間、介紹明確的限制以提高系統的可控制性。
組態管理原先應用於硬體管理上，組織和控制發展系統，確定和 定義系統中項目 (Items) 的程序。在整個生命週期中都必須控制這些 項目的改變，記錄、並報告狀況和控制變更要求，並且保證這些項目 的完整性和正確性[Bers80]。
2.2 軟體組態管理
軟體組態管理是一個協調軟體開發過程之管理工作，藉使軟體開 發過程中所產生的混亂程度降到最低。建立軟體組態管理，可以加強 軟體開發的進行，並且執行版本的控制以減少軟體維護成本和錯誤的 發生，進而提高軟體產品之品質。
IEEE 提供了一般標準的軟體組態管理的定義[IEEE87]包括：
??組態識別與追蹤：在所有開發階段中對每一軟體元件及其狀 態做標識。
??變更管制：針對軟體元件的變更做識別、記錄、審查與授權。
在其接受變更之前，其必需針對其他項目之影響加以鑑定。
??狀態報告：對於軟體元件之狀態、變更要求及核准實行做記 錄，並產出管理報告。
??審計與複查：確認軟體元件完整性，以及所有的元件在整個 生命週期是保持一致，並且處於適當狀態，且定義明確。
不同的組態管理的使用者 (管理者、程式開發者、使用客戶)，
由於在組織中扮演的角色不同，因此傾向於不同的組態管理的功能，
所以這些定義是不足夠的，之後再擴大定義[Dart91]增加包括：
??建構管理：管理建構與建構產品以最理想的方法。
??過程管理：保證組織程序、政策和生命週期模式的完成。
??團隊工作：控制工作與多開發者之間的交互影響。
一個現代的軟體組態管理提供許多的利益，包括：提供完整的軟 體開發和維護過程，更容易的達成測試和品質保證，從產品發行管理 中除去有錯誤傾向的步驟，提供相關元件的追蹤，組態管理過程程序 的自動化，和更容易的變更管理與問題追蹤。
軟體組態管理主要的工作是管理軟體產品或是系統設計過程，也 是專案設計師與其他開發者的溝通橋樑，缺乏這樣的控制，常常會導 致同時間修改衝突或是共享程式碼問題與版本混亂且錯誤的情形。
2.3 軟體組態管理模型
在組態管理越來越受到注意的同時，商業系統中也提供了許多新 的組態管理功能，以這些功能為基礎的模型也隨之被提出。目前許多 商業軟體發展的環境中都具有支援組態管理的功能，其中包含四個不 同的組態管理模型，除了一般較為熟悉的 Checkout /Checkin 模型外，
還包括 Composition 模型、Long Transaction 模型及 Change Set 模型，
Checkout/Checkin 模型
組態管理系統通常由兩個相當獨立的工具所組成：一個儲存庫工 具、一個建構工具。儲存庫工具儲存檔案版本並提供創造新版本的控 制機制。而建構工具則是對於組成產品元件的描述。
Checkout/Checkin 模型主要的概念為支援個別檔案的版本，以維 護檔案的版本歷史，並且控制同時發生的修改。檔案多版本通常儲存 在儲存庫中，使用者必須從儲存庫中 Checkout 取得一個檔案的版本，
經過修改後再 Checkin 回儲存庫中，產生一個新的版本，對於其中的 元件透過鎖定與合併更可以做到控制同時發生的修改。
圖 2-1 Checkout/Checkin 模型 [Feil91]
Composition 模型
Composition 模型延伸軟體組態管理由元件階層至系統階層，延 續發展於 Checkout/Checkin 之後。Composition 模型是由系統模型和 版本選擇規則所共同組成，一個系統模型建造去提供列出所有系統組 成與架構的元件資訊，版本選擇規則應用於系統模型去選擇所需求的 系統版本。
圖 2-2 Composition 模型 [Feil91]
Long Transaction 模型
Long Transaction 模型主要介紹工作區 (workspace) 的概念，開 發者分隔於各處，Transaction 模型提供較佳支援於團隊環境同時發生 的修改。在這模型中開發者最先選擇系統的架構，元件版本則由所選 擇的架構決定。
Long Transaction 由兩個概念組成：一個工作區，和一個同時控 制的計畫。工作區允許組態管理系統不只管理儲存庫，而且支援開發 者在他們的工作區域中變更系統。而同時控制的計畫則是協調同時變 更的一項方針。
圖 2-3 Long Transaction 模型 [Feil91]
Change Set 模型
Change Set 模型集中焦點在於變更而非版本，在這個模型中，變 更集合是兩個檔案版本中的一個差異，應用於架構上，變更集合就是 在兩個架構版本中的差異，也就是兩個架構版本中差異的集合。變更 的繁殖是藉由版本的合併，當一個特別的版本合併後，則漸增的變更 將不斷的繁殖。
圖 2-4 Change Set 模型 [Feil91]
不同模型比較
這四個模型各有不同的管理重點，分別強調：Checkout/Checkin 模型提供個別系統元件的版本管理，Composition 模型以著重透過選 擇版本改善系統組態架構，Long Transaction 模型強調系統發展是一 連續組態版本，並且要協調同時發生的活動，最後 Change Set 模型則 以提升組態管理發展為著重變更。
目前的組態管理工具或是其他發展工具上，可以發現於組態管理 的功能中，都提供有一個或是兩個以上的模型。而近年來也有許多學 者應用現有組態管理模型的觀念再進行研究，如：
Crnkovic 提出變更管理過程：變更要求 (Change Request, CR) 來 自於發展計畫，鑑定發展的項目，和錯誤報告。一個變更要求通過發 展過程的不同狀態，當 CR 被創造出於最初階段，由發展者進行更新，
之後經過實驗、執行測試階段，最後到達終止階段，CR 結合成為一 個產品發行於發行階段[Crnk98]。
之後 Crnkovic, Funk, Larsson 三人更進一步提出一個模型，讓需 求在嚴格的組態管理的控制之下。利用組態管理的特色，特別是變更 管理，去達成較佳的控制和察覺需求，並以再利用或是鑑定問題的方 法簡化需求追蹤[Crnk99]。
而 COMFORM 是一個提供指導方針和程序[Capr92]，在維護過 程中完成種種活動執行的方法，所提議的方法能提供於軟體組態管理 應用時一個變更控制架構，目標是用於控制現存軟體系統同時新增加 的文件。COMFORM 的發展是以軟體組態管理為中心，發展一套程 序和管理系統的標準，本質上著重變更：如何控制變更、如何管理軟 體系統受支配的變更、如何發行變更的軟體系統給使用者。
Checkout/Checkin 模型為組態管理發展最主要的基礎，其他的三 個模型都是以其為基準，改進組態管理的功能。在本研究中也將應用 Checkout/Checkin 模型的觀念管理版本的使用，以 Change Set 模型控 制變更的狀況，讓版本變更更進一步的受到管理，並且加強對於團隊 環境下發生的修改控制。
2.4 軟體組態管理工具
軟體組態管理工具，在企業發展中廣泛的獲得接受與使用，但是 在過去許多企業發展出他們自己的軟體組態管理工具，不但要投入許 多的人力，不一致和錯誤的情形也不斷發生。在 1950 年初期，這些 工具在使用上就既不友善而且粗劣。
在軟體發展的過程中，必然牽涉到大量的檔案 (程式語言撰寫出 的程式碼、網頁 HTML)，而軟體組態管理是一個對於保護程式碼來
說非常重要的工具。今日的軟體組態管理工具，已變得較龐大也較完 善，即使是一個個人開發者，版本控制系統可以幫助追蹤和記錄變 更，也可以自由的創造變更或是回復到先前的版本。
美商瑞理大中國區總經理陳致平就指出[興德科技 99]，「組態管 理就好像軟體開發的基礎架構一樣，從系統分析設計一直到程式撰寫 和測試，最直接面對的就是各開發階段版本控管的問題，若是版本搞 錯了，所有的開發工作都將前功盡棄。」軟體組態管理工具提供符合 每個人的需要，從針對個人發展者的簡單版本控制系統，到大型團隊 開發者的系統管理的作業，是今日管理和控制高度複雜軟體產品發展 的關鍵。
軟體組態管理發展至今，有許多的軟體組態管理工具利用於商業 上。然而過份強調於程式碼版本的控制，卻忽略了軟體組態管理其他 如：組態識別與追蹤、狀態報告和審計複查… 等相同重要的功能 [Chan97]。目前市面上組態管理工具種類繁多，表 2-1 將針對現有的 商業組態管理工具，進行分析比較：
其中 Microsoft Visual SourceSafe 是微軟所提供的一套組態管理 工具，它能保護工作團隊中最寶貴的資產，並在複雜的發展和編輯環 境中，協助工作更有效率。Visual SourceSafe 不但提供安全的版本控 制，也提供了使用簡易、專案導向的版本控制系統。Visual SourceSafe 讓使用者安全的儲存 Web 內容、程式原始碼與企業文件，使用者介 面的外觀與功能類似 Windows Explorer，方便使用者學習與使用。
Visual SourceSafe 也可以協調檔案變更，並利用 Check Out 檔案鎖定、
Visual Merge 與 Difference Reporting 等功能，避免不小心覆寫程式 碼，並可讓使用者輕易的重新建立先前的版本。
在本論文研究的實作系統中，將選用微軟 Visual SourceSafe 這套 組態管理工具作為發展基礎，利用工具本身現有的功能，擴大發展一 個版本變更分析系統，以提供給專案經理以及系統設計師更為有意義 的資訊。
在本章中，概略的介紹軟體組態管理的相關理論與模型，並對於 現有的軟體組態管理工具做比較。下一章將根據現有的軟體組態管理 工具的缺點，進一步提出一個版本變更差異分析系統架構，並分析說 明其中所包含的元件。
第三章 版本變更差異分析系統架構
軟體組態管理在軟體工程的過程中是不可或缺，有效的版本管理 更可以幫助專案開發人員對於專案進行控管。在本研究中將著重於軟 體專案開發中，物件導向設計分析設計圖檔案的版本控制分析，以整 合軟體組態管理概念與現有的工具，提出一個軟體組態差異分析器架 構，並將對於其中的元件做詳細的說明。
3.1 變更差異分析功能
許多的軟體組態管理工具提供版本控制的功能，但是對於不同版 本的控管上，只是將不同版本間的程式碼差異列舉出來。面對常常是 動輒數千行甚至數萬行的程式碼，如果僅僅只是提供不同版本間的程 式碼差異，對於非開發者本身撰寫的程式碼來說，除了並不能夠立即 為使用者提供有效益且有意義的訊息外，可能還需要花費更多的時間 來判讀其中程式碼的內容。
本研究將應用於系統分析設計階段，利用提供完整 UML 模式語 言的 Rational Rose 為分析設計工具，並整合現有的軟體組態管理工 具，配合發展一個版本變更差異分析系統，期望對於分析設計階段所 繪製的流程圖進行版本的控管，並提供給開發人員更有意義的資訊。
3.1.1 物件導向設計與 UML
軟體生命週期是由數個主要的階段所組成，包含：系統分析、設 計、撰寫程式和維護… 等，應用組態管理於軟體產品發展的各個生命 週期中都是非常重要的[Do99]。其中系統分析設計階段主要是在正確 的了解系統使用者對於系統軟體方面的需求，不正確或是不完整的分 析，經常會導致整個專案的失敗。而系統分析師在這階段的工作，除 了必須了解問題、評估與分析、製作規則書並接著複查與審核外，包 括利用模式語言將設計表達出來，通常牽涉到許多的圖形，因此在管 理這些流程圖檔案將是一個重要的工作，本研究中我們將範圍定義於 系統分析設計階段，對於分析師所設計流程圖進行版本控制與管理。
物件導向分析是一種系統分析與設計方法，它使用類似人類思考 模式的方法去描述以及分析系統，物件導向的技術在近年來被廣泛的 應用於軟體發展的各個階段，對於軟體的分析與設計上，以物件導向 為基礎的模式與方法先後被提出與應用，其中則以近年來的 UML 最 廣為重視。
物件導向系統分析工具能協助人們建立企業系統及資訊系統 的模式。自從 1993 年以來，在 Booch、Rumbaugh 和 Jacobson 三 位專家的合作下，提出 UML 模式語言，供系統開發人員對於整個 系統生命週期的管理，表達其分析與設計的構思，更於 1997 年成
UML 模式語言是物件導向軟體模式語言，根據物件導向的概 念，這種模式語言比傳統的語言更接近人類的思考方式，應用在 軟體的分析與設計方法，做為互相溝通與了解的基礎，也讓使用 者可以更容易接受[物擇 96]。在本論文中將針對分析與設計階段中 最常用的三種流程圖，使用案例圖、類別圖、和循序圖進行設計過 程的版本控制分析。
3.1.2 相關發展工具
在研究進行的過程中，將利用現有的組態管理工具和繪製流程圖 的工具，如下：
Microsoft Visual SourceSafe
Visual SourceSafe 為微軟所提供的一套 專案導向版本控制系 統，用來控制各軟體、文件的版本，其有利於程式設計人員、文件撰 寫人員針對所產出之文件、程式碼進行版本管理。其功能除了版本控 制外，還可以比對各版本間的差異性，對程式寫作也有相當大的幫助。
Visual SourceSafe 的優點包括：安全性高且授權的使用者也能輕 易地存取檔案，支援各種大小規模的作業，允許在專案之間分享檔案 與變更追蹤，提高了網路與個人電腦上，檔案管理的團隊生產力。另
外與許多產品密切的整合，提供各類文件的版本控制，且提供許多進 階功能，可用於大型團隊、複雜的專案與網站。
雖然 Visual SourceSafe 提供強大的組態管理功能，也擁有許多的 優點，但對於版本間的變更控管上，也和許多其他工具一樣，僅僅只 能提供給使用者程式碼差異的比較，如圖 3-1，並未能對於差異內容 進行更進一步的說明與分析，所以我們將利用 Visual SourceSafe 原有 的功能，延伸發展一個變更差異分析系統，希望對於變更狀況能做到 更有效的整合、分析管理。
圖 3-1 Visual SourceSafe 提供版本差異報告
Rational Rose
Rational Rose 為視覺化物件導向分析設計工具，其提供最完整的 UML 支援，不論系統分析、設計、至程式設計，均可用 UML 來發 展物件導向系統。由於 Rational Rose 繪製的流程圖，將轉換成編碼的 方式來儲存設計檔案，因此在版本控制分析上可以用來比對版本間的 變更差異。
由於我們將系統範圍設定在系統分析設計階段，因此在利用 Rational Rose 繪製 UML 物件導向流程圖中，將選擇最常用於物件導 向系統設計的三種流程圖應用於版本變更上的分析管理，包括：使用 案例圖、類別圖、和循序圖。
??類別圖 (Class Diagram)
類別圖在物件導向方法當中最常被使用到，也是最核心 的部分。類別圖描述系統中物件的類型以及類型間的各種靜 態 關 係 ， 還 會 把 類 別 的 屬 性 (attribute) 、 運 作 (operation)、以及物件間相連接所應遵守的限制都顯示出 來，舉例說明如圖 3-2。
圖 3-2 類別圖
??使用案例圖 (Use Case Diagram)
使用案例圖主要是從功能的角度來敘述系統的設計，可 以明白說明系統所提供的功能與使用者之間的關係，由行為 者 (actor) 與使用案例 (use case) 組成，舉例說明如圖 3-3。
圖 3-3 使用案例圖
??循序圖 (Sequence Diagram)
循序圖主要是用來表達每個使用案例的工作流程，物件 與物件間的互動關係以及訊息的傳遞，是 UML 中針對物件 導向設計做較為動態的說明，舉例說明如圖 3-4。
圖 3-4 循序圖
3.2 系統架構
本研究以發展軟體組態差異分析器 (Software Configuration Difference Analyzer, SCDA)為核心，再整合現有的軟體組態管理工具 Microsoft Visual SourceSafe，並配合使用繪製物件導向流程圖的軟體 Rational Rose，進行系統分析與設計階段的流程圖版本控制管理。當 設計師對於自身負責的設計檔案，或是專案經理對於整體專案需要觀 看其變更修改狀況時，則透過軟體組態差異分析器自動要求 Visual SourceSafe 產生差異報告，並進行比對、轉換與分析，最後提供符合 各個使用者需求的資訊。
本研究將系統的使用設定於系統開發生命週期的系統分析設計 階段，因此整個系統的使用者角色上，包含系統設計師 (Designer) 與 專案經理 (Project manager)，系統設計師可以利用本系統來管理所參 與專案的流程圖設計的版本修改，而專案經理則可以利用本系統控制 與監督整個專案進行的設計開發過程。整合的系統架構圖如圖 3-5。
其中 Visual SourceSafe 為軟體組態管理工具，在專案的開發過程中，
會全程控管整個專案的發展，系統設計師在設計修改專案中的流程圖 時，必須先將該設計檔案做 Checkout 複製到自己的工作目錄下，並 於繪製物件導向流程圖的軟體 Rational Rose 中進行設計與修改，當修 改結束後將修改後的設計檔案於 Visual SourceSafe 中 Checkin 回存於 系統，再進行綜合更新，系統執行流程如圖 3-6。
圖 3-6 系統執行流程圖
大略概述整體系統架構之後，以下將介紹系統架構中的每個元 件並說明 Visual SourceSafe 在本系統中所扮演的角色。
Difference
report Analytical
report Software
Configuration Difference
Analyzer Check out
Microsoft Visual SourceSafe
Check in
Rational Rose Design model Edit UML
3.2.1 模式符號產生器 (Model Notation Generator)
Rational Rose 提供了最完整的 UML 支援繪製物件導向流程圖。
因此當受到 Visual SourceSafe 控管的設計檔案處於 Check out 狀態 時，設計師則可以透過 Rational Rose 進行設計檔案的修改。
Rational Rose 以繪製物件導向流程圖的方式進行系統分析與設 計，並以轉換成編碼的方式儲存設計檔案，其中除了新增、刪除以及 修改整體設計流程圖之外，針對於個別設計流程圖的變更情形包括：
??各種物件定義的變更
??物件之間相互關係的變更
??圖形位置的改變
這種透過工具使用而自行產生編碼的設計檔案，通常會以某種特 定且固定的方式記錄與儲存，而設計檔案在變更修改時，也可以發現 有固定依循的模式符號 (Model Notation)。由於本研究主要將對於圖 形設計上的變更進行了解和管理，對於非設計上的變更(如：圖形位 置的改變)則加以排除，因此根據這個特性，必須將此領域中的模式 符號加以分類歸納，以便進行設計檔案版本控制時的整合與分析。
在我們的研究中，分析的焦點在利用 Rational Rose 繪製 UML 流 程圖的設計檔案版本變更，因此應用於設計不同的流程圖檔案，新
增、修改、刪除變更的符號也將不相同，下表 3-1 整理分類出繪製流 程圖中的模式符號項目，包括：
表 3-1 UML 符號項目 類別圖
(Class Diagram)
類別 (Class)、屬性 (Attribute)
運作 (Operation)、關係 (Association) 使用案例圖
(Use Case Diagram)
行為者 (Actor)、使用案例 (Use Case) 關係 (Association)
循序圖
(Sequence Diagram)
物件 (Object)、訊息 (Message)
根據以上分類的符號項目，我們可以利用 Rational Rose 中完整的 設計檔案編碼進行更深入的相關模式符號歸納，並將歸納的模式符號 儲存於 UML 符號資料庫 (UML Notation Database) 中，以方便於之 後的比對分析工作。
3.2.2 軟體組態差異分析器架構
軟體組態差異分析器為本系統中最主要的核心元件，有了上述的 兩種資料，專案中設計檔案的版本差異報告與 UML 模式符號之後，
我們就可以透過使用軟體組態差異分析器，進行分析與整合整體的專 案，提供系統設計師或是專案經理所需求的資訊。圖 3-7 為軟體組態 差異分析器的架構圖。
軟體組態差異分析器在整體的系統架構中，是最為重要的一個元 件，原先我們必須透過執行 Visual SourceSafe 要求其提供某設計檔案 的版本差異報告。現在我們則隱藏此動作，改由本系統所設計之介面 (Difference Analyzer Interface) 要求 Visual SourceSafe 來提供使用者 所需求之差異報告。接下來本系統再利用 Visual SourceSafe 所提供的 差異報告，與先前 UML 符號資料庫中的模式符號做分析比對後進行 符號規則的轉換，最後進行版本或是整體專案的分析與整合，其結果 將可以利用介面提供給專案經理或是設計師所需要的版本分析資 訊。以下將再分別介紹其中的組成元件。
3.2.2.1 符號轉換規則 (Notation Transformation Rules)
UML 符號資料庫中的模式符號，是針對著該領域中重要的符號 項目加以分類收集，亦代表著變更過程中可能有的變更情形。為了要 詳細說明設計檔案變更的狀況，我們必須對於要轉換的相關 UML 符 號進行更為明確定義，一旦 Visual SourceSafe 所提供的差異報告中，
找出符合的 UML 符號，我們就可以根據其意轉換 UML 符號為已經 定義的說明。
UML 符號轉換規則的收集過程，是由軟體組態管理工程師 (SCM Engineer) 透過一個符號管理介面 (Notation Manager)，對於轉 換相關 UML 符號進行定義說明的記錄，並將其儲存於符號轉換規則 中，以利於進行比對之後的轉換工作。
3.2.2.2 差異分析引擎 (Difference Analyzer Engine)
差異分析引擎是軟體組態差異分析器中的核心，對於 Visual SourceSafe 提供的差異報告，執行 UML 符號的符合比對、轉換與進 一步的整合分析工作，最後再將產生的結果呈現給系統設計師或是專 案 經 理 。 其 中 包 含 比 對 機 制 (Matching Mechanism)、 轉 換 機 制 (Transformation Mechanism) 、 版 本 報 告 產 生 器 (Version Report Generator)、以及專案報告產生器 (Project Report Generator)。
由於在報告的呈現上是根據使用者的角色不同而提供不同分析 程度的報告，這個部份是由版本報告產生器 (Version Report Generator) 和專案報告產生器 (Project Report Generator)所控制。因此，透過判 斷使用者在專案中所扮演的角色，進行版本報告產生器或是專案報告 產生器的運作，並在差異分析引擎中進行分析或是整合報告的產生，
將版本差異分析報告提供給系統設計師做為控管版本修改參考，而專 案整合報告則是提供給專案經理做為整體專案管理的依據。
比對機制 (Matching Mechanism)
比對機制的工作就是尋找出是否有符合先前歸納分類的 UML 符 號。其根據使用者的不同要求，將 Visual SourceSafe 提供的各式各樣 的版本差異報告，與 UML 符號資料庫中所儲存的模式符號，進行找 尋比對與設計變更相關的資訊，若非相關設計的變更(如：圖形位置 的改變)則不加以考慮。
轉換機制 (Transformation Mechanism)
轉換機制的工作則是轉換差異報告為符號規則。所以當比對機制 比對版本差異報告與 UML 符號，找出符合的模式符號後，轉換機制
版本分析器 (Version Analyzer)
由於不同使用者的需求與權限不同，因此在完成比對與轉換的工 作後，將針對不同的需要給予不同的報告資訊。
在個別版本報告的產生過程中，利用版本分析器將進行統計與分 析工作，對於設計檔案中的每個版本間的差異情形，統計 UML 符號 的變更數量，並分析記錄變更項目與其相關連性，讓設計師可以更準 確的掌握版本的修改情形。
專案整合器 (Project Integrator )
而對於整體專案的報告產生上，除了整合專案中的所有設計檔 案，並將分析完整的專案架構外，還必須要整合專案中的資料，以提 供給專案經理一個架構完整且詳細的專案報告。
版本報告產生器 (Version Report Generator)
版本報告產生器的功能為產生個別版本差異分析報告，當設計師 透過軟體組態差異分析器中的差異分析介面 (Difference Analyzer Interface) 要求產生某設計檔案的版本報告時，系統將連結 Visual
SourceSafe 要求產生某版本的差異報告，並將此差異報告與 UML 符 號比對，當兩者有相符合的情形時，則將原先的差異報告轉換為模式 規則，並進行統計、分析的工作，最後根據統計、分析的結果提供版 本差異報告給該設計師。下圖 3-8 為版本報告的產生過程：
圖 3-8 版本差異分析報告產生流程圖
Compare difference report with the model notation
Statistics and analyze Request for version report
VSS generate difference report
Generate difference analyze report
Matching?
Yes
No
Transfer original difference reports to notation rules
專案報告產生器 (Project Report Generator)
若專案經理要求產生整體專案的分析報告時，則透過差異分析介 面，連結 Visual SourceSafe 要求產生整體專案的所有相關報告，除了 將此報告與 UML 符號加以比對並轉換為符號規則外，並進行整合所 有設計檔案與資料、以及分析完整的專案組成架構，最後再根據整合 整體與分析的結果產出專案整合報告。專案整合報告中，提供包括了 專案中的個別設計檔案架構圖、整合類別圖、整合使用案例圖以及整 合循序圖的說明。圖 3-9 為專案整合報告產生的過程：
圖 3-9 專案整合報告產生流程圖
Compare reports with the model notation
Analyze project architecture
Request for project report
VSS generate all reports of requested project
Generate project integrate analyze report Matching?
Yes
Transfer original reports to notation rules
Integrated project files
Integrate project data
3.2.2.3 差異分析介面 (Difference Analyzer Interface)
差異分析介面為系統提供給使用者輸入需求的一個介面，透過此 介面，系統可以結合 Visual SourceSafe 中對於專案開發的權限控管機 制，賦予使用者在系統使用過程中相對應有的權限。
3.2.3 Visual SourceSafe 使用模式
Microsoft Visual SourceSafe 為微軟出版的一套版本控制系統，當 專案的設計檔案加入 Visual SourceSafe 之後就將列入 SourceSafe 的管 控，而所有使用者也都必須在 SourceSafe 的控管下進行檔案的修改。
Visual SourceSafe 在本系統中所扮演的角色為管理專案的基本版 本控制，在透過使用 Source Safe 管理流程圖的開發過程中，受到 Source Safe 控管的流程圖設計檔案都必須先 Check out，此時 Source Safe 便鎖定該設計檔案，致使其他的使用者無法在同時間進行修改以 避免產生問題，並且執行開啟 Rational Rose 讓使用者進行修改。當確 定修改完成，則儲存並 Check in 該設計檔案以取消鎖定，完成設計檔 案的修改更新版本。
在許多的軟體組態管理工具中，對於每個檔案版本的變更，都可 以提供給使用者版本比對的結果，讓使用者可以比對程式碼修改的差 異情形。而差異報告為 Visual SourceSafe 提供的相關功能，讓使用者 可以依需求，呈現出整體專案、個別版本修改歷史清單，或是針對於 每個檔案版本之間的差異比對提供差異報告。下圖 3-10 為使用 Visual SourceSafe 的流程圖。
圖 3-10 Visual SourceSafe 使用流程圖
根據本章所提出架構，我們將在下章實作一個應用於分析階段版 本控管的差異分析系統，並分別對於系統的開發環境、系統功能架 構、以及系統做詳細說明。
Pass request to show history Check out requested
file and lock
Check in file and unlock
Request to generate difference report
第四章 系統實作與介紹
本研究將以前述章節所規劃設計的軟體組態差異分析器系統架 構與整合機制為基礎，實作一個應用於分析階段版本控管的差異分析 系統以驗證其可行性。本章將分別對於系統的開發環境、系統功能架 構、以及系統做詳細說明。
4.1 開發環境
本研究所開發的版本變更差異分析系統，在整個系統的開發中主 要是使用微軟 Microsoft 公司的 Windows 2000 作業系統作為系統開發 平台，並以 Microsoft Visual Basic 6.0 作為系統的開發工具，再加上 結合前一章所述的 Microsoft Visual SourceSafe 與 Rational Rose 進行 系統的實作。
Visual Basic 6.0 為一中文化的開發工具，除了承襲以往 Visual Basic 易學易用的特性之外，能夠幫助開發人員輕易建立多層式解決 方案。使用者可以快速、有效率、輕鬆的建立出以 Windows 為基礎 的圖形化應用程式。
4.2 系統功能架構
本研究所設計之版本變更差異分析系統功能架構如圖 4-1。系統 下分為【個別版本管理】與【專案整合分析】兩個部份，【個別版本 管理】主要針對系統設計師的需要，提供系統設計師對於所負責繪製 的流程圖詳細的版本變更狀況。而【專案整合分析】則提供給專案經 理使用，除了包含對於整個專案下呈現的流程圖架構之外、再分別對 於類別圖、使用案例圖、以及循序圖的部份給予詳細的整合說明。
圖 4-1 系統功能架構
變更差異分析系統
個別版本管理 專案整合分析
版 本 變 更 歷 史 清 單
版 本 差 異 說 明
版 本 差 異 統 計 分 析
專 案 流 程 圖 架 構
專 案 類 別 圖
專 案 使 用 案 例 圖
專 案 循 序 圖
4.3 詳細系統說明
本節將詳細的介紹本研究所發展的系統實作的成果，以及所提供 的各項相關功能。
系統登入
進入本系統的起始畫面即為使用者登入畫面如圖 4-2，使用者在 輸入帳號、密碼之後，系統會查詢該使用者帳號密碼是否有誤，是否 為專案中的成員，並且判斷使用者在專案中所扮演的角色。
圖 4-2 系統起始登入畫面
個別版本管理
當使用者所輸入的帳號密碼正確，並且系統判斷使用者的角色為 專案中的設計師時，系統則進入版本變更差異分析系統─【個別版本 管理】的畫面，如圖 4-3。
圖 4-3 系統【個別版本管理】畫面
當使用者進入此畫面，僅可以選擇查看自己所參與專案中的設計 檔案，並且在選取所要觀看的設計檔案中某一修改版本後，系統將會 列出該版本中的所有修改狀況，並提供修改項目數量的統計。
但是當使用者選擇了並非是自己所參與專案中修改的設計檔案 時，系統將會出現錯誤提示畫面，如圖 4-4，以告知使用者並非專案 中該設計檔案的設計者。
圖 4-4 非檔案設計者錯誤畫面
專案整合分析
若當使用者所輸入的帳號密碼正確，並且系統判斷使用者的角色 為專案中的專案經理時，系統則進入版本變更差異分析系統─【專案 整合分析】的畫面，如圖 4-5。
圖 4-5 系統【專案整合分析】區畫面
當專案經理進入此畫面時，僅可以選擇查看自己所管理的專案，
因此當專案經理在選取所要觀看的專案後，系統將會提供給專案經理 所有相關於該專案的資訊，並且對於三種流程圖分別提供整合性的分 析資訊，以下將分成四區來作不同層級的說明：
(一) (二)
(四) (三)
(一) 系統畫面的左上角提供該專案所有設計檔案中的流程 圖架構。
(二) 在點選某一設計檔案後，畫面的右上角將會列出參與該 設計檔案的設計師資訊。
(三) 當選取的是類別圖時，在畫面的左下角則提供專案設計 檔案中相關類別圖架構，其中包含：類別、屬性以及運 作。若選取的是使用案例圖時，則提供行為者與使用案 例的關係架構圖。而當選取循序圖時，則提供專案中尋 循序圖設計檔案的架構。
(四) 當選取的是類別圖時，右下角則提供針對於該類別圖的 類別關係資訊，包含一般關係、繼承關係以及聚合關 係。當選取循序圖時，則依照先後順序提供訊息間傳遞 的關係，包含傳送者、接收者以及傳送的訊息。若選取 的是使用案例圖時，則無提供更詳細的資訊。
在介紹系統實作結果之後，在下一章中我們將一個現有的專案運 用於本系統上，並對於系統所提供的功能做說明。
第五章 實例說明
本研究所發展出來的系統結合了 Visual SourceSafe 與 Rational Rose 的使用，期望對於版本的差異提供詳細的分析報告。本章將利 用一個現有的專案─【銀行信用卡】[高煥堂 99]，說明使用本系統在 專案進行過程中，對於分析設計流程圖的開發進行版本的控管，並提 供給專案經理與系統設計者所需求的報告。
5.1 專案版本管理
Visual SourceSafe 的使用中，加入一個專案【銀行信用卡】，並且 在其中加入系統範圍、銀行系統兩個設計檔案，如圖 5-1。
圖 5-1 Visual SourceSafe 的使用
此時這兩個設計檔案在修改的過程中，就必須受到 Visual SourceSafe 的控制。透過 Visual SourceSafe，專案經理也可以設定加 入專案的系統設計師，並分別給予設計師修改檔案的權限。
5.2 物件導向系統分析設計過程
當系統設計師在利用 Visual SourceSafe 工具執行 Check out 動作 之後，便會執行開啟 Rational Rose 工具，讓系統設計師使用並進行設 計檔案中流程圖的新增與修改。如下圖 5-2 。
圖 5-2 Rational Rose 的使用
在 Rational Rose 中完成修改並且儲存之後，便可以回到 Visual SourceSafe 中執行 Check in 的動作，此時設計檔案的版本編號會遞增。
5.3 前後版本差異分析實例
系統設計師經由利用 Visual SourceSafe 進行專案控管，並使用 Rational Rose 所繪製完成的類別圖，如圖 5-3。
圖 5-3 類別圖修改後
專案開發過程中在經過不同系統設計師的修改及變更，Visual SourceSafe 中會記錄設計檔案版本的修改歷史清單，並提供前後兩個 版本編碼差異的報告如圖 5-4。Visual SourceSafe 產生的差異報告僅 將版本間的編碼差異給擷取出來，並未對於其中給予詳細的說明。
圖 5-4 Visual SourceSafe 所提供之版本差異報告
Diffing: $/銀行信用卡/銀行系統 .mdl;3 Against: $/銀行信用卡/銀行系統.mdl;4
67 Change: (object ClassAttribute "總價"
To: (object ClassAttribute "總金額"
69 Change: (object ClassAttribute "日期"
To: (object ClassAttribute " 消費日期"
70 Change: quid "3B298BA5021D") To: quid "3B298BA5021D"))) 71 Del: (object ClassAttribute "商店名稱"
72 Del: quid "3B298C08024E"))) 86 Ins: (object Class " 會員"
87 Ins: quid "3B59044D02F5"
88 Ins: exportControl "Private"
89 Ins: operations (list Operations
90 Ins: (object Operation "查詢總額度"
91 Ins: quid "3B5904AC02C0"
92 Ins: concurrency "Sequential"
93 Ins: opExportControl "Private"
94 Ins: uid 0)
95 Ins: (object Operation "修改總額度"
96 Ins: quid "3B5904B901DA"
97 Ins: concurrency "Sequential"
98 Ins: opExportControl "Private"
99 Ins: uid 0))
100 Ins: class_attributes (list class_attribute_list 101 Ins: (object ClassAttribute "姓名"
102 Ins: quid "3B5904950383") 103 Ins: (object ClassAttribute "地址"
104 Ins: quid "3B59049D0104") 105 Ins: (object ClassAttribute " 會員編號"
106 Ins: quid "3B5904A000EB"))) 107 Ins: (object Class " 額度"
108 Ins: quid "3B5904F2035F"
109 Ins: operations (list Operations
110 Ins: (object Operation "查詢現金額度"
111 Ins: quid "3B59050C00AC"
112 Ins: concurrency "Sequential"
113 Ins: opExportControl "Public"
114 Ins: uid 0)
115 Ins: (object Operation "更改現金額度"
116 Ins: quid "3B59051B0131"
117 Ins: concurrency "Sequential"
118 Ins: opExportControl "Public"
119 Ins: uid 0))
120 Ins: class_attributes (list class_attribute_list 121 Ins: (object ClassAttribute "會員 ID"
122 Ins: quid "3B5904FA00B8") 123 Ins: (object ClassAttribute "總額度"
124 Ins: quid "3B5904FF00FC") 125 Ins: (object ClassAttribute "紅利"
126 Ins: quid "3B59050603E2")))
100 Change: client_cardinality (value cardinality "0..n"))))) To: client_cardinality (value cardinality "0..n")))) 140 Ins: (object Association " 會員"
141 Ins: quid "3B590532039A"
142 Ins: roles (list role_list 143 Ins: (object Role "$UNNAMED$2"
144 Ins: quid "3B5905330157"
145 Ins: supplier "Logical View::會員"
146 Ins: quidu "3B59044D02F5"
147 Ins: client_cardinality (value cardinality "1")) 148 Ins: (object Role "$UNNAMED$3"
149 Ins: quid "3B5905330161"
透過本系統的使用，改善 Visual SourceSafe 提供差異報告的方 式，不但可以明確的說明流程圖各版本間的實際差異如：新增、刪除、
修改某些符號外，還可以提供進一步的統計分析資訊如圖 5-5。
圖 5-5 類別圖版本差異分析報告
除了類別圖之外，利用本系統於使用案例圖與循序圖的設計繪製 上，所進行設計檔案版本修改之後，所產生版本間變更差異分析結果 如下。
Diffing:$/銀行信用卡/銀行系統.mdl Ver 3 Checked in by Vincent Against:$/銀行信用卡/銀行系統 .mdl Ver 4 Checked in by Erin 修改 Attribute "總價" 為 Attribute "總金額"
修改 Attribute "日期" 為 Attribute "消費日期"
刪除 Attribute "商店名稱"
新增 Class "會員"
新增 Operation "查詢總額度" (Private) 新增 Operation "修改總額度" (Private) 新增 Attribute "姓名"
新增 Attribute "地址"
新增 Attribute "會員編號"
新增 Class "額度"
新增 Operation "查詢現金額度" (Public) 新增 Operation "更改現金額度" (Public) 新增 Attribute "會員 ID"
新增 Attribute "總額度"
新增 Attribute "紅利"
新增 Association "會員" ("會員" <1> － "信用卡" <1..n>) 新增 Association "總額度" (" 額度" <1> － "會員" <1>)
新增 Class 2 個 新增 Attritube 6 個 修改 Attritube 2 個 刪除 Attritube 1 個 新增 Operation 4 個 新增 Association 2 個
圖 5-6 使用案例圖修改前
圖 5-7 使用案例圖修改後
圖 5-8 使用案例圖版本差異分析報告
Diffing:$/銀行信用卡/系統範圍.mdl Ver 2 Checked in by Erin Against:$/銀行信用卡/系統範圍 .mdl Ver 3 Checked in by Vincent 修改 UseCase "查詢可用額度" 為 Class "銀行行員"
新增 Actor "商家店員"
新增 UseCase "可用額度查詢"
修改 UseCase "掛失信用卡" 為 UseCase "信用卡掛失"
新增 UseCase "調整信用額度"
新增 UseCase "列印帳單"
新增 UseCase "還款"
新增 UseCase "查詢信用卡狀況"
新增 Association ("調整信用額度" － "銀行行員") 新增 Association ("列印帳單" － "銀行行員") 新增 Association ("還款" － "銀行行員")
新增 Association ("要求調整額度" － "銀行行員") 新增 Association ("查詢信用卡狀況" － "商家店員")
新增 Actor 1 個 修改 Class 2 個 新增 Association 5 個 新增 Usecase 5 個 修改 Usecase 2 個
圖 5-9 循序圖修改前
圖 5-10 循序圖修改後
圖 5-11 循序圖版本差異分析報告
Diffing:$/銀行信用卡/系統範圍.mdl Ver 4 Checked in by Vincent Against:$/銀行信用卡/系統範圍 .mdl Ver 5 Checked in by Vincent 修改 Message "查詢總額度" 為 Message "總額度查詢"
新增 Message "更改總額度"
新增 Message "預計消費"
新增 Message "查詢現金額度"
新增 Message "更改現金額度"
新增 Object "消費"
新增 Object "總額"
新增 Object 2 個 新增 Message 4 個 修改 Message 1 個
5.4 專案整合分析實例
除了上節所述之外，針對於專案中的個別設計檔案，會提供給系 統設計師個別版本差異的分析統計功能之外，對於專案經理也能夠提 供關於整體專案整合性的分析報告。專案整合性分析報告其中將包 括：專案架構圖、整合類別圖、整合使用案例圖以及整合循序圖，分 別詳述如下。
專案架構圖
在專案整體架構的表示上，系統會根據 Visual SourceSafe 所控管 的專案，和該專案所包含的設計檔案，以整體專案的檔案架構與所包 含流程圖的方式呈現，如圖 5-12。
圖 5-12 專案架構圖
整合類別圖
系統將該專案中所有關於類別圖架構呈現如圖 5-13，其中包含有 類別、及其屬性、運作，並針對於類別圖中所有類別的關係如：一般 關係、繼承關係、聚合關係做分類。
圖 5-13 整合類別圖畫面
整合使用案例圖
在使用案例圖的整合說明上，系統將該專案中所有使用案例圖架 構呈現如圖 5-14，其中包含有行為者與使用案例，並明確表示使用案 例圖中行為者與使用案例之間的關係。
圖 5-14 整合使用案例圖畫面
整合循序圖
在循序圖的整合說明上，系統將該專案中所有循序圖架構呈現如 圖 5-15，另外對於循序圖中所有進行的狀態變化情形如：物件、訊息 都將會依其順序，全都表示出來。
圖 5-15 整合循序圖畫面
第六章 結論
在本章中，我們將對於系統開發的特色加以說明，並對於後續的 研究提出未來方向，最後再為本研究提出結論。
6.1 系統特色
簡化差異報告的判讀
本研究的首要目標就是希望能在進行流程圖版本控管的同時，對 於變更的符號提供詳細的說明。所以當變更修改發生後，將差異報告 和資料庫中所儲存管理的模式符號進行比對分析，再轉換列舉出變更 的狀況，這樣不但可以簡化差異報告中程式碼的判讀，也可以清楚的 表示變更的情形。
提供專案整合與分析功能
目前現有的一些軟體組態管理工具，對於各個版本間只提供程式 碼的差異比對，並無法進一步得知其意義，因此我們以 SourceSafe 為基礎，發展一個版本差異分析系統，並選擇系統分析設計階段的物 件導向流程圖進行版本控制，對於所繪製的流程圖，不但做到版本控 制管理，也能更進一步的得到各不同版本間的差異分析，對於開發者
6.2 未來研究方向
本論文根據所提出軟體組態差異分析器架構以及整合機制，進行 版本變更差異分析系統的實作，後續相關的研究方向有：
(一) 目前我們主要是針對使用案例圖、類別圖、和循序圖，這 三種系統分析設計階段中最常使用的流程圖進行控管與 分析整合的工作，未來增加更多模式符號的收集，對於其 他種類的流程圖也可以進行相同的管理工作。
(二) 現階段對於 UML 模式符號的分類收集，是經由人工建立 完成，未來可以利用其他人工智慧的技術，例如：決策樹 (Decision Tree)、智慧型代理人 (Intelligent agent) … 等，
幫助其進行相關模式符號收集整理。
(三) 目前我們將系統限定於系統分析設計階段，對於使用 Rational Rose 工具所產生的物件導向分析設計流程圖進 行版本控管與分析，未來將可以擴大應用於系統發展生命 週期的其他階段中。
6.3 結論
在本論文的研究中，以軟體組態管理相關基礎理論與模型的探 討，與比較現有的相關技術工具下，提出了一個應用於分析設計階段 的版本變更差異分析系統架構，之後再根據此系統架構，進而實作一 個版本變更差異分析系統以驗證其可行性，結果顯示在系統的規劃 下，所預先歸納的模式符號足以描述流程圖設計過程時的變更情形，
而系統實作的結果與各項功能也都夠如預期的展現。
軟體開發過程中，專案經理與其他成員都扮演非常重要的角色，
除了相關努力、時間、與資源的獲得外，還需要一個好的軟體組態管 理的輔助，藉由適當的執行軟體組態管理的過程，在複雜的軟體發展 中提供元件的控管與更進一步的分析整合，不但可以幫助企業改善軟 體發展生命週期和產品的品質，更可以增加企業競爭優勢。
參考文獻
[中文文獻]：
1. [MISO98] MISOO 物件教室, Rational Rose 的 Use Case 觀點 (View), 物件導向雜誌, 第十期之 50-65 頁, 1998 年 4 ~ 5 月。
2. [王豐堅 98] 王豐堅, 物件導向技術之發展現況, 軟服團軟體 產業通訊, 第十四期軟體技術, 1998 年 12 月。
3. [物澤 96] 物澤 OT中心, 迎接 UML, 物件導向雜誌, 第五期之 98-106 頁, 1996 年 8 ~ 9 月。
4. [物澤 97] 物澤 OO 中心, UML 的使用個案觀念之多少, 物件 導向雜誌, 第六期之 98-107 頁, 1996 年 12 月~1997 年 1 月。
5. [徐明 96] 徐明,高煥堂, UML,讓我來瞭解您的心, 物件導向雜 誌, 第六期之 63-75 頁, 1996 年 12 月~1997 年 1 月。
6. [高煥堂 99] 高煥堂, 系統分析師(SA)文件的標準化、視覺化、
數位化, 物件導向雜誌, 第十二期之 7-39 頁, 1999 年 6 月~7 月。
7. [興 德科技 99] 興 德科技 , 興德總代理 Rational ClearCase, 1999。http://www.sinter.com.tw/ClearCasenew.htm (2 Apr. 2001).
[英文文獻]：
1. [Ambr90] V. Ambriola, L. Bendix, P. Ciancarini, “The Evolution of Configuration Management and Version Control,” Software Engineering Journal, Volume 5, Number 6, Page(s): 303-310, November 1990.
2. [Belk96] N. Belkhatir, J. Estublier, “Supporting Reuse and Configuration for Large Scale Software Process Models,”
Proceedings of the 10th International Software Process Workshop, Page(s): 35-39, 1996.
3. [Bers80] E. Bersoff, V. Henserson, S. Siegel, Software Configuration Management, An Investment in Product Integrity, Prentice-Hall, 1980.
4. [Buck94] F.J. Buckley, “Implementing a software configuration management environment,” Computer, Volume 272, Page(s):
56-61, February 1994.
5. [Capr92] M.A.M. Capretz, M. Munro, “COMFORM - A Software Maintenance Method Based on the Software Configuration Management Discipline,” Proceedings of the Conference on Software Maintenance, Orlando, Florida, Page(s): 183-192, November 1992.
