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

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

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

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

  • 動態產出:設定 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)

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

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

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

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

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

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

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

範例-靜態的程式碼設計契約
範例-程式碼與類別圖的對應關係

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

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

類別圖無法作到 …

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

閱讀全文 »

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

基礎觀念導引 - 何謂靜態與動態?

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

閱讀全文 »

[3/27,28] HSDc. 讀書會與課程活動剪影

上個星期六、日,我們團隊連著兩天舉辦了「讀書會」與「單元課程(一日遊)」等活動。

星期六,讀書會場地是選在位於通化街的「曼德主廚私房料理」。一邊心得分享與研討、同時可以享受飲食與咖啡下午茶,這樣也比較輕鬆沒有壓力。
[讀書會] @曼德主廚私房料理

閱讀全文 »

[冷笑話] 咖啡是素的耶 !?

我已經算是生活白癡了,對生活日常的細節,不用心也不是那麼在乎。不過,我們團隊那個 Cathy,更是白癡中的白癡 (指生活)。

舉一個例子,有次我們在客戶單位顧問輔導,因為下午挺沉悶的,所以還特別下去咖啡廳點了咖啡上來。為了暖暖氣氛,我就裝作很驚訝的說: "Cathy,我們點的咖啡是素的耶!!"

真的耶!! 我們喝到素的咖啡耶。Cathy 很天真又很驚喜的回答。

然後那個輔導單位的妹妹們都面面相覷,一幅怎麼覺得是兩個白癡的對話。其中一位忍不住說道:「請問咖啡有葷的嗎?」

Cathy 真的是有夠天真的回答說:「有啊,加了肉桂不就是葷的嗎?」

哇哩勒! 肉桂 (Cinnamon) 是一種月桂科的長綠植物;肉桂粉(俗稱玉桂粉)是以桂樹的乾樹皮以及磨成粉末狀,可作為西式烹飪與咖啡調味用。

不過,到底真有沒有葷的咖啡呢? 我也不敢武斷的肯定啦。我還在想,若是有人研發出加了肉燥的咖啡,不知道味道如何呢。 😉

別出極具創意的新年賀卡-UML 13張關連心智筆記圖

過年前,我們團隊 (HSDc Inc.)所舉辦的 [UML 2.0 觀念引導與實務操作入門] 課程,約有近 20位學員參加。其中,有一位相當高恌的女孩子就坐在最前座,上課的時候總是相當專心聽講作筆記。

我在講課時總是喜歡採用反問的方式,藉以引導學員可以思考我所提問問題背後的涵意。大部分學員總是會有些怕怕,也比較不敢表達出自己的想法,但這位女孩子卻是可以回答出令人相當滿意的答案,讓我相當的佩服;更為訝異的是,在下課時與她閒聊,才知道她還只是撰寫大型系統的程序性古典語言,也沒有寫過 Java or .NET 等 OOP 語言。但是,我可是真的覺得,她對物件導向的設計哲理,相當具有領悟力,也很肯去反思,俱足軟性思考的頭腦。

對於這樣聰慧、具 Smart 特質、又肯主動學習的學員,除了讓我印象深刻外,我更是願意就我所能,引導與分享對於軟體設計領域上的觀念與學習技巧。

就在想說,年後我們團隊若有一些研討活動 (如讀書會、研討會)等,準備邀請該位學員來參與。沒想到,就在除夕春節前,這位學員還主動寄了一封新年賀卡給我們。除了新年賀節問候外,也說出了她對這次上 UML 課程的收獲與心得,真的很感心~

更特別的是,附檔的新年賀卡是她利用 PowerPoint 設計的。內容竟然是把兩天課程所介紹 UML 13張設計圖,它們之間的關聯、特質與應用時機等,給全串在同一張圖內;還畫了虎年到來、新年迎春饒富過年氣氛的插圖。
Sharon 的 UML 新年賀卡

哇!! 這麼別出心裁、這麼有創意的新年賀卡,又是如此的用心製作 (必然要耗費很多時間),我收到這樣的賀卡真的是相當開心,也相當感動。更是覺得,這麼棒的作品,要不分享出來給眾讀者們欣賞,那真是太可惜了。所以,我還特別寫了信徵求該位學員的同意後才特別公開。

對啦,她的名字叫 Sharon,這樣直接稱呼也比較方便勒。另外這裡同時也公開她的網誌應該沒有問題吧? 看看她寫的文章,文句優雅頗具知性,會讓人以為她是一位柔弱感性的少女呢;但是,再瀏覽她整理的網誌相簿,呼,Sharon 可還是一位熱愛潛水的陽光健康女孩呢。 🙂

 o http://blog.yam.com/sharontaiwan
 o http://sharonwang.myweb.hinet.net/

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal