スレッドを表現するための直感的なUMLアプローチはありますか
私はUML図を使用してソフトウェアを説明するのが好きです。ほとんどの場合、図は私自身が使用するためのものであり、より複雑なコードや相互作用などに使用します。将来、図を振り返ることができるというメリットがあります。
私がいくつかの異なる方法を実行していることに気付いたのは、スレッドを図解することです。スレッドはその性質上、より複雑なコードにポップアップする傾向があり、それらを追跡することが私の設計ドキュメントの主な目的であることがよくあります。
以前、シーケンス図でシンボルを使用して新しいスレッドの作成を示しましたが、いくつかの図を振り返ると、オブジェクトの存続期間（シーケンス図の対象）とスレッドの存続期間があいまいになることがあります。スレッドをUMLに組み込むためのより良いアプローチはありますか？
描いたときに自分に合った図を作ることができました。基本的な前提は、クラスインスタンスを表す灰色のボックスと、スレッドの存続期間を表す青いボックスを重ね合わせたことです。それが私に追跡させてくれる主なことは、特定のメソッドを呼び出すときにどのスレッドで実行するかを知ることです。
スレッドとクラスのモデリングを行うためのより優れた、より直感的な方法があることは間違いありません。私にとっての成功の尺度は、私自身の図が6か月後に同じレベルの理解を私に与えてくれるかどうかです。
アクティビティ、シーケンス、および状態図は、すべてスレッドの動作を示す正しい方法です。
1st：（vsのコメントへ）UMLには、静的構造と動作の2つの図またはモデリング要素があります。どんな本でも、通常は内容/目次で分割を理解するのに役立ちます。さらに、私の意見では、マーティンファウラーのUML蒸留されたほぼ事実上の標準の11ページで見ることができます。
2番目：（sipwizの質問とコメントへ）アクティビティ図は、ビジネスプロセスをモデル化するために一般的に理解されていませんが、そのために使用できます。簡単なチュートリアルは、ビジネスの観点からそれにアプローチします。
スレッドをモデル化するためのオプションに関する議論：
アクティビティ図-BARと使用ラインを使用して、同時実行をフォークおよび指定できます。下部の例はビジネスプロセスではないことに注意してください 例 。ほとんどの人は、これら、ビジネス、管理、および開発者を読むことができますが、詳細が不足したり、乱雑になったりすることもあります。
シーケンス相互作用図-同じ投稿で 例 、シーケンス図を使用すると、シーケンス内の並列動作を指定できます並列化可能な動作を「par」というラベルでボックス化することにより、これは、どのメソッドを並列に、つまり異なるスレッドで呼び出すことができるか、または呼び出す必要があるかを読者に示すのに役立ちます。これは、オブジェクトの構築に関する議論など、詳細な開発者に使用する方法です。
状態図-アクティビティと同じように、状態チャートはBARと使用ラインを使用して同時実行を可能にします。
注：これらは特定のスレッドをモデル化せず、正確なリフトサイクルです。モデリングのインスタンス/ランタイムレベル。これが必要な場合は、質問を明確にしてください。回答します。 MDA/UMLの専門家以外はあなたを呼び出さず、実行中のシステムを生成していないので、上記のいずれかを使用してモデル化します。
また、詳細はほとんどのUMLブックに記載されていることに注意してください。また活用： http://www.jguru.com/faq/view.jsp?EID=56322
従来、スレッドはペトリネットを使用して図式的に描かれてきました。 Rob Martinは 記事 UMLのマルチスレッドについて持っています。
更新-アクティビティ図でフォークを使用してスレッドを表すことができることを思い出しました-私はなんとか これを説明する何かを見つける 。
ペトリネットの無料チュートリアルを見つけるのは非常に難しいですが、ペトリネットが並行性のモデリングに適していることはわかっているので、Googleで「生産者/消費者ペトリネット」（私のお気に入りのスレッド）と これを見つけました 。
また、ペトリネットを示すスライドもいくつか見つかりました セマフォのモデリング 。
UMLアクティビティ図には、ロジックの並列フローを示すためのフォーク要素と結合要素があります。
方法はわかりませんが、スレッドがThread（または同様の）クラスとして実装されている多くの言語であることを考えると、シーケンス図の使用は完全に不適切とは思えません。
最もUML互換の方法は、おそらく「オブジェクト」がスレッドを表すことを示す何らかの注釈を追加することです。
UMLはUML上部構造によって定義されており、ここで見つけることができます http://www.omg.org/spec/UML 。仕様を読むと、UMLクラスをアクティブにできることがわかります。アクティブクラスは、メタ属性isActiveがtrueに設定されているクラスです。また、描写も異なります。アクティブクラスのオブジェクトインスタンスは、「分類子の動作」を自動的に実行します。すべての動作については、非同期シグナルを待機し（AcceptEventActions）、メソッドを呼び出す（CallOperationAction）またはその他の動作（CallBehaviorActions）を実行するアクティビティを使用して定義できます。これが、アクティブオブジェクトがUMLでモデル化される方法です。 UML仕様を読む必要があります。
アクティビティ図は、ソフトウェアの内部動作をスレッドを表すためのフォークと結合でモデル化します。これを適切にモデル化する方法を正確に見つけるには、ConradBockの優れた一連の記事を参照してください。 ここ はフォークと結合をカバーする記事ですが、「カラーペトリネット」を使用して適切にモデル化する方法を学ぶには、シリーズの最初の記事に戻るリンクをたどる必要があります。それはあなたの考え方ではありません（そしてそれはかなり簡単です）！
[〜＃〜] omg [〜＃〜] と呼ばれる言語の新しいインプロセス標準があります Alf アクティビティのより便利な表面表記を提供しますダイアグラムであり、コードを表すことを目的としています。仕様から：
アクション言語の主な目標は、UMLの通常のグラフィカルな表記法を使用して主に表される、より広いモデル内で実行可能な動作を指定するための表面表記法として機能することです。たとえば、これには、クラスの操作に関するメソッドや、ステートマシンでの遷移効果の動作が含まれる場合があります。
プログラマーにとって、おそらくAlfよりも直感的になることはできません。そして、それは完全にUMLアクティビティ図に変換されます。
UMLの最大の強みは、静的な構造を表現することです。短命のスレッドを使用している場合、それらを簡単に図解する方法もわかりません。状況を少し変えることで解決策を見つけることができるかもしれません：なぜスレッドを使用/必要とするのですか？彼らが提供する機能は何ですか？それらが相互作用し、いくつかの（メッセージパッシング）APIに従う場合、それらをコンポーネントとして描画することは理にかなっているかもしれません。