4、盒子結構層次
正如前面所述，盒子結構層次隨著逐步求精和驗證而不斷進化。這是一種使用的分層結構而不是一個部件的分層結構，也就是說，一個盒子的每次使用都在分層結構中占有不同的位置，并且通過盒子的順序和并發使用定義了所有處理過程。當然，使用的分層結構并不意味代碼在執行使用的任何地方都要復制。
下圖的例子描繪了一個初始黑盒被細化為一個狀態盒，再細化為一個明盒。明盒的控制結構在下一個層次包含六個黑盒。這些黑盒可以是相同的，也可不相同，或者是幾個的組合。使用系統組件的分層結構有助于對系統開發管理保持智能控制。
5、盒子結構原則
本節歸納了盒子結構指南與分析的四個重要原則（Mills.Linger.Hevner1986，1987）。前兩個原則針對盒子結構求精過程，后兩個針對設計過程。
引用透明性（Referential Transparency）原則：在一個系統組件的授權開發期間，應該完全明確該組件的所有的需求，使得完成該組件邏輯上不再需要進一步的規范。
每只黑盒應該為系統或其組件定義所需的全部外部行為。當狀態盒正確地執行黑盒所需行為以及明盒正確地執行狀態盒所需行為時也必須滿足引用透明性。這三種盒子分別定義行為、狀態和過程，但都是完整的并與系統和系統組件的定義在行為上是等價的，不會漏掉任何行為。這種具有引用透明性的分層結構可以延緩細節實現而不會遺漏細節。明盒在保持引用透明性方面起到關鍵作用。因為它組織和連接下一層要嵌入的子系統和組件的操作。
有效的項目管理需要組織大量的細節成為用于代理和開發的相關結構。盒子結構中的引用透明性提供簡潔的代理和責任。當組件以一定的信任度分配給開發小組時，明確了組件承諾，賦予了職責。另外，引用透明性明確了責任，減少了許多討論和協調，從而簡化了項目成員之間的交流，提高了效率。
事務閉包（Transaction Closure）原則：系統或其組件的事務必須是充分的，以便獲得并保留所有的狀態數據。同時，狀態數據必須是足夠的，以完成所有的事務。
事務是對行為的高層次描述，它可以由低層次的事務組成。例如，事務"銀行賬目清單"可由"存取報表"，"存款"，"取款"等事務組成。事務閉包定義了一個迭代的分析過程，以保證系統或其組件的規范中的事務和狀態數據是足夠的。這個過程從由主要用戶進行的主要事務開始，所定義的狀態數據要支持這些事務。這些數據需要額外的事務來初始化和更新它們，這會產生更多的狀態數據，依此類推。這種迭代一直進行到不再需要增加數據為止，也就滿足了事務閉包原則。
狀態遷移（State Migration）原則：系統數據應該遷移和封裝到最好小的系統部分，這樣不必復制更新。
狀態遷移使得狀態數據封裝在合適的層次，以減少系統規范和結構的復雜性。例如，考慮一個包含狀態數據T并在下一層將調用黑盒的明盒。如果T僅在那個黑盒的狀態盒中被引用，那么T可以向下遷移和封裝，而不必復制更新。相反，當設計展開時，為了消除復制更新，應該將數據向上遷移。
共享服務（Common Services）原則：對于多次用到的系統部分可以考慮定義共享服務。應該在系統部分創建盡可能多的重用機會。
在軟件系統中到處可發現共享服務。例如，GUI就是一組管理用戶界面的內部狀態和更新顯示的共享服務。在盒子結構開發中，定義共享服務是常有的事。例如，一個天氣預報系統可能要處理從許多分散的傳感器傳來的測量數據。在系統的許多地方都需要對測量數據進行初始化、更新、檢索和刪除�？梢栽谛碌暮凶咏Y構層次把這些測量數據作為狀態封裝并為所有的程序提供共享服務。這種設計隔離和保護了測量數據，加強了控制訪問的整體性，也有助于為未預見的將來的數據使用提供準備。這樣重復使用軟件組件為提高生產率和可靠性帶來了機會。
6、盒子結構的開發過程
基于前面的描述，下面歸納了盒子結構的細化和驗證的一般過程。下面的例子安全警報器和第三部分的例子衛星控制系統將詳細說明該過程。
盒子結構的開發過程
（1）定義系統需求。
（2）確定和確認黑盒
定義系統邊界和確定所有的激勵和響應。
確定黑盒映射規則。
同系統擁有霆和用戶一起確認黑盒
（3）確定和驗證狀態盒
確定狀態數據和初始狀態值。
確定狀態盒變換功能。
從狀態盒導出黑盒的行為，把導出黑盒與原來的黑盒進行比較看是否等價。
（4）設計和驗證明盒
設計明盒的控制結構和操作。
必要時嵌入新的黑盒或重用黑盒。
從明盒導出狀態盒的行為，把導出狀態盒與原來的狀態盒進行比較看是否等價。
（5）對新的黑盒重復上述過程。
必須注意的是，為適用于特定的項目環境和目標可對該過程進行裁減以最好地利用項目資源。例如，對于功能豐富的系統應該把分析重點放在其外部行為上。這種情況下，重點在于黑盒規范。執行大量數據操作的子系統可以表述為簡單的黑盒行為，但可能帶來狀態結構、存儲和檢索的復雜性。這時，重點在于定義狀態盒。進行大量數學運算的組件只需展示簡單的黑盒行為和使用簡明的狀態定義，但在明盒中需要復雜的結構和操作。這時，重點在于設計明盒。
由許多子系統和組件組成的大規模系統在具體實施過程中要采用許多不同的方法。但不管把重點放在那里，系統開發都應該和風險承擔者取得一致，并從最可能明白的地方開始。要注意的是在系統開發初期對泛泛的需求往往是不可能完成全明白的。盒子結構方法與啟發和發現需求的的過程是兼容的，它是利用用戶的反饋通過原型的增量開發來進行實施。但即使是原型，需要執行的部分需求應該在一開始就是明確的，以有效利用資源和減小風險。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
