Visual Basic .Net (VB.Net) 程式語言案例學習 (01. 快速建置資訊系統)¶

1 簡介¶

這是一本介紹用簡潔又快速的方式應用資訊的書籍，怎麼說呢？原因在題目，這是個無解的題目，永遠都有更快更好的方式建立系統，科技日新月異，本來要花十年的工，現今可能只要十分鐘。現實一點好了，工作總是這麼多，事情永遠做不完，尤其資訊行業，永遠都有新鮮事。當然能快就快，一件事趕快處理完，自己還可以多撈一些自修的時間，我想鮮少會有老闆願意或知道讓員工自修，其實也是知識資產增加的部份。因為看不到嘛！只有當員工離職時才會驚覺，阿～那個某某人以前真的做了很多事。因此，這本教材的動機就很清晰明瞭了，就是希望能夠替資訊人員增加一些時間，無論自修自樂都是好事。能夠調節身心，免得時時處在緊繃的狀態，那人久了也真是受不了。

本教材會分為兩個大類，一類是在於分析問題及處理方式，第二類是以實際的案例來做說明。本教材有個好處，程式碼公開，好不好用直接可以試用，您可以自行修改程式碼應用在工作上，無須重新再將程式碼輸入一遍。謂何第一類？就是提供簡單的分析方法，現實工作中除非是很有制度的公司，要不然是不會重視分析階段，大部分都是構想一下，就開始邊作邊想邊改。因此作者依據以往的經驗，規劃出幾段重要的項目，在分析時要考慮的部份。依照所列的項目去設想，很快就可以有系統的雛形。並且列出基本系統規格文件，輪廓較為清晰。

第二類的部份，是拿出實際案例，描述當初設計場景，有原始的程式碼，並標示出重點，以供讀者修改，進而讓使用者了解設計架構及修改重點。儘量採取輕鬆及簡單的方式讓使用者能夠快速明瞭，能夠快速應用。目的是要解決問題，而並非是完全自製程式。有時透過既有的軟體就可以解決的問題，例如像是微軟的Office系列產品可處理的問題，就交給微軟處理吧。或不能完全交給，也可以採取合作的方式，給一部份自己做，一部份交由微軟Office。解決問題隨時想到手邊可用的方法，就可以立刻拿來用，可行的話，稍微包裝一下，再送出去。一個問題有多的解法，實例說明時，會採取類似的介紹方法，而不單一直述一種作法。活化腦筋，俗話說：『山不轉，路轉；路不轉，人轉』。在第二類會看到很多這樣的例子。

本教材想要表達一種意思，相同的人，不同的環境，會有不同的處理方式，因為人是活的，所以可以把事情做活。只要達成目的，使用好的方法是很重要的，而好的方法也不會只有一種，壞的方法在不同的時機也許會成為最適當的方法。説到這裡是不是有點暈頭轉向，總而言之，快速建置資訊系統是要提供適當的方法解決問題。期望客倌們會喜歡。

1.1 資訊系統的目的¶

目的是建置資訊系統的原因，所以一開始就要很清楚。系統要做什麼，不要做什麼；能做什麼，不能做什麼。很多時候分析目的的時候，常常聚焦在這個系統要做什麼，能做什麼，而忘記不要做什麼，不能做什麼。導致功能不斷的增加，慾望不斷的增強。

相信這是時常發生在會議上，大家談的興高采烈的時候，新的點子就不斷的加入，過了幾次會議，越改越奇怪，越來越離開本來的目標。過些時候會發現使用者與開發者之間鴻溝越來越深。雖然在學術上有提出需多的解決辦法，但這些辦法必須在有共識的情形下才能運作。否則就變成一人獨唱高調的情形，因此建議在一開始的時候就要採取明確目標的方式，能夠讓大家都清楚，這個系統不能及不要的部份，以防在＂加一點沒有關係＂、＂這又沒什麼，又不是很難，就加上去吧＂的使用者觀點，而危害了整體系統的完整性。

表格 1‑1簡單的系統目的分析表

版本：	要做什麼	不要做什麼（不要做不代表不會做）
能做什麼	（要做及能做的項目。）	（儘量不要做但卻是能力範圍內的項目。）
不能做什麼（不能做代表不需要做）	（要做卻不能做成的項目，或是這樣做不能達到更好效果的敘述。）	（不要也不能答應的要求。）

列出明確的系統目標後，就要開始進行分類的工作了。分類能夠讓系統輪廓顯現。分類的方式，以類似用這種概念去構想，將目標項目分群，也可以找出優先權，什麼項目是應該先做的，什麼可以後做，什麼項目是必須等待。還可以找到重要程度，什麼項目是重要的，重要的意涵是系統的核心，當該項目完成後，越能顯現系統完成度的項目，就是越重要的。反之，完成的某個項目，對於系統似乎影響不大，這就是不重要的。

