JP2002157120A - 設計ドキュメント管理システム - Google Patents

Abstract

(57)【要約】 【課題】 同一の設計ドキュメントに対して複数のレイ
アウト情報を適用して目的に応じた表現方法を選択でき
るようにし、同時にドキュメントに対する検索や更新等
の処理をシンプルかつ効率的に行なえるようにする。 【解決手段】 ダイアグラムを含む設計ドキュメントに
ついて、ダイアグラムに現れる構成要素に関して論理的
な内容を記述した論理情報とダイアグラム上のレイアウ
ト情報とに分離してそれぞれの対応関係を管理する手段
と、分離したそれぞれの情報をオープンな形式で保存・
交換する手段とを備える。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ソフトウェア開発
における設計ドキュメントの管理システムに関し、特に
オブジェクト指向開発でのＵＭＬ(Unified Modeling La
nguage)を用いた設計ドキュメントを効率良く管理する
ためのシステムに関するものである。

【０００２】

【従来の技術】近年のソフトウェア開発では、システム
の分析・設計・実装が効率良く行なえるオブジェクト指
向開発手法が一般的に採り入れられるようになってきて
いる。オブジェクト指向開発手法の普及に伴い、ソフト
ウェアの開発過程において作成する設計ドキュメントの
一部として、ＵＭＬ記法に基づくクラス図やシーケンス
図を記述することが多くなってきた。これらの設計ドキ
ュメントは開発過程を通して全ての設計者と実装者が参
照すべきものであるが、その保存形式はベンダの提供す
るＣＡＳＥツールごとに独自に規定された形式である場
合が多い。従って、設計ドキュメントを参照するために
は、そのドキュメントを作成したＣＡＳＥツールもしく
はドキュメントデータの形式に互換性のあるＣＡＳＥツ
ールが必要となる。

【０００３】ドキュメントの保存形式に互換性の無いＣ
ＡＳＥツール同士でもデータ変換を行なえば、ドキュメ
ントデータを互いに利用できる場合もある。ＯＭＧ(Obj
ectManagement Group)では、ＵＭＬを包含した一般的な
メタデータモデルを定義し、それをＸＭＬ(Extensible
Markup Language)形式で記述するＸＭＩ(ＸＭＬ Metada
ta Interchange)仕様を策定している。ＸＭＩ対応のＣ
ＡＳＥツールどうしならばオリジナルのドキュメントデ
ータの形式に互換性が無くても、ＸＭＩを介することに
よってドキュメントデータを交換することができる。

【０００４】一方、設計ドキュメントをＨＴＭＬ化して
Ｗｅｂを通して参照するという形態も多く見られるよう
になってきている。Rational社が販売するＣＡＳＥツー
ルであるRoseでは、ＵＭＬで記述された設計ドキュメン
トをＨＴＭＬ形式に変換する機能が提供されている。こ
の機能を利用すれば、ソフトウェアの設計者がRoseを使
ってドキュメントを書き、それをＨＴＭＬに変換したも
のをプログラマがＷｅｂブラウザを通して参照するとい
う使い方ができるようになる。全ての開発者にＣＡＳＥ
ツールが行き渡らないような場合はこの形態が有効にな
る。

【０００５】

【発明が解決しようとする課題】しかし、実際の開発現
場では設計ドキュメントが効率的に運用されているケー
スは少ない。それはＵＭＬによる設計ドキュメントを管
理する機能を提供する環境が十分に整備されていないか
らであり、特に以下の事柄が課題として挙げられる。 （１）ドキュメント内に含まれている情報に対する問合
せ機能が十分ではない。例えば、クラス名からそのクラ
スを含むダイアグラムを検索できる機能が提供されてい
ない。 （２）設計ドキュメントの中から必要な部分だけを適宜
取り出すことが難しい。例えば、特定のクラスの仕様を
印刷したい場合に、必ずしもクラス図全体を参照する必
要はない。 （３）論理的に同じ内容のドキュメントを異なるレイア
ウトで表示・印刷させることができない。ダイアグラム
のレイアウトが設計者の一存で固定されてしまい、目的
に応じて柔軟に表示方法を変更することができない。 （４）既存の設計ドキュメントとの組合せ利用が難し
い。例えば、ワープロを用いて作成されたバグ票とクラ
ス図をリンクして双方向に参照できるような機能が提供
されていない。 （５）リンクや検索、更新処理などを含めて、設計ドキ
ュメントを統一的に管理するための環境が整っていな
い。

