UML物件裏的Generalization

在 UML 裏，有一種關係叫 "Generalization"。一般而言，我們把這個關係當作物件「繼承」的表達。不過，在此之前，一直對 "Generalization" 圖示的方向性有疑惑：為什麼他的方向是從 "子類別" 指向 "父類別" 呢!?

很早以前，大概從高中剛始，自己對哲學就一直很有興趣，還曾一度想以哲學系為目標；只是因為自己對科學"更"有興趣 (也有未來出路的考量)，所以選了電子系。然而，自己對哲學的興趣一直沒有消失，所以大概從三年前開始，跑去洪建全基金會上傳佩榮教授的「西洋哲學」課程。這個課程，對我有很大的幫助；其幫助不是在人生觀或人生態度的建立，而是在「思考過程」的進步。是的，我特別強調了「思考過程」這個概念，這個概念表意著一個「活動」，而這個活動體現了我的「存在」...

上面那一段其實是廢話。我在學哲學的時間，跟我在學 UML 的時間差不多剛好重疊；這也讓我在學 UML & OO 時，有了一些與他人不同的思考視野 (也不知道是好還是不好)。針對本文一開頭的問題來說，一般多數的"華語"人士，大概都是這麼解釋：「祖先不知道子孫的存在，可是子孫卻知道祖先的存在...」(此段文句取自 "OCUP UML初級認證攻略"；另外，我大學時的 C++ 老師也是這麼解釋)。

一般而言，這樣說應該也沒錯，而且，知道怎麼用就好了，不是嗎?? 不過呢，在我上過哲學課程之後，我卻對 "Generalization" 有了些不同的看法。引述一段黑格爾 (Georg Hegel) 的話：「An idea is always a generalization, and generalization is a property of thinking. To generalize means to think. 」。我想，應該很少人知道 "Generalization" 在哲學領域裏所代表的意思 (大概也沒人像我這麼無聊吧!?)。這裏留下 Wiki 的連結：Wiki百科 - Generalization

我想說的是，正因為 UML 想表達的是 "Generalization" 而不再是 "Inheritance"，所以箭頭方向會從子類別指向父類別；從 "實體(implementation)" "抽出(generalize)" "概念(notion)"。而這樣也更能表達英美實證主義哲學，其 "由實體歸納出概念" 的思考方向...(上面這一段文句，我還不知道該怎麼描述比較好...)。好啦，我的意思就是，"Generalization"的方向，其實是有其哲學上的意涵 - 當然，是不是真的有這種意涵，我也不知道 - 反正，知道怎麼用就好了啦~~~~

不過，我也想知道，一開始的時候，為什麼是用 "Inheritance" !!?? 個人的猜測，一開始時候，也就是 "Inheritance" 的時代，物件導向的 "學術概念" 還沒很完備。一直到 Java 時代，也差不多是 "Generalization" 時代，物件導向概念與方法才算比較成熟，所以才把 "Inheritance" 換成了 "Generalization"。當然，直到今日，這些東東仍然不斷在演進，就像 UML 的版本仍不斷在更新。未來，這些概念的用詞，是否會再改變，我想答案是肯定的吧!?

PS:我個人其實不怎麼喜歡 "知道怎麼用就好了" 這一段話，這樣的態度，某種程度上的阻礙了學術的進步。不過，那是另一個issue了...

開會技巧知識分享

前言：
開會是是組織溝通最常用的方法，然而多數的會議執行情形，要不就是變得太發散，要不就是變得太封閉，以致常會有”以會養會、越開越不會”的情形。以下分享開會的技巧與知識，期能增進開會的效率。

本文：
這裏將開會技巧分成三個不同的領域：”認清自我”、”責任歸屬”與”執行步驟與技巧”。”認清自我”與”責任歸屬”其實是一個組織在組成的時候就應該注意的問題，而這兩個問題其實也會貫穿整個組織的運作流程。很多時候，一個組織的運作如果不順暢，很有可能就是這兩個領域出了問題。對於會議的執行，其實也一樣，如果這兩個領域沒能釐清，會議的效率必定會大打折扣。以下就分別對這三個領域說明之。

