UML 2.0 und MDA: Neues Paradigma für die Softwareentwicklung?

Präsentation zum Thema: "UML 2.0 und MDA: Neues Paradigma für die Softwareentwicklung?"—  Präsentation transkript:

1 UML 2.0 und MDA: Neues Paradigma für die Softwareentwicklung?
Thank you for the opportunity to present to you today. Many of you who grew up in the industry know Borland from its language compiler technologies in the 1980s that changed the face of software development by bringing it to the desktop and enabling millions to build application quickly and cost-effectively. In the late 90s we refocused the company around its core values of Excellence in Software Development, and we have fared very well since that time, bucking the trend affecting virtually all software companies in our industry. We have grown every quarter (except the 9/11 quarter), and have been consistently profitable every step of the way, culminating in two major technology acquisitions late last year. More about this later. Our focus on excellent technology and great products endures and is a leading theme for the company going forward as well. Take Away: Borland Continues to Deliver Great Products München, 10. November 2003 Udo Apel Technical Director Deutschland-Österreich-Schweiz

2 Agenda- bzw. Präsentationsmerkmale
Softwareentwicklung im Griff? Softwareentwicklung mit UML Modell Driven Architecture und UML 2.0 Modell Driven Architecture im Überblick MDA: Was ist das ? MDA: Grundlagen und Prinzip MDA konrekt MDA Vor- und Nachteile MDA oder MDA „light“ ? Diskussion: MDA ein weiterer Hype oder neues Paradigma in der Softwareentwicklung

3 Software-Entwicklung: Erfolgsfaktoren
PROZESSE MENSCHEN TECHNOLOGIE

4 Softwareentwicklung „old style“

5 daraus folgt...

6 Software-Entwicklung im Griff ?
Branching Remote Debugging Security Ausfallsicherheit Workflow Black-Box Tests GUI Team-Development Struktur-Analyse Use-Cases Lastverhalten Traceability Change Management Deployment Fachkonzept Prozessmodellierung Transaktionen Web-Services White-Box Tests Iterative Vorgehensweise EJB Performance Integration Caching Requirements-Analyse Web Skalierbarkeit Workflow Versionierung Build-Prozess

7 Technologien und Tools als Lösung ?
J2EE C++ C# Delphi SmallTalk Python UML .NET CORBA ?

8 Prozessmodelle als Lösung ?
Wasserfall Modell V-Modell Prototypen-Modell Evolultionäres Modell Iteratives Modell Inkrementelles Modell „Nebenläufiges“ Modell Rational Unified Process (RUP) Synchronize-Stabilize (MS) Rapid-Object-Oriented Process for Embedded Systems (ROPES) Cluster Modell Extreme Programming (XP) Agile Processes (iterativ-inkrementell) Application Lifecycle Management to be continued... ?

9 Application Lifecycle Management als Lösung ?
Change und Config managen ? Modellieren und dokumentieren Code erzeugen DESIGN DEVELOP Fachlichkeit definieren DEFINE CCM TEST Code testen DEPLOY Deployment optimieren Anforderungen festlegen Deployment erstellen

10 Kernfrage des Abends Was leistet unter Einbeziehung von Technologien, Werkzeugen, Prozessen und ALM-Perspektiven die Modell Driven Architecture für die Softwareentwicklung ?

11 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. Folgende Diagrammarten sind gegeben: Class Diagram Use-Case Diagram Sequence Diagram Collaboration Diagram Statechart Diagram Activity Diagram Component Diagram Deployment Diagram Use Case Sequence Class

12 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

13 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.ä.

14 UML: Nutzen für die Softwareentwicklung
Unklarheiten ? Missverständnisse ? Auslassungen ? Zwei Probleme: Übergang von abstrakt zu konkret  UML als Vermittler

15 UML: Nutzen für die Softwareentwicklung
Unklarheiten ? Schnittstellen ? Missverständnisse ? Architektur ? APIs ? Auslassungen ? Zwei Probleme: Übergang von abstrakt zu konkret  UML als Vermittler Detailreichtum von (fertigen) Softwaresystemen  UML als Agreggation

16 UML: Vorgehensweise für die Softwareentwicklung
Findung des Funktionalitäts- / Ablaufumfanges mit Hilfe von UseCase (Anwendungsfall-) Diagrammen Bestandteile von UseCase Diagrammen: Relationen zwischen UseCases:

17 UML: Vorgehensweise für die Softwareentwicklung
UseCases sind der Ausgangspunkt für weitere Vorgehen: Aus Akteuren werden Klassensysteme > > Akteur aus UC Analyse-Klassen Implementierungs Klassen

18 UML: Vorgehensweise für die Softwareentwicklung
UseCases sind der Ausgangspunkt für weitere Vorgehen: Aus Akteuren werden Klassensysteme UCs werden entweder durch weitere UCs genauer beschrieben, oder (bei genug granularer Beschreibung) in Klassensysteme umgesetzt >

19 UML: Vorgehensweise für die Softwareentwicklung
UseCases sind der Ausgangspunkt für weitere Vorgehen: Aus Akteuren werden Klassensysteme UCs werden entweder durch weitere UCs genauer beschrieben, oder (bei genug granularer Beschreibung) in Klassensysteme umgesetzt > >

20 UML: Vorgehensweise für die Softwareentwicklung
Die Aktivitäten/Aufgaben/Abläufe des Systemes werden detailgenau mit Hilfe von Sequence-Diagrammen dargestellt

21 UML: Weitere Diagrammtypen
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.

22 UML: Weitere Diagrammtypen
Collaboration Diagramm  Verhalten Im Vergleich zum Sequence Diagramm abstraktere Darstellung der Beteiligten an bestimmten Aktivitäten / der Zusammenarbeit innerhalb eines Prozesses. Typischerweise werden UCs durch Collaboration Diagramme genauer beschrieben.

23 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 Objektattributen manifestieren.

24 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 Schnittstellen Zwischen den Systemen.

25 UML: Weitere Diagrammtypen
Deployment Diagramm  Struktur Darstellung der Verteilung der einzelnen Subsysteme und Komponenten auf physikalische Maschinen.

26 UML: Chancen und Risiken
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

27 UML: Chancen und Risiken
UML ist keine Lösung sondern Teil der Lösung

28 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.

29 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

30 UML 2.0 im Fokus: MDA, BPM, XMI, RT
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).

31 Ziele der UML 2.0 Ü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

32 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

33 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.

34 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)

35 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

36 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.

37 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.

38 Fachliche Spezifikation
MDA Prinzip Fachliche Spezifikation PIM anhand UML (-Profil) PIM-to-PSM-Transformation PSM´s durch UML Profile J2EE .NET CORBA XML Modell-Code-Transformation J2EE Code .NET Code CORBA Code XML Implementierung

39 MDA Prinzip Fachliche Modellierung
-Konzepte (Klassen, Abläufe, usw.) der Anwendungsdomänen werden beschrieben -unabhängig von Implentierungstechnologie PIM PSM Code

40 MDA Prinzip Integration der Plattformspezifika
-Technologie (Betriebssystem, Programmiersprache, Middleware, RDBMS, etc.) -Parametersets steuern Generierung von PSM aus PIM PIM PSM Code

41 MDA Prinzip Generierung von Programmcode
-Generatoren erzeugen den Code aus dem PSM und aus Templates -Architektur-Knowhow in Vorlagen -Parameter steuern Generierungsprozess PIM PSM Code

42 Platform Independent Model
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

43 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.

44 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

45 UML Profile 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)

46 Mappings innerhalb der Modell Driven Architecture
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

47 PIMs zu PSMs zu PIMs ? 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. Zusammenhang PIM " PSM " Plattform

48 Zusammengefasst: Basiselemente der MDA
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

49 Zusammengefasst: Basiselemente der MDA
Mapping, Transformation 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

50 Zusammengefasst: Basiselemente der MDA
Services Directory Security Transactions Events Quasi die PIM Darstellung der entsprechenden CORBA-Services Vereinfacht die Programmierung durch Nutzung der Funktionen

51 Zusammengefasst: Basiselemente der MDA
Vertikals 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

52 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.

53 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

54 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.

55 Die idealtypische „MDA Maschinerie“
UML/ Case-Tool Generator SW-Komponenten UML Modelle

56 Annahmen: Vorteile der MDA
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

57 Annahmen: Nachteile 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) Bis hierhin sind dies die Aussagen und Aussichten die die OMG zur MDA veröffentlicht hat. Die MDA ist aber bisher immer noch nicht über den Ansatz einer Idee, oder eines Standards, heraus gekommen. Die OMG überlässt es an dieser Stelle der Industrie weitere Ideen zur praktischen Umsetzung zu präsentieren. Unterschiedliche Ansätze werden bisher verfolgt, aber es ist noch kein Standard für den Transformationsprozess in Sicht.

58 Referenzen/ Quellen 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

59 Vielen Dank für Ihre Aufmerksamkeit