Standardy w zakresie systemów rozproszonych i baz danych

1. Standardy w zakresie systemów rozproszonych i baz danych Wykład 7: Model Driven Architecture (MDA) Piotr Habela Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

2. Plan prezentacji • Modelowanie – rola w dzisiejszych metodykach • Motywacja Model Driven Architecture (MDA) • Podstawowe pojęcia i koncepcja MDA • Istniejące specyfikacje OMG • MDA: podsumowanie i otwarte kwestie • MDA a nasze prace

3. Modelowanie – ogólne spostrzeżenia • Obowiązkowe z punktu widzenia jakości a nawet wykonalności większej skali projektów • Pomyślna standaryzacja UML wzmacnia jego pozycję jako środka komunikacji pomiędzy uczestnikami projektu • dynamizuje rozwój narzędzi • Narzędzia CASE nie są efektywnym środkiem programowania wyższego poziomu - wbrew początkowym nadziejom • Narzędzia CASE są traktowane często jako źródło narzutów metodologicznych i dokumentacyjnych • stąd postrzegane negatywnie np. w metodach XP

4. Geneza MDA • Kolejna inicjatywa konsorcjum OMG (CORBA, UML…), oparta na ramie pojęciowej UML • MDA jest stworzone w duchu standardu CORBA: • jako rozwiązanie uniwersalne w stosunku do platform i technologii • jako nawiązanie architektoniczne obejmujące całość cyklu wytwarzania oprogramowania • Bardziej szerokie i realistyczne spojrzenie na rozwój technologii: • Nieuniknione jest współistnienie wielu języków programowania, • Nieuniknione są różnorodne technologie middleware • Technologie ewoluują i są zastępowane przez inne • Cykl życiowy systemu/projektu może być długi

5. MDA – motywacja • Zapewnienie modelowaniu centralnego miejsca: • nie ideologicznie, a praktycznie • jako działanie ukierunkowane wprost na wytworzenie produktu • Zakłada podniesienie produktywności w następujących aspektach wytwarzania oprogramowania: • Implementacja, testowanie • Integrowanie, pielęgnacja • Modele są abstrakcyjne w sensie technologii: • ochrona inwestycji poczynionych podczas analizy w obliczu zmian technologicznych i wymogów współdziałania • Realizacja tradycyjnej misji OMG: • przenośność, współdziałanie, ponowne użycie.

6. 3 główne zasady MDA • Bezpośrednia reprezentacja problemu. Tworzenie oprogramowania ma się koncentrować nie wokół konkretnej technologii ale wokół problemu, który mamy do rozwiązania. • Automatyzacja. Należy użyć automatycznych narzędzi do zmechanizowania tych aspektów tworzenia oprogramowania, które nie mają wiele wspólnego z ludzką kreatywnością. • Otwarte standardy: Ponowne użycie,budowa właściwej infrastruktury rynku, wykorzystanie open source.

7. Założenia koncepcyjne MDA • Oddzielenie specyfikacji funkcjonowania systemu od szczegółów specyficznych dla danej platformy. • Podejścia ad-hoc w narzędziach CASE opartych na UML usiłowały zawrzeć w jednym kroku przejście od modelu do kodu. Jest to problematyczne: • Albo fiksujemy „jedynie słuszne” odwzorowania abstrakcji modelu na konstrukcje językowe wybranej platformy • Albo zaśmiecamy model znaczną liczbą specyficznych dla platformy adnotacji • MDA zakłada: • Wyodrębnienie modelu abstrakcyjnego - wyniku analizy • Modelu określającego sposób implementacji dla określonej platformy • Wsparcie odwzorowania pomiędzy tymi modelami jako zasadnicze źródło poprawy produktywności.

8. Poziomy abstrakcji wyodrębnione w MDA • Określane pojęciem viewpoint: • zastosowanie zasady abstrakcji celem uzyskania optymalnego dla prowadzonych działań obrazu systemu. • Wyróżniono 4 poziomy: • Computation Independent Model (CIM) • inaczej: domain model; vocabulary • model biznesowy, • nie precyzujący zakresu odpowiedzialności oprogramowania; • Platform Independent Model (PIM) • abstrakcyjna specyfikacja systemu • Platform Specific Model (PSM) • model odwzorowany na konkretne rozwiązania wybranej platformy; • Implementation Model • proste przełożenie decyzji z modelu platformowego. • Pojęcia „PI” i „PS” są względne – zależne od tego, co uznamy za platformę.

