Erweiterungsvorschläge

Beim Einsatz der mit dieser Klassenbibliothek erstellten Gerätetreiber sind einige Punkte aufgefallen, bei denen Erweiterungen von Vorteil sind. Hierzu werden im folgenden einige Vorschläge gemacht.

1. Wie in Abschnitt beschrieben, wird nach dem Empfangen einer Nachricht als erstes überprüft, ob die MSG_STOP-Flagge gesetzt ist. Ist dies der Fall, wird das Programm sofort beeendet, ohne zu überprüfen, ob der Absender der Nachricht berechtigt ist, diese Handlung auszulösen. Die Berechtigung kann hier aber nicht überprüft werden, da sie immer einer Aktion zugeordnet ist. Ein Ausweg wäre die Einführung einer Aktion STOP zum Feld PROCESS, das in Abschnitt eingeführt wurde. Diese Aktion könnte mit Sicherheitsüberprüfung zum Beenden des Programmes benutzt werden.

2. Bei der Verwendung der Errorklasse werden sowohl die Fehlermeldungen als auch die Debugmeldungen auf dasselbe Ausgabegerät error ausgegeben. Dadurch werden alle Meldungen vermischt und die Fehlermeldungen eventuell übersehen. Durch die Einrichtung zweier getrennter Ausgabegeräte (z.B. error und debug) könnten separate Ausgaben erfolgen.

3. Die Flexibilität der Errorklasse könnte durch die Einführung zweier getrennter Klassen ErrorCerr und ErrorMpx erhöht werden. Die erste würde Fehlerausgabemöglichkeiten über das lokale Terminal und die zweite über das Messagesystem zur Verfügung stellen. Beide erben die gemeinsamen Ausgabefunktionen von ihrer Basisklasse ErrorInterface. Am Beginn des Programms würde man je nach Ausgabeweg eine Instanz der Klasse ErrorCerr oder ErrorMpx anlegen. Dort, wo in den Programmen Ausgaben erfolgen sollen, müßte dann nur ErrorInterface verwendet werden. Bei der Implementierung des Programmes müßten mit diesem Verfahren nur die wirklich benötigten Ausgabefunktionen eingebunden werden, und es wäre mit geringem Aufwand möglich, den Ausgabeweg zu ändern.