《軟件工程-理論、方法與實踐》課件第16章

第16章凈室軟件工程16.1凈室方法基礎(chǔ)16.2凈室技術(shù)16.3盒子行為和結(jié)構(gòu)本章小結(jié)習(xí)題16.1凈室方法基礎(chǔ)

16.1.1函數(shù)理論

凈室開發(fā)方法基于數(shù)學(xué)中的函數(shù)理論。一個函數(shù)定義了一個從定義域到值域的映射，定義域中的每個元素都可在值域中找到唯一的元素與之對應(yīng)。一個特定的程序好似定義了一個從定義域(程序所有可能輸入序列的集合)到值域(所有對應(yīng)于輸入的輸出集合)的映射。這樣一個程序的定義就是一個函數(shù)的定義，描述了一個程序的定義域(輸入序列)到值域(輸出空間)的映射。一個定義明確(well-defined)的函數(shù)有如下特性：完備性、一致性和正確性。因為一個程序定義描述了一個函數(shù)，所以它必須是完備的、一致的和正確的。

數(shù)學(xué)完備性要求對定義域中的每個元素，值域中至少有一個元素與之對應(yīng)。也就是說，每種可能的輸入都必須定義，并有一個輸出與之對應(yīng)。

數(shù)學(xué)一致性要求在值域中最多有一個元素與定義域中的某一元素對應(yīng)，也就是說，每個輸入只能對應(yīng)一個輸出。相對于需求定義的正確性由定義域?qū)＜遗袛?，對于一個給定的定義，某項設(shè)計及其定義的正確性是可以通過基于函數(shù)理論的推理來驗證的。

1986年Linger、Mills和Hevner提出了用于凈室軟件開發(fā)的盒子結(jié)構(gòu)的方法，該方法取代了Linger、Mills和Witt于1979年提出的將數(shù)學(xué)函數(shù)理論應(yīng)用于軟件開發(fā)的方法。并明確地提出有三種功能形式的盒子：黑盒、狀態(tài)盒和明盒。16.1.2統(tǒng)計理論

凈室測試方法基于統(tǒng)計學(xué)。在過去的幾十年中，統(tǒng)計學(xué)在工程中獲得了廣泛的應(yīng)用。

當(dāng)從經(jīng)濟上或技術(shù)上無法測試全體樣本時，便可以使用統(tǒng)計抽樣的方法。如果統(tǒng)計結(jié)果沒有達到質(zhì)量目標(biāo)，生產(chǎn)過程需做必要調(diào)整。這種以統(tǒng)計學(xué)為堅實基礎(chǔ)的從產(chǎn)品度量到生產(chǎn)過程之間的反饋循環(huán)，得到了廣泛的認(rèn)可和應(yīng)用。在軟件中，用于采樣的總體(population)是所有可能使用情況的集合，其中集合中的每個元素代表系統(tǒng)的一種可能運行情況。統(tǒng)計的目的是度量系統(tǒng)正確運行一個樣本的能力。因為總體是無限的，完全的測試是不可能的，所以必須利用統(tǒng)計學(xué)方法來對系統(tǒng)性能做一個有效的推理。測試過程無論如何擴展，在所有可能的輸入序列中都只能算一個很小的集合，所有的測試活動只能是無限總體中的抽樣。16.1.3凈室開發(fā)小組活動

凈室開發(fā)小組通常由3～8人組成，小組中有一名組長，根據(jù)整個組的責(zé)任和進度優(yōu)先級，負(fù)責(zé)小組內(nèi)部的工作分配和協(xié)調(diào)。凈室開發(fā)小組要完成三項主要工作：制定系統(tǒng)規(guī)范、開發(fā)和認(rèn)證。

小規(guī)模的項目可以只由一個小組來承擔(dān)開發(fā)任務(wù)。小組在開發(fā)的不同階段分別完成系統(tǒng)的規(guī)范制定、開發(fā)和認(rèn)證工作。對于中等規(guī)模的項目，可能需要多個小組的協(xié)作，一個核心小組負(fù)責(zé)規(guī)范和定義系統(tǒng)的結(jié)構(gòu)，開發(fā)并認(rèn)證一兩個增量，并為子系統(tǒng)制定規(guī)范，然后由這個核心小組的成員擔(dān)任開發(fā)和認(rèn)證各個子系統(tǒng)的小組組長。為了適應(yīng)用戶需求的變化或系統(tǒng)層次策略的改變，核心小組在一段時間后可能重組。對于大規(guī)模的項目，多組協(xié)作是必要的，小組職責(zé)的劃分可能要更清晰，包括規(guī)范組、開發(fā)組和認(rèn)證組。因此，開發(fā)伊始，應(yīng)該組成三個初始組，一個組制定系統(tǒng)規(guī)范，一個組開發(fā)初始增量，還有一個組認(rèn)證這些增量。此后，三個初始組的成員在子系統(tǒng)層次上領(lǐng)導(dǎo)特定的小組，所有小組成員都要接受凈室技術(shù)培訓(xùn)。評審是凈室小組的一項重要工作。每個產(chǎn)品從最初的概念到最后形成都要經(jīng)歷多次評審。評審有兩種類型，一種稱為開發(fā)評審，一種是驗證評審。

開發(fā)評審的焦點集中于技術(shù)策略、好的想法以及小組培訓(xùn)和交流。一般來說，軟件開發(fā)過程中，最初的開發(fā)思路未必是合理、全面的。因此，評審的一個關(guān)鍵目標(biāo)是在軟件的規(guī)范、設(shè)計和驗證方面找到更好的方案。一個小組成員可以召集相關(guān)人員來評審和討論一個只有一兩頁程序的設(shè)計方案，討論的焦點是關(guān)于控制和最初數(shù)據(jù)結(jié)構(gòu)的策略、算法的折中方案等等，這有利于產(chǎn)生好的思路和方案。一個產(chǎn)品可能要經(jīng)歷多次開發(fā)評審。成功的評審，可通過積累的知識進行交流來提高效率，也會使小組成員對產(chǎn)品更熟悉，并利于產(chǎn)生良好的軟件開發(fā)活動，最后的產(chǎn)品是小組所有成員智慧的結(jié)晶。驗證評審?fù)ㄟ^形式化方法來驗證產(chǎn)品的正確性和完備性，驗證評審首先由設(shè)計者逐一列舉出滿足函數(shù)的正確性條件，小組按順序檢查每個條件，不允許有存在異議的情況。任何修改必須經(jīng)過后續(xù)評審的重新驗證。一個產(chǎn)品經(jīng)過驗證評審后不再有更改的必要時就被認(rèn)為是正確和完整的。在凈室活動中，整個組對產(chǎn)品擁有主權(quán)，其中任何后續(xù)錯誤都應(yīng)該由該組承擔(dān)責(zé)任。由于在開發(fā)評審中，每個參與者都已熟悉了被驗證產(chǎn)品的結(jié)構(gòu)和內(nèi)容，因此在驗證評審中效率能夠得到保證。另外，凈室過程常采用可重用的規(guī)范和設(shè)計模型，因此，驗證工作多數(shù)也是可重用的。

16.2凈室技術(shù)

16.2.1基于統(tǒng)計過程控制下的增量開發(fā)

統(tǒng)計過程控制(SPC)是一種借助于數(shù)理統(tǒng)計方法的生產(chǎn)過程質(zhì)量控制的重要工具，它應(yīng)用統(tǒng)計方法對過程中各個階段進行監(jiān)控與診斷，從而達到改進與保證產(chǎn)品質(zhì)量的目的。SPC強調(diào)全過程管理，強調(diào)從整個系統(tǒng)看待問題；強調(diào)用科學(xué)的統(tǒng)計技術(shù)保證全過程預(yù)防原則的實現(xiàn)。SPC廣泛適用于生產(chǎn)過程、服務(wù)過程和管理過程。增量開發(fā)基于產(chǎn)品開發(fā)中受控迭代的工程原理——控制迭代。增量開發(fā)不是把整個開發(fā)過程作為一個整體，而是將其劃分為一系列較小的、累積的增量。增量開發(fā)是開發(fā)小組保持對項目控制的基礎(chǔ)。因為小組成員在任何時刻只需把注意力集中于工作的一部分，而不是一次考慮所有的事情。

增量開發(fā)把一個凈室項目分成一個有序的開發(fā)周期序列。在每個周期完成一些用戶功能。在每個增量開發(fā)完成時，產(chǎn)品的功能便可向客戶演示。這樣客戶對產(chǎn)品有真實的感觀認(rèn)識，可不受約束重新確認(rèn)需求或使需求更加清晰。這將使產(chǎn)品在完成時雙方的不滿意程度降到最低。增量開發(fā)計劃由系統(tǒng)結(jié)構(gòu)驅(qū)動，系統(tǒng)結(jié)構(gòu)定義了高層的結(jié)構(gòu)和接口。在給定一個系統(tǒng)結(jié)構(gòu)的情況下，增量的規(guī)劃(參見第2章)有許多因素要考慮。如要考慮功能依賴的問題，核心功能應(yīng)該優(yōu)先開發(fā)。例如，在嵌入式系統(tǒng)中，硬件開發(fā)的進度協(xié)調(diào)是一個要考慮的要素；在圖形用戶界面(GUI)系統(tǒng)中，第一個增量通常是制定用戶接口原型，這是需求中最易改變的部分。另外，影響增量開發(fā)的其他因素還包括：開發(fā)的風(fēng)險、復(fù)雜性、重用性以及使用頻率等。如果可能，在較早的增量中要包含最具不確定性的部分，這樣可盡早理解影響進度的因素。

智能控制、客戶反饋、風(fēng)險管理以及增量開發(fā)等優(yōu)點可使項目組有效地統(tǒng)計過程控制。在每一增量開發(fā)結(jié)束時，要度量產(chǎn)品的質(zhì)量并和小組的質(zhì)量目標(biāo)進行比較。比較的結(jié)果可以確定開發(fā)是否在控制之下，出現(xiàn)較小的偏差時要對項目進行追蹤，而出現(xiàn)不可接受的偏差時要進行仔細(xì)的性能評審。如果確定了問題，則小組要進行過程調(diào)整以便在下一個增量中改進性能。16.2.2基于函數(shù)的定義(Specification)、設(shè)計和驗證

凈室采用的方法不僅具有堅實的理論基礎(chǔ)，而且具有良好的可操作性。系統(tǒng)的定義和實現(xiàn)被規(guī)范為函數(shù)盒的轉(zhuǎn)換過程。系統(tǒng)首先定義描述外部視圖的黑盒，之后，黑盒被轉(zhuǎn)化成一個狀態(tài)機視圖，稱之為狀態(tài)盒，最后由過程，即明盒來實現(xiàn)。這些形式上不同、行為上等價的視圖統(tǒng)稱為盒子結(jié)構(gòu)。盒子結(jié)構(gòu)是基于對象的，并支持軟件工程的信息隱蔽以及接口和實現(xiàn)分離的關(guān)鍵原則。圖16.1黑盒的概念視圖黑盒規(guī)范定義了一個系統(tǒng)或其組件從輸入到輸出的映射的外部行為。因只需定義外部行為，而不必描述內(nèi)部狀態(tài)或?qū)崿F(xiàn)細(xì)節(jié)，故稱之為黑盒。黑盒只定義一個系統(tǒng)或其組件的用戶視圖。這里的用戶可能是一個人、硬件單元或其他程序。圖16.1從概念上描述了一個黑盒，其中SH代表激勵歷史(StimulusHistory)，R代表相應(yīng)的響應(yīng)(Response)。一個激勵序列是對系統(tǒng)的一系列單一輸入。一個激勵可能由用戶(如一次按鍵或鼠標(biāo)單擊)產(chǎn)生，也可能由硬件(如一個時鐘脈沖或來自傳感器的信號)產(chǎn)生，或者是由另一個軟件組件(如操作系統(tǒng)或數(shù)據(jù)庫)產(chǎn)生。一系列這樣的激勵組成了一個獨一無二的激勵序列，激勵必須對應(yīng)一個響應(yīng)。黑盒由所有可能的激勵列表、響應(yīng)列表以及激勵到響應(yīng)的映射規(guī)則(函數(shù))組成。黑盒是一種與狀態(tài)無關(guān)，與過程無關(guān)的函數(shù)描述，其映射必須是完備的、一致的和可跟蹤的正確性。狀態(tài)盒規(guī)范由黑盒導(dǎo)出，是通向?qū)崿F(xiàn)的第一步。狀態(tài)盒把為獲得黑盒指定的外部行為而需保存的激勵元素定義為狀態(tài)數(shù)據(jù)。狀態(tài)盒把系統(tǒng)或其組件所需行為定義為一個從當(dāng)前激勵和舊狀態(tài)到對應(yīng)響應(yīng)和新狀態(tài)的映射(變換)。定義狀態(tài)數(shù)據(jù)后，就不必考慮激勵的歷史了。圖16.2描述了狀態(tài)盒的概念視圖。

