Standardy w zakresie systemów rozproszonych i baz danych

P.Habela, K.Subieta. SSR, Wykład 7, Folia 1 kwiecień 2009

Standardy w zakresie systemów rozproszonych i baz danych

Piotr HabelaKazimierz Subieta

Polsko-Japońska Wyższa SzkołaTechnik Komputerowych, Warszawa

Wykład 7:Model Driven Architecture (MDA)


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


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


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


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.


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.


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.


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ę.


Transformacja PIM -> PSM

Źródło: MDA Guide V1.0.1

1. Specyfikacja platform2. Specyfikacja systemu3. Wybór platformy4. Transformacja specyfikacji

do realizacji na platformie


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.


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.


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.


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.


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).


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)


1-sze podejście do MDA: „Elaborationist approach”

• 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

PIM

PSM

kodelaboration

Compuware, Interactive Objects, Softeam i inni

uruchomienie

OCL

3GL


2-gie podejście do MDA: „Translationist approach”

• 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

PIM

PSM

kod

„translation”

uruchomienie

Język akcji

Bridgepoint, Kennedy Carter, Telelogic i inni


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


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.


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.

4. 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


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.


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).


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.


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.


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.


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).


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);


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).


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 ?


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…


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.

Standardy w zakresie systemów rozproszonych i baz danych

Documents

Transcript of Standardy w zakresie systemów rozproszonych i baz danych