軟件工程課件

V4.1高級軟體工程第一章軟體工程概述第一章軟體工程概述

1.1軟體技術概述1.2軟體危機1.3軟體工程1.4軟體工程環(huán)境

在學習了“高級程式設計語言”和“數據結構”後，編寫小程式不會有太大問題。但要開發(fā)一個大型軟體一定有許多困難，例如在接到專案後，應該從哪兒入手、用什麼方法、按照哪些步驟進行開發(fā)，如何評價一個軟體的好壞，等等，這些都是初次參加大型軟體的開發(fā)人員要遇到的問題。因此，必須學習軟體工程。第一章軟體工程概述高級軟體工程一、軟體的概念與特點

程式是一系列指令序列的集合，它能被電腦理解和執(zhí)行。

文檔是指用自然語言或者形式化語言所編寫的文字資料和圖表，用來描述程式的內容、組成、設計、功能規(guī)格、開發(fā)情況、測試結果及使用方法，如程式設計說明書、流程圖、用戶手冊等。1.1軟體技術概述第一章軟體工程概述

1.1軟體技術概述1.1.1軟體的概念與特點

1.1.2電腦軟體技術1.1.3軟體複用1.2軟體危機1.3軟體工程1.4軟體工程環(huán)境

高級軟體工程

軟體是電腦系統(tǒng)中與硬體子系統(tǒng)相互依存的另一個子系統(tǒng)，是一個包含程式及其文檔資料的完整集合，提供了用戶與硬體子系統(tǒng)之間的介面。隨著電腦科學技術的發(fā)展，人們對軟體的認識也在不斷深化，這從下麵式子變化就可以看出：70年代以前：軟體＝程式；70年代：軟體=程式＋文檔；80年代以後：軟體=文檔＋程式。

在軟體的可維護性變得越來越重要的今天，文檔的地位也提高到前所未有的高度，並且能夠自動化地生成。與小型軟體不同，大型軟體具有如下特點：⑴規(guī)模大現(xiàn)在的軟體動咎上百兆，需要處理的數據量大，佔用的記憶體也大。對於即時軟體，除了規(guī)模大以外，還要求可靠性高。⑵複雜性高大型軟體由大量的模組集成，模組間的關係、調用方式以及數據和文件的關係都相當複雜。⑶開發(fā)週期長大型軟體從立項到交付使用，需幾十人、幾百人經過幾個月甚至幾年的時間。⑷開發(fā)、維護和使用人員不同⑸多學科綜合軟體開發(fā)人員除了具有必備的軟體知識外，還應該具有多方面的專業(yè)知識和經驗。二、電腦軟體技術電腦軟體技術是指開發(fā)電腦軟體所需的所有技術的總稱。按照軟體分支學科的內容劃分，電腦軟體技術相應有如下幾個領域：(1)軟體工程技術包括軟體開發(fā)的原則與策略、軟體開發(fā)方法與軟體過程模型、軟體標準與軟體品質的衡量、軟件開發(fā)的組織與專案管理和軟體工程工具和環(huán)境等。第一章軟體工程概述

1.1軟體技術概述1.1.1軟體的概念與特點

1.1.2電腦軟體技術

1.1.3軟體複用1.2軟體危機1.3軟體工程1.4軟體工程環(huán)境

⑵程式設計技術包括程式的結構與演算法設計、程式設計的風格、程式設計語言、程式設計方法和程式設計自動化、程式的正確性證明和程式的變換。⑶軟體工具環(huán)境技術包括人機介面技術、軟體自動生成、軟體工具的集成、軟體開發(fā)環(huán)境和軟體的複用等。⑷系統(tǒng)軟體技術包括操作系統(tǒng)、編譯方法、分佈式系統(tǒng)的分佈處理與並行計算、並行處理技術和多媒體軟體技術⑸資料庫技術包括數據模型、資料庫與資料庫管理系統(tǒng)、分佈式資料庫、面向對象的資料庫技術、工程資料庫、多媒體資料庫，以及數據倉庫和數據挖掘等。⑹即時軟體技術⑺網路技術包括網路軟體技術、調試工程、網路管理、局域網技術、網路互連技術和智能網路等。三、軟體複用1.軟體複用(軟體重用)概述從1968年提出可複用庫的思想後，軟體複用的概念被推廣了。

軟體複用是指在構造新的軟體系統(tǒng)過程中，對已存在的軟體產品(設計結構、源代碼、文檔等)重複使用的技術。軟體複用有三個層次：知識複用、方法複用和軟體成分複用。前兩個屬於知識工程的範疇，這裏只討論軟體成分的複用。第一章軟體工程概述

1.1軟體技術概述1.1.1軟體的概念與特點1.1.2電腦軟體技術

1.1.3軟體複用

1.2軟體危機1.3軟體工程1.4軟體工程環(huán)境

軟體成分的複用包括以下三個級別：⑴代碼的複用可以採用源代碼剪貼、源代碼包含和繼承來實現(xiàn)。⑵設計結果的複用指複用某個軟體系統(tǒng)的設計模型。適用於軟體系統(tǒng)的移植。⑶分析結果的複用是指複用某個軟體系統(tǒng)的分析模型。適用於用戶需求未改變，而系統(tǒng)體系結構變化的場合。不屬於軟體複用的範疇：程式的重複運行、執(zhí)行期間的重複調用等。軟體複用的優(yōu)點：由於軟體複用利用已有的軟體成分來構造新的軟體，因此大大縮減了軟體開發(fā)所需的人力、物力、財力和開發(fā)時間，並且能提高軟體的可靠性和可維護性。2.軟體複用技術

軟體複用技術分為兩類：合成技術和生成技術。(1)合成技術

利用部件(component,組件，構件)合成軟體系統(tǒng)的技術。

部件是可複用的一小段軟體(可為二進位形式)，可以是對某一函數、過程、副程式、數據類型、演算法等可複用軟體成分的抽象，封裝了功能細節(jié)和數據結構，有詳細的介面。

Microsoft等公司提出了OLE/COM(ObjectLinkingEmbeding/ComponentObjectModel，對象鏈接和嵌入/組件對象模型)概念，並開發(fā)出各種獨立的標準組件，用戶使用這些組件集成自己的軟體，提高了軟體的品質，軟體維護更加容易，同時降低了軟體開發(fā)成本。

目前有三個重要的部件技術：①OMG的CORBA技術②Microsoft的COM+技術③Sun公司JavaBeansAPI，基於Java的部件技術標準。CORBA技術，是異構系統(tǒng)中的分佈式部件技術。CORBA(CommonObjectRequestBrokerArchitecture,公共對象請求代理體系結構)是由OMG(ObjectManagementGroup)提出的應用軟體體系結構和對象技術規(guī)範，其核心是一套標準的語言、介面和協(xié)議，以支持異構分佈應用程式間的互操作性及獨立於平臺和編程語言的對象重用。在1990年開始制定並且逐步完善的部件標準。CORBA3.0。

COM+是微軟公司在新的企業(yè)應用體系結構下，將COM、DCOM和MTS統(tǒng)一起來，形成真正適合於企業(yè)級應用的部件技術。

“COM+”容易使人產生誤解，以為它是COM的新版本，其實COM+的含義遠比COM豐富得多。COM+是一種中間件技術的規(guī)範，其要點是提供建立在操作系統(tǒng)上的、支持分佈式企業(yè)級應用的“服務”。COM+是在20世紀末隨著Windows2000發(fā)佈才面世的。有三種方法將部件合成更大的部件：①連接標準函數庫中的標準函數靠編譯和連接程式與其它模組一起合成系統(tǒng)。②消息傳遞和繼承

smalltalk。③管道機制

UNIX中用管道(pipe)連接命令shell，使前一命令的輸出做為後一命令的輸入，用管道機制把多個shell命令連接在一起完成一個更加複雜的系統(tǒng)。(2)生成技術

利用可複用的模式，通過生成程式產生一個新的程式或程式段，產生的程式可以看成是模式的實例?？裳}用的模式有兩種：代碼模式和規(guī)則模式。①代碼模式可複用的代碼模式存在於應用生成器中，通過特定的參數替換，生成抽象軟體模組的具體實體。各種程式生成器。②規(guī)則模式利用程式變換系統(tǒng)，把用超高級規(guī)格說明語言編寫的程式轉化成某種可執(zhí)行語言的程式。IDL——CORBA的介面定義語言。一、軟體危機概述

