Transcript MDA
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ę