Спасибо за комментарий!
Мы пока зафиксировали наши наблюдения за процессом — провели «предпроектное обследование»:)
Но Вы правы безусловно! Цель, входы, выходы и оценка эффективности процессов — важнейшие составляющие! Добавлю про них во вторую часть.
А что значит «простой» проект?
Здесь скорее «типовой» — «не типовой». Повторюсь немного: если мы разрабатываем 1001-ую систему для данной предметной области, или переносим систему на 1001-ую платформу, или разрабатываем систему, для которой есть почти 100% аналог, то вряд ли будем отрисовывать весь процесс, скорее только на какие-то нюансы внимание обратим.
А если у нас для автоматизации всего один небольшой процесс, но о котором на входе в проект мало информации, и нет четких требований и понимания, что в итоге должно получится, то почему бы и не разработать модель? В идеале разработка модели и составление текстового описания (продуманного) по трудоемкости не должны сильно отличаться.
Нет, без ТЗ никак, модель не может заменить ТЗ. На мой взгляд, модель позволяет систематизировать собранную информацию о том, что собираемся автоматизировать, и помогает написать адекватное ТЗ. Диаграммы, как правило, в ТЗ тоже приводим, а еще с помощью макросов, например, можно сгенерировать кое-какое дополнительное описание по модели. Можно, конечно, и просто текстовое описание процесса дать, но, по мне, так с помощью диаграмм нагляднее получается. Но это все безусловно дело вкуса и привычки. Если моделирование занимает много времени, ну, значит, или инструмент не тот выбрали, или методика хромает. У меня в статьях: и про «сказки», и про реальную жизнь, — предусматривается переход от шагов процесса к требованиям и функциям системы, при этом трассировка сама собой получается — всегда понятно, та или иная функция с чего вдруг «придумана». Но не могу сказать, что сначала модель, а только потом ТЗ. Модель начинаем разрабатывать до написания ТЗ, а потом продолжаем развивать, добавляя архитектурные аспекты. Резюмирую: модель и классическое ТЗ друг другу не противопоставляем, а стараемся взаимополезно сочетать.
И только в одном примечании в документации UML есть довольно явное указание на использование дорожек (п.15.2.5, стр.383):
Еще одна цитата:
NOTE. The swimlanes are an important feature for indicating senders and responders.
И ее перевод
ПРИМЕЧАНИЕ. Плавательные дорожки являются важной особенностью (возможностью/ характеристикой) [языка] для обозначения отправителей и получателей [сообщений/ информации/ потока управления].
Цитата:
Swimlanes are vertical or horizontal bands in a diagram that divide the diagram into logical areas or partitions. You can apply them to all Enterprise Architect diagram types. Activities relating to particular entities within the model (such as the User, or the back end Repository) can be placed within the same Swimlane to indicate their association.
Перевод цитаты
«Плавательные дорожки» — это вертикальные или горизонтальные полосы на диаграмме, которые разделяют диаграмму на логические области или разделы. Их можно применить ко всем типам диаграмм Enterprise Architect. Действия, относящиеся к определенной сущности в модели (например, пользователь или серверное хранилище), могут быть помещены на одну и ту же дорожку, чтобы показать их связь с данной сущностью.
Смотрите, что получается: в документации ЕА приведен пример «специализации» дорожек – «Действия, закрепленные за сущностями». Но это только один из способов структурирования диаграммы! Мы не нарушим нотацию, если закрепим за дорожками другие «специализации», например, такие: «Входные и выходные артефакты», «Шаги процесса», «Участники процесса» и т.д.
Нет на этот счет запретов ни в языке, ни в инструменте! Попробуйте! А вдруг Вам тоже такой способ структурирования подойдет?
Диаграммы Activity в моих примерах используются для сбора информации о процессе, который мы будем автоматизировать и о котором мы, когда приступаем к работе, не очень много знаем (т.е. если Вы разрабатываете 1001-ую систему для данной предметной области, оно Вам, может, и не нужно, хотя и в этом случае — не факт). По отношению к процессу мы выступаем в роли сторонних наблюдателей, собираем информацию: кто и что делает, в какой последовательности, что использует для работы, какие документы использует, а какие «порождает», есть ли доп.правила, при этом стараемся сразу структурировать добытую информацию — раскладываем по полочкам — Swimlanes нам в помощь. Такое формализованное описание процесса поможет нам выявить требования к будущей системе.
Не пытаюсь никого «обратить в свою веру», но призываю не следовать слепо «догме», тем более, что судя по документации ее и нет вовсе:)
И еще маленький комментарий вот на это замечание:
Ведь на сколько я понимаю принцип дорожек именно в разделении границ между взаимодействующими сторонами, ну т.е. в одной дорожке то что делает пользователь, в другой то, что делает система и т.п.?
Ваше замечание как раз перекликается со 2-ой цитатой из документации UML (см.выше).
И такой подход к структурированию диаграммы Activity: «Действия пользователя», «Действия системы», — мы тоже периодически применяем в своих проектах, но уже на следующих этапах проектирования, когда описываем автоматизированные функции (как правило, это происходит на этапе эскизного или технического проекта).
P.S. Очень хотелось схулиганить и написать в заметке: «Вы просто поверьте, а поймете потом».:) Но взяла себя в руки и написала более серьезный обоснованный ответ.
P.P.S. Кажется, набирается материал на самостоятельную статью.:) Спасибо Вам!
Что касается моды на UML и «происков» производителей ПО — это все, конечно, верно.
UML был очень моден.
…
Разводка от производителей ПО для UML, все это по большей части.
Но… Страсти по UML давно улеглись, появилось много инструментов бесплатных или весьма бюджетных (не сравнить с Rational Rose не только по цене, но и по юзабилити), а еще и с открытым кодом имеются. Универсальность UML немного пугает в начале, но если перефразировать принцип Парето «20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата» в «20% диаграмм используется в 80% случаев», то жизнь становится легче:) И что плохого в том, что есть достаточно четкие правила использования моделирующих элементов каждой диаграммы, у диаграмм есть специализация? А если что-то хочется изменить или дополнить — пишите соглашение по моделированию, — вот и все!
Ну, а на счет «бизнес рванул» — все возможно…
Мол жила семейная пара со своим мелким бизнесом, и что то у них он плохо шел.
вот купили они ПО для UML (Rational Rose) нарисовали диаграммы и пр. (пример довольно примитивной диаграммы с «человечками» и стрелочками) и как у них бизнес рванул…
Возможно, систематизировали люди информацию, проанализировали, нашли узкие места, что-то поменяли, вот бизнес и рванул, а UML действительно помог. Хотя пример в книжке — это еще и разводка маркетинговый ход от производителей ПО для UML, как Вы верно заметили:)
Есть маленький лайф-хак:)
Когда понимаю, что нужен новый объект (артефакт или участник), добавляю сначала новый класс или актора в соответствующий пакет, потом на Activity перетаскиваю из дерева уже как объект.
Если очень хочется показать "внутренних работников" — "человечек в кружочке", то надо участника добавить как класс, перетащить на диаграмму как объект и уже объекту назначить стереотип internal woker, но это уж слишком много дополнительных телодвижений, по-моему.
Да, и к тому же у меня накапливается таким образом материал для объектной модели параллельно с отрисовкой бизнес-процесса.
Спасибо!
Да, планирую добавить про StateChart и Sequence диаграммы.
При проектировании больше ориентированы на применение отечественных ГОСТов, в основном это 34 серия, т.к. речь об автоматизированных системах. Использование ГОСТ продиктовано требованиями Заказчика, но если не придираться к несколько «устаревшей» терминологии и громадному количеству документов (нужно просто выбрать необходимое и достаточное), то практически все рекомендации наших стандартов очень разумны — умные люди составляли (это я про 34-ую серию).
Пользовательские требования собираются в ходе моделирования бизнес-процесса.
Про трассировку от функций системы к бизнес процессу чуть-чуть описано во 2-ой части, в планах есть описать подробнее.
Да, мне тоже проще сначала первый вариант построить, а потом можно уже и развернуть, не показываю уже входы и выходы, например, тогда компактнее получится.
Спасибо!
Про ЕА соглашусь на 100%! ЕА использую давно, чуть ли не 6-ой версии, и люблю больше чем Modelio, все там удобнее, продуманнее:)
Но Modelio бесплатен и для учебных задач годится более чем. И, кстати, есть несколько приятных «фишечек», которых нет в ЕА, например, клонирование диаграммы вместе со структурой плавательных дорожек.
Теперь, почему не BPMN. Ничего против BPMN не имею. И да — некоторые моменты выглядят логичнее, можно взаимодействие процессов, например, показать явно. Но в моем примере UML Activity используется еще и как своеобразная карта сбора данных. Ну и хотелось ограничиться одним языком моделирования. К тому же переход к BPMN, если моделирование процесса с помощью Activity было освоено, не составит труда.
Еще раз благодарю за интерес к моим статьям!
Спасибо! На самом деле, «сказочная» предметная область только для «затравки». На семинарах и лабораторных моделируем «электронную очередь в банке» и что-то из учебного процесса, например: «замена в расписании», «учет посещений и успеваемости». Плюс у ребят курсовая со своей индивидуальной темой. Темы студенты предлагают самостоятельно, я только направляю немного, вот несколько примеров: «Автоматизация процессов контрольно-пропускного пункта города (закрытого)», «Автоматизация логистических процессов аптеки» (ну, здесь было очень много всего, пришлось ограничивать количество декомпозиций), «Автоматизация работы хронометристов баскетбольного матча», «Автоматизация работы военного комиссариата» (тоже ограничили количество рассматриваемых функций), «Автоматизация работы приемной комиссии вуза» (и тоже только фрагмент).
Конечно, студенческие проекты требуют «причесывания», это же у меня 2 семестр! Постараюсь к лету получить модели, которые можно было бы в пример привести.
И что-нибудь из РЕАЛЬНОЙ жизни (параллельной работе в вузе) подберу.
Да, можно применить стандартную отрисовку плавательных дорожек, но тогда не будет той структуры, которая используется для сбора данных о процессе: входные/выходные объекты, правила, инструменты и т.д. Да, можно еще «лишние» потоки управления убрать за счет потоков объектов — стрелок будет меньше, но объекты окажутся «размазаны» по всей диаграмме, структура потеряется. Из личного опыта добавлю, что нередко самый разумный подход — это иметь 2 варианта активити диаграммы.
Перерисую диаграмму в «стандартный» вид и постараюсь показать в сравнении плюсы и минусы каждого подхода.
Спасибо! Отличная идея на счёт углубления знаний по BPMN!
Мы пока зафиксировали наши наблюдения за процессом — провели «предпроектное обследование»:)
Но Вы правы безусловно! Цель, входы, выходы и оценка эффективности процессов — важнейшие составляющие! Добавлю про них во вторую часть.
Здесь скорее «типовой» — «не типовой». Повторюсь немного: если мы разрабатываем 1001-ую систему для данной предметной области, или переносим систему на 1001-ую платформу, или разрабатываем систему, для которой есть почти 100% аналог, то вряд ли будем отрисовывать весь процесс, скорее только на какие-то нюансы внимание обратим.
А если у нас для автоматизации всего один небольшой процесс, но о котором на входе в проект мало информации, и нет четких требований и понимания, что в итоге должно получится, то почему бы и не разработать модель? В идеале разработка модели и составление текстового описания (продуманного) по трудоемкости не должны сильно отличаться.
Для начала цитаты из документации UML и EA.
UML
И только в одном примечании в документации UML есть довольно явное указание на использование дорожек (п.15.2.5, стр.383):
ЕА
Смотрите, что получается: в документации ЕА приведен пример «специализации» дорожек – «Действия, закрепленные за сущностями». Но это только один из способов структурирования диаграммы! Мы не нарушим нотацию, если закрепим за дорожками другие «специализации», например, такие: «Входные и выходные артефакты», «Шаги процесса», «Участники процесса» и т.д.
Нет на этот счет запретов ни в языке, ни в инструменте! Попробуйте! А вдруг Вам тоже такой способ структурирования подойдет?
Диаграммы Activity в моих примерах используются для сбора информации о процессе, который мы будем автоматизировать и о котором мы, когда приступаем к работе, не очень много знаем (т.е. если Вы разрабатываете 1001-ую систему для данной предметной области, оно Вам, может, и не нужно, хотя и в этом случае — не факт). По отношению к процессу мы выступаем в роли сторонних наблюдателей, собираем информацию: кто и что делает, в какой последовательности, что использует для работы, какие документы использует, а какие «порождает», есть ли доп.правила, при этом стараемся сразу структурировать добытую информацию — раскладываем по полочкам — Swimlanes нам в помощь. Такое формализованное описание процесса поможет нам выявить требования к будущей системе.
Не пытаюсь никого «обратить в свою веру», но призываю не следовать слепо «догме», тем более, что судя по документации ее и нет вовсе:)
И еще маленький комментарий вот на это замечание:
Ваше замечание как раз перекликается со 2-ой цитатой из документации UML (см.выше).
И такой подход к структурированию диаграммы Activity: «Действия пользователя», «Действия системы», — мы тоже периодически применяем в своих проектах, но уже на следующих этапах проектирования, когда описываем автоматизированные функции (как правило, это происходит на этапе эскизного или технического проекта).
P.S. Очень хотелось схулиганить и написать в заметке: «Вы просто поверьте, а поймете потом».:) Но взяла себя в руки и написала более
серьезныйобоснованный ответ.P.P.S. Кажется, набирается материал на самостоятельную статью.:) Спасибо Вам!
Но… Страсти по UML давно улеглись, появилось много инструментов бесплатных или весьма бюджетных (не сравнить с Rational Rose не только по цене, но и по юзабилити), а еще и с открытым кодом имеются. Универсальность UML немного пугает в начале, но если перефразировать принцип Парето «20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата» в «20% диаграмм используется в 80% случаев», то жизнь становится легче:) И что плохого в том, что есть достаточно четкие правила использования моделирующих элементов каждой диаграммы, у диаграмм есть специализация? А если что-то хочется изменить или дополнить — пишите соглашение по моделированию, — вот и все!
Ну, а на счет «бизнес рванул» — все возможно…
Возможно, систематизировали люди информацию, проанализировали, нашли узкие места, что-то поменяли, вот бизнес и рванул, а UML действительно помог. Хотя пример в книжке — это еще и
разводкамаркетинговый ход от производителей ПО для UML, как Вы верно заметили:)Есть маленький лайф-хак:)
Когда понимаю, что нужен новый объект (артефакт или участник), добавляю сначала новый класс или актора в соответствующий пакет, потом на Activity перетаскиваю из дерева уже как объект.
Если очень хочется показать "внутренних работников" — "человечек в кружочке", то надо участника добавить как класс, перетащить на диаграмму как объект и уже объекту назначить стереотип internal woker, но это уж слишком много дополнительных телодвижений, по-моему.
Да, и к тому же у меня накапливается таким образом материал для объектной модели параллельно с отрисовкой бизнес-процесса.
Да, планирую добавить про StateChart и Sequence диаграммы.
При проектировании больше ориентированы на применение отечественных ГОСТов, в основном это 34 серия, т.к. речь об автоматизированных системах. Использование ГОСТ продиктовано требованиями Заказчика, но если не придираться к несколько «устаревшей» терминологии и громадному количеству документов (нужно просто выбрать необходимое и достаточное), то практически все рекомендации наших стандартов очень разумны — умные люди составляли (это я про 34-ую серию).
Пользовательские требования собираются в ходе моделирования бизнес-процесса.
Про трассировку от функций системы к бизнес процессу чуть-чуть описано во 2-ой части, в планах есть описать подробнее.
Про ЕА соглашусь на 100%! ЕА использую давно, чуть ли не 6-ой версии, и люблю больше чем Modelio, все там удобнее, продуманнее:)
Но Modelio бесплатен и для учебных задач годится более чем. И, кстати, есть несколько приятных «фишечек», которых нет в ЕА, например, клонирование диаграммы вместе со структурой плавательных дорожек.
Теперь, почему не BPMN. Ничего против BPMN не имею. И да — некоторые моменты выглядят логичнее, можно взаимодействие процессов, например, показать явно. Но в моем примере UML Activity используется еще и как своеобразная карта сбора данных. Ну и хотелось ограничиться одним языком моделирования. К тому же переход к BPMN, если моделирование процесса с помощью Activity было освоено, не составит труда.
Еще раз благодарю за интерес к моим статьям!
Конечно, студенческие проекты требуют «причесывания», это же у меня 2 семестр! Постараюсь к лету получить модели, которые можно было бы в пример привести.
И что-нибудь из РЕАЛЬНОЙ жизни (параллельной работе в вузе) подберу.
Перерисую диаграмму в «стандартный» вид и постараюсь показать в сравнении плюсы и минусы каждого подхода.