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

Я в середині проекту, і мені запропонували написати діаграми UML (використовувати випадки, діаграми класів тощо). Проект не дуже складний.

Мені було цікаво, чи це марна трата мого часу? Чи варто мені просто займатися іншими цікавими речами, як-от писати код? І коли не нормально щось будувати, не проходячи всю концептуальну фазу? Це все в складності? І якщо так, то як це виміряти?

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

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

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

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

Планування є критичним, але, як застерігає відомий стратег Карл фон Клаузевіц

Жоден план походу не витримає першого контакту з ворогом

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

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

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

Написання UML лише для написання UML стає непотрібною бюрократією і робить проект та код менш пристосованими до змін, без жодної користі.

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

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

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

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

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

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

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

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

Я колись працював на концерті, де мені потрібно було керувати командою розробників контрактів за кордоном.

Деякі речі, які вони виробляли, були досить жахливими (поширений симптом віддалених кодерів контрактів - вони насправді не дуже дбають про ваш код, вони просто хочуть швидко виконати роботу).

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

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

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

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

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

Там це точка добре зроблено тут по ragu.pattabi розрізнення між двома видами UML ...

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

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

Я використовую UML (або що схоже на UML :)), коли розмовляю з друзями про те, що ми маємо робити. Для обговорення ідей. Не готувати UML-проект, який автоматично створить код для мене. Я не уявляю, як створювати свої класи в UML, потім генерувати код і не налаштовувати його пізніше. Цього ніколи не буває. Тому вам доведеться внести зміни з коду до UML. І коли я використовую UML, я малюю на дошці або папері. Ніколи в таких інструментах, як Enterprise Architect.

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

Проектна робоча документація є фундаментальним результатом професійного проекту. Скільки вистачає? Ну, це залежить, звичайно, від багатьох факторів. Однак, на мою думку, випадки використання, діаграми класів, діаграми потоків процесу тощо взагалі не марнують час. Вони мають значення в різних фазах проекту. Єдина проблема з документацією - це зазвичай ресурси.

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

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

Зокрема, випадки використання неможливо легко вивести з коду (на відміну від багатьох інших аспектів системи). Переконайтеся, що ви робите це.

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

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

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

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

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

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

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

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

Я вважаю їх завищеними. Я вважаю їх єдиними картинками, які не малюють тисячі слів.

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

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

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

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

Справа в документації полягає в тому, що є два рівні:

• Рішення високого рівня (архітектурні) повинні бути документацією вручну
• Факти низького рівня (відносини між суб'єктами господарювання) повинні вилучатися автоматично

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

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

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

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

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

З мого досвіду, UML важливий для спілкування між розробниками щодо моделей коду та архітектури в цілому програми.

Я люблю діаграми, але якби мене попросили зробити один (особливо UML!), Я поставив би два питання:

1. Для кого це?
2. Чи потрібні вони зараз?

Діаграми одразу застаріли. Тому якщо ви не використовуєте його для спілкування з кимось зараз, він просто згниє. І якщо людині, з якою ви спілкуєтесь, краще було б описати текстовий опис, телефонний дзвінок або неофіційну діаграму на дошці - запропонуйте це замість цього.

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

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

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

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

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

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

Про розробку програм.

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

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

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