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