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

Bezpośrednia reprezentacja problemu Manifest MDA MDA Otwarte standardy Bezpośrednia reprezentacja problemu Automatyzacja Czyli to co przyświeca firmie OMG (koncentrowanie się wokół problemu, nie technologii, to co nie jest kreatywne - automatyzacja, wykorzystanie open-source, ponowne użycie)

Oddzielenie tego co trwałe od tego co zmienne Zmieniają się technologie, architektury, platformy, SO, stała – dziedzina problemu 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) Różne poziomy 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 PSI proste przełożenie decyzji z modelu platformowego 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 Dążymy do uruchamialnego UML’a

Uszczegółowienie modelu 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 -> PSM 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 PSI OCL 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 Sam PIM może być wykonywalny i testowany (krótki cykl wytwarzania oprogramowania), jeśli nieskomplikowany język akcji – osoby nieprogramujące mogą uczestniczyć w całym cyklu tworzenia (w ramach UML)

Dziękujemy za uwagę