65 lines
4.3 KiB
Markdown
65 lines
4.3 KiB
Markdown
---
|
|
tags:
|
|
- Methoden
|
|
---
|
|
Für das Erstellen der Thesis werden folgende Werkzeuge, die mit folgendem Zweck verwendet werden.
|
|
|
|
| Werkzeug | Zweck |
|
|
| ---------------------------- | -------------------------------------------------------- |
|
|
| Obsidian | Knowledge Graph, Persönliche Dokumentation, Organisation |
|
|
| Gitea | Online Repository und Code Organisation, Management |
|
|
| LaTeX / Typst | Schreiben der Thesis / Exposé |
|
|
| Zotero | Dokumentation und Datenbank der verwendeten Quellen |
|
|
| DrawIO / Mermaid | Graphenerstellung |
|
|
| VSCode | Development Environment |
|
|
| Python | Ausgewählte Programmiersprache |
|
|
| Docker / Podman | Containerisierung |
|
|
| Gitea Actions, Woodpecker CI | CI / CD |
|
|
| NGINX | Hosting der Dokumentation |
|
|
| Sphinx | Generierung der Dokumentation |
|
|
| pylint, yapf, isort | Code Linting |
|
|
| pre-commit | Linting Überprüfung vor Pushes auf Branches |
|
|
|
|
# Repository Strategien
|
|
|
|
## Branching
|
|
Für Sicherheitserhöhung soll parallel zum `main` Branch ein `beta` Branch existieren. Arbeitspakete gehen vom `beta` Branch aus und werden bereits dort durch die CI/CD-Pipeline. Damit soll mehrfach geprüft werden, dass implementierte Module / Features vernünftig funktionieren und Probleme nicht direkt auf den `main` Branch veröffentlicht werden.
|
|
|
|
## CI / CD
|
|
Für die CI/CD Pipeline sind folgende Module von Interesse:
|
|
1. Linter
|
|
2. Modultests
|
|
3. Automatische Generierung der Dokumentation
|
|
|
|
Für die CI/CD Pipeline wurde Woodpecker verwendet, dieses lässt sich in die bereits existierende Gitea Instanz hinzufügen. Zusätzlich ermöglicht dies eine Erweiterung der Integration und Development Pipelines im Sinne, dass von dort ein Automatisiertes Prüfen des Code-Stils und anschließend die Dokumentation erneuert werden kann.
|
|
# Code Stil
|
|
Für den Code Stil wird sich an die Vorgaben durch Google gehalten, folgender [Styleguide](https://google.github.io/styleguide/pyguide.html) wird dafür verwendet. Dem Linter wird dieses Styleguide ebenfalls übergeben, sodass die Code-Architektur Einheitlich durchgeführt wird.
|
|
|
|
Der Code-Stil wird durch mehrere Tools automatisiert begutachtet und beim nicht-einhalten kann kein Merging in den `main` Branch durchgeführt werden. Diese Tools sind folgende: *pre-commit*, *pylint*, *yapf*, *isort*
|
|
|
|
## Code Dokumentation
|
|
Zur Bereitstellung der Dokumentation wird [Sphinx](https://www.sphinx-doc.org/en/master/) verwendet.
|
|
|
|
|
|
|
|
# Dokumentation
|
|
Zusätzlich zur Code-Dokumentation wird in der Thesis die Dokumentation für die Programmnutzung als Anhang hinzugefügt werden.
|
|
|
|
|
|
# Architektur
|
|
Die Architektur wird anhand mehrere Prinzipien gestützt.
|
|
## Hybride Plug-in Layer + Pattern Architektur
|
|
|
|
## Analysis Orchestrator
|
|
_"Advantages include decoupling with logic layers, collating many functions, and acting as a centralized controller"_ [gaurgaurav+1](https://www.gaurgaurav.com/patterns/orchestration-pattern/)
|
|
|
|
Anhand des Orchestrators wird die Logikschicht und deren Plug-Ins orchestriert, sodass ein zentraler Controller für die Grundfunktionen und Erweiterungen existiert.
|
|
|
|
## Core Analysis
|
|
_"Predefined linguistic rules are used to analyze and process textual data... deterministic in nature, not probabilistic"_ [geeksforgeeks](https://www.geeksforgeeks.org/nlp/rule-based-approach-in-nlp/)
|
|
|
|
Dabei wird folgende Regel verfolgt:
|
|
_"A rule-based model is deterministic in nature... Either a document satisfies a given rule completely or it doesn't"_ [sas](https://support.sas.com/resources/papers/proceedings17/SAS0587-2017.pdf)
|
|
|
|
Die Umsetzung erfolgt Algorithmisch anstelle von mit KI wegen folgender Problematik:
|
|
_"Rule-based approach produces fewer minor hallucinations than neural counterparts"_ [aclanthology](https://aclanthology.org/2024.inlg-main.48.pdf) |