概念: 提升抽象層次
本原則說明如何藉由提升抽象層次以減低複雜性。
主要說明

簡介

複雜性是軟體開發的中心問題。提升抽象層次有助於減低複雜性,連帶減少專案所需的文件量。欲提升抽象層次,應重複使用、使用高階建模工具,並及早使架構穩定。

          
好處
  • 生產力
  • 複雜性降低
型樣
  1. 重複使用現有資產
  2. 使用較高階工具及語言,減少文件製作量
  3. 首重架構
  4. 架構講求、彈性、品質、易於瞭解及複雜性控制
反型樣
  • 直接從含糊不清的高階需求著手,編寫自訂細部程式碼:
    • 因較少運用抽象概念,大量依靠程式碼進行討論而未先就概念溝通,錯失許多重複使用等有利機會。
    • 未確切掌握需求及其他資訊,導致必須一再重複進行討論並重審規格
    • 較少論及架構,導致在專案後期必須大幅重做

討論 

複雜性是我們在軟體開發上所面臨的一大問題。我們知道降低複雜性對於生產力有重大影響。提升開發過程中的抽象層次,能減低複雜性並促進溝通。

重複使用現有資產是減低複雜性的有效方法,例如有可重複使用的元件、舊式系統、現有商業流程、型樣或開放源碼軟體。以下舉出 過去十年間掀起軟體產業重大變革的兩大重複使用案例:

  • 重複使用中介軟體,例如資料庫、Web 伺服器及入口網站;以及最近的
  • 開放原始碼軟體,提供許多大大小小可靈活運用的元件

連帶的,Web 服務對於重複使用也有潛在重要影響力,因為這類服務提供簡單的方式在不同的平台間重複使用許多主要功能,且將放寬消費者與服務提供者之間的耦合性。換句話說,我們得以更彈性活用各種服務組合,滿足商業需求。 RAS、UDDI、SOAP、WSDL、XML 及 UML 等開放標準,亦降低了重複使用的門檻。

圖解說明透過服務導向架構重複使用現有資產
透過服務導向架構,重複使用現有資產。
重複使用的主要問題在於,兩種重複使用的元件在開發期間便需要知道有對方存在。 而服務導向架構即可利用所謂的放寬耦合性來減輕這項問題,讓服務的消費者動態尋獲服務提供者。如此即可將現有元件或舊式系統封套於服務中,讓其他元件或應用程式透過標準化介面、相互獨立的平台及實作技術,動態取得其所需的功能

另一個方法是運用較高階的工具、架構及語言來降低複雜性並提升通訊一致性:

  • 標準語言中的統一建模語言 (UML) 及速成應用程式語言如 EGL 等,能夠將高階構想具象化 ,可運用在商業流程及服務元件等,一方面促進高階建構的合作,同時省去不必要的細節。
  • 設計與建構工具可自動促使高階構想轉換成作業程式碼:
    • 工具中提供各種精靈,用來產生程式碼並套用程式片段,藉此進行自動化設計、建構及測試;
    • 工具能夠透過整合化環境、建置及測試環境,將整合及測試工作轉換成縝密的開發作業。
  • 組合式管理工具能夠以整體單獨個體的方式,管理多項專案的財務及其他資產。

概括而言,高階工具能夠以強效且動人的圖形化方式,掌握並摘要呈現關鍵建模資訊。有關視覺化建模的好處,在輔助資料:視覺化建模中有更詳盡的探討。

管理複雜性的第三種方法是以架構為重,無論是定義事業或者開發系統或應用程式皆同。在軟體開發上,應在專案早期力求完成架構的設計、實作及測試。亦即在專案之初,應將重點鎖定在下列目標:

  • 定義高階建置區塊,乃至於首要元件及其任務與介面。
  • 設計與實作架構機制,亦即使用現成解決方案對付一般問題,例如對於持續性的因應之道或記憶體回收等。

若能及早敲定架構,即可催生系統的綱要以掌握全局,以便於日後投入專案的人力、元件、功能及程式碼擴增時,仍能輕鬆管理系統複雜性。此外並 界定可資運用的可重複使用資產,以及系統中需要自訂建置的環節。