面向對象技術之需求分析：usecase圖

一、Usecase圖的歷史與黑盒視角

1.用況圖的歷史

l1987年，I.Jacbson首先提出

l得到了許多方法學的采納

l90年代末被UML采納并標準化

2.系統邊界

l黑盒：系統對外部的客觀世界發揮什么作用，提供什么業務功能來展現系統

l白盒：系統如何提供業務功能的。

n問題的提出：在系統尚未存在時，如何描繪用戶需要一個什么樣的系統？如何規范地定義用戶需求？

n考慮問題的思路：把系統看作一個黑箱，看它對外部的客觀世界發揮什么作用，描述它外部可見的行為。

系統邊界與參與者

l系統邊界：一個系統所包含的所有系統成分與系統以外各種事物的分界線。

l系統：是由“用戶”使用的軟件，以及所有與其相關的硬件。指被開發的計算機軟硬件系統，不是指現實世界的系統。

l系統成分：在OOA和OOD中定義，在編程時加以實現的系統元素——對象系統邊界與參與者

l參與者：在系統邊界以外，與系統進行交互的事物——人員、設備、外系統

   注意問題：

 l系統是指被開發的計算機軟硬件系統自身。

 l問題域中的某些事物將作為參與者處理。

 l原來已經存在的系統，看作是一個外系統。

 l子系統彼此之間都可以互為外系統。

   現實世界中的事物與系統的關系包括如下幾種情況：

 l某些事物位于系統邊界內，作為系統成分。

 l某些事物位于系統邊界外，作為參與者。

 l某些事物可能既作為參與者，有作為系統成分。

 l某些事物既不作為參與者，又不作為系統成分。

二、參與者的概念、分類與關系

   參與者

 l簡而言之，參與者是在系統之外的與系統進行交互的任何事物。

 l定義：參與者模型系統之外的實體，當外部實體與系統交互時，它就扮演某一特定參與者的角色。

n參與者可以發出對系統服務的請求

n按系統的要求提供服務

n通過參與者和系統之間服務請求的復雜對話與系統交互

n所有參與者的請求/響應的完全集構成了可以察覺到的系統的問題域邊界。

n一個參與者的一個實例代表以一種特定的方式與系統進行的單獨的交互。

n盡管在模型中使用參與者，但參與者實際上并不是系統的一部分。它們存在于系統之外。

   參與者之間的泛化關系

 2一些參與者可能具有共同的對系統調用的請求。

一種做法是顯式地將這樣相同的每一個請求與每一個參與者相關聯。（不推薦）

 2如果一組參與者具有共同的性質，可以把這些性質抽取出來放在另一個參與者中，它們再從中繼承，把這種關系稱為參與者之間的泛化關系。

 2定義：從參與者A到參與者B之間的泛化關系是指，A的實例能與和B實例進行通訊的用況實例進行通信。

       450

三、識別參與者的策略與技巧

   識別參與者

   1.首先將精力集中于啟動系統行為的參與者。

   2.從用戶、外部系統和設備三個方面發現參與者。

   3.通過識別一般的或較特殊的角色來組織參與者。

   用戶、外部系統與設備

   用戶

從直接使用系統的人員中發現參與者

這里強調的是直接使用，而不是間接的。

特定的人，在系統中可扮演不同的角色。

是用戶角色的類別

   外部系統

所有與系統交互的外部應用系統都是參與者

ü外部應用系統可以是其他子系統，上級系統或任何與它進行協作的系統。

   設備

識別所有與系統交互的設備

ü與系統相連的設備

ü向系統提供外界信息或系統的控制下運行。

ü通常，不包括監視器、鍵盤、鼠標和其他的標準的用戶接口類型設備。

ü考慮外部傳感器（輸入信息）和受控馬達（輸出信息）。

       外部事件

 l當我們構造實時和異步交互的系統時，將外部事件識別為潛在的參與者就變的更加重要。

   例如，由時間的流逝而激發系統的活動是常見的情況。可以把時間事件作為一個參與者，也可以把時間事件作為系統的一部分。

四、用況與簡單案例

   用況

   定義：用況是對參與者使用系統的一項功能時所進行的交互過程的描述。

   A use case is a special sequence of transactions, performed by auser and a system in a dialogue.[Jacobson 1987]

   使用用況的原因

ü用況是對用戶需求（主要是功能需求）的規范化的描述。

ü為領域專家、最終用戶和開發者提供一種相互交流的手段。

ü為開發者提供一種認識和理解系統的方法。

