中科院需求工程-8D講多視點需求工程與矛盾需求處理-

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