Кстати, по поводу поиска исходника. Если png-диаграмма сделана в plantuml, то картинку можно конвертировать в исходный код. Встроенная функция в плагин plantuml для VS Code. Главное, чтобы там кириллицы только не было, а иначе придется руками надписи переписывать. Это еще один фактор, почему я полностью перешел на plantuml и других мотивирую.
Plantuml + Visual studio code (с плагином plantuml) + git для исходников. Для визуализации схемы выгружались в формат svg. Просмотр и ссылки между схемами посредством sharepoint-а. Версионный контроль и сравнение через git.
Если используется confluence и bitbucket, то можно генерировать диаграммы на странице confluence прямо из кода диаграммы в ветке master, например. Но плагин для этого платный и довольно дорогой.
Если настроить PlantUML сервер, то можно заиспользовать препроцессинг. Он позволит выносить общие части диаграмм в отдельные библиотеки. Например, можно включить все ИС компании в такую библиотеку, добавить ее в диаграмму через !include, описать взаимодействия и активировать отображение только включенных во взаимодействие ИС. +100500 к унификации.
Еще есть алгоритмы и инструменты автоматической генерации диаграмм, но до этого я даже не дошёл.
В общем как инструмент plantuml очень мощный, изучать его можно долго.
У нас UML был сразу спецификацией для разработчиков, практически без сопроводительного текста. Поэтому их было много, они были всегда актуальные, продуманные и правильные. И да, сложные. Их нужно было внимательно читать.
Тестирование было тоже на основе диаграмм, так что разработчикам приходилось им следовать.
Использовали UML для детального проектирования одной ИС для транспортной компании. Покрытие моделями было под 95% для процессов, детальные макеты и прототип, который было не отличить от работающего ПО. В итоге через год после старта проект из самого рискованного превратился в самый стабильный и прибыльный для компании. А проблемы, на которые у других команд уходили дни, мы решали за считанные часы. При всём при этом сроки были сжатые, как обычно, договор фикс.
Считаю, что моделирование и проектирование крайне недооценено для успеха проекта. Ну и мало кто видел действительно качественное проектирование, вот и сформировалось мнение, что оно не нужно.
Обычная проблема. Недоиспользование потенциала ИТ в обучении. И, видимо, даже на профильных кафедрах. Хотя удаленный формат обучения где-то может быть даже эффективнее, но только при желании учиться, конечно.
Да, Яндекс.Почта по умолчанию отправляет ответ с адреса, на который пришло письмо. Мобильное приложение так не умеет, но позволяет вручную выбрать алиас для отправки.
Кстати, по поводу поиска исходника. Если png-диаграмма сделана в plantuml, то картинку можно конвертировать в исходный код. Встроенная функция в плагин plantuml для VS Code. Главное, чтобы там кириллицы только не было, а иначе придется руками надписи переписывать. Это еще один фактор, почему я полностью перешел на plantuml и других мотивирую.
Plantuml + Visual studio code (с плагином plantuml) + git для исходников. Для визуализации схемы выгружались в формат svg. Просмотр и ссылки между схемами посредством sharepoint-а. Версионный контроль и сравнение через git.
Если используется confluence и bitbucket, то можно генерировать диаграммы на странице confluence прямо из кода диаграммы в ветке master, например. Но плагин для этого платный и довольно дорогой.
Если настроить PlantUML сервер, то можно заиспользовать препроцессинг. Он позволит выносить общие части диаграмм в отдельные библиотеки. Например, можно включить все ИС компании в такую библиотеку, добавить ее в диаграмму через !include, описать взаимодействия и активировать отображение только включенных во взаимодействие ИС. +100500 к унификации.
Еще есть алгоритмы и инструменты автоматической генерации диаграмм, но до этого я даже не дошёл.
В общем как инструмент plantuml очень мощный, изучать его можно долго.
У нас UML был сразу спецификацией для разработчиков, практически без сопроводительного текста. Поэтому их было много, они были всегда актуальные, продуманные и правильные. И да, сложные. Их нужно было внимательно читать.
Тестирование было тоже на основе диаграмм, так что разработчикам приходилось им следовать.
Пробовали VS code + plantuml? Прирост в скорости разработки и изменения сиквенсов x10 по сравнению с Visio тем же.
Код прошлых диаграмм очень удобно использовать для новых.
Использовали UML для детального проектирования одной ИС для транспортной компании. Покрытие моделями было под 95% для процессов, детальные макеты и прототип, который было не отличить от работающего ПО. В итоге через год после старта проект из самого рискованного превратился в самый стабильный и прибыльный для компании. А проблемы, на которые у других команд уходили дни, мы решали за считанные часы. При всём при этом сроки были сжатые, как обычно, договор фикс.
Считаю, что моделирование и проектирование крайне недооценено для успеха проекта. Ну и мало кто видел действительно качественное проектирование, вот и сформировалось мнение, что оно не нужно.
Обычная проблема. Недоиспользование потенциала ИТ в обучении. И, видимо, даже на профильных кафедрах. Хотя удаленный формат обучения где-то может быть даже эффективнее, но только при желании учиться, конечно.
Привет, Арсен! Ну как, в связи с пандемией кампус стали использовать на полную?