淺論系統內部的結構分析與設計

什麼是系統內部的結構(Structure)?

  • 系統內部(內涵),由某些單元或元素所組合而成為一個整體(Whole)。
  • 系統被視為一個整體時,即具備了系統功能(System Functions),可以提供服務(Services),以應付外部的需求。
  • 系統作為一個整體時,其應付外部需求變動的彈性(Flexibility) 取決於內部的結構分析(Analysis)與設計(Design)程度。
  • 莫僅從表面看事務,即便連藝術家如達文西,在描繪人像時,會去研究及實驗人體解剖,以觀察及瞭解人體結構的奧妙。

什麼是系統的結構分析與設計?

  • 找出與描述系統組成結構的元素 – 分析(Analysis);尋求一個解決方案(Solution),利用結構內部的元素,動態組合以滿足外部的功能需求 – 設計(Design)。
  • “Do the right thing (分析)”and “Do the thing right (設計)”。

系統結構分析與設計的手法

  • 以組成元素來區分

    • Non Object-based
      • Procedure-based and Data-Oriented
      • Form + Script (Function) + Data-model
    • Object-Oriented
      • Functional Object – 源自於需求(Requirements)
      • Entity(Essential) Object – 源自於領域概念(Domain Concepts)
  • 以系統分析的思維來區分
    • Functional-based Decomposition
    • Essential Object-based Decomposition

Non Object-based Structure
圖1、Non Object-based Structure

Object-Oriented Structure
圖2、Object-Oriented Structure

Functional-Object Decomposition
圖3、Functional-Object Decomposition

Essential Object Decomposition
圖4、Essential Object Decomposition

Functional vs. Essential Object 的幾點思考

  • 即使採用 .NET 或 J2EE 等 OOP 語言,但以功能分解的分析設計思維仍佔大部分的比例。
    • 系統內部的結構係以功能物件(Functional Object)所組成。
      係以收集使用者需求所建構而成的系統 – Use Case First。
    • 直覺、開發快速且容易。
    • 系統整體的“應變能力”較差,彈性度不佳。
  • 物件導向的核心典範 – 分解的單位源自於問題領域的概念(Concept),而非以功能來分解。
    • 問題領域的概念,為該領域所常用的字彙或術語,例如,訂購、客戶、產品等術語,係屬於該領域本質性(Essential)的穩定。
    • 讓系統具備高度彈性的設計思維 – Mapping from the real-world domain concepts to the software objects.
    • 以領域物件為單位,具備了快速組裝的能力,可以應付頻繁的需求變動。需求的變更成為驗證系統的彈性度及正確性 – Use Case Driven。
    • 系統分析與設計不易。如何找出領域物件,建構領域物件的概念模型,並轉為軟體系統的規格(Specification)模型,以及如何分派領域物件的責任,是非常大的挑戰。
  • 功能物件 vs. 領域物件–並非對立,而是互補

功能物件與領域物件的互補合作
圖5、功能物件與領域物件的互補合作

文章導覽

   

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *