Übungsaufgaben zu Programmiersprachen und Paradigmen

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „Programmiersprachen und
Paradigmen“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/programmiersprachen
- https://oer-informatik.de/entwicklungswerkzeuge
- Stilbeispiel: https://oer-informatik.de/programmiersprachen-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Programmiersprache
- Compiler
- Interpreter
- Skriptsprache
- Fehlerarten
- strukturierte Programmierung
- objektorientierte Programmierung
- Auswahlkriterien

Kompetenzstufe: Basiskompetenz (alternativ: Kernkompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

Ein Compiler übersetzt den gesamten Quelltext vor der Ausführung in Maschinencode und speichert ihn als ausführbares Programm; auf dem ESP32 läuft dann direkt Maschinencode, schnell und mit wenig Rechenaufwand (1,5 Punkte). Ein Interpreter liest den Quelltext zur Laufzeit Anweisung für Anweisung, übersetzt und führt sie sofort aus; das kostet bei jeder Ausführung Rechenzeit und damit Energie, Änderungen sind aber sofort testbar (1,5 Punkte).

Ziffer 2 (2 Punkte). Aussage 1 beschreibt einen Interpreter, Logikfehler (3) findet kein Compiler, Maschinencode (4) ist an eine Prozessorarchitektur gebunden, und Skriptsprachen (5) werden meist interpretiert.

Je richtiger Zuordnung 1 Punkt: A–4, B–3, C–1, D–2.

Je 1 Punkt: (1) Syntaxfehler – der Compiler meldet ein fehlendes Semikolon; (2) Logikfehler – das Programm läuft, liefert aber ein falsches Ergebnis (z. B. Zeitzone falsch berechnet); (3) Laufzeitfehler – das Programm ist korrekt übersetzt, bricht aber während der Ausführung ab.

Kriterium 1 Punkt, Begründung 2 Punkte, z. B.:

• Energiebedarf und Leistung: Die Schilder laufen mit Akku; kompilierter C++-Code braucht weniger Rechenzeit, der Mikrocontroller kann länger schlafen, der Akku hält länger.

• Know-how im Team: Die Schüler*innen kennen Python aus dem Unterricht; mit MicroPython ist die Firmware schneller fertig und leichter von anderen zu pflegen.

• Verfügbare Bibliotheken: Für E-Paper-Displays und MQTT müssen gepflegte Bibliotheken für die Sprache vorhanden sein, sonst steigt der Aufwand stark.

Je Vorteil 1 Punkt, z. B.: Abbild der realen Dinge (Klassen Werkstattauftrag, Fahrrad, Ersatzteil); Kapselung schützt Daten vor unzulässigen Änderungen; Wiederverwendbarkeit und Erweiterbarkeit durch Vererbung; bessere Wartbarkeit, Änderungen bleiben in einer Klasse; Arbeitsteilung über klare Schnittstellen.

Ziffern 1 und 3 (je 1 Punkt).

Je 1 Punkt: A deklarativ (SQL beschreibt, welches Ergebnis gewünscht ist); B objektorientiert (Klasse mit gekapseltem Attribut und Methode); C prozedural (Funktion mit Parameter); D keine Programmiersprache (HTML ist eine Auszeichnungssprache ohne Variablen, Verzweigungen und Schleifen).

Ziffer 2 (2 Punkte).

• Begründung (2 Punkte): Clientseitiger Code läuft auf dem Gerät der Kundschaft und lässt sich mit den Entwicklerwerkzeugen des Browsers verändern; ein manipulierter Preis würde sonst übernommen. Auf dem Server sind Berechnung, aktuelle Preise aus der Datenbank und Rabattregeln geschützt; die Anzeige im Browser dient nur als Vorschau.

• Sprachen (je 1 Punkt): clientseitig JavaScript (bzw. TypeScript); serverseitig z. B. PHP, Python, Java, C# oder JavaScript mit Node.js.

Das Sequenzdiagramm zeigt den Ablauf: Der Browser berechnet nur eine Vorschau, den verbindlichen Preis ermittelt der Webserver mit den Preisen und Rabattregeln aus der Datenbank.

Je richtiger Zeile 0,5 Punkte: 1 Go, 2 Go, 3 Python, 4 Python, 5 C#, 6 C#.

Zu Zeile 1: Erwartet ist Go, weil eine einzelne, eigenständige Programmdatei dort der Standardweg ist. Auch C# kann mit Zusatzoptionen beim Veröffentlichen (dotnet publish als self-contained single-file oder mit Native AOT) eine eigenständige Datei erzeugen, die ohne installierte .NET-Laufzeit startet. Wer C# einträgt und das begründet, erhält die Punkte ebenfalls.

Nutzwert = Summe aus Gewicht × Bewertung:

• Python: 0,35 · 5 + 0,25 · 5 + 0,15 · 2 + 0,25 · 3 = 1,75 + 1,25 + 0,30 + 0,75 = 4,05

• Go: 0,35 · 2 + 0,25 · 3 + 0,15 · 5 + 0,25 · 5 = 0,70 + 0,75 + 0,75 + 1,25 = 3,45

• C#: 0,35 · 3 + 0,25 · 3 + 0,15 · 4 + 0,25 · 3 = 1,05 + 0,75 + 0,60 + 0,75 = 3,15

Die Tabelle empfiehlt Python.

Bewertung: Rechenweg 1 Punkt; je richtigem Nutzwert 0,5 Punkte; Empfehlung 0,5 Punkte.

• Neue Nutzwerte (2 Punkte): Python 0,20 · 5 + 0,25 · 5 + 0,30 · 2 + 0,25 · 3 = 3,60; Go 0,20 · 2 + 0,25 · 3 + 0,30 · 5 + 0,25 · 5 = 3,90; C# 0,20 · 3 + 0,25 · 3 + 0,30 · 4 + 0,25 · 3 = 3,30. Jetzt liegt Go vorn.

• Beurteilung (1 Punkt): Das Ergebnis kippt schon bei einer moderaten Verschiebung der Gewichte, die Entscheidung hängt also vor allem an der Gewichtung und nicht an klaren Unterschieden. Das Team sollte die Gewichte vor der Bewertung begründen und festlegen. Für 120 Sensoren mit einer Nachricht pro Minute ist der Ressourcenbedarf eher gering; ein Gewicht von 30 % dafür ist schwer zu begründen, die Kenntnisse im Team wiegen für den Betrieb über Jahre schwerer.

• Fehlendes Kriterium (2 Punkte, Kriterium 1, Begründung 1), z. B.: Zukunftssicherheit und Sicherheitsupdates von Sprache und Bibliotheken, sonst muss der Dienst später aufwendig umgezogen werden; Testbarkeit und Werkzeuge, damit Änderungen gefahrlos möglich sind; Einarbeitungsaufwand für jedes neue Ausbildungsjahr, weil die Betreuung wechselt.

Schwächen (je 1 Punkt), z. B.:

• Jede neue Sensorart verlangt eine Änderung der zentralen if-elif-Kette; die Funktion wächst und jede Änderung kann die bestehenden Prüfungen beschädigen.

• Grenzwerte stehen als feste Zahlen mitten im Code und lassen sich nicht je Raum oder Sensor einstellen.

• Die Art ist nur eine Zeichenkette; ein Tippfehler wie "CO2" fällt erst zur Laufzeit auf, weil dann einfach kein Hinweis entsteht.

• Die Daten liegen offen in Wörterbüchern; jeder Programmteil kann wert oder art beliebig ändern.

Entwurf (3 Punkte), z. B.:

• Eine abstrakte Klasse Sensor mit den gekapselten Attributen kennung, grenzwert und wert, der Methode messwert_setzen(wert) und der abstrakten Methode hinweis() (1 Punkt).

• Unterklassen Co2Sensor, TemperaturSensor und FeuchteSensor erben von Sensor und überschreiben hinweis() jeweils mit ihrer eigenen Regel; eine neue Sensorart ist eine neue Unterklasse, bestehender Code bleibt unverändert (1 Punkt).

• Eine Klasse Raum kennt ihre Sensoren (Aggregation 1 zu 1..*); der Dienst ruft für jeden Sensor hinweis() auf, ohne die Art zu kennen (Polymorphie) (1 Punkt).

from abc import ABC, abstractmethod

class Sensor(ABC):
    def __init__(self, kennung, grenzwert):
        self._kennung = kennung
        self._grenzwert = grenzwert
        self._wert = None

    def messwert_setzen(self, wert):
        self._wert = wert

    @abstractmethod
    def hinweis(self):
        pass

class Co2Sensor(Sensor):
    def hinweis(self):
        if self._wert is not None and self._wert > self._grenzwert:
            return "Bitte lüften"
        return None

Als UML-Klassendiagramm sieht der Entwurf so aus:

Eine Skizze als UML-Klassendiagramm oder als Stichwortliste ist ebenso richtig wie Code.

Je Vorteil 2 Punkte, z. B.:

• Skriptsprache: Änderungen sind sofort ausführbar, weil nicht kompiliert werden muss; für Administrationsaufgaben gibt es fertige Befehle und Module (Netzwerkzugriffe, Dateien, Zeitpläne), und das Skript lässt sich direkt auf dem Server anpassen.

• Compilersprache: Das fertige Programm läuft schneller und wird als ausführbare Datei ohne Quelltext und Interpreter verteilt; Syntax- und viele Typfehler werden schon beim Übersetzen gefunden, und meist steht eine leistungsfähige Entwicklungsumgebung zur Verfügung.

Der C#-Compiler übersetzt den Quelltext zunächst in eine prozessorunabhängige Zwischensprache (Common Intermediate Language, CIL). Erst beim Start lädt die .NET-Laufzeitumgebung diesen Zwischencode und übersetzt ihn mit einem Just-in-time-Compiler in Maschinencode für den vorhandenen Prozessor (2 Punkte). Vorteil, z. B.: Dasselbe übersetzte Programm läuft auf dem Linux-Server ebenso wie auf einem Windows-Testrechner, und der Compiler findet Typfehler schon vor dem Einsatz (1 Punkt).