一、概述

　　web網(wǎng)站往往具有復雜與高度動態(tài)的特點。為了讓web應用在短時間之內開始運作，開發(fā)周期應該盡量地短。許多時候，開發(fā)者直接進入編寫代碼這一階段，卻不去仔細考慮自己想要構造的是什么樣的網(wǎng)站以及準備如何構造：服務器端代碼往往是毫無準備的即興式編寫，數(shù)據(jù)庫表也是隨需隨加，整個應用的體系有時候呈現(xiàn)一種無規(guī)劃狀態(tài)。然而，只要我們運用一些建模技術和軟件工程技術，就能夠讓開發(fā)過程更加流暢，確保web應用將來更容易維護。

　　uml（unified modeling language，統(tǒng)一建模語言）是一種通用的可視化建模語言，用于對軟件進行描述、可視化處理、構造和建立軟件系統(tǒng)的文檔。uml適用于各種軟件開發(fā)方法、軟件生命周期的各個階段、各種應用領域以及各種開發(fā)工具。uml能夠描述系統(tǒng)的靜態(tài)結構和動態(tài)行為：靜態(tài)結構定義了系統(tǒng)中重要對象的屬性和操作以及這些對象之間的相互關系；動態(tài)行為定義了對象的時間特性和對象為完成目標任務而相互進行通信的機制。uml不是一種程序設計語言，但我們可以用代碼生成器將uml模型轉換為多種程序設計語言代碼，或使用反向生成器工具將程序源代碼轉換為uml模型。

　　本文介紹用uml為web網(wǎng)站建模的一些方法。全面采用uml技術是一個復雜的過程，但uml的某些部分很容易使用，而且它能夠幫助你用更少的時間構造出更好的系統(tǒng)。

　　為了示范uml在網(wǎng)站建設中的應用，本文將構造一個支持無線用戶、提供各個地區(qū)天氣報表和交通流量報表的網(wǎng)站。本文不準備詳細介紹uml本身。但為了方便起見，附錄中簡要介紹了常見的uml符號和術語。要了解更多有關uml的信息，請參見文章最后的參考資源。

　　二、規(guī)劃階段

　　不論你是從頭開始構造網(wǎng)站、移植網(wǎng)站還是增加某個重要的功能，為了確保設計決策的最優(yōu)化，進行一些先期規(guī)劃是必要的。如果你和其他人協(xié)作完成一項工程，就工作總量及其分配達成明確的共識具有不可估量的作用。在規(guī)劃期間，你應該努力對系統(tǒng)的以下方面形成正確的認識：

用戶和角色。
應用需求。
各個界面之間的轉換流程。
[li]要用到的工具和技術。 [/li]

　　2.1 用戶

　　了解使用系統(tǒng)的用戶是很重要的。不僅系統(tǒng)分析要求你接觸一些用戶（通過問卷調查、email，或者面對面交談），而且你經常還要讓系統(tǒng)能夠控制不同的用戶角色和權限。通過對用戶進行分類并了解他們的需求，你就可以找出線索來確定數(shù)據(jù)庫的安全機制、功能限制方法、用戶界面分組、培訓和幫助需求、對具體內容的需求，甚至還可以從側面了解到潛在廣告客戶的分布。

圖1：參與者/角色 層次圖

　　上圖顯示了幾組不同的網(wǎng)站用戶（在uml中稱為actor，即參與者）。在這里，最普通的用戶類型（“site user”）位于圖的頂端，實線箭頭表示generalization關系（“泛化”關系，參見本文附錄說明，下同），它表示site user又可以具體分成兩類用戶：guest，registered user。這兩類用戶共有的特征在“site user”參與者中說明，而guest和registered user各自私有的特征則在對應的參與者中說明。通常，你可以直接為參與者加上說明文檔，無需單獨編寫說明用戶的文檔，但具體與你所用的uml工具有關。在本例中，registered user又可以細分為wireless user和administrator兩種類型，系統(tǒng)對這些用戶的處理方式應有所不同。

