上上星期，收到一封電子郵件，是位就讀「銘傳大學」資管系(在職班)的女孩子，詢問我是否可以以私人的身份指導她們在系統分析的專題研究與開發。 一般而言，我並不會接受私人的顧問輔導，我還是傾向與我們公司接洽聯絡，不過，由於她們也不是透過學校，而是以與我聯絡的那位專題研究的小組長、自己掏出腰包來擔負請我指導的學費。真的很有心，所以我不想計較學費；再則，一方面我還從沒有去過銘傳大學(以前北工的聯誼是經常有與當時的銘傳商專聯誼，不過我從沒參加過)，還蠻想瞧瞧銘傳內部的校區；另一方面，她們的專題研究也挺有趣，「運動彩券投注系統」。

前一天我聯絡了常來上我們單元課程的「生魚片」，他對軟體設計這個領域一直相當有興趣，所以利用這次的機會安排他見習參與該專題的討論研究。

忘了星期六是要補星期一端午節連假而需要上班的，所以她們小組來了兩位女孩子。一開始就是先讓我看一下她們目前的開發成果，有包括了使用案例、循序圖與類別圖。嗯，小組長(Amy, 也就是聯絡我的女孩子)她們的學分科目是屬於「物件導向系統分析與設計」，教授的內容也包含了 UML 設計圖及系統分析與設計。我個人是挺肯定的啦，雖然設計的產出看來都有問題，但是學生會有這麼認真實屬難得可貴！ 我授課與輔導都比較偏向引導的方式，而不會是一直講、一直講，那意義不太大。透過引導詢問的方式，比較容易知道她們的問題在哪裡，是否瞭解一些基礎觀念的知識等。

一開始我就說了，今天就要把其中一個使用案例給寫出程式碼來，嘿，她們愣住，光是對這個專題的系統分析上，她們已經花了起碼兩個月的時間，以及小組成員之間無數的爭論，一天給寫出來？ 嗯，這也不就是業界的常態嗎？ 怎麼會想要把系統分析給窮究分析徹底呢？ 怎麼有可能一開始就要收集完所有且明確的需求規格呢？ 怎麼有可能假設分析與設計是沒有問題的呢？ 這不就是典型 "瀑布式(waterfall)" 流程開發經常發生的詬病嗎？

找出對系統最有價值的案例，馬上快速跑過一個開發循環(Iteration)，最少包括了需求分析、簡單結構設計、程式碼實作，再回頭來增加細節等。一開始我就開始灌輸她們這樣的觀念，要能懂得如何在第一個循環過濾掉不必要的細節。當然是身體力行，直接就帶著她們快速導入實作。

這個系統我看來最有價值、可以先開發的功能案例有兩個：投注與派彩。 嗯，今天就先把投注這個案例先跑過一個循環吧。教她們如何建構使用案例模型，如何寫出正確格式的使用案例敘述。但在結構分析上，我並沒有提，因為結構分析對她們現在的程度，以及短短的兩天，是不可能作得好的。我只揭露出如何利用 "控制(Control)物件"、"邊界(Boundary)物件" 來實現實體系統的 MVC(Model-View-Control) 分層結構。

中午午餐休息時間，我們一起走到士林夜市那條馬路上，找個有冷氣的飲茶簡餐店用餐，在那邊聊得愉快，同時也瞭解她們這些小女生都是在業界(幾乎是在 MIS 部門)上班，晚上還要修習大學課程，還要提心吊膽考試被當(該系統分析課程還被當了 10 餘個)，真是辛苦！ 用完餐後，我要去付錢，但是 Amy 堅持她要請客，有些不好意思(我不太喜歡讓女孩子請客)。

下午繼續，我也指導她們利用 EA(Enterprise Architect) 工具來實現塑模，然後到最後呢，就是 "CodeGen"，把程式碼框架給加到 NetBean 的專案目錄內。一切蠻順暢，也挺輕鬆愉快的。 Amy 她們可真認真，說還要聯絡其她組員晚上過來，把我教導的內容轉述傳授給未能來的組員們；同時呢，我是留了兩個實作的課題，請她們要能連上資料庫與設計一個簡單的 WebForm。

