Які переваги моделювання програмних систем проти того, як робити все це в коді?

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

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

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

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

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

Які аргументи для моделювання програмних систем мені не вистачає?

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

Пояснення:

Питання було відкладено як незрозуміле. Тому дозвольте додати пояснення:

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

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

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

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

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

Це не означає, що я не буду вибивати ескіз UML час від часу. Але я ніколи не буду тим, хто вимагає подати документ UML, перш ніж ви зможете кодувати. Я можу зажадати, щоб ви зайняли 5 хвилин і знайшли ДЕЙШИЙ спосіб пояснити, що ви робите, бо я не витримую існування коду, який розуміє лише одна людина.

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

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

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

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

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

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

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

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

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

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

Я не погоджуюся, що всі люди, яких ви знаєте, вірять у це, але я не думаю, що це обов'язково часто. У 1970 році Вінстон Ройс знав, що розробка програмного забезпечення має певний рівень ітерації між дизайном та кодовою діяльністю. У 1992 році Джек Рівз писав про те, що кодування є справжньою дизайнерською діяльністю (також обговорювалося на C2 Wiki ).

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

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

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

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

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

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

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

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

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

Які переваги моделювання програмних систем проти того, як робити все це в коді?

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

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

Багато документів, що не кодуються, корисні як креслення . Тобто «правда» дизайну повинна слідувати цьому напрямку. Це спосіб моделювання елементів, який повинен виконати дизайн. Ви можете назвати їх документами з вимогами, але це, можливо, занадто сильно у всіх прикладах, які я можу навести. Я використовував PlantUML через PlantText.com для їх виготовлення.

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

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

• Діаграми стану можуть показувати передбачувану динаміку на веб-сайті:

• Банки з чотирьох моделей дизайну представлені у вигляді статичних та динамічних моделей. Наприклад, Memento:
  
  

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

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

• Петре, Маріан (2013). UML на практиці . В: 35-а Міжнародна конференція з інженерії програмного забезпечення (ICSE 2013), 18-26 травня 2013 р., Сан-Франциско, Каліфорнія, США, стор. 722–731.
• Н. Мангано, Т. Д. Латоза, М. Петре та А. ван дер Хоек (2015). Як дизайнери програмного забезпечення взаємодіють із ескізами на дошці . В: IEEE Угоди з інженерії програмного забезпечення, т. 41, ні. 2, стор 135-156.
• Ендрю Форвард та Тімоті К. Летбридж. 2008. Проблеми та можливості для модельного та проти кодового розвитку програмного забезпечення: опитування професіоналів програмного забезпечення . У працях міжнародного семінару 2008 року з моделей інженерії програмного забезпечення (MiSE '08). ACM, Нью-Йорк, Нью-Йорк, США, 27-32.

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

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

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

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

• Ви впевнені, що думаєте, перш ніж робити, кодування, як тільки ви знаєте, що вам потрібно зробити, ЛЕГКО.
• Ви можете поставити більш досвідчених людей, щоб зосередитись на найскладнішій частині вашого програмного забезпечення: дизайн, алгоритм / математика - будь-який, крім дуже конкретної мети (вбудований, реальний час, складання).
• Ви можете делегувати менш досвідченим людям хорошу частину процесу кодування, тоді як більш досвідчені люди зосереджуються лише на найбільш критичній частині, яка потребує рівня їхньої майстерності. Ті менш досвідчені люди дізнаються багато про це.
• Ви можете обговорити людей, які не є ІТ, через зображення вашого дизайнерського документа, тоді як, якби у вас був лише код, вам доведеться витягнути зображення того, що ви зробили, з усією небезпекою щось забути (забутий слухач десь ...). Дивіться відповідь CandiedOrange для отримання більш детального аспекту спілкування.
• Коли вам доведеться розвивати своє програмне забезпечення, ви можете краще передбачити, який вплив буде.
• Дизайн дозволить легко скоротити частину вашого програмного забезпечення і мати частину вашого програмного забезпечення, що розробляється одночасно.
• Запишіть цей проклятий ребербативний блок-тест буде набагато простіше, коли вам не доведеться боліти головою про те, щоб охопити всі випадки під час їх кодування, в TDD-підході, що кодує тест, перш ніж код стане простим.
• ...

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