標準UMLを持つということはどういう意味なのか、そしてなぜ標準は人々が考えるほど多くのことを標準化していないのか。

2000年のUML Worldで、UMLにカーネルが必要かどうかについてパネルディスカッションを行いました。SD Magazineはそれを驚くほど首尾一貫した記事にしました（優れた編集者にはかないません！）。私がカーネルをどれほど恐ろしく小さくしようとしたかをご覧ください。

UMLにおいて、集約とコンポジションほど混乱を招くものはほとんどありません。特に、それらが通常の関連付けとどのように異なるかについてです。

UML 2で登場した新しい表記法の1つは、クラスが必要とするインターフェースを示すソケット表記法です。これは、クラスが複数のインターフェースを実装することを示すためにMicrosoftによって普及した「ロリポップ」表記法に由来しています。そのため、Arrayクラスが次のように複数のインターフェースを実装することを示すことができます。

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

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

UMLで派生情報をどのように表現しますか？

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

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

モデル駆動型アーキテクチャ（MDA）は、アセンブラから最初の高水準言語への移行以来、ソフトウェア開発における最大の変化になると考える人もいます。他の人は、それは生きているケースツールの夜に過ぎないと考えています。私は後者の陣営にいますが、巧妙な言葉以上のものが必要だと感じています。

モデル駆動型ソフトウェア開発（MDSD）は、従来のプログラミングスタイルの代替手段と見なされるソフトウェア開発スタイルです。このアプローチは、ソフトウェアシステムのモデル構築を中心としています。これらのモデルは、通常、図式設計表記法を通じて明示されます。UMLは1つのオプションです。アイデアは、これらの図を使用してシステムをモデリングツールに指定し、次に従来のプログラミング言語でコードを生成することです。

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

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

UML Distilled では、UML のアクティビティ図を教えるための良い本がないことを嘆きました。まだありませんが、最近 Conrad Bock の UML 2.0 に関する記事 を見つけました。その中には、Distilled で取り上げることができたよりも深く掘り下げたアクティビティ図に関する一連の記事があります。(ご存知ない方のために説明すると、Conrad Bock は UML 2 のアクティビティ図作業のリーダーの 1 人です。)

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

昨日、コードベースを調べて、コードのドメインモデル部分を見ていました。コードベースを探索するときは、学んでいることを覚えるのに役立つメモを取るのが好きです。一部のコードベース、特にドメインモデルの場合、UMLクラス図をスケッチすると便利です。

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

これの約束は、UML がより高水準の言語であり、したがって現在のプログラミング言語よりも生産性が高いことです。

この UMLモード では、開発者は UML を使用してシステムのいくつかの側面を伝えやすくします。青写真と同様に、スケッチをフォワードエンジニアリングまたはリバースエンジニアリングの方向に使用できます。フォワードエンジニアリングは、コードを書く前に UML 図を描画しますが、リバースエンジニアリングは、既存のコードから UML を構築して理解を深めます。

UML 2 を見ていると、UML が何であるべきかについて異なる基本的な見解があるため、人々は UML に何を入れるべきかについて意見が異なることに気付きました。これについて考えた結果、UML について考えるための 3 つの主要な分類を思いつきました: スケッチとしての UML、青写真としての UML、および プログラミング言語としての UML。(興味深いことに、Steve Mellor は独立して同じ分類を思いつきました。)

UML 図をたくさん描きますが、CASE ツールは使用しません。理由は、すべてのレポジトリではなく、スケッチとしての UML に興味があるからです。これまでのところ、私の定番の選択肢は Visio でした。Visio には UML テンプレートが付属していますが、組み込みのテンプレートは使用していません。Pavel Hruby のテンプレートを好みます。

先週、OMG は UML 2 の上部構造ドキュメントを採用しました。実際には、これは UML 2 が合意されたことを意味します。UML 2 では UML に多くの変更があります。これは、UML が最初に合意されて以来、UML に対する最大のオーバーホールを表しています。一般ユーザーにとって最も明らかな変更は、おそらく次のとおりです。

UML は人によって異なる意味を持つため、人々が異なる UML モード を使用するという概念が役立つと思います。私が話をするほとんどの人は スケッチとしての UML に興味を持っており、このグループは UML 2 にあまり感銘を受けていません。

ユースケースは、要件を整理し、引き出すための手法です。それらはもともと 80 年代後半と 90 年代初頭に Ivar Jacobson によって普及しました。

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