Standardy w zakresie systemów rozproszonych
This presentation is the property of its rightful owner.
Sponsored Links
1 / 31

Standardy w zakresie systemów rozproszonych i baz danych PowerPoint PPT Presentation


  • 99 Views
  • Uploaded on
  • Presentation posted in: General

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. Plan prezentacji. Modelowanie – rola w dzisiejszych metodykach

Download Presentation

Standardy w zakresie systemów rozproszonych i baz danych

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Standardy w zakresie system w rozproszonych i baz danych

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


Plan prezentacji

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

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

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

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

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.


Za o enia koncepcyjne mda

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

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

Transformacja PIM -> PSM

  • Specyfikacja platform

  • Specyfikacja systemu

  • Wybór platformy

  • Transformacja specyfikacji do realizacji na platformie

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


Czego wymaga pim

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

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

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

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

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

    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)


    1 sze podej cie do mda elaborationist approach

    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


    2 gie podej cie do mda translationist approach

    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


    Korzy ci z podej cia 2

    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


    Transformacje mda po dane w asno ci 1

    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.


    Transformacje mda po dane w asno ci 2

    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


    Transformacja jako metaobiekt

    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

    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

    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

    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

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

    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 – 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...?

    • 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

    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

    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.


  • Login