JP2000020298A - ソフトウェア開発支援装置 - Google Patents

ソフトウェア開発支援装置

Info

Publication number
JP2000020298A
JP2000020298A JP10182200A JP18220098A JP2000020298A JP 2000020298 A JP2000020298 A JP 2000020298A JP 10182200 A JP10182200 A JP 10182200A JP 18220098 A JP18220098 A JP 18220098A JP 2000020298 A JP2000020298 A JP 2000020298A
Authority
JP
Japan
Prior art keywords
class
package
repository
source file
database
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP10182200A
Other languages
English (en)
Inventor
Hirobumi Araya
博文 新家
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP10182200A priority Critical patent/JP2000020298A/ja
Publication of JP2000020298A publication Critical patent/JP2000020298A/ja
Pending legal-status Critical Current

Links

Abstract

(57)【要約】 (修正有) 【課題】 開発の途中で生じるパッケージ構成の変更作
業を支援し、適切なパッケージを用いた設計を行うこと
を可能とする。 【解決手段】 ソースファイルを解析し、各パッケージ
を構成するクラス及びメンバの情報を登録したリポジト
リデータベースと、解析の結果の構文解析情報データベ
ースとを作成するソース解析部と、前記リポジトリデー
タベース中の情報からクラス及びメンバのシンボルとク
ラス及びメンバの参照関係を示す図形データを作成する
リポジトリ可視化部と、前記図形データをグラフィック
端末へ表示すると共に当該ソースファイルのパッケージ
構成の変更指示を受け付ける表示制御部と、前記変更指
示に従って、リポジトリデータベース、構文解析情報デ
ータベース及びソースファイルの内容を更新し、ソース
ファイルのパッケージ構成を変更するプログラム修正部
とを備える。

Description

