MDA

Report
MDA – Model
Driven Architecture
Grupa: I9H1S4
Podgrupa: pierwsza
Wykonali: Piotr Litwiniuk, Bartosz Wołowicz, Aleksander Wiśniewski,
Piotr Kwiatek, Mariusz Kluska, Magdalena Bęczkowska, Łukasz Skibniewski, Paweł Głębocki
Manifest MDA
Bezpośrednia
reprezentacja
problemu
Automatyzacja
Otwarte
standardy
MDA
Kluczowa koncepcja:
Oddzielenie tego co trwałe od tego co zmienne
Wykorzystywane standardy
• UML (Unified Modeling Language) jako rozszerzalny obiektowy
język modelowania z wizualną notacją: wsparty specjalizowanymi
profilami może służyć tworzeniu modeli CIM, PIM, PSM. + jego
rozszerzenia dziedzinowe (SysML, DoDAF, SoaML)
• 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.
• CWM (Common Warehouse Metamodel) – definiuje abstrakcyjne
własności z obszaru hurtowni danych.
• XMI (XML Metadata Interchange) – oparty na MOF standard
XML-owego zapisu modeli (UML lub innych zdefiniowanych w
terminach MOF), nie diagramów, celem ich wymiany między
narzędziami.
Punkty widzenia systemu
więcej
abstrakcji
Model niezależny od obliczeń –
Computation Independent Model
(CIM)
Model niezależny od platformy –
Platform Independent Model
(PIM)
Model specyficzny dla platformy –
Platform Specific Model
(PSM)
więcej
specyfikacji
Modele muszą wspierać wspólną semantykę
CIM
• Odnosi się do dziedziny problemu lub modelu
biznesowego
• Prezentuje system na najwyższym poziomie abstrakcji
• Jego celem jest zdefiniowanie problemów do rozwiązania
z pominięciem sposobów ich implementacji
• Nie precyzuje zakresu odpowiedzialności oprogramowania
• Używamy jedynie słownictwa z dziedziny problemu, do
reprezentacji pojęć biznesowych, które są niezależne od
oprogramowania systemu
• W modelu nie znajdujemy żadnych informacji związanych
z komputerowym wspomaganiem dla rozwiązywanych
problemów
PIM
• Abstrakcyjna specyfikacja systemu
• Używany przez architektów i projektantów do opisu
oprogramowania dla systemu na wysokim poziomie,
niezależnego od docelowej platformy
implementacyjnej
• Opis ten pozwoli na jego przekształcenie na wiele
różnych platform implementacyjnych, wskazując: SO,
CPU, j. programowania czy biblioteki
• Mniej abstrakcyjny niż CIM (stanowi jego
uszczegółowienie)
• Bliższy implementacji, jednak bezpośrednio jej nie
określa
PSM
• Model odwzorowany na konkretne rozwiązania
wybranej platformy
• Specyfikuje rozpoznane w modelu PIM szczegóły
konstrukcyjne i technologiczne, określając, jak będą
one implementowane w docelowej platformie
rozwiązania
• Wykorzystuje technologie projektowe, infrastrukturę i
wzorce projektowe
PSI
• proste przełożenie decyzji z modelu
platformowego
Transformacje
• Sam UML to za mało, potrzebne definicje
przekształceń (zbiór reguł, określających, na jakie
elementy oferowane przez daną platformę
informatyczną przekształcić elementy z PIM)
• Dla systemów czasu rzeczywistego, językiem
opisu akcji (semantyk akcji) - SDL
CIM
PIM
Realizacja
modelu
PSM
Uszczegółowienie
modelu
PSI
Generacja
kodu
• CIM – powiązane z przypadkami użycia wymagania i
szczegółowe diagramy sekwencji, aktywności i stanów
• PIM – formalna specyfikacja (w UML) struktury i funkcji
systemu, która abstrahuje od szczegółów technologicznych
• PSM – dodanie szczegółów technologicznych (np. middleware,
SO, sieć, CPU)
• PSI – źródła i skompilowane kody wyprodukowane z modeli,
przeznaczone dla wybranej platformy docelowej („target
platfrom”)
Transformacja PIM -> PSM
1.
2.
3.
4.
Specyfikacja platform
Specyfikacja systemu
Wybór platformy
Transformacja specyfikacji
do realizacji na platformie
Marks (oznaczenia) = typy, stereotypy, role,
ograniczenia itp. i wzorce projektowe
Podejście przez opracowanie („ręczne”) „Elaborationist approach”
PIM
PSM
OCL
PSI
3GL
uruchomienie
• Wszystkie etapy wymagają udziału człowieka
• Reverse engineering czasem jest konieczny
(utrata zgodności)
• Język akcji nie jest używany, logika aplikacji
specyfikowana na poziomie kodu w językach
programowania (zależnych od platformy)
Podejście przez transformacje („auto”) „Translationist approach”
PIM
PSM
PSI
uruchomienie
Język akcji
•
•
•
•
To co nie jest kreatywne - automat
Tylko etap PIM wymaga udziału człowieka
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
Dziękujemy za uwagę

similar documents