Чому ми все ще не займаємося розробкою моделей? [зачинено]

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

Я також знаю, що існує маса проблем

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

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

Запитання : Що ви бачите як найбільші проблеми, через які ви навіть не розглядаєте розробку, орієнтовану на модель?

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

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

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

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

Ось мій список причин:

• крива навчання - інструменти моделювання розвиваються так швидко, що мені важко знайти інженерів, які глибоко розуміють цей інструмент. Я все ще вважаю, що ти такий же хороший, як і твій інструмент для моделювання. Справді, багато проблем, які нижче, можуть відслідковувати цю проблему - коли ви вважаєте, що інструмент занадто обмежує, можливо, ви не знаєте його досить добре.
• Занадто структурований - Особисто я опинився в ситуаціях, коли виявив, що інструмент моделювання просто надто структурований, щоб дозволити мені описати все, що потрібно описати. І як тільки я переходжу до того, щоб намалювати деяку частину моделі поза інструментом, речі швидко занепадають, коли люди починають виходити за межі інструменту, щоб знайти інформацію.
• Вартість налаштування інструменту - кожен раз, коли я намагався автогенерувати код, я в кінцевому підсумку переробляв код вручну, коли я бачив, що цей інструмент вважав правильним. Я знаю, що після декількох проблем, це питання зменшується, але це означає, що вам доведеться пережити перші кілька турів. Я, як правило, відчував, що ми граємо в ударну моль - зробіть модель -> генеруйте код -> виправити код -> оновити модель -> виправити модель, промити та повторити.
• Управління конфігурацією моделі - оскільки модель описує великі частини проекту, на певному рівні модель СМ буде більш наскрізною, ніж вбудований код. Розділення файлів моделювання - це мистецтво саме по собі - робіть це неправильно, і ви часто стикаєтеся з тупиком розробника або застарілими моделями, коли люди здаються і переходять до коду.
• час виходу на ринок - я відчував певні проблеми, коли в ситуації, коли потреба в робочому програмному забезпеченні була нагальною. Якщо проект та команда досить малі, я не бачу причин витрачати час на інструмент моделювання, коли час можна витратити на кодування та тестування. Не кожен проект достатньо великий, щоб вимагати таких інвестицій.
• Вартість відмови - коли я бачив, як проекти тікають від інструментів моделювання, це пов’язано з високою ціною відмови - щоб користуватися інструментами, потрібно залучати кожного розробника. Це велика інвестиція в навчання і досвід навчання, і дуже дорога помилка, якщо хтось погано налаштував модель. Мій досвід полягає в тому, що для правильної моделі моделі може знадобитися два-три випуски - тому багато проектів не переживають помилок моделювання досить довго, щоб зрозуміти переваги.

Це вже було цитовано, але жодна срібна куля не вирішує цю проблему досить добре:

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

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

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

Пізніше Брукс зазначає наступне про поняття "автоматичне програмування":

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

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

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

В основному, я б заперечував, що MDD - це ще один евфемізм для програмування з мовою вищого рівня, ніж це було раніше.

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

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

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

Тому що моделювання! = Програмування.

Оскільки вартість / вигода була занадто високою на стороні витрат і недостатньою на стороні вигоди. Це, мабуть, змінилося з того часу, як я востаннє переглянув MDD, тоді вам потрібно було б заплатити> 6000 доларів / місце (USD) за інструмент, який би міг бути здатним до MDD.

Тому що модель, яка достатньо описує функцію для генерування коду, вже не корисна як модель.

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

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

Microsoft / Apple / Google не натискає на це :)

Який розвиток популяризується, має багато спільного з інструментами, носіями та євангелізацією. Дуже важко пробитися з чимось, не маючи великого резервного копіювання (Ruby on the rail, можливо, виняток, але він все ще невеликий порівняно з Java / C # / Python)

Через простий закон, який вплинув на всі ці інструменти моделювання, ви знаєте, CASE, UML тощо:

Потрапити між програмістом і його кодом дуже дорого.

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

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

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

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

Але я взагалі не захоплююсь підприємницькими рішеннями.

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

Як я знаю, недоліки MDA є:

• Відсутня підтримка рефакторингу: Нехай здогадується, що я хочу моделювати об'єкти моєї моделі даних за допомогою MDA (Типовий шрифт № 1). Якщо у мене є модель, скажімо, діаграма UML, і я її змінюю, нічого з мого коду не змінюється (хоча б згенеровані класи), і замість того, щоб мати ще працюючу програму з кращими названими атрибутами, я отримую багато помилок, які я маю виправити вручну.
• Відсутність підтримка налагодження: Зазвичай переклад з моделі в код виконується, маючи під рукою деяку мову перетворення. Звичайно це не буде проблемою, але, коли ми налагоджуємо, ми оптимально не повинні турбуватися про код, який ми створюємо, і налагоджувач повинен вступати в модель трансформації. Натомість він вступає в згенерований код, і, як ми всі знаємо, перетворення повинні виглядати добре, а не генерований код. Гаразд, ми можемо досить роздрукувати його, але в оптимальному світі згенерований код є артефактом компілятора, і його ніколи не потрібно відкривати в редакторі для сеансу налагодження (я міг би жити з ним, і цей аргумент трохи теоретично, але це одна з причин проти MDA)
• Зашифровані моделі прості: в інших прикладах Модель може моделювати деякий доменний аспект, який потім компілюється в код. Так, це MDA, але більшість моделей MDA - це лише складні конфігураційні файли, з якими можна легко оброблятись під час виконання.
• Трансформації важко перевірити: Якщо ви використовуєте перетворення в спеціалізованому IDE, вони здійснюються "компілятором" IDE. Але перетворення повинні розглядатися як частина коду програми, і як такі також повинні пройти тест та вимоги щодо покриття коду програми.

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

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

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

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

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

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

Наскільки мені відомо, MDE та MDA недостатньо задовольняють потреби розробника вбудованого контролера. Моделі, безумовно, можуть бути використані для опису системи, але я не думаю, що вбудований розробник готовий довіряти моделі для доставки найкращого або навіть правильного вихідного коду.

Існує ряд плагінів для Eclipse, які дозволяють розробникові використовувати або модель для створення / оновлення коду Java, або код Java для створення / оновлення моделі. Це здається зручним інструментом. На жаль, вся моя розробка робиться в ANSI / ISO C, і я не знаю плагінів, про які я знаю, що дозволило б мені зробити те саме.

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

Як ви реалізуєте ті функції, які не вписуються в модель?

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

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

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

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

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

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

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

Як це зробити? Просто! Просто не пишіть його і не генеруйте, в першу чергу!

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

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

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

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

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

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

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

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

Розробка моделей не має сенсу, оскільки це модель зверху до коду. Неможливо створити повноцінний додаток просто з моделі, і тому MDD марний !!

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

Я виявив, що жива синхронізація з такими інструментами, як Togethersoft, Omondo, була дійсно корисною, коли я вперше почав моделювати в 2004 році. Нещодавно компанія Omondo представила новий етап, який є своєрідним відображенням між Java, моделлю та ідентифікатором бази даних. Дійсно потужна, і це добре працює в моїх проектах.

Мої діаграми UML зараз допомагають мені пришвидшити проект і вже не є марними :-)

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

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

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

Крім того, корисність MDE обмежена системами з великим використанням компонентів.

MBSE - інженерія програмного забезпечення на основі моделей - найбільш відповідний термін.

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

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

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

Ти написав:

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

Якщо ваш код повторюваний, ви або вибрали погану мову програмування, або ви погано використовуєте його. З кращими мовами повторення не потрібно. Розгляньте бібліотеку Ruby Active Record. Таблиці баз даних створюються написанням міграцій. Не потрібно повторювати визначення схеми в будь-якому іншому місці. Не потрібно визначати клас із членами даних, що відповідають стовпцям таблиці. Один рядок коду з'єднує клас із таблицею.

Я розглядаю розробку моделей як складну і неефективну обробку для слабких мов програмування.