【発明の詳細な説明】
【0001】
【発明の属する技術分野】本発明は、オブジェクト指向
プログラミング言語を用いたソフトウェア開発を支援す
るソフトウェア開発支援装置に関し、特に、モジュール
化の概念をパッケージという形で取り入れたオブジェク
ト指向プログラミング言語によるソフトウェア開発支援
環境を提供するソフトウェア開発支援装置に適用して有
効な技術に関するものである。
【0002】
【従来の技術】品質の高いソフトウェアを開発するにあ
たって、オブジェクト指向技術を取り入れることが効果
的であると考えられている。オブジェクト指向の分析・
設計では、システムが扱う問題領域の様々な概念を表す
ところのクラスを基に分析・設計を行うことで、柔軟性
や再利用性の高い堅牢なソフトウェアの開発を可能にし
ている。
【0003】オブジェクト指向技術を支える技術の一つ
に、オブジェクト指向プログラミング言語がある。オブ
ジェクト指向プログラミング言語は、オブジェクト指向
の概念を構文レベルでサポートし、オブジェクト指向の
分析・設計の結果を、より自然な方法でプログラムに変
換することができるものである。Javaは、この様なオブ
ジェクト指向プログラミング言語の一つである。
【0004】どの様なソフトウェアの開発の方法論にお
いても、一般に対象システムをより小さな規模のサブシ
ステムに分割して、複雑さを軽減することが行われる。
オブジェクト指向開発においては、この対象システムの
分割はモジュール化という形をとる。
【0005】モジュール化とは、システムを構成する全
てのクラスを互いに関係の深い幾つかのグループに分け
ることである。適切なモジュール分割を用いた開発で
は、モジュール間でのクラスの依存関係を小さく保ち、
個々のモジュールの再利用性を高め、全体として柔軟性
の高いソフトウェアを作成することができる。
【0006】Java言語はモジュール化の概念をパッケー
ジという形で取り入れている。Java言語においてクラス
がどのパッケージに属するかは、ソースファイルの先頭
に記述したpackage宣言文で指定される。他のオブジェ
クト指向言語に無いJava言語の特徴は、クラスのメンバ
のアクセス許可(accessibility)が、参照元/参照先
のクラスが属するパッケージとクラス及びメンバの可視
性修飾詞(visibilitymodifier)の両方によって決めら
れる点である(可視性修飾詞は、クラスに対しては、pu
blic、修飾詞無し(可視性=package)の何れかの値、メ
ンバに対しては、public、protected、private、修飾詞
無し(可視性=package)の何れかの値をとる)。Java言
語のこの性質は、パッケージ内のクラス間での「強い結
合」と、パッケージ間の「弱い結合」を実現する設計を
支援するものである。
【0007】
【発明が解決しようとする課題】前記の様にオブジェク
ト指向言語を用いた従来のソフトウェア開発では、パッ
ケージによって対象システムをより小さな規模のサブシ
ステムに分割して、複雑さを軽減することが行われる
が、はじめからクラスの集合を適切なパッケージに分割
することはしばしば困難である。特に開発の初期の段階
においては個々のクラスの概念や位置付けが明確で無
く、クラスのカテゴリもまた明確で無いからである。そ
のため、開発の途中段階でパッケージ分割を見直した
り、時には新しいパッケージを作成し、クラスを最初に
開発したパッケージとは異なるパッケージに移動する必
要が出る場合がある。
【0008】また、開発対象のソースコードの量が少な
く、開発者が全体を見渡せる状態では、パッケージに分
けるメリットよりも、オーバヘッドの方がむしろ大きい
ため、パッケージに分けずに開発を行う場合もある。し
かしこの様な場合でも、機能が拡張されてシステムの規
模が大きくなり、管理するコードの量が増え、開発に関
わる開発者も増えてくると、工程の何れかの時点でコー
ドをパッケージに分割する作業が必要になってくる。
【0009】この様に、しばしばソフトウェアを構成す
るパッケージの見直しが必要となるが、この変更は煩雑
である。Java言語における異なるパッケージ内のクラス
の参照は、<パッケージ名>.<クラス名>という完全限定
された形式(fully qualifiedform)で行うか、そのパ
ッケージを「import」するかの何れかの方法で行なわな
ければならず、変更の対象になったクラスを参照する全
ての個所について、ソースコードに変更を加えなければ
ならないからである。
【0010】また、この様なパッケージの見直しは、ク
ラス単独の性質を考慮して行うのでは無く、他のクラス
との関係を考えた総合的な判断が必要となる。例えば、
或クラスを他のパッケージに移す場合、このクラスと関
連の深い他のクラスも共に、同じパッケージに移動しな
ければならないかもしれない。
【0011】また、パッケージの変更は、Java言語の特
徴であるパッケージの影響を受けるアクセス許可の性質
を考慮して行なわなければならない。例えば、クラスB
のメンバxが、可視性修飾詞無しであった場合、これを
参照するクラスAがBと同一パッケージではこのアクセス
が許可されるが、異なるパッケージに移したときにはア
クセスが許可されない。
【0012】この様な不適切なアクセス個所が生じた場
合に開発者は、クラスBのメンバxの可視性を見直してこ
のメンバを公開するか、この状況を引き起こすパッケー
ジ間のクラスの移動を取りやめるかの判断を行なわなけ
ればならない。移動の対象となったクラスは他の全ての
クラスからアクセスされる可能性があるため、上記の様
な検討が必要とされる個所を特定する為には、他の全て
のクラスとの関係を調べ挙げなければならず、開発者に
とって負担である。
【0013】更に、検討に際しては、移動するクラスが
移動前/移動後の両方のパッケージから参照されている
場合や、対象のクラス自身が他のクラスを参照している
様な場合等、クラス間の相互の参照を考慮して総合的な
判断を行なわなければならない。
【0014】本発明の目的は、上記問題を解決し、開発
の途中で生じるパッケージ構成の変更作業を支援し、適
切なパッケージを用いた設計を行うことが可能な技術を
提供することにある。
【0015】本発明の他の目的は、パッケージ構成変更
時に発生する不適切なアクセス個所を示して検討すべき
個所を開発者に知らせると共に、クラスの相互参照関係
を示して開発者のパッケージ設計時の判断を支援するこ
とが可能な技術を提供することにある。
【0016】本発明の他の目的は、クラス或いはメンバ
の可視性の変更を表示装置上で指示し、アクセス許可を
考慮に入れたパッケージの設計を表示装置を通じて行う
ことが可能な技術を提供することにある。
【0017】
【課題を解決するための手段】本発明は、モジュール化
の概念をパッケージという形で取り入れたソフトウェア
開発を支援するソフトウェア開発支援装置であって、各
パッケージを構成するクラス及びメンバを示すシンボル
とその参照関係を可視化して表示し、可視化されたシン
ボルとその参照関係を変更する指示に従って、対応する
ソースファイルのパッケージ構成を変更するものであ
る。
【0018】本発明のソフトウェア開発支援装置のソー
ス解析部は、モジュール化の概念をパッケージという形
で取り入れた言語(例えばJava言語)で記述されたソー
スファイルを解析し、パッケージとクラスの対応、各ク
ラスについて各メンバ(メソッド、フィールド)の可視
性(public、protected、private、package)、クラス
及びメンバ間の参照関係、クラスの継承関係を示す情報
を登録したリポジトリデータベースと、解析の結果得ら
れた構文解析情報を登録した構文解析情報データベース
とを作成する。
【0019】リポジトリ可視化部は、前記リポジトリデ
ータベース中の情報を可視化してクラス及びメンバのシ
ンボルとクラス及びメンバの参照関係を示す図形データ
を作成し、前記作成した図形データをグラフィック端末
へ表示すると共に当該ソースファイルのパッケージ構成
を変更する指示を表示制御部により受け付ける。
【0020】プログラム修正部は、前記表示制御部を介
して受けた指示に従って、リポジトリデータベース、構
文解析情報データベース及びソースファイルの内容を更
新し、当該ソースファイルのパッケージ構成を変更す
る。
【0021】前記の様に本発明では、パッケージとクラ
スの関係を保持するリポジトリデータベースを基に、ク
ラスを表すシンボルとパッケージを表す矩形の図形的な
包含関係で表示し、開発者のパッケージ理解を促すと共
に、開発者がクラスを表すシンボルをドラッグする等、
表示装置で行ったクラスの異なるパッケージへの移動の
指示を基に、対応したリポジトリデータとソースファイ
ル該当個所の記述更新を行うことで、開発者が容易にパ
ッケージ構成を変更できる様にすることができる。
【0022】また、クラス或いはメンバの相互の参照関
係を、クラスやメンバを表すシンボルを結ぶ矢印付きの
線分等の図形で表示すると共に、Java言語のアクセス許
可の判定論理を保持したアクセス許可テーブルを基にク
ラスやメンバ間のアクセスの許可性を判定し、この判定
結果を基に許可されたアクセスと許可されない参照を線
分等前記図形の表示方法の違いによって示すことで、パ
ッケージの設計を行うにあたって検討すべき個所と設計
の判断に必要なクラス相互の間の参照関係を開発者に明
示することが出来る。
【0023】また可視性の変更を表示装置上で行って、
これを基にソースファイル該当個所の記述更新を行うこ
とで、表示装置を通じてアクセス許可を考慮に入れたパ
ッケージ構成の設計を行うことができる。
【0024】以上の様に、本発明のソフトウェア開発支
援装置によれば、パッケージの概念をサポートしたクラ
スの管理を行い、パッケージのクラスやメンバを図形的
に表示装置に表示することにより開発者のパッケージへ
の総合的な理解を促すと共に、開発者が表示装置を通じ
てパッケージの構成を操作できる様にするので、開発の
途中で生じるパッケージ構成の変更作業を支援し、適切
なパッケージを用いた設計を行うことが可能である。
【0025】
【発明の実施の形態】以下に、Java言語を用いたソフト
ウェア開発を支援する一実施形態のソフトウェア開発支
援装置について説明する。
【0026】図1は本実施形態のソフトウェア開発支援
装置の概念図であり、図2は図1におけるリポジトリデ
ータベース10のデータモデルである。図3はJava言語の
ソースファイル20の例を示しており、更に図4は、図3
のソースファイル20を解析した情報を登録した場合のリ
ポジトリデータベース10の内部のデータ構造を示したオ
ブジェクト図である。
【0027】また図5は本実施形態のソフトウェア開発
支援装置の働きを概略で示す処理フローである。図中の
ステップ302、303及び305の処理については、図7、図
8、図11、図12及び図13に詳細に示した。図6
は、図5のステップ302において可視化されたリポジト
リの内容の例であり、パッケージとこれを構成するクラ
ス、クラスとこれを構成するメンバ、及びこれらの参照
関係を図形表示した表示画面の状態を示している。
【0028】まず図1に従って本実施形態のソフトウェ
ア開発支援装置の構成について説明する。図1に示す様
に本実施形態のソフトウェア開発支援装置は、リポジト
リ可視化部30と、プログラム修正部40と、ソース解析部
50と、表示制御部60とを有している。
【0029】リポジトリ可視化部30は、リポジトリデー
タベース10中の情報を可視化してクラス及びメンバのシ
ンボルとクラス及びメンバの参照関係を示す図形データ
を作成し、図形データの表示属性をその可視性に応じて
変更する処理部である。
【0030】プログラム修正部40は、表示制御部60を介
して受けた指示に従って、リポジトリデータベース10、
構文解析情報データベース15及びソースファイル20の内
容を更新し、ソースファイル20のパッケージ構成を変更
する処理部である。
【0031】ソース解析部50は、モジュール化の概念を
パッケージという形で取り入れた言語(例えばJava言
語)で記述されたソースファイル20を解析し、パッケー
ジとクラスの対応、各クラスについて各メンバ(メソッ
ド、フィールド)の可視性(public、protected、priva
te、package)、クラス及びメンバ間の参照関係、クラ
スの継承関係を示す情報を登録したリポジトリデータベ
ース10と、解析の結果得られた構文解析情報を登録した
構文解析情報データベース15を作成する処理部である。
【0032】表示制御部60は、リポジトリ可視化部30で
作成した図形データをグラフィック端末70へ表示すると
共にユーザからの制御を受け付ける処理部である。
【0033】ソフトウェア開発支援装置を、リポジトリ
可視化部30、プログラム修正部40、ソース解析部50及び
表示制御部60として機能させる為のプログラムは、CD
−ROM等の記録媒体に記録されて実行されるものとす
る。尚、前記プログラムを記録する媒体は、CD−RO
M以外の他の媒体でも良い。
【0034】本実施形態のソフトウェア開発支援装置
は、パッケージ及びクラスの構成情報とこれら要素間の
参照情報を保持するリポジトリデータベース10、ソース
ファイル20を解析して得られた構文解析情報(抽象構文
木)を保持する構文解析情報データベース15、ソースフ
ァイル20を解析することによりリポジトリデータベース
10と構文解析情報データベース15を作成または更新する
ソース解析部50、リポジトリデータベース10中の情報を
可視化して図形表示する為のリポジトリ可視化部30、図
形データをグラフィック端末70へ表示すると共にユーザ
からの制御を受け付ける表示制御部60、表示制御部60を
介して受けたユーザの指示に従ってリポジトリデータベ
ース10、構文解析情報データベース15及びソースファイ
ル20の内容を更新するプログラム修正部40からなる。
【0035】リポジトリ可視化部30は、参照元/先クラ
スの属するパッケージと対象クラス及びメンバの可視性
修飾詞から、アクセスが許可されているかどうかを判断
する為のクラスアクセス許可テーブル31とメンバアクセ
ス許可テーブル32を備えている。クラスアクセス許可テ
ーブル31及びメンバアクセス許可テーブル32の構造につ
いては図9及び図10に示す。
【0036】リポジトリデータベース10はソースファイ
ル20(図3にJava言語のソースファイル20の例を示す)
が表現するプログラムについてのパッケージ構成情報と
クラス及びメンバの参照関係を保持するデータベースで
ある。これに対して、構文解析情報データベース15は、
ソースファイル20を解析して得られた構文解析情報を保
持している。リポジトリデータベース10と構文解析情報
データベース15は、互いに協調して用いられる。リポジ
トリデータベース10の項目のうち、ソース中の特定の構
文要素に関係しているものは、構文解析情報データベー
ス15中の抽象構文木ノードへの関連を持っている。
【0037】図2は、本実施形態のリポジトリデータベ
ース10のデータモデルを示す図である。図2の内容に従
ってリポジトリデータベース10の構造を説明する前に、
図2の記法について述べる。図2中に矩形で示したエン
ティティの各々は、夫々半導体メモリ或いは磁気ディス
ク等の記憶媒体上に割り付けられるデータ構造の型であ
って、矩形上段内に示した名前で識別されるエンティテ
ィ型で区別され、矩形下段内に示した個々の属性に対応
する値を格納する為の下位のデータ構造を内部に持つ。
【0038】例えばクラスエンティティ102は、型名
「クラス」と、2つの属性「名称」及び「可視性」とを
持ち、媒体上に割り当てられた時、クラスエンティティ
102を保持する領域は「名称」及び「可視性」を保持す
る小領域を持つ。
【0039】エンティティが割り付けられた記憶媒体上
の領域をオブジェクト(或いはインスタンス)と呼ぶ。
オブジェクトの各々は、唯一つのエンティティの型を持
ち、型を区別する識別子がオブジェクトの領域の決まっ
た場所に保持される。
【0040】エンティティはまた、図2中にエンティテ
ィ間を結ぶ矢印で示した「関連」を持つことができる。
関連とは、特別な属性であり媒体上に割り付けられた時
に、他のエンティティが割り付けられた同媒体上の領域
(即ちオブジェクト)へのポインタを値として持つもの
である。
【0041】「関連」は多重度を持つことができ、複数
のオブジェクトを指すことができる。この様な多重の関
連は、前記ポインタの代わりにポインタの配列等を用い
て実装することができる。関連の多重度は、関連を示す
線分の端に数値または「*」の記号で示した。ここで
「*」は多重度に上限値が無いことを示す。
【0042】図中、異なる複数のエンティティから、同
一エンティティへの関連は、必ずしも複数のエンティテ
ィからの同一のオブジェクトへの関連を意味せず、一般
には同一のエンティティ型の異なるオブジェクトを参照
することを示す。「関連」は、オブジェクトのぞれぞれ
が表現する事物の間の概念的な関係を表現するものであ
る。
【0043】もう一つのエンティティ間の関係は、図2
中で123或いは133の図形で示した継承関係である。例え
ば、この場合メンバ103に対してフィールド104及びメソ
ッド105は下位のエンティティとなる。
【0044】継承関係において、あるエンティティが他
のエンティティ(上位エンティティ)の下位であるとい
うことは、注目したエンティティのデータ構造が、上位
エンティティと同じデータ構造を持った領域と、当該エ
ンティティ型独自の拡張部分から成ることを示す。継承
関係は、下位エンティティが上位エンティティを特殊化
或いは拡張した概念であることを表現している。
【0045】次に図2の内容について説明する。パッケ
ージ101は、Java言語におけるクラス管理の単位である
パッケージに対応したエンティティであり、クラス102
は、クラスに対応したエンティティである。クラス102
は、属性としてクラス名称及び可視性を保持する。クラ
ス102に対する可視性は、publicか或いはpackageの何れ
かの値をとる。
【0046】図3は、本実施形態のJava言語のソースフ
ァイル20の一例を示す図である。図3に示す様にソース
ファイル20中では、クラスはクラス宣言711(ClassDecl
aration)によって定義され、クラスが属するパッケー
ジは、パッケージ宣言709(PackageDeclaration)によ
って指定される。
【0047】本実施形態のソフトウェア開発支援装置で
は実装の簡略化の為にインポート宣言710を扱わないも
のとし、従って本実施形態のソフトウェア開発支援装置
が扱うソースファイル20は、実際にはインポート宣言71
0の無いものであるとするが、インポート宣言710を扱う
実施形態も本実施形態のソフトウェア開発支援装置から
容易に類推することが出来る。
【0048】ソース解析部50は、対応するソースファイ
ル20を解析し、ソースファイル20中のクラスとパッケー
ジを拾い、リポジトリデータベース10にクラス102及び
パッケージ101として登録する。クラスとこれを含むパ
ッケージの関係は、関連121として表現される。
【0049】リポジトリデータベース10中のパッケージ
101とクラス102の概念は、ソースファイル20中の記述と
の対応を保持する為に、夫々、次の仕方で構文解析情報
データベース15と関係付けられている。
【0050】クラス102はクラス宣言構文要素と1対1の
対応が付けられる為、直接、対応するソースファイル20
中のクラス宣言構文要素に対応する抽象構文木ノード10
9への関連127を保持する。
【0051】一方、構文要素を示すエンティティである
パッケージ宣言108を、パッケージ101とは独立したエン
ティティとして扱う。これは、パッケージを定義する記
述が、複数のソースファイル20中に散らばっており、パ
ッケージ101とは1対1の対応が取れないからである。パ
ッケージ宣言108は、パッケージ宣言を表す抽象構文木
ノード109への関連132を持つ。
【0052】図4は、本実施形態の図3のソースファイ
ル20を解析した情報を登録したリポジトリデータベース
10の内部のデータ構造を示す図である。図3の例では、
COM.xxxパッケージを構成するクラスとして、Aという名
前の可視性publicを持つクラスが定義されている。図4
のオブジェクト図(インスタンス図)に示したパッケー
ジ801とクラス802a間の関連821は、クラスAがCOM.xxxパ
ッケージに含まれることを示している(図4では、抽象
構文木ノード109への関連127は示していない)。
【0053】メンバ103は、フィールド104かメソッド10
5の何れかであり、継承関係123がこれを示している。こ
れらは夫々、概念的にJavaプログラム中の各クラスが提
供するフィールド及びメソッドに対応しており、クラス
102からメンバ103への関連122がこれを表現する。
【0054】フィールド104及びメソッド105は夫々ソー
スファイル20中の構文要素であるフィールド宣言(Fiel
dDeclaration)、メソッド宣言(MethodDeclaration)
と1対1に対応しており、従ってメンバ103は、これに対
応した抽象構文木ノード109への関連129を保持してい
る。
【0055】図3のソースの例では、クラスAは、フィ
ールドb1、メソッドfoo1及びfoo2等のメンバを持ってい
る。これは、リポジトリデータベース10内では図4の80
3a〜cとして登録され、関連822によってクラスAがこれ
らを提供することが示されている。
【0056】メンバ103は、属性として名称及び可視性
を持つ。可視性は、public、protected、private、pack
ageの何れかの値を取ることが出来る。図4に示された
メンバb1、foo1の可視性は、夫々、package、publicで
ある(図4では、抽象構文木ノード109への関連129は省
略されている)。
【0057】リポジトリデータベース10は、上記情報に
加え、クラス及びメンバ間の参照関係を保持する。クラ
ス102はソースコードのクラス中での他のクラス又はメ
ンバへの各々の参照に対応して参照106を持ち、参照106
は参照対象107(これはクラス102又はメンバ103の何れ
かである)への関連130を持つ。
【0058】ここで「クラスAがクラスBへの参照を持
つ」のは、次の何れかの場合である。 1)クラスAがクラスB型のメンバを持つ。2)クラスA
のメソッドの何れかがクラスB型の形式引数を持つ。
3)クラスAのメソッドの何れかがメソッド内のローカ
ル変数としてクラスB型の変数を参照している。4)ク
ラスAのメソッドの何れかがクラスBのクラスメンバ(st
atic修飾されたメンバ)を参照している。
【0059】図3のクラス参照の例701〜704が、1)〜
4)のそれぞれの例になっている。これらは、図4では
クラス802aが持つ、クラス802bへの4つの参照806c〜806
fで表現されている。
【0060】また「クラスAがクラスBのメンバxへの参
照を持つ」のは次のいずれかの場合である。1)クラス
Aのメソッドの何れかがB.xを参照している(クラスメン
バの場合)。2)クラスAのメソッドの何れかがクラスB
のインスタンスbを参照し、b.xを参照する(インスタン
スメンバの場合)。
【0061】これらの参照の例を図3のメンバ参照の例
705〜708に示した。これに対応して図4では、参照806a
及び806bがクラス802aからのメンバ803d(B.x)への参
照を示している。
【0062】参照106は、ソースファイル20中の特定の
構文要素に対応し、抽象構文木ノード109への関連131を
持つ(図4では、抽象構文木ノード109への関連131は省
略されている)。また、ここに挙げた例から観察できる
注意すべき点は、クラスBのメンバxの参照がクラスBの
参照を前提としていることである。
【0063】図5は、本実施形態のソフトウェア開発支
援装置の処理概略を示す図である。図5に示す様に本実
施形態のソフトウェア開発支援装置においてソフトウェ
ア開発支援処理を起動すると(ステップ301)、ソフト
ウェア開発支援装置は、リポジトリデータベース10の内
容を読み取り、このデータを可視化して表示する(ステ
ップ302)。
【0064】ここでソフトウェア開発支援装置は、ユー
ザの指示に従って次の何れかの処理を行う。まず第1の
場合として、ユーザがエディタ等によって、ソースファ
イル20を変更したり、新たにソースファイル20を追加す
る場合がある(パス306)。この場合、ソフトウェア開
発支援装置は、ソース解析部50によりソースファイル20
を構文解析し、構文解析情報データベース15とリポジト
リデータベース10を更新する(ステップ303)。
【0065】次に第2の場合として、ユーザがグラフィ
ック端末70上でパッケージ構成情報を変更する場合があ
る(パス308)。この場合には、リポジトリデータベー
ス10、構文解析情報データベース15と合わせてソースフ
ァイル20の変更を行う(ステップ305)。ここに述べた
パッケージ構成情報の変更とは、1)パッケージ間のク
ラスの移動、2)クラス或いはメンバの可視性修飾詞の
変更、である。
【0066】また、第3の場合として、ユーザがソフト
ウェア開発支援処理の終了を指示した場合(パス30
7)、ソフトウェア開発支援処理を終了する(ステップ3
04)。ステップ302及びステップ305の処理の詳細につい
ては後述する。
【0067】上記ステップ302において、リポジトリデ
ータベース10を可視化することによって得られるパッケ
ージ−クラス構造の表示画面の例を図6に示す。
【0068】図6は、本実施形態のパッケージ−クラス
構造の表示画面の一例を示す図である。図6において、
矩形201及び202がパッケージを表し、この中に表示され
たシンボル203、204、205及び207等がクラスを示してい
る。
【0069】パッケージを示す矩形とシンボルの包含関
係は、そのクラスが当該パッケージに属することを示し
ている。例えばクラスA、クラスB、クラスCは、パッケ
ージpack_Aに属している。
【0070】図6では各シンボルは名前と共に可視性を
表示しており、クラスのシンボルの表示方法をクラスの
可視性に従って変えている。例えば、可視性packageを
持つクラスAは破線で、可視性publicを持つクラスB及び
クラスCは全線で示されている。
【0071】更に、クラスからクラス及びメンバへの参
照を矢印付き線分で示している。例えばクラスBは、ク
ラスF及びクラスDのzメンバ等を参照している。この様
な参照を示す矢印の表示では、参照元/先のクラスの属
するパッケージと参照先クラス及びメンバの可視性修飾
詞に従って参照が有効/無効を判定し、その判定結果に
よって表示方法を変える。例えば、無効な参照211は破
線で、有効な参照212は全線で表示されている。
【0072】ここではクラスへの参照とメンバへの参照
の両方を一つの画面で表現しているが、実際にクラスや
メンバの数が多くなると、この図法では表現が見づらく
なる可能性がある。その為、通常の表示ではクラス−ク
ラス間の関係だけを表示しておいて、見たい個所だけを
詳細に表示する様なインタフェースも考えられる。
【0073】図7は、本実施形態のリポジトリ可視化処
理の処理手順を示すフローチャートである。図5におけ
るステップ302のリポジトリ可視化処理の詳細について
図7を用いて説明する。
【0074】まず、ステップ402〜407の処理について説
明する。ステップ402〜407の処理は、ループA、ループ
B、ループCの3重ループの制御構造を持つ。ループAの
ループの変数はaで、リポジトリデータベース10に属す
るパッケージが順次代入される(402)。ループBのルー
プ変数はbであり、パッケージaに属するクラスの各々が
順次代入される(404)。これは、リポジトリデータベ
ース10中の関連121を手繰ることにより行うことが出来
る。ループCのループ変数はcであり、クラスbに属する
メンバの各々が順次代入される(406)。これは、リポ
ジトリデータベース10中の関連122を手繰ることにより
行うことが出来る。
【0075】この制御構造の基に行われる各処理の内容
は以下の通りである。ステップ403では、パッケージaを
表す矩形を画面に表示する。ステップ405では、パッケ
ージaに対応した矩形中に、クラスbを示すシンボルを表
示する。ステップ407では、クラスbに関連したメンバc
を示すシンボルを表示し、クラスbとメンバcの間の関連
を線分等で表示する。ステップ405及びステップ407にお
いては、クラスbの可視性がpackageならば破線で、publ
icならば全線で描画を行う。ステップ407のメンバcの表
示においてクラスbの可視性修飾詞を考慮するのは、既
に述べた様にクラスのメンバへの参照がクラスへの参照
を前提とするからである。
【0076】次に、ステップ414、415及び413の処理に
ついて説明する。処理はループD及びループEの2重ルー
プの構造を持ち、ループ変数は夫々、変数a及び変数bで
ある。変数aにはリポジトリデータベース10に属するパ
ッケージが順次代入され(ステップ414)、変数bにはパ
ッケージaに属するクラスの各々が順次代入される(ス
テップ415)。
【0077】この制御構造の基に行われる処理として、
ステップ413では、リポジトリデータベース10中の関連1
28を手繰ることにより、クラス間の継承関係を示す図形
(図6の例では、214)を表示する。
【0078】更に、408〜412の処理によって、リポジト
リデータベース10中のクラス−クラス、クラス−メンバ
間の全て参照について以下の処理を行い、参照を示す矢
印付き線分を画面表示する。処理は、ループF、ループ
G、ループHの3重ループの構造を持ち、ループ変数は夫
々、変数a、変数b、変数cである。変数aには、リポジト
リデータベース10に属するパッケージの各々が、変数b
にはパッケージaに属するクラスの各々が、変数cにはク
ラスbの参照の各々が、順次代入される(408、409、41
0)。クラスbの参照の各々は、リポジトリデータベース
10中の関連126を手繰ることにより得ることが出来る。
【0079】この制御構造の基に行われる処理の各々は
以下の通りである。ステップ411では、参照cが許可され
ているかどうかをアクセス許可テーブルを用いて判断す
る(詳細は後述)。ステップ412では、ステップ411の判
断に基づいて参照cを表現する矢印付き線分を、クラスb
から参照先クラス或いはメンバに向けて描画する。参照
cが許可されている時には全線で、参照cが許可されてい
ないときには破線で描画を行う。
【0080】図8は、本実施形態のパッケージa中のク
ラスbからの参照cについてのアクセス許可性を判定する
処理の処理手順を示すフローチャートである。ステップ
411のアクセス許可性の判定処理について、図8を用
いて詳細に説明する。まず、参照cの対象を変数Tに代
入する(ステップ420)。対象Tがクラスであればステッ
プ430、メンバであればステップ440へ進む。ここで、対
象Tのタイプは、リポジトリデータベース10中での対象T
のエンティティ型で表現されており、得る事ができる。
【0081】まず、対象Tがクラスであった場合につい
て記述する。対象Tの属するパッケージPと、対象Tの可
視性Mを取得し(ステップ430)、パッケージPがパッケ
ージaに等しいかどうか判断する(ステップ431)。等し
い場合には、アクセス条件A=「同一パッケージ」(ステ
ップ432)で、そうでない場合にはアクセス条件A=「パ
ッケージ外」(ステップ433)でステップ434の検索を行
う。
【0082】ステップ434では、上記アクセス条件Aと対
象Tの可視性Mによってクラスアクセス許可テーブル31を
検索し、ここで得た結果を判定結果Xとする。
【0083】図9は、本実施形態のクラスアクセス許可
テーブル31の一例を示す図である。図9によれば、例え
ばアクセス条件A=「パッケージ外」、可視性=package
の場合、アクセスは許可されない。
【0084】次に対象Tがメンバであり、ステップ440へ
処理を進める場合について説明する。まず、対象Tの可
視性M、対象Tの属するクラスC、クラスCの属するパッケ
ージP、クラスCの可視性Nを取得する(ステップ440)。
【0085】上述した様にメンバへのアクセスはその属
するクラスへのアクセスが前提となる為、クラスC及び
可視性Nについてステップ430〜434と同様の処理を行い
(ステップ440〜444)、ステップ450でクラスCへのアク
セスが許可されていると判断されたときのみステップ45
1に進み、処理を続ける。クラスCへのアクセスが許可さ
れていないと判断した場合、そのメンバである対象Tへ
のアクセスも不許可になる(ステップ458)。
【0086】ステップ451に進んだ場合には、まずクラ
スbとクラスCとが等しいかどうかの判定を行い(ステッ
プ451)、等しい場合にはアクセス条件A=「同一クラ
ス」としてステップ460に進む(ステップ452)。
【0087】クラスbとクラスCとが等しくない場合は、
次にパッケージaとパッケージPとが等しいかどうかの判
定を行い(ステップ453)、等しい場合にはアクセス条
件A=「同一パッケージ」としてステップ460に進む(ス
テップ454)。
【0088】パッケージaとパッケージPとが等しくない
場合は、更にクラスbがクラスCのサブクラスであるかど
うかの判定を行う(ステップ455)。この判定は、リポ
ジトリデータベース10中にクラスCからクラスbへの継承
関係が存在するかどうかを調べることで行える。
【0089】クラスbがクラスCのサブクラスであった場
合には、アクセス条件A=「異パッケージ、サブクラス」
とし(ステップ456)、クラスbがクラスCのサブクラス
ではなかった場合には、アクセス条件A=「異パッケー
ジ、非サブクラス」として(ステップ457)、何れの場
合もステップ460に進む。
【0090】ステップ460では、前記のステップ452、45
4、456または457で設定されたアクセス条件Aと対象Tの
可視性修飾詞Mとによって、メンバアクセス許可テーブ
ル32の検索を行う。ここで得た結果を判定結果としてX
に代入する。上記何れのパスを通った場合も判定結果は
変数Xに入れられる。
【0091】図10は、本実施形態のソフトウェア開発
支援装置のメンバアクセス許可テーブル32の一例を示す
図である。図10によれば、例えばアクセス条件A=「異
パッケージ、非サブクラス」、可視性=packageの場
合、アクセスは許可されない。
【0092】次に、図11及び図12のフローチャート
に従って、図5のステップ303でソースファイル20を解
析して登録するリポジトリデータベース10の構築処理に
ついて説明する。
【0093】リポジトリデータベース10の構築は、ソー
ス解析部50に依って行われる。ソース解析部50は、プロ
グラミング言語の構文に従って抽象構文木を生成する構
文解析部と、これを入力としてリポジトリデータベース
10を更新する部分からなる。ここで用いる構文解析部は
一般的なもので、よく知られた技法で構成することがで
きる。ここでは、構文解析部が作成した構文解析情報に
対して意味的解析を行って、リポジトリデータベース10
を構築する処理について説明する。
【0094】図11は、本実施形態のソース解析部50の
第1の処理の処理手順を示すフローチャートであり、図
12は、本実施形態のソース解析部50の第2の処理の処
理手順を示すフローチャートである。リポジトリデータ
ベース10を構築する処理は2つの部分から成り、第1の部
分の処理は、対象プログラムソース内で定義されたパッ
ケージ、クラス及びメンバの構成関係を構文解析情報よ
り読み出す処理である。この処理はコンパイル単位(ソ
ースファイル)毎に全てのファイルに対して行われる。
第2の部分は、第1の処理を前提にクラスからクラス、
クラスからメンバへの参照関係を読み出す処理である。
【0095】図11に従って処理の第1の部分を説明す
る。まず、コンパイル単位にパッケージ宣言があるかど
うかを調べる(ステップ901)。対象とするコンパイル
単位にパッケージ宣言が無い場合には、デフォルトパッ
ケージに相当するパッケージエンティティのインスタン
スを取り、これをPとする(ステップ905)。
【0096】コンパイル単位にパッケージ宣言が存在す
る場合は、リポジトリデータベース10中にパッケージ宣
言エンティティPDを生成する(ステップ910)。次に、
リポジトリデータベース10中を検索し、パッケージ宣言
中に指定されたパッケージ名称を持ったパッケージPが
存在するかどうかを調べる。パッケージPが存在しない
場合、パッケージエンティティのインスタンスを生成し
て名称を設定し、これをPとする(ステップ911)。コン
パイル単位にパッケージ宣言があるときには、さらにパ
ッケージ宣言PDに対し、パッケージPへの参照を格納す
る(ステップ912)。
【0097】例えば、図3のソースファイル20(コンパ
イル単位)は、パッケージ宣言709を含むので(ステッ
プ901)、リポジトリデータベース10中にパッケージ宣
言のインスタンス808を生成する(ステップ910)。この
パッケージ宣言808は、パッケージ宣言に宣言された名
称"COM.xxx"を持つパッケージ801への関連824を保持し
ている。リポジトリデータベース10中のインスタンスパ
ッケージ801は、最初に"package COM.xxx;"宣言を持っ
たコンパイル単位を処理した時に生成される。
【0098】次に、コンパイル単位で宣言されている個
々のクラスに対する処理を行う。構文解析情報より同コ
ンパイル単位のクラス宣言の一つを取り、これをCDとす
る(ステップ920)。クラス宣言CDの先頭部は、修飾詞
+"class"+識別子(Identifier)+...という形式であ
る。例えば、図3に示したコンパイル単位には一つのク
ラス宣言711があり、クラスの修飾詞、識別子は夫々、"
public"、"A"である。
【0099】ステップ921では、リポジトリデータベー
ス10中にクラスエンティティのインスタンスを生成し
て、これらの修飾詞及び識別子を設定し、これをCとす
る。例えば、図3のコンパイル単位に対しては、図4に
示したインスタンス802a(名称=A、可視性修飾詞=publi
c)を生成する。
【0100】さらに、クラスCとパッケージPの間に関連
821を設定してCをPの構成メンバとして登録し(ステッ
プ922)、パッケージ宣言PDにパッケージPへの参照を格
納して関連825を設定する(ステップ924)。図4におい
ては、パッケージ801がクラス802aへの参照を保持して
クラス802aがパッケージ801を構成するクラスであるこ
とを示しており、さらにクラス802aがパッケージ宣言80
8への参照を保持している。
【0101】以上で、クラス宣言先頭部の処理を終え、
クラス本体部の処理を行う。Java言語におけるクラス本
体部は、メンバ宣言の並びから成っている。例えば、図
3中のクラス宣言711では、3つのメンバ"B b1"、"publi
c void foo1(B b2){...}"、"string foo2(...){...}"
がメンバ宣言である。またメンバ宣言には、「フィール
ド宣言」「メソッド宣言」の2種類ある。上の例では、
最初のものはフィールド宣言であり、後のものはメソッ
ド宣言である。
【0102】ステップ930〜970の処理は、対象のクラス
宣言CD中のこれらのメンバ宣言の各々に対して行う処理
である。クラス宣言CD中のメンバ宣言の一つを取って、
これをMDとする(ステップ930)。メンバの種類(フィ
ールド、メンバ)によって以下のいずれかの処理を行う
(ステップ931)。
【0103】まずメンバがフィールドである時には、リ
ポジトリデータベース10中にフィールドエンティティの
インスタンスFを生成し、構文解析情報より得た名称及
び修飾詞をこれに設定する(ステップ940)。そして、
生成したフィールドFをクラスCの構成メンバのリストに
加える(ステップ941)。以上がメンバがフィールドで
ある場合の処理である。
【0104】メンバがメソッドの場合には、リポジトリ
データベース10中にメソッドエンティティのインスタン
スMを生成する(ステップ950)。このメソッドMには、
構文解析情報より得た名称及び修飾詞を設定する。メソ
ッドの名称は、Javaの様にメソッド名のオーバーロード
を許す言語の場合、メソッドの名前だけでは一意にでき
ないので、メソッドの名前+パラメータ引数の型リスト
を適当に符号化したものをメソッド名称として用いる。
【0105】生成したメソッドMをクラスCの構成メンバ
のリストに加える(ステップ951)。図3のプログラム
ソース例では、クラス宣言中の3つメンバを解析するこ
とによって、図4に3つのメンバ、803a、803b、803cが
作成される。
【0106】以上で、リポジトリデータベース10の構築
処理の第1の部分の説明を終わる。第1の部分の処理を
通して、例えばリポジトリデータベース10中に図4の80
1、802a〜b、803a〜d、808の様にインスタンスが生成さ
れる。ここで、802b及び803dは、図3のソースとは別の
コンパイル単位の解析によって生成されたものである。
【0107】次に、図12のフローチャートを用いて、
リポジトリデータベース10の構築処理の第2の部分であ
る参照情報の登録について説明する。この処理は、リポ
ジトリデータベース10中の全てのパッケージ、全てのク
ラスについての2重ループ処理となっている(ステップ
1001〜1043、ステップ1010〜1042)。このループにおい
て、現在処理中のパッケージ、クラスを夫々、P、Cとす
る。
【0108】まず、構文解析情報中からクラスCに対応
するクラス宣言を取得してこれをCDとする(ステップ10
12)。クラス宣言CD中の先頭部を調べ、スーパークラス
の型名がある場合、リポジトリデータベース10中でこの
型名に対応するクラスSを検索し、クラスCに親クラスと
して格納する。これによってクラス間の継承関係128を
設定する(ステップ1013)。
【0109】以上で、クラス宣言先頭部の処理を終え、
次にステップ1020〜1041のループ処理によって、クラス
宣言の本体部のメンバ宣言(フィールド宣言、メソッド
宣言)の各々についての処理を行う。まず、クラス宣言
CDのメンバ宣言MDを一つ選び、ループ処理の変数とする
(ステップ1020)。メンバの種類によって、以下のいず
れかの処理を行う(ステップ1030)。
【0110】まず、フィールド宣言の場合の処理につい
て説明する。MDに定義されたフィールドの型を調べ、こ
れに対応するリポジトリデータベース10中のクラスC'を
対象として、参照Rを生成し、これをCに格納すること
で、クラスCからクラスC'への参照関係を設定する(ス
テップ1040)。
【0111】例えば、図4に示したリポジトリデータベ
ース10において、パッケージCOM.xxxのクラスAについて
の処理を行う場合を例を考える。メンバ宣言701 "B b
1;"は、フィールド宣言である。ここに現れた参照806c
を生成して、フィールドの型Bに対応するリポジトリデ
ータベース10中のインスタンス、クラス802bを参照806c
の対象に設定し、参照806cをクラス802aの参照リストに
格納する。
【0112】次に、メソッド宣言の場合の処理について
説明する。まず、MDに定義されたメソッドの戻り型、パ
ラメータリスト、例外リストを調べ、他のクラス型への
参照があれば、これらの夫々に対して、フィールド型の
時と同様、リポジトリデータベース10中に参照Rを生成
し、それぞれをこの参照Rの対象に設定し、クラスCの参
照リストに格納する(ステップ1050)。
【0113】例えば、先に挙げた例で"public void foo
1(B b2){ ... }"は、メソッド宣言である。このメソッ
ドは戻り型、例外リストを持たないが、パラメータリス
トでクラスBを参照している。これに対し、ステップ105
0の処理では、参照806dを生成してクラスBに相当するク
ラス802bをその対象とし、クラスAを表すクラス802aに
参照806dを格納して、クラスAからクラスBへの参照を表
現する。
【0114】さらに、メソッド宣言については、メソッ
ド本体を定義するブロックの中に現れる表式の全てを解
析し、クラスやメンバの個々の参照について以下の様な
処理を行う。これらの参照には3つの異なる形式があ
り、これに従って夫々異なる処理を行う。
【0115】第1の形式は、型名Tの直接の参照であ
る。この場合、型Tに対するリポジトリデータベース10
中のクラスC'を取り、リポジトリデータベース10中に対
象をC'として参照Rを生成し、これをCの参照リストに格
納する(ステップ1061)。再び、先に挙げた例で説明す
れば、メソッド本体部の型名の直接参照は、図3では70
3と704である。これらに対応して図3の様に、参照806e
及び参照806fを生成して、クラス802bを対象として格納
し、これらをクラス802aに格納してクラスAからクラスB
への参照を表現する。
【0116】第2の形式は、型名Qを用いたQ.idという形
式の参照である。この場合、型名Qに対するリポジトリ
データベース10中のクラスC'のメンバidを対象として参
照Rを生成し、クラスCの参照リストに加える。この形式
は、典型的には、クラスQに定義されているstaticメン
バの参照時に使用される。図3では、705の表現がこれ
に当たる。クラスBのメンバxに対するリポジトリデータ
ベース10中のインスタンス、803dを対象として参照806a
が生成される。
【0117】第3の場合として、型名で無い任意の表現Q
によるQ.idという形式である。この場合には、表式Qの
型をまず調べ、これに対応するリポジトリデータベース
10中のクラスをC'とする時、C'のメンバidを対象として
参照Rを生成し、Cの参照リストに加える(ステップ106
3)。これはもっとも一般的であり、Qの部分には、言語
の任意の形式の表現が現れうる。図3では、706、707、
708がその例である。このうち、706は、クラスBのメン
バxへの参照である。707及び708の参照は、図4のリポ
ジトリデータベース10には表現されていない。例えば、
707の型は、Bのメンバxの型を評価して初めて知る事が
できるものである。
【0118】ステップ1061〜1063の処理をメソッド本体
の要素を全て処理して終わるまで繰り返す。以上が、リ
ポジトリデータベース10の構築処理の流れの全てであ
る。図11及び図12を用いて説明した処理によって、
図3の様なプログラムソースの情報から図4の様な構造
のリポジトリデータベース10が構築される。
【0119】尚、本実施形態のソフトウェア開発支援装
置では、ソースファイル20を解析する例を示したが、Ja
va言語においてはバイトコードを解析することによって
も同等の解析が行える。組織外で開発されたライブラリ
を利用するとき等、ソースファイル20が手に入らないと
きでも、バイトコードを直接解析して上の処理を行うこ
とが出来る。
【0120】最後に図13に従って図5のステップ305
のリポジトリデータベース10及びソースファイル20の更
新処理について説明する。
【0121】図13は、本実施形態のリポジトリデータ
ベース10及びソースファイル20の更新処理の処理手順を
示すフローチャートである。ユーザが、グラフィック端
末70上で行うことが出来る操作は、1)クラスを表すシ
ンボルをマウスでドラッグし、他のパッケージを示す矩
形内に移すクラスの移動操作と、2)クラス或いはメン
バの可視性を変更する操作の2種類である。それぞれの
操作を行った場合の処理を説明する。
【0122】まず、1)の場合について図13の処理手
順(ステップ601〜612)に従って説明する。ドラッグさ
れたクラスをa、移動先の新しいパッケージをb、クラス
aが元々所属していたパッケージをcとする。処理の流れ
は以下の様になる。
【0123】クラスaから関連125を辿り、該当するパッ
ケージ宣言dを得る(ステップ601)。パッケージ宣言d
から関連132を手繰り、対応する抽象構文木ノードeを得
る(ステップ602)。得られた抽象構文木ノードeが示
す、ソースファイル20中のパッケージ名称を<パッケー
ジbの名称>に変更する(ステップ603)。パッケージ宣
言dからの関連124をパッケージbを指す様に変更し(ス
テップ604)、パッケージcの関連121からクラスaを除く
(ステップ605)と同時に、パッケージbの関連121にク
ラスaを登録する(ステップ606)。
【0124】ステップ607〜612の処理は、ループ処理
(ループA)となっており、ループ変数fには、リポジト
リデータベース10内に存在する全ての参照が順次代入さ
れる。この制御構造の基で行われる処理を以下に説明す
る。
【0125】ステップ608の処理では、参照fがクラスa
を対象として持つかどうかを調べ、参照fがクラスaを対
象として持つ場合にステップ609〜612の処理を行う。
【0126】ステップ609では、参照fを提供するクラス
の属するパッケージgを取得する。次に、パッケージbと
パッケージgとが同一かどうかを調べ(ステップ610)、
同一であれば、参照fに対応する抽象構文木ノードeの示
すソースファイル20中のクラス名の表現を、単純形式で
<クラスaの名称>とし(ステップ611)、同一ではない
場合には、完全限定された形式で<パッケージbの名称
>.<クラスaの名称>とする(ステップ612)。
【0127】次に、2)のクラス或いはメンバの可視性
を変更した場合の処理について図13のステップ621〜6
22を用いて説明する。まず、リポジトリデータベース10
中で指定されたクラス或いはメンバの可視性属性を指定
されたものに変更し(ステップ621)、その後、指定さ
れたクラス或いはメンバから関連127或いは関連129を辿
って、抽象構文木ノードの示すソースファイル20中の個
所の可視性修飾詞を変更する(ステップ622)。
【0128】以上説明した様に、本実施形態のソフトウ
ェア開発支援装置によれば、パッケージの概念をサポー
トしたクラスの管理を行い、パッケージのクラスやメン
バを図形的に表示装置に表示することにより開発者のパ
ッケージへの総合的な理解を促すと共に、開発者が表示
装置を通じてパッケージの構成を操作できる様にするの
で、開発の途中で生じるパッケージ構成の変更作業を支
援し、適切なパッケージを用いた設計を行うことが可能
である。
【0129】また、本実施形態のソフトウェア開発支援
装置によれば、パッケージ構成の変更によりアクセスが
許可されなくなった参照関係について異なる図形表示を
行うので、パッケージ構成変更時に発生する不適切なア
クセス個所を示して検討すべき個所を開発者に知らせる
と共に、クラスの相互参照関係を示して開発者のパッケ
ージ設計時の判断を支援することが可能である。
【0130】また、本実施形態のソフトウェア開発支援
装置によれば、クラスやメンバの可視性の変更指示に従
ってソースファイル中の可視性修飾詞を書き換えるの
で、クラス或いはメンバの可視性の変更を表示装置上で
指示し、アクセス許可を考慮に入れたパッケージの設計
を表示装置を通じて行うことが可能である。
【0131】
【発明の効果】本発明によれば、パッケージの概念をサ
ポートしたクラスの管理を行い、パッケージのクラスや
メンバを図形的に表示装置に表示することにより開発者
のパッケージへの総合的な理解を促すと共に、開発者が
表示装置を通じてパッケージの構成を操作できる様にす
るので、開発の途中で生じるパッケージ構成の変更作業
を支援し、適切なパッケージを用いた設計を行うことが
可能である。
【図面の簡単な説明】
【図1】本実施形態のソフトウェア開発支援装置の概略
構成を示す図である。
【図2】本実施形態のリポジトリデータベース10のデー
タモデルを示す図である。
【図3】本実施形態のJava言語のソースファイル20の一
例を示す図である。
【図4】本実施形態の図3のソースファイル20を解析し
た情報を登録したリポジトリデータベース10の内部のデ
ータ構造を示す図である。
【図5】本実施形態のソフトウェア開発支援装置の処理
概略を示す図である。
【図6】本実施形態のパッケージ−クラス構造の表示画
面の一例を示す図である。
【図7】本実施形態のリポジトリ可視化処理の処理手順
を示すフローチャートである。
【図8】本実施形態のパッケージa中のクラスbからの参
照cについてのアクセス許可性を判定する処理の処理手
順を示すフローチャートである。
【図9】本実施形態のクラスアクセス許可テーブル31の
一例を示す図である。
【図10】本実施形態のソフトウェア開発支援装置のメ
ンバアクセス許可テーブル32の一例を示す図である。
【図11】本実施形態のソース解析部50の第1の処理の
処理手順を示すフローチャートである。
【図12】本実施形態のソース解析部50の第2の処理の
処理手順を示すフローチャートである。
【図13】本実施形態のリポジトリデータベース10及び
ソースファイル20の更新処理の処理手順を示すフローチ
ャートである。
【符号の説明】
10…リポジトリデータベース、15…構文解析情報データ
ベース、20…ソースファイル、31…クラスアクセス許可
テーブル、32…メンバアクセス許可テーブル、70…グラ
フィック端末、30…リポジトリ可視化部、40…プログラ
ム修正部、50…ソース解析部、60…表示制御部、101…
パッケージ、102…クラス、103…メンバ、104…フィー
ルド、105…メソッド、106…参照、107…参照対象、108
…パッケージ宣言、109…抽象構文木ノード、121…関
連、122…関連、123…継承関係、124…関連、125…関
連、126…関連、127…関連、128…関連、129…関連、13
0…関連、131…関連、132…関連、133…継承関係、701
〜704…クラス参照の例、705〜708…メンバ参照の例、7
09…パッケージ宣言、710…インポート宣言、711…クラ
ス宣言、801…パッケージ、802…クラス、803…メン
バ、806…参照、808…パッケージ宣言、821…関連、822
…関連、825…関連、826…関連。

Claims (3)

    【特許請求の範囲】
  1. 【請求項1】 モジュール化の概念をパッケージという
    形で取り入れたソフトウェア開発を支援するソフトウェ
    ア開発支援装置であって、 ソースファイルを解析し、各パッケージを構成するクラ
    ス及びメンバの情報を登録したリポジトリデータベース
    と、解析の結果得られた構文解析情報を登録した構文解
    析情報データベースとを作成するソース解析部と、 前記リポジトリデータベース中の情報を可視化してクラ
    ス及びメンバのシンボルとクラス及びメンバの参照関係
    を示す図形データを作成するリポジトリ可視化部と、 前記作成した図形データをグラフィック端末へ表示する
    と共に当該ソースファイルのパッケージ構成を変更する
    指示を受け付ける表示制御部と、 前記表示制御部を介して受けた指示に従って、リポジト
    リデータベース、構文解析情報データベース及びソース
    ファイルの内容を更新し、当該ソースファイルのパッケ
    ージ構成を変更するプログラム修正部とを備えることを
    特徴とするソフトウェア開発支援装置。
  2. 【請求項2】 前記ソース解析部は、クラス及びメンバ
    それぞれの可視性を示す情報を前記リポジトリデータベ
    ースに登録し、前記リポジトリ可視化部は、クラス及び
    メンバのシンボルとクラス及びメンバの参照関係を示す
    図形データの内容をその可視性に応じて変更するもので
    あることを特徴とする請求項1に記載されたソフトウェ
    ア開発支援装置。
  3. 【請求項3】 前記プログラム修正部は、クラスやメン
    バの可視性の変更指示に従って前記リポジトリデータベ
    ース中の可視性を示す情報を変更し、更にこれを反映し
    て当該ソースファイル中の可視性修飾詞を書き換えるも
    のであることを特徴とする請求項2に記載されたソフト
    ウェア開発支援装置。
