Grupa: I9H1S4Podgrupa: pierwsza

Wykonali: Piotr Litwiniuk, Bartosz Wołowicz, Aleksander Wiśniewski, Piotr Kwiatek, Mariusz Kluska, Magdalena Bęczkowska, Łukasz Skibniewski, Paweł Głębocki

MDA – Model Driven

Architecture

Manifest MDA

MDA

Otwarte standardy

Bezpośrednia reprezentacja

problemu

Automatyzacja

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

Model specyficzny dla platformy – Platform Specific Model

(PSM)

Model niezależny od platformy – Platform Independent Model (PIM)

Model niezależny od obliczeń – Computation Independent Model

(CIM)

więcej abstrakcji

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

Realizacja modelu

Uszczegółowienie modelu

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 -> PSM1. Specyfikacja platform2. Specyfikacja systemu3. Wybór platformy4. Transformacja specyfikacji

do realizacji na platformie

Marks (oznaczenia) = typy, stereotypy, role, ograniczenia itp. i wzorce projektowe

Podejście przez opracowanie („ręczne”) -„Elaborationist approach”

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

PIM PSM PSIOCL 3GL uruchomienie

Podejście przez transformacje („auto”) -„Translationist approach”

• 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

PIM PSM PSI

Język akcjiuruchomienie

Dziękujemy za uwagę