tut_uml_modeling_bs04.adoc

front_matter.adoc

スコアやフレームの状態を調べる

設計で作成するモデルと実装に使うプログラムの対応づけができたました。 この対応づけを前提に、ボウリングスコアのモデルの作成を進めましょう。

フレームの状態について検討する

[scoresheet01] を見ると、フレームの表示は、ゲームの進行状況によって変わっています。

ゲームの進行状況によってフレームの表示は異なる

• まだプレーしていないフレーム

• 1投目の投球を待っているフレーム（現在のプレーヤーの現在のフレームの1投目の前）

• 2投目の投球を待っているフレーム（現在のプレーヤーの現在のフレームの2投目の前）

• 2投目が投球されて獲得ピン数が確定したフレーム（1,2投目のピン数とトータルスコアが表示されている）

• ストライクのボーナスが確定しないフレーム（ストライクの記録だけでトータルスコアは表示されていない）

• スペアのボーナスが確定しないフレーム（1投目とスペアの記録だけでトータルスコアは表示されていない）

• スペアまたはストライクのボーナスが確定したフレーム（1,2投目のピン数とトータルスコアが表示されている）

それぞれについて、もう少し詳しく見てみましょう。

まだプレーしていないフレーム

まだプレーしてないフレームは、フレームの最初の状態です（ まだプレーしていないフレーム ）。 このフレームは、ピン数の入力を待っていません。

Figure 1. まだプレーしていないフレーム

1投目の投球を待っているフレーム

現在プレー中のフレームで、まだ1投目が投球されていない状態のフレームです（ 1投目の投球を待っているフレーム ）。 次にピン数を受け取ると、このフレームの1投目に記録されます。

Figure 2. 1投目の投球を待っているフレーム

2投目の投球を待っているフレーム

現在プレー中のフレームで、1投目がストライクでなかったときに2投目を待っている状態のフレームです（ 2投目の投球を待っているフレーム ）。 次にピン数を受け取ると、このフレームの2投目に記録されます。

Figure 3. 2投目の投球を待っているフレーム

スペアのボーナスの確定待ちのフレーム

現在プレー中のフレームの前のフレームがスペアで、現在のフレームが1投目の投球を待っているとき、前のフレームはスペアボーナスの確定待ちの状態です（ スペアのボーナスの確定待ちのフレーム ）。 次にピン数を受け取ると、現在のフレームの1投目に記録されるとともに、前のフレームのスペアボーナスが確定します。

Figure 4. スペアのボーナスの確定待ちのフレーム

ストライクのボーナスの確定待ちのフレーム

ストライクボーナスの確定待ちには2通りの場合があります。

1つ目は、現在プレー中のフレームの前のフレームがストライクで、現在のフレームが2投目の投球を待っているときです。 このとき、前のフレームはストライクボーナスの確定待ちの状態です（ ストライクのボーナスの確定待ちのフレーム（次がストライクでない） ）。 次にピン数を受け取ると、現在のフレームの2投目に記録されるとともに、前のフレームのストライクボーナスが確定します。

Figure 5. ストライクのボーナスの確定待ちのフレーム（次がストライクでない）

2つ目は、現在プレー中のフレームが1投目の投球を待っていて、前のフレームと前の前のフレームがともにストライクであったとき（ダブルのとき）ときです。 このとき、前の前のフレームはストライクボーナスの確定待ちの状態です（ ストライクのボーナスの確定待ちのフレーム（次がストライク） ）。 次にピン数を受け取ると、現在のフレームの1投目に記録されるとともに、前の前のフレームのストライクボーナスが確定します。

Figure 6. ストライクのボーナスの確定待ちのフレーム（次がストライク）

獲得ピン数とボーナスが確定したフレーム

現在のフレームがスペアやストライクにならなかったとき、そのフレームはボーナスの確定待ちにならず、この段階でそのフレームのトータル（ボーナスなしの獲得ピン数）が確定します。

スペアボーナスの確定待ち、またはストライクボーナスの確定待ちのフレームは、後のフレームの投球によってボーナスが確定すると、フレームのトータルが確定します。 このとき、確定待ちのフレームでは、そのフレームの獲得ピン数と確定したボーナスの合計がそのフレームのトータルです。

フレームのトータルが求められると、それ以前のフレームまでの「のべのトータル」にそのフレームのトータルを加算して、のべのトータルを更新します。そして、更新したのべのトータルがフレームの下部に記録されます（ 2投目を投球して、ピン数が確定したフレーム（のべのトータルが求められている） ）。 このとき、確定待ちになっていたフレームものべのトータルが更新され、その段階のゲームのトータルも更新されます。

Figure 7. 2投目を投球して、ピン数が確定したフレーム（のべのトータルが求められている）

フレームの状態をステートマシン図で表す

フレームの状態を検討した結果、フレームはゲームの状況によって変わる複数の状態を持つことがわかりました。 また、フレームが表示できる情報も、状態によって異なることがわかりました。 このことを、モデル図を使って表してみましょう。 状態とその推移（状態遷移と呼びます）を表すには、ステートマシン図を使います。

「Frame」クラスにステートマシン図を追加する

「Frame」クラスの状態を表す図を描きたいので、「Frame」クラスに図を追加しましょう。

「Frame」クラスにステートマシン図を追加する

1. 「Frame」クラスにステートマシン図を追加する

   • 構造ツリーから「Frame」クラスを選択し、右クリックしてポップアップメニューを表示する（ 「Frame]クラスにステートマシン図を追加する ）。

   • 「図の追加＞ステートマシン図」でステートマシン図が追加される。

Figure 8. 「Frame]クラスにステートマシン図を追加する

2. ステートマシン図に名前をつける

   • 追加したステートマシン図のプロパティーの「ベース」を開く。

   • 名前を編集して「Frameクラスのステートマシン図」とする。

   • ダイアグラムエディタのタイトルやタブにも反映される。

フレームのステートマシン図を作成する

ステートマシン図に、フレームの状態と状態遷移を追加しましょう。

ステートマシン図に「Frame」クラスの状態遷移を作成する

1. 「Frame」クラスの最初の状態を作成する（ 「Frame」クラスのステートマシン図に最初の状態を追加する ）。

   • パレットから「開始疑似状態」を選択し、ステートマシン図に追加する。

   • パレットから「状態」を選択し、ステートマシン図に追加する。

   • 「まだプレーしていない」状態を「RESERVED」という名前にする。

   • パレットから「遷移」を選択して、「開始疑似状態」から「RESERVED」へ遷移を引く。

Figure 9. 「Frame」クラスのステートマシン図に最初の状態を追加する

2. 最初の状態遷移とイベントを追加する（ 「Frame」クラスのステートマシン図に1投目の前の状態遷移とイベントを追加する ）。

   • 「1投目の投球を待っている」状態「BEFORE_1ST」を追加する。

   • 「RESERVED」から「BEFORE_1ST」へ状態遷移を引き、イベント「SETUP」を割り当てる。

Figure 10. 「Frame」クラスのステートマシン図に1投目の前の状態遷移とイベントを追加する

3. 1投目の後の状態遷移とイベントを追加する（ 「Frame」クラスのステートマシン図に1投目の後の状態遷移とイベントを追加する ）。1投目の後は、受け取ったピン数によって遷移先は2通りある（ストライクか否か）ので「選択疑似状態」を使って遷移先を分ける。

   • 「2投目の投球を待っている」状態を「BEFORE_2ND」として追加する。

   • 「スペアのボーナスの確定待ち」と「ストライクのボーナスの確定待ち」を「PENDING」として追加する。

   • 「選択疑似状態」を追加する。

   • ピン数を受け取るイベント「PINS」（パラメーターとしてピン数 pins を持つ）を「BEFORE_1ST」から「選択疑似状態」への遷移に割り当てる。アクションとして、イベントで受け取ったピン数を1投目のピン数に保存する。

4. 選択疑似状態からの遷移を追加する。

   • 1投目のピン数がストライクであれば「PENDING」へ遷移する。このとき2投目のピン数は「0」にする。

   • 1投目のピン数がストラクでなければ「BEFORE_2ND」へ遷移する。

Figure 11. 「Frame」クラスのステートマシン図に1投目の後の状態遷移とイベントを追加する

5. 2投目の後の状態遷移とイベントを追加する（ 「Frame」クラスのステートマシン図に2投目の後の状態遷移とイベントを追加する ）。2投目の後は、受け取ったピン数によって遷移先は2通りある（スペアか否か）ので「選択疑似状態」を使って遷移先を分ける。

   • 「獲得ピン数とボーナスが確定した」状態を表す「FIXED」として追加する。

   • 2投目の後の処理の選択のために「選択疑似状態」を追加する。

   • 「BEFORE_2ND」でイベント「PINS」を受け取ると、選択疑似状態へ遷移する。アクションとして、受け取ったピン数を2投目のピン数に保存する。

6. 選択疑似状態からの遷移を追加する。

   • 2投目のピン数がスペアであれば「PENDING」へ遷移する。

   • 2投目のピン数がスペアでなければ「FIXED」へ遷移する。

7. 「PENDING」からの遷移を追加する。

   • 「PENDING」中のフレームで、イベント「DETERMINE」を受け取ったらトータルが確定したとし、「FIXED」へ遷移する。

Figure 12. 「Frame」クラスのステートマシン図に2投目の後の状態遷移とイベントを追加する

これで、フレームのステートマシン図が作成できました。

フレームのクラス図を更新する

ステートマシン図で状態遷移のために追加したアクションやガード条件用の処理を「Frame」クラスのメソッドに追加しておきましょう（ ステートマシン図に合わせて「Frame」クラスを更新する ）。

