This page looks plain and unstyled because you're using a non-standard compliant browser. To see it in its best form, please visit upgrade to a browser that supports web standards. It's free and painless.

掇拾 會員登入 會員註冊
一致化物件與資料的存取

何謂 LINQ

程式語言隨著時間演進,一再沉澱經驗與抽象後,以簡練直觀的語法解決具有共通特徵的各式問題。Visual Studio 2008(程式碼名稱為 Orcas)C# 3.0 VB.NET 9.0 後將支援新的語法 Language Integrated Query(LINQ),想一體解決多樣的資料存取。它是由 Anders Hejlsberg 所主導。Anders 曾打造了 Turbo PascalDelphiVisual J++C# 等叫好叫座的產品,單憑這位殺手應用創造者的眼光,LINQ 就不可小覷。

LINQ 是一系列語言延伸模組,以型別安全的方式支援資料查詢。期待隔絕各種資料的特性,不管是各廠家資料庫的 SQL 方言,或是 XML DOMXQuery XPath,抑或是物件集合的屬性存取。以共通的方式完成資料操作,如:挑選、比對、排序、彙總等等。期待減輕程式開發人員學習操作各種資料的負荷。

在即將來臨的 C# 3.0 / VB.NET 9.0 / Orcas 將支援之 LINQ 架構如下圖:

1C# 3.0 / VB.NET 9.0 / Orcas 將支援的 LINQ 架構

LINQ 藉由各語言編譯器將內嵌的 LINQ 語法轉譯成原本的 C# VB.NET 程式碼,並呼叫相關的底層模組以實體維護資料。最後編譯成與 .NET Framework 2.0 CLR 相容的 IL,所以 CLR 本身並未增加與 LINQ 相關的模組,但 .NET FrameworkVisual Studio 整合開發環境和程式語言需要增加相關功能和語法。

就筆者自己的感覺,LINQ 有以下的好處:

l 簡化大量的細節運作,將如何(how)取得資料換成要操作什麼(what)資料:這隱含存取最佳化交由專家來做,如 DB 引擎最佳化存取資料。

l 透過IEnumerable 一致性地存取各種資料,並在查詢語法中互相整合:如 File System、作業系統的 processRegistry、物件集合、XMLDB...,所用的皆是物件,大家的屬性都是資料。換句話說,資料物件化,物件資料化,存取二者的語法與語意相同。

l 平行運算:若要處理大量資料,程式設計師不容易撰寫 for 迴圈還包含平行運算。但 LINQ 轉譯成 C# VB.NET 的程式碼時,可以平行運算的方式處理大量資料。

l 撰寫資料物件存取的過程中,可以 IntelliSense 和強型別檢查:相較於以往 ADO.NET 加上 SQL 語法,LINQ typed dataset 直觀易懂,且應用更為廣泛。

就筆者與許多朋友聊到 LINQ 時,最多的詢問便是「未來是否不需要學 SQL 了?」個人認為,短時間不可能,LINQ 或許會減輕程式設計師對 SQL 的倚賴,但 LINQ 不會取代 SQL。它們各有一片天,LINQ 是程式設計師講的資料物件語言,SQL 是資料庫管理師對資料庫引擎講的語言,LINQ 是從應用程式處理資料的角度出發,但 SQL 關乎著整體資料庫伺服器有效且安全地活著的每一個細節。

而緊接的問題通常是:「將資料以物件來包裝,透過 entity 類別間接存取資料,那是否會有效率問題?」這筆者無法回答,尚待真實世界來證明。

@小標:LINQ 範例

你可以在 C# 中直接內嵌如下的語法:取得在 Customer 物件集合中,每個 Customer 的屬性 Country 值為 USA,按照 City 屬性由大到小排序,傳回以 CompanyName City 兩個屬性的字串值所建立的新物件之集合:

var matchCustomers = from c in db.Customers

where c.Country == "USA"

orderby c.City descending

select new { c.CompanyName, c.City };

這句 LINQ 語法經由 C# 編譯器解析,傳回實做 IEnumerable 介面的物件給 matchCustomers 變數。而在查詢語法中,呼叫了 whereorderbyselect 延伸方法(Extension Methods)。並定義匿名方法(Anonymous Methods)委派(delegate);要求 where 方法比較 Customers 集合中 Customer 物件的 Country 屬性值為 USA。換句話說,自動將 c.Country == "USA" 轉成 bool Pred(T item) 形式的委派。最後透過 select 延伸方法搭配物件初始設定式,回傳匿名型別(Anonymous Type)物件的集合。

若不採用 LINQ 寫法,上述語法也可以寫成如下的方式:

var matchCustomers = db.Customers.Where(c => c.Country == "USA").OrderByDescending(c => c.City).Select(c => new { c.CompanyName, c.City });

哇,想我修習 .NET 數年,竟不知所云!?在此介紹一本入門書:「Introducing Microsoft LINQ」,Microsoft Press 出版。它讓你了解以往的 C# VB.NET 各版本如何漸進地增加功能,最後演變出 LINQ 語法。

@小標:書籍內容

本書結構短小,僅六章加上一個附錄,各章的基本架構就是對應圖 1 的各個區塊。

第一章針對 LINQ 做總體概觀介紹,初讀此章時,覺得過於唐突,比照下載的完整範例程式碼還是不知所云,滿頭問號。待看完本書其他章節後,再回過頭看第一章,這回看懂了J

沒有任何進步是獨立完成的,因此本書第二、三章介紹為了支援 LINQ,或應該說若你要了解 LINQ 的運作原理,必須先熟悉 C# VB.NET 的相關功能,約略表列如下:

l C# 2.0 提供的泛型(Generic)、匿名方法,與改良的委派 Enumerators Yield

l C# 3.0 提供的 Local Type InferenceLambda 運算式(Lambda Expressions)、延伸方法、隱含型別化區域變數(var)、匿名型別,和改良的物件初始設定式(Object Initialization Expressions)

VB.NET 9.0 LINQ 語法相關的項目和前述 C# 相似,但少了 yield 關鍵字和匿名方法[1],多了對 XML 語法的支援和 Relaxed Keyword

本書第四章介紹 LINQ 的語法結構,以及各種資料集合的運算,如連結、排序、過濾、群組、彙總.. .NET Framework 預設為 LINQ 所提供的多種延伸方法。

第五章介紹 LINQ to ADO.NET 的特徵,這又分為 LINQ to SQLLINQ to DataSetLINQ to Entities ,本章簡述這三部分的建置與對應的 LINQ 語法:

l LINQ to SQL 透過 Orcas 的「LINQ to SQL File」範本產生出類別實體,以對應 SQL Server 資料庫內的某些資料表及其關聯,或是呼叫預存程序、函數等資料庫物件的方法後,撰寫資料處理的語法變得直觀易懂。搭配交易,以屬性和方法來新增、修改、刪除、查詢資料物件。

l LINQ to DataSet:由於 DataSet 可以視作記憶體中的小型資料庫,而賦予 DataSet 資料的方式也很多樣化,因此當 DataSet 有資料後,仍透過 LINQ 如同對一般資料庫的存取。

l Orcas 內建了產生 Entity Data Model(EDM) 的精靈,將資料存取物件的操作與資料實體儲存機制隔絕開來。LINQ 仍以相似的方式存取物件化的資料實體。此部分的相關資訊可參考本書的附錄。

第六章解釋何謂 LINQ to XML。由於 LINQ to XML API 嘗試簡化 XML 的相關技術,所以建置了一整組 X 開頭的類別,讓你以直觀的物件架構存取 XML 的各種節點,而不需要透過 W3C XML DOM 的繁複方式。本章除了說明這些 X 開頭的類別與以往 DOM 各物件方法之對應外,也闡述了如何透過 LINQ 維護 XML 資料。

在附錄中解釋了 ADO.NET Entity Framework 的架構,以及 Orcas 如何產生該架構下的三種檔案:

l Conceptual Schema Definition Language(CSDL):用來描述程式碼所依據的資料定義。

l Storage Schema Definition Language(SSDL):用來描述實體資料儲存區,如 SQL Server 對資料庫內各物件的定義。

l Mapping Schema Language(MSL):用來聯繫對應 CSDL SSDL,因此 CSDL SSDL 可以多對多對應,也就是資料操作與資料儲存能夠分開。

Orcas 參照 CSDL 會產生出代表資料的實體(entity)物件之 C# 程式碼,再經由 SSDL MSL 結合到資料儲存的實體,如 SQL Server。當透過 LINQ 操作 ADO.NET Entity 時,可輕易完成資料維護與交易管理。

@小標:閱讀建議

本書是為熟悉 C# 的程式設計師介紹 LINQ 語法,因此全書的文字內容並沒有完整的可執行範例[2],且未與 ASP.NET Windows Form 等使用者介面技術整合。但對於 LINQ 的基本技術介紹得還算完整。由於只有 217 頁,逐頁讀完,也就對 LINQ 了然於胸J。若僅想熟悉 C# VB.NET 二者之一,還可以在第二、三兩章中擇一,需要閱讀的分量就更少了。

但若不熟悉 C#,則你需要很大的耐心,先了解本文上述所表列 C# 的各項功能,並反覆閱讀本書,才能漸漸融會貫通。

最後,若你要購買本書,先有兩點考量:

l LINQ 還處於 Beta,明年推出的正式版可能仍有變化。

l 相對於內容分量,本書的價格偏於昂貴。

也因如此,它在 Amazon 的評價只有兩顆星。或許,它僅適合買書不考慮成本,以及對於新知充滿好奇的人。

最後,本書僅是 LINQ 的入門介紹,對於實際使用 LINQ 到日用習慣的資料操作,如與控制項做雙向資料繫結(DataBinding)以維護資料庫內資料、彈性地動態組 SQL 語法等,並未明確地交代。期待這一部分隨著 Orcas 步入正式版會有簡單且完整的解法。

@小標:相關閱讀

最後,筆者列出些相關的資源以延伸閱讀:

Anders Hejlsberg (C# 首席設計師) LINQ 定位的說明與實際親手示範其用法:

l http://blogs.msdn.com/charlie/archive/2007/01/26/anders-hejlsberg-on-linq-and-functional-programming.aspx

l http://channel9.msdn.com/showpost.aspx?postid=114680

MSDN 上介紹 LINQ 的文件:該篇專欄可幾近取代本書的第二章。

l http://msdn.microsoft.com/msdnmag/issues/07/06/csharp30/default.aspx?loc=zx

作者為本書所建置的網站,上有當作試閱的第一章,以及可下載的範例程式碼:

l http://introducinglinq.com/



[1] VB.NET 9.0 雖未個別支援 Anonymous Method 的宣告與使用,但 lambda expression LINQ 實則需要 Anonymous Method 的運行架構。因此 VB.NET 9.0 編譯器在底層解釋與編譯前述二者的語法時,已經採用了 Anonymous Method

[2] 本書沒有隨附範例程式碼光碟,僅可從網站下載。但若你想要執行那些範例,最好先從 MSDN 下載並安裝 Orcas Beta 版。才能順利執行範例程式碼。

Windows Workflow Foundation 的入門書

以圖型呈現工作流程模型,並提供基礎環境給開發者

當我們在設計與撰寫應用程式時,多多少少會有條件、步驟、狀態、事件、時程、進度。若這些組合簡單易懂,則直接寫在程式內即可,開發與維護都不成問題。但若組合複雜,執行時程跨日甚至跨月,則可能需要簡單的工作流程引擎(Workflow Engine),透過明確與程式碼區塊對應的圖形來萃取工作流程模型(model),這將可簡化設計、開發與維護,但又不需要花大錢購買如微軟 BizTalk 等伺服器。

微軟在推出 Vista 作業系統後,同時推出了 .NET Framework 3.0,也就是在既有的 .NET Framework 2.0 之上,新增了四大塊功能:

l 定義使用者圖形介面的 WPF(Windows Presentation Foundation)

l 程式間標準溝通方式 WCF(Windows Communication Foundation)

l 設計與撰寫工作流程邏輯的 WF(Windows Workflow Foundation[1])

l 認證個人身分用的 WCS(Windows CardSpace)

換句話說,未來新的作業系統,都將內附 WF,而其他較早版本的作業系統,如 Windows XP Windows 2003 可以單獨下載安裝。也就是我們將有一個免費的工作流程執行環境(Workflow runtime)

WF 處在撰寫程式的階層,主要提供開發者將工作流程的功能內建到自己的應用程式中,是單一程式內的工作流程。其包含了工作流程架構(Framework).NET API、延伸的服務,以及 Visual Studio 2005 的視覺化設計開發介面,但並非獨立執行的服務或引擎。藉其 API 和工具,你我可以在 Windows 平臺上開發含有工作流程的系統,並延伸 WF 既有的架構,客製化所需的功能。期待透過統一的模型與程式介面,解決多種工作流程的問題,包括人與人、人與系統和系統與系統之間的工作流程。

使用 WF 開發工作流程的經驗與透過 .NET 程式碼開發其他元件近似,如同設計 Web/Windows表單或控制項,你可以圖形介面設計大體架構,繼而切換到程式碼頁撰寫觸發事件,最後編譯成 .NET 組件(Assembly)[2]。一般你還需要撰寫承載工作流程的可執行程式(host,通常是個 exe),參照 WF 架構提供的組件,藉以載入工作流程執行環境,而後交付工作流程定義令其執行。

結合 Visual Studio 開發工作流程

一般而言,工作流程大分兩類:

l 循序工作流程:工作流程的工作可以自動執行,不需要外界介入,例如不需與使用者互動,或等待事件觸發。

l 以狀態為基礎的工作流程(state-based workflow):也有人稱為有限狀態機(finite state machine),其工作流程特徵在與外界互動後改變狀態,轉換到下一個狀態以進入工作流程下一步。

WF 據此提供兩種主要的設計範本,搭配工作流程引擎提供了許多標準活動(Activity),如 IfElseWhileCodeDelaySequenceParallelTransactionScopeCompensatableTransactionScopeStateStateInitializationEventDrivenSetState…等。一般的作法是:它們以圖形呈現在 Visual Studio 的工具列上,讓你拖曳到設計區中,以規劃工作流程邏輯,再經由屬性視窗設定事件對應的函數,進一步到程式碼頁撰寫 .NET 程式語言。

換句話說,WF 的「工作流程」是以「活動」示意圖來定義的人或系統之行為模型。「活動」是「工作流程」中的各個步驟,並且是設定、執行和重用的單位,經由活動組合的設計圖表達了規則、操作、狀態以及彼此的關係。最後編譯為 .NET 程式組件,且在工作流程執行環境和共通語言執行環境(CLR)中執行。如此,藉由 WF 可以設計使用者或伺服器端的工作流程,在所有類型的 .NET 應用程式內執行。

這讓程式設計人員可將個別程式的工作流程行為,從巨量的程式碼中單獨萃取出來。在 Visual Studio 內,透過圖形化的模型,較容易開發與維護這些工作流程。藉由專業的工作流程執行環境與設計模式,可提升所撰寫程式的穩定性。但對於繁雜的工作流程,如公文簽核或製造業所用的 RosettaNet…等等,可能還是需要獨立的產品。

在大型應用系統上,我們需要彈性整合與控管,結合其它應用程式與多個平台,則仍需 A to A(Application to Application)B to B(Business to Business)EAI(Enterprise Application Integration)BPM(Business Process Management)等相關產品。畢竟,你可以徒手開發符合特殊目的之系統,但要整合多個系統、交換各種資料,融貫不同技術的存取介面等,本身就是件麻煩事。此時,建立商業工作流程的標準與彈性是重要的目的,耗時費工用低階的 WF[3] 自己建車輪,反而會見樹不見林。

總而言之,我們可以 WCF 建立程式間溝通的標準與易整合的服務,藉由 WF 建置服務內與服務間的工作流程,以 BizTalk 建立程式間有效快速的整合,以 BPM 產品彈性地串起企業內與企業間各個商務流程。

在此介紹一本不錯的 WF 入門書:「Microsoft Windows Workflow Foundation Step by Step,作者是 Kenn Scribner,擁有多年的程式開發與顧問經驗。他詳細解釋了工作流程引擎需要注意的問題,透過 WF 撰寫自己的工作流程邏輯並不容易,因為可能要考慮多個相同工作流程定義但不同的執行個體一起執行,這時資料交換將需透過特定的界面與服務架構。此外,多執行緒的協同、時程控管、工作流程執行個體的追蹤監控、將執行一半的工作流程存放到資料庫內、交易管理、與外部應用程式溝通等等,都是需要關心的課題。

書籍內容

本書共分十九章,充滿了 WF 的技術與流程設計的觀念,作者同時說明 What How,相當不錯。書籍規畫上分為四個主要部分。簡單介紹如下:

l 第一部分一至六章為 WF 的基礎知識。第一章一開始便以逐步導引的方式,簡單完成一個工作流程,並撰寫 Host 程式,以乘載工作流程引擎與工作流程執行個體。第二章闡述了流程執行環境的設計架構,如何透過 .NET 程式語言參照與呼叫該環境所提供的物件、屬性、方法與事件等。作者撰寫了一個 WorkflowFactory 類別,據以整合工作流程執行環境,建立流程執行個體。並透過程式解說,列舉執行流程應注意的事項,之後的章節將重複使用這個類別。第三章介紹工作流程執行個體的生與死,透過 WorkflowInstance 物件的屬性和方法,以啟動、查詢與終止流程。在第四章中,大致區分流程的特徵,描述循序流程和狀態機流程的差異。第五章介紹如何追蹤流程的執行,WF 預設提供將流程執行個體的執行紀錄存放至 SQL Server,本章示範從 SQL Server 擷取這些資料並加以呈現,以及如何執行 Windows SDK 所附的小工具程式 WorkflowMonitor,簡單呈現某個流程的執行狀態。本章尚有另外一個重點,就是介紹 WF 架構預設提供的外加服務(pluggable service),在其後的多個章節中,多有用到此功能。第六章說明如何將長時間執行的流程執行個體;在其不活動(idle)的期間存放(Persist) SQL Server,以節省伺服器的資源,以及如何再取出重新執行。

l 第二部分七至十三章逐章介紹各種活動,讓你了解這些流程積木的特徵,在堆砌時,才不致誤用。第七章介紹了開發工作流程中基本的活動,如 SequenceCode…等,以及很重要的一些議題,如錯誤處理、除錯、暫停與停止工作流程等。第八章解釋如何在流程內將資料傳給外部的 Host,這命題看似簡單,實則相當麻煩。本章尚有另一個重點,如何在流程執行個體內執行另外一個子流程。第九章條列 WF 提供的邏輯控管活動,如 IfElseWhileReplicator 等活動,它們代表了撰寫程式時的 if 判斷式、whilefor 迴圈等。第十章介紹事件處理,本章提供之模擬買賣股票的範例蠻複雜的,統合了前面章節的各種技術,透過 Windows Form 型態撰寫的 Host 程式買賣股票,Host 程式負責與使用者互動,但買賣股票的商業邏輯寫在工作流程。Host 須將買賣動作以事件的方式去觸發已執行之流程。同時,流程也取得股票更新的資料,傳給外部 Host 程式,以呈現股價的變化。第十一章介紹不同的活動平行執行,透過 Parallel 活動,可以在其內放置多個 Sequence 活動,而後再在 Sequence 內放置所需執行的其他活動。但由於 WS Parallel 活動內並非真的採用多執行緒並行執行,而是交錯輪流執行,造成在第一個循序流程中執行了某個活動,接著就跳到第二個循序流程執行另一個活動。作者在此引進 SynchronizationScope 活動,以強制需要一起執行完畢的活動執行完後,才可以跳至另一個循序流程。第十二章解釋如何透過設定規則(rule)與政策(policy),就可以改變流程的執行方式,而不需要以程式碼的 ifswitch 等語法寫死在程式中,條件的邏輯改變還需要重新改寫,這將提供更多的彈性。第十三章則是說明如何自行開發活動,作者從開啟一個空的類別庫(Class Library)開始,撰寫繼承 System.Workflow.ComponentModel.Activity 類別的子類別,用以完成自製的 FTP 活動。

l 第三部分十四至十六章介紹較為複雜的工作流程,第十四章以自動販賣機為例子,解釋以「狀態」為基礎的工作流程。販賣機從等待到使用者投幣、接著進入到錢數足夠等待選擇產品,以及完成等四個狀態。作者示範如何透過事件轉化狀態,以完成有限狀態的自動機器。第十五章說明如何在工作流程設計交易管理,本章續以狀態為基礎的工作流程模擬提款機,解釋 TransactionScope CompensatableTransactionScope 活動的用途。第十六章解釋如何用 XAML(XML Application Markup Language)描述流程主要架構,這個概念與 WPF 近似。本書的前十五個章節都是用 Visual Studio 的圖形介面拖曳流程的活動,完成工作流程的主體架構。而這些活動其實都可以 XML 描述,你可以用任何文書編輯器編輯,再將其文字檔的副檔名定為 xoml,而細節的商業邏輯可以透過 .NET 程式語言撰寫在 code-beside 檔案中。

l 第四部分十七至十九章說明工作流程如何存取外部資源。第十七章介紹當一個 Host 程式要產生相同工作流程的多個執行個體,且需要交換資料時,需要注意的事項。最後兩章分別是從工作流程呼叫 Web Service,以及讓設計好的工作流程可以當作 Web Service 來使用。由於 WF 的流程預設是以非同步執行,對長時間執行的流程來說,這是必要的。但 Web 網頁呼叫的模式,是立刻返回並結束,這將無法處理在網頁中被叫起的流程執行個體。由於在 IIS/ASP.NET 環境執行 WF 與之前章節的作法大不相同,因此若要將流程當作 Web Service,必須仔細研讀第十九章。

最後,作者提供相當多有趣的範例散布在各章節中,與現實生活經驗貼近,例如水箱、自動販賣機、提款機、問卷、買賣股票等,讓你容易領悟工作流程的特徵,而實作練習也有相當的樂趣。

閱讀建議

微軟圖書的 Step by Step 系列比較強調簡單易懂,英文語法平鋪直敘,各操作步驟儘量解釋清楚。本書對WF 來說,是由淺而深的入門書,但不適合程式設計新手,你需要熟悉 C#,知道多執行緒、平行運算、交易管理、狀態機(State machine)FtpWebRequest 類別、MS SQL Server 資料庫、ASP.NETWeb Service…等概念,換言之,你是個程式老手,而 WF 將是另一個工作利器。

作者在整本書各章節中,都提供了範例。每個範例大都有基本的初始環境,以及完成後的結果兩種目錄。讓你練習時免於設定初始狀態,照著書中所言,完成各個練習的步驟,且各步驟的說明多有圖示,讓你一目了然。當設計與撰寫程式碼有疑義時,比照另一個已完成的專案,你可以參考正確設計來修改。

若沒時間或耐心照著走,最起碼開啟與執行完整的範例專案一遍,關於 WF 的綱要也就了然於胸了J。而書中有些工作流程範例在直接開啟時,因為需要參照的自訂活動尚未編譯,其設計界面會呈現錯誤畫面,你可以直接建置專案,而後設計畫面就可以恢復正常。

本書的章節內容有相關性,尤其前幾章的安排為循序漸進,最好先按部就班地讀完第一和第二部分,而後瀏覽全書,再選擇需要或有興趣的部分精讀。WF 是給系統開發人員的工具,本書的讀者當然也屬這個族群。若你不是系統開發人員,但要評估與工作流程或 BPM 相關的產品,或許略翻一下本書,將會對工作流程引擎有更深一層的認識。

相關閱讀

書中提供許多關聯到某項技術的網頁,你可以延伸閱讀。除此之外,筆者列出些相關的資源:

l MSDN 自家對 WF 的主網頁:http://msdn2.microsoft.com/en-us/netframework/aa663328.aspx。以及本書的勘誤表:http://support.microsoft.com/kb/935354/en

l Essential Windows Workflow Foundation:出版社 Addison-Wesley,作者 Dharma Shukla Bob SchmidtWF 的架構師和程式設計師合著的書,介紹 WF 底層的設計與運作原理。

工作流程設計模式(Pattern)的定義:在 http://www.workflowpatterns.com/ 這個網站裡有用 Flash 繪製的各種工作流程設計模式動畫,它與產品無關,但你可以據此了解何謂工作流程,以及應用上的變化。


[1] 曾經一開始 Windows Workflow Foundation 縮寫為 WWF,因此你在微軟相關技術文件內,還可以看到這樣的縮寫。謠傳因為跟其他的註冊商標衝到,而改稱為 WF

[2] 組件形式通常設計成 DLL,一個 DLL內可以內含多個工作流程定義。但在筆者此次介紹的書中,強調當下的 WF 若將多個工作流程放在同一個組件中,當要一起執行時,會有 bug L。因此建議分開放置各個工作流程到不同的組件。

[3] 就這一版的 WF,筆者在練習建流程時,其工作流程與活動(Activity)的設計方式、物件命名等,與坊間其他的產品大異其趣。例如,想要做流程活動間的 ANDORNOT,或是與外界交換資料就很不直觀。或許是鎖定的族群不同,WF 的目標是程式開發人員,而坊間大部分的產品還期待系統分析師,乃至於使用者自行參與流程設計。

以商業流程的彈性與效率強化企業的競爭力

定位模糊標準繁多的 BPM

BPM(Business Process Modeling 另作 Business Process Management)讓系統整合的層次提升到商業使用者,而非僅是 IT 人員,透過流程最佳化提升企業競爭力是所有人的夢想與職責。但由於整個企業的商業流程浩繁,IT 技術與產品多樣,整體架構要兼具彈性、效率、穩定等互斥的面向。這讓架構工程師(Architect)很難規畫可大可久的 BPM 架構。因為它不僅僅是買個 BPM 流程引擎或設計介面,還牽涉到商業流程的規劃,應用系統的開發與整合。長期以往尚需延伸系統的功能、版本升級、安全架構、分析與監控流程的執行等。

BPM 的想法與產品由來已久,但在國內 IT 人心中的定位大都混沌不明。在國外雖行之有年,但競逐的標準繁多。例如 IBM 和微軟、BEA 等首倡;並由 OASIS 審核的 WS-BPEL(Business Process Execution Language for Web Services)BPMI 協會的 BPML(Business Process Modeling Language) BPMN(Business Process Modeling Notation)W3C WS-CDL(Web Services Choreography Description Language)WfMC 協會的 XPDL(XML Process Definition Language)OMG MDA(Model-Driven Architecture)…等等。有這麼多的相關標準,但沒有獨大的廠商,怪不得關於 BPM 產品的架構優劣,如何滿足企業 BPM 的需求等議題,至今眾說紛紜。

內容介紹

或許 BPM 正在醞釀起飛中,而國內的著述或引進的原文書不多。且因為市面上的多項產品實做方式差異頗大,而各家企業的商業流程更是不同,因此難有逐步引導的書籍。

在此介紹一本關於 BPM 理論不錯的書:Essential Business Process Modeling,出版商 O’Reilly。作者是任職於 IBM 的架構師 Michael Havey。本書的內容偏向 BPM 標準的來龍去脈,而非圖解式地介紹以某項產品完成幾個企業基礎的流程。本書的讀者應該是企業內的架構工程師,在規畫系統,選擇產品前可參考本書。而非學習如何寫程式碼,定義資料庫架構的開發人員。

本書的內容呼應了書名,討論的是 BPM 本質(essential)。看完後,你可以了解什麼是BPM、建製該系統時需要的背景知識,但做不出一條自動化商業流程。因為它沒有以單一產品為背景,從頭到尾詳細解釋產品功能,逐步做出一個 BPM 系統。因此,這是你築底的背景,並非應用的招式。可培養看問題的深度,但恐怕無助於當下問題的解決。

本書大分三個部分,前四章是本書第一部分,介紹 BPM 的概念。第二部分從第五章到第九章,分別介紹 BPM 各個面向的標準。第三部分為本書的最後兩章,以兩個例子來介紹 BPM 的實作。

在第一章中,作者介紹了何謂流程,又何謂 BPM,以及導入 BPM 的好處。不過筆者覺得有趣的是他歸納流程導向(process-oriented)的程式特徵如下:

l 執行時間長(long-running):某個流程的執行個體從開始到結束,可能經年累月。

l 要保存狀態(persisted state):流程過程中的資料需要長時間保存管理,並提供查詢與更新。

l 個別動作變化迅速,但整體流程大部分時間都處於停滯(Bursty, sleeps most of the time):流程的執行個體大多數時間都是停滯的,等待下一個事件觸發後醒過來,趕忙執行相關的動作(Activity),並切換狀態。

l 協調系統以及人際之間的溝通整合(Orchestration of system or human communications):流程要能協調、管理並整合多個異質系統和人員。

除了基本特徵外,書中在第二章介紹 BPM 所面對的基本問題:

l 設計:BPM 需要提供可以直觀繪製商業流程的軟體介面,使用介面須讓商業分析師(business analyst)容易上手,而非僅是 IT 專業人員,讓這兩種人有共通的圖形語言,且該語言需要嚴謹而簡潔。

l 執行:需要能準確執行使用者所繪製的流程圖。但其間流程圖會先轉化為專門用來描述流程的專屬語言,如 BPEL,流程圖與流程語言可以輕易地互轉,期間不要參雜需編譯解析的程式語言。因為程式語言會降低商業流程開發的順暢性,讓設計與執行間夾雜了 IT 技術的鴻溝。

l 監控與管理:監控各流程的執行狀況,以處理個別流程例外狀況的發生,並統計各個流程的執行,ad-hoc 查詢各種資料。可以新增、檢視流程定義、啟動、暫停、回復、中斷、刪除各流程與其執行個體。而這些監控與管理的機制除了透過套裝工具提供外,最好還能整合進使用者自己的應用程式中。

l 與人的互動:一些流程中的步驟需與特定的人或角色互動,除了友善的介面、彈性的流程步驟、安全的角色控管外,並可以在人機介面與流程引擎間整合交換資料。

l 與系統的互動:步驟中可以呼叫外不程式,或是被程式呼叫。這些程式可能是企業內部的元件或系統,但也可能是企業外的協力系統。這部分最重要的是與各種 IT 技術整合的彈性,如 Web ServiceMQ/SeriesJDBCJ2EECOM.NETMCF…等等

而該章第 25 BPM 架構圖 2-2 是個不錯的概觀指引,勾勒出 BPM 系統的基本元素與互動關係。

第三章稍微解釋了 BPM 的數學理論基礎:Pi-Calculus Petri Nets,對筆者來說,這似乎遙遠了些(看懂數學表示法的意義後,只高興了幾秒鐘,因實在難與實務連結)。該章的後段稍以 UML Activity Diagram State Diagram 兩種圖形,輔之以保險理賠為背景故事,描述流程中的狀態變化,藉以解釋狀態機器(state machine)和商業流程的關係。

在第四章中,作者表列針對流程設計常用的 20 種流程設計模式(Process Design Pattern)[1],此為 van der Aalstter HofstedeKiepuszewski Barrios 等四位學者提出。而這 20 種模式將一般的流程變化分為六大類:

l 基本型(Basic):如循序、分岔後平行執行、擇一執行、合併等。

l 進階的分岔與合併(Advanced Branch and Join):如複選、同步合併、多重合併、M N 合併等。

l 結構化(Structural):如任意迴圈、隱含結束等。

l 多執行個體(Multiple Instance):如不同步、設計時期決定、執行時期決定、執行時期動態決定。

l 狀態(State-Based):延遲選擇、交錯平行繞行、里程碑等。

l 取消(Cancellation):停止活動、停止流程等。

但就本章其後的 Yet Another Workflow Language(YAWL) 一節,可以看到不只是前述流程定義的規格,而實做的產品也處在戰國時代。因為上述四位學者歸納出大部份的供應商都未完整支援這 20 種流程設計模式,且沒有標準的圖示和語法來描述這些設計模式,因此制定了 YAWL。而本書作者再引功能近似的 BPMNUML Activity Diagram BPEL,以及 Java

C++Smalltalk 等程式語言與 GoF 設計模式的關係,來強調 YAWL 不重要L

接下來五至九章都是介紹規格,就筆者個人覺得,第五章 Business Process Execution Language(BPEL)和第九章 Other BPM Models 可以花些時間去了解,因為 BPEL 的聲勢較大,且最後兩章的範例多以 BPEL 程式碼來表現。而第九章內容是綜合陳述,且較貼近產品面。其它章節所描述的規格可以稍微瀏覽,碰到相關問題時再回來精讀。

本書的最後兩章搭配 Oracle BPEL Process Manager 當作 BPEL 流程引擎,以非常簡單的流程提供實作範例,但太多地方僅表列 WSDL BPEL 程式碼,很容易讓人失去耐心L

其中,第十章透過 BPEL 設計簡易的壽險理賠流程,主要示範一般的人事流程,搭配 Eclipse開發環境和 Oracle BPEL Process Designer 0.9.10 for Eclipse 來繪製流程,並交由 BPEL 引擎執行。同時,作者指出該版本 BPEL 引擎的 BugL,並解釋他本人補救的方式。

最後一章討論 Message Broker 的概念。本章的 Message Broker 或可視為 Enterprise Service Bus(ESB)理念的基礎架構,ESB 希望提供企業間系統整合時,有效交換訊息的平台。也就是若企業有 N 個系統,若彼此之間要整合並交換訊息,則需要建立 N*(N-1)/2 個介面。但若有標準而集中的訊息整合平台,各系統都只連接到該平台,而這個訊息平台根據既定的規則交換資料,則 N 個系統只需要建立 N 個介面。而單就 ESB 這個主題在眾廠家極力鼓吹 SOA 概念的今天,由於服務導向隱含了訊息導向,因此 ESB 本身就是個值得探討的議題。本章中,作者以人事醫療流程來示範,討論同時多個流程執行時,定義標準 XML 訊息的重要。

閱讀建議

這是本稍嫌枯燥的書,很難讓人耐著性子一口氣看完。不知你是否喜歡讀法律條文,我是花了好多天翻來覆去地選讀,煩了就丟到一邊,別的事情做累了,再回來看看。外加很多的名詞需要從 BPM 的角度重新認知,這也是本文大量夾帶英文的原因。但讀完之後,覺得對 BPM 的定位與規格有更深一層的認識。另外,每章最後都有結論,讓你可以重點溫習該章節的內容。畢竟理論看久也昏了J,有個提綱挈領的概要,能收畫龍點睛之效。

相關閱讀

除了本書外,你也可到以下的網址稍微了解與 BPM 相關資訊:

l Google Wikipedia:本書有非常多的專有名詞,啃這本書讓筆者覺得好像回到研究生時代,隨便看篇論文,需要找的相關論文可能遠超過起始的預期。不過現在有 Google Wikipedia 真好J

l 本書的各章大多附有參考資料,可提供你延伸閱讀。

l 提供 BPM 相關標準的網站:www.bpmi.orgwww.wfmc.orgwww.omg.orgwww.oasis-open.org

l 一些提供 BPM 產品的供應商網站:

n http://www.ascentn.com/:以 .NET 為基礎的 BPM 產品。

n http://www.pegasystems.com/:以 Java 為基礎的 BPM 產品。

n http://www.microsoft.com/biztalk/default.mspx:微軟提供的流程引擎,在 EAI 享有盛名,但其核心語言目前仍是 XLANG,可對 BPEL 做匯入/匯出。

http://www.oracle.com/technology/products/ias/bpel/index.htmlOracle 提供相關 BPEL 的資源,主要是 BPEL 引擎。


[1] 作者稱這四人為 Process Four P4,剛好對應了一般程式分析設計時,常借鏡學習的 23 個設計模式,一般稱其作者 GammaHelmJohnson Vlissides 4 人為 Gang of Four(GoF) J

研讀、實做、測試與認證

微軟認證

微軟認證考試在 IT 界是相當流行的實力證明,而網路上多有認證與薪水的關連性分析,透過 Google 稍做搜尋即可得到上萬個中英文連結,似乎認證對於加薪是稍有助益。但筆者個人覺得它不太能驗證真正的工作經驗與解決問題的能力,因為 IT 的系統管理與研發含有藝術成分,且 EQ 的重要性高過 IQ,這無法藉由考試得知,但看臨場的做法才能真知道。

然而認證提供起碼的技術門檻供人參考。本書專注在科目 70-431,考過該科即取得「SQL Server 2005 微軟認證技術專家(Microsoft Certified Technical Specialist MCTS)」資格。而 70-431 同時為更高階認證「SQL Server 2005 微軟認證 IT 專家(Microsoft Certified IT Professional MCITP)」的必考科目。認證可以提供較明確的技能架構給相關人員參考,如微軟 SQL Server 2005 資料庫管理師、開發人員以及公司管理階層,可透過微軟對認證的規劃,了解從事 SQL Server 2005 相關工作的人該具備之本職學能。

本書譯自英文版的「MCTS Self-Paced Training Kit (Exam 70-431): Microsoft SQL Server(TM) 2005 Implementation and Maintenance」,由 Solid Quality Learning 的講師群撰寫(有趣的是這家公司的縮寫即為 SQL)。該公司的講師與相關著述都相當有名,如 Inside SQL 系列的 Kalen DelaneyItzik Ben-GanDejan Sarka。本書是由七位專家合作而成,也才能豐富而深入。而中文版是由資深的資訊技術譯者張世敏所譯,他所涉獵的領域廣泛,已有多本譯著面世,譯筆清晰流暢。

內容介紹

中譯本分做一、二兩集,是紮實的工具書。將建置 SQL Server 2005 的每個單項功能都解釋清楚。尤其難得的是一般中文書籍少有探討的功能,如 SQL Server 2005 新提供的動態管理檢視(Dynamic Management View)和函數(Dynamic Management Function)、資料庫快照集(Database Snapshot)、資料庫鏡像(Database Mirroring)、複寫(Replication)Service Broker、全文檢索(Full text search)…等等。但這也導致其內容深度超過考試的難度,但畢竟考試與認證是一時的,有實力解決日常工作上的問題才是最重要的,且單次單科 80 美金的考試費用所費不貲,多準備些才去考試總比準備不足好。

資料庫管理工作的複雜,由本書的章節選材可以略知一二。本書選擇的內容相當廣泛,共分 21 個章節,涵蓋大部分 SQL Server 2005 的功能,因此中文譯本將其分為上下兩冊,上冊除了第八章 XML (要看懂本章,你本身要對 XML 技術有一定的功力),其餘章節皆較為基礎。其內容包含伺服器安裝、資料庫和資料表的建置與定義,T-SQL、索引、檢視、預存程序、函數、觸發程序、備份/還原等,這些都是資料庫管理師的基本功。

下冊除第 14 章介紹 SQL Server Agent Services,第 15 章介紹效能監控與調校功能;這兩章應該熟悉外,對資料庫管理師的日常工作而言,其它章節大都是選擇性的。也就是要看你工作上的需求決定是否採用。換句話說,許多的內容可能在當下用不到(也就是前述筆者表列一般中文書少探討的部分),初次閱讀或許瀏覽即可,但不可忽視。心中對技術的定位與作法有印象,在遇到問題時,才能做正確的選擇,也才知道在本書哪些章節中可尋求解答。

閱讀建議

本書應不算是入門書,但仍有一步步導引你操作的部分,還不至於太難。這本書不好唸,除內容深度外,其內章節交錯著不同功能的區塊。它將一章分成多個課程,課程內有「實務應用」上的經驗、有提綱挈領的觀念與功能解釋、有注意事項、「Quick Check」的提問與解答、各課程結尾的「課程總結」與「課程回顧」,以及每章結束前的「重要詞彙」、「案例情境」、「實戰演練」等大大小小的結構。這麼多人合作,還要維持這麼複雜的結構,著實不易。但剛開始看時有點混亂,靜下心來,讀個幾章熟悉結構後就好了。

每章結束前的「案例情境」是個有趣的設計,以該章所解釋的技術模擬一個虛擬公司的現實問題J。而「Quick Check」、「課程回顧」都是測試習題,念過短短一段課程或是完整一章之後,感覺起來自己都懂了,但一做習題,才發現依然有所疏漏。

若仔細研讀,把習題做通,相關的 70-431 考試就剩英文能力了L,我相信對不熟悉英文的朋友來說,在心情緊張的情境下,看不清題意是很大的殺傷力。就個人覺得,本書所附的模擬試題設計得介面不錯。雖然試題內容與真正的考題有出入,但就模擬考試經驗,測試閱讀本書的成果應該足夠。

因為其內容的豐富性,就算你不打算考證照,或是已經取得認證,本書依然都值得當作案頭的工具書。

相關閱讀

除了這兩本書外,你也可到以下的網址稍微了解微軟認證與考試的相關資訊:

l http://www.microsoft.com/taiwan/learning/mcp/mcitp/:此為台灣微軟對 mcitp 認證的說明。

l http://www.microsoft.com/learning/exams/70-431.mspx:解釋 70-431 單科認證的定位與技術需求。

l http://assessment.learning.microsoft.com/test/home.asp:在此可以稍微體驗一下回答英文試題的經驗J

l http://www.solidqualitylearning.com:出版本書的顧問與教育訓練公司,他們講師群的 blog 不錯J

l http://edu.uuu.com.tw/intro_aboutUCOM/UCOM_intro04.asp:考試認證相關事宜的說明。

l http://www.testking.com/70-431.htmTestking 是專門賣認證考古題的公司,而這個網頁是在賣 70-431 該科考古題L

深究微軟 SQL Server Transact Structure Query Language

隨著 SQL Server 版本的演進,T-SQL(Transact Structure Query Language)變得獨立而功能強大,且擁有眾多使用者,是解決各種資料問題的主流語言。由於公司內各種資料日益龐大、MS SQL Server 的功能擴增、其產品廣泛進入企業各系統,讓專門處理資料的 T-SQL 語言變成顯學。

在關聯式資料庫中,以集合(set)的方式來處理大量紀錄才有效率,使得 SQL 語言無法被程序導向語言如 C#/Java/Visual Basic 等取代。而善用資料是資訊系統成功的關鍵因素之一,伴隨大量交易、資料整合、商業智慧的結構性需求大增,將令 SQL 更形重要。

雖然討論 T-SQL 的書很多,但因為 SQL Server 2005 巨幅擴增了功能,且標準化了許多語法,將原來需要透過系統預存程序、DBCC 才能建置、設定或維護的功能,都回歸到標準的 T-SQL 語法,並放放寬了語法的自由度,例如:建立系統登入與資料庫使用者、透過 T-SQL 維護索引、TOP 運算子可以搭配變數或子查詢,以及搭配 CTE 使用在 UPDATEDELETE 語法中、彙總運算搭配 OVER 運算子等,諸多功能在 SQL Server 2000 是無法以 T-SQL 辦到的。

我們需要全面性地重新認識 T-SQL,而在這個時間點,夠分量的 T-SQL 書籍大概非 Inside Microsoft SQL Server 2005 : T-SQL Programming Inside Microsoft SQL Server 2005 : T-SQL Querying 二書莫屬。書籍的作者群裡,以資深的講師與顧問 Itzik Ben-Gan 為首,包含SQL Server 2005 團隊的兩位產品經理,分別負責SQL Server 查詢引擎以及 Service Broker 的深入介紹,以及其他擁有多年經驗的顧問與教師們合作撰寫,因此,兩本書中有著技術底層的詳細解說,也有各項功能的最佳應用實作。

作者群們主要以集合資料處理(set-based query)和程序邏輯(procedural programming)兩個面向來區分這兩本書。前者重視 SQL DML 語法的邏輯和效率,後者則強化搭配程序控制( IFWHILE、游標等)所建構的伺服器端物件,如函數、預存程序、CLR 物件、Service Broker 等。

筆者一直認為技術書籍與線上說明不同的地方是提供應用場景與閱讀的趣味,將技術與實務串起來。因為線上說明寫得像字典,若將資訊語言的應用比喻為作文,則一般人很難光靠一本字典學會作文。我們需要看文章來模擬筆觸、技法與結構。在學習資訊技術時,自然需要實務場景和程式碼範例。而這兩本書所提供的 T-SQL 範例大都簡短有力,兩三行就切中要旨,由範例就可看出作者的功力J。對於 T-SQL 的各面向,作者們提綱挈領深入淺出,不管是凸顯語法結構、運算子、適用性、建立伺服器物件等,都讓有 T-SQL 底子的人能迅速抓住重點。

使用 T-SQL 有如激盪腦力的智力測驗,同一個問題讓人驚艷的解法層出不窮,需要經驗與知識的累積,是技術與藝術的展現。而這兩本書讀來讓人愉悅,有如在讀 T-SQL 的秘技,作者整合了不同的技術,混在一起使用。例如,以一般的 SELECT 語法查詢;要將多筆紀錄的欄位值組成符號分隔的單一字串時,會採用類似如下的做法:

DECLARE @c nvarchar(4000)

SET @c=''

SELECT @c=@c + CustomerID +',' FROM Customers

SELECT @c

在上述範例中,會傳回 Customers 資料表中,以逗號分隔所有客戶編號的單一字串。但作者在Inside Microsoft SQL Server 2005 : T-SQL Programming 一書中,強調此種作法的不確定性,因為微軟並沒有明文保證此種連接字串的方法一定可行。但由於 FOR XML 子句在 2005 版本時,多了 PATH 選項,因此組字串可以換成如下標準的查詢方式:

SELECT CustomerID + ',' AS [text()]

FROM Customers FOR XML PATH('')

書中充滿了此種結合不同技術的意想不到之解法,讓懂得關鍵之人妙趣橫生,不懂奧妙之人,仍可抄襲應用。

善用 T-SQL 查詢語法

是否能善用 SQL Server,指標之一是能否精通 SQL 語法。而熟悉 SQL Server 的關連引擎(Relational Engine)如何評估 SQL 語法,如何建立與最佳化執行計畫是一切的基礎。針對此,T-SQL Querying 一書的第一章解釋了 SELECT 語法的運作邏輯,二、三兩章則詳細解釋了執行計劃的產生、如何觀察、以及查詢語法的最佳化。

在隨後的第四到第八章中,介紹了子查詢、Ranking 函數、Join、彙總、TopApply、修改資料等項目,個別針對 SQL 語法中的特殊功能逐一介紹。作者在說明個別的功能時,並非單調地舉個簡單的例子,說明一下用途和語法就結束了。大多會延伸該功能的設計意涵,或以相同目的但不同解法做個比較,讓你明瞭該項功能的優點,例如在介紹 Ranking 系列函數 Row_Number 時,就比較了欲取回查詢結果每筆紀錄的循序編號,可用自動編號(Identity)、游標(cursor)、子查詢以及系統含數 Row_number 等,除了 Row_number 本身的功能外,其間的效率差異才是重點。

最後一章廣泛地介紹如何用 T-SQL 來處理資料結構,如 GraphTree、階層與遞迴等。這讓筆者想起在學校時,用 C 語言探討資料結構的上課情形,沒想到也可以用 SQL 語法來介紹J。書中所舉的資料結構是我們一般常遇到的,例如製造業的 BOM(Bill of Materials)表,公司的組織結構與運輸的道路配置等。當你大腦清醒且一杯咖啡在手時,可以玩玩該主題。

最後,主要作者 Itzik Ben-Gan 開宗明義便強調:撰寫 SQL 語法是邏輯推理的訓練,而 T-SQL Querying 一書更以 18 個益智題目作結尾,增加了閱讀的趣味。

T-SQL 完成商業邏輯

Inside Microsoft SQL Server 2005 : T-SQL Programming 一書在前幾章詳細解釋了一般 SQL 使用上,讓人困擾的用法,例如以文字型態描述日期時間時,最好採用 [yy]yymmdd[ hh:mm[:ss][.mmm]] 格式,也就是以 ‘20060110’ 來表示時間最佳。前四個章節探討了動態組織與執行 SQL 語法、暫存資料表和資料表變數、游標等,大家以 T-SQL 撰寫商業邏輯時,常用的技巧,作者詳加剖析了較佳的用法。

在其後的章節中,本書分別解釋了為何要在伺服器端建置檢視、函數、預存程序、觸發、端點、Service Broker 等物件,以及交易管理和錯誤處理。兩書中都解釋了許多關於效能的議題,本書第六章特別強調了使用者函數的正面價值在於:提供了安全、彈性以及程式的可維護性外,但它可能損傷效能。而第七章說明了預存程序雖然會因為快取執行計畫而提升效能,但若資料分布不平均,造成索引誤用,依然損傷效能。因此需要小心搭配整個預存程序的 WITH RECOMPILE 選項,或是 SQL Server 2005 新提供的:單句查詢語法搭配 OPTION(RECOMPILE) 選項。

讀到 Service Broker 的產品經理 Roger Wolter 所撰寫的第十一章時,才能理解由於時程壓力,為了趕上市而切割 SQL Server 2005 的部分功能。但因功能尚未完成,導致保留的 T-SQL 語法讓人莫測高深,這些情況在本章有了解釋。例如 Service Broker 在開啟對話時,總要以 BEGIN DIALOG CONVERSATION 語法開始,筆者就一直懷疑是否自己的英文能力太差,為何看不出Conversation Dialog 這個關鍵字的用途L?原來 Conversation 分為 Dialog Monolog 兩種,Dialog 是兩邊的服務可以互為溝通,Monolog 則是發起端單方面的宣告。但 Monolog 在這個版本還未做出來,而為了下一個版本的相容性,本版就需要保留使用 Dialog 關鍵字。

另外,在 Queue 的中繼資料結構中保留了 priority 欄位,但我卻找不到如何在發送訊息時,設定優先權,結果也是開發小組來不及做,僅留了中繼資料的欄位結構。現階段若要分辨訊息的優先順序,只能自行根據不同的優先權個別建立佇列,自己再將訊息派送到正確的佇列,並完成處理。我的另一個疑惑是在建立 Service Broker 的對話時,來源端的 Service 名稱可以直接指定 Service 物件名稱,但目的端卻需要用字串,讀了此書才知道因為未來目的端可能不侷限是 SQL Server 所提供的服務,因此以一般的文字串來描述。

閱讀建議

這兩本書的目的是為了幫助你熟悉 T-SQL 語言,並透過 T-SQL 撰寫 SQL Server 伺服器端的物件,例如檢視、使用者自訂函數、預存程序、觸發等等。因此,在順序上應先閱讀 Inside Microsoft SQL Server 2005 : T-SQL Querying,而後才是 T-SQL Programming。兩本書的各章節大都彼此獨立,且作者所擬的章節針對性很強,你可以博覽後,選擇主題切入[1]

筆者讀完二書後,個人的感覺是:若你是程式設計師,僅要寫好 T-SQL 語法,但無權到 SQL Server 建立物件,則 T-SQL Querying 是你應讀的,T-SQL Programming 也值得你參考。但若是資料庫管理師,則兩本書都應該精讀。雖然作者群儘量從基礎入門開始介紹,但針對的是 SQL Server 2005 新增的部分,或是與效能相關的深入課題,而未完整解釋基本的語法結構。因此,若未經常使用 T-SQL 語言,不習慣以 T-SQL 為主;來處理資料問題。此二書的內容仍然偏難。話雖如此,輔之以線上說明多讀兩遍後,相信可讓人功力大進。

相關閱讀

除了本書外,Inside Microsoft SQL Server 2005 系列叢書中,當下買得到的尚有Kalen Delaney 所著的 Inside Microsoft SQL Server 2005 : The Storage Engine。筆者在先前的專欄中,已經介紹過了該書,在此也就不多贅述。

另外,在這兩本書中,作者們處處標示著可延伸閱讀的網路連結,筆者稍舉覺得有趣的連結:

l 關於 SQL Server 2005 的批次編譯、重新編譯、計畫快取:http://www.microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx

l 透過 C# 寫成的 CLR 預存程序,評估 T-SQL 查詢語法所花的成本:

http://msdn2.microsoft.com/en-us/library/ms345130.aspx



[1] 本書的作者習慣在文中強調某個重點在叢書中的某章有描述,或是可以參照哪些技術文件。就筆者個人感覺,第一次概覽閱讀時,不需要跟著跳躍,否則會迷失原有章節的重點。待遇到相關問題,需要精讀該章的技術時,再去串連這些延伸閱讀。

深入頗析微軟 SQL Server 2005 資料庫服務的運作原理

SQL Server 最重要的著作

若論微軟 SQL Server 最重要著作,大概非 Inside SQL Server 系列叢書莫屬了,從 SQL Server 6.5 以來,一直常駐在專業 SQL Server DBA 案頭的,就是對應各版本的這本書。這不是筆者的妄加讚譽,而是素有資訊界諾貝爾獎稱呼的圖靈獎(Turing Award)得主 Jim Gray 在該書的序言所說的。

筆者本身也以讀過該書,代表進入了該版本的世界(例如要熟悉 SQL Server 2000,先讀 Inside SQL Server 2000),以此為深入了解 SQL Server 的指標。而值此年終之際,稍有空閒時日,能專心拜讀此書實是精通 SQL Server 的最佳方式J

由於 SQL Server 2005 大幅改版,大量地新增功能,讓以往出書速度還蠻快的 Inside SQL Server 系列;這次叫大家從 SQL Server 2005 上市後等了近兩年。也由於功能繁多,原本極為厚重的 Inside SQL Server 再也無法以單行本出書,而改為四本合集的系列叢書[1]。在此介紹其中的一本「Inside Microsoft SQL Server 2005 : The Storage Engine」,執筆者為先前 Inside SQL Server 各版本的作者 Kalen Delaney,在此次 Inside 系列討論 SQL Server 2005 的四本書中,她改任系列編輯(Series Editor),並於本書擔任作者。

一翻開書籍前頁,看到 Kalen Delaney 的致謝,立即對本書的嚴謹要求與參與人力嘆為觀止。大概很少書是原廠產品團隊派一群人伺候,提供技術諮詢還要兼審稿,外加微軟出版社的編輯審稿,並有作者所在公司同事的襄助。或許,討論 SQL Server 這類大型產品的書籍還真需要人脈廣,經驗足才能撰寫[2]

筆者長年在各企業間解決 SQL Server 的問題,例如功能不會用、效能不佳、不穩、不安全等,深覺最主要的原因是使用者對產品的了解不夠。尤其一般使用者存有誤解,以為 SQL Server 不需要專業的學習與管理,像 Office 等產品,隨意架設使用。若執行起來效能不佳,便認定產品本身的能力不足。其實不然,SQL Server 在台灣,乃至於世界各地都已經進入企業的關鍵系統,數以兆(tera)計的資料量比比皆是。而我們所欠缺的是深入的知識與經驗,以發揮 SQL Server 所提供的各種功能。此書便是鑽研 SQL Server 設計原理的最佳管道。

資料庫引擎之堂奧

相信久用資料庫的管理與開發人員大都熟悉資料庫、資料表或索引的建置,交易的管理,但 SQL Server 資料庫儲存引擎(Storage Engine)實際如何完成你的要求,卻諱莫如深。這本書將讓你知其然也知其所以然。

書中除了解釋設計理念與運作原理外,還輔之以測試驗證的方式。因此本書蘊含了許多官方文件沒有說明的技巧,如查詢特定的動態管理檢視、執行各種 DBCC 指令,如 DBCC INDDBCC PAGE、各種追蹤旗標等。藉以解釋 SQL Server 如何使用 CPU、記憶體、硬碟與網路等硬體資源,資料表、索引頁、交易紀錄的結構,資料在新增、修改、刪除的過程中,對實體存放的影響,交易與鎖定的運作原理等等。

由於分成了四冊,由 Kalen Delaney主寫的本書其章節不多,僅有八章。鎖定在描述資料引擎的基礎運作,例如資料庫的設定與資料實際在硬碟的擺放,索引結構,交易與鎖定等。

由於 SQL Server 2005 提供了非常多的服務,如 Database ServicesAnalysis ServicesReporting ServicesNotification ServicesIntegration Services 等,讓筆者覺得 SQL Server 像一個品牌了,有如 Office 一樣,其下涵蓋了非常多個別的產品。再加上一堆的版本,如 EnterpriseEvaluationStandardWorkgroupDeveloperExpress[3],還有 32 64 位元的差異,讓安裝 SQL Server 變得複雜。一般新入手的使用者恐怕連需要安裝哪些服務,各安裝步驟的意義,對其後系統執行時的影響都一知半解。本書的第一章從安裝與昇級開始談起,可見得 SQL Server 2005 的安裝都變得有學問了J

SQL Server 的資料庫服務由多個元件所組成,可大分為協定存取層、關聯引擎(Relational Engine,一般也稱為查詢處理器 Query Processor)、儲存引擎、SQL 核心等部份。本書的第二章先概略介紹這些元件的定位,好讓讀者知道本書所討論的重點:儲存引擎,在整體 SQL Server 資料庫服務中所佔的位置。

SQL Server 伺服器執行個體和資料庫皆提供了相當多的設定,但由於預設的設定已經符合大多數的使用情境,因此 SQL Server 管理師們大都不會深究這些設定。但隨著使用人數增多,資料量增大,安全需求提高,這些設定就變得重要。本書的第三章和第四章詳細解說了這些設定。另外,SQL Server 2005 所新增的 Database SnapshotSchema 等功能也是本章的重點。

為維護資料更新時的完整性,SQL Server 透過放在硬碟上的交易紀錄(transaction log)先行記載變更,再批次更新到資料檔案中。但又為了執行效率與穩定,必須設計一系列精細的運作。而管理者需要熟悉這些運作,以提供足夠的硬碟空間,並設計資料庫備份的策略。本書第五章探討了交易紀錄的運作方式,連帶剖析備份還原的設計。

資料表是實際存放資料的地方,也就是一切存取的核心。如何有效地切割資料欄位,精確地使用資料格式,設定各種維護資料正確性的條件約束(Constraint)…等等,都是資料庫管理師和程式設計人員所需要謹慎考慮的。本書第六章詳細解釋了資料實際在硬碟上的擺放方式,各種資料型態對儲存的影響,以及修改既有的資料表設計。

索引是有效使用資料庫引擎最重要的議題之一,但建立與維護索引並不是容易的事,索引建少了,查詢效率不好,建多了,危害新增、修改、刪除。什麼欄位該建,是否要對計算欄位、檢視建索引?建立索引將耗掉多少硬碟資源等,都是資料庫管理師所必備的知識。本書第七章佔據了全書最大的篇幅,詳細解釋了索引的組織結構,叢集(Clustered)和非叢集(Nonclustered)索引的差異、資料切割(Partition)SQL Server 建置和維護索引的方式,管理者應注意的資料不連續與索引重整等議題。

當多人或多個批次工作同時存取相同範圍的資料時,交易與鎖定的管理就變得很重要。SQL Server 2005 在此版加入了「紀錄版本(row versioning)」功能,本書作者稱為樂觀並行(Optimistic concurrency),而稱呼經由資源鎖定的並行處理為悲觀並行(Pessimistic concurrency)SQL Server 2000以前的版本僅支援悲觀並行。「紀錄版本」保留紀錄最後完成交易的值,供使用者查詢,讓查詢的工作不影響修改的工作,反之亦然。而不像以往透過資源鎖定的方式,在預設的交易層級下,正在讀的紀錄不能改,正在改的紀錄不能讀。而不管是哪一種並行處理,本書第八章都提供了深入的解釋,這是多人同時存取時,效能好壞的關鍵因素之一。

閱讀建議

本書不是入門書,不會一步步導引你操作。若你尚不了解 SQL Server,玩得不深,本書可能就沉重了些。而就算你是專業的 SQL Server 管理師,我相信本書依然是蠻難啃的。因為作者解釋的大都是 SQL Server 底層的運作原理,少有操作講解。為了解釋,在書中提供像字典似的列表,並輔之以示意圖。讀起來枯燥無味,但面臨問題時,是深入探究的起點。

雖然章節間沒有必然關係,但整本書所設計的順序還是從基礎到衍生,因此從第一章看起是比較好的。快速瀏覽過各章節的內容後,在實際工作時,碰到需要深入研究的問題,再回來溫習書中所解釋的原理。對於讀不懂的章節不要沮喪,大部分的人應該都跟你一樣,待更有經驗且有空時,重新讀過,相信會有不同的收穫。

若你已經是 SQL Server 2000 的高手,這本書依然適用,但可能會缺乏耐心逐字閱讀,因為部分內容是與 2000 重疊的。仍勸你瀏覽與精讀並用,遇到熟知的部分快速翻閱,但讀到 2005 新增的部份,就需要手腦並用了,既詳讀文章,且在 SQL Server 2005 上操作一遍,以確認真的讀通了。

相關閱讀

除了本書外,Inside Microsoft SQL Server 2005 系列叢書中,當下買得到的尚有

l Inside Microsoft SQL Server 2005 : T-SQL Querying。作者:Itzik Ben-GanLubor Kollar Dejan Sarka。微軟出版社出版。

l Inside Microsoft SQL Server 2005 : T-SQL Programming。作者Itzik Ben-GanDejan SarkaRoger Wolter微軟出版社出版。

本書的相關網址http://www.insidesqlserver.com/及其系列書籍的相關網址http://www.sql.co.il/books/insidetsql2005/。若你不欲購買本書,或可在該網站逛逛。



[1] Inside SQL Server 2005 系列的另外兩本書名,筆者列在文章的結尾。而 Inside Microsoft SQL Server 2005: Query Tuning and Optimization 這一本似乎還沒上市。

[2] 雖提供幫助的人數眾多,但本書依然有著許多勘誤,Kalen 有詳列在書籍的網站上。可見得要撰寫一本無誤的技術書籍還真困難。

[3] 此為書中所列的版本,在微軟網站上還可以看到 Mobile Compact 等其他版本。

從整理過的資料才找得到知識,建立兼具效率與彈性的提取、轉換與載入資料之流程

資料轉換的需求

當我們要把其他系統的資料如以往 dBase/Clipper/FoxPro dbfExcel xlscsvAccess/Jet mdb 乃至於 SQL Server/Oracle/DB 2/Teradata 等大型資料庫,或是 html/XML 檔案彼此互轉時,往往需要搭配工具,輔之以自己動手撰寫簡單的指令碼或程式。

除了彈性效率兩大重點外,這些轉換的動作往往還特別需要注意錯誤處理,將有錯誤的記錄另外存放起來供事後檢視。因為老舊系統或是其他非資料庫系統在設計時,大都沒有注意到關連式資料庫的正規劃,以及一些相關的限制式( uniquedefaultcheckprimary key),所以資料內容很可能不會完全符合我們利用關聯式資料庫所定義的資料規格。而多個系統的資料匯聚時,還會發生資料重複、格式不一致、內容衝突、資料過時...等等問題。

上述情況在一般中大型的企業非常普遍,由於資訊系統經年累月地開發與使用,各個單位與歷代的資訊工程師對資料處理方式的偏好不同,加上資訊技術日新月異,自然導致全公司的資料儲存與使用方式千奇百怪。但若要讓資訊系統發揮最大效用,又往往要讓這些系統能夠溝通無阻,彼此簡單地交換資料以提供整合方便的資訊。

近幾年來,資料倉儲(Data warehouse)/線上分析(OLAP)/資料採礦(Data Mining)等系統開始流行,因為企業已能夠利用各型資料庫系統累積線上交易(OLTP)資料,而這些累積的資料大多潛藏著公司的營運指標或是客戶的行為邏輯。為了找出其中的模式,必須將存在各交易子系統的資料;其中符合分析主題之內容,以一致的表現方式集中儲存到資料倉儲。

困難處

這時第一個技術上的難題就是容易上手、有彈性且高效率的資料轉換工具。其主要的困難點如下:

l 異質型資料來源:用來集中儲存資料的資料倉儲一般就是一個超大型關聯式資料庫,如專屬的 NCR Teradata 或通用的 MS SQL Server...等,而提供轉進資料的各交易系統卻可能多所不同,設計師要同時了解多種資料存取機制並不容易。

l 商業邏輯運算與彈性:一般在匯入資料至目的端之前,可能會先完成分割、過濾、查閱(將代碼轉成值)、彙總、聯集、排序...等動作。且在流程中輔之以優先順序、條件判斷、交易管理、資料庫物件的維護、錯誤處理、訊息發佈...等。且隨著資料來源增加,資料目的地用途變異與擴增,設計用來轉換資料的物件要能容易修改與重用。

l 效率:彈性與效率基本上是兩個互相衝突的面向,彈性代表著工具本身會做廣泛地測試,讓使用者簡單設定完畢後,它會自己找到正確的處理解決方式,但這也代表需要較複雜的準備工作。而效率則需要以最簡單直觀的方式處理單一事情,這意涵著一點設定錯誤就全毀了。在廣泛地整合時,我們需要彈性,但對於大量資料的載入,又必須有效率。筆者曾碰過需要轉換數天,以 tera 為單位的資料量。而在轉換過程中,一般只能乾等,我們稱此為資料處理的空窗期。空窗期越長,代表資料及時性越糟,延誤下一個資料使用階段,這是大家所不樂見的。

l 校正與一致化:凡是要轉進資料倉儲的資料應先求得格式與意義之一致,在不同的交易系統中,如公司人事資料可能用「男」、「女」來標示性別,但客戶資料卻可能用「0」、「1」,其他系統的性別欄位還可能使用 TrueFalse FemaleMale 等等,隨著當時的系統開發人員喜好而定。但這在資料倉儲內一定要一致。另外,某個系統的地址相關欄位可能是五欄,另一個可能是六欄或四欄,但你的分析可能只需要三欄,因此轉到資料倉儲時需要合併或分割欄位,更有甚者是原來三欄的資料可能要改成三列,或著反之。種種語意、格式、資料的正確性等諸多問題要在轉換時期解決;這不是一件容易的事情。

l 週期性處理與管理:從線上交易系統將資料轉進資料倉儲是週期性的工作,絕不是累一次就可以一勞永逸,要讓整個轉換工作可以輕易地批次執行,如此系統才可能長久。另外,就筆者接觸過的大型企業,其 DTS 封裝從 50 多個到 700 多個都有,平均而言有 2~300 個封裝,而參與使用該資料轉換技術的工程師規模從 2~3 人到幾十人。因此,如何妥善管理,其面向包含部署、備份、版本控管、災難復原、教育訓練...等,都需要考慮。

l 安全:按照安全的最小接觸面原理,整合就有可能增加安全漏洞。由於是多種資料彙集,一定會碰上各系統的存取介面、網路流通、彼此系統的帳號登入、機密性資料處理、經手人的授權、背景批次執行的帳號、加解密資料的流程等問題。

微軟的 SQL Server 小組將資料整合納入該產品線需要滿足的目標,其解決方案為何呢?

需求無法滿足,SSIS 應運而生

SQL Server 7.0 版首次導入的資料轉換服務(Data Transformation Services)是一個容易上手的資料搬移和轉換工具,讓不同的資料來源與目的可以透過 ODBC/OLE DB 來互相轉換資料。當你有各型資料格式或內容需要轉換,將資料搬有運無時,DTS 是可輕易上手的工具。SQL Server 2000 之後,更是強化了它,使其成為最普遍的資料處理工具。

DTS 之所以稱為資料轉換(Data Transformation),就是因為它主要的目的在轉換,而不只是搬移資料。若僅搬移資料,光是 SQL Server 就不下五六種方法,如複製(Replication)、卸離/附加(Detach/Attach)、備份/還原(Backup/Restore)Bulk Insert/Select Into/BCPLog Shipping等等,都可以將資料從一處搬到另一處,但它們的特色大都是原封不動地搬移,且不整合其他非資料處理功能,只有 DTS 講究轉換與流程。

隨著企業規模擴大、企業體內整體系統的數量遞增、單一系統資料量累積,系統間資料整合之需求提升,以及上述幾點難題讓舊架構的 DTS 顯得力不從心,微軟必須以全新架構的 SSIS 來提供解決之道。

SQL Server 2005 放棄了之前相當成功的 DTS,完全重新設計與改寫。在這個版本推出了 SQL Server Integration Services(SSIS) ,務求提升效能和增添更豐富的功能。而企圖心從改變名稱就可以看得出來,它不僅僅要做兩個系統間的資料轉換,還要提供多個系統間的資料整合。

SSIS 從核心重新開發,成為脫胎換骨的新產品。其中最大的變革之一是將流程(Integration Services run-time engine)與資料轉換(Integration Services data flow engine)分成兩大引擎來處理。這提供了較佳的流程控管與資料處理細節之可見度,同時增加了使用者自行撰寫程式延伸 SSIS 的標準化與方便性。

新版本在封裝執行的流程控管、錯誤處理、物件設定、除錯、部署、執行記錄、安全架構、效率,以及開發者透過微軟版本控管機制( Visual SourceSafe VSSVisual Studio Team System VSTS)控管 SSIS 封裝的版本、自行以 .NET 語言延伸開發…等等方面都有長足的進步。若你有存放在不同系統的資料需要交換,例如從甲資料庫轉到乙檔案格式,便可以考慮這個工具,倒是不一定要有 SQL Server 的參與。

SSIS 的開發小組讓這個產品具有更開放的架構、更多功能、更具彈性、以及更高的執行效率。

聽聽產品開發者怎麼說

若你想要熟悉 SSIS,在此介紹一本好書:Microsoft SQL Server 2005 Integration Services,作者Kirk Haselden(網誌位址:http://sqljunkies.com/weblog/knight_reign/) 本身就是 SSIS 的開發經理(Development Manager),所以其著作應該算是官方說法了J

本書圍繞在前述筆者所列的主題上;為你詳加介紹這個全新的產品。書中除了說明 SSIS what how,也就是它所提供的某項功能是什麼,以及如何使用外,也稍微談了 why,敘述設計該項功能的緣由。

這本書不算入門書,但也不是深奧的進階書,逐章讀過後,應可以充分運用 SSIS。但你最好稍有用過微軟的相關產品,如 DTSSQL Server,寫過 SQL 語言、簡單的 ScriptVB.NET C#。當然,若你不想自己開發執行在 SSIS 平台上的物件,可以跳過本書的第六部份 Programming Integration Services,也就不需要熟悉 C# 語言了。

最後,筆者覺得稍為可惜的是本書未提供所有 SSIS 控製流程工作(control flow task)與資料流程元件(data flow component)的說明,讓我們在使用 SSIS 的某個物件時,可以如同翻閱字典一類的工具書,參照說明與簡單的實例[1]。對於這些獨立的物件,作者只舉其大者,以範例說明,且略過了與 Analysis Services 整合的部份。

相關閱讀

除了本書之外,若你覺得還需要其他的免費資源,可以參考以下的網址:

l http://msdn.microsoft.com/sql/bi/integration/default.aspx:關於 SSIS 的官方網站,有非常多的資源。

l http://blogs.msdn.com/ashvinis/http://sqljunkies.com/WebLog/ashvinis/default.aspx:此網誌的作者 Ashvini Sharma SSIS 小組的 Development Lead。這裡有一些不錯的技術說明。可惜,他似乎不再維護這兩個網誌了。而上述 MSDN 網址提供了其他技術人員的網誌連結(包含本書作者),你都可以逛逛J

l http://www.sqlis.comhttp://www.sqldts.com:這兩個姐妹站有許多關於 DTS SSIS 的技術文件。

l http://www.dbworld.com.tw:筆者在此處也撰寫了大量關於 SSIS 的技術文章。

@書名:Microsoft SQL Server 2005 Integration Services

@作者:Kirk Haselden

@出版商:SAMS

@售價:2040


[1] 關於工具書這一部份,或許你會說看線上說明不就好了,但就筆者個人覺得,SSIS 針對每個物件提供的線上說明不夠詳盡,往往模擬兩可,或根本沒有範例與說明,讓人需要經過錯誤嘗試後,才能稍微了解該物件的目的和用法。

給我份報告,讓數據說話。但引用的數據不對,公式改成這樣吧,那顏色換一下,還有...

大多數的資訊系統都輸出報表,而每個企業也都存在著各式報表。隨著商業競爭日益激烈,資訊系統需要提供隨手可得、即時而正確的資料。若要讓數據說話,就必須正確地引用資料,套上商業邏輯後,有條理而直觀地呈現。但當企業具一定規模後,要做到此並不容易。

資訊發送平台

以往的報表隨附在應用程式內,使用者要看什麼樣的報表,就開該應用程式。因此運算力憑藉的是各系統的電腦,安全由該應用程式控管,資料憑專屬的方式取得。而在我們需要廣泛地分析,大量的報表,整合的資料來源,統一地管理維護時,這種分散的報表開發與部署方式並不合用[1]

隨著商業智慧(Business Intelligence BI)概念的流行,大型資料倉儲、累積且集中的多方資料、廣泛而多樣的分析方式...種種需求讓分析變成獨立的系統,而統籌各式報表的報表平台應運而生,微軟 2004 年一月推出的 Reporting Services 是一個很好的範例。它的訴求在完整的報表生命週期管理,從開發、管理、派送三個面向,滿足對報表平台大部分的需求。

然而,真的要好好設計與照顧報表平台並不容易,就筆者個人的經驗,主要的難度有以下面向:

l 正確:資料來源廣泛,商業邏輯複雜,參與人員來自不同單位。例如,在報表的生命過程中,參與者有報表檢視者、需求分析人員、報表設計者、提供資料來源之交易系統的操作者、轉至資料倉儲或超市的資料轉換過程...等等。冗長的流程讓報表設計與除錯上必須小心翼翼。筆者就曾與同事為了上百筆紀錄彙總後達 1 億多的金額,但短少 300 元而忙了一天,最後發現是輸入者選錯了員工部門。開發的初期,更不知多少次,在資料海中比對了半天後,才發現資料轉換的過程中有誤。

l 呈現:資料呈現方式因人的好惡而難以設計,現今報表的製作還多少需要一點美術概念。報表設計需要能讓資訊以最有效的方式傳達,這裡面有著許多文化因素,例如,報表工具大都是英語體系國家發明的,而中文的呈現往往有些細微差異,例如直書/橫書、中文大寫數字、日期時間的呈現...等等。最麻煩的是用新的工作做出與舊格式完全相同的報表。畢竟開發工具不同,例如以往是用 Clipper Office 系列產品,搭配徒手撰寫程式,因此許多用程式所造成的列印效果,而今要改用 Web 呈現,這是用鐵鎚打蒼蠅。

l 效率:報表平台的資料量大,使用人數多,公式計算與繪製報表的邏輯;讓產生報表變得雙重複雜。實做過程中,隨時要考慮到如何有效地切割與分散運算,限制使用者的存取[2]

l 安全:當報表數量與使用人數皆多時,認證與授權設計的複雜度就會倍增,你可以想像數百人存取數百張報表,不同人可存取的報表不同,不同人存取相同報表時,呈現的內容也要不同。但這些人平日的工作執掌還會有許多的變動。另外,加密資料的維護也造成系統備份/還原上需要多花一點心思。

l 發送:使用者要如何方便地看到報表。由於集中在報表平台,最方便的方式當然是讓使用者以瀏覽器瀏覽,但若使用者人數龐大,大家都擠到 Web Server 看報表,這會造成效率瓶頸[3],安全也難以管控。
Reporting Services
預設提供週期性;批次地以電子郵件派送報表。或是自動產生報表後存放到共用資料夾,你可以再搭配 FTP 等方式來提供存取機制。或是以 .NET 程式語言整合 Report Viewer Control,乃至於以 URL 連結某份報表,或直接呼叫 Reporting Services web service,都是讓使用者可以存取報表的方式。選項多,事前規劃就變得重要。設計得好,既可減輕運算負擔,也簡化安全的複雜性。

l 彈性:由於企業體內早已存在行之有年的安全架構、資料存放與管理機制、資訊呈現的前端平台( Enterprise Information Portal EIP),因此,要新加入一個報表平台,很有可能要與上述的架構整合。這必須要能夠讓 RS 的使用者或開發者自行擴充各種需求,例如安全的認證方式,資料提取的方式,以及整合進既有的應用程式來呈現報表。大家須自行依照需求,打造延伸功能的模組[4]

當報表從交易型系統的附屬品搖身變成分析系統的主要角色之一時,其重要性與專業性已大幅提升。

就自己實際任職顧問的企業,以 Reporting Service 為報表平台,負責開發報表者僅有一人,花了約一年半的時間,製作了七十多張報表,至今五十多張報表上線使用。就她表示:開發工具很方便,可以很容易地做出報表來,只是資料驗證要花時間,大部分碰到的問題都是從資料庫內數千個資料表間,釐清用途與報表邏輯的問題。

另一個較麻煩的問題是使用者需求變更,由於開發時程較長,一年半前系統分析人員(SA)所提供的報表規格,在驗收時可能已經不適用了。一則是使用報表的習慣變,例如:將原本所列出的各單位業績金額,修改為只列出入帳的金額。此種簡單的過濾條件增減,以及增加金額小計、總計的格式修改倒還好。另一是較令人頭痛的結構變更;例如:企業組織調整。當組織結構一改,所有的報表就要重新檢驗。先前,組織內的五大體系合併,而造成報表開發時程延誤的原因之一是處理報表共用耗時過多。原本幫主體系做了六、七十支的報表,之後為了讓其他體系共用,改利用某個屬性的過濾條件撈取需要的組織資料。其中,若是沒有牽扯組織結構的報表內容,還好修改。但若碰上需要逐一呈現組織階層、隸屬單位或是人員的話,在製作的過程上還是遇到許多困難的地方需要克服。最主要的原因是每個體系的組織階層不同,以及同一個組織內其業務員所隸屬的階層單位不同,為了要將這些業務員的資料呈現在報表上,花費了不少腦力。所幸這些問題都已獲得解決,未來只要跟著既有規則走,就可以較輕鬆地開發報表了。」

當問題無解時,回去唸理論

針對前文所討論的難處,先引用不曉得在哪本雜誌上讀到的,華碩董事長施崇棠先生常對該企業員工說的話:「回去把電磁學再唸二、三十遍,唸到不只 know how,還要 know why。」面對錯綜複雜的問題時,唯有追本溯源,提綱挈領才能企求釜底抽薪地解決問題。所以,多看書是必要的第一步J

在此介紹一本講述微軟 Reporting Services 不錯的書:「Professional SQL Server 2005 Reporting Services」,出版商為 Wrox。你可以在以下的網頁取得該書的第七章試閱:http://www.microsoft.com/technet/prodtechnol/sql/2005/technologies/rch7rptslnpatternrecipes.mspx。這一章相當不錯,可以當作各種小技巧的範本。若沒時間閱讀該書,單靠此章就可以提昇不少功力J

相對於上述整體報表平台架構性的問題,本書著墨不多,它就是平實地解釋各項功能,並提供各種設計範例。適合初學者按部就班地了解 Reporting Services 各個面向。但若要完整處理報表平台,這就不僅僅是 Reporting Services 本身的問題了,例如 Windows 平台的目錄服務、資料庫的管理維護、使用者存取報表的應用程式整合...等等,這需要廣泛涉獵各種技術,並充分了解使用者需求才行。

該書是從前一版描述 Reporting Services 2000 的內容改寫而來,由於 Reporting Services 2000 2005 的相容性很高,因此若你仍在用 2000 版本,此本書仍有參考價值。

閱讀建議

該書是 Reporting Services 2005 的入門書,地毯式地描述各項功能。其英文文字平易近人,讓讀者不會因為語文本身造成艱澀難懂。

本書分五個部份介紹 Reporting Services,其中第二部份介紹報表設計(從第四章到第七章),第四部份討論報表服務管理(第十、十一章),這兩部份需要熟悉。另外,第一部分的簡介,其第三章的架構說明最好也要熟讀。至於其他部分,例如第三部份之 Report Model Report Builder 的使用,以及第五部份的將報表平台與應用程式整合,就看你是否有此需求了。

相關閱讀

l http://msdn.microsoft.com/sql/bi/reporting/default.aspx 此處有很多關於 Reporting Services 的資源,特別是有一些微軟已經建立好的報表範本,讓你可以分析一些應用系統的執行狀況。另有許多錄製的線上研討會,也可以引導你入門。微軟的線上討論區 Reporting Services 版區也有非常多的問題解析: http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=82&SiteID=1

l 介紹一本中文書:SQL Server 2005 Reporting Services 報表服務實務應用,博碩出版社出版,作者:姚巧玫、尹相志、許致學。這三位作者在 SQL Server 領域都鑽研已久,本書融合他們的技術與實務經驗而成,是一本不錯的參考書。

另外,報表設計的主軸有二,一是資料來源,另一是佈置呈現方式。對 Reporting Services 來說,要強化上述的兩部份,你還需要熟悉 SQL VB.NET 兩種語言。SQL 用在處理資料,例如將複雜的資料邏輯在資料庫端以預存程序(stored procedure)撰寫,然後餵給報表。而在報表版面設計時,所有預設功能外的加值,都是靠撰寫 VB.NET

@書名:Professional SQL Server 2005 Reporting Services

@作者:Paul Turley, Todd Bryant, James Counihan, Dave DuVarney 等著

@出版商:Wrox

@售價:1360


[1] 不過,我並不是說哪一種報表應用模式會取代哪一種,Visual Studio 2005 所提供 Report Viewer Control 也提供了不需要報表平台(Reporting Services),讓個別報表存放在應用程式自身中,隨著應用程式散佈的模式。

[2] 筆者在教授 Reporting Services 的課程中,遇到一位朋友抱怨效率不佳,我問她資料來源多大,她回答:一百萬筆紀錄 Join 另外一百萬筆!你可以想見,當資料庫緩慢地 Join 完後,傳遞給 RSRS 還要再進一步地彙總與繪製,這過程讓效率如何能好?

[3] Reporting Services 企業版是可以透過多台報表伺服器存取同一台存放中繼資料的 SQL Server 資料庫,以建構負載平衡的解決方案。

[4]通常撰寫這些模組,必須遵照兩端的標準,例如,既有的資料庫存取方式,並滿足 RS 結構定義,其要注意的細節往往不簡單。

Web 應用程式開發的標準化與範本化,組裝大積木,快速開發

.NET 2.0 在去年底(2005 )風光上市,就筆者來看,最大的新增在 Team System 架構,與豐富了 ASP.NET 的開發功能。而對廣大的使用者來說,無疑是 ASP.NET 2.0 最讓人興奮。

@小標:Web 應用程式開發的新頁章

ASP.NET 2.0 改良 1.x 版的設計,讓 Web 應用程式的開發架構變得更有彈性,例如:

l 開發專案(project)以檔案和目錄為單位,不由專案檔啟動。利用臨時的 Web 服務執行測試,在開發環境免掉了 IIS(Internet Information Services)服務。

l 使用免費的 SQL Server Express 版本資料庫伺服程式,搭配自動建立的資料庫檔案,以存放各種服務的中繼資料。

l 透過各種設定管理的工具,簡化 web.config machine.config 等設定檔的管理。

l 經由各種檔案獨立且自動化的編譯,讓開發環境所提供的 IntelliSense功能更聰明,部署個別網頁更為簡單,不會因為一兩個網頁,壞了整個網站的編譯。

l 提供數量倍增的控制項(control)

l ...

種種設計,讓開發者的環境需求較為輕便。而內建豐富的功能,讓你我透過點選、拖曳就可以完成大部份的基礎工作。

Web 應用程式在企業內越來越風行,隨著資訊教育普及,員工倚賴 IT 輔助日深,各種客製化小系統如雨後春筍遍佈在企業內。雖然系統需求各異,但有許多共通的基本功能很重要,做起來卻麻煩。例如使用者帳號管理、登入、授權與加密,個人化網頁,瀏覽路徑導覽,一致性的網頁設計風格...等。ASP.NET 2.0 內建這些功能,並透過預設的 Provider,將實做這些功能所需之管理資訊存放到自動建立的 SQL Express 資料庫內。開發人員僅靠設定就可以替網站系統完成大部分的基礎設施。

ASP.NET 2.0 除了提供很多新的內容,也改善了舊技術,例如 Web Part。新的 Web Part 技術在 ASP.NET 2.0 網頁中,搭配預設的個人化功能,可以讓使用者隨意佈置網站版面,而開發者卻不需要花費什麼功夫。但這與以往透過 Visual Studio 2003 搭配額外下載的 Web Part 範本,開發在 Windows 2003 SharePoint Services(WSS) 使用的 Web Part 並不相同。或許在下一版的 WSS 中,將會全面採用 ASP.NET 2.0 的架構。

@小標:快速拼裝的速食系統

FrontPage 出現後,全世界產生了幾百萬張醜網頁曾在美國的大型研討會聽演講者這麼說,主講人是希望藉此提醒基礎知識的重要。筆者贊同深入技術的必要,但另一方面來說,FrontPage 讓人們敢於嘗試建立網頁也功不可沒,畢竟要跨出第一步最難。就曾經拜訪過的企業,不知多少小網站是起自於 FrontPage,而後若該系統變得重要,再重新思考網站的定位,與進一步採用更專業地開發設計流程。而非技術人員用 FrontPage 愉悅地在網路上建立出自己的首頁,更豐富了整個 Web 世界。

我相信 ASP.NET 2.0 所提供的各式服務,如 membershiprole managementprofileweb part personalizationsite map...等,再加上一大堆的控制項,將會讓企業內,部門級的網站系統開發更為相像。就像 Visual Basic 所造就的 Windows Form 充斥,或如上述,透過 FrontPage 來建立的初級網站林立。今後用 Visual Studio 所快速開發的 ASP.NET 網站也將隨處可見,且都大同小異。

筆者在授課時,與學員的互動中可感受到,大家驚艷於 ASP.NET 2.0 大幅簡化了基礎功能的開發,但又懼怕日後需求變易時,難於駕馭。大堆頭的功能越多,越容易拼裝上陣。一旦用上了,要修改得精細合身卻又不易。且下層連結運作的機制必定複雜,非一時三刻可以搞懂。就好像騎腳踏車時,若有問題還可能自己維護。但汽車拋錨時,修理它會讓你我卻步。但,行遠路時,你要開車還是騎腳踏車呢?

@小標:登堂入室

若你已玩過一陣 ASP.NET 2.0,在此介紹一本關於該技術的好書:Programming Microsoft ASP.NET 2.0 Application Advanced Topics。這不是入門書,它未曾介紹如何無中生有建立一個 ASP.NET 網站,或一步步說明如何使用 Visual Studio 2005 開發工具,乃至於 C# 語法解說...等等。簡言之,滿是字,很少圖。

就作者 Dino Esposito 的規劃,若你是剛入門者,可能他的另外一本書 Programming Microsoft ASP.NET 2.0 Core Reference 比較適合。但依筆者來看,還是到坊間找中文書比較便宜,原文書太貴了L

這本書著重解釋基礎機制的運作原理,例如:各種程式碼、定義、資源等不同檔案的配置、動態編譯、載入與釋放,Handler Module 的設計,非同步執行網頁的方式,自行撰寫控制項等。

其功用比較像是工具書,讓你在實做較為艱深的功能時可以參考專章。或是查閱一些細部的設定,例如透過第三章 ASP.NET Configuration 尋找繁多的 machine.config web.config 等設定之格式與意義。

第四章的Building Custom ASP.NET Providers 是要深入了解 ASP.NET 2.0 的一個重點,Provider Model[1] 應該是此版最值得研究的架構之一。其他的技術,如動態編譯與載入、Handler ModuleWeb User Control Custom ASP.NET Control...等,在本書雖都有深入的探討,但畢竟它們自 ASP.NET 1.0 始就已經存在,2.0 對這些部份算是小幅改良。

提供建置網站的程式基礎架構時,如何能讓開發者自由擴充是最難的項目。由於各企業多存在行之有年的資料結構與商業邏輯,如何讓新建立的網站可以套用舊的資料,儘量保有以往對資訊技術的投資。例如,舊的會員資料庫已經存在,但如何讓新撰寫的 ASP.NET 2.0 網站可以使用到該資料庫來認證會員身份,使用個人資料(profile)。抑或是網站導覽的資料結構早已存在舊網站中,又如何讓新的 SiteMapPath TreeViewMenu SiteMapDatSource 等控制項與舊資料結合,好在以新技術撰寫的網頁中提供整合的網站導覽。

ASP.NET 2.0 針對上述問題的解法是 Provider Model。模型最具威力的地方就是從繁瑣的表徵中,抽象出核心運作之原理,在提綱挈領描繪出骨幹後,你可以將相同的經驗類推到各種功能開發中。就筆者來看,Provider Design Pattern,物件導向分析、設計與撰寫,元件化重用等方面,都做了絕佳的示範[2]

ASP.NET 2.0 這次新增的 membershipsite mapsprofile...等服務,都依照 Provider Model 的精神實做,也就是提供四個層次的架構:

l 與使用者互動的控制項(UI)

l 標準的程式存取介面(API)

l 存取資料提供者(Provider)

l 實體中繼資料結構

在每一層,ASP.NET 2.0 都提供了直接可用的物件。但你仍可依自己的需要,隨意置換某個服務任一層的元件,而其他層的既有架構照舊使用。

除了上述內容之外,本書對於一些越來越熱門的主題,例如 Ajax 和微軟未來的 Atlas,或是為行動裝置開發網頁,作者都稍有著墨,但並未深入探討。

@小標:閱讀建議

再次強調,此書不是入門書。若你是 ASP.NET 2.0 的生手,但某些場合讓你親炙了許多 ASP.NET 2.0 炫麗的功能,例如很酷的控制項、Master-Content 網頁的設計,Theme Skin 的套用、整合自身與 Reporting Services 的報表...等,這些都在前述作者的另一本書內,本書並不適合你。

當你需要深入了解 ASP.NET 2.0 的基礎原理,架構較為大型的網站,並希望重複使用自己曾經開發的模組或元件時,此書所討論的主題:如 Handler Module、自訂 Provider、自訂控制項等,就很值得你深究。

建議你先看完第一、四、七、十章,分別了解 ASP.NET 2.0 的檔案配置與編譯、提供各種服務的 Provider PatternWeb Part架構,以及 site navigation 等技術。因為相較於其他內容,這四章或許會比較快用到J。其他的章節稍做瀏覽,讓你往後鑽研進階功能時,知道在哪可以找到資源。

本書的範例很多,且彼此獨立,在翻閱各章內容時,可以同時執行一下範例程式,先了解功能為何,是否吸引你進一步深研該章節。不過,由於一些應用程式的基本設定可能與你的系統環境不合,因此,若不熟悉 ASP.NET 2.0 的設定與執行, SQL Server 資料庫連線的方式,基本的 C# 語言,則可能很多範例執行起來會有問題L

@小標:相關閱讀

ASP.NET 的中文書籍向來是許多作者的最愛,你可以駐足書店,尋找自己喜歡的風格。在此,筆者僅建議你逛逛以下的網站:

l MSDNhttp://msdn.microsoft.com/asp.net/。微軟技術的大本營不可不去J,對於初學者而言,以下的內容蠻不錯的: http://msdn.microsoft.com/asp.net/learning/learn/newtodevelopment/default.aspxMSDN 為本書作者 Dino Esposito 提供的網頁如下:http://msdn.microsoft.com/asp.net/community/authors/dinoesposito/default.aspx

l http://www.gotdotnet.com/ 分門別類地整理相關技術,而官方的討論區也有相當豐富的內容 http://forums.microsoft.com/MSDN/default.aspx?SiteID=1

l 當然,恆逸講師群所努力充實的 .NET Magazine 網站也可讓你獲益良多:http://www.netmag.com.tw



[1]相關資料可參閱 MSDN 所提供的說明與原始碼範例, http://msdn.microsoft.com/asp.net/downloads/providers/ASP.NET 2.0 內建的各種服務,其預設的資料儲存區都是 SQL Server,在此網址有提供 C# 原始碼,實做各種 provider 存取放在 Access/Jet 資料庫內的中繼資料。或許使用哪種 DB 格式並不重要,但一窺各種 Provider C# 原始碼,卻是練功的好方法J

[2] 就筆者自己的感覺,它示範了 FactoryAdapterFaçade design pattern。同時,ODBCOLE DBADO.NET 似乎早已使用了這種設計方式,你可看到大家用的都是 driverprovideradapter 等字樣J。不過,將各種 Web 網站服務的開發架構標準化,雖不是新想法,但的確是值得鼓勵與學習的新技術。

遞迴修正到滿意為止,由下而上,漸次遞增,越來越合用

@小標:補鞋匠的孩子沒鞋穿

英諺有云:補鞋匠的孩子沒鞋穿(Cobbler’s children go shoeless),用在軟體從業人員身上還真貼切J。我們專門幫各行各業自動化,提升工作品質,增加專案效率。但自身如何建構一個可控管,有效率、高品質的軟體開發流程卻一直是個令人頭大的問題。

由於軟體專案的重複性較低,不管是客戶需求、使用技術、團隊成員養成、專案成本等面向,在兩個案子間都存在著極大差異。一般在其他工程界,如製造、建築等,行之有年而較成熟的專案管理理論拿到軟體界來,通常都難以適用。

軟體工程的大師們一直在找尋著能降低軟體專案不確定性的方法。例如分析設計上的結構化、物件導向,軟體生命週期的瀑布模型或漩渦式開發,乃至於整體流程的CMMI Agile。然而,我們大多數依然活在經費超支、時程延宕、軟體品質不穩,功能不足的夢靨中。

就筆者觀察,在週遭的工作環境中存在一個有趣的現象,非軟體相關科系的從業人員多過正規教育出身的人。不知其他工程,例如建築、製造、塑化、生技等領域是否也如此。但就自身的感覺,我們這些黑手出身的,在進入到工作崗位上,一開始想的都是如何寫程式幫使用者立刻解決眼前的問題。不會深思所寫出來的東西是否經得起時間錘鍊,我們不會長考成員們如何合作,僅以最會寫程式的人當意見領袖。總要專案陷入困頓後,才抬起頭來找尋出路。

筆者遊走於各大企業,與各產業內的工程師交換著黑手技術的經驗,這些跨國大企業,大金融集團,通訊、製造、醫療等龍頭,它們的事業都是如此的成功,但其內的 IT 狀況卻是差不多的。這種存在既合理的實質現象,總讓筆者迷惑。僅針對企業體內的軟體開發團隊與使用者而言,「能用」的彈性真大。

@小標:敏捷開發與極致軟體製程

就筆者自身的感覺,當下最負盛名,也較適合企業內專案開發的精神是敏捷開發(Agile)[1]

它的發展史如下:20012月,在美國猶他州的一個滑雪場,17位軟體開發方法論的專家,包括Kent BeckMartine Fowler (其方法論為 Extreme Programming)Alistair Cockburn(其方法論為 Crystal Methodologies)Jim Highsmith(其方法論為 Adaptive Software Development)…等等,共同發佈了「敏捷開發宣言The Manifesto for Agile Software Development」。你可以在 http://www.agilemanifesto.org/ 網站上看到宣言的全文,筆者妄加翻譯如下:

l 開發者以及彼此的互動重於流程和工具(Individuals and interactions over processes and tools)

l 做軟體重於細緻文件(Working software over comprehensive documentation)

l 客戶參與開發重於訂約(Customer collaboration over contract negotiation)

l 應變重於墨守成規(Responding to change over following a plan)

在上述敏捷開發宣言下,有著諸多的方法論,其中極致軟體製程 XP(Extreme Programming)最為著名且完整,其核心強調四大價值:溝通(communication),簡單(simplicity),回饋(feedback)和勇氣(courage)。並針對軟體生命週期中的設計、測試、開發、上線等環節提出十多種做法建議(practice)

XP 的特色在於由下而上(value up)快速循環,一般建議以兩週左右為一個單位,迅速做一次設計、測試、開發、達交的動作,而後檢討修正,再開始下一個進度單位。在客戶與使用者的參與下,一次次地修正,直到達目的地為止。

與其他 Agile 精神下的方法論相比,XP較強調測試的重要性,每個開發人員不僅要寫程式碼,同時也必須寫相應的測試案例(test case)程式碼。經由持續的構建和集成(Continuous Build & Integration)。並在一次次的遞迴週期中,完成局部的產品功能。每次週期結束時,搭配重構(Refactoring)的規則,修正不好的程式碼,再通過先前累積的測試案例後,進入下一階段遞迴,以此為下一步的開發提供了較穩定的基礎。

如同 Martin Fowler在其文章“The New Methodology”中強調:「敏捷強調修正,而非預測。重量級方法花費大量的人力物力,試圖制訂詳細計畫來指導長期的工作。而一旦發生變化,計畫就不再適用。因此本質上,重量級方法是抵制變化的。而敏捷方法則強調適應變化。其次,敏捷方法以人為中心,而非以流程為中心。敏捷方法強調順乎本性(work with peoples nature),軟體開發應帶來樂趣。」

在此介紹一本關於 XP 的好書:規劃極致軟體製程(Planning Extreme Programming),此書兩位作者在軟體開發流程的方法論界極富盛名,也就是前面提到的 Agile 宣言發起者 Kent Beck Martin Fowler。在本書中,他們風趣幽默地將理念納於短文中。書雖小,但富含智慧。筆者在此列舉書中一些有趣的觀點:

l 我們將開發軟體比喻為開車,開車並非讓車子朝向一個方向前進並保持它即可,開車必須進行許多微小的路線修正[2]

l 在軟體開發計畫中,業務決定結案日期(dates)、功能範圍(scopes)以及優先順序(priority)。技術人員估算(estimates)[3]

l 顧客必須是開發團隊的一部份,這個角色太重要而不能是局外人,假如顧客無法參與,任何 XP 專案將失敗當顧客水準不夠,就算擁有世界上最佳的才能、技術與程序,仍終將失敗。

l 對顧客而言,XP 最棘手的就是習慣規律的交付(delivery)…顧客必須時時刻刻問自己:下次擁有什麼功能是最有價值的?

l 加班不是一個好主意...即使程式設計人員願意加班,也不是一個好主意。長時間的工作會令人感到疲累,疲累的人容易犯錯,而錯誤需要花更長的時間來找尋與修正。

l 軟體專案的四個變數中:成本(cost)、品質(quality)、時間(time)和規模(scope),時間和規模是較好控制的...必須讓時間成為可見的。

l 假設明天所能做的,將會和今天實際上已完成的一樣多。

l 每日需要簡潔的會議...整個會議過程中,每個人都必須站立著,以提醒簡短發言。

l 每次遞迴完成某項功能後,由顧客操作示範與解說,並由顧客將牆上待完成表內之該項目劃掉。

l 可信賴的業務或顧客,其人格特質需要:經驗(experience)、交際(contacts)、遠見(vision)、勇氣(courage)

l 顧客必須做決策,但不必忠於決策,改變心意是他們的權力,但是決策必須由某個基於企業觀點的人產生。

@小標:自己炒得菜,再難吃,自己也會捧場

最近,筆者碰到一個開發模式局部採用 XP 的案子,開發團隊 5 人,產出的系統有 600 人使用,共花了 5 個月的時間完成。

開發期間,主事者以一週為單位,當作循環週期。經歷了初期的練習後,小組團隊較能切割一個星期能達交的工作內容。由於達交時間短,讓開發者不能鬆懈。因為即便兩次都展示同樣的半成品,也總得交代時間花在什麼地方J

在開發初期,一個星期的遞迴時間在遇到比較難的技術問題時,可能根本看不到成果,主事者因此取消過一、兩次的專案會議,可是團隊就鬆懈下來了。這也驗證了本書兩位作者強調遞迴時間固定的重要性。

另外,由於一個星期內,大家專注開發同一功能,因此開發團隊的成員可以彈性調度支援。不會有兩三個月,大家各自開發專屬功能的模組,而其後將無法互相支援的窘境。

過程中,使用者每個星期都參與成果測試,並分析下一個遞迴的需求。等於使用者本身就是分析、測試人員,由這樣的會議交談,讓整個團隊對領域知識了解更深刻。也由於參與度足夠,且因為開發時間短,所以需要相對修正的內容也會比較少。又因為有多少就給使用者測多少,可以在早期發現錯誤,就算全部推翻重寫,也不過推翻了一、兩星期的時間。這次的嘗試雖比預估時間晚了一個月才完成系統,但最令人興奮的是,上線後少有人抱怨。

主事者目前覺得有問題的是時程掌控不易,這不是開發者的問題,而是一直在修正。因為如果有完美主義者參與,他們老覺得這裡要加一點那裡要加一點L

@小標:閱讀建議

本書輕薄短小,很有敏捷風J,章節很多(27 ),文字很少。讀來輕快有成就感。所以,建議你就一口氣讀完吧。

@小標:相關閱讀

原典與精神總是值得參詳的,Kent Martin 各有巨著,本書的作者簡介有表列。另外,建議你到以下的網址逛逛:

l http://www.agilemanifesto.org/

l http://www.agilealliance.com/

本書未談論搭配軟體開發實做的產品,筆者就微軟 Visual Studio Team System 在此方面的相關資源稍做建議:

l Software Engineering with Microsoft Visual Studio Team System 出版社 Addison Wesley 作者 Sam Guckenheimer。這依然是一本解釋 Visual Studio Team System 所為何來的書,因為作者在 Team System 團隊中就代表使用者。書中並沒有如何操作的步驟,但可讓你了解為何 Team System 要實做這些功能。

MSDNhttp://msdn.microsoft.com/vstudio/teamsystem/。當然,微軟技術的大本營不可不去J


[1] 就個人感覺,針對系統整合、軟體外包,以及百人開發的大型軟體產品等領域,Agile 尚需給我們更明確的指引。

[2] 將軟體開發比喻成開車是 XP 很傳神的論述,但就筆者與開發團隊討論到此點時,會覺得這似乎隱含了軟體規模,若軟體專案規模如汽車,則轉向容易,大家可以約略知道目的地後,就一路修正駛往目的地之方向。但若規模大到如火車,則似乎需先定好各站的進程規劃,一發車後,就很難調整,因為笨重的身軀若隨意轉向,可能傷害就大了。

[3] 就筆者參與專案的經驗,作者所列由業務或企劃所決定的三件事,在軟體開發中爭執已久,不過由 XP 開宗明義的客戶導向,一切就顯得理所當然。否則,若由技術人員決定日期、範圍、和順序,整個軟體開發就變成製造導向了。

擅用內容者王,有資料而不會用,等於沒有資料

在上一個網際網路飆升的年代,1995 年前後,Content is King喊得震天嘎響。當此之時,獲得與累積資料、產生資訊與整理成知識並不容易,企業間比較的是有沒有建置一些標竿系統,以量取勝。

10 年後的今天,網際網路熱再臨,大型系統遍布,資料充斥,要深入分析與善用資料,如 GoogleAmazonWal-Mart 等,才能稱王。

@小標:由量轉質

時至今日,技術、方法與商業模式都營造了大量累積的資料,鉅量的資訊讓人們的注意力變成稀有資源。各中大型企業不再缺乏什麼系統,例如 ERPCRMSCMEIP…都已經建置完成,而今需要整合各系統以發揮綜效,讓有意義的資訊與知識適時且直觀地呈現。這令資料倉儲(Data Warehouse)、商業智慧(Business Intelligence)變成流行的名詞[1]。但在台灣若要說清楚意涵與架構方法,卻又因為缺乏深入淺出的中文書籍而難有普遍共識。

資料倉儲系統其背後代表著多項的技術整合,就筆者的經驗,其技術困難點如下:

l 擷取資料:正確地整合各種資料來源,例如 ERP Oracle、網站與製造資料放在 MS SQL Server、各地分公司以 .csv 格式傳遞相關資料進總公司等等,這些資料都要彙整到資料倉儲中,以提供廣泛的分析基礎。而資料轉換需要經過挑選、清洗、彙總、豐富等過程,並符合彈性、安全、自動化、高效率等基本需求。

l 儲存資料:就資料應用面的不同,切割大量資料的存放,規劃出操作型資料商店、資料超市與資料倉儲等應用。求取資料超市/資料倉儲與交易資料庫的平衡,畢竟前者以星狀模型為設計基礎,而後者強調三階正規化。務求正確、有效地處理超大量資料。

l 分析資料:筆者粗略地將使用者的分析需求分成四類:臨時性的查詢(ad-hoc query)、靜態報表,多維度線上分析、資料採礦預測等。由於我們一般 IT 人員對於生產良率、客戶需求、公司營運等分析的敏感度不夠,又對多維度分析語言、資料採礦等技術不熟,要掌握分析重點,滿足以上四類需求確實不易。

l 呈現分析結果:呈現結果的方式也非一致格式,例如一般使用者日常所需的生產、營運分析、異常警示等靜態報表。給分析師與經理使用的動態分析和預測。搭配企業管理理論,如平衡計分卡、6個標準差等,給高階管理人員檢視的儀表板。由於對各種人對電腦操作的熟悉度不同,對資訊呈現的要求迥異,很難用一套技術滿足所有需求。

l 教育訓練、維護與安全:資料倉儲與 BI 系統的觀念新、牽涉面廣、使用人數多,資料博雜。在推廣、建置與維護上,需要謹慎考慮。

最後,整體系統設計與實做,還會因日漸高漲的及時性需求(也就是來源的交易資料有修改,在分析報表中可以立刻看到變化),而增加成本與困難度。

在此介紹一本不錯的入門書,李卓翰博士所著:資料倉儲理論與實務,學貫行銷出版。此書僅介紹資料倉儲系統的建置觀念,對於整個系統的組成元素,例如:資料轉換(Extract Transform Load)、資料庫定位(操作型資料商店(Operational Data Store)、資料超市(Data Mart)與資料倉儲)、多維線上分析(Multi Dimension Online Analysis Process)、資料採礦(Data Mining)等提供清楚的定義說明。

全書並未輔之以軟硬體產品介紹,純粹的概念剖析,讓人容易理解整個商業智慧系統架構的環節。在建置龐大的資料倉儲流程時,腦海中先有完整的架構圖。

可惜本書中未以專章探討前端呈現分析結果之應用程式特徵,就筆者所接觸的分析系統建置,這是很讓人頭大的一環。分析的結果要直觀清楚,還要讓使用者容易深入、聯想、整合與引用分析結果。這種介面往往對 IT 技術人員而言,是另一個領域的藝術

另一方面,使用者又往往要求分析報表的呈現須依循老系統的樣式。但新技術的特點與舊系統大不相同,勉強為之,不但發揮不出新平台的優點,還讓開發者用牛刀殺雞,滿頭大汗地呈現支離破碎的結果。

@小標:企業文化與商業智慧導入

任何資訊系統的成功,產品與技術雖很重要,但真正關鍵因素卻在成員素質與企業文化。資料倉儲系統不若交易系統可以明顯地看到投資報酬率,因此更需要上位者眼光宏觀,並能夠察納雅言,不停地吸收新知。而中階經理人要能務實地訂定階段、步驟與方法,確實執行。

同時,分析系統的團隊成員須加入對領域知識(Domain Know-how)熟悉之人才,而不是找當下沒事做的人。部分公司對分析系統的態度還是以有比較好(nice to have)”的心態在建置,因此加入的人往往不是該領域知識的菁英,而是較空閑的人。

分析的需求往往是由上而下,且需要橫向的資料整合才能建立廣泛而深入的系統。團隊成員要有高階經理人加入,整合往往引發政治與資源的角力,因此更需要上位者的遠見與支持。

本書在第 1-4 常見對資料倉儲系統的誤解,以及第十三章常碰到的非技術性問題,表列了資料倉儲系統失敗的潛在因素,或許在你規劃系統時,可以先考慮此類企業政治與文化的因素,而非單純的技術問題。

就企業文化而言,若重視產品定位、市場行銷,以服務客戶為宗旨,時時改善現況,強調研發創新,要求決策品質。則人人在精益求精的過程中,將會發現手邊可供參考的資訊不足,因而企盼正確有效的知識隨手可得。隨著資訊化的普及與精進,整合與分析的需求將會越來越殷切。

@小標:資料倉儲建置是持續的流程

一般建置資訊系統時,其模式固定,目標明確,技術單一,大家較有經驗規劃軟體生命週期的進度。而資料倉儲的建置並非如此,參照前文所列的困難,如匯整資料的來源多樣,累績、運算的需求各異,資料量大而駁雜,呈現分析的方式需直觀方便,整體系統還需時時依照營運重點更改分析模型

為了提供妥適的分析以因應公司營運的各種需求,資料倉儲系統需具備動態增減資料來源、分析模式、呈現方式的能力,因而在資料倉儲系統雛型建立完畢後,後續上線維護時,依然會需要技術人員參與投入。

普遍而言,我們各產業的 IT 部門對於資料倉儲尚處在摸索階段。因此,公司需要願意引入新觀念、技術與產品,投資教育訓練,培養人才,始能夠讓分析系統落地生根,開花結果。

@小標:閱讀建議

本書些許目錄與頁眉章節名稱的編排有誤,第十四章的資料倉儲建置實例稍嫌簡化,怕會誤導讀者考慮不周。但瑕不掩瑜,就想要了解何謂資料倉儲與商業智慧的管理階層和 IT 技術人員而言,仍是一本不錯的入門書。書中的概念介紹可以讓你在選擇技術,購買產品時有所依循,且在系統分析設計時,有重點輪廓。

在閱讀本書時,除了照作者所擬定的章節順序外,以及先熟悉第一章的概論外,依筆者個人的經驗,若想瞭解資料倉儲系統主要組成元素,或按軟體產品分類,可先閱讀第二章的資料倉儲、第七章的資料轉換、第九章的線上分析、第十一章的資料採礦與第十二章的工具。作者未專章強調的前端使用者介面,但它們依然是需要實體採購建置的,或許你可以比較參照市面上的相關產品,以補充書中的不足。

而第三章的技術團隊、第四章的專案步驟、第五章的需求分析是一般專案開發與管理的範疇,你還需要佐以軟體工程的進一步理論。而第六章的資料模式、第八章的中繼資料與第十三章的非技術問題則是商業智慧系統較其他系統需要深思的部份。

@小標:相關閱讀

本書在附錄 E 與附錄 F 已詳列了衍生閱讀與研究的相關圖書和網站。由於本書未談論實做的產品技術,筆者就微軟 SQL Server 2005 在此方面的相關資源稍做介紹:

l SQL Server 2005 資料採礦聖經 尹相志著 學貫行銷出版。尹顧問有多年資料倉儲與資料採礦的經驗,也是在台灣最先導入 SQL Server 2005 資料倉儲的人。在本書中,有詳細解釋 SQL Server 2005 所提供的資料採礦模型之原理與使用方式。

l MSDN Forum( http://forums.microsoft.com/MSDN/default.aspx?ForumGroupID=19&SiteID=1)此討論區內分門別類地提供 SQL Server 各項問題的解答或許你疑問可以透過關鍵字在此找到答案。

l DB World 網站(http://www.dbworld.com.tw)在該網站上有許多關於 SQL Server 2005 資料庫管理、開發以及資料轉換工具 SSIS 的文章。

@小標:結論

商業智慧系統的最終目標是整合全公司、上下游供應鏈,乃至於各種市場分析的資料,讓每個人各取所需,不同層級的員工在做決策時,參考不同面向的資料。但不管是經費或效益評估,皆不可能一開始就以全面整合為目標,因此架構工程師需要能看到主架構的遠景,訂立系統進程,分階段引入不同的團隊、資料、產品與技術。主事者在不同階段都能夠提供具說服力的投資報酬率,分析系統才得以成長茁壯。


[1] 商業智慧涵蓋的面向較資料倉儲為大,畢竟公司營運所依憑的,不僅是格式化存放的資料。但筆者在本文所介紹的書籍著重在資料倉儲,因此文中皆以資料倉儲泛指大量資料為基礎的分析系統。

在資訊與網路的美麗新世界裡,起飛的動力與方向為何?

身處坐三望四的年紀,身旁不少朋友躊躇滿志地準備創業,或辛苦經營著自創的資訊事業,或竭誠殫慮輔佐公司。常聽他們高談闊論地談公司遠景,產品定位與行銷,供應鏈的合縱連橫。閱讀此篇文章的你,是否也是其中一員呢?

@小標:以史為鏡,可以知興替

在此推薦一本好書,或許可作為資訊公司策略制定者,或產品市場定位者的參考。這本書主要以十幾年前的商場征戰為實例討論。因此,若你的年齡與筆者相仿,相信對大多爭霸的結果早已了然於胸,如 Word WordPerfectIE NetscapeMac Wintel、高畫質電視在當時仍處鹿死誰手,至今多已塵埃落定。閱讀此書時,比照理論推演,更饒富趣味。

除資訊軟硬體產業以外,作者更舉出許多追溯自工業革命以來的商業運作模式,如電力系統、電話系統、電視系統、信用卡業務乃至於鐵路、航空的營運。讓我看到以歸納和演繹做學問的廣度與深度。

IBMIntelMicrosoftAdobe 等巨擘在不同領域裡掀起了一場場影響深遠的戰役,其本身也都獲得了重大的利益。相反地,曾叱吒風雲的 DigitalAshton-TateWordPerfectLotusNetscape…等,隨著商機流失而走入歷史。多少紅透半邊天的產品,如 Alpha 微處理器,dBaseWordPerfectLotus 1-2-3Netscape Navigator 瀏覽器等也煙消雲散。隨著歷史軌跡,作者讓我們看到了成王敗寇的法則。

這是一本規模較大,戰略性研究的書,對智慧財產權、反托拉斯法、產業標準等多所著墨。或許大部分的讀者都沒有機會參與標準制定,也無法左右市場,但由廣泛現象歸納的結論,可以提供你我在處理日常事務的眼界。

@小標:本立而道生

以往總覺得經濟學是門高不可攀的科學,是社會科學的基礎學門,如同數學、物理之於自然科學。先入為主的觀念,讓自己以為讀經濟學的相關書籍,最好是在失眠時,藉此可以輔助入睡。但此書卻讓我興味盎然,有點像商場征戰史,輔之以脈絡大解讀。

本書的兩位作者都是名校的經濟學教授,其中一位並在美國反托拉斯部門服務過。他們以淺顯易懂的實例,穿插簡潔的圖表[1]說明。且明確地為書籍定位:我們的原則是談模型不談趨勢,談觀念不談字彙,談分析不談比喻。我們堅信如此才能讓讀者徹底了解,今天高科技產業發展的基本原理,在未來的網路經濟中立於不敗之地。

有能力化繁為簡,以理論駕馭實務,綜觀全局後,提綱挈領地引導大家循序漸進,達此境界的領導者,總讓人心嚮往之。然研習基礎理論是達到上述法門之一,我相信有天縱英明,對產業直覺敏銳的領導者。但平凡我輩,還是選擇苦學苦思後的圓融吧。

此書提供從源頭的思考,它不是教戰守則,沒有解題步驟。你需要咀嚼其論述後,再推及身處的情境,相信能提供你透視問題的能力。

@小標:資訊產業的特徵

身為顧問,在對業主的資訊政策提供建議時,筆者往往簡單地做出選擇。因為就直覺上,選擇市佔率較大的軟硬體,可能也表示著整體擁有成本較低。當然,我還是會附上一堆模擬兩可的技術評估,畢竟技術趨勢本身很難說得準L。然而在閱讀完本書所解釋的種種概念,例如:產品與價格的差異化、需求面的經濟規模、網路效應、集體轉換成本、正反饋現象等理論後,感到有些釋懷。當然,再做建議時,我也應該多考慮書中所解釋的套牢與解套、技術的革新與相容、廠商和標準的合作與相容等議題J

本書將很多存在於資訊從業人員心中的模糊意念具體化,由於條列分明,讓我們能討論、比較,但願能進而化約成目標、行動。以下列舉書中一些有趣的觀點:

l 資訊的豐裕造成注意力的貧乏。今天最大的問題已不是資訊的取得,而是資訊超載。資訊提供者最重要的貢獻是為消費者找尋、篩選與解讀資訊,這也是為什麼網路上最熱門的網站是搜尋引擎 引導使用者找到自己所要的資訊。

l 資訊產品的製造有兩種成本:高昂的固定成本與低廉的變動成本。第一個產品的生產成本很高,從第二個開始(即再製成本)就微不足道了根據成本來定價不可行。再製成本趨近於零時,加上一、二成來定價根本沒有意義,而應該以消費者的價值為定價基礎。一項產品對每個人的價值都不一樣,差別定價便是很合理的策略。

l 如果能依據消費者最高購買意願訂定不同價格,豈不是最理想?善用網際網路,發揮一對一行銷將差別定價分成:

n 個人化定價:對每個消費者採用不同的定價。

n 分版:提供豐富產品線,讓消費者選擇最適合自己的版本。

n 團體定價:依據每個消費族群制定不同價格,如學生折扣價。

l 先設計高階產品,然後將產品功能降低。這有兩個優點,第一:較能應付未來可能出現的競爭對手。第二:你可以利用低階產品為高階產品打廣告。

l 促銷活動必須能區隔市場才能發揮作用。

l 套牢就是使用者必須付出相當的成本,才能完成品牌或技術的轉換。在資訊體系裡這個問題幾乎無可避免,成本的控制對買方與賣方同樣是一大挑戰任何人只要針對特定對象做投資,在整個投資過程中都會面臨套牢的問題。不管這個對象是供應商、消費者或合夥人,一旦發生變節或倒閉,你就會蒙受損失。

l 耐久設備的轉換成本會隨時間遞減,原因是設備會折舊或著優良的新機種會出現。特定軟體品牌的訓練則恰好相反,如果你的訓練是專屬某種品牌的,轉換成本係與時俱增。

l 亞當斯密(Adam Smith)曾經說過:競爭壓力會促使生產者做出最有利大眾的決策。

l 在網路市場中如何設計一個可以影響消費者預期的策略很重要,當需求面的規模經濟正在強力運作時,大勢所趨的氣氛就是強有力的武器消費者擔心買到不普及的產品,將剩下一堆無用的設備因此,資訊科技剛開始總是慢慢加速,集聚一定的能量後開始起飛,或從此一蹶不振。

l 在網路市場裡有三個標準可以測量你的實力:目前在市場上的地位,技術能力,智財權的掌控程度。

l 企業在推出新產品時,有以下的問題:

n 選擇性能或相容性:犧牲性能以成全相容性稱為進化,反之,犧牲相容性以突顯優越性能稱為革命。

n 選擇開放或控制:開放的技術較容易普及,但不保證獲利豐厚。你必須具備創新能力,又能掌控技術的使用與設計,才是最大贏家。

l 追求最大的利益不等於追求最大的控制權,重點是你能爭取多大的一塊餅。你的利益=業界增加的總價值 * 你所分得的比例

l 標準的制定會使競爭的重心由產品移到價格,原因很簡單:每一種品牌的同質性很高。周密的標準雖可降低不相容卻也可能使產品難以發揮特色,而被迫走向價格競爭消費者較能免於被套牢的威脅。對廠商而言,最好是否此產品有些不相容,各自分割一小塊市場,大家著力於產品特色,而不必削價競爭。

以上是針對書中前八章的內容,筆者節錄私自認為的重點,有斷章取義之嫌,在此要先對你說聲抱歉。另外,本書的最後兩章談及標準戰爭資訊政策,其內容偏向產業的整合與國家政策,雖有很高的可看性,但比較不是普羅大眾能觸及與決斷的,因此沒有在此談論。

@小標:閱讀建議

本書的理論解釋有其連貫性,你需要先閱讀前幾章的基本定義,才能了解其後章節。且往往前後兩章間有接續關係,因此,照順序翻閱,較易於理解。而有些章節描述的玩家規模過大,例如制定標準,打標準戰爭等,雖親身參與的門檻高,我輩終身可能都碰不到,但仍可以欣賞兩軍對戰的藝術J

本書的章節不多,或許你可以先看一下目錄,了解書籍的大概架構。作者在章節的本文中,多以實例來解釋理論。章節的撰寫大都依循著破題,實例解釋,分類歸納等順序鋪陳,並於章末都會給一個啟示,是該章的重點結論。

@小標:相關閱讀

除了透過本書宏觀地解析天下大勢外,企業內的運作也是大學問。筆者對企管涉獵甚少,但仍想野人獻曝地提供自己所讀過,可延伸相關閱讀趣味的書籍:

l 注意力經濟戴文波特(Thomas HDavenport)、貝克(John CBeck)著陳琇玲 譯 天下文化出版。這本書在上市之初也引發轟動,值得你研讀。或許在「資訊經營法則」的討論裡,可以誘導你深思對外的戰略,則「注意力經濟」可以激發對企業內乃至於個人的管理與文化之長考。



[1] 就筆者的感覺,第七章好些圖的標示似乎有錯,不曉得是否是在翻譯時出了些問題。可惜不知道原稿是如何繪製的 L

提升軟體品質的必經之路

軟體是多個長期構思,協同作業下的成果,不可能不出錯。若沒有配置相當的人力物力資源,分階段把關測試,將隨著系統規模漸大而逐漸失去控制的能力。

@小標:被疏忽的一環

筆者在赴製造業授課時,看到偌大的辦公大樓內,整個樓層的品保(QA)專業人員,使用華麗的軟硬體,針對製造流程上的瑕疵缺點做各種的良率分析,但該企業的 MIS 開發卻沒有測試人員的配置。換句話說,為支援品保所成立的軟體團隊,在開發軟體時,本身沒有品保的支援。

投資出錢的企業老闆們往往不清楚軟體開發的困難與複雜,一般大眾也充滿著對軟體工業的誤解。如筆者任職顧問的報業集團,其建立了首屈一指的編審制度,企業內全盛時期,有八到十位軟體工程師花費近兩年的時間,開發給上千位編輯使用的系統環境,為得就是對上千位記者所撰寫的文字內容嚴格把關。

但沒有軟體專業人員為系統開發把關,讓筆者斗膽做個對照,若程式設計師撰寫程式碼如同記者撰寫文稿,則我們沒有測試工程師如同編輯來編審與校稿,也就是沒有 code review與測試。軟體開發團隊也缺乏如編輯們對整份報紙的版面編排與改稿,也就是沒有軟體的重構(refactoring)。甚至對程式碼的錯誤追蹤和版本控管都還不如編輯們對文稿修改所提追蹤功能之要求。

換句話說,每個產業都有其專業,卓越企業的管理階層對該公司之品管一定都有嚴格的標準,如本書第九章所描述的全面品質管制(TQM Total Quality Management)。但對支援品管的資訊系統本身之品管卻由於無知而導致漠視。

既然全面品質管制是大大小小的計畫(Plan)、執行(Do)、檢查(Check)、處理(Act)” PDCA 循環流程,沒道理提升公司競爭力的資訊系統沒有檢查。而純由腦力合作建構的資訊系統又沒有容易施行與監督的標準步驟(SOP),則更應該強化軟體測試,以提升品質。

軟體測試在國內往往是被忽略的一環,光從筆者對書籍中專有名詞的翻譯感到陌生可作為一個指標[1],因為專有名詞的翻譯是約定俗成的,若大家朗朗上口,且對定義清楚明瞭,代表該技術在此已經落地生根行之有年。反之,則代表大家還在啟蒙階段,雖然美國早在上個世紀 70 年代就已經建構理論,近年更提出開發與測試人員的比例最少 3 1 的要求(本書中描述微軟的開發與測試人員視專案的不同,比例是 1 1.5 1 3,也就是一個程式撰寫人員配置三個測試人員)

而我曾經和國內一家軟體開發商的美籍品管工程師聊天,他說他在美國曾待過四家公司,不管規模如何,沒有一家公司沒有專業的品保人員。但他在台灣沒看過具專業品保流程與品保工程師的軟體公司或 MIS 部門。

@小標:建構體系

軟體生命週期中,大分有分析、設計、開發、測試、上線、維護,若越晚發現問題,修正錯誤所付出的代價越大。任何階段的工作與產出皆有可能出錯,因此如以測試驅動開發(Test-Driven Development TDD)方法論所提倡的,在分析的初始,應該就同時撰寫測試案例(Test Case),亦及以測試來驗證對需求的了解程度,並規範接下去的設計與開發不至於偏離。

也就是在分析時期,要撰寫如何測試是否符合使用者需求的文件,在設計時期,要提出模組與架構間整合測試的方式,以確認架構與介面定義的正確性。而在開發時期,同時撰寫單元測試,以驗證個別程式碼的正確性。同時,說明文件的正確性也要一並測試。讓 V&V(Verification and Validation)的精神貫穿整個開發過程,時時驗證(Verification)是在做使用者需要的產品,並確認(Validation)把事情做對。

軟體測試理論從 1970 年代建構至今,已經自成體系。隨著 ISOCMMIAgile 的盛行,不管是 CMMI Support process areas,或是 Agile TDDPair Programming,都規範了軟體品質的基本要求,確保品質的構成要素,以及實踐的方向。或許,這是當今軟體專案管理人員不可或缺的常識。

瀏覽書中所架構的測試定位與流程讓自己一身冷汗,忝為教人做軟體的講師或顧問,自認稍有涉獵軟工中的測試環節,但從未在心中建立出一套完整的測試架構。或許是疏於找尋,滿足於浮面的知識,以往總以人力資源不足,專案時間短促等理由自欺欺人,而讓測試流於形式。

當我們永遠陷在資源不足的窘境中時,如何拿捏資源分配應是首要問題。而不是把不熟的領域直接割捨。若心中沒有整個測試的輪廓,如何能夠取捨該做多少?

@小標:軟體測試之定位

書中提出對軟體測試定位的認知,或許值得你參考:

l 提高軟體測試的效率和產出依靠功力,好的測試人員不僅要掌握各種測試技術,還要具備豐富的程式編寫和對 bug 的敏感度。

l 經驗對軟體測試至關重要,有無經驗的測試人員實有天壤之別。軟體測試有複雜專業的技術,且需要測試專案本身的專案管理。

l 軟體測試有規範與理論,不是隨心所欲愛做多少做多少,需要分配時間、人力、財力。

l 開發與測試是相輔相成的過程,開發與測試兩個團隊間的交流、協助是提高整體效率的重要因素。

l 軟體生命週期中的測試階段表明該階段的主要工作是測試,但不是說測試工作只發生在該階段。通常測試階段的主要任務是執行測試與撰寫報告,但準備工作如測試計劃,案例(test case)以及測試程式的編寫要在更早階段完成。開發過程中交互執行著單元測試(unit test),若干單元或全部集結後的測試,在日漸高漲的軟工理論 TDD 中,要求週期性的甚至到每天編譯(build)後執行測試計劃,第二天看分析報表。

l 軟體測試是一種有效提高軟體品質的手段,但不能百分之百地發現所有品質的隱憂。

@小標:工欲善其事,必先利其器

由於應用程式的開發方式繁多,如採用 C++Visual BasicJavaDelphi.NETD2K…等,存取介面也大不相同,如批次作業、WebWindows Form。而我們的測試目的,除了上述開發流程中的配套作業外,尚有安全、壓力等測試。廣義而言,你還需要測試使用者的專業能力(或許使用者的無知,是系統損毀、安全疑慮的最大來源),系統災難復原的能力、隨著軟硬體迭代更新的相容性等等。因此,測試工程師需要選擇適合的軟體工具,建構獨立的測試環境,並有程式寫作、整合軟硬體平台,協調開發人員的能力,同時在人格特質上喜歡找問題,挑毛病。這其實與軟體開發工程師喜歡堆積木,無中生有創造系統的特質不同。

當我們定出軟體測試的流程後,若沒有強悍、整合、易上手且自動化的工具程式,則推廣的結果可能是流於空談,畢竟測試是一再重複而枯燥的流程。

本書中除了對 ISOCMMTQM 等規範與軟體測試之關係,各種開發階段所應進行的測試工作,不同類型的測試之定位有明確解說外,於後半冊廣泛介紹了在軟體測試領域著名的廠家,也詳列了著名的軟體測試工具,並分門別類地介紹工具之使用。擷取操作的螢幕畫面,以逐步介紹的方式解說。

@小標:閱讀建議

這本書有點流於教科書的繁雜,且部份細部章節的編排上稍嫌紊亂。書中有些過於理論的說明,需要讀者耐得住性子[2]。且受限於專案經費、時程與人力,若要將書中的建議全部落實於我們日常的團隊合作,似乎仍有一段落差。

建議你先廣泛地瀏覽一下書籍內所談到的內容,如操做測試的黑箱/白箱進行方式,配合開發流程而對應的測試流程,如單元、整合、確認、系統、平行驗收等測試。有了概念後,在軟體開發的過程中,再擇要精讀。

由於導入測試的效益要明顯呈現,恐怕是在兩三個案子之後,這種先期需要投資,但下兩三個案子才見效益的規劃,對專案經理而言,可能更需要謹慎拿捏資源配置的比例。

@小標:相關閱讀

對於國內廣大的微軟產品愛用者而言,這本書有點可惜的是於此主題著墨不多。若你需要從事 Microsoft .NET 開發相關的測試,可以參考以下的書籍:

l Test-Driven Development in Microsoft.NET,作者為 James W. NewkirkAlexei A. Vorontsov。出版社 Microsoft此書有介紹 TDD 的概念,以及免費軟體工具 NUnit 搭配 C#/.NET Framework 開發與測試的使用方式。

l Working with Microsoft Visual Studio 2005 Team System,作者為 Richard Hundhausen。出版社 Microsoft此書是本入門書,介紹 VSTS 的架構,與實做軟體生命週期管理之方式。並對於 VSTS 所提供的測試管理:Test ManagerTest ViewTest ProjectTest Results,以及測試類型 Unit TestCode CoverageProfilingManual TestWeb TestLoad Test 稍有介紹。

若要強化軟體品質,重構是可考慮的過程,而重構更與測試密不可分。你可參考與重構相關的書籍:

l 重構改善既有程式的設計(Refactoring : Improving The Design of Existing Code),作者為 Martin Fowler,譯者 侯捷/熊節,碁峰出版。

除了書籍外,以下這個網站也蠻有趣的,值得去逛逛:周思博趣談軟體(http://chinesetrad.joelonsoftware.com/index.html)


[1] 或許還有一個原因是:我猜這本書是從簡體翻譯成繁體的,所以有些地方的用語不同。但對於專業用語繁體版的編輯翻譯不一致,仍代表大家對這個領域的不熟悉。偶而看到一本討論測試的中文書,但卻是從簡體版翻譯過來,深覺資訊的基礎功夫對岸比較紮實。要枝繁葉茂需要先根深蒂固,而從圖書的廣度與深度可以略窺一二。

[2]就筆者的感覺,習於實做的人要的是 step by step 之說明即可,而管理人員則只看定位與效益,這本書兩者都談,會讓人很難看完J

從誠懇出發,邁向自我實現

如果完滿的人生是我們要建構的系統,則李開復博士的這本書嘗試提供分析與設計。在書中,作者提供了如何讓自己更好的方法論,旁徵博引地闡述中心思想的實質意義。他畫出了以價值觀為中心,自省、胸懷、同理心、自信、勇氣、積極位於內圈,是人生態度。有效執行、合作溝通、人際交流、發現興趣、追尋理想、努力學習為外圈,是實踐行為。以此構成成功同心圓。在書中逐章以工作生活上的實例剖析其意義,充滿了溫馨的小故事,時而幽默,時而勵志,實因李開復博士學貫中西,閱歷廣博。而己立立人,己達達人的熱誠洋溢全書。

本書作者的學經歷傲人,如台灣出生、美國成長、大陸開創,擁有卡內基美隆(Carnegie Mellon)大學資訊博士學位、先後任職於蘋果電腦、SGI、微軟、Google 等公司的副總裁,獲得美國電子電氣工程師協會(Institute of Electrical and Electronics Engineers IEEE)院士頭銜等等,由他來闡述成功的定義,組成要素與成就的過程,對資訊從業人員來說再適合不過了。書中有激發人心的話語,又有切實履行的步驟,實是立志類的好書。

現今是一個高度專業團隊合作的世界,在筆者的經驗中,若將英雄與團隊抽離,大概都無法成就他的事業。而這些成功的團隊肇因於優秀的成員。而每一位成員都要如作者所言:「成功的人士不僅僅靠知識、創意等外在素質他們成功的關鍵在於,他們具備了某些最為根本的、最有價值的素質或品格」。

本書從核心價值起始,探討安身立命的基本價值:「誠信」,於個人、企業、社會的時代意義。列舉惠普、微軟、Google、奇異、eBay 等成功企業,其企業體、領導者乃至於客戶間以誠信為本的價值觀,而歸結恩龍、巴林銀行等大企業失敗的原因,乃是喪失誠信之結果。

近日台灣大眾媒體所播放的訊息,皆是與弊案有關,不管是個人、團隊與政黨,都充斥著損人利己的思想,本書可說是暮鼓晨鐘。當對自己良心喪失誠信,與人相處只知個人利害,結黨只為營私,上下交相賊,沒有好的文化與本質,在贏得了世界後,下一步是什麼?除了贏的那一刻有些許快樂外,其他的時間內心可有一絲自由。

我常在想,喪失了核心價值、理想與讓自己更好的動力後,華服,珠寶與枷鎖有什麼差別?當尊榮與地位要靠飾物來妝點,穿戴身外之物以填充優越感,從而建立自信以見人。但這同時構築出與他人的距離,價值越高距離越遠,人際間的真誠越少,利害就越多。當不敢以樸實見人時,總要帶上面具,向物質大神乞求力量後,演一齣酒酣耳熱虛情假意的交心戲。再也脫不去的物質是否等同心靈的枷鎖?受桎梏的心能翱翔嗎?

作者在書中開宗明義地定義誠信實為邁向成功的核心價值觀,呼應<<大學>>所強調的意誠、心正、身修、家齊、國治、天下平的層次步驟。筆者也一直以為誠實是通往成功的必經之路,謊言蒙蔽了智慧,掩蓋了恆久,陷所有的事於表象,扼殺了自省和勇氣,此為平凡與不凡的起點。

沒有能力替自己定義價值觀是可悲的,隨便撿個世俗的價值觀就奉行不逾,如何能夠讓今日的自己比昨日更好。不知道如何跟昨日的自己比,撿些雞毛蒜皮的尺度跟陌生人比,整日以物喜,以己悲,靠擁有尋求自己的存在。

若成功是根植於自我實現,則成功是多元的,這會具體呈現在社會活力上。反之,若社會有公訂的成功,貴賤的尺度一致,則身而為人卻放棄了思考、反省的天賦,放棄了自由意志與選擇的權利,其一生與扛著食物的螻蟻何異?

以往,總覺得修身困難重重,雖不致遙不可及,但老在三天捕魚兩天曬網中度日。例如雖知道革除慾望就富有了,戰勝自己就成功了,乃至於簡單的減肥健身,都因為不知如何做才能持之以恆而成效有限。在本書中,除了以心性為出發點外,列出了要朝什麼目標前進,以及如何做的步驟。作者育教於週遭工作環境中的實例,讓本書的內容更為鮮活與實用,是一本立德、立功的好參考書。

這本書有清楚的結構與指引,適時地以圖示解釋概念,並透過眾多口訣提供心法。每章開頭都明確標示該章在構築成功同心圓的哪一個模組,並在章節結尾提供簡約的要義。若你的時間充裕,建議你詳讀每一章,透過同心圓架構圖分析自己的長短處,參詳李開復博士的建議,加強與去除優缺點。若你的時間有限,也建議先詳讀第一與最後一章,並理解每章結尾的要義,讓心中有一份參考地圖。當有時間反省自思時,可以進一步深探。

除了精闢的架構分析外,另一個讓我感受良多的是,作者書中十足展現對中國的熱愛,以及文人的儒雅風範。本書從<<大學>>的誠意、正心為起點,終於<<中庸>>的圓融智慧。其間穿插著中外的典籍與案例,話語間流露出對中國學生的諄諄告誡,充滿著期許與熱誠,撐起了整本書的張力。若你一時還無法擁有這本書,或許可以先到作者的開復學生網(www.kaifulee.com)瀏覽一下。

自我成長的個人大系統需要我們小心謹慎地分析、設計、開發、除錯、測試與維護。是否是套成功的系統,端看對自己所開的需求。

資訊專案管理的迷思

這大概是近年來所看過最好的一本討論軟體專案管理書籍,32 年前的經驗至今竟然歷久彌新,在變動不止的軟體科技上,果然有可抽象、萃取的智慧。

首先節錄一段本書的開場白:「史前時期最駭人的景象,莫過於一群巨獸在焦油坑裡做垂死前的掙扎。不妨閉上眼睛想像一下,你看到了一群恐龍、長毛象、劍齒虎正在奮力掙脫焦油的束縛,但越掙扎,焦油就纏得越緊,就算牠再強壯,再厲害,最後,都難逃滅頂的命運。過去十年間,大型系統的軟體開發工作就像是掉進了焦油坑裡」。從事資訊工作的你我是否也踩進了焦油坑呢?

@小標:前車之鑑

IT 專案管理一直是個讓人頭大的事情,因為至今它仍不成熟,仍在手工業階段蹣跚走向工業化。雖 CMMIAgileRUP等理論與架構盛行,PMP課程充斥,但資訊專案失敗,不滿意的比率仍大過成功與滿意的比率。

就筆者所接觸的專案,不管是以顧問身份參與,或是作為系統開發的一員,其成本大至數億,小則自己一個人獨立完成。不管領域、規模與人數,專案進行其間,團隊瀰漫的不滿與挫折情緒,往往多過本書作者描繪軟體開發所帶來的創作、成長、玩魔法之樂趣,絕大部分是在第一章所言的苦難中渡過L

早在 1974 Brooks博士把他帶領建置IBM System/360OS/360的經驗集結成書,撰寫了這本人月神話。至今,它的內容依然讓我受益良多。自己在IT領域裡,學習、實作了將近20年,最大的感嘆莫過於:唯一不變的就是「變」。筆者一直覺得掌握不變的、較為抽象、形而上的觀念,其重要性遠高於埋沒在繁雜變動的技術中。而此本書就是討論這類議題的好書,它敘說著IT專案管理上的誤謬。

@小標:越早開始的,越晚結束

在筆者己身的經驗中,IT 專案的起始需要細細琢磨WhoWhatWhichWhenHow

Who(有沒有夠專業的團隊):這是成功與否的絕對關鍵因素,沒有正確的人,其他四個W都是瞎掰的。

What(需求是否清晰?系統主架構是否明確):唯有正確的方向,才能做對的事情,否則只有嘆將帥無能,累死三軍。

Which(什麼樣的技術、軟硬體產品、開發方法論是適合的):工欲善其事,必先利其器,如此才能把事情做對。

When(什麼是合理的時程與進度):品質、功能、時程、成本是四個互相牽扯制肘的面向,而時程最難預估與掌控。

How(如何按部就班地實踐):細節是成功的關鍵,要能有效地施行、監控與評估。

@小標:科技始終依靠人性

一直覺得資訊專案管理是一門藝術,它不太容易標準化,複製成功案例。資料專案太倚賴高素質的人一起團隊合作,而與人相處本身就是一種藝術,要學有專精的人一起集結創意,更是藝術中的精品。

在這本書中,作者條列了IT專案的特徵、成功者須具備的條件及失敗者常誤入的陷阱,但並沒有Step by Step的流程,可能IT開發的本質,就是沒有放諸四海皆準的流程,畢竟功能需求、使用技術、人力配置、經費成本、組織文化等面向差異太大,因此需要管理者小心翼翼、步步為營地,關注呵護一個系統的成長。

這其實是IT經理人應該深思的,就筆者廣泛接觸的經理人們,為數不少的人都還在等待書中所懷疑的銀彈,癡妄地以為花點時間學到一套蓋世神功,或覓得神兵利器,陷在泥淖的系統開發,就可以迎刃而解了。

一些無心的專業經理人擁有甚囂塵上的PMP,朗朗上口CMMI的枝節,但未關注團隊人心,以致溝通不良。我無意貶抑PMPCMMIAgile等學理的重要性,它們非常的重要,或許,可視為現今資訊專案管理的基本知識。有中心思想,才有進步的依據。

但我想強調的是:IT是活的,落於紙上的都是死的。「擱淺的船就是燈塔」,死掉的理論只能讓我們避免不要在同一塊礁石上擱淺。而無心不經意地駕駛,終究會擱淺在另一塊礁石上。

部份IT經理人不具備資訊科技的基本知識,因為日新月異的技術早迥異於他在學校所學的。又磨光了初入行的熱忱才升上經理階級,沒時間也沒興趣吸收資訊常識。對於使用者的需求應用面僅略知一二,整日忙著把酒言歡,與關鍵關係人建立人際關係。奢言要求他對系統主架構的認知與重視,更由於缺乏眼界與肩膀而盲目答應,讓團隊失去了方向。

同時,在人月迷思中,貶抑了專業的價值,以為人多就可辦事,花錢就可解決問題,而不思如何建構具水準的團隊。想要當個入門的IT經理人,或許需要先讀通本書,了解揉合科技與人性的困難。

@小標:資訊專案管理的重點

30 多年前,Brooks博士在本書中所提及的概念,至今仍是IT開發的圭臬,由於己身知識與經驗不足,我試著表列自認為的重點如下:

l 軟體系統大概是人類創作中最錯綜複雜的東西(從組成各部份的類型數量來看)。軟體開發的問題源自於本質上的複雜性,以及複雜性隨著軟體規模成非線性成長。

l 人月是個危險並很容易就遭到誤解的迷思,因為他假設人力和工時是可以互換的。

l 在一個時程已經落後的軟體專案中增加人手,只會使它更落後。

l 同樣資歷下,優秀程式設計師的生產力要比差勁的好上十倍。

l 專案如果要成功,人的品質以及人的組織與管理,遠遠比他們所運用的工具或技術要來得重要。

l 設計系統時,最重要的是概念整體性。

l 太多的失敗都源自於自始至終都搞不清楚要做的是什麼。

l 專案經理最好的朋友,就是整天和他唱反調的、獨立的產品測試小組。

l 每個子案子(Subproject)都必須具備兩種領導角色,也就是管理者和技術總監或架構設計師,兩種角色的職掌不同,需要的天份也不同。

l 在功能、效率、程式大小、成本和時程之間總是衝突的情況化,架構設計師需要綜觀全局,站在維護使用者利益的角度上做出取捨。

l 為什麼專案會落後一年,因為每次落後一天。每天一點點的延誤讓人無關痛癢,很難預防也很難挽救。

l 軟體專案越到後期,進展越慢。

l 第一次出爐的系統絕少是有用的,把必然的一次失敗納入到正式計劃中,製作測試系統(如現今的AlphaBeta 版本)。

l 每修正一個錯誤之後,都應該將之前所有的測試案例拿來進行回歸測試。

l 交付出去的程式都應附帶一小組測試案例,包含合法的輸入、罕見的輸入和明顯不合法的輸入。

l 系統除錯與組件除錯相比,所耗費的時間將超乎你的預期,須具備一套條理分明,規劃良好的測試方案。

在書中,Brooks博士根據己身的經驗,或是旁徵博引各大師的研究著述,娓娓敘說著箇中原委。讀完此書,讓我有一個深深的感受,資訊專案的開發過程中,局部的錯誤失敗是必然的,並不可怕。可怕的是不能從失敗錯誤中學習,一再犯同樣的錯誤導致全面性的失敗。

書中在第八章開頭引用了一句話:經驗的代價是昂貴的,但愚人就只能從經驗中學習(Experience is a dear teacher, but fools will learn at no other)」但更為可惜的是,太多的專案經理由於過於忙碌,沒有時間也缺乏停下來深思的習慣,往往付出了慘痛的代價,但經由反省而學到的經驗卻少之又少。

@小標:閱讀建議

若你從事的是資訊相關工作,不管是經理人,架構或需求的分析設計人員,開發、除錯、維護人員等,或許都該翻翻這本書,了解用來安身立命的工作之特質。書中描述了許多應有的態度與方式。從仿效開始,強迫自己養成好習慣,久而久之,自發性地做對的事情,自然會累積成功。

由於本書的各章節有其獨立的討論議題,建議你先概略瀏覽一下全書,在心中對軟體專案的特質有個概念,而後在專案進行中,隨著情境的變遷,再回來溫習一下,相信會更有所得。另外,它的第十八章是個總結,若你需要提綱挈領,可以閱讀此章。

書中有一個特點就是每章開頭都附有貼切的短文與圖案,饒富機智與趣味。當筆者第一次看完這本書後,立刻就將所有章節開頭的短文都敲到網誌上。偶而悵然若失時,讓我有機會反省一下是否又陷入了什麼樣的迷思。

期待這一本好書能讓你在資訊海洋航行時,摸索出正確的航向。