ユースケース図
私の図が正しいかどうかはわかりませんが、この数の包含関係があっても大丈夫ですか？
注：私のシステムシナリオ：ユーザーがWebページにアクセスしてTwitterユーザーアカウントを入力すると、システムは目的のユーザーのツイートを収集し、それらをクリーンアップして前処理し、分類して分類結果を計算し、最終的にユーザーに結果を表示します。
ユースケース図についてですか？
ユースケースは、それが何のために使用され、どのようにしてその環境のアクターに価値をもたらすかを示すことによって、検討中のシステムの全体像を与えるものとします。
「 値 」の概念は、ユースケースの識別に不可欠です。ここでの意図は、システムの動作方法や内部の相互作用を詳細に説明することではありません。それは目的についてです。図の各ユースケースは次のとおりです。
アクターに観察可能な価値の結果をもたらす、システムが実行する一連のアクションとバリアントのシーケンスの説明。
-イヴァルジェイコブソン
これをあなたの例に当てはめてみましょう：収集ツイート、きれいなツイート、前処理ツイート、ツイートを分類、結果を計算するすべてがステップであるように見え、個別に実行した場合、観察可能な結果やユーザーにとっての価値はありません。同様に、display resultsも独立したユースケースではありません。リクエストのコンテキストでのみ値があります。
しかし、あなたのシステムが何をしているかを読んでいるとき、私はユーザーがTwitterアカウントを入力して分類を取得したいと思っていることを理解しています。これは、ユーザーにとって本当に価値のある唯一のものです。
それが唯一のユースケースである場合、この図は少しやりすぎです。自発的に、私は2番目のユースケースが分類エンジンをトレーニングする（MLコンポーネントがあるため）と思われます。
それともあなたの処理チェーンの詳細についてですか？
ユースケースの内部、つまり実行される一連のアクションを表現する場合は、 アクティビティ図 の使用を検討できます。
いくつかの利点があります。処理フローが矢印で強調表示されます。処理フローで結合とフォークを表示することもできます。最終的には、プロセスステップ間で交換されるオブジェクトを強調表示できます。サードパーティコンポーネントの技術的な詳細を調べる必要がない場合（たとえば、ユースケースでは、独立したシステムをアクターとして示し、ライブラリではない場合）。
そのようなユースケースを分解すべきではありません。これは、関与するアクターとして比較的多くの外部システムを使用する「ユーザーの分類を要求する」単一の単純な使用例です。
ユースケースの処理方法を示す分解は、別の図で表す必要があります。複数の相互作用によるシーケンス図をお勧めしますが、アクティビティー図もそれを行います（あまり明確でない場合があります）。