軟件工程(ruǎnjiànɡōnɡchénɡ)初步主編：賈長云副主編：朱敏陸衛忠主審：陳金水

高等教育出版社2004年第一頁，共三百六十八頁。電子(diànzǐ)教案制作人員鄔天菊賈長云朱敏第二頁，共三百六十八頁。內容摘要本書為配合國家技能型緊缺人才培養培訓工程并根據《計算機應用和軟件專業領域技能型緊缺人才培養培訓指導方案》的要求而編寫。本書針對(zhēnduì)職業院校學生的特點，充分體現《指導方案》中素質為基礎、能力為本位、需求為依據、就業為導向的基本原則，教學內容注重選擇當前軟件工程中的一些新理論、新方法與新技術，通過一個小型軟件項目為案例貫穿全書，使學生在學完后能基本掌握軟件工程的基本理論與方法在軟件項目開發中的實際應用。其主要內容涉及軟件工程中的軟件策劃、需求分析、軟件設計、編碼實現、軟件測試及實施與維護等方面的內容，考慮職業院校學生的就業定位，重點側重于詳細設計、軟件編碼、軟件測試、軟件維護這幾個方面的基本知識與技能。為保持教學內容的先進性同時便于對教學進行科學靈活的組織，對諸如UML方法、面向對象的分析、設計與編程、面向對象軟件測試、CMM等也作了介紹。本書可以作為職業院校計算機類專業的軟件工程課程的教材或教學參考書，也可作為IT行業程序員、測試員、維護員等的培訓教材或參考書。第三頁，共三百六十八頁。主要(zhǔyào)內容第1章軟件工程(ruǎnjiànɡōnɡchénɡ)概述第2章系統(xìtǒng)策劃第3章需求分析第4章軟件設計第5章編碼第6章軟件測試第7章軟件實施與維護第8章軟件項目管理第9章軟件過程管理第四頁，共三百六十八頁。第一章軟件工程(ruǎnjiànɡōnɡchénɡ)概述第五頁，共三百六十八頁。本章(běnzhānɡ)主要內容1.1軟件(ruǎnjiàn)與軟件(ruǎnjiàn)工程1.2軟件生存周期(zhōuqī)與開發模型1.3軟件工程過程1.4軟件開發工具簡介1.5學習指南第六頁，共三百六十八頁。11軟件(ruǎnjiàn)及軟件(ruǎnjiàn)工程—軟件(ruǎnjiàn)軟件(ruǎnjiàn)的定義在運行中能提供所希望的功能與性能的程序(chéngxù)

使程序能夠正確運行的數據及其結構描述軟件研制過程和方法所用的文檔

軟件的特點軟件角色的雙重性軟件不是傳統意義上的被制造軟件不會“磨損”，但會退化軟件都是手工定制的開發過程的復雜與費用的昂貴第七頁，共三百六十八頁。11軟件(ruǎnjiàn)及軟件(ruǎnjiàn)工程—軟件(ruǎnjiàn)軟件(ruǎnjiàn)的分類分類方法軟件類型按功能(1)系統軟件(2)支撐軟件

(3)應用軟件按版權(1)商業軟件(2)共享軟件

(3)自由(免費)軟件(4)公有領域軟件按工作方式(1)實時軟件(2)分時軟件(3)交互式軟件(4)批處理軟件按銷售方式(1)訂制軟件(2)產品軟件第八頁，共三百六十八頁。11軟件(ruǎnjiàn)及軟件(ruǎnjiàn)工程—軟件(ruǎnjiàn)工程軟件(ruǎnjiàn)危機軟件開發的生產率遠遠不能滿足客觀需要

開發的軟件產品往往不能滿足用戶的實際需要

軟件產品的質量低下(dīxià)且可維護性差

很難估計軟件開發的進度計劃與成本

軟件神話有了軟件開發書籍，就可以解決軟件開發中的一切問題進度滯后了？好，增加程序員只要程序正確，項目就成功，文檔可有可無軟件質量只能在正式投入運行后才知道第九頁，共三百六十八頁。11軟件(ruǎnjiàn)及軟件(ruǎnjiàn)工程—軟件(ruǎnjiàn)工程軟件工程(ruǎnjiànɡōnɡchénɡ)的定義IEEE定義：軟件工程是將系統化的、嚴格約束的、可量化的方法應用于軟件的開發、運行和維護，即將工程化應用于軟件。通俗地說，軟件工程是指導軟件開發和維護的一門工程學科。它采用(cǎiyòng)工程的概念、原理、技術和方法，把經過時間檢驗而證明是正確的管理技術和當前能夠得到的最好的技術方法結合起來，用于開發和維護軟件。

第十頁，共三百六十八頁。質量焦點11軟件(ruǎnjiàn)及軟件(ruǎnjiàn)工程—軟件(ruǎnjiàn)工程軟件工程(ruǎnjiànɡōnɡchénɡ)—層次化技術過程方法軟件工程三個要素：方法、工具(gōngjù)、過程工具第十一頁，共三百六十八頁。11軟件(ruǎnjiàn)及軟件(ruǎnjiàn)工程—軟件(ruǎnjiàn)工程軟件工程(ruǎnjiànɡōnɡchénɡ)的作用【成功案例(ànlì)】美國聯邦速遞公司(FedEX)的管理信息系統

【失敗案例】英國倫敦的急救服務管理信息系統

軟件工程的基本原理用分階段的生存周期計劃嚴格管理

堅持進行階段評審

實行嚴格的產品控制

采用現代程序設計技術

結果應能清楚地審查

開發小組的人員應該少而精

承認不斷改進軟件工程實踐的必要性

80:20原則第十二頁，共三百六十八頁。12軟件生存周期與開發(kāifā)模型—生存周期軟件(ruǎnjiàn)生存周期人的生存(shēngcún)周期嬰兒——幼兒——兒童——少年——青年——中年——老年——死亡

軟件的生存周期軟件定義軟件開發軟件支持問題定義可行性分析需求分析概要設計詳細設計編碼測試軟件發布軟件運行維護或退役第十三頁，共三百六十八頁。12軟件生存周期(zhōuqī)與開發模型—生存周期(zhōuqī)軟件定義(dìngyì)階段問題定義可行性分析(fēnxī)立項或簽訂合同軟件開發階段需求分析軟件設計編碼與測試發布或安裝驗收軟件開發階段軟件的使用、運行軟件維護第十四頁，共三百六十八頁。12軟件生存(shēngcún)周期與開發模型—開發模型問題的提出—軟件工程需要(xūyào)解決什么問題？軟件開發模型(móxíng)做什么軟件？怎么做軟件？軟件如何適應變化？軟件開發過程概括，是軟件工程思想的具體化它是跨越整個軟件生存周期的各個階段所需要的全部工作與任務的結構框架

第十五頁，共三百六十八頁。12軟件生存周期(zhōuqī)與開發模型—開發模型瀑布(pùbù)模型—線性順序模型可行性分析(fēnxī)需求分析設計編碼測試支持定義階段開發階段支持階段第十六頁，共三百六十八頁。12軟件(ruǎnjiàn)生存周期與開發模型—開發模型瀑布模型(móxíng)的特點：瀑布(pùbù)模型的應用范圍階段間具有順序性和依賴性每個階段必須完成規定的文檔;每個階段結束前完成文檔審查,及早改正錯誤,但：開發過程一般不能逆轉，否則代價太大。實際的項目開發很難嚴格按該模型進行。客戶往往很難清楚地給出所有的需求，而該模型卻要求如此。軟件的實際情況必須到項目開發的后期客戶才能看到，這要求客戶有足夠的耐心。用戶的需求非常清楚全面，且在開發過程中沒有或很少變化

