草稿 - 最近のメタボリックス

Fractal UML Modeling No.2
Fractal UML Modeling No.2 (for Embedded Systems)
フラクタル UML モデリング No.2 (制御系編)
YAMADA Masaki/Metabolics, Ltd.
山田正樹/メタボリックス
© Metabolics, Ltd., 2003
1/77
Fractal UML Modeling No.2
01.01. 目次
Part I 浴室制御システム
01.02. はじめに
01.03. 浴室制御システム
01.04. ユースケース・ビュー
01.05. システム
01.06. アクタ
01.07. 静的なモデリングと動的なモデリング
01.08. アクティビティ図
01.09. ワークフロー
01.10. ユースケース
01.11. ユースケースとアクタ
01.12. ユースケース・シナリオ
01.13. シーケンス図
01.14. ユースケース・シナリオを描いてみる
01.15. ユースケースの事前条件/事後条件
01.16. 状態
01.17. ライフサイクル
01.18. 概念ビュー
01.19. 概念オブジェクト
01.20. コラボレーション
01.21. 概念オブジェクトの詳細化
01.22. ライフサイクル
01.23. アクション
01.24. 事前条件/事後条件
01.25. シミュレーションと検証
01.26. 次のステップ
01.27. パッケージ
2/77
Fractal UML Modeling No.2
Part II 外部コントローラ
02.01. 外部コントローラ
02.02. アクタ
02.03. ワークフロー
02.04. ユースケース
02.05. シナリオ
02.06. 事前条件/事後条件
02.07. 状態
02.08. シグナル
02.09. ライフサイクル
02.10. 次のステップ
3/77
Fractal UML Modeling No.2
Part I. 浴室制御システム
01.02. はじめに
フラクタル UML モデリング、略して FUM とは UML を使ってソフトウェアを
開発する一つの方法です。UML はモデリング言語の標準で、モデルの記法に
ついては規定されていますが、ソフトウェア開発のどのような局面でどのよう
なモデリングをすればよいかについてはどこにも書かれていません。したがっ
て UML の書き方を覚えただけでソフトウェア開発に利用しようとするのは、
楽譜の読み方を覚えただけで演奏会をしようとするようなものといえるでしょ
う。
本書ではオブジェクト指向の基礎概念について理解している方を対象に、UML
の記法と UML を使ったソフトウェア開発の方法について述べています。ソフ
トウェア開発の方法は対象となるシステムの種類やプロジェクトの種類の数だ
けあり得ますが、No.2 では制御系システムを例にとって典型的な開発の方法を
見ていきます。ビジネス系システムを例にした FUM は No.1 をご覧ください。
FUM ではその名前のとおり、システムをフラクタルにモデリングしていきます。
つまり最初はおおざっぱに対象をモデリングし、さらに対象の複雑さに合わせ
て細部をモデリングしていくという過程を再帰的に繰り返します。FUM が従来
の構造分析/設計の方法と異なるのは、段階的な詳細化が一方向にツリー状に行
われるのではなく、対象の複雑さに応じて行ったり来たりしながらセミラティ
ス状に行われる点です。
「フラクタル UML モデリング」という特別な名前を付けてはいますが、FUM
は他のオブジェクト指向開発方法論と多くの共通点があります。ですから FUM
のやり方を身につけていれば、他の方法論を利用する場合にも困ることはない
でしょうし、自分たちのプロジェクトにあった方法に応用することもできるよ
うになるでしょう。
4/77
Fractal UML Modeling No.2
01.03. 浴室制御システム
今回はお風呂の湯沸かしを制御するシステムを考えます。教材ですから、実際
のシステムに較べればいろいろな点で簡略化して扱いますが、本質的なところ
は本当のシステムと同じです。
このシステムは皆さんの家のお風呂に付いているのと同じように、設定した水
位/湯温で自動的にお風呂を沸かしたり、沸き上がった後一定の水位/湯温に保
つものです。沸かす時間を指定して予約することもできます。
コントローラは浴室と浴室外の二つがあり、それぞれ多少機能が異なります(た
とえば浴室コントローラは予約はできないが、お湯の増量や暖めを指示できる
など)。また Web 経由で設定や予約をすることもできます。
浴槽には水道と風呂釜が付いていて、システムはこれらを制御して上記の機能
を実現します。また浴槽のお湯を風呂釜に循環させる弁もあります。通常は台
所や洗面所と共通の給湯システムになっているでしょうが、今回は簡単のため
にお風呂だけのためのシステムとします。
この会社ではこのようなシステムを開発するのは初めてなので、詳細について
は開発を進めながら詰めていくことにします。
5/77
Fractal UML Modeling No.2
01.04. ユースケース・ビュー
FUM ではまずシステムを外側から見た視点でモデリングします。これを「ユー
スケース・ビュー」ということがあります。通常のシステム開発方法でいえば
外部仕様に相当するものです。
ユースケース・ビューは UML では主にユースケース図を使って表現します。
ユースケース図に登場するのは主にシステム、アクタ、ユースケースといわれ
るものです。またこれらの振る舞いをモデリングするためにアクティビティ図
やシーケンス図、ステートチャート図も使います。
制御系のシステムは従来ユースケース・ビューはあまり真剣に考えられてこな
かったり、企画部門だけで決められていたこともあるかもしれません。しかし、
今後のシステム開発では顧客満足度を高めたり、全体的な品質を向上させる上
で重要な役割を担うものと考えられています。
順に見ていくことにしましょう。
6/77
Fractal UML Modeling No.2
01.05. システム
最初にユースケース図にこれから我々が作ろうとしているシステムそのものを
描きます。これがモデリングの出発点になります。
まず、新しいプロジェクトを作成しましょう。Ctrl-N あるいは「ファイル」メ
ニュー->「新規プロジェクト」を選択します。MagicDraw は比較的安定して動
作するツールですが、念のためにこまめに保存(Ctrl-S あるいは「ファイル」メ
ニュー->「プロジェクトを保存」)します。
作成したプロジェクトの細かい設定は「オプション」メニュー->「プロジェク
ト...」で行います。好みによりますが、「スタイル」->「デフォルト」->「パス」
の「直線の種類」は「斜線」にしておいた方が書きやすいかもしれません。
新しい図を作るには「図」メニューから図の種類を選択するか、ツリー・ビュ
ーの「データ」を右クリックして「新規の図」から図の種類を選択します。ま
ずはユースケース図を作ってみましょう。ダイアグラムの名前はとりあえず「ユ
ースケース・ビュー」とでもしておきます。
ダイアグラムに新しい要素を追加するには、ツリー・ビューとダイアグラムの
間にあるツール・バーから要素を選択してクリックし、さらにダイアグラムの
適当な場所をクリックします。「システム」の場合は上から 8 番目のアイコン
を右クリックするか、長押しして「システム境界」を選択します。さらにダイ
アグラムの適当な位置でクリックすれば、長方形が描かれたはずです。この内
側が我々がこれから作ろうとしているシステム、外側がこのシステムに関連す
る外部環境となります。
この長方形が選択された状態でダブル・クリックするか、Enter キーを押すと「仕
様パネル」が表示されます。要素に関する詳しい情報はここに入力します。こ
こでは「名前」を「浴室制御システム」として、パネルの下にある「OK」ボ
タンをクリックしましょう。
7/77
Fractal UML Modeling No.2
ダイアグラムにある要素を右クリックしても、その要素に関するさまざまな設
定や見え方の制御を行うことができます。またダイアグラムと同時にツリー・
ビューにも同じ要素が現れているはずです。ここで要素を右クリックしても、
さまざまな設定や制御を行うことができます。
ダイアグラムとツリー・ビューは微妙に異なっています。ダイアグラムは「見
栄え」を表します。一方ツリー・ビューは「構造」を表します。たとえば一つ
の同じ要素を複数(同一の、あるいは異なるダイアグラム上に)表示することが
できます。そのためにはツリー・ビューから要素をダイアグラム上にドラッグ
&ドロップします。この場合ダイアグラム上では同じ要素が複数見えています
が、ツリー・ビュー上では増えていないはずです。まだダイアグラム上でたと
えば要素の一方の名前を変更すれば、ダイアグラム上のもう一方の要素の名前
も、ツリー・ビュー上の要素の名前も同じように変わります。
これに関連して重要なのは、ダイアグラム上で要素を「削除(Delete)」したら、
要素はダイアグラムからは消えますが、モデルには残っているということです。
その要素をツリー・ビューからダイアグラムにドラッグ&ドロップすれば、ま
た見えるようになります。逆にダイアグラム上で「削除(Ctrl-D)」したり、ツリ
ー・ビュー上で「削除(Delete)」したらその要素はモデルから(当然すべてのダ
イアグラムからも)消えてしまいます。間違って消してしまった場合にはデフォ
ルトでは 100 レベルまで「取り消し」(Ctrl-Z)できます。
我々のシステムはこの時点ではよく分かっていないものですから、単純な長方
形をしていますが、これからモデリングを行っていく過程で徐々に複雑な形に
変形していくことになります。
8/77
Fractal UML Modeling No.2
01.06. アクタ
アクタとは我々が作ろうとしているシステムに関係する外部要素のことです。
もっと具体的に言えば、たとえばシステムのユーザとか、システムと通信する
他のシステムなどがアクタになります。アクタは人型のアイコンで表します。
このアイコンをスティックマンと呼ぶこともありますが、実際のアクタは人以
外のシステムの場合もあります。
浴室制御システムのアクタには何があるでしょうか? まず直接のユーザはお風
呂に入る人です。ただし実際にお風呂に入って湯温や水位を調整している場合
と、外部コントローラから予約や自動沸かしの設定をしている場合では役割が
違いそうです。ここではシステムとどのように関わっているか、を軸にして次
の三つの役割を抽出します。アクタとは特定の人を表しているわけではなく、
役割を表しているのです。
o 浴室ユーザ - 実際にお風呂に入っている人
o 外部ユーザ - 外部コントローラから設定をする人
o Web ユーザ - web 経由で運転や予約をする人
さらに忘れがちですが、このシステムの場合には点検や保守を行う人もいます。
この人もアクタとして識別しておきましょう。
o 保守ユーザ - 点検や保守をする人
アクタは我々が作ろうとしているシステムからすれば外部の要素ですから、シ
ステムを表す長方形の外に描きます。またアクタの名前は、アクタの役割を的
確に示す簡潔な単語を付けるようにします(口で言うほど簡単ではありません
が:-)
もっとよく考えていくとアクタはまだまだあるかもしれません。しかしモデリ
ングをしているときにはある程度考えてある程度の結果が出た時点で先に進み
ます。そこに止まって考え込んでいても答えは出てこないからです。必要なら
9/77
Fractal UML Modeling No.2
ばまた後で戻ってきます。モデリングとは完璧な正解を作る場ではなく、試行
錯誤の場なのです。
10/77
Fractal UML Modeling No.2
01.07. 静的なモデリングと動的なモデリング
FUM によるモデリングの一つの特徴は、静的なモデリングと動的なモデリング
を交互に繰り返していくことです。たとえばさっきはアクタをモデリングしま
した。ここでは時間の概念は出てきませんから静的なモデリングです。しかし
静的なモデリングからは対象の構造は見えてきますが、それらが実際にどのよ
うに動くのか、本当に思ったように動くのか、ということが分かりません。し
たがって静的なモデリングを行ったら、それを実際に動かしてみます(今はモデ
ルの上と頭の中でシミュレートするだけですが)。それが動的なモデリングです。
動的なモデリングを行うことによって、前に行った静的なモデリングに問題が
あることが分かることもありますし、新たな構造が必要であることが分かるこ
ともあります。動的なモデリングはいわば静的な構造の検証(デバッグ)に相当
します。また動的なモデリングを行うことによって次のステップに進むヒント
を得ることができます。
アクタをモデリングしたら、今度はそのアクタたちがどのように振る舞うかを
モデリングします。アクタたちの振る舞いをモデリングしたものをワークフロ
ーと呼びます。
11/77
Fractal UML Modeling No.2
01.08. アクティビティ図
ワークフローとは、アクタたちの振る舞いの様子をモデリングしたものです。
UML ではアクティビティ図を使って表します。アクティビティ図は、アクシ
ョン(動作)やアクティビティ(活動)の連鎖を表すための図です。
アクティビティ図では動作や活動は俵型のアイコンで表して、アクション状態
と呼びます。アクション状態には「XXX をする」というような動作や活動を表
す名前を付けます。
アクション状態には主語に相当する存在があるはずです。ワークフローでは普
通それがアクタになります。複数のアクタにまたがるワークフローでは、アク
タを区別するためにアクティビティ図を縦に区切ることができます。この区切
りのことをスイムレーンと呼びます。スイムレーンには動作や活動の主体とな
る存在の名前を付け、その主体が行うアクション状態はこのスイムレーンの中
に描きます。
アクション状態とアクション状態は矢印でつなぎます。矢印でつながれたアク
ション状態はある動作が起きて、その次に次の動作が起きるという時間上の前
後関係を表します。
動作の流れが何らかの条件によって分岐するときには判断を表す菱形を使いま
す。また動作の流れが二つ(かそれ以上)の並行した流れに分岐するときには同
期バーを使います。同期バーで分岐した流れが合流するときにも同期バーを使
います。
ときにはアクション状態の間で何らかの情報が受け渡されることもあります。
その情報をオブジェクト・フローと呼び、長方形で表します。オブジェクト・
フローはアクション状態からアクション状態への矢印の間に置きます。
12/77
Fractal UML Modeling No.2
01.09. ワークフロー
まず中心になるワークフローを考えてみましょう。ワークフローとは、アクタ
がある目的(この場合は快適にお風呂にはいること)を達成をするためにどのよ
うな振る舞いをするかを表したものです。
たとえば次のようなワークフローを考えることができます。いろいろな設定を
して、その場でお風呂を沸かし始め、お風呂に入って湯温や水位を変え、止め
てお風呂から出てくるような場合です。
1. 外部ユーザが初期設定する(最初、あるいはリセット後の一回のみ)
2. 外部ユーザが湯温や水位を設定する(既定値でよければ不要)
3. 外部ユーザが自動でお風呂を沸かし始める
4. 浴室ユーザが入浴する
5. 浴室ユーザが湯温や水位を変える(変えない場合もある)
6. 浴室ユーザが止める(外部ユーザが止める場合もある)
これをアクティビティ図に描いてみると次のようになります。
13/77
Fractal UML Modeling No.2
最初は一番単純なケースを考えてみましたが、他にもいろいろな場合がありそ
うです。たとえばお風呂を沸かし始めたけれど途中で止めたくなる場合もある
14/77
Fractal UML Modeling No.2
でしょう。そのような場合は前のワークフローを少し変えて次のようにします。
ここで角括弧[]に記述されているのは分岐の条件でガードと呼びます。UML で
15/77
Fractal UML Modeling No.2
はシーケンス図に限らずさまざまなダイアグラムでガードが使われています。
さらに予約をしたい場合にはどうすればいいでしょうか。
16/77
Fractal UML Modeling No.2
01.10. ユースケース
動的モデリングを行ったら、それを元に前に行った静的モデリングの妥当性を
検証します。見落としていた重要なアクタはないでしょうか。
問題がなければ、この動的モデリングの成果をふまえて次の静的モデリングに
進みます。次の静的モデリングではユースケースを考えます。ユースケースと
は、システムがアクタに提供する外部機能のことです。サービスやフィーチャ
といわれているものともだいたい同じです。重要なのはあくまでアクタにとっ
て意味のある機能だけを考えることです。ユーザにとって直接意味のない内部
機能はこの段階では考えません。
ユースケースは UML ではユースケース図に記述します。ユースケースとはシ
ステムが提供する外部機能ですから、システムの長方形が描かれている場合に
はその中に描きます。ユースケースのアイコンは楕円形です。アイコンの中に
はユースケースの名前を書きますが、通常は「XXX が YYY を ZZZ する」とい
うようになります。XXX(場合によっては YYY)がアクタに相当しますが、明確
ならば省略しても構いません。
浴室制御システムではどのようなユースケースがあるでしょうか。
#1 初期設定する
#2 湯温や水位などを設定する
#3 自動で沸かす
#4 予約する
#5 状態を見る
#6 湯温や水位などを調節する
#7 動作テストをする
興味深いのは、ワークフローのアクション状態とユースケースに重複している
ものが多いことです。ワークフローとはアクタがある目的を達成する(この場合
はお風呂に入る)ためにどんなことをするかを記述したものです。一方ユースケ
17/77
Fractal UML Modeling No.2
ースとはある目的を達成するためにシステムがアクタに提供する機能です。し
たがってアクション状態のうち、システムが直接関係しないものを除けば、ユ
ースケースとほぼ重なるのは自然なことでしょう。逆にワークフローをヒント
にしてユースケースを洗い出すことができます。
洗い出したユースケースをユースケース図に描くと次のようになります。
18/77
Fractal UML Modeling No.2
01.11. ユースケースとアクタ
ユースケースとはシステムがアクタに提供する外部機能ですから、どのユース
ケースも必ずどれかのアクタと関係があります。ユースケースの名前「XXX が
YYY を ZZZ する」で言えば、主語 XXX(場合によっては目的語 YYY)に相当す
るアクタがあるはずです。逆にアクタはシステムと関係を持つ外部要素ですか
ら、何らかのユースケースと関係があります。
ユースケースとアクタの間の関係を関連と呼んで、ユースケース図上では対応
するユースケースとアクタを実線で結びます。
19/77
Fractal UML Modeling No.2
ユースケースとアクタを結ぶ線は、システムを表す長方形と交差します。この
交点がシステムと外部とのインタフェースに相当すると考えることができます。
システムを表す長方形はシステムの外部と内部の境界を表しているわけです。
20/77
Fractal UML Modeling No.2
01.12. ユースケース・シナリオ
前にあげた原則どおり、ユースケースの静的モデリングをしたら次は動的モデ
リングです。前の動的モデリングではアクタ同士の振る舞いをアクティビティ
図を使ってモデリングしましたが、ここではアクタ(たち)とシステムの間の振
る舞いをシーケンス図を使ってモデリングします。このモデリングのことをユ
ースケース・シナリオと呼びます。
ユースケース・シナリオとはその名前のとおり、ユースケースがどう振る舞う
かを記述した脚本です。この脚本の登場人物はシステムとアクタ(たち)です。
通常はユースケースごとに正常の場合、例外の場合、エラーの場合など複数の
ユースケース・シナリオを考えます。
別の言い方をすると、ユースケース・シナリオを集めたものがユースケースで
あると考えることもできます。
たとえばユースケース#1 「初期設定する」のユースケース・シナリオは次の
ようになるでしょう。
1. 外部ユーザが浴室制御システムの時刻を設定する
2. 外部ユーザがその他の既定値を設定する(工場出荷時の設定でよければその
まま)
UML ではユースケース・シナリオをシーケンス図を使って表します。
21/77
Fractal UML Modeling No.2
01.13. シーケンス図
シーケンス図はオブジェクト間のメッセージ交換の様子を表すのに使われるダ
イアグラムです。アクティビティ図に似ている面もありますが、アクティビテ
ィ図に較べるとオブジェクト間の相互作用の表現に重点を置いています。
シーケンス図の上部には、シーケンス図に登場するオブジェクトを長方形で描
きます。長方形の中にはそのオブジェクトの名前を":"に続いて書き、下線を引
きます。この":"や下線の意味については後で述べます。
オブジェクトを表す長方形から下に延びている線を生命線と呼び、上から下へ
の時間の流れを表しています。残念ながら今のバージョンの UML では時間間
隔や絶対時間を表すよい方法は用意されていません。必要ならばノートに書い
て図に貼り込んでおきます。
あるオブジェクトと別のオブジェクトの間にメッセージ交換がある場合には、
それぞれの生命線の間に実線矢印を引き、交換されるメッセージの内容を実線
の上に書きます。
ここではオブジェクトとメッセージという用語を使っていますが、ユースケー
ス・シナリオを描く場合にはアクタやシステムとその間の相互作用というよう
に置き換えて考えも構いません。このように UML では同じ図でもその使い方
に応じて意味を柔軟に考えることがよくあります。
すでにアクタが定義されている場合には、ツリー・ビューからそのアクタをシ
ーケンス図上にドラッグ&ドロップするだけで、そのアクタに対応するオブジ
ェクトが作られます。これは UML ツールを使っている場合の強力なポイント
の一つです。
22/77
Fractal UML Modeling No.2
01.14. ユースケース・シナリオを描いてみる
前に考えた「初期設定する」ユースケースのユースケース・シナリオをシーケ
ンス図を使って描いてみましょう。
シーケンス図上でアクタとユースケースとの間に矢印が引かれているというこ
とは、ユースケース図上でアクタとユースケースの間に関連を示す実線が引か
れているということに対応しています。
そのほかのユースケース・シナリオについても考えてみましょう。
(湯温や水位などを設定する)
23/77
Fractal UML Modeling No.2
(自動で沸かす)
24/77
Fractal UML Modeling No.2
(自動で沸かす - 中断)
25/77
Fractal UML Modeling No.2
ユースケース・シナリオはあまり精緻に考えすぎないようにしてください。シ
ーケンス図はそれほど表現力が高くありませんし、ユースケース・シナリオは
実際には無数にあり得る場合が多いからです。ユースケース・シナリオを描く
理由はすべての場合を尽くすためではなく、いくつかの典型的な例についてシ
ミュレーションを行い、ユースケースをより具体的にすることにあります。
26/77
Fractal UML Modeling No.2
予約するなど、残りのユースケースについても、シーケンス図を使ってユース
ケース・シナリオを描いてみてください。
27/77
Fractal UML Modeling No.2
01.15. ユースケースの事前条件/事後条件
ユースケースに対してユースケース・シナリオを考えることによって、ユース
ケースをより具体的に考えることができるようになりました。しかし、ユース
ケース・シナリオが与えてくれる情報は「こういう場合もある」「ああいう場
合もある」ということにしかすぎません。モデリングも進んでくればもう少し
正確な情報が必要になってきます。
言葉を換えると、ユースケース・シナリオはユースケースを外延的に定義する
ものですから、それに対してユースケースを内包的に定義する方法が必要にな
ります。そのために「そのユースケースはどういう条件がそろったときに起動
されるか」「そのユースケースが終了したときにはどういう条件が満たされる
はずか」を考えます。
「そのユースケースはどういう条件がそろったときに起動されるか」を事前条
件(pre-condition、前置条件ともいう)、「そのユースケースが終了したときには
どういう条件が満たされるはずか」を事後条件(post-condition、後置条件ともい
う)と呼びます。
事前条件/事後条件を記述する方法はいくつかあります。
o 自然言語を使って記述する
o (擬似)プログラミング言語を使って記述する
o 論理式を使って記述する
この段階では自然言語を使って記述するのがもっとも適当でしょう。(擬似)プ
ログラミング言語を使って記述すれば、後で実際に実行してチェックすること
が比較的簡単にできます。ただし多くのプログラミング言語は副作用を持った
り、ロジックの表現に不向きです。論理式を使って記述するのがいちばん正確
です。UML ではオブジェクト制約言語(OCL)が定義されていますが、まだ成熟
した段階には至っておらず、これをサポートするツールも多くありません。
28/77
Fractal UML Modeling No.2
たとえば「自動で沸かす」ユースケースの事前条件/事後条件を考えてみましょ
う。自動を開始できるのは沸かしている途中でないと考えれば、事前条件は
pre: 沸かしている途中ではない
になります。
一方自動が終了した時点ではどうなっているべきかを考えれば、事後条件は
post: 浴槽が設定したとおりの湯温、水位になっている
となります。
ダイアグラム上に書く場合には、pre:, post:などから始まるノートを付けておけ
ばいいでしょう。
29/77
Fractal UML Modeling No.2
01.16. 状態
さて、事前条件/事後条件を考えているときに「沸かしている途中ではない」と
か「保温中である」のような条件が出てきました。これは浴室制御システムが
取りうる状態を表しています。浴室制御システムが取りうる状態には他にどの
ようなものがあるのでしょうか。
o 初期状態 (設置直後、あるいはリセット後)
o 時刻設定済み
o 運転待ち
o 湯沸かし中
o 保温中
o 予約済み
o 自己点検中
これらはワークフローやユースケース・シナリオ、事前条件/事後条件などを参
考にシステムにとって重要と考えられる状態を抜き出したものです。UML で
は状態を表すのに状態チャート図を使います。状態は角の丸い長方形で表しま
す。状態の名前には「...中」、「...待ち」、「...状態」のような状態を表す名前を選
びます。
浴室制御システムが持つ状態を状態チャート図に描いてみましょう。
30/77
Fractal UML Modeling No.2
31/77
Fractal UML Modeling No.2
01.17. ライフサイクル
さっきは浴室制御システムが持つ状態について考えました。浴室制御システム
はこれらの状態を渡り歩くことになります。システムにどのような状態がある
のか、状態から別の状態にどういう条件で遷移するのかをまとめたものをシス
テムのライフサイクルと呼びます。いわばシステムの一生です。
システムは何らかのイベントを受け取ると、ある状態から別の状態に変化しま
す。これを状態遷移と呼びます。イベントの種類としては、
o シグナルやメッセージ (シグナルやメッセージを受け取った)
o 時間 (一定時間が経過した)
o 変化 (システムの何かが変化した)
などがあります。
状態遷移を先ほど状態を描いた状態チャート図に描き重ねてみましょう。
特に今はユースケース・ビューでのライフサイクルを考えていますから、外か
ら見えるシステムの状態とその間の遷移ということになります。したがってこ
こではユースケースをイベントとして考えることができます。たとえば「運転
待ち状態にあるときにユースケース 03 が起動されたらシステムは湯沸かし中
状態に遷移する」ということになります。逆に「自動で沸かす」ユースケース
はシステムを運転待ち状態から湯沸かし中状態に遷移させるものと考えること
もできます。
32/77
Fractal UML Modeling No.2
33/77
Fractal UML Modeling No.2
01.18. 概念ビュー
さて今まではユースケース・ビューといって、システムを外側の視点から眺め
てきました。いつまでもこのままでは実際に動くシステムを作ることはできま
せん。そろそろ視点をシステムの内側に移していきます。
システムを内側から見るためにはいくつかの視点が考えられますが、最初にシ
ステムの概念的にとらえる視点から見てみます。これを概念ビューと呼びます。
これはユースケース・ビューと整合性を保ったまま、システムをいくつかのコ
ンポーネントに分割する見方です。
ここでのコンポーネントは、できるだけ概念的なものとします。つまり現実の
世界をシミュレートするのに便利なような概念や存在をオブジェクトとして扱
います。システムを実装するために必要とされるような裏方的なオブジェクト
はこの段階では考えません。
34/77
Fractal UML Modeling No.2
01.19. 概念オブジェクト
前にあげたような基準で浴室制御システムがどのようなオブジェクトで成り立
っているか、考えてみましょう。このときに考える一つの枠組みとして、また
ユースケース・ビューから概念ビューへの移行の契機として、ユースケースご
とに考えます。
まず「初期設定する」ユースケースに関わる概念はなんでしょうか。初期設定
するのは現在時刻と、湯温、水位などの既定値です。ですからここでは現在時
刻を表す「現在」と既定値を表す「既定値」という二つの概念オブジェクトを
抽出します。
そのほかのユースケースについても同様に概念オブジェクトを抽出してみまし
ょう。抽出した概念オブジェクトを、ユースケースを描いたユースケース図に
重ねて描いて見てください。オブジェクトを表すのは長方形です。関連のある
ユースケースと概念オブジェクトの間には実線を引きます。
35/77
Fractal UML Modeling No.2
ユースケース・ビューでは、多少の見方の違いは出てきますが大きなところで
はだいたい同じようなビューを作ることができます。しかし概念ビューでは人
によって大きく見方が変わってくる場合が出てきます。これはマニュアル的に
どうするのがいいと教えられるよりは、経験を積み重ねて感覚をつかんだ方が
いいと思います。
36/77
Fractal UML Modeling No.2
01.20. コラボレーション
我々が作ろうとしている浴室制御システムは概念的には前に挙げたようなオブ
ジェクトが協調動作することによって成り立っているシステムであることが分
かってきました。このオブジェクトの間の協調動作のことをコラボレーション
と呼びます。ここでコラボレーションの中身、つまり実際にどのように動作し
ているのかを確かめる必要があります。
コラボレーションは基本的にはユースケースに対して考えたユースケース・シ
ナリオと同じです。大きく違うのは登場人物です。コラボレーションの主要な
登場人物は概念オブジェクトですが、コラボレーションのトリガーとしてアク
タが、またトリガーの受け取り口としてシステムが登場します。そしてコラボ
レーションもユースケースごとに考えるのがよいでしょう。
つまり、コラボレーションはユースケース・シナリオをさらに右(システムの背
後)に拡張し、下(メッセージ交換)に詳細化したものということになります。
コラボレーションはユースケース・シナリオと同様、UML ではシーケンス図
を使って描きます。ユースケースと概念オブジェクトを元にコラボレーション
を描いてみましょう。
(初期設定する)
37/77
Fractal UML Modeling No.2
(湯温や水位などを設定する)
38/77
Fractal UML Modeling No.2
(自動運転する)
39/77
Fractal UML Modeling No.2
(予約する)
40/77
Fractal UML Modeling No.2
41/77
Fractal UML Modeling No.2
01.21. 概念オブジェクトの詳細化
コラボレーションを元にして、概念オブジェクトを詳細化していきます。
概念オブジェクトは基本的に通常のクラスと同じですから、固有の属性(変数)
と操作(メソッド)を持っています。属性はそのクラスが持つ情報です。普通の
オブジェクト指向プログラミング言語でプログラミングをする場合には、型な
ど詳細を詰める必要がありますが、この段階のモデリングではそれは必要あり
ません。そのクラスにとって本質的にどのような情報が必要かだけに集中しま
す。
操作はそのクラスが受け付けるメッセージです。つまりそのクラスにとってど
のような操作ができなければならないかを表しています。操作を洗い出すため
には、前に考えたコラボレーションが役に立ちます。基本的には各概念オブジ
ェクトが受け取ったメッセージに対応する操作が必要になることになります。
たとえば「現在」という現在時刻を表す概念オブジェクトには属性として時刻
が必要です。また時刻を設定する操作「設定する」が必要になります。
UML ではクラスはクラス図に三つの区画を持った長方形として記述します。
いちばん上の区画にはクラス名を、次の区画にはクラスが持つ属性を、一番下
の区画にはクラスが持つ操作を書きます。
42/77
Fractal UML Modeling No.2
43/77
Fractal UML Modeling No.2
01.22. ライフサイクル
ユースケース・ビューでもシステムのライフサイクルを考えました。概念ビュ
ーでもシステムのライフサイクルを考えます。基本的な考え方はどちらの場合
も同じですが、概念ビューでのライフサイクルは、ユースケース・ビューでの
ライフサイクルに較べて以下の点が異なっています。
o より詳細である
o システムの内部状態についてもモデリングする
o アクションをモデリングする
最後の点については後で述べます。
概念ビューでのライフサイクルも、ユースケース・ビューでのライフサイクル
を出発点として考えればよいでしょう。そして前に考えた状態の中でさらに複
数の状態と状態遷移に分割して考えることができるものを見つけて、それを別
の状態チャート図を使ってモデリングします。
(初期設定する)
44/77
Fractal UML Modeling No.2
(運転中)
45/77
Fractal UML Modeling No.2
(保温中状態)
(非平衡状態)
46/77
Fractal UML Modeling No.2
47/77
Fractal UML Modeling No.2
01.23. アクション
今までモデリングしてきた状態チャート図では状態とイベントと状態遷移だけ
を考えてきました。しかし、状態チャート図にはもっと重要な情報を記述する
ことができます。それがアクションです。
アクションとは、非常におおざっぱに考えれば通常のプログラミング言語のプ
ログラムの断片と思えばいいでしょう。もう少し正確に言うとモデルの状態を
変える行為のことです。ここでモデルの状態を変えるとは、オブジェクトを生
成/消去したり、オブジェクトの属性の値を変えたり、オブジェクトの間にリン
クを張ったり、オブジェクトの操作を呼び出しすることを指します。
UML で定義されている状態チャート図では、以下のような場合に実行される
アクションを定義することができます。
o イベントを受け取ってある状態から別の状態に遷移するとき (遷移アクショ
ン)
o ある状態に入ってきたとき (入場アクション)
o ある状態から出て行くとき (退場アクション)
o ある状態にいる間 (実行アクション)
o ある状態にいるままイベントを受け取ったとき (内部遷移アクション)
アクションは通常イベントやラベル名(enter, exit など)の後ろに"/"で区切って書
きます。アクションを具体的にどう書くかは現在の UML では規定されていま
せん。アクションの具体的な書き方を定めたものをアクション言語と呼びます
が、UML で規定されている意味論さえ満たせば、その文法はツールやユーザ
ごとに違っていても構わないことになっています。
したがって既存のオブジェクト指向プログラミング言語を再利用することも全
く新しいモデリング専用のアクション言語を設計することもできます。前に紹
介した OCL はロジックだけを記述するための副作用を持たない言語ですから、
アクション言語とはかなり異なっています。ただし、現状では OCL とアクシ
ョン言語を融合した新しいモデリング言語を作る試みもあるようです。
48/77
Fractal UML Modeling No.2
このように将来的には標準的なアクション言語が出てくる可能性もありますが、
今回は簡単な擬似的な言語を使いましょう。先ほど書いた概念ビューでのシス
テムのライフサイクルにアクションを追加していきます。具体的なアクション
の対象として先に定義した概念オブジェクト群を利用します。
(初期設定する)
(運転中状態)
49/77
Fractal UML Modeling No.2
(保温中状態)
(非平衡状態)
50/77
Fractal UML Modeling No.2
51/77
Fractal UML Modeling No.2
01.24. 事前条件/事後条件
同じようにして、前に描いたユースケースの事前条件/事後条件も概念オブジェ
クトを用いてもう少し詳細に記述しておくことにしましょう。
前に書いたものがどう書き換えられているか、見てください。
52/77
Fractal UML Modeling No.2
01.25. シミュレーションと検証
このようにして描いてきたモデルは、適当なツールかある程度の時間があれば
実際に動かしてみることができます。もちろんまだハードウェアはつながって
いませんが、ソフトウェアとしてシミュレートしてみることができます。この
ように早期の段階で実際に動かすことによって検証してみることができるのは、
モデリングの大きな利点の一つです。
単にきれいなドキュメントを作るだけならばモデリングにコストをかける必要
性は全くありません。何らかのコストをかけて作ったものならば、それが妥当
なものかどうかが検証できなければ意味がないのです。従来のソフトウェア開
発で作成されてきたドキュメントはほとんど自然言語で書かれており、論理的
な検証や実際に動作させてみての検証は不可能でした。その代わりに何度もレ
ビューを繰り返したのですが、レビューはコストの割に効率がよくありません。
またいくら「正しい」ドキュメントが作られたとしてもそれは製品には何ら直
接的な関係はありませんでした。
モデリングをする、ということは単に流行のプラクティスであるというだけで
はなく、上に挙げたようなドキュメントにはない強力な利点があってこそ意味
があることを理解して欲しいと思います。
53/77
Fractal UML Modeling No.2
01.26. 次のステップ
モデリングの最初のステップも終わりに近付いてきました。ここまでは我々が
作ろうとしている浴室制御システムを外からの視点(ユースケース・ビュー)と
概念的な視点(概念ビュー)に立って見てきました。
ここまではどのようなハードウェアを使うのかとか、どのようなユーザ・イン
タフェースにするのかという話はいっさい出ていません。その代わりにお風呂
を沸かすということはどういうことかということを中心にモデリングしてきま
した。この部分がシステムを作る際に最も重要になり、普遍性も不変性も高い
からです。それに較べるとハードウェアやユーザ・インタフェースは変わりや
すいですし、後からどんどん機能が追加されていくかもしれません。そのよう
な場合でも中心となる部分さえしっかりモデリングされていれば、変更や機能
追加のコストは最小限に抑えることができます。
これからは次のようステップを踏んでモデリングを進めていきます。
o システムをいくつかの部分(パッケージといいます)に分ける
o それぞれごとに今までやってきたようなモデリングを繰り返す
o 必要ならば上のパッケージに戻ったり、横のパッケージを合わせてリファク
タリングする
これを繰り返して十分実行可能で妥当性の高いモデルが完成したときがシステ
ムが完成したときです。
そのために、今は浴室制御システムをいくつかのパッケージに分割してみまし
ょう。
54/77
Fractal UML Modeling No.2
01.27. パッケージ
システムをパッケージに分割する、ということはシステムのアーキテクチャを
考えるということに相当します。したがって、どのようにパッケージ分割する
かはシステムに与えられた主に非機能的な要件(品質や性能)に依存します。し
かし一般的にいえば、アーキテクチャとしては依存度が低く、凝集度が低いと
いうことが重要になります。
依存度とはパッケージの間の依存関係で、凝集度とはパッケージ内の一貫性の
ことです。「外に対して開かれており、中に対して閉じている」(オープン=クロ
ーズ原則)とも言われます。要はできるだけパッケージが依存し合わないような
アーキテクチャを作ることによって、システムの柔軟性や拡張可能性、保守性
を高めることができます。
今回は制御系のシステムでよく使われているアーキテクチャをベースにするこ
とにしましょう。
UML ではパッケージはフォルダのようなアイコンを使って描きます。依存関
係のあるパッケージの間には依存関係を表す点線矢印を引きます。パッケージ
A からパッケージ B に点線矢印が引かれているということは、パッケージ A が
パッケージ B を利用しているということとほぼ同じです。
55/77
Fractal UML Modeling No.2
これまでにモデリングしてきたのは、浴室制御システムというパッケージに相
当することになります。これから他のパッケージのモデリングを進めることに
よって、実際に動作するシステムに変換していくのが我々の作業過程です。
56/77
Fractal UML Modeling No.2
Part II. 外部コントローラ
02.01. 外部コントローラ
ここではいくつかあるパッケージのうちから、外部コントローラをモデリング
する過程を追いかけてみます。前のステップで見たとおり、外部コントローラ
に隣接するパッケージは次のようになっています。
57/77
Fractal UML Modeling No.2
02.02. アクタ
浴室制御システムにとってのアクタはユーザや外部システム(こちらは今回はな
し)でした。外部コントローラにとってのアクタは何になるでしょうか。ここで
はデバイスを抽象化したものをアクタと考えることにします。抽象化した、と
は個々のデバイスそのものではなく、デバイスを理想化した、ある意味でスマ
ートなデバイスを対象とするということです。実際の個々のデバイスはデバイ
スのレイヤで扱います。これによってこのレイヤでは実際の個々のデバイスの
差異にとらわれないモデリングを行うことができるのです。
さて、アクタを考える前に実際にどのようなユーザ・インタフェースにするか
をある程度決める必要があります。今回は次のようなユーザ・インタフェース
にしました。
このユーザ・インタフェース案をもとにして、抽象デバイスに相当するアクタ
をユースケース図に描いてみます。
58/77
Fractal UML Modeling No.2
ここでは抽象的なデバイスに対応するアクタの他に、ちょっと特別なアクタと
してユーザを表すアクタと浴室制御システムを表すアクタを導入しました。こ
れでデバイスの向こう側にいるユーザとの間接的な相互作用や浴室制御システ
ムとの通信もモデリングすることができます。
59/77
Fractal UML Modeling No.2
02.03. ワークフロー
ここではアクタのワークフローを考えるステップですが、外部コントローラの
主なアクタであるボタンやパネルなどの抽象デバイスにはほとんどワークフロ
ーがありませんから、ここではこのステップはパスします。
60/77
Fractal UML Modeling No.2
02.04. ユースケース
次に外部コントローラのユースケースを考えます。基本的には浴室制御システ
ムのユースケースの中からそのユーザ・インタフェースに関係するユースケー
スを抜き出し、必要ならば詳細化したものになります。
前と同じようにアクタとユースケースの関連も付けてみます。
61/77
Fractal UML Modeling No.2
62/77
Fractal UML Modeling No.2
02.05. シナリオ
個々のユースケースごとにユースケース・シナリオを描きます。だいたいのシ
ナリオはユーザのトリガに始まって、浴室制御システムへの通知で終わるよう
な感じになります。
このときに、例外や繰り返し、疑問点や問題点などは積極的にノートの形で残
しておきます。
(時刻設定)
(湯温設定)
63/77
Fractal UML Modeling No.2
(予約設定)
64/77
Fractal UML Modeling No.2
(保温時間設定)
65/77
Fractal UML Modeling No.2
(自動運転)
66/77
Fractal UML Modeling No.2
67/77
Fractal UML Modeling No.2
02.06. 事前条件/事後条件
外部コントローラのようなユーザ・インタフェースに関するパッケージでは、
機能のほとんどは副作用に依存していますから、事前条件/事後条件を定めるの
は簡単ではありません。ここでは事前条件/事後条件を考えるのは止めておきま
しょう。
68/77
Fractal UML Modeling No.2
02.07. 状態
次に外部コントローラの持つ状態を洗い出してみましょう。浴室制御システム
の持つ状態とは重なる部分もありますが、かなり違ってくると思います。それ
は前には浴室制御システムを対象にしていましたが、今回は外部コントローラ
を対象にしているからです。
69/77
Fractal UML Modeling No.2
02.08. シグナル
シグナルは状態遷移のトリガとなるイベントの一つです。制御系のシステムを
モデリングする場合、デバイスに近い存在について次の二つのモデリング手法
が考えられます。
一つはすべてをオブジェクトとしてモデリングし、オブジェクト間の相互作用
はオブジェクトのメッセージ交換として考えるやり方です。この方法の利点は
システム全体にわたってオブジェクトという統一的な考え方で一貫したモデリ
ングができることです。ただし現在の UML では、必ずしも物理的なデバイス
をうまく扱いきれません。
もう一つの方法は、通常のオブジェクトとその間のメッセージ交換と枠組みを
離れて、デバイスとシグナルという別の枠組みを使うことです。この方法の利
点はより自然なモデリングが可能になる点です。
今回は後者の方法をとることにしましょう。今までに(抽象的な)デバイスはア
クタとしてとらえられています。シグナルは外部コントローラからデバイスに
対して送ったり、外部コントローラがデバイスから受け取る情報です。具体的
にどういうフォーマットでどういうタイミングでやりとりされるかは、より低
レベルのパッケージで定義します。
外部コントローラと情報のやりとりを行うパッケージは主に
o 浴室制御システム
o UI デバイス
です。
ユーザが外部コントローラに設定した情報は浴室制御システムにシグナルとし
て送られ、逆に他のコントローラの設定や浴室制御システム自体の状況を表す
情報は外部コントローラが受け取ります。また外部コントローラから UI デバ
イスのうち、表示パネルなどに対してはシグナルを送り、UI デバイスのうち、
ボタンなどからはシグナルを受け取ります。
70/77
Fractal UML Modeling No.2
シグナルは UML では一種の特殊なクラスとして記述します。UML では一般的
に特殊なモデル要素を表すためにステレオタイプを用います。シグナルもクラ
スに対するステレオタイプの一つです。表記上は"<<", ">>"内にステレオタイプ
名を書くことで明示します。シグナルの場合には<<signal>>のように書けばい
いでしょう。
シグナルがクラスとして特殊であるのは次のような点です。
o 操作を持たない
o 基本的にシグナルを運ぶ以外の役には使えない
外部コントローラと浴室制御システムの間で送られるシグナルは以下のような
ものです。他のコントローラからの制御や浴室制御システムの状態を反映させ
る必要があるので、ほとんどのシグナルは双方向でやりとりされます。
71/77
Fractal UML Modeling No.2
一方、UI デバイス・レイヤにある抽象デバイスとの間でやりとりされるシグナ
ルは以下のようになります。
72/77
Fractal UML Modeling No.2
02.09. ライフサイクル
さて、ここで今まで考えてきた
o 状態
o シグナル
を元に、状態チャート図を使って外部コントローラのライフサイクルを考えま
す。同時にアクションも前回同様に考えていきます。
アクションを考えていくと、さまざまな情報を保持しておく必要が出てきます。
その時点でそれらを外部コントローラの概念オブジェクトとしてモデリングし
ていきましょう。制御系のシステムでも、もっとデータが中心において考える
必要がある場合もあります。そのような場合には、より早い段階で概念オブジ
ェクトを抽出します。外部コントローラでは情報はそれほど中心的な役割を果
たしませんから、今回はライフサイクルから考えています。
73/77
Fractal UML Modeling No.2
(運転中状態)
(時刻合わせ中)
74/77
Fractal UML Modeling No.2
(予約設定中)
(保温時間設定中)
75/77
Fractal UML Modeling No.2
76/77
Fractal UML Modeling No.2
02.10. 次のステップ
ここまでで、外部コントローラのモデリングはほぼ終了です。ここまでくれば
先ほどと同じように少なくともソフトウェアのレベルでユーザ・インタフェー
スのシミュレーションを行い、モデルを検証することができるようになります。
次にはもし物理デバイスの仕様が決まれば、この下のパッケージである UI デ
バイス・パッケージをモデリングすることになります。場合によってはこのパ
ッケージでは UML でモデリングするのではなく、皆さんがいつもやっている
ように直接プログラミング言語を使ってプログラミングしてしまうこともあり
ます。I/O アドレスへのアクセスや割り込みの制御、タイミングの制御などが
この段階で行われることになります。逆に言うとそのような物理レベルの処理
はすべてこのパッケージに押し込んでしまうことによって、汎用性と柔軟性を
高めるようなパッケージ分割を行っているわけです。
もし必要ならばさらにこのパッケージを複数のパッケージに分割して、同様の
モデリングを繰り返していきます。また、浴室制御システムのパッケージに戻
って、外部コントローラのパッケージの成果を組み入れます。
77/77