［Jude開発記］

はじめに

去る1999年7月30日に私達は，Jude(Java and UML Developers' Enviroment)というUMLダイヤグラムエディタをフリー公開しました。Judeは、Java^TM言語とUML(Unified Modeling Language)によるオブジェクト指向設計を支援するツールです。ここでは、Judeの設計、方針、苦労話、ぶつかった問題などなど、公開に到るまでの記録を開発事例として紹介します。オブジェクト指向開発を実際に行っている方々、特にJavaを利用して対話型アプリケーションを作成する際のヒントになれば幸いです。

開発動機

1997年12月、JOMT(ジョムト)というコードネームでJudeの開発プロジェクトはスタートしました。手軽に使えるOMTツールがなかったことGUIを持つグラフィックアプリケーションを一度作って見たかったこと、javaが盛り上がっていたこと、などが開発の動機になっています。

JOMTという名前からも分かるように、そのころまだ UML は成熟しておらず、OMTが最も名の通った方法論だったのです。開発後期に、JOMTはJudeと改名しました。

開発方針

最初に以下の方針を立てました。

1. Javaによるオブジェクト指向開発をサポートすること
2. 開発者が使いやすく、開発者の好みに対応でき、スムーズにデスクトップの一員となれるツール
3. Javaにコミットすること、Javaで開発すること、およびJavaをサポート言語の中心にすることに関しては疑問を抱かないこと
4. JFC(Swing+Java2D)を利用して、クールなルックスにすること
5. 日本初、日本発、のUMLエディタとなること
6. 再利用可能なオブジェクトを、フレームワークとして抽出すること

アーキテクチャ

【フレームワーク】
最初からアプリケーションを作るのではなく、最初にMVCフレームワークを作成することから始めました。あわよくばJudeだけでなく、今後作るアプリケーションの土台を作ろう、という目論見です。おそらく、このようなアプローチは最近はよく行われているものだと思います。どのようなアプリケーションでも、必ず再利用可能な可能性がある部品が作成されます。レイヤーを明確に区切ることで、意識的に再利用部品をメンテナンスすることができます。

汎用GUI MVCフレームワーク

このフレームワークは、Golf(ゴルフ)と名付けました。GolfはGraphics-Oriented Lightweight Frameworkの略です。基本的にJDK1.2上(Swing、Java2Dを含む)に、MVCを意識したフレームワークを構築しています。

フレームワークとして取り組んだ点は、

• MVC型のフレームワーク
• 無限回Undo/Redoを最初から考慮した設計
• カレント状態に応じたメニュー項目の非活性化(かすれ)
• スクリプティング言語(Python)によるAPI
• Java2を最大限利用する

Golf概要図

(図をクリックすると拡大表示されます)

以下に、クラス図の中の代表的なクラスについて、その役割を解説しました。

特に凝った点は、随所にjavaのイベントモデル(MultiCastパターン)を用いている所でしょうか。MultiCastパターンはObserverパターンに比べて型安全なので、多くの場面で有用でした。

例えば、モデルからビューの更新や、GUIイベントのCommandイベントへの変換等で使用しています。(MultiCastパターンについては、お世話になった本〔4〕を参照)

【Undo/Redo】
Undo/Redoの実装としては、GoFのCommandパターン、Mementoパターンを思い出す方が多いと思います。これは、CommandクラスのメソッドとしてdoIt()、undoIt()、redoIt()を持たせるものです。

しかし、この方法だとCommandサブクラス実装者に負担が掛かります。また、コマンドによってundoできるものとできないもの、という不整合も起こりがちです。

そこで、Golfでは、データ管理の責任者であるEntityStoreが一括してUndo/Redoの面倒を見てくれるようにしました。EntityStore内のデータに対する編集は、追加、削除、修正に分類されてトランザクションごとに履歴として記憶され、1トランザクションをundo/redoの単位としました。この手法は、javax.swing.undoパッケージのクラスの仕組みにうまく載せることができました。

Undo可能な編集は、1つのUndoableEditとしてまとめられ、UndoManagerへ投げられます。ここでもMultiCastパターンが登場します。

【モデルとそのFacade】
UMLを表現するモデルを自分達で新しく構築するのは困難であり、Rational社より公開されているメタモデル仕様を忠実に実装しました。

メタモデルでは、多重継承が使用されているところがいくつかあります。ところが、Javaは多重継承を許さないため、すべてのモデルに対して(javaの)インターフェースを作成して、対応することにしました。

モデルはこれで整うのですが、実際これを利用するにはまだ複雑でした。例えばクラスのモデルをひとつ作成するだけでも、親のパッケージモデルとの関連をつないだりなど複数の作業を行わなければなりません。そのため、メタモデルの複雑な構造をカプセル化し、モデルの利用を簡単に行うためのモデルのFacadeを作成しました。それは以下のような役割を持ちます。

• メタモデル内の整合性を保つ
• EntityStoreデータベースへのモデルのadd、modify、remove処理の管理

【モデル情報、図情報、ビュー情報の関連】
Judeで作成するファイルに保存するデータとしては、上記のモデルの情報と、またそのアイテム(表示される絵)の位置情報など図の情報とがあります。

MVCにおいて、MとVをわけて考えようという思想と同様に、モデル情報と図情報をわけて考えました。

ModelElement、Presentation、Diagramはモデルに属し、永続化可能なオブジェクトです。これに対して，ViewElementはテンポラリな情報であり、ModelElementとPresentationから組み立てることができます。

ここで要求されることは、

• モデル情報(ModelElement)が変更されたときの図情報(Presentation)やビュー(ViewElement)の更新
• 図情報(Presentation)が変更されたときのビュー(ViewElement)更新
• 図情報(Presentation)の一部が変更されたときの他の図情報(Presentation)の追従
• 図(Diagram)の一部をCut、Copy、Paste、Deleteするときの整合性維持

• 各要素の更新はObserver-Observableで扱う
• UMLメタモデルの複雑な構造をビューがあまり意識しなくていいように図情報をできるだけ単純な構造にする
• Presentation間での両参照をサポートする機構を上位クラスに用意する
• トランザクションIDを利用して不必要な更新処理をまびく

【自動レイアウト】
自動レイアウトは、ユーザが描いたクラス図を適当に美しく配置しなおしてくれる機能です。ここでは、クラスなどのアイテムを先に配置し、その後関連線などのアイテム間の線を整えるという方法をとりました。アイテムの配置方法は、

1. ツリー構造のレイアウト
2. 関連関係のあるもののレイアウト
3. 全体のレイアウト

自動レイアウトはまだまだ研究の余地があります。「綺麗」という判断基準が見る人によって違うのも、この問題を難しくします。将来は、幾つかの配置ポリシーやパラメータをユーザに選んでもらうような方法にして行きたいと思っています。

【JavaCCの利用】
RationalRoseで提供されているファイル(mdlファイルなど)の読み込みには、パーサを用意する必要がありました。これには、JavaCCを利用しています。JavaCCを使えば、一から自分で構文解析のコードを書くよりは楽です。しかし、JavaCCはかなり大きなコードを吐き出すので、その結果JavaCC から作成されたコードは、Jude全体の1/7のステップ数をしめたことには驚いています。

【ユーザーインターフェースの構築】
リソース(テキストファイル)を読み込み、それをもとに自動的にメニュー、ボタン、ツールバーを構築するクラスを作成しました。コンパイルをせずに、リソースファイルを編集するだけでメニューの構成を変更でき、デバッグコマンドの追加などにも役にたちました。

画像の加工

ロゴ、アイコンなど画像はすべてチーム内で加工されました。特に、ロゴ(Jude Home Pageの先頭)は開発者みんなが墨と筆で書道を行い、スキャナーでとりこみ、コンテストしました。

開発プロセス

開発の工程管理、成果物の指針は、NJKのDropを採用しました。開発を始めた時点で、成果物となる仕様書の書き方や項目について、日本語で規定していたオブジェクト指向方法論がDropでした。現在では、Rational Unified Processなどのメジャーでスタンダードなプロセスも候補になるでしょう。

開発ツール

【Java開発環境】
開発マシンは、LANに繋がれたUNIXとWindows NT、95、98です。Java 環境はJDK1.2+エディタ(mule、meadow)という原始的な組合せです。IDEは特に使用しませんでした。

【ソースコード構成管理】
CVSを使用しました。特に開発マシンがUNIXとWindowsが共存していたので、UNIX上にCVSリポジトリを置き、sambaでファイル共有しました。また、仕様書類もすべてテキストファイルを基本として CVS で管理しました。

最近、WinCVSというフリーの大変使いやすいGUIベースのCVSツールが出ています。sambaとの相性もよく、改行などのWindows<->UNIX変換も自動的に行ってくれるようです。さらに、UNIX上にはApacheを置いて、仕様書をWindowsのブラウザから見えるようにしました。

【設計ツール】
UMLダイヤグラムの作成に、Rational Rose 98を使用しました。市販のオブジェクト指向CASEツールとしては最も高機能で安定しているものです。Judeは最終的にはこの商品のライバルとなることを目指していますが、まだ道のりは遠いようです。コードができ始めてからは、javadocを毎晩走らせ、HTMLでのドキュメントを更新しました。共通で使用するパッケージの仕様などがブラウザで見れて便利でした。また、javadocにはDocletという機能があり、HTML 以外の形式でもソースコードから設計情報をとり出せるようになっています。RoseDocletを自作して、javaソースからRational Roseのモデルデータを取り出すことも行いました。Rose のリバースエンジニアリング機能でも同等のことができます。

【バグ管理】
メールと組み合わせたGNUのバグ管理ツール、gnatsを使用しました。

お世話になったページ

開発にあたって、よく参照したページを紹介します。

お世話になった本

開発中に特にお世話になった本を挙げておきます。最初の2つはUMLメタモデルを理解、解釈する際に読みました。

おわりに

以上、駆け足でJudeの開発を振り返って書いてみました。Judeの無償ダウンロードと機能説明について詳しくは、

https://www.esm.co.jp/divisions/open-sys/Jude/

からどうぞ。

最後に、開発に携わった全員に、それぞれ最も苦労した点をコメントして頂き、クレジットに替えます。

●フレームワークの設計がなかなか固まらず何度もやり直したこと(Javaがすき：Java2D)

●テキスト罫線出力のアルゴリズムの実装は結構苦労した。でもこの機能の設計はなかなか楽しく、わりにいい出来なので満足してます。(ちゃまだ：開発チーフ)

●ダイアグラム上での細かい操作に対応するコマンド機構の設計に悩みました。図情報の複雑さへの挑戦も手強かった。(越前ガニ：Model-View担当)

●苦労した点は、自動レイアウトでの配置位置の決定方法(アルゴリズム決定まで)。どの部分からどのように配置していけば、たいていのケースにおいて綺麗に見えるのかの検討。(りすちゃん：自動配置担当)

●Golfの中でも、UI部分構造を決めるのに苦労した(ような気がする)。(ume：UI担当)

●苦労した(???)点、それは画像アイコン作成。色や見ための統一感。少ないドット数での機能の表現。(GEN：アイコンデザイン担当)

●方針を決める時に、言語は本当にJavaでいいのか悩んだ。C++ならもっと軽快なソフトになったのでは、と途中何度も思ったが、JDK1.2が提供してくれたライブラリのおかげで、かなり開発は楽だった。(KH：プロジェクト管理担当)