プログラムの設計にするときに初めからプログラム全体の詳細に考えたり、具体的なことを考えることは不可能といって良いでしょう。
例えば、一つのコンパイル単位となる、数百から千数百行のプログラム(プログラミング)を設計するときに、いきなりコーディングできるような細かく設計していくことは不可能です。
プログラム開発の経験している方なら誰でも分かると思います。
実際にプログラム(プログラミング)の問題を修正するときに、まず、大まかな処理の手順を考えるのが自然だと思います。
次に、その大まかな処理を細かい処理の手順に分け、これを繰り返していき、さらに細かく設計をしていきます。
プログラム(プログラミング)に要求された問題を解決するために、全体としてどのように実現すればよいのか検討します。
まずは、問題解決を実現するための要素を大まかに洗い出して、抽出した要素間に実行順序を考慮した順次、選択、反復などの制御プログラムを付加します。
検討の結果、プログラム(プログラミング)の問題を実現するために個々の機能が明らかにし、要素を洗い出すときに、その規模や性質などを考えて出来るだけ対等になるようにします。
また、大きい問題のプログラム(プログラミング)を設計するとき、抽出した要素はプログラムの問題の大きさに比例して粗くなっていきます。
第1段階で明らかになった個々の機能で詳細化が必要な機能を一つずつ取り上げて、個々についてどのように実現したら良いのか検討します。
この段階の検討も第1段階と同じく「要素の抽出」と「制御の付加」を行い、これによって第2段階の機能が明らかになります。
第3段階以降は、前の段階によって明らかになった個々の機能について、第2段階と同じく検討を繰り返すことになります。
このようにして、進めていけば最終的にコーディングすることができる詳細まで到達することができるのです。
与えられた問題からいきなり具体的なことを考えることは不可能なので、最初は抽出すべき要素やその要素の性質を抽象的なレベルで考えて行き、個別に具体化していくことで、一度に考える範囲を限定し、設計を進めることができるのです。
範囲を限定して考えることで、設計を行っている範囲に関係がない情報を考慮する必要がなくなり、設計している範囲の独立性が高まり、局所化し易くなるのです。
検討している範囲よりさらに細かい事項を保留しておき、1段階下のレベルまで延期する事ができます。
そのため、同時に検討する複数の項目は重要度や質などを同じものにすることができ、効率の良い検討をすることができるのです。
段階的詳細化によって設計された末端の処理は単純で、独立性が高く、わかり易いものになっています。
最後に構造化された、わかりやすいプログラムの設計方法についてまとめると「段階的詳細化+基本三構造の組み合わせ」で行うことが良いでしょう。
しかし、基本三構造ばかりのとらわれて形式的な構造化を行ったりすると、返って分かり易さを損なう恐れがあります。
読みやすさを最大の要件と考え、制御構造全体として確保することが大切だと思います。
趣味でプログラム(プログラミング)を作らない限り、現場ではフローチャートや木構造チャートなどのプログラム図を作成してからプログラム(プログラミング)をコーディングすることが当たり前になっています。
設計しながらプログラム(プログラミング)をコーディングするのではなく、まず最初にプログラム図を書いて設計を行い、論理的に正しいと確信を持ってからコーディングを行うようにします。
その方が正しく動作するプログラム(プログラミング)を作成する近道だと思います。
設計しながら作成したプログラム図がそのまま設計ドキュメントとなり、詳細なドキュメントはデバッグやプログラム(プログラミング)の保守をする際に役に立つのです。
一般的にプログラム図は特定の言語に依存しないで記述することができ、詳細設計段階ではプログラミング言語(プログラミング)に捉われない論理を追及することができるのです。
プログラム図で作成した詳細な設計ドキュメントさえあれば、バグの性質を簡単に見分けることができます。
Last update:2019/3/20
『プログラミング 設計』 最新ツイート
このサイトはリンクフリーです。