全文均刊登於北京「程序員(Programmer)」雜誌(台灣天瓏書局可購得), 2007 7月刊, p67~p69。 感謝朱海豔(helenna)小姐用心將文稿轉為簡體專業術語，以及將 Model 重新美編，並轉為簡體。

結構面的設計產出

關於軟體結構

所謂的系統結構(System Structure)分析與設計(Analysis and Design)，係指如何正確、有效地分解設計範圍內系統的元素(Element，一般泛指物件(Object))，指派每一個物件所應有的屬性(attributes)與行為(behavior, 責任的分派)，抽象表達靜態類別之間的關係，動態組合物件在執行期間(run-time)的訊息(Message)傳遞，以履行系統的功能需求(ex. 來自於 Use Case 的功能分析)．．．。做好結構分析、捕捉有效的領域概念，以成為系統的主結構，才能建構出堅若磐石的軟體系統，來應付現實複雜系統的善變，甚而讓系統呈現有機的次序成長、生生不息。

如何找出問題領域(Problem)的概念具化成為企業物件(Business Object)、指派每一個物件應盡的責任，並以此來建構系統中的軟體規格模型，已是高階系統分析與設計人員最大的挑戰與應具備的本質學能。更為難的是，如何將企業物件配合現實面的平台，例如如何活用 J2EE Spring and Hibernate 系統框架。因為，現實上，物件的狀態(state)就是被永續(persistent)儲存在資料庫系統內，而在需要用到(企業邏輯的運算)的時候才被活化(activate)起來；同時因為物件共用的議題而需要 AP 應用伺服器的系統支援，包括交易(transaction)控管、安全性(security)、效能(performance)、分散(distribution)等議題的設計考量。兩個層次(高階概念性的分析設計；細部平台面的設計)，互補且缺一不可。

系統的內，也就在於分析所組成的內部結構元素，套現在 IT 的術語來說，也就是所謂的物件導向分析與設計(Object-Oriented analysis and design)。相對於系統的外，是著重在功能性的需求分析(也就是前一期內容所介紹如利用使用案例建構的需求模型)。兩者是互補—找出內部穩定的結構元素(物件,Object)，來應變外部的功能需求。

而系統的結構分析，正是現今軟體人員們最大的罩門所在。在速成短線的專案開發生態，軟體人員只會看到現在所看到的—找出一個一個的功能，快速地利用所提供的平台技術(如 .NET, J2EE)，疊床架屋的方式，Quick and Dirty 快速的給開發出來。不要以為利用 .NET 或 Java 等 OOP 語言，就是所謂的物件導向開發模式，這是兩回事，如果沒有用心地萃取具本質性(Essential)的物件(再一次強調，源自於問題領域的概念術語)，而只是看到一個功能就成為一個 Class，那麼，這樣的系統完全會受限於需求性的變動而導致震盪不穩，是不會具軟體系統的彈性(flexibility)、穩定性(stability)與延展性(extensibility)！

什麼是軟體的結構？

軟體系統的整體呈現是來自於問題領域(Problem Domain)，也就是把該領域中經常溝通的術語(terminology) 對映至軟體系統的物件，稱之為領域物件(Domain Object)或企業物件(Business Object)。 例如，”人事資源(Human Resource) 管理” 系統的開發，其核心的問題領域當然是以 “人事” ，經常溝通的術語會有 “員工(Employee)”、”部門(Department)”、”請假”、”請假細項(AskLeave Lineitem)”、”考績” …等，而這些術語自然地就會被捕捉(capture)至軟體系統內，而成為構成軟體系統主結構(main-structure)的成分元素了。

將組成軟體系統結構的元素組織在一起，並利用視覺化的方式來呈現，稱之為 “領域模型(domain model)”。領域模型代表真實世界中的概念性類別，呈現的是領域中的概念性類別或真實世界中的物件。在 UML 的模型中，最重要也是最必要的一張結構圖也就是類別圖(Class Diagram)。

參考下圖 1，通常使用 UML 表示法呈現的領域模型，凸顯的是概念(concept)，再來則是以及概念之間的關連(association)與屬性(attributes)。例如 “Order”, “OrderLineItem”, “Customer” 都是屬於在該領域中的概念； Customer 與 Order 之間則存在著 1 對 1..多 的關連(一個客戶會有 1到 1..多筆訂購交易)； Product(產品) 具有 description, price 的屬性。在概念性的分析時，細節(包括操作,屬性,資料型態等)在目前並不重要，最重要的是能突顯出概念的呈現，也就是找出類別(Class)。

（點擊圖片鏈接看原圖）圖 1、範例—訂購系統的類別圖(Class Diagram)

那個時候最能表現出結構設計的應變能力？ 筆者常說，當 SA(System Analyst) 遇到 有點像又不太像 這類的需求時，也就是結構設計發揮的時機了。 舉個例，訂購 若會視訂購的類型，可能是書籍、雜誌、百貨商品等，而有不同的訂購流程與處理邏輯，此時，懂得虛與實互補設計之道的 SA，會很自然地把訂購分為一般化與特殊化(generalization-specialization)—把已知的部分放在一般化；而未來要具體實現的部分放在特殊化。事實上，這也才只是利用到多型(polymorphism)的基本技巧而已，就已經足以解決為何程序員經常會為了訂購類型寫了一堆的 switch, if…then…else 這種的條件敘述，而造成程式碼混雜，難以維護了。

如何找出軟體的穩定結構元素，是系統分析人員最大的挑戰。SA 並不需要具備領域知識(Domain Knowledge)，但卻要懂得如何與領域專家(Domain Expert)溝通合作，萃取其知識，並抽象(abstract)成為軟體的主結構。這相當不容易，那並非是純技術面，真正的軟體設計行家，絕對是具高度的抽象的能力，要能懂得從多個構面觀察，時常在反思與找問題(不是找答案)。筆者正是被這在 虛 與 實 均要能互補、一輩子也學不完的軟體設計領域，給深深地著迷，才從原來是系統管理與 Oracle 資料管理師，而至中年才轉到軟體一職來，並已把此視為是終身之職，是要窮究一輩子、甚至帶至下一輩子繼續來修行的。

回歸正題，關於結構設計的好書相當稀少，筆者這裡特別推薦 Peter Coad 軟體大師，從早期 1990年的 “Object-Oriented Analysis”，“Object-Oriented Design”，至 1998 年的 “Object Models”、1999年 ” Java Modeling In Color with UML” 等著作。尤其是 “Object Models” 一書所揭露出以交易為核心的 交易樣式(Transaction Pattern)，更是軟體結構分析人員必讀的聖經。在筆者經常訪問與輔導各領域的公司時，經常在當場就直接展現與證明不用懂領域知識，也能馬上抓出該領域的核心結構，所使用的利器即是 交易樣式(Transaction Pattern)。

閱讀全文 »

全文均刊登於北京「程序員(Programmer)」雜誌(台灣天瓏書局可購得), 2007 6月刊, p74~p77。 感謝朱海豔(helenna)小姐用心將文稿轉為簡體專業術語，以及將 Model 重新美編，並轉為簡體。

前言

筆者在輔導專案的初期，第一個時間點就要能抓出系統開發的架構全貌，請注意一下，系統不全然是指軟體資訊系統，也有可能是將企業當成是系統，並對其作需求分析、結構設計，此稱之為企業塑模(Business Modeling)。這是牽涉到系統開發的範圍與層級，無論是企業或軟體系統，如何讓開發團隊所有成員與利益關係人(stakeholder)，都能對待開發的系統有一致性的整體觀，這會是架構師首重的工作與責任。

保持整體觀可不是只透過一種設計產出就能讓所有人瞭解，道理很簡單，開發人員經常會有各自所關注的觀點，例如，需求分析人員關心的是系統能提供什麼功能與服務給使用者，他重視的是系統外部的功能需求；結構設計人員關注的是如何找出穩定的結構元素(經常是源自於問題領域的概念(concepts))，來支撐與應變外部需求的變動，他重視的就是系統內部的結構組成元素；實做人員當然就是重視能不能快速寫出程式(program)，同時還能有高效率與彈性，他重視的就是系統平台面(ex. .NET or J2EE)的實做與相關設計議題；甚至，連客戶單位的高層管理人員，也有他重視的觀點，如資訊系統是如何協助與協助企業流程(Business Process)的自動化 …。

所謂架構呈現的整體，並不是靜態不變的，而是持續性的動態調和，架構師就是要能懂得如何調和 需求功能面、結構面與平台實作面 等多重觀點，凝聚各種不同的角色，還能有一致性的全貌見解。這可不是容易的事，軟體架構不只跟結構與行為有關，同時也跟背景環境有關，包括：使用方式、功能性(Functionality)、效能、彈性、再利用性(Reuse)、可理解性(Comprehensibility)、經濟效應與技術的限制與取捨 … 等。

本篇內文，筆者是希望利用一些 UML 視覺化的設計產出(artifacts)，來說明這些產出是如何來協助架構師觀照與協調整體。這些設計產出，彼此之間有某種程度的關連性，並且要能保持一致性；架構師也容易瞭解架構的全貌是從哪一種角度來看待的觀點，然後知道如何在表象複雜的系統中，聚焦(focus)在系統廣度與深度的某一點，而不致偏離所探討的主題。 聚焦可是架構師必具備的能力，知道焦點的所在，決定是否再細分下去探究內部的細節；還是因為成員之間常因細節爭擾不紛時，就知道應該再把討論的焦點層次再往上，才比較能取得共識。

以架構為中心的觀點與產出

在前一期的專欄中，筆者提及了三個觀點來呈現架構(關於該三個觀點的解釋，請參照上期內容)，參考如下圖 1。

（點擊圖片鏈接看原圖）圖 1、表達軟體架構的三種觀點

以下列出筆者個人經常在使用的設計圖，用來呈現與解釋各種架構的觀點。請注意，筆者並不是會全部用到所有的設計圖，會視專案的規模與性質來決定該有哪些架構設計，有時甚至也會有額外、不一定非得是標準 UML 的設計圖。重點還是在於：你要知道該設計產出是在那一個觀點、表達的是那一個範圍與層次。筆者太常看到，團隊成員們之間，爭論的話題，根本就是不同觀點、不同層次，卻又不自知，難怪會經常導致溝通障礙的問題了。

閱讀全文 »

前言

筆者多年來輔導過諸多不同類型與不同領域的軟體開發專案，本身的職務是擔任軟體架構師(Architect)與顧問輔導。架構師不是只負責技術面的問題，更要兼顧到專案開發的過程中， 」人」 的互動所衍生而來的諸多問題，包括想法的歧異、見解的落差、不同的觀點與角度，甚至情緒問題等等，這些都需要與專案經理協同合作，一同來解決問題。

軟體的開發，最終目標雖然是 「完成高品質」 的軟體系統，但在進行階段過程中，所衍生出的兩大議題—專案管理(Project Management)與開發流程(Development Process)，卻是首要需克服的階段目標。而該兩大議題，均是係以 「人」 為核心的考量，專案管理講究的是 「領導統御」、」人和」；開發流程重視的是 「調和 (凝聚團隊成員的觀點、角度，保持產出的一致性)」。專案管理的部分，筆者的角色比較不方便闡述(此一部份由專案管理者來論文比較妥當)，倒是相關於開發流程的議題，筆者倒是可以把藉由所觀察到諸多各形的開發型態，以及個人的一些研究、學習、思考與體悟的心得提供給讀者參考之，文中內容會是筆者比較偏以 「主觀意義」 的表達。

變動無常的軟體專案

軟體系統的專案開發，特別的是，需求往往不明確，更何況是經常處於變動中，所以導致專案的範圍與規模無法界定，連帶也引起時程無法估算(人月？ 神話吧)。那麼，是不是開發成本的成本也無法預估，而往往也因為成本與時程的低估，更容易導致品質不佳、粗製濫造的軟體系統。

正是由於軟體別於如硬體產業的變動性問題，使得在其它成熟領域的專案管理經驗，並不容易全盤導入至純粹是軟體的系統開發上。若是把軟體開發當成是知識與創新的產業，那麼一成不變且僵化的專案管理方式，並不妥當；除非是將軟體產業當成是軟體工廠，需求固定且明確，工作者(worker) 各司其職，負責實做局部的小功能，再由 「大一點」 的工作者，來組裝成大功能。請記得，這樣的方式，其假設前提是需求不容易變動，工作者也不太需要具備創新獨立思考的能力。

個人是很難相信需求不會變動，同時也認為正是因為軟體的多變性，才造就了更多的好機會，所以軟體的開發，不應該視善變為畏途，反而是把變動看成是理所當然，更是多添了許多的好機會。我們所要作的事情只是，如何將變動抑制或收斂在某一程度可以被控管的範圍內，同時，學會如何在某一問題領域(Problem Domain)，重覆性、同質性高的軟體系統，來找出不容易變動的部分，成為系統的框架(framework)，或稱之為主結構(Main-Structure)。而容易變動的部分，又是如何從主結構中抽離出來，爾後只花少許的 「工作量(effort)」，就可以輕而易舉的滿足客戶的需求。

很難嗎？ 只要有兩個滿足的要素即可：一為開發的資源(包括成本與時程)多一點；另一為團隊對軟體的基礎養成與默契好一點。 但是好像要能滿足這兩點可真是困難，該如何才有可能達成這種 「夢幻」 的要件呢？

這就回到最現實 「人」 的因素了，要能爭取到多一點的開發資源，如果你沒有什麼誘因吸引老闆或業主(兩者可統稱為關係利益人, stakeholder)，是不太容易的。專案的領導者總是要有 「實績」 才能讓關係利益人信賴並願意投入資源，而資源越多，當然專案成功的機會就更大。後文會提及，「反覆與漸增(I&I, Iteration and Incremental) 」，會是提升專案開發 「實績」 的好手段。

再探討另外一點，如何才能讓團隊成員對軟體的基礎養成與默契好一點？ 默契要好，溝通必然要多，要能溝通多，當然就是要勇於把自己的想法給表達出來，而這些，則是有賴於專案領導者的支援與協調。總之，好的專案領導者是要能懂得 「觀察」 在整個專案開發的過程中，成員之間互動所衍生出的種種問題，然後找出 「解決方案」 來謀和 「人」 的問題；另外回到最根本的是，畢竟這是軟體的開發，軟體的基礎養成功夫不足，當然也不太可能作得好軟體開發，軟體人員持續的學習與成長，更會是軟體產業的命脈。

幾個可能是軟體開發流程的問題點

正是由於 「變動無常」 的軟體開發專案，有些人的想法是想要 「凍結」 住需求，然後依照固定不變的製程，一個階段接續下一個階段以循序式 (Sequential)的開發產出 (artifacts)，例如預估一年開發期的專案，三個月的系統分析(SA, System Analysis)、三個月的系統設計(SD, System Design)，六個月的實做與測試(Implement and Test)，這樣的開發方式稱之為 「瀑布式(Waterfall)」 的開發流程，參考如圖1。 閱讀全文 »