軟件工程柯逍第六章(完成規(guī)格說明書)課件

第6章

需求建模：流程、行為和模式需求建模：流程、行為和模式在第5章討論了用例、數(shù)據(jù)建模和基于類模型后，很自然會問“這些需求建模表示方法就足夠了嗎？”要看情況而定對于某種類型軟件，用例可能是唯一可行的需求建模表示方法。而其他類型的軟件，則需要選擇面向?qū)ο蟮姆椒ㄩ_發(fā)基于類的模型。但在另外一些情形下，復雜應(yīng)用需求可能必須檢測：查看當數(shù)據(jù)對象在系統(tǒng)中移動時是如何轉(zhuǎn)換的查看一個應(yīng)用系統(tǒng)是如何工作的查看現(xiàn)存知識領(lǐng)域能否解決當前問題第6章6.1需求建模策略6.2面向流程建模6.3生成行為模型6.4需求建模的模式第6章6.1需求建模策略6.2面向流程建模6.3生成行為模型6.4需求建模的模式6.2面向流程建模描述了數(shù)據(jù)對象在系統(tǒng)中的變換過程采用數(shù)據(jù)流圖(dataflowdiagram，DFD)、狀態(tài)遷移圖等。DFD是結(jié)構(gòu)化分析方法，不是UML的組成部分，但可以補充對系統(tǒng)需求和流程的認識。DFD采取了系統(tǒng)的輸入-處理-輸出觀點，即流入軟件的數(shù)據(jù)對象，經(jīng)由處理元素變換，最后結(jié)果以數(shù)據(jù)對象的形式流出軟件。數(shù)據(jù)流圖（記號）數(shù)據(jù)流圖（用戶取錢的例子）銀行取款過程外部實體：儲戶、日歷處理：檢驗、登錄、付款數(shù)據(jù)存儲：帳卡、存折數(shù)據(jù)流圖使用分層的方式表示第一個數(shù)據(jù)流模型（第0層DFD，也稱環(huán)境圖）表示整個系統(tǒng)，隨后的數(shù)據(jù)流圖改進環(huán)境圖，在每個后續(xù)層提供更多的細節(jié)。數(shù)據(jù)流圖有助于軟件工程師開發(fā)信息域的模型，并同時開發(fā)功能域的模型。當把DFD逐步細化時，分析師同時也就完成了系統(tǒng)功能分解。與此同時，當數(shù)據(jù)在應(yīng)用系統(tǒng)中的多個處理間流動時，DFD的精煉結(jié)果導致了相應(yīng)的數(shù)據(jù)精化。數(shù)據(jù)流圖可能會出現(xiàn)數(shù)據(jù)流圖過于復雜。原因分析師試圖過早地顯示過多的細節(jié)信息流中表示軟件流程方面的內(nèi)容SafeHome安全功能的環(huán)境層DFD控制面板（Internet,計算機）傳感器控制面板（Internet,計算機）警報電話線SH軟件用戶指令和數(shù)據(jù)傳感器狀態(tài)顯示信息警報類型電話號碼撥號通過篩選輸入、輸出即可給出于0層DFD外部實體(方框)產(chǎn)生并使用系統(tǒng)產(chǎn)生的信息數(shù)據(jù)流圖如何將第0層DFD擴展到第1層數(shù)據(jù)流模型？對描述環(huán)境層泡泡的用例敘述采用“語法解析”的方法即將第一次需求收集會議獲得的SafeHome處理敘述中的所有名詞(名詞短語)與動詞(動詞短語)分離開來。SH安全功能輔助房主在安裝時配置安全系統(tǒng)，監(jiān)測所有連接到安全系統(tǒng)的傳感器，通過Internet、計算機或控制面板和房主交互。在安裝中，SH計算機被用于配置系統(tǒng)，每個傳感器被分配一個編號和類型，主密碼被用以控制啟動和關(guān)閉系統(tǒng)，當傳感器事件發(fā)生時，將撥打預設(shè)的電話號碼。當識別出一個傳感器事件時，軟件激活附于系統(tǒng)上的可發(fā)聲警報，在一定的延遲時間（由房主在系統(tǒng)配置活動中指定）后，軟件撥打監(jiān)測服務(wù)的電話號碼并提供關(guān)于位置的信息，報告被檢測到的事件的性質(zhì)，電話號碼將每20秒重撥一次，直至電話接通。房主通過控制面板、計算機或瀏覽器這些統(tǒng)稱為接口的設(shè)施接收安全信息。接口在控制面板、計算機或瀏覽器窗口中顯示提示信息和系統(tǒng)狀態(tài)信息。房主的交互采用如下形式……

SH安全功能輔助房主在安裝時配置安全系統(tǒng)，監(jiān)測所有連接到安全系統(tǒng)的傳感器，通過Internet、計算機或控制面板和房主交互。在安裝中，SH計算機被用于配置系統(tǒng)，每個傳感器被分配一個編號和類型，主密碼被用以控制啟動和關(guān)閉系統(tǒng)，當傳感器事件發(fā)生時，將撥打預設(shè)的電話號碼。當識別出一個傳感器事件時，軟件激活附于系統(tǒng)上的可發(fā)聲警報，在一定的延遲時間（由房主在系統(tǒng)配置活動中指定）后，軟件撥打監(jiān)測服務(wù)的電話號碼并提供關(guān)于位置的信息，報告被檢測到事件的性質(zhì)，電話號碼將每20秒重撥一次，直至電話接通。房主通過控制面板、計算機或瀏覽器這些統(tǒng)稱為接口的設(shè)施接收安全信息。接口在控制面板、計算機或瀏覽器窗口中顯示提示信息和系統(tǒng)狀態(tài)信息。房主的交互采用如下形式……數(shù)據(jù)流圖根據(jù)語法解析動詞是SafeHome的處理，在后續(xù)的DFD中用泡泡表示；名詞是外部實體(方框)、數(shù)據(jù)或控制對象(箭頭)、數(shù)據(jù)存儲(雙橫線)。在任何DFD層次中對某個泡泡的處理敘述文字進行語法解析，可以產(chǎn)生許多如何精化到下一個層次的有用信息。例如，第0層DFD可以擴展為6個處理，這些處理來自于語法解析檢查。第二層DFD數(shù)據(jù)流圖持續(xù)進行DFD的求精，直到每個泡泡都執(zhí)行了某個單一的功能，也就是說，直至每個泡泡所代表的處理都執(zhí)行一個功能，并且該功能可以很容易地成為一個程序構(gòu)件。DFD之間的數(shù)據(jù)流必須要連續(xù)。創(chuàng)建控制流模型事件或控制項可以實現(xiàn)為布爾值例如，真或假、開或關(guān)、1或0條件的離散列表例如，空、擁擠、滿創(chuàng)建控制流模型選擇潛在候選事件的指導原則：列出所有被軟件“讀”的傳感器。列出所有的中斷條件。列出操作人員能夠啟動的所有“開關(guān)”。列出所有的數(shù)據(jù)條件。回顧對處理敘述所進行的名詞或動詞的語法解析，考察所有可能作為控制規(guī)格說明輸入/輸出的“控制項”。通過標識狀態(tài)來描述系統(tǒng)的行為，標識如何達到這些狀態(tài)，并定義狀態(tài)間的遷移。關(guān)注可能的疏忽，即關(guān)注那些描述控制中非常普遍的錯誤。例如，提問“有什么其他途徑可以達到或離開這個狀態(tài)嗎？”控制流模型控制流模型用于事件驅(qū)動問題的建模控制規(guī)格說明(ControlSPECification,CSPEC)對行為的建模，描述了軟件狀態(tài)以及導致狀態(tài)變化的事件，常用狀態(tài)圖ResettingEntry/setsystermStatus“inactive”Entry/setdisplayMsg1“Startingsystem”Entry/setdisplayMsg2“Pleasewait”Entry/setdisplayStatusslowBlinkingDo:rundiagnostics開始/結(jié)束切換電源“開”IdleEntry/setsystermStatus“inactive”Entry/setdisplayMsg1“Ready”Entry/setdisplayMsg2“”Entry/setdisplayStatussteadyKeyHit/handleKey系統(tǒng)就緒不能設(shè)置/設(shè)置顯示消息2“聯(lián)系供應(yīng)商”重置關(guān)閉/電源關(guān)閉MonitoringSystemEntry/setsystermStatus“monitoring”Entry/setdisplayMsg1“Armed”Entry/setdisplayMsg2“”Entry/setdisplayStatussteadyDo:MonitorAndControlSystemKeyHit/handleKey激活解除密碼ActingOnAlarmEntry/setsystermStatus“MonitorAndAlarm”Entry/setdisplayMsg1“ALARM”Entry/setdisplayMsg2triggeringSenserEntry/setdisplayStatusfastBlinkingDo:MonitorAndControlSystemDo:soundAlarmDo:notifyAlarmRespondersKeyHit/handleKey傳感器觸發(fā)/啟動計時器超時錯誤警報解除密碼傳感器觸發(fā)/新啟動計時器SafeHome安全功能的狀態(tài)圖處理規(guī)格說明處理規(guī)格說明（ProcessSPECification,PSPEC)：也稱加工說明，是對數(shù)據(jù)流圖中每個加工所作的說明，處理規(guī)格說明的內(nèi)容包括敘述性正文、處理算法的程序設(shè)計語言描述、數(shù)學方程、圖表，常用判定表。通過為流模型中的每個泡泡提供PSPEC，軟件工程師創(chuàng)建了“小型規(guī)格說明”(mini-spec)可以作為軟件構(gòu)件實現(xiàn)處理的設(shè)計指南。判定表一個表格，描述條件和條件導致的動作的集合Rule1Rule2Rule3Rule4Rule5HighstandardizedexamscoresTFFFFHighgrades-----TFFFOutsideactivities----------TFFGoodrecommendations---------------TFSendrejectionletter√√√Sendadmissionforms√√判定表（II）結(jié)構(gòu)化分析結(jié)構(gòu)化分析工具使用“數(shù)據(jù)字典”作為說明所有數(shù)據(jù)對象的中心數(shù)據(jù)庫。數(shù)據(jù)字典管理各種關(guān)系模型中的信息定義四類元素：數(shù)據(jù)流、數(shù)據(jù)流分量、數(shù)據(jù)存儲和處理信息：一般信息：名字、別名、描述等定義信息：數(shù)據(jù)類型、長度、結(jié)構(gòu)使用特點：值的范圍、使用頻率、使用方式控制信息：來源、使用它的程序分組信息：父結(jié)構(gòu)、從屬結(jié)構(gòu)、物理位置等數(shù)據(jù)字典數(shù)據(jù)元素組成數(shù)據(jù)對象的方式：順序：兩個或多個分量以確定次序進行連接選擇：從兩個或多個可能的元素中選取一個重復：把指定的分量重復零次或多次可選：一個分量是可有可無的（重復0或1次）符號：=

