Projektowanie aplikacji internetowych Wykład 2 Projektowanie aplikacji internetowych sterowane modelami Założenia projektowania aplikacji sterowane modelami Nurty MDE Proces budowy MDA Transformacje modeli Zalety i wady projektowania aplikacji sterowane modelami

Wytwarzanie oprogramowania sterowane modelami (1) Projektowanie (aplikacji) sterowane modelami - Model Driven Engineering (MDE) ma na celu podniesienie poziomu abstrakcji oraz zwiększenie automatyzacji w wytwarzaniu oprogramowania. Hasło przewodnie MDE: „wszystko jest modelem” Wykorzystanie modeli na różnych poziomach abstrakcji tworzenia systemów. Zwiększenie automatyzacji budowy oprogramowania przez transformacje modeli wyższego rzędu do modeli rzędu niższego, aż do uzyskania wykonywalnego kodu.

Wytwarzanie oprogramowania sterowane modelami (2) Główną motywacją wykorzystywania MDE jest podniesienie produktywności. MDE umożliwia to (w krótkim okresie) przez wzrost funkcjonalności podstawowych cząstek oprogramowania oraz (w dłuższym okresie) przez zmniejszenie szybkości dezaktualizowania się tych cząstek. Celem wielu technologii i narzędzi jest wzrost funkcjonalności podstawowych cząstek oprogramowania.

Postulaty stawiane przed MDE (1) Aspekty podniesienia odporności cząstki oprogramowania na zmiany: Aspekt ludzki. Wiedza o budowie systemu lub jego cząstki powinna być dostępna dla osób nie będących twórcami danej cząstki oprogramowania. Aspekt zmiany wymagań. Częste potrzeby zmian i dodawania funkcjonalności nie może mieć znaczącego wpływu na funkcjonowanie systemu.

Postulaty stawiane przed MDE (2) Aspekty podniesienia odporności cząstki oprogramowania na zmiany: Różnorodność środowisk projektowych. Model danej cząstki oprogramowania powinien być niezależny od środowisk projektowych. Zmienność środowisk uruchomieniowych. Zapewnienie jak najdłuższej kompatybilności cząstki oprogramowania z kolejnymi wersjami środowiska.

Postulaty stawiane przed MDE (3) Postulaty stawiane przed MDE (strona techniczna): Zwięzła i dopasowana do zadania notacja (graficzna). Dynamiczne dodawanie nowych elementów w trakcie działania aplikacji. Uniwersalne formaty opisu cząstek (uniezależnienie od narzędzi projektowych). Automatyzacja uzyskiwania dla danej platformy cząstek oprogramowania (mapowanie przez użytkownika).

Nurty MDE (projektowania aplikacji sterowane modelami) (1) MDA (Model Driven Architecture) - wspierany przez OMG (od 2000 r.) MDSD (Model Driven Software Development) - mniej sformalizowany (szybkie wprowadzenie do użytkowania). MDA - wykorzystywanie modeli w produkcji oprogramowania. Standard obejmuje opis rodzajów modeli, które należy używać, przygotować oraz w jakich są między sobą relacjach. MDA uwzględnia dwie perspektywy opisu oprogramowania: funkcjonalną – funkcjonowanie na zasadzie „czarnej skrzynki” konstrukcyjną – budowa i działanie na zasadzie „białej skrzynki”

Nurty MDE (projektowania aplikacji sterowane modelami) (2) Koncepcja MDA - oddzielenie sposobu działania systemu od sposobu wykorzystania możliwości platformy (systemy są definiowane niezależnie od platform). Cele stawiane przed MDA: przenośność, interoperacyjność wieloużywalność (rozdział zainteresowań na poziomie architektury)

Nurty MDE (projektowania aplikacji sterowane modelami) (3) Punkty widzenia systemu, według MDA: niezależny od sposobu przetwarzania - ukierunkowanie na kontekst i wymagania stawiane systemowi (struktura i sposób przetwarzania danych są ukryte lub nie zdefiniowane) niezależny od specyfiki platformy – ukierunkowanie na sposób działania systemu (bez detali związanych z wykonaniem operacji na określonej platformie). Obejmuje część specyfikacji systemu nie podlegającej zmianom przy przechodzeniu między różnymi platformami. uwzględniający specyfikę danej platformy - dodaje do widoku informacje o wykorzystaniu funkcjonalności specyficznych dla platformy.

Nurty MDE (projektowania aplikacji sterowane modelami) (4) MDA (Architektura Sterowana Modelami) definiuje następujące modele: CIM (ang. Computation Independent Model), PIM (ang. Platform Independent Model), PSM (ang. Platform Specific Model). Dodatkowo PDM (ang. Platform Description Model).

