【文章內容簡介】 (如數據表 )的類型。 這兩種類型之間聯系密切，在數據庫開發(fā)中兩種類型都會用到。然而，如果使用數據訪問類型來填充數據表示類型將節(jié)省大量工作。 目前的主流版本是 ，比之前的版本提供了更先進的功能，主要包括以下高級特性： 支持批量復制，在其 .NET 類庫中提供了批量復制類。 新的主要數據控件，包括 DataGridView、 DataConnector 和 DataNavigator。 DbProvidersFactories 類，該類能導出本地計算機中的 .NET 數據提供者列表。 DataTable 新增兩個重要的方法： Load()方法和 Save()方法。 Load()方法可將數據對象直接加載到 DataTable 中，而 Save()方法可以將 DataTable 中的數據保存到一個持久化的存儲媒體中。 支持自定義的數據提供者。 最短路徑算法介紹 最短路經 算法 分靜態(tài)最短路 徑算法 和動態(tài)最短路 徑算法 。靜態(tài)最短路徑算法是外界環(huán)境不變，計算最短路徑。主要有 Dijkstra 算法， A*（ A Star）算法。動態(tài)最短路 徑算法 是外界環(huán)境不斷發(fā)生變化，即不能計算預測的情況下計算最短路。如在游戲中敵人或障礙物不斷移動的情況下。典型的有 D*算法 [4]。 最短路徑不僅僅指一般意義上的距離最短，還可以引申到其他的度量，如時間、費用、線路容量等。相應地，最短路徑問題就成為最快路徑問題、最低費用問題等。由于最短路徑問題在實際中常用于汽車導航系統(tǒng)以及各種應急系統(tǒng)等（如 110 報警、 119 火警以及醫(yī)療救護系統(tǒng)），這些系統(tǒng)一般要求計算出到出事地點的最佳路線的時間應該在 1 s～ 3 s 內，在行車過程中還需要實時計算出車輛前方 的行駛路線，這就決定了最短路徑問題的實現應該是高效率的。其實 ,無論是距離最短、時間最快 、 費用最低，它們的核心算法都是最短路徑算法。 經典的最短路徑算法 —— Dijkstra 算法是目前多數系統(tǒng)解決最短路徑問題采用的理論基礎，只是不同系統(tǒng)對 Dijkstra 算法采用了不同的實現方法。 Dijkstra 算法的基本思路是：假設每個點都有一對標號 (dj, pj)，其中 dj是從起源點 s 到點 j 的最短路徑的長度 (從頂點到其本身的最短路徑是零路 (沒有弧的路 )，其長度等于零 )； pj 則是從 s 到 j 的最短路徑中 j 點的前一點。求解從起 源點 s 到點 j的最短路徑算法的基本過程如下： 。起源點設置為： 9 ① ds=0, ps 為空 。 ② 所有其他點 : di=∞ , pi=?。 ③ 標記起源點 s，記 k=s,其他所有點設為未標記的。 k 到其直接連接的未標記的點 j的距離，并設置： dj=min［ dj, dk+lkj］ 式中， lkj 是從點 k到 j的直接連接距離。 。從所有未標記的結點中，選取 dj 中最小的一個 i： di=min［ dj, 所有未標記的點 j］ 點 i 就被選為最短路徑中的一點，并設為已標記的。 點 i的前一點。從已標記的點中找到直接連接到點 i 的點 j*， 作為前一點 ,設置： i=j* i。如果所有點已標記，則算法完全推出，否則，記 k=i，轉到 2 再繼續(xù)。 從上面可以看出，在按標記法實現 Dijkstra 算法的過程中，核心步驟就是從未標記的點中選擇一個權值最小的弧段，即上面所述算法的 (2)～ (5)步。這是一個循環(huán)比較的過程，如果不采用任何技巧，未標記點將以無序的形式存放在一個鏈表或數組中。那么要選擇一個權值最小的弧段就必須把所有的點都掃描一遍，在大數據量的情況下，這無疑是一個制約計算速度的瓶頸。 要解決這個問題，最有效的做法就是將這些要掃描的點按其所在邊的權值進行順序排列，這樣每循環(huán)一次即可取到符合條件的點，可大大提高算法的執(zhí)行效率 [5]。 還有一種基于 Dijkstra 算法的優(yōu)化算法 ——— 鄰接結點算法 ,該算法充分利用了網絡拓撲信息中的弧段的連接關系 ,避免了使用含有大量無窮值的關聯矩陣 ,使之更適合帶有拐向限制設置的最短路徑算法和大量結點的實際數據。實踐證明 ,該算法可以節(jié)約大量的內存 ,對于結點數比較大的網絡 ,或帶有大量拐向限制設置的網絡 ,具有較好的適用性。 A*算法作為一種改進的 Dijkstra 算法 ， 實際上是一種啟發(fā)式搜索，所謂啟發(fā)式搜索，就是利用一個估價函數評估每次的決策的價值，決定先嘗試那一種方案。這樣可以極大地優(yōu)化普通的廣度優(yōu)先搜索。一般來說，從起始點 A到終點 B的最短路徑是固定的，可以寫一個函數 Judge()來估計 A到 B的最短距離，如果程序已經嘗試著從 A沿著某條路線移動到了 C 點，那么認為這個方案的 AB 間的估計距離為 A 到 C 實際已經行走了的距離 H加上用 Judge()估計出的 C到 B的距離。如此，無論程序搜索展開到了哪一步，都會算出一個評估值，每一次決策后，將評估值和等待處理的方案一起排序，然 后挑出待處理的各個方案中最有可能是 10 最短路線的一部分的方案展開到下一步，一直循環(huán)到對象移動到目的地為止 [6]。 B/S 介紹 B/S（ browser/server，簡稱 B/S）模式 ，即 瀏覽器 /服務器 模式，它是 基于Intra 的需求而出現并發(fā)展的。 Intra 是應用 TCP/IP 協(xié)議建立的企事業(yè)單位內部專用網絡，它采用諸如 TCP/IP、 HTTP、 SMTP 和 HTML 等 Inter 技術和標準，能為企事業(yè)單位內部交換信息提供服務。同時，它具有連接 Inter 的功能和防止外界入侵的安全措施。另一 方面，由于數據庫具有強大的數據存儲和管理能力，并且能夠動態(tài)地進行數據輸入和輸出，如果把數據庫應用于 Intra上，不僅可以實現大量信息的網上發(fā)布，而且能夠為廣大用戶提供動態(tài)的信息查詢和數據處理服務，進而加強企事業(yè)單位內部部門之間、上級部門與下級部門之間、企事業(yè)單位員工之間、企事業(yè)單位與客戶之間以及企事業(yè)單位與企事業(yè)單位之間的信息交流，降低企事業(yè)單位的日常工作成本，提高企事業(yè)單位的經濟效益。 它通常采用 3 層結構：瀏覽器―― WEB 服務器――數據庫服務器。 在 Intra 框架中， Browser/Server模型的處理方式如下： 1．用戶打開計算機中的瀏覽器。 2．輸入或自動啟動主頁的 URL (Uniform Resource Locator)，瀏覽器生成一個 HTTP 請求并把它發(fā)給指定的 Inter 服務器。 3．服務器發(fā)回主頁的 HTML (Hypertext Markup Language)頁面。瀏覽器將其顯示在屏幕上。 4．用戶在主頁面上進行操作 (如：點擊、鍵入等 )。 5．瀏覽器生成相應的 HTTP 要求，發(fā)送給相應的服務器。 6．服務器收到請求后，查看本站點是否擁有這個文檔。如果有，就將它放入響應信息中返 回給瀏覽器。 7．瀏覽器收到響應，查看頭文件的格式，判斷能否直接顯示。如果否，就調用對應的幫助應用程序或外掛程序處理顯示。 11 第三章 系統(tǒng)需求分析 本章分析了系統(tǒng)的各項需求，包括性能需求 、功能需求、 模塊劃分 等 。 性能需求分析 為了保證系統(tǒng)能夠長期、安全、穩(wěn)定、可靠、高效地運行，公交查詢系統(tǒng)應該滿足以下性能需求： 、 及時性 和響應速度 系統(tǒng)處理的準確性和及時性是系統(tǒng)的必要性能。查詢時應保證查全率，所有相應域包含查詢關鍵字的記錄都應能查到。在系統(tǒng)設計和開發(fā)過程中，要充分考慮系統(tǒng)當前和 將來可能承受的工作量，使系統(tǒng)的處理能力和響應時間能夠滿足系統(tǒng)管理員對信息處理的需求。響應時間，更新處理時間都 要 比較迅速， 應 滿足 大部分 用戶 的 要求。一般操作的響應時間應在 12s 內，對數據的導入、導出的操作也應在可接受的時間內完成，原則上保證操作人員不會因為速度問題而影響工作效率。 系統(tǒng)在開發(fā)過程中，應該充分考慮以后的可擴充性。例如，用戶查詢的需求也會不斷地更新和完善。這就要求系統(tǒng)提供足夠的手段進行功能的調整和擴充。而要實現這一點，應通過系統(tǒng)的開放性來完成，即系統(tǒng)應是一個開 放系統(tǒng)，只要符合一定的規(guī)范，可以簡單地加入和減少系統(tǒng)的模塊，配置系統(tǒng)的硬件。通過軟件的修補、替換，完成系統(tǒng)的升級和更新換代。 系統(tǒng)是直接面對使用人員的，而使用人員往往對計算機并不是非常熟悉。這就要求系統(tǒng)能夠提供良好的用戶接口，易用的人機交互界面。所以在系統(tǒng)開發(fā)的時候就考慮到了這一點，只要用戶知道本系統(tǒng)的網址就可以直接使用本系統(tǒng)的查詢模塊而無須用戶注冊及登陸，充分節(jié)約了用戶查詢的方便及隨意性。其次，要實現本系統(tǒng)的易用性就要求系統(tǒng)應該盡量使用用戶熟悉的術語和中文信息的界面；針對用戶可 能出現的使用問題，要 提供足夠的在線幫助，在本系統(tǒng)中專門設置了“聯系我們”這一信息 ，可以讓用戶對本系統(tǒng)的不足之處讓設計者知道，使系統(tǒng)更加完善。 公交查詢系統(tǒng)中涉及到的數據是公交公司的相當重要的信息，系統(tǒng)要提供方便的手段供系統(tǒng)維護人員進行數據的備份，日常的安全管理，系統(tǒng)意外崩潰時數據的恢復等工作。 12 系統(tǒng)在設計開發(fā)使用過程中都要涉及到很多計算機硬件、軟件。所有這些都要符合主流國際、國家和行業(yè)標準。例如在開發(fā)中使用的操作系統(tǒng)、網絡系統(tǒng)、開發(fā)工具都必須符合通用標準。如規(guī)范的數據庫操縱界面、作為 業(yè)界標準的TCP/IP 網絡協(xié)議及 ISO9002 標準所要求的質量規(guī)范等；同時，在自主開發(fā)本系統(tǒng)時，要進行良好的設計工作，制訂行之有效的軟件工程規(guī)范，保證代碼的易讀性、可操作性和可移植性。目前計算系統(tǒng)的技術發(fā)展相當快，做為公交查詢系統(tǒng)工程，應該保證系統(tǒng)長期保持先進，在系統(tǒng)的生命周期盡量做到系統(tǒng)的“與時俱進”，充分完成企業(yè)信息處理的要求而不至于落后。這一方面通過系統(tǒng)的開放性和可擴充性，不斷改善系統(tǒng)的功能完成。另一方面，在系統(tǒng)設計和開發(fā)的過程中，應在考慮成本的基礎上盡量采用當前主流并先進且有良好發(fā)展前途的產品。 功能 需求分析 本系統(tǒng)采用結構化設計的方法來實現系統(tǒng)總體功能，提高系統(tǒng)的各項指標，即將整個系統(tǒng)合理的劃分成各個功能模塊，正確地處理模塊之間和模塊內部的聯系以及和數據庫的聯系，定義各模塊的內部結構，通過對模塊的設計和模塊之間關系的系統(tǒng)來實現整個系統(tǒng)的功能。 普通用戶需求分析 基于方便市民搭乘公交出行的原則，該系統(tǒng)應滿足 普通用戶 下面幾方面 功能需求： ：方便用戶了解到最快最新的線路信息，如 :此線路經過哪些站點，和站點在線路中的位置等。 ：用戶如果對線路不清楚，只知道自己要去的 地方，那么站點查詢會幫你快速找出可以搭乘哪些線路的公交車到達此地 ,還能提供 各線路的相關信息，并注明了此站點在相應線路中的順序，方便用戶了解該站點在線路中所處的位置。 ：如果沒有直達線路，則找出轉乘的最短公交路線。用戶輸入起始站和終點站作為查詢關鍵字，即可查詢到三次轉車內到達目的地址的公交線路。可以為用戶節(jié)省更多的時間，也提高了效率。 ： 將用戶查詢到的內容 自 動生成報表，并打印輸出 。 ：用戶可聯系管理員反映自己的意見。 查詢者 可以執(zhí)行線路查詢、站點查詢、換乘查詢（包括：一次 換乘、二次換 13 乘、三次換乘查詢）的操作。 查詢者 的用例分析如圖 所示： 查 詢 者系 統(tǒng)線 路 查 詢站 點 查 詢換 乘 查 詢一 次 換 乘二 次 換 乘三 次 換 乘 子 類 子 類 子 類 圖 查詢者的用例分析 由上圖可查詢者所需執(zhí)行的系統(tǒng)功能。 管理員需求分析 為了維護系統(tǒng)的正常運行，系統(tǒng)還需提供 后臺管理 功能， 用于管理員登陸，添加、修改、刪除公交 數據信息 ，修改信息資料、安全密碼，回復用戶留言等 ，其中最主要的功能是新增、修改、刪除數據信息 ，以保證公交 車線路 是正確可用的。管理員的用例 分析如圖 所示 ： 管 理 員系 統(tǒng)新 增查 看修 改刪 除 e x t e n d s e x t e n d s 圖 管理員的用例分析 由上圖可知管理員所需執(zhí)行的系統(tǒng)功能 。 14 功能 模塊劃分 模塊 該模塊實現公交查詢功 能。可實現按線路查詢、站點查詢和起點－終點查詢三種查詢方式。 模塊 該模塊實現數據的新增、修改、刪除功能 。 模塊的各功能劃分如圖 所示： 圖 系統(tǒng)功能模塊圖 系統(tǒng)的功能模塊由上圖所示劃分，在不同的模塊下實現不同的功能 ，如普通用戶模塊下有車次查詢、站點查詢等功能，管理員用戶模塊下有修改、刪除數據等功能，分工明確，一目了然。 公交路線查詢系統(tǒng) 普通用戶模塊 管理員用戶模塊 車次查詢 站站查詢 站點查詢 路線打印 新增 刪除 修改 線路 車輛