8. April 2007, 16:50, by Silvan Mühlemann

Textanalyse: Der erste Schritt zum OO-Design

Forscher

Als ETH-Betriebs- und Produktionsingenieur (Grundstudium Elektrotechnik) weiss ich, wie man triviale Sachverhalte in komplex wirkenden PowerPoint-Slides darstellt. Von sauberem OO-Design wurde mir hingegen nichts beigebracht. So kam es, dass die erste tilllate-Version vom Jahr 2000 aus 30 PHP3-Skripten à je 2000 Zeilen aufgebaut war.

Zum Glück war ich von 10 bis 16 ein Ober-Geek und verbrachte vor dem C-128D und Amiga, währende andere auf dem Fussballplatz oder am ZSC Match waren. Zum Glück: Denn trotz 2 Jahren Consulting-Ausbildung blieb noch ein kleines bisschen PC-Affinität übrig. Ich lernte schnell, dass der PHP3-Spaghetti-Code von damals weder wart- noch ausbaubar war.

"OOP, dass muss es sein", dachte ich mir – das war im Jahr 2003. Und baute mein erstes Skript. "OO Style": Ich fügte also einem bestehenden 2000-Zeilen-Elefant das Schlüsselwort "class Fotoalbum" hinzu. Den bestehenden Code packte ich eine einzige Methode "Fotoalbum". Juhui! Ich bin ein OO-Guru!

 
class Chat
{
	function Chat()
	{
	    // die 2000 Zeilen Gammelcode
	}
}

Nun, ziemlich schnell merkte ich, dass dieser Code nichts mit Objektorierung zu tun hatte. Da kann ich noch so viele class oder new-Statements verwenden.

Objekte identifizieren

Jetzt, sieben Jahre später, dank phpArchitect, Martin Fowler und ein paar gute Angestellten habe ich dazugelernt. Zugegeben, ich erachte mich noch immer nicht als der Hirsch in der OOP. Für das habe ich einen zu grossen Anteil Management-Tasks in meinem Arbeitsalltag.

Dennoch muss ich ab und zu ein Objektmodell aufbauen. Hier hat sich für mich folgende Methode bewährt:

Die wichtigste Frage: Welches sind meine Objekte? Was ist deren Zuständigkeit?Hierzu formuliere ich meine Aufgabe in Prosa:

Der tilllate Chat besteht aus mehreren Chatrooms. Als Member kann man in einem oder mehreren Chatrooms sein. Wenn man eingeloggt ist, erscheint man in einer Memberliste. Die Member posten Mitteilungen in einen Chatroom..

Aus dieser Prosa leiten sich gleich meine Objekte ab:

Der tilllate Chat besteht aus mehreren Chatrooms. Als Member kann man in einem oder mehreren Chatrooms sein. Wenn man eingeloggt ist, erscheint man in einer Memberliste. Die Member posten Mitteilungen in einen Chatroom.

Im Objektmodell müssen also folgende Objekte berücksichtigt sein:

  • Chat
  • Chatroom
  • Member
  • Memberliste
  • Mitteilung

Beziehungsfragen

Beziehungen unter den Objekten lassen sich auch aus dem Text herauslesen: "Der Chat besteht aus mehreren Chatrooms". Somit hat es wohl im Objekt "Chat" ein Array von Chatroom-Objekten.

class Chat
{
	private $a_chatrooms=Array();
	//...
}

Ebenfalls aus der Textanalyse rausziehen lässt sich die von den Objekten angebotenen Methoden: "…schreiben Mitteilungen in einen Chatroom" führt zu folgener Methode bei der Member-Klasse.

class Chatroom
{
	public function postMessage(Message $o_message)
	{
		// ...
	}
}

Die aus dem Text extrahierten Informationen zeichne ich dann – auf Papier oder mit einem Tool wie Visual Paradigm auf. (Dies drucke ich dann aus und hänge es im Office hinten an die Wand, um die Damen von der Marketingabteilung zu beeindrucken :-)

UML Beispieldiagramm

So trivial dies tönt: Die Analyse der Texte hat mir geholfen, meine Applikationen besser zu strukturieren. Denn dadurch ist die Software näher bei der echten Welt und dadurch auch einfacher zu begreifen. Kommen die Mitteilungen beim Member nicht an, muss beim Objekt Member oder Mitteilung gesucht werden. Die Zuständigkeit der Objekte kann man sich leicht vorstellen. Man spürt sie regelrecht.

Textanalyse automatisieren

Die Methode der Text-Analyse wird übrigens auch von grossen $2000-Software-Engineering-Paketen angeboten: Der Anwender lädt das Word-Dokument mit den Requirements hoch. Die Software leitet daraus Hinweise für ein Objektmodell ab. Ich konnte das Feature nicht prüfen. Und ich bin etwas skeptisch: Dies wird wohl etwa so funktionierten wie das AutoZusammenfassen im Word: Das Feature macht sich auf der Verpackung gut, doch brauchen wird es niemand.

Die Idee dahinter hingegen finde ich gut. So komme ich schneller zu einem brauchbaren Objektmodell. Applikationen mit einer Klasse à 2 Methoden (mit je 1000 Zeilen) wird es bei mir nicht mehr geben.

Filed under: Programming

1 Comment

  1. So, mal noch ein wenig klugscheissern von meiner Seite. Die Methode zur Analyse des Domain Models ist ja schon fast nach Lehrbuch, mit dem würdest du dir vermutlich schon ein paar ECTS-Punkte im Informatikstudium holen.

    Das Domain-Model direkt ins Klassenmodel umzusetzen wird zwar häufig gemacht, kann aber verheerend sein. Nicht jedes Objekt aus dem Domain-Model der Textanalyse sollte automatisch in eine Klasse umgesetzt werden. Wird das gemacht entsteht “Code auf Vorrat”, dass kann zu Wartungs-Albträumen und Performance-Problemen führen. Deshalb sollte für das Klassenmodel nochmals überlegt werden welche Klassen wirklich Sinn machen.

    In deinem kleinen Beispiel wären diese Überlegungen zum Beispiel ob es wirklich eine “Message” braucht (oder ob es nicht einfach ein Text ist) oder ob es wirklich eine Memberliste braucht (oder ob hier ein Standard-Container ausreicht).

    Comment by http://leo.buettiker.org/ — 30. April 2007 @ 09:34

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

© 2017 tilllate Schweiz AG - Powered by WordPress