UML Blog

虛擬寶麗來(Polaroid)

2009-07-06T19:14:00.007+08:00

看到壹周刊介紹寶麗來(Polaroid)的軟體，覺得有趣，也去它的官網下載來玩 ^^

(小滷蛋2009/6/7,20,29的照片)

世界在外面[黎智英]

2009-07-06T18:43:00.002+08:00

(摘自壹週刊第423期2009.7.2)

這個世界有完全客觀的事實，譬如科學知識便是了；卻沒有完全主觀的見識。人的思想裡充滿事實，而不單純是他個人的見解。人的見識往往是來自書本或別人的意見，即使他有自己的信念或看法，這些看法也必然融合了別人的見解而變得客觀起來，也因而更接近事實。

UML風格::易讀(三)

2009-07-06T11:43:00.003+08:00

--------------------
4. 使用一致尺寸的符號(Apply Consistently Sized Symbols)
--------------------

較大型的節點比較突出，容易吸引觀看者的目光，所以除非您真的就是要突顯某一個節點，否則盡量使用一致尺寸的節點符號較佳。

不過，這一點對UML不太適用，因為UML的節點大小通常取決於節點內部的文字，文字多些，節點就大些。譬如，圖13的使用案例圖，不是因為「查詢餘額」這個使用案例特別重要，所以橢圓圖示特別大，而是因為這個使用案例的名稱比較多字。

圖13: 不同尺寸

還好，使用案例的名稱可以選擇擺在橢圓外的下方處，如圖14所示。我個人就很喜歡把使用案例的名稱擺在外部下方，因為這樣橢圓大小一致，總覺得看起來比較舒服。

圖14: 相同尺寸

不過，UML只有少部分的圖示可以像使用案例這樣將名稱外放，大多數的圖示像是類別圖中的類別(class)、或是活動圖中的動作(action)等等圖示，就沒辦法將內部的字標外放，所以節點尺寸大小不一。

<上一篇><下一篇>

8的秘密

2009-07-06T10:47:00.003+08:00

(圖片出處：博客來網路書店)

人物往往會嚮往或抗拒追尋，若他們提議追尋，便被譽為英勇或純潔的化身；若橫身阻攔，便被刻劃為邪惡或懦弱。因此每個典型人物，常有他道德上的敵對，就像棋局中的黑子與白子一樣。[13]

對待年輕孩子最好順著毛摸，別去強壓她們。[15]

天地間的事，都有其定數與道理。[24]

以血作為賭注，絕對是邪惡的。[24]

應該了解生命中有些事物，比一時的任性來得重要。[29]

妳聽到我說的啦，那我就不打擾妳撰寫自己的墓誌銘了。[37]

沖水聲再次響起，我所有的希望也跟著一起沖下馬桶了。[39]

在生命的棋局中，卒子是棋局的靈魂，即使是微不足道的兵，也能改變局勢。[53]

西洋棋是一種非常伊底帕斯的遊戲，弒君又亂倫，就這麼回事。[94]

還沒拿到資料前就先做推論，是天大的錯誤。[142]

在任何一場遊戲中，面對威脅時，都可以選擇防守或攻擊。[176]

傳統上，撲克牌裡的鬼跟死神有關。但鬼牌亦是重生的表徵，代表人在失敗前的天真無知。[177]

最佳的防禦就是狠擊對方。[178]

文字有創造與扼殺的力量，創造人類的偉大建築師，也創造了語言。[200]

音樂不僅與我們心靈溝通，事實上，還會以一種無以名狀的方式改變我們的想法。[202]

如果你從不去愛，就絕不會有所失落。[229]

戰術是在有法可想時，知道該怎麼做。戰略則是在無可回天時，知道怎麼做。[241]

戰術是攻佔位置的短期動作，而戰略則是贏棋的長線佈局。[262]

人類若能任意說出，並做出心中所想的事，便會明白自己能如何蛻變了。[432]

UML風格::易讀(二)

2009-06-29T22:43:00.002+08:00

--------------------
3. 避免對角線或曲線(Avoid Diagonal or Curved Lines)
--------------------

眼睛追隨著直線或橫線比較容易，所以避免使用像圖10的對角線或曲線。很多UML工具都有提供簡單的線條風格，供使用者選擇，比方我慣用的免費工具—StarUML，就可以讓使用者選擇使用直線或是斜線兩種不同的線條風格，如圖11所示。

圖10: 對角線及曲線

圖11: 線條風格

繪圖時，可以假想圖面上有一個棋盤式的格線，將節點擺放在格線交錯點上，讓線段沿著格線或直或橫，避免使用對角線或曲線，如圖12所示。

圖12: 把節點放置格線交錯點上

<上一篇><下一篇>

貝親黃色小花

2009-06-29T22:34:00.003+08:00

(小滷蛋2009/6/29的照片)

今天拿貝親的黃色小花給小滷蛋玩，果然受歡迎，她啃的口水直流。不過，有時候小滷蛋會把小花甩到旁邊去，然後照舊啃起她的最愛 ><

UML風格::易讀(一)

2009-06-26T11:24:00.004+08:00

以下這十三條指南，都是為了讓我們可以輕易閱讀圖面上的資訊，降低誤判或不易閱讀的可能性。

--------------------
1. 避免交錯線(Avoid Crossing Lines)
2. 使用「跳躍」來描繪交錯線(Depict Crossing Lines as a Jump)
--------------------

上述第一和二條指南的意思是說，避免使用像圖4的交錯線，因為誤判。如果真的無法避免交錯線的話，請採用如圖5的跳躍線來表示。

圖4: 交錯線

圖5: 跳躍線

像是在UML活動圖中，複雜一些的流程，就很可能出現交錯線的情況，如圖6所示。

圖6: 活動圖的交錯線

其實，圖6的情況很常見，我是認為也不會真的嚴重到造成什麼誤判啦，只是圖面上看起來比較醜些。簡單一點的圖，可以調整成圖7的樣子，去掉動線交錯的情況。

圖7: 去掉交錯線

可是，我們來想像一下，如果出現如圖8，甚至於更複雜的情況時，很可能會有線段跨越整張活動圖。

圖8: 跨越整張活動圖

為了處理這種圖面上交錯線或橫跨線的表達問題，我們也可以在活動圖中使用「連接器」(connector)，如圖9所示。連接器的圖示是成對的小圓，小圓內部標示出連接器的名稱，或者使用簡單的代碼也可以，比方說圖9中的連接器就簡單使用"A"代碼。圖8和圖9兩張圖同義，只不過圖9使用A連接器，把原先跨越整張活動圖的線段切斷了，再透過成對的A連接器標示出連接點。

圖9: 圓形連接器

<上一篇><下一篇>

UML風格::一般製圖指南

2009-06-25T11:19:00.001+08:00

顧名思義，一般製圖指南就是所有圖的通則，無論是否為UML圖，洋洋灑灑一共有二十六條之多。原著作者將這二十六條指南分為四大類，接下來我就依循這四類區分成四個次小節一一說明之。

<上一篇><下一篇>

唱山歌

2009-06-25T11:08:00.002+08:00

(小滷蛋2009/6/7的照片)

老媽和老姐說，小滷蛋這幾天心情大好，天天自顧自地唱山歌，咿咿嗚嗚的 ^^

UML風格::章節結構

2009-06-24T11:57:00.002+08:00

這是一本200頁的小書，正文大約170頁，保證讀得完！讀小書其實很能建立信心，認真一點讀，總是讀得完。大書就不一定了，從書櫃拿下來就手軟，翻了兩頁就頭昏，電子辭典不離身，每本都讀不完，買了既傷荷包又傷心。

再者，小書也比較有詮釋與想像的空間，有留白的美感，容易引發讀者的思考；大書就不是這樣了，大書作者通常叨叨絮絮，什麼繁瑣細節都說光了，確實描寫的一清二楚，只不過少了可以讓讀者寫下感受的空間吧！這是我個人的體驗啦，所以我喜歡讀小書，當然很多時候不免還是得讀讀既傷荷包又傷眼的大書。

不過，這本書雖然篇幅少，章節可不少，共分為十七章。全書大抵可分為三個部份：前三章包含簡介、一般製圖指南及通用的UML元素指南；第四到十六章共十三章分別說明UML2的十三款圖；最後的第十七章簡單提到了敏捷建模(agile modeling)。

看完章節之後，我預計會挑讀前三章，至於第四到十七章，我只挑讀使用案例圖(use case diagram)、類別圖(class diagram)和循序圖(sequence diagram)這三章，理由很簡單，實務上用到最多的是這三款圖，其餘圖款即便我現在讀了，也會因為實務上用不到而忘記，倒不如等專案有用到時再回頭來讀。

真要開始動手整理這一條一條的指南，倒是讓我猶豫了一會兒。我私下在閱讀原文書時，會針對某些我覺得重要的句子在書頁的空白處隨手寫下簡單的、也恐怕只有自己看得懂的翻譯。現在真想把選讀的指南原文一一列出，也順便配上自己簡單的中譯時，不免猶豫了起來，雖然指南的原文句子都很簡潔，不過還是對自己上不了臺面的英文能力感到退卻。

總之，我還是會將選讀的指南原文一一列出，也嘗試著配上自己肉腳的中譯，一切只希望有助於您的閱讀。但是，也有很多條指南，我沒有按字面中譯，而是參照原文書中的說明，點出它們的重點。此外，指南前面的編號與Scott W. Ambler書上的編號相同，日後您若有興趣找原文書來閱讀的話，方便參照。

<上一篇><下一篇>

UML風格::憶往

2009-06-23T11:45:00.002+08:00

重讀這本書讓我回憶起一個專案，不過也不能算是重讀這本書，因為在此之前，我其實讀的是第一本2002年版的書，這次則是讀第二本2005年版的書。

岔題了，回頭來說我多年前輔導的UML/OOAD專案，在那個專案中，我帶領了一個六人的系統分析師團隊，其中絕大部分的人都是生手，聽過UML/OOAD但是沒有實際應用在專案中。這個專案後來夭折了，中途砍掉專案的原因當然很多，不過我倒是憶起當時我們大約每兩天就要開一次會議，一邊檢視我們的產出，一邊統一彼此的產出風格。

團隊成員會決定花時間統一產出的風格，並不是毫無緣由的。當時，一方面考量日後會加新人進團隊，有一致的風格會讓新進成員有跡可循，另一方面也考量當時訂下的風格可以成為公司正式的文件，以後公司所有的UML/OOAD專案無論是委外開發或是自行開發產出的文件內容都有一致的風格，不僅可以節省訂定統一風格的探索時間，也可以提高產出的效能和品質。

現在回想起來，如果當年大家都讀過Scott W. Ambler的書的話，應該可以節省不少開會時間吧！

不過，當時出錢的大老闆並不欣賞我們的做法，看團隊成員三天兩頭關在會議室熱烈地開著會，覺得我們在浪費時間，主事者的急功近利、眼光短淺其實是這個專案中途腰斬的最大原因。

統一風格當然是有好處的，不過這就像是建設下水道工程一般，建設平凡老百姓看不到的地方，很難爭取到選票，如同當時雖然團隊成員上下一心且投入極大的熱情，但是產出的東西還是很難說服主事者繼續掏出口袋裡的鈔票！

許多學者專家已經證明過，在專案進行中，貿然加入新的團隊成員，通常會拖慢專案進度，而非理想中的加快專案進度。當然，這個問題要認真討論起來，又要花上一大堆的篇幅了。

但是，統一風格卻是對團隊成員的擴充有幫助的。怎麼說？我想很多人都有中途加入專案的經歷，總是焦頭爛額地想在極短的時間內搞清楚產出的文件、搞清楚現在專案的進度及程序、搞清楚自己該產出什麼樣的文件、搞清楚自己該如何以最快的速度融入團隊！如果您沒有這樣會使人壓力大到胃潰瘍的經驗的話，恭喜您，不過請您現在想像一下這樣的場景。

所以說，倘若之前團隊產出的文件都有統一的風格的話，因為容易解釋與理解，所以方便現有的團隊成員解釋給新進的團隊成員聽，通常是一敎就懂。如果UML/OOAD文件雜亂無章、毫無風格的話，新進成員腦袋裡會有一堆的問號，像無頭蒼蠅般纏著現有成員不放，不僅無法盡速投入工作，還會擾亂現有成員的工作進度與心情。

總之，簡單來說，有統一風格的產出文件，能夠讓UML圖更簡明且容易了解，也能夠讓UML圖更行得通且有效能。看了Scott W. Ambler的書後，認真地調整一下專案文件的風格，這可是提升產能的第一步喔，好比許多名人懷孕前喜歡找中醫抓藥調整體質一般，調整調整之後，總是很快就聽到懷孕的好消息了。

<上一篇><下一篇>

為愛朗讀

2009-06-22T12:25:00.004+08:00

週六晚上，跟我老公跑去三重幸福戲院看「為愛朗讀」二輪片。離開電影院時，已經接近晚上12點了，走著電影院的安全梯下樓，回想起當年看鐵達尼號也是這樣，擦著眼淚走安全梯下樓。唉，女主角凱特溫絲蕾演的真好，讓我哭了好幾回。

除了電影讓我動容外，也興起想去找原著小說來看的念頭。這類的小說家真是令我佩服；只談愛情太過淺膚，光談戰爭、人性或生活也不免過於沉重或嚴肅，兩者混在一起，閱讀起來，就趣味橫生了。包裹了糖衣的藥，再苦，都吞得下…

這部片有很多面向值得探討，不過我不擅長，所以也不談太多，要是有人帶領討論這部片，倒是很值得去參與。

UML風格::書籍資料

2009-06-19T15:38:00.005+08:00

圖1: UML風格的書籍封面

《The Elements of UML 2.0 Style》一書封面如圖1所示，我在Amazon.com節錄了這本書的基本資料及評價，條列如下：

書名：《The Elements of UML 2.0 Style》
作者：Scott W. Ambler
頁數：200頁
出版社：Cambridge University Press
出版日期：May 9, 2005
ISBN-10：0521616786
ISBN-13：978-0521616782
14位讀者的平均評價為：★★★★☆
★★★★★：7位
★★★★☆：4位
★★★☆☆：1位
★★☆☆☆：1位
★☆☆☆☆：1位

Scott W. Ambler 在2005年出版的第二本書是針對UML2，因為UML2一共有十三款圖，比起UML1的九款圖，多了四款。不過，Scott W. Ambler早在2002年就已經針對UML1的九款圖出版了《The Elements of UML Style》一書，封面如圖2所示，讀者對這本書的評價甚至高達五顆星。

圖2: 舊版UML風格的書籍封面

大陸清華大學出版社有出版第一本2002年版的翻譯書，書名叫做《UML風格：口袋裡的236條UML實作準則》，如圖3所示；這是我在網路上查到的資料，倒是沒買來看。到目前為止，也沒查到大陸出版社有繼續出版第二本2005年版的書，至於台灣就沒見到有譯者翻譯這兩本書了。

圖3: 舊版UML風格的簡體版書籍封面

同樣，這是我節錄自Amazon.com的書籍資料及評價，條列如下：

書名：《The Elements of UML Style》
作者：Scott W. Ambler
頁數：160頁
出版社：Cambridge University Press
出版日期：November 18, 2002
ISBN-10：0521525470
ISBN-13：978-0521525473
9位讀者的平均評價為：★★★★★
★★★★★：5位
★★★★☆：4位
★★★☆☆：0位
★★☆☆☆：0位
★☆☆☆☆：0位

<上一本書><下一篇>

貝親綠色小花

2009-06-18T12:03:00.007+08:00

(小滷蛋2009/6/8的照片)

小滷蛋太愛吃手指頭了，上網查到許多媽媽會買固齒器給寶寶咬，讓寶寶少吃手指頭。最受寶寶喜愛的就是貝親的綠色小花了，如圖1所示。我昨天花了一整晚在找貝親的綠色小花，有人稱它為「杯型固齒器」，正式的名稱是「嘴唇訓練器」。

不過，日本製的綠色小花已經停產了，現在商店賣的多半是圖2的黃色小花，大陸製。由於，這是給寶寶咬的東西，所以許多媽媽還是建議買日本製的綠色小花比較妥當，可惜已經停產，聽說得去進貨較慢的商家詢問，看看是否還有庫存的綠色小花。

圖1：日本製的綠色小花已經停產了

圖2：大陸製的黃色小花是新款

-----
<嬰兒吮手指是智力發育信號，家長不要打攪孩子的快樂>
新華網天津2月25日電(趙津、張建新)

很多寶寶出生兩三個月，最愛做的事情是“吃手”，專家說，嬰兒與幼兒吮吸手指的意義是不同的。嬰兒時期吮吸手指是嬰兒智力發展的一個信號，是嬰兒進入手指功能分化和手眼協調準備階段的標誌之一。家長不要輕易打攪孩子的快樂。

天津市婦女兒童保健中心主任醫師李義民說，通常新生兒只會雙手握拳，胡亂揮舞，其大腦尚不能指揮把自己的手放入嘴中。到2個月至3個月時，隨著大腦的發育，嬰兒逐步學會兩個動作：一個是用眼睛盯著自己的手看，另一個便是吮吸自己的手指。對於他們來說，吮指是一種學習和玩耍。起初他們只是將整個手放到嘴裏，接著是吮吸兩三個手指，最後發展到只吮吸1個手指，從笨拙地吮吸整只手，發展到靈巧地吮吸某一個手指，這說明嬰兒支配自己行為的能力大有提高。吮吸手指動作，促使嬰兒手、眼協調行動，為5個月左右學會準確抓握玩具打下了堅實的基礎。另外，這一時期的嬰兒主要是通過嘴來了解外界，嬰兒認為手也是外界的東西，所以總愛將它塞進嘴裏吮吸感知。

李義民說，通常情況下，隨著嬰兒動作的迅速發展，他們逐步學會自由地坐、爬、站等，手指的動作也愈加精細，當長到能單獨玩玩具的時候，孩子吮吸手指的現象自然會大大減少。此外，細心的父母可以發現，孩子在吮吸手指的時候，通常是非常安靜，不哭也不鬧。實際上，有時嬰兒還以吮吸手指來穩定自身的情緒，這說明嬰兒吮吸手指對他們的心理發育也起著重要的作用。因此，對於嬰兒吮吸手指，父母不必焦慮煩惱，更不用強行制止。如果孩子的行為實在過於頻繁，父母可以經常對孩子的小手進行撫摩、擺動，以轉移其吮吸手指的注意力；會拿玩具時可把玩具放入他的手中，逗引他搖動、擺弄玩具，把嬰兒的雙手佔住，使他無暇去吮吸手指。

李義民提醒家長，家長需要做的是保持嬰兒小手乾淨，保持嬰兒口唇周圍清潔乾燥以免發生濕疹。如果孩子到了三四歲，仍然經常吮吸手指，就可視為一種不良行為，需細心了解形成原因耐心糾正。

四色原型::結語

2009-06-17T20:11:00.005+08:00

老實說，如果以使用的角度來看，直接讀Peter Coad《Object Models: Strategies, Patterns, and Applications》書中的交易樣式，可能會比較容易理解，上手所需要的時間也比較短。因為相較之下，我個人是覺得《Java Modeling In Color With UML: Enterprise Components and Process》書中四色原型的概念比較抽象，需要更多的時間理解、消化與練習，才能在實務上派上用場。

不過，話又說回來，書中所提到的61組領域特定元件其實非常值得參考，不妨將它們視為參考資料，以後遇到相同領域時，可以回過頭來查看專家的建議。

