摘要
如今，UML用於對軟件系統進行建模已有多年時間。然而，我極少看到有關對現代軟件系統建模和技術的詳細討論或實例。例如，對應用程序及其部署建模需要開發各類原型系統，並需要使用有組織的方法來設計圖的作用范圍和布局，使其真正發揮作用。在復雜的環境中，建模顯得尤為重要，它不僅能為編寫代碼的軟件工程師帶來好處，而且負責正確配置和部署軟件系統的軟件配置管理團隊和生產服務團隊也能從中獲益良多。本文演示了對現代軟件建模的幾種方法，這些方法可用於精確而簡明地交流架構方面的細節。
簡介
不久以前，有用的企業應用程序還是由少數實體bean、較多的會話bean和一些JSP構建而成。EJB被打包在JAR文件中，而JSP則被簡單地存儲在Web服務器的類路徑中。如果軟件業還能有什麼讓您所稱道的，那就是軟件在大小、功能和復雜性方面呈幾何指數增長。軟件大小已經增長到每個企業應用程序的各個部分都被存儲在壓縮格式的WAR和EAR文件中的程度。軟件系統的復雜性需要高效的建模，以便幫助管理設計和相互關系。軟件功能現在已經處於這樣一個級別：需要定義一個完整的新范型——即服務，才能對其進行管理。
必須對軟件復雜性進行管理，因為它對企業的影響很大。這種管理可以同時采取規劃和通信的形式。現在，可以使用UML來幫助規劃軟件的架構、設計和部署。還可以使用它把這些規劃發送到企業中必須創建、安裝和維護企業軟件的各個部門中。
如果是對代碼進行建模，UML 1 X就已經很不錯了。而當對軟件系統的打包和部署進行建模時，它就顯得不夠了。隨著UML 2.0的出現，UML對核心軟件系統建模的能力大為增強。然而，UML 2.0真正耀眼的地方是在對軟件打包和部署建模時。
本文的目的是演示對現代軟件系統進行建模的幾種有效方法，這些方法可用於把架構、設計和部署方面的細節精確而簡明地傳達給企業中的相關負責部門。我並沒有聲明這是建模現代軟件的惟一方法。UML的建模語言相當豐富。然而，如果您不確定如何使用UML.2.0進行快速建模，尤其是對特定於BEA WebLogic Platform建模的信息，本文將會為您提供幫助。
建模難題——少就是多
我喜歡更加敏捷的建模方法。對軟件系統進行建模不會使公司直接獲益，但可執行軟件卻可從中受益。然而，建模是一種有效的通信工具，有助於讓整個公司就如何構建、部署和操作軟件達成一致的認識。
在對軟件建模時，其實少就是多。代碼隨著時間而增多，而模型則是靜止的，它是某個時刻設計思想的快照。因此，對軟件系統的每一個細節都建模並沒有太大用處。軟件系統的細節是在有機變化的。最佳方法是對軟件的核心部分進行建模。這些模型往往能夠在相當長的時間內發揮作用。
對代碼進行建模
我將從一個特定於代碼的模型開始，然後再逐漸轉到軟件打包和部署圖上。在此過程中，我認為您可以很好地理解什麼樣的細節級別適合於您的企業。有一點很重要，即，您要不斷地詢問自己，“這個圖可以幫助大家理解設計嗎？”。
首先，讓我們看一看我稱之為“over-modeling”的建模方式。圖1給出了一個使用了bean托管持久性的實體bean的UML圖。在這個圖中，您可以看到3個主接口和它們的根接口，以及實現類。
圖1. 對一個EJB進行Over-modeling
乍一看，圖中的內容似乎很多。其實，這個模型不過是較為詳細而已，實際上內容很少。該圖實際上顯示了一個實體bean的基本結構。稍微了解一點EJB知識的工程師就會發現這個圖其實很簡單。如果您提供一個充滿了這種“沒有價值的東西”的完整設計文檔，工程師們很快就會感到厭煩，並拒絕接受這種“無用的”設計文檔。
提示！——對系統的重要部分而不是無關緊要的部分進行建模。
讓我們看一看同一個圖經過修改後的版本。它刪除了無價值的內容，並將重點放在重要的內容上。樣板代碼和構件幾乎從不需要建模，除非它們能給圖帶來特別的好處（比如提供上下文）。例如，表示一個像ejbActivate()這樣的函數不能為圖增加清晰度或內容，因此也就無需對其進行建模。EJB規范中說方法必須出現在實現類中，並不意味著它需要出現在模型中。
圖2. 一個簡明的EJB模型
除了在建模上顯而易見的區別之外，兩張圖之間還有一處基本的區別：stereotype的自由使用。Stereotype是一種傳達有關任意模型元素的不相關信息的強大方式。使用stereotype的另一個有利之處是，定義的信息是由對象而不是圖來傳達的。在圖1中，JNDI信息表示在圖中的一條注釋中。這可以使JNDI信息特定於圖。在圖2中，我為捕捉JNDI信息的<<EntityBean>> stereotype定義了兩個標記值。標記定義是stereotype的屬性。通過為stereotype定義標記定義，實現了下面兩個目標：為架構師和設計師提供一些有關每個stereotype中應該包含何種信息的提示，並為企業引入了一些建模標准。通過使用stereotype並填充相關的標記定義值，可以讓包含該元素的每個圖都能使用這些信息。大多數UML工具都允許有選擇性地隱藏stereotype及其標記定義，您可以定制化每個圖，同時無需修改任何重要的模型數據。在本文後面，我將提供一個示例的stereotype類別。
提示！——使用stereotype對不相關信息進行建模。
對可部署代碼進行建模
現在，我將使用功能代碼，並對應該如何把它打包到一個可部署模塊中進行建模。在軟件建模項目中，這通常是會被徹底忽視的重要一步。然而，在這個領域中，誤解也是很常見的，而這些誤解通常會增加公司的成本，因為它會導致項目出現延期並重新編碼以糾正問題。
J2EE項目通常被打包為一個EAR或WAR文件。JAR文件仍然在使用，但是現在通常作為EAR或WAR文件的元素而存在。在UML中，文件被表示為Artifact。Artifact用於對節點上的內容進行建模。（節點通常表示一種設備，通常為計算機，但是它也可以表示一種虛擬設備。）例如，在UML中，文檔、文件、可執行文件和庫都被建模為Artifact。可部署的軟件也在這種定義的范圍之內，所以也可以把它建模為Artifact。
在整個領域內，這些類型的圖相當少見。我僅看見過兩家公司能夠實現這種級別的建模。創建這些模型的人通常會掉入到對可部署模塊的“定義”建模的陷阱中去。看看圖3您就會明白我的意思了。
圖3. 常見的可部署建模
這個圖的第一個錯誤之處就是“對顯而易見的內容進行建模”。“App-Inf”、“webapp”和“meta-inf”目錄沒有為圖增加任何價值。類似地，對“自定義屬性”文件的建模也很值得商榷。這只是圖中的無用信息。圖3的第二個錯誤之處是，它僅對模塊的“定義”進行了建模。它仍然以軟件為重點，展示了位於com.bea.customer Java包結構中的Customer EJB。對包結構建模可以增加價值，這取決於企業的需要，但是這個圖確實還有疏漏之處。它應該包含比軟件工程師需要的還多的信息，還應該包括對於軟件配置管理團隊來說重要的信息。這些“缺失的”信息就是部署模塊的“上下文”。必須運行軟件的團隊需要知道如何部署它，因此上下文對於他們來說很重要。
提示！——部署模型需要說明“定義”和“上下文”。
看一看圖4就很清楚了。這個圖既說明了部署模塊的定義，也說明了模塊必須存在於其中的上下文。上下文提供了模塊正確發揮功用所需的資源。這就告訴了SCM和生產團隊要確保提供這些資源，否則軟件就不會運行。
圖4. 較好的可部署模塊圖
現在，對於任何必須為應用程序創建可執行環境的人，這個圖都可以派上用場。現在，他們知道需要在環境中配置一個JMS隊列和一個JDBC驅動程序，因為這是應用程序的需要。有關JMS隊列和JDBC驅動程序的關鍵信息也包含在內。雖然我在這裡沒有對每一個細節都進行建模，但是通過對環境依賴性進行建模，我為SCM團隊提供了詢問其他問題的機會。此外，數據庫管理員可能會喜歡看到這個圖。他們很可能會提出有關客戶數據庫、索引、鍵之類的一些問題。
一個優秀的模型不只回答問題，它還會讓人們思考和詢問其他的問題。一開始，當您想建模來回答問題和記錄決策時，這似乎有些奇怪。這沒錯，但是UML的設計目的不是對一切內容進行建模。某些內容，比如數據庫設計，最好使用更加專業的工具進行建模。某些信息最好以純文本格式進行定義。一個優秀的模型可作為企業其他部門進行具體思考和設計的出發點。
提示！——優秀的模型可以回答一些問題並提出一些其他的問題。
您可能已經注意到了，這些圖中有些內容是相同的。每個圖都有其特定的目的，並包含針對特定受眾的消息。不能為了圖本身而創建圖，創建圖是為了與預定的受眾進行交流。每個圖都應該包含一條有針對性的消息。這條消息可能是“下面是這個[概念|類|對象|節點]與其直接鄰居的關系”，也可能是“下面是方法的行為”。就像所有的交流形式一樣，如果沒有特定的消息要傳達，很可能是該消息的接收方根本無法理解您的消息。
提示！——每個圖都應該有其特定的用途。
還要注意，在圖4中，我避免對JMS隊列和JDBC驅動程序的詳細細節進行建模。JMS隊列可以有另外的標記值，表示緩存大小、分頁目錄、啟動時暫停的插入，等等。通常不會對這些數據建模，因為這類內容是隨環境不同（也就是說，當把軟件從測試環境轉移到生產環境時）而不同的，而且這些值在應用程序調優過程中也會變化。提前指定它們的值通常不會帶來什麼好處。不過有一個例外：如果您的公司有這樣一個策略——在進行性能調優之後采用最後的生產配置值（即，應用程序配置值），那麼我將在模型中包含這些值。
部署圖
出於某種原因，在大多數UML書籍中，部署圖通常會受到輕視。在很多書中，有關部署圖的章節只不過2到6頁內容，而且只給出最簡單的示例圖。而我認為，這些圖恰恰是UML中最重要的部分。這些圖允許您表達一個軟件系統或者甚至是整個IT部門的架構，而且在找出生產環境中性能問題的根源時，它們可能是一個關鍵因素。
一家典型的公司有很多環境：開發環境（至少一個）、測試環境（可能多於一個）、性能環境、登台環境，當然還有生產環境。許多企業還需要維護一個災難恢復環境，以防自然或人為的災難。但是，沒有必要為所有這些環境維護部署圖。開發、測試和性能環境通常變化得太快，以至於無法為部署在這些環境中的軟件進行認真的建模。登台、生產和災難恢復環境在本質上是（或者說應該是）類似的，因此只對生產環境建模通常就足以捕捉到部署空間的本質。
這正是UML 2.0真正的用武之地。從UML 2.0中的變化來看，顯然很多人都覺得部署圖相當重要。在項目的早期階段，我建議在邏輯級別上對部署進行建模。我還建議在項目的最早期創建這些圖。部署是項目規劃的一個關鍵部分，而不是事後考慮。
我所看到的該領域中的部署圖大多數止於邏輯模型。重要的是對所有系統部署進行建模，而不是單獨對每個軟件系統進行建模。筒倉應用程序大行其道的時代已經一去不復返了。我們現在生活在一個互連系統的世界，而這些互連需要進行規劃和映射。
事實是，優秀的實用部署圖能幫助您找出生產中的問題。系統是否是在投入到生產中時還運轉良好，而現在卻出了問題呢？有時候，顯示征兆的系統並不是問題的根源所在。相反，有可能是上游或下游的系統沒有按照期望運行，而性能問題表現在系統的完全不同的部分中了。
有一個古老的寓言是這麼說的，有一個國王要求3個天生的盲人通過觸摸大象的一個部分來描述大象的樣子。摸到大象耳朵的盲人認為大象像一個簸箕，摸到大象尾巴的盲人認為大象像一把刷子，抱著大象腿的盲人認為大象像一棵樹。生產環境就像這頭大象一樣，由許多部分組成。如果您無法窺見全貌，那麼就很可能像寓言中的盲人一樣看法片面。您對任何問題真正本質的看法都可能是錯誤的。然而，對一個大型系統進行建模不是一件簡單的事情。如果試圖在一幅圖中表示過多的生態系統，那麼結果很可能是在牆上貼滿了許多無用的圖。
因此，我推薦使用層次結構來組織具體的部署圖。該層次結構的頂部是整個軟件生態系統的全貌。由於這類圖的本質，它將包含很少的具體部署細節，而將重點放在大型系統的邏輯關系上。
圖5是一個生產環境的簡單視圖。從這幅簡單的圖中，可以看到整個架構是中心輻射型的。還可以看到，整個企業在邏輯上被劃分為7個不同的組，還可以從中心節點的名稱“服務基礎架構”（Service Infrastructure）上猜到這些邏輯、功能性區域是通過一個服務層連接起來的。從這個圖出發可以深入研究獲得更多的細節。讓我們來仔細看一下客戶關系管理(Customer Relations Management，CRM)系統。
圖5.部署概覽圖
在圖6中，我修改了圖的范圍，以便聚焦於CRM系統。在這個圖中，您可以看到子系統中包含的3個商業應用程序：Siebel、Salesforce.com和ACTI。Salesforce.com實際上就是一個基於Web的應用程序，駐留在Salesforce.com服務器上，但是從企業的角度來看，它被認為是企業的一部分。
圖6. CRM域
從上圖中您還可以看到，有2個自主開發的子系統。第一個子系統允許客戶查看他們的帳戶狀態，定購產品，並使用Siebel系統提供的其他“自助”活動。第二個是CSR Command Center，它是一個自定義的應用程序，允許公司的客戶服務代表代表客戶執行任何功能。此外，它為客戶提供通常不可用的功能，比如在聯系人成為客戶之前跟蹤他們的前導信息。
接下來，我將聚焦於客戶自助（Customer Self Service，CSS）子系統，以便更加詳細地了解這個系統。
圖7. CSS物理部署細節
圖7給出了一幅非常詳細的實際部署圖。事實上，這個圖已經是密密麻麻的了。注意Domain實例中的嵌套元素（圖中心的大方框）。一般來說，我發現嵌套的最大深度是3層。如果超過3層，圖就開始超出其消息的范圍。這個圖說明了如下內容：
這個部署中總共有4台物理機器：2台是Sun Fire v40z機器，另外2台數據庫服務器是Dell PowerEdge 6850。顯示了PowerEdge的IP地址，但是SunFire機器的IP地址則沒有顯示。這是因為SunFire機器支持虛擬服務器。對這個圖來說，重要的是虛擬服務器的IP地址，而不是物理主機的IP。
總共在SunFire機器中創建了7台虛擬機器。這些虛擬機器與Java VM無關。它們是功能完整的機器，具有自己的IP地址。Java VM可以運行在這些虛擬機器中。
一個WebLogic Platform域包含了一台管理服務器和兩個集群。
WebPortal集群包括4台服務器。還可以看到將每台服務器連接到虛擬機器的部署線。這使得SCM如何建立集群的過程變得很清楚（至少是在結構化的級別上）。
名為BackEnd的第二個集群，它包含2台WebLogic服務器，還可看到這兩台服務器部署到虛擬機器上的位置。
一個包含客戶模式的Oracle數據庫，運行在Dell PowerEdge 6850機器上。
一個硬件負載均衡器，它把URL“customer.bea.com”轉換為WebLogic Portal服務器所使用的相應IP地址。
最後，我在底部為實際部署映射定義了一個圖例，它會提供有關已部署的實例類型的附加細節。
在這幅圖中，我提供了大量對開發、SCM和生產服務團隊有用的信息。
提示！——三層的嵌套通常就夠用了。
然而，還需要另一幅聚焦特定於WebLogic Server的細節的圖。這幅圖主要面向開發人員和SCM團隊。圖8就是一個例子。
圖8. 聚焦WebLogic Server的圖
下面，我將展示另一些特定於WebLogic Server的配置信息。您可以看到集群地址、多播地址和多播端口。您還可以看到創建了一個名為customerDS的數據源，其目標是BackEnd集群，這意味著該集群中的2台服務器都可以訪問這個數據源。我可以使用類似的結構對JMS主題和隊列、持久性存儲等建模。
此外，您還可以看到，這裡還顯示了前面圖中定義的可部署模塊，以及它們如何關聯到WebLogic集群。BackEnd集群（及其所有服務器）上都部署了customer.ear文件。類似地，WebPortal集群及其服務器上也部署了customer.ear文件。通過引用可部署模塊圖，可以快速關閉對這些信息的循環。
WebLogic Platform Stereotype分類
正如早先提到的那樣，UML stereotype是一種功能強大的注釋工具，它允許捕捉關於模型中元素的附加信息。在大多數建模工具中，都對J2EE、Web services和其他技術有著不同的UML分類。如果您的工具沒有提供這些預定義的分類，或者如果預定義的分類不能滿足您的特定要求，您可以快速創建自己的分類。圖9說明了本文中使用的分類。您可以對這個例子進行定制化，來滿足您的特定要求。
圖9. WebLogic Platform模型的一種Stereotype分類
對於Stereotype，您要記住的重要一點就是，要以一致的方式使用它們。模型必須經過一個復審過程，以確保它們滿足您所在公司所設立的標准。這可以幫助您創建標准化的模型，從而有助於讓IT部門之間和子團隊實現清楚的交流。獨立地（即，在它自己的模型中）維護stereotype模型，然後把stereotype導入到項目模型中。這將為您節省時間，並確保您在當前項目中使用的是最新的stereotype分類。
結束語
在本文中，我涵蓋了大量的細節。盡管進行高效的建模需要學習的東西肯定比我在這裡講的要多，本文應該可以幫助您創建更好的模型和圖，改進IT部門的不同團隊之間對於這些細節的交流，並提供一些標准和方法來幫助您更加有效地管理軟件系統。記住，建模只是一種輔助性工作，真正重要的還是可以執行的軟件系統。
