Modellgetriebene Architektur ( MDA ) ist ein Software-Designansatz für die Entwicklung von Softwaresystemen. Sie bietet Richtlinien für die Strukturierung von Spezifikationen, die als Modelle ausgedrückt werden. Modellgetriebene Architektur ist eine Form des Domänen-Engineerings und unterstützt das modellgetriebene Engineering von Softwaresystemen. Sie wurde 2001 von der Object Management Group (OMG) ins Leben gerufen. [ 1 ]

Überblick

Model Driven Architecture® (MDA®) bietet einen Ansatz zur Wertschöpfung aus Modellen und Architekturen, der den gesamten Lebenszyklus physischer, organisatorischer und IT-Systeme unterstützt. Ein Modell ist eine Abstraktion eines Systems. MDA® schafft Mehrwert durch die Erstellung von Modellen auf verschiedenen Abstraktionsebenen – von der konzeptionellen Sicht bis hin zu kleinsten Implementierungsdetails. Die OMG-Literatur spricht von drei solchen Abstraktionsebenen bzw. Architektursichtweisen: dem rechenunabhängigen Modell (CIM), dem plattformunabhängigen Modell (PIM) und dem plattformspezifischen Modell (PSM). Das CIM beschreibt ein System konzeptionell, das PIM die Rechenaspekte eines Systems ohne Bezugnahme auf die zur Implementierung verwendeten Technologien, und das PSM liefert die für die Implementierung des Systems notwendigen technischen Details. Der OMG Guide merkt jedoch an, dass diese drei Architektursichtweisen zwar nützlich sind, aber nur drei von vielen möglichen Sichtweisen darstellen. [ 2 ]

Die OMG-Organisation stellt Spezifikationen anstelle von Implementierungen bereit, häufig als Antwort auf Ausschreibungen (RFPs). Implementierungen stammen von privaten Unternehmen oder Open-Source-Gruppen.

Das MDA-Modell basiert auf mehreren Standards, darunter die Unified Modeling Language (UML), die Meta-Object Facility (MOF), XML Metadata Interchange (XMI), Enterprise Distributed Object Computing (EDOC), das Software Process Engineering Metamodel (SPEM) und das Common Warehouse Metamodel (CWM). Der Begriff „Architektur“ in Model Driven Architecture (MDA) bezieht sich nicht auf die Architektur des modellierten Systems, sondern auf die Architektur der verschiedenen Standards und Modellformen, die die technologische Grundlage für MDA bilden.

Ausführbares UML war das UML-Profil, das bei der Entstehung von MDA verwendet wurde. Jetzt fördert die OMG stattdessen fUML . (Die Aktionssprache für fUML ist ALF.)

Warenzeichen

Die Object Management Group besitzt eingetragene Markenrechte an dem Begriff „Model Driven Architecture“ und dessen Akronym MDA sowie an Markenrechten für Begriffe wie: „Model Based Application Development“, „Model Driven Application Development“, „Model Based Programming“, „Model Driven Systems“ und andere. [ 3 ]

Themen der modellgetriebenen Architektur

MDA-Ansatz

OMG konzentriert sich bei Model Driven Architecture® auf Forward Engineering, d. h. die Generierung von Code aus abstrakten, manuell erstellten Modellierungsdiagrammen (z. B. Klassendiagrammen). Die ADTF-Gruppe (Analysis and Design Task Force) von OMG leitet diese Bemühungen. Mit einem Augenzwinkern wählte die Gruppe ADM (MDA rückwärts) als Bezeichnung für die Reverse-Engineering-Forschung. ADM steht für Architecture-Driven Modernization (Architekturgetriebene Modernisierung). Ziel von ADM ist die Entwicklung von Standards für das modellbasierte Reverse Engineering von Altsystemen. [ 4 ] Das Knowledge Discovery Metamodel (KDM) ist der am weitesten fortgeschrittene dieser Ansätze und beschreibt Informationssysteme anhand verschiedener Assets (Programme, Spezifikationen, Daten, Testdateien, Datenbankschemata usw.).

