MDE to skrót od Model Driven Engineering, nazwy ogól­ne­go tren­du w świe­cie inżynierii.

Od pew­ne­go już cza­su da się zaob­ser­wo­wać, że ludzie i ich umie­jęt­no­ści nie nadą­ża­ją za zło­żo­no­ścią sys­te­mów… Nie jest to jakieś wiel­kie odkry­cie, bo pro­blem ten wystą­pił w inży­nie­rii maszyn kil­ka­dzie­siąt lat temu… mniej wię­cej w cza­sie gdy zaczę­ły się poja­wiać pierw­sze samo­cho­dy, potem było już coraz gorzej: licz­ba deta­li maszyn idzie w tysią­ce (pojaz­dy) a nie raz i milio­ny (samo­lo­ty pasa­żer­skie, pociągi).

Jedynym spo­so­bem zapa­no­wa­nia nad zło­żo­no­ścią obec­nych kon­sy­tu­acji inży­nier­skich jest reduk­cja zło­żo­no­ści ich opi­sów, a moż­li­we jest to jeże­li zacznie­my two­rzyć abs­trak­cje opi­su­ją­ce wybra­ne aspek­ty tych kon­struk­cji. Jest to tak­że zgod­ne z podej­ściem nauko­wym (ogól­na teo­ria sys­te­mów, meto­do­lo­gia nauki), pole­ga­ją­cym na generalizowaniu.

W inży­nie­rii od lat sto­so­wa­ne są rysun­ki tech­nicz­ne poglą­do­we, doku­men­to­wa­nie kon­struk­cji od ogó­łu do szcze­gó­łu. Po poja­wie­niu się kom­pu­te­rów oso­bi­stych poja­wi­ły się ich – desek kre­ślar­skich – odpo­wied­ni­ki w posta­ci apli­ka­cji CAD/CAM.

W inży­nie­rii opro­gra­mo­wa­nie nota­cje, odpo­wied­ni­ki rysun­ków tech­nicz­nych, poja­wi­ły się już w latach 80-tych. Rozwijały się wraz z roz­wo­jem inży­nie­rii pro­gra­mo­wa­nia i tech­no­lo­gii infor­ma­tycz­nych. Języki pro­gra­mo­wa­nia tak­że roz­wi­ja­ją się w stro­nę coraz wyż­sze­go pozio­mu abs­trak­cji (od asem­ble­ra do języ­ków skryp­to­wych takich jak Pyton czy Ruby on Rails). Rubikon został prze­kro­czo­ny gdy poja­wi­ły się meto­dy obiek­to­we w inży­nie­rii opro­gra­mo­wa­nia i nota­cja UML (co meto­do­lo­gicz­nie nie­mal­że zrów­na­ło inży­nie­rię opro­gra­mo­wa­nia z innym obsza­ra­mi inżynierii).

W kon­se­kwen­cji w inży­nie­rii opro­gra­mo­wa­nia na pierw­szy plan wysu­wa się rola archi­tek­ta roz­wią­za­nia, przed rola­mi zwią­za­ny­mi z imple­men­ta­cją. Architekt to ktoś kto wie co i po co ma powstać, pro­jek­tu­je roz­wią­za­nie na pozio­mie abs­trak­cji igno­ru­ją­cej deta­le a sku­pia­ją­cej się na cechach użyt­ko­wych. Bardzo waż­ne: archi­tekt nie jest developerem.

W obsza­rze inży­nie­rii opro­gra­mo­wa­nia orga­ni­za­cja stan­da­ry­zu­ją­ca Object Management Group (OMG​.org) opra­co­wa­ła spe­cy­fi­ka­cję MDA (Model Driven Architecture). MDA na tle MDE wyglą­da tak:

Kluczowy jest tu obszar ozna­czo­ny kolo­rem zie­lo­nym (model dri­ven deve­lop­ment), to obszar pra­cy z abs­trak­cją sys­te­mu, pozwa­la­ją­cy na dopra­co­wa­niu kon­struk­cji i jej testo­wa­niu, bez koniecz­no­ści two­rze­nia real­nych pro­to­ty­pów, któ­re są naj­kosz­tow­niej­szą czę­ścią pro­jek­tów inżynierskich.

Jednym z klu­czo­wych pojęć w pro­ce­sie two­rze­nia abs­trak­cji – mode­lu – roz­wią­za­nia jest poję­cie meta­mo­de­lu. Metamodel to abs­trak­cja budo­wa­na w opar­ciu o kla­sy ele­men­tów sys­te­mu. jest to dość trud­ne poję­cie jed­nak nie raz sto­so­wa­ne intu­icyj­nie: pisząc w doku­men­ta­cji wyma­gań Faktura naj­czę­ściej mamy na myśli wszyst­kie doku­men­ty będą­ce fak­tu­rą, a nie kon­kret­ną fak­tu­rę FV/1234/2018. Użycie poję­cia Faktura to nic inne­go jak nazwa­nie (wyod­ręb­nie­nie) kla­sy doku­men­tów mają­cych pew­ne wspólne.

Autor cyto­wa­nej pre­zen­ta­cji opi­su­je tak­że aspek­ty gene­ro­wa­nia kodu z mode­li, jed­nak tu oso­bi­ście jestem scep­ty­kiem. Wyeliminowanie ludzi z pro­ce­su two­rze­nia kodu jest w moich oczach taką samą uto­pią jak 100% eli­mi­na­cja ludzi z pro­ce­su two­rze­nia i reali­za­cji kon­struk­cji dra­pa­czy chmur czy samochodów.

A teraz zapra­szam do lek­tu­ry cyto­wa­nej pre­zen­ta­cji. Co praw­da opu­bli­ko­wa­na w 2013 roku ale nie stra­ci­ła wie­le na aktualności.