開發人員對軟件的應用領域很熟悉。用戶的使用環境非常穩定。開發工作對用戶參與的要求很低

第十七頁，共三百六十八頁。12軟件生存周期(zhōuqī)與開發模型—開發模型原型(yuánxíng)模型用戶測試(cèshì)運行原型建造/修改原型聽取用戶意見第十八頁，共三百六十八頁。12軟件生存周期與開發(kāifā)模型—開發(kāifā)模型原型模型(móxíng)的特點：原型(yuánxíng)模型的應用范圍可以得到比較良好的需求定義，容易適應需求的變化。有利于開發與培訓的同步。開發費用低、開發周期短、維護容易且對用戶更友好。客戶與開發者對原型理解不同準確的原型設計比較困難不利于開發人員的創新對所開發的領域比較熟悉而且有快速的原型開發工具項目招投標時，可以以原型模型作為軟件的開發模型進行產品移植或升級時，或對已有產品原型進行客戶化工作時，原型模型是非常適合的。

第十九頁，共三百六十八頁。12軟件生存周期(zhōuqī)與開發模型—開發模型基于構件的開發(kāifā)模型特點(tèdiǎn)：屬于演化式開發或迭代式開發，其開發過程：客戶的交流，獲得問題的定義標識基本類計劃與風險分析類的復用或重新開發構造系統用戶評估采用了先進的面向對象技術。

基于構件庫的開發，這是軟件復用的基礎，開發速度快。

融合了螺旋模型特征支持軟件開發的迭代方法，是一種演化型的開發技術。

第二十頁，共三百六十八頁。13軟件工程(ruǎnjiànɡōnɡchénɡ)過程軟件工程(ruǎnjiànɡōnɡchénɡ)過程的概念ISO9000過程(guòchéng)：軟件工程的三要素之一從開發到維護軟件相關產品所采取一系列管理活動。主要包括項目管理、配置管理、質量管理、文檔管理等。IS09001：設計、開發、生產、安裝和服務的質量保證模式

IS09002：生產、安裝和服務的質量保證模式IS09003：最終檢驗和試驗的質量保證模式。

第二十一頁，共三百六十八頁。13軟件工程(ruǎnjiànɡōnɡchénɡ)過程CMM軟件(ruǎnjiàn)能力成熟度模型

CMM(CapabilityMaturityModel)CMM的級別(jíbié)初始級Initial可重復級Repeatable已定義級Defined已管理級Managed優化級Optimizing第二十二頁，共三百六十八頁。開發工具的作用(zuòyòng)與功能14軟件(ruǎnjiàn)開發工具簡介—CASE工具計算機輔助軟件工程(ruǎnjiànɡōnɡchénɡ)

CASE作用認識與描述系統需求

保存與管理開發過程中的信息

代碼的生成

文檔的編制與生成

軟件項目的管理第二十三頁，共三百六十八頁。開發工具的分類(fēnlèi)14軟件開發工具簡介(jiǎnjiè)—CASE工具分類(fēnlèi)方法按應用階段劃分

按功能劃分設計工具分析工具項目管理軟件配置質量保證分析設計計劃工具界面開發客戶服務器Web開發第二十四頁，共三百六十八頁。IBMRational工具(gōngjù)14軟件(ruǎnjiàn)開發工具簡介—常用CASE工具Rational公司是專門從事CASE工具研制與開發的軟件公司，2003年被IBM公司收購。該公司所研發(yánfā)的Rational系列軟件是完整的CASE集成工具，貫穿從需求分析到軟件維護的整個軟件生存周期。需求分析與設計工具產品主要構成測試工具軟件配置管理工具RosePurifyPlusRobotClearCase第二十五頁，共三百六十八頁。北大青鳥(qīnɡniǎo)工具14軟件(ruǎnjiàn)開發工具簡介—常用CASE工具北大青鳥系列CASE工具北京北大青鳥軟件有限公司(yǒuxiànɡōnɡsī)開發研制的，在國內有較高的知名度，北京大學軟件工程國家工程研究中心就設在該公司。產品主要構成面向對象軟件開發工具集

JBOO構件庫管理系統

JBCLMS項目管理與質量保證

JBCMJBPMJBCCM軟件測試系統Safepro第二十六頁，共三百六十八頁。微軟版本(bǎnběn)管理器—VSS14軟件開發工具簡介—常用(chánɡyònɡ)CASE工具版本管理是軟件配置管理中的核心工作，由Microsoft公司開發的VisualSourceSafe6.0使用非常廣泛而且(érqiě)很容易獲得。文件檢入與檢出產品主要功能版本控制

文件的拆分與共享權限管理第二十七頁，共三百六十八頁。本書案例介紹—教師教學網絡(wǎngluò)測評系統15學習(xuéxí)指南—學習(xuéxí)案例為實現教學質量的量化考核，借此評價教師的教學水平并有針對性的提高教學質量，某高校開發了基于校園網的教學質量網上測評系統四大功能模塊數據采集模塊，學生對一個學期中所學課程的各任課教師的教學水平及師德兩個方面給予的百分制評價分值數據統計模塊，根據教務處規定的統計方法統計出每位任課教師在一個學期中的教學水平及師德的最終測評得分。數據查詢模塊，查詢全校任課教師的最終得分及名次，還能夠查詢各個班級的學生對任課教師的教學水平及師德的評分情況。輔助(fǔzhù)功能模塊，包括基礎數據的管理、測評類型的管理等。

第二十八頁，共三百六十八頁。本書案例介紹—教師(jiàoshī)教學網絡測評系統15學習(xuéxí)指南—學習(xuéxí)案例系統(xìtǒng)運行界面—瀏覽器端：第二十九頁，共三百六十八頁。本書案例介紹—教師(jiàoshī)教學網絡測評系統15學習(xuéxí)指南—學習(xuéxí)案例系統運行(yùnxíng)界面—服務器端：第三十頁，共三百六十八頁。第二章系統策劃第三十一頁，共三百六十八頁。這個項目(xiàngmù)是做還是不做呢？還是(háishi)先去做一下市場調研或與客戶談談簽約的事吧！第三十二頁，共三百六十八頁。2.1可行性研究2.2軟件項目(xiàngmù)計劃本章(běnzhānɡ)主要內容第三十三頁，共三百六十八頁。21可行性研究問題(wèntí)的定義問題(wèntí)定義確定軟件開發項目必須完成的目標。其關鍵問題是：“要解決(jiějué)什么問題？”含義主要內容問題的背景、總體要求與目標、類型范圍、功能規模、實現目標的方案、開發的條件、環境要求等問題定義報告應包括內容

項目名稱

使用方對問題的概括定義項目的目標項目的規模第三十四頁，共三百六十八頁。21可行性研究問題(wèntí)的定義案例(ànlì)分析某校在校生近5000人，每學期在期中都要進行一次對教師的教學質量測評，要求所有學生都要參加。以前測評的方式都是手工操作，由教務處發出書面問卷調查表，每個同學填寫完成后交回到教務處。然后教務處再使用手工的方法對問卷進行統計匯總，最后得出學生對每一位教師的總體評價。這種方法一方面浪費了大量的財力、人力，另一方面統計繁瑣且容易出錯。考慮到現在學校校園網已經(yǐjing)建成，為節省開支，提高效率，學校決定委托計算機系開發一套基于校園網的《教師教學網絡測評系統》

1、問題的提出第三十五頁，共三百六十八頁。21可行性研究問題(wèntí)的定義案例(ànlì)分析2、問題(wèntí)分析系統分析人員經過與學校教務部門及各相關單位進行充分的調查后，了解了該項目的一些背景資料與基本要求。教師測評分兩大部分，一是師德測評；二是教學質量測評。師德測評有4項指標，教學質量測評有14項指標。系統要實現的目標是：?所有學生在指定時間內在指定機房的計算機上完成對任課教師的測評打分，測評過程全部采用選擇的方法，不需要輸入任何信息

?所有的測評數據保存在學校中心服務器上，有較為嚴格的安全措施

?系統能對所有的數據進行統計匯總，得出每一位教師的測評結果，并能進行排序、輸出。

……系統開發的大體費用在1.2萬元左右，開發周期大約6個人月。

第三十六頁，共三百六十八頁。21可行性研究問題(wèntí)的定義案例(ànlì)分析3、系統(xìtǒng)定義報告根據以上分析，形成如下的系統定義報告。

案例文檔之一——系統定義報告用戶單位：XX學校教務處負責人：XXX開發單位：XX學校計算機系分析員：XXX項目名稱：基于校園網的教學質量測評系統問題概述：教師教學質量測評每學期必須進行一次，原有的手工方法存在資源浪費、效率極低、結果不準確等問題。……(其它的相關說明)項目目標：開發一個效率高且相對通用的教師教學網絡測評系統。項目規模：開發成本大約1.2萬元，開發周期約6個人月。可行性研究：建議進行一周，費用不超過500元。第三十七頁，共三百六十八頁。21可行性研究可行性研究的任務(rènwu)與步驟一、可行性研究的任務(rènwu)

2、經濟可行性

3、社會(shèhuì)因素的考慮分析成本——收益與短期效益——長遠利益這兩個方面。要作出投資的估算和系統投入運行后可能獲得的經濟效益或可節約的費用估算。分析利用現有的技術能否實現，能否解決系統中的技術難題，所開發的系統能否達到所要求的功能和性能，系統對技術人員的要求，現有的技術人員能否勝任，開發所需要的軟件與硬件能否如期得到等

1、技術可行性

主要考慮的是市場、政策與法律方面的問題

第三十八頁，共三百六十八頁。21可行性研究可行性研究的任務(rènwu)與步驟二、可行性研究的步驟(bùzhòu)1、重新檢查系統定義報告中相關內容，明確對目標(mùbiāo)系統限制與約束。

2、研究目前正在使用的系統，找出其基本功能和所需要的基本信息，繪制系統流程圖。

3、設想新系統高層邏輯模型，分析歸納現有系統，最后建造新物理系統。

4、導出各種實現方案并對方案進行評價

5、推薦可行性方案6、編寫可行性研究報告第三十九頁，共三百六十八頁。21可行性研究技術(jìshù)可行性分析技術可行性分析(fēnxī)的三個方面

1、在給定的時間內能否實現系統定義(dìngyì)中的功能。2、軟件的質量如何？如實時性、正確性和精確性。3、軟件的生產率如何？高生產率意味著利潤。做得了嗎？做得好嗎？做得快嗎？

先分析第四十頁，共三百六十八頁。21可行性研究技術(jìshù)可行性分析在進行技術可行性分析時，一個重要的內容是對現有系統與擬開發的系統繪制系統流程圖。系統流程圖中所用的符號與程序設計語言(yǔyán)中的程序流程圖所用的符號類似。但系統流程圖與程序流程圖不同，系統流程圖表達的是信息在系統中各個部件之間的流動情況，而程序流程圖表達的是程序對信息進行加工處理的控制過程

系統(xìtǒng)流程圖第四十一頁，共三百六十八頁。21可行性研究技術(jìshù)可行性分析符

號名稱含

義處理能改變數據或數據位置的加工或部件輸入/輸出廣義的不指明具體設備的輸入與輸出連接在同一頁上指明轉到圖的另一部分或從圖的另一部分轉來換頁連接指轉到另一頁或從另一頁轉來數據流連接其他符號，指明數據的流動方向文檔通常表示打印輸出系統(xìtǒng)流程圖中的常用符號

第四十二頁，共三百六十八頁。系統(xìtǒng)流程圖中的常用符號

21可行性研究技術(jìshù)可行性分析聯機存儲任何種類的聯機存儲磁盤磁盤的輸入/輸出，也表示存儲在磁盤上的數據庫或文件人工輸入在脫機情況下人工輸入數據，如填寫表格人工操作人工完成的操作，如在表格上的簽名通信鏈路通過通信鏈路傳送數據第四十三頁，共三百六十八頁。測評數據庫測評設置測評人員管理人員數據處理數據提交驗證驗證測評測評結果教師(jiàoshī)教學網絡測評系統流程圖

21可行性研究技術(jìshù)可行性分析第四十四頁，共三百六十八頁。21可行性研究經濟可行性分析(fēnxī)

經濟(jīngjì)可行性分析

1.成本(chéngběn)分析

2.收益分析辦公成本

人員成本資源成本其它成本貨幣的時間價值純收入

如果從經濟可行性的角度分析得出純收入小于或等于零的結論，則這個項目是不能投資的

最難準確核算

純收入=總收入折現-總成本折現P=F(1+i)-n

稱為折現第四十五頁，共三百六十八頁。21可行性研究經濟可行性分析(fēnxī)

常用成本(chéngběn)估算策略1、在項目后期(hòuqī)進行估算，即完全精確核算2、基于已經完成的類似項目進行估算3、使用相對簡單的分解技術以生成項目成本及工作量的估算4、使用一個或多個經驗模型進行軟件成本及工作量的估算估算不能選擇比較切實可行兩種常用策略第四十六頁，共三百六十八頁。21可行性研究經濟可行性分析(fēnxī)

兩種成本估算(ɡūsuàn)方法代碼(dàimǎ)行法(LOC)功能點法(FP)每行代碼的平均成本乘以程序的行數采用軟件所提供的功能來測量的第四十七頁，共三百六十八頁。21可行性研究案例(ànlì)分析（可行性研究）可行性研究最終生成(shēnɡchénɡ)可行性研究報告案例文檔之二——可行性研究報告1．引言1.1編寫目的本報告分析了《教師教學網絡測評系統》開發的可行性，請院領導審閱并對是否進行該系統的開發做出批示。1.2項目背景建議(jiànyì)進行《教師教學網絡測評系統》的開發。(背景介紹略)我院計算機系具備進行該軟件系統開發的能力并承擔本軟件系統的開發與維護工作。該軟件系統由我院教務處使用。……詳見教材第四十八頁，共三百六十八頁。22軟件(ruǎnjiàn)項目計劃系統(xìtǒng)定義報告

用戶(yònghù)的需求報告

可行性研究報告

項目開發計劃及相關的一些專題計劃

如:測試計劃、質量保證計劃、配置管理計劃、人員培訓計劃、系統安裝計劃

第四十九頁，共三百六十八頁。22軟件(ruǎnjiàn)項目計劃軟件(ruǎnjiàn)項目計劃的主要內容制訂方法軟件(ruǎnjiàn)項目計劃資源(zīyuán)計劃

軟件估算計劃進度安排計劃人力資源

可復用的構件開發環境高層管理人員

項目經理

開發人員客戶、最終用戶軟件/硬件環境

采用任務分解技術對軟件的規模與工作量進行估算，并將總的開發費用分配到開發的各個階段中

軟件規模工作量進度成本進度安排要確定最終的軟件交付日期，并在限定的日期內安排和分配工作量；或者在合理復用各種資源分配工作量的基礎上確定最終交付日期。

其它專題計劃如質量保證計劃、配置管理計劃、里程碑及評審計劃、測試計劃等

第五十頁，共三百六十八頁。22軟件項目(xiàngmù)計劃案例分析（軟件項目(xiàngmù)開發計劃書）案例文檔之三—軟件項目開發(kāifā)計劃書1．引言1.1編寫目的為保證《教師教學網絡測評系統》的開發成功，按期交付使用，特編寫項目開發計劃，請參與開發的人員遵照執行。1.2項目背景(略)1.3定義《教師教學網絡測評系統》以下簡稱《測評系統》。

。。。。。詳見教材(jiàocái)第五十一頁，共三百六十八頁。第三章需求(xūqiú)分析第五十二頁，共三百六十八頁。本章主要(zhǔyào)內容3.1需求分析(fēnxī)概述3.2結構化分析3.3面向對象分析3.4UML概述(ɡàishù)第五十三頁，共三百六十八頁。31需求分析(fēnxī)概述--需求分析的重要性

需求分析是發現、求精、建模、規格說明和復審的過程；需求分析是系統設計(shèjì)的基礎，關系到程的成敗和軟件產品的質量。重要性需求獲取(huòqǔ)困難,原因有三一是用戶需求的動態性(不穩定性)二是需求的模糊性(不準確性)三是需求必須得到用戶的確認，否則毫無意義第五十四頁，共三百六十八頁。31需求分析(fēnxī)概述—需求分析(fēnxī)的任務1、確定對系統的綜合要求：系統界面要求、系統功能要求、系統性能要求、完全性可靠性保密性要求、系統運行(yùnxíng)要求、異常處理要求、將來可能提出的要求、分析系統的數據要求。2、分析系統的數據要求3、異出系統的邏輯模型4、修正項目開發劃5、開發原型系統需求分析(fēnxī)任務第五十五頁，共三百六十八頁。需求工程需求開發需求管理需求獲取需求分析編寫需求文檔需求確認需求工程(gōngchéng)層次分解圖31需求分析概述--需求分析的過程(guòchéng)與方法一、需求分析(fēnxī)過程第五十六頁，共三百六十八頁。需求(xūqiú)獲取用戶(yònghù)概要(gàiyào)信息業務需求功能需求用戶需求非功能性需求可行性報告系統定義報告系統分析員程序員分析調研座談法

調查表法

觀察法31需求分析概述--需求分析的過程與方法第五十七頁，共三百六十八頁。需求(xūqiú)分析獲取數據分析、處理目標邏輯(luójí)模型需求(xūqiú)獲取系統分析員從數據流和數據結構出發，找出系統各元素之間的聯系、接口特征及設計限制、能否滿足功能需求31需求分析概述--需求分析的過程與方法第五十八頁，共三百六十八頁。系統分析員需求(xūqiú)規格說明書編寫(biānxiě)目標系統的基本描述

系統各項需求

系統限制及條件

系統數據(shùjù)定義……需求分析結果需求文檔編寫31需求分析概述--需求分析的過程與方法第五十九頁，共三百六十八頁。評審(pínɡshěn)、驗證的四個方面一致性完整性現實性有效性所有需求(xūqiú)必須一致，不能前、后和相互矛盾說明書應包括(bāokuò)用戶需求的每一方面在現有基礎上可實現必須證明需求有效，能解決用戶提出的問題需求評審與確認31需求分析概述--需求分析的過程與方法第六十頁，共三百六十八頁。31需求(xūqiú)分析概述--需求(xūqiú)分析的過程與方法二、需求(xūqiú)分析的方法分析(fēnxī)方法結構化分析方法面向對象的分析方法面向數據的方法，以數據流為中心。其核心概念包括：進程、數據流、數據存儲、外部實體、數據組和數據元素。有代表性的模擬工具有：數據流圖、數據字典、原始進程規格說明。

面向對象分析以對象及其服務作為建模標準，比較自然，對象也具有相對的穩定性。主要模擬的元素有：對象、類、屬性、關系、方法、消息傳遞、用例等。其主要原理包括分類、繼承、層次、信息隱藏、匯集關系等。第六十一頁，共三百六十八頁。基本(jīběn)思想自頂向下逐層分解(fēnjiě)結構化分析(StructuredAnalysis)它是一種面向數據流的需求(xūqiú)分析方法，適用分析大型數據處理系統，是一種簡單、實用的方法。32結構化分析第六十二頁，共三百六十八頁。軟件系統（S）D1D2D3…Dn問題域DiP1P2P3…Pn問題PjF1F2F3…Fn問題(wèntí)域問題(wèntí)行為(xíngwéi)（功能）對應于軟件子系統對應于子軟件的軟構件對應于軟件子系統32結構化分析自頂向下需求分析模型圖S={D1，D2，D3，…Dn}Di={P1，P2，P3，…Pm}Pj={F1，F2，F3，…Fk}第六十三頁，共三百六十八頁。概念(gàiniàn)是描述數據信息的集合，是對系統中所有數據元素(yuánsù)定義的集合。包含(bāohán)信息數據、控制項、數據存儲或外部實體的主要名稱和別名使用數據和對象的列表、使用對象的方式描述數據或控制內容的符號關于數據類型、預置值、限制等其他補充信息32結構化分析--數據字典一、定義第六十四頁，共三百六十八頁。32結構化分析--數據(shùjù)字典二、數據項的定義(dìngyì)數據三種基本類型順序選擇循環即以確定次序連接兩個或多個分量從兩個或多個可能的元素選取一個即把指定的分量重復零次或多次算符意義=等價于或定義為+連接兩個分量[]或(從方括號內列出的若干個分量中選擇一個),用“|”號分開供選擇分量{}重復(重復花括號內的分量)()可選(圓括號內的分量可有可無)數據(shùjù)字典符號第六十五頁，共三百六十八頁。三、數據字典(zìdiǎn)舉例教師測評(cèpínɡ)系統中,數據字內部分內容測評子項得分={測評子項編號+{子項得分}}學生評測數據={序號+教師姓名+{所任課程}+{測評子項得分}}以測評子項得分為單位(dānwèi)的評測數據記錄={學期+被評對象編號+測評類型編號+評測者區別編號+測評子項名稱+測評子項所得分值}以測評類型得分為單位的評測數據記錄={學期+被評對象編號+測評類型編號+評測者區別編號+本測評類型所得分值}被評對象各測評類型的得分記錄={學期+被評對象編號+測評類型編號+測評類型得分+本測評類型占總分的比率}32結構化分析--數據字典第六十六頁，共三百六十八頁。定義(dìngyì)數據流變換(biànhuàn)數據的處理數據(shùjù)存儲數據的源/宿32結構化分析--數據流圖數據流圖(DFD)是一種圖形化技術，它描繪信息和數據從輸入到輸出的過程中所經受的變換。

符號第六十七頁，共三百六十八頁。數據流圖說明：描繪(miáohuì)“做什么”，不考慮“怎么做”箭頭：數據流圖和程序(chéngxù)圖中用箭頭表示的控制流有本質不同，不能混淆。在數據流圖中應該描繪所有可能的數據流向，而不應該描繪出現某個數據流的條件。處理：處理并不一定是一個程序。一個處理框可以代表一系列程序、單個程序或者程序的一個模塊，也可代表一個人工處理過程，如用戶目視檢查數據正確性。數據存儲：一個數據存儲并不等同于一個文件，它可以表示一個文件、文件的一部分、數據庫的元素或記錄的一部分等；數據可以存儲在磁盤、磁帶、磁鼓、主存、微縮膠片、穿孔卡片及其他任何介質上(包括人腦)。數據存儲和數據流都是數據，僅僅所處的狀態不同。數據存儲是處于靜止狀態的數據，數據流是處于運動中的數據。32結構化分析--數據流圖第六十八頁，共三百六十八頁。32結構化分析--數據流圖教師教學網絡測評系統數據流圖統計查詢學生評測數據提交并存儲以測評子項得分為單位評測數據記錄以測評類型得分為單位評測數據記錄被評對象各測評類型的得分記錄被評對象各測評子項得分記錄以評測類型為單位的測評表案例(ànlì)第六十九頁，共三百六十八頁。狀態轉換圖簡稱狀態圖，描述的是系統的狀態及引系統狀態轉換的事件，可用來表示系統的行為。狀態圖指出了作為特定事件的結果將執行(zhíxíng)哪些動作（如處理數據）。所以說，狀態圖提供了行為建模機制。狀態1do:行為1初始事件狀態2do:行為2事件[條件1]結束事件表示(biǎoshì)從一個狀態到另一個狀態的轉換，箭頭的方向表示(biǎoshì)轉換的方向。表示(biǎoshì)狀態。定義符號狀態圖示例32結構化分析--狀態轉換圖第七十頁，共三百六十八頁。軟件需求規格說明闡述一個軟件系統必須提供的功能和性能以及它所要考慮的限制條件,它不僅是系統測試和用戶文檔的基礎，也是所有(suǒyǒu)子系列項目規劃、設計和編碼的基礎。它應該盡可能完整地描述系統預期的外部行為和用戶可視化行為。除了設計和實現上的限制，軟件需求規格說明不應該包括設計、構造、測試或工程管理的細節。說明(shuōmíng)格式(géshi)見教材32結構化分析--需求規格說明書第七十一頁，共三百六十八頁。33面向對象的分析(fēnxī)面向對象分析方法的核心是利用面向對象的概念和方法為軟件(ruǎnjiàn)需求建造模型。它包含面向對象的圖形語言機制以及用于指導需求分析的面向對象的方法學。本節主要介紹面向對象的概念、面向對象方法及面向對象分析過程。第七十二頁，共三百六十八頁。33面向對象的需求分析(fēnxī)--面向對象的概念面向對象(duìxiàng)＝對象(duìxiàng)＋分類＋繼承＋通信對象(duìxiàng)對象是現實世界中個體或事物的抽象表示，它封裝了特殊的屬性(數據)和行為方法。例如，大型客機可視為對象，它具有位置、速度、顏色、容量等屬性，對于該對象可施行起飛、降落、加速、維修等操作，這些操作將或多或少地改變飛機的屬性值(狀態)。

第七十三頁，共三百六十八頁。類類是具有相同屬性(shǔxìng)和操作的一組相似對象的抽象例如，飛行器類是所有能夠飛行的器械的抽象(如各種飛機、航天器等)，它可以包含位置、速度、顏色等屬性，同時也具有起飛、降落、加速等操作。顯然類是一個(yīɡè)支持繼承的抽象數據類型，而對象就是類的實例。33面向對象的需求分析(fēnxī)--面向對象的概念第七十四頁，共三百六十八頁。實例(shílì)是由某個特定的類所描述(miáoshù)的一個具體的對象例如，圓具有半徑和圓心等屬性，它是一個抽象類，可用circle類來定義，有許多(xǔduō)不同半徑和不同圓心的具體的圓，它們是類的一個個實例。33面向對象的需求分析--面向對象的概念第七十五頁，共三百六十八頁。屬性(shǔxìng)是類或對象中所定義的數據，它是描述客觀世界實體(shítǐ)靜態特征的數據項。當類被實例化而形成具體的對象后，它不僅包含類所具有的一些屬性，而且還有自己所特有的屬性值例如，Circle類中定義的代表圓心坐標、半徑、顏色等的數據成員，就是圓類所具有(jùyǒu)的屬性，當實例一個具體的圓后，其屬性也必然存在，還可能增加一些特殊的屬性。33面向對象的需求分析--面向對象的概念第七十六頁，共三百六十八頁。方法(fāngfǎ)方法是對象所能執行(zhíxíng)的操作，也就是類中所定義的服務。方法描述了對象執行(zhíxíng)操作的算法，響應消息的方法在C++語言中把方法(fāngfǎ)稱為成員函數。例如在圓的對象中可以定義一個方法(fāngfǎ)GetColor()，用來取得圓的顏色。33面向對象的需求分析--面向對象的概念第七十七頁，共三百六十八頁。消息(xiāoxi)就是要求某個對象執行在定義它的那個(nàge)類中所定義的某個操作的規格說明。通常，一個消息由以下三部分組成：

?接收消息的對象；

?消息選擇符即消息名；

?零個或多個變元。例如，MyCircle是一個半徑4cm、圓心位于(100，200)的Circle類，也就是一個實例，當要求它以綠顏色在屏幕上顯示自己時，在C++語言中應該向它發下列消息：MyCircle.Show(GREEN);

其中(qízhōng)，MyCircle是接受消息的對象名，Show是消息選擇符(即消息名)，圓括號內的GREEN是消息的變元。當Mycircle接收到這個消息后，將執行在Circle類中所定義的Show操作。33面向對象的需求分析--面向對象的概念第七十八頁，共三百六十八頁。封裝所謂封裝就是把某個事物包起來，使外界不知道(zhīdào)該事物的具體內容。在面向對象的程序中，把數據和實現操作的代碼集中起來放在對象內部。

*

數據與方法代碼的內部細節對外界隱藏，這樣對其的任何改變可能(kěnéng)引起的副作用只能作用在內部，不會傳播。

*封裝是軟件復用的基礎。*被封裝對象間的接口大大地簡化了，對象之間通過消息聯系它時不再關心對象內部的數據結構，系統的耦合度降低了。

含義(hányì)優點33面向對象的需求分析--面向對象的概念第七十九頁，共三百六十八頁。繼承(jìchéng)含義(hányì)分類(fēnlèi)類之間的繼承關系是現實世界中遺傳關系的直接模擬，它表示類之間的內在聯系以及對屬性和操作的共享，即子類可沿用父類(被繼承)的某些特征。當然也可以具有自己獨有的屬性和操作。

單重繼承

多重繼承子類僅從一個父類繼承屬性和行為，而且子類可以覆蓋父類的部分屬性和方法子類可從多個父類繼承屬性和方法33面向對象的需求分析--面向對象的概念第八十頁，共三百六十八頁。類繼承(jìchéng)實例汽車類轎車類貨車類商用轎車家用轎車汽車是抽象層次較高的概念，在汽車類的基礎上可以分出轎車類與貨車類等，如果再細分，還可在轎車類的基礎上分出商用轎車與家用轎車等。由于商用轎車與家用轎車作為轎車在絕大多數的屬性(shǔxìng)和行為上是一致的，可以把轎車類看成是家用轎車的父類，而家用轎車這個子類繼承了父類所擁有的屬性(shǔxìng)與行為，并在父類的基礎上加入了特殊化的屬性(shǔxìng)與行為而形成了新的類。在類的層次結構中，相對(xiāngduì)上層的是超類(superclass)，相對(xiāngduì)下層的是子類(subclass)

33面向對象的需求分析--面向對象的概念第八十一頁，共三百六十八頁。33面向對象的需求(xūqiú)分析--面向對象方法簡介面向對象方法(fāngfǎ)支持三種基本的活動

識別對象(duìxiàng)和類描述對象和類之間的關系通過描述每個類的功能定義對象的行為。面向對象方法Booch方法：提出面象對象的軟件工程的概念OMT方法：提出面象對象的建模技術方法OOSE方法：用例貫穿于軟件整個開發過程UML在Booch方法、OMT方法和OOSE方法的基礎上推出了統一的建模語言(UML)，1997年被國際對象管理組織(OMG)確定為標準的建模語言第八十二頁，共三百六十八頁。33面向對象的需求(xūqiú)分析--面向對象分析過程面向對象方法實際上是一整套的軟件開發方法，它包括面向對象的分析OOA、面向對象的設計OOD、面向對象的編程OOP、面向對象的測試OOT等，可以看出面向對象方法可以貫穿軟件開發的整個過程。

OOA方法的關鍵，是識別問題域內的對象，并分析它們相互間的關系，最終建立起問題域的簡潔、精確、可理解的正確模型。這是面向對象分析的首要任務

在實際工作中，建模的步驟并不一定嚴格(yángé)按照前面講述的次序進行

第八十三頁，共三百六十八頁。OOA分析(fēnxī)過程分析用戶(yònghù)需求識別(shíbié)類與對象

確定對象的內部特征

識別對象之間的關系

定義主題詞

系統分析員應該深入地理解用戶需求，抽象出目標系統的本質屬性，并用模型準確表示來；另外要向領域專家學習。確定問題域中的類和對象

確定對象的屬性的操作分類關系(一般/特殊)、組成關系(整體/部分)，還有反映對象屬性之間聯系的實例連接、反映對象行為之間依賴關系的消息等

概念上把大型的、復雜的系統包含的內容分解成若干個范疇

33面向對象的需求分析--面向對象分析過程第八十四頁，共三百六十八頁。34UML概述(ɡàishù)1997年UML1.1被對象管理組織OMG確定為標準建模語言是軟件工程領域最重要的、具有劃時代重大意義的事件。UML是一種定義良好、易于表達、功能強大且普遍適用的標準的圖形化建模語言,用它可以簡明、準確地為目標系統建立模型。它融入了軟件工程領域的新思想、新方法和新技術。它的作用域不限于支持面向對象的分析與設計，還支持從需求(xūqiú)分析開始的軟件開發的全過程。第八十五頁，共三百六十八頁。34UML概述(ɡàishù)--UML的結構一、UML中的基本構造(gòuzào)塊——UML建模的積木塊構成UML模型的基本(jīběn)構造塊有三種積木元素或積木組合體,即：

反應的是類與類之間聯系的方法與性質，關系有依賴、關聯、繼承、實現和聚合5種

圖是軟件系統在不同角度上的投影，它是一組元素的表示，包含了事物及其關系的組合。UML有九種圖事物是UML模型中的靜態元素，UML中共有11種不同的事物

事物關系圖第八十六頁，共三百六十八頁。序號事物名稱語義及表示1類就是面向對象方法中的類，用具有上、中、下三部分的矩形表示。2接口一個類或一個構件的服務的操作集，用一個帶有名稱的圓表示。3協作表示多個元素的交互，用一個僅包含名稱的虛線橢圓表示。4用例涉及系統的參與者的一組動作序列(可以是人、設備或其他系統)，用僅包含名稱的實線橢圓表示。5主動類擁有進程或線程的類，用外框線加粗的類表示。6構件物理上可替代的軟部件，用帶有小方框包含名稱的矩形表示7節點一般是網絡中的服務器，用包含名稱的立方體表示。8交互一組對象間的交換消息，用包含操作名的有向線段表示。9狀態機對象或交互在其生存周期內呼應其事件而經歷的狀態序列，用包含名稱的圓角矩形表示。10包UML模型的組織元素，用包含名稱的左上角帶有一個小矩形的大矩形表示。11注釋對UML模型的解釋，用包含注解內容的右上角為折角的矩形表示UML中的“事物(shìwù)”

34UML概述(ɡàishù)--UML的結構第八十七頁，共三百六十八頁。二、UML中的規則(guīzé)——UML建模的“粘合劑”UML中的規則是為了將UML中的構造塊有機地組裝在一起形成一個結構良好的模型而對事物(shìwù)進行描述的語義規則。

5種規則(guīzé)

1、為事物、關系命名的命名規則2、給一個名字以特定含義的范圍規則3、使名字可見或如何使用的可見性規則4、描述事件正確、一致地相互聯系的完整性規則5、描述運行或模擬動態模型含義的執行規則

34UML概述--UML的結構第八十八頁，共三百六十八頁。三、應用于UML的通用機制(jīzhì)——UML模型的圖紙說明為了對UML模型進行進一步的說明(shuōmíng)，同時增強其表達能力，UML提供了4種在整個語言中可以一致應用的“通用機制”，可以認為是對UML模型的圖紙說明(shuōmíng)

四種(sìzhǒnɡ)機制規格說明

修飾通用劃分擴展機制UML圖形每個部分后面的語法語義描述UML表示法中每個元素都有一個基本符號UML構造塊有兩種劃分，即類與對象、接口與實現提高UML語言表達能力，它包含構造型、標記值和約束等3種類型34UML概述--UML的結構第八十九頁，共三百六十八頁。34UML概述(ɡàishù)--UML的圖UML主要用圖來表達模型的內容，而圖又由代表模型元素的圖形符號組成。學會使用UML的圖，是學習、使用統一建模語言UML的關鍵。UML的重要內容可以由下列(xiàliè)五類圖(共9種圖形)UML圖用例圖(Use-casediagram)靜態(jìngtài)圖(Staticdiagram)行為圖(Behaviordiagram)交互圖(Interactivediagram)實現圖(Implementationdiagram)第九十頁，共三百六十八頁。34UML概述(ɡàishù)--UML的應用UML的目標是用面向對象的圖形(túxíng)方式來描述任何類型的系統，因此，具有很寬的應用領域。其中最常用的是建立軟件系統模型，但是它同樣也可以用于描述非計算機軟件的其他系統，如機械系統、商業系統、企業機構或業務過程、處理復雜數據的信息系統、具有實時要求的工業系統或工業過程等。總之，UML是一個通用的標準建模語言，可以為任何具有靜態結構和動態行為的系統建立模型。第九十一頁，共三百六十八頁。UML適用于系統(xìtǒng)開發全過程

需求(xūqiú)分析

分析(fēnxī)

設計編碼測試捕獲用戶的需求、用例建模用UML的邏輯視圖和動態視圖來描述問題域中的基本概念(例如抽象、類和對象等)和機制。類圖描述系統的靜態結構，合作圖、順序圖、活動圖和狀態圖描述系統的動態行為。把分析階段的結果擴展成技術解決方案，加入新的類來定義軟件系統的技術方案細節。設計階段用和分析階段類似的方式使用UML。這個階段的任務是把來自設計階段的類轉換成某種面對象程序語言的代碼(如VB、C++、Java等)UML模型可作為測試階段的依據。單元測試使用類圖和類規格說明；集成測試使用構件圖和合作圖；系統測試使用用例圖來驗證系統的行為34UML概述--UML的應用一、UML的應用領域第九十二頁，共三百六十八頁。二、UML的建模機制(jīzhì)

UML9個模型(móxíng)UML9種圖UML5個視圖(shìtú)業務模型、領域模型、用例模型、分析模型、設計模型、過程模型、部署模型、實現模型、測試模型

用例視圖、設計視圖、進程視圖、實現視圖、實施視圖用例圖、靜態圖（包括類圖、對象圖和包圖）、行為圖（包括狀態圖和活動圖）、交互圖（包括順序圖和協作圖）、實現圖（構件圖和配置圖）34UML概述--UML的應用第九十三頁，共三百六十八頁。靜態(jìngtài)建模動態(dòngtài)建模

反映的是目標(mùbiāo)系統的靜態數據，用例圖、類圖、對象圖、包、構件圖、配置圖等是靜態建模機制，其中尤以用例圖和類圖最為重要。強調的是系統的行為，動態建模所建立的模型或者可以執行，或者表示執行時的時序狀態或交互關系。它包括狀態圖、活動圖、順序圖和合作圖等四個圖形,是標準建模語言UML的動態建模機制。UML建模34UML概述--UML的應用第九十四頁，共三百六十八頁。在UML中可以通過用例圖來構造目標(mùbiāo)系統的用例模型，它通過用例來捕獲用戶需求，通過用例建模,描述對系統感興趣的外部角色及其對系統(用例)的功能要求。它從系統外部觀察系統，而不涉及到技術上如何做這些事。34UML概述--UML中的需求(xūqiú)分析（用例圖的創建）第九十五頁，共三百六十八頁。一、用例模型(móxíng)(Usecasemodel)描述的是外部執行者(Actor)所理解(lǐjiě)的系統功能。用例模型用于需求分析階段。在UML中，一個(yīɡè)用例模型由若干個用例圖描述，用例圖的主要元素是用例和執行者。用例模型是開發者和用戶對需求規格達成的共識用例模型※描述了待開發系統的功能需求；

※它將系統看作黑盒，從外部執行者的角度來理解系統；

※它驅動了需求分析之后各階段的開發工作，影響開發工作的各個階段和UML的各個模型。

用例模型功能34UML概述--UML中的需求分析（用例圖的創建）第九十六頁，共三百六十八頁。二、用例(usecase)一個用例是用戶與計算機之間的一次典型(diǎnxíng)交互過程。在UML中，用例表示為一個橢圓

含義(hányì)

1、用例捕獲某些用戶可見的需求，實現(shíxiàn)一個具體的用戶目標。

2、用例由執行者激活，并提供確切的值給執行者。

3、用例可大可小，但它必須是對一個具體的用戶目標實現的完整描述。

特點34UML概述--UML中的需求分析（用例圖的創建）第九十七頁，共三百六十八頁。舉例(jǔlì)教師(jiàoshī)測評系統用例圖以《測評系統》為例，“一個學生測評某位老師”和“管理員進行測評數據處理”便是(biànshì)兩個典型的用例

測評數據處理學生管理員說明：學生、管理員是執行者34UML概述--UML中的需求分析（用例圖的創建）第九十八頁，共三百六十八頁。三、執行者(Actor)含義(hányì)執行者是指用戶(yònghù)在系統中所扮演的角色。其圖形化的表示是一個小人。

通信聯系不帶箭頭的線段將執行者與用例連接到一起，表示兩者之間交換(jiāohuàn)信息注意盡管執行者在用例圖中是用類似人的圖形來表示的，但執行者未必是人。意義面對一個大系統，要列出用例清單常常是十分困難。這時可先列出執行者清單，再對每個執行者列出它的用例，問題就會變得容易很多34UML概述--UML中的需求分析（用例圖的創建）第九十九頁，共三百六十八頁。四、使用(shǐyòng)和擴展(UseandExtend)擴展(kuòzhǎn)關系當一個用例使用另一個用例時，這兩個(liǎnɡɡè)用例之間就構成了使用關系當一個用例與另一個用例相似，但所做的動作多一些，就可以用到擴展關系

使用關系說明使用和擴展是兩種不同形式的繼承關系34UML概述--UML中的需求分析（用例圖的創建）第一百頁，共三百六十八頁。舉例(jǔlì)例中學位課程的學習(xuéxí)包括課程設計，因此構成了使用關系；學位課程學習(xuéxí)比專業課程學習(xuéxí)有更多的要求，因此構成了擴展關系。課程設計的完成學位課程的學習專業課程的學習《使用》《擴展》34UML概述--UML中的需求(xūqiú)分析（用例圖的創建）第一百零一頁，共三百六十八頁。五、用例模型(móxíng)的獲取步驟(bùzhòu)獲取(huòqǔ)執行者

1、使用系統的主要功能(主要使用者)。

l

2、誰需要系統支持他們的日常工作。

l

3、誰來維護、管理使系統正常工作(輔助使用者)。

4、系統需要操縱哪些硬件。

5、系統需要與哪些其它系統交互，包含其它計算機系統和其它應用程序。

獲取用例l

執行者要求系統提供哪些功能(執行者需要做什么)？

l

執行者需要讀、產生、刪除、修改或存儲的信息有哪些類型。

l

必須提醒執行者的系統事件有哪些？或者執行者必須提醒系統的事件有哪些？怎樣把這些事件表示成用例中的功能？

l

為了完整地描述用例，還需要知道執行者的某些典型功能能否被系統自動實現？

l

系統需要何種輸入輸出？輸入從何處來？輸出到何處？

當前運行系統(也許是一些手工操作而不是計算機系統)的主要問題？

34UML概述--UML中的需求分析（用例圖的創建）第一百零二頁，共三百六十八頁。舉例(jǔlì)教師測評系統(xìtǒng)用例模型34UML概述--UML中的需求分析(fēnxī)（用例圖的創建）第一百零三頁，共三百六十八頁。第四章軟件設計第一百零四頁，共三百六十八頁。本章(běnzhānɡ)內容軟件設計基本概念概要設計詳細(xiángxì)設計面向對象的分析與設計

第一百零五頁，共三百六十八頁。41軟件設計基本概念軟件設計軟件表達方式詳細設計表達概要設計表達軟件結構圖數據流圖流程圖盒圖軟件設計是一個把需求轉換為某種軟件表達方式的過程。基本目標是用比較抽象概括的方式確定目標系統如何完成(wánchéng)預定的任務。

第一百零六頁，共三百六十八頁。41軟件設計基本概念軟件設計工作(gōngzuò)內容概要設計詳細設計

將軟件需求(xūqiú)轉化為軟件體系結構，確定系統級接口、全局數據結構或數據庫模式。

確立每個模塊的實現算法、局部數據結構(shùjùjiéɡòu)，用適當方法表示算法和數據結構(shùjùjiéɡòu)的細節。

第一百零七頁，共三百六十八頁。41軟件設計基本概念軟件模塊(mókuài)定義整個(zhěnggè)軟件被劃分成若干單獨命名和可編址的部分，稱之為模塊。

模塊的基本(jīběn)屬性模塊實現什么功能模塊的內部實現邏輯該模塊使用時的環境和條件第一百零八頁，共三百六十八頁。41軟件設計基本概念模塊(mókuài)劃分的原則劃分模塊的重要目標(mùbiāo)是提高模塊的獨立性。度量模塊獨立性的兩個準則是模塊間的內聚性和耦合性。好的軟件結構應該具有高內聚、低耦合的模塊化結構。

內聚性耦合性內聚性是一個模塊內部各個元素彼此(bǐcǐ)結合的緊密程度的度量。

耦合性是模塊間互相連接的緊密程度的度量。它取決于各個模塊之間接口的復雜度、調用方式以及哪些信息通過接口。

第一百零九頁，共三百六十八頁。41軟件設計基本概念內聚性模塊內聚按照(ànzhào)模塊獨立性由高到低的順序敘述如下：

(1)功能內聚(2)信息內聚(3)通信內聚(4)過程內聚(5)時間(shíjiān)內聚(6)邏輯內聚(7)巧合內聚第一百一十頁，共三百六十八頁。41軟件設計基本概念耦合性(1)非直接耦合(2)數據耦合(3)標記耦合(4)控制(kòngzhì)耦合(5)外部耦合(6)公共耦合(7)內容耦合模塊間的耦合按照(ànzhào)模塊獨立性由高到低的順序列舉如下：

第一百一十一頁，共三百六十八頁。42概要(gàiyào)設計概要設計需要完成(wánchéng)的工作(1)制定規范(guīfàn)(2)軟件系統結構的總體設計(3)處理方式設計(4)數據結構設計(5)可靠性設計(6)編寫概要設計階段的文檔第一百一十二頁，共三百六十八頁。42概要(gàiyào)設計概要設計(shèjì)的目標概要設計的主要(zhǔyào)目標是把需求轉換為軟件的體系結構。

軟件的體系結構程序的模塊結構程序的數據結構第一百一十三頁，共三百六十八頁。42概要(gàiyào)設計設計(shèjì)程序的模塊結構程序的模塊結構表明(biǎomíng)了程序各個部件(模塊)的組織情況，是軟件的過程表示。

第一百一十四頁，共三百六十八頁。42概要(gàiyào)設計模塊間關系(guānxì)的表示結構圖反映程序中模塊間的調用(diàoyòng)關系和模塊間信息的傳遞。結構圖的要素包括：(1)模塊：模塊用矩形框表示，并用模塊的名字標記它。(2)模塊的調用(diàoyòng)關系和接口：模塊之間用單向箭頭聯結，箭頭從調用(diàoyòng)模塊指向被調用(diàoyòng)模塊，表示調用(diàoyòng)模塊調用(diàoyòng)了被調用(diàoyòng)模塊。第一百一十五頁，共三百六十八頁。42概要(gàiyào)設計設計程序(chéngxù)的數據結構(1)確定軟件涉及的文件系統的結構以及數據庫的模式、子模式，進行數據完整性和安全性的設計。(2)確定輸入、輸出文件的詳細的數據結構。(3)結合算法設計，確定算法所必需(bìxū)的邏輯數據結構及其操作。(4)確定對邏輯數據結構所必需的那些操作的程序模塊(軟件包)。(5)限制和確定各個數據設計決策的影響范圍。(6)若需要與操作系統或調度程序接口所必須的控制表等數據時，確定其詳細的數據結構和使用規則。(7)數據的保護性設計

第一百一十六頁，共三百六十八頁。43詳細(xiángxì)設計詳細設計需要(xūyào)完成的工作在詳細設計過程中，需要完成的工作是：(1)確定軟件各個(gègè)組成部分內的算法以及各部分的內部數據組織。(2)選定某種過程的表達形式來描述各種算法。可選用的過程表達形式有：流程圖、盒圖、PAD圖等。(3)編寫詳細設計說明書。(4)制定單元測試計劃。(5)進行詳細設計評審。第一百一十七頁，共三百六十八頁。43詳細(xiángxì)設計詳細(xiángxì)設計的表示詳細設計中應采用合適的方式來描述模塊內問題(wèntí)解決過程的細節，采用結構化的圖形設計表示法是人們易于使用、易于理解的方式。

圖形設計表示法流程圖盒圖PAD圖第一百一十八頁，共三百六十八頁。43詳細(xiángxì)設計程序(chéngxù)流程圖結構化程序基本結構順序結構選擇結構循環結構第一百一十九頁，共三百六十八頁。43詳細(xiángxì)設計標準(biāozhǔn)流程圖符號我國國家標準(ɡuójiābiāozhǔn)局批準的國家標準(ɡuójiābiāozhǔn)(GB1525-89)流程圖符號：第一百二十頁，共三百六十八頁。43詳細(xiángxì)設計標準(biāozhǔn)流程圖示例第一百二十一頁，共三百六十八頁。43詳細(xiángxì)設計盒圖（N-S圖）第一百二十二頁，共三百六十八頁。43詳細(xiángxì)設計面向數據結構(shùjùjiéɡòu)的詳細設計方法

Jackson方法第一百二十三頁，共三百六十八頁。44面向對象的分析(fēnxī)與設計面向對象的分析(fēnxī)與設計步驟使用面向對象的設計方法，同樣需要得出軟件的體系結構。首先，需要將系統劃分為子系統，可以使用包來描述子系統，根據子系統提供的操作定義它們的接口，然后設計子系統的概念模型。對復雜的子系統，可以繼續將其分解(fēnjiě)，得到更簡單的子系統。直到得出子系統內待解決問題域中的類。確定子系統中存在的類及類之間的關系，并定義了子系統的接口及關系后，便完成了系統的靜態建模工作。接下來需要描述待解決問題域中類的動態行為，從而建立問題解決過程的系統動態模型。第一百二十四頁，共三百六十八頁。44面向對象的分析(fēnxī)與設計識別(shíbié)類為了描述(miáoshù)一個軟件系統，識別其中的對象并將其抽象為類是極為關鍵的。識別類和對象的一些好的方法：(1)通過實體-關系模型識別類和對象。(2)基于自然語言信息識別類和對象。(3)基于用例與序列圖識別類和對象。第一百二十五頁，共三百六十八頁。44面向對象的分析(fēnxī)與設計篩選(shāixuǎn)出正確的類篩選(shāixuǎn)時主要依據下列標準，刪除不正確或不必要的類—&—對象。①冗余

如果兩個類表達了同樣的信息，則應該保留在此問題域中最富于描述的類。②無關

現實世界中存在許多對象，不能把它們都納入到系統中去，僅需要把與本問題密切相關的類—&—對象放進目標系統中。有些類在其他問題中可能很重要，但與當前要解決的問題無關，同樣也應該把它們刪掉。第一百二十六頁，共三百六十八頁。44面向對象的分析(fēnxī)與設計篩選(shāixuǎn)出正確的類（續）③籠統

在需求陳述中常常使用一些籠統的、泛指的名詞，雖然在初步分析時把它們作為候選的類—&—對象列出來了，但是，要么系統無須記憶有關它們的信息，要么在需求陳述中有更明確更具體的名詞對應它們所暗指的事務，因此，通常把這些籠統的或模糊(móhu)的類去掉。④屬性

在需求陳述中有些名詞實際上描述的是其他對象的屬性，應該把這些名詞從候選類—&—對象中去掉。當然，如果某個性質具有很強的獨立性，則應把它作為類而不是作為屬性。第一百二十七頁，共三百六十八頁。44面向對象的分析(fēnxī)與設計篩選(shāixuǎn)出正確的類（續）⑤操作

在需求陳述中有時可能使用一些既可作為名詞，又可作為動詞的詞，應該(yīnggāi)慎重考慮它們在本問題中的含義，以便正確地決定把它們作為類還是作為類中定義的操作。⑥實現在分析階段不應該過早地考慮怎樣實現目標系統。因此，應該去掉僅和實現有關的候選的類—&—對象。在設計和實現階段，這些類—&—對象可能是重要的，但在分析階段過早地考慮它們反而會分散我們的注意力。第一百二十八頁，共三百六十八頁。44面向對象的分析(fēnxī)與設計確定(quèdìng)屬性一般來說，確定屬性的過程包括分析和選擇兩個步驟。①分析在需求陳述中用名詞詞組表示屬性，例如，“汽車的顏色”或“光標的位置”。往往用形容詞表示可枚舉(méijǔ)的具體屬性，例如，“紅色的”、“打開的”。但是，不可能在需求陳述中找到所有屬性，分析員還必須藉助于領域知識和常識才能分析得出需要的屬性。②選擇認真考察經初步分析而確定下來的那些屬性，從中刪除不正確的或不必要的屬性。第一百二十九頁，共三百六十八頁。44面向對象的分析(fēnxī)與設計使用(shǐyòng)類圖來描述類類圖通常表示為長方形，長方形又分三個部分，分別用來表示類的名字、屬性(shǔxìng)和操作。第一百三十頁，共三百六十八頁。44面向對象的分析(fēnxī)與設計類圖中類之間的關系及表示(biǎoshì)

普通關聯第一百三十一頁，共三百六十八頁。44面向對象的分析(fēnxī)與設計類圖中類之間的關系及表示

導航(dǎoháng)關聯第一百三十二頁，共三百六十八頁。44面向對象的分析(fēnxī)與設計類圖中類之間的關系及表示

關聯(guānlián)中的角色第一百三十三頁，共三百六十八