等價于+和[]

或（選擇一個，用|隔開分量）字母或數(shù)字=[字母字符|數(shù)字字符]{}

重復字母數(shù)字串=0{字母或數(shù)字}7()

可選數(shù)據(jù)字典數(shù)據(jù)字典（例）名字：訂貨報表別名：訂貨信息描述：每天一次送給采購員的需要訂貨的零件表定義：訂貨報表=零件編號+零件名稱+訂貨數(shù)量+價格+供應(yīng)者位置：輸出到打印機數(shù)據(jù)字典（IV）數(shù)據(jù)字典（例）名字：零件編號別名：描述：唯一地標識庫存清單中特定零件的域定義：零件編號=8{字符}8位置：訂貨報表、訂貨信息、庫存清單、事務(wù)第6章6.1需求建模策略6.2面向流程建模6.3生成行為模型6.4需求建模的模式6.3生成行為模型行為模型描述了系統(tǒng)如何響應(yīng)外部事件或激勵要生成行為模型，分析師必須按如下步驟進行：(1)評估所有用例，以保證完全理解系統(tǒng)內(nèi)的交互序列(2)識別驅(qū)動交互序列的事件，并理解這些事件如何和具體的類相互關(guān)聯(lián)(3)為每個用例生成序列（順序圖）(4)創(chuàng)建系統(tǒng)狀態(tài)圖(5)評審行為模型以驗證準確性和一致性識別用例事件只要系統(tǒng)和參與者之間交換了信息就發(fā)生事件。從信息交換的角度檢查用例：房主使用鍵盤鍵入4位密碼。該密碼和保存在系統(tǒng)中的有效密碼相比較。如果密碼不正確，控制面板將鳴叫一聲并復位以等待下一次輸入；如果密碼正確，控制面板等待進一步的操作。用例場景中加下劃線的部分表示事件。應(yīng)確認每個事件的參與者，應(yīng)標記交換的所有信息，而且應(yīng)列出任何條件或限制。識別用例事件考慮用例中加下劃線的“房主使用鍵盤鍵入4位密碼”。在需求模型的環(huán)境下，對象Homeowner向?qū)ο驝ontrolPanel發(fā)送一個事件。這個事件可以稱為“輸入密碼”。傳輸?shù)男畔⑹墙M成密碼的4位數(shù)字。注意到某些事件對用例的控制流有明顯的影響，而其他的事件對控制流沒有直接的影響。例如，事件“輸入密碼”不會明顯地改變用例的控制流事件“比較密碼”(從與事件“該密碼和保存在系統(tǒng)中的有效密碼相比較”的交互中得到)的結(jié)果將明顯地影響到SafeHome軟件的信息流和控制流。識別用例事件一旦確定了所有的事件，這些事件將被分配到所涉及的對象，對象負責生成事件，例如Homeowner房主對象生成“輸入密碼”事件或識別已經(jīng)在其他地方發(fā)生的事件例如，ControlPanel控制面板識別“比較密碼”事件的二元結(jié)果狀態(tài)表現(xiàn)在行為建模的場合，必須考慮兩種不同的狀態(tài)描述：（1）系統(tǒng)執(zhí)行其功能時每個類的狀態(tài)（2）系統(tǒng)執(zhí)行其功能時從外部觀察到的系統(tǒng)狀態(tài)類的狀態(tài)有被動和主動兩種特征：被動狀態(tài)——很簡單，是某個對象所有屬性的當前狀態(tài)比如，對象的位置與方向信息等；主動狀態(tài)——對象進行持續(xù)變換和處理時的當前狀態(tài)比如，移動、休息、受傷、療傷、被捕、失蹤等必然發(fā)生事件(有時被稱為觸發(fā)器)才能迫使對象做出從一個主動狀態(tài)到另一個主動狀態(tài)的轉(zhuǎn)移。狀態(tài)圖：為每個類呈現(xiàn)了主動狀態(tài)和導致這些主動狀態(tài)變化的事件每個箭頭表示某個對象從一個主動狀態(tài)轉(zhuǎn)移到另一個主動狀態(tài)。每個箭頭上的標注都體現(xiàn)了觸發(fā)狀態(tài)轉(zhuǎn)移的事件。狀態(tài)圖除了說明導致轉(zhuǎn)移發(fā)生的事件外，分析師還可以說明守衛(wèi)Guard和動作:守衛(wèi)是為了保證轉(zhuǎn)移發(fā)生而必須滿足的一個布爾條件。轉(zhuǎn)移的守衛(wèi)通常依賴于某個對象的一個或多個屬性值。換句話說，守衛(wèi)依賴于對象的被動狀態(tài)。例如，“Reading”狀態(tài)轉(zhuǎn)移到“Comparing”狀態(tài)的守衛(wèi)可以由檢察用例來確定:if(passwordinput=4digits)thencomparetostoredpassword動作是與狀態(tài)轉(zhuǎn)移同時發(fā)生的或者作為狀態(tài)轉(zhuǎn)移的結(jié)果，而且通常動作包含對象的一個或多個操作(職責)。例如，和“輸入密碼”事件相關(guān)聯(lián)的動作是validatePassword()操作，該操作通過訪問password對象并通過執(zhí)行按位比較來驗證輸入密碼。順序圖順序圖用時間函數(shù)表明事件如何引發(fā)從一個對象到另一個對象的轉(zhuǎn)移每個箭頭代表了一個事件時間縱向向下度量窄的縱向矩形表示處理某個活動所用的時間。沿著縱向的時間線可以展示出對象的狀態(tài)。順序圖順序圖一旦完成了完整的順序圖，把所有導致系統(tǒng)對象之間轉(zhuǎn)移的事件整理為輸入事件集合和輸出事件集合(來自一個對象)。出卷系統(tǒng)案例頂層數(shù)據(jù)流圖出卷系統(tǒng)案例(II)一層數(shù)據(jù)流圖出卷系統(tǒng)案例(III)二級數(shù)據(jù)流圖（自動出卷部分）出卷系統(tǒng)案例(IV)出卷功能初步的ER圖出卷系統(tǒng)案例(V)“試題”的數(shù)據(jù)信息名字：試卷別名：描述：試卷的內(nèi)容定義： 試卷=試卷編號+課程名+出卷人+時間+總分+難度 試卷編號=1{字符}10 課程名=1{字符}30

