Разработчики программного обеспечения часто изучают программирование на UML в колледже.
Кредит изображения: Stockbyte / Stockbyte / Getty Images
Унифицированный язык моделирования (UML) - это язык моделирования программного обеспечения с упором на графику и движение. Согласно Sparx Systems, это отраслевой стандартный язык для моделирования и проектирования программного обеспечения. Однако некоторые разработчики и компании, занимающиеся разработкой программного обеспечения, могут столкнуться с проблемами при использовании UML. Недостатки использования UML включают добавление задач в объем работ проекта и чрезмерное использование диаграмм UML.
Время
Один из недостатков, который некоторые разработчики могут найти при использовании UML, - это время, необходимое для управления диаграммами UML и их поддержки. Для правильной работы схемы UML должны быть синхронизированы с программным кодом, что требует времени для настройки и обслуживания, а также добавляет работы в проект разработки программного обеспечения. Небольшие компании и независимые разработчики могут не справиться с дополнительным объемом работы, необходимой для синхронизации кода.
Видео дня
Неясно, кому это выгодно
Не всегда ясно, кому выгодна диаграмма UML. Согласно статье, опубликованной на веб-сайте Eiffel Software, UML невыгоден разработчикам программного обеспечения, главным образом потому, что разработчики программного обеспечения работают с кодом, а не с изображениями или диаграммами. Диаграммы UML могут быть полезны менеджерам проектов или руководителям, чтобы проиллюстрировать, как будет работать программный инструмент, но они может быть проще нарисовать схему на доске или листе бумаги, чем тратить время на изучение UML язык.
Диаграммы могут быть ошеломляющими
При создании диаграммы UML в сочетании с разработкой программного обеспечения диаграмма может стать чрезмерно сложной или чрезмерно сложной, что может сбивать с толку и расстраивать разработчиков. Разработчики не могут описать каждый сценарий для программного инструмента на диаграмме, и даже если они попытаются это сделать, диаграмма станет беспорядочной. Один из способов решения этой проблемы разработчиками - включение в Диаграммы UML, согласно сообщению Стефано Борини, квантового химика и UML, о переполнении стека разработчик.
Слишком много внимания дизайну
UML уделяет большое внимание дизайну, что может быть проблематичным для некоторых разработчиков и компаний. Просмотр объема программного обеспечения на диаграмме UML может привести к чрезмерному анализу заинтересованными сторонами программного проекта. проблемы, а также заставляют людей терять концентрацию, тратя слишком много времени и внимания на программное обеспечение Особенности. Компании не могут решить каждую проблему с помощью программного инструмента, используя диаграмму UML - в конце концов, им просто нужно начать кодирование и тестирование. Броуди Гуч, один из создателей UML, сказал, что первоначальное видение UML было «графическим языком, помогающим рассуждать о проектировании системы как он разворачивается ". Если люди зацикливаются на диаграммах для выявления и решения проблем, это может задержать фактическую работу, которая должна быть выполнена, чтобы исправить вопросы.