Nurty MDE (projektowania aplikacji sterowane modelami) (5) Model CIM (ang. Computation Independent Model) - widok na system, niezależnie od sposobu przetwarzania. Celem jest pełne zrozumienie i opisanie funkcjonowania organizacji. Nie pokazuje szczegółów struktury systemu Nazywany modelem domeny (opisywany jest językiem zrozumiałym dla praktyków) Użytkownik CIM-a nie musi mieć wiedzy o sposobie modelowania funkcjonalności systemu CIM łączy ekspertów dziedzinowych z ekspertami projektowania i budowy systemów.

Nurty MDE (projektowania aplikacji sterowane modelami) (6) Model PIM (ang. Platform Independent Model) - widok na system, niezależnie od platformy. Opisuje budowę systemu na poziomie ontologicznym (bez szczegółów implementacji) – wymagania dziedzinowe. Zbiory elementów modelu ontologicznego: kompozycja - zestawienie elementów z jakiś kategorii środowisko - zestawienie elementów z takiej samej kategorii produkcja - zbiór elementów z kompozycji tworzących coś, co jest dostarczane elementom ze zbioru środowisko, struktura -zbiór więzów interakcji pomiędzy elementami z kompozycji oraz między nimi a elementami ze środowiska.

Nurty MDE (projektowania aplikacji sterowane modelami) (7) Model PSM (ang. Platform Specific Model) – widok na system, zależnie od danej platformy (zawiera elementy i parametry specyficzne dla danej platformy). Uszczegółowiona wersja PIM. Model PDM (ang. Platform Description Model) - dostarcza informacji technicznych o częściach składowych platform i udostępnianych przez nie serwisach.

Nurty MDE (projektowania aplikacji sterowane modelami) (8)

CIM PIM PSM Proces budowy MDA Metodyki przebiegu tworzenia aplikacji na podstawie poszczególnych modeli (w oparciu o MDA): CIM (Computation Independent Model) PIM (Platform Independent Model) PSM (Platform Specific Model) Zdefiniowanie modelu CIM, we współpracy z klientem, przez personel zajmujący się stroną biznesową przedsięwzięcia. CIM jest przetwarzany na model PIM przez zespół projektowy. Zdefiniowanie platformy, co wymaga posiadania odpowiedniego modelu platformy (PDM). Transformacja modelu PIM do modelu PSM jest dokonywana pod nadzorem specjalisty od danej platformy. MDA zakłada możliwość przechodzenia między modelami tego samego typu, różniącymi się poziomem abstrakcji. Ilość transformacji jest dobierana tak, aby umożliwić przejście między końcowymi modelami różnego typu.

Metamodel Postulat MDA - formalizacja definiowania poszczególnych modeli (istnienie ujednoliconego opisu sposobu tworzenia modelu - metamodelu). Metamodel jest zbiorem koncepcji (elementów, procesów, itp.) w zakresie modelowania pewnej dziedziny. Pojęcie metamodelu może być rozumiane w dwóch kontekstach: lingwistycznym i ontologicznym. Czteropoziomowa hierarchia UML

Transformacje modeli (1) Tworzenie zasad transformacji jest zdefiniowane w MDA jako kilka podejść: 1) Wstawianie znaczników do modelu 2) Tworzenie zasad transformacji na podstawie typów modeli 3) Mapowanie wzorców

Transformacje modeli (2) Wstawianie znaczników do modelu Znacznikami nazywane są dodatkowe informacje wstawiane do modelu źródłowego, które kontrolują przebieg transformacji (na podstawie metamodelu docelowego). Model docelowy może oferować kilka rozwiązań realizacji elementu modelu źródłowego. Ich lista jest dostarczana przez metamodel docelowy. Wstawienie do modelu źródłowego znacznika określającego wybrane rozwiązanie wymusza wybór konkretnej ścieżki podczas procesu transformacji. Model źródłowy najczęściej nie jest oznaczany bezpośrednio (tworzona jest kopia pośrednia modelu źródłowego, zawierająca znaczniki i odwołania do elementów oryginału).

Transformacje modeli (3) Tworzenie zasad transformacji na podstawie typów modeli Wszystkie elementy modelu źródłowego czy docelowego są podtypami typów określonych w modelu typów dla danego modelu. Zdefiniowany jest zestaw reguł mapujący bezpośrednio typ ze źródłowego modelu typów na typ z docelowego modelu typów. Mapowanie to może być proste (1:1) lub złożone (1:N). Model typów źródłowy i docelowy może być w ogólniejszym przypadku zastąpiony odpowiednimi metamodelami.

