Udo Apel Technical Director Deutschland-Österreich-Schweiz UML 2.0 und MDA: Neues Paradigma für...

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