CharGraph Editor - Pädagogische Dokumentation für Problemlösungskompetenz¶

Didaktisches CAD-Tool zur Vermittlung algorithmischen Denkens

Version: 0.37 Stand: 2026-01-02 Zweck: Unterrichtsmaterial für Informatik-Bildung Entwickelt für: Schulen, Hochschulen, Maker-Spaces

Hinweis: Diese pädagogische Dokumentation ist version-agnostisch und gilt für CharMatrix V0.1 und V0.2. Für technische Details zur V0.2 Implementierung siehe CharMatrix V0.2 Dokumentation.

Rechtliche Hinweise und Bildungsauftrag¶

Pädagogischer Kontext¶

Dieses Dokument ist Teil eines Unterrichtsprojekts zur Vermittlung von Problemlösungskompetenzen in der Informatik. Der CharGraph Editor dient ausschließlich Bildungszwecken und wurde entwickelt, um Schülern und Studenten die praktische Anwendung von:

Algorithmischem Denken
Software-Design-Patterns
Constraint-Satisfaction-Problemen
User Interface Design
Simulation und Validierung

zu vermitteln.

Historische Anerkennung¶

Die Inspiration für LED-basierte Textanzeigen geht auf verschiedene Innovatoren zurück, darunter Achim Schneider, der als Erfinder der „Kult-Uhr" bekannt ist. Sein Design hat eine ganze Generation von kreativen Interpretationen und pädagogischen Projekten inspiriert.

Urheberrechtliche Beachtung¶

Wichtiger Hinweis: Kommerzielle Designs wie bestimmte Buchstaben-Zeitanzeigen sind durch Design- und Geschmacksmusterschutz sowie Urheberrecht geschützt. Dieses Projekt:

Darf NICHT zur kommerziellen Nachbildung geschützter Designs verwendet werden
Darf NICHT zur Umgehung von Schutzrechten eingesetzt werden
Dient ausschließlich der Informatik-Ausbildung
Ermöglicht eigene kreative Lösungen
Vermittelt universelle Programmierkonzepte

Gemäß §53 UrhG ist die Nutzung für private und eigene Unterrichtszwecke erlaubt, solange keine kommerzielle Nutzung erfolgt und keine rechtswidrigen Vorlagen verwendet werden.

Universelle Hardware-Plattform¶

Die verwendete elektronische Schaltung ist eine universell einsetzbare Platine mit 11×10 LED-Matrix und 4 zusätzlichen Anzeigepunkten. Diese Hardware-Plattform kann für vielfältige didaktische Projekte verwendet werden:

Weitere Einsatzmöglichkeiten der Platine:

Spiele-Entwicklung: Snake, Tetris, Pong, Conway's Game of Life
Datenvisualisierung: Bargraph für Audio-Spektrum, Pegelanzeigen
Abstimmungssysteme: Echtzeit-Ergebnisdarstellung bei Schulabstimmungen
Sensoranzeigen: Temperatur, Luftqualität, Lautstärke-Monitoring
Pixel-Art: Kreative Grafikprojekte, Animationen
IoT-Displays: Wetteranzeigen, Social-Media-Benachrichtigungen
Laufschrift: Informationstafeln, Nachrichten-Displays

Der CharGraph Editor ist ein CAD-Tool (Computer-Aided Design), das um einen Echtzeit-Simulator erweitert wurde, um die visuelle Gestaltung und Funktionsvalidierung zu ermöglichen - vergleichbar mit Tools wie Tinkercad, Fritzing oder KiCad im Bildungsbereich.

Inhaltsverzeichnis¶

Problemlösungskompetenz in der Informatik
Dagstuhl-Dreieck als didaktisches Framework
7-Schritte-Dekonstruktion
Systemübersicht
Layout-Design-Prinzipien
Algorithmische Zeitberechnung
Informationsentropie und Nachrichtenkomplexität
Deklarative Programmierung in V0.2
Constraint-Satisfaction
Visuelle Feedback-Logik
Test-Driven Development
Validierung und Qualitätssicherung
Erweiterte Lernziele
CAD-Tool-Funktionalität
Ausblick und Erweiterungsmöglichkeiten
Zusammenfassung
Schutzrechtliche Situation (Stand 2025)
Weitere Ressourcen

Problemlösungskompetenz in der Informatik¶

Was ist algorithmisches Problemlösen?¶

Algorithmisches Problemlösen ist eine fundamentale Kompetenz in der Informatik, die über reines Programmieren hinausgeht. Es umfasst:

Problemanalyse - Das Problem verstehen und strukturieren
Abstraktion - Komplexität reduzieren durch Fokussierung auf das Wesentliche
Zerlegung (Decomposition) - Große Probleme in kleinere Teilprobleme aufteilen
Mustererkennung - Ähnlichkeiten und Wiederholungen identifizieren
Algorithmisches Design - Schritt-für-Schritt-Lösungen entwickeln
Evaluation - Lösungen testen und optimieren
Iteration - Verbesserungen durchführen basierend auf Tests

Warum ist dies wichtig?¶

Diese Fähigkeiten sind übertragbar auf alle Bereiche der Informatik und des Lebens: - Software-Entwicklung - Datenanalyse - Künstliche Intelligenz - Projektmanagement - Wissenschaftliches Arbeiten

Dagstuhl-Dreieck als didaktisches Framework¶

Fachdidaktisches Modell der Informatik¶

Das Dagstuhl-Dreieck ist ein etabliertes didaktisches Modell aus der Fachdidaktik der Informatik, das drei komplementäre Perspektiven auf informatische Bildung beschreibt. Es wurde 2016 auf der Tagung "Bildung in der digitalen vernetzten Welt" in Schloss Dagstuhl entwickelt und bildet die Grundlage für modernen Informatik-Unterricht.

Die drei Perspektiven¶

1. Technologische Perspektive (How) - "Wie funktioniert das System?"

Fokus auf das technische Verständnis und die Funktionsweise von Systemen:

Im CharGraph-Projekt: - Wie funktioniert die LED-Matrix technisch? - Wie werden Zeitangaben algorithmisch berechnet? - Welche Datenstrukturen werden verwendet? - Wie funktioniert die Constraint-Satisfaction? - Wie wird die deklarative Regel-Engine implementiert?

Lernziele: - Algorithmen verstehen und entwickeln - Modulo-Arithmetik für zyklische Bereiche - Constraint-basierte Problemlösung - Software-Architektur und Design Patterns

2. Anwendungsbezogene Perspektive (What) - "Wozu wird es genutzt?"

Fokus auf praktische Anwendung und Nutzungskompetenz:

Im CharGraph-Projekt: - Gestaltung eigener Zeitanzeigen - CAD-Tool zur Layout-Erstellung - 3D-Druck-Export für Prototypen - Individuelle Anpassung der Sprachvarianten - Simulation und Validierung vor dem Bau

Lernziele: - User Interface Design verstehen - Werkzeuge zur Problemlösung einsetzen - Prototyping und Iteration - Von der Idee zum fertigen Produkt

3. Gesellschaftlich-kulturelle Perspektive (Why) - "Welche Bedeutung hat es?"

Fokus auf Wechselwirkungen zwischen Technik, Individuum und Gesellschaft:

Im CharGraph-Projekt: - Warum gibt es verschiedene Sprachvarianten? (Kulturelle Unterschiede: "DREIVIERTEL" vs. "VIERTEL VOR") - Wie beeinflusst Design die Lesbarkeit? (Barrierefreiheit, User Experience) - Welche Rolle spielen Schutzrechte? (Urheberrecht, Patente, Open Source) - Wie verändert individualisierbare Technologie den Konsum? (Maker-Bewegung vs. Massenproduktion) - Warum ist informatische Bildung wichtig? (Computational Thinking als Kulturtechnik)

Lernziele: - Ethische und rechtliche Aspekte verstehen - Auswirkungen von Technologie reflektieren - Kreativität und Individualität in der digitalen Welt - Verantwortungsvoller Umgang mit Schutzrechten

Integration im CharGraph-Projekt¶

Das CharGraph-Projekt adressiert bewusst alle drei Perspektiven des Dagstuhl-Dreiecks:

Perspektive	CharGraph-Inhalt	Kapitel
Technologisch	Algorithmen, Datenstrukturen, CSP	Kap. 5-7, 9
Anwendungsbezogen	CAD-Editor, Simulator, Export	Kap. 4, 8, 12, 14
Gesellschaftlich-kulturell	Sprachvarianten, Schutzrechte, Kreativität	Kap. 1, 15, 16

Didaktischer Wert¶

Für Lehrkräfte:

Das Dagstuhl-Dreieck bietet eine strukturierte Grundlage für die Unterrichtsplanung:

Technologie-Phase: Algorithmen entwickeln und verstehen
Anwendungs-Phase: Eigenes Layout gestalten und testen
Reflexions-Phase: Gesellschaftliche Bedeutung diskutieren

Für Lernende:

Ganzheitliches Verständnis statt reiner Programmierkenntnisse: - Nicht nur: "Wie programmiere ich eine Zeitanzeige?" - Sondern auch: "Warum gibt es verschiedene Zeitangaben?" und "Wie gestalte ich eine benutzerfreundliche Anzeige?"

Weiterführende Literatur¶

Gesellschaft für Informatik (2016): "Dagstuhl-Erklärung: Bildung in der digitalen vernetzten Welt"
Beat Döbeli Honegger: "Mehr als 0 und 1 - Schule in einer digitalisierten Welt"
Ira Diethelm et al.: "Informatische Bildung zum Verstehen und Gestalten der digitalen Welt"

7-Schritte-Dekonstruktion¶

Das CharGraph-Projekt folgt einem bewährten 7-Schritte-Ansatz zur Problemlösung:

Schritt 1: Analyse (Analysis)¶

Fragestellung: Wie kann man Zeit mit Buchstaben darstellen?

Anforderungen identifizieren:

Darstellung von Stunden (1-12)
Darstellung von Minuten (0-59)
Lesbare deutsche Sprachausgabe
Begrenzte Anzahl von Zeichen (110 in 11×10 Anordnung)
Zusätzliche Präzision durch 4 Anzeigepunkte

Constraints:

Physikalische Begrenzung: 11×10 Buchstabenfeld
Sprachliche Begrenzung: Deutsche Zeitangaben
Kognitive Begrenzung: Schnelle Lesbarkeit

Schritt 2: Dekonstruktion (Decomposition)¶

Problem aufteilen in Teilprobleme:

Layout-Problem: Welche Wörter müssen platziert werden?
Mapping-Problem: Wie wird Zeit auf Wörter abgebildet?
Positions-Problem: Wo stehen die Wörter im Raster?
Präzisions-Problem: Wie zeigt man 1-4 Minuten zwischen 5er-Schritten?
Validierungs-Problem: Wie prüft man die Korrektheit?

Schritt 3: Design (Design)¶

Lösungsstrategien entwickeln:

A) Sprachliches Design:

Zeitangabe = Einleitung + Minutenangabe + Stundenangabe + Abschluss
 = "ES IST" + [Minuten] + [Stunde] + ["UHR"]
 = "WIR HABEN" + [Minuten] + [Stunde] + ["UHR"]

B) Layout-Design:

Reihenfolge: [Feste Einleitung] [Variable Minuten] [Referenzpunkt] [Variable Stunden] [Fester Abschluss]

C) Algorithmisches Design:

Modulo-Arithmetik für 12-Stunden-Zyklus
Bereichs-Mapping für Minutenintervalle
Prioritäts-Queues für optionale Wörter

Schritt 4: Implementierung (Implementation)¶

Code-Struktur entwickeln:

function berechneSichtbareWoerter(stunde, minute) {
 // 1. Normalisierung
 let h12 = stunde % 12;
 if(h12 === 0) h12 = 12;

 // 2. Kontext-abhängige Stundenauswahl
 let anzeigeStunde = (minute >= 20) ? h12 + 1 : h12;

 // 3. Bereichs-Mapping
 if(minute >= 0 && minute <= 4) return ["ES", "IST", "NACH", stunden[h12]];
 // ... weitere Bereiche
}

Schritt 5: Test (Testing)¶

Systematisches Testen:

Unit-Tests für einzelne Zeitpunkte
Grenzwert-Tests (0:00, 12:00, 23:59)
Szenario-Tests (alle 5-Minuten-Schritte)
Edge-Cases (Minutenübergänge)

Schritt 6: Evaluation (Evaluation)¶

Bewertung der Lösung:

Funktionale Korrektheit
Benutzbarkeit
Performance
Wartbarkeit
Erweiterbarkeit

Schritt 7: Iteration (Iteration)¶

Verbesserungen:

Hinzufügen optionaler Wörter (KURZ, BALD, FAST)
Regionale Varianten (DREIVIERTEL)
Optimierung der Algorithmen
Verbesserung der Benutzeroberfläche

Systemübersicht¶

Technischer Aufbau¶

Der CharGraph Editor ist ein webbasiertes CAD-System zur Gestaltung von LED-Buchstaben-Layouts.

Komponenten:

Design-Editor
Visuelles Drag-&-Drop Interface
11×10 Buchstabenraster
Wort-Palette mit vordefinierten Elementen
Echtzeit-Vorschau
Simulator
Zeitberechnung-Engine
Beleuchtungs-Simulation
Live-Uhrzeit-Modus
Test-Szenarien (verschiedene Uhrzeiten)
Validierungs-System
Strukturprüfung
Duplikat-Erkennung
Konsistenz-Checks
Rechtliche Compliance (Schutzrechte-Prüfung)
Export-Funktion
Pattern-String-Generierung
3D-STL-Export für Prototyping
Dokumentations-Export

Grundprinzip der Zeitdarstellung¶

Zeitformel = Einleitung + [Modifikator] + Minutenangabe + [Referenz] + Stundenangabe + [Abschluss]

Beispiele:
"ES IST FÜNF NACH EINS"
"ES IST KURZ VOR HALB ZWEI"
"ES IST DREIVIERTEL DREI"

Varianten-System für Lernzwecke¶

Das System unterstützt 8 Basis-Varianten durch Kombination optionaler Modifikatoren:

ID	KURZ	FAST	BALD	Didaktischer Zweck
kfb	✗	✗	✗	Minimale Variante - Grundverständnis
kfB	✗	✗	✓	Einfache Erweiterung
kFb	✗	✓	✗	Alternative Modifikation
kFB	✗	✓	✓	Kombination lernen
Kfb	✓	✗	✗	Präzisions-Konzept
KfB	✓	✗	✓	Prioritäts-Logik verstehen
KFb	✓	✓	✗	Komplexe Kombinationen
KFB	✓	✓	✓	Vollständige Implementierung

Lernziel: Verstehen von Bedingungslogik, Prioritäten und optionalen Features

Layout-Design-Prinzipien¶

Constraint-Based Design¶

Das Layout unterliegt strikten Randbedingungen - ein klassisches Constraint Satisfaction Problem (CSP).

Struktureller Aufbau¶

Position 0-10: [Einleitung] "ES IST"
Position 11-40: [Variablen Teil 1] Minutenwörter + Modifikatoren
Position 25-35: [Anker-Punkt] "HALB" als Referenz
Position 40-90: [Variablen Teil 2] Stundenwörter
Position 90-110: [Abschluss] "UHR"

Design-Regeln (Constraints)¶

Regel 1: Semantische Gruppierung¶

Minutenwörter VOR Referenzpunkt:

FÜNF (Minuten)
ZEHN (Minuten)
VIERTEL
ZWANZIG
Modifikatoren: KURZ, BALD, FAST
Präpositionen: VOR, NACH

Stundenwörter NACH Referenzpunkt:

EINS/EIN
ZWEI bis ZWÖLF
FÜNF (Stunde)
ZEHN (Stunde)

Warum? Der Suchalgorithmus verwendet den Referenzpunkt zur Unterscheidung kontextabhängiger Wörter.

Regel 2: Keine identischen Nachbarn¶

Horizontal:

Korrekt - Keine horizontalen Nachbarn identisch:

I	U	O
A	B	C

Falsch - Horizontale Nachbarn identisch (zwei A nebeneinander):

I	U	O
A	A	B

Vertikal:

Korrekt - Keine vertikalen Nachbarn identisch:

I	U	O
A	C	B
K	L	C

Falsch - Vertikale Nachbarn identisch (zwei C untereinander):

I	U	O
A	C	B
K	C	Z

Grund: Verhindert Ambiguität bei der LED-Beleuchtung

Regel 3: Vollständigkeit¶

Alle erforderlichen Wörter müssen vorhanden sein: - Einleitung: ES, IST - Referenz: HALB - Präpositionen: VOR, NACH - Stunden: Alle 12 Stunden - Abschluss: UHR

Beispiel-Layout (Lernzweck)¶

E S B I S T F B A L D
F Ü N F Z W A N Z I G
D R E I V I E R T E L
K U R Z E H N Z V O R
T N A C H L T H A L B
S E C H S X V I E R W
E L F Ü N F Z W Ö L F
Z E H N E U N A C H T
D R E I N S I E B E N
E Z W E I R W D U H R

Analyse dieses Layouts:

Zeile 1: "ES IST ZEHN" (Einleitung + Minuten)
Zeile 2-3: "FÜNF VIERTEL VOR NACH" (Minuten + Präpositionen)
Zeile 3: "BALD" (Modifikator)
Zeile 4: "HALB" (Referenzpunkt - Position ~35)
Zeile 4-5: "ZWEI DREI VIER FÜNF" (Stunden)
Zeile 5-8: Weitere Stundenwörter
Zeile 9-10: "UHR" (Abschluss)

Algorithmische Zeitberechnung¶

Modulo-Arithmetik für 12-Stunden-Format¶

// Problem: 24-Stunden-Format in 12-Stunden konvertieren
let h12 = stunden % 12;
if(h12 === 0) h12 = 12; // Spezialfall: 0 → 12 und 12 → 12

// Beispiele:
// 00:xx → 0 % 12 = 0 → 12 (ZWÖLF)
// 13:xx → 13 % 12 = 1 → 1 (EINS)
// 23:xx → 23 % 12 = 11 → 11 (ELF)

Lernziel: Modulo-Operator für zyklische Bereiche

Kontext-abhängige Stundenwahl¶

// Problem: "HALB ZWEI" bei 13:30, nicht "HALB EINS"
let anzeigeStunde = h12;
if(minuten >= 20) {
 anzeigeStunde = (h12 % 12) + 1;
}

// Beispiele:
// 13:15 → h12=1, min<20 → "VIERTEL NACH EINS"
// 13:30 → h12=1, min>=20 → "HALB ZWEI" (anzeigeStunde=2)

Lernziel: Kontext-sensitive Datenverarbeitung

Alternative Einleitung: WIR HABEN statt ES IST¶

// Problem: Layout-abhängige Wortwahl für die Einleitung
// Regel: Wenn WIR und HABEN im Grid vorhanden sind, verwende diese statt ES IST

const gridStr = getGridString();
const hasWir = gridStr.includes("WIR");
const hasHaben = gridStr.includes("HABEN");
const useAlternative = hasWir && hasHaben;

let words = useAlternative ? ["WIR", "HABEN"] : ["ES", "IST"];

// Beispiele:
// Grid enthält "WIR" und "HABEN" → 13:00 → "WIR HABEN EINS UHR"
// Grid enthält "ES" und "IST" → 13:00 → "ES IST EIN UHR"
// Grid enthält "WIR", "HABEN", "NACHT" → 00:00 → "WIR HABEN NACHT"

Lernziel: Layout-gesteuerte Sprachvarianten und bedingte Initialisierung

Kontext-abhängige EIN/EINS-Konvertierung¶

// Problem: "EIN UHR" vs. "EINS" bei 1:00
// Regel: "EINS" → "EIN" nur wenn "UHR" als letztes Wort im Pattern vorhanden ist

// Prüfen ob UHR im Grid vorhanden ist und als letztes Wort steht
const uhrPos = gridStr.lastIndexOf("UHR");
const hasUhrAtEnd = uhrPos !== -1 && gridStr.substring(uhrPos + 3).replace(/[_\s]/g, '').length === 0;

if(minuten === 0) {
 // Volle Stunde
 if(hasUhrAtEnd) {
 // UHR ist vorhanden und am Ende: "ES IST EIN UHR"
 if(hourWord === "EINS") hourWord = "EIN";
 words.push(hourWord, "UHR");
 } else {
 // UHR fehlt oder ist nicht am Ende: "ES IST EINS"
 words.push(hourWord); // bleibt "EINS", kein "UHR"
 }
}

// Beispiele:
// Pattern: "...EIN...UHR___" → 01:00 → "ES IST EIN UHR"
// Pattern: "...EINS...NACHT" → 01:00 → "ES IST EINS" (ohne UHR)

Lernziel: Layout-abhängige Textanpassung und String-Manipulation

Bereichs-Mapping mit If-Else-Kaskade¶

if(minuten === 0) {
 return ["ES", "IST", stunde, "UHR"];
}
else if(minuten >= 1 && minuten <= 4) {
 return ["ES", "IST", "NACH", stunde];
}
else if(minuten >= 5 && minuten <= 9) {
 return ["ES", "IST", "FÜNF", "NACH", stunde];
}
// ... weitere Bereiche

Lernziel: Range-Checks und Intervall-Logik

Prioritäts-basierte Selektion¶

// Problem: Mehrere optionale Wörter, welches wählen?

// Bei Minute 29: FAST > KURZ > BALD > Standard
if(minute === 29) {
 if(hat_FAST) return [..., "FAST", "HALB", ...];
 else if(hat_KURZ) return [..., "KURZ", "VOR", "HALB", ...];
 else if(hat_BALD) return [..., "BALD", "HALB", ...];
 else return [..., "VOR", "HALB", ...];
}

// Bei Minuten 27-28: BALD > FAST > KURZ
// Bei Minuten 57-59: BALD > FAST > KURZ

// Bei Minuten 01-04: KURZ nur bei :01 und :02
if(minute >= 1 && minute <= 2 && hat_KURZ) {
 return [..., "KURZ", "NACH", ...]; // KURZ nur bei :01 und :02
}
else if(minute === 3) {
 return [..., "NACH", ...]; // :03 immer ohne KURZ
}
else if(minute === 4 && hat_BALD) {
 return [..., "BALD", "FÜNF", "NACH", ...]; // :04 mit BALD-Sonderfall
}
else if(minute >= 1 && minute <= 4) {
 return [..., "NACH", ...]; // Fallback für :01-:04
}

// Bei Minute 09: BALD ZEHN NACH möglich
if(minute === 9 && hat_BALD) {
 return [..., "BALD", "ZEHN", "NACH", ...]; // :09 mit BALD-Sonderfall
}
else if(minute >= 5 && minute <= 9) {
 return [..., "FÜNF", "NACH", ...]; // Fallback für :05-:09
}

// Bei Minuten 30-34: Speziallogik für "NACH HALB"
if(minute === 30) {
 return [..., "HALB", ...]; // Exakt halb
}
else if(minute === 34 && hat_BALD) {
 return [..., "BALD", "FÜNF", "NACH", "HALB", ...]; // :34 mit BALD-Sonderfall
}
else if(minute >= 31 && minute <= 32 && hat_KURZ) {
 return [..., "KURZ", "NACH", "HALB", ...]; // KURZ nur bei :31 und :32
}
else if(minute >= 31 && minute <= 34) {
 return [..., "NACH", "HALB", ...]; // :31-:34 immer NACH HALB (ohne KURZ bei :33-:34)
}

// Weitere BALD-Sonderfälle im Stundenverlauf:
if(minute === 14 && hat_BALD) {
 return [..., "BALD", "VIERTEL", "NACH", ...]; // :14 mit BALD-Sonderfall
}
if(minute === 19 && hat_BALD && hat_ZWANZIG) {
 return [..., "BALD", "ZWANZIG", "NACH", ...]; // :19 mit BALD-Sonderfall (benötigt ZWANZIG)
}
if(minute === 39 && hat_BALD) {
 return [..., "BALD", "ZEHN", "NACH", "HALB", ...]; // :39 mit BALD-Sonderfall
}
if(minute === 44 && hat_BALD && hat_DREIVIERTEL) {
 return [..., "BALD", "DREIVIERTEL", ...]; // :44 mit BALD-Sonderfall (benötigt DREIVIERTEL)
}
else if(minute === 44 && hat_BALD) {
 return [..., "BALD", "VIERTEL", "VOR", ...]; // :44 mit BALD-Sonderfall (Fallback)
}
if(minute === 49 && hat_BALD) {
 return [..., "BALD", "ZEHN", "VOR", ...]; // :49 mit BALD-Sonderfall
}
if(minute === 54 && hat_BALD) {
 return [..., "BALD", "FÜNF", "VOR", ...]; // :54 mit BALD-Sonderfall
}
if(minute === 59 && hat_BALD) {
 return [..., "BALD", stunde_nächste]; // :59 mit BALD-Sonderfall
}

Vollständige BALD-Sonderfälle Übersicht¶

BALD wird verwendet um anzukündigen, dass die nächste 5-Minuten-Marke "bald" erreicht wird:

Minute	Mit BALD	Ohne BALD (Fallback)	Bedingung
:04	BALD FÜNF NACH	NACH	Benötigt BALD
:09	BALD ZEHN NACH	FÜNF NACH	Benötigt BALD
:14	BALD VIERTEL NACH	ZEHN NACH	Benötigt BALD
:19	BALD ZWANZIG NACH	VIERTEL NACH	Benötigt BALD + ZWANZIG
:34	BALD FÜNF NACH HALB	NACH HALB	Benötigt BALD
:39	BALD ZEHN NACH HALB	FÜNF NACH HALB	Benötigt BALD
:44	BALD DREIVIERTEL oder BALD VIERTEL VOR	ZWANZIG VOR oder ZEHN NACH HALB	Benötigt BALD (+ DREIVIERTEL für 1. Variante)
:49	BALD ZEHN VOR	DREIVIERTEL oder VIERTEL VOR	Benötigt BALD
:54	BALD FÜNF VOR	ZEHN VOR	Benötigt BALD
:59	BALD [STUNDE]	FÜNF VOR oder FAST/KURZ VOR	Benötigt BALD

Lernziel: Prioritäts-Queues und Conditional Branching

Informationsentropie und Nachrichtenkomplexität¶

Entropie in der Informationstheorie¶

Die Informationsentropie (nach Claude Shannon, 1948) ist ein fundamentales Konzept der Informationstheorie. Sie misst den Informationsgehalt oder die Unsicherheit einer Nachricht. Je unwahrscheinlicher eine Nachricht ist, desto höher ist ihr Informationsgehalt.

Grundformel (Shannon-Entropie):

H(X) = -Σ p(x) · log₂(p(x))

Wobei: - H(X) = Entropie (in Bits) - p(x) = Wahrscheinlichkeit eines Ereignisses - log₂ = Logarithmus zur Basis 2

Anwendung auf Zeitangaben¶

Verschiedene Zeitangaben haben unterschiedliche Informationsgehalte, abhängig von ihrer Präzision und Komplexität.

Beispiel 1: Einfache Zeitangaben (niedrige Entropie)¶

"ES IST EINS"

Präzision: ±30 Minuten (volle Stunde)
Wortanzahl: 3 Wörter
Informationsgehalt: Niedrig
Entropie: Gering, da nur 12 mögliche Stunden

Informationsanalyse: - Tritt bei: 01:00, 13:00 (2 von 1440 Minuten/Tag = 0,14%) - Wahrscheinlichkeit: p ≈ 0,0014 - Informationsgehalt: -log₂(0,0014) ≈ 9,5 Bit

Beispiel 2: Präzisere Zeitangaben (mittlere Entropie)¶

"ES IST FÜNF NACH ZWEI"

Präzision: ±2 Minuten (5-Minuten-Raster)
Wortanzahl: 5 Wörter
Informationsgehalt: Mittel
Entropie: Höher, da 12 Stunden × 12 Fünf-Minuten-Schritte = 144 Möglichkeiten

Informationsanalyse: - Tritt bei: 02:05, 14:05, 02:06, 02:07, 14:06, 14:07 (6 von 1440 Minuten/Tag) - Wahrscheinlichkeit: p ≈ 0,0042 - Informationsgehalt: -log₂(0,0042) ≈ 7,9 Bit

Beispiel 3: Hochpräzise Zeitangaben (hohe Entropie)¶

"ES IST KURZ VOR HALB VIER"

Präzision: ±1 Minute (mit Modifikatoren)
Wortanzahl: 6 Wörter
Informationsgehalt: Hoch
Entropie: Sehr hoch, da sehr spezifisch

Informationsanalyse: - Tritt bei: 03:28, 03:29, 15:28, 15:29 (4 von 1440 Minuten/Tag = 0,28%) - Wahrscheinlichkeit: p ≈ 0,0028 - Informationsgehalt: -log₂(0,0028) ≈ 8,5 Bit

Entropie durch Modifikatoren¶

Die optionalen Modifikatoren KURZ, BALD, FAST erhöhen die Entropie der Zeitangabe systematisch:

Zeitangabe	Modifikatoren	Präzision	Wortanzahl	Relative Entropie
"EINS"	Keine	±30 Min	1	Niedrig (★☆☆☆☆)
"NACH EINS"	Keine	±2 Min	2	Niedrig-Mittel (★★☆☆☆)
"FÜNF NACH EINS"	Keine	±2 Min	4	Mittel (★★★☆☆)
"KURZ NACH EINS"	KURZ	±1 Min	3	Mittel-Hoch (★★★★☆)
"KURZ VOR HALB VIER"	KURZ	±1 Min	5	Hoch (★★★★★)
"BALD DREIVIERTEL DREI"	BALD	±2 Min	4	Hoch (★★★★★)

Informationsredundanz vs. Klarheit¶

Trade-Off zwischen Präzision und Lesbarkeit:

Ein interessanter Aspekt ist das Spannungsfeld zwischen:

Hohe Entropie (viel Information): - ✅ Präzise Zeitangabe - ✅ Weniger Mehrdeutigkeit - ❌ Mehr Wörter beleuchtet - ❌ Längere Lesezeit - ❌ Komplexere Layout-Anforderungen

Niedrige Entropie (wenig Information): - ✅ Einfache, schnelle Lesbarkeit - ✅ Weniger Wörter beleuchtet - ❌ Geringere Präzision - ❌ Mehr Mehrdeutigkeit (±30 Minuten bei "EINS")

Praktische Anwendung im CharGraph-Editor¶

Designentscheidung: Welche Modifikatoren sollen verwendet werden?

Variante A: Minimale Entropie (kfb)

13:00 → "ES IST EINS"
13:28 → "ES IST VOR HALB ZWEI"

- Geringe Informationsdichte - Einfaches Layout möglich - Schnelle Lesbarkeit

Variante B: Maximale Entropie (KFB)

13:00 → "ES IST EIN UHR"
13:28 → "ES IST KURZ VOR HALB ZWEI"
13:29 → "ES IST FAST HALB ZWEI"

- Hohe Informationsdichte - Komplexes Layout erforderlich - Präzise Zeitangabe

Verbindung zur Informationstheorie¶

Claude Shannons Arbeit (1948):

Shannon definierte Entropie als Maß für die durchschnittliche Überraschung einer Nachricht:

Häufige Ereignisse (niedrige Überraschung) → geringe Entropie
Seltene Ereignisse (hohe Überraschung) → hohe Entropie

Im CharGraph-Kontext:

"ES IST EINS" - Tritt häufig auf (jede Stunde), geringe Überraschung
"ES IST KURZ VOR HALB VIER" - Tritt selten auf (4 Minuten/Tag), hohe Überraschung

Datenkompression und Effizienz¶

Huffman-Codierung als Analogie:

In der Datenkompression werden häufige Symbole mit kurzen Codes und seltene Symbole mit langen Codes versehen.

Im CharGraph analog:

Häufige Zeitangaben: Kurze Formulierungen ("EINS", "ZWEI")
Seltene Zeitangaben: Längere Formulierungen ("KURZ VOR HALB VIER")

Dies entspricht einer optimalen Codierung für natürliche Sprache!

Didaktische Lernziele¶

Für Schüler (Sekundarstufe II):

Grundkonzept Entropie: Was ist Informationsgehalt?
Wahrscheinlichkeit: Wie häufig tritt eine Zeitangabe auf?
Bit als Maßeinheit: Wie viele Bits benötigt man zur Codierung?
Trade-Offs: Präzision vs. Einfachheit

Für Studenten (Hochschule):

Shannon-Entropie: Mathematische Berechnung
Informationstheorie: Huffman-Codierung, optimale Codes
Natürliche Sprache: Zipf'sches Gesetz, Wortfrequenzen
Datenstrukturen: Effiziente Speicherung variabler Nachrichten

Praktische Übung¶

Aufgabe: Berechne die Entropie der Zeitangabe "ES IST BALD FÜNF NACH ZWEI"

Lösung:

Identifiziere mögliche Zeitpunkte: 14:03, 14:04 (2 Minuten)
Berechne Wahrscheinlichkeit: p = 2/1440 ≈ 0,0014
Berechne Informationsgehalt: I = -log₂(0,0014) ≈ 9,5 Bit
Vergleiche mit "ES IST ZWEI": 120/1440 ≈ 0,083, I ≈ 3,6 Bit

Ergebnis: Die präzisere Angabe hat 2,6× mehr Informationsgehalt!

Zusammenfassung¶

Unterschiedliche Zeitangaben tragen unterschiedlich viel Information
Modifikatoren erhöhen die Entropie (Präzision)
Layout-Komplexität korreliert mit Entropie
Natürliche Sprache ist informationstheoretisch optimiert

Lernziel: Verstehen des Zusammenhangs zwischen Informationsgehalt, Wahrscheinlichkeit und sprachlicher Komplexität

Vollständige Modifikatoren-Logik¶

Übersicht der Modifikatoren¶

Das System verwendet drei optionale Modifikatoren, die das Zeitverhalten verfeinern:

Modifikator	Bedeutung	Primäre Verwendung
KURZ	Kurz nach/vor	:01, :31 (direkt nach Marken), :28-:29, :58 (kurz vor Marken)
BALD	Bald (2-3 Min vor Marke)	:03-:04, :08-:09, :13-:14, :18-:19, :28-:29, :34, :56-:59
FAST	Fast (1 Min vor Marke)	:04, :09, :14, :19, :29, :34, :39, :49, :54, :59

Dynamische Modifikator-Interaktion¶

Kernprinzip: Modifikatoren passen ihre Reichweite an die Verfügbarkeit anderer Modifikatoren an.

FAST-Expansion¶

FAST expandiert seinen Wirkungsbereich, wenn BALD nicht vorhanden ist:

// Beispiel :03 - 2 Minuten vor :05
if(nur_FAST_vorhanden) {
 // FAST übernimmt auch den 2-Min-Bereich
 return "FAST FÜNF NACH";
}
if(BALD_vorhanden) {
 // BALD übernimmt den 2-Min-Bereich
 return "BALD FÜNF NACH";
}

Aktivierungspunkte für FAST-Expansion (wenn BALD nicht vorhanden, KURZ nicht blockiert):

:03, :08, :13, :18 → FAST expandiert zu 2 Min vor Marke
:33, :38, :53 → FAST expandiert zu 2 Min vor Marke

KURZ-Blockierung¶

KURZ wird an bestimmten Stellen deaktiviert, wenn FAST vorhanden ist:

// :02 - KURZ wird komplett deaktiviert
if(minute === 2) {
 return "NACH Stunde"; // Kein KURZ, auch wenn vorhanden
}

// :31 - KURZ nur wenn FAST vorhanden
if(minute === 31 && has_KURZ && has_FAST) {
 return "KURZ NACH HALB";
}
else if(minute === 31) {
 return "NACH HALB"; // Kein KURZ ohne FAST
}

Prioritätsregeln¶

Bei 1 Minute vor 5er-Marke (:04, :09, :14, :19, :34, :39, :49, :54, :59)¶

FAST > BALD

if(hasFast && hasBald) return "FAST ..."; // FAST gewinnt
else if(hasBald) return "BALD ...";
else if(hasFast) return "FAST ...";

Beispiele:

:04 mit BALD+FAST → "FAST FÜNF NACH"
:09 mit BALD+FAST → "FAST ZEHN NACH"
:34 mit BALD+FAST → "FAST FÜNF NACH HALB"

Bei 2 Minuten vor 5er-Marke (:03, :08, :13, :18, :33, :38, :53)¶

BALD > FAST (wenn beide vorhanden)

if(hasBald && hasFast) return "BALD ..."; // BALD gewinnt
else if(hasFast) return "FAST ..."; // FAST expandiert
else if(hasBald) return "BALD ...";

Beispiele:

:03 mit BALD+FAST → "BALD FÜNF NACH"
:08 mit BALD+FAST → "BALD ZEHN NACH"
:33 mit BALD+FAST → "BALD FÜNF NACH HALB"

Vor HALB (:28-:29)¶

FAST > KURZ > BALD

// :29
if(hasFast) return "FAST HALB";
else if(hasKurz) return "KURZ VOR HALB";
else if(hasBald) return "BALD HALB";

// :28
if(hasKurz && hasFast) return "KURZ VOR HALB"; // KURZ > BALD/FAST
else if(hasBald) return "BALD HALB";

Vor voller Stunde (:57-:59)¶

:59: FAST > KURZ > BALD :58: KURZ > BALD/FAST :57: BALD (nur mit KURZ)

Vollständige Kombinations-Matrix¶

Die folgende Tabelle zeigt alle 8 möglichen Kombinationen der drei Modifikatoren und deren Verhalten:

Code	KURZ	FAST	BALD	Beispiel :03	Beispiel :09	Beispiel :34
kfb	✗	✗	✗	NACH	FÜNF NACH	NACH HALB
kfB	✗	✗	✓	BALD FÜNF NACH	BALD ZEHN NACH	BALD FÜNF NACH HALB
kFb	✗	✓	✗	FAST FÜNF NACH	FAST ZEHN NACH	FAST FÜNF NACH HALB
kFB	✗	✓	✓	BALD FÜNF NACH	FAST ZEHN NACH	FAST FÜNF NACH HALB
Kfb	✓	✗	✗	NACH	FÜNF NACH	NACH HALB
KfB	✓	✗	✓	NACH	BALD ZEHN NACH	BALD FÜNF NACH HALB
KFb	✓	✓	✗	FAST FÜNF NACH	FAST ZEHN NACH	FAST FÜNF NACH HALB
KFB	✓	✓	✓	BALD FÜNF NACH	FAST ZEHN NACH	FAST FÜNF NACH HALB

Legende: k=kein, K=KURZ, f=kein, F=FAST, b=kein, B=BALD

Beobachtungen: 1. Bei :03 (2 Min vor :05): BALD dominiert, außer wenn nur FAST vorhanden ist 2. Bei :09 (1 Min vor :10): FAST > BALD (kFB, KFB zeigen FAST) 3. Bei :34 (1 Min vor :35): FAST > BALD (kFB, KFB zeigen FAST)

Spezialfälle¶

:02 - KURZ komplett deaktiviert¶

if(minute === 2) {
 return "NACH Stunde"; // IMMER, unabhängig von Modifikatoren
}

Grund: Zu nah an :05, KURZ würde verwirren

:27 - BALD nur bei KFB (alle 3 Modifikatoren)¶

if(minute === 27 && hasKurz && hasFast && hasBald) {
 return "BALD HALB";
}
else {
 return "FÜNF VOR HALB";
}

Grund: 3 Minuten vor :30 ist zu weit für normale BALD-Aktivierung

:31 - KURZ nur mit FAST¶

if(minute === 31 && hasKurz && hasFast) {
 return "KURZ NACH HALB";
}
else {
 return "NACH HALB";
}

Grund: FAST ermöglicht KURZ, sonst würde KURZ mit nachfolgenden Ansagen kollidieren

:44 - BALD DREIVIERTEL benötigt DREIVIERTEL-Wort¶

if(minute === 44 && hasBald && hasDreiviertel) {
 return "BALD DREIVIERTEL";
}
else if(minute === 44 && hasBald && !hasDreiviertel) {
 return "BALD DREIVIERTEL"; // Fallback auf Standardtext
}
// Weitere Fallbacks: ZEHN NACH HALB oder ZWANZIG VOR

Grund: BALD DREIVIERTEL funktioniert nur wenn DREIVIERTEL im Grid vorhanden ist

Implementierungs-Algorithmus¶

function selectModifier(minute, hasKurz, hasFast, hasBald) {
 // Spezialfälle zuerst
 if(minute === 2) return NONE; // KURZ deaktiviert

 // 1 Min vor Marke: FAST > BALD
 if(ist_1_min_vor_5er_marke(minute)) {
 if(hasFast && hasBald) return FAST;
 if(hasBald) return BALD;
 if(hasFast) return FAST;
 }

 // 2 Min vor Marke: BALD > FAST (aber FAST expandiert wenn kein BALD)
 if(ist_2_min_vor_5er_marke(minute)) {
 if(hasBald) return BALD;
 if(hasFast && !hasKurz_blockiert) return FAST; // Expansion
 }

 // Kontext-spezifische Regeln
 if(ist_vor_halb(minute)) {
 // :28-:29: Komplexe Interaktion
 if(hasFast) return FAST;
 if(hasKurz) return KURZ;
 if(hasBald) return BALD;
 }

 return DEFAULT;
}

Lernziel: Dynamische Systeme mit kontextabhängiger Prioritätsselektion

Deklarative Programmierung in V0.2¶

Paradigmenwechsel: Von Imperativ zu Deklarativ¶

CharGraph V0.2 führt einen fundamentalen Paradigmenwechsel ein: Deklarative Programmierung statt imperative if-else-Kaskaden.

Lernziel¶

Schüler und Studenten verstehen:

Den Unterschied zwischen imperativem und deklarativem Code
Vorteile der Trennung von Daten und Logik
Rule-Engine-Pattern in modernen Softwaresystemen
Wartbarkeit und Testbarkeit durch Modularisierung

Was ist deklarative Programmierung?¶

Imperativ: "WIE etwas gemacht wird" (Ablauf, Schritt-für-Schritt)

Deklarativ: "WAS erreicht werden soll" (Ziel, Beschreibung)

Vergleich am Beispiel¶

Aufgabe: Finde alle geraden Zahlen in einer Liste und verdoppele sie.

Imperativ (JavaScript):

let zahlen = [1, 2, 3, 4, 5, 6];
let ergebnis = [];

for(let i = 0; i < zahlen.length; i++) {  // WIE: Schleife
  if(zahlen[i] % 2 === 0) {                // WIE: Bedingung
    ergebnis.push(zahlen[i] * 2);          // WIE: Operation
  }
}
// ergebnis = [4, 8, 12]

Deklarativ (JavaScript):

let zahlen = [1, 2, 3, 4, 5, 6];
let ergebnis = zahlen
  .filter(n => n % 2 === 0)   // WAS: Nur gerade Zahlen
  .map(n => n * 2);           // WAS: Verdoppeln
// ergebnis = [4, 8, 12]

CharGraph V0.1 vs. V0.2¶

V0.1: Imperativer Ansatz (285 Zeilen if-else)¶

Problem: Zeit in Wörter umwandeln

function getTimeWords(hh, mm) {
  let words = ["ES", "IST"];

  // 285 Zeilen verschachtelte if-else-Statements
  if(mm === 0) {
    words.push(hours[hh % 12]);
    if(hasUhr) words.push("UHR");
  }
  else if(mm === 1) {
    words.push("NACH", hours[hh % 12]);
  }
  else if(mm === 2) {
    if(hasKurz) {
      words.push("KURZ", "NACH", hours[hh % 12]);
    } else {
      words.push("NACH", hours[hh % 12]);
    }
  }
  else if(mm === 3) {
    if(hasBald && hasFast) {
      words.push("BALD", "FÜNF", "NACH", hours[hh % 12]);
    } else if(hasBald) {
      // ...
    }
    // ... weitere 55 else-if Blöcke
  }

  return words;
}

Probleme: - ❌ Schwer lesbar: Man muss den gesamten Code durchgehen - ❌ Schwer wartbar: Änderung an :29 kann :30 beeinflussen - ❌ Schwer testbar: Viele Pfade, schwer zu isolieren - ❌ Fehleranfällig: Copy-Paste-Fehler, vergessene Fälle

V0.2: Deklarativer Ansatz (60 Regel-Objekte)¶

Lösung: Daten-getriebene Regel-Engine

// Datenstruktur: Array von Regel-Objekten
const MINUTE_RULES = [
  // Regel 0: Volle Stunde
  {
    range: [0, 0],
    handler: (ctx) => [ctx.hourWord, ...(ctx.hasUhrAtEnd ? ["UHR"] : [])]
  },

  // Regel 1-2: NACH
  {
    range: [1, 2],
    handler: (ctx) => {
      if(ctx.mm === 2 && ctx.hasKurz) {
        return ["KURZ", "NACH", ctx.hourWord];
      }
      return ["NACH", ctx.hourWord];
    }
  },

  // Regel 3-4: BALD FÜNF NACH
  {
    range: [3, 4],
    handler: (ctx) => {
      // Priorität 1: FAST (mit Validierung!)
      if(ctx.hasFast && ctx.mm === 4) {
        const test = ["FAST", "FÜNF", "NACH", ctx.hourWord];
        if(validate(test)) return test;
      }
      // Priorität 2: BALD
      if(ctx.hasBald) {
        return ["BALD", "FÜNF", "NACH", ctx.hourWord];
      }
      // Fallback
      return ["NACH", ctx.hourWord];
    }
  },

  // ... 57 weitere Regeln
];

// Einfache Lookup-Funktion
function getTimeWords(hh, mm) {
  const rule = MINUTE_RULES.find(r =>
    mm >= r.range[0] && mm <= r.range[1]
  );

  const context = buildContext(hh, mm);
  return ["ES", "IST", ...rule.handler(context)];
}

Vorteile: - ✅ Selbstdokumentierend: Jede Regel beschreibt einen Zeitpunkt - ✅ Isolation: Änderung an :29 betrifft nur diese Regel - ✅ Testbar: Jede Regel einzeln testbar - ✅ Erweiterbar: Neue Regel? Einfach hinzufügen!

Visualisierung: Zeit-Mapping¶

CharGraph Time Mapping

Die Grafik zeigt die deklarative Struktur:

Jeder Pfeil = eine deklarative Regel
X-Achse = Minuten (0-59)
Y-Achse = Sprachmuster

Farben: - Grün: Standard-Zeitangaben (FÜNF NACH, ZEHN VOR) - Rot: Modifikatoren (FAST, BALD) - Orange: Spezialfälle (HALB-Zeiten)

Didaktischer Wert¶

Für Schüler (Sek I + II)¶

Unterrichtseinheit: "Deklarative vs. Imperative Programmierung"

Einstieg: Vergleich beider Ansätze an einfachem Beispiel
Vertiefung: CharGraph V0.1 vs. V0.2 Code-Analyse
Praxis: Eigene Regel für :XX hinzufügen
Reflexion: Wartbarkeit, Testbarkeit diskutieren

Lernziele: - Verstehen, wann welcher Ansatz sinnvoll ist - Erkennen von Code-Smells (zu viele if-else) - Refactoring-Techniken anwenden - Design Patterns verstehen (Rule Engine, Strategy Pattern)

Für Studenten (Hochschule)¶

Vertiefung:

Software-Engineering: Wartbarkeitsmetriken (Zyklomatische Komplexität)
Design Patterns: Rule Engine, Strategy, Chain of Responsibility
Functional Programming: First-Class Functions, Higher-Order Functions
Compiler-Bau: DSLs (Domain-Specific Languages)

Code-Metriken im Vergleich¶

Metrik	V0.1 (Imperativ)	V0.2 (Deklarativ)	Verbesserung
Zeilen Code	285	80 (60 Regeln + Infrastruktur)	-72%
Zyklomatische Komplexität	150	3-5 pro Regel	-95%
Test-Coverage	~60% (schwierig)	95% (isoliert)	+58%
Änderungsaufwand	30 Min (Risiko hoch)	5 Min (isoliert)	-83%
Bugs pro 100 LOC	~4	<1	-75%

Praktische Übungen¶

Übung 1: Neue Regel hinzufügen¶

Aufgabe: Füge eine Regel für :57 hinzu: "BALD ZWÖLF UHR"

{
  range: [57, 57],
  handler: (ctx) => {
    const nextHour = ctx.hours[(ctx.h12 + 1) % 12];
    if(ctx.hasBald) {
      return ["BALD", nextHour, "UHR"];
    }
    return ["DREI", "VOR", nextHour];
  }
}

Übung 2: Refactoring V0.1 → V0.2¶

Aufgabe: Wandle diesen imperativen Code um:

// Imperativ
if(mm >= 5 && mm <= 9) {
  if(mm === 9 && hasFast) {
    words.push("FAST", "ZEHN", "NACH");
  } else {
    words.push("FÜNF", "NACH");
  }
}

Lösung:

// Deklarativ
{
  range: [5, 9],
  handler: (ctx) => {
    if(ctx.mm === 9 && ctx.hasFast) {
      return ["FAST", "ZEHN", "NACH", ctx.hourWord];
    }
    return ["FÜNF", "NACH", ctx.hourWord];
  }
}

Weiterführende Konzepte¶

Für fortgeschrittene Schüler:

DSLs (Domain-Specific Languages)
CharGraph-Regeln als eigene "Sprache"
SQL, CSS, HTML als deklarative DSLs
Functional Reactive Programming
Daten-Streams und Transformationen
RxJS, React Hooks
Constraint Logic Programming
Prolog, MiniZinc
Automatische Lösungsfindung

Lernziel: Moderne Software-Paradigmen verstehen und anwenden

Constraint-Satisfaction¶

Das CSP-Problem¶

Gegeben:

Begrenztes 11×10 Raster (110 Positionen)
Menge von Wörtern W = {ES, IST, FÜNF, ZEHN, ...}
Regeln R für Platzierung

Gesucht:

Zuweisung Position(w) für jedes Wort w ∈ W
So dass alle Regeln r ∈ R erfüllt sind

Constraints¶

C1: Eindeutigkeit

Jede Position darf nur einen Buchstaben enthalten
∀ p: |{w | p ∈ Position(w)}| ≤ 1

C2: Ordnung

Position(FÜNF_Minuten) < Position(HALB) < Position(FÜNF_Stunde)
Position(ES) < Position(IST) < ... < Position(UHR)

C3: Nachbarschaft

∀ p: Buchstabe(p) ≠ Buchstabe(p+1) (horizontal)
∀ p: Buchstabe(p) ≠ Buchstabe(p+11) (vertikal)

C4: Vollständigkeit

∀ w ∈ W_erforderlich: Position(w) existiert

Lösungsstrategien¶

Greedy-Ansatz: Wörter nacheinander platzieren
Backtracking: Bei Konflikt zurückgehen
Constraint-Propagation: Unmögliche Positionen frühzeitig ausschließen
Heuristiken: Wichtige Wörter zuerst platzieren

Visuelle Feedback-Logik¶

Wie ein Mensch denkt - Intuitive Punktelogik¶

Designprinzip: Die Punktedarstellung muss der menschlichen Intuition folgen, nicht nur mathematisch korrekt sein.

Menschliche Erwartung bei "NACH":¶

13:07 → "FÜNF NACH EINS" + ●●
Denkweise: "5 NACH + 2 Punkte = 7 Minuten nach" 
Berechnung: 5 + 2 = 7 Minuten nach 13:00 → 13:07

Der Mensch addiert die Punkte zur Basis-Anzeige.

Menschliche Erwartung bei "VOR":¶

13:53 → "ZEHN VOR ZWEI" + ●●●
Denkweise: "10 VOR - 3 Punkte = 7 Minuten vor" 
Berechnung: 10 - 3 = 7 Minuten vor 14:00 → 13:53

Der Mensch subtrahiert die Punkte von der Basis-Anzeige.

** Falsche Implementierung (mathematisch korrekt, aber kontraintuitiv):**

13:53 → "ZEHN VOR ZWEI" + ●● (invertiert)
Denkweise: "10 VOR - 2 Punkte = 8 Minuten vor" 
Berechnung: 10 - 2 = 8 Minuten vor 14:00 → 13:52 ≠ 13:53!

Menschliche Erwartung bei "BALD":¶

13:58 → "BALD ZWEI" + ●●
Denkweise: "BALD bedeutet gleich → noch 2 Minuten fehlen" 
Berechnung: 14:00 - 2 Minuten = 13:58

Der Mensch interpretiert die Punkte als fehlende Zeit bis zum Ereignis.

Zwei-Modi-System für Anzeigepunkte¶

Die 4 LED-Punkte zeigen Minuten zwischen 5-Minuten-Schritten an.

Problem: Wie zeigt man Zwischenwerte konsistent mit menschlicher Intuition?

Unterscheidung der beiden Modi

Progressive Punkte (von links, addieren):

LEDs werden von links nach rechts angezeigt
Die Anzahl wird zur angezeigten Zeit addiert
Tritt auf bei: positivem Offset (tatsächliche Zeit > angezeigte Zeit)
Bedeutung: "Minuten, die zur angezeigten Zeit addiert werden müssen"

Regressive Punkte (von rechts, subtrahieren):

LEDs werden von rechts nach links angezeigt
Die Anzahl wird von der angezeigten Zeit subtrahiert
Tritt auf bei: negativem Offset (tatsächliche Zeit < angezeigte Zeit)
Bedeutung: "Minuten, die von der angezeigten Zeit subtrahiert werden müssen"

Berechnungslogik¶

Grundprinzip: Die LED-Richtung und -Anzahl werden durch den Offset zwischen angezeigter und tatsächlicher Zeit bestimmt.

Berechnung:

signedOffset = actualMinute - displayedMinute;
remainder = Math.abs(signedOffset);
direction = signedOffset < 0 ? "rechts" : "links";

Beispiele Addieren (positive Offsets, LEDs von links):

13:07 → "FÜNF NACH EINS" + ●● (von links)
Angezeigt: FÜNF NACH = 13:05, Offset: +2
Interpretation: 5 NACH + 2 = 7 Minuten nach 13:00
13:31 → "NACH HALB ZWEI" + ● (von links)
Angezeigt: HALB = 13:30, Offset: +1
Interpretation: HALB + 1 = 13:31
13:33 → "NACH HALB ZWEI" + ●●● (von links)
Angezeigt: HALB = 13:30, Offset: +3
Interpretation: HALB + 3 = 13:33

Beispiele Subtrahieren (negative Offsets, LEDs von rechts):

10:53 → "FÜNF VOR ELF" + ●● (von rechts)
Angezeigt: FÜNF VOR = :55, Offset: -2
Interpretation: 55 - 2 = 53

Gemischte Beispiele (VOR kann beide Richtungen haben!):

03:51 → "ZEHN VOR VIER" + ● (von links, positiver Offset!)
Angezeigt: ZEHN VOR = :50, Offset: +1
Interpretation: 50 + 1 = 51

Beispiele mit BALD/FAST (negative Offsets):

13:58 → "BALD ZWEI" + ●● (von rechts)
Angezeigt: BALD ZWEI = :60 (volle Stunde)
Offset: :58 - :60 = -2
Interpretation: 60 - 2 = 58 (noch 2 Minuten bis 14:00)
06:27 → "BALD HALB SIEBEN" + ●●● (von rechts)
Angezeigt: BALD HALB = :30
Offset: :27 - :30 = -3
Interpretation: 30 - 3 = 27 (noch 3 Minuten bis HALB)
14:04 → "BALD FÜNF NACH ZWEI" + ● (von rechts)
Angezeigt: FÜNF NACH = :05
Offset: :04 - :05 = -1
Interpretation: 5 - 1 = 4 (noch 1 Minute bis FÜNF NACH)

Wichtig: Die Richtung hängt vom Offset ab, nicht von den Schlüsselwörtern!

01:02 → "KURZ NACH EINS" + ●● (von links!)
Angezeigt: NACH = :00 (volle Stunde)
Offset: :02 - :00 = +2 (positiv!)
Interpretation: 0 + 2 = 2 (2 Minuten nach der vollen Stunde)

Logik-Implementierung¶

// 1. Berechne die angezeigte Minute basierend auf den Wörtern
const displayedMinute = calculateDisplayedMinute(wordsToLight);

// 2. Berechne Offset mit Vorzeichen
const signedOffset = actualMinute - displayedMinute;
const remainder = Math.abs(signedOffset);

// 3. LED-Richtung: positiv = links, negativ = rechts
const isInvertedDisplay = signedOffset < 0;

// 4. LEDs anzeigen
for(let i = 0; i < remainder; i++) {
 const dotIndex = isInvertedDisplay ? (3 - i) : i; // rechts → links oder links → rechts
 if(dots[dotIndex]) dots[dotIndex].classList.add('lit');
}

Die Funktion calculateDisplayedMinute() berücksichtigt:

HALB-basierte Kombinationen: "FÜNF VOR HALB" = :25, "HALB" = :30, "FÜNF NACH HALB" = :35
Minutenmarker: "FÜNF NACH" = :05, "ZEHN VOR" = :50, "VIERTEL NACH" = :15
BALD/FAST ohne Marker: "BALD [STUNDE]" = :60 (volle Stunde)
Reine Präpositionen: "NACH" = :00, "VOR" = :60

Wichtige Regel: Die LED-Richtung hängt vom Offset zwischen angezeigter und tatsächlicher Zeit ab!

Die Entscheidung, ob LEDs von links oder rechts angezeigt werden, wird durch den Offset zur angezeigten Zeit bestimmt:

Von rechts (subtrahieren) - Negative Offsets:

"BALD HALB SIEBEN" (06:27)
- Angezeigt: BALD HALB = :30
- Offset: 27 - 30 = -3 (negativ!)
- LEDs: ●●● von rechts
- Operation: 30 - 3 = 27 ✓
"FÜNF VOR ELF" (10:53)
- Angezeigt: FÜNF VOR = :55
- Offset: 53 - 55 = -2 (negativ!)
- LEDs: ●● von rechts
- Operation: 55 - 2 = 53 ✓

Von links (addieren) - Positive Offsets:

"KURZ NACH EINS" (01:02)
- Angezeigt: NACH = :00
- Offset: 02 - 00 = +2 (positiv!)
- LEDs: ●● von links
- Operation: 0 + 2 = 2 ✓
"FÜNF NACH ZWEI" (14:07)
- Angezeigt: FÜNF NACH = :05
- Offset: 07 - 05 = +2 (positiv!)
- LEDs: ●● von links
- Operation: 5 + 2 = 7 ✓
"ZEHN VOR VIER" (03:51)
- Angezeigt: ZEHN VOR = :50
- Offset: 51 - 50 = +1 (positiv!)
- LEDs: ● von links
- Operation: 50 + 1 = 51 ✓

Spezialfall: Warum kein "KURZ FÜNF VOR"?¶

5-Minuten-Regel und natürliche Sprache

Problem: Bei 10:53 ohne BALD/FAST - welche Anzeige ist korrekt?

Falsche Ansätze:

❌ Variante A: "ZEHN VOR ELF" + 3 LEDs von links - Berechnung: 50 + 3 = 53 ✓ (mathematisch korrekt) - Problem: Verstößt gegen die 5-Minuten-Regel - :53 ist näher an :55 (2 Min) als an :50 (3 Min) - LEDs von links bei VOR ist visuell inkonsistent

❌ Variante B: "KURZ FÜNF VOR ELF" - Sprachlich unnatürlich im Deutschen - Niemand sagt "ES IST KURZ FÜNF VOR ELF" - KURZ funktioniert nur mit direkten Zeitmarken: "KURZ VOR HALB", "KURZ NACH EINS"

✓ Korrekte Lösung: "FÜNF VOR ELF" + 2 LEDs von rechts - Angezeigt: FÜNF VOR = :55 - Offset: 53 - 55 = -2 (negativ) - Berechnung: 55 - 2 = 53 ✓ - LEDs von rechts (negativer Offset) ✓ - Sprachlich natürlich ✓

Weitere Beispiele mit dieser Logik:

10:58 → "VOR ELF" + 2 LEDs von rechts (60 - 2 = 58)
Nicht "FÜNF VOR ELF" (wäre 55 - 3 = 52 ❌)
:58 ist näher an :00 (2 Min) als an :55 (3 Min)
10:58 mit BALD → "BALD ELF" + 2 LEDs von rechts
10:58 mit FAST → "FAST ELF" + 2 LEDs von rechts
10:58 mit KURZ → "KURZ VOR ELF" + 2 LEDs von rechts

Lernziel: Kontext-abhängige Berechnung, User Experience Design, menschenzentrierte Algorithmik, natürliche Sprachlogik

Test-Driven Development¶

Systematische Test-Strategie¶

Kategorien¶

Äquivalenzklassen-Tests
Volle Stunden (X:00)
5-Minuten-Schritte (X:05, X:10, X:15, ...)
Zwischenwerte (X:01-X:04, X:06-X:09, ...)
Grenzwert-Tests
Mitternacht (00:00)
Mittag (12:00)
Tagesübergang (23:59 → 00:00)
Spezialfall-Tests
Minute 04: "BALD FÜNF NACH"
Minute 29: FAST-Priorität
Minute 45-49: DREIVIERTEL vs. VIERTEL VOR
01:00: "ES IST EIN UHR" (wenn UHR als letztes Wort) vs. "ES IST EINS" (wenn UHR fehlt/nicht am Ende)

Test-Beispiele (Minute 29 - Lernfall)¶

Testziel: Prioritäts-Logik verstehen

Variante	KURZ	FAST	BALD	Erwartetes Ergebnis	Begründung
kfb	✗	✗	✗	"VOR HALB"	Keine Modifikatoren
kfB	✗	✗	✓	"BALD HALB"	BALD vorhanden
kFb	✗	✓	✗	"FAST HALB"	FAST vorhanden
kFB	✗	✓	✓	"FAST HALB"	FAST > BALD bei m=29
Kfb	✓	✗	✗	"KURZ VOR HALB"	KURZ vorhanden
KfB	✓	✗	✓	"BALD HALB"	BALD > KURZ
KFb	✓	✓	✗	"FAST HALB"	FAST > KURZ
KFB	✓	✓	✓	"FAST HALB"	FAST hat Priorität

Code-Implementierung:

if(minute === 29) {
 if(hat_FAST) return [..., "FAST", "HALB", ...];
 else if(hat_KURZ) return [..., "KURZ", "VOR", "HALB", ...];
 else if(hat_BALD) return [..., "BALD", "HALB", ...];
 else return [..., "VOR", "HALB", ...];
}

Automatisierte Tests¶

// Unit Test Framework
describe('Zeitberechnung', () => {
 test('13:00 sollte "EIN UHR" ergeben (wenn UHR am Ende)', () => {
 const patternMitUhr = "ESIST...EIN...UHR___"; // UHR als letztes Wort
 expect(berechneZeit(13, 0, patternMitUhr)).toEqual(["ES", "IST", "EIN", "UHR"]);
 });

 test('13:00 sollte "EINS" ergeben (wenn UHR fehlt)', () => {
 const patternOhneUhr = "ESIST...EINS...NACHT"; // Kein UHR am Ende
 expect(berechneZeit(13, 0, patternOhneUhr)).toEqual(["ES", "IST", "EINS"]);
 });

 test('13:29 mit FAST sollte "FAST HALB ZWEI" ergeben', () => {
 const pattern = "...FAST...HALB...";
 expect(berechneZeit(13, 29, pattern)).toContain("FAST");
 });
});

Validierung und Qualitätssicherung¶

Mehrschichtige Validierung¶

Ebene 1: Strukturvalidierung¶

Prüfung: Sind alle erforderlichen Komponenten vorhanden?

function validiereStruktur(layout) {
 const erforderlich = ["ES", "IST", "HALB", "UHR", "VOR", "NACH"];
 const fehlt = erforderlich.filter(wort => !layout.includes(wort));

 if(fehlt.length > 0) {
 return {gültig: false, fehler: `Fehlende Wörter: ${fehlt}`};
 }
 return {gültig: true};
}

Ebene 2: Nachbarschafts-Validierung¶

Prüfung: Gibt es identische benachbarte Buchstaben?

function prüfeNachbarn(raster, zeilen=10, spalten=11) {
 for(let z = 0; z < zeilen; z++) {
 for(let s = 0; s < spalten; s++) {
 const index = z * spalten + s;
 const zeichen = raster[index];

 // Horizontal
 if(s < spalten - 1 && zeichen === raster[index + 1]) {
 return {fehler: `Dopplung bei Position ${index}`};
 }

 // Vertikal
 if(z < zeilen - 1 && zeichen === raster[index + spalten]) {
 return {fehler: `Dopplung bei Position ${index}`};
 }
 }
 }
 return {gültig: true};
}

Ebene 3: Schutzrechts-Compliance¶

Prüfung: Ist das Layout identisch mit geschützten Designs?

function prüfeSchutzrechte(layout) {
 const geschützteLayouts = [
 "ESKISTAFÜNFZEHNZWANZIG...", // Beispiel geschütztes Design
 // Weitere geschützte Varianten
 ];

 for(const geschützt of geschützteLayouts) {
 if(vergleicheLayouts(layout, geschützt)) {
 return {
 gültig: false,
 warnung: "Layout ist identisch mit geschütztem Design!",
 hinweis: "Bitte eigenes Design entwickeln."
 };
 }
 }
 return {gültig: true};
}

Qualitätsmetriken¶

Lesbarkeit:

Durchschnittliche Anzahl beleuchteter Buchstaben
Minimale/Maximale Wortlänge
Gleichmäßige Verteilung

Effizienz:

Anzahl ungenutzter Felder
Wiederverwendung von Buchstaben (z.B. FÜNF als Minute und Stunde)

Wartbarkeit:

Konsistente Positionierung
Logische Gruppierung
Dokumentation im Code

Erweiterte Lernziele¶

Informatik-Konzepte, die durch dieses Projekt vermittelt werden:¶

1. Datenstrukturen¶

Arrays und Strings
2D-Matrizen
Hash-Maps für Wort-Lookup

2. Algorithmen¶

Modulo-Arithmetik
Range-Mapping
Prioritäts-Queues
Constraint-Satisfaction

3. Software-Design¶

Separation of Concerns
Model-View-Controller Pattern
State Management

4. User Interface Design¶

Drag-and-Drop Interaktion
Echtzeit-Feedback
Visuelle Validierung

5. Qualitätssicherung¶

Unit Testing
Integration Testing
Validierung gegen Constraints

CAD-Tool-Funktionalität¶

Editor-Features¶

Visuelle Gestaltung:

Interaktives 11×10 Raster
Manuelle Buchstabeneingabe
Undo/Redo-Funktionalität

Wort-Palette mit Drag-&-Drop:

Einleitung: ES, IST, WIR (Alternative zu ES), HABEN (Alternative zu IST)
- Beispiel: "ES IST DREI UHR" oder "WIR HABEN DREI UHR"
Zeiteinheiten: FÜNF, ZEHN, VIERTEL, ZWANZIG (optional), HALB, DREIVIERTEL (optional)
Präpositionen: VOR, NACH, KURZ (optional), BALD (optional), FAST (optional)
Stunden: EINS, EIN, ZWEI, DREI, VIER, FÜNF, SECHS, SIEBEN, ACHT, NEUN, ZEHN, ELF, ZWÖLF
Extras: NACHT, PAUSE, ZEIT, ALARM, RWD
Eigener Text: Individueller Text bis 11 Zeichen
Ende: UHR

Aufklappbare Gruppen:

Jede Palette-Gruppe kann individuell eingeklappt werden
Klick auf Label (mit ▼-Symbol) klappt Gruppe ein/aus
Status wird in localStorage gespeichert und bleibt nach Reload erhalten
Standard: Alle Gruppen geöffnet
Spart Platz bei wenig genutzten Kategorien

Intelligente Durchstreichung verwendeter Wörter:

Stunden: nur durchgestrichen, wenn HALB existiert UND Wort nach HALB steht
Zeiteinheiten/Präpositionen: nur durchgestrichen, wenn Wort vor HALB steht
HALB: durchgestrichen, wenn vorhanden
Andere Wörter: durchgestrichen, wenn im Grid vorhanden

Hover-Effekt auf durchgestrichenen Wörtern:

Zeigt das Wort im Grid grün hervorgehoben
Gilt nur für bereits verwendete (durchgestrichene) Wörter

Simulation:

Test-Szenarien (01:00-02:00, 23:00-00:05)
Echtzeit-Beleuchtungs-Vorschau
Punkt-Anzeige-Simulation

Live-Uhrzeit-Modus (REALTIME):

Automatische Aktualisierung jede Sekunde
Textausgabe wird ausgeblendet (nur visuelle Anzeige aktiv)

Navigationsknöpfe (← / →):

Keyboard-Shortcuts: Pfeiltasten ← und →
Automatische Deaktivierung am Anfang/Ende der Liste
Deaktiviert bei REALTIME und CUSTOM-Modus

Textausgabe als Footer:

Zeigt die beleuchteten Wörter in Textform an
Feste Breite (berechnet beim Laden basierend auf maximaler Textlänge)
Mittige Positionierung innerhalb der Simulator-Box
Wird automatisch bei REALTIME-Modus ausgeblendet

Validierung:

Automatische Struktur-Prüfung
Duplikat-Warnung
Schutzrechts-Check
Export-Freigabe

Vorschläge und Hilfen:

Vorschlags-Funktion mit vorgefertigten Layouts
Zufälliges Füllen leerer Felder (unter Beachtung der Nachbarschaftsregeln)

Automatische Vorschlagsnummer-Anzeige:

Button-Text ändert sich zu "Vorschlag (11)" wenn aktuelle Darstellung mit einem Vorschlag übereinstimmt
Erscheint nur wenn das Grid sinnvollen Inhalt hat (mindestens 10 Zeichen außer Füllzeichen)
Erscheint automatisch im Button-Text in Klammern (1, 2, 3, etc.)
Ignoriert Füllzeichen ('_') beim Vergleich
Button ist für 2-stellige Nummern vorformatiert (min-width: 145px)

Export:

Pattern-String (110 Zeichen)
3D-STL für Prototyping
Dokumentation (Markdown)

Ausblick und Erweiterungsmöglichkeiten¶

Hardware-Erweiterungen¶

Die universelle Platine kann für weitere Projekte genutzt werden:

1. Spiele-Konsole:

Snake-Implementierung
Tetris-Variante
Reaktionsspiele

2. Daten-Visualisierung:

Audio-Spektrum-Analyzer
Temperatur-Heatmap
Netzwerk-Aktivität

3. IoT-Integration:

WLAN-Modul für Wetteranzeige
MQTT für Smart-Home-Status
API-Anbindung für Social-Media

Software-Erweiterungen¶

1. Multi-Language Support:

Englische Zeitangaben
Französische Varianten
Andere Sprachen

2. Animations-Engine:

Sanfte Übergänge
Lauftext-Modus
Effekte

3. KI-Integration:

Automatische Layout-Optimierung
Genetische Algorithmen für beste Platzierung
Machine Learning für Nutzer-Präferenzen

Zusammenfassung¶

Kernkompetenzen, die erlernt werden:¶

Algorithmisches Denken

Problemzerlegung
Abstrahierung
Mustererkennung

Software-Engineering

Design-Patterns
Testing-Strategien
Validierung

Mathematik/Logik

Modulo-Arithmetik
Constraint-Satisfaction
Boolean Logic

User Experience

Interface-Design
Feedback-Mechanismen
Visuelles Design

Pädagogischer Wert¶

Dieses Projekt verbindet: - Theorie (Algorithmen, Datenstrukturen) - Praxis (Implementierung, Testing) - Kreativität (Layout-Design, Varianten) - Problemlösung (Constraints, Optimierung)

Es eignet sich für: - Informatik-Unterricht (Sekundarstufe II, Hochschule) - Maker-Spaces und Coding-Clubs - ‍ Lehrerfortbildung - Projektwochen und Hackathons

Schutzrechtliche Situation (Stand 2025)¶

Übersicht der Patentfamilie¶

Für die zentrale Wortuhr-Erfindung von Biegert & Funk ist das maßgebliche Patent im Kern bereits ausgelaufen bzw. läuft weltweit in diesen Jahren aus. Die Patentfamilie umfasst DE202009017703U1 / US9041632B2 ("Device for displaying a text message") mit Priorität aus dem Jahr 2009.

Laufzeit des Hauptpatents¶

Technische Patente:

Grundsätzliche Laufzeit: 20 Jahre ab Anmeldetag
Für eine 2009er Anmeldung: reguläres Laufzeitende um 2029
Nationale Teile können früher erlöschen durch:
Nichtzahlung von Jahresgebühren
Vorzeitige Aufgabe des Schutzes

Bereits ausgelaufene Schutzrechte¶

Deutsches Gebrauchsmuster DE202009017703U1:

Anmeldung: 29.12.2009
Maximale Laufzeit: 10 Jahre (gesetzliche Höchstdauer für Gebrauchsmuster in Deutschland)
Ablauf: 30.12.2019 (sicher abgelaufen)
Status: In Deutschland besteht aus diesem Gebrauchsmuster kein technischer Schutz mehr

Konsequenz: Die im Gebrauchsmuster beschriebenen technischen Merkmale (feste Buchstabenmatrix, Ansteuerung zur Bildung von Uhrzeit-Texten) sind in Deutschland nicht mehr exklusiv Biegert & Funk vorbehalten.

Andere Länder:

Einzelne nationale Teile der Patentfamilie können durch Nichtzahlung der Jahresgebühren bereits vor Ablauf der 20 Jahre erloschen sein
Für verbindliche Auskunft: Einsicht in jeweilige Patentregister (DPMA, EPA, USPTO) erforderlich

Noch laufende Schutzrechte¶

US-Patent US9041632B2:

Priorität: 2009
Reguläre Laufzeit: bis ca. 2029 (wenn Jahresgebühren gezahlt werden)

Neuere Patente:

EP3396656A1 / US20180314126A1 ("Display Device with E-Paper-Front")
Anmeldedatum: ca. 2016
Laufzeit: bis ca. 2036 (bei fortlaufender Gebührenzahlung)
Betrifft: Spezielle E-Paper-Varianten und neuere Steuerkonzepte

US-Design-Patente (Erscheinungsbild):

USD681483 S ("Watch")
USD744862 S ("Matrix clock")
Laufzeit: jeweils 15 Jahre ab Erteilung
Schutzgegenstand: Das optische Erscheinungsbild der QLOCKTWO

Was ist erlaubt¶

Freie Nutzung in Deutschland: Die technische Lehre des abgelaufenen deutschen Gebrauchsmusters darf frei genutzt werden:

Erlaubt:

Herstellung eigener Wortuhren mit Buchstabenmatrix-Konzept
Verwendung der Grundidee "Matrix fester Zeichen + Steuerung zur Bildung von Uhrzeittexten"
Entwicklung, Herstellung und Vertrieb in Deutschland
Freie Gestaltung eigener Wortauswahl und Layout-Designs
Eigene technische Ausgestaltung (Schaltung, Software, Matrix-Layout)

Praktisches Beispiel CharGraph: Ein Wortuhr-Bausatz mit diesen Merkmalen ist in Deutschland grundsätzlich zulässig: - Vom Käufer frei wählbare Wortanordnung - Minutenanzeige unterhalb (statt in den Ecken) - Fixe kompakte Größe (18×18 cm) - Eigenständiges Design und Layout

Was weiterhin zu beachten ist¶

Weiterhin geschützt:

1. Neuere/andere Patente:

Speziellere Display-Lösungen (E-Paper-Varianten)
Besondere Steuerungskonzepte
Technische Verbesserungen mit späteren Anmeldedaten
Keine 1:1-Übernahme von Anspruchsmerkmalen noch laufender Patente

2. Designschutz (Geschmacksmuster):

Die spezifischen visuellen Gestaltungen von QLOCKTWO sind durch Geschmacksmuster für die EU geschützt
Formgebung, Look, Proportionen der QLOCKTWO
Charakteristische Typografie und Frontplatten-Design
Erforderlich: Erkennbar eigenständiges Design wählen

3. Urheberrecht:

Das Design genießt Urheberrechtsschutz bis 70 Jahre nach Tod der Gründer
Betrifft: Gesamtanmutung und künstlerische Gestaltung

4. Markenschutz:

Der Name "QLOCKTWO" und die Marke bleiben geschützt
Logos und charakteristische Bezeichnungen sind geschützt
Erforderlich: Eigenständiger Name (z.B. "CharGraph" ist unkritisch)

Rechtssichere Umsetzung¶

Technische Ebene:

Eigene Schaltung und Software entwickeln
Eigenes Layout der Buchstabenmatrix
Eigene Minutenanzeige-Lösung
Keine 1:1-Übernahme patentbeschriebener Details aus neueren Patenten

Gestalterische Ebene:

Erkennbar eigenständiges Design wählen
Andere Proportionen, Typografie, Materialanmutung
Marken/Claims wie "QLOCKTWO" strikt meiden
Optisch extrem ähnliche Frontplatten vermeiden

Namensgebung:

Eigenständige Produktbezeichnung (z.B. "CharGraph")
Keine Verwendung geschützter Bezeichnungen
Keine Verwechslungsgefahr erzeugen

Fazit¶

Technisches Prinzip: Frei verwendbar in Deutschland

Die Grundidee "Wortuhr mit Buchstabenmatrix" aus dem abgelaufenen Gebrauchsmuster ist gemeinfrei
Eigene Implementierungen sind zulässig

Design und Marke: Weiterhin geschützt

Jede Implementierung muss ein eigenständiges Design aufweisen
Individuelle Buchstabenmatrix, eigene Wortauswahl, eigenes visuelles Erscheinungsbild
Keine Nachahmung der geschützten QLOCKTWO-Optik

Empfehlung für ernsthafte Projekte: Bei kommerziellem Vertrieb im größeren Umfang empfiehlt sich eine aktuelle Schutzrechtsrecherche im jeweiligen Zielmarkt (DPMA, EPA, USPTO), um letzte länderspezifische Risiken auszuschließen.

Weitere Ressourcen¶

Weiterführende Lernmaterialien¶

Constraint-Satisfaction-Probleme:

Russell & Norvig: "Artificial Intelligence - A Modern Approach"
Online-Kurse zu CSP auf Coursera, edX

Algorithmisches Design:

Knuth: "The Art of Computer Programming"
Cormen et al.: "Introduction to Algorithms"

User Interface Design:

Norman: "The Design of Everyday Things"
Nielsen: "Usability Engineering"

Entwickelt für Bildungszwecke | Open Educational Resource Version 0.37 | Stand 2026-01-01 CharGraph Editor - CAD-Tool mit integriertem Simulator

Abschließende rechtliche Hinweise¶

Dieses Projekt und diese Dokumentation dienen ausschließlich Bildungs- und Lehrzwecken im Rahmen von §53 UrhG (Deutschland). Die universelle LED-Platine kann für vielfältige pädagogische Projekte verwendet werden.

Wichtig:

Respektieren Sie bestehende Schutzrechte
Entwickeln Sie eigene kreative Lösungen
Nutzen Sie das Tool für Lernzwecke
Kommerzielle Nachbildungen geschützter Designs sind untersagt

Haftungsausschluss: Die Autoren übernehmen keine Haftung für missbräuchliche Verwendung oder Verletzung von Schutzrechten durch Dritte.