[現在の実装はこう なっています。]
ヒストグラムには配列などの記憶域と、その横軸の意味するもの、ビン、 エントリー数、オーバーフローやアンダーフローなど色々な情報が 含まれます。そのうちの「横軸の意味するもの」について考えて 見ましょう。これはある値を取るものです。それは例えばイベント データの中に含まれるADCの値です。このことから、データ収集部分で 述べたデータリストを構成するものとも関係付けられます。
同じ情報が例えばフィルするかどうかの判断に使えます。ADCの値が この範囲の時のTDCの値などを求めるとき、同じ枠組みでデータを 検査し、フィルの判断に用いることが出来ます。このように、 解析で使われる物理データとしてのオブジェクトを導入し、それを 用いてデータセレクションやヒストグラミングを行なうことにします。
イベントデータはそこに多くの物理データを含みます。そこから どのようなヒストグラムをフィルしていくかを考えてみましょう。 同じデータがいくつものヒストグラムをフィルする場合があります。 物理データとヒストグラムは1対1対応する訳ではありません。また、 物理データがいくつか取り出され、そこから相関を得てフィルが 行なわれる場合もあります。物理データとヒストグラムの他に、 データを取り出してフィルをする機能が外に存在しなければならない ことになります。「ヒストグラムをフィルするもの」という クラスを用意することが必要です。
アナリシスによっては、大量のヒストグラムを生成する必要がある ことがあります。その場合、合理的効率的にヒストグラムを管理する ことが重要になってきます。階層化された構造の中に保管したり、 意味のわかる名前で検索できたりすることが出来るようになっていなければ なりません。
ヒストグラムはある意味でデータ集計表です。集計表の次元としては いくつでも可能ですが、現実的な記憶域との関係から高い次元のものは 作りにくいので、当面1から3次元くらいのものを考えましょう。この ことからヒストグラム本体は
現在の実装では次のように継承関係が与えられています。
現在の実装では次のように継承関係が与えられています。
現在の実装では次のように継承関係が与えられています。
解析では、おもに用いる物理データによってヒストグラムをグループに 分けることが考えられます。また、それらは相互の関係から、例えば ディレクトリ構造に配置されることが好ましいでしょう。
ディレクトリ構造をクラスとして扱うKonoeDirectoryクラステンプレートを 利用して実装します。
物理データが導出されると、そのデータを使ってヒストグラムをフィルする 段階に入ります。このとき、物理データが自分のフィルすべきヒストグラムを 知っていればそれぞれをフィルしてまわればいいのですが、物理データ自身に ヒストグラムの情報を覚えさせるのは好ましくありません。そうすると、 ヒストグラムを一つ一つ調べていって必要ならフィルするのも効率的とは 言えません。また、逆にヒストグラムの方から必要な物理データを呼び出して フィルする方法もありますが、この場合、例えば相関をとるときなど 同じ処理を繰り返すことになったりして、やはり効率的でないと考えられます。
物理データでヒストグラムをフィルするという発想をそのまま受け入れると すれば、第三者が最も効率的な手順でそれを行なうというモデルが適して いるように思えます。このことにより、物理データとヒストグラムが 強く相関し過ぎることを避けることが出来ます。物理データにしてみれば ヒストグラムの実装には興味がありません。ヒストグラムにしてみれば 自分をフィルするのに最小限の情報を知りたいと思っているので、物理 データの実装の詳細は知りたくありません。
フィルをする主体は、物理データとヒストグラムの両方について 知っていなければなりません。物理データが出そろったところで、フィル 主体が起動されます。フィル主体は物理データからフィルデータセットを 抽出し、ヒストグラムのフィルメソッドを読みだします。
フィルデータセットの抽出は解析の上で非常に重要な作業です。抽出という 作業の中には、値に関する演算と、その結果を用いた論理操作・判断が 含まれます。また、それらはいくつものステップが一連の操作として カスケードに行なわれていきます。それらの手順が記述されなければ なりません。
以上の議論をもとに、次のような登場人物を考えることが出来ます。
プログラミングの詳細に行く前に問題を良く分析することが必要なことは いうまでもありません。特にオブジェクト指向プログラミングの場合 そこにある「もの」をいかに的確に認識するかということがポイントに なります。プログラミングが問題解決の方法であると考えると、問題の うらに隠れている「もの」の発見がソフトウエア設計(クラス設計)の もっとも重要な仕事になります。
class KonoeFillData { public : KFloat getX( ); KFloat getY( ); KFloat getZ( ); };これを用いて、
class KonoeHistogramBase : ... { public : virtual KInt fill( KonoeFillData * ) = 0; ... }:という風にしたいのです。
class KonoeFillDataExtractor { public : KonoeFillDataExtractor( KonoePhysicalValue * value, KInt manner ); KInt getDataCount( ); KonoeFillData * next( ); };とかを考えてみましょう。コンストラクタで物理量と振る舞いを指定しています。 フィルの際、順にフィルデータを取り出す機構が想像できると思います。
class KonoeHistogramFiller { public : KonoeHistogramFille( KonoeHistogramBase * histogram, KonoeFillDataExtractor * extractor ); KInt fill( ); };コンストラクタで抽出器とヒストグラムを結び付けます。そうすると fillメソッドを呼ぶだけでヒストグラムがフィルされます。
抽出器やフィル主体は必要な情報をコンストラクタで得ています。それによって 最初にコンフィギュレーションをおこなうだけで、ユーザはフィルを直接 記述する必要がなくなります。汎用性のあるコードを意識しています。
class KonoeHistoFillerList : public KonoeTree < KonoeHistogramFiller * > { public : KInt fill( ); };まずFillerListを生成し、個別のFillerをaddしていきます。これで準備は 終わりです。フィルすべきタイミングでこのリストのfillメソッドを 呼ぶと、一つづつとりだしてfillを呼ぶことになります。