Transcript Document

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
P.Habela, K.Subieta. SSR, Wykład 7, Folia 1
kwiecień 2009
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
P.Habela, K.Subieta. SSR, Wykład 7, Folia 2
kwiecień 2009
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
P.Habela, K.Subieta. SSR, Wykład 7, Folia 3
kwiecień 2009
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
P.Habela, K.Subieta. SSR, Wykład 7, Folia 4
kwiecień 2009
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.
P.Habela, K.Subieta. SSR, Wykład 7, Folia 5
kwiecień 2009
3 główne zasady MDA
1. Bezpośrednia reprezentacja problemu. Tworzenie
oprogramowania ma się koncentrować nie wokół
konkretnej technologii ale wokół problemu, który
mamy do rozwiązania.
2. 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ą.
3. Otwarte standardy: Ponowne użycie, budowa
właściwej infrastruktury rynku, wykorzystanie open
source.
P.Habela, K.Subieta. SSR, Wykład 7, Folia 6
kwiecień 2009
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.
P.Habela, K.Subieta. SSR, Wykład 7, Folia 7
kwiecień 2009
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ę.
P.Habela, K.Subieta. SSR, Wykład 7, Folia 8
kwiecień 2009
Transformacja PIM -> PSM
1.
2.
3.
4.
Specyfikacja platform
Specyfikacja systemu
Wybór platformy
Transformacja specyfikacji
do realizacji na platformie
Źródło: MDA Guide V1.0.1
P.Habela, K.Subieta. SSR, Wykład 7, Folia 9
kwiecień 2009
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.
P.Habela, K.Subieta. SSR, Wykład 7, Folia 10
kwiecień 2009
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.
P.Habela, K.Subieta. SSR, Wykład 7, Folia 11
kwiecień 2009
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.
P.Habela, K.Subieta. SSR, Wykład 7, Folia 12
kwiecień 2009
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.
P.Habela, K.Subieta. SSR, Wykład 7, Folia 13
kwiecień 2009
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).
P.Habela, K.Subieta. SSR, Wykład 7, Folia 14
kwiecień 2009
Rodzaje transformacji wg OMG
1. Ręczna:
• Od tradycyjnych podejść różni się oddzieleniem PIM od PSM oraz
udokumentowaniem transformacji pomiędzy nimi.
2. 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.
3. Transformacja używająca oznaczeń i wzorców
4. Transformacja automatyczna:
• Specyficzne sytuacje, gdy sam PIM wystarcza do wytworzenia
PSM (sam wybór platformy i PIM determinują go)
P.Habela, K.Subieta. SSR, Wykład 7, Folia 15
kwiecień 2009
1-sze podejście do MDA: „Elaborationist approach”
Compuware, Interactive Objects, Softeam i inni
PIM
OCL
PSM
• 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 kodu w językach zależnych od
platformy
kod
3GL
uruchomienie
P.Habela, K.Subieta. SSR, Wykład 7, Folia 16
elaboration
kwiecień 2009
2-gie podejście do MDA: „Translationist approach”
Bridgepoint, Kennedy Carter, Telelogic i inni
PIM
Język akcji
„translation”
PSM
kod
• Tylko etap PIM wymaga
udziału człowieka. Reszta
jest automatyczna.
• Reverse engineering nie jest
potrzebny.
• Język akcji jest potrzebny
aby określić logikę aplikacji
na poziomie PIM w sposób
niezależny od platformy
uruchomienie
P.Habela, K.Subieta. SSR, Wykład 7, Folia 17
kwiecień 2009
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 wymaga powtórnego zakodowania logiki
aplikacji
• Programowanie na wyższym poziomie abstrakcji
– niezależnie od platformy, np. aspekty
P.Habela, K.Subieta. SSR, Wykład 7, Folia 18
kwiecień 2009
Transformacje MDA – pożądane własności
(1)
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.
2. 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.
P.Habela, K.Subieta. SSR, Wykład 7, Folia 19
kwiecień 2009
Transformacje MDA – pożądane własności
(2)
3. 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:
4.
•
•
•
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
P.Habela, K.Subieta. SSR, Wykład 7, Folia 20
kwiecień 2009
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.
P.Habela, K.Subieta. SSR, Wykład 7, Folia 21
kwiecień 2009
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).
P.Habela, K.Subieta. SSR, Wykład 7, Folia 22
kwiecień 2009
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.
P.Habela, K.Subieta. SSR, Wykład 7, Folia 23
kwiecień 2009
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.
P.Habela, K.Subieta. SSR, Wykład 7, Folia 24
kwiecień 2009
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.
P.Habela, K.Subieta. SSR, Wykład 7, Folia 25
kwiecień 2009
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 (metametamodel).
P.Habela, K.Subieta. SSR, Wykład 7, Folia 26
kwiecień 2009
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);
P.Habela, K.Subieta. SSR, Wykład 7, Folia 27
kwiecień 2009
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).
P.Habela, K.Subieta. SSR, Wykład 7, Folia 28
kwiecień 2009
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 ?
P.Habela, K.Subieta. SSR, Wykład 7, Folia 29
kwiecień 2009
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…
P.Habela, K.Subieta. SSR, Wykład 7, Folia 30
kwiecień 2009
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.
P.Habela, K.Subieta. SSR, Wykład 7, Folia 31
kwiecień 2009