TstDiff: Unterschiede bewerten

Dieses Dokument ist das Ergebnis eines Brainstormings zu Ticket PC020668.

Ziel der Bewertung soll sein,

• definieren zu können, welche Differenzen ok sind,
• einen Returncode von 0 zu bekommen, wenn keine relevanten Unterschiede existieren, um auf einen Blick zu erkennen, ob näher analysiert werden muss.

Im aktuellen Test-Datenmodell sind Protokolle, wie im Ausschnitt rechts zu sehen ist, folgendermaßen schon berücksichtigt:

• Ein Protokoll basiert auf zwei Aufzeichnungen
• Ein Protokoll beinhaltet Protokollsätze
• Ein Protokollstatus basiert auf Protokollsätze

Aus der Aufgabe heraus gibt es zwei wesentliche Anforderungen, die in diesem Datenmodell schon modelliert sind:

1. Definieren welche Differenzen ok sind.
2. Ein rc=0 zu bekommen, wenn keine relevanten Unterschiede existieren.

Der erste Punkt bezieht sich auf die Entität „Protokollsatz“. Der zweite Punkt bezieht sich auf die Entität „Protokollstatus“.

Den Ablauf, der als Ergebnis einen Protokollstatus liefert, kann man grob in vier Schritte unterteilen:

1. Erstellung des Protokolls.
2. Gewichtung der Protokollsätze.
3. Protokollsätze mit Stati versehen.
4. Ermitteln des allgemeinen Status auf Basis der Stati der Protokollsätze.

Seit dem TAA Release 6.07 steht hierfür das Utility „tstdiff“ zur Verfügung. Es erstellt auf Anforderung ein Protokoll mit Unterschieden zu: Der Input- und Output-Schnittstelle eines Moduls, oder die Unterschiede zweierlei Ausführungen eines Bausteinaufrufes, oder die Unterschiede im produzierten Schriftgut.

Die Gewichtung der Protokollsätze hat zur Folge, dass jeder Protokollsatz, jede Differenz und Indifferenz, die Gewichtung „Severe“, „Warning“ oder „Info“ zugeordnet bekommt. Die Zuordnung soll codiert erfolgen und ggf. auf Basis eines Regelwerks übersteuert werden können.

In diesem Schritt soll jeder Protokollsatz auf Basis seiner Gewichtung einen Status bekommen, der besagt, dass der Protokollsatz „akzeptiert“, „vielleicht akzeptiert“ oder „nicht akzeptiert“ werden kann. Die Zuordnung soll codiert erfolgen und auf Basis eines Regelwerks übersteuert werden und ggf. anschließend manuell verändert werden können.

In diesem Schritt wird der Status des Protokolls ermittelt. Das Ergebnis ist ein „ok“ oder „nicht ok“. Auch hier sollte ein codierter Ansatz mit Übersteuerungsmöglichkeit durch ein Regelwerk vorgesehen werden.

In diesem Absatz wird beschrieben, welche Zuordnungen an Protokollsätze bezüglich Gewichtung, Status und allgemeiner Status die codierte Ermittlung durchführen soll.

Die Gewichtungen haben folgende Bedeutung:

• Severe: Die Gewichtung „Severe“ für einen Protokollsatz deutet darauf hin, dass sich etwas unterschieden oder auch nicht unterschieden hat, welches schwerwiegende Folgen für den durchgeführten Ablauf haben könnte.
• Warning: Die Gewichtung „Warning“ für einen Protokollsatz deutet darauf hin, dass sich etwas unterscheidet, oder nicht unterscheidet, welches möglicherweise Folgen für den durchgeführten Ablauf haben könnte.
• Info: Die Gewichtung „Info“ für einen Protokollsatz besagt, dass eine Differenz oder Indifferenz festgestellt wurde, die nicht die Gewichtung „Severe“ oder „Warnung“ hat.

Untenstehende Tabelle ordnet möglichen Differenzprotokollsätzen eine Gewichtung zu. Welche Auswirkung die Gewichtung auf den allgemeinen Status eines Protokolls hat, wird beschrieben in Zuordnung eines Status an Protokollsätze.

Mittels des Regelwerks ist es dann möglich diese Gewichtungen zu verändern.

Die Stati haben folgende Bedeutung:

• Accept: Der Status „Accept“ besagt, dass dieser Protokollsatz akzeptiert wird.
• MayBeAccept: Der Status „MayBeAccept“ besagt, dass dieser Protokollsatz vielleicht akzeptiert wird.
• NotAccept: Der Status „NotAccept“ besagt, dass dieser Protokollsatz nicht akzeptiert wird.

Die codierte Zuordnung eines Status an einen Protokollsatz sollte nicht allzuviel Logik beinhalten, sondern eher pauschal die Stati setzen. Mittels eines Regelwerkskönnen dann die Ausnahmen bzw. Übersteuerungen beschrieben werden. Ein Vorschlag für eine allgemeine Regel wäre:

1. Alles mit Gewichtung „Info“ bekommt den Status „Accept“
2. Alles mit Gewichtung „Warning“ bekommt den Status „MayBeAccept“
3. Alles mit Gewichtung „Severe“ bekommt den Status „NotAccept“

Ist die Gewichtung durch die Codierung und seine Übersteuerung durch das Regelwerk zur Gewichtung richtig bestückt, müsste diese allgemeine Zuordnung im Normalfall zutreffen und die relevanten Unterschiede mittels eines „NotAccept“ kennzeichnen.

Die Stati haben folgende Bedeutung:

• Ok: Der Status „Ok“ besagt, dass dieses Protokoll keine relevanten Unterschiede beinhaltet. Der TstDiff könnte in diesem Fall ein rc=0 zurückliefern.
• NotOk: Der Status „NotOk“ besagt, dass dieses Protokoll eine nähere Betrachtung braucht, weil es relevante Unterschiede gibt. Der TstDiff könnte in diesem Fall die Anzahl der relevanten Unterschiede als Returncode zurückliefern.

Die codierte Ermittlung soll auch hier eher pauschal arbeiten und mittels eines Regelwerks seine Logik bekommen. Ein Vorschlag für eine allgemeine Regel wäre:

1. Gibt es mindestens einen Protokollsatz mit „NotAccept“, dann ist der Protokollstatus „NotOk“
2. Gibt es keinen Protokollsatz mit „NotAccept“, aber mehr als 10 Protokollsätze mit „MayBeAccept“, dann ist der Protokollstatus „NotOk“
3. In allen anderen Fällen ist der Protokollstatus „Ok“

In diesem Absatz wird beschrieben, wie Zuordnungen an Protokollsätze bezüglich Gewichtung, Status und des allgemeinen Status in ein Regelwerk abgelegt werden könnten. Bei der Implementierung des Regelwerks sollte man überlegen bzw. in Betracht ziehen, ob TAA-Module hier ein Rolle spielen können, um z.B. komplexe oder fachliche Regeln zu implementieren. Vielleicht ist ein Prinzip wie der „Buddy“ in CTV auch hier brauchbar.

==== Aufgabe 'PC020668' und der Brainstorm Die Aufgabe wurde folgendermaßen formuliert: „Komfort bei Differenzen. Man muss einerseits in der Lage sein zu definieren, welche Differenzen ok sind und andererseits muss es möglich sein ein rc=0 (Returncode) zu bekommen, wenn keine relevanten Unterschiede existieren, um auf einen Blick zu erkennen ob näher analysiert werden muß.“

Um einen Eindruck zu bekommen welche Art der Differenzen relevant sein könnten und was man möglicherweise über ein Protokoll wissen möchte, wurde ein wenig gebrainstormt; das Ergebnis des Brainstorms finden Sie unter http://www.teamwise.de/taa/mld/pc/020/668.htm. Relevanter Ausschnitt des Test-Datenmodells Im aktuellen Test-Datenmodell sind Protokolle, wie im Ausschnitt rechts zu sehen ist, folgender- maßen schon berücksichtigt:

Ein Protokoll basiert auf zwei Aufzeichnungen

Ein Protokoll beinhaltet Protokollsätze

Ein Protokollstatus basiert auf Protokollsätze

Aus der Aufgabe heraus gibt es zwei wesentliche Anforderungen die in diesem Datenmodell schon modelliert sind: Definieren welche Differenzen ok sind. Ein rc=0 zu bekommen, wenn keine relevanten Unterschiede existieren. Der erste Punkt bezieht sich auf die Entität „Protokollsatz“. Der zweite Punkt bezieht sich auf die Entität „Protokollstatus“. Ermittlung eines Protokollstatus Der Ablauf, der als Ergebnis einen Protokollstatus liefert, kann man grob in vier Schritte unterteilen: Erstellung des Protokolls. Gewichtung der Protokollsätze. Protokollsätze mit Stati versehen. Ermitteln des allgemeinen Status auf Basis der Stati der Protokollsätze. Schritt 1: Erstellung des Protokolls Seit dem TAA Release 6.07 steht hierfür das Utility „tstdiff“ zur Verfügung. Es erstellt auf Anforderung ein Protokoll mit Unterschieden zu: Der Input- und Outputschnittstelle eines Moduls, oder die Unterschiede zweierlei Ausführungen eines Bausteinaufrufes, oder die Unterschiede im produzierten Schriftgut. Für eine genaue Beschreibung von „tstdiff“ möchte ich Sie auf http://www.teamwise.de/taa/Notes/TstDiff.htm verweisen. Schritt 2: Gewichtung der Protokollsätze Die Gewichtung der Protokollsätze hat zur Folge, dass jeder Protokollsatz, jede Differenz und Indifferenz, die Gewichtung „Severe“, „Warning“ oder „Info“ zugeordnet bekommt. Die Zuordnung soll codiert erfolgen und ggf. auf Basis eines Regelwerks übersteuert werden können. Schritt 3: Protokollsätze mit Stati versehen In diesem Schritt soll jeder Protokollsatz auf Basis seiner Gewichtung einen Status bekommen, der besagt, dass der Protokollsatz „akzeptiert“, „vielleicht akzeptiert“ oder „nicht akzeptiert“ werden kann. Die Zuordnung soll codiert erfolgen und auf Basis eines Regelwerks übersteuert werden und ggf. anschließend manuell verändert werden können. Schritt 4: Ermitteln des allgemeinen Status In diesem Schritt wird der Status des Protokolls ermittelt. Das Ergebnis ist ein „ok“ oder „nicht ok“. Auch hier sollte ein codierter Ansatz mit Übersteuerungsmöglichkeit durch ein Regelwerk vorgesehen werden. Vorschlag für die Implementierung Die vier einzelnen Schritte sollten so implementiert werden, dass sie als selbständige Einheit ausführbar sind und ebenso sollte der TstDiff alle vier Schritte auf einmal durchführen können. Falls die Umsetzung dieses Konzeptes nicht auf einmal durchgeführt werden soll, empfiehlt es sich in der ersten Phase, Schritt 2 bis 4 auf Basis der codierten Ermittlung zu implementieren (Schritt 1 ist schon vorhanden). In der zweiten Phase könnte dann ein Regelwerk hinzugefügt werden und in der dritten Phase die manuelle Änderung durch den Benutzer oder ggf. sein lokales Regelwerk. Die codierte Ermittlung In diesem Absatz wird beschrieben, welche Zuordnungen an Protokollsätze bezüglich Gewichtung, Status und allgemeiner Status die codierte Ermittlung durchführen soll. Die hier beschriebene Zuordnung ist ein Vorschlag. Schritt 2: Gewichtung der Protokollsätze Die Gewichtungen haben folgende Bedeutung:

Severe Die Gewichtung „Severe“ für einen Protokollsatz deutet darauf hin, dass sich etwas unterschieden oder auch nicht unterschieden hat, welches schwerwiegende Folgen für den durchgeführten Ablauf haben könnte.

Warning Die Gewichtung „Warning“ für einen Protokollsatz deutet darauf hin, dass sich etwas unterscheidet, oder nicht unterscheidet, welches möglicherweise Folgen für den durchgeführten Ablauf haben könnte.

Info Die Gewichtung „Info“ für einen Protokollsatz besagt, dass eine Differenz oder Indifferenz festgestellt wurde, die nicht die Gewichtung „Severe“ oder „Warnung“ hat.

Untenstehende Tabelle ordnet möglichen Differenzprotokollsätzen eine Gewichtung zu. Welche Auswirkung die Gewichtung auf den allgemeinen Status eines Protokolls hat, wird beschrieben in Zuordnung eines Status an Protokollsätze.

Differenz Gewichtung Der Modultyp hat sich verändert. Severe Der Modultyp hat sich nicht verändert. Info Einer der beiden Zustände ist nicht gesetzt, was auf einen möglichen Absturz oder eine unvollständige Implementierung hindeutet. Severe Der Zustand des Moduls hat sich verändert. Warning Der Zustand des Moduls hat sich nicht verändert. Info Die Gesamtverweildauer oder die Verweildauer (ohne gerufene Module) in einem der beiden Bausteinaufrufe ist leer bzw. 0, was auf eine fehlende Abmeldung (Unregister) des Moduls hindeutet. Severe Die Gesamtverweildauer des rechten Bausteinaufrufes weicht um mehr als 30% vom Referenzstand ab. Severe Die Gesamtverweildauer des rechten Bausteinaufrufes weicht um mehr als 20% vom Referenzstand ab. Warning Die Gesamtverweildauer des rechten Bausteinaufrufes weicht weniger als 20% vom Referenzstand ab. Info Die Verweildauer im Baustein des rechten Bausteinaufrufes (ohne gerufene Module) weicht um mehr als 20% vom Referenzstand. Severe Die Verweildauer im Baustein des rechten Bausteinaufrufes (ohne gerufene Module) weicht um mehr als 10% vom Referenzstand ab. Warning Die Verweildauer im Baustein des rechten Bausteinaufrufes (ohne gerufene Module) weicht weniger als 10% vom Referenzstand ab. Info Die Anzahl gerufener Bausteine unterscheidet sich. Severe Die Anzahl gerufener Bausteine ist gleich. Info Der gerufene Baustein wird später oder früher gerufen (CalleeOrder). Warning Beim gerufenen Baustein wird ein anderes Ereignis ausgelöst. Warning Der gerufene Baustein wird in der gleichen Reihenfolge und mit dem gleichen Ereignis gerufen. Info Es werden andere oder zusätzliche Conditionoperationen durchgeführt. Warning Es werden die gleichen Conditionoperationen durchgeführt. Info Die Severity bei der gleichen Condition ist eine andere. Severe Die Severity bei der gleichen Condition ist gleich. Info Es treten die gleichen oder mehrere Oopse auf. Severe Es treten weniger Oopse auf; also Oopse, die im Referenzstand vorhanden sind und im rechten Bausteinaufruf nicht. Info Ein Parameter oder globales Objekt ist nicht vorhanden. Severe Ein Parameter oder globales Objekt ist zusätzlich vorhanden. Severe Typ, Objt, Class oder Dstr eines Parameters oder globalen Objektes unterscheiden sich. Severe Typ, Objt, Class oder Dstr eines Parameters oder globalen Objektes sind gleich. Info Die Rolle eines Parameters oder globalen Objektes ist unterschiedlich. Warning Die Rolle eines Parameters oder globalen Objektes ist gleich. Info Der InputCount unterscheidet sich. Warning Der InputCount ist gleich. Info Der OutputCount unterscheidet sich. Warning Der OutputCount ist gleich. Info Der Insert- bzw. DeleteCount unterscheidet sich. Warning Der Insert- bzw. DeleteCount ist gleich. Info Die Reihenfolge der Items ist eine andere. Warning Die Reihenfolge der Items ist die gleiche. Info Ein Feld ist bei einem der beiden Bausteinaufrufen nicht vorhanden (missing=yes), was auf eine veränderte Datenstruktur hinweist. Severe Ein Feld ist bei einem der beiden Bausteinaufrufen nicht gefüllt und beim anderen Bausteinaufruf gefüllt (empty=yes). Warning Ein Feld unterscheidet sich im Inhalt oder hat den gleichen Inhalt. Info Mittels des Regelwerks ist es dann möglich diese Gewichtungen zu verändern. Schritt 3: Protokollsätze mit Stati versehen Die Stati haben folgende Bedeutung:

Accept Der Status „Accept“ besagt, dass dieser Protokollsatz akzeptiert wird.

MayBeAccept Der Status „MayBeAccept“ besagt, dass dieser Protokollsatz vielleicht akzeptiert wird.

NotAccept Der Status „NotAccept“ besagt, dass dieser Protokollsatz nicht akzeptiert wird.

Die codierte Zuordnung eines Status an einen Protokollsatz sollte nicht allzuviel Logik beinhalten, sondern eher pauschal die Stati setzen. Mittels eines Regelwerks können dann die Ausnahmen bzw. Übersteuerungen beschrieben werden. Ein Vorschlag für eine allgemeine Regel wäre: Alles mit Gewichtung „Info“ bekommt den Status „Accept“ Alles mit Gewichtung „Warning“ bekommt den Status „MayBeAccept“ Alles mit Gewichtung „Severe“ bekommt den Status „NotAccept“ Ist die Gewichtung durch die Codierung und seine Übersteuerung durch das Regelwerk zur Gewichtung richtig bestückt, müsste diese allgemeine Zuordnung im Normalfall zutreffen und die relevanten Unterschiede mittels eines „NotAccept“ kennzeichnen. Schritt 4: Ermitteln des allgemeinen Status Die Stati haben folgende Bedeutung:

Ok Der Status „Ok“ besagt, dass dieses Protokoll keine relevanten Unterschiede beinhaltet. Der TstDiff könnte in diesem Fall ein rc=0 zurückliefern.

NotOk Der Status „NotOk“ besagt, dass dieses Protokoll eine nähere Betrachtung braucht, weil es relevante Unterschiede gibt. Der TstDiff könnte in diesem Fall die Anzahl der relevanten Unterschiede als Returncode zurückliefern.

Die codierte Ermittlung soll auch hier eher pauschal arbeiten und mittels eines Regelwerks seine Logik bekommen. Ein Vorschlag für eine allgemeine Regel wäre: Gibt es mindestens einen Protokollsatz mit „NotAccept“, dann ist der Protokollstatus „NotOk“ Gibt es keinen Protokollsatz mit „NotAccept“, aber mehr als 10 Protokollsätze mit „MayBeAccept“, dann ist der Protokollstatus „NotOk“ In allen anderen Fällen ist der Protokollstatus „Ok“ Die Zahl 10 in Regel 2 ist ein Vorschlag für den Default und sollte sowieso mittels einer Commandlineoption bzw. eines Registryeintrags gesetzt werden können. Definition eines Regelwerks zur Ermittlung In diesem Absatz wird beschrieben, wie Zuordnungen an Protokollsätze bezüglich Gewichtung, Status und des allgemeinen Status in ein Regelwerk abgelegt werden könnten. Bei der Implementierung des Regelwerks sollte man überlegen bzw. in betracht ziehen, ob TAA-Module hier ein Rolle spielen können, um z.B. komplexe oder fachliche Regeln zu implementieren. Vielleicht ist ein Prinzip wie der „Buddy“ in CTV auch hier brauchbar.

Die Gewichtung mittels eines Regelwerks basiert einerseits auf einer statischen Definition, andererseits auf einer dynamischen Ermittlung der Gewichtung. Die statische Definition dient eher der Gewichtung allgemeiner Protokollsatzarten und weniger von fachlichen Unterschieden. Wohingegen die dynamische Ermittlung eher die fachliche Gewichtung für einzelne Protokollsätze vornehmen soll. Dieser Abschnitt behandelt die statische Definition. Zur fachlichen Gewichtung sei nur vermerkt, dass dies für spezifische Abläufe und Benutzergruppen z.B. mittels Pseudocode, Stylesheets und/oder Callbackfunktionen vorstellbar wäre.

Für die Gewichtung eines Protokollsatzes sind folgende Eigenschaften wichtig:

• Equal: Protokollsatz beinhaltet keine Differenz
• NotEqual: Protokollsatz beinhaltet eine Differenz
• Empty: Protokollsatz beinhaltet ein leeres Feld (empty=yes)
• Missing: Protokollsatz beinhaltet ein fehlendes Feld (missing=yes)

Die Eigenschaften „Equal“ und „NotEqual“ beziehen sich immer auf den ganzen Satz, dagegen beziehen sich „Empty“ und „Missing“ nur auf einen Teil des Satzes. Deswegen sollte der Satzteil, worauf sich die Gewichtung bezieht, angegeben werden. Als mögliche Werte für den Satzteil gibt es „complete“ für den kompletten Satz, „left“ für den Referenzstand und „right“ für den aktuellen Stand. Eine Tabelle, die die Gewichtung der Protokollsatzarten beinhaltet, könnte folgendermaßen aussehen:

Der Eintrag „Moduletype“ sagt aus, dass die Gewichtung für „Der Modultyp hat sich verändert“ anstelle von „Severe“ jetzt „Warning“ ist.

Der Eintrag „Itemfield“ sagt aus, dass die Gewichtung für „Ein Feld ist bei einem der beiden Bausteinaufrufen nicht vorhanden (missing=yes), was auf eine veränderte Datenstruktur hinweist.“ nur „Severe“ als Gewichtung zuordnet, wenn es auf den aktuellen Stand (Rechts) zutrifft. Trifft die Regel auf den Referenzstand zu, bekommt der Protokollsatz die Gewichtung „Info“. Damit hat man dann erreicht, dass neue Felder in einer Datenstruktur nicht mehr als relevante Differenz gelten (Gewichtung „Severe“) und fehlende Felder in der neuen Datenstruktur trotzdem als relevante Differenz gelten.

Die Tabelle könnte, ggf. in einer nächsten Stufe, ein zusätzliches Feld „IfCode“ bekommen, wo dann in Pseudocode beschrieben wird, ob diese Regel für einen Protokollsatz gelten soll. Hierdurch könnte man z.B. den Eintrag „ItemField“ auf einen einzelnen Parameter beschränken, von dem bekannt ist, dass er weniger Felder bekommen hat. Allerdings sei hier noch erwähnt, dass zu überlegen ist, in welchem Kontext dieser Pseudocode dann auszuführen ist. Eine Möglichkeit wäre innerhalb des Kontextes des Bausteinaufrufes, wobei angegeben werden muss, ob es der Referenzstand bzw. der aktuelle Stand des Kontextes sein soll. Die Auflistung der Protokollsatzarten sollte im Rahmen der Umsetzung dieses Konzeptes durchgeführt werden.

In der codierten Zuordnung wird pauschal entschieden und allein auf Basis der Gewichtung. Im Regelwerk soll hingegen die Möglichkeit bestehen, auf Basis der Protokollsatzart sowie der einzelnen Protokollsätze zu entscheiden, welchen Status dieser Satz bekommt. Fangen wir erst mal mit der Tabelle an, in der beschrieben wird welche Protokollsatzart unter Berücksichtigung der Gewichtung welchen Status bekommt.

Der Eintrag „CallEvnt“ besagt, dass bei einer Gewichtung „Warning“ der Protokollsatzstatus „Accept“ sein soll (Die Gewichtung „Warning“ wird vergeben, wenn „Beim gerufenen Baustein wird ein anderes Ereignis ausgelöst“ zutrifft). Der Eintrag „ItemField“ ist ein Beispiel für eine „überflüssige“ Regel in dem Sinne, dass die codierte Zuordnung alle Gewichtungen mit „Warning“ schon den Status „MayBeAccept“ zugeordnet hat. Inwieweit dieses Konzept am Ende eine Oberfläche braucht um die Regeln zu definieren, soll hier nicht geklärt werden. Auch hier gilt, wie bei Schritt 2, dass eine Spalte mit „IfCode“ hinzugefügt werden könnte, um anstelle von Regeln für Protokollsatzarten, beschränkt auch Regeln für Protokollsätze definieren zu können. Inwieweit Pseudocode oder Callback/Buddymodule der richtige bzw. der bessere Ansatz sind, sollte noch weiter überdacht werden. Hier soll lediglich der Hinweis stehen, dass ein solches Instrument dem Komfort dienen könnte, jedoch auch seinen Preis bezüglich Entwicklung, Test und Wartung hat.

In der codierten Ermittlung werden für den allgemeinen Status nur die Stati der Protokollsätze berücksichtigt. Ein Regelwerk in diesem Schritt sollte eher anstelle der codierten Ermittlung ziehen und Regeln beinhalten, die für alle Protokollsatzarten gelten sowie Regeln die für einzelne Protokollsatzarten gelten. Im Moment sehe ich hier noch keinen Bedarf, auf Basis von einzelnen Protokollsätzen den allgemeinen Status zu beeinflussen. Falls so eine Situation auftreten sollte, wäre zuerst zu überlegen, ob es nicht mittels Schritt 3 umzusetzen ist, indem ein Status „NotAccept“ für diesen Protokollsatz gesetzt wird. Die Tabelle beschreibt Regeln, die dazu führen, dass ein Protokollstatus nicht in Ordnung ist. Trifft keine Regel zu, ist der Protokollstatus „Ok“.

TimeFunc|MayBeAccept|1|NotOk|

Im ersten Eintrag wurde keine Protokollsatzart angegeben; damit gilt er für alle Sätze und besagt, dass erst bei einer Anzahl von 5 oder mehr Protokollsätzen mit dem Status „NotAccept“ der Protokollstatus „NotOk“ ist. Hier hat man direkt ein Beispiel, weswegen in diesem Schritt entweder die codierte Logik oder das Regelwerk ziehen soll und nicht beide, da dann schon bei einem Satz mit Status „NotAccept“ der Status auf „NotOk“ käme.

Im zweiten Eintrag („TimeFunc“) wird bei auftreten eines Satzes der Art „TimeFunc“ mit Satzstatus „MayBeAccept“ der Protokollstatus „NotOk“. In diesem Satz steht, dass wenn „Die Verweildauer im Baustein des rechten Bausteinaufrufes weicht um mehr als 10% vom Referenzstand ab.“ zutrifft, das Protokoll nicht in Ordnung ist. Dieses Ergebnis hätte man auch erreichen können, indem man im Schritt 2 die Gewichtung für diese Satzart verändert hätte oder in Schritt 3 den Status für diese Satzart auf „NotAccept“ gesetzt hätte.

Der erste Schritt zur Umsetzung dieses Konzeptes sollte die Implementierung der „codierten Ermittlung“ sein. Diese liefert etwas mehr Komfort als zur Zeit gegeben ist und hält dafür die Komplexität und den Wartungsaufwand in Grenzen. Wenn man die Tabelle in Schritt 2 (Zuordnung Protokollsatzart zu Gewichtung) als Referenztabelle ablegt und nicht im Code fest verdrahtet, hat man die Möglichkeit, für verschiedene Umgebungen solche Tabellen pflegen zu können.

Die Umsetzung des Regelwerks, sei es in der hier gezeigten Form, oder nach erneuter Betrachtung in einer anderen Form, bringt ein Stück Komplexität mit sich, die sehr wahrscheinlich Tools zur Pflege braucht. Inwieweit sich der dadurch zusätzlich entstandene Komfort gegenüber dem Aufwand bzw. der Pflege und Fehleranfälligkeit rechnet, sollte überdacht werden.