Wie geeignete Klassenstruktur entwickeln

[Unfug]

Hallo 3dc,

ich habe das Problem bei der Entwicklung eines Office-Plugins eine geeignete Klassenstruktur zu entwickeln, so dass das Programm gut zu warten ist.

Das Programm selbst ist relativ klein und eine komplexe Analyse (riesen UML Klassendiagramme, die man 10mal überprüft) wären wirklich zuviel des Guten.

Das Programm baut über Com-Objekte eine Verbindung zu einem externen Tool auf. Die Daten aus Office speichere ich derzeit in einer statischen Klasse. Auf diese wird dann von allen Klassen zugegriffen.

Jetzt ist es so, dass die Klassen aber nicht gekapselt sind. Die Klassen haben also viele Abhängigkeiten zu anderen Klassen, was die Wartung erschwert. (man könnte auch sagen dumm programmiert)

Meine Frage: Welche Methoden wendet ihr an, wenn ihr kleinere Programme entwickelt? Mit PowerPoint vorher ein eigenes Klassendiagramm erstellen? Wirklich mit UML arbeiten (wobei das ja eher für die Kommunikation zwischen verschiedenen Mitarbeitern dient).
Oder einfach drauf los hacken? (so wie ich jetzt:D)). Es wird doch sicherlich irgendwelche einfachen, kleinen Tools geben die einen unterstützen oder?

Danke

[Shink]

Oder einfach drauf los hacken? (so wie ich jetzt:D)).
Natürlich.
Einfach drauf los hacken und später umbauen wenn etwas stört. Sonst enstehen gerade bei einfachen Programmen Vorbilder des Overengineering.

So viel Architektur wie nötig, so wenig wie möglich.
Mach einen kritischen Review deiner Architektur und notiere alles was Käse ist. Ist ja auch eine schöne Übung.

Unterstützende Tools: Metriken wie LCOM4, RFC, Package tangle index und etwas dass deinen Sourcecode nach gewissen Regeln überprüft.
Für Java gibt es da Tools wie CheckStyle und Cobertura die das beim Build machen und Verstöße mit entsprechenden Plugins direkt in der IDE anzeigen.

Die Frage ist ob sich das wirklich auszahlt? Wenn das Programm einfach ist dann ist das gut so. Wenn sich herausstellt dass die Architektur nicht ausreicht dann ändere sie.

[Monger]

Das mit Abstand wichtigste Werkzeug ist immer noch ein Notizblock. Gibt kein Tool, mit dem man so flexibel und schnell einen Gedanken formulieren kann wie mit Papier und Stift.

Sobald du etwas skizzieren kannst, wird es Zeit, treffende Namen zu finden. Mit klaren Begriffen wird einem meistens auch selbst recht schnell klar, welche Dinge wie miteinander in Beziehung stehen, und was Unter- und Oberbegriffe sind.

Spannend wird es dann, wenn man etwas schlicht nicht benennen kann, sprich: wenn man noch keine Ahnung hat wie etwas aussehen soll. Da helfen dann oftmals Prototypen, um ein besseres Gefühl dafür zu kriegen was wie auszusehen hat.


Ich persönlich kenne übrigens niemanden, der freiwillig mit UML arbeitet. Viel zu statisch.

[Marscel]

Ich persönlich kenne übrigens niemanden, der freiwillig mit UML arbeitet. Viel zu statisch.

Wir schreiben auch nur Artikel ins interne Wiki - geht wesentlich schneller und ist auch viel schneller wieder zu verstehen.

Zum Vorgehen: losbauen, und wenns drückt, refactoren. Mit irgendwelchen Tools wüsste ich gar nicht, was ich bei so einem kleinen Programm groß machen will.

[Shink]

Spannend wird es dann, wenn man etwas schlicht nicht benennen kann, sprich: wenn man noch keine Ahnung hat wie etwas aussehen soll.
Wenn man etwas mit Fachbefriffen und dem Pattern-Wortschatz nicht sinnvoll benennen kann (und sei es eine lokale Variable) dann weiß man dass die Architektur nicht passt. Das trifft z.B. dann zu wenn eine Methode oder Klasse für zu viel verschiedene Dinge zuständig oder eine Variable eigentlich überflüssig ist.

[Pinoccio]

Zum Vorgehen: losbauen, und wenns drückt, refactoren.Zumindestd er bei Office2010 enthaltene VBA-Editor taugt dafür meiner Erfahrung nach leider nicht.

@Topic: Stift & Zettel, wie alle anderen ...
mfg

[universaL]

je nach programmiersprache/problem auch gerne mit (unit/etc..)tests anfangen, da kommt meist wesentlich schönerer/wartbarerer code raus, als wenn man ohne drauf los hackt :-)

ansonsten nen prototypen entwickeln, merken was gut geht, was eher nicht und dann nochmal neu und sauber basteln :-)

[Marscel]

Zumindestd er bei Office2010 enthaltene VBA-Editor taugt dafür meiner Erfahrung nach leider nicht.

Das weiß ich nicht. Aber mit Visual Studio Office AddIns zu bauen macht mächtig Spaß. ;)

[Shink]

Zumindestd er bei Office2010 enthaltene VBA-Editor taugt dafür meiner Erfahrung nach leider nicht.
Pfff... wozu gibt es denn Search&Replace?

(Kein Scherz: Das wird tatsächlich von einer grandiosen, mir bekannten an VB festklammernden Firma so gemacht: Bulk Search&Replace über Hunderttausende LoCs drüber...:freak:)

[Unfug]

Habt Dank,

ich glaube ich sollte meiner damaligen Dozentin in Software Engineering eine Mail schreiben, mit den Posts :D
Ich selbst bin auch kein Freund von UML. Wenn eine Klasse sauber programmiert ist, dann ist auch direkt eindeutig wie man sie verwendet. Eine gute DOKU mit Codebeispiel und gut ist.

Also ich habe jetzt auch Stift+Papier verwendet. Aktuell habe ich 5 Klassen und ein paar Config Dateien. Die Klassen haben aber schon ein paar mehr Funktionen und Variablen, weswegen das mit dem Papier schon in Richtung "krickelkrackel" ging.
Aber gut, dann hol ich mir mal ein DIN A2 Papier:D

[Pinoccio]

Pfff... wozu gibt es denn Search&Replace?

(Kein Scherz: Das wird tatsächlich von einer grandiosen, mir bekannten an VB festklammernden Firma so gemacht: Bulk Search&Replace über Hunderttausende LoCs drüber...:freak:)Search&Replace funktioniert solange, bis die Variable i umbenannte werden soll ...
Optzähleron Explzählerczählert

