Planung von Webanwendungen

[alinnert]

Hallo und einen schönen Aprilscherz allerseits

ich hab derzeit mehrere Webprojekte im Kopf, hab aber derzeit noch Probleme, eine Struktur dafür zu entwickeln - also die Projekte richtig zu planen.

Wie plant man richtig Webprojekte - basierend auf HTML, PHP etc., evtl. mit AJAX-Funktionalitäten?

Ich hab mir auch schon selbst darüber Gedanken gemacht, wie sowas am intelligentesten aussehen würde, aber ich finde bisher keine Diagramm-Art (ja, UML kenne ich), die zu dem passt, was ich im Kopf habe. Klassen- und Datenbank-Diagramme sind mir zu spezifisch, als dass ich mein Konzept da reinpressen könnte.

Ich möchte meine Datenstruktur auch Systemunabhängig planen - d. h. ohne mich vorher zu entscheiden, ob das eine Klasse oder eine Datenbanktabelle (was bei mir eh sehr unwahrscheinlich ist) oder sonst was wird.

Gibt es da etwas, das mir helfen kann? Oder wie werden solche Projekte heute geplant?

Was auch zu dem Thema passt: ich habe auch keine Möglichkeit gefunden, JSON-Strukturen zu planen/entwerfen, außer direkt einen Prototypen zu schreiben.

Wenn es hier (vollständiger Bereich Webprojekt-Planung) noch nichts konkretes gibt, würde es sich lohnen, etwas Neues zu entwickeln? Wie erwähnt, hab ich mir da schon grobe Gedanken gemacht, wie so etwas aussehen würde.

Und ich entschuldige mich, wenn das alles etwas konfus klingt, aber ich bin eben genau auf der Suche nach der Struktur/dem Anhaltspunkt, der mir hier fehlt.

Viele Grüße

Andreas

[lilith2k3]

Klassendiagramme sind erst einmal egal.

Am Anfang steht das gute alte Use-Case-Diagramm ergänzt um User-Stories und wenn dich die künstlerische Ader packt, mach ein Mockup, wo Du Dein Layout durchdenkst. Erst, wenn Du weißt, was Du willst, wäre es sinnvoll einen Schritt weiter zu gehen; evtl. willst Du schon ein paar Sequenzen und Abläufe festhalten. Das alles sind Sachen, die ersteinmal Nullkommajarnüscht mit Javascript, JSON, XML, ASP.Net, PHP und weißderGeierwas zu tun haben.

Oder mach's auf die coole OldSkool-ArtundWeise: Nimm Dir 'nen Zettel und ein Blatt Papier und malere Dir, was Du brauchst. Kostet auch nur 'nen Euro für'n Stift - im Gegensatz zu Visual Paradigm zum Preis eines gebrauchten Kleinwagens.

Solange Du nicht genau weißt, was Du überhaupt willst, ist es schnurpiepegal, ob Du später mit REST/JSON oder SOAP/XML arbeiten willst. Und sich jetzt schön über so einen Killefit Gedanken zu machen ist in meinen Augen verschwendete Zeit. Wenn Du ein ordentliches Modell Deiner Anwendung zusammen hast, lohnt sich erst der Gedanke an JSON. Und dann benötigst Du keinen Designer oder kein Tool, dann ergibt sich die Datenstruktur aus dem, was Du an DTOs etc. entwickelt hast.

Die Use-Cases führen logisch gesehen zur testgetriebenen, (BDD als Unterart von TDD verstanden) Entwicklung. Von daher wäre das für mich der Ausgangspunkt.

[etreu]

Definiere erst mal Anwendungsfälle und User-Stories.

Visualieren kannst du das wie du willst, kannst dir mal das Pencil Projekt anschauen.

Datenstruktieren werden in der Analyse unabhänging vom Zielsystem modelliert. Wenn du mit OO arbeitest kannst du hier auch Klassendiagramme verwenden. Um Abläufe zu modellieren kannst du beispielsweise ADs verwenden.

Ob du nun ein Webfrontend oder eine normale GUI Anwendung entwickelst, sollte abgehsen vom visualisieren erst mal keinen Unterschied machen.

[alinnert]

Okay, danke erst mal für die Antworten. Das sieht mir sehr nach UseCases und User-Stories für den Anfang aus. Ich werde den Gedanken mal weiter verfolgen.

Stift und Papier nehme ich eigentlich ungerne, da das sehr unflexibel ist, wenn Änderungen anfallen oder ich noch etwas einfügen möchte, aber kein Platz mehr vorhanden ist. Deswegen suche ich schon länger nach einer Software, mit der man sowas machen kann. Aber viele sind hier zu stark an der Papiervariante der Diagramme orientiert - es ist also immer noch recht viel Aufwand, etwas zu entwerfen, Inhalte zu pflegen, neue Figuren zu zeichnen, Verbindungen herzustellen und aufrechtzuerhalten. Damit hab' ich derzeit noch ein großes Problem. Ich möchte meine Ideen einfach "schnell" eingeben können, aber gleichzeitig eine schöne Visualisierung des Ganzen vor mir haben.

Mal nebenbei: das Projekt, das ich wahrscheinlich als nächstes umsetzen werde, wird wohl eine Blogverwaltung oder ein Mini-CMS mit Blog- und Literaturfokus sein.

Da fällt mir auch ein weiterer Punkt ein: Ich werde vielleicht auch irgendwo Probleme mit dem UseCase-Schema haben, da ich gerne ein Interface vor mir sehe, mir vorstelle, wie ich dieses bediene und mir aufgrund dessen neue Funktionen oder Ideen kommen, die mir beim UseCase-Entwurf gar nicht einfallen können. Oder ist es üblich, dass man öfter zwischen diversen Schritten hin- und herspringt? Aber aus diesem Grund, tendiere ich eigentlich fast dazu mit Mockups anzufangen. Ich gehe auch schon vorher im Kopf durch, für was die Anwendung gut sein soll, was man damit machen kann etc.

Dann nochmal zur Datenstrukturplanung. Dass ich bei Webprojekten eine SQL-Datenbank verwenden werde, halte ich für recht unwahrscheinlich, da ich ein großer Fan von NoSQL-Datenbanken bin (und meiner Vorstellung nach lassen sich die Daten meiner Projekte auch gut damit abbilden). Allerdings hab' ich hier das Problem, dass es keine offiziellen Diagramme gibt, mit denen man Strukturen in solchen Datenbanken planen kann. Ich hab mir bisher immer mit Textdateien ausgeholfen. Das Gleiche gilt eben auch für JSON-Strukturen, wenn ich Server-Skripte schreibe, die Datenbankinhalte als JSON-String zurückliefern.

[Pixie]

Wenn Du nicht für die Papier-Variante bist: Hast Du es schon einmal mit MindMaps versucht? Beleibig erweiterbar, Äste können umgehängt werden, man kann sie mit Notizen versehen und z.B. auch Mackupscreens als Notizen anhängen...

[alinnert]

Nun, die hab ich bisher außen vor gelassen, weil ich immer nur welche mit kurzen Begriffen gesehen hab - die typischen eben. Wenn es da eine Software gibt, die da flexibel genug ist, um Begriffe mit andersartigen Elementen zu verknüpfen, klingt das in der Tat sehr interessant.

[lilith2k3]

<- Wie wäre es mit sowas?!

Oder ist es üblich, dass man öfter zwischen diversen Schritten hin- und herspringt?

Klaro Im Grunde ist das multiperspektivisches Entwickeln: Du näherst Dich dem Produkt über viele Seiten.

[alinnert]

<- Wie wäre es mit sowas?!

Das sieht mir sehr nach einer Testphase aus, wenn das Design und die Struktur der Anwendung bereits steht. Durch das Papier wirkt es auch noch etwas komplizierter. Und da ich alleine bin, tut es das wahrscheinlich auch, wenn ich das Ganze am Bildschirm und im Kopf durchgehe - finde ich nun.

Okay, das mit dem multiperspektivischen Entwickeln klingt nachvollziehbar.