Anhang
C Wichtige Änderungen gegenüber den Vorversionen

In Tango 1.5 wurden überflüssige Konstrukte der Vorversionen entfernt und einige Elemente semantisch konkretisiert. Da die älteren Konstrukte sehr kontextbezogen interpretiert wurden, können sie auch ohne explizite Beschreibung noch verstanden werden. Wichtig ist, dass sie mit Tango 1.5 nicht mehr verwendet werden können.

In den früheren Spezifikationen finden sich auch Beschreibungsweisen, die nicht korrekt waren, aber mangels Alternative oder Sprachbeschreibung trotzdem verwendet wurden. Diese ungenauen Beschreibungen wurden mit Domänenwissen korrigiert.

C.1 Mathematische Symbole sind nicht Teil der Tango-Beschreibungssprache

Frühere Versionen gingen davon aus, dass mathematische Berechnungen Teil der Tango-Spezifikation sind.

Jede Art von Berechnung oder Konvertierung wird jetzt in einer formlosen Wertbeschreibung, einer allgemeinen formlosen Beschreibung oder als komplexer Name notiert, es gibt keine freifliegenden Symbole mit mathematischer Bedeutung mehr.

Die Konflikte zwischen Tango-Symbolen und mathematischen Symbolen wie + und - sind damit ebenfalls gelöst.

C.2 Frühere Verwendung der Symbole > und < obsolet

Die Symbole werden nicht mehr in diesem Sinne verwendet. Das Auslösen eines Aktivators wird durch den Stern * markiert, das Versenden von Information an einen externen Empfänger wird notiert durch <<. Der Empfang von Information erfordert kein spezielles Sprachelement, die Information wird als Unteraspekt von $EXTERN abgegriffen oder durch einen Kanal empfangen.

C.3 Andere Wertzuweisungs-Syntax möglich

Frühere Tango-Versionen kannten keinen Operator für eine Wertzuweisung. Eine Wertänderung wurde wie folgt notiert:

        $EtDiesesFeld.SELECTION.NULL

Dies entspricht in der aktuellen Notation der Aussage

        $EtDiesesFeld.SELECTION := NULL

Die Nutzung der Wertzuweisung ist jetzt die empfohlene Methode um Mehrdeutigkeiten oder Missverständnisse auszuschließen, obwohl beide Möglichkeiten akzeptabel sind.

C.4 Keine automatische Berechnung mehr

Automatische Zustandsänderungen konnten in einer besonderen Syntax notiert werden. Im folgenden Beispiel wird ein Knopf automatisch aktiv geschaltet, wenn der eingegebene Kunde in der Datenbank vorhanden ist:

        +BtKundenLöschen
            .AKTIV [ AKTIV | INAKTIV ]
                +/ <- EtKundeName.{in Datenbank vorhanden}

Es wird keine Notation für die automatische Änderung mehr zur Verfügung gestellt. Stattdessen wird jetzt eine Eigenschaft definiert:

        +BtKundenLöschen
            .{bedienbar nur, wenn EtKundeName als Kunde in der Datenbank vorhanden ist}

Die Eigenschaft kann auch mit Hilfe einer Verzweigung oder Bedingung außerhalb eines Aktivitätsblocks beschrieben werden.

C.5 Rückgabewert und Bearbeitungsende geändert

Das Terminal DONE wurde als Kennzeichen für das Bearbeitungsende in einer Aktion verwendet, in Klammern dahinter der Rückgabewert:

@AskSave
    ?WnMain.EtAssets.CHANGED =
        = HasChanged
            => ?"Save Now?" =
                = Yes
                    => .@SaveNow
                       .DONE (OK)
                = No, drop it
                    => .DONE (OK)
                = Abort
                    => .DONE (ABORT)

Ein Rückgabewert wird jetzt mit ^OK, ^ABORT usw. notiert. DONE ist überflüssig.

C.6 Typangabe bei Inhaltsbeschreibung empfohlen

Die Inhaltsbeschreibung eines Zustands erfolgte früher ohne Typmarkierung. Diese ist jetzt zwar nicht zwingend vorgeschrieben, aber dringend empfohlen. Es sollte immer unterscheidbar sein, ob ein Zustand oder ein Typ, also eine beschreibende Eigenschaft gemeint ist.

    .MeinDatum1 : Datum                        // alte Notation ohne Typangabe, wäre immer noch erlaubt
    .MeinDatum2 : _Datum                       // besser mit Typangabe

C.7 Keine Aktionen als Prüfkriterium in Bedingungen

In früheren Versionen war die Verzweigung ausschließlich für die Bearbeitung von Anfragen an fremde Systeme oder den USER zuständig. Konsequenterweise wurde in Bedingungen auf die Resultate einer Aktion geprüft. Dies führte häufig zu Mehrfachnutzung derselben Aktion in einer Bedingungskaskade, was durch Lesekonvention wieder zurechtgebogen wurden. Konstrukte dieser Art müssen mit aller Vorsicht interpretiert werden.

Für die Nutzung von Ergebnissen aus Aktionen und zeitbehafteten Vorgängen ist jetzt die Verzweigung zuständig. Der Wertlieferant muss damit nur ein einziges Mal genutzt werden, die Prüfung des Ergebnisses gegen verschiedene Rückgabewerte organisiert das Konstrukt und ist deshalb problemlos. Die Nutzung von Zeit konsumierenden Vorgängen als Wertlieferant in einer Bedingung sollte vermieden werden.

C.8 Änderung der Listensyntax

In früheren Versionen wurde die Liste selbst als solche markiert. Der wiederholte Eintrag dieser Liste wurde über den Namen des Unteraspekts identifiziert:

!$KundeListe...
    .Kunde 
        .Name
        .Adresse

Diese Notation ist inkonsistent mit der übrigen Syntax der Tango-Beschreibungssprache, denn sie markiert als einzige einen Aspekt am Ende der Beschreibung. Des Weiteren erlaubt sie keine namenlose Liste, die für Nicht-Zustands-Aspekte nützlich ist, um auf wiederholtes Auftreten dieser Aspekte hinzuweisen. Dies führte zu etlichen uneinheitlichen Ersatznotationen in den Spezifikationen.

Der übergeordnete Aspekt wird jetzt nur mehr über den Namen als Halter einer Liste gekennzeichnet, die Markierung als Liste erfolgt am mehrfach wiederholten Eintrag.

!$KundeListe
    ...Kunde
        .Name
        .Adresse

C.9 Semantik der Auswahlliste geändert

Die Auswahlliste früherer Versionen sollte nur disjunkte Einträge enthalten. Es ist an der Auswahlliste nicht erkennbar, ob die Wertemengen tatsächlich in dieser Absicht niedergeschrieben wurden, aber in vielen beobachteten Fällen wurde dies offensichtlich nicht berücksichtigt. Die Aussagen rund um die Auswahlliste müssen deshalb mit Domänenwissen interpretiert werden, auf die Korrektheit der Niederschrift darf man sich nicht unbedingt verlassen. Insbesondere wurde häufig ignoriert, dass mit disjunkten Beschreibungen in Auswahllisten nicht nur der beschriebene Zustand, sondern implizit auch die Wertemengen in der Auswahlliste definiert werden.

In der aktuellen Version wird eine Sammlung disjunkter Wertemengen als strenge Auswahlliste formuliert, damit ist klargestellt, dass die beschriebenen Wertemengen disjunkt sein sollen. Die Auswahlliste enthält keine bewusst dissjunkten Wertemengen.

C.10 Abschließendes & hinter Bedingungen

Bedingungen, die mit UND verknüpft sind, brauchen am Ende der ersten Bedingungszeile ein abschließendes &, damit klargestellt ist, dass der nachfolgende Unterblock keine Erläuterung der Bedingung ist, sondern eine UND-Verknüpfung. Dieses & fehlt in vielen älteren Spezifikationen, weil irrtümlich davon ausgegangen wurde, dass ein Unterblock immer UND-verknüpft wäre. Beim Lesen älterer Spezifikationen muss immer geprüft werden, ob der Unterblock einer Bedingung eine Erläuterung oder eine UND-Verknüpfung ist.

C.11 Keine Verwendung von & als UND-Verknüpfung von Werten

Die logische Verknüpfung von Zuständen wurde in früheren Versionen vereinzelt etwa wie folgt notiert:

$freieFahrt <- $AmpelGrün & $KreuzungLeer

Dies ist nicht mehr zulässig. Durch & werden Bedingungen oder Bedingungskaskaden gekennzeichnet, durch die eine Aussage über die Relevanz eines zugeordneten Aktivitätsblocks getroffen wird, die alte Beschreibung ist syntaktisch fehlerhaft.

Die korrekte Notation erfordert eine formlose Wertbeschreibung:

$freieFahrt <- "$AmpelGrün UND $KreuzungLeer"

Dabei ist nicht definiert, wie die logische Verknüpfung in der formlosen Wertbeschreibung notiert werden muss. Statt UND wären auch AND, &, gleichzeitigMit denkbar.

C.12 Keine Filterbeschreibung mit Namen

Ein Schritt, der aus einem Pfad einen Filter macht, darf nicht mehr mit einem Namen beschrieben werden. Dies würde die Konsistenzprüfung torpedieren, denn der Name würde nirgendwo als Unteraspekt notiert sein, aber die Spezifikation wäre trotzdem vollständig. Diese neue Restriktion schränkt die Nutzbarkeit nicht ein, denn eine allgemeine formlose Beschreibung im Filter ist ein vollwertiger Ersatz.