狀態(tài)盒只描述了系統(tǒng)或其組件的響應(yīng)和狀態(tài)更新，它不包括過程實現(xiàn)的細(xì)節(jié)。和黑盒一樣，狀態(tài)盒必須滿足完備性、一致性和可跟蹤的正確性。明盒規(guī)范用過程實現(xiàn)了對應(yīng)的狀態(tài)盒。這些過程實現(xiàn)了狀態(tài)盒的映射規(guī)則，也有可能引進代表宏操作的新黑盒。過程必須足以完成必要的狀態(tài)更新和所需的響應(yīng)。圖16.3描述了明盒的概念視圖，為一順序控制結(jié)構(gòu)。分支、循環(huán)和并發(fā)控制結(jié)構(gòu)也可在明盒中出現(xiàn)。引入的黑盒將在隨后的求精過程中細(xì)化為狀態(tài)盒和明盒。圖16.2狀態(tài)盒的概念視圖圖16.3明盒的概念視圖(BB=黑盒)與黑盒和狀態(tài)盒一樣，明盒也必須滿足完備性、一致性和可跟蹤的正確性。明盒可由系統(tǒng)的設(shè)計語言或目標(biāo)語言來加以定義。

在盒子結(jié)構(gòu)規(guī)范設(shè)計中，黑盒定義系統(tǒng)的行為；狀態(tài)盒是黑盒的細(xì)化，定義了所需的狀態(tài)數(shù)據(jù)；明盒是狀態(tài)盒的細(xì)化，定義了所需的過程/處理。每一種盒結(jié)構(gòu)在小組評審時都要經(jīng)正確性驗證。小組采用基于函數(shù)理論的推理，根據(jù)前一步來驗證每一細(xì)化步驟的正確性。換言之，開發(fā)小組確認(rèn)在每一步中定義的激勵—響應(yīng)映射規(guī)則都在后續(xù)步驟中被保持。明盒過程可能包含無限多的實現(xiàn)路徑，在凈室技術(shù)中，這些路徑不是通過基于路徑的審查或軟件測試進行全部的檢查，而是通過函數(shù)理論的正確性定理進行程序正確性驗證。正確性定理是基于驗證單個控制結(jié)構(gòu)而不是跟蹤整個路徑，由于明盒過程包括有限的控制結(jié)構(gòu)，因此正確性定理將驗證定義為有限情形的檢查，并從邏輯上全部驗證所有可能的情況。16.2.3統(tǒng)計測試和軟件認(rèn)證

