システムやアプリケーションを生成するプログラムを見て、その機能を理解するには、プログラム言語に関する知識が必要である。プログラムの内容が高度化すると、そのような知識を持つ者にとっても、これを理解するのは容易ではない。したがって、プログラマが第三者に自らのプログラムについて理解させるには、分かりやすい説明が求められる。プログラムの説明は、たとえば、長くメンテナンスされながら使用するシステムやアプリケーションでそのメンテナンス作業が第三者によって行われる場合、また、他の分野への応用が期待されるプログラムでその応用が第三者によって行われる場合等いろいろなケースで必要となる。
高度で複雑なシステムやアプリケーションは大規模なプログラムからなることが多く、複数の開発者によって共同で作成されるのが通常である。開発者はそれぞれ自らの専門分野を分担してプログラミングを行う。このような開発形態では、各開発者それぞれがプログラムの全体の内容を細部まで理解する必要はなく、機能の概要を理解していればよいので、作業効率が向上する。したがって、開発者間の情報共有等の目的で、自分の担当するプログラムの機能について他の共同開発者に説明する場合も、分かりやすい説明が求められる。説明が難解で理解に時間のかかるものであってはこのような開発形態をとる意味がない。
そこで、近年、プログラム言語を用いずに簡潔にプログラムの内容を表記するために、UML(Unified Modeling Language)が広く普及している。これは、世界共通の統一表記方法で、JAVA(登録商標)に代表されるオブジェクト指向プログラム言語の表記方法のデファクトスタンダードとして使われている。オブジェクト指向とは、何らかのデータと、それを操作するためのメソッドの組み合わせをオブジェクトと呼ばれる1つのまとまりとする考え方である。オブジェクトを抽象化したもの、または同じ特性を持ったオブジェクトの集合はクラスとして表わされる。クラスは、個々のオブジェクトを特定するフィールド、および操作を表わすメソッドにより記述されるオブジェクトの設計図に相当するものである。
図28は、「Directory」クラスのオブジェクトについてJAVA(登録商標)で記述されたプログラムを表わしたものである。この第1のプログラム200は、JAVA(登録商標)で記述されたプログラムの一例であり、これを用いてプログラムの構造について説明を行うことにする。図28に示すように、この第1のプログラム200はコメント文201とクラス定義文202とで構成されている。クラス定義文202は、変数の初期化を行わせる文203、クラスのフィールドを記述する文204およびメソッドを記述する第1のメソッド定義文205と第2のメソッド定義文206とで構成されている。「Directory」というクラス名207は、クラス定義文202のはじめに定義されている。したがって、このクラス定義文202により、この「Directory」クラスのオブジェクトが保持するフィールドは「java.lang.String」クラスのオブジェクト「name」、「File」クラスのオブジェクト「htmlFile」および「txtFile」であり、メソッドは「listFiles」および「getName」であるということが表わされている。「java.lang.String」はJAVA(登録商標)の標準API(Application Program Interface)に含まれるクラスである。標準APIとはJAVA(登録商標)の環境下でシステムに依存せずに使用できるオブジェクトの集合である。
図29は、「File」クラスのオブジェクトについてJAVA(登録商標)で記述されたプログラムを表わしたものである。図28と共に説明を行う。この第2のプログラム300は、第1のプログラム200のフィールドが保持する「File」クラスのオブジェクトついて記述されたものである。図28と同様に、この第2のプログラム300はコメント文301とクラス定義文302とからなる。また、クラス定義文302は、変数の初期化を行わせる文303、クラスに含まれるフィールドを記述する文304およびメソッドを記述するメソッド定義文305とで構成されている。「File」というクラス名307は、クラス定義文302のはじめに定義されている。したがって、このクラス定義文302により、この「File」という名前のオブジェクトの保持するフィールドは文字列オブジェクト「name」であり、メソッドは「getName」であるということが表わされている。
図30は、図28のプログラムをUMLで表記したものである。「Directory」クラスのUML表記351は、名前コンパートメント352、フィールドコンパートメント353およびメソッドコンパートメント354という3つの四角で構成されている。このようにUMLを用いると、図28のプログラムと比較して、より簡単にプログラムの構造を表示できるようになっている。
図31は、図29のプログラムをUMLで表記したものである。図30と同様に、「File」クラスのUML表記361は、名前コンパートメント362、フィールドコンパートメント363およびメソッドコンパートメント364で構成されている。図30および図31のようにUMLを使用することにより、オブジェクト指向の言語によって記述されたプログラムが簡潔に表現できるようになる。したがって、第三者にプログラムの内容について説明する際には、これらを使用して視覚的に理解しやすい説明を行うことができる。
しかしながら、説明するプログラムが膨大なものになると、その内容をすべてUMLのような表記方法で表わすというのは手間のかかる作業である。このような作業は、プログラムの説明を行う者、つまりプログラムの開発者にとって大きな負担になってしまう。
そこで、オブジェクト指向のプログラム言語で記述されたプログラムを解析して、説明用の表記方法にして表示するようにした装置が提案されている(たとえば特許文献1参照)。この第1の提案の装置は、プログラムからクラス名、フィールド名、メソッド名、クラス間の関係およびフィールドとメソッド間の関係を抽出し、これらを色を変化させた線、矢印および矩形で表示するようになっている。したがって、プログラム言語で記述されたプログラムの内容を視覚的に理解しやすく表示することができる。
特開平11−095990号公報(段落0018、図1)
図1は、本発明の一実施例によるプログラム視覚的表示装置の構成の概要と視覚的に表示させるプログラムとを表わしたものである。プログラム視覚的表示装置401は、JAVA(登録商標)によって記述されたプログラムを読み込む入力部402、そのプログラムを構成図として視覚的に表示する出力部403、およびプログラムから構成図を完成させる処理を行う処理部404とで構成されている。
処理部404は読み込んだプログラムのデータ構造を解析するためのプログラム解析部410を備えている。このプログラム解析部410は、一時記憶部411と接続されており、解析処理によって導き出されたデータがここに一時記憶されるようになっている。処理部404には、さらに、オブジェクトのクラス名と対応する図形のファイルパスを記憶するクラス名記憶部412や、図形データをマッピング形式で記憶する図形データ記憶部413が備えられている。また、プログラム構成図を完成させる図形表示処理部414、プログラム中の英語を自国語に翻訳する翻訳部415を備えられている。読み込むプログラムは、図28に示した「Directory.java」という第1のプログラム200、および図29に示した「File.java」という第2のプログラム300として説明を行うことにする。ここで、「.java」は、JAVA(登録商標)で記述されたプログラムにつけられる拡張子である。入力部はメディアに記憶されたこれらのプログラムを読み出す装置である。
図2は、このプログラム視覚的表示装置の回路構成の概要を表わしたものである。図1と共に説明を行う。プログラム視覚的表示装置401は、CPU(中央処理装置)421を備えている。CPU421は、データバス等のバス422を通じてプログラム視覚的表示装置401内の各部と接続されている。このうち、ROM(リード・オン・メモリ)423は、不揮発性データあるいは制御プログラムを格納している。RAM(ランダム・アクセス・メモリ)424はCPU421が各種制御を実行する際に必要となるデータを一時的に格納するようになっている。また、一時記憶部411はこのRAM424の領域の一部を使用するようになっている。ハード・ディスク・ドライブ(HDD)425は、このプログラム視覚的表示装置401の制御を行うためのOS(Operation System)やアプリケーションプログラムが格納された磁気記憶装置である。このハード・ディスク・ドライブ425の一部領域はクラス名記憶部412および図形データ記憶部413として使用されている。表示部426は液晶あるいは有機パネルを使用したモニタを備え、情報を視覚的に表示するようになっている。FDD(フロッピー(登録商標)・ディスク・ドライブ)427は、図示しないフロッピー(登録商標)ディスクを介して、外部からプログラムを読み込んだり、書き込んで外部に情報を出力するようになっている。操作部428は、キーボード、マウスおよびスイッチボタンを備え各種操作を受け付けるようになっている。通信部429は、LAN(Local Area Network)やインターネットに接続し、外部と通信を行っている。
図3および図4は、プログラム視覚的表示装置がプログラムファイルを読み込んで図形を表示する処理の流れを表わしたものである。図1と共に説明を行う。プログラム視覚的表示装置401はこれから処理する第1および第2のプログラム200、300を入力部402で読み込み、これらを処理部404に送る(ステップS101)。第1および第2のプログラム200、300を受け取った処理部404では、プログラム解析部410により、ファイルの解析処理が行われる(ステップS102)。翻訳部415による翻訳を行うかどうかは、処理のはじめに操作部428によりユーザが設定できるようになっている。ここでは、翻訳処理を行う設定として説明を行う。
図5は、プログラム解析部による第1のプログラムの解析結果を表わしたものである。図28および図1と共に説明を行う。プログラム解析部410は第1のプログラム200から、クラス名、フィールドおよびメソッドの抽出処理を行う。たとえばクラス名207を抽出するには、直前にある「class」というキーワードを検索して、それに続く「Directory」をクラス名と判断して抽出するようになっている。フィールド、メソッドも同様にこれらの前後にあるべきキーワードを検索して、抽出されるようになっている。この抽出結果から図5に示した第1のプログラム解析結果503が得られるようになっている。
図6は、プログラム解析部による第2のプログラムの解析結果を表わしたものである。第2のプログラム解析結果504は、図5に示した第1のプログラム解析結果503と同様な処理により得られるようになっている。
図3に戻って説明を続ける。ステップS102のプログラム解析処理で得られた解析結果は、一旦、一時記憶部411に格納される(ステップS103)。さらに、一時記憶部411に格納されているオブジェクトのクラス名およびデフォルトで指定されている図形データとの対のリストからなるGUI(Graphical User Interface)画面を表示部426に表示する。そして、操作部428によりユーザの図形データの変更要求を受信し、ユーザにより選択された図形データに変更する(ステップS104)。一時記憶部411および図形データの変更処理について説明する前に、図形データ記憶部413についての説明を行う。
図7は、図形データ記憶部に格納されている図形データファイルの例を表わしたものである。このように図形データ記憶部413には複数の互いに異なる形状の図形データが格納されている。これらの図形データは、ビットマップ形式、JPEG(Joint Photographic Experts Group)形式、あるいはGIF(Graphics Interchange Format)形式等の各種の画像形式で表わすことができる。この図形データ記憶部413に格納された図形データ以外で利用したい図形データがあれば、追加することも可能である。また、この図形データ記憶部413は実際に1つである必要はなく、図形データは複数箇所(たとえばウエブ上の特別のサーバ内を含む)に散在していてもよい。図形データが記憶された複数の記憶領域を、実質的に1つの図形データ記憶部413として扱うことにする。
ここで、第1〜第3の図形データ5161〜5163はJAVA(登録商標)の標準APIに含まれるオブジェクトに対応する図形の一部である。これらについては、予めオブジェクト名を貼付したものを完成済み図形データとして用意し、必要以上の解析を抑制して処理効率を向上させるようにしている。また、第4〜第6の図形データ5164〜5166は日本語に翻訳されたオブジェクト名が貼付されたもので、日本語翻訳を行う設定の場合に使用する完成済み図形データとなっている。第7〜第9の図形データ5167〜5169はオブジェクト名はまだどのクラスのオブジェクトにも対応付けられていない未完成の図形データである。
図8は、クラス名記憶部に格納されているオブジェクトのクラス名と対応する図形のファイルパスの例を表わしたものである。完成済み図形データファイルパス517と未定義図形データファイルパス518とからなっている。完成済み図形データファイルパス517ではオブジェクトのクラス名と、図7に示した第1〜第6の図形データ5161〜5166のような完成済み図形データとがそれぞれ結びつけられている。ファイルパスは英語表記および日本語表記ごとに格納されている。また、未定義図形データファイルパス518には、第7〜第9の図形データ5167〜5169のような未完成図形データのファイルパスが、クラス名が定義されていない(null)状態で格納されている。
図9は、図3のステップS103の処理で一時記憶部に格納されたデータを表わしたものである。図5および図6に示したような解析結果が、このように一時記憶部411には、オブジェクトのクラス名をキーとして、フィールドのクラス名の集合、およびメソッド名の集合といったデータが格納されている。図に示すように、一時記憶部411はさらに、図形データ、図形データの縦横比および完成済み図形データの情報を格納する領域を持っている。この段階で、これらの情報はそれぞれ格納されていないので、詳細については後述する。
図10は、図3のステップS104における図形データ変更前のGUI画面を表示した表示部を表わしたものである。表示部426は、オブジェクトのクラス名およびそれに対応する図形データと、これらの図形データの変更要求を受け付ける第1および第2の図形変更アイコン5191、5192とからなっている。「Directory」クラスおよび「File」クラスはぞれぞれプログラム視覚的表示装置401に新たに入力されたものなので、クラス名がまだ定義されていない。そのため、図形データには初期図形として図形データ記憶部413の未完成の図形データの1つが仮に割り当てられ表示されている状態である。
ユーザは操作部428の操作により、画面上の第1および第2の図形変更アイコン5191、5192を押し、これらの図形を適切なものに変更する。第1あるいは第2の図形変更アイコン5191、5192が押下されると、表示部426には図8の未定義図形データファイルパス518に格納されたファイルパスを利用して、図7に示した図形データ記憶部413の記憶するクラス名が未定義の図形データの一覧が表示されるようになっている。ユーザはその中から任意で図形データを選択することができる。
図11は、図3のステップS104における図形データ変更後のGUI画面を表示した表示部を表わしたものである。このように「Directory」および「File」クラスのオブジェクトにはそれぞれユーザにより、適切な図形データが選択され、変更処理が行われる。これらの処理は、図9に示す一時記憶部411の「図形データ」欄にも反映されるようになっている。
図3に戻って説明を続ける。図形表示処理部414は、このように一時記憶部411に格納された図形表示の対象となるオブジェクトの中から1つを選択して読み出す処理を行う(ステップS105)。ここでは、ABC順にオブジェクトが選択されるとするが、もちろん、どのような順番でもよい。そこで、まずクラス「Directory」オブジェクトが選択されることになる。次に、そのオブジェクトに対する図形データの縦横比が一時記憶部411に格納済みかどうかの判断処理を行う(ステップS106)。まだ格納されていないので(N)、図形データのサイズの縦横比を計算して、その計算値をオブジェクトのクラス名をキーとして一時記憶部411に記憶する処理を行う(ステップS107)。縦横比とは、オブジェクトの保持するフィールドとして保持するオブジェクトの数やそれに対応する図形によって決まる値である。たとえば、「Directory」オブジェクトでは、フィールドに「java.lang.String」クラスのオブジェクトと、「File」クラスの2つのオブジェクトを持つ。したがって、フィールドオブジェクトの総数は3である。また「File」オブジェクトでは、フィールドオブジェクトの総数が1である。このように総数が3および1のときは、縦横比はともに「1:1」が適当である。ただし、縦横比はフィールドオブジェクトに対応する図形データの形状にも依存する。縦横比の設定方法については、詳細を後述することにする。ステップS107で設定された縦横比は、図9に示す一時記憶部411の「図形データの縦横比」欄に反映されるようになっている。
その後、先程選択したオブジェクトのクラスに対応する完成済み図形データが存在するかどうかの判断処理を行う(図4ステップS108)。これはオブジェクトのクラスがJAVA(登録商標)の標準APIに含まれるか、あるいはすでに対応する図形データが自装置で定義されている場合、重複して完成済み図形データを作成する処理を避けるためである。完成済み図形データが存在すれば、図8のクラス名記憶部412の完成済み図形データファイルパス517に、一致するオブジェクトのクラス名が格納されている。この説明では、日本語への翻訳処理を行うことになっているので、完成済み図形データファイルパス517中の、日本語図形データのファイルパスが存在するかどうかで、完成済み図形データの存在を判断するようになっている。
一致するものが格納されていなければ(N)、そのオブジェクトがフィールドに保持する全オブジェクトに対する完成済み図形データが存在するかどうかの判断処理に進む(ステップS109)。「Directory」はクラス名記憶部412の完成済み図形データファイルパス517に記憶されたクラス名に一致しない。このため、「Directory」クラスのオブジェクトがフィールドに保持するオブジェクトのクラスに対して、完成済みの図形データが存在するかどうかを判断する処理に進む。フィールドに保持されるオブジェクトのクラスで「java.lang.String」は、クラス名記憶部412の完成済み図形データファイルパス517に記憶されたクラス名に一致する。一方、「File」は一致するクラス名が存在しない(ステップS109:N)。そこで、完成済みの図形データが定義されていないオブジェクトの中から、1つオブジェクトを選択して(ステップS105)、順次同様の処理を行う。
この場合、「File」クラスのオブジェクトが選択される。縦横比が格納されていないため(ステップS106:N)、対応する図形データの縦横比を計算する処理を行う(ステップS107)。ここでは「1:1」と計算され、この値が一時記憶部411に格納される。「File」クラスに対する完成済み図形データが存在しない(ステップS108:N)が、「File」クラスが保持する全オブジェクト、すなわち「java.lang.String」型オブジェクトに対する完成済み図形データは存在する(ステップS109:Y)。そこで、「File」クラスのオブジェクトの図形データの左上にクラス名を貼付する(ステップS110)。次に、保持する全オブジェクトの図形データを内部に貼付する(ステップS111)。このとき、「File」型オブジェクトおよび「java.lang.String」型オブジェクトのそれぞれの図形データの縦横比をできるだけ保った状態で、両図形を伸縮させながら処理を行う。最後にメソッド名を図形の下部に貼付する(ステップS112)。クラス名およびメソッド名の貼付の際は、翻訳部415による翻訳処理が行われる。その後、「File」型オブジェクトに対する完成済み図形データを一時記憶部411の完成済み図形データ欄に格納する(ステップS113)。さらに、この完成済み図形データを図7の図形データ記憶部413に格納し、そのファイルパスをクラス名記憶部412の完成済み図形データファイルパス517に格納する(ステップS114)。これにより、「File」オブジェクトに対する図形データ作成処理は、2度目以降スキップされるようになる。
図12は、翻訳処理の例を表わしたものである。JAVA(登録商標)によるプログラミングでは、クラス名やメソッド名はスペースを設けず、単語と単語の区切れは大文字で表わされるのが通常である。そこで、その規則に従って翻訳処理例560に示したように、まずは単語に区切る処理を行い、その後、翻訳処理を行うようにしている。
図4に戻って説明を続ける。プログラム視覚的表示装置401では、一時記憶部411が持つ全てのオブジェクトに対する完成済み図形データが揃ったかどうかの判断処理を行う(ステップS115)。完成済み図形データは「File」型オブジェクトに対するものだけなので(N)、ステップS105の処理に戻る。最初に完成済み図形データを持たないオブジェクトとして「Directory」が選択され(ステップS105)、このオブジェクトは図形データの縦横比がすでに一時記憶部411に格納されているので(ステップS106:Y)、保持する全オブジェクトに対する完成済み図形データが存在するかどうかの判断処理に進む(ステップS109)。すでに「File」および「java.lang.String」に対する完成済み図形データが存在するので(Y)、「File」オブジェクトと同様にクラス名の貼付(ステップS110)、図形データを内部に貼付(ステップS111)、メソッド名を内部に貼付(ステップS112)、完成済み図形データを一時記憶部に格納(ステップS113)、および完成済み図形データの図形データ記憶部への格納とそのファイルパスの格納(ステップS114)の処理が行われる。これにより、「Directory」オブジェクトに対する図形データ作成処理も、2度目以降スキップされるようになる。クラス名およびメソッド名貼付の際は、やはり翻訳部415による翻訳処理が行われる。
引き続き再度、一時記憶部が持つ全てのオブジェクトに対する完成済み図形データが揃ったかどうかの判断処理が行われる(ステップS115)。今回は全オブジェクトに対する完成済み図形データが存在するので(Y)、これらを表示部426の図形描画領域に貼り付ける(ステップS116)。完成図形データは表示部426に出力され(ステップS117)、処理を終了する(エンド)。なお、ステップS108で完成済み図面データが存在する場合には(Y)、クラス名の貼付が行われ(ステップS118)、ステップS113へと処理が進むことになる。
図13は、完成図形データが出力された表示部を表わしたものである。表示部426には完成した「Directory」と「File」クラスのオブジェクトに対応する図形データが出力されている。
図14は、全オブジェクトに対する完成済み図形データが存在するときの一時記憶部に格納されたデータを表わしたものである。図形データおよび完成済み図形データには、実際は図1に示したクラス名記憶部412に格納されたそれぞれの図形データへのファイルパスにつながる情報が格納されている。前述した図形データの縦横比は、基本的にその図形の内部に貼付する図形の数、つまりクラスオブジェクト保持するフィールドオブジェクトの数に応じて設定される。1つのときは「1:1」、2つのときは「1:2」あるいは「2:1」、3つのときは「1:1」として上下に3つの図形を配置するようにしてもよい。ただし、この縦横比の設定は、保持するフィールドオブジェクトに対応する図形の縦横比が「1:1」でない場合には、これに対応して変わるのが望ましい。この設定方法は、極端な設定で図形データの形が著しく損なわれない程度に、予めユーザによって決められるものとする。
以上説明したように、本実施例によれば、プログラムに含まれる各オブジェクトに対して、そのクラスに対応した様々な図形データを割り当てられるようにした。これにより、作成したプログラムのデータ構造を視覚的に、分かりやすく表示することができる。従来から、Eclipse(登録商標)ソフトウェアのように、プログラムをUML表示に変換する手法は存在する。しかしながら、UMLやオブジェクト指向の知識を持たない者にとって、線や矩形のみで表現された図形から、プログラムの構造を理解するのは依然容易ではなかった。また、これらの手法では、プログラムに英語で記述されたクラス名やメソッド名を単純表記するにすぎない。したがって、英語になじみのない者にとっては、それぞれの名前から意味や役割を理解するには、翻訳作業が必要であった。JAVA(登録商標)ではクラス名やメソッド名に日本語を表記できる2バイトコードの文字が使用できるものの、使用されることは稀である。しかし、本実施例によれば翻訳部415を使用することで、クラス名およびメソッド名を自国語で翻訳表示することが可能となっている。これにより、オブジェクトの意味や役割をより理解しやすいものとして表示することができる。
入力部402および出力部403はそれぞれFDD427以外にも、メモリーカードのような記憶媒体でデータを出し入れできるものであってもよい。あるいはスキャナやプリンタのような装置で入出力できるようにしてもよい。また通信部429によりデータの送受信をできるようにしてもよい。また、プログラム視覚的表示装置401は、パーソナルコンピュータおよびその上で動作するソフトウェアとして実現することもできる。つまり、図2に示したようなCPU、ROM、RAM等の各部はパーソナルコンピュータが持つ既存のハードウェアにより与えられる。したがって、後はプログラム解析部410および図形表示処理部414による解析処理を行うことのできるソフトウェアがあれば、同様にプログラムの構造を視覚的に表示させることができる。
本実施例のプログラム視覚的表示装置401では、図形データ記憶部413に複数の互いに異なる形状の図形データが格納されているとしている。そして、フィールドのオブジェクトを表わす図形データを、これを保持するオブジェクトを表わす図形データの内部に、両図形を伸縮させながら貼付する処理を行うとしている。このように、貼付の処理を行うときに、図形データの大きさを変更するのではなく、予め複数の大きさの互いに異なる形状の図形データを図形データ記憶部413に格納するようにしておいてもよい。
<本発明の第1の変形例>
JAVA(登録商標)では、同じクラス名が複数存在しても、パッケージによりこれらを区別することが可能である。つまり同じクラス名でも異なるパッケージに属していれば、これらは衝突を起こさないようになっている。たとえば、「ソフトウェアベンダA」および「ソフトウエアベンダB」によって提供された2種類の「ApplicationServer」という同一名のクラスが存在する場合、これらをパッケージを用いて区別することが可能である。プログラム視覚的表示装置401では、このようにパッケージが異なれば、同一名のクラスに対しても別の図形を割り当てて、区別して表示させることが可能である。また、たとえばこれら2つの「ApplicationServer」クラスのオブジェクトが、フィールドにそれぞれ「ソフトウェアベンダC」により提供される同一のオブジェクトを含む場合がある。このように、パッケージが異なるオブジェクトに保持されていても、実質的に同一のオブジェクトに対しては、同じ図形を割り当てて表示させる。このようなパッケージの概念を持ったプログラムを例にしてプログラム視覚的表示装置401の動作について説明を行うことにする。
図15〜図18は、それぞれJAVA(登録商標)で記述された第3〜第6のプログラムを表わしたものである。第3および第4のプログラム713、714はクラスが同じ「ApplicationServer」オブジェクトであるが、パッケージがそれぞれ「com.vender_A」、「com.vender_B」となっている。これらはそれぞれ「com.vender_A.ApplicationServer」、「com.vender_B.ApplicationServer」のようにパッケージ名とクラス名を連ねて表記することで区別される。第5および第6のプログラム715、716はそれぞれクラスが「com.vender_C.WebServer」、「com.vender_C.WebApplication」となっている。
これらの第3〜第6のプログラム713〜716がプログラム視覚的表示装置401に入力されると、図3および図4に示した処理が同様に行われ、図形表示がされるようになっている。実施例と同様の処理については省略し、図3および図4を用いて、第1の変形例におけるプログラム視覚的表示装置401の処理の説明を行うことにする。
図19〜図22は、それぞれ図3のステップS102のプログラム解析処理の解析結果を表わしたものである。第3〜第6のプログラム解析結果723〜726には、それぞれクラス、フィールドおよびメソッドが抽出されたものとなっている。これらの第3〜第6のプログラム解析結果723〜726は一時記憶部411にクラス名をキーとして格納される(図3、ステップS103)。第3〜第6のプログラム解析結果723〜726は、フィールドに「File」クラスのオブジェクトを含んでいる。ここでは、プログラム視覚的表示装置401には過去に「File.java」を入力し、その際に「File」クラスに対して完成済み図形データを作成したものとして説明を行うことにする。新たにプログラム視覚的表示装置401に入力したプログラムが、自装置に完成済み図形データを持たないクラスのオブジェクトを含む場合は、この段階でエラーメッセージを表示部426に出力するか、これからの処理でクラス名だけを貼付した図形を仮に表示させて対応するようにしてもよい。
図23は、図3のステップS104でGUI画面を用いた図形データ変更後の一時記憶部に格納されたデータを表わしたものである。「com.vender_A.ApplicationServer」、「com.vender_B.ApplicationServer」オブジェクトにはそれぞれ異なる図形データが割り当てられている。実際には、一時記憶部411では、図形データの代わりにクラス名記憶部412に格納されたそれぞれのオブジェクトへのファイルパスにつながる情報が格納されている。
図24は、図4のステップS109で全オブジェクトに対する完成済み図形データが存在するときの一時記憶部に格納されたデータを表わしたものである。「com.vender_C.WebApplication」オブジェクトは配列形式であるため、そのオブジェクトの図形データを重ねた状態がわかるようにして表示するようになっている。
図25は、第1の変形例のプログラム視覚的表示装置における完成図形データが出力された表示部を表わしたものである。表示部426には完成した図形データがパッケージごとに2つに分けて出力されている。これは、第4のプログラム714に対応する完成済み図形データである。表示部426には、第3〜第6のプログラム713〜716に対応する図形データを1つずつ表示してもよいし、同時に表示してもよい。この第1の変形例のプログラム視覚的表示装置401では、パッケージの概念を含んだプログラムで、同じクラス名を含むときも、プログラム視覚的表示装置401により、視覚的に区別して表示することができる。
図26は、図25をUML表記で表わしたものである。図25と比較して、オブジェクトの保持関係が理解しにくくなっている。
図27は、本発明の第1の変形例におけるプログラム視覚的表示装置を用いたプログラム視覚的表示システムの構成を表わしたものである。プログラム視覚的表示システム800は、プログラム視覚的表示装置401およびこれとインターネット801により接続された第1〜第Nの端末8021〜802Nとからなっている。プログラム視覚的表示装置401は第1〜第Nの端末8021〜802Nから第1〜第Nのプログラム8041〜804Nと第1〜第Nのプログラム視覚的表示要求8051〜805Nを受信すると、その要求に対する処理をそれぞれ行って、第1〜第Nのプログラム視覚的表示処理結果8061〜806Nを第1〜第Nの端末8021〜802Nに送信するようになっている。
このように複数の端末から複数の処理要求を受け取って処理を行う場合は、特にクラス名の衝突が起こる可能性が高い。プログラム視覚的表示装置401では、パッケージによるクラス管理が行われているため、クラス名を衝突させることなく処理を行うことができる。