“軟體工程”起因於“軟體危機”。60年代末期出現(xiàn)的軟體危機，使軟體陷入到“泥潭”之中。什麼是軟體危機？軟體危機是指在軟體開發(fā)過程中遇到的一系列嚴重問題，如：開發(fā)週期延長，成本增加，可靠性降低等。1.2軟體危機第一章軟體工程概述

1.1軟體技術概述1.2軟體危機1.2.1軟體危機概述

1.2.2產生的原因1.2.3解決方法1.3軟體工程1.4軟體工程環(huán)境

高級軟體工程例1IBMOS/360系統(tǒng)，有346萬條彙編語句，1968至1978年投入5000人年，共改21版，結果不能使用。例21962年美國飛往金星的探測衛(wèi)星發(fā)射失敗，原因是控制系統(tǒng)中的一個FORTRAN迴圈語句DO5I=1,3被誤寫成DO5I=1.3，由於空格對FORTRAN編譯程序沒有意義，誤寫的語句被當成了賦值語句DO5I=1.3，一點之差，使衛(wèi)星偏離軌道，只好下令引爆，導致1850萬美元的損失。DO5I=1,3

循環(huán)體5K=X/Y+34.6除了不能正常運行的軟體，軟體危機還反映在如下幾個方面：⑴對軟體成本、開發(fā)成本和開發(fā)進度的估計不準確；軟體成本在電腦系統(tǒng)總成本中所占的比例逐年上升；⑵用戶對“己完成的”軟體系統(tǒng)不滿意的現(xiàn)象時常發(fā)生；⑶軟體產品的品質往往靠不住；⑷軟體通常沒有適當的文檔資料，維護困難。⑸軟體開發(fā)生產率的提高速度遠跟不上電腦應用的普及和深入的趨勢。二、軟體危機產生的原因46年第一臺電腦“誕生”後的很長一段時間裏，人們都是用電腦來解決一些“小問題”，編制一些小程式。隨著電腦軟硬體的發(fā)展，人們用電腦來解決的問題越來越大，程式規(guī)模也越來越大，而開發(fā)大型軟體與編制小程式有一定區(qū)別：第一章軟體工程概述

1.1軟體技術概述1.2軟體危機1.2.1軟體危機概述1.2.2產生的原因

1.2.3解決方法1.3軟體工程1.4軟體工程環(huán)境

高級軟體工程⑴人員。小程式從確定要求、設計、編制、使用，直到維護通常由一個人完成；大型軟體則必須由用戶、專案負責人、分析員、初級程式員、資料員、操作員等組成一支開發(fā)隊伍來協(xié)同完成。⑵文檔。小程式是編制者腦中的“產品”，很少有書面文檔；大型軟體則是集體勞動的“產物”，必須有規(guī)範化的文檔，便於開發(fā)和維護。⑶產品。小程式通常是一次性的，如果需作大的修改，則寧可捨棄舊程式而重新編寫；但大型軟體的開發(fā)耗費了大量的人力與物力，所以不可能輕易拋棄，而總是在舊軟體的基礎上一再改動，以延長它的使用期，因此“版本”在不斷升級。大型軟體的開發(fā)提出了許多新的問題，而開發(fā)方法卻還停留在編制小程式的方法上，經驗和技巧已不能滿足開發(fā)大型軟體的需要，導致軟體開發(fā)過程混亂；使用的開發(fā)方法和技術不當，沒有適當的文檔，不易交流，維護困難，開發(fā)成本高，軟體品質低等等，這些問題是造成軟體危機的主要原因。三、軟體危機的解決方法以“工程化”的思想來指導軟體開發(fā)。軟體危機使人們認識到，軟體的研製和開發(fā)不能象以前那樣——開發(fā)過程混亂、無規(guī)範化的文檔、個體作坊式的開發(fā)，而必須立足於科學理論的基礎上，像生產產品、研製一臺機器或建造一座樓房那樣，以“工程化”的思想來指導軟體開發(fā)，解決軟體研製中面臨的困難和混亂，從根本上解決軟體危機。第一章軟體工程概述

1.1軟體技術概述1.2軟體危機1.2.1軟體危機概述1.2.2產生的原因1.2.3解決方法

1.3軟體工程1.4軟體工程環(huán)境

高級軟體工程

從技術上，以軟體工程技術、程式設計方法和技術為基礎，力求將軟體工程與知識工程、人工智慧技術結合起來，以構造基於知識的軟體開發(fā)環(huán)境；

從管理上，以管理學為依託，對開發(fā)人員、成本、專案、文檔等加強管理，對軟體開發(fā)全過程進行控制。第一章軟體工程概述高級軟體工程26第一章軟體工程概述

1.1軟體技術概述1.2軟體危機1.3軟體工程1.3.1軟體工程的概念

1.3.2軟體工程原理1.3.3軟體開發(fā)方法簡介1.4軟體工程環(huán)境

一、軟體工程的概念軟體工程是指用工程的概念、原理、技術和方法來開發(fā)和維護軟體，把經過時間考驗證明正確的管理技術和當前能夠得到的最好的技術方法結合起來，指導電腦軟體的開發(fā)和維護的工程學科。1.3軟體工程高級軟體工程第一章軟體工程概述27

軟體工程採用的生命週期方法學是指從時間的角度對軟體開發(fā)和維護的複雜問題進行分解，把軟體生存的漫長週期依次劃分為若干階段，每個階段都有相對獨立的任務，然後逐步完成每個階段的任務。軟體的生命週期：把從軟體開發(fā)專案的提出到軟體產品完成使命而報廢的整個時期。28軟體生命週期劃分為三個大的階段：軟體定義階段：包括問題定義、可行性研究和需求分析三個子階段；軟體設計階段：包括總體設計、詳細設計、編碼和測試四個子階段；軟體維護階段：使軟體在運行期間滿足用戶的需要。29圖1-1瀑布模型問題定義可行性研究需求分析總體設計詳細設計編碼與單元測試綜合測試軟體維護傳統(tǒng)瀑布模型的特點：(1)階段間有順序性和階段性(2)推遲實現(xiàn)的觀點(3)品質保證的觀點經驗表明，越早潛伏的錯誤，越晚發(fā)現(xiàn)，糾正錯誤所花費的代價也越高。因此，及時審查和糾正錯誤，是保證軟體品質、降低軟體成本的重要措施。軟體生命週期可以用瀑布模型來表示。30二、軟體工程原理

B.W.Boehm總結出七條軟體工程基本原理：⑴嚴格按照計畫進行管理；⑵堅持進行階段評審；⑶實行嚴格的產品控制；⑷採用現(xiàn)代化的程式設計技術；⑸結果應能清楚地審計；⑹開發(fā)小組的人員應該少而精；⑺承認不斷進行軟體工程實踐的必要性。第一章軟體工程概述

1.1軟體技術概述1.2軟體危機1.3軟體工程1.3.1軟體工程的概念1.3.2軟體工程原理

1.3.3軟體開發(fā)方法簡介1.4軟體工程環(huán)境

高級軟體工程31三、軟體開發(fā)方法簡介簡單介紹三種常用的方法：結構化方法、快速原型法和麵向對象法。1、結構化方法結構化方法是以“結構化”的思想、方法和工具進行軟體開發(fā)。

“結構化”是指用一組標準的準則和工具從事某項工作，它最早出自結構化程式設計。結構化程式設計

結構化系統(tǒng)設計

結構化系統(tǒng)分析第一章軟體工程概述

1.1軟體技術概述1.2軟體危機1.3軟體工程1.3.1軟體工程的概念1.3.2軟體工程原理1.3.3軟體開發(fā)方法簡介

1.4軟體工程環(huán)境

第一章軟體工程概述32結構化程式設計的基本思想：只使用順序、選擇、迴圈三種基本結構來編寫程式，它們都是單入口單出口的；使用自頂向下逐步求精的程式設計方法，即利用三種基本結構實現(xiàn)程式結構的連續(xù)分解，產生較低層次的結構，直到設計下降到能使用低層偽代碼或高級語言中的三種基本語句表達為止。結構化程式設計

結構化系統(tǒng)設計

結構化系統(tǒng)分析“GOTO語句是有害的”。結構化程式設計是成功的程式設計方法，但不能解決系統(tǒng)的結構問題，更不能解決系統(tǒng)總體模型表達方面的問題。33結構化程式設計

結構化系統(tǒng)設計

結構化系統(tǒng)分析結構化系統(tǒng)設計原則:(1)一個系統(tǒng)由層次化的程式模組構成;(2)每個模組只有一個入口和一個出口;(3)每個模組歸其上級模組調用;(4)應當構造內部聯(lián)繫緊密的模組，降低模組間的聯(lián)繫;(5)使用系統(tǒng)結構圖等圖形工具表達系統(tǒng)結構;(6)結構化設計採用自頂向下的模組化設計方法。34結構化程式設計

結構化系統(tǒng)設計

結構化系統(tǒng)分析結構化設計並不能對系統(tǒng)分析有幫助。當問題比較複雜，軟體規(guī)模較大時，系統(tǒng)分析是必不可少的階段。不論從用戶角度還是從系統(tǒng)結構設計角度都需要有一個邏輯模型定義系統(tǒng)的邏輯功能。結構化分析是定義系統(tǒng)邏輯模型的一種方法學。35結構化方法把軟體開發(fā)過程分成六個階段:調查、分析、設計、編碼、測試和維護。在分析、設計和編碼階段均採用結構化的思想和工具進行軟體的開發(fā)，如分析階段的數據流圖、數據字典、實體聯(lián)繫圖和狀態(tài)轉移圖等，設計階段的軟體結構圖、層次圖等，編碼階段的結構化編程等。36結構化方法的優(yōu)點：簡單易學，易交流。結構化方法的缺點：第一，它試圖在系統(tǒng)建立之前對用戶需求進行嚴格定義或預先加以明確說明，這通常是不切實際的；第二，用戶只參加軟體開發(fā)的軟體定義階段的工作，不易發(fā)現(xiàn)開發(fā)中的問題，導致維護代價增加。第三，靜態(tài)的建模工具（文字和圖形）缺乏直觀的感性認識。372、快速原型法原型是系統(tǒng)的早期版本，是系統(tǒng)的物理模型，只實現(xiàn)了系統(tǒng)的一些最基本的功能，反映系統(tǒng)的行為特性，但不一定滿足全部需求?？焖僭头ㄊ窃诮Y構化生命週期的編碼階段之前插入一個建立系統(tǒng)原型的階段。38建立原型分四步：第一步，確定用戶的基本需求，而不是全部需求；第二步，建立一個工作原型；第三步，試用原型；第四步，修改和補充原型。原型要求快速建立，通常只有幾周時間，所以稱這種方法為快速原型法。39快速原型法的優(yōu)點：(1)容易理解和溝通;有一個可以“運行”的物理模型；(2)通過與原型交互,用戶可以及早發(fā)現(xiàn)需求中的問題；(3)開發(fā)人員可以檢查設計的可行性?？梢栽谀繕讼到y(tǒng)的詳細設計之前較容易地改正原型設計的問題?？傊焖僭头s短了軟體開發(fā)週期，降低了開發(fā)和維護費用，也提高了用戶的滿意度?？焖僭头ㄐ枰锌焖俚亟⑾到y(tǒng)原型的工具，其中包括超高級語言。403、面向對象方法軟體的穩(wěn)定性、可修改性和可重用性比較差。結構化方法和快速原型法存在的缺陷：結構化方法和快速原型法使用的核心技術是結構分析與設計技術。41原因：(1)結構分析與設計技術的本質是功能分解;是圍繞實現(xiàn)處理功能的“過程”來構造系統(tǒng)的，而用戶需求的改動大部分是針對功能的，這必然引起軟體結構的變化。(2)它嚴格地定義了目標系統(tǒng)的邊界；很難把這樣的系統(tǒng)擴展到新的邊界，系統(tǒng)較難修改和擴充。42(3)它把處理分解成子處理的過程有些任意性；不同的開發(fā)人員開發(fā)相同的系統(tǒng)時，可能經分解而得出不同的軟體結構；(4)開發(fā)出的軟體複用性較差，或不能實現(xiàn)真正意義上的軟體複用?；渡鲜龇N種因素，誕生了一種新的軟體開發(fā)方法——面向對象方法。43面向對象方法（Objected-Oriented,OO）:

盡可能模擬人類習慣的思維方式，使軟體開發(fā)方法與過程盡可能地接近人類認識世界解決問題的方法與過程。面向對象方法:面向對象分析（Object-OrientedAnalysis,OOA）面向對象設計（Object-OrientedDesign,OOD）面向對象程式設計（Object-OrientedProgramming,OOP）最主要的特徵之一是整個生命週期使用相同的概念、表示法和策略，即每一件事都圍繞對象進行。面向對象程式設計

面向對象設計

面向對象分析44OOA是軟體開發(fā)過程中的問題定義階段。它從對問題的初始陳述開始，運用應用領域知識來識別該領域中的物理實體和概念，提取出對象，分析對象之間存在的相互關係，最後建立系統(tǒng)模型。系統(tǒng)模型描述了系統(tǒng)的對象結構，是對問題論域精確、清晰的定義。45

OOD決定如何將系統(tǒng)組織成子系統(tǒng)，每個子系統(tǒng)分成更小的子系統(tǒng)。較低層的子系統(tǒng)稱模組。一個遵循對話獨立性原則的交互軟體系統(tǒng)常分成用戶介面和應用功能核心兩個子系統(tǒng)。面向對象系統(tǒng)的控制結構方式可以是過程驅動、事件驅動或共行方式的。

OOP是將OOD的結果用一種程式設計語言實現(xiàn)。通?？偸沁x擇一種面向對象的程式設計語言。46第一章軟體工程概述

1.1軟體技術概述1.2軟體危機1.3軟體工程1.4軟體工程環(huán)境

1.4軟體工程環(huán)境軟體開發(fā)手段經歷了從手工編碼到使用支撐軟體產品的自動化軟體工具的變遷。現(xiàn)在，從軟體的開發(fā)、運行到維護各階段都有軟體工具，這些工具形成了現(xiàn)代化軟體工程環(huán)境的基礎。高級軟體工程第一章軟體工程概述47

軟體工具是指可以用來幫助開發(fā)、測試、分析、維護其他電腦程式的程式以及文檔資料的集合，它可以實現(xiàn)軟體生產過程自動化，提高軟體的生產率、可靠性，降低軟體生產成本。軟體工具在各種狀況下都能被簡單、方便地使用，能給軟體的開發(fā)帶來極大的方便。48大型軟體生產所使用的軟體工具是一種自動化系統(tǒng)，包括需求分析工具、設計工具、編碼工具、確認工具、維護工具等。

需求分析工具能夠輔助系統(tǒng)分析員把用戶所提出的含糊的用戶說明，經過分析及一致性、完備性檢查後，快速生成指導系統(tǒng)設計用的“需求規(guī)格說明書”及其相應的文檔資料。

設計工具能夠依據輸入的需求規(guī)格說明，自動設計出一系列軟體設計文檔，如軟體結構說明、模組介面說明等。

編碼工具的主要功能是輸入設計階段產生的文檔，自動生成特定語言編制的程式。如各種應用程式生成器等。49儘管軟體工具種類繁多，形式多樣，但都只是用於軟體生存週期中的某一個階段或某一個環(huán)節(jié)，而不能對整個生命週期有效。為了能夠對軟體整個生命週期提供支持，於是出現(xiàn)了軟體工程環(huán)境的新課題。

軟體工程環(huán)境(SoftwareEngineeringEnvironment,SEE)是指用以支持需求定義、程式生成，以及軟體維護等整個軟體生命週期全部活動的，並把方法、規(guī)模和電腦程式集成在一起的整個體系。軟體工程環(huán)境又稱為軟體開發(fā)環(huán)境，軟體支撐環(huán)境，自動開發(fā)環(huán)境等。50軟體工程環(huán)境的全部需求可以概括為：⑴應該是集成化的系統(tǒng)；⑵應該是通用的系統(tǒng)；⑶應該是既可剪裁又可擴充的系統(tǒng)；⑷應該是實用的、經濟合算的系統(tǒng)。51近幾年，軟體工程領域中出現(xiàn)一種新趨勢，即將軟體工程方法、工具與環(huán)境方面的新技術同形式化語義理論有機地結合起來，形成高水準的電腦輔助軟體工程(ComputerAidedSoftwareEngineering，CASE)系統(tǒng)，標誌著軟體開發(fā)技術的發(fā)展進入到一個新階段。

CASE系統(tǒng)可以幫助開發(fā)人員執(zhí)行許多和軟體開發(fā)有關的艱苦工作，包括對各種計畫、合同、規(guī)格說明、設計、源代碼和管理資訊之類的文檔進行組織。可以說，CASE系統(tǒng)可以對軟體生產過程的每一步提供輔助手段。52第二章需求分析工程第二章需求分析工程

2.1概述2.2需求分析工程2.3需求分析技術需求分析是軟體開發(fā)過程中最重要的階段，如果不清楚系統(tǒng)“做什麼？”，也就談不上“怎麼做”。把需求當作一項工程，足見需求分析的重要。高級軟體工程第二章需求分析工程53第二章需求分析工程2.1概述2.2需求分析工程2.3需求分析技術(1)在軟體生命週期中，一個錯誤發(fā)現(xiàn)越晚，修復錯誤的費用越高。(2)許多錯誤是潛伏的，且在錯誤產生後很長一段時間才被檢測出。(3)需求分析中會產生大量錯誤。(4)需求分析中的錯誤多為疏忽、不一致和二義性。(5)需求錯誤是可以被檢測出來的。因此，有必要將需求過程上升為需求工程。2.1概述一、問題的引出軟體危機引起人們對需求分析的重視。以下五個事實說明了這一點：54二、什麼是需求工程需求：是一個待開發(fā)軟體中各個有意義陳述的集合，它必須是清晰的、簡潔的、一致的和無二義性的。需求工程：是指應用已證實有效的原理、方法，通過合適的工具和記號，系統(tǒng)地描述待開發(fā)軟體及其行為和相關約束。需求工程有四個步驟：(1)需求獲取(2)需求分析(3)編寫需求規(guī)格說明書(SRS)(4)驗證55需求工程的最終目標：得到待開發(fā)軟體的系統(tǒng)模型。它必須是清晰的、易於理解的、一致的和無二義性的。模型：是對現(xiàn)實系統(tǒng)的描述，是現(xiàn)實系統(tǒng)的抽象和簡化。原型:是系統(tǒng)的早期版本，是系統(tǒng)的物理模型，只實現(xiàn)了系統(tǒng)的一些最基本的功能，反映系統(tǒng)的行為特性，但不一定滿足全部需求。56三、需求工程中的角色需求工程會涉及到三方面人員：(1)需求方對軟體開發(fā)起決定作用的一方，個人或企業(yè)等。需開發(fā)軟體者。不一定是最終用戶。(2)系統(tǒng)分析方(系統(tǒng)分析員)對待開發(fā)軟體的需求進行詳細描述。不一定與開發(fā)方同一個企業(yè)(代理，趨勢)。(3)開發(fā)方構造系統(tǒng)。設計員、編程員和專案管理員。57用戶程式員系統(tǒng)分析員SRS系統(tǒng)分析員的作用58第二章需求分析工程2.1概述2.2需求分析工程2.3需求分析技術2.2需求分析工程需求工程有四個步驟：(1)需求獲取(2)需求分析(3)編寫需求規(guī)格說明書(SRS)(4)驗證需求工程即包括這四個方面的工作。高級軟體工程59一、需求獲取

主要工作：收集資訊，理解需求，歸納整理。功能要求非功能要求弄清需求澄清概念保留合理需求拋棄不可能需求獲取的困難之處：誤解、交流障礙、缺乏共同語言、需求不完備、需求不穩(wěn)定、用戶意見不統(tǒng)一、錯誤的要求、認識混淆等，都會影響需求的獲取。

解決方法：仔細研究需求分析資料，深入進行市場調查，多與用戶溝通，請教應用領域專家，考察現(xiàn)場等。60二、需求分析需求獲取後，必須對需求進行分析。

目的：細化、精化軟體的作用範圍，確定軟體的功能和性能、約束、環(huán)境等。從兩個方面分析用戶的需求：功能性需求，非功能性需求。指系統(tǒng)必須完成的所有功能性能要求運行要求未來要求數據要求指系統(tǒng)必須完成的所有功能。

如聯(lián)機系統(tǒng)的回應時間，系統(tǒng)需要的存儲容量以及系統(tǒng)的健壯性和安全性等方面的要求。指系統(tǒng)運行所需要的軟硬體環(huán)境。指系統(tǒng)將來可能的擴充要求、可重用性、可移植性等。指系統(tǒng)所要處理的數據以及它們之間的聯(lián)繫。61需求分析工程最重要的結果是《軟體需求規(guī)格說明書》。編寫SRS的指導性原則：1.從實現(xiàn)中分離功能，即描述“做什麼”,不必描述“怎麼做”；2.要求有一個面向處理的系統(tǒng)規(guī)格說明語言，以描述系統(tǒng)級的動態(tài)行為；3.必須對以該軟體為元素的系統(tǒng)進行說明，以描述清楚系統(tǒng)各元素之間的關係；4.必須對系統(tǒng)的運行環(huán)境進行說明，以保持系統(tǒng)介面描述的一致性；三、編寫需求規(guī)格說明書(SRS)625.必須是認識的模型而不是實現(xiàn)的模型，即它必須以用戶能夠接受和理解的形式進行描述，將實際規(guī)則、條例組合到規(guī)格說明中；6.必須是可操作的；7.必須可容忍不完備性和可修改性；8.必須局部化和鬆散耦合，使得資訊發(fā)生變化時只有唯一的一個片段(理想情況下）需要修改。63四、驗證驗證即是對需求工程的結果——SRS進行評審，糾正錯誤，彌補缺陷，以保證SRS的品質。從以下幾個方面評審：正確性，無二義性，完整性，可驗證性，一致性，非電腦人員能理解，可修改性，可跟蹤性，注釋。指SRS中對需求的描述與用戶要求一致。指SRS中陳述的事情有且僅有一種解釋。包含軟體要做的全部事情。注明系統(tǒng)對有效和無效輸入的反應。注明頁碼、圖和表等的編號。存在技術和經濟上可行的手段對需求驗證和確認。術語、特性和定時等的一致，不矛盾。形式化和非形式化的矛盾。修改方便。每個需求的來源和流向清晰。向用戶和設計者給出提示。642.3需求分析技術第二章需求分析工程2.1概述2.2需求分析工程2.3需求分析技術需求分析技術有：(1)結構化分析技術(SAT)；(2)結構化分析與設計技術(SADT)；(3)面向對象技術(OOT)；(4)時序圖(5)有限狀態(tài)機(FSM)；(6)Petri網；等等。(4)、(5)、(6)用於(控制)系統(tǒng)動態(tài)分析。高級軟體工程第二章需求分析工程65時序圖可以描述系統(tǒng)中處理事件的時序與相應的處理時間。下圖中事件e被功能1、功能2和功能3處理的時間共為(T1+T2+T3)，功能間的切換時間為0。第二章需求分析工程2.1概述2.2需求分析工程2.3需求分析技術2.3.1時序圖

2.3.2有限狀態(tài)機

2.3.3Petri網2.3.1時序圖66右圖採用擴充時序圖表示進程間的通信流，可以用於分析幾個事件的交錯執(zhí)行。右圖可以做出如下分析：“必須設計成HOST1在等待C1的應答R1期間要能夠接收從HOST2發(fā)出的命令C2?！?7一、基本模型

有限狀態(tài)機(FiniteStateMachine,FSM)是一種描述控制方面特性為主的建模方法。

FSM應用於軟體生存週期的所有階段。

FSM描述如下：(1)一個有限的狀態(tài)集合Q；(2)一個有限的輸入集合I；(3)一個變遷函數：QIQ是一個狀態(tài)函數。在某一狀態(tài)下，給定輸入後FSM轉入該函數產生的新狀態(tài)。第二章需求分析工程2.1概述2.2需求分析工程2.3需求分析技術

2.3.1時序圖2.3.2有限狀態(tài)機

2.3.3Petri網2.3.2有限狀態(tài)機高級軟體工程第二章需求分析工程68頂點：表示狀態(tài)；有向邊：表示狀態(tài)的變遷。從弧尾狀態(tài)向弧頭狀態(tài)變遷。邊上的值：表示在該值的輸入下狀態(tài)發(fā)生變遷。開關按下關按下開q0q1q3q2aabbc有限狀態(tài)機變遷函數(q1,a)=q2表示在輸入值a下狀態(tài)q1轉變?yōu)闋顟B(tài)q2。左上圖有四個狀態(tài)q0,q1,q2,q3,輸入集有三個元素a,b,c。FSM用有向圖表示。69例：化學反應控制系統(tǒng)的FSM。問題描述：某化工設備中的一個控制部件?？紤]安全，要觀察和控制生產中溫度和壓力，安裝一些感測器。當某個感測器測量到的溫度和壓力中有一個超過安全值時就報警和關閉該裝置。正常後，手工重新啟動。開關高壓/示警重新啟動系統(tǒng)的有限狀態(tài)機高溫/示警正常關閉系統(tǒng)的改進有限狀態(tài)機壓力反應溫度反應溫度信號溫度信號壓力信號壓力信號恢復成功恢復成功恢復不成功恢復不成功FSM在需求分析中的作用：描述系統(tǒng)內狀態(tài)以及狀態(tài)之間的轉換。狀態(tài):(開，關)輸入:(高溫，高壓，啟動)701.“計算能力”有限

FSM最大的優(yōu)點是簡單，但系統(tǒng)複雜時就成了弱點，“計算能力”有限，因為它只能存儲有限的狀態(tài)。當狀態(tài)很多(無限)時，就無法用FSM建模。改進的辦法：(1)簡化。放棄系統(tǒng)的細節(jié)。(如前述的化學反應控制系統(tǒng))(2)轉換。改用其他模型或用FSM的變形。(3)擴充。增加新特性擴充FSM的能力。二、FSM存在的問題71例：生產者和消費者問題。

另外，F(xiàn)SM是同步模型，不能描述非同步。<1,P1,C2>狀態(tài)表示緩衝區(qū)有一個消息，生產者進程處於狀態(tài)P1，消費者進程處於狀態(tài)C2。當緩衝區(qū)容量增加後，則合併後的FSM的狀態(tài)將增加，規(guī)模增大，無法完成分析，出現(xiàn)複合增長問題。2.複合增長問題三個分離的FSM，合併(複合)後的FSM有12個狀態(tài)。72一、概述

Petri網的思想是62年由德國人C.A.Petri提出，Peterson詳細定義和描述。

Petri提出該網是用來表達非同步系統(tǒng)的控制的，但現(xiàn)在已廣泛用於硬體和軟體系統(tǒng)的開發(fā)中。用於各種系統(tǒng)的模型化。它適於描述與分析併發(fā)執(zhí)行的處理系統(tǒng)——相互獨立、協(xié)同操作的處理系統(tǒng)。在軟體分析與設計階段都可使用。2.3.3Petri網第二章需求分析工程2.1概述2.2需求分析工程2.3需求分析技術

2.3.1時序圖

2.3.2有限狀態(tài)機2.3.3Petri網高級軟體工程第二章需求分析工程73

Petri網簡稱PNG(PetriNetGraph)，是一種有向圖，它有兩種結點：(1)位置(庫所)○：表示系統(tǒng)的狀態(tài)，或使系統(tǒng)工作的條件。(2)轉移(變遷)—或|：表示系統(tǒng)中的事件。(3)有向邊：表示對轉移的輸入，或由轉移輸出：符號

：表示事件發(fā)生的前提，即對轉移(事件)的輸入；符號|

：表示事件的結束，即由轉移(事件)輸出。處於靜止狀態(tài)的系統(tǒng)二、基本理論74稱轉移的起動為激發(fā)(fire)，它是轉移的輸出。只有作為輸入的所有位置(庫所)的條件都滿足時(“使能”)才能引起激發(fā)。為了描述系統(tǒng)的動態(tài)行為，引入標記或令牌(token)(黑點)，表示處理要求的到來。例如，P3和P5出現(xiàn)了標記，表示它們有了處理的要求，即轉移t3激發(fā)的條件已經具備，轉移t3激發(fā)。執(zhí)行的結果，P3和P5的標記移去，轉移到P4上。標記在PNG上的移動，就出現(xiàn)了“狀態(tài)的遷移”。757677(1)衝突。左圖中存在兩個獨立的動作流，共用一個公共資源(P3)。兩個動作流中只有一個獲得資源並被激發(fā)，而哪一個獲得是不確定的，稱這種情況為兩個轉移(變遷)是衝突的。進程同步機制的PNG。(2)餓死。左邊的動作流總競爭到資源而不斷執(zhí)行，右邊的進程將“餓死”。並行系統(tǒng)模型,可以用Petri網描述之。78(3)衝突和資源競爭的調整。在P3中設有兩個標記(兩個共用資源)，則t3和t4就不會發(fā)生衝突和資源競爭，可以併發(fā)執(zhí)行。改進

79(4)死鎖。

執(zhí)行序列<t1,t3’,t2,t4’>，將死鎖。

Petri網很好地描述了該模型。80可達樹

PR1:寫數據到緩衝區(qū)

PR2:從緩衝區(qū)讀數據

若出現(xiàn)葉結點，則系統(tǒng)中有死鎖。81三、示例——生產者和消費者

Petri網能解決FSM存在問題。

Petri網狀態(tài)空間複雜度是各子系統(tǒng)的狀態(tài)數相加，F(xiàn)SM是相乘的關係。82<生產,寫入,生產,讀出,消費,寫入,讀出,消費>

FSM不能描述非同步問題。Petri網可以描述非同步問題。初始狀態(tài)83<生產,寫入,生產,讀出,消費,寫入,讀出,消費><生產,寫入,生產,讀出,消費,寫入,讀出,消費>84<生產,寫入,生產,讀出,消費,寫入,讀出,消費>高級軟體工程第二章需求分析工程85四、Petri網的局限性及擴展1、令牌缺乏表示資訊內容的能力令牌只是表示動作控制的流向，無法表達資訊的內容。通道1通道2P右圖轉發(fā)消息，若消息形式正確(消息中含偶數個1)，則從通道1轉發(fā)；若消息形式不正確(消息中含奇數個1)，則從通道2轉發(fā)。但是，令牌並未表達消息的內容和數值，因此，無法確定向哪個通道轉發(fā)。高級軟體工程第二章需求分析工程86對Petri網擴展，使令牌可以攜帶適當類型的值，以改善令牌缺乏表示資訊內容的能力。準備好元組:令牌的值滿足謂詞要求的元組。右圖中令牌被賦值為整數。

t1的謂詞邏輯：P2>P1,P4:=P1+P2t2的謂詞邏輯：P3=P2,P4:=P3-P2,P5:=P3+P2t1有兩個準備好元組：<3,7>,<3,4>

t2有一個準備好元組：<4,4>

若用<3,4>激發(fā)t1,則t2變?yōu)榉恰笆鼓堋?；若?lt;3,7>激發(fā)t1,則可以用<4,4>激發(fā)t2。t1令牌賦值的Petri網P13P2147P34t2P4P5通道1通道2P擴展方案同樣可解決通道選擇問題。872、缺乏描述選擇“使能”變遷的策略存在激發(fā)序列<t1,t3,t5>無限迴圈，而<t2,t4,t6>被“餓死”，原因是Petri網不能描述選擇策略。

可以對Petri網擴展，使轉移帶一定的優(yōu)先順序。如果存在多個轉移處於“使能”，則只有最大優(yōu)先順序的轉移被激發(fā)。但在一般情況下Petri網無力描述選擇策略，而不確定的Petri網是不實用的。修改Petri網，強制它使用一種選擇策略，避免了t3在t4

激發(fā)之前激發(fā)兩次。883、定時問題

Petri網不能描述有定時要求的計算問題，而很多系統(tǒng)的定時問題則很重要。右圖也可能存在定時問題,但它不能表達出來。比如，要求t2在t3之前被點燃，Petri網不能表達出來。對Petri網擴展，將時間序對<tmin,tmax>與變遷關聯(lián)，則可解決Petri網的定時問題。89加上時間序對的Petri網稱為時間Petri網。時間Petri網的思想：即使一個變遷處於使能狀態(tài)，它也必須經過tmin之後才能被點燃，且必須在tmax之前。例1，P2中獲得一個令牌。t1和t2都有可能被點燃,但只能點燃一個。例2，P4中獲得一個令牌。t1和t3都有可能被點燃,但只能點燃一個。90將時間Petri網中的變遷與優(yōu)先順序關聯(lián)，則可更加詳細地描述系統(tǒng)的定時問題。例:P2中獲得一個令牌。t1t2t3012345P4中獲得一個令牌。91下麵是時間Petri網示例。(2)建模一旦發(fā)現(xiàn)消息的兩個拷貝相同，便立即接受該消息。

tvoting1的邏輯謂詞:PC1=PC2

tvoting2的邏輯謂詞:PC1=PC3tvoting3的邏輯謂詞:PC2=PC3(1)問題描述消息被複製為三份，三份拷貝必須經過三個不同的物理通道轉發(fā)，而接收端至少接收到三個消息中的兩個相同的拷貝才認為轉發(fā)成功，並接受該消息。92右圖形式化地表示了需求的另外一個不同的解釋。此方案要求所有的消息都到達以後才進行判斷，決定接受什麼。tvoting的邏輯謂詞：

PC1=PC3或PC2=PC3;tvoting的函數：ifPC1=PC3thenPC1elseifPC2=PC3thenPC2elseifPC1=PC3thenPC1

elseERROR93五、Petri網用於系統(tǒng)分析——電梯控制系統(tǒng)設計和實現(xiàn)一個系統(tǒng)，用於控制一個高層建築中電梯的運行。要求必須高效合理地調度電梯。94一個有m層的樓中有n部電梯?？刂埔?guī)則已給定：

(1)每部電梯都有一系列的接鈕，每層對應一個按鈕。如果按下一個按鈕，則該按鈕就點亮，並且使電梯運行到相應的樓層。

(2)每一層都有兩個接鈕(UP和DOWN)，按下後要點亮。電梯到達相應樓層後，該樓層的按鈕將熄滅。同時，或者在請求服務的方向上繼續(xù)運行，或者不再有未完成的請求。如果兩個按鈕都被按下，那麼只能有一個相應的按鈕將熄滅?？刂蒲菟惴〞Q定應該先對哪一個請求進行服務，並在最少的等待時間內使兩個請求都獲得服務。1.問題描述95

(3)如果一部電梯沒有任何請求需要服務，那麼就停在最後一次服務的目的地，關閉電梯門，等待下一次服務請求。

(4)所有樓層上發(fā)出的所有要求電梯服務的請求最終都要獲得服務，所有的樓層具有相同的優(yōu)先順序。

(5)所有在電梯內發(fā)出的請求最終都要獲得服務，而且按照電梯運行的順序進行服務。

(6)每一部電梯的內部都有一個緊急情況按鈕，按下它電梯就會向電梯管理員發(fā)出-個報警信號，這部電梯就會被認為“終止服務”。每一部電梯都有一種機制使電梯脫離“終止服務”狀態(tài)。962.初步分析

(1)對說明缺省知識的補充?！懊恳粚佣加袃蓚€接鈕”。(召喚面板)(2)分清模糊不清的含義。

“電梯到達相應樓層後，該樓層的按鈕將熄滅?！?/p>

(3)查出不嚴密處?！翱刂蒲菟惴〞Q定應該先對哪一個請求進行服務，並在最少的等待時間內使兩個請求都獲得服務?！?73.電梯控制系統(tǒng)的簡單模型按鈕模型電梯在第j層電梯在第j+1層按鈕點亮按下第j+1層內部按鈕該模型太簡單，太抽象，也存在一些問題，如描述不全面、還存在一些錯誤。但它揭示了電梯位置和決定電梯運動的事件，可以此為起點，通過細化(或分解)來得到系統(tǒng)的完整模型。98

(1)構造策略需求分析的常用手段：分解和抽象。分解成一系列模組，每個模組用Petri網描述系統(tǒng)的一個部件。

(2)系統(tǒng)描述結構

n部電梯類型的說明模組

m個樓層類型的說明模組

各模組的關係及規(guī)則電梯位置類型模組：電梯所處樓層電梯按鈕類型模組：電梯內部按鈕狀態(tài)向上服務請求按鈕模組向下服務請求按鈕模組4.電梯控制系統(tǒng)的Petri網模型99(3)各模組的Petri網模型按下tmin=0.1tmin(C)=0.05tmax(C)=0.05100101第三章軟體開發(fā)的結構化方法3.1問題的定義3.2可行性研究3.3結構化分析3.4結構化設計3.5軟體測試3.6程式調試結構化方法是Yourdon、Constatine等人提出的。它是一種面向數據流的開發(fā)方法。它的一些重要概念也滲透到其他開發(fā)方法中。第三章軟體開發(fā)的結構化方法高級軟體工程第三章軟體開發(fā)的結構化方法1023.1問題的定義問題定義可行性研究需求分析總體設計詳細設計編碼與單元測試綜合測試軟體維護圖1-1

瀑布模型問題定義、可行性研究和需求分析是軟體生命週期中的軟體定義階段，而問題定義又是整個軟體生命週期的第一個步驟。第三章軟體開發(fā)的結構化方法3.1問題的定義

3.2可行性研究3.3結構化分析3.4結構化設計3.5軟體測試3.6程式調試103主要任務：是確定“軟體要解決的問題是什麼？”一、問題定義的任務如果不知道問題是什麼，或者只瞭解一點皮毛，就急於去開發(fā)軟體，顯然是盲目的，只能白白浪費時間和費用，最終開發(fā)出的軟體肯定是毫無實際意義。在實踐中又是最容易被忽視的一個步驟。104二、問題定義的結果問題定義的結果：《問題目標和規(guī)模報告書》系統(tǒng)分析員應該提出關於問題性質、工程目標和規(guī)模的書面報告。通過對系統(tǒng)的實際用戶和使用部門的訪問調查，分析員應該扼要地寫出對問題的理解，並在用戶和使用部門負責人參加的會議上認真討論這份報告，澄清含糊的地方，改正分析員理解得不正確的地方，最後得出一份令雙方都滿意的問題定義文檔。1053.2可行性研究一、可行性研究的任務主要任務：(1)“確定問題定義階段定義的問題是否有可行的解？”(2)對建議的系統(tǒng)進行仔細的成本／效益分析。並不是所有問題都有簡單明顯的解決方法。第三章軟體開發(fā)的結構化方法3.1問題的定義3.2可行性研究

3.3結構化分析3.4結構化設計3.5軟體測試3.6程式調試106二、可行性研究的目的可行性研究的目的：就是用最小的代價，在最短的時間內確定問題是否能夠解決，是否值得去解決。從以下四個方面分析系統(tǒng)的可行性：⑴技術可行性。分析系統(tǒng)採用的技術是否先進，能否實現(xiàn)系統(tǒng)目標，開發(fā)人員的素質是否具備等。⑵經濟可行性。分析目標系統(tǒng)能否用最小的代價獲得最大的經濟效益、社會效益和技術進步。⑶操作可行性。分析系統(tǒng)的操作方式在用戶範圍內是否可行。⑷法律可行性。分析系統(tǒng)開發(fā)可能造成的責任問題。有無違法行為？如合同的責任問題、專利版權問題等。107問題定義階段提出的對工程目標和規(guī)模的報告通常比較含糊。可行性研究階段應導出系統(tǒng)的高層邏輯模型（通常用數據流圖表示），並且在此基礎上更準確、更具體地確定工程規(guī)模和目標。分析員更準確地估計系統(tǒng)的成本和效益。對建議的系統(tǒng)進行仔細的成本／效益分析是這個階段的主要任務之一。108三、可行性研究的結果可行性研究的結果是使部門負責人作出是否繼續(xù)進行這項工程決定的重要依據，一般說來，只有投資可能取得較大效益的那些工程專案才值得繼續(xù)進行下去。對不值得投資的工程專案,系統(tǒng)分析員則應建議終止，可以避免更大的浪費。可行性研究的結果:《可行性研究報告》。1093.3結構化分析第三章軟體開發(fā)的結構化方法3.1問題的定義

