Kenmingの鮮思維

這一份 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 小姐所整理出來的比較表：

繼續閱讀 »

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

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

HSDc Seq. Generator plugin 操作示範

1. 安裝 Seq. Generator plugin

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

繼續閱讀 »

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

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

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

• 動態產出：設定 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 設計圖之間的關聯性

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

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

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

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

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

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

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

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

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

類別圖無法作到 …

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

繼續閱讀 »

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

靜態結構 (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)的應用程式。
• 資訊系統履行軟體人員的設計契約，使之可以在其平台上執行。

繼續閱讀 »

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

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

• 43頁：
  一般化關係：是不是應該說明一般、特殊化關係的方向性？
  整體-局部關係：聚合跟組合的圖看起來都是實心的。
• 44頁：
  相依性關係：圖示錯了。
• 45頁：
  圖3-2的內容跟前面訪談結果不一致，特助有說跟住院事件相關的人員：醫生、護士、櫃台人員，但是類別圖卻沒有櫃台人員。

Ringle 的回覆如下：

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

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