前言

雖然，物件導向程式設計(Object-oriented programming, OOP)已是老生常談，網路上有太多的資源可參考，不過，因為實在太重要了，筆者還是不免俗的再加一，不同的是我們會先談物件導向系統分析(OOA)與物件導向系統設計(OOD)，讓入門者能一窺全貌，瞭解分析/設計/程式撰寫的銜接流程與內容。

OOA是一種資料導向(Data driven)的分析方法，首先從需求中找出實體(Entity)，再定義其屬性及方法(Method)，並描繪出類別之間的關聯，進而串連成業務流程，接著進行系統設計(OOD)，訂定系統架構及程式規格，最後以OOP實作，以類別(Class)定義實體，完成系統開發，大多數的程式語言都支援OOP及相關設計典範，Python也不例外，本文會先討論OOA、OOD。

物件導向系統分析(OOA)

傳統的軟體開發生命週期(Software Development Life Cycle, SDLC)如圖一，是所謂的瀑布型模型(Waterfall Model)，分階段依序進行，從規畫、系統分析、系統設計、程式設計、單元測試、整合測試至系統測試，其中單元測試依據系統設計規格書進行功能驗證，系統整合測試(System Integration Testing, SIT)依據系統分析規格書進行流程驗證，針對單一流程進行測試，例如採購、入庫或銷售流程，最後使用者驗收測試(User Acceptance Testing, UAT)依據規畫書進行整體需求驗證。

圖一. 瀑布型模型(Waterfall Model)

瀑布型模型是一般政府機構及大型專案階段驗收的標準，想順利領錢就要按階段完成各項工作，優點是循序漸進，檢核點非常明確，缺點是專案期程會拉的很長，少則一年，多則3~5年，而且風險很高，往往在專案末期，才發現甲乙雙方有巨大的認知差距，屆時專案要轉向已經來不及了，為補救這些缺點，就有所謂的並行處理(Parallel)、迭代式(iterative)及敏捷式開發流程(Scrum)等方法論出現，不過，瀑布型模型定義的各項階段工作仍需進行，只是執行的先後順序有所調整而已。

圖二. 部份工作可並行處理(Parallel)， Object-Oriented Analysis by Edward Nash Yourdon

圖三. 迭代式(iterative)開發流程, Rational Unified Process(RUP) by Rational Software

圖四. Scrum framework，圖片來源：【Essential elements of Agile Scrum】

一般系統分析的方法論分為兩種方式(approach)發展：

1. 流程為主：以作業流程(Process flow)為出發點，再逐步定義輸出入資料流(Data flow)、資料儲存(Data store)、資料字典(Data dictionary)及流程規格(Process specification)，主要的方法論為【結構化分析與設計】(Structured Analysis and System Specification)，俗稱DFD。

2. 資料為主：以資料導向為出發點，先找出實體(Entity)，定義實體的屬性(Property or Attributes)、職責(Responsibility)、方法(Method)或事件(Event)，並描繪出類別之間的關聯，進而串連成業務流程，Rational Unified Process(RUP)、Model Driven Architecture(MDA)...等。

由於OOP的興起，資料為主的方法論產出的規格書可以直接轉換為程式，逐漸成為主流，而流程為主的方法論雖然用力調整，向資料為主的方法論靠攏，但最後還是逐漸式微，筆者個人覺得非常可惜，後者還是保有許多優點，例如DFD分層、有明確的工作流程。

圖五. 分層的DFD(Leveled DFD)

結構化分析與設計有非常明確的工作流程，首先建構資料流程圖(DFD)，描述作業流程，再詳細定義DFD中的資料流(data flow)、資料字典(data dictionary)及流程規格(Process spec. or mini spec.)，最後交由程式設計師開發系統。此方法論最經典的書籍為【Structured Analysis and System Specification】，目前筆者還保有一本，當初以200元購入，現在已增值到5000元，賺翻了，可惜有行無市🤩。

圖六. Structured Analysis and System Specification by Tom DeMarco 1979年出版

圖七. Structured Analysis and System Specification 書中手繪的DFD，彌足珍貴

而資料導向的方法論則以Rational Unified Process(RUP)為代表，使用UML圖形工具，分為結構圖(Structure diagrams)及行為圖(Behavior diagrams)兩類，共有10多種圖形，並非每一種都要繪製，可視需要選用，缺點就是選擇性太多，沒有明確的工作流程，檢核點都在後期，因為，工作都採並行/迭代處理，到後期才會看到全貌，因此，可以從網路上搜尋，每份報告書差異較大，良莠不齊，一致性明顯不如以流程為主的方法論。

