Вопрос по – Вы все еще используете UML? Как? Зачем? [закрыто]

45

Несколько лет назад все в нашем магазине были Crazy с UML. Теперь все, кажется, остыли.

Мне любопытно, все еще широко используется UML в программных проектах.

Если так, это использование ограничено доской? Вы используете это для документации? Используете ли вы инструменты для генерации кода из него?

Связанный

Практично ли UML?

Ваш Ответ

19   ответов
8

и общении с другими разработчиками. Но, помимо первоначального дизайна, время, потраченное на обновление UML, не стоит этих усилий.

23

Проворный принятие UML (например, эскизы белой доски) надводопа адаптация UML (например, чрезмерные документы сложных диаграмм, нарисованных в Visio).

UML все еще полезен для объяснения дизайна кому-то еще. Например. шаблон составного проекта легко объяснить с помощью простых диаграмм классов (то есть после того, как вы закончите с этими интересными аналогиями).

Несколько нарисованных от руки диаграмм классов и последовательностей удобны для быстрого начала работы при столкновении с новым или старым проектом с повсеместно замусоренными классами и без достаточной документации.

оманда @My также успешно использует диаграммы классов для создания схем баз данных. Возможно, есть и лучшие способы, но это другой вопрос.

Я могу ошибаться, но для схем БД нет UML-диаграмм, люди обычно используют диаграммы отношений сущностей, которые не являются типом UML-диаграмм. Yasser1984
@ Yasser1984 да. Я имел в виду, что мы использовали диаграммы классов для создания схемы базы данных. rpattabi
10

тельной документации. Документы предоставляют фрагмент времени, такой как «это была наша первоначальная концепция пользователя». Постоянно обновлять документы сложно, и это будет сделано только в том случае, если нам потребуется изменить наше определение. Тогда у нас есть еще один моментальный снимок. UML был не дизайном, а частью процесса проектирования.

Я использовал некоторые инструменты генерации кода, которые использовали UML, но только для генерации заглушек. Обычно после того, как код был сгенерирован, он эволюционировал отдельно от диаграммы.

Одна из проблем с UML заключалась в том, что во многих случаях возникали споры о правильном синтаксисе / стиле UML вместо того, чтобы сосредоточиться на том, помог ли чертеж клиенту, аналитику или разработчику понять концепцию. Я знаю, что синтаксис важен при генерации кода, но я обнаружил, что UML лучше всего использовать для понимания концепции.

9

SO: UML практичен? для получения дополнительных ответов по теме. Похоже, что UML все еще полезен для передачи концепций и систем. Люди, кажется, используют это как описание, а не определение. Если вы отделите UML от самой реализации, у вас возникнут проблемы с синхронизацией.

4

который использовался, чтобы помочь новым сотрудникам получить представление о сложной и сложной системе. Поскольку UML был автоматически сгенерирован из кода, он всегда был актуален, и некоторые люди находили его полезным.

Я считаю, что генерировать UML в основном бесполезно. Он настолько подробен, что сам код так же доступен. Самый ценный UML - это абстракции более высокого уровня, и их могут создавать только люди. Chris Noe
ya, они ценны до тех пор, пока не устареют, через 5 минут после начала разработки части проекта. Возможность видеть, как код взаимодействует в одном месте, имела определенные преимущества по сравнению с просмотром многих уровней иерархии объектов. tloach
4

UML действительно мертв, или только каталептик?

Доска / Документация в порядке. Генерация кода из этого? Кому это нужно и для чего?

Генерирование документации из кода полезно, потому что оно обеспечивает синхронизацию вашей документации с кодом. Doxygen - хороший пример полезного способа создания документов из кода. Ben Collins
А как насчет Рапсодии? Это генерирует код из UML. gonzobrains
3

чтобы помочь мне визуализировать и продумывать проблемы. Для этой цели очень полезны диаграммы последовательности, диаграммы активности и диаграммы объектов.

Компонентные диаграммы хороши, когда вы пытаетесь связать программные слои.

Диаграммы развертывания очень полезны для определения упаковки и развертывания, а также путей взаимодействия между узлами.

