Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Udo Apel Technical Director Deutschland-Österreich-Schweiz UML 2.0 und MDA: Neues Paradigma für die Softwareentwicklung? München, 10. November 2003.

Ähnliche Präsentationen


Präsentation zum Thema: "Udo Apel Technical Director Deutschland-Österreich-Schweiz UML 2.0 und MDA: Neues Paradigma für die Softwareentwicklung? München, 10. November 2003."—  Präsentation transkript:

1 Udo Apel Technical Director Deutschland-Österreich-Schweiz UML 2.0 und MDA: Neues Paradigma für die Softwareentwicklung? München, 10. November 2003

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 TECHNOLOGIEMENSCHEN

4 Softwareentwicklung „old style“

5 daraus folgt...

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

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

8  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... Prozessmodelle als Lösung ?

9 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

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

11 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 Use Case Sequence UML als Grundlage für die Softwareentwicklung

12  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

13  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

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

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

16 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

17 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

18 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

19 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

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

21 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

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

23 Statechart Diagramm  Verhalten Darstellung von Zuständen, Zustandsübergängen und deren Bedingungen. Typischerweise werden Zustände sich in Objekten oder in Objektattributen manifestieren. UML: Weitere Diagrammtypen

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

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

26 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

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

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  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

31 Ü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

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 MDA Prinzip J2EE Code Fachliche Spezifikation J2EE.NETCORBA XML.NET CodeCORBA CodeXML PIM anhand UML (-Profil) PIM-to-PSM-Transformation PSM´s durch UML Profile Modell-Code-Transformation Implementierung

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

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

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

42  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

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  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

46 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

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

48  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

49  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

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

51  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

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“ Generator UML Modelle UML/ Case-Tool SW-Komponenten

56 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

57  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

58 Refactoring: Improving the Design of Existing Code, Martin Fowler et al., Addison- Wesley, 2000 Helmut Balzert: Lehrbuch der Software-Technik, Spectrum Vlg Roßbach, Stahl, Neuhaus. Model Driven Architecture: Development und Solutions Journal, Systems Andreas Andresen: Komponentenbasierte Softwareentwicklung mit MDA, UML und XML. Hanser Verlag, Bohlen, Starke: MDA entzaubert. In: Objektspeltrum 03/ Oesterreich, Walkiens: UML 2.0: Alles wird gut ? In : Object Spectrum 01/ Peter Fettke Peter Loos: Modell Driven Architecture.in: WIRTSCHAFTSINFORMATIK 45 (2003) 5, S. 555–559 Referenzen/ Quellen

59 Vielen Dank für Ihre Aufmerksamkeit


Herunterladen ppt "Udo Apel Technical Director Deutschland-Österreich-Schweiz UML 2.0 und MDA: Neues Paradigma für die Softwareentwicklung? München, 10. November 2003."

Ähnliche Präsentationen


Google-Anzeigen