上海交通大學(xué)計算機集成技術(shù)開放實驗室第6講需求分析.ppt

《上海交通大學(xué)計算機集成技術(shù)開放實驗室第6講需求分析.ppt》由會員分享，可在線閱讀，更多相關(guān)《上海交通大學(xué)計算機集成技術(shù)開放實驗室第6講需求分析.ppt（88頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、2020/7/14,1,第6講 需求分析,2020/7/14,2,內(nèi)容,需求分析的重要性 需求分析的困難性 需求工程 需求分析過程 概念模型和規(guī)范化 圖形工具 需求驗證 原型技術(shù),2020/7/14,3,需求分析,需求分析是軟件定義時期的最后一個階段 回答“系統(tǒng)必須做什么？”的問題,2020/7/14,4,需求分析的重要性,真的很重要嗎？ 例：Our real-time example is based on the embedded software in the Ariane-5, a space rocket belonging to the European Space Agency

2、(ESA). On June 4, 1996, on its maiden flight, the Ariane-5 was launched and performed perfectly for approximately 40 seconds. Then, it began to veer off course. At the direction of an Ariane ground controller, the rocket was destroyed by remote control. The destruction of the uninsured rocket was a

3、loss not only of the rocket itself, but also of the four satellites it contained; the total cost of the disaster was $500 million (Newsbytes home page 1996; Lions et al. 1996).,2020/7/14,5,需求分析的重要性,The reason: there was no discussion in the requirements documents of the ways in which the Ariane-5 tr

4、ajectory would be different from Ariane-4.,統(tǒng)計資料： In 1994, the Standish Group surveyed over 350 companies about their over 8000 software projects to find out how well they were faring. The results are sobering. Thirty-one percent of the software projects were canceled before they were completed. More

5、over, in large companies, only 9% of the projects were delivered on time and cost what they were budgeted, and 16% met those criteria in small companies (Standish 1994).,2020/7/14,6,需求分析的重要性,2020/7/14,7,需求分析的重要性,5點事實 軟件生命周期中，一個錯誤發(fā)現(xiàn)得越晚，修復(fù)錯誤的費用越高,2020/7/14,8,需求分析的重要性,許多錯誤是潛伏的，并且在錯誤產(chǎn)生后很長一段時間才被檢查出來 在需求過

6、程中會產(chǎn)生很多錯誤 DeMarco在一份研究報告中指出，被檢查出來的錯誤的56產(chǎn)生的根源可以追溯到需求階段。 AIRMICS所進行的一項調(diào)查發(fā)現(xiàn)，在一份美國軍方大型管理信息系統(tǒng)的需求現(xiàn)格說明書(SRS)中存在著500多個錯誤，當(dāng)然這僅僅是一個軟件項目中的一次調(diào)查。 在需求階段，代表性的錯誤為疏忽、不一致和二義性 美國海軍研究實驗室從20世紀(jì)70年代起就對軟件開發(fā)技術(shù)不斷地進行研究。他們對海軍A7E它機上的”宅行操作程序進行實地測試，以驗證許多新設(shè)想的可行性。得出的研究數(shù)據(jù)表明：A7E項目中77的需求錯誤特點是不明確：疏忽、不一致和二義性。按錯誤類型對這些錯誤分布進行分析的結(jié)果是： 49不正確的

7、事實，31疏忽，l 3不一致，5二義性,2020/7/14,9,需求分析的重要性,需求錯誤是可以被檢查出來的,2020/7/14,10,需求分析的重要性,在需求過程中會產(chǎn)生很多錯誤(事實3和4)。 許多錯誤并沒有在早期被發(fā)現(xiàn)(事實2)。 這樣的錯誤是能夠在產(chǎn)生的初期被檢查出來的(事實5)。 如果沒有及時檢查出來這些錯誤，軟件費用會直線上升(事實1),2020/7/14,11,需求管理的困難性,2020/7/14,12,需求工程,需求是什么?需求就是以一種清晰、簡潔、一致且無二義性的方式，對一個待開發(fā)系統(tǒng)中各個有意義方面的陳述的一個集合。 需求工程一般指應(yīng)用已證實有效的原理、方法，通過合適的工具

8、和記號，系統(tǒng)地描述出待開發(fā)系統(tǒng)及其行為特征和相關(guān)約束；通常是一些過程的集合：需求獲取(需求引出)、需求分析和編寫軟件規(guī)格說明書(SRS)及驗證(包括鑒定和證實)。,2020/7/14,13,需求工程涉及人員,2020/7/14,14,軟件需求,功能需求 性能需求 環(huán)境需求 可靠性需求 安全保密要求 用戶界面需求,資源使用需求 成本消耗需求 開發(fā)進度需求 預(yù)先估計以后系統(tǒng)可能達到的目標(biāo),2020/7/14,15,需求分析與程序分析的不同,2020/7/14,16,需求分析現(xiàn)狀,誤解 交流障礙 缺乏共同語言 “完整性”問題 需求永遠(yuǎn)不會穩(wěn)定 用戶意見不統(tǒng)一 錯誤要求 認(rèn)識混淆,2020/7/14,

9、17,需求分析的任務(wù),可行性分析階段已經(jīng)粗略了解了用戶的需求，甚至已經(jīng)提出了一些可行的方案，但是，可行性研究的基本目的是用較小的成本在較短的時間內(nèi)確定是否存在可行的方案。因此許多細(xì)節(jié)被忽略。 在系統(tǒng)開發(fā)前，還需要進一步確定,2020/7/14,18,需求分析的任務(wù),Final stage of Definition phase,仍然回答“What”，而不是“How”， 但更細(xì)致、精確（合同的擬定）,2020/7/14,19,需求分析的任務(wù),完整 準(zhǔn)確 清晰 具體,2020/7/14,20,需求分析的任務(wù),2020/7/14,21,需求分析的任務(wù),1、確定要求 功能要求(functional r

10、equirements):系統(tǒng)必須做什么？ 性能要求(performance requirements)：做得怎樣？ 例：response time , memory , back-up memory , security , 運行要求(operational requirements) ：運行環(huán)境、軟硬件配置等。 未來可能的擴充要求(possible evolution)：如3維虛擬現(xiàn)實的效果等等。,2020/7/14,22,需求分析的任務(wù),2分析數(shù)據(jù) 建立概念模型(conceptual models): E-R Diagram 形象描繪數(shù)據(jù)結(jié)構(gòu): Data Hierarchy, Warni

11、er Diagram, IPO 數(shù)據(jù)結(jié)構(gòu)規(guī)范化(Normalization),3、導(dǎo)出邏輯模型： DFD + DD + IPO,4、修正計劃：重估成本、進度等,2020/7/14,23,需求分析的任務(wù),“樣機 試用”,C,D,G,5、開發(fā)原型系統(tǒng)(Prototyping),2020/7/14,24,分析過程,軟件系統(tǒng)本質(zhì)上是信息處理系統(tǒng)，任何信息處理系統(tǒng)的基本功能都是把輸入數(shù)據(jù)轉(zhuǎn)變成需要的輸出信息 數(shù)據(jù)是分析的出發(fā)點，在可行性分析階段許多實際的數(shù)據(jù)元素被忽略了，需求分析階段將定義這些數(shù)據(jù)元素 結(jié)構(gòu)化分析方法就是面向數(shù)據(jù)流自頂向下逐步求精進行需求分析的方法,2020/7/14,25,分析過程,1

12、、沿DFD回溯 （1）DFD的輸出端是系統(tǒng)的最終目的 （2）向回確定每個數(shù)據(jù)元素的來源 （3）為了得到某個數(shù)據(jù)元素需要用到數(shù)據(jù)流圖中目前還沒有的數(shù)據(jù)元素，或者得出某個數(shù)據(jù)元素需要用的算法尚不清楚，可加細(xì)DFD及DD，并將相關(guān)算法記錄在IPO圖中。,2020/7/14,26,分析過程,2、用戶復(fù)查 數(shù)據(jù)字典準(zhǔn)確完整嗎？ 算法正確嗎？ 有沒有遺漏必要的處理或數(shù)據(jù)元素？ 某些數(shù)據(jù)元素是從哪里來的？ 構(gòu)成一個循環(huán)，認(rèn)識螺旋式上升,2020/7/14,27,分析過程,3、細(xì)化DFD： 加細(xì)前后的IO須相同。 分解到須考慮具體實現(xiàn)的代碼時即可仃止,2020/7/14,28,分析過程,4、修正計劃 5、文檔

