注意! 6/16は授業があります。6/23 はお休みにします。
オブジェクトは、個々に勝手に動作するのではなく、全体としてある目的を もって協調して動作するべきであろう。個々のオブジェクトの振る舞いの 総和がシステムの振る舞いを決める。これは単純には、個々のオブジェクトの 状態遷移図の積であるはずである。
しかし、それは人間の手に負えないほど複雑なものであるのが普通である。 たとえば、2状態のオブジェクトが10個あったとすると、その積は2^10=1024 の状態を持つ。 したがって、個々のオブジェクトの状態だけでなく、システム全体の振る舞いを 見通し良くするための表現が必要だと考えられる。
そのためにオブジェクトライフサイクル手法では以下のようなさまざまな モデルを工夫している。
これらのモデルは、ある意味でオブジェクトの並列実行を仮定している。 しかし、オブジェクト指向プログラムを普通の逐次型プログラム言語で 記述する時には、なんらかの方法で並列実行をシミュレーションしなくては ならない。そのためには以下のような方法がある。
この三つの方法の利点と欠点について考察してみよ。
Action Dataflow Diagram は、問題のオブジェクトへの分割が終り、 さらに、個々のオブジェクトのアクション(状態遷移)の解析が終った 後で、複数のオブジェクトのアクションの流れを記述するものである。 実際には、このような順序でOOA/OODが行われるとは限らないし、この 手順は、Rapid proto typing を通して何回も繰り返される。
ADFDは、残念ながら全ての場合を尽くして記述することはできない。あくまでも、 典型的な部分を記述することになる。なるべくうまく記述して、アプリケーション 全体の動作を記述するようにする。これはフローチャートではないことに注意する こと。
Object 間の通信をみるだけならば、Object Communication Model
というのが適している。
Graphical User Interface を含むプログラムでは、その表示され るもの(View) と、それが表しているObject (Model) というように わけてプログラムする方法がある。View と Model とは同期を取る 必要があり、それを担当するControllerというObjectが担当する。 これを、Model-View-Controller (MVC) という。
MVC は、Phigs などでも採用されていて、GUIや3D Visualのプログラムでは 良く使われる手法である。しかし、Controller が複雑になることが多く、 View と Model とで同じような構造体を用意しなければならないなど、不都合な 点も多い。
Multi-user card game をPerl/Tkで作ることを考えてみよう。これを、情報モデル、 状態モデル、そして、システム全体の振る舞いを考えることによってオブジェクト 指向問題分析を行う。
まず、情報モデルを作成する。必要なオブジェクトを抜き出す。
次に、その相互の静的な参照関係を考える。図は、文字で作成するか、 idraw などで作成してメールで送ること。
解答は、 kono@ie.u-ryukyu.ac.jp まで、来週までにメールで送ること。 Subject には、
Report on Software Engineering Lecture 6/9を付けること。
6/16は授業があります。6/23 はお休みにします。