今回は、前回「第9回 UMLベース開発プロセスの流れ」説明した開発フェイズの基本知識を基に、いくつかの開発フェイズを組み合わせながら開発を進める方法（開発プロセス）について説明をしていきます。UMLの使い方について例題を使って説明する予定でしたが、プロセス関連でお話ししたいことが山ほどあり、今回は例題まで話をつなげることができません。よって、例題については次回に回します。皆さん気長にお付き合いください（笑）。 開発フェイズとUMLモデリング 前回説明したように、オブジェクト指向型開発プロセスでは、表のような開発フェイズを持っています。実際、これらの開発フェイズの名前や、その中で行う作業の定義については、開発プロセスの中で定義されているのですが、どの開発プロセスを利用するにしても、下記のフェイズを理解して開発を進めることが重要です。これは、前回の順平君の体験例にてお分かりいただいたと思います
プログラミングと設計は本来切り離せないものなのではがすごい反響だったのですが、結局この記事で私が言いたかったことは、 Java EEなどの現代的な開発環境はCOBOLなどの古い言語を使った開発とは根本的に設計の手法が異なる 多くの現場では未だに古い設計手法を使っているため、オブジェクト指向などの最近の開発環境のメリットが活用できず、低い生産性にとどまっている。 ということに要約できると思います。ただし、どうして、Javaではオブジェクト指向で開発しないといけないのか、どうして昔ながらの伝統的なやり方を改め、新しい設計手法を採り入れないといけないのかと疑問を持たれた方もいらっしゃるかもしれません。ここでは、開発手法と生産性の問題について、もう少し掘り下げて検討してみたいと思います。 レガシー言語の生産性 最近のCOBOLでは、オブジェクトやスタック変数すら使えますが、ここではCOBOL85の
ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系 作者: F.ブッシュマン,H.ローネルト,M.スタル,R.ムニエ,P.ゾンメルラード,Frank Buschmann,Hans Rohnert,Michael Stal,Regine Meunier,Peter Sommerlad,金沢典子,桜井麻里,千葉寛之,水野貴之,関富登志出版社/メーカー: 近代科学社発売日: 2000/12メディア: 単行本購入: 15人 クリック: 448回この商品を含むブログ (54件) を見るPattern-Oriented Software Architecture, A System of Patterns (Wiley Software Patterns Series) 作者: Frank Buschmann,Regine Meunier,Hans Rohnert,Peter Somme
半年前に爆発的に盛り上がったネタで今更ですが、 実はオブジェクト指向ってしっくりこないんです！：気分はstatic！：エンジニアライフ について。多態性（ポリモーフィズム）やGoFのデザインパターンなどの常識を知らない筆者が、C#でpublic staticメソッドを使えば*1インスタンス化が不要などと知ったかぶりの口調で説明したところ、コメント欄やその他のブログで爆発的に議論（多くは反論）が巻き起こったという、伝説的な内容の記事です。多くの方が既にコメントしているので、ここでは筆者の無知や態度については繰り返し言及しないことにします。ユーザー企業のIS部門という業界のピラミッド構造のかなり上の方に属する立場のSEにはこの程度の見識しか持たない人もいるのか、井の中の蛙の技術者とはこのようなものなのかという事実をあらためて世に知らしめたという意味で、（炎上した多数のコメントも含めて）非常に貴
今回は、開放・閉鎖原則のお話です。 これも、リスコフの置換原則と同じかそれ以上に、ソフトウェア開発者の方には有名な原則ですね。 これも、開発の現場では、みんな知ってるにもかかわらずないがしろにされがちな原則です。 英語でopen・closed principleですので、OCPと略されたりもします。 ソフトウェア開発者でない方には、この原則の概念を理解していただきたいと思います。 この原則によって、あなたの生活からストレスが軽減される…かもしれません。 ソフトウェア開発者の方には、この原則の重要性を再認識していただきたいと思います。 コンテンツ計画は、細かければ細かいほど失敗しやすい例： 旅行計画オープンでクローズドオススメ計画は、細かければ細かいほど失敗しやすい 何か重要なやるべきことがあるとします。 すごく楽しみにしてた観光だとか、失敗できない仕事だとかそういうことです。 そんなとき、
リスコフの置換原則（LSP:the Liskov Substitution Principle）派生型はその基本型と置換可能でなければならない。どういうこと？使う側から言うと、基本型を引数にとる関数に、どんな派生型のインスタンスをもらっても気にしないで使えないとダメ。実装側から言うと、派生クラスがその基本クラスで使われるところにおいても、正常に動作することを保証しなければならない。なんで？使う側に意識させるということは、OCPに違反することになるから。つまり、LSPに違反すると、必然的にOCPにも違反してしまう。たとえば？ではまず、簡単な例。Shapeクラス、そしてその派生クラスCircle/Squareがある。Shapeにabstract関数を使わない。Circle/Squareにそれぞれ独自のDraw関数がある。ここでShapeを受け取ってDrawする関数を作ろうとすると、、、、 v
iPhone用の「はてな人気エントリーリーダー」、そろそろ形になってきたのだが、作ってみていろいろと発見した部分もあったので、全面的にクラス構成を見直し、大幅に書き直した。 HTTPで通信をしているコードが二カ所に分かれていたので、それをDataOverHTTP/XMLOverHTTPという二つのクラスにまとめ（XMLOverHTTPはDataOverHTTPのサブクラス）、はてな独自のRSSフィードを読んでいるコードから一般的なRSSフィードを扱うコードをくくりだしてRSSFeed/RSSFeedLoaderという二つのクラスにまとめて、あとで別のアプリケーションで再利用することを可能にした。それに加えて、各種ローダーに非同期通信をさせる主体をController（HotEntryViewController）からModel側（HateneHotEntry）に移すことにより、難解になりが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