Da sich die Konzepte und Technologien zur Umsetzung von Designs und Architekturen unabhängig voneinander weiterentwickelt haben, ermöglicht deren Entkopplung Systementwicklern, die jeweils besten und passendsten Lösungen auszuwählen. Das Design adressiert die funktionalen Anforderungen ( Anwendungsfälle ), während die Architektur die Infrastruktur bereitstellt, durch die nicht-funktionale Anforderungen wie Skalierbarkeit, Zuverlässigkeit und Leistung realisiert werden. MDA geht davon aus, dass das plattformunabhängige Modell (PIM), das ein konzeptionelles Design zur Umsetzung der funktionalen Anforderungen darstellt, auch bei Änderungen der Realisierungstechnologien und Softwarearchitekturen Bestand haben wird .

Von besonderer Bedeutung für die modellgetriebene Architektur ist das Konzept der Modelltransformation . Eine spezifische Standardsprache für die Modelltransformation wurde von der OMG mit dem Namen QVT definiert .

MDA-Tools

Die OMG-Organisation liefert eher grobe Spezifikationen als konkrete Implementierungen, oft als Antwort auf Ausschreibungen (RFPs). Der gesamte Prozess wird von der OMG in einem Dokument namens MDA-Leitfaden festgehalten.

Ein MDA-Tool dient im Wesentlichen dazu, Modelle oder Metamodelle zu entwickeln, zu interpretieren, zu vergleichen, abzugleichen, zu messen, zu verifizieren, zu transformieren usw. [ 5 ] Im Folgenden wird „Modell“ als jede Art von Modell (z. B. ein UML-Modell) oder Metamodell (z. B. das CWM-Metamodell) verstanden. Bei jedem MDA-Ansatz gibt es im Wesentlichen zwei Arten von Modellen: Ausgangsmodelle werden manuell von Menschen erstellt, während abgeleitete Modelle automatisch von Programmen generiert werden. Beispielsweise kann ein Analyst aus der Beobachtung einer vagen Geschäftssituation ein UML-Ausgangsmodell erstellen, aus dem dann durch eine Modelltransformation automatisch ein Java-Modell abgeleitet wird .

Ein MDA-Tool kann ein Werkzeug sein, das dazu dient, Modelle auf Vollständigkeit, Inkonsistenzen sowie Fehler- und Warnzustände zu überprüfen.

Manche Werkzeuge erfüllen mehrere der oben genannten Funktionen. Beispielsweise verfügen einige Erstellungswerkzeuge auch über Transformations- und Testfunktionen. Andere Werkzeuge dienen ausschließlich der Erstellung, ausschließlich der grafischen Darstellung, ausschließlich der Transformation usw.

Implementierungen der OMG-Spezifikationen stammen von privaten Unternehmen oder Open-Source -Gruppen. Eine wichtige Quelle für OMG-Implementierungen ist die Eclipse Foundation (EF). Viele Implementierungen von OMG-Modellierungsstandards finden sich im Eclipse Modeling Framework (EMF) oder im Graphical Modeling Framework (GMF). Die Eclipse Foundation entwickelt darüber hinaus weitere Tools verschiedener Art, wie beispielsweise GMT. Die Einhaltung der OMG-Spezifikationen durch Eclipse ist oft nicht streng. Dies gilt beispielsweise für den OMG-Standard EMOF, den EMF mit seiner Ecore-Implementierung annähernd umsetzt. Weitere Beispiele finden sich im M2M-Projekt, das den QVT-Standard implementiert, oder im M2T-Projekt, das den MOF2Text-Standard implementiert.

Man sollte darauf achten, die Liste der MDA-Werkzeuge nicht mit der Liste der UML-Werkzeuge zu verwechseln , da erstere wesentlich umfassender ist. Diese Unterscheidung lässt sich weiter fassen, indem man zwischen „Werkzeugen mit variablem Metamodell“ und „Werkzeugen mit festem Metamodell“ unterscheidet. Ein UML-CASE-Werkzeug ist typischerweise ein „Werkzeug mit festem Metamodell“, da es fest so programmiert ist, dass es nur mit einer bestimmten Version des UML-Metamodells (z. B. UML 2.1) funktioniert. Andere Werkzeuge hingegen verfügen über interne generische Funktionen, die es ihnen ermöglichen, sich an beliebige oder bestimmte Arten von Metamodellen anzupassen.

Üblicherweise konzentrieren sich MDA-Tools auf die Spezifikation rudimentärer Architekturen, obwohl die Tools in einigen Fällen architekturunabhängig (oder plattformunabhängig) sind.

Einfache Beispiele für Architekturspezifikationen sind:

  • Auswahl einer der unterstützten Referenzarchitekturen wie Java EE oder Microsoft .NET ,
  • Die Architektur wird auf einer feineren Ebene spezifiziert, einschließlich der Wahl der Präsentationsschichttechnologie, der Geschäftslogikschichttechnologie, der Persistenztechnologie und der Persistenz-Mapping-Technologie (z. B. objektrelationaler Mapper).
  • Metadaten: Informationen über Daten.

MDA-Bedenken

Einige Schlüsselkonzepte des 2001 eingeführten MDA-Ansatzes wurden erstmals Ende der 1980er Jahre durch die Shlaer-Mellor-Methode erläutert. Tatsächlich wurde ein wichtiger, bisher fehlender technischer Standard des MDA-Ansatzes – die Syntax einer Aktionssprache für ausführbares UML – von einigen Anbietern durch die Anpassung der ursprünglichen Shlaer-Mellor-Aktionssprache (modifiziert für UML) überbrückt. Dennoch konnte sich der MDA-Ansatz in dieser Zeit nicht in der breiten Industrie durchsetzen. Die Gartner Group stufte MDA in ihrem „ Hype Cycle “ von 2006 weiterhin als aufstrebende Technologie ein [ 6 ] , während Forrester Research MDA im selben Jahr als gescheitert einstufte [ 7 ]. Zu den potenziellen Bedenken hinsichtlich des OMG-MDA-Ansatzes gehören:

  • Unvollständige Standards: Der MDA-Ansatz basiert auf einer Vielzahl technischer Standards, von denen einige noch nicht spezifiziert (z. B. eine Aktionssemantiksprache für xtUML ) oder noch nicht standardisiert implementiert (z. B. eine QVT- Transformations-Engine oder ein PIM mit virtueller Ausführungsumgebung) sind. [ 8 ] [ 9 ]
  • Anbieterabhängigkeit: Obwohl MDA als Ansatz zur Erreichung (technischer) Plattformunabhängigkeit konzipiert wurde, zögern die derzeitigen MDA-Anbieter, ihre MDA-Toolsets interoperabel zu gestalten. Dies könnte zu einer Anbieterabhängigkeit für diejenigen führen, die einen MDA-Ansatz verfolgen.
  • Idealistisch: MDA ist als Forward-Engineering-Ansatz konzipiert, bei dem Modelle, die Action-Language-Programmierung einbeziehen, durch einen vollständig oder teilweise automatisierten „Generierungsschritt“ in Implementierungsartefakte (z. B. ausführbarer Code, Datenbankschema) transformiert werden. Dies entspricht der Vision der OMG, dass MDA die Modellierung der gesamten Komplexität eines Problembereichs in UML (und verwandten Standards) mit anschließender Transformation in eine vollständige (ausführbare) Anwendung ermöglichen soll. [ 10 ] Dieser Ansatz impliziert jedoch, dass Änderungen an Implementierungsartefakten (z. B. Optimierung des Datenbankschemas) nicht unterstützt werden. Dies stellt ein Problem dar, wenn eine solche Anpassung der Implementierungsartefakte nach der Transformation als notwendig erachtet wird. Hinweise darauf, dass der vollständige MDA-Ansatz für manche reale Anwendungen zu idealistisch sein kann, zeigt der Aufstieg des sogenannten „pragmatischen MDA“. [ 11 ] Pragmatic MDA verbindet die wörtlichen Standards von OMGs MDA mit traditionelleren modellgetriebenen Ansätzen wie Round-Trip-Engineering , das Unterstützung für die Anpassung von Implementierungsartefakten bietet (wenn auch nicht ohne erhebliche Nachteile).
  • Spezielle Kompetenzen: Anwender von MDA-basierter Softwareentwicklung müssen (wie bei anderen Werkzeugsätzen) über ein hohes Maß an Fachwissen verfügen. Derzeit sind erfahrene MDA-Anwender (oft als Modellierer/Architekten bezeichnet) im Vergleich zu traditionellen Entwicklern rar. [ 12 ]
  • Erfolgsbilanz der OMG: Das OMG-Konsortium, das den MDA-Ansatz fördert (und die Marke MDA besitzt), hat auch den CORBA-Standard eingeführt und gefördert, der sich jedoch selbst nicht als weit verbreiteter Standard durchsetzen konnte. [ 13 ]
  • Unsicheres Wertversprechen (UVP): Wie bereits erwähnt, ermöglicht die Vision von MDA die Spezifikation eines Systems als abstraktes Modell, das als konkrete Implementierung (Programm) für eine bestimmte Computerplattform (z. B. .NET) realisiert werden kann. Eine Anwendung, die erfolgreich mit einem reinen MDA-Ansatz entwickelt wurde, könnte somit theoretisch deterministisch auf eine neuere .NET-Plattform (oder sogar eine Java-Plattform) portiert werden – allerdings bleiben hinsichtlich der praktischen Umsetzung (z. B. der Benutzeroberflächenimplementierung) noch erhebliche Fragen offen. Ob diese Möglichkeit ein signifikantes Wertversprechen darstellt, ist für die einzelnen Anwender eine Frage. Ungeachtet dessen sollten Anwender von MDA, die in einer „Alternative zur Programmierung“ einen Mehrwert suchen, diesen Ansatz sehr sorgfältig bewerten. Die Komplexität jedes Problembereichs bleibt bestehen, und die Programmierung der Geschäftslogik muss in MDA wie in jedem anderen Ansatz erfolgen. Der Unterschied bei MDA besteht darin, dass die verwendete Programmiersprache (z. B. xtUML) abstrakter ist (als beispielsweise Java oder C#) und eng mit traditionellen UML-Artefakten (z. B. Klassendiagrammen) verknüpft ist. Ob die Programmierung in einer abstrakteren Sprache als den gängigen 3GL- Sprachen zu Systemen von besserer Qualität, geringeren Kosten oder schnellerer Bereitstellung führt, ist eine Frage, die noch nicht ausreichend beantwortet wurde.
  • MDA wurde als möglicher Weg erkannt, verschiedene, unabhängig voneinander entwickelte standardisierte Lösungen zusammenzuführen. Für die Simulationsgemeinschaft wurde es als wirtschafts- und industrieorientierte Alternative zu einem weiteren vom US-Verteidigungsministerium vorgeschriebenen Standard empfohlen. [ 14 ]

Siehe auch

Referenzen

Weiterführende Literatur

  • Kevin Lano. „Modellgetriebene Softwareentwicklung mit UML und Java“. CENGAGE Learning, ISBN 978-1-84480-952-3
  • David S. Frankel . Modellgetriebene Architektur: Anwendung von MDA im Enterprise Computing . John Wiley & Sons, ISBN 0-471-31920-1
  • Meghan Kiffer, The MDA Journal: Modellgetriebene Architektur direkt von den Meistern . ISBN 0-929652-25-8
  • Anneke Kleppe (2003). MDA Explained, The Model Driven Architecture: Practice and Promise . Addison-Wesley. ISBN 0-321-19442-X
  • Stephen J. Mellor (2004). MDA Distilled, Principles of Model Driven Architecture . Addison-Wesley Professional. ISBN 0-201-78891-8
  • Chris Raistrick. Modellgetriebene Architektur mit ausführbarem UML . Cambridge University Press, ISBN 0-521-53771-1
  • Marco Brambilla, Jordi Cabot, Manuel Wimmer, Modellgetriebene Softwareentwicklung in der Praxis , Vorwort von Richard Soley ( OMG -Vorsitzender), Morgan & Claypool, USA, 2012, Synthesis Lectures on Software Engineering #1. 182 Seiten. ISBN 9781608458820(Taschenbuch), ISBN 9781608458837(E-Book). http://www.mdse-book.com
  • Stanley J. Sewall. Begründung der Exekutive für die Massenentnahme.
  • Soylu A., De Causmaecker Patrick. Zusammenführung modellgetriebener und ontologiegetriebener Systementwicklungsansätze aus der Perspektive des pervasiven Computing , in: Proceedings des 24. Internationalen Symposiums für Computer- und Informationswissenschaften. 2009, S. 730–735.