IIRC、ユースケースはシステムの典型的な使用法を説明していますよね？しかし、ユースケース図に属するthin [g]と、それらをどのように接続するのでしょうか。
ユースケース図（はい、一般的なプロジェクトには複数あります）は、おそらくUMLスイートで最も単純な図であるはずです。定義したアクター/ロールをシステムのユースケースに直接マッピングする必要があります。実際、彼らは主に単一のアクターに焦点を合わせ、特定のユースケースに参加する必要がある場合にのみ他のアクターを含める必要があります。
これが私がグーグルを降りた例です：
サンプルのユースケース図http://java.sun.com/mailers/newsletters/fundamentals/img/usecase.png
単純さに注意してください。1つのアクター、1つのシステム、5つのユースケース。他には何もありません。
また、@ Eric Pが提案し、私の例の画像が示すように、ユースケースに「[Verb][Object]」構造のタイトルを付ける必要があります。つまり、「メンバーが本を借りる」は「本を借りる」になります。ユースケース文の欠落しているサブジェクト（「メンバー」）は、ユースケース図に、ユースケースに関連付けられたアクターとしてエンコードされます。
システムを使用しているのは従業員です。メンバーはまだ俳優としてここに属していますか？
その答えは主観的なものではないかと思います。システムは従業員によってのみ使用されているため、従業員が唯一のアクターであると言う人もいます。私は個人的に同意しません。
なんで？1つは、ユースケースは要件収集フェーズの一部です。これらは、システムの最終的な機能を整理するのに役立ちます。Memberしかし、単にテクノロジーが使用されないという現在の信念のためにアクターを拒否することMemberは、そのフェーズで自分自身を制限することです。
最終的なシステムが自動化されている場合、つまり、Member自分で本をチェックアウトするために端末に行く場合はどうなりますか？要件の収集中に仮定を行った場合、重要な機能を見逃す可能性があります。
編集：一連の行動はどのように記述されていますか？繰り返されるある種のルーチンへのメソッド呼び出しのようなusesアソシエーションを見ることができると言われましたか？これは正しいですか？そして、拡張はどのように使用されますか？
ユースケース図は高レベルです。それらは、あなたの高レベルの機能（各ユースケースの形で）とそれらを利用するアクターだけを示す必要があります。ユースケース図にextendsとincludesを散らかさないでください。それらはまれで、特別な場合のみでなければなりません。あなたが犯す可能性のある最大の新人の間違い（そして私を信じて、私はそれを成し遂げました！）は、ユースケース図内でコードをモジュール化しようとすることです。はい、私は知っています、それは彼の塩に値するプログラマーが最初にやろうとすることですが、ユースケース図はそれのための場所ではありません。
アクションのシーケンスに関して：典型的なUMLダイアグラムのスイートでは、各ユースケースに1つ以上のアクティビティダイアグラムが関連付けられています。これらはフローチャートにほぼ類似しており、ほとんどのソフトウェアエンジニアリングの教科書が推奨する典型的なユースケースの物語構造のグラフィック表現として機能します。
とにかく、これがお役に立てば幸いです。他にご不明な点がございましたら、お気軽にお問い合わせください。
