Я должен использовать UML при разработке нового кода и алгоритмов? [закрытый]

Мне кажется, что вы говорите UML, но на самом деле говорите о некоторой генерации кода из UML. Это две совершенно разные вещи.

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

Инструменты UML - это совсем другая история: некоторые из них дешевы и полезны: например, бумага, карандаш и ластик.

Инструменты, используемые для генерации кода из диаграмм UML (или моделей UML) если быть более точным) иногда бывают дорогими и (ИМХО) всегда бесполезными. Проблема в том, что интересная часть кода требует всех мелких деталей, и очень медленно вводить все эти детали в графическую модель. Текстовый редактор более полезен для такого рода вещей. И даже для таких простых вещей, как атрибуты и ссылки, он заставляет вас чрезвычайно строго использовать UML, что просто болезненно. Представьте, что учитель английского прерывает вас каждый раз, когда вы не используете идеальный оксфордский английский.

Я считаю полезными инструменты, позволяющие рисовать диаграммы UML в свободном виде (Enterprise Architect, Visio, Whiteboard) и те, которые создают диаграммы UML из вашего кода. Нравится этот плагин для IDEA http://plugins.intellij.net/plugin/?id=3202 Доска) и те, которые создают диаграммы UML из вашего кода. Нравится этот плагин для IDEA http://plugins.intellij.net/plugin/?id=3202 Доска) и те, которые создают диаграммы UML из вашего кода. Нравится этот плагин для IDEA http://plugins.intellij.net/plugin/?id=3202 (Это сделал мой коллега, поэтому я пристрастен)

Я вижу два подхода к использованию UML: формальная фиксация проекта и неформальное наброски некоторых аспектов дизайна в качестве помощи в процессе проектирования.

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

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

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

используйте карандаш и бумагу

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

Позже вы можете рассмотреть диаграммы, если вы все сделали так, как вы хотели.

Тем не менее, было бы неплохо знать, насколько велик ваш проект на самом деле, чтобы дать вам хороший ответ?

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

[борются] со структурой Что я хочу сделать. Симптом в том, что ... Это не но мне ясно, что это компоненты точно или какие отношения - например, я удалось удалить тот, который не был

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

Сначала сделайте четкое описание того, что, по вашему мнению, хочет клиент. Дайте это клиенту, и тогда он (вероятно) сделает или скажет что-то нелестное и укажет на то, что вы пропустили. Или не считал важным. И спросите, почему программа делает "x", "i" и "r" когда он хотел «a», «b», «c» и «x».

В этот момент клиент также обычно вспоминает суперфункцию «M», без которой он не может жить.

Спецификации сэкономить ваше время и силы. Еще до того, как карандаш и бумага UML или блок-схемы.

Просто чтобы подкрепить некоторые из того, что я сказал: Безболезненные функциональные спецификации , Джоэл Спольски. Прочтите, это убедительно.

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

Для разработки кода и алгоритмов карандаш и бумага всегда лучший способ, как сказал Ому.

UML не сделает ваш код лучше, но может улучшить ваше видение того, что вы делаете.

Дело не в том, полезен ли UML для написания кода, а в о ИСТИННОЙ цели UML , чтобы вы могли представить себе, что вы хотите делать, как выглядит система .

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

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

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

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

Я использую UML для нескольких разных целей:

1. продумывание дизайна или архитектуры
2. описание архитектуры или сложных деталей проекта для коллег
3. создания диаграмм для поддержать документ

Интересно то, что я использую разные инструменты для каждого из них. Я просмотрел несколько разработчиков моделей (в приблизительном хронологическом порядке): Objecteering , ObjectDomain , Visio , ArgoUML , ] Poseidon для UML и MagicDraw . Я использую Visio и MagicDraw для большинства целей.

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

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

Встраивание диаграмм UML в документы обычно связано с Visio, хотя я никогда не использую официальную поддержку моделирования UML. Используйте вместо него трафарет Павла Грубого . Режим модели UML в Visio нарушен во многих отношениях, что на самом деле не стоит потраченных денег или усилий. Однако с трафаретом Павла создавать специальные диаграммы UML быстро и легко. Другой совет здесь - использовать формат векторной графики вместо растрового формата для самих изображений . Моя компания, как и многие другие, заражена вирусом Microsoft Office, поэтому я в значительной степени застрял в Word для документов. В этом случае я использую Enhanced Metafiles (* .emf) в качестве предпочтительного формата изображения. Если вы работаете в среде DocBook, используйте вместо него SVG .

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

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

---

ДОПОЛНИТЕЛЬНО Есть ли что-нибудь в программном обеспечении UML, которое обеспечивает согласованность (на любом уровне) между кодом и диаграммой. Я предполагаю, что когда, скажем, создается StrategyPattern, он может генерировать код-заглушку. Но можно ли включить этот код таким образом, чтобы в случае нарушения шаблона инструмент UML обнаружил это?

Существует множество различных инструментов UML, и некоторые из них имеют разную степень проверки ограничений. Обычно это ограничивается синтаксисом UML, но есть также язык объектных ограничений , который можно использовать для создания утверждений о модели UML, а некоторые инструменты могут генерировать код для проверки этих утверждений во время выполнения. (Здесь все становится немного туманным, поскольку я никогда не работал в магазине, который был готов платить за указанные инструменты, поскольку они не дешевы и чаще используются во встроенных системах, где большая часть моей работы была технических вычислений.) Итак, если вы приобрели высококачественный инструмент UML, который поддерживает сопоставление OCL с генерацией кода, настройте стереотип в своем инструменте, чтобы выразить, что такое шаблон стратегии, а затем сгенерируйте код, который включает эти утверждения (если они время выполнения) или применяет утверждения к структуре в модели (если они являются утверждениями метамодели). (Я Я не совсем уверен, позволяют ли инструменты писать ограничения для метамодели, т. е. утверждать, что стратегия должна предоставлять функцию, которая вместо того, чтобы просто утверждать предварительные и последующие условия, но тогда такие утверждения также проверяются системой типов большинства языков, если вы все равно делаете абстракцию метода в супертип стратегии). Если вы затем перепроектируете свой код, и он нарушит ограничения, он будет отмечен инструментом. Проблема в том, что то, что составляет пример некоторых шаблонов, в некоторой степени зависит от намерения разработчика, а не от чего-либо, что можно утверждать о созданной структуре.

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

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