1、基于ROSE的Web Service建模作者：曹偉    本文選自：51CMM  2003年01月09日此部分根據RUP的資料進行整理，作者將此部分為序言，逐步分析以UML建模實現Web Service架構，以下的將采用以WebLogic提供服務，基于Java實現為例說明。此部分作者直接引用資料或相關圖片知識產權屬于RUP提供商。近年來，IT詞匯表中出現了一條新的術語，它就是“Web應用程序”。參與業務軟件系統的所有人似乎都有構建Web應用程序的計劃，而在與業務不相關的軟件方面也有很多人對此感興趣。對于很早前就采用這種構架的許多人來說，Web

2、應用程序這個詞象系統本身一樣，已經從成功的小型 Web 站點插件發展成了強壯的n層應用程序。Web應用程序可以同時為分布在世界各地的、成千上萬的用戶提供服務，這種情況早已司空見慣。構建Web應用程序是一件嚴肅的事情。在實際應用中，Web應用程序這個詞對不同的人而言含義略有不同。一些人認為凡是用到 Java 的都是 Web 應用程序，而另一些人則認為凡是使用Web服務器的都是Web應用程序。多數人的意見介于這兩者之間。站在本文的角度，我們將Web應用程序大體定義為Web系統（Web服務器、網絡、HTTP、瀏覽器），在這個系統中，用戶的輸入（導航和數據輸入）會影響到業務狀態。該定義試圖將Web應用

3、程序確立為一個具有業務狀態的軟件系統，并且它的“前端”基本上是通過Web系統傳遞的。Web應用程序的總體構架是一個客戶機服務器系統，但二者有幾點顯著的區別。Web應用程序最重要的優點之一在于它的部署。部署Web應用程序通常指的是建立網絡的服務器端構件。客戶端不需要特別的軟件或配置。兩者的另一個重大差異在于客戶機和服務器通信的本質。Web應用程序的基本通信協議是HTTP，這是一個無連接協議，它不是為最大的通信吞吐量設計的，而是為強壯性和容錯而設計的。在Web應用程序中，客戶機和服務器的通信通常圍繞Web頁導航進行，而不是在服務器端和客戶端對象之間直接通信。在一定的抽象程度上，Web應用程序中所有

4、的信息傳遞都可描述為Web頁實體的請求和接收。通常所說的Web應用程序構架與動態Web站點的構架并無太大區別。Web應用程序與Web站點，甚至是與動態Web站點的區別都要涉及到使用。Web應用程序實現的是業務邏輯，它的使用改變了業務的狀態（其狀態為系統捕獲）。這是很重要的，因為它確定了建模工作的重點。Web 應用程序執行業務邏輯，因此大多數重要的系統模型都側重于業務邏輯和業務狀態，而不是表示細節。表示很重要（否則系統將毫無用處），不過應盡量將業務和表示所關注的問題區分開。如果表示問題是重要的，甚至是復雜的，那么也需要對它們建模，但不必將它們作為業務邏輯模型的構成部分。此外，用于表示的資源更注重

5、外觀設計，而與實施業務規則關系不大。關系管理方法(RMM)是與Web系統開發有關的一種方法/表示法。RMM是一種用于設計、構建和維護Intranet 及Internet Web 系統的方法。它的根本目標是降低動態數據庫驅動的Web站點的維護成本。它提倡系統進行形象化表示，以便展開設計上的討論。它是一個迭代式過程，包括Web頁可視元素的分解，及這些元素與數據庫實體的關聯關系。RMM 是一種用于動態 Web 站點創建和維護的“完整詳盡”的方案。不過，在構建Web應用程序方面RMM就顯得無能為力了。Web應用程序以業務邏輯為中心，它包括了許多實施業務邏輯的技術機制，而這些內容在RMM表示法中并未充分

6、說明。客戶端腳本編寫、Applet 和 ActiveX 控件等技術為促進系統業務規則的執行發揮了重大作用。另外，Web應用程序還可用作分布式對象系統的交付機制。Applet 和 ActiveX 控件可以包含那些獨立于Web服務器，通過 RMI 或者 DCOM 與服務器端構件異步交互的構件。復雜應用程序還可利用多個瀏覽器實例和客戶機上的框架，建立并維護自己的通信機制。既然所有這些機制都對系統的業務邏輯有促進作用，因此同樣也需要為它們建模。而且，由于它們只表示部分業務邏輯，它們需要與其余的系統模型集成。在很多情況下，大部分業務邏輯在Web服務器后、服務器端的某一層執行。建模語言和表示法的選擇通常要

7、按照這一端的應用程序的需要來決定。隨著 UML 作為一種正式的對象建模語言被 OMG 所接受，越來越多的系統開始用 UML 表示。許多人選擇 UML 作為軟件密集型系統的建模語言。于是 Web 應用程序建模的主要問題變成了：“如何在應用程序的其余部分表示在特定Web構件中執行的業務邏輯？”答案取決于我們用UML在那些特定的Web元素和技術中表示系統業務邏輯執行的能力。本文旨在簡要介紹Web應用程序建模存在的問題和可能的解決方案。其中著重講述在構架上對 Web 應用程序有重要意義的構件，以及如何使用 UML 對它們進行建模。本文假定讀者熟悉UML、面向對象技術的原理和 Web 應用程序開發。文中

8、描述的工作基于一些無偏向性的假設。· Web 應用程序是日益復雜的軟件密集型系統，它們在關鍵的任務中發揮著越來越重大的作用。· 管理軟件系統復雜性的一種方法是對它們進行抽象和建模。· 軟件系統一般有多個模型，每一個模型代表一個不同的觀點、不同的抽象和詳細級別。· 哪個抽象和詳細級別是合適的，這取決于開發流程中的工件和角色活動。· 軟件密集型系統的標準建模語言是統一建模語言 (UML)。建模通過簡化一些細節，模型可以幫助我們理解系統。如何選擇建模對象對理解問題和提供解決方案有重大影響。Web 應用程序與其他軟件密集型系統一樣，通常由用例模型、實施

9、模型、部署模型、安全模型等一組模型來表示。Web 系統還另有一個專用模型，即站點圖。站點圖是對貫穿整個系統的 Web 頁和導航路線的抽象。目前采用的大部分建模方法都適用于各種 Web 應用程序模型的開發，因而無需對它們進行進一步的討論。不過，有一個非常重要的模型，分析/設計模型 (ADM)，在嘗試將 Web 頁、與其相關的可執行代碼和其他元素納入模型時，確實出現了一些困難。在決定如何建模時，確定正確的抽象和詳細級別對于是否能讓模型用戶享受到建模帶來的好處至關重要。一般而言，最好對系統的工件建模。工件就是那些為生成最終產品而構建和操縱的真實生活中的實體。對 Web 服務器的內部構件建模，或者對

10、Web 瀏覽器的具體構成部分建模，這對于 Web 應用程序的設計員和構架設計師并沒有什么幫助。頁、頁之間的鏈接、構成頁的所有動態內容，以及在客戶機上出現過的頁的動態內容，對這些建模才是重要的，而且是非常重要的。設計員設計的、實施員實施的正是這些工件。頁、超鏈接、客戶機和服務器上的動態內容正是需要建模的對象。下一步是將這些工件映射到建模元素。例如，超鏈接自然映射到模型中的關聯關系元素。超鏈接代表了從某一頁到另一頁的導航路徑。將這種思路進行擴展，頁就可以映射到模型邏輯視圖中的類。如果 Web 頁是模型的一個類，那么頁的腳本自然就映射為這個類的操作。腳本中的所有頁范圍 (內的) 變量映射為類屬性。W

11、eb 頁可能包括一套在服務器上執行的腳本（準備頁的動態內容），以及另一套完全不同的只在客戶機上執行的腳本（如 JavaScript），考慮到這一點時，一個問題就出現了。在這種情況下，當我們查看模型中的 Web 頁類時，我們搞不清楚在準備頁的過程中哪些操作、屬性甚至關系在服務器上處于活動狀態，而當用戶與頁交互時哪些在客戶機上處于活動狀態。另外，Web 應用程序中傳遞的 Web 頁最好是作為系統構件建模。簡單地將 Web 頁映射到 UML 類不會對我們理解系統有所幫助。UML 的創始人意識到總會存在這樣的情況：初始的 UML 不足以獲取一個特定領域或構架的相關語義。為了解決這個問題，他們確定了一種

