Несколько лет назад все в нашем магазине были сумасшедшими с UML. Теперь все, кажется, остыли.
Мне любопытно, если в проектах программного обеспечения все еще широко используется UML.
Если это так, это использование ограничено доской? Используете ли вы его для документации? Используете ли вы инструменты для генерации кода?
Я предпочитаю гибкое принятие UML (например, эскизов белой доски) над адаптацией водопада UML (например, чрезмерные документы сложных диаграмм, нарисованных в Visio).
UML по-прежнему полезен для объяснения дизайна кому-то другому. Например. композитный шаблон проектирования легко объяснить с помощью простых диаграмм классов (т.е. после того, как вы закончите с этими интересными аналогами).
Несколько рисованных диаграмм классов и последовательностей удобны для быстрого запуска, когда сталкиваются с новым или старым проектом с классами, замусоренными повсюду и без хорошей документации.
Моя команда также успешно использует диаграммы классов для генерации схем баз данных. Возможно, есть лучшие способы, но этот еще один вопрос.
Я всегда использовал графику UML (или UML) в качестве поддерживающей документации. Документы предоставляют фрагмент времени, например "это была наша оригинальная концепция пользователя". Хранение документов в актуальном состоянии является сложным и будет сделано только в том случае, если нам необходимо изменить наше определение. Затем у нас есть еще один быстрый снимок. UML не был дизайном, а частью процесса проектирования.
Я использовал некоторые инструменты генерации кода, которые использовали UML, но только для создания начальных заглушек. Обычно, когда код был сгенерирован, он эволюционировал отдельно от диаграммы.
Одна проблема с UML заключалась в том, что во многих случаях возникали споры о правильном синтаксисе/стиле UML вместо того, чтобы сосредоточиться на том, помог ли этот чертеж клиенту, аналитику или разработчику понять концепцию. Я знаю, что синтаксис важен при генерации кода, но я нашел, что UML лучше всего использовать для понимания концепции.
См. SO: Является ли UML практическим? для получения дополнительных ответов по этой теме. Похоже, что UML по-прежнему полезен для обмена идеями и системами. Кажется, что люди используют это как описание, а не определение. Если вы отделите UML от самой реализации, вы столкнетесь с проблемой сохранения двух синхронизаций.
Я использую UML для начальных проектов и в качестве помощи при обсуждении при разговоре с другими разработчиками. Но, помимо первоначального дизайна, время, потраченное на то, чтобы поддерживать UML в актуальном состоянии, не стоит усилий.
Я видел, как сгенерированный UML использовался, чтобы помочь новым нанимателям получить представление о том, что было очень сложной и сложной системой. Поскольку UML автоматически генерировался из кода, он всегда был актуальным, и некоторые люди считали его полезным.
UML мертв, мертв, мертв: Является ли UML действительно мертвым или только Cataleptic?
Белая доска/документация в порядке. Генерирование кода из него? Кому это нужно и для чего?
Я действительно использую UML, чтобы помочь мне визуализировать и продумать проблемы. Для этой цели очень полезны диаграммы последовательности, диаграммы деятельности и диаграммы объектов.
Компонентные диаграммы хороши, когда вы пытаетесь передать программные уровни.
Диаграммы развертывания очень полезны для определения упаковки и развертывания, а также для путей связи node.
Диаграммы классов Я считаю наименее полезными, так как большинство IDE могут легко создать иерархию классов.
Я использую UML в обсуждениях с другими разработчиками. Я часто думаю о себе, что я более успешен в передаче информации другим людям с помощью изображений, поэтому я рисую диаграмму классов или диаграмму действий на доске при мозговом штурме с остальной частью команды. Другие участники могут рисовать и изменять его, и как только мы все узнаем, о чем мы говорим, мы склонны просто кататься с ним. Мы не потрудились генерировать код непосредственно из него (отчасти потому, что наши инструменты были ужасными), но, с другой стороны, мы, возможно, чувствовали себя более ограниченными, если бы мы это сделали. Эти проекты изменили LOT с доски...
Если вы используете Agile, вы должны использовать UML.
Моделирование важно. Если, конечно, более интересно писать код, но вы тратите время на свободное время и понятия не имеете, отвечаете ли вы требованиям клиента. Вы моделируете, чтобы понять проблему, которую вас просят решить, а также ускорить время разработки и отправить полезный продукт своим клиентам.
Сохраните золотое покрытие для завышенных кабелей Monster.
Мы по-прежнему используем UML. Как и другие здесь, я нахожу, что они очень помогают в общении. Это намного проще для людей, чтобы общаться, когда у них есть наглядные пособия (введите популярность PowerPoint). Это особенно актуально на начальных этапах проекта, где сценарии, подобные firebird84, объясняются очень часто. Кропотливая сторона UML - это поддержка диаграмм, когда разработчики проекта начинают кодирование.
Мы не генерируем код из них, хотя и мне еще предстоит лично поговорить с тем, кто использовал UML в такой степени.
Я ежедневно использую диаграммы классов для обсуждения модели, как объектов, так и схем. Это действительно отбрасывает DBAs, пока вы не укажете, что вы можете получить ERD из диаграммы классов, скользя все стрелки на другом конце строк... Стрелки все еще указывают в том же направлении, что и вы. Там он теперь изображает FK.
Существует много структурных и семантических деталей, которые различаются между двумя типами диаграмм, но преобразование стрелки, кажется, очищает ментальный блок.
Together/J - хорошая контрольная точка, потому что нет никаких усилий для создания UML, это просто рядом с вашим Java-кодом. Интересно посмотреть, использовал ли я UML, когда он был там для "свободного".
Я нашел, что полезно иметь его там? Честно говоря, я счел это полезным в качестве дополнительного визуального подтверждения и перекрестной проверки того, что дизайн, который я сделал, формировался и как инструмент визуального каталогизации. Я не думал о конкретной логике или схемах, основанных на диаграммах. Хорошо, возможно, иногда я это делал.
Стоило ли это денег? Это заставило меня почувствовать себя хорошо в этом процессе. Это выглядело впечатляющим для других. Он несколько мгновений побрился, думая о том, что я делал. Это заставило меня больше думать о аккуратности и простоте в целом, что с каждым объектом, занимающим экранную недвижимость. Это заставило меня спросить, действительно ли мне нужен этот атрибут, или я могу сделать его более аккуратным? Иногда это помогало мне "думать в UML".
С дополнительным опытом я бы теперь использовал Together/J? Буду ли я тратить время на создание UML с нуля?
Хорошо, когда я смотрю, что я на самом деле делаю для проекта, он состоит из написания проектов пользовательского интерфейса, схем баз данных и протоколов связи, учитывая использование и использование памяти, использование полосы пропускания и безопасность. На самом деле почти все возможное, кроме объектно-ориентированного/UML. И я не использую Together/J.
Почему это?
Это потому, что я теперь усвоил мои знания из UML. Сейчас я сосредоточен на достижении скорости, пространства и времени в дизайнах. Мои проекты сильно ограничены принципами UML, поэтому стоило изучить все эти вещи, но я не использую фактические бумажные UML-диаграммы или больше не думаю о UML.
Предполагается, что UML; данный. Или, скорее, его влияние на дизайн.
Теперь у меня на экране есть чистый код и данные. У меня также есть чувство достижения.: -)
Зависит от аудитории и цели того, что вы рисуете (предполагая, что вы используете UML как язык визуального моделирования, а не его менее распространенную более абстрактную форму).
Если вы сообщаете последовательность управления или иерархию классов с другими инженерами, диаграммы UML идеальны.
Коммуникационная архитектура макроприложений для клиентов или высокотехнологичных менеджеров, вы, вероятно, найдете powerpoint, однако вам может потребоваться держать нос, более эффективно
См. Documenting Software Architectures для хорошего резюме слабых мест в UML для некоторых обычно требуемых диаграмм архитектурных представлений.
Еще один совет - используйте текстовый инструмент, такой как отличный PlantUml - там очень простая DSL, чтобы узнать, а затем вы можете сосредоточиться на значении, а не принуждать Visio к рисованию прямых линий или использованию огромного перегруженного инструмента CASE. Проверьте модели PlantUml на исходный элемент управления и настройте задание CI для автоматической сборки и публикации SVG или PNG.
Я использую его для диаграмм использования. не намного больше.
Я использую UML для начальных проектов. После выполнения фазы reqs и вариантов использования (как в UML, так и в текстовой форме) базовая система выложена в виде компонентной диаграммы для идентификации отдельных компонентов, интерфейсов, а также подсистем.
Мы используем диаграммы классов UML только для некоторых царапин в основном в начале проектов, но также при объяснении нашего собственного кода другим разработчикам. Но это только справка, а не документирование нашего программного обеспечения.
На мой взгляд, много говорят об UML (людьми, журналами), но не так много людей действительно используют его.
Я решил, что мне нравятся стили Cockburn, как описано Фаулером в его книге под названием "UML Distilled". Мне они нравятся, что я разработал экспериментальный способ встраивания их непосредственно в пространства имен С#.
Сделав это, я могу бесплатно закодировать бизнес-логику или логику пользовательского интерфейса с точки зрения использования англоязычного контента для использования без необходимости писать какой-либо язык, специфичный для домена. Самое непосредственное преимущество заключалось в том, что я улучшил читаемость кода (albiet в совершенно новом и эзотерическом виде). Это еще экспериментальный подход. Однако я считаю, что это может быть полезно.
Здесь есть ссылка на вопрос, который я опубликовал, пытаясь найти другие способы сделать то, что я сделал.
Я думаю, что традиционный UML мертв. Я имею в виду статический UML, который проводит несколько месяцев моделирования требований и генерации кода из модели. Мы не можем ждать больше недели, прежде чем начинать код, потому что нам нужно доставлять наш проект быстрее и быстрее. Если вы затем моделируете код, сгенерированный код обычно настолько плох, что вам нужно его исправить. Я потратил больше времени на исправление грязного кода, созданного UML несколько лет назад, чем написание чистого нового кода.
Я думаю, что MDD (например, разработка с использованием модели) мертва, но не графическая нотация UML. Я все еще использую его каждый день, и он работает очень хорошо. Когда я получаю новые требования, я сразу моделирую его в диаграмму классов. Сначала я отменяю свой существующий проект, затем создаю новые элементы и объединяю их с существующим кодом. Для создания скелета моего требования в мой существующий проект не более 2 часов. Мне нравится создавать свой скелет с диаграммой классов, потому что он дает вам более высокий уровень абстракции и кода. Очень круто. Я использую Omondo EclipseUML, и я создан для этого инструмента, извините за других поставщиков, но этот инструмент изменил мою жизнь. Я объединять свой проект с оффшорными командами два раза в день и воссоздавать новые диаграммы. Это не автоматически, потому что я предпочитаю проверять код до принятия фиксации. Я проверяю компиляцию, а также объектный подход, и только UML может дать мне представление о том, что было сделано, как и где клей добавлен для поддержки новых требований. Я счастлив, потому что не использую более грязное генерирование кода MDD, но могу сосредоточиться на нотации и кодексе UML.
Я считаю ULM бесполезным для меня, это вредит моему творчеству. Я генерирую UML только как документацию, если клиент этого хочет. Но я не использую его для моделирования классов. Архитектура - это развивающийся процесс, где я думаю снова и снова и получаю новые идеи во всем мире, причем не только в офисе. Я постоянно рефакторинг, чтобы приблизиться к оптимальному, сначала в виду тогда в коде. Надеюсь, я понимаю, что я имею в виду.