JP10182200A 1998-06-29 1998-06-29 ソフトウェア開発支援装置 Pending JP2000020298A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP10182200A JP2000020298A (ja) 1998-06-29 1998-06-29 ソフトウェア開発支援装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP10182200A JP2000020298A (ja) 1998-06-29 1998-06-29 ソフトウェア開発支援装置

Publications (1)

Publication Number Publication Date
JP2000020298A true JP2000020298A (ja) 2000-01-21

Family

ID=16114113

Family Applications (1)

Application Number Title Priority Date Filing Date
JP10182200A Pending JP2000020298A (ja) 1998-06-29 1998-06-29 ソフトウェア開発支援装置

Country Status (1)

Country Link
JP (1) JP2000020298A (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20010112753A (ko) * 2000-06-15 2001-12-22 김윤호 형상 관리 시스템 및 방법
WO2007083399A1 (ja) * 2006-01-17 2007-07-26 Matsushita Electric Industrial Co., Ltd. 情報処理端末、プログラム
JP2008176364A (ja) * 2007-01-16 2008-07-31 Hitachi Ltd プログラム部品化支援装置
WO2008146341A1 (ja) * 2007-05-25 2008-12-04 Fujitsu Limited 業務フロー図生成プログラム、業務フロー図生成装置および業務フロー図生成方法
WO2017176086A1 (ko) * 2016-04-08 2017-10-12 ㈜투비소프트 스크립트 기반 어플리케이션 개발방법

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20010112753A (ko) * 2000-06-15 2001-12-22 김윤호 형상 관리 시스템 및 방법
WO2007083399A1 (ja) * 2006-01-17 2007-07-26 Matsushita Electric Industrial Co., Ltd. 情報処理端末、プログラム
JP2008176364A (ja) * 2007-01-16 2008-07-31 Hitachi Ltd プログラム部品化支援装置
WO2008146341A1 (ja) * 2007-05-25 2008-12-04 Fujitsu Limited 業務フロー図生成プログラム、業務フロー図生成装置および業務フロー図生成方法
JP4796185B2 (ja) * 2007-05-25 2011-10-19 富士通株式会社 業務フロー図生成プログラム、業務フロー図生成装置および業務フロー図生成方法
WO2017176086A1 (ko) * 2016-04-08 2017-10-12 ㈜투비소프트 스크립트 기반 어플리케이션 개발방법

Similar Documents

Publication Publication Date Title
US8566782B2 (en) Generating application data editors
US7171646B2 (en) Generating source code for object oriented elements with language neutral transient meta model and correlating display of names, symbols and code
US7114149B2 (en) Navigation links in generated documentation
US6993759B2 (en) Diagrammatic control of software in a version control system
US7055130B2 (en) Methods and systems for identifying dependencies between object-oriented elements
US7810069B2 (en) Methods and systems for relating data structures and object-oriented elements for distributed computing
US8171449B2 (en) Generating sequence diagrams using call trees
US6851107B1 (en) Software development tool with instant updating and simultaneous view of graphical and a textual display of source code
US6408430B2 (en) Interactive software testing system and method
US6993710B1 (en) Method and system for displaying changes of source code
US7055131B2 (en) Methods and systems for animating the interaction of objects in an object oriented program
US6976243B2 (en) Method and system for developing source code and displaying linked elements found within the source code
US7437722B2 (en) Determining which software component versions of an issue resolution are included in a version of a software development project at a particular time
US20070234316A1 (en) Methods and systems for development of software for complex systems
JPH08512152A (ja) インクリメンタル生成システム
US20120110560A1 (en) Data type provider for a web semantic store
US20120110548A1 (en) Data type provider for an operating system instrumentation store
JP2000020298A (ja) ソフトウェア開発支援装置
JP4939007B2 (ja) システム設計支援プログラム
Borgfeld Tool Support for Layout Algorithm Development with ELK
Paige et al. Model management in the wild
Cooper et al. Using dependence graphs to assist manual and automated object oriented software inspections
OliveiraJr et al. Designing, Tracing, and Configuring Software Product Lines with SMarty
Śmiałek et al. Writing Model Transformations for Requirements
Ducasse et al. Project-Team RMoD (Analyses and Language Constructs for Object-Oriented Application Evolution) 2011 Activity Report