KONOE第三回ワークショップ(1997年12月)
KONOE第三回ワークショップは以下の要領で開かれました。
その時のスナップ、1と
2が会議中、
3と
4が宴会中です。
1.ワークショップ概要
日時 | 1997年12月18日(木)午前10時より19日(金)午後3時まで |
場所 | 岡山大学理学部物理教室 |
2.ワークショップの日程
今回のワークショップは特に解析部分とユーザインターフェース部分に
重点をおいたコーディング作業を中心としたものになります。
2日間の内の大半をコーディングに充てることになります。
- 全体ミーティング(18日午前)
- 作業(18日午後・19日午前)
- 全体ミーティング(19日午後)
3.ワークショップの内容
3.1.解析・UIパッケージの内容の検討
KONOEの全体の枠組みの中で、特に解析部分は非常に発展性の高い
部分です。そういう意味でどのようなものを目指すのか集中的に
議論します。その内容に応じてユーザインターフェースをどう
設計していくかということも重要になります。
3.2.作業分担とコーディング
解析パッケージの作業分担を明確にし、今回のワークショップでの
到達目標を決め、それに向けてコーディングを行なっていきます。
すでに用意されているデモプログラムの後半を拡張していく作業に
該当します。Javaアプレットのフロントエンドまでも含めて、
KONOEの一貫したデモがここで初めて完成します。
- プロセスの構成
- 現在、1対1接続になっているサーバとクライアントの関係を1対多と
して実装する必要があります。複数の解析プログラムを接続することを
考えています。
- データソース
- 現在のデモは単純に乱数をふっているだけですが、もうちょっと
リアルな実験を想定してデータを発生させることを考えます。例えば
宇宙線の通過位置を発生してそれに対応したチェンバーやカウンターの
応答をシミュレーションするなど。
- 解析
- 現在は単純なTDCヒストグラムだけですが、拡張してニ次元の
ヒストグラムを生成するようにしましょう。
- ユーザインターフェース
- 今回の作業ではじめてUI部分が付け加わります。解析プログラムと
通信してappletでヒストグラムを表示します。
3.3.開発ソフトウエア管理の方法
ある程度コーディングが進んでいくようになりますので、ソース
コードの管理をきちんとやらなくてはなりません。そのために
パッケージマネージャとカテゴリーマネージャを決め、その人に
それぞれのコードの管理をお願いしたいと思います。
- パッケージマネージャ
- パッケージ全体の進行の把握。
- パッケージのバージョン管理。
- パッケージ内カテゴリの整合性の検査。
- パッケージソースコードの品質管理。
- カテゴリーマネージャ
- カテゴリーの進行の把握。
- 必要なクラスの設計。
- カテゴリーのバージョン管理。
- カテゴリーソースコードの品質管理。デバッグなど。
3.3.1.バージョン管理
バージョン管理についてですが、ライブラリバージョンをメジャー
バージョンとし、現在0とします。パッケージごとにマイナーバージョン
を振ります。現在を0.1とします。パッケージ相互の関係がありますので、
同じマイナーバージョンのコードは互換性を持つ必要があります。つまり、
他のパッケージから参照されるクラスの仕様を変更し、インターフェースが
変わる場合(再コンパイルが必要な場合)新しいマイナーバージョンを請求
します。カテゴリーバージョンはさらにその下に位置します。パッケージ
内の他のカテゴリーから参照され、その仕様が変わる場合バージョンを
請求します。現在を0.1.1とします。カテゴリー内のクラスはさらに
下のバージョンコードを持ちます。0.1.1.1とします。ソースコードは
同じクラス定義の元での改訂(レビジョン)をABC...をつけて表現します。
オブジェクト入出力様式は同様に独自のバージョンを持っています。
こちらは通し番号で0から順に増加します。ファイル中に保存されたり、
ソケットを通して通信され、受信時に読み取り方法を判断するのに
使われます。
3.3.2.コード品質管理
書かれたコードの品質を管理します。品質として次のようなものが
考えられます。
- エラーを含まないこと。
- 本当の意味ではこれは大変難しいことですが、少なくともコンパイラ
などが警告を含むエラーメッセージを発行しないコードにしておくことは
必要です。例えばWarningだからまあいいかと思ってほっておいたものが
実は深刻な問題を引き起こすことがあります。
- どの計算機でも変更なく動くコードになっていること。
- KONOEではできるだけ機種依存性を排除したコーディングを行なう
努力をしています。システムサービスやコンパイラオプションなどで
必然的に発生しうる部分もソースコードやMakefileの書き換え無しで
吸収することを目指しています。
- コメントに必要な情報が含まれていること。
- 最近のプログラム言語ではプログラム自身の可読性はずいぶん向上
しています。変数のスコープなども含め、ソースを読むことがやりやすく
なっています。しかし、例えばクラス設計で期待された機能がまだ実装
されていない場合など制限事項はソース中にもコメントするべきでしょう。
また、修正を加えた場合、その範囲に、作業者、日付、理由、措置を
記入しましょう。(レビジョン)
- 不必要なコードを含まないこと。
- 例えばデバッグの時に用いたcoutへの書き出しなど、製品として
公開する場合には必要ないものは削除するか、必要な措置をしてそれが
出てこないようにします。コメントアウトするか条件コンパイルを
用います。

[activity/workshop_dec97.html] Last Modified : 02-Dec-1997.
KONOEコラボレーション
konoe-req@konoe.kek.jp