ü用況是開發期間隨著演化而測試每個元素的基礎。

   用況與參與者之間的關系

       定義：關聯是參與者在用況中的參與（也就是參與者實例與用況實例之間的相互通信）。

       若沒有進行特殊的說明，任何一方都可以發送和接受消息。

       這是參與者和用況之間的唯一關系。交互是雙向的，參與者能夠產生對系統的請求，或系統要求參與者采取的某些動作。

       把參與者和用況之間的關聯表示成參與者和用況之間的一條實線。

   例1：語音郵件系統

       在語音郵件系統中，當有人撥打一個號碼時，如果沒有人接聽此電話，此人便留下信息。以后，該信息那個被另一個人檢索到并進行保留或刪除。

    一個用況可能同多個參與者交互

       參與者之間通過系統實時交互

       參與者之間與系統處于同一控制流

   例2：選課系統

   在選課系統中，學生登錄后可以查詢所有的課程，并選擇所要修的課程，也可以放棄已經選擇的課程，教務員登錄后可以加入新的課程，刪除一門課程，并可以與指導者一起審查學生所選的課程，如果不合適，則取消其所選的課程。

五、用況參與者及用況之間的關系與案例

   用況之間的關系——擴展關系

定義：從用況A到用況B的擴展關系是指，用況B的實例是可以被用況A指定的行為擴充（服從于在擴展中指定的特殊條件）。行為被插入到由B中的擴展點定義的位置。

通過敞開的虛線箭頭表示用況之間的擴展關系，該箭頭從提供擴展的用況指向基用況。這個箭頭用關鍵字<<extend>>標記。可以在這個關鍵字附近表示這個關系的條件。

擴展點是用況中的一個位置，在該位置上，可以插入另外一些用況的動作序列。

在一個用況中，每一個擴展點的名字是唯一。

可以把擴展點列在用況中的一個題頭為“擴展點”的分欄中。以一種適當的方式給出擴展點的位置描述，通常采用普通的文本。

   用況之間的關系——包含關系

定義：從用況A到用況B的包含關系表明，用況A的一個實例也包含了用況B所指向的行為。在用況A中定義的位置包含該行為。

通過一個敞開的虛線箭頭表示用況之間的包含關系，該箭頭從基用況指向被包含的用況。這個箭頭用關鍵字<<include>>標記。

包含關系使得我們在一個用況中局部化多個用況中共同的活動序列。這樣，可以避免多次描述同一事件流；當這個共同的序列發生變化時，這樣就顯示出優勢，即只需要在一個地方進行改動。

六、不同學者對包含關系與擴展關系的區別

   觀點1

       相同點

n都是不完整的

n都離不開基本用況

n都可實現為子程序

   不同點

n方向不同

n1對多選包含關系（1個子用況，多個主用況）

n多對1選擴展（多個子用況，1個主用況）

n包含處理一般的情況（調用時，為無條件調用）

n擴展處理特殊的情況（調用時，為有條件調用）

   觀點2

        Maksimchuk &Naiburg, UML for Mere Mortals,2005

   觀點3

        Usecases-Yesterday, today, and tomorrow, Ivar Jacobson

       相同點

nExtensions/inclusions that are concrete use cases.（擴展/包含是具體的用況）

nExtensions/inclusions that are just fragments of a use case.（擴展/包含是用況的一部分）

nExtensions/inclusions use cases are both related to a base use case.（擴展/包含相關的用況都是基本用況）

nWhen the usecase instance has come to the end of the extension orthe inclusion use case, it will return to the base use case and to the positionin the flow described in the base use case, where it left off.

   不同點

nThe major difference between extension and inclusion use cases isthe way that use case instance is instructed to interrupt the base use case andinstead follow the extension or inclusion use case.

nIn the case of inclusion, the base flow itself explicitly instructsthe use-case instance to obey the inclusion use case.

nIn the case of extension, the base flow doesn’t specify theinterruption; instead, the extension use case specifies where in the base usecase the use case instance shall make the interruption.

   觀點4

        UML Distilled，MartinFowler

        當在兩個或多個獨立usecase中重復自己并希望避免重復時，使用包含。

        當表述關于正常行為的一個變化情形并希望臨時表述時，使用泛化。

        當表述正常行為的一個變化情形并希望使用更為受控的形式在基本usecase中說明擴展點時，使用擴展。

   觀點5

        面向對象的系統分析，邵維忠，楊芙清

        語義差別甚微

        實踐中很容易相混

        為什么沒有包含點

        方向不同

七、用況之間的泛化關系、用況的詳細描述、識別策略與注意問題

   泛化關系

子用況繼承父用況的行為和含義。

子用況還可以增加或覆蓋父用況的行為。

子用況可以出現在父用況出現的任何位置。

用一個指向父用況的帶有封閉的空心箭頭的實線來表示用況之間的泛化關系。

參與者泛化與用況泛化的混合使用

       用況分類

 l高層用況和低層用況

  2高層用況描述對有價值的功能所提供的要素做了總的、簡要的描述，并不考慮這些有價值的功能是怎樣獲得的。（usecase圖）

  2低層用況描述提供了表示活動、任務或變化的確切順序的業務細節。（用況的詳細描述）

 l本質用況和具體用況

  2本質用況是獨立于實現的（硬件的和軟件的）業務解；

  2具體用況是依賴設計的。

 l主要用況與次要用況

  2主要用況捕獲系統的主要業務功能。

  2次要用況處理不常見的和例外的情況。可選用況表示可以處理也可以不處理的用況。

   用況是對場景的概括

   捕捉用況的策略

   1.首先寫下兩個或三個最常見的簡單場景（用況）。

   2.當有兩個或三個場景看上去很相似的時候，就試著產生更“抽象”的場景（用況）。

   3.應謹慎選擇用于不常見時間的附加的用況，并保持在可管理的數量上。

   4.以增量的方式進行分析。

  2首先開發主要的、高層的用況模型。

  2然后使用該模型開發主要的、本質的用況模型。

  2進一步地使用所得到的模型指導開發次要的、本質的用況。

  2……

  2最后，使用該模型開發次要的、具體的用況。

   用況文檔模版

       用況名

       描述：對該用況的一句或兩句的描述。

       參與者：識別參與用況的參與者。

       包含：識別該用況所包含的用況。

       擴展：識別該用況可以擴展的用況。

       泛化：若該用況是子用況，則要說明它的父用況。

       前置條件：啟動此用況所必須具備的條件。

       細節：識別該用況的細節。

       后置條件：識別在該用況結束時確保成立的條件。

       例外：識別在該用況的執行的過程中可能引起的例外。

       限制：識別在應用中可能出現的任何限制。

       注釋：提供可能對該用況是重要的任何附加信息。

   舉例：

   例：網上職位分布系統

       網上職位發布系統中，職位發布員編輯準備發布的職位名稱，職位要求，招聘人數等信息，預覽一下其發布職位的版式，在通過權限檢查后，方可在網上發布。除了一般類型的職位發布外，還有一種特效職位發布，允許職位發布員發布自定制的圖片/頁面等。

   用況詳細描述

   用況詳細描述的三種方式

   詳細描述用況的問題

 2沒有系統

 2沒有參與者

 2過多的用戶界面細節

 2過低的目標級別

八、用況圖的應用場合、復雜案例與建模要點

   用況圖在軟件生命周期中的運用

 2主要用來明確需求

 2用來輔助分析

 2用來輔助設計，特別是用戶界面的設計

 2用來測試

   用況分組

   當許多用況具有同樣的功能或者以同樣的方式相互聯系，就將它們歸在一起。UML的包表示了用況的聚類。

   分組的依據

 2同樣的參與者

 2共同的實體

   書：讀者管理員

 2特定的工作流

   審查

 2參與者

確定系統環境中的所有角色，并都歸入了相應的參與者。

每個參與者都至少和一個用況關聯；

若一個參與者是另一個參與者的一部分，把它們合并；

若兩個參與者相對于系統而言，扮演了類似的角色，應該在它們之間使用泛化關系。

 2用況

每個用況都至少和一個參與者關聯；

若兩個用況有相同或相似的序列，可能需要合并它們，或抽取出一個新用況，在它們之間使用包含、擴展或泛化關系。

若用況過于復雜，為了易于理解，考慮進行分解；若一個用況中有完全不同的事件流，最好把她分解成不同的用況。

    例：

       持卡用戶在銀行ATM機上進行查詢/取款/轉賬等業務。若ATM發現用戶連輸三次密碼不對，該卡已經掛失或忘記取卡，則吞卡。檢測到無效卡則退卡。每到午夜12點。統計該日的取款總額并發送到總部系統，機內無現金是幾時通知總部系統。

   用況建模的注意事項

 2應確保不僅領域專家而且程序員都能夠理解每一種用況所描述的系統使用的重要意義。

 2定義用況文本時，應準確和一致地使用名詞和動詞

 2區分出在用況之間/參與者之間的關系

 2大量的用況應該組織為包

九、用況驅動的方法研究，及用況與用戶故事、場景、業務用況的比較研究

   用況圖的研究

       用況驅動的軟件開發

2積極意義

有助于分析模型、設計模型的建立

有助于改進分析、設計以及實現與測試

2問題

對用況依賴過高

導致功能分解的老路