图8：具体表示层模型
可以对表示层模型模式进行扩展，以使多种组件作为StaticDisplay，InteractionControls 和ActionInvokers。这种扩展能够提供一个可公布的标记，来建模抽象和具体组件间的映射关系。然而，图8 所示的具体表示层模型给出了在对我们的案例进行建模时，什么是所需要的。另外，具体表示层模型还描述了如何指定表示层的布局。每一个Container 类的实例必须聚合（aggregate）一个LayoutImplementation 实例。有几种布局对象（layout object）可作为LayoutImplementation 的子类，被添加至具体表示层模型之中。我们并没有对UI 表示层布局的建模进行完全说明。实际上，具体表示层模型依赖于环境这样的语义。对于在图8 中所示的具体表示层模型的情形，Java 提供了内嵌于方法中的算法，并以此作为模板来对UI 表示层模型的布局进行建模。
基于表示层框架的具体表示层模型，不会导致很大部分的设计需要依赖于具体的环境，它提供了一个在《apm》类和组件类之间具有灵活、稳固关系的模型。比如，虽然图8 是使用Java 的AWT 组件进行建模的，但是Swing组件也能够非常自然地对AWT 组件进行替换，而不会破坏抽象表示层模型。
图9 中的抽象表示层模型便是对ConnectionUI（如图5 所示）所进行的建模。该模型为一个对象图（object diagram），其所用到的链接包括：节4.1 中的compose（组合）和integrate（集成）链接，与Frame 实例（其可作为AbstractContainer）以及它们各自的LayoutImplementation 实例相关的organise（组织）链接。对于每一个Frame实例来言，该连接是必不可少的。进一步说，图9 表明Panels 可以用来代替Containers 对非顶层容器（non top-level containers）进行建模。当边界类（bound classes）的子类作为具体表示层模型的一部分时，便会出现该情形。
5.2 具体表示层的行为
一旦我们了解了如何对具体表示层模型的结构建模，就需要对表示层的行为进行建模。如图9 所示，大量的组件具有与其相关联的行为。例如，当用户按下按钮时，OK 对象（Button 类）将会触发一个与其相关联的事件。
而另一方面，PasswordLabel 对象（Label 类）则没有关联任何需要应用程序进行处理的事件。
关于对表示层的行为进行建模的第一个问题是，如何从UML 图中标识出可能与《boundary》对象相关联的事件。在我们的应用程序模型中每一个《boundary》对象就是一个Frame 实例，它具有两个与其自身进行事件关联的操作：sendConfirmation（）和sendCancellation（）。
通过对应用程序模型进行检查我们可以发现，sendConfirmation（）消息已在图4 所示的序列图中进行过描述，而sendCancellation（）则根本就没有进行过建模过。实际上，每一个从角色（actor）发往《boundary》对象的消息都表明了一个与UI 组件相关联的事件。因此，一个可行的方法是可以为每个UI 事件生成一个交互图，用来建模所有的表示层行为。在ConnectToSystem 的用例中我们仅建模了一个场景：用户成功登录至系统。所以，我们需要对当ConnectToSystem 中的CANCEL 按钮被按下时的场景进行建模。
图9：ConnectionUI 的具体表示层模型