W09 專案的開發(2)──決定系統的主要架構

Use Case收集到一個程度，需要開始分析Use Case間的關聯，目的是檢查被定義為include或extends次數多的Use Case將之納入主要架構的設計。

直接查看Use Case的關聯（項目）看哪些拉出很多關係當然可以，不過製作出Use Case-Use Case水平追溯表（清單）會更有一目瞭然的效果。UML工具應要支援關聯的記錄與存取的API，那麼就可以撰寫工具程式直接產出為Excel檔案並註明include或extends的關係，再運用Excel的功能作排序、計數等等的運用找出適合納入主要架構的Use Case。

在主要架構裡會有些隱含的Use Case。像是在client-server架構下，如果沒有採用現成的framework勢必要自己設計一個收送的功能，即使客戶沒提也一定要有記錄log的功能，這些都是必須額外加上的Use Case。在這裡加上的Use Case大多與設計有關，必須視使用的framework予以調整到完備。另外還有一些event時間點的處理功能，也要一併納入考慮。

從UML model裡再轉換出Actor-Use Case的垂直追溯表，可以定義出執行功能的權限管理。在分析階段收集範圍後再追溯關聯，可以精確地得到相關資訊作為架構設計的依據。

W08 專案的開發(1)──收集Use Case

在開始之前，先讓觀念作點轉換：
人＝Actor
事＝Use Case
物＝Data
時＝Use Case Entry Point
地＝Use Case Precondition

在系統分析時對Actor與Use Case應進行的步驟如下：
●收集全部Actor與Use Case以明確定義系統可以做的所有功能
●建立全部Actor與Use Case之間的使用關係
●分析Actor之間的使用範疇有包含關係者改為繼承
●所有Actor區分群組並定義在其所屬的Package下
●分析Use Case之間的使用範疇有包含關係者改為繼承
●分析Use Case內是否能拆解出include或extends關係的子Use Case
●所有Use Case區分群組並定義在其所屬的Package下
●明確定義每一個Use Case的發動時機
●明確定義每一個Use Case發動前的狀態
●明確定義每一個Use Case發動後的狀態
●收集每一個Use Case的所有可能劇本

在抽取共用Use Case的同時，思考的是＂某種特定的使用者目的＂。例如最近幫客戶設計晶片卡密碼驗證的功能，其目的是把使用者從密碼輸入器輸入的密碼傳到晶片卡模組去檢查，這雖然可以是一個獨立的Use Case，但也可以將用途切割為＂取得密碼輸入器上輸入的密碼＂與＂將密碼送到晶片卡模組檢查＂兩個Use Case，後者include前者。如果輸入密碼的方式又多了＂從鍵盤輸入密碼＂，由於是二擇一的關係，關聯就要更改為extends。

對設計者而言，Use Case與Activity的抽取常會混淆，Use Case必須從Actor的角度看待，其目的是＂對使用者有意義的獨立行為＂。上面若將不同的密碼輸入功能合併為一個＂從輸入設備輸入密碼＂就會有點模糊，因為輸入設備只是個概括的名詞（除非再另外定義輸入設備包括哪些）；若在其他功能內只允許用密碼輸入器輸入密碼時，這個Use Case就會變為不合用，重新定一個會造成功能重覆，修改原來的又怕會影響之前的Use Case造成問題。

沒有作好一對一的分析與設計，就常會有這樣的兩難局面。

W07 一般工程設計與軟體設計的不同

最近參與公司內的討論，聽到了＂因為軟體本質上的不同，所以一般工程方法難以適用在軟體工程＂的話語。發言者強調軟體是易變的，所以無法像工廠一樣產出固定不變的元件，同時設計也常因需求改變而隨時變動，建立在易變產出上的方法自然無法固定。

依照慣例，我還是仔細地思考了一下話中的含意。

根據自己的經驗推論，建築工程是三度空間的設計，但是軟體設計就像是四度空間的思考。像建設高速公路時只要在必要的通道上設收費站就一定收得到過路費，但是軟體即使規定好設計的層次，但任誰都可以修改為完全不經過那一個點而進入；汽車的動力從引擎經過傳動軸再傳到輪胎，但是在程式定義上直接讓動力直接轉動輪胎也是可行的作法；還有就是蓋房子時九樓往上一層一定是十樓，但是在軟體裡卻可以跳躍到任何一層，完全不受空間限制。

就製作的成本考量，一般工程需要零件時因為自己開模製作很慢於是會開好規格訂購現成零件，但是軟體元件卻因程式修改快速且成本不大，所以就在該要的地方直接作出可以應付的結果，全然不去考慮日後重用的兼容問題，反正複製一個後再改程式微調差異即可。

只注重結果的思維造成跳躍式的使用、零成本的修改（指非人力的）造成隨意的改變，雖然執行的結果相同，卻使得產出的程式碼有難以統一的多變風格、修改時也不易找出問題的真正原因。也由於同樣的需求會觸發各種不同的想法與設計，我們又無法像一般工程那樣證明哪個作法是最好的而規定下來，更增加了產出的不確定因素。

邏輯上只要檢查不出錯誤就可以說是對的。在沒法證明哪一種作法具有全部好處時，大家只能針對自己著重的方向使用自己覺得好處最多的方法。然而在對應種類眾多的時刻，選擇作法時比照一般工程嚴謹地讓每個零件限定只能接續特定的零件，是否就能適用一般工程的作法呢？

W06 做事的方法(16)──對小朋友所說的做事接物摘要

●使用一個物時一定會有一個連帶的動詞，該動詞稱之為一件事。
　例如：拿剪刀、穿鞋子、背書包等。
●物要固定放在一個地方，需要的時候只要找一個地方；如果平時物隨意亂放，需要的時候就得找很多地方，而且不一定找得到。
●每一件事都有一系列的動作要做，而且要依照一定的順序。
　例如：用剪刀時要將拇指與食指伸入剪刀的圈圈、把要剪的東西放在另一側的兩個剪片之間、拇指與食指用力夾起。
●直接使用一個物的事稱之為小事，包含數個小事的事稱為大事。
　例如：整理書桌是大事，因為包括了整理小書架、桌面、抽屜與桌下等四件小事。
●指派一件事時要有能力把它拆解為小一點的事，並各自一直循環到最小的事為止。
　例如：要你整理房間時，意思是要你整理書桌、整理書櫃、整理衣櫥與清掃地面。
●指派給你的大事拆解的定義要跟我想的一樣；當然，會先告訴你定義的範圍是什麼。
　例如：要你整理房間時，不要只整理好書桌就回報說已經做好了。
●做事的範圍要看實際的物有些什麼而加以變動。
　例如：現在的書桌上有小書架，如果換了一個沒有小書架的新書桌，整理書桌時就不用整理小書架。
●要能判斷自己應該做的事是否需要立即動手去做。
　例如：感覺書桌有點亂時，不需要人講就應該自己收拾；睡前與出門前檢查應帶的東西是否都已放入書包。

生活上接觸得到的事物很多，要一件件都在適當的時機做而且要做得好，實在是不容易的事；大人都已經是如此，更何況心性未定的小朋友。整理出做事與接物的原則雖然可以比較明白其原理，但是對真正要做事的細節並沒有很大的幫助，因為會忘的還是會忘、不做的終究不做。理論與實作，不就是像這樣的對照嗎？

W05 三看簡單型Component

運用人、事、物的想法再回頭來檢視簡單型Component。如果直接可以操作物的只有最小的事，那麼先將之定義為Action，其他無法直接操作到物的事則是不同層級的Flow；這麼一來除了最底層的動作要包裝為功能元件之外，其他各層級的流程應該都只是流程元件？！

這樣的切割法又讓我對元件的結構有了不同想法。依這裡的思緒我應該包裝出只有Action的功能元件，使用Action的流程再另外包裝出流程元件；不過在特定需求的系統裡我也可以產出一個包裝不同流程元件與功能元件的複合式元件，依參數調整內部使用的流程元件；流程元件操作功能元件時，也可以依設定更換不同實作的功能元件。這樣的作法將可以提供更靈活、更多樣化的組裝。

程式解析工具在元件分離的情況下依然可以運作：流程元件只需要處理流程方法是原本就要做的，動作方法不需要做所以不存在也沒關係；但是功能元件內部就需要再拆解出與執行流程相關的方法，標示給工具去解析。不過基本上並沒有很大的影響。（唯有元件產生工具需要調整）

註：人、事、物的關聯一開始只是為了對小朋友講解做人做事的基本原則所整理出來的想法，卻沒料到完全適用在元件結構的應用，這是原本始料未及的。

W04 我的設計準則(6)──追溯關聯

所有的單位在操作或使用的同時就發生了關聯。無論是一對一、一對多、多對一或是多對多，關聯都是追蹤影響的最重要依據；唯有透過關聯的追蹤才能發現某個單位的變動範圍到底有多廣泛。

收集範圍與追溯關聯是在求快速開發的同時最易忽略不做的工作。由於程式碼經常變動造成使用關聯頻繁變化，使得修改追溯表的速度根本追不上變動的頻率，長久下來完全沒有人可以追蹤出任一個底層API修改之後向上隔了數個層次的Use Case到底有哪些會被影響。縱使現在的IDE工具可以查出全部的呼叫歷程，但是在出版本前的迴歸測試要如何取得幾十個變更的影響範圍？

無論人對事、事對物、地對事、時對人與事或是事與事之間的全部關聯都應該要記錄下來，不管是做事的SOP或是程式的呼叫也都有使用的關聯，如何快速列出能夠操作目標單位的全部集合雖然不易，卻是在某些狀況下必須得到的結果。程式碼中快速且正確地列出使用集合，正是我要定義程式結構的主要目的。

針對UML裡的Use Case我實測了三種UML軟體：Rose 7.0.0.0、JUDE Community 5.5與Star UML 5.0.2.1570，測試範圍是Actor與Use Case的關聯、Activity與Activity的關聯。Rose明確地標示出三種圖示與兩種關聯；JUDE連Activity都沒被視為保存的單位（這表示activity無法分析是否重用），更不用提關聯；Star UML標示出三種圖示，也在各圖示內管理自己的關聯。

