現状のKATSがどうなっているかまとめた事がありませんでした。
仕様書を書く前に、せめてクラス図だけでも書いておこうと思います。

会社のPCならモデリングツールが入っていますが自宅PCには無いので、フリーの
UMLツールをダウンロードして書いてみました。

まずはシステムコンテキストダイアグラムから。
皆さんご存知だとは思いますが、KATSの構成はこんな感じになっています。

ザラバ中に楽天RSSからリアルタイムデータを取得したり、監視銘柄抽出の時に
銘柄一覧を取得したりするためのクラス群は「RakutenRss」という名前空間です。

メインのDdeManagerというクラスが、NDdeというクラスライブラリのラッパーです。
全てのPublicメソッドはstaticです。
RequestStockItem()メソッドは全銘柄一覧を取得するメソッドです。
Request系メソッドは取得するデータ型毎にメソッドがあります。
IsArive()メソッドは楽天RSSの生死確認用メソッドです。
StartAdviceするのはStart()メソッドで、更新通知を開始する項目はIDdeAdviceという
インタフェースで渡します。監視する項目が変わってもDdeManagerを修正しないで
済むように、また煩雑なIF文を書かないようにStateパターンで実装しています。

余力情報、保有銘柄一覧、約定一覧などの取得や発注はクリック証券のWebサービス
APIを呼び出していますが、それらは「Gmo」という名前空間です。

こちらはGmoProxyというクラスがクリック証券のWebサービスのラッパーです。
KATSはGmoProxyを使う事によってWebサービスを意識せずに各種情報の取得や
発注を行う事が出来ます。
GmoProxyのPublicメソッドは全てWebサービスのURLに準じています。
Webサービスの結果は全てXML形式で返るのですが、そのままだと扱いにくいので
画面に表示するにもプログラム中で使うにも都合が良いようにDataSetの形に
変換しています。

そしてKATSのメイン部分です。
メイン画面から開く各サブ画面(メインのバッチ処理以外)はこんな感じです。

設定画面はSettingFormです。
各種設定をapp.config.xmlに読み書きする画面です。
購入候補登録画面は購入候補登録のバッチ処理を非同期で起動します。
その時、RakutenRssやGmoの名前空間を使用します。
購入候補はKATSDataSetを使ってRDB(Access)に登録します。
TableAdapterも使っていますが省略しています。
購入候補や売却候補の画面はKATSDataSetの内容を確認したり手直ししたり出来る
画面です。

メイン処理のクラス図も一応書きました。でもうまくまとまりません(^-^;

自動購入処理と自動売却処理はそれぞれ別のBackGroundWorkerで非同期に
実行されます。
実際に起動されるロジックは設定画面で指定したロジックでTradeLogicFactoryが
app.config.xmlを見てインスタンス化し、起動します。
名前の通りFactoryパターンを使用しています。
売買ロジックを切り替える時にはプログラムを修正しなくても設定画面から修正すれば
良いようにしています。
各売買ロジックは色々なクラスを呼び出していますがロジック毎に違いますので
まとめて書いてます。

ざっとこんな感じです。

お気に入りの記事を「いいね！」で応援しよう