Post on 06-Apr-2015
Udo Apel
Technical Director
Deutschland-Österreich-Schweiz
UML 2.0 und MDA: Neues Paradigma für die
Softwareentwicklung?
München, 10. November 2003
Agenda- bzw. Präsentationsmerkmale
Softwareentwicklung im Griff?Softwareentwicklung mit UMLModell Driven Architecture und UML 2.0Modell Driven Architecture im Überblick
MDA: Was ist das ?MDA: Grundlagen und PrinzipMDA konrektMDA Vor- und NachteileMDA oder MDA „light“ ?
Diskussion: MDA ein weiterer Hype oder neues Paradigma in der Softwareentwicklung
Software-Entwicklung: Erfolgsfaktoren
PROZESSE
TECHNOLOGIEMENSCHEN
Softwareentwicklung „old style“
daraus folgt...
Software-Entwicklung im Griff ?
EJB
Web
White-Box Tests
Black-Box Tests
Remote Debugging
Deployment
Workflow
Change Management
Requirements-Analyse
Use-CasesStruktur-Analyse
Build-Prozess
Integration
Security
Transaktionen
Versionierung
Branching
Performance
Fachkonzept
Iterative Vorgehensweise
Team-Development
GUI
Web-Services
Skalierbarkeit
Lastverhalten
Ausfallsicherheit
Traceability
Prozessmodellierung
Workflow
Caching
J2EE
C++ C# Delphi SmallTalk Python
UML
.NET CORBA
Technologien und Tools als Lösung ?
Wasserfall ModellV-ModellPrototypen-ModellEvolultionäres ModellIteratives ModellInkrementelles Modell„Nebenläufiges“ ModellRational Unified Process (RUP)Synchronize-Stabilize (MS)Rapid-Object-Oriented Process for Embedded Systems (ROPES)Cluster ModellExtreme Programming (XP)Agile Processes (iterativ-inkrementell)Application Lifecycle Management
to be continued...
Prozessmodelle als Lösung ?
DEFINE
DEPLOY
DESIGN DEVELOP
TEST
Application Lifecycle Management als Lösung ?
CCM
Fachlichkeit definieren
Anforderungen festlegen
Modellieren und dokumentieren
Code erzeugen
Code testen
Deployment erstellen
Deployment optimieren
Change und Config managen
Was leistet unter Einbeziehung von Technologien, Werkzeugen,
Prozessen und ALM-Perspektiven die Modell Driven Architecture für
die Softwareentwicklung ?
Kernfrage des Abends
• Ansammlung von Diagrammarten zwecks einer problem- und lösungsunabhängigen Beschreibung eines fachlichen Inhaltes hinsichtlich Merkmalen des Verhaltens und der Struktur.
Folgende Diagrammarten sind gegeben:» Class Diagram
» Use-Case Diagram
» Sequence Diagram
» Collaboration Diagram
» Statechart Diagram
» Activity Diagram
» Component Diagram
» Deployment Diagram
Class
UseCase
Sequence
UML als Grundlage für die Softwareentwicklung
Ansammlung von Diagrammarten zwecks einer problem- und lösungsunabhängigen Beschreibung eines fachlichen Inhaltes hinsichtlich Merkmalen des Verhaltens und der Struktur.
• Problemunabhängig:
– Gleichermaßen einsetzbar für Banken, Telekommunikations-unternehmen, Behörden, usw.
• Lösungsunabhängig:
– Nutzbar, um Software zu bauen (in verschiedenen Programmiersprachen), Organisationsstrukturen einzuführen oder allgemein Wissen/Know How zu manifestieren/ Abstraktion einzusetzen
Class
UML als Grundlage für die Softwareentwicklung
Ansammlung von Diagrammarten zwecks einer problem- und lösungsunabhängigen Beschreibung eines fachlichen Inhaltes hinsichtlich Merkmalen des Verhaltens und der Struktur.
• Verhalten:
– Reaktion eines Systemes auf Anreize aus der Umgebung, Prozesschritte in einem Ablauf, u.ä.
• Struktur:
– Aufteilung eines Systemes in einzelne Bestandteile, Relationen und Abhängigkeiten zwischen den Bestandteilen, u.ä.
UML als Grundlage für die Softwareentwicklung
Zwei Probleme:1. Übergang von abstrakt zu konkret UML als Vermittler
Missverständnisse ?
Unklarheiten ?
Auslassungen ?
UML: Nutzen für die Softwareentwicklung
Zwei Probleme:1. Übergang von abstrakt zu konkret UML als Vermittler2. Detailreichtum von (fertigen) Softwaresystemen UML als Agreggation
Schnittstellen ?
Architektur ?
APIs ?
UML: Nutzen für die Softwareentwicklung
Missverständnisse ?
Unklarheiten ?
Auslassungen ?
1. Findung des Funktionalitäts- / Ablaufumfanges mit Hilfe von UseCase (Anwendungsfall-) Diagrammen
Bestandteile von UseCase Diagrammen:
Relationen zwischen UseCases:
UML: Vorgehensweise für die Softwareentwicklung
2. UseCases sind der Ausgangspunkt für weitere Vorgehen:1. Aus Akteuren werden Klassensysteme
> >Akteur aus UC Analyse-Klassen Implementierungs
Klassen
UML: Vorgehensweise für die Softwareentwicklung
2. UseCases sind der Ausgangspunkt für weitere Vorgehen:1. Aus Akteuren werden Klassensysteme
2. UCs werden entweder durch weitere UCs genauer beschrieben, oder (bei genug granularer Beschreibung) in Klassensysteme umgesetzt
>
UML: Vorgehensweise für die Softwareentwicklung
2. UseCases sind der Ausgangspunkt für weitere Vorgehen:1. Aus Akteuren werden Klassensysteme
2. UCs werden entweder durch weitere UCs genauer beschrieben, oder (bei genug granularer Beschreibung) in Klassensysteme umgesetzt
>>
UML: Vorgehensweise für die Softwareentwicklung
3. Die Aktivitäten/Aufgaben/Abläufe des Systemes werden detailgenau mit Hilfe von Sequence-Diagrammen dargestellt
UML: Vorgehensweise für die Softwareentwicklung
• Activity Diagramm Verhalten
Im Vergleich zum Sequence Diagramm abstraktere Darstellung von Abläufen/Ablaufmöglichkeiten sowie Datenflüssen oder Entscheidungswegen.
Typischerweise werden UCs durch Activity Diagramme genauer beschrieben.
UML: Weitere Diagrammtypen
• Collaboration Diagramm Verhalten
Im Vergleich zum Sequence Diagramm abstraktere Darstellung der Beteiligten an bestimmten Aktivitäten / der Zusammenarbeit innerhalbeines Prozesses.
Typischerweise werden UCs durch CollaborationDiagramme genauer beschrieben.
UML: Weitere Diagrammtypen
• Statechart Diagramm Verhalten
Darstellung von Zuständen,Zustandsübergängen und deren Bedingungen.
Typischerweise werden Zustände sich in Objekten oder in Objektattributenmanifestieren.
UML: Weitere Diagrammtypen
• Component Diagramm Struktur
Darstellung der einzelnen Subsysteme / Komponenten Und deren Interaktion ggfs. über Schnittstellen.
Hieraus ergibt sich die Aufteilung eines Systemes in seine Einzelteile, sowie ggfs.die benötigten SchnittstellenZwischen den Systemen.
UML: Weitere Diagrammtypen
• Deployment Diagramm Struktur
Darstellung der Verteilung dereinzelnen Subsysteme undKomponenten auf physikalische Maschinen.
UML: Weitere Diagrammtypen
• Es ist relativ leicht, die grundlegende Handhabung von UML zu erlernen.
• Es ist extrem schwierig und bedarf der Erfahrung, UML gewinnbringend in Projekten einzusetzen
– “Zuviel“ Modellierung
– „Zu wenig“ Modellierung
– „Falsche“ Modellierung
UML: Chancen und Risiken
UML ist keine Lösung sondern Teil der Lösung
UML: Chancen und Risiken
UML und UML 2.0
Seit ihrem ersten Erscheinen inerhalb der OMG im Jahr 1996/97 wurde UML mehrmals revidiert. Die bisher letzte Version trägt die Nummer 1.5; die meisten Bücher und Werkzeuge sind auf dem Stand von UML 1.3 oder 1.4.
Es zeigten sich beim Gebrauch von UML Probleme, die nicht mit kleinen Revisionen gelöst werden konnten.
Die OMG, hatte 2001 Projekt für eine Revision von UML gestartet. Interessenten wurden eingeladen, Vorschläge für eine Um- und Neugestaltung von UML zu unterbreiten. Nach einem mehrjährigen Konsensbildungsprozess liegt das Ergebnis vor: die UML 2.0 (verschoben insb. aufgrund MDA Problematiken auf voraussichtlich April 2004)
Während sich an der grundsätzlichen Philosophie von UML wenig geändert hat, soll UML 2.0 in einzelnen Modellierungsbereichen substanzielle Änderungen und Verbesserungen mit sich bringen.
Insbesondere der Bereich der Architekturmodellierung wurde komplett überarbeitet. Ferner gibt es erhebliche Änderungen im Bereich der Modellierung von Abläufen und Verhalten, welche insbesondere eine bessere und umfassendere Generierung von Code aus UML-Modellen ermöglichen und das Konzept der Model-Driven Architecture (MDA) unterstützen. Auch das UML-Metamodell wurde erheblich überarbeitet.
UML 2.0 Gliederung
UML 2.0 ist formal in folgende Teile gegliedert:
• Infrastructure: Kern der Architektur, Profile und Stereotypen
• Superstructure: statische und dynamische Modellelemente
• Object Constraint Language (OCL): formale Sprache für Zusicherungen
• Diagram Interchange: UML-Austauschformat
Beim Entwurf der UML 2.0 wurde unter anderem folgenden Bereichen größere Aufmerksamkeit gegeben:
verbesserter Modellaustausch durch XML Metadata Interchange (XMI), z.B. inklusive Diagramm-Layout-Informationen
verbesserte Unterstützung der Model Driven Architecture (MDA),d. h. auch von Modelltransformationen und ausführbaren UML-Modellen)
bessere Unterstützung von Echtzeitmodellierung (RT) sowie ER Modelling durch neue Diagrammtypen und erweiterte Semantik
optimierte Unterstützung von Geschäftsprozessmodellierung (BPM).
UML 2.0 im Fokus: MDA, BPM, XMI, RT
Übersichtlichkeit-Weniger graphische Modellkonstrukte-Weniger Basiskonzepte-Wiederverwendung von Basiskonzepten
Präzisionssteigerung-Reformulierung des Meta-Modells-Weitestgehende OCL-Verwendung-Unveränderte Wiederverwendung von Basiskonstrukten soweit sinnvoll möglich
Ausführbarkeit-Erweiterte Zustandsmaschinen-Stärkere Beziehungen zwischen statischen und dynamischen Diagrammen-Integration erprobter Konzepte außerhalb der UML
Ziele der UML 2.0
Hintergrund: Modell Driven Architecture
MDA ist ein „junger“ Standard der OMG (Object Management Group)
OMG war bislang oft federführend in der Durchsetzung hersteller-neutraler sowie technisch weitestgehend offener Standards wie z.B. : CORBA
IDL
UML
XMI
MOF
Standards
UML und Object Constraint Language (OCL): Die UML kann als eine Modellierungssprache zur Repräsentation von PIM und PSM verwendet werden. Mithilfe der OCL können diese Modelle semantisch präzisiert werden. Ferner kann die OCL einen Beitrag zur Spezifikation von Restriktionen bei der Modelltransformation leisten.
Meta Object Facility (MOF): Die MOF ist eine Sprache zur Beschreibung von Modellierungssprachen (MetaModellierungssprache), bspw. soll das Metamodell von UML 2.0 mit der MOF harmonisiert werden. Die MOF ist in sich selber definiert, so dass keine höheren Metamodellierungssprachen benötigt werden. Darüber hinaus ist Metamodellierung in der MDA relevant für die Beschreibung von Transformationsdefinitionen: Die Definition von Transformationsregeln kann sich auf die Konstrukte der Metamodelle abstützen, so dass allgemein gültige Transformationsregeln angegeben werden können.
XML Metadata Interchange (XMI): XMI soll zum Austausch von Modellen zwischen verschiedenen Werkzeugen verwendet werden. XMI definiert mithilfe von XML (Extensible Markup Language) die Serialisierung von MOF konformen Sprachen. Hierzu beschreibt XMI, wie die Konstrukte der MOF auf XML abgebildet werden. XMI nimmt nur Bezug auf die Meta-Modellierungssprache MOF, so, dass sämtliche MOF-konforme Modellierungssprachen über XMI mit einem entsprechenden XMLSchema genutzt werden können.
Der Ansatz für MDA
Fachliche Informationen bzw. Spezifikationen werden in plattformunabhängigen Modellen erstellt (PIM= Platform Independent Modell):
>simplifiziert: bspw. ist die Funktionalität zur Überweisung einer bestimmten Menge an Geldes unabhängig von einer technologischen Plattform.
Diese Funktionalität bzw. das „Business Modell“ bleibt unverändert, egal ob es mit CORBA Anwendungen, EJBs oder.NET Komponenten realisiert wird
Erst mit der technischen Erstellung der Business-Komponente in Sourcecode wird ein PSM Status erreicht (PSM: Platform Specific Modell)
MDA und UML 2.0
Die MDA Vision der OMG besteht darin, dass plattformspezifische Modelle ausführbar sind, d.h. Entfall der typischen Code-Generierung
Voraussetzung hierfür: Compiler und Interpreter für Zielplattformen (embedded System -MDA- Compiler) sowie UML 2.0 Spezifikation
Zur Darstellung Plattform-unabhängiger und Plattform-spezifischer Modelle nutzt MDA zusätzlich Artefakte der UML 2.0 :
•Aus UML 2.0 soll automatisiert Plattform-unabhängiger Quellcode generiert werden•UML 2.0 Modelle sollen ausführbar werden•UML 2.0 Modelle sollen vor ihrer Implementierung verifizierbar und validierbar sein
Entwicklungsprozess mit der MDA
Der Entwicklungsprozess beginnt mit einer Anforderungsermittlung, deren Ergebnis eine natürlichsprachliche Beschreibung der Systemanforderungen ist.
Im Rahmen der Analyse werden die Anforderungen in ein PIM überführt. Der Systementwurf in Form eines PSM wird anschließend durchgeführt.
Es folgen Implementierung und Test.
Der Prozess wird durch die Auslieferung des Systems abgeschlossen.
Der Gesamtprozess gleicht einem klassischen Entwicklungsprozess. Der wesentliche Unterschied ist, dass die Transformationsschritte zwischen Analyse, Entwurf und Implementierung nicht manuell, sondern weitgehend automatisiert durchgeführt werden.
Ansatz für MDA
PIM
PSM
Plattformunabhängiges Modell
(UML, OCL, XMI)
Plattformspezifisches Modell
(J2EE, CORBA, .NET)
Fachliche Spezifikationen werden mit einer formal eindeutigen Modellierungssprache (erweiterte UML-Notation) erstellt
Durch Modelltransformation (in der Regel mittels Entwicklungswerkzeugen oder tool-orientierten Generatoren) werden plattformabhängige Modelle (PSM) gewonnen, die im Sinne der Generierung und Ausentwicklung für die konkrete Zielplattform eingesetzt werden.
MDA Prinzip
J2EE Code
Fachliche SpezifikationFachliche Spezifikation
J2EE .NET CORBA XML
.NET Code CORBA Code XML
PIM anhand UML (-Profil)
PIM-to-PSM-Transformation
PSM´s durch UML Profile
Modell-Code-Transformation
Implementierung
MDA Prinzip
PIM PSM Code
Fachliche Modellierung
-Konzepte (Klassen, Abläufe, usw.) der Anwendungsdomänen werden beschrieben
-unabhängig von Implentierungstechnologie
MDA Prinzip
PIM PSM Code
Integration der Plattformspezifika
-Technologie (Betriebssystem, Programmiersprache, Middleware, RDBMS, etc.)
-Parametersets steuern Generierung von PSM aus PIM
MDA Prinzip
PIM PSM Code
Generierung von Programmcode
-Generatoren erzeugen den Code aus dem PSM und aus Templates
-Architektur-Knowhow in Vorlagen
-Parameter steuern Generierungsprozess
Klassenmodell mit zwei fachlichen Klassen: Customer + Account (mit Stereotyp <> )
Attribut, ist mit dem Stereotyp <> ausgezeichnet
Customer enthält Methode “findByLastName”, die mit Stereotyp <> versehen ist.
Die Erweiterung des Standardsprachumfangs der UML durch Stereotypen ist ein Standardmechanismus, der zu diesem Zweck von der OMG spezifiziert wurde.
Hier : Definition der formal eindeutigen Modellierungssprache Erst diese Eindeutigkeit macht ein UML-Modell zu einem MDA-Modell.
Die im PIM verwendeten Konzepte <>, <> und <> sind vollständig unabhängig von der Zielplattform. Erst im PSM finden sich die für J2EE spezifischen Konzepte <>, <> und <>. Konrete Ausformung nach Transf. in Code.
PIM Ausschnitt
Platform Independent Model
Merkmale von UML in der Modell Driven Architecture
MDA Model: Ein Modell ist eine abstrakte Repräsentation von Struktur, Funktion oder Verhalten eines Systems. MDA-Modelle werden in der Regel in UML definiert. Diese sind wiederum unabhängig von der darunter liegenden Plattform UML-Diagramme sind nicht per se MDA-Modelle. Der wichtigste Unterschied zwischen allgemeinen UML-Diagrammen (z.B. Analyse-Modellen) und MDA-Modellen liegt darin, dass die Bedeutung von MDA-Modellen formal definiert ist. Dies wird durch die Verwendung einer formal eindeutigen Modellierungssprache sicher gestellt, die in einem UML-Profile festgelegt wird. Damit wird erreicht, dass das erzeugte Modell eindeutig durch Generatoren auf ein anderes Modell oder auf Sourcecode abgebildet bzw. tranformiert werden kann.
UML Profile
UML-Profile: UML-Profile sind der Standardmechanismus zur Erweiterung des Sprachumfangs der UML. Sie enthalten Sprachkonzepte, die über Basis-UML-Konstrukte wie Klassen und Assoziationen, Stereotypen, Tagged Values und Modellierungsregeln (Constraints) festgelegt werden.
Definiert wird ein UML-Profile als Erweiterung des UML-Metamodells.
Verwendung eines UML-Profils
Die Standard-UML-Konzepte Attribute, Class und Operation werden im UML-Profile um die spezifischen Konzepte PrimaryKeyField, EJBEntityBean und EJBFinderMethod erweitert.
Zusätzliche Erweiterungen werden durch Tagged Values und Modellierungsrichtlinien in Form von Constraints definiert. UML-Profile sind Metamodelle und definieren formale Modellierungssprachen als Erweiterung der UML
UML-Metamodell und UML-Profil für EJB (Ausschnitt)
UML Profile
Mappings innerhalb der Modell Driven Architecture
Mappings:
Die MDA sieht diverse Mappings vor zwischen den Modellen unterschiedlicher Abstraktionsebenen (Platform Independent Model, Platform Specific Model, Enterprise Deployment Model)
Folgende Mappings lassen sich qua Konzept durchführen:
-PIM zu PIM-PIM zu PSM-PSM zu PSM-PSM zu PIM-PSM zu EDM
PIMs zu PSMs zu PIMs ?
Zusammenhang PIM " PSM " Plattform
Die Gewinnung eines PIMs aus einem PSM ist z.Zt. kaum automatisierbar. Dieser Weg erfordert manuelle Arbeit in Form eines Refactorings, da mit dem PIM eine echte Abstraktion erreicht wird. MDA legt einen Forward Engineering Prozess nahe und toolunterstütztes Roundtrip Engineering ist kaum möglich.
UML (2.0): Die Sprache, in der die Modelle (CIM, PIM und PSM) ausgedrückt werden
MOF (MetaObjectFacility): Das MetaModel, Mapping und die Beschreibung der Modelle
CWM (CommonWarehouseModel): Das Pendant von UML für Daten-Modelle
Trennung von Business Logik und technischen Aspekten durch Plattform-Independent Models
Zusammengefasst: Basiselemente der MDA
Die Mappings um PIMs in CORBA, Java und .NET PSMs zu transformieren
XMI/XML als Austauschformat zwischen Modellen und Systemen
Ermöglicht:
– Plattformunabhängigkeit
– Herstellerunabhängigkeit
– Wiederverwendbarkeit
Zusammengefasst: Basiselemente der MDA
Mapping, Transformation
Directory Security Transactions Events Quasi die PIM Darstellung der
entsprechenden CORBA-Services
Vereinfacht die Programmierung durch Nutzung der Funktionen
Zusammengefasst: Basiselemente der MDA
Services
PIMs von verschiedenen Branchen
Z.Zt. HealthCare in Arbeit
„Beispiel Modelle“ aus den jeweiligen Branchen
Ermöglicht vielleicht die Standardisierung und Wiederverwendung von Business-Logik
Zusammengefasst: Basiselemente der MDA
Vertikals
Ziele und Potentiale der Modell Driven Architecture
MDA soll den Entwicklungsprozess beschleunigen: Durch eindeutige (formale) Modelle sollen Generatoren (Modell to Source) automatisch Code erzeugen.
MDA soll die Software-Qualität steigern, indem Fehler aus generierten Sourcecode-Anteilen im Sinne einer eindeutig verortbaren Fehlerquelle (Generator-Schablonen) einmalig verbessert werden.
MDA soll die Wiederverwendbarkeit von Software- oder Softwarekomponenten steigern, dadurch, dass durch die fehleroptimierten Generatoren qualitativ optimierter Sourcecode erzeugt wird.
MDA soll durch die gesteigerte und gleichbleibend hohe Qualität des Codes einen langfristigen Wiederverwendungswert von Software gewährleisten.
Weitere Hauptziele von MDA
Plattformunabhängigkeit
Komplexitätsreduktion mittels Abstraktion, d.h. mittels Modellierungssprachen (UML) und Metakonstrukten zu standardkonformen Modellierungsdiagrammen soll Programmierung im Sinne einer „Enttechnisierung“ durch erhöhte Abstraktionsstufen stattfinden.
Striktere Trennung von Technik und Fachlichkeit, dadurch:•Klare Verantwortlichkeiten im Entwicklungsprozess und -team•Bessere Wartbarkeit von Software bzw. SW-Komponenten•Verbessertes „handling“ von Softwareevolutionen
Gesteigerte Interoperabilität bzw. erleichterte Erstellung interoperabler Software vor dem Hintergrund modellgetriebener SW-Entwicklung
MDA Problem: Transformation
Transformationen: Transformationen bilden Modelle auf die jeweils nächste Ebene, weitere Modelle oder Sourcecode ab. Im Sinne von MDA müssen Transformationen flexibel und formal auf Basis eines gegebenen Profils definiert werden können. Dies ist eine Voraussetzung für die gewünschte Automatisierung der Transformation über Generatoren.
Zur Zeit existiert allerdings noch keine OMG-Spezifikation für eine einheitliche Transformationssprache (Request liegt vor) Darin soll eine Transformation zwischen Metamodellen beschrieben werden. Metamodelle können in UML-Profilen definiert sein.
Nehmen wir an, uns läge ein UML-Profil für EJB und ein UML-Profil für den Borland Applicaton Server “BES” vor. Die Transformation würde dann eine Abbildung zwischen den Modellierungssprachen in diesen beiden UML-Profilen beschreiben. Als Resultat könnten dann Modelle aus der einen Modellierungssprache in die andere überführt werden.
Heutige Generatoren lösen dieses Problem auf andere Weise, indem sie proprietäre Transformationssprachen verwenden. Hier kommen beispielsweise jPhyton, TCL, JSP, XSLT oder zweckoptimierten Skriptsprachen zum Einsatz. Die mit diesen Sprachen definierten Generatorschablonen funktionieren nach dem Prinzip von Makros und verwenden die Modelle als Eingabeparameter. Derzeit ist demzufolge (noch) keine Interoperabilität für Modell-Transformationen gegeben.
Die idealtypische „MDA Maschinerie“
GeneratorGenerator
UML Modelle
UML/ Case-Tool
SW-Komponenten
• Volle Unterstützung der Architektur über den kompletten Application Lifecycle (der Firma)
• Erhöhte Wiederverwendung von Applikationen, Code und Qualität• Technologie-unabhängige Repräsentierung der implementierten Business-Objects• Skalierbarkeit, Stabilität uns Sicherheit durch generierten Code • Stabiler modellbasierter Ansatz maximiert den ROI• Schnelle Einbindung neuer Technologien durch eindeutige PIMs und Profiles,
templates und zusätzliche Schablonen (z.B. EDMs)• Präzisere Umsetzung fachlicher Vorgaben• Schnelle Dokumentation (UML = Dokumentation)• Befreiung von „technikverliebten“ IT-Abteilungen• Unabhängikeit von „IT-Hypes“ • Software-Entwicklung als fabrikorientierte, automatisierte Fertigung von
wiederverwendbaren Komponenten• Entlastung von Kopfmonopolen im Entwicklungsbereich
Annahmen: Vorteile der MDA
Noch zu mangelhaft spezifiziert (UML 2.0) Die verbrauchte Zeit am Anfang einer SW-Entwicklung um ein PIM ausreichend zu
modellieren, ist sehr hoch Es kann lange dauern, bis Mappings für neue Technologien verfügbar sind
(Änderungen in Technologien benötigen Mapping Änderungen, z. B EJB oder CORBA Spec.)
Die Gefahr, dass sich die Theorie nur teilweise umsetzen lässt (insb. MOFs, Omni-Generatoren, etc.)
Proprietäre Generatoren binden Unternehmen an Hersteller Neue Einführung bedeutet sehr hohe Kosten Armotisation nur langfristig zu bewerten, da erheblicher Aufwand im Umfeld des
Neuaufbaus der Entwicklungsprozesse Zu wenig durchgeführte Projekte, wenn, dann meistens anhand individuell
angepasste Generatoren, die zur Zeit MDA eher als firmenspezifische MDD (Model Driven Development) betreiben.
Kosten Nutzen Aspekte sind zur Zeit schwierig zu prognostizieren „Overhead Kill“ durch MDA Hohe Kosten (Neue Konzepte, neue Lernkurven im Unternehmen, neue Tools,
externe Beratung und Training)
Annahmen: Nachteile der MDA
• Refactoring: Improving the Design of Existing Code, Martin Fowler et al., Addison-Wesley, 2000
• Helmut Balzert: Lehrbuch der Software-Technik, Spectrum Vlg. 1996• Roßbach, Stahl, Neuhaus. Model Driven Architecture: Development und Solutions
Journal, Systems 2003. • Andreas Andresen: Komponentenbasierte Softwareentwicklung mit MDA, UML und
XML. Hanser Verlag, 2003.• Bohlen, Starke: MDA entzaubert. In: Objektspeltrum 03/ 2003.• Oesterreich, Walkiens: UML 2.0: Alles wird gut ? In : Object Spectrum 01/ 2003.
• Peter Fettke Peter Loos: Modell Driven Architecture.in: WIRTSCHAFTSINFORMATIK 45 (2003) 5, S. 555–559
• www.omg.org
• www.borland.com
Referenzen/ Quellen
Vielen Dank für Ihre Aufmerksamkeit