Objektorientierte Analyse, Design, Implementation

Ok, viele werden sich jetzt denken… OOA, OOD, OOI kenn ich ja schon.

Aus meiner praktischen Erfahrung weiss ich aber, dass viele Leute vorallem den Aufwand von OOA und OOD scheuen bzw. diese Phasen vernachlässigen. Ich werde in diesem Artikel versuchen, denn Sinn dieser Phasen zu erläutern und was typische Probleme sind, warum man diese Phasen zu wenig oder gar nicht macht.

Objektorientierte Analyse

In der Analysephase ist die wichtigste Frage WAS? Es geht darum herauszufinden, wer WAS tun kann.

Als Ausgangslage existiert meistens ein Pflichtenheft (entweder schon vorhanden oder mit dem Kunden zusammen erstellt).

Nun gilt es ein OOA-Modell zu erstellen (z.B. mit UML2), hier ist folgendes wichtig:

  • Erstellen logisches, korrektes und funktionierendes Modell
  • Beliebige Systemressourcen (CPU, Memory, Datenbank etc. ist unendlich verfügbar) -> keine Performancegedanken
  • Systemressourcen werden nicht definiert (z.B. nicht definieren, ob Daten in einer DB oder in einem File gespeichert wird)

Einfach zusammengefasst kann gesagt werden, dass man mit dem Kunden so wenig wie möglich, aber soviel wie nötig definieren muss. Würde man beim Kunden über Datentypen, eingesetzte Technologien, gerichtete Assozationen diskutieren, würde die Analysephase ewig dauern und die Zeit beider Parteien wird verschwendet.

Man muss die Domäne des Kunden verstehen und mit ihm ein gemeinsamen Wortschatz bilden. Häufig wird ja vom Kunden sehr schnell eine Offerte erwartet. Nach der Analysephase sollte dies nun möglich sein, darum sollte diese Phase auch kurz gehalten werden.

Objektorientiertes Design

In der Designphase ist die wichtigste Frage WIE? Also WIE wird was aus der Analyse umgesetzt.

Die Modelle aus der Analysephase werden übernommen und nun verfeinert. Die Entwickler können sich in ihr stilles Kämmerlein setzen und über folgende Punkte diskutieren:

  • Logische und physische Architektur
  • Detailliertes GUI Design

Häufig wird nicht das ganze System durchdesignt, sondern nur aktuell relevanten Teile davon. Folgender stark vereinfachter Ablauf wäre denkbar. Design Komponente 1, Umsetzung Komponente 1, Design Komponente 2, Umsetzung Komponente 2, …

Objektorientierte Implementation

In dieser Phase wird logischerweise die Planung in realen Code umgesetzt.

Warum wird OOA, OOD vernachlässigt?

In diesem Abschnitt versuche ich zu beschreiben, warum objektorientierte- Analyse und Design vernachlässigt wird.

Erfahrung, Rollen der Teammitglieder

Softwareentwickler mit weniger Erfahrung neigen dazu lieber in die Tasten zu hauen, als zu planen. Der Softwareentwickler hat allgemein das Gefühl, wenn er Diagramme zeichnet, nicht soviel arbeitet bzw. nicht so produktiv ist, wie wenn er am programmieren ist. Gibt es in einem Team viele unerfahrene Entwickler und andere Rollen sind nicht genügend abgedeckt (z.B. Software Architect, Requirements Engineer, Senior Software Engineer, …) dann besteht die Gefahr, dass genau diese wichtigen Phasen vernachlässigt werden.

Zeitdruck Kunde

Macht ein Kunde ordentlich Dampf und verlangt in unmenschlichen Fristen ein Angebot, neigt man dazu die OOA zu vernachlässigen, vorallem wenn man auf den Kunden angewiesen ist. Dadurch steht das Projekt schon von Anfang an unter einem schlechten Stern. Man ist quasi von Anfang an unter Druck und macht wieder den gleichen Fehler. Man überspringt die “unwichtigen” Dinge und fängt an zu programmieren.

Synchronität der verschiedenen Phasen

Eine weitere Begründung für das Weglassen von OOA oder OOD ist die Problematik der Synchronität der Dokumente. Nehmen wir an, dass die ganzen Phasen ordnungsgemäss durchlaufen wurden, besteht immer das Problem, dass Designänderungen im Code unter Umständen nicht in die Analyse oder die Designdokumente übertragen werden.

Fazit – Warum ist OOA, OOD essentiell für die Entwicklung

Ohne OOA, OOD ist es heutzutage schwierig überhaupt noch gute Software zu entwickeln.

In der OOA lernt man den Kunden zu verstehen. Wird diese Phase übersprungen, werden die Probleme später kommen oder man redet ständig aneinander vorbei. Auch unausgesprochene Anforderungen werden vom Kunden jetzt gefordert – “Aber für uns war das klar, dass dies auch dazu gehört!”.

In der Designphase wird der Grundstein für die Architektur gelegt. Man ist noch nicht so im Detail, dass man sich darin verlieren kann und evtl. wichtige Punkte übersieht. Ausserdem sind Diagramme bzw. Bilder viel sprechender als Berge von Klassen. Mitarbeiter, welche neu ins Projekt kommen, verstehen den Aufbau viel schneller, als im Sourcecode.

Ein gewichtiges Argument gegen die Modellierung, nämlich die Synchronisation der verschiedenen Dokumente, möchte ich zum Schluss noch erschlagen. Es gibt heutzutage viele gute Tools, mit welcher sogenannte MDA (Model Driven Architecture) gemacht werden kann. Sprich, es kann Forward- und Reverse Engineering von UML -> Code / Code -> UML gemacht werden. Somit sind alle Diagramme und Sourcecode Einheiten zu jedem Zeitpunkt aktuell.

2 Responses

  1. Guter artikel.. ich krieg nur die Krise mit 4D.. da ist nix mit “OOA” und “OOD”.. da kannste gerademal “A” und “D” machen.. schon das höchste der Gefühle :-((((

Leave a Reply

Your email address will not be published. Required fields are marked *