Figure 13. ステートマシン図に合わせて「Frame」クラスを更新する

フレームの処理をプログラムに変換する

フレームのクラスとステートマシン図が作成できたので、Rubyのプログラムに変換してみましょう。 「[_model_to_code_design]」で決めたルールにしたがって、モデルからコードへ変換します。

まず、プログラムの初期化とアクションの部分は、 【Ruby】score.rb(1) のようになるでしょう。

【Ruby】score.rb(1)

# frozen_string_literal: true

require 'securerandom'

# Frameは1フレーム分のピン数やボーナスを記録する
class Frame
  attr_reader :frame_no
  attr_accessor :first, :second, :spare_bonus, :strike_bonus, :total, :state

  def initialize(frame_no)
    @frame_no = frame_no
    @first = 0
    @second = 0
    @spare_bonus = 0
    @strike_bonus = 0
    @total = 0
    @state = :RESERVED # (1)
  end

  def action(event, pins=0)
    case @state # (2)
    when :RESERVED
      case event
      when :SETUP # (3)
        @state = :BEFORE_1ST
      else
        puts "invalid event: #{event} is ignored."
      end
    when :BEFORE_1ST
      before_1st_porc(event, pins) # (4)
    when :BEFORE_2ND
      before_2nd_proc(event, pins) # (5)
    when :PENDING
      case event
      when :DETERMINE # (6)
        @state = :FIXED
      end
    when :FIXED
      puts 'fixed.'
    end
  end
end

1. フレームの初期状態は「RESERVED」とする。状態はRubyのシンボルを使って表現する。

2. 状態に応じて処理を分ける。

3. 「RESERVED」状態では「SETUP」イベントを受け取り、「BEFORE_1ST」状態へ遷移する。他のイベントが来たら無視する。

4. 「BEFORE_1ST」状態では「PINS」イベントを待つ。詳細な処理は「before_1st_porc」メソッドに記載する。

5. 「BEFORE_2ND」状態では「PINS」イベントを待つ。詳細な処理は「before_2nd_porc」メソッドに記載する。

6. 「PENDING」状態では「DETERMINE」イベントを受け取り、「FIXED」状態へ遷移する。

ガード条件やアクションのメソッドは、 【Ruby】score.rb(2) のようになるでしょう。

【Ruby】score.rb(2)

# frozen_string_literal: true

require 'securerandom'

# Frameは1フレーム分のピン数やボーナスを記録する
class Frame
  # initialize、actionの定義がここにある

  def frame_score # (1)
    @first + @second + @spare_bonus + @strike_bonus
  end

  def strike? # (2)
    @first == 10
  end

  def spare?
    @first < 10 && (@first + @second) == 10
  end

  def miss?
    @first < 10 && @second.zero && @state == :FIXED
  end

  def gutter?
    @first.zero
  end

  def fixed? # (3)
    @state == :FIXED
  end

  def to_s # (4)
    total = if @state == :FIXED
              @total
            else
              '   .'
            end
    format '|%2d|%3s|%3s|%5s|%11d|%11d|%12d|%11s|',
           @frame_no, @first, @second, total, frame_score,
           @spare_bonus, @strike_bonus, @state
  end

  private # (5)

  def before_1st_porc(evt, pins) # (6)
    case evt
    when :PINS
      puts "invalid pins: #{pins}" if pins.negative? || pins > 10
      @first = pins
      @state = if strike?
                 @second = 0
                 :PENDING
               else
                 :BEFORE_2ND
               end
    else
      puts "invalid event: #{evt} on #{@state}."
    end
  end

  def before_2nd_proc(evt, pins) # (7)
    case evt
    when :PINS
      puts "invalid pins: #{pins}" if pins.negative? || pins > (10 - @first)
      @second = pins
      @state = if spare?
                 :PENDING
               else
                 :FIXED
               end
    else
      puts "invalid event: #{evt} on #{@state}."
    end
  end
end

1. フレームのスコアを計算するメソッド

2. ストライクかどうか判定するガード条件用のメソッド。

3. フレームのスコアが確定したか調べるメソッド。

4. 「Frame」クラスのインスタンスを文字列化するメソッド。呼び出し時点の「Frame」クラスが保持するインスタン変数の値を出力するのに使う。

5. これ以降のメソッドはプライベート。

6. 「1投目の投球を待っている」状態を担当するメソッド。イベント「PINS」を受け取り、1投目のピン数に保存する。その後ストライクかどうか調べ、次の状態へ遷移する。

7. 「2投目の投球を待っている」状態を担当するメソッド。イベント「PINS」を受け取り、2投目のピン数に保存する。その後スペアかどうか調べ、次の状態へ遷移する。

サービスフレームの扱いについて検討する

「クラッシックスコアリング」の場合、第10フレームが他のフレームとは異なっています。 サービスフレームという考え方があり、ストライクやスペアの場合に追加で投球できます。

このサービスフレームの扱い方にについて整理しておきましょう。

第10フレームがストライクもスペアもない場合

第10フレームがストライクでもスペアもない場合、サービスフレームは提供されません。 第9フレームまでの通常のフレームと同様、1投目と2投目を記録するだけです（ 第10フレームがストライクもスペアもない場合 ）。

Figure 14. 第10フレームがストライクもスペアもない場合

第10フレームがスペアの場合

第10フレームの2投目でスペアになった場合、1投目と2投目を通常のフレームと同様に記録したのち、もう1投追加されます。 これを、第10フレームに加えて、第11フレームの1投目が追加されたとみなします。 つまり、ゲームスコアのデータを「 第10フレームがスペアの場合（第11フレームの2投目はない） 」のように構成します。

Figure 15. 第10フレームがスペアの場合（第11フレームの2投目はない）

スコアをこのように構成しておくと、第10フレームの場合も、通常フレームの組み合わせによってボーナスが計算できます。 ゲーム終了時の第10フレームのスコア（ピン数に以後の投球によるボーナスを加えたスコア）を取得すると、それがゲームのスコアです。

第10フレームの1投目がストライクの場合

第10フレームの1投目がストライクの場合、第10フレームをストライクとした上で、もう2投追加されます。 これを、第10フレームに加えて、第11フレームの1投目と2投目が追加されたとみなします。 つまり、ゲームスコアのデータを「 第10フレームの1投目がストライクの場合 」のように構成します。 だたし、第11フレームの1投目がストライクの場合は、同じ2投追加でも次の「2投目もストライクの場合」の考え方を使います。

Figure 16. 第10フレームの1投目がストライクの場合

スコアをこのように構成しておくと、第10フレームの場合も、通常フレームの組み合わせによってボーナスが計算できます。 ゲーム終了時の10フレームのスコア（ピン数に以後の投球によるボーナスを加えたスコア）を取得すると、それがゲームのスコアです。

第10フレームの2投目もストライクの場合

第10フレームの2投目もストライクの場合、第10フレーム、第11フレームをストライクとした上で、もう1投追加されます。 これを、第10フレーム、第11フレームに加えて、第12フレーム目の1投目が追加されたとみなします。 つまり、ゲームスコアのデータを「 第10フレームの2投目もストライクの場合 」のように構成します。 このように構成すれば、通常のフレームでダブルをとったときの計算方法（ストライクが続いたときはさらに次のフレームの1投目が2投目として加算される）のままで第10フレームのボーナスが計算できます。

Figure 17. 第10フレームの2投目もストライクの場合

スコアをこのように構成しておくと、第10フレームの場合も、通常フレームの組み合わせによってボーナスが計算できます。 ゲーム終了時の10フレームのスコア（ピン数に以後の投球によるボーナスを加えたスコア）を取得すると、それがゲームのスコアです。

スコアの状態をステートマシン図で表す

サービスフレームの扱い方を検討した結果、工夫すれば通常のフレームと同じように扱えることがわかりました。 それでは、フレームの集まりであるスコアについて、どのような処理をすればよいのか検討しましょう。

「Score」クラスにステートマシン図を追加する

「Frame」クラスにステートマシン図を追加したのと同じ手順で、「Score」クラスにステートマシン図を追加します（ 「Score」クラスにステートマシン図を追加する ）。

Figure 18. 「Score」クラスにステートマシン図を追加する

スコアのステートマシン図を作成する

ステートマシン図に、検討した結果を使って、スコアの状態と状態遷移を追加しましょう。

ステートマシン図に「Score」クラスの状態遷移を作成する

1. 「Score」クラスの状態を追加する（ ステートマシン図に「Score」クラスの状態を追加する ）。

   • パレットから「開始疑似状態」をステートマシン図に追加する。

   • パレットから「状態」を選択し、ステートマシン図に追加する。

   • 「1投目待ち」の状態として状態名を「WAIT_FOR_1ST」に設定する。

   • 「2投目待ち」の状態として状態名を「WAIT_FOR_2ND」に設定する。

   • 「ゲームの終了」の状態として状態名を「FINISHED」に設定する。

   • パレットから「終了疑似状態」をステートマシン図に追加する。

Figure 19. ステートマシン図に「Score」クラスの状態を追加する

2. 「Score」クラスのイベントとアクションを作成する（ ステートマシン図に「Score」クラスのイベントとアクションを追加する ）。

3. 「WAIT_FOR_1ST」からの遷移には、ストライクの場合、ストライクでない場合、ゲームが終了の場合があるので、「選択疑似状態」を追加する。

   • 「WAIT_FOR_1ST」から「選択疑似状態」への遷移では、ピン数を受け取るのを待っている。受け取ったときには、現在にフレームへピン数のイベントを送る。その後、1投目の後のスペアとストライクのボーナスを計算し、のべのトータルを更新する。

   • 「選択疑似状態」から「WAIT_FOR_1ST」への遷移のガード条件は「ストライクである」こと。このときはアクションとして「次のフレームへ進む」。

   • 「選択疑似状態」から「WAIT_FOR_2ND」への遷移のガード条件は「ストライクでない（かつゲーム終了ではない）」こと。

   • 「選択疑似状態」から「FINISHED」への遷移のガード条件は「ゲーム終了である」であること。

4. 「WAIT_FOR_2ND」からの遷移には、ゲーム終了の場合とそうでない場合があるので、「選択疑似状態」を追加する。

   • 「WAIT_FOR_1ST」から「選択疑似状態」への遷移では、ピン数を受け取るのを待っている。受け取ったときには、現在にフレームへピン数のイベントを送る。そして、2投目の後のスペアとストライクのボーナスを計算し、のべのトータルを更新する。

   • 「選択疑似状態」から「WAIT_FOR_1ST」への遷移のガード条件は「ゲーム終了ではない」こと。このときはアクションとして「次のフレームへ進む」。

   • 「選択疑似状態」から「FINISHED」への遷移のガード条件は「ゲーム終了である」であること。ゲーム終了は、10フレーム目の状態が「FIXED」になったことで判定できる（そのようなメソッドを用意する）。

Figure 20. ステートマシン図に「Score」クラスのイベントとアクションを追加する

クラス図に検討結果を反映する

第10フレームの場合にもサービスフレームのために追加のフレームを用意することで、通常フレームと同じようにピン数やボーナスを扱えるようになりました。

クラス図にこの結果を反映しましょう。

ステートマシン図に合わせてクラス図を更新する（ ステートマシン図に合わせてクラス図を更新する ）

1. 「Frame」クラス側の関連端の多重度を「10」から「12」に変更する。

   • これは、通常のフレームを追加する方法でサービスフレームを処理するための追加。

2. 関連にノートをつけて説明をつけておく。

   • パレットからノートを選択し、クラス図に追加する。

   • ノートに「Frame側の多重度は、サービスフレーム用に必要なフレーム分だけ追加してある」という説明を追加する。

   • ノートから関連の線に向かってアンカーを引く。

   • パレットからノートのアンカーを選択し、ノートにマウスカーソルを移動して青枠が表示されるのを待つ。

   • マウスのボタンを押したまま、マウスカーソルをドラッグし、関連の線に近づけ青枠が表示されるのを待つ。

3. 「Score」クラスにステートマシン図で作成したメソッドを追加しておく。

   • 「次のフレームへ進む」メソッド「go_next_frame」を追加する。

   • 「ゲーム終了か判定する」メソッド「finished?」を追加する。

   • 「1投目の後のスペアのボーナスを計算する」メソッド「calc_spare_bonus_after_1st」を追加する。

   • 「1投目の後のストライクのボーナスを計算する」メソッド「calc_strike_bonus_after_1st」を追加する。

   • 「2投目の後のストライクのボーナスを計算する」メソッド「calc_strike_bonus_after_2st」を追加する。

   • 「のべのトータルを更新する」メソッド「update_total」を追加する。

   • スコアを記録するメソッド（ステートマシン図の処理を担当する）メソッド「scoring」を追加する。

   • ステートマシン図の状態ごとの処理を担当するメソッド「wait_for_1st_proc」と「wait_for_2nd_proc」を追加する。

   • スコアの記録を文字列化するメソッド「to_s」を追加する。

4. 関連を追加する

   • 「Score」クラスから「Frame」クラスへ、「現在のフレーム」を指す関連「current」を追加する。

Figure 21. ステートマシン図に合わせてクラス図を更新する

Tip	ノート内の文章を編集するときは、ノートを選択した状態でプロパティーを使って編集すると、改行が入力しやすくなります。

スコアの処理をプログラムに変換する

スコアのクラスとステートマシン図が作成できたので、Rubyのプログラムに変換してみましょう。 変換したプログラムの初期化やユーティリティメソッドの部分は、 【Ruby】score.rb(3) のようになるでしょう。

【Ruby】score.rb(3)

# frozen_string_literal: true

require 'securerandom' # (1)

# Frameクラスの定義がここにある

# スコアは各人の10フレーム分のスコアを記録する
class Score # (2)
  attr_accessor :id, :player, :fno, :frames, :state

  def initialize(name)
    @id = SecureRandom.urlsafe_base64(8) # (3)
    @player = name
    @fno = 1
    @frames = []
    (-1..13).each do |fno| # (-1, 0) are dummy frame # (4)
      @frames.append Frame.new(fno)
    end
    @state = :WAIT_FOR_1ST # (5)
    @frames[fno2idx(@fno)].action(:SETUP) # (6)
  end

  def fno2idx(fno) # (7)
    fno + 1 # frame number 1 => array index 3 (0 origin).
  end

  def frame(fno)
    @frames[fno2idx(fno)] # return index on @frams at frame number.
  end

  def go_next_frame # (8)
    @fno += 1
    @frames[fno2idx(fno)].action(:SETUP)
  end

  def current # (9)
    frame(@fno)
  end
