9+資源環(huán)境信息系統（GIS07）.ppt

2020 3 14 1 2 5環(huán)境GIS工程開發(fā)與實現 軟件工程思想軟件危機與軟件工程環(huán)境GIS開發(fā)模式環(huán)境GIS系統分析環(huán)境GIS系統設計環(huán)境GIS系統實施環(huán)境GIS系統維護 2020 3 14 2 系統實施階段的任務 是實現系統設計階段提出的物理模型 按實施方案完成一個可以實際運行的信息系統 交付用戶使用 系統實施包括資源配置 程序編寫 系統安裝和系統測試 實施管理小組負責系統實施的進度和質量管理 2020 3 14 3 1 系統配置 系統配置包括軟硬件配置 人員組織以及數據準備等 2020 3 14 4 軟硬件購置在規(guī)劃地理信息系統的軟硬件時 需要考慮的主要因素包括 系統的數據量有多大 用戶數有多少 網絡環(huán)境是什么 投資規(guī)模如何 地理信息系統在整個系統中所處的位置是什么 也就是說 這是一個純粹的地理信息系統還是地理信息系統與其它系統相結合的綜合信息系統 如果是綜合系統 是以地理信息系統為主體還是以其它的系統為主體 2020 3 14 5 以ESRI公司的產品為例 如果所開發(fā)的系統投資規(guī)模比較小 對系統的功能要求不是很高 可以選用ArcView3 x軟件或MapObjects進行開發(fā) 如要求系統有較強的功能 系統投資規(guī)模較大 可考慮選用ArcGIS軟件進行開發(fā) 如系統數據量大 而且要滿足多用戶并發(fā)訪問 則需要配置ArcSDE 如系統是B S結構 則可選用ArcIMS開發(fā) 如開發(fā)的地理信息系統是綜合系統的一部分 利用MapObjects開發(fā)比較合適 每一種軟件 對硬件的配置有相應的要求 如ArcView3 x要求主機的基本配置 主頻 內存 2020 3 14 6 硬件配置 2020 3 14 7 人員組織軟件項目成功的關鍵是要有高素質的軟件開發(fā)人員 然而大多數軟件產品規(guī)模都很大 以至單個軟件開發(fā)人員無法在給定期限內完成開發(fā)工作 因此 必須把多個軟件開發(fā)人員組織起來 分工協作 共同完成開發(fā)工作 為了成功地完成軟件開發(fā)工作 項目組成員必須以一種有意義且有效的方式彼此交互和通信 如何組織項目組是一個管理問題 管理者必須合理地組織項目組 使項目組有較高生產率 能夠按預定的進度計劃完成所承擔的工作 經驗表明 項目組組織的越好 其生產率越高 而且產品質量也越高 2020 3 14 8 現有的軟件項目組的組織方式很多 常見的有程序設計小組的組織 主程序員組的組織等 程序設計小組的規(guī)模以2 8名成員為宜 通常采用非正式的組織方式 也就是說 雖然名義上有一個組長 但是他和組內其他成員完成同樣的任務 在這樣的小組中 由全體討論決定應該完成的工作 并且根據每個人的能力和經驗分配適當的任務 如果組內多數成員是經驗豐富技術熟練的程序員 那么這種組織方式會非常成功 但如果組內多數成員水平不高 沒有明確的權威指導開發(fā)工程的進行 最終可能會導致工程失敗 2020 3 14 9 美國IBM公司在1970年代初期開始采用主程序員組的組織方式 主程序員組由主程序員 后備主程序員 編程秘書以及1 3名程序員組成 在必要的時候 該組還有其他領域的專家 例如 法律專家 財務專家等 協助 主程序員組的組織方式有不少優(yōu)點 但典型的主程序員組在許多方面是不切實際的 2020 3 14 10 人員配置 2020 3 14 11 2 程序編寫 程序編寫的過程就是利用某種程序設計語言把詳細設計編碼成計算機可接受的形式 也是人借助編程語言與計算機通信的過程 應該說 在系統開發(fā)的各個階段中 編程是最容易 也是人們已掌握得較好的一項工作 但編寫一個好的程序需要高水平的編程人員 2020 3 14 12 對于程序好壞的評價 50年代與70年代的觀點有很大不同 50年代計算機內存小 速度慢 人們往往把程序的長度和執(zhí)行速度放在重要位置 費盡心機縮短程序長度 減少存儲量 提高速度 現在情況有了很大的不同 一般認為好程序應具備的最重要條件是可讀性 2020 3 14 13 要使程序的可讀性好 程序員應有一定的寫作能力 他應寫出結構良好 層次分明 思路清晰的程序 有人說 對于程序員來說 最重要的不是學習程序設計語言 FORTRAN C等 而是英語 日語 漢語 程序員在寫程序時應該記住 程序不僅是給計算機執(zhí)行的 也是供人閱讀的 2020 3 14 14 程序設計語言 程序設計語言發(fā)展到今天 先后有幾百種程序設計語言 大致可分為四代 第一代語言是指與機器緊密相關的機器語言和匯編語言 其歷史可追溯到第一臺電子計算機問世 因其與硬件操作一一對應 基本上有多少種計算機就有多少種匯編語言 第二代語言是20世紀50年代末至20世紀60年代初先后出現的 它們應用面廣 為人們熟悉和接受 有大量成熟的程序庫 這代語言包括FORTRAN COBOL Algol60和BASIC等 2020 3 14 15 第三代語言 也稱結構化程序語言 其特點是直接支持結構化構件 并具有很強的過程能力和數據結構能力 這類語言本身又可細分為三類 通用高級語言 如Pascal Ada等 專用語言 如LISP Prolog等 和面向對象的語言 如C Smalltalk Java等 第四代語言實際上就是程序生成器 它能輸入由自然語言書寫的語句 自動產生完整的程序 但目前這方面成功的例子還只限于商業(yè)信息系統的開發(fā) 2020 3 14 16 程序設計語言的選擇 選擇合適的程序設計語言能減少編碼的工作量 產生易讀 易測試 易維護的代碼 程序設計語言的選擇應考慮的因素包括 應用領域 算法和計算的復雜性 軟件運行環(huán)境 軟件性能要求 數據結構的復雜性 軟件開發(fā)人員的知識水平等 其中 項目所屬的應用領域常常作為首要的標準 2020 3 14 17 程序設計語言的選擇 例如 C語言常用于系統軟件開發(fā) COBOL迄今仍為商業(yè)信息處理的首選語言 FORTRAN始終占領著工程及科學計算領域的主導地位 人工智能領域則更多地使用LISP Prolog等 2020 3 14 18 在GIS開發(fā)中的程序設計語言底層開發(fā)通常采用VC 等 組件開發(fā)通常采用VB Delphi等 WebGIS開發(fā)通常采用Java等 虛擬現實GIS開發(fā)采用VRML等 2020 3 14 19 編程的技巧和方法 70年代以來 人們總結了使程序簡單 清晰的種種技巧和方法 包括 用結構化方法進行編程設計 程序中包括說明文檔 良好的程序書寫風格 良好的編程風格 2020 3 14 20 結構化程序設計 結構化程序設計 是荷蘭學者Dijkctra提出的 他要求程序設計者不能隨心所欲地編寫程序 而要按照一定的結構形式來設計和編寫程序 基本思想 將一個大的程序按功能分割成一些小模塊 開發(fā)方法 自上向下 逐步分解 分而治之 2020 3 14 21 結構化程序設計的特點 各模塊相對獨立 功能單一 結構清晰 接口簡單控制了程序設計的復雜性提高元件的可靠性縮短開發(fā)周期易于維護和功能擴充具體有兩個方面 一是程序設計采用自頂向下 逐步細化的原則 二是程序的控制結構由三種基本結構 順序結構 分支選擇結構和循環(huán)結構 構成 2020 3 14 22 順序結構 以各子結構出現的次序順序控制執(zhí)行 分支選擇結構有兩種 一是If then else結構 另一種是case結構 當滿足某個條件時反復執(zhí)行 否則不執(zhí)行 Do while循環(huán) 2020 3 14 23 順序結構 Input 請輸入梯形的上底 ToMInput 請輸入梯形的下底 ToNInput 請輸入梯形的高 ToH 梯形面積 Str M N H 2 10 2 Return 2020 3 14 24 選擇結構 2020 3 14 25 循環(huán)結構 2020 3 14 26 結構化程序設計有以下幾個特點 只有一個入口和一個出口 沒有死語句 永遠執(zhí)行不到的語句 沒有死循環(huán) 無限制的循環(huán) 2020 3 14 27 提供說明文檔 程序中的說明文檔可以用注釋語句書寫 程序適當加注釋后 閱讀時就不必再看其他說明材料了 因此 是提高程序可閱讀性的有力手段 程序中的注釋包括文件頭注釋 函數注釋 程序段注釋和語句注釋 2020 3 14 28 增加注釋的原則注釋必須與程序一致 否則毫無價值 甚至使人感到莫名其妙 所以 修改程序時 要注意對注釋進行相應的修改 注釋不是重復程序語句 而應提供從程序本身難以得到的信息 對程序段作注釋 而不是對每個語句作注釋 2020 3 14 29 文件開頭的注釋模板 文件名 Copyright c 1998 1999 公司技術開發(fā)部 創(chuàng)建人 日期 修改人 日期 描述 版本 2020 3 14 30 函數開頭的注釋模板 函數名 輸入 a b c a b c 輸出 x x為1 表示 x為0 表示 功能描述 全局變量 調用模塊 作者 日期 修改 日期 版本 2020 3 14 31 程序段和語句注釋實例 初始化控件 comboBox1 Items Clear 清空組合框 listBox1 Items Clear 清空列表框 2020 3 14 32 良好的編程風格 編程的風格在很大程度上影響著程序的可讀性 可測試性和可維護性 良好的編程風格是在不影響性能的前提下 有效地編排和組織程序 以提高可讀性和可維護性 2020 3 14 33 良好的編程風格體現在 結構化規(guī)范化簡單化 2020 3 14 34 結構化 實質是控制編程中的復雜性 除了使用讀者明了的結構化程序部件 還包括用公共函數調用代替重復出現的表達式等 2020 3 14 35 規(guī)范化 理解變量的含義是理解程序邏輯的關鍵 在系統中 涉及的變量 過程 文件很多 編寫程序的人也很多 因此 在編寫程序之前 應對名字做出統一的規(guī)范標準 變量名應顯示說明 同一變量名不要具有多種含義 一個變量在不同程序段中表示不同的含義 即使計算機不混淆 也不便于人的閱讀理解 修改程序時也容易造成錯誤 變量名 文件名 過程名應規(guī)范化 應選用表義性強的名字 相應英文名或縮寫 避免使用臨時變量而使可讀性下降 適當插入括號 使表達式的運算次序清晰直觀 排除二義性 有效使用空格符 以區(qū)別程序的不同意群 例如 注釋與程序 分程序之間等 2020 3 14 36 簡單化 使用簡單的數據結構 避免使用多維數組 指針和復雜的表 使用執(zhí)行時間短的算術運算 避免不同類型的對象混合操作 盡量使用整型運算和布爾表達式 以手工方式簡化算術和邏輯表達式 直接地反映代碼的意圖 2020 3 14 37 DO14I 1 NDO14J 1 N14V I J I J J I DO5I 1 NDO5J 1 NIF I EQ J THENV I J 1 0ELSEV I J 0 0ENDIF5CONTINUE 兩個程序比較 軟件測試 2020 3 14 39 在開發(fā)軟件的過程中 人們使用了許多保證軟件質量的方法分析 設計和實現軟件 但難免還會在工作中犯錯誤 這樣 在軟件產品中就會隱藏許多錯誤和缺陷 對于規(guī)模大 復雜性高的軟件更是如此 在這些錯誤中 有些是致命的錯誤 如果不排除 就會導致生命與財產的重大損失 2020 3 14 40 1963年在美國曾發(fā)生了這樣一件事 把一個FORTRAN程序的循環(huán)語句DO5I 1 3誤寫成DO5I 1 3 循環(huán)語句被當作了賦值語句 一點之差致使飛往火星的火箭爆炸 造成1000萬美元的損失 這種情況迫使人們必須認真計劃 徹底地進行軟件測試 2020 3 14 41 什么是軟件測試 軟件測試是為了發(fā)現錯誤而執(zhí)行程序的過程 軟件測試在軟件生存期中橫跨兩個階段 通常在編寫出每一個模塊之后就對它做必要的測試 稱為單元測試 編碼與單元測試屬于軟件生存期中的同一個階段 在結束這個階段之后 對軟件系統還要進行各種綜合測試 這是軟件生存期的另一個獨立階段 即測試階段 測試只能證明程序有錯誤 而不可能證明程序沒有錯誤 2020 3 14 42 軟件測試的目的 GrenfordJ Myers提出以下觀點 測試是程序執(zhí)行過程 目的在于發(fā)現錯誤 一個好的測試用例很可能找到迄今為止尚未發(fā)現的錯誤 一個成功的測試是發(fā)現了至今未發(fā)現的錯誤的測試 E W Dijkstra指出 程序測試能證明錯誤的存在 但不能證明錯誤不存在 測試的目的是發(fā)現程序中的錯誤 是為了證明程序有錯 而不是證明程序無錯 2020 3 14 43 軟件測試的目的 測試的目的是想以最少的時間和人力系統地找出軟件中潛在的各種錯誤和缺陷 測試的附帶收獲是 它能夠證明軟件的功能和性能與需求說明相符合 此外 實施測試收集到的測試結果數據為可靠性分析提供了依據 把證明程序無錯當作測試目的不僅是不正確的 完全做不到的 而且對做好測試沒有任何益處 甚至是十分有害的 能夠發(fā)現錯誤的測試是成功的測試 否則是失敗的測試 2020 3 14 44 測試者知道軟件怎樣才能發(fā)生故障而導致失敗 并可記錄發(fā)生失敗的多種故障類型測試案例沒有冗余 每個測試案例都有不同的用途 不要重復相同意義的測試案例使用最具有代表性的案例 它能夠高效率揭示所有可能的錯誤每個測試應該能獨立執(zhí)行 不能太復雜 也不會太簡單 它們能夠被組合用于一個測試案例中 好的測試應該具有的特性 2020 3 14 45 軟件錯誤的分類 按錯誤的影響和后果分類較小錯誤 只對系統輸出有一些非實質性影響 如 輸出的數據格式不合要求等 中等錯誤 對系統的運行有局部影響 如輸出的某些數據有錯誤或出現冗余 較嚴重錯誤 系統的行為因錯誤的干擾而出現明顯不合情理的現象 比如開出了0 00元的支票 系統的輸出完全不可信賴 嚴重錯誤 系統運行不可跟蹤 一時不能掌握其規(guī)律 時好時壞 非常嚴重的錯誤 系統運行中突然停機 其原因不明 無法軟啟動 最嚴重的錯誤 系統運行導致環(huán)境破壞 或是造成事故 引起生命 財產的損失 2020 3 14 46 軟件測試的特點 軟件測試的開銷大按照Boehm的統計 軟件測試的開銷大約占總成本的30 50 例如 APPOLLO登月計劃 80 的經費用于軟件測試 不能進行窮舉測試只有將所有可能的情況都測試到 才有可能檢查出所有的錯誤 但這是不可能的 例如 程序P有兩個整型輸入量X Y 輸出量為Z 在32位機上運行 所有的測試數據組 Xi Yi 的數目為 232 232 264 假設 毫秒執(zhí)行 次 如要進行完全測試 共需 億年 例 Windows95有1000萬行代碼 Windows2000有5000萬行代碼 3000多個工程師 幾百個小團隊 Exchange2000和Windows2000開