Ivar Jacobson 如何把使用者目標接到軟體流程？Use Cases、OOSE、UML 與 RUP

先講結論：Ivar Jacobson 把使用者目標轉成可追蹤的 Use Case，並透過 OOSE、Objectory、UML、RUP 與 Essence 連接需求、分析、設計、開發與驗收；Use Case 是需求視角，不是完整規格或流程保證。

Q：Ivar Jacobson 主要貢獻是什麼？ A：他是軟體工程方法論先驅，推動 Use Case、OOSE、Objectory，並參與 UML、RUP 與 Essence 的發展。

Q：Use Case 解決什麼問題？ A：它描述參與者、目標、系統邊界、基本流程、例外流程與替代路徑，讓需求從抽象願望變成可討論行為。

Q：Use Case 不是什麼？ A：它不是單純功能清單，也不是畫一個橢圓就完成的文件；它不能取代領域模型、非功能需求、介面契約與驗收測試。

Q：OOSE 如何接上軟體流程？ A：OOSE 把使用者目標連到物件、互動與責任，讓需求分析能逐步轉成設計、實作與測試工作。

Q：UML 和 Use Case 的關係是什麼？ A：UML 提供共同的模型語言，Use Case 是描述使用者與系統互動的一種視角，還需要類別、活動、狀態與部署等其他模型互相配合。

Q：RUP 和 UML 是同一件事嗎？ A：不是。UML 是建模語言，RUP 是包含角色、工件、活動與反覆迭代的軟體開發流程框架；兩者可一起使用但層次不同。

Q：Use Case 如何幫助驗收？ A：每個目標與流程可轉成情境、例外案例和測試條件，讓團隊檢查系統是否真的完成使用者要做的事。

Q：這套方法有哪些限制？ A：若只寫理想流程而忽略效能、安全、資料、可用性與維運，Use Case 會留下重要風險；需求也需要持續和實作、使用者回饋對照。

Q：圖片與文章的關係是什麼？ A：圖片是 Ivar Jacobson、Use Case、OOSE、UML、RUP 與使用者目標分析的主題路線圖，不是某個團隊的完整 RUP 專案計畫或 UML 規格截圖。

增量補充：Use Case 的核心是目標與可驗收行為

Ivar Jacobson International 將 Ivar Jacobson 的工作與 Use Case、元件架構、UML、RUP 及方法工程連在一起。這支持本文把 Use Case 視為把使用者目標接到工程流程的工具；但一個 Use Case 不是單純的功能清單，也不能取代領域模型、非功能需求與驗收測試。來源：Ivar Jacobson International — Dr. Ivar Jacobson。

寫得好的 Use Case 應能回答：誰在什麼情境下想完成什麼目標？系統提供哪些可觀察回應？哪些例外會讓流程改道？完成條件如何被測試？把這些資訊保留下來，Use Case 才能成為產品、設計、開發與測試之間的追蹤線，而不是只在需求簡報出現一次的橢圓圖。

先講結論

Ivar Jacobson 把使用者目標變成可討論、可切分、可追蹤的軟體工程工作。Use Case、OOSE、Objectory 後來又連到 UML、RUP 與 Essence。

Ivar Jacobson 是誰？

Ivar Jacobson 是瑞典電腦科學家與軟體工程師，取得 KTH Royal Institute of Technology 博士學位。Ivar Jacobson International 的人物資料把他描述為元件與元件架構、Use Case、Objectory、Rational Unified Process、UML 及 SEMAT／Essence 的重要推動者。這些說法來自其機構資料；文章仍應把「共同創造」和「單獨發明」區分開來。

Use Case 解決了什麼問題？

傳統需求文件很容易從系統內部功能開始：要建立哪個資料表、呼叫哪支 API、畫哪個畫面。但使用者真正關心的是目標與結果，例如「提交報名」「恢復帳號」或「查詢訂單」。Use Case 先描述參與者、目標、基本流程與例外，再把這些內容交給分析、設計、測試與產品決策共同使用。