12、正式擴展機制，允許實踐者擴展 UML 的語義。該機制允許定義可應用到模型元素的構造型、標注值和約束。構造型是一種修飾，允許我們為建模元素定義新的語義。標注值是可以與建模元素相關聯的鍵值對，允許我們在建模元素?quot;標注"任何值。約束是定義模型外形的規則。它們可表示為任何形式的文本，或者用更正式的對象約束語言 (OCL) 表示。本文討論的工作引入了為 Web 應用程序所作的一種 UML 擴展。這種擴展從整體上看超出了本文的范圍，然而這里還是討論了其中大部分的概念和解釋。關于建模最后還要注意一點，一定要明確區分業務邏輯和表示邏輯。對于典型的業務應用程序而言，只有業務邏輯才應成為 AD

13、M 的一部分。表示細節，如動畫按鈕、浮動幫助和其他 UI 增強方式通常不屬于 ADM。如果為應用程序單獨構建一個 UI 模型，則可在其中納入表示細節。ADM 需要始終將重點放在業務問題和解決方案的表達上。在今天這個 Web 設計師的時代，對 Web 頁外觀的設計和實現最好由專業人員（技術繪圖師）取代傳統的開發人員來完成。Web 應用程序構架Web 應用程序的基本構架包括瀏覽器、一個網絡和一個 Web 服務器。瀏覽器向服務器請求"Web 頁"。每一頁都是內容和以 HTML 表達的格式指令的組合。一些頁包括客戶端腳本，它們由瀏覽器解釋。這些腳本為顯示的頁定義了其他動態行為，而且

14、它們經常與瀏覽器、頁內容和頁中包含的其他控件（Applet、ActiveX 控件和插件）交互。用戶查看頁中的內容，并與其交互。有時，用戶在頁的字段元素中輸入信息，并提交給服務器處理。用戶還可以通過超鏈接導航到系統的其他頁，與系統進行交互。無論是哪種情況，用戶都在向系統提供輸入，這樣就可能改變系統?quot;業務狀態"。從客戶端來看，Web 頁總是一個采用 HTML 格式的文檔。然而在服務器端，"Web 頁"可表現為多種形式。在最早的 Web 應用程序中，動態 Web 頁用公共網關接口 (CGI) 構建。CGI 定義了一個供腳本和已編譯模塊使用的接口，它們通過該接口

15、訪問與頁請求一起傳遞的信息。在基于 CGI 的系統中，通常在 Web 服務器上配置一個特殊的目錄，以便針對頁請求來執行腳本。在請求 CGI 腳本時，服務器會用解譯器（通常是一個 PERL shell）處理或執行相應的文件，以流的形式將輸出返回給發出請求的客戶機，而不僅僅是返回文件內容（就像處理 HTML 格式的文件時一樣）。處理的最終結果是 HTML 格式的流，它會被返回給發出請求的客戶機。業務邏輯在處理文件的同時在系統中執行。在這段時間內，它能夠與服務器端資源（如數據庫和中間層構件）交互。目前的 Web 服務器已經在這個基本設計上有所改進。它們現在已非常注重安全性，而且包含了一些特性：如在服

16、務器端的客戶機狀態管理、事務處理集成、遠程管理、資源共享等，這里只列舉了其中的幾種。總的來說，最新一代 Web 服務器處理的都是那些對構架設計師來說非常重要的問題，它們關系到任務至上、可縮放和強壯的應用程序。根據 CGI 腳本的作用，可以將現今的 Web 服務器分為三大類：腳本頁、編譯頁，以及兩者的混合體。在第一類中，客戶機瀏覽器能請求的每一個 Web 頁在 Web 服務器的文件系統中都用一個腳本文件來表示。這個文件一般是 HTML 和其他一些腳本語言的混合。對頁發出請求后，Web 服務器委派一個可識別該頁的引擎對其進行處理，最終結果以格式為 HTML 的流的形式返回給發出請求的客戶機。Mic

