1 教師住房管理信息系統設計說明書 第一部份軟件工程 1968 年，北大西洋公約組織的學術會議第一次創造了“軟件工程”一詞，提出“軟件工程”概念。通過工程化的方法來開發軟件，解決軟件危機。三十年余年來，盡管軟件的差錯就象汽車一樣時有拋錨的時候，但軟件的發展速度遠遠超過了任何傳統工業，而期間并未出現真真的軟件危機。這在很大程度上歸功于“軟件工程”。如今軟件工程成了一門學科。 軟件工程簡單的講，主要講述軟件開發的道理，基本上是軟件實踐者的成功經驗和失敗教訓的總結。軟件工程的觀念、方法、策略和規范都是樸 實無華的，平凡之人皆可領會，而關鍵在于運用。軟件工程方法是應該事先掌握，在整個軟件設計過程中都必須遵照執行的，而不能把它看成是事后解決問題的錦囊妙計，對預料將要出現的問題，必須控制每個實踐環節，防患于未然。研究軟件工程將隨著軟件工程的開始，直到軟件被廢棄研究工作才結束。 軟件工程中最基本的概念是軟件生命周期。一個軟件從定義到開發、使用和維護，直到最終被廢棄，要經歷一個漫長的時期，通常把軟件經歷的這個漫長的時期稱為生存周期。軟件生存周期就是從提出軟件產品開始，直到該軟件產品被淘汰的全過程。軟件生命周期 是指軟件產品或軟件系統從產生、投入使用到被淘汰的全過程統。通常，將軟件生命周期分為五個階段：需求分析、系統設計、編碼實現、系統測試和運行維護。 需求分析和系統設計是軟件開發過程中最核心的活動。典型的針對需求分析和系統設計的軟件開發方法有：結構化分析方法、面向數據結構的方法和面向對象方法。 結構化分析方法 (稱 一種面向數據流進行需求分析的方法，適合于數據處理類型軟件的需求分析。結構化分析方法使用數據流圖 數據字典 描述，面向數據流問題的 需求分析適合于數據處理類型軟件的需求描述。其核心思想是分解化簡問題，將物理與邏輯表示分開，對系統進行數據與邏輯的抽象。下面的需求分柝和系統設計就是以結構化分析方法為前提的。 面向數據結構的方法是結構化方法的變形，它注重數據結構而不是數據流，是從數據結構方面分析，即分析信息結構，并用數據結構圖來表示，在此基礎上進行需求分析，導出軟件的結構。其特征是：信息結構是層次式；數據結構的表達要求用順序、選擇、重復等合成構造；具有將層次式數據結構映射到程序結構的映射機制。 一、 需求分析 一目錄概述背景： 系統目標完 成的任務、不完成的任務、業務模式、業務狀況、用戶需求、業務需求、使用范圍、功能要求、權限管理性能、需求業務流程與其他系統的關系業務、流程圖業務、邏輯業務分解。 業務描述數據分析、數據單據數據、分類數據描述附件概述。 景 ：該教師住房管理信息系統是按課題要求所完成的。 面向的用戶 : 全校住學校宿舍的教師 因此該系統的最終用戶是全校的住學校宿舍的教師，同時還有對于住房分配的相關管理者。他們的權限各有不同。要求使用本系統的用戶對計算機能夠熟練的使用，知道基本的操作。 統目標 統應 完成的目標 通過計算機完成教師住房管理 :用計算機高速、快捷的完成從大量的戶主中提取相關信息，以反映住房情況；計算機聯網后，數據在網上傳遞，可以實現數據共享、避免重復勞動，規范住房分配管理行為、從而提高了分配效率和水平；住房管理信息系統以計算機為工具，通過對住房管理所需的信息管理，把管理人員從繁瑣的數據計算處理中解脫出來，使其有更多的精力從事住房管理政策的研究實施，分配計劃的制定執行和分配質量的監督檢查，從而全面提高分配的合理性。 統不完成的任務 : 1 系統不統計對于戶主住房地址等信息的管理。 2 系 統同時對輸入僅提供簡單的輸入格式是否合格檢查，不提供對輸入的核對檢查，要確定輸入是否正確，還需工作人員自己手工完成。 2 務模式 (略 ) 行組織機構及業務狀況 用戶目前完成這些工作是通過傳統的手工操作方式，易發生數據丟失、統計錯誤、勞動強度高、且速度慢，通過計算機工具和本系統來提高速度、改善現狀。 務需求 用范圍 高校教師住房情況以及可分配的房源，隨時可以查詢 ,輸出。 能要求 戶主檔案管理 :戶主的一般情況（每個已注冊戶主的姓名、性別、職稱等） 能需 求 息由各用戶在規定的權限下在各自的工作站上錄入，信息上網后各用戶可查詢、調用，達到信息共享，數據的完整性、準確性。錄入數據采用表格方式，限制錄入數據類型及取值范圍以保證數據的完整性及準確性。 統備有的修改功能均可反悔。 如房源的分配，只有在戶主相關申請后才可以進行分配。 第一級 :依賴于網絡本身對用戶使用權限的規定。 第二級 :在程序模塊中通過使用密碼控制功能對用 戶使用權限加以限制。如前面的數據收集前的系統權限表。 二、 概念結構圖 管理員身份驗證 主控對話框 戶主相關信息 房源相關信息 戶主信息瀏覽 戶主信息查詢 房源信息處理 房源申請處理 家庭信息查詢 戶主身份驗證 主控對話框 戶主相關信息 房源相關信息 戶主信息處理 戶主信息查詢 家庭信息處理 房源申請信息 3 二、系統設計 系統設計是把需求轉化為軟件系統的最重要的環節：系統設計的優劣在根本上決定了軟件系統的質量 o：系統設計主要著力于系統“如何做”，它包含如下四方面內容：體系結構設計、模塊設計、數據結構與算法設計、用戶界面設計。在系統設計時，通常分為概要設計和詳細設計兩個階段。詳細設計產生程序員可用的模塊說明，即數據結構說明及加工描述。 1概要設計 概要設計建立整個軟件體系結構，包括子系統、模塊以及相關層次的說明、每一模塊的接口定義等。概在概要設計過程中，復審系統計劃與需求分析，確定系統具體的實施方案，構建軟件的體系結構。概要設計還要確定模塊結構，劃分功能模塊，將軟件功能需求分配給所劃分的最小單元模塊。要確定各模塊間的聯系，確定數據結構、文件結構、數據庫模式，以及確定測試方法與策略。 體系結構設計 體系結構是軟件系統中最本質的東西，它是對復雜事物的一種抽象。良好的體系結構是普遍適用的，它可以高效地處理多種多樣的個體需求。體系結構設計時 應在一定的時間內保持穩定。 軟件體系結構已經在軟件工程領域中有著廣泛的應用，但迄今為止還沒有一個被大家所公認的定義。體系結構 (詞在英文里就是“建筑”的意思。我們把 定義作為參考：軟件體系結構是具有一定形式的結構化元素，耳 p 構件的集合，包括處理構件、數據構件和連接構件。處理構件負責對數據進行加工，數據構件是被加工的信息，連接構件把體系結構的不同部分組組合連接起來：這，定義注重區分處理構件、數據構件和連接構件，這一方法在其他 的定義和方法中基本上得到保持。 體系結構有許多種，包括常用的層次結構。 層次結構是把比較復雜的事情，進行分層，然后 層一層地去完成。在實現時，高層的工作總是建立在低層的工作之上。層次關系主要有兩種：上下層關系和順序相鄰關系。 上下層關系非常常見，如學校的組織結構，最高層是學校，下面院系，院系下面是學系。在權限上學校的權限高于院系，學校可以指揮院系，而反過來不行。 對于順序相鄰關系，我們可以把計算機網絡的 考模型來理解， 七個層次，在通訊時，只能在相鄰兩層之間發 生，信息只能被一層一層地順序傳遞下去。發送方和接收方傳遞的方向剛好相反。 體系結構設計要求：通過分層，把每個功能逐步獨立起來，并且保證每個功能都有相應的模塊來實現；要確定模塊間的調用關系，對模塊間接口做總體描述，明確模塊間信息的傳遞。 模塊設計 在設計好軟件的體系結構后，宏觀上就明確了各個模塊應具有的功能，在哪一個層次上，與其他功能模塊的關系。我們習慣從功能上劃分模塊，保持“功能獨立”是模塊化設計的基本原則。因為，“功能獨立”的模塊可以降低開發、測試、維護等階段的代價。但是“功能獨 立”并不意味著模塊之間保持絕對的孤立。一個系統要完成某項任務，需要各個模塊相互配合才能實現，此時模塊之間就要進行信息交流。模塊設計主要說明每個模塊“做什么”、簡要說明數據輸入、輸出、處理邏輯、與其它模塊的接口，與其它系統或硬件的接口等聯系。 評價模塊設計優劣的三個特征因素：“信息隱藏”、“內聚與耦合”和“封閉、開放性”。 信息隱藏：是盡量避免某個模塊的行為去干擾同一系統中的其它模塊，在我們學習面向對象程序設計，類的封裝性就是為了實現信息隱藏。 內聚與耦合：內聚 (一 個模塊內部各成分之間相關聯程度的度量。耦合 (模塊之間依賴程度的度量。內聚和耦合是密切相關的，與其它模塊存在強耦合的模塊通常意味著弱內聚，而強內聚的模塊通常意味著與其它模塊之間存在弱耦合。模塊設計追求強內聚，弱耦合。 封閉、開放性：如果一個模塊可以作為一個獨立體被其它程序引用，則稱模塊具有封閉性。如果一個模塊可以被擴充，則稱模塊具有開放性。 模塊的“封閉、開放性”實際上對應于軟件質量因素中的可復用性和可擴充性。采用面向過程的方法進行程序設計，很難開發出既具有封閉性又具有開放 性的模塊。采用面向對象設計方法可以較好地解決這個問題。 2詳細設計 詳細設計的目的是為軟件中的每一個模塊確定使用的算法和塊內數據結構，并用某種選定的表達工具給出清晰的描述。主要任務： 為每個模塊確定采用的算法，選擇某種適當的工具表達算法的過程，寫出模塊的詳細過程性描述； 確定每一模塊使用的數據結構； 確定模塊接口的細節，包括對系統外部的接口和用戶界面，對系統內部其它模塊的接口，以及模塊輸入數據、輸出數據及局部數據的全部細節。 4 為每一個模塊設計出一組測試用例，以 便在編碼階段對模塊代碼 (即程序 )進行預定的測試，模塊的測試用例是軟件測試計劃的重要組成部分，通常應包括輸入數據，期望輸出等內容。 三、編碼實現 編碼實現是將設計結果轉化為可執行的程序代碼，這是程序員的主要任務。 要將設計結果轉化為語言代碼，首先必須正確理解需求分析中要求“做什么 ?”。要詳細閱讀概要設計書和詳細設計書，明確自己需要完成的模塊和其他 模塊之間的聯系 (接口規范 )，外部提供的數據元素和自己輸出的數據元素等。 一個大的系統是由一個團隊共同協作完成的，必須完全按照設計書的要求來完成相應模 塊的程序編碼。 一個好的程序編碼，在完成模塊功能的前提下，應該做到程序簡單易懂、運行可靠、性能穩定和執行效率高等特點。 1在編碼實現過程中還應該注意做到： 所使用的標識符應有一定的約定，盡可能采用有一定含義的名字，可以顧名思義； 在程序設計時，盡可能加上注解； 書寫格式要規范，采用縮進等格式； 這樣，可以便于閱讀和理解程序，為今后維護提供便利條件。 2采用標準的控制結構 根據詳細設計的流程，采用標準的和詳細設計要求一致的分支和循環結構，不準隨意的 用 句或多余無效的循環等。 3數據輸入、輸出要求 數據的在輸入、輸出過程中，要求做到： 人機操作界面要友好，操作方便，對于前后界面之間、相同類似操作界面間等風格要一致。如 同的對話框界面等。 從外部提供的數據 (輸入數據 )要進行合法性或有效性檢查，防止無效數據輸入。如性別輸入，只有男或女兩者之一，在輸入時應根據約定只能提供男女兩種數據形式。 如果數據是根據約定輸入 (是為了方便數據的輸入 )，應該提示相關約定信息。如性別輸入時 用 M 表示男，用 F 表示女，則在輸入時，應該包含上面的約定信息。 輸入的數據格式盡可能和日常的表示方式一致。如日期，我們通常的表 示是年月日格式。 數據輸出時，盡可能輸出易懂的信息，如果是符號，要提示符號的約定。如性別輸出是應該輸出男或女，如果輸出的是符號，則需說明 M表示男， F表示女，便于別人理解。 程序要具有“傻瓜”功能，不會因為用戶輸入信息等環節偶然的錯誤，而導致程序非正常退出。 除此之外，還可以提供在線幫助等方式，來方便用戶使用。 四、系統測試 系統測試就是通過測試 活動使軟件系統達到需求時提出的各項要求，檢測和排除錯誤。測試總是在假設程序中存在缺陷的前提下，再通過執行程序來發現并最終改正缺陷。 世界上沒有完美無缺的程序，任何程序都或多或少的存在錯誤，系統測試的目的是盡可能多的去發現程序所存在的錯誤，提高程序的質量。 要盡可能多的發現程序中的錯誤不是一件輕而易舉的事情。需要找到相關的測試的方法，而要找出系統中所有的錯誤，那只是一種設想。試想一下目前我們使用非常廣泛的 作系統，還一直被程序的許多漏洞所困擾，微軟一直在提供相關的補丁，使系統能穩 定的運行。 測試一個系統，一定要明確是尋找系統中的缺陷和錯誤，如果是去證明系統的正確性，那么測試的時候，就會按照系統的流程去測試，這樣就不可能發現程序中的錯誤，這樣的測試是毫無意義，也是沒有必要的。 一個成功的測試示例在于發現了至今尚未發現的缺陷。 對一個系統的測試內容有： 功能性測試：測試軟件功能是否滿足設計要求，當給定合理的數據輸入，系統能否得到預期的結果。功能性測試是系統成立的前提。 容錯性測試：當給定的數據偏離合理數據范圍時，系統能否正常運行而不至于系統癱瘓或不會得出 啼笑皆非的結果。 性能與效率測試：性能與效率測試主要是測試軟件的運行速度和對資源的利用率。一個好的系統應該盡可能低的占用計算機資源，且運行效率高。 易用性測試：系統提供的使用方法是否方便。一個好的系統應該有好的應用界面，使用戶操作方便、輸入輸出直觀。 當對系統進行具體測試時，有多種測試手段： “白盒測試”是指開發人員從程序內部對上述內容進行測試。“白盒測試”針對程序內部邏輯結構，對 5 所有邏輯路徑進行測試。測試時，從檢查程序的邏輯著手，得出測試數據。 “黑盒測試” (又 稱為功能測試或數據驅動測試 )是把測試對象看作一個黑盒子。利用黑盒測試法進行動態測試時，需要測試軟件產品的功能，不需測試軟件產品的內部結構和處理過程。 五、運行維護 運行維護是將系統投入運行，并對投入運行的軟件進行修改調整，使軟件系統能適應外界環境的變化、實現功能擴充和質量改善。 前面我們已經提到，系統不可能是完美無缺的。當系統投入使用后，系統中的缺陷就會不斷暴露出來，系統投入使用的開始，也是系統不斷維護的開始。系統維護的終結，也是系統“死亡”的時刻。 維護主要分三類： 糾錯性維護： 由于前期的測試不可能揭露軟件系統中所有替在的錯誤，用戶在使用軟件時仍將會遇到錯誤，診斷和改正這些錯誤的過程稱為糾錯性維護。 適應性維護。由于新的硬件設備不斷推出，操作系統和編譯系統也不斷地升級，為了使軟件能適應新的環境而引起的程序修改和擴充活動稱為適應性維護。 完善性維護。在軟件的正常使用過程中，用戶還會不斷提出新的需求。為了滿足用戶新的需求而增加軟件功能的活動稱為完善性維護。 參考資料： 1本章的部分內容引用了浙大林銳博士的 、 、 輸出： 、 、 功能：建立查詢總表 調用以下模塊： 模塊 模塊名： 入： 、 輸出： 功能：將 、 存入指定的 中。 模塊 模塊名： 入： 、 輸出： 功能：將 中信息折算成分數，并按總分從高到低排成 。 10 模塊 模塊名： 入： 、 輸出： 、 和 中的一項或幾項的屏幕形象或紙面現象。 功能：將 、 和 中的一項或幾項在屏幕或打印機上顯示出來。 模塊 模塊名： 入： 、 輸出： 功能：將 按總分從高到低排序。 調用以下模塊：無 模塊 模塊名： 入： 輸出： 的屏幕或紙面形象。 功能：將 在屏幕或紙面上顯示。 調用以下模塊：無 注釋：該模塊與數據流圖中的加工 對應。 四 詳細設計（ 語言） 系統中所用的數據結構模塊 i; 后續函數中所需的中間變量 日期類 年、月 ; 等級表類 00; 姓名 職稱（ 1教授 ;2副教授 ;3教師 ;4助教） 參加工作日期 最后學歷（ 1博士 ;2碩士 ;3本科 ;4其他） 原住房等級（ 1集體宿舍； 2一室； 3一室一廳； 4二室； 5二室一廳； 6三室； 7三室一廳） 職稱分、工齡分、年齡分、學齡分 總分 ; 家庭成員類 00; 成員姓名 （ 1 2 出生日期 ; 戶主類 00; 戶主姓名 戶主性別（ 1 2 戶主職稱（ 1教授 ;2副教授 ;3教師 ;4助教 ;） 出生日期 參加工作日期 11 最后學歷（ 1博士 ;2碩士 ;3本科 ;4其他 ;） ; 教師住房信息類 戶主 家庭人數 00; 家庭成員類家庭成員數組 現住房等級（ 1集體宿舍； 2一室； 3一室一廳； 4二室； 5二室一 廳； 6三室； 7三室一廳；） 現住房面積（單位：平方米；） 分數 申請住房等級（ 1集體宿舍； 2一室； 3一室一廳； 4二室； 5二室一廳； 6三室； 7三室一廳； ） 教師住房信息類指針 ; 戶主信息輸入模塊 ; p1=p2=n=1; 分別輸入戶主個人信息及家庭成員信息并輸出存儲在文檔中 ) if(n=1)p2=p1= n+; if(2) ; 再次輸入戶主個人信息及家庭成員信息并輸出存儲在文檔中 申請住房信息輸入模塊 教師申請住房信息 ; a; p1= (=*a) 輸入與申請住房相關的各類信息 12 2); if(0)1)s=s+20; 職稱分計分系統 if(2)s=s+16; if(3)s=s+12; s=s+8; p,q; p=( 工齡分 q=( 年齡分 s=s+p+q; 學齡分 if(1)s=s+ if(2)s=s+s=s+2; s; p1= 類信息輸出模塊 申請一室住房名單（按順序排名并存盤） 申請一室一廳住房名單（按順序排名并存盤） 申請二室住房名單（按順序排名并存盤） 申請二室一廳住房名單（按順序排名并存盤） 申請三室住房名單（按順序排名并存盤） 申請三室一廳住房名單（按順序排名并存盤） 輸出婚后仍分居集體宿舍者的戶主姓名及出生年月，這類教師的總數。 輸出未住上三室一廳或三室的副教授、教授姓名及現住房標準，這類教師的總數。 輸出未住上一室一廳及以上等級的具有博士學位的教師姓名及住房標準。 輸出全校教師人均 (包括家庭人口 )住房面積 。 5 編程（略） 第三部份成績評定標準 第四部分用戶說明書 本教師住房管理系統全部代碼均由 C+編寫而成，用于教師住房信息的創建、修改、刪除、排序、查找以及查詢相關教師住房信息。 使用本軟件，只需運行其中的“教師住房管理系統 可。 13 本系統主要功能如下： 1 創建存儲教師住 房信息。 2 分房時，為申請者輸入申請信息 (存盤 )。 3 對于所有分房者按申請等級不同 (共 6 級 )分別按分數高低列表 (一種等級一張表 )輸出 (同時存盤 )。 4 各類信息的查詢 A輸出婚后仍分居集體宿舍者的戶主姓名及出生年月，這類教師的總數。 B輸出未住上三室一廳或三室的副教授、教授姓名及現住房標準，這類教師的總數。 C輸出未住上一室一廳及以上等級的具有博士學位的教師姓名及住房標準。 D輸出全校教師人均 (包括家庭人口 )住房面積。 本系統具體操作如下： 1 創建存儲教師住房信息 當 打 開 本 系 統 進 入 管 理 界 面 ， 出 現 如 下 界 面 輸入 1 進入教師住房信息創建系統，系統如圖： 14 這時用戶可按照自己的信息輸入，系統會為用戶自動將信息存盤。輸入完后將進入下一界面： 此時，如需創建下一教師住房信息，輸入 1 繼續，否則輸入 2。本此操作為介紹所需（戶主押書凱，家庭成員吳凱劉燁李聰），為簡便起見，直接進入下一程序。輸入 2 后界面如下： 2. 分房時，為申請者輸入申請信息 (存盤 )。 接 1 最后一張圖，輸入 1 后界面如下： 此時便是第 2 條功能，申請者輸入申請信息。輸入信息后，界面如下： 3 對于所有分房者按申請等級不同 (共 6 級 )分別按分數高低列表 (一種等級一張表 )輸出(同時存盤 )。 上述操作完成后，會自動生成 件“教師申請住房信息”、 “教師住房信息 ”： 此時結束申請信息的輸入后會出現如下界面： 輸入 1 進入。 然后出現如下界面： 15 按照系統提示可進行相關信息的查詢（ 此次查詢包含有第 3 條功能需求的部分 ）和第 4 條的功能如下： A輸出婚后仍分居集體宿舍者的戶主姓名及出生年月，這類教師的總數 B輸出未住上三室一廳或三室的副教授、教授姓名及現住房標準，這類教師的總數 C輸出未住上一室一廳及以上 等級的具有博士學位的教師姓名及住房標準 D輸出全校教師人均 (包括家庭人口 )住房面積 此前信息為“押書凱申請三室一廳”，所以我們選擇第 6 條查詢功能： 系統會自動彈出申請三室一廳的人數及其信息，繼續輸入 8 進行查詢： 其余各條功能在此不再一一演示。每輸入一項查詢操作，便會自動生成相應的 件： 16 最后輸入 2 退出信息管理系統。 第五部分程序設計日志 教學住房管理系統 工作日志 作者： 組成員： 期 考勤 內容 勤 初步接觸課程設計任務，由劉老 師講解。開始選擇設計課題，定為“教師住房管理系統”。 四人共同討論了關于高校教師住房管理系統的任務 成系統分析報告的