Eine Messanwendung entwickeln
=============================

Dieser Einstieg richtet sich an Entwickler, die einen vorhandenen Ablauf
konfigurieren oder mpylab um Messlogik, Geräte oder eine Oberfläche erweitern.

1. Passende Erweiterungsebene wählen
------------------------------------

Prüfen Sie in dieser Reihenfolge:

#. Kann eine vorhandene Messklasse nur durch eine neue ``conf.py`` sowie
   :doc:`DOT- <../configuration/dot>` sowie :doc:`INI- und DAT-Dateien
   <../configuration/instrument-data>` angepasst werden?
#. Fehlt ein konkreter Gerätetreiber für eine vorhandene Gerätebasisklasse?
#. Wird tatsächlich eine neue fachliche Messklasse benötigt?
#. Benötigt der bestehende Ablauf lediglich einen weiteren UI-Adapter oder
   Reportbaustein?

Die :doc:`Framework-Architektur <../framework/architecture>` beschreibt die
Verantwortungsgrenzen.

2. Durchgängiges Beispiel nachvollziehen
----------------------------------------

Das :doc:`Entwicklertutorial <../framework/tutorial>` führt anhand eines
virtuellen Verstärkertests von ``conf.py`` über DOT und INI bis zu
Pfadkorrektur, Autosave, Tests und UI-Anbindung.

3. Schnittstellen und Verhaltensregeln einhalten
------------------------------------------------

* Messklassen erben von ``Measure`` und trennen Messung von Auswertung.
* Hardwareprotokolle bleiben in Gerätetreibern.
* ``MGraph`` erhält DOT-Conditions und physische Context-Controller über
  einen expliziten Kontext. Eigene Anwendungen behandeln eine erkannte
  Zustandsabweichung, ohne die Hardware automatisch zurückzuschalten.
* Messwerte bleiben als SCUQ-Quantities erhalten.
* Blockierende Aufrufe laufen bei Qt in einem Worker.
* RF-Off, Gerätegrenzen und manuelle Intervention bleiben erreichbar.

Vertiefungen finden Sie unter
:doc:`Messklassen <../framework/measurement-classes>`,
:doc:`Treiber <../framework/drivers>`,
:doc:`DOT-Context-Controller <../configuration/dot>`,
:doc:`Pfadkorrekturen <../framework/path-corrections>` und
:doc:`UI-Worker <../framework/ui-workers>`.
Die :doc:`EUT-Monitoring-Anleitung <../framework/eut-monitoring>` zeigt die
Entwicklung spezifischer Monitore, deren Thread-Kapselung und die Einbindung
über ``EUTMonitoringSession``.

Für weitergebbare Ergebnisse trennt die
:doc:`Report-Anleitung <../results/reports>` die TOML-basierte
Darstellungskonfiguration von eigenen Python-Reportmodulen. Die kuratierte
:doc:`Report-API <../../api/reports>` dokumentiert deren Lebenszyklus und
Einbindung.

4. Ohne Hardware absichern
--------------------------

Neue Abläufe benötigen reine Logiktests, Schnittstellentests der
Geräteklassen, eine virtuelle Konfiguration, einen kurzen End-to-End-Lauf
sowie Safety- und Resume-Tests. Der
:doc:`Testleitfaden <../framework/testing>` ordnet diese Ebenen ein.

5. API nachschlagen
-------------------

Die kuratierte, englischsprachige :doc:`API- und CLI-Referenz
<../../api/index>` dokumentiert die empfohlenen Erweiterungspunkte. Nicht
dokumentierte Namen mit führendem Unterstrich sind als interne
Implementierung zu behandeln.

Beim Aktualisieren älterer Anwendungen zeigt der :doc:`Leitfaden zur
Werkzeugmigration <../framework/tool-modules>`, wie Importe aus der
historischen Fassade ``mpylab.tools.util`` durch fokussierte Module ersetzt
werden.