例如影像瀏覽程式，重要的項目應該是對圖片檔案解碼顯示為核心，完成後雛型就顯現出來了。反之，列印的功能完成後，卻沒有什麼大的幫助，因此重要的程度是很小的。雖然有時候優先權與重要的程度是有點難去區分，但還是可以看出端倪來。在制定項目的時候，儘量採取明確的語句，越是模糊的語句是越難分類，不要有看似重要卻又不重要的語句敘述。透過簡單的圖表1，來做個簡單的系統目標分析。

表格 1‑2簡單的系統目標分析表

版本：	重要	不重要
優先	（重）	（急）
不急迫	（輕）	（緩）

有了上述兩張表格，填滿之後大概的系統輪廓就會顯現了。顯現後的輪廓，助於我們限制系統的邊界，所謂邊界內就是系統能做及要做的部份，邊界外就是系統不能及不要的部份。若不能不要的部份，就再採取其他的方式去解決，例如合作策略，或是分工方式，都是能使系統成型的方法。每個階段都有可能去修改到這兩張表格，但是必須把握原則，不能做什麼及不要做什麼必須優先列出，以防止系統邊界扭曲變形。

有時候還可以透過這兩張表格，取出可能的工作時段，進行簡單的專案規劃。安排工時制定流程，這也是另一種用法。

1.2 規格¶

制訂系統規格是很重要的階段，若不清楚系統平台的性質，很容易設定出看似合理確難實現的規格出來。規格依照系統目的系統目標中抽取出來，或是模擬出來。規格也有分很多種，例如最常見的是系統需求，最低需求，建議需求。這是指運行這套系統的最低及建議的要求。

規格的項目也要清楚的名列，列出清單有個好處，可以有系統的檢驗，而比較不會漏掉什麼。在呈現給客戶或是使用者看的時候，也會有一整套的參考資料，以及清晰的思維。一個最起碼的規格表，至少會羅列出系統項目，項目內容中是參數，或是勾選，等等的表示。這也是將目標系統量化的一個方法。

表格 1‑3簡單的規格表

規格項目	規格內容	備註
…	(參數)	…

1.3 建置、調校、維運¶

建置資訊系統初期必定會遇到一些不可預期的問題，因此規劃、評估就是初期的必要工作，透過幾張簡單的表格大致可以處理掉一些問題。遇到不可預期的問題就得在羅列出來，反覆的處理問題。調校是在系統開始導入，就要開始的工作，問題會不斷的被提出來，期望做些修改或者是新增、刪除。不斷的變更就是調校時期的工作，直到大家都可以接受的一個程度，會趨近穩定。

穩定後便進入維持運作的階段，維持運作的工作是很繁雜的，檢修、更新、備份、還原、安全都是維持運作時期要做的，系統很要注意軟體的版次，因此最好是每一個版本都必須有備份，或更新之前的備份，已備不時之需。一般來說，很少去進行還原測試，必須驗證備份的工作是否有效，就必須還原操作。在安全的部份，具有權限的操作者可以操作的什麼樣的階段，也必須去設限。設限並非不信任，而是避免發生問題後，問題涵蓋的層面擴大，變的不好處理及分析。

1.4 建置資訊系統的原則¶

1.4.1 解決問題為主¶

問題是目標，也就是人類希望透過系統去處理的項目，這項工作藉由系統去處理會比較好，比人類做的好才會交由系統去運作。這也是問題所在。系統本身所具備哪些知識或是哪些功能，能夠比人類做的更好呢？至少人類要能夠知道這些訊息，主要還是解決問題為主。透過這些訊息來處理問題，而非去製造更多的步驟更麻煩的程序來搗亂。俗話說：「真不知是被電腦用，還是在用電腦」的窘境，才不會發生。

1.4.2 找到同質性（減少重工）¶

在解決問題的同時，為求不必要的重複工作，必須力求儘量減少。有時後多花些時間設計，是為了往後運用，在設計時儘量不要被一個問題所綁死，程式及方法就只為了一個問題而做，往後要再遇到類似的問題還是必須要重新設計，這實在不是大家所樂見的。找到同質性，就可以減少重工。這有些抽象化的意義，去尋找程式再用的可能性，也許不用深入到設計技巧方面，有時候用直觀的方式去思考程式再利用，會是比較快速的方式。

1.4.3 絕對會變¶

「客戶及使用的需求唯一不變的就是會變」，這句話應該在很多場合都適用，的確沒錯。實在很難去設計一套規則，之後就不會去更改的。因此設計時時都要保持彈性，抱持彈性可以免除厄運到來，沒有彈性的程式，最終不是被重新設計，要不然就是被消滅。

