既然所有這些機制都對系統的業務邏輯有促進作用，因此同樣也需要為它們建模。而且，由于它們只表示部分業務邏輯，它們需要與其余的系統模型集成。在很多情況下，大部分業務邏輯在 Web 服務器后、服務器端的某一層執行。建模語言和表示法的選擇通常要按照這一端的應用程序的需要來決定。隨著 UML 作為一種正式的對象建模語言被 OMG 所接受，越來越多的系統開始用 UML 表示。許多人選擇 UML 作為軟件密集型系統的建模語言。于是 Web 應用程序建模的主要問題變成了：“如何在應用程序的其余部分表示在特定 Web 構件中執行的業務邏輯？”答案取決于我們用 UML 在那些特定的 Web 元素和技術中表示系統業務邏輯執行的能力。
本文旨在簡要介紹 Web 應用程序建模存在的問題和可能的解決方案。其中著重講述在構架上對 Web 應用程序有重要意義的構件，以及如何使用 UML 對它們進行建模。本文假定讀者熟悉 UML、面向對象技術的原理和 Web 應用程序開發。文中描述的工作基于一些無偏向性的假設。
Web 應用程序是日益復雜的軟件密集型系統，它們在關鍵的任務中發揮著越來越重大的作用。
管理軟件系統復雜性的一種方法是對它們進行抽象和建模。
軟件系統一般有多個模型，每一個模型代表一個不同的觀點、不同的抽象和詳細級別。
哪個抽象和詳細級別是合適的，這取決于開發流程中的工件和角色活動。
軟件密集型系統的標準建模語言是統一建模語言 (UML)。
本文介紹的概念和思想在今年年底即將由 Addison Wesley Longman 出版的“Object Technology Series”中的“Building Web Applications with UML”一書中有更為充分的論述。
建模
通過簡化一些細節，模型可以幫助我們理解系統。如何選擇建模對象對理解問題和提供解決方案有重大影響。Web 應用程序與其他軟件密集型系統一樣，通常由用例模型、實施模型、部署模型、安全模型等一組模型來表示。Web 系統還另有一個專用模型，即站點圖。站點圖是對貫穿整個系統的 Web 頁和導航路線的抽象。
目前采用的大部分建模方法都適用于各種 Web 應用程序模型的開發，因而無需對它們進行進一步的討論。不過，有一個非常重要的模型，分析/設計模型 (ADM)，在嘗試將 Web 頁、與其相關的可執行代碼和其他元素納入模型時，確實出現了一些困難。
在決定如何建模時，確定正確的抽象和詳細級別對于是否能讓模型用戶享受到建模帶來的好處至關重要。一般而言，最好對系統的工件建模。工件就是那些為生成最終產品而構建和操縱的真實生活中的實體。對 Web 服務器的內部構件建模，或者對 Web 瀏覽器的具體構成部分建模，這對于 Web 應用程序的設計員和構架設計師并沒有什么幫助。頁、頁之間的鏈接、構成頁的所有動態內容，以及在客戶機上出現過的頁的動態內容，對這些建模才是重要的，而且是非常重要的。設計員設計的、實施員實施的正是這些工件。頁、超鏈接、客戶機和服務器上的動態內容正是需要建模的對象。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
