Kenmingの鮮思維 » 軟體開發工具

[轉貼] EA 與 Visio UML 工具比較

Kenming Wang — Mon, 17 May 2010 07:15:01 +0000

這一份 EA (Enterprise Architect) 與 Visio 的比較表，是由我們 HSDc. Cathy 小姐找了許多資料，用心所整理出來的功能比較表。

EA 怎麼會與 Visio 來作比較？其實這是國內某大銀行 IT高級主管所要求的，必須附在產品採購內的評估報告。

一開始的直覺是，這兩樣能作比較嗎？ Visio 算是一種繪圖製作的工具，提供了諸多各類型，包括網路、基本流程、甘特圖、乃至於 Mindmap, UML 等圖形元件 (Widgets)的模版 (Template)：而 EA 則當然是 UML 專業設計的工具。

但是，我還真問了許多已經使用過這類如 EA, RSA (Rational Software Architect), Together 等工具的軟體開發者 (Developer)，到底與 Visio 的主要差異為何，沒想到絕大部分還真回答不出來，以為就是在繪製 UML 圖形的便利性與否而已。

不然！其實以 EA 這等專業 UML 工具，為何售價需要近萬元？必然是有 Visio、或者一般免費 UML 工具所無法比擬的特點。但可不是繪圖容易與否這類問題上，真正的主要差異在於：

有效調和專案 (Project)開發過程中，不同角色 (Role)的開發者所設計出來的 UML 產出 (Artifacts)，並在這些產出之間，有效監控並期能保持一致性。

更簡而言之來說，當專案是需要團隊協同開發時，則專業性的 UML 工具則是有其必要的，且更能有效保存軟體開發過程中的設計產出，成為團隊甚或企業的有效資產。

至於 EA 與 Visio 兩者的ㄧ些主要功能差異，則可以參考底下 Cathy 小姐所整理出來的比較表：

比較點說明	visio	EA
1. 產品本質不同	是繪圖工具。	是視覺化的塑模工具。
2. UML Elements關係	Elements 之間關係建立並無法追溯 Links。	可以很清楚的掌握每個 Elements 之間得關係。
3. UML Diagram 關係	Diagrams 之間無法建立直接關係，每張設計圖並無法直接連結。	各個不同層次的設計圖，可以建立關係，並輕鬆的 Double-Click 即可到該設計圖位置。
4. 文件產製	僅可將設計結果轉成圖檔，但無法支援設計圖描述的相關文件格式或資訊。	可自行製訂文件格式，後自塑模工具直接轉出所有設計文件及設計圖。
5. 反向工程的能力	僅支援Microsoft Visual C++ 6.0、Microsoft Visual Basic 6.0 和 Microsoft Visual J++ 6.0三種語言，提供反向工程，從程式碼轉回設計圖之過程。	1. 強化正反向過程，可支援多種程式語言(包括：C、C#、C++、Delphi、Java、PHP、Python、VB .Net、Visual Basic、Action Script)，隨時同步處理程式碼與設計(Class Model)之間的正確性。 2. 有能力透過動態執行時期(runtime)或靜態方式掃瞄程式碼產出系統一致的設計圖(Sequence Diagram)。
6. 與資料庫的關係	無支援該服務。	Data Model可動態各種不同資料庫之間轉換DDL。
7. 塑模除錯檢查	無支援該服務。	由於是塑模工具，嚴格的按照 UML2.1 的語法進行整個除錯檢查，於塑模過程中若有不對的語法，使用者會很輕易的知道錯誤。
8. 產生程式碼框架的能力	無支援該服務。	可支援多種程式語言(包括：C、C#、C++、Delphi、Java、PHP、Python、VB .Net、Visual Basic、Action Script)，產生程式碼框架。也可自建其他程式碼語言轉換樣版。
9. 團隊協同合作	僅是繪圖工具，並無支援協同合作。	1. 可直接與各種不同的版本控管系統結合，包括：CMS, Subversion, Team Foundation Server. 並可支援。 2. 可以充分掌握每個設計Element的Owner, Update, 並產出不同View(譬如：使用案例與商業邏輯)之間關係矩陣表。 3. 商業用使用案例(Business Use Case)直接寫完後，可直接自動轉成流程圖。
10. 與測試案例規畫應用上	不支援該功能。	提供可以將使用案例的情節(Scenario)直接匯入至測試案例規畫情節，測試分析師只要填寫相關測試資料即可。

※ 延伸參考
　o UML 工具比較分析。

延伸閱讀：

程式碼與 UML 類別_循序圖的關係探討-完結 (4)

Kenming Wang — Fri, 14 May 2010 00:05:05 +0000

支援自動產出循序圖的工具

EA (Enterprise Architect) 8.x－內建動態產出循序圖的機制。
Together, RSA, Flowchart4j(c#) －支持靜態產出循序圖的方式。
HSDc. Sequence Genenator (名稱暫訂)
- 實作於 EA 7.x-8.x Plugin。
- 支持靜態產出循序圖的方式。
- 可支持正向/反向將程式碼/循序圖互轉的功能。

HSDc Seq. Generator plugin 操作示範

安裝 Seq. Generator plugin

（點擊圖片鏈接看原圖）圖、安裝 Seq. Generator plugin

匯入原始碼所在目錄

（點擊圖片鏈接看原圖）圖、匯入原始碼所在目錄
匯入成功後呈現的類別圖

（點擊圖片鏈接看原圖）圖、匯入成功後呈現的類別圖
選擇進入點 (entry point) method

（點擊圖片鏈接看原圖）圖、選擇進入點 (entry point) method
產出的循序圖 (sequence diagram)

（點擊圖片鏈接看原圖）圖、產出的循序圖

※ 延伸參考
o　程式碼與 UML 類別_循序圖的關係探討 (1)。
o　程式碼與 UML 類別_循序圖的關係探討 (2)。
o　程式碼與 UML 類別_循序圖的關係探討 (3)。

延伸閱讀：

程式碼與 UML 類別_循序圖的關係探討 (3)

Kenming Wang — Mon, 10 May 2010 08:31:39 +0000

程式碼與循序圖的正反向工程

先瞭解一個重點：靜態程式碼結構並無法直接對應循序圖 (對應的是類別圖)。

兩種方法可以產出循序圖：

動態產出：設定 run-time 環境，實際執行應用程式，再由 UML 工具至系統內追蹤解析。
靜態產出：直接掃瞄程式碼，解析物件之間的參考 (reference)。

動態產出循序圖的優缺點：

優點：
- 不需要程式原始碼，只要具有能直接執行的應用程式 (如 .NET DLL 執行檔)即可。
- 可以確實捕捉單一程序內，物件之間的呼叫情形。
缺點：
- 需要事先設定好可以執行該應用程式的 run-time 環境。設定相當複雜繁瑣 (一般需為命令列模式)，且不同的程式語言 (如 C#NET, Java, PHP …等)均須各自設定不同的 run-time 執行環境。
- 只能呈現單一執行路徑內的物件互動。意即，無法呈現如 If…Then…Else 或 Exception 等多種條件或替代路徑。

靜態產出循序圖的優缺點：

優點：
- 不需要設定繁瑣的 run-time 執行環境，操作相當簡潔。
- 可以指定所掃瞄的程式碼深度 (層次)。
- 可以同時呈現多重的條件或替代路徑的物件呼叫互動情形。
缺點：
- 需要有原始程式碼，以提供靜態掃瞄的來源依據。
- 轉換工具的實作邏輯並無明確的轉換 (transform)規則；相對來說，需要考量到程式語言個別的機制與語法，故轉換工具的實作難度相對提高。

※ 延伸參考
o　程式碼與 UML 類別_循序圖的關係探討 (1)。
o　程式碼與 UML 類別_循序圖的關係探討 (2)。

延伸閱讀：

程式碼與 UML 類別_循序圖的關係探討 (2)

Kenming Wang — Thu, 06 May 2010 14:45:30 +0000

程式碼與 UML 設計圖之間的關聯性

從抽象的角度思考類別(Class)/物件(Object) 的關係

物件是活的！
但是，類別可不是死的 (更不是活的)；因為，它僅是對系統的設計契約而已。

問題思考！？
程式原始碼 (Source Code) 對應的是 UML 哪一張設計圖？

推導－1
程式碼 = 靜態結構 = 設計契約 = 類別設計

所以 程式碼 對應的是：UML 類別圖 (Class Diagram)。

Ex. 程式碼與類別圖的對應

範例－程式碼與類別圖的對應關係

使用 UML 類別圖 (Class Diagram)的好處

快速定義類別的結構 (包括類別名稱、屬性與行為)。
過濾程式碼實做的細節，容易聚焦於類別的責任分派 (responsibility assign)設計議題。
可以透過工具，將類別圖轉出至對應的程式碼 (反之亦然)骨架 (skeleton)。

類別圖無法作到 …

無法呈現系統執行期間 (run-time)，程序單位之間的呼叫情形。
無法追蹤為完成某一特定功能案例，物件之間的動態相依呼叫關係。
無法掃瞄物件之間的動態連結，是否有違背類別圖的結構設計。

UML 循序圖的作用

循序 (sequence)圖與溝通(communication)圖均屬於物件合作 (collaboration)的呈現。
兩者僅在於呈現的方式不一樣。循序圖呈現的是從上而下循序的訊息傳遞；溝通圖呈現的是自由排列的訊息傳遞格式。
循序圖僅呈現某一特定的功能案例，一般稱之為劇本 (scenario)。為實現該案例，主要參與物件與物件之間的訊息 (message)互動描述。

Ex. 循序圖的範例呈現

（點擊圖片鏈接看原圖）圖、循序圖的範例呈現

推導－2
執行期間 (run-time)的應用程式 = 動態關連 = 物件合作

所以編譯後的程式碼在系統執行期間所呈現的物件互動，對應的是：
　　UML 合作(循序 or 溝通)圖 (Collaboration Diagram)。

繪製循序圖的重點

只表達值得關注的參與物件。
瞭解主要參與物件之間的訊息 (message)傳遞。

如同腳本，表達出某一場戲所安排的主要演員，以及演員之間的互動對話。

※ 延伸參考
o　程式碼與 UML 類別_循序圖的關係探討 (1)。

延伸閱讀：

程式碼與 UML 類別_循序圖的關係探討 (1)

Kenming Wang — Mon, 03 May 2010 13:56:22 +0000

基礎觀念導引－何謂靜態與動態？

靜態結構 (Static Structure)

表達軟體內部的結構設計。
一般指程式原始碼 (Source Code)。
軟體人員對資訊系統的設計契約 (Design Contract)。

靜態結構的設計契約

public class myclass {
	public void method_1() {
		//do something
	}
 
	public string method_2(string var) {
		//return a string
		return var;
	}
}

誰來解讀設計契約？

一般指軟體資訊系統或應用軟體伺服器 (Application Server)。
ie. 可以編譯 C#.NET 程式碼 (設計契約)並能在 .NET 平台上執行應用程式。
可以編譯 Java Spring 程式碼並能在支持 JEE (Java Enterprise Edition)平台執行完成編譯的應用程式。

動態相依 (Dynamic Dependency)

系統在執行某一特定功能時，所啟始不同的程序單元之間呼叫的一種動態相依關係。
一般指程式碼經過編譯後在執行期間 (run-time)的應用程式。
資訊系統履行軟體人員的設計契約，使之可以在其平台上執行。

靜態設計契約 vs. 動態物件間的相依關係

範例－靜態的程式碼設計契約

範例－動態物件間的相依關係

從物件導向角度來看待時

類別 (Class)：Developer 對系統的設計契約。
物件 (Object)：系統依據 Developer 的設計契約 (類別)在執行期間所產生的個體 (instance)。

推論－靜/動態與類別/物件的關係

靜態結構 = 類別設計 (Class Design)。
動態相依 = 物件之間的互動合作 (Object Collaboration)。

延伸閱讀：

「UML 協同團隊合作開發」問題與內容勘誤回覆

Kenming Wang — Tue, 07 Jul 2009 14:59:44 +0000

讀者 Pogi 很細心地在「Ringle 即將出版的新書─ UML 協同團隊合作開發」一文中，提出他對閱讀了該書之後所發現的問題。在此我也特請原作者 Ringle 在此針對所提的問題作回覆。

請問有提供勘誤表回饋網址或mail嗎？

43頁：
一般化關係：是不是應該說明一般、特殊化關係的方向性？
整體-局部關係：聚合跟組合的圖看起來都是實心的。

44頁：
相依性關係：圖示錯了。

45頁：
圖3-2的內容跟前面訪談結果不一致，特助有說跟住院事件相關的人員：醫生、護士、櫃台人員，但是類別圖卻沒有櫃台人員。

Ringle 的回覆如下：

謝謝你那麼仔細地看這本書，有關您所問的問題，分別說明如下：

43頁：
一般化關係：是不是應該說明一般、特殊化關係的方向性？
照您所說的，我會在下一版中加入一個說明：「病床」類別是「非健保病床」與「健保病床」類別的一般化。
另，聚合的部分應該為實心，這是在校稿時忽略掉了。
相依關係的部分也是一樣的。這幾個部分，主要是由於書籍的美編重新改過了原來的稿子所造成的，不過我在校稿時也沒有發現，謝謝你的指正。
有關類別圖與訪談結果並沒有不一致。「櫃臺人員」主要是屬於「Actor」的性質，並不屬於類別圖中所需關心的問題。
對於特助來說，他並非軟體設計人員，因此，他只是忠實地說明他所看到的現象，但設計人員應該要針對他的回答加以思考並過濾，而非全盤接收。

延伸閱讀：

「UML 團隊開發流程與管理」新書正式出版(6/12)

Kenming Wang — Sun, 07 Jun 2009 14:42:41 +0000

Ringle 的新書：「UML 團隊開發流程與管理」確定於 6/12 由「悅知文化」正式出版。現在有活動優惠，在 6/12 前預購均享有 7 折優惠。

UML團隊開發流程與管理
-----------------------------------
作者：賴信仁
出版社：悅知文化
ISBN：978-986-6761-90-4

本書特色：
這是一本將理論與實務作完美結合的書。以案例分析的方式，告訴讀者如何透過UML正確表達軟體設計的精神，同時搭配工具軟體與Lab單元，讓讀者可以從做中學，在練習的過程中，確實瞭解軟體開發的過程。

內容簡介：
對於軟體設計的初學者來說，面對大量的資訊，往往不知從何處開始下手。本書係根據作者多年的授課經驗寫作而成，特別針對有以下需求的讀者，提供學習的指引：

■ 想要瞭解UML及其應用時機的讀者：
本書第一部份，設計了一個完整的案例，並且將UML的十三張圖應用在該案例中，利用Q&A的方式，深入淺出地說明UML 13張圖的基本精神及其應用，讓剛開始接觸UML的讀者可以透過實際案例瞭解UML。

■ 想要知道如何在實際專案中應用UML的讀者：
本書的第二部分，設計了另一個完整的案例，並搭配工具軟體，配合UML、MDA以及實際的程式碼，讓進階的讀者可以瞭解，應該如何在實際的專案中應用UML。而且在每個章節中，都提供LAB練習，讓讀者可以「從做中學」。

■ 想要知道軟體開發團隊如何合作的讀者：
本書的第三部分，作者設計了一個團隊合作的情境，透過一個虛擬專案的進行，讓讀者可以瞭解團隊中的各個角色，以及如何挑選適合的工具來幫助自己完成工作，以及如何善用工具，讓團隊合作能夠更簡單、更順利。

■ 想瞭解Enterprise Architect如何使用：
Enterprise Architect是一套完整的UML支援工具，完整支援UML 2.1的13張圖形，並且Support多種程式語言及資料庫，且提供了非常多的客製化空間。本書主要使用該套工具進行實作，並介紹該軟體的操作及客製化技巧。

（點擊圖片鏈接看原圖）「UML 團隊開發流程與管理」新書封面完稿

※ 延伸參考：
o 「UML 協同開發管理」新書序言 Preview。
o Ringle 即將出版的新書─「UML 協同團隊合作開發」。

延伸閱讀：

「UML 協同開發管理」新書序言 Preview

Kenming Wang — Thu, 04 Jun 2009 05:38:25 +0000

Ringle 的新書 ─ 「UML 協同開發管理」，順利的話，應該是這個月就會出版了。本書的序言還特別邀請我們曾經輔導過，包括企業 IT 資訊部門主管，以及軟體開發公司教育課程培訓承辦人、專案經理等。由於先前輔導時的合作均相當愉快，且對 Ringle 嚴謹且甚為專業的能力給予相當肯定，所以請之協助寫序時，都相當樂意來背書。

我這裡就先列出該書部份的序言內容。其中也有美女好朋友們的加持，而且好不容易獲得她們的首肯，願意提供美美的照片放在序言內。不過不知道新書出版時會不會有含照片？有的話也算創舉，想必銷路會賣得更好。

~序的開始~該怎麼開始才好呢？

生平以來第一次很榮幸的接到Ringle老師的邀請，幫忙推薦~ 以小女子我的經驗：

公司在去年 (2008 年)針對技術同仁們進行一系列的Java 與UML技術培訓課程，聘請了Ringle與其顧問團隊擔任課程的專業講師，規劃長達七個月的訓練。

過程中在每次上課時看到他們用心教學及互動，課前或課後也都會互相溝通關於學員的學習狀況及如何改正微調後續的教學方向，讓我在執行時非常順利及安心。課程結束後學員們對課程的滿意度平均值也是相當不錯，所以在此特別謝謝他們對課程的用心。

同時也恭喜Ringle將教材、專案開發與顧問輔導時的經驗等等撰寫成書，對於期望應用物件導向原理於開發實務的朋友來說，一定會是一本很好的重要學習指南喔。

HiTrust 教育訓練培訓專員 Vivi Wang

「UML」這名詞，對於從事軟體設計的工作者來說一定非常熟悉，但我相信一定有很多軟體設計師和我有一樣的心路歷程，對於坊間介紹 UML 的書籍不勝枚舉，拿起這些書籍在看的當下，也許有時是懂非懂，有時心神領會，甚而也可頭頭是道的講出這十三張圖個別的用途，然而每當在開發專案欲實際應用「UML」圖形來表達各開發階段的層次時，就會開始充滿疑惑 ……

「這兩個 Use Case 的關係應該是什麼? Association? Generalization?」、「抓出來的 Use Case 怎麼像是系統功能?」、「循序圖到底要表達到多細節?畫的人好辛苦，看的人也好累!」，「活動圖表達出來的像是資料流程圖?」，最後的結果就是，畫出的UML自己也不知道對還是錯，變相為只是為了文件交差，而非開發團隊的溝通工具，完全扭曲了「UML」這個Language的用途，這是在我從事軟體開發多年來，在每家公司皆會遇到的情況。

直到任職的公司，請了 HSDc. 來輔導專案開發，在參與輔導的過程中，Ringle 將過去我對「UML」的誤解─不具實質意義的理論工具，完全導正回來，重新認識每張圖的本質意義，一步一步將真實的專案，協同開發團隊以「UML」溝通進而實作出來。

舉個例來說，以前對「Use Case」的畫法，就是拉幾個「小人形」和「小圈圈」，寫上每個「圈圈」代表的功能，再用「框框」把「圈圈」圍起來就完成了，在團隊溝通間表達出的意思就是「這個系統有哪些功能！」，更不知道「圈圈」的背後還要描述「正常流程」這回事，說起來真是汗顏，把「UseCase」的用途─使用者心中的期望，完全曲解了。

經過了 HSDc. 顧問群的輔導之後，讓我對每每陷入泥沼的軟體開發，重新有了熱情與動力，在軟體設計之餘，感嘆坊間關於「UML」與「團隊開發」的書籍總是不平易近人，也許是大師們的著作內容層次過高，讓軟體開發初學者無法心領神會的參透「UML」本質，將理論正確的實際應用在專案中。

終於Ringle在各方遊說之下，將其多年來的軟體設計及顧問輔導的經驗，集結成書，以故事性的訴說，引導讀者進入模擬的專案角色之中，步驟性的繪製出「UML」圖形，淺顯易懂的了解各種「UML」圖形的本質與繪製方式。

書中的第二、三部份再採實作方式，以案例實際帶領讀者，補捉企業流程、找出使用案例、撰寫使用案例與測試案例、實現使用案例、程式開發、部署，可確實了解完整的團隊軟體開發流程與建構管理的種種面向，閱讀起來不僅易懂更讓人有恍然大悟之感，是適合軟體開發團隊中各種角色閱讀的一本實用書。

博暉科技專案經理 Erin Fang

三年前因負責一個小型系統的發展，帶領一組團隊開發並藉此進行人員培訓，專案初期就遇到需求無法有效整理出來的窘境，專案最後雖然順利完成，心中卻埋下了一連串的問號？

需求提出者雖長期於相關領域任職，提出的需求卻是片段且不連貫。

這些不連貫的資訊要如何有效歸納為需求，才不會出現雞同鴨講的情形？

如何在分析、設計、開發的過程中，需求變動的一致性要如何維持？

專案採用物件導向程式語言，專案成員要如何迅速掌握、運用？

專案有時程壓力，要如何進行紓解，讓專案在可控的範圍內順利執行？

那些部分可以委外進行，委外同時，自身應該要做好那些準備？

…..

同時，專案過程中，會產出各式的文件。系統分析文件記錄企業的業務活動、準則、系統需求，設計文件則描繪實踐系統的方法、步驟，產出這些大量的文件需要可觀的人力，若無法達到「有效溝通」的目的，就會造成時程延宕、品質不佳、成本居高不下等現象出現，失敗的專案當然又多一個出來。

文件另一方面而言，被視為企業的重要資產，當然希望能有效的保存、運用，但常因相關主事者的習慣、喜惡而產出各種不同形式的文件，保存的方式也各有不同，降低文件的流通性及可利用性，最後散落各地。雖可作為系統維護者的參考資訊，但真正要解決問題時仍舊需要去閱讀大量的程式碼，才能確實理解系統的處理規則，維護人力也會大量增加。文件的因欠缺「標準化」、「可閱讀性」、「有效運用」…，並未真正成為企業的資產，這些都是我們嘗試要解決的課題。

偶然的機會中接觸了「信仁軟體設計有限公司」的顧問團隊，經主管的支持，邀請他們分享在軟體分析、設計、開發的心得。爾後請他們在一個小型的研究專案中提供顧問服務，藉以進行人員培訓。在為期四個月的顧問服務期間，透過運用UML塑模方式進行專案需求分析、設計、驗證等過程，確實體驗到信仁顧問團隊在整合「理論」與「實務」上的功力。

後來，我們嘗試在其它的專案上導入UML分析設計的作法，利用「使用案例圖」來捕捉客戶需求並界定系統範圍。「循序圖」來描繪系統內部的運作，產生程式碼框架，利用這些程式碼框架來做為外包開發的基礎。「活動圖」與客戶確認相關的業務流程。使用EA做為我們專案團隊的共同文件製作平台。作法上，我們並未使用UML全部塑模圖形，而以專案團隊可以善加運用的為主。文件的「溝通性」是我們所專注的重點，如果純粹為了UML而使用UML，必會產生反效果，這不是我們所樂見的。經由這些嘗試的過程，我們逐漸歸納出適用於自己專案推動的文件規範與溝通模式，成功的完成任務。

本書作者「賴信仁（Ringle）」即為輔導我們領略「理論」與「實作」合而為一的顧問之一，經過三年的時間，他將輔導客戶的心得整理成冊，透過「信仁醫院」的模擬案例，帶領讀者由「企業流程」->「系統需求」->「領域模型」->「系統結構（鉅觀與微觀）」->「系統實作」等步驟，探討UML在系統分析及設計的相關議題。全書的用字淺顯易懂，沒有技術書籍的艱深用語，反而像是在敘述一件故事的發展並且對於故事的內容分析其原由一般。

讀者可先以瀏覽的方式快速閱讀一次，然後把書放在隨手可得之處，利用空檔閒暇之時輕鬆翻閱，從萬物依存的角度來檢視「系統」、「企業」、「人」三者間存在的關連，在軟體開發的工作上能提供另一種思考的方向及層次。另外雖然本書是以物件導向的觀念來說明UML的分析設計作法，但其分析設計的手法並不一定非得拘泥在採用物件導向為開發語言的專案中，讀者可以嘗試在傳統結構式語言中加以運用變化，同樣可以清晰的勾勒出系統的全貌與領域模型。

某大物流業資訊中心軟體資深專員盧祐正

欣見軟體界一本好書出版。

Ringle 是我認識的「架構師」中一直有自己特色及獨立思考的「大無尾熊」，在與之合作之相關專案，發現其個性溫厚，包容力超強，設計實作速度快到有時候連我都不免好奇怎麼會有如此天賦，常常發現與之合作的其他架構師都遭遇跟不上他速度的窘境，直到最近難得找到另外一隻小無尾熊，一起研製成長。

在克明的鼓勵，以及我們期望 Ringle 把這上天給的恩賜的能力100%發揮出來整理成書，造福社會更多需要這門知識的夥伴後，這本「UML協同團隊開發」終於誕生。

懷著興奮的心情在拜讀這本書後，可以很輕易的發現 Ringle 係按照以架構為中心的軟體本質精神，並以案例實戰演練不斷的透過循環與漸增的方式引導讀著，以架構觀點在讀這本書時，發現該書不只是單純了理論基礎，而是經過很多實戰經驗累積而成，這是一本讓有興趣的往「軟體架構師」生涯發展的架構師們，可以真正於每次的任務或專案中實戰演練的好書。

個人欣見其努力扎根，也同時盼望與祝福軟體產業蓬勃發展，喜見其成功，特為之此序，祝賀台灣軟體產業在全世界發光發熱。

企業架構師協會台灣分會執行長宋敏如

延伸閱讀：

Kenmingの鮮思維 » 軟體開發工具

[轉貼] EA 與 Visio UML 工具比較

程式碼與 UML 類別_循序圖 的關係探討-完結 (4)

程式碼與 UML 類別_循序圖 的關係探討 (3)

程式碼與循序圖的正反向工程

程式碼與 UML 類別_循序圖 的關係探討 (2)

程式碼與 UML 設計圖之間的關聯性

程式碼與 UML 類別_循序圖 的關係探討 (1)

基礎觀念導引 － 何謂靜態與動態？

「UML 協同團隊合作開發」問題與內容勘誤回覆

「UML 團隊開發流程與管理」新書正式出版(6/12)

「UML 協同開發管理」新書序言 Preview

程式碼與 UML 類別_循序圖的關係探討-完結 (4)

程式碼與 UML 類別_循序圖的關係探討 (3)

程式碼與 UML 類別_循序圖的關係探討 (2)

程式碼與 UML 類別_循序圖的關係探討 (1)

基礎觀念導引－何謂靜態與動態？