使用模型是指系統(tǒng)使用中所有可能的情形及其發(fā)生的概率。使用模型可以是多種形式的，如馬爾可夫模型和形式化語法。在馬爾可夫模型中，使用模型由一個狀態(tài)集組成，狀態(tài)之間由轉(zhuǎn)移弧線連接，轉(zhuǎn)移弧線表示系統(tǒng)測試時可能的激勵條件，并有一個概率值與之對應(yīng)，該概率值表示從給定狀態(tài)發(fā)生特定轉(zhuǎn)移的可能性大小。從起始狀態(tài)穿過模型到終點狀態(tài)便得到了一個測試用例。圖16.4描述了一個使用模型。其中弧線代表激勵條件，節(jié)點代表使用狀態(tài)，每條弧線標(biāo)有激勵和發(fā)生的概率。圖16.4一個簡單的使用模型使用模型是可重用的項目資源，測試用例可由其產(chǎn)生。實際上，測試一個系統(tǒng)可采用多種使用模型，對每種使用模型可采用多種概率分布。在某些情況下，系統(tǒng)可能提供一些很少使用的功能，但這些功能如果出現(xiàn)處理失誤則會帶來嚴(yán)重的后果，如關(guān)閉核反應(yīng)堆。這種功能執(zhí)行概率很小，但當(dāng)集中測試這種可能產(chǎn)生重大后果的功能時，需要采用嚴(yán)格的安全使用模型、風(fēng)險使用模型、惡意使用模型或其他特定環(huán)境使用模型。統(tǒng)計測試可以方便地結(jié)合其他測試一起進行。

16.3盒子行為和結(jié)構(gòu)

盒子結(jié)構(gòu)是在需求定義和設(shè)計中對系統(tǒng)的外在基本屬性和內(nèi)在實現(xiàn)行為的描述。圖16.5描繪了三種盒子(黑盒、狀態(tài)盒、明盒)從定義到實現(xiàn)的精化過程，以及相反的驗證過程。黑盒確定了一個系統(tǒng)或系統(tǒng)組件的外部行為；狀態(tài)盒則指定了完成外部行為所需的狀態(tài)數(shù)據(jù)。明盒則進一步把狀態(tài)盒具體化，它確定了完成狀態(tài)盒行為的過程設(shè)計。明盒由程序控制結(jié)構(gòu)組成。每一步的細(xì)化是根據(jù)前一步進行驗證的。盒子結(jié)構(gòu)將系統(tǒng)開發(fā)的三個方面(行為、數(shù)據(jù)和過程/處理的定義)分離開，但又把它們連成一個細(xì)化和驗證的內(nèi)聚過程。圖16.5盒結(jié)構(gòu)的精化和驗證(BB=黑盒)16.3.1黑盒行為

黑盒定義了一個系統(tǒng)或系統(tǒng)組件的外部行為，提供了從外部行為來看待系統(tǒng)或組件的視圖。例如，工作站接受鍵盤和鼠標(biāo)的激勵會改變當(dāng)前窗口內(nèi)容或顯示新的窗口以作出響應(yīng)，而用戶對工作站的內(nèi)部操可以一無所知，感受到的僅僅是它的外部行為。當(dāng)系統(tǒng)接受激勵S，將產(chǎn)生響應(yīng)R。響應(yīng)往往不僅與當(dāng)前激勵有關(guān)，還與到目前為止收到的歷史激勵有關(guān)。例如，假設(shè)定義一個計算器的黑盒，如果正在進行一次計算，當(dāng)前的激勵是按了鍵5；如果此前的歷史激勵是C718，其中C表示清零，那么響應(yīng)將是顯示7185。也就是說，計算器將當(dāng)前顯示的數(shù)字左移一位，并在單元位置插入5；如果此前的歷史激勵是C718+，則響應(yīng)是在屏幕位置顯示一新的字符5。因此，系統(tǒng)的當(dāng)前激勵及此前的歷史激勵的共同作用才確定了它的響應(yīng)。黑盒行為的數(shù)學(xué)語義可以寫成如下函數(shù)：

歷史激勵?→?響應(yīng)

簡記為

SH?→?R

