 |
|
PLAINセンターニュース第157号 |
|
|
PLAINセンターニュース第157号 |
|
村田 健史 （前々号, 前号 から続く） 3.2 STARS1 & STARS2：オブジェクト指向とオブジェクト指向開発技法 私事で恐縮であるが、筆者が STARS の開発を始めたのは愛媛大学工学部情報工学科に所属していた約 10 年前である。（現在は、同大学の総合情報メディアセンター所属。）そのころ情報工学的な研究テーマを探していた筆者は、ソフトウェア技法を生かしたアプリケーション開発に注目した。ちょうど同じ時期に、筆者の研究室に１年間、ブラジルから留学生がやって来た。Julio Gomes 君というブラジルのある大学の情報工学系の学部 4 年生であった。私が宇宙関係の研究をしていると話すと、「具体的にどんなアプリケーションが作りたいのか説明してくれ」と質問してきたので、「今、太陽地球系物理分野では、ISTP（International Solar-Terrestrial Physics）観測計画という国際プロジェクトが進められており、すべての衛星観測データを同時に解析できるツールが作りたい」と言うと、彼は「オブジェクト指向技術を使えば（何でも）できる」と主張した。オブジェクト指向という言葉は聞いたことがあったが、それが何であるのか何ができるのかを知らなかった私は、当時 C マガジンに連載されていた「憂鬱なプログラマのためのオブジェクト指向」という記事を読み始めた。（その後、オブジェクト指向についての様々な教科書を読んだが、今でもこの教科書が入門書としては一番よく書けていると思う。） 本稿でオブジェクト指向について解説するのは適切ではないと思うので割愛するが、一言で説明するなら、「オブジェクト指向とはプログラミング言語ではなく、モノの見かた・とらえ方」であると言えるだろう。「世界をオブジェクトとしてとらえるためのプログラミング技法」といってもよいかもしれない。マンガの世界では、「キャラがたつ」という言葉があるそうであるが、オブジェクト指向も同じである。まず、登場人物（クラス）が決まり、複数の人物がかかわりあいながらものがたりは進行する（プログラミングが行われる）。面白い（よくできた）マンガ（プログラム）ほど、キャラクター（クラス）の振る舞いがユニークで、また、“よくできている”のである。オブジェクト指向プログラミングでは、どんなアルゴリズムを作るかよいうことよりも、どんなクラスを作るということがまず要求される。アルゴリズムは、クラスというキャラクターの行動パターンの一つを現す手立てでしかない。 Julio Gomes 君と私、そして当時、大学院前期課程（修士課程）の学生であった山口弘市君の3人は、オブジェクト指向開発技法（OMT という技法）にのっとって、STARS を開発することにした。（実は、STARS を命名したのは私ではなく、Gomes 君と山口君の二人である。）まず、約半年をかけて太陽地球系物理分野の観測データのクラス設計とオブジェクト図を行った。これは、オブジェクト指向開発技法では最も基本的な作業であるが、われわれはその作業に、半年間をかけたのである。我々がその半年間に行ったのは太陽地球系物理観測データに共通する特徴とデータごとに独自の特徴を区別し整理することであり、二人の学生はその間、1行もプログラムを書くことはなかった。このことはオブジェクト指向開発技法に詳しい方であれば特に驚かれないであろうが、半年間、二人の学生が1行もプログラムを書かないことに、指導教官としてはかなりあせった記憶がある。その結果得られたオブジェクトモデルが図10 である。
四角い箱がクラスで、属性や操作（メソッド）は省略した。半年間かけて作ったモデル図がこれほどシンプルでることに驚く方もおられるかもしれない。しかし、この図で示されているものは、「3人が観測データというものをどのようにとらえたのか」という姿である。クラス図は現在の STARS はもう少し複雑になっているが、基本的なモデルは変わっていない。おそらく、STARS が存在する限りは、このモデルに基づいた開発が行われ続けるであろう。それこそが、オブジェクト指向のよい点なのである。 別のオブジェクト指向の特長、つまりオブジェクト指向が太陽地球系物理観測データに向いている点の一つとして、クラスの隠蔽がある。クラスの隠蔽とは、クラスを作る人（キャラをたてる人）はそのクラスに責任を持つが、そのプログラムでクラスを使う人（ストーリーを考える人）はクラスの中のプログラムを理解する必要がないということである。これは、地方大学でプログラム開発を行う際には、絶好の機能である。地方大学では多くの学生が修士課程に進学せず、卒業論文を書いたら研究室を離れてしまう。その際、もっとも問題になるのが、プログラムの引継ぎである。しかし、オブジェクト指向言語でプログラムを開発していれば、指導教員はクラスの中身を理解する必要はない。たかだか 1年足らず研究室に所属した学生が書いたプログラムをすべて理解することは容易ではない。（それぐらいなら、自分で一から書いたほうが早い。）しかし、オブジェクト指向を採用すれば、その学生が責任を持ってクラスを実装することで、指導教員はその属性と操作、つまりキャラクターさえ理解していれば、あとはそのクラスを使うだけでよいのである。 また、オブジェクト指向の継承という概念も、太陽地球系物理観測データに活用できる概念であった。なにしろ、この分野は観測データの種類が多く、またデータを管理している組織がばらばらなのである。一つ一つのデータに対して独立にプログラムを作っていたのでは、プログラム管理が崩壊することは目に見えている。たとえば、今、STARS では 150 種類のデータを扱っているが、150 のデータ I/O 関連のプログラムをすべて管理することは現実的ではない。継承という概念は、「共通な特徴と独立な特徴を区別しましょう」という考え方である。AKEBONO/PWS と GEOTAIL/PWI/SFA はともにダイナミックスペクトルであるが、観測する衛星は異なっている。GEOTAIL/PWI/SFA と GEOTAIL/MGF/FX ではデータはまったく異なるが、同じ衛星による観測データである。プログラムから見た場合に、どちらが同じグループに属するのかを考えるのが、オブジェクト指向的な考え方である。別の例を挙げてみよう。たとえば衛星軌道データと磁場データは、ともにベクトルデータであるという共通点がある。しかし、軌道上に物理量をマッピングすることはあっても、磁場データ上に別の物理量をマッピングすることはないという点では異なる。一つ一つのデータの共通点がある場合にはそれを親クラスに集約してしまうことができるのがオブジェクト指向であり、これによって、150 のデータを管理することが可能となったのである。 このようなクラス設計を経て、STARS1 は完成した。ただし、STARS1 開発の主目的は、解析ができるツールを実装しようというよりも、オブジェクト指向でどこまでできるかという筆者の挑戦であった。そのため、STARS１ がデータ解析に利用されることはなかった。それを反省して STARS2 では、GEOTAIL 衛星データを中心に、いくつかのデータプロットと解析を行うツールとして実装を行った。STARS2 は、数名のユーザに利用されたが、普及することはなかった。その一番の理由は、STARS1/2 では、メタデータを取り扱うデータベースを必要としたからである。STARS では、データファイルをユーザに意識させない。データはデータクラスから GetData 関数により取得するというコンセプトで設計した（図11）。
これは、データクラスに開始時刻と終了時刻、およびサンプリングタイムを渡すとデータが任意の時間幅で返るという仕組みを作りたかったからである。そのために、ユーザは、データ解析を行う際にはデータファイル情報（ディレクトリ情報）をクラスに渡す必要がある。STARS2 では、Microsoft 社のポータブル DBMS である ACCESS によってデータファイルのディレクトリ情報を管理した。そのため、データベースへの登録はユーザが自分で行う必要があったこれが、STARS 普及の最大のネックとなった。この問題を解決するため、STARS 計画は STARS3 へと進むことになる。 （次号 に続く）
|
|
|||||||||||
 |
||||||||||||
