UML как альтернатива техническим заданиям при автоматизации процессов
Некоторые разработчики пренебрегают этапом проектирования в целом, ссылаясь на то, что это потеря времени. Если задача небольшая, то это вполне оправдано, однако при решении сложных задач планирование и моделирование значительно упрощают программирование: вносить изменения в диаграммы классов легче, чем в исходный код. Проектирование с помощью UML-диаграмм помогает найти оптимальное решение до начала программирования, имея его перед глазами вы можете анализировать и видоизменять всю систему.
Что такое UML
UML – (Unified Modeling Language) – это система обозначений, которая применяется для объектно-ориентированного анализа и проектирования и используется для визуализации, конструирования и документирования программных систем.
Если речь идет о сложных логистических процессах, объектах и связях между ними, то UML позволяет описать задачу оптимальным образом. В то время как техническое задание – это преимущественно текстовое описание задачи, которое хорошо работает для простых задач.
UML-диаграммы – наш опыт
Мы обратились к работе с UML, когда перед нами встала задача описать проект по автоматизации логистического подразделения крупной компании.
Вариант с техническим заданием быстро потерпел фиаско, потому что текстовое описание сложных логистических процессов, структуры данных компании, многочисленных связей между ними – возводило трудность восприятия до предела, и в какой-то момент любой человек перестаёт понимать всю систему.
Технологии Agile, при которых итеративно можно бы было реализовать какой-то маленький, но работающий кусочек, тоже подходили плохо, потому что при недостаточном описании связей блока с другими часто получалось, что блок нужно переписывать с нуля. Количество зависимостей в системе было настолько велико, что выдернуть из неё отдельный блок – невозможно, равно как и двигаться сверху вниз, от общего к частному (потому что общего как такового нет).
Итак, нам потребовалось найти способ, как можно описать проект с тонной документации и тысячами связей так, чтобы:
- В нём было просто ориентироваться;
- Можно было бы легко изменять “масштаб” описания блоков: сворачивать лишние и разворачивать нужные.
В качестве решения мы стали использовать UML-диаграммы с поддержкой ссылок объектов друг на друга, а также полнотекстовых описаний. Это нам позволило:
- Использовать как графическое, так и текстовое описание одновременно (и каждое из них именно там, где нужно);
- Объединять и структурно организовывать десятки диаграмм;
- Видеть крупные блоки “сверху”, с основными связями, а также иметь возможность опуститься до базового уровня с полным описанием, структурой таблиц, детализацией связей и чуть ли не примерами кода.
Вот так, например, выглядит часть дерева диаграмм проекта:
И каждый пункт на ней – диаграмма с многочисленными блоками.
А вот так реализован процесс поездки водителя от склада по маршруту:
Удобство состоит в том, что, нажав на знак “+” рядом с каким-либо объектом, мы сразу можем увидеть, на каких ещё диаграммах он встречается:
И поэтому можем разделять одни и те же элементы между разными диаграммами, не рисуя сложно воспринимаемую паутину из сотен и тысяч связей. Бывает, что элемент встречается на большом количестве диаграмм:
Это позволяет, например, быстро понять, в каких блоках проекта используется генерация CSV-файлов:
Программист, который будет выполнять эту задачу, сможет учесть связи при реализации.
Это невероятно удобный способ описания блоков во время встреч с заказчиком. За пару-тройку часов обсуждения можно набросать небольшой текстовый документ с заметками, а потом перенести их на диаграммы, отмечая все возникшие зависимости. В будущем это позволит на этапе программирования не упустить что-то радикально важное.
Подробные текстовые описания по каждому элементу удобно прячутся под соответствующими пиктограммами:
И на этом ещё не всё, за некоторыми элементами могут скрываться целые дочерние диаграммы, подробно описывающие тот или иной процесс или сложную структуру:
Клик по связанной диаграмме откроет её саму:
И на ней опять будут различные ссылки, связи, документация и прочее.
Ещё одно достоинство выбранного представления – возможность как-то выделять цветом на диаграммах любые проблемные места, где возникли вопросы. Впоследствии их можно будет задать заказчику прямо на встрече, оставив комментарии внутри этих же объектов (в их документации). Таким образом вся собранная информация будет в одном месте.
Плюсы и минусы такого подхода (по нашему опыту):
+ Наглядность. Упрощение восприятия и ориентировки в проекте;
+ Экономия времени на этапе передачи знаний (в том числе на следующие этапы);
+ Полнота. Отображение и выявление большинства связей, которые могли бы остаться незамеченными при текстовом описании;
+ Удобство обсуждений и сбора информации с представителями заказчика;
По нашему опыту данный механизм больше подходит для водопада, нежели agile-технологий. Запускать в разработку можно только то, что уже описано на диаграммах. Требуется знание языка UML и нотации BPMN (как минимум у того/тех, кто создаёт и читает диаграммы), а также интерфейса и всех функций используемого ПО. Стоит учитывать продолжительность этапа сбора сведений и проектирования.