軟件工程課件 全

1軟件工程概述2軟件的定義及可行性研究3需求分析4概要設計5詳細設計目錄6面向?qū)ο蟾拍詈蚏ose建模技術(shù)7面向?qū)ο蟮姆治雠c設計8編碼9軟件測試10軟件維護11軟件項目管理1軟件工程概述2軟件的定義及可行性研究3需求分析4概要設計51軟件工程概述第1章教學要求[1]了解軟件的概念、特點及主要分類；[2]掌握軟件危機的產(chǎn)生、表現(xiàn)及原因；[3]掌握軟件工程的定義以及基本原理；[4]掌握軟件生存周期概念；[5]理解軟件開發(fā)模型；[6]了解軟件開發(fā)工具與環(huán)境。軟件工程概述第1章教學[1]了解軟件的概念、特點及主要分類；21.1軟件與軟件危機第1章1．軟件的定義軟件是計算機中與硬件相互依存的另一部分，軟件包括程序、數(shù)據(jù)及其相關(guān)文檔的完整集合。1.1.1軟件的定義及其特點軟件程序數(shù)據(jù)文檔程序是按事先設計的功能和性能要求執(zhí)行的指令序列數(shù)據(jù)是使程序能夠正確地處理信息的數(shù)據(jù)結(jié)構(gòu)文檔是與程序開發(fā)、維護和使用有關(guān)的圖文資料1.1軟件與軟件危機第1章1．軟件的定義1.1.1軟件32.軟件具有下列特點：1.1軟件與軟件危機第1章1.1.1軟件的定義及其特點軟件是邏輯產(chǎn)品生產(chǎn)與硬件不同不會磨損和老化依賴硬件手工開發(fā)為主成本高、風險高比硬件發(fā)展慢2.軟件具有下列特點：1.1軟件與軟件危機第1章1.1.141.軟件技術(shù)的發(fā)展1.1軟件與軟件危機第1章1.1.2軟件的發(fā)展及其分類程序設計程序系統(tǒng)軟件工程1.軟件技術(shù)的發(fā)展1.1軟件與軟件危機第1章1.1.252.軟件的分類1.1軟件與軟件危機第1章1.1.2軟件的發(fā)展及其分類重點掌握2.軟件的分類1.1軟件與軟件危機第1章1.1.2軟件61.軟件危機的主要表現(xiàn)1.1軟件與軟件危機第1章1.1.3軟件危機（1）軟件不能滿足用戶的需求。（2）軟件開發(fā)成本嚴重超標，開發(fā)周期大大超過規(guī)定日期。（3）軟件質(zhì)量難于保證，可靠性差。（4）軟件難于維護。（5）軟件開發(fā)速度跟不上計算機發(fā)展速度。1.軟件危機的主要表現(xiàn)1.1軟件與軟件危機第1章1.1.372.軟件危機產(chǎn)生的原因1.1軟件與軟件危機第1章1.1.3軟件危機（1）忽視軟件開發(fā)前期的調(diào)研和需求分析工作。（2）缺乏軟件開發(fā)的經(jīng)驗和有關(guān)軟件開發(fā)數(shù)據(jù)的積累，使得開發(fā)計劃很難制定。（3）開發(fā)過程缺乏統(tǒng)一的、規(guī)范化的方法論指導。（4）忽視與用戶、開發(fā)組成員間的及時有效的溝通。（5）文檔資料不規(guī)范或不準確。導致開發(fā)者失去工作的基礎，管理者失去管理的依據(jù)。（6）沒有完善的質(zhì)量保證體系。2.軟件危機產(chǎn)生的原因1.1軟件與軟件危機第1章1.1.383.軟件危機解決途徑1.1軟件與軟件危機第1章1.1.3軟件危機要解決軟件危機問題，需要采取以下措施：（1）使用好的軟件開發(fā)技術(shù)和方法。（2）使用好的軟件開發(fā)工具，提高軟件生產(chǎn)率。（3）有良好的組織、嚴密的管理，各方面人員相互配合共同完成任務。為了解決軟件危機，既要有技術(shù)措施（好的方法和工具），也要有組織管理措施。軟件工程正是從技術(shù)和管理兩方面來研究如何更好地開發(fā)和維護計算機軟件的。3.軟件危機解決途徑1.1軟件與軟件危機第1章1.1.39為了克服軟件危機，1968年10月在北大西洋公約組織（NATO）召開的計算機科學會議上，F(xiàn)ritzBauer首次提出“軟件工程”的概念。按工程化的原則和方法組織軟件開發(fā)工作是有效的，是擺脫軟件危機的一條主要出路。軟件工程的主要思想是強調(diào)軟件開發(fā)過程中應用工程化原則的重要性。軟件工程的目標是實現(xiàn)軟件的優(yōu)質(zhì)高產(chǎn)。軟件工程的目的是在經(jīng)費的預算范圍內(nèi)，按期交付出用戶滿意的、質(zhì)量合格的軟件產(chǎn)品。1.2軟件工程第1章1.2.1軟件工程的定義和目標為了克服軟件危機，1968年10月在北大西10著名軟件工程專家Boehm提出。（1）用分階段的軟件生存周期計劃進行嚴格的質(zhì)量管理。（2）堅持進行階段評審。（3）實行嚴格的產(chǎn)品控制。（4）采用現(xiàn)代程序設計技術(shù)。（5）軟件工程結(jié)果應能清楚地審查。（6）開發(fā)小組的人員應該少而精。（7）承認不斷改進軟件工程實踐的必要性。1.2軟件工程第1章1.2.2軟件工程的基本原理著名軟件工程專家Boehm提出。1.2軟111.2軟件工程第1章1.2.3軟件工程的研究內(nèi)容1.2軟件工程第1章1.2.3軟件工程的研究內(nèi)容121.3軟件生存周期第1章可行性研究問題定義需求分析詳細設計總體設計編碼系統(tǒng)測試確認測試集成測試單元測試運行與維護計劃時期開發(fā)時期運行時期時間1.3軟件生存周期第1章可行性研究問題定義需求分析詳細設計總131.4軟件開發(fā)模型第1章1.4.1瀑布模型問題定義可行性研究需求分析軟件設計編碼軟件測試運行維護開發(fā)時期運行時期計劃時期1.4軟件開發(fā)模型第1章1.4.1瀑布模型問題定義可行141.4軟件開發(fā)模型第1章1.4.1瀑布模型瀑布模型的主要優(yōu)點：（1）原理簡單、容易掌握。（2）各階段間都有驗證和確認環(huán)節(jié)，以便進行質(zhì)量管理。（3）主要用于支持結(jié)構(gòu)化方法。瀑布模型的主要缺點：（1）缺乏靈活性，不能適應用戶需求的變化。（2）缺乏演化性，返回上一級的開發(fā)需要付出十分高昂的代價。（3）是線性的軟件開發(fā)模型，回溯性很差。1.4軟件開發(fā)模型第1章1.4.1瀑布模型瀑布模型的主151.4軟件開發(fā)模型第1章1.4.2快速原型模型1.4軟件開發(fā)模型第1章1.4.2快速原型模型161.4軟件開發(fā)模型第1章1.4.2快速原型模型快速原型模型的優(yōu)點：（1）增強了開發(fā)者與用戶間的交流，有助于滿足用戶的真實需求。（2）用戶可及早得到有用的產(chǎn)品，可及早發(fā)現(xiàn)問題，隨時糾正錯誤。（3）減小技術(shù)、應用風險，可降低開發(fā)費用，縮短開發(fā)時間?？焖僭湍Ｐ偷娜秉c：（1）缺乏豐富而強有力的軟件工具和開發(fā)環(huán)境。（2）對設計人員水平及開發(fā)環(huán)境要求較高。（3）在多次重復改變原型的過程中，程序員會厭倦。（4）對于做到徹底測試，更新文檔較為困難。1.4軟件開發(fā)模型第1章1.4.2快速原型模型快速原型171.4軟件開發(fā)模型第1章1.4.3漸增模型1.4軟件開發(fā)模型第1章1.4.3漸增模型181.4軟件開發(fā)模型第1章1.4.3漸增模型漸增模型的優(yōu)點：漸增模型是瀑布模型的一個變體，可以看作是重復執(zhí)行的多個瀑布模型，具有瀑布模型的所有優(yōu)點，此外，還有以下優(yōu)點：（1）可分批次提交軟件產(chǎn)品，方便用戶及時了解軟件開發(fā)進展情況，及早發(fā)現(xiàn)問題。（2）以組件為單位進行開發(fā)，降低了軟件開發(fā)風險。（3）開發(fā)順序靈活。優(yōu)先級最高的服務首先交付。漸增模型的缺點：（1）由于對整個軟件系統(tǒng)的需求沒有一個完整的定義，會給總體設計帶來麻煩。（2）在把每個新的增量構(gòu)件集成到現(xiàn)有軟件結(jié)構(gòu)中時，必須不破壞原來已開發(fā)出的產(chǎn)品。（3）軟件的體系結(jié)構(gòu)必須是開放的，即向現(xiàn)有產(chǎn)品中加入新構(gòu)件的過程必須簡單、方便。每次增量開發(fā)的產(chǎn)品都應當是可測試的、可擴充的。1.4軟件開發(fā)模型第1章1.4.3漸增模型漸增模型的優(yōu)191.4軟件開發(fā)模型第1章1.4.4噴泉模型1.4軟件開發(fā)模型第1章1.4.4噴泉模型201.4軟件開發(fā)模型第1章1.4.4噴泉模型噴泉模型的主要特點：（1）各階段相互重疊，反映了軟件過程的并行性。（2）以分析為基礎，資源消耗呈塔形，在分析階段消耗資源最多。（3）反映了軟件過程迭代的自然特性，從高層返回低層無資源消耗。（4）強調(diào)增量開發(fā)，依據(jù)分析一點、設計一點的原則，不要求一個階段的徹底完成，整個過程是一個迭代的逐步提煉的過程。（5）是對象驅(qū)動的過程，對象是所有活動作用的主體，也是項目管理的基本內(nèi)容。1.4軟件開發(fā)模型第1章1.4.4噴泉模型噴泉模型的主211.4軟件開發(fā)模型第1章1.4.5螺旋模型1.4軟件開發(fā)模型第1章1.4.5螺旋模型221.4軟件開發(fā)模型第1章1.4.5螺旋模型1.4軟件開發(fā)模型第1章1.4.5螺旋模型231.5軟件開發(fā)方法第1章1．結(jié)構(gòu)化方法結(jié)構(gòu)化方法又稱傳統(tǒng)方法、生存周期法、面向過程的方法、面向功能的方法、面向數(shù)據(jù)流的方法。所謂結(jié)構(gòu)化分析，就是根據(jù)分解與抽象的原則，按照系統(tǒng)中數(shù)據(jù)處理的流程，用數(shù)據(jù)流圖來建立系統(tǒng)的功能模型，從而完成需求分析。所謂結(jié)構(gòu)化設計，就是根據(jù)模塊獨立性準則、軟件結(jié)構(gòu)準則，將數(shù)據(jù)流圖轉(zhuǎn)換為軟件的體系結(jié)構(gòu)，用軟件結(jié)構(gòu)圖來建立系統(tǒng)的物理模型，實現(xiàn)系統(tǒng)的總體設計。所謂結(jié)構(gòu)化程序設計，就是根據(jù)結(jié)構(gòu)程序設計原理，將每個模塊的功能用相應的標準控制結(jié)構(gòu)表示出來，從而實現(xiàn)詳細設計。1.5軟件開發(fā)方法第1章1．結(jié)構(gòu)化方法241.5軟件開發(fā)方法第1章2．面向數(shù)據(jù)結(jié)構(gòu)方法面向數(shù)據(jù)結(jié)構(gòu)方法（也稱為Jackson方法）。該方法從目標系統(tǒng)的輸入、輸出數(shù)據(jù)結(jié)構(gòu)入手，導出程序框架結(jié)構(gòu)，再補充其他細節(jié)，就可得到完整的程序結(jié)構(gòu)圖。這一方法以數(shù)據(jù)結(jié)構(gòu)為驅(qū)動，其優(yōu)點是通俗易懂，特別適合信息系統(tǒng)中數(shù)據(jù)層（數(shù)據(jù)庫服務器）上的設計與實現(xiàn)，對輸入、輸出數(shù)據(jù)結(jié)構(gòu)明確的中小型系統(tǒng)特別有效。其缺點是實現(xiàn)窗口界面較困難。該方法也可與其他方法結(jié)合，用于模塊的詳細設計。1.5軟件開發(fā)方法第1章2．面向數(shù)據(jù)結(jié)構(gòu)方法251.5軟件開發(fā)方法第1章3．面向?qū)ο蠓椒嫦驅(qū)ο蠓椒ㄊ且环N自底向上和自頂向下相結(jié)合的方法，該方法把對象作為數(shù)據(jù)和在數(shù)據(jù)上的操作（服務）相結(jié)合的軟件構(gòu)件。用對象分解取代結(jié)構(gòu)化方法的功能分解。把所有對象都劃分成類，把若干個相關(guān)的類組織成具有層次結(jié)構(gòu)的系統(tǒng)，下層的類繼承上層的類所定義的屬性和服務。對象之間通過發(fā)送消息進行聯(lián)系。使用面向?qū)ο蠓椒ㄩ_發(fā)軟件時，可以重復使用對象和類等構(gòu)件，從而降低了軟件開發(fā)成本，所開發(fā)的軟件能適應需求變化，穩(wěn)定性好，可重用性好，可維護性好，對于大型、復雜及交互性比較強的系統(tǒng)，使用面向?qū)ο蠓椒ǜ袃?yōu)勢。1.5軟件開發(fā)方法第1章3．面向?qū)ο蠓椒?61.6軟件工具與開發(fā)環(huán)境第1章1.6.1軟件工具軟件工具是指用來輔助計算機軟件開發(fā)、維護和管理的軟件。按照軟件過程活動可將軟件工具分為支持軟件開發(fā)過程的工具、支持軟件維護過程的工具、支持軟件管理過程與支持過程的工具等。支持軟件開發(fā)過程的工具包括需求分析工具、設計工具、編碼與排錯工具和測試工具等；支持軟件維護過程的工具包括版本控制工具、文檔分析工具、開發(fā)信息庫工具、逆向工程工具和再工程工具等；支持軟件管理與軟件支持的工具包括項目管理工具、配置管理工具和軟件評價工具等。1.6軟件工具與開發(fā)環(huán)境第1章1.6.1軟件工具軟件工271.6軟件工具與開發(fā)環(huán)境第1章1.6.2軟件開發(fā)環(huán)境1．計算機輔助軟件工程計算機輔助軟件工程（ComputerAidedSoftwareEngineering，CASE）將各種軟件工具、開發(fā)機器和一個存放開發(fā)過程信息的工程數(shù)據(jù)庫組合起來形成一個軟件工程環(huán)境。2．集成化CASE環(huán)境集成化開發(fā)環(huán)境（Integrated-CASE，I-CASE）是一種把支持多種軟件開發(fā)方法和過程模型的軟件工具集成到一起的軟件開發(fā)環(huán)境。3．軟件工程環(huán)境軟件工程環(huán)境（SoftwareEngineeringEnvironment，SEE）是指以軟件工程為依據(jù)，支持典型軟件生產(chǎn)的系統(tǒng)。包括三層含義，一組軟件工具的集合；工具按一定方法或模型組織；工具支持整個生存周期各階段或部分階段。1.6軟件工具與開發(fā)環(huán)境第1章1.6.2軟件開發(fā)環(huán)境128軟件的定義及可行性研究第2章本章要點理解問題定義的內(nèi)容與方法；學會書寫問題定義報告；理解可行性研究的任務與步驟；學會書寫可行性研究報告；學會繪制系統(tǒng)流程圖。軟件的定義及可行性研究第2章本章理解問題定義的內(nèi)容與方法；292.1問題定義第2章2.1問題定義第2章30（1）問題的背景，弄清楚待開發(fā)系統(tǒng)現(xiàn)在處于什么狀態(tài)，為什么要開發(fā)它，是否具備開發(fā)條件等問題。（2）提出開發(fā)系統(tǒng)的問題要求以及總體要求。（3）明確問題的性質(zhì)、類型和范圍。（4）明確待開發(fā)系統(tǒng)要實現(xiàn)的目標、功能和規(guī)模。（5）提出開發(fā)的條件要求和環(huán)境要求。以上主要內(nèi)容應寫在問題定義報告（或系統(tǒng)目標和范圍說明書）中，作為這一階段的“工作總結(jié)”。2.1問題定義第2章2.1.1問題定義的內(nèi)容（1）問題的背景，弄清楚待開發(fā)系統(tǒng)現(xiàn)在處于什么狀態(tài)，為什么要31具體步驟如下:首先，系統(tǒng)分析員要針對用戶的要求做詳細的調(diào)查研究，認真聽取用戶對問題的介紹；閱讀與問題有關(guān)的資料，必要時還要深入現(xiàn)場，親自操作；調(diào)查開發(fā)系統(tǒng)的背景；了解用戶對開發(fā)的要求。其次是與用戶反復討論，以使問題進一步確定化。經(jīng)過用戶和系統(tǒng)分析員雙方充分協(xié)商，確定問題定義的內(nèi)容。最后寫出雙方均認可的問題定義報告。2.1問題定義第2章2.1.2問題定義的方法具體步驟如下:2.1問題定義第2章2.1.2問題定義的32可行性研究是在問題定義之后進行的，它是軟件定義時期的第二個階段?？尚行匝芯渴侵冈陧椖窟M行開發(fā)之前，根據(jù)項目發(fā)起文件（或稱項目建議書）和實際情況，對該項目是否能在特定的資源、時間等制約條件下完成做出評估，并且確定該項目是否值得去開發(fā)?？尚行匝芯康哪康牟辉谟谌绾谓鉀Q問題，而在于確定問題“是否能夠解決”和“是否值得解決”。其中的項目發(fā)起文件（或稱項目建議書），是項目發(fā)起時，由發(fā)起人或單位遞交給項目支持者或領導的書面材料，其作用是讓項目支持者或領導明白項目的必要性和可行性。2.2可行性研究第2章可行性研究是在問題定義之后進行的，它是軟件定義時期的第二個階332.2可行性研究第2章1.技術(shù)可行性技術(shù)可行性從技術(shù)的角度去研究系統(tǒng)實現(xiàn)的可行性。主要包括風險、資源和技術(shù)分析。風險分析主要考慮在給定的約束條件下設計和實現(xiàn)系統(tǒng)的風險；資源分析是考慮技術(shù)資源的可行性，也就是參與人員的技術(shù)基礎、基礎硬件與軟件的可用性和軟件工具的實用性；技術(shù)分析是考慮技術(shù)解決方案的實用性，即所使用技術(shù)的實用化程度和技術(shù)解決方案的合理程度。2.經(jīng)濟可行性經(jīng)濟可行性從經(jīng)濟角度評價開發(fā)一個新系統(tǒng)是否可行。主要任務是對軟件開發(fā)項目進行成本估算、效益估算和成本/效益分析，分析實現(xiàn)這個系統(tǒng)有沒有經(jīng)濟效益和社會效益。2.2.1可行性研究的任務2.2可行性研究第2章1.技術(shù)可行性2.2.1可行342.2可行性研究第2章3.運行可行性（或用戶使用可行性）即判斷為新系統(tǒng)規(guī)定的運行方式是否可行。首先要分析用戶類型（如外行型、熟練型或?qū)＜倚停?，然后從操作習慣、使用單位的計算機使用情況和相關(guān)規(guī)章制度等方面進行分析，判斷當系統(tǒng)交付使用后，使用單位是否有能力保證系統(tǒng)的正常運行和使用。4.法律可行性研究新系統(tǒng)的開發(fā)在社會上和政治上會不會引起侵權(quán)和責任問題，如是否違反專利法、著作權(quán)法和軟件保護條例等法律，是否涉及信息安全和個人隱私等問題。2.2.1可行性研究的任務2.2可行性研究第2章3.運行可行性（或用戶使用可行性）352.2可行性研究第2章1.審核系統(tǒng)的規(guī)模和目標2.分析研究現(xiàn)行系統(tǒng)3.設計新系統(tǒng)的高層邏輯模型4.獲得并比較可行的方案5.撰寫可行性研究報告2.2.2可行性研究的步驟2.2可行性研究第2章1.審核系統(tǒng)的規(guī)模和目標2.2.2362.2可行性研究第2章2.2.3系統(tǒng)流程圖2.2可行性研究第2章2.2.3系統(tǒng)流程圖372.2可行性研究第2章在可行性研究過程中，經(jīng)濟可行性研究占有重要地位，它從經(jīng)濟上衡量一個項目是否有開發(fā)價值。經(jīng)濟可行性研究主要包括兩個方面的內(nèi)容：一是新系統(tǒng)成本的估計；二是新系統(tǒng)可能產(chǎn)生的效益。又稱為成本/效益分析。2.2.4經(jīng)濟可行性2.2可行性研究第2章在可行性研究過程中，經(jīng)濟可行性研究382.3可行性研究報告的內(nèi)容及作用第2章可行性研究報告編制中應注意以下幾個方面的問題：（1）堅持實事求是的原則，不要隨意夸大新系統(tǒng)的功能和其他指標。（2）任何一項內(nèi)容的書寫均要以科學分析的結(jié)果為依據(jù)，不能憑空想象。（3）對每一項內(nèi)容的描述必須反復推敲，一定要做到用詞恰當、準確。（4）從具體情況出發(fā)?？尚行匝芯繄蟾娌灰欢婷婢愕?，但對于用戶關(guān)心的部分或項目中重要的部分要重點闡明。（5）書寫形式要規(guī)范。2.3.1可行性研究報告編制中應注意的問題2.3可行性研究報告的內(nèi)容及作用第2章可行性研究報告編392.3可行性研究報告的內(nèi)容及作用第2章可行性研究報告在軟件開發(fā)中起著重要的作用：（1）可行性研究報告是可行性研究階段的成果。（2）可行性研究報告提出了軟件開發(fā)的總體目標和范圍，因此它是軟件開發(fā)的行動指南。（3）可行性研究報告是需求分析的基礎和依據(jù)。2.3.2可行性研究報告在軟件開發(fā)中的作用2.3可行性研究報告的內(nèi)容及作用第2章可行性研究報告在402.4項目開發(fā)計劃第2章經(jīng)過可行性研究后，如果一個項目是值得開發(fā)的，則接下來應制定項目開發(fā)計劃。軟件項目開發(fā)計劃是軟件工程中的一種管理性文檔，主要是對所開發(fā)的軟件項目的費用、時間進度、人員組織、硬件設備的配置、軟件開發(fā)環(huán)境和運行環(huán)境的配置等進行說明和規(guī)劃，是項目管理人員對項目進行管理的依據(jù)，據(jù)此對項目的費用、進度和資源進行控制和管理。項目開發(fā)計劃的目的是提供一個框架，使得主管人員在項目開始后較短時間內(nèi)就可以對資源、成本、進度進行合理的估計，而不必等到詳細的需求分析完成之后。項目開發(fā)計劃有分析和估算兩項任務。分析是對系統(tǒng)內(nèi)各軟件功能界限的劃定，估算是指根據(jù)已有的定性數(shù)據(jù)和以往的經(jīng)驗對系統(tǒng)開發(fā)的資源、費用和進度進行定量的估計。項目復雜性越高、規(guī)模越大，估算的難度就越大，當項目的結(jié)構(gòu)化程度越高且估算人員的經(jīng)驗越豐富時，則估算就更為準確。2.4項目開發(fā)計劃第2章經(jīng)過可行性研究后，如果一個項目是值41需求分析第3章本章要點理解需求分析的任務；熟悉需求分析的步驟；理解結(jié)構(gòu)化需求分析的基本思想；掌握數(shù)據(jù)流圖和數(shù)據(jù)詞典的用法。需求分析第3章本章理解需求分析的任務；423.1需求分析的任務第3章需求分析的任務是要準確地定義新系統(tǒng)的目標，準確回答“系統(tǒng)必須做什么”的問題，并用需求規(guī)格說明書規(guī)范的形式準確地表達用戶的需求。需求分析是理解、分析和表達“系統(tǒng)必須做什么”的過程。雖然在可行性研究階段，對用戶需求有了初步了解，但對需求的了解是概括的、粗略的，許多細節(jié)被忽略了。可行性研究是決定“做還是不做”，而不是對需求進行定義。而需求分析階段則需要充分理解用戶需求，通過分析得出對新系統(tǒng)完整、準確、清晰、具體的要求。需求分析的結(jié)果是否正確，關(guān)系到軟件開發(fā)的成敗和軟件產(chǎn)品的質(zhì)量，正確的需求分析是整個系統(tǒng)開發(fā)的基礎。3.1需求分析的任務第3章需求分析的任務是要準確地定義新系統(tǒng)433.2需求獲取的方法第3章在需求分析過程中，需求獲取階段是開發(fā)人員和用戶交往最多的階段。一般情況下，用戶并不熟悉計算機的相關(guān)知識，更不懂得需求分析方法，所以他們不知道如何全面而又準確無誤地表達自己的需求。而軟件開發(fā)人員對相關(guān)的業(yè)務領域也不甚了解，用戶與開發(fā)人員之間對同一問題理解的差異和習慣用語的不同往往會給需求分析帶來很大困難。所以，開發(fā)人員與用戶之間要進行充分和有效的溝通，需要采取科學的需求獲取方法與技巧，恰當?shù)貑l(fā)引導用戶表達自己的需求，以減少后期重復修改需求的次數(shù)。3.2需求獲取的方法第3章在需求分析過程中，需求獲取階段是開443.2需求獲取的方法第3章1．深入淺出需求獲取要盡可能全面、細致。調(diào)研獲取的需求是個全集，而目標系統(tǒng)真正實現(xiàn)的是個子集。分析時的調(diào)研內(nèi)容并不一定都要納入到新系統(tǒng)中，但全面、細致的調(diào)研既有利于弄清系統(tǒng)全局，又有利于以后的擴充。2．以流程為主線在與用戶交流的過程中，應該用流程將所有的內(nèi)容串起來，如單據(jù)、信息、組織結(jié)構(gòu)和處理規(guī)則等，這樣便于交流溝通。流程的描述既要有宏觀描述，也要有微觀描述。3.2.1需求獲取的基本原則3.2需求獲取的方法第3章1．深入淺出3.2.1需求獲453.2需求獲取的方法第3章1.問卷調(diào)查2.訪談和會議3.市場調(diào)查4.實地操作5.建立原型3.2.2需求獲取的途徑和方法3.2需求獲取的方法第3章1.問卷調(diào)查3.2.2需求獲463.2需求獲取的方法第3章要獲取用戶需求，就需要深入企業(yè)現(xiàn)場調(diào)研，需求調(diào)研的步驟如下：（1）調(diào)研用戶領域的組織結(jié)構(gòu)、崗位設置和職責定義，從功能上區(qū)分有多少個子系統(tǒng)，劃分系統(tǒng)的大致范圍，明確系統(tǒng)的目標。（2）調(diào)研每個子系統(tǒng)所需的工作流程、功能與處理規(guī)則，收集單據(jù)、報表和賬本等原始資料，分析物流、資金流和信息流三者的關(guān)系，以及如何用數(shù)據(jù)流來表示這三者的關(guān)系。（3）對調(diào)研的內(nèi)容事先準備，針對不同管理層次的用戶詢問不同的問題，列出問題清單。將操作層、管理層和決策層的需求既聯(lián)系又區(qū)分開來，形成一個金字塔，使下層滿足上層的需求。（4）對與用戶溝通的情況及時總結(jié)歸納，整理調(diào)研結(jié)果，找出新的疑點，初步構(gòu)成需求基線。（5）若需求基線符合要求，則需求分析完畢；反之返回到前面某一步。如此循環(huán)多次，直到需求分析使雙方滿意為止。3.2.3需求調(diào)研的步驟3.2需求獲取的方法第3章要獲取用戶需求，就需要深入企業(yè)現(xiàn)場473.3需求獲取的步驟第3章3.3需求獲取的步驟第3章483.3需求獲取的步驟第3章此階段的工作是需求獲取、問題識別，即收集并明確用戶需求的過程。首先，系統(tǒng)分析員要研究可行性研究報告和軟件項目實施計劃。主要是從系統(tǒng)的角度來理解軟件，確定對目標系統(tǒng)的綜合要求，即軟件的需求。還要提出這些需求實現(xiàn)的條件，以及需求應達到的標準。也就是解決待開發(fā)系統(tǒng)需要“做什么”，“做到什么程度”的問題。這些需求包括：（1）功能需求：（2）性能需求：（3）環(huán)境需求：（4）可靠性需求：（5）安全保密性需求：（6）用戶界面需求：（7）資源使用需求：（8）軟件成本消耗與開發(fā)進度需求：（9）預計系統(tǒng)可達到的目標：3.3.1需求獲取3.3需求獲取的步驟第3章此階段的工作是需求獲取、問題識別，493.3需求獲取的步驟第3章獲取到需求后，要把來自用戶的信息加以分析，通過“抽象”建立待開發(fā)的系統(tǒng)邏輯模型。模型是為了理解事物而對事物做出的一種抽象，通常由一組符號和組織這些符號的規(guī)則組成。為待開發(fā)系統(tǒng)建立模型，有助于人們更好地理解問題，常用的建模方法有數(shù)據(jù)流圖、實體聯(lián)系圖（E-R圖）、狀態(tài)轉(zhuǎn)換圖、用例圖、類圖、對象圖等。系統(tǒng)分析員根據(jù)目標系統(tǒng)的模型，從信息流和信息結(jié)構(gòu)出發(fā)，逐步細化所有的軟件功能，找出系統(tǒng)各元素之間的聯(lián)系、接口特性和對設計的限制，剔除需求中不合理的成分，增加需要的部分，最終把各項需求組織起來，提交目標系統(tǒng)的詳細邏輯模型。3.3.2分析建模3.3需求獲取的步驟第3章獲取到需求后，要把來自用戶的信息加503.3需求獲取的步驟第3章需求描述就是指編制需求分析階段的文檔。即將已經(jīng)過分析的需求清晰、全面、系統(tǒng)、準確地描述成正式的文檔——軟件需求規(guī)格說明書。軟件需求規(guī)格說明書以開發(fā)人員的角度，對開發(fā)系統(tǒng)的業(yè)務模型、功能模型、數(shù)據(jù)模型等內(nèi)容進行描述，明確地表達了用戶與系統(tǒng)分析員對軟件系統(tǒng)的共同理解，將作為概要設計和詳細設計的基線。對于復雜的軟件系統(tǒng)，此階段除產(chǎn)生軟件需求規(guī)格說明書（稱軟件需求文檔，主要描述軟件部分的需求）外，還要產(chǎn)生系統(tǒng)定義文檔（即用戶需求報告）和系統(tǒng)需求文檔（即系統(tǒng)需求規(guī)格說明書）。3.3.3需求描述3.3需求獲取的步驟第3章需求描述就是指編制需求分析階段的文513.3需求獲取的步驟第3章需求驗證就是驗證（復查）需求分析的成果，也稱綜合評審。需求驗證就是對需求的正確性進行嚴格的驗證，確保需求的一致性、完整性、清晰性、現(xiàn)實性和有效性，確保設計與實現(xiàn)過程中的需求可回溯性，并進行需求變更管理。一般情況下，需求驗證以用戶、系統(tǒng)分析員、系統(tǒng)設計人員和管理人員共同參與的會議形式進行，最后由評審負責人簽字。3.3.4需求驗證3.3需求獲取的步驟第3章需求驗證就是驗證（復查）需求分析的523.4結(jié)構(gòu)化需求分析方法第3章1.分析策略結(jié)構(gòu)化分析（StructuredAnalysis，簡稱SA）方法是20世紀70年代由E·Yourdon等人提出的一種面向數(shù)據(jù)流的分析方法，適用于大型的數(shù)據(jù)處理系統(tǒng)。由于利用圖形來表達需求會使文檔清晰、簡明、易于學習和掌握，所以軟件分析人員仍在廣泛使用這種傳統(tǒng)的分析方法。結(jié)構(gòu)化分析方法總的指導思想是“自頂向下，逐步求精”，它的兩個基本原則是“抽象”和“分解”，即按照功能分解的原則，對系統(tǒng)進行逐層分解，直到找到所有滿足功能要求的可實現(xiàn)軟件元素為止。3.4.1結(jié)構(gòu)化分析方法概述3.4結(jié)構(gòu)化需求分析方法第3章1.分析策略3.4.1結(jié)533.4結(jié)構(gòu)化需求分析方法第3章3.4.1結(jié)構(gòu)化分析方法概述3.4結(jié)構(gòu)化需求分析方法第3章3.4.1結(jié)構(gòu)化分析方法543.4結(jié)構(gòu)化需求分析方法第3章2.描述工具結(jié)構(gòu)化分析方法利用圖形等半形式化的描述表達需求，用它們形成需求規(guī)格說明書的主要部分，主要工具有：（1）數(shù)據(jù)流圖（DFD）。描述系統(tǒng)的分解，即描述系統(tǒng)由哪幾部分組成，各部分之間有什么聯(lián)系等。（2）數(shù)據(jù)詞典（DD）。明確定義數(shù)據(jù)流圖中的數(shù)據(jù)和加工。它是數(shù)據(jù)流條目、數(shù)據(jù)存儲條目、數(shù)據(jù)項條目和基本加工條目的匯集。（3）結(jié)構(gòu)化語言、判定表和判定樹。用于詳細描述數(shù)據(jù)流圖中不能再分解的每一個基本加工的處理邏輯。3.4.1結(jié)構(gòu)化分析方法概述3.4結(jié)構(gòu)化需求分析方法第3章2.描述工具3.4.1結(jié)553.4結(jié)構(gòu)化需求分析方法第3章3.分析步驟3.4.1結(jié)構(gòu)化分析方法概述3.4結(jié)構(gòu)化需求分析方法第3章3.分析步驟3.4.1結(jié)563.4結(jié)構(gòu)化需求分析方法第3章1.數(shù)據(jù)流圖的基本符號3.4.2數(shù)據(jù)流圖3.4結(jié)構(gòu)化需求分析方法第3章1.數(shù)據(jù)流圖的基本符號3.4.573.4結(jié)構(gòu)化需求分析方法第3章2.數(shù)據(jù)流圖的繪制步驟（1）畫頂層數(shù)據(jù)流圖列出系統(tǒng)的全部數(shù)據(jù)源點和終點，將系統(tǒng)加工處理過程作為一個整體，就可能得到頂層圖。具體說就是：畫一個圓，在其中寫上系統(tǒng)名稱，然后在圓的外圍畫上系統(tǒng)的輸入和輸出，這一步工作實際上是決定研究的內(nèi)容和系統(tǒng)的范圍。（2）畫各層數(shù)據(jù)流圖對系統(tǒng)處理過程自頂向下，逐步分解，畫出各層的數(shù)據(jù)流圖。（3）畫總的數(shù)據(jù)流圖這一步對了解整個系統(tǒng)很有好處，但也要根據(jù)實際情況來決定總圖的布局，不要把數(shù)據(jù)流圖畫得太復雜。3.4.2數(shù)據(jù)流圖3.4結(jié)構(gòu)化需求分析方法第3章2.數(shù)據(jù)流圖的繪制步驟3.4.583.4結(jié)構(gòu)化需求分析方法第3章3.數(shù)據(jù)流圖中的命名規(guī)則（1）數(shù)據(jù)流數(shù)據(jù)流表明數(shù)據(jù)和數(shù)據(jù)流向，它通常由一組數(shù)據(jù)項組成。（2）加工加工是對數(shù)據(jù)的某種操作或變換。（3）文件文件起暫時保存數(shù)據(jù)的作用。（4）數(shù)據(jù)源點和終點數(shù)據(jù)源點和終點是數(shù)據(jù)的始發(fā)點和終止點，是軟件系統(tǒng)外部環(huán)境中的實體（包括人員、組織或其他軟件系統(tǒng)），統(tǒng)稱外部實體。3.4.2數(shù)據(jù)流圖3.4結(jié)構(gòu)化需求分析方法第3章3.數(shù)據(jù)流圖中的命名規(guī)則3.4593.4結(jié)構(gòu)化需求分析方法第3章4.數(shù)據(jù)流圖中分層技術(shù)對于比較復雜的實際問題，在數(shù)據(jù)流圖上常常出現(xiàn)十幾個乃至幾十個、上百個加工，這樣的數(shù)據(jù)流圖復雜而且難以理解。為了避免這種情況出現(xiàn)，可以采用數(shù)據(jù)流圖的分層技術(shù)。分層技術(shù)的基本思想是，不是在一個數(shù)據(jù)流圖中一次引入太多的細節(jié)，而是有控制地逐步增加細節(jié)，實現(xiàn)從抽象到具體的逐步過渡。3.4.2數(shù)據(jù)流圖3.4結(jié)構(gòu)化需求分析方法第3章4.數(shù)據(jù)流圖中分層技術(shù)3.4.603.4結(jié)構(gòu)化需求分析方法第3章1.數(shù)據(jù)詞典的內(nèi)容一般說來，數(shù)據(jù)詞典的每個條目中應包括以下信息。（1）名字：數(shù)據(jù)流、數(shù)據(jù)項、數(shù)據(jù)存儲或外部實體的名稱。（2）別名或編號：第（1）項中對象的其他名字。（3）分類：數(shù)據(jù)流、數(shù)據(jù)項、加工、數(shù)據(jù)存儲、外部實體等。（4）內(nèi)容描述：描述內(nèi)容或數(shù)據(jù)結(jié)構(gòu)等。（5）何處使用：哪些加工使用該條目。3.4.3數(shù)據(jù)詞典3.4結(jié)構(gòu)化需求分析方法第3章1.數(shù)據(jù)詞典的內(nèi)容3.4.3613.4結(jié)構(gòu)化需求分析方法第3章2.數(shù)據(jù)詞典中使用的符號3.4.3數(shù)據(jù)詞典3.4結(jié)構(gòu)化需求分析方法第3章2.數(shù)據(jù)詞典中使用的符號3.4623.4結(jié)構(gòu)化需求分析方法第3章3.數(shù)據(jù)詞典書寫實例3.4.3數(shù)據(jù)詞典3.4結(jié)構(gòu)化需求分析方法第3章3.數(shù)據(jù)詞典書寫實例3.4.3633.4結(jié)構(gòu)化需求分析方法第3章3.數(shù)據(jù)詞典書寫實例3.4.3數(shù)據(jù)詞典3.4結(jié)構(gòu)化需求分析方法第3章3.數(shù)據(jù)詞典書寫實例3.4.3643.4結(jié)構(gòu)化需求分析方法第3章3.數(shù)據(jù)詞典書寫實例3.4.3數(shù)據(jù)詞典3.4結(jié)構(gòu)化需求分析方法第3章3.數(shù)據(jù)詞典書寫實例3.4.3653.4結(jié)構(gòu)化需求分析方法第3章4.數(shù)據(jù)詞典的實現(xiàn)通常，實現(xiàn)數(shù)據(jù)詞典有三種途徑：(1)人工方法：人工方法實現(xiàn)時，每一詞典條目（即每一個數(shù)據(jù)定義或每一個加工邏輯說明）寫在一張卡片上，由專人管理和維護。為了便于搜索，所有卡片按數(shù)據(jù)名稱排序。人工方法的優(yōu)點是容易實現(xiàn)。(2)自動方法：把詞典存在計算機中，用計算機對它搜索和維護?，F(xiàn)有多種“詞典管理程序”，如PLS/PSA。用計算機管理詞典質(zhì)量高，搜索、維護方便。(3)人工和自動混合的方法：在人工過程中可借助正文編寫程序、報告生成程序等工具輔助完成。3.4.3數(shù)據(jù)詞典3.4結(jié)構(gòu)化需求分析方法第3章4.數(shù)據(jù)詞典的實現(xiàn)3.4.3663.4結(jié)構(gòu)化需求分析方法第3章4.數(shù)據(jù)詞典的實現(xiàn)不論通過哪種途徑實現(xiàn)的數(shù)據(jù)詞典都應盡量做到以下幾點：(1)沒有冗余：主要指數(shù)據(jù)定義不能重復。在規(guī)格說明書的其他組成部分中已出現(xiàn)的信息不能重復。(2)查閱方便：通過名字可以方便地查閱數(shù)據(jù)詞典中的每個定義。(3)定義的書寫方法簡單、方便、嚴謹，而且可讀性強。(4)建議采用卡片形式書寫。3.4.3數(shù)據(jù)詞典3.4結(jié)構(gòu)化需求分析方法第3章4.數(shù)據(jù)詞典的實現(xiàn)3.4.3673.4結(jié)構(gòu)化需求分析方法第3章1.結(jié)構(gòu)化語言3.4.4加工邏輯的描述3.4結(jié)構(gòu)化需求分析方法第3章1.結(jié)構(gòu)化語言3.4.4683.4結(jié)構(gòu)化需求分析方法第3章2.判定表在一些數(shù)據(jù)處理中，數(shù)據(jù)流圖的加工需要經(jīng)過多個邏輯條件組合的取值而確定，此時用自然語言或結(jié)構(gòu)化語言難以描述，而運用判定表描述就比較清晰明了。3.4.4加工邏輯的描述3.4結(jié)構(gòu)化需求分析方法第3章2.判定表3.4.4加693.4結(jié)構(gòu)化需求分析方法第3章3.判定樹判定樹也是用來表達加工邏輯的工具，它是判定表的變形，有時比判定表更直觀，更易于理解和使用。圖書優(yōu)惠政策的判定樹如圖3-8所示。3.4.4加工邏輯的描述3.4結(jié)構(gòu)化需求分析方法第3章3.判定樹3.4.4加703.5需求規(guī)格說明書的編寫與評審第3章1．需求規(guī)格說明書的編寫內(nèi)容需求分析階段應交付的主要文檔是軟件需求規(guī)格說明書。它提供了用戶與開發(fā)人員對開發(fā)軟件的共同理解，其作用相當于用戶與開發(fā)單位之間的技術(shù)合同，是后續(xù)設計和編碼的基礎，是測試和驗收的依據(jù)。軟件需求規(guī)格說明書的內(nèi)容框架可參閱GB/T8567-2006《計算機軟件文檔編制規(guī)范》。在編寫需求規(guī)格說明書時應注意以下幾個問題：（1）說明書中的每一部分都非常重要，因此要慎重對待。（2）問題的描述要做到準確無誤，沒有二義性。（3）說明書的書寫形式要規(guī)范。（4）允許用戶根據(jù)項目的具體情況適當?shù)膶鴮憙?nèi)容進行調(diào)整和篩選。3.5需求規(guī)格說明書的編寫與評審第3章1．需求規(guī)格說明書的編713.5需求規(guī)格說明書的編寫與評審第3章2．需求分析的評審在需求分析規(guī)格說明書編寫完成后，必須進行需求評審，以驗證需求的正確性。如果在評審過程中發(fā)現(xiàn)說明書存在錯誤或缺陷，應及時進行更改或彌補，重新進行相應部分的需求分析、需求建模、修改需求規(guī)格說明書，并再行評審。需求分析評審的主要內(nèi)容如下：（1）一致性。所有需求必須是一致的，任何一條需求不能和其他需求相矛盾。（2）完整性。需求必須是完整的，規(guī)格說明書應該包括用戶需要的每一個功能或性能。（3）現(xiàn)實性。指定的需求應該是用現(xiàn)有的軟硬件技術(shù)基本上可以實現(xiàn)的。對硬件技術(shù)的進步可以預測，對軟件技術(shù)的進步則很難預測，只能從現(xiàn)有技術(shù)水平判斷需求的現(xiàn)實性。（4）有效性。必須證明需求是正確而有效的，確實能解決用戶所面對的問題。3.5需求規(guī)格說明書的編寫與評審第3章2．需求分析的評審723.6項目實踐：“圖書管理系統(tǒng)”軟件需求分析第3章下面以第2章的“圖書管理系統(tǒng)”為例，說明面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法及軟件需求說明書的編寫內(nèi)容。在圖書館負責人和計算機系的技術(shù)人員通過了“圖書管理系統(tǒng)”《項目開發(fā)計劃》后，項目組隨即進入了項目開發(fā)階段，計算機系教師與圖書館相關(guān)業(yè)務人員緊密合作，經(jīng)過15天的工作，形成了“圖書管理系統(tǒng)”《軟件需求說明書》。主要數(shù)據(jù)流圖如下：3.6項目實踐：“圖書管理系統(tǒng)”軟件需求分析第3章下面以第2733.6項目實踐：“高校圖書管理系統(tǒng)”軟件需求分析第3章3.6項目實踐：“高校圖書管理系統(tǒng)”軟件需求分析第3章743.6項目實踐：“高校圖書管理系統(tǒng)”軟件需求分析第3章3.6項目實踐：“高校圖書管理系統(tǒng)”軟件需求分析第3章753.6項目實踐：“高校圖書管理系統(tǒng)”軟件需求分析第3章3.6項目實踐：“高校圖書管理系統(tǒng)”軟件需求分析第3章763.6項目實踐：“高校圖書管理系統(tǒng)”軟件需求分析第3章3.6項目實踐：“高校圖書管理系統(tǒng)”軟件需求分析第3章773.6項目實踐：“高校圖書管理系統(tǒng)”軟件需求分析第3章3.6項目實踐：“高校圖書管理系統(tǒng)”軟件需求分析第3章783.6項目實踐：“高校圖書管理系統(tǒng)”軟件需求分析第3章3.6項目實踐：“高校圖書管理系統(tǒng)”軟件需求分析第3章79概要設計第4章本章要點

掌握軟件設計的概念與原則；理解軟件設計的任務；

掌握概要設計的內(nèi)容與步驟；掌握結(jié)構(gòu)化設計方法；了解概要設計說明書的內(nèi)容。概要設計第4章本章掌握軟件設計的概念與原則；804.1軟件設計概述第4章軟件設計是軟件工程的重要階段，是一個將軟件需求轉(zhuǎn)換為軟件表示的過程。軟件設計的基本目標是用比較抽象概括的方式確定目標系統(tǒng)如何完成預定的任務，即確定系統(tǒng)的物理模型，解決軟件系統(tǒng)“怎么做”的問題。軟件設計不同于程序設計，程序設計是軟件設計的編碼實現(xiàn)過程。軟件設計的重要性有以下幾點：（1）軟件開發(fā)階段（設計、編碼、測試）占據(jù)軟件項目開發(fā)總成本絕大部分，是在軟件開發(fā)中形成質(zhì)量的關(guān)鍵環(huán)節(jié)。（2）軟件設計是開發(fā)階段最重要的步驟，是將用戶需求準確地轉(zhuǎn)化為最終的軟件產(chǎn)品的唯一途徑。（3）軟件設計作出的決策，最終將直接影響軟件實現(xiàn)的成敗。（4）軟件設計是軟件工程和軟件維護的基礎。4.1.1軟件設計的概念與重要性4.1軟件設計概述第4章軟件設計是軟件工程的重要階段，是一個814.1軟件設計概述第4章從工程管理的角度來看，可以將軟件設計分為兩個階段：概要設計（又稱總體設計）階段和詳細設計（又稱過程設計）階段。概要設計階段得到軟件系統(tǒng)的基本框架，詳細設計階段明確系統(tǒng)內(nèi)部的實現(xiàn)細節(jié)。4.1.2軟件設計的任務4.1軟件設計概述第4章從工程管理的角度來看，可以將軟件設計824.2概要設計的任務與步驟第4章概要設計的基本任務是：（1）設計軟件系統(tǒng)結(jié)構(gòu)；（2）數(shù)據(jù)結(jié)構(gòu)及數(shù)據(jù)庫設計；（3）編寫概要設計文檔；（4）評審概要設計文檔。4.2.1概要設計的任務4.2概要設計的任務與步驟第4章概要設計的基本任務是：4.834.2概要設計的任務與步驟第4章概要設計的一般步驟如下：1.選定體系結(jié)構(gòu)2.確定設計方案3.設計軟件結(jié)構(gòu)4.數(shù)據(jù)結(jié)構(gòu)及數(shù)據(jù)庫設計5.制訂測試計劃6.編寫概要設計文檔7.概要設計文檔評審4.2.2概要設計的步驟4.2概要設計的任務與步驟第4章概要設計的一般步驟如下：4844.3概要設計的原則第4章1.模塊化模塊化是“分而治之”策略的具體表現(xiàn)。模塊化就是將整體軟件劃分成獨立命名且可獨立訪問的模塊，不同的模塊通常具有不同的功能或職責。每個模塊可獨立地開發(fā)、測試，最后組裝成完整的軟件。在結(jié)構(gòu)化方法中，函數(shù)、過程和子程序等都可作為模塊；在面向?qū)ο蠓椒ㄖ?，對象、對象?nèi)的方法也是模塊。模塊是構(gòu)成軟件的基本構(gòu)件。4.3概要設計的原則第4章1.模塊化854.3概要設計的原則第4章2.抽象與分解抽象是指忽視一個主題中與當前目標無關(guān)的方面，以便更充分地注意與當前目標有關(guān)的方面。抽象可以分成若干級別，級別越高，細節(jié)越少。其實整個軟件的開發(fā)過程就是一個從抽象到具體的過程：需求分析時，使用問題域語言來概括性地描述解決方案，抽象級別最高；軟件設計時，同時使用面向問題域和面向?qū)崿F(xiàn)的兩種術(shù)語描述解決方案，抽象級別次之；在編碼時，使用直接實現(xiàn)的方式（源程序代碼）來描述解決方案，抽象級別最低。在軟件設計中，過程抽象和數(shù)據(jù)抽象是兩種常用的抽象手段。4.3概要設計的原則第4章2.抽象與分解864.3概要設計的原則第4章3.信息隱蔽和局部化信息隱蔽是指模塊所包含的信息，不允許其他不需要這些信息的模塊訪問，獨立的模塊間僅僅交換為完成系統(tǒng)功能而必須交換的信息。信息隱蔽的目的是提高模塊的獨立性，減少修改或維護時的影響面。局部化就是把關(guān)系密切的軟件元素物理地放得彼此靠近。其優(yōu)點是可維護性、可靠性和可理解性好。4.模塊獨立性模塊獨立性概括了把軟件劃分為模塊時要遵守的準則，也是判斷模塊構(gòu)造是否合理的標準。模塊獨立性好的軟件接口簡單、容易開發(fā)，獨立的模塊也容易測試和維護。因此，模塊獨立性是軟件質(zhì)量的關(guān)鍵。4.3概要設計的原則第4章3.信息隱蔽和局部化874.3概要設計的原則第4章5.復用性設計復用是指同一事物不做修改或稍加修改就可以多次重復使用。將復用思想用于軟件開發(fā)稱為軟件復用，將軟件的重用部分稱為軟構(gòu)件。也就是說，在構(gòu)造軟件系統(tǒng)時不必從零做起，可通過直接使用或加以修改已有軟構(gòu)件來組裝成新系統(tǒng)。軟件復用可提高軟件的生產(chǎn)率。由于軟構(gòu)件是經(jīng)過反復使用驗證的，自身具有較高的質(zhì)量，因此由軟構(gòu)件組成的新系統(tǒng)也具有較高的質(zhì)量。軟件復用并不局限于軟件代碼，其范圍也可擴展到軟件開發(fā)各個階段，包括需求模型和規(guī)格說明、設計模型、文檔、測試用例等。4.3概要設計的原則第4章5.復用性設計884.4模塊的獨立性第4章模塊獨立性是指軟件系統(tǒng)中每個模塊只涉及軟件要求的具體的子功能，而與軟件系統(tǒng)中其他模塊的接口是簡單的。模塊獨立性取決于模塊的內(nèi)部和外部特征。一般用耦合和內(nèi)聚兩個定性的指標來度量。耦合是模塊之間相互依賴的緊密程度的度量，內(nèi)聚是一個模塊內(nèi)部各個元素之間彼此結(jié)合的緊密程度的度量。一個模塊內(nèi)部各個元素之間的聯(lián)系越緊密，則模塊的內(nèi)聚度就越高，相對地，它與其他模塊之間的耦合就越低，模塊的獨立性就越強。一個優(yōu)秀的軟件設計，應盡量做到高內(nèi)聚、低耦合，從而提高模塊的獨立性。4.4模塊的獨立性第4章模塊獨立性是指軟件系統(tǒng)中每個模塊只894.4模塊的獨立性第4章耦合是模塊之間相互連接的緊密程度的度量。耦合強弱取決于模塊間接口的復雜程度、進入或訪問一個模塊的點以及通過接口的數(shù)據(jù)。模塊之間的連接越緊密，聯(lián)系越多，耦合性就越高，而其模塊獨立性就越弱。通常希望一個軟件系統(tǒng)具有較低的耦合性。4.4.1耦合性（Coupling）4.4模塊的獨立性第4章耦合是模塊之間相互連接的緊密程度的904.4模塊的獨立性第4章1.非直接耦合兩個模塊間沒有直接關(guān)系，它們之間的聯(lián)系完全是通過主模塊的控制和調(diào)用來實現(xiàn)的。耦合度最弱，模塊獨立性最強。2.數(shù)據(jù)耦合調(diào)用模塊和被調(diào)用模塊之間只傳遞簡單的數(shù)據(jù)項參數(shù)。相當于高級語言中的值傳遞。4.4.1耦合性（Coupling）4.4模塊的獨立性第4章1.非直接耦合4.4.1耦合914.4模塊的獨立性第4章3.標記耦合調(diào)用模塊和被調(diào)用模塊之間傳遞數(shù)據(jù)結(jié)構(gòu)而不是簡單數(shù)據(jù)。也稱特征耦合。標記耦合的模塊間傳遞的不是簡單變量，而是像高級語言中的數(shù)組名、記錄名和文件名等數(shù)據(jù)結(jié)構(gòu)，這些名字即為標記，其實傳遞的是地址。4.4.1耦合性（Coupling）4.4模塊的獨立性第4章3.標記耦合4.4.1耦合性924.4模塊的獨立性第4章4.控制耦合模塊之間傳遞的不是數(shù)據(jù)信息，而是控制信息如標志、開關(guān)量，一個模塊控制了另一模塊的功能。4.4.1耦合性（Coupling）4.4模塊的獨立性第4章4.控制耦合4.4.1耦合性934.4模塊的獨立性第4章5.外部耦合一組模塊都訪問同一全局簡單變量，而且不通過參數(shù)表傳遞該全局變量的信息，則稱之為外部耦合。6.公共耦合若一組模塊都訪問同一全局數(shù)據(jù)結(jié)構(gòu)，則稱之為公共耦合。公共數(shù)據(jù)環(huán)境可以是全局數(shù)據(jù)結(jié)構(gòu)、共享的通信區(qū)、內(nèi)存的公共覆蓋區(qū)等。如果模塊只是向公共數(shù)據(jù)環(huán)境輸入數(shù)據(jù)，或是只從公共數(shù)據(jù)環(huán)境取出數(shù)據(jù)，這屬于比較松散的公共耦合；如果模塊既向公共數(shù)據(jù)環(huán)境輸入數(shù)據(jù)又從公共數(shù)據(jù)環(huán)境取出數(shù)據(jù)，這屬于較緊密的公共耦合。4.4.1耦合性（Coupling）4.4模塊的獨立性第4章5.外部耦合4.4.1耦合性944.4模塊的獨立性第4章7.內(nèi)容耦合一個模塊直接訪問另一模塊的內(nèi)容，則稱這兩個模塊為內(nèi)容耦合。若在程序中出現(xiàn)下列情況之一，則說明兩個模塊之間發(fā)生了內(nèi)容耦合：（1）一個模塊直接訪問另一個模塊的內(nèi)部數(shù)據(jù);（2）一個模塊不通過正常入口而直接轉(zhuǎn)入到另一個模塊的內(nèi)部;（3）兩個模塊有一部分代碼重疊（該部分代碼具有一定的獨立功能）;（4）一個模塊有多個入口。4.4.1耦合性（Coupling）4.4模塊的獨立性第4章7.內(nèi)容耦合4.4.1耦合性954.4模塊的獨立性第4章一個模塊內(nèi)各個元素彼此結(jié)合的緊密程度用內(nèi)聚（或稱聚合）來度量。一個理想的模塊只完成一個功能，模塊設計的目標之一是盡可能高內(nèi)聚。4.4.2內(nèi)聚性（Cohesion）4.4模塊的獨立性第4章一個模塊內(nèi)各個元素彼此結(jié)合的緊密程964.4模塊的獨立性第4章1.偶然內(nèi)聚一個模塊內(nèi)的各處理元素之間沒有任何聯(lián)系，只是偶然地被湊到一起。這種模塊也稱巧合內(nèi)聚，內(nèi)聚程度最低。4.4.2內(nèi)聚性（Cohesion）4.4模塊的獨立性第4章1.偶然內(nèi)聚4.4.2內(nèi)聚性（974.4模塊的獨立性第4章2.邏輯內(nèi)聚指模塊內(nèi)執(zhí)行幾個邏輯上相關(guān)的功能，通過參數(shù)確定該模塊完成哪一個功能。4.4.2內(nèi)聚性（Cohesion）4.4模塊的獨立性第4章2.邏輯內(nèi)聚4.4.2內(nèi)聚性（984.4模塊的獨立性第4章3.時間內(nèi)聚把需要同時或順序執(zhí)行的動作組合在一起形成的模塊。時間內(nèi)聚模塊中的功能元素只因時間因素關(guān)聯(lián)在一起，各元素之間沒有共用數(shù)據(jù)，而且一般情況下各部分可以以任意次序執(zhí)行。4.過程內(nèi)聚如果一個模塊內(nèi)的處理元素是相關(guān)的，而且必須以特定次序執(zhí)行則稱為過程內(nèi)聚。4.4.2內(nèi)聚性（Cohesion）4.4模塊的獨立性第4章3.時間內(nèi)聚4.4.2內(nèi)聚性（994.4模塊的獨立性第4章5.通信內(nèi)聚指模塊內(nèi)所有處理功能都通過公用數(shù)據(jù)而發(fā)生關(guān)系。即模塊內(nèi)各個組成部分都使用相同的輸入數(shù)據(jù)或產(chǎn)生相同的輸出結(jié)果。4.4.2內(nèi)聚性（Cohesion）4.4模塊的獨立性第4章5.通信內(nèi)聚4.4.2內(nèi)聚性（1004.4模塊的獨立性第4章6.順序內(nèi)聚指一個模塊中各個處理元素和同一個功能密切相關(guān)，而且這些處理必須順序執(zhí)行，通常前一個處理元素的輸出是后一個處理元素的輸入。順序內(nèi)聚的內(nèi)聚度比較高，但缺點是不如功能內(nèi)聚易于維護。7.功能內(nèi)聚指模塊內(nèi)所有元素的各個組成部分全部都為完成同一個功能而存在，共同完成一個單一的功能，模塊已不可再分。即模塊僅包括為完成某個功能所必須的所有成分，這些成分緊密聯(lián)系、缺一不可。4.4.2內(nèi)聚性（Cohesion）4.4模塊的獨立性第4章6.順序內(nèi)聚4.4.2內(nèi)聚性（1014.4模塊的獨立性第4章1.模塊功能的完善化2.消除重復功能，改善軟件結(jié)構(gòu)3.模塊規(guī)模應該適中4.模塊的深度、寬度、扇出和扇入都應適當5.模塊的作用范圍應該在控制范圍之內(nèi)6.力爭降低模塊接口的復雜程度7.設計單入口、單出口的模塊8.模塊功能應該可以預測4.4.2軟件結(jié)構(gòu)優(yōu)化準則4.4模塊的獨立性第4章1.模塊功能的完善化4.4.21024.5軟件結(jié)構(gòu)設計的圖形工具第4章層次圖（Hierarchy）也稱H圖，用于表示軟件的層次結(jié)構(gòu)，特別適合于在自頂向下設計時使用。4.5.1層次圖4.5軟件結(jié)構(gòu)設計的圖形工具第4章層次圖（Hierarch1034.5軟件結(jié)構(gòu)設計的圖形工具第4章IPO圖是輸入/處理/輸出圖（InputProcessOutput），其基本形式是三個方框，左邊方框列出所有的輸入數(shù)據(jù)，中間框列出主要的處理，右邊框列出輸出數(shù)據(jù)。4.5.2IPO圖4.5軟件結(jié)構(gòu)設計的圖形工具第4章IPO圖是輸入/處理/輸1044.5軟件結(jié)構(gòu)設計的圖形工具第4章模塊結(jié)構(gòu)圖（StructureChart，SC圖）用于表示軟件系統(tǒng)的層次分解關(guān)系、模塊調(diào)用關(guān)系、模塊之間數(shù)據(jù)流和控制信息流的傳遞關(guān)系，是描述軟件系統(tǒng)物理模型、進行概要設計的主要工具，也是軟件文檔的一部分。4.5.3結(jié)構(gòu)圖4.5軟件結(jié)構(gòu)設計的圖形工具第4章模塊結(jié)構(gòu)圖（Struct1054.6結(jié)構(gòu)化的設計方法第4章結(jié)構(gòu)化設計方法是面向數(shù)據(jù)流的設計方法，它以數(shù)據(jù)流圖為基礎，定義了將數(shù)據(jù)流圖映射為軟件結(jié)構(gòu)圖（即DFD→SC）的方法，而數(shù)據(jù)流的類型決定了映射的方法。數(shù)據(jù)流分為變換流和事務流兩種，因此由數(shù)據(jù)流組成的數(shù)據(jù)流圖也分為變換型數(shù)據(jù)流圖和事務型數(shù)據(jù)流圖兩種類型。由變換型數(shù)據(jù)流圖向結(jié)構(gòu)圖的映射稱變換分析，由事務型數(shù)據(jù)流圖向結(jié)構(gòu)圖的映射稱事務分析。4.6結(jié)構(gòu)化的設計方法第4章結(jié)構(gòu)化設計方法是面向數(shù)據(jù)流1064.6結(jié)構(gòu)化的設計方法第4章1．數(shù)據(jù)流圖的類型（1）變換流變換型數(shù)據(jù)流的特征是可以把它看成由輸入、變換中心和輸出三部分組成，這樣的數(shù)據(jù)流圖稱為變換型數(shù)據(jù)流圖。如圖4-20所示。4.6結(jié)構(gòu)化的設計方法第4章1．數(shù)據(jù)流圖的類型1074.6結(jié)構(gòu)化的設計方法第4章（2）事務流事務型數(shù)據(jù)流的特征是可以把它看成具有在多種事務中選擇執(zhí)行某類事務的能力。這樣的數(shù)據(jù)流圖稱為事務型數(shù)據(jù)流圖。4.6結(jié)構(gòu)化的設計方法第4章（2）事務流1084.6結(jié)構(gòu)化的設計方法第4章2.結(jié)構(gòu)化設計過程面向數(shù)據(jù)流的結(jié)構(gòu)化方法的設計過程如圖4-22所示。4.6結(jié)構(gòu)化的設計方法第4章2.結(jié)構(gòu)化設計過程1094.6結(jié)構(gòu)化的設計方法第4章（1）精化DFD。（2）確定DFD類型。（3）把DFD映射到系統(tǒng)模塊結(jié)構(gòu)，設計模塊結(jié)構(gòu)的上層。（4）基于DFD逐步分解高層模塊，設計出下層模塊。（5）根據(jù)模塊獨立性原理，精化模塊結(jié)構(gòu)。（6）描述模塊接口。4.6結(jié)構(gòu)化的設計方法第4章（1）精化DFD。1104.6結(jié)構(gòu)化的設計方法第4章兩種映射方法都是先映射出初始軟件結(jié)構(gòu)圖。4.6結(jié)構(gòu)化的設計方法第4章兩種映射方法都是先映射出初1114.6結(jié)構(gòu)化的設計方法第4章3.變換分析變換分析是一系列設計步驟的總稱，通過執(zhí)行這些步驟，將具有變換流特點的數(shù)據(jù)流圖按預先確定的模式映射成軟件結(jié)構(gòu)。采用變換分析方法開發(fā)出的軟件結(jié)構(gòu)圖，其一般方式為：“輸入—處理—輸出”。變換分析方法的設計步驟如下：第一步復查基本系統(tǒng)模型。以確定輸入數(shù)據(jù)和輸出數(shù)據(jù)是否與實際相符。第二步復查并精化數(shù)據(jù)流圖。完成對需求分析階段得出的數(shù)據(jù)流圖的復查和精化。第三步判斷數(shù)據(jù)流圖具有變換特性還是事務特性。根據(jù)數(shù)據(jù)流圖中占優(yōu)勢的屬性是事務的還是變換的，來確定數(shù)據(jù)流的全局屬性。第四步確定輸入流和輸出流的邊界，從而將變換中心劃分出來。第五步完成“第一級分解”。分配控制的過程，劃分頂層模塊和從屬模塊。第六步完成“第二級分解”。就是把數(shù)據(jù)流圖中的每個處理映射成軟件結(jié)構(gòu)中一個適當?shù)哪K。第七步采用啟發(fā)式設計規(guī)則和設計度量對得到的軟件結(jié)構(gòu)進行精化。4.6結(jié)構(gòu)化的設計方法第4章3.變換分析1124.6結(jié)構(gòu)化的設計方法第4章4.事務分析事務分析的設計步驟和變換分析的設計步驟基本類似，主要差別在于數(shù)據(jù)流圖到軟件結(jié)構(gòu)的映射方法不同。在事務分析的設計中，由數(shù)據(jù)流圖映射到軟件結(jié)構(gòu)時，從事務中心邊界開始，把接收通路映射成一個模塊，在發(fā)送通路設立一個控制模塊，用以控制由不同發(fā)送通路映射成的分支模塊。4.6結(jié)構(gòu)化的設計方法第4章4.事務分析1134.7概要設計文檔與評審第4章軟件設計規(guī)格說明書是軟件設計階段要完成的文檔，作為設計任務的最終成果。概要設計、詳細設計、數(shù)據(jù)設計規(guī)格說明書可根據(jù)項目的大小分別編寫或合并為一份設計規(guī)格說明書。我國國家標準GB/T8567\|2006《計算機軟件文檔編制規(guī)范》都給出了設計說明書的內(nèi)容框架，可以選擇使用。本章4.8節(jié)給出的“高校圖書管理系統(tǒng)”《軟件概要設計說明書》可供讀者參考。4.7.1概要設計說明書的編寫內(nèi)容4.7概要設計文檔與評審第4章軟件設計規(guī)格說明書是軟件設1144.7概要設計文檔與評審第4章設計評審就是對設計文檔的評審。目的是為了盡早發(fā)現(xiàn)軟件的欠缺并盡早糾正，因此評審對于項目的成功是絕對必要的。（1）評審的指導原則概要設計評審和詳細設計評審應分開進行，不可合并為一次評審；概要設計評審應邀請用戶代表和有關(guān)領域?qū)＜业綍敿氃O計評審則不需要；評審是為了提前揭露錯誤，參加評審的設計人員應該歡迎別人提出批評和建議，不要掩蓋設計的缺陷。評審的對象是設計文檔而不是設計者；評審中提出的問題應詳細記錄，但不謀求當場解決；評審結(jié)束前應做出本次評審能否通過的結(jié)論。4.7.2概要設計評審4.7概要設計文檔與評審第4章設計評審就是對設計文檔的評1154.7概要設計文檔與評審第4章（2）評審的主要內(nèi)容概要設計評審應該把重點放在系統(tǒng)的總體結(jié)構(gòu)、模塊劃分、內(nèi)外接口等方面。如軟件結(jié)構(gòu)能否滿足需求；結(jié)構(gòu)形態(tài)是否合理；層次是否清晰；模塊劃分是否符合優(yōu)化原則；人機界面、內(nèi)外部接口和出錯處理是否合理等。詳細設計評審的重點應該放在各個模塊的具體設計上。如模塊的設計能否滿足其功能和性能要求；算法和數(shù)據(jù)結(jié)構(gòu)是否合理；設計描述是否簡單、清晰等。4.7.2概要設計評審4.7概要設計文檔與評審第4章（2）評審的主要內(nèi)容4.71164.7概要設計文檔與評審第4章（3）評審的方式評審分為正式和非正式兩種方式。非正式評審參加人數(shù)少，且均為軟件人員，帶有同行討論性質(zhì)，不拘泥于時間和形式，適宜詳細設計評審。正式評審除軟件開發(fā)人員外，還應邀請用戶代表和有關(guān)領域?qū)＜覅⒓?。通常采用答辯方式，與會者提前審閱文檔資料，設計人員使用幻燈片等方式對設計方案詳細說明之后，回答與會者的問題并記錄各種重要的評審意見。正式評審是概要設計評審的常用方式。4.7.2概要設計評審4.7概要設計文檔與評審第4章（3）評審的方式4.7.21174.8項目實踐：“圖書管理系統(tǒng)”概要設計第4章4.8項目實踐：“圖書管理系統(tǒng)”概要設計第4章1184.8項目實踐：“圖書管理系統(tǒng)”概要設計第4章功能模塊與相應數(shù)據(jù)表之間的關(guān)系表4.8項目實踐：“圖書管理系統(tǒng)”概要設計第4章功能模塊與119詳細設計第5章本章要點理解詳細設計的任務與原則；掌握詳細設計的表達工具；學會書寫軟件詳細設計文檔。詳細設計第5章本章1205.1詳細設計的任務與原則第5章詳細設計（又稱為過程設計或模塊設計），是編碼的前導。其主要任務是確定每一個模塊所使用的算法、塊內(nèi)數(shù)據(jù)結(jié)構(gòu)和接口細節(jié)，用描述工具表達算法的過程，即對模塊的具體實現(xiàn)過程進行詳細地描述。具體任務如下：（1）算法設計（2）數(shù)據(jù)結(jié)構(gòu)設計（3）模塊接口細節(jié)（4）測試用例設計（5）數(shù)據(jù)庫物理設計（6）數(shù)據(jù)代碼設計（7）其他設計（8）編寫詳細設計說明書并進行評審。5.1.1詳細設計的任務5.1詳細設計的任務與原則第5章詳細設計（又稱為過程設計1215.1詳細設計的任務與原則第5章進行詳細設計時應遵循以下原則：（1）采用自頂向下、逐步求精的程序設計方法。在詳細設計過程中，采用逐步求精的方法尅降低待處理問題的復雜度。（2）使用三種基本控制結(jié)構(gòu)完成程序設計。使用順序、選擇和循環(huán)三種基本控制結(jié)構(gòu)構(gòu)造程序，限制使用無條件跳轉(zhuǎn)語句。（3）設計人員組織結(jié)構(gòu)采用“外科醫(yī)生——助手”模式。在這種組織結(jié)構(gòu)中，外科醫(yī)生和助手都應了解相關(guān)設計內(nèi)容，但外科醫(yī)生在設計中起主導作用，是設計的技術(shù)負責人，助手只起技術(shù)支持作用。此種模式區(qū)別于傳統(tǒng)的“平等組合”模式，使設計責任集中在少數(shù)人身上，避免了因觀點不同而造成的設計策略和接口的差異。5.1.2詳細設計的原則5.1詳細設計的任務與原則第5章進行詳細設計時應遵循以下1225.2詳細設計的工具第5章算法過程在理想的情況下是使用自然語言來描述，但由于自然語言存在多義性，在實際的算法描述中，只能采用更加嚴謹?shù)姆绞絹砭谋硎?。進行詳細設計時常用三種工具：圖形、表格和語言。圖形工具：包括程序流程圖、N\|S圖、PAD圖等。表格工具：判定表。語言工具：過程設計語言（PDL）。5.2詳細設計的工具第5章算法過程在理想的情況下是使用自1235.2詳細設計的工具第5章1.程序流程圖程序流程圖又叫程序框圖，它是歷史最悠久、使用最廣泛的一種算法表示工具。5.2詳細設計的工具第5章1.程序流程圖1245.2詳細設計的工具第5章程序流程圖的5種控制結(jié)構(gòu)如圖5-2所示。5.2詳細設計的工具第5章程序流程圖的5種控制結(jié)構(gòu)如圖51255.3用戶界面設計第5章5.3.1用戶界面設計的重要性5.3.2用戶界面設計考慮的問題5.3.3用戶界面設計的基本原則5.3.4用戶界面設計指南5.3用戶界面設計第5章5.3.1用戶界面設計的重要1265.4數(shù)據(jù)代碼設計第5章1.代碼設計的原則2.代碼的種類順序碼、信息塊碼、分組碼、助記碼、縮寫碼、合成碼5.4數(shù)據(jù)代碼設計第5章1.代碼設計的原則1275.5詳細設計文檔的編制及評審第5章1.詳細設計文檔的編制2.詳細設計的評審

