[個案研討] FTP Server 是否可為企業系統的外部系統?

** 本文同步發表於 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、網購平台使用案例模型

圖1、網購平台使用案例模型

但是當從需求分析轉移到實作階段時,因為必然會談及到實作的議題,包括連結的協定與資料格式等。所以呼叫的標的系統此時就應以實際所連結的標的來稱之,如 FTP Server。

參考下圖2,PlaceOrderControl 是 Domain Controller 類型,它接收了「處理訂購」的要求。實作人員設計了 DAO (Data Access Object)物件,它負責把訂購交易的資訊儲存到資料庫 (如 Oracle);Adapter 物件則是負責把物流資訊,可能整理成 XML 格式,然後再寫入至指定的檔案位置,並透過 FTP 協定傳送檔案至遠端的 FTP Server 上。

圖2、PlaceOrder 實作循序圖 (sequence diagram)

圖2、PlaceOrder 實作循序圖 (sequence diagram)

上圖2 循序圖是會透過實作的手法來調整設計的。很可能 Adapter 物件並沒有透過 FTP 協定傳送至 Ftp Server,而是僅僅只寫入至 Local 端的檔案系統;而 FTP 傳遞則是在另外一個時間點,藉由另行撰寫如「SendFiles script」來批次傳送資料。若是這樣的情境,那應該是會被視為另一個個案的分析了。 (啟動的參與者為 Scheduler 系統,Use Case 為「傳遞物流資訊」。)

文章導覽

   

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。