面向對象的分析
在您準備為企業(yè)作出系統和軟件投資前，必須首先了解企業(yè)的實(shí)際需求，明確所部署的技術(shù)將如何幫助您的企業(yè)獲取更大的成功。您能夠使用 UML，借助用例圖、序列圖和活動(dòng)圖來(lái)進(jìn)行分析。這些圖表將幫助您規劃系統的范圍、動(dòng)態(tài)性能、連同表現方式等。不必考慮實(shí)施細節，您希望獲得的只是按照您的需求而表現的系統性能。
用例圖(The Use Case Diagram)
UML 用例圖提供了一個(gè)系統環(huán)境的建模方式。他能夠幫助您確定系統/應用程式的外部和內部元素連同系統范圍。作為圖像建模模式，他在您需要和所收集的系統需求進(jìn)行對話(huà)時(shí)也將有所幫助，對于研制成品的研發(fā)團隊來(lái)說(shuō)，更是有著(zhù)舉足輕重的重要性。對于企業(yè)的任何者，或第一次接觸該軟件產(chǎn)品的用戶(hù)也有很大的幫助作用。用例圖能夠以可視化的方式，表達系統如何滿(mǎn)足所收集的業(yè)務(wù)規則，連同特定的用戶(hù)需求等信息。
在項目后期，也能夠用到 UML 用例圖。您能夠通過(guò)用例圖中定義的需求來(lái)協(xié)助測試項目的相關(guān)功能。您不但能夠驗證系統性能是否無(wú)錯誤（無(wú)崩潰或明顯的非邏輯響應），還能夠驗證系統運行時(shí)是否按照需要，執行了指定命令。這樣，您能夠測試系統是否完全滿(mǎn)足了需要，以確信成品能夠投入生產(chǎn)——也就是說(shuō)，他已完全滿(mǎn)足了用戶(hù)的需求。
只有確保滿(mǎn)足了合理、實(shí)用的各項需求，才能確保 IT 項目的更大成功。
您能夠使用 UML 序列圖細化需求并對設計元素進(jìn)行鏈接。序列圖允許高層和低層對象間的交互文檔。該交互在角色（和用例圖中的角色相同）和類(lèi)實(shí)例（運行于電腦內存中的技術(shù)對象和細節對象）之間顯示。
通過(guò)序列圖，您能夠按照系統特定方案中事件（消息）的精確順序來(lái)描述隨時(shí)間變化的系統行為。使用序列圖進(jìn)行用例分析并引導設計：您能夠決定將對用例圖所定義的管理任務(wù)負責的系統對象類(lèi)型，并決定哪種對象將管理系統內外的“會(huì )話(huà)”或通信。由于消息已從序列圖中抽出，您能夠描述類(lèi)和接口（我們最后要編譯和部署的代碼元素）所需的某些關(guān)鍵操作（方法）。
活動(dòng)圖(The Activity Diagram)
UML 活動(dòng)圖設計用于幫助您了解系統中對象的動(dòng)態(tài)變化。用于描述某一特定類(lèi)或一組類(lèi)如何協(xié)同工作。和序列圖有所不同，活動(dòng)圖不是一系列和時(shí)間相關(guān)的通信，而是從一個(gè)任務(wù)到另一任務(wù)的控制轉移，同時(shí)指定誰(shuí)（哪個(gè)對象）對發(fā)生的任務(wù)負責。
UML 活動(dòng)圖也是業(yè)務(wù)流程的技術(shù)視圖?？蓪I(yè)務(wù)工作流進(jìn)行分析或在“業(yè)務(wù)流程建模”工作后可獲得活動(dòng)圖。
活動(dòng)圖還可幫助構造系統內元素的周詳動(dòng)態(tài)視圖（EJB 如何互操作等）。
通過(guò)分析模型可捕獲單獨于實(shí)施細節之外的系統意向和預期行為，和使用的語(yǔ)言、部署的應用程式服務(wù)器或使用的體系結構都沒(méi)有關(guān)系。但是，設計階段開(kāi)始后，一切都發(fā)生了變化。您必須進(jìn)入生產(chǎn)環(huán)境的細節并將軟件構建至特定的體系結構。設計是對系統的實(shí)施。
假如設計是由分析得到的，您能夠更加確信所編寫(xiě)的系統行為的正確性，確認所研發(fā)的成果將是個(gè)按需求構建的系統。您將獲得高度成功——讓用戶(hù)得到所需要的系統。您還能夠直接利用分析得出的信息而無(wú)需在設計過(guò)程中重新生成，從而縮減研發(fā)時(shí)間，由于不必“重新復制”任何工作，因此減少了人為錯誤。
通過(guò)分析，我們可獲得什么呢？通過(guò)用例圖能夠發(fā)現對象并促進(jìn)類(lèi)和接口的創(chuàng )建。一個(gè)或更多類(lèi)和接口能夠實(shí)現一個(gè)角色，您能夠在角色定義中直接創(chuàng )建類(lèi)和接口。您還能夠將角色鏈接到現有的類(lèi)和接口，顯示如何使用一條代碼來(lái)滿(mǎn)足所分析的多個(gè)元素。
通過(guò)序列圖能夠發(fā)現方法并促進(jìn)類(lèi)操作的創(chuàng )建。假如您需要向類(lèi)發(fā)送消息，您能夠調用該類(lèi)的方法。序列圖中的消息能夠用來(lái)自動(dòng)創(chuàng )建操作或鏈接到現有操作。您能夠通過(guò)鏈接跟蹤方法的功能，包括將哪些作為輸入內容和必須返回哪些內容等等。
設計所包含的內容
您已知道要構建的內容，現在您需要表述如何構建。您需要確定業(yè)務(wù)邏輯所在的位置：能夠置于應用程式服務(wù)器的 EJB 等組件中，也能夠置于使用 VB 或 PowerBuilder 等語(yǔ)言、作為客戶(hù)端應用程式一部分的類(lèi)或組件中，或做為觸發(fā)器和過(guò)程內置于關(guān)系數據庫中。您需要根據需求做出一些選擇，包括擴展性、安全、性能和可訪(fǎng)問(wèn)性等方面。
UML 類(lèi)圖和組件圖將用于定義周詳的技術(shù)系統靜態(tài)結構。
類(lèi)圖 (The Class Diagram)
UML 類(lèi)圖、業(yè)務(wù)邏輯和任何支持結構一同被用于定義全部的代碼結構。既然類(lèi)圖用來(lái)模擬研發(fā)中所維護的實(shí)際代碼，顯然他是 Java 或 PowerBuilder 等對象語(yǔ)言的概括性表述。您還能夠使用 UML 類(lèi)圖來(lái)概括 XML 中的復雜結構，令其更易于研發(fā)和理解。
能夠從 UML 類(lèi)圖上生成代碼。還能夠在研發(fā)過(guò)程中編輯該代碼以完善、測試和部署最終運行的應用程式。由于 PowerDesigner 在對象語(yǔ)言和 UML 類(lèi)圖之間具備 1:1 的映射功能，您還能夠實(shí)施反向工程代碼，讀取源文檔并創(chuàng )建新的類(lèi)圖。您能夠更深入地理解現有系統并簡(jiǎn)化集成和維護工作。
組件圖(The Component Diagram)
UML 組件圖將被用于在更大的黑匣視圖（Black Box View）中描述高級對象的定義和相關(guān)性。他仍然是個(gè)設計模型,并且是代碼的直接概括。例如，一個(gè) EJB 的組件標識直接鏈接到實(shí)施所必需的一系列類(lèi)和接口，并將生成所需代碼來(lái)推動(dòng)最終 bean 的研發(fā)。
組件圖比組件體系結構的代碼層視圖更容易理解和管理。還能夠通過(guò)編寫(xiě)組件接口的文檔來(lái)實(shí)現代碼的共享和反復使用，用戶(hù)無(wú)需（或很少）了解組件的實(shí)施細節即可在其他項目和系統中使用這些代碼。
右擊Customer EntityBean_CMP，選擇Create/Update Class Diagram,生成如下class diagram:
循環(huán)疊代工程
世界不是一成不變的，您的 IT 項目也如此。在您了解需求，通過(guò)分析進(jìn)行了設計，并構建了系統的某些元素后，必然還會(huì )碰到新的變化，如要更新定義，又或現有用例圖中存在某些需要改正的錯誤，代碼在 IDE 和文本編輯器中被編輯連同數據庫被DBA 優(yōu)化等。必須管理和掌控任何需要更改的細節，以確保所構建的系統能夠和業(yè)務(wù)需求保持一致。
往返工程的一個(gè)方案是當代碼在研發(fā)過(guò)程中被更改時(shí)，需要在類(lèi)圖中反映出來(lái)。具體細節如下：
1. 創(chuàng )建類(lèi)圖并將業(yè)務(wù)邏輯元素添加到模型中
2. 生成文檔系統的應用程式代碼
3. 在 IDE 或文本編輯器中編輯代碼
4. 編輯設計，此時(shí)忽略在生成的代碼中所發(fā)生的更改
5. 對編輯內容實(shí)施反向工程，直到和現有類(lèi)圖一致
6. 將設計過(guò)程中完成的工作和研發(fā)時(shí)編輯的內容同步（合并）
7. 生成新代碼，該代碼是設計代碼和研發(fā)人員更改代碼的總和
當對類(lèi)圖進(jìn)行了修改以反映新的設計內容時(shí)，應該使用同步/合并技術(shù)防止丟失研發(fā)人員的工作成果，同時(shí)允許設計人員接受或拒絕研發(fā)過(guò)程中所做的更改。這樣，PowerDesigner 令 IT 能夠完全控制體系結構，這正是制勝的關(guān)鍵。
PowerDesigner 的功能并不是僅限于此！現在設計模型已被更新，您能夠將這些更改鏈接到分析中。有可能您在分析中發(fā)現了新的需求，能夠將這一更改反映到設計中并編寫(xiě)代碼。使用 PowerDesigner 中領(lǐng)先的 Compare/Merge 技術(shù)（在 September Blueprint 中討論過(guò)），您能夠在研發(fā)周期的任何模型和階段中獲得真正的往返同步。
對象圖(Object Diagram)
和類(lèi)圖相同，對象圖也是個(gè) UML 靜態(tài)結構圖；他定義了系統在給定時(shí)刻具備的物理元素，而沒(méi)有具體考慮系統的動(dòng)態(tài)活動(dòng)。他和代碼一一對應，但和類(lèi)圖不同，我們現在討論的是具體的分類(lèi)器，而不是分類(lèi)器定義。將對象圖描述為類(lèi)實(shí)例圖可能最為合適。
對象圖的主要用途是進(jìn)行分析。類(lèi)圖中無(wú)法表示的類(lèi)之間存在不確定的約束。我們將使用對象圖來(lái)記錄這些約束。而且，在我們查看所管理的具體類(lèi)實(shí)例示例以闡明這些元素之間的交互作用關(guān)系時(shí)，對象圖還允許我們定義具體的“What if”場(chǎng)景。
以下內容適用于 OO 建模的初學(xué)者：分類(lèi)器是抽象的對象結構定義。分類(lèi)器能夠告訴我們所管理的是什么類(lèi)型的數據（屬性/成員表示數據元素）連同該分類(lèi)器具備什么能力（操作/方法表示對象的行為）。實(shí)例是具體的分類(lèi)器示例。假定定義一個(gè)名為 Customer 的類(lèi)，該類(lèi)具備 Name 屬性。類(lèi) Customer 的實(shí)例“Jane Doe”是姓名恰為“Jane Doe”的客戶(hù)。實(shí)例通常具備比分類(lèi)器更豐富的含義，這是因為分類(lèi)器表示某種級別的概述。收集某個(gè)分類(lèi)器的若干個(gè)實(shí)例或示例可能有助于您理解其用途并更好地使用他。
因此，對象圖是類(lèi)圖的具體形式，表示類(lèi)實(shí)例樣本，并且顯示了鍵值和關(guān)系。例如，CustomerBean 類(lèi)具備以下客戶(hù)實(shí)例：該客戶(hù)的 ID 為 52271，姓名為“John Doe”。該客戶(hù)實(shí)例和三個(gè)訂單實(shí)例（三份訂單）相關(guān)，訂單編號分別為122047、122103 和 122399。
協(xié)作圖(Collaboration Diagram)
協(xié)作圖和序列圖很相似。實(shí)際上，序列圖和協(xié)作圖能夠有效地交替使用，并能夠簡(jiǎn)便的相互轉換。其區別在于用戶(hù)閱讀和理解的方式不同。序列圖具備很好的層次性，并且圍繞時(shí)間構造。協(xié)作圖則主要是圍繞對象結構構造。通過(guò)在圖中對消息進(jìn)行編號能夠表示消息的順序。采用這種方式時(shí)，即使圖的結構不是基于時(shí)間的，也將保持定時(shí)關(guān)系。
協(xié)作圖借助于系統中元素或對象之間的交互作用，表示系統的動(dòng)態(tài)方面，即在一段時(shí)間內的表現方式。他通過(guò)表示系統的靜態(tài)結構來(lái)對類(lèi)圖和對象圖進(jìn)行補充，但不是借助于基于結構的關(guān)系，而是在系統對象之間傳遞交互作用“消息”。
構造協(xié)作圖時(shí)還能夠在概念級測試靜態(tài)模型。在類(lèi)圖中定義了類(lèi)實(shí)例，這些類(lèi)實(shí)例之間的交互作用定義了一個(gè)具體的使用方案連同將在這些元素之間發(fā)生的內部通訊。我們還能夠使用其他角色來(lái)表示系統的外部作用者和內部使用者，如用例圖。
例如，我們能夠建立一個(gè)訂單輸入系統，以供客戶(hù)和銷(xiāo)售代表使用?？蛻?hù)通過(guò)創(chuàng )建新訂單和該系統交互作用。訂單對象和銷(xiāo)售對象之間進(jìn)行對話(huà)，該對話(huà)由鏈接消息表示，在此情況下，只有兩個(gè)消息：一個(gè)是來(lái)自 Orders 類(lèi)的訂單請求，一個(gè)是來(lái)自 Sales 類(lèi)的訂單確認。對一個(gè)鏈接上的消息數量沒(méi)有限制。我們在此討論的對話(huà)以一個(gè)訂單請求開(kāi)始，然后是對該訂單的確認。
適用性
協(xié)作圖對于設計人員尤其重要，因為他闡明了對象的作用。您能夠在序列圖之前構造協(xié)作圖（假如您計劃構造這兩個(gè)圖），但通常是在完成類(lèi)圖之后構造協(xié)作圖以說(shuō)明從類(lèi)中導出的對象之間的交互作用。能夠使用一個(gè)或多個(gè)協(xié)作圖來(lái)實(shí)現一個(gè)用例，或將復雜行為分割成多個(gè)邏輯子行為。
狀態(tài)圖(Statechart Diagram)
狀態(tài)圖（也稱(chēng)為狀態(tài)機）描述了特定類(lèi)或組件在其整個(gè)生命周期中不斷變化時(shí)的行為。該圖顯示是什么觸發(fā)了從一種狀態(tài)向另一種狀態(tài)的轉換，連同在該類(lèi)上調用哪些操作以提供該狀態(tài)的行為或觸發(fā)這種轉換。例如，訂單在被創(chuàng )建時(shí)處于初始狀態(tài)。在客戶(hù)確認訂單正確后，訂單將進(jìn)入確認狀態(tài)。在發(fā)貨以后，訂單需要從確認狀態(tài)進(jìn)入發(fā)貨狀態(tài)。
因此，每當一個(gè)類(lèi)在其生命周期的不同階段具備不同的可用選項（不同的有效行為）時(shí)，您都能夠使用狀態(tài)圖來(lái)將這些規則和條件建模。生命周期中的每個(gè)階段都是該對象的一種狀態(tài)，而每個(gè)改變狀態(tài)的觸發(fā)器都代表從一種狀態(tài)到另一種狀態(tài)的轉換。能夠根據需要從某個(gè)狀態(tài)轉換到任意多個(gè)其他狀態(tài)，也能夠從其他多個(gè)狀態(tài)進(jìn)入某個(gè)狀態(tài)。
子狀態(tài)圖
若要保持狀態(tài)圖簡(jiǎn)單和易讀，您可能發(fā)現所定義的一個(gè)或多個(gè)狀態(tài)實(shí)際上涉及到更為復雜的行為，以至于他本身就能夠定義為一個(gè)狀態(tài)圖。此時(shí)，和向主圖中添加大量復雜細節的做法相比，更好的做法是將這個(gè)單獨的狀態(tài)分解為多個(gè)子狀態(tài)，進(jìn)而組成一個(gè)輔助圖，以定義父狀態(tài)的更為復雜的內部行為。
部署圖(Deployment Diagram)
部署圖能夠幫助我們確定任何代碼元素在服務(wù)器、工作站和數據庫中的存放位置。有的節點(diǎn)需要依賴(lài)硬件或軟件框來(lái)運行部分業(yè)務(wù)邏輯。這些節點(diǎn)交互作用以演示我們研發(fā)的多個(gè)電腦和系統是如何交互作用和集成的。節點(diǎn)中包含將部署到數據庫、應用程式或 Web 服務(wù)器中的組件實(shí)例。
部署圖用于將組件實(shí)際部署到服務(wù)器中。通過(guò)定義希望組件運行的位置，我們能夠快捷的映射、部署和管理分布在客戶(hù)端應用程式和應用程式服務(wù)器端組件之間的業(yè)務(wù)邏輯或數據庫端服務(wù)器邏輯。以下是要管理的物理體系結構的 1:1 模型。
例如，假定我們已決定實(shí)現兩個(gè) Enterprise Java Beans，并且在應用程式服務(wù)器上運行他們。下圖顯示了單個(gè)節點(diǎn)連同該節點(diǎn)內的兩個(gè)組件（每個(gè) EJB 一個(gè)組件）。我們能夠看出 EmployeeBean 依賴(lài)于同一應用程式服務(wù)器內的 CustomerBean。
結論
在我們借助用例圖、序列圖、活動(dòng)圖、類(lèi)圖和組件圖完成基本 UML 建模時(shí)，我們將需要其他一些工具來(lái)定義有關(guān)系統中某些特定元素的周詳信息。我們可能希望在對象圖中使用精確的示例來(lái)表示對象的結構，或借助于狀態(tài)圖來(lái)更多地了解在其內部具備多個(gè)復雜狀態(tài)的類(lèi)的行為。我們需要使用協(xié)作圖從結構角度而不是從時(shí)間角度來(lái)考察系統組件之間的交互作用。最后，還需要使用部署圖來(lái)顯示任何系統組件在運行環(huán)境中的物理硬件或服務(wù)器中所處的位置，從而更詳盡的了解分布式體系結構的使用方式。
UML 為我們提供了更加實(shí)用的圖表，以便完成對業(yè)務(wù)邏輯的技術(shù)分析、設計、研發(fā)、或部署。將這 9 種圖表和傳統的數據建模方法和新的業(yè)務(wù)流程建模方法相結合，我們能夠在從高級需求到技術(shù)和數據需求，連同物理實(shí)現的各個(gè)方面來(lái)全面了解推動(dòng)軟件研發(fā)的任何因素
聯(lián)系客服
