会話による ソフトウェア工学の開発実践12 - 状態図を書く

単語

ポイント

• 議論が度々出てきました。 → 经常出现争论。

• 迷っていました。 → 我困惑了。

• わかってくるようです。 → 好像明白了。

会話

会話の背景

• 前回はシーケンス図の書き方などを話した。動的なモデリングをするため、シーケンス図とともに、多くの場合、状態図も書く。
• シーケンス図にはほとんどのクラスが登場するが、状態図は一部のカラスの処理が状態に依存して複雑な処理になる場合のみ、必要あるいは有効である。それ以外の場合は必ずしも書く必要はない。

登場人物

• 近藤：システムアーキテクト
  鈴木：開発チームリーダー
  山田、田中：開発チームメンバー

会話内容

• 鈴木：

  • おはようございます。
  • このところ、シーケンス図を書くたびに、その中の一部のオブジェクトに対して状態変化に関する議論が度々出てきました。今日は時間を取って、これらの状態変化について、UMLの状態図をどうやって取り込むかを議論してほしいてス。

• 山田：

  • そうですね。
  • 我々は先日、問合せ記入、商社への見積もり、顧客の注文、販売店への注文、納品管理などのシーケンス図を書きました。ただし、書いているうちに、いくつかのシーケンス図間の関連情報をどう反映するか、迷っていました。
  • たとえば、顧客注文を照会するときには、ここまでの見積もり状況や、販売店からの返事などを引き出さなければなりませんから、何かよい方法がないかなと感じました。

• 近藤：

  • なるほど。
  • それこそ、確かに我々はこの車両販売管理システム中の取引というオブジェクトに注目しなければなりません。ここで、取引とは、最初の顧客の問合せの記録だけではなく、見積や、注文、納品、最後の会計まで、状態が変わっていくように表現しなければなりません。これを状態図で分析設計すれば、問題が解決できると思います。

• 山田：

  • そうですか。ということは、取引オブジェクトに、問合せ中、見積中、販売店注文中、納品済み、請求済みなどの状態を取り込めば、いいわけでしょうか？

• 近藤：

  • そうです。
  • 1つの取引は、最初の問合せから、最後の納品また会計までの状態遷移により、販売のビジネスを進めていくことを記述できます。
  • また、各状態に対して、状態遷移の条件やイベントがあり、特定の条件を満たせば、または、あるイベント発生したら、状態Aから状態Bへ遷移します。また状態遷移のあとはほとんどの場合アクションが発生します。

• 田中：

  • すみませんけど、状態遷移の条件と状態遷移あとのアクションと言われましたが、もうちょっと詳しく説明していただけるでしょうか？

• 近藤：

  • はい。先の取引の例を取ってみてみましょう。
  • ある特定の取引に対し、顧客が注文を確認した後に、システムが特定の条件を確認したうえで販売店へ正式注文します。そうすると、取引は注文中という状態を持っています。この状態を変更すると、こちらのシステムが販売店に注文することになります。
  • この場合は、この状態遷移の条件としては、確かに顧客の確認だけではなく、例えば代金の30%がこのシステムに入らないといけないことは、状態遷移の条件とも考えられます。
  • また、一旦この頭金の条件を満たすと、システムとしては、直ちに特定の販売店に注文するアクションが発生しなければなりません。それは、今回顧客注文の状態遷移のアクションとも言えますね。

• 田中：

  • それを聞いたら、分かってくるようですが、取引にはいくつかの状態があります。しかし、もし細かく考えると、注文という状態の中にも入れ子の状態があるようですけど。

• 近藤：

  • その通りです。オブジェクトの状態は階層化することができますから、言い換えると、ある状態の中で、また入れ子状態を持つことがよく発生します。これらの階層化された状態をUMLで記述することもできます。
  • 入れ子状態だけではなく、並列状態もあります。ようするに、状態とは、単独的なものだけではなく、並列した状態を同時に処理することもたびたび発生します。そのときは、2つの状態の「AND」また「OR」の論理演算により、次の状態へ遷移するかどうかが決まるわけです。
  • たとえば、ローンで自動車を買う時に、顧客からの頭金により注文状態と、信販会社からの審査結果状態は両方がOKだったら、次の販売店注文状態へ行きます（これは「AND」論理）。ところが、その2つ状態のいずれも成り立たないと、結局、拒否される状態へ遷移します（これは「OR」論理）。

• 山田：

  • それは分かりやすい例ですね。
  • ところで、今回の車両販売管理システムでは、どんなオブジェクトの状態を記述する必要があるでしょうか？

• 鈴木：

  • 一般的に言うと、1つのシステムには状態を持つオブジェクトはほんの一部しかないので、例えば、我々の今回のシステムにはおそらく取引オブジェクトと注文オブジェクトには状態があると思います。
  • 具体的には、皆に考えてもらいます。大抵状態が必要とするオブジェクトは特定の属性を持ち、これらの属性の変化範囲は有限ですが、さらに離散的な値に限定されていることが多いです。

• 近藤：

  • そうですね。
  • 要求定義により、一部オブジェクトが持っている属性が連続値になっているが、値として状態を持つこともあります。そのときには、連続値を区間で区切った仮想的な離散値へ変換することが必要だと思います。

• 山田：

  • そうですか。よく説明していただき、どうもありがとうございました。

• 鈴木：

  • それなら、その後は実践ですね。皆さんにシステムの要求を考察してもらい、状態のあるオブジェクトを洗い出して、その状態を記述してもらいます。皆さん、よろしくお願いします。

• 皆：

  • それでは、失礼します。

× WZhong

真诚赞赏，手留余香

2元 5元 10元 50元 100元 任意金额

2元

使用微信扫描二维码完成支付

• ← Previous Post
• Next Post →