UML業(yè)務用例模型

1、業(yè)務用例模型業(yè)勢用例僅型業(yè)務用例模型：業(yè)務用例模型描述一個業(yè)務的流程以及它們與外部各方（如客戶和合作 伙伴）之間的交互。解釋由業(yè)務用例和主角構成的模型的主要目的是說明客戶和合作伙伴是如何開展業(yè)務的。直接與客戶或合作伙伴相關的活動以及與外部各方并不直接相關的支持和管理任務都可以在 模型中給出。模型以業(yè)務用例（相當于我們常說的“流程”）的形式對業(yè)務進行說明。登記處的主角和用例。業(yè)務用例的不同類型當考查業(yè)務中的活動時，您至少可以確定三類工作，它們對應著三種業(yè)務用例類型。第一類是在商業(yè)上比較重要的活動，常稱為業(yè)務流程。第二類是在商業(yè)上不太重要的活動，但必須進行這些活動來保證業(yè)務正常運轉。系統(tǒng)管理、清潔

2、和安全等工作就是這類活動的示例。該業(yè)務用例具有支持的性質。第三類是管理工作。具有管理性質的業(yè)務用例所顯示的工作影響如何管理其他業(yè)務用例 以及該業(yè)務和其所有者的關系。通常，管理類型的業(yè)務用例概括地描述了CEO和業(yè)務用例中工作人員之間的關系。它還說明了業(yè)務用例是如何被開發(fā)和“啟動”（實例化）的。在餐館中，核心業(yè)務用例是市場營銷(Marketing)和用餐服務(Serving Dinner),而采購(Purchasing Supplies)是支撐業(yè)務用例。請注意，有時候您當作核心業(yè)務用例的用例在其他業(yè)務中會成為支撐業(yè)務用例。例如，在軟件開發(fā)公司中， 軟件開發(fā)是核心業(yè)務用例；而在銀行或保險公司中，它卻

3、是支撐業(yè)務用例。一個業(yè)務有多個業(yè)務用例一個業(yè)務有多個業(yè)務用例。 多個不同業(yè)務用例的實例或一個業(yè)務用例的多個實例并行執(zhí) 行的情況是很正常的。一個用例實例可以遵循的路徑的數目幾乎是沒有限制的。這些不同的路徑代表了工作流程說明中用例實例的各種選擇。根據具體事件和情況， 用例實例可以沿著多種可能路徑中的一種進行下去，例如：來自主角的輸入。一條業(yè)務規(guī)則。在對業(yè)務用例建模時，您可以假定用例實例可以在不互相沖突的情況下同時進行。在業(yè)務開發(fā)的這個階段，您應該側重于業(yè)務應該作些什么。而解決潛在資源沖突的工作應該在工作建模階段進行，此時，您要設法理解業(yè)務中的工作是如何進行的?；蛘?，您也可以在新組織實施過程中，通過

4、增加能完成關鍵任務的雇員來解決這些問題。業(yè)務用例是否總是與業(yè)務主角相關？每個核心業(yè)務用例都應該和某個業(yè)務主角之間存在通信關系。該規(guī)則強調了構建業(yè)務的目的，即構建業(yè)務是為了提供用戶要求的服務。如果業(yè)務用例模型中存在無人要求的業(yè)務用例，這就說明模型存在問題。業(yè)務用例可以周期性地觸發(fā)，也可以長時間工作； 監(jiān)督功能就是后者的一個示例。這些業(yè)務用例中甚至還存在最初啟動這些業(yè)務用例并期望得到不同服務的業(yè)務主角。否則，它們將不能成為業(yè)務的一部分。其他業(yè)務用例將產生業(yè)務主角需要的結果，盡管業(yè)務主角并沒有明確地啟動它們。例如，某個廣泛發(fā)布產品的開發(fā)很少是由某個可以確定的客戶啟動的。而對新產品的需求通常是通過市場

5、研究和積累大量的用戶請求了解到的。盡管管理和支撐業(yè)務用例一般都有某種外部聯系，但它們不一定需要與業(yè)務主角進行聯系。例如，管理業(yè)務用例可以將業(yè)務的所有者或董事會作為其業(yè)務主角。抽象業(yè)務用例不需要業(yè)務主角，因為它們從不獨立進行實例化(“啟動”)。建立業(yè)務用例模型建立業(yè)務用例模型有三個主要原因：使業(yè)務用例更易于理解。復用多個業(yè)務用例共享的部分工作流程。使業(yè)務用例模型更易于維護。我們有三種關系用于建立業(yè)務用例模型。使用這些關系，您可以將那些可以在其他業(yè)務用例中復用的、或者作為該業(yè)務用例的特化或選項的部分業(yè)務用例分離出來。我們將代表修改的業(yè)務用例稱為附加用例。被修改的業(yè)務用例稱為基本用例。如果基本用例的

6、某個部分代表一個功能，而業(yè)務用例只依賴于本功能的結果，而不是產生結果的方法，那么您可以將這部分分離出來，形成一個附加用例。使用包含關系，將附加部分明確包含于基本用例中。另請參見指南：業(yè)務用例模型中的包含關系。如果基本用例的一部分是可選的，或對于理解該用例的主要目的來說不是必需的， 那么您可以將這部分分離出來，形成一個附加用例，以簡化基本用例的結構。利用擴展關系，將附加部分隱含地包含于基本用例中。另請參見指南：業(yè)務用例模型中的擴展關系。如果幾個業(yè)務用例在行為和結構上具有共同點，同時在目的上又很相似，則可以將它們的共同部分分離出來，形成一個基本用例(父用例)，該基本用例被附加用例(子用例)繼承。子

7、用例可以在從父用例繼承的結構中插入新的行為或修改現有的 行為。另請參見指南：業(yè)務用例模型中的用例泛化關系。Through C/心噸登記處的主角和用例。這里，我們還顯示了包含用例"行李處理” (Baggage Handling)和 擴展用例"通過登記處” (Through Check-1 n)。您可以使用主角泛化關系來顯示主角之間的特化情況。另請參見指南：業(yè)務用例模型中的主角泛化關系。另請參見指南：用例模型中關于建立系統(tǒng)用例模型的討論。為建模工作定界特別是當開發(fā)業(yè)務模型只是為了“支持”某個軟件工程項目時， 您需要細致地對業(yè)務建模工作進行定界。在這種情況下，即使只對業(yè)務流程的一

8、部分進行建模，也幾乎不值得涵蓋整個組織。為了能突出重點并產生期望的結果， 應該選擇只將整個公司的一部分視為您的“業(yè)務系統(tǒng)”，而所選部分應該是公司中將直接使用該系統(tǒng)的部分。組織中決定作為模型外部對 待的那部分則可以表示為業(yè)務主角。示例：某公司決定開發(fā)一個用于銷售和訂購管理的新應用程序。為了研究組織的需要，同時調整組織中開展業(yè)務的方式，第一步工作就是構建一套業(yè)務模型。公司中不經常使用新訂購應用程序的部門被當作模型的外部，用業(yè)務主角表示。¥ zContrjd DtpjrtmentCut tom sDr deffFinanceCompanySupplerExecutiveDmes nn Ml

9、Jfa ： r某個訂購管理組織的業(yè)務用例模型中的業(yè)務主角和業(yè)務用例。該組織向每個客戶銷售復雜的定制解決方案。業(yè)務用例的簡要說明：訂購流程(Order Process):該流程描述了公司如何采取適當的行動向客戶提供解決方 案，該解決方案是通過一系列客戶需求確定的。當作出業(yè)務決策，開發(fā)雙方協(xié)商同意的解決 方案時， 流程開始。 這常表現為公司收到客戶的定單。 而當客戶對解決方案的安裝和試運行 表示滿意， 公司收到客戶的付款后， 流程結束。 流程的目標是在滿足客戶需求的同時保證公 司獲利。投標流程 (Proposal Process)： 該流程針對客戶的需求產生一個或多個投標方案。該流 程由客戶的詢問

10、觸發(fā)，當客戶接受(或拒絕) 標書中的報價時結束。目標是協(xié)商確定一個客 戶和公司都可以接受的報價。報價流程 (Quote Process)： 報價流程是一個抽象業(yè)務用例，它包含在投標流程和訂購 流程中。 當客戶要求公司為其需求給出報價時， 報價流程開始。 報價流程的目標是產生一個 滿足客戶需求的解決方案，同時給出這個方案的價格。調查說明業(yè)務用例模型的調查說明應該：概述組織的目的。指出模型的定界 - 模型中不包括的部分以及不包括的原因。 指定主要業(yè)務用例。示例：業(yè)務用例模型覆蓋我們公司管理客戶訂單的部分， 因為只有這部分對軟件工程項目有意 義，它將使用業(yè)務建模的結果作為輸入。 出于這個原因， 我們

11、沒有將公司中負責結賬、 生產、 產品管理和產品開發(fā)的部門包括進來；這些部門作為模型的外部被表示為業(yè)務主角。在該組織中， 一次銷售不僅包括對某個解決方案達成一致， 還包括對該解決方案的構建。 為了給解決方案定價，您需要將其設計并構建到足夠細化的程度。 這就是在 “投標流程”中 所進行的工作。 與客戶達成一致之后， 公司便開始設計解決方案的所有細節(jié)， 然后在客戶方 進行安裝。這就是在 “訂購流程” 中所進行的工作。 “投標流程”和 “訂購流程”都包括 “報 價流程”這個抽象業(yè)務用例。好的業(yè)務用例模型的特征用例符合它們所描述的業(yè)務。 可以找到所有用例。合起來看，用例可以執(zhí)行業(yè)務中的所有活動。 業(yè)務中的每個活動都應包含在至少一個用例中。用例數量和用例大小之間應該保持平衡：較少的用例可以使模型易于理解。用