成功建構 J2EE 企業級應用的關鍵，在於有效的需求溝通、正確的分析與設計決策，以及識別最佳的實作選擇。追求卓越可視化建模的企業，能更快速地開發軟體並建立更高品質的系統。統一建模語言（UML）正是軟體工業視覺化建模的標準。
UML 於 1997 年成為 OMG 標準，是一種支援軟體系統建模與開發的圖形化語言，為從需求分析、規格定義到建構與配置等所有開發階段提供建模與視覺化支援。運用 UML 進行視覺化建模，主要目的是掌握系統的重要細節，使專案需求能清晰表達、解決方案架構得以開發、所選實作方案能被明確標識與建構。UML 不僅為基本構造元素提供符號表示，更提供表達元素間複雜關係的機制，這些關係皆以 UML 圖表形式呈現。
專案失敗往往源於需求理解不足或溝通不暢。自然語言（口頭或書面）天生不嚴謹，難以精確傳達需求。UML 用例模型可建立精確的系統需求模型，並以此為基礎推動系統開發的各個面向。用案如同串聯項鍊的線，將所有珍珠（需求細節）串聯起來，在終端用戶與系統需求間架起橋樑，支援從功能需求到系統實作的雙向追溯，也可作為連結詳細用例文件的節點。
圖 1 展示線上 CD 商店的部分用例圖，從文字與口頭功能需求提煉而來。圖中顯示購買者（角色，用簡易人形圖示）可透過四種方式使用系統（用例，以橢圓表示）。
圖 1：簡易用例圖
每個用例透過一個或多個序列圖場景精確描述。需求擷取與分析早期，序列圖相對簡單且可能不完整。圖 2 即為說明「付費」用例的序列圖範例。在 Rational Rose 中，可於瀏覽器選取用例，再從功能表選擇 New > Sequence Diagram 來建立對應序列圖。
圖 2：解釋付費用例的序列圖
進入用例分析階段，針對內部元素如何交互以滿足功能需求，提供初始的高層級定義。此階段需反覆試驗直到獲得滿意方案。「分析類別」的行為常以自然語言描述，較為抽象，但在此階段是有用工具。分析類別通常不直接在軟體中實作，而是在整體設計過程中轉換為精確定義的設計類別與子系統。
我們精心繪製序列圖以揭露系統內部運作，不再展示角色與系統的交互，而是將系統分解為獨立的分析物件，將系統職責分配至分析層級物件以獲得更佳序列圖。這裡介紹三類分析物件：
代表系統內部運作與其所處環境間的交互，包含使用者透過圖形介面的交互、與其他角色（如代表外部系統的角色）的交互、與設備的交互等。邊界物件將系統內部與外部事物隔離保護。簡單說，每個角色-用例交互映射至一個邊界物件。
代表系統的關鍵資訊，長期持久存在。主要目的在表達與管理系統資訊。模型中系統關鍵概念以實體物件呈現。
用於建模系統行為。控制物件不需自行實作行為，可與其他物件協作實現用例行為。核心思想是將行為與底層資訊隔離，便於應對後續變更。
UML 提供 stereotype 標記（雙尖括號文字）以區分不同類型類別。在 Rational Rose 中，只需將類別的 stereotype 欄位分別設為 <<boundary>>、<<entity>> 和 <<control>> 即可輕鬆建立分析類別，作為分析層級圖表基礎。
圖 3 為更新版付費用例序列圖，系統分解為分析物件。圖中以圖示代表邊界（T 字形）、控制（帶箭頭圓圈）與實體（帶切線圓）物件。
圖 3：帶有分析物件的精確序列圖
類別通常參與多個用例，理解其靜態關係同樣重要。UML 類別圖有助於捕捉不同結構元素的靜態模型。首先將用例中所有類別置入類別圖，由於行為已分布至物件，分析各類別操作變得較簡單。注意這些是分析層級操作，隨著分析設計深入將持續細化。Rational Rose 允許在序列圖的分析類別上直接定義新操作（選擇現有訊息，從功能表選擇），若已定義類別操作則可從列表選擇既有操作，這提高生產力並確保模型一致性與品質。另一實用功能是查詢模型中未解釋的類別與訊息（如未映射至真實類別或操作）。
完成類別圖尚需識別類別屬性（代表資訊，可能被其他類別或自身需要）與類別間關係（關聯、依賴、繼承）。分析完所有用例並建立各自類別圖後，需整合不同分析類別獲取統一分析模型，識別跨用例重複或僅微小差異的類別並合併（如相似行為的控制類、相同屬性的實體類），以獲得最小類別集合並避免冗餘。圖 4 顯示基於圖 1 用例的初步分析層級類別圖，使用 Rose 的顯示過濾功能隱藏屬性與操作細節以專注關係。
圖 4：初步分析層級類別圖
