Modellgetriebene Softwareentwicklung 30.10.2008 Dr. Georg Pietrek, itemis AG
Inhalt Wer ist itemis? Modellgetriebene Entwicklung Ein Praxis-Beispiel Fazit 2
Vorstellung IT-Dienstleister Software-Entwicklung Schulung/Coaching Vorgehensmodelle (agile Verfahren) Toolkette/Toolentwicklung Software-Architektur Projektmanagement Mitarbeit im Projekt Auftragsentwicklung 3
Vorstellung Anwendungsgebiete Unternehmensanwendungen Eingebettete Systeme Expertise/Schwerpunkt: Modellgetriebene Entwicklung 4
Vorstellung Standorte Lünen (Hauptsitz) Kiel Leipzig Bonn Pforzheim Toulouse bald: Schweiz, Nordamerika Mitarbeiter über 130 5
Ausgewählte Kunden und Projekte ThyssenKrupp Steel Ablösung der Hostsysteme in der Verkehrswirtschaft durch J2EE Systeme Deutsche Post Optimierung der MDA Entwicklung, SOA Einführung Mailing Factory, Gesundheitskarte, Plusbrief Individuell Bertelsmann Projekte für Lufthansa Miles & More, Maggi, Riester Rente PricewaterhouseCoopers Benchmarking Platform, zentrales Kernprojekt, strategische Partnerschaft Bosch Toolkette Modellgetriebene Softwareentwicklung für Automobil-Steuergeräte 6
Innovationsfähigkeit 4+1 Arbeitszeitmodell Open Source Engagement Werkzeuge für Modellgetriebene Entwicklung Strategisches Mitglied der Eclipse Foundation Forschungsprojekte Veröffentlichungen Bücher Zeitschriftenbeiträge Konferenzen 7
Inhalt Wer ist itemis? Modellgetriebene Entwicklung Ein Praxis-Beispiel Fazit 8
Modellgetriebene Entwicklung Was ist Modellgetriebene Entwicklung? Vielfalt von Begriffen: MDA (Model Driven Architecture) MDSD (Model Driven Software Development) MBD (Model Based development) DSL (Domain Specific Language) Gemeinsamkeit: maschinelle Verarbeitung von Modellen daraus: Erzeugung von Modellen, Quelltext, Testfällen, Dokumentation, Konfigurationsdateien, 9
MDA Was ist Model Driven Architecture (MDA)? Definiert von der OMG Generierung von Software aus UML-Modellen drei Stufen Platform Independent Model (PIM) Platform Specific Model (PSM) Quelltext Wird in dieser theoretischen Reinform in der Praxis fast nie angewandt 10
MDA Geschäftsprozesse Anforderungen Computational Independent Model (CIM) Model-Model Transformation* Analyse/Design CORBA-Model J2EE-Model XML-Model Platform Independent Model (PIM) Model-Model Transformation* Platform Specific Models (PSM) Model-Code Transformation* CORBA-Code J2EE-Code XML Implementierung * Transformationen sind i.d.r. Tool-gestützt 11
MDA Was ist MDA wirklich? MDA ist keine Architektur (im Sinne einer Software-Architektur) MDA ist Architektur-neutral beliebige Architekturen lassen sich mit MDA umsetzen MDA ist ein Ansatz, einen bestimmten Teil des Softwareentwicklungsprozesses zu automatisieren 12
MDSD pragmatische Sicht: Model Driven Software Development (MDSD) Modellierung in geeigneter Darstellungsform (UML, DSL, Visio, Excel-Datei) grafisch textuell Generierung von Quelltext-Rahmen (oder anderen Artefakten) Ergänzen des Rahmens mit handprogrammiertem Code (100%-Generierung kein sinnvolles Ziel!) 13
MDSD Model 2 Text Simulation/Visualization Model 2 Model M2 MDSD Models Validation/Verification Editors 14
MDSD Entwicklungsprozess und Erzeugnisse Analyse OOA-Modell Design OOD-Modell Implementierung Quelltext MDSD automatisiert einen Teil des Schrittes vom OOD-Modell zum Quelltext 15
MDSD Objektorientierte Software-Entwicklung (ohne MDSD) Analyse Design Implementierung Anforderungen Analyse-Modell (OOA) Design-Modell (OOD) Quelltext (OOP) 16
MDSD Vorgehen mit MDSD Analyse Design Generierung Anforderungen Analyse-Modell (OOA) Design-Modell (OOD) Implementierung (Ergänzung) generierter Quelltext Quelltext (OOP) 17
MDSD Vorgehensmodell für MDSD-Etablierung: Definition der Architektur Entwicklung eines Architektur-Prototypen Identifizierung generierbarer Anteile Definition einer Modellierungssprache Ableitung der Templates aus dem Prototyp-Quelltext Verifizierung der Templates durch Rückwärts-Vergleich der Generate mit dem Prototyp-Quelltext Einsatz der Templates Modellierung Generierung Ergänzung des Quelltextes 18
Inhalt Wer ist itemis? Modellgetriebene Entwicklung Ein Praxis-Beispiel Fazit 19
Inhalt Wer ist itemis? Modellgetriebene Entwicklung Ein Praxis-Beispiel Fazit 20
Praxis-Erfahrungen Zwei parallele Entwicklungsstränge gleichzeitige Weiterentwicklung an Architektur/Framework/Generator Fachanwendung auf den erste Blick: macht das Leben schwieriger Koordination der Releases funktionierende Rückkopplung von der Fachanwendungsentwicklung zur Architektur ist unabdingbar 21
Praxis-Erfahrungen Zwei parallele Entwicklungsstränge tatsächlich: einziger in der Praxis funktionierender Weg (Alternative Wasserfall funktioniert nicht) Architektur-Tätigkeit wird konstruktiv (keine Elfenbeinturm-Architektur!) Architektur entwickelt sich auf der Grundlage der Anforderungen der Fachanwendung (Architektur dient der Anwendungsentwicklung) 22
Praxis-Erfahrungen Spezialisierung der Entwickler Aufteilung in zwei Rollen Framework-/Generator-Entwickler Konzentration auf Technik Wissen Generator-Entwicklung nötig Wissen über technische Plattform nötig (EJB, Swing,...) Fachanwendungs-Entwickler Konzentration auf fachliche Aspekte Wissen Generator-Anwendung nötig wie wird modelliert? wo wird handgeschriebener Code zugefügt? kein Plattform-Wissen nötig 23
Praxis-Erfahrungen Spezialisierung der Entwickler zweifacher Vorteil Arbeit kann besser verteilt werden (Herausforderung Großprojekt: wie verteilt man die Aufgaben so, dass 100 Entwickler gleichzeitig arbeiten können?) Konzentration des Entwicklers auf sein Spezialgebiet (es muss nicht mehr jeder alles können) 24
Praxis-Erfahrungen Auswirkungen auf Software-Architektur ein großer Teil der Architektur-Vorgaben kann automatisiert umgesetzt werden garantierte Einhaltung der Architektur-Vorgaben automatisierte Umstellung bei Änderungen möglich (bis hin zum Wechsel auf andere Technik-Plattform) 25
MDSD: Pros und Cons Nachteile: initiale Kosten (für Erst-Erstellung der Generator-Templates) eventuell höhere Anforderungen an Qualifikation der Entwickler (Modellierungs-Kenntnisse) Vorteile: Realisierung konzentriert sich auf fachliche Aspekte mittel-/langfristig niedrigere Kosten langfristige Wartbarkeit Flexibilität Architektur-Änderungen durch Template-Anpassung bis hin zum Wechsel der technischen Plattform garantierte (da automatisierte) Architektur-Konformität höheres Qualitätsniveau der Ergebnisse 26
MDSD: Pros und Cons Größter Nutzen Höheres Qualitätsniveau der Ergebnisse: Vervielfachung von hochwertigem und getestetem Code Erstellung hochwertiger Templates ist rentabel, da diese vielfach genutzt werden keine Flüchtigkeitsfehler (keine Copy&Paste-Programmierung) Konzeption des Systems auf passendem Abstraktionsniveau (Modell, nicht Code) oft angestrebt, aber die Realität sieht meist so aus: einmaliges Erstellen eines Modells danach Pflege im Code Modell ist nach wenigen Monaten historisch bei MDA-Vorgehen automatisch erfüllt 27
Fazit Es lohnt sich! Grosse Teile einer Anwendung generierbar für jede Architektur machbar (vorgestellte Architektur diente hier nur als Beispiel) an beliebige Plattform anpassbar GUI: Struts, JSF, Swing, SWT, Server: EJB, Spring,.NET, Programmiersprache: Java, C#, Groovy, Cobol, 28