體系結構第1章認識體系結構ppt課件

《體系結構第1章認識體系結構ppt課件》由會員分享，可在線閱讀，更多相關《體系結構第1章認識體系結構ppt課件（86頁珍藏版）》請在裝配圖網(wǎng)上搜索。

軟件體系結構,1,第1章 軟件體系結構概論,從軟件危機談起 ◎ 軟件成本日益增長 ◎ 開發(fā)進度難以控制 ◎ 軟件質量差 ◎ 軟件維護困難,2,,軟件成本日益增長 20世紀50年代，軟件成本在整個計算機系統(tǒng)成本中所占的比例為10%-20%。到20世紀60年代中期，軟件成本在計算機系統(tǒng)中所占的比例已經(jīng)增長到50%左右。 而且，該數(shù)字還在不斷地遞增，下面是一組來自美國空軍計算機系統(tǒng)的數(shù)據(jù)：1955年，軟件費用約占總費用的18%，1970年達到60%，1975年達到72%，1980年達到80%，1985年達到85%左右。,3,,開發(fā)進度難以控制 由于軟件是邏輯、智力產品，軟件的開發(fā)需建立龐大的邏輯體系，這是與其他產品的生產不一樣的。 在軟件開發(fā)過程中，用戶需求變化等各種意想不到的情況層出不窮，令軟件開發(fā)過程很難保證按預定的計劃實現(xiàn)，給項目計劃和論證工作帶來了很大的困難。 盲目增加軟件開發(fā)人員并不能成比例地提高軟件開發(fā)能力。相反，隨著人員數(shù)量的增加，人員的組織、協(xié)調、通信、培訓和管理等方面的問題將更為嚴重。,4,,軟件質量差 軟件項目即使能按預定日期完成，結果卻不盡人意。1965年至1970年，美國范登堡基地發(fā)射火箭多次失敗，絕大部分故障是由應用程序錯誤造成的。 在“軟件作坊”里，由于缺乏工程化思想的指導，程序員幾乎總是習慣性地以自己的想法去代替用戶對軟件的需求，軟件設計帶有隨意性，很多功能只是程序員的“一廂情愿”而已，這是造成軟件不能令人滿意的重要因素。,5,,軟件維護困難 由于在軟件設計和開發(fā)過程中，沒有嚴格遵循軟件開發(fā)標準，各種隨意性很大，沒有完整的真實反映系統(tǒng)狀況的記錄文檔，給軟件維護造成了巨大的困難。 特別是在軟件使用過程中，原來的開發(fā)人員可能因各種原因已經(jīng)離開原來的開發(fā)組織，使得軟件幾乎不可維護。 有資料表明，工業(yè)界為維護軟件支付的費用占全部硬件和軟件費用的40%-75%。,6,軟件危機的原因,用戶需求不明確 缺乏正確的理論指導 軟件規(guī)模越來越大 軟件復雜度越來越高,7,,用戶需求不明確 在軟件開發(fā)完成之前，用戶不清楚軟件的具體需求； 用戶對軟件需求的描述不精確，可能有遺漏、有二義性、甚至有錯誤； 在軟件開發(fā)過程中，用戶還提出修改軟件功能、界面、支撐環(huán)境等方面的要求； 開發(fā)人員對用戶需求的理解與用戶本來愿望有差異。,8,,缺乏正確的理論指導 缺乏有力的方法學和工具方面的支持。由于軟件不同于大多數(shù)其他工業(yè)產品，其開發(fā)過程是復雜的邏輯思維過程，其產品極大程度地依賴于開發(fā)人員高度的智力投入。由于過分地依靠程序設計人員在軟件開發(fā)過程中的技巧和創(chuàng)造性，加劇軟件產品的個性化，也是發(fā)生軟件危機的一個重要原因。,9,,軟件規(guī)模越來越大 隨著軟件應用范圍的增廣，軟件規(guī)模愈來愈大。大型軟件項目需要組織一定的人力共同完成，而多數(shù)管理人員缺乏開發(fā)大型軟件系統(tǒng)的經(jīng)驗，而多數(shù)軟件開發(fā)人員又缺乏管理方面的經(jīng)驗。各類人員的信息交流不及時、不準確、有時還會產生誤解。 軟件項目開發(fā)人員不能有效地、獨立自主地處理大型軟件的全部關系和各個分支，因此容易產生疏漏和錯誤。,10,,軟件復雜度越來越高 軟件不僅僅是在規(guī)模上快速地發(fā)展擴大，而且其復雜性也急劇地增加。軟件產品的特殊性和人類智力的局限性，導致人們無力處理“復雜問題”。 所謂“復雜問題”的概念是相對的，一旦人們采用先進的組織形式、開發(fā)方法和工具提高了軟件開發(fā)效率和能力，新的、更大的、更復雜的問題又擺在人們的面前。,11,如何克服軟件危機,人們面臨的不光是技術問題，更重要的是管理問題。管理不善必然導致失敗 。 要提高軟件開發(fā)效率，提高軟件產品質量，必須采用工程化的開發(fā)方法與工業(yè)化的生產技術。 在技術上，應該采用基于重用的軟件生產技術；在管理上，應該采用多維的工程管理模式。,12,“建筑體系結構”,13,前言 體系結構簡稱架構或構架。 構：本義架木造屋，引申為構造 構架：建筑的結構 結：用繩、線、皮條等綰成的疙瘩；關鍵點；被聯(lián)結狀態(tài) 結構：組成整體的各部分的搭配和安排 對住房的功能需求：能夠居住。 對住房的質量需求： 安全性：能避免地震、臺風、暴雨等各種自然災害。 居住者在建筑內的健康性，舒適性。 美觀性：有親和感，社會文化的體現(xiàn)。 不同住房具有相同的功能，但其架構不同，所滿足的居住質量也不相同。,14,人類最早的居住方式：巢居和穴居,炎熱或高海拔地區(qū)的穴居方式，可獲得相對穩(wěn)定的室內熱環(huán)境，頂部的天窗既可采光又可排煙。,15,愛斯基摩雪屋的外觀和室內布置,用干雪沏成，厚度500ｍｍ的墻體可以提供較好的保溫性能。當室外平均溫度－30℃時可維持室內溫度－5℃以上。,16,大陸氣候的中國民居,土窯洞借助土壤大熱慣性，達到冬暖夏涼的目的。,17,利用太陽高度角的特點，僅在北方出現(xiàn)。 四合院建筑冬季有效地利用了太陽能采暖和抵御北風侵襲，屋頂設計避免了夏季室內過熱。,中國四合院：座北朝南的典范,18,濕熱地區(qū)的中國民居,云南干闌竹樓：防雨，防濕和防熱。,19,地球環(huán)境還可持續(xù)發(fā)展嗎？,? 遍布全球的玻璃和鋼筋盒子建筑,空調的普及使人們不再關心建筑的冷暖，但高能耗又使環(huán)境受到影響。,20,為什么研究軟件架構? 思想有多遠，我們就能走多遠 高度決定思路，思路決定出路 系統(tǒng)的建立是為了滿足組織的需求（包括功能和質量），質量需求決定了系統(tǒng)必須達到的特征, 包括性能, 可靠性, 互操作性以及生命周期等。隨著軟件系統(tǒng)的日益復雜，涉眾對軟件的要求已不局限于功能上的滿足，而是更加注重質量。 很少有人注意到組織（開發(fā)組織、客戶等）在系統(tǒng)設計和系統(tǒng)成敗上扮演的角色。 系統(tǒng)的質量特征受到軟件架構的限制，或者說構架設計的選擇受到要達到的質量特征的影響。,21,,本課程的目的：對軟件體系結構的產生、演化做通俗介紹，減少對軟件體系結構認識的神秘感，對軟件體系結構設計提供實用的指導。,22,,第1部分: 軟件構架的基礎 第2部分: 構架的創(chuàng)建 第3部分: 構架的分析與評審,23,,課程形式 理論課、專題課、作業(yè) 成績評定 作業(yè)、考勤、考試 作業(yè) +考勤 30%、考試 70%,24,軟件架構的概念,25,軟件架構—在一定的設計原則基礎上，從不同角度對組成系統(tǒng)的各部分進行搭配和安排，形成系統(tǒng)的多個結構而組成架構，它包括該系統(tǒng)的各個組件、組件的外部可見屬性及相互關系。 外部可見屬性—指其它組件可對該組件所做的假設，如該組件提供的服務、具備的性能特征、錯誤處理、共享資源的使用。 為什么設計原則是架構的一部分？ 做事先做人 很多人不懂或不遵守走路的規(guī)則，結果丟掉性命 很多人不遵守開車的規(guī)則，結果造成嚴重交通事故 同樣，不遵循架構設計的原則，架構也容易失敗。,軟件架構的定義,26,架構定義可以從下面六個方面來理解： 架構應建立在一定的設計原則之上，否則很容易失敗。 系統(tǒng)可能由多個結構組成，其中任何一個結構都不能與構架等同。 每個軟件系統(tǒng)都有自己的架構。 軟件架構決定了各個組件。 只要某個組件的行為可以從其它組件的角度觀察到或區(qū)別開，這樣的行為就是軟件架構的內容。 軟件架構是抽象的，它不考慮實現(xiàn)、算法和數(shù)據(jù)表示的細節(jié)，而集中研究“黑盒”組件的行為和交互，是設計第一步。,27,其它觀點,觀點1 軟件架構是高層次的設計 觀點2 軟件架構是軟件系統(tǒng)的總體結構 觀點3 IEEE的定義：軟件架構是一個程序或系統(tǒng)的組件結構、組件之間的相互聯(lián)系及支配組件設計和進化的指導原則 觀點4 Perry和Wo1f提出：軟件架構是具有一定形式的結構化元素，包括處理元素、數(shù)據(jù)元素和連接元素。處理元素負責對數(shù)據(jù)進行加工，數(shù)據(jù)元素是被加工的信息，連接元素把架構的不同部分組合連接起來。,28,觀點5 Mary Shaw和David Garlan認為軟件體系結構是軟件設計過程中的一個層次，這一層次超越計算過程中的算法設計和數(shù)據(jù)結構設計。體系結構問題包括總體組織和全局控制、通訊協(xié)議、同步、數(shù)據(jù)存取，給設計元素分配特定功能，設計元素的組織，規(guī)模和性能，在各設計方案間進行選擇等。軟件體系結構處理算法與數(shù)據(jù)結構之上關于整體系統(tǒng)結構設計和描述方面的一些問題，如全局組織和全局控制結構、關于通訊、同步與數(shù)據(jù)存取的協(xié)議，設計構件功能定義，物理分布與合成，設計方案的選擇、評估與實現(xiàn)等。 觀點6 Kruchten指出，軟件體系結構有四個角度，它們從不同方面對系統(tǒng)進行描述：概念角度描述系統(tǒng)的主要構件及它們之間的關系；模塊角度包含功能分解與層次結構；運行角度描述了一個系統(tǒng)的動態(tài)結構；代碼角度描述了各種代碼和庫函數(shù)在開發(fā)環(huán)境中的組織。,29,這些角度形成了一個“4+1”的視角模型?！?+1”模型從5個不同的視角包括邏輯視角、過程視角、物理視角、開發(fā)視角和場景視角來描述軟件體系結構。每一個視角只關心系統(tǒng)的一個側面，5個視角結合在一起才能夠反映系統(tǒng)的軟件體系結構的全部內容?！?+1”模型如圖所示：,30,觀點7 Hayes Roth則認為軟件架構是一個抽象的系統(tǒng)規(guī)范，主要包括用其行為來描述的功能構件和構件之間的相互連接、接口和關系 。 觀點8 Barry Boehm提出，軟件架構包括系統(tǒng)構件，互聯(lián)及約束的集合；系統(tǒng)需求說明的集合；一個基本原理用以說明這一構件，互聯(lián)和約束能夠滿足系統(tǒng)需求。 觀點9 軟件架構為軟件系統(tǒng)提供了一個結構、行為和屬性的高級抽象，由構成系統(tǒng)的元素的描述、這些元素的相互作用、指導元素集成的模式以及這些模式的約束組成。軟件架構不僅指定了系統(tǒng)的組織結構和拓撲結構，并且顯示了系統(tǒng)需求和構成系統(tǒng)的元素之間的對應關系，提供了一些設計決策的基本原理。,31,設計僅是系統(tǒng)功能需求分析的產物？ 功能需求?設計?系統(tǒng)開發(fā)？,否也?。?！,2009年1月3號廣州火車站16萬張票同時出閘致系統(tǒng)癱瘓。,911中是世界貿易大廈的倒塌。,2007年1月18日，招商證券的客戶發(fā)現(xiàn)，在公司進行網(wǎng)絡交易時，公司網(wǎng)站竟然無法登陸。一部分客戶轉向電話服務尋求幫助，卻發(fā)現(xiàn)電話線路出現(xiàn)同樣的阻塞。行情轉瞬即逝。擁堵是由于交易量激增，原有系統(tǒng)容量不足引起的 。,奧運門票銷售系統(tǒng)的失敗,軟件架構的產生?,32,軟件體系結構研究的問題,結構性問題 系統(tǒng)的組織,由哪些組件構成 全局性的控制結構 通訊,同步或訪問的協(xié)議 將功能分配到不同的系統(tǒng)組成部分 設計元素的組成 系統(tǒng)的物理分布 可擴展性,性能,33,,主要內容包括 A對系統(tǒng)組成元素的描述 B這些元素相互之間的交互 C系統(tǒng)組成的模式 D模式的約束 所以在軟件構架中,系統(tǒng)以組件和組件之間的交互進行定義 當前的系統(tǒng)同時可以作為更高層設計的一個系統(tǒng)組件,34,軟件設計的層次,軟件設計可以在多個不同的層次,在每一層我們都會發(fā)現(xiàn)相應的組件以及由這些組件組成更大的組件的組合機制. 二進制執(zhí)行文件層 位模式 代碼層 編程語言的原語,操作符; 記錄,數(shù)組,過程; 構架層 模塊,35,軟件體系結構的意義,體系結構是風險承擔者進行交流的手段 軟件體系結構代表了系統(tǒng)的公共的高層次的抽象。這樣，系統(tǒng)的大部分有關人員（即使不是全部）能把它作為建立一個互相理解的基礎，形成統(tǒng)一認識，互相交流。 體系結構提供了一種共同語言來表達各種關注和協(xié)商，進而對大型復雜系統(tǒng)能進行理智的管理。這對項目最終的質量和使用有極大的影響。,36,,體系結構是早期設計決策的體現(xiàn) 軟件體系結構明確了對系統(tǒng)實現(xiàn)的約束條件 軟件體系結構決定了開發(fā)和維護組織的組織結構 軟件體系結構制約著系統(tǒng)的質量屬性 通過研究軟件體系結構可能預測軟件的質量 軟件體系結構使推理和控制更改更簡單 軟件體系結構有助于循序漸進的原型設計 軟件體系結構可以作為培訓的基礎,37,,軟件體系結構是可傳遞和可重用的模型 軟件體系結構級的重用意味著體系結構的決策能在具有相似需求的多個系統(tǒng)中發(fā)生影響，這比代碼級的重用要有更大的好處。,38,軟件體系結構的發(fā)展史,,“無體系結構”設計階段,39,,Perry和Wolf認為 未來的年代是研究軟件體系結構的時代,40,軟件體系結構的應用現(xiàn)狀,軟件體系結構描述語言 體系結構描述構造與表示 體系結構分析、設計與驗證 體系結構發(fā)現(xiàn)、演化與重用 基于體系結構的軟件開發(fā)方法 特定領域的體系結構框架 軟件體系結構支持工具 軟件產品線體系結構 建立評價軟件體系結構的方法,41,我們的目標,在軟件開發(fā)過程中使用軟件體系結構 成為系統(tǒng)架構師,42,系統(tǒng)架構師,系統(tǒng)架構師負責設計系統(tǒng)整體架構，從需求到設計的每個細節(jié)都要考慮到，把握整個項目，使設計的項目盡量效率高，開發(fā)容易，維護方便，升級簡單等。 系統(tǒng)構架師是近幾年來在國內外迅速成長并發(fā)展良好的一個職位。比爾? 蓋茨 （首席軟件架構師）；丁磊 （首席架構師 ）,43,,系統(tǒng)架構師的職責 l、領導與協(xié)調整個項目中的技術活動（分析、設計和實施等） 2、推動主要的技術決策，并最終表達為軟件構架 3、確定和文檔化系統(tǒng)的相對構架而言意義重大的方面，包括系統(tǒng)的需求、設計、實施和部署等“視圖” 4、確定設計元素的分組以及這些主要分組之間的接口 5、為技術決策提供規(guī)則，平衡各類涉眾的不同關注點，化解技術風險，并保證相關決定被有效的傳達和貫徹 6、理解、評價并接收系統(tǒng)需求 7、評價和確認軟件架構的實現(xiàn),44,,某集團公司要開發(fā)一個網(wǎng)絡財務程序，使各地員工能在互聯(lián)網(wǎng)絡上進行財務處理和報銷。在設計該財務程序的體系結構時，項目組產生了分歧： 張工程師認為應該采用客戶機/服務器（C/S）結構。各分公司財務部要安裝一個軟件客戶端，通過這個客戶端連接到總公司財務部主機。如果員工在外地出差，需要報銷帳務的，也需要安裝這個客戶端才能進行。 李工程師認為應該采用瀏覽器/服務器（BS）結構，各分公司及出差員工直接通過Windows操作系統(tǒng)自帶的IE瀏覽器就可以連接到總公司的財務部主機。,45,架構受系統(tǒng)風險承擔者的影響 風險承擔者—對構建軟件系統(tǒng)感興趣的人或組織，包括合同中的客戶、系統(tǒng)最終用戶、開發(fā)人員、開發(fā)組織、系統(tǒng)維護人員等，他們所關注的問題各不相同，但都要求系統(tǒng)在他們所關注的方面提供保證或優(yōu)化。,事物有主要矛盾和次要矛盾之分。 開發(fā)系統(tǒng)時，首先要確定其軟件構架。借助于構架，設計師可以分析眾多風險承擔者所提出的各種要求的優(yōu)先級，并將這些要求轉化為系統(tǒng)的各個特性，再針對它們在系統(tǒng)結構上做折衷，從而得到和諧的架構。,46,開發(fā)組織所關心的問題不同于客戶，它對軟件構架的影響分為3類： · 直接影響 如希望向產品線發(fā)展 · 長遠影響 如行業(yè)布局 · 組織結構的影響 如軟件外包 · 開發(fā)團隊的經(jīng)驗對設計師的影響,47,架構受設計師的素質和經(jīng)驗的影響,1 熟悉.NET的設計師在設計時會考慮.NET的框架和技術。 2 熟悉J2EE的設計師在設計時會考慮J2EE的框架和技術。 3 設計師具有數(shù)據(jù)庫方向的背景，系統(tǒng)會被認為是數(shù)據(jù)庫的應用。 4 設計師具有網(wǎng)絡安全的背景，系統(tǒng)的安全會被放在很突出的位置。,48,構架受技術環(huán)境的影響,現(xiàn)在B/S樣式很流行，設計師在設計時往往首先考慮系統(tǒng)能否在互聯(lián)網(wǎng)環(huán)境下運行。,49,架構所受的影響,50,軟件的架構不是靜止的,51,軟件在開發(fā)過程中或交付使用后，都可能會發(fā)生修改，這些修改往往涉及到架構的變更。因此軟件版本的演進也是軟件架構的演進。 軟件架構影響設計師的經(jīng)驗。 軟件架構影響開發(fā)組織的內部結構和經(jīng)營目標。 軟件架構可能會影響客戶對下個系統(tǒng)的需求 有些系統(tǒng)甚至會影響并實際改變軟件工程的發(fā)展，以及開發(fā)人員學習和實踐的技術環(huán)境，如互聯(lián)網(wǎng)、嵌入式、手機等。,52,架構商業(yè)周期—架構是軟件開發(fā)的必經(jīng)之路和必要手段，它受到來自客戶和開發(fā)組織的影響，也受到設計師的素質和經(jīng)驗以及技術環(huán)境的影響；反過來，構架也影響著被開發(fā)的系統(tǒng)，對客戶、開發(fā)組織、構架和技術環(huán)境也都有影響，還影響著客戶及其開發(fā)組織的未來目標。圍繞著構架的這些影響和反饋循環(huán)構成構架商業(yè)周期。 事物是靜止的，也是運動、發(fā)展和變化的，軟件架構也不例外。軟件的架構是運動、發(fā)展和變化的。,53,構件與軟件重用,構件模型及實現(xiàn) 構件是指語義完整、語法正確和有可重用價值的單位軟件，是軟件重用過程中可以明確辨識的系統(tǒng)；結構上，它是語義描述、通訊接口和實現(xiàn)代碼的復合體。,54,,在大多數(shù)工程學科中，系統(tǒng)是通過組合現(xiàn)有構件進行設計的，這些構件已經(jīng)在其它系統(tǒng)上使用過。 軟件工程一直以來注重于原始開發(fā)，現(xiàn)在已經(jīng)認識到要更快、更低成本的獲得更好的軟件，我們需要采取一種基于系統(tǒng)化軟件復用（systematic software reuse）的設計過程。,55,,在軟件演化的過程中，重復使用的行為可能發(fā)生在三個維上： 1. 時間維：使用以前的軟件版本作為新版本的基礎，加入新功能，適應新需求，即軟件維護。 2. 平臺維：以某平臺上的軟件為基礎，修改其和運行平臺相關的部分，使其運行于新平臺，即軟件移植。 3. 應用維：將某軟件(或其中構件)用于其他應用系統(tǒng)中，新系統(tǒng)具有不同功能和用途，即真正的軟件復用。,56,,促進從手工作坊式的軟件開發(fā)向工業(yè)化開發(fā)發(fā)展： 核心的就是軟件構件技術。工業(yè)化的軟件生產，應該有一個工業(yè)化的軟件生產線，軟件生產應該做成什么樣，應該有不同的車間，有的車間專門是做構架的，就是框架。有的車間做構件，零件。,57,復用的好處,增強可靠性（Increased reliability） 復用構件在工作系統(tǒng)上試用過，應該比新軟件更可靠。失誤已經(jīng)在初始使用中暴露和解決，復用軟件的失效數(shù)目應比較低。 減少過程風險（Reduced process risk） 有現(xiàn)成的軟件，成本比重新開發(fā)低。同時降低了項目成本估算的不確定性。在大型系統(tǒng)中，如果子系統(tǒng)是復用的，效果最明顯。 符合標準（Standards compliance） 有些象用戶界面這樣的標準，，就可以制成一組可復用的標準構件。例如，如果把用戶界面中的菜單（Menu）做成可復用的構件，并讓所有的應用都采用相同的菜單格式展現(xiàn)給用戶。使用這樣的標準用戶界面就使系統(tǒng)的可信度得到改善，因為用戶在相似的界面下更不容易出錯。 加速開發(fā)（Accelerated development） 盡快地把一個系統(tǒng)投入市場有時候比它的總開發(fā)成本更重要。因為減少了開發(fā)和確認的時間，復用軟件能夠加速系統(tǒng)生產。,58,,構件模型的三個主要流派 OMG（Object Management Group，對象管理集團）的CORBA（Common Object Request Broker Architecture，通用對象請求代理結構） Sun的EJB（Enterprise Java Bean） Microsoft的DCOM（Distributed Component Object Model，分布式構件對象模型）。,59,,“九五”期間，青鳥工程研究軟件的工業(yè)化生產技術，開發(fā)軟件工業(yè)化生產系統(tǒng) ——青鳥軟件生產線系統(tǒng)，即基于構件—構架模式的軟件開發(fā)技術及系統(tǒng)，為軟件開發(fā)提供整體解決方案，推行軟件工業(yè)化生產模式，促進軟件產業(yè)規(guī)模的形成。,60,,61,,青鳥構件模型,62,,構件獲取 從現(xiàn)有構件中獲得符合要求的構件，直接使用或作適應性修改，得到可重用的構件； 通過遺留工程，將具有潛在重用價值的構件提取出來，得到可重用的構件； 從市場上購買現(xiàn)成的商業(yè)構件，即COTS（Commercial Off-The-Shell）構件； 開發(fā)新的符合要求的構件。,63,,64,構件管理,構件描述 構件分類與組織 人員及權限管理,65,,構件描述 構件模型是對構件本質的抽象描述，主要是為構件的制作與構件的重用提供依據(jù)； 從管理角度出發(fā)，也需要對構件進行描述，例如：實現(xiàn)方式、實現(xiàn)體、注釋、生產者、生產日期、大小、價格、版本和關聯(lián)構件等信息，它們與構件模型共同組成了對構件的完整描述。,66,,67,,構件分類與組織 關鍵字分類法 刻面分類法 超文本組織方法,68,,關鍵字分類法,69,,刻面分類法 使用環(huán)境 應用領域 功能 層次 表示方法,70,,71,,72,,超文本組織法,73,,,74,,人員及權限管理 一般來講，構件庫系統(tǒng)可包括五類用戶，即注冊用戶、公共用戶、構件提交者、一般系統(tǒng)管理員和超級系統(tǒng)管理員。,75,構件重用,檢索與提取構件 理解與評價構件 修改構件 構件組裝,76,檢索與提取構件,基于關鍵字的檢索 刻面檢索法 超文本檢索法 其他檢索方法,77,理解與評價構件,構件的功能與行為 相關的領域知識 可適應性約束條件與例外情形 可以預見的修改部分及修改方法,78,修改構件,理想的情形是對庫中的構件不作修改而直接用于新的軟件項目。 但是，在大多數(shù)情況下，必須對構件進行或多或少的修改，以適應新的需求。 為了減少構件修改的工作量，要求開發(fā)人員盡量使構件的功能、行為和接口設計更為抽象化、通用化和參數(shù)化。,79,構件組裝,◇ 基于功能的組裝技術 ◇ 基于數(shù)據(jù)的組裝技術 ◇ 面向對象的組裝技術,80,,基于功能的組裝技術 基于功能的組裝技術采用子程序調用和參數(shù)傳遞的方式將構件組裝起來。它要求庫中的構件以子程序/過程/函數(shù)的形式出現(xiàn)，并且接口說明必須清晰。當使用這種組裝技術進行軟件開發(fā)時，開發(fā)人員首先應對目標軟件系統(tǒng)進行功能分解，將系統(tǒng)分解為強內聚、松耦合的功能模塊。然后根據(jù)各模塊的功能需求提取構件，對它進行適應性修改后再掛接在上述功能分解框架中。,81,,基于數(shù)據(jù)的組裝技術 首先根據(jù)當前軟件問題的核心數(shù)據(jù)結構設計出一個框架，然后根據(jù)框架中各結點的需求提取構件并進行適應性修改，再將構件逐個分配至框架中的適當位置。此后，構件的組裝方式仍然是傳統(tǒng)的子程序調用與參數(shù)傳遞。這種組裝技術也要求庫中構件以子程序形式出現(xiàn)，但它所依賴的軟件設計方法不再是功能分解，而是面向數(shù)據(jù)的設計方法，例如Jackson系統(tǒng)開發(fā)方法。,82,,面向對象的組裝技術 · 構造法 在子類中引進基類的對象作為子類的成員變量，然后在子類中通過成員變量重用基類的屬性和方法。 · 子類法 將新子類直接說明為庫中基類的子類，通過繼承和修改基類的屬性與行為完成新子類的定義。,83,,84,,85,,86,