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

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

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

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

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

私の考えでは、
コンポーネント図におけるコンポーネントは、関心のあることを表現できるものであればよく、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