Чи є майбутнє у керованої моделлю розробки програмного забезпечення

Давненько не писав. Часто виникає бажання щось написати, але потім якось руки не доходять. Аж раптом нещодавно трапилась мені на очі презентація шановного Джона ден Хаана під назвою «Чому у керованої моделлю розробки програмного забезпечення немає майбутнього» (Why there is no future for model driven development).  Оскільки я палкий прихильник розробки програмного забезпечення, керованої моделлю, не можу не відреагувати. Свою думку я йому коротко висловив на сайті, а тепер вирішив трохи детальніше розміркувати.

Почнімо з визначення. Отже розробка програмного забезпечення, керована моделлю (РКМ) – це методологія розробки програмного забезпечення (ПЗ), що спрямована на використання моделей ПЗ як основних продуктів розробки та генерування на їх основі інших робочих продуктів, у тому числі і вихідного коду, наприклад на Java або C++. Як і більшість понять у галузі ПЗ, це поняття запозичене із більш традиційних інженерних дисциплін, хоча там на керованості моделлю так явно не наголошують, оскільки використання моделей є загальноприйнятим. Ніхто навіть і уявити собі не може конструювання такої будівлі як Московський Міст у Києві чи літак «Мрія» без попередньої побудови великої кількості різноманітних спеціалізованих моделей. Моделі допомагають зрозуміти складні завдання та їх потенційні розв’язки через абстракцію. Однак у галузі розробки ПЗ моделювання аж ніяк не набуло широкого впровадження. Не будемо тут намагатися аналізувати причини, це тема окремого посту, а перейдемо відразу до демонстрації того, що РКМ має майбутнє.

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

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

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

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

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

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

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

Отже, чи є майбутнє у інженерії ПЗ, керованої моделлю? Судячи з усього так, інакше немає майбутнього у ПЗ як такого.

Як стати успішним архітектором програмного забезпечення

Молоді спеціалісти, в тому числі і я, часто захоплюються різними титулами, хочуть ці титули мати. Титул, чи посада "Архітектор ПЗ" є особливо омріяною. Хоча я не думаю, що архітектором буди краще чи престижніше, ніж кодувальником чи тестувальником, все ж архітектура є для мене найцікавішою галуззю знань в програмній інженерії. Однак чи ж інженерією є розроблення програмного забезпечення? Кількість дискусій на дану тему зростає, що змушує задуматися. Погляньте лише на розмах маніфесту програмних ремісників. І якщо інженерія програмного забезпечення не інженерія, то архітектуру освоїти з книжок або в університеті неможливо... З цього приводу хочу навести уривок з інтерв'ю Франка Бушмана (програмного інженера з Siemens) для Software Engineering Radio (епізод 54).

Міхаель: Як людина може стати успішним архітектором?

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

Однак хіба усі сучасні 100% інженерні дисципліни (наприклад, електрика, механіка) відразу були інженеріями? Хоча практика, практика, практика - це, безперечно, дуже важливо,  стати успішним архітектором без серйозної теоретичної підготовки, на мій погляд, дуже складно, адже накопичених важливих знань з архітектури програмного забезпечення сьогодні дуже і дуже багато.