第3章 需求分析與用例模型

1、 在軟件工程中，需求分析指的是在建立系統(tǒng)時描寫系統(tǒng)的目的、范圍、定義和功能時要做的所有工作。 需求分析是軟件工程中的一個關(guān)鍵過程。在這個過程中，系統(tǒng)分析員和軟件工程師要確定顧客的需求。需求層次內(nèi)容業(yè)務(wù)需求 客戶對系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求。通常問題定義就是業(yè)務(wù)需求用戶需求 描述用戶使用產(chǎn)品必須要完成什么任務(wù)，怎么完成，通常是在問題定義的基礎(chǔ)上進(jìn)用戶訪談、調(diào)查，對用戶使用的場景進(jìn)行整理，從而建立從用戶角度的需求系統(tǒng)需求 從系統(tǒng)的角度來說明軟件的需求，它就包括了用特性說明的功能需求，質(zhì)量屬性以及其它非功能需求，還有設(shè)計約束。在統(tǒng)一過程（UP）中，需求按照“FURPS”模型進(jìn)行分類。 功能性（Fun

2、ctional）：特性、功能、安全性； 可用性（Usability）：人性化因素、幫助、文檔； 可靠性（Reliability）：故障頻率、可恢復(fù)性、可預(yù)測性； 性能（Performance）：響應(yīng)時間、吞吐量、準(zhǔn)確性、有效性、資源利用率； 可支持性（Supportability）：適應(yīng)性、可維護(hù)性、國際化、可配置性。非功能性需求非功能性需求 在系統(tǒng)開發(fā)的初期階段，基于以下目的做成用例圖： 明確開發(fā)系統(tǒng)的主要功能 明確開發(fā)系統(tǒng)的范圍 明確開發(fā)對象和外界的關(guān)系由參與者（Actor）、用例（Use Case）以及它們之間的關(guān)系構(gòu)成的用于描述系統(tǒng)功能的動態(tài)視圖稱為用例圖（Use Case Diagr

3、am）。要在用例圖上顯示某個用例，可繪制一個橢圓，然后將用例的名稱放在橢圓的中心或橢圓下面的中間位置。 要在用例圖上繪制一個參與者（表示一個系統(tǒng)用戶），可繪制一個人形符號。參與者和用例之間的關(guān)系使用帶箭頭或者不 在用例建模中，為了更加清楚的描述用例或者參與者，會使用到注釋。 用例圖是需求分析中的產(chǎn)物，主要作用是描述參與者和用例之間的關(guān)系，幫助開發(fā)人員可視化的了解系統(tǒng)的功能。借助于用例圖，系統(tǒng)用戶、系統(tǒng)分析人員、系統(tǒng)設(shè)計人員、領(lǐng)域?qū)＜夷軌蛞钥梢暬姆绞綄栴}進(jìn)行探討，減少了大量交流上的障礙，便于對問題達(dá)成共識。 用例圖可視化地表達(dá)了系統(tǒng)的需求，具有直觀、規(guī)范等優(yōu)點(diǎn)，克服了純文字性說明的不足。 用

4、例方法是完全從外部來定義系統(tǒng)功能，它把需求和設(shè)計完全的分離開來。我們不用關(guān)心系統(tǒng)內(nèi)部是如何完成各種功能的，系統(tǒng)對于我們來說就是一個黑箱子。 獲取需求、指導(dǎo)測試、對開發(fā)過程中的其他工作起指導(dǎo)作用。 用例圖包含3方面內(nèi)容： 用例圖中可以包含注釋、約束o參與者是系統(tǒng)外部的一個實體，以某種方式參與用例的執(zhí)行過程。是為了完成一個事件與系統(tǒng)進(jìn)行交互的實體，是與系統(tǒng)交互作用的外部用戶、進(jìn)程或其他系統(tǒng)的理想化概念。o在UML中，參與者用名字寫在下面的人形圖標(biāo)表示。 參與者由它們參與用例時所擔(dān)當(dāng)?shù)慕巧珌肀硎?。o 任何事物人、外系統(tǒng)、特殊的硬件、時間(到某一時間觸發(fā)某一事件）等 在獲取用例前要先確定系統(tǒng)的參與者，

5、可以根據(jù)以下的一些問題來尋求系統(tǒng)參與者。 （1）使用系統(tǒng)主要功能的人是誰？（2）需要借助于系統(tǒng)完成日常工作的人是誰？（3）誰來維護(hù)管理系統(tǒng)保證系統(tǒng)正常工作？（4）系統(tǒng)控制的硬件有哪些？（5）系統(tǒng)與哪些其他系統(tǒng)交互？（6）對本系統(tǒng)產(chǎn)生的結(jié)果感興趣的人或事是哪些？ 多個參與者之間可以具有與類之間相同的關(guān)系。 在用例圖中，可以使用泛化關(guān)系來描述多個參與者之間的。 例如，在圖書館管理系統(tǒng)中，借書者可以泛化成兩類：學(xué)生和老師。 再如，航空售票系統(tǒng)接受客戶預(yù)定機(jī)票，客戶可以進(jìn)行電話預(yù)定和網(wǎng)上預(yù)定，如果不考慮客戶是如何與系統(tǒng)接觸的，可以使用一般角色的參與者，即父類；如果強(qiáng)調(diào)接觸發(fā)生的形式，那么必須使用實際的

6、參與者，即子類。學(xué)生借書者客戶老師電話客戶網(wǎng)上客戶 更具一般的，可以由下圖表示參與者之間的關(guān)系。特殊化參與者超類參與者特殊化參與者 用例是系統(tǒng)中的功能 一個用例表示一個功能，集中所有的用例，可完整描述如何使用該系統(tǒng) 可以通過關(guān)聯(lián)線與參與者連接，一個用例至少與一個參與者相關(guān)聯(lián)。 給用例取名字要站在使用者的立場上考慮 可以用系統(tǒng)邊界把用例框起來以區(qū)分系統(tǒng)內(nèi)外 在UML中，用例用一個橢圓來表示，用例的名字可以寫在橢圓的下方。用例名 用例圖對整個系統(tǒng)的建模過程非常重要，在繪制系統(tǒng)用例圖前，有許多工作需要做。 系統(tǒng)分析者必須分析系統(tǒng)的參與者和用例，它們分別描述了“誰來做”和“做什么”這兩個問題。 識別用

7、例最好的方法就是從分析系統(tǒng)的參與者開始，考慮每個參與者是如何使用系統(tǒng)的。使用這種策略的過程中可能會發(fā)現(xiàn)新的參與者。 在識別用例的過程中，通過回答以下幾個問題，系統(tǒng)分析者可以獲得幫助。 參與者要從系統(tǒng)中獲得哪種功能？參與者需要做什么？ 參與者需要讀取、產(chǎn)生、刪除、修改或存儲系統(tǒng)中的某種信息嗎？ 系統(tǒng)中發(fā)生的事件要通知參與者嗎？或者參與者需要通知系統(tǒng)某事件嗎？這些事件（功能）能干什么？ 用系統(tǒng)的新功能處理參與者的日常工作是簡化了，還是提高了工作效率？ 還有一些與當(dāng)前參與者的日常工作無關(guān)的問題，也能幫助發(fā)現(xiàn)用例 系統(tǒng)需要的輸入、輸出是什么信息？這些信息是從哪里來到哪里去？ 系統(tǒng)當(dāng)前的這種實現(xiàn)方法要解

8、決什么問題（也許用自動系統(tǒng)代替手工操作）？ 用例圖中，除了參與者與用例之間的關(guān)聯(lián)關(guān)系外，參與者和參與者之間可以有泛化關(guān)系，用例和用例之間有泛化關(guān)系、包含關(guān)系和擴(kuò)展關(guān)系。 參與者與用例之間通常用關(guān)聯(lián)關(guān)系來描述。每個參與者可以參與一個或多個用例。 參與者與用例之間的關(guān)聯(lián)關(guān)系使用帶箭頭或者不帶箭頭的實現(xiàn)表示。 如果系統(tǒng)中一個或多個用例是某個一般用例的特殊化時，就需要使用用例的泛化關(guān)系。 在UML中，用例泛化與其他泛化關(guān)系的表示法相同，用一個三角箭頭從子用例指向父用例。 如果系統(tǒng)中一個或多個用例是某個一般用例的特殊化時，就需要使用用例的泛化關(guān)系。 在UML中，用例泛化與其他泛化關(guān)系的表示法相同，用一個

9、三角箭頭從子用例指向父用例。包含關(guān)系描述的是一個用例需要某種功能，而該功能被另外一個用例定義，那么在用例的執(zhí)行過程中，就可以調(diào)用已經(jīng)定義好的用例。在UML中，用例之間的包含關(guān)系含有關(guān)鍵字的帶有箭頭的虛線表示。如果兩個以上用例有大量一致的功能，則可以將這個功能分解到另一個用例中，其他用例可以和這個用例建立包含關(guān)系（如之前介紹的飲料自動售貨機(jī)）。 一個用例的功能太多時，可以使用包含關(guān)系建立若干個更小的用例。（如學(xué)生管理系統(tǒng)） 有助于將來實現(xiàn)系統(tǒng)時，確定哪些功能可以重用，在編寫代碼時就可以實現(xiàn)代碼的重用，縮短開發(fā)周期。 注意：執(zhí)行基用例時，每次都必須調(diào)用被包含用例。 擴(kuò)展關(guān)系是一個用例被定義為基礎(chǔ)用

10、例的增量擴(kuò)展，通過擴(kuò)展關(guān)系把新的行為插入到已有用例中。擴(kuò)展關(guān)系中，擴(kuò)展用例是基礎(chǔ)用例的一個相對獨(dú)立并且可選的用例。 在UML中，擴(kuò)展關(guān)系用虛線箭頭加表示，箭頭指向基礎(chǔ)用例，即被擴(kuò)展的用例 對擴(kuò)展用例的限制規(guī)則：將一些常規(guī)的動作放在一個基本用例中，將放在它的擴(kuò)展用例中。 用例的粒度指的是用例所包含的系統(tǒng)服務(wù)或功能單元的多少。 用例的粒度越大，用例包含的功能越多，反之則包含的功能越少。 如果用例的粒度很小，得到的用例數(shù)就會太多。反之，如果用例的粒度很大，那么得到的用例數(shù)就會很少。 如果用例數(shù)目過多會造成用例模型過大和引入設(shè)計困難大大提高。如果用例數(shù)目過少會造成用例的粒度太大，不便于進(jìn)一步的充分分析

11、?會員?輸入用戶名?驗證用戶名和密碼?會員?登錄?身份驗證查詢訂單建立數(shù)據(jù)庫連接執(zhí)行SQL語句 用例圖只是在總體上大致描述了系統(tǒng)所提供的各種服務(wù)，讓用戶對系統(tǒng)有一個總體的認(rèn)識。但對于每一個用例還需要有詳細(xì)的描述信息，以便讓其他人對于整個系統(tǒng)有一個更加詳細(xì)地了解，這些信息包含在用例規(guī)約之中。 用例模型指的也不僅僅是用例圖，而是由用例圖和用例的詳細(xì)描述用例規(guī)約所組成的。用例規(guī)約包含以下內(nèi)容： 1 簡要說明:對用例作用和目的的簡要描述。 2 事件流:事件流包括基本流和備選流?；玖髅枋龅氖怯美幕玖鞒蹋侵赣美罢！边\(yùn)行時的場景。 3 用例場景:同一個用例在實際執(zhí)行的時候會有很多不同的情況發(fā)生，

12、稱之為用例場景，也可以說用例場景就是用例的實例。 4 特殊需求: 特殊需求指的是一個用例的非功能性需求和設(shè)計約束。特殊需求通常是非功能性需求，包括可靠性、性能、可用性和可擴(kuò)展性等。例如法律或法規(guī)方面的需求、應(yīng)用程序標(biāo)準(zhǔn)和所構(gòu)建系統(tǒng)的質(zhì)量屬性等。 5 前置條件: 執(zhí)行用例之前系統(tǒng)必須所處的狀態(tài)。例如，前置條件是要求用戶有訪問的權(quán)限或是要求某個用例必須已經(jīng)執(zhí)行完。 6 后置條件:用例執(zhí)行完畢后系統(tǒng)可能處于的一組狀態(tài)。例如，要求在某個用例執(zhí)行完后，必須執(zhí)行另一個用例。 說明用例如何開始和結(jié)束。只說明屬于該用例的事件，而不是發(fā)生在其他用例中或系統(tǒng)外部的事件。 避免不明確的術(shù)語，如“例如”、“等等”和“

13、信息” 在事件流里要對事件流進(jìn)行結(jié)構(gòu)化說明基本事件流 描述每個情節(jié)的行為者:目標(biāo)語句對的順序 假設(shè)之前的每一步都是成功的備選事件流 異常情況非功能需求(URPS)可用性（Usability）可靠性（Reliability）性能（Performance）可支持性（Supportability）設(shè)計約束用Oracle數(shù)據(jù)庫平臺，用PB開發(fā)軟件必須符合ISO標(biāo)準(zhǔn)本質(zhì)上不是需求，只是從商業(yè)、行政、技術(shù)上的約束?軟件需求?非功能需求?功能需求?設(shè)計約束用例編號UC01用例名稱用戶注冊用例概述未注冊用戶注冊成為會員參與者未注冊用戶前置條件用戶在主頁單擊“注冊”,進(jìn)入注冊程序后置條件注冊時填寫的用戶信息保存

14、到系統(tǒng)中基本事件流1.系統(tǒng)顯示注冊頁面；2.用戶填寫用戶名、密碼等相關(guān)信息后提交；3.系統(tǒng)處理該請求并顯示注冊成功；4.注冊成功后跳轉(zhuǎn)到登錄頁面；擴(kuò)展事件流2a.如果填寫的用戶名已經(jīng)存在，則提示錯誤信息：用戶名已經(jīng)存在 如果密碼不符合要求，則提示錯誤信息：密碼格式不正確；3a.注冊失敗 系統(tǒng)再跳轉(zhuǎn)到注冊頁面，提示用戶重新注冊；規(guī)則與約束無用例編號UC02用例名稱登錄用例概述驗證用戶名和密碼參與者系統(tǒng)的注冊用戶前置條件無后置條件登錄的用戶已經(jīng)注冊基本事件流1.用戶填寫用戶名、密碼，點(diǎn)擊“登錄”；2.系統(tǒng)驗證用戶名和密碼；3.驗證成功，系統(tǒng)跳轉(zhuǎn)到用戶主頁；擴(kuò)展事件流3a.驗證失敗 3a1:如果用戶

15、名不存在，系統(tǒng)提示“用戶名不存在”； 如果密碼錯誤，則系統(tǒng)提示“用戶名或密碼錯誤”； 3a2:讓用戶重填用戶名和密碼規(guī)則與約束 無用例編號UC03用例名稱新增書籍信息用例概述錄入新購書信息，并自動存儲建檔參與者圖書管理員前置條件用戶進(jìn)入圖書管理系統(tǒng)中的“新增書籍信息”程序后置條件完成新書信息的存儲建檔基本事件流1.系統(tǒng)要求圖書管理員選擇要新增的書籍是計算機(jī)類還是非計算機(jī)類；2.圖書管理員做出選擇后，顯示相應(yīng)的頁面，讓圖書管理員輸入信息，并自動根據(jù)書號規(guī)則生成書號；3.圖書管理員輸入書籍信息，包括書名、作者、出版社、ISBN、定價；4.系統(tǒng)確認(rèn)輸?shù)娜胄畔⒅袝麤]有重名；5.系統(tǒng)將所輸入的信息存儲

16、建檔擴(kuò)展事件流5a.如果輸入的書名有重名，則顯示重名的書籍，并要求圖書管理員選擇修改書名或取消輸入 5a1.圖書管理員選擇取消輸入，則結(jié)束用例，不做存儲建檔工作； 5a2.圖書管理員選擇修改書名后，轉(zhuǎn)到第5步規(guī)則與約束無“企業(yè)進(jìn)、存、銷管理系統(tǒng)” 功能性需求包括以下內(nèi)容： （1）采購員根據(jù)生產(chǎn)原料的使用情況判斷采購用品，對需要訂購產(chǎn)品信息統(tǒng)計訂貨的，并制作產(chǎn)品訂單。最后根據(jù)訂單進(jìn)行采購活動。 （2）倉庫管理員負(fù)責(zé)產(chǎn)品的庫存管理。 包括產(chǎn)品入庫管理、處理盤點(diǎn)信息、處理報損產(chǎn)品信息和一些信息的設(shè)置。這些設(shè)置信息，包括：供應(yīng)商信息、產(chǎn)品信息。 倉庫管理員每天對產(chǎn)品進(jìn)行一次盤點(diǎn)，當(dāng)發(fā)現(xiàn)庫存產(chǎn)品有損壞時

17、，及時處理報損信息。當(dāng)產(chǎn)品生產(chǎn)后，將產(chǎn)品進(jìn)行入庫。當(dāng)產(chǎn)品銷售后時，產(chǎn)品進(jìn)行出庫處理。 （3）統(tǒng)計人員負(fù)責(zé)統(tǒng)計分析管理，包括：查詢產(chǎn)品信息、查詢銷售信息、查詢供應(yīng)商信息、查詢?nèi)必浶畔?、查詢報表信息，并制作報表。統(tǒng)計分析員使用系統(tǒng)的統(tǒng)計分析功能，了解產(chǎn)品信息、銷售信息、供應(yīng)商信息、庫存信息。 （4）在銷售員為客戶提供售貨服務(wù)時，接受客戶購買產(chǎn)品，根據(jù)系統(tǒng)的定價計算出產(chǎn)品的總價，客戶付款，系統(tǒng)自動保存客戶購買記錄。 （5）系統(tǒng)管理員負(fù)責(zé)本系統(tǒng)的系統(tǒng)維護(hù)。系統(tǒng)管理員負(fù)責(zé)員工信息管理、供貨商信息管理以及系統(tǒng)維護(hù)等。每種管理者都通過自己的用戶名稱和密碼登錄到各自的管理系統(tǒng)中。 （1）銷售員：為客戶客提供銷

