中科院需求工程8d講)多視點需求工程與矛盾需求處理-預覽頁
【正文】 B o o k s u p p l i e rI t e m d a t a b a s eR e g i s t e r u s e rU p d a t e i t e m d a t a b a s e 舉例（圖書館管理） ? 第一步：識別視點（區(qū)分定義視點和限界視點） L i b r a r y u s e rC a t a l o g u e O r d e r i t e mI s s u e i t e m R e t u r n i t e mV a l i d a t e u s e rU s e r d a t a b a s eI s s u e c l e r kB o o k s u p p l i e rI t e m d a t a b a s eR e g i s t e r u s e rU p d a t e i t e m d a t a b a s e限 界 視 點 定 義 視 點 舉例（圖書館管理） ? 第二步：視點結(jié)構(gòu)化 –功能子系統(tǒng)層次結(jié)構(gòu)，自頂向下分解 –限界視點在相同的層次上 L i b r a r y w o r l dL i b r a r y w o r l dL i b r a r y w o r l d L i b r a r y w o r l dL i b r a r y w o r l d L i b r a r y w o r l dO r d e rU p d a t eI s s u eR e g i s t e r 舉例（圖書館管理） ? 第三步：表表示法 –采集視點信息的一種機制 –包括：執(zhí)行的行為、這些行為要使用的數(shù)據(jù)、導出的輸出數(shù)據(jù)、數(shù)據(jù)的來源、數(shù)據(jù)的目的地 –主要側(cè)重在信息流建模，便于視點間數(shù)據(jù)流沖突的檢測，包括數(shù)據(jù)來源和目的地的一致性等 舉例（圖書館管理） Source Input Action Output Destination Library user Requested item Check item Issued item Library user Error message Issue clerk Library user Library card Validate user Loan default message Issue clerk CORE方法的其余步驟 ? 第四步，數(shù)據(jù)結(jié)構(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概述 ? 九十年代早期， Imperial College London ? 基本原理： –軟件開發(fā)涉及許多專家的參與 –這些專家關(guān)注于軟件開發(fā)和應用領(lǐng)域的不同方面 –每個專家都只負責或關(guān)注他所關(guān)心的方面 VOSE視點 ? 使用視點來捕獲上述不同的方面，劃分和分布參與者的活動和知識 ? 捕獲參與者在軟件開發(fā)特定階段的角色和職責 ? 通過參與者的角色來識別視點 ? 不同角色的知識封裝在一個視點內(nèi)， VOSE提供了視點的表示風格 什么是視點 ? ? 松耦合、局部管理、分布的對象，它封裝了關(guān)于系統(tǒng)及其領(lǐng)域的： –部分表示知識 –開發(fā)過程知識 –規(guī)格說明知識 標準視點框架 描述該視點使用的表示格式 描述該視點的開發(fā)行為，過程和策略 標識相對于要開發(fā)的整個系統(tǒng)而言該視點的關(guān)注點 按 style槽規(guī)定的，采用 work plan槽中描述的策略開發(fā)的表示法描述視點 維護視點規(guī)格說明的開發(fā)狀態(tài)，通過它可以實現(xiàn)需求的可追蹤性，記錄一些形式的開發(fā)理念。這個方面還缺少統(tǒng)一有效的處理方法和技術(shù)。否則，稱 Δ相對于該場景是一致的。 （冗余性） 設(shè) ΔI,ΔE 是一個場景， Δ是與該場景相關(guān)的需求說明。如果 ?Φ∈ ΔE使得 Δ∪ ΔI|≠Φ， 那么稱Δ相對于該場景是不完整的。 對不完整的需求， 在實際操作過程中，我們可以通過向需求說明中添加該場景中未能得到的期望響應的降格形式來提醒開發(fā)人員去收集完善相關(guān)的需求信息。 不一致性處理的群體決策機制 不一致性處理的群體決策機制 協(xié)商元語言，包括如下幾種語言行為： ? request(i, j,φ)：從主體 i到主體 j關(guān)于提議 φ的請求； ? offer(i, j,φ)： 主體 i向主體 j提出一個提議 φ； ? accept(i, j,φ)：主體 i接受了主體 j的提議 φ； ? reject(i, j,φ)：主體 i拒絕了主體 j的提議 φ； ? withdraw(i, j)：主體 i退出與主體 j的協(xié)
環(huán)評公示相關(guān)推薦
鄂ICP備17016276號-1