軟體設計美學之道最終回──尋找軟體美學的迷思與挑戰

技術的演化有其目的與價值
從筆者學生時代開始參與軟體專案至今，雖然才短短幾年時間，在軟體設計的技術及方法論上，就已經出現了不少的變化。這從許多販賣專業電腦書籍的書店就可以略知一二了。雖然現在這些書店的電腦書還是以基礎技術實作以及工具使用的書籍為大宗，但是這2、3年來，已經出現了越來越多如Pattern、軟體架構、UML、UP/RUP、Open Source Framework甚至專案管理的相關中文書籍。這種情況代表著電腦書籍的市場，反應出目前業界的問題，也反應出了軟體技術演化的需求。

相信有許多老手當初在接軟體專案時，是從瀑布式流程的方式開始進行。從確定需求，到使用DFD分析客戶訪談所得到的資料並歸納出功能列表之後，大致就開始進行SA之後的工作。然後就定期地和客戶review進度，並且在每次的review　meeting之後又會有一些修改以及新的功能。週而復始地重覆這個夢魘，直到終於上線後，開始祈禱系統短期之內不要有事就好了。

以前這種方法，是從客戶所要的功能項目開始專案的開發，注重的是輸入、輸出與資料，很程序性地完成需求，就像是一根根直通通的水管，把水運到目的地就好，不需要真正的OOAD，大不了需要OOP，十分地直覺簡單。但是由於技術及軟體市場的演化，在台灣開始出現了許多現在大家耳熟能詳，諸如這幾期的軟體美學連載裏所提到的技術，我才開始感受到，在我們市儈的專案心態之外，軟體設計也有其美學之道的。

迷思與挑戰
在這8篇連載文章裏，筆者從物件（Object）技術、Pattern、架構到UP談起，因為這些東西是習習相關的，我希望能表達出這些技術的完整性。然而在這些不同的主題裏，充滿了許多常在技術會議或討論網站上出現的議題，例如，學UML等於導入OO、Use Case與DFD的比較、OO思維與資料思維、再利用迷思、Iterative與Waterfall等等。以下筆者僅針對部分的迷思討論，提出個人主觀的想法。

學UML等於導入OO？
在之前的篇幅中，筆者都沒有提到UML，因為它只是一種提供思維表達的工具之一。雖然有一些在坊間講相關主題的書籍會以UML的學習做為開埸，不過工具的用途在於被使用，與思維本身沒有直接的關係，就像哈利波特的故事可以用許多不都的語言在世界流傳一樣。UML是用來表達物件觀念的絕佳工具，不過，千萬不要將導入UML與物件思維畫上等號。

Use Case與DFD？
許多人會拿這兩種技術來比較，殊不知這兩種技術有著本質及面向上的差異，無論學理或實作，都不應該將他們混為一談。「Use Case」技術純粹用來「描述」使用者需求，是以「使用人員」的觀點來看他們與系統的互動，它比較接近傳統瀑布式流程中SA階段的「確定需求」步驟。Use Case Diagram則是用UML來視覺化Use Case文件的工具，有點像圖像化的需求索引，它不是「Use Case」技術的全部。另外，因為Use Case的觀點與客戶使用系統的方式一致，因此從Use Case來設計Test Case可以比較容易測試出用戶所關心的東西。

而DFD是結構化分析中「分析需求」的工具，它是以開發人員的角度來看系統，以資料流為中心，找出相關的程序及資料儲存等等，它是瀑布式流程中SA階段「確定需求」的下一個步驟。DFD需要有一定程度的客戶，才有可能和您一起討論。當然，與客戶的需求確認，Use Case文件或Use Case Diagram，也不見得是與客戶確認需求的好方法，端看客戶的習慣與能力，有時UI Prototype再加上Functional List就能簡單地與客戶溝通。

OO思維與結構化分析？
有人會將DFD當作OOD及OOP的開端，但筆者認為由於物件導向思維與結構化分析在本質上的不同，這樣做就像讓狗來生蛋一樣地奇異。這兩種思維，有著截然不同的思考出發點，OO是結合「行為」與「資料」，強調抽象並用物件來呈現概念，而結構化分析則是清楚地將這些東西分開。OOA中包含了物件分析，就是找出並描述領域模型（Domain Model），接下來才有辦法完成OOD，因此，怎能把DFD當作OOD的開端呢？物件可不是天上掉下來的禮物啊。

OOA中的Domain Modeling是結構化分析不會出現的概念，它也是OOAD中，從「需求」進化到「物件設計層次」中間的重要媒介。在實作上，也有人會把它放到Use Case之前，把它當作整理Use Case的第一步。對於OO的抽象設計來說，Domain Modeling的結果，常會連結到Interfaces（types）而不是實作，這個觀念對於領域知識在系統設計上的「再利用」，有著不少的幫助。

在實際的軟體市場上，有人會說大部份的系統都在使用RDB，而OO無法與關連性資料的思維整合，因此以結構化的分析來設計會好的多。我們先撇開世面上的OR Mapping相關技術不談，如此的說法沒有考慮到OO的「抽象」能力。筆者在這裡當然是不建議各位使用OO的方式來設計資料庫，因為如果這樣做，即使DBA不跳腳，系統的執行效率也會有問題。這時可以使用Layer的觀念替系統設計一個抽象層，用它來連結OO與資料的世界，把物件設計與資料庫設計的專業分開。

Iterative與Waterfall？
不管你喜歡用那一種技術來開發軟體專案，都會牽涉到專案進行時的流程，像是UP/RUP和Waterfall。有些人會認為UP/RUP所強調的Iteration開發方式，不符合台灣的文化國情，所以可能比較適合產品型的專案，而不是一般商業整合型的專案。因為大部份的專案是固定價錢的，使用這種流程會導致成本的增加，因為客戶不會另外付費支付多出來的Iteration。不過，在這種情況之下，Waterfall的流程一樣也逃不過工期的延長而增加成本的命運，同樣的，難道開發產品就可以容許成本的增加嗎？因此，這個迷思的重點在於Iteration Plan以及專案管理能力，而不是方法論本身。

結語
在我們所處的環境中，許多的軟體專案是偏向商業的資料庫系統，而軟體公司的接案心態大多都以系統能在最短的時間結案為重心，不太考慮完整售後客服所需的能量、團隊經驗的累積，甚至是與世界接軌的機會。至於軟體專案的買方，常見的狀況則是固定價格及時間，但卻有不固定的需求。在如此惡劣的發展環境之下，在國內的軟體專案市場裏討論軟體美學，的確是充滿了迷思與挑戰。如果一個軟體公司或軟體人只把自己定位在做小型的商務資料應用專案，那真的只需要一些簡單的結構化分析流程以及編程技術，就夠處理大部分的專案。然而國際上的各式軟體技術及方法論快速地發展著，筆者著實希望我們能夠跟上國際的腳步，進而發展出自己的價值。

葉政達
艾群科技研發中心技術經理，中原大學電子工程研究所碩士。曾任職於網際商擎科技、台聯電訊研發工程師等職，專精於OOAD、軟體架構設計、Pattern、J2EE、J2SE、行動運算應用；通過SCEA、SCWCD、SCJP等認證。曾參與電子商務系統、航空即時訂票系統、SNMP網路管理產品開發、亞太電信QMA Image Solution、Sandio Mobile Sync產品設計開發等專案規畫建置。