|
じゃんけんしましょうじゃんけんとはなんぞや? |
||||
登場人物は誰だ | ||||
Mastermind に続いてとりあげるのはじゃんけんです。じゃんけんと聞いただけだと、なんだかとても簡単なような気がして、すぐにでもプログラムを書きたいと思うのではないですか。でも、ちょっとまってください。まず、登場人物の洗い出しから行っていきましょう。 じゃんけんはどのように行うのでしょうか。あたりまえのようですが、少し考えてみましょう。じゃんけんを行うには少なくとも 2 人の登場人物が必要です。ここではプレイヤー A とプレイヤー B としましょう。プレイヤーはグー、チョキ、パーを選択して、勝負するわけです。 ところで、この勝敗を決めるのは誰でしょうか。普通人間が行うとしたらプレイヤー同士が判定の方法 (ようするにグーはチョキに勝ち、チョキはパーに勝ち、パーはグーに勝つこと) を理解しており、プレイヤー自身が勝敗を決めることができます。でも、もし判定方法をプレイヤー A が知らなかったらどうしましょう。プレイヤー B が判定を行ってもいいのですが、プレイヤー A は敵であるプレイヤー B の判定が信用できなかったら...。そういう時は、中立な第三者に判定をお願いすればいいですね。審判でもジャッジでもレフリーでも何でもいいんですが、中立な立場の人が勝負の勝敗を決めるわけです。そうすればプレイヤー A も信用して審判の判定に従うでしょう。 ここでじゃんけんの登場人物をまとめてみましょう。
これらの登場人物の行うことは
になります。 これを Mastermind の時と同じように、ユースケース図で表してみたのが図 2-1 です。ユースケースがひとつしかないので、Mastermind のユースケースより簡単なようなきがしませんか。一番の違いはプレイヤーアクタが複数あることです。ようするに、Mastermind は 1 対 1 のゲームでしたが、じゃんけんは不特定多数のプレイヤーがゲームをするわけです。これをプログラムでどのように表していくかが、じゃんけんゲームの肝になると思います。
|
どうやって遊ぶ | ||||
登場人物もそろったので、プレイヤーたちにじゃんけんを行ってもらいましょう。ゲームは次のように行われるはずです。
はじめの掛け声は誰が行うのでしょう。プレイヤー全員が行うのでもいいのですが、虎視眈々と相手の隙を狙っているプレイヤーたちに同時に掛け声をかけさせるのはちょっと考えものです。はじめの掛け声はゲームの開始を告げていると考えることができます。たとえば、野球で審判がプレイボールを宣言するように、スポーツでは試合の開始を告げるのは審判の役目です。そこで、ここでも「ジャンケンポン」の掛け声は審判にお願いすることにしましょう。 もうひとつ分からないのは、最後の判定はいつ行われるかということです。プレイヤーがまったく同時に手を出せばいいのですが、そうでないときにはプレイヤー全員の手が出るのを待たなくては判定できませんね。ここでは単純化するために、後出しなどの反則は考えないことにします。ということは審判は全員の手が出たかどうかを監視しなくては行けないことになります。 前節でも説明したように、アプリケーションを作るときには「誰が何をした」ということがとても重要になるので必ず確認するようにしましょう。 この 2 点を考慮して、ゲームの流れを書きなおしてみました。
このように記述すると、1 から 5 というように動作が行われているようになりますが、実際は同時に行われたり先に行われていることがあります。たとえば、プレイヤー A とプレイヤー B が手を出すのは同時に行われます。 シーケンス図は一連の処理が順序よく処理されることを記述するにはいいのですが、処理の順序がはっきり決まらないときは、記述するのが難しくなってしまいます。ただし、じゃんけんは処理の順序自体は決まっているので、シーケンス図に表すことができます。 もし、処理の順序が決まらないときには、いろいろな条件下で複数のシーケンス図を描くことをお勧めします。一枚のシーケンス図ではかけなくても、複数のシーケンス図でカバーできればそれでいいのです。 図 2-2 にじゃんけんの流れをシーケンス図で表してみました。
|
処理の見直し | ||
もう一度、図 2-2 のシーケンス図を見ていきましょう。処理の流れという観点から見ると、図 2-2 は流れが 1 本になっていないことがお分かりでしょうか。前章でも説明したように、処理は基本的に 1 つの流れになっていなくてはなりません。ところが、このシーケンス図では 4 のメッセージセンディングまでは 1 本ですが、5 と 6 のメッセージセンディングは 4 までの処理の流れとは異なってしまいます。 やはり、Mastermind の時とおなじように、シーケンス図の見直しが必要なようです。シーケンス図の中で登場人物同士のやり取りは
の 2 種類があります。 まず、「試合開始を告げる」から考えていきましょう。試合開始を告げられたプレイヤーはそのメッセージに対してどうしたらいいでしょうか。選択肢としては次の 3 種類の候補があるのではないでしょうか。
2. は単に返事だけを返すようなものです。よくこれを Acknowledge、略して Ack といいます。 たとえば、ある人が「今は 5 時 20 分ですよ」と他の人に教えてあげた時に、1. はまったく答えない、2. は「分かりました」と答える、3. は「それでは、6 時までにはあと 40 分ですね」と答えるようなものです。 そこで、試合開始を告げられた時に、プレイヤーはどのような処理をするのでしょうか。ゲームが始まればプレイヤーは手を選択するのですから、このメッセージが到達した時点で手を選択してもいいはずです。こう考えてみると、「試合開始を告げる」の戻りは、1. や 2. でもいいのですが、3. のように処理結果、ここでは選択した手を戻り値として帰すことも可能であるのではないでしょうか。こうすると、「試合開始を告げる」という動作と「手を提示する」という動作がいっしょになってしまいました。 したがって、処理の流れも変わってきます。図 2-2 のシーケンス図では審判はプレイヤーに試合開始を告げてから、プレイヤーからの手の提示を待っていました。これが審判がプレイヤーに手を教えてもらうという流れになります。これにあわせてアップデートしたシーケンス図を図 2-3 に示しました。 こうすることによって、処理も 1 本の流れになりました。メッセージセンディングが行われたときにどういう処理を行うかを考えることによって、戻りをどのようにすればいいかを決めることができます。 (Oct. 2000) |
|