概念: 開發元件解決方案
元件式開發是從一般應用程式開發延伸的一個派別。在本準則中,「元件」一詞代表可獨立開發和部署的元件。
主要說明
生命週期的活動:
  1. 簡介
  2. 初始階段的活動
  3. 詳述階段的活動
  4. 建構階段的活動
  5. 轉換階段的活動
其他主題:

簡介

元件式開發是從一般應用程式開發延伸的一個派別,其中:

  • 應用程式由各別的可執行元件組成,這些元件彼此獨立開發和部署,可能由不同的團隊負責。
  • 應用程式可以採取較小的幅度升級,僅升級應用程式的部份構成元件。
  • 應用程式可以共用元件,提高重複使用的機會,但也會產生專案間的相依關係
  • 分散式不一定就是元件式,但元件式應用程式通常是分散式

在本頁,這些可獨立開發和部署的元件通稱為「元件」。但在 RUP 的其他地方,我們根據概念:元件中的定義採用更廣義的「元件」,並視情況適當地修飾意義。

以下討論 Rational Unified Process (RUP) 在處理元件式開發議題上所做的調整。

初始階段的活動

適用初始階段的基本工作流程,加入下列延伸或變化:

專案管理

  • 活動:評估專案範圍與風險
  • 導入元件方法會改變某些風險的本質及引發新的風險。具體而言:

    • 來自外部的元件會提高風險,因為專案小組無法直接掌控引進的重要元素
    • 來自外部的元件可縮短開發時間,降低資源風險
    • 如果來自外部的元件本身產生結構性限制,可能會破壞系統的架構
  • 活動:規劃專案
  • 作業:規劃階段與反覆週期中,「建構階段」的規劃可能指出專案分割成兩條不同的平行途徑:分別在這兩條途徑上開發特定應用程式和特定領域的元件(安排在架構的上層 - 請參閱概念:分層),以及非應用程式和非特定領域的元件(安排在下層)。在某些情況下,可重複使用的元件由獨立管理的開發團隊來開發。引進平行途徑的決策通常是一項人員配置和資源的議題,起因於希望將可重複使用的元件資產與應用程式(元件在其中部署)分開來管理。

需求

  • 活動:修正系統定義
  • 在修正系統的需求時,必須掌握選取的元件架構所加諸的限制。元件架構提高開發生產力的原因,一部份是因為限制軟體架構師和設計師的自由度。作業:詳述軟體需求的重點就在於詳實記載這些限制。

測試

環境

  • 活動:準備專案的環境
  • 收集與準備專案所需的準則時,如需詳細資訊,請參閱  作業:準備專案的準則,考量特定的元件架構,及準則對其所設的限制。準則應該包含如何以架構來設計和撰寫程式碼。對於元件架構本身與元件之間定義的介面,也應該提供測試指引,教導如何驗證 兩者的相符度。

詳述階段的活動

適用詳述階段的基本工作流程,加入下列延伸或變化:

需求

  • 活動:修正系統定義
  • 作業:詳述軟體需求較強調技術面和非功能面的需求,以及對於建置或採購的元件上所加諸的限制。必須考量的非功能面需求包括大小、效能、記憶體或磁碟追蹤、執行時期版權問題,以及會影響選擇或建構元件的類似限制。

分析與設計

  • 活動:設計元件
  • 作業:子系統設計進一步修正元件設計,並指出元件內部提供元件實際行為的類別。在「詳述階段」的早期可能只有一個類別,可稱為一種「子系統/元件 Proxy」,扮演 Stub 來模擬元件行為,目的是打造架構的原型。在後期,此類別的行為會分配給子系統內的一群彼此合作的類別。作業:類別設計中會修正這些內含的類別。

  • 活動:設計資料庫
  • 詳述的重點是確保持續性策略可靈活調整,且資料庫設計和持續性機制可支援系統的產能需求。持續性類別將確認並對映至持續性機制。資料密集使用案例將經過分析,以確定可彈性調整機制。透過與測試活動的結合,評鑑並驗證持續性機制及資料庫設計。

實作

測試

  • 活動:定義評估任務驗證測試方法測試及評估達到任務接受率改善測試資產

    「詳述」階段的測試活動主要是驗證架構。在元件式系統中,這項重點變成:

    • 推演元件之間的介面,以確保元件界限適當
    • 更強調效能測試,尤其是效能彈性測試,以確保可以支撐預期的交易量

    元件架構原有的任何假設也需要一併評估。通常包括持續性與交易管理機制的延展性和產量,其中,機制設計者所作的隱含假設,如果無法為應用程式架構所理解,則經常會實際地侵蝕應用程式架構。

專案管理

  • 活動:規劃下一個反覆週期

    將實作子系統視為「責任的邏輯單元」時,建構工作可以分割為一或多個平行的「途徑」:一個注重於特定應用程式功能,其他注重於一般、可重複使用的元件。當然,這取決於是否有足夠的資源可分配並列開發的投入成本。能否平行地分割開發團隊和工作,完全取決於架構的穩定性,更具體地說,也就是元件之間介面的品質和穩定性。「詳述階段」做的愈好,將愈可能實現這樣的劃分。

建構階段的活動

適用建構階段的基本工作流程,加入下列延伸或變化:

專案管理

  • 活動:規劃下一個反覆週期

    稍早在詳述階段接近尾聲時已說明如何規劃第一個建構反覆週期。後續的反覆週期規劃及平行地劃分開發團隊和工作的能力,仍然取決於架構的穩定性及元件之間介面的品質與穩定性。

分析與設計

  • 活動:修正架構活動:設計元件

    建構的重點是分析剩餘的使用案例,以及找出適當的元件及實現使用案例的元件合作關聯。擴充和完成現有的架構,並完整設計和實作元件的「內部行為」。

  • 活動:設計資料庫

    建構的重點是完成資料庫設計,確定資料庫與持續性機制支援所有持續性類別。這項工作與活動:修正架構活動:設計元件中的工作會齊頭並進和反覆地執行。理想的組織中應該要有整合的元件團隊,團隊之間在持續性議題上彼此協調,以確保獲得最佳的資料庫設計。

實作

測試

效能測試依然重要,但開始逐漸強調功能測試。必須著重在功能的完整性、現有功能的迴歸測試及效能期望的達成性。

轉換階段的活動

  • 產品發行在 Web 環境下有漸進和持續的傾向,而較不重視傳統的媒體交付。必須視情況適度地調整發行規劃。
  • 正式作業支援逐漸成為本階段的重心。
  • 執行資料轉換活動