Use Cas Modeling (2) - Fundamentals of Use Case Modeling

Use Case Modeling 有其強盛的優點，卻也有其明顯可見的問題所在，其中優點是我們可以使用一系列的UC 捕捉的形式來健全我們的modeling 活動，

而缺點是我們很容易的淪落到去假設 UC modeling 就只是把圖畫一畫，這很容易讓剛開始接觸到UC的人產生誤解。

特別要強調的一點是，Use Case 的整體核心價值，不在於圖形而是其所併同撰寫的使用者案例敘述，此敘述完整描繪了整個Use Case所需要企及的目標以及過程手段等資訊。

---

The USE-CASE Model - a semantically closed abstraction of a subject system

 

從一個特定的角度來看，模型Model是一個完整的系統描述，在這裡我們要強調的是完整是指Model本身就已經俱足了足夠的資訊，而我們不用在額外的去添增其他輔助資訊才能讓我們懂得這個model到底在做啥。

不過對於UC Model而言，UC本身並不足以提供所有相應的資訊，他仍然需要其他的手法或工具來協助獲取，Use Cases主要是將系統需求上下文獲取，然後將functional requirements的部份給全數涵蓋進來，這裡我們並不處理 Non-functional requirements的議題，這些事留待其他部分才進行。

所以 給個小定義 --> A model that describes the functional requirements of a system or other classifier in terms of use cases...

 

同時在定義上也提到：

• A use-case model is a model of a system defined in terms of use cases, actors, and the relationship between them


• A use-case model can contain, and is often represented by, a set of use-case diagrams

---

The Basic building blocks of a use-case model (建構 Use Case Model 的基本元素) 

• Actor - An Actor defines a role that a user can play when interacting with the system. A user can either be an individual or another System

特別要注意的是，Actor 通常指的是使用者所扮演的角色而非我們會不小心就引用的職務名稱進去，這是一件天大的錯誤。

在UML中對於actor的更標準的定義是： A coherent set of roles that users of use cases play when interacting with these use cases

• 用來呈現使用者或者其他系統


• 定義出使用者在與Use Cases 互動過程中所扮演的角色


• 如果是外部的系統型態，那麼應該是排除於目前系統的控制範圍


• 訴諸其需求，使得系統本身是可提供Actor 所需要的服務

• Use Cases


• 
  
  
  
  • 被參與者觸發啟動
  
  
  • 由系統所提供的功能(服務)
  
  
  • 可以同時有多個參與者(支援者)
  
  
  • 描述系統是如何地與起動者之間互動的來完成啟動者的目標
  
  
  • 提供一整組的藍圖來描繪系統如何被使用，以及是如何辦到的
  
  
  
  

A use case describes how an actor uses a system to achieve a goal and what the system does for the actor to achieve that goal.

It tells the story of how the system and its actors collaborate to deliver something of value for at least one of the actors.

在actor 與  Use Cases 之間的連接線我們用的是 association，但這裡的連接線有區分成兩類型，一種是單純的實線，另一種是帶有箭頭的實線，帶有箭頭的是表示由誰來啟動。

但切忌一件事情，連接線很容易被誤以為是 data flow ，這完全不正確。

• Use Case Narrative

Brief descriptions , 每一個actor以及其使用者案例都需要有一個對這幾個元素的簡單描述，讓人知道他們到底是在幹啥用的，尤其在團隊開發模式的時候，RA / SA 一開始就得先把 Actor 與 UC 的定義列清楚，免得不同人看到這些東西都只會變成是自己在猜想、瞎猜這樣的狀況，導致整體想法完全不一樣。

但描述的東西也不是像在寫小說或散文那樣的落落長，應把握簡潔完整的原則來撰寫，包含必要性的主詞、動詞、受詞，去除多餘的情境描繪與感官描述。

在撰寫UC-Narrative的時候，很早之前有個叫做Alistair Cockburn的先驅曾經提出，在描繪UC的案例敘述時應該使用18個屬性來記錄這些議題，他將之稱為 Use Case Properties。不過在現今的需求捕捉模式下，也許我們最起碼需要抓以下這幾種：(全部的介紹會放在 ch 7 )

• Flow of Events


• 
  
  
  
  • The Basic Flow
  
  
  • The Alternative Flows - optional behavior and variations on a theme
  
  
  • The Alternative Flows - Exceptions / Error conditions
  
  
  • Sub flows - The requirements elaboration into a set of individual actions and response.
  
  
  
  


• Pre-Conditions / Post-Conditions


• 
  
  
  
  • 前置條件指的是在執行此UC前必須滿足的最小條件需求，通常會提供一段資訊描述。
  
  
  • 後置條件是表達 當完成此UC執行後，系統的當前狀態需要是什麼樣的規格或限制。
  
  
  • 後置條件必須在當你alternative flow被觸發，都必須能符合此限制條件，否則這個後置條件就不正確了
  
  
  
  

底下這段是原文對於post-condition的描述，可是我還是覺得怪怪的：

A post-condition for a use case should be true regardless of which alternative flows were executed;

it should not be true only for the basic flow.

為何在basic flow 的執行結果，不見得會滿足 post-condition ? 還是我英文的理解能力太弱XD

在描述完成 Use Case Narrative之後，也可以補充一個狀態機的圖，用以輔助說明  pre-cond 與 post-cond ，在各種不同的 flow event 的執行結果的關係

• Supporting artifacts - The glossary is the only artifact used to capture the business domain of the project.


• 
  
  
  
  • Glossary - Simple textual glossary , 通常是把rfp , 或者蒐集得來的文件內容當中，把domain 術語或者名詞給蒐整起來，做一個標準化以及統一定義用途
  
  
  • Domain Model - A formal domain model
  
  
  • A textual glossary with illustrative domain model(s)
  
  
  
  

Domain model 是 Business Object Model 的子集合，這個定義是Jacobson在 "The Object Advantage"一書當中所提及的。

他說到，如果business object model不存在的話，那麼 business modeling 必須被進行用以確保我們真的知道business 以及其行為內涵。

當然我們也可以一開始就直接用瞎猜的方式來構築Domain Model，小範圍的可能沒啥問題，但如果架構範圍太大則很容易出一堆包。

好的，那麼glossary的用途是幹嘛的? 其實最主要的就是要來陳述這個UC 所要表達的核心內涵，如下：

1. Understanding the Context of the Project


2. Creating Use Cases and other requirements Documentation


3. Designing the resulting system


4. Producing the user documentation

我們該怎麼去找出這些 glossary ? 仔細聆聽StakeHolder常常提到的，或者是開發團隊常用的語彙，然後注意一件事情，只捕捉 單數名詞，而非複數名詞。

將這些彙整而來的glossary讓所有參與的成員都清楚知道其定義，確保沒有人混淆，而這些glossary 的蒐整也是為了建立從 actor 與 use case 之間的collaboration，捕捉其 business model，

如此才可將範圍限縮在有效合理的Modeling 過程，否則 過多或過少都會是一種負擔。換句話說，如果你發現你的glossary並不在 actor or use case 之間的描述中看的到，就意味著你的UC 捕捉有缺漏，需要再次檢閱。

• Supplementary Specifications - capturing the non-functional requirements , 只是這不是去捕捉單一個uc 的需要，而是為了整體需要的設置

在捕捉需求的過程中，有些東西可能無法被你明確的用文字給描述下來，而這類的 supplementary requirements 捕捉了那些不在UC裡面描繪的系統需求，有包括了以下幾種：

1. Legal and regulatory requirements - ex: The customer must be of legal age to purchase alcohol


2. Application development standards - ex: The system must be developed in accordance with the RUP methodology


3. The quality attributes of the system to be built, including usability, reliability, performance, and supportability requirements


4. The Constraints placed on the design and implementation of the system, such as OS , environments, compatibility requirements, programming languages, and other design constraints


5. Other requirements that dont fit naturally into the use cases - ex : 當系統idle過久超過20分鐘之後的話，要先給點提示警示訊息，若之後還是沒反應就中斷交易與連線

Q : 那我們都該怎麼地來挑選出 supplementary specifications ?

A : 把 System shall / must 的議題 給抓到SS 去是比較好的選擇，只是說要取得他的balance就是。