9. Transformacja PIM -> PSM • Specyfikacja platform • Specyfikacja systemu • Wybór platformy • Transformacja specyfikacji do realizacji na platformie Źródło: MDA Guide V1.0.1

10. Czego wymaga PIM? • Zakłada się niewielką liczbę (kilka) profili dla wyrażania modeli PIM przeznaczonych dla rodzajów zastosowań • systemy informacyjne, systemy czasu rzeczywistego, itd. • Poza zdefiniowaniem pojęć pożądana może okazać się stosowna dla ich użycia notacja graficzna • w tej roli UML • Niezależność od platformy: złożenie pojęć PIM w spójną abstrakcyjną ramę - „maszynę wirtualną” • Takie rozwiązanie pozwala precyzyjnie określić decyzje projektowe przy przejściu na model PSM • Stan i akcje maszyny wirtualnej mogą być w jednoznaczny sposób odwzorowane na stan i akcje konkretnego PSM • Odwzorowanie może być automatyczne • Definicja takiej abstrakcyjnej ramy jest niewątpliwie jednym z najważniejszych kandydatów do standaryzacji.

11. Pervasive Services • Objaśnienie koncepcji MDA nawiązuje do przedłużenia ewolucji języków programowania, zmierzających ku coraz wyższemu poziomowi abstrakcji. • Poziom PIM – najwyższy poziom w programowaniu • Pervasive Services zaproponowane jako zręby takiej maszyny wirtualnej: • Niezależne od platformy definicje usług, takich jak np. trwałość, transakcyjność, komunikaty, security, etc. • W znacznej części planowane jako rozwinięcie / uogólnienie zestawu Common Object Services standardu CORBA. • Pewne doświadczeniu przy abstrakcyjnym opisie możliwości oferowanych przez technologie uzyskano przy tworzeniu CWM.

12. PSM a model platformy • Nową jakość ma zagwarantować daleko posunięte wsparcie dla odwzorowania PIM => PSM. • Dążenie do zdefiniowanie na poziomie „meta” możliwie dużej liczby zagadnień związanych z tym odwzorowaniem. • Będzie to odwzorowanie abstrakcyjnych usług używanych w PIM na konkretne technologie modelu platformowego. • Model platformy przedstawiany ma być również za pomocą UML i OCL i przechowywany w repozytoriach MOF. • Niezbędne profile UML dla poszczególnych platform • specyficzne dla technologii pojęcia w postaci stereotypów oraz związanych z nimi ograniczeń i tagged values • Obecnie przykłady koncentrują się na technologiach języka Java • dzięki powstaniu profili UML w ramach Java Community Process • m.in. JSR026: UML/EJB Mapping Specification; • Microsoft nie uczestniczy w tym przedsięwzięciu.

13. Realizacja odwzorowania (transformacji) (1) • Zrealizowane na poziomie metamodeli: • opisują, jak mają być odwzorowywane pomiędzy sobą instancje (wystąpienia) tych modeli; • elementy (konstrukty) modeli PIM i PSM a także odwzorowania pomiędzy nimi są modelowane za pomocą MOF. • Krokiem w stronę wytworzenia PSM jest naniesienie specyficznych dla wybranej technologii oznaczeń (marks) [typy, stereotypy, role…] na model PIM. • Oznaczenia te mogą np. określać wybór jednego z kilku szablonów dla transformacji danego elementu modelu. • Mogą też dostarczać parametrów dla takich szablonów. • Dopuszcza się różne rodzaje oznaczeń mających różne cele, co może nam nasuwać skojarzenia z aspektami czy rolami obiektów. • Oczywiście, stosowany zestaw oznaczeń też musi zostać odpowiednio zamodelowany.

14. Realizacja odwzorowania (transformacji) (2) Marked PIM + transformation=> PSM + record of transformation Jak wyrażać transformacje (mappings)? • Język naturalny nieprecyzyjny i nieczytelny maszynowo; • „technology to be adopted”... • Przejście od PIM do PSM może obejmować więcej niż jeden krok transformacji. • Model type mapping vs. model instance mapping: • Określa, czy modele PIM oraz PSM są wystąpieniami czy specjalizacjami typów zdefiniowanych dla PI oraz PS i opisanych w transformacji. • W obu przypadkach na poziomie typów PI oraz PS mogą być zdefiniowane (i odwzorowywane między sobą) całe wzorce (patterns).

15. Rodzaje transformacji wg OMG • Ręczna: • Od tradycyjnych podejść różni się oddzieleniem PIM od PSM oraz udokumentowaniem transformacji pomiędzy nimi. • Transformacja PIM zdefiniowanego z użyciem profilu. • Oznaczenia zdefiniowane w profilu PS odnoszące się do pojęć profilu PI; • UML 2 pozwoli na definiowanie operacji w profilach – mogą one posłużyć do zdefiniowania reguł transformacji. • Transformacja używająca oznaczeń i wzorców • Transformacja automatyczna: • Specyficzne sytuacje, gdy sam PIM wystarcza do wytworzenia PSM (sam wybór platformy i PIM determinują go)

16. 1-sze podejście do MDA: „Elaborationist approach” Compuware, Interactive Objects, Softeam i inni PIM • Aplikacja jest definiowana w 3 etapach. • Wszystkie wymagają udziału człowieka • Reverse engineering czasem jest konieczny. • Język akcji nie jest potrzebny, ponieważ logika aplikacji jest specyfikowana na poziomie koduw językach zależnych od platformy OCL PSM kod 3GL uruchomienie elaboration

17. 2-gie podejście do MDA: „Translationist approach” Bridgepoint, Kennedy Carter, Telelogic i inni • Tylko etap PIM wymaga udziału człowieka. Reszta jest automatyczna. • Reverse engineering nie jest potrzebny. • Język akcjijest potrzebny aby określić logikę aplikacji na poziomie PIM w sposób niezależny od platformy PIM Język akcji PSM „translation” kod uruchomienie

18. Korzyści z podejścia 2 • Krótsze cykle wytwarzania oprogramowania • Sam PIM może zostać wykonany i testowany • Dostępność • Osoby nie programujące mogą uczestniczyć w cyklu tworzenia aplikacji • Ale istnieje niebezpieczeństwo, że język akcji stanie się tak samo trudny, jak język programowania • Ponadto, język akcji nie zajmuje się interfejsem użytkownika • Jednolite podejście • Cały proces wytwórczy odbywa się w ramach UML • Nie ma potrzeby używania UML równocześnie z językami, których semantyka była tworzona niezależnie od UML • Pełna niezależność od platformy • Zmiana platformy nie wymagapowtórnego zakodowania logiki aplikacji • Programowanie na wyższym poziomie abstrakcji • niezależnie od platformy, np. aspekty

19. Transformacje MDA – pożądane własności (1) • Możliwość „dostrojenia” transformacji, poprzez: • Pytanie projektanta o decyzje przy wykonywaniu transformacji; • Umożliwienie projektantowi uszczegółowienia kryteriów transformacji; • Wprowadzenie parametrów do definicji transformacji. Mając na względzie klarowność obu modeli, należy rozważyć możliwość przechowywania niektórych parametrów jako własności raczej samej transformacji niż któregokolwiek z modeli. • Możliwość śledzenia źródeł (identyfikacja źródła danego konstruktu modelu docelowego). • Związane z możliwościami inżynierii odwrotnej. • Szczególnie istotne jest jednak zachowanie spójności w warunkach modyfikacji modelu docelowego.

20. Transformacje MDA – pożądane własności (2) • Tzw. „spójność inkrementacyjna”: • Ponowne wygenerowanie modelu docelowego po modyfikacji modelu źródłowego nie powinno prowadzić do utraty pracy wykonanej w modelu docelowym (np. sprecyzowanie sposobu wyświetlania czy uzupełnienie ciał metod); • Bardziej jaskrawym przykładem jest zmiana modelu w warunkach istnienia wypełnionej danymi bazy. W takiej sytuacji bardziej przydatne byłyby definicje niezbędnych zmian schematu, nie zaś wygenerowany kod definicji nowych tabel. • Dwukierunkowość transformacji: • Nie zawsze wykonalne. • Wymaga analogicznych środków wyrazu w obu modelach, zaś głównym motywem rozwijania MDA jest wyższy poziom abstrakcji modelu PIM. • Model PSM wprowadza więcej szczegółów implementacyjnych

21. Transformacja jako metaobiekt • Transformacja jest wykonywanym na modelach procesem. • Powinna być jednakże reprezentowana również jako obiekt przechowujący informacje o odwzorowaniu, które logicznie doń przynależą. • Związek pomiędzy modelami wyznaczony przez transformację powinien być trwały. • Można przyjąć, że powstanie jeden obiekt opisujący (instancję) transformacji na każde zastosowanie reguły transformacji pomiędzy modelami. • Transformacje zaś powinny mieć możliwość ich parametryzowania. • W instancji transformacji znajdą się wówczas wartości przyjętych parametrów.

22. MDA - istotne specyfikacje OMG (1) • UML (Unified Modeling Language) • rozszerzalny obiektowy język modelowania z wizualną notacją • wsparty specjalizowanymi profilami może służyć tworzeniu modeli CIM, PIM, PSM. • MOF (Meta Object Facility) • pojęciowo zgodny z UML • może być traktowany jako podzbiór • służy definiowaniu innych metamodeli oraz konstrukcji ustandaryzowanych repozytoriów metadanych, pozwalających przechowywać ich wystąpienia. • XMI (XML Metadata Interchange) • oparty na MOF standard XML-owego zapisu modeli (UML lub innych zdefiniowanych w terminach MOF).

23. MDA - istotne specyfikacje OMG (2) • CWM (Common Warehouse Metamodel) • definiuje abstrakcyjne własności z obszaru hurtowni danych. • Software Process Engineering Metamodel • pozwala definiować w jednolitej postaci metodyki wytwarzania oprogramowania. • Pervasive Services: • abstrakcyjne usługi używane w definicjach modeli PIM (zdarzenia, usługi katalogowe, security, transakcje…). • Rozwijane obecnie poprzez inżynierię odwrotną popularniejszych usług CORBA. • EDOC (Enterprise Distributed Object Computing), EAI (Enterprise Application Integration) • profile UML stosowane do tworzenia PIM.

24. UML 2.0 • Uporządkowanie i ujednolicenie wewnętrznej organizacji pojęć: • Ujednolicenie metamodelu z rozwiązaniami MOF. • Końce asocjacji traktowane jednolicie z atrybutami – toteż m.in. można modelować statyczne asocjacje (bodajże występuje tam jawnie pojęcie static, w miejce pierwotnie stosowanego owner’s scope). • Podobnie poprawiona sprawa parametrów metod – mogą teraz one określać liczności podobnie jak atrybuty i asocjacje. • Aktywności (diagramy aktywności) nie są już specjalizacjami (szczególnym rodzajem) stanów z diagramów stanów. • OCL będzie również opisany metamodelem.

25. UML 2.0 – własności użytkowe • Liczność domyślna w UML = * • Kolejna nowość – o ile dana rola nie jest oznaczona jako isUnique=true, to dopuszczalne są powtórzenia! • Ciekawe właściwości asocjacji (a właściwie ich ról) – dotyczą wszystkich „Property”: • subsets nazwaInnejRoli, union -> isDerivedUnion : Boolean • rozróżniono „non-navigable” i „unspecified navigability”; • Collaboration diagram => communication diagram? • Poza diagramami sekwencji diagramy interakcji obejmują ponadto interaction overview diagrams • obrazują przepływ sterowania w oparciu o diagram aktywności; • każdy węzeł może być diagramem interakcji.

26. UML 2.0 a MOF 2.0 • UML zdefiniowany w MOF. • Wspólny pakiet Core – stanowi zarówno: • fundament dla poszczególnych metamodeli; • zestaw pojęć służących definiowaniu metamodeli (meta-metamodel).

27. Meta-modelowanie • Niezbędny jest mechanizm definiowania • inny niż gramatyka BNF, która jest odpowiednia dla notacji tekstowej. • Ważnym zadaniem jest zdefiniowanie języka transformacji, służącego do odwzorowywania wystąpień metamodeli. Wymaga on: • Wskazania modeli źródłowego i docelowego; • Deklaracji wykorzystywanych przez transformację elementów modeli źródłowego i docelowego; • Deklaracji warunków wstępnych i końcowych przekształcenia; • Deklaracji przekształceń: mogą przybrać postać prostego skojarzenia elementu źródłowego z docelowym plus ograniczeń nałożonych na model docelowy; • Zarówno dla formułowania warunków jak i dla odwzorowań przydają się operatory makroskopowe • autorzy [MDA Explained] przyjęli jako robocze rozwiązanie OCL; • możliwość definiowania transformacji przez wskazanie innych (np. w postaci sekwencji);

28. UML – mocne i słabe strony • UML jako narzędzie budowy PIM: • silna strona = model klas; • słaba strona = behavior (środki zróżnicowane, ekspresyjne, ale słabiej sformalizowanie). • Executable UML = UML + AS (Action Semantics): maszyny stanów i procedury pisane w AS dla każdego ze stanów. Problemy: • dla wielu dziedzin model maszyn stanów może okazać się niewygodny (stosowany głównie dla embedded); • AS jest niskopoziomowe (poziom abstrakcji jak w PSM -> mały zysk z przeniesienia definicji do PIM; „UML-owy asembler”); • notacja AS nie jest ustandaryzowana. • OCL: • Może wspierać definicję dynamiki systemu i podnosić precyzję modelu; • Nie pozwala na wygenerowanie pełnych ciał metod. • Niezbędne jest ustandaryzowanie języka transformacji • Rozpisano RFP na język QVT (Query, View, Transformation).

29. Microsoft...? • Microsoft odrzuca nie tylko MDA, ale i znaczną część celów UML • Jest jedyną wielką organizacją, która nie uczestniczy w OMG • Lansuje dziedzinowe języki modelowania zamiast UML • Dla Microsoftu UML jest za trudny i nie do końca pasuje do jego narzędzi • UML „as a sketch” – popiera • UML „as a blueprint” (podejście 1 do MDA) – krytykuje, np. nie można bezpośrednio używać klasy UML jako klasy C# • UML „as a programming language” (podejście 2 do MDA) - nie jest zainteresowany, rozwija własne języki • Być może Microsoft tworzy jakieś własne wersje UML i MDA ?

30. Podsumowanie • Języki modelowania – w miarę precyzyjna definicja dzięki MOF. • Z kolei brak ustandaryzowanej postaci definiowania transformacji czyni realizacje założeń MDA zależnymi od poszczególnych dostawców. • Otwarte kwestie: • Czy można wprowadzić dostatecznie precyzyjny język dla definiowania zachowania systemu, który zarazem będzie oferował istotnie wyższy poziom abstrakcji niż postać docelowa w kodzie programu? • Co z programowaniem aspektowym i jego ewentualnym wsparciem? • Odwzorowania z modelu klas na warstwy danych oraz aplikacyjną są stosunkowo jednoznaczne, natomiast wygenerowanie z nich warstwy prezentacji może być wątpliwe…

31. MDA a nasze prace • MOF dostarcza dość intuicyjnych środków definiowania metamodeli. • Tworzone u nas definicje metamodelu dla ODRA można uznać za zgodne z meta-metamodelem MOF. • Propozycja specyfikacji QVT (Query View Transformation), jak również przydatność w definiowaniu odwzorowań istniejącego już OCL, zgodnie przemawiają za użytecznością obiektowego języka zapytań jako środka do manipulacji metadanymi. • Wobec tego, realizując narzędzie z obszaru technologii CASE możnaby rozpatrywać ODRA jako repozytorium modeli/metamodeli używanych w MDA.