到底什麼是 “Component(元件)”?

前陣子看到討論區有人提問,元件與類別有何不同?
直覺上,覺得蠻奇怪的,怎麼會拿這兩者來比較?因為這兩者是不同等位的:類別是虛的;元件是實的。

類別,即是種類上的區別。簡單的說,即是「物以類聚」。自然而然,我們會把較同性質的事物擺在一起,以別於其他的事物。
所以,分類是一種本能(不一定單指人類才有這種本能),是一種從抽象的角度來區別事物在行為或特徵上的不同點。
為了作比較,我們會區分為動物類、植物類;再更進一步的觀察,又會再把動物類更細分為哺乳類、爬蟲類...等。在更深入,會再將哺乳類細分為人類、狗、貓、猩猩、猴子等各種類別...。
以此推知,元件也會分門別類,諸如,UI(User Interface)元件、企業元件(Business Component)、功能性元件(Functional Component)等。

在軟體設計上,如何分類,是一門相當深入的功夫。這又是另外一篇重要的主題了。
回到本標題,真要作比較,可能是元件(Component)與物件(Object)來作比較說明會來得恰當。

學習軟體設計多年,我個人覺得有兩個專業的字彙,是最難最難解釋的了:一個是 “架構(Architecture)”;另外一個就是 “元件” 了。因為,這兩個字太容易太容易被濫用及泛用了。
針對上述兩個字彙,我個人也思考多年,或多或少有些自己的見解(至現在為止,除了高煥堂大師有這種能耐可以解釋這兩個字彙,我還沒有看過有人可以說出此兩個字彙真正的意涵)。
因為是我個人的見解來解釋什麼是 “元件”。並無所謂絕對的「對」與「錯」,只能說:僅供參考!

閱讀全文 »

物件導向的軟體設計觀

由於軟體開發廠商致力於提供更好的物件導向化的工具,包括從物件導向程式語言(OOP,C++、Java、VB.NET…)至使用者端介面的開發工具(圖形元件化,如 Button、Textfield、Form…,乃至模型化的工具(Rational Rose for UML)。似乎,採取了這些工具,軟體開發人員就得以享受到物件導向化軟體開發的美麗新境界,得以脫離傳統軟體開發方式的夢魘。

殊不知,物件導向化的開發設計並不是萬靈丹,並不是採取了物件導向的技術,就能簡化軟體的設計 ; 再則,物件導向設計的思維,也不是由 UML、OOP、Tools 等這些表面所獲得的知識就可以能理解的。

物件導向化的軟體設計是從真實世界上人們面臨問題時,所運用的哲理及技巧來解答問題,將這些智慧及經驗的累積,來反應至軟體的設計思維。所以,並不是因為有了所謂的 “軟體” 才會有 “物件導向” 這樣的技術產生,反之,如何運用前人為了解決生活上的問題所累積的智慧及經驗,甚而創造自己的智慧,並將經驗傳授他人等這些技巧來反應至軟體的設計思維,才是軟體開發人員所需具備的涵養。

例如,介面(Interface)的設計,老早在現實的生活上隨處可見,好比,設計了雙孔插座,使得家電用品不需要知道內部複雜電路的設計,只要依循其規格:雙孔插座、110V 電壓,任何家電用品即可享用其共通的規格,造成了多型(Polymorphism)的效果,進而增加再利用(Reuse)的好處。

但反映到軟體的設計上,大部分的軟體開發人員卻沒有體認到介面設計的好處, “Design Pattern” 一書即提到:

「介面是物件導向系統的基石。想辨識物件,只有靠介面這條路 ; 若不知道介面,便無從得知物件的資訊,也無法叫它作任何事。物件介面並不含任何實做事項 – 物件有權自由決定該如何實做這些操作,因此,兩物件即使介面完全一樣,也可能會有完全不同的實做。」

為何需要這些生活上的哲理來輔助軟體的設計呢?主要的原因也就在於 “變” 這個因素。因為 “變” 造成了軟體系統開發的障礙,提升了複雜度、增加高度維護的成本。如果軟體開發人員一直無法認清這點,一直想以逃避的方式來凍結 “變”,既不合情合理、沒有人性化,也使得軟體系統無法順應善變的需求 ; 反之,若能認清 “變” 的本質,進而擁抱 “變” (Embracing Change),使得軟體系統能生意盎然、生生不息,而提升了軟體系統的高度價值,這反而因為 “變” 而帶來了更巨大的經濟效應。

軟體設計與交易<2>-What is Transaction?

資訊系統的設計,只有良好的 OOAD 是不夠的,同時也要考慮到分散式系統的現實環境,其中,Middleware 要能確保有穩健的交易環境是相當重要的,所以,對於 “交易(Transaction)” 這個術語,需要有清晰的瞭解才行。

在商業上, ”交易” 係指兩個契約當事人之間的一種交換行為。例如,向小販購買冰淇淋甜筒,是以金錢來換取零食 ; 在一家公司工作,是以技能及時間來交換金錢。
在交易的過程中,會試圖來保持交易的穩定性,也就是說,你會確信交易能符合雙方的期望,所以商業交易的第一法則定律就提到:

「Every movement of commerce in one direction is accompanied by an equivalent movement in the opposite direction」
(每項朝某個方向的商業行為,必然伴隨一個等值但是反方向的商業行為)

例如,您投一塊錢到公用電話機,電話公司就讓您通話三分鐘,這種商業活動是等值但呈相反方向。這符合商業第一法則,雙方誰也不欠誰,皆感到公平合理。萬一您投了錢幣,卻被電話機吃掉了,您會感到吃虧,就違背商業第一法則了。

在軟體系統上,交易就包含了商業上的交換觀念。針對企業資訊系統的交易,是一種 “工作單元(unit-of-work)” 的執行,以存取一或多個共享的資源(在實體環境上,資源經常是置於資料庫上),所謂的工作單元,就是一連串的相關活動必須一起完成。例如,向航空公司預購飛機票,”預購”的程序就是一個 “unit-of-work” 而組成許多的活動:記錄飛機班次及座位、信用卡刷卡(debiting a credit card)、產生機票,三個活動共組成一個 “unit-of-work”。

交易是存在於各種不同系統的一部份,而每一筆的交易,其目標都是一樣的:執行一串活動的 “工作單元(unit-of-work)” 而結果導致具可靠性的交換。

例如:
ATM(automatic teller machine):
主要功用為存款、提款、轉帳等。執行這些工作單元而成為交易。例如,執行提款的工作單元,首先,ATM 會檢查帳戶內的金額以確定沒有透支,然後再從你的帳戶內扣除該筆金額,並從 ATM 內吐出該筆現金,完成交易。

線上書籍及訂購:
例如透過 Web 向博客來訂購書籍,這樣型態的購買也是一種 “工作單元” 而發生了一筆交易。在線上訂購的過程中,首先鍵入了信用卡卡號,然後經由博客來訂購系統的驗證,費用就從信用卡上扣款,而書籍就經由郵局等掛號寄送過來,經由一連串的活動而完成了交易。

可以瞭解的是,交易是高度複雜並且經常伴隨的是訴諸於大量資料的操作,交易的過程當中如果發生錯誤,不僅僅是金錢的損失,甚而可能影響到身家性命!所以,交易必須要能保持資料的完整性,也就是說,每一次的交易均要能完美地執行該工作,否則就要回復到交易之前的狀態。

交易的四大特性
在高度大量資料交易的環境或者是 mission-critical 的系統,交易是不允許有絲毫的錯誤,因為這個理由,在交易服務領域的專家們鑑定了交易需要有四大特性的遵循才得以說這個系統是有安全的交易環境:

交易必須是 atomic, consistent, isolated, and durable (ACID)

Atomic
所謂的 Atomic,係指交易必須是完全地執行否則就根本不執行,這也就意味著在 “工作單元” 內的每一項工作在執行過程中皆不能有差錯,若任一工作發生錯誤時,則整個的 “工作單元” 或交易就中斷,所有已變更的資料必須回復為未修改前(undone or rollback)的狀態。若在 “工作單元” 內的所有工作皆執行成功,則該交易就被 “commit”,代表著所變更的資料需要永存到 Database。

Consistent
保證當交易完成後,必須讓系統的狀態保持一致性。何謂一致性的系統狀態?例如,在顧客完成提款的交易後,銀行系統的一致性狀態必須依循著 “客戶帳號的存款總額不能是負數的” 的規則。

Isolation
單一交易的執行不能受到其它程序或另一交易的干擾,也就是說,在該筆交易所存取的資料不能被系統的其它部分影響,直到交易或 “工作單元” 完成執行。

Durable
意味著在交易的過程當中所變更的資料必須在交易完全地執行成功前寫入到某些型態的實體儲存機制,例如 Database,而不會因為系統的當機(crash)而導致資料的遺失。

軟體設計與交易<1>

軟體設計階段是否需考量實體系統環境的配置?個人認為是 “Yes”。因為設計並非「昧於事實」。

舉個例來說,Architect 檢視 Designer 所繪的循序圖,他需要瞭解到交易的源頭(Transaction Root)是起始於那個物件?
若是 Transaction 是自 Server Page(如 ASP.NET or JSP/Servlet)啟始,那可能是 “Bad design”;
若是 Transaction 是自 Control Object 啟始,但與 Desinger 溝通,發現到 Control Object 是被設計為 “Stateful” 物件,哪麼,這也可能是不佳的設計。

為什麼?因為交易根物件(Transaction Root Object)在符合 “ACID” 的四項原則下,盡可能交易一完成就立即釋放資源(Resource),這是實體 3-Tier 典型的特性。所以,Architect 此時就必須與 Designer 溝通:交易根物件設計為 “Stateless” 物件較為適宜。

軟體設計者若依循古典物件導向,沒有考量到分散式系統的設計,因而,都假設所有的物件為 “Stateful”,且對交易等的問題,認為是至實作面才去解決。哪麼,很有可能變成是 “紙上談兵”,往往 Designer 與 PG 之間就會溝通上的衝突了。

什麼是軟體設計(Software Design)?

為了包容複雜,軟體設計會投入大量心思精力,追求一致、和諧、平衡、穩定、永恆之美,直到開發出偉大軟體之後,大量複製,就會發揮規模報酬遞增的鉅大經濟效益。所以,軟體業的特性就是:設計、研發的成本很高,而利潤遞增的經濟效益極大。這也是知識經濟的特色。

當我們瞭解把軟體與人腦視為同等級時,就會知道軟體需要精心設計,而不是只有寫程式而已。

設計者不是只追尋一條工程化的步驟,而忽略設計所需的藝術美感素養。軟體開發如果太過於工程化、數學化,會把軟體設計(Software Design)視為程式設計(Progarmming),貶低了軟體設計的無形、重複、利潤遞增的高度價值。

軟體設計就像莎士比亞寫劇本,程式設計就像照劇本演戲,所以軟體產業的高度價值在於軟體設計,而不是寫程式。軟體設計的藝術成分較高,程式設計的工程成分較高;這與建築業很類似。

軟體系統是收集使用者需求建構而成的嗎?

軟體公司的 PM(Project Manager)一向重視的是如何在不合理的開發時程下完成專案的開發。許多 PM 也認為他們認同物件導向及如 RUP/XP 的開發流程模式,認為如此他們可以縮短開發的時程。

個人最常與 PM 們討論的一個話題是:軟體應用系統是否係由使用者的需求收集而來所建構而成的?
絕大部分的 PM 的回答是:Yes!

為何問這個問題?個人發現到 PM 一定會先請 SA 訪談客戶的需求,並記錄在 Use Case 敘述內。再由 SD 針對 Use Case 敘述來找出領域物件(Domain Objects)。

在這樣的開發流程下,顯然使用者需求(Use Requirements)是重於軟體結構(Classes)的。所以,Use Case 是目的;Classes 是手段。

有沒有道理?在某種觀點及假設下,可能有道理!

只是,讓我們回想 RUP 所建議的最佳實務作法:”Use Case Driven;Architecture Centric”。

那麼,PM 既然認同 RUP 的開發模式,但是是否有仔細分辨倒底系統開發的方式是 “Use Case Driven” 或者是 “Use Case First” 呢?

有趣的問題,留待各位一起討論!

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal