Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => UML SysML и пр. => Тема начата: kollega от 28 Августа 2009, 18:49:38
-
На вход (пина) действия "Согласования" попадает объект "Документ" и выходит 2 пина ( с типом "документ" и типом, скажем, резолюция, ). Далее по идее должны идти 2 объектных потока на decision, в котором имеется 2 решения: если не согласовано, то возвращает на действие выше по уровню например на действие "подготовку документа", а если согласовано, то идти на вход нового действия "Подписание".... Вопрос: сколько должно показываться потоков после decision, которые идут на "подготовку документа" и на "Подписание"?
-
Decision - это точка принятия решения, как минимум два потока. Но реально поток всегда одни, прочо могут быть разные направления потоков. Decision - стрелка на рельсах - поезд не может поеххать сразу по двум направлениям - верно?
Т.е. Decision - показывает возможные пути, но конкретный поток идет по одному пути. Если нужно убрать ветвление путей-направлений используется Merge, который опять не сводит несколько поток в в один, а сливает разные пути в один.
Так что попробуйте сформулировать вопрос точнее. И действительно, зачем описывать словами то, что проще изобразить на картинке.
-
нотация - UML 2, рассматриваем Activity diagram
Здесь есть 2 вопроса:
1. Если на вход decision node поступает 2 объектных потока обязательно ли, чтобы выходило также 2 объектных потока? Если нет, то как его можно уничтожить, показать это на схеме (например в случае, если на подписание надо отправить только документ и сохранение резолюции в datastore не требуется)?
2.Было бы шакарно разместить операцию добавления резолюции в datasore "Решения по документу" на месте между output pin "Резолюция" действия "Согласования" и decision node, а не после decision node. В таком случае, какой flow будет после datastore? Если это будет control flow, то decision не сможет выбрать, согласован документ или нет (потому что именно резолюция содержит информацию, согласован ли документ)? Если это будет объектный поток, то как избавляться потом от него после decision (ведь насколько я знаю, кол-во объектов до входа на decision = кол-ву объектов после входа на decision, см. вопрос 1)?
-
kollega,
Просьба постить темы в нужный раздел сразу.
-
Прошу прощения, немного не разобрался (поэтому и новичокс)
-
У меня склаывается ощущение, что на диаграмме постоянно путаются потоки данных и управления.
Если речь идет о UML 2, то могу сказать следующее:
На входе и выходе decision могут быть только потоки управления.
нотация - UML2, вы правы: "На входе и выходе decision могут быть только потоки управления."
-
нотация - UML2, вы правы: "На входе и выходе decision могут быть только потоки управления."
Если поток один и это поток данных, то подразумевается, что в нем присутствует поток управления.
-
Это для меня новая информация. Денис, можно цитату из спецификации с четким указанием, что поток данных можно заводить на вход decision?
Про DecisionNode аккуратно прочитайте.
The edges coming into and out of a decision node must be either all object flows or all control flows.
-
Вопрошающему стоило указать, реальные решения:
- продублировать decision-ы для потока документов и для потока резолюций;
- укрупнить объектные токены, чтобы в 1 токен влезала пара документ+резолюция;
- забыть про datastore как про страшный сон.