MDE to skrót od Model Driven Engineering, nazwy ogólnego trendu w świecie inżynierii.

Od pewnego już czasu  da się zaobserwować, że ludzie i ich umiejętności nie nadążają za złożonością systemów… Nie jest to jakieś wielkie odkrycie, bo problem ten wystąpił w inżynierii maszyn kilkadziesiąt lat temu… mniej więcej w czasie gdy zaczęły się pojawiać pierwsze samochody, potem było już coraz gorzej: liczba detali maszyn idzie w tysiące  (pojazdy) a nie raz i miliony (samoloty pasażerskie, pociągi).

Jedynym sposobem zapanowania nad złożonością obecnych konsytuacji inżynierskich jest redukcja złożoności ich opisów, a możliwe jest to jeżeli zaczniemy tworzyć abstrakcje opisujące wybrane aspekty tych konstrukcji. Jest to także zgodne z podejściem naukowym (ogólna teoria systemów, metodologia nauki), polegającym na generalizowaniu.

W inżynierii od lat stosowane są rysunki techniczne poglądowe, dokumentowanie konstrukcji od ogółu do szczegółu. Po pojawieniu się komputerów osobistych pojawiły się ich – desek kreślarskich – odpowiedniki w postaci aplikacji CAD/CAM.

W inżynierii oprogramowanie notacje, odpowiedniki rysunków technicznych, pojawiły się już w latach 80-tych. Rozwijały się wraz z rozwojem inżynierii programowania i technologii informatycznych. Języki programowania także rozwijają się w stronę coraz wyższego poziomu abstrakcji (od asemblera do języków skryptowych takich jak Pyton czy Ruby on Rails).  Rubikon został przekroczony gdy pojawiły się metody obiektowe w inżynierii oprogramowania i notacja UML (co metodologicznie niemalże zrównało inżynierię oprogramowania z innym obszarami inżynierii).

W konsekwencji w inżynierii oprogramowania na pierwszy plan wysuwa się rola architekta rozwiązania, przed  rolami związanymi z implementacją. Architekt to ktoś kto wie co i po co ma powstać, projektuje rozwiązanie na poziomie abstrakcji ignorującej detale a skupiającej się na cechach użytkowych. Bardzo ważne: architekt nie jest developerem.

W obszarze inżynierii oprogramowania organizacja standaryzująca Object Management Group (OMG.org) opracowała specyfikację MDA (Model Driven Architecture). MDA na tle MDE wygląda tak:

Kluczowy jest tu obszar oznaczony kolorem zielonym (model driven development), to obszar pracy z abstrakcją systemu, pozwalający na dopracowaniu konstrukcji i jej testowaniu, bez konieczności tworzenia realnych prototypów, które są najkosztowniejszą częścią projektów inżynierskich.

Jednym z kluczowych pojęć w procesie tworzenia abstrakcji – modelu – rozwiązania jest pojęcie metamodelu. Metamodel to abstrakcja budowana w oparciu o klasy elementów systemu. jest to dość trudne pojęcie jednak nie raz stosowane intuicyjnie: pisząc w dokumentacji wymagań Faktura najczęściej mamy na myśli wszystkie dokumenty będące fakturą, a nie konkretną fakturę FV/1234/2018. Użycie pojęcia Faktura to nic innego jak nazwanie (wyodrębnienie) klasy dokumentów mających pewne wspólne.

Autor cytowanej prezentacji opisuje także aspekty generowania kodu z modeli, jednak tu osobiście jestem sceptykiem. Wyeliminowanie ludzi z procesu tworzenia kodu jest w moich oczach taką samą utopią jak 100% eliminacja ludzi z procesu tworzenia i realizacji konstrukcji drapaczy chmur czy samochodów.

A teraz zapraszam do lektury cytowanej prezentacji. Co prawda opublikowana w 2013 roku ale nie straciła wiele na aktualności.