利用 LINQ 實現期指Tick檔彙整為K棒

參考這一篇:「How to group a time series by interval (OHLC bars) with LINQ」。

我這裡使用 C#.NET 實作,並作了一些小小的修正,使之確實可以執行,並可從期交所所下載的原始 Tick 資料檔,經由前置的解壓縮、轉換為 Tick 物件型態,再透過該實作邏輯,就可以將 Tick 物件依所指定的時間週期 (time-interval),群組為所謂的「分K棒」(其實,正確的稱呼應該為 OHCK Bar)。

這裡也不禁對 LINQ 實作技術感到讚嘆! 它讓中間層 (middleware)的物件結構與資料來源 (data-sources)的存取,變得更為簡單太多了,所以也使得 Tick 轉K棒 的轉換邏輯,可以利用相當簡潔的語法 (類 SQL 語法),而達成該功能的實現。

底下的程式碼並未包含前述所提包括解壓縮、轉換為 Tick 物件等邏輯,只從一群已有 Tick 資料的 Collection 集合 (型態為 IEnumerable),依據所指定的 Interval 時間間隔,轉換為 K棒 (含開、高、收、低、量)的實作邏輯。

Tick 與 OHLC-Bar(K棒) 物件結構為:

    public class Tick
    {
        public string Symbol { get; set; }     //商品代號        
        public DateTime Timestamp { get; set; }  //成交日期時間
        public decimal Price { get; set; }     //成交價格
        public uint volume { get; set; }       //成交量
    }

    public class OHLCBar
    {
        public string Symbol { get; set; }  //商品代號
        public decimal OPEN { get;set; }  //開盤價
        public decimal CLOSE { get; set; }   //收盤價
        public decimal HIGH { get; set; }  //最高價
        public decimal LOW { get; set; }   //最低價
        public uint VOLUME { get; set; }   //成交量
        public DateTime BeginTime { get; set; } //開始時間
        public TimeSpan Interval { get; set; }   //時間區間
    }


將 Ticks 集合當成參數傳進該 method (generate_OHLCBar),處理後再傳回 OHLCBar 集合。

閱讀全文 »

[C# 實作筆記] 將 Zip壓縮檔內的文字檔轉至記憶體內的List集合

    目標:

  1. 在 C#.NET 程式內處理 *.zip 壓縮檔 (內含文字檔)的解壓縮 (decompress)。
  2. 將解壓縮後的文字檔讀進記憶體內 (memory),並將每行 (per-line)的字串 (string)儲存至 List 集合 (collection),以俾方便處理。
    主要做法:

  1. 因官方未提供處理解壓縮 .zip 壓縮格式機制,所以需下載 3rd party 的類別庫 (class library)。這裡以 SharpZipLib ( formerly NZipLib) 類別庫來處理解壓縮。
  2. 利用 SharpZipLib 內的 ZipInputStream 開啟 .zip 壓縮檔。
    string fname = @"C:\Download\TxtData.zip";
    ZipInputStream zipStream = new ZipInputStream(File.Open(fname, FileMode.Open));
  3. ZipInputStream 會依據所指定的緩衝區大小,依序將已解壓縮的文字檔內容讀至「位元組陣列 (Byte array)」;同時再利用已新增的 MemoryStream (記憶體串流)物件讀進 Byte array。
                    MemoryStream memStream = new MemoryStream();
                    int bufferSize = 2048;     //指定的緩衝區大小
                    int readCount = 0;           //回傳已讀取的位元組數目
                    byte[] buffer = new byte[bufferSize];
     
                    readCount = zipStream.Read(buffer, 0, bufferSize);   
                    while (readCount > 0)
                    {
                        memStream.Write(buffer, 0, readCount);
                        readCount = zipStream.Read(buffer, 0, bufferSize);
                    }
  4. 閱讀全文 »

程式碼與 UML 類別_循序圖 的關係探討-完結 (4)

支援自動產出循序圖的工具

  • EA (Enterprise Architect) 8.x-內建動態產出循序圖的機制。
  • Together, RSA, Flowchart4j(c#) -支持靜態產出循序圖的方式。
  • HSDc. Sequence Genenator (名稱暫訂)
    • 實作於 EA 7.x-8.x Plugin。
    • 支持靜態產出循序圖的方式。
    • 可支持正向/反向 將程式碼/循序圖互轉的功能。

HSDc Seq. Generator plugin 操作示範

  1. 安裝 Seq. Generator plugin

    圖、安裝 Seq. Generator plugin
    (點擊圖片鏈接看原圖)圖、安裝 Seq. Generator plugin

  2. 閱讀全文 »

程式碼與 UML 類別_循序圖 的關係探討 (3)

程式碼與循序圖的正反向工程

先瞭解一個重點:靜態程式碼結構並無法直接對應循序圖 (對應的是類別圖)

兩種方法可以產出循序圖:

  • 動態產出:設定 run-time 環境,實際執行應用程式,再由 UML 工具至系統內追蹤解析。
  • 靜態產出:直接掃瞄程式碼,解析物件之間的參考 (reference)。

動態產出循序圖的優缺點:

  • 優點:
    • 不需要程式原始碼,只要具有能直接執行的應用程式 (如 .NET DLL 執行檔)即可。
    • 可以確實捕捉單一程序內,物件之間的呼叫情形。
  • 缺點:
    • 需要事先設定好可以執行該應用程式的 run-time 環境。設定相當複雜繁瑣 (一般需為命令列模式),且不同的程式語言 (如 C#NET, Java, PHP …等)均須各自設定不同的 run-time 執行環境。
    • 只能呈現單一執行路徑內的物件互動。意即,無法呈現如 If…Then…Else 或 Exception 等多種條件或替代路徑。

靜態產出循序圖的優缺點:

  • 優點:
    • 不需要設定繁瑣的 run-time 執行環境,操作相當簡潔。
    • 可以指定所掃瞄的程式碼深度 (層次)。
    • 可以同時呈現多重的條件或替代路徑的物件呼叫互動情形。
  • 缺點:
    • 需要有原始程式碼,以提供靜態掃瞄的來源依據。
    • 轉換工具的實作邏輯並無明確的轉換 (transform)規則;相對來說,需要考量到程式語言個別的機制與語法,故轉換工具的實作難度相對提高。

※ 延伸參考
o 程式碼與 UML 類別_循序圖 的關係探討 (1)
o 程式碼與 UML 類別_循序圖 的關係探討 (2)

程式碼與 UML 類別_循序圖 的關係探討 (2)

程式碼與 UML 設計圖之間的關聯性

從抽象的角度思考 類別(Class)/物件(Object) 的關係

  • 物件是活的!
  • 但是,類別可不是死的 (更不是活的);因為,它僅是對系統的設計契約而已。

問題思考!?
程式原始碼 (Source Code) 對應的是 UML 哪一張設計圖?

推導-1
程式碼 = 靜態結構 = 設計契約 = 類別設計

所以 程式碼 對應的是:UML 類別圖 (Class Diagram)

Ex. 程式碼與類別圖的對應

範例-靜態的程式碼設計契約
範例-程式碼與類別圖的對應關係

使用 UML 類別圖 (Class Diagram)的好處

  • 快速定義類別的結構 (包括類別名稱、屬性與行為)。
  • 過濾程式碼實做的細節,容易聚焦於類別的責任分派 (responsibility assign)設計議題。
  • 可以透過工具,將類別圖轉出至對應的程式碼 (反之亦然)骨架 (skeleton)。

類別圖無法作到 …

  • 無法呈現系統執行期間 (run-time),程序單位之間的呼叫情形。
  • 無法追蹤為完成某一特定功能案例,物件之間的動態相依呼叫關係。
  • 無法掃瞄物件之間的動態連結,是否有違背類別圖的結構設計。

閱讀全文 »

程式碼與 UML 類別_循序圖 的關係探討 (1)

基礎觀念導引 - 何謂靜態與動態?

靜態結構 (Static Structure)

  • 表達軟體內部的結構設計。
  • 一般指程式原始碼 (Source Code)。
  • 軟體人員對資訊系統的設計契約 (Design Contract)。

靜態結構的設計契約

public class myclass {
	public void method_1() {
		//do something
	}
 
	public string method_2(string var) {
		//return a string
		return var;
	}
}

誰來解讀設計契約?

  • 一般指軟體資訊系統或應用軟體伺服器 (Application Server)。
  • ie. 可以編譯 C#.NET 程式碼 (設計契約)並能在 .NET 平台上執行應用程式。
  • 可以編譯 Java Spring 程式碼並能在支持 JEE (Java Enterprise Edition)平台執行完成編譯的應用程式。

動態相依 (Dynamic Dependency)

  • 系統在執行某一特定功能時,所啟始不同的程序單元之間呼叫的一種動態相依關係。
  • 一般指程式碼經過編譯後在執行期間 (run-time)的應用程式。
  • 資訊系統履行軟體人員的設計契約,使之可以在其平台上執行。

閱讀全文 »

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal