Comments 18
Насколько UML востребован сегодня? Использовал его только в одной фирме, потом он
оказался ненужен никому, совсем. Так-же как и IDEF.
оказался ненужен никому, совсем. Так-же как и IDEF.
Востребован, просто нужны нормальные инструменты. Например plantuml как составная часть системы генерации документации с сохранением в гит. Главное не забывать актуализировать.
Plantum смог применять только для диаграммы последовательности. И то — с трудом, потому что долго разбираешься и пробуешь, как же так написать «код», чтобы он отображал элементы диаграммы так, как надо.
Другие типы диаграм попробовал нарисовать что-то простое — оно сразу на этом этапе становилось непонятным как текст, а следовательно, теряло единственное преимущество перед картинкой.
Проще и быстрее использовать редактор WYSIWYG.
Другие типы диаграм попробовал нарисовать что-то простое — оно сразу на этом этапе становилось непонятным как текст, а следовательно, теряло единственное преимущество перед картинкой.
Проще и быстрее использовать редактор WYSIWYG.
WYSIWYG быстрее, пока в диаграмму с десятком элементов не надо будет вставить в середину что-то. Вриходится несколько минут (условно, в каждом случае индивидуально) мышевозить раздвигая другие элементы. В plantuml, если им пользоваться, это делается вставкой в нужное место.
Ну и версионность для визивигов не завезли. Вернее не саму версионность (никто не мешает блобы складывать в гит), а удобного сравнения версий.
Ну и версионность для визивигов не завезли. Вернее не саму версионность (никто не мешает блобы складывать в гит), а удобного сравнения версий.
Вот как раз со вставкой никаких проблем нет. Более того, даже более удобно: выделил часть, оттащил в сторону, дорисовал/вставил новое, задвинул часть обратно, при этом расположил элементы с учётом увеличившейся схемы. (Это может быть немного муторно, если схема ну очень большая, но это значит, что либо вы не умеете в композицию/вложенность/подпроцессы, либо это редкий уникальный случай.)
В случае plantuml — она либо тупо расширила схему, либо как-то, по её мнению, перерисовала, решив, что «она так видит» (знаю, плавал, скриншоты этого треша не сохранил), что выливается в… (читаем предыдущее моё сообщение) «долго разбираешься и пробуешь, как же так написать «код», чтобы он отображал элементы диаграммы так, как надо»
Вот про версионность — согласен. Но пока не пригождалось. :)
В случае plantuml — она либо тупо расширила схему, либо как-то, по её мнению, перерисовала, решив, что «она так видит» (знаю, плавал, скриншоты этого треша не сохранил), что выливается в… (читаем предыдущее моё сообщение) «долго разбираешься и пробуешь, как же так написать «код», чтобы он отображал элементы диаграммы так, как надо»
Вот про версионность — согласен. Но пока не пригождалось. :)
Так правильно.
Зачем нужен «промежуточный» ЯП?
Основная идея «веселых картинок», то что она понятна всем.
Но проблема в том, что UML настолько сложная вещь, что для понимания диаграмм UML нужно учить язык UML.
Этот ЯП должны знать все участники процесса.
Если программисты, еще как нибудь его выучат, то заказчикам это не нужно от слова совсем.
При этом agile и концепция MVP сразу убивают «рисование картинок».
Т.к. всем проще и понятнее работать с чем-то материальным, где сразу видны проблемы.
Чем с какими-то абстрактными картинками.
Зачем нужен «промежуточный» ЯП?
Основная идея «веселых картинок», то что она понятна всем.
Но проблема в том, что UML настолько сложная вещь, что для понимания диаграмм UML нужно учить язык UML.
Этот ЯП должны знать все участники процесса.
Если программисты, еще как нибудь его выучат, то заказчикам это не нужно от слова совсем.
При этом agile и концепция MVP сразу убивают «рисование картинок».
Т.к. всем проще и понятнее работать с чем-то материальным, где сразу видны проблемы.
Чем с какими-то абстрактными картинками.
Общий язык общения команды состоящей из разных компетенций в разных областях необходим на крупных проектах. Но UML на него не тянет.
Archi позволяет владельцу продукта определиться с требованиями к нему, архитектору — по требованиям набросать архитектуру (или детализировать ее полностью при необходимости), разработчикам — получить объем работ и видеть зависимости подсистем. Что вполне сочетается как с MVP и agile, так и с водопадом.
Даже в agile, без архитектурной проработки, легаси вас рано или поздно догонит, и потопит проект.
Archi позволяет владельцу продукта определиться с требованиями к нему, архитектору — по требованиям набросать архитектуру (или детализировать ее полностью при необходимости), разработчикам — получить объем работ и видеть зависимости подсистем. Что вполне сочетается как с MVP и agile, так и с водопадом.
Даже в agile, без архитектурной проработки, легаси вас рано или поздно догонит, и потопит проект.
Похоже на то. Клиенты смотрели на эти бесконечные диаграммы, но вникать в них даже не собирались, т.к. и свою работу нужно было делать, а не разбираться с веселыми картинками.
Он очень полезен, когда нужно описать средние и сложные процессы. Хотя я иногда и простые описываю.
Потому что диаграмма:
1. это не текст из кучи неопределённых слов и домысливаний. Разработчики обычно говорят спасибо.
2. позволяет найти все ветвления процесса и описать их поведение.
Потому что диаграмма:
1. это не текст из кучи неопределённых слов и домысливаний. Разработчики обычно говорят спасибо.
2. позволяет найти все ветвления процесса и описать их поведение.
Отношусь к UML как к «латыни программирования».
С одной стороны — это «мертвый язык», и успешного полноценного применения (когда UML — это основной инструмент проектирования, о чем мечтали авторы) ни разу не видел.
С другой стороны, изучение UML крайне полезно в плане переформатирования мозгов. Сама идея что приложение можно описать с разных точек зрения с помощью различных диаграмм UML (и то как эти диаграммы согласованы друг с другом) — для начинающих специалистов часто является революционной и двигает их вперед.
P.S. На практике применяю порядка 5 видов диаграмм UML — в основном в иллюстративных целях.
С одной стороны — это «мертвый язык», и успешного полноценного применения (когда UML — это основной инструмент проектирования, о чем мечтали авторы) ни разу не видел.
С другой стороны, изучение UML крайне полезно в плане переформатирования мозгов. Сама идея что приложение можно описать с разных точек зрения с помощью различных диаграмм UML (и то как эти диаграммы согласованы друг с другом) — для начинающих специалистов часто является революционной и двигает их вперед.
P.S. На практике применяю порядка 5 видов диаграмм UML — в основном в иллюстративных целях.
Основные цели дизайна UML:
- Предоставить пользователям готовый, выразительный язык визуального моделирования, чтобы они могли разрабатывать и обмениваться осмысленными моделями.
- Обеспечить механизмы расширяемости и специализации для расширения основных понятий.
- Быть независимым от конкретных языков программирования и процессов разработки.
- Обеспечить формальную основу для понимания языка моделирования.
- Поощрять рост рынка объектно-ориентированных инструментов.
- Поддержка высокоуровневых концепций разработки, таких как совместная работа, структуры, шаблоны и компоненты.
- Интегрировать лучшие практики.
1. «готовый», «выразительный», «осмысленный» — условные и относительные понятия.
2. «специализация» — да, «расширяемость» — нет, всё зажато в рамках основных понятий и ООП.
3. «независимый от конкретных языков», что приводит к абстракциям, которые отрываются от реализации на конкретных программных платформах. И язык должен быть только ОО.
4. «формальную основу для понимания» — О! Готовы рассказать об этом? :)
5. Точнее, только ОО инструментов и только для ООП.
6. А подробнее, что есть для этого именно в самом UML?
7. Как и что? Всех заставить рисовать на UML? Много интегрировали?
Спасибо за комментарии. Вся редакция Ave Кодер сразу поняла, кто самый умный мальчик в классе.
Мы также рады, что наш материал побудил Вас к созданию собственной статьи на схожую тему. Именно это и была одной из целей нашего блога — пробудить людей к изучению IT.
Мы от всей души желаем Вам удачи в Ваших проектах, например Gitune (хотя мы бы советовали Вам поработать над уровнем английского — количество ошибок просто зашкаливает, ну и дизайном) и хотели бы попросить Вас ограничиться от пассивно агрессивного поведения на столь уважаемом ресурсе — вы показываете себя в дурном свете.
Уңышлар телим!
Мы также рады, что наш материал побудил Вас к созданию собственной статьи на схожую тему. Именно это и была одной из целей нашего блога — пробудить людей к изучению IT.
Мы от всей души желаем Вам удачи в Ваших проектах, например Gitune (хотя мы бы советовали Вам поработать над уровнем английского — количество ошибок просто зашкаливает, ну и дизайном) и хотели бы попросить Вас ограничиться от пассивно агрессивного поведения на столь уважаемом ресурсе — вы показываете себя в дурном свете.
Уңышлар телим!
Ну вот, я думал, сейчас обсудим Формальную семантику, OCL и MOF по п.4, обменяемся мнениями о https://www.omg.org/industries по п.7.
PS. Я не Алексей, который из Gitune.
PS. Я не Алексей, который из Gitune.
Sign up to leave a comment.
Что находится между идеей и кодом? Обзор 14 диаграмм UML