軟件需求分析ppt課件_第1頁
軟件需求分析ppt課件_第2頁
軟件需求分析ppt課件_第3頁
軟件需求分析ppt課件_第4頁
軟件需求分析ppt課件_第5頁
已閱讀5頁,還剩100頁未讀 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

1、軟件需求分析的任務和過程 結構化分析方法 原型化方法 圖形分析方法 有窮狀態(tài)機 Petri網(wǎng),軟件需求分析,(包括第3章和第4章內(nèi)容),1,3.1 軟件需求分析的任務,確定對系統(tǒng)的綜合要求 分析系統(tǒng)的數(shù)據(jù)要求 導出系統(tǒng)的邏輯模型 修正開發(fā)計劃,2,軟件的綜合需求(P46):,功能需求 性能需求 環(huán)境需求 可靠性需求 安全保密要求 約束 逆向需求 用戶界面需求,資源使用需求 成本消耗需求 開發(fā)進度需求 出錯處理需求 接口需求 將來可能提出的要求,3,分析系統(tǒng)的數(shù)據(jù)要求,采用建立數(shù)據(jù)模型的方法分析系統(tǒng)的數(shù)據(jù) 數(shù)據(jù)結構規(guī)范化問題范式,4,借助于當前系統(tǒng)的邏輯模型導出目標系統(tǒng)的邏輯模型,解決目標系統(tǒng)的

2、 “做什么” 的問題。,5,3.2 需求分析的方法及過程,(1) 問題識別 從系統(tǒng)的角度來理解軟件并評審軟件范圍是否恰當 確定對目標系統(tǒng)的綜合要求,即軟件的需求 提出這些需求實現(xiàn)條件,以及需求應達到的標準,6,問題識別的另一項工作是建立分析所需要的通信途徑,以保證能順利地對問題進行分析。,7,(2) 分析與綜合 從信息流和信息結構出發(fā),逐步細化所有的軟件功能,找出系統(tǒng)各元素之間的聯(lián)系、接口特性和設計上的約束,分析它們是否滿足功能要求,是否合理。剔除其不合理的部分,增加其需要部分。最終綜合成系統(tǒng)的解決方案,給出目標系統(tǒng)的詳細邏輯模型。,8,(3) 編制需求分析階段的文檔 軟件需求說明書 數(shù)據(jù)要求

3、說明書 初步的用戶手冊 修改、完善與確定軟件開發(fā)實施計劃,9,(4) 需求分析評審,系統(tǒng)定義的目標是否與用戶的要求一致; 系統(tǒng)需求分析階段提供的文檔資料是否齊全; 文檔中的所有描述是否完整、清晰、準確反映用戶要求; 與所有其它系統(tǒng)成分的重要接口是否都已經(jīng)描述;,10,被開發(fā)項目的數(shù)據(jù)流與數(shù)據(jù)結構是否足夠,確定; 所有圖表是否清楚,在不補充說明時能否理解; 主要功能是否已包括在規(guī)定的軟件范圍之內(nèi),是否都已充分說明; 設計的約束條件或限制條件是否符合實際; 開發(fā)的技術風險是什么;,11,是否考慮過軟件需求的其它方案; 是否考慮過將來可能會提出的軟件需求; 是否詳細制定了檢驗標準,它們能否對系統(tǒng)定義

4、是否成功進行確認;,12,需求分析流程,13,軟件需求分析的原則,需要能夠表達和理解問題的信息域和功能域 要能以層次化的方式對問題進行分解和不斷細化 要給出系統(tǒng)的邏輯視圖和物理視圖,14,面向數(shù)據(jù)流自頂向下求精結構化分析方法,面向數(shù)據(jù)流進行需求分析的方法 結構化分析方法適合于數(shù)據(jù)處理類型軟件的需求分析 具體來說,結構化分析方法就是用抽象模型的概念,按照軟件內(nèi)部數(shù)據(jù)傳遞、變換的關系,自頂向下逐層分解,直到找到滿足功能要求的所有可實現(xiàn)的軟件為止,15,結構化分析方法使用工具: 數(shù)據(jù)流圖記錄補充的數(shù)據(jù)流、數(shù)據(jù)存儲和處理 數(shù)據(jù)字典記錄數(shù)據(jù)元素信息 IPO圖描述算法 結構化英語 判定表與判定樹,16,實

5、體 聯(lián)系圖,數(shù)據(jù) 詞典,狀態(tài)遷移圖,數(shù)據(jù)流圖,數(shù)據(jù)對象描述,控制規(guī)格說明,加工規(guī)格說明,分析模型的結構,結構化分析的分析模型,17,在模型的核心是數(shù)據(jù)詞典,它描述了所有的在目標系統(tǒng)中使用的和生成的數(shù)據(jù)對象。 圍繞著這個核心的有三種圖:實體聯(lián)系圖(ERD)描述數(shù)據(jù)對象及數(shù)據(jù)對象之間的關系;數(shù)據(jù)流圖(DFD)描述數(shù)據(jù)在系統(tǒng)中如何被傳送或變換,以及描述如何對數(shù)據(jù)流進行變換的功能(子功能);狀態(tài)遷移圖(STD)描述系統(tǒng)對外部事件如何響應,如何動作。 因此,ERD用于數(shù)據(jù)建模,DFD用于功能建模,STD用于行為建模。,18,對數(shù)據(jù)流圖的每一個基本加工,必須有一個基本加工邏輯說明 基本加工邏輯說明必須描述

6、基本加工如何把輸入數(shù)據(jù)流變換為輸出數(shù)據(jù)流的加工規(guī)則 加工邏輯說明必須描述實現(xiàn)加工的策略而不是實現(xiàn)加工的細節(jié) 加工邏輯說明中包含的信息應是充足的,完備的,有用的,無冗余的,基本加工邏輯說明,19,用于寫加工邏輯說明的工具,結構化英語 判定表 判定樹,20,(1)結構化英語,結構化英語的詞匯表由 英語命令動詞 數(shù)據(jù)詞典中定義的名字 有限的自定義詞 邏輯關系詞 IF_THEN_ELSE、 CASE_OF 、 WHILE_DO、 REPEAT_UNTIL等組成。,21,是一種介于自然語言和形式化語言之間的語言 語言的正文用基本控制結構進行分割,加工中的操作用自然語言短語來表示 其基本控制結構有三種:

7、簡單陳述句結構:避免復合語句; 重復結構:while_do 或 repeat_until 結構。 判定結構:if_then_else 或 case_of 結構;,22,商店業(yè)務處理系統(tǒng)中“檢查發(fā)貨單”,if 發(fā)貨單金額超過$500 then if 欠款超過了60天 then 在償還欠款前不予批準 else (欠款未超期) 發(fā)批準書,發(fā)貨單 else (發(fā)貨單金額未超過$500) if 欠款超過60天 then 發(fā)批準書,發(fā)貨單及賒欠報告 else (欠款未超期) 發(fā)批準書,發(fā)貨單,23,(2)判定表,如果數(shù)據(jù)流圖的加工需要依賴于多個邏輯條件的取值,使用判定表來描述比較合適,24,以“檢查發(fā)貨單

8、”為例,25,26,(3)判定樹,判定樹也是用來表達加工邏輯的一種工具。有時侯它比判定表更直觀。,檢 查 發(fā) 貨 單,金額$500,金額$500,欠款60天,不發(fā)出批準書,欠款60天,發(fā)貨單,發(fā)出批準書、,欠款60天,發(fā)出批準書、,發(fā)貨單及賒欠報告,欠款60天,發(fā)出批準書、,發(fā)貨單,27,簡易的應用規(guī)格說明技術,面向團隊 初步訪談 審查需求 得出意見一致的列表 定出小型規(guī)格說明 整套確認標準 完整的軟件需求規(guī)格說明書,28,原型化方法,在開發(fā)初期,要想得到一個完整準確的規(guī)格說明不是一件容易的事。特別是對一些大型的軟件項目。 用戶往往對系統(tǒng)只有一個模糊的想法,很難完全準確地表達對系統(tǒng)的全面要求。

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

10、開發(fā)和實現(xiàn)之前,考核方案是否合適,規(guī)格說明是否可靠。 演化型:這種原型的目的不在于改進規(guī)格說明,而是將系統(tǒng)建造得易于變化,在改進原型的過程中,逐步將原型進化成最終系統(tǒng)。,32,原型類型的選擇,從系統(tǒng)結構方面考慮:聯(lián)機事務處理系統(tǒng),相互關聯(lián)的應用系統(tǒng)適合于用原型化方法,而批處理、批修改等結構不適宜用原型化方法。 從邏輯結構方面考慮 :有結構的系統(tǒng),如操作支持系統(tǒng)、管理信息系統(tǒng)、記錄管理系統(tǒng)等適合于用原型化方法,而基于大量算法的系統(tǒng)不適宜用原型化方法。,33,從用戶特征方面考慮:不滿足于預先做系統(tǒng)定義說明,愿意為定義和修改原型投資,不易肯定詳細需求,愿意承擔決策的責任,準備積極參與的用戶是適合于使

11、用原型的用戶。 從應用約束方面考慮:對已經(jīng)運行系統(tǒng)的補充,不能用原型化方法。,34,選擇適當?shù)脑头椒?35,建立快速原型,進行系統(tǒng)的分析和構造的4點好處:,增進軟件者和用戶對系統(tǒng)服務需求的理解,使比較含糊的具有不確定性的軟件需求(主要是功能)明確化。 軟件原型化方法提供了一種有力的學習手段。,36,使用原型化方法,可以容易地確定系統(tǒng)的性能,確認各項主要系統(tǒng)服務的可應用性,確認系統(tǒng)設計的可行性,確認系統(tǒng)作為產(chǎn)品的結果。 軟件原型的最終版本,有的可以原封不動地成為產(chǎn)品,有的略加修改就可以成為最終系統(tǒng)的一個組成部分,這樣有利于建成最終系統(tǒng)。 下面講原型的生存期,37,38,39,原型開發(fā)技術,可執(zhí)

12、行規(guī)格說明 基于腳本(scenario)的設計 自動程序設計 專用語言 可重用(reusable)的軟件構件 簡化假設,40,可執(zhí)行規(guī)格說明,可執(zhí)行規(guī)格說明是用于需求規(guī)格說明的一種自動化技術。使用這種方法,人們可以直接觀察他們用語言規(guī)定的任何系統(tǒng)性行為。包括 代數(shù)規(guī)格說明 有限狀態(tài)模型 可執(zhí)行的數(shù)據(jù)流圖,41,(1)代數(shù)規(guī)格說明,代數(shù)規(guī)格說明使用集合、定義于這些集合上的函數(shù)和定義于這些函數(shù)上的方程來描述對象。規(guī)格說明的操作語義用這些方程表示。 見下例:,42,NEW_STACK: Stack PUSH:Stack,Element Stack POP: Stack (Element | Unde

13、fined) POP (NEW_STACK ( ) ) Undefined POP (PUSH ( stk,elem ) ) elem 其中,前三行定義了操作的語法,后兩行把它們的語義定義為一些方程。,舉例:定義一個無界的棧及其操作,43,(2)有限狀態(tài)模型,parnas提出的使用最廣泛的一種可執(zhí)行規(guī)格說明形式。從一個初始狀態(tài)開始接收輸入,到產(chǎn)生輸出,狀態(tài)在推移變化。施加在狀態(tài)元素上的約束確定了有效狀態(tài)的推移。 見下例:,44,舉例:建立用戶程序對話,45,(3)可執(zhí)行的數(shù)據(jù)流圖,用一種可執(zhí)行的語言程序代替定義處理邏輯的結構化英語,數(shù)據(jù)流圖就成為由可執(zhí)行語言程序模塊組成的網(wǎng)絡,在一定環(huán)境或工具

14、的支持下就可成為一個可以執(zhí)行的原型系統(tǒng)。,46,基于場景的設計(原型開發(fā)技術2),場景是指用戶界面的原型。一個場景用以模擬在系統(tǒng)運行期間用戶經(jīng)歷的事件。它提供了輸入處理輸出的屏幕格式和有關對話的模型。因此,軟件開發(fā)者能夠給用戶顯示系統(tǒng)的逼真的視圖,使用戶得以判斷是否符合他的意圖。,47,可在任一場景中使用一套可復用的軟件模塊,以表達某一方面的要求。 可使用一種原型語言來描述原型系統(tǒng)。原型開發(fā)過程中用這種語言來定義屏幕、數(shù)據(jù)項、及其相關的操作。從系統(tǒng)的外部描述開始,開發(fā)與數(shù)據(jù)庫的接口、錯誤處理和恢復過程等系統(tǒng)的與外部視圖一致的細節(jié)。,48,自動程序設計(原型開發(fā)技術3),自動程序設計是指在程序自

