TOPシステム開発【楽々デブドックを書こう!】XMLで開発ドキュメント> 第3回:情報システムの仕様をXMLで記述する! (1/3)




XMLで開発ドキュメント

【楽々デブドックを書こう!】XMLで開発ドキュメント

第3回:情報システムの仕様をXMLで記述する!

著者:佐賀大学総合情報基盤センター 只木 進一

公開日:2008/02/20(水)

情報システムの仕様書で必要な考え方

読者の皆さんの文書作成環境は、Wordの方が多いのではないだろうか。その場合、WYSIWYG(What You See is What You Get)環境が当たり前であり、XMLはなんとも歯がゆいものである。XMLで書く文書は見た目とは異なり、文書の構造を書いたものである。構造、表示、内容が分かれており、面倒なだけに違いない。確かにWYSIWYGでことが済めばそれにこしたことはない。しかし、そういう環境において文書の整合性を維持するのは結構大変である。

では、UNIX系OSのテキストを基本とした環境に慣れている人にとってはどうだろうか。WYSIWYGは便利だと思うが、それほど魅力的でもない。短くコンパクトで完結したものを連結して使うのがUNIXの文化であり、文書もそのようなものであるべきと考える。つまり、文書もプログラムのようにモジュール化されているべきである。小さなモジュールの完結性が全体の整合性を担保してくれるからだ。この方が思考経済(思惟経済)としてずっと合理的に思える。思考経済とは「できるだけ少ない情報量で事実を表現することで、思考のコストを節約すること」である。

情報システムの仕様書はUNIX的文化に馴染むと筆者は思う。仕様書は各サブシステムごとにモジュールとして完結であるべきである。他と関係がある場合でも、整合的でなければならない。仕様書はそれを担保するための約束ごとであるため、「忍耐」ではなく、プログラムのような明確な制約を作って整合性を担保するべきである。

Image

仕様書作成の前に、文書構造を把握する

仕様書を作成するにあたって、筆者を含めた技術系の人間の陥る罠が「ウォーターフォール」である。ウォーターフォールでは、文書の規約を定め、それに従って内容を書き、そして表示方法を整備する。このように上流から下流に作業が一方向に流れると嬉しく、わかりやすい。

しかし、それは無理である。システム要件を記述するのが目的であって、仕様書はその手段に過ぎないからだ。つまりシステム要件を記述するために、文書の規約は変更されるべきである。また、共同作業者の意見を聞いて文書規約も変更しなければならない。柔軟に対応する必要があるのだ。

まず、文書の全体構成を把握しよう。書きやすい部分を例として文書構造の大枠がわかるように、馴染みの道具で作成する。これはWordでも、LaTeXやHTMLのような形式でも良い。前回述べたように、階層構造がどうなっているかを把握することがこの作業の主眼である。

各階層には、どのような内容が必要だろうか。前回述べたように、仕様書は基本的に箇条書きである。最下層の項目以外の階層では、表題が1つとその下層の項目が複数個で構成されている。

サーバ類の記述でいくと、サブシステムが「Section」に、各サーバが「SubSection」に、そのソフトウェアやハードウェアが「TopItem」に、そしてソフトウェアやハードウェアの詳細が「li」に対応する。このような構造を意識して文書をXMLのようなタグを使って作っていく。次に文書構造を定義していこう。 次のページ




佐賀大学総合情報基盤センター  只木 進一
著者プロフィール
佐賀大学総合情報基盤センター 只木 進一
センター長・教授
交通流やインターネットパケットの流れなど、自己駆動粒子系の研究を専門としている。並行して、情報システムの管理運用技術の研究開発も行っている。XMLやJavaなどを仕事道具として活用している。
http://www.cc.saga-u.ac.jp/


この記事の評価をお聞かせください
ボタンをクリックしますとウインドウが開きます。

INDEX
第3回:情報システムの仕様をXMLで記述する!
情報システムの仕様書で必要な考え方
  文書構造の定義
  作業環境
【楽々デブドックを書こう!】XMLで開発ドキュメント
第1回 標準化と再利用
第2回 情報システムにXMLが求められる背景
第3回 情報システムの仕様をXMLで記述する!
第4回 XMLの出力環境