|
Uml輔助網(wǎng)站規(guī)劃和設(shè)計(jì)指南
一、概述
Web網(wǎng)站往往具有復(fù)雜與高度動(dòng)態(tài)的特點(diǎn)。為了讓W(xué)eb應(yīng)用在短時(shí)間之內(nèi)開始運(yùn)作，開發(fā)周期應(yīng)該盡量地短。許多時(shí)候，開發(fā)者直接進(jìn)入編寫代碼這一階段，卻不去仔細(xì)考慮自己想要構(gòu)造的是什么樣的網(wǎng)站以及準(zhǔn)備如何構(gòu)造：服務(wù)器端代碼往往是毫無準(zhǔn)備的即興式編寫，數(shù)據(jù)庫表也是隨需隨加，整個(gè)應(yīng)用的體系有時(shí)候呈現(xiàn)一種無規(guī)劃狀態(tài)。然而，只要我們運(yùn)用一些建模技術(shù)和軟件工程技術(shù)，就能夠讓開發(fā)過程更加流暢，確保Web應(yīng)用將來更容易維護(hù)。
UML（Unified Modeling Language，統(tǒng)一建模語言）是一種通用的可視化建模語言，用于對軟件進(jìn)行描述、可視化處理、構(gòu)造和建立軟件系統(tǒng)的文檔。UML適用于各種軟件開發(fā)方法、軟件生命周期的各個(gè)階段、各種應(yīng)用領(lǐng)域以及各種開發(fā)工具。UML能夠描述系統(tǒng)的靜態(tài)結(jié)構(gòu)和動(dòng)態(tài)行為：靜態(tài)結(jié)構(gòu)定義了系統(tǒng)中重要對象的屬性和操作以及這些對象之間的相互關(guān)系；動(dòng)態(tài)行為定義了對象的時(shí)間特性和對象為完成目標(biāo)任務(wù)而相互進(jìn)行通信的機(jī)制。UML不是一種程序設(shè)計(jì)語言，但我們可以用代碼生成器將UML模型轉(zhuǎn)換為多種程序設(shè)計(jì)語言代碼，或使用反向生成器工具將程序源代碼轉(zhuǎn)換為UML模型。
本文介紹用UML為Web網(wǎng)站建模的一些方法。全面采用UML技術(shù)是一個(gè)復(fù)雜的過程，但UML的某些部分很容易使用，而且它能夠幫助你用更少的時(shí)間構(gòu)造出更好的系統(tǒng)。
為了示范UML在網(wǎng)站建設(shè)中的應(yīng)用，本文將構(gòu)造一個(gè)支持無線用戶、提供各個(gè)地區(qū)天氣報(bào)表和交通流量報(bào)表的網(wǎng)站。本文不準(zhǔn)備詳細(xì)介紹UML本身。但為了方便起見，附錄中簡要介紹了常見的UML符號和術(shù)語。要了解更多有關(guān)UML的信息，請參見文章最后的參考資源。
二、規(guī)劃階段
不論你是從頭開始構(gòu)造網(wǎng)站、移植網(wǎng)站還是增加某個(gè)重要的功能，為了確保設(shè)計(jì)決策的最優(yōu)化，進(jìn)行一些先期規(guī)劃是必要的。如果你和其他人協(xié)作完成一項(xiàng)工程，就工作總量及其分配達(dá)成明確的共識具有不可估量的作用。在規(guī)劃期間，你應(yīng)該努力對系統(tǒng)的以下方面形成正確的認(rèn)識：
用戶和角色。
應(yīng)用需求。
各個(gè)界面之間的轉(zhuǎn)換流程。
要用到的工具和技術(shù)。
2.1 用戶
了解使用系統(tǒng)的用戶是很重要的。不僅系統(tǒng)分析要求你接觸一些用戶（通過問卷調(diào)查、email，或者面對面交談），而且你經(jīng)常還要讓系統(tǒng)能夠控制不同的用戶角色和權(quán)限。通過對用戶進(jìn)行分類并了解他們的需求，你就可以找出線索來確定數(shù)據(jù)庫的安全機(jī)制、功能限制方法、用戶界面分組、培訓(xùn)和幫助需求、對具體內(nèi)容的需求，甚至還可以從側(cè)面了解到潛在廣告客戶的分布。
http://www.yesky.com/20021114/softfz201114_01.gif
圖1：參與者/角色 層次圖
上圖顯示了幾組不同的網(wǎng)站用戶（在UML中稱為Actor，即參與者）。在這里，最普通的用戶類型（“Site User”）位于圖的頂端，實(shí)線箭頭表示generalization關(guān)系（“泛化”關(guān)系，參見本文附錄說明，下同），它表示Site User又可以具體分成兩類用戶：Guest，Registered User。這兩類用戶共有的特征在“Site User”參與者中說明，而Guest和Registered User各自私有的特征則在對應(yīng)的參與者中說明。通常，你可以直接為參與者加上說明文檔，無需單獨(dú)編寫說明用戶的文檔，但具體與你所用的UML工具有關(guān)。在本例中，Registered User又可以細(xì)分為Wireless User和Administrator兩種類型，系統(tǒng)對這些用戶的處理方式應(yīng)有所不同。
2.2 定義需求
在正式開始編寫代碼之前，你應(yīng)該對準(zhǔn)備構(gòu)造一個(gè)怎樣的系統(tǒng)有一個(gè)清晰的認(rèn)識。雖然在編寫代碼的同時(shí)也可以逐步完成這一工作，而且這種做法也很有吸引力，但借助圖形和文字資料事先集體進(jìn)行討論效率要高得多。為網(wǎng)站編寫詳細(xì)的需求說明往往不那么合算，但你應(yīng)該有時(shí)間畫出幾個(gè)草圖、寫下幾段注解去說明網(wǎng)站準(zhǔn)備提供的服務(wù)。這就要用到Use Case圖（用例圖）。Use Case可以看成一組功能——它可能對應(yīng)網(wǎng)站上的一個(gè)頁面、一個(gè)必須編寫的程序，或者網(wǎng)站上可能發(fā)生的一個(gè)動(dòng)作（比如，驗(yàn)證用戶登錄，改變用戶的配置文件，清除過期的賬號，等等）。下面就是一個(gè)能夠幫助你規(guī)劃網(wǎng)站的Use Case圖。注意，該圖并沒有顯示出網(wǎng)站的所有Use Case，通常我們需要多個(gè)Use Case圖才能描述完整的網(wǎng)站功能。
http://www.yesky.com/20021114/softfz201114_02.gif
圖2：Use Case圖
即使是在這樣一個(gè)簡單的Use Case圖中，我們也能夠輕松地表達(dá)出大量的信息。例如，include關(guān)系說明兩個(gè)Use Case包含同樣的身份驗(yàn)證功能；extend關(guān)系說明天氣頁面可能以WML或者HTML格式顯示；generalization關(guān)系說明各個(gè)具體的表現(xiàn)過程將遵從“Render HTML Page”或者“Render WML Page”所描述的基本行為規(guī)則以達(dá)到維持統(tǒng)一的風(fēng)格效果和統(tǒng)一宏觀行為模式的目的。
上圖也顯示出無線用戶能夠訪問網(wǎng)站中其他用戶不能訪問的某些區(qū)域。在這個(gè)Use Case圖中，只有無線用戶能夠訪問交通流量報(bào)表。這是因?yàn)槲覀円呀?jīng)得知只有在旅途中的移動(dòng)用戶才需要交通流量報(bào)表，而且不想再花時(shí)間把交通流量報(bào)表制作成其他標(biāo)記語言形式。由此，“Get Traffic Report”Use Case不需要分成WML和HTML兩種顯示形式，它可以直接包含“Render WML Traffic Report”這個(gè)Use Case。
一般地，你應(yīng)該為這些Use Case加上簡單的說明。具體地說，你應(yīng)該描述每一個(gè)Use Case里將要發(fā)生什么，誰可以使用它，它如何啟動(dòng)、如何停止，以及某些時(shí)候可能發(fā)生的特殊事件（稱為variation，即變化）。
2.3 用戶界面組織
在制作Use Case的過程中，你會(huì)得到一些指示網(wǎng)站需要哪些用戶界面的線索。也許你早就有了設(shè)計(jì)某些頁面的絕妙主意，但Use Case幫助我們從另外一個(gè)角度來看問題。用戶是否確實(shí)需要那么多的界面？某個(gè)頁面是否過于復(fù)雜？網(wǎng)站的導(dǎo)航設(shè)施是否簡單易用，即從主頁訪問常用服務(wù)是否很方便？在勾畫界面草圖、制作網(wǎng)站原型之前，你應(yīng)該先在Use Case圖中解決這些問題。
當(dāng)Use Case逐漸清晰時(shí)，我們就可以開始勾畫出網(wǎng)站的大致結(jié)構(gòu)。有些人會(huì)強(qiáng)調(diào)說頁面和文件應(yīng)該用相應(yīng)的構(gòu)件圖（Component Diagram）建模，其實(shí)類圖（Class Diagram）工具也很方便。請參見下圖：
http://www.yesky.com/20021114/softfz201114_03.gif
圖3：用戶界面及其布局
在上圖中，各種網(wǎng)站服務(wù)被捆綁到了不同的網(wǎng)站區(qū)域：
/ - 網(wǎng)站的根
/common/ - 公用的圖形、腳本、CSS文件等
/maps/ - 地圖數(shù)據(jù)
/traffic/ - 交通流量報(bào)表
/weather/ - 天氣報(bào)表
該圖還顯示了在頁面之間傳遞的參數(shù)。regionId是一個(gè)很重要的參數(shù)，它代表著用戶感興趣的地區(qū)（可能是一個(gè)國家、城市或者省份）。regionId在頁面之間傳遞地區(qū)信息，使得用戶能夠從指定地區(qū)的天氣報(bào)表跳轉(zhuǎn)到交通流量信息。至于網(wǎng)站的common區(qū)域，你可以看到指針指向的是整個(gè)包（package）而不是區(qū)域中的單個(gè)文件，這是一種減少混亂的簡化方法，因?yàn)樗衅渌陌家玫酱蟛糠郑ㄈ绻皇侨康脑挘?common/區(qū)域中的文件。
用戶界面布局圖能夠幫助你避免網(wǎng)站混亂，它對于規(guī)劃網(wǎng)站是很有用的。而且，一旦確定了一種有效的網(wǎng)站結(jié)構(gòu)組織方式，它還可以作為一個(gè)固定的模式在多個(gè)網(wǎng)站上應(yīng)用。
2.4 工具選擇
對于小型網(wǎng)站，選擇工具和技術(shù)相當(dāng)簡單。特別是由于投資的原因，只有少數(shù)幾種工具組合才具有現(xiàn)實(shí)意義——Apache，MySQL或者PostgreSQL，PHP、Perl或JSP/Servlet。當(dāng)前最流行的組合是Apache + PHP + MySQL，有許多低價(jià)位的Web托管服務(wù)支持并主要集中在這種工具組合上。而對于規(guī)模較大的網(wǎng)站，在投資應(yīng)用軟件之前，它必須對各種工具進(jìn)行更嚴(yán)格的評估和測試。下面是一個(gè)構(gòu)件圖的例子，它可以用來說明網(wǎng)站的體系結(jié)構(gòu)。這個(gè)圖形雖然簡單，但它已經(jīng)描述出了當(dāng)前大多數(shù)網(wǎng)站的體系結(jié)構(gòu)，對于你的網(wǎng)站，重新制作該圖可能也沒有必要，因?yàn)樵僖矝]有什么與眾不同的內(nèi)容值得加入這個(gè)圖形了。
http://www.yesky.com/20021114/softfz201114_04.gif
圖4：網(wǎng)站體系結(jié)構(gòu)圖
討論軟件的整個(gè)生命周期已經(jīng)超出了本文的范圍，但應(yīng)該指出的是，建立應(yīng)用原型和界面模型應(yīng)該在這個(gè)時(shí)候就開始。務(wù)必記下有關(guān)網(wǎng)站結(jié)構(gòu)和頁面布局的一些想法，因?yàn)樽罱K你會(huì)想要為布局（菜單，導(dǎo)航條，頁面整體布局等）編寫一些公用的代碼。另外，如果你正在轉(zhuǎn)到新的工具和技術(shù)，建立原型的工作能夠讓你確保設(shè)計(jì)的可行性，確信已經(jīng)就新工具的使用對開發(fā)組成員進(jìn)行了足夠的培訓(xùn)。
三、設(shè)計(jì)階段
設(shè)計(jì)階段應(yīng)該與分析階段交迭。一旦對自己所要構(gòu)造的系統(tǒng)有了較多的認(rèn)識，你就應(yīng)該開始擬定設(shè)計(jì)思路。先100%地分析系統(tǒng)再進(jìn)入設(shè)計(jì)階段是沒有意義的。需求總是不斷地發(fā)展，而設(shè)計(jì)本身有時(shí)也會(huì)推動(dòng)需求的發(fā)展（反之亦然）。所有的開發(fā)者都在進(jìn)行某種類型的設(shè)計(jì)——只不過有些開發(fā)者直接以編程代碼的形式進(jìn)行設(shè)計(jì)。雖然這也能夠完成任務(wù)，但它使得管理復(fù)雜工程和在工作組之內(nèi)分配任務(wù)變得非常困難。先花一點(diǎn)時(shí)間通過設(shè)計(jì)圖構(gòu)造系統(tǒng)模型，以后你將獲得巨大的回報(bào)。
3.1 為未來而設(shè)計(jì)
許多開發(fā)者花費(fèi)在代碼調(diào)試和改寫上的時(shí)間超過了編寫代碼的時(shí)間，如果從一個(gè)以上網(wǎng)站的建設(shè)來看這個(gè)問題，情況就尤其嚴(yán)重了。好的網(wǎng)站設(shè)計(jì)能夠以結(jié)構(gòu)、組織方式和代碼重用的形式應(yīng)用到多個(gè)網(wǎng)站上。然而，如果代碼只是匆匆忙忙堆砌而成，從現(xiàn)有代碼長期獲益的機(jī)會(huì)就減少了。要對網(wǎng)站進(jìn)行設(shè)計(jì)規(guī)劃，一種很有效的方法是畫出類圖（Class Diagram）。下圖顯示了類圖通常要用到的許多重要關(guān)系。
http://www.yesky.com/20021114/softfz201114_05.gif
圖5：類圖
說明如下：
Renderer類是一個(gè)抽象類（用斜體字顯示）。這意味著Renderer類不能直接使用，程序只能創(chuàng)建其子類的實(shí)例（即new Region()）。為了滿足把頁面內(nèi)容顯示到不同類型瀏覽器的需要，所有用來生成內(nèi)容的頁面都必須從Renderer類派生。
WeatherReport類創(chuàng)建并擁有Region對象，這通過代表聚合關(guān)系（Aggregate Relationship）的黑色菱形顯示出來，它表示一個(gè)對象擁有并創(chuàng)建其他對象。
方法名字前面的加號（“+”）表示該方法是公用方法，可以被其他對象或者函數(shù)調(diào)用；減號（“-”）表示方法或者變量是私有的，只能由同一對象內(nèi)部的成員函數(shù)訪問。在PHP中方法和變量是公用的，但我們應(yīng)該總是把變量看成私有，避免從對象外部直接訪問變量。
HTMLWeatherReport類依賴于HTMLUtils類。依賴關(guān)系（dependency）表示一個(gè)類要?jiǎng)?chuàng)建另一個(gè)類的實(shí)例或者調(diào)用另一個(gè)類的方法。
類圖中的每一個(gè)類應(yīng)該注明：所有的方法（以及所有的變量，如有的話），方法的訪問屬性（public，private或者protected），方法的返回值類型，方法的參數(shù)，變量的類型。函數(shù)寫在前面，如果類有變量的話，則一般隨后在一個(gè)分開的方框中列出。
即使你所構(gòu)造的不是一個(gè)面向?qū)ο蟮南到y(tǒng)，你仍就可以用類圖建立系統(tǒng)的模型。類能夠方便地描述出各種包含關(guān)系和你所編寫的函數(shù)文件。雖然此時(shí)類圖不再顯示繼承、構(gòu)成/聚合等面向?qū)ο笙到y(tǒng)特有的關(guān)系，但它可以用依賴關(guān)系描述出文件之間的調(diào)用關(guān)系。
3.2 運(yùn)行時(shí)的系統(tǒng)模型
有些時(shí)候，我們需要顯示出應(yīng)用的各個(gè)部件如何在運(yùn)行時(shí)協(xié)作完成任務(wù)。前面的類圖顯示了類之間的關(guān)系，但它沒有顯示出調(diào)用出現(xiàn)的次序，也沒有顯示出來自一個(gè)函數(shù)的結(jié)果可能決定下一次調(diào)用的目標(biāo)。為了在更動(dòng)態(tài)的層面上描述系統(tǒng)，UML提供了許多其他類型的圖。對于Web網(wǎng)站設(shè)計(jì)來說，情節(jié)圖（Scenario Diagram）特別有用。情節(jié)圖分成兩種：協(xié)作圖（Collaboration Diagram），序列圖（Sequence Diagram）。一般地，我們不會(huì)建立系統(tǒng)所有交互過程的模型，情節(jié)圖只用來描述系統(tǒng)最復(fù)雜的部分，或用來概括出代碼的一般調(diào)用模式。例如，我們可能要示范特定的頁面如何與驗(yàn)證用戶身份的代碼協(xié)作，或者要顯示頁面如何調(diào)用公用代碼（工具性的框架代碼）以保持統(tǒng)一的外觀和風(fēng)格。
協(xié)作圖和序列圖分別舉例如下。
http://www.yesky.com/20021114/softfz201114_06.gif
圖6：協(xié)作圖
上面的協(xié)作圖顯示了從Web網(wǎng)站獲取天氣報(bào)表的一般過程。注意該圖忽略了一些不重要的方法，因?yàn)槲覀冎粚μ幚磉^程中的關(guān)鍵步驟感興趣。你可以根據(jù)編號“1”到“1.3.3.4”找出各個(gè)函數(shù)的執(zhí)行次序。一些人喜歡以“1，2，3，……”形式對執(zhí)行步驟編號，但一般而言，用“1，1.1，1.2，2，2.1，……”的形式顯示出調(diào)用棧的深度是一種更好的選擇，這種編號方式能夠更清楚地顯示出程序的控制轉(zhuǎn)換過程。例如，上圖顯示出report()方法調(diào)用了WMLUtil以及Region對象中的許多方法：在通過一系列的查詢和內(nèi)容生成函數(shù)為指定地區(qū)生成報(bào)表之前，我們調(diào)用了WMLUtil中的buildHeader(...)函數(shù)；最后我們調(diào)用的是WMLUtil模塊的buildFooter(...)，然后返回report()方法，最后返回getPage()。你可以為協(xié)作圖加上更多的細(xì)節(jié)說明，比如返回值、約束、條件等。
http://www.yesky.com/20021114/softfz201114_07.gif
圖7：序列圖
就圖形所傳達(dá)的信息而言，次序圖和協(xié)作圖非常相似。事實(shí)上，許多UML建模工具能夠從協(xié)作圖生成次序圖，或者相反。次序圖與協(xié)作圖的主要不同之處在于：在次序圖上，事件的發(fā)生次序一目了然，非常直觀。另外，次序圖中還可以加入生存周期和時(shí)間方面的詳細(xì)信息，比如延遲、線程并發(fā)、對象的構(gòu)造和刪除等。
在決定選用次序圖還是協(xié)作圖的時(shí)候，考慮以下幾點(diǎn)有助于你作出最合適的選擇：
如果要顯示代碼中與時(shí)間或線程密切相關(guān)的問題，選擇次序圖。
如果要顯示對象之間的交互模式，選擇協(xié)作圖。
如果要顯示幾個(gè)或者大量對象之間的交互過程，選擇次序圖。
如果要顯示少量對象之間的大量消息傳遞或交互過程，選擇協(xié)作圖。
3.3 應(yīng)用部署的規(guī)劃
正如本文前面“工具選擇”部分所提到的，大多數(shù)Web網(wǎng)站的體系結(jié)構(gòu)并不復(fù)雜。盡管如此，部署圖（Deployment Diagram）在兩個(gè)方面仍舊很有用：網(wǎng)站結(jié)構(gòu)，文件組織。對于文件組織，前面討論界面規(guī)劃時(shí)已經(jīng)提到它也可以用類建模工具進(jìn)行規(guī)劃。下面給出一個(gè)簡單的構(gòu)件圖供參考，但根據(jù)網(wǎng)站的需要和復(fù)雜程度的不同，你可能不需要它。
http://www.yesky.com/20021114/softfz201114_08.gif
圖8：構(gòu)件圖
3.4 設(shè)計(jì)原則
UML只是一個(gè)工具。如果使用得法，UML能夠幫助我們輕松地構(gòu)造出更好的網(wǎng)站。然而，要設(shè)計(jì)出優(yōu)秀的網(wǎng)站，關(guān)鍵仍在于要有一個(gè)好的設(shè)計(jì)原則或理念。
“提高類的內(nèi)聚力，減少不同類之間的聯(lián)系”這一點(diǎn)在談到好的面向?qū)ο笤O(shè)計(jì)原則時(shí)經(jīng)常被反復(fù)引用。一個(gè)內(nèi)聚的類包含那些在目標(biāo)和作用域上都緊密相關(guān)的行為和信息。它意味著你不應(yīng)該把構(gòu)造UI的代碼和實(shí)現(xiàn)數(shù)學(xué)算法的代碼混合到一起，你應(yīng)該盡力把所有與用戶緊密相關(guān)的信息封裝到UserAccount類。內(nèi)聚式設(shè)計(jì)是一個(gè)重要的設(shè)計(jì)原則，原因有很多：它有助于減少類之間的依賴關(guān)系，使得設(shè)計(jì)更直觀、更容易理解，方便了向其他開發(fā)者介紹整個(gè)設(shè)計(jì)，減少了開發(fā)者同一時(shí)刻需要操作的類的數(shù)量，等等。例如，如果你要改變網(wǎng)站的用戶身份驗(yàn)證機(jī)制，只修改單個(gè)文件中的一個(gè)類無疑要比修改多個(gè)文件、多個(gè)類更加方便。
“減少不同類之間的聯(lián)系”意味著使類或者文件之間的交互減到最少。它不僅使得整個(gè)設(shè)計(jì)容易理解，而且也方便了代碼的維護(hù)。請考慮下面這個(gè)例子：
http://www.yesky.com/20021114/softfz201114_09.gif
圖9：設(shè)計(jì)實(shí)例A
除非深入了解了上述各個(gè)類的用途，要估計(jì)這些類的內(nèi)聚程度是不可能的。然而，從這些類之間的關(guān)系可以看出，這個(gè)設(shè)計(jì)方案已經(jīng)成功地減少了不同類之間的聯(lián)系。類之間的交互被減到了最少，從而使得系統(tǒng)的行為很容易理解。更重要的是，修改任意一個(gè)類時(shí)受影響的類數(shù)量都減到了最少（例如，修改D類只直接影響B(tài)類）。另外，要訪問D類中的功能，我們無需知道任何有關(guān)E、F或G類的情況。作為比較，請考慮下圖：
http://www.yesky.com/20021114/softfz201114_10.gif
圖10 設(shè)計(jì)實(shí)例B
顯然，在這個(gè)設(shè)計(jì)實(shí)例中，類之間的聯(lián)系是相當(dāng)緊密的。一旦對D1類作了修改，為了檢查這種修改對其他類的影響，我們必須對其他類進(jìn)行廣泛的測試。
只有在實(shí)踐中不斷鍛煉才能避免出現(xiàn)過于復(fù)雜的設(shè)計(jì)，但注意以下幾點(diǎn)有助于達(dá)到這一目標(biāo)：
提高類的內(nèi)聚力。不要把密切相關(guān)的功能分散到多個(gè)文件和類之中。
采用直觀、有意義的名字。如果其他人不能了解類、函數(shù)或者變量的作用，不管類的結(jié)構(gòu)是多么完美，整個(gè)設(shè)計(jì)仍缺乏直觀性。過多地采用縮寫詞會(huì)影響設(shè)計(jì)的可理解性。
不要害怕改寫代碼。有些時(shí)候，在幾個(gè)類之間移動(dòng)一些函數(shù)能夠大大地簡化代碼。
類應(yīng)該保持緊湊、簡潔。代碼膨脹是類缺乏內(nèi)聚力的一種征兆。過于龐大的類、模塊或者文件往往缺乏明確的用途和目標(biāo)。
讓其他人復(fù)查你的設(shè)計(jì)。其他人可能有新的想法，或者為你指出你以為顯而易見但別人卻不能明白的問題。
在早期設(shè)計(jì)階段不要考慮太多的性能問題。與一個(gè)笨拙的、為了昨天所出現(xiàn)的問題而優(yōu)化的設(shè)計(jì)相比，一個(gè)簡潔、經(jīng)過精心調(diào)整的設(shè)計(jì)更容易進(jìn)行性能優(yōu)化。注意這并不是建議把性能問題拋到腦后，而是建議把細(xì)節(jié)優(yōu)化問題留到工程后期考慮。
四、UML工具
下面是一些值得考慮的UML建模工具：
Microsoft Visio：Visio Professional 2000現(xiàn)在開始提供內(nèi)建的UML支持。如果考慮Visio繪圖工具的其他各種用途，這是一個(gè)相當(dāng)有價(jià)值的工具。如果你使用2000以前的版本，你可以在這里找到Visio Stencil and Template for UML。
Rational Rose：這是一個(gè)推薦使用的工具，但對于許多小型Web工程來說它顯得很昂貴。有了Rational Rose這樣的工具，改進(jìn)和維護(hù)設(shè)計(jì)、從模型生成報(bào)表、在平行協(xié)作環(huán)境中與他人共同進(jìn)行建模工作就很方便了。
MagicDraw：一個(gè)基于Java的廉價(jià)UML建模工具。
Together：與C/C++和Java聯(lián)系密切，支持UML建模。
Objecteering UML：一個(gè)免費(fèi)的個(gè)人UML產(chǎn)品。
System Architect：一個(gè)很受歡迎的高端UML建模工具，支持雙向工程（Round-trip Engineering）。
五、附錄：常用UML符號和參考資源
下面這個(gè)表格簡要介紹了常用的UML符號和關(guān)系。要了解有關(guān)UML概念和各種面向?qū)ο笮g(shù)語的詳細(xì)說明，請參見后面的參考資源。
http://www.yesky.com/20021114/softfz201114_11.gif
Use Case
用例。Use Case描述了系統(tǒng)某一部分的行為。一般地，Use Case記錄對某個(gè)系統(tǒng)功能的需求，而這個(gè)功能由對動(dòng)作或者事件的應(yīng)答示范。
Package
包。用來聚集和組織模型中的一個(gè)部分（Use Case，類，等等）。
http://www.yesky.com/20021114/softfz201114_12.gif
Actor
參與者。它代表一個(gè)用戶或者其他外部的激勵(lì)器。
http://www.yesky.com/20021114/softfz201114_13.gif
Use Case
用例。Use Case描述了系統(tǒng)某一部分的行為。一般地，Use Case記錄對某個(gè)系統(tǒng)功能的需求，而這個(gè)功能由對動(dòng)作或者事件的應(yīng)答示范。
http://www.yesky.com/20021114/softfz201114_14.gif
<> Relationship
包含關(guān)系。標(biāo)注為<>關(guān)系的Use Case關(guān)系能夠引入其他Use Case的功能。這是一種方便的分割Use Case、避免單個(gè)Use Case過于龐大的方法。
http://www.yesky.com/20021114/softfz201114_15.gif
<> Relationship
擴(kuò)充關(guān)系。標(biāo)注為<>關(guān)系的Use Case關(guān)系能夠在不重復(fù)現(xiàn)有Use Case的各種描述和需求的情況下，使現(xiàn)有Use Case的行為特殊化。
http://www.yesky.com/20021114/softfz201114_16.gif
Note
注解。在UML圖中提供注解的目的是以簡短的說明闡明圖表的內(nèi)容。
http://www.yesky.com/20021114/softfz201114_18.gif
Component
構(gòu)件。構(gòu)件一般代表一個(gè)軟件單元，它可能是一個(gè)DLL、一個(gè)執(zhí)行文件，或者是一個(gè)數(shù)據(jù)庫。
http://www.yesky.com/20021114/softfz201114_19.gif
Node
節(jié)點(diǎn)。節(jié)點(diǎn)一般代表一臺(tái)機(jī)器，這臺(tái)機(jī)器具有運(yùn)行一個(gè)或者多個(gè)系統(tǒng)構(gòu)件的能力。http://www.yesky.com/20021114/softfz201114_20.gif
Class
類。UML中的類與面向?qū)ο缶幊讨械念愐粯?，即它定義并封裝了一組行為和屬性。類在運(yùn)行時(shí)被實(shí)例化從而創(chuàng)建出對象。
http://www.yesky.com/20021114/softfz201114_21.gif
Object
對象。對象是類的實(shí)例。例如，“MyClass myObj = new MyClass; ”創(chuàng)建了一個(gè)myObj對象。
http://www.yesky.com/20021114/softfz201114_22.gif
Generalization
泛化。父類能夠派生出（或稱為特殊化）具有更多特殊行為的子類，此時(shí)父類即為子類的超類（或子類的泛化版本）。
http://www.yesky.com/20021114/softfz201114_23.gif
Interface
接口。接口定義了一組可以從外部訪問的行為。類、庫、執(zhí)行文件、數(shù)據(jù)文件都可以由接口來描述。接口本身并不實(shí)現(xiàn)任何功能，它只是和聲明實(shí)現(xiàn)該接口的對象訂立了一個(gè)必須實(shí)現(xiàn)哪些行為的契約。
http://www.yesky.com/20021114/softfz201114_24.gif
Abstract Class
抽象類。抽象類不能直接實(shí)例化，但允許派生出具體的、有實(shí)際功能的類。
http://www.yesky.com/20021114/softfz201114_25.gif
Association
關(guān)聯(lián)。關(guān)聯(lián)就是把兩個(gè)或以上的類連接起來。你可以為兩個(gè)類之間的這種關(guān)系提供更具體的信息。關(guān)聯(lián)是兩個(gè)或多個(gè)特定類元之間的關(guān)系，它描述了這些類元的實(shí)例的聯(lián)系。在一個(gè)關(guān)聯(lián)中同一個(gè)類可以出現(xiàn)在多個(gè)位置上。
http://www.yesky.com/20021114/softfz201114_26.gif
Aggregation
聚合。聚合關(guān)系表示某個(gè)對象屬于其他對象所有。
參考資源：
UML 1.3 Specification：UML規(guī)范，來自omg.org
UML Resource Page：OMG維護(hù)的UML資源
Object Oriented F
AQ：一個(gè)面向?qū)ο笮g(shù)語和概念的介紹
Practical UML Guide
Cetus UML Links
Modeling Web Application Design with UML - Rational Rose白皮書
（出處：）
|
