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
:
Verschoben durch User
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...
Es gäbe da z.B. das Modellierungstool "Innovator" von MID aus Nürnberg. Ohne Werbung machen zu wollen.
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.
Ich hab mal einen Simulator fuer eine Zusatndmaschin geschrieben. Auf Controllern arbeit ich immer mit Zustandsmaschinen.
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.
Angehängte Dateien:
-
Software_dev.jpg
47 KB
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.
http://theaddictiveblog.com/software-engineering-classics-and-comics/ hier gibts noch mehr recht zutreffende comics auf manche softwareentwicklung
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.