圖八. UML圖形工具

圖九. UML圖形範例

UML圖形工具的用法可參閱【Unified Modeling Language (UML) Diagrams by geeksforgeeks】及下方的超連結頁面。

實施步驟

筆者通常會綜合流程為主與資料導向的方法論優點，以下列方式進行：

1. 從需求訪談中找出實體(Entity)。
2. 將實體轉換為角色(Role)，例如會計室張小姐的角色為會計人員，並針對角色定義她的屬性，例如職級、薪資、所屬部門...，以及職責(Responsibility)，例如製作傳票、登帳、結帳...。
3. 以類別(Class)定義實體，並描繪出類別之間的關聯，通常會使用類別圖(Class diagram)、物件圖(Object diagram)或元件圖(Component diagram)。
4. 描述作業流程：通常會採用案例圖(Use case diagram)、順序圖(Sequence diagram)、活動圖(Activity diagram)，不過，筆者偏好使用資料流程圖(DFD)，因為它可以分層，而且搭配資料流(data flow)、資料字典(data dictionary)及流程規格(Process spec. or mini spec.)，超好用。

個案研究

以一篇訪談【新竹物流下一步要邁向智慧物流】為例，說明如何從需求訪談中找出實體(Entity)。從原文中抽出一段：

圖十. 從需求訪談中找出實體

先從需求訪談中找出實體，以黃色標示重點，通常是名詞，不過有些動詞也要注意，因為他們可能是系統必要的功能，分析結果如下：

1. 實體：貨件、司機、貨車、摩托車、轉運中心、站點、條碼、自動化小物分類系統、材積自動化辨識系統、電子資料交換（EDI）、外包廠商。
2. 職責(Responsibility)：司機要負責運費計算、外包廠商要負責理貨，材積自動化辨識系統要負責測量貨物大小...等。
3. 屬性或繼承：載具可分為貨車及摩托車，可以使用屬性區分，也可以使用繼承，例如貨車及摩托車均繼承載具。
4. 實體關聯：貨件、司機、載具、轉運中心、站點、條碼及各個系統之間的關聯，可使用類別圖(Class diagram)或元件圖(Component diagram)表示，並以案例圖(Use case diagram)列舉各項作業或職責(Responsibility)，或以順序圖(Sequence diagram)說明與時序相關的工作順序。
5. 從上述訪談中可以衍生一種設計思維，分析時可以將實際現狀(Physical current status)描繪出來，再將實體轉化為角色(Role)，即邏輯現狀(Logical current status)，接著著手改善流程或引進新科技，例如上文的【材積自動化辨識系統】，擘劃出未來的流程(Logical future status)，最後轉化為實際的設計(Physical future status)，總結如下圖。
   
   圖十一. 設計思維

物件導向系統設計(OOD)

設計階段主要是落實及強化系統分析結果，填補細節，包括類別的屬性詳細定義，含資料型別/長度/發生頻率，以及作業流程/程式規格...等，另外，架構師(Architect)也要擬定系統架構，選擇開發框架、套件、快取、AOP/Function programming、Queue、權限控管、公用函數庫、資料庫設計...等。

系統分析主要聚焦在【要做甚麼】(What to do)，框住專案範圍，系統設計則聚焦在【要如何做】(How to do)，明確告訴程式設計師依據規格撰寫程式碼，規格書也需包括完整的處理流程，提供上下文參考。

物件導向程式設計(OOP)

有了明確的設計規格，程式設計師就可以放膽開始撰寫程式了，應用前幾篇所討論的設計機制以及OOP的繼承(Inheritance)、封裝(Encapsulation)、多型(Polymorphism)等特性，寫出正確、安全、高效能、具彈性的程式碼。

結語

大部份的公司都會有一套自訂的OOA/OOD/OOP標準及文件格式，作為專案團隊開發指引，當然也包括專案管理指引，這是軟體公司最重要的無形資產，我們可多方觀摩各家優缺點，擇優採用。本篇是筆者多年開發經驗的分享，並未完全依照學理講述，如有錯誤或疏漏，還請不吝指正。

後續我們會以Python進行OOP實戰，包括類別實作、遊戲製作、資料庫操作...等，下回再見分曉了。