Step-1. 接口可能是已经存在的，也可能是架构师脑海里构思中的。无论是那一种，架构师都必须清晰认知到它(们)的存在。例如下图表示智能城市里的智能家庭系统和交通车联网的互联互通架构：
于是，架构师会认知到两个重要接口的存在，如下图：
Step-2. 藉由EIT造形<I>来明确地<定义>上图里的接口，并藉由<E>和<T>来辅助其清晰表达接口的<涵意>。因此，使用两个EIT造形分别来表述一个接口。
Step-3. 藉由這兩個EIT造形將三項善變的內涵分離開來，如下圖：
Step-4. 架构师想象EIT造形就是<基类/子类>的结构，<E>是基类(Super class)，<T>是子类(Subclass)，而<I>则实现为基类里的抽象函数(Abstract function)。于是，架构师设计一个明确的架构，如下图：
Step-5. 上图只是架构师脑海里的设计而已，那么又如何确保它是可落地的呢?因此，需要尽快落实为代码，并立即进行检验和测试。
Step-6.例如，通常先测试<通信协议>。包括：
测试两个<I>是否能有效包容通信协议的技术变迁。
对通信机制的能量进行可靠性测试。
于是，撰写两个<E&I>代码；并写撰写两个Mock<T>代码。如下图：
所谓Mock代码，就意味着并没有真正联结到<智能家庭系统>和<交通车联网>；而只是做个赝品(Mock)来配合<E&I>来进行测试而已。
Step-7.接着，测试<交通车联网>。不必等待<智能家庭>系统的完成，就能开始测试<交通车联网>了。如下图：
Step-8.接着，测试<智能家庭>系统。如下图：
以上是Mock类别的典型角色而已。有时可做更多的变化和运用，例如设计右边Mock<E&I>来配合测试。如下图：
此外，还可以设计左边的Mock<E&I>来配合测试。如下图：
从上所述可知，EIT造形是代码层级的<基类/子类>结构，我们能在<智能家庭>系统和<交通车联网>开发建置之前，就将EIT造形先落实为代码，迅速进行重要接口、协议或机制的可靠性测试。这对于大型系统整合，或软硬结合产品的研发是非常关键的。
~ End ~