15、動生成環(huán)境的支持下,利用計算機實現(xiàn)軟件的開發(fā)。它可以自動地或半自動地把用戶的非過程式問題規(guī)格說明轉換為某種高級語言程序: 演繹綜合手段: 基于數(shù)學推理的構造式證明。,49,程序變換手段: 將一程序轉換成另一功能等價的程序,并保持其正確性不變。 實例推廣手段: 從實例特征出發(fā),將它推廣為待編程序的特征,最后得到程序。 過程化手段: 研究甚高級語言的編譯和知識的過程化。,50,專用語言(原型開發(fā)技術4),專用語言是應用領域的模型化語言。在原型開發(fā)中使用專用語言,可方便用戶和軟件開發(fā)者在計劃中的系統(tǒng)特性方面的交流。,51,軟件復用技術(原型開發(fā)技術5),利用可復用的模塊,做出適當?shù)慕M合,就可得到快速

16、構造的原型系統(tǒng)。 為了快速地構造原型,這些模塊首先必須有簡單而清晰的界面;其次它們應當盡量不依賴其它的模塊或數(shù)據(jù)結構;第三,它們應具有一些通用的功能。,52,簡化假設(原型開發(fā)技術6),簡化假設是在開發(fā)過程中使設計者迅速得到一個簡化的系統(tǒng)所做的假設。盡管這些假設可能實際上并不能成立,但它們在原型開發(fā)過程中可以使開發(fā)者的注意力集中在一些主要的方面。,53,在修改一個文件時,可以假設這個文件確實存在 在存取文件時,待存取的記錄總是存在 一旦計劃中的系統(tǒng)滿足用戶所有的要求,就可以撤消這些假設,并追加一些細節(jié)。,54,3.3 軟件需求規(guī)格說明,原則1:功能與實現(xiàn)分離 原則2:要求使用面向處理的規(guī)格說明

17、語言,來定義一個行為模型。 原則3:如果目標軟件只是一個大系統(tǒng)中的一個元素,那么整個大系統(tǒng)也包括在規(guī)格說明的描述之中。 原則4:必須包括系統(tǒng)運行的環(huán)境。 原則5:必須是一個認識的模型。 原則6:規(guī)格說明必須是可操作的。 原則7:必須容許不完備性并允許擴充。 原則8:必須局部化和松散的耦合。,55,56,需求規(guī)格說明評審,合計16項主要內(nèi)容: 系統(tǒng)定義的目標是否與用戶的要求一致; 系統(tǒng)需求分析階段提供的文檔資料是否齊全; 文檔中的所有描述是否完整、清晰、準確反映用戶要求; 與所有其它系統(tǒng)成分的重要接口是否都已經(jīng)描述; 被開發(fā)項目的數(shù)據(jù)流與數(shù)據(jù)結構是否足夠,確定; 所有圖表是否清楚,在不補充說明時

18、能否理解;,57,主要功能是否已包括在規(guī)定的軟件范圍之內(nèi),是否都已充分說明; 軟件的行為和它必須處理的信息、必須完成的功能是否一致; 設計的約束條件或限制條件是否符合實際; 是否考慮了開發(fā)的技術風險; 是否考慮過軟件需求的其它方案;,58,是否考慮過將來可能會提出的軟件需求; 是否詳細制定了檢驗標準,它們能否對系統(tǒng)定義是否成功進行確認; 有沒有遺漏,重復或不一致的地方; 用戶是否審查了初步的用戶手冊或原型; 軟件開發(fā)計劃中的估算是否受到了影響。,59,系統(tǒng)圖形分析,系統(tǒng)的需求規(guī)格說明通常是用自然語言來敘述的,但是用自然語言描述往往會出現(xiàn)歧義性。 為了直觀地分析系統(tǒng)的動作,從特定的視點出發(fā)描述系

