UMLやSysMLを活用できないエンジニアのための実践的活用術（前編）：プロジェクトを成功させるモデリングの極意（1）（4/6 ページ）

[五味弘，MONOist]

状態遷移図（State Transition Diagram）

　状態遷移図はシステムの状態に注目して、状態とその遷移を図で表現したものです。

　組み込み系システムなどのように状態数が多いシステムや状態が変更されるようなシステムではこの図がモデルとして多く使われます。特に通信関係のシステムではよく見られます。図6に状態遷移表の例を、図7にUMLのステートマシン図の例を示します。

図7. 状態遷移表

図8. UML ステートマシン図

　状態遷移図を描くときにもいろいろな問題や実践的なコツがあります。例えば、状態遷移図で表現しない（できない）隠れた状態をどうするのか、時間とともに変化する状態をどうするのか、例外状態や例外遷移をどうするのか、状態や遷移の分類をどうするのかなど、さまざまな問題があります。

　状態遷移図では複雑怪奇な図をよく見かけます。例えば距離の長い遷移が図にあるときは遷移を追いかけるだけで疲れてしまい、モデルとしては使い物にならなくなります。状態遷移図の記述能力は低い（遷移のカテゴリがなく荒っぽくしか書けないなど）ので、遷移の分類や意味論が不明になりがちで、リモデリングもクラス図よりやっかいになります。このため最初に状態遷移図を作るときには気を引き締めてください。この連載では状態遷移図特有の話はここだけになりますが、この連載を読んでモデリングのコツを学んでいただければ、きっと状態遷移図も魑魅魍魎な図にはならないでしょう。

フローチャート（flowchart）

図9. フローチャート

図10. UML アクティビティ図

　フローチャートは昔からあるモデル図で、処理の流れを表現した図です。処理の流れを順次操作や分岐、繰り返しで表現します。図8にフローチャートの例を、図9にUMLでフローチャート的なものを描くときに使う「アクティビティ図」の例を示します。

　フローチャートは単純な表記なので面積が大きくなるという欠点もあり、どうしてもA3用紙が必要になるというA3症状が出ます。そこで各社がフローチャートの表現能力を高めてコンパクトに記述するために、独自の拡張を行っています。例えば、NTTのHCP（Hierarchical ComPact description chart）や日立のPAD（Problem Analysis Diagram）、NECのSPD（Structured Programming Diagram）、富士通のYAC（Yet Another Control chart） などがあります。

　フローチャートも立派なモデリング手法です。このモデリングには歴史があるので、多くの人に利点と欠点が知られていて、その使いこなしのコツも広く普及しています（コンパクトに描くとあちこちにジャンプ記号が出てきて迷路のようになりがちです、そうならないように修行したひとも多いはずです）。この連載記事では後ほど、A3症状に陥らず、コンパクトに描くコツを紹介します。