忽略多個Use Case之間的使用關係時，雖然對於單一Use Case可以快速開發，但是就沒法作出最佳化的分析與設計（如果向下的層次也不追蹤使用關係的話）。使用關聯的雜亂是專案產出的品質難以控管的重要因素之一，卻是被許多人所忽略的。

W03 我的設計準則(5)──收集範圍

分析設計時的人、事、時、地、物都需要各自收集範圍以便定義各自的邊界，收集的好處在於接觸到某一個單位的同時能夠立即知道它是否在該單位的集合，已存在的話可以直接重用，不存在的話就必須另外建立。這個方式對於reuse的幫助很大。

收集起來的單位數會非常多，因而需要建立各自的分類方法依特性分群組放置，這樣可以加快定位的速度；當然加上搜尋的功能也很好。在＂事＂的分類佈置可以衍伸為Package的定義，搭配Component工具就能夠將所有新＂事＂的定義直接匯出元件程式結構，舊＂事＂則依設定參考原有的元件功能。

觀察到很多SA、SD與PG的想法都偏向輸入與輸出，在意得到什麼樣的輸入且應有什麼樣的輸出而忽略了處理輸入輸出的做事流程。在明確定義做事流程的方式下可以得到處理的SOP，進而與其他做事流程共同抽取相同的部分成為API；忽略做事流程的作法下任何想法都以湊出對的結果為目標，雖然效率很好，但是僵化、綑綁與難修改都會跟隨其中。

這是可以套用在任何地方的想法。分析時一個群組（例如會計室）收集的應做之事就是該群組的功能，一個單位（例如出納）收集的應做之事就是這個單位的責任；每一個群組與每一個單位都依其特性給予它應有的責任範圍，並要求該責任只有這個單位具有而其他單位都不得處理。

每個部份要先依其大小意義定出有多少層次，在收集範圍的同時都要依層級分開收集在不同的層次，唯有將所有單位都分門別類地放置的一致化作法才能夠再定義出更上一層的存取規則。這也正是各種工具程式的操作依據。

W02 Use Case裡的人、事、時、地、物

＂人＂必須透過＂事＂才能操作＂物＂是分析與設計的根本，某個物被改變＂必然＂是因為某個人做了某件事，確定了這個關係後就可以很容易地接受Actor、Use Case與Data的說法。再加上該件事發生的時機與執行的地方，就構成了人、事、時、地、物的思考模式。

在系統裡通常會用角色來取代Actor，當某個角色發動做某件事時，權限控管會根據角色與功能的關係決定是否允許。功能被執行後會進行一連串的動作，執行動作的流程會被編輯為Activity Diagram，而被執行的動作就是Activity。


事件可以區分為一次操作一物的＂小事＂與一次包括許多小事的＂大事＂。舉例來說，整理書房是一件很大的事，至少包含整理書桌、整理書櫃、清掃地面幾件較小的事；整理書桌又包含整理書架、整理桌面與整理抽屜三件明確的小事，每件小事都關聯到一個物件。切割範圍的思維一致後，每個人對事物切割範圍的誤差才不致大大。

單位切割之後要處理的是每個單位的分類方式，如何訂定各種存放類別、單位存放時如何分類也是必須同步的想法；另外單位之間原有存在的關聯都是必須保存下來的資訊。

W01 公司應有的文化──所有人員的想法與行為一致

公司的CMMI導入團隊說現在訂立的規範都只強調精神，各專案要根據自己的特性予以調適；由於沒有提供一個基本的範本，造成每個專案各做各的沒有交集，等於是沒有規範。也由於各個專案作法與產出不同，卻擁有相似的問題──沒人看得懂，修改沒品質，無人想維護。

敏捷開發的原則非常強調開發成員間的想法同步。2006年開發UI編輯器時小組裡有四個人，我們每天上午十一點與下午五點都各開半小時內的會議，內容為核對進度、提出問題與回饋作法；目的是讓所有人都對不熟的技術與平台獲得同樣的了解，當時我覺得效果相當好。可是當時的主管有天卻問我這句話：你們一天到晚常常開會，這樣進度來得及嗎？

一間較大公司內會有數個專案，一個較大的專案下會有數個小組，把眼光提升到公司的層級就會有一個疑問：要怎麼做才能讓公司內所有專案、所有小組、所有角色產出的內容與品質接近一致？採用CMMI的流程控管會有許多繁瑣的手續耗費開發的時間，使用快速的方法可以讓開發迅速卻讓其他人難以瞭解系統。

無論是人為的控制或是自由的開發都有可能因為每個人的思考方式不同而導致結果有差異。要能同步所有人的思維，應從瞭解設計的本質開始，再搭配每一個階段、每一個步驟為什麼要這樣做，這樣做有什麼樣的好處與壞處著手。讓所有人打從心裡相信雖然自己多花一點時間，卻能夠留下足夠資訊達成各個面向的要求。

做事方法與思考原則的完全一致化，會訓練出有紀律的團隊，同時會有讓所有成員一看就懂的產出。