設計の履歴書が延ばすソフトウェアの寿命
ATR通信システム研究所 通信ソフトウェア研究室 浜田 雅樹
1．はじめに
交換機、銀行のオンラインシステムなど、高度な通信サービスの実現にソフトウェアは不可欠です。ハードウェアが各サービス間で共通する機能を提供するのに対し、ソフトウェアは、個々のサービス毎に対応して作られます。サービスに対する要求は多様化していきますので、ソフトウェアはよく修正される運命を持っています。ソフトウェアはその名の通り柔らかいものですから、修正しやすいと思われがちです。しかし、ソフトウェアの全開発費の約70％が保守費用であるという調査報告が示すように、現状ではとても修正しやすいとは言えません。従って、高度情報社会の実現には、通信ソフトウェアの生産性とともに、保守性の向上、即ちソフトウェアの寿命を延ばす技術が不可欠になります。ATR通信システム研究所では、これらのテーマに取り組んでいます。本稿では、後者の研究について紹介します。
ソフトウェアの修正が困難なのは、ソフトウェアをなぜそのように設計したのかという、設計の理由が残されないためです。本研究では、設計の履歴書を残すことにより、設計の理由に関する情報をソフトウェアの修正時に効率的に参照することを可能にし、ソフトウェアを修正しやすくすることを目指しています。
2．ソフトウェアのドキュメント
ソフトウェアの開発では、ソフトウェアのソースコードと種々のドキュメントが作成されます。ソフトウェアを修正する作業で最も困難なのが、ソースコードとドキュメントにおける変更箇所を限定する解析です。この解析を以下、影響波及解析と呼びます。
ソフトウェアの影響波及解析を難しくしている原因の1つとして、影響波及解析に必要な情報がドキュメントに記述されていないことが挙げられます。現在、ソフトウェアのドキュメントを大きく分けると、(1)各開発工程の設計生産物(2)運用マニュアル等の2種類が挙げられます。一般にソフトウェアは、複数の工程に分けて開発されています（図1）。(1)は、この各工程の設計結果として作成されるドキュメントを指しています。(2)はソフトウェアの使い方などを説明したものです。(2)の一部として、保守のためのドキュメントを作成する場合もありますが、記述される内容は(1)のものとほぼ同じです。(1)も(2)も設計の結果のみが記述されており、なぜそのように設計したのかが記述されていません。ソフトウェアの影響波及解析では(1)のドキュメントを参照します。ソフトウェアの設計では、多くの要因、例えば、要求されている機能、処理のスピード、ソフトウェアが走行するハードウェアの構成、既存ソフトウェアとの互換性etc、が絡んできます。(1)のドキュメントは、設計者がこれらを考慮しながら設計した結果を記述したものと言うことができます。ソフトウェアの修正は、要因のどれか、例えばハードウェアの構成等、が変った場合、変更後の新しい要因を満足するようにソフトウェアの内容を修正することです。従って、設計生産物に記述されている情報を基に要因変更の影響波及解析を行うには、どのような要因がどのように設計に影響を与えたかを保守者が推測する必要があります。この作業の困難さが、影響波及解析の困難さにつながっています。
では、なぜ現在、設計に影響を与えた要因を記述していないのでしょうか？ 原因の1つとして、適切な記述手段が提案されていないことが挙げられます。例えば、自然言語で記述することはできます。しかし、自然言語で記述された膨大な量のドキュメントから修正に関連する場所を検索する手段がないため、記録した情報を有効に活用できません。また、記述する設計者の精神的な負担や工数の増加があることも原因となっています。
ATR通信システム研究所では、設計に影響を与えた要因のドキュメント化（「設計の履歴書」）および影響波及解析時での効率的な参照を可能にする方法を研究しています。つまり、設計の履歴書によりソフトウェアの寿命を延ばすことができる訳です。設計に影響を与えた要因に関する情報は、設計の工程の記録、即ち設計において設計者が要因を考慮した記録、を残すことでドキュメント化します。また、設計工程の記録は、構造化（形式化）を行い、支援システムを適用することにより−、ドキュメントの文書推敲のための思考が不用となり、記録の負担、工数増加が少なくてすみます。更に、ドキュメント作成段階になって重要な要因を忘れるといった心配もなくなります。また、影響波及解析において必要な情報を、設計工程に記録されているインデックスや関係情報を用いて効率良く検索することを可能にしています。
3．設計の履歴書
（1）設計工程のモデル化
まず、ソフトウェアを設計する工程のモデルについて説明します。
設計しているソフトウェアで実現すべき機能を設計対象と呼ぶことにします。ソフトウェアの設計ではまず設計対象を設計します。一般に、設計対象は多くの機能が複雑に絡み合っているため、設計者は設計対象の特定の箇所の特定の性質に着目して設計していきます。例えば、ある機能が持つ詳細な機能項目だとか、特定の機能の処理スピードなどです。この設計対象の特定の箇所の特定の性質に着目して設計したものを設計ビューと呼びます。各設計ビュー間には依存性が存在するため、設計ビューは互いに考慮して設計する必要が有ります。設計ビューは、前述の、設計者が設計において考慮した要因に相当します。
設計対象の設計は、以下のように行われます。設計者は、まず、ソフトウェアで実現する通信サービスの概要やソフトウェア開発依頼者の要求（原要求と呼ぶ）に基づき、設計対象に要求される性質を分析します。これは、原要求を利用して設計ビューを設計することに相当します（図2（1））。次に、それらの結果を基に、設計生産物の作成で必要な設計ビューを順次設計し（図2（2））、最後に設計生産物を作成します（図2（3））。設計者は、以上の設計において自身が持っている領域知識を利用します。このように、設計工程は、設計ビュー、設計生産物および（設計ビュー、設計生産物、原要求、領域知識間の）設計における考慮の関係（以下利用関係と呼ぶ）から構成されています。
設計ビューの内容は、機能やデータなどソフトウェアの設計で用いられる概念（設計エンティティと呼ぶ）と視点より構成されます。設計エンティティのうち、設計された箇所を表すもの（インデックス情報）をキー設計エンティティ（または略してキー）と呼び、機能項目、処理スピードなど着目した性質を表すものを視点と呼びます。
（2）設計の履歴書の構造
設計の履歴書は以下の情報から構成されます。・設計ビューとそれらの間の利用関係
・設計生産物
・設計ビューと設計生産性、原要求、領域知識間の利用関係
このように、設計者が設計で考慮した要因に関する情報が、設計ビュー（要因に対応）とそれらの間の利用関係として表されます。
（3）設計の履歴書の記録方法
通信システム研究所では、設計の履歴書を記録、検索するシステムDIG（Design Information Gathering systemを試作しました。設計者は、DIGのグラフィカルなユーザインタフェースを用いて、設計を行う設計エンティティや視点を指定し、設計ビューエディタに設計ビューの内容を記述しながら設計を進めて行きます。利用関係は、設計者が設計ビューの設計中に参照していた他の設計ビューや原要求をシステムが調べて自動的に記録します（図3参照）。
4．影響波及解析
影響波及解析では、まず、設計の履歴書から（a）設計対象に要求されていた性質の中で変更されるものを検索します。これは、図2（1）の中から変更に関する設計ビューを選ぶことに相当します。次に、（b）変更された設計ビューを利用して設計されている他の設計ビュー、設計生産物を利用関係を用いて検索していきます。以下、DIGにおいて影響波及解析を行う手順を示します。
（a）変更に関連した設計ビューの検索
システムは、まず原要求を利用して設計された設計ビューの一覧を表示します。保守者は変更に関連した設計ビューをその中から選びます。この選択では、設計ビューのインデックス情報である視点とキーが役に立ちます。今、基本的な電話サービス（pots）を、端末（電話）の受話器を取りフラッシュするだけで特定の端末にかかるように変更する例を考えます（図4）。この変更は、端末操作という性質が変るので、保守者は表示されている設計ビューの一覧の中で、視点：「端末操作」を持つものにまず着目します。次に、この変更は、電話をかける側の端末T１が受話器を取っている状態で行われる端末操作が変るので、キーとして「T1がダイヤルトーンでT2がアイドル」および「T1がダイヤルトーンでT2がアイドルでない」をそれぞれ選ぶことにより、変更に関連した設計ビューを限定できます。図の4の(2)、(3)は、そのうちキーとして「T1がダイヤルトーンでT2がアイドル」、視点として「端末操作」をインデックスとして持つ設計ビューを選んでその内容を表示させた場面です。表示された設計ビューでは、原要求を利用して設計された箇所、本例では「T1からT2にダイヤルする」、がハイライト（図では下線で表示）されます。保守者はこの設計ビューを修正の対象としてマークします（図4中の(4)）。
（b）影響波及解析
システムは、先ほどマークした設計ビューを利用して設計された設計ビューのリストを表示します（図4中の(5)）。保守者は、リストにある設計ビューそれぞれをチェックし、修正が必要ならマークして行きます。同様に続けて行くと、影響を受ける設計生産物までたどり着くことができます。
5．おわりに
通信システム研究所で行っている、通信ソフトウェアの保守性向上のための研究について紹介しました。現在、さらに設計の履歴書を記録する工数を削減するための方法として、過去に記録した設計の履歴書を別の設計で利用する手法について検討しています。今後も、通信ソフトウェアの生産性、保守性の向上へむけた研究を積み重ねて行く予定です。
参考文献
