Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Grupa: I9H1S4 Podgrupa: pierwsza Wykonali: Piotr Litwiniuk, Bartosz Wołowicz, Aleksander Wiśniewski, Piotr Kwiatek, Mariusz Kluska, Magdalena Bęczkowska,

Podobne prezentacje


Prezentacja na temat: "Grupa: I9H1S4 Podgrupa: pierwsza Wykonali: Piotr Litwiniuk, Bartosz Wołowicz, Aleksander Wiśniewski, Piotr Kwiatek, Mariusz Kluska, Magdalena Bęczkowska,"— Zapis prezentacji:

1 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 MDA – Model Driven Architecture

2 Manifest MDA MDA Otwarte standardy Bezpośrednia reprezentacja problemu Automatyzacja

3 Kluczowa koncepcja: Oddzielenie tego co trwałe od tego co zmienne

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

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

6 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

7 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

8 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

9 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

10 CIMPIMPSMPSI 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)

11 Transformacja PIM -> PSM 1.Specyfikacja platform 2.Specyfikacja systemu 3.Wybór platformy 4.Transformacja specyfikacji do realizacji na platformie Marks (oznaczenia) = typy, stereotypy, role, ograniczenia itp. i wzorce projektowe

12 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) PIMPSMPSI OCL3GL uruchomienie

13 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 PIMPSMPSI Język akcji uruchomienie

14 Dziękujemy za uwagę


Pobierz ppt "Grupa: I9H1S4 Podgrupa: pierwsza Wykonali: Piotr Litwiniuk, Bartosz Wołowicz, Aleksander Wiśniewski, Piotr Kwiatek, Mariusz Kluska, Magdalena Bęczkowska,"

Podobne prezentacje


Reklamy Google