クラス図を書く上で大事なコツや事前にやっておくべき事

Question

現在ゲーム制作をしており
企画書→仕様書→フローチャート→クラス図
の順序で進めてきたのですが、クラス図を書くところで詰まってしまいました...
ゲームが将棋をベースにしている&クラス図の練習も兼ねてまず従来の将棋のクラス図を書こうと思ったのですが
これも上手くいきません。
具体的にはオブジェクト同士の関係をどのように構築していけば良いのか考えても手が止まってしまうのです。

何かコツや予めやっておくべき事等あれば教えていただきたいです。
非常に曖昧な質問となってしまい申し訳ありません。

Comments

[YAmaGNZ]

質問は編集できますので、今度からは新しく投稿しなおすのではなく質問を編集しましょう。

[m_etekusat]

確かに編集出来ますね...
申し訳ないです、少し慌ててしまいました。

Answer 1

企画書→仕様書→フローチャート→クラス図
の順序で進めてきたのですが

クラス図がリバースエンジニアリングでないなら、順序がおかしいです。
思考のパターンもこの通りなら、それが邪魔しているかもしれません。

通常は、
要件（企画書）→クラス図（機能仕様）→シーケンス図（フローチャート）
です。

クラス設計のポイントの一つとして、それぞれの相互関係(継承、集約、関連)を意識する事にあります。
UML辺りを切っ掛けに、そもそもクラス図とは何なのかの理解を深められた方が良いかと思います。

Comments

[m_etekusat]

なるほど...そもそも開発順序が違うのですね
個人的にクラス図は各パーツの情報&行動を記載し、かつパーツ同士の関係性を記した図だと認識しています。
なのでクラス図を書けば後はその通りにコーディングして行けば良いと思っていたので
順序も処理の流れを書くフローチャートから最も細かく記載するクラス図を書こうと考えていました。

実際には先にクラス図を書くようですが、何故処理の流れを最後に書くのでしょうか？
処理を書く=各オブジェクトにどのような役割が必要なのか分かると思うのですが、そもそも今私が考えているクラス図及びフローチャートの役割の認識が違うのでしょうか。

[sazi]

クラスで入出力の定義を行うのですから、それが決まらないと流れ（シーケンス・フロー）を決められないからです。

[sazi]

y=f(x)という関数があったとして、この関数のxやy（入出力）が定義されないと、流れは決められないですよね。
この関数をクラスと置き換えてみると考えやすいのではないでしょうか。

[sazi]

多分開発に選択した言語がオブジェクト指向言語で先ずクラスの定義を行う必要があって、それでクラス図を作ろうとされているのでは？

それであれば、仕様書を元にクラスの定義を行って行くという事になると思いますので、
やっぱりクラスとは何か？を理解されないと駄目だと思います。
当然観点が異なるので、仕様書とクラスが１：１にならない事もあるでしょうし。

[m_etekusat]

なるほど、確かにクラスは必須となっているのでそちらに引っ張られていました。

ありがとうございます。
やり直し、クラス図から考えてみます。