今天生魚片比較沒有發揮的機會，但很健談，也發表了很多他的想法，相當不錯。他開車順帶送回我中和去。在開車的路途中，我請教他關於期指看盤的重點。生魚片是作比較偏波段的操作，據他的講法說他是死多頭(剛好與我相反，我比較喜歡放空)。嗯，光這幾天大盤瘋狂的漲勢，已讓他的期指多單，賺到比一年的薪水還要高呢。

隔天呢，另外兩位女孩子也過來了，都好乖。我安排生魚片先與 Amy 她們實作 UI 與資料庫連結，然後我先與今日來的那兩位女孩子以閒聊的方式，花了快兩個鐘頭吧，讓她們先建立一些對軟體設計的基礎知識觀；耶，她們資料庫好像還沒連上，不過也已過中午，要吃中餐了。

這次我們是到士林夜市旁邊一家新開的平價義大利麵，量好多，也不難吃，坐在我對面的 Wendy，竟然點了大辣，還吃得津津有味。我這陣子因為腸胃不適，只能吃淡的、不能加辣，冰的也不行，更甚者，連咖啡都不能喝。 唉，我要去付錢，Amy 又搶著去付錢請客了，實在真的很不好意思。 生魚片真的很健談，有他在真好，四位女孩子也是與他聊得很愉快。

下午呢，她們還是無法連上資料庫，對於 JSP 也不熟。由於生魚片只懂 .NET，對於 Java 的實作設定等，也是陌生。後來我要求改成 Java Swing，先讓 UI Form 可以連得上控制物件，並且可以取得 "下注" 的對話訊息(也就是控制物件的 method)。 NetBean 怪怪的，一時之間還真連不上資料庫，肯定是 JDBC 設定的問題。不過我不可能將時間耗在這些設定的 How-to 上，不過同時呢，也就 identify 一個潛伏的問題：小組成員的實作能力也需要加強！ 剩下最後的時間，我仍需要講解如何正確定捕捉 E-R(Entity-Relationship) Schema，以及將這兩天所有的設計產出做個總整理，同時呢，我利用 EA 的 "文件產生功能" 產出了這兩天所有設計的 Word 格式文件，她們好高興，沒想到可以產出看來起好有質感的文件。嗯，做文件這種東西，就是很自然在開發過程中產出，若是刻意要去寫，意義實在不大。

雖然最後無法連上資料庫，沒有完全打通，稍稍有些可惜。不過也指導了該從哪個物件連結資料庫，這一個技術環節，在爾後她們的實作上，其實是可以輕而易舉完成的；同時，我也感覺的出來，她們對這兩天的實戰輔導，感到很開心，當然，我自己也是很欣慰的，對她們多少有些實質上的協助。

結束了，Amy 拿了學費給我。我堅持一定要請她們晚上吃大餐，坐計程車到往陽明山那個麥當勞附近，沒想到所有的餐廳全都客滿，走了許久，到了士林捷運站底下一家日式燒肉店，問問她們的意見，也都可以接受，就進去來吃燒肉囉。不錯耶，這家店我還記得七、八年前我與老婆、蓁妮來吃過，當時感覺沒那麼好吃，沒想到現在作得如此好吃。生魚片不能吃牛肉，算命的說他吃牛肉會破財，為了他的期貨仍留倉多單，一旦破戒吃牛肉搞不好星期一開盤大跌，所以我們就幫他點了松阪豬肉，喔，還有海鮮火鍋，大家都吃得還挺愉快的。

這兩日與生魚片輔導這四位單純又認真的女孩子，覺得也真不錯，後來才又知道，她們是班上第一個已經在進行的專題小組研究，其他的小組，都還只在紙上規劃主題呢，實在是好有心、好認真！ 我想，三不五時，還是協助她們透過 Email，Review 其設計產出，多少指導她們一些比較顯著問題上的修正。還有，等到專題成果整個完成後，小女生們還說要再請我們去吃燒肉呢。

