發表者

討論內容

冷日
(冷日)

發表時間：2008/3/19 7:52

Webmaster

註冊日: 2008/2/19
來自:
發表數: 15771

[分享]軟體設計美學之道第1回——美力時代？軟體烏托邦

軟體設計美學之道第1回——美力時代？軟體烏托邦

前幾個月讀了一本封面標題為「美力時代」的商業周刊，封面的小標──「當美成為時代的新競爭力，你也該為美感能力建立存摺」，讓我愣了幾十秒：這是多麼簡單而又令人震撼的一句話，道盡了近年來世界科技及經濟的進化。

美感這兩個字可以應用到人們感觀所能觸及到的所有事物，因此除了看到的商品，享用的服務也一樣開始受著「美力」所影響。從最近蘋果電腦的白色旋風iPod，以及由ICQ啟始而影響人們溝通習慣的網路即時傳訊、部落格(Blog)到網路相簿(如最近熱門的Flickr)等等，大家應該就可以感受到了吧。由「美力」所帶來的經濟力是如此強大，各行各業的產品也好，服務也好，都越來越講究精緻甚至豪華，產品或服務的功能面已經是基本的要求，似乎美的展現才是大家的決戰點。

美的本質是創造力

其實美的追求是人類的天性，當社會進步到某一個程度，我想這是合理的現象，人類也是感觀的動物，遇到美麗的事物，人們可以利用五官，甚至是心去感受，而「設計」，是表現出美的方法之一，例如華裔建築師貝聿銘為法國羅浮宮設計了一個玻璃金字塔入口，那是一個很美的架構，人們即使不懂它的設計原理，也可以用眼睛去欣賞它的外觀，用心去感受它古典造型及現代建材的融合。

我常常在想，那軟體設計的工作呢？軟體的「設計」有人能看的到嗎？它的美有價值嗎？當我在讀《Software Architecture in Practice》一書時，封面的羅浮宮玻璃金字塔照片表達了軟體架構的美──就和偉大的建築一樣，而差別只在於建築是人人看得到摸得到，而軟體架構卻不是。既然如此，軟體的設計需要美學嗎？還是只在學理派的烏托邦才看得到呢？美學大師蔣勳的一句話「…美的本質是創造力…」，讓我更相信自己心中的軟體烏托邦，軟體的本質也是創造力，「設計」則是讓創造力具化出美的手段。

看到這裡，也許有一些經驗較豐富的軟體人會笑說，在臺灣的軟體環境裏，軟體美學是沒有價值的。可能是因為臺灣的軟體市場小，所以臺灣的軟體公司資本也比較小，讓臺灣的老闆比較重視馬上看得到的「錢」途，而大家也總是比較重視「看得到的設計」，對於「看不到的設計」，在沒發生任何狀況前，大多是自然地忽略，因此就養壞了市場對於軟體設計的不尊重，並間接影響到軟體開發人員的價值。我姑且不評論這個適合放到討論網站的題目，以及會變成砲灰的答案，因為事情的看法常常和信仰有關，而現實的對與錯是不會影響到信仰的，對不對？所以先來談談我所看到的軟體美學吧。

軟體架構之美好比建築之美
我不得不拿建築來比喻軟體開發，因為真的太相似了，建築師設計出建築藍圖之後，需要有各類專家依照藍圖的設計，真正地將房子蓋起來，而軟體開發也是同樣需要設計及實作的。那什麼能夠感覺到美呢？一個建築師發揮創意所蓋出來的房子，應該是兼具美麗外觀、安全與實用等等，人們可以從建築的實體，感受出建築師的創意，進而感受出這一種美的「思維」，因此，除了形狀、顏色、聲音或者動作可以讓人感覺到美，思維也應該能讓人感覺美，而設計就是一種高度的思維活動。

從建築師的「創意」到施工實作的過程中，還需要「溝通」，不然思維是無法實現的。相同的，軟體的設計就是將「創意」的思維表現出來，有創意的軟體設計必需要能與實作者溝通，而溝通最好的工具，就是共同的語言。

有空多敷Pattern面膜
近年來OOAD盛行後，匯集物件導件精髓的Design Pattern，就是用來發揮創意解決問題並且表達溝通最好的共同語言了，在軟體設計人員驅之若騖學習之餘，大家除了要了解它的使用時機，其溝通的意義也是很重要的。

美麗，真的該從頭開始，身為軟體開發人員應該有空就敷一下Pattern面膜，因為這些是許許多多前人所留下的智慧，當你從其中感受出設計思維之後，對於這些美麗元素能不發出讚嘆都會很難，我也是在了解Pattern的過程中，慢慢地體會到物件導向的精神。

軟體架構的風格與結構
一個軟體系統就像建築一樣，有其風格及結構，就是所謂的軟體架構。調理出好的架構體質對軟體系統未來的美麗外觀、堅固安全與實用是非常重要的，這和一般疊床架屋的蠻幹方式有很大的不同。

使用思維來塑造軟體架構的美感，也就是使用Pattern來設計軟體架構，並且以架構為中心的開發方式，可以讓設計的美麗從軟體核心一層一層地透出來。而物件導向的精髓提供了軟體架構許多巧妙的設計或者擴充空間，進而影響軟體未來的實作與發展。

一個軟體專案的開發過程當然包含了許許多多不同領域及責任的專家們，這是一種需要團隊合作的藝術，單純的利用Pattern來溝通創意當然是不夠的。專家們有不同的理念及需求，這是一個複雜的現實環境，而藝術與現實的結合才能實現創意，才能讓人感動吧！

一個有效的軟體開發流程就像是一位導演，指揮著不同的專家，在適當的時機使用相同的語言，來溝通整合大家的創意及需求。因此有了思維還不夠，我們需要方法才能導演出美麗，甦醒軟體美學。

講了那麼多虛無飄渺的東西，感覺像藝術一樣距離遙遠，也許這真的需要在烏托邦才做得到，當然，尋找軟體烏托邦是充滿挑戰的，而膽識是必要的條件。

《作者簡介》葉政達

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

回覆

冷日
(冷日)

發表時間：2008/3/19 7:53

Webmaster

註冊日: 2008/2/19
來自:
發表數: 15771

[分享]軟體設計美學之道第2回──軟體的美麗元素──設計思維

軟體設計美學之道第2回──軟體的美麗元素──設計思維

世界上大大小小的事件、每個人的想法、做法，只要不是具象的事物，就都是抽象的，而軟體設計的思維亦是如此。

在軟體設計的領域中，物件導向的設計方式是個抽象的分析思考法，很適合在虛擬世界裏面表達出真實世界的需求。

雖然物件導向的技術已經行之有年了，但是真正了解其觀念，並且能將其思維放到實際設計與實作上的人並不多，可能是因為受到現實環境的影響。

以Java來說，筆者就看過許多使用Java寫出C程式風格的例子，以應用面來看，這樣實在談不上有設計思維，只能說是透過程式撰寫一行行地列出工作而已。然而也許是因為這樣的觀念不清，導致利用Java開發的系統效率不張或者幽靈問題不斷，而讓人誤解Java系統的好壞。

物件導向的關鍵哲理－抽象

物件導向是一種很有趣的分析「哲學」，它試圖從人們對真實世界的看法及感受來解釋屬於虛擬世界的軟體。從分析問題領域，進而轉成相對應的程式碼，都是在模擬真實世界裏的自然過程。

真實世界的事物是瞬息萬變的，而軟體開發也是如此，唯一不變的，就是恆變的需求。因而，「抽象」則是描述「瞬息萬變」的一個重要並且安全的方法。

抽象的觀念也是大部分的人在學習或運用物件導向觀念時，比較容易遇到的瓶頸。所謂的抽象，簡單來說，就是「萃取」出的概念，而且和實作無關，因為真實問題背後所隱含的意義，往往無法從直接的實作中得知。抽象的焦點是事物的本質特性，不同的觀點可以對同一事物抽離出不同的元素來，若是將抽象結果對映到真實世界中，有可能是一個具體的東西，也可能是一個看不見的概念。

抽象有助概念與實作的再利用
想像一個簡單的例子，在人聲鼎沸的世貿電腦展裏，你能夠抽象出什麼呢？是某電腦公司的攤位、辣妹跳舞、某個品牌的電腦，還是拆解成攤位、辣妹、表演、消費者、產品、銷售、交易？若是後者，那麼將這些元素套用到家具展上，其實也沒問題。因此，抽象有助於「概念的再利用」，同樣也有助於「實作的再利用」及穩定。

如果我們要設計一個展覽館的軟體平臺，起碼，當電腦展要改成家具展時，只要重新實作產品內容，不用重新設計整個平臺，因為交易模式及展埸運作模式都是類似的。

大家在此應先建立一個觀念，物件導向的分析方法是由特殊到一般，由實體到抽象。抽象的觀念還可以在經過一般化（generalization）或者特殊化（specialization）的分析後，衍生出階層的結構，這一層一層的抽象結構，可以像一層一層的防火牆一樣，擋住一級一級需求變異的風浪。

以駭客任務說明物件導向
對物件導向技術有初步認識人都會讀到不少技術名詞，例如介面（Interface）、訊息（Message）、類別（Class）、抽象（Abstraction）、具象（Concrete）或者Pattern、IoC（Inversion of Control）、Dependency Injection、MVC（Model View Controller）等等，這些名詞都和物件導向的設計思維習習相關。我很喜歡的一部電影──駭客任務（Matrix），可以套用來說明這些名詞的觀念及物件導向設計的思維。

在駭客任務的電影情節裏，人類被所謂的「母體」控制在一個虛擬的電腦世界裏，在那個虛擬世界裏面的所有事物，例如行道樹、食物、味覺，甚至物理或化學反應，不管是看得到、感覺得到還是所謂的自然定律，都是電腦程式所創造出來的，而真實的人類卻渾然不知地被「飼養」在一座座充滿連接管線的生態槽裏。

看完電影後我不禁思考：如果我是那母體（Matrix）的架構師（architect），該怎麼設計那套系統？

我大概會利用複合技術（composition）的方法，再配合連結器（adapter）機制和真實世界生態槽裏收集人體各項類比訊號的生物介面連接，再轉化成數位訊號，然後將人類的類別（class）具現（instantiate）到數位世界裏時，利用dependency injection的方式，將經轉化的數位訊號注入人類實例（instance），並和那裏的所有事物建立物件關係，然後人類就可以在那個世界裏生活著。

這麼酷的想像，透過物件導向的技術來形容似乎就不難理解，它可以容易地傳遞設計的思維。然而，光是了解物件導向的原理，還不足以讓你變成一位好的設計師，好的設計作品應該是容易地再利用、擴充及維護的，因此除了抽象、封裝、繼承與多型的基礎概念之外，有經驗的老手可能還知道許多物件導向的設計原則，像是「封裝變異」、使用複合技術代替繼承、針對介面寫而不是實作。

設計思維的傳達與再利用
當你在利用上述這些設計思維來塑造軟體時，出現的另一個問題是：大部分的軟體開發不會是只由你一個人負責，而是團隊作業，然而在一個團隊中，要如何讓伙伴了解你根據這些物件導向基礎或原則所做的美妙設計呢？設計思維的傳達，變成了下一個問題，而這也意味著一個很重要的概念，那就是設計思維應該是可以再利用的。

物件導向的重要概念－介面
在物件導向的設計裏，表達抽象的一個重要設計概念就是「介面」，它也是物件導向的基石。這裡所指的介面有2種意義：Java語言上的介面（interface），以及概念上的介面，此處我們所談論的是後者──概念上的介面。

物件的介面界定出「外界」能送給它的訊息資訊，也可以說是「限制」了外界對該物件所能影響的範圍，對每個物件來說，介面也是了解另一個物件的唯一方法。以汽車的例子來說，我們看得到汽車的外觀，也看得到汽車移動的方式，因此汽車的外觀及移動方式，都是屬於汽車的介面。

至於汽車是何以能如此移動，是利用什樣的動力驅動－汽油引擎、柴油引擎或油電混合引擎，是採用什麼樣的傳動機制－前輪驅動、後輪驅動或四輪驅動，以上這些則屬於實作。

有趣的是，一個物件可以有一個以上的介面，這就是多形（polymorphism）的應用。舉個例子來說，臺灣之光－王建民，他是洋基隊的球員，他也是臺灣人，更是他父母的兒子，因此，以球隊的觀點來看，他可以幫洋基隊投球，以臺灣的觀點來看，他有國民的義務，以家庭的觀點來看，他必須盡到做兒子的責任，但是他都是王建民。所以，介面有點像是物件所扮演的角色，而角色當然就伴隨著「責任」，物件導向設計時的重點之一就是在做物件的「責任分配」。

有許多的Pattern或者Framework都要靠穩定的介面為其發展的基礎的，例如，DI（Dependency Injection）、MVC（Model View Controller）、Spring、Struts、JUnit等等，不勝枚舉。

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

回覆

冷日
(冷日)

發表時間：2008/3/19 7:54

Webmaster

註冊日: 2008/2/19
來自:
發表數: 15771

[分享]軟體設計美學之道第3回── 敷一下Pattern面膜，從頭開始美麗

軟體設計美學之道第3回── 敷一下Pattern面膜，從頭開始美麗

一個好的軟體系統，除了必須符合使用者的需求之外，應該可以容易地再利用、維護及擴充。要達成這個目標，需要多少的設計思維及創意呢？若是符合這個目標的系統，一定充滿軟體美學的精神。

軟體設計其實是一種藝術，它不僅需要靈活的設計思維及技巧，還需要平衡專案的資源及使用者的期望，因此不管從工程面來看，還是從管理面來看，都是一種藝術。而要秉持軟體美學精神來開發軟體系統，其最深層的根基則必須要以「Pattern」來支撐。

相信有許多軟體開發人員會覺得：Pattern和自己開發的程式碼好像是兩回事一樣，不知如何理解及使用，更不會了解它和軟體架構、開發流程，乃至於整個開發專案的關係。美麗，應該從頭開始，開發一個好的軟體系統也是一樣，就讓我們從敷Pattern面膜開始。

我們先想像一個情境，假設你是一家比薩餐廳的大廚，現在有兩位客人向你點餐，第一個人說：「我要一份蝦仁搭配鳳梨、洋蔥的比薩，蝦仁要多一點，再加上一份灑上墨西哥辣椒、洋蔥、美式臘腸、義大利肉腸的比薩，不要太辣，外加一份法國香蒜麵包及2瓶350毫升的百事可樂」。第二個人則說：「鮮蝦鳳梨及哈辣墨西哥比薩各一份，外加一份香蒜麵包及2瓶小瓶的百事」。

如果你是大廚，你會比較希望聽到哪一種點餐方式？除此，這兩個人的點餐方式有什麼差別呢？其中最大的差別就在於第二個人使用了大家都了解的餐點名稱，大大地簡化了點餐所使用的語句，而且所表達的意思和第一個人所要的差不多。如此身為大廚的你不僅容易理解顧客所點的餐點，也容易記憶他要的東西，並且節省了彼此溝通的時間。相較之下，你聽到第一種點餐方式是不是很想把他轟出餐廳呢？

Pattern的溝通力量
我們再來看看物件導向的程式設計。一個設計老手一定熟悉許多物件導向的基本原理及設計原則，當他在解決一些設計問題時，會很自然地運用這些技巧及經驗，設計出解決各式難題的藍圖。

假設你就是這位設計老手，而你剛好要跟伙伴說明這個絕妙的設計。你可能會說：「我先建立一個super abstract class及兩個繼承於它的sub-class，並在其中一個sub-class中建立一個往super abstract class方向的association以便形成container功能，這樣就可以先完成一個遞迴的類別結構，然後在那container class實作一個final的method，用來固定的呼叫super abstract class所定義的抽象方法，這樣在未來繼承於此container class的類別階層的所有物件，都可以動態地被加入到執行時期物件模型的遞迴結構，透過分別修飾原有功能來增加新功能」，不知道說到這裡，有幾個人聽得懂的呢？

或許你可以用更簡潔的方式來表達，你可以說：「在這個部份的設計，我要建立一個Decorator Pattern」。一句再簡單不過的話，就足以表達上述那段又臭又長的演講，甚至所傳達的意思還更為清楚。這就是「共用詞彙」的力量，也是「溝通」的力量。

在前一篇「感受美麗的元素，設計思維」中有提到，大部分的軟體開發都是團隊合作，要讓大家了解自己偉大的設計，光用言語及UML來表達可能不夠，還必須注意傳達設計思維的問題。由於每一個Pattern的設計都是基於物件導向精神及原則，在應用上來看，它們保證了軟體某個程度的彈性及穩定，除此之外，「溝通」則是另一項非常重要但卻比較少人體認到的功用。從Pattern的定義來看：「一種在某個特定情境下，為了解決某種問題的解決方案。」因此，還要再加上某個特定「名稱」，才能算是個Pattern，才能和別人溝通。

3類常見的Pattern
Pattern有很多種類，只要符合定義的都可以稱做Pattern，但我們先把Pattern簡單的分為三種常見的種類，分別是「Architectural Pattern」、「Platform Pattern」及「Design Pattern」，代表三種不同層次的應用，因為每個層次都有各自不同的問題。

Architectural Pattern針對的是軟體架構，如Pipes、Broker、MVC等等。

Platform Pattern針對的是某個特定的發展平臺，例如J2EE Pattern。

而Design Pattern就是大家比較耳熟能詳的，例如四人幫（Gang of Four，簡稱GoF，這四個人分別是Gamma、Johnson、Helm、Vlissides）的聖經級著作《Design Patterns: Elements of Reusable Object-Oriented Software》一書中，所探討的是針對一般化的問題，而不是特定領域的問題。每個領域的Pattern幾乎都可以看到Design Pattern的影子，因為它提供了最基礎而穩固的設計元素。

看到這裡也許有人會說，有那麼多開放原始碼軟體可用，為何還要用Pattern呢？這其實也是個事實，我們常常尋找好用的開放原始碼Framework作為開發系統的骨幹，例如，Struts、Spring、Hibernate等等，通常我們只要加上一些客戶需求的程式碼，拼湊一番，就可以上線了，似乎用不上Pattern。但是，除了要注意開放原始碼的授權種類之外，還要注意那些Framework，是否有助於我們讓自己的程式碼容易地維護、再利用及擴充？是否有助於我們去「溝通」？再者，這些著名的Framework都是使用Pattern來設計的最佳範例，因此理解Pattern對於了解Framework的精髓，及如何整合入自己的系統，有很大的幫助，才不會誤解Framework的整合方法而張冠李戴，這就是使用Pattern的最好時機及理由。

必學23個Design Pattern
初學Pattern的人一定會覺得Design Pattern很難放到自己的設計上，這個因擾大部分來自於所學的Design Pattern太少，只學習了幾個Pattern就急於使用，就很容易會為了使用Pattern而強用Pattern，反而是化簡為繁。因此，首先要盡量讓自己對於Pattern有多一點的理解。我認為GoF所歸納出來的23個Pattern，是你該理解的最基本數量，這麼說並不代表在設計軟體中就應該全數用上，重點是當你理解那23個Pattern後，對物件導向會更有感覺，所累積的原力會讓你較容易地「感覺」出，應該使用哪些Pattern。其實在做程式碼的Refactorying時，是最好的練習時機，因為你可以從現有程式碼，慢慢修改到某個Pattern的形式，要記住的是，Pattern只是心法，如何變化出招式是靠你的美感，實際的設計是沒有必要和Pattern所定義的形式完全相同的。

《作者簡介》葉政達
艾群科技研發中心技術經理，中原大學電子工程研究所碩士。

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

回覆

冷日
(冷日)

發表時間：2008/3/19 7:54

Webmaster

註冊日: 2008/2/19
來自:
發表數: 15771

[分享]軟體設計美學之道第4回──要美麗先調體質

軟體設計美學之道第4回──要美麗先調體質

「架構」一詞意味著什麼呢？這個看似學術的名詞，其實在我們的日常生活中也常會聽到的，例如，文章架構、組織架構、發展架構，它在形容事物的一種風格、組織方式或著決策方向。

在這裏我們要談的是軟體架構，顧名思義它也是指軟體的一種風格、組織方式或著決策方向，不過這樣的解釋可能不好理解，畢竟軟體本身是一個複雜的創意。軟體架構的重要，就如同每個人的體質，從身體的最深處，一層一層的影響到外表的美麗。

軟體架構雜亂，專案失敗風險高
我曾經歷過一個經典且傳統的軟體專案，那是一個旅遊網站，旅客可以在網站上透過聰明的航程規畫精靈即時地比較機票的價格，然後直接訂機票並且線上付款，流程中幾乎不用和旅行社的票務人員交涉，除此之外，在那個網站上也可以查到各式旅行資訊。

和大部份的軟體專案一樣，在這個案子裏有一位野心勃勃的老闆，另外，我們有一些極熱心但是擁有類比腦（完全不懂電腦）的旅遊專家──就是票務小姐及票務經理，然後我們需要和信用卡系統及一個世界級，但是穩定度及整合介面是古蹟級的票務系統介接，最後還有一群從沒搭過飛機，但視加班為進補的程式開發人員，我們要做的系統包含了旅客會直接使用的訂票網、票務小姐管理票務的後臺系統、跨平臺介接的即時訂票系統及線上付款系統等等。

這個專案包含了許多不同的「角色」及「需求」。角色有旅客、老闆、票務人員及軟體開發人員等等。他們都有各自己的需求，例如，旅客希望票價便宜並且系統使用安全、方便及穩定、老闆希望以最少的成本及時間就能上線、票務小姐希望系統能減輕她們後臺票務的工作量、行銷業務希望什麼功能都有、開發人員希望系統設計彈性或者使用熟悉的技術來開發。

於是乎，開發人員為了符合大家的需求或者某個特殊活動的需要，開始了一夜夜悲壯的軟體開發戰役。而在系統尚未穩定之時，沒想到老闆竟想要複製「成功」經驗，開始建立兩岸三地的作戰堡壘，因此系統也由小恐龍漸漸地變成了究極大怪獸。

「使用介面風格不一致、訂票系統容易斷線、訂票回應速度太慢……」，一連串的問題陸續出現，然而最終沒有人真正了解問題的來源或者可以解釋細節。這個沒有人能控制的大怪獸終於帶來了最後的審判日──失敗的軟體專案。這個專案失敗的原因很複雜，包括了使用者接受度、商業模式（Business Model）、政治因素、專案管理控制等等，當然有很大的一部分原因是：它擁有一個雜亂的軟體架構及一個無法控制的系統。

軟體系統的最高指導原則
所謂的軟體架構，簡單的來說，就是定義一個軟體系統未來發展的「最高指導原則」，就像憲法一樣，在未來的發展中不可抵觸，例如，系統該分成哪些模組、要用哪些技術、元件間的溝通介面是什麼、元件間的互動行為要用哪些Pattern。

這些最高的原則當然是由各種需求或者開發團隊的能力分組所引導出來的，例如，分成三層，並分給三個不同能力的小組來完成，或者使用訊息中介軟體介接外部系統，縮短使用者的等待時間並增加系統的穩定度及可靠度等等。這些最高指導原則訂定了整個軟體系統發展的大方向，也等於限制住系統技術發展的最大範圍，進而防止系統開發走向錯誤的方向，並且讓開發人員有一個技術的依歸，可以踏實地完成系統開發。當然，憲法是可以修的，只不過必須經過正式的修憲會議而已，軟體架構也是一樣，不然在偏離架構範疇下所開發出來的軟體，最後還是很可能會誤入歧途而失敗。

