Architektura oparta na modelach

Model Driven Architecture ( MDA ) to podejście do projektowania oprogramowania służące do tworzenia systemów oprogramowania. Zawiera zestaw wytycznych dotyczących strukturyzacji specyfikacji, które są wyrażone jako modele . Model Driven Architecture jest rodzajem inżynierii domeny i obsługuje systemów oprogramowania opartą na modelach . Został uruchomiony przez Object Management Group (OMG) w 2001 roku.

Przegląd

Model Driven Architecture® (MDA®) „zapewnia podejście do czerpania wartości z modeli i architektury w celu wsparcia pełnego cyklu życia systemów fizycznych, organizacyjnych i informatycznych”. Model jest (reprezentacją) abstrakcji systemu. MDA® zapewnia wartość, tworząc modele na różnych poziomach abstrakcji, od widoku koncepcyjnego po najdrobniejsze szczegóły implementacji. Literatura OMG mówi o trzech takich poziomach abstrakcji lub architektonicznych punktach widzenia: model niezależny od obliczeń (CIM), model niezależny od platformy (PIM) i model specyficzny dla platformy (PSM). CIM opisuje system koncepcyjnie, PIM opisuje obliczeniowe aspekty systemu bez odniesienia do technologii, które mogą być użyte do jego wdrożenia, a PSM zawiera szczegóły techniczne niezbędne do wdrożenia systemu. Przewodnik OMG zauważa jednak, że te trzy architektoniczne punkty widzenia są przydatne, ale to tylko trzy z wielu możliwych punktów widzenia.

Organizacja OMG dostarcza specyfikacje, a nie implementacje, często jako odpowiedzi na zapytania ofertowe (RFP). Implementacje pochodzą od prywatnych firm lub grup open source.

Powiązane normy

Model MDA jest powiązany z wieloma standardami, w tym Unified Modeling Language (UML), Meta-Object Facility (MOF), XML Metadata Interchange (XMI), Enterprise Distributed Object Computing (EDOC), Software Process Engineering Metamodel (SPEM) oraz wspólny metamodel magazynu (CWM). Należy zauważyć, że termin „architektura” w Model Driven Architecture nie odnosi się do architektury modelowanego systemu, ale raczej do architektury różnych standardów i form modeli, które służą jako podstawa technologiczna dla MDA. ^{[ potrzebne źródło ]}

Wykonywalny UML był profilem UML używanym podczas narodzin MDA. Teraz zamiast tego OMG promuje fUML . (Językiem akcji dla fUML jest ALF.)

Znak towarowy

The Object Management Group posiada zarejestrowane znaki towarowe dla terminu Model Driven Architecture i jego akronimu MDA, a także znaki towarowe dla terminów takich jak: Model Based Application Development, Model Driven Application Development, Model Based Application Development, Model Based Programming, Model Driven Systems, i inni.

Tematy dotyczące architektury opartej na modelach

podejście MDA

OMG koncentruje się na architekturze Model Driven Architecture® na inżynierii przyszłości, tj. tworzeniu kodu z abstrakcyjnych, opracowanych przez człowieka diagramów modelowania (np. diagramów klas) ^{[ potrzebne źródło ]} . Grupa OMG ADTF (Analysis and Design Task Force) kieruje tymi wysiłkami. Z odrobiną humoru grupa wybrała ADM (MDA wstecz), aby nazwać badanie inżynierii odwrotnej. ADM dekoduje modernizację opartą na architekturze. Celem ADM jest tworzenie standardów dla opartej na modelach inżynierii wstecznej starszych systemów. Metamodel odkrywania wiedzy (KDM) jest najdalszy z tych wysiłków i opisuje systemy informacyjne w kategoriach różnych zasobów (programy, specyfikacje, dane, pliki testowe, schematy baz danych itp.).

