Warenautomat – Teil I – Objektorientierte Analyse

Unglaublich aber wahr, in der Schule dürfen wir einen Warenautomaten programmieren 🙂

Bevor aber etwas programmiert wird, geht es zuerst einmal in die Analyse. Wie schon in einem früheren Artikel erwähnt, ist es wichtig zuerst die Anforderungen des Kunden zu verstehen und diese in einem Model abzubilden. Wie sich manch einer denken kann, ist dies gar nicht so einfach.

Im folgenden Artikel möchte ich beschreiben, wie die Vorgänge in der Gruppe waren und was zu Schwierigkeiten geführt hat.

Phase 1 – Die ersten Schritte

Unsere Gruppe bestand aus 3 Personen und als erstes machten wir uns daran die Kundenspezifikation zu studieren. Wir konzentrierten uns zuerst auf das Klassendiagramm. Wir erarbeiteten das Diagramm mit folgenden Schritten:

  • Suchen nach Klassen
  • Suchen nach Beziehungen zwischen Klassen
  • Suchen nach Attributen und Operationen

Schon nach kurzer Zeit hatten wir Diskussionen über irgendwelche Implementationsdetails, welche für die Analysephase überhaupt nicht wichtig sind. Auch gab es Meinungsverschiedenheiten, weil bei einem Entwicklerego stets seine Meinung die beste ist.

Nach dem ersten gemeinsamen Abend, machten wir uns also daran jeweils alleine das Klassendiagramm fertig zu stellen. Aus diesen 3 Erzeugnissen sollte dann später wieder ein Klassendiagramm gemacht werden, einfach mit den jeweils besten Varianten.

Phase 2 – Die Überarbeitung alleine

Ich arbeitete also alleine am Klassendiagramm für den Warenautomaten weiter. Die grössten Schwierigkeiten waren folgende:

  • Verstehen der Anforderung des Kunden
  • Wo platziere ich Attribute für die Datenhaltung
  • Wie detailliert soll die Analyse sein?

Phase 3 – Das Zusammenführen

In Phase 3 des Miniprojekts galt es, die 3 Klassendiagramme zu einem zusammenzuführen. Es war doch überraschend, wie unterschiedlich sich die 3 Diagramme entwickelt habe, obwohl wir die gleiche Ausgangslage hatten.

Fazit

Was überraschte war, dass die grössten Schwierigkeiten in der Zusammenarbeit lagen. Dies hat wohl damit zu tun, dass man häufig denkt, man selber sei am schläusten, die eigene Meinung sei am wichtigsten usw. Hier noch einmal die wichtigsten Schwierigkeiten aufgelistet:

  • Alle 3 Meinungen, Ansichten vereinigen (Aus 3 Varianten muss 1 gemeinsame Lösung erarbeitet werden)
  • Sich nicht auf Design/Implementationsebene begeben (Das Modell muss nur logisch korrekt sein und sowohl für den Entwickler als auch für den Kunden verständlich sein) -> Designfragen klären verschwendet Zeit
  • Anforderungen verstehen und in einem Model logisch korrekt abbilden

3 Responses

  1. Hätte auch gedacht, dass das Mergen von 3 verschiedenen Varianten am aufwendigsten ist. Sehr interessant zu sehen wie aus einer Kundenspezifikation so unterschiedliche Klassendiagramme erstellt worden sind. Ich weiß noch nicht ob ich die Vorgehensweise gut finden soll oder ob es zeitsparender gewesen wäre, gemeinsam ein Klassendiagramm zu erarbeiten. Jedenfalls ein spannender Ansatz!

  2. Es ging dabei auch nie um Effizienz. Wir müssen ja alle das modellieren lernen und daher haben wir uns entschieden, dass wir den 2. Teil alleine machen um die Unterschiede dann zu besprechen.

    Wenn man etwas zusammen macht, besteht jeweils die Gefahr, dass die Person mit der meisten Erfahrung oder dem grössten Durchsetzungsvermögen die Stossrichtung vorgibt und dadurch die anderen beim Lernprozess zu kurz kommen.

Leave a Reply

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