スタティックUMLモデルでイベントベースのアーキテクチャを表現する方法は？

Question

私はかなり基本的なC＃イベントベースのシステムを持っていますが、どのようにUMLでモデル化するのかはわかりません。私はobviosulyイベントパブリッシャー、サブスクライバー、ハンドラーとEventArgsクラスを表示したい。私はあなたが '信号'を使用すると思いますが、私は例を見つけることができません。誰かが私を模範にしたり、光を放つことができますか？

おかげ

編集：私は静的なモデルを作成していますが、私はプロセスを通じて状態やパスを表す必要はありません。申し訳ありませんが、私は最初の質問で明確にしていない場合..

Answer 1

状態図またはアクティビティ図を使用してください。

Answer 2

状態図の例についてはhere、アクティビティ図の場合はhereとし、必要に応じて選択してください。

Answer 3

lexuとJohnが示すように、ステートチャートとアクティビティ図を使用して、システムの動的な側面のいくつかをモデル化することができます。

静的モデルでは、クラスが操作として処理できるイベントをモデル化できます。ステレオタイプ（<<event>>）を使用して、これらの操作を他と区別することができます（たとえば、同期的にメソッドと呼ばれます）。

Answer 4

私はおそらくちょうど左のフィールドのアイデアとして。しかしながら相互作用を記述するためのソース/消費者やステレオタイプの操作を表現するために

を論理的なコンポーネントモデルを使用したい - 別possbilityは私にocurrs ....

BPMNのいくつかの側面を利用できるかどうかは疑問です。 - sparx eaのようなumlツールの多くにはそれが含まれています

メッセージの構文では、ソースイベントを記述できるようにし、プールやアクティビティを使用してコンシューマ/ハンドラを記述することができます。内部の挙動（私はブルース・シヴァーの「LEVEL1」BPMNに似た抽象化のレベルを考えています） 同様に、あなたがあればペイロード/ EventArgsの

をsepcifyするメッセージングinteractionnsを使用する場合があります;。スパークスと類似気にいらを使用して再、おそらくbpm要素からのトレースの依存関係をc＃コードの「本当の」クラスモデルに追加することができます。

Answer 5

"パブリッシャー - サブスクライバー"のペアパターン（a.k.a "オブザーバー"）は、各プログラミング（言語）フレームワークで異なるように実装されているため、U.M.L.

イベント（「シグナル」または「メッセージ」）がパブリッシャ（別名「サーバ」）から任意のサブスクライバ（「クライアント」）に送信される場合、概念的には、識別するための「id」特定のイベント、他のイベントからのイベント、そのイベント、およびいくつかの追加のパラメータまたはデータも送信されます。

その他の回答が既に記載されているので、静的モデルを記述するための（クラス）図が必要な場合があります。

......................................... 
+----------------+..+----------------+... 
| <<Publisher>> |..| <<Subscriber>> |... 
| VectorDrawApp |..|  Figure |... 
+--------+-------+..+--------+-------+... 
.........|...................|........... 
.......+-+-+...............+-+-+......... 
.......| |...send(fill)..| |..Fill(). 
.......| +==============>+ +---+..... 
.......| |...............| |...|..... 
.......| |...<<return>>..| |...|..... 
.......| |<--------------+ +<--+..... 
.......| |...............| |......... 
.......+-+-+...............+-+-+......... 
.........|...................|........... 
.........X...................X........... 
......................................... 

：動的モデルを説明するための図を必要とするかもしれない、また

.............................. 
+--------------------------+.. 
|  <<Publisher>>  |.. 
|  VectorDrawApp  |.. 
+--------------------------+.. 
| [+] create()    |.. 
+--------------------------+.. 
| [+] send(EventArgs e) |.. 
+------------+-------------+.. 
............/ \............... 
............\ /............... 
.............|................ 
.............|................ 
+------------+-------------+.. 
|  <<Subscriber>>  |.. 
|   Figure   |.. 
+--------------------------+.. 
| [+] create()    |.. 
+--------------------------+.. 
| [+] receive(EventArgs e) |.. 
+--------------------------+.. 
.............................. 
+--------------------------+.. 
|  <<Event>>   |.. 
|  EventArgs   |.. 
+--------------------------+.. 
| [+] Sender: TObject  |.. 
+--------------------------+.. 
| [+] receive(EventArgs e) |.. 
+------------+-------------+.. 
.............|................ 
.............+................ 
............/ \............... 
...........+---+.............. 
.............|................ 
+------------+-------------+.. 
|  <<Event>>   |.. 
| FillEventArgs: EventArgs|.. 
+--------------------------+.. 
| [+] ForeColor   |.. 
| [+] BackColor   |.. 
| [+] FillStyle   |.. 
+--------------------------+.. 
.............................. 

そして：（ない、「関連」を使用することができる「組成物」、「集約」があることに注意してください）

ステレオタイプ（UML形式）あなたの "お酒を飲む仲間"、 であり、俳優、オブジェクト、クラス、 の特質やインターフェースが何を記述したり制限したりすることができます。他の親クラスが存在する場合であってもモデルとなっている

あなたがそれらを使用して、オブジェクトやクラス、 がクラスのサブクラスである、または実装ハイライト、 活動に関連するインターフェース、 、 またはインターフェイス。

乾杯。

Answer 6

エンティティの生活史の角度から問題へのアプローチ（イベントモデリング、REF、例えば、Jackson System [of] Development。）：

UML and Data Modeling: A Reconciliation By David C. Hay のRef。 p.34

Software Evolution with UML and XML edited by Hongji Yang 'エンティティライフヒストリ - 問題と問題'、p142 - 私はbtw、シーケンスdiagに同意しません。状態の診断中に問題のエンティティに限定されていれば比較的容易に採用することができる。 Software Systems Architecture, Nick Rozanski, Eoin Woods、 'Information Lifecycle Models'、p 317に正しく示されています。