end

1. 安全なIDを生成するためのライブラリをインポートした。

2. 「Score」クラスの定義のはじまり。

3. スコアのインスタンスにIDをつけておく。

4. 「Frame」のインスタンスの作成。クラス図では、「Score」から「Frame」へのコンポジションとして表されている部分。設計上は12個だが、サービスフレームで「次」を参照する場面、第1フレームで「前のフレーム」「前の前のフレーム」を参照する場面で参照するダミーのフレームを追加している。

5. スコアの最初の状態を「WAIT_FOR_1ST」にする。

6. 第1フレームへ「SETUP」イベントを送る。

7. フレーム番号とフレームの配列のインデックスを対応づけるメソッド（ダミーのフレームを第1フレームの前に追加したためのオフセット）。

8. 現在のフレームを「次のフレームへ進める」メソッド。このメソッドでは、次のフレームに「SETUP」イベントを送る。

9. 「現在のフレーム」を参照するためのメソッド。クラス図では関連端名が「current」の「Frame」クラスへの関連で表されている。

ボーナス計算やトータル計算のメソッドは 【Ruby】score.rb(4) のようになるでしょう。

【Ruby】score.rb(4)

# Frameクラスの定義やそれ以前のコードがここにある

# スコアは各人の10フレーム分のスコアを記録する
class Score
  # アクセサーの定義がここにある
  # initialize、fno2idx、frame、go_next_frame、currentメソッドの定義がここにある

  def prev # (1)
    frame(@fno - 1)
  end

  def pprev # (2)
    frame(@fno - 2)
  end

  def calc_spare_bonus_after_1st # (3)
    return unless prev.spare?

    prev.spare_bonus = current.first
    prev.action(:DETERMINE)
  end

  def calc_strike_bonus_after_1st # (4)
    return unless prev.strike? && pprev.strike?

    pprev.strike_bonus = prev.first + current.first
    pprev.action(:DETERMINE)
  end

  def calc_strike_bonus_after_2nd # (5)
    return unless prev.strike?

    prev.strike_bonus = current.first + current.second
    prev.action(:DETERMINE)
  end

  def update_total # (6)
    @frames.each_cons(2) do |prev, cur|
      cur.total = prev.total + cur.frame_score
    end
  end

  def finished? # (7)
    frame(10).fixed?
  end
end

1. ボーナス計算で使う、「前のフレーム」を得るメソッド。

2. ボーナス計算で使う、「前の前のフレーム」を得るメソッド。

3. 1投目の後のスペアボーナスを計算するメソッド。前のフレームのスコアが確定するので、前のフレームへ「DETERMINE」イベントを送る。

4. 1投目の後のストライクボーナスを計算するメソッド。前の前のフレームからストライクが続いていた場合、ここでスコアが確定するので、前の前のフレームへ「DETERMINE」イベントを送る。

5. 2投目の後のストライクボーナスを計算するメソッド。前のフレームのスコアが確定するので、前のフレームへ「DETERMINE」イベントを送る。

6. 「のべのトータル」を更新するメソッド。each_consは、配列から指定した数ずつ要素を取り出すメソッド。

7. 「ゲーム終了」の判定用のメソッド。サービスフレームの検討結果から、第10フレームが「FIXED」になれば、そのゲームは終了とみなせる。

そして、ステートマシン図で表した、実際にゲームの進行に合わせてスコアを記録する処理をするメソッドは 【Ruby】score.rb(5) のようになるでしょう。

【Ruby】score.rb(5)

# Frameクラスの定義やそれ以前のコードがここにある

# スコアは各人の10フレーム分のスコアを記録する
class Score
  # アクセサーの定義がここにある
  # initializeからfinished?までのメソッドの定義がここにある

  def wait_for_1st_proc(pins) # (1)
    current.action(:PINS, pins) # (2)
    calc_spare_bonus_after_1st
    calc_strike_bonus_after_1st
    update_total
    if finished? # (3)
      @state = :FINISHED
    elsif current.strike? # (4)
      @state = :WAIT_FOR_1ST
      go_next_frame
    else # (5)
      @state = :WAIT_FOR_2ND
    end
  end

  def wait_for_2nd_proc(pins) # (6)
    current.action(:PINS, pins) # (7)
    calc_strike_bonus_after_2nd
    update_total
    if finished? # (8)
      @state = :FINISHED
    else # (9)
      @state = :WAIT_FOR_1ST
      go_next_frame
    end
  end

  def scoring(pins) # (10)
    case @state
    when :WAIT_FOR_1ST
      wait_for_1st_proc(pins)
    when :WAIT_FOR_2ND
      wait_for_2nd_proc(pins)
    when :FINISHED
      puts 'finished'
    end
  end

  def to_s # (11)
    "Player:#{@player}, Score(id: #{@id}), Frame:#{@fno},
|No|1st|2nd|Total|Frame Score|Spare Bonus|Strike Bonus|Frame State|
#{@frames.join("\n")}"
  end
end

1. 「WAIT_FOR_1ST」状態のときの状態遷移のメソッド。

2. 現在のフレームについて、ピン数を更新し、ボーナスを計算し、のべのトータルを更新する。

3. 「選択疑似状態」での遷移先の分岐処理。「ゲーム終了」の場合は「FINISHED」へ遷移する。

4. 「ストライクだった」の場合は、次のフレームへ進んで「WAIT_FOR_1ST」へ遷移する。

5. それ以外のときは2投目を待つので、「WAIT_FOR_2ND」へ遷移する。

6. 「WAIT_FOR_2ND」状態のときの状態遷移のメソッド。

7. 現在のフレームについて、ピン数を更新し、ボーナスを計算し、のべのトータルを更新する。

8. 「選択疑似状態」での遷移先の分岐処理。「ゲーム終了」の場合は「FINISHED」へ遷移する。

9. それ以外のときは、次のフレームへ進んで「WAIT_FOR_1ST」へ遷移する。

10. スコアを記録するステートマシン図の振る舞いを担当するメソッド。状態に応じてそれぞれの状態用のメソッドを呼び出す。

11. 「スコア」クラスのインスタンスの内容（内包するフレームも含む）を文字列化するメソッド。

これで、フレームとスコアを、それぞれのステートマシン図で表した振る舞いに合わせて動作するプログラムに変換できました。

ゲームの進行について検討する

残るは、複数名のスコアのセットで構成される「Game」と、複数の「Game」を記録する「ScoreSheet」クラスです。

ヨーロピアン方式とアメリカン方式

ボウリングを複数名で楽しむとき、みなさんはたいてい、1組のチームで1つのレーンを使って、1フレームごとにプレーヤーが交代しながらプレイします。 このようなゲームの方式は、「ヨーロピアン方式」と呼ばれています。

別の方式として、ボールラック（ボールが返ってくるラック）を挟んだ2つのレーンを、1フレーム交代で使ってプレーする方式があります。 このようなゲームの方式は「アメリカン方式」と呼ばれています。

このチュートリアルでは、ヨーロピアン方式を使うことにします。

Gameクラスの処理

ほとんどのみなさんがボウリングをやるときにゲームを進行する手順は、「ヨーロピアン方式」と呼ばれています。 「ヨーロピアン方式」による進行を想定して、「Game」クラスはどのような手順で動作させるべきか整理しましょう。

ボウリングのゲームを進める手順（ヨーロピアン方式）

1. スコアシートに参加するプレーヤー名を書く（エントリーする）。

2. 書いたプレーヤーの順に1フレーム分プレーする（各自のターン）。

3. 次のプレーヤと交代する（次のターンへ進む）。

4. 全員がゲーム終了するまで手順を繰り返す。

この方式に合わせてスコアを記録する処理をする「Game」クラスは、 【Ruby】score.rb(6) のようになるでしょう。

【Ruby】score.rb(6)

# FrameクラスとScoreクラスの定義やそれ以前のコードがここにある

# Gameクラスは複数名の1ゲーム分のスコアのセットを構成する
class Game
  attr_reader :id, :turn, :scores

  def initialize
    @id = SecureRandom.urlsafe_base64(8) # (1)
    @turn = 0
    @scores = []
  end

  def entry(name = 'unknown') # (2)
    @scores.append(Score.new(name))
  end

  def turn_player_name # (3)
    @scores[@turn].player
  end

  def go_next_turn # (4)
    @turn = (@turn + 1) % @scores.size
  end

  def playing(score_index, pins) # (5)
    @scores[score_index].scoring(pins)
    if @scores[score_index].fno > 10 # (6)
      go_next_turn if @scores[score_index].finished?
    elsif @scores[score_index].current.state == :BEFORE_1ST # (7)
      go_next_turn
    end
  end

  def finished? # (8)
    @scores.reject(&:finished?) == []
  end

  def to_s # (9)
    "Game(id:#{@id}),\n#{@scores.join("\n")}"
  end
end

1. ゲームごとにユニークなIDをつけておく。

2. ゲームに参加するプレーヤーを登録するメソッド。そのプレーヤーの今回のゲーム分のスコアも用意する。

3. 現在プレー中のプレーヤー名を取得するメソッド。

4. 次のプレーヤーに交代するメソッド。登録したプレーヤーの順に進み、最後まで来たら最初のプレーヤーへ戻る。

5. ゲームを実行するメソッド。現在のプレーヤーのスコアクラスのscoring メソッドを呼び出して1フレーム分のプレーを記録する。

6. サービスフレームでは、2フレーム以上プレーする場合があるので、そのときは交代しない。

