フローチャート以外の設計方法

大学で初めてＣ言語プログラミングを習い、
授業が終わってからもＣ言語の書籍をいくつか読みました。

その力試しとしてトランプゲームのブラックジャックの
プログラムを作ってみようと思いました。

その過程でフローチャートを用いて設計してみたのですが
条件分岐がぐちゃぐちゃだったり、gotoを使わなければならなかったり
とてもまともなコードが書けるような代物ではありませんでした。

確かに読んだ本の中で
「フローチャートは設計するために使ってはいけない」
という内容がありました。
ですがそれらの本ではフローチャートはいけないというだけで
具体的にどのような設計方法を用いればよいか読み取れませんでした。

そこでみなさんに質問なのですが、
一通りプログラミング言語の文法を理解したプログラミング初心者が
こんなプログラムを作りたいと思ってから
（たとえば簡単なトランプゲームなど）
実際にソースコードを書くまでには
どのような方法でどのような手順を踏んだらよいのでしょうか？
教えてください。よろしくお願いします。

No.1 ベストアンサー 回答者： galluda 回答日時： 2007/11/26 23:32

がると申します。

んと…書き込んでおいてなんなのですが、そこそこの年数プロやってるとどうしても「初心者さんのわからない部分」がわからないので、ってのはあるのですが。

普段私もやって下の子にも教えてるのが
・まずコメント書け
です。

例えばブラックジャックなら…とりあえず「終了条件が発生するまで何度も同じゲームを繰り返す」ものですよね？
なので、まず

// 終了条件が発生するまで
while(終了条件が発生していない) {
}

と書いてしまいます。
で…とりあえず「１対１のブラックジャック」を想定すると。
・カードを配って特定条件でカード配るのをやめて勝負
ですよね？
なので

while(終了条件が発生していない) {
　while(親子の最低どっちかがカード欲しい) {
　　if(子がカード欲しい) {
　　　子供がカードを取得する処理
　　}
　　if(親がカード欲しい) {
　　　親がカードを取得する処理
　　}
　}
　/* 勝負 */
　子供のカードの数字計算
　親のカードの数字計算
　if(子供が勝った) {
　　子供が勝った時の処理
　}
　if(親が勝った) {
　　親が勝った時の処理
　}
　if(ドロー) {
　　ドローの処理…ですが、多分これって親が勝った時の処理ですよね？
　}
}

ってな感じでかいていきます。
で、各場所まずは「何をやりたいかを書いて」から、日本語部分を「コメント化して読みやすく文章を整形して」「コーディング」していくと、案外に楽に組める…と思うのですが。
実際のところ初心者さんにはどうでしょうか？

以上…あまり参考になるのか自信が持てないのですが。参考の参考、くらいにでもなれば幸いです。

No.4 回答者： nak777r 回答日時： 2007/11/29 02:35

C言語で goto を使っていいのは、きれいなフローチャートが

思い描ける人だけです

条件分岐がぐちゃぐちゃだったり gotoを使わなければならない
状態になった事をフローチャートのせいにしないで
まず、きれいなフローチャートになるように再度考えてみてください
ぐちゃぐちゃになるなら、ぐちゃぐちゃにならないように関数化
して分割していけばいいのですよ

No.3 回答者： R32C 回答日時： 2007/11/27 17:13

UMLでステートチャートあたりを使うといいのではないでしょうか？

ステートマシンを想定して作ればロジックは比較的単純にできると
思います。
http://homepage1.nifty.com/BROKEN/project/humano …

まずjudoで適当な図を書いてみるのもいいかと思います。

http://jude.change-vision.com/jude-web/product/c …

No.2 回答者： uki629 回答日時： 2007/11/27 12:22

>gotoを使わなければならなかったり

これは絶対にやってはいけない。

>確かに読んだ本の中で
>「フローチャートは設計するために使ってはいけない」
>という内容がありました。
昔ながらの構造化型のプログラミング言語においては
プログラムの流れを勉強する上ではいいけど実際に
業務でいちいちフローチャートを全部書いていたら
えらいことになりますよ。

>ですがそれらの本ではフローチャートはいけないというだけで
>具体的にどのような設計方法を用いればよいか読み取れませんでした。
最近のオブジェクト指向ならUML


>（たとえば簡単なトランプゲームなど）
>実際にソースコードを書くまでには
>どのような方法でどのような手順を踏んだらよいのでしょうか？
簡単なプログラムで業務としてではなくてメンテナンス性が必要ないプログラムなら簡単な機能分割して機能説明を書いた関数orクラス表を作ってそのまま作業開始
業務でも簡単なものは関数orクラス表作って後はソースのコメントですます。
小さいプログラムに対して仕様書を核時間が無駄。で効率が悪い。
はっきりいってコメントで十分。