回答編集履歴
3
図表追加
test
CHANGED
|
@@ -1,4 +1,18 @@
|
|
|
1
1
|
小さなシステムしか作ったことがない者の個人的な意見ですが、私がシステムを組む場合は、初期化や入力や集計処や出力などの各種の処理を縦軸に、ファイルや画面デザインや印刷デザインを横軸に並べたプロセスマトリックスチャートを作ってから開発します。そしてそれぞれのファイルや画面デザインなども大まかなデザインを描いておきます。開発しながらの多少の仕様変更もおこりますが、システムの全体像が見えていれば修正点と影響箇所が見渡しやすいので、臨機応変に対処できます。
|
|
2
|
+
|
|
3
|
+
|
|
4
|
+
|
|
5
|
+
ちなみに６年前にAccessで開発したe-ラーニングシステムのチャートが下図です。
|
|
6
|
+
|
|
7
|
+
|
|
8
|
+
|
|
9
|
+
|
|
10
|
+
|
|
11
|
+
フレームワークによるMVCモデルではないですが、システムの全体像を俯瞰する意義は共通すると思います。
|
|
12
|
+
|
|
13
|
+
一応、もう少し機能を単純化したIIS上で働くASPスクリプトでWebシステム向けのバージョンも開発しました。
|
|
14
|
+
|
|
15
|
+
|
|
2
16
|
|
|
3
17
|
その手順からすれば、モデルもビューも同様にある程度形になっていた方が、処理で扱いやすいと思います。
|
|
4
18
|
|
2
文章校正
test
CHANGED
|
@@ -4,4 +4,4 @@
|
|
|
4
4
|
|
|
5
5
|
質問の内容によれば、モデルの正規化やグループ集計用のキー項目の工夫などの必要性が後で浮かび上がってきて、蒸し返しが多発する可能性があり、その点をご心配なのでしょう。
|
|
6
6
|
|
|
7
|
-
逆にビューを明確にするとシステムの目的が理解しやすくなるので、それを狙ってビューを最初に固める方針ではないかと思われます。ビューもモデルもその他のシステムのエンティティもある程度は形にしておくとよいでしょう。さらに、改善点に気付いた
|
|
7
|
+
逆にビューを明確にするとシステムの目的が理解しやすくなるので、それを狙ってビューを最初に固める方針ではないかと思われます。ビューもモデルもその他のシステムのエンティティもある程度は形にしておくとよいでしょう。さらに、改善点に気付いたときにその修正箇所と影響範囲を見通せるように、モデルとビューとそれに対応するコントローラとの関連性をチャート化しておけば、ある程度はオーバーヘッドも想定して手当てできるのではないでしょうか。
|
1
文章校正
test
CHANGED
|
@@ -4,4 +4,4 @@
|
|
|
4
4
|
|
|
5
5
|
質問の内容によれば、モデルの正規化やグループ集計用のキー項目の工夫などの必要性が後で浮かび上がってきて、蒸し返しが多発する可能性があり、その点をご心配なのでしょう。
|
|
6
6
|
|
|
7
|
-
逆にビューを明確にするとシステムの目的が理解しやすくなるので、それを狙ってビューを最初に固める方針ではないかと思われます。ビューもモデルもその他のシステムのエンティティもある程度は形にしておくとよいでしょう。さらに、改善点に気付いたら、その修正箇所と影響範囲を見通せるように、モデルとビューと、それに対応するコントローラとの関連性をチャート化しておけば、ある程度はオーバーヘッドも想定して、していけばうまくいくのではないでしょうか。
|
|
7
|
+
逆にビューを明確にするとシステムの目的が理解しやすくなるので、それを狙ってビューを最初に固める方針ではないかと思われます。ビューもモデルもその他のシステムのエンティティもある程度は形にしておくとよいでしょう。さらに、改善点に気付いたら、その修正箇所と影響範囲を見通せるように、モデルとビューと、それに対応するコントローラとの関連性をチャート化しておけば、ある程度はオーバーヘッドも想定して、手当てしていけばうまくいくのではないでしょうか。
|