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

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

Тобто я ніколи не генерував код автоматично з діаграм, а з точки зору зв'язку я, як правило, намагаюся тримати свої діаграми максимально простими та зрозумілими.

Але коли я дивлюся на Visio та Enterprise Architect, здається, у них є багато різних типів графіків, форм, об'єктів властивостей, більшість з яких я не використовую.

Чи використовують люди UML, щоб робити більш складні речі, такі як генерація коду чи бази даних?

Так, інструменти UML CASE були одним із найпопулярніших пунктів 90-х…, а потім не вдалося доставити.

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

Єдиним потенційним винятком із цього, про який я знаю, є діаграми взаємовідносин між сутністю, які не містять код сам по собі, лише (як випливає з назви) фрагментів даних та їх взаємозв'язків. Але я ніколи не чув про успішну спробу використання будь-якого типу діаграм UML для генерації реального коду [Оновлення] - тобто більше, ніж скелети класів та тривіальний код, як геттери / сеттери - за винятком інструментів / областей, таких як ORM, як свідчив Док Браун нижче [/ Оновлення] , і я думаю, це не випадково.

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

Тому коли я був в uni (деякий час тому назад), мені сказали, що UML - це майбутнє, UML замінить програмування, і ми просто генеруємо код із діаграм тощо.

Вони помилялися. Це станеться у той час, коли люди відмовляться від мови і повернуться до печерного живопису.

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

НІ

Легенда ґрунтувалася на невдалому припущенні, що пише:

class ClassName extends SomeThing
{

}

... це важко і потребує автоматизації .

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

Був там, не вважав це занадто корисним.

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

В одному з проектів нам потрібно було розробити код в UML-модельєрі (Rhapsody) і згенерувати його звідти. Це працювало і, ймовірно, було дещо легше, ніж набирати заголовки (це був C ++) та прототипи вручну. Можливість автоматично зберігати ці два послідовності була дещо зручною.

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

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

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

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

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

все це (схеми моделювання) призначено для комунікаційних цілей

Моделювання має 4 важливих звички в процесі розробки програмного забезпечення:

1. Інтегрований інструмент дизайну

2. Інструмент зв’язку

3. Допомога для генерації програмного забезпечення

4. Спосіб зменшити складність проблеми з реальними словами (я дізнався про це у відповіді @kevin cline вище)

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

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

Чи використовують люди UML, щоб робити більш складні речі, такі як генерація коду чи бази даних?

Так, справді. ЕРД (не діаграма UML) та діаграми класів можуть використовуватися (залежно від можливостей вашого інструмента) для створення:

1 - Мова визначення даних (DDL)

2 - Збережені процедури для CRUD та діаграм класів на бажаній мові (менш корисні, оскільки інструменти ORM роблять більше для цього)

Серед найцінніших особливостей інструментів моделювання є:

1 - Здатність зберігати цілісність моделі. Якщо ви внесете зміни, вони поширюються в моделі

2 - Можливість відповідати на запитання, де використовуються (де "рахунок", який використовується в моїй моделі?)

3 - Можливість дозволити сумісним користувачам працювати над моделлю

4 - Пошук у графічних зображеннях

5 - Контроль друку

6 - Нашарування (організуйте елементи діаграми по шарах), щоб ви могли зосередитись на шарі одночасно

7 - Генерація коду бази даних для декількох систем баз даних

8 - Перевірка моделі (перевіряє послідовність, відсутні клавіші, цикли тощо)

Отже, інструменти для моделювання, особливо хороші, роблять набагато більше, ніж Paint.

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

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

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

У своєму останньому проекті я використовую UML-Lab (https://www.uml-lab.com). Це приємний інструмент, який дозволяє також розробляти модель реверсу. Інструмент генерує код Java та навіть анотації JPA, які є досить точними.

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

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

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

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

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

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

Використовуючи OAW та такий інструмент моделювання, як Enterprise Architect, ми можемо записати сильніші генератори коду, які можуть навіть допомогти у створенні конфігураційних файлів, заводського коду за допомогою стереотипів та позначених значень.

Я досі не розумію, чому бізнес-розвідка з такими інструментами, як Business Object здатна аналізувати та використовувати переваги всієї інформації про компанію, тоді як на технологічному рівні ми все ще працюємо лише на рівні коду або на абстрактному рівні з UML !!

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

Рішення полягає в перетворенні для відображення реального світу, і тому весь проектний код в єдину модель UML. Маючи єдину модель та повну логіку проекту, ви зможете щоразу створювати погляди з моделі, а не з коду. Є смілива ініціатива, яку виступив Omondo в рамках технології Java / Jee. Концепція - це прямі синхронізовані MOF та UML безпосередньо з кодом та ORM. Діаграма UML - це лише представлення на високому рівні моделі, яка відображає весь проект. Ви можете створити сотні переглядів, додати сотні приміток тощо ...., щоб краще зрозуміти проект. Код буде генеруватися лише в тому випадку, якщо елемент буде змінено або створено. Чудова технологія, де Java Id відображається на ідентифікатор UML без традиційного моста трансформації між MOF та UML.

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

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