Krzysztof Olszewski

Krzysztof Olszewski

Dyrektor Technologii i Architektury Oprogramowania

Krzysztof Olszewski

Krzysztof Olszewski

Dyrektor Technologii i Architektury Oprogramowania

To, co chciałbym dzisiaj przekazać, jest bardzo proste i jednocześnie mam nadzieję na tyle ciekawe, że warto doczytać do końca. Jako „starter” polecam dawny wpis z bloga pod tytułem „W naszych życiowych poczynaniach niezmiernie ważna jest jedność intencji i następujących po nich działań” z 2012 roku. Opisywany tam problem i prezentowane rozwiązanie może być przyczynkiem do głębszych rozważań o architekturach systemów informatycznych.

Przechodząc do konkretów, rozważmy trzy podejścia do tworzenia oprogramowania. W podejściu imperatywnym cały system powstaje jako ciąg instrukcji, oczywiście ciąg ten jest ustrukturyzowany w byty proceduralne, obiektowe czy inne, nie ma to wielkiego znaczenia, każda z aktywności, którą podejmuje system, posiada algorytm działania. W podejściu deklaratywnym system powstaje jako zbiór deklaracji czy definicji bytów, bytów abstarkcyjnych w sensie implementacji, ale realnych w sensie istnienia, posiadania cech i tożsamości. Nieodłączną częścią deklaratywnego opisu świata aplikacji są także relacje pomiędzy bytami, które nawiązują pomiędzy sobą różnego rodzaju i typu związki. W podejściu takim, aby otrzymać system trzeba jeszcze mieć interpreter modelu, specjalizowany „runtime”, który rozumiejąc model, na jego podstawie wytworzy gotową aplikację. W trzecim podejściu mieszamy te oba modele, w pewnych miejscach używając modelowego opisu a w pewnych imperatywnego, sam podział, w których miejscach które podejście stosować nie jest wcale trywialny i pomimo pewnych wzorców w tej dziedzinie, szala zazwyczaj przeważa na stronę kodu imperatywnego. Przykłady? Najprostszy – HTML opisuje deklaratywnie strukturę strony www, CSS deklaratywnie opisuje wygląd statyczny i dynamiczny tej samej strony, a JavaScript dostarcza definicji dynamicznych zachowań o imperatywnej strukturze. Przeglądarka dopełnia tu układ, będąc interpreterem modelów i środowiskiem uruchomieniowym dla kodu imperatywnego, dostarczając do tego kodu zunifikowanego modelu w postaci DOM.

To, co chciałbym przekazać poza byciem pod wrażeniem przeglądarkowej trójki HTML + CSS + JavaScript, to spostrzeżenia w dziedzinie przyszłości tworzenia oprogramowania. Zauważam i uważam, że przyszłość należy do programowania deklaratywnego, a systemy oparte o model w architekturze MDA (Model Driven Architekture) będą powoli zastępować te tworzone klasycznie (archaicznie) przy użyciu kodu imperatywnego. Co więcej, same modele będą stawały się coraz bardziej dziedzinowe, dostosowane i specjalizowane do konkretnych potrzeb i konkretnego otoczenia. Kod imperatywny jako trudny do utrzymania i rozwijania odejdzie w zapomnienie, czasy dostarczania aplikacji i systemów skrócą się o kilka rzędów wartości, wzrośnie jakość i niezawodność oprogramowania. Kod deklaratywny, przechodząc na kolejne etapy dojrzałości modelu, z czasem zbliży się do języka naturalnego i wtedy każdy będzie mógł „napisać sobie program”.

Dodam jeszcze, że po pierwsze, proces migracji do MDA nie zaczyna się teraz, tylko trwa już od dawna. Od czasów Asemblera, kiedy w zasadzie programowało się maszynę Turinga i wszystko było imperatywne, poprzez znane wszystkim „SELECT max(kwota) FROM wynagrodzenia” gdzie deklaratywność i bliskość językowi naturalnemu aż zaskakuje, i dalej poprzez adnotację „@Entity”, gdzie nie trzeba tworzyć nawet polecenia, wystarczy deklaracja, że jakiś byt jest bytem trwałym, a resztę wykonuje „runtime”, a na renesansie podejścia funkcyjnego kończąc.

Nie należy zapominać jednak o programowaniu imperatywnym, procesory dalej jeszcze przetwarzają instrukcję po instrukcji (mniej więcej), no i w związku z tym ktoś musi definiować interfejsy dla modeli i tworzyć „runtime”’y, więc spokojnie dla pasjonatów „if” i „else” pracy nie zabraknie.