Как представить архитектуру на основе событий в статической модели UML?

Question

У меня довольно простая система, основанная на событиях C #, но я не уверен, как ее смоделировать в UML. Я хочу показать список издателей событий, подписчиков, обработчиков и классов EventArgs. Я думаю, что вы используете «сигналы», но я не могу найти примеры. Кто-нибудь может указать мне на пример или пролить свет?

Спасибо

Редактировать: Я создаю статическую модель, мне не нужно представлять состояние или пути в процессе. Извините, если я не прояснил это в первоначальном вопросе ..

Answer 1

Шаблон пар «Издатель-подписчик» (a.k.a «Наблюдатель») может быть реализован по-разному в каждой среде программирования (языка), поэтому в U.M.L.

В любом случае, концептуально, когда отправляется событие («сигнал» или «сообщение») от издателя (он же «сервер») любому подписчику («клиент»), иногда «идентификатор» для идентификации определенное событие, из других событий, его предоставленное, и некоторые дополнительные параметры или данные, которые это также послало.

Как уже упоминалось в других ответах, вам может потребоваться диаграмма (класса) для описания статической модели. (Обратите внимание, что существует «агрегация», а не «состав», можно использовать «ассоциацию»):

..............................
+--------------------------+..
|      <<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            |..
+--------------------------+..
..............................

А также вам может потребоваться диаграмма для описания динамической модели:

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

Стереотипы в США - ваши "собутыльники", и позволяют вам описать или ограничить, что актер, объект, класс, черта, или интерфейс делает.

Когда вы используете их, выделите, когда объект или класс, являются подклассами класса или реализовать, интерфейс, который имеет отношение к деятельности, которые были моделью, даже если есть другие родительские классы, или интерфейсы.

Приветствие.

Answer 2

Как указывают lexu и John, вы можете использовать диаграммы состояний и диаграммы действий для моделирования некоторых динамических аспектов вашей системы.

Для вашей статической модели вы можете смоделировать события, которые класс может обрабатывать как операции. Вы можете использовать стереотип (<<event>>), чтобы отличать эти операции от других (например, синхронно вызываемые методы).

Answer 3

Подход к проблеме с точки зрения истории жизни объекта (моделирование событий, ссылка, например, Jackson System [of] Development ):

UML и моделирование данных: согласование Дэвид С. Хей Ссылка стр.34

Эволюция программного обеспечения с использованием UML и XML под редакцией Хунцзи Ян «Истории жизни сущностей - проблемы и проблемы», стр. 142 - Я не согласен, между прочим, последовательность Diag. может быть применен относительно легко, если он ограничен рассматриваемой организацией, в то время как состояние диаг. успешно иллюстрируется в Архитектура программных систем, Ник Розански, Эоин Вудс , «Модели жизненного цикла информации», стр. 317.

Answer 4

Я бы, вероятно, просто использовал модель логического компонента для представления источников / потребителей и стереотипных операций для описания взаимодействий.

Однако, как идея левого поля - для меня возникает еще одна возможность .....

Интересно, не могли бы вы использовать некоторые аспекты BPMN? - множество инструментов uml, таких как sparx ea, включают его

Его синтаксис сообщений должен позволять вам описывать исходные события, и вы сможете описывать потребителей / обработчиков, используя пулы или действия, не обязательно заботясь о внутреннем поведении (я думаю об уровне абстракции похож на "уровень 1" Брюса Сивера) Точно так же вы можете использовать обмен сообщениями для разделения полезных данных / EventArgs

если вы используете что-то похожее на sparx, вы, вероятно, могли бы добавить зависимости трассировки от элементов bpm к "реальной" модели класса кода c #.

Answer 5

посмотрите здесь для примеров диаграммы состояний и здесь для диаграммы активности, затем выберите то, что соответствует вашим потребностям!

Answer 6

Используйте диаграмму состояний или диаграмму деятельности.