計算機程式設計/基於元件的軟體開發
軟體工程學士
軟體元件目前是軟體工程界最流行的流行語之一。本章概述了元件技術、其重用概念和特性。然後，我們將簡要概述軟體架構及其與基於元件開發的關係。最後，我們將以 JavaBeans 為例來檢查元件模型。
1968 年在加米施-帕滕基興舉行的北約會議上，首次提到了“軟體危機”。人們承認軟體開發很困難，甚至困難到必須將其視為一門獨立的工程學科。此外，人們還希望擺脫困境的途徑可能是形成新的軟體元件產業和元件市場。
軟體開發的狀態與 19 世紀初的許多行業相似：產品是手工製作的，昂貴且容易出錯。成熟行業的特徵是它製造的產品由許多小型標準化和可互換的部件組裝而成。
例如，電子工程，其中小型電子元件（如二極體、電阻器和電晶體）不是為單個應用而設計的，而是為眾多不同的應用而設計的。它們可以組合在電路板上形成更大的積體電路 (IC)。只要提供相同的功能，單個部件就可以簡單地替換為其他部件。ISO、ANSI 或 DIN 等標準保證了元件的相容性和互換性。
軟體開發試圖模仿這些重用機制。其思想是透過以“即插即用”的方式組裝一組獨立開發的現成元件 (COTS) 來開發軟體系統。
“軟體元件”的概念已經相當古老，但在最近一段時間發生了很大的變化。在程式設計的早期，軟體元件主要被視為原始碼模組，如 FORTRAN 庫，如今對元件有了更多要求。軟體元件究竟是什麼，沒有統一的定義。問題是，觀點在很大程度上取決於作者的背景，並且在過去幾年裡，關於元件的討論很多，以至於元件的概念變得有些模糊和模稜兩可。
然而，有一些通用屬性，人們通常將其與軟體元件相關聯。一個好的起點是在 ECOOP 96 會議上做出的定義
“軟體元件是具有契約指定的介面和僅顯式上下文依賴性的組合單元。軟體元件可以獨立部署，並且可以由第三方進行組合。” Clemens Szyperski，元件軟體，ACM 出版社/艾迪生-韋斯利，英國，(1998)。
接下來，我們將更詳細地描述定義中出現的不熟悉術語。
可能最重要的特徵是元件完全隱藏了它們的實現。Parnas 的資訊隱藏原則早在很久以前就強調了這一點的重要性
“每個模組都隱藏了一個重要的設計決策及其實現，隱藏在一個定義明確的介面後面，當設計決策或實現發生變化時，該介面不會發生變化”
元件就像黑盒子：程式設計師知道外部是什麼樣子，以及元件可以提供什麼，但他不知道元件內部是如何工作的。乍一看，這種完全封裝似乎是一種限制，但我們會看到它實際上是一種幫助。
應用程式構建器從中受益，因為他可以將元件替換為另一個元件，如果它支援相同的介面和功能。此外，他不需要了解內部工作原理，而只需要瞭解元件的介面。
另一方面，元件提供者可以更改元件的實現，只要介面仍然滿足即可。介面是 CBSD 中一個非常重要的術語。它被定義為“表示一項功能的命名方法集合”。介面充當元件提供者和元件使用者之間的一種契約。它不僅應該提到元件的服務，還應該提到其對環境的依賴關係。
原始碼的缺失帶來了一些需要解決的困難。首先，仍然必須能夠根據使用者的個性化需求調整元件。在不知道元件實現的情況下進行適配稱為定製化。此外，元件必須提供一種獲取其規範資訊的機制。這種自描述性是透過內省實現的。
元件可以輕鬆地傳輸到不同的應用程式上下文中。因此，元件需要是自包含的軟體元素，獨立於任何其他元件。這種獨立性非常嚴格，甚至禁止實現繼承，因為它使元件依賴於其超類，並且更改超類可能會破壞元件。介面繼承，這僅僅是特性規範的概括，是允許的。
為了使元件可互換，理想情況下，元件不得直接相互定址，而應透過間接機制。中央登錄檔儲存有關元件和介面的所有資訊。每次客戶端想要呼叫方法時，它都會查詢登錄檔以獲取所需的介面，該介面又會返回對實現元件的引用。
對元件提出的下一個需求是它們必須是可互操作的，這意味著它們必須能夠與用另一種程式語言編寫的或位於不同主機上的元件進行通訊。此外，它們本身也必須能夠轉移到其他作業系統和硬體平臺。這些需求透過虛擬機器、交叉編譯器和中介軟體來保證，例如來自 Sybase 的Avaki EII、來自 OMG 的 CORBA 以及來自 Microsoft 的 DCOM。
元件不是孤立使用的，而是根據軟體架構來使用，軟體架構決定了元件可以具有的介面以及如何組合元件。元件模型提供了一個元件互動的通用框架。元件模型是必須遵循的程式設計指南，以便能夠使用元件。在框架之外，元件是不可用的。兩個重要的元件模型是來自 Sun Microsystems 的 JavaBeans 和來自 Microsoft 的 ActiveX，後者基於元件物件模型 (COM)。CSBD 的關注和成功主要歸功於這兩個元件模型。但是，現有的元件模型都沒有實現對元件的所有期望功能。
如果有一天 CBSD 真的大規模建立起來，它將從根本上改變軟體的開發方式。透過基於元件的開發，元件的程式設計過程與將元件組合成應用程式的過程分離。希望元件可以像樂高積木一樣輕鬆地拼湊在一起，而無需編寫原始碼。因此，即使是技術技能較少的領域專家也可以組裝應用程式。
此外，預計 CBD 將對軟體開發的質量產生重大影響。
- 由於簡單性，軟體開發速度加快。無需從頭開始開發所有內容，因為可以購買第三方元件。開發時間縮短導致成本降低。
- 元件增強了軟體的可靠性，因為它們經過多年的改進、測試和除錯。除此之外，組合器還可以選擇和組合不同供應商的最佳元件。
- 軟體系統的可擴充套件性和可演化性得到改善，因為元件可以靈活地被滿足要求的另一個元件所替代。
幾年前，這種前景在軟體開發社群中引發了一種欣快感，因為人們期望元件能夠解決很多問題。現在，一些幻滅感開始蔓延。CBSD 變得非常困難，因為軟體由許多緊密耦合的互動實體組成，這些實體無法以簡單的方式連線在一起。
通常，元件和物件會被混淆或混在一起。基於元件的開發確實從面向物件方法借鑑了許多概念。基於元件的開發，正如今天所理解的那樣，建立在 OOP 的基礎上，但比面向物件方法提供了更抽象的軟體系統檢視。
主要區別在於元件是完全封裝的，正如我們剛剛看到的。元件嚴格禁止訪問其內部，而在 OOP 中，需要了解物件的內部工作原理，例如從類繼承時。OOP 中的這種重用機制也稱為白盒重用，因為原始碼對洞察和修改是開放的。
此外，構建塊的粒度也不同：元件存在於不同的規模，從庫中的單個物件到整個應用程式。但是，在大多數情況下，元件是更大的實體，包含多個物件。
OOP 的一個難點是互動協議的表示。在面向物件程式設計中，全域性控制流分佈在多個物件上。因此，對互動協議的修改會導致多個物件發生變化，這阻礙了系統的直接演化。另一個問題是，物件只能在具有相似互動模式的系統中重用。
元件技術允許將軟體系統的架構表示為可重用的實體。架構描述語言 (ADL) 以抽象角色之間的協作來描述軟體系統。角色是現有元件的一種佔位符。在組合時，角色透過單獨的聯結器填充元件。
好處是
- 元件包含較少的上下文依賴關係，因此更容易轉移到其他軟體系統。
- 互動協議可以重用。
- 軟體架構促進為系統建立精心設計的結構，而不是將元件拼湊在一起。良好的結構提高了軟體系統的可維護性，以便以後可以更輕鬆地進行更改。
JavaBeans 是主流的 Java 元件模型，由 Sun Microsystems 於 1996 年推出。它考慮了構成元件的大多數重要特徵。JavaBeans 定義如下：
"Java Bean 是一個可重用的軟體元件，可以在構建工具中以可視方式進行操作。"
Sun 除了元件模型之外，還發布了一個簡單的視覺化組合工具 BeanBox。它更適合於實驗 Bean，而不是提供專業的 IDE。對於實際應用，最好使用支援 JavaBeans 視覺化組合的 Java IDE 之一，例如 Visual Age 或 JBuilder。
正如我們所看到的，JavaBeans 與標準 Java 類並沒有太大區別。這使得 Bean 元件模型非常易於使用。但是 JavaBeans 可以具有一些大多數普通 Java 類不具備的功能。
- 永續性
- 屬性
- 內省
- 事件通訊
- 定製
要成為 Bean 的物件，需要定義一個公共的無參建構函式，以便構建工具能夠以簡單的方式例項化 Bean（在 Point Bean 中，無參建構函式是隱式給出的）。其次，需要實現java.io.Serializable或java.io.Externalizable介面之一。這些介面沒有規定任何方法的實現，但表示 Bean 可以儲存到持久儲存中，例如檔案或資料庫中。這樣做，可以在應用程式關閉或跨網路傳輸後恢復 Bean。在持久儲存中儲存元件狀態的能力稱為永續性。Java 提供了一種標準的序列化機制，這使得序列化物件變得非常容易。或者，可以透過實現Externalizable介面以自定義方式（例如 xml 格式）儲存元件。
Bean 的屬性是所有可以透過公共方法訪問和修改的欄位。這些 getter 和 setter 方法應該按照某種命名方案進行標記。
<PropertyName>(PropertyType).
另一方面，訪問器方法由模式程式設計。
public PropertyType get<PropertyName>()
這種命名約定的用意在於，它可以幫助構建工具瞭解 Bean 的工作原理及其功能。正如我們所看到的，元件必須提供有關其服務的資訊，這稱為內省。JavaBeans 提供了兩種內省機制：反射和BeanInfo類。BeanInfo 提供了有關 Bean 元件的複雜資訊，但必須顯式實現。
JavaBeans 透過事件相互互動。事件是元件可以向其他元件發出的通知，表示發生了某些有趣的事情。事件的一個示例可能是單擊按鈕或關閉視窗。Bean 可以是事件的源和目標。要收到事件通知，Bean 必須在另一個 Bean 上註冊為監聽器。
Java 事件模型實現了觀察者設計模式，從而減少了元件間的耦合。方法呼叫需要緊耦合，因為呼叫方和接收方需要在編譯時相互瞭解，而在事件中，所有通訊僅透過介面進行。
有一種特殊的事件叫做PropertyChangeEvents。它們用於限制某些屬性只能取特定的值，例如，對於月份，整數的值只能在 1 到 31 之間。每次修改這樣的繫結屬性時，都會向所有註冊的PropertyChangeListeners傳送通知。
定製是透過屬性編輯器完成的。屬性編輯器是用於在設計時定製特定屬性型別的工具。屬性編輯器從所謂的屬性表啟用，屬性表顯示 Bean 的所有屬性。如果選擇一個屬性進行定製，屬性表會找出該屬性的型別，並顯示相應的屬性編輯器及其當前值。
JavaBeans 元件模型的一大優勢在於它設計得非常簡單。開發 JavaBeans 非常簡單，因為許多行為（如平臺獨立性或打包機制）在 Java 程式語言中預設支援。但是，可以根據需要為 Bean 配備額外的物件，如BeanInfos 或自定義PropertyEditors，以便更靈活地使用元件模型。第二個特性是 Sun 根據 JavaBeans 元件模型設計了整個 Swing GUI 庫。因此，Swing 元件可以輕鬆地在視覺化構建工具中組合。
然而，JavaBeans 並沒有實現元件模型的所有功能。一個缺點是 JavaBeans 受限於 Java 程式語言，而元件的一個重要目標是實現語言的獨立性。