状態遷移表設計によるソフトウエア開発プロセス改善
The Improvement of the Software Development Process through the Use of State Transition Matrix

渡辺智＊

Watanabe, Satoshi

滝研司＊Taki, Kenji

黒畑貴夫＊

Kurohata, Takao

In the process of developing control software for office machinery, we have introduced the design
method based on state transition matrix. As a result, the quality of software is raised with decreasing theoccurrence of failure. This report describes the feature of method, the result with the applied case, and theefficiency of development tool.

１

はじ め に２

情報 機 器制 御 シス テ ム制 御 の特 徴複写機をはじめとする情報機器は多機能、高性能化し、情報機器は、機器に組み込まれたコンピュータシステ

それを制御するソフトウエアも肥大、複雑化している。

ム（組込みシステム）によって制御されており、次のよ

また、商品サイクルも年々短くなり、開発期間の短期化

うな特徴がある１）。

が求められている。これらの機器を制御するソフトウエ

第一に、組込みシステムはユーザによる操作やセンサアの開発においても、このような要求に対応するための信号等の外部からの事象（イベント）に対して、ランプ対策が望まれている。

を点けたりモータを回す等の処理（アクション）を行う

従来のソフトウエア開発は、要求仕様書からソフトウ反応型（リアクティブ）システムであることがあげられエア設計仕様書を作成し、この設計仕様書をもとにソフる。このようなリアクティブなシステムでは、内部の状トウエアの最終段階であるソースコードを作成していた。

態と外部からの事象により制御（処理）を行うことが多しかし、要求仕様書の大部分が図表でなく文章で書かれい。２）ているために、ソフトウエア設計者が要求仕様書の文章

情報機器の一つである複写機について考えてみると、を読解してソフトウエアを設計する段階で、誤解が生じ原稿をセットしてからコピーボタンを押してコピー動作たり、思考の漏れや抜けが生じる可能性がある。対象とを開始する手順を処理するためには、原稿がセットされなるソフトウエアが複雑になればなるほどこの傾向は顕た時点でその状態を内部に保持し、コピーボタンが押さ著となっている。また、ソフトウエア設計仕様書もほとれた時点で内部に保持した原稿がセットされているといんどが文章で書かれているため、デザインレビュー等にう状態と照らし合わせて、コピー動作（処理）を開始す

おいては、レビューの参加者が、設計内容をビジュアルる。ただ、単純に思えるこの動作も、実際にはコピーボに把握することができず、期待通りのレビューを行うこタンが押された時に機器がウオームアップ中なのか、すとができないと言った問題も起こる。

でにウオームアップが完了した状態なのかといったようさらに、時事刻々変化する市場ニーズへの対応や開発に、多くの状態が存在することになる。

段階での課題に呼応して要求仕様が変更されることがあ

第二には、制御対象に予測・制御不可能な要素が含まるが、従来は変更内容が記載された仕様書や変更部分がれているために入力と出力の関係が一意に定まらないこ

修正された仕様書をソフトウエア担当者が読解し、直接とがあげられる。

ソースコードを修正している。このため変更部分の影響

例えば複写機では、給紙開始指令を出してから紙が通について漏れや抜けが生じ、仕様変更に伴なう不具合が過検知センサに到達するタイミングは、紙の特性や環境発生することがある。

要因等により複写動作の各紙毎で異なっており、同一の今回、上記の問題点を改善すべく、複写機のフィニッタイミングで制御することは不可能である。第一の特徴

シングシステムおよびカラープリンタシステムの制御ソで示した多くの状態において、様々なタイミングで事象

フトウエア設計に状態遷移表設計手法を導入した。また、が発生することとなる。

合わせて状態遷移表設計を支援するCASE（Computer

即ち、複写機をはじめとする情報機器の制御設計におAided Software Engineering）ツールの導入効果については、複雑にからみあった状態と、これらの状態においても評価を行ったので、その結果と有効性について紹いて様々なタイミングで発生する事象を如何に整理する介する。

かが課題となる。

＊ＯＤカンパニー 機器開発統括部 第３開発センター

KONICA TECHNICAL REPORT VOL. 13（2000）

65

３

状態 遷 移表 設 計手 法 の導 入

３．１

目

的

本手法導入の目的は、状態遷移表を使ってソフトウエア設計を行い、状態と事象を明示的に整理することにより、ソフトウエア設計段階で発生する不具合を低減することである。
Fig.１は、複写機のフィニッシングシステムの開発段

Fig.２ 状態遷移表（例）

階で発生したソフトウエア不具合について、不具合の発生原因を、要求仕様そのものの不備、設計段階でのミス、コーディング段階でのミスの３つに大別して示したものである。

今回、状態遷移表設計手法を２つの機種開発の一部に導入した。

Fig.１から、不具合の多くは設計段階で発生しており、一つは、複写機のフィニッシングシステムの制御ソフ

ソフトウエア不具合を低減させるには、設計段階での不トウエア設計への適用である。今回設計手法の導入対象具合低減が有効であることがわかる。としたのは、フィニッシングシステムのカバーシートフィーダー機能である。カバーシートフィーダー機能とは、複写機本体から排出されてくるコピー紙に対して、予めフィニッシングシステムに用意された紙を表紙や裏表紙として挿入する機能である。ユーザーが、予めフィニッシングシステムに用意された紙をどこに挿入するかを指定するオペレーション機能と、紙を搬送して複写機本体から排出されてくるコピー紙と合わせるために機構部品を制御する搬送制御機能とから構成されている。今回は、この両方の機能のソフトウエア設計に手法を導入した。

Fig.１ 不具合発生の原因となった工程もう一つは、カラープリンタの状態管理機能である。
設計段階で不具合が発生する原因として、次のようなことがあげられる。

プリンタの制御ソフトウエアは、外部との通信を行う通信機能、機械の状態を監視しプリント作業全般について第一には、設計が設計者の頭の中で行われており、そ司令を出す状態管理機能、画像を形成する画像形成機能、の結果を明示的に示すものがないため十分なデザインレ

紙の搬送を制御する紙搬送機能、トナーを紙に定着させビューが行われないこと。第二には、納期圧力の関係かる定着機能、特殊な動作司令に対応して動作する特殊機ら設計の一部を端折ってコーディング作業を開始してし能より構成されているが、今回は状態管理機能のソフト

まい、コーディング中に設計漏れや設計抜けに気付いてウエア設計に手法を導入した。

も設計フェーズにもどらずその場のコーディングで対処してしまうこと。第三には、仕様変更があった場合、設計者が頭の中で考えていた初期設計時の情報が失われて４

結果

４．１

不具合発生率の低減

おり、変更仕様の織込みに際して、影響範囲や関連個所

Fig.３は、フィニッシングシステムにおいて状態遷移の把握が十分に行えずに設計漏れや設計抜けが生じ易い表設計手法を採用してソフトウエア設計を行ったカバーこと。

シートフィーダー機能と、従来の設計手法でソフトウエ

状態遷移表設計手法の導入は、これらの問題を解決し、ア設計を行ったその他の機能でのソフトウエアの不具合

設計段階での不具合を低減することにある。

発生率を示した表である。手法の導入により設計段階で３．２の不具合発生率が従来の約1/2に低減されている。

導入

状態遷移表設計手法は、制御対象となるシステムがとり得る全ての状態と、そのシステムで発生する全ての事象を洗い出し、この２つの要素より構成される表を作成し、ある状態である事象が発生したときの処理をその表の升目（セル）に記載するとともに、処理実行後にシステムがとる状態を記載することにより、システム全体の動作を設計するものである。Fig.２に状態遷移表の概要
Fig.３ 各機能での不具合発生率を示す。

66

KONICA TECHNICAL REPORT VOL. 13（2000）

Fig.４は、同様にカラープリンタにおいて状態遷移表全てのセルについてそこでの処理を考えるため、設計段設計手法を採用してソフトウエア設計を行った状態管理階での漏れや抜けを防止できるからである。

機能と、その他の機能でのソフトウエアの不具合発生率

５．２

デザインレビューでの有効性を比較した表であるが、このシステムにおいても、手法

Fig.６は、フィニッシングシステムのカバーシートフィーの導入により設計段階での不具合発生率が従来の約1/4

ダー機能の初期設計段階で作成した状態遷移表をもとにに低減されている。

デザインレビューを行った際のデザインレビューでの不具合指摘件数とその後に指摘を受けた不具合の件数割合を示したものであるが、不具合の多くがデザインレビューにより指摘されていることがわかる。これは、仕様を状態遷移表で表すことにより、従来設計者の頭のなかで行われていた設計がビジュアル化され、デザインレビューの参加者が設計内容を理解しやすくなり、適切な指摘が可能になったためと考えられる。

Fig.４ 機能別の不具合発生率４．２

仕様変更への対応

今回のカバーシートフィーダー機能の開発では、初期設計で機能の基本的な部分に対応した小規模な状態遷移表を作成し、開発の進捗に伴って発生する要求仕様を、状態・イベントの追加として折り込み、状態遷移表を拡張する方法を採用した。
Fig.５は、初期設計での状態遷移表と最終的な状態遷移表のセル数を比較したものであが、この方法により開発の進捗に合わせて初期の約2.5倍の規模まで状態遷移表を拡張し、且つ、日程の遅延なく前記のように高い品

Fig.６ 不具合指摘件数質のソフトウエアを提供できた。
５．３

仕様変更への適応性

Fig.７は、状態遷移表設計手法を導入してフィニッシングシステムのカバーシートフィーダー機能を開発した際の工程別作業工数の割合を示したものである。

Fig.５ 各設計段階でのセル数

５考察

５．１

設計における手法の有効性

今回ソフトウエア設計に状態遷移表設計手法を導入した機能は、ユーザーインターフェイスの役割を担うオペレーション機能、紙搬送のための機構制御を担う搬送制
Fig.７ 工程別作業工数

御機能、プリンタシステムの状態監視と全体の制御を担う状態管理機能といったように夫々異なった機能であるが、これらは全て有限の状態をもち、外部からの事象の状態遷移表設計手法を導入したソフトウエア開発では、変化を受けて、何らかの処理を行うリアクティブなシス設計作業が全体の作業量の約６割を占めている。初期設テムであると考えることができる。状態遷移表設計は、計において設計の作業量が大きなウェイトを占めること

この様なシステムの設計段階において発生する不具合のは容易に想像される。しかし、仕様変更を行った最終段防止に有効な方法であると言える。これは、状態遷移表階においても、なお、設計作業が初期設計と同等のウェを活用して設計を行うことにより、システムがとりうるイトを占めるのである。

全ての状態とイベントを洗い出すと共に、状態遷移表の

これは、状態遷移表設計では仕様変更時に、追加またKONICA TECHNICAL REPORT VOL. 13（2000）

67

は削除される状態とイベントを整理した後、状態遷移表

ルが状態遷移表の肥大化防止に有効であることが確認でを修正するためである。即ち、仕様変更時も初期設計時きた。と同様に状態遷移表による設計作業が行われるため、仕ソースコードの不一致については、CASEツールが持様変更作業後でも作業全体に占める設計作業のウェイトつソースコード自動生成機能を活用することによって改は変わらないのである。この再設計作業により、仕様変善が可能であると考え、今回状態遷移表設計手法を導入更に伴なう設計漏れ、設計抜けを防止できる。

したカラープリンタの画像形成機能の一部について、そして、状態遷移表設計では、最新の仕様に対して、CASE ツールを活用して状態遷移表による再設計を行常に最適な設計がされていることになる。これにより、い、CASEツールの自動生成機能によるソースコードのソフトウエアの最新の設計状態を容易に把握できるとと自動生成を行った。

もに、たとえ不具合が発生しても現状分析が容易であり、その結果、状態遷移表で記述した分岐条件等が自動的短時間で原因解析が可能であるという効果が期待できる。にコード化され状態遷移表とソースコードの不一致が回６

状態 遷 移表 設 計支 援 ツー ル の評 価

ソフトウエア設計に状態遷移設計手法を導入し、その有効性を確認することができたが、今回の手法導入において幾つかの課題があったことも事実であった。

避されたと同時に、ソフトウエア設計者によって入力するソースコードが1/3に軽減された。また、最終的に生成されたオブジェクトコードは、CASEツールを使用せずに作成したときとほぼ同等であった。
CASEツールの活用は、以上のような効果があるが、そこで、この課題を解決するため、状態遷移表設計手法導入の初期段階ではツールに習熟するための時間が必要を支援するCASEツールについても調査とその評価を行っである。

た。
CASEツールについては、ツールの各種機能や、その７

むす び

CASEツールを実際の開発業務に活用した事例が紹介さ

情報機器の制御ソフトウエア設計に状態遷移表設計手れており、今回はこのCASEツールを採用した３）、４）。

法を導入することによりソフトウエア設計段階での不具

今回の手法導入の中で出てきた課題は、状態遷移表の合発生を低減できることを確認した。同手法は多数の状肥大化と、状態遷移表とソースコードの不一致である。

態と事象を管理するプログラムの設計に有効な手法であフィニッシングシステムのカバーシートフィーダー機能ると考える。の開発においては、市販の表計算ソフトを活用して状態今後、同手法をより多くの開発に適用していくと共に、遷移表の作成を行った。しかし、Fig.５にも示したよう支援ツールも含めより効果的な導入方法についても検討に、オペレーション機能、搬送制御機能とも状態遷移表していく必要があると考える。のセル数が1000を超えており、全体を一度に把握することが難しくなると同時に、状態遷移表のコンピュータの●参考文献

画面への表示、紙へのプリントアウトといった物理的な

１）高田広章, 情報処理, Vol.38 No.10, 870,（1997）
２）川口晃, 岸知二, 門田浩, 情報処理,Vol.38 No.10, 881, (1997）面での制約も発生した。
また、フィニッシングシステムの開発では、ソースコー
ドの作成は、状態遷移表を見ながらソフトウエア作成者がコードを作成する作業を行ったが、この際に入力ミス

３）渡辺政彦, リアルタイム制御CASE, 初版, 電子開発学園編,電子開発学園出版局, (1993)
４）渡辺政彦, 石田哲史, 戴志堅, リアルタイム環境へのCASE導入, 初版,電子開発学園編, 電子開発学園出版局, (1994)が発生した。今後、より多くのシステム開発に状態遷移表を採用した場合、この作業は大きな課題になると考えた。
今回の状態遷移表設計において、状態遷移表が肥大化した大きな要因は、セルの中に条件判断をうまく記述できないことにあった。今回のように市販の表計算ソフトを活用して状態遷移表を作成した場合は、操作上、セルの中を分割することが難しく、新たな状態を作成して対処することとなる。この結果状態の数が多くなり、状態遷移表が肥大化してしまった。これに対して、CASEツー
ルはセル内での条件分割機能がある。フィニッシングシ
ステムのオペレーション機能について、CASEツールの条件分割機能を使用して状態遷移表を再設計した。その結果、状態遷移表のセル数を約1/6にでき、CASEツー

68

KONICA TECHNICAL REPORT VOL. 13（2000）