亚洲精品无码av人在线播放,久久成人伊人欧洲精品,日本精品αv中文字幕

搜索

APP

起點(diǎn)課堂會員權(quán)益

職業(yè)體系課特權(quán)

線下行業(yè)大會特權(quán)

個人IP打造特權(quán)

30+門專項(xiàng)技能課

1300+專題課程

12場職場軟技能直播

12場求職輔導(dǎo)直播

12場專業(yè)技能直播

會員專屬社群

榮耀標(biāo)識

發(fā)布

注冊 | 登錄

使用用例獲取需求

旺旺旺旺旺仔

2012-05-17

0 評論 14060 瀏覽 7 收藏

20 分鐘

簡介：

研發(fā)都通常都使用典型場景(scenarios)來理解一個系統(tǒng)的需要是什么和系統(tǒng)是怎樣工作的。不幸的是，盡管研發(fā)都已這樣做了，但他極少用有效的形式歸檔。用例(Use-Cases)就是將這些場景獲取正式化、形式化的技術(shù)。

用例是Jacobson在面象對象的軟件工程中提出的，但他實(shí)際上是獨(dú)立于面象對象的。用例是獲取業(yè)務(wù)過程和系統(tǒng)需求的有效方式。而且技術(shù)本身是非常簡單易學(xué)的。

使需求可被瀏覽

形式化場景獲取是為了使用戶和研發(fā)者都能瀏覽這些場景。所有功能需求符號都必須滿足以下兩條準(zhǔn)則：

應(yīng)易于需求源和瀏覽者理解，并且

不應(yīng)包含系統(tǒng)的形式和內(nèi)容的所有細(xì)節(jié)

功能需求是外部需求，用他來評估系統(tǒng)的設(shè)計(jì)和最終實(shí)現(xiàn)。

應(yīng)當(dāng)以系統(tǒng)無關(guān)的方式獲取買家(stakeholders)的需要和期望。

用例令需求可被瀏覽

用例正被廣泛使用。和其他需求分析技術(shù)相比，用例已取得成功，這是因?yàn)椋?/p>

用例將系統(tǒng)視為黑盒

用例使了解需求的實(shí)現(xiàn)精度變得容易

后者來源于前者。用例應(yīng)該不涉及需求相關(guān)系統(tǒng)的所有內(nèi)部結(jié)構(gòu)，這樣如果用例指出“提交對訂單數(shù)據(jù)庫的改動”或“在Web頁面顯示結(jié)果”，內(nèi)部結(jié)構(gòu)顯而易見并可標(biāo)識為潛在的設(shè)計(jì)限制。

需求不應(yīng)該涉及所有內(nèi)部結(jié)構(gòu)是因?yàn)椋好枋鰞?nèi)部結(jié)構(gòu)帶給設(shè)計(jì)者額外的限制。沒有這些限制設(shè)計(jì)者會有更大的自由來建立恰當(dāng)?shù)膶?shí)現(xiàn)了外部可觀察行為的系統(tǒng)，并有可能提供突破性的解決方案。

工業(yè)對用例的接受

用例是在大約六年前正式發(fā)布的，此后被絕大多數(shù)主要對象方法吸收。用例也已被業(yè)務(wù)處理再工程協(xié)會(business process reenginerring community)吸收為描述現(xiàn)有及未來模式業(yè)務(wù)操作的有效方法。

用例本身最近因其UML中的位置和地位再次得到強(qiáng)調(diào)。UML已被OMG接受做為對象系統(tǒng)的標(biāo)準(zhǔn)建模語言。

什么是用例

用例本身是指一個用戶或其他系統(tǒng)和要設(shè)計(jì)的系統(tǒng)進(jìn)行的一個交互，這個交互是了達(dá)到某個目標(biāo)(goal)。術(shù)語活動者(Actor)用來描述有該目標(biāo)的人或系統(tǒng)。這個術(shù)語強(qiáng)調(diào)了所有人或系統(tǒng)擁有目標(biāo)的事實(shí)。目標(biāo)本身是個動詞短語，如“客戶：下訂單”，“店員：記錄庫存”。

作為用例的一部分，有必要記錄目標(biāo)成功和失敗的對于活動者和系統(tǒng)的含義。在下訂單的實(shí)例中，目標(biāo)達(dá)成可能包括貨物交給活動者和公司收到相應(yīng)的貨款。仔細(xì)定義目標(biāo)成敗是定義系統(tǒng)范圍(scope)的基礎(chǔ)。因?yàn)閷τ谝粋€簡易的訂單輸入系統(tǒng)，目標(biāo)達(dá)成可能僅僅意味著訂單已經(jīng)過驗(yàn)證并且交貨已排定日程。

場景中的任務(wù)

一個用例中的不同場景顯示目標(biāo)怎樣成或敗：成功的場景中目標(biāo)達(dá)成，失敗的場景中目標(biāo)沒有達(dá)成。這里邊美妙的地方在于：目標(biāo)總結(jié)了許多的系統(tǒng)使用意圖，用戶能看見他們被期望臬使用系統(tǒng)。當(dāng)然系統(tǒng)沒有支持他們所有的目標(biāo)時(shí)，用戶也能即時(shí)察覺而不用等第一個原型研發(fā)出來，或甚至糟糕到要等系統(tǒng)全部研發(fā)完才發(fā)現(xiàn)。

用例應(yīng)該多大?

一個有趣的話題是試圖確定用例的大小。一種方法是將大小和用例的范圍和意圖聯(lián)系起來。對于真正大的范圍，一個用例不只描述一個獨(dú)立的系統(tǒng)，而是描述一筆業(yè)務(wù)用到的所有系統(tǒng)。這種業(yè)務(wù)用例(business use case)將整個系統(tǒng)當(dāng)作一個黑盒，并描述活動者和公司相關(guān)的目標(biāo)。業(yè)務(wù)用例的場景不能對公司的內(nèi)部結(jié)構(gòu)做所有假設(shè)。也就是說：用戶應(yīng)該向公司下訂單，不是客戶服務(wù)部。

而對于系統(tǒng)研發(fā)來說，一個用例的范圍限制為單個系統(tǒng)。這是用例更常見的形式，稱為系統(tǒng)用例(system use case)，他們將系統(tǒng)當(dāng)作黑盒。這些用例不能描述所有內(nèi)部結(jié)構(gòu)，并且只能使用問題域的語言。

用例的另一個范圍是系統(tǒng)內(nèi)的子系統(tǒng)或構(gòu)件的設(shè)計(jì)。這些實(shí)現(xiàn)級用例(implementation use case)將構(gòu)件當(dāng)作黑盒，活動者是和之有接口的構(gòu)件。例如：可能用實(shí)現(xiàn)級用例說明某個應(yīng)用程式對所使用的EMAIL構(gòu)件的需求。

按這樣分級，關(guān)于用例大小的討論是容易的。被設(shè)計(jì)項(xiàng)目(item)的范圍界定總的大小(overall size)。為了幫助系統(tǒng)設(shè)計(jì)者，每個用例應(yīng)該只描述單一的沒有大分枝的活動線索(thread)。違背這一約束，這在不精確或含混的準(zhǔn)則中常常能見到，會使得把用例當(dāng)作測試說明源材料的變得非常難。

作為系統(tǒng)用例的例子，“詢問數(shù)據(jù)庫庫存是否偏低”就太小了，顯然把實(shí)現(xiàn)細(xì)節(jié)和需求混起來了。對比之下，作為系統(tǒng)用例，“管理倉庫”就太大了，因?yàn)樗豢赡茏鳛閱我坏臎]有大分枝的活動線索來完成，而且從系統(tǒng)看，描述目標(biāo)成功是非常困難的。但他是個非常好的分部門(parts department)的業(yè)務(wù)用例。對于分部門來說，定義“管理倉庫”目標(biāo)的成功是可能的(可能用庫存清單變化、部門能力或運(yùn)作成本等術(shù)語)。

業(yè)務(wù)用例的好處在于可用來將其他用例歸類?！肮芾韨}庫”可用來組合所有和倉庫管理相關(guān)的用例。

用例的形式化定義

用例是結(jié)果的提交者，該結(jié)果對特定活動者是可測量的。

正如前面提到的，活動者能是和要設(shè)計(jì)的系統(tǒng)進(jìn)行交互的人或外部系統(tǒng)。對于一個用例有能測量的結(jié)果的需求，是從單線索需求衍生的。做為可測量結(jié)果的一個方面，目標(biāo)要么成功要么失敗，不存在中間結(jié)果。(注：如果存在，則需進(jìn)一步分解細(xì)化用例，直到單線索。)

給用例寫文件

用例有個非常好的地方，就是能給場景寫各種形式化程度文件。每個場景指通過用例的一條獨(dú)立路徑，從某個角度說是一套條件。

能使用非格式化的文本描述，但有多重條件或可能的失敗時(shí)，跟蹤起來有些困難。非格式化的敘述風(fēng)格在試圖理解需求的初始階段是非常有用的。然而，在接下來的用例研發(fā)中，用更形式的機(jī)制來寫用例文件是非常有用的。

客戶的粗略框架(rough sketch)：下訂單的用例可能是這樣的：

“識別客戶，檢查所需的貨物在庫中并且沒有超過他們的信用限制”。

結(jié)構(gòu)敘述(structured narrative)格式能提供更高效的率。這種格式說明一個活動者：目標(biāo)的序列。這各方式首先寫下來的是簡單的成功場景，所以的活動者：目標(biāo)語句都假定前一個目標(biāo)已成功，這樣形成是是最簡單的成功場景。

用例認(rèn)為我們正在設(shè)計(jì)的系統(tǒng)是個黑盒，根本不記錄所有內(nèi)部結(jié)構(gòu)，并且能看成對寫出場景的意圖有一個獨(dú)立的活動者。(and it can be considered to be a single actor for the purposes of writing out the scenario.)用例不描述系統(tǒng)內(nèi)部的所有情況，只有系統(tǒng)有什么目標(biāo)和是些什么目標(biāo)才是用例應(yīng)當(dāng)處理的。

—————————-

1. Clerk: Identify Customer

2. system: Identify Item

3. System: Confirm Ship Quantity

4. System: Confirm Credit

5: Customer: Authorize Payment

6. System: Dispatch Order

Extensions

1a. Customer not found

1a1. Clerk: Add new Customer

3a. Partial Stock

3a1. Clerk: Negotiate quantity

—————————-

處理目標(biāo)失敗-擴(kuò)展

下一步應(yīng)該注意的是上面記下來的每一步都可能失敗。導(dǎo)致失敗的條件能做為場景的擴(kuò)展來獲取。這些擴(kuò)展的寫法是：寫下場景在失敗條件之后的部份，跟隨這部分場景直到回到主體或失敗。

分離的失敗條件便利場景更具可讀性?；镜某晒鼍笆峭ㄟ^用例最簡單的路徑，路上的每一步中活動者目標(biāo)都達(dá)成了。獨(dú)立列出所有失敗條件能提供更好的質(zhì)量確保。瀏覽者非常容易檢查是否所有條件都已指明，或更有什么可能的條件被忽略了。失敗場景能是可恢復(fù)的或不可恢復(fù)的。可恢復(fù)的場景最終成功了，不可恢復(fù)場景直接失敗掉。

失敗中的失敗

另一個需要注意的復(fù)雜之處是失敗場景可能會再出現(xiàn)其他失敗。這意味著擴(kuò)展區(qū)可能有進(jìn)一步的失敗，他能用稍長一些的前綴數(shù)字標(biāo)識：1a1b. Customer is a bad credit risk. 這能在1a1b1中恢復(fù)。

為什么用一種結(jié)構(gòu)化的敘述格式?

結(jié)構(gòu)化的敘述體的價(jià)值在于他是可辯駁(refutable)的?？赊q駁描述的意義在于他足夠精確以供爭論或贊同：

“他不是這樣工作的?！?/p>

“我們在收訂單時(shí)不檢查可用性。”

“你丟了一些步驟?！?/p>

對比之下，粗略框架提供的非格式化描述則難以辯論，但他對問題域的早期理解是有用的。

另一個可辯駁描述的好處是當(dāng)你給用例寫文件時(shí)，希望(expect to)得到用戶和研發(fā)者的反饋。這是非常有價(jià)值的，因?yàn)樗馕秵栴}在在研發(fā)過程的早期就會得到修正。典型的用戶反饋是指出不同的順序、可能的并行性或缺少的步驟。研發(fā)者的典型反饋是和說清晰一個特別失敗條件的含義及怎么檢測他的需求相關(guān)的。

用例的圖像符號

有用來描述用例的圖像符號。在UML中使用一個簡單的曲棍球手符號代表活動者，橢圓代表用例，如下圖1所示。當(dāng)你想看看一套用例的相互關(guān)系和系統(tǒng)的總圖時(shí)，這些圖可就太棒了。

用例圖并不顯示不同的場景，他用想顯示的是活動者和用例間的關(guān)系。因此用例圖需要配上結(jié)構(gòu)化敘述的文本。UML有一些圖能代替敘述來表示不同的場景，常用的圖有交互圖和活動圖。這些圖的主要缺點(diǎn)是是不如文本簡潔，但對給出用例的總體感覺是有用的。關(guān)于交互圖和活動的說明參考“UML Distilled”，Martin Fowler(Addison-Wesley 1997)。

獲得需求重用

用“活動者：目標(biāo)”格式寫用例描述的價(jià)值在于：他將一個用例分解成許多因子(步驟)，能將通用的因子變成一個子用例。此后公共部分就能被各個主用例使用了。例如下訂單的識別客戶這一步就能被許多其他的用例使用。

(注：這也就是UML中常見的用例間泛化關(guān)系之一：使用。這里解釋的是在需求分析過程中格式化文本能怎么有效的分析出可被其他用例使用的部分。)

應(yīng)用用例的復(fù)雜性和風(fēng)險(xiǎn)

在基本的活動者和用例間沒有聯(lián)系(connection)

有時(shí)，在想從用例中獲益的活動者和活躍參和用例的活動者之間沒有清晰的聯(lián)系。例如，主辦會計(jì)(Chief Accountant)可能是“研發(fā)票”的活動者，但他們未必會在初始發(fā)票運(yùn)轉(zhuǎn)中活動(actually initiate the invoice run)。這是個問題，用例仍然有效，只不過活動者間的聯(lián)系是有價(jià)值的(getting the value)而用例的初始情況恰好超出了系統(tǒng)設(shè)計(jì)的范圍?；净顒诱呷匀皇怯杏玫?，因?yàn)榘缪菰摻巧娜艘簿褪悄銓懹美募枰徽劦娜恕?/p>

場景步驟不必序列化

在場景中的順序步驟無效時(shí)，有多種機(jī)制能突出可能的并行性。活動圖是UML中最佳選擇的方法，但非正式的，你能通過查看用例場景，看看那些相同的活動者并在用例中相鄰的步驟，來找出并行之處。就在我們前面的例子中，就有并行進(jìn)行confirm the ship quantity 和 confirm credit的可能性。有時(shí)，在用例文件中注意這種可能的并行性是有用處的。

確定用例大小

在開始使用用例是個絕對的風(fēng)險(xiǎn)就是有許多步驟或太少的步驟。如果用例中有多于15個步驟，可能某些實(shí)現(xiàn)細(xì)節(jié)已被包括進(jìn)去了。如果步驟太少則檢查看看目標(biāo)能通過沒有大分枝的獨(dú)立活動線索而達(dá)成。

非常少(如果有)人類活動者

如果非常少人類活動者，多數(shù)用例來自其他系統(tǒng)，則用來識別用例的機(jī)制應(yīng)該改動。用和活動者交流(用機(jī)器做有點(diǎn)難:-)，代替查找系統(tǒng)必須反應(yīng)或識別的外部事件。

需求分析和系統(tǒng)復(fù)雜性

總的看來，場景獲取和系統(tǒng)復(fù)雜性相關(guān)，但即使是大型系統(tǒng)，使用“活動者：目標(biāo)”對能寫出相對簡潔的文件。用例格式的價(jià)值在于：不同于有大量難以閱讀的功能說明，用例令用戶和研發(fā)者能標(biāo)識出活動者，然后確認(rèn)列出的目標(biāo)符合(或不符合)活動者的工作職責(zé)。

但系統(tǒng)并不只是功能需求

用例并不獲取系統(tǒng)的所有外部需求。用例非常少獲取系統(tǒng)將被怎樣使用方面的功能需求。需求更有許多其他方面需要獲取并解決。然而一些非功能性的需求是相關(guān)的，這樣就能將他們附加到一個用例中。一個例子是諸如產(chǎn)量(throughput)和性能(performance)。其他沒有使用關(guān)聯(lián)的需求需要分別獲取。這種例子可能是：

系統(tǒng)范圍

用戶對系統(tǒng)所擁有的目標(biāo)

用戶界面原型

通用規(guī)則

限制

算法

運(yùn)行時(shí)需求對構(gòu)造時(shí)需求

獲取需求時(shí)應(yīng)當(dāng)記信的一個重要因素是：系統(tǒng)的成員(constituency)比用戶團(tuán)體大得多。系統(tǒng)中有不同主顧，用例只獲取其中一部分的需求。本質(zhì)上，用例只獲取系統(tǒng)的運(yùn)行時(shí)需求而忽略了一個主要的主顧：系統(tǒng)研發(fā)組織。系統(tǒng)研發(fā)組織對說明系統(tǒng)的構(gòu)造時(shí)需求興趣十足。

運(yùn)行時(shí)需求包括：系統(tǒng)范圍、目標(biāo)和用戶組織對產(chǎn)品的期望，用例，其他非功能性需求。

構(gòu)造時(shí)需求包括：易于研發(fā)、面對變化時(shí)的健壯性、已有構(gòu)件的重用。

構(gòu)造時(shí)需求能用用例圖分別處理，但研發(fā)組織還需要解決許多其他方面：

項(xiàng)目范圍和目標(biāo)：什么是項(xiàng)目必須提供的(有別于系統(tǒng)范圍，系統(tǒng)范圍通常會在多個項(xiàng)目中提供)。

增長和變化的實(shí)例：這能作為“變化情況”用通常的用例格式來獲取

研發(fā)主持約束：這包括標(biāo)準(zhǔn)、實(shí)踐、工具、質(zhì)量測量(measure)和質(zhì)量確認(rèn)(assurance)的概念和實(shí)踐

用例的適用性

用例主要針對需要響應(yīng)外部事件的系統(tǒng)。他們也能用于有明確可理解目標(biāo)的明顯活動者的其他系統(tǒng)。

當(dāng)外結(jié)果示定義或不明確時(shí)用例不能使用。

這意味著如果目標(biāo)成敗不能定義，則用例不可用于獲取該需求。

應(yīng)該指出的是，絕大多數(shù)現(xiàn)代對象方法都在使用用例，這是因?yàn)橛美驯蛔C實(shí)是需求獲取的非常有效的機(jī)制。

總結(jié)