We build our computer (systems) the way we build our cities: over time, without a plan, on top of ruins.
Ellen Ullman
Synopsis
Beim Erstellen von Software muss ich, vorallem zu Beginn des Projektes, sehr viele Dateien anlegen. Das Anlegen von neuen, leeren Dateien, können zwar die Entwicklungswerkzeuge häufig übernehmen, doch oft nicht mit dem selben Grad an Kontrolle, wie ich es gerne hätte. Ich hätte gerne ggf. eine Vorlage, mit der die Dateien befüllt werden. Das Tool sollte über die Eingabeaufforderung (Konsole) ausgeführt werden können. Die Aufruf Syntax sollte nicht einen Doktor der Philosophie erforderlich machen.
Ein ähnliches Tool existiert bereits unter Linux, es heißt, halte Dich fest, touch. Genau. So soll meins auch heißen. Die Features sollten jedoch etwas…“besser“ sein.
Übersicht
| Projekt Name | Touch |
| Projekt Art | Anwendung |
| Umgebung | Konsolenanwendung |
| Zielgruppe | Entwickler |
| Sprache | C++ |
| Framework | Qt |
User Story
Möchte ich eine Datei anlegen, z.B. „datei.txt“, so tippe ich touch datei.txt, möchte ich ein Pärchen aus datei.h sowie datei.cpp anlegen, so tippe ich touch datei. Es sollte konfigurierbar sein, was für ein Pärchen dabei erzeugt wird. Vielleicht möchte jemand ja *.hpp und *.cpp, oder *.h und *.c. Relative und absolute Pfade sollten ebenfalls erlaubt sein. Desweiteren möchte ich für die verschiedenen Dateiendungen Vorlagen anlegen dürfen. Wir unterscheiden dabei Text-Vorlagen und binäre Vorlagen. Eine binäre Vorlage, z.B. ein Musterbild, wird einfach an den entsprechenden Ort hinkopiert. Eine textuelle Vorlage, kann ggf. nach dem Anlegen verändert werden. Dabei sind Platzhalter gemeint, die das System auflösen kann. Dateiname, Autor, Daten, Uhrzeit etc.
Spezifikation
Nun haben wir eine Beschreibung aus der Perspektive eines Benutzers. Ich werde jetzt diese Informationen verwenden um eine eher „technische“ Beschreibung anzufertigen. In dieser konzentriere ich mich mehr darauf, wie ich die vom Benutzer erwähnten Features umsetzen würde. Ich mache diesen Schritt gerne bevor es an eine Anforderungsanalyse geht, einfach um klären zu können, ob man die selbe Sprache spricht wie der Benutzer. Ich weiß, da Benutzer und Entwickler hier die selbe Person ist, wirkt das ganze etwas witzig, ist aber dennoch eine gute Übung.
Offensichtlich muss das Programm konfigurierbar sein. Ein Konsolen Programm, welches nur ein Hilfswerkzeug ist, wird nicht über eine grafische Konfiguration verfügen. Kanonen und Spatzen und so. Stattdessen nehmen wir etwas was möglichst einfach ist (für den entwickelnden Benutzer), eine *.ini Datei. Diese definiert erst einmal drei wesentliche Informationen. Die erste ist, wo sich die Vorlagen befinden, und die zweite ist, was zu erzeugen ist, wenn keine Datei Endung angegeben wird. Hier taucht auch schon die Frage auf, was passiert, wenn jemand tatsächlich eine Datei ohne Endung angeben will (was nicht so häufig passiert?). Die verschiedenen Vorlagen sind nicht zwingend konfiigurierbar. Es reicht wenn Vorlagendateien in dem angegebenen Verzeichnis liegen. Das Programm wird selbst schauen, was drin liegt, und ggf. die richtige auswählen. Die letzte Information die wir benötigen, ist eine Liste der nicht binären Dateien. Binäre Dateien werden angelegt „as is“, sprich wir kopieren nur die Vorlagendatei und gut ist. Was ich weiß trage ich einfach mal in eine überschaubare Liste zusammen:
- Die Anwendung hat Zugriff auf eine *.ini Datei mit der Konfiguration.
- Die *.ini Datei spezifiziert ein Verzeichnis mit Vorlagen.
- Soll eine Datei erstellt werden, kann das Programm in dem Verzeichniss nach der passenden Vorlage suchen.
- Die *.ini Datei definiert eine Liste mit Dateiendungen, die nicht binär sind, sprich die nach dem Anlegen bearbeitet werden sollen.
- Die *.ini Datei definiert eine Liste von Dateiendungen, die anzulegen sind, wenn eine Datei ohne Endung angegeben wird.
- Eine spezielle Aufrufoption ermöglicht die Anlage einer Datei ohne Endung (diese wird leer, ohne Vorlage angelegt).
OK, das sieht doch schon mal ganz passabel aus. Ich habe gehört, dass der potentielle Anwender auch zufrieden ist, *hust hust*. Aber jetzt ist es an der Zeit das ganze in eine Liste mit Anforderungen zu packen. Diese werde ich noch um ein paar Punkte erweitern, die allgemein sinnvoll sind, wirst Du schon sehen.
Anforderungen
Eine Liste mit Anforderungen. Diese sind eindeutig gekennzeichnet und werden über den gesamten Entwicklungs- und Lebenszyklus nachverfolgt.
Projekt
Aus den Anforderungen werden Aufgaben. Die Aufgaben sind gruppiert in Meilensteine. Hier kannst Du sehen woran ich gerade arbeite, was bereits fertig ist usw.
Code
Geht es an die Programmierung, werde ich natürlich Quellcode Dateien produzieren. Diese kannst Du hier sehen. Hier findest Du auch einen Link zu der GitHub Seite.