SH表示包括當(dāng)前激勵的所有歷史激勵。黑盒行為不包含狀態(tài)數(shù)據(jù)及過程實現(xiàn)。它僅定義了取決于歷史使用的能被用戶感受到的外部可見行為。因此，黑盒關(guān)心的是從用戶角度看待系統(tǒng)行為的問題，而并不是考慮狀態(tài)和過程的設(shè)計。黑盒規(guī)范定義了所有可能使用情況所需的行為。也就是說，在黑盒規(guī)范中，為所有可能的當(dāng)前激勵和歷史激勵以及它們的組合定義了正確的響應(yīng)，在凈室項目中黑盒定義的下列三個原則對高效系統(tǒng)開發(fā)很關(guān)鍵。

(1)對系統(tǒng)擁有者和用戶而言，黑盒定義了他們分析和協(xié)商的所需行為，這是他們準(zhǔn)備資源、著手開發(fā)和測試的前提。

(2)對系統(tǒng)開發(fā)者而言，黑盒定義了待設(shè)計和實現(xiàn)的所需行為。

(3)對系統(tǒng)測試者而言，黑盒定義了在測試過程中待確認(rèn)的所需行為。黑盒可以用表格形式來定義，表16.1的三列分別對應(yīng)于激勵歷史條件、當(dāng)前激勵和響應(yīng)。這個黑盒定義了一個基于12個月平均銷售額的預(yù)測系統(tǒng)，用于為一個產(chǎn)品清單控制系統(tǒng)中數(shù)以千計的產(chǎn)品預(yù)測銷售額。其中，產(chǎn)品的月銷售額構(gòu)成當(dāng)前的激勵，并根據(jù)歷史激勵條件產(chǎn)生響應(yīng)。黑盒規(guī)則1指定了某一產(chǎn)品少于12個月銷售額時的正確響應(yīng)，規(guī)則2指定了至少有12個月銷售額時的正確行為。這張表以一種非形式的方式描述了系統(tǒng)行為，其中尖括號中的內(nèi)容有待于進一步定義和細(xì)化。比如，規(guī)則1可進一步細(xì)化為6～12個月的平均銷售額。16.3.2狀態(tài)盒行為

狀態(tài)盒對系統(tǒng)或組件進行初步細(xì)化，定義了狀態(tài)空間。狀態(tài)盒把激勵歷史條件封裝成狀態(tài)數(shù)據(jù)，但仍沒有涉及具體過程。它把舊的狀態(tài)OS(OldState)和激勵S映射到新的狀態(tài)NS(NewState)和響應(yīng)R；而新的狀態(tài)在下—次變換時則變成了舊狀態(tài)。狀態(tài)盒子行為的語義是一個如下的變換函數(shù)：

(舊狀態(tài)，激勵)?→?(新狀態(tài)，響應(yīng))

或簡寫為

(OS，S)?→?(NS，R)

狀態(tài)盒根據(jù)黑盒來細(xì)化和驗證。狀態(tài)信息就是為了符合黑盒子定義而必須保存的激勵歷史，這樣信息來自于黑盒，無需再定義。因為每個歷史激勵可用狀態(tài)來表示，所以每個黑盒對應(yīng)一個狀態(tài)盒。狀態(tài)可以有多種不同的表示和訪問方法。狀態(tài)盒可用表格來定義，對應(yīng)的列包括舊狀態(tài)、激勵、新狀態(tài)、響應(yīng)以及相應(yīng)的黑盒規(guī)則等。表16.1定義了銷售額預(yù)測系統(tǒng)的黑盒，表16.2將其轉(zhuǎn)換為狀態(tài)盒。通過對黑盒的激勵歷史條件進行分析，產(chǎn)生〈銷售文件〉狀態(tài)項，用來保存每種產(chǎn)品最近11個月的銷售額；銷售文件的每條記錄〈產(chǎn)品〉來標(biāo)識，并包含一個能存11個月銷售額的數(shù)組。由于當(dāng)前激勵加上前11個月的銷售額便可求出所需的平均值，所以只需存11個值就夠了，不必保留更早的，而接下來的激勵將導(dǎo)致刪除早于11個月的銷售額。表16.2中的規(guī)則1定義了當(dāng)激勵引入一個新產(chǎn)品時所需的行為；規(guī)則2定義了當(dāng)狀態(tài)盒已知的產(chǎn)品還沒達到11個月的銷售額時所需的行為，變換1和2只是將激勵顯示給用戶；規(guī)則3定義了計算平均值的穩(wěn)定狀態(tài)。注意，每條規(guī)則都要進行相應(yīng)的狀態(tài)更新，為處理隨后的激勵做好準(zhǔn)備。例如，規(guī)則3將引起這樣的狀態(tài)更新：刪除最早的〈銷售額值〉，把當(dāng)前激勵作為最新的〈銷售額值〉加入到〈銷售文件〉的該〈產(chǎn)品〉記錄中。16.3.3明盒行為

