私の友人は皆オタクなので、多くの人が2003年11月の「ロード・オブ・ザ・リング/二つの塔」のエクステンデッド版DVD発売日を待ち望んでいました（私の友人の中では、エクステンデッド版だけが価値のあるものだったのです）。しかし、私にとってその日は、多くの点で同様に重要な別のリリースを意味していました。セルジオ・レオーネの偉大な西部劇がついにDVDで発売されたのです。

「公開インターフェース」とは、私が（最初にリファクタリングで）使用した用語で、定義されているコードベースの外で使用されるクラスインターフェースを指します。そのため、Javaのpublicよりも、そしてC#の非内部publicよりも意味が広いのです。IEEE Softwareのコラムでは、公開とプライベートの違いよりも、公開と非公開の違いの方が実際には重要であると主張しました。

UMLではどのように導出情報を表現しますか？

キーリングにつけるラップトップ、多くの点でこれは誇張に過ぎないかもしれませんが、最近このアイデアが私を魅了しています。きっかけはKnoppixを見つけたことでした。

頭字語：Plain Old Java Object。

プロジェクトレトロスペクティブ中に作成すると価値のあるものとなるプロジェクトのタイムライン。タイムラインには、プロジェクト中に発生した様々なイベントとそのプロジェクトへの影響を示す必要があります。

サービス指向アーキテクチャ向けにサービスを構築する際に重要な考え方です。サービスを構築する際には、クライアントがテストに使用できるサービススタブも構築します。このようなスタブは、固定された一連のリクエストに対する定型応答を提供し、エラー状態をシミュレートし、クライアントのマシン上で実行可能である必要があります。スタブが実際のシステムの動作を適切に模倣していることを確認する必要があります。クライアントにスタブを提供することで、クライアントがサービスを使用しやすくなり、結果としてサービスが使用される可能性が高まります。

現在、XP Dayのセッションに参加しており、オーエン・ロジャースとロブ・スタイルズがXPのユニットテストと受け入れテストの違いについて話しています。これによって、受け入れテストを記述するための言語とはどのようなものでなければならないかという考えが頭に浮かびました。

これは、かなり前から存在するアンチパターンの一つですが、現在特に急増しているように見えます。エリック・エバンスとこのことについて話し合ったところ、どちらも人気が高まっていることに気づきました。適切なドメインモデルの熱心な支持者として、これは良いことではありません。

モジュールへのインターフェースの最も一般的なスタイルは、プロシージャまたはオブジェクトメソッドを使用することです。そのため、モジュールに契約の料金を計算させる場合、計算を行うメソッドを持つBillingServiceクラスがあり、次のように呼び出すことができます。

aBillingService.calculateCharges(aContract)

コマンド指向インターフェースでは、各操作にコマンドクラスがあり、次のように呼び出されます。

CalculateChargeCommand.new(aContract).run()

私が接するクライアントのほとんどは、反復型開発のことを聞いたことがないか、新しく比較的試されていない現象だと考えています。これとは対照的に、反復型開発は様々な名称で長年にわたって存在しています。IEEE SoftwareのCraig LarmanとVic Basiliによる最近の論文は、この歴史を捉える取り組みを要約しており、反復型開発アプローチを使用する成功したプロジェクトの長い歴史についての良い見解を与えてくれます。

UMLは人によって意味が異なるため、UmlModeを使用するという考え方が役立つと考えています。私が話すほとんどの人はUmlAsSketchに関心があり、このグループはUML 2にあまり感銘を受けていません。

特にオブジェクト指向システムでは、カプセル化の一般的な部分として、データ構造を隠蔽することがあります。しかし、このデータの多くをデータアクセスルチンで公開することも一般的です。このコラムでは、データアクセスルチンの記述に関するいくつかのガイドラインについて説明します。ただし、データを隠したままにできる場合は、通常はそれが最善です。

これまで、リファクタリングツールは多くの言語に登場しています。Smalltalkの先駆けとして、Java向けのツールがいくつか、C#向けのものもいくつか登場しています。訴えにもかかわらず、C++は目立たない言語です。これは、最初のリファクタリングに関する論文がC++のバックグラウンドを持つBill Opdykeによって書かれたという事実にもかかわらずです。

私が発見し、従ってきた最も有用な設計原則の1つは、プログラムのプレゼンテーション面（ユーザーインターフェース）とその他の機能との間の良好な分離を維持することです。長年にわたって、これを行ってきた場面を見てきましたが、多くの利点がありました。

最近、AmazonでP of EAAに関するいくつかの悪いレビューを見つけました。その理由は、この本にはエンタープライズアーキテクチャに関する記述がないためです。もちろん、それには正当な理由があります。この本はエンタープライズ*アプリケーション*アーキテクチャ、つまりエンタープライズアプリケーションを設計する方法について書かれています。エンタープライズアーキテクチャは異なるトピックであり、エンタープライズ内の複数のアプリケーションをどのように一貫性のある全体として構成するかについてです。

UMLクラス図では、ローカル変数（パラメータ、一時変数など）をどのように示しますか？

XP愛好家なら誰でも、4つの価値と12のプラクティスを知っていますが、15の原則について知っている人はどれだけいるでしょうか？ ケントが先週JAOOでそれについて話したとき、私は知らなかったことを告白します。講演後、ケントにそれについて尋ねました。「ホワイトブックに載っていましたか？」「はい」と彼は答えました。「『基本原則』という章に巧妙に隠されていました」。

このサイト全体は、単純なXML文書で記述され、HTMLに変換されています。これは非常にうまく機能し、HTML形式を扱うことを心配する必要がなくなります。（あなたが想像できるように、派手なレイアウトは私のスタイルではありません。）私はその方法で本を1冊書いています。

依存関係と関連付けの違いは何ですか？

モデル駆動アーキテクチャ（MDA）に関する大きな主張の1つは、プラットフォーム非依存モデル（PIM）でシステムを開発し、それを.NETやJavaなどのテクノロジーのプラットフォーム固有モデル（PSM）に変換できることです。注意深い読者はこれに対して「ちょっと待って、Javaのポイントはプラットフォームに依存しないことではないのですか？ なぜ別のプラットフォームに依存しないテクノロジーを生成するプラットフォームに依存しないテクノロジーが必要なのですか？」と言うでしょう。

オブジェクト指向の初期の頃、私のようなOOの提唱者は、再利用を主張することに多くの注意を払っていました。当初はクラスの再利用について話していました。その後、個々のクラスの再利用は、場合によってはうまく機能しますが、他の場所ではうまく機能しないことがわかりました。そこで、再利用可能なフレームワークを使用するようになりました。これにより、機能の一部が構築されたアプリケーションが得られました。

ソフトウェア開発における未解決の問題の1つは、ソフトウェアの境界を決定することです。（ブラウザはオペレーティングシステムの一部ですか？）。サービス指向アーキテクチャの多くの支持者は、アプリケーションは消滅しつつあり、将来のエンタープライズソフトウェア開発はサービスを組み合わせることになると考えています。

アプリケーション境界がなぜそれほど描きにくいかと同じ理由で、アプリケーションは消滅しないと私は考えています。基本的に、**アプリケーションは社会的構成物**です。

リファクタリングという言葉はどこから来たのでしょうか？

ソフトウェアプロセス、設計プラクティスなどについて、多くの感情的な議論を見かけます。ソフトウェア業界は、ソフトウェア開発の有効性の基本要素の一部を測定する能力を欠いているため、これらの議論の多くは解決不可能です。特に、生産性を合理的に測定する方法がありません。

ValueObjectの一般的な例はたくさんありますが、私のお気に入りはMoneyであり、Moneyと密接に関連しているのが通貨です。

ユースケースとXPのユーザーストーリーの違いは何ですか？

すべてのアジャイル手法は、システムの開発者と、最終的な受益者である顧客との直接的な相互作用の重要性を強調しています。アジャイル宣言には、「ビジネス関係者と開発者は、プロジェクト全体を通して毎日協力しなければならない」とあり、高い頻度の相互作用を強調しています。エクストリームプログラミングは、オンサイト顧客というプラクティスを通じてこれを強調しています。

人々が「ソフトウェアアーキテクト」という用語を使うとき、彼らは建築建設からのメタファーを使って、アーキテクトの役割を理解するのに役立てています。皮肉なことに、これを行うことで、彼らは実際の建築家の役割を誤解しています。

データモデリング手法は、関係について話す際に、カーディナリティという用語を使用して、いくつエンティティが互いにリンクできるかを示します。したがって、注文と顧客間の関係があり、その関係のカーディナリティが1対多であると言うことができます。または、注文に対する顧客のカーディナリティは0対多であると聞くかもしれません。

アプリケーションプログラミング言語とリレーショナルデータベース間の通信を行うほとんどのライブラリを見てみると、データベースの文字列型（charまたはvarchar）をプログラミング言語の文字列型にマッピングしていることに気付くでしょう。シンプルで明らかですが、間違っているかもしれません。

パターンに関する書籍に対するよくある不満は、経験豊富な開発者にとって新しいことが何も書かれていないということです。（最近、AmazonのレビューやThe Server Sideでいくつかそのような意見を見かけたので、今は少し敏感になっているのかもしれません。）これは事実であるだけでなく、パターンの本質でもあります。

ザ・シンギング・ディテクティブは、1980年代にBBCが制作したテレビシリーズ（1時間番組6話）です。私を含め多くの人が、これこそがこれまでに見た中で最高のテレビ番組だと考えています。複雑な作品であり、おそらくテレビ向けに制作された中で最も独創的な芸術作品の一つです。そのため、万人向けではありませんが、私は何度も見ています。最も注目すべきは、多くの挑戦的なテレビ番組を作った作家デニス・ポッターと関連付けられています。DVDで最近入手可能になりました。

多くの人は、アジャイルプロジェクトで固定価格契約を行うことはできないと考えています。アジャイルプロセスのポイントは将来を予測できないことなので、これは不合理な推測ではありません。しかし、これは固定価格のアジャイル契約を結べないという意味ではありません。実際には、固定スコープの契約を結べないということです。

大企業を調べれば、たいていはエンタープライズ全体の概念モデリングに焦点を当てたグループが見つかります。最も一般的なのはデータ管理グループですが、エンタープライズ全体のサービスの定義に関与している場合もあります。単一のアプリケーションの取り組みに焦点を当てるのではなく、複数のアプリケーションの統合に重点を置いているため、エンタープライズ全体を対象としています。

歴史は、ほとんどがつまらないものだ

--ヘンリー・フォード

最近、UML Distilledの読者から不満のメールを受け取りました。怒っている読者が、私の時折の知恵の言葉を、読むどころか購入することを後悔している場合、それは私の1日の始まりとしては決して良いものではありません。しかし、この読者の不満には特に興味深い点がありました。彼の具体的な不満は、私の「不必要な歴史」に関するものでした。

ソフトウェアアーキテクチャについて考えるとき、通常は技術アーキテクチャについて考えます。しかし、もう一つ重要なアーキテクチャがあります。それは、ソフトウェアの顧客とコミュニケーションするために使用するアーキテクチャ、つまりマーケティングアーキテクチャです。この「マーケテクチャ」とその「ターキテクチャ」との関係を無視すると、開発プロジェクトに多くの問題が生じる可能性があります。

アーキテクチャとは何か、そしてアーキテクトとは正確には誰か？これらは、誰もが非常に興奮するような質問です。そこで、このIEEE Softwareコラムでは、Ralph Johnsonにアーキテクチャについて説明してもらいます。それは、誰もが同意しない方法で、他のすべての定義と一致する定義です。また、アーキテクトの2つの亜種、「Architectus Reloadus」と「Architectus Oryzus」についても説明します。

今月はIEEEのソフトウェアエンジニアリング知識体系のレビュー月間です。これは、免許のある職業の基盤を築くことができる方法で、私たちの職業の知識体系を定義しようとする試みです。

同僚のJoe Walnesが指摘してくれたように、同僚のChris Stevensonが開発した驚くほどシンプルなツールがあります。TextDox（AgileDoxの一部）は、JUnitテストケースからドキュメントを自動生成するツールです。ばかげているように聞こえますが、それはWardishのアイデアのようなものです。

特に強く型付けされた言語でオブジェクトを使い始めるとき、よくある質問は、異なるドメイン型に対して特定のコレクションクラスを持つべきかどうかということです。したがって、従業員の集合を格納するcompanyクラスがある場合、ライブラリから通常のcollectionクラスを使用するべきか、特定のEmployeeListクラス（型付きコレクション）を作成するべきかということです。

先週、フロリダ州を巡り、Dan SandlinとDavid LeBlancとマイクロソフトアーキテクチャ評議会の一連のセッションで話す機会がありました。David LeBlancは、Michael Howardと共著で非常に人気のある書籍Writing Secure Codeを書いたことを知らない人のために言っておきます。各セッションで、私はP of EAA（今週JavaWorld awardを受賞）に関する講演/質疑応答を行い、Davidはセキュリティについて続きました。

テスト強化設計におけるよくある問題は、テストモードでサービススタブを作成しながら、本番環境（および一部のテスト）では実際のものを利用できるようにする方法です。私の同僚の何人かが彼らのアイデアを共有してくれました。

先週、OMGはUML 2の上部構造文書を採用しました。実際には、UML 2が合意されたことを意味します。UML 2にはUMLへの多くの変更があり、UMLが最初に合意されて以来、最大の改訂を表しています。一般ユーザーにとって、最も明白な変更はおそらく

UMLユースケース図は、ユースケース間の多くの関係を定義します。最もよく知られている2つはincludeとextendです。これらの2つの関係に関する質問は、ユースケースの他の部分、おそらくUMLの他のものよりも多いようです。

収穫によってプラットフォームを構築するには、まずプラットフォームを構築しようとせず、アプリケーションを構築することから始めます。アプリケーションを構築している間は、汎用コードを開発しようとせず、適切にファクタリングされ、適切に設計されたアプリケーションを構築することに努力します。

基盤プラットフォームとは、その上に構築されるあらゆるアプリケーションよりも先に構築されるものです。様々なアプリケーションに必要なプラットフォームのニーズを分析し、それからプラットフォームを構築するという考え方です。プラットフォームが完成したら、その上にアプリケーションを構築します。ポイントは、アプリケーションの作業を開始する前に、プラットフォームが安定したAPIを備えている必要があるということです。そうでなければ、プラットフォームへの変更は、アプリケーションへの波及効果によって管理が困難になります。

最近、ロバート・クリングリー氏による記事が、リファクタリングコミュニティでちょっとした騒ぎを引き起こしました。彼はリファクタリングを批判したのです。リファクタリングメーリングリストでのフィリップ氏の反応は、「…彼は『読もうとも思っていない本の書評を書く』懐疑論者のようだ」という、異例に抑制されたものでした。

このUmlModeでは、開発者はUMLを使用してシステムのいくつかの側面を伝えるのに役立てます。設計図と同様に、スケッチを順方向エンジニアリングまたは逆方向エンジニアリングの方向で使用できます。順方向エンジニアリングはコードを書く前にUML図面を作成し、逆方向エンジニアリングは既存のコードからUMLを構築して理解を助けます。

UMLを十分に詳細に記述し、ソフトウェアに必要なすべてのセマンティクスを提供できれば、UMLをプログラミング言語にすることができます。ツールは、あなたが描いたUML図面を取り込み、実行可能なコードにコンパイルすることができます。

これによるメリットは、UMLはより高レベルの言語であり、現在のプログラミング言語よりも生産性が高いという点です。

長い間、エンジニアリングの影響を受けたソフトウェアプロセスでは、設計図が橋の建設に使用されるのと同様に、ソフトウェア設計を表現し、その設計をコード作成担当の別のグループに引き渡す方法が求められてきました。これにより、希少で高価なソフトウェア設計者は設計図に集中し、より安価な多くのコーダーは構築に集中することができます。

UML 2を調べている際に、UMLに何を含めるべきかについて人々の意見が異なることに気づきました。それは、UMLが何であるべきかという根本的な見解が異なるためです。このことを考えているうちに、UMLを検討するための3つの主要な分類方法を思いつきました。それは、スケッチとしてのUML、設計図としてのUML、そしてプログラミング言語としてのUMLです。（興味深いことに、スティーブ・メラーも独立して同じ分類方法を考案しました。）

私はしばらくの間、ブログの動向を見てきましたが、参加したくならないわけにはいきません。しかし、ブログにはあまり熱心でない点もあります。まず第一に、名前です。同僚のマイク・ツーが言うように、「ブログとは、医師に除去してもらいたいもののような響きだ」。しかし、名前以外にも、ブログ投稿の非常に一時的な性質があります。読んだときには興味深い可能性のある短い書き込みですが、すぐに古くなります。私は書くことが大変なので、消えてしまうものに費やしたくありません。

オブジェクト指向を人に教える場合、どの言語を使用すべきでしょうか？

リファクタリングを使用してプラットフォームを構築できますか？

UMLにおいて、特に通常の関連付けとどのように異なるかという点で、集約と合成ほど多くの混乱を引き起こすものはほとんどありません。

CHAOSレポートによると、プロジェクトの成功率はわずか34％です。

スタンディッシュグループのCHAOSレポートは、長年にわたりITプロジェクトにおける数十億ドルもの無駄遣いについて述べてきました。34％という成功率は、2001年の28％という数値よりも実際には改善されています。しかし、「失敗」とは実際には何を意味するのでしょうか？

protected AccessModifierを持つデータがクラスに存在することは、良いOO設計と言えるでしょうか？

オブジェクト指向言語は、プログラムをクラスと呼ばれるモジュールに分割します。各クラスには、データ（フィールド）とメソッドで構成される機能が含まれています。（すべての言語がこの用語を使用するわけではありませんが、ここではこれで十分です。）言語には、他のクラスがクラスの機能にアクセスできるかどうかについての様々なルールがあり、これらは多くの場合、クラスに適用されるアクセス修飾子に基づいています。

トラックのArrayListを持つアルバムクラスがあるとします。これをUMLクラス図にどのように示しますか？

よくある質問として、大規模プロジェクトをアジャイル手法で行うことができるかどうかがあります。結局のところ、多くのアジャイルアプローチは小規模なプロジェクト向けに設計されており、それらが抵抗する重量級のアイデアは、より大規模なプロジェクトではより必要になります。

カオス理論が、コンポーネントアセンブリが思ったほど簡単ではない可能性を示唆する理由。

Software Development誌は、私の著書「エンタープライズアプリケーションアーキテクチャのパターン」の第7章（分散戦略）を記事として掲載しました。分散オブジェクト設計の第一法則を含め、その調子を気に入ったのだと思います。

ソフトウェア設計の理解にパターンがどのように貢献できるかについてのIEEEコラム。

XPやその他のアジャイル手法の人気が高まるにつれて、10～12人のチームを超えてXPをスケーリングする方法に関する疑問が表面化し始めています。2003年2月中旬、このテーマに特化したワークショップがカナダのアルバータ州バンフで開催されました。この記事では、ケン・シュワバーとマーティン・ファウラーによる基調講演と、その他主要な実践者について報告します。

過去数十年の間に、データベース指向のソフトウェア開発者とインメモリアプリケーションソフトウェア開発者の間のギャップが広がっています。これにより、SQLやストアドプロシージャなどのデータベース機能の使用方法について多くの論争が生じています。この記事では、単純ながらも豊富なSQLクエリを例に、パフォーマンスと保守性を中心に、ビジネスロジックをSQLクエリに配置するか、インメモリコードに配置するかという問題について検討します。

しばらくの間、私はほとんどのライティングをXMLで行ってきました。最新の著書もXMLで執筆したほどです。このことを人に話すと、私の経験について多くの質問をされることがあり、この記事を書くきっかけになりました。

値に対して新しいユーザー定義型（またはクラス）を作成する際のガイドライン。