UMLアクティビティ図でネストされたアクションを表現するにはどうすればよいですか?


16

この質問は非常によく似ているこのいずれかが、答えは私のニーズと一致していません。特定のUMLツール(Papyrus)に焦点を当てていますが、私の質問はUMLについてより一般的です。

ネストされたアクションアクティビティ図で表現したいと思いますが、それを行う一般的な方法はわかりません。考え方は、他のアクションと同じスコープのアクションがありますが、その実行はより複雑であるということです。他のレベルと同じレベルでこのアクションを表示できるようにしながら、その実行に関する詳細を表示したいと思います。

ある種の「バックホーム」アクティビティを示すアクティビティ図である以下の例では、ネストされたアクションがアクションに含まれていPet the catます。この図には別の潜在的なエラーがあることに注意してください。質問の最後の正誤表を参照してください。

最後に家に帰る

構造化ノードを使用しましたが、それが正しい方法であるかどうかはわかりません。そのため、質問です。ステートチャートでは、同等のものは複合状態になりますが、複合アクションについては何も見つかりません。構造化されたノードについては、それに関するいくつかのドキュメントを読んだ後、それがどのように使用されるべきかをまだ本当に理解していないので、この図ではまったく間違っているかもしれません。

また、下の画像のように、トライデントシンボルで別のサブアクティビティを参照する可能性があることも知っていますが、同じ図にすべての情報が必要なので、ニーズに一致しません(印刷できるようになります情報の損失なし)

トライデントサブアクティビティ

では、そのようなネストされたアクションを表す標準的な方法は何ですか?標準では、一般的に見られ、可能であればほとんどのUML設計ツールで実行可能な有効なUMLを意味します。

無関係な正誤表:私の図では別のことが間違っています。同じアクション(Scratch behind the ears)に来る矢印は、アクションに入る前にマージノードに移動する必要があります。このJOTの引用を含む以下のコメントを参照してください。


あなたはこれについて尋ねませんでしたが、「耳の後ろに引っかく」というアクションは決して実行できないことを指摘したいと思います。これが本当である理由を誰もが知っていますか?
ジムL.

よくわかりませんが、上司に最終的に与えた図が次のように見えるので、猫の気質であることを願っています:/
Tim

その理由は、両方のパスからのトークンをアクションに提供する必要があるためです。開始することは不可能です。
ジムL.

@JimL。この状態に入るには両方の条件が真でなければならないということですか?それでは、私が表現したいことを表現する方法は何でしょうか?州の入り口の前のダイアモンドノードの結合?
ティム

私たちは州ではなく行動について話している。しかし、はい、この問題を解決するにはマージが必要です。
ジムL.

回答:


23

どちらも「標準」です。UML仕様による最初の図は

構造化されたアクティビティノード

StructuredActivityNodeは、ActivityGroup(サブ節15.6を参照)であり、その動作が含まれるActivityNodesおよびActivityEdgesによって指定されるアクションです。他の種類のActivityGroupとは異なり、StructuredActivityNodeは含まれるActivityNodesとActivityEdgesを所有するため、ノードまたはエッジは1つのStructuredActivityNodeにのみ直接含めることができます。ただし、StructuredActivityNodesはネストすることができます(StructuredActivityNodeとして、ActionとしてもActivityNodeです)。したがって、エッジまたはノードは、多数のネストされたStructuredActivityNodesに間接的に含まれることがあります。

活動グループ

ActivityGoupsは、ActivityNodesおよびActivityEdgesのグループ化構成です。ノードとエッジは複数のグループに属することができます。このサブ句は、ActivityPartitionsとInterruptibleActivityRegionsの2種類の具体的なActivityGroupsについて説明します。StructuredActivityNodesはActivityGroupの3番目の種類ですが、アクションでもあり、アクションの条項16のサブ条項16.11で説明されています。

2枚目の写真は

呼び出しアクション

InvocationActionは、直接または間接的にBehaviorの呼び出しを引き起こすアクションです(サブ句13.2を参照)。InvocationActionsには、操作または動作を呼び出すため、および以前にインスタンス化された動作を開始するためのCallActionsが含まれます。追加の種類のInvocationActionsを使用すると、信号や他のオブジェクトをターゲットに送信したり、利用可能な受信者に信号をブロードキャストしたりできます。

両方のケースの主な違いは再利用です。最初の場所では1つの場所(あなたのPet the cat)で多少の複雑さがありますが、2番目の場所は複数の場所で特定のアクションを(再)使用する場合です。ただし、1回のみ使用する場合でも、呼び出しバリアントを使用する傾向があります。ここで、複合ダイアグラム(EAではdbl-clickで開く)を追加して、対応するアクションの詳細を表示します。メインフローは概要を表示するだけで、詳細が必要な場合は、dblキーを押すだけです。

現在、EAで複合ダイアグラムを作成することは(再び)異なります。パッケージレベルでADを作成してから、これを呼び出し要素にドラッグする必要があります。これで、dblキーを押しながらクリックすると、埋め込み図が開きます。


ご回答ありがとうございます。どの可能性を使用するかについて、詳細を教えてください。ユーザー側でUML仕様を読むのは非常に難しいと思います。
ティム

就寝前の講義ではありません:-)もう少し説明を加えてみましょう。
qwerty_so

私は別のEAUIについて発言して更新しました。
qwerty_so
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.