回答編集履歴
4
fix
answer
CHANGED
|
@@ -2,9 +2,9 @@
|
|
|
2
2
|
|
|
3
3
|
「ソフトウェア設計」について学習・習得されると良いのではないでしょうか。一口に 設計(Design) といっても、作りたいプログラムの規模や種類によって必要な道具(表現方法)やスキルは異なります。
|
|
4
4
|
|
|
5
|
-
設計フェーズは必ず **トップダウン方式** になると思います。つまり大きな目的「これは何を解決するプログラムなのか？」から始まり、次に「このプログラムの入出力
|
|
5
|
+
設計フェーズは必ず **トップダウン方式** になると思います。つまり大きな目的「これは何を解決するプログラムなのか？」から始まり、次に「このプログラムの入出力データは何か」「ユーザから何を受け取る／何を見せるか」「どんなアルゴリズム・データ構造を使うか」のように詳細化していきます。特殊ケースへの対処についてあれこれ考えるのは、これらの基本方針が固まった後が望ましいです。
|
|
6
6
|
|
|
7
|
-
一方で、「ソフトウェア計を隅々まで終わらせてから、具体的なプログラム実装を始める」というやり方は大抵上手く行きません。プログラムを作り始めるまで設計上の問題に気づかない、ということはよくあります。ソフトウェア設計は、あくまでも **これから自分が何を作ろうとしているのか見失わない** ための道具として捉えるべきです。
|
|
7
|
+
一方で、「ソフトウェア設計を隅々まで終わらせてから、具体的なプログラム実装を始める」というやり方は大抵上手く行きません。プログラムを作り始めるまで設計上の問題に気づかない、ということはよくあります。ソフトウェア設計は、あくまでも **これから自分が何を作ろうとしているのか見失わない** ための道具として捉えるべきです。
|
|
8
8
|
|
|
9
9
|
（※ 本回答ではSI企業で行われるような大規模システム開発は想定しません。）
|
|
10
10
|
|
3
fix
answer
CHANGED
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
|
|
5
5
|
設計フェーズは必ず **トップダウン方式** になると思います。つまり大きな目的「これは何を解決するプログラムなのか？」から始まり、次に「このプログラムの入出力は何か」「どんなアルゴリズム・データ構造を使うか」「ユーザから何を受け取る／何を見せるか」のように詳細化していきます。特殊ケースへの対処についてあれこれ考えるのは、これらの基本方針が固まった後が望ましいです。
|
|
6
6
|
|
|
7
|
-
一方で、「
|
|
7
|
+
一方で、「ソフトウェア計を隅々まで終わらせてから、具体的なプログラム実装を始める」というやり方は大抵上手く行きません。プログラムを作り始めるまで設計上の問題に気づかない、ということはよくあります。ソフトウェア設計は、あくまでも **これから自分が何を作ろうとしているのか見失わない** ための道具として捉えるべきです。
|
|
8
8
|
|
|
9
9
|
（※ 本回答ではSI企業で行われるような大規模システム開発は想定しません。）
|
|
10
10
|
|
2
update
answer
CHANGED
|
@@ -10,10 +10,15 @@
|
|
|
10
10
|
|
|
11
11
|
----
|
|
12
12
|
|
|
13
|
-
フローチャート(Flowchart)は、まさにソフトウェア設計の道具の1つです。ただし、最近のプログラミング言語では必ずしもフローチャートを作る意義は薄くなっているように思います。というのも、フローチャートはプログラミング言語自身の表現能力が貧弱な時代に開発された道具であり、モダンなプログラミング言語ではあえて図示しなくともプログラム処理の流れ（＝フローチャートが表現する情報）を簡潔に記述できます。
|
|
13
|
+
フローチャート(Flowchart)は、まさにソフトウェア設計の道具の1つです。ただし、最近のプログラミング言語では必ずしもフローチャートを作る意義は薄くなっているように思います。というのも、フローチャートはプログラミング言語自身の表現能力が貧弱な時代に開発された道具であり、モダンなプログラミング言語ではあえて図示しなくともプログラム処理の流れ（＝フローチャートが表現する情報）を簡潔に記述できます。
|
|
14
14
|
|
|
15
|
+
一般に、文字（プログラム）よりも図の方が大まかな構造を表現するのに向いていますから、初心者向けの説明ではとっつきやすさを重視してフローチャートが良く用いられるようです。
|
|
16
|
+
|
|
17
|
+
（※ 個人差や好みがありますから、フローチャートを全否定する意図はありません。）
|
|
18
|
+
|
|
15
19
|
----
|
|
16
20
|
|
|
17
21
|
下記の読み物（記事）もご参考にどうぞ：
|
|
18
22
|
|
|
19
|
-
- [ソフトウェア設計が重要である理由](https://postd.cc/why-software-design-is-important/)
|
|
23
|
+
- [ソフトウェア設計が重要である理由](https://postd.cc/why-software-design-is-important/)
|
|
24
|
+
- [ソフトウェア設計のすすめ](https://www.slideshare.net/sifue/ss-40756807)
|
1
update
answer
CHANGED
|
@@ -6,9 +6,14 @@
|
|
|
6
6
|
|
|
7
7
|
一方で、「プログラム設計を隅々まで終わらせてから、具体的なプログラム実装を始める」というやり方は大抵上手く行きません。プログラムを作り始めるまで隠れた課題に気づかない、ということはよくあります。プログラム設計は、あくまでも **これから自分が何を作ろうとしているのか見失わない** ための道具として捉えるべきです。
|
|
8
8
|
|
|
9
|
-
（※ 本回答では
|
|
9
|
+
（※ 本回答ではSI企業で行われるような大規模システム開発は想定しません。）
|
|
10
10
|
|
|
11
|
+
----
|
|
11
12
|
|
|
13
|
+
フローチャート(Flowchart)は、まさにソフトウェア設計の道具の1つです。ただし、最近のプログラミング言語では必ずしもフローチャートを作る意義は薄くなっているように思います。というのも、フローチャートはプログラミング言語自身の表現能力が貧弱な時代に開発された道具であり、モダンなプログラミング言語ではあえて図示しなくともプログラム処理の流れ（＝フローチャートが表現する情報）を簡潔に記述できます。（図の方が分かりやすい／ソースコードの方が分かりやすいといった個人差はあります）
|
|
14
|
+
|
|
15
|
+
----
|
|
16
|
+
|
|
12
17
|
下記の読み物（記事）もご参考にどうぞ：
|
|
13
18
|
|
|
14
19
|
- [ソフトウェア設計が重要である理由](https://postd.cc/why-software-design-is-important/)
|