"UML - це найгірше, що коли-небудь траплялося з MDD". Чому?


17

Вільям Кук у своєму твіт написав, що:

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

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

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


15
Я б сказав, що MDD - це найгірше, що коли-небудь траплялося з MDD.
Майкл Боргвардт

Відповіді:


39

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

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

2) думка, що 7 (або 13) форматів діаграм в UML може охоплювати все, є божевільною. Що з графічними інтерфейсами, веб-кадрами, авторизацією тощо?

3) UML заохочує думку про те, що моделі повинні бути графічними. Смішно! Текстові та графічні моделі є як корисними, так і часто взаємозамінними

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

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


10
+1 для пошуку та відповіді на запитання на prog.SE про власний твіт!
Warren P

Тож мені завжди здавалося, що розвиток, орієнтований на модель, стосується створення візуальної моделі. А якщо не UML, то що? (зауважте, я ніколи не любив MDD, і ненавиджу UML. Але я готовий надати MDD-sans-UML. Що мені слід спробувати?
Warren P

1
@Warren P: що вам не подобається в MDD та UML?
dan_l

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

Я думаю, що коментар "святого грааля" стосується частоти викладання.

8

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



3

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

MDD = Модель <Дизайн | Розробка>. Ідея полягає в тому, щоб мати можливість розробляти рішення на рівні абстракції, відповідного проблемній області - тобто це спроба виразити рішення проблем у найбільш природному синтаксисі для вираження цих рішень. Сама проблемна область характеризується операційною моделлю (тобто моделлю, яку можна виконати комп'ютером). Отже, MDD може бути дуже привабливим підходом, хоча і з двома основними вимогами:

  1. Треба бути у змозі скласти цю мову у форму, придатну для виконання на комп’ютері (модель повинна бути функціональною ); і
  2. Треба створити мову моделювання для проблемної області.

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

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

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


  • -2

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

    Скажімо, UML та MDD розлучилися сьогодні, щоб краще жити більше не разом :-)


    Це не "чудово" на будь-якому рівні. Користувач згубної мови програмування ADA (Booch) створив кілька дитячих діаграм і підключився до декількох більш серйозних підходів до діаграми класу для створення UML. UML одразу перетворився на генератор доходів великих виробників програмного забезпечення. Це було приголомшливо, але врятувалося просто введенням нових типів діаграм (що раніше датувались UML), як послідовність, потік даних тощо. У цьому немає нічого розширюваного. Ніяких схем баз даних, ніяких діаграм шарів, вона повна прогалин і одночасно непотрібних діаграм.
    Rick O'Shea
    Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
    Licensed under cc by-sa 3.0 with attribution required.