前言
成功地運用J2EE構建企業應用的關鍵和所有復雜的軟件平台是一樣的：有效的需求溝通、制定正確的分析和設計決定，並且識別最佳的實現選擇。
追求最佳可視化模型的公司可以更快地開發它們的軟件，並且建立更高質量的系統。Unified Modeling Language (UML)就是可視模型化的軟件工業標准。
在這裡，我們將向你介紹如何運用UML和Rational Rose 2001a，它是現今最流行的基於UML的軟件模型化和開發工具，可用於開發基於J2EE的企業應用。
什麼是UML?
Unified Modeling Language (UML),是始於1997年一個OMG標准，它是一個支持模型化和軟件系統開發的圖形化語言,為軟件開發的所有階段提供模型化和可視化支持，包括由需求分析到規格，到構造和配置。
使用UML作可視化模型主要是為了了解系統的重要細節，以便項目的需求可以清晰地表達、開發出解決方案體系、並且一個選擇的實現可以清晰地標識和構造。為達到這個目的，需要豐富的符號來表達模型化的軟件系統。UML不但為基本的構造塊提供了符號表示，它還提供了方法來表達基本構造塊之間的復雜關系。這些關系都以UML框圖的形式表示出來。
以下就讓我們來看一下UML和Rational Rose是如何有助於理解、設計和實現J2EE應用的。
理解需求
項目失敗的原因通常是由於需求沒有很好地理解或者進行溝通。我們也可以很容易地理解，無論是口頭或者書面的語言，都是不嚴密的。
你可以應用UML用例模型來開發一個精確的模型來表示系統的需求，然後以這些用例為基礎來推動系統開發的其它方面。用例的作用就好象是項鏈上的一條線，它將所有的珍珠綁定在一起。用例在最終的用戶和系統需求之間建立起一座橋。它們可用來在功能需求和系統實現本身之間進行回溯。用例也可以作為一個連接點，連接到一個詳細的說明需求細節的用例文檔。
圖1展示了一個在線CD商店的部分用例框圖，它們是從文本和口頭的功能需求中提取出來，然後轉為用例。在這個例子中，很明顯購買者（由幾條線條組成的人物，表示為UML中的角色）可以通過4種方式來使用系統（在UML中以橢圓表示一個用例）。
***********圖1********
一個簡單的用例圖
每個用例則通過順序框圖中的一個或者多個場景來精確描述。當然，在需求捕捉和分析的早期階段，順序圖是相對簡單，而且也可能是不完整的。順序圖的這樣一個例子如圖2所示。在Rational Rose中，要為某個用例創建順序圖，你可以在浏覽器中選擇它，然後從用例的菜單中選擇New>Sequence Diagram。
***********圖2************
一個解釋付費用例的順序圖
設計一個方案
隨後的階段是用例分析，對於內部元素是如何交互來滿足系統的功能需求，以及它們是如何相關，這個階段提供了一個初始的、高級別的定義。這個分析需要進行反復的試驗，直到產生滿意的解決方案。“Analysis classes（分析類）”的行為通常是通過自然的語言描述的，比較抽象，在這個分析階段中，它是一個有用的工具。分析類通常都不在軟件中實現，雖然我們可以做到這一點，實際上，在總體設計過程中，分析類才會轉換為精確定義的設計類和子系統。
我們首先要精心地制造順序圖，以便它們可以揭露出系統的內部運作，我們並不是通過展示角色和一個系統的交互來分析系統，而是將系統分解成獨立的分析對象。系統的職責被分解到分析級別的對象中，以便可以得到一個更好的順序圖。在這裡我們要介紹三種分析對象：
．邊界對象
邊界對象代表系統的內部工作和它所處環境之間的交互。它包括有一個用戶通過圖形界面的交互，與其它角色的交互（例如代表其它系統的角色），和設備的交互等。邊界對象將系統的其它部分和外部的相關事物隔離和保護起來。簡單地說，每一個角色-用例交互對映射到一個邊界對象。
. 實體對象
實體對象代表系統的重要信息。在一個很長的時間內，它們都是持久和存在的。它們的主要目的是表達和管理系統中的信息。在模型中，系統中的關鍵概念以實體對象來表現。
. 控制對象
控制對象是用來模型化系統中的行為的。控制對象並不需要實現這個行為，它可能是與其它對象協作以實現用例的行為。它的想法是為了將行為和模型下層的信息隔離開來，這樣在處理以後的改變時就比較容易。
UML提供了stereotype符號，它表示為放在一個雙角括號中的文本，以便和不同類型的類區別開來。在Rational Rose中，你可以很容易地創建分析類，只需將類的stereotype字段分別修改為<>, <>和<>就可以了。這些都可以作為創建分析級框圖的基礎。
付款用例順序圖的一個更新版本如圖3所示，這裡系統被分解為分析對象。在這個圖中，使用圖標來代表邊界、控制和實體對象（分別以一個T、帶箭頭的圓圈和一個帶切線的圓表示）。
當然，類通常都參與到幾個用例中，因此為確保系統的一致性，理解它們的靜態關系也是同樣重要的。對於捕捉不同結構元素的靜態模型，UML類圖是很有用的。
首先，我們標識和放置用例中所有的類到一個類框圖中。我們已經將用例的行為分布到對象中，所以要分析每個類的操作就變得相對簡單了。要注意的是，這些是分析的操作，這意味著隨著我們不斷地進行分析和設計，這些操作將會不斷地需要細化。
Rational Rose可讓你很簡單地在順序圖中的分析類上定義新的操作，你只要選擇現有的信息，並且在菜單上選擇 就可以了（如圖3所示）。---www.bianceng.cn。如果你已經定義了一個類的操作，你可以簡單地由列表上選擇現有的操作。
****圖3：帶有分析對象的精確順序圖****
這是Rational Rose中的一個典型方法，它可以提高用戶的生產力，並且確保整個模型的一致性和質量，另一個類似的有用特性包括有查詢模型哪個類和消息是沒有解釋的（例如在模型中沒有映射到真正的類或者操作）。
還有一個方面是需要標識每個類的屬性。屬性代表的信息，可能是其它類需要的，也可能是類自身為履行自己的職責需要的。在這個分析階段，應將屬性標識為普通的類型，例如數字、字符串等。
要完成用例的類圖，你還需要標識類間的關系。在這個階段中我們特別感興趣的關系是關聯、依賴和繼承。
在分析完所有的用例和為每個用例創建類框圖後，我們就需要接合各種不同的分析類來得到一個統一的分析模型。這是一個重要的活動，因為我們需要得到一個最小集合的類，並且為了避免在最後的分析模型中出現不必要的冗余。
這個階段的主要任務是標識在用例間重復出現的類或者只有很小改變的類。例如，對於跨用例間擁有類似行為或者表示同樣概念的控制類，我們應該將它們合並。擁有同樣屬性的實體類也應該被合並，它們的行為也合並為一個類。
圖4展示了一個初步分析級的類框圖（這是根據圖1的用例得到的）。由於我們現今只是關系類間的關系，所以我們使用Rational Rose的顯示過濾能力來過濾掉每個類的細節（通過不勾選Format>Show all attributes和Format>Show all operations就可以了）。
**********圖4************
初步分析級的類框圖
