什麼是系統內部的結構(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

圖1、Non Object-based Structure

圖2、Object-Oriented Structure

圖3、Functional-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、功能物件與領域物件的互補合作