Hallo zusammen,
ich würde mal gerne eure Vorgehensweisen erfragen, wenn ihr neue
Projekte angeht.
Zu dem Hintergrund:
Ich programmier gerade Software-Paket, für Mikrocontroller in C und .NET
in Basic und Java. Alles für das gleiche Projekt. Es handelt sich um ein
größeres Projekt mit mehreren selbstdefinierten
Kommunikationsprotokollen. Ich selber programmier schon was länger (5-6
Jahre) auch größere Sachen. Auf PC-Basis Objektorientiert und mit C
soviel es geht :D
Jetzt steh ich aber manchmal vor dem Code und weiss einfach nicht, wie
ich weiter machen soll.
Wie macht ihr das? Weil Flussdiagramme meiner Meinung eher ungeeignet
sind (mit Ausnahme Mikrocontroller) und UML-Diagramme zwar die Objekte
wiedergeben, aber eher weniger wie die Software interagieren soll.
Also würde mich freuen, wenn ihr mal berichtet, wie ihr das so macht?
Gruß
Frank
Vor meinem Schreibtisch steht ein Flipchart (Whiteboard wär noch
besser...) und ich zeichne für Komplexere Algorithmen und Abläufe immer
Flussdiagramme. Erst wenn ich das Flussdiagramm fertig hab und wenn
möglich mit jemand anderem besprochen, dann erst mach ich mich an die
Implementierung.
Bei Objekten notiere ich mir meistens was ich von der Klasse erwarte,
wie ich erwarte die in meinem nächsten Programmverlauf zu verwenden
(sprich Interfaces definieren), ... private Methoden und Variablen
kommen dann während des Programmierens einfach so dazu, über das äußere
Erscheinungsbild mach ich mir vorher Gedanken. Wird dann leider öfters
mal "außen hui, innen pfui.."
Sind die Schnittstellen definiert, erstelle ich die Klasse mit den
Schnittstellen, die bleiben aber vorerst leer.
Danach schreibe ich (ab und zu auch innerhalb der Klasse) eine
Testfunktion, die Soll- und Fehlfunktionen testet und in einer Übersicht
printed (Test bestanden, Test nicht bestanden). Sprich einfach unit
testing..
Ist der Test fertig, implementiere ich die Funktion der Klasse.
Ich muss aber zugeben, dass das eher eine theoretische Vorgehensweise
ist, fällt mir oft schwer sie exakt einzuhalten, aber mit der hab ich
bis jetzt am wenigsten Fehler übersehen.
Am uC - wenn er von außen gesteuert wird - am besten auch schonmal
Testszenarien vordefinieren (Tasten drücken, bestimmte Befehle schicken,
wild auf der Tastatur hämmern, ...) und auch das erwartete Verhalten
festlegen. Nach Fertigimplementierung dann diese vorher erstellte
Beschreibung abarbeiten und validieren...
ALso ich mach das immer so
1. Anforderungen Definieren
Wichtig weil man sonst nicht weiß was man überhaupt zum Schluss haben
will
2. Layer definieren
welche ebenen hat man
-logisch
-darstllung
-datenhaltung
3. Architektur erstellen (Klassendiagramm)
nicht immer einfach, je gründlicher desto einfacher die umsetzung
4. Modell in Module zerlegen
meinst wie layer evtl mehr je nach Komplexität
5. Schnittstellen definieren
so weiß jede seite das es von der anderen zu erwarten hat
6. Ablaufdiagramme erstellen
wird meist erst hinterher zur Übersichtlichkeit gemacht. grundlegendes
sollte aber schon vorher definiert sein.
7. Hauptprogrammierarbeit
8. Testen
Wenn man 1-6 vorher erledigt hat sehe ich keinen punkt wo man nicht
weiter wissen sollte außer man hat das problem noch nicht ganz
verstanden.
An welcher stelle kommst du denn nicht weiter?
>Jetzt steh ich aber manchmal vor dem Code
Einfach den Standpunkt wechseln.
Wenn du vor lauter Code den Wald nicht siehst einfach was anderes
anschauen. Wie von Sebastian vorgeschlagen Anforderungsliste,
Modulstruktur, Oberfläche, Datenstrukturen oder einen anderen Aspakt
betrachten.
Manchmal erkennt man Sackgassen im Code wenn man die Widersprüche in den
Anforderungen betrachtet. Manchmal sieht man unrealisierbare
Anforderungen, wenn man im Code wühlt.
Frank schrieb:> mit mehreren selbstdefinierten> Kommunikationsprotokollen.
Wenn irgendwie möglich, greife ich bei einem Protokoll auf was
vorhandenes zurück. Das hat den Vorteil, das es Messgeräte dafür gibt
und evtl. sogar schon Software. Wenn das bei dir nicht geht, schade.
Pico Oschi schrieb:> Ich hab mal einen Simulator fuer eine Zusatndmaschin geschrieben. Auf> Controllern arbeit ich immer mit Zustandsmaschinen.
...wow!
Der Controller ist eine Zustandsmaschin' :)
Nun ja, bei Menüstrukturen lohnt es sich, soetwas zu implementieren, da
es einem mehr Übersicht gibt und die Wartbarkeit steigt. Vor allem der
Übergang von UML nach Code gestaltet sich da leichter.
mfg mf
Wow. Die meisten hier scheinen ja die Software wie im Lehrbuch zu
schreiben.
Also ich hab festgestellt, oft ist die Software nicht besonders
kompliziert. Alles schon hundert mal programmiert. Da kann man sich
einen Entwurf sparen und muss nur schauen, aus welchen alten Projekten
man Code wiederverwenden kann.
Bei komplizierten Sachen überlebt der Entwurf meist nicht sehr lange,
gerade wenn er sehr detailliert ist. Irgendwas vergisst man beim Entwurf
immer oder es funktioniert dann nicht wie geplant.
Ich geh deshalb eher pragmatisch ran. Ich verlasse mich auf mein Gefühl,
frag mal Kollegen, wie die das machen würden und ich schreib Prototypen.
Aus dem Prototypen kann man dann relativ einfach ein schönes Programm
machen.
Bei mir geht es gar nicht darum, dass ich zu einem konkreten Problem
eine Frage habe. Lediglich habe ich Interesse daran meine
Softwareentwicklung zu verbessern.
Ich mache nämlich eigentlich alles im Kopf, vom Konzept bis zur
Realisierung. Und das ist irgendwann extrem anstrengend alles im Kopf zu
behalten. Allerdings weiss ich zu Beginn meißt nicht, wie facettenreich
mein Programm wird, deswegen ist es schwer dort schon eine Struktur zu
implementieren.
Ich bin ein ähnlicher Programmierer wie mein Vorredner. In alten
Projekten gucken und soviel wie möglich in Sinnesabschnitte (Objekte,
Module, INterface) zu verpacken
Frank schrieb:> Weil Flussdiagramme meiner Meinung eher ungeeignet> sind (mit Ausnahme Mikrocontroller)
Flußdiagramme sind so ziemlich das Unübersichtlichste was es gibt. Auch
ein µC macht da keine Ausnahme - es sei denn, du bist ein "Goto"-Fan.
IMHO bekommt man mit Nassi-Shneiderman-Diagrammen eine wesentlich
bessere Strukturierung in Funktionsblöcke, die sich auch vernünftig
überprüfen läßt.
Na ja, der einzige vernünftige Tipp ist da wohl:
Sobald man die Struktur nicht mehr überblickt wegwerfen und neu machen.
Geht schneller als man denkt.
Und Konzepte unbedingt mit Bleistift und Papierkorb machen. Vor den
perfekten Ausdrucken der Tools hat man viel zu viel Respekt; sieht
nicht, das die ganze Idee in einer Sackgasse endet.
Einfach mal zurücktreten. Schauen wo die Unübersichtlichkeit begann.
Das Wichtigste bei der Controller Software Entwicklung : Debugging ist
Teil des Prozesses, und nicht eine Feuerloeschuebung falls es wider
Erwarten nicht tun sollte. Man muss das Konzept und den Aufbau bereits
debugbar planen. Die serielle Schnittstelle muss Debugcode verarbeiten
koennen, das Protokoll muss Debugcode verarbeiten koennen. Falls die
serielle Schnittstelle schwieriger als sonst ist, eine zweite
Schnittstelle einplanen. Daher lieber den Mega644, wie den Mega32.
Wenn's dann laeuft kann man den Mega32 einsetzen, er ist pinkompatibel.
Den SPI Bus mit Vias versehen, sodass man die Scopeproben einstecken
kann. Echtzeitdaten per externem DAC sichtbar machen. Ein Scope kann
dann den Prozess transparent darstellen.
Pico Oschi schrieb:> ...
Ich glaube das zu erzählen bringt nichts. Das muss jeder selbst
irgendwann einsehen ("Beim nächsten mal, mache ich das /anders/").
;-)
Frank schrieb:> Ich programmier gerade Software-Paket, für Mikrocontroller in C und .NET> in Basic und Java. Alles für das gleiche Projekt.
O ha. Du machst simultan in C, Dotnet, Basic und Java? Kann ich nicht
empfehle, man kommt nur durcheinander.
Bei mir sieht das ganz anders aus: Da ich jedesmal sowohl die Hardware
als auch die Software dazu mache, seh ich zuallererst vor, mit der
soeben aufgebauten Kiste irgendwie flott zu kommen, also erstmal ein
Kaltstartcode und dann ein Minimalst-Monitor, dann all das, was man an
I/O braucht, zuallererst simpel per Polling, dann gepuffert, dann kommt
sowas wie ne Event-Behandlung dazu und dann ist es Zeit, auf dieser nun
schon benutzbaren Basis das aufzubauen, was man eigentlich braucht. Und
das denk ich mir mit Bleistift und Papier aus. Aber sowas wie PAP,
Flußdiagramme usw. mache ich nur für Detailprobleme, niemals für's
Ganze. Viel wichtiger ist es, sich die Protokolle genau zu übelegen, mit
denen die verschiedenen Teile der Kiste miteinander kommunizieren
sollen, bevor man die erste Zeile des "Nutzinhaltes" schreibt.
W.S.
0) Eine Liste von Anforderungen definieren (grob a la "Der Benutzer kann
mit der PC-Software eine LED am uC einschalten.", keine
Implementierungsdetails)
1) Ein paar wenige Features von der Liste aussuchen und festlegen, wann
diese als erfüllt gelten (einfache Testfälle). Evtl. ein paar
Ablaufdiagramme etc. zeichnen.
2) Nur diese soweit implementieren, dass die Testfälle erfüllt werden.
Noch nicht zuviel verallgemeinern, Hauptsache es läuft.
3) Wenn die Liste abgearbeitet ist, refactoren, aufräumen, Funktionen
verallgemeinern/auslagern. Die Testfälle müssen natürlich hinterher
immer noch erfüllt werden. Ggf. Flussdiagramme und Doku zum
geschriebenen Code erstellen und die Pläne aus 1) dem tatsächlich
geschriebenen Code anpasssen. Keine Angst haben, Code
wegzuwerfen/neuzuschreiben.
4) Wenn es bei 3) nichts mehr zu verbessern gibt, wieder zu 1) springen.
Schritt 3 ist der wichtigste, sonst kommt man irgendwann nicht mehr
weiter.
Alle halbwegs komplizierten Projekte wachsen langsam, deshalb sollte man
so ehrlich sein, den Entwicklungsprozess darauf anzupassen und sich
nicht a la Wasserfallmodell in die Tasche lügen ;)
Tom K. schrieb:> 0) Eine Liste von Anforderungen definieren (grob a la "Der Benutzer kann> mit der PC-Software eine LED am uC einschalten.", keine> Implementierungsdetails)
Genau das halten viele nicht fest sondern nur im Kopf und man verliert
schnell den Fokus auf das Wesentliche.
Noch schlimmer ist es wenn Anforderungen vergessen werden.
Tom K. schrieb:> 3) Wenn die Liste abgearbeitet ist, refactoren, aufräumen, Funktionen> verallgemeinern/auslagern. Die Testfälle müssen natürlich hinterher> immer noch erfüllt werden. Ggf. Flussdiagramme und Doku zum> geschriebenen Code erstellen und die Pläne aus 1) dem tatsächlich> geschriebenen Code anpasssen. Keine Angst haben, Code> wegzuwerfen/neuzuschreiben.
Gerade das machen viele zu spät bzw gar nicht.
Das macht weiteres vorgehn echt schwer
Ich persönlich finde es wichtig solche Konzepte auch im privaten zu
"üben" und zu verbessern.
Hallo !
Ich finde jeder muss selbst für sich richtig entscheiden können welche
Tools und Vorgehensweisen man im Softwareentwicklungszyklus verwendet.
Jedoch an manche Grundlagen sollte man sich schon halten. -> Die
Lehrbücher lügen nun mal auch nicht.
L.g.