1.認清自我
知道自己組織是什麼、知道自己組織的目標、知道自己組織想要做什麼，這些都是”認清自我”的基本條件。而在面對”會議執行”這件事的時候，主要需要認清的項目包括下列兩點：

(1).組織的情形
組織的情形又分成”人”與”環境”。”人”的情形指的就是組織成員的能力、經驗等問題，而”環境”的情形指的就是組織的文化。面對不同的的成員情形與組織情形，必須運用不同的開會技巧，才能達到應有的效率。這裏將成員的經驗與能力分成”高”與”低”兩種，將組織的文化也分成”開放”與”封閉”兩種。所謂開放的組織文化是說組織成員對於問題的反應踴躍，組織成員熱心於提出問題與意見；反之，封閉的組織文化則會有相反的情形，成員對於提出問題與意見的意願不高。將上述”人”與”環境”的情形組合起來，可能會產生以下四種情形：

A.成員的經驗與能力高+組織文化開放
如果成員的經驗與能力足夠，而如果組織文化又比較開放，則開會很容易因為討論的目標太多，造成討論失去焦點與方向。

B.成員的經驗與能力高+組織文化封閉
這種情形比較特別，通常是因為組織負責人太過專制才會發生，因為如果成員經驗與都夠，通常組織不至變得封閉。如果真發生這種情形，這個組織會有解體的可能性。

C.成員的經驗與能力低+組織文化開放
這種情形是比較好的情形，但因為成員能力經驗不足，會議負責人必須小心導引會議的進行，否則會議的進度可能會不如預期。

D.成員的經驗與能力低+組織文化封閉
因為成員的經驗與能力較低，對於問題的思考比較不易聚焦，開會時的討論容易變得沉悶，討論的結果可能只有宣示的效果而不易成為共識。

不管是上述哪種情形，會議負責人與組織負責人其實都是會議成敗的關鍵。在「第3節-執行步驟與技巧」時會再探討面對相關情形時，會議負責人與組織負責人的對應方式。

(2).會議的形式
這裏將會議的形式分為”開放式”與”收斂式”。所謂”收斂式”的會議，通常都只是在做最後的確認與宣示，因為目標與策略明確，可能發生的問題也少。一個會議會有效率不彰的情形，通常都是”開放式”的會議，這種會議的特色就是「目標與策略不明」。然而，多數的會議其實都是為了釐清問題或探尋方法，所以多數會議本來就常常是「目標與策略不明」，而這也是開會技巧所要面對的問題。
以本專案的某一次會議為例，一開始專案經理請同仁分享客戶問題的管理方法，介紹完之後，專案經理開始提出了一些問題。因為會議之前只有提到會議主題而沒有說到會議目標，而會議一開始就讓同仁進行分享，也沒有提到目標與策略是什麼，所以一開始對於這次會議的目的就不甚了解，在聽了經理提出的問題之後，更對會議目標充滿疑惑，所以忍不住提出這樣的問題：「會議的目標是什麼?」。經理的回答是：「我們的目標是希望找到好的方法幫助同仁執行運作」。這樣的答案是其實是有疑問的：與會同仁是否理解與認同這樣的的目標?
猜想，專案經理應該是沒有花足夠的時間處理會議前置工作；專案經理可能只是認為這樣的會議配上這樣的目標就已足夠，而會議本身只要開放大家討論即可，卻忘了與會人員裏尚有許多未來得及進入狀況的新同仁。這樣的開會效率其實是有限的，這樣的經驗分享的效率也會有所打折，當然，如果主管滿足於這樣的效率，組織同仁大概也沒什麼好抱怨的。(註1)


