MDA mit AndroMDA

MDA mit AndroMDA Praxiserfahrungen Torsten Lunze, Communardo Software GmbH

Inhalt
Motivation
Kurzeinstieg in AndroMDA
Einsatz im Projekt
Erfahrungen aus dem Projekteinsatz
Fazit
© Communardo Software GmbH · Fon +49 (0) 351 833820 · info@communardo.de · www.communardo.de Folie

Motivation
Welchen Vorteil bringt uns eine MDA Lösung?
Anforderungen
Aufwand für Einarbeitung und Einrichtung im Verhältnis stehend zum Nutzen (Return of Investment)
Einfach handhabbar auch für neue Entwickler
Die Generierung und der Buildprozess muss stabil funktionieren
Das Modellierungstool muss bezahlbar bleiben

Inhalt
Motivation
Einsatz im Projekt
Fazit

Einstieg in AndroMDA
Java Sourceforge Projekt
Version 3.2 im weiteren verwendet
Modellierung erfolgt über UML
Anpassungen durch UML Profile (Stereotypen und Tagged Values)
Generierung anhand von Velocity Templates
Bündelung von Templates und Konfigurationen in Cartridges
Anpassung an generierten Code durch
Vererbung
Mergemappings

Cartridges
Vorgefertige Cartridges:
(N)Hibernate
EJB3
Spring
Webservices (AXIS, Xfire)
Struts
© Communardo Software GmbH · Fon +49 (0) 351 833820 · info@communardo.de · www.communardo.de Folie AndroMDA und Cartridges können direkt verwendet werden ohne Generator oder Templates anzupassen oder zu erstellen.

Andromda Generationsprozess © Communardo Software GmbH · Fon +49 (0) 351 833820 · info@communardo.de · www.communardo.de Folie

Andromda Standardarchitektur © Communardo Software GmbH · Fon +49 (0) 351 833820 · info@communardo.de · www.communardo.de Folie

Inhalt
Motivation
Einsatz im Projekt
Fazit

Einsatz im Projekt
Setup des Projektes
Buildmanagement
Teamwork
Versionskontrolle
Releasemanagement

Setup von AndroMDA
Verwendung von AndroMDA 3.2 mit Cartridges
Hibernate
Spring
BPM4Struts
Modellierung mit MagicDraw 9.5
AndroMDA bietet einen Projektgenerator für Maven 2
Cartridges müssen ebenfalls versioniert werden
Initiale geringe Anpassungen

Buildmanagement
Integration der Generierung in Maven 2
Kleine Änderung im Modell
Ziel: Nur die Dateien neu generieren, die davon betroffen sind
Lösung:
 Generierung nur eines bestimmten Packages
 Generierung nur durch ausgewählte Cartridges
Die Festlegung was neu generiert werden soll, wird nicht automatisch sondern muss vom Entwickler getroffen werden.

Versionierung
Problem: XML Format eines Modells komplex
Mergen nahezu unmöglich
Lösung:
Aufsplitten der Modelle in Schichten (FE/Service/Backend) und Komponenten (User/Evaluation/Security…)
Mehrere Modelldateien
Nutzen von Locks in Versionskontrollen
Alternativ:
Teamworkserver (Checkin/Checkout über MagicDraw)
Generierte Dateien nicht in Versionskontrolle

Releasemanagement
Neues Release 2 wird entwickelt.
Das Modell für Release 2 wird umfangreich angepasst.
Es tritt ein Bug im Release 1 auf.
Der Bugfix benötigt eine Änderung des Modells für Release 1.
Die Änderung muss auch in Release 2 nachgezogen werden…
Automatismus?

Probleme
Konfliktlösung in Modellierung falls Entwickler gleichzeitig ein Modell bearbeitet haben
BPM4Struts Cartridge zu unübersichtlich verwendbar
Modellierung zu umständlich mit MagicDraw
Zusätzlich hoher Lernaufwand um Cartridge zu verstehen
Bugs die durch Cartridge / Generator erzeugt werden sind schwieriger zu beheben
Lösungen die an Standardarchitektur vorbeigehen:
Erstellung von nichtgenerierten Klassen
Keine Modellierung im Modell

Inhalt
Motivation
Einsatz im Projekt
Fazit

Einfluss auf Softwareprozess
Learning Curve: „Lernen statt Arbeiten“
Lernaufwand höher: Zu verstehen was wird wie wo generiert
Dafür Einsparung von Arbeit: Kleine Anpassung im Modell  Große Änderung im Code (anstatt per Hand)
Bei der Konfiguration des Projektes:
Auswahl der zu nutzenden Cartridges
Anpassung, Erweiterung an Architekturforderungen
Während des Projektes:
Fehlerbehebung und Anpassung der Cartridges
Zu entscheiden: Passe ich die Implementierung an oder suche ich eine generische Lösung durch Veränderung der Cartridges?
Nachdem Projekt:
Einfluss der Erfahrungen
Wiederverwendung in neuen Projekten

Verbreitung im Unternehmen
Einstieg in AndroMDA für Softwareentwickler erleichtern
Vorträge
Workshops
Einsatz von AndroMDA in neuen Java Projekten
 Durch ähnliche Architektur von AndroMDA Projekten ist die Einarbeitung in ein anderes AndroMDA Projekt deutlich einfacher
Erstellung und Nutzung einer Cartridge für Coremedia (CMS System)

Andromda - Vorteile
Vorgefertige Cartridges (Hibernate, Spring) sind Out Of The Box verwendbar
Müssen in anderen System i. d. R. erst von Hand geschrieben werden
Sehr aufwändig
Anpassbarkeit gegeben
Schnelles Entwickeln: Modell Code (abgesehen von Setup Aufwand)

Andromda - Nachteile
Muss mit den vorgefertigten generierten Konzept der 3-Schichten-Architektur leben
Trennung des Plattformspezifisches Modell nicht gegeben (für Andromda 4 geplant)
Verknüpfung von mehreren AndroMDA Projekten nur durch Anpassung von Cartridges

Vorteile MDA
Langfristige/Kurzfristige Vorteile (je nach Dauer des Projekts von Bedeutung):
Fehleranfälligkeit und Code-Qualität  Ja
Integration und Interoperabilität  Nicht relevant
Portabilität  Praktisch schwierig
Konsistenz zwischen Code und Modellen  Ja
Aufwand vs. Kosten

Open issues
Stabilität des Datenmodells
Auswirkungen auf Datenbank
Entfremdung des Entwicklers vom Code
Herstellerabhängigkeit durch Verwendung der Tools
Modellierung im Team
Releasemanagement

Inhalt
Motivation
Einsatz im Projekt
Fazit

Fazit
Templates / Cartridges in AndroMDA können direkt gentutzt werden
Ohne Anpassung von Generation möglich Webanwendungen zu generieren
Ansatz in kurz- und mittelfristigen Projekten sinnvoll
Bei großen Projekten führen die Open Issues (insb. Teamwork und Releasemanagement) zu Problemen

Vielen Dank
www.humannetworkcompetence.de
www.communardo.de
www.xing.com/profile/torsten_lunze

MDA mit AndroMDA

by jugsaxony on Apr 04, 2008

Accessibility

Tags

Upload Details

Usage Rights

2 Embeds 5

Statistics

MDA mit AndroMDA — Presentation Transcript

http://www.slideshare.net	4
http://www.software-saxony.de	1