前にやっていた
シリーズ化してしまいつつある
情報処理における学会と産業界というのは、かなり距離がある。
したがって、2つの間に関連性がありながら、
学界的に「それは違う」と排除してしまい、
産業界的にも、学界的にも、豊かな研究分野・実践を
踏みにじってしまうことがある。
って話、久々につづき。
前回の最後にこう書いた。
実は、大学のソフトウェア工学の教育方法と
現場との違いは、根本的な相違点がある。
それは、
パターンっていうのは、計算機工学の考え方の基本なんだよ!
http://blog.goo.ne.jp/xmldtp/e/0cf44129a90e47cefa3ac5d3d7a04f75
に書いたことでもあるんだけど、
ダック・タイピングを認めるか否か
が決定的な違いになる。大学の教育は、抽象から演繹的に落としていき、具体になっていく。
それに対し、現在の開発は、ダッグタイピングを認め、帰納的、ないしはアブダクションによって意思決定していくことが多い(たぶん、演繹的に考えるより多い)
今日は、それについて
■大学の教え方は、トップダウンで、途中、切れる
大学の教え方は、トップダウンである。
まず、開発工程全体に触れ
その工程をどのようにこなすかについて説明する
・ウォーターフォール
・スパイラル
などなど。
その後、各工程について詳細化していく
・要求
・(外部・詳細)設計
・実装
・テスト
そして、ソフトウェア工学の授業で、
要求・設計・テストを中心に行う(テストは大学によっては触れないかも)
要求仕様は、機能要件抽出方法として、ユースケースについて
設計方法としては、
オブジェクト指向分析と構造化手法分析
構造化手法では
DFDとER図
オブジェクト指向では
UMLのクラス図と状態図、シーケンス図
(なぜか、アクティビティ図はそんなに人気ない)
で、なぜか、実装はプログラミングの授業が別に有り
テストをやる学校は、テストについて教わる。
このように、トップダウンに詳細化していくので、
当然クラスは、継承を使って、詳細化していく。
で、気づいただろうか・・・
画面とかDBの話には結び付かない。これらは。直接。
だから、大学の授業では、トップから詳細化していくけど、
画面とかDBの設計にまでは降りてこない(アクティビティ図もないし)
で、いきなり、プログラミングの授業でプログラムする。
■最近の開発は、ボトムアップ
実際の開発では、仕事の流れが重視される。
そして、画面設計がされ、画面がきまると、フレームワークによって、
ある程度の開発方針が立つ。
データに関しては極論すると、画面や帳票で必要なデータをDBに入れればよい
ということになり、画面や帳票から設計することも可能である。
まさに、ユーザー主導のボトムアップ開発
したがって、継承は、個々の要素の共通部分を抽象化し、その抽象化されたものから
継承する形になる。
抽象化されたものの中にさらに抽象化できるものがあれば、さらに継承
と、ボトムアップ、帰納的になってくる。
このように、継承をボトムアップにつくるとなると、トップダウンで継承はできないから、
ダッグタイピングのような、継承を回避できるテクニックは、だいじなわけだ。
つまり、トップダウンとボトムダウンがmeetするポイントは、
「画面」「帳票」といった、UI等
になるのだが、
大学の授業はトップから始めて、そこまで降りてこない。
企業の開発は、そこから始まり、あまり抽象度を上げない(上げる必要がない)
っていうことで、ギャップができてしまうのだ・・・
シリーズ化してしまいつつある
情報処理における学会と産業界というのは、かなり距離がある。
したがって、2つの間に関連性がありながら、
学界的に「それは違う」と排除してしまい、
産業界的にも、学界的にも、豊かな研究分野・実践を
踏みにじってしまうことがある。
って話、久々につづき。
前回の最後にこう書いた。
実は、大学のソフトウェア工学の教育方法と
現場との違いは、根本的な相違点がある。
それは、
パターンっていうのは、計算機工学の考え方の基本なんだよ!
http://blog.goo.ne.jp/xmldtp/e/0cf44129a90e47cefa3ac5d3d7a04f75
に書いたことでもあるんだけど、
ダック・タイピングを認めるか否か
が決定的な違いになる。大学の教育は、抽象から演繹的に落としていき、具体になっていく。
それに対し、現在の開発は、ダッグタイピングを認め、帰納的、ないしはアブダクションによって意思決定していくことが多い(たぶん、演繹的に考えるより多い)
今日は、それについて
■大学の教え方は、トップダウンで、途中、切れる
大学の教え方は、トップダウンである。
まず、開発工程全体に触れ
その工程をどのようにこなすかについて説明する
・ウォーターフォール
・スパイラル
などなど。
その後、各工程について詳細化していく
・要求
・(外部・詳細)設計
・実装
・テスト
そして、ソフトウェア工学の授業で、
要求・設計・テストを中心に行う(テストは大学によっては触れないかも)
要求仕様は、機能要件抽出方法として、ユースケースについて
設計方法としては、
オブジェクト指向分析と構造化手法分析
構造化手法では
DFDとER図
オブジェクト指向では
UMLのクラス図と状態図、シーケンス図
(なぜか、アクティビティ図はそんなに人気ない)
で、なぜか、実装はプログラミングの授業が別に有り
テストをやる学校は、テストについて教わる。
このように、トップダウンに詳細化していくので、
当然クラスは、継承を使って、詳細化していく。
で、気づいただろうか・・・
画面とかDBの話には結び付かない。これらは。直接。
だから、大学の授業では、トップから詳細化していくけど、
画面とかDBの設計にまでは降りてこない(アクティビティ図もないし)
で、いきなり、プログラミングの授業でプログラムする。
■最近の開発は、ボトムアップ
実際の開発では、仕事の流れが重視される。
そして、画面設計がされ、画面がきまると、フレームワークによって、
ある程度の開発方針が立つ。
データに関しては極論すると、画面や帳票で必要なデータをDBに入れればよい
ということになり、画面や帳票から設計することも可能である。
まさに、ユーザー主導のボトムアップ開発
したがって、継承は、個々の要素の共通部分を抽象化し、その抽象化されたものから
継承する形になる。
抽象化されたものの中にさらに抽象化できるものがあれば、さらに継承
と、ボトムアップ、帰納的になってくる。
このように、継承をボトムアップにつくるとなると、トップダウンで継承はできないから、
ダッグタイピングのような、継承を回避できるテクニックは、だいじなわけだ。
つまり、トップダウンとボトムダウンがmeetするポイントは、
「画面」「帳票」といった、UI等
になるのだが、
大学の授業はトップから始めて、そこまで降りてこない。
企業の開発は、そこから始まり、あまり抽象度を上げない(上げる必要がない)
っていうことで、ギャップができてしまうのだ・・・