13、：需求規(guī)格說明書,2020/7/14,29,需求分析規(guī)格說明書,2020/7/14,30,需求分析規(guī)格說明書,系統(tǒng)規(guī)格說明： 系統(tǒng)概貌 功能要求 性能要求 運行要求 可能增加的要求 DFD IPO, 數(shù)據(jù)要求： DD Hierarchy 或 Warnier Diagram, 用戶系統(tǒng)描述 初步用戶手冊：從用戶的觀點考慮系統(tǒng) 系統(tǒng)功能、性能 使用與步驟 等,修正的開發(fā)計劃： 成本估計 資源使用計劃 進度計劃,2020/7/14,31,需求分析規(guī)格說明書,從現(xiàn)實中分離功能，即描述要“做什么”而不是“怎樣實現(xiàn)” 要求使用面向處理的規(guī)格說明語言（或稱系統(tǒng)定義語言） 如果被開發(fā)軟件只是一個大系統(tǒng)中的一個

14、元素，那么整個大系統(tǒng)也包括在規(guī)格說明的描述之中 規(guī)格說明必須包括系統(tǒng)運行環(huán)境 規(guī)格說明必須是一個認(rèn)識模型 規(guī)格說明必須是可操作的 規(guī)格說明必須容許不完備性并允許擴充 規(guī)格說明必須局部化和松散耦合,2020/7/14,32,分析過程,輕松一分鐘 True Tech Support Stories A woman complied with a techs request to send in a copy of a defective diskette. A few days later, the tech received a letter from her along with a xero

15、x copy of the floppy. A tech advised a customer to put his troubled floppy back in the drive and close the door. The customer put his phone down and was heard walking across the room and shutting the door to the room.,2020/7/14,33,分析過程,節(jié)選自目前我國的一些實際系統(tǒng)中的功能性需求的說明方式：“根據(jù)詳細(xì)的系統(tǒng)調(diào)研和需求分析，系統(tǒng)的功能必須滿足以下需求： 1)編制計劃

16、、計劃工程撥款管理，工程批復(fù)管理，工程進度統(tǒng)計； 2)工程項目管理； 3)計劃撥款、征費收繳信息及其他收撥款信息查詢統(tǒng)計； 4)路產(chǎn)管理，違章建筑管理，工程材料管理，超限運輸管理； 5)養(yǎng)征信息查詢管理，收費站信息管理； 6)文檔管理，會議管理，合同管理，駕駛員外勤管理，常用管理； 7)養(yǎng)護信息管理，公路維護預(yù)警； 8)路況信息管理，交通量信息管理，科研項目信息管理；,2020/7/14,34,需求表達,需求說明語句 保持語句和段落的簡短 采用主動語態(tài)的表達方式 編寫具有正確的語法和標(biāo)點的完整句子 使用的術(shù)語應(yīng)該和詞匯表中定義的一致 需求陳述應(yīng)該具有一致的式樣，例如“系統(tǒng)必須”，或者“用戶必須

17、”，并緊跟一個行為動作和可觀察的結(jié)果，例如“倉庫管理子系統(tǒng)必須現(xiàn)實一張在所請求的倉庫中有存貨的藥品名單。”,2020/7/14,35,需求表達,為了減少不確定性，避免采用模糊的、主觀的術(shù)語，例如，用戶友好、容易、簡單、迅速、有效、支持、許多、最新技術(shù)、優(yōu)越的、可接受的和健壯的。 避免使用比較性的詞匯，例如：提高，最大化，最小化和最佳化。定量地說明所需要提高的程度或者說清一些參數(shù)可接受的最大值和最小值。,2020/7/14,36,需求表達,“產(chǎn)品必須在固定的時間間隔內(nèi)提供狀態(tài)消息，并且每次時間間隔不得小于60秒” 后臺任務(wù)管理器應(yīng)該在用戶界面的指定區(qū)域顯示狀態(tài)消息 在后臺任務(wù)進程啟動之后，消息必

18、須每隔60（+_10）秒更新一次，并且保持連續(xù)的可見性。 如果正在正常處理后臺任務(wù)進程，那么后臺任務(wù)管理器必須顯示后臺任務(wù)進程已完成的百分比 當(dāng)完成后臺任務(wù)時，后臺任務(wù)管理器必須顯示一個“已完成”的消息。 如果后臺任務(wù)中止執(zhí)行，那么后臺任務(wù)管理器必須顯示一個出錯信息。,2020/7/14,37,需求表達,“產(chǎn)品必須在顯示和隱藏非打印字符之間進行瞬間切換” “用戶在編輯文檔時，通過激活特定的觸發(fā)機制，可以在顯示和隱藏所有HTML標(biāo)記之間進行切換。”,2020/7/14,38,需求表達,“分析程序應(yīng)該能生成HTML標(biāo)記出錯的報告，這樣就可以使HTML的初學(xué)者使用它來迅速排錯” 在HTML分析程序完

19、全分析完一個文件后，該分析程序必須生成一個出錯報告，這個報告中包含了在分析文件中所發(fā)生錯誤的HTML所在的行號以及文本內(nèi)容，還包含了對每個錯誤的描述。 如果分析過程中未發(fā)生任何錯誤，就不必生成任何錯誤報告,2020/7/14,39,分析過程,第六步 審查和復(fù)審 以上六步構(gòu)成一個循環(huán),2020/7/14,40,需求分析過程,2020/7/14,41,概念模型和規(guī)范化,軟件系統(tǒng)開發(fā)過程中必須考慮兩方面的問題 “數(shù)據(jù)”及對數(shù)據(jù)的“處理” 為了把用戶的數(shù)據(jù)要求清晰明確地表達出來，系統(tǒng)分析員通常建立一個概念性的數(shù)據(jù)模型（也稱為信息模型）。概念性數(shù)據(jù)模型是一種面向問題的數(shù)據(jù)模型，是按照用戶的觀點來對數(shù)據(jù)和

20、信息建模。,2020/7/14,42,概念模型和規(guī)范化,最常用的表示概念性數(shù)據(jù)模型的方法，是實體聯(lián)系方法（Entity-Relationship Approach） ER圖描述現(xiàn)實世界中的實體，而不涉及這些實體在系統(tǒng)中的實現(xiàn)方法。,2020/7/14,43,概念模型和規(guī)范化,實體是客觀世界中存在的且可相互區(qū)分的事務(wù)。實體可以是人也可以是物，可以是具體的事物也可以是抽象概念。例如，職工、學(xué)生、課程、教師等都是實體。,2020/7/14,44,概念模型和規(guī)范化,客觀世界中的事物彼此間往往是有聯(lián)系的，例如，教師與課程間存在“教”這種聯(lián)系。,2020/7/14,45,概念模型和規(guī)范化,屬性是實體或聯(lián)系

21、所具有的性質(zhì)。通常一個實體由若干個屬性來刻畫。 例如，“學(xué)生”實體有學(xué)號、姓名、性別、系、年級,2020/7/14,46,概念模型和規(guī)范化,例：,2020/7/14,47,概念模型和規(guī)范化,2、范式(Normal Forms)：消除數(shù)據(jù)冗余的程度 IBM E. F. Godd (1970) 例：,*Keyword:可唯一地標(biāo)識一個元組的屬性,2020/7/14,48,概念模型和規(guī)范化,范式級別越高，存儲同樣數(shù)據(jù)就要分解成更多張表，因此“存儲自身”的過程也就越復(fù)雜 隨著范式級別的提高，數(shù)據(jù)的存儲結(jié)構(gòu)與基于問題域的結(jié)構(gòu)間的匹配程度也隨之下降，因此，在需求變化時數(shù)據(jù)的穩(wěn)定性較差 范式級別的提高則需要

22、訪問的表增多，性能（速度）將下降,2020/7/14,49,概念模型和規(guī)范化,1 - NF：所有屬性都是原子值，即不出現(xiàn)“表中有表”,2020/7/14,50,概念模型和規(guī)范化,2 - NF：在 1-NF 基礎(chǔ)上，每個non-key-word都由整個key word 決定（而非依賴于key word 的一部分）。例：“Major”實際上由“ID”的第6、7位決定，可省去。,2020/7/14,51,概念模型和規(guī)范化,3 - NF：在 2-NF基礎(chǔ)上，non-key-word之間無從屬關(guān)系。,2020/7/14,52,圖形工具,1、層次方框圖 (Hierarchy) 描繪數(shù)據(jù)的結(jié)構(gòu) 例：A Ro

23、om hierarchy based on an interior designers perspective.,2020/7/14,53,圖形工具,2、Warnier Diagram：,2020/7/14,54,圖形工具,3、IPO圖(Input / Process / Output)：簡要的算法描述,1. 校驗 主記錄 2. 校驗 事務(wù)記錄 3. 更新 主記錄,舊的主文件 事務(wù)文件,有效的 主記錄 有效的 事務(wù)記錄 更新后的 主文件,2020/7/14,55,改進的IPO圖,2020/7/14,56,需求驗證,方法： 人工審查 初步用戶手冊 Prototyping 使用軟件工具 完整性、一

24、致性,2020/7/14,57,需求驗證,例1：Software Requirements Engineering Methodology (SREM) (TRW Corporation, 1977) SREM = Requirements Statement Language (RSL) + Requirements Engineering Validation System (REVS),2020/7/14,58,需求驗證,2020/7/14,59,自動化工具,近年來已經(jīng)開發(fā)出一些需求分析工具，它們提供一組程序，幫助分析員制定需求規(guī)格說明。以自動化為主的工具給分析員提供另一種可供選擇的方案

25、。軟件需求能夠用一種規(guī)格說明語言來描述，這種語言把關(guān)鍵字指示符與自然語言(例如英語)描述結(jié)合起來。規(guī)格說明語言被送進一個處理機，它產(chǎn)生出一份需求規(guī)格說明，更為重要的是，它同時還產(chǎn)生出一組有關(guān)規(guī)格說明的一致性和組織的診斷報告。 在過去的10年間，已經(jīng)提出過一些用于制訂需求規(guī)格說明的自動化工具。,2020/7/14,60,自動化工具,2020/7/14,61,自動化工具,軟件需求工程方法學(xué)(SREM)和問題陳述語言問題陳述分析器(PSLPSA)是有代表性的自動化工具。此外，一些基于知識或形式化方法都需要有自動工具來支持，才能有較好實用價值。,2020/7/14,62,自動化工具,軟件需求工程方法學(xué)

26、(SREM) SREM是一種自動化的需求分析工具，它用一種需求陳述語言(RSL)來描述“元素、屬性、關(guān)系和結(jié)構(gòu)”。元素(按照SREM的術(shù)語)包括一組用來制定需求規(guī)格說明的對象和概念。各對象之間的關(guān)系規(guī)定為RSL的一部分，而屬性則用來描述或說明元素，結(jié)構(gòu)用來說明信息流程。這些RSL基本成分與敘述性信息一起構(gòu)成需求規(guī)格說明的細(xì)節(jié)。,2020/7/14,63,自動化工具,問題陳述語言與問題陳述分析PSLPSA PSLPSA是1968年由DTeichroew在密執(zhí)安大學(xué)(Un5versity nf Michigan)提出的。 它是為ISDOS項目而開發(fā)的，又是一個稱之為計算機輔助設(shè)計與規(guī)格說明分析工具

27、(computeraided design and sPecification analysisto01，CADSAT)的更大的系統(tǒng)的部分。 PSLPSA給分析員提供的功能包括： 一般信息系統(tǒng)的描述，不論其應(yīng)用領(lǐng)域如何。 建立一個包含用于信息系統(tǒng)的描述符的數(shù)據(jù)庫。 描述符的添加、刪除和修改。 提供格式化的文檔資料和關(guān)于規(guī)格說明的各種報告。,2020/7/14,64,自動化工具,(1)問題陳述語言(the problem statement language，PSL)。PSL是一種用來描述信息系統(tǒng)的語言。PSL模型的結(jié)構(gòu)由表達以下內(nèi)容的描述符構(gòu)成：系統(tǒng)信息流、系統(tǒng)結(jié)構(gòu)、數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)的導(dǎo)出、系統(tǒng)

28、的規(guī)模和容量、系統(tǒng)的動態(tài)特性、系統(tǒng)的性質(zhì)以及項目的管理等。 (2)問題陳述分析(the problem statement analyzer，PSA)。PSA能夠?qū)τ蒔SL描述的問題進行分析。使用者對系統(tǒng)建立了一個完整的PSL描述后，就調(diào)用問題陳述分析器(PSA)對其進行分析。PSA將產(chǎn)生一系列報告。其中包括修改規(guī)格說明數(shù)據(jù)的所有記錄、以各種格式介紹數(shù)據(jù)庫信息的參考報告、提供研制項目管理信息的小結(jié)報告和評價該數(shù)據(jù)庫文件的分析報告等。,2020/7/14,65,自動化工具,基于知識的途徑 軟件開發(fā)是一種高級智能活動，極富創(chuàng)造性，是知識密集型產(chǎn)業(yè)，需要使用有關(guān)領(lǐng)域的大量知識。因此，引入人工智能技術(shù)

29、，構(gòu)造基于知識的軟件工具或軟件工程環(huán)境是十分必要的。隨著知識工程的進步，目前在軟件開發(fā)過程中使用人工智能在技術(shù)上已成為可能。 引入人工智能的原理和技術(shù)，把演進型原型的思想進一步提高和細(xì)化，可以得出如圖所示的擴展的自動程序設(shè)計范型。這是一個把用受限自然語言描述的初步需求逐步演進成最終的源程序的自動程序設(shè)計系統(tǒng)的概念模型，是由美國南加州大學(xué)信息科學(xué)研究所首先提出來的。,2020/7/14,66,原型化方法,在開發(fā)初期，要想得到一個完整準(zhǔn)確的規(guī)格說明不是一件容易的事。特別是對一些大型的軟件項目。 用戶往往對系統(tǒng)只有一個模糊的想法，很難完全準(zhǔn)確地表達對系統(tǒng)的全面要求。 軟件開發(fā)者對于所要解決的應(yīng)用問題

30、認(rèn)識更是模糊不清 隨著開發(fā)工作向前推進，用戶可能會產(chǎn)生新的要求，或因環(huán)境變化，要求系統(tǒng)也能隨之變化；開發(fā)者又可能在設(shè)計與實現(xiàn)的過程中遇到些沒有預(yù)料到的實際困難，需要以改變需求來解脫困境。 因此規(guī)格說明難以完善、需求的變更、以及通信中的模糊和誤解，都會成為軟件開發(fā)順利推進的障礙。 為了解決這些問題，逐漸形成了軟件系統(tǒng)的快速原型的概念。,2020/7/14,67,軟件原型的分類,在軟件開發(fā)中，原型是軟件的一個早期可運行的版本，它反映最終系統(tǒng)的部分重要特性。 探索型：目的是要弄清對目標(biāo)系統(tǒng)的要求，確定所希望的特性，并探討多種方案的可行性。 實驗型：這種原型用于大規(guī)模開發(fā)和實現(xiàn)之前，考核方案是否合適，

31、規(guī)格說明是否可靠。 進化型：這種原型的目的不在于改進規(guī)格說明，而是將系統(tǒng)建造得易于變化，在改進原型的過程中，逐步將原型進化成最終系統(tǒng)。,2020/7/14,68,建立快速原型好處,增進軟件者和用戶對系統(tǒng)服務(wù)需求的理解，使比較含糊的具有不確定性的軟件需求（主要是功能）明確化。 軟件原型化方法提供了一種有力的學(xué)習(xí)手段。 使用原型化方法，可以容易地確定系統(tǒng)的性能，確認(rèn)各項主要系統(tǒng)服務(wù)的可應(yīng)用性，確認(rèn)系統(tǒng)設(shè)計的可行性，確認(rèn)系統(tǒng)作為產(chǎn)品的結(jié)果。 軟件原型的最終版本，有的可以原封不動地成為產(chǎn)品，有的略加修改就可以成為最終系統(tǒng)的一個組成部分，這樣有利于建成最終系統(tǒng)。,2020/7/14,69,可執(zhí)行規(guī)格說明

32、 基于腳本(scenario)的設(shè)計 自動程序設(shè)計 專用語言 可復(fù)用(reusable)的軟件 簡化假設(shè),原型開發(fā)技術(shù),2020/7/14,70,可執(zhí)行規(guī)格說明,可執(zhí)行規(guī)格說明是用于需求規(guī)格說明的一種自動化技術(shù)。使用這種方法，人們可以直接觀察他們用語言規(guī)定的任何系統(tǒng)性行為。包括 代數(shù)規(guī)格說明 有限狀態(tài)模型 可執(zhí)行的數(shù)據(jù)流圖,2020/7/14,71,（1）代數(shù)規(guī)格說明,代數(shù)規(guī)格說明使用集合、定義于這些集合上的函數(shù)和定義于這些函數(shù)上的方程來描述對象。規(guī)格說明的操作語義用這些方程表示。 舉例：定義一個無界的棧及其操作 NEW_STACK： Stack PUSH：Stack，Element Stac

33、k POP： Stack (Element | Undefined) POP (NEW_STACK ( ) ) Undefined POP (PUSH ( stk，elem ) ) elem 其中，前三行定義了操作的語法，后兩行把它們的語義定義為一些方程。,2020/7/14,72,（2）有限狀態(tài)模型,parnas提出的使用最廣泛的一種可執(zhí)行規(guī)格說明形式。從一個初始狀態(tài)開始接收輸入，到產(chǎn)生輸出，狀態(tài)在推移變化。施加在狀態(tài)元素上的約束確定了有效狀態(tài)的推移。 舉例：建立用戶程序?qū)υ?2020/7/14,73,（3）可執(zhí)行的數(shù)據(jù)流圖,數(shù)據(jù)流圖是基于結(jié)構(gòu)化開發(fā)方法的結(jié)構(gòu)化規(guī)格說明 用一種可執(zhí)行的語言程

34、序代替定義處理邏輯的結(jié)構(gòu)化英語，數(shù)據(jù)流圖就成為由可執(zhí)行語言程序模塊組成的網(wǎng)絡(luò)，在一定環(huán)境或工具的支持下就可成為一個可以執(zhí)行的原型系統(tǒng)。,2020/7/14,74,基于腳本的設(shè)計,腳本是指用戶界面的原型。一個腳本用以模擬在系統(tǒng)運行期間用戶經(jīng)歷的事件。它提供了輸入處理輸出的屏幕格式和有關(guān)對話的模型。因此，軟件開發(fā)者能夠給用戶顯示系統(tǒng)的逼真的視圖，使用戶得以判斷是否符合他的意圖。 可在任一腳本中使用一套可復(fù)用的軟件模塊，以表達某一方面的要求。 可使用一種原型語言來描述原型系統(tǒng)。原型開發(fā)過程中用這種語言來定義屏幕、數(shù)據(jù)項、及其相關(guān)的操作。從系統(tǒng)的外部描述開始，開發(fā)與數(shù)據(jù)庫的接口、錯誤處理和恢復(fù)過程等系

35、統(tǒng)的與外部視圖一致的細(xì)節(jié)。,2020/7/14,75,自動程序設(shè)計,自動程序設(shè)計是指在程序自動生成環(huán)境的支持下，利用計算機實現(xiàn)軟件的開發(fā)。它可以自動地或半自動地把用戶的非過程式問題規(guī)格說明轉(zhuǎn)換為某種高級語言程序： 演繹綜合手段： 基于數(shù)學(xué)推理的構(gòu)造式證明。 程序變換手段： 將一程序轉(zhuǎn)換成另一功能等價的程序，并保持其正確性不變。 實例推廣手段： 從實例特征出發(fā)，將它推廣為待編程序的特征，最后得到程序。 過程化手段： 研究甚高級語言的編譯和知識的過程化。,2020/7/14,76,專用語言,專用語言是應(yīng)用領(lǐng)域的模型化語言。在原型開發(fā)中使用專用語言，可方便用戶和軟件開發(fā)者在計劃中的系統(tǒng)特性方面的交流

36、。,2020/7/14,77,軟件復(fù)用技術(shù),利用可復(fù)用的模塊，做出適當(dāng)?shù)慕M合，就可得到快速構(gòu)造的原型系統(tǒng)。 為了快速地構(gòu)造原型，這些模塊首先必須有簡單而清晰的界面；其次它們應(yīng)當(dāng)盡量不依賴其它的模塊或數(shù)據(jù)結(jié)構(gòu)；第三，它們應(yīng)具有一些通用的功能。,2020/7/14,78,簡化假設(shè),簡化假設(shè)是在開發(fā)過程中使設(shè)計者迅速得到一個簡化的系統(tǒng)所做的假設(shè)。盡管這些假設(shè)可能實際上并不能成立，但它們在原型開發(fā)過程中可以使開發(fā)者的注意力集中在一些主要的方面。 在修改一個文件時，可以假設(shè)這個文件確實存在 在存取文件時，待存取的記錄總是存在 一旦計劃中的系統(tǒng)滿足用戶所有的要求，就可以撤消這些假設(shè)，并追加一些細(xì)節(jié)。,20

37、20/7/14,79,系統(tǒng)動態(tài)分析,系統(tǒng)的需求規(guī)格說明通常是用自然語言來敘述的，但是用自然語言描述往往會出現(xiàn)歧義性。 為了直觀地分析系統(tǒng)的動作，從特定的視點出發(fā)描述系統(tǒng)的行為，需要采用動態(tài)分析的方法。 最常用的動態(tài)分析方法 狀態(tài)遷移圖 時序圖 Petri網(wǎng),2020/7/14,80,狀態(tài)遷移圖,狀態(tài)遷移圖是描述系統(tǒng)的狀態(tài)如何相應(yīng)外部的信號進行推移的一種圖形表示。 圓圈“”表示可得到的系統(tǒng)狀態(tài) 箭頭“”表示從一種狀態(tài)向另一種狀態(tài)的遷移。 例如, 當(dāng)有多個申請占用CPU運行的進程時, 有關(guān)CPU分配的進程的狀態(tài)遷移。,2020/7/14,81,可得到的狀態(tài)就緒，運行，等待 生成的事件t1，t2，

38、t3， t4 t1 中斷事件 t2 中斷已處理 t3 分配CPU t4 用完CPU時間,狀態(tài)遷移圖,2020/7/14,82,狀態(tài)遷移圖的優(yōu)點,狀態(tài)之間的關(guān)系能夠直觀地捕捉到 由于狀態(tài)遷移圖的單純性，能夠機械地分析許多情況，可很容易地建立分析工具,2020/7/14,83,Petri網(wǎng),Petri網(wǎng)已廣泛地應(yīng)用于硬件與軟件系統(tǒng)的開發(fā)中，它適用于描述與分析相互獨立、協(xié)同操作的處理系統(tǒng)，也就是并發(fā)執(zhí)行的處理系統(tǒng)。 Petri網(wǎng)簡稱PNG (Petri Net Graph)，它有兩種結(jié)點： 位置(place)：符號為“”，它用來表示系統(tǒng)的狀態(tài)。 轉(zhuǎn)移(transition)：符號為 “”, 它用來表示系統(tǒng)中的事件。 圖中的有向邊表示對轉(zhuǎn)移的輸入，或由轉(zhuǎn)移的輸出,2020/7/14,84,標(biāo)記，或稱令牌(token)，是表明系統(tǒng)當(dāng)前處于什么狀態(tài)的標(biāo)志,Petri網(wǎng),2020/7/14,85,Petri網(wǎng),2020/7/14,86,Petri網(wǎng),2020/7/14,87,處理兩個進程的同步問題,Petri網(wǎng),2020/7/14,88,Petri網(wǎng),