Tool Lagerverwaltung (Teil 3) Noch eine Wiki anlegen

Diesmal ein kurzer Post zur Vollständigkeit für die weitere Entwicklung. Nun braucht die Anwendung selbst eine eigene Wiki. Anders als bei dem Application Framework, wird die Funktionsweise und Benutzung beschrieben.

 

Benötigt

GitHub

 

Begin mit dem Benutzerhandbuch

Jede erstellte Seite soll eine Beschreibung und mindestens eine Skizze haben. Die Beschreibungen sind zunächst als Grundlage, was die Anwendung alles haben und wie sie funktionieren soll. Hier gehören keine Technischen Hintergründe, denn diese gehören entweder im Code als Kommentar oder im Ticket.

 

Am Anfang ein Konzept

Bevor die Anwendung geschrieben wird, soll mit dem Konzepthandbuch die Nutzeranforderungen ermittelt werden. Wenn später die Inhalte fertig sind, können nach und nach die Konzeptbeschreibung zur Benutzerbeschreibung umgestellt werden.

Nun könnte man sagen, dass Konzept kann man sich sparen und man erstelle die Dokumentation, wenn die Anwendung fertig ist. Wenn eine Planung vorliegt, dann ist das Ziel bekannt. Darauf los zu programmieren, führt eher dazu, dass man sein Ziel vergisst.

Die Konzeptbeschreibung ist auch die Möglichkeit die Nutzeranforderung zu spezifizieren und somit im weiteren daraus die Technischen Anforderungen zu formulieren.

Eigentlich eine einfache Sache und dennoch glauben viele, dass man diesen Schritt sich sparen kann. Doch sparen bedeutet am Ende mehr versteckter Zeitaufwand.

 

Wieder mal das GitHub Wiki

Diesmal wird keine Anleitung hinterlegt, wie die Einzelnen Steuerelemente verwendet werden. Wie bereits im vorigen Absatz, werden soll Beschreibungen angelegt. Damit Bildet sich dann Praktisch eine Vorläufige grobe Anforderung, die verfeinert werden kann.

 

Die Inhaltsangabe dient hier zunächst als grobe Richtung. (Im ersten Teil, ist das Beispiel wie das Menü im Edit aussieht)

 * Was kann die Anwendung  
 * Einleitung  
     * Hintergrund  
 * Start Seite  
     * Grundrahmen  
     * Übersichtsliste  
     * Suche  
 * Vorlage Einstellen  
     * Basisfelder  
     * Optionale Felder  
 * Neue Sache  
     * Vorlage verwenden  
     * Eigene Vorlage verwenden  
 * Sache bearbeiten  
     * Optionale Felder hinzufügen  
 * Sache archivieren  
     * Sache wiederherstellen  

Inhalt füllen

Im Ersten Teil habe ich bereits beschrieben, was man bereits mit dem Wiki erzeugen kann und deshalb geht es hier einen Schritt weiter voran mit dem erzeugen der Seite für die 'Start Seite' der Anwendung. Auf der neuen Seite, kommt zu der Textform auch Bilder. Mit diesen wenigen Details, lassen sich im Anschluss bereits die ersten Technischen Anforderungen ableiten.

 

 

Bisher noch nicht erwähnt, hatte ich das Tool Pencil. Neben Ablauf Diagrammen, können Skizzenhaft die Programmoberfläche Gestaltet werden.

 

Nächster Ansatz

Damit ist der nächste Ansatz getan. Aber bevor ich mit den weiteren Teilen der Anwendung weiter schreibe, geht es mit einer Technische Komponente weiter.

 

Übersicht

Teil 1 - Wiki anlegen in GitHub

Teil 2 - Neue Solution

Teil 3 - Noch eine Wiki anlegen

Teil 4 - Datenbank und Schnittstelle

Teil 5 - Konzept ausschreiben

Teil 6 - Umzug nach .NET MAUI

Tool Lagerverwaltung (Teil 2) Neue Solution

Welche Architektur oder welche Form soll das Projekt haben. Am liebsten setze ich auf die Drei-Schichten-Architektur. Klinkt abstrakt und hochtrabend, aber kompliziert ist die Sache nicht. Sich dran halten ist anfangs schwierig. Vorzugsweise setze ich auf Desktop Anwendung.

Benötigt

• Visual Studio 2022 oder anderen Compiler
• .NET 6.0
• Codexzier's Application Framework
• GitHub

 

Ziel für diesen Blog-Eintrag

Eine neue Solution und die benötigten Projekte einrichten mit dem Ansatz der Drei-Schichten Architektur..

 

Drei-Schichten

Wenn ich Rückblicke, in welchen Formen ein Drei-Schichten Modell aussieht, dann waren diese immer unterschiedlich gestaltet und hielten dennoch erkennbar Drei Schichten. Grundlegen haben wir das Frontend oder auch Benutzeroberfläche genannt, dann die Service-Schicht in der die Daten verarbeitet werden und als drittes die Datenhaltung in einer Datenbank.

 

Solution anlegen

Aber bevor das Projekt angelegt wird, soll eine leere Solution erstellt werden. Idealerweise gibt ihr in die Suche 'Blank' ein.

Nach der Auswahl kommen wir zur Eingabe des Solution Name und das Festlegen des Speicherortes.

Git Repository

Bevor das WPF Projekt Eingesetzt wird, gehört die Pflege der Sourcecodes in das Git System. Also fehlt der Klick auf den Button 'Create Git Repository…'.

Falls die Anmeldung von GitHub noch nicht geschehen ist, dann wird dies jetzt gefordert. In meinem Fall ist das Projekt öffentlich, weshalb der Haken für 'Private repository' raus ist.

Ist das Repository erstellt, dann sollte der aktuelle Stand bereits Online in eurem GitHub Repositories zu finde sein.

 

Einrichten der Projekte

Als erstes kommt das WPF Projekt, das die Frontend Schicht abbildet. Hier verwende ich das Projekt Template, dass bereits die Referenzen zu meinem Application Framework enthält.

Im folgenden kommen zwei Möglichkeiten, um das Template in Visual Studio 2022 einzubinden.

 

Option 1

Die Zip-Datei Codexzier Application Framework Vorlage Augsut 2022 in den Ordner ../Visual Studio 2022/Templates/ProjectTemplates einfügen (zum Download)

 

Option 2

Das Codexzier Application Framework von meinem GitHub Repository herunterladen und in Visual Studio öffnen. Dann oben auf Projekt

Dann das Projekt Template 'Codexzier.Wpf.ApplicationTemplate' auswählen..

..und im nächsten Schritt einen Namen vergeben.

Wählt nun die Solution aus und fügt diesem ein neues Projekt zu.

Das WPF Vorlagen Projekt kann bei Bedarf über die Suche gefunden werden.

Für die Benutzer Oberfläche, solltet ihr für den Namensraum den Bereich Namentlich erkenntlich Beschreiben.

Service Schicht

Das nächste Projekt soll alle Service Komponenten enthalten, die nichts mit der Benutzer Oberfläche zu tun haben. Obwohl ich von Service Schicht gesprochen habe, wird eine einfachen Klassen Bibliothek angelegt. Hier darauf achten, dass ihr die Vorlage für das aktuelle .NET Framework verwendet.

Und wieder einen passen Namen vergeben für die Service Komponenten Schicht.

Im nächsten Schritt muss noch die .NET Version angegeben werden und dann kann das Projekt erstellt werden.

Ein Projekt noch

Eins fehlt noch und zwar das für die Automatischen Tests. Für die UI kann eigentlich auch ein Test Projekt angelegt werden, aber aktuell reicht ein Unit Test Projekt für die Service Komponenten Schicht.

Der Namespace bekommt den Zusatz 'Test'. Damit sollte das Unit Test Projekt direkt unter dem zu testenden Projekt sein.

Zum Schluss wieder die .NET Version auswählen und erstellen.

Initialen Stand sichern

Hier braucht der Text schlichtweg aussagen, dass grundlegend die Projekte angelegt wurden.

Grundlage für das gesamt Projekt

Der zweite Schritt ist erledigt. Eine neue Solution mit den Grundlegenden Projekten ist angelegt. Die Inhalte habe ich nicht zu stark unterteilt, schließlich handelt es sich hier um ein sehr kleines Privat Projekt. Im nächsten Schritt geht’s dann mit dem Konzept und Funktionsumfang weiter.

Übersicht

Teil 1 - Wiki anlegen in GitHub

Teil 2 - Neue Solution

Teil 3 - Noch ein Wiki anlegen

Teil 4 - Datenbank und Schnittstelle

Teil 5 - Konzept ausschreiben

Teil 6 - Umzug nach .NET MAUI

Tool Lagerverwaltung (Teil 1) Wiki anlegen in GitHub

Für das Tool soll das eigene Framework verwendet werden, dass ich in den letzten Jahren immer weiter ausgebaut hatte. Jedoch ist noch offen, eine Dokumentation anzulegen, die den Funktionsumfang sowie Verwendung des Applikation Framework zeigt.

 

Benötigt

• Visual Studio 2022 oder anderen Compiler
• .NET 6.0
• Codexzier's Application Framework
• GitHub

 

Was ist mein Ziel?

Primär soll ein einfaches Tool entwickelt werden, dass zur Lagerverwaltung verwendet werden kann. Mit der der Entwicklung möchte ich beschreiben, welche Vorgehensweisen und Lösungen ich verwende. Zudem soll zu jeder Funktion aus dem Applikation Framework dokumentiert werden, das ich für den aktuellen Schritt verwendet wird.

 

Neben Produkt

Immer wenn ich eine neue Anwendung geschrieben habe, benötigte ich Grundlegende Inhalte für eine WPF Anwendung mit bestimmten Funktionen die ich selbst mal geschrieben habe. Und weil ich meine Anwendung auch ein Bestimmtes Aussehen haben sollen, habe ich auch die Styles immer mit kopiert. Damit ergaben sich Vorteile aber auch Nachteile.

 

Vorteile

• Auf den Bisherigen Lösungen etwas Besseres oder neues entwickeln
• Übung, Übung, Übung

Nachteil

• Pflege älterer Anwendung erschwert
• Doppelte Arbeit

 

Ok, gehen wir von der selbst Erklärung rüber zum ersten Schritt.

 

Henne-Ei-Problem

Fange ich mit der Dokumentation an, was funktionieren soll oder fange ich mit dem Programmieren an und dokumentiere? Die Frage, ob man mit der Dokumentation anfängt, ist davon abhängig, um was für eine Dokumentation angelegt werden soll. Bevor etwas entsteht, kann im Grunde nur ein Konzept- oder ein Grundbeschreibungen zu einer Anwendung angelegt werden.

In meinem Fall liegt der Programmcode vor und die Dokumentationsbeschreibung fehlt. Also wie in vielen Projekten.

 

GitHub Wiki

Die Sourcen zu dem Applikation Framework von mir habe ich bereits auf GitHub hochgeladen und dort kann zusätzlich ein Wiki gepflegt werden. Und damit soll's neben dem Hauptprojekt beginnen.

 

Als erstes hilft eine Grobe Inhaltsangabe anzulegen, so dass eine Grundlage vorliegt, an der man sich orientieren kann.

 Home  
 Lizenz  
 Grundlagen  
      Vorlage  
      Neues Projekt einrichten  
      Grundaufbau  
      Weiter Einstellungen  
 Components  
      Event Bus Manager  
      User Settings  
      Animation Helper  
 Styles  
      Blue Gray  
      White Gray  
      Gray White  
 Steuerelemente  
      Button  
      Diagram  
      Folder Browser  
 Game Tree 

So sieht der Text in der Bearbeitung aus in der GitHub Wiki (Zuvor hatte ich am Ende jedem Eintrag immer Page stehen gehabt, leider ist das dann auch der Name der Seite und habe das deshalb abgeändert)

 * [[Lizenz|Lizenz]]  
 * [[Grundlagen|Grundlagen]]  
 > - [[Vorlage|Grundlagen - Vorlage]]  
 > - [[Neues Projekt einrichten|Grundlagen - Neues Projekt einrichten]]  
 > - [[Grundaufbau|Grundlagen Grundaufbau]]  
 > - [[Weiter Einstellungen|Grundlagen - Weitre Einstellungen]]  
 - [[Components|Components]]  
 > - [[Event Bus Manager|Components - Event Bus Manager]]  
 > - [[User Settings|Components - User Settings]]  
 > - [[Animation Helper|Components - Animation Helper]]  
 * [[Styles|Styles]]  
 > - [[Blue Gray|Styles - Blue Gray]]  
 > - [[White Gray|Styles - White Gray]]  
 > - [[Gray White|Styles - Gray White]]  
 * [[Steuerelemente|Steuerelemente]]  
 > - [[Button|Steuerelemente - Button]]  
 > - [[Diagram|Steuerelemente - Diagram]]  
 > - [[Folder Browser|Steuerelemente - Folder Browser]]  
 > - [[Game Tree|Steuerelemente - Game Tree]]  

Und so sieht's dann nach dem Speichern aus.

Gefärbter Text

Im Bild ist zu sehen, dass nur der Text 'Lizenz' in blauer schrift hinterlegt ist. Wenn du suggestiv einen Link vermutest, dann liegst du richtig. Für die Seite Lizenz, habe ich bereits eine Seite angelegt. Alle die noch rot eingefärbten sind, müssen noch erstellt werden. Wenn man auf eines der rot gefärbten Text klickt, kommt statt einem Fehler eine Bearbeitungsmaske, um diese Seite zu erstellen.

 

Grundlage

Der erste Schritt ist damit getan. Nun muss man nur dranbleiben und hin und wieder schauen, ob die Struktur weiterhin passt.

Links

https://docs.github.com/en/communities/documenting-your-project-with-wikis/editing-wiki-content