Transformacje modeli (4) Mapowanie wzorców Mapowanie specyficzne dla określonych grup elementów modelu źródłowego. Zmienia to zasięg reguł z całego modelu na obszary konkretnych wzorców elementów. Niewiele narzędzi MDA w pełni implementuje transformacje między metamodelami. Pozostałe narzędzia stosują różnego rodzaju techniki bezpośredniego generowania kodu źródłowego aplikacji bez zaznajamiania generatora z metamodelem docelowego języka programowania

MDSD (1) MDSD (Model Driven Software Development) – celem MDSD jest zwiększenie efektywności tworzenia oprogramowania, jego jakości, możliwości ponownego użycia. Zastosowanie MDSD ma spowodować zwolnienie twórcy oprogramowania z wykonywania nudnej, podatnej na błędy, rutynowej pracy. Wykorzystywanie sformalizowanych i dopracowanych architektur oprogramowania. Architektura stosująca niezależne od siebie opisy aspektów tworzenia aplikacji, może być wykorzystana do stworzenia tej samej aplikacji na rożne sposoby.

MDSD (2) Jeżeli architekci oprogramowania stworzą zestaw referencyjnych implementacji (realizacji najważniejszych aspektów danej architektury oprogramowania), twórcy aplikacji mogą je używać jako implementacje wzorcowe wymagające jedynie drobnych modyfikacji. Posiadanie repozytorium rozwiązań dla danej architektury, umożliwia budowę aplikacji na podstawie szablonów oraz komponentów wielokrotnego użycia. Im dokładniej opisana zostanie dana architektura oprogramowania, tym bardziej schematyczne i powtarzalne stanie się programowanie z jej użyciem. Architektura, opisująca wszystkie definicje swoich detali w formie programów nosi nazwę generatywnej architektury oprogramowania (Generative Software Architecture).

MDSD (3) MDSD - tworzenie modelu CIM/PIM z pominięciem pośredniej transformacji do modelu PSM, przechodząc od razu do kodu aplikacji (uproszczenie całego procesu). Eliminacja modeli pośrednich zapobiega również potencjalnym problemom niespójności (zmiana nie może być automatycznie przeniesiona na wyższy poziom). W praktycznym podejściu rezygnuje się z możliwości automatyzacji transformacji powrotnej z kodu do modelu abstrakcyjnego ( problem transformacji powrotnej jest nierozwiązywalny w ogólnym przypadku, gdyż dla arbitralnie wybranego kawałka kodu może nie istnieć odpowiadający mu element modelu PIM).

MDSD (4) MDSD - tworzenie modelu CIM/PIM z pominięciem pośredniej transformacji do modelu PSM, przechodząc od razu do kodu aplikacji (uproszczenie całego procesu). Stworzenie modelu PIM posiadającego elementy odpowiadające wszystkim dowolnie wybranym kawałkom kodu, sprowadziłoby go na ten sam poziom abstrakcji, co kod źródłowy. MDSD prezentuje więc podejście inżynierii normalnej (ang. forward engineering), gdzie wszystkie zmiany projektowe muszą być dokonywane w modelu, a nie w kodzie źródłowym. Możliwe i preferowane jest podejście inkrementacyjne, wykonujące wiele iteracji: modyfikacja modelu + generacja kodu.

Języki dziedzinowe - DSL Cechą MDE jest konieczność opisu modelu za pomocą konkretnej notacji bądź języka modelowania (dopasowywanego do rozwiązywania określonej dziedziny problemów oraz ich określonej reprezentacji). Tego typu „wyspecjalizowane” języki są nazywane językami dziedzinowymi - DSL (ang. DomainSpecific Language). Mogą one mieć formę zarówno tekstową, jak i graficzną. Przeciwieństwem języków dziedzinowych są języki programowania ogólnego zastosowania – GPL (ang. General Purpose Language). Język dziedzinowy wykorzystuje do opisu problemu ontologię danej dziedziny. Mając model opisany w języku dziedzinowym, można zdefiniować sposób przekształcania tego opisu w domyśle na kod w języku GPL. Prawidłowo zaprojektowany język DSL dopuszcza istnienie składni roboczych (dialektów języka) oraz zawiera opisy mapowań i semantyki.

Zalety projektowania sterowanego modelami (1) MDE jest szybsze Wyższy poziom abstrakcji modelu powoduje, że pojedynczy element odpowiada kilku(nastu) linijkom kodu. MDE obniża koszty Krótszy czas dostarczenia aplikacji na rynek, obniżenie kosztów dzięki wykorzystaniu mniejszej ilości mniej wyspecjalizowanych pracowników, zmniejszają się również koszty wprowadzania zmian. MDE sprzyja poprawie jakości Techniczna jakość aplikacji zależy od jakości generatora. MDE jest mniej podatne na błędy Testowanie aplikacji sprowadza się do testowania jej funkcjonalności. Problemy techniczne są wychwytywane podczas budowy generatora. Przeoczony błąd techniczny wymaga poprawy generatora i ponownego wygenerowania aplikacji. MDE ułatwia walidację MDE umożliwia walidację na poziomie abstrakcji modelu.

