Web網站往往具有複雜與高度動態的特點。爲了讓Web應用在短時間之內開始運作，開發週期應該儘量地短。許多時候，開發者直接進入編寫代碼這一階段，卻不去仔細考慮自己想要構造的是什麼樣的網站以及準備如何構造：服務器端代碼往往是毫無準備的即興式編寫，數據庫表也是隨需隨加，整個應用的體系有時候呈現一種無規劃狀態。然而，只要我們運用一些建模技術和軟件工程技術，就能夠讓開發過程更加流暢，確保Web應用將來更容易維護。
UML（Unified Modeling Language，統一建模語言）是一種通用的可視化建模語言，用於對軟件進行描述、可視化處理、構造和建立軟件系統的文檔。UML適用於各種軟件開發方法、軟件生命週期的各個階段、各種應用領域以及各種開發工具。UML能夠描述系統的靜態結構和動態行爲：靜態結構定義了系統中重要對象的屬性和操作以及這些對象之間的相互關係；動態行爲定義了對象的時間特性和對象爲完成目標任務而相互進行通信的機制。UML不是一種程序設計語言，但我們可以用代碼生成器將UML模型轉換爲多種程序設計語言代碼，或使用反向生成器工具將程序源代碼轉換爲UML模型。
本文介紹用UML爲Web網站建模的一些方法。全面採用UML技術是一個複雜的過程，但UML的某些部分很容易使用，而且它能夠幫助你用更少的時間構造出更好的系統。
爲了示範UML在網站建設中的應用，本文將構造一個支持無線用戶、提供各個地區天氣報表和交通流量報表的網站。本文不準備詳細介紹UML本身。但爲了方便起見，附錄中簡要介紹了常見的UML符號和術語。要了解更多有關UML的信息，請參見文章最後的參考資源。
二、規劃階段
不論你是從頭開始構造網站、移植網站還是增加某個重要的功能，爲了確保設計決策的最優化，進行一些先期規劃是必要的。如果你和其他人協作完成一項工程，就工作總量及其分配達成明確的共識具有不可估量的作用。在規劃期間，你應該努力對系統的以下方面形成正確的認識：
用戶和角色。
應用需求。
各個界面之間的轉換流程。
要用到的工具和技術。
2.1 用戶
瞭解使用系統的用戶是很重要的。不僅系統分析要求你接觸一些用戶（通過問卷調查、email，或者面對面交談），而且你經常還要讓系統能夠控制不同的用戶角色和權限。通過對用戶進行分類並瞭解他們的需求，你就可以找出線索來確定數據庫的安全機制、功能限制方法、用戶界面分組、培訓和幫助需求、對具體內容的需求，甚至還可以從側面瞭解到潛在廣告客戶的分佈。
圖1：參與者/角色 層次圖
上圖顯示了幾組不同的網站用戶（在UML中稱爲Actor，即參與者）。在這裏，最普通的用戶類型（“Site User”）位於圖的頂端，實線箭頭表示generalization關係（“泛化”關係，參見本文附錄說明，下同），它表示Site User又可以具體分成兩類用戶：Guest，Registered User。這兩類用戶共有的特徵在“Site User”參與者中說明，而Guest和Registered User各自私有的特徵則在對應的參與者中說明。通常，你可以直接爲參與者加上說明文檔，無需單獨編寫說明用戶的文檔，但具體與你所用的UML工具有關。在本例中，Registered User又可以細分爲Wireless User和Administrator兩種類型，系統對這些用戶的處理方式應有所不同。
2.2 定義需求
在正式開始編寫代碼之前，你應該對準備構造一個怎樣的系統有一個清晰的認識。雖然在編寫代碼的同時也可以逐步完成這一工作，而且這種做法也很有吸引力，但藉助圖形和文字資料事先集體進行討論效率要高得多。爲網站編寫詳細的需求說明往往不那麼合算，但你應該有時間畫出幾個草圖、寫下幾段註解去說明網站準備提供的服務。這就要用到Use Case圖（用例圖）。Use Case可以看成一組功能——它可能對應網站上的一個頁面、一個必須編寫的程序，或者網站上可能發生的一個動作（比如，驗證用戶登錄，改變用戶的配置文件，清除過期的帳號，等等）。下面就是一個能夠幫助你規劃網站的Use Case圖。注意，該圖並沒有顯示出網站的所有Use Case，通常我們需要多個Use Case圖才能描述完整的網站功能。
圖2：Use Case圖
即使是在這樣一個簡單的Use Case圖中，我們也能夠輕鬆地表達出大量的信息。例如，include關係說明兩個Use Case包含同樣的身份驗證功能；extend關係說明天氣頁面可能以WML或者HTML格式顯示；generalization關係說明各個具體的表現過程將遵從“Render HTML Page”或者“Render WML Page”所描述的基本行爲規則以達到維持統一的風格效果和統一宏觀行爲模式的目的。
上圖也顯示出無線用戶能夠訪問網站中其他用戶不能訪問的某些區域。在這個Use Case圖中，只有無線用戶能夠訪問交通流量報表。這是因爲我們已經得知只有在旅途中的移動用戶才需要交通流量報表，而且不想再花時間把交通流量報表製作成其他標記語言形式。由此，“Get Traffic Report”Use Case不需要分成WML和HTML兩種顯示形式，它可以直接包含“Render WML Traffic Report”這個Use Case。
一般地，你應該爲這些Use Case加上簡單的說明。具體地說，你應該描述每一個Use Case裏將要發生什麼，誰可以使用它，它如何啓動、如何停止，以及某些時候可能發生的特殊事件（稱爲variation，即變化）。
2.3 用戶界面組織
在製作Use Case的過程中，你會得到一些指示網站需要哪些用戶界面的線索。也許你早就有了設計某些頁面的絕妙主意，但Use Case幫助我們從另外一個角度來看問題。用戶是否確實需要那麼多的界面？某個頁面是否過於複雜？網站的導航設施是否簡單易用，即從主頁訪問常用服務是否很方便？在勾畫界面草圖、製作網站原型之前，你應該先在Use Case圖中解決這些問題。
當Use Case逐漸清晰時，我們就可以開始勾畫出網站的大致結構。有些人會強調說頁面和文件應該用相應的構件圖（Component Diagram）建模，其實類圖（Class Diagram）工具也很方便。請參見下圖：
圖3：用戶界面及其佈局
在上圖中，各種網站服務被捆綁到了不同的網站區域：
/ - 網站的根
/common/ - 公用的圖形、腳本、CSS文件等
/maps/ - 地圖數據
/traffic/ - 交通流量報表
/weather/ - 天氣報表
該圖還顯示了在頁面之間傳遞的參數。regionId是一個很重要的參數，它代表着用戶感興趣的地區（可能是一個國家、城市或者省份）。regionId在頁面之間傳遞地區信息，使得用戶能夠從指定地區的天氣報表跳轉到交通流量信息。至於網站的common區域，你可以看到指針指向的是整個包（package）而不是區域中的單個文件，這是一種減少混亂的簡化方法，因爲所有其它的包都要用到大部分（如果不是全部的話）/common/區域中的文件。
用戶界面佈局圖能夠幫助你避免網站混亂，它對於規劃網站是很有用的。而且，一旦確定了一種有效的網站結構組織方式，它還可以作爲一個固定的模式在多個網站上應用。
2.4 工具選擇
對於小型網站，選擇工具和技術相當簡單。特別是由於投資的原因，只有少數幾種工具組合才具有現實意義——Apache，MySQL或者PostgreSQL，PHP、Perl或JSP/Servlet。當前最流行的組合是Apache + PHP + MySQL，有許多低價位的Web託管服務支持並主要集中在這種工具組合上。而對於規模較大的網站，在投資應用軟件之前，它必須對各種工具進行更嚴格的評估和測試。下面是一個構件圖的例子，它可以用來說明網站的體系結構。這個圖形雖然簡單，但它已經描述出了當前大多數網站的體系結構，對於你的網站，重新制作該圖可能也沒有必要，因爲再也沒有什麼與衆不同的內容值得加入這個圖形了。
圖4：網站體系結構圖
討論軟件的整個生命週期已經超出了本文的範圍，但應該指出的是，建立應用原型和界面模型應該在這個時候就開始。務必記下有關網站結構和頁面佈局的一些想法，因爲最終你會想要爲佈局（菜單，導航條，頁面整體佈局等）編寫一些公用的代碼。另外，如果你正在轉到新的工具和技術，建立原型的工作能夠讓你確保設計的可行性，確信已經就新工具的使用對開發組成員進行了足夠的培訓。
三、設計階段
設計階段應該與分析階段交迭。一旦對自己所要構造的系統有了較多的認識，你就應該開始擬定設計思路。先100％地分析系統再進入設計階段是沒有意義的。需求總是不斷地發展，而設計本身有時也會推動需求的發展（反之亦然）。所有的開發者都在進行某種類型的設計——只不過有些開發者直接以編程代碼的形式進行設計。雖然這也能夠完成任務，但它使得管理複雜工程和在工作組之內分配任務變得非常困難。先花一點時間通過設計圖構造系統模型，以後你將獲得巨大的回報。
3.1 爲未來而設計
許多開發者花費在代碼調試和改寫上的時間超過了編寫代碼的時間，如果從一個以上網站的建設來看這個問題，情況就尤其嚴重了。好的網站設計能夠以結構、組織方式和代碼重用的形式應用到多個網站上。然而，如果代碼只是匆匆忙忙堆砌而成，從現有代碼長期獲益的機會就減少了。要對網站進行設計規劃，一種很有效的方法是畫出類圖（Class Diagram）。下圖顯示了類圖通常要用到的許多重要關係。
圖5：類圖
說明如下：
Renderer類是一個抽象類（用斜體字顯示）。這意味着Renderer類不能直接使用，程序只能創建其子類的實例（即new Region()）。爲了滿足把頁面內容顯示到不同類型瀏覽器的需要，所有用來生成內容的頁面都必須從Renderer類派生。
WeatherReport類創建並擁有Region對象，這通過代表聚合關係（Aggregate Relationship）的黑色菱形顯示出來，它表示一個對象擁有並創建其他對象。
方法名字前面的加號（“+”）表示該方法是公用方法，可以被其他對象或者函數調用；減號（“-”）表示方法或者變量是私有的，只能由同一對象內部的成員函數訪問。在PHP中方法和變量是公用的，但我們應該總是把變量看成私有，避免從對象外部直接訪問變量。
HTMLWeatherReport類依賴於HTMLUtils類。依賴關係（dependency）表示一個類要創建另一個類的實例或者調用另一個類的方法。
類圖中的每一個類應該註明：所有的方法（以及所有的變量，如有的話），方法的訪問屬性（public，private或者protected），方法的返回值類型，方法的參數，變量的類型。函數寫在前面，如果類有變量的話，則一般隨後在一個分開的方框中列出。
即使你所構造的不是一個面向對象的系統，你仍就可以用類圖建立系統的模型。類能夠方便地描述出各種包含關係和你所編寫的函數文件。雖然此時類圖不再顯示繼承、構成/聚合等面向對象系統特有的關係，但它可以用依賴關係描述出文件之間的調用關係。
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/emtit2008/archive/2008/10/09/3042360.aspx