5.5詳細設計文檔的編制及評審第5章1.詳細設計文檔的1285.6項目實踐：圖書管理系統(tǒng)詳細設計第5章“借書借閱”、“圖書歸還”程序的層次結(jié)構(gòu)圖

5.6項目實踐：圖書管理系統(tǒng)詳細設計第5章“借書借閱”、1295.6項目實踐：圖書管理系統(tǒng)詳細設計第5章“借書借閱”模塊功能描述

5.6項目實踐：圖書管理系統(tǒng)詳細設計第5章“借書借閱”模1305.6項目實踐：圖書管理系統(tǒng)詳細設計第5章“借書借閱”程序流程圖

創(chuàng)建本窗體連接數(shù)據(jù)庫調(diào)用“檢查借書數(shù)量”調(diào)用“檢查圖書”調(diào)用“審核讀者”調(diào)用“辦理借書”5.6項目實踐：圖書管理系統(tǒng)詳細設計第5章“借書借閱”程1315.6項目實踐：圖書管理系統(tǒng)詳細設計第5章“借書借閱”模塊程序接口

5.6項目實踐：圖書管理系統(tǒng)詳細設計第5章“借書借閱”模132面向?qū)ο蟾拍詈蚏ose建模技術(shù)第6章本章要點掌握面向?qū)ο蟮幕靖拍睿?/p>