3.2可行性研究3.3結構化分析3.3.1結構化設計方法概述3.3.2數據流圖3.3.3數據字典3.3.4處理的邏輯表達方式3.3.5數據分析可行性研究後，軟體系統(tǒng)就可以立項開發(fā)，進入軟體需求分析階段。該階段的任務不是具體解決問題，而是準確地確定“為了解決這個問題，目標系統(tǒng)必須做什麼”的問題，主要是確定目標系統(tǒng)必須具備哪些功能。110從五個方面分析系統(tǒng)的綜合要求：⑴功能要求。指系統(tǒng)必須完成的所有功能。⑵性能要求。如聯(lián)機系統(tǒng)的回應時間，系統(tǒng)需要的存儲容量以及系統(tǒng)的健壯性和安全性等方面的要求。⑶運行要求。指系統(tǒng)運行所需要的軟硬體環(huán)境。⑷未來要求。指系統(tǒng)將來可能的擴充要求。⑸數據要求。指系統(tǒng)所要處理的數據以及它們之間的聯(lián)繫。需求分析的結果：《需求規(guī)格說明書》111系統(tǒng)分析員在需求分析階段必須和用戶密切配合，充分交流資訊，分析系統(tǒng)的綜合要求，導出經過用戶確認的系統(tǒng)邏輯模型。系統(tǒng)邏輯模型完整準確地反映了用戶的要求，是以後設計和實現(xiàn)目標系統(tǒng)的基礎。需求分析有多種方法和工具，其中結構化分析方法是目前常用的方法之一。適用於分析大型的數據處理系統(tǒng)。1123.3.1結構化分析方法概述結構化分析（StructuredAnalysis,SA）採用軟體工程中控制複雜性的兩個基本手段：“分解”和“抽象”，將系統(tǒng)自頂向下逐層分解，直到找到滿足所有功能要求的可實現(xiàn)軟體為止。分解：為把複雜性降到人們可以掌握的程度，將複雜的問題拆成若干小問題再分別解決的過程。抽象：先考慮問題最本質的屬性，暫時略去細節(jié)，再逐層添加細節(jié)，直至達到必要的詳細程度(理解和表達)。第三章軟體開發(fā)的結構化方法

3.3結構化分析

3.3.1結構化設計方法概述

3.3.2數據流圖3.3.3數據字典3.3.4處理的邏輯表達方式3.3.5數據分析113SA方法具有如下特點：⑴用戶共同參與系統(tǒng)開發(fā)，面向用戶；⑵建立系統(tǒng)的邏輯模型，強調邏輯而不是物理；⑶使用圖表工具明確表達系統(tǒng)邏輯模型，作為與用戶和系統(tǒng)開發(fā)人員的通訊媒介；⑷採用自頂向下的方法進行系統(tǒng)分析；⑸使用同一份系統(tǒng)分析資料，避免了重複性，增強了一致性。114大多數電腦系統(tǒng)都是用來替代一個已存在的系統(tǒng)，它可以是一個電腦系統(tǒng)也可以是一個人工系統(tǒng)。SA可按如下步驟進行：⑴分析當前系統(tǒng)，導出當前系統(tǒng)的物理模型(用DFD描述)；⑵從當前系統(tǒng)的物理模型抽象出當前系統(tǒng)的邏輯模型(用DFD描述)；⑶分析目標系統(tǒng)與當前系統(tǒng)邏輯上的差別，建立目標系統(tǒng)的邏輯模型；⑷補充目標系統(tǒng)的邏輯模型。115

SA方法採用介於形式語言和自然語言之間的描述方式書寫系統(tǒng)《需求規(guī)格說明書》。系統(tǒng)《需求規(guī)格說明書》包括四個部分：⑴一套分層的數據流圖；⑵一本數據字典；⑶一組小說明；⑷補充材料，如表達數據分析結果的實體聯(lián)繫圖等。116SA方法從總體上看是一種強烈依賴數據流圖的自頂向下的建模方法，它不但是需求分析技術，也是完成規(guī)格說明文檔的技術手段。

SA方法能夠清楚地提供組織和描述系統(tǒng)資訊的方法，也提供了檢查資訊精確性的指標，為理解和分析一個現(xiàn)存系統(tǒng)提供了有效的工具。

總之，SA方法的本質就是採用一套分層的數據流圖及相應的數據字典和小說明來作為系統(tǒng)的模型(建模工具)。1173.3.2數據流圖數據流圖是描述系統(tǒng)邏輯功能的圖形工具，用來表達系統(tǒng)的邏輯功能。

數據流圖中無具體物理元素如顯示終端、磁片檔、列印輸出等。表明數據在系統(tǒng)內的邏輯流向和數據的邏輯處理。數據流圖是結構化方法的核心。數據流圖有四種基本成分：外部項、處理、數據流和數據存儲。第三章軟體開發(fā)的結構化方法

3.3結構化分析3.3.1結構化設計方法概述

3.3.2數據流圖

3.3.3數據字典3.3.4處理的邏輯表達方式3.3.5數據分析118數據流圖的四種基本成分(外部項、處理/加工、數據流、數據存儲)：⑴外部項（源點或匯點）。

外部項是指系統(tǒng)以外的事物、人或組織，它表達了該系統(tǒng)數據的外部來源或去處。用方框□表示。方框內是外部項的名字。名字通常是名詞，如人或事物。為避免在數據流圖上出現(xiàn)數據流的線條交叉，同一外部項可以在一張圖上出現(xiàn)若干次。確定了外部項，實際上也就確定了系統(tǒng)和外部環(huán)境的分界線。119

處理表達了對數據的邏輯加工或變換功能。對數據的加工處理的結果，或是變換了的數據的結構，或是在原有數據的基礎上產生新的數據。處理用圓○表示，圓中是處理的名字。名字應恰當地反映處理的含義，使之容易理解，通常是動賓結構?？梢杂脭底謱祿鲌D中的處理編號。一個處理可以對應於一個模組，一個程式，也可以是“穿孔”、“列印輸出”或者甚至是“目視檢查數據正確性”的人工處理過程。⑵處理(加工)。120

數據流指示數據的流動方向。用帶箭頭的直線→或弧線表示。直線或弧線上帶有數據流的名稱。名稱通常是名詞。數據流可以由一個外部項產生，也可由某一處理產生，或者來自某一數據存儲。數據流的含義：(a)數據流是成份已知的資訊包；(b)數據流經處理後可合併或分解；(c)意義清楚時可省略數據流名；(d)數據流不是控制流。⑶數據流。121

數據存儲指明了保存數據的地方。它並不代表具體的存儲介質?？梢允菣n的一個部分、資料庫的元素或記錄的一部分。數據可以存儲在磁片、磁帶、記憶體及任何物理介質。數據存儲使用右端開口的矩形框表示?？騼葮擞写鎯Φ臄祿拿Q，通常是名詞。同外部項一樣，為避免圖中線條交叉，可在一張圖中多次出現(xiàn)相同的數據存儲，這時只須在矩形左側加豎線，並標上數據存儲的名字。⑷數據存儲。122數據流圖的畫法：採用自頂向下的方法分層(先外後內)畫。畫數據流圖的步驟：(1)提取數據流圖中的四個基本成分；(2)畫出高層數據流圖；(3)逐層分解較高層數據流圖中的處理，得到一套分層數據流圖；(4)命名各元素。123分解數據流圖時應遵循下列原則：⑴分解要自然，概念要合理；⑵以分層方式對處理編號；⑶注意父圖與子圖的平衡，即子圖中所有的輸入和輸出數據流應當和父圖中相應處理的輸入和輸出數據流一致；⑷一個處理一般可分解成７士２個子處理，不宜過多；⑸當進一步分解可能涉及具體的物理實現(xiàn)手段時，分解應終止。124某工廠採購部門每天要開出定貨清單，清單中包括訂購部件的部件號、部件名、規(guī)格、說明、訂購量、當前價格、主要供應商和輔助供應商。部件入庫或出庫稱為業(yè)務，通過倉庫中的終端把業(yè)務報告給定貨系統(tǒng)，處理庫存業(yè)務。當某種部件的庫存量少於標準線以下時，倉庫管理員就應該及時通知定貨系統(tǒng)開出定貨清單，交由採購員採購。例子：125根據畫數據流圖的步驟畫出定貨系統(tǒng)的數據流圖。(1)從系統(tǒng)的簡述中提取數據流圖的四個成分;1)源點和匯點。倉庫管理員視為源點，採購員視為匯點。2)處理。處理通常是系統(tǒng)簡述中的動詞短語，如產生定貨清單，處理庫存業(yè)務等。3)數據流。從系統(tǒng)的源點流出和流入匯點的數據流即是系統(tǒng)的輸入數據流和輸出數據流。4)數據存儲。確定哪些數據應保存在數據存儲中。庫存業(yè)務一旦產生就立即被處理，所以不必保存。定貨清單一天只產生一次，故需要保存產生定貨清單的數據。有關庫存零部件的資訊包括定貨標準線也應作為數據存儲，統(tǒng)稱為庫存數據。126定貨系統(tǒng)數據流圖的基本成分源點/匯點處理數據流數據存儲管理員產生定貨清單 定貨清單定貨數據採購員處理庫存業(yè)務庫存業(yè)務庫存數據注意：這些成分有的直接從系統(tǒng)問題簡述中提取，有的則是隱含在問題簡述中。127(2)畫出系統(tǒng)的高層數據流圖;高層數據流圖強調源點、匯點和輸入輸出數據流。(3)逐步分解高層數據流圖;高層數據流圖畢竟太抽象了，需要分解其中的處理，得到功能級的數據流圖。128通過分解關鍵處理，對數據流圖進行細化，得到細化的數據流圖。注意：分解過程中要遵循數據流圖的分解原則。最後必須檢查得到的數據流圖，注意數據是否守恆，父圖和子圖是否平衡。129(1)簡潔、清楚地描述了系統(tǒng)的邏輯模型，易於理解和評價。數據流圖是結構化軟體設計的基礎，由它出發(fā)可以映射出軟體的結構。(2)作為資訊交流的工具，數據流圖易於系統(tǒng)分析員與用戶交流。數據流圖的優(yōu)點：數據流圖反映了數據在系統(tǒng)中的流向和數據被加工處理的情況，但它無法詳細描述數據流、數據存儲、處理邏輯和外部項的內容，這樣數據流圖就不嚴格，也難以發(fā)揮作用，因此還必須輔以其他工具。這些工具包括數據字典、結構化自然語言、判定表和判定樹等。1303.3.3數據字典數據字典是關於數據資訊的集合，也就是對數據流圖中四個基本成分詳細定義或說明的集合?；緮祿?簡稱數據元素)是數據字典中數據的最小單位，不可再分解。若干數據元素，或若干數據元素加上數據的結構構成數據結構。第三章軟體開發(fā)的結構化方法

3.2可行性研究3.3結構化分析3.3.1結構化設計方法概述3.3.2數據流圖

3.3.3數據字典

3.3.4處理的邏輯表達方式3.3.5數據分析為便於查閱，數據字典中的條目應按一定次序排列，並提供檢索手段。高級軟體工程第三章軟體開發(fā)的結構化方法131數據字典中除了數據流圖中的四個成分需描述外，還要包括數據元素和數據結構一覽表。定貨系統(tǒng)數據字典。132133另外，還可以用數據字典運算符描述。=:由...組成；+:和；供應商=供應商編號+供應商名稱+供應商地址{}:重複；課程表={星期幾+第幾節(jié)+教室}[|]:選擇一個；存期=[1|2|5]():可選(也可不選)。1343.3.4處理的邏輯表達方式數據流圖中的每個“處理”應該有一個“小說明”，用來描述處理的邏輯加工。小說明通常採用結構化自然語言、判定樹、判定表等工具來表達處理的邏輯。第三章軟體開發(fā)的結構化方法

3.2可行性研究3.3結構化分析3.3.1結構化設計方法概述3.3.2數據流圖3.3.3數據字典

3.3.4處理的邏輯表達方式3.3.5數據分析一般對數據流圖中最底層的“處理”進行定義。高級軟體工程135⒈結構化自然語言結構化自然語言的辭彙表包括數據字典中定義的數據元素、數據結構、數據流等名詞，加上自然語言中有限的含義明確的執(zhí)行性動詞以及一些常用的運算符，包括算術、關係和邏輯運算符等。使用的語句僅限於簡單的祈使語句，判斷語句和迴圈語句以及由這三種語句組成的複合語句。結構化自然語言是介於自然語言和程式設計語言之間的一種半形式語言。它是在自然語言的基礎上加上了有限的辭彙和語句而形成的語言。136下麵是結構化自然語言的語句表達處理1.1“接收庫存業(yè)務”的例子：GET庫存業(yè)務；EDIT庫存業(yè)務；IF庫存業(yè)務有錯

THEN置庫存業(yè)務的錯誤標誌

ELSE去掉庫存業(yè)務的錯誤標誌1372.判定樹

表示判斷邏輯使用判定表、判定樹比結構化自然語言更直觀、清楚，易於理解。判定樹是表達嵌套的多層判斷的有效工具。例如:某工廠的職工超產獎勵政策如下：對產品X，實際生產數量超過計畫指標50件（含50件）以下，每超產1件獎勵1元；超產數量在51～100件，超過50件部分，每超產１件獎勵1.2元；超產數量在100件以上，超過100件部分，每超產1件獎勵1.5元。對產品Y，實際生產數量超過計畫指標25件以下（含25件），每超產1件獎勵2元；超產數量在25件以上，每超產1件獎勵3元。138獎勵政策用判定樹表達如下：139判定表是表達條件和操作之間相關關係的一種規(guī)範的方法。⒊判定表

當某個處理依賴於多個邏輯條件時，判定表比判定樹更有效。例如一個用結構化自然語言表達的“檢查訂購單”處理的邏輯描述如下：

IF金額超過500元且未過期

THEN發(fā)出批準單和提貨單；

IF金額超過500元且已過期

THEN不發(fā)批準單；

IF金額低於500元

THEN不論是否過期都發(fā)批準單和提貨單，在過期的情況下還發(fā)出通知書。140用判定表描述下表。判定表和判斷樹只適合表達判斷，不適宜表達迴圈。1413.3.5數據分析軟體系統(tǒng)本質上是資訊處理系統(tǒng)，在軟體系統(tǒng)的整個開發(fā)過程中都應該考慮兩個方面的問題——“數據”及對數據的處理。因此，分析系統(tǒng)的數據要求是系統(tǒng)分析的一個重要任務。第三章軟體開發(fā)的結構化方法

3.2可行性研究3.3結構化分析3.3.1結構化設計方法概述3.3.2數據流圖3.3.3數據字典3.3.4處理的邏輯表達方式

3.3.5數據分析高級軟體工程第三章軟體開發(fā)的結構化方法142在細化數據流圖的過程中，已收集了數據元素並錄入數據字典中。數據結構表示數據元素間的邏輯關係。數據流和數據存儲中的數據是基於數據的結構的，這並不是數據的最恰當的組織方式，通常用ER（Entity-Relationship）圖表示數據的組織及數據之間的關係。為減少數據冗餘，簡化修改數據的過程，還應該對數據進行規(guī)範化。系統(tǒng)的數據分析應當包括收集系統(tǒng)所使用的數據，適當地將數據元素組織成合理的數據結構。1433.4結構化設計分析階段得到了軟體的《需求規(guī)格說明書》，它明確地描述了用戶要求系統(tǒng)“做什麼”的問題，下麵是決定“怎麼做”的時候了，即建立一個符合用戶需求的軟體系統(tǒng)。軟體開發(fā)進入軟體設計階段。第三章軟體開發(fā)的結構化方法3.1問題的定義3.2可行性研究3.3結構化分析3.4結構化設計3.5軟體測試3.6程式調試144設計階段通常分為兩步：軟體設計方法有多種，本節(jié)介紹結構化設計方法。第一步：系統(tǒng)的總體設計或一般設計。它的任務是確定軟體結構。第二步：系統(tǒng)的詳細設計。進行各模組內部的具體設計。1453.4.1結構化設計方法概述第三章軟體開發(fā)的結構化方法3.3結構化分析3.4結構化設計

3.4.1結構化設計方法概述3.4.2軟體結構圖3.4.3軟體設計原理3.4.4軟體設計原則3.4.5結構化軟體設計策略3.4.6資料庫的邏輯設計結構化設計（StructuredDesign,SD）方法用於設計軟體結構。SD的目標：根據系統(tǒng)分析資料確定軟體應由哪些子系統(tǒng)或模組組成，它們應採用什麼方式連接，介面如何，才能構成一個好的軟體結構，如何用恰當的方法把設計結果表達出來。同時考慮資料庫的邏輯設計。146SD方法的基本思想：採用自頂向下的模組化設計方法，按照模組化原則和軟體設計策略，將軟體分析得到的數據流圖，映射成由相對獨立、單－功能的模組組成的軟體結構。

SD是一種面向數據流的設計方法。兩種數據流圖：變換型和事務型。將數據流圖映射為軟體結構也就有兩種方法：(1)以變換為中心的方法;變換型的軟體結構(2)以事務為中心的方法;事務型的軟體結構。147SD方法的優(yōu)點：(2)減少設計複雜性，研製工作得以簡化，縮短了軟體開發(fā)週期，也減少了開發(fā)軟體所需的人力。(3)模組的相對獨立性也能有效地防止錯誤在模組之間擴散蔓延,提高了系統(tǒng)的可靠性。(1)模組可以獨立地被理解、編程、調試、排錯和修改(4)提高了代碼的可複用性。1483.