汎用のフレームワークがあれば業務アプリ実装にオブジェクト指向は不要という考え方は適切でないと思う - 達人プログラマーを目指して
前回のエントリいまさらですが、職業Javaプログラマーなら理解しておいてほしい「継承」の意味についてのブクマのコメントで、 すごく今さら感がｗ 最近の開発はフレームワーク使うことが多いようだから知らなくても作れちゃうと思ってたけど違うのかなあ。 という感想をいただきました。実際に、SI業界で多くの方々、特に、アプリケーション開発の下流工程を担当しない層の方でこのように考えている方はほんとうに多いのではないかと思います。確かに最近ではSalesforceなどの製品もありますし、CRUD処理を行うような見栄えの良い業務アプリケーションは非常に簡単に開発できるようになっているということはあります。また、Visual BasicやMS Accessなど気軽にアプリケーションを開発できるツール類は昔からありました。そして、業界構造などの理由からやむを得ない側面があるとはいえ、SIerの提供する多くの
分析手法のキホン：「分解と分類」
第8回「分析から設計へのモデル変換などについて」はシステム開発プロセスで「分析・設計」と隣り合わせで使われるが、本来全く異なる概念である「分析（analysis）」と「設計（design）」について考えてみました。分析は複雑で理解困難な対象を単純な構成要素に分解して本質を見極める科学（science）の範疇（はんちゅう）に入ります。一方設計は、人工物を合成する工学（engineering）の範疇です。システム開発では分析と設計の間に大きなギャップがあります。 実際、このモデル変換という作業はとても大変で、機械的にできるものではありません。例えば、大学の学部でいえば分析は、（対象が自然現象なら）「理学部」か、あるいは（対象が社会現象なら）「社会科学系の学部」に属し、設計は「工学部」に属すくらいの差があるといえるでしょうか。なお、ある時期から、理工学部という、科学と工学の橋渡しを行うような存在
UML2.0で変わるモデリング作法
UML2.0の仕様についてはこれまでさまざまなメディアで解説されてきたが、サポートするツールが存在しない状況では、それがどんなに便利なものであっても、絵に描いた餅（もち）に過ぎなかった。しかし、ようやくUML2.0に対応したUMLモデリングツールがいくつか登場し始めた。ツールの登場により、UML2.0で拡張された機能の意味を身をもって体験できるようになるだろう。テクノロジックアート 代表取締役社長 長瀬氏に、UML2.0の仕様拡張とそれらがモデリングに与える影響について、簡潔に語ってもらった。（アットマーク・アイティ編集局） UMLが登場して8年が経過した。その間に、システム開発の環境も大きく変化した。かつて、オブジェクト指向開発といえば、SmalltalkやJavaでの単体プログラム作成を指していたが、今日では、単体プログラムだけではなく、フレームワークを利用した大規模システム開発もオブ
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指して
プログラミングと設計は本来切り離せないものなのではがすごい反響だったのですが、結局この記事で私が言いたかったことは、 Java EEなどの現代的な開発環境はCOBOLなどの古い言語を使った開発とは根本的に設計の手法が異なる 多くの現場では未だに古い設計手法を使っているため、オブジェクト指向などの最近の開発環境のメリットが活用できず、低い生産性にとどまっている。 ということに要約できると思います。ただし、どうして、Javaではオブジェクト指向で開発しないといけないのか、どうして昔ながらの伝統的なやり方を改め、新しい設計手法を採り入れないといけないのかと疑問を持たれた方もいらっしゃるかもしれません。ここでは、開発手法と生産性の問題について、もう少し掘り下げて検討してみたいと思います。 レガシー言語の生産性 最近のCOBOLでは、オブジェクトやスタック変数すら使えますが、ここではCOBOL85の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