2.2 定義需求

　　在正式開始編寫代碼之前，你應該對準備構造一個怎樣的系統(tǒng)有一個清晰的認識。雖然在編寫代碼的同時也可以逐步完成這一工作，而且這種做法也很有吸引力，但借助圖形和文字資料事先集體進行討論效率要高得多。為網(wǎng)站編寫詳細的需求說明往往不那么合算，但你應該有時間畫出幾個草圖、寫下幾段注解去說明網(wǎng)站準備提供的服務。這就要用到use case圖（用例圖）。use case可以看成一組功能——它可能對應網(wǎng)站上的一個頁面、一個必須編寫的程序，或者網(wǎng)站上可能發(fā)生的一個動作（比如，驗證用戶登錄，改變用戶的配置文件，清除過期的帳號，等等）。下面就是一個能夠幫助你規(guī)劃網(wǎng)站的use case圖。注意，該圖并沒有顯示出網(wǎng)站的所有use case，通常我們需要多個use case圖才能描述完整的網(wǎng)站功能。

圖2：use case圖

　　即使是在這樣一個簡單的use case圖中，我們也能夠輕松地表達出大量的信息。例如，include關系說明兩個use case包含同樣的身份驗證功能；extend關系說明天氣頁面可能以wml或者html格式顯示；generalization關系說明各個具體的表現(xiàn)過程將遵從“render html page”或者“render wml page”所描述的基本行為規(guī)則以達到維持統(tǒng)一的風格效果和統(tǒng)一宏觀行為模式的目的。

　　上圖也顯示出無線用戶能夠訪問網(wǎng)站中其他用戶不能訪問的某些區(qū)域。在這個use case圖中，只有無線用戶能夠訪問交通流量報表。這是因為我們已經得知只有在旅途中的移動用戶才需要交通流量報表，而且不想再花時間把交通流量報表制作成其他標記語言形式。由此，“get traffic report”use case不需要分成wml和html兩種顯示形式，它可以直接包含“render wml traffic report”這個use case。

　　一般地，你應該為這些use case加上簡單的說明。具體地說，你應該描述每一個use case里將要發(fā)生什么，誰可以使用它，它如何啟動、如何停止，以及某些時候可能發(fā)生的特殊事件（稱為variation，即變化）。

　　2.3 用戶界面組織

　　在制作use case的過程中，你會得到一些指示網(wǎng)站需要哪些用戶界面的線索。也許你早就有了設計某些頁面的絕妙主意，但use case幫助我們從另外一個角度來看問題。用戶是否確實需要那么多的界面？某個頁面是否過于復雜？網(wǎng)站的導航設施是否簡單易用，即從主頁訪問常用服務是否很方便？在勾畫界面草圖、制作網(wǎng)站原型之前，你應該先在use case圖中解決這些問題。

　　當use case逐漸清晰時，我們就可以開始勾畫出網(wǎng)站的大致結構。有些人會強調說頁面和文件應該用相應的構件圖（component diagram）建模，其實類圖（class diagram）工具也很方便。請參見下圖：

圖3：用戶界面及其布局

　　在上圖中，各種網(wǎng)站服務被捆綁到了不同的網(wǎng)站區(qū)域：

/ - 網(wǎng)站的根
/common/ - 公用的圖形、腳本、css文件等
/maps/ - 地圖數(shù)據(jù)
/traffic/ - 交通流量報表
[li]/weather/ - 天氣報表 [/li]

　　該圖還顯示了在頁面之間傳遞的參數(shù)。regionid是一個很重要的參數(shù)，它代表著用戶感興趣的地區(qū)（可能是一個國家、城市或者省份）。regionid在頁面之間傳遞地區(qū)信息，使得用戶能夠從指定地區(qū)的天氣報表跳轉到交通流量信息。至于網(wǎng)站的common區(qū)域，你可以看到指針指向的是整個包（package）而不是區(qū)域中的單個文件，這是一種減少混亂的簡化方法，因為所有其它的包都要用到大部分（如果不是全部的話）/common/區(qū)域中的文件。

