Objektorientierte Analyse und Design

Objektorientierte Analyse und Design (OOAD) sind objektorientiert und dienen dazu Software zu planen. Dazu zählt die Analyse der Anforderungen an die Software und das Design (Wie wird die reale Welt im Programm abgebildet).

Analyse

Die Analyse ist ein fortlaufender Prozess.

Es ist wichtig, eine Dokumentation zu verfassen, die allgemein lesbar ist. Im OO-Desgn werden "Use Case" verwendet.

Design

• 1/3 alle Softwareprojekte werden nicht abgeschlossen!
• Im OO-Design ist es wichtig vorhandene Komponenten, Frameworks und Bibliotheken zu suchen und zu verwenden.
• Man benötigt eine Balance zwischen dem Auftraggeber und Auftragnehmer und den zur Verfügung stehenden Ressourcen.
• Ziel sollte es sein, es so einfach wie möglich ("Keep ist simple") zu halten.
• Ehrgeizige Projekte enden als komplizierte Ungetüme von denen Teile nie oder selten verwendet werden.
• Komplexe Entwürfe können auch Performance-Probleme mit sich bringen.

Erstens

Usecases aufschreiben

Zweitens

Es sind die Hauptsorten / Hauptobjekte / Aktoren an Objekten zu identifizieren.

Bei einem Hersteller können dies sein:

• Geschäftskunden
• private Kunden
• Zulieferer
• Teile
• Güter

Drittens

Objekte (hierarchsich) anordnen

Viertens

Beziehungen zwischen den Klassen sind zu modellieren.

Eine Kunde sollte nicht gelöscht werden, solange es noch einen offenen Prozess gibt (Rechnungen, Guthaben).

Fünftes

Wiederverwendung von externem Code prüfen

Sechstes

Balancierterten Entwurf erstellen

Siebtens

Klassen und Vererbung aus Objektdesign erstellen

Achtens

Code gut lesbar

OO-Implementierung

• Aus dem Design sollte sich die Implementierung ableiten lassen.
• Man einigt sich eventuell auf Möglichkeiten der Programmiersprache zu verzichten statt print a, b, c --> print (a,b,c)
• An die Programmierlichtlinien ist sich zu halten
• Leserbarkeit: Programm wird hier und da geschrieben - aber oft gelesen.

Tests

• Tests benötigen Szenarien und erwartete Resultate
• Das Ziel ist es mögliche Fehler zu finden
• Tests sollten reproduzierbar sein
• Sinnvolle Tests für einzelne Module
• Getrennte Teams für die Entwicklung von Tests beauftragen. Das Team benötigt Verständnis zur Spezifikation.
• Testsuiten - Tests sollten automatisierbar sein.

Wartung

• Änderungswünsche des Kunden
• Änderung der Repräsentierung von Daten
• Notfall-Reparaturen
• Gewöhnliche Korrekturen
• Hardware-Änderungen
• Dokumentation
• Performance-Verbesserungen
• Andere Ursachen

Links und Quellen

Siehe auch

• Unified Modeling Language

---

Andere Lexika

• Objektorientierte Analyse und Design bei Wikipedia (Erste Wikipedia-Version)

---

---