Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- wiki:software:beuthbot:software-architecture [10.12.2019 19:01]
Christopher Lehmann
+++ wiki:software:beuthbot:software-architecture [23.01.2020 15:30] (aktuell)
Timo Bruns [Software Architecture]
@@ Zeile 1: / Zeile 1: @@
 ===== Software Architecture =====
-==== Table of Contents ====
+==== Table of content ====
-<!-- TOC depthFrom:2 depthTo:6 withLinks:1 updateOnSave:1 orderedList:0 -->
+	- [[wiki:software:beuthbot:software-architecture#table of content|Table of content]]
+	- [[wiki:software:beuthbot:software-architecture#overview|Overview]]
-- [Table of Contents](#table-of-contents)
+	- [[wiki:software:beuthbot:software-architecture#basic structure|Basic Structure]]
-- [Overview](#overview)
+		- [[wiki:software:beuthbot:software-architecture#bot|Bot]]
-- [Basic Structure](#basic-structure)
+		- [[wiki:software:beuthbot:software-architecture#gateway|Gateway]]
-	- [Bot](#bot)
+		- [[wiki:software:beuthbot:software-architecture#registry|Registry]]
-	- [Gateway](#gateway)
+		- [[wiki:software:beuthbot:software-architecture#service|Service]]
-	- [Registry](#registry)
+	- [[wiki:software:beuthbot:software-architecture#api|API]]
-	- [Service](#service)
-- [API](#api)
-<!-- /TOC -->
 ==== Overview ====
-_BeuthBot_ consists of many interwoven _Microservices_. Evey Microservice uses our basic API to communicate with other Microservices. This approach enables us to change parts of the system easily at any time or to introduce new Microservices, all they need to do is to implement our API.
+//BeuthBot// consists of many interwoven //Microservices//. Evey Microservice uses our basic API to communicate with other Microservices. This approach enables us to change parts of the system easily at any time or to introduce new Microservices, all they need to do is to implement our API.
 ==== Basic Structure ====
@@ Zeile 26: / Zeile 22: @@
 > Bot <=> Gateway <=> Registry <=> Service
-Following diagram shows that in more detail.
+Following diagram shows that in more detail:
-![structure](../assets/structure-without-notes.png)
+<uml>
+abstract class Bot
+class TelegramBot
+class TwitterBot
-A user can write the _Bot_ to request informations, the meaning of the message is extracted and a fitting _Microservice_ is choosen to retrieve the necessary data. A response is build from that data and distributed back up to the bot which answers the users request.
+Bot <|-- TelegramBot
+Bot <|-- TwitterBot
-following sequence diagram further illustrates that.
+class Gateway
+class MetaMetaPersistence
+class MetaPersistence
-![flow](../assets/flow.png)
+package nlp {
+class "rasa-ai"
+class "drools"
+class "Google Cloud Speech API"
+class "Google Cloud Natural Language"
+class "Microsoft Azure Spracherkennungs-API"
+class "Microsoft Azure Textanalyse-API"
+"Google Cloud Speech API" -> "Google Cloud Natural Language"
+"Microsoft Azure Spracherkennungs-API" -> "Microsoft Azure Textanalyse-API"
+}
+Gateway -- nlp
+Bot "1..*" -- Gateway
+Gateway -- MetaMetaPersistence
+class Registry
+Gateway "1" -- "1" Registry
+Registry -- MetaPersistence
+abstract class Service
+class MensaService
+Service <|-- MensaService
+Service <|-- WetterService
+Registry "1" -- "*" Service
+</uml>
+A user can write the //Bot// to request informations, the meaning of the message is extracted and a fitting //Microservice// is choosen to retrieve the necessary data. A response is build from that data and distributed back up to the bot which answers the users request.
+Following sequence diagram further illustrates that:
+<uml>
+Bot -> Gateway : request
+Gateway -> nlp : request
+Gateway <- nlp : request<message>
+Gateway -> Registry : request<message>
+Registry -> Service : request<message>
+Service -> Registry : response
+Registry -> Gateway : response
+Gateway -> nlp : response (text)
+nlp->Gateway : response (audio)
+Gateway -> Bot : response (text|audio)
+</uml>
 === Bot ===
-This is an abstraction for the available chatbots, e.g. a _Bot_ for _Telegram_ and another _Bot_ for _WhatsApp_.
+This is an abstraction for the available chatbots, e.g. a //Bot// for //Telegram// and another //Bot// for //WhatsApp//.
-The user interacts with this _Microservice_, here she can request information and gets answers from _BeuthBot_.
+The user interacts with this //Microservice//, here she can request information and gets answers from //BeuthBot//.
 === Gateway ===
-The _Gateway_ is the centerpiece of _BeuthBot_ one could say.
+The //Gateway// is the centerpiece of //BeuthBot// one could say.
-The _Bot_ notifies the _Gateway_ with the message it got from the user.
+The //Bot// notifies the //Gateway// with the message it got from the user.
-The _Gateway_ then uses NLP (Natural Language Processing) _Microservices_ to get the meaning and intention of the user. Here we try to extract what the user wants from _BeuthBot_, to notify the right service and present a fitting answer to our user.
+The //Gateway// then uses NLP (Natural Language Processing) //Microservices// to get the meaning and intention of the user. Here we try to extract what the user wants from //BeuthBot//, to notify the right service and present a fitting answer to our user.
 === Registry ===
-After obtaining the intention of our user, the _Gateway_ notifies the _Registry_, to get the information the user requested.
+After obtaining the intention of our user, the //Gateway// notifies the //Registry//, to get the information the user requested.
-The Registry distributes the request to the correct _Service_, that takes care of retrieving the right informations.
+The Registry distributes the request to the correct //Service//, that takes care of retrieving the right informations.
 === Service ===
-_Service_ is an abstraction for the implemented _Microservices_ that retrieve the necessary data we need to answer users requests. E.g. the _MensaService_ is a _Microservice_ that can give informations about the current menu, filtered by a number of parameters, e.g. a vegan user.
+//Service// is an abstraction for the implemented //Microservices// that retrieve the necessary data we need to answer users requests. E.g. the //MensaService// is a //Microservice// that can give informations about the current menu, filtered by a number of parameters, e.g. a vegan user.
 ==== API ====
-Because of the complexity of the single _Microservices_, every single _Microservice_ implements its own, distinct, API.
+Because of the complexity of the single //Microservices//, every single //Microservice// implements its own, distinct, API.
-But to answer a users request we use a unified, comprehensive API. Its basic idea is to pass a _Response_-Object trough the individual _Microservices_, which consists of the initial request, an answer as a response to the users request and informations about the user.
+But to answer a users request we use a unified, comprehensive API. Its basic idea is to pass a //Response//-Object trough the individual //Microservices//, which consists of the initial request, an answer as a response to the users request and informations about the user.
 Following class diagram further illustrates that:
-![flow](../assets/response-request-api.png)
+<uml>
+class Request {
+platform
+userId
+message: Message
+history: Trace
+metadata: KeyValueStore
+answer(): Response
+}
+class Message {
+id: unique
+evaluated: Meaning
+evaluate()
+}
+Request *-- Message
+Response -- Request
+class Response {
+request: Request
+answer
+history: Trace
+}
+class TextMessage {
+content
+}
+class AudioMessage {
+url
+}
+Message <|-- AudioMessage
+Message <|-- TextMessage
+</uml>
+<WRAP pagebreak></WRAP>

wiki.ziemers.de

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge