Architektura oparta na modelach - Model-driven architecture

Model Driven Architecture ® (MDA®) to podejście do projektowania oprogramowania służące do opracowywania systemów oprogramowania. Zawiera zestaw wytycznych dotyczących strukturyzowania specyfikacji, które są wyrażone jako modele . Model Driven Architecture jest rodzajem inżynierii domen i obsługuje opartą na modelach inżynierię systemów oprogramowania. 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ść poprzez tworzenie modeli na różnych poziomach abstrakcji, od koncepcyjnego widoku do najdrobniejszego szczegółu implementacji. Literatura OMG mówi o trzech takich poziomach abstrakcji lub architektonicznych punktów 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 zapewnia szczegóły techniczne niezbędne do wdrożenia systemu. Przewodnik OMG zauważa jednak, że te trzy architektoniczne punkty widzenia są przydatne, ale są to tylko trzy z wielu możliwych punktów widzenia.

Organizacja OMG zapewnia specyfikacji zamiast implementacji, często w odpowiedzi na zapytania ofertowe (ofertowych). Wdrożenia pochodzą od prywatnych firm lub grup open source.

Powiązane standardy

Model MDA jest powiązany z wieloma standardami, w tym z Unified Modeling Language (UML), Meta-Object Facility (MOF), XML Metadata Interchange (XMI), Enterprise Distributed Object Computing (EDOC), metamodelem inżynierii procesów oprogramowania (SPEM) oraz metamodel wspólnego magazynu (CWM). Należy zauważyć, że termin „architektura” w modelu 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.

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

Znak towarowy

Przedmiot działalności Grupy ładownie zarejestrowanymi znakami towarowymi w sprawie czasu Model Driven Architecture i jego akronim MDA, jak również znaków towarowych do pojęć takich jak: model oparty Application Development, model Driven Application Development, model oparty Application Development, model oparty programowania, Model Driven Systems, i inni.

Tematy dotyczące architektury opartej na modelu

Podejście MDA

OMG koncentruje 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). Grupa zadaniowa ADTF (Analysis and Design Task Force) OMG przewodzi tym wysiłkom. Z pewnym humorem grupa wybrała ADM (od tyłu MDA), aby nazwać badanie inżynierii odwrotnej. ADM dekoduje do modernizacji opartej na architekturze. Celem ADM jest opracowanie standardów inżynierii odwrotnej opartej na modelach istniejących systemów. Metamodel odkrywania wiedzy (KDM) jest najdalej w tych wysiłkach i opisuje systemy informacyjne w kategoriach różnych zasobów (programów, specyfikacji, danych, plików testowych, schematów 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, ich rozdzielenie pozwala programistom systemów wybierać spośród najlepszych i najbardziej odpowiednich w obu dziedzinach. Projekt odnosi się do wymagań funkcjonalnych ( przypadków użycia ), podczas gdy architektura zapewnia infrastrukturę, dzięki 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 w technologiach realizacji i architekturach oprogramowania .

Szczególne znaczenie w architekturze opartej na modelu ma pojęcie transformacji modelu . Specjalny język standardowy do transformacji modeli został zdefiniowany przez firmę OMG o nazwie QVT .

Narzędzia MDA

Organizacja OMG zapewnia ostre specyfikacji zamiast implementacji, często w odpowiedzi na zapytania ofertowe (ofertowych). OMG dokumentuje cały proces w dokumencie zwanym Przewodnikiem MDA.

Zasadniczo narzędzie MDA jest narzędziem używanym do opracowywania, interpretowania, porównywania, dopasowywania, mierzenia, weryfikacji, przekształcania itp. modeli lub metamodeli. W dalszej części „model” jest interpretowany jako oznaczający dowolny rodzaj modelu (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 utworzyć początkowy model UML na podstawie obserwacji jakiejś luźnej sytuacji biznesowej, podczas gdy model Java może zostać automatycznie wyprowadzony z tego modelu UML poprzez operację transformacji modelu .

Narzędzie MDA może być narzędziem używanym do sprawdzania modeli pod kątem kompletności, niespójności lub błędów i ostrzeżeń. Służy również do obliczania metryk modelu.

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 transformacji 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 Eclipse Foundation (EF). Wiele implementacji standardów modelowania OMG można znaleźć w Eclipse Modeling Framework (EMF) lub Graphical Modeling Framework (GMF), fundacja Eclipse opracowuje 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 OMG EMOF, który EMF aproksymuje swoją implementacją Ecocore. Więcej przykładów można znaleźć w projekcie M2M wdrażającym standard QVT lub w projekcie M2T wdrażającym standard MOF2Text.

Należy uważać, aby nie pomylić Listy Narzędzi MDA z Listą narzędzi UML , która jest znacznie szersza. Rozróżnienie to można uogólnić, rozróżniając „narzędzia metamodeli zmiennych” i „narzędzia metamodeli stałych”. Narzędzie UML CASE jest zazwyczaj „stałym narzędziem metamodelu”, ponieważ zostało na stałe przystosowane do pracy tylko z daną wersją metamodelu UML (np. UML 2.1). Wręcz przeciwnie, inne narzędzia mają wewnętrzne zdolności generyczne, które pozwalają im dostosowywać się do dowolnych metamodeli lub do określonego rodzaju metamodeli.

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

Proste przykłady specyfikacji architektury obejmują:

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

Obawy dotyczące MDA

Niektóre kluczowe koncepcje, które leżą u podstaw podejścia MDA (rozpoczętego w 2001 r.) zostały po raz pierwszy wyjaśnione metodą Shlaera-Mellora pod koniec lat osiemdziesiątych. Rzeczywiście, kluczowy nieobecny standard techniczny podejścia MDA (składnia języka akcji dla Executable UML ) został pomostowany przez niektórych dostawców poprzez adaptację oryginalnego języka akcji Shlaer-Mellor (zmodyfikowanego dla UML). Jednak w tym okresie podejście MDA nie zyskało akceptacji w branży; przy czym Gartner Group nadal identyfikuje MDA jako technologię „rosnącą” w swoim „ Cykle rozgłosu ” z 2006 r. , a firma Forrester Research w 2006 r. ogłosiła, że ​​MDA jest „DOA”.

  • Niekompletne standardy: Podejście MDA opiera się na różnych standardach technicznych, z których niektóre nie zostały jeszcze określone (np. język semantyki działań dla xtUML ) lub nie zostały jeszcze zaimplementowane w standardowy sposób (np. mechanizm transformacji QVT lub PIM ze środowiskiem wykonanie wirtualnej).
  • Zamknięcie dostawcy: Chociaż MDA zostało pomyślane jako podejście do osiągnięcia (technicznej) niezależności platformy, obecni dostawcy MDA niechętnie projektowali swoje zestawy narzędzi MDA tak, aby były interoperacyjne. Taki wynik może skutkować zablokowaniem dostawcy dla tych, którzy stosują podejście MDA.
  • Idealistyczny: MDA jest pomyślany jako podejście inżynieryjne, w którym modele zawierające programowanie w języku Action Language są przekształcane w artefakty implementacyjne (np. kod wykonywalny, schemat bazy danych) w jednym kierunku poprzez w pełni lub częściowo zautomatyzowany krok „generowania”. Jest to zgodne z wizją OMG, że MDA powinno umożliwiać modelowanie pełnej złożoności problematycznej domeny 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. dostrajanie schematu bazy danych) nie są obsługiwane . Stanowi to problem w sytuacjach, gdy takie potransformacyjne „adaptowanie” artefaktów implementacyjnych jest postrzegane jako konieczne. Dowodem na to, że pełne podejście MDA może być zbyt idealistyczne dla niektórych wdrożeń w świecie rzeczywistym, był wzrost tak zwanego „pragmatycznego MDA”. Pragmatic MDA łączy dosłowne standardy MDA OMG z bardziej tradycyjnymi mechanizmami opartymi na modelach, takimi jak inżynieria w obie strony, która zapewnia wsparcie dla adaptacji artefaktów implementacji.
  • Wyspecjalizowane zestawy umiejętności: Od praktyków inżynierii oprogramowania opartej na MDA (podobnie jak w przypadku innych zestawów narzędzi) wymaga się wysokiego poziomu wiedzy w swojej dziedzinie. Obecni praktycy-eksperci MDA (często określani jako Modelerzy/Architekci) są rzadkością w porównaniu z dostępnością tradycyjnych programistów.
  • OMG Track Record: 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 w sobie nie zmaterializował się jako powszechnie stosowany standard.
  • Niepewna propozycja wartości (UVP): Jak wspomniano, wizja MDA pozwala na określenie systemu jako abstrakcyjnego modelu, który może być realizowany jako konkretna implementacja (program) dla konkretnej platformy obliczeniowej (np. .NET). W ten sposób aplikacja, która została pomyślnie opracowana przy użyciu czystego podejścia MDA, mogłaby teoretycznie zostać przeniesiona na nowszą platformę .NET (lub nawet platformę Java) w sposób deterministyczny – chociaż pozostają istotne pytania dotyczące praktycznych aspektów rzeczywistych podczas tłumaczenia (takich jak jako implementacja interfejsu użytkownika). To, czy ta zdolność stanowi znaczącą propozycję wartości, pozostaje pytaniem dla poszczególnych adoptujących. Niezależnie od tego, osoby stosujące MDA, które poszukują wartości poprzez „alternatywę dla programowania”, powinny być bardzo ostrożne przy ocenie tego podejścia. Złożoność każdej 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). To, czy programowanie w języku, który jest bardziej abstrakcyjny niż główne języki 3GL , będzie skutkowało systemami lepszej jakości, tańszymi kosztami lub szybszą dostawą, jest pytaniem, na które trzeba jeszcze odpowiedzieć.
  • MDA uznano za możliwy sposób na połączenie różnych niezależnie opracowanych znormalizowanych rozwiązań. Społeczności zajmującej się symulacjami zarekomendowano ją jako biznesową i branżową alternatywę dla jeszcze jednego standardu nakazanego przez Departament Obrony USA.

Kontrowersje związane z generowaniem kodu

Generowanie kodu oznacza, że ​​użytkownik w sposób abstrakcyjny modeluje rozwiązania, które są konotowane przez niektóre dane modelu, a następnie zautomatyzowane narzędzie wyprowadza z modeli części lub całość 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 przytaczaną krytyką jest to, że diagramom UML po prostu brakuje szczegółów, które są potrzebne do zawierania tych samych informacji, które są zawarte w źródle programu. Niektórzy programiści twierdzą nawet, że „Kod jest projektem”.

Zobacz też

Bibliografia

Dalsza lektura

  • Kevina Lano. „Tworzenie oprogramowania oparte na modelu z UML i Java”. CENGAGE Learning, ISBN  978-1-84480-952-3
  • David S. Frankel . Architektura oparta na modelu: zastosowanie MDA w komputerach korporacyjnych . John Wiley & Sons, ISBN  0-471-31920-1
  • Meghan Kiffer Dziennik MDA: 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 . Addisona-Wesleya. ISBN  0-321-19442-X
  • Stephena J. Mellora (2004). Destylowane MDA, Zasady architektury opartej na modelu . Addison-Wesley Profesjonalista. 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, Praktyczna inżynieria oprogramowania oparta na modelu , przedmowa Richarda Soleya ( prezesa OMG ), Morgan & Claypool, USA, 2012, Synteza Wykłady z Inżynierii Oprogramowania #1. 182 strony. ISBN  9781608458820 (miękka okładka ), ISBN  9781608458837 (ebook). http://www.mdse-book.com
  • Stanley J. Sewall. Uzasadnienie wykonawcze dla MDA
  • Soylu A., De Causmaecker Patrick. Połączenie podejścia opartego na modelu i opartego na ontologii podejścia do rozwoju systemu opartego na wszechobecnej perspektywie obliczeniowej , w Proc 24th Intl Symposium on Computer and Information Sciences. 2009, s. 730-735.

Zewnętrzne linki