【０００６】一方、実際の開発現場ではプログラミング
の段階になってから設計上の不備が見つかり、設計変更
が余儀なくされる事が珍しくない。特に、オブジェクト
指向開発では部分的な設計と実装を繰り返すスパイラル
型の開発が奨励されるようになってきている。しかし、
各設計者がスタンドアロンでＣＡＳＥツールを利用する
ような環境では、頻繁に発生するドキュメントの変更に
よるバージョンの不整合が発生し易くなる。そのため、
ＣＡＳＥツール中心でドキュメントデータを交換すると
いう運用ではなく、ドキュメントデータを中心として、
それを操作・管理するサービスを提供する環境が必要で
ある。また、新しいサービスを容易に提供できるように
するためには、プログラムの開発が容易になるように、
設計ドキュメントをオープンな形式で保存する必要があ
る。

【０００７】本発明の目的は、同一の設計ドキュメント
に対して複数のレイアウト情報を適用して目的に応じた
表現方法を選択できるようにし、同時にドキュメントに
対する検索や更新等の処理をシンプルかつ効率的に行な
うことができる設計ドキュメント管理システムを提供す
ることにある。また、ＵＭＬで記述されたドキュメント
に対して、検索や更新を含む問合せ処理やＷｅｂブラウ
ザ上で表示する操作をスムーズにすることができる設計
ドキュメント管理システムを提供することにある。

【０００８】

【課題を解決するための手段】上記目的を達成するため
に、本発明は、ダイアグラムを含む設計ドキュメントに
ついて、ダイアグラムに現れる構成要素に関して論理的
な内容を記述した論理情報とダイアグラム上のレイアウ
ト情報とに分離してそれぞれの対応関係を管理する手段
と、分離したそれぞれの情報をオープンな形式で保存・
交換する手段とを備えることを特徴とする。また、前記
設計ドキュメントの論理情報を対応するレイアウト情報
に基づいてブラウザ上に出力する手段をさらに備えるこ
とを特徴とする。また、前記ドキュメントに対する問合
せ手段をさらに備えることを特徴とする。さらに、前記
設計ドキュメントを前記問合せ手段による問合せで指定
された出力要求に適合するように変換する手段をさらに
備えることを特徴とする。

【０００９】

【発明の実施の形態】以下、本発明の実施の形態を図面
を用いて詳細に説明する。図1は、本発明を適用した設
計ドキュメント管理システムの一実施の形態を示すシス
テム構成図である。本実施形態では、ＵＭＬによる設計
ドキュメントについて、クラス仕様票などの、ダイアグ
ラムの図形的な情報に関わらない論理的な部分(以下、
論理情報)と、各クラスの情報をダイアグラム中に描画
する位置や線の太さ、フォント等を指定するレイアウト
情報とに分離し、それぞれ論理情報ＤＢ（１０１）とレ
イアウト情報ＤＢ（１０２）に格納している。

【００１０】論理情報は論理情報作成・登録手段（１０
３）で作成し、論理情報ＤＢ（１０１）に登録する。レ
イアウト情報も同様に、レイアウト作成・登録手段（１
０６）で作成したものをレイアウト情報ＤＢ（１０２）
に登録する。論理情報検索・更新手段（１０４）は、与
えられた条件を満たす論理情報の一部または全部を論理
情報ＤＢ（１０１）から取り出す。同様に、レイアウト
取得手段（１０５）は、指定された論理情報に対応する
レイアウト情報をレイアウト情報ＤＢ（１０２）から取
り出す。

【００１１】ドキュメント変換手段（１０７）は、それ
ぞれ取り出したレイアウト情報と論理情報から、指定の
形式のドキュメントを変換・合成して出力する。指定す
る形式は、ＨＴＭＬ文書の場合であったり描画用ベクト
ルデータであったりする。ＷＷＷサーバ（１０８）は、
ドキュメント変換手段（１０７）の出力をネットワーク
を通してクライアントへ送出する。クライアント上のＷ
ＷＷブラウザ（１０９）は取得したＨＴＭＬ文書を表示
するか、もしくはアプレット等で実現されたドキュメン
ト描画手段（１１０）を用いて、取得した描画用ベクト
ルデータからダイアグラムを描画する。以降では、ＵＭ
Ｌを用いた設計ドキュメントで頻繁に使用されるクラス
図とシーケンス図、およびそれらに含まれる論理情報の
それぞれの記述例とレイアウト情報の記述例を示し、ド
キュメント変換手段（１０７）がそれらを基にドキュメ
ントデータ出力する方法を、図を交えて詳しく説明す
る。本実施形態では、論理情報とレイアウト情報の記述
方法としてＸＭＬを採用している。

【００１２】図２は、ＵＭＬによるクラス図の一例であ
る。この例ではClientクラス（２０１）、ArticleServe
rクラス（２０２）、Articleクラス（２０３）の3つの
クラスがそれぞれ矩形で表現されている。Clientクラス
（２０１）には、引数を取らず戻り値の無いshowArticl
esメソッドが定義されている。ArticleServerクラス
（２０２）には、String型の引数conditionを受け取
り、Articleオブジェクトの配列を返すsearchメソッド
が定義されている。

【００１３】Articleクラス（２０３）では、全てStinr
g型でpublicな3つの属性title、date、textと、String
型の引数wordを受け取りboolean型の値を返すisContain
edメソッドが定義されている。Clientクラス（２０１）
とArticleServer（２０２）クラスの間の関連は直線
（２０４）で表現され、両端に多重度、ArticleServer
側にロール名が設定されている。同様に、Clientクラス
（２０１）とArticleクラス（２０３）との間の関連も
直線（２０６）で表され、多重度とロール名が設定され
ている。ArticleServerクラス（２０２）とArticleクラ
ス（２０３）との間は集約の関連があり、ひし形のつい
た直線（２０５）で表現されており、他の関連と同様に
多重度とロール名が設定されている。

【００１４】図３及び図４は、図２のようなクラス図に
表れているクラスや関連等の論理構造を規定するための
記述であり、ＸＭＬのＤＴＤ(Document Type Definitio
n)の書き方に従っている。このＤＴＤ（３０１）は本実
施形態のために作成した一例であり、本発明は本実施形
態中で挙げた例以外のＤＴＤを用いて実現しても良い。
（３０２）はこのクラス図がクラス（３０４）と関連
（３１０）の記述の繰り返しとして記述される構造であ
ることを表している。（３０３）ではクラスや引数の名
前と型、デフォルト値の内容が文字列で表されることを
規定している。（３０４）はクラスの構造を規定し、こ
こではクラスが一つの名前と０個以上の属性、０個以上
のメソッド、他のクラスとの０個以上の関連から構成さ
れると規定している。同様に（３０５）では属性が、型
と名前、そしてデフォルト値から構成され、デフォルト
値は無くても良いことを規定している。（３０６）では
メソッドが一つの名前と０個以上の引数、そして返り値
から構成され、返り値が無くても良いことを規定してい
る。

【００１５】（３０７）ではメソッドの引数が型と名前
と省略可のデフォルト値から構成されること、（３０
８）でメソッドの返り値が型から成ることが規定されて
いる。（３０９）ではクラスが持つ関連が、（３１０）
のrelationへの参照として規定されている。（３１０）
は関連自体の内容を規定し、省略可の名前と、二つの終
端から成っている。（３１１）と（３１２）はクラス
（３０４）への参照によって関連の終端を表し、同時に
ロール名と多重度を持つ。ロール名（３１３）は文字列
で表され、可視性を規定する。（３１４）は４種類の多
重度の書き方を規定している。

【００１６】図５〜図７は、図３のＤＴＤに従って、図
２のクラス図に含まれる論理情報を記述したＸＭＬデー
タである。図は紙面の都合で分割されているだけであ
り、図５〜図７をつなげたものが一つのドキュメント
(ここではクラス図)の論理情報を表す。図５のＸＭＬデ
ータ(５０１)は、図２に現れる各クラスの内容を記述し
ている。(５０２)はこのＸＭＬデータが図３のＤＴＤに
基づいていることを表す。(５０３)は図２のClientクラ
ス(２０１)の論理構造を記述している。Clientクラス
(２０１)には属性は無いのでその部分の記述は省略され
ている。(５０４)はArticleServerクラス(２０２)の論
理構造を記述している。同様に(５０５)はArticleクラ
ス(２０３)の論理構造を記述している。

【００１７】図７のＸＭＬデータは、各クラス間の関連
について記述している。(７０１)はClientクラス(２０
１)とArticleServerクラス(２０２)との間の関連(２０
４)の論理構造を記述したものであり、両端の多重度や
ロール名を記述している。同様に、(７０２)はArticleS
erverクラス(２０２)とArticleクラス(２０３)との間の
関連(２０５)の論理構造を記述したものである。こちら
は集約の関連なので属性rel#typeの値が”aggregatio
n”に設定されている。(７０３)はClientクラス(２０
１)とArticleクラス(２０３)との間の関連(２０６)の論
理構造を記述したものである。

【００１８】ＵＭＬではクラス図以外にも様々なダイア
グラムがあり、その中でシーケンス図は記述される頻度
が高いので一例を図８に示す。シーケンス図は各クラス
のインスタンスでどのようなメッセージが送られるか
(どのメソッドを呼び出すか)の時系列を示したものであ
る。(８０１)は図２に示したClientクラス(２０１)のイ
ンスタンスを表す。(８０２)も同様に図２のArticleSer
verクラス(２０２)のインスタンスを表す。(８０３)と
(８０４)は、共にArticleクラス(２０３)のそれぞれ別
個のインスタンスである。このシーケンス図では、まず
Clientオブジェクト(８０１)が、ArticleServerオブジ
ェクト(８０２)のsearchメソッドを呼び出している(８
０５)。次にArticleServerオブジェクト(８０２)は、Ar
ticleオブジェクトatl01(８０３)とatl02(８０４)のそ
れぞれのisContainedメソッドを呼び出している(８０
６，８０７)。最後に、Clientオブジェクト(８０１)が
自分自身のshowArticlesメソッドを呼び出している(８
０８)。

【００１９】図９は図８のようなシーケンス図の論理情
報を規定するための記述であり、これも本実施例形態用
に作成したＤＴＤの一例である。図１０及び図１１は図
９のＤＴＤに基づいて図８のシーケンス図を記述したＸ
ＭＬデータである。図１０の(１００１)はヘッダ情報を
表し、図８のシーケンス図の名前やバージョンを記述し
ている。(１００２)はClientオブジェクト(８０１)に関
する記述である。同様に、(１００３)、(１００４)、
(１００５)はArticleServerオブジェクト(８０２)、Art
icleオブジェクトacl01(８０３)、Articleオブジェクト
acl02(８０４)に関する記述である。(１００６)は、図
８のsearchメッセージ(８０５)に関する記述であり、こ
のメッセージがClientオブジェクト(１００１)からArti
cleServerオブジェクト(１００２)に向けてのものであ
ることと、このメッセージの名前および引数を記述して
いる。(１００７)と(１００８)は、それぞれ図８のメッ
セージisContained(８０６，８０７)の内容を記述した
ものであり、(１００９)はメッセージshowArticles(８
０８)の内容を記述したものである。

【００２０】以上に述べたＸＭＬによる論理情報を用い
て、図２や図８のようなダイアグラムをブラウザ上に描
画する際のレイアウトを指定するレイアウト情報の実施
形態を次に示す。本実施形態ではレイアウト情報をウェ
ルフォームドなＸＭＬで記述する。図１２はレイアウト
情報の一例である。この例では、各クラス及び関連ごと
にレイアウト情報を記述している。この実施形態では、
レイアウト情報はlayoutタグで始まる。layoutタグの属
性で、単位はミリメートルで、クラス図に関するレイア
ウトであることを示している。(１２０１)は図２のClie
ntクラス(２０１)を描画するために指定するレイアウト
指定を表し、ここではクラスの属性やメソッドのシグネ
チャを表示すること、クラスを表す矩形のサイズはアプ
リケーションに任せること、クラスを表す矩形をその左
上が原点を起点として横方向に30ミリ、縦方向に20ミリ
の位置に配置することを指定している。

【００２１】同様に、(１２０２)はArticleServerクラ
ス(２０２)を描画するためのレイアウト指定であり、こ
の例では矩形の大きさが横50ミリ縦18ミリで、Clientク
ラス(２０１)の中心から横方向に30ミリ、縦方向に0ミ
リの位置に配置することを指定している。同様に、(１
２０３)はArticleクラス(２０３)のレイアウト指定で、
ArticleServerクラス(２０２)の中心から横方向に0ミ
リ、縦方向に35ミリの位置に配置することを指定する。
(１２０４)は関連(２０４)のレイアウト指定であり、ri
ght-angledの属性値により、この関連は水平方向の線分
と垂直方向の線分のみで描画するよう指定している。ま
たlocationタグのbase属性の値”center”は線分がクラ
スの矩形の中心に向かうように描画することを指定す
る。(１２０５)および(１２０６)はそれぞれ関連(２０
５)と関連(２０６)のレイアウト指定である。

【００２２】図５〜図７に示した論理情報とそれに対応
する図１２のレイアウト情報を元に、ドキュメント変換
手段(１０７)は実際にブラウザ上にダイアグラムを描画
するためのベクトルデータを作成する。もしくは、単に
文書として表示するためのＨＴＭＬデータを作成する。
ドキュメント変換手段(１０７)は、レイアウト情報に指
定されていないデフォルトの描画情報を持つ。例えば、
関連(２０５)は集約の関連なので描画する際にはひし形
を付与する必要があるが、本実施形態ではレイアウト情
報で特に指定しなくてもドキュメント変換手段(１０７)
がデフォルトの設定で付与する。また、線の太さやフォ
ント等の情報も同様に、特にレイアウト情報で特に指定
しないものはデフォルトの設定を用いる。描画用ベクト
ルデータやデフォルト値の設定データの形式は、既に多
くのドローツール等で実現されているので省略する。

【００２３】図１３に、ドキュメント変換手段がドキュ
メントとレイアウト情報からベクトルデータを作成する
処理のフローチャートを示す。まず、指定されたクラス
図の論理情報を表すＸＭＬデータをスキャンし、クラス
情報すなわちclassタグを見つけ出す(ステップ１３０
１)。もし、まだ処理していないclassタグが見つからな
ければ関連の処理に移る(ステップ１３０２)。classタ
グがある場合は、レイアウト情報からそのクラス名に対
応するレイアウト指定を探し出し取り出す(ステップ１
３０３)。もし対応するレイアウト指定が見つからなか
った場合は(ステップ１３０４)、そのクラスの描画デー
タは作成せず、次のクラス情報を取り出すべくステップ
１３０１へ戻る。もしレイアウト指定が見つかった場合
は、その内容に応じて描画データを作成する(ステップ
１３０５)。この部分の詳細は図１４に示す。描画デー
タを作成したら次のクラス情報を取り出すべくステップ
１３０１へ戻る。

【００２４】指定されたクラス図の全てのクラス情報を
処理し終わったならば、次に関連の情報を取り出す(ス
テップ１３０６)。クラスの場合と同様に、まだ処理し
ていない関連の情報が無い場合は(ステップ１３０７)、
これまでに作成した描画データを出力(ステップ１３０
１)して終了する。まだ処理していない関連の情報があ
る場合は、その関連に対応するレイアウト指定をレイア
ウト情報から取り出す(ステップ１３０８)。もし対応す
るレイアウト指定が見つからなかった場合は(ステップ
１３０９)、その関連の描画データは作成しない。対応
するレイアウト指定が見つかった場合は、その内容に基
づいて描画データを作成する(ステップ１３１０)。この
部分の詳細はクラスの場合と同様の処理であり、図１４
に示す。描画データを作成したら、次の関連のデータを
取り出すべくステップ１３０６へ戻る。

