Objektorientierte Vorgehensmodelle

Präsentation zum Thema: "Objektorientierte Vorgehensmodelle"—  Präsentation transkript:

1 Objektorientierte Vorgehensmodelle
Praktischer Einsatz im Unterricht DI Harald Sander

2 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 DI Harald Sander

3 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 DI Harald Sander

4 Objektorientierte Vorgehensmodelle
DI Harald Sander

5 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 DI Harald Sander

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

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

8 Objektorientierte Vorgehensmodelle
RUP (Rational Unified Process) schwergewichtige Methodik sehr formalisiert hoher Einführungsaufwand DI Harald Sander

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

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

11 Objektorientierte Vorgehensmodelle
Wasserfallmodell OO Entwurf OO Design OO Programmierung Problemanalyse Anforderungsdefinition Entwurf Implementierung Test Test Einsatz und Betreuung Einsatz und Betreuung DI Harald Sander

12 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 DI Harald Sander

13 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) DI Harald Sander

14 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“ DI Harald Sander

15 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 ??!!?? DI Harald Sander

16 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. DI Harald Sander

17 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 DI Harald Sander

18 Objektorientierte Vorgehensmodelle
MDA - Vorgehensweise Forward Engineering Reverse Engineering Quellcode Modelle Round Trip Engineering DI Harald Sander

19 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 DI Harald Sander

20 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. DI Harald Sander

21 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