《再利用的设计》PPT课件.ppt

再利用的設計,以可再利用的元件建構軟體,本章目的,瞭解軟體元件再利用的好處以及可能產生的問題。 瞭解可再利用的不同類型元件與再利用的設計程序。 瞭解應用程式系列產品是軟體再利用最有效的應用。 瞭解模式(pattern)如何成為高階的抽象表示，並且在物件導向開發中提升設計的再利用。,本章內容,元件開發 應用程式系列產品 設計模式,軟體再利用,在大部分的工程領域中，系統的設計都是由一些已經在其他系統使用過的元件組合而成。 軟體工程在過去大都著重於原始的開發方式，現在卻致力於建構出更好、速度更快、價格更便宜的軟體，所以必須採用以系統化再利用(systematic reuse)為主的設計程序。,以重複利用為主的軟體工程,應用系統的再利用 整個應用程式系統可能都可以再利用，不用做任何改變就可以納入其他系統(如COTS產品的再利用)，或是開發應用程式系列產品時的再利用。 元件再利用 應用程式的元件從子系統到單一的物件都可以拿來再利用。 功能再利用 被製作成單一功能的軟體元件也可以拿來再利用。,再利用的實踐,應用系統的再利用 被廣泛運用的軟體系統通常會被實作成應用程式的系列產品(application families)，例如COTS產品的再利用就越來越普遍。 元件再利用 以元件為主的軟體工程被視為是有效而普遍的再利用方式，但這種方式的發展卻還不夠成熟。 功能再利用 常見於一些應用領域(例如，工程領域)，這些領域都已經建立了可再利用功能的專門領域知識庫。,再利用的好處,增加可靠性 元件可以直接運用在實際運作的系統 降低處理風險 降低開發成本的不確定因素 有效的利用專家 重複利用元件而不是專家 符合標準 可再利用的元件以內含標準 加速開發 避開原始的開發方式，加速產品的問市,以再利用方式進行軟體設計的需求,必須找到適當的可再利用元件。 必須讓使用可再利用元件的使用者有信心，讓這些元件依指定的方式執行並且具可靠性。 所有元件都必須有相關的文件說明，以幫助使用者了解這些文件的用法並且做適當的修改。,軟體再利用的相關問題,增加維護成本 缺乏支援工具 非自創症候群(Not-invented-here syndrome) 元件庫的維護 找尋與改寫可再利用元件,以產生器為主的再利用,程式產生器包含標準模式和演算法的再利用 這些都內含在產生器，然後以使用者指令做參數設定，程式因此可以自動產生。 以產生器為主的再利用只有在該領域的抽象化和對應的可執行碼被識別出來時才有可能。 使用特定領域的語言可以構成及控制這些抽象化。,程式產生器的類型,程式產生器的類型 商業資料處理系統的應用程式產生器 語言處理系統的剖析器產生器 CASE工具集的程式碼產生器 以產生器為主的再利用是非常符合成本效益的，但是它的適用性卻僅限於幾個應用領域。 與其他元件式再利用的方式比較，終端使用者可以很容易的使用產生器來開發程式。,以產生器為主的再利用,元件式開發,元件式軟體開發工程(CBSE)是一種仰賴再利用的軟體系統開發方式。 它的產生是由於物件導向開發方式未如預期的對軟體再利用有很好的效果。物件導向中的每一個物件類別都太過詳細且特定。 元件則比物件類別更為抽象，而且它可以被視為獨立的服務提供者。,元件(Components),元件可以提供服務，不管該元件是在何處執行或是使用哪一種程式語言開發 元件是一個獨立的可執行實體，它可以由一個或多個可執行的物件所組成。 元件會對外開放他們的介面，而且所有的互動都是透過公開的介面來進行。 元件可以是小至簡單的函數大至整個應用程式系統,元件介面(interface),元件介面,提供介面(Provides interface) 定義元件提供給其他元件的服務 需求介面(Requires interface) 指定使用此元件的系統應該提供的服務,列印服務元件,元件抽象化,功能性抽象(Functional abstraction) 元件只實作一個單一功能，例如一個數學函數。 隨意編組(Casual groupings) 元件是由一群關係鬆散的實體所組成， 這些實體可能是資料宣告或函式等。 資料抽象(Data abstraction) 元件代表物件導向程式語言中的一個資料抽象化或是類別。 叢集抽象(Cluster abstraction) 元件代表一起運作的相關類別所成的群組。 系統抽象(System abstraction) 元件是一個完全自給自足的系統。,CBSE的程序,元件式開發可以藉由將一個再利用活動加入到程序中的方式與標準的軟體系統程序做整合。 不過以可再利用的方式進行開發時，系統需求必須針對元件做修改，才能讓元件使用。 元件式軟體開發工程(CBSE)的程序通常包含一個雛形化或增量式的開發程序，而程式庫中被引用的元件通常會使用 scripting 語言來撰寫。,整合元件式開發的系統開發程序,再利用式開發,CBSE程序的相關問題,元件不相容可能造成成本及時間不如預期的節省 找尋與瞭解元件 需求改變時的維護與演化的管理，尤其是當系統元件無法更改時,應用程式框架,框架(Framework)是由一群抽象和具體的類別以及這兩者之間的介面所組成的子系統設計。 子系統的實作是在部分的設計中加入元件以及對框架中某些抽象類別進行實體化。 框架是可再利用的大型實體。,框架的類別,系統基礎結構框架 支援系統基礎結構的開發，例如通訊、使用者介面和編譯器等。 中介軟體整合框架 支援元件溝通和訊息交換的標準和相關類別。 企業級應用程式框架 支援特定應用領域的開發，例如電信或財務金融系統。,框架的擴充,框架是一個通用的結構，可以進行擴充，以建立更特定的應用程式或子系統。 擴充框架時包含 加入具體類別，這些類別必須繼承自框架中某些抽象類別的操作。 加入回呼方法，以這些方法來回應可被框架辨識出來的事件。 框架的問題是它們的複雜性以及要有效的使用它們所花的時間。,模型-檢視-控制者(MVC),GUI 設計的系統基礎結構框架。 可讓某個物件有多種呈現方式，並且將這些呈現方式與互動分開。 模型-檢視-控制者(MVC)框架利用各種不同模式建立實例(instantiation)，稍後將進一步討論。,模型-檢視-控制者,COTS產品的再利用,COTS是指Commercial Off-The-Shelf系統。 COTS系統通常是能夠提供應用程式介面(API)的完整應用程式系統。 利用整合COTS系統的方式來建立大型系統已成為一個可行的開發策略，尤其是對如電子商務之類的系統。,COTS系統整合的問題,缺乏對功能與效能的控制 COTS系統的效率不見得好 COTS互通性的問題 不同的COTS系統可能有不同的假設，整合困難 系統的演進無法控制 系統的演進是由COTS的開發商來控制，而不是系統使用者 COTS開發商的支援 COTS開發商可能不會在產品使用期間提供支援,再利用式的元件開發,可再利用的元件可以從現存的通用元件特別建構而成 元件的可再利用性(reusability) 應該要反映穩定的領域抽象化 應該要隱藏狀態表示方式 應該盡可能獨立 應該透過元件介面對外提出例外狀況 可再利用性與可使用性(usability)必須權衡 介面愈一般化，可再利用性愈大，但是可能會愈複雜而讓可使用性愈低。,可再利用的元件,可再利用元件的開發成本比特定等價物的開發成本還高。可再利用性額外增加的成本應當視為組織的成本而非專案成本。 與特定的等價物做比較，通用元件可能在空間上較無效率，執行時間也可能比較長。,提高可再利用性,名稱普遍化(Name generalisation) 元件中的名稱可以做修改，以避免直接反映某個特定的應用程式實例。 操作普遍化(Operation generalisation) 可以增加操作，提供額外的功能，也可以移除某些應用程式的特定操作。 例外普遍化(Exception generalisation) 可以移除應用程式特定的例外，加入例外管理功能以增加元件的強固性。 元件的認證(Component certification) 元件必須經過認證才可再利用。,提高可再利用性的程序,應用程式系列產品,應用程式系列產品(application family)或產品線(product line)是相關的一組應用程式，它們具有共通的特定領域架構。 每當需要新的應用程式時，應用程式系列產品的共通核心就會被再利用。 每個特定的應用程式在某些方面都有特別之處。,應用程式系列產品的特殊版本,特殊的執行平台 針對不同執行平台開發不同版本的應用程式 特殊的組態 針對不同的週邊設備製造不同版本的應用程式 特殊的功能 針對客戶的不同需求建立不同版本的應用程式,資源管理系統,存貨管理系統,資源資料庫 維護受管理項目的細節 輸入/輸出的內容描述 描述資源資料庫的結構以及所使用的輸出入格式 查詢層級 提供查詢資源的功能 存取介面 使用者介面以及應用程式介面,應用程式系列產品的架構,應用程式系列產品的架構必須以分開的不同子系統來建立，並且允許這些子系統被修改。 應用程式系列產品的架構也必須能夠將實體和它們的描述分離開，以便從系統中較高層級透過這些描述來存取這些實體，而不是直接存取。,圖書館系統,圖書館系統,此系統中受管理的資源是圖書館裡的書。 此應用程式還必須增加其他特定領域的功能(例如流通、借書等)。,系列產品成員的開發,系列產品成員的開發,找出利害關係人(stakeholder)的需求 利用現有的系列產品成員當做一個雛形 選擇最適合的系列產品 找出最符合需求的系列產品成員 重新協調需求 協調需求是軟體所必須具備的能力 調整現有系統 開發新的模組並且修改系列產品成員的模組 產生新的系列產品成員 把重要的功能寫成說明文件以做為其他系統的開發依據,設計模式,設計模式(design pattern)是重複利用抽象知識的方法，這些抽象知識用來表示某個問題和其解決方法。 設計模式可做為問題和其重要解決方法的描述。 設計模式必須夠抽象，以便在不同設定中可被再利用。 設計模式經常依賴繼承(inheritance)和多型(polymorphism)之類的物件特性。,模式的要素,名稱 一個代表模式的有意義名稱 問題的描述 解決方法的描述 不是具體的設計描述，而是某個解決方法的樣板，可以用各種不同方法建立實例。 結果 套用這個模式的結果和利害得失。,多重顯示,Observer模式,名稱 Observer 說明 將物件狀態的表示方式和物件本身分開 問題描述 在需要以多個顯示格式來顯示狀態時可以應用這個模式 解決方法描述 請參考說明UML的投影片 結果 無法以最佳化的方式加強顯示的效能。,Observer 模式,以再利用進行設計包含設計良好設