ブラックジャックの設計手法例
先日の記事でBlackJackプログラムを一応書いたのですが、設計を考えておらずかつ、一つのクラスで作ってしまったので、今回は「UMLモデリングの本質」の本を読んでソフトウェア設計をしてみたいと思います。
要求分析
初めに、上記の記事で軽く今回作る仕様を羅列しましたが、その仕様をまとめて要求分析を行います。
Qiitaにあったプログラミング初級者の卒業プログラムとして、BlackJackプログラムを作成することにした。 今回作成するBlackJackは、プレイヤーとディーラーの１体１の対戦形式となっている。 初めに両者に山札からカードを２枚ずつ配り、その後各一人ずつ山札からカードを引く。引くカードはカードの合計が２１を超えない限り何枚引いても良い。 お互いカードを引き終えたら、場にカードを出しよりカードの合計数値が２１に近いほうが勝ち。 細かい制約としては * ディーラーの1枚目のカードは知ることができるが、2枚目以降のカードをわからない * プレイヤーがカードを山札から引く際、21を超えたらバーストと扱い自動的に負けとする * 絵札(J、Q、K)は10として扱い、Aは1として扱う * その他のルール（ダブルダウン、スプリット、サレンダー）はなし
型図作成
型図と呼ばれる、概念の構造を記述した図のことでUML記法では「クラス図」と呼ばれるものに似ているみたいです。 まず型図を作成するために、BlackJackシステムに出てくる概念をまとめてみます。
プレイヤー、ディーラー、山札、カード、手札、カードの合計数値、絵札、A（エース）、バースト...
概念の候補として上記のようなものが挙げられます。 この中から必要だと思われる要素をピックアップして、型図（クラス図）を作成してみます。
中心部分からどのような関係となるか考える始めるのが良いみたいです。なのでブラックジャックの中心部分、プレイヤーとディーラーの関係から考え始めました。 そして、完成した型図として下記のような形になりました。
今回図の作成に使用したツールはastah* communityというツールです。 http://astah.change-vision.com/ja/product/com-announcement.html
上記のツールは旧バージョン(Ver6.9)を無償で使用できます（最新版Ver7.0～は非商用に限り使用）。また、2018年9月26日で公開終了となるらしいので、学習用として使用を考えている方はお早めにダウンロードして置くことをおすすめします。
ここから汎化や継承など、改良を加えていくのですが、今回は簡単な例なのでこの図で進めていこうと思います。なにか問題があれば修正を加えます。
アクティビティ図
次にアクティビティ図と呼ばれるフローチャートと似たようなもので、処理の流れやプログラムの実行の流れなどを表す図を作成していきます。
先程の型図（クラス図）は静的な側面を捉えるのに向いていますが、アクティビティ図は動的な側面を捉えます。 動的な側面を捉えることで、型図の型のインスタンスの生成や消滅などの動的な変化に気づき、必要な機能が見えてきます。
今回のブラックジャックのプログラムのアクティビティ図を下記のようにしました。
アクティビティ図の書き方に確定した方法論はないのですが、処理の流れを想像、またはインタビューで聞き出し、アクティビティのそれぞれの単位を分かりやすく、最小の単位で書くこと重要です。
ユースケース図
次にユースケース図(use case)を作成します。ユースケース図は今回作成するブラックジャックプログラムを利用するユーザとシステムとのやり取りを描きます。
ユースケース図を作成するとどのような機能が必要なのかが見えてきます。
作成した図は以下のとおりです。
複雑なシステムになると図だけではなく、ユースケースごとに詳細な説明を箇条書きなどで記述したものなどがあると分かりやすくなります。
シーケンス図
次にシーケンス図を作成します。 シーケンス図はクラス間やオブジェクト間のやりとりを表現する図で、これを作成すると、それぞれのクラスがどのような機能を持ち、どの様に関わってくるのかが可視化されます。
作成した図がこちらです。
作成していた思ったのですが、結構UML図のことがうろ覚えなのでもしかして記法が間違っているかもしれないので、ご指摘頂けると幸いです。
etc
一旦今回作成する図は以上で完成ですが、複雑なシステムになると他にも色々な図が登場してきます。
- コンポーネント図
- 物理的な構成要素からシステムの構造を記述できる図
- パッケージ図
- パッケージ同士の依存関係を描画することで論理的なグルーピングをするための図
- ステートマシン図
- 状態遷移図と呼ばれるオブジェクトの状態を記述した図
それぞれシステムやプロジェクトに合わせて対応を決めれば良いと思います。
一旦設計ができたので、次はプログラムに起こしていこうと思いますが、少し長くなってしまうので、次回の記事に分けようと思います。