Ponieważ koncepcje i technologie wykorzystywane do realizacji projektów oraz koncepcje i technologie wykorzystywane do realizacji architektur zmieniały się we własnym tempie, oddzielenie ich umożliwia twórcom systemów wybór najlepszego i najlepiej dopasowanego w obu domenach. Projekt odnosi się do wymagań funkcjonalnych ( przypadek użycia ), podczas gdy architektura zapewnia infrastrukturę, za pomocą której realizowane są wymagania niefunkcjonalne, takie jak skalowalność, niezawodność i wydajność. MDA przewiduje, że model niezależny od platformy (PIM), który reprezentuje projekt koncepcyjny realizujący wymagania funkcjonalne, przetrwa zmiany technologii realizacji i architektury oprogramowania .

Szczególne znaczenie dla Model Driven Architecture ma pojęcie transformacji modelu . Specyficzny standardowy język transformacji modelu został zdefiniowany przez OMG pod nazwą QVT .

narzędzia MDA

Organizacja OMG dostarcza raczej przybliżone specyfikacje niż implementacje, często jako odpowiedzi na zapytania ofertowe (RFP). OMG dokumentuje cały proces w dokumencie zwanym Przewodnikiem MDA.

Zasadniczo narzędzie MDA to narzędzie służące do opracowywania, interpretowania, porównywania, wyrównywania, mierzenia, weryfikowania, przekształcania itp. modeli lub metamodeli. W dalszej części „model” jest rozumiany jako dowolny model (np. model UML) lub metamodel (np. metamodel CWM). W każdym podejściu MDA mamy zasadniczo dwa rodzaje modeli: modele początkowe są tworzone ręcznie przez agentów ludzkich, podczas gdy modele pochodne są tworzone automatycznie przez programy. Na przykład analityk może stworzyć początkowy model UML na podstawie obserwacji luźnej sytuacji biznesowej, podczas gdy model Java może zostać automatycznie wyprowadzony z tego modelu UML przez transformacji modelu .

Narzędzie MDA może być narzędziem służącym do sprawdzania modeli pod kątem kompletności, niespójności lub warunków błędów i ostrzeżeń.

Niektóre narzędzia wykonują więcej niż jedną z wymienionych powyżej funkcji. Na przykład niektóre narzędzia do tworzenia mogą mieć również możliwości przekształcania i testowania. Istnieją inne narzędzia, które służą wyłącznie do tworzenia, wyłącznie do prezentacji graficznej, wyłącznie do transformacji itp.

Implementacje specyfikacji OMG pochodzą od prywatnych firm lub grup open source . Jednym z ważnych źródeł implementacji specyfikacji OMG jest Fundacja Eclipse (EF). Wiele implementacji standardów modelowania OMG można znaleźć w Eclipse Modeling Framework (EMF) lub Graphical Modeling Framework (GMF), fundacja Eclipse rozwija również inne narzędzia o różnych profilach, takie jak GMT. Zgodność Eclipse ze specyfikacjami OMG często nie jest ścisła. Dotyczy to na przykład standardu EMOF firmy OMG, który EMF przybliża za pomocą implementacji Ecore. Więcej przykładów można znaleźć w projekcie M2M implementującym standard QVT lub w projekcie M2T implementującym standard MOF2Text.

Należy uważać, aby nie pomylić Listy narzędzi MDA i Listy narzędzi UML , ponieważ ta pierwsza jest znacznie szersza. To rozróżnienie można uczynić bardziej ogólnym, rozróżniając „narzędzia zmiennego metamodelu” i „narzędzia stałego metamodelu”. Narzędzie UML CASE jest zwykle „narzędziem stałego metamodelu”, ponieważ zostało zaprogramowane do pracy tylko z określoną wersją metamodelu UML (np. UML 2.1). Wręcz przeciwnie, inne narzędzia mają wewnętrzne ogólne możliwości pozwalające im dostosować się do dowolnych metamodeli lub określonego rodzaju metamodeli.

Zwykle narzędzia MDA skupiają się na podstawowej specyfikacji architektury, chociaż w niektórych przypadkach narzędzia te są niezależne od architektury (lub niezależne od platformy).

Proste przykłady specyfikacji architektury obejmują:

Wybór jednej z wielu obsługiwanych architektur referencyjnych, takich jak Java EE lub Microsoft .NET ,
Określenie architektury na bardziej szczegółowym poziomie, w tym wybór technologii warstwy prezentacji, technologii warstwy logiki biznesowej, technologii trwałości i technologii mapowania trwałości (np. mapper obiektowo-relacyjny).
Metadane: informacje o danych.

