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

需求工程金芝中國科學院數(shù)學與系統(tǒng)科學研討院zhijin@amss.ac什么是視點？了解系統(tǒng)的需求，需求了解：系統(tǒng)提供的效力系統(tǒng)的運用領(lǐng)域系統(tǒng)將處于的環(huán)境影響系統(tǒng)的組織問題等等因此，需求工程過程涉及：捕獲、分析和決議——各種意見什么是視點？視點：出自一個特定角度的，關(guān)于系統(tǒng)或相關(guān)問題、環(huán)境和運用領(lǐng)域的一組信息角度：系統(tǒng)的最終用戶其它的系統(tǒng)涉及系統(tǒng)開發(fā)的工程師任何系統(tǒng)相關(guān)者什么是視點？假設：針對整個系統(tǒng)而言，每個視點都是不完好的整個系統(tǒng)的需求將經(jīng)過集成各個視點信息得到由于普通而言視點之間會包含不同的需求，因此特別地要涉及矛盾的歸結(jié)過程什么是視點？“火車自動控制系統(tǒng)〞中的能夠視點和需求來源：司機：來自火車司機的需求，能夠大部分是涉及可用性的非功能性需求軌道設備：來自軌道設備的需求，這些軌道設備將與系統(tǒng)發(fā)生交互已有的其它系統(tǒng)：來自曾經(jīng)存在的其它系統(tǒng)的兼容性需求平安工程師：來自于鐵路平安工程師的系統(tǒng)平安性需求火車制動安裝的特征：從火車制動安裝的特性中導出的需求什么是視點？視點：需求相關(guān)者對問題某個方面的觀念，顯式區(qū)別不同的需求來源視點是分別關(guān)注點的一種方法，讓參與者僅僅關(guān)注他們感興趣的問題，忽略與他們無關(guān)的問題提供組織和構(gòu)造化這些不同信息的機制提供手段，讓需求源或需求相關(guān)者標識和檢查他們對需求的奉獻第十講：面向視點的需求方法構(gòu)造化分析和設計技術(shù)〔SADT〕控制需求表達〔CORE〕面向視點的系統(tǒng)工程〔VOSE〕面向視點的需求定義〔VORD〕面向視點的需求驗證“問題〞需求的處置框架從構(gòu)造化分析和設計技術(shù)〔SADT〕中談起SADT方法由長方形〔表示活動〕和不同含義的箭頭組成將問題分解為層次圖，每層含一組長方形和箭頭低層的是高層的精化最上層的是上下文圖，表示系統(tǒng)的輸入／輸出／控制／支撐機制SADT方法中的視點沒有顯式的視點定義，是其建模技術(shù)的直觀推行由它的數(shù)據(jù)和來源和去向決議視點SADT方法中的視點視點Libraryuser表示檢查和未檢查的館藏的來源和目的地視點Issueclerk表示檢查這些館藏并注明歸還日期視點Itemdatabase表示關(guān)于館藏的信息的來源和要修正的信息視點Userdatabase表示驗證合法用戶的信息來源SADT方法中的視點視點只是一種直覺,而沒有明確的表示沒有關(guān)凝視點定義的專門步驟視點只出如今上下文層沒有超出只將視點作為數(shù)據(jù)的來源和出處的視點分析控制式需求表達〔CORE〕CORE方法概述英國宇航局，七十年代末期關(guān)注功能分解〔與SADT一樣〕，但不同的是，它顯式地以視點為根底用于歐洲宇航工業(yè)界，著名的工程包括：八十年代中旬的實驗飛行器方案，CORE用于系統(tǒng)和軟件定義最近的歐洲戰(zhàn)斗機方案，CORE作為規(guī)范的需求分析方法CORE方法中的視點分兩層思索視點第一層次：識別與目的系統(tǒng)交互的或者影響目的系統(tǒng)的實體CORE提供識別功能性和非功能性視點的指南第二層次：區(qū)別定義視點和邊境視點定義視點：系統(tǒng)的子過程，采用自頂向下的方式限界視點：間接地與目的系統(tǒng)發(fā)生交互的實體CORE方法的步驟迭代式過程視點識別視點構(gòu)造化表表示的采集數(shù)據(jù)構(gòu)造化單視點建模組合視點建模約束分析舉例〔圖書館管理〕第一步：識別視點〔頭腦風暴，識別能夠?qū)嶓w〕舉例〔圖書館管理〕第一步：識別視點〔區(qū)分定義視點和限界視點〕舉例〔圖書館管理〕第二步：視點構(gòu)造化功能子系統(tǒng)層次構(gòu)造，自頂向下分解限界視點在一樣的層次上舉例〔圖書館管理〕第三步：表表示法采集視點信息的一種機制包括：執(zhí)行的行為、這些行為要運用的數(shù)據(jù)、導出的輸出數(shù)據(jù)、數(shù)據(jù)的來源、數(shù)據(jù)的目的地主要偏重在信息流建模，便于視點間數(shù)據(jù)流沖突的檢測，包括數(shù)據(jù)來源和目的地的一致性等舉例〔圖書館管理〕SourceInputActionOutputDestinationLibraryuserRequesteditemCheckitemIssueditemLibraryuserErrormessageIssueclerkLibraryuserLibrarycardValidateuserLoandefaultmessageIssueclerkCORE方法的其他步驟第四步，數(shù)據(jù)構(gòu)造化：將數(shù)據(jù)項分解為其組成部分，創(chuàng)建數(shù)據(jù)字典第五步和第六步，單視點建模和多視點組合建模：采用活動圖為視點活動建模，類似于SADT，闡明活動的過程，以及關(guān)聯(lián)到的表集第七步，約束分析：將系統(tǒng)看作一個整體進展分析CORE方法的問題討論任何實體都可以是視點，對什么是視點短少明確的界定定義視點和限界視點使視點的識別更加復雜限界視點是將與目的系統(tǒng)發(fā)生信息交互的外部實體定義視點是目的系統(tǒng)的子過程分析比較薄弱，僅關(guān)注于內(nèi)部視點〔定義視點〕，對限界視點不進展分析，它們只是作為與系統(tǒng)交互的數(shù)據(jù)來源和目的地面向視點的系統(tǒng)工程〔VOSE〕VOSE概述九十年代早期，ImperialCollegeLondon根本原理：軟件開發(fā)涉及許多專家的參與這些專家關(guān)注于軟件開發(fā)和運用領(lǐng)域的不同方面每個專家都只擔任或關(guān)注他所關(guān)懷的方面VOSE視點運用視點來捕獲上述不同的方面，劃分和分布參與者的活動和知識捕獲參與者在軟件開發(fā)特定階段的角色和職責經(jīng)過參與者的角色來識別視點不同角色的知識封裝在一個視點內(nèi)，VOSE提供了視點的表示風格什么是視點?松耦合、部分管理、分布的對象，它封裝了關(guān)于系統(tǒng)及其領(lǐng)域的：部分表示知識開發(fā)過程知識規(guī)格闡明知識規(guī)范視點框架描畫該視點運用的表示格式描畫該視點的開發(fā)行為，過程和戰(zhàn)略標識相對于要開發(fā)的整個系統(tǒng)而言該視點的關(guān)注點按style槽規(guī)定的，采用workplan槽中描畫的戰(zhàn)略開發(fā)的表示法描畫視點維護視點規(guī)格闡明的開發(fā)形狀，經(jīng)過它可以實現(xiàn)需求的可追蹤性，記錄一些方式的開發(fā)理念。視點類型一個視點框架就是一個視點類型，它只包含風格〔style〕槽任務方案〔workplan〕槽按照任務方案槽中定義的行為開發(fā)視點，得到視點類型的一個實例主要研討的問題視點的表示視點內(nèi)部的交互視點之間的交互沖突消解視點框架視點框架是可重用的描畫，可以多次實例化，得到多個視點框架的一次實例化過程就是一個視點的開發(fā)過程框架不僅描寫視點要表示的需求,還表達了視點的開發(fā)方法和開發(fā)過程視點擁有者：擔任制定該視點的過程模型的人或者智能工具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ī)那么實踐上部分定義了視點表示的語義是方法設計者確定良定規(guī)格闡明的根據(jù)視點間檢查檢查不同視點規(guī)格闡明間的一致性視點間一致性規(guī)那么規(guī)定在什么情況下出現(xiàn)不一致視點觸發(fā)活動為了創(chuàng)建新視點(實例化視點框架)而必需執(zhí)行的活動普通作為一個其它開發(fā)活動的結(jié)果，比如：在agent層次中添加一個agent觸發(fā)為這個agent創(chuàng)建一個新的視點在功能分解層次中添加一個子過程，觸發(fā)創(chuàng)建一個表集視點過程模型兩類視點框架Agent構(gòu)造視點表集視點Agent構(gòu)造視點表集視點〔一〕表集視點〔二〕視點間的關(guān)系〔一〕視點間的關(guān)系〔二〕案例〔圖書館〕識別信息處置實體，作為Agent，用Agent層次構(gòu)造將它們組合起來LibraryWorld視點案例〔圖書館〕針對每個葉子agent，構(gòu)造描寫信息處置過程的表構(gòu)造Borrower視點其它視點內(nèi)活動檢查源和目的地的存在性，針對agent的層次構(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)系定義視點之間的構(gòu)造約束視點間規(guī)那么的征引在創(chuàng)建包含該規(guī)那么的視點類的實例〔源視點〕時，聲明：至少要有一個目的視點，使得它將與源視點維護這個關(guān)系可以觸發(fā)目的視點的創(chuàng)建VPsVPdsuchthatVPsVPd視點集成〔征引〕視點間規(guī)那么的運用檢查方式：？失敗導致不一致性處置變換方式：f(,VPs,VPd)將一個視點中的對象或關(guān)系一對一映射到另一個視點的對應對象或關(guān)系上〔滿足關(guān)系〕視點集成〔運用〕視點集成視點間不一致性的處置視點間不一致性的處置視點間不一致性的處置利用封鎖世界假設，可以推出矛盾：討論根本觀念：在處置概念建模問題時，建立多個代表不同視角的片段模型，比試圖構(gòu)造單個模型要好分別地為不同涉眾建模，然后再組合起來，會導致對領(lǐng)域的更豐富的了解視點方法的益處得到涉眾的認可：分別地獲取不同涉眾的視點，他們可以看到本人的奉獻構(gòu)造化過程：需求制品的并行開發(fā)，不受一致性的局限，建模過程可以分派給不同的開發(fā)小組延遲承諾：允許問題的不同表示，對哪些需求更重要的問題，他們應該如何建模等，分析員可以推遲做出選擇，直到對涉眾的視角有更好的了解其它能夠的益處視點建模改良可追蹤性：由于比較和合并是顯式地進展的，過程可以記錄下來視點建模改良結(jié)果模型的可讀性：原始涉眾對模型的了解才干視點建模改良捕獲不同觀念和微弱觀念的才干：沒有視點，有些不符合特定建模原那么的現(xiàn)實會被忽略視點建模使小組的建模更容易，由于分解了建模義務帶來的新問題如何識別視點之間的關(guān)系？如何發(fā)現(xiàn)和處置不一致性？經(jīng)過實驗評價這個方法多倫多大學問題：KidsHelpPhone根本表示框架：I*實驗設計全局建模組開發(fā)包含一切事務的單個I*模型視點開發(fā)組為每個被面談的涉眾開發(fā)個體模型，然后合并它們獲得整個模型，合并過程由整個開發(fā)組共同完成全局開發(fā)組的活動輸入：14個事務概念獲?。杭s950個意圖元素，約120個潛在的Actors和RolesSR模型：9個分別的SR模型結(jié)果檢查：交叉檢查、裁剪過合并元素推斷9個SR模型之間的戰(zhàn)略依賴關(guān)系，得出一個完好的組織SD模型視點開發(fā)組的活動視點劃分：14個事務分成3組分別開發(fā)：每個模型僅包含本組事務中的信息，排除其它事務的信息模型采用與涉眾一樣的詞匯視點合并選擇一個看起來被一切視點共享的元素作為開場點構(gòu)造一個合并模型，使它包含能與一切視點匹配的元素和只出如今一個視點中出現(xiàn)的元素假設元素表示的詳細程度不同，那么運用最詳細的版本假好像一個術(shù)語被用來表示不同的概念，改動其中的一個術(shù)語，使可以區(qū)別這個不同假好像一個概念在不同的視點中采用了不同方式來表示，就比較費事，經(jīng)常需求開發(fā)一個新的構(gòu)造普通的結(jié)論兩個組都覺得從文本中抽取模型元素比較困難對更大的模型，獨一實踐的方法是將它劃分成許多分別的視圖〔留意不是視點〕比較模型規(guī)模是全局開發(fā)組的難題從事務中抽取的意圖元素太多不好管理，也無法檢查類似項難以決議如何將一個大的模型劃分為小的視圖不得不將大的actor分割成小的roles，否那么依賴關(guān)系太多模型太大導致圖形規(guī)劃問題，可讀性遭到影響，檢查和驗證幾乎不能夠視點開發(fā)組可以抑制這些問題模型的規(guī)模比較后向可追蹤性視點開發(fā)組比較容易做到全局開發(fā)組比較難，在整個開發(fā)過程，他們只查閱了原始事務描畫5次它們的模型離原始事務比較遠，在建模過程中引入了許多原始事務中沒有的概念，意圖元素的列表是原始事務和模型之間的中間表示意圖元素的列表對選擇建模問題的初始分解起到重要作用比較視點合并是視點開發(fā)組的主要難題，這個組不得不針對一切不同點提出處理方案，經(jīng)常要回到原始事務描畫中，識別某個概念的真正含義，需求一切的建模人員參與不同詳細程度不同建模風格不同方式化程度建模過于自在不同術(shù)語比較模型分析，不同小組開發(fā)的模型，采用不同的模型分析技術(shù)：全局開發(fā)組的模型用目的評價過程視點開發(fā)組的模型讓涉眾檢查分析，了解涉眾之間觀念的不同“問題〞需求的處置框架對軟件問題本身只有有限的理解需求相關(guān)者眾多軟件復雜程度的增加需求陳述比較模糊，需求信息不完整，不同相關(guān)人的需求陳述重疊、冗余甚至相互沖突等軟件需求抽取和表達中的困難相關(guān)任務不一致需求的檢測和處理1993年，Easterbrook等人1999年，Nuseibeh等人1997年Spanoudakis2005年，Haase等人1998年，Hunter等人2001年，Easterbrook等人2002年，Konieczny2003年Sabetzadeh等人1998年Lamsweerde等人2001年Nentwich等人不一致需求的管理框架

實際上，不一致信息和“有問題”的需求信息緊密相連，

需求信息的不完整性和冗余性的處理，在一些相關(guān)文獻中只是略有涉及，缺乏深入的探討。在I﹡和AGORA方法中，對不完整需求說明的檢測通過在與/或圖中簡化和說明目標來完成。這個方面還缺少統(tǒng)一有效的處理方法和技術(shù)。需求的完整性總是與一致性和正確性問題聯(lián)系在一起的，它們之間存在重要的因果關(guān)系。好的需求規(guī)格闡明

“好”的需求規(guī)格說明應該具備的基本特征:完整性一致性無二義性可跟蹤性適宜需求推理的邏輯工具適合需求推理的邏輯工具至少應該具有如下特點：超協(xié)調(diào)性非單調(diào)性在語法上可以區(qū)分不同的非規(guī)范信息在語義上可以對非規(guī)范需求表示賦以{true，false}以外的真值超協(xié)調(diào)邏輯無合?。篈和B不能推出AB無真值關(guān)系：A的真值與A的真值無關(guān)多值系統(tǒng)：3值或4值邏輯相關(guān)邏輯：運用不同的蘊涵操作子弱化證明：限制證明的方式〔如QC-LOGIC〕定理證明技術(shù)〔QC-logic〕不利用封鎖世界假設定理證明技術(shù)〔QC-logic〕擴展可滿足性關(guān)系：強可滿足+弱可滿足定理證明技術(shù)〔QC-logic〕“問題〞需求的種類非規(guī)范需求（不一致性）設<ΔI,ΔE>是一個場景，Δ是與該場景相關(guān)的需求說明。如果Δ∪ΔI╞α:r,r∈{┬,┬p},那么稱Δ相對于該場景來說是不一致的。否則，稱Δ相對于該場景是一致的。（潛在不一致性）

