Форум Сообщества Аналитиков
Общий раздел => Для всех => Тема начата: Belchona от 02 Ноября 2015, 09:44:28
-
Здравствуте!
Помогите, пожалуйста, определиться с выбором диаграммы.
Я ранее никогда не использовала UML, а сейчас необходимо отобразить жизнь банковского продукта в действиях 3 разных пользователей (ролей) в 3 различных системах.
Идея в том, что Клиент (роль 1) приходит к Посреднику (роль 2), который работает в 1 из систем, а далее в трех системах работают Банковские работники (роль 3). Роли могут взаимодействовать друг с другом Клиент также может работать в системе 1. Роли работают с разными сущностями в системах, среди которых можно выделить одну главную сущность - заявку Клиента.
Мое руководство хочет видеть действия этих ролей на одной схеме. Как это отобразить я ума не приложу. На диаграмме последовательности? Коммуникации?
Шагов в схеме много, схема подробная, и при этом она должна быть читаемой и наглядной.
Или идея утопична, и надо делить схему на разные диаграммы, например, отображая 1 роль на 1 диаграмме?
Есть у вас есть примеры, покажите, пожалуйста, как это обычно выглядит.
-
А почему обязательно UML, а не ARIS, BPMN, IDEF?
-
Примеров множество в гугле по запросу workflow diagram: https://www.google.ru/search?q=workflow+diagram&newwindow=1&espv=2&biw=1466&bih=932&source=lnms&tbm=isch&sa=X&ved=0CAYQ_AUoAWoVChMI2Lq9sefxyAIV6epyCh3RowRW
-
А почему обязательно UML, а не ARIS, BPMN, IDEF?
В BPMN не могу представить наглядную композицию. в IDEF тоже. ARIS у нас не очень принят, скорее UML.
-
Примеров множество в гугле по запросу workflow diagram: https://www.google.ru/search?q=workflow+diagram&newwindow=1&espv=2&biw=1466&bih=932&source=lnms&tbm=isch&sa=X&ved=0CAYQ_AUoAWoVChMI2Lq9sefxyAIV6epyCh3RowRW
Это понятно что вариантов много, проблема в том что их слишком много в гугл)
Пытаюсь сузить поиск, потому и обратилась сюда, если вдруг кто-то решал подобную задачу и уже знает как лучше это сделать.
-
https://www.google.ru/search?q=uml+swimlane&newwindow=1&espv=2&biw=1466&bih=932&source=lnms&tbm=isch&sa=X&ved=0CAYQ_AUoAWoVChMIyNK4sPPxyAIVReFyCh3taAVS#
-
<...>
Роли работают с разными сущностями в системах, среди которых можно выделить одну главную сущность - заявку Клиента.
Мое руководство хочет видеть действия этих ролей на одной схеме. Как это отобразить я ума не приложу. На диаграмме последовательности? Коммуникации?
<...>
Для графического отображения процессов этого уровня лучше всего подходит BPMN. Просто потому, что он и создавался под процессы этого уровня.
Если же всё упёрлось в UML - попробуйте перехитрить сами себя и сделать всё на Диаграмме Активностей. Тот же BPMN если не брать детали
-
Соглашусь с Андреем: BPMN или activity diagrams (http://www.uml-diagrams.org/activity-diagrams.html)
-
Смело рисуйте наклейки с действиями прямо на дорожках диаграммы, которую принято называть «диаграммой последовательности».
-
Примерно так. Только без прямоугольной лапши, которая должна иллюстрировать время обработки. Это визуальный мусор, от которого я не смог избавиться, когда рисовал диаграмму в EA.
-
Примерно так. Только без прямоугольной лапши, которая должна иллюстрировать время обработки. Это визуальный мусор, от которого я не смог избавиться, когда рисовал диаграмму в EA.
Вот пожалуйста
(http://www.uml2.ru/forum/index.php?action=dlattach;topic=6456.0;attach=5117)
Правда, не могу понять, чем это лучше той же диаграммы деятельности с дорожками.
-
Правда, не могу понять, чем это лучше той же диаграммы деятельности с дорожками.
Ничем не лучше. Это одно и то же.
-
Ничем не лучше. Это одно и то же.
В чем же сходство?
-
Ничем не лучше. Это одно и то же.
По моему это нецелевое использование диаграммы. Не путать со статьёй УК:). Зачем изобретать свою нотацию, если есть uml activity diagram? Вы не боитесь запутать неокрепшие умы? И ещё... Смотря на такую диаграмму сразу хочется прочитать надписи на стрелках.
-
По моему это нецелевое использование диаграммы. Не путать со статьёй УК:). Зачем изобретать свою нотацию, если есть uml activity diagram? Вы не боитесь запутать неокрепшие умы? И ещё... Смотря на такую диаграмму сразу хочется прочитать надписи на стрелках.
UML – не для неокрепших умов. Я на эту тему даже доклад делал на Analyst Days.
https://www.greesha.ru/speeches/%d0%bf%d0%be%d1%87%d0%b5%d0%bc%d1%83-uml-%d1%8d%d1%82%d0%be-%d0%bf%d0%bb%d0%be%d1%85%d0%be%d0%b9-%d0%b2%d1%8b%d0%b1%d0%be%d1%80-%d0%b4%d0%bb%d1%8f-%d0%be%d0%b1%d1%83%d1%87%d0%b5%d0%bd%d0%b8%d1%8f/
-
В чем же сходство?
В использовании одних и тех же элементов – ролей/акторов, дорожек и действий.
-
Смотря на такую диаграмму сразу хочется прочитать надписи на стрелках.
В данном случае стрелочки просто показывают последовательность действий во времени. Это не операции, не сообщения, не методы.
Вообще imho чем меньше текста на диаграмме, тем лучше.
Кстати, в учебниках по банковскому делу для таких описаний используют подобие Collaboration Diagram - на мой взгляд, худшей из всех диаграмм в истории UML. Примерно как на картинке. Очень жалко бедных студентов, которые по таким картинкам пытаются разобраться.
-
В данном случае стрелочки просто показывают последовательность действий во времени. Это не операции, не сообщения, не методы.
Вообще imho чем меньше текста на диаграмме, тем лучше.
Кстати, в учебниках по банковскому делу для таких описаний используют подобие Collaboration Diagram - на мой взгляд, худшей из всех диаграмм в истории UML. Примерно как на картинке. Очень жалко бедных студентов, которые по таким картинкам пытаются разобраться.
И всё же для меня остаётся непонятным, зачем использовать для целей указания последовательности действий Sequence вместо Activity diagram. Тем более что Activity больше похожа на обычую схему алгоритма и ветвления на Activity изображаются более лаконично и наглядно. Это более знакомо и привычно. Как студентам/выпускникам тех. вузов, так и тем, кто уже "вырос". А в случае применения sequence мы изобретаем новую нестандартную диаграмму, хотя есть стандартизованные аналоги.
-
И всё же для меня остаётся непонятным, зачем использовать для целей указания последовательности действий Sequence вместо Activity diagram. Тем более что Activity больше похожа на обычую схему алгоритма и ветвления на Activity изображаются более лаконично и наглядно. Это более знакомо и привычно. Как студентам/выпускникам тех. вузов, так и тем, кто уже "вырос".
В данном случае, как я понял из исходного поста, важно в первую очередь показать порядок действия нескольких пользователей и систем. Для этого лучше всего использовать дорожки.
Activity Diagram, корни которой лежат в блок-схеме алгоритма, лучше всего подходит для показа последовательности действий "в одном потоке". Хотя её тоже можно нарезать на столбцы, как на приведенном рисунке, но в этом случае получается примерно то же самое, что я предлагаю. При этом столбцы содержат больше визуального мусора.
А в случае применения sequence мы изобретаем новую нестандартную диаграмму, хотя есть стандартизованные аналоги.
Что значит "стандартизованные"? Если речь об UML, то в нём слишком много элементов, причём назначение некоторых трудно понять, специально не изучая язык. Если нельзя исходить из того, что все, кто будет пользоваться диаграммой, знакомы с UML, то нужно использовать самые простые и интуитивно понятные элементы. "Дорожки" imho являются как раз таким элементом.
-
Вот пожалуйста
Спасибо! Перерисовал, получается примерно так.
В данном случае присутствует роль, не выполняющая никаких действий. При этом она является неотъемлемой частью диаграммы, которая как раз и призвана продемонстрировать, что инкассовые поручения выполняются без участия владельца счёта, и повлиять на этот процесс он никак не может.
-
Хотя её тоже можно нарезать на столбцы, как на приведенном рисунке, но в этом случае получается примерно то же самое, что я предлагаю. При этом столбцы содержат больше визуального мусора.
По-моему весь этот "визуальный мусор" наоборот акцентирует внимание на сути процесса, а также более привычен как тем, кто знает UML, так и тем, кто не знает UML, но знаком с блок-схемами алгоритмов. Сейчас мы можем скатиться к спору о вкусах:)
Что значит "стандартизованные"? Если речь об UML, то в нём слишком много элементов, причём назначение некоторых трудно понять, специально не изучая язык. Если нельзя исходить из того, что все, кто будет пользоваться диаграммой, знакомы с UML, то нужно использовать самые простые и интуитивно понятные элементы. "Дорожки" imho являются как раз таким элементом.
Если говорить о тех, кто ни разу не видел UML и блок-схемы алгоритмов, тогда я, возможно, согласился бы. Но таких, по моему опыту, мало. Всем остальным привычнее будет Activity диаграмма. Тем более что видов элементов Activity диаграмм очень немного. "Дорожки", как Вы сказали, также могут применяться с Activity диаграммой.
-
Гриша, но если построить активити диаграмму не как алгоритм, а как сценарий (который ты изображаешь малопонятной на мой взгляд диаграммой последовательности с придуманными от себя элементами), то вообще не понятно зачем ты завел речь о диаграмме последовательности.
Впрочем понятность или непонятность вещь субъективная и для ее оценки требуется научное исследование: описание небольшой задачи, изображение ее в виде разных диаграмм, формирование репрезентативной экспертной группы, проведение эксперимента оценивания: путем выбора лучшей диаграммы на взгляд эксперта; путем независимого оценивания уровня понятности каждой диаграммы отдельно :)
-
Гриша, но если построить активити диаграмму не как алгоритм, а как сценарий (который ты изображаешь малопонятной на мой взгляд диаграммой последовательности с придуманными от себя элементами), то вообще не понятно зачем ты завел речь о диаграмме последовательности.
А что, действительно получилось малопонятно? :( А чего, на твой взгляд, не хватает, чтобы было понятнее?
Речь о "диаграмме последовательности" я завёл только потому, что другого общепринятого названия для диаграммы с дорожками я пока не знаю. Хотя это название imho крайне неудачно (в UML вообще проблема с интуитивно понятными названиями диаграмм).
-
А чего, на твой взгляд, не хватает, чтобы было понятнее?
Григорий,
Изобразите пожалуйста пару гейтов "и/или" в Вашем варианте.
Давайте предположим, что "Снять деньги со счёта" не получилось по причине недостатка средств.
А потом ещё изобразим реакцию Получателя на отказ.
Интерес не праздный.
У меня реально ступор с этой диаграммой и именно из-за гейтов.
В скрепке - схема, которая реально лучше смотрелась бы на диаграмме последовательностей, но я пока не нашёл честного способа разделить потоки на условиях
-
Ну или вот ещё пример (скрепка).
Схема чисто саннидэй. По хорошему, нужно отобразить на ней проверки и ответы статусами "упешно/нет", но ни Sparx ни StarUml не предлагают готовых элементов "ветвление" для этой диаграммы (панель на скрине).
Какой тут бест-практис то ? :))))
-
Ну или вот ещё пример (скрепка).
Схема чисто саннидэй. По хорошему, нужно отобразить на ней проверки и ответы статусами "упешно/нет", но ни Sparx ни StarUml не предлагают готовых элементов "ветвление" для этой диаграммы (панель на скрине).
Какой тут бест-практис то ? :))))
Начал отвечать на предыдущий пост и тоже столкнулся с тем, что самые удобные редакторы не позволяют положить ромбик выбора на дорожку. Значит, опять буду рисовать в paint :) (На самом деле, в OpenOffice Impress)
Я подробно отвечу на предыдущий вопрос позже, а пока просто приложу ещё одну картинку.
-
Ну или вот ещё пример (скрепка).
Схема чисто саннидэй. По хорошему, нужно отобразить на ней проверки и ответы статусами "упешно/нет", но ни Sparx ни StarUml не предлагают готовых элементов "ветвление" для этой диаграммы (панель на скрине).
Какой тут бест-практис то ? :))))
Андрей, на диаграмме последовательности да ветвления может использоваться элемент типа fragment, но от этого диаграмма, на мой взгляд, не становится более применимой для отображения потоков действий. Если бы я не знал Григория, то взглянув на диаграмму без дополнительных пояснений в первую очередь заподозрил бы незнание UML. А так это похоже на попытку изобрести свою нотацию с использованием элементов UML sequence diagram.
-
Андрей, на диаграмме последовательности да ветвления может использоваться элемент типа fragment, но от этого диаграмма, на мой взгляд, не становится более применимой для отображения потоков действий. Если бы я не знал Григория, то взглянув на диаграмму без дополнительных пояснений в первую очередь заподозрил бы незнание UML. А так это похоже на попытку изобрести свою нотацию с использованием элементов UML sequence diagram.
Это действительно попытка описать (не изобрести) простую нотацию. :) Причём довольно серьёзная, я эту нотацию скоро опубликую. Я считаю, что большинство концепций UML невозможно понять, не имея опыта программирования. Аналитику для общения с непрограммистами нужно что-то значительно более простое и интуитивно понятное. Вся мощь UML в большинстве случаев не нужна на уровнях более абстрактных, чем программный код и внутренняя архитектура программ.
Я только не согласен с тем, чтобы считать отдельные элементы неотъемлемой принадлежностью UML. UML возник не на пустом месте, а вобрал в себя множество давно существующих подходов и нотаций. А то, что сейчас любую диаграмму в первую очередь оценивают с точки зрения UML, я считаю проблемой. Да, в UML "всё есть". Но часто нам нужен только маленький кусочек того, что там есть, а приходится изучать всё - например, чтобы использовать инструменты, ориентированные на UML, как в нашем случае с EA (хочешь добавить элемент из другой диаграммы, а инструмент по умолчанию этого не позволяет).
-
Кстати, в lucidchart можно на дорожки класть любые элементы - там это очень удобно сделано.
-
А так это похоже на попытку изобрести свою нотацию с использованием элементов UML sequence diagram.
Это действительно попытка описать (не изобрести) простую нотацию.
Изобретение собственных нотаций - это вообще вполне нормальная практика на мой взгляд. Просто потому что универсальной нотации нет, а сколько людей- столько и остального.
Особенно это касается случаев устойчивых отношений бизнес-заказчиков и ИТ (характерно для "внутренних" ИТ-отделов и "старых добрых незаменимых" вендоров).
У меня у самого есть достаточно функциональный Набор элементов Visio (составлен из ряда стандартных и собственных иконок путём скрещивания правил BPMN и Функциональной блок-схемы с применением положительных свойств EPC).
Набор включает в себя:
Собственно элементы блок-схемы Visio
Элементы BPMN (гейты, старты, стопы с расширяющими иконками)
Иконки пользователей (одиночных и группы)
Иконки группы "компьютеры"
Иконки группы "транспорт"
Иконки документов (офис и прочее)
Хороший набор, позволяющий очень быстро набросать схему процесса для формального утверждения с пользователями, не искушенными в IDEF UML EPC BPM (далее по списку) и передачи в разработку с комментариями простым текстом.
Для небольших локальных задач - идеальная штука, а готовой нотации, включающей в себя все достоинства других, нет и не будет. Потому что сколько людей - столько и достоинств.
Но в данном конкретном случае я готов бодаться довольно долго.
Задача находится на уровне BPMN, ну или Activity-диаграммы UML. Там просто всё для этого есть.
Поэтому попытки изобрести некую новую сущность безусловно любопытны, но не более.
Повторюсь. В рамках данного конкретного вопроса.
-
Но в данном конкретном случае я готов бодаться довольно долго.
Задача находится на уровне BPMN, ну или Activity-диаграммы UML. Там просто всё для этого есть.
Дуэль на картинках? :)
Просим топикстартера дать более подробное описание задачи и предлагаем варианты?
-
А что, действительно получилось малопонятно? :( А чего, на твой взгляд, не хватает, чтобы было понятнее?
Речь о "диаграмме последовательности" я завёл только потому, что другого общепринятого названия для диаграммы с дорожками я пока не знаю. Хотя это название imho крайне неудачно (в UML вообще проблема с интуитивно понятными названиями диаграмм).
Извини, но у меня совершенно элементы для диаграммы последовательности не ассоциируются с дорожками. Вот в диаграмме деятельности ассоциируются.
Названия не фонтан, а может дать пример совершенного попадания? Как называется диаграмма в IDEF0, а в IDEF3?
Есть например FLOW-диаграммы, они проще? Понятнее?
-
Изобретение собственных нотаций - это вообще вполне нормальная практика на мой взгляд. Просто потому что универсальной нотации нет, а сколько людей- столько и остального.
Согласен. Вполне нормальная практика. Но нужно понимать, что у нотации собственного сочинения могут быть как плюсы, так и минусы. Григорий предлагает использовать все те же элементы, что и на activity-диаграмме, за исключением дорожек от sequence-диаграммы. На мой взгляд, ничего принципиально нового и замечательного, в данном конкретном случае мы не получаем. С другой стороны мы заранее ограничиваем круг потенциальных потребителей таких диаграм, если всё же будем использовать элементы ветвлений диаграммы последовательности. Это уже более экзотично и менее понятно.
-
Дуэль на картинках? :)
Просим топикстартера дать более подробное описание задачи и предлагаем варианты?
Ну можно и так назвать.
Главное дождаться собственно задачи. Пропал наш топикпастер :)