Програмування — це матеріалізація ідей

Основна теза цієї статті: Розробку програмного забезпечення слід розглядати як матеріалізацію ідей допомогою трансформації ментальних моделей в програмний код.
У статті описується парадигма матеріалізації ідей в програмної інженерії (engl.: RPSE: Reification as Paradigm of Software Engineering).

Англійський варіант статті: RPSE: Reification as Paradigm of Software Engineering. Скорочення RPSE використовується далі в тексті для позначення цієї парадигми.

Основні визначення

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

Програмна інженерія

Під програмною інженерією ми будемо розуміти класичне визначення дисципліни Software Engineering зі словника IEEE [1]: Програмна інженерія — це «The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software».

Парадигма

Використовуваний у цій статті термін парадигмаспирається на яке стало класичним визначення парадигми Томаса Куна [2]: Парадигма — це коло проблем, набір понять, загальновизнаних правил та законів, прийомів вирішення завдань у певній галузі науки.

Детальніше про парадигмахЩоб точніше визначити використовуване далі поняття парадигми, корисно привести дві відомі цитати з книги Куна:
Під парадигмами я маю на увазі визнані всіма наукові досягнення, які протягом певного часу дають науковому співтовариству модель постановки проблем та їх рішень…

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

Програмна інженерія і особливо її важлива складова частина — програмування, не стали винятком. На даний момент існує багато конкуруючих парадигм програмування. Їх перерахуванню присвячена окрема стаття у Вікіпедії[3], а також такі цікаві огляди як [4].

Про обмеженість парадигм програмуванняАвтори описаних в [3] і [4] парадигм концентруються на вузькій під-галузі програмної інженерії, а саме — написанні програм на тій або іншій мові програмування. Я думаю, багато професіоналів згодні з думкою, що реальні програмні проекти не виходить виконати в рамках тільки однієї з цих парадигм (наприклад — функціонального програмування).

Описана в цій статті парадигма, навпаки, застосовна до різних предметних областях і фазах створення програмного забезпечення.
Про обмеженість парадигм управління програмними проектамиДеякі автори, наприклад, в огляді [5], називають парадигмами різні підходи та моделі організації і проведення програмних проектів. Наприклад, порівнюються моделі водоспаду, V-модель або Agile-модель. Навряд чи ці підходи, на відміну від парадигм програмування, згаданих вище, можна назвати парадигмами в дусі визначення Куна в силу їх відносної теоретичної простоти і відсутність широкої теоретичної бази.

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

Матеріалізація ідей

Використовуваний у цій статті термін матеріалізація ідей (engl: reification) є розширенням класичного визначення reification в інформатиці: “Reification is the process by which an abstract idea about a computer program is turned into an explicit data model or other object created in a programming language” [6].

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

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

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

Спроби сформулювати наше розуміння Ідеального як правило, не приводять до успіху.
Про це чудово сказав великий російський поет Федір Іванович Тютчев:
Як серцю висловити себе?
Іншому як зрозуміти тебе?
Чи зрозуміє він, чим ти живеш?
Думка изреченная є брехня…[7]Навіть практичні ідеї типу дрібного ремонту по дому або приготування нової варіації знайомого страви спочатку важко сформулювати. І тільки після обмірковування або спроби пояснити іншому, ідея набуває все більш чіткі «обриси».

Читайте також  Математика в Gamedev по-простому. Вектори і інтеграли

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

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

Віддаючи собі звіт про відносну неточності запропонованого визначення, далі в цій статті я буду розділяти світ феноменів нашого внутрішнього і зовнішнього світу U на дві частини:

U = M + I

де множина М складається з феноменів, які можна об’єктивно реєструвати або вимірювати (матеріальний світ) і I — все інше.

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

Або, сформулювавши у вигляді тези: Все безліч належать до програмної інженерії феноменів можна розділити на підмножину ідеальних і підмножина матеріальних. При цьому матеріальні феномени регистрируемы або вимірювані на основі їх моделей.
Процес створення або зміни програмної системи закінчується у більшості випадків створенням того або іншого коду, який з допомогою комп’ютера відображається у фізичний процес (феномен реального світу).

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

