UMLコンポーネント図

VB初心者です。
コンポーネント図を作成しています。
ネットで調べているとコンポーネントは
VBではexeやdllの事を指すことが分かりましたが
インターフェイスというのがどういう意味でどういった時に書けばよいのかよく分かりません。
サンプル例でコンポーネント→httpというのがありましたが
分かる方ご教授下さい。

# 文章で説明するのが難しい…。
# おかしなことを書いていたらツッコミよろしく＞識者の方

> ネットで調べているとコンポーネントは
> VBではexeやdllの事を指すことが分かりましたが
そうなることもありますが、そうでないこともあります。

「コンポーネント(component)」とは、構成要素とか部品という意味に過ぎず、
それがなんの関係性を表した図なのか、その粒度によって定義づけが変化します。

EXE/DLL というファイル単位になることもあれば、アセンブリ単位になることもありますし、
COM ライブラリやフレームワークといった単位になることもあります。

例えば下図は VB ではなく C++ の場合ですが、物理的な構成要素の例として
ソース間の依存関係という粒度で見ると、*.cpp や *.h がコンポーネントとなり、
実行ファイルの依存関係という粒度では、*.exe や *.dll がコンポーネントとなります。
http://objectclub.jp/technicaldoc/uml/umlintro2#component

下記はファイルよりももっと大きな単位で構成されており、
コンポーネントがサブシステム単位となっています。
http://yohshiy.blog.fc2.com/blog-entry-158.html

このように、規模が大きいシステムでは、システム全体を俯瞰するためにコンポーネント図を使い、
個々のコンポーネントが、さらに粒度の細かいコンポーネント図として組まれることがあります。

なお上記は UML 1.0 時代の図なので、矩形から2つの長方形の棘が生えていますが、
UML 2.0 では単純な矩形だけで示されることもあります。UML 1.0/2.0 の差異は下記参照。
https://www.itmedia.co.jp/im/articles/0502/02/news110.html

この URL の図7ではなく、コンポーネント区画の内部に、より細かいコンポーネントが
部品として配置されていますね。


> インターフェイスというのがどういう意味でどういった時に書けばよいのかよく分かりません。
クラス図における「インターフェイス」であれば、端的には「ポリモーフィズム」のためです。
VB だと Interface ステートメントに当たりますね。
https://atmarkit.itmedia.co.jp/fdotnet/bookpreview/kisokaravb_0802/kisokaravb_0802_01.html
https://www.umayadia.com/VBStandard2/Standard28-2.htm

コンポーネント図における「インターフェイス」の場合は、クラス図のそれと同様の意味で使われることも
ありますが、どちらかといえばより大まかな概念を示すものでしょう。

それぞれのコンポーネントは、自立した別々の構成要素でありますが、
あるコンポーネントが、他の機能に依存することはよくあります。
その場合、それぞれのコンポーネントがどのような機能を有しているのかを、
必須の（あるいは公開された）インターフェイスとして定義しておきます。
これにより個々のコンポーネントが、他のコンポーネントのどのインターフェイスに
依存しているのかを明確にすることができます。


> サンプル例でコンポーネント→httpというのがありましたが
その例が使われている URL 等を提示してもらえると話がしやすいのですけれどね。


例えば下記の「コンポーネント内で定義する場合」の例でいうと、
https://notepm.jp/template/component
各コンポーネントはデータを処理（読み書き）する部品という構成で、
コンポーネント1 は、HTTP でデータを受信し、
コンポーネント2 とは、FTP を通じて、そのデータをファイルとして受け渡す流れ。

この場合のインターフェイスは、通信プロトコルを指し示していることになります。
（HTTP や FTP というクラスが、通信プロトコルであることは明確ですね）
これは、要件設計やインフラ設計のレベルで使われるコンポーネント図。


https://www.edrawsoft.com/jp/uml-component.html
上記の「4.1 eコマース」の図でいうと、コンポーネントは
データの単位(データベースのテーブルのようなもの)であり、
インターフェイスは、それらのデータのうち、各コンポーネントの関連性を示す共有情報となります。

個々のインターフェイスには、明確な名前をつけられることもあります。

下記の場合は、Scanner コンポーネントが Product コンポーネントのデータにアクセスする際に
findItem というデータ構造（これがインターフェイス）を通じてデータをやり取りすることを示しています。
https://docwiki.embarcadero.com/RADStudio/Alexandria/ja/UML_1.5_%E3%82%B3%E3%83%B3%E3%83%9D%E3%83%BC%E3%83%8D%E3%83%B3%E3%83%88%E5%9B%B3%E3%81%AE%E5%AE%9A%E7%BE%A9

ずばりの回答ではありません。ごめんなさい。

名無しさんの発想が通常と逆なように思えます。
通常は、表現したいものがあって、コンポーネント図が適切だと思って、あれを表現するにはコンポーネント図をどう書けばよいか
というように考えていくと思います。

今回の、名無しさんは、コンポーネント図を書こうと思って、コンポーネントやらインターフェースやらがあるようなので、それは何なのか
というように考えているように見えます。

たとえ話ですいませんが電車にたとえると…
通常：秋葉原に行きたい！ → 山手線で行けるようだ → どうやって乗ればよいのだろうか？
今回：山手線に乗りたい → 行先まで切符を買う必要があるようだ → 行先とはなんだろう？

この状態だとコンポーネントもインターフェースもあまり腹落ちしないのではないかなと思います。
多分、勉強目的か、誰かから何か課題を与えられたか、というところがきっかけでしょうか。

私の考えでは、
コンポーネント図におけるコンポーネントは、関心のあることを表現できるものであればよく、dllやexeとは限りません。
(だから関心があることがなければコンポーネントをどうするか考えられないのです。)
また、インターフェースは、メソッドやらプロパティやら、起動時のパラメーターやら、その機能が公開するWebAPIやら、あるいは機能(例：メール送信)であったり、他のコンポーネント等とコミュニケートする口ということになると思いますが、コンポーネントが定まらないと決まらないように思います。

あと、蛇足かもしれませんが、私の周りでコンポーネント図を書いている人を見たことありません。
結構コンサルやSIerやいろいろな会社の人と仕事をしているのですが…。シーケンス図はよく見かけます。

オブジェクト指向でがっつり作るという作り方は最近は減少傾向にあるようで、その代わりマイクロサービスアーキテクチャーや、そこまでいかなくてもクラウドやSaaSを組み合わせてうまく１つのソリューションにするという作り方が流行ってきているように思います。

そのため、下記のようなアーキテクチャー構成図をよく見かけます。
https://learn.microsoft.com/ja-jp/azure/architecture/browse/

参考：UMLのトレンドは下降してます
https://trends.google.co.jp/trends/explore?date=all&geo=JP&q=UML&hl=ja

詳しい説明ありがとうございます。

理解が深まりました。