【００２５】図１４は、描画データを作成する処理の詳
細を示すフローチャートである。まず、ドキュメント変
換手段（１０７）が保持するデフォルトの描画データの
中から、描画する対象の種類(クラスまたは関連)に応じ
た描画データを取り出す(ステップ１４０１)。次に、図
１３の処理で読み出したレイアウト指定の中に含まれて
いる指定項目を一つ取り出す(ステップ１４０２)。もし
まだ処理していない指定項目が無い場合は(ステップ１
４０３)終了する。まだ処理していない指定項目があっ
た場合は、ステップ１４０１で読み出したデフォルト描
画データの中の、レイアウト指定項目に対応する部分を
その指定内容に応じて書き換える(ステップ１４０４)。
書き換えたら次のレイアウト指定項目を処理すべくステ
ップ１４０２に戻る。

【００２６】このようにドキュメント変換手段(１０７)
によって作成した描画データは、ＷＷＷサーバ(１０８)
を通してクライアントに渡され、ドキュメント描画手段
(１０９)によってブラウザ(１０９)上に表示される。シ
ーケンス図の場合も同様の処理によって描画データを作
成することができる。また、このようなシステム構成に
することによって、一つのクラス図の論理情報に対して
複数のレイアウト情報を用意して選択できるようにする
ことが容易に実現可能となる。

【００２７】次に、ＵＭＬによる設計ドキュメントによ
る問合せ処理の流れを図1５のフローチャートに示す。
ブラウザ（１０９）はフォームなどの既存の仕組みを用
いて問合せ内容をＷＷＷサーバ（１０８）に送る(ステ
ップ１５０１)。問合せ内容には、問合せ条件と出力す
べき内容(クラス図や仕様書)が指定されている。ＷＷＷ
サーバ（１０８）は受け取った問合せを論理情報検索・
更新手段に送る(ステップ１５０２)。論理情報検索・更
新手段は、問合せ条件を満たす論理情報を論理情報ＤＢ
（１０１）から検索する(ステップ１５０３)。もし、問
合せ条件を満たす論理情報が見つからなければ(ステッ
プ１５０４)、該当するドキュメントが存在しない旨を
示すデータをＨＴＭＬ形式等で作成して(ステップ１５
１０)、結果をブラウザ（１０９）に返す(ステップ１５
１１)。

【００２８】問合せ条件を満たす論理情報が見つかった
場合は、ドキュメント変換手段は問合せの中で指定され
ている出力形式に応じて、予めXSLTスタイルシート等で
記述しておいた変換ルールを選択する(ステップ１５０
５)。ここで、問合せの中に指定されている出力の形式
を調べ(ステップ１５０６)、もし出力形式がＵＭＬダイ
アグラムの場合は、レイアウト取得手段（１０５）を通
して対応するレイアウト情報を取り出し(ステップ１５
０７)、ダイアグラム描画用ベクトルデータに変換する
(ステップ１５０８)。もし出力形式がＨＴＭＬの場合は
変換ルールを用いてドキュメントをＨＴＭＬ形式に変換
する(ステップ１５０９)。そして変換結果をブラウザ
（１０９）に返して終了する(ステップ１５１１)。

【００２９】ＵＭＬによる設計ドキュメントの一部を更
新する処理の流れを図１６のフローチャートに示す。ブ
ラウザ（１０９）はフォームなどの既存の仕組みを用い
て更新内容をＷＷＷサーバ（１０８）に送る(ステップ
１６０１)。問合せ内容には、検索の場合と同様の問合
せ条件と、更新すべき論理情報の指定と更新する値が含
まれる。ＷＷＷサーバ（１０８）は受け取った問合せを
論理情報検索・更新手段（１０４）に送る(ステップ１
６０２)。論理情報検索・更新手段（１０４）は、問合
せ条件を満たす論理情報を論理情報ＤＢ（１０１）から
検索する(ステップ１６０３)。もし、問合せ条件を満た
す論理情報が見つからなければ(ステップ１６０４)、該
当するドキュメントが存在しない旨を示すデータを作成
して(ステップ１６１１)、ブラウザに返す(ステップ１
６１２)。

【００３０】問合せ条件を満たす論理情報が見つかった
場合は、論理情報検索・更新手段（１０４）は、取得し
た論理情報をロックする(ステップ１６０５)。ロックの
正否を調べ(ステップ１６０６)、もし失敗していた場合
は、更新付加の旨を示すデータを作成して(ステップ１
６１０)、ブラウザ（１０９）に返す(ステップ１６１
２)。ロックに成功した場合は、論理情報検索・更新手
段（１０４）は、与えられた更新情報に従って論理情報
の内容を更新し(ステップ１６０７)、論理情報ＤＢ（１
０１）に格納してロックを解除する(ステップ１６０
８)。次に、更新処理成功の旨を示すＨＴＭＬデータを
作成して(ステップ１６０９)、ブラウザ（１０９）に返
す(ステップ１６１２)。

【００３１】

【発明の効果】以上説明したように本発明によれば、オ
ブジェクト指向開発におけるＵＭＬを用いた設計ドキュ
メントについて、設計ドキュメントに含まれる論理的な
構造とレイアウト情報を明確に分離して一元的に管理す
ることで、同一の設計ドキュメントに対して複数のレイ
アウト情報を適用して目的に応じた表現方法を選択でき
るようにし、同時にドキュメントに対する検索や更新等
の処理をシンプルかつ効率良く行なえるようになる。ま
た、論理情報およびレイアウト情報をＸＭＬ等のオープ
ンかつ構造を保持できる形式で管理することにより、Ｕ
ＭＬで記述されたドキュメントに対して、検索や更新を
含む問合せ処理やＷｅｂブラウザ上で表示する操作をス
ムーズに提供することができるといった効果が得られ
る。

【図面の簡単な説明】

【図１】本発明を適用した設計ドキュメント管理システ
ムの実施形態を示すブロック図である。

【図２】ＵＭＬによるクラス図の例を示す図である。

【図３】クラス図に含まれる論理情報を規定するための
ＤＴＤの例を示す図である。

【図４】図３の続きを示す図である。

【図５】クラス図に含まれる論理情報のうちクラスにつ
いて記述した例を示す図である。

【図６】図５の続きを示す図である。

【図７】クラス図に含まれる論理情報のうち関連につい
て記述した例を示す図である。

【図８】ＵＭＬによるシーケンス図の例を示す図であ
る。

【図９】シーケンス図に含まれる論理情報を規定するた
めのＤＴＤの例を示す図である。

【図１０】シーケンス図に含まれる論理情報について記
述した例を示す図である。

【図１１】図１０の続きを示す図である。

【図１２】クラス図を描画するためのレイアウト指定の
記述例を示す図である。

【図１３】クラス図の論理情報とレイアウト情報を元に
ダイアグラム描画データを生成する処理の概略フロー図
である。

【図１４】レイアウト指定から描画データに変換する部
分の概略フロー図である。

【図１５】本発明におけるドキュメントの検索処理の概
略を示すフロー図である。

【図１６】本発明におけるドキュメントの更新処理の概
略を示すフロー図である。

【符号の説明】

１０１…論理情報ＤＢ、１０２…レイアウト情報ＤＢ、
１０３…論理情報作成・登録手段、１０４…論理情報検
索・更新手段、１０５…レイアウト取得手段、１０６…
レイアウト作成・登録手段、１０７…ドキュメント変換
手段、１０８…ＷＷＷサーバ、１０９…Ｗｅｂブラウ
ザ、１１０…ドキュメント描画手段。

Claims (4)

【特許請求の範囲】
1. 【請求項１】 ソフトウェア開発における設計ドキュメ
   ントの管理システムであって、 ダイアグラムを含む設計ドキュメントについて、ダイア
   グラムに現れる構成要素に関して論理的な内容を記述し
   た論理情報とダイアグラム上のレイアウト情報とに分離
   してそれぞれの対応関係を管理する手段と、 分離したそれぞれの情報をオープンな形式で保存・交換
   する手段とを備えることを特徴とする設計ドキュメント
   管理システム。
2. 【請求項２】 前記設計ドキュメントの論理情報を対応
   するレイアウト情報に基づいてブラウザ上に出力する手
   段をさらに備えることを特徴とする請求項1に記載の設
   計ドキュメント管理システム。
3. 【請求項３】 前記ドキュメントに対する問合せ手段を
   さらに備えることを特徴とする請求項1または２に記載
   の設計ドキュメント管理システム。
4. 【請求項４】 前記設計ドキュメントを前記問合せ手段
   による問合せで指定された出力要求に適合するように変
   換する手段をさらに備えることを特徴とする請求項３に
   記載の設計ドキュメント管理システム。