出卷人=1{字符}8

時間=日期總分=整數(shù)難度=[難|中|易]位置：試卷數(shù)據(jù)集出卷系統(tǒng)案例(VI)“出卷要求”的數(shù)據(jù)信息名字：出卷要求別名：要求描述：出卷的卷面要求定義：出卷要求=總分+總難度+總知識點總分=整數(shù) 總難度=難分數(shù)比例+中分數(shù)比例+易分數(shù)比例總知識點=1{知識點分數(shù)比例}*位置：自動出卷、手動出卷、設(shè)置出卷要求短信系統(tǒng)案例用例場景發(fā)送短信的場景描述用戶輸入短信內(nèi)容用戶選擇若干個發(fā)送人員系統(tǒng)將明文短消息編碼成格式化的短消息串系統(tǒng)以串行方式將短信串傳入無線移動終端接收短信的場景描述用戶向串口發(fā)送指令從無線移動終端讀取一組短消息串系統(tǒng)將一組短信串解碼成明文的短消息系統(tǒng)將短消息寫入數(shù)據(jù)庫，并顯示給用戶短信系統(tǒng)案例（II）人員維護的場景描述管理員添加一個新成員管理員更新一個成員的信息管理員刪除一個成員系統(tǒng)設(shè)置的場景描述管理員修改基本信息：如短信客服中心號碼、發(fā)送頻率、延時等系統(tǒng)保存設(shè)置信息短信系統(tǒng)案例（III）類包括邊界類：用于建立系統(tǒng)與其參與者之間交互的模型，經(jīng)常代表對窗口、屏幕、打印機接口等抽象。發(fā)送短信界面、接收短信界面、收發(fā)接口控制類：代表協(xié)調(diào)、排序、事務(wù)處理以及其它的對象控制，經(jīng)常用于封閉與某個具體用例有關(guān)的控制。發(fā)送短信、接收短信實體類：用于長效持久的信息建模。多數(shù)情況下，實體類是直接從業(yè)務(wù)對象模型中相應(yīng)的業(yè)務(wù)實體類得到。短信編/解碼、發(fā)送的短信串、接收的短信串短信系統(tǒng)案例（IV）發(fā)送短信用例的協(xié)作圖：短信系統(tǒng)案例（V）發(fā)送短信用例的順序圖(時序圖)：第6章6.1需求建模策略6.2面向流程建模6.3生成行為模型6.4需求建模的模式6.4需求建模的模式軟件模式是獲取領(lǐng)域知識的一種機制，從而遇到新問題時可以反復使用。在某些情況下，領(lǐng)域知識在同一應(yīng)用領(lǐng)域中用于解決新問題。在另外一些情況下，通過模式獲取的領(lǐng)域知識可借助模擬用于完全不同的應(yīng)用領(lǐng)域。分析模式表示了在某些應(yīng)用領(lǐng)域中常合并一個類、一個功能、或一個行為的解決方案。當為某個領(lǐng)域的應(yīng)用執(zhí)行需求建模時會重用模式。分析模式都存儲于一個倉庫中以便軟件團隊的成員能夠使用搜索工具找到并復用。一旦選擇到合適的模式，就可通過參考模式名稱整合到需求模型中發(fā)現(xiàn)分析模式需求模型由各種元素組成：基于場景(用例)、基于數(shù)據(jù)(數(shù)據(jù)模型)、基于類、基于流和行為。其中每個元素都是從不同的視角檢查問題，并且每一個都提供一種發(fā)現(xiàn)模式的機會，可能發(fā)生在整個應(yīng)用領(lǐng)域，或者發(fā)生在類似但橫跨不同的應(yīng)用領(lǐng)域。在需求模型的描述中最基本的元素是用例。一套連貫用例可以成為服務(wù)于發(fā)現(xiàn)一個或多個分析模式的基礎(chǔ)。語義分析模式(semanticanalysispattern,SAP)描述了一小套連貫用例，這些用例一起描述了通用應(yīng)用的基礎(chǔ)。發(fā)現(xiàn)分析模式用例：監(jiān)控反向運動描述：當車輛安裝了反向齒輪，控制軟件就能從后向視頻攝像機將一段視頻輸入到儀表板顯示器上?？刂栖浖趦x表板顯示器上疊加各種各樣距離和方向的線，以便車輛向后運動時駕駛員能保持方向?？刂栖浖€能監(jiān)控臨近傳感器，以判定在車后方10英尺內(nèi)是否有物體存在。如果臨近傳感器檢測到某個物體在車后方x英尺內(nèi)就會讓車自動停止，這個x值由車輛的速度決定。本例中，“傳感器”提供臨近信息和視頻信息。“執(zhí)行器”用于車輛的停止系統(tǒng)。許多不同應(yīng)用領(lǐng)域的軟件需要監(jiān)控傳感器和控制物理執(zhí)行器。所依照的分析模式描述了能廣泛應(yīng)用的通用需求。形成了模式Actuator-Sensor(執(zhí)行器-傳感器)需求模式舉例模式名：執(zhí)行器—傳感器目的：詳細說明在嵌入式系統(tǒng)中的各種傳感器和執(zhí)行器。動機：嵌入式系統(tǒng)常有各種傳感器和執(zhí)行器。這些傳感器和執(zhí)行器都直接或間接連接到一個控制單元。雖然許多傳感器和執(zhí)行器看上去十分不同，但它們的行為是相似的，足以讓它們構(gòu)成一個模式。這個模式顯示了如何為一個系統(tǒng)指定傳感器和執(zhí)行器，包括屬性和操作。執(zhí)行器—傳感器模式為被動式傳感器使用“拉機制”(通過請求查詢來獲得值)，為主動傳感器使用“推機制”(值改變時，主動進行消息廣播)。需求模式舉例：執(zhí)行器—傳感器約束：每個被動傳感器必須有某種方法讀取傳感器的輸入和表示傳感器值的屬性。每個主動傳感器必須能在其值發(fā)生變更時廣播更新消息。每個主動傳感器應(yīng)該能發(fā)送一個生命刻度，即在特定時間幀中發(fā)布狀態(tài)信息，以便檢測出可能的錯誤動作。每個執(zhí)行者必須有某種方法調(diào)用由ComputingComponent構(gòu)件產(chǎn)生的適當應(yīng)答。每個傳感器和執(zhí)行器應(yīng)有實施檢測其自身操作狀態(tài)的功能。每個傳感器和執(zhí)行器能測試接收值或發(fā)送值的有效性，并且當值超出指定邊界時能設(shè)定其操作狀態(tài)。需求模式舉例：執(zhí)行器—傳感器適用性：對有多個傳感器和執(zhí)行器的任何系統(tǒng)都是非常有用的。結(jié)構(gòu)體：執(zhí)行器、被動傳感器和主動傳感器是抽象類，該模式中有四種不同的傳感器和執(zhí)行器。圖6-8：傳感器和執(zhí)行器的UML類圖需求模式舉例：執(zhí)行器—傳感器行為：順序圖，用以控制安全攝像機的調(diào)整(例如轉(zhuǎn)動、變焦、聚焦)圖6-9：傳感器和執(zhí)行器的UML順序圖需求模式舉例：執(zhí)行器—傳感器參與者：列舉需求模式中的類或?qū)ο?，并描述每個類和對象的職責需求模式舉例：執(zhí)行器—傳感器協(xié)作：描述的是對象和類之間如何進行交互活動以及實現(xiàn)自身的責任。當ComputingComponent需要更新PassiveSensor時，它詢問傳感器，通過發(fā)送適當?shù)南⒄埱髠髦?。ActiveSensor無需查詢。這些對象和類主動向計算機單元中傳送傳感器的值，使用適當?shù)姆椒ㄔO(shè)定在ComputingComponent中的值。對象和類在指定的時間幀發(fā)送至少一次生命刻度，以便用系統(tǒng)時間更新它們的時間戳。當ComputingComponent需要設(shè)定執(zhí)行器的值時，給執(zhí)行器發(fā)送值。ComputingComponent能使用適當?shù)姆椒ú樵兒驮O(shè)定傳感器和執(zhí)行器的操作狀態(tài)。如果發(fā)現(xiàn)操作狀態(tài)為零，就發(fā)送錯誤給FaultHandler錯誤處理程序，這個類包含處理錯誤消息的方法，比如啟動更詳細的恢復機制或者備份設(shè)備。如果不可恢復，系統(tǒng)只能使用傳感器最后的已知值或者默認值。需求模式舉例：執(zhí)行器—傳感器結(jié)果1.傳感器和執(zhí)行器類有一個通用接口。2