19、統(tǒng)的行為,需要采用圖形分析的方法。,60,最常用的圖形分析方法,ER圖 狀態(tài)遷移圖 時序圖 Petri網(wǎng),61,3.4 E-R方法 ( Entity-Relationship Approach) 和實體模型,在需求分析階段進行數(shù)據(jù)庫邏輯設計過程中,使用E-R圖,可定義一 個實體模型。 實體模型是現(xiàn)實世界的純表示,它不涉及數(shù)據(jù)世界的數(shù)據(jù)結構、存取路徑、存取效率等問題。它可以轉換成數(shù)據(jù)庫中的數(shù)據(jù)模型。,62,數(shù)據(jù)可以按相應數(shù)據(jù)模型進行組織。 E-R圖中表示實體聯(lián)系的符號如下:,63,在E-R圖中,每個方框表示實體型或屬性,方框之間的連線表示實體之間,或實體與屬性之間的聯(lián)系。出現(xiàn)在連線上的短豎線可以

20、看成是“1”,而圓圈隱含表示“0”。 例如,在教學管理中,一個教師可以教授零門、一門或多門課程,每位學生也需要學習幾門課程。因此,教學管理中涉及的對象(實體型)有學生、教師和課程。,64,用E-R圖描述它們之間的聯(lián)系,得下圖。其中,學生與課程是多對多的聯(lián)系,而教師與課程的聯(lián)系是零、一對多。,65,進一步,要確定屬性。例如, 學生具有學號、姓名、性別、年齡、專業(yè)(其它略)等屬性; 課程具有課程號、課程名、學分、學時數(shù)等屬性; 教師具有職工號、姓名、年齡、職稱等屬性。 此外,學生通過學號、分數(shù)與課程發(fā)生聯(lián)系。如此可得教學實體模型。,66,教學實體模型,67,3.5 數(shù)據(jù)規(guī)范化,信息域分析需要確定數(shù)

21、據(jù)的內(nèi)容,每個數(shù)據(jù)項要用表格列出,最后組織成文件的邏輯結構,即面向邏輯而不是面向存儲的結構。 為了便于數(shù)據(jù)庫的設計,常常要對這種結構做一些簡化,其中最常見的一種方法就是規(guī)范化技術。,68,“規(guī)范化”將數(shù)據(jù)的邏輯結構歸結為滿足一定條件的二維表(關系)。 表格中每個信息項必須是一個不可分割的數(shù)據(jù)項,不可是組項。 表格中每一列 (列表示屬性)中所有信息項必須是同一類型,各列的名字 (屬性名) 互異,列的次序任意。 表格中各行 (行表示元組) 互不相同,行的次序任意。,69,不滿足上述要求的二維表或關系,叫做非規(guī)范化關系。對于非規(guī)范化的關系,必須將它規(guī)范化。 規(guī)范化的5點目的是: 消除數(shù)據(jù)冗余,即消除

22、表格中數(shù)據(jù)的重復; 消除多義性,使關系中的屬性含義清楚、單一;,70,使關系的“概念”單一化,讓每個數(shù)據(jù)項只是一個簡單的數(shù)或字符串,而不是一個組項或重復組; 方便操作。使數(shù)據(jù)的插入、刪除與修改操作可行并方便; 使關系模式更靈活,易于實現(xiàn)接近自然語言的查詢方式。,71,用教學管理例子說明如何規(guī)范化,有三個實體型,即課程、學生和教師,用三組屬性保存它們的信息: 學生(學號,姓名,性別,年齡,專業(yè),籍貫) 教師(職工號,姓名,年齡,職稱,工資級別,工資) 課程(課程號,課程名,學分,學時,課程類型),72,為表示實體型之間的聯(lián)系,建立兩個關系: 選課 (學號,課程號,聽課出勤率,作業(yè)完成率,分數(shù))

23、教課 (職工號,課程號) 在每個關系中,屬性名下加下劃線指明關鍵字。并規(guī)定關鍵字能唯一地標識一個一元組。,73,關系規(guī)范化的程度,通常按屬性間的依賴程度來區(qū)分,并以范式 NF (Normal Form) 來表達。常用的范式分為第一范式(1NF)、第二范式(2NF)和第三范式(3NF)。 設是一個關系,和是中的兩個屬性。若對于的任一個值,僅有一個值與之對應,則稱的屬性函數(shù)依賴于屬性。例如,,74,教師 (職工號, 姓名, 年齡, ) 其中,屬性“姓名”,“年齡”等都函數(shù)依賴于屬性“職工號”。屬性可以是復合屬性,如: 選課 (學號, 課程號, 聽課出勤率, ),75,如果屬性函數(shù)依賴于復合屬性,而

24、不與的任何真子集函數(shù)依賴,則稱屬性完全函數(shù)依賴于復合屬性。 例如在“選課”關系中,屬性“聽課出勤率”、“作業(yè)完成率”和“分數(shù)”等表示某個學生學習某門課程時的學習情況。只有同時指定“學號”和“課程號”,才能準確地說明是哪位學生學習哪門課程時的學習情況。,76,因此,“分數(shù)”等屬性完全函數(shù)依賴于“學號,課程號”。 判斷規(guī)范化程度的條件是: 關系中所有屬性都是“單純域”,即不出現(xiàn)“表中有表” 非主屬性完全函數(shù)依賴于關鍵字 非主屬性相互獨立,即任何非主屬性間不存在函數(shù)依賴。 如果一個關系連條件 都不滿足,則這個關系是非規(guī)范化的。,77,如果一個關系僅滿足條件 ,則這個關系滿足第一范式 (1NF)。 如

25、果一個關系滿足條件 、,但不滿足 ,則這個關系滿足第二范式 (2NF)。 如果一個關系同時滿足條件 、和 ,則這個關系表滿足第三范式(3NF)。 當數(shù)據(jù)模型達到 3NF,一般情況下就能滿足數(shù)據(jù)庫應用的需要。,78,數(shù)據(jù)庫分析的過程,在需求分析階段進行數(shù)據(jù)庫分析的流程,79,為開發(fā)一個系統(tǒng)所使用的數(shù)據(jù)庫,在開始分析數(shù)據(jù)庫的需求前,分析員必須了解該系統(tǒng)的總目標和范圍。然后建立一個完整并高度細化的信息模型。 此信息模型應包括一個綜合的數(shù)據(jù)詞典,定義所有在開發(fā)數(shù)據(jù)庫時用到的數(shù)據(jù)項。 接著數(shù)據(jù)庫分析定義數(shù)據(jù)庫的邏輯特性和物理特性。,80,以信息模型和系統(tǒng)規(guī)格說明為指導,定義數(shù)據(jù)庫的邏輯數(shù)據(jù)結構。 這種邏

26、輯結構必須適應數(shù)據(jù)存取、修改、關聯(lián)性及其它相關需求。 一旦邏輯數(shù)據(jù)結構建立起來,就可以研制數(shù)據(jù)庫的物理結構。 物理數(shù)據(jù)庫結構定義文件結構、記錄格式、與硬件相關的處理方式以及數(shù)據(jù)庫管理系統(tǒng)的特性。,81,最后,要對模式和物理特性進行完全的評審。 在數(shù)據(jù)庫分析過程中所考慮的因素間存在著復雜的相互聯(lián)系。改變其中的任何一個因素都會(潛在地)影響其它的因素。所以必須在各個因素之間進行折衷。 這種折衷包括專用性和通用性的折衷,信息關聯(lián)程度、擴充潛力及操作特性等方面的折衷。,82,操作特性根據(jù)折衷的結果而定。數(shù)據(jù)庫的結構、規(guī)模和邏輯設計都會對它的物理組織、硬件、存取方式以及性能產(chǎn)生重要的影響。,83,3.6

27、 狀態(tài)遷移圖,狀態(tài)遷移圖是描述系統(tǒng)的狀態(tài)如何相應外部的信號進行推移的一種圖形表示。 狀態(tài)、事件、符號 圓圈“”表示可得到的系統(tǒng)狀態(tài) 箭頭“”表示從一種狀態(tài)向另一種狀態(tài)的遷移。,84,例如, 當有多個申請占用CPU運行的進程時, 有關CPU分配的進程的狀態(tài)遷移。,85,可得到的狀態(tài)就緒S3,運行S2,等待S1 生成的事件t1,t2, t3, t4 t1 中斷已處理完 t2 分配CPU t3 CPU時間用完 t4 中斷發(fā)生,86,狀態(tài)遷移圖的優(yōu)點,狀態(tài)之間的關系能夠直觀地捕捉到 由于狀態(tài)遷移圖的單純性,能夠機械地分析許多情況,可很容易地建立分析工具,87,在系統(tǒng)分析中,用時序圖描述在系統(tǒng)中處理事件的時序和相應的處理時間。在下圖中, 對于事件e,功能1功能3 的處理時間總計為 (T1T2T3)

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論