Hi Lars,
hat Dich der Thread zum mitmachen animiert
Freut mich, also will ich meine nächsten 9ct auch noch loswerden... Dazu würfle ich Deine Sätze ein wenig durcheinander, so daß es mir passt
Ausserdem greife ich immer wieder auf ModelMaker zurück, da ich mit dem Tool seit einigen Jahren arbeite. Es soll aber nicht heißen, daß es nicht vielleicht bessere Tools gibt.
Zitat von
LarsMiddendorf:
Mich würden da mal Meinungen aus dem täglichen Alltag von Softwareentwicklern interessieren
Dann mache ich mal den Anfang
Zitat von
LarsMiddendorf:
Gibt es da vielleicht einen sinnvollen Mittelweg.
Ja, ich glaube schon. Aber ist dieser für jedes Projekt etwas anders. Soll es nur mal schnell ein Utility sein, welches sich einer speziellen Aufgabe widmet, keinen Schnick-Schnack bieten soll, dann wird man oft wohl komplett ohne
UML auskommen. Nicht jedoch, ohne einen festen Plan. Manchmal mag es reichen seich das Ziel zu merken (
lösche alle Dateien die "$$$*.*" entsprechen), aber sich dieses zu notieren wird nicht schaden
Sollte es etwas mehr sein (
lösche alle Dateien auf allen Rechnern im Netzwerk die "$$$*.*" entsprechen und älter als eine Woche sein), dann sollte man sich zumindest schon einmal etwas Gedanken machen, ob man da nicht vielleicht ein, zwei Klassen (Netzwerksuche, Dateifilter, ...) entwickeln kann, welche man später in anderen Projekten wiederverwenden kann. Diese sollte man dann vielleicht schon in einem
UML-Tool (z.B. ModelMaker) erstellen und gleich dokumentieren. Warum?... ein paar Zeilen später.
Zitat von
LarsMiddendorf:
Ist es überhaupt möglich ein größeres Programm komplett zu planen und dann erst umzusetzen?
Kommt wohl wieder auf die Größe an, aber ist das denn nötig? Nehmen wir mal ein größeres Softwareprojekt, wie es in meiner Firma zur Zeit läuft. Planungs- und Umsetzungszeitraum ca. 18 Monate.
Zitat von
LarsMiddendorf:
Wie detailliert sollte der
UML Entwurf sein?
Der erste Entwurf sollte
gar keine Details enthalten. Wie auch, man muss ja erst einmal eine Idee aufs Papier bringen (
MindMap Diagram). Darin sollte man erst einmal alle Ideen, Erfahrungen, Gedanken, Wünsche,
Kundenvorschläge , etc. notieren. Dann kann man anfangen sich Gedanken zu machen, was aus den Ideen genutzt wird, was warten kann und was man gar nicht braucht oder will.
Wenn man die Komponenten (oder Utilities, Teilprogramme, Funktionen, etc.) der ersten Stufe festgelegt hat, dann sollte man sich anschließend auch daran halten, damit man später nicht vom Weg abkommt.
Nun geht es ans erste Design. Man schaut welche Komponente welche Teilbereiche hat. Diese hält man dann wieder fest. Und spätesten jetzt sollte man sich auch im Klaren sein, was die Komponenten miteinander tun sollen (nicht das wie!) Auch sollte man schauen, ob man evtl. Dinge beachten muss, die die zurückgestellten Komponenten später benötigen, um sich in das Gesamtprojekt zu integrieren.
Zitat von
LarsMiddendorf:
Wenn man direkt alle Felder und Methoden einträgt, dann hat man ja im Prinzip keine höhere Abstraktionsebene als wenn man es direkt programmiert?
Jetzt kann man anfangen für jede einzelne Komponente eine Lösung zu ermitteln und diese in Klassen aufzuteilen. Wenn man diese Klassen hat muss man anfangen zu ermitteln, wie diese untereinander kommunizieren und welche Schnittstellen es gibt. Das alles sollte
imho noch im Diagramm geschehen. Hier verlasse ich meistens die Diagrammebene und gehe später in den Code-Editor von ModelMaker. Das hat den Vorteil, daß ich später den Code wieder auf Diagrammebene "zaubern" kann. *break, mehr zum weiteren Weg kommt gleich...*
Zitat von
LarsMiddendorf:
Kann man alle Probleme komplett voher überblicken, so daß die tatsächliche Umsetzung dann auch elegant ist
Komplett - bestimmt, aber man braucht nur den IQ von Einstein + 200, die Intuition aller Frauen zzgl. der Gabe in die Zukunft der Kundenwünsche zu schauen
Nein, ich glaube nicht. Aber man kann sich auf viele vorbereiten und offen planen, so daß man später nicht alles wieder umstoßen muss, nur weil der Kunden gerne Icons hätte und das ja auch sinnvoll ist.
Zitat von
LarsMiddendorf:
oder geht man teilweise wieder einen Schritt zurück zur Planung?
Ja! Wenn man merkt, daß es happert, dann sollte man nicht einfach eine Lösung an Ort und Stelle bauen. Das ist zwar meistens schnell gemacht, aber bei Projekten mit Größen von mehreren 1000 A4 Code ist das auch gefährlich. Keiner kann mir erzählen, daß er/sie dann noch die Hand ins Feuer legen würde, wenn die Änderung auch andere Stellen betrifft. Also lieber zurück zum Reißbrett und versichern, daß es passt. Änderung dort eintragen und erst dann(!) implementieren.
Zitat von
LarsMiddendorf:
Oder ist es eventuell sinnvoller immer inkrementell Teile des Programms zu planen und direkt umzusetzen und zu testen?
Teile eines Programmes - was sind diese? Andere Programme, dann ja! Oder doch nur eine
Unit - hm, macht man doch eh, oder arbeitest Du an 6 Units gleichzeitig
!weiterlesen!
Zitat von
LarsMiddendorf:
Was ist besser beim Softwareentwurf: Top-Down oder Bottom-Up?
Wie an den jetzigen Ausführungen merkst, gibt es keine eindeutige Antwort. Ich verfolge beide Wege gleichzeitig. Erst einmal Top-Down: Was will ich am Ende sehen und was soll es können. Danach jedoch strikt Bottom-Up: Ich weiß jetzt, was jede Komponente tun soll und auch etwa welche Klassen drinne sind. Jetzt stricke ich jede Lösung durch Lösung ihrer kleinen Probleme zu einem Gesamtwerk, welches hoffentlich auch hält
Zitat von
LarsMiddendorf:
Muß man für jede kleine Klasse ein Diagramm anlegen, die man doch schneller direkt programmieren könnte?
Bei mir: ja
Na gut, fast. Da nicht jede Klasse im Diagramm auftaucht, aber jede Klasse existiert in ModelMaker um evtl. bei Bedarf im Diagramm zu landen
Warum denn? Na ja, wenn es ohne ModelMaker so viel schneller geht, dann werde ich nicht sofort wiedersprechen. Es ist bestimmt einfacher die Klasse mal schnell in Delphi einzutippen. Na gut, mache ich auch, aber im Anschluß importiere ich diese nach ModelMaker und dokumentiere diese auch. Anschließend erstellt ModelMaker mir mein RTF welches ich zu einer HLP-File als Doku kompiliere.
Warum? Einfach, ich kann jetzt víer Wochen/Monate später zurück kommen, schnell in die Doku schauen und den Fehler beseitigen oder vielleicht eine neue Funktion einfügen. Tools wie ModelMaker beiten einfach einen besseren Überblick über die einzelnen Strukturen, Beziehungen und Aufgabenlösungen.
Zitat von
LarsMiddendorf:
Behindert man sich dadurch nicht selber?
Anfangs dachte ich es auch, aber inzwischen liebe ich diesen Weg, da der auf Dauer immer schneller ans Ziel führt als noch einmal durch 5000 Zeilen Code zu springen, um sich die Beziehungen unter 3 Klassen anzuschauen.
Abschluß
Mit ModelMaker verwalten wir die aktuelle Version unserer Software (zumindest den Delphi-Teil) von Beginn an, importieren meist auch 3rd Party Codes, damit diese besser verständlich werden und noch behalte ich den Überblick über mehr als 7 MB Delphi-Quellcodes, 2 MB
XML Definitionsdateien, 3 MB ASP Quellcodes und fast 3 MB Hilfedateien (ohne wirklichen Inhalt
)
...
...