第6章 本当に大きな問題の解決
今まではせいぜい10個程度のクラスのアプリケーションを開発してきた。より大規模なアプリケーションの開発はどうやって行うのか?
→大きな問題も小さな問題と同じように解決する。
- 顧客が必要とする処理をソフトウェアが実行するようにする。
- オブジェクト指向の基本原則を適用し柔軟性を高める。
- 保守と再利用が可能な設計を追求する。
ソフトウェア開発はこれのイテレート。
大きな問題は小さな問題に分割して個別に対処する。本当に大きな問題を解決するために多くの小さな問題を解決する。
この章では、大きな問題を小さな問題に分割して解決していき、システムの全体像を把握する。
要件とFeature
システムがどのようなものであるのか(共通性)、またどのようなものでないのか(変動性)を把握する。 Featureと要件の意味や用語の用い方は人によって異なる。ここではFeatureは多くの要件が集まった1つの大きな機能を意味するものとする。
- 顧客からFeatureを得て、そのFeatureの実装に必要な要件を把握する。
顧客からのFeature | 要件 |
---|---|
様々な地形をサポートする | マスは地形と関連付けられる。 ゲームデザイナーは独自に地形を作成することができる。 各地形、ユニットの移動に影響する特質がある。 |
- Featureまたは要件の一覧を用いて、システムが実行する必要のある大きなことを把握する。
ゲームシステムワーク Feature一覧 |
---|
1. 様々な地形をサポートする。 2. 様々な時間軸をサポートする。 3. ゲームごとに異なる複数の種類の軍隊やユニットをサポートする。 4. 作戦や戦闘を追加するための、アドオンモジュールをサポートする。 5. 正方形のマスで構成される盤を1枚提供し、各マスには地形が存在する。 6. 誰のターンであるかを制御する。 7. 基本的な移動を管理する。 |
ユースケースとユースケース図
ユースケースは詳細であり全体像を提示することはない。システムに必要とされる処理の詳細が決まっていない状態では、ユースケースを作成することで全体像を見失う危険がある。
ここでは詳細には立ち入らずシステムがどのようなものであるのか全体像を把握するためにユースケース図を作成する。
Featureをユースケース図に当てはめて、ユースケースがFeatureを網羅することを確認する。
- 単純なユースケース図
アクターは人である必要はない。またアクターはシステムを使うのであってシステムの一部ではない。