如果我是某大軟體公司的主管，要應徵軟體結構性的設計人員 (偏對技術性，而非需求分析)，一般的職稱是稱之為 系統設計師 (SD, System Designer)，或者號稱為架構師 (Architect)、資深技術人員等。 若他們在履歷表上寫著擅長或懂 "O-O (Object Oriented)" 或 "UML"、結構設計 等，那麼，我不會考他們什麼 UML 語法還是 設計樣式 (Design Pattern) 等等。 那只是 "背書" 而已，一點意義都沒有。 要背書的話，不如直接給個電腦上網，然後要應徵人員展現如何透過 Google 查詢找到如何實做設計樣式的方法還比較實在。
我會提供的考題，必然是針對應徵人員 "自我思考推理" 的能力驗證，答案的正確性完全不重要，重要的是你為什麼是這樣表達設計的，能否自圓其說。 具有獨立思考能力的設計師，這才是人才！
所以，我會提供一個如這樣的考題：
Google 書籤 (bookmark)是利用 標籤 (Tag)來作分類的。 一個書籤可以被 "標記" 為一到多個標籤，相對來說，一個標籤可以有一到多個書籤。 另外，標籤是不會含有子標籤 (Sub-Tag) 的。
如果我要改良 Google 書籤的設計，希望能再加上 "資料夾 (folder)" 的管理觀念，也就是說書籤必然會 "放" 在某一個資料夾目錄內 (也只能是唯一)，而某一個資料夾可以擁有一到多個書籤，同時資料夾也能再包含子資料夾 (Sub-folder)。
同樣類似的應用，可以延伸至部落格 (Blog)的本文 (Content)與標籤、目錄 (category)的結構設計。
請你利用 UML 類別圖，來表達出關於 書籤、標籤與資料夾的結構關係，並簡單說明你的設計想法。
上述的考題是一個 "需求陳述"，應該算是蠻普遍的一般應用常識了。 不過若還是不懂上述的敘述，那麼也可以再佐以範例，來解釋什麼是 書籤、標籤與資料夾的概念。
老實說，我是以為，這類的結構設計應該算是很基礎的了，事實上，答案也比想像得意外簡單。 但是，我也問過好幾個號稱對所謂 設計樣式 很熟悉的資深技術人員，最直接給我的答案就是說： 這不就是 "複合結構 (composite structure)" 樣式的應用嗎？ 不管你說什麼，反正先把設計圖畫出來再說吧。 結果呢，也真的如我所料，表達不出所以然，真的就只是在背書而已。 最大的盲點，就是把 標籤 (Tag) 與 資料夾 (folder) 給關聯在一起，而其實這兩個是一點關係都沒有的；甚至有些還執著在因為 標籤與書籤 的多對多關係，所以又拉出了一個所謂的 "關聯類別 (Association Class)"，卻又說不所以然，越弄越複雜。 因為既然是表達想法，所以類別圖自然是表達 概念 (concept)與概念之間 的關係，而至於那個多對多的關聯類別，是在更細節性的規格設計實做階段再來討論即可，太早論及，反而模糊了要突顯的概念。
表達這類結構性的設計圖，要先找出核心的類別是什麼。 在本例中， "書籤 (bookmark)" 即為本文主體，是最根本的核心類別。 再來當能分別出 標籤 與 資料夾 並沒有關連，而是各自與 書籤 建立關係，那麼，這個設計的表達就可以說對了一大半以上了。 參考的 UML 類別設計如下圖：
閱讀全文 »
