Model Driven Architecture: Praktische Interpretation und Anwendung

Model Driven Architecture:
Praktische Interpretation und
Anwendung
Ilja Pavkovic
Projektleiter
© 2003 · b+m Informatik AG · 18.10.2003 · 1/21
Agenda
Vorstellung b+m
b+m Vorgehensmodell
Beispiel StattAuto
MDA - Konzeptionelle Einordnung und Abgrenzung
© 2003 · b+m Informatik AG · 18.10.2003 · 2/21
b+m Fakten
Entwicklung: Gründung (1994), Umwandlung in AG (2000)
Standorte: Melsdorf bei Kiel (Hauptsitz), Berlin (seit 2000), Hannover (seit 2002)
Mitarbeiter: 130 Mitarbeiter
Umsatz: 10,2 Mio. € (in 2002),12 Mio. € Umsatz (in 2003 geplant)
© 2003 · b+m Informatik AG · 18.10.2003 · 3/21
Agenda
Vorstellung b+m
b+m Vorgehensmodell
Beispiel StattAuto
MDA - Konzeptionelle Einordnung und Abgrenzung
© 2003 · b+m Informatik AG · 18.10.2003 · 4/21
Infrastrukturcode: Ansatz für Codegenerierung
J2EE Anwendung Kredit
J2EE Anwendung Bauspar
Infrastruktur Code Kredit
• Aktivitäten
• Prozesse
• Komponenten
• Anbindung von Host-Tx
• JSPs/Controller/Model
• ...
Infrastruktur Code Bauspar
...
Fachlicher Code Kredit
• Methoden in Aktivitäten
• Methoden in Entitäten
• Host-Transaktionen
• ...
Fachlicher Code Bauspar
...
Architektonischer Infrastruktur
Code in n-facher Ausprägung
Der Infrastruktur Code aller
Anwendungen ist von
gleicher Systematik aber
nicht identisch
© 2003 · b+m Informatik AG · 18.10.2003 · 5/21
Anwendungsfamilien
J2EE Anwendung Kredit
Fachlicher Code Kredit
...
J2EE Anwendung Bauspar
Fachlicher Code Bauspar
...
Architektonischer
Infrastruktur Code in 1facher Ausprägung
Vorteile
Generierbarkeit für jede
Anwendung der Familie
Architekturzentriertes Design Kredit
Architekturzentriertes Design Bauspar
Qualität (fester CodeRahmen)
Wartbarkeit
J2EE Anwendungsfamilie
Infrastruktur Code für unternehmensspezifische J2EE-Architektur z.B.
in Form von Schablonen (Templates)
Migrierbarkeit
Standardisierte
Dokumentation
Generatives
Testengineering
© 2003 · b+m Informatik AG · 18.10.2003 · 6/21
Ein generativer Entwicklungsprozess (b+m Generative
Development Process)
Iteration
Laufzeitkomponenten
erstellen
Analyse
Architektur
Erstellung einer
Anwendungsfamilie
Design
ReferenzImplementierung erstellen
Muster
identifizieren
ReferenzDesign erstellen
Generierung
Implementierung
Generator Templates
ableiten
© 2003 · b+m Informatik AG · 18.10.2003 · 7/21
MDA-Ansatz (1/2)
Unser MDA-Ansatz – architekturzentrierte, generative Entwicklung:
Der b+m GDP ist als Tailoring für etablierte Entwicklungsprozesse gedacht und soll
diese nicht ersetzen, sondern ergänzen
Modellbasierte Sourcecodegenerierung auf Basis von PIMs
Wohldefinierte Anwendungsarchitektur liefert schematischen Code, der generiert
werden kann
Generierter Code stützt sich auf ein generisches Laufzeitsystem
© 2003 · b+m Informatik AG · 18.10.2003 · 8/21
MDA-Ansatz (2/2)
Sourcecodegenerierung wird nur eingesetzt, wo sie die Arbeit erleichtert (Ersatz
von Copy-Paste-Programmierung)
Nicht ganze Anwendungen werden generiert, sondern nur ImplementierungsRahmen, die ausprogrammiert werden
Inkrementelle Generierung wird ermöglicht durch frei definierbare, geschützte
Bereiche
Reines Forward-Engineering: „Das Modell ist gleichbedeutend mit Code“
(garantierte Konsistenz)
Anwendungsfamilien statt Unikate
© 2003 · b+m Informatik AG · 18.10.2003 · 9/21
Agenda
Vorstellung b+m
b+m Vorgehensmodell
Beispiel StattAuto
MDA - Konzeptionelle Einordnung und Abgrenzung
© 2003 · b+m Informatik AG · 18.10.2003 · 10/21
Beispiel StattAuto: Die Produktidee
Informationssystem für Car-Sharing Unternehmen
Reservierung und Vermietung von KFZ
Verwaltung der Stammdaten der Mitglieder
Annahme und Erfassung der Reservierung
Prüfung der Verfügbarkeit von KFZ
Abrechnung mit den Mitgliedern
Produktkarton
© 2003 · b+m Informatik AG · 18.10.2003 · 11/21
Beispiel StattAuto:
Laufzeitsystem und
Plattform
Plattform
Tomcat Webserver 4.1.x
EJB 2.0 konformer Applikationserver JBOSS 3.0.4
Datenbank Hypersonic SQL 1.6x
Laufzeitsystem
struts 1.1 als Ablaufsteuerung
Zusätzlich exemplarisch einige Basis- und Hilfsklassen, die den
Applikationsrahmen von StattAuto ergänzen
© 2003 · b+m Informatik AG · 18.10.2003 · 12/21
Beispiel StattAuto: Transformation
Architekturkonzepte/
UML-Profil
Plattformbindung/Generat
Struts-ActionForm
Presentation
Struts-Action
Struts-Config
ActivityController
ValueObject
ProcessObject
JSP
Java-“Structure“
BusinessInterface EJB-SessionBean
BusinessDelegate
EntityObject
EJB-EntityBean
CMP 2.0 Mapping
Plattform
Tomcat
Struts
BaseClasses/Util
JBOSS
HSQL DB
Transformation
© 2003 · b+m Informatik AG · 18.10.2003 · 13/21
Analysemodell „StattAuto Reservierung“
[ Abbruch ]
Reservierung
identifizieren
[ Reservierung ändern ]
Benutzer
anmelden
[ Abbruch ]
[ Ok ]
Mitglied
identifizieren
[ Abbruch ]
Kat egorie
auswählen
[ Ok ]
[ Ok ]
[ Reservierung anlegen ]
Reservierung
bearbeiten
[ Ok ]
Reservierung
bestätigen
[ Abbruch ]
[ Ok ]
© 2003 · b+m Informatik AG · 18.10.2003 · 14/21
Designmodell „StattAuto Reservierung“
[ Abbruch ]
<<Activity>>
ReservierungIdentifizieren
{ControllerClass=de. ...}
[ ReservierungAendern ]
<<Activity>>
BenutzerAnmelden
[ Abbruch ]
<<Activity>>
MitgliedIdentifizieren
{ControllerClass=de. ...}
[ Ok ]
{ControllerClass=de. ...}
[ Abbruch ]
[ Ok ]
<<Activity>>
KategorieAuswaehlen
[ Ok ]
{ControllerClass=de. ...}
[ ReservierungAnlegen ]
<<Activity>>
ReservierungBearbeiten
{ControllerClass=de. ...}
[ Ok ]
<<Activity>>
ReservierungBestaetigen
{ControllerClass=de. ...}
[ Abbruch ]
[ Ok ]
© 2003 · b+m Informatik AG · 18.10.2003 · 15/21
Beispiel StattAuto: Statistische Auswertung
Präsentation-Schicht
98% generiert
Action, JSP, ActionForm, strutsconfig
Geschäftslogik-Schicht
70% generiert
SessionBeans, Business Delegates, „Structure“
Datenhaltungs-Schicht
98% generiert
EntityBeans, CMP-Mapping
Summe
Anteil Infrastruktur-Code:
85% (generiert)
Anteil Business-Logik (manuell programmiert):
15%
© 2003 · b+m Informatik AG · 18.10.2003 · 16/21
Agenda
Vorstellung b+m
b+m Vorgehensmodell
Beispiel StattAuto
MDA - Konzeptionelle Einordnung und Abgrenzung
© 2003 · b+m Informatik AG · 18.10.2003 · 17/21
MDA - Konzeptionelle Einordnung und Abgrenzung (1/2)
MDA ist kein CASE-, 4GL-, oder UML-Tool
Flexibilität durch variable Profile, Transformationen und Plattformen
Interoperabilität durch Standardisierung
MDA ist mehr als pragmatische Sourcecode-Generierung durch generative Wizards, IDEs
oder projektspezifische Scripts
Abstrakte, durchgängige Modellierung durch profiliertes UML
Standardisierung und Tool-Unabhängigkeit
Generische MDA-Werkzeuge erleichtern das Erstellen von Transformationen und
ermöglichen iterative und inkrementelle Generierung
© 2003 · b+m Informatik AG · 18.10.2003 · 18/21
MDA - Konzeptionelle Einordnung und Abgrenzung (2/2)
MDA-Vision (mit UML 2.0): Action Semantics und Executable UML
MDA umfasst das Konzept der Entwurfsmuster
Entwurfsmuster können insbesondere transparent für den Entwickler innerhalb der
Transformationen verwendet werden
© 2003 · b+m Informatik AG · 18.10.2003 · 19/21
Fazit
Welches sind die Erfolgsfaktoren beim Einsatz von MDA ?
Werkzeuge müssen ihre Kosten durch Nutzen aufwiegen
Projektspezifika berücksichtigen (ggf. spezielles Profil)
Ausschöpfung des Potenzials durch Vermeidung von Unikaten
Entwicklungsprozess: Zusammenspiel Analyse und Architektur
Team-Organisation
b+m goes open source: http://www.architectureware.de
Praktischer Erfolg belegt u.a. durch Success Story der Gothaer Versicherungen unter
http://www.omg.org/mda/products_success.htm
© 2003 · b+m Informatik AG · 18.10.2003 · 20/21
Vielen Dank für Ihre
Aufmerksamkeit !
Kontakt
Ilja Pavkovic
b+m Informatik GmbH Berlin
Schumannstraße 6
10117 Berlin-Mitte
[email protected]
Tel.: (030) 288 788-10
© 2003 · b+m Informatik AG · 18.10.2003 · 21/21