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


103

В колледже у меня было много дизайна и UML ориентированных курсов, и я признаю, что UML можно использовать для использования в программном проекте, особенно в отношении use-case, но действительно ли это практично? Я сделал несколько условий совместной работы, и кажется, что UML не используется в значительной степени в отрасли. Стоит ли во время проекта создавать UML-диаграммы? Кроме того, я нахожу, что диаграммы классов вообще не полезны, потому что просто посмотреть на заголовочный файл для класса. В частности, какие диаграммы являются наиболее полезными?

Редактировать: Мой опыт ограничен небольшими, менее 10 проектами разработчиков.

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

+3

Результаты опроса, проведенного в 2013 году, показывают, что он не используется так же, как профессора программного обеспечения (!), И выявить некоторые причины, почему: http://oro.open.ac.uk/35805/8/UML%20in%20practice% 208.pdf 11 июн. 152015-06-11 23:21:25

39

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

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

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

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


17

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


1

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

  0

Или, по крайней мере, ключевые проблемы дизайна. 06 ноя. 082008-11-06 08:20:57


-3

UML - это лишь один из способов общения внутри людей. Белая доска лучше.


16

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

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

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

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

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

  0

вы читали мои мысли;) 25 сен. 082008-09-25 04:58:03


2

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

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

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


13

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

Как я посмотреть UML и Rational Unified Process является то, что это больше ГОВОРЯ о том, что вы собираетесь делать, чем на самом деле ДЕЛАЕМ что вы собираетесь делать.

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

+8

Я не буду голосовать за вас, потому что я думаю, что это хороший ответ, но я не мог больше не согласиться. Каждый раз, когда я рисую что-то, я сохраняю часы или месяцы времени dev, и я почти всегда развиваюсь один (недавно). 22 окт. 082008-10-22 06:09:40

+1

Говорить и писать о том, что вы хотите сделать, поможет вам и другим понять и уловить возможные проблемы раньше. 16 июн. 152015-06-16 17:34:32


10

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

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

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

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

  0

+1 Хорошая визуализация данных помогает выявлять проблемы и тенденции, которые в противном случае скрываются с неуместными деталями. 14 янв. 102010-01-14 11:43:09


2

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

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

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

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

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


30

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

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

+3

Странная вещь об этом сайте, нет способа сказать, что вы цитируете кого-то в первом абзаце, а затем не соглашаетесь с ними .. но да, правда: псевдокод также отличный метод диаграмм и очень часто используется. Странные метафоры с участием лесов, факелов и т. Д. Тоже велики. 22 окт. 082008-10-22 06:13:28


2

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

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

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


1

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

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

+1

Также в немного меньших проектах это разочаровывает работу, сообщая, на мой взгляд. Если вы должны спросить и рассказать все время много вещей, это прерывает работу и никаких документов не производится. Вместо этого ключевые принципы проектирования должны быть документированы и смоделированы. 06 ноя. 082008-11-06 08:24:53


0

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

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

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


0

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

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


74

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

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

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

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

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

+1

+1 так что вы нажмете 10k 11 янв. 112011-01-11 09:31:59

+25

«А как насчет нового проката, который приходит через полгода, и нужно придумать код?» Errr .. как насчет просмотра кода? Это единственный точный и полный способ ускорения работы с кодом. Также самый естественный способ, учитывая, что мы программисты. Я считаю, что нам нужно взглянуть на диаграмму, чтобы понять код, совершенно смешной, а также удручающий, что этот мусор каким-то образом стал широко распространенным. 03 июн. 112011-06-03 08:31:25

+4

Согласитесь с BobTurbo, я никогда не использовал UML, особенно чужой UML. Я всегда предпочитаю идти прямо к коду. 20 фев. 132013-02-20 19:38:41

+7

Я нашел рисунок диаграммы класса UML, прежде чем приступать к кодированию, спас мне время. Это позволило мне визуализировать конструктивные недостатки и недостатки и обсудить их с моими коллегами. Еще лучше, если они будут нарисованы с использованием инструментов CASE, они будут генерировать базовый структурный код вашего приложения. Таким образом, окупаемость в три раза. 28 янв. 142014-01-28 07:09:10

+1

@James Adam, ни одна диаграмма не должна заменять взгляд на код, но в огромных кодовых базах (попробуйте миллионы строк кода), имеющих более высокий уровень обзора системы, может спасти кучу времени и нервов. 24 янв. 152015-01-24 01:14:30

+6

Картинка по-прежнему стоит тысячи слов, даже если это код, @BobTurbo. Я не вижу рационального аргумента против этого - и это включает в себя аргументы, которые начинаются с «Ну _real_ программистов ...» Если я собираюсь поговорить об архитектуре с моей командой, я не собираюсь писать скотч 10 страниц исходного кода на доске. 19 июн. 152015-06-19 21:51:56

  0

@DavidS При необходимости диаграммы могут быть сделаны после производства намного быстрее, чем наоборот. Нет необходимости принуждать весь проект к сверхпрактичной методологии на случай, если кто-то захочет быстро взглянуть в будущее. 02 июн. 162016-06-02 03:30:24

+1

@BobTurbo Но всегда ли легко читать код другого человека? Насколько вы уверены, что просто читаете исходный код Microsoft .NET и понимаете все это за 1 месяц? Даже если вы понимаете, у вас всегда остается вопрос: «Почему он так сделал? Почему бы и нет?» Диаграммы также позволяют правильно планировать и распределять задачи кодирования, чтобы вы не перекрывали задачи. Это также помогает в определении выполнимости, стоимости, а также доказательств, чтобы оправдать ваше решение для клиентов/начальников/некодиров. По сути, рекомендуется использовать UML, если вы не разрабатываете приложение hello world. 05 дек. 162016-12-05 04:06:08


12

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

  0

Ничего себе. Как насчет инструмента, который поддерживает диаграмму в синхронизации с кодом и наоборот, например Together? 22 окт. 082008-10-22 06:08:21

+1

Тот факт, что UML может быть сгенерирован из источника, означает для меня, что нет никакой пользы в чтении UML за просто чтение источника. Другими словами, это пустая трата. 25 сен. 112011-09-25 23:42:31

+1

@MarcusDowning Нет, это помогает новым нанимателям массово. Быстрее смотреть на UML, чем на код. 16 июн. 152015-06-16 17:37:41


4

UML работал для меня в течение многих лет. Когда я начал, я прочитал Fowler's UML Distilled, где он говорит: «Делайте достаточно моделирования/архитектуры и т. Д.». Просто используйте то, что вам необходимо!


2

Я считаю, что может использоваться способ использования UFC-игр, кайтов и вариантов уровня моря в стиле кокпита, описанных Фаулером в его книге «UML Distilled». Моя идея заключалась в том, чтобы использовать примеры использования Cockburn в качестве помощи для чтения кода.

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

Пожалуйста, проверьте сообщение, если вы заинтересованы. Go here.


2

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

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


3

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

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

Это сказанное я, как следующие UML инструментов:

  1. Violet - Если бы оно было более простым было бы бумажка

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

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

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

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

8

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

  • связи
  • Стандартизированный документация Дизайн/Решение
  • DSL (Domain Specific Language) Определение
  • Model Definition (UML Profiles) Использование
  • Pattern/Asset
  • Генерация кода
  • Преобразование модели в модель

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

Обсуждение должно быть расширено от того, как UML может быть убит или применен к небольшим проектам, чтобы обсудить, когда UML имеет смысл или фактически улучшит продукт/решение, как это когда UML следует использовать. Бывают ситуации, когда UML для одного разработчика может также ощущаться, например, Pattern Application или Code Generation.


3

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


0

UML полезно двумя способами:

  • Техническая сторона: много людей (менеджер и некоторый функционал аналитик) считают, что UML является особенностью роскоши, потому что Код документация: вы начинаете кодирование, после отладки и исправления. Синхронизация диаграмм UML с кодом и анализом заставляет вас хорошо понимать запросы клиента;

  • Сторона управления: диаграммы UMl являются зеркалом требуемого клиента, который является неточным: если вы кодируете без UML, возможно, вы можете найти ошибку, требуемую после долгих часов работы. Диаграммы UML позволяют находить возможные противоречивые точки и разрешать до того, как кодирование => поможет вашему планированию.

Как правило, все проекты без UML-диаграмм имеют поверхностный анализ или имеют короткий размер.

, если вы находитесь в связанной группе SYSTEMS ENGINEERS, см. my old discussion.


2

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

  0

Это не так просто! Если вы используете обратную инженерию для извлечения UML-модели из реального кода, вы, как правило, получаете настолько много деталей в своей модели UML, что это бесполезно. Без сомнения, это преследуют исследователи, но решить эту проблему непросто. 04 фев. 162016-02-04 17:20:37


-2

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


-1

В конце UML существует только из-за RUP. Нужен ли нам UML или какой-либо из связанных с ним материалов для использования Java/.Net? Практический ответ: у них есть собственная документация (javadoc и т. Д.), Которая является достаточной и позволяет нам выполнить нашу работу!

UML no thanx.

  0

RUP - это управление процессами, UML - это язык. UML полезен, когда вы имеете дело с большим количеством людей и нуждаетесь в общем языке. 09 авг. 092009-08-09 10:20:43

+1

Когда-либо слышал о китайских whispiers - чем больше он переводил из одной формы в другую, тем меньше разница и ошибка. Если UML так хорош, почему Microsoft, Sun, Google включают UML в свои данные о продукте? Вам будет трудно найти что-либо. Что бы ни случилось с инструментами? Передовые/обратные двухсторонние инструменты? Они не существуют, потому что эта прихоть умерла из-за отсутствия заслуг. 11 авг. 092009-08-11 11:55:27


2

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

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

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

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


3

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

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

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

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

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


-1

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


3

Хотя эта дискуссия давно неактивна, у меня есть пара-моментов, которые важно добавить.

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

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

+1

Вы читали стандарт UML?он не имеет никакого математического фона вообще, и он даже имеет внутренние несоответствия. Это также очень трудно понять: например, закругленные прямоугольники используются для двух совершенно разных вещей (состояний в государственных машинах и действий и действий на диаграммах активности). Это ужасно. 27 июн. 122012-06-27 20:48:40


-3

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

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

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

+4

Пожалуйста, попробуйте разработать большое программное обеспечение для критически важных задач, которое должно взаимодействовать с различными аппаратными системами с почти или полными требованиями к реальному времени и исключительно полагаться на код для предоставления вашей документации. Теперь попробуйте управлять командой, поддерживающей это приложение с 0% времени простоя/отказа. Скажем ... системы управления авионикой, программное обеспечение для медицинских изображений и т. Д. 05 янв. 122012-01-05 15:31:21