Про проміжних моделяхВ простих системах або при нескладних доповненнях/зміни великих систем розробник відразу пише код або конфігурує систему на підставі своєї ментальної моделі. Однак у більшості випадків створюються проміжні моделі різної складності і рівня формалізації — від простого списку вимог до обширних формальних моделей (наприклад, UML або ВРМN моделей)

Матеріалізація ідей в сусідніх з Програмною Інженерією областях

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

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

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

По-іншому йде справа в математиці

Про матеріалізації ідей в математиціЦікаві факти і міркування з приводу матеріалізації ідей в математиці можна знайти у пункті 7.3 у книзі[8].
«Кінцевим продуктом» математики є формальні моделі зі строго доведеними властивостями.

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

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

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

З цієї точки зору програмування лежить посередині.

Чому програмування лежить посередині?Кінцевий продукт програмування — програмний код. І хоча він при виконанні на hardware відображається в конкретні фізичні об’єкти (електричні сигнали і поля різної фізичної природи), ці об’єкти важко порівняти з гайками, шестерінками і корпусами машин. З іншого боку, програмний код близький до математичним формулам, а іноді є їх прямим відображенням. Проте в будь-якій реальній програмній системі треба враховувати масу конкретних аспектів оточення та взаємодії з користувачами або іншими системами. Це робить код більш конкретним, ніж математичні формули.
Чому програмна інженерія може повчитися у сусідніх областей у плані використання моделейРозглянемо спочатку математику.

Мультимодельность світу

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

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

Читайте також  Як написати розширення для GNOME Shell: режим «Do Not Disturb»

Морфизм моделей і узгодженість понять і нотацій

Математика добре навчилася не тільки описувати одні і ті ж реальні або уявлювані об’єкти і процеси з допомогою моделей самої різної математичної природи. Важливим досягненні математики є вміння визначати ступінь подібності моделей з різних розділів математики, а також уміння трансформувати їх один в одного. Багато проривні рішення найважливіших математичних проблем останніх років є по суті ланцюжками окремих доказів, кожне з яких використовує спеціалізованих апарат із спеціального розділу математики. У місцях з’єднання цих вузькоспеціалізованих доказів математики вміло трансформує моделі одного розділу математики в моделі іншого розділу. У програмуванні щось подібне відбувається вже зараз при компіляції вихідного коду програми і при генерації коду з DSL (Domain Specific Language) або метаданих. Але культура роботи з моделями в області програмного інжинірингу далеко відстає від математичної.

Моделі в машинобудуванні

А чому програмна інженерія може повчитися у плані матеріалізації у машинобудування?
У багатьох галузях і навіть всередині великих концернів існують ланцюжка узгоджених формальних та семи-формальних моделей. Ці ланцюжки закінчуються моделями, на підставі яких виготовляються і монтуються фізичні об’єкти — прилади і машини. Як правило, на більшість типів проміжних моделей існують формальні методи перевірки їх коректності (технічні норми). Моделі є основною мовою комунікації фахівців різного профілю у процесі проектування і виготовлення машинобудівних виробів.

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

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

 

Визначення і контури парадигми матеріалізації ідей (RPSE)

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

У рамках пропонованої парадигми:

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

Чому Матеріалізація а не Моделизация?Зазначимо, що хоча у визначенні RPSE йдеться про побудові ланцюжків моделей, тим не менш парадигму запропоновано називати матеріалізацією а не моделизацией. Тим самим робиться спроба підкреслити особливість ланцюжків моделей, які стають все менш абстрактними/ідеальними і все більш конкретними/матеріальними.
Наведене вище визначення має свої особливості і варіації в різних областях програмної інженерії. Тільки в дуже невеликій кількості випадків буває так, що в голові програміста спочатку повністю визріває ясне уявлення про спосіб вирішення що стоїть перед ним завдання, яке він після цього за невеликий час відображає в код на мові програмування. У більшості реальних проектів процеси пошуку рішення та його реалізація співіснують, розвиваються паралельно і взаємодіють один з одним. Тобто ментальні моделі, код і часто проміжні моделі (у вигляді тесту, зображень, формальних моделей типу UML) ростуть і змінюються паралельно, впливаючи одне на одного.

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

Нерідко код на деякій мові програмування фактично відсутня, оскільки створення нового рішення зводиться до управління масками конфигураторов або генераторів, як наприклад при роботі з інструментами розробки в системах типу SAP або WebSphere.

Варіанти перетворення вручну написаного або автоматично згенерованого коду у виконуваний код у наш час стали також дуже різноманітні.

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

І тим не менш, RPSE, в силу її спільності, застосовне до всіх перерахованих вище областях.
Що ще можна сказати про певну парадигму сьогодні, чи можна якось окреслити її контури поточніше?

Читайте також  Епізод 1. Вартість Hack'а

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

Моделі RPSE можна розділити на три основні категорії:

  • Ментальні моделі
  • Код на мовах програмування або його еквіваленти як моделі виконуваного коду.
  • Проміжні моделі.

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

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

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

Інтерв’ювання дозволяє на підставі правильно сформульованих питань щодо об’єктивно побудувати моделі різної складності. Найбільш вживаними є:
Структурні моделі:

  • Списки з бінарними, перечислительными (enumeration), числовими, рядковими і іншими значеннями.
  • Графові і мережеві структури даних

Моделі опису поведінки:

  • Семи-формальні моделі визначення поведінки
  • Формальні моделі визначення поведінки (наприклад — кінцеві автомати)

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

Навіщо програмної інженерії потрібна «наскрізна» парадигма?

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

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

.

Основні завдання з розвитку парадигми

 

Теоретичні завдання

Як вже неодноразово зазначалося, в тому числі і в книзі Куна[2], в більшості випадків вчені займаються вирішенням потенційно розв’язуваних завдань, і рідше беруться за такі, до яких не дуже зрозуміло як підійти. Але саме такі наші завдання. Ось основні з них:

  1. Конструктивне визначення поняття ментальної моделі.
  2. Знаходження конструктивних критеріїв оцінки ступеня абстрактності/ідеальності vs. конкретності/матеріальності моделей.
  3. Знаходження критеріїв для відбору кандидатів на роль проміжних і додаткових моделей.
  4. Відбір та розробка критеріїв і методів порівняння моделей різних типів, включаючи їх пряму і зворотну трасування.
  5. Розробка методів автоматизованої і автоматичної трансформації моделей.

 

Практичні завдання

Поряд з теоретичними завданнями для розвитку і впровадження описуваної парадигми в практику програмної інженерії необхідно вирішити як мінімум наступні практичні завдання:

  1. Створення інструментів для: а) Екстрагування і фіксації ментальних моделей. б) Автоматизованої і автоматичної трансформації ментальних моделей в проміжні. в) Трасування і оцінки зміни змісту трансформованих моделей
  2. Створення необхідної технічної і навчальної літератури та іншого медіального навчального матеріалу.
  3. Організація форумів і конференцій на цю тему

 

Висновок

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

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

Це перша стаття із запланованої серії статей. У наступних статтях я збираюся розповісти про ментальних і проміжних моделях.

Література

1. IEEE Standard Glossary of Software Engineering Terminology, IEEE std 610.12-1990, 1990.
2. Kuhn, Thomas S. The Structure of Scientific Revolutions. 3rd ed. Chicago, IL: University of Chicago Press, 1996.
3. Programming paradigm: en.wikipedia.org/wiki/Programming_paradigm (state — 27.08.2018)
4. Peter A. Henning, Holger Vogelsang Taschenbuch Programmiersprachen. Carl Hanser Verlag GmbH & Co. KG; Auflage: 2., neu bearbeitete (5. September 2007). ISBN-13: 978-3446407442.
5. Software Engineering Paradigms And Models Information Technology Essay
www.uniassignment.com/essay-samples/information-technology/software-engineering-paradigms-and-models-information-technology-essay.php (state — 27.08.2018)
6. Reification (computer science) en.wikipedia.org/wiki/Reification_(computer_science) (state — 27.08.2018)
7. Федір Іванович Тютчев. Silentium! (Мовчання (лат.), 1829 р.
8. Боровик, Alexandre. Mathematics under the microscope: notes on cognitive aspects of mathematical practice. American Mathematical Society. ISBN-13: 978-0821847619.

Степан Лютий

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

You may also like...

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *