XML
を用いたソフトウェア関連文書とソースプロ
グラムの整合性検査ツール
Tool to Check the Consistency both Software Documents Using XML and Source Programs
戸板 晃一
∗山本 晋一郎
†阿草 清滋
‡Summary. Generally, a software consists of source programs and soft-ware documents. Programmers, however, tend to describe source pro-grams in a software development process. By this tendency, the revision of software documents with the modification of source programs delays, and the discordance turns up among source programs and software doc-uments. Resolving these problems, we need an integrated management system of both source programs and software documents.
In this paper, we describe integrated management both software docu-ments and source programs. We realize the tool to check the consistency among them and evaluate it.
1
はじめに
最近では、ソフトウェアの開発を支援するためにさまざまなCASEツールが実用 化されている．しかし，ソフトウェアはソースプログラムとソフトウェア関連文書 から構成されているにもかかわらず，現在のCASEツールの多くは，ソースプログ ラムのみを対象としている． ソフトウェアの開発工程において，プログラマはソースプログラムの作成に労力 をとられるため，ソースプログラムの変更に伴うソフトウェア関連文書の更新が遅れ たり，ソースプログラムとソフトウェア関連文書の間に不整合がおこりがちである． これらの問題を解決するためには，ソフトウェア関連文書を管理の対象として， ソースプログラムとの統合管理を行う必要がある． 本稿では，ソースプログラムとソフトウェア関連文書の整合性検査ツールの作成 に必要である両者の統合管理について述べ，それをもとに整合性検査ツールを作成 し，評価を行う．2 ソースプログラムとソフトウェア関連文書の統合管理
2.1 ソースプログラムの管理 従来から，ソフトウェアの品質向上及び開発期間短縮をめざして，CASEツール が用いられてきた．ソフトウェアの開発工程には要求分析から保守運用に至るまで さまざまなフェーズがある．そのなかでも特に，設計フェーズ以降の下流工程のプ ロダクトであるソースプログラムの保守・管理や，再利用を目的としたさまざまな CASEツールが提案，実用化されている．∗Kouichi Toita,名古屋大学大学院工学研究科, toita@agusa.nuie.nagoya-u.ac.jp †Shinichiro Yamamoto,愛知県立大学情報科学部, yamamoto@ist.aichi-pu.ac.jp ‡Kiyoshi Agusa,名古屋大学大学院工学研究科, agusa@nuie.nagoya-u.ac.jp
我々の研究室では，細粒度リポジトリに基づいたCASEツールプラットフォーム として，Sapid[1]が開発されている．Sapidは，対象言語をC言語として，ソース プログラムを構文要素に分解し，リポジトリに格納することができる．しかしSapid では，ソースプログラムのみを対象としたCASEツールプラットフォームであるた め，ドキュメントを直接扱うことはできない． 2.2 ソフトウェア関連文書の管理 ソフトウェア関連文書は，ソースプログラムの理解を深めるために記述するもの である．そのためには，次のような要素が必要である． ソフトウェア関連文書の参照を助ける要素 ソフトウェア関連文書中のある事柄についての説明を調べるときに，その度にソ フトウェア関連文書を探していては非常に手間がかかる．そこで，事柄の使用部分 と説明部分にリンクを表す要素を追加することで，ソフトウェア関連文書の参照の 手間を省くことができる．例として，ハイパーテキストにおけるリンク関係が挙げ られる． ソースプログラムの断片を表す要素 ソフトウェアの構成を説明する時など，ソースプログラムの断片を用いて説明す ると，ソースプログラムの理解を助ける．しかし，ソースプログラムの断片を記述 するだけではなく，ソースプログラムの断片が記述してあることを示す要素を追加 することで，計算機を用いてソフトウェア関連文書を解析するときに役立つ． ソースプログラムとの関連を表す要素 ソフトウェア関連文書は，ソースプログラムと密接に関係している．よって，文 書の一部とソースプログラムの構文要素との関連を表す要素を追加することで，文 書からソースプログラムを参照することが可能になるので，ソースプログラムの理 解に役立つ． 我々の研究室では，ソフトウェアドキュメント統合モデルに基づいたCASEツー ルプラットフォームDapid[2]が開発されている．Dapidは，XML文書を対象とし， 文書中のプログラム断片について細粒度の解析が可能であり，ソースプログラム中 の各構文要素と，文書の構文要素との関連づけが可能である．また，文書中の各要 素に対して，要素の取得が可能である．Dapidでは，文書の解析を行うために，識 別子定義を表す要素，識別子参照を表す要素，プログラム断片を表す要素にタグ付 けを必要とする． 2.3 ソースプログラムとソフトウェア関連文書の統合管理 2.2節で述べたように，Dapidでは，文書中のプログラム断片について細粒度の 解析が可能であり，ソースプログラム中の各構文要素と，文書の構文要素との関連 づけが可能である．その文書に対するソースプログラムについてSapidを用いて解 析を行えば，ソースプログラムとソフトウェア関連文書の統合管理は可能である．
3 ソースプログラムとソフトウェア関連文書の整合性検査ツール
ソフトウェアの開発時には文書中に記述された事柄とソースプログラムとの整合 性がとれなくなる場合がある．これを解決するために，文書中に宣言された関数， typedef宣言，構造体，共用体，列挙子定義などが，実際にソースプログラム中に 存在しているか，関数の定義において引数の数がソースプログラムと一致している か，構造体の定義においてmemberの数がソースプログラムと一致しているかなど を検査するツールが必要である． そのためには，ソースプログラムとソフトウェア関連文書が統合管理されている 必要がある．既存のシステムでは，ソースプログラムとの統合管理をすることが困 難であったが，SapidとDapidを用いることでソースプログラムとソフトウェア関 連文書を統合管理することが可能となる． Dapidでは，文書中の識別子定義要素の取得が可能であり，また，識別子定義要 素中のプログラム断片に対して，細粒度の情報の取得が可能である．また，Sapid を用いることでソースプログラムに対する細粒度の情報も取得可能であるので，細 粒度の整合性の検査を行うことができる． 3.1 対象とするソフトウェア関連文書 本稿では，ソフトウェアの開発工程において作成されるソフトウェア関連文書の 中で，ソースプログラムとの整合性に関わる文書を扱う． 具体的には， • ソースプログラムおよびライブラリの仕様書 • ソースプログラムおよびライブラリのマニュアル • ソースプログラムの外部に記述された説明文書（メモ） を対象とする． これらの文書を扱う理由は，ソフトウェア開発の中流工程以降でこれらの文書が ソースプログラムの理解において重要な役割を果たすからである． また，Dapidを用いて解析を行うため，対象とする文書はXMLで書かれている ことを前提とする． 3.2 ソフトウェア関連文書の記述 Dapid[2]の文献では，外部リンケージを持つ識別子のみを対象としていた．それ は，局所変数など同じ名前の識別子が複数出現するような場合，文書中に記述して ある識別子を，ソースプログラム中のどの識別子と関連付けを行えばよいかという 判断が困難であるからである．しかし，同じソフトウェアの中で，同じ名前の識別 子を持つ型の定義やマクロが存在することは少ない．また，整合性検査ツールのよ うなプログラムでは，型の定義など外部リンケージを持たない識別子も扱うことで， 広い範囲で整合性の検査を可能にする． そこで，外部リンケージを持つ識別子である関数しか扱えなかったものを，型や マクロなどの定義も扱えるようにするために，識別子の種類を指定できるようにす る必要がある． 図1は，上の条件を含んだDapidで解析するためのソフトウェア関連文書をXMLで記述するためのDTDである．
<!ELEMENT document (#PCDATA|define|docident)*> <!ELEMENT define (srccode,(#PCDATA|docident)*)> <!ATTLIST define
name CDATA #REQUIRED sort CDATA #REQUIRED> <!ELEMENT docident (#PCDATA)> <!ELEMENT srccode (#PCDATA)>
図1 ソフトウェア関連文書のDTD 図1のdefineが識別子定義要素を表すタグ名であり，nameが識別子の名前を， sortが識別子の種類を表す属性である．また，docidentが識別子参照要素を表す タグ名で，srccodeがプログラム断片要素を表すタグ名である． 図2は，図1に基づいて記述されたソフトウェア関連文書の一例である． <?xml version="1.0"?> <document>
<define name="spdGetClassIdByName" sort="function"> <srccode>
SpdClassId spdGetClassIdByName(SpdString className); </srccode> <docident>className</docident>を与えると， 対応する<docident>classId</docident>を返す． 該当する<docident>classId</docident>が存在しない場合は <docident>SAPID_NON_ID</docident>を返す． </define>
<define name="SpdObjId" sort="typedef"> <srccode>
typedef SpdId SpdObjId; </srccode> オブジェクトの識別番号を表す． </define> </document> 図2 入力XML文書例 3.3 プログラム断片の解析手法 本稿で扱うプログラム断片は，関数のプロトタイプ宣言，型の定義などのプログ
ラム断片とする． プログラム断片の解析手法は，プログラム断片を切り出して，プログラム断片ご とにファイルに保存し，その後Sapidの解析に基づいてそのファイルの解析を行う． ここで，扱うプログラム断片は#includeやマクロなどの前処理命令を使用しない ものとするので，Sapidによる解析と異なり前処理を行わない．解析してできたリ ポジトリは，Sapidの前処理後のモデルであるI-modelの中に格納される．最後に， このリポジトリと，ソフトウェア関連文書をDapidで解析してできたリポジトリと を関連で結ぶ．こうすることで，プログラム断片のリポジトリをソフトウェア関連 文書のリポジトリからたどることが可能になる． 3.4 整合性の検査 図1のDTDに基づいて記述されたソフトウェア関連文書と，ソースプログラム の整合性について考える． この検査は，以下のような場合において行うことを想定する． • ソースプログラムの変更作業終了後に，古いバージョンのソフトウェア関連文 書と整合性を検査する • ソフトウェア関連文書の変更作業終了後に，古いバージョンのソースプログラ ムと整合性を検査する • ソースプログラムとソフトウェア関連文書の変更作業終了後に，両者の整合性 を検査する 整合性の検査の対象として，ソフトウェア関連文書中で定義されることが多い， 関数，定義された型，構造体，共用体，マクロ，ファイルを扱う． 次にそれぞれに対して，どのような検査を行うかについて述べる． 3.4.1 関数に対する整合性検査 関数に対する検査は，まず，ソースプログラム中で宣言されている関数がソフト ウェア関連文書中に存在するか，ソフトウェア関連文書中で宣言されている関数が ソースプログラム中に存在するかを調べる．次に，関数宣言の部分で，その関数の 名前，型，引数の数，名前，型についてソースプログラムとソフトウェア関連文書 で整合しているかを調べる．さらに細かく検査を行う場合は，関数の内部で，使用 される変数や呼び出す関数，呼び出される関数についても調べる．ライブラリに関 するソフトウェア関連文書では，関数の使用方法や，どのような動作をするという 説明がほとんどであり，関数内部のことの説明は，プログラムのシステム設計仕様 書のようなソフトウェア関連文書で扱われることが多い．よって，対象とするソフ トウェア関連文書に合わせて，関数内部の検査を行うようにする． 3.4.2 定義された型，構造体，共用体に対する検査 型，構造体，共用体に対する検査は，まず，ソースプログラム中で宣言されてい る型，構造体，共用体がソフトウェア関連文書中に存在するか，ソフトウェア関連 文書中で宣言されている型，構造体，共用体がソースプログラム中に存在するかを 調べる．定義された型は，その型の名前とtypedefで定義される前の型について調 べる．構造体，共用体はその型の名前，member の数，型，名前について調べる．
3.4.3 マクロに対する検査 マクロは，プログラムやライブラリの内部でしか使用しないものが多い．よって， ライブラリに関するソフトウェア関連文書には，外部で使用するためのマクロにつ いてのみが書かれているのが一般的である．そのために，ソフトウェア関連文書中 で宣言されているマクロがソースプログラム中に存在するかだけを調べる．次にマ クロの名前，引数を持つものであれば，引数の数，名前，マクロで定義されている 式または値について整合性を調べる． 3.4.4 ファイルに対する検査 ファイルに対する検査は，ソースプログラム中に存在するファイルがソフトウェ ア関連文書中で<define>タグによって定義されているか，ソフトウェア関連文書中 で<define>タグによって定義されているファイルがソースプログラムで使用され ているかを調べる．しかし，ライブラリに関する文書では，インクルードして使う ヘッダファイルの定義がほとんどであると考えられる．よって，このような場合で は，ヘッダファイルについてだけソフトウェア関連文書中で<define>タグによって 定義されているかを調べるべきであると考えられる． ファイルは，そのファイルに存在する関数，定義された型，マクロなどについて 整合性を調べる．ソフトウェア関連文書中のファイルの定義では，プログラム断片 としてソースプログラムを全て書くことはないので，定義された識別子による検査 が必要となってくる．
4 整合性検査ツールの実装
3.4節で挙げた検査項目をもとに，ソースプログラムとソフトウェア関連文書と の整合性を検査するプログラムspdChkDocを作成した．このツールは，Sapid に リリースされており，Sapidのホームページ[3]において配布中である． 4.1 実現した検査項目 3.4節で挙げてきた検査項目のうち，実現したものを以下に示す． 4.1.1 関数 以下の６つの項目についての検査を実現した． • ソースプログラム中の関数がソフトウェア関連文書中に存在するか • ソフトウェア関連文書中で定義された関数がソースプログラム中に存在するか • 関数の戻り値の型が一致しているか • 関数の引数の数が一致しているか • 関数の各引数の型が一致しているか • 関数の各引数の名前が一致しているか 4.1.2 型，構造体 以下の６つの項目についての検査を実現した． • ソースプログラム中の型，構造体がソフトウェア関連文書中に存在するか • ソフトウェア関連文書中で定義された型，構造体がソースプログラム中に存在 するか • 型のtypedef で定義される前の型が正しいか • 構造体のmember の数が一致しているか• 構造体の各memberの型が一致しているか • 構造体の各memberの名前が一致しているか 4.1.3 マクロ 3.3節で示したように，プログラム断片要素には，#includeやマクロなどの前処 理命令を使用しないものを扱うことにしたので，マクロのプログラム断片を扱うこ とはできない．そこで，以下の検査だけを実現した． • ソフトウェア関連文書中で定義されているマクロがソースプログラム中に存在 するか 4.1.4 ファイル 以下の２つの項目についての検査を実現した． • ソースプログラム中に存在するファイルがソフトウェア関連文書中で定義され ているか • ソフトウェア関連文書中で定義されているファイルがソースプログラム中に存 在するか 4.2 出力結果例 このツールは，検査後に結果をHTMLファイルに出力する．図3は関数の整合 性の結果例である． 図3 関数の整合性結果
このHTMLファイルは，４つのフレームで構成されている．左上のフレームに ソースプログラム中のファイル，関数，型，構造体の数と，ソフトウェア関連文書 中のマクロの数を表示する．左下のフレームにファイル，関数，型，構造体，マク ロの整合性の結果を表示する．右上のフレームにどの結果の詳細を見ているかを表 示する．右下のフレームに結果の詳細を表示する． 右下のフレームに表示される表は，表1のような構成になっている． 表1 結果の詳細テーブルの構成 関数や型などのID 関数や型などの名前 整合性検査の結果 関数や型などについての記述 整合性検査の結果，ソースプログラムとソフトウェア関連文書との間で記述が違っ ていた場合， Invalid FuncType. "SpdString"<-->"char *" というように表示される．まず，どこが違っているかを表示して，次の行に違って いる部分のソースプログラムとソフトウェア関連文書の記述を表示する．この場合， "SpdString"がソースプログラムの記述であり，"char *"がソフトウェア関連文書 の記述である． ソースプログラムとソフトウェア関連文書で定義の記述に整合が取れていない場 合は，色分けして表示し，整合が取れていないもののうち同じ種類のものを集めて 表示する．よって，ひと目で間違っているものを知ることができ，いくつ間違って いるかすぐに知ることができる．また，ソフトウェア関連文書による記述が存在す る場合は，該当部分を切り出して表示するので，このツールの結果を見るだけでソ フトウェア関連文書に記述されている内容を検査できる． さらに関数，型，構造体，マクロ，ファイル名をクリックすることでそのプログ ラムのソースを見ることができる．またプログラムのソースからその関数などの名 前をクリックすることで，整合の結果画面へジャンプするのでソースプログラム中 の何がどのように間違っているのかがわかる．
5 評価
実際にこのツールを用いて，Sapidのライブラリの１つであるlibSapidUtilを対 象に整合性検査を行った．libSapidUtil に関するソフトウェア関連文書には，ファ イルの説明はなかったのでファイルに関する整合性検査は行わなかった．このライ ブラリは，C言語で書かれていて，約7000行である．また， XML で書かれたラ イブラリの仕様書は，TEXファイルを XMLファイルに変換するツールを用いて変 換したものを使用した．このツールは，Sapid 用の決められたTEXのタグをXML のタグに変換するものである．このライブラリの仕様書のTEXファイルは約1800 行であり，変換したXMLファイルは約1000行である． 5.1 関数に対する整合性検査の結果 関数の整合性検査の結果を表2に示す．表2 関数に対する整合性検査の結果 libSapidUtil 3.854 外部関数の数 154 整合のとれている関数の数 39 整合のとれていない関数の数 11 文書中で定義されていない関数の数 104 ソースプログラムに存在しない関数の数 9 戻り値の型が違う関数の数 2 引数の数が違う関数の数 5 型が違う引数の数 6 名前が違う引数の数 1 表2を見ると，整合の取れていない関数が11個あることが分かる．戻り値の型が 違う，引数の数が違うなどどこが違うかが分かるため，ソフトウェア関連文書ある いはソースプログラムの修正に有用である． また，ソフトウェア関連文書中で定義されていない関数が104個あることが分か る．このツールでは，関数名をクリックすることでソースプログラムを参照するこ とが可能である．よって，ソフトウェア関連文書中で定義されていない関数につい て，ソースプログラムを見ながらソフトウェア関連文書中に新しく定義できる． さらにソースプログラムに存在しない関数が9個あることが分かる．ソースプロ グラムに存在しない関数は，ソフトウェア関連文書中に存在しても意味をなさない ので，ソフトウェア関連文書中から削除する必要がある．このツールでは，ソース プログラムに存在しない関数についても関数名が表示されるので，その関数名を見 て定義されている箇所を削除できる． 5.2 型と構造体に対する整合性検査の結果 型と構造体の整合性検査の結果を表3に示す． 表3 型と構造体に対する整合性検査の結果 libSapidUtil 3.854 型と構造体の数 89 整合のとれている型と構造体の数 3 整合のとれていない型と構造体の数 1 文書中で定義されていない型と構造体の数 85 ソースプログラムに存在しない型と構造体の数 0 定義される前の型が違う型の数 0 memberの数が間違っている構造体の数 1 型が間違っている member の数 0 名前が違う member の数 0 表3を見ると，整合の取れていない型と構造体が1個あることが分かり，member の数が違うことが分かる．今回のケースでは，memberの数が異なるものしかなかっ たが，memberの数以外にも複数間違いがあった場合も具体的にどのように間違っ ているかが分かるため，ソフトウェア関連文書あるいはソースプログラムの修正に 有用である． しかし，SapidUtilのみの型，構造体に整合性検査を行うことが目的であったが，
Sapidのライブラリ全てに整合性検査を行い，ソフトウェア関連文書が存在しない 型，構造体が多く出る結果となった．この点については今後の課題である． 5.3 マクロに対する整合性検査の結果 マクロの整合性検査の結果を表4に示す． 表4 マクロに対する整合性検査の結果 libSapidUtil 3.854 マクロの数 2 ソースプログラム中に存在するマクロの数 2 ソースプログラム中に存在しないマクロの数 0 表4を見ると，ソフトウェア関連文書中に存在するマクロが2個あることがわか り，2個ともソースプログラム中に存在することがわかる．今回のケースでは，ソー スプログラム中に存在しないマクロはなかったが，ソースプログラム中に存在しな いマクロについても抽出できる．そういったマクロについての定義はソフトウェア 関連文書中に存在していても意味をなさないので，ソフトウェア関連文書中から削 除する必要がある．このツールでは，ソースプログラムに存在しないマクロについ てもマクロ名が表示されるので，そのマクロ名を見て定義されている箇所を削除で きる． しかし，マクロに対する検査は存在の有無だけなので，まだ貧弱である．マクロ についても，引数の数や，引数の名前などの検査が行えるよう拡張が必要である． 5.4 関連研究との比較 従来の文書管理の枠組みとして，LinuxDoc-SGML[4]や，W3Cによって提案さ れたDOM (Document Object Model) [5]によるXMLドキュメントの管理手法な どがあげられる． LinuxDoc-SGML では，マニュアルなどのソフトウェア関連文書をある決まった DTDを用いた SGML 文書として記述する．このSGML 文書は groff 形式， tex 形式，HTML形式などに自動的に変換することが可能である．しかし，SGML文 書に対して，各構成要素を取得したり，変更したりといった任意の操作に対するサ ポートは考慮されていない．また，文書中にソースプログラムを記述することは可 能であるが，特に検査されないため，文法的に間違ったプログラムなどが記述され ることもある．さらに，LinuxDoc-SGMLはソフトウェア関連文書のみを扱うシス テムであるので，ソフトウェア関連文書の一部とソースプログラムとの関係を表現 することはできない． DOMでは，XMLかHTMLで記述された文書を対象とし，要素単位で文書の断 片の取得や，変更が可能である．しかし，DOM はXML/HTML 文書要素の木構 造をモデル化したものであり，このモデル自身には，リンク関係を表す仕組みがな い．さらにソースプログラムとのリンク関係を表すこともできない．また，DOM では元々 Web ドキュメントの管理手法として発展してきた経緯から，複数のファ イルからなる文書を扱うことはできない． 2.2節で述べたように，Dapid では，文書中のプログラム断片について細粒度の
解析が可能であり，ソースプログラム中の各構文要素と，文書の構文要素との関連 づけが可能である．また，文書中の各要素に対して，要素の取得が可能である． 本稿で挙げる検査ツールは，文書中のプログラム断片について解析を行い，その 情報をもとに，ソースプログラムとの比較を行うことを必要とする．そのため，本稿 ではDapid を用いて文書を解析し，ソースプログラムとの比較を行った．また，整 合性の検査を行うに当たって，Dapidで扱うことのできない部分を新しく作成した．
6
おわりに
6.1 まとめ 本稿では，ソフトウェア関連文書の統合管理を行うために，ソースプログラムと ソフトウェア関連文書の個別管理について考察し，これらの管理にSapidとDapid を用いることで，統合管理が可能であることを述べた． 統合管理を行うことで実現できることとして，ソースプログラムとソフトウェア 関連文書の整合性の検査について考察し，整合性検査ツールを実装した．このツー ルをSapidのライブラリの１つであるlibSapidUtilを対象に整合性検査を行い，整 合の取れていない関数が11個あることや，ソフトウェア関連文書中で定義されてい ない関数が104個あることが分かり，ソースプログラムあるいはソフトウェア関連 文書の修正を行うのに有用であることを示した． 6.2 今後の課題 今回実装したspdChkDocは，整合性検査において以下のような拡張の余地がある． 6.2.1 型と構造体の整合性検査 5.2節で示したように，ライブラリの型と構造体の整合性検査において，全ての ライブラリに検査をかける結果になった．これは，stdio.hといったシステムファ イル以外のファイル全てに対して検査を行ったためである． この問題を解決するために，対象とするヘッダファイルを正確に選択し，そのヘッ ダファイルに対してのみの解析を行うというルーチンが必要である． 6.2.2 マクロの整合性検査 マクロの検査については，本稿で扱うプログラム断片を，#includeやマクロな どの前処理命令を使用しないものと制限したために，中身の検査を行うことができ なかった．このためには，マクロの解析を可能にする必要がある． 現在Dapidでは，プログラム断片を解析したクラスは前処理後のモデルである I-modelとしか関連を持っていない．マクロは，前処理後は値または式に置き換え られてしまうので，マクロのプログラム断片をI-modelと関連を持つことは難しい． そこで，前処理前のモデルであるP-modelのクラスと関連を持つことができれば， マクロのプログラム断片を解析し，P-modelに入れることでマクロの解析も可能に なる．また，マクロの解析が可能になれば，マクロの中身についての検査も実現で きる． 6.2.3 その他のプログラム断片の整合性検査 今回は，関数，定義された型，構造体，マクロ，ファイルを整合性検査の対象と して扱った．しかし，これら以外にもソフトウェア関連文書には，共用体や，列挙 子など様々なプログラム断片が記述されると考えられる．こういったものにも対応できるように拡張することでより有用になる．
謝辞
日頃から議論，指導してくださる阿草研究室のみなさんに感謝します． 参考文献
[ 1 ] 福安 直樹,山本 晋一郎,阿草 清滋: ”細粒度ソフトウェア・リポジトリに基づいたCASEツー ル・プラットフォームSapid”,情報処理学会論文誌, Vol.39, No.6, pp.1990–1998, 1998
[ 2 ] 古山 将佳寿,山本 晋一郎,阿草 清滋: ”ドキュメントを含むソフトウェアモデルの提案”,日本 ソフトウェア科学会FOSE’99, pp.100-107
[ 3 ] ”Sapid Home Page”, http://www.sapid.org
[ 4 ] Linux JF Project, ”日本語Linuxdoc-SGMLガイド”,
http://www.linux.or.jp/JF/workshop/sgml-jguide/jguide.html
[ 5 ] W3C，”Document Object Model(DOM) Level 1 Specification”,
http://w3c. org/TR/REC-DOM-Level-1/
[ 6 ] P.Francois, P.Futtersack, C.Espert,”SGML/HyTime Repositories and Object Paradigms”, Electronic Publishing—Origination Dissemination, and Design”,,Vol. 8, Number 2/3, pp. 63-79, June /sep 1995.
[ 7 ] E.Koppen, G Neumann, “A practical approach towards active hyperlinked documents”, Computer Networks and ISDN Systems Vol. 30 pp.251-258, 1998.
