MDA mit AndroMDA
Loading...
Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.
Favorites, Groups & Events
MDA mit AndroMDA - Presentation Transcript
- MDA mit AndroMDA Praxiserfahrungen Torsten Lunze, Communardo Software GmbH
- Inhalt
- Motivation
- Kurzeinstieg in AndroMDA
- Einsatz im Projekt
- Erfahrungen aus dem Projekteinsatz
- Fazit
- 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
- Kurzeinstieg in AndroMDA
- Einsatz im Projekt
- Erfahrungen aus dem Projekteinsatz
- 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
- 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
- © Communardo Software GmbH · Fon +49 (0) 351 833820 · info@communardo.de · www.communardo.de Folie => Modelliert Generiert
- Inhalt
- Motivation
- Kurzeinstieg in AndroMDA
- Einsatz im Projekt
- Erfahrungen aus dem Projekteinsatz
- 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
- Kurzeinstieg in AndroMDA
- Einsatz im Projekt
- Erfahrungen aus dem Projekteinsatz
- 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
- Kurzeinstieg in AndroMDA
- Einsatz im Projekt
- Erfahrungen aus dem Projekteinsatz
- 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
More Info
© All Rights Reserved
Go to text version- Total Views 727
- 726 on SlideShare
- Comments 0
- Favorites 0
- Downloads 0
Most viewed embeds
All embeds
- Uploaded via SlideShare
- Uploaded as Microsoft PowerPoint
0 comments
Post a comment