[StarUML] 新增一個 MDA Approach 樣版

試用過幾個免費UML工具，個人感覺使用StarUML較順手，搭配還不錯用的MDA，只是每次開新專案時，都必須重新建立一次MDA樣版，有點麻煩，於是起了自己建立一個預設MDA樣版的念頭。

Approach就是一個專案的概略樣板，在開啟StarUML時，他會問您"new project by Approach"，讓您選擇要使用何種樣板建立專案，我的目的就是要在這裡加一個MDA的Approach，如下圖所示多了一個MDA Approach：



StarUML是一套OpenSource的軟體，所以他的開發文件裏有提到建立一個Approach的方法，有興趣您也可以去官網下載研究，他只要編寫一個XML文件，再複製到Module目錄下即可，目前我只做出精簡的MDA樣板，有時間再來深入研究研究。開啟MDA Approach後的畫面如下：



另外Approach的XML文件不支援中文，所以只能用英文。當我翻閱開發文件時，得知StarUML是使用Delphi開發的時候，剛好我很熟這套IDE，所以嘗試拿它的Source Code來改看看，無奈他使用的某些元件裝不起來，只好暫時放棄，以後再研究研究。

點這裡下載MDA.zip

壓縮檔中包含一個MDA目錄，解壓縮後將MDA目錄直接複製到StarUML的安裝目錄下的approaches目錄即可，例如：

C:\Program Files\StarUML\modules\staruml-standard\approaches\

再重新啟動StarUML即可，這樣新建立專案時，就能直接以MDA樣版建立專案。

[Class Diagram] 參數方向 out 與 return 的不同

參數方向是指參數傳遞的方向，當我們要宣告一個函式(Function or Method)時，必須一並定義出參數的名稱與型態與方向，讓程式設計師在呼叫函式時有個依循的方向，所以UML在參數傳遞上定義了4種方向：

1. in－輸入參數
2. inout－輸入參數後，再將結果輸出。
3. return－回傳參數
4. out－輸出參數

這四種方向明確指出參數的行為特徵，分敘如下：

第一種in輸入參數，其實就是指Call by Value，這個一定會用到，應該不用解釋了。

第二種inout其實就是指Call by Reference或Call by Address，這個也很常用。

第三種retrun就是函式回傳值，也是絕對少不了的。

第四種out就比較少用到了，而且它跟return一樣都是用在輸出數值，可能會讓人搞不清楚有什麼不同。

在我使用的Delphi(pascal語言)，參數就有宣告為out的用法，C/C++、Java或其他語言有沒有這種用法我就不清楚了。其實out與return在使用目的上是一樣的，都是在回傳數值，只是在於用法的不同而已。James Rumbaugh在「The Unified Modeling Language Reference Manual」書中有這麼段說明：

outAn output parameter. There is no input value. The final value is availabel to the caller.
return
A return value of a call. The value is available to the caller. Semantically, no different from an out parameter, but the result is available for use in a in-line expression.

他指出了兩者的不同在於：out是一種輸出參數(output parameter)，是以參數的型式回傳數值；return是一種回傳數值(return value)，以數值的方式回傳。

return是一種數值回傳的方法，所以在函式結束時，必須回傳數值給呼叫者，這種回傳方式只要宣告型態，不需要宣告名稱，而且回傳值只能宣告一個，在C/C++和Java指的就是保留字return的用法，例如(C/C++)：

int methodA(int i, int j)
{
//do something
return 2;
}

紅色int是宣告這個methodA在結束時，必須回傳一個int型態的數值，而藍色return 2則是回傳一個int型態的值=2，這是典型的回傳數值的用法。

而out它是一種參數型態的回傳方法，使用上他是宣告在參數區，有參數名稱與資料型態，而且可以有很多個，需要幾個就宣告幾個，例如(delphi/pascal)：

function methodA(i: integer; j: integer; out r: integer): integer;

藍色integer宣告這個methodA在結束時，必須回傳一個integer型態的數值給呼叫者，與前面的return例子是一樣的。這裡要解釋的是在參數區多宣告了一個r參數，並宣告方向為out，表示這個r參數目的僅用在輸出數值，不需要對它傳入數值而已。

out在用法上與Call by Reference是一樣的，或許有人會說，那就使用inout就好了，何需要多此一舉呢。其實還是有不同的，inout雖也能輸出數值，不過在呼叫函式時，宣告為inout的參數要先賦予初始值(不論宣告的是基本型態、物件參考或指標等任何有意義的值)，表示函式需要先使用此變數。而out則不用賦予初始值，前面James Rumbaugh已經提到了，只要宣告一個變數去承接回傳值即可，這是inout、out兩者不同的地方。參數方向講到這裡out與return反而容易分辨，容易混淆的是在inout與out呢。

inout與out這樣區分應該是要讓語言使用上更明確與嚴謹，若呼叫函式時，必須賦予初始值給函式使用，而函式處理完畢會改變變數內容，那就使用inout。若呼叫的函式僅要回傳數值那就使用out。我在實務上out也完全沒用過，都是直接使用Call by Reference，其實這沒有對錯，可以完成任務就好。換個更嚴謹的說法，設計文件上只要明確指出參數的方向，Programer就算都只用Call by Reference，也能清楚的知道函式需不需要使用到該參數，進而決定要不要輸入數值。

我想到有個地方可以用的到，當我們要定義一堆API時，通常API的訊息代碼(message code)會用return回傳，若API還需要回傳更多參數或物件時，就可以使用out來回傳。

註：
文章有引述到uml-blog著作及相關書籍的部分內容，若有侵權請告知。

[書籍] 寫給C++程式設計師的UML實務手冊

這本”寫給C++程式設計師的UML實務手冊”『以下簡稱UML4C++』主要的重點是：以實例說明UML轉換成C++程式碼的過程。

UML4C++承襲作者一貫輕鬆風格，以簡單的實例解說過程，沒有複雜的圖形，沒有艱深的程式碼，圖文對照，有OO(物件導向)概念很快就能掌握箇中精髓。對剛踏入程式設計師這條路的人來說，直接接觸此書一定會非常有Feel，當然本書針對的對象就是程式設計師，除了了解程式設計師會接觸到的幾張UML外，還能幫助程式設計師去體會系統的設計理念。書中的實例採用基金系統，我想應該是考量到所有人或多或少都有接觸過基金，至少也大致了解流程，優點就在這裡，閱讀過程中，很自然的就會自己預先思考下一步驟，達到有效引導作用。

另外UML4C++書名雖是針對C++程式設計師，個人感覺不是這樣的，只要有OO概念的程式設計師都適合閱讀，比方說我的OO概念是學Java時奠定基礎的，但是卻是在Delphi上運用，書中將OO概念運用到C++上，並不會對我造成障礙，我想對使用其他語言的程式設計師來說，應該都不會是問題。

UML4C++對系統分析師也有相當程度的助益，對剛入門系統分析師的人，能幫助了解程式設計的邏輯，避免設計成”摳”不出來的系統。由程式設計師轉型為系統分析師的人，更能區分出兩者思考模式的差異。我就是那種剛要轉型為系統分析師的人，當我在學習系統分析設計時，最常遇到的困難就是無法跳脫程式設計師的思考邏輯，想著想著不自覺腦中就跑出程式碼，結果就變成由腦中的程式碼畫出UML圖，那耶安捏，這根本就是逆向工程嘛，不過看過本書後比較能體會系統分析師與程式設計師之間的差異，作者研究UML十多年，經驗豐富，最了解其中的差異，兩者之間的協調問題，UML4C++已經幫我解答了部份疑問。

至於UML4C++缺點也是有啦，就是太簡單啦，哈哈～好像就是如此，UML4C++讓入門變簡單了，真正實做時一定會有問題跑出來的，不過這是經驗問題啦，若遇到問題可到作者的UML Blog發問，作者是個對UML非常熱情的人，她一定會熱心的為您解答。

後記：

2007年底作者邀請我寫一篇感想，有點受寵若驚，因為以前聯考我的作文分數大概都只有15分耶，不知道自己寫出來的東西能看嗎？不過在作者的鼓勵下決定試著寫一篇心得報告，原本計劃要在2008年元旦假期後刊出的，不幸的是在跨年夜發生了爆炸性的意外(請參閱2008跨年夜驚魂記)，腦震盪外加聽力受損，一直拖到最近才完成，實在是對作者感到不好意思啦。

[書籍] 寫給SA的UML/MDA實務手冊

會接觸到這一本書，其實是因為我正在研究RUP入門，在網路上搜尋資料時，誤闖作者的UML Blog，而發現的一塊寶地，在裡面挖到了不少寶貴的知識，對我這初學者來說，實在是珍貴無比，所以囉，入寶山豈有空手而回的道理呢，恩～作者會不會告我闖空門阿？

言歸正傳，因為我是初學者，我就以初學者的角度來看這本書，作者在書中用輕鬆有條理的口吻來說明案例流程，每個步驟都清楚的交代，還有完整的範本，蠻適合初學者閱讀的，初學者在學習上最困難的地方，就是在如何運用，有時候看了一堆書籍，明明道理都懂，實務上卻不知從何入手，也許要再花上幾年的琢磨，才能真正體會到竅門，現在作者將多年累積的經驗集結成冊，有了這本書的幫助，對想入門SA的朋友來說，等於已經是把釣魚的方法公佈出來了，所謂：「師傅領進門，修行在個人」，剩下的就看個人的造化了。

延續上面釣魚的例子來對照：

釣魚前的準備工作<=>開發流程與風險管理的理論

釣魚的方法 <=> 寫給SA的UML/MDA實務手冊

釣竿 <=>輔助工具

魚<=>客戶口袋裡的$$

因為我稍微看過一些開發流程理論，再來看到這本書，會發現原來那些理論實現方法是可以這樣做的，有種茅塞頓開的感覺。反過來說，如果沒有這些理論基礎的人來看的話，或許可以給初學者很大的信心，但是我認為實務上可能反而會帶來嚴重的挫折感，因為在開發專案時，會牽涉到需求變動與風險管理等問題，就像前面釣魚的例子，我知道釣魚的方法(寫給SA的UML/MDA實務手冊)，也有釣竿(輔助工具)，而我要去海釣的話，還要清楚漲退潮或季節與魚餌等問題(風險管理)，才有可能滿載而歸。關於這方面書中只有提到一點點，真的很小一點，我想這方面或許可以再加強一點，或者說在書中提醒讀者在看這本書之前或之後，再吸收一些相關知識會比較完整一點。