全文均刊登於北京「程序員(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 的設計圖。重點還是在於：你要知道該設計產出是在那一個觀點、表達的是那一個範圍與層次。筆者太常看到，團隊成員們之間，爭論的話題，根本就是不同觀點、不同層次，卻又不自知，難怪會經常導致溝通障礙的問題了。

需求功能觀點：

• 表達大範圍企業流程的Eriksson-Penker Business Extension Diagram
• 表達單一企業流程的活動圖(Activity Diagram)
• 表達系統範圍的使用案例圖(Use Case Diagram)

結構觀點：

• 表達軟體主結構的類別圖(Class Diagram)
• 表達元件、子系統之間介面(interface)溝通的複合結構圖(Composite Diagram)

實做觀點：

• 表達資訊系統與套件之間相依的部署圖(deploy diagram)
• 表達物件互動的循序圖(sequence diagram)

需求面的設計產出

需求面是從系統外部，一般也就是從使用者的角度來看待系統所提供的功能(function)，從系統的角度來看時，也就是系統應該提供什麼服務(service)給外部的使用者。筆者一直在強調，既然是站在系統外部，那就是以 用 的角度來看系統，千萬不要在此階段討論到系統的 How-to 面議題，否則可是會永遠都分析不完，陷入癱瘓。那會是留待在結構設計與實做的階段。

需求面主要有兩個焦點的設計議題： 企業流程(Business Process) 與 系統功能(System Functions)。

企業流程對軟體資訊系統而言，是一個大的框架。從流程當中，我們才可以得知，哪些流程的活動(activity)，需要資訊系統的協助與參與；活動與活動之間，是否也要透過資訊系統的傳遞轉移(transition)。UML 活動圖，是表達企業流程的最佳工具，不過它只能表達單一的流程(例如訂購流程)，有時我想看某一流程(內有多個活動與條件判斷)結束後，又會轉移到另一個流程，這些流程之間的資訊流是什麼樣的關係。就是想知道更大一點範圍的業務流程，例如，訂購(Order)循環→採購(PurchaseOrder)循環→出貨循環。那麼筆者還會使用非標準 UML 圖：Eriksson-Penker Business Extension，由於該圖形很像火箭，所以筆者常簡稱為火箭圖(Rocket Diagram)。簡單的說，小 BP 用活動圖即可；而大BP，則可以使用火箭圖。

圖 2、表達訂購流程的火箭圖

上圖是訂購業務流程的範例，它綜合了火箭圖與活動圖，也就是在火箭內部表達出收到訂單之後訂購活動的流程。一般筆者是會另行以一張活動圖來表達比較複雜一點的流程活動。火箭圖表達了事件(event)的觸發者(trigger)，圖中就是 收到訂單 後即觸發訂購的業務流程；它也呈現了在該流程的進行過程中，有哪些會支援或提供的資訊，如圖 出貨與財務部門 均會支援(或者參與)訂購業務流程，而 訂購資訊 則是在流程中會使用到的資訊；筆者最喜歡該火箭圖的一點就是它能呈現出該業務流程的目的(goal)為何。這重要，這可以讓利益關係人知道某業務流程所能呈現的價值與目的為何，而可以省略掉看諸多細節的活動。以圖中的例子而言，訂購業務流程的目的即是可以處理客戶訂單與出貨事宜。其實火箭圖說穿了，就是一種很典型的 I-P-O(Input-Process-Output) 表示法，但很有效，它可以封裝(encapsulate)流程內複雜的活動，而這些細部的活動，則由活動圖來表達比較理想。

（點擊圖片鏈接看原圖）圖 3、訂購流程的活動圖

上圖則是利用 UML 活動圖 表達了訂購的業務流程。在此筆者並不打算來說明活動圖的語法，這在一般 UML 入門書籍即可以看到。總之，活動圖很像傳統行之有年的流程圖(flow-chart)，但有經過一些語法上改良與修正，例如增加了並行流程的表示法。

有件事可要注意，筆者在表達業務流程，無論是使用活動圖或火箭圖時，都絕對不會加入資訊系統的表達，也就是完全是先以純人工作業的方式來看這些傳統業務流程活動之間的資訊傳遞，如此會單純化很多，也能夠比較能把焦點擺在一個個的活動。為什麼不要加入資訊系統呢？ 因為在此階段，你不容易瞭解所要開發的資訊系統會有幾個，是的，這可是一個最常見的問題，軟體開發人員經常會把開發的系統當成僅有一個，且都是自行開發，是這樣嗎？ 請看看上圖的訂購業務流程，假如需求有說到活動處理完畢需要電子簽核，那麼，會有哪幾個系統的參與呢？ 是否有 訂購系統、出貨系統、財會系統，還有工作流程系統(workflow)，或者根本就只是 ERP 系統與工作流程系統呢？

如何界定有哪些系統的參與，不會是在畫業務流程圖時來決定的，因為你不能：1.決定哪些活動是由哪一個資訊系統來支援；2.不是所有的活動都需要資訊系統的參與，有些活動可能仍是人工作業。表達資訊系統的範圍界定與外部系統的互動，以及參與的使用者，利用使用案例圖是最佳的呈現。筆者看過許多的軟體開發單位，會直接從業務流程圖轉至系統的開發，這絕對不是一個好方法，除了上述提及的問題外，也因為這樣，而忽略掉了系統內部的結構分析與設計，而這才真正是支撐系統的彈性應變與穩定性的根本所在！

火箭圖與活動圖都是與資訊系統無關，它就是單純表達原來在企業上就會有的流程。經由一些原則與步驟，其實可以很容易地從活動圖中的活動，找出局部功能觀點的資訊系統使用案例圖。因為使用案例可以明確地釐清系統範圍、系統操作的使用者、使用者操作系統的目的，所以，使用案例可以成為實現系統功能需求的最佳前導工具。

如何得知活動圖中的每一個活動是否需要資訊系統的參與？ 基本上，就是針對每一個活動詢問幾個問題：1. 誰是主要的參與者？ 2. 需要系統提供服務嗎？若是，是由哪一個系統負責？ 3. 系統提供什麼服務？ 4. 系統是否需要支援的參與者(Supporting Actor)？若需要，是哪一個外部系統？ 筆者曾在前幾期連載的內容中，有說明與範例，如何從企業流程(活動)圖找出資訊系統的使用案例，可以參考。

使用案例圖(Use Case Diagram)可以說是筆者擔任架構師的最愛，它最大的價值反而不是在釐清有多少功能需求，需求功能的釐清，是需求分析師會需要瞭解的，而架構師反而關注的是系統的範圍。
下圖係利用套件(Package)圖來界定網路訂購系統範圍(System Boundary)。
界定了系統範圍，即代表框框內橢圓形的使用案例是我們負責設計開發的系統，包括了軟體與硬體。而在框框之外的，則表示並非是由我們負責設計的，例如表達外部系統的參與者，它是在我們的系統設計範圍之外。

界定系統範圍最大的價值，乃在於，決定什麼是內？什麼是外？；什麼該作、什麼不需作。

下圖左邊棒形人偶圖示，包括客戶、財會人員、業務人員，他們是屬於主要的參與者(Primary Actor)，是站在從系統外面來看系統所提供的功能。他們關注的是自身的利益，是否系統能滿足他們的需求，這也就是為什麼筆者說使用案例是表達系統的局部功能的原因了。而外部功能的觀點是站在 用 的角度來看系統提供的服務，自然就不應該也不需要知道系統內部的實做面議題。使用案例圖易學難精，原因正是要讓 SA 不去考量到流程(那會是表達在活動圖)、不想到權限控管等實做面問題(那是系統內部的結構設計或實作的議題)，好像很困難。簡單的說，要能寫得好使用案例，就是要能表現出無知，只看系統怎麼用就好了。

右邊棒形人偶圖示，包括 庫存系統、Banking 系統、會計系統，它們是提供服務給網路訂購系統，是屬於支援性參與者(Supporting Actor)。被歸為外部系統，也就是並不屬於在系統的開發範圍內，系統的開發範圍是被界定在網路訂購系統內。對於 訂購商品 這個使用案例而言，它需要兩個外部系統的支援，一為 庫存系統，以取得庫存商品資訊；另一為 Banking 系統，以取得信用卡付款時的驗證扣款的服務。

只要是被界定為外部系統者，則不需要去探究外部系統的內部結構，只要知道如何透過 介面(interface) 的呼叫連結，來取得相關的服務即可(再一次強調，這就是一種用的角度)。例如庫存系統可能是提供 Web Service 介面供外界呼叫使用，那麼訂購系統就要知道如何呼叫該 Web Service 的連結方式；而若是 Banking 系統只提供 Main-Frame 大型系統的連結介面，那麼我們就要知道，在實做層次的階段時，是如何連接呼叫該系統所提供的 APIs 了。

（點擊圖片鏈接看原圖）圖 4、網路訂購系統的使用案例圖

再來思考一個問題，庫存系統為什麼會是外部系統呢？ 這就是界定系統範圍的重點了。有可能庫存系統已經存在，我們不需要再重新設計一個新的庫存系統；也有可能在系統架構設計時，就打算將訂購系統與庫存系統分成兩個獨立的模組(Module)，讓彼此之間的耦合度(coupling)不致太過緊密，而可以形成可抽換(PnP, Plug and Play) 的高度彈性。但只要切開後，就需要定義明確的介面規格，這是非常困難的事，同時也要耗費更多的開發成本。一般以專案導向(Project-based)的開發，會比較傾向是把兩者合成同一個系統(此時系統名稱就可能會改為進銷存系統較為適合)；而開發產品(product)者，因為會賣給不同的客戶有不同功能的模組，且需要順應客戶需求的客製化(customization)，是需要有較高度的彈性，如此把兩者分開會是比較理想的。

筆者已經是將使用案例圖當成在架構設計規劃時，用來表達多個資訊應用系統整合時的重要工具。但筆者在此階段從來不提資料庫系統，原因在於系統整合講究的是介面的整合，而不是資料的整合。資料庫是被封裝在每一個應用系統內部的私有倉儲(private storage)了，例如 訂購系統、庫存系統、會計系統 都各有自己所屬的資料庫，資料庫之間，絕對嚴禁直接連結，否則即會違背了整體架構的設計，那也不用再談所謂的彈性與延展性了！

※ 延伸參考：
o　{程序員邀稿} 從軟體架構師(Architect)的觀點來看軟體開發流程

比較一下 ADO.NET 與 J2EE 的永續機制

• ADO.NET 的設計理念是將資料庫“搬移”至應用伺服器的記憶體(DataSet)，然後就與資料來源離線，讓應用程式就近方便“撈”資料處理。這是屬於“寬鬆耦合 (loose coupling)”的設計方式。
• J2EE 眾多永續儲存機制，包括 EJB Entity Bean, Hibernate 等，都是“緊緊地”維繫資料庫與應用伺服器內的資料物件 (Data Object)的一致性，將 O-R mapping 的自動化做到“最善”。這是屬於“緊密耦合 (tight coupling)”的設計方式。
• 兩者的設計方案並不一樣，但也各有各的優缺點，並不容易評斷好壞。無論如何，企業層級的系統設計，不應受限與受制於現有的系統機制，而是應該活用、善用其優點。

DataSet 在中間層的設計策略

目的：設計 虛擬DB(Virtual DB)，位於中間層(middle-tier) ，讓 企業物件(business Object) 與 控制物件(control object) 得以方便撈資料處理。

實現方法：設計 ModelVDB 類別(Class)，內含兩個屬性(property)，一為 DataModel；另一為 DataUtility。兩者均為 DataSet 類別。

• DataModel 定義與關連資料庫一樣的 Table Schema(可依業務性質定義相關的 Table 即可)。
• DataUtility 定義關於 使用者資訊、查詢條件參數、資料庫連線資訊等 Table Schema。

設計約束：

• 把 ModelVDB 視為是 “Value Object”，所以不提供任何方法供物件存取，企業或控制物件是直接透過屬性的存取來取得 位於 VDB 內表格的資料。
• VDB 要讀取或寫入資料庫系統，是透過控制物件呼叫 “小弟物件(PO, Persistent Object)” 負責與資料庫的溝通。
• Form 物件不得直接存取 ModelVDB ，必須透過控制物件，以維護資訊的完整性與封裝(encapsulation)。

（點擊圖片鏈接看原圖）圖1、ModelVDB 與其它物件的相依性關係

（點擊圖片鏈接看原圖）圖2、範例–查詢訂購資訊 by ModelVDB

DataSet 在 UI 層的設計策略

目的：設計 表單專用的虛擬DB(Virtual DB)，讓 表單物件直接存取其內表格的資料，再透過 控制物件 轉換格式至 ModelVDB，然後寫回至實體資料庫，反之亦然。

優點：表單擁有專屬的虛擬資料庫，設計的表格可以以表單為單位，來儲存表單內的欄位資訊，而不用與實體資料庫的結構相符。UI 與 結構設計團隊可以個別開發，彼此不用互相遷就，未來只要在控制物件執行格式轉換即可。

實現方法：設計 ViewVDB 類別(Class)，內含兩個屬性(property)，一為 ViewModel；另一為 ViewUtility。兩者均為 DataSet 類別。

• ViewModel 定義以表單為單位的表格，行(column)與資料型態以表單欄位為主。
• ViewUtility 定義關於 使用者資訊、查詢條件參數等 Table Schema。

設計約束：表單要寫入實體資料庫時，將 ViewVDB 當參數傳遞給 控制物件，再由其轉換格式為 ModelVDB，再透過 PO 物件寫入實體資料庫。

（點擊圖片鏈接看原圖）圖3、ViewVDB 與其它物件的相依性關係

（點擊圖片鏈接看原圖）圖4、ViewVDB 與 ModelVDB 的 Transform 循序圖表達

什麼是 .NET DataSet？

• ADO.NET(.NET Framework 所提供的資料存取技術解決方案) 中最為主要的元件。
• 它是一種資料容器(container)物件，是屬於記憶體的快取資料(in-memory cache of data)。
• 它完全獨立於資料來源(如 資料庫系統)，是離線的(disconnected)。
• 它所讀取的資料來源可以是：
  • Database (SQL Server, Oracle ...)
  • Object (如 MQ 物件)
  • Web Service
• 它內部可以包含多個表格(Table)的關連，並且可以同時從多個資料來源讀取資料至所定義的表格，儲存成為一列列(row)的資料。
• 它內部的格式是以 XML 所定義的，所以可以序列化(serialized)為 XML 字串，以方便當成參數來傳遞。(例如，透過 Web Service 傳至 EJB Session Bean)。

DataSet 與 RDB 的連結關係

（點擊圖片鏈接看原圖）圖1、DataSet 與 RDB 的連結關係

DataSet 內的 Table Schema

（點擊圖片鏈接看原圖）圖2、利用 Visual Studio .NET 2005 Solution Explorer 瀏覽 DataSet

DataSet 的優勢

• 中間層(middleware)的物件可以將 DataSet 視為是位於記憶體的資料庫(虛擬 DB)，方便就近 “撈” 資料來處理。
• 可攜性極高，隨時可以序列化為 XML，當成參數傳遞至其它如表單或物件來處理。
• 當 DataSet 內的資料經過處理而變動後，由於需要與資料庫內的資料保持同步、維護一致性，所以需要再透過 Data Adapter 建立連線，寫回資料庫內。同步的過程，交由 ADO.NET 的交易機制來處理，這是屬於永續性(persistent) O-R (Object-Relation) mapping 的系統設計議題。