設<ΔI,ΔE>是一個場景，Δ是與該場景相關(guān)的需求說明。假設Δ∪ΔI是一致的。如果Δ∪ΔI╞α:t（或Δ∪ΔI╞α:f）并且Δ∪ΔI╞α:fp（或Δ∪ΔI╞α:tp），那么稱Δ相對于該場景是潛在不一致的。（冗余性）設<ΔI,ΔE>是一個場景，Δ是與該場景相關(guān)的需求說明。如果?Γ?Δ使得?！圈╞ΔE并且Γ相對于該場景是一致的，那么稱Δ相對于該場景是冗余的。進而，Γ被看作是Δ相對于該場景的一個簡化。（不完整性）設<ΔI,ΔE>是一個場景，Δ是與該場景相關(guān)的需求說明。如果?Φ∈ΔE使得Δ∪ΔI|≠Φ，那么稱Δ相對于該場景是不完整的。一個適宜的邏輯工具帶注釋的謂詞演算〔AnnotatedPredicateCalculus，APC〕每一個經(jīng)典的原子公式〔e.g.l〕都伴隨有一個來自于信任半格〔beliefsemilattice，BSL〕的值〔e.g.r〕作為注釋。例：Reserve(User,Book):t→Borrow(User,Book):tp“問題〞需求的處置框架非規(guī)范軟件需求一致管理框架需求規(guī)格闡明Δ運用場景輸入ΔI,期望呼應ΔE自然言語描畫的需求規(guī)格闡明自然言語描畫的運用場景方式化：翻譯成APC邏輯公式不一致性潛在不一致性冗余性不完好性需求推理Δ∪ΔI╞┬？分析推理結(jié)果修正處置方案選擇〔決策機制〕對于模糊需求信息采用如下元策略或者規(guī)則：對與（潛在）不一致性有關(guān)聯(lián)的模糊信息采取降格策略；對與不一致性無關(guān)的模糊信息采取確認或者升格策略。

對于冗余需求信息，必要需求描述不能被移除，而有用但不必要的需求描述則代表了客戶需求的一種可能的方式；無用的需求描述是完全冗余的，他們最終需要被精簡掉。對不完整的需求，

在實際操作過程中，我們可以通過向需求說明中添加該場景中未