Автор Тема: (UML2 Activicy diagram) Есть ли в это диаграмме аналог "OR" как на IDEF3?  (Прочитано 3842 раз)

LesheyEst

  • Newbie
  • *
  • Сообщений: 9
  • Рейтинг читателей: 0
    • Просмотр профиля
Здравствуте формучане!

Вопрос такой, как правильно отобразить такую ситуацию:
   Если на Fork создаются маркеры для веток A,B, то на Join создается маркер только если пришли маркеры с веток A,B.
   Если на Fork создаются маркеры для веток A,C, то на Join создается маркер только если пришли маркеры с веток A,C.
   Если на Fork создаются маркеры для веток A,B,C, то на Join создается маркер только если пришли маркеры с веток A,B,C.
   ...
И вообще возможно ли это в UML2?
Заранее благодарен.


Виктор Малышко

  • Гость
Полного аналога нет.
Несовсем ясно, что именно Вы хотите промоделировать. Fork всегда создаёт все три исходящих маркера, если в него приходит маркер. Т. о. не может быть тех "если", о которых вы пишите в 1-м и 2-м пункте.

Galogen

  • Member of CAR
  • Hero Member
  • *****
  • Сообщений: 6158
  • Рейтинг читателей: 198
  • Аксакал
    • Просмотр профиля
    • Профиль в Моем Круге
Присоединюсь к Виктору, что вы хотите промоделировать - не совсем ясно, что у вас изображено
« Последнее редактирование: 07 Апреля 2013, 19:38:50 от Galogen »

LesheyEst

  • Newbie
  • *
  • Сообщений: 9
  • Рейтинг читателей: 0
    • Просмотр профиля
Ситуация такая, происходит регистрация плановых начислений и удержаний.
Эти самые плановые начисления и удержания могут регестрироваться 7-мью   различными документами. Причем не обязательно формировать их все сразу, если будет сформирован хотябы один это уже будет считаться, что плановые начисления и удержания зарегистрированы. Вот и возникает вопрос, как же тогда сложившуюся ситуацию изобразить на диаграмме активности?

Galogen

  • Member of CAR
  • Hero Member
  • *****
  • Сообщений: 6158
  • Рейтинг читателей: 198
  • Аксакал
    • Просмотр профиля
    • Профиль в Моем Круге
Ситуация такая, происходит регистрация плановых начислений и удержаний.
Эти самые плановые начисления и удержания могут регестрироваться 7-мью   различными документами. Причем не обязательно формировать их все сразу, если будет сформирован хотябы один это уже будет считаться, что плановые начисления и удержания зарегистрированы. Вот и возникает вопрос, как же тогда сложившуюся ситуацию изобразить на диаграмме активности?
Немного стало яснее. Мне кажется, использование распараллеливания здесь не допустимо. Мне кажется и использование асинхронного OR в IDEF3 не будет правильным. По сути тут идут два процесса: начисление и удержание. Они могут быть выполнены различными документами, что вы представляете как 7 разных действий или деятельностей, а действительно ли они разные эти действия?

Вот в BPMN есть такой ad hoc процесс, мне кажется, это отражает вашу особенность наилучшим образом, но как простым способ изобразить в ДД - не знаю.

Скажите, пожалуйста, каким образом возникает потребность использования одного из 7 документов или нескольких для определения назначений и удержаний?

LesheyEst

  • Newbie
  • *
  • Сообщений: 9
  • Рейтинг читателей: 0
    • Просмотр профиля
Вот как описывают подсистему расчет зарплаты в сомой 1С. Хотел эту схему представить в UML2

Galogen

  • Member of CAR
  • Hero Member
  • *****
  • Сообщений: 6158
  • Рейтинг читателей: 198
  • Аксакал
    • Просмотр профиля
    • Профиль в Моем Круге
Вот как описывают подсистему расчет зарплаты в сомой 1С. Хотел эту схему представить в UML2
И?
« Последнее редактирование: 20 Апреля 2013, 20:34:20 от Galogen »

Виктор Малышко

  • Гость
Вот как описывают подсистему расчет зарплаты в самой 1С. Хотел эту схему представить в UML2
Приведённая схема описывает взаимосвязи документов, а не передачу управления. Поэтому транслировать её в диаграмму деятельности не совсем корректно. Однако, если стоит такая задача, можно подойти формально, и для каждого узла исходной схемы вроде "обработка", "расчёт", "регистрация" создать узел действия на диаграмме деятельности, а для каждого узла вроде "документ", "справочник", "регистр" -- соответствующий объектный узел. Полученные узлы следует соединить потоками данных, ориентируясь на исходную схему. Для нижнего узла дополнительно следует создать узел действия "Объединить результаты расчётов" и разместить его между объектными узлами, представляющими промежуточные результаты и объектным узлом "Результаты расчётов".