7. 現在のプレーヤーの現在の状態が「BEFORE_1ST」なら、次のフレームの投球待ちになっているので、プレーヤーを交代する。

8. すべてのプレーヤーがゲーム終了かどうか調べるメソッド。

9. ゲームの状況を文字列化するメソッド。

クラス図にもこの結果を反映しておきましょう（ 「Game」クラスを更新したクラス図 ）。 現在のプレーヤーは、関連端名が「turn」の関連によって参照しているScoreを使っています。

Figure 22. 「Game」クラスを更新したクラス図

ScoreSheetクラスの処理

「Game」クラスが作成できたので、スコアシートを扱う「ScoreSheet」クラスも作成できそうですね。 新しいスコアシートを作成して、そこに必要な数のゲームを追加すれば済みそうです。

この方式に合わせてスコアを記録する処理をする「Game」クラスは、 【Ruby】score.rb(7) のようになるでしょう。

【Ruby】score.rb(7)

# FrameクラスとScoreクラスとGameクラスの定義やそれ以前のコードがここにある

# ScoreSheetは、複数名の複数回のGameを記録する
class ScoreSheet
  attr_accessor :id, :time, :games

  def initialize(date) # (1)
    @id = SecureRandom.urlsafe_base64(8) # (2)
    @play_date = date
    @games = []
  end

  def add_game(games = 1) # (3)
    games.times do
      @games.append(Game.new)
    end
  end

  def to_s # (4)
    "Score Sheet Date: #{@time}(id:#{@id})"
  end
end

1. スコアシートを作成するときは、作成時の日時を控えておく。

2. スコアシートごとにユニークなIDをつけておく。

3. 希望する数のゲームをシートに追加するメソッド。引数がないときは1組だけ追加する。

4. スコアシートの状況を文字列化するメソッド。

クラス図にもこの結果を反映しておきましょう（ 「ScoreSheet」クラスを更新したクラス図 ）。 現在のプレーヤーは、関連端名が「turn」の関連によって参照しているScoreを使っています。

Figure 23. 「ScoreSheet」クラスを更新したクラス図

まとめ

ボウリングのゲームスコアを記録するスコアシートの振る舞いを検討しました。

振る舞いのモデルを作成した手順

振る舞いのモデルに登場する構成要素（状態、イベント、アクション）を洗い出し、ゲームの手順を整理しました。

スコアシートの振る舞いのモデルを作成した手順

1. スコアに関する状態の発見

   • スコアが記録されるときのフレームの変化を観察して、フレームにどのような状態があるか洗い出した。

2. スコアに関するステートマシン図の作成

   • 洗い出したフレームの状態に、関連するイベントやアクションを考えてステートマシン図に表した。

3. フレームスコアに関する状態の発見

   • ゲームを進めるときのスコアの変化を観察して、スコアにどのような状態があるか洗い出した。

4. フレームに関するステートマシン図の作成

   • サービスフレームの動作を観察して、通常のフレームを追加してスコアを記録する方法を発見した。

   • 洗い出したスコアの状態に関連するイベントやアクションを考えてステートマシン図に表した。

モデルとコードの対応づけは振る舞い設計の前に

ステートマシン図を使うことで、フレームやスコアの動作を表せました。 そして、あらかじめモデルとコードを対応づけておけば、それを前提として（モデルやコードの構成方式として）振る舞いの設計に活かせます。

モデルとコードが対応づけられていれば、Rubyのプログラムはステートマシン図から変換するように作成できます。 つまり、解決すべき課題があったとき、その課題を構造のモデルと振る舞いのモデルで表すことができれば、そのモデルなりのプログラムが作成できるわけです。 一方、このような方法で作成したプログラムが期待した動作をしない場合には、モデルが誤っているか、対応づけのルールに不備があるということです。

【参考】モデル変換とモデル駆動開発（MDD）

ここで示したようなモデルとコードの対応づけのほかに、モデルから別のモデルへ、あるいはコードから別のコードへといった対応づけも考えられます。 モデルからコードを生成する方法には、このチュートリアルのように図の要素とコードの要素を対応させるルールを決めて手で変換する方法以外にもあります。 例えば、コード片のテンプレート（スニペットなどと呼ばれます）にモデルのデータベースへの問い合わせを埋め込んだスクリプトを使って生成する方法はよく使われています

これらは、ソフトウエア設計における「モデル変換」と呼ばれています（コードも一種のモデル表現とみなせます）。 そして、モデル変換を用いて開発プロセスにおける各工程間をモデルで接続して開発する方法のことを「モデル駆動開発（MDD: Model Driven Development）」と呼びます。

モデル駆動開発を紹介している記事として次の記事があります。

モデル駆動開発におけるモデル変換の役割

https://codezine.jp/article/detail/10597

この記事では、モデル変換の繰り返しによる開発方法であることや、その実施例を紹介しています。