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).

Übrigens: Die PlusPedia ist NICHT die Wikipedia.
Wir sind ein gemeinnütziger Verein, PlusPedia ist werbefrei. Wir freuen uns daher über eine kleine Spende!

1 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.

2 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.

2.1 Erstens

Usecases aufschreiben

2.2 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

2.3 Drittens

Objekte (hierarchsich) anordnen

2.3.1 Viertens

Beziehungen zwischen den Klassen sind zu modellieren.

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

2.3.2 Fünftes

Wiederverwendung von externem Code prüfen

2.3.3 Sechstes

Balancierterten Entwurf erstellen

2.3.4 Siebtens

Klassen und Vererbung aus Objektdesign erstellen

2.3.5 Achtens

Code gut lesbar

3 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.

4 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.