17、rosoft 的 Active Server Pages、Java Server Pages 和 Cold Fusion 都屬于這一類。在第二類中，Web 服務器加載并執行一個二進制構件。這個構件和腳本頁一樣，有權訪問與頁請求一起發送的所有信息（表單字段值和參數）。經過編譯的代碼利用請求的詳細信息，并通常要訪問服務器端的資源，以生成 HTML 流并返回給客戶機。編譯頁包含的功能往往比腳本頁大，盡管并未明確這一規律。通過向編譯頁請求傳遞不同的參數，可獲得不同的功能。任何一個編譯構件實際都可以包含整個目錄腳本頁的所有功能。Microsoft 的 ISAPI 和 Netscape 的 NSAPI 就

18、是表示這種構架類型的技術。第三類指的是那些一旦發出請求即進行編譯的腳本頁，以后的所有請求都使用編譯過的頁。Web 頁建模Web 頁，不管是腳本頁還是編譯頁，都一對一地映射到 UML 中的構件。構件是系統的"物理"可更換部件。模型的實施視圖（構件視圖）描述了系統的構件及它們之間的關系。在 Web 應用程序中，這個視圖描述了系統的所有 Web 頁及它們彼此之間的關系（如超鏈接）。在一定程度上，Web 系統的構件圖就相當于站點圖。由于構件僅僅代表了接口的物理打包方式，它們并不適用于對頁內部的協作關系建模。這一抽象級別仍需要成為模型的組成部分，而且對設計員和實施員而言極其重要。為引

19、入正題，我們可以說每個Web 頁在模型的設計視圖（邏輯視圖）中都是一個UML類，它與其他頁的關系（關聯關系）即代表了超鏈接。但如果考慮到任何 Web頁都可能既代表一組只存在于服務器上的功能和協作，同時又代表只存在于客戶機上的一組完全不同的功能和協作，那么這種抽象就不成立了。舉例來說，使用動態HTML（客戶端腳本）作為部分輸出的所有服務器 Web腳本頁都是這樣的頁。對這個問題的直接反應可能就是為類中的每個屬性或操作設計原型，指明它是在服務器端還是在客戶端有效。至此，運用模型倒讓問題變得復雜了，而我們的初衷是要簡化問題。一個更好的解決方案是"分別考慮"。從邏輯上講，服務器端的

20、Web 頁行為與客戶端是完全不同的。在服務器上執行時，頁有權訪問服務器端資源（中間層構件、數據庫、文件系統等），即與這些資源具有某些關系。同一頁（或者是該頁的 HTML 流輸出）在客戶端有完全不同的行為和關系集。在客戶端，腳本頁與瀏覽器本身（通過文檔對象模型，即 DOM），以及該頁指定的所有 Java Applet、ActiveX 控件或插件相關。對于認真的設計員而言，頁還可能與客戶機上在另一個 HTML 框架或瀏覽器實例出現的其他“活動”頁相關。通過分別考慮，我們就可以用一個類為 Web 頁的服務器端建模，用另一個類為客戶端建模。我們采用 UML 擴展機制為兩者分別定義構造型和圖標“serv

21、er page” 和“client page”，以此來區分兩者。UML 中的構造型允許我們為建模元素定義新的語義。已指定構造型的類在 UML 圖中可用定制圖標表示，或者僅僅用 ("")之間的構造型名稱說明。圖標對概述圖很有用，在概述圖中，最好使用簡單的標記對顯示出的類屬性和操作進行標注。對于 Web 頁，構造型指出了類是客戶機或服務器上 Web 頁邏輯行為的抽象。兩種抽象通過兩者之間的定向關系相互關聯關系。這種關聯關系的構造型為："build"，因為可以說服務器頁構建了客戶機頁（圖 1）。每個動態 Web 頁（即頁內容在運行時才能決定的頁）都用一個服務器

