了得網研究生_信息繫統開發方法教程（第5版）

產品特色

編輯推薦

本書在介紹基本概念、開發思想和工作原則的基礎上，引入CMM概念介紹信息繫統開發過程的管理及內容。從繫統的觀點出發，站在全局的角度，介紹信息繫統的總體規劃方法，強調以數據為中心的信息資源規劃，並用總體規劃的結果指導後續開發工作，從而保證繫統良好的整體性。在後續的開發過程中，分階段介紹了每個階段的工作內容、工作方法。

內容簡介

本書繫統地介紹信息繫統開發中的基本概念、開發思想、基本的工作原則、開發方法及開發過程的管理。本書在介紹基本概念、開發思想和工作原則的基礎上,引入CMM概念介紹信息繫統開發過程的管理及內容。按照繫統的觀點,立足全局,介紹信息繫統的總體規劃方法,強調以數據為中心的信息資源規劃,並用總體規劃的結果指導後續開發工作,從而保證繫統良好的整體性。在後續的開發過程中,分階段地介紹每個階段的工作內容、工作方法。在需求分析階段,以面向管理流程的思想,以圖形化文檔為主要描述工具,描述、分析和確認信息繫統的功能需求;在繫統分析階段,詳細介紹如何在總體規劃指導下,以需求分析結果為依據構建信息繫統的功能模型、數據模型,進而建立支持下一階段開發的面向對像模型,同時為了減小開發產品與需求之間的偏差,引入黑盒測試方法,在繫統分析階段進行測試數據的設計;在繫統設計階段,以前一階段所構建的數據模型和面向對像模型為基礎,介紹面向對像設計的基本原則、評價標準和基本方法,同時引入白盒測試方法,再進一步開展測試數據的設計。測試數據的設計工作前移體現了測試驅動的思想,利用測試數據可以很好地幫助開發人員理解詳細的功能需求並及時發現程序設計中的缺陷;在繫統測試及運行維護階段,繫統地介紹各種測試方式、手段、工作原則和工作內容。
本書力求理論與實際的有機結合,用一個教學管理繫統案例貫穿整個開發過程,使開發方法具有較強的可操作性,能夠有效地指導開發人員構建一個性能良好、實用、可修改、可擴充的信息繫統,並為信息資源的開發和利用奠定良好的基礎。本書提供與之配套的教學課件,以方便教和學,本書可作為高等院校信息管理與信息繫統、計算機應用等專業的本科生教材,也可作為相關管理人員的培訓教材,同時也是信息繫統開發人員的參考書。

目錄
第1章信息繫統基本概念1
1.1信息的基本概念1
1.1.1數據與信息1
1.1.2信息的特性2
1.1.3信息的生命階段4
1.2信息繫統的基本概念9
1.2.1繫統的概念9
1.2.2信息繫統11
1.3信息繫統的開發20
1.3.1信息繫統開發中常見的問題20
1.3.2繫統的方法21
1.3.3繫統開發步驟23
1.3.4信息繫統開發的指導思想和工作原則27目錄
第1章信息繫統基本概念1
1.1信息的基本概念1
1.1.1數據與信息1
1.1.2信息的特性2
1.1.3信息的生命階段4
1.2信息繫統的基本概念9
1.2.1繫統的概念9
1.2.2信息繫統11
1.3信息繫統的開發20
1.3.1信息繫統開發中常見的問題20
1.3.2繫統的方法21
1.3.3繫統開發步驟23
1.3.4信息繫統開發的指導思想和工作原則27
1.4信息繫統開發的組織及項目管理30
1.4.1信息繫統開發人員的組織30
1.4.2繫統分析員應具有的基本技能32
1.4.3信息繫統開發中的文檔管理33
1.4.4信息繫統開發中的項目管理36
1.5原型法40
1.5.1原型法開發步驟41
1.5.2原型法的使用前提42
1.5.3原型法的人員組織和工作環境44
思考題45
第2章信息繫統開發過程管理46
2.1CMM概述46
2.1.1CMM基本概念46
2.1.2CMM框架49
2.1.3CMM管理手段53
2.2信息繫統開發過程模型55
2.2.1常用的開發模型56
2.2.2CMM中的開發流程定義59
2.2.3CMM中的開發流程裁剪63
2.3信息繫統開發過程中的標準規範68
2.3.1過程文檔的標準規範68
2.3.2開發文檔的標準規範70
2.3.3程序編制的標準規範71
思考題71
第3章信息繫統總體規劃72
3.1信息繫統總體規劃概述72
3.1.1問題的提出72
3.1.2總體規劃的時機75
3.1.3總體規劃的內容76
3.1.4總體規劃的組織77
3.1.5總體規劃的步驟79
3.2數據環境81
3.2.1建立數據庫的必要性81
3.2.2四類數據環境82
3.2.3主題數據庫規劃的內容83
3.3總體業務規劃84
3.3.1現行繫統的調查85
3.3.2職能域87
3.3.3業務過程88
3.3.4業務活動91
3.3.5業務模型的優化95
3.4總體數據規劃100
3.4.1主題數據庫規劃101
3.4.2信息繫統總體結構規劃102
3.4.3主題數據庫的分布規劃109
3.4.4主題數據庫的可靠性規劃112
3.5信息技術規劃112
3.5.1關鍵技術應用規劃112
3.5.2應用開發策略規劃115
3.5.3數據管理策略117
3.5.4硬件基礎設施規劃118
3.5.5開發工具的選擇策略120
思考題121
第4章業務流程及功能需求分析122
4.1需求調查概述122
4.1.1良好需求的特征122
4.1.2需求調查的步驟及工作產品124
4.1.3需求調查前的準備125
4.2業務流程調查126
4.2.1業務流程圖繪制標準126
4.2.2業務流程概要調查127
4.2.3業務流程詳細調查129
4.2.4業務流程審查與確認132
4.3功能需求分析與描述規範134
4.3.1自然語言描述面臨的問題135
4.3.2結構式語言136
4.3.3判斷樹139
4.3.4判斷表140
4.3.5功能需求描述範例142
4.4情景描述板143
4.4.1情景描述143
4.4.2UI設計基本原則145
思考題152
第5章繫統分析建模153
5.1繫統分析概述153
5.1.1繫統分析任務及步驟153
5.1.2繫統分析的工作產品154
5.1.3繫統分析的特點156
5.2繫統建模157
5.2.1文檔規範157
5.2.2詳細的功能分析及過程建模161
5.2.3過程模型的審查與確認166
5.2.4用例模型的設計169
5.3功能描述176
5.3.1用例的活動圖描述176
5.3.2狀態圖181
5.3.3用例說明183
5.4數據建模184
5.4.1關繫的基本性質及規範化形式184
5.4.2數據分析建立數據模型189
5.4.3信息分類編碼設計193
5.5時序分析199
5.5.1時序圖制作規範200
5.5.2功能需求的時序描述200
5.5.3時序描述的檢驗207
5.6類分析模型208
5.6.1繫統分析中的常用類及關繫208
5.6.2時序圖向類分析模型的轉換209
5.6.3構建類分析模型211
5.7測試用例的設計216
5.7.1測試用例的設計步驟216
5.7.2黑盒測試方法218
5.7.3流程測試226
思考題229
第6章信息繫統設計230
6.1信息繫統設計概述230
6.1.1功能設計的基本任務231
6.1.2繫統設計評價標準234
6.1.3繫統設計的步驟及工作產品238
6.2繫統架構設計239
6.2.1繫統架構簡介239
6.2.2繫統架構的選擇243
6.3繫統界面設計245
6.3.1輸入/輸出方式245
6.3.2界面靜態設計247
6.3.3界面動態設計250
6.4繫統功能設計252
6.4.1繫統流程對像設計252
6.4.2繫統實體對像設計255
6.5數據庫物理設計及持久化設計257
6.5.1數據庫物理設計257
6.5.2對像的持久化260
6.6程序設計262
6.6.1應用程序的詳細設計263
6.6.2面向對像的程序代碼設計269
6.6.3測試程序的設計280
6.6.4白盒測試方法281
6.7繫統實現285
6.7.1繫統配置及設定285
6.7.2繫統的部署286
思考題289
第7章繫統測試與運行維護290
7.1繫統測試概述290
7.1.1測試的基本方法290
7.1.2測試的基本原則292
7.1.3測試內容及測試手段294
7.1.4測試用例設計策略296
7.2人工測試方法296
7.2.1程序審查會296
7.2.2人工運行298
7.2.3靜態檢驗299
7測試和集成測試299
7.3測試300
7.3.2集成測試300
7.3.3測試的執行302
7.4高級測試302
7.4.1繫統測試302
7.4.2驗收測試及安裝測試305
7.5測試計劃和控制305
7.5.1測試計劃305
7.5.2測試完成的標準306
7.6繫統切換307
7.6.1繫統切換前的準備308
7.6.2繫統切換309
7.7繫統運行維護310
7.7.1繫統運行310
7.7.2繫統維護312
7.7.3繫統運行的審計與評價314
思考題315
附錄A程序代碼編寫規範示例317
A.1排版317
A.2注釋319
A.3命名320
參考文獻322

前言

前言
目前信息化已然成為企業經營管理的趨勢,也成為人們日常生活、學習、工作的重要組成部分。從技術層面來看,通信技術、遙感和傳感技術以及移動終端技術的發展為信息化提供了豐富的數據來源和采集手段,為大數據分析與應用奠定了良好的基礎;並行計算的應用則提升了大數據分析和各類信息處理的效率;瀏覽器/服務器模式使信息繫統應用和開發具有了跨平臺、跨地域的特點;大容量存儲技術、虛擬化資源管理技術打破了實體結構之間的障礙,為海量信息存儲提供便利。總之,信息化已經全面滲透到人們生活和工作的方方面面,而信息技術的發展又為信息化實現提供了新手段、新模式,也對信息繫統的設計提出了新的要求。前言
目前信息化已然成為企業經營管理的趨勢,也成為人們日常生活、學習、工作的重要組成部分。從技術層面來看,通信技術、遙感和傳感技術以及移動終端技術的發展為信息化提供了豐富的數據來源和采集手段,為大數據分析與應用奠定了良好的基礎;並行計算的應用則提升了大數據分析和各類信息處理的效率;瀏覽器/服務器模式使信息繫統應用和開發具有了跨平臺、跨地域的特點;大容量存儲技術、虛擬化資源管理技術打破了實體結構之間的障礙,為海量信息存儲提供便利。總之,信息化已經全面滲透到人們生活和工作的方方面面,而信息技術的發展又為信息化實現提供了新手段、新模式,也對信息繫統的設計提出了新的要求。
信息技術的發展方式已從過去的技術驅動轉變為應用創新與技術驅動相結合的方式。雲計算、大數據分析、海量存儲、移動智能終端技術的應用無不凸顯信息資源的開發與利用的重要作用。信息化與工業化的高度融合使得信息繫統的規模越來越大、功能越來越復雜,為了適應需求的變化、適應操作方式的變化、適應信息技術的變化,必須有一套行之有效的方法指導和支持大型復雜信息繫統的開發。事實上,為了解決信息化過程中出現的各種問題,人們在信息繫統開發方法的研究方面不斷探索。在信息繫統功能分析與設計方法方面,從面向過程的開發演變為面向對像的開發;在繫統功能結構方面,由單層、雙層結構演變為多層架構,而這種多層架構又體現在操作頁面、功能建模、數據存取等多個角度;在信息的組織與存儲方面,在利用成熟和標準化的關繫數據庫基礎上,探討新型的NoSQL數據庫,同時研究構建多維數據庫模型;在對開發模型的研究方面,由基於過程的瀑布模型演變為過程模型與以面向對像為主導思想的迭代模型相融合的開發模型,同時引入測試驅動、敏捷式開發等開發思想與方法;在對開發過程的管理方面,由CMM演變為更加靈活、實用的CMMI,並依此管理整個信息繫統開發過程。信息繫統開發從理論到實踐都發生了巨大變化,支持信息繫統開發的工具與開發語言也在不斷地變化。
信息繫統開發方法隨信息技術發展的變化，使得編寫一本既能夠保留經過時間檢驗而驗證有效的傳統理論,又能夠融合新觀點、新方法的信息繫統開發教材變得非常困難。本書致力於開發方法的研究,力求與時俱進,在保留和完善既有知識體繫的基礎上適量增加新的內容,融合新的觀點和方法而調整原有的內容。在整個開發過程中堅持“以數據為中心”的觀點並注重繫統的整體觀,自頂向下地進行開發工作。在總體規劃中,仍然以業務流程再造思想來構建業務模型,再用主題數據庫思想對信息進行整合,以解決“信息孤島”的問題。在隨後的需求分析和繫統分析的前期階段保留了面向過程的思想,從業務流程分析入手尋找信息繫統的功能需求和數據存儲需求,運用數據庫設計的基本理論和信息分類方法指導構建信息繫統的多維數據模型,運用面向對像的分析與設計方法構建信息繫統的功能結構。多維數據模型能夠為信息資源的開發與利用奠定良好的基礎,而采用面向對像方法所建立的良好的功能結構能夠很好地保證信息繫統功能的可修改性、可擴充性、可復用性和可移植性。為減小信息繫統功能與需求之間的偏差,本書在繫統分析階段便引入測試驅動的思想,在分析階段采用黑盒方法進行測試數據的設計,在繫統設計階段采用白盒方法進行測試數據的設計,利用測試數據強化功能需求並對信息繫統的功能進行檢驗。在管理信息繫統開發過程方面,繼續使用CMM/CMMI進行開發過程的管理和控制。因此,本書面向培養專業技術和管理技能的信息專業人纔,適合作為高校信息類、計算機類專業課教材。
本書共分7章,首先介紹信息繫統開發的基本概念、基本思想和基本原則,其次介紹信息繫統開發過程的管理,後以信息繫統的開發階段為基礎,分章節介紹信息繫統總體規劃、業務流程及功能需求分析、信息繫統分析、信息繫統設計、繫統測試與運行維護等開發階段的工作內容、開發方法及相應的工作成果。本書第1～4章內容由陳佳和徐斌共同完成;第5、6章內容由谷銳完成;第7章內容由陳佳完成。書中附帶的開發文檔、課件由陳佳、谷銳、徐斌共同完成。
因作者水平所限,書中難免存在疏漏和不妥,敬請讀者不吝賜教，批評指正。

作者
2018年10月

在線試讀

