＊＊ 本文同步發表於 FB 社團－軟體設計鮮思維 ＊＊
月初在內湖某大電視購物/網購平台總部的資訊單位授課。喔，先誇讚下，約有50來位的學員，上課過程大都蠻踴於提問且活潑，可說上得挺順暢愉快。
其中在談及使用案例模型 (use case model)的需求架構分析時，關於外部系統的定義，個人特別強調會是透過介面 (interface)的整合，如透過 web service or message service 等)，而不會是透過資料庫的整合方式。
然後其中有位學員就問了，如果連結外部系統是透過 FTP，也就是開發中的系統這邊為 FTP Client，然後以批次定時處理的方式，傳送到外部單位的 FTP Server，對方也是採用批次自動處理的作法，把接收下來的檔案作解析處理。
這樣 FTP Server 是否是開發中系統的外部參與者 (actor)？我倒是沒想到現在會有這樣的作法，最初的直覺當然不會是。
不過課程休息時，再仔細想想，回歸到所謂外部系統整合的定義，是否有透過介面來連結？ 事實上，FTP 的 Client/Server 是有的 (當然就是透過 FTP 協定)，且兩邊系統之間並未透過手動操作，而確實是系統對外部系統之間有達成自動化的整合 (雖然是透過批次處理的方式)。
為何會有這麼「low」的作法？其實這與實作技術沒有太大關係，而是因為當要與外部單位的系統作整合時，外部單位總會有「安全性」的考量，不一定願意釋放出可讓系統直接呼叫的介面。
不過我在作需求架構的分析利用使用案例模型表達時，還是不會把 FTP Server 視為是外部參與者。參考下圖1，開發中系統為「電子商務系統」，那麼與之連結的「外部系統」應該要是同一個「層級」。
也就是當我們開發的系統是某一業務領域 (business domain)，那麼外部系統也應該是對等於同一業務層級。所以，「電子商務系統」與「物流管理系統」才是同一個層級，但 FTP Server 卻不是，它應該被視為是「物流管理系統」底層的元件 (component)。
圖1、網購平台使用案例模型
但是當從需求分析轉移到實作階段時，因為必然會談及到實作的議題，包括連結的協定與資料格式等。所以呼叫的標的系統此時就應以實際所連結的標的來稱之，如 FTP Server。
參考下圖2，PlaceOrderControl 是 Domain Controller 類型，它接收了「處理訂購」的要求。實作人員設計了 DAO (Data Access Object)物件，它負責把訂購交易的資訊儲存到資料庫 (如 Oracle)；Adapter 物件則是負責把物流資訊，可能整理成 XML 格式，然後再寫入至指定的檔案位置，並透過 FTP 協定傳送檔案至遠端的 FTP Server 上。
圖2、PlaceOrder 實作循序圖 (sequence diagram)
上圖2 循序圖是會透過實作的手法來調整設計的。很可能 Adapter 物件並沒有透過 FTP 協定傳送至 Ftp Server，而是僅僅只寫入至 Local 端的檔案系統；而 FTP 傳遞則是在另外一個時間點，藉由另行撰寫如「SendFiles script」來批次傳送資料。若是這樣的情境，那應該是會被視為另一個個案的分析了。 (啟動的參與者為 Scheduler 系統，Use Case 為「傳遞物流資訊」。)