![Amazon.co.jp: Use Case Driven Object Modeling with UMLTheory and Practice: Theory and Practice: Rosenberg, Don, Stephens, Matt: 本](https://cdn-ak-scissors.b.st-hatena.com/image/square/b3356884eb582d18fbede2ec962ac5a36355e6ae/height=288;version=1;width=512/https%3A%2F%2Fm.media-amazon.com%2Fimages%2FI%2F510XOeOqKTL._SL500_.jpg)
This website uses cookies for account and order processing. By using this site you understand and agree to our use of cookies, our Terms Of Use, and Privacy Policy We’re sorry. We put our most map-savvy gerbil on the case, but we still couldn’t find the page you were looking for. If you got here via an external link, it is possible that the content may have moved when we updated to this new site.
There are several ways to split up the logic of the presentation. 11 July 2006 This is part of the Further Enterprise Application Architecture development writing that I was doing in the mid 2000’s. Sadly too many other things have claimed my attention since, so I haven’t had time to work on them further, nor do I see much time in the foreseeable future. As such this material is very much in draft
「EoM=EoC+EoT」を鍵概念として、良い設計とは何か、よいプロセスとは何か、を再定義しようとしている。今回は、テストの役割について再考する。 テストは設計とプロセスの両方の基本単位だ。まず、テストと進捗管理の話をしたい(テストとドキュメントの話、テストとコミュニケーションの話、テストと開発リズムの話、などと続く予定)。 みなさんは、進捗指標として何を使っているだろうか?「工程ごとに違うが、成果物の完成に対する到達度だ」という答えが一般的だと思う。しかし、「設計書90%完成という報告が2週間続いている」というような進捗会議に参加したことはない? (きっとあるはずだ。) ぼくが考える進捗管理の基本は、 の3点だ。先に述べた「設計書のページ数」という単位は、3つの条件をどれも満たしていない。すべての設計書を否定するつもりはないが、設計書は内部の中間生産物であることが多いし、100%終了とい
前回、「EoM(保守容易性)が良い設計の基準だ、そして、EoM=EoT+EoCだ」という議論を書いた。ここまでの議論は、ソフトウェアの設計についてのものであり、開発の「プロセス」(あるいはプラクティス)とは無関係に進めてきた。ここで、1つの経験則を使って、プロセスの方(鏡の反対側)を見てみたい。その経験則とは、 コーンウェイの法則: ソフトウェアの構造は開発チームの構造に一致する。コンパイラを4チーム編成で作れば、4パスコンパイラになる である。(※この法則は、ソフトウェアとチームの「構造」(organization)について述べたものだが、ここでは、プロセスについて拡大解釈する) この法則を使うと、3つの設計品質についての方針は、そのまま、プロセスについての方針にミラーコピーできる。 EoTに関するプロセスの命題は、テストというより、「テスティング」という活動が、プロセスの中で最も重要な
前2回で、オブジェクト指向を「テスト容易性」と「変更容易性」を中心に再定義したい、という話をした。 従来オブジェクト指向の説明に使われている概念、およびそこから得られる(といわれている)再利用性という品質からではなく、 テスト容易性: EoT = Ease of Testing 変更容易性: EoC = Ease of Changing という2つの概念からが、(現代的な)オブジェクト指向設計の焦点であることを主張してきた。最後、なぜこの2つが必要なのか、というと、それは、メンテナンスのしやすさ(EoM=Ease of Maintenance)を高めるからだ。そして、このEoMこそが、2005年のソフトウェア開発の根本品質だ、と言い切ってまとめたい。 EoMの高い設計が、よいオブジェクト指向設計である。 ということである。今回は、前回書いた、EoT/EoCそして、このEoMについて、ソフト
前回は、EoT(Ease of Testing: テスト容易性)によってよいオブジェクト指向設計を再定義したい、という表明をした。今回は、二本目のナイフを抜きたい。キーワードは、EoC(*1)(Ease of Changing)、変更容易性だ。 この記事では、 EoCの高い設計が、よいオブジェクト指向設計である。 と主張したい。設計品質の中で、「変更容易性(EoC)」を最上位と見る。 ここ10年のオブジェクト指向の最大の失敗は、「再利用性」をその最大の価値、として説明しようとしてきたこと。そして分かったことは、再利用がその努力コストに見合う効果がでることは極めて稀であること、また、テクノロジではなくソーシャルな活動が再利用に効くこと、さらに、コードの再利用ではなく、ナレッジの再利用(例えばパターン)の方が、まだ可能性があるということ(少なくとも2005年のコンテクストでは)。 再利用性では
アプリケーションをレイヤ分割した場合、 プレゼンテーション層 -> ビジネスロジック層 -> データアクセス層 のように分けるのが一般的ではないかと思います。 ここで、矢印は、依存関係を表しています。例えば、プレゼンテーション層は、ビジネスロジック層に依存していて、ビジネスロジック層は、データアクセス層に依存しています。 矢印の向いていないほうには依存していません。例えば、ビジネスロジック層は、プレゼンテーション層に依存していません。 誤解が多いんじゃないかと思うのは、レイヤとモデルを混同することです。一番多く見られるのは、ビジネスロジック層とドメインモデルの混同です。 モデルは、各層を流れていくデータ(+ ロジック)であり、どの層にも依存しません。逆に層はモデルに依存することになります。 モデルは、プレゼンテーションモデルとドメインモデルに分かれます。本当は、ERモデルもあるのですが、こ
関連:id:sumim:20040525:p1 keisuken さんの 航海日誌 発、babie さんの 遅レス 経由で、オライリーのオープンソースコンベンション(OSCON 2005)のセッション「10 Things Every Java Programmer Should Know About Ruby」(スライド、brazil さんの和訳)で語られた「Item #9 Everything is an Object」から生じる語弊について。 そうですね。これではまるで Java のクラスがオブジェクトではないかのように読めますし、そうだとすれば(オブジェクトに定義にもよりますが、おそらく)間違いでしょう。ただ、文脈をたぐると、ここでの Jim Weirich さんの主張は「(Ruby において)“Array”は、Array というクラス(を実現した)オブジェクトを束縛した定数(に過ぎ
http://martinfowler.com/bliki/AccessModifier.html オブジェクト指向言語ではプログラムはクラスと呼ばれるモジュール群に分かれます。 それぞれのクラスは機能(features)をもっており、データ(フィールド)とメソッドで構成されます(すべての言語がこの用語を使うわけではありませんが、役割は一緒です)。 言語には、どのクラスがあるクラスの機能にアクセスできるのかについてのルールがあり、たいていクラスに適応されるアクセス修飾子に基づいて決まっています。 C++ の選択 おそらく最も影響力のあるアクセス修飾子はC++の3つから始まりました。 public: どのクラスもアクセスできる protected: どのサブクラスもアクセスできる private: どのクラスもアクセスできない 他のクラスやメソッドに対して _friend_ を使ってアクセス
本コーナーは、.NET関連の新刊書籍から主要なチャプターをそのまま転載し、その内容を紹介するものです。 今回は、日経BPソフトプレス/マイクロソフトプレスより2005年3月28日に発行の書籍『Code Complete 第2版 上 ― 完全なプログラミングを目指して』より、同社の許可を得てその内容を転載しています。 同書は、11年前に出版された名著「Code Complete」の第2版です。第2版では、全体をとおしてオブジェクト指向の考え方が反映され、リファクタリングの章なども追加されています。また、開発言語としてC#やVisual Basic .NETも取り上げられています。“完全な”コーディングのための鉄則を凝縮した本書は、開発者ならば必読といえるでしょう。 本記事では「第6章 クラスの作成」の前半部分を転載しています。クラスを記述しようとすると、どちらの実装がより美しいのだろうかとい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く