使用案例(Use Case)是表達系統的外觀，即系統功能，以滿足參與者使用系統的目的。
使用案例是需求分析很重要的關鍵技術，也是採用以物件導向思維的方式來開發系統的重要前導工具。但請記得，使用案例無法表達系統內部的結構(Structure)。
系統內部有其結構的分析與設計。以物件導向思維的模式來開發系統時，結構的分析與設計即在於建立物件模型(Object Model)，並利用互動(interaction)圖來描述物件之間的合作情形。
我們可以把使用案例當作是一個個小型的迷你系統，然後利用如下圖的表達方式，即以虛線的橢圓形連結實線的橢圓形，其內的名稱均填上同樣的使用案例名稱，例如 “Place Orader”。
虛線的橢圓形表達其內有許多各類不同角色的物件來參與完成，或稱之為實現(Realize)使用案例。
所以，虛線的橢圓形所參與的物件，已經牽涉到了系統內部的結構分析與設計。
觀察下圖，會發現參與實現使用案例的物件有不同的圖示表達，也就代表了系統內部的物件，不僅僅是從功能面來區分物件，更因為是觀察系統變更的程度而區分出物件的生命週期：
- 處於系統及它的參與者(Actors)之間的界限(boundary)。
- 系統使用的資訊(information)。
- 系統的控制邏輯(control logic)。
- 擔負控制邏輯的責任，是為 “控制物件(Control Object)”。
- 基於擔負著分隔變動週期界線，是為 “邊界物件(Boundary Object)”。例如 UI Form 物件、負責連結資料庫的永續性物件(persistent object)。
- 擔負領域(Domain)內企業邏輯(Business logic)的物件，稱之為 “實體或本質(Entity)物件”。整個物件群中，實體物件具最穩定的本質，因為一般它與領域上的概念(Domain Concept)是一致的，所以可重用性(Reuse) 的程度也是最高的。
使用案例的實現會包含上述三種分析類別的參與，使得系統更具彈性度與延展性。
請問虛線的使用案例，目的是不是像是用放大鏡來檢視實線的使用案例中的結構而已？
如果是這樣，我覺得虛線使用案例的存在似乎有點多餘
還是說這是 OMG 制定的標準畫法？
還有，虛線使用案例對於 “可執行的 UML” 是不是很重要？(雖然我不太相信 UML 可執行)
謝謝!
1. 虛線的表達並不是用來檢驗使用案例的結構，注意兩者之間的關聯是利用 “realize(實現)” 來表達的。也就是說，虛線的 collaboration，實現使用案例的功能。
2.collaboration，顧名思義，就隱含了虛線內部的元素，是由一到多個物件 (instance)來共同互動合作完成使用案例的功能。
3. 沒有這種 “可執行的 UML” 這類說法，這邊你想太多囉~
4. 個人從來都把 UML 建議為草稿式 (draft)的表達、而非藍圖式的精確語法；所以，上述利用 “realize” 串聯 UC 與 實現的合作，並沒有所謂的標準語法；這僅是當初 RUP 的一種建議表達方式、而許多 UML 工具有支援其表達的語法罷了。
5. 再次提醒，UML 是用來表達個人、團隊的設計想法，”設計意涵” 會來得比 UML 語法重要太多太多了。
嗯~”設計意涵” 這詞用得巧妙~我喜歡!
我也是覺得用草稿式的表達方式就夠了
只是有時仍會不小心掉入藍圖式的陷阱
或許是從PG出身有關吧，思維還沒完全轉換過來 XD
PS. Executable UML 一詞是有的，跟藍圖式是一樣的意思~交流一下 😛
呵呵， “Executable UML” 這類字眼在我看來是騙小朋友的。 ^^
多年來的觀察，絕大數軟體開發人員不是不會寫程式，而是並不容易具備 結構/架構 性。
這個基礎功夫要沒有養成，即使利用 Notation 產出可執行的 AP，那有甚麼意義呢？
我還是不厭其煩的再強調一次：會寫 Code 與 懂 UML 語法並不代表你就具備了軟體設計與規劃的基礎功夫；如何讓 Code 具清晰的結構，以及如何利用 UML 表達出設計思維，這才是軟體開發需要的真功夫。
本末可切不能倒置。
Kenming你好：
我看完frankie 提問的你的回覆後，還是不能分辦控制物件是不是企業物件耶？還是說控制物件是MVC架構中的Control層，而企業物件是Model層？然後像存取db的DAO是邊界物件？而實體物件就是hibernate 或jpa 中entity 物件(也就是對應table的映射文件)？
謝射 ~~
karen 妳的推論全都正確 ^^
大概再補充一下。
1. 控制物件的確就是擔任 MVC 的 Controller，不過，它也有可能在簡化設計的情況下，而同時擔任 BPO (Business Process Object) 的角色。
2. 企業物件 (business object)的確就是所謂的 Model 層，而存取外部系統的 Adapter 與 存取 DB 的 DAO 都是屬於 邊界(Boundary)物件。
3. 透過 O-R Famework mapping 而來的物件，在 Java 族群這邊可能是稱為 Entity 物件，不過我會比較避免用這樣的用語。我會直接把這類的物件稱為 “Value” or “Data” Object，就僅是資料的物件型態而已。
4. Entity 這個術語，應該算是 Domain 的術語。而從具化的角度來看，它其實就是位於 Middleware 的企業物件，與位於 DB 的 Entity Table。兩者的本質都是源自於 Domain 而來的。而只是兩者的主要差別就在於企業物件具有行為處理的責任，而 Entity Table 則是狀態的儲存。 現實的分離主要是因為實體技術的限制。
很高興 karen 能提出這類有意義的問題。 🙂
可否更清楚的描述企業邏輯的物件及控制物件的定義，最好能舉例 ?
謝謝 ~
請參考我這一篇：「{程序員邀稿} 以架構為中心的主要設計產出(2)」。
其中：
中間層：領域物件模型主要所在的位置。為了應付功能性需求，UI 端的功能性呼叫(functional call)是透過中間層的控制物件(Co, Control Object)來控制與協調為完成該功能所需要相關領域物件互動參與的資訊與企業邏輯(business logic)運算；為了隔離外部系統(包括資料庫與外部系統)的變動性，控制物件會透過 邊界類型的物件(boundary object)，如永續性物件(PO, Persistent Object)，連結資料庫系統、調變性物件(AO, Adapter Object)，連結外部系統，如 Mainframe, Message Quese System, 其它需透過介面(interface)傳遞的系統等，來取得外部系統的資訊。
而真正軟體的主結構，其實就是落在 Domain 物件(在中間層稱之為企業物件，Bo, Business Object)上，也就是源自於問題領域的概念性物件，以滿足應用程式的需求。所謂的軟體結構分析設計人員，其實就是應該要聚焦在如何作好領域物件的結構分析與設計！