系統(tǒng)或組件的明盒實際上定義了狀態(tài)盒行為的過程，即定義了黑盒/狀態(tài)盒行為的具體實現(xiàn)過程，也是對狀態(tài)盒進一步細(xì)化的過程。明盒可以是精確的處理過程定義，也可以是計算機程序或程序集，基于程序的內(nèi)部狀態(tài)OS，接受激勵S，產(chǎn)生新的內(nèi)部狀態(tài)NS并產(chǎn)生響應(yīng)R。這些過程由基于結(jié)構(gòu)化程序設(shè)計的控制結(jié)構(gòu)來定義，即順序、選擇、循環(huán)結(jié)構(gòu)，如果引入并發(fā)機制則還要加上并行結(jié)構(gòu)。明盒用這些控制結(jié)構(gòu)來完成新狀態(tài)和響應(yīng)的計算。對于所給狀態(tài)盒可以定義多種不同的明盒。明盒可用一個變換函數(shù)表示：

(舊狀態(tài)，激勵)?→?(新狀態(tài)，響應(yīng))，借助過程定義

或簡記為

(OS，S)?→?(NS，R)，借助過程定義

明盒的過程可以重用已有的黑盒，也可在后續(xù)求精過程的狀態(tài)盒與明盒中引入新的黑盒。

明盒的驗證是把其操作抽象成一個導(dǎo)出的狀態(tài)盒并與原來的狀態(tài)盒進行比較。16.3.4盒子結(jié)構(gòu)層次

正如前面所述，盒子結(jié)構(gòu)層次隨著逐步求精和驗證而不斷進化。這是一種使用的分層結(jié)構(gòu)而不是一個部件的分層結(jié)構(gòu)。也就是說，一個盒子的每次使用都在分層結(jié)構(gòu)中占有不同的位置，并且通過盒子的順序和并發(fā)使用定義了所有處理過程。

圖16.6的例子描繪了一個初始黑盒被細(xì)化為一個狀態(tài)盒，再細(xì)化為一個明盒的過程。明盒的控制結(jié)構(gòu)在下一個層次包含六個黑盒。這些黑盒可以是相同的，也可以是不相同的，或者是幾個黑盒的組合。使用系統(tǒng)組件的分層結(jié)構(gòu)有助于對系統(tǒng)開發(fā)管理保持智能控制。圖16.6盒結(jié)構(gòu)的使用層次(BB=黑盒；SB=狀態(tài)盒；CB=明盒)16.3.5盒子結(jié)構(gòu)的開發(fā)過程

基于前面的描述，下面歸納了盒子結(jié)構(gòu)的開發(fā)過程：

(1)定義系統(tǒng)需求。

(2)確定和確認(rèn)黑盒。

●定義系統(tǒng)邊界和確定所有的激勵和響應(yīng)。

●

確定黑盒映射規(guī)則。

●與系統(tǒng)擁有者和用戶一起確認(rèn)黑盒。

(3)確定和驗證狀態(tài)盒。

●確定狀態(tài)數(shù)據(jù)和初始狀態(tài)值。

●確定狀態(tài)盒變換功能。

●從狀態(tài)盒導(dǎo)出黑盒的行為，把