アプリケーションの設計を考える

今回のパートでは、作成するアプリケーションの全体像を把握します。

設計の必要性について

アプリケーションを作成する際は コードを書く前に設計 をすることをオススメします。

設計を予めしておくことで、コードを書いている途中で手戻りやコードを大きく変更する必要をある程度なくすことが出来ます。

実際、業務では開発する前に設計書を書きます。要件定義書からテスト仕様書まで多岐にわたる設計書が必要になります。これらはチーム開発のみならず、個人の開発でも必要だと思います。

ですが、設計にはスキルや慣れが必要です。

本教材は初学者を対象としているので、完璧な設計は難しいと思います。そのため、作りながら設計を修正していく形にします。

各章で設計が変わるのでそこにも注目してみてください。

では、今回は以下の手順で設計をしていきましょう。※あくまで簡略なドキュメントです。

1. 今回作るアプリケーションの要件定義
2. 処理の流れを整理する
3. 必要な機能の洗い出し
4. 必要なクラスの洗い出し
5. クラス設計を考える

また、視覚的にわかりやすくするために今回は UML を使用します。

UML とは・・・ソフトウェアの機能や構造を 2 次元の図に表現するためのもの。

1.今回作るアプリケーションの要件定義

今回作るファイナルファンタジー風のアプリケーションの要件を定義していきます。

• 敵(複数)と主人公・仲間が戦う
• それぞれのキャラクター(敵含む)は異なる HP・攻撃力・魔法攻撃力を持つ
• 主人公・仲間はジョブという役割をもっており、スキルが使える
• ジョブは「勇者」「黒魔道士」「白魔道士」
• ターン制バトル
• それぞれのキャラクターは 1 ターンに 1 度だけ行動する
• 攻撃対象はランダム。ただし、すでに HP が 0 のキャラクターは対象としない
• ジョブを持つキャラクターは通常攻撃の代わりに一定確率でスキルを発動する
• 主人公・仲間 → 敵 の順で行動する
• どちらかのパーティが全滅するまで戦う

こんなところでしょうか。

2.処理の流れを整理する

処理の流れを表すのはアクティビティ図がわかりやすいです。

お互いのステータス表示の後、攻撃をします。

主人公側が全滅の場合、「Game Over...」と表示され、敵側が全滅の場合は、「ファンファーレ」と表示されます。

「A」となっている箇所はつながっています。つまりどちらも全滅でない場合は繰り返されます。

3. 必要な機能の洗い出し

アプリケーションに必要な機能を考えていきましょう。

アクティビティ図から抜き出すとわかりやすいです。

• ステータスの表示
• 攻撃
• スキルの発動
• 全滅かどうかのチェック

4. 必要なクラスの洗い出し

ここで、オブジェクト指向のメインである、クラスが登場します。

クラスは設計書のようなもので、同じ変数や関数を持つ オブジェクト を作るのに使います。

オブジェクト とはここでいう、登場するキャラクター(敵も含む)と同義だと思ってください。

アクティビティ図からも分かる通り、以下の２つのクラスが必要なことがわかります。

• 主人公・仲間クラス
• 敵クラス

5. クラス設計を考える

実際に次章からクラスの設計をしていきます！

以上で今回のパートは終了です。