18、售產(chǎn)品的服務(wù)。 （2）倉庫管理員：負(fù)責(zé)庫存產(chǎn)品的管理活動。 （3）采購員：負(fù)責(zé)企業(yè)生產(chǎn)原料的訂購。 （4）會計：負(fù)責(zé)企業(yè)經(jīng)營狀況的統(tǒng)計。 （5）系統(tǒng)管理員：負(fù)責(zé)企業(yè)員工信息管理、供應(yīng)商信息管理以及系統(tǒng)維護(hù)等。（1）銷售員能夠通過該系統(tǒng)進(jìn)行銷售商品活動。首先登錄系統(tǒng)，驗證身份成功后，獲取商品信息，然后將銷售信息更新，最后對客戶進(jìn)行商品銷售。（2）倉庫管理員能夠通過該系統(tǒng)進(jìn)行如下活動： 處理盤點(diǎn)：每天需要對庫存產(chǎn)品信息進(jìn)行盤點(diǎn)。 產(chǎn)品入庫：當(dāng)產(chǎn)品生產(chǎn)后，將產(chǎn)品進(jìn)行入庫。 產(chǎn)品出庫：當(dāng)產(chǎn)品銷售發(fā)貨后，進(jìn)行出庫處理。 管理設(shè)置：倉庫管理員負(fù)責(zé)供應(yīng)商信息、產(chǎn)品基本信息的管理設(shè)置。（3）采購員能夠通過該系

19、統(tǒng)進(jìn)行訂貨管理活動。采購員首先根據(jù)經(jīng)營情況統(tǒng)計所缺的生產(chǎn)資料，根據(jù)需要制定出訂單。（4）會計負(fù)責(zé)產(chǎn)品的統(tǒng)計分析管理，它能夠通過該系統(tǒng)進(jìn)行如下活動： 查詢基本信息。會計能夠查詢產(chǎn)品的基本信息，根據(jù)產(chǎn)品的基本信息，制定出相應(yīng)的方案。 查詢銷售信息。會計根據(jù)銷售情況匯總后交銷售部制定合理的銷售方案。 查詢供應(yīng)商信息。會計能夠查詢供應(yīng)商信息。 查詢?nèi)必浶畔?。會計能夠查詢?nèi)必浶畔ⅰ?查詢報損信息。會計能夠查詢報損信息。（5）系統(tǒng)管理員能夠通過該系統(tǒng)進(jìn)行如下活動： 維護(hù)員工信息。系統(tǒng)管理員能夠維護(hù)企業(yè)員工的信息，如添加員工、刪除員工和修改員工信息等。 維護(hù)供應(yīng)商信息。系統(tǒng)管理員能夠維護(hù)供應(yīng)商的信息，如添加供應(yīng)商、刪除供應(yīng)商和修改供應(yīng)商信息等。 系統(tǒng)設(shè)置。系統(tǒng)管理員能夠根據(jù)一些需要進(jìn)行必要的系統(tǒng)設(shè)置。在每個新學(xué)年開始的時候都會有新生入學(xué)。這時： 管理人員可以通過系統(tǒng)將這些新生的學(xué)籍、年齡、家庭住址、性別、學(xué)生證號、身份證號等基本信息存入數(shù)據(jù)庫。在日常的管理中： 系統(tǒng)管理員還可以對所有學(xué)生的基本信息進(jìn)行查詢、修改、刪除等操作。 校領(lǐng)導(dǎo)可以查詢、修改全校學(xué)生的基本信息 教師查詢、修改自己