[C]KONOEクラスライブラリー
「KONOEを構成するプロセス」のところで見てきたいろいろなプログラムは
それぞれがアプリケーションクラスとして定義されることによってカスタマイズ
を容易にできるように設計されます。それ以外に、KONOEの縦糸横糸をなす
様々な機能はすべてクラスライブラリとして提供されます。
実際の産物は、開発中のものですが、ここ
からたどることが出来ます。
基本的な構成として、
- システムの骨格となる部分として
- DAQ部品となる部分
- 解析ツール部品となる部分
- GUI部品
などを必要なクラスライブラリとして準備します。これらを使ってKONOE
プロセス自身を設計するとともに、ユーザにカスタマイズのための
パーツとして提供されます。
大分類としては上述の4つのカテゴリーに分けましたが、さらに細分した
カテゴリー毎にクラスを宣言していきます。以下、カテゴリーには
というロゴマークが、クラスには
がそれぞれ張り付けてあります。
C1.システムの骨格部分
この部分はシステムを構成する階層を満たすためのクラスで、全体に関わる
重要な部分です。特にDAQシステムを構築する場合に重要なのがマルチプロセスの
取り扱いです。様々な理由から、システムはいくつものプロセスから成り立って
おり、何らかの通信手段で対話する必要があります。また、それらはネットワーク
上に分散して配置されることになります。
オブジェクト指向技術の導入を考えた場合、プロセス間で交換されるものは
オブジェクトということになります。ところが現在までのオブジェクト指向言語
処理系は、単一のプロセスの中ではオブジェクトを制御できるけれども、プロセスが
消滅すると同時にオブジェクトも消失してしまいます。プロセス消滅後も
オブジェクトを生存させる機構は現在の処理系には含まれていません。
また、オブジェクトはそのプロセスの中だけに存在し、複数のプロセスで
オブジェクトを共有する機構もまた用意されていないのが現状です。プロセス
の間で通信するソケットで送られるものはあくまでもバイトストリームで
あり、オブジェクトとしてどう読むかはアプリケーションの責任です。これは
ファイルに書き出されるデータも同じようなバイトストリームですから、
オブジェクトをファイルに書き出すとかファイルから読み込む機能も
同じ枠組みで実装することが出来ます。プロセスの寿命を越えて存在し
続けるオブジェクトを実現する仕組みをオブジェクトパーシステンシーと
呼びます。
一般的なオブジェクトパーシステンシーの実現はファイルに書かれているものや
プロセスの間、ネットワークでやりとりするものがオブジェクトとして認識
されるオペレーティングシステムの機能として実装されて初めて完全なものに
なると考えられます。そのための研究開発や試験的な製品もでていますが、
それを待つわけにいかない私達は以上の検討から、DAQシステム構成という
目的に限定して、上に述べたようなオブジェクトパーシステンシーを実装する
ことにします。
オブジェクトはオブジェクトストリームを通して入出力されます。
オブジェクトを一定のルールに従い、バイトストリームに変換したり、
バイトストリームをオブジェクトストリームと解釈してそこから
オブジェクトを生成します。そのため、オブジェクトストリームで
扱えるクラスはそのルールを理解している必要があります。この
ルールは"オブジェクトとしてストリーム可能な"という抽象クラスの
継承で実現されます。
バイトストリームの中ではオブジェクトは構造化データとして検索可能な
適当なフォーマットで表現されます。そのフォーマットでのタグにより
メンバーデータが識別されることになります。このとき、
- クラス定義のバージョン管理の取り扱い。
- 継承関係にあるオブジェクトの取り扱い。
などが主要な検討課題にとなると考えられます。
[現在の実装はこう
なっています。]
オブジェクトストリームを継承し、オブジェクトファイル入出力を実現
します。あくまでもUNIXやDOSなどのファイルシステムを利用することを
考えており、しかも短時間に開発する必要があることから、実装としては
UNIXシステムコールによる入出力を用いた、オブジェクトストリームの
実現ということになります。
ファイル名の管理や操作なども機能として含む必要があります。
[現在の実装はこう
なっています。]
オブジェクトストリームの継承の一つとしてソケット入出力を実装します。
これはプロセス間通信に用いられるソケットを通してオブジェクトを交換することを
おこなうものです。データ収集システムの基本部分であるデータの転送も
オブジェクト通信として扱われるわけですが、これにより、バッファや待ち
行列などの実装と、アプリケーションの構成を絶縁することが可能となります。
実用的な性能を実現するために重要なクラスでもあります。
ソケット通信の開設と閉鎖、接続相手のネットワークアドレスやポートの
管理なども機能に含まれる必要があります。
[現在の実装はこう
なっています。]
これも入出力と関係しますが、システム全体で利用されるデータベースを、
やはりオブジェクト入出力の機能を使って実装する必要があります。ネットワーク
上の任意のホストから、データベースサーバへ問い合わせた場合、サーバは
検索の結果みつけたオブジェクトをストリームを通して返してやります。同様に
クライアントはデータベースに登録するオブジェクトをストリーム経由で
送り付けます。サーバはオブジェクトファイルとしてデータベースを記録
します。
このようにオブジェクトデータベースはこれまでに見たオブジェクトファイルI/O
やオブジェクトストリームI/Oを用いて実現されるサーバアプリケーションと、
それとの対話を行なうインターフェースクラスにより構成されることになります。
KONOEシステムでは各々のプロセスは主にデータストリームを送り出しもしくは
受け取るプロセスとして共通の属性をもちます。また、次に述べるメッセージ
システムを通して通信しながら並列動作するプロセス群として制御されます。
これはある種のクラスとしてプロセスを定義可能であることを示します。
おのおののプロセスはそれらの機能を実装したアプリケーションテンプレート
クラスのオブジェクトとして実行されます。
また、プロセスという概念はKONOEがネットワーク分散環境であることから、
システムの基本的な要素です。プログラムの中で他のプロセスを指定する
必要が頻繁に発生します。そのため、各々のプロセスに関する情報を
オブジェクトとして持っている必要があります。プロセスは例えば名前で
識別されます。その名前のプロセスがネットワーク上のどこにあるか、
現在どういう状態にあるかなどプロセス情報オブジェクトを通して調べる
ことができなくてはなりません。
KONOEではさらに、各々のプロセスの生成消滅を管理するサーバを必要と
します。
一言でデータベースといいますが、色々なデータの扱いが考えられます。
そのなかで、UNIXのデータ収集系で特に必要なものを考えてみましょう。
UNIXはコンパクトですが、実時間OSとしてはいろいろと不十分なものです。
その不十分さの一つにVMSでいう論理名のような、複数のプロセスで共有
できる名前空間を持たないことがあります。例えば環境変数は自分の
子プロセスにしか引き継がれないし、その場合も、引き継がれた後は
別のテーブルなので親が変更しても子には反映しません。近い機能と
してはシンボリックリンクがありますが、これもファイルへのリンクと
しての性格が強く、OSレベルではデータベースとしての利用には適しません。
この論理名は非常に簡単なもので、単に文字列である名前に対応した
文字列データを保持しているだけです。もちろんこれだけでも随分と
役に立ちます。例えばランコメント、ランナンバーなどスカラー量で
あればこの方式で十分実装できます。また、強引ですが、名前の末尾に
数字を付けてベクトルも表現することは可能ですが、効率的とは言えません。
ともあれ、これらの情報は非常に頻繁に参照され更新されます。例えば
イベントナンバーなどは逐次更新されます。このような機能はオブジェクト
データベースとは別に実装する必要があるかも知れません。
KONOEではネットワークに分散したたくさんのプロセスが有機的に結合して
システムを構成します。そのためのメッセージ交換はDAQの制御階層の中心部分と
なります。メッセージ送受信をつかさどる機構が実装されなければならないわけ
です。また、メッセージは各々のプロセスに対するコマンドとして解釈される
必要があります。そのための通訳機能や、命令定義などの機能をクラスとして
実装します。
上述したメッセージも含め、DAQシステムではさまざまな情報がログとして処理され
記録される必要があります。また、一部の障害報告でそれによって自動的な対処が
必要なものもありえます。ファイルにログを書き出したり、そのログを検索
したりする機能、受け取ったメッセージの識別番号などを手掛かりに対処法を
起動する場合、そのメカニズムなどを規定する機能などが必要になります。
ここまでに見てきた様々な機能、また次節以降に述べる多くの
機能は基本的にUNIXのシステムサービスを呼ぶ出すことによって実装される
ことになります。問題は、計算機の種類やOSによってシステムサービスの
仕様などに差があることです。全てのシステムが例えばPOSIX互換であれば
それに閉じてプログラムすることが可能ですが、それにしてもオブジェクト
指向と相性の良くないシステムサービスをプログラム中にちりばめることは
好ましいことではありません。
KONOEではそのような機種依存の部分をシステムサービスインターフェース
クラスに吸収してしまいます。他の全てのコードは完全に全てのシステムで
共通になるようにします。
[現在の実装はこう
なっています。]
大規模なプログラムではオブジェクトの集合をいかに合理的に管理をするかが
重要な性能決定事項になります。通常、オブジェクトはコンテナクラスと
呼ばれるクラスを用いて管理されます。KONOEは、このコンテナクラスについても
すべて自前で用意します。
C2.DAQ構成部品
次にデータ収集を作り上げるためのクラスについて見ていきましょう。
ここでは主にデータを集めてくる部分の機能について見ます。次の節で
それらのデータを処理する部分について検討します。
データ収集システムはある意味でデータ転送システムです。複数のプロセスで
それを実装する場合データの流れをどのように扱うかをモデル化することが
必要になります。KONOEではデータフローはノードとなるプロセスとその間を
接続するソケット結合であるリンクにより空間的に分布するものと考えます。
そして基本的にリンクではデータの論理的な流れは一方通行です。
このモデルでは各々のプロセスはノードとして、0以上の入力と0以上の
出力を持ちます。リンクは一方通行なので、一つの出力と一つの入力を
接続します。
このようなDAQプロセスの枠組みを提供するクラスを用意します。
データ収集系としてまずデータソースを考えてみましょう。データは
VMEやCAMACなどのモジュールから読み取られるものが一般的ですが、
場合によってはシミュレーションや仮想的なモジュールという場合も
ありえます。特にソフトウエア開発の段階では、例えば実際には接続
されていないことも多々あります。この場合、代わりに仮想的な
モジュールを接続することでおおかたのデバッグを行なうこともできます。
データソースとなるハードウエアとしてはVME、CAMAC、TKOを当面の対象と
することにします。それぞれ、かなり異なった読み出し方法をするので、
一括して扱うための工夫が必要です。例えばアドレスの指定の仕方は
それぞれで全然違うものですが、データを読みだすためのアドレスを
持っているという属性は同じです。DAQクレートと、それにささった
DAQモジュールという抽象クラスを導入し、それぞれの実際のハードウエア
について継承します。
DAQモジュールとしては手作りのものも含めて、様々な種類のものが
ありますが、それぞれについてクラスを定義することになります。
おのおのは初期化や読み出し書き込みなどDAQモジュールのメソッドを
実装しなければなりません。
[現在の実装はこう
なっています。]
データソースを読み込もうとするタイミングは割り込みによって発生する
場合もありますし、あらかじめプログラムされている場合もあります。またその
タイミングをプロセスにどのように伝えるかを考える必要もあります。
割り込みやタイマー等によるシグナルなどのトランザクションに、対応する
処理を結び付ける仕組みが必要です。
[現在の実装はこう
なっています。]
例えばあるトランザクションに対応して、どのようにデータソースから
データを読みだすかを規定する方法が必要です。この場合、ただ取り出す
だけでなく、それらのデータに名前を付けて検索可能にしてイベントデータ
として構成する必要があります。これらを記述する方法が必要です。
この方法の実装により、実行時に任意に読み方を再定義できます。また、
この読み出し手順はデータベースに保管され、次に呼び出すことが
可能になっていなければなりません。
[現在の実装はこう
なっています。]
C3.解析部品
オンラインシステムにおいてもデータ解析の機能は非常に重要です。
解析ではデータをどのようにモデル化するかが問題になります。
まず前半で生データとして扱われるものについて考えます。次に
解析の結果であるヒストグラム等をどのように扱うかを考えます。
読みだされたデータの並びは一まとまりのレコードとしてメモリー上及び
二次記憶中で管理されることになります。他のホストやプロセスとの通信に
おいてもこの単位で処理されます。KONOEではとりあえずDAQモジュールからの
データをデータレコードに突っ込みます。データ収集段階ではデータの物理的
意味などは考える必要がないのでこのままデータレコードとしてやりとり
され、解析段階になってはじめてデータレコードから個別のデータが取り出され
解読されます。
データレコードはイベント毎にはイベントレコードとして扱われます。
ランビギンレコードやランエンドレコードなどもこの枠組みで処理します。
[現在の実装はこう
なっています。]
データレコードの解析は、まずタグの付けられたバイナリーデータを
物理データに解読することから始まります。これは、ADCの値であったり、
ドリフト時間であったり、クラスターエネルギーであったり、いろいろな
ものがあります。基本的に我々が扱いたいのはこのレベルのデータです。
この物理データはイベントを選ぶためにフィルターとして使われ、
ヒストグラムのインプットとして使われ、トレンドの作成にも
使われます。
イベント毎に得られた物理データは場合によってはイベントレコードに
追加されて次のプロセスへ回されます。そのために、データレコードの
枠組みに埋め込める形になっている必要があります。
[現在の実装はこう
なっています。]
ヒストグラムはオンライン・オフラインを問わず最も多くもちいられる
解析手法です。イベントデータなどからヒストグラムを生成する機能と、
ヒストグラムの表示や演算などの機能を用意する必要があります。
[現在の実装はこう
なっています。]
トレンドは時系列にならんだデータの並びであり、刻々の変化を記録
したものです。取り扱う
データには色々な物理量の平均値もしくは最大、最小値、単位時間内の計数
などが考えられます。これも上に述べた物理データオブジェクトが
利用できます。ヒストグラムとほぼ同じ機能ですが、例えば有限の
長さの記憶域では過去のデータを上書きしながらリング状に記憶域を
使うなど、固有の機能が必要です。
データをモニターするうえでもう一つ重要なのが、イベントバイイベントでの
データの表示です。通常はイベントディスプレイと呼ばれます。イベント
ディスプレイを実装するためには、ヒットに該当する測定器要素をその
幾何学的な配置にあわせて表示する必要があります。このため、測定器要素の
座標や形状と言った情報を持っておく必要があります。
こういった幾何学情報は解析の他の段階でも必要になります。例えば
カウンターのヒット位置とチェンバーのヒット位置の間の相関をとり
たい場合、すべての組み合わせをヒストグラムに使ってしまうとわけが
わからなくなります。この場合、例えばヒットのX座標が最も近い
組み合わせを採用するという操作が必要になります。
C4.マンマシンインターフェース
マンマシンインターフェースを実現するための機能を担うクラスです。
これらはクライアント側のプロセスを構成するためにJavaのクラスとして
実装されます。そして、その基本部品をjava.awtから取ってくることに
なります。
いくつかのウィジェット(ウインドウを構成するボタンや枠などの部品)は
AWTに定義されていますが、それだけでは不十分です。よりアプリケーションに
ちかい、高いレベルの機能を定義します。具体的にいうと、例えば
DAQ構成層のそれぞれに対応したインターフェースをクラスとして用意する
ことによって、全体として統一した操作感が確保できます。例えば
データベース検索はいろいろなところで必要な機能ですが、それらを
GUIレベルで実現するクラスはいろいろなアプリケーションで共通に
用いられるべきです。
描画を行なう機能を実装します。イベントディスプレイのように、
三次元座標のイメージを表示するもの、ヒストグラムやトレンドなど、
専用のイメージを扱うものが必要です。
描画コンテキストとしてはjava.awtと、ハードコピーに出力するための
ポストスクリプトのコンテキストが必要になります。
DAQの様々な局面で使われるいろいろなイメージファイルやグラフ、
図面などはシステムを通してグラフィックスオブジェクトとして
認識される必要があります。これは追及していくと結構大変な
問題ですが、検討する価値のある問題です。
DAQのマンマシンインターフェースの機能としてレポート機能は非常に
重要な要素の一つです。せっかくJavaをベースに構成するわけですから、
(アプレットとはいかないですが)レポートはHTMLファイルの自動生成と
いう形で実装したいものです。
この場合日本語の取り扱いは重要な課題です。
KONOEでは日常の操作はGUIを通して行なうことを想定しています。しかし、
必ずしもGUIによる操作が好まれない場合もあります。例えば同じような
操作を繰り返したりする場合、一連の手順を記録してそれを実行したい
という時があります。マウスやボタンの操作を記録することは可能ですが、
その記録を編集することを考えると手順の記録としては適切ではありません。
このような場合、コマンド言語処理系は重要な役割をします。コマンド言語
はテキストですから、通常のエディターなどで編集可能ですし、それぞれの
行の意味は人間が読んでわかるものです。処理系の実装によっては
条件分岐やループなどのプログラミング機能も加えることができます。
目次へ 前章へ
次章へ
[classes/classes.html] Last Modified : 05-Feb-1998.
KONOEコラボレーション
konoe-req@konoe.kek.jp