Які діаграми UML досі широко використовуються? [зачинено]

Я викладаю програмне забезпечення на бакалавраті, і у мене є питання до практиків UML.

Більшість підручників з програмної інженерії вживають серйозних зусиль у висвітленні діаграм UML. Але з іншого боку, я почув від багатьох випускників, що UML, здається, більше не використовується в окопах.

Які діаграми UML досі широко застосовуються в професійній практиці, і чому? Чи є діаграми, які більше не використовуються і чому?

NB: Щоб уникнути дебатів та обговорень, заснованих на думці, будь ласка, проілюструйте свою відповідь фактичними та об'єктивними елементами (якщо можливо, перевіреними) або нейтральними спостереженнями щодо особистого досвіду

З багатьох діаграм, запропонованих UML, діаграми класів та діаграми послідовностей все ще широко використовуються, безумовно, слідують діаграми стану:

• їх можна легко використовувати на білих дошках для розробки та обговорення дизайну перед тим, як стрибнути в код
• вони дозволяють дуже швидко передати огляд, який сам код не дає так легко, і немає його замінної замінності.

Я думаю, що випадки використання в реальному житті використовуються більш епізодично. У великих проектах, що мають кілька сотень випадків використання, діаграми болісно малювати і не дають мало користі для таблиці. Значно більше використовуються BPMN для проектування процесів, відображення історій користувачів або табличне розкладання подій у стилі Кокберна . Чому? Оскільки вони легше ділитися з діловими користувачами, щоб ефективно розробити вимоги.

Я впевнений, що це місця, де UML все ще активно та систематично використовується. Я не уявляю, що аерокосмічне програмне забезпечення або системи управління атомними електростанціями виробляються без повного набору документації UML. Але я вважаю, що це швидше виняток, ніж правило.

Я відчуваю підтвердження в цьому твердженні, коли заглядаю в книгарні. Пару років тому ви можете знайти безліч книг про UML 2.0. Сьогодні, якщо ви шукаєте UML 2.5, вибір досить обмежений. Гірше: багато авторів навіть не докладають зусиль, щоб переглянути свої колишні книги, щоб вони були актуальними (наприклад: приємний вступ Фаулера " UML-дистильована ", який досі починається з 2003 року з UML 2.0 і такий же для Емблерових "Елементів" стилю UML 2.0 "!).

Я не думаю, що ця тенденція, що зменшується, зміниться, дивлячись на узагальнення спритного та його просування "Робочого програмного забезпечення над всеосяжною документацією".

Зрештою, я дуже провокаційно стверджую, що методи моделювання, як видається, дотримуються дарвіністичної схеми: виживе лише найбільш підходяща техніка діаграми, ті, що забезпечують явну перевагу перед неформальними підходами (наприклад, ілюстрація серветки) та детальний код (наприклад, навіщо малювати схему активності А1, коли відповідний код міг би вміститися на аркуші А4?) ;-)

З іншого боку, я чув від багатьох випускників, що UML, здається, більше не використовується в окопах.

Всі вони використовуються на практиці. Але не всі ними користуються. Деякі люди відмовляються від дизайну повністю і переходять безпосередньо до кодування. Ви не можете покластися на анекдотичні докази, щоб знати, що роблять "усі".

Такі інструменти, як UML, працюють найкраще, якщо ви використовуєте, коли вони додають значення ; напр

• для великих проектів
• для складних частин проекту
• коли дизайн проекту вимагає введення декількох людей

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

Також ... UML насамперед розроблений як інструмент дизайну. Це не так ефективно (в ці дні), як інструмент документації. Типові IDE допомагають вам візуалізувати багато аспектів, якщо структура бази коду на ходу. Це часто краще, ніж покладатися на діаграми UML, які, можливо, застаріли / неточні.

У траншеях досі використовується UML. Але, як завжди, люди використовують його підмножину. Який підмножина є предметом проблем.

UML поставляється у багатьох версіях. Але, як завжди, люди використовують його символи неофіційно та непостійно.

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

Замість того, щоб створювати студентів, які можуть виправити будь-яку діаграму UML на відповідність UML версії 2.5 , або будь-яку найновішу, випускайте учнів, які можуть зрозуміти, що діаграма намагається повідомляти, навіть якщо вона не повністю відповідає конкретній версії UML, оскільки це як UML використовується в траншеях. Він подається в дивних місцевих діалектах, змішаних з іншими системами, і іноді ми просто складаємо власні символи.

Навчіть їх, що добре запитати, що означають речі. Не вчіть їх виправляти інших, які порушують деякі уявні правила. Ми просто намагаємося спілкуватися тут.

Найкраще, що я бачив у uml, це дозволити новому програмісту показати нам свій план вирішення проблеми. Це швидко показало нам частину системи, яку ми нехтували чи не усвідомлювали.

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

Але я думаю, що всі ми знаємо, що існує різниця між звичайною головкою стрілки і відкритою головкою стрілки. Правильно?

Я буду конкретний відповідно до свого досвіду: - Діаграма розгортання - Діаграма послідовності - Діаграма класу Ці три найбільш використовувані в будь-якому проекті, вони забезпечують реальну цінність спілкування з командою на різних рівнях.