基于rose的web service建模

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

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

3、程序確立為一個具有業(yè)務(wù)狀態(tài)的軟件系統(tǒng)，并且它的“前端”基本上是通過Web系統(tǒng)傳遞的。Web應(yīng)用程序的總體構(gòu)架是一個客戶機(jī)服務(wù)器系統(tǒng)，但二者有幾點顯著的區(qū)別。Web應(yīng)用程序最重要的優(yōu)點之一在于它的部署。部署Web應(yīng)用程序通常指的是建立網(wǎng)絡(luò)的服務(wù)器端構(gòu)件?？蛻舳瞬恍枰貏e的軟件或配置。兩者的另一個重大差異在于客戶機(jī)和服務(wù)器通信的本質(zhì)。Web應(yīng)用程序的基本通信協(xié)議是HTTP，這是一個無連接協(xié)議，它不是為最大的通信吞吐量設(shè)計的，而是為強(qiáng)壯性和容錯而設(shè)計的。在Web應(yīng)用程序中，客戶機(jī)和服務(wù)器的通信通常圍繞Web頁導(dǎo)航進(jìn)行，而不是在服務(wù)器端和客戶端對象之間直接通信。在一定的抽象程度上，Web應(yīng)用程序中所有

4、的信息傳遞都可描述為Web頁實體的請求和接收。通常所說的Web應(yīng)用程序構(gòu)架與動態(tài)Web站點的構(gòu)架并無太大區(qū)別。Web應(yīng)用程序與Web站點，甚至是與動態(tài)Web站點的區(qū)別都要涉及到使用。Web應(yīng)用程序?qū)崿F(xiàn)的是業(yè)務(wù)邏輯，它的使用改變了業(yè)務(wù)的狀態(tài)（其狀態(tài)為系統(tǒng)捕獲）。這是很重要的，因為它確定了建模工作的重點。Web 應(yīng)用程序執(zhí)行業(yè)務(wù)邏輯，因此大多數(shù)重要的系統(tǒng)模型都側(cè)重于業(yè)務(wù)邏輯和業(yè)務(wù)狀態(tài)，而不是表示細(xì)節(jié)。表示很重要（否則系統(tǒng)將毫無用處），不過應(yīng)盡量將業(yè)務(wù)和表示所關(guān)注的問題區(qū)分開。如果表示問題是重要的，甚至是復(fù)雜的，那么也需要對它們建模，但不必將它們作為業(yè)務(wù)邏輯模型的構(gòu)成部分。此外，用于表示的資源更注重

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

21、er page” 和“client page”，以此來區(qū)分兩者。UML 中的構(gòu)造型允許我們?yōu)榻Ｔ囟x新的語義。已指定構(gòu)造型的類在 UML 圖中可用定制圖標(biāo)表示，或者僅僅用 ("")之間的構(gòu)造型名稱說明。圖標(biāo)對概述圖很有用，在概述圖中，最好使用簡單的標(biāo)記對顯示出的類屬性和操作進(jìn)行標(biāo)注。對于 Web 頁，構(gòu)造型指出了類是客戶機(jī)或服務(wù)器上 Web 頁邏輯行為的抽象。兩種抽象通過兩者之間的定向關(guān)系相互關(guān)聯(lián)關(guān)系。這種關(guān)聯(lián)關(guān)系的構(gòu)造型為："build"，因為可以說服務(wù)器頁構(gòu)建了客戶機(jī)頁（圖 1）。每個動態(tài) Web 頁（即頁內(nèi)容在運行時才能決定的頁）都用一個服務(wù)器

22、頁構(gòu)建。每個客戶機(jī)頁至多只能用一個服務(wù)器頁構(gòu)建，而一個服務(wù)器頁可以構(gòu)建多個客戶機(jī)頁。圖 1. 服務(wù)器頁構(gòu)建客戶機(jī)頁Web頁之間通過超鏈接建立公共關(guān)系。Web應(yīng)用程序中的超鏈接代表系統(tǒng)的一條導(dǎo)航路徑。這種關(guān)系在模型中用一個構(gòu)造型為“l(fā)ink”的關(guān)聯(lián)關(guān)系表示。關(guān)聯(lián)關(guān)系總是從客戶機(jī)頁出發(fā)，指向另一個客戶機(jī)頁或服務(wù)器頁。超鏈接作為 Web 頁請求在系統(tǒng)中實施，Web 頁作為實施視圖中的構(gòu)件來建模。指向客戶機(jī)頁的鏈接關(guān)聯(lián)關(guān)系大體等同于指向構(gòu)建該客戶機(jī)頁的服務(wù)器頁的鏈接關(guān)聯(lián)關(guān)系。這是因為鏈接實際是一個頁請求，不是上述兩種類抽象。由于 Web 頁構(gòu)件同時實現(xiàn)兩種頁抽象，因此指向由該頁構(gòu)件實現(xiàn)的任何類的鏈接都

23、是等同的。標(biāo)注值用于定義隨鏈接請求一起傳遞的參數(shù)?！發(fā)ink”關(guān)聯(lián)關(guān)系標(biāo)注值“Parameters”是一個參數(shù)名（和可選值）的列表，處理請求的服務(wù)器頁要用到它。在圖 2 中，SearchResults 頁包含數(shù)目可變的指向 GetProduct 服務(wù)器頁的超鏈接 (0.*),每一個鏈接都有一個不同的 productId 參數(shù)值。GetProduct 頁用于構(gòu)建 productId 參數(shù)所指定產(chǎn)品的 ProductDetail 頁。圖2. 使用超鏈接參數(shù)使用這些構(gòu)造型簡化了對頁腳本和關(guān)系的建模。"server page" 類的操作變?yōu)轫摲?wù)器端腳本的函數(shù)，它的屬性變?yōu)轫摲秶?/p>

24、量（頁函數(shù)可對其進(jìn)行全局訪問）。"client page" 類的操作和屬性也同樣變?yōu)樵诳蛻魴C(jī)上可見的函數(shù)和變量。將服務(wù)器端頁和客戶端頁作為不同的類考慮，其最大好處在于明確頁與系統(tǒng)的其他類之間的關(guān)系。客戶機(jī)頁根據(jù)它們與客戶端資源的關(guān)系進(jìn)行建模?？蛻舳速Y源有：DOM、Java Applet、 ActiveX 控件和插件（圖 3）。服務(wù)器頁根據(jù)它們與服務(wù)器端資源的關(guān)系進(jìn)行建模。服務(wù)器端資源有：中間層構(gòu)件、數(shù)據(jù)庫存取構(gòu)件、服務(wù)器操作系統(tǒng)等(圖 4)。圖 3. 客戶機(jī)協(xié)作圖 4. 服務(wù)器協(xié)作用類構(gòu)造型對 Web 頁的邏輯行為建模的最大優(yōu)勢在于：頁與服務(wù)器端構(gòu)件的協(xié)作可以基本上用其他任

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

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