通信サービス記述と検証の容易化をめざして
1＋1＝2？
ATR通信システム研究所 通信ソフトウェア研究室 平川 豊
1．はじめに
銀行のオンラインシステム、新幹線の座席チケット予約など、各種の通信サービスが、私達の身近に提供されています。しかし、社会の発展の速度は速く、より高機能で、より便利な通信サービスが、常に求められています。
これらの通信サービスの機能の多くは、ソフトウェアにより実現されており、ソフトウェアを容易に作成するための技術が、ますます重要になって来ています。
ATR通信システム研究所では、このような要請に応えるために、第一段階として、電話サービスを対象に、ソフトウェア開発の自動化を目指した研究を行っています。
電話サービスには、不在時に他の電話機に着信を転送する着信転送サービスをはじめ、各種のサービスがあります。個々のサービスはさほど複雑なものではありませんが、複数の電話サービスを同時に受ける場合には、サービスが相互に影響しあい、複雑な状況が生れる場合があります。このような動作は、複合サービス動作と呼ばれ、通信ソフトウェアのなかでも最も複雑な部分となっています。以下ではまず、複合サービス動作について説明します。
2．複合サービスの動作[1]
電話サービスでは、複数のサービスが同時に提供される場合があります。例えば、話中着信サービスと、着信転送サービスを同時に提供している場合を考えてみましょう。
話中着信サービスは、通話中の着信を音で知らせ、通話の切り替えを可能とするサービスです。図1を用いて具体的な動作を説明します。BさんはCさんと通話をしているとし、Bさんは話中着信サービスに加入しているとします。ここで、AさんがBさんにダイヤルをした場合を考えます。Bさんは通話中ですが、話中着信サービスに加入しているため、Aさんは呼び返し音（ringback
tone）受信状態となり、Bさんには通話中着信が音によって通知されます。
次に、着信転送サービスについて説明します。このサービスは、通話中に着信した呼びを指定された相手に転送するサービスです。図2を用いて、具体的な動作を説明します。Bさんが着信転送先としてDさんの電話番号を登録しているとします。今、BさんとCさんが通話中の時、AさんがBさんにダイヤルしたとします。この時、着信転送先であるDさんの電話が使用中でなければ、Dさんの電話に着信し、Aさんは呼び返し音受信、Dさんは呼び出し音受信の状態となります。
では、これら2つのサービスを同時に受ける場合を考えてみます。この際、次のようなサービス間の動作競合が起こります。
図3に示すような場合を考えてみましょう。Bさんは話中着信サービスと着信転送サービスに加入し、しかも着信転送先としてDさんの電話番号を登録しているとします。BさんとCさんが通話中で、Dさんが電話を使用していない時、AさんがBさんにダイヤルしたとします。このときどのように動作するのでしょうか。先に述べた話中着信サービスに従えば、AさんはBさんに話中着信することになります。しかし、着信転送サービスの規定に従うと、AさんはDさんに着信することになります。このような同時に2つの動作が可能な状況を、サービス間の動作競合と呼びます。実際には、このような場合、どちらかの動作を優先したり、サービス加入を片方に制限するなど、サービス性や使い勝手を考慮して設計しなくてはなりません。
電話サービスでは、複数サービス間に、このような相互関係が存在します。従って、単純に、個々のサービスを実現するソフトウェアを開発し、それらを足し合せるだけでは、両方のサービスを実現することはできません（図4）。1＋1が単純に2にならないのです。このため、新たなサービスを導入する場合にも、そのサービスと、既存の全てのサービスとの相互関係を予め厳密に規定する必要があります。これが、ソフトウェア設計を非常に困難なものとしている大きな要因の一つです。
ATR通信システム研究所では、このような複数サービスの相互関係の設計を容易にする手法の研究を進めています。具体的には、サービス個々の動作を設計者が設計すると、支援システムが、設計されたサービス間の競合の有無を機械的に検出する手法の研究を進めています。
このような設計支援を実現するためには、サービス競合を検出し易いサービス記述手法の開発と共に、記述されたサービス間の競合を検出する手法の開発が必要です。以下では、これら2つの課題について説明をします。
3．サービス記述手法
従来、電話サービスの仕様記述では、国際標準となっているSDL記述（Functional Specification Description
Language）[2]が多く用いられています。サービスを記述するには、個々のサービス動作を記述すると共に、前節で述べたようにサービスが競合した際の動作を規定する必要があります。しかし、このようなサービス競合時の動作をSDLで規定する場合、その記述はプログラム記述に近い詳細な記述となり、設計の初期段階で厳密に規定することは非常に困難です。
このため、設計の初期段階に通信サービスの動作を厳密に規定する手法として、状態遷移規則記述（STR記述：State Transition
Rule記述）手法[3,4]を開発しました。この手法では、通信サービスの動作を、システム内部動作の詳細には、立ち入らないで利用者の視点からの動作として記述することが特徴です。
具体的なSTR記述例を図5に示します。これは、基本的なサービス動作の一部を記述したものです。図には、4つの規則が記述されています。各規則は、「現状態」、「イベント」、「次状態」の3つの部分から構成されています。各規則は、次のような動作を規定しています。少しくどいかもしれませんが、実際の状況を想像しながら以下お読みください。
規則1）電話機を使用していない状態（空状態と呼ばれる）で、受話器を上げると、発信音受信の状態となる。
規則2）端末Aが発信音受信の状態で、端末Bが空状態の時、A端末からB端末にダイヤルすると、A端末は、呼び返し音受信の状態に、B端末は呼び出し音の鳴っている状態になる。
規則3）端末Aが発信音受信の状態で、端末Bが空でない状態の時、A端末からB端末にダイヤルすると、A端末はビジー音受信の状態になり、B端末の状態変化はない。
規則4）端末Aが呼び返し音受信の状態で、端末Bが呼び出し音の鳴っている状態のとき、端末Bが応答する（受話器を上げる）と、両者は通話中の状態になる。
対応する従来仕様記述（SDL）を図6に示します。図5の記述と図6の記述は等価なものです。図5の規則2と規則3に対応する動作は、次のような手順として、図6に記述されています。端末Aが発信音受信状態の時、端末Xを指定するダイヤルを受信したとき、端末Xに対して、信号1（着信要求）を送出します。端末Xが信号1を空状態で受信した場合には、信号2（着信応答）が返送され、端末Xは呼び出し音受信状態へ、また、端末Aは呼び返し音受信状態へ遷移します。一方、端末Xが空以外の状態（not〔空（B）〕対応する発信音受信状態など）で信号1を受信した場合には、信号3（棄却）が返送され、端末Aはビジー音受信状態へ遷移し、端末Xでは状態遷移は起こりません。
従来、設計者は、図5に記載したような、各状況でどの様な動作をすべきかということを理解し、それを実現する図6の形式の制御手順を作成していました。図5の各状況に矛盾せず、しかも漏れのない手順を作成することは容易なことではありません。これに対し、私たちが提案する図5のような記法では、各状況を個別に記述するため、人間の理解と親和性のよい記述となっています。
また、この記述は、各要求動作（イベント）が起きたとき、その影響を受ける範囲をその都度指定できます。これは、従来記述になかった特徴であり、これを利用することにより、複数サービスの複合した場合の動作記述が容易となります。
4．サービス記述の正当性検証[5,6]
図7に、図1と図2を用いて説明した話中着信サービスと、着信転送サービスの動作記述を示します。この2つの規則は図3に示した状況に対して、異なる2つの動作を規定しています。規定が不完全である場合には、しばしば2つの規則が競合することがあります。
例えば、以下の状況（図3に対応）で、図7の2つの規則を考えてみましょう。
端末A：発信音受信状態。
端末B：Cと通話中、かつ話中着信可能。同時に、着信転送として端末Dを登録。
端末D：空状態。
この状況では、図7の2つの規則の条件が共に満たされるため、2つの規則が共に適用可能となり、動作競合となります。
上記の3つの端末の状態は、図7の2つの規則の条件である現状態の記述を複合したものです。
競合の機械判定は、以下のように行います。
step 1）1つの端末の動作に着目し、規則を用いて、端末が取り得る状態を全て列挙します。
step 2）2つの規則に対して、上記のような両方の条件を複合した端末状態を作成します。
step 3）作成した端末状態（例えば、上記端末A、B、Dの状態の各々）がstep 1）で列挙した端末状態に含まれているならば、競合の可能性があると判断します。
この手法により、人間の手作業では困難な規則間の競合検出を、機械的に行うことができます。現在、この検出手法をワークステーション上にインプリメントし、実際の電話サービスのSTR記述を対象とした競合検出実験を行っています。
今後は、検出手法の高速化に向けて取り組む予定です。
5．おわりに
通信システム研究所で行っている、通信サービス記述・検証の研究について紹介しました。現在、通信ソフトウェアの自動作成を実現する一手法として、STR記述を標準的な仕様記述言語に変換する手法[7]、仕様の詳細化を支援する手法なども並行して開発中です。今後も、自動作成の夢の実現にむけ、段階的な研究を積み重ねて行く予定です。
参考文献
