淨室與其他軟體工程實踐的關係 (轉)
淨室與其他工程實踐的關係
未經允許,嚴禁轉載本欄目內容本文經許可轉載自軟體工程專家網,
未經CSDN許可,請勿隨便轉載,謝謝合作?page=/bbs/index.asp?Type=D">
淨室過程對許多當前使用中成功的軟體實踐提供了強有力的支援。
一、面向
淨室過程為物件導向開發提供了可管理性和技術嚴密性(Ett和Trammell 1995)。物件從本質上來說是封裝了資料和一系列服務的狀態機器。一個淨室用黑盒檢視(一個物件的外部行為)、狀態盒檢視(一個物件的封裝資料)和明盒檢視(處理外部需求和訪問封裝資料的服務)來定義。一個淨室元件從技術上講就是一個物件。淨室盒子結構有助於產生一個完備、一致和正確的物件行為規範。而且,盒子結構有助於定義和管理資料並且控制資料在各個物件之間的流動。
在淨室技術中,數學形式化方法成為規範、設計、正確性驗證和測試的基礎。這種成熟的形式化方法可為相對直觀的物件導向方法增加精確性和可預見性。淨室是應用工程而非領域工程的一種方法。物件導向方法的普遍力量在於尋求某領域應用特徵的關係和抽象。物件導向的領域分析可作為淨室應用工程的補充。
二、軟體複用
成功的軟體元件複用需要對元件功能在語義上有精確的定義,還需元件在特定使用環境中得到質量和可靠性認證。沒有這些保證,複用將是不可預見的和冒險的。
淨室黑盒規範能從語義上定義所有可能的使用情況。如果內部重用的範圍窄於元件的範圍(如減小了可變範圍),可透過限制黑盒的定義域來制定範圍減小的規範。一個“包裝”(一個包含重用元件的元件)可以加強元件的並置條件。
一個現成重用元件的適應性常常是透過試執行來評估的。淨室認證透過統計測試能提高特定使用環境的質量和可靠性度量。統計測試允許從特定使用情況和指定置信度水平評估元件的可靠性。
結合淨室可靠性方案,Poore、Mills和Mutchler(1993)改進了一種複用分析的定量方法。利用這種方法,在頂層設計時就可建立元件的可靠性和轉移機率。如果給定元件的可靠性指標,透過頂層元件網的定量分析可得到關於可靠性的上界。分析結果可用於評估元件重用的生命力。
三、軟體體系結構
在眾多軟體體系結構的定義中,一個共同的主題是:軟體體系結構定義了主要的元件和它們之間的關係。淨室提供了一個過程來準確定義體系結構的功能性語義--------是什麼元件以及它們之間有什麼關係。
淨室狀態盒和明盒中高層的內部設計關係到系統主要元件以及它們之間的關係:主要的資料物件由狀態盒設計確定,資料物件的主要操作由明盒設計完成。最後,高層明盒設計體現了系統體系結構的主要元素。
淨室規範和設計包括對一個系統解空間的系統的探索。黑盒和狀態盒的關係是一對多,必須從一個物件集中做出選擇。狀態盒和明盒的關係也是一對多,必須從一個物件操作集中做出選擇。軟體體系結構的進化將產生設計的分類,淨室工作者的設計選擇隨著盒子結構設計被編成目錄。
簡而言之,淨室系統總在明晰體系結構,但從沒命名(除“系統頂層明盒”之外)。在研究軟體體系結構時對設計模型的命名和描述將加速對設計選擇的評估。
四、檢查和評審
淨室正確性驗證允許在檢查和評審中增加額外的技術嚴密性和精確性。除了使用本地檢查列表外,淨室還利用基於函式的理論:一個(程式碼)實現一個函式(規範)對程式碼和設計進行評審。淨室評審的目的是驗證實現了的功能規範的正確性。對程式碼的評審總是對照其所實現的功能規範進行,而不是空對空的。
淨室規範和設計產品具有內部的可跟蹤性。在盒子結構規範和設計的每一步都要進行同樣的評審。要對每個工作產品進行評審,對應的小組成員要對工作產品的正確性負責。最終的成功是小組的成功,失敗也是小組的失敗。健全的技術和小組對正確性的責任的結合是預防缺陷非常有效的方法。
五、軟體測試方法
淨室測試基於使用模型對給定版本的軟體的預期操作產生有根據的統計參考。淨室使用模型也可用於其他測試目的,如最大覆蓋測試和加強關鍵功能。使用模型為模型覆蓋測試、隨機測試、重點測試、劃分測試和其他形式的測試提供了科學的基礎。
人工測試(Crafted testing)同樣可用於淨室過程。有必要為特定環境的系統執行提供專門的測試用例以消除不確定性。另外,在後臺執行的程式碼覆蓋工具可作為使用測試的補充。迴歸測試、結構(白盒)測試和其他測試方法和淨室是相容的。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10748419/viewspace-997161/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 淨室軟體工程及發展 (轉)軟體工程
- 軟體工程實踐(一) (轉)軟體工程
- 軟體工程實踐(二) (轉)軟體工程
- 軟體工程實踐----初步接觸軟體工程的總結軟體工程
- 物件導向軟體工程方法學實踐 (轉)物件軟體工程
- 【軟體工程理論與實踐】Homework(四.1)軟體工程
- 軟體工程實踐總結軟體工程
- ERP和其他管理軟體之間的邏輯關係
- “輕”方法與滿意質量——市場驅動的軟體工程實踐 (轉)軟體工程
- 軟體工程,實踐作業1軟體工程
- (原)ERP和其他管理軟體之間的邏輯關係
- 【軟體工程理論與實踐】Homework(一.2,3)軟體工程
- 下一代軟體工程的思考與點滴實踐軟體工程
- ERP和其他管理軟體之間的邏輯關係(原創)
- 軟體工程實踐總結作業軟體工程
- 物聯網與erp軟體的關係
- 專案管理軟體與IT業界專案經理人的關係(2)(轉)專案管理
- 專案管理軟體與IT業界專案經理人的關係(3)(轉)專案管理
- 專案管理與軟體工程(轉)專案管理軟體工程
- 軟體工程實踐專案學習與執行日誌軟體工程
- 淨室基礎 (轉)
- 我的軟體實驗室
- 好文分享:軟體測試與世界盃的關係
- 軟體工程與管理實驗3軟體工程
- C++與OOP,謊言?現實?軟體工程的嘗試? (轉)C++OOP軟體工程
- 雲音樂隱性關係鏈的探索與實踐
- 軟體、軟體危機、軟體工程 (轉)軟體工程
- 現代語文與軟體測試學的關係
- 軟體工程 第一章 軟體與軟體工程軟體工程
- 讀《大道至簡:軟體工程實踐者的思想》有感軟體工程
- 軟體工程的實踐專案課程的自我目標軟體工程
- 軟體工程管理(轉)軟體工程
- PHP創始人:開源與商業軟體是競合關係(轉)PHP
- Marty Cagan:產品管理與軟體開發的關係
- 個人作業——軟體工程實踐總結作業軟體工程
- 《大道至簡--軟體工程實踐者的思想》讀後感軟體工程
- 《大道至簡——軟體工程實踐者的思想》讀後感軟體工程
- 論Asp與XML的關係(轉)XML