在《Software Architecture in Practice》一書中，作者Bass、 Clements、Kazman對於軟體架構以比較學術的方式來解釋：「軟體架構是一種系統的結構，「包含」並「定義」了許多軟體元件及其間的組織方式和互動行為」。換句話來說，軟體架構有許多軟體元件、一個以上的結構以及它們之間的各種關係。除此之外，架構還包含了非功能面的條件，像是QoS（Quality of Service）或是SLR（Service Level Requirement），它包含可用性（Availability）、可信賴（Reliability）、可擴充（Scalability）和安全性（Security）等等。

上述這個定義也暗示著任何一個軟體系統都有軟體架構，只不過和系統本身的好壞無關。對於一個軟體系統來說，架構並沒有絕對的好與壞，只有適不適合而已。例如，一個時間緊迫並且規模小的網站系統，就沒有必要一定要用MVC的架構來開發，它也可以很簡單的利用Layer的觀念並且配合資料封裝技術來實作。建立軟體架構的關鍵在於能夠提供軟體系統未來實用而穩固的發展基礎，這是很重要的一點，因此架構不應由錯誤嘗試中得到，它應該是經過認真的設計及規劃出來的，而架構文件則是架構設計後所該留下的重要結果，也是未來開發的依據。清楚的架構設計有利於開發過程的「溝通」、系統的「演化」以及未來產品線開發的「再利用」。

平衡軟體專案元素，建立扎實軟體架構
通常一個軟體系統，打從娘胎開始就會不斷地受到各種需求的影響，但同時滿足所有的需求是不容易的，因為有許多的需求是相互抵觸或者是有隱含的意義。軟體的「開發過程」就是在協調及滿足這些需求，而過程中，如果沒有好好地規畫軟體設計的發展策略，軟體系統很容易會變成多頭馬車，進而演變出疊床架屋的架構，充滿隨時倒塌的危險。

架構師的責任就在於利用自己的經驗來「平衡」專案相關人員需求、開發團隊技術能力、技術環境及成本等元素，進而建立出扎實的軟體架構。雖然我們都知道軟體的本質是「恆變的需求」，但是在我們擁抱改變的信念下，還是不可能從咖啡機中煮出紅酒來的。
「軟體架構」就像是一個人的體質，它會影響軟體系統未來的生老病死，因此在開發軟體系統前，請先好好的調理它。

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

回覆

冷日
(冷日)

發表時間：2008/3/19 7:55

Webmaster

註冊日: 2008/2/19
來自:
發表數: 15771

[分享]軟體設計美學之道第5回──塑造軟體架構的美感

軟體設計美學之道第5回──塑造軟體架構的美感

我們都知道，蓋房子都會有一個挖地基，打地基的步驟，而且依據房子的類型及用途，地基的工程以及結構的材料也會有所不同，這些都是經過建築師專業而仔細的設計及計算才得知的，為的是房子未來的安全及使用需求，甚至是施工過程的安全及順暢度等等。

軟體建造的道理，其實是一樣的，大家也都希望不僅開工順利，最後也驗收順利，最好是在保固期內，什麼事都不會發生。

建立軟體架構的目的，就在於提供系統一個穩固而堅實的發展基礎，而其具體的產出，就是一份軟體架構書以及依照架構書這個最高設計原則所建構出來的原型（Prototype）。這樣就可以讓後續加入的工程團隊遵循架構設計所表達的美感，並照著原型的建造工法，來繼續大部份尚未完成的工程。

當你決定使用以架構為中心的開發方式時，這兩個產出是連接架構設計階段及實作階段最重要的東西。當然，軟體架構的設計不是一、兩篇文章就可以解釋清楚的，本文僅將一些比較重要的概念及經驗提出來，希望能給初入門的讀者有個概括的認識。

所有的故事，都是從需求開始
任何一個軟體專案的開始，都是為了滿足某些特定的需求，這是一句廢話，但也是一句非常重要的話，因為當我們在塑造軟體架構的時候，顯性的需求或其所帶來的隱性特質，都可能是影響日後系統成功的關鍵。顯性的需求是客戶最直接的期望，他可以明確的告訴你說，他需要在某個畫面上加一個按鈕，讓使用者可以簡單的按下按鈕，就輕鬆地訂到機票並且自動地完成付款，但是客戶可能不會清楚使用者在按下這顆按鈕時，不希望等待時間超過10秒鐘，他更不會知道從按下按鈕，到系統完成所有的工作，是經過幾萬行的程式並和幾個外部系統連線後才會有的結果。而一百或者一千個使用者的規模，對於軟體架構以及開發成本，又有著截然不同的設計，往往客戶和開發人員的期待落差，就此產生。因此，影響軟體專案成敗的地方，大部份不是顯性的需求，而是隱藏在那背後的邪惡靈魂。

透視需求，找到架構觀點
不知道各位有沒有做過健康檢查？當你在健檢中心做檢查時，通常會有好多的關卡，而您會像過關斬將般地面對一站一站不同的儀器及醫生，每一站所檢查的內容都不一樣，例如骨科醫生看到的，是你的骨質狀況；腸胃科看的是你的腸胃健康，他們唯一做的同一件事，就是在檢查同一個你。

人類是一個完美而複雜的系統，人體的複雜當然不是只有我們看的到的外表，這是我們都能了解的事實，而軟體系統也是一樣。以UP（Unified Process）這個軟體開發方法論為例，它有幾種架構觀點（views）；使用案例觀點、邏輯觀點、執行觀點、部署觀點、實作觀點等等。這些軟體的觀點，就像是不同科的醫生對人所看到的不同觀點一樣，都是在描述同一個軟體系統。

設計架構的工作，其實就像醫生角色伴演的遊戲，你要伴演各科別的醫生，透視軟體系統，從外在功能面上的需求，找出隱含在各種觀點背後的需求，然後再像建築師，設計出滿足這些需求的架構。
顯性的需求通常所描述的是「使用案例」（Use-Case），這是以使用者的觀點來看系統的外觀長相，看的到的東西都是屬於功能性的需求，例如，會員管理、票價查詢、訂票等等。

在這些顯性需求背後所含的隱性特質，就是所謂的SLR（Service Level Requirement），其中包含了可靠性（availability）、可修改性（modifiability）、效能（performance）、安全（security）、可測試性（testability）、可使用性（usability）等等，而滿足這些從使用案例觀點所發覺出來的SLR，就是「邏輯觀點」以及其他的架構觀點的責任了。

滿足需求再描述設計
在滿足SLR及設計架構觀點的過程中，我比較建議從「邏輯觀點」開始，因為它是在描述軟體實作時所需的設計概念。在這個觀點裏，會有較高層次的設計元件，包括Package、Subsystem、Interface等等，它會直接影響到執行觀點以及實作觀點的設計，當然，部署觀點也是一樣。只不過通常部署觀點會有需多客戶本身的限制，例如，客戶需要用掉之前的機器庫存或者預算限制等等，因此在專案開始前，這個部份有時是被限制住的。其實這些架構觀點都會因為某些需求而互相影響，端看架構師的智慧及經驗來取捨。

對於這些架構觀點詳細的說明或舉例，因為篇幅的關係，建議各位去讀讀UP相關書籍及Craig Larman所著的《Applying UML and Patterns》一書，大家會有更清楚的了解。

「凡走過，必留下痕跡」，以上所說的種種觀點，如果沒有記錄下來，架構的設計也就沒有意義了，一般來說，我們會將這些設計內容一一地寫到所謂的SAD（Software Architecture Document）－軟體架構書裏，這是系統未來開發的最高指導原則。而為了系統後續的開發順利，在SAD完成後，我們還必須分析並找出架構設計裏面的指標因子，例如風險較高的技術、連接子系統的關鍵、影響程式撰寫風格的部份等等，然後進行細部設計及實作這些指標因子，使成為所謂的Prototype。接下來，開發團隊的大部份成員就可以遵循著SAD及Prototype的腳步，比較穩健而安全的開發下去。

用Pattern的美感來表達軟體架構
Pattern是一個很重要的軟體設計技術，從定義中我們可以知道它是在一個特定背景下，已被命名而且為了解決某個特定問題的解決方案，而Architectural Pattern更是針對架構性的問題所發展出來的，例如在POSA1所提的，Layers、Broker、MVC等等。現在世面上所流行的技術或Open Source Framework，像是RMI、Struts等等，都是基於上述的Architectural Pattern所發展出來，當然，在做架構設計時，reuse這些技術框架也是省時方便的策略。

一般的軟體技術，如OO的基本原則，或者系統分析設計方法並不一定能真正地解決特定的SLR，因此這些已驗證過的Pattern可以做為設計軟體架構時，滿足特定隱性需求最佳的架構單位，除了利用Pattern來建構一個穩固的軟體架構之外，其利於溝通的特性讓你容易地將你的設計記錄在SAD裏並讓後續的開發團隊易於了解。讓自己的「創意」經由「溝通」而能確實實現，我想是這是每個軟體人的希望吧。

對於這些架構觀點詳細的說明或舉例，建議各位去讀讀UP相關書籍及Craig Larman所著的《Applying UML and Patterns》一書，大家會有更清楚的了解。

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

回覆

冷日
(冷日)

發表時間：2008/3/19 7:56

Webmaster

註冊日: 2008/2/19
來自:
發表數: 15771

[分享] 軟體設計美學之道第6回──統一流程（Unified Process）

軟體設計美學之道第6回──統一流程（Unified Process）

為什麼需要流程？
雖然之前的文章都在談論軟體美學，但是在這篇文章，讓我們暫時先丟開這個浪漫傳說，回頭來看看真實世界的軟體專案。公司接案的最大目的是什麼呢？當然就是要能賺錢，這也許很俗氣，不過卻是事實。

軟體開發的專案有四個重要的變數－成本、時間、品質及規模，如果以企業生存遊戲的角度來看，那成本一定是最難控制的變數，而品質是客戶堅持的，時間是客戶規定的，相對之下，只要能符合客戶的業務需求，最容易控制的，我想就是「規模」了。因此我們可以假設在品質及時間不變的情況之下，若受到規模衝擊的影響變小，則成本也會下降，而在成本越小的情況下，公司的獲利當然也就會越多了。

只要能積極地管理規模變數，團隊及客戶對於其他三個變數的控制能力也能增加。因為通常客戶不會太清楚他們要的是什麼東西，真正的規模到那裡，當然，這不是他們的錯，軟體的本質本來就是恆變的需求，而軟體專案的開發本來就常處於「一寸以前，才是光明的」的狀況，開發團隊必需要協助客戶，幫助客戶找到他們真正的需求，幫助他們釐清可能的風險，一寸一寸地走，一點一點地將整個光明都找出來。

當一個團隊千辛萬苦地將一個軟體專案完成後，最重要的事情除了收錢之外，還有什麼呢？答案是「累積與再利用」，如果你是老闆，你會不會希望看到下次在接到相似類型的專案時，開發團隊可以利用更少的時間完成專案呢？因此，如何讓團隊能夠在每個案子產生一個正向的回饋，讓下次同類型的專案可以減低規模的衝擊，進而減少成本，最後提高專案的利潤，是一個非常重要的課題，而軟體元件重用（Reuse）的技術也就呼之欲出了，這時，以Pattern為基礎，並且以軟體架構為中心的開發方式將是關鍵。這整個過程，勢必需要一個軟體開發流程來指揮協調。