至於特徵驅動開發，除了「特徵」這個辭彙比較新鮮外，其實整體的開發程序並沒有獨特的創新處。此外，我個人是認為，任何一套開發程序都是聽起來簡單，但是執行起來問題多多呢！

最後，我到底買了這本書沒？本來打算代購了，也問好價錢了，結果UML互助會的夥伴來信告訴我他服務的機構有這本書，可以幫我代借，一個月後歸還即可。真是好消息，我心中大喜，趕忙請他代借，不僅省了1000大洋，更省了大半個月的國際郵寄時間。

後記：在這本書的讀書筆記寫完之後，大陸機械工業出版社寄送了《彩色UML建模》一書到台灣給我。我這才知道，這本書正好於2008年12月出版簡體版，真是好書不寂寞啊，書籍封面如圖37所示。

圖37: 彩色UML建模

<上一篇><回首篇><下一本書>

四色原型::開發程序(development process)

2009-06-17T11:28:00.003+08:00

簡單的開發程序，不僅可以讓團隊成員專注在產出上，而非繁雜的執行步驟上，同時也讓新進的團隊成員可以迅速融入專案。因此，特徵驅動開發只有簡單的五個步驟。請看圖36，這是Peter Coad書上的圖，我重新繪製的。

圖36: 特徵驅動開發的五個步驟

在我看來，特徵驅動開發的五個步驟化成白話文來說的話，其實就是下述五個步驟：

建立結構—參考前述的四色原型以及領域特定元件的類別結構，建構出整體的模式雛型，產出類別圖。這個步驟初始約花費專案10%的時間，後面陸續還會花費約4%的時間。
列出特徵—使用前述的特徵短句寫出詳細的特徵，同時還要訂出每個特徵的優先順序及重要性，產出特徵清單。這個步驟初始約花費專案4%的時間，後面陸續還會花費約1%的時間。
規劃進度—依據特徵清單產出專案的細部時程表。這個步驟初始約花費專案2%的時間，後面陸續還會花費約2%的時間。
設計行為—設計出動態行為，產出循序圖。此處的「設計行為」與接續的「按圖編碼」步驟，兩個步驟組成一個循環(iteration)，專案約莫77%的時間都花費在一個又一個的循環上，每次循環大約花費兩週時間。
按圖編碼—依據上述的產出編寫程式碼，以及進行測試。

以我輔導台灣專案的經驗來說，最難的是在第一和第四步驟，特別是在第一步驟，一開始就要建構出整體的領域模式，即便只是雛型，都需要對建構領域模式相當有經驗的成員才做的出來，這個步驟也通常是我輔導專案的重點。

至於第四步驟，則相對於第一步驟，如果第一步驟有高品質的產出的話，第四步驟的產出也會容易些，同時品質也會優些。所以，這兩個步驟的關鍵都在第一步驟所產出的領域模式，當然這也是Peter Coad書中花了九成的篇幅用力說明的部份。

四色原型::特徵(feature)

2009-06-16T11:48:00.004+08:00

什麼是「特徵」？特徵是一個對客戶有價值的功能(a client-values function)，並且它可以在兩週、甚至少於兩週的時間內被實作出來。特徵是一個極小的建構單元(building block)，使用者用一句簡短的話就可以表達出來。Peter Coad甚至對這句描繪特徵的話，設計了一個樣版，如圖35所示。

圖35: 特徵樣版

文句中所指的物件，就是前面提到的時間片段、角色、人(組織)地物、敘述這幾種物件。Peter Coad在書中舉了一個套用這個句型的例子—計算銷售總和(calculate the total of a sale)。

由於，特徵是個極小的功能，並且是由使用者的角度為出發點，尋求使用者能夠認知的字句。因此，不會出現「建立一個銷售交易系統」這樣的特徵短句，因為這個功能太大了；也不會出現「建立一個用例物件來控制購物流程」的特徵短句，因為在使用者的認知中，可能沒有「用例」這樣的字彙。

<上一篇><下一篇>

體態輕盈的小滷蛋

2009-06-15T15:16:00.006+08:00

(小滷蛋2009/6/7的照片)

小滷蛋今天去打預防針，順便量身高體重，上回(4/13)的身高體重是58.2cm/5.5kgw，這回(6/15)是64.5cm/5.9kgw。因為小滷蛋愛吃手指頭、不愛喝奶的結果，體重才增加一點點，真是傷腦筋呢！

我特別上網查看小滷蛋的生長發育情況，找到了甜蜜家庭疫苗網可以評量身高體重。試算的結果，小滷蛋身高介於97~75%，體重介於24~3%，是個又高又瘦、體態輕盈的小天使。

四色原型::特徵驅動開發(Feature-Driven Development)

2009-06-15T12:46:00.003+08:00

無論是企業運作或是IT技術，其變化的週期愈來愈短，在這種現況中，許多冗長、龐大、複雜的古典軟體開發程序(software development process)逐漸沒落，取而代之的是能夠提供短小精簡的開發程序，而「特徵驅動開發」(Feature-Driven Development, FDD)正打著相同的旗號，標榜為變化迅速的環境所生。

簡單來說，特徵驅動開發一開始會先花約一成的專案時間，建構出整體的領域模式雛型；接著也是花費大約一成左右的專案時間進行跟「特徵」(feature)有關的計畫；最後八成的專案時間，以每兩週為一個循環，發展出一系列以特徵為主的設計與編碼。領域模式雛型的模樣，長得就像前述所提及的現金銷售期間之類別結構。

接下來，我想討論下列兩個問題：

什麼是「特徵」？
特徵驅動開發的開發程序為何？

四色原型::現金銷售期間

2009-06-13T12:02:00.006+08:00

Peter Coad團隊發展出領域中立元件之後，將這樣的概念投入實務工作中，並且陸續找出共61組的「領域特定元件」(domain-specific component)，在書中第二章到第五章的內容範圍中，正是在說明這61組領域特定元件。

不過，我只挑選了書中的第3.2.1小節來說明，主要在談現金銷售管理(cash-sale management)中的「現金銷售期間」(cash sale session)。之所以挑選這一小節，有兩個主要原因：第一個原因是，大部分人都有接觸過這個領域，所以比較容易理解；第二個原因是，它所涉及的類別比較少、複雜度低，方便用來做為說明範例。

現金銷售管理在談「現款取貨」(cash and carry)的情況。例如，我經常去二手書店買書，店裡通常只收現金、不接受信用卡、而且免開統一發票，諸如此類一手交錢一手交貨的現金交易，就適合採用現金銷售管理裡頭談的領域特定元件。

現金銷售管理細分為兩個子套件(package)：現金銷售期間(CashSaleSession)與現金銷售(CashSale)，如圖31所示。

圖31: 現金銷售管理套件

兩個子套件裡頭只有三個時間片段類別為：現金銷售期間套件中的收銀機作業類別(CashSaleSession::CashDrawerAssignment)、現金銷售期間類別(CashSaleSession::CashSaleSession)，以及現金銷售套件中的現金銷售類別(CashSale::CashSale)，如圖32所示。

圖32: 時間片段類別

61個領域特定元件彼此之間是有關係的，所以除了套件本身內部的類別外，還可能連接其他套件的類別。請看圖3，這是現今銷售期間套件內部的類別結構，這個套件內部定義了三個類別，分別為：收銀機作業(CashDrawerAssignment)、現金銷售期間(CashSaleSession)與收銀機(CashDrawer)。除此之外，它們還連接了現金銷售套件內的現金銷售類別(CashSale::CashSale)，以及關係管理之個人角色子套件下的收銀員類別(RelMgmt::PersonRole::Cashier)。

圖33: 現金銷售期間

根據圖33的類別結構，我們假想出如圖4的情境圖，用假想情境來解釋抽象的類別圖，條列說明如下：

假設，邱郁惠是一名二手書店的收銀員。
邱郁惠在9/29上9:00~下午6:00以及9/30下午6:00~晚上10:00，都有操作收銀機處理銷售交易，所以在圖3中收銀員與收銀機作業之間為一對多的關係。
二手書店有兩台收銀機，邱郁惠在9/29上9:00~下午6:00以及9/30下午6:00~晚上10:00剛好都被分派使用到1號收銀機，所以在圖33中收銀機與收銀機作業之間為一對多的關係。
二手書店將整日的銷售期間分為上午、下午及晚上三個時段，所以說，邱郁惠在9/29日值了上午及下午兩個時段，而9/30日則值了晚上一個時段。參照看到圖33中收銀機作業與現金銷售期間之間為一對多的關係。
二手書店的生意很好，所以每個現金銷售期間都會發生多筆的現金銷售交易，所以在圖33中現金銷售與現金銷售期間之間為一對多的關係。
至於，圖33中收銀員與現金銷售期間之間的一對多關係，可以從收銀員與收銀機作業之間的關係，推衍得知。
還有，圖33中收銀員與現金銷售之間的一對多關係，也是可以從收銀員、收銀機作業與現金銷售期間三者之間的關係，一路推衍得知。

圖34: 情境圖

至於，圖33類別中的屬性(attribute)與操作(operation)，我就不加以解釋了。一方面，因為不同的現金銷售專案可能都不盡相同。不過，您要是有空或者有需要使用到的時候，還是值得花一些時間推敲推敲的。

另一方面，書上其實並沒有對每一個類別以及其內部的屬性、操作做詳細的說明。或許，Peter Coad認為只要是這個領域的讀者都可以輕易理解這些類別結構，所以真要將這些類別結構用在實務上，還真得花些時間多多推敲推敲才行。

<上一篇><下一篇>

《寫給SA的UML/UseCase實務手冊》序

2009-06-11T18:18:00.007+08:00

原本這本新書要叫《UML/UseCase做中學》，不過出版社覺得之前的《寫給XX的XXX實務手冊》名稱比較經典。我是認為，只要書名明確就可以了，所以這本新書可能會叫《寫給SA的UML/UseCase實務手冊》。這讓我聯想到，阿諾演了「魔鬼終結者」紅了之後，以後他演的片子中譯名稱都稱為「魔鬼XXX」，像是「魔鬼孩子王」!><

-----
「許多觀念必須在做中學習，適時地給予機會教育」，這是我一開始寫這本書時，想要呈現給讀者的。所以，在這本書中，我特別模擬了一個小型兩人團隊的運作情況，有些詼諧地、有點趣味地，適時點出什麼時候該運用什麼樣的技術？在使用的過程中，又會發生什麼樣的問題？而這個問題，兩人又用了什麼方法解決？最後，兩人小組運用了書上所教的技術，討論出一個包含了數個次系統的書局系統。

俗話說，萬事起頭難，確實如此，寫每一章的基礎小節時，是最難的時候。我總是得氣定神閒地坐下來反問自己：如果我是個讀者，我沒有太多時間聽你(作者)說閒話，你就只要先教我最必要的一招半式，等我先去闖蕩江湖之後，不足了，再回頭甘願聽你長篇大論、嘮嘮叨叨。

也就因著這樣的構想，我在每一章的小節標題前都區分了「基礎、案例、進階、習作」這四個主題。在我的構想中，讀者先讀完基礎篇，學了一招半式；然後跟著兩人小組進入案例篇，去闖十八銅人；挨了打，再回頭過來，進入進階篇，多點耐心多學些。最後，如果是學校學生，可以進入習作篇，為自己找個練習場，自己也去闖蕩闖蕩。

挑選書局系統做為案例，實在是因為它比較通俗，但是其實它也是一個最典型的電子商務系統，讀者看到這個系統之後，很容易可以應用到自己手上的電子商務系統。而且，特別不同的是，大部分的UML/OOAD書籍不使用大型系統做為範例，但是我為了重現真實專案中遭遇整合其他現存系統的情況，所以讓這個書局系統規模變大，讓它可以整合其他系統，也更為貼近真實的狀況。

在案例篇的規劃上，是一個連貫的案例，由W和R兩人領銜演出。兩人從一開始接到一個書局系統的案子，在對案子範圍模模糊糊的情況下，就開始動手建立使用案例模式，並且應用使用案例點的技術來估算工時。由於，這本書的主題涵蓋了估算工時的技術，所以除了一般的IT技術人員之外，UML/OOAD專案經理也是這本書的預設讀者。

話說我的第一本書《寫給SA的UML/MDA實務手冊》除了在業界廣受好評外，還陰錯陽差地成了許多大專院校的學校用書，銷售一鳴驚人，也因此好幾位出版社的編輯便期望我能再寫本暢銷的學校用書。

我沒當過學校老師，不過卻當了許多年的業界講師。我通常把學員當成新書的預設讀者，為他們編寫教材，透過文字來傳道、授業、解惑也。只是沒想到，這樣的書，也同樣受到學校教授和學生的喜愛。令我受寵若驚！同樣地，這本書，也為了業界與校園的讀者們而寫，希望能夠再一次深入淺出地傳達UML/OOAD的理論觀念與實務經驗。

-----
第1章繪製使用案例圖
1.1【基礎】使用案例技術的定位
1.2【基礎】一睹使用案例的長相
1.3【基礎】繪製使用案例圖
1.4【案例】書局系統
1.5【進階】系統內部啟動的使用案例
1.6【進階】UML風格
1.7【進階】用活動圖來抓使用案例
1.8【習作】動手做
第2章編寫使用案例敘述
2.1【基礎】使用案例敘述
2.2【基礎】主要流程與替代流程
2.3【案例】書局系統
2.4【進階】呈現風格
2.5【進階】詳細程度
2.6【進階】站在巨人的肩膀上
2.7【習作】動手做
第3章建立使用案例關係
3.1【基礎】包含關係
3.2【基礎】擴充關係
3.3【基礎】一般化關係
3.4【案例】書局系統
3.5【進階】UML風格
3.6【進階】登入的問題
3.7【進階】新增/讀取/更新/刪除的問題
3.8【習作】動手做
第4章切分次系統使用案例
4.1【基礎】什麼是「次系統使用案例」？
4.2【基礎】架構樣式
4.3【基礎】切分次系統使用案例
4.4【案例】書局系統
4.5【進階】串起次系統使用案例
4.6【進階】定期檢視
4.7【習作】動手做
第5章估算工時
5.1【基礎】估算工時
5.2【案例】書局系統
5.3【進階】循環式開發
5.4【進階】交易樣式
5.5【習作】動手做
第6章接下來可以怎麼做
6.1【基礎】少不了三王一后
6.2【案例】書局系統
6.3【進階】尋找類別與物件
6.4【進階】物件導向分析
第7章 StarUML操作說明
7.1 StarUML的特色
7.2 開啟一個新的專案
7.3 開啟或新增UML圖
7.4 繪製使用案例圖
7.5 繪製類別圖
7.6 繪製循序圖
附錄A 書局系統
A.1 組合式架構示意圖
A.2 書局系統
A.3 網路書局
A.4 客服次系統
A.5 付款次系統
A.6 其他次系統
附錄B 實用小工具
B.1 繪製使用案例圖
B.2 編寫使用案例敘述
B.3 建立使用案例關係
B.4 切分次系統使用案例
B.5 估算工時

精彩生活，自己創造

2009-06-11T11:35:00.002+08:00

(摘自30雜誌2009年6月號)

人生短暫，不能等待，實現理想，無可取代。

我們沒辦法控制人生，只能創造回憶，你要先自己開門，喜歡自己的工作，才有可能作得比別人好，更能面臨大的變局。

聽說金魚的記憶力，只有3秒鐘，牠只要繞魚缸一圈，又是一個新的世界，人要學習金魚的記性，常常忘記不開心的事。

讀一本課本是不夠的

2009-06-11T11:31:00.002+08:00

(摘自天下雜誌第418期2009.3.25-4.7)

從大腦和記憶的研究來看，廣泛閱讀的效果較好，因為記憶是個熟悉度，常用字的神經迴路連接得比較緊密，記憶比較好，同時，因為它反覆在不同情境下出現，這個生字的正確用法可以透過內隱的學習而得之...

一個單獨出現的生字不及在文章中出現時記得牢，因為故事內容提供了更多的提取線索。

閱讀最忌一直停下來查生字，它會中斷閱讀、喪失學習的樂趣。

香港的學校沒有使用注音符號，他們是一開始便廣泛閱讀，透過閱讀認識生字，變成熟字，更透過閱讀，掌握這個詞的正確用法。

佐藤可士和的「創意整理學」

2009-06-11T11:22:00.003+08:00

(摘自天下雜誌第413期2008.12.31-2009.1.13)

「減」比「加」更能貼近事物的本質。

強調「減」比「加」更重要的創意管理，以釐清事物本質，讓創意發揮最大成效。

從事設計最重要的元素，就是「清楚的概念」、「小說般的敘事能力」、「兼具邏輯與美感的構圖」，左腦與右腦並用，缺一不可。這些，都必須靠善於整理的工夫。

桌面的整潔度，跟工作效率成正比。因為，一個人的桌面，顯示他的大腦所呈現的狀態；桌面愈亂，表示這個人思緒愈混亂，對目前手邊的工作難以掌握進度與品質。

如果看過的資訊卻記不住，這跟從未閱讀那項資訊根本沒兩樣。

決定觀點，才能打開一扇窗，從窗外看見風景。因為，「客觀」與「沒觀點」是兩回事，接收資訊時，如果沒有在過程中確立觀點，就只是把所有的資訊堆在腦子裡，難以消化，到最後什麼都記不住。

轉換觀點，從各個角度觀察，包括當事人、對手、第三者。

腦中蒐集大量資訊之後，最後、也是最重要的一步，就是如何透過思考，把這些資訊分析整理，成為可行的新概念。

培養「將思緒轉化為語言」的能力非常重要。如果能將腦中的想法轉化為語言表達，有用的資訊會被過濾出來，然後以有邏輯、有條理方式加以整理，思緒自然就清明了。

一般人該如何找到自己的「第二雙眼睛」？透過廣泛的閱讀，透過跟自己不同「型」的人討論溝通，都是方法。如果永遠只閱讀自己喜歡的書籍、只跟自己想法相近的人交往，那就永遠跳脫不出現有的框架，也就難以出現新的創意。

產品不只是產品，它出自你的思考與雙手，代表著你看世界的觀點與態度。

四色原型::交易樣式(Transaction Patterns)

2009-06-10T11:17:00.005+08:00

書上提到，早在1992年9月，四原型的概念就被刊登在《Communications of the ACM》雜誌的“Object-Oriented Patterns”一文中，且於1995~1997年間出版的《Object Models: Strategies, Patterns, and Applications》一書中被擴大應用。

不過，1992年剛提出四原型概念時，並未加入顏色建模的概念，一直到1997年Peter Coad團隊才開始採用四色建模的方式。或許也正因為如此，所以《Java Modeling In Color With UML: Enterprise Components and Process》一書才得以在1999年問世，讓我們再次見到四原型加顏色建模的創意。

也就是說，雖然《Java Modeling In Color With UML: Enterprise Components and Process》一書比《Object Models: Strategies, Patterns, and Applications》晚出版，可是這本書中的四原型概念比交易樣式的概念還要早出現，交易樣式只是後生晚輩，拿四原型的概念來應用罷了。

進一步來說，Peter Coad在書中除了談到四色原型外，同時將這四色原型兜起來，形成一個更大更複雜的類別結構，稱為之「領域中立元件」(domain-neutral component)，局部如圖29所示。

圖29: 領域中立元件

其實，我一見到書中的領域中立元件便覺得熟悉，因為它跟交易樣式的結構十分相似，局部如圖30所示。所以我推想，交易樣式非常可能是參考了領域中立元件的結構，然後再進一步提出關於交易樣式的見解的。不過，本文的重點不在交易樣式，所以理解它跟四色原型之間的關係即可，我們就不再細究交易樣式的內容了。

圖30: 交易樣式

<上一篇><下一篇>