第5章繫統分析建模
繫統分析是在需求分析的基礎上,對繫統要素進行綜合分析並找出解決問題的可行方案的方法,它的基礎是需求調查所形成的文檔資料。本章以教學管理繫統為例,根據獲取的用例和收集的文檔資料,圍繞功能和數據兩條主線,運用面向對像分析方法和數據庫設計技術進行過程建模、數據建模和功能建模,形成繫統邏輯模型。
5.1繫統分析概述
繫統分析階段的核心工作是通過對需求的理解和詳細分析,確定未來的新繫統應該以什麼方式和手段實現並滿足需求分析中所提出的功能要求。本節主要論述繫統分析的任務、工作產品和特點,以便從總體上把握繫統分析階段的工作的要點。
5.1.1繫統分析任務及步驟
在繫統分析階段要求繫統分析員詳細了解每一個業務過程和業務活動的工作流程及信息處理流程,理解管理者(用戶)的需求,然後運用信息繫統開發理論、開發方法和開發技術確定繫統應具有的邏輯功能,再用適當的方法表達出來,即信息繫統分析建模,形成繫統的邏輯方案,這個方案不但要能夠充分反映用戶的信息需求並和用戶達成一致的意見,而且要能夠使繫統設計員和程序員由此設計、開發出一個計算機信息繫統。
繫統分析階段是繫統詳細開發的關鍵性階段,是確保每個子繫統在服從全局的前提下,實現具體功能的重要基礎,其關鍵在於“理解”和“表達”。“理解”是開發人員對繫統需求的理解,既要充分理解用戶能夠明確表達出來的需求,也要善於通過分析挖掘用戶沒有明確表達出來的需求,同時還要善於對一些需求進行修正以使繫統高於用戶的期望值。“表達”的目的有兩個: 一是把繫統分析員對繫統的理解通過邏輯模型表達出來,讓用戶檢查,確定繫統分析員“理解”的正確性;二是表達出邏輯模型一定要成為下一階段的工作基礎和依據。因此“表達”的關鍵是用什麼樣的工具描述對繫統的理解,一方面使得用戶能夠看懂,能夠與繫統分析員共同討論和修改,另一方面又要使得繫統設計員和程序員能夠正確理解,保證開發出的繫統終能夠符合用戶的需求。
繫統分析過程遵循以下工作步驟。
(1) 對需求分析結果做深入分析形成過程模型。
需求分析階段形成的以數據流程圖來描述的過程模型和以用例圖形式描述的用例模型是站在用戶的角度來定義未來繫統應該具有哪些業務功能,有哪些信息需要存儲在數據庫中,同時也概要說明了對繫統性能、安全性、可靠性方面的要求,但是根據這些文檔資料還不足以支持後續的開發,必須對需求分析的結果做進一步的分析,分析內容包括以下4點。第5章繫統分析建模
繫統分析是在需求分析的基礎上,對繫統要素進行綜合分析並找出解決問題的可行方案的方法,它的基礎是需求調查所形成的文檔資料。本章以教學管理繫統為例,根據獲取的用例和收集的文檔資料,圍繞功能和數據兩條主線,運用面向對像分析方法和數據庫設計技術進行過程建模、數據建模和功能建模,形成繫統邏輯模型。
5.1繫統分析概述
繫統分析階段的核心工作是通過對需求的理解和詳細分析,確定未來的新繫統應該以什麼方式和手段實現並滿足需求分析中所提出的功能要求。本節主要論述繫統分析的任務、工作產品和特點,以便從總體上把握繫統分析階段的工作的要點。
5.1.1繫統分析任務及步驟
在繫統分析階段要求繫統分析員詳細了解每一個業務過程和業務活動的工作流程及信息處理流程,理解管理者(用戶)的需求,然後運用信息繫統開發理論、開發方法和開發技術確定繫統應具有的邏輯功能,再用適當的方法表達出來,即信息繫統分析建模,形成繫統的邏輯方案,這個方案不但要能夠充分反映用戶的信息需求並和用戶達成一致的意見,而且要能夠使繫統設計員和程序員由此設計、開發出一個計算機信息繫統。
繫統分析階段是繫統詳細開發的關鍵性階段,是確保每個子繫統在服從全局的前提下,實現具體功能的重要基礎,其關鍵在於“理解”和“表達”。“理解”是開發人員對繫統需求的理解,既要充分理解用戶能夠明確表達出來的需求,也要善於通過分析挖掘用戶沒有明確表達出來的需求,同時還要善於對一些需求進行修正以使繫統高於用戶的期望值。“表達”的目的有兩個: 一是把繫統分析員對繫統的理解通過邏輯模型表達出來,讓用戶檢查,確定繫統分析員“理解”的正確性;二是表達出邏輯模型一定要成為下一階段的工作基礎和依據。因此“表達”的關鍵是用什麼樣的工具描述對繫統的理解,一方面使得用戶能夠看懂,能夠與繫統分析員共同討論和修改,另一方面又要使得繫統設計員和程序員能夠正確理解,保證開發出的繫統終能夠符合用戶的需求。
繫統分析過程遵循以下工作步驟。
(1) 對需求分析結果做深入分析形成過程模型。
需求分析階段形成的以數據流程圖來描述的過程模型和以用例圖形式描述的用例模型是站在用戶的角度來定義未來繫統應該具有哪些業務功能,有哪些信息需要存儲在數據庫中,同時也概要說明了對繫統性能、安全性、可靠性方面的要求,但是根據這些文檔資料還不足以支持後續的開發,必須對需求分析的結果做進一步的分析,分析內容包括以下4點。
① 繫統的功能要求。功能要求既包括需求分析中提出的功能需求,也包括分析後新增加的一些功能要求。
② 繫統性能要求。結合需求分析的結果,對未來繫統在性能方面,如聯機繫統的響應時間、繫統需要的存儲容量以及後援存儲、重新啟動和安全性等方面進行深入的分析。
③ 運行要求。這類要求集中表現在對繫統運行及所處環境的要求。如用戶希望使用哪種數據庫管理繫統,需要什麼樣的存儲器等。
④ 將來可能的需求。這類需求是指目前不屬於繫統開發的範疇,但繫統分析員根據以往的經驗和對未來的判斷,提出的一些新的功能,這部分功能應該高於用戶的期望值,而使繫統具有先進性和前瞻性。
(2) 數據分析,建立數據庫邏輯模型。
在過程模型基礎上,按照總體規劃中提出的主題數據庫模型,運用數據庫設計技術,對數據流程中所涉及的主題數據庫進行詳細的邏輯設計,並根據繫統的實際需求建立繫統內的一些專用數據庫,然後建立或進一步完善數據字典。
(3) 進行功能分析構建用例模型。
以面向對像的思想為指導,對需求分析階段形成的用例模型做詳細分析和設計,使繫統具有復用性、可修改性,滿足用戶需求並適應未來的發展和變化。在用例模型分析中仍使用結構式語言、判斷樹、判斷表、活動圖、狀態圖等工具對用例進行描述,其結果既要能夠有利於溝通、協商並獲得確認,同時也便於指導後續的開發工作。
(4) 建立類分析模型。
依據用例模型和對用例模型的詳細描述,確定每個用例所包含的對像,分析用例的時序,然後將時序分析結果轉化為類分析模型。
(5) 整理各項文檔資料,並提出繫統分析總結報告。
5.1.2繫統分析的工作產品
繫統分析以需求調查的工作文檔為基礎,進行過程建模、數據建模、時序分析和構建類分析模型等工作,實現分析建模階段的工作目標。各工作步驟及工作產品如圖51所示。
1. 繫統建模
繫統建模包括兩部分模型,一個是過程模型,另一個是用例模型。需求分析階段形成的業務流程圖表達了用戶的功能需求、流程及信息交換關繫,是站在用戶角度來看繫統,每項業務功能應該如何實現還需做進一步分析,通過分析調整和補充一些用戶沒有提及的功能需求,用數據流程圖表達出來。數據流程圖表達了功能與數據庫基本表之間的關繫,反映了數據的變換流程,因此數據流程圖是繫統的過程模型。結合需求分析階段的功能描述和情景描述板建立以用例圖為主,活動圖、狀態圖為詳細說明的用例模型,用例模型反映了每個具體功能(用例)的活動情況及狀態。繫統分析階段建立的用例模型使用UML工具來描述。Unified Modeling Language(UML)稱為統一建模語言或標準建模語言,該語言支持模型化和軟件繫統開發的圖形化,目前面向對像的分析和設計都使用這種語言來描述。2. 數據建模
在信息繫統中,數據被存儲在數據庫中,如何在數據庫中建立一個穩定的、結構合理的數據結構,是繫統分析階段要完成的工作之一。數據庫的邏輯結構描述了繫統需要建立的基本表、基本表的結構以及每個基本表中應該包含的屬性,終的數據庫邏輯結構是運用數據庫設計方法對基本表的結構進行優化設計而形成的。數據模型的表達方式是ER圖(實體聯繫圖),可以利用ERwin、PowerDesigner等數據建模工具構建數據庫的邏輯模型和物理模型。
3. 確定對像、時序分析
在繫統多層架構思想指導下,針對每個用例,分析尋找其中的頁面對像、業務邏輯對像和數據處理對像,表達在時序圖中。對像之間的聯繫依靠的是消息機制,對像之間的聯繫可以通過活動圖、狀態圖、用例說明中所描述的動作序列得到,動作序列有一定的時序關繫,因此利用時序圖可以表達對像、對像之間傳遞的消息以及消息之間的時序關繫。
4. 構建類分析模型
類分析模型即類模型,是繫統分析和設計的核心,繫統分析階段構建的類模型是繫統的初始結構方案,在時序分析基礎上,將時序圖中的對像映射成類,將對像之間傳遞的消息映射成方法,即可形成類模型。對類模型所表達的初始方案所做的優化設計,則在繫統設計階段以迭代方式完成。
5.1.3繫統分析的特點
繫統分析階段的特點體現在以下4個方面。
(1) 用畫圖的方法,直觀且容易理解。
不用煩瑣的語言來描述,而是用畫圖的方式,簡單明確地表達這個繫統的現行狀態,使用戶能夠從這些圖中直觀地了解繫統的概貌和工作流程,這樣可以避免用語言描述所帶來的理解上的偏差,保證繫統分析員能夠正確理解繫統和需求,繫統分析員在理解的基礎上所產生的各種模型仍然是用圖形工具來描述,也方便用戶理解新繫統的概況及邏輯功能,提出修正意見。另外作為繫統設計員來說,他也能夠直接根據這些圖形進行繫統設計,並保證設計的正確性。因此圖形工具是繫統分析員和用戶、繫統分析員和繫統設計員之間的“通信手段”。
(2) “自頂向下”的工作原則。
采用“自頂向下”的工作原則,把一個復雜的繫統由粗到細、由表及裡地分析、認識,符合人類的認識規律,是信息繫統開發過程中一直倡導的工作原則。運用這一原則使用戶和繫統分析員不但對繫統有一個總的概念性印像,而且隨著逐級向下地擴展,對那些具體的、局部的組成部分也有深刻的理解,繫統分析員能夠很快地了解現行繫統並提出新繫統的邏輯結構,用戶也能夠對此進行評審,提出修改意見。相應地，還可以運用這一原則進行繫統設計工作。
(3) 強調邏輯結構而不是物理實現。
繫統分析階段的主要任務是確定新繫統能夠實現用戶提出的哪些需求,能夠達到什麼目標,至於用哪種計算機、用什麼技術、怎麼去實現等問題不是繫統分析階段所要解決的。這樣做的優點在於繫統分析員在分析階段可以不用過多地考慮具體的實現細節,而把精力放在邏輯功能的確定上,首先確保設計基礎是正確的,進而纔能保證未來繫統的正確性。
(4) 避免重復工作。
繫統分析資料一方面可以用來與用戶進行交流,另一方面用來進行繫統設計,這就大大增強了繫統開發的一致性。正確而規範的文檔資料又可以提高繫統的可修改性,當然它並不能保證繫統分析不出錯。實際上繫統分析階段中的分析過程也是文檔資料的編制過程,繫統分析員在編制文檔資料的過程中要相當仔細,盡量避免出現錯誤,特別是邏輯上的錯誤或矛盾。一旦發現錯誤就要及時更正,不要把錯誤帶到下一階段的開發工作中。
5.2繫統建模
根據需求分析的結果進行詳細的功能分析,采用的工作路線是“自底向上”,從底層的功能需求開始,考慮在信息繫統中為實現功能需求,還需要存儲哪些信息和增加哪些業務功能,分析結果用過程模型(即數據流程圖)來描述,然後再進行用例模型的設計,以使信息繫統具有可復用性、可修改性。
5.2.1文檔規範〖*2〗1. 數據流程圖繪制標準用數據流程圖來描述業務分析結果,其制作規範要求如圖52所示。
圖52數據流程圖圖例
(1) 外部實體。
外部實體指不受繫統控制,在繫統以外的事物或人,它表達了數據處理的外部來源和去處。一般用一個正方形並在其上方和左上方各加一條線來表示。正方形內部要標明外部實體的名稱,為了避免在數據流程圖中出現線條交叉,同一個外部實體可以在一張圖中出現若干次。
(2) 數據流。
數據流表明了數據的流動方向及其名稱,是數據載體的表現形式之一。一般用一個帶有箭頭的直線來表示,箭頭指出了數據的流動方向。數據流的名稱即數據載體的名稱一般寫在數據流的上方,其名稱一定是名詞而不能出現動詞。數據流可以來自或流向一個外部實體,表明有信息從外部進入繫統或繫統要向外部輸出信息;數據流可以來自數據存儲或流向數據存儲,表明有信息要存入數據庫中或要從數據庫中檢索信息,在這種情況下,在數據流上可以沒有名稱,表明數據流程方向的箭頭可以是雙向的;數據流也可以來自某一個業務功能或流向業務功能,表明經過業務功能產生了某些信息或為了完成某項功能需要輸入某些信息。值得注意的是除了與數據存儲相關的數據流之外,數據流中的箭頭隻采用單箭頭來表示。
(3) 數據存儲。
數據存儲用來指明數據保存的地方。這裡所說的“地方”不是指數據保存的物理地點或物理存儲介質,而是指數據存儲的邏輯描述,實際上就是數據庫的邏輯描述。數據存儲必須有名稱和標識,其名稱要適當並且必須是名詞。為了便於區別和定義,為每個數據存儲定義的標識一般用D或DB開始,後面是英文字符或數字。同外部實體一樣,為了避免在一張數據流程圖中出現線條的交叉,同一個數據存儲可以出現若干次。
(4) 業務功能。
如果將數據流比喻成工廠中的零部件的傳送帶,數據存儲是零部件的存儲倉庫,那麼每一道加工工序就相當於數據流程圖中的業務功能,它表達了對數據如何處理的業務邏輯,業務功能符號由三部分組成: 標識部分、功能描述部分和功能完成人(角色)。標識部分用數字表示,用於地標識出這個業務功能以及它所在的管理層次,標識的定義與業務流程圖一樣。功能描述部分要求用一句簡單的祈使句來直接表示這個業務功能所要完成的事情,祈使句中至少要有一個動詞和名詞,寫在長方形的中間位置。這部分的描述中沒有主語,主語在功能完成人(角色)部分描述。
數據流程圖的制作範例如圖53所示。
圖53數據流程圖繪制範例
2. 用例模型描述規範
(1) 用例。
用例(Use Case)是在不展現繫統內部結構的情況下,對繫統功能的定義和描述。可以把用例理解為要完成一件事情,而要完成這件事情就需要做一繫列的活動,做這些活動時可以采用不同的辦法和步驟。用戶要做一件事情,這件事情用用例描述出來,但是完成這件事情所需要的一繫列活動、辦法和步驟並沒有在用例上體現出來。
用例來自於用戶對繫統所期望的功能需求,它反映用戶要完成一件事情,信息繫統能夠如何幫助用戶完成這件事情。所以,用例描述了繫統在響應來自某個參與者(Actor)的請求時的各種操作行為,參與者則是與繫統交互的人或物。用例的命名可以是一個簡單的祈使句,其中包含有動詞和該動詞的賓語,說明繫統將要做什麼,它以業務功能為基礎,抽取在信息繫統上將要實現的功能。
(2) 用例模型。
用例模型由用例和參與者(又稱角色)組成,其中值得注意的是用戶和參與者的概念有所不同,一個用戶可以在繫統中扮演多個角色,角色是繫統行為主體。
用例模型通過用例圖來描述,用例模型回答了每個角色執行哪些功能,這些功能內部包含了哪些行為,這些行為的執行序列是什麼,這些行為序列對哪些數據做什麼處理等。因此,用例模型描述了繫統的功能需求,信息繫統的開發以實現用例為目標。
(3) 用例圖基本符號。
本書使用Rational Rose工具繪制用例圖,Rational Rose是Rational公司推出的一種面向對像的統一建模語言的可視化建模工具,不同的建模工具所產生的用例圖在形式上略有差別,但表述的內容完全一致。用例圖的基本符號(圖例)如圖54所示。
圖54用例圖基本符號
用例(Use Case): 用橢圓圖形表示,每個用例代表一個功能。用例的名稱寫在橢圓圖形下面。
參與者(Actor): 參與者用線條化的人形表示,即角色。角色是一個比較抽像的概念,對角色的理解參照某場話劇演出,劇情中有若干角色,但具體到某一場次的演出中,某個角色可能會由不同的人來扮演,無論是誰,隻要扮演的是同一個角色,那麼他的臺詞、動作等都是一樣的。角色可以與管理中的崗位相聯繫,崗位相對穩定,而具體的人是相對流動的,一個人(用戶)在某個崗位上,就要承擔這個崗位的職責,一旦這個人調離了這個崗位,那麼他就不再承擔這個崗位的職責,但這個崗位還在,這個崗位的職責一定會有另外一個人(用戶)來承擔。因此,在具體執行時,角色是被分配到具體的某個人(用戶)來實現的。角色在繫統中是比較穩定的,而用戶(即繫統的操作人員)則是角色的實例。用角色的概念來描述業務功能完成人，可幫助建立一個相對穩定的繫統。
單向關聯(Unidirectional Association): 參與者和用例是通過單向關聯符號連接的,不帶箭頭的一端是參與者,帶有箭頭的一端指向用例,表示某個參與者啟動某個用例。
擴展(Extend): 表示用例和用例之間的關繫,擴展關繫描述一個用例擴展使用另外一個用例。
包含(Include): 表示用例和用例之間的關繫,包含關繫表示的是某個用例中包含使用另外一個用例。
用例圖示例如圖55所示。
圖55用例圖示例
圖55構建了一個用例模型,它描述了三個參與者與三個用例之間的關繫,其中F2用例有兩個參與者,它表明F2可以被A1和A3驅動,也就是說,A1和A3擁有對F2功能的操作權限,同時圖55還說明繫統將實現三個功能。
(4) 用例之間的擴展關繫和包含關繫。
圖55中的用例模型僅包含參與者和用例之間的關繫,在實際的需求分析中,必要時還需要描述用例和用例之間的關繫。用例間常用的關繫是擴展關繫和包含關繫,如圖56所示。
圖56用例間的關繫
學籍管理員可發起(執行)“學生基本信息管理”,教務處負責人發起(執行)“查詢學生基本信息”功能,但值得注意的是,他們在操作功能之前都必須先通過身份認證,沒有經過身份認證的繫統勢必會被認為是一個不安全的繫統。因此,“身份認證”功能被抽取為公共功能,作為被包含的用例而存在,如圖56所示,在用例間的包含關繫中,帶有箭頭的一端是被包含用例,不帶箭頭的一端是包含用例,被包含用例描述了多個用例中的共同的行為。
當學校對院繫進行機構調整後,學籍管理員需要對學生基本信息進行相應地修改,這種修改被命名為“修改學生所在學院”,由於機構調整並不是經常性的,因此這項功能可在信息修改完畢後從繫統中移除,因此可以將“修改學生所在學院”看作是學生基本信息管理用例的擴展。被擴展用例是“學生基本信息管理”,而擴展用例是“修改學生所在學院”,如圖56所示,在兩個用例圖例之間畫一個擴展關繫,帶有箭頭的一端是被擴展用例,不帶箭頭的一端是擴展用例。被擴展用例運行時,不要求擴展用例也同時運行,也就是說擴展用例隻有在特定情況下纔執行,通常情況下不是必需的,當擴展用例被刪除或者是用新的擴展用例來取代時,被擴展用例不會受到影響。
注意擴展關繫和包含關繫的區別: 如果意圖是對某個完整的用例進行擴充,那麼可以使用擴展關繫;如果意圖是將兩個或兩個以上用例所包含的共同行為分解為單個用例,那麼使用包含關繫。擴展用例可以在不需要時方便地取消,而包含用例則必須執行,不能被隨意取消。擴展用例和包含用例的產生是為了便於繫統的復用和修改,這也說明了在需求分析階段就應該適當地考慮軟件的復用性和可修改性問題。
3. 功能(用例)描述標準
業務流程圖、數據流程圖、用例模型是用圖形方式描述業務操作流程和操作功能,但對操作功能的細節無法在圖中做詳細說明,為此可使用UML工具中的活動圖、狀態圖以及結構式語言、判斷樹、判斷表來進行描述。
5.2.2詳細的功能分析及過程建模〖*2〗1. “教學計劃管理”功能分析分析圖45所描述的教學計劃管理,教工1根據實際情況制定和通知培養計劃修訂日程這兩項業務(標識為3.1.1和3.1.2)屬於工作通知範疇,在與教工1進行溝通協商後確定這兩項業務可以在另外一個被稱為“辦公自動化繫統”中的“通知”功能實現,故可將這兩項業務從教學管理繫統中除去。同理,標識為3.1.6的制定評估日程也可通過“辦公自動化繫統”實現,也從教學管理繫統中除去。
從圖45中可以觀察出培養計劃要在經過錄入、初審、終審三個環節(標識為3.1.3、3.1.4和3.1.5)後再組織計劃評估(標識為3.1.7),“組織計劃評估”是由多人參與的討論會,參加人員有各專業秘書、院繫教工和教務處的教工1,這項工作屬於會議形式的群體決策,無法通過教務管理繫統來實現,可將這項業務從教學管理繫統中除去,由教工1根據會議結果“整理評估後的培養計劃”(標識為3.1.8),“整理評估後的培養計劃”實際上完成的是對培養計劃的修改,其修改的依據是評估結果,如果初始的專業培養計劃已經存在於數據庫中,那麼教學管理繫統可為教工1提供“修改培養計劃”功能。完成培養計劃的修改形成的終結果可通過“頒布培養計劃”(標識為3.1.9)的操作打印出紙質培養計劃書發給各院繫。從教學秘書錄入培養計劃直至打印紙質培養計劃書,整個教學計劃管理流程以培養計劃數據為核心,需要圍繞培養計劃進行數據庫的邏輯設計,建立培養計劃主題庫。
對圖45所描述的教學計劃管理中部分業務的詳細討論如下。
(1) 對“專業培養計劃錄入”的討論。
輸入專業培養計劃的功能由專業秘書來完成,在前期需求調查中得知,專業秘書實際上是由各專業的教師兼任的,全校有多少個專業便會有多少個專業秘書,並且專業秘書的上級主管並不是教務處,而是學校下屬的各院繫。如果教學管理繫統的定位在為教務處的管理業務提供支持,管理方式由分層級的分散管理方式變為集中管理方式,那麼專業秘書實質上是不受教學管理繫統所管理的“外部項”,滿足這項功能需求的好方式是提供網上的信息錄入功能。值得注意的是,在實際操作過程中,隻提供輸入功能是不夠的,因為當發現輸入中有錯誤數據時,就必須由修改或刪除功能來支持對錯誤數據的修正。因此,可將“專業培養計劃錄入”更名為“專業培養計劃管理”,並提供新增、刪除、修改和查詢功能,其中,新增、刪除、修改和查詢功能的權限僅限於專業秘書所屬專業的培養計劃,對其他專業的培養計劃信息無操作權限。
(2) 對“修改專業培養計劃”的討論。
修改專業培養計劃的功能由教務處的教工1這個角色來完成,這就意味著教工1要根據各專業培養計劃協調後的結果,對全校專業培養計劃進行修改。為使修改操作方便、快捷,首先需要提供查詢功能,然後再提供修改功能,查詢的權限是全校各專業培養計劃。另外,修改專業培養計劃操作的前提是專業秘書將專業培養計劃信息輸入並提交完畢。
(3) 對“審核專業培養計劃”和“打印專業培養計劃”的討論。
審核專業培養計劃由主管處長來完成,其前提是教工1完成了“修改專業培養計劃”並提交修改後的結果。審核過程需要留下審核意見,終的審核結論可以用“通過”“繼續修改”字樣來表達。另外,需要研究的一個功能是,審核過程中是否允許主管處長對發現的問題進行修改,如果允許修改,則同樣要在審核功能中提供查詢和修改功能,否則為不允許修改,處於“繼續修改”狀態的專業培養計劃,將返回給教工1,由教工1在“修改專業培養計劃”功能中完成。如果審核僅提出意見,不允許修改,那麼勢必增加了人員之間的溝通成本。為此,在與用戶(主管處長和教工1)溝通後確認審核功能中增加查詢和修改功能。
審核工作完畢,即每個專業的專業培養計劃所處的狀態均為“通過”,則可以進入打印程序,即“通過”狀態是打印功能的前提。對打印的方式要進行詳細的分析,通常有很多方式來實現,考慮到每個專業都應該獲得一份終審核通過的專業培養計劃,故應該提供按專業打印培養計劃的功能,至於打印的格式可與用戶進行協商,確定後的打印格式。
“教學計劃管理”業務流程的分析結果用數據流程圖來描述如圖57所示,其中的功能描述標識被重新定義,每項功能都由某一具體角色來完成並體現在功能描述符號的下方。
圖57“教學計劃管理”數據流程圖
2. “排課處理”功能分析
從圖47所示的業務流程圖中可以看出,“計算機排課”功能(標識為3.3.10.1)的輸入信息是“全校教學任務分配表”,這個信息必須存儲在數據庫中,命名這個數據庫為“教師任課信息”庫。但是僅有教學任務分配信息還不足以支持實現計算機排課功能,經過詳細地調查和確認,可以很明確地知道排課還必須有教室信息,並且教室信息也必須存儲在數據庫中。將教室信息存儲在數據庫中引發了一個新的功能——“教室基本信息管理”,也就是說,

商品搜索

商品分类

【醫學】

【各大出版社】