回答編集履歴

4

fix

2019/02/15 09:27

投稿

yohhoy
yohhoy

スコア6189

test CHANGED
@@ -6,11 +6,11 @@
6
6
 
7
7
 
8
8
 
9
- 設計フェーズは必ず **トップダウン方式** になると思います。つまり大きな目的「これは何を解決するプログラムなのか?」から始まり、次に「このプログラムの入出力は何か」「どんなアルゴリズム・データ構造を使うか」「ユーザから何を受け取る/何を見せるか」のように詳細化していきます。特殊ケースへの対処についてあれこれ考えるのは、これらの基本方針が固まった後が望ましいです。
9
+ 設計フェーズは必ず **トップダウン方式** になると思います。つまり大きな目的「これは何を解決するプログラムなのか?」から始まり、次に「このプログラムの入出力データは何か」「ユーザから何を受け取る/何を見せるか」「どんなアルゴリズム・データ構造を使うか」のように詳細化していきます。特殊ケースへの対処についてあれこれ考えるのは、これらの基本方針が固まった後が望ましいです。
10
10
 
11
11
 
12
12
 
13
- 一方で、「ソフトウェア計を隅々まで終わらせてから、具体的なプログラム実装を始める」というやり方は大抵上手く行きません。プログラムを作り始めるまで設計上の問題に気づかない、ということはよくあります。ソフトウェア設計は、あくまでも **これから自分が何を作ろうとしているのか見失わない** ための道具として捉えるべきです。
13
+ 一方で、「ソフトウェア計を隅々まで終わらせてから、具体的なプログラム実装を始める」というやり方は大抵上手く行きません。プログラムを作り始めるまで設計上の問題に気づかない、ということはよくあります。ソフトウェア設計は、あくまでも **これから自分が何を作ろうとしているのか見失わない** ための道具として捉えるべきです。
14
14
 
15
15
 
16
16
 

3

fix

2019/02/15 09:27

投稿

yohhoy
yohhoy

スコア6189

test CHANGED
@@ -10,7 +10,7 @@
10
10
 
11
11
 
12
12
 
13
- 一方で、「プログラム設計を隅々まで終わらせてから、具体的なプログラム実装を始める」というやり方は大抵上手く行きません。プログラムを作り始めるまで隠れた課題に気づかない、ということはよくあります。プログラム設計は、あくまでも **これから自分が何を作ろうとしているのか見失わない** ための道具として捉えるべきです。
13
+ 一方で、「ソフトウェア計を隅々まで終わらせてから、具体的なプログラム実装を始める」というやり方は大抵上手く行きません。プログラムを作り始めるまで設計上の問題に気づかない、ということはよくあります。ソフトウェア設計は、あくまでも **これから自分が何を作ろうとしているのか見失わない** ための道具として捉えるべきです。
14
14
 
15
15
 
16
16
 

2

update

2019/02/15 09:26

投稿

yohhoy
yohhoy

スコア6189

test CHANGED
@@ -22,7 +22,15 @@
22
22
 
23
23
 
24
24
 
25
- フローチャート(Flowchart)は、まさにソフトウェア設計の道具の1つです。ただし、最近のプログラミング言語では必ずしもフローチャートを作る意義は薄くなっているように思います。というのも、フローチャートはプログラミング言語自身の表現能力が貧弱な時代に開発された道具であり、モダンなプログラミング言語ではあえて図示しなくともプログラム処理の流れ(=フローチャートが表現する情報)を簡潔に記述できます。(図の方が分かりやすい/ソースコードの方が分かりやすいといった個人差はあります)
25
+ フローチャート(Flowchart)は、まさにソフトウェア設計の道具の1つです。ただし、最近のプログラミング言語では必ずしもフローチャートを作る意義は薄くなっているように思います。というのも、フローチャートはプログラミング言語自身の表現能力が貧弱な時代に開発された道具であり、モダンなプログラミング言語ではあえて図示しなくともプログラム処理の流れ(=フローチャートが表現する情報)を簡潔に記述できます。
26
+
27
+
28
+
29
+ 一般に、文字(プログラム)よりも図の方が大まかな構造を表現するのに向いていますから、初心者向けの説明ではとっつきやすさを重視してフローチャートが良く用いられるようです。
30
+
31
+
32
+
33
+ (※ 個人差や好みがありますから、フローチャートを全否定する意図はありません。)
26
34
 
27
35
 
28
36
 
@@ -35,3 +43,5 @@
35
43
 
36
44
 
37
45
  - [ソフトウェア設計が重要である理由](https://postd.cc/why-software-design-is-important/)
46
+
47
+ - [ソフトウェア設計のすすめ](https://www.slideshare.net/sifue/ss-40756807)

1

update

2019/02/15 09:23

投稿

yohhoy
yohhoy

スコア6189

test CHANGED
@@ -14,9 +14,19 @@
14
14
 
15
15
 
16
16
 
17
- (※ 本回答ではSI企業で行われるような大規模システム開発は想定しません。)
17
+ (※ 本回答ではSI企業で行われるような大規模システム開発は想定しません。)
18
18
 
19
19
 
20
+
21
+ ----
22
+
23
+
24
+
25
+ フローチャート(Flowchart)は、まさにソフトウェア設計の道具の1つです。ただし、最近のプログラミング言語では必ずしもフローチャートを作る意義は薄くなっているように思います。というのも、フローチャートはプログラミング言語自身の表現能力が貧弱な時代に開発された道具であり、モダンなプログラミング言語ではあえて図示しなくともプログラム処理の流れ(=フローチャートが表現する情報)を簡潔に記述できます。(図の方が分かりやすい/ソースコードの方が分かりやすいといった個人差はあります)
26
+
27
+
28
+
29
+ ----
20
30
 
21
31
 
22
32