4、盒子结构层次
正如前面所述，盒子结构层次随着逐步求精和验证而不断进化。这是一种使用的分层结构而不是一个部件的分层结构，也就是说，一个盒子的每次使用都在分层结构中占有不同的位置，并且通过盒子的顺序和并发使用定义了所有处理过程。当然，使用的分层结构并不意味代码在执行使用的任何地方都要复制。
下图的例子描绘了一个初始黑盒被细化为一个状态盒，再细化为一个明盒。明盒的控制结构在下一个层次包含六个黑盒。这些黑盒可以是相同的，也可不相同，或者是几个的组合。使用系统组件的分层结构有助于对系统开发管理保持智能控制。
5、盒子结构原则
本节归纳了盒子结构指南与分析的四个重要原则（Mills.Linger.Hevner1986，1987）。前两个原则针对盒子结构求精过程，后两个针对设计过程。
引用透明性（Referential Transparency）原则：在一个系统组件的授权开发期间，应该完全明确该组件的所有的需求，使得完成该组件逻辑上不再需要进一步的规范。
每只黑盒应该为系统或其组件定义所需的全部外部行为。当状态盒正确地执行黑盒所需行为以及明盒正确地执行状态盒所需行为时也必须满足引用透明性。这三种盒子分别定义行为、状态和过程，但都是完整的并与系统和系统组件的定义在行为上是等价的，不会漏掉任何行为。这种具有引用透明性的分层结构可以延缓细节实现而不会遗漏细节。明盒在保持引用透明性方面起到关键作用。因为它组织和连接下一层要嵌入的子系统和组件的操作。
有效的项目管理需要组织大量的细节成为用于代理和开发的相关结构。盒子结构中的引用透明性提供简洁的代理和责任。当组件以一定的信任度分配给开发小组时，明确了组件承诺，赋予了职责。另外，引用透明性明确了责任，减少了许多讨论和协调，从而简化了项目成员之间的交流，提高了效率。
事务闭包（Transaction Closure）原则：系统或其组件的事务必须是充分的，以便获得并保留所有的状态数据。同时，状态数据必须是足够的，以完成所有的事务。
事务是对行为的高层次描述，它可以由低层次的事务组成。例如，事务"银行账目清单"可由"存取报表"，"存款"，"取款"等事务组成。事务闭包定义了一个迭代的分析过程，以保证系统或其组件的规范中的事务和状态数据是足够的。这个过程从由主要用户进行的主要事务开始，所定义的状态数据要支持这些事务。这些数据需要额外的事务来初始化和更新它们，这会产生更多的状态数据，依此类推。这种迭代一直进行到不再需要增加数据为止，也就满足了事务闭包原则。
状态迁移（State Migration）原则：系统数据应该迁移和封装到最好小的系统部分，这样不必复制更新。
状态迁移使得状态数据封装在合适的层次，以减少系统规范和结构的复杂性。例如，考虑一个包含状态数据T并在下一层将调用黑盒的明盒。如果T仅在那个黑盒的状态盒中被引用，那么T可以向下迁移和封装，而不必复制更新。相反，当设计展开时，为了消除复制更新，应该将数据向上迁移。
共享服务（Common Services）原则：对于多次用到的系统部分可以考虑定义共享服务。应该在系统部分创建尽可能多的重用机会。
在软件系统中到处可发现共享服务。例如，GUI就是一组管理用户界面的内部状态和更新显示的共享服务。在盒子结构开发中，定义共享服务是常有的事。例如，一个天气预报系统可能要处理从许多分散的传感器传来的测量数据。在系统的许多地方都需要对测量数据进行初始化、更新、检索和删除。可以在新的盒子结构层次把这些测量数据作为状态封装并为所有的程序提供共享服务。这种设计隔离和保护了测量数据，加强了控制访问的整体性，也有助于为未预见的将来的数据使用提供准备。这样重复使用软件组件为提高生产率和可靠性带来了机会。
6、盒子结构的开发过程
基于前面的描述，下面归纳了盒子结构的细化和验证的一般过程。下面的例子安全警报器和第三部分的例子卫星控制系统将详细说明该过程。
盒子结构的开发过程
（1）定义系统需求。
（2）确定和确认黑盒
定义系统边界和确定所有的激励和响应。
确定黑盒映射规则。
同系统拥有霆和用户一起确认黑盒
（3）确定和验证状态盒
确定状态数据和初始状态值。
确定状态盒变换功能。
从状态盒导出黑盒的行为，把导出黑盒与原来的黑盒进行比较看是否等价。
（4）设计和验证明盒
设计明盒的控制结构和操作。
必要时嵌入新的黑盒或重用黑盒。
从明盒导出状态盒的行为，把导出状态盒与原来的状态盒进行比较看是否等价。
（5）对新的黑盒重复上述过程。
必须注意的是，为适用于特定的项目环境和目标可对该过程进行裁减以最好地利用项目资源。例如，对于功能丰富的系统应该把分析重点放在其外部行为上。这种情况下，重点在于黑盒规范。执行大量数据操作的子系统可以表述为简单的黑盒行为，但可能带来状态结构、存储和检索的复杂性。这时，重点在于定义状态盒。进行大量数学运算的组件只需展示简单的黑盒行为和使用简明的状态定义，但在明盒中需要复杂的结构和操作。这时，重点在于设计明盒。
由许多子系统和组件组成的大规模系统在具体实施过程中要采用许多不同的方法。但不管把重点放在那里，系统开发都应该和风险承担者取得一致，并从最可能明白的地方开始。要注意的是在系统开发初期对泛泛的需求往往是不可能完成全明白的。盒子结构方法与启发和发现需求的的过程是兼容的，它是利用用户的反馈通过原型的增量开发来进行实施。但即使是原型，需要执行的部分需求应该在一开始就是明确的，以有效利用资源和减小风险。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