　　用戶界面布局圖能夠幫助你避免網(wǎng)站混亂，它對于規(guī)劃網(wǎng)站是很有用的。而且，一旦確定了一種有效的網(wǎng)站結構組織方式，它還可以作為一個固定的模式在多個網(wǎng)站上應用。

2.4 工具選擇

　　對于小型網(wǎng)站，選擇工具和技術相當簡單。特別是由于投資的原因，只有少數(shù)幾種工具組合才具有現(xiàn)實意義——apache，mysql或者postgresql，php、perl或jsp/servlet。當前最流行的組合是apache + php + mysql，有許多低價位的web托管服務支持并主要集中在這種工具組合上。而對于規(guī)模較大的網(wǎng)站，在投資應用軟件之前，它必須對各種工具進行更嚴格的評估和測試。下面是一個構件圖的例子，它可以用來說明網(wǎng)站的體系結構。這個圖形雖然簡單，但它已經描述出了當前大多數(shù)網(wǎng)站的體系結構，對于你的網(wǎng)站，重新制作該圖可能也沒有必要，因為再也沒有什么與眾不同的內容值得加入這個圖形了。

圖4：網(wǎng)站體系結構圖

　　討論軟件的整個生命周期已經超出了本文的范圍，但應該指出的是，建立應用原型和界面模型應該在這個時候就開始。務必記下有關網(wǎng)站結構和頁面布局的一些想法，因為最終你會想要為布局（菜單，導航條，頁面整體布局等）編寫一些公用的代碼。另外，如果你正在轉到新的工具和技術，建立原型的工作能夠讓你確保設計的可行性，確信已經就新工具的使用對開發(fā)組成員進行了足夠的培訓。

　　三、設計階段

　　設計階段應該與分析階段交迭。一旦對自己所要構造的系統(tǒng)有了較多的認識，你就應該開始擬定設計思路。先100%地分析系統(tǒng)再進入設計階段是沒有意義的。需求總是不斷地發(fā)展，而設計本身有時也會推動需求的發(fā)展（反之亦然）。所有的開發(fā)者都在進行某種類型的設計——只不過有些開發(fā)者直接以編程代碼的形式進行設計。雖然這也能夠完成任務，但它使得管理復雜工程和在工作組之內分配任務變得非常困難。先花一點時間通過設計圖構造系統(tǒng)模型，以后你將獲得巨大的回報。

　　3.1 為未來而設計

　　許多開發(fā)者花費在代碼調試和改寫上的時間超過了編寫代碼的時間，如果從一個以上網(wǎng)站的建設來看這個問題，情況就尤其嚴重了。好的網(wǎng)站設計能夠以結構、組織方式和代碼重用的形式應用到多個網(wǎng)站上。然而，如果代碼只是匆匆忙忙堆砌而成，從現(xiàn)有代碼長期獲益的機會就減少了。要對網(wǎng)站進行設計規(guī)劃，一種很有效的方法是畫出類圖（class diagram）。下圖顯示了類圖通常要用到的許多重要關系。

圖5：類圖

　　說明如下：

renderer類是一個抽象類（用斜體字顯示）。這意味著renderer類不能直接使用，程序只能創(chuàng)建其子類的實例（即new region()）。為了滿足把頁面內容顯示到不同類型瀏覽器的需要，所有用來生成內容的頁面都必須從renderer類派生。

weatherreport類創(chuàng)建并擁有region對象，這通過代表聚合關系（aggregate relationship）的黑色菱形顯示出來，它表示一個對象擁有并創(chuàng)建其他對象。

方法名字前面的加號（“+”）表示該方法是公用方法，可以被其他對象或者函數(shù)調用；減號（“-”）表示方法或者變量是私有的，只能由同一對象內部的成員函數(shù)訪問。在php中方法和變量是公用的，但我們應該總是把變量看成私有，避免從對象外部直接訪問變量。

