使用案例分析.pdf

第五章 使用案例分析 第五章 使用案例分析 使用案例(use case)描述需求定義的關鍵元件細節。它能說明在前一章節中系統將會符合功 能需求定義的程序。使用案例建立一個程序模型，以更正式的規定來定義這個商業程序。 目標　 　 　 　 　 　 　 　 　 　 　　 　 　 　 　 　 了解使用案例功用 了解設計使用案例的程序 有能力去設計使用案例 章節概述　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 導論 使用案例 使用案例的元件 建構使用案例 應用概念到CD Selections 辨識主要使用案例 辨識每一個使用案例的主要的步驟 使用案例 辨識各步驟的元件 確認使用案例 修訂需求的定義 摘要 引言 　 　 前一章節討論了決定需求的程序，且產生了需求定義。需求定義(requirements definition) 定義了系統要做什麼。在這個章節中，用符合這些需求的系統和系統中需要被抓取和儲存的資 料，我們討論在一些使用案例中這些需求如何進一步被精製來提供程序上的細節。一旦使用案例 被發展，下一步是使用需求定義和使用案例來為新系統的程序模型和資料模型創造更詳細的程序 和資料描述。 使用案例(use case)是一個比較新的技術。近幾年來，系統分析師能很坦率的坐下來與使用 者交談並且開始繪製程序和資料的模型。然而使用者經常發現要學習由分析師所使用的程序和資 料模型語言是困難的。近年來，許多組織開始和使用者在分析第一次工作時用使用案例方法來產 生複雜程序的簡單文件描述，然後使用這些去建製正式模型。不管是否專案團隊是定義成as-is 模型或to-be 模型，步驟是相同的；但是明顯的，焦點是不同的，鑑於to-be 模型是集中於要求 商業程序，as-is 模型是集中於當前商業程序。 複雜系統的二個步驟方法(使用案例第一，程序和資料模型第二)來自兩各不同部分的系統分 析和設計共同體，如此對於如何以最好的方式，來創造使用案例，產生了兩種不同的觀點。當他 們稱做使用案例的組織使用物件導向技術(見 15 章)時，他們稱做商業方案的組織已被用結構化 設計技術來描述程序。目前商業方案或使用案例並沒有正式的標準，所以我們試著去合併兩種方 1 第五章 使用案例分析 法中，我們相信最好的元件。我們比較適應使用案例(use case)多於商業方案(business scenario)，因為它逐漸的變成流行了。1 在本章節中，我們首次解釋了如何去讀取使用案例且描述它們的基本語法。然後我們描述 用來建製使用案例的程序。 註 1：在 15 章你會看到，物件導向技術促成了本章所描述的文字基礎的使用案例，並且在進行到模型結構和行為 前，創造了使用案例圖表(像是下一章所描述的資料和程序模型)。在沒有物件導向技術的世界，使用案例圖表沒被 設計，所以在本章中省略，它們在 15 章會被描述。我們只集中於使用案例的文字敘述，關於商業方案更多細節的 描述。 使用案例 使用案例(use case)是用來產生一些輸出結果的一組動作。每一使用案例描述出系統如何反 應一次觸發(triggers)系統的事件(event)。例如，在圖書館系統中，一次觸發事件可能是某人借 書、還書或一本書已經到期了。這種的事件驅動模型(event-driven modeling)，系統中的所有事， 可以想成是一些觸發事件的反應。當沒有事件，系統是靜止的，耐心地等待下次事件。來觸發它。 當一個觸發事件發生，系統會反應它，執行在使用案例中所定義的動作且稍後回到等待狀態。 在一些情況中，程序也許很"小"，就像前例中借書的動作被執行一樣。在較複雜的系統中(像 本書CD Sele