狐狸糊塗
10:06:10
請教大家乙個問題：
業務建模應該包括哪些東西？
青潤10:07:14
rup中關於業務建模目的地描述是：
①了解目標組織（將要在其中部署系統的組織）的結構及機制。
②了解目標組織中當前存在的問題並確定改進的可能性。
③確保客戶、終端使用者和開發人員就目標組織達成共識。
④匯出支援目標組織所需的系統需求。
為實現這些目標，業務建模工作流程說明了如何擬定新目標組織的前景，並基於該前景來確定該組織在業務用例模型和業務物件模型中的流程、角色以及職責。
狐狸糊塗
10:08:11
寒，我說錯了。。應該是業務模型包括哪些東西。。而不是建模～
狐狸糊塗
10:08:46
這些東西應該是看得見的。
青潤10:09:09
業務模型，就是乙個模型檔案，你的這個包括那些東西，應該是說：業務模型需要說明哪些問題，才對吧？
狐狸糊塗
10:09:53
我想問的是，應該用哪些東西來描述乙個業務模型。 青潤
10:10:18
噢．呵呵
這樣就明白了，那就是應該用那些符號或者語言來描述業務模型．
狐狸糊塗
10:10:41
對的，我就是想問這個。呵呵。
青潤10:10:44
這在我的書上沒有直接提出來，但是，應該可以看到用到了哪些．
狐狸糊塗
10:11:20
能不能就我自己的意思先描述一下，如果您有時間的話希望能指正一些錯誤，或者遺漏～
青潤10:11:20
業務用例圖，狀態／活**／泳道圖
青潤10:12:11
沒關係，你說，大家的觀點都可以表達出來．
我的做法，只是我的一些體驗，並不一定完全正確．而且，我用到的也不是全部的ｕｍｌ，只是我需要用到的部分而已．
狐狸糊塗
10:13:42
我想的（也是這麼做的）是
: 業務模型應該是由
2個部分構成的，
1是資料模型；
2是業務邏輯（業務流程）
。我做的過程中是由
use case
－－》根據
use case
設計出整個資料模型，然後對應每個
usecase
會由對應設計到的資料模型以及對應的流程（業務邏輯）。
這樣下來就可以把所有的
usecase
通過資料模型＋業務邏輯來描述出來。
同事對每個
usecase
都會由角色的約束。
不知道這樣來做，是否合理？
青潤10:16:39
你的做法和我的方法是相似的，應該沒有什麼問題．
不過，我在對狀態／活**的用法上是有乙個定義的：
狀態圖繪製大的階段或者需要細化的操作；
活**模型繪製小的活動或者被細化的操作細節．
具體的可以在我的書中找到對應的內容．
狐狸糊塗
10:18:44
哦，終於明白了。我就是覺得在我那種方法中，對業務邏輯的描述就容易出現乙個問題。描述的顆粒度的控制。
太大則無法完全描述業務，太細則又顯得臃腫。
原來你是分別用狀態圖和活**來描述不通顆粒度的業務邏輯。
不找到我這樣說是否正確？
青潤10:20:54
基本上差不多．
尤其在ｕｍｌ圖中，ｓｔａｔｅ表示的就是階段或者需要被細化的活動，ａｃｔｉｖｉｔｙ我用來表示不需要被細化的活動和行為．
青潤10:21:58
(此處影象顯示不出來，只好暫時放棄)
就是這兩個圖例
狐狸糊塗
10:22:12
是不是可以這樣理解，
state
描述的是更加泛化的，而
activity
則描述的就是細化的？ 青潤
10:22:17
可以．青潤
10:22:34
乙個ｓｔａｔｅ下面會有多個ｓｔａｔｅ和ａｃｔｉｖｉｔｙ
狐狸糊塗
10:22:41
好的，謝謝青潤～
全程建模 業務用例與用例的對應關係解析
下文中是關於業務用例和用例之間的對應關係的對話，一般來說在一些較大的業務系統或者業務邏輯較為複雜的系統開發中才需要進行單獨的業務建模過程，而對於大多數業務系統是不需要單獨進行這樣的開發階段的。在每次的全程建模的培訓中，青潤都會提出這個過程將業務建模過程進行詳細的分解，但是在 軟體工程之全程建模實現 ...
全程建模 業務用例與用例的對應關係解析
下文中是關於業務用例和用例之間的對應關係的對話，一般來說在一些較大的業務系統或者業務邏輯較為複雜的系統開發中才需要進行單獨的業務建模過程，而對於大多數業務系統是不需要單獨進行這樣的開發階段的。在每次的全程建模的培訓中，青潤都會提出這個過程將業務建模過程進行詳細的分解，但是在 軟體工程之全程建模實現 ...
UML 用例建模技巧
uml 用例建模技巧 從參與者的角度並以主動語態編寫用例。應該以主動語態 學生表明參加研習班意向 而不是被動語態 研習班意向被學生表明 來編寫用例。而且，應該從參與者的角度來編寫用例。畢竟，用例的目的是理解使用者如何對系統進行操作。編寫方案文字，而非功能需求。用例描述的是對參與者來說有價值的一系列行...