日が昇るとどうなるか．夏には太陽と共にたくさんの鳥が歌を奏でることを知っている．多くのことが一度に起こることを記述するとしよう．それはひとことで言えば，並列性である．太陽は，全ての鳥にひとつずつメッセージを送信しないといけないのだろうか？そうだとすると，どの鳥を最初にする? デッドロックの可能性はないのだろうか? これらは愚かな疑問である．ソフトウェアの実行として捉えているからだ．単に，太陽が昇るに過ぎないのに．世界のわかりきった部分を記述するのにも，オブジェクトのメッセージ送信として記述しなければならないといっているようである．ばかげた疑問である 1．
冒頭は，Syntropy手法の教科書にある一文である．UMLのOCL（オブジェクト制約言語）のベースとなっている．Catalysis手法にも影響を与えている．この本には，ずいぶんと影響を受けた．20年近く経っても忘れない，モデル化に関する美しい説明である．
要求段階におけるモデル化の問題を考える上で，忘れてはならない．当たり前のことだが，図式や言語に入り込んでしまうと，大事なことを見落としてしまう．
今回からしばらく，状態機械を扱う．上記を肝に銘じながら説明していく．
前回のイベントトレース図は，基本的に例を示している．参加予定者全員のスケジュールが揃わないときは，別のイベントトレース図を必要とする．フレームを用いた記述は，表現力を高めるが，網羅できるのは単純なケースに限られる．
状態機械図は，システムのふるまいに関して網羅的な記述を与えることを目的としている．
いま，特定の入力によって，ある定まった出力を与えるシステムを考える．
状態機械の原型
このとき，入力の与え方によって，出力が変化する．このシステムは，入力に従って内部になんらかの状態を持つと想像できる機械である（ランダムに出力しているが人間が意味を与えているとは考えない）．状態機械の名前は，この「機械」に由来する．
いま，例として次を考える．入力としては，ゼロないしは1を与える．入力で，1が連続するときには，1を出力し，それ以外は0を出力する機械を考える．
機械内部には，次のような状態があると想像できる（状態機械図としては，一意には定まらない）．
状態機械図の例（Moore）
遷移線の上にあるのが，状態機械への入力である．丸が状態を示しラベル名とともに，状態機械の出力が記載されている（ラベル名／出力）．ざっと追いかけて頂けるとふるまいが確認できると思う．
（nil）
Notes:
- Steve Cook and John Daniels, Designing Object Systems: Object-Oriented Modelling with Syntropy, Prentice Hall 1994 ↩
