延伸Extend一般化Generalization.PPTVIP

I、使用個案塑模-使用個案圖 行為者(Actor) 使用個案(Use Case) 連接線 系統邊界 使用個案間之關係 包含(Include) 延伸(Extend) 一般化(Generalization) 初步的使用個案圖之建構步驟 使用個案圖(Use Case Diagram) 以外部觀察者角度來描述觀察到的系統功能，強調系統能做什麼(what)，而不是如何做(how)這些事。 Use Case：指的是可以使用(Use)系統來處理的個案(Case)。亦即系統提供的功能是什麼(what)？ 使用個案圖的繪製工作就是從需求分析文件中找出Actor、使用個案及使用個案之間的關係。 使用個案圖之元件 1. 行為者(Actor) 是一種角色，為環境中與系統有互動或交換訊息之任何人或物，也是系統外部的參與者。 雖然在使用個案圖中，行為者是以人形來表達，但實際上這個角色不限定是人，也可以是任何組織、物件或相關系統等。 常見的Actor 使用者 系統 時間 Actor：時間(Time) 有時候，驅動系統執行某項功能的原因是因為時間到了。 例如產生月報表這個功能。 如果時間一到便會驅動系統自動來執行，可將這個actor命名為: Time。 Actor：系統(System) 某些情況下，一些特定的功能是由系統自己來驅動。 例如，當一筆訂單確認後，系統須主動寄發email給顧客這個事件。對於這個事件，系統(system)就是actor。 Actor的找法 嘗試回答下列問題： 誰要使用到此系統？ 誰提供這些資訊？ 誰需要這些資訊？ 誰可以改變這些資訊？ 誰可以刪除這些資訊？ 再次強調，「誰」不一定是代表哪些人(可能是時間或系統) 2.使用個案(Use Case) 用以表示使用者與系統之互動，是系統要做的事情，也就是系統中一系列的交易，以完成某一特定工作，並對系統之行為者產生可衡量的價值。 事件與使用個案 事件表是用來表達系統應該提供的功能，也因此，使用個案與事件會有對應上的關係。 如果需求文件是以事件表的方式寫成，你「應該」可以直接就將事件名稱用到使用個案的名稱上。 不過使用個案的命名應該從使用者的觀點來描述。因此，如果事件描述不是從使用者的觀點，那麼你不應該直接拷貝事件的名稱做為使用個案名稱。 請注意：並不是任何的動作都是使用個案！系統所執行的處理中有很多是使用者看不到的。 使用個案找法 最基本的方式就是從事件表開始找起。 有時候，事件的描述可能太細了，那麼你可將一系列相關的事件有組織地集合起來使之成為一個使用個案。 利用事件表，應該可以開始找出許多的使用個案。 另外一個思考方向：有其他系統需要跟本系統互動嗎？ 假設公司中的郵件系統是一個獨立的資訊系統，而你要建立的系統需要寄送email郵件來通知顧客某些事情，那麼這兩個系統就會有互動。 技巧：儘量用actor可以看到的系統功能來進行塑模。 3.連接線 是一條直線，用來連結使用者以及系統執行的功能。 這條連結線表示某個角色的Actor啟動了某個個案 左下圖為使用者瀏覽產品目錄，右下圖為客戶提款 4.系統邊界 系統以一個方形為代表，用以表示系統的邊界。 當開發的系統並不會與其他系統有互動時，我們有時候會省略它。 5.使用個案間之關係 在使用個案圖中，除了Actor、系統、使用個案、連結線之外，使用個案與使用個案之間也可以有關係的存在。 主要可以分為三種 ： 包含(Include) 延伸(Extend) 一般化(Generalization) 5.1 包含(Include)關係 可視為一種委派(Delegation)或是整合(Aggregation) 若某一使用個案「A」一定會用到另一使用個案「B」，則稱A 委派或整合B (A Include B)，關係之箭頭符號由A 指向B。 包含(Include)之實例 提款 對於一個ATM系統，「提款」這個使用個案一定會包含「更新帳戶餘額」使用個案： 「跨行轉帳」也會用到「更新帳戶餘額」 包含關係的好處 當你發現許多個使用個案，都共用一些相同的功能時，你可以把此功能獨立出來，讓它自成一個個案 其他的使用個案只需要包含它就可以了 (可以不需要在不同的地方重複描述同一個使用個案) 5.2 延伸(Extend)關係 在某些情況或條件下(延伸點, extension point)，一個使用個案的行為，可被另一個使用個案的行為所延伸。 在某些情況或條件成立之下，使用個案B會去執行使用個案A，我們稱A在特定情況下為B的Extension (A Extend B)，關係之箭頭符號由A指向B 延伸(Extend)關係之實例 下訂單案例 使用者可以下訂單，系統會先檢查庫存有無貨品。若已無存貨，系統要執行訂貨。 「訂貨」這個使用個案，延伸了「下訂單