Zalety projektowania sterowanego modelami (2) Oprogramowanie stworzone w oparciu o MDE jest mniej zależne od zmian personalnych Zmiana specjalisty zajmującego się aplikacją jest łatwiejsza. MDE wykorzystuje wiedzę ekspertów z danej dziedziny MDD umożliwia ekspertom z danej dziedziny bezpośrednie włączenie się w tworzenie aplikacji. MDE docenia ekspertów technicznych Zaawansowani programiści mogą skupić się na wytwarzaniu unikalnych rozwiązań wykorzystywanych przez generator, pozostawiając powtarzalną pracę mniej doświadczonym członkom zespołu. MDE jest pomostem między biznesem a dostawcami oprogramowania Synchronizacja między potrzebami biznesowymi a rozwiązaniami technicznymi jest zawsze ważnym aspektem wytwarzania aplikacji. MDE tworzy oprogramowanie odporniejsze na zmiany wymagań biznesowych MDE przynajmniej częściowo rozwiązuje ten problem, umożliwiając szybsze tworzenie oprogramowania oraz ułatwiając modelowanie zmian.

Zalety projektowania sterowanego modelami (3) MDE tworzy oprogramowanie odporniejsze na zmiany technologii Struktura MDE zapewnia niezmienność modelu aplikacji w sytuacji zmian wykorzystywanych rozwiązań technologicznych. Zmiany są wprowadzane jedynie w generatorze kodu. MDE wymusza stosowanie konkretnej architektury oprogramowania MDE niejako gwarantuje zgodność wszystkich elementów z wybraną architekturą poprzez eliminację ręcznego wprowadzania/modyfikowania kodu elementu. MDE umożliwia przechowywanie wiedzy specyficznej dla domeny Wiedza specyficzna dla domeny, dostępna najczęściej tylko ekspertom z danej dziedziny, jest zapisywana w postaci abstrakcyjnych modeli podczas projektowania aplikacji. MDE dostarcza aktualną dokumentację Model jest dokumentacją, co gwarantuje, że nigdy nie będzie ona przestarzała lub niekompletna. MDE pozwala na skupienie się na problemach biznesowych MDE separuje sposób rozwiązania problemu biznesowego od technologii, w jakiej to rozwiązanie zostanie docelowo wykonane.

Wady projektowania sterowanego modelami (1) MDE usztywnia sposób programowania W przeciwieństwie do klasycznych metod wytwarzania oprogramowania, MDE wymaga od projektanta stosowania się do sztywnych form i ograniczeń. Modele MDE oferują tylko tyle elastyczności, ile jej zaprojektowano Pierwszym ograniczeniem jest używane narzędzie MDE, po drugie projektant ma tylko tyle elastyczności w tworzeniu modelu, ile przewidziano w wykorzystywanym języku DSL. Im wyższy poziom abstrakcji, tym więcej uogólnień. MDE zmienia wymagania stawiane przed twórcami oprogramowania W przeciwieństwie do metod tradycyjnych, część programistyczna jest realizowana przez wąską grupę ekspertów IT („meta-team”). Budowa rozwiązania biznesowego jest natomiast wykonywana przez „biznes-inżynierów”, a nie programistów. Środowisko modelowania MDE najczęściej nie wspiera kontroli wersji Istniejące rozwiązania kontroli wersji radzą sobie świetnie z tekstowymi językami programowania. W przypadku języków graficznych brak jest jak dotąd dobrych rozwiązań kontroli wersji. W przypadku dużego zespołu projektowego może to się stać poważnym problemem.

Wady projektowania sterowanego modelami (2) Istnieje tendencja do wykorzystywania „prawie ukończonych” środowisk MDE Większość udostępnianych narzędzi MDE jest jeszcze niedojrzała i nie posiada wielu pozytywnych referencji. Osoby negocjujące z klientem zakres wymagań dla aplikacji muszą znać ograniczenia technologii W związku z ograniczeniami wykorzystywanego DSL, istnieje niebezpieczeństwo, że konsultant nieznający jego ograniczeń ustali z klientem rozwiązanie niewykonalne w danym narzędziu MDE. Oferowanie rozwiązań MDE nie posiadając doświadczonego zespołu MDE staje się modne, istnieje więc pokusa oferowania tego typu rozwiązań bez odpowiedniego przygotowania zespołu. Nowinki pochłaniają czas Zespół rozpoczynający użytkowanie nowego, innowacyjnego narzędzia ma tendencję do zajmowania się wyszukiwaniem i testowaniem wszystkich „fajnych” możliwości nowej technologii, odkładając na bok realizację zleconego projektu.