Чи UML практичний? [зачинено]

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

Редагувати: мій досвід обмежений невеликими, до 10 проектами для розробників.

Редагувати: Багато хороших відповідей, і хоч це не найголовніше, але я вірю, що обраний є найбільш врівноваженим.

У досить складній системі є місця, де деякі UMLвважаються корисними.

Корисні діаграми для системи залежать від застосовності.
Але найбільш широко використовуються:

• Діаграми класів
• Діаграми стану
• Діаграми діяльності
• Діаграми послідовності

Є багато підприємств, які їх клянуться, і багато хто відверто відкидає їх як цілком марну трату часу і сил.

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

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

Справа не лише в тому, що ти робиш. Що з новим прокатом, який прийде через півроку і йому потрібно прискорити швидкість коду? Що за п’ять років відтепер, коли всіх, хто зараз працює над проектом, немає?

Надзвичайно корисно мати доступну базову оновлену документацію для всіх, хто пізніше приєднається до проекту. Я не виступаю за повномасштабні діаграми UML з іменами методів та параметрами (ШЛУЧА важко підтримувати), але я думаю, що основна діаграма компонентів у системі з їх взаємозв'язками та базовою поведінкою є неоціненною. Якщо дизайн системи не зміниться кардинально, ця інформація не повинна сильно змінюватися, навіть якщо реалізація налаштована.

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

Інший випадок, коли я знайшов UML корисним, це коли старший розробник відповідає за розробку компонента, але потім передає дизайн молодшому розробнику для реалізації.

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

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

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

Мені б не погодитися, UML використовується повсюдно - там, де розробляється ІТ-проект, UML зазвичай буде там.

Тепер , чи є вона використовується також інша справа.

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

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

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

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

Спосіб переглянути UML і Rational Unified Process є те , що це більше КАЖУЧИ про те, що ви збираєтеся робити , ніж на самому справі РОБИТИ то , що ви збираєтеся робити.

(Іншими словами, це багато в чому трата часу)

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

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

Час заняття було обмеженим, як і у мене поза межами аудиторії. Таким чином, нам доводилося проводити перевірку коду на кожному класному засіданні, але з 25 учнів, які записали індивідуальний час на огляд, було дуже коротким. Інструментом, який ми визнали найбільш цінним на цих сесіях з огляду, були ЕРД, діаграми класів та діаграми послідовностей. Діаграми ERD та класів були зроблені лише у Visual Studio, тому час, необхідний для їх створення, був тривальним для студентів.

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

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

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

• Зв'язок
• Стандартизована документація на дизайн / рішення
• Визначення DSL (мови, визначеної для домену)
• Визначення моделі (UML-профілі)
• Використання візерунка / активів
• Генерація коду
• Модель для моделювання перетворень

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

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

UML працював на мене роками. Коли я розпочав свою роботу, я прочитав UML Distilated Fowler, де він говорить: "зробіть достатньо моделювання / архітектури / тощо". Просто використовуйте те, що вам потрібно !

З точки зору інженера QA, діаграми UML вказують на потенційні вади логіки та думки. Полегшує роботу :)

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

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

При цьому, мені подобаються такі інструменти UML:

1. Фіолетовий - Якби це було простіше, це був би аркуш паперу

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

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

4. Poseidon - гідний інструмент з гарним ударом за долар

5. StarUML - найкращий інструмент моделювання з відкритим кодом

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

З теми: Використання моделей у процесі розробки за адресою http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx

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

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

Як навчитися «гарному дизайну / архітектурі програмного забезпечення»? за адресою /programming/268231/how-to-learn-good-software-design-architecture/2293489#2293489

Хоча ця дискусія давно була неактивною, я маю додати ще декілька - на мій погляд важливих - пунктів.

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

У UML є ще один важливий аспект: він "спілкується" безпосередньо з нашою сильною здатністю - візуалізацією. Якби, наприклад, ITIL V3 (у самому серці досить простий) повідомлявся у вигляді діаграм UML, він міг бути опублікований у кількох десятках форматів A3. Натомість він вийшов у декількох томах по-справжньому біблійних розмірів, породивши всю галузь, захоплюючи великі витрати та широко розповсюджений кататонічний шок.

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

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

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

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

По суті, не важливо, чим ви користуєтесь, вам просто потрібно пам’ятати про дві речі:

• Ви хочете якесь планування архітектури
• Ви хочете бути впевнені, що всі в команді фактично використовують однакові технології для планування проектів

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

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

UML корисний, так! Основними напрямами, які я використав для цього, були:

• Мозковий штурм про те, як має працювати певний програмний продукт. Це дозволяє легко донести те, що ви думаєте.
• Документування архітектури системи, її закономірностей та основних взаємозв'язків її класів. Це допомагає, коли хтось входить у вашу команду, коли ви виходите і хочете переконатися, що ваш наступник зрозуміє це, і коли ви зрештою забудете, для якого чорта цей маленький клас був призначений.
• Документування будь-якого архітектурного шаблону, який ви використовуєте у всіх ваших системах, з тих же причин, що описані вище

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

Я вважаю, що може існувати спосіб використовувати випадки використання UML у рибі, зміях та рівні моря, використовувані у формі Кокберна, як описав Фаулер у своїй книзі "UML Distilated". Моя ідея полягала в тому, щоб використовувати випадки використання Cockburn як допоміжний засіб для читання коду.

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

Будь ласка, ознайомтеся з публікацією, якщо вас цікавить. Іди сюди .

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

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

Виходячи зі студента, я вважаю, що UML має дуже мало користі. Я вважаю іронічним те, що ПРОГАМЕРИ ще розробили програму, яка автоматично генерує необхідні речі. Було б надзвичайно просто спроектувати функцію у Visual Studio, яка могла б витягати фрагменти даних, шукати визначення та відповіді на продукт достатня, щоб кожен міг її подивитися, великий чи маленький, і зрозуміти програму. Це також буде постійно його оновлювати, оскільки для отримання інформації вона береться безпосередньо з коду.

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

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

UML - це лише мова, це насправді не метод.

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

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

UML здається хорошим для великих проектів з великими командами людей. Однак я працював у невеликих командах, де краще спілкування.

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

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

Я вважаю, що використання UML є суб'єктивним ситуації, в якій працює команда розробників.

З мого досвіду:

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

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

UML корисний двома способами:

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

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

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

якщо ви перебуваєте в підключеній групі СИСТЕМНИХ ІНЖЕНЕРІВ , дивіться мою стару дискусію .

Зрештою, UML існує лише через RUP. Чи потрібен нам UML або будь-який пов'язаний з ним матеріал для використання Java / .Net? Практична відповідь - у них є своє документальне підтвердження (javadoc тощо), яке є достатнім і дозволяє нам виконати свою роботу!

UML не більше ніж.

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

UML, безумовно, має своє місце в галузі. Уявіть, що ви будуєте програмне забезпечення для літаків Boing або іншої складної системи. Тут допоможуть UML та RUP.

UML - лише один із методів спілкування всередині людей. Дошка краще.