輝々凛々

ガンバるってことは、素晴らしい事だ。

プロセッシングモデル。

以前、書いた「プロジェクト処理モデル?」のコーディングをちょとずつ進めているんですけど、モジュールの名称やらを以下のように変更・・・というメモ。

追記補足

「プロセッシングモデル」などと大仰に呼んでいるもので、やりたいことは「同じようなアプリケーションの組み方を毎度毎度するのも嫌だし、基本的な処理の流れをあらかじめパターン化しておけばいいんじゃないか」と思ってパターン化しているもの。いわゆるデザインパターン的かもしれない。

で、ここで示しているもの(というかメモなんですけど)は、アプリケーションの処理がユーザーの入力待ちにならないようなものを想定している。ユーザーからの入力は、このモデルに突入するよりも前に処理すれば良いようなものでもいい(ユーザーがパラメータを決定して、そのパラメータで処理する部分をこのモデルで書ける)。

また、サーバーアプリのようなものには適用できないと思われる。

概要

大まかには、「ユニット」と呼ぶ処理モジュールがあって、アプリケーションはそのユニットをいくつでも、つなげて目的の仕事を達成させる。また各ユニットのデータのやりとりは「データ」という抽象的なデータを用いて行う。

基本的には以上だが、各ユニットの動作が必ずしも同じ速度で動くわけではないので、各データを貯めておく為に「データプール」というモジュールを用意しておく。

また、アプリケーションは、このモデルを利用した際に煩雑な手順を毎回コーディングすることになってしまうので、シンプルに扱えるように「マネージャ」というモジュールを用意しておく。

ユニット
何かを処理するモジュール。入力データや出力データはなくても良い(ファイルリードは入力データなしのユニットで、ファイルライトは出力データなしのユニット)。ユニット内ですべき仕事はアプリケーションからパラメータとして渡される。
データ
データの抽象クラス。バイナリデータや、画像データなどのデータをメモリ上に持つ(メモリアロケーションの管理もする?)。
データプール
データを一時的に貯めておく貯蓄クラス。アプリケーション(マネージャ)は、プールがあふれない様にプログラムを組む必要がある(面倒?)。
マネージャ
ユニット間のデータ接続やプールの管理などを簡単に行えるインタフェースをアプリケーションに提供するモジュール。
アプリケーション
仕事を記述するだけ、あるいは拡張ユニットを作成してマネージャに投げるだけ。

C#でクラスダイアグラムを作ってみた↓

プロセッシングモデル
クラスダイアグラム - プロセッシングモデル

うわぁ。しまった、ちょっと画像間違えた。IUnit.InputData.getはいらねぇし、IUnit.OutputData.setもIUnit.HasExited.setいらねぇなぁ。ついでにいうと、IDataPool.Dataも、どっちかっていうとIDataPool.DataListくらいにした方がいいのか? それなら、アクセッサはpush/pop系にしたいなぁ。

問題点

この状態でいくつかモジュール実装して、処理の流れがうまくいくことを確認。モジュールの追加や削除も簡単。しかし、ひとつ問題が浮上。問題は、「複数の出力データを受けて処理するユニット」とか「出力データが複数あるユニット」が作れないこと。

次のどれかだとは思うが、ほかに良い方法がないか探り中。

  1. IUnitを拡張して、PrevUnitListや、PostUnitList、InputDataList、OutputDataListなどを持つ、、という安易な方法。
  2. IDataPoolの実装方法を工夫する。ガベコレのような管理をするプールを実装。
  3. IDataの実装でがんばる。特定のユニットまでデータをキャリーしていくデータを実装。

上記、いずれにしてもIManagerが複雑化する。

WF

「エッセンシャルWindows Workflow Foundation」という本を読み進めているのだけど、何かここにヒントがあれば・・・・・・・・・・いいのになぁ。

関連記事

ツッコミの投稿


(ツッコミ非公開の場合はチェック)