各式軟體開發流程

最常見的軟體開發流程就是線性或「瀑布式」的舊式流程，當然還有相當有名的XP（Extreme Programming）以及我們要討論的UP（Unified Process）等等。

軟體開發的方法論有很多，各有其巧妙及適合的時機，端看開發團隊的能力、專案類型甚至是文化國情。筆者就曾在某大電信公司，遇過某個開發團隊所採用的是「課長流程」（就是以該單位主管心中的喜惡為主的「無定向」開發方式）！相信這在台灣也算是一種流行的開發流程吧。

「瀑布式」的舊式開發流程常見的做法依序是收集需求、系統分析、系統設計，最後根據設計結果來實作。這會衍生出一些職位如系統分析師（SA）、系統設計師（SD）以及「最底層」的程序員（Programmer），因此除了開發步驟的每一個階段是線性的走向之外，時常連開發工作也會依職位的高低而變成官僚作風。有時在同一開發團隊的SA甚至會做出和Programmer實作不同的需求文件，因為真正的需求及設計最後是靠SD，甚至是Programmer以及客戶的「提醒」才找出來的。如此的開發方式，不容易應付恆變需求的軟體專案，更不容易累積可再利用的軟體元件，而開發工作的責任及角色雖然和經驗累積有關，但並不全然和職位的線性關係劃上等號，因為每一種角色都有其專門的責任及技術深度。

UP精神
「統一流程（unified process）」對於「管理規模變數」以及「提高軟體元件的重用」有著不錯的影響，而針對線性流程無法確實掌握需求與實作關係的缺點，也有不錯的解決方式。我們暫時拋開在流程裏常會令人心煩的工作項目及開發階段，先體會一下UP精神，這將有助於UP的實作。

UP精神最主要圍繞在三個方向，分別是Use-Case-Driven、Architecture-Centric以及Iterative & Incremental。以下我先簡述其重要觀念，針對工作流程及項目的協調運作，將在下一篇的文章提及，而關於UP的詳細內容，筆者建議大家閱讀「The Unified Software Development Process」這本書。

所謂的Use Case「Driven」，就是指團隊在執行整個流程時，都是從Use Case開始所有的工作項目。這樣可以讓開發團隊在每次的工作循環裏，以聚焦在客戶的需求為出發點，避免迷失在專案的規模中。Use Case是大家用來發掘並記錄功能性需求的一種技術。換句話說，它的功用在於找出對使用系統的參與者有價值的需求，並且能產生有價值及看的到的結果；例如，買機票、處理退貨、結帳等等。而Use Case也可以幫助我們開發使用者介面，讓客戶清楚他們未來要如何使用系統來完成他們的工作，幫助客戶找出他們真正要的東西，也幫助大家控制「規模變數」。

Architecture-Centric的概念最容易被想要實行UP的開發團隊遺忘。通常大家只會注意到UP所定義出來繁複的工作項目，並拘泥在工作項目的意義及執行時間點，殊不知以軟體架構為中心的開發觀念是UP在執行物件導向專案的支柱。

軟體架構的功用及開發步驟在之前的幾篇文章之中已經提過了，在此我只再強調其對於「提高軟體元件的重用」及「提供穩定的開發基礎」有著重要的影響。在Use Case Driven的觀念下，Architecture的開發是以支撐Use Case需求為目的，而Architecture的建構則會影響到那些Use Case可以被實現。

Iterative & Incremental意謂著透過回饋與調整來擁抱改變。在軟體需求的恆變性之下，我們需要反覆式的開發，讓軟體可以在一連串的建構、回饋與調整的循環之中逐步完成，這是線性式的開發流程所欠缺的。而這種短期、固定時間長度以及小規模的開發循環之下，可以讓軟體開發的複雜性變小，我們也可以用Risk-Driven的觀念，先開發風險比較高的部份，讓早期的進展減緩風險可能帶來的衝擊。

大部份的人也許會覺得UP是一部很笨重的方法論，拿來做研究還不錯，但是對於用在實際的專案上，則是望之卻步。其實在了解UP的精神後，再找出自己團隊或者專案適合的開發活動與工作流程才是真正的關鍵。UP其實可以很敏捷，也可以很繁重，端看團隊真正的需求。

《作者簡介》葉政達

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

回覆

冷日
(冷日)

發表時間：2008/3/19 7:56

Webmaster

註冊日: 2008/2/19
來自:
發表數: 15771

[分享]軟體設計美學之道第7回──隨著UP的樂章，讓軟體美學起舞

軟體設計美學之道第7回──隨著UP的樂章，讓軟體美學起舞

三大精神，四大核心，讓你UP起來
秀出設計，才能讓人感受思維的美，而實作出來，才能滿足現實的世界，軟體設計有其美學之道，它和建築一樣，可以利用「工程方法」，讓美學之道和實際需求接軌。在前一篇所介紹的三大UP（Unified Process）精神之下，還有許多在實踐專案時會遇到的開發階段和工作科目，其相互的運作流程與軟體設計之間的關係，是最難想像與實作的部份。

關於這些開發階段與工作科目，我想曾經讀過這個方法論的人都會很熟悉一個詭異的波浪圖（如右圖所示），這張圖是UP的精華，不過我個人覺得對於剛踏入UP的人來說，如果沒有好好地理解它，這張圖會像個鎮煞避邪的石敢當，反而就會把大家嚇跑了。

簡單地來解釋這張圖，它的X軸所代表的是四大開發階段以及許多的反覆期（Iteration），也代表著時間軸；Y軸則代表工作科目，而在此圖表上的大大小小波浪，則是代表專案隨著時間進行時，各個工作科目在各開發階段上的比重，其實這也隱喻著這四個階段有著不同的核心任務，只要能掌握這些靈魂，執行UP就能簡單不少。

是大餅，還是焦油坑－－Inception階段
專案的一開始，絕對不是一頭埋進成堆的客戶需求之中，然後埋頭苦幹地開工實作，因為你不一定會知道，前面的路是個焦油坑還是一塊大餅。雖然有時迫於情勢，就算是個焦油坑專案，我們還是得做，不過起碼我們可以先採行一些預防措施，例如使用符合成本的技術、資源，或者盡早另覓他處等等。

在這個階段的時間會比較短，因為重點在於確立產品範圍，了解專案關係人是否對專案願景有基本的認同。因此，在這個階段裏，我們可能會只先列出大部份使用案例的名稱，描述其中小部份，但卻非常重要、有疑慮或者風險較高的使用案例，甚至建立一些簡單的使用者介面prototype來驗證需求，然後針對一些不確定或者難度高的技術做POC（Prove of Concept）測試。

真正的需求開發以及軟體架構的建立，會是在下一個階段，而在Inception階段可能的唯一一個反覆期（Iteration）裏，是要能了解專案未來的路是通住天堂，或者是條令人心驚膽寒的天堂路。

給我架構，踏出美的第一步──Elaboration階段
當完成了Inception階段的工作並通過里程碑（milestone）的查核後，也不代表我們就可以放心地往前衝了。在這個階段裏，我們必需要釐清大部份的需求，但最重要的，是要能產出一個能夠解決高風險元素的「架構原型（architectural prototype）」。這也是整個UP流程和傳統的開發流程最不一樣的地方了。

實作此階段的關鍵概念就是要進行短時間且長度固定的多個反覆（Iteration）、優先釐清重要或高風險的需求，然後及早開始寫程式並測試，最後再將測試結果以及需求變化回饋到下一個反覆（Iteration）之中。除此之外，我們要記得另一個重要觀念－「建立軟體架構的關鍵在於能夠提供軟體系統未來實用而穩固的發展基礎」。

架構原型只是整個系統的骨幹及部份肌腱，因此，及早開始寫程式的意思是在於及早開始實作「架構原型」，並不是開始實作出系統的大部份哦。因為唯有不斷地透過開發、測試人員，甚至是使用者的回饋，架構原型才能真正的確定系統風險的解決，並成為下一個階段的穩定發展藍圖。

實作這個階段使用到許多軟體美學的重要技術及設計工具，例如，使用Use Case來描述需求細節、利用Domain Modeling來找尋軟體物件靈感、利用Pattern來設計軟體架構中的邏輯觀點等等。因此這個階段可說是整個流程的重心，也是軟體架構師最重要挑戰以及最大的舞台了。

開工、發包──Construction階段

這個階段會是整個流程裏面最熱鬧的一段時期，因為在成本可行並且有計劃的情形下，會有越來越多的人可以在這個時期裏加入團隊，甚至可以多個團隊一起工作，包括外包。為什麼呢？因為上一個階段的結束，代表我們已經了解了大部份的需求，解決了高風險的問題並且完成軟體架構原型、軟體架構書（SAD）以及架構原型的系統設計相關文件等等重要產出。因此，我們也比較能預估專案接下來所需要的工作量及時間，而現階段的開發團隊可以依樣畫葫蘆地照著架構原型的程式碼及其程式風格來開發建構系統其餘的部份。

軟體架構師在這個時期所扮演的角色就是開發團隊的領導以及教練了。軟體架構師此時必須掌握開發團隊所發展的程式是否遵循著軟體架構書所設計的大方向，並且時時利用架構原型都各部份為範本，教導開發團隊來建構系統尚未完成的部份，如此這般的，一個反覆一個反覆地往下走。這個階段的工作有時會有點像在填補Elaboration階段所建構出來的骨架的肉，也就是架構原型以外的所有東西。因此，這個階段的成功，和上個階段的結束，有著非常重要的關係，而這個階段的後期，團隊也該完成一些如使用者手冊等文件以及alpha測試，以便能替下一個階段的beta測試做好準備。

完美的收尾－－Transition階段
在經過前面三個階段之後，在這個最後的階段當然就是要做個漂亮的收尾了。這個階段的主要目的是將系統變成真正的產品，工作的內容可能包含了最後測試、針對測試結果所做的回應、展示、教育訓練以及將產品交付客戶等等。最後，當然就是希望能撇開一些可能的政治問題，順利結案並且拿到錢了。

在執行這些開發階段時，還有一個重要觀念：每個階段的結束，都是為了下一個階段的開始，因此每個階段的結束，都會有一些確實的，可以衡量的產出物（deliverables），例如，文件、程式碼、測試結果等等，這些產出物就是下一個階段最重要的輸入，這是個容易影響UP執行順暢度的觀念。

近兩期文章的種種，僅是極精簡的UP內容，UP方法論的細節的確很繁多，不過，規則永遠是人定的，只要能理解UP的三大精神及四大核心，再找出一個適合你所屬團隊的工作科目，才是真正的王道。

《作者簡介》葉政達

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

回覆

冷日
(冷日)

發表時間：2008/3/19 7:57

Webmaster

註冊日: 2008/2/19
來自:
發表數: 15771

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

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

在臺灣的軟體專案市場裏討論軟體美學，的確充滿迷思與挑戰。如果一個軟體公司或軟體人，只把自己定位在做小型的商務資料應用專案，那只需要一些簡單的結構化分析及編程技術；然而國際上各式軟體技術及方法論快速發展，著實希望我們能夠跟上國際的腳步，進而發展出自己的價值

技術的演化有其目的與價值
從筆者學生時代開始參與軟體專案至今，雖然才短短幾年時間，在軟體設計的技術及方法論上，就已經出現了不少的變化。這從許多販賣專業電腦書籍的書店就可以略知一二了。雖然現在這些書店的電腦書還是以基礎技術實作以及工具使用的書籍為大宗，但是這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產品設計開發等專案規畫建置。

回覆

主題一覽的下方

討論串

前一個主題 | 下一個主題 | 頁首 |

| |

發表新主題

軟工藝術 : [分享]軟體設計美學之道第1回——美力時代？軟體烏托邦