因此要保留程式設計的彈性就是儘量採取可替換式的設計，每個環節採取能夠替換的方式設計，無須深奧的技巧，把握這個原則就可以避免沒有彈性了。程式間的接口，也是關鍵所在，一致化的介面接口，可以免除在替換時的麻煩，不用轉換成為互相知道的資料形式，這樣應用可以因應一變再變的需求。

1.5 資料的儲存方式¶

在這裡指的是程式儲存資料的形式，並非實體的儲存裝置。程式運作方式是系統的思維及智慧，產生的資料有時必須儲存起來，呼叫再度使用。有不同形式的儲存方式可以供參考，也應用到不同時機。

1.5.1 檔案¶

常見應用在需要快速呼叫的機制中，例如有些代理伺服器（Proxy Server）的暫存檔，一個快速的索引指向到一個檔案，而這檔案就是索引指向的資料內容。其實「快速」就是要使用它的時機。無須事先建立起連線，也沒有透過特別的轉介動作，直接開檔取用，就是要快。有時可以透過建樹（資料結構中所描述的樹狀結構）的方式替檔案名稱編碼，對於大量的又須快速存取的檔案，可以直接的開啟使用。

1.5.2 資料檔¶

雖說MS Access是資料庫的一種，但其還是以檔案的形式所存在，因此歸類在資料檔，此種形式特點就是一個檔案中可以存放許多資料，有許多的資料表，資料表還可以互相的關連，建立成為集中式的資料檔。使用時必須先建立連線，雖然可以方便的連線，取用資料，而且可以共用的連線，這些支援都已經設計妥當了，依照規則就可以順利的存取資料，但是隨著資料量的增加，檔案也會不斷的膨脹，有時好幾十MB的資料檔都有可能。

頻繁的新增、刪除及修改也都會造成檔案大小的成長，必須透過壓縮來處理。連線數不如資料庫的那麼多，速度也不如直接以檔案形式開啟的快，但卻是簡單適中，使用功能方便的選擇。有時後需要用到資料庫的架構，一般應用又不需要像檔案開啟要求速度，事實上資料檔的引用是很受歡迎的。

1.5.3 資料庫¶

資料庫有許多廠商各有各的特點，一般最常見於Windows平台上所使用的就是MS SQL，有個特點可以透過既有的介面，連線資料庫，也可以網路的方式連線，這是在開發網路版本程式相當方便的一點。雖然速度不會很快速，但是卻也足夠使用於一般應用，行政及網路上的應用都相當合適，而且有完整的調教機制，透過Enterprise Manager就可以概觀的統合資料庫，去管理資料庫。甚至資料的備份還原及安全性的考量都會比資料檔來的周到。這也是常見的系統規劃方式。

1.6 資料的表示方式¶

資料的表示在於顯示資料的方式，所謂「百聞不如一見」，一個清晰整齊的資料顯示方式的確有助於讀取資料的速度。

1.6.1 介面¶

操作資料的進出都是要依靠著介面，介面在這裡指的是操作介面。操作頁面是替資料進入時把關，何種資料格式何種形式才可進入，透過好的介面也許日期是透過點選的方式輸入，而不用使用者熟記日期格式，一步一步的輸入進去，還有輸入錯誤的風險，雖然輸入錯誤可以叫使用者重新輸入，但是這卻是相當不方便的事情。有些資料可以透過點選的方式或是已經安排好的下拉式選單，就不用使用文字方框輸入，文字方框雖然彈性很大，但從另一方面去考量的話，風險也很大，能用點選的就儘量不要讓使用者自行輸入，尤其是大量資料輸入的介面，其設計最好以點選方式，優點是資料不容易輸入錯誤，資料輸入速度比較快。常常因為一個空格，一個逗點而造成資料的錯誤。

以往常見到一些以SQL為指令的特殊符號，不小心由介面輸入進去後，卻叫不出來了問題，雖說這是程式設計要注意的部份，但也因為使用了文字輸入框後，讓使用者能夠自行輸入各種格式的文字，所造成的結果。安排介面是一種難說好壞的事情，但至少上述的原則能夠把握的話，資料進入比較不會有問題。

否則以往常見到，一些大量輸入資料尤其是個人資料表的時候，幾乎可以看到十幾種電話的格式，有的會空白，有的會用括號，有的會用連字符號，等等。這對於處理電話資料時都是個困擾，更別說有的數字用全形輸入。那才真叫人哭笑不得。

1.6.2 報表¶

報表是呈現資料最常用的方式，報表形式有許多種類，大致可分為匯總報表及明細報表。在這裡除了報表的形式，還指的是報表儲存的方式，一般的程式除了可將資料羅列成為報表之外，有的時候報表還可匯出成文字檔、HTML、MS Excel等其他形式的檔案。方便做報表的分析，這也是設計時的技巧。有些時候沒有辦法將所有功能集於一身的時候，透過合作的方式，將資料以報表形式匯出，交由其他外部程式去做分析，也是一種可行的方式。報表本身可以列印，預覽列印有時也可以做為檢視資料的操作形式，可多加利用。

1.6.3 網頁¶

網頁是目前最常見的呈現方式，尤其在Web Services逐漸普及的時代，網頁呈現資料或作為資料輸入輸出的介面，已經是非常方便的應用。如今Dot Net的網頁介面已經越做越方便，有時透過網頁以具有的輸入輸出控制項來製作程式，是相當快速的。網頁不但具有報表能顯示能力，也具有介面的操作能力。是兩者共通的結合體。網頁能夠提供自動化的報表形式，設計時有時可採用。無須像一般程式必須經過安裝、設定、啟用的幾個步驟。大家可以透過共通的溝通介面，操作介面溝通資料。

1.7 系統的設計方式¶

在這裡指的是設計時的工作環境，畢竟工作是掙一口飯吃，有時人還是得屈就環境的安排。但工作還是得做好，依照經驗將設計時的工作環境分類成三大類。這三大類對於程式設計各有不同的適應方式。

1.7.1 有規範的環境¶

若貴公司或工作環境已經有導入資訊開發流程，例如CMI、CMMI，等等。或者已經有規範，例如ISO的規定。那麼相信這些資訊要求是很審慎的，必須按部就班的照著做，因為大家都這麼做，而這麼做對於公司及大家都是有幫助的話，就不必更改什麼流程，除非您具有決策權限，而且熟知這些規定。因為貴公司或工作環境是有一定的嚴謹程度。當然制度的人導的，也許有些時候會淪為文件製造者。但這也是這個環境的一種文化，就要去適應。

1.7.2 目標型的環境¶

一般中小企業開發設計，也許不會有什麼大的硬性規定，只要能夠在預設的時間內達成開發目標即可。這種目標型的環境其實彈性也很大，就蠻適合本教材的設計方式，本教材內容應該能因應許多的狀況。一般會遇到的問題，透過分析就會有了目標清單，呈給上司或與同事討論時，就足夠應付。目標型的工作環境不管使用何種方法，都有討論的空間，只要能夠達成目的，即使很現成的方式，幾乎都可以過關。因為目標達成了，就不必太煩惱工作上的問題。

1.7.3 易變型的環境¶

易變型的環境有點類似服務業，只是服務的內容是資訊軟體。很少人會在乎您用何種方式設計開發，只要能夠解除他們的「病痛」，就可以了。而目標實在很不明確，隨時想到就會想要與設計人員討論，就要加入設計。這對於設計師來說好似很沒確定感，永遠也做不完的需求。因此，本教材提到系統目標設定時，就要清楚的羅列，「什麼不能，什麼不要」的原則，以免需求無度的時候，設計師很快就會被榨乾了。

1.8 案例分析¶

案例分析會針對問題而提出解決方案，解決方案可能不只一種，會由簡而繁，以因應不同的情況，本教材盡量能夠提出方便而快速的處理方式，方法也許不只一種，提出架構，讓設計者能夠繼續變化、擴充及延伸。

案例分析的表示方式會仔細描述，包括標題、問題、需求、特色、使用語言、使用軟體、系統架構、程式實作、修改重點、結論。

有時一個案例可能包含多次的變革，以因應使用者的變化，因此除了標題不變之外，其他的部份皆有可能再次的提出，不過有了版本的區別，就不會混淆了。

以下是各項目的意義：

項目	說明
標題	題目，這是給予問題的一個稱呼。看到標題時，大概可以了解到所遇到的問題，或是解決方案。
問題	描述所遇到的處境，及接到工作的內容。有時問題會因為使用者變而增加，鮮少有減少的時候。在這裡會詳細的問題羅列出來。
需求	由問題中抽出問題需求，讓設計者了解系統目的及系統目標。並且有簡單的規格單，以供驗證。
特色	介紹解決方案的標題，幾句話標出解決方案的特點，讓使用者能夠了解所帶來的好處。
使用語言	標示使用哪些程式語言，例如：Visual Basic、ASP、ASP .NET等等。
使用軟體	標示使用哪些應用程式，例如：MS Access、MS Excel等等。
系統架構	有時會將架構圖描繪出來，或者用文字的方式解釋，系統架構就是系統的本身核心。
程式實作	將完整經過試驗的程式碼羅列出來，並標以備註，使用者可以放心的去實作。
修改重點	指出當使用者要應用時，修改哪些部份較為方便，並指出用途。
結論	總結以整體內容做個簡單的彙整。
版本	若有多個版本時，會加註。

若還有不足的地方，會再加以敘述補充說明。本教材期望讀者能夠身歷其境的感受，以了解問題及解決方案的內容。

Lai Tai-Yu (賴岱佑)

回到教材說明