73 lines
4.0 KiB
Markdown
73 lines
4.0 KiB
Markdown
VisuAlg ist eine Software zur Visualisierung von Algorithmen und Datenstrukturen.
|
|
Sie kommt leider schon lange nicht mehr in der Vorlesung "Algorithmen und Datenstrukturen" zum Einsatz.
|
|
|
|
-------
|
|
|
|
VisuAlg wurde in der Vergangenheit von Bachelor- und Masterstudierenden im Zuge ihres Softwareprojekts entwickelt.
|
|
Dieses Projekt ist ein Fork des abgeschlossenen Softwareprojekts WS18/19 SS19.
|
|
|
|
-------
|
|
|
|
### Einführung
|
|
|
|
VisuAlg hat eine komplexe Paketstruktur und viele verschiedene Komponenten. Daher hier eine kurze Einführung in die Funktionsweise der Software.
|
|
|
|
**Datenstrukturen:**
|
|
- die Datenstrukturen werden in drei Typen *ArrayStructure*, *GraphStructure* und *TreeStructure* unterschieden
|
|
- zu *ArrayStructure* zählen zum Beispiel das statische und dynamische Array, die einfach-verkettete Liste, Skip-Liste und Hash-Tabelle
|
|
- die Datenstrukturen sind in *structure* umgesetzt
|
|
- die abstrakte Klasse *Structure* fasst alle DS zusammen
|
|
|
|
**Algorithmen:**
|
|
- ein Algorithmus kann auf genau einer oder einem Typ von Datenstruktur angewandt werden
|
|
- ein Algorithmus kann Hilfs-Datenstrukturen hinzufügen
|
|
- ein Algorithmus setzt sich aus den Änderungen auf den Datenstrukturen, dem Highlighting und dem Pseudocode zusammen
|
|
- der Pseudocode orientiert sich am Pseudocode von Prof. Weicker
|
|
- die Algorithmen sind in *algorithm* umgesetzt
|
|
- die abstrakte Klasse *Algorithm* fasst alle Algorithmen zusammen
|
|
|
|
**Darstellung:**
|
|
- die Darstellung von Datenstrukturen, die Operationen zum Highlighting und die Kontextmenüs sind in den *Drawable*-Klassen umgesetzt
|
|
- über die Klassen bzw. Kontextmenüs werden die Algorithmen aufgerufen
|
|
- die abstrakte Klasse *StructureDrawable* fasst alle Drawables zusammen
|
|
|
|
**Import / Export:**
|
|
- eine Datenstruktur wird als XML-Datei gespeichert
|
|
- die Funktionalitäten zum Importieren und Exportieren von Datenstrukturen sind unter *dataholder* umgesetzt
|
|
|
|
**Einstellungen:**
|
|
- die Einstellungen werden als XML-Datei gespeichert
|
|
- die Funktionalitäten zum Laden, Setzen und Speichern von Einstellungen sind unter *option* umgesetzt
|
|
|
|
-------
|
|
|
|
### Mitmachen
|
|
|
|
Im Folgenden sind die Regeln zur Arbeit an diesem Projekt festgehalten:
|
|
|
|
**Mitarbeit:**
|
|
- jeder kann an dieser Software mitarbeiten
|
|
- die Software wird in Java 8 mit JavaFX entwickelt
|
|
- Bugs können jederzeit behoben werden
|
|
- ein Feature sollten nur dann umgesetzt werden, wenn es als wünschenswert bestätigt wurde
|
|
- für dieses Projekt gibt es kein Ticketsystem, daher werden die Tickets und Bugs als Issues verwaltet
|
|
- jeder kann neue Issues erstellen
|
|
- jeder kann sich ein Issue selbst zuweisen, sofern es noch nicht von jemand anderem bearbeitet wird
|
|
- die Änderungen eines Issues sind auf einem separatem Branch, abgezweigt von *master* und mit dem Namen "G-X", umzusetzen; dabei steht "X" für die ID des bearbeiteten Issues
|
|
- unter [THANKS.txt](https://gitlab.imn.htwk-leipzig.de/imocsy/visualG/blob/master/THANKS.txt) werden die Namen und Arbeiten der beteiligten Personen festgehalten
|
|
|
|
**Merge Request:**
|
|
- nach / während der Umsetzung eines Issues kann ein Merge Request in *master* gestellt werden
|
|
- der Titel und die Beschreibung des MR sollten auf das Issue und die umgesetzten Änderungen hinweisen
|
|
- die Änderungen des MR sollten von mindestens 2 anderen Personen gereviewed und als "Gut" befunden werden
|
|
- das Code-Review eines MR umfasst Korrektheit, Funktionalität, Darstellung, Test, Testabdeckung, Eintrag ins Handbuch (sofern notwendig)
|
|
- die Abstimmung über einen MR passiert über die Däumchen auf der Seite des MR
|
|
- vor dem Mergen eines MR muss der Ziel-Branch in den Issue-Branch gemergt werden
|
|
|
|
**Code-Konventionen:**
|
|
- Code, Dokumentation und Commit-Nachrichten werden in Englisch geschrieben
|
|
- die Beschreibung von Issues wird auf Deutsch verfasst
|
|
- der Code muss mit [visualgFormatter.xml](https://gitlab.imn.htwk-leipzig.de/imocsy/visualG/blob/master/visualgFormatter.xml) formatiert sein (Standard-Formatierung in Eclipse)
|
|
- Variablen-, Methoden- und Klassennamen sind passend und selbsterklärend zu wählen
|
|
- Funktionalitäten und Variablen müssen mit JavaDoc dokumentiert werden
|