Розробники програмного забезпечення часто дізнаються про UML-програмування в коледжі.
Авторство зображення: Stockbyte/Stockbyte/Getty Images
Unified Modeling Language (UML) — це мова програмного моделювання з акцентом на графіку та рух. За даними Sparx Systems, це стандартна мова для моделювання та проектування програмного забезпечення. Однак у деяких розробників і компаній, що розробляють програмне забезпечення, можуть виникнути проблеми з використанням UML. Недоліки використання UML включають додавання завдань до обсягу роботи проекту та занадто велике покладання на діаграми UML.
Час
Одним із недоліків, які деякі розробники можуть виявити при використанні UML, є час, необхідний для керування та підтримки діаграм UML. Для належної роботи діаграми UML мають бути синхронізовані з програмним кодом, який вимагає часу на налаштування та обслуговування, а також додає роботу в проект розробки програмного забезпечення. Малі компанії та незалежні розробники можуть не впоратися з додатковим обсягом роботи, необхідної для синхронізації коду.
Відео дня
Незрозуміло, кому це вигідно
Не завжди зрозуміло, кому корисна діаграма UML. Згідно зі статтею, опублікованою на веб-сайті Eiffel Software, UML не є вигідним для розробників програмного забезпечення, головним чином тому, що розробники програмного забезпечення працюють з кодом, а не із зображеннями чи діаграмами. Діаграми UML можуть бути корисними для менеджерів проектів або керівників, щоб проілюструвати, як буде працювати програмний інструмент, але може бути легше намалювати схему на дошці або аркуші паперу, ніж витрачати час на вивчення UML мову.
Діаграми можуть стати переважними
Під час створення діаграми UML у поєднанні з розробкою програмного забезпечення, діаграма може стати надто складною або надто складною, що може заплутати та розчарувати розробників. Розробники не можуть намітити кожен сценарій для програмного засобу на діаграмі, і навіть якщо вони спробують це зробити, діаграма стає безладною. Один із способів боротьби з цією проблемою для розробників — це включати лише основні факти та інформацію високого рівня Діаграми UML, відповідно до публікації на Stack Overflow Стефано Боріні, квантового хіміка та UML розробник.
Занадто великий акцент на дизайні
UML приділяє велику увагу дизайну, що може бути проблематичним для деяких розробників і компаній. Погляд на область програмного забезпечення на діаграмі UML може призвести до надмірного аналізу зацікавлених сторін програмного проекту проблеми, а також призводять до того, що люди втрачають увагу, витрачаючи занадто багато часу та уваги на програмне забезпечення особливості. Компанії не можуть вирішити будь-яку проблему за допомогою програмного інструменту, використовуючи UML-діаграму – зрештою, їм просто потрібно почати кодування та тестування. Броуді Гуч, один із творців UML, сказав, що початкове бачення UML було «графічною мовою, яка допомагає розуміти дизайн системи як це розгортається." Якщо люди зациклюються на використанні діаграми для виявлення та вирішення проблем, це може затримати фактичну роботу, яку необхідно виконати, щоб виправити проблему питання.
