Motivation bei Privatprojekten (Split aus Diamond of Death)
-
Mandarin
-
Was für ein Thread...
PI, wieso machst du nicht ein Thread auf mit dem Titel: "IRC BOT (Plugins)".Die ersten Posts zu dem eigentlichen Thema waren noch recht interessant, weil es mir auch manchmal so geht. Aber dann ist der Thread total abgeschweift nach "Welche Sprache, Welche IPC-Methode, etc.".
Am besten bennent ein Moderator bitte den Thread um. Das ist Irreführung :p
-
Man könnte ja den Split nochmal splitten und den Split-Split ins C++-Forum schieben. Mir solls recht sein.
-
Was gehört zur Planung eines Designs dazu? Wie genau muss so eine Planung aussehen?
- Sollen nur die Klassen geplant werden in ihrer Funktionsweise?
- Soll das Interface von Klassen, möglicherweise auch Funktions-Signaturen mit geplant werden mit Beschreibung der einzelnen Funktionen?
- Sollen private Member (sowohl Variablen, als auch Funktionen) geplant werden?
-
Oh Mann...
Du überspringst schon wieder Schritte.1: Anforderungen definieren. Was soll das Ding können?
Sich davor über's Design Gedanken zu machen führt zu nichts Gutem!
-
- Verbindung nur zu einem Server, multi-Server Support nicht erforderlich
- Multi-Channel support
- Config Datei für Daten wie Server, Nickname, Username, Whois-Text, ...
- Soll unter Ubuntu 11.04 (Server) und Mac OS X 10.6 (Lappi) lauffähig sein
- IPC über Shared Memory mit Plugins
- Events für Plugins für jede Art an "Dingen", die im IRC halt so auftreten können: MOTD, Kick, Ban, Op, Voice, Topic-change, Chanmode-change, Query, Normale Channel Nachricht, Ping, CTCP, aber auch Fehler, wie: Nickname schon vorhanden, keine Rechte, G-Line, Verbindungsfehler, etc.
- Automatisches Laden aller Plugins aus einem plugins/ Unterordner bei Start
- Nachladen/Deaktivieren/Neuladen von Plugins über den Bot
- Simples Logging in eine Datei, die bei jedem Start einfach überschrieben wird, hier sollen einfach alle Nachrichten rein, sowie die, die der Bot gesendet hat, und zwar Server Nachrichten beginnend mit "S: ", Bot-Nachrichten beginnend mit "C: "
- Steuerung des Bots über die Konsole: Connect, Disconnect, Plugin-Management, ...Ist das richtig so?
-
Pfuh, jain.
Du vermischt schon wieder das "wie" mit dem "was". Um das "wie" geht's beim Anforderungen definieren schonmal (meistens) nicht. "IPC über Shared Memory" ist "wie", nicht "was". Was ist das "was" dazu?Aber egal.
Jetzt formulier das ganze genauer aus.
Stichwort User Stories und Use Cases.
-
Ich habe mir das hier ergoogelt:
http://de.wikipedia.org/wiki/User_Story
http://de.wikipedia.org/wiki/AnwendungsfallAllerdings fange ich damit nicht wirklich was an...
-
Such nach englischen Seiten, da findet man mehr.
Such nach "use case examples".Zwei nicht ganz unbrauchbare Beispiele:
http://www.math-cs.gordon.edu/courses/cs211/ATMExample/UseCases.html
http://www.acs.ilstu.edu/faculty/bllim/oo/usecase.htm
-
Wenn ich das also richtig verstanden habe, ist ein Use Case eine Beschreibung eines einzelnen Vorgangs, wie "Bot wird gestartet", "eine Nachricht vom Server trifft ein", oder "Plugin will Antwort senden". Dabei wird allerdings nur beschrieben, was getan wird (aus Sicht des Benutzers des Bots), aber nicht wie.
Was wären denn die "Use Cases" bei meinem Bot? Mir würden hier folgendes einfallen:
- Startup (Besteht aus Connect, Plugin-Load)
- Nachricht vom Server trifft ein (Besteht aus Logging, Informieren des Plugins, und Verarbeitung durch Plugin)
- Antwort eines Plugins (Bot informieren, Logging, Senden)
- Shutdown (Plugins informieren, auf Beendigung der Plugins warten, "hängende" Plugins terminieren, Verbindung beenden)
-
Wenn ich das also richtig verstanden habe, ist ein Use Case eine Beschreibung eines einzelnen Vorgangs, wie "Bot wird gestartet", "eine Nachricht vom Server trifft ein", oder "Plugin will Antwort senden". Dabei wird allerdings nur beschrieben, was getan wird (aus Sicht des Benutzers des Bots), aber nicht wie.
Ich vermute dass du es halbwegs richtig verstanden hast.
Das "wie" wird schon beschrieben, aber nur das "wie" aus Sicht des Benutzers. Das ist auch wichtig, genau darum geht es in einem Use-Case.Eine User-Story wäre "Als Bot-Besitzer möchte ich über die Konsole Plugins nachladen können".
Der Use Case würde dann detailiert beschreiben wie der User das machst, und wie das System darauf reagiert.Beide sprechen aber nicht über die Implementierung.
Mir würden hier folgendes einfallen: (...)
Ja das könnte hinkommen. Das sind aber erst "Titel" von User-Stories/Use-Cases, jetzt musst du sie noch ausformulieren.
Und...
- Nachladen/Deaktivieren/Neuladen von Plugins über den Bot
- Steuerung des Bots über die Konsole: Connect, Disconnect, Plugin-Management, ...Beim 2. Punkt wirst du vermutlich sogar mehrere Use-Cases haben.
Jede Aktion die jmd. über die Konsole durchführen will ist ein Use-Case.
Und für "..." ist in der Planung kein Platz, "..." gibt's nicht.
-
===============================================================================================================================================================================
StartupUser Story: Als Bot-Besitzer möchte ich, dass mir der Bot eine neue Konfigurations-Datei bei Start anlegt, wenn keine existiert.
Use Case: Config bei Start
Voraussetzung:
- Die Konfigurationsdatei "bot.conf" existiert nicht.Beschreibung:
- Der Bot legt eine neue Config mit dem Dateinamen "bot.conf" an. (Use Case: Config-Erstellung)Ausnahmen:
- Die Datei existert bereits. Nichts passiert.-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
User Story: Als Besitzer des Bots möchte ich, dass der Bot bei Start eine neue Log-Datei anlegt.
Use Case: Log-Start
Voraussetzungen:
- Die Log-Datei existert noch nicht.Beschreibung:
- Der Bot versucht, eine neue Datei mit dem Namen "bot.log" anzulegen.Ausnahmen:
- Die Datei existert bereits. Die alte Datei wird überschrieben.
- Die Datei konnte nicht erstellt werden. Der User wird mit der Meldung "Couldn't create logfile." informiert. Der Bot fährt sich herunter.
(Use Case: User-Information, Shutdown)-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
User Story: Als User möchte ich, dass sich der Bot beim Start automatisch mit dem Server verbindet.
Use Case: Auto-Connect
Voraussetzungen:
- Ein Host + Port wurde in der Config angegeben.Beschreibung:
- Der User hat einen Host und einen Port in der Konfigurationsdatei angegeben.
- Der Bot verbindet sich mit dem Host über den angegebenen Port. (Use Case: Connect)Ausnahmen:
- Kein Host oder Port wurde angegeben. Nichts passiert.
- Nur der Host wurde angegeben. Der Bot versucht, sich über den Port 6667 (default IRC Port) mit dem Host zu verbinden. (Use Case: Connect)
- Nur der Port wurde angegeben. Der Bot informiert den User mit der Nachricht "Host missing for port <port> in config file." und schreibt selbige Nachricht in die Logdatei.
(Use Case: User-Information, Logging)
- Die angegebene Portnummer ist ungültig. Der User wird darauf mit der Fehlermeldung "Invalid port number <port> in config file." hingewiesen. (Use Case: User-Information)
Die Meldung wird auch in die Log-Datei geschrieben. (Use Case: Logging)-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
User Story: Als Bot-Benutzer möchte ich, dass der Bot alle Plugins beim Start lädt.
Use Case: Auto-Plugin-Load
Voraussetzungen:
- Das Plugin Verzeichnis "plugins/" existiert.
- Die Plugins im Verzeichnis haben die Dateiendung ".plg".Beschreibung:
- Der Bot lädt alle Plugins mit der Dateiendung ".plg" aus dem "plugins/" Unterordner im Bot-Verzeichnis.Ausnahmen:
- Das Verzeichnis existiert nicht. Der Bot erstellt ein leeres "plugins/" Verzeichnis. (Use Case: Plugin-Ordner erstellen)
- Das Laden eines Plugins ist fehlgeschlagen. Der Bot informiert den User über den Fehlschlag mit der Nachricht "Couldn't load plugin <plugin-name>." und schreibt selbige
Nachricht in die Logdatei. (Use Case: User-Information, Logging)===============================================================================================================================================================================
===============================================================================================================================================================================
Kommunikation mit dem ServerUser Story: Wenn eine Nachricht vom Server kommt, möchte ich, dass der Bot die Nachricht loggt und die Plugins auf die Nachricht reagieren können.
Use Case: Nachricht von Server
Voraussetzungen:
- Plugins wurden geladen
- Die Nachricht entspricht dem IRC Protokoll RFC 1459Beschreibung:
- Eine Nachricht vom Server trifft ein.
- Der Bot schreibt die Nachricht in die Log-Datei und hängt ein "S: " - Präfix an. (Use Case: Logging)
- Der Bot bringt die Nachricht in eine für Plugins besser verarbeitbare Form.
- Der Bot informiert die Plugins, damit sie die Nachricht verarbeiten können.Ausnahmen:
- Keine Plugins wurden geladen. Nichts passiert.
- Die Nachricht entspricht nicht RFC 1459. Der Bot verwirft die Nachricht und schreibt in den Log, dass eine ungültige Nachricht ankam: "Invalid message from server: '<msg>'"
(Use Case: Logging) Der User wird davor mit der selben Nachricht über den Fehler informiert. (Use Case: User-Information)-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
User Story: Wenn ein Plugin eine Nachricht zum Server sendet will, soll die Nachricht vom Bot geloggt werden, bevor sie gesendet wird.
Use Case: Nachricht von Plugin
Voraussetzungen: Keine
Beschreibung:
- Ein Plugins informiert den Bot, dass es eine Nachricht senden möchte.
- Der Bot setzt eine laut RFC 1459 gültige Nachricht zusammen.
- Der Bot schreibt die Nachricht in die Log Datei und hängt ein "C: " - Präfix an. (Use Case: Logging)
- Der Bot sendet die Nachricht zum Server.Ausnahmen:
- Die Nachricht ist ungültig. Der Bot Verwirft die Nachricht und schreibt in den Log, dass eine ungültige Nachricht ankam: "Invalid message from plugin <plugin-name>: '<msg>'"
(Use Case: Logging) Der User wird davor mit der selben Nachricht über den Fehler informiert. (Use Case: User-Information)===============================================================================================================================================================================
===============================================================================================================================================================================
ShutdownUser Story: Als Bot-Besitzer möchte ich, dass der Bot versucht, alle Plugins ordnungsgemäß herunterzufahren.
Use Case: Plugin-Shutdown
Voraussetzungen:
- Eine Wartezeit für Plugins, die sich herunterfahren, wurde in der Konfigurationsdatei eingestellt.Beschreibung:
- Der Bot informiert alle Plugins über den bevorstehenden Shutdown.
- Der User wird durch die Nachricht "Shutting down plugins..." informiert, selbige Nachricht wird in den Log
geschrieben. (Use Case: User-Information, Logging)
- Der Bot wartet die in der Config eingestellte Zeit, um den Plugins etwas Zeit zu geben, sich zu beenden.
- Alle Plugins, die sich nicht beendet haben, werden ohne weitere Kommunikation terminiert.
- Der User wird informiert, wenn Plugins terminiert werden mussten, und zwar mit der Nachricht "The following plugins had to be terminated: <plugin-list>".
(Use Case: User-Information) Die selbe Nachricht wird in die Logdatei eingetragen. (Use Case: Logging)
- Der Bot schreibt in den Log (Use Case: Logging) und informiert den User (Use Case: User-Information) mit der Nachricht: "Plugin shutdown complete."Ausnahmen:
- Keine Plugins wurden geladen. Nichts passiert.
- In der Config wurde keine Wartezeit eingestellt. Der Bot wartet 500 ms auf Beendigung.
- Das Logging schlägt fehl. Der Bot ignoriert den Fehler und geht weiter vor wie geplant.-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
User Story: Als User erwarte ich, dass der Bot bei Beendigung die Verbindung beendet.
Use Case: Bot-Shutdown
Voraussetzung: Keine
Beschreibung:
- Der Bot informiert den User mit der Nachricht "Shutting down Bot..." (Use Case: User-Information) und schreibt selbiges in den Log. (Use Case: Logging)
- Der Bot schreibt in den Log (Use Case: Logging) und informiert den User (Use Case: User-Information), mit der Meldung "Closing connection...".
- Der Bot schließt die Verbindung zum Server.
- Der Bot informiert den User und schreibt in den Log "Connection closed." (Use Case: User-Information, Logging)
- Der Bot schreibt in den Log und informiert den User mit der Nachricht "Bot shutdown complete." (Use Case: User-Information, Logging)
- Das Programm endet.Ausnahmen:
- Das Logging schlägt fehl. Der Bot ignoriert den Fehler und geht weiter vor wie geplant.===============================================================================================================================================================================
===============================================================================================================================================================================
KonsoleUser Story: Als Bot-Besitzer möchte ich, dass ich den Bot über die Konsole zu einem Server verbinden lassen kann.
Use Case: Console-Connect
Voraussetzungen:
- Der User hat in der Konsole einen gültigen Verbindungsbefehl eingegeben. ("connect <host>[:<port>]")
- Der Bot ist mit keinem Server verbunden.Beschreibung:
- Der User gibt in der Konsole "connect <host>[:<port>]" ein.
- Der Server verbindet sich über den Port <port> mit dem Host <host>. (Use Case: Connect)
- Die Plugins werden aktiviert.Ausnahmen:
- Der User hat weder Host, noch Port angegeben. Der User wird aufgefordert, eine gültige Eingabe zu machen, mit der Nachricht:
"Invalid parameters. Syntax: connect <host>[:<port>]"
- Der Bot ist bereits mit einem Server verbunden. Der User wird darüber informiert mit der Nachricht "Already connected to <host>:<port>.".
- Der User hat keinen Host angegeben. Der User wird mit der Fehlermeldung "Host missing for port <port>" darauf hingewiesen.
- Der User hat keinen Port angegeben. Der Bot versucht, sich auf Port 6667 (default IRC Port) mit dem Server zu verbinden. (Use Case: Connect)
- Der User hat keine gültige Portnummer angegeben. Er wird darauf mit der Fehlermeldung "Invalid port number." hingewiesen.-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
User Story: Als Besitzer des Bots möchte ich, dass der Bot auf Befehl die Verbindung zum Server beendet.
Use Case: Console-Disconnect
Voraussetzungen:
- Der User hat "disconnect" eingegeben.
- Der Bot ist mit einem Server verbunden.Beschreibung:
- Der User gibt "disconnect" in der Konsole ein.
- Der Bot informiert Plugins über den bevorstehenden Disconnect.
- Der Bot wartet die in der Config eingestellte Zeit, um den Plugins Zeit zu geben, Nachrichten zum Server zu senden.
- Der Bot schließt die Verbindung zum Server. (Use Case: Disconnect)
- Alle Plugins werden deaktiviert. (Use Case: Plugin-Shutdown)Ausnahmen:
- Der Bot ist mit keinem Server verbunden. Der User wird auf den Fehler mit der Nachricht "Not connected." informiert.
- In der Config ist keine Zeit eingestellt. Der Bot wartet 500 ms auf Beendigung.===============================================================================================================================================================================
So, das wars fürs erste, meine Motivation sinkt wieder. Vielleicht mache ich später noch weiter, ansonsten morgen.
-
===============================================================================================================================================================================
Konsole - Teil 2User Story: Als Bot-Besitzer möchte ich in der Konsole Plugins laden können, während der Bot läuft.
Use Case: Console-Plugin-Start
Voraussetzungen:
- Der Bot ist mit einem Server verbunden.
- Der Benutzer hat einen gültigen Plugin-Start Befehl eingegeben. (Syntax: "plugin start <plugin-name>", plugin-name = Dateiname ohne .plg Endung im plugins/ Ordner.)
- Das Plugin, das der Nutzer laden möchte, existiert.
- Das Plugin wurde noch nicht geladen.Beschreibung:
- Der Benutzer gibt "plugin start <plugin-name>" ein.
- Der Bot informiert den Benutzer, dass das Plugins gestartet wird, mit der Nachricht "Starting plugin <plugin-name>...".
- Der Bot startet das Plugin.
- Der Bot informiert den Nutzer, dass das Plugins gestartet wurde, mit der Nachricht "Plugins <plugin-name> started.".Ausnahmen:
- Der Bot ist mit keinem Server verbunden. Er wird durch die Meldung "Not connected." darauf hingewiesen.
- Das angegebene Plugin existiert nicht. Der Benutzer erhält die Fehlermeldung "Plugin <plugin-name> doesn't exist.".
- Das Plugin konnte nicht gestartet werden. Der Benutzer erhält die Fehlermeldung "Couldn't start plugin <plugin-name>.".
- Das Plugin wurde bereits gestartet. Der User wird darüber mit der Nachricht "Plugin already started." informiert.-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
User Story: Als Benutzer möchte ich Plugins über die Konsole deaktivieren.
Use Case: Console-Plugin-Stop
Voraussetzungen:
- Der User hat einen gültigen Plugin-Stop-Befehl eingegeben. (Syntax: "plugin stop <plugin-name>")
- Das Plugin existiert.
- Das Plugin wurde gestartet.
- In der Config wurde eine Plugin-Wartezeit angegeben.Beschreibung:
- Der Benutzer gibt "plugin stop <plugin-name>" ein.
- Der Bot informiert den Nutzer, dass das Plugin gestoppt wird, mit der Meldung "Stopping Plugin <plugin-name>...".
- Der Bot informiert das Plugin, dass es deaktiviert wird.
- Der Bot wartet die in der Config angegebene Wartezeit, um dem Plugin etwas Zeit zu geben, sich zu beenden.
- Wenn sich das Plugin nicht beendet hat, wird es vom Bot terminiert. Der User wird darauf mit der Meldung "Plugin <plugin-name> had to be terminated." hingewiesen.
- Der User wird informiert, dass der Vorgang beendet ist. Die Nachricht "Plugin <plugin-name> disabled." erscheint.Ausnahmen:
- Das Plugin existiert nicht. Der User wird darauf mit der Fehlemeldung "Plugin doesn't exist." hingewiesen.
- Das Plugin wurde nicht gestartet. Der Besitzer wird darauf mit der Fehlermeldung "Plugin not started." hingewiesen.
- In der Config wurde keine Wartezeit eingestellt. Der Bot wartet 500 ms auf Beendigung.===============================================================================================================================================================================
===============================================================================================================================================================================
Sonstige CasesUser Story: ???
Use Case: Connect
Voraussetzungen: Keine
Beschreibung:
- Der Bot versucht, den angegebenen Host zu finden.
- Der Bot verbindet sich mit dem Host über den angegebenen Port.Ausnahmen:
- Der Host wurde nicht gefunden. Der User wird über den Fehlschlag mit der Fehlermeldung "Host <host> not found." informiert. Dasselbe wird auch in den Log geschrieben.
- Der Verbindungsversuch schlägt fehl. Der Benutzer wird darüber mit der Fehlermeldung "Couldn't connect to host." informiert. Selbiges wird auch geloggt.-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
User Story: ???
Use Case: Config-Erstellung
Voraussetzungen: Keine
Beschreibung:
- Der Bot legt eine neue Datei mit dem Namen "bot.conf" an.
- Der Bot fügt folgende Zeilen ein:
"host="
"port="
"plugin-wait=500"Ausnahmen:
- Das Erstellen schlägt fehl. Der Bot fährt sich herunter. Der User wird darüber mit der Fehlermeldung "Couldn't create config file." informiert. Wird auch geloggt.
- Die Datei existiert bereits. Nichts passiert.
- Das Schreiben schlägt fehl. Der Bot fährt sich herunter. Der User wird darüber mit der Fehlermeldung "Couldn't create config file." informiert. Wird auch geloggt.-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
User Story: Als User möchte ich über jeden Vorgang informiert werden.
Use Case: User-Information
Voraussetzungen: Keine
Beschreibung:
- Der Bot fragt Uhrzeit und Datum vom System ab.
- Er setzt eine Nachricht wie folgt zusammen: "[dd.mm. - hh.mm.ss:ms] <msg>"
- Die Nachricht wird dem User mitgeteilt.Ausnahmen:
- Uhrzeit/Datum konnten nicht abgefragt werden. Die Nachricht wird ohne an den User weitergeleitet.-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
User Story: Als Besitzer des supertollen Bots von PI möchte ich, dass jeder Vorgang geloggt wird.
Use Case: Logging
Voraussetzungen: Keine
Beschreibung:
- Der Bot fragt Uhrzeit und Datum vom System ab.
- Er setzt eine Nachricht wie folgt zusammen: "[dd.mm. - hh.mm.ss:ms] <msg>"
- Die Nachricht wird in die Logdatei geschrieben.Ausnahmen:
- Uhrzeit/Datum konnten nicht abgefragt werden. Die Nachricht wird ohne in den Log geschrieben.
- Die Nachricht konnte nicht geschrieben werden. Der Bot fährt sich herunter.===============================================================================================================================================================================
So, damit dürfte ich alles haben.
Fehlt etwas?
-
Thread übersehen oder keine Lust so viel Text zu lesen hustbaer?
Wäre nett, wenn du mir doch noch antworten würdest.
-
ich hab auf jeden fall keine lust so viel text zu lesen. was mir auffällt ist, dass du nur beschreibst was der user möchte, und was das programm dann tut. aber wie kriegt das programm mit was der user möchte? was macht er, um sowas auszulösen?
-
Verstehe ich nicht. Der User hat zur Interaktion mit dem Programm die Konsole (wo ich dazugeschrieben habe, was der User eingibt.) und die Config-Datei (wo ich dazugeschrieben habe, welche Optionen es gibt.)
Kannst du mir das genauer erläutern?
-
das bezieht sich vor allem auf die letzten beiden punkte mit den infos und dem logging. evtl. ist das auch keine story, sondern sollte separat dokumentiert werden, weil es ja sowieso die ganze zeit im hintergrund mitläuft.
beim rest scheints zu passen. das ist auf jededn fall schonmal nendeutlich bessere grundlage als nix.
-
Vielen Dank für dein Feedback!
Wie sehen die nächsten Schritte in Richtung Erfolg aus? Ist der Punkt #1 hiermit abgeschlossen?
-
Ich möchte ja nicht aufdringlich sein, aber es wäre sehr nett, wenn mir jemand weiterhelfen könnte. Ich habe noch nie ein Projekt geplant - dementsprechend wenig erfolgreiche Projekte gehabt und weiß alleine nicht weiter.
-
Ja, Schritt 1 passt erstmal für den Anfang. Jetzt also das Design. Nimm dir dazu Zeit! Gehe möglichst in die Tiefe, viel wichtiger aber, gehe in die gesamte Breite, also behandle alle Teile des Bots. Und mache erst weiter, wenn du zufrieden bist. Überlege dabei, wie du Stellen schaffst, an denen das Design bei Bedarf leicht erweitert werden kann. Es ist sehr frustrierend, wenn du irgendwann Feature X implementieren möchtest und dann feststellst, dass das nur entweder mit umfangreichem Neuprogrammieren oder mit schlimmen Hacks geht.
Mit Sicherheit werden sich später bei der Programmierung noch Probleme im Design zeigen, bzw. Stellen, die man einfacher/besser umsetzen könnte. Das ist kein Problem. Aber arbeite trotzdem erstmal so lange am Design, bis du denkst, dass es passt und genau so auch funktionieren würde.
