電子商務項目-需求分析與建模第二部分

關鍵字：uml

四、UML中的用例及用例圖概述

（1）用例及用例圖產生的技術背景概述

在軟件系統的分析與設計中，必須要了解并準確描述用戶的功能需求，以便于確定建立的對象。 很長時間以來，無論是傳統的軟件開發方法還是面向對象的開發方法，都采用自然語言（如中文）來描述對系統的需求 其缺點是沒有統一的格式，缺乏描述的形式化，隨意性較大，常常產生理解上的含混及不確定性。  在這種背景下，有關專家提出了用例（Use Case）的概念及其圖形表示方法——用例圖，這種方法很快得到廣泛的應用。

（2）參與者和用例

 參與者（Actor）表示系統用戶能扮演的角色(role)，這些用戶可能是人、也可能是其他的計算機或者一些硬件或者甚至是其它軟件系統，唯一的標準是它們必須要在被劃分進用例的系統部分以外，并且它們必須能刺激系統部分并接收返回。

在本項目中的參與者主要有用戶和系統統管理員，而管理員使用控制面板對系統和用戶管理，也就是進行系統設置，管理用戶、用戶組、權限，查看系統訪問日志及用戶使用情況等的統計信息。  在前面的學校課程管理系統中的示例中則有三個Actor 在不同的應用中互動。這三個Actor分別是學生，講師以及系統管理者。而學生Actor 使用了系統中瀏覽課程以及注冊課程的功能，而系統管理者Actor 則是負責管理注冊的學員，編排課程以及確認課程。講師則是主導課程的Actor，他可以瀏覽，開辦以及移除課程(當然，必須是這個講師自己的課程)

（3）所要注意的問題

 參與者主要是指角色而非具體的個人

 用戶與參與者之間的關系 一個用戶可以抽象為多個參與者，如：張三即可以是網上書店的讀者，也可以是管理員 一個參與者可以包含多個用戶，如：網上書店的讀者可以是張三和李四 　

（4）用例（UseCase）及其定義

它描述了當主角之一給系統特定的刺激時系統的活動，是主角通過系統完成一個過程時出現的一組事件，最終以實現一種功能。 通常，用例側重于功能，但不重點描述該功能的實現細節。 用例的大小劃分一般以事件流在10個步驟左右為好。

（5）用例的分類

業務用例（Business Use Case）
指系統提供的業務功能與參與者的交互，表現問題領域中各實體間的聯系和業務往來活動。它用于建立問題領域的業務用例模型。 系統用例（System Use Case）
指參與者與系統的交互，它表現了系統的功能需求和動態行為。

注意：用例確定的只是交流的目的，而不是交流的手段

客戶并不需要了解執行者、用例這些概念。用例能告訴開發團隊“去向客戶了解什么”（目的），不能告訴你如何向客戶去了解（手段）；

手段可以有很多種，文檔研究、問卷調查、訪談、觀察、研究競爭對手、開會、原型、場景演示…，使用用例思維來指導這些交流手段，會使交流更有目的，更加高效。因為以場景方式表達的需求本來就比一條條列出的需求要便于交流。

原文轉自：http://www.anti-gravitydesign.com