理解面向?qū)ο笈c面向過程的區(qū)別；

了解UML的各種圖；

熟悉靜態(tài)建模和動態(tài)建模的方法；

學會RationalRose軟件的安裝與配置方法；

掌握利用RationalRose建模的基本步驟。面向?qū)ο蟾拍詈蚏ose建模技術(shù)第6章本章掌握面向?qū)ο蟮幕?336.1面向?qū)ο蠓椒ǜ攀龅?章目前廣泛使用的軟件工程方法主要有結(jié)構(gòu)化方法和面向?qū)ο蟮姆椒ā＝Y(jié)構(gòu)化方法是面向功能的，它從系統(tǒng)的功能入手，將系統(tǒng)分解為若干功能模塊，通常使用函數(shù)或過程來實現(xiàn)所需功能，數(shù)據(jù)通常作為參數(shù)傳遞給函數(shù)或過程。用這種方式開發(fā)的軟件可重用性、可維護性都較差。尤其是當軟件規(guī)模較大或軟件需求模糊易變時，采用結(jié)構(gòu)化方法開發(fā)軟件往往不能成功。為此，人們提出了面向?qū)ο蟮拈_發(fā)方法。面向?qū)ο蠓椒捎孟旅娴墓絹砻枋觯好嫦驅(qū)ο?對象+類+繼承+消息傳遞6.1.1面向?qū)ο蠓椒ǖ奶卣?.1面向?qū)ο蠓椒ǜ攀龅?章目前廣泛使用的軟件工程方法主1346.1面向?qū)ο蠓椒ǜ攀龅?章面向?qū)ο蠓椒ǖ闹饕獌?yōu)點如下：1.與人類習慣的思維方法一致2.系統(tǒng)的穩(wěn)定性好3.可重用性好4.較易于開發(fā)大型軟件產(chǎn)品5.可維護性好6.1.1面向?qū)ο蠓椒ǖ奶卣?.1面向?qū)ο蠓椒ǜ攀龅?章面向?qū)ο蠓椒ǖ闹饕獌?yōu)點如下：1356.1面向?qū)ο蠓椒ǜ攀龅?章1.對象（Object）在應用領域中有意義的、與所有解決的問題有關(guān)系的任何事物都可以作為對象。對象可以是具體的物體實體的抽象，也可以是人為的概念，或者是任何有明確邊界和意義的東西。例如，一名學生、一本圖書等。對象由一組屬性和對這組屬性進行操作的一組方法（服務）組成。屬性就是對象所包含的數(shù)據(jù)，它代表對象的狀態(tài)，它在設計對象時確定，一般只能通過執(zhí)行對象的操作來改變，例如，學生的屬性有姓名、年齡等。操作（或稱方法或服務）即對象所能執(zhí)行的操作，也就是類中所定義的服務，它描述了對象執(zhí)行操作的算法，響應消息的方法?？梢酝ㄟ^向?qū)ο蟀l(fā)送消息來調(diào)用其方法。例如：“讀者”類的服務有“借書”、“還書”等。6.1.2面向?qū)ο蠓椒ǖ幕靖拍?.1面向?qū)ο蠓椒ǜ攀龅?章1.對象（Object）6.1366.1面向?qū)ο蠓椒ǜ攀龅?章1.對象（Object）6.1.2面向?qū)ο蠓椒ǖ幕靖拍?.1面向?qū)ο蠓椒ǜ攀龅?章1.對象（Object）6.1376.1面向?qū)ο蠓椒ǜ攀龅?章2.類（Class）和實例（Instance）類是具有相同屬性和服務的一組對象的集合。類是關(guān)于對象的抽象描述，反映了該對象類型的所有對象的性質(zhì)。一個對象則是其對應類的一個實例。類和對象的關(guān)系是：類是對象的抽象，類是對象的“模板”，類用于創(chuàng)建對象；對象是類的實例。例如：“學生”是一個類，它描述了所有學生的性質(zhì)。而一個具體的學生“張三”是類“學生”的一個實例。類是關(guān)于對象性質(zhì)的描述，它同對象一樣，包括一組數(shù)據(jù)屬性和在數(shù)據(jù)上的操作。6.1.2面向?qū)ο蠓椒ǖ幕靖拍?.1面向?qū)ο蠓椒ǜ攀龅?章2.類（Class）和實例（1386.1面向?qū)ο蠓椒ǜ攀龅?章4．封裝（Encapsulation）封裝是一種信息隱蔽技術(shù)，用戶只能見到對象封裝界面上的信息，而對象內(nèi)部的實現(xiàn)細節(jié)對用戶是隱藏的。封裝有兩個含義，一個是指把對象的全部屬性和全部操作（即方法）結(jié)合起來，形成一個不可分割的獨立單位（即對象）；另一個是指信息隱蔽，即盡可能隱蔽對象內(nèi)部的行為實現(xiàn)細節(jié)。類（或?qū)ο螅┦欠庋b的基本單位。在類中定義的接收對方消息的方法稱為類的接口。封裝使對象形成兩個部分：接口部分和實現(xiàn)部分。接口部分是可見的，供外界通過消息來訪問該對象，而實現(xiàn)部分不可見。6.1.2面向?qū)ο蠓椒ǖ幕靖拍?.1面向?qū)ο蠓椒ǜ攀龅?章4．封裝（Encapsula1396.1面向?qū)ο蠓椒ǜ攀龅?章5．繼承性(Inheritance)繼承