中科院需求工程-8D講多視點(diǎn)需求工程與矛盾需求處理-

需求工程金芝中國科學(xué)院數(shù)學(xué)與系統(tǒng)科學(xué)探討院zhijin@amss.ac什么是視點(diǎn)？理解系統(tǒng)的需求，須要理解：系統(tǒng)供應(yīng)的服務(wù)系統(tǒng)的應(yīng)用領(lǐng)域系統(tǒng)將處于的環(huán)境影響系統(tǒng)的組織問題等等因此，需求工程過程涉及：捕獲、分析和確定——各種看法什么是視點(diǎn)？視點(diǎn)：出自一個特定角度的，關(guān)于系統(tǒng)或相關(guān)問題、環(huán)境和應(yīng)用領(lǐng)域的一組信息角度：系統(tǒng)的最終用戶其它的系統(tǒng)涉及系統(tǒng)開發(fā)的工程師任何系統(tǒng)相關(guān)者什么是視點(diǎn)？假設(shè)：針對整個系統(tǒng)而言，每個視點(diǎn)都是不完整的整個系統(tǒng)的需求將通過集成各個視點(diǎn)信息得到由于一般而言視點(diǎn)之間會包含不同的需求，因此特殊地要涉及沖突的歸結(jié)過程什么是視點(diǎn)？“火車自動限制系統(tǒng)”中的可能視點(diǎn)和需求來源：司機(jī)：來自火車司機(jī)的需求，可能大部分是涉及可用性的非功能性需求軌道設(shè)備：來自軌道設(shè)備的需求，這些軌道設(shè)備將與系統(tǒng)發(fā)生交互已有的其它系統(tǒng)：來自已經(jīng)存在的其它系統(tǒng)的兼容性需求平安工程師：來自于鐵路平安工程師的系統(tǒng)平安性需求火車制動裝置的特征：從火車制動裝置的特性中導(dǎo)出的需求什么是視點(diǎn)？視點(diǎn)：需求相關(guān)者對問題某個方面的觀點(diǎn)，顯式區(qū)分不同的需求來源視點(diǎn)是分別關(guān)注點(diǎn)的一種方法，讓參與者僅僅關(guān)注他們感愛好的問題，忽視與他們無關(guān)的問題供應(yīng)組織和結(jié)構(gòu)化這些不同信息的機(jī)制供應(yīng)手段，讓需求源或需求相關(guān)者標(biāo)識和檢查他們對需求的貢獻(xiàn)第十講：面對視點(diǎn)的需求方法結(jié)構(gòu)化分析和設(shè)計(jì)技術(shù)（SADT）限制需求表達(dá)（CORE）面對視點(diǎn)的系統(tǒng)工程（VOSE）面對視點(diǎn)的需求定義（VORD）面對視點(diǎn)的需求驗(yàn)證“問題”需求的處理框架從結(jié)構(gòu)化分析和設(shè)計(jì)技術(shù)（SADT）中談起SADT方法由長方形（表示活動）和不同含義的箭頭組成將問題分解為層次圖，每層含一組長方形和箭頭低層的是高層的精化最上層的是上下文圖，表示系統(tǒng)的輸入／輸出／限制／支撐機(jī)制SADT方法中的視點(diǎn)沒有顯式的視點(diǎn)定義，是其建模技術(shù)的直觀推廣由它的數(shù)據(jù)和來源和去向確定視點(diǎn)SADT方法中的視點(diǎn)視點(diǎn)Libraryuser表示檢查和未檢查的館藏的來源和目的地視點(diǎn)Issueclerk表示檢查這些館藏并注明歸還日期視點(diǎn)Itemdatabase表示關(guān)于館藏的信息的來源和要修改的信息視點(diǎn)Userdatabase表示驗(yàn)證合法用戶的信息來源SADT方法中的視點(diǎn)視點(diǎn)只是一種直覺,而沒有明確的表示沒有關(guān)凝視點(diǎn)定義的特地步驟視點(diǎn)只出現(xiàn)在上下文層沒有超出只將視點(diǎn)作為數(shù)據(jù)的來源和出處的視點(diǎn)分析限制式需求表達(dá)（CORE）CORE方法概述英國宇航局，七十年頭末期關(guān)注功能分解（與SADT相同），但不同的是，它顯式地以視點(diǎn)為基礎(chǔ)用于歐洲宇航工業(yè)界，著名的項(xiàng)目包括：八十年頭中旬的試驗(yàn)飛行器支配，CORE用于系統(tǒng)和軟件定義最近的歐洲戰(zhàn)斗機(jī)支配，CORE作為標(biāo)準(zhǔn)的需求分析方法CORE方法中的視點(diǎn)分兩層考慮視點(diǎn)第一層次：識別與目標(biāo)系統(tǒng)交互的或者影響目標(biāo)系統(tǒng)的實(shí)體CORE供應(yīng)識別功能性和非功能性視點(diǎn)的指南其次層次：區(qū)分定義視點(diǎn)和邊界視點(diǎn)定義視點(diǎn)：系統(tǒng)的子過程，接受自頂向下的方式限界視點(diǎn)：間接地與目標(biāo)系統(tǒng)發(fā)生交互的實(shí)體CORE方法的步驟迭代式過程視點(diǎn)識別視點(diǎn)結(jié)構(gòu)化表表示的采集數(shù)據(jù)結(jié)構(gòu)化單視點(diǎn)建模組合視點(diǎn)建模約束分析舉例（圖書館管理）第一步：識別視點(diǎn)（頭腦風(fēng)暴，識別可能實(shí)體）舉例（圖書館管理）第一步：識別視點(diǎn)（區(qū)分定義視點(diǎn)和限界視點(diǎn)）舉例（圖書館管理）其次步：視點(diǎn)結(jié)構(gòu)化功能子系統(tǒng)層次結(jié)構(gòu)，自頂向下分解限界視點(diǎn)在相同的層次上舉例（圖書館管理）第三步：表表示法采集視點(diǎn)信息的一種機(jī)制包括：執(zhí)行的行為、這些行為要運(yùn)用的數(shù)據(jù)、導(dǎo)出的輸出數(shù)據(jù)、數(shù)據(jù)的來源、數(shù)據(jù)的目的地主要側(cè)重在信息流建模，便于視點(diǎn)間數(shù)據(jù)流沖突的檢測，包括數(shù)據(jù)來源和目的地的一樣性等舉例（圖書館管理）SourceInputActionOutputDestinationLibraryuserRequesteditemCheckitemIssueditemLibraryuserErrormessageIssueclerkLibraryuserLibrarycardValidateuserLoandefaultmessageIssueclerkCORE方法的其余步驟第四步，數(shù)據(jù)結(jié)構(gòu)化：將數(shù)據(jù)項(xiàng)分解為其組成部分，創(chuàng)建數(shù)據(jù)字典第五步和第六步，單視點(diǎn)建模和多視點(diǎn)組合建模：接受活動圖為視點(diǎn)活動建模，類似于SADT，說明活動的過程，以及關(guān)聯(lián)到的表集第七步，約束分析：將系統(tǒng)看作一個整體進(jìn)行分析CORE方法的問題探討任何實(shí)體都可以是視點(diǎn)，對什么是視點(diǎn)缺少明確的界定定義視點(diǎn)和限界視點(diǎn)使視點(diǎn)的識別更加困難限界視點(diǎn)是將與目標(biāo)系統(tǒng)發(fā)生信息交互的外部實(shí)體定義視點(diǎn)是目標(biāo)系統(tǒng)的子過程分析比較薄弱，僅關(guān)注于內(nèi)部視點(diǎn)（定義視點(diǎn)），對限界視點(diǎn)不進(jìn)行分析，它們只是作為與系統(tǒng)交互的數(shù)據(jù)來源和目的地面對視點(diǎn)的系統(tǒng)工程（VOSE）VOSE概述九十年頭早期，ImperialCollegeLondon基本原理：軟件開發(fā)涉及很多專家的參與這些專家關(guān)注于軟件開發(fā)和應(yīng)用領(lǐng)域的不同方面每個專家都只負(fù)責(zé)或關(guān)注他所關(guān)切的方面VOSE視點(diǎn)運(yùn)用視點(diǎn)來捕獲上述不同的方面，劃分和分布參與者的活動和學(xué)問捕獲參與者在軟件開發(fā)特定階段的角色和職責(zé)通過參與者的角色來識別視點(diǎn)不同角色的學(xué)問封裝在一個視點(diǎn)內(nèi)，VOSE供應(yīng)了視點(diǎn)的表示風(fēng)格什么是視點(diǎn)?松耦合、局部管理、分布的對象，它封裝了關(guān)于系統(tǒng)及其領(lǐng)域的：部分表示學(xué)問開發(fā)過程學(xué)問規(guī)格說明學(xué)問標(biāo)準(zhǔn)視點(diǎn)框架描述該視點(diǎn)運(yùn)用的表示格式描述該視點(diǎn)的開發(fā)行為，過程和策略標(biāo)識相對于要開發(fā)的整個系統(tǒng)而言該視點(diǎn)的關(guān)注點(diǎn)按style槽規(guī)定的，接受workplan槽中描述的策略開發(fā)的表示法描述視點(diǎn)維護(hù)視點(diǎn)規(guī)格說明的開發(fā)狀態(tài)，通過它可以實(shí)現(xiàn)需求的可追蹤性，記錄一些形式的開發(fā)理念。視點(diǎn)類型一個視點(diǎn)框架就是一個視點(diǎn)類型，它只包含風(fēng)格（style）槽工作支配（workplan）槽依據(jù)工作支配槽中定義的行為開發(fā)視點(diǎn)，得到視點(diǎn)類型的一個實(shí)例主要探討的問題視點(diǎn)的表示視點(diǎn)內(nèi)部的交互視點(diǎn)之間的交互沖突消解視點(diǎn)框架視點(diǎn)框架是可重用的描述，可以多次實(shí)例化，得到多個視點(diǎn)框架的一次實(shí)例化過程就是一個視點(diǎn)的開發(fā)過程框架不僅刻畫視點(diǎn)要表示的需求,還表達(dá)了視點(diǎn)的開發(fā)方法和開發(fā)過程視點(diǎn)擁有者：負(fù)責(zé)制定該視點(diǎn)的過程模型的人或者智能工具Style槽兩部分：Object：Object.AttributeRelation：Relation(Object1,Object2).AttributeRelation(Object1,Object2).Object1.Attribute例子Process.NameState.Name.`On’Transition(On,Off).Name.`Button-press’WorkPlan槽組裝活動視點(diǎn)內(nèi)檢查視點(diǎn)間檢查視點(diǎn)觸發(fā)活動組裝活動用來采集（構(gòu)造）該表示框架的規(guī)格說明的基本活動事實(shí)上是一組基本的編輯活動視點(diǎn)內(nèi)檢查檢查視點(diǎn)規(guī)格說明語法上的局部一樣性這些檢查規(guī)則事實(shí)上部分定義了視點(diǎn)表示的語義是方法設(shè)計(jì)者確定良定規(guī)格說明的依據(jù)視點(diǎn)間檢查檢查不同視點(diǎn)規(guī)格說明間的一樣性視點(diǎn)間一樣性規(guī)則規(guī)定在什么狀況下出現(xiàn)不一樣視點(diǎn)觸發(fā)活動為了創(chuàng)建新視點(diǎn)(實(shí)例化視點(diǎn)框架)而必需執(zhí)行的活動一般作為一個其它開發(fā)活動的結(jié)果，比如：在agent層次中增加一個agent觸發(fā)為這個agent創(chuàng)建一個新的視點(diǎn)在功能分解層次中增加一個子過程，觸發(fā)創(chuàng)建一個表集視點(diǎn)過程模型兩類視點(diǎn)框架Agent結(jié)構(gòu)視點(diǎn)表集視點(diǎn)Agent結(jié)構(gòu)視點(diǎn)表集視點(diǎn)（一）表集視點(diǎn)（二）視點(diǎn)間的關(guān)系（一）視點(diǎn)間的關(guān)系（二）案例（圖書館）識別信息處理實(shí)體，作為Agent，用Agent層次結(jié)構(gòu)將它們組合起來LibraryWorld視點(diǎn)案例（圖書館）針對每個葉子agent，構(gòu)造刻畫信息處理過程的表結(jié)構(gòu)Borrower視點(diǎn)其它視點(diǎn)內(nèi)活動檢查源和目的地的存在性，針對agent的層次結(jié)構(gòu)而言假如出錯，隱含：增加新agent重命名不一樣的源和目的地視點(diǎn)集成視點(diǎn)間關(guān)系定義（舉例）表集合圖中的每個源必需是agent層次中的一個命名agentSource.Name=VP(AS,Dd):Agent.Name表集合圖中的每個目的地必需是agent層次中的一個命名agentDestination.Name=VP(AS,Dd):Agent.Name視點(diǎn)間關(guān)系定義（舉例）來自表集合圖的每個輸出必需是另一個agent的表集合圖的一個輸入Connected-to(Output,Destination).Output.Name=VP(TC,Destination.Name):Connected-to(Ds,Input).Input.Name來自表集合圖中一個源的每個輸入必需由該源agent的表集合圖產(chǎn)生Connected-to(Source,Input).Input.Name=VP(TC,Source.Name):Connected-to(Output,Ds).Output.Name兩個視點(diǎn)表集合圖間關(guān)系視點(diǎn)間關(guān)系定義（舉例）Agent層次上的每個agent必需有一個表集合圖與它關(guān)聯(lián)（蘊(yùn)涵每個agent都是一個信息處理實(shí)體）AgentVP(TC,Agent.Name)總之，視點(diǎn)間關(guān)系定義視點(diǎn)之間的結(jié)構(gòu)約束視點(diǎn)間規(guī)則的援引在創(chuàng)建包含該規(guī)則的視點(diǎn)類的實(shí)例（源視點(diǎn)）時，聲明：至少要有一個目的視點(diǎn)，使得它將與源視點(diǎn)維護(hù)這個關(guān)系可以觸發(fā)目的視點(diǎn)的創(chuàng)建VPsVPdsuchthatVPsVPd視點(diǎn)集成（援引）視點(diǎn)間規(guī)則的應(yīng)用檢查模式：？失敗導(dǎo)致不一樣性處理變換模式：f(,VPs,VPd)將一個視點(diǎn)中的對象或關(guān)系一對一映射到另一個視點(diǎn)的對應(yīng)對象或關(guān)系上（滿足關(guān)系）視點(diǎn)集成（應(yīng)用）視點(diǎn)集成視點(diǎn)間不一樣性的處理視點(diǎn)間不一樣性的處理視點(diǎn)間不一樣性的處理利用封閉世界假設(shè)，可以推出沖突：探討基本觀點(diǎn)：在處理概念建模問題時，建立多個代表不同視角的片段模型，比試圖構(gòu)造單個模型要好分別地為不同涉眾建模，然后再組合起來，會導(dǎo)致對領(lǐng)域的更豐富的理解視點(diǎn)方法的好處得到涉眾的認(rèn)可：分別地獲得不同涉眾的視點(diǎn)，他們可以看到自己的貢獻(xiàn)結(jié)構(gòu)化過程：需求制品的并行開發(fā)，不受一樣性的局限，建模過程可以分派給不同的開發(fā)小組延遲承諾：容許問題的不同表示，對哪些需求更重要的問題，他們應(yīng)當(dāng)如何建模等，分析員可以推遲做出選擇，直到對涉眾的視角有更好的理解其它可能的好處視點(diǎn)建模改進(jìn)可追蹤性：因?yàn)楸容^和合并是顯式地進(jìn)行的，過程可以記錄下來視點(diǎn)建模改進(jìn)結(jié)果模型的可讀性：原始涉眾對模型的理解實(shí)力視點(diǎn)建模改進(jìn)捕獲不同觀點(diǎn)和微弱觀點(diǎn)的實(shí)力：沒有視點(diǎn)，有些不符合特定建模原則的事實(shí)會被忽視視點(diǎn)建模使小組的建模更簡潔，因?yàn)榉纸饬私Ｈ蝿?wù)帶來的新問題如何識別視點(diǎn)之間的關(guān)系？如何發(fā)覺和處理不一樣性？通過試驗(yàn)評估這個方法多倫多高校問題：KidsHelpPhone基本表示框架：I*試驗(yàn)設(shè)計(jì)全局建模組開發(fā)包含全部事務(wù)的單個I*模型視點(diǎn)開發(fā)組為每個被面談的涉眾開發(fā)個體模型，然后合并它們獲得整個模型，合并過程由整個開發(fā)組共同完成全局開發(fā)組的活動輸入：14個事務(wù)概念獲得：約950個意圖元素，約120個潛在的Actors和RolesSR模型：9個分別的SR模型結(jié)果檢查：交叉檢查、裁剪過合并元素推斷9個SR模型之間的策略依靠關(guān)系，得出一個完整的組織SD模型視點(diǎn)開發(fā)組的活動視點(diǎn)劃分：14個事務(wù)分成3組分別開發(fā)：每個模型僅包含本組事務(wù)中的信息，解除其它事務(wù)的信息模型接受與涉眾相同的詞匯視點(diǎn)合并選擇一個看起來被全部視點(diǎn)共享的元素作為起先點(diǎn)構(gòu)造一個合并模型，使它包含能與全部視點(diǎn)匹配的元素和只出現(xiàn)在一個視點(diǎn)中出現(xiàn)的元素假如元素表示的具體程度不同，則運(yùn)用最具體的版本假猶如一個術(shù)語被用來表示不同的概念，變更其中的一個術(shù)語，使能夠區(qū)分這個不同假猶如一個概念在不同的視點(diǎn)中接受了不同方式來表示，就比較麻煩，常常須要開發(fā)一個新的結(jié)構(gòu)一般的結(jié)論兩個組都覺得從文本中抽取模型元素比較困難對更大的模型，唯一實(shí)際的方法是將它劃分成很多分別的視圖（留意不是視點(diǎn)）比較模型規(guī)模是全局開發(fā)組的難題從事務(wù)中抽取的意圖元素太多不好管理，也無法檢查相像項(xiàng)難以確定如何將一個大的模型劃分為小的視圖不得不將大的actor分割成小的roles，否則依靠關(guān)系太多模型太大導(dǎo)致圖形布局問題，可讀性受到影響，檢查和驗(yàn)證幾乎不行能視點(diǎn)開發(fā)組可以克服這些問題模型的規(guī)模比較后向可追蹤性視點(diǎn)開發(fā)組比較簡潔做到全局開發(fā)組比較難，在整個開發(fā)過程，他們只查閱了原始事務(wù)描述5次它們的模型離原始事務(wù)比較遠(yuǎn)，在建模過程中引入了很多原始事務(wù)中沒有的概念，意圖元素的列表是原始事務(wù)和模型之間的中間表示意圖元素的列表對選擇建模問題的初始分解起到重要作用比較視點(diǎn)合并是視點(diǎn)開發(fā)組的主要難題，這個組不得不針對全部不同點(diǎn)提出解決方案，常常要回到原始事務(wù)描述中，識別某個概念的真正含義，須要全部的建模人員參與不同具體程度不同建模風(fēng)格不同形式化程度建模過于自由不同術(shù)語比較模型分析，不同小組開發(fā)的模型，接受不同的模型分析技術(shù)：全局開發(fā)組的模型用目標(biāo)評估過程視點(diǎn)開發(fā)組的模型讓涉眾檢查分析，理解涉眾之間觀點(diǎn)的不同“問題”需求的處理框架軟件需求抽取和表達(dá)中的困難相關(guān)工作不一樣需求的管理框架好的需求規(guī)格說明適合需求推理的邏輯工具超協(xié)調(diào)邏輯無合?。篈和B不能推出AB無真值關(guān)系：A的真值與A的真值無關(guān)多值系統(tǒng)：3值或4值邏輯相干邏輯：運(yùn)用不同的蘊(yùn)涵操作子弱化證明：限制證明的形式（如QC-LOGIC）定理證明技術(shù)（QC-logic）不利用封閉世界假設(shè)定理證明技術(shù)（QC-logic）擴(kuò)展可滿足性關(guān)系：強(qiáng)可滿足+弱可滿足