2.責任歸屬
在上述的文章裏有提到兩種負責人，「會議負責人」與「組織負責人」。組織負責人其實就是”主管”，而會議負責人可能是會議主持人，也可能是主管。這必須看這個會議的發起人是誰，如果發起人就是”主管”，則該”主管”就應該是責無旁代的負責人，即便”主管”是交待別人當會議主持人。
事實上，一個組織的文化跟主管本身有絕大的關係，即便是同一群組織成員，面對不同的主管也可能展現不同的文化情形，所以就算主管交待別人當會議主持人，也無法脫卸責任(除非這個主管不在意會議結果)。當然，如果主管能與會議主持人有充份的溝通，能夠讓彼此對目標與策略有足夠的共識，那至少可以均分責任。
在接下來的執行步驟與技巧裏，重點會放會議負責人身上。所以，會議執行前，責任的釐清與區別是非常重要的。


3.執行步驟與技巧
執行步驟簡單分為三個：會前、會中、會後。多數人應該都知道，會前的準備是非常重要的，可是多數人其實都不清楚”會前的準備”到底要準備什麼。這篇文章的主軸即是放在會前準備的技巧上。當然，很多人可能會因為沒有時間做會前準備，而只好直接依靠開會來解決問題，但卻造成會議的效率的低落。其實這就有點像系統開發時碰到的問題，因為沒有時間做好需求分析就直接開始撰寫程式，最後做出來的東西反而不是客戶要的….
在這裏，我們必須特別注意，會議負責人與會議主持人是不是同一個人。如果會議負責人與會議主持人不是同一個人，那麼在會議之前的充份溝通將是非常的重要。在以下的步驟說明裏，會先假設會議負責人與會議主持人是同一個人，所以只寫出會議負責人的執行重點。對於一個開會技巧尚未成熟的組織而言，建議最好先讓會議負責人與會議主持人就是同一個人。

(1).會前
會前主要的工作步驟有三個：資訊收集、分析與整理、目標與策略擬定。其實這樣的工作步驟跟系統開發是很像的：客戶訪談、需求分析、技術解決。想說的是，很多東西其實是”一法通，萬法通”，養成這樣的思考習慣其實比找到好方法更重要!!

A.資訊收集
資訊收集要做的工作其實就是事先的訪談(有點像客戶訪談)。正如前面所說，當一群人開會時，容易變得太過發散或太過收斂，這就是所謂的”小團體效應”(這裏的小團體指的是5人以上到30人左右)。為避免這樣的情形，事前應該先以2~3人的小小團體溝通為手段，一方面可以收集資料，一方面可以幫助要參與會議的同仁先行了解會議目標並釐清想法，以免到了會議執行時，或是提不出想法，或是想法太過偏離。這樣的小小團體的人數，建議不要超過5人，這個人數也是XP(終極開發流程)所建議的人數。

B.分析與整理
資訊收集之後，就必須進行分析與整理。這個動作可以幫助了解組織的情形，以擬定適當的會議目標與策略。這段過程注意的重點有二個：
a.了解組織情形
利用這段過程，可以了解組織成員對會議主題的經驗與了解程度，這些資訊有助會議負責人擬定適當的目標，並幫助有效控制會議的進行。
b.分析資訊共通性
分析資訊共通性可以了解組織成員對於會議主題上的認知的差異，並可從資訊的共通性裏整理出會議主題的關鍵鏈，這個關鍵鏈可為會議策略之主軸。

C.目標與策略擬定
首先，我們可以從所收集到的資訊，分析組織的情形，來決定適合的目標。這裏談的目標，其實包含”程度”的意念，亦即了解這次的會議執行所能達到的程度。這裏把程度分為三種：
a.如果收集到的資訊多，且共通性也多，那麼會議就可以用”達到共識”做為目標。
b.如果收集到的資訊多，但共通性少，那麼會議目標可能只能以探討共通性為主。這種時候，最好先將會議規模縮小，利用小小團體討論，先找出共通性。
c.如果收集到的資訊很少，尚無法有效分析共通性，那麼建議會議負責人事先做好會議內容，在會議上直接傳達宣示就可以了。(或是根本不要開這個會)

