wiki.ziemers.de

ziemer's informatik Wiki

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Zuletzt angesehen:
wiki:software:beuthbot:berichte:ss2020:zwischen

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung 		Vorhergehende Überarbeitung
wiki:software:beuthbot:berichte:ss2020:zwischen [04.06.2020 12:35]
Lukas Danckwerth 		wiki:software:beuthbot:berichte:ss2020:zwischen [04.06.2020 15:58] (aktuell)
Lukas Danckwerth
Zeile 8: Zeile 8:
   * Denny Schumann   * Denny Schumann
  
-====Übersicht (Fragen, die beantwortet werden sollten)====+====Inhaltsangabe==== 
 +   
 +  - Einleitung / Aktueller Stand 
 +  - BeuthBot-Projekt 
 +  - deconcentrator-js 
 +  - Virtuellen Machine 
 +  - Funktionale Anforderungen 
 +  - Persistenz & Cache 
 +  - Microservices 
 +  - Ausblick 
  
 ===Was haben wir vorgefunden?=== ===Was haben wir vorgefunden?===
Zeile 64: Zeile 73:
  
 Nun wurde der Beuth Bot gestartet, konnte allerdings nicht in Betrieb genommen werden, da dieser keine Netzwerkverbindung nach draußen hatte. Daraufhin wurde uns ein Server auf der Beuth zur verfügung gestellt, auf welchem der Beuth Bot letztendlich laufen sollte. Nachdem dieser dort versucht wurde eingerichtet zu werden, fehlte es dem Server an zugewiesenem Speicher, was erst behoben werden musste um den Bot vollständig installieren und in Betrieb nehmen zu können. Es konnten nach der Behebung des fehlenden Speichers letztendlich fast alle Docker-Container erfolgreich gestartet werden, bis auf den Service Deconcentrator, welcher sich erst nicht richtig starten ließ und als er lief nicht funktionierte.  Nach mehreren Wochen der Versuche diesen Service zum laufen zu bekommen entschieden wir uns in Absprache mit Herrn Ziemer diesen zu verwerfen und einen neuen Deconcentrator zu schreiben.  Nun wurde der Beuth Bot gestartet, konnte allerdings nicht in Betrieb genommen werden, da dieser keine Netzwerkverbindung nach draußen hatte. Daraufhin wurde uns ein Server auf der Beuth zur verfügung gestellt, auf welchem der Beuth Bot letztendlich laufen sollte. Nachdem dieser dort versucht wurde eingerichtet zu werden, fehlte es dem Server an zugewiesenem Speicher, was erst behoben werden musste um den Bot vollständig installieren und in Betrieb nehmen zu können. Es konnten nach der Behebung des fehlenden Speichers letztendlich fast alle Docker-Container erfolgreich gestartet werden, bis auf den Service Deconcentrator, welcher sich erst nicht richtig starten ließ und als er lief nicht funktionierte.  Nach mehreren Wochen der Versuche diesen Service zum laufen zu bekommen entschieden wir uns in Absprache mit Herrn Ziemer diesen zu verwerfen und einen neuen Deconcentrator zu schreiben. 
 +
 +===Resultierende Aufgaben===
 +
 +  * Dokumentation komplettieren / umstruktorieren
 +  * Den alten deconcentrator "rausschmeissen" und neuen (deconcentrator-js) schreiben
 +  * Übergeordnetes Git Projekt erstellen mit Paketen als Submodule
  
 ===Wo stehen wir gerade?=== ===Wo stehen wir gerade?===
 Aktuell Ist der Beuth Bot vollständig in Betrieb genommen, dank des neu geschriebenen Deconcentrators. Ebenso liegt dieser nun, auf einem für uns zugreifbaren Server, welcher dort erfolgreich in Betrieb genommen wurde. Auch wurde er nun ermöglicht den gesamten Bot, welcher 8 Services beinhaltet mit zwei docker-compose files zu starten. Das Projekt wurde nun in 2 Git Submodule unterteilt, welche in Zukunft leichter bearbeitet werden können. Ebenfalls wurden sowohl in diesem Semester zu bearbeitende, also auch zukünftige Projektideen erschlossen. Die Arbeitsteilung der einzelnen Gruppenmitglieder wurde durchgeführt und ein Zwischenbericht wurde angelegt. Aktuell Ist der Beuth Bot vollständig in Betrieb genommen, dank des neu geschriebenen Deconcentrators. Ebenso liegt dieser nun, auf einem für uns zugreifbaren Server, welcher dort erfolgreich in Betrieb genommen wurde. Auch wurde er nun ermöglicht den gesamten Bot, welcher 8 Services beinhaltet mit zwei docker-compose files zu starten. Das Projekt wurde nun in 2 Git Submodule unterteilt, welche in Zukunft leichter bearbeitet werden können. Ebenfalls wurden sowohl in diesem Semester zu bearbeitende, also auch zukünftige Projektideen erschlossen. Die Arbeitsteilung der einzelnen Gruppenmitglieder wurde durchgeführt und ein Zwischenbericht wurde angelegt.
  
-  * was werden wir tun?+===Wo werden wir tun?=== 
 +Zusammengefasst, werden wir den Scraper Microservice fertigstellen und anpassen, eine Persistenz hinzufügen die es dem System erlaubt Präferenzen vom User zu speichern, den Wetter Microservice anpassen, einen Cache hinzufügen und zwei neue Microservices namens Schedule (Stundenplan) und Finals (Prüfungen) hinzufügen.
  
-====Challenges / Barriers==== +Auf diese Punkte wird im weiteren Verlauf dieses Dokuments eingegangen.
- +
-  * Complex Project Structure +
-  * Bad documentation of final state. So we ... +
-  * Focused to long on the image of virtual machine +
-  * Bad documentation of JSON format of messages +
-  * Running out of space on Virtual Machine +
-  * Current Situation with the Corona Virus +
- +
-====Needs For Action==== +
- +
-  * Complete Documentation +
-  * "Kick out" the `deconcentrator` and `scraper` +
-  * Create a master project containing the packages as submodules +
-====Done so far==== +
- +
-===Model of Messages of Telegram Bot=== +
- +
-<uml> +
-@startuml +
-class Message { +
-  message_id: Integer +
-  from: User +
-  chat: Chat +
-  date: Long +
-  text: String +
-} +
- +
-class User { +
-   id: Integer +
-   is_bot: Boolean +
-   first_name: String +
-   username: String +
-   language_code: String +
-} +
- +
-class Chat { +
-   id: Integer +
-   first_name: String +
-   username: String +
-   type: String +
-} +
- +
-Message *--- User +
-Message *--- Chat +
- +
-@enduml +
-</uml>+
  
 ===BeuthBot Project (One Git Repository)=== ===BeuthBot Project (One Git Repository)===
Zeile 231: Zeile 200:
  
 https://github.com/beuthbot/deconcentrator-js https://github.com/beuthbot/deconcentrator-js
 +
 +The deconcentrator uses different NLU processors to compare their results and tries to choose an best fitting answer. The NLU processors like RASA must know their domain on their own. The deconcentrator simply compares the confidence score of the intents given from the processors and returns the intent with the highest score.
 +
 +==Functionality==
 +
 +<uml>
 +@startuml
 +
 +participant "gateway" as GW
 +
 +box "deconcentrator-js" #LightBlue
 +participant "deconcentrator.js" as DC
 +participant "processor-queue.js" as PQ
 +participant "rasa-processor.js" as RP
 +participant "PROC_1.js" as P1
 +participant "PROC_2.js" as P2
 +end box
 +
 +GW -> DC: request\nwith message
 +activate DC
 +DC -> DC: create and fill queue
 +DC -> PQ: run
 +activate PQ
 +PQ -> RP: (async) request
 +activate RP
 +PQ -> P1: (async) request
 +activate P1
 +RP -> PQ: interpretation
 +deactivate RP
 +PQ -> P2: (async) request
 +activate P2
 +P1 -> PQ: interpretation
 +deactivate P1
 +P2 -> PQ: interpretation
 +deactivate P2
 +PQ -> DC: all\ninterpretations
 +deactivate PQ
 +DC -> DC: filter out\nbest intent
 +DC -> GW: response\nwith intent
 +deactivate DC
 +
 +@enduml
 +</uml>
 +
 +==processor-queue.js==
 +
 +For every incoming message the deconcentrator creates a new `ProcessorQueue` (defined in `processor-queue.js`) and adds all available processors to it. When calling the `.interpretate(message)` function of the queue it starts requesting the processors for an interpretation. The number of asynchronous requests can be set with the `numOfSynchronProcessors` property of the queue.
 +
 +==processor.js==
 +
 +Defines the interface of a NLU processor.
 +
 +==API==
 +
 +The following lists the resources that can be requested with the deconcentrator API.
 +
 +Request life sign.
 +
 +<code>
 +GET   http://localhost:8338
 +</code>
 +
 +Answer:
 +
 +<code>
 +Hello from BeuthBot Deconcentrator: 0.1.1
 +</code>
 +
 +Request interpretation of message.
 +
 +<code>
 +POST  http://localhost:8338/messages
 +</code>
 +
 +==Request Schema==
 +
 +<code>
 +{
 +  "text": "Wie wird das Wetter morgen?",
 +  "min_confidence_score": 0.8,
 +  "processors": ["rasa"]
 +}
 +</code>
 +
 +Whereas the specification of the min_confidence_score and theprocessors is optional. If not minimum confidence score is given a default one is used (by now this is 0.8). For now there is only the usage of RASA implemented so there is no effect of specifying the processors property.
  
 Model of an incoming message. Model of an incoming message.
Zeile 244: Zeile 298:
 </uml> </uml>
  
-Model of an answer from deconcentrator.+==Response Schema== 
 + 
 +The response for a successfully processed request to the deconcentrator contains the following information. 
 + 
 +<code> 
 +{ 
 +  "intent": { 
 +    "name": "wetter", 
 +    "confidence": 0.9518181086 
 +  }, 
 +  "entities": [ 
 +    { 
 +      "start": 20, 
 +      "end": 26, 
 +      "text": "morgen", 
 +      "value": "2020-01-20T00:00:00.000+01:00", 
 +      "confidence": 1.0, 
 +      "additional_info": { 
 +          "values": [ 
 +              { 
 +                  "value": "2020-01-20T00:00:00.000+01:00", 
 +                  "grain": "day", 
 +                  "type": "value" 
 +              } 
 +          ], 
 +          "value": "2020-01-20T00:00:00.000+01:00", 
 +          "grain": "day", 
 +          "type": "value" 
 +      }, 
 +      "entity": "time" 
 +    } 
 +  ], 
 +  "text": "Wie wird das Wetter morgen?" 
 +} 
 +</code> 
 + 
 +Model of an answer.
  
 <uml> <uml>
Zeile 283: Zeile 373:
 @enduml @enduml
 </uml> </uml>
 +
 +The response for a unsuccessfully processed request to the deconcentrator or when an error occures contains the following information.
 +
 +<code>
 +{
 +  "error": "The given message can't be interpretated.",
 +  "text": "Wie wird das Wetter morgen?"
 +}
 +</code>
 +
 +==Requirements Analysis deconcentrator.js==
 +
 +  * /DCF100/ The deconcentrator responds to incoming POST requests by delegating the message to a collection of NLU processor which try to interpretate the given message
 +  * /DCF101/ The deconcentrator accepts incoming messages as defined via the Request Schema
 +  * /DCF102/ The deconcentrator sends answers as defined via the Response Schema
 +  * /DCF103/ The deconcentrator answers with proper messages for occuring errors
 +  * /DCF104/ New NLU processors muss be easy to integrate
 +  * /DCF105/ The deconcentrator has a default value for the minimum confidence score
 +  * /DCF106/ The deconcentrator has a default value for the list of processors
 +  * /DCF107/ The minimum confidence score can be set globally within the Dockerfile
 +  * /DCF108/ The list of processors to be used can be set globally within the Dockerfile
  
 ===Deploying on Virtual Machine=== ===Deploying on Virtual Machine===
Zeile 426: Zeile 537:
 </code> </code>
  
-Current output of `docker ps` on virtual machine:+==Contents of .env file== 
 +Following lists the contents of the .env file of the telegram-bot project. Note that the value for TELEGRAM_TOKEN has been removed for security reasons. 
 + 
 +<code> 
 +GATEWAY_ENDPOINT=http://172.17.0.1:3000 
 +TELEGRAM_TOKEN=        # removed 
 +</code> 
 + 
 +==Contents of docker-compose.yml file== 
 +Following lists the contents of the docker-compose.yml file of the BeuthBot project. 
 + 
 +<code> 
 +version: '3.7' 
 +services: 
 +  telegram-bot: 
 +    build: . 
 +    restart: unless-stopped 
 +    environment: 
 +      - GATEWAY_ENDPOINT 
 +      - TELEGRAM_TOKEN 
 +</code> 
 + 
 +==Current output of `docker ps` on virtual machine:==
  
 <code> <code>
Zeile 440: Zeile 573:
 </code> </code>
  
 +Both projects contains a update.sh file which can be used to fast update the projects.
  
 ====Requirements==== ====Requirements====
 +
 +**Funktionale Anforderungen:**
 +
 +''/F100/'' Das System muss den User fragen, ob er möchte dass seine Präferenzen gespeichert werden.
 +
 +''/F101/'' Das System muss die User-Präferenzen in einer Datenbank speichern können.
 +
 +''/F102/'' Das System muss die Responses der Microservices in einem Cache zwischenspeichern.
 +
 +''/F103/'' Das System muss den User an Termine und Prüfungen erinnern.
 +
 +''/F200/'' Das System muss die Prüfungen von der Beuth Prüfungs-Website scrapen.
 +
 +''/F201/'' Das System muss die PDF die das System vom User bekommt verarbeiten können.
 +
 +''/F202/'' Das System muss dem User die Möglichkeit bieten einen Stundenplan manuell anzulegen.
 +
 +''/F203/'' Das System muss dem User die Möglichkeit bieten einen Stundenplan per PDF anzulegen.
 +
 +**Nicht-Funktionale Anforderungen:**
 +
 +''/NF100/'' Das System sollte Nachrichten innerhalb von 3 Sekunden beantworten.
 +
 +''/NF101/'' Das System sollte so modular wie möglich aufgebaut sein.
 +
 +''/NF102/'' Das System sollte eine Downtime von maximal 1% haben.
 +
 +''/NF103/'' Die Datenbank sollte eine Downtime von maximal 1% haben.
 +
 +''/NF200/'' Das System sollte DSGVO konform sein.
 +
 +''/NF201/'' Das System sollte standard Sicherheitsvorkehrungen besitzen.
  
 ===Persistence=== ===Persistence===
  
 Damit der Benutzer sich selbst nicht ständig wiederholen muss, wird ihm die Möglichkeit geboten, seine Vorlieben zu speichern. Als Datenbank haben wir uns für die MongoDB entschieden. Damit der Benutzer sich selbst nicht ständig wiederholen muss, wird ihm die Möglichkeit geboten, seine Vorlieben zu speichern. Als Datenbank haben wir uns für die MongoDB entschieden.
 +
 +<uml>
 +@startuml
 +actor "User" as U
 +rectangle "telgram-bot" as TGB
 +package "BeuthBot" {
 +  rectangle "gateway" as GW
 +  package "Persistence" {
 +    rectangle "database-container" as DBC
 +    database "DB_NAME" {
 +    }
 +  }
 +}
 +
 +U -down-> TGB
 +TGB -right-> GW
 +GW -left-> TGB
 +
 +GW -up-> DBC
 +DBC -down-> GW
 +
 +DB_NAME -right-> DBC
 +DBC -left-> DB_NAME
 +@enduml
 +</uml>
  
 ===Cache=== ===Cache===
Zeile 562: Zeile 752:
  
 ====Goal for end of semester==== ====Goal for end of semester====
 +
 +Following diagram demonstrates the current state of the working component of the BeuthBot.
  
 Current State: Current State:
Zeile 598: Zeile 790:
 </uml> </uml>
  
-Target State:+Following diagram demonstrates the target state of the working component of the BeuthBot.
  
 <uml> <uml>
Zeile 620: Zeile 812:
     rectangle "weather" as WS     rectangle "weather" as WS
     rectangle "mensa" as MS     rectangle "mensa" as MS
-    rectangle "NEW_SER_1" as NS1 +    rectangle "schedule" as NS1 
-    rectangle "NEW_SER_2" as NS2+    rectangle "scraper" as NS2 
 +    rectangle "pdf-reader" as NS3
   }   }
 } }
Zeile 651: Zeile 844:
 RE -up-> NS2 RE -up-> NS2
 NS2 -down-> RE NS2 -down-> RE
 +RE -up-> NS3
 +NS3 -down-> RE
  
 DB_NAME -right-> DBC DB_NAME -right-> DBC
Zeile 669: Zeile 864:
  
 -- Implementation -- -- Implementation --
-[Persist user preferences] as [I1] lasts 30 days and starts 5 days after [C]'s end +[Persist user preferences (Lukas & Tobias)] as [I1] lasts 30 days and starts 5 days after [C]'s end 
-[Cache microservices responses] as [I2] lasts 30 days and starts 5 days after [C]'s end +[Cache microservices responses (Jan)] as [I2] lasts 30 days and starts 5 days after [C]'s end 
-[Transform scraper microservice] as [I3] lasts 30 days and starts 5 days after [C]'s end +[Transform scraper microservice (Denny & Jan)] as [I3] lasts 30 days and starts 5 days after [C]'s end 
-[Adjust weather microservice] as [I4] lasts 30 days and starts 5 days after [C]'s end +[Adjust weather microservice (Denny)] as [I4] lasts 30 days and starts 5 days after [C]'s end 
-[New course schedule microservice] as [I5] lasts 30 days and starts 5 days after [C]'s end+[New course schedule microservice (?) (Denny & Jan)] as [I5] lasts 30 days and starts 5 days after [C]'s end
 [C] -> [I1] [C] -> [I1]
 [C] -> [I2] [C] -> [I2]
Zeile 679: Zeile 874:
 [C] -> [I4] [C] -> [I4]
 [C] -> [I5] [C] -> [I5]
 +[D] is 80% completed
 [I1] is 0% completed [I1] is 0% completed
 [I2] is 0% completed [I2] is 0% completed
wiki/software/beuthbot/berichte/ss2020/zwischen.1591266946.txt.gz · Zuletzt geändert: 04.06.2020 12:35 von Lukas Danckwerth

Seiten-Werkzeuge