22、頁構建。每個客戶機頁至多只能用一個服務器頁構建，而一個服務器頁可以構建多個客戶機頁。圖 1. 服務器頁構建客戶機頁Web頁之間通過超鏈接建立公共關系。Web應用程序中的超鏈接代表系統的一條導航路徑。這種關系在模型中用一個構造型為“link”的關聯關系表示。關聯關系總是從客戶機頁出發，指向另一個客戶機頁或服務器頁。超鏈接作為 Web 頁請求在系統中實施，Web 頁作為實施視圖中的構件來建模。指向客戶機頁的鏈接關聯關系大體等同于指向構建該客戶機頁的服務器頁的鏈接關聯關系。這是因為鏈接實際是一個頁請求，不是上述兩種類抽象。由于 Web 頁構件同時實現兩種頁抽象，因此指向由該頁構件實現的任何類的鏈接都

23、是等同的。標注值用于定義隨鏈接請求一起傳遞的參數。“link”關聯關系標注值“Parameters”是一個參數名（和可選值）的列表，處理請求的服務器頁要用到它。在圖 2 中，SearchResults 頁包含數目可變的指向 GetProduct 服務器頁的超鏈接 (0.*),每一個鏈接都有一個不同的 productId 參數值。GetProduct 頁用于構建 productId 參數所指定產品的 ProductDetail 頁。圖2. 使用超鏈接參數使用這些構造型簡化了對頁腳本和關系的建模。"server page" 類的操作變為頁服務器端腳本的函數，它的屬性變為頁范圍變

24、量（頁函數可對其進行全局訪問）。"client page" 類的操作和屬性也同樣變為在客戶機上可見的函數和變量。將服務器端頁和客戶端頁作為不同的類考慮，其最大好處在于明確頁與系統的其他類之間的關系。客戶機頁根據它們與客戶端資源的關系進行建模。客戶端資源有：DOM、Java Applet、 ActiveX 控件和插件（圖 3）。服務器頁根據它們與服務器端資源的關系進行建模。服務器端資源有：中間層構件、數據庫存取構件、服務器操作系統等(圖 4)。圖 3. 客戶機協作圖 4. 服務器協作用類構造型對 Web 頁的邏輯行為建模的最大優勢在于：頁與服務器端構件的協作可以基本上用其他任

25、意服務器端協作所使用的方式來表示。"server page" 僅僅是參與系統業務邏輯的另一個類。上升到概念的層次來講，服務器頁一般扮演控制者的角色，協調必要的業務對象活動，以滿足瀏覽器頁請求所提出的業務目標。客戶端的協作更復雜一些。部分原因可歸咎于可用技術的多樣性。即使是最簡單的客戶機頁，至少也是一個既包含內容又包含表示信息的 HTML 文檔。瀏覽器利用頁的格式指令提供 HTML 頁，有時還帶有單獨的樣式表。在邏輯模型中，這一關系可用客戶機頁對構造型為 "Style Sheet" 的類的依賴關系來表示。樣式表基本上是一個表示問題，通常不包含在 ADM 內

26、。表單Web 頁的基本數據輸入機制是表單。表單在 HTML 文檔中用 窗體頂端標記來定義。每個表單都會指明它自身要提交到哪一頁。表單包括許多輸入元素，它們全用 HTML 標記表示。最常用的標記是 <input>、<select> 和 <textarea> 。輸入標記多種多樣，它可以是一個文本字段、復選框、單選按鈕、按鈕、圖像、隱藏字段，還有其他一些不太常見的類型。對表單建模要使用另一個類構造型：“Form”。“Form”沒有操作，這是因為可能在 <form> 標記中定義的所有操作實際上都為客戶機頁所有。表單的輸入元素都是“Form”類的建有構造型的屬性。“Form”可以與作為輸入控件的 Applet 或者 ActiveX 控件有關系。表單還與服務器頁有關系，服務器頁即是處理表單提交內容的頁。這種關系的構造型為“submit”。由于表單完全包含在 HTML 文檔內，所以它們在 UML 圖中用一種強聚合關系形式表示。圖 5 是一個簡單的購物車