会話の背景：
システムモデリングには、静的なモデリングと動的なモデリングがある。静的なモデリングがある。静的なモデリングがクラスに重点を置くというなら、動的なモデリングはオブジェクトに注目している。今回と次回は動的あるいはダイナミック的なモデリングについて話す。動的なモデリングはいくつかあるが、よく使われているのは、シーケンス図と状態図である。どちらでも静的なクラスに基づいて設計する。シーケンス図の特徴は、オブジェクト間（かん）の相互動作を時系列で表現することである。
登場人物：
近藤― SA
鈴木― PL
山田、田中― PG
会話：
鈴木：こんばんは。
先々週からはクラス図を書いてきました。これは静的なモデリングと言われます。今週からは動的なモデリングをします。作業としては、シーケンス図と状態図を書く予定です。今日は、まず、シーケンス図に関して、近藤さんに説明してもらいましょう。近藤さん、お願いします。
近藤：そうですね。ここまで書いてもらったクラス図では、主にオブジェクトのテンプレートとなるクラスの名前、属性、および操作を定義し、その上各クラスの関係付けも記述しておきます。それに対して、システムが実行するときに、システムの制御の流れがどうなるか？各オブジェクトがどう動くか？お互いにどう交信（こうしん）しながら機能を果たすか？また各オブジェクトが自分のライフサイクルでどう変化するか？などを記述することを動的なモデリングと言います。
田中：すみませんけど、動的なモデリングって、具体的に言うと、いくつかの種類がありますか？それぞれの特徴および適応性はどうでしょうか？
近藤：そうですね。いろいろありますが、よく使われてるのは、コラボレーション図（collaboration diagram)、シーケンス図（sequence diagram)、状態図（state diagram）、それとアクティビティ図（activity diagram)があります。
コラボレーション図は各オブジェクトがイベントにより交信することを重視したもので、時間には関係なさそうな振る舞いを表現するにはいいと思います。
それに対して、シーケンス図は関係オブジェクト間の時間序列（じょれつ）により交信することを表現するので、時系列にかかわる機能には表現しやすいです。
田中：もしかしたら、アクティビティ図と状態図もオブジェクト間の振る舞いを表現するのでしょうか。
近藤：それらはちょっと違いがあります。
アクティビティ図はシステムの制御の流れは表示しやすいと思います。むかのフローチャートやデータフロー図から変身してきたと思います。ここでは流れの主体はオブジェクトになっています。状態図はオブジェクト間の関係ではなく、ある特定のオブジェクトに対して、そのライフサイクルの中で状態の変化を表現します。もちろん、その状態の変化とともに、イベントが発生しますから、それも一緒に記述します。
田中：なるほど。大体わかりました。われわれも今回の四種類の図を書かなければなりませんか？
鈴木：本来はそうすべきですが、しかしプロジェクトによりお客様の要求次第でまちまちですから。今回はとにかくシーケンス図と状態図だけを書けばいいことになりました。
田中：そうですか。そうしたら、シーケンス図に関して今回の作業ではどう書けばいいでしょうか。
近藤：この前も言いましたが、シーケンス図にはハイレベルとローレベルの書き方があります。今回の開発はこのシステムがそんなに大きくないので、ローレベルの書き方を薦めたいです。
田中：ローレベルの書き方って、どんな意味でしょうか？
近藤：ローレベルの書き方とは、コーディングと緊密に関係した方法です。具体的にいうと、ここまで設計したクラスとこれから書こうとするJSPやJavaの名称や操作などを直接使いながら書きます。たとえば、お客さんが見積記入という振る舞いを記述して見ると、NewQuotationJSP,NewQuotationAction,Quotation,Approvalなどのクラスがある。その場合、これらのクラスのオブジェクトあいだの交信を時系列で書けばいいと思います。具体的には、サンプルも書いておきますから、参考にしてください。
田中：どうもありがとうございます。
山田：それと、シーケンス図に対して何か特徴や注意点などがあるでしょうか？
近藤：そうですね。まずは、今われわれはローレベルで書いていますので、大抵（たいてい）一つのセッションには一つのシーケンス図があります。そうすると、シーケンス図を読むと、コーディングがすぐできるような状態になります。逆にいうと、コーディングがあれば、シーケンス図により、検証することもできます。
山田：それは大変助かります。
近藤：それと、シーケンス図には、細かくいうと、オブジェクト間でメッセージ通信するときに、条件をつけることがよくありますから、条件を書いたほうがいいとおもいます。
二番目は、関係したオブジェクトが流れのあいだに生成されたり（new,create)、消滅されたり(destroy,delete)、自己交信する（self)こともよくありますので、UMLの記号を正しく使ってちゃんと表示してほしいです。
山田：ところで、シーケンス図が、並列プロセスも表現できるでしょうか？
近藤：もちろんです。シーケンス図で並列プロセスを表示するため、頭が半分しかない矢印を使って非同期メッセージを送信するように表現できます。
一般的にいうと、シーケンス図では、あるオブジェクトが相手のオブジェクトに送信し、相手のオブジェクトが処理を終えた後、次の操作へ進む。これにより、時系列を守ります。図を書くときには、こんな送信は普通の矢印を使います。
しかし、並列プロセスあるいは非同期の場合は、非同期メッセージを送信した後、呼び出し側をブロックしませんので、自身の処理を継続して実行できます。というのは受信側オブジェクトの処理完了を待たずに、すぐ次の動作を続けます。
山田：わかりました。
鈴木：それでは、具体的にはまだいろいろがあると思いますが、書きながらまた議論してきただければ勉強になると思います。今日のミーティングはここまで終わらせてもらいます。皆明日から早速書いてもらいましょう。
もう遅くなりましたので、近藤さん、皆さん、お疲れ様でした。
皆：お疲れ様。
１２．状態図を書く
会話の背景：
前回はシーケンス図の書き方などを話した。動的なモデリングをするため、シーケンス図とともに、多くの場合、状態図も書く。
シーケンス図にはほとんどのクラスが登場するが、状態図は一部のクラスの処理が状態に依存して複雑な処理になる場合のみ、必要なるいは有効である。それ以外の場合は必ずしも書く必要はない。
登場人物：
近藤― システムアーキテクト
鈴木― PL
山田、田中― PG
会話：
鈴木：おはようございます。
このところ、シーケンス図を書くたびに、その中の一部のオブジェクトに対して状態変化に関する議論がたびたび出てきました。今日は時間を取って、これらの状態変化について、UMLの状態図をどうやって取り込むかを議論してほしいです。
山田：そうですね。
われわれは先日、問い合わせ記入、商社への見積、顧客注文、販売店への注文、納品管理などのシーケンス図を書きました。ただし、書いているうちに、いくつかのシーケンス図間（かん）の関連情報をどう反映するか、迷っていました。
例えば、顧客注文を照会するときには、ここまでの見積状況や、販売店からの返事などをひきださなければなりませんから、なにかよい方法がないかなと感じました。
近藤：なるほど。それこそ、確かにわれわれはこの車両販売管理システム中の取引というオブジェクトに注目しなければなりません。ここで、取引とは、最初の顧客の問い合わせの記録だけではなく、見積や注文、納品、最後の会計まで、状態が変わっていくように表現しなければなりません。これを状態図で分析設計すれば、問題が解決できると思います。
山田：そうですか。ということは、取引オブジェクトに、問い合わせ中、見積中、販売店注文中、納品済み、請求済みなどの状態を取り込めば、いいわけでしょうか？
近藤：どうです。
一つの取引は、最初の問い合わせから、最後の納品また会計までの状態遷移により、販売のビジネスを進めていくことを記述できます。
また、各状態に対して、状態遷移の条件やイベントがあり、特定の条件を満たせば、または、あるイベント発生したら、状態Aから状態Bへ遷移します。また状態遷移の後はほとんどの場合アクションが発生します。
田中：すみませんけど、状態遷移の条件と状態遷移あとのアクションと言われましたが、もつちょっと詳しく説明していただけるでしょうか？
近藤：はい。先の取引の例をとってみてみましょう。
ある特定の取引に対し、顧客が注文を確認したあとに、システムが特定の条件を確認したうえで販売店へ正式注文します。そうすると、取引は注文中という状態を持っています。この状態を変更すると、こちらのシステムが販売店に注文することになります。
その場合は、この状態遷移の条件としては、確かに顧客の確認だけではなく、たとえば代金の30％がこのシステムにはいらないといけないことは、状態遷移の条件ともかんがえられます。
また、一旦この頭金の条件を満たすと、システムとしては、直ちに特定の販売店に注文するアクションが発生しなければなりません。それは、今回顧客注文の状態遷移のアクションともいえますね。
田中：それを聞いたら、わかってくるようですが、取引にはいくつかの状態があります。しかし、もし細かく考えると、注文という状態の中にも入れ子の状態があるようですけど。
近藤：その通りです。オブジェクトの状態は階層化することができますから、言い換えると、ある状態のなかで、また入れ子状態を持つことがよく発生します。これらの階層化された状態をUMLで記述することもできます。
入れ子状態だけではなく、並列状態もあります。ようするに、状態とは、単独的なものだけではなく、並列した状態を同時に処理することもたびたび発生します。そのときは、二つの状態の「And」また「Or」の論理演算により、次の状態へ遷移するかどうかが決まるわけです。
例えば、ローンで自動車を買うときに、顧客からの頭金により注文状態と、信販会社からの審査結果状態は両方がOKだったら、次の販売店注文状態へ行きます（これは「AND]論理）。ところが、その二つ状態のいずれも成り立たないと、結局、拒否される状態へ遷移します（これは「OR」論理）。
山田:それはわかりやすい例ですね。
ところで、今回の車両販売管理システムでは、どんなオブジェクトの状態を記述する必要があるでしょうか？
鈴木：一般的にいうと、一つのシステムには状態を持つオブジェクトはほんの一部しかないので、例えば、われわれの今回のシステムにはおそらく取引オブジェクトと注文オブジェクトには状態があると思います。
具体的には、皆に考えてもらいます。大抵状態が必要とするオブジェクトは特定の属性をもち、これたの属性の変化範囲は有限ですが、さらに離散的な値に限定されていることが多いです。
近藤：そうですね。
要求定義により、一部オブジェクトが持っている属性が連続値になっているが、値として状態を持つこともあります。そのときには、連続値を区間で区切った仮想的な離散地へ変換することが必要だと思います。
山田：そうですか。よく説明していただき、どうもありがとうございました。
鈴木：それなら、そのあとは実践ですね。皆さんにシステムの要求を考察してもらい、状態のあるオブジェクトを洗い出して、その状態を記述してもらいます。皆さん、よろしくお願いします。
皆：それでは、失礼します。
没有评论:
发表评论