軟體設計必讀經典(12)強化結構分析，跨越產業鴻溝

擔任系統開發顧問多年，我觀察到各行業（金融、鋼鐵、保險、零售、股票……等）的資訊主管，幾乎清一色要求軟體架構師（SA）要懂得相關領域知識（Domain Knowledge），認為這樣才能作好系統分析。

然而，SA最多只能代表操作人員（Operator）層級的功能需求分析，核心知識包括企業流程的制訂改善等事務，則是由領域專家（Domain Expert）所掌握。

SA與SD（System Designer）均太過偏重領域知識的結果（在臺灣，SA與SD 的分界一向不明顯，可能是SA與客戶訪談需求，然後由SD作E-R Model資料庫表格的結構分析），反而忽略軟體結構分析的重要性，所抓出來的Entity （經常呈現為資料庫表格），往往耦合性（coupling）太重，導致牽一髮而動全身，無法彈性應付變動。

我經常建議SA與SD要學習與各專業領域專家溝通合作，將核心知識抽象化為軟體系統的結構，所以，SA與SD應具備的，不是其他領域的專業知識，而是結構分析的萃取能力，那是一種可以獨立於各個問題領域（Domain）與IT平臺技術的通用技能，我常稱之為「純」軟體的抽象分析。

套句軟體界常用的術語，就是物件導向分析與設計。這類技術並不能從程式語言、平臺技術或者領域知識學習而來，而是需要培養對事物本質的體悟力、感知力，加上大量的觀察及動態學習。

對於跨領域與平臺技術的抽象能力的建立，《Object Models》可說是最佳教戰手冊，光是「交易樣式」，就得以讓我們跨越專業知識的鴻溝，抓出最穩固的核心結構元素。

以核心交易為主軸，釐清系統架構的脈絡

結構分析主要就是抓出各領域的穩定元素，以建構軟體系統，穩定元素往往就是該領域經常使用的概念術語（Concept Terminology）。在設計階段，一般是以UML類別圖（Class Diagram）呈現；具體化在應用系統中的是企業物件（Business Object），以及資料庫的表格（Table），兩者差別主要在於企業物件需要分析各個物件的責任（在程式語言則稱之為方法，Method），而分析領域物件與明確分派物件的責任，正是影響軟體結構彈性度的主要關鍵。

大部分SA與SD透過需求訪談記錄找出「名詞」，但所抓出來的類別往往見樹不見林，無法有效地將相關類別連結在一起。如何找出有效類別？主要作者Peter Coad觀察到企業行為的本質源自於交易，他指出，交易是商業利益交換的一種契約（Contract），是必須保存的事件（Event）記錄，找出核心類別後，便能以交易為中心，串連參與者（Actor）、地點（Place）、物品（Item），以及所包含的交易細項（Line-item）等其它相關類別。這種先抓主幹、再抓枝葉，進而建構系統的方式，正是「交易樣式」（Transaction Pattern）的精神。

以訂購系統為例，訂購（Order）是核心的交易類別，再以它延伸，可以找出交易細項（Transaction Lineitem）、客戶（Actor）、訂購地點（Place）、商品項目（item）等訂購細項。

如果分析保險業系統的話，保險絕對是一個顯而易見的交易類別，而對保則是後續的交易類別（Subsequent Transaction Class）。如果要分析一個運動彩券投注系統，要你馬上抓出第一個類別，應該就知道該怎麼抓吧？（投注、派彩都是核心類別）

在產出系統、提升效能後，更要賦予系統彈性

本書前5章為各自獨立的案例分析，後兩章為策略與樣式的整理列表。因為內容較艱深，獨立閱讀本書可能會很吃力，建議讀者找幾位同好一起研讀，甚至以角色扮演的方式，思考所抓出來的類別，以及所賦予責任的合理性與正確性。

本書的類別表示法採用作者自創的語法（Coad Notation），它可說是自成一格，例如多重性（Multiplicity）剛好與UML類別圖的表示法完全相反，所以一定要先閱讀附錄的語法說明，才不會搞混。另外，每個案例的研討過程，作者會列出他在某個分析階段所使用的策略或樣式，並將之編號整理在最後兩章，相當有參考價值，你可以配合案例的過程說明互相對照。

Object Models：Strategies, Patterns, and Applications

Peter Coad,David North,Mark Mayfield/著

Prentice-Hall ECS Professional出版

售價：85美元

Amazon四顆半星

《作者簡介》

王克明

台北工專五專部電子科畢業。現於HSDc軟體設計顧問團隊擔任架構師／顧問／講師。興趣為整體架構性的思考與學習、期貨投機操作與閱讀。