Является ли UML практичным?

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

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

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

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

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

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

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

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

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

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

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

Общий рабочий поток и DFDs могут быть очень полезны для сложных процессов. Все остальные схемы (особенно UML), по моему опыту, без исключения были болезненной тратой времени и усилий.

Я бы не согласился, UML используется повсюду - везде, где разрабатывается проект IT, обычно будет присутствовать UML.

Теперь другое дело, хорошо ли он используется.

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

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

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

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

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

(Другими словами, это в значительной степени пустая трата времени)

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

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

Время занятий было ограничено, как и мое время вне класса. Таким образом, мы должны были выполнять проверку кода на каждом собрании класса, но с 25 студентами, зачисленными на индивидуальную проверку, время было очень коротким. Наиболее ценным инструментом, который мы нашли в этих обзорных сессиях, были ERD, диаграммы классов и диаграммы последовательностей. ERD-е и диаграммы классов были сделаны только в Visual Studio, поэтому время, необходимое для их создания, было тривиальным для студентов.

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

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

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

• Общение
• Стандартизированная документация по проектированию / решению
• DSL (Доменный Язык) Определение
• Определение Модели (UML Профиль)
• Шаблон / Использование Активов
• генерация кода
• Преобразования от модели к модели

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

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

UML работает на меня уже много лет. Когда я только начинал, то прочел книгу Фаулера "29 дистиллированных ", где он говорит: "делай достаточно" 27.". Просто используйте то, что вам нужно !

С точки зрения инженера QA, диаграммы UML указывают на потенциальные недостатки в логике и мышлении. Это облегчает мою работу :)

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

Из темы: использование моделей в процессе разработки на http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx

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

Вы также можете прочитать мой ответ на следующий пост:

Как узнать " хорошее программное обеспечение design/architecture”? at https://stackoverflow.com/questions/268231/how-to-learn-good-software-design-architecture/2293489#2293489

Хотя эта дискуссия уже давно не ведется, я хотел бы добавить еще несколько важных, на мой взгляд, моментов.

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

UML имеет еще один важный аспект: это "talks" непосредственно к нашей самой сильной способности, то есть к визуализации. Если бы, например, ITIL V3 (в глубине души достаточно простой) был передан в виде диаграмм UML, он мог бы быть опубликован на нескольких десятках раскладок A3. Вместо этого она вышла в нескольких томах поистине библейских масштабов, породив целую индустрию, захватывающие дух затраты и широко распространенный кататонический шок.

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

Чтобы научиться эффективно использовать UML, требуется немного практики. Самый важный момент-это четкое общение, модель, когда это необходимо, и модель в команде. Белые доски - это лучший инструмент, который я нашел. Я не видел ни одного "digital whiteboard software", который сумел бы захватить полезность реальной доски.

Тем не менее, мне нравятся следующие инструменты UML:

1. Вайолет - если бы все было проще, то это был бы листок бумаги

2. Altova UModel-хороший инструмент для моделирования Java и C#

3. MagicDraw - мой любимый коммерческий инструмент для моделирования

4. Посейдон-достойный инструмент с хорошей челкой на доллар

5. StarUML-лучший инструмент моделирования с открытым исходным кодом

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

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

UML - это просто язык, это не совсем метод.

Что касается меня, то меня действительно раздражает отсутствие схемы UML для проектов с открытым исходным кодом. Возьмите что-то вроде Wordpress, у вас просто есть схема базы данных, ничего больше. Вам придется побродить по кодексу api, чтобы попытаться получить общую картину.

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

Мне нравится делать диаграммы прецедентов, но я не встречал слишком много людей, которые считают их ценными.

Я часто задавался вопросом, Является ли Rational Rose хорошим примером тех видов приложений, которые вы получаете от UML-model-based design. Он раздутый, глючный, медленный, уродливый ...

Я нашел UML не очень полезным для очень маленьких проектов, но действительно подходящим для больших.

По сути, это действительно не имеет значения, что вы используете, вы просто должны иметь в виду две вещи:

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

Так что UML - это просто стандарт того, как вы планируете свои проекты. Если вы нанимаете новых людей, то, скорее всего, они знают любой существующий стандарт - будь то UML, Flowchard, Nassi-Schneiderman, что угодно - а не ваш существующий внутренний материал.

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

UML полезно, да, действительно! Основное применение, которое я сделал из него, было:

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

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

Я верю, что там может быть способ, чтобы использовать Кокберн стиль UML рыб,змей и море-уровень варианты использования, как описано Фаулер в своей книге "UML Distilled." моя идея заключалась в том, чтобы использовать случаи Кокберн использовать в качестве вспомогательного средства для удобочитаемости кода.

Итак, я провел эксперимент, и здесь есть сообщение об этом с тегом "UML" или "FOWLER.". это была простая идея для c#. найти способ встраивания вариантов использования Cockburn в пространства имен программных конструкций (таких как пространство имен класса и внутреннего класса или использование пространств имен для перечислений). Я считаю, что это может быть жизнеспособной и простой метод, но все еще есть вопросы и нужны другие, чтобы проверить его. Это может быть хорошо для простых программ, которым нужен своего рода псевдодоменный специфический язык, который может существовать прямо посреди кода c# без каких-либо языковых расширений.

Пожалуйста, проверьте почту, если вы заинтересованы. Идти сюда .

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

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

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

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

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

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

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

Я считаю, что использование UML субъективно зависит от ситуации, в которой работает команда разработчиков.

По моему опыту:

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

Знание специфики UML - когда использовать пунктирную линию или конечную точку круга-не совсем так необходимо, но все же хорошо иметь.