UML 的创始人意识到总会存在这样的情况：初始的 UML 不足以获取一个特定领域或构架的相关语义。为了解决这个问题，他们确定了一种正式扩展机制，允许实践者扩展 UML 的语义。该机制允许定义可应用到模型元素的构造型、标注值和约束。
构造型是一种修饰，允许我们为建模元素定义新的语义。标注值是可以与建模元素相关联的键值对，允许我们在建模元素上“标注”任何值。约束是定义模型外形的规则。它们可表示为任何形式的文本，或者用更正式的对象约束语言 (OCL) 表示。
本文讨论的工作引入了为 Web 应用程序所作的一种 UML 扩展。这种扩展从整体上看超出了本文的范围，然而这里还是讨论了其中大部分的概念和解释。
关于建模最后还要注意一点，一定要明确区分业务逻辑和表示逻辑。对于典型的业务应用程序而言，只有业务逻辑才应成为 ADM 的一部分。表示细节，如动画按钮、浮动帮助和其他 UI 增强方式通常不属于 ADM。如果为应用程序单独构建一个 UI 模型，则可在其中纳入表示细节。ADM 需要始终将重点放在业务问题和解决方案的表达上。在今天这个 Web 设计师的时代，对 Web 页外观的设计和实现最好由专业人员（技术绘图师）取代传统的开发人员来完成。
Web 应用程序构架
Web 应用程序的基本构架包括浏览器、一个网络和一个 Web 服务器。浏览器向服务器请求“Web 页”。每一页都是内容和以 HTML 表达的格式指令的组合。一些页包括客户端脚本，它们由浏览器解释。这些脚本为显示的页定义了其他动态行为，而且它们经常与浏览器、页内容和页中包含的其他控件（Applet、ActiveX 控件和插件）交互。用户查看页中的内容，并与其交互。有时，用户在页的字段元素中输入信息，并提交给服务器处理。用户还可以通过超链接导航到系统的其他页，与系统进行交互。无论是哪种情况，用户都在向系统提供输入，这样就可能改变系统的“业务状态”。
从客户端来看，Web 页总是一个采用 HTML 格式的文档。然而在服务器端，“Web 页”可表现为多种形式。在最早的 Web 应用程序中，动态 Web 页用公共网关接口 (CGI) 构建。CGI 定义了一个供脚本和已编译模块使用的接口，它们通过该接口访问与页请求一起传递的信息。在基于 CGI 的系统中，通常在 Web 服务器上配置一个特殊的目录，以便针对页请求来执行脚本。在请求 CGI 脚本时，服务器会用解译器（通常是一个 PERL shell）处理或执行相应的文件，以流的形式将输出返回给发出请求的客户机，而不仅仅是返回文件内容（就像处理 HTML 格式的文件时一样）。处理的最终结果是 HTML 格式的流，它会被返回给发出请求的客户机。业务逻辑在处理文件的同时在系统中执行。在这段时间内，它能够与服务器端资源（如数据库和中间层构件）交互。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