obawy MDA

Niektóre kluczowe koncepcje leżące u podstaw podejścia MDA (rozpoczętego w 2001 r.) zostały po raz pierwszy wyjaśnione metodą Shlaera-Mellora pod koniec lat 80. Istotnie, kluczowy nieobecny standard techniczny podejścia MDA (składnia języka akcji dla wykonywalnego UML ) został zastąpiony przez niektórych dostawców poprzez adaptację oryginalnego języka Shlaer-Mellor Action Language (zmodyfikowanego dla UML) ^{[ potrzebne źródło ]} . Jednak w tym okresie podejście MDA nie zyskało akceptacji głównego nurtu przemysłu; z Grupą Gartnera nadal identyfikuje MDA jako technologię „rosnącą” w swoim „ Cyklu szumu ” z 2006 r., a firma Forrester Research ogłosiła MDA jako „DOA” w 2006 r. Potencjalne obawy, które zostały podniesione w związku z podejściem OMG MDA, obejmują:

Niekompletne standardy: Podejście MDA opiera się na różnych standardach technicznych, z których niektóre nie zostały jeszcze określone ( np . PIM z wirtualnym środowiskiem wykonawczym).
Uzależnienie od dostawcy: chociaż MDA zostało pomyślane jako podejście do osiągnięcia (technicznej) niezależności platformy, obecni dostawcy MDA niechętnie konstruują swoje zestawy narzędzi MDA tak, aby były interoperacyjne. Taki wynik może doprowadzić do uzależnienia od dostawcy dla tych, którzy stosują podejście MDA. ^{[ potrzebne źródło ]}
Idealistyczne: MDA jest pomyślane jako podejście do inżynierii przyszłości, w którym modele zawierające programowanie w języku akcji są przekształcane w artefakty implementacyjne (np. kod wykonywalny, schemat bazy danych) w jednym kierunku poprzez całkowicie lub częściowo zautomatyzowany etap „generowania”. Jest to zgodne z wizją OMG, zgodnie z którą MDA powinno umożliwiać modelowanie pełnej złożoności domeny problemowej w UML (i powiązanych standardach) z późniejszym przekształceniem w kompletną (wykonywalną) aplikację. Takie podejście oznacza jednak, że zmiany w artefaktach implementacji (np. strojenie schematu bazy danych) nie są obsługiwane. Stanowi to problem w sytuacjach, w których takie potransformacyjne „adaptowanie” artefaktów implementacyjnych jest postrzegane jako konieczne. Dowodem na to, że pełne podejście MDA może być zbyt idealistyczne w przypadku niektórych wdrożeń w świecie rzeczywistym, było pojawienie się tak zwanego „pragmatycznego MDA”. Pragmatic MDA łączy dosłowne standardy MDA firmy OMG z bardziej tradycyjnymi mechanizmami opartymi na modelach, takimi jak inżynieria w obie strony , która zapewnia wsparcie dla adaptacji artefaktów implementacji.
Specjalistyczne zestawy umiejętności: Praktycy inżynierii oprogramowania opartej na MDA muszą (podobnie jak w przypadku innych zestawów narzędzi) posiadać wysoki poziom wiedzy specjalistycznej w swojej dziedzinie. Obecni praktycy-eksperci MDA (często nazywani modelarzami/architektami) są rzadkością w porównaniu z dostępnością tradycyjnych programistów.
Rekord osiągnięć OMG: Konsorcjum OMG, które sponsoruje podejście MDA (i jest właścicielem znaku towarowego MDA), również wprowadziło i sponsorowało standard CORBA, który sam nie zmaterializował się jako szeroko stosowany standard.
Niepewna propozycja wartości (UVP): Jak już wspomniano, wizja MDA pozwala na określenie systemu jako abstrakcyjnego modelu, który może być zrealizowany jako konkretna implementacja (program) dla określonej platformy obliczeniowej (np. .NET). W związku z tym aplikacja, która została pomyślnie opracowana przy użyciu czystego podejścia MDA, mogłaby teoretycznie zostać przeniesiona na nowszą wersję platformy .NET (lub nawet platformę Java) w sposób deterministyczny – chociaż pozostają istotne pytania dotyczące praktycznych aspektów tłumaczenia (takich jak np. jako implementacja interfejsu użytkownika). To, czy ta zdolność stanowi znaczącą propozycję wartości, pozostaje kwestią dla poszczególnych użytkowników. Niezależnie od tego, użytkownicy MDA, którzy szukają wartości poprzez „alternatywę dla programowania”, powinni być bardzo ostrożni przy ocenie tego podejścia. Złożoność dowolnej dziedziny problemu zawsze pozostanie, a programowanie logiki biznesowej musi być podejmowane w MDA, tak jak w przypadku każdego innego podejścia. Różnica w stosunku do MDA polega na tym, że używany język programowania (np. xtUML) jest bardziej abstrakcyjny (niż, powiedzmy, Java czy C#) i jest przeplatany tradycyjnymi artefaktami UML (np. diagramami klas). Niezależnie od tego, czy programowanie w języku, który jest bardziej abstrakcyjny niż główny nurt 3GL zaowocują systemami o lepszej jakości, tańszych kosztach lub szybszych dostawach, to pytanie, na które nie ma jeszcze właściwej odpowiedzi.
MDA uznano za możliwy sposób na połączenie różnych, niezależnie opracowanych standardowych rozwiązań. Społeczności zajmującej się symulacjami zalecano go jako biznesową i branżową alternatywę dla kolejnego standardu wymaganego przez Departament Obrony Stanów Zjednoczonych.

Kontrowersje związane z generowaniem kodu

Generowanie kodu oznacza, że użytkownik abstrakcyjnie modeluje rozwiązania, które są konotowane przez niektóre dane modelu, a następnie zautomatyzowane narzędzie wyprowadza z części modeli lub całego kodu źródłowego systemu oprogramowania. W niektórych narzędziach użytkownik może dostarczyć szkielet kodu źródłowego programu w postaci szablonu kodu źródłowego, w którym predefiniowane tokeny są następnie zastępowane częściami kodu źródłowego programu podczas procesu generowania kodu.

Często cytowana krytyka dotyczy tego, że diagramom UML po prostu brakuje szczegółów, które są potrzebne, aby zawierały te same informacje, które są zawarte w źródle programu. Niektórzy programiści twierdzą nawet, że „kod jest projektem”.

Zobacz też

Dalsza lektura

Kevin Lano. „Tworzenie oprogramowania oparte na modelach z UML i Javą”. Nauka CENGAGE, ISBN 978-1-84480-952-3
Davida S. Frankela . Architektura oparta na modelach: zastosowanie MDA do przetwarzania w przedsiębiorstwie . John Wiley & Sons, ISBN 0-471-31920-1
Meghan Kiffer The MDA Journal: Architektura oparta na modelu prosto od mistrzów . ISBN 0-929652-25-8
Anneke Kleppe (2003). Wyjaśnienie MDA, architektura oparta na modelu: praktyka i obietnica . Addison-Wesley. ISBN 0-321-19442-X
Stephen J. Mellor (2004). Destylowane MDA, zasady architektury opartej na modelach . Addison-Wesley Professional. ISBN 0-201-78891-8
Chrisa Raistricka. Architektura oparta na modelu z wykonywalnym UML . Cambridge University Press, ISBN 0-521-53771-1
Marco Brambilla, Jordi Cabot, Manuel Wimmer, Model Driven Software Engineering in Practice , przedmowa Richarda Soleya ( przewodniczącego OMG ), Morgan & Claypool, USA, 2012, Synthesis Lectures on Software Engineering #1. 182 strony. ISBN 9781608458820 (miękka okładka), ISBN 9781608458837 (ebook). http://www.mdse-book.com
Stanleya J. Sewalla. Uzasadnienie wykonawcze dla MDA
Soylu A., De Causmaecker Patrick. Łączenie podejść do rozwoju systemów opartych na modelach i ontologiach z wszechobecnej perspektywy obliczeniowej , w Proc 24th Intl Symposium on Computer and Information Sciences. 2009, s. 730–735.

Linki zewnętrzne