軟件需求工程 課件 第10-12章 面向軟件行為和視點(diǎn)的需求建模與檢測方法、面向問題域的需求分析方法、面向多視點(diǎn)的需求工程

第10章面向軟件行為和視點(diǎn)的

需求建模與檢測方法

目錄基本原理視點(diǎn)表示模型和視點(diǎn)管理需求模型的具體構(gòu)建方法基于行為模型的需求可視化需求模型的檢測方法需求建模方法的特點(diǎn)10-110-210-310-410-510-6進(jìn)一步的研究10-7引言將需求工程中的需求分析與需求驗(yàn)證階段的工作通過一個(gè)實(shí)際的方法給予有機(jī)的結(jié)合，能更系統(tǒng)和完整地了解和熟悉需求工程的研究內(nèi)容。該方法也使用了一些形式化方法和技術(shù)，試圖將理論研究與實(shí)際應(yīng)用較好地結(jié)合起來。此外，在本章介紹的內(nèi)容中，也將第5章中自動(dòng)取款機(jī)軟件系統(tǒng)作為實(shí)例，目的是使我們可以對(duì)兩種不同風(fēng)格的需求建模方法進(jìn)行比較和評(píng)價(jià)。在學(xué)習(xí)和理解本章介紹的方法之后，建議結(jié)合一個(gè)實(shí)際系統(tǒng)應(yīng)用本方法建立該系統(tǒng)的需求模型。面向軟件行為和視點(diǎn)的需求建模與檢測方法10-1基本原理復(fù)雜系統(tǒng)該系統(tǒng)是一個(gè)抽象概念，通常指規(guī)模大且內(nèi)部邏輯關(guān)系復(fù)雜、涉及相關(guān)人員較多的軟件系統(tǒng)。傳統(tǒng)的策略：通常是把復(fù)雜的問通過分解而給予解決。

特點(diǎn)：相關(guān)的問題域復(fù)雜=>利用分解策略涉及人員較多=>根據(jù)不同用戶建立相應(yīng)視點(diǎn)。需求建模方法應(yīng)提供的內(nèi)容：使用該方法的步驟=>從自然語言逐步過渡到行為模型。描述問題的手段=>視點(diǎn)表示模型和行為描述語言（BDL)。面向軟件行為和視點(diǎn)的需求建模方法是一種可用于建立復(fù)雜的軟件系統(tǒng)（以下簡稱復(fù)雜系統(tǒng)）需求模型的方法。10-1基本原理軟件的行為研究軟件行為的原因指主體施用一個(gè)服務(wù)、操作或動(dòng)作于客體。軟件行為的正確與否決定了軟件能否滿足用戶需求軟件特性如可信特性也是通過軟件行為來驗(yàn)證的可以從自然語言抽取和描述與軟件行為相關(guān)的細(xì)節(jié)10-1基本原理研究軟件行為的方法與現(xiàn)有的需求分析方法不同，基于軟件行為和視點(diǎn)的需求分析過程將主要考慮如何發(fā)現(xiàn)軟件需求信息中的行為，然后有步驟地實(shí)施需求建模，具體為:1）如何根據(jù)自然語言描述的需求，建立相應(yīng)場景信息。2）如何根據(jù)場景信息抽取與行為相關(guān)的信息，并利用行為描述語言建立行為表達(dá)式。3）如何建立行為描述語言的語義模型，為檢驗(yàn)復(fù)雜系統(tǒng)的各種特性奠定基礎(chǔ)。4）如何利用模型檢驗(yàn)方法和技術(shù)檢測復(fù)雜系統(tǒng)的一些特性。10-1-1基本概念1）視點(diǎn)一個(gè)觀察者（視點(diǎn)源）根據(jù)其關(guān)注點(diǎn)和某個(gè)問題域而提出的需求信息的集合構(gòu)成一個(gè)視點(diǎn)。2）視點(diǎn)模板視點(diǎn)模板是視點(diǎn)信息的存放形式，并由一些信息槽構(gòu)成。每個(gè)信息槽記錄了視點(diǎn)某方面的信息。3）視點(diǎn)間關(guān)系視點(diǎn)間關(guān)系是指兩個(gè)視點(diǎn)之間在問題域或者需求信息方面的聯(lián)系。重疊關(guān)系：指兩個(gè)視點(diǎn)的視點(diǎn)源的觀察領(lǐng)域存在一定程度的重合，其包括兩種情況：部分重合和完全重合。順序關(guān)系：指兩個(gè)視點(diǎn)在行為方面存在著先后關(guān)系，如兩個(gè)視點(diǎn)間存在著傳遞信息的行為等。無關(guān)系：指兩個(gè)視點(diǎn)在觀察領(lǐng)域上不存在重合，并且不具備行為上的先后關(guān)系，如兩個(gè)并行的視點(diǎn)等。當(dāng)且僅當(dāng)兩個(gè)視點(diǎn)是重疊關(guān)系或者順序關(guān)系時(shí)，它們具備依賴關(guān)系。10-1基本原理10-1-1基本概念4）軟件行為軟件的行為是指軟件運(yùn)行時(shí)作為主體，依照自身的功能對(duì)客體的施用、操作或動(dòng)作的過程，或主體施用一個(gè)服務(wù)、操作或動(dòng)作于客體。軟件的行為由行為主體和客體、操作或動(dòng)作、行為輸入/出和行為屬性等組成。5）行為主體行為主體可以是用戶或者問題域中的實(shí)體或概念。行為主體可以是復(fù)合主體，即一個(gè)行為可以有多個(gè)主體，且行為的主體必須是確定的。6）行為客體即行為的受體，通常指人或問題域中的實(shí)體或概念等。行為客體可以是復(fù)合客體，并且也可以是未確定的。10-1基本原理10-1-1基本概念7）主體的行為蹤跡：將同一主體在某一觀察時(shí)間段內(nèi)的行為以發(fā)生的時(shí)間順序用串的格式記錄下來，成為主體的行為蹤跡。8）行為的分類：目標(biāo)行為：為實(shí)現(xiàn)目標(biāo)需求而施行的行為。功能行為：直接面向功能需求的行為。目標(biāo)行為可以分解成一系列的功能行為，目標(biāo)是通過這些功能行為達(dá)到的。復(fù)合行為：由功能行為分解出的行為，且功能行為也可視為復(fù)合行為。每個(gè)功能行為可分解為一系列的復(fù)合行為，功能是由這些復(fù)合行為完成的。每個(gè)復(fù)合行為還可進(jìn)一步分解為原子行為。原子行為：不能再被分解的行為，具體為某個(gè)動(dòng)作或操作。10-1基本原理10-1-1基本概念9）場景:(見第3.7節(jié)的介紹）此處場景是指軟件系統(tǒng)在某一執(zhí)行期間內(nèi)按順序出現(xiàn)的一系列行為。場景描寫的范圍并不是固定的，既可以包括系統(tǒng)中發(fā)生的全部行為，也可以只包括由某些特定對(duì)象的行為。軟件需求可被描述成一系列場景，而每個(gè)場景則由一個(gè)或多個(gè)具體的行為所組成。10）行為的描述語言用于描述軟件系統(tǒng)行為的語言11）行為的操作語義行為的操作語義是行為描述語言的語義模型，其又分為靜態(tài)操作語義（用于定義行為表達(dá)式）和動(dòng)態(tài)操作語義。動(dòng)態(tài)操作語義是以動(dòng)作作為對(duì)象來研究在給定環(huán)境中行為狀態(tài)的變化。10-1基本原理10-1-2基本步驟面向軟件行為和視點(diǎn)的需求建模方法可以說是一種軟件方法?；谲浖袨楹鸵朁c(diǎn)的需求建模方法主要分為三個(gè)主要環(huán)節(jié)：首先是針對(duì)復(fù)雜系統(tǒng)劃分問題子域，根據(jù)問題域建立起多視點(diǎn)模型，其中每個(gè)視點(diǎn)應(yīng)屬于一個(gè)問題子域，并且包含一個(gè)或者多個(gè)場景。然后根據(jù)這些場景，用行為描述語言（BehaviorDescriptionLanguage，BDL)建立相應(yīng)的行為模型。最后在該行為模型的基礎(chǔ)上進(jìn)行視點(diǎn)內(nèi)及視點(diǎn)間的一致性檢測，包括語法和語義層面上的檢測，直到得到一個(gè)正確的需求模型。基于行為的需求建模方法的基本步驟如圖10-1所示。10-1基本原理10-1-2基本步驟1.劃分問題域?qū)τ趶?fù)雜系統(tǒng)，由于其對(duì)應(yīng)的問題域比較龐大和復(fù)雜，所以在需求分析的開始就需要將其分解為多個(gè)子問題域，然后根據(jù)每個(gè)子問題域施行需求分析。注意：問題域的劃分應(yīng)根據(jù)問題域的邏輯特性和內(nèi)部各成分間的邏輯關(guān)系進(jìn)行。2.標(biāo)識(shí)視點(diǎn)根據(jù)相應(yīng)的問題子域，從中找出所有的視點(diǎn)源及其關(guān)注點(diǎn)，并將它們標(biāo)識(shí)為視點(diǎn)，然后建立視點(diǎn)模板以及在該模板中填寫部分視點(diǎn)信息。3.描述需求從每個(gè)視點(diǎn)源獲取相關(guān)的需求信息，經(jīng)過分析整理，以自然語言的形式填入視點(diǎn)模板中“需求描述”信息槽。10-1基本原理10-1-2基本步驟4.建立場景建立場景的過程分為如下幾步:1）確定系統(tǒng)的所有行為和主體。2）確定有效的行為和主客體。去掉不正確和不必要的行為和行為主客體，保留那些與系統(tǒng)密切相關(guān)的行為和行為主客體。3）分析行為間的關(guān)系。行為間的執(zhí)行關(guān)系大體上可以分為順序、并行、交互、選擇等。行為在結(jié)構(gòu)上也可分為父行為與子行為之間的關(guān)系。4）構(gòu)建場景。一個(gè)場景是可以被感受到的系統(tǒng)的一個(gè)完整的功能。場景的描述主要用自然語言，而且根據(jù)已獲取的所有的有效行為并按它們的執(zhí)行順序構(gòu)成有序的行為系列，從而構(gòu)建出每一個(gè)場景。5.使用BDL建立行為模型使用行為描述語言來描述每個(gè)場景，并用行為表達(dá)式來表示場景中的內(nèi)容。在描述過程中可以采用逐步細(xì)化的方式來描述一個(gè)場景的行為模型。與所有場景對(duì)應(yīng)的多個(gè)行為表達(dá)式就構(gòu)成軟件系統(tǒng)的行為模型或需求模型。10-1基本原理10-1-2基本步驟6.建立異類需求模型為便于檢測使用其他建模技術(shù)和符號(hào)建立需求模型，有必要將需求描述語言BDL視為元語言，并將這些需求模型轉(zhuǎn)換為用BDL描述的形式（語法層的轉(zhuǎn)換)，即把非形式化或半形式化需求模型過渡到形式化，從而保證這些模型能用統(tǒng)一的語義表示，并為后面的模型檢測等后續(xù)工作提供基礎(chǔ)。7.檢測所有視點(diǎn)該步驟的檢測工作分為兩個(gè)方面：一方面是從語法的角度檢測視點(diǎn)內(nèi)行為表達(dá)式的正確性和行為間的一致性，檢測的內(nèi)容主要是行為表達(dá)的合法性、行為一致性和行為連續(xù)性等;另一方面是根據(jù)視點(diǎn)間的相關(guān)關(guān)系檢測視點(diǎn)間的行為一致性。8．修改需求及行為模型根據(jù)檢查結(jié)果，如果發(fā)現(xiàn)問題則修改相應(yīng)的視點(diǎn)的需求及其行為模型，直到每個(gè)視點(diǎn)都滿足檢查的要求。9．檢測軟件系統(tǒng)的部分特性綜合所有視點(diǎn)，最后得到軟件系統(tǒng)最終的需求模型。10-1基本原理10-2視點(diǎn)表示模型和視點(diǎn)管理視點(diǎn)表示模型和視點(diǎn)管理的重要性在面向行為和視點(diǎn)的需求建模方法中，視點(diǎn)表示模型和視點(diǎn)管理是十分重要的內(nèi)容。視點(diǎn)表示模型：規(guī)定了視點(diǎn)的描述內(nèi)容，并以視點(diǎn)模板的形式來表達(dá)視點(diǎn)。一個(gè)視點(diǎn)模板包括多個(gè)信息槽，信息槽記錄了該視點(diǎn)的所有相關(guān)需求信息，如需求描述、行為模型等。視點(diǎn)管理包括六大管理功能：問題域管理、視點(diǎn)生存過程管理、視點(diǎn)關(guān)系表管理、術(shù)語表及行為表管理、用戶管理和日志管理。10-2視點(diǎn)表示模型和視點(diǎn)管理10-2-1視點(diǎn)表示模型視點(diǎn)表示模型被表示成模板的形式，并稱為視點(diǎn)模板。視點(diǎn)模板存放與視點(diǎn)相關(guān)的信息，而且主要由一些信息槽構(gòu)成，每個(gè)信息槽記錄了視點(diǎn)的某一方面的信息。視點(diǎn)模板如表10-1所示。10-2視點(diǎn)表示模型和視點(diǎn)管理10-2-1視點(diǎn)表示模型其中，由于一個(gè)視點(diǎn)可能包含多個(gè)場景，所以視點(diǎn)模板的“場景描述”信息槽中應(yīng)該允許包含多個(gè)場景的描述，其表示形式如表10-2所示。與“場景描述”對(duì)應(yīng)的“行為模型”信息槽中的表示形式如表10-3所示:10-2視點(diǎn)表示模型和視點(diǎn)管理10-2-1視點(diǎn)表示模型場景標(biāo)識(shí)是唯一的，且原則上一個(gè)場景對(duì)應(yīng)一個(gè)場景行為模型。將一個(gè)視點(diǎn)中的多個(gè)場景行為模型可視為一個(gè)較大的視點(diǎn)行為模型?！捌渌Ｐ汀毙畔⒉蹫閺?fù)合信息，其至少包含一個(gè)該視點(diǎn)中用其他圖形建模技術(shù)或符號(hào)（如UML)建立的需求模型。該信息槽的表示形式如表10-4所示:10-2視點(diǎn)表示模型和視點(diǎn)管理10-2-2劃分問題域和標(biāo)識(shí)視點(diǎn)的具體步驟1.劃分問題域問題域是指與問題相關(guān)的部分現(xiàn)實(shí)世界。一個(gè)較為可行的方法是首先將復(fù)雜系統(tǒng)分解為多個(gè)問題子域，然后在每個(gè)問題子域內(nèi)標(biāo)識(shí)視點(diǎn)，使得每個(gè)視點(diǎn)都從屬于某一個(gè)問題子域。問題域劃分的具體步驟如下:1）開發(fā)人員與客戶、應(yīng)用（問題)領(lǐng)域?qū)＜业葘?duì)問題進(jìn)行交流。2）確定待開發(fā)系統(tǒng)問題域的邊界。3)將系統(tǒng)按照合理的方式劃分成多個(gè)問題子域。4）系統(tǒng)分析員登錄系統(tǒng)，在系統(tǒng)中新建或增添問題子域名。在問題子域名建立后通常不允許再修改，否則必須修改所有與該問題子域相關(guān)的信息。10-2視點(diǎn)表示模型和視點(diǎn)管理10-2-2劃分問題域的具體步驟2.標(biāo)識(shí)視點(diǎn)標(biāo)識(shí)視點(diǎn)是多視點(diǎn)需求工程的首要任務(wù)，也是應(yīng)用多視點(diǎn)需求工程方法時(shí)比較棘手的問題在每個(gè)問題子域中標(biāo)識(shí)視點(diǎn)相對(duì)于直接在整個(gè)系統(tǒng)中標(biāo)識(shí)視點(diǎn)要較為容易。標(biāo)識(shí)視點(diǎn)的具體步驟如下：對(duì)于每個(gè)問題子域:1）分析并確定該問題子域中存在的需求源（即視點(diǎn)源)。2）確定每個(gè)視點(diǎn)源對(duì)問題子域的關(guān)注點(diǎn)。3）根據(jù)關(guān)注點(diǎn)創(chuàng)建視點(diǎn)，生成視點(diǎn)模板。4）填寫視點(diǎn)基本信息，如視點(diǎn)標(biāo)識(shí)、視點(diǎn)責(zé)任人等。10-2視點(diǎn)表示模型和視點(diǎn)管理10-2-3視點(diǎn)管理視點(diǎn)管理主要包括6個(gè)方面的管理：問題域管理、視點(diǎn)生存過程管理、視點(diǎn)關(guān)系表管理、術(shù)語表及行為表管理、用戶管理和日志管理。其中，視點(diǎn)生存過程管理最為重要。1．問題域管理問題域管理主要是對(duì)劃分出的子問題域進(jìn)行管理。1）系統(tǒng)分析員對(duì)問題域進(jìn)行劃分后，需對(duì)劃分出的各個(gè)子問題域進(jìn)行命名，并確定各個(gè)子問題域間的關(guān)系。2）系統(tǒng)分析員或用戶向系統(tǒng)提交問題域劃分的結(jié)果后，系統(tǒng)會(huì)保存各個(gè)子問題域的名字和它們之間的關(guān)系。這兩者都是后續(xù)工作的重要基礎(chǔ)，所以問題域的劃分一旦提交，通常就不再允許任何形式的修改。10-2視點(diǎn)表示模型和視點(diǎn)管理10-2-3視點(diǎn)管理2.術(shù)語表及行為表管理建立術(shù)語表同劃分問題域一樣，也是需要系統(tǒng)分析員預(yù)先完成的工作。目的：在建模中使用統(tǒng)一的術(shù)語（或用語)，避免出現(xiàn)術(shù)語（或用語）不一致的情況。術(shù)語表由5項(xiàng)組成，分別是序號(hào)、標(biāo)識(shí)符、標(biāo)準(zhǔn)名稱、別名序列、所在視點(diǎn)及備注。在整個(gè)術(shù)語表中，標(biāo)識(shí)符應(yīng)該具有唯一性。而別名序列中可記錄同一指稱的多個(gè)別名。在系統(tǒng)開發(fā)結(jié)束前允許對(duì)術(shù)語表進(jìn)行動(dòng)態(tài)編輯。術(shù)語表中詞條的存儲(chǔ)形式如表10-5所示:10-2視點(diǎn)表示模型和視點(diǎn)管理10-2-3視點(diǎn)管理2.術(shù)語表及行為表管理行為表記錄了項(xiàng)目中需要標(biāo)識(shí)的行為名稱，其作用就是為了統(tǒng)一不同視點(diǎn)中的行為名。行為表的形式如表10-6所示:系統(tǒng)分析員和用戶在需求建模過程中可根據(jù)實(shí)際需要隨時(shí)定義或查詢術(shù)語表和行為表中的內(nèi)容。10-2視點(diǎn)表示模型和視點(diǎn)管理10-2-3視點(diǎn)管理3．視點(diǎn)生存過程管理視點(diǎn)生存過程管理是視點(diǎn)管理模塊的核心部分，它包括視點(diǎn)的創(chuàng)建、修改、刪除和查詢功能。(1）視點(diǎn)的創(chuàng)建創(chuàng)建一個(gè)視點(diǎn)，具體地說，就是添加一條視點(diǎn)記錄。記錄的格式由視點(diǎn)模板提供。用戶通過填寫視點(diǎn)模板中的各個(gè)信息槽來記錄一個(gè)視點(diǎn)的各種信息，有部分信息槽用戶無法填寫,需要系統(tǒng)分析員填入或在后續(xù)工作中補(bǔ)充。(2）視點(diǎn)的修改當(dāng)需求發(fā)生變更時(shí)，用戶需要修改自己的視點(diǎn)。用戶只能修改自己建立的視點(diǎn)，無權(quán)修改其他用戶的視點(diǎn)。視點(diǎn)模板中的信息槽分為面向系統(tǒng)的信息槽和面向用戶的信息槽。面向系統(tǒng)的信息槽：包括視點(diǎn)標(biāo)識(shí)、問題域、創(chuàng)建時(shí)間和最近修改時(shí)間等，這些信息是為系統(tǒng)管理提供的。面向用戶的信息槽：包括視點(diǎn)名稱、視點(diǎn)責(zé)任人、視點(diǎn)源、關(guān)注點(diǎn)、需求描述、場景描述、相關(guān)視點(diǎn)、行為模型和其他模型等，它們描述了待開發(fā)軟件的需求信息。10-2視點(diǎn)表示模型和視點(diǎn)管理10-2-3視點(diǎn)管理3．視點(diǎn)生存過程管理(3）視點(diǎn)的刪除與創(chuàng)建視點(diǎn)相反，刪除視點(diǎn)就是刪除一條視點(diǎn)記錄。當(dāng)一個(gè)視點(diǎn)被刪除后，它與其他所有視點(diǎn)間的關(guān)系也必須被同時(shí)刪除（由系統(tǒng)同時(shí)在視點(diǎn)關(guān)系表及視點(diǎn)模板中修改)。用戶只能刪除自己建立的視點(diǎn)。所有的刪除操作都會(huì)被系統(tǒng)日志記錄。(4）視點(diǎn)的查詢與視點(diǎn)的建立、修改和刪除相比，查詢只是一個(gè)附帶功能。它除了為系統(tǒng)開發(fā)人員服務(wù)之外，也可供其他經(jīng)過授權(quán)的人員使用，如公司領(lǐng)導(dǎo)和領(lǐng)域?qū)＜业?。根?jù)不同的權(quán)限，這類人員可以看到視點(diǎn)的部分或全部內(nèi)容，但不能進(jìn)行修改。10-3需求模型的具體構(gòu)建方法10-3需求模型的具體構(gòu)建方法面向?qū)ο蟮男枨蠼７椒ǖ膯栴}面向?qū)ο蟮男枨蠼Ｖ饕揽縐ML等建模技術(shù)來進(jìn)行需求建模。這種半形式化的建模方法雖然在定義、表達(dá)和理解等方面有著一定的優(yōu)勢，但卻在推理、驗(yàn)證和檢測等方面存在一些問題，如需求模型與源程序分離，各類模型之間相互獨(dú)立，無法進(jìn)行需求檢驗(yàn)和需求跟蹤，難以描述非功能需求等?；谛袨榈男枨蠼７椒嫦驈?fù)雜系統(tǒng)的需求建模方法應(yīng)根據(jù)復(fù)雜系統(tǒng)的特點(diǎn)進(jìn)行需求建模。在構(gòu)建復(fù)雜系統(tǒng)的需求模型時(shí)，基于行為的需求建模方法首先將問題域分解成若干個(gè)子問題域，然后根據(jù)不同的用戶視點(diǎn)建立系統(tǒng)的需求模型。最后使用行為描述語言和行為樹（或行為圖）等建模技術(shù)來建立系統(tǒng)的行為模型，并使用操作語義建立行為模型的語義模型，以對(duì)行為模型進(jìn)行各種檢測等。10-3需求模型的具體構(gòu)建方法10-3-1行為描述語言該語言主要用于描述待開發(fā)軟件系統(tǒng)的行為。1.行為模型的結(jié)構(gòu)場景行為模型的結(jié)構(gòu)如下:10-3需求模型的具體構(gòu)建方法10-3-1行為描述語言1.行為模型的結(jié)構(gòu)視點(diǎn)行為模型的結(jié)構(gòu)如下：系統(tǒng)行為模型的結(jié)構(gòu)如下:10-3需求模型的具體構(gòu)建方法10-3-1行為描述語言2.BDL的語法結(jié)構(gòu)定義令A(yù)BehID為原子行為標(biāo)識(shí)，BehID為行為標(biāo)識(shí)。(1）原子行為 1）原子行為表達(dá)式: 2）未確定客體的原子行為:10-3需求模型的具體構(gòu)建方法10-3-1行為描述語言2.BDL的語法結(jié)構(gòu)定義(1）原子行為 3）空動(dòng)作: 4）復(fù)合行為結(jié)束動(dòng)作: 5）調(diào)用共享場景:(2）簡單行為10-3需求模型的具體構(gòu)建方法10-3-1行為描述語言2.BDL的語法結(jié)構(gòu)定義(3）復(fù)合行為 1）順序行為：2）確定選擇行為：10-3需求模型的具體構(gòu)建方法10-3-1行為描述語言2.BDL的語法結(jié)構(gòu)定義(3）復(fù)合行為 3）非確定選擇行為：4）并行行為10-3需求模型的具體構(gòu)建方法10-3-2行為描述語言的動(dòng)態(tài)語義令B、Bi、B’,（i=1，2）為行為表達(dá)式，ABehID和α均為原子行為標(biāo)識(shí)。1.順序行為當(dāng)ABehID為B中不帶參數(shù)的最開始的原子行為，或是復(fù)合行為結(jié)束的原子行為時(shí):當(dāng)ABehID(xi）為B中帶參數(shù)的最開始的原子行為時(shí):當(dāng)空動(dòng)作Idle為B中最開始的原子行為時(shí):2.非確定選擇行為10-3需求模型的具體構(gòu)建方法10-3-2行為描述語言的動(dòng)態(tài)語義3.并行行為4.確定選擇行為10-3需求模型的具體構(gòu)建方法10-3-3構(gòu)建行為模型的具體過程下面介紹使用BDL建立基于行為的需求模型的具體過程：1.確定系統(tǒng)的所有行為和主體首先必須從自然語言描述的需求中歸納出描述場景的動(dòng)作和主客體。通過如下幾個(gè)方面可以發(fā)現(xiàn)場景中的動(dòng)作:1）提取動(dòng)賓短語得出組成場景的動(dòng)作，例如“輸人密碼”、“注冊(cè)用戶”、“選擇事務(wù)”等等。2）提取具有交易或接觸性質(zhì)的動(dòng)詞，得出組成場景的動(dòng)作，例如買賣、納稅、結(jié)婚等等。3）提取場景中隱含的動(dòng)作，得出組成場景的動(dòng)作，例如“分行請(qǐng)總行驗(yàn)證”，從中可以提取出隱含動(dòng)作“發(fā)送驗(yàn)證請(qǐng)求”等。10-3需求模型的具體構(gòu)建方法10-3-3構(gòu)建行為模型的具體過程1.確定系統(tǒng)的所有行為和主體有了構(gòu)成場景的動(dòng)作，然后必須從需求中歸納出系統(tǒng)中的行為主體以及客體，此處的行為主體不僅僅包括使用系統(tǒng)的用戶，還包括一切參與到行為中的實(shí)體和概念等。例如，可以通過如下幾個(gè)方面發(fā)現(xiàn)場景的行為主體(或客體):1）提取與上述動(dòng)作相關(guān)聯(lián)的主語(主體)，例如“用戶輸人密碼”中的“用戶”等。2）提取與上述動(dòng)作相關(guān)聯(lián)的賓語(客體)，例如“添加日志”中的“日志”等。3）提取與動(dòng)作相關(guān)聯(lián)的隱含的主語(主體)，例如“輸入密碼”，其隱含的主語為“普通用戶”或“管理員”等。4）提取與動(dòng)作相關(guān)聯(lián)的隱含的賓語(客體)，例如“用戶注銷”，其隱含的賓語為“系統(tǒng)”或“當(dāng)前事務(wù)”等。10-3需求模型的具體構(gòu)建方法10-3-3構(gòu)建行為模型的具體過程2.確定有效行為和主體通過上述方法獲取了需求相關(guān)的動(dòng)作和行為主體(或客體)之后，就必須對(duì)其進(jìn)行分析和篩選，去掉不正確和不必要的行為和行為主體(或客體)，保留那些與系統(tǒng)密切相關(guān)的行為和行為主體(或客體)。例如，可從如下幾個(gè)方面來對(duì)行為主體(或客體)進(jìn)行篩選：1)無關(guān)性?，F(xiàn)實(shí)世界中存在許多動(dòng)作和對(duì)象，不能把它們都納入到系統(tǒng)中，僅需要把與本問題密切相關(guān)的動(dòng)作和參與者放進(jìn)系統(tǒng)中。2)冗余性。如果兩個(gè)行為或者參與者表達(dá)了同樣的信息，則應(yīng)該保留在此場景中最富于描述力的名稱或表達(dá)更精確的描述。3)籠統(tǒng)性。在需求陳述中常常使用一些籠統(tǒng)的、泛指的動(dòng)詞或名詞，通常把這些籠統(tǒng)的或模糊的參與者或動(dòng)作去掉或者改寫為更加精確的描述。4)模糊性。在場景描述中有時(shí)可能使用一些既可作為名詞又可作為動(dòng)詞的詞匯，此時(shí)應(yīng)該慎重考慮它們?cè)诒緢鼍爸械暮x，以便正確地決定把它們作為行為還是參與者。10-3需求模型的具體構(gòu)建方法10-3-3構(gòu)建行為模型的具體過程3．建立行為間的關(guān)系行為間的執(zhí)行關(guān)系大體上可以分為順序、并行、交互、選擇等，行為在結(jié)構(gòu)上也可分為父行為與子行為之間的關(guān)系。在自然語言描述的需求場景中，通過分析描述性動(dòng)詞或動(dòng)詞詞組之間的關(guān)系，可以推導(dǎo)出行為間的關(guān)系。同時(shí)，通過分析場景，還能發(fā)現(xiàn)一些在陳述中隱含的關(guān)系。關(guān)系通過行為描述語言中的操作符來表示，比如‘；’表示順序關(guān)系，‘||’表示并行關(guān)系，‘＋'表示非確定選擇關(guān)系等。行為間的層次關(guān)系可通過行為樹來描述。樹中的節(jié)點(diǎn)代表單一主體的某個(gè)行為，子節(jié)點(diǎn)描述其子(功能)行為﹔樹中的邊，由行為定義中的父子關(guān)系以及子行為關(guān)系決定。10-3需求模型的具體構(gòu)建方法10-3-3構(gòu)建行為模型的具體過程4．建立場景通過前述方法中獲取的有效行為以及主體來構(gòu)建場景。場景可作為用例的一個(gè)部分，即系統(tǒng)完成的一系列動(dòng)作，動(dòng)作的結(jié)果能被特定的參與者察覺到。這些動(dòng)作除了完成系統(tǒng)內(nèi)部的計(jì)算與工作外，還包括與一些參與者的通信。場景具有下述特征:1）場景代表某些用戶可見的功能，實(shí)現(xiàn)一個(gè)具體的系統(tǒng)需求。2）場景總是被參與者啟動(dòng)的，并向參與者提供可識(shí)別的信息。3）場景必須是完整的。場景的實(shí)例是系統(tǒng)的一種實(shí)際使用方法，通常是系統(tǒng)的一次具體執(zhí)行過程，并由若干行為組成。10-3需求模型的具體構(gòu)建方法10-3-3構(gòu)建行為模型的具體過程4．建立場景由于前述步驟中已經(jīng)確定了行為的主體，故可以通過請(qǐng)每個(gè)行為主體回答下述問題來獲取場景:行為主體在系統(tǒng)中需要提供哪些功能?行為主體如何實(shí)現(xiàn)這些功能?行為主體是否需要讀取、創(chuàng)建、刪除、修改或存儲(chǔ)系統(tǒng)中的某類信息?系統(tǒng)中發(fā)生的事件需要通知行為主體嗎?行為主體需要處理這些事件嗎?還有一些不是針對(duì)具體行為主體而是針對(duì)整個(gè)系統(tǒng)的問題，也能幫助建模者發(fā)現(xiàn)場景，例如:系統(tǒng)需要哪些輸入輸出?輸人來自何處?輸出到哪里去?當(dāng)前使用的系統(tǒng)(可能是人工系統(tǒng))存在的主要問題是什么?場景的描述主要用自然語言，然后人工將其轉(zhuǎn)換為用BDL描述的行為表達(dá)式。場景之間亦可以建立關(guān)系以及精化處理。例如：向一個(gè)場景中添加一些動(dòng)作后構(gòu)成了另一個(gè)場景，這兩個(gè)場景之間的關(guān)系就是擴(kuò)展關(guān)系，后者繼承前者的一些行為。場景集合中的每個(gè)場景都是針對(duì)系統(tǒng)的一個(gè)潛在的需求。10-3需求模型的具體構(gòu)建方法10-3-3構(gòu)建行為模型的具體過程5．使用行為描述語言描述場景構(gòu)建行為模型時(shí)可采用逐步細(xì)化的方法，其描述過程可以遵循如下幾個(gè)步驟:1）用BDL描述場景內(nèi)的原子行為。原子行為是構(gòu)成場景形式化描述的最基本單位。2）建立場景內(nèi)行為之間的關(guān)系。即將原子行為組合成子行為，并建立子行為間的關(guān)系。3）建立視點(diǎn)行為模型內(nèi)場景之間的關(guān)系。即場景之間的關(guān)系與場景行為表達(dá)式之間的關(guān)系一致，主要包括順序、并行、非確定選擇。同時(shí)，場景之間也可以相互通信。使用BDL描述的行為集可以作為描述某個(gè)視點(diǎn)需求的行為模型或需求模型。行為模型可以幫助我們理解系統(tǒng)的行為，并且可以用于進(jìn)行系統(tǒng)的分析和設(shè)計(jì)。10-3需求模型的具體構(gòu)建方法10-3-3構(gòu)建行為模型的具體過程6．部分異類需求模型根據(jù)場景內(nèi)容建立行為模型的過程可以認(rèn)為是從非形式化過渡到形式化的需求建模過程?？赡苁褂闷渌＜夹g(shù)和符號(hào)建立需求模型，如時(shí)序圖、狀態(tài)圖、工作流圖、數(shù)據(jù)流圖等。有必要將BDL視為元語言，將其他建模技術(shù)和符號(hào)建立的模型轉(zhuǎn)換為BDL描述的形式（語法層的轉(zhuǎn)換），以保證語義的統(tǒng)一。處理部分異類需求模型的具體內(nèi)容將在10-3-6節(jié)中詳細(xì)說明。10-3需求模型的具體構(gòu)建方法10-3-4實(shí)例說明銀行自動(dòng)取款機(jī)系統(tǒng)（具體的需求描述見5.4.4節(jié)）：把該系統(tǒng)的需求模型分為3個(gè)視點(diǎn)、即ATM視點(diǎn)，總行視點(diǎn)和分行視點(diǎn)，且按前述的需求建模步驟說明如下。1.劃分問題域現(xiàn)將與該系統(tǒng)相關(guān)的問題域劃分為三個(gè):ATM、總行、分行。2.確定系統(tǒng)中所有的原子行為根據(jù)用自然語言描述的需求信息，找出該系統(tǒng)中所有的原子行為。需對(duì)上述的關(guān)系進(jìn)行篩選，以刪除不必要的和不正確的行為，并確定系統(tǒng)中所有有效原子行為。(1）直接提取動(dòng)詞短語得到行為，如：ATM、中央計(jì)算機(jī)、分行計(jì)算機(jī)及柜員終端組成的網(wǎng)絡(luò)系統(tǒng)，總行擁有多臺(tái)ATM等。10-3需求模型的具體構(gòu)建方法10-3-4實(shí)例說明2.確定系統(tǒng)中所有的原子行為(2）問題中隱含的行為，如：總行由各個(gè)分行組成，分行保管賬等。(3）通過問題分析而得到的行為，如：銀行卡訪問賬戶，分行雇傭柜員。3.標(biāo)識(shí)視點(diǎn)為便于說明，在此實(shí)例中假設(shè)每個(gè)問題子域有一個(gè)視點(diǎn)，并分別標(biāo)識(shí)為ATM視點(diǎn)(VPATM)、總行視點(diǎn)(VPHeadBank)、分行視點(diǎn)(VPLocalBank)。4.建立場景通過前述獲取的有效行為來構(gòu)建場景。在此實(shí)例中將ATM系統(tǒng)劃分為如下4個(gè)場景，而且為便于說明，在柜員終端場景中增加了一些具體的處理行為。10-3需求模型的具體構(gòu)建方法10-3-4實(shí)例說明4.建立場景4個(gè)場景分別描述如下：(1）0ATM的場景，如：ATM在顯示屏上顯示問候信息，顧客將磁卡插入ATM等。(2）總行的場景，如：總行擁有多臺(tái)ATM，總行由各個(gè)分行組成等。(3）分行的場景，如：分行負(fù)責(zé)提供分行計(jì)算機(jī)和柜員終端，分行計(jì)算機(jī)維護(hù)賬戶。(4）柜員終端的場景，如分行負(fù)責(zé)提供柜員終端，分行雇傭銀行柜員。5.使用行為描述語言建立行為模型根據(jù)劃分出的視點(diǎn)和場景分別建立各視點(diǎn)的行為模型，其中一個(gè)視點(diǎn)包含2個(gè)場景。ATM系統(tǒng)的行為模型(ATMSBM)詳見課本P158。10-3需求模型的具體構(gòu)建方法10-3-5圖形化輸入為克服用BDL建立的行為模型在可讀性和可理解性方面的效果相對(duì)于圖形方式要差這一缺點(diǎn)，本建模方法也提供圖形化輸人方式。圖形化輸入方式允許用戶以圖形結(jié)合文本的方式輸入目標(biāo)系統(tǒng)的行為模型，并進(jìn)行相應(yīng)的語法檢查。其主要功能包括:1）以圖形的方式輸人行為模型，定義原子行為、復(fù)合行為、行為表達(dá)式。2）檢查圖形文法。3）將圖形化的行為模型轉(zhuǎn)換為BDL語言描述的行為模型。10-3需求模型的具體構(gòu)建方法10-3-5圖形化輸入1.圖形化表示圖形表示的方法概要介紹如下:(1）視點(diǎn)的表示視點(diǎn)頁面保持原來的內(nèi)容不變。(2）場景的表示一個(gè)場景行為模型有一個(gè)唯一的標(biāo)志開始的圖形表示(shape)和一個(gè)唯一的標(biāo)志結(jié)束的圖形表示(見圖10-2)，分別代表場景行為模型表達(dá)式在BDL語言語法上的開始和結(jié)束。圖形表示中包含場景行為模型的ID以及文本內(nèi)容。10-3需求模型的具體構(gòu)建方法10-3-5圖形化輸入1.圖形化表示(3)行為的表示原子行為：一個(gè)原子行為的文本形式表示如下(其對(duì)應(yīng)的形狀如圖10-3所示):其中，用文本來表示行為中的各個(gè)參數(shù)，如行為表示是一個(gè)字符串。對(duì)于帶參數(shù)的Return和不帶參數(shù)的Return行為，提供以下兩種待選方案:1)對(duì)應(yīng)的圖形帶一個(gè)箭頭，若箭頭指向某個(gè)行為，則跳轉(zhuǎn)到該行為，否則箭頭指向結(jié)束。2）對(duì)應(yīng)的圖形中添加一個(gè)字符串，字符串表示Return跳轉(zhuǎn)的目的行為。復(fù)合行為：一個(gè)復(fù)合行為由多個(gè)行為組成，其對(duì)應(yīng)的形狀如圖10-4所示。10-3需求模型的具體構(gòu)建方法10-3-5圖形化輸入1.圖形化表示(4)行為間關(guān)系的表示順序關(guān)系：順序關(guān)系“;”用一個(gè)表示順序行為的箭頭“→”給予表示(箭頭同時(shí)也表示其他運(yùn)算中的關(guān)系)。箭頭的起止端分別為兩個(gè)行為(原子行為、復(fù)合行為或行為表達(dá)式)的對(duì)應(yīng)圖形。非確定選擇關(guān)系：非確定選擇關(guān)系“＋”用如圖10-5所示的兩個(gè)圖形“非確定選擇開始”、“非確定選擇結(jié)束”分別標(biāo)志非確定選擇運(yùn)算“+”在BDL語言語法上的開始、結(jié)束。并行關(guān)系：并行關(guān)系“||”用如圖10-6所示的兩個(gè)圖形“并行開始”、“并行結(jié)束”分別標(biāo)志并行運(yùn)算“||”在BDL語言語法上的開始、結(jié)束。10-3需求模型的具體構(gòu)建方法10-3-5圖形化輸入1.圖形化表示(4)行為間關(guān)系的表示確定選擇關(guān)系：確定選擇關(guān)系“if-then-else”用如圖10-7所示的兩個(gè)圖形“確定性選擇開始”、“確定性選擇結(jié)束”分別標(biāo)志確定選擇運(yùn)算“if-then-else”在BDL語言語法上的開始、結(jié)束。10-3需求模型的具體構(gòu)建方法10-3-5圖形化輸入2.圖形化行為模型文件圖形化輸出的目標(biāo)系統(tǒng)行為模型文件以vsd文件保存。對(duì)于該文件，提供以下的檢查和處理:1)圖形文法的檢查。該檢查識(shí)別用戶輸入的圖形化行為模型是否滿足以上圖形輸人方案。如各種開始符和結(jié)束符的對(duì)應(yīng)、確定選擇運(yùn)算的嵌套等。2)圖形化模型的轉(zhuǎn)換。將圖形化定義的行為模型轉(zhuǎn)換為BDL語言描述的行為模型，后續(xù)的語法檢查、一致性檢查等都以按文本方式保存的BDL行為模型文件為準(zhǔn)。10-3需求模型的具體構(gòu)建方法10-3-5圖形化輸入3.圖形化行為模型以下為ATM系統(tǒng)總行場景實(shí)例的BDL行為模型及相應(yīng)的圖形化行為模型(見圖10-8)。10-3需求模型的具體構(gòu)建方法10-3-6異類視點(diǎn)需求模型的轉(zhuǎn)換實(shí)現(xiàn)(1)相關(guān)定義UML狀態(tài)圖(類似于5.4.3節(jié)介紹的擴(kuò)充的狀態(tài)轉(zhuǎn)換圖)是UML中有關(guān)系統(tǒng)動(dòng)態(tài)方面建模的圖形工具之一，并用于描述對(duì)象隨時(shí)間變化的動(dòng)態(tài)行為。UML狀態(tài)圖作為描述反應(yīng)式系統(tǒng)和實(shí)時(shí)系統(tǒng)行為的圖形語言，它對(duì)傳統(tǒng)的有限狀態(tài)機(jī)進(jìn)行了三個(gè)方面的擴(kuò)充:層次(hierarchy)——通過狀態(tài)嵌套實(shí)現(xiàn)，一個(gè)狀態(tài)可由多個(gè)狀態(tài)組成，即一個(gè)狀態(tài)可求精成另一個(gè)狀態(tài)圖;并發(fā)(concurrency)——允許多個(gè)復(fù)合狀態(tài)并發(fā)執(zhí)行；廣播通信(broad-castcommunication——并發(fā)狀態(tài)的通信是通過事件廣播來實(shí)現(xiàn)的。10-3需求模型的具體構(gòu)建方法10-3-6異類視點(diǎn)需求模型的轉(zhuǎn)換實(shí)現(xiàn)(1)相關(guān)定義為了使UML狀態(tài)圖既能滿足其標(biāo)準(zhǔn)規(guī)范，又能滿足轉(zhuǎn)換成BDL的要求，我們約定了UML狀態(tài)圖的層次狀態(tài)圖規(guī)范，即結(jié)構(gòu)化的圖層嵌套關(guān)系，如圖10-9所示，其中圖形符號(hào)含義及其與BDL的對(duì)應(yīng)關(guān)系請(qǐng)見后文說明。10-3需求模型的具體構(gòu)建方法10-3-6異類視點(diǎn)需求模型的轉(zhuǎn)換實(shí)現(xiàn)(2)狀態(tài)符號(hào)與BDL結(jié)構(gòu)的對(duì)應(yīng)關(guān)系圖10-9中主要使用了UML狀態(tài)圖中的初始狀態(tài)、最終狀態(tài)、狀態(tài)、復(fù)合狀態(tài)、轉(zhuǎn)換、分叉轉(zhuǎn)換、集結(jié)轉(zhuǎn)換及判定等符號(hào)(暫不考慮其他的符號(hào))，且所使用的這些符號(hào)與BDL中的各個(gè)結(jié)構(gòu)的對(duì)應(yīng)關(guān)系如下:1）初始狀態(tài)和最終狀態(tài)(如圖10-10所示)：每個(gè)狀態(tài)圖或子狀態(tài)圖中只允許有一個(gè)初始狀態(tài)和最終狀態(tài)，并且成對(duì)出現(xiàn)。2）轉(zhuǎn)換：UML狀態(tài)圖中轉(zhuǎn)換的符號(hào)表示如圖10-11所示。UML狀態(tài)圖的轉(zhuǎn)換對(duì)應(yīng)BDL中的順序關(guān)系，即“;”。10-3需求模型的具體構(gòu)建方法10-3-6異類視點(diǎn)需求模型的轉(zhuǎn)換實(shí)現(xiàn)(2)狀態(tài)符號(hào)與BDL結(jié)構(gòu)的對(duì)應(yīng)關(guān)系5）狀態(tài)：狀態(tài)的符號(hào)表示如圖10-14所示。狀態(tài)名對(duì)應(yīng)于BDL中的原子動(dòng)作ID，關(guān)于狀態(tài)的說明(相關(guān)參數(shù))對(duì)應(yīng)于BDL中原子動(dòng)作的定義，即：注：根據(jù)狀態(tài)的說明可以將狀態(tài)與BDL的原子動(dòng)作、空動(dòng)作Idle、返回動(dòng)作Return相對(duì)應(yīng)。6）復(fù)合狀態(tài)：復(fù)合狀態(tài)的符號(hào)表示如圖10-15所示。一個(gè)復(fù)合狀態(tài)對(duì)應(yīng)一個(gè)子狀態(tài)圖，在該子狀態(tài)圖中可使用上述列舉的圖形符號(hào)等。10-3需求模型的具體構(gòu)建方法10-3-6異類視點(diǎn)需求模型的轉(zhuǎn)換實(shí)現(xiàn)(3）轉(zhuǎn)換實(shí)現(xiàn)的流程主要工作：將UML狀態(tài)圖描述轉(zhuǎn)換為所對(duì)應(yīng)的BDL語言。轉(zhuǎn)換實(shí)現(xiàn)流程如圖10-16所示，具體過程如下:①建立或打開視點(diǎn)。在新建或已存在的項(xiàng)目中編輯視點(diǎn)有兩種選擇：一是采用BDL的建模方法，對(duì)需求按照?qǐng)鼍皠澐?，直接建立基于BDL的視點(diǎn)模型。二是先使用其他(除BDL外)建模技術(shù)和建模符號(hào)建立異類視點(diǎn)需求模型，然后再將其轉(zhuǎn)換成BDL形式。②建立或編輯UML狀態(tài)圖。用Visio中的UML狀態(tài)圖對(duì)一個(gè)視點(diǎn)進(jìn)行需求建模，其建模所用到的符號(hào)及具體規(guī)約請(qǐng)參閱本節(jié)(2)的闡述。10-3需求模型的具體構(gòu)建方法10-3-6異類視點(diǎn)需求模型的轉(zhuǎn)換實(shí)現(xiàn)(3）轉(zhuǎn)換實(shí)現(xiàn)的流程③圖形文法檢查。該檢查識(shí)別基于UML狀態(tài)圖的異類視點(diǎn)需求模型是否滿足本節(jié)(2)中所做的規(guī)約。④狀態(tài)圖->BDL。如果在圖形文法檢查過程中發(fā)現(xiàn)異類視點(diǎn)需求模型不滿足規(guī)約要求，則提示用戶對(duì)狀態(tài)圖進(jìn)行修改。反之，在滿足圖形文法檢查的條件下，可以將基于狀態(tài)圖的異類視點(diǎn)需求模型轉(zhuǎn)換為BDL描述。⑤生成文本文件。將基于UML狀態(tài)圖的視點(diǎn)需求模型轉(zhuǎn)換為BDL語言描述的行為模型，以文本的形式輸出。后續(xù)的語法檢查、一致性檢查等都以按文本方式保存的BDL行為模型文件為準(zhǔn)。生成文本時(shí)，若相同名稱的文本行為模型已經(jīng)存在，則覆蓋已有的文件。⑥BDL語法檢查。在項(xiàng)目中對(duì)轉(zhuǎn)換為BDL后的異類視點(diǎn)需求模型進(jìn)行語法檢查。在檢查異類視點(diǎn)需求模型時(shí)，若該視點(diǎn)的BDL需求描述與BDL的語法不符，則返回②。10-4需求模型的檢測方法視點(diǎn)檢測視點(diǎn)檢測主要包括三部分：即語法檢查、語義檢查和系統(tǒng)特性檢測。其中，前兩項(xiàng)檢查需要分別在視點(diǎn)內(nèi)及視點(diǎn)間進(jìn)行，系統(tǒng)特性檢測主要利用行為時(shí)序邏輯進(jìn)行檢查。與視點(diǎn)檢測相關(guān)的一些概念的形式化定義如右圖所示。10-4需求模型的檢測方法10-4需求模型的檢測方法10-4-1檢測內(nèi)容1.行為表達(dá)合法性指一個(gè)行為表達(dá)式能滿足行為描述語言的語法。2.含輸入/輸出行為的一致性含輸人/輸出行為的一致性分為視點(diǎn)內(nèi)的與視點(diǎn)間的。1)視點(diǎn)內(nèi)含輸入/輸出行為的一致性:給定一個(gè)視點(diǎn)行為模型，稱其中含輸人/輸出的行為是一致的，如果該視點(diǎn)行為模型中的某些含輸出的行為都存在一個(gè)與其匹配的含輸入的行為，且該行為在本視點(diǎn)模型中。10-4需求模型的檢測方法10-4-1檢測內(nèi)容2.含輸入/輸出行為的一致性2）視點(diǎn)間含輸入/輸出行為的一致性:假設(shè)系統(tǒng)行為模型中存在兩個(gè)視點(diǎn)V1與V2，稱視點(diǎn)V1與V2中含輸人/輸出的行為是一致的，如果V1的行為模型中存在一個(gè)與V2相關(guān)的帶輸出參數(shù)的行為，并且V2的行為模型中至少存在一個(gè)與1，輸出參數(shù)匹配的輸入?yún)?shù)(即數(shù)據(jù)名相同)的行為。或者，反之也成立。3.行為完整性行為完整性指在一個(gè)行為模型中行為與行為之間至少存在一條執(zhí)行路徑，即行為間存在可達(dá)關(guān)系。4.視點(diǎn)間行為一致性視點(diǎn)間行為一致性是指在一個(gè)由多個(gè)視點(diǎn)構(gòu)成的系統(tǒng)行為模型中，如果其中兩個(gè)視點(diǎn)出現(xiàn)重疊，則對(duì)于重疊部分中相同行為的理解和描述應(yīng)該是相同的。10-4需求模型的檢測方法10-4-1檢測內(nèi)容5.行為有效性行為有效性表示一個(gè)行為模型總能夠按照預(yù)期的方式運(yùn)行。檢測行為有效性方法的基本原理如圖10-17所示。10-4需求模型的檢測方法10-4-2檢測過程系統(tǒng)行為模型的檢測過程如圖10-18所示。10-4-3檢測過程中個(gè)檢測方法的具體實(shí)現(xiàn)1.行為表達(dá)合法性根據(jù)行為描述語言的語法，設(shè)計(jì)等價(jià)的LALR(1)文法，利用輔助工具(FLEX，BI-SON)設(shè)計(jì)一個(gè)語法分析器，檢查行為表達(dá)式是否滿足描述語言的語法。2.含輸入/輸出行為的一致性根據(jù)行為表達(dá)式構(gòu)建行為樹，然后遍歷行為樹，搜索相關(guān)行為的輸入與輸出。3.行為完整性遍歷行為樹，記錄所有可達(dá)的行為，然后與行為表達(dá)式中定義的行為比較，判斷是否有行為不可達(dá)。10-4需求模型的檢測方法10-4-3檢測過程中個(gè)檢測方法的具體實(shí)現(xiàn)4．視點(diǎn)間行為一致性視點(diǎn)間行為一致性檢測的具體步驟如圖10-19所示。檢測以下情況：在一個(gè)由多個(gè)視點(diǎn)構(gòu)成的系統(tǒng)行為模型中，如果其中兩個(gè)視點(diǎn)出現(xiàn)重疊，則對(duì)于重疊部分中相同行為的理解和描述應(yīng)該是相同的。具體步驟如下:10-4需求模型的檢測方法10-4-3檢測過程中個(gè)檢測方法的具體實(shí)現(xiàn)4．行為有效性系統(tǒng)行為有效性檢測是檢測一個(gè)行為模型總能夠按照預(yù)期的方式運(yùn)行，具體檢測步驟如圖10-20所示：步驟1：確定系統(tǒng)行為模型中的條件表達(dá)式的真值。步驟2：將系統(tǒng)行為模型轉(zhuǎn)換為等價(jià)的通信演算系統(tǒng)(CCS)模型。步驟3：獲取用時(shí)序邏輯公式描述的行為有效性表達(dá)式。步驟4：將步驟2中的操作語義模型和步驟3中的有效性公式代人到模型檢測工具中進(jìn)行自動(dòng)檢測。步驟5:顯示檢測的結(jié)果。步驟6:若檢測結(jié)果有問題則修改需求模型，直到滿足系統(tǒng)行為有效性為止。10-5基于行為模型的需求可視化10-5基于行為模型的需求可視化需求動(dòng)畫需求動(dòng)畫是需求驗(yàn)證的具體技術(shù)之一，其可以提高需求驗(yàn)證的效率和可信度，有助于用戶與軟件開發(fā)人員間的交流。本節(jié)介紹的需求可視化方法是在分析國內(nèi)外現(xiàn)有研究的基礎(chǔ)上開發(fā)而成。利用該方法，只需少量的人工輔助，就可以實(shí)現(xiàn)從需求模型到需求動(dòng)畫的逐步轉(zhuǎn)換實(shí)現(xiàn)，圖10-21表示了該方法的基本原理。10-5基于行為模型的需求可視化需求動(dòng)畫的基本原理(1）建立基于軟件行為的需求建模方法目的：將用戶需求轉(zhuǎn)化為軟件行為模型，并用半形式化、形式化的建模語言表達(dá)復(fù)雜系統(tǒng)的軟件行為及行為間的相互作用。該方法的關(guān)鍵技術(shù)問題包括從自然語言表達(dá)的需求中抽取出與行為相關(guān)的細(xì)節(jié)，如何用建模語言表達(dá)軟件行為以及如何描述軟件行為之間的相互作用。(2）建立動(dòng)畫描述模型(從需求模型到動(dòng)畫描述模型的轉(zhuǎn)換)動(dòng)畫描述模型是需求動(dòng)畫的執(zhí)行基礎(chǔ)，主要用于描述動(dòng)畫的組成結(jié)構(gòu)、執(zhí)行過程、軟件行為與動(dòng)畫動(dòng)作的關(guān)聯(lián)和用戶需求中的對(duì)象與動(dòng)畫部件的關(guān)聯(lián)等靜態(tài)信息，它在行為模型與動(dòng)畫執(zhí)行引擎間起著橋接作用。(3）建立動(dòng)畫執(zhí)行引擎動(dòng)畫執(zhí)行引擎主要用于解釋執(zhí)行動(dòng)畫描述模型，以及實(shí)際控制舞臺(tái)動(dòng)畫的執(zhí)行。首先需要考慮如何解釋動(dòng)畫描述模型，以及根據(jù)動(dòng)畫描述模型設(shè)計(jì)和生成控制動(dòng)畫運(yùn)行的具體動(dòng)作。10-5基于行為模型的需求可視化需求動(dòng)畫的基本原理(4）提供輔助動(dòng)畫制作的機(jī)制為了使用戶能有效和較容易地進(jìn)行動(dòng)畫設(shè)計(jì)，需要?dú)w納不同需求模型中的行為模式和行為對(duì)象，建立開放的動(dòng)作庫和動(dòng)畫部件庫，使開發(fā)人員能基于動(dòng)作庫構(gòu)造各種復(fù)雜行為的動(dòng)畫執(zhí)行，使用動(dòng)畫部件庫中的圖形符號(hào)直觀地表達(dá)需求中的各種對(duì)象等。圖10-22表示了該方法的具體實(shí)現(xiàn)過程。10-5基于行為模型的需求可視化需求動(dòng)畫的基本原理(4）提供輔助動(dòng)畫制作的機(jī)制利用上述需求動(dòng)畫方法和技術(shù)實(shí)現(xiàn)的自動(dòng)取款機(jī)系統(tǒng)的動(dòng)畫界面如圖10-23所示。該圖表現(xiàn)的是：在正常取款的場景中，用戶提交的卡號(hào)和密碼信息在由ATM加密以后，正通過總行發(fā)送到開戶分行進(jìn)行驗(yàn)證。未來開戶分行接收到相應(yīng)的加密信息后，將把該信息與分行數(shù)據(jù)庫中的用戶信息進(jìn)行比較和驗(yàn)證，用來確定該賬戶的合法性。10-6需求建模方法的特點(diǎn)10-6需求建模方法的特點(diǎn)面向復(fù)雜系統(tǒng)的需求建模方法的特點(diǎn)(1）創(chuàng)新的需求工程建模方法該建模方法基于多視點(diǎn)和軟件行為建模，有別于現(xiàn)有的一些需求建模方法和技術(shù)。該建模方法完整地、系統(tǒng)地給出了需求建模的具體流程和步驟、行為描述語言及其語義、自動(dòng)檢測需求模型的方法和步驟等。(2）靈活的視點(diǎn)表示模型為了表示用戶的視點(diǎn)，視點(diǎn)表示模型使用視點(diǎn)模板的形式來表達(dá)和存放與視點(diǎn)相關(guān)的信息。視點(diǎn)模板：規(guī)定了視點(diǎn)的基本描述內(nèi)容。一個(gè)視點(diǎn)模板包括多個(gè)信息槽，每個(gè)信息槽分別記錄了該視點(diǎn)的部分需求信息，如視點(diǎn)名、建立視點(diǎn)的時(shí)間、相關(guān)的視點(diǎn)等，用戶可根據(jù)自己的需要在模板中填寫相應(yīng)的信息。在視點(diǎn)模板中可以存放不同形式的、與視點(diǎn)相關(guān)的信息，如用文本方式描述的用戶需求，用圖形或BDL語言方式表達(dá)的行為模型等。10-6需求建模方法的特點(diǎn)面向復(fù)雜系統(tǒng)的需求建模方法的特點(diǎn)(3）易于理解和使用的需求建模語言BDLBDL：一種語法結(jié)構(gòu)簡單的語言。該語言雖然具有形式語言的嚴(yán)格性，如提供了嚴(yán)格的語法和動(dòng)態(tài)語義，但與現(xiàn)有的形式化建模語言相比而言，它具有易使用和易理解的特點(diǎn)。(4）多樣化的、嚴(yán)格的需求模型檢測方法根據(jù)形式化的需求模型的特點(diǎn)，我們提出和實(shí)現(xiàn)了多種檢測需求模型的方法。這些方法大致可分為語法和語義兩個(gè)方面。其中，語法檢測是為保證基于行為需求模型的語法正確性，如行為表達(dá)合法性、含輸入/輸出行為的一致性和行為完整性等。語義檢測是基于視點(diǎn)相對(duì)獨(dú)立的特點(diǎn)和檢測系統(tǒng)特性的需要，特別是在檢測系統(tǒng)特性時(shí)使用了模型檢測的基本原理和行為時(shí)序邏輯理論。10-6需求建模方法的特點(diǎn)面向復(fù)雜系統(tǒng)的需求建模方法的特點(diǎn)(5）具有較好的兼容性和可擴(kuò)展性該方法能與一些其他的現(xiàn)有建模方法和技術(shù)銜接，即可將行為描述語言作為元語言來表達(dá)一些其他建模技術(shù)和符號(hào)，如時(shí)序圖、狀態(tài)圖、工作流圖、數(shù)據(jù)流圖等一些半形式化的圖形建模技術(shù)，使得不同的建模方法和技術(shù)能有統(tǒng)一的形式語義，并為需求檢測奠定基礎(chǔ)。該方法的形式化工作也考慮與現(xiàn)有的形式化設(shè)計(jì)方法的銜接，如B方法等。在該方法的基礎(chǔ)上可繼續(xù)延伸以支持軟件的設(shè)計(jì)和實(shí)現(xiàn)工作。10-7進(jìn)一步的研究10-7進(jìn)一步的研究10-7-1方法的實(shí)現(xiàn)我們已基于前述的需求建模和檢測方法自主研制出面向復(fù)雜系統(tǒng)的需求工程建模工具系統(tǒng)的原型。該系統(tǒng)主要以前述的需求工程建模方法為基礎(chǔ)，從多視點(diǎn)和軟件行為的角度為軟件開發(fā)人員提供了實(shí)用的建立需求模型和分析用戶需求的功能，能夠更清晰地表達(dá)用戶的意圖，且建模工具系統(tǒng)的操作簡單，便于開發(fā)人員掌握和使用。該系統(tǒng)的實(shí)現(xiàn)是在MicrosoftVisio2007工具上進(jìn)行二次開發(fā)，利用Visio的圖形界面接口，實(shí)現(xiàn)了建模過程的可視化。為了驗(yàn)證和評(píng)價(jià)本章介紹的需求建模和檢測方法，以及需求建模工具系統(tǒng)的實(shí)用性和有效性，我們使用了一些不同類型和不同應(yīng)用領(lǐng)域的實(shí)際軟件系統(tǒng)作為實(shí)例，并在需求建模工具系統(tǒng)中進(jìn)行了實(shí)驗(yàn)，獲得了較理想的結(jié)果。10-7進(jìn)一步的研究10-7-1方法的實(shí)現(xiàn)我們已基于前述的需求建模和檢測方法自主研制出面向復(fù)雜系統(tǒng)的需求工程建模工具系統(tǒng)的原型。該系統(tǒng)主要以前述的需求工程建模方法為基礎(chǔ)，從多視點(diǎn)和軟件行為的角度為軟件開發(fā)人員提供了實(shí)用的建立需求模型和分析用戶需求的功能，能夠更清晰地表達(dá)用戶的意圖，且建模工具系統(tǒng)的操作簡單，便于開發(fā)人員掌握和使用。該系統(tǒng)的實(shí)現(xiàn)是在MicrosoftVisio2007工具上進(jìn)行二次開發(fā)，利用Visio的圖形界面接口，實(shí)現(xiàn)了建模過程的可視化。為了驗(yàn)證和評(píng)價(jià)本章介紹的需求建模和檢測方法，以及需求建模工具系統(tǒng)的實(shí)用性和有效性，我們使用了一些不同類型和不同應(yīng)用領(lǐng)域的實(shí)際軟件系統(tǒng)作為實(shí)例，并在需求建模工具系統(tǒng)中進(jìn)行了實(shí)驗(yàn)，獲得了較理想的結(jié)果。如：校園通系統(tǒng)(類型：實(shí)時(shí)系統(tǒng)和信息管理；應(yīng)用領(lǐng)域：教育)。10-7進(jìn)一步的研究10-7-2有待研究的問題目前的軟件需求開發(fā)工作還存在許多不足之處，主要表現(xiàn)在如下幾個(gè)方面:1）高層次的系統(tǒng)需求分析階段易于與軟件實(shí)現(xiàn)階段脫節(jié)。2）由于上述的脫節(jié)，也使得系統(tǒng)需求分析階段對(duì)需求模型的檢測與軟件測試階段對(duì)源程序的測試工作脫節(jié)，導(dǎo)致需花費(fèi)很多精力和成本來重復(fù)設(shè)計(jì)測試用例。3）如何將需求模型有效地應(yīng)用于軟件實(shí)現(xiàn)工作中，即能否根據(jù)需求模型來進(jìn)行軟件的設(shè)計(jì)和實(shí)現(xiàn)，還有待于探討?；谏鲜龃嬖诘膯栴}，有必要根據(jù)前述建模方法的特點(diǎn)(如特點(diǎn)3)，進(jìn)一步研究在前述建模方法基礎(chǔ)上的、面向某一應(yīng)用領(lǐng)域(如嵌入式實(shí)時(shí)系統(tǒng)軟件)的、可從需求模型到代碼生成的方法及其工具系統(tǒng)，并通過一定的人工干預(yù)和調(diào)整(因?yàn)槌绦蜃詣?dòng)生成的理論與技術(shù)還不夠成熟)，支持源代碼的生成。第11章面向問題域的

需求分析方法

目錄問題域的劃分問題框架11-211-311-411-511-6PDOA方法的分析步驟問題框架實(shí)例間的關(guān)系及其組合需求測試11-1問題域11-1問題域問題域的定義所謂問題域是指與問題相關(guān)的部分現(xiàn)實(shí)世界。問題域和問題相互依存，問題處于一定的問題域之中，脫離了問題域，問題就無法存在。問題域也是與特定的問題相關(guān)的現(xiàn)實(shí)世界,脫離特定的問題考慮純粹的問題域沒有任何意義。如圖所示，上面的三種描述橫跨兩種類型的域:需求分析文檔全部包含在問題域中，與機(jī)器域無關(guān);程序作用在機(jī)器域中，與問題域無關(guān);而規(guī)格說明文檔描述問題域與機(jī)器域之間的接口。這三類描述除所處的域類型、關(guān)注的內(nèi)容不同外，相互之間也存在一定的關(guān)系,即需求規(guī)格說明文檔可以看作是把需求分析文檔轉(zhuǎn)換為接口處的描述,程序則是使計(jì)算機(jī)按需求規(guī)格說明文檔中所描述的那樣運(yùn)行。11-1問題域11-2問題域的劃分對(duì)于復(fù)雜問題的分析，一般的做法是采用“分而治之”的策略。人們一般采用層次式功能分解的方法。1.確定系統(tǒng)所需的各項(xiàng)功能；2.若某些（或個(gè)）功能對(duì)應(yīng)于一個(gè)足夠小的具體實(shí)現(xiàn)單元，則由該實(shí)現(xiàn)單元直接實(shí)現(xiàn)這些（或個(gè)）功能；3.否則，把功能分解為一系列子功能，并重復(fù)步驟2和3，直到所有子功能可分別對(duì)應(yīng)一個(gè)足夠小的具體實(shí)現(xiàn)單元。11-2問題域的劃分層次式分解方法的不足把高層功能分解成子功能的方式可能有多種，但沒有任何方法可以提前告知這些分解方式中哪一個(gè)好或哪一個(gè)差，直到進(jìn)入實(shí)現(xiàn)階段時(shí)才可評(píng)價(jià)所采用的分解方式是否恰當(dāng)，而此時(shí)分解活動(dòng)早已結(jié)束。

分治策略并行劃分：將每個(gè)子問題看成是整個(gè)問題的一個(gè)投影，通過不同角度的投影，將整個(gè)問題分解為一系列相互關(guān)聯(lián)的子問題。其中子問題的需求是整個(gè)需求的一個(gè)投影，它的接口也是整個(gè)問題接口的一個(gè)投影。同時(shí)，在劃分子問題的過程中，以已知解決方案的問題或以已知解決方案的相似問題為導(dǎo)向，來對(duì)未知解決方案的整個(gè)待求解問題進(jìn)行恰當(dāng)?shù)姆治龊蛣澐帧.Jackson提出的并行劃分11-2問題域的劃分11-3問題框架軟件開發(fā)的五類問題需求式行為問題、命令式行為問題、信息顯示問題、工件問題和變換問題。M.Jackson對(duì)每類基本問題的基本性質(zhì)、所涉及問題域的類型、每類問題所涉及的問題域、用戶需求和機(jī)器域之間的拓?fù)浣Y(jié)構(gòu)、應(yīng)滿足的關(guān)系及其性質(zhì)等進(jìn)行了研究,提出了這五類基本問題對(duì)應(yīng)的五個(gè)不同的基本問題框架，并將這些問題框架用于對(duì)每種類型的基本問題進(jìn)行描述和需求建模,同時(shí)對(duì)每個(gè)基本問題框架的可能變體進(jìn)行了研究。11-3問題框架問題框架是一種模式，它捕獲并定義了常見的簡單子問題的類型。問題框架的作用類似于設(shè)計(jì)模式,只是前者用于問題的分析和描述,后者用于解決方案的設(shè)計(jì)。11-4問題框架的類型對(duì)軟件系統(tǒng)進(jìn)行了各種分類,試圖為同類型軟件的開發(fā)提供有益的指南或方法。常見的分類方式如:按系統(tǒng)軟件和應(yīng)用軟件分類，進(jìn)一步將后者劃分為商業(yè)軟件和工程軟件兩類。按批處理系統(tǒng)/脫機(jī)系統(tǒng)、交互系統(tǒng)和實(shí)時(shí)系統(tǒng)等分類。按以數(shù)據(jù)處理為主的系統(tǒng)、交互為主的系統(tǒng)和算法為主的系統(tǒng)等分類。問題框架可根據(jù)問題域特征、接口特征和需求特征定義一個(gè)直觀的、可標(biāo)識(shí)的問題類。對(duì)于上面所提及的五類基本問題，可以用五個(gè)不同的基本問題框架分別進(jìn)行描述。在形式上，一個(gè)問題框架類似于一個(gè)問題圖。與問題圖稍微不同的是,問題框架中對(duì)每個(gè)域1的類型與共享現(xiàn)象的類型都進(jìn)行了描述。問題框架不對(duì)應(yīng)具體問題,其中的組成元素也不具有任何實(shí)際的意義。具體應(yīng)用一個(gè)問題框架于某個(gè)實(shí)際問題稱為實(shí)例化該問題框架,實(shí)例化后的結(jié)果稱為問題框架實(shí)例。11-4問題框架的類型軟件系統(tǒng)的分類需求式的行文問題框架的直觀思想：存在客觀世界的某個(gè)部分，其行為要受到控制，以使得它滿足特定的條件。問題是要建立一個(gè)機(jī)器，該機(jī)器施加所需要的控制。

11-4問題框架的類型需求式行為問題框架

在需求式行為問題中,實(shí)際受控制的域也可能并不直接與控制機(jī)器相連,而是通過其他的連接域進(jìn)行橋接，這是需求式行為問題框架的一種變體。如下圖所示:命令式的行為問題框架的直觀思想：存在客觀世界的某個(gè)部分，其行為要依據(jù)操作者發(fā)出的命令來控制。問題是要建立一個(gè)機(jī)器，該機(jī)器接受操作者的命令并施加相應(yīng)控制。其問題框架如圖11-5所示。

11-4問題框架的類型命令式行為問題框架信息顯示問題框架的直觀思想：存在客觀世界的某個(gè)部分，關(guān)于其狀態(tài)和行為的特定信息被連續(xù)的需要。問題是要建立一個(gè)機(jī)器，該機(jī)器從客觀世界中獲得相關(guān)信息，并按所要求的格式呈現(xiàn)在所要求的地方。其問題框架如圖11-6所示。

11-4問題框架的類型信息顯示問題框架除帶連接域的變體外,信息顯示問題框架還有兩種常見的變體。第一種變體引進(jìn)一個(gè)模型域,并將信息顯示問題框架用兩個(gè)子框架表示,其中第一個(gè)子框架對(duì)現(xiàn)實(shí)世界進(jìn)行建模，生成一個(gè)反映現(xiàn)實(shí)世界的模型域;

第二個(gè)子框架基于該模型域顯示需求中所要求的信息，如圖所示：信息顯示問題框架的其他兩種變體11-4問題框架的類型第二種變體是引進(jìn)一個(gè)操作者域,機(jī)器根據(jù)操作者所發(fā)出的請(qǐng)求顯示現(xiàn)實(shí)世界中的相關(guān)信息，如下圖所示。11-4問題框架的類型信息顯示問題框架的其他兩種變體工件問題框架工作問題框架的直觀思想：需要一個(gè)工具，讓用戶創(chuàng)建并編輯特定類型的計(jì)算機(jī)可處理的文本或圖形對(duì)象或簡單結(jié)構(gòu)，以便它們隨后能被拷貝、打印、分析或按其它方式使用。問題是要建立一個(gè)機(jī)器，該機(jī)器可以充當(dāng)這個(gè)工具。其問題框架如圖11-9所示。11-4問題框架的類型變換問題框架變換問題框架的直觀思想是：存在一些計(jì)算機(jī)可讀的輸入文件，其數(shù)據(jù)必須變換，以給出所需要的特定輸出文件。輸出數(shù)據(jù)必須遵守特定的格式,按照特定的規(guī)則從輸入數(shù)據(jù)中導(dǎo)出。問題是要建立一個(gè)機(jī)器，該機(jī)器從輸入中產(chǎn)生所需要的輸出。其問題框架如圖10-10所示。11-4問題框架的類型11-5PDOA方法的分析步驟PDOA方法的特點(diǎn)將關(guān)注的重點(diǎn)定位在問題及其相關(guān)的問題域上，通過對(duì)問題及其問題域進(jìn)行合理的分類，為分析人員提供解決具體問題的相關(guān)指南。同時(shí)從問題域的角度出發(fā)，使用戶能參與整個(gè)需求過程，有利于更直觀和真實(shí)地反映問題域的信息和用戶的需求。PDOA方法的基本過程1.搜集需求信息，界定和描述問題及問題域。2.劃分問題域并開發(fā)相關(guān)問題框架。3.根據(jù)問題框架的類型進(jìn)一步描述問題域的相關(guān)特性。11-5PDOA方法的分析步驟11-5PDOA方法的分析步驟11-5-1問題及問題域的界定與描述傳統(tǒng)的系統(tǒng)分析一般采用上下文圖的形式界定并描述問題及其問題域。上下文圖相當(dāng)于結(jié)構(gòu)化分析方法中的第0層數(shù)據(jù)流圖。它由一個(gè)代表解系統(tǒng)的圓圈、一些對(duì)解系統(tǒng)外部可見且與解系統(tǒng)直接相連的域以及相關(guān)的信息流組成。域用矩形框表示，可以是某個(gè)特定的物理實(shí)體、與解系統(tǒng)交互的人，也可以是其他計(jì)算機(jī)系統(tǒng)等。采用上下文圖界定問題域的方式實(shí)際上就是對(duì)那些解系統(tǒng)外部可見且直接與之相關(guān)的域進(jìn)行標(biāo)識(shí)。上下文圖界定并描述整個(gè)問題及其問題域存在的不足：1）只描述了與解系統(tǒng)直接相連的域，而沒有描述與解系統(tǒng)間接相連的其它域，這導(dǎo)致一些對(duì)于理解用戶需求、甚至與用戶需求直接關(guān)聯(lián)的域可能會(huì)因此被忽略掉。2）只描述了系統(tǒng)外部可見的域，而沒有描述在系統(tǒng)運(yùn)行后才生成的域；3）只描述了域與解系統(tǒng)之間的關(guān)系，而沒有描述域與域之間的關(guān)系；4）沒有對(duì)問題進(jìn)行任何具體的描述。11-5PDOA方法的分析步驟11-5-1問題及問題域的界定與描述以校園通為例，整個(gè)待解決的問題實(shí)際上是開發(fā)一套運(yùn)行在主機(jī)上的軟件系統(tǒng)，使之滿足實(shí)例陳述中所提到的各種要求。通過對(duì)該實(shí)例進(jìn)行初步分析，可生成如圖11-11所示的上下文圖。問題圖M.Jackson等認(rèn)為問題及其問題域的界定和描述必須以問題為中心，而不是以解系統(tǒng)為中心，并提出了采用問題圖的形式來界定和描述問題及其問題域。問題圖形式上是由機(jī)器、問題域和需求以及它們之間的關(guān)系組成。描述域與域間關(guān)系的現(xiàn)象描述域與域間關(guān)系的現(xiàn)象可分為事件、實(shí)體、值、狀態(tài)、真值和角色等六種類型。前三種為個(gè)體，后三種為個(gè)體間的關(guān)系。個(gè)體是可以命名且可以區(qū)別于其他個(gè)體的事物；關(guān)系則是一組個(gè)體間的關(guān)聯(lián),它由一定數(shù)量的元組構(gòu)成。在問題圖中，機(jī)器與各個(gè)域之間的共享現(xiàn)象用于描述規(guī)格說明，稱為規(guī)格說明現(xiàn)象。需求與各個(gè)域之間的共享現(xiàn)象用于描述用戶需求,稱為需求現(xiàn)象。PDOA方法的分析步驟11-5校園通的問題圖在校園通系統(tǒng)中，除圖11-11中所標(biāo)識(shí)的五個(gè)域外，可以發(fā)現(xiàn)還有其他的一些域和該問題密切相關(guān)。有些和系統(tǒng)間接相連，如學(xué)生域、IC卡域、家長域、移動(dòng)網(wǎng)絡(luò)系統(tǒng)域、家長手機(jī)域、電話域等;有些則位于系統(tǒng)內(nèi)部，由系統(tǒng)在實(shí)際運(yùn)行時(shí)創(chuàng)建,如考勤報(bào)表域、學(xué)生在校表現(xiàn)域、學(xué)生請(qǐng)假記錄域、原始刷卡記錄域等。通過對(duì)問題所涉及的域以及域與域、域與機(jī)器、域與需求之間的關(guān)系進(jìn)行深入分析，對(duì)校園通可作出如圖11-12所示的問題圖。PDOA方法的分析步驟11-5因?qū)嶋H問題及其問題域的類型和結(jié)構(gòu)各不相同，難以找出一個(gè)通用、精確的方法來劃分所有類型的問題及其問題域，主要依靠系統(tǒng)分析員的經(jīng)驗(yàn)。通常的做法是通過與各基本問題框架及其變體進(jìn)行隨機(jī)匹配，以隨意的方式對(duì)相關(guān)問題及其問題域進(jìn)行劃分：(1)由內(nèi)到外的劃分。(2)由外到內(nèi)的劃分。(3)基于節(jié)奏的劃分。此外，還存在其他一些啟發(fā)式的劃分方法，如基于語氣的劃分、基于組合框架的劃分等，讀者可參閱相關(guān)的文獻(xiàn)。

11-5PDOA方法的分析步驟11-5-2基于問題框架的問題域劃分基于各種基本問題框架及其變體，以及前面介紹的劃分方法，對(duì)于“校園通問題圖”，可劃分出如下一系列的問題框架實(shí)例。首先，家長可通過電話查詢學(xué)生的各類在校表現(xiàn)，經(jīng)過分析，它可與信息顯示問題框架匹配，如圖11-13所示。校園通問題圖-問題框架實(shí)例11-5PDOA方法的分析步驟圖11-13可看作是圖11-12所示校園通問題的一個(gè)投影，例如圖11-13中的機(jī)器“學(xué)生在校表現(xiàn)查詢器”是圖11-12的機(jī)器“校園通系統(tǒng)”的投影，共享現(xiàn)象d是圖11-12中共享現(xiàn)象n的投影等。故此處通過與信息顯示問題框架的匹配，實(shí)際上達(dá)到了對(duì)圖11-12所示的問題進(jìn)行一次劃分的目的。其次，通過與命令式行為問題框架匹配，不難發(fā)現(xiàn)其中存在兩個(gè)命令式行為子問題。第一個(gè)子問題是系統(tǒng)依據(jù)教師的操作命令給學(xué)生家長發(fā)送短信或取消暫未發(fā)出的短信。第二個(gè)子問題是系統(tǒng)依據(jù)學(xué)生的刷卡情況給學(xué)生家長發(fā)送短信，分別如圖11-14a和圖11-14b所示。校園通問題圖-問題框架實(shí)例11-5PDOA方法的分析步驟考勤規(guī)則、學(xué)生請(qǐng)假記錄、學(xué)生在校表現(xiàn)、原始刷卡記錄等均為詞法域，通過與工件問題框架匹配，可找出如下四個(gè)工件子問題:管理員創(chuàng)建并編輯學(xué)校的考勤規(guī)則;教師創(chuàng)建并編輯學(xué)生的請(qǐng)假記錄﹔教師創(chuàng)建并編輯學(xué)生的在校表現(xiàn)信息﹔系統(tǒng)依據(jù)學(xué)生的刷卡情況創(chuàng)建原始刷卡記錄。分別如圖11-15、圖11-16、圖11-17和圖11-18所示，其中圖11-18是帶連接域的工件問題框架實(shí)例。校園通問題圖-問題框架實(shí)例11-5PDOA方法的分析步驟最后，系統(tǒng)根據(jù)考勤規(guī)則，對(duì)學(xué)生的原始刷卡記錄和學(xué)生的請(qǐng)假記錄進(jìn)行匯總，變換生成考勤報(bào)表，剛好與變換問題框架匹配，如圖11-19所示。至此，通過與各基本問題框架及其變體的匹配，將圖11-12所示的校園通問題圖劃分成了圖11-13~圖11-19所示的各具體問題框架實(shí)例，從而實(shí)現(xiàn)了對(duì)校園通問題及其問題域的有效劃分。校園通問題圖-問題框架實(shí)例11-5PDOA方法的分析步驟11-6問題框架實(shí)例間的關(guān)系及其組合各問題框架實(shí)例間的關(guān)系由這種并行的劃分所決定。兩個(gè)并行的問題框架實(shí)例可能相互獨(dú)立、互不相關(guān)，也可能相互之間具有一定的關(guān)聯(lián)。對(duì)于問題框架實(shí)例的關(guān)聯(lián)，可從靜態(tài)形式和動(dòng)態(tài)交互兩個(gè)方面討論。形式方面:一個(gè)問題框架實(shí)例對(duì)應(yīng)一個(gè)問題圖，因而兩個(gè)問題框架實(shí)例在形式上相互關(guān)聯(lián)是指它們所對(duì)應(yīng)的問題圖之間相互關(guān)聯(lián)。兩個(gè)問題框架實(shí)例形式上相關(guān)的另一種情況是一個(gè)問題框架實(shí)例所包含的需求，或者說它所對(duì)應(yīng)的子問題應(yīng)滿足的需求是另一個(gè)問題框架實(shí)例中的域。交互方面：兩個(gè)問題框架實(shí)例相關(guān)本質(zhì)上是指它們的機(jī)器與機(jī)器之間存在由并行的劃分所引發(fā)的并發(fā)關(guān)系，這類似于兩個(gè)并發(fā)進(jìn)程間的關(guān)系。綜上可見，形式上兩個(gè)問題框架實(shí)例間的關(guān)系可分為三種類型：無關(guān)、具有公共的域、一個(gè)問題框架實(shí)例的需求是另一個(gè)問題框架實(shí)例中的域。

11-6-1問題框架實(shí)例間的關(guān)系11-6問題框架實(shí)例間的關(guān)系及其組合問題框架實(shí)例的組合與基于問題框架劃分問題及其問題域相輔相成，主要考慮在組合各個(gè)獨(dú)立的問題框架實(shí)例時(shí)，如何使不同的問題框架實(shí)例在整體上保持協(xié)調(diào)，從而使它們能與原來的整個(gè)問題及其問題域保持一致。

如果兩個(gè)問題框架實(shí)例在形式上無關(guān)，則它們之間的組合僅是簡單意義上的相加，不存在任何問題需進(jìn)行處理。若一個(gè)需求式行為問題框架實(shí)例與一個(gè)變換問題框架實(shí)例在形式上不存在任何重疊部分,則它們顯然是相互協(xié)調(diào)的,不存在組合方面的問題。應(yīng)滿足的需求是另一個(gè)問題框架實(shí)例中的域。

如果兩個(gè)問題框架實(shí)例具有公共的域，則在公共域上，它們可能不存在任何交互，也可能存在一定形式的交互。對(duì)于不存在交互的情況，兩者的組合也不存在任何問題需進(jìn)行處理。11-6-2問題框架實(shí)例的組合11-6問題框架實(shí)例間的關(guān)系及其組合如果兩個(gè)問題框架實(shí)例在某個(gè)公共域上具有交互關(guān)系，則在組合時(shí)，兩者在公共域上可能存在如下兩種類型的問題：第一種類型的問題源自寫者-寫者型交互，表現(xiàn)為兩個(gè)問題框架實(shí)例對(duì)公共域均具有約束性，但它們對(duì)公共域的不同約束在某一時(shí)刻只能有一個(gè)成立，且任何一個(gè)約束的成立都不會(huì)導(dǎo)致另一個(gè)約束成立，這種問題可稱為沖突問題。第二種類型的問題源自讀者-寫者型交互，表現(xiàn)為一個(gè)問題框架實(shí)例引用公共域中的現(xiàn)象，而另一個(gè)問題框架實(shí)例則約束或者說改變?cè)摴灿蛑械默F(xiàn)象。上面第二種類型的問題又可分為兩種情況。一種稱為同步問題，另一種稱為干擾問題。引起上面各類組合問題的根本原因不在于每個(gè)問題框架實(shí)例自身對(duì)對(duì)應(yīng)子問題及其問題域的描述和建模是否正確，而在于它們各自只是從自身的目的和要求出發(fā)考慮各自所關(guān)心的具體問題，忽略了其他因素可能對(duì)該問題所造成的影響,從而使整個(gè)問題的不同部分缺乏協(xié)調(diào)。問題框架實(shí)例組合問題的解決通常需要與相關(guān)的客戶進(jìn)行協(xié)商、協(xié)調(diào)或從客戶處獲取更多的具體信息。11-6-2問題框架實(shí)例的組合11-6問題框架實(shí)例間的關(guān)系及其組合第12章面向多視點(diǎn)的需求工程多視點(diǎn)需求工程的提出多視點(diǎn)需求工程適用對(duì)象20世紀(jì)90年代，A.Finkelstein和I.Sommerville等人正式提出了面向多視點(diǎn)的需求工程，采用視點(diǎn)的方式獲取和組織不同用戶的需求，并根據(jù)視點(diǎn)間的關(guān)系分析和處理需求的一致性問題，以確保用戶需求的完整性和一致性。面向多視點(diǎn)的需求工程(以下簡稱多視點(diǎn)需求工程)之所以特別適合于大型、復(fù)雜的軟件系統(tǒng),尤其是分布式或涉及復(fù)雜問題領(lǐng)域的系統(tǒng),根本原因在于它采用關(guān)注點(diǎn)分離的思想。面向多視點(diǎn)的需求工程

目錄什么是視點(diǎn)多視點(diǎn)與需求工程多視點(diǎn)需求工程的過程模型示例12-112-212-312-412-1什么是視點(diǎn)視點(diǎn)的定義不同的研究人員對(duì)視點(diǎn)的理解和定義各不相同，大致而言，有如下幾種類型的定義：視點(diǎn)是信息處理的實(shí)體，同時(shí)這一實(shí)體可能是另一視點(diǎn)的信息來源或信息流向。視點(diǎn)是服務(wù)的接收者，這些服務(wù)可被看作系統(tǒng)的需求。視點(diǎn)與某特定問題域相關(guān)，是一個(gè)由表示知識(shí)、開發(fā)知識(shí)和規(guī)約知識(shí)等構(gòu)成的松散耦合、局部管理的對(duì)象。視點(diǎn)包含問題和問題解決過程的部分信息，它是與問題、問題域及問題解決過程相關(guān)的一個(gè)特定和部分的方法或視圖。視點(diǎn)是一個(gè)形式化的部分規(guī)格說明。視點(diǎn)代表了系統(tǒng)相關(guān)人員的觀點(diǎn)和看法，并且是對(duì)來源于某特殊角度的部分需求信息的封裝。視點(diǎn)一般由視點(diǎn)的擁有者及該擁有者對(duì)目標(biāo)系統(tǒng)的部分或全部看法或要求組成。什么是視點(diǎn)12-112-2多視點(diǎn)和需求工程多視點(diǎn)多視點(diǎn)的概念建立于單視點(diǎn)概念之上。多視點(diǎn)就是在客觀分析若干視點(diǎn)的內(nèi)、外部關(guān)系的基礎(chǔ)上對(duì)其進(jìn)行有機(jī)的整理和綜合。導(dǎo)致多視點(diǎn)形成的原因有三個(gè)主要的因素：時(shí)間上的差異、空間上的差異和知識(shí)上的差異。多視點(diǎn)的思想在眾多領(lǐng)域，例如哲學(xué)、經(jīng)濟(jì)學(xué)、政治學(xué)等學(xué)科中均有運(yùn)用。多視點(diǎn)是群體協(xié)作活動(dòng)中的本質(zhì)特征。面向多視點(diǎn)的需求工程方法將需求從多維的信息映射到最終的一維的馮·諾依曼體系結(jié)構(gòu)上，并在映射的過程中盡量保持信息多維的特征，避免在轉(zhuǎn)換的過程中對(duì)信息的扭曲或遺失，如圖12-1所示。12-2多視點(diǎn)和需求工程面向多視點(diǎn)的需求工程方法的優(yōu)勢復(fù)雜系統(tǒng)的本質(zhì)特性與多視點(diǎn)思想吻合，利用多視點(diǎn)需求工程方法可以有效地減少某些重要需求被遺漏的可能性，從而保證了需求規(guī)約的完備性。每個(gè)視點(diǎn)只需關(guān)心它自己感興趣的內(nèi)容，不需或較少地考慮其它因素的影響，從而有效地降低了需求獲取和描述的難度，有利于提高整個(gè)需求工程的質(zhì)量。視點(diǎn)的形式使軟件系統(tǒng)以一種更加結(jié)構(gòu)化的形式被描述，從而為自動(dòng)化的完備性和一致性檢查提供了可能性。多視點(diǎn)為封裝軟件系統(tǒng)的不同描述模型提供了一個(gè)強(qiáng)而有力的手段。通過把需求和表達(dá)需求的視點(diǎn)關(guān)聯(lián)起來，可增強(qiáng)需求的可追蹤性。多視點(diǎn)和需求工程12-212-3多視點(diǎn)需求工程的過程模型20世紀(jì)90年代開始，多視點(diǎn)需求工程的研究得到了極大的發(fā)展。例如，早在20世紀(jì)70年代的SADT(1970)方法和CORE方法等，到20世紀(jì)90年代的VOSE方法、VORD方法、PREView方法、IEEE1471一2000標(biāo)準(zhǔn)、SEI標(biāo)準(zhǔn)和RM-ODP方法等，從不同角度推進(jìn)了面向視點(diǎn)的需求工程的研究。綜觀這些多視點(diǎn)的需求工程方法，可以看出多視點(diǎn)需求工程的研究內(nèi)容及主要工作可概括為：視點(diǎn)的標(biāo)識(shí)、視點(diǎn)的表示、視點(diǎn)的分析與檢測、視點(diǎn)的集成。多視點(diǎn)需求工程的過程模型多視點(diǎn)需求工程的需求分析過程12-3圖12-2表示了多視點(diǎn)需求工程的需求分析過程。多視點(diǎn)的需求工程方法12-3-1視點(diǎn)的標(biāo)識(shí)需求信息主要從項(xiàng)目相關(guān)人員、與軟件系統(tǒng)相關(guān)的文檔等處獲取，這些可以說是需求信息的來源，也簡稱“視點(diǎn)源”。視點(diǎn)標(biāo)識(shí)的主要任務(wù)：確定視點(diǎn)源,然后根據(jù)視點(diǎn)源標(biāo)識(shí)出相應(yīng)的視點(diǎn),并獲取相應(yīng)的需求信息。標(biāo)識(shí)視點(diǎn)的方法Sommerville給出了標(biāo)識(shí)視點(diǎn)的一般方法：1）從視點(diǎn)類層次圖中刪除那些與待開發(fā)軟件系統(tǒng)不相關(guān)的視點(diǎn)；2）考慮目標(biāo)系統(tǒng)的各類相關(guān)人員，若某些類型的項(xiàng)目相關(guān)人員不是組織視點(diǎn)類的一部分，則增加該類型的視點(diǎn)；3）使用一個(gè)系統(tǒng)體系結(jié)構(gòu)模型標(biāo)識(shí)子系統(tǒng)的視點(diǎn)；4）標(biāo)識(shí)以不同方式和頻率使用系統(tǒng)的各類操作員，分別對(duì)應(yīng)不同的視點(diǎn)；5）對(duì)每個(gè)已標(biāo)識(shí)出的間接視點(diǎn)類，考慮與其相關(guān)的主要人員的角色，在需要的情況下使不同的角色對(duì)應(yīng)不同的視點(diǎn)。RM-ODP方法從靜態(tài)的角度定義了五類視點(diǎn)：企業(yè)視點(diǎn)，信息視點(diǎn)，計(jì)算視點(diǎn)，工程視點(diǎn)和技術(shù)視點(diǎn)。多視點(diǎn)需求工程的過程模型12-312-3-2視點(diǎn)的表示視點(diǎn)表示階段的工作主要需解決兩個(gè)問題：一個(gè)是視點(diǎn)到底應(yīng)包含哪些信息，另一個(gè)是用什么方式來表示視點(diǎn)的信息。視點(diǎn)表示方法1）A.Finkelstien采用模板的形式表示