Objektorientierte Vorgehensmodelle Praktischer Einsatz im Unterricht 12. 10. 2010 DI Harald Sander

Objektorientierte Vorgehensmodelle Im Durchschnitt sind: ca. 23% der Softwareprojekte erfolgreich, ca. 53% der Softwareprojekte über Budget und/oder Zeit, ca. 24% der Softwareprojekte vorzeitig abgebrochen worden Untersuchung von Standish Group, Gartner Group, Cutter Consortium und Cneter for Project Management 12. 10. 2010 DI Harald Sander

Objektorientierte Vorgehensmodelle Im Durchschnitt produziert ein Entwickler im längerfristigen Durchschnitt pro Tag: 10 lines of code (LOC) laut Mayer 2005 16 lines of code (LOC) laut Ludewig/Richter 2006 gilt für Team – geeigneten, dokumentierten, zuverlässigen, test- und wartbaren Code Zeitbdarf wird häufig zu kurz geschätzt Projektorganisation Kommunikationsbedarf Programmierdauer 12. 10. 2010 DI Harald Sander

Objektorientierte Vorgehensmodelle   12. 10. 2010 DI Harald Sander

Objektorientierte Vorgehensmodelle Verschiedene Meinungen zur optimalen Vorgehensweise, häufig wiederzufindende Praktiken und Forderungen sind folgende: klares schriftlich fixiertes Projektziel Änderungen der Anforderungen von vornherein einplanen Design und Architektur möglichst einfach, gut strukturiert und änderbar Kundeneinbindung, intensiv und kontinuierlich frühe Prototypen frühes und häufiges Testen richtiges Maß an Dokumentation 12. 10. 2010 DI Harald Sander

Objektorientierte Vorgehensmodelle Scrum leichtgewichtige Methodik hoher Einführungsaufwand kein Überblick über die Architektur „Scrum is simple, but very hard“ 12. 10. 2010 DI Harald Sander

Objektorientierte Vorgehensmodelle XP (Extreme Programming) leichtgewichtige Methodik geringer Einführungsaufwand Architektur wird von allen definiert erfordert daher ein homogenes Team 12. 10. 2010 DI Harald Sander

Objektorientierte Vorgehensmodelle RUP (Rational Unified Process) schwergewichtige Methodik sehr formalisiert hoher Einführungsaufwand 12. 10. 2010 DI Harald Sander

Objektorientierte Vorgehensmodelle V-Modell (Unternehmensprozess) sehr formalisiert und dokumentenzentriert Archtiktenaufgabe auf mehrere Rollen verteilt hoher Einführungsaufwand 12. 10. 2010 DI Harald Sander

Objektorientierte Vorgehensmodelle OEP (Object Engineering Process) anwendungsfall und architektur- zentriert zugeschnitten auf Entwicklung betrieblicher Informations- systeme, weniger für technische Systeme geeignet 12. 10. 2010 DI Harald Sander

Objektorientierte Vorgehensmodelle Wasserfallmodell OO Entwurf OO Design OO Programmierung Problemanalyse Anforderungsdefinition Entwurf Implementierung Test Test Einsatz und Betreuung Einsatz und Betreuung 12. 10. 2010 DI Harald Sander

Objektorientierte Vorgehensmodelle erlaubt Iterationen nur zwischen zwei aufeinanderfolgenden Phasen relativ starr sequentiell geringer Einführungsaufwand funktioniert auch in einem heterogenen Team Erfolgreichen praktischen Einsatz im Schulalltag, verspricht aus didaktischen Gesichtspunkten nur das Wasserfallmodell begrenzte Zeit Komplexität der anderen Vorgehensweisen (vor allem im Rollenverständnis) Gefahr dadurch Schüler zu verlieren + überschaubar + Einfachheit 12. 10. 2010 DI Harald Sander

Objektorientierte Vorgehensmodelle Alle diese Vorgehensmodelle haben ihre bestimmten Anwendungsgebiete mit Vor- und Nachteilen Allen gemeinsam ist, das als Unterstützung UML (Unified Modelling Language) zur Modellierung eingesetzt wird bzw. werden kann. Idealerweise wird dazu ein Modellierungstool eingesetzt, kostenfreie Tools sind z.B.: StarUML Argo - UML (Verwendung in diesem Seminar) Together Control Center Fujuba Live e2UML PlugIn für Eclipse (kurze Vorstellung) 12. 10. 2010 DI Harald Sander

Objektorientierte Vorgehensmodelle IT Problemstellungen datenbasierte Probleme Daten, welche das Problem beschreiben stehen im Vordergrund (statische Diagrammtypen der UML stehen im Vordergrund) – Beispiel „Arztpraxis“ szenariobasierte Probleme Abläufe und Prozesse stehen im Vordergrund (dynamische Diagrammtypen der UML stehen im Vordergrund) – Beispiel „Kaffeemaschine“ 12. 10. 2010 DI Harald Sander

Objektorientierte Vorgehensmodelle OO Entwurf Sammeln von Fakten Darstellung und Überprüfung der Fakten Unabhängig von Informatiksystemen Ergebnis ist eine Anforderungsdefinition und vorläufiges Modell OO Design Weiterentwicklung des Modells Abhängig von Informatiksystemen Einarbeitung von Design Patterns Ergebnis ist ein vollständiges Modell, beinhaltet auch das User Interface Auftraggeber und Entwickler müssen diesem Modell zustimmen OO Programmierung Modell wird in eine Programmiersprache abgebildet Beachtung des Zielsystems (Laufzeitbetrachtung) Modell Driven Architecture (MDD) -> Modell Driven Architecture (MDA) -> Forward und Reverse Engineering, Round Trip Engineering ??!!?? 12. 10. 2010 DI Harald Sander

Objektorientierte Vorgehensmodelle MDD bezeichnet die Verwendung von Modellen und Generatoren zur Verbesserung der Softwareentwicklung. MDD unterscheidet sich zu den CASE (Computer Aided Software Engineering) - Ansätzen der 1990er Jahre dadurch, das CASE - Ansätze das Ziel hatten, Software möglichst vollständig automatisiert aus der fachlichen Beschreibung zu erstellen. CASE erwies sich als zu unflexibel und konnte sich daher nicht durchsetzen. MDA ist ein möglicher Weg zur Implementierung von MDD Erfordert keine 100 prozentige Automatisierung, sondern nur einen sinnvollen Anteil (variiert von 20 bis 80 Prozent, je nach fachlicher Anforderung). Architektur wird händisch erstellt, daher flexibel und man hat die Kontrolle während des Entwicklungsablaufs. 12. 10. 2010 DI Harald Sander

Objektorientierte Vorgehensmodelle Ziele: Steigerung der Entwicklungsgeschwindigkeit bessere Handhabbarkeit, aufgrund der höheren Abstraktion Vorgehen: man unterteilt das Modell in Untermodelle, da ein Modell zu überladen wäre und damit zu unscharf CIM (Computer Independent Model) – Umgangssprachliche Beschreibung PIM (Plattform Indenpendent Model) – Beschreibung der Geschäftsprozesse PSM (Plattform Specific Model) – Beschreibung der Architektur und Services CM (Code Model) – Code für die Zielplattform 12. 10. 2010 DI Harald Sander

Objektorientierte Vorgehensmodelle MDA - Vorgehensweise Forward Engineering Reverse Engineering Quellcode Modelle Round Trip Engineering 12. 10. 2010 DI Harald Sander

Objektorientierte Vorgehensmodelle UML ist keine Methode, sondern bietet eine Notation für Modelle UML ermöglicht es eine gemeinsame Sprache zwischen Auftraggeber und Entwickler zu lernen dadurch ist eine präzise Beschreibung eines Softwaresystems möglich UML ist auch Dokumentationswerkzeug dadurch wird es ermöglicht, ein System nachzuvollziehen, es zu erweitern und zu verändern UML ist nicht nur für die Modellierung von Software einsetzbar, sondern auch für andere Bereiche 12. 10. 2010 DI Harald Sander

Objektorientierte Vorgehensmodelle UML in den IT Bildungsstandards - Bereich 5 Softwareentwicklung IT 5.4.B (Verstehen) - Ich kann die wichtigsten UML-Diagramme und deren Einsatz erklären. IT 5.16.C (Anwenden) – Ich kann eine mittels UML - Diagramm spezifierte Umweltbeschreibung in eine Objektorientierte Programmiersprache umsetzen. IT 5.25.E (Entwicklen) – Ich kann eine gegebene Anwendungssituation analysieren und daraus ein UML-Klassendiagramm ableiten. 12. 10. 2010 DI Harald Sander

Objektorientierte Vorgehensmodelle Methode nach Abott Anwendungsfall- diagramm Dokumenten-analyse Rapid Analyse Design CRC-Karten Abschluss Vorstudien dynamische Analyse Klassen- diagramm Untersuchung des zeitlichen Ablaufs parallele Prozesse darstellen Objektzustände darstellen statische Analyse Interaktions- diagramme Aktivitäts- diagramm Zustands- diagramm Schwerpunkt Nachrichtenverlauf Schwerpunkt aktive Objekte? nein Sequenz-diagramm ja Kollaborations- diagramm Abschluss der Entwurfsphase