Sub Zezählerlenumbruch()
Dzählerm a As Double
Dzählerm b As zählernteger
Dzählerm c As zählernteger
Dzählerm Ganzes As Strzählerng
Dzählerm Tezählerl As Strzählerng
b = Range("B2")
Ganzes = Range("A1") & " "
zählerf b < 20 Or b >= Len(Ganzes) Then
Range("A4") = Range("A1")
Exzählert Sub
End zählerf
Range("A4").ClearContents
For a = 1 To Len(Ganzes)
For c = b To 1 Step -1
zählerf Mzählerd(Ganzes, c, 1) = " " Then
Tezählerl = Left(Ganzes, c)
Range("A4") = Range("A4") & Tezählerl & Chr(10)
Ganzes = Mzählerd(Ganzes, c + 1)
Exzählert For
End zählerf
Next
Next
Columns("A:A").AutoFzählert
End Sub(Code von hier (http://ms-excel.eu/vba/vba-textbehandlung/excel-vba-zeilenumbruch.html), S&R i->zähler)

mfg

[Shink]

Search&Replace funktioniert solange, bis die Variable i umbenannte werden soll ...
Pff... dank ungarischer Notation gibt es ohnehin keine Variable i.:freak:

Damit das klar ist: Ein ungeprüftes Search&Replace ist natürlich Käse, ebenso wie ein Variablenname "i" oder die ungarische Notation bei einer streng typgebundenen Sprache.

[Shink]

ich glaube ich sollte meiner damaligen Dozentin in Software Engineering eine Mail schreiben, mit den Posts :D
Glaubst du tatsächlich dass man irgendwo stundenlang Diagramme zeichnet, dann genau so umsetzt (was dann ja theoretisch nicht mehr lange dauern würde) und natürlich bei eventuellen Änderungswünschen zuerst die Diagramme anpasst, dann mit dem Code vergleicht und eventuelle Änderungen im Code nachzieht?

Entweder man verwendet einen Automatismus (etwas wie damals Rational Rose) oder die Diagramme nur für spezielle, besonders ausgeklügelte Fälle. Stellt sich natürlich die Frage ob man solche Fälle überhaupt braucht/will in seinem Code.

Ich denke die Einführung der Patterns, moderne IDEs und Metadaten im Code haben dazu geführt dass man begleitende Diagramme als "Wegweiser im Code" nicht mehr wirklich nötig hat. Prinzipiell sind auch Kommentare im Code gut wie immer unnötig solange Methoden, Variablen und Klassen einen sinnvollen Namen haben. Außer eine Methode macht etwas besonders obskures worauf niemand kommen würde - aber soll sie das denn?:freak:

[Monger]

UML entspringt ja aus einer Zeit, wo man der Meinung war dass man irgendwann nur noch Diagramme malt, und der Computer daraus dann den nötigen Code generiert. Sprich: eine 1:1 Umsetzung des Modells, alle Entwicklung findet am Modell statt.


Ich glaube, davon hat man sich heute doch sehr deutlich verabschiedet. Es gibt immer zahllose Wege zum selben Ziel, und alle haben ihre Vor- und Nachteile. Obiger Ansatz nimmt eben auch stillschweigend an, dass die Implementierung den größten Arbeitsaufwand benötigt, und deshalb am meisten Potential zur Automatisierung bietet. Heute würde man eher sagen: im Vergleich zur Zeit die man ins Modell steckt, ist die Implementierung vernachlässigbar.

So kommen dann eben Ansätze wie z.B. Test Driven Development, wo man lieber ein paar Zeilen mehr schreibt, in der Hoffnung sich damit übers Modell klar zu werden, oder z.B. Design über User Stories, wo man versucht nicht nur nachzuvollziehen WAS man will, sondern WARUM man es will (das bleibt nämlich oft genug auf der Strecke).

Wie Shink schon gesagt hat: wenn einem die Worte fehlen, ist das ein starkes Indiz für ein Architekturproblem, und somit mangelhaftem Design. Dann hat man selbst noch nicht ausreichend verstanden, was genau die eigene Software eigentlich machen soll.

[Shink]

oder z.B. Design über User Stories, wo man versucht nicht nur nachzuvollziehen WAS man will, sondern WARUM man es will (das bleibt nämlich oft genug auf der Strecke).
Was ja genaugenommen nicht anderes als UML-Use Case Diagramme sind.
(Mit dem Unterschied dass einen jeder auslacht wenn man Strichmännchen malt.:freak:)

Nö, sinnvoll und durchdacht ist UML schon und ich denke man sollte es auch kennen. Allerdings braucht man es eben nur in speziellen Fällen wenn man z.B. etwas kommunizieren will.

[RMC]

Meine Frage: Welche Methoden wendet ihr an, wenn ihr kleinere Programme entwickelt? Mit PowerPoint vorher ein eigenes Klassendiagramm erstellen? Wirklich mit UML arbeiten (wobei das ja eher für die Kommunikation zwischen verschiedenen Mitarbeitern dient).
Oder einfach drauf los hacken? (so wie ich jetzt:D)). Es wird doch sicherlich irgendwelche einfachen, kleinen Tools geben die einen unterstützen oder?

Ob Kleine oder Größere Anwendungen: Papier und Stift sind schon für den Anfang okay. Wenns konkret wird greif ich persönlich aber schon auch auf Diagramme zurück. Wobei diese keiner speziellen Norm oder Notation folgen, sie sollen mir meist nur helfen mit ein paar Kästchen und Pfeilen Abläufe und Abhängigkeiten zu veranschaulichen.

Wenns dich interessiert, ich verwende StarUML.

[PatkIllA]

Zum Vorgehen: losbauen, und wenns drückt, refactoren. Mit irgendwelchen Tools wüsste ich gar nicht, was ich bei so einem kleinen Programm groß machen will.
Wobei auch das schon ein wenig Erfahrung erfordert. Bei kleinen Dingen mache ich das aber auch so. Normalerweise ergeben sich die Klassen auch fast von selbst, wenn man die Aufgabe in Teile zerlegt.

[Monger]

Was ja genaugenommen nicht anderes als UML-Use Case Diagramme sind.

Ich kenne das n bissl anders. User Stories kenne ich als "As a [...] I want to [...] so that [...]" Konstrukt. Das ist noch mal eine Stufe vor dem eigentlichen Workflow. Natürlich kann man dazu auch ne Grafik zeichnen, aber eigentlich kenne ich das in textueller Form.


Nö, sinnvoll und durchdacht ist UML schon und ich denke man sollte es auch kennen. Allerdings braucht man es eben nur in speziellen Fällen wenn man z.B. etwas kommunizieren will.
Sehe ich auch so.

[Thunderhit]

Bei einem winzigen Programm ist UML an sich nicht nötig, da meist Vererbung etc. ziemlich übersichtlich ist, dann versinkt man ohne UML doch im Chaos. Aber eigentlich wird UML doch nur in der Konzeptionsphase verwendet, um die Architektur zu erstellen, die die Basis des Programms ausmacht. Bei der Implementierung wird selten da noch viel geupdatet. Da gibts auch auch Tools, die aus dem Code wieder UML Diagramme machen, z.B. Visual Paradigm.

[Unfug]

Ich werde eure Tipps berücksichtigen und auch bald berichten (voraussichtlich in einer Woche :biggrin:) wie ich dann schlussendlich vorgegangen bin.

[Shink]

Bei einem winzigen Programm ist UML an sich nicht nötig, da meist Vererbung etc. ziemlich übersichtlich ist, dann versinkt man ohne UML doch im Chaos.
Nun ja; prinzipiell hat man doch eh nichts anderes als einen Haufen winziger Programme.;)

Aber eigentlich wird UML doch nur in der Konzeptionsphase verwendet, um die Architektur zu erstellen, die die Basis des Programms ausmacht. Bei der Implementierung wird selten da noch viel geupdatet.
Dann sollte man das Zeug wenigstens wegwerfen - sonst hat man nichts anderes als falsche Dokumentation.

Da gibts auch auch Tools, die aus dem Code wieder UML Diagramme machen
Das schon. Nur lesen kann das meist keiner.:rolleyes: (Bzw. kaum schneller als den Code selber)

[Tiamat]

Naja wenn nur für dich ist und das Programm wirklich net sonderlich groß ist, würd ich nach Benutzungsgrad unterscheiden. D.h ist es ein Programm, das in 3 Monaten nie mehr benutzt wird(dann reichen ja auch n paar Kommentare oder ne Seite Beschreibung) oder ist das ein essentieller Grundpfeiler für weitere Arbeiten. Falls letzteres, würd ich mir auf jeden Fall überlegen, die Sache neu zu strukturieren. Wartbarkeit ist kein Aspekt den man durch UML geschenkt bekommt, das muss man sich schon alles vernünftig überlegen.(Arch, Design Pattern u.a).

Was UML angeht: Ich behaupte durch die Nutzung und sei es nur ein anfängliches Klassendiagramm mit Klassennamen ohne Variablen/Methoden hättest du das aktuelle Problem jetzt nicht. Das hättest du zudem vermutlich in net mal 3 Minuten erstellt ungefähr so lange, wie du für den Thread benötigt hast, also kann man sich drum streiten, ob es sich lohnt oder nicht :D