Диаграммы классов, которые я считаю наименее полезными, так как большинство IDE могут довольно легко дать вам встроенную иерархию классов.

2

ся, что я более успешен в передаче информации другим людям с помощью картинок, поэтому я буду рисовать диаграмму классов или диаграмму деятельности на доске, проводя мозговой штурм с остальной командой. Другие участники могут нарисовать и изменить его, и как только мы все узнаем, о чем мы говорим, мы склонны просто катиться с ним. Мы не удосужились сгенерировать код непосредственно из него (отчасти потому, что наши инструменты были ужасны), но, с другой стороны, мы могли бы чувствовать себя более стесненными, если бы сделали это. Эти конструкции изменили много с доски ....

1

Моделинг важен. Если, конечно, веселее писать код, вы тратите много времени и понятия не имеете, отвечаете ли вы требованиям заказчика. Вы моделируете, чтобы понять проблему, которую вам предлагается решить, и ускорить время разработки, и доставить полезный продукт своим клиентам.

Сохраните золотое покрытие для кабелей Monster по завышенной цене.

1

я считаю, что они очень помогают в общении. Людям намного легче общаться, когда у них есть наглядные пособия (введите популярность PowerPoint). Это особенно верно на начальных этапах проекта, где сценарии, подобные объясненным firebird84, случаются очень часто. Кропотливая сторона UML - поддержка диаграмм, как только разработчики проекта начинают кодировать.

Мы не генерируем из них код, и мне еще предстоит лично поговорить с кем-то, кто использовал UML в такой степени.

0

много больше, хотя.

1

как объектов, так и схем. Это действительно отбрасывает администраторов баз данных, пока вы не укажете, что вы можете вывести ERD из диаграммы классов, переместив все стрелки на другой конец линий ... Стрелки все еще указывают в том же направлении. Там сейчас изображен Ф.

Есть много структурных и семантических деталей, которые отличаются между двумя типами диаграмм, но преобразование стрелок, кажется, освобождает умственный блок.

1

потому что нет никаких усилий по созданию UML, он просто есть рядом с вашим Java-кодом. Интересно посмотреть, использовал ли я UML, когда он был там "бесплатно".

Мне было полезно иметь его там? Честно говоря, я нашел это полезным в качестве дополнительной визуальной гарантии и перекрестной проверки, что дизайн, который я сделал,бы принимает форму и как визуальный инструмент каталогизации. Я не думал о конкретной логике или схемах, основанных на диаграммах. Ну ладно, может быть, иногда я сделал.

Стоило ли это денег? Это заставило меня чувствовать себя хорошо о процессе. Это выглядело впечатляюще для других. Это сбило несколько мгновений с размышлений об инвентаре вещей, которые у меня были. Это заставило меня больше думать о аккуратности и простоте в целом, что с каждым объектом, занимающим экранную недвижимость. Это заставило меня спросить, действительно ли мне нужен этот атрибут или я могу сделать его аккуратнее? Это иногда помогало мне «думать в UML».

С дополнительным опытом, я бы теперь использовал Вместе / J? Буду ли я сейчас тратить время на создание UML с нуля?

Ну, когда я смотрю на то, что на самом деле делаю для проекта, он состоит из написания проектов пользовательского интерфейса, схем баз данных и протоколов связи, с учетом вариантов использования и использования памяти, использования полосы пропускания и безопасности. Фактически можно рассмотреть практически все, кроме объектно-ориентированного / UML. И я не использую Вместе / J.

Почему это

Это потому, что я теперь усвоил свои знания из UML. Сейчас я сосредотачиваюсь на достижении скорости, пространства и эффективности времени в проектах. Мои проекты сильно ограничены принципами UML, поэтому стоило изучить все эти вещи, но я больше не использую реальные бумажные UML-диаграммы и больше не думаю о UML.

UML просто предполагается; данный. Или, скорее, его влияние на дизай

Что у меня сейчас на экране чистый код и данные. У меня также есть чувство достижения. : -)

1

что вы рисуете (при условии, что вы используете UML в качестве языка визуального моделирования, а не его менее распространенную, более абстрактную форму).

Если вы связываете последовательность управления или иерархию классов с другими инженерами, диаграммы UML идеальны.

Передавая архитектуру макроприложения клиентам или старшим техническим менеджерам, вы, вероятно, найдете PowerPoint, как бы вам ни приходилось держать нос, более эффективный

Видеть Документация программных архитектур для краткого описания слабых мест в UML для некоторых часто используемых диаграмм архитектурных представлений.

Еще один совет - используйте текстовый инструмент, например, отличный PlantUML - есть очень простой DSL для изучения, и тогда вы можете сконцентрироваться на значении, а не принуждать Visio к рисованию прямых линий или использованию огромного сверхинженерного инструмента CASE. Проверьте в моделях PlantUml управление исходным кодом и настройте задание CI для автоматической сборки и публикации SVG или PNG.

0

зы reqs и вариантов использования (как в UML, так и в текстовой форме) базовая система представляет собой диаграмму компонентов для идентификации отдельных компонентов, интерфейсов, а также подсистем.

0

главным образом в начале проектов, но также и при объяснении нашего собственного кода другим разработчикам. Но это всего лишь треск, а не документирование нашего программного обеспечения.

По-моему, об UML много говорят (люди, журналы), но не так много людей действительно его используют.

0

что мне нравятся варианты использования в стиле Кокберна, описанные Фаулером в его книге «UML Distilled». Они мне нравятся настолько, что я разработал экспериментальный способ встраивания их непосредственно в пространства имен C #.

Делая это, я мог бы бесплатно кодировать бизнес-логику или логику пользовательского интерфейса в терминах англоязычного контента вариантов использования без необходимости писать какой-либо предметно-ориентированный язык. Самое непосредственное преимущество состояло в том, что я улучшил читабельность кода (очень новый и эзотерический способ). Это все еще экспериментальный подход. Тем не менее, я считаю, что это может быть полезно.

Во - это ссылка на вопрос, который я разместил, пытаясь найти другие способы сделать то, что я сделал.

0

что традиционный UML мертв. Я имею в виду статический UML, который тратит несколько месяцев на моделирование требований и генерацию кода из модели. Мы не можем ждать больше недели, прежде чем приступить к написанию кода, потому что мы должны выполнять наш проект быстрее и быстрее. Если вы моделируете, а затем генерируете код, сгенерированный код обычно настолько плох, что вам нужно его исправить. Несколько лет назад я потратил больше времени на исправление грязного кода, сгенерированного на UML, чем на написание чистого нового кода.

, что MDD (например, разработка, управляемая моделями) мертв, но не графическая запись UML. Я до сих пор использую его каждый день, и он работает очень хорошо. Когда я получаю новые требования, я немедленно моделирую их в диаграмме классов. Сначала я переворачиваю свой существующий проект, затем создаю новые элементы и объединяю его с существующим кодом. Создание каркаса моего требования в моем существующем проекте занимает не более 2 часов. Мне нравится создавать свой скелет с диаграммой классов, потому что она дает вам более высокий уровень абстракции и кода. Очень круто. Я использую Omondo EclipseUML, и я создан для этого инструмента, извините за других поставщиков, но этот инструмент изменил мою жизнь. Я объединяю свой проект с оффшорными командами два раза в день и воссоздаю новые диаграммы. Это не автоматически, потому что я предпочитаю проверять код перед принятием коммита. Я проверяю компиляцию, а также объектный подход, и только UML может дать мне представление о том, что было сделано, как и где был добавлен клей для поддержки новых требований. Я счастлив, потому что я больше не использую грязную генерацию кода MDD, но могу сосредоточиться на нотации UML и качественном коде.

0

это вредит моему творчеству. Я генерирую UML только как документацию, если клиент этого хочет. Но я не использую его для моделирования классов. Архитектура - это развивающийся процесс, в котором я снова и снова думаю и получаю новые идеи везде, не только в офисе. Я постоянно занимаюсь рефакторингом, чтобы приблизиться к оптимальному, сначала в уме, потом в коде. Надеюсь, вы понимаете, о чем я.

Похожие вопросы