這不是把所有需求都寫成故事，而是把系統邊界和成功條件說清楚。好的 Use Case 可以回答：誰在什麼情境下啟動？系統要回應什麼？失敗時有哪些替代路徑？哪些條件仍需要業務或安全規則補充？

OOSE、Objectory、UML 與 RUP 怎麼連在一起？

1. OOSE：以使用情境驅動物件導向分析

Object-Oriented Software Engineering（OOSE）把 Use Case 放在需求與設計的連接處，讓團隊能從使用者目標逐步推導物件、責任與協作。重要的不是記住一套圖，而是保留「需求如何影響設計」的可追溯鏈。

2. Objectory：把方法變成可重複的流程資產

Objectory 是 Jacobson 早期方法與公司脈絡的一部分。它把 Use Case、物件模型與迭代式開發連在一起，讓軟體團隊有一套可以反覆使用、教學和調整的工程方法。

3. UML 與 RUP：共同語言與流程骨架

Jacobson International 的人物資料指出，Jacobson 是 UML 三位原始開發者之一，Objectory 在 1995 年被 Rational Software 收購後，相關工作又與 UML 和 Rational Unified Process（RUP）發展相連。這不代表 UML 是 Jacobson 一人創造，也不代表 RUP 是每個團隊都必須照抄的流程；更精確的理解是，Use Case、模型語言與迭代流程在產業中逐步整合。

Use Case 2.0 為什麼仍有價值？

Ivar Jacobson International 的 Use-Case 2.0 文件把 Use Case 拆成可以逐步交付的 use-case slice。這種做法試圖保留使用者目標的完整脈絡，同時讓團隊能以小批次切出可實作、可驗證的部分。

它對現代產品團隊的價值不在於回到厚重文件，而在於避免兩種斷裂：一是使用者故事只剩短句，失去整體目標；二是規格文件很完整，卻無法對應可驗收的行為。Use-case slice 可以作為需求、設計、測試與迭代之間的中介，但仍需要團隊自己決定粒度。

常見誤解與限制

Use Case 不是 UI 操作腳本。 它描述參與者目標與系統回應，畫面只是其中一種實作。
UML 不是完整開發流程。 UML 提供模型語言；RUP、敏捷方法或團隊實踐才處理工作節奏與治理。
RUP 不是瀑布法的同義詞。 它強調迭代與風險導向，但實際導入方式仍取決於組織與產品。
Use Case 不會自動消除需求歧義。 例外、非功能需求、權限、資料品質與安全界線仍要由團隊補足。

常見問題

Ivar Jacobson 發明了 UML 嗎？

不是單獨發明。Jacobson 是 UML 三位原始開發者之一，另外兩位是 Grady Booch 與 James Rumbaugh；UML 的形成也涉及 Rational Software 與 OMG 標準化過程。

Use Case 和 User Story 一樣嗎？

不完全一樣。Use Case 通常保留參與者、目標、基本流程與例外的系統脈絡；User Story 往往是敏捷待辦中的較小需求切片。兩者可以互補，不能只用名稱判斷粒度。

RUP 現在還值得學嗎？

值得把它當成需求、風險、迭代與模型治理的歷史資源，但不必原封不動導入。團隊應挑選能改善目標澄清、驗收與協作的實踐，再用現代工具與節奏落地。

時間線

1980–1990 年代：Jacobson 發展以 Use Case 驅動的 OOSE／Objectory 方法。
1995 年後：Objectory 被 Rational Software 收購，相關方法與 UML、RUP 發展接軌。
2000 年代：Jacobson 持續推動輕量、可組合的軟體工程實踐。
2023–2024 年：Ivar Jacobson International 公開 Use-Case 2.0／3.0 文件，延伸 use-case slice 與實踐導向的方法。

Ivar Jacobson 如何把使用者目標接到軟體流程？Use Cases、OOSE、UML 與 RUP