Motivation bei Privatprojekten (Split aus Diamond of Death)
-
===============================================================================================================================================================================
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.
-
Was wird bei einem Design geplant? Nur das Interface (public/protected Methoden)? Oder doch schon mit Sachen, die zur Implementierung (private) gehören?
Gibt es irgendwelche Methoden, die sich beim Designen als besonders gut erwiesen haben?(Ja, ich will alles wissen
)
-
Nur public/protected, also die Schnittstellen. Die Implementierung ist erstmal völlig egal (natürlich solltest du dir aber trotzdem Gedanken machen, dass man das Designte auch irgendwie vernünftig implementieren kann). Die Form ist eigentlich weitgehend dir überlassen. UML ist relativ verbreitet. Ich z.B. nehme gerne ein paar Zettel und schreibe die Klassen mit deren Interfaces auf, die ich brauche. Außerdem sehr hilfreich ist ein Diaramm, wie welche Klasse mit welcher zusammenspielt.
Aber wie gesagt: im Prinzip kannst du das machen, wie du willst. Wichtig ist das Ergebnis: du musst wissen, wie das Programm strukturiert sein wird, d.h. welche Teile/Module/Klassen/etc. es gibt und wie genau diese zusammenspielen.
-
314159265358979 schrieb:
Gibt es irgendwelche Methoden, die sich beim Designen als besonders gut erwiesen haben?
Strenges Prüfen aller Tips, ob sie nicht eher religiöser Natur sind. Da sehe ich bei Dir größte Gefahr. Ablehnen von Shlaer-Mellor. UML nicht als Planungswerkzeug benutzen. Ich glaube nicht, daß mangelnde Planung überhaupt etwas mit Deinem Problem zu tun hat. Deine Projekte kippen ja nicht um, werden nicht unwartbar wegen schlechtem Anfang, eröffnen nicht, daß der Anfang ganz falsch war. Sondern Du verlierst einfach die Lust, sobald Du herausgefunden hat, wie es geht. Deswegen lernst Du auch so schnell, auffallen schnell, würde ich sagen. Was Du brauchst, sind ein paar FIAEs, die den Rest für Dich erledigen. Oder einen Chef, der sehr sehr traurig wird, wenn Du das Projekt nicht fertig machst.
-
Die Sache ist die: Ich möchte endlich mal ein Projekt, das ich auch herzeigen kann. Wenn ich die Leute im IRC sehe, wie der erste mit seinem 3D-Spiel mit Raumkrümmung, der nächste mit seinem siebzehnten IRC-Daemon und der dritte mit einer eigenen Programmiersprache daherkommt, fragt man sich, ob man nicht doch irgendwas falsch macht.
-
volkard schrieb:
Strenges Prüfen aller Tips, ob sie nicht eher religiöser Natur sind.
[...]
UML nicht als Planungswerkzeug benutzen.
genau.
UML ist auch kein Planungswerkzeug sondern eine Möglichkeit einen Entwurf (eine Planung) graphisch darzustellen, nicht mehr und nicht weniger. Warum Du da immer noch religiös dagegen eiferst ist mir völlig unklar. Warum schadet es, nachdem man siche ne Liste der wichtigsten Klassen gemacht hat, sich Boxen zu malen, da die Klassennamen reinzuschreiben und Klassen die sich vermutlich kennen müssen mit ner Linie zu verbinden? Wo ist das Problem? Menschen arbeiten stark visuell, das auszunutzen ist doch kein Fehler.
@314159265358979: überleg dir, was die wichtigsten klassen sind, was die ungefähr für schnittstellen brauchen und welche Klassen (bzw. Instanzen davon) sich kennen müssen. Ob Du auf dem richtigen Weg bist kannst Du leicht überprüfen, indem Du mal versuchst dir zu überlegen wie Du jetzt die Use-Cases abhandeln würdest, wer müßte dafür wen wann und mit welchen Informationen aufrufen? Kennen die die benötigten Objekte und können sie sich die benötigen Informationen besorgen? Wenn nicht, hast Du vermutlich noch ein paar Verbindungen übersehen.
-
Jester schrieb:
UML ist auch kein Planungswerkzeug sondern eine Möglichkeit einen Entwurf (eine Planung) graphisch darzustellen, nicht mehr und nicht weniger.
Wird aber in Schule, Berufsschule und Studium als Planungswerkzeug gelehrt.
Jester schrieb:
Warum Du da immer noch religiös dagegen eiferst ist mir völlig unklar.
So, wie ich auch religiös gegen den Papst eifere.
-
Jester schrieb:
genau.
UML ist auch kein Planungswerkzeug sondern eine Möglichkeit einen Entwurf (eine Planung) graphisch darzustellen, nicht mehr und nicht weniger. Warum Du da immer noch religiös dagegen eiferst ist mir völlig unklar. Warum schadet es, nachdem man siche ne Liste der wichtigsten Klassen gemacht hat, sich Boxen zu malen, da die Klassennamen reinzuschreiben und Klassen die sich vermutlich kennen müssen mit ner Linie zu verbinden? Wo ist das Problem? Menschen arbeiten stark visuell, das auszunutzen ist doch kein Fehler.
volkard is halt in vielen Bereichen ziemlich... verbohrt.
-
volkard schrieb:
UML nicht als Planungswerkzeug benutzen.
Jester schrieb:
UML ist auch kein Planungswerkzeug
this->that schrieb:
volkard is halt in vielen Bereichen ziemlich... verbohrt.
Ich hätte auch feststellen können, daß Gras grün ist; es wird jemanden geben, der mir das zur Last legt.
-
Weil das bei Dir klingt, als müsse man sich von UML fernhalten. Das ist aber eigentlich überhaupt kein Kriterium. UML bietet nichts anderes als eine "Sprache", in der man Entwürfe aufmalen kann. Da ist meiner Meinung nach nichts falsches dran. Oder wie siehst Du das? Natürlich muß man nach wie vor selber nachdenken welche Klasse welche Funktionalität bietet, welche Interfaces sich kennen sollen etc. Das kann einem aber auch keiner abnehmen.
Zugegeben, vieles an UML ist überladen, mir genügen zum Beispiel Boxen für Klassen, ungerichtete Verbindungen, evtl. besondere Pfeile für Vererbung und Gruppierungen durch Pakete; für das hier angestrebte Projekt ist das mit Sicherheit vollkommen ausreichend. Man mag sich streiten, ob man das noch UML nennen mag (ich würde aber schon dazu tendieren). Aber hilfreich ist das doch allemal.
Wenn Du das Gefühl hast, dass UML zu stark als Planungswerkzeug und zu wenig als Konvention fürs Aufmalen von Planungsergebnissen (bzw. deren Evolution) verstanden wird, warum arbeitest Du dann nicht eher dagegen als gegen das komplette Konzept UML? Das komplette Ablehnen wirkt dagegen einfach nur stur und wenig begründet.
-
Jester schrieb:
Wenn Du das Gefühl hast, dass UML zu stark als Planungswerkzeug und zu wenig als Konvention fürs Aufmalen von Planungsergebnissen (bzw. deren Evolution) verstanden wird, warum arbeitest Du dann nicht eher dagegen als gegen das komplette Konzept UML? Das komplette Ablehnen wirkt dagegen einfach nur stur und wenig begründet.
volkard schrieb:
314159265358979 schrieb:
Gibt es irgendwelche Methoden, die sich beim Designen als besonders gut erwiesen haben?
Strenges Prüfen aller Tips, ob sie nicht eher religiöser Natur sind. Da sehe ich bei Dir größte Gefahr. Ablehnen von Shlaer-Mellor. UML nicht als Planungswerkzeug benutzen. Ich glaube nicht, daß mangelnde Planung überhaupt etwas mit Deinem Problem zu tun hat. Deine Projekte kippen ja nicht um, werden nicht unwartbar wegen schlechtem Anfang, eröffnen nicht, daß der Anfang ganz falsch war. Sondern Du verlierst einfach die Lust, sobald Du herausgefunden hat, wie es geht. Deswegen lernst Du auch so schnell, auffallen schnell, würde ich sagen. Was Du brauchst, sind ein paar FIAEs, die den Rest für Dich erledigen. Oder einen Chef, der sehr sehr traurig wird, wenn Du das Projekt nicht fertig machst.
Nö, da bist Du hochgegangen, weil ich meinen dreckigen Finger auf eine Wunde legte.
Jester schrieb:
Aber hilfreich ist das doch allemal.
Hier liegt der Hund begraben.
-
volkard schrieb:
Nö, da bist Du hochgegangen, weil ich meinen dreckigen Finger auf eine Wunde legte.
Quark, Du hast offensichtlich eine UML-Wunde, die Du bei jeder Gelegenheit auspackst. Und genau da leg ich grad den Finger rein, und was kommt? Gejaule aber kein einziges Argument. Schade.
An das Mär vom Projekt, das nur scheitert weil jetzt alles ganz einfach ist, glaube ich nicht. Insofern halte ich Deine Analyse für falsch und auch für kontraproduktiv. Wenn ein Projekt scheitert, sollte man sich vielleicht mal überlegen woran es genau gelegen hat. Da scheint mir die Erklärung, dass die immer alle zu leicht waren auf Dauer nicht sehr befriedigend.
-
Jester schrieb:
und was kommt? Gejaule aber kein einziges Argument. Schade.
Wie sind doch einer Meinung, was UML als Planungswerkzeug angeht.
Jester schrieb:
Da scheint mir die Erklärung, dass die immer alle zu leicht waren auf Dauer nicht sehr befriedigend.
Das war nicht meine Erklärung.