Hallo Thomas,
so wird es vielen Programmierern gehen. Zunächst sollte die Unzufriedenheit bei bestimmten Entwicklungsschritten genau festgestellt werden. In der Regel sind es Aufgaben wie:
hinterher noch eine Spalte in den Table einfügen, weil man diese zuvor nicht bedacht hatte oder ein Model arbeitet doch mehr mit einem anderen Model zusammen, als gedacht. Da wird jeder seine Lieblingsärgernisse haben. Im Prinzip läuft alles darauf hinaus, das die Software zuvor nicht ausreichend geplant und durchdacht war. Gerade bei größeren Projekten wird man Schwierigkeiten haben, alles im Kopf zuvor einmal geplant und durchgegangen zu haben.
>>Wie bereitet Ihr euch vor?
Themenrecherche um ein Grundverständnis für die Aufgabe zu bekommen!!!
>>Wie plant ihr eure Projekte?
Die Lösung der Probleme ist meiner Meinung nach „MDD“ (Model Driven Development) & “UML“ Unified Modeling Language. Diese Technologien beschäftigen sich mit dieser Art Problemen.
UML ist die perfekte Art von Bleistift und Papier. Mit dieser Sprache werden Softwarearchitektur und Prozesse im Vorfeld visualisiert. Für jede Art von Problemen gibt es eine eigene Diagrammart die die Anforderung und die Schwachstellen verdeutlicht. Zu den Entwicklungsschritten schreibe ich dir den jeweiligen Diagrammnamen dazu, dann fällt es beim Pauken leichter.
Als Beispiel, damit es vorstellbar ist, dient ein Pizza-Lieferdienst-Service Portal auf dem viele Restaurants gelistet sind. Die Restaurants bekommen die Bestellungen aus dem Portal direkt an ein Androit in die Küche.
Die Vorgehensweise:
Vorgaben und Lastenheft genau anschauen. Dieses dann in eigene Worte fassen und als „Requirement“ eintragen. Die Requirements sind dann die Basis für jede weitere Planung.
Aus den Requirements lassen sich als nächstes die Anwendungsfälle „Use Case“ ableiten. In den Use Cases werden die verschiedenen Aufgaben die der User, der Admin und das System leisten muss dargestellt.
„User navigiert durch die Restaurants“
„User loggt sich ein“ ...usw
Die Use Cases minimieren so Aktionen wie „Mist, der User bekommt ja noch nen Gutschein, hm wer wollte ihm den Gutschein übermitteln, wer darf überhaupt Gutscheine Ausgeben, gibt es einen GS Pool für jedes Restaurant“. ↠Das sind genau die Fragen an denen man beim Entwickeln unzufrieden wird )
Nun geht’s um die Sequenzen zu den jeweiligen Anwendungsfällen.
„User navigiert durch die Restaurants“ für den Lieferbereich die Restaurants laden. Restaurants die extra Werbung geschaltet haben zuerst anzeigen. Gute Bewertungen höher ranken. ...usw.
In die Sequenzen beschreiben dann die tieferen Prozesse die für die Lösung der Aufgabe nötig sind. Es macht sich gut, dies für jeden UseCase einzeln zu erstellen. Man erkennt oft, dass eine Sequenz mehrfach und für andere Anwendungsfälle genutzt werden kann. Nebenher notiert man sich weitere Requirements oder verbindet bereits vorhandene mit der Sequenz.
Das ist im Groben die Planung. Entscheidend ist hier der Vorteil, dass man Probleme und Aufgaben frühzeitig erkennt und diese in diesem Stadium der Entwicklung einsortieren kann. Der Zeitvorteil ist enorm, da man eher mit der Maus boxen verschiebt als den Code umzuschreiben!!
Der Planungsteil ist hier soweit abgeschlossen. Nun geht es ans Modellieren der Anwendung.
Die Diagrammart ist hier das „Class Model“
Das Class Model sieht bei mir immer wie die spätere Files und Folder Struktur aus(admin mvc; user mvc). Hier füge ich die bereits erstellten Anwendungsfälle als Klassen und Funktionen ein. Also nur das Skelett schreiben, auf gar keinen Fall genaue Routinen. Die Klassen werden auch hier als Diagramm dargestellt. Diese kann man verschieben kombinieren, ableiten ...usw. Das Geschiebe beim Modellieren spart jede Menge Frust als wenn man das mit dem Code beim Coden machen würde.(ein Segen) Hier achtet man automatisch darauf das die Datenmodell (Klassen) erweiterbar sind und vor Allem auch wie. (Segen ++)
Ich denke es lässt sich schwer vermitteln, das man so einen Aufwand bei der Planung betreibt und noch keine Zeile Code real programmiert hat. Als UML Tool habe ich Enterprice-Architect (EA).
Der EA druckt mir auf Verlangen das zuvor erstellte Datenmodell als Dateien samt deren Verknüpfungen mit den jeweiligen Kommentaren aus.
Gleiches gilt bei der Erstellung der DB Tables.... es werden die kompletten inserts und creates ausgegeben.(Segen²)
….nun geht’s an Programmieren. Hier arbeite ich dann die zuvor erstellten UseCases und Sequenzen ab. Ich beschäftige mich an dieser Stelle ausschließlich mit dem Code und nicht mit der Struktur. Die Trennung wie wir sic beim Css-Html-Php-JS haben, findet hier ebenso statt. Ich denke , jeder der diese Vorgehensweise beim Webseiten-schreiben mag erkennt hier die Notwendigkeit der Stricten Trennung von Planning und Development.
Es lässt sich nie ganz verhindern, das man irgendwo im Code „nachpatchen“ muss. Der EA bietet hier eine Reverse-Funktion. Es wird der Programmcode in das Class-Model eingelesen. Das aktualisierte Diagramm steht dir dann wie weiter oben beschrieben zur Verfügung.
Besser und schneller werden: Die Nachpatche-Erfahrung von gerade eben beachtet man beim neuen Projekt eher und bezieht diese bei der Planung sofort ein, da man diese Visualisiert hat. Vielleicht auch, weil man dieses nachpatchen als Strukturelle Frage und nicht als Code-Frage erkannt hat.
Welche Techniken nutzt/kennt Ihr und welche davon haben sich bei euch bewährt?
UML
MDD
und als Programm Enterprice Architect ggf. fürs Wiren den ScreenArchitect.
Note: Zum Anfang ist man bei der Anwendung von UML wenig effizient. Teilweise erschliessen sich Sinn und Nutzen erst später. Auf jeden Fall sollte man MDD und UML zum Lernen immer nebenher mit machen. Man wird von Mal zu Mal besser.
Der Angehängte Screen verdeutlicht nur. Oben ein Use Case darunter eine Sequence zu einem Usecase. Der vollständige Pdf-Output sind knapp 50 Seiten.
Beitrag erstellen
EinloggenKostenlos registrieren