接下來，整理所收集到的資料，並分析出關鍵鏈，就可以擬定會議的目標與策略。所謂的關鍵鏈，可能是一連串的相依性的問題或意見，而這些其實是組織成員共通的問題或意見，會議負責人將這些串連起來，就成為會議進行的方向。接下來，再依據組織的情形決定執行策略。以下分二種情形：
a.如果組織成員資深的比較多，則會議負責人可以將所收集到的資訊直接付諸討論。
b.如果組織成員資淺的比較多(可能在資訊收集時會發現所能收集到的資訊不足)，這時候，會議負責人就必須注意問題導引。建議使用開放性提問的方式(註2)，導引成員思考與提問。事實上，如果在資訊收集時會發現所能收集到的資訊不夠多，建議不要直接執行會議，而應該增加多次的小小團體會議以提高效率。

(2).會中
一旦擬定了策略，會議就可以依策略執行。重點在於如果發現會議執行與所擬定的策略有差距 (可能是事前準備不足所造成)，最好能即時停止討論避免時間的浪費。也可以就地轉成小小團體討論，可能會有更好的成效。

(3).會後
會議結束後，除了留下討論紀錄外，最好也把討論的過程及優缺點記錄下來，例如會議是否有依策略執行，如果有的話，成功的關鍵是什麼? 如果沒有的話，原因又是為何? (如果有做好會議前置準備，這些會後資訊才有保留價值；如果沒有做好會議前置準備，會後這件事最好就算了…)

結語：
良好的溝通是一個組織能夠成功的最重要的關鍵之一，一個溝通不良的組織，幾乎免不了失敗的命運。期待這樣的知識技術分享，能幫助增進組織的溝通效率。

註1：
我其實並不認同「找到好方法」這樣的目標，個人認為，所謂的”好方法”會依目前的資訊發展情形、依成員的能力、依客戶的需要而有所不同。所以覺得，比起「找到好方法」，「找到”幫助同仁找到好方法”的方法」才是更重要的目標。

註2：
人的思考通常不可能真正的天馬行空、不著邊際，絕大多數的人的思考都還是會有所依附，然後再運用聯想的方式，建立自己對問題的思想地圖。所以，在會議進行中，資深同仁可以依附自己的經驗來提出想法；但對於資淺的同仁，則可能會先從其他同仁的話語裏，挑選自己了解的部份為依附，然後再以此為出發點來進行思考聯想(如果沒有挑選到可以依附的東東，大概就會想睡覺)。這時候，組織負責人的提問，很容易成為其他同仁(不管是資淺同仁、甚或是尚未釐清會議目標的資深同仁)的依附目標，結果意外的將整個會議導向了原本非預期的方向。這樣的情形原本就是人之常情，不是組織負責人聲斯力竭、大聲疾呼就會輕易改變的…


附錄：組織文化與組織負責人

組織文化的建立與組織負責人有極大的關係，就像之前所說，同一批人，在不同的主管面前，也可能會展現不同的文化。如果一個組織的文化比較封閉，而組織的負責人希望能有所改變，建議可以從下面兩點著手：

1.接受不成熟的意見
以資工所而言，多數的主管都有接受不同意見的心胸，卻沒有接受不成熟意見的能力(風險容忍)。理論上，所謂的主管，應該也是組織裏經驗與能力較好的人，所以通常組織成員所提之意見相對而言都會是比較不成熟的。這時候，多數的主管多會忍不住想要糾正。多數的主管可能認為這樣的糾正行為是讓成員有所成長的機會，也可能認為導正成員不成熟的意見，避免成員失敗是主管應負的責任；但事實上，這樣的行為對剛入行、有衝勁、缺經驗的人也許是有效的，但對其他多數人反而會造成思考與成長的抑制。
李世民是中國最成功的皇帝，他最有名的事蹟就是「廣納諫言」。但多數人可能只注意到他具有接受不同意見的心胸，卻沒有注意到更重要的是他有接受不成熟意見的能力。事實上李世民是非常聰明的人，他本人的意見很多時候會比他的臣子還要好、還要高明。然而，他的諫臣 魏徵 卻極力要求他去接受那些不成熟的意見。因為，如果主子時常糾正臣子的意見，那臣子自然會減少意見的提出，到時即便賞金封爵，也不會有人再提出諫言。

2.縮減範圍
當然，要接受不成熟意見，必須考慮到所能容忍的風險(畢竟是不成熟的意見)，如果組織本身沒有足夠的風險容忍能力，那就應該縮減執行的範圍。例如，想在一個多人的組織推行一個新方法，可以先分割小團體試行，然後再慢慢擴大(有點像雛形法或漸近法)。但是，這種方法的執行，其組織負責人必須要有很強的能力與控制力，必須有能力區分階段，必須要能清楚掌控各階段的情形與銜接，每個階段都必須要能完成完整驗證。這也意謂，比起”瀑布式”執行法，會多花上好幾倍的時間…

xtags library 使用上的BUG

我們要做一個 Web 介面供人員查詢資料檢核結果。原來的 Web 設計是用JSP讀取資料庫資料，然後 output 成 XML 直接回傳給 Client 的 Browser。而這個回傳的 XML 有標記搭配的 XSL，Browser 在讀取這個 XML 後，會去找到搭配的 XSL 以產出 Html 型態顯示。也就是說，將 XML & XSL 的處理交給 Client Browser。

這樣的方法發現一些問題，會有一些 IE Browser 無法正常顯示 (Mozilla Firefox 好像就沒這種問題)。我們推測是 Browser 對 XML 與 XSL 的支援上有問題 (可是找不出問題在哪!?)。後來，我們決定修改設計，將 XML & XSL 的結合，改由 Server 處理，所以我們在 Tomcat Web Server 上 加裝了 xtags library。

用 xtags library 處理 XML 其實很容易，只要在 JSP 程式裏加上一些 TAG 就好。

例 1 : 直接處理一個已存在的 XML File
<xtags:style xml="test.xml" xsl="test.xsl>>
</xtags:style>

例 2 : 內嵌 XML
<xtags:style xsl="test.xsl">
<root>
<childnode></childnode>
</root>
</xtags:style>

也可以這樣 :
<xtags:style xsl="test.xsl">
<%
out.println("<root>");
%>
<childnode><% =varible %></childnode><br /> </root>
</xtags:style>

然而，如果是用"例 2"的方法，會有怪問題
JSP 的結果會問隔性的出現 "IOException : Stream Closed"
也就是說，執行第一次會成功，第二次失敗，第三次又成功，第四次又失敗....

這個問題是 Tomcat 與 xtags library 的問題，目前無解。但可以改用以下方法來避開這個問題：
<xtags:parse id="myreport">
<root>
> <childnode></childnode>
</root>
</xtags:parse>
<xtags:style document="<%" %>"">


這樣就不會有 Stream Closed 的錯誤，也解決了之前 Browser 的問題....

前置需求分析作業

背景
　客戶想要幹什麼的時候! 有時候，也有可能是，老闆想要幹什麼的時候! 最常發生的時機，大概都會是在年度快結束，準備要談下年度的工作的時候。

需求內容
也就是客戶說他想要幹什麼的內容，通常會包含有三種資訊：
1.故事：誰想做什麼?
　過去怎麼做的；現在我們想要改成什麼樣子，或是增加什麼功能；未來最好可以保留什麼彈性，以方便增加什麼東西。
2.限制：誰? 什麼時候? 在哪裏? 跟什麼搭配?
　預報員於預報作業時間，在預報中心的主機，讀取GFE的資料，編輯產品後，送給機務課負責傳送…
3.相關配合工作：
　請你們幫忙Survey什麼技術，幫我們的人做教育訓練，還要有一些文件可以給我們…

運作執行
好了，我們接到客戶提出來的需求了，接下來呢…
1.先開一個會，擬定策略
　(1).先討論這件事的程度，意思是說，也許根本可以不理他…
　(2).確立權責與關鍵人員：這項工作的對象包括我方與對方；誰是這項任務的負責人與關鍵人員，這很重要!!
　(3).建立溝通管道：對於這樣子的負責人與關鍵人員，應該有什麼樣的管道；是要集合所有關鍵人員一起開會，還是各個擊破，還是對單一窗口就好?
　(4).訂立時程規劃：以上確定後，就可以來訂定時程，時程的規劃，主要會包含[步驟2.]，而且可能會重覆3~4次；時程人力的預估，應該會依需求內容之不同而有不同。不過，我們現在還沒有足夠的統計資訊，所以可以先憑經驗，大家有共識即可。
2.開始認真工作 (這個步驟可能會重覆3~4次)
　(1).系統需求分析 (這個步驟可能也會重覆好幾次)
　　將客戶提出的故事、限制等等東東，分解成為四種圖，可以看一下本文件後面 [參考事項-需求分析] 一節。
　　A.對四個面向分別討論已知及未知項目
　　B.連結各面向關係，檢視彼此衝突
　　C.重覆A、B動作，直到沒有疑慮
　　D.討論相關配合工作：這個項目的討論，跟上面的系統開發，好像比較沒有什麼關係，似乎只要能釐清就好…
　　E.整理記錄，安排下一階段工作，可能的工作像是：找哪一個客戶確認什麼事情；了解一下什麼技術…
　(2).人力預估：對上面討論的結果，主要是已知的部份，包括模組與元件的開發以及配合的工作項目，估計人力成本。因為，在與客戶反覆討論與確認的過程中，人力資訊可能會是客戶做決定的一個參考指標。
　(3).與客戶討論與確認：最好都能留下會議記錄。
3.撰寫規格書&建議書：到了這個階段，寫這些東西應該就不是什麼難事了…

參考事項－需求分析
　需求分析的工作，應該會要有下面的四種圖，而這四種圖之間會有連結與衝突之關係，實際的需求分析工作，其實就在於了解之間的關連並解決彼此的衝突。每一個圖都應該會有已知的部份以及未知的部分，所以實際畫圖時，可能會畫出不只一張圖；例如，對於未知的使用者操作流程，我們可能就可以先行假設2~3種不同的建議。

1.使用案例圖：即是UML裏的UseCase，一個系統可能會有好幾個不同的UseCase，每一個UseCase應該會是一個獨立的作業流程。以QPF為例：[預報編輯]與[預報校驗]會是兩個不同的UseCase。當然，系統夠大才會需要UseCase；像TED系統，預報員的作業是一次從頭做到尾(選擇條件、編輯、傳送)，其實就只有一個UseCase，所以也就不需要案例圖了。

2.作業流程圖：這是從使用者角度觀看的操作流程，只要把使用者會知道、會看到的部份寫上去就行了。建議可以是UML的Activity Diagram。

3.資料流程圖：以氣象局為例，客戶很重視資料(包含產品)如何流動；所以，必需將資料流程清楚表現。建議可以用DFD，但是，最好是與 [作業流程圖] 搭配，不要把圖畫的太複雜。

4.模組元件圖：這個會是以系統開發人員的角度來畫的圖，也是以後系統開發設計時，主要的參考資料。所以，必須十分注意，模組與元件的完整性，以及介面的相關性。因為，這些資訊會變成一個系統的架構，也就是說，以後如果有新的需求是要變更這個架構，會累死人的…