Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 10
Спасибо за статью.
Прочел ваши предыдущие статьи и все равно не понимаю, почему у вас действия Актантов (или Акторов) в диаграмме активности не в виде дорожек, а так как вы представили? Ведь на сколько я понимаю принцип дорожек именно в разделении границ между взаимодействующими сторонами, ну т.е. в одной дорожке то что делает пользователь, в другой то, что делает система и т.п.?
Можно будет еще раз немного поподробнее рассказать по данный выбор и не нарушает ли он нотацию?
Прочел ваши предыдущие статьи и все равно не понимаю, почему у вас действия Актантов (или Акторов) в диаграмме активности не в виде дорожек, а так как вы представили? Ведь на сколько я понимаю принцип дорожек именно в разделении границ между взаимодействующими сторонами, ну т.е. в одной дорожке то что делает пользователь, в другой то, что делает система и т.п.?
Можно будет еще раз немного поподробнее рассказать по данный выбор и не нарушает ли он нотацию?
ну т.е. в одной дорожке то что делает пользователь, в другой то, что делает система и т.п.?
Есть разные варианты нотаций. А есть нюансы EA в отображении диаграмм :)
И есть более удобные способы отображения процессов
Заметки по поводу использования Swimlanes — «Плавательных дорожек»
Для начала цитаты из документации UML и EA.
UML
И только в одном примечании в документации UML есть довольно явное указание на использование дорожек (п.15.2.5, стр.383):
ЕА
Смотрите, что получается: в документации ЕА приведен пример «специализации» дорожек – «Действия, закрепленные за сущностями». Но это только один из способов структурирования диаграммы! Мы не нарушим нотацию, если закрепим за дорожками другие «специализации», например, такие: «Входные и выходные артефакты», «Шаги процесса», «Участники процесса» и т.д.
Нет на этот счет запретов ни в языке, ни в инструменте! Попробуйте! А вдруг Вам тоже такой способ структурирования подойдет?
Диаграммы Activity в моих примерах используются для сбора информации о процессе, который мы будем автоматизировать и о котором мы, когда приступаем к работе, не очень много знаем (т.е. если Вы разрабатываете 1001-ую систему для данной предметной области, оно Вам, может, и не нужно, хотя и в этом случае — не факт). По отношению к процессу мы выступаем в роли сторонних наблюдателей, собираем информацию: кто и что делает, в какой последовательности, что использует для работы, какие документы использует, а какие «порождает», есть ли доп.правила, при этом стараемся сразу структурировать добытую информацию — раскладываем по полочкам — Swimlanes нам в помощь. Такое формализованное описание процесса поможет нам выявить требования к будущей системе.
Не пытаюсь никого «обратить в свою веру», но призываю не следовать слепо «догме», тем более, что судя по документации ее и нет вовсе:)
И еще маленький комментарий вот на это замечание:
Ваше замечание как раз перекликается со 2-ой цитатой из документации UML (см.выше).
И такой подход к структурированию диаграммы Activity: «Действия пользователя», «Действия системы», — мы тоже периодически применяем в своих проектах, но уже на следующих этапах проектирования, когда описываем автоматизированные функции (как правило, это происходит на этапе эскизного или технического проекта).
P.S. Очень хотелось схулиганить и написать в заметке: «Вы просто поверьте, а поймете потом».:) Но взяла себя в руки и написала болеесерьезный обоснованный ответ.
P.P.S. Кажется, набирается материал на самостоятельную статью.:) Спасибо Вам!
Для начала цитаты из документации UML и EA.
UML
Цитата:
15.6.4.1 Activity Partitions
An ActivityPartition is notated with two, usually parallel lines, either horizontal or vertical, and a name labeling the partition in a box at one end. Any ActivityNodes and ActivityEdges placed between these lines are considered to be contained within the partition. This notation for an ActivityPartition is colloquially known as a swimlane, as shown in Figure 15.66(a). Swimlanes can express hierarchical partitioning by representing the subpartitions as further partitioning of the superpartition, as illustrated in Figure 15.66(b). Diagrams can also be partitioned multidimensionally, as depicted in Figure 15.66©, where each «swim cell» is an intersection of multiple partitions.
Перевод цитаты:
15.6.4.1 Разделы диаграммы Activity
ActivityPartition обозначается двумя, обычно параллельными линиями, горизонтальными или вертикальными, и именем, обозначающим раздел в поле на одном конце. Любые моделирующие элементы ActivityNodes и ActivityEdges, размещенные между этими линиями, считаются содержащимися в этом разделе. Это обозначение для ActivityPartition, в просторечии известное как swimlane, как показано на рисунке 15.66(a). Плавательные дорожки могут выражать иерархическое разделение, представляя подразделы как дальнейшее разделение, как показано на рис.15.66(b). Диаграммы также могут быть разделены многомерно, как показано на рисунке 15.66 ©, где каждая «swim cell», «плавательная ячейка», является пересечением нескольких разделов.
И только в одном примечании в документации 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 вообще необходимо?
Что проще в данном случае? Написать классическое ТЗ и броситься в бой? Или модели дают реальный выхлоп? Является ли модель заменой ТЗ или по модели затем сочиняется ТЗ?
Нет, без ТЗ никак, модель не может заменить ТЗ. На мой взгляд, модель позволяет систематизировать собранную информацию о том, что собираемся автоматизировать, и помогает написать адекватное ТЗ. Диаграммы, как правило, в ТЗ тоже приводим, а еще с помощью макросов, например, можно сгенерировать кое-какое дополнительное описание по модели. Можно, конечно, и просто текстовое описание процесса дать, но, по мне, так с помощью диаграмм нагляднее получается. Но это все безусловно дело вкуса и привычки. Если моделирование занимает много времени, ну, значит, или инструмент не тот выбрали, или методика хромает. У меня в статьях: и про «сказки», и про реальную жизнь, — предусматривается переход от шагов процесса к требованиям и функциям системы, при этом трассировка сама собой получается — всегда понятно, та или иная функция с чего вдруг «придумана». Но не могу сказать, что сначала модель, а только потом ТЗ. Модель начинаем разрабатывать до написания ТЗ, а потом продолжаем развивать, добавляя архитектурные аспекты. Резюмирую: модель и классическое ТЗ друг другу не противопоставляем, а стараемся взаимополезно сочетать.
А есть ли минимальный размер проекта, с которого целесообразно заниматься моделированием? Просто моделирование для простых проектов выглядит моделью ради модели.
Или модели дают реальный выхлоп?
Что мешает собрать модель и после сгенерирвать код, сэкономив время
Является ли модель заменой ТЗ или по модели затем сочиняется ТЗ?
смотря на какой стадии: «что есть» или «как нужно».
А что значит «простой» проект?
Здесь скорее «типовой» — «не типовой». Повторюсь немного: если мы разрабатываем 1001-ую систему для данной предметной области, или переносим систему на 1001-ую платформу, или разрабатываем систему, для которой есть почти 100% аналог, то вряд ли будем отрисовывать весь процесс, скорее только на какие-то нюансы внимание обратим.
А если у нас для автоматизации всего один небольшой процесс, но о котором на входе в проект мало информации, и нет четких требований и понимания, что в итоге должно получится, то почему бы и не разработать модель? В идеале разработка модели и составление текстового описания (продуманного) по трудоемкости не должны сильно отличаться.
Здесь скорее «типовой» — «не типовой». Повторюсь немного: если мы разрабатываем 1001-ую систему для данной предметной области, или переносим систему на 1001-ую платформу, или разрабатываем систему, для которой есть почти 100% аналог, то вряд ли будем отрисовывать весь процесс, скорее только на какие-то нюансы внимание обратим.
А если у нас для автоматизации всего один небольшой процесс, но о котором на входе в проект мало информации, и нет четких требований и понимания, что в итоге должно получится, то почему бы и не разработать модель? В идеале разработка модели и составление текстового описания (продуманного) по трудоемкости не должны сильно отличаться.
А что значит «простой» проект?
Некая выбранная мера сложности. Например, количество сущностей (или классов, юз-кейсов, акторов и т.д.).
А если у нас для автоматизации всего один небольшой процесс, но о котором на входе в проект мало информации, и нет четких требований и понимания, что в итоге должно получится, то почему бы и не разработать модель?
Ну вот это и есть критерий, как я понимаю. Если нет четких требований и понимания, то моделирование — оправдано. Да, это лучше, чем формальные критерии по количеству элементов системы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
UML&Enterprise Architect: проектируем целевой процесс при создании автоматизированной системы