第三类指的是那些一旦发出请求即进行编译的脚本页，以后的所有请求都使用编译过的页。只有最初页的内容谋淞耍靡巢呕峤辛硪淮伪嘁搿Ｕ饫嘁辰橛诹榛畹慕疟疽澈透咝У谋嘁胍持洹?
Web 页建模
Web 页，不管是脚本页还是编译页，都一对一地映射到 UML 中的构件。构件是系统的"物理"可更换部件。模型的实施视图（构件视图）描述了系统的构件及它们之间的关系。在 Web 应用程序中，这个视图描述了系统的所有 Web 页及它们彼此之间的关系（如超链接）。在一定程度上，Web 系统的构件图就相当于站点图。
由于构件仅仅代表了接口的物理打包方式，它们并不适用于对页内部的协作关系建模。这一抽象级别仍需要成为模型的组成部分，而且对设计员和实施员而言极其重要。为引入正题，我们可以说每个 Web 页在模型的设计视图（逻辑视图）中都是一个 UML 类，它与其他页的关系（关联关系）即代表了超链接。但如果考虑到任何 Web 页都可能既代表一组只存在于服务器上的功能和协作，同时又代表只存在于客户机上的一组完全不同的功能和协作，那么这种抽象就不成立了。举例来说，使用动态 HTML（客户端脚本）作为部分输出的所有服务器 Web 脚本页都是这样的页。对这个问题的直接反应可能就是为类中的每个属性或操作设计原型，指明它是在服务器端还是在客户端有效。至此，运用模型倒让问题变得复杂了，而我们的初衷是要简化问题。
一个更好的解决方案是"分别考虑"。从逻辑上讲，服务器端的 Web 页行为与客户端是完全不同的。在服务器上执行时，页有权访问服务器端资源（中间层构件、数据库、文件系统等），即与这些资源具有某些关系。同一页（或者是该页的 HTML 流输出）在客户端有完全不同的行为和关系集。在客户端，脚本页与浏览器本身（通过文档对象模型，即 DOM），以及该页指定的所有 Java Applet、ActiveX 控件或插件相关。对于认真的设计员而言，页还可能与客户机上在另一个 HTML 框架或浏览器实例出现的其他"活动"页相关。
通过分别考虑，我们就可以用一个类为 Web 页的服务器端建模，用另一个类为客户端建模。我们采用 UML 扩展机制为两者分别定义构造型和图标?quot;server page" 和 "client page"，以此来区分两者。UML 中的构造型允许我们为建模元素定义新的语义。已指定构造型的类在 UML 图中可用定制图标表示，或者仅仅用 ("") 之间的构造型名称说明。图标对概述图很有用，在概述图中，最好使用简单的标记对显示出的类属性和操作进行标注。
对于 Web 页，构造型指出了类是客户机或服务器上 Web 页逻辑行为的抽象。两种抽象通过两者之间的定向关系相互关联关系。这种关联关系的构造型为："build"，因为可以说服务器页构建了客户机页（图 1）。每个动态 Web 页（即页内容在运行时才能决定的页）都用一个服务器页构建。每个客户机页至多只能用一个服务器页构建，而一个服务器页可以构建多个客户机页。
文章来源于领测软件测试网 https://www.ltesting.net/
