日が昇るとどうなるか．夏には太陽と共にたくさんの鳥が歌を奏でることを知っている．多くのことが一度に起こることを記述するとしよう．それはひとことで言えば，並列性である．太陽は，全ての鳥にひとつずつメッセージを送信しないといけないのだろうか？そうだとすると，どの鳥を最初にする? デッドロックの可能性はないのだろうか? これらは愚かな疑問である．ソフトウェアの実行として捉えているからだ．単に，太陽が昇るに過ぎないのに．世界のわかりきった部分を記述するのにも，オブジェクトのメッセージ送信として記述しなければならないといっているようである．ばかげた疑問である[ref]Steve Cook and John Daniels, Designing Object Systems: Object-Oriented Modelling with Syntropy, Prentice Hall 1994[/ref]．
冒頭は，Syntropy手法の教科書にある一文である．UMLのOCL（オブジェクト制約言語）のベースとなっている．Catalysis手法にも影響を与えている．この本には，ずいぶんと影響を受けた．20年近く経っても忘れない，モデル化に関する美しい説明である．
要求段階におけるモデル化の問題を考える上で，忘れてはならない．当たり前のことだが，図式や言語に入り込んでしまうと，大事なことを見落としてしまう．
今回からしばらく，状態機械を扱う．上記を肝に銘じながら説明していく．
前回のイベントトレース図は，基本的に例を示している．参加予定者全員のスケジュールが揃わないときは，別のイベントトレース図を必要とする．フレームを用いた記述は，表現力を高めるが，網羅できるのは単純なケースに限られる．
状態機械図は，システムのふるまいに関して網羅的な記述を与えることを目的としている．
いま，特定の入力によって，ある定まった出力を与えるシステムを考える．
状態機械の原型
このとき，入力の与え方によって，出力が変化する．このシステムは，入力に従って内部になんらかの状態を持つと想像できる機械である（ランダムに出力しているが人間が意味を与えているとは考えない）．状態機械の名前は，この「機械」に由来する．
いま，例として次を考える．入力としては，ゼロないしは1を与える．入力で，1が連続するときには，1を出力し，それ以外は0を出力する機械を考える．
機械内部には，次のような状態があると想像できる（状態機械図としては，一意には定まらない）．
状態機械図の例（Moore）
遷移線の上にあるのが，状態機械への入力である．丸が状態を示しラベル名とともに，状態機械の出力が記載されている（ラベル名／出力）．ざっと追いかけて頂けるとふるまいが確認できると思う．
（nil）
イベントトレース図は，伝統的にはメッセージシーケンスチャート（MSC）と呼ばれるものである．長く，通信業界で用いられてきた[ref]Z.120 Formal description techniques (FDT) – Message Sequence Chart (MSC), ITU-T, 2004[/ref]
UMLでは，バージョン2になってから，シーケンス図にMSC的記述が取り入れられた．もちろん，違いもある．MSCでは，プロセス単位の記述を行うが，シーケンス図では，インスタンス単位の記述を行う．MSCにおけるメッセージの送受信は，プロセス間のメッセージの送受信であるのに対し，シーケンス図では基本的に関数呼び出しである．
ただ，図がどこに重きを置いているということとは別に，要求段階では，我々は（アクタ或いはエージェント同士のやりとりを記述するので）プロセス単位で考えるべきだし，関数呼び出しというよりメッセージのやりとりと見なすべきである．
下図に会議スケジュール管理システムの例を示す．
イベントトレース図
ここで，’?’は インターラクションにおいて，なんらかの回答を求める表記を示している．’！’は，その答えである．
さまざまな図式を紹介する本節で，今回対象とするのは，UMLとともに，よく知られるようになったユースケースである．ユースケース図自体は，UMLが定義される前から，すでに存在していた（従って，UMLで定義されているユースケースとそれ以外は区別した方がよいように思う．ただ，今回は図式の紹介なので，あえて区別はしないでおく）．
表記法が単純である場合，記述が難しくなるのは，他と同様である．会議スケジュール管理システムにおけるユースケースの例を下記に示す．
会議スケジュール管理システムにおけるユースケース図の例
原書の例を，少し書き換えている．
重要なのは，（記法の問題で，勘違いをしやすいのだが）ユースケース図もここまで見た他の図式と同様に機能分割しているわけではない．ユースケースとは，オリジナルの定義に従えば，システム境界を流れるイベント列である．あくまで，システム境界をまたぐが否かが問題で，それ以外の要素を含むべきではない．もし，全て記述したいと云うことであれば，他によい書き方は幾らでも存在している．
原書では，ユースケース図を単純すぎるとしている．少し不当な評価にも思う．Cockburn氏により，適切な詳細化方法が提供されている[ref]Writing Effective Use Cases, Alistair Cockburn, 1st edition, January, 2000, pages 270, Addison-Wesley Professional[/ref]．もちろん，UMLのユースケース図という限定をつければ，妥当な評価ではあるのだが．
(nil)