負(fù)責(zé)人：韓朝燕

1什么是用例？

? ? ? 在介始用例方法之前，我們首先來(lái)看一下傳統(tǒng)的需求表述方式-"軟件需求規(guī)約"(Software Requirement Specification)。傳統(tǒng)的軟件需求規(guī)約基本上采用的是功能分解的方式來(lái)描述系統(tǒng)功能，在這種表述方式中，系統(tǒng)功能被分解到各個(gè)系統(tǒng)功能模塊中，我們通過(guò)描述細(xì)分的系統(tǒng)模塊的功能來(lái)達(dá)到描述整個(gè)系統(tǒng)功能的目的。一個(gè)典型的軟件需求規(guī)約可能具有以下形式：

?

? ? ?采用這種方法來(lái)描述系統(tǒng)需求，非常容易混淆需求和設(shè)計(jì)的界限，這樣的表述實(shí)際上已經(jīng)包含了部分的設(shè)計(jì)在內(nèi)。由此常常導(dǎo)致這樣的迷惑：系統(tǒng)需求應(yīng)該詳細(xì)到何種程度？一個(gè)極端就是需求可以詳細(xì)到概要設(shè)計(jì)，因?yàn)檫@樣的需求表述既包含了外部需求也包含了內(nèi)部設(shè)計(jì)。在有些公司的開發(fā)流程中，這種需求被稱為"內(nèi)部需求"，而對(duì)應(yīng)于用戶的原始要求則被稱之為"外部需求"。

? ? ? 功能分解方法的另一個(gè)缺點(diǎn)是這種方法分割了各項(xiàng)系統(tǒng)功能的應(yīng)用環(huán)境，從各項(xiàng)功能項(xiàng)入手，你很難了解到這些功能項(xiàng)是如何相互關(guān)聯(lián)來(lái)實(shí)現(xiàn)一個(gè)完成的系統(tǒng)服務(wù)的。所以在傳統(tǒng)的SRS文檔中，我們往往需要另外一些章節(jié)來(lái)描述系統(tǒng)的整體結(jié)構(gòu)及各部分之間的相互關(guān)聯(lián)，這些內(nèi)容使得SRS需求更象是一個(gè)設(shè)計(jì)文檔。

?

1.1 參與者和用例

? ? ? 從用戶的角度來(lái)看，他們并不想了解系統(tǒng)的內(nèi)部結(jié)構(gòu)和設(shè)計(jì)，他們所關(guān)心的是系統(tǒng)所能提供的服務(wù)，也就是被開發(fā)出來(lái)的系統(tǒng)將是如何被使用的，這就用例方法的基本思想。用例模型主要由以下模型元素構(gòu)成：

參與者(Actor)?
參與者是指存在于被定義系統(tǒng)外部并與該系統(tǒng)發(fā)生交互的人或其他系統(tǒng)，他們代表的是系統(tǒng)的使用者或使用環(huán)境。

針對(duì)我們的此次項(xiàng)目分析：

管理者：

? ? ? ? ? 輸入數(shù)據(jù)

? ? ? ? ? 管理者輸入相應(yīng)的登錄名和密碼進(jìn)入相應(yīng)用戶界面。

? ? ? ? ? 輸出數(shù)據(jù)

? ? ? ? ? 根據(jù)用戶所要查詢的內(nèi)容輸出相應(yīng)信息。

? ? ? ? ? 更改數(shù)據(jù)

? ? ? ? ? 可以對(duì)教室有關(guān)信息進(jìn)行查詢，修改，增加，刪除。

用戶：

? ? ? ? ?注冊(cè)

? ? ? ? ?可以通過(guò)界面進(jìn)行信息注冊(cè)。

? ? ? ? ?登入

? ? ? ? ?通過(guò)界面登入并進(jìn)行查看。

用例(Use Case)?
用例用于表示系統(tǒng)所提供的服務(wù)，它定義了系統(tǒng)是如何被參與者所使用的，它描述的是參與者為了使用系統(tǒng)所提供的某一完整功能而與系統(tǒng)之間發(fā)生的一段對(duì)話。

針對(duì)我們的此次項(xiàng)目分析：

? ? ? ?管理者對(duì)教室的管理，根據(jù)教室的課程表的情況對(duì)數(shù)據(jù)庫(kù)中的信息進(jìn)行插入、刪除、更新操作。

? ? ? ?用戶可以在注冊(cè)界面進(jìn)行注冊(cè)或登入界面查找某天某個(gè)時(shí)間段空閑教室的情況。

通訊關(guān)聯(lián)(Communication Association)?
通訊關(guān)聯(lián)用于表示參與者和用例之間的對(duì)應(yīng)關(guān)系，它表示參與者使用了系統(tǒng)中的哪些服務(wù)（用例），或者說(shuō)系統(tǒng)所提供的服務(wù)（用例）是被哪些參與者所使用的。

針對(duì)我們的此次項(xiàng)目分析：

? ? ? ?此項(xiàng)目為參與者提供查找空教室的相關(guān)信息，用戶登入輸入查找的信息管理者會(huì)通過(guò)用戶所輸入的信息把相關(guān)的數(shù)據(jù)輸出到界面

?

1.2用例方法的優(yōu)點(diǎn)

? ? ? 用例方法完全是站在用戶的角度上（從系統(tǒng)的外部）來(lái)描述系統(tǒng)的功能的。在用例方法中，我們把被定義系統(tǒng)看作是一個(gè)黑箱，我們并不關(guān)心系統(tǒng)內(nèi)部是如何完成它所提供的功能的。用例方法首先描述了被定義系統(tǒng)有哪些外部使用者（抽象成為Actor），這些使用者與被定義系統(tǒng)發(fā)生交互；針對(duì)每一參與者，用例方法又描述了系統(tǒng)為這些參與者提供了什么樣的服務(wù)（抽象成為Use Case），或者說(shuō)系統(tǒng)是如何被這些參與者使用的。所以從用例圖中，我們可以得到對(duì)于被定義系統(tǒng)的一個(gè)總體印象。

? ? ? 與傳統(tǒng)的功能分解方式相比，用例方法完全是從外部來(lái)定義系統(tǒng)的功能，它把需求與設(shè)計(jì)完全分離開來(lái)。在面向?qū)ο蟮姆治鲈O(shè)計(jì)方法中，用例模型主要用于表述系統(tǒng)的功能性需求，系統(tǒng)的設(shè)計(jì)主要由對(duì)象模型來(lái)記錄表述。另外，用例定義了系統(tǒng)功能的使用環(huán)境與上下文，每一個(gè)用例描述的是一個(gè)完整的系統(tǒng)服務(wù)。用例方法比傳統(tǒng)的SRS更易于被用戶所理解，它可以作為開發(fā)人員和用戶之間針對(duì)系統(tǒng)需求進(jìn)行溝通的一個(gè)有效手段。

? ? ? 在RUP中，用例被作為整個(gè)軟件開發(fā)流程的基礎(chǔ)，很多類型的開發(fā)活動(dòng)都把用例作為一個(gè)主要的輸入工件(Artifact)，如項(xiàng)目管理、分析設(shè)計(jì)、測(cè)試等。根據(jù)用例來(lái)對(duì)目標(biāo)系統(tǒng)進(jìn)行測(cè)試，可以根據(jù)用例中所描述的環(huán)境和上下文來(lái)完整地測(cè)試一個(gè)系統(tǒng)服務(wù)，可以根據(jù)用例的各個(gè)場(chǎng)景(Scenario)來(lái)設(shè)計(jì)測(cè)試用例，完全地測(cè)試用例的各種場(chǎng)景可以保證測(cè)試的完備性。

2. 建立用例模型

使用用例的方法來(lái)描述系統(tǒng)的功能需求的過(guò)程就是用例建模，用例模型主要包括以下兩部分內(nèi)容：

用例圖(Use Case Diagram)?
確定系統(tǒng)中所包含的參與者、用例和兩者之間的對(duì)應(yīng)關(guān)系，用例圖描述的是關(guān)于系統(tǒng)功能的一個(gè)概述。

?

?

2.1 尋找參與者

所謂的參與者是指所有存在于系統(tǒng)外部并與系統(tǒng)進(jìn)行交互的人或其他系統(tǒng)。通俗地講，參與者就是我們所要定義系統(tǒng)的使用者。尋找參與者可以從以下問(wèn)題入手：

? ? ? ?參與者可以是教師、學(xué)生，也可以是管理員，通過(guò)界面可以可以查看教室的情況，管理者可以增刪改查的教室管理，更好的為用戶服務(wù)。

2.2 確定用例

找到參與者之后，我們就可以根據(jù)參與者來(lái)確定系統(tǒng)的用例，主要是看各參與者需要系統(tǒng)提供什么樣的服務(wù)，或者說(shuō)參與者是如何使用系統(tǒng)的。尋找用例可以從以下問(wèn)題入手（針對(duì)每一個(gè)參與者）：

? ? ? ? ?教室的管理系統(tǒng)可以方便用戶對(duì)它的使用，可以找到空教室進(jìn)行自習(xí)也可以對(duì)感興趣的課程進(jìn)行蹭課，更好的利用時(shí)間。

? ? ? ? ?管理者在系統(tǒng)中創(chuàng)建、修改、刪除、存儲(chǔ)數(shù)據(jù)，可以在數(shù)據(jù)庫(kù)中對(duì)各個(gè)教室的情況進(jìn)行這些操作。

? ? ? ? ?系統(tǒng)對(duì)用戶的輸入信息進(jìn)行分析查找返回用戶所需要的信息。

? ? ?在用例的抽取過(guò)程中，必須注意：用例必須是由某一個(gè)主角觸發(fā)而產(chǎn)生的活動(dòng)，即每個(gè)用例至少應(yīng)該涉及一個(gè)主角。如果存在與主角不進(jìn)行交互的用例，就可以考慮將其并入其他用例；或者是檢查該用例相對(duì)應(yīng)的參與者是否被遺漏，如果是，則補(bǔ)上該參與者。反之，每個(gè)參與者也必須至少涉及到一個(gè)用例，如果發(fā)現(xiàn)有不與任何用例相關(guān)聯(lián)的參與者存在，就應(yīng)該考慮該參與者是如何與系統(tǒng)發(fā)生對(duì)話的，或者由參與者確定一個(gè)新的用例，或者該參與者是一個(gè)多余的模型元素，應(yīng)該將其刪除。

? ? ?可視化建模的主要目的之一就是要增強(qiáng)團(tuán)隊(duì)的溝通，用例模型必須是易于理解的。用例建模往往是一個(gè)團(tuán)隊(duì)開發(fā)的過(guò)程，系統(tǒng)分析員在建模過(guò)程中必須注意參與者和用例的名稱應(yīng)該符合一定的命名約定，這樣整個(gè)用例模型才能夠符合一定的風(fēng)格。如參與者的名稱一般都是名詞，用例名稱一般都是動(dòng)賓詞組等。

? ? ?對(duì)于同一個(gè)系統(tǒng)，不同的人對(duì)于參與者和用例都可能有不同的抽象結(jié)果，因而得到不同的用例模型。我們需要在多個(gè)用例模型方案中選擇一種"最佳"（或"較佳"）的結(jié)果，一個(gè)好的用例模型應(yīng)該能夠容易被不同的涉眾所理解，并且不同的涉眾對(duì)于同一用例模型的理解應(yīng)該是一致的

轉(zhuǎn)載于:https://www.cnblogs.com/lvcaixia/p/4541584.html

總結(jié)

以上是生活随笔為你收集整理的SRS文档的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。