htmlweatherreport類依賴于htmlutils類。依賴關系（dependency）表示一個類要創(chuàng)建另一個類的實例或者調用另一個類的方法。

[li]類圖中的每一個類應該注明：所有的方法（以及所有的變量，如有的話），方法的訪問屬性（public，private或者protected），方法的返回值類型，方法的參數(shù)，變量的類型。函數(shù)寫在前面，如果類有變量的話，則一般隨后在一個分開的方框中列出。 [/li]

　　即使你所構造的不是一個面向對象的系統(tǒng)，你仍就可以用類圖建立系統(tǒng)的模型。類能夠方便地描述出各種包含關系和你所編寫的函數(shù)文件。雖然此時類圖不再顯示繼承、構成/聚合等面向對象系統(tǒng)特有的關系，但它可以用依賴關系描述出文件之間的調用關系。

　　3.2 運行時的系統(tǒng)模型

　　有些時候，我們需要顯示出應用的各個部件如何在運行時協(xié)作完成任務。前面的類圖顯示了類之間的關系，但它沒有顯示出調用出現(xiàn)的次序，也沒有顯示出來自一個函數(shù)的結果可能決定下一次調用的目標。為了在更動態(tài)的層面上描述系統(tǒng)，uml提供了許多其他類型的圖。對于web網(wǎng)站設計來說，情節(jié)圖（scenario diagram）特別有用。情節(jié)圖分成兩種：協(xié)作圖（collaboration diagram），序列圖（sequence diagram）。一般地，我們不會建立系統(tǒng)所有交互過程的模型，情節(jié)圖只用來描述系統(tǒng)最復雜的部分，或用來概括出代碼的一般調用模式。例如，我們可能要示范特定的頁面如何與驗證用戶身份的代碼協(xié)作，或者要顯示頁面如何調用公用代碼（工具性的框架代碼）以保持統(tǒng)一的外觀和風格。

　　協(xié)作圖和序列圖分別舉例如下。

圖6：協(xié)作圖

　　上面的協(xié)作圖顯示了從web網(wǎng)站獲取天氣報表的一般過程。注意該圖忽略了一些不重要的方法，因為我們只對處理過程中的關鍵步驟感興趣。你可以根據(jù)編號“1”到“1.3.3.4”找出各個函數(shù)的執(zhí)行次序。一些人喜歡以“1，2，3，……”形式對執(zhí)行步驟編號，但一般而言，用“1，1.1，1.2，2，2.1，……”的形式顯示出調用棧的深度是一種更好的選擇，這種編號方式能夠更清楚地顯示出程序的控制轉換過程。例如，上圖顯示出report()方法調用了wmlutil以及region對象中的許多方法：在通過一系列的查詢和內容生成函數(shù)為指定地區(qū)生成報表之前，我們調用了wmlutil中的buildheader(...)函數(shù)；最后我們調用的是wmlutil模塊的buildfooter(...)，然后返回report()方法，最后返回getpage()。你可以為協(xié)作圖加上更多的細節(jié)說明，比如返回值、約束、條件等。

圖7：序列圖

　　就圖形所傳達的信息而言，次序圖和協(xié)作圖非常相似。事實上，許多uml建模工具能夠從協(xié)作圖生成次序圖，或者相反。次序圖與協(xié)作圖的主要不同之處在于：在次序圖上，事件的發(fā)生次序一目了然，非常直觀。另外，次序圖中還可以加入生存周期和時間方面的詳細信息，比如延遲、線程并發(fā)、對象的構造和刪除等。

　　在決定選用次序圖還是協(xié)作圖的時候，考慮以下幾點有助于你作出最合適的選擇：

如果要顯示代碼中與時間或線程密切相關的問題，選擇次序圖。
如果要顯示對象之間的交互模式，選擇協(xié)作圖。
如果要顯示幾個或者大量對象之間的交互過程，選擇次序圖。
[li]如果要顯示少量對象之間的大量消息傳遞或交互過程，選擇協(xié)作圖。 [/li]

3.3 應用部署的規(guī)劃

　　正如本文前面“工具選擇”部分所提到的，大多數(shù)web網(wǎng)站的體系結構并不復雜。盡管如此，部署圖（deployment diagram）在兩個方面仍舊很有用：網(wǎng)站結構，文件組織。對于文件組織，前面討論界面規(guī)劃時已經提到它也可以用類建模工具進行規(guī)劃。下面給出一個簡單的構件圖供參考，但根據(jù)網(wǎng)站的需要和復雜程度的不同，你可能不需要它。

圖8：構件圖

　　3.4 設計原則

　　uml只是一個工具。如果使用得法，uml能夠幫助我們輕松地構造出更好的網(wǎng)站。然而，要設計出優(yōu)秀的網(wǎng)站，關鍵仍在于要有一個好的設計原則或理念。

　　“提高類的內聚力，減少不同類之間的聯(lián)系”這一點在談到好的面向對象設計原則時經常被反復引用。一個內聚的類包含那些在目標和作用域上都緊密相關的行為和信息。它意味著你不應該把構造ui的代碼和實現(xiàn)數(shù)學算法的代碼混合到一起，你應該盡力把所有與用戶緊密相關的信息封裝到useraccount類。內聚式設計是一個重要的設計原則，原因有很多：它有助于減少類之間的依賴關系，使得設計更直觀、更容易理解，方便了向其他開發(fā)者介紹整個設計，減少了開發(fā)者同一時刻需要操作的類的數(shù)量，等等。例如，如果你要改變網(wǎng)站的用戶身份驗證機制，只修改單個文件中的一個類無疑要比修改多個文件、多個類更加方便。

　　“減少不同類之間的聯(lián)系”意味著使類或者文件之間的交互減到最少。它不僅使得整個設計容易理解，而且也方便了代碼的維護。請考慮下面這個例子：

圖9：設計實例a

　　除非深入了解了上述各個類的用途，要估計這些類的內聚程度是不可能的。然而，從這些類之間的關系可以看出，這個設計方案已經成功地減少了不同類之間的聯(lián)系。類之間的交互被減到了最少，從而使得系統(tǒng)的行為很容易理解。更重要的是，修改任意一個類時受影響的類數(shù)量都減到了最少（例如，修改d類只直接影響b類）。另外，要訪問d類中的功能，我們無需知道任何有關e、f或g類的情況。作為比較，請考慮下圖：

圖10 設計實例b

　　顯然，在這個設計實例中，類之間的聯(lián)系是相當緊密的。一旦對d1類作了修改，為了檢查這種修改對其他類的影響，我們必須對其他類進行廣泛的測試。

　　只有在實踐中不斷鍛煉才能避免出現(xiàn)過于復雜的設計，但注意以下幾點有助于達到這一目標：

提高類的內聚力。不要把密切相關的功能分散到多個文件和類之中。
采用直觀、有意義的名字。如果其他人不能了解類、函數(shù)或者變量的作用，不管類的結構是多么完美，整個設計仍缺乏直觀性。過多地采用縮寫詞會影響設計的可理解性。
不要害怕改寫代碼。有些時候，在幾個類之間移動一些函數(shù)能夠大大地簡化代碼。
類應該保持緊湊、簡潔。代碼膨脹是類缺乏內聚力的一種征兆。過于龐大的類、模塊或者文件往往缺乏明確的用途和目標。
讓其他人復查你的設計。其他人可能有新的想法，或者為你指出你以為顯而易見但別人卻不能明白的問題。
[li]在早期設計階段不要考慮太多的性能問題。與一個笨拙的、為了昨天所出現(xiàn)的問題而優(yōu)化的設計相比，一個簡潔、經過精心調整的設計更容易進行性能優(yōu)化。注意這并不是建議把性能問題拋到腦后，而是建議把細節(jié)優(yōu)化問題留到工程后期考慮。 [/li]

　　四、uml工具

　　下面是一些值得考慮的uml建模工具：

microsoft visio：visio professional 2000現(xiàn)在開始提供內建的uml支持。如果考慮visio繪圖工具的其他各種用途，這是一個相當有價值的工具。如果你使用2000以前的版本，你可以在這里找到visio stencil and template for uml。
rational rose：這是一個推薦使用的工具，但對于許多小型web工程來說它顯得很昂貴。有了rational rose這樣的工具，改進和維護設計、從模型生成報表、在平行協(xié)作環(huán)境中與他人共同進行建模工作就很方便了。
magicdraw：一個基于java的廉價uml建模工具。
together：與c/c++和java聯(lián)系密切，支持uml建模。
objecteering uml：一個免費的個人uml產品。
[li]system architect：一個很受歡迎的高端uml建模工具，支持雙向工程（round-trip engineering）。 [/li]

　　五、附錄：常用uml符號和參考資源

　　下面這個表格簡要介紹了常用的uml符號和關系。要了解有關uml概念和各種面向對象術語的詳細說明，請參見后面的參考資源。

符號
說明

package
包。用來聚集和組織模型中的一個部分（use case，類，等等）。

actor
參與者。它代表一個用戶或者其他外部的激勵器。

use case
用例。use case描述了系統(tǒng)某一部分的行為。一般地，use case記錄對某個系統(tǒng)功能的需求，而這個功能由對動作或者事件的應答示范。

<> relationship
包含關系。標注為<>關系的use case關系能夠引入其他use case的功能。這是一種方便的分割use case、避免單個use case過于龐大的方法。

<> relationship
擴充關系。標注為<>關系的use case關系能夠在不重復現(xiàn)有use case的各種描述和需求的情況下，使現(xiàn)有use case的行為特殊化。

dependency
依賴。正如其字面意義，它表示一個事物依賴另一個事物。這意味著一個事物了解另一個事物，并需要另外一個事物才能發(fā)揮功能。

note
注解。在uml圖中提供注解的目的是以簡短的說明闡明圖表的內容。

component
構件。構件一般代表一個軟件單元，它可能是一個dll、一個執(zhí)行文件，或者是一個數(shù)據(jù)庫。

node
節(jié)點。節(jié)點一般代表一臺機器，這臺機器具有運行一個或者多個系統(tǒng)構件的能力。

class
類。uml中的類與面向對象編程中的類一樣，即它定義并封裝了一組行為和屬性。類在運行時被實例化從而創(chuàng)建出對象。

object
對象。對象是類的實例。例如，“myclass myobj = new myclass; ”創(chuàng)建了一個myobj對象。

generalization
泛化。父類能夠派生出（或稱為特殊化）具有更多特殊行為的子類，此時父類即為子類的超類（或子類的泛化版本）。

interface
接口。接口定義了一組可以從外部訪問的行為。類、庫、執(zhí)行文件、數(shù)據(jù)文件都可以由接口來描述。接口本身并不實現(xiàn)任何功能，它只是和聲明實現(xiàn)該接口的對象訂立了一個必須實現(xiàn)哪些行為的契約。

abstract class
抽象類。抽象類不能直接實例化，但允許派生出具體的、有實際功能的類。

association
關聯(lián)。關聯(lián)就是把兩個或以上的類連接起來。你可以為兩個類之間的這種關系提供更具體的信息。關聯(lián)是兩個或多個特定類元之間的關系，它描述了這些類元的實例的聯(lián)系。在一個關聯(lián)中同一個類可以出現(xiàn)在多個位置上。

aggregation
聚合。聚合關系表示某個對象屬于其他對象所有。

　　參考資源：

uml 1.3 specification：uml規(guī)范，來自omg.org
uml resource pag

該文章在 2010/7/3 16:17:07 編輯過