[交易系統] C#.NET 開發海外期貨部位策略管理系統

這是兩三個月前,某大戶所委託開發關於海外期貨的部位策略管理系統。先前有徵詢過該大戶的同意,得以分享該系統的功用與開發概要。

該大戶係以 MultiCharts 作為報價與策略設計的平台,然後再以自行開發輸出文字檔的 DLL 元件,並搭以自動下單系統,而構成全自動化的程式交易系統。

由於管理的海期商品多達上百種,且運作的帳戶亦多達數十個,資金操作已達一定的規模。有感於資金部位的風險管理有其必要,故把他關於資金部位的策略邏輯,並需要整合現在運作的自動下單,寫成一份需求委託文件,以及一些測試的案例與資料供開發上的參考。

我使用了 UML 元件圖 (Component Diagram),先大致表達出整個海期交易系統的架構 (architecture):

海期自動化交易系統架構圖

圖、海期自動化交易系統架構圖

原來的交易系統係以無窮迴圈的處理方式來持續輸出所監控商品的報價文字檔,使用相當簡單的程序以代表 Tick 的跳動;然後自動下單系統再去讀取所有商品文字檔 (仍以無窮迴圈方式),並判斷商品的部位數量有無變化情形,再決定是否傳送至券商的下單系統。

「海期部位策略管理系統」從功能區分大致上區分有三個模組:商品即時監控、專案帳戶資金管理、判斷帳戶所持有部位 (新增/輸出)的邏輯處理

圖、海期資金部位策略管理系統 by C#.NET

圖、海期資金部位策略管理系統 by C#.NET


為了要對各商品的部位規模作管控,所以就是在輸出的報價商品文字檔這邊截斷,然後改由打算新增的「部位策略管理模組 (在整個交易系統中,是被視為單一模組的)」接手,將讀取進來的報價商品針對各專案帳戶,運用如海龜的資金管理邏輯,來決定部位 (Position Size)的放大或縮小;處理之後的監控商品再輸出為文字檔,然後才再由自動下單模組讀取並進行後續的處理。

這仍是個即時 (Real Time)的交易報價暨下單系統,只是因為商品文字檔係以無窮迴圈的方式來輸出的,所以其實已沒有 Tick-Notify-Driven 的事件處理這樣的觀念了。原來我是以事件處理的架構撰寫的 (以為文字檔是 Tick-based,後來大戶解說後才知道),結果幾乎每毫秒就會觸發 Tick 事件處理程序,這根本就不合理;後來改採以 Timer 定時觸發方式 (每 500 毫秒,可設定),系統在校能、穩定、正確性方式就得以達成要求。

使用什麼樣的程式語言開發,該大戶並沒有要求。我是建議採用 C#.NET 來開發,因為該系統個人評估未來有兩個需克服的關鍵點:一為效能上的考量;另一為策略邏輯的實作。

圖、Visual Studio 2012 開發交易系統 by C#.NET

圖、Visual Studio 2012 開發交易系統 by C#.NET

因為系統需要持續的讀取所監控的商品文字檔 (多達上百檔以上),然後又要持續輸出處理過後的商品文字檔,再則專案帳戶是近上百個 (還會持續增加),這整個處理與判斷的邏輯,需要控制在 500 毫秒 (0.5秒)內完成。

這是屬於系統的非功能需求 ((Non-Functional Requirements)範疇。顯然這必須以多執行緒 (Multi-Thread)技術架構來達成效能與效率上的要求。要用如 Excel VBA 或 PHP 等機制,是難以達成效能上的要求的;相對採用 .NET 機制來處理多執行緒,會容易很多 (但如何設計規劃,仍是需要 Developer 本身構思的)。

再來關於系統的功能性需求 (Functional Requirements)範疇,要能判斷與處理監控商品的資金與部位的商業邏輯 (business logic),也沒有想像得簡單,更何況所有專案帳戶、所有監控商品,要能控制在 0.5 秒完成~。

圖、海期資金部位策略管理系統-新增商品對話框

圖、海期資金部位策略管理系統-新增商品對話框

所有商品 Tick 資訊係以物件結構儲放在記憶體內 (如此才有可能快速運算),並利用所謂的泛型List 集合 (Generic Collection)物件來組織;要如何有效篩選所需處理的商品物件?此時採用 C# LINQ 機制,那可說是太簡潔便利的利器了。

例如我要利用商品ID尋找到所對應的專案商品物件,LINQ 語法只要這麼一行:

ProjectItemDTO ipto = prj.prjDTO.prjItemList.Where(d => d.ID == dto.ID).FirstOrDefault();

若沒使用 LINQ,那麼就需要自行撰寫尋找商品的 Function,大概就需要10來行才能達成上述只要一行的功能。

簡單的說,利用 .NET 的機制,讓多執行緒的處理更為有效率簡單;利用 C#.NET 語法,來撰寫物件結構並以 LINQ 機制快速存取記憶體內的物件。把主要關於非功能性與功能性的風險得以侷限在可控制的範圍內,這是中大型系統開發一開始就要針對架構規劃並提出適當的解決方案的

日前該系統已完成開發並已交付,前期的測試也已告完成,但仍須較長時間的一般化功能測試,務求系統的精確性 (畢竟,這是具相當規模的資金管理系統)。

除了在系統開發的過程中,對這類即時性、採以多執行緒的系統更有實務上的心得外 (畢竟個人所輔導與開發的系統大都偏向大型 MIS 管理系統),更是對交易的核心部分-資金與風險的策略性管理有了更深一層的體會心得;所以我還特別再重新詳讀「海龜投資法則」與「短線交易秘訣」這兩本書關於資金部位的策略管理觀念,收穫著實甚多。

對了,我想應該也會採購「MultiCharts」這套交易系統 (等待年底五週年慶國內凱衛的優惠),這一部分的投資還是不能省的。對於接收報價 (台灣、國際)以及作投資組合的績效回測等,它優異具彈性的表現仍是國內外最受歡迎的交易系統。

MC 有提供 APIs,如此就可以容易地整合自行開發如上述的資金部位策略管理模組。當然要熟習關於 MC 的報價接收/策略開發/績效回測等功能,仍是需要一些些學習時間;不過這對我還好,其實幾年前我就已利用該系統實作過一些功能,例如-DDE 即時連結大盤江波買賣資訊。後續應該會分享諸多相關於 MC 的一些開發心得文的。

文章導覽

   

共有 6 則迴響

  1. 太厲害了
    像我有 100個以上的策略要執行
    真需要這樣的軟體平台 !!!
    請問可以問相關問題嗎?

  2. 你好

    我是一個小小碼農,不是本科。

    目前在券商服務,不過目前的IT環境並不是我想要的。

    以前做過營業員,其實我對工作的想法很像這個BLOG的內容。

    就是以交易為主下去客制化系統,不知道對於這點您有哪些建議。

    最近可能會想換工作了吧~~~

發表迴響

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