Software Engineering Lecture 7/10

Menu Menu

7/24 日は休講とします。

復習

先週の復習

オブジェクトの並列実行

UML では、概念モデルで現実世界に対応したオブジェクトの静的な関係を表し、相互作用図( シーケンス図 , 協調図)により、時系列に対応したユースケースの具体的な記述を行う。そして、個々のオブジェクトの振る舞いは、状態図で表現する。

これらのモデルは、ある意味でオブジェクトの並列実行を仮定している。しかし、オブジェクト指向プログラムを普通の逐次型プログラム言語で記述する時には、なんらかの方法で並列実行をシミュレーションしなくてはならない。そのためには以下のような方法がある。

実際には、最初の方法が一番簡単な実現方法だといえるだろう。 しかし、入出力処理がともなう場合には、プロセスを分割するかスレッドを使う必要がある。さらに、スケジューラオブジェクトのプログラムはプロセスモデルを複雑にしてしまうことが多い。

問1

この三つの方法の利点と欠点について考察してみよ。

MVC

Graphical User Interface を含むプログラムでは、その表示されるもの(View) と、それが表しているObject (Model) というようにわけてプログラムする方法がある。View と Model とは同期を取る必要があり、それを担当するControllerというObjectが担当する。これを、Model-View-Controller (MVC) という。

MVC は、Phigs などでも採用されていて、GUIや3D Visualのプログラムでは良く使われる手法である。しかし、Controller が複雑になることが多く、View と Model とで同じような構造体を用意しなければならないなど、不都合な点も多い。

問2

CardPlay のモジュールにおいて MVC がどのように使われているかを、協調図を用いて表せ。

分散プログラミング

最近のアプリケーションは、ほとんどすべてネットワーク対応だといっても良い。ネットワーク対応にする一つの方法は、NFS (ネットワークファイルシステム)を使うことにより、ファイルシステムだけネットワーク対応にする方法である。このようにすれば、既存のプログラムを変更することなく、自動的にネットワーク対応のプログラムに変更される。しかし、例えばメールリーダなどは、NFSに対応したロックプロトコルを要求される。あるいは、X-Window では、表示方式そのものがネットワーク透過であり、自動的にネットワークを越えた画像アプリケーションが作成される。しかし、このアプリケーションが自動的にマルチユーザに対応することはない。これらはネットワーク対応ではあるが、ネットワークアプリケーションということはできない。

本当のネットワークアプリケーションは、自分でネットワーク接続を管理する必要がある。ここで良く使われるのはサーバクライアントと呼ばれるモデルである。サーバクライアントにもいくつか種類がある。 一つ一つの処理をサーバ逐次に行っていく方法では、クライアントを待たせる必要がある。 サーバがクライアントに対応したslave serverを立ち上げれば、データベースのアクセス競合がないかぎり、サービスは平行に行うことができる。

どちらの方法にせよ、このモデルではサーバが必ずネックになる。これをさけるためには、サーバをなくし、それぞれのネットワーク・エージェントが独立に通信すれば良い。 しかし、この方法は、全体の整合性を維持する方法が難しい。それぞれのエージェントが自分のサーバとなるような方法、仮想的なリングを構成する方法、投票により全体の状態を統合する方法、などが使われている。

RFC

ソケットレベルでのプロトコルや、その他のレベルのプロトコルを記述した文書。あまりに低レベルすぎるとかも知れない。

分散プログラミングにおける通信

ネットワーク上の通信は、ストリームなどの原始的な通信を使うこともできるが、いくつかのより高度な方法が提供されている。

Remote Procedure Call

RPC は、手続き呼び出しと同じ形式で、他のサイトのプログラムを呼び出す。RPC には同期と非同期がある。非同期は、call backにより答を返す。

Tuple通信

Linda とは、並列通信プログラミング手法の１つで、タプルと呼ばれるデータを交換する事により通信を行う。タプルは、サーバーに蓄えられ、 id によってアクセスする。サーバーにタプルを出し入れすることにより、複数のクライアントから通信する事ができる。 

    out(id, data);
データをサーバに書き出すのに使う。 

    in(id)
    rd(id)
    ck(id);
これらはサーバのデータを受け取るときに使う。まず、in/rd/ ck のどれかで、どのidのデータを受け取るかを指示する。データが来ていればデータを返す。rd は読み込んでもデータをサーバがから削除しない。ckの場合は、データが来ても、それはタプルがないことを示す空文字列の場合がある。

平行オブジェクト

平行オブジェクトでは、3種類のメッセージ送信がある。

ACTORと呼ばれる平行オブジェクトは、オブジェクトをモニタとして扱う。つまり、オブジェクトの中には一回に一つのactivityしか存在できない。

この制限は、再帰呼出しなどの場合は若干きつすぎる。これの解決には様々な方法がある。 

	呼出しのプライオリティを付ける方法
	オブジェクトの変更を名前付けだけに許すことにして、
	自分自身の呼出しの際には、新しい名前を作る。
Javaなどでは、平行実行とオブジェクトは独立。

CORBA, RMI, Horb

C++ に特化した分散オブジェクトの枠組。C++ でなくとも使えると称するが若干疑問。IDL と呼ばれる分散メソッドの記述が特徴。

Java でも、RMI や Horb といった、普通のメッセージ送信と同じ構文を使った分散通信フレームワークが用意されている。

モーバイル・エージェント

コードそのものを送ると言う発想で作られた分散処理フレームワーク。 今はほとんど消滅した MagicCapというPDA用の言語、Telescript が、ほとんどの基本的な概念をそなえている。

Internet 上では 10 バイト送るのも 1k バイト送るのも時間的にほとんど変わらない。そういう環境では有効となる場合もある。あまり有効なアプリケーションは見つかっていない。

宿題: Multi-user card gameにおける平行実行

マルチユーザゲームの難しい所は、ユーザの参加や脱退である。この部分をサーバで表す場合に、サーバに必要な平行オブジェクトの機能は何か?

実際にカードゲームが始まる時には、それぞれのユーザや、ゲームのサーバが相互に通信しあって処理を行う。以下の例を協調図を使って記述してみよ。

  1. 参加するユーザを決定し、ゲームの開始を参加するユーザに通知する
  2. カードをシャッフルし各ユーザに配布する。
  3. 選択したゲームの1ターンを行う
  4. ゲームの終了判定と終了の処理を行う

解答は、kono@ie.u-ryukyu.ac.jp まで、来週までにメールで送ること。Subject には、 

   Report on Software Engineering Lecture 7/11
を付けること。

Shinji KONO / Tue Jul 10 14:59:51 2001