ボールアンドソケット

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

これは、このような内容を表示するための便利な表記です。実現化矢印を使用すると、より乱雑なダイアグラムになります。

クラスはインターフェースを実装するだけでなく、インターフェースを必要とすることもできます。たとえば、音楽プレイリストの合計時間など、デジタル音楽プレイリストに関するさまざまな情報を提供するクラスを作成するとします。個々の音楽ファイルに関する情報を取得するには、どこかからデータを取得する必要があります。私はかなりヒップな男なので、iTunesから取得できますが、他の可能性(たとえばmp3から直接読み取る)があることを認識しているので、他の実装を簡単に代用できるようにインターフェースを使用します。

必須のインターフェース表記を使用すると、この必須インターフェースをコンパクトなソケット表記で表示できます。

ボールとソケットは非常に近いため、それらが一致するのは当然のように思えます。したがって、私はUML Distilledの執筆時に目にしたUML仕様でそれらが一致することを許可しました。

このことはそれらのUML仕様に許可されていましたが、Bran SelicはUML委員会がこのことは誤りであり、ボールアンドソケット表記をこのように使用すべきではないと判断したと教えてくれました。ボールアンドソケット表記は依然としてUMLにありますが、複合構造ダイアグラム内のコネクタにのみ使用できます。複合構造ダイアグラムは別のトピックです。

必須インターフェースと提供されるインターフェース間のこのリンクを表示する方法という疑問が残ります。UML 1では依存関係を使用しました。

Jim Rumbaughのリファレンスマニュアルに別の方法が示されています。

このような例では、同じ意味を伝える表記が少ないため、UML 1スタイルが好ましいと思います。ただし、単一の必須インターフェースを実装する複数のクラスなど、より複雑なものを表示したい場合は、ランボーのスタイルが優れています。

重ねられたボールアンドソケット表記は技術的には無効ですが、インターフェースと実装の接続方法を表示する方法としては気に入っています。そのため、厳しいUMLルールを破って使用する傾向があります。より複雑なケースでは、ボールアンドソケット間に依存関係表記を使用することもありますが、その場合はインターフェースに明示的なクラスボックスを使用することを好みます。