シス開発：注目すべき重要技術 |
どんな開発方法論でも、設計内容を記述する表記法が重要である。オブジェクト指向技術を利用した方法論の場合は、クラスの関連や動的な処理の流れを表現するために、図による表記が多く使われる。以前は、方法論ごとに異なるルールで図を描いていた。図のルールが標準化されないと、良いツールが登場しづらい。図を用いた記述はソフトによる支援が不可欠だけに、非常に困った状況だった。
これを打開するために、方法論を提示していた３人（最初はGrady Booch氏とJames Rumbaugh氏、後でIvar Jacobson氏が加わる）が中心となり、標準化作業を進めた。こうして出来上がったのが、UML（Unified Model Language：統一モデリング言語）だ。何種類もの図を組み合わせて、システムの設計内容を記述する。
標準的に使われるためには、開発方法論に依存しない点も重要だ。たいていの方法論に対応できるようにと考慮して、記述ルールを設計してある。UMLは設計内容を記述する言語なので、方法論の中でも違いが大きい設計プロセスを含まなくてよい点も幸いした。もし設計プロセスの途中で特別な記述を必要とする場合は、UMLに独自の書式を加えれば済む。またUMLでは、最初から拡張を考慮した仕様を含んでいる。以上のような点を検討して設計したことに加え、方法論を提示していた人物が設計したので、デファクト・スタンダードになってしまった。１つの標準にまとまることは非常に重要である。優れた作成ツールが登場しやすいし、技術者が設計内容を評価し合うのが容易になる。また、これから勉強する人も、１種類のモデリング言語を習得すればよい。
UMLの記述できる対象はかなり広い。実現すべき機能の概要を示すユースケース図、クラスやオブジェクトの関連など表すクラス図とオブジェクト図、オブジェクト間のメッセージ交換の流れを記述するシーケンス図とコラボレーション図、オブジェクトの状態と変化のトリガーを整理する状態図、処理の実行内容を流れ中心で説明するアクティビティ図がある。また、コンポーネントの種類と関連を描いたコンポーネント図、ハードとソフトの接続状態や関連を示す配置図も含まれる。以上のような何種類もの図が規定されているため、かなり多くの内容を記述できる。
図を用いた設計内容の記述方法は、HIPOやDFDなど、これまでに何種類も登場している。それらの多くは、システムの内部仕様、つまり実装レベルの内容を対象としていた。UMLでは少し範囲を広げ、システムの外部仕様も一部サポートしている。ユースケース図などは、使おうと思えばニーズ分析の段階から使える。このように守備範囲を広げた点は、高く評価して良い。
UMLで規定しているのは、図を中心とした表記方法である。図による表記は、言葉だけの説明よりも全体像を把握しやすい利点がある。そのため、UMLを用いると分かりやすい仕様書が書ける。ただし、図を描いただけでは、読んで理解できる仕様書にはならない。どうしても言葉による説明が必要だし、適切な図と上手な説明文の両方が揃って、理解しやすい仕様書が出来上がる。一般的には、きちんと記述するなら文章量はかなり多くなるはずだ。
たとえば、システムで実現する機能の外部仕様を、ユースケース図を用いて記述したとしよう。アクターとシステム機能を図で描いただけでは、どのような機能なのか不明な点が多い。システムが提供する機能を大まかに説明するとともに、アクターの条件も書かなければならない。また、そのユースケース図で描かれた機能が、システム上でどんな位置付けなのかや、どのような条件で発生するのかなども、記述する必要がある。
UMLの他の図も同様で、言葉による説明がかなり多くなる。さらに、どんな図を作成したのか把握するための一覧表、図と図の関連を示す書類など、書類全体を管理するための書類も作らなければならない。
加えて、システム開発全体では、UMLがサポートしていない書類も数多く作成する。もし全面的にUMLを採用したとしても、対象外の書類に関しては別な記述方法を用いる必要がある。代表的なものを、ざっと挙げてみよう。ニーズ分析の内容、データベース設計、テスト仕様、運用仕様、プロジェクト管理などだ。他にも、仕様書の一覧表など、仕様書全体を管理するための書類も作成する。これら全部の書式が決まっていなければ、システム開発を円滑には進められない。どのような書類を作成し、それぞれにどんな表記方法を用いるのか、開発を始める前に決めておくべきだ。UMLを採用するときが、作成すべき書類を整理する良い機会となるだろう。
UMLのような図による表記方法は、手で描いていたら手間がかかりすぎて実用にならない。専用のソフトによる支援が不可欠だ。幸いなことに、良いツールが登場しつつある。しかし、きちんとしたシステム開発で必要とされる機能を評価基準にした場合、まだまだ満足できるレベルには達していないようだ。ツールに求められる機能のうち、あまり考慮されていない点を中心に、ここで整理してみよう。
まず、前述の文章や表による記述を自由に組み合わせられなければならない。個々の図に関連する形で、文字中心の補足説明を加える。最低限として、マルチスタイル（１文字ごとに書体やスタイルが設定可能）のテキストと、簡単な作表機能があればよい。作成した補足説明は、データベースに入れて管理し、簡単に検索や参照できることが望ましい。
きちんとした開発では、レビューを実施して設計の質を確保する。仕様書を書くソフトでは、レビューも支援しなければならない。レビューのためには、個々の機能にIDを付けて管理する。前工程で設計した機能が、次の行程で全部は含まれているかどうかなど、IDを使いながら検査する。UMLで描くツールでも、入力したユースケースやクラスは、ユーザーが規定した書式でIDを付けられる必要がある。そのうえで、IDによる関連を入力できたり、ID順の一覧表や関連表を出す機能も付ける。
プロジェクト管理を支援する意味で、入力した設計内容の進捗状況の設定も必須だ。作成したクラス図などが、設計中なのか、一応の設計が終わってレビュー前なのか、レビューが終わって修正前なのか、レビューも修正も終わったのかなど、個々の設計物の状況を入力できなければならない。もちろん、設計やレビューを誰が担当して、いつまでの終わらせる予定なのかも一緒に入れるのは当然だ。このような機能があれば、プロジェクトの状況を容易に把握できる。
どんなシステムでも変更しながら使い続けるので、メンテナンスへも対応したい。変更の履歴を持て、変更前と変更後の両方を保持できればベストだ。それが難しいなら、前の状態の全体ファイルを残し、変更後のファイルと比較して変更点を示す機能がほしい。
このようなツールを使う開発では、チームでの作業が当たり前なので、グループウェア的な機能も求められる。他に、関連する別な図との整合性の検査機能も、ユーザーが定義して追加できる形が望ましい。また、ソースコード管理機能との連携、テスト機能との連携など、他のツールと一緒に使える機能がほしい。こうして考えていくと、UMLだけをサポートするツールでは不十分で、全体として統合された開発支援ツールにならなければならない。そこまで到達するのは難しいだろうが、目指すゴールはハッキリしている。
UMLは、今でも改良が進められている。１つ重要なのは、モデルの記述内容を保存するための標準フォーマットの規定だ。これが実用になれば、異なるツールで作成した設計内容を交換できて、特定のツールに依存しなくて済む。
標準フォーマットの内容を知らないが、実用的なレベルに仕上げるのは相当に難しいと思う。システム開発に役立つ機能を加えるほど、UMLがサポートしない情報が多い。それらは、UMLがサポートする内容と関連していて、関連を保ったまま移行できなければならない。その意味で、いろいろな付加情報を含められるフォーマットに設計するのは必須といえる。
その他の機能でも、UMLは拡張し続けるだろう。せっかくユースケースにまで範囲を広げたので、もっと広い範囲をサポートしてもらいたい。ニーズ分析やテスト仕様などだ。加えて、プロジェクト管理に役立つステータス情報、クラスなどのID管理機能など、ツールに付けるべき推奨機能も提案したらどうだろうか。これらをデータ交換の標準フォーマットに加えれば、サポートするソフトが増えて、レベルの高いデータ交換フォーマットが規定できるはずだ。
いろいろと述べたが、オブジェクト指向技術を用いた開発では、仕様書の表記方法としてUMLが重要な役割を果たす。その点だけは間違いない。繰り返すが、良い仕様書に仕上げるためには、UMLがサポートしていない部分も重要となる。それだけに、UML仕様もツールもどんどんと